I have a mainframe FOCUS batch job that reads 31 concatenated flat files as input and outputs 1 output file, formatted as alpha.

I get several dozen format error messages:

(FOC1130) FORMAT CONVERSION ERROR FIELD/KEY  : PLAN

How do I determine which input rows cause these errors?

This message has been edited. Last edited by: Francis Mariani,

Interesting one....

I would try writing a record counter, and the field to a file.

Then check the file to see when the counter skips a beat.

May not work, just a theory.

I had thought of that too, but the &RECORDS and &LINES are the same so it looks like it's not dropping rows, but perhaps dropping values in rows.

I've seen this before. My memory is a little fuzzy on this but I seem to recall that on WinNT 7.68 it displayed the rejected records in TRMOUT. What was even more annoying is that &FOCERRNUM was 0 unless the error occurred on the last row.

I think you'll have to use divide and conquer to find the rogue data.

EricH

Thanks Eric.

My original post simplified the actual situation. I have 31 concatenated files as input so, to find the needle in the haystack I thought I would allocate one file at a time and run the job 31 times. Well, they all ran without format errors!

Then I started with two concatenated files, ran the job, added another, ran the job, and so on. I finally figured out a combination of two files gives me three format errors - but there are about two million rows...

I'm thinking of giving up.

I wonder if the field has MISSING=ON, whether it will be populated with a missing value ?

If not already the case, and if possible, I would convert all numeric data elements to alpha format.

I had something similar happen recently, we have a WebFocus program that builds a file that is used in AIX FOCUS. A tab was entered into one of the data fields. Passed through the WebFocus program without any problems, but when it hit the AIX FOCUS it rejected because all of the fields after were in the wrong position.

Any differences in the DCB (record length, block size, record format,..) between the files?

you can write the rejected records to an other database

You might check for a blank row (extra return) at the end of each file

I assume that this describes the problem.

EX -LINES 6 EDAPUT MASTER,TST_DATA,CV,FILE
FILENAME=TST_DATA, SUFFIX=FIX,$
SEGNAME=TST_DATA, $
  FIELD=KEY      ,ALIAS=  ,A10  ,A10 ,$
  FIELD=VALUE    ,ALIAS=  ,P10.2,A10 ,$
  FIELD=TEST_TYPE,ALIAS=  ,A30  ,A30 ,$

-RUN

EX -LINES 7 EDAPUT FOCTEMP,TST_DATA,CV,FILE
TEST 1        100.01VALID
TEST 2     999999.99VALID
TEST 3     MISTAKE 1Text instead of numeric
TEST 4          0.99VALID
TEST 5      12345,20Comma in numeric
TEST 6      -8888.77VALID

-RUN

FILEDEF TST_DATA DISK tst_data.ftm (LRECL 50 RECFM V

-RUN

TABLE   FILE TST_DATA
 PRINT  TEST_TYPE
        VALUE
 BY     KEY
 ON     TABLE HOLD AS TST_HOLD FORMAT ALPHA
END

-RUN

! type tst_hold.ftm

And it seems to indicate that the records are not held.

To determine the records with the format errors, I would create a second master that is alpha only, (you only need the keys) and compare the two results.

If the format errors are not on the keys then it should pinpoint the offending records.

I may be totally off the mark here, but ...
Could it be that by using 31 concatenated files and adding the records, you end up overflowing one of the summed fields (PLAN in this case), producing *** in the output file?
If that might be the case, then increasing the format (not the actual) of the field PLAN on the input side might solve the problem.

GamP!

Some of the fields do indeed have asterisks denoting data overflow - these are most likely causing the data format errors.

Thanks very much,

Francis.


------------------------------------------------------------------------------------------

The program inputs and outputs the same number of records.

All the input files have the same DCB.

After concatenating all the input files to one HOLD FORMAT ALPHA file, an alternate Master with an occurs is used. This is where the format errors happen.