|
View previous topic :: View next topic
|
| Author |
Message |
RedDevil711
New User
.jpg)
Joined: 04 Jun 2010
Posts: 25
Location: Pune
|
|
|
|
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.
Thanks for the help |
|
| Back to top |
|
 |
steve-myers
Active Member
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. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
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. |
|
| Back to top |
|
|
RedDevil711
New User
Joined: 04 Jun 2010
Posts: 25
Location: Pune
|
|
|
|
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.  |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
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. |
|
| Back to top |
|
|
RedDevil711
New User
Joined: 04 Jun 2010
Posts: 25
Location: Pune
|
|
|
|
Hi Bill,
Here is the storage dump near the abend
| Code: |
Storage dump near condition, beginning at location: 171D96A0
+000000 171D96A0 C2F5F5F3 F3F0C240 5C5C5C5C C2F5F5F1 F0F14040 5C5C5C5C C2F5F4F1 F2F04040
!B55330B ****B55101 ****B54120 ! |
| Code: |
Parameters, Registers, and Variables for Active Routines:
CEEHDSP (DSA address 00090628):
UPSTACK DSA
Saved Registers:
GPR0..... 00090DD0 GPR1..... 00090A84 GPR2..... 00092268 GPR3..... 00090B14
GPR4..... 16F044D8 GPR5..... 0007E038 GPR6..... 16E3D410 GPR7..... 00090F20
GPR8..... 96F033CA GPR9..... 00092626 GPR10.... 00091627 GPR11.... 16EFF6B8
GPR12.... 00088B88 GPR13.... 00090628 GPR14.... 8007F0EA GPR15.... 96F2C9E8
GPREG STORAGE:
Storage around GPR0 (00090DD0)
-0020 00090DB0 170D6640 00000CB1 41C3C5C5 00000000 00030C87 59C3C5C5 !... .....CEE.......g.CEE.......Y!
+0000 00090DD0 C3969584 89A38996 95409799 968385A2 A2899587 409985A2 !Condition processing resulted in!
+0020 00090DF0 40A38885 40A49588 81958493 85844083 96958489 A3899695 ! the unhandled condition. !
Storage around GPR1 (00090A84)
-0020 00090A64 40404040 40404040 40404040 40404040 40404040 40404040 ! !
+0000 00090A84 00090DD0 00090E20 00092268 00092268 00090B10 00091030 !...........................8....!
+0020 00090AA4 00000000 00000000 000AF710 172C0938 00090F20 172EE860 !..........7...........Y-.0......!
Storage around GPR2 (00092268)
-0020 00092248 F6000000 00000008 F1F7F1F4 F2C3C6F6 00000009 4EF0F0F0
+0000 00092268 00000000 00000000 00000000 00000000 00000000 00000000
+0020 00092288 - +00003F 000922A7 same as above
Storage around GPR3 (00090B14)
-0020 00090AF4 0008E018 00000004 172ED038 0000D758 00089630 16E3D410
+0000 00090B14 00000000 00000003 00090C50 00000000 16F0336A 00000000
+0020 00090B34 00000000 0007E038 0008EDF8 0008EC18 172EE856 172C0938
Storage around GPR4 (16F044D8)
-0020 16F044B8 D4C41733 503020E8 5870D4E0 5030701C 98E1D220 9835D230
+0000 16F044D8 000030F8 000030F8 D200D5AD 8002D200 AEE92002 D200D5AD
|
Listing for the same from LIST :
| Code: |
020832 CALL
00F5FA 4100 76B0 LA 0,1712(0,7) I105-PA
00F5FE 5000 32A8 ST 0,680(0,3) TS2=0
00F602 58E0 9190 L 14,400(0,9) BLL=4
00F606 4100 E000 LA 0,0(0,14) Z003-PA
00F60A 5000 32AC ST 0,684(0,3) TS2=4
00F60E 9680 32AC OI 684(3),X'80' TS2=4
00F612 D207 32B0 5501 MVC 688(8,3),1281(5) TS2=8
00F618 58F0 C038 L 15,56(0,12) CBL=2
00F61C DC07 32B0 FFB9 TR 688(8,3),4025(15) TS2=8
00F622 D203 32B8 5984 MVC 696(4,3),2436(5) TS2=16
00F628 4100 32B0 LA 0,688(0,3) TS2=8
00F62C 4120 32A8 LA 2,680(0,3) TS2=0
00F630 5000 32BC ST 0,700(0,3) TS2=20
00F634 5020 32C0 ST 2,704(0,3) TS2=24
00F638 4110 32B8 LA 1,696(0,3) TS2=16
00F63C 182E LR 2,14
00F63E 5830 905C L 3,92(0,9) TGTFIXD
00F642 58F0 3100 L 15,256(0,3) V(IGZCF
00F646 05EF BALR 14,15
00F648 5810 9128 L 1,296(0,9) BL=1
00F64C 40F0 1008 STH 15,8(0,1) RETURN-
020833 IF
00F650 5800 20BA L 0,186(0,2) Z003-RE
00F654 4900 A498 CH 0,1176(0,10) PGMLIT
00F658 4780 B406 BC 8,1030(0,11) GN=438( |
|
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
| You should know by now to use code tags when posting data like this. I have 'coded' it for you. Do it yourself in future. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Code: |
| C2F5F5F3 F3F0C240 5C5C5C5C C2F5F5F1 F0F14040 5C5C5C5C C2F5F4F1 F2F04040 |
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 :-) |
|
| Back to top |
|
|
RedDevil711
New User
Joined: 04 Jun 2010
Posts: 25
Location: Pune
|
|
|
|
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 |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
