MVSFORUMS.com

[pdwheaton]

My task is to upgrade an OS/VS COBOL program to Release 6.2 of enterprise COBOL. I converted all the obsolete language syntax, and received an error-free program compilation. So, my subtask is to do a parallel run of the revised program and compare to production. It's a report program that processes an input file and creates an employee roster highlighting employee benefit options that have been selected.

It processes the first 4999 employee records, then upon the 5000th READ executed abends with an 0C4 abend, reason code 4, protection exception. The input file is FB, LRECL=7000, and BLKSIZE=28000, stored on DASD.

I created a subset of the file, omitting the first 4999 records, and re-tested. Once again, the first 4999 records were processed, but the program goes down on the 5000th logical record (for a different employee) with an 0C4 abend.

I put in DISPLAY statements to identify the program flow and the input record being processed. In both cases, the 0C4 points to the READ statement, and the name displayed corresponds to the 4999th record on the input file, just prior to the abend. The first extent of these files contains record 4999 and record 5000.

The program uses the record layout in the File Section (originally this program was written in 1969) instead of a record description in Working Storage. Based on these test results, I don't believe that the data on the records is the cause of the 0C4, but that something is clobbering addressability to the buffer for the input file.

After the second abend, I changed the default region size to REGION=0M but it did not change the results.

This program is "spaghetti code' with an assortment of PERFORM formats, fall-through code, GO statements, a DECLARATIVE / USE Section if there is an i/o error on the input file (not raised). There are small tables and subscripts in the program. but the subscripts seem to be well-controlled--not exceeding limits based on PICTURE clauses. I will say that I would never code subscripts in display format (as this program does).

Based on the above, my first thought is to change the READ to be a READ INTO then use a Working Storage layout for all references to the data. My next thought is to gather all the subscripts to a common format and add a DISPLAY statement for each of them just prior to the READ...INTO, say, if the input-record-ctr is over 4995. My third thought would be to untangle the spaghetti code in case there is the potential for recursive code being generated by the newer compiler.

Thoughts? Suggestions?

I have been programming using COBOL for around 40 years and this is the first time I have seen a READ statement cause an 0C4 abend on a particular input record count.

Thanks in advance.

[kolusu]

pdwheaton,

Are there any internal tables defined that might be defined as < 5000 ? May be it is causing Out of bounds error and this resulted in a S0C4. What is the SSRANGE option you have?
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

www.linkedin.com/in/kolusu

[pdwheaton]

[kolusu]

pdwheaton,

A READ should never result in S0c4 abend especially reading Fixed length records. Can you check the FD definition has "BLOCK CONTAINS 0 RECORDS" clause? and the DATA RECORD matches 7000 bytes?

Can you compile with NOSSRANGE and try to run the same program and do you still get an abend?
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

www.linkedin.com/in/kolusu

[pdwheaton]

[kolusu]

pdwheaton,

Was the input on a tape? If So can you copy the first 10,000 records to a DASD dataset and then see if it still abends after 5000th record?
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

www.linkedin.com/in/kolusu

[pdwheaton]

Thanks. The input years ago was on tape, but has been on DASD for at least a decade.

I have discovered the source of this problem but I do not have an explanation as to why it is happening.

There was a RERUN statement under I-O CONTROL to take a checkpoint every 5000 input file records. Don't know why, but it is that way. Commented it out, and the program runs to completion with the COND CODE=0000. In the JCL, the ddname of the checkpoint file was DD DUMMY, so it wasn't actually being used.

[kolusu]

pdwheaton,

You may want to check if your shop has these APARs

https://www.ibm.com/support/pages/apar/PH18138

https://www.ibm.com/support/pages/apar/PI76988
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

www.linkedin.com/in/kolusu