I am at a complete loss on this one:

(FOC422) THE FOCUS FILE IS NOT ON A WRITABLE DISK. CANNOT MODIFY:
 (FOC36398)  CANT MODIFY SEGMENT SEG01    IN READ-ONLY FILE INV_BAL  (INCLUDE)

This is happening EVERY time I attempt to use MODIFY to fill a very large FOCUS / XFOCUS table, which resides in the same directory as many other focus tables.

The MFD starts out as:

FILENAME=INV_BAL , SUFFIX=XFOCUS, $
  SEGMENT=SEG01, SEGTYPE=S5, $

I have tried both SUFFIX=FOC and SUFFIX=XFOCUS.

The table was created without error using:

CREATE FILE INV_BAL DROP

A CHECK FILE of the table I am trying to fill results in:

0 NUMBER OF ERRORS=     0
 NUMBER OF SEGMENTS=   1  ( REAL=    1  VIRTUAL=   0 )
 NUMBER OF FIELDS=    65  INDEXES=   5  FILES=     1
 TOTAL LENGTH OF ALL FIELDS=  986

5 of those fields are alpha index fields, the largest of which is 12 characters. The other 60 fields are P16.2 format.

The CODE that prepares the ALPHA file produces 400,000 rows that need to be loaded into the table. However, the following error is generated by MODIFY statements every time.

 (FOC422) THE FOCUS FILE IS NOT ON A WRITABLE DISK. CANNOT MODIFY:
 (FOC36398)  CANT MODIFY SEGMENT SEG01    IN READ-ONLY FILE INV_BAL  (INCLUDE)
 0 TRANSACTIONS:         TOTAL =     1  ACCEPTED=     1  REJECTED=     0
 SEGMENTS:             INPUT =     0  UPDATED =     0  DELETED =     0
 BYPASSING TO END OF COMMAND

This table is being saved on an AIX box, permissions have been verified, and there is more than enough space in the hard drive.

The final element, this table can be saved if a ON TABLE HOLD FORMAT FOCUS is used, So I doubt that it is actually a space issue. However the end client wants MODIFY used.

This is a WebFOCUS 7.6.8 installation on AIX.

Since I am not that experienced with MODIFY, I would greatly appreciate any assistance that can be provided.

This message has been edited. Last edited by: Kerry,

I would suggest putting in a case with techsupport.

Hi,
You wrote that you can create your FOCUS file with the command:

quote:

CREATE FILE INV_BAL DROP

I don't recall a DROP option. Are you sure about this?
I would suggest you use the USE command to specify where this file shoud be created. For example:

USE 
pathname/INV_BAL.FOC NEW
END
CREATE FILE INV_BAL

Then test where the file has been created:

? FILE INV_BAL

Then run your MODIFY procedure.

Another thing. Is your MODIFY long and complicated? If not, could you post it?

From the manual:

quote:

The DROP option on the CREATE FILE command prevents the display of the messages and creates the data source, dropping the existing table first if necessary and re-parsing the Master File if it changed.

And you should use the USE command to point to the correct location. That way you're sure it will go to the desired location in stead of the default.

ok, here is the entire MODIFY:

USE CLEAR *

USE
/cisfocrpt/data/invbal.foc NEW AS INV_BAL
END


CREATE FILE INV_BAL

MODIFY FILE INV_BAL
LOG NOMATCH MSG OFF
LOG DUPL MSG OFF

FIXFORM ERP/4 ITEM_NUM/5 FISCAL_YEAR/3 WAREHOUSE/12 UOM_CODE/2 QTY_MO_01/16 QTY_MO_02/16 QTY_MO_03/16 QTY_MO_04/16 QTY_MO_05/16 QTY_MO_06/16 QTY_MO_07/16 QTY_MO_08/16 QTY_MO_09/16 QTY_MO_10/16 QTY_MO_11/16 QTY_MO_12/16 ONHAND_MO_01/16 ONHAND_MO_02/16 ONHAND_MO_03/16 ONHAND_MO_04/16 ONHAND_MO_05/16 ONHAND_MO_06/16 ONHAND_MO_07/16 ONHAND_MO_08/16 ONHAND_MO_09/16 ONHAND_MO_10/16 ONHAND_MO_11/16 ONHAND_MO_12/16 PICNT_01/16 PICNT_02/16 PICNT_03/16 PICNT_04/16 PICNT_05/16 PICNT_06/16 PICNT_07/16 PICNT_08/16 PICNT_09/16 PICNT_10/16 PICNT_11/16 PICNT_12/16 PIAMT_01/16 PIAMT_02/16 PIAMT_03/16 PIAMT_04/16 PIAMT_05/16 PIAMT_06/16 PIAMT_07/16 PIAMT_08/16 PIAMT_09/16 PIAMT_10/16 PIAMT_11/16 PIAMT_12/16 UNIT_COST_01/16 UNIT_COST_02/16 UNIT_COST_03/16 UNIT_COST_04/16 UNIT_COST_05/16 UNIT_COST_06/16 UNIT_COST_07/16 UNIT_COST_08/16 UNIT_COST_09/16 UNIT_COST_10/16 UNIT_COST_11/16 UNIT_COST_12/16

