IBM Mainframe Forum

Hi,

I have one main COBOL program and some sub programs.
The program is abending in one of the sub programs with SOC4 abend while performing the move statement.

The input file is a multiple set of records, each record set with different type of records.

When we split up the record set (a record set is a set of type of records, the record which causing the abend is in this record set) which is causing the abend into another file and give these two piles in input DD, then program is running fine and also
after compilation of the program also the job is running fine with the same input file (without split up of the file).

Please suggest.

Thanks in advance.

The program is abending in prod environment and when we re compile it in test, the program is running fine.

I'll hazard a guess - but what compiler options did you use in test and Prod to compile the program?

You have a program bug.

The inability to re-create it outside of production does not mean it is not a bug. It means you haven't got everything the same. This includes all input to your program (including reference files and DBs) as well as the driving file, in the original order. As Anuj has pointed out, the compiler options you have can even be relevant. The "correct" options will not make the program work, but the "incorrect" options can make it fail, rather than mess up and carry on.

So, tell us more about the MOVE in question.

Hi,

Thanks for the help
Yes, you are correct. I am able to re-create the problem without SSRANGE compiler option. If SSRANGE=YES in compile, then not able to re-create the problem in test.
More info:

1. If a program is abending while processing a record (call it as REC30), I have ran the program again by removing the record (REC30=causing the abend initially) then it is abending in another record (REC28). So, it is not about a particular record.

The destination field has the occurs clause for 4 times.

Is this causing this abend?

Please post the relevant code, including data definitions. Can't say otherwise.

SSRANGE should not prevent an abend, it should abend itself if you access storage outside a Cobol table (occurs) with a subscript, index or reference-modification. It will provide information about the problem as well.

This would indicate that you still haven't recreated the situation in your test environment. Or, just possibly, you have managed to overwrite some code, and the inclusion of the SSRANGE code has made that overwriting in a less "vital" place or value. This is, however, unlikely. Don't bother looking into that until all more reasonable possibilities exhausted.

To try to recreate the problem, you need your compile options all the same as production.

Hi,

This is the situation in cobol programs.

One main program(MP) calls a sub porgram (SP).

In SP, the reading of file happens. The file is read into the A record. Based on the A-type field value the record gets moved to different destination records which are of same length as A-record.

The destination field is declared in the Linkage section.
Only Group move is happening in the sub program.
There is no computation of fields and subscription based storing or accessing .

gopal_NKP - your last response seems to be totally irrelevant compared with what you were requested to provide. If you do not provide the requested information then no one can help you and you might as well not bother asking for help.

I am able to re-create the problem without SSRANGE compiler option. If SSRANGE=YES in compile, then not able to re-create the problem in test.

This is a CLUE. If you understand what SSRANGE is doing, then you will have gone a long way towards understanding the source of the problem as well as how to resolve it.

So, show the data definitions in the calling program, of all items on the USING of the CALL. Show the CALL as well. Show the LINKAGE SECTION and PROCEDURE DIVISIONS USING of the called program, and the code doing the READ and any MOVEs.