CEE3207S The system detected a data exception (System Completion Code=0C7).
From compile unit MODULE1 at entry point MODULE1 at compile unit
offset +0000F646 at entry offset +0000F646
at address 17142CF6
Now, when i see the compiler listing for this MODULE1 i can see the following assemble instruction
05EF BALR 14,15
Now when i see the main cobol command being issued, it has the following statement
CALL MODULE2 USING PARM
Has anyone faced such an issue before ?
Is it an abend caused when data in PARM may have invalid numeric data.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Most of the time the instruction where a failure occurs is the instruction immediately after the actual failed instruction. A BALR 14,15 instruction cannot, essentially by definition, get an S0C7. The only major exceptions are many S0C4 errors where the instruction that failed failed because of address issues detected by the paging hardware.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Language Environment is pointing at the offset of the actual failing instruction.
You have taken that offset, and located the generated assembler which matches the offset.
As Steve Myers has pointed out, it is impossible, totally impossible, for the instruction you show to have given a data-exception (S0C7). If you have a look at "Storage dump near condition, beginning at location:" you can see, and may get a big clue.
Two likelihoods: you are not looking at the correct listing for the program that is running; your program code has been overwritten by your program, or a program which CALLs it, or a program it CALLs, or something else which is CALLed.
Hi Bill and Steve,
Even my thinking is the same that the statement pointed by the generated offset cannot cause this issue.
I am looking at two points now.
One, the parm which is passed to the linked module, has corrupt data or second like steve said, there is an IF condition just after this call and it has a condition placed on a COMP field.
Problem at my firm no xpeditor, have to use display.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
No. LE is giving you the displacement of the instruction that failed, it is not giving you the PSW which contains the Next Sequential Instruction (NSI).
If you paste the "Storage dump near condition, beginning at location:" line we may spot something.
A COMP field will not cause a S0C7. Only a Zoned- or Packed-Decimal (COMP-3).
If you bounce a load of zeros over program code, an F0 is going to be interpreted as an instruction at some point and it is a "decimal" instruction, which can give you a S0C7. Other overwritten values can give S0C7 unexpectedly as well.
I repeat. You either have the wrong listing, or your executable code has been overwritten.
The problem with putting DISPLAY in is that sometimes this will cause the overwriting to be done somewhere else, and you may not get an abend at all. Then you take the DISPLAYs out, and it abends again :-)
You can have the same effect using a debugger if the debugging code is embedded in the code from your program.
You need to confirm you are executing the correct program for the listing you are looking at.
If you are, are you using SSRANGE in that program and all others in the run? If yes, then check the USINGs on CALLs and PROCEDURE DIVISION that you have the correct items in the correct order. Check also the lengths of data in the LINKAGE SECTIONs of the programs to the lengths of the data "passed".
You can sometimes short-circuit this by "what has changed recently" to get an idea where best to start.
If you can read a dump, produce a dump beyond what LE gives you. Everything you need to find out what has happened at that point is there. If it is overwriting, finding out when it happened can be more problematic.
But first, confirm that the executing program is the exact one that matches your listing you have used to track the offset provided by LE to an instruction in the generated pseudo-assembler from the COBOL program.
Definite Code-overwrite. Storage which has been stepped upon. Here is your executable code, in character format:
Code:
B55330B ****B5191 ****B541
Whatever that is (which you may recognize) it isn't program-code. There is plenty there to cause a "decimal" instruction to be executed.
So, compiler option SSRANGE can tell you (by causing an abend) if you go outside the bounds of a table. Check the CALL USING and PROCEDURE DIVISION USING as already suggested, order and length of the items.
A tip for knowing exactly what program is running, which compile output it was, is:
Code:
01 W-WHEN-COMPILED PIC X(8)BX(8).
...
First time into the program:
MOVE WHEN-COMPILED TO W-WHEN-COMPILED
DISPLAY
"[Your-program-name] compiled on "
W-WHEN-COMPILED
The output will exactly match the date/time on the compile listing. If feared that the program will still be running in the 22nd Century, use FUNCTION ( WHEN-COMPILED ) instead.
Edit: Just noticed I didn't need to do the translation :-)
Hi Bill,
Thanks a lot. Got the issue.
There was an array used at the end of the program which was out of bounds for a previous input record .
Can you please guide me to the books/links where i can learn analysing CEEDUMP like this, it will help me a bit, adding display's and debugging is quite a pain
.jpg)
.
