IBM Mainframe Forum

I am getting "A010 INVALID FILE REFERENCE" error in the below code



This is some old code in production which fails with "A010 INVALID FILE REFERENCE - FILE1" when one of the files has just 1 record and the other has more than 1 records. For all other cases it works just fine.

Recrods in FILE1 Records in FILE2 JOB STATUS
0 0 SUCCESS
0 1 SUCCESS
0 M (Many) SUCCESS
1 0 SUCCESS
1 1 SUCCESS
1 M (Many) FAILS
M 0 SUCCESS
M 1 FAILS
M M (Many) SUCCESS

The program fails in the below highlighted statement. This is done so that there is atleast 1 record in the output file as the downstream is not designed to handle an empty file.

IF RECORD-COUNT(FILE1) = 1
WS-STORE-HEADER = FILE1-REC
END-IF

I think it has something to do with the way the synchronised file read happens in easytrieve.

Also, if there are 2 records in one of the file and more than 2 in the other the below code fails with the same error.

IF RECORD-COUNT(FILE1) = 2
WS-STORE-HEADER = FILE1-REC
END-IF

I have a solution in place but I just want to know why it is failing.

Hello,

If the code references a field in a record that was NOT read (i.e. after eof), the reference is invalid.

When you have the file-matching logic:

File 1 low key, file 1 available, file 2 not
File 2 low key, file 1 not, file 2 available
Keys match, file 1 available, file 2 available

It is for this reason that you test for the files being available before accessing any fields defined for a record on the file. If you don't test, then you'll get the Invalid File Reference if the record is not there.

With your code, RECORD-COUNT ( FILE1 ) is equal to one on more than one occasion as you go through the JOB. It is one for the first record on the file and, if there are no more records on that file, it stays one. If there are more records but FILE2 has a lower key, again the record-count is one, and again you'll get the A010.



Will only ever be true once - or never be true. With an empty FILE1 you'll not get your field set anyway as the record-count for that file will never reach one.

I hope you don't mind, Jiten, but I read your post again today.

The downstream job might not like an empty file, but what does it do with a record picked at random?

You are showing some sort of results from testing. I hope this is only a part of your testing. For the file-matching logic, the number of records on the files is not a particularly high priority. The keys are the most important thing, and you must test (both ways) at the limits. For instance, if the key on file1 is the highest key, and there is only one record, you will not get the A010. Do you have duplicate keys on either file? If not, test with duplicates anyway so that you know what the situation looks like. If yes, maybe post back here what duplicates can exist.

You have a GO TO JOB in the code, just before the first PROC. This is at the point Easytrieve+ will automatically GO TO JOB, so your's is not needed and will make people think something is odd.

Once you have identified MATCHED, you check for presence on FILE1 and do stuff, then check on FILE2 and do stuff. Again to save confusion, do this as an ELSE.

You can do PUT x FROM y.

You are counting, but don't do anything much with the counts. What you do, is test them in the FINISH proc. However, why don't you test the record-count on the output file? If you have the counts, display them for information.

You are using "=" in your IFs and in your assignments. I think clearer if you use EQ/NE etc in the IFs and "=" in the assignments.