offset +0000381E at entry offset +0000381E at address 15E03926.
When i search for '381E' in my compile program. it says search string not found.
My unserstanding was that, when a cobol program is compiled, it generates assembler code and it will have the offset address.
Am i doing something wrong? why am i not able to find '381E' in my compile job?
Cobol code rarely translates one-to-one, so there will typically be many assembler instructions from one line of Cobol code.
When you have the offset, you have to find the source line whose offset is closest but less than the offset you are looking for.
If you generate the pseudo-assembler in the compile listing you will get an exact hit for the offset of the assembler generated, and it is the previous Cobol statement that the code has been generated from.
Yes, it is the code to do with the WRITE that has failed.
Are you saying you used LIST and didn't get the pseudo-assembler, or just didn't get a match to the offset?
If you have your LIST output, compare the code to the code around the location of the offset from the dump. Check what is being written, is the file open, stuff like that.
If you have the LIST and the code doesn't match, or the OFFSET is in the middle of an instruction, then you either have a problem with overwriting (start by looking to see if SSRANGE compile option is set) or you are not running the program you are looking at the compile listing of.
Joined: 06 Jun 2008 Posts: 8280 Location: Dubuque, Iowa, USA
The OFFSET compiler option provides the offsets within the program for each COBOL verb. Since there may be multiple pseudo-assembler statements generated for each COBOL verb, as you have found the precise offset of an abend may be between the offsets of two COBOL verbs since it may occur on any pseudo-assembler instruction. The LIST compiler option will produce a pseudo-assembler listing of the entire program, so the exact offset of an abend can be located (in most cases); the cost is that the listing will be larger than if OFFSET is used.
Be careful when doing a re-compile. If you use a different option which affects the generated code (say, SSRANGE) the offset from the dump will no longer stand any chance of matching the listing, so the job will have to be run again to obtain the new dump with offset: which should then be in the listing.
Have a look here for a method to ensure you are looking at the same code from the run and the listing.