How to do dump analysis for S0C7 abend?

[ramanaefds]

Hi,

How to find out the record contains invalid data causes an soc7 abend from Registers ( saved registers in dump)?

For example input file contains 9 records, but due to some invalid data in one of the 9 records, the program got abend with SOC7. So how to find out the the record which is giving this S0C7 from dump.

My program is giving the SOC7 at offset 000003E6. I can find out the statment based on this offset from compile listing. The statment is
COMPUTE WS-SAL = WS-IN-SAL * 5
But I want to know for which record this problem is coming.

I am giving the dump also for your ref..


1CEE3DMP V1 R9.0: Condition processing resulted in the unhandled condition.

Information for enclave SOC7

Information for thread 8000000000000000

Traceback:
DSA Addr Program Unit PU Addr PU Offset Entry E Addr E Off
00053018 CEEHDSP 047D0718 +00002C2A CEEHDSP 047D0718 +00002
00028018 SOC7 00006AE0 +000003E6 SOC7 00006AE0 +00000

Condition Information for Active Routines
Condition Information for SOC7 (DSA address 00028018)
CIB Address: 00053630
Current Condition:
CEE3207S The system detected a data exception.
Location:
Program Unit: SOC7 Entry: SOC7 Statement: Offset: +000003E6

Machine State:
ILC..... 0006 Interruption Code..... 0007
PSW..... 078D1000 80006ECC
GPR0..... 000280C0 GPR1..... 0005291A GPR2..... 000197FC GPR3..... 0
GPR4..... 00007170 GPR5..... 80006F02 GPR6..... 00000000 GPR7..... 0
GPR8..... 00007360 GPR9..... 00006FC0 GPR10.... 00006BEC GPR11.... 0
GPR12.... 00006BDC GPR13.... 00028018 GPR14.... 5004B334 GPR15.... 8
torage dump near condition, beginning at location: 00006EB6
+000000 00006EB6 702C96F0 8014F234 D0988010 960FD09B FC30D098 A02EF353

ameters, Registers, and Variables for Active Routines:
EEHDSP (DSA address 00053018):
Saved Registers:
GPR0..... 047D3580 GPR1..... 000533F0 GPR2..... 00000001 GPR3..... 0
GPR4..... 00000008 GPR5..... 00053630 GPR6..... 0001D038 GPR7..... 0
GPR8..... 047D3715 GPR9..... 047D2716 GPR10.... 047D1717 GPR11.... 0
GPR12.... 00017920 GPR13.... 00053018 GPR14.... 8001E0E2 GPR15.... 8
PREG STORAGE:
GPREG STORAGE:
Storage around GPR0 (047D3580)
-0020 047D3560 00000000 047D35D0 047D358C 047D35D4 047D35C4 00000000
+0000 047D3580 00000003 00000004 00000006 00000007 00000008 00000009
+0020 047D35A0 0000000D 0000000E 00000010 00000015 00000017 00000020
Storage around GPR1 (000533F0)
-0020 000533D0 00000000 00000000 00000000 00000000 00000000 00000000
+0000 000533F0 000534DB 0005352B 00054448 00054448 00053874 0005373C
+0020 00053410 00000000 00000000 00000000 00000000 00000000 00053630
Storage around GPR2 (00000001)
-0001 00000000 Inaccessible storage.
+001F 00000020 Inaccessible storage.
+003F 00000040 Inaccessible storage.
Storage around GPR3 (00000003)
-0003 00000000 Inaccessible storage.
+001D 00000020 Inaccessible storage.
+003D 00000040 Inaccessible storage.
Storage around GPR4
(00000008)
-0008 00000000 Inaccessible storage. -0008 00000000 Inaccessible storage.
+0018 00000020 Inaccessible storage.
+0038 00000040 Inaccessible storage.
torage around GPR5 (00053630)
-0020 00053610 40404040 40404040 40404040 40404040 40404040 40404040
+0000 00053630 C3C9C240 00000000 00000000 010C0004 00000000 00000000
+0020 00053650 00000000 0005373C 00030C87 59C3C5C5 00000000 00000000
V1 R9.0: Condition processing resulted in the unhandled condition.