MATCH ERP ITEM_NUM FISCAL_YEAR WAREHOUSE UOM_CODE

 ON MATCH UPDATE QTY_MO_01 QTY_MO_02 QTY_MO_03 QTY_MO_04 QTY_MO_05 QTY_MO_06 QTY_MO_07 QTY_MO_08 QTY_MO_09 QTY_MO_10 QTY_MO_11 QTY_MO_12 ONHAND_MO_01 ONHAND_MO_02 ONHAND_MO_03 ONHAND_MO_04 ONHAND_MO_05 ONHAND_MO_06 ONHAND_MO_07 ONHAND_MO_08 ONHAND_MO_09 ONHAND_MO_10 ONHAND_MO_11 ONHAND_MO_12 PICNT_01 PICNT_02 PICNT_03 PICNT_04 PICNT_05 PICNT_06 PICNT_07 PICNT_08 PICNT_09 PICNT_10 PICNT_11 PICNT_12 PIAMT_01 PIAMT_02 PIAMT_03 PIAMT_04 PIAMT_05 PIAMT_06 PIAMT_07 PIAMT_08 PIAMT_09 PIAMT_10 PIAMT_11 PIAMT_12 UNIT_COST_01 UNIT_COST_02 UNIT_COST_03 UNIT_COST_04 UNIT_COST_05 UNIT_COST_06 UNIT_COST_07 UNIT_COST_08 UNIT_COST_09 UNIT_COST_10 UNIT_COST_11 UNIT_COST_12
 ON NOMATCH INCLUDE

DATA ON DM0008
END

-RUN

I had included the DROP in the intial CREATE, but even without it, I get the same error.

First, I don't see anything wrong with the code. With that said, I have a few suggestions. While I know these suggestions should not matter, they really seem to help when I have problems with MODIFY.

1. Change the MODIFY so that each line is less than 80 characters. I know that should not be the case but I have had issues that go away as soon as I do that.
2. Put the LOG statements just before the DATA statement.
3. Create a master for the input data, i.e. DM0008.MAS and use a FIXFORM FROM DM0008. If the file is being created with a ON TABLE SAVE AS command, use ON TABLE HOLD AS with a ON TABLE SET HOLDFORMAT ALPHA. The ON TABLE HOLD AS will create the master for DM0008.
4. You are sure that the input file is alpha and not binary?
5. What version of WebFOCUS are you using. MODIFY in early verisions of 7.1 (we found it in 7.1.3) would not load properly with if there was missing data and the input file format was alpha. I think this was fixed in 7.1.7.

Your MODIFY would look something like this:

MODIFY FILE INV_BAL
FIXFORM FROM DM0008
MATCH ERP ITEM_NUM FISCAL_YEAR WAREHOUSE UOM_CODE
ON NOMATCH INCLUDE
ON MATCH UPDATE *
LOG NOMATCH MSG OFF
LOG DUPL MSG OFF
DATA ON DM0008
END

This message has been edited. Last edited by: jgelona,

It sounds like a file-permissions issue. CREATE only needs to Write, whereas Modify needs to Update.

Or: Perhaps "NEW" is tripping up the Modify.

Check that the CREATE worked (as Daniel suggested); and reissue the USE, without "NEW", before the MODIFY.

USE CLEAR *
USE
/cisfocrpt/data/invbal.foc NEW AS INV_BAL
END
CREATE FILE INV_BAL
-RUN
? FILE INV_BAL
-RUN

USE CLEAR *
USE
/cisfocrpt/data/invbal.foc AS INV_BAL
END
MODIFY FILE INV_BAL
. . .

This message has been edited. Last edited by: j.gross,

And if it is a file permission issue, try doing the chmod 777 for the focus file after having created it.

On Bob's behalf --

The problem isn't permissions and it isn't file space. Those are the first 2 things I checked.

What about the third issue? (See my previous post)

You folks are gonna LOVE this one. We finally got the program working. There were two issues, that when we finally fixed both of them, all was well.

1) There was an error in one of the fields of the master file. A P9 number does not fit in a D5 field and a lot of asterisks were appearing in the table created by the ON TABLE HOLD version.

2) Total field length of almost 1K and 450,000 records appears to be more that FOCUS could handle in this instance. We changed the INV_BAL table to XFOCUS, as well as the intermediate hold files used to create the final ALPHA table used by the modify.

My client had opened a case on this, and no one can explain why these two conditions were causing a FOC422 error.

This issues is SOLVED! :-)

It looks like you are working with a single-segment database, for the Inventory Balance database.

Just some food for thought, looking that the data you provided..

You might want to consider looking at creating a multiple segment database.

Something like:

 
	Segment 1 – Product - Segtype = S2
          ERP
	 ITEM_NUM
	Segment 2 – Data Year – Segtype = S1
	 FISCAL_YEAR
	Segment 3 – Monthly Data –Segtype = S1
	 MONTH_NUMBER
	 QUANTITY
	 ONHAND
	 UNITCOST  

quote:

1) There was an error in one of the fields of the master file. A P9 number does not fit in a D5 field and a lot of asterisks were appearing in the table created by the ON TABLE HOLD version.

2) Total field length of almost 1K and 450,000 records appears to be more that FOCUS could handle in this instance. We changed the INV_BAL table to XFOCUS, as well as the intermediate hold files used to create the final ALPHA table used by the modify.

Both issues (overflow and record length) could be alleviated by Holding the data in Binary (rather than Alpha) format, and using
FIXFORM FROM
in the MODIFY.

"Rolling your own" FIXFORM is something I avoid.

And I agree with David -- segment the database (whether or not you normalize with respect to months).