torage around GPR6 (0001D038)
-0020 0001D018 00000000 00023038 40404040 40404040 00000000 C3C5C540
+0000 0001D038 0001E038 80010528 0001E060 0001E074 847D0718 0001E09C
+0020 0001D058 0001E0D8 0001E0EC 0001E100 0001E114 0001E128 0001E13C
torage around GPR7 (00054017)
-0020 00053FF7 00000000 00000000 00000000 00000000 00000000 00000000
+0000 00054017 - +00005F 00054056 same as above
torage around GPR8 (047D3715)
-0020 047D36F5 D3D6C3D2 E240E2E3 D6D94040 40404040 40404040 E2E3D2E4
+0000 047D3715 C4C30000 00000000 00000000 00000000 00000000 00000000
Storage around GPR9 (047D2716)
-0020 047D26F6 58406050 504050DC D2035000 9FF74840 60544040 500C4840
+0000 047D2716 50B06058 D2035034 605C5840 60605040 50B45840 60645040
+0020 047D2736 D20B5028 6068D20B 50186074 58406080 504050C4 584060CC
Storage around GPR10(047D1717)
-0020 047D16F7 4E98FCD0 C407FE91 0A605F47 80BFFA45 E0A4BF41 30000150
+0000 047D1717 30000413 33194347 40A12B47 80A17541 30003C19 434720A1
+0020 047D1737 CA434480 42894000 0247F4A0 2D47F0A1 2B47F0A0 5547F0A1
Storage around GPR11(047D0718)
-0020 047D06F8 F1F0F1F6 F0F0F0F1 F0F9F0F0 0007E4D8 F2F0F5F6 F9000000
+0000 047D0718 47F0F014 00C3C5C5 00002270 000031D0 47F0F001 90ECD00C
+0020 047D0738 AFFF4180 9FFF5800 82335810 C2C81E01 5900C2C4 47D0B040
Storage around GPR12(00017920)
-0020 00017900 00000000 00000000 C3C5C5C3 C1C14040 00000000 00000000
+0000 00017920 00000800 00000000 00028000 00048000 00000000 00000000
+0020 00017940 00000000 00000000 00000000 00000000 00000000 00000000
Storage around GPR13(00053018)
-0020 00052FF8 00000000 00000000 E2E3D2D3 00056000 00026000 00002388
+0000 00053018 0808CEE1 00028018 000280C0 8001E0E2 847DB860 047D3580
Storage around GPR14(0001E0E2)
-0020 0001E0C2 92B850E0 D06C58F0 F0100CEF 58E0D06C 0B0E847D A1A850E0
+0000 0001E0E2 58E0D06C 0B0E847D B86050E0 D06C58F0 F0100CEF 58E0D06C
+0020 0001E102 D06C58F0 F0100CEF 58E0D06C 0B0E8481 E9A850E0 D06C58F0
Storage around GPR15(047DB860)
-0020 047DB840 F0F9F0F1 F1F0F2F3 F0F0F0F1 F0F9F0F0 0007E4D8 F2F0F5F6
+0000 047DB860 47F0F014 00C3C5C5 000004C8 00002E00 47F0F001 90ECD00C
+0020 047DB880 AFFF5800 9E625810 D04C1E01 5500C00C 47D0B03C 58F0C2BC
SOC7 (DSA address 00028018):
Saved Registers:
GPR0..... 000280C0 GPR1..... 0005291A GPR2..... 000197FC GPR3..... 0
GPR4..... 00007170 GPR5..... 80006F02 GPR6..... 00000000 GPR7..... 0
GPR8..... 00007360 GPR9..... 00006FC0 GPR10.... 00006BEC GPR11.... 0
GPR12.... 00006BDC GPR13.... 00028018 GPR14.... 5004B334 GPR15.... 8
GPREG STORAGE:
Storage around GPR0 (000280C0)
-0020 000280A0 07E001A8 00000000 00000000 00000000 00FFFFFF 00000000
+0000 000280C0 00001001 00053018 00028588 847DC760 047DE6C8 00000000
+0020 000280E0 00000000 000000FF 00000008 00000100 00054017 00028270

 

[slade]

Hi Raman,

It looks like a mainframe dump (I'm not familiar w/PCs). If it is you should recompile your pgm adding the following parm info in the compile step;

LIST,NOOFF

This will tell the compiler to list the assembler languge instructions generated by your cobol code, specifically, for the instruction that cauesed the 0c7.

These instructions will give you a clue as to where the abennd causing data resides. Then you can compare it to the 9 records in your file.

If you have trouble finding it, show us the generated code for the instruction that failed and any other info you're sure of.

BTW, the low tech approach may be easier and faster:

Display each record immediately after you read it. The last record displayed will be the record that caused the 0C7.

Regards, Jack.

 

[3gm]

If it were I, I'd turn on the compile options that will produce a formatted dump. Then you can see the input record that's in the buffer and all of working storage formatted quite nicely (I believe you want the TEST, SYM options turned on.)

In this case, however, your dump gives you enough information to perhaps resolve the problem. Get out your trusty green/yellow card (my reverse assembler skills are mighty rusty, so take this with a grain of salt):

The PSW ends in 6ECC. Look at the storage in that vicinity as shown in the dump:

00006EB8  96F0 8014       OI 20(R8),X'F0'
00006EBC  F234 D098 8010  PACK 152(3,R13),16(4,R8) Get field to multiply
00006EC2  960F D09B       OI 156(R13),X'0F'
00006EC6  FC30 D098 A02E  MP 152(3,R13),46(0,R10) Multiply failed!
00006ECC  F353            UNPK etc[\code]

R13 is the TGT, and you're doing a MULTIPLY of a field that was PACKed into the TGT work area from the location pointed to by R8.  So look at R8 and you should see the address/contents of your buffer or portion of working-storage:
[code]
D3D6C3D2 E240E2E3 D6D94040 40404040  40404040 E2E3D2E4 
L O C K  S   S T  O R                         S T K U
[\code]
You would appear to have "    S" in the WS-IN-SAL field. (I appear to be off a byte here; having the whole dump and the compile map would be of some help. :-))  Assuming your record is in working storage and the key or other unique identifying information is located near WS-IN-SAL, you should be able to tell which record caused your problems.

Good luck!

Glenn

 

[Lunker]

I would agree with Glenn.
Compiler option TEST(NONE,SYM) will produce a formatted dump that is relatively simple to read. It will show you the files and the current record in the buffer as well as all of Working-Storage.

 

[ramanaefds]

Hi,

I didn't compile my program with test(sym) option, If I put this I will get the exact record which is giving the SOC7. I tried this one. Suppose If I am not put this option, how to trace the record from dump, Glenn could you please explain in detail if possible because I am new to assembler language. Please help it regarding this.
Once again I am giving statment causing the soc7 based on the compile output.

000046 COMPUTE
0003FE F210 D098 8010 PACK 152(2,13),16(1,8) TS2=0
000404 960F D099 OI 153(13),X'0F' TS2=1
000408 FC10 D098 A031 MP 152(2,13),49(1,10) TS2=0
00040E F351 8008 D098 UNPK 8(6,8),152(2,13) WS-SAL
000414 96F0 800D OI 13(8),X'F0' WS-SAL+5

Could you please explain what is meant by TGT and how you find out the register R8 and after find out the register how to locate the invalid record.Glenn please explain in detail.

 

[3gm]

If I understand your post, you've solved your problem and get a formatted dump. You just would like more information to help educate you about reading dumps? This forum is probably not the place for a complete discourse on dump reading or assembler, but here's some further information. (The code you present in your followup post does not match the code in your original post. If you were bringing this dump to me and asking for help in person, I'd have you go back and give me both the dump and the matching compile. In this case, against my better judgement, we'll assume you've given us the right stuff.)

Also, you can't do this stuff without some documentation. I live and die by my green/yellow card "System/370 Reference Summary" GX20-1850. I don't know if it's available online or from IBM publications. It likely has been superceded, but someone in your shop should have one you can copy/borrow. Pay special attention to the machine instructions and the code tables. That will show you how to break apart, for instance, a MP instruction. It's an SS format instruction: MP D1(L1,B1),D2(L2,B2). D is displacement, L is length, and B is base register.

1. TGT - This is the Task Global Table. It is pointed to by R13 and contains lots of "good stuff". Check the COBOL Programming Guide manual for more information. For our purposes, it is sufficient to know that it contains, among a lot of other things, space for temporary workareas used for packing/unpacking data.

2. We start with the failing instruction which is the MP (Multiply Packed or Multiply Decimal). It is multiplying a 1 byte field 49 bytes from the address held in R10 (source) by the 2 byte field 152 bytes off of R13 (destination). Since the destination is offset from R13, the TGT, I would infer that the multiply is using a temporary work area in the TGT as its destination. The compile listing confirms that (note the name TS2 - Temporary Storage 2).

3. We should look at both the source and destination locations to see which field caused the data exception. R10 + 49 must be a valid, one-byte packed field. R13 + 152 must be a valid, two-byte packed field.

4. First, we examine the source. If R10+49 points to x'5C' (or perhaps X'5F') we know it is the constant "5" and the problem is with WS-IN-SAL. This is almost certainly the case. If it points to another valid packed 1 byte field, then R10 points to the workarea containing WS-IN-SAL and you can examine the storage in that vicinity for the record key etc. If the field is invalid, then either the CGT (constant global table) got clobbered, perhaps due to a subscript out of bounds, or WS-IN-SAL is non-numeric. To tell which, we need to examine the destination field of the MP.

5. To figure out the original source of the data in TS2, back up an instruction. You see the OI of x'0F' against this value's low-order byte. This is the compiler's attempt to make sure the packed number in TS2 is unsigned (positive). Back up another instruction and we see the PACK with TS2 as the destination. The source is 16 bytes off of R8 with a length of 1 byte. (Here's the main place your original code differs. In that code, WS-IN-SAL was 5 bytes; here it is only 1.) If you look at the storage around R8, you should see the storage around WS-IN-SAL and can, with luck, identify the record causing the problem. (It's not clear to me whether WS-IN-SAL is an independent data field loaded from the record or whether it is part of the record directly. If it is not part of the record, then R8 may be of no help to you at all. In that case you have to have the storage dump and chase through the FCBs (file control blocks); not much fun.

Learning to read dumps is as much art as it is science. It helps if you can get someone to show you the ropes (in person ) Also, practice helps. Once you've figured out a problem from a dump, do some further work. Decode some additional instructions. Examine your compile map and see the relationship of what's there to what's in the dump.

Glenn

 

[slade]

Hi ramanaefds,

Go to half.com and search for:

cobol application debugging under mvs by Alan Friend.

Even though it stops at cobolII, It'll teach you the fundamentals. There are others, but the idea is to get any one of them and get the basics. Well worth the $10-$15 cost.

Regards, Jack.