IBM Mainframe Forum

Hi All,
Need urgent help in resolving SOC4 Reason code 4.
Our program is such a way that it gets triggered from JCL ==> Prog A ==> Prog B. For the first 1 requests the call to Prog B is successful whereas in the 3rd request we get the SOC4 abend. This is happening in UAT region but when we test with the same file in the development region we're unable to recreate this scenario.
We had also checked the compiler options, AMODE, RMODE, Link edit options and everything looks the same as in development. Looking at the Dump it is saying that Prog B is impacted. For some reason, some of the information we couldn't check it in our Dumpmaster tool (might be some setting issue); unable to view the last instruction executed etc.

I've put some of the information from Dumpmaster.

It is exactly failing once it enters ProgB. We suspect the linkage section. We both use the same copybook and length is one and the same. Copybook as OCCURS 500 times inbetween which might be causing the problem. In ProgB it is having a group move of 01 level (is this a problem)? Since ProgB is not owned by us we need to give the exact reason to have it fixed.

Please help!!!

Thanks,
Durga R

Please let me know incase of any other information required. Know that definitely more info would be required. Incase of anything specific please let me know because I need to edit it accordingly and post it. Thanks.

We do not do "urgent." Some of the people that monitor this board - not me - are consultants that might take on this issue for payment of an appropriate fee.

As for information, you have not provided anything that is useful in diagnosing this problem.

Sorry.. After posting only I had the look at the rules.

I did attach a word document. Not sure whether I need special to attach them. I'm new to board.

$HASP375 IEPIP4S3 ESTIMATED LINES EXCEEDED
$HASP375 IEPIP4S3 ESTIMATE EXCEEDED BY 10,000 LINES
$HASP375 IEPIP4S3 ESTIMATE EXCEEDED BY 20,000 LINES
$HASP375 IEPIP4S3 ESTIMATE EXCEEDED BY 30,000 LINES
$HASP375 IEPIP4S3 ESTIMATE EXCEEDED BY 180,000 LINES
IEA995I SYMPTOM DUMP OUTPUT 692
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000004
TIME=23.49.02 SEQ=08149 CPU=0000 ASID=0095
PSW AT TIME OF ERROR 078D3000 960870C0 ILC 4 INTC 04
ACTIVE LOAD MODULE ADDRESS=16087000 OFFSET=000000C0
NAME=ProgB
DATA AT PSW 160870BA - 40404040 00000000 FFFFFFB2
AR/GR 0: 93B7258A/000816B0 1: 00000000/00081490
2: 00000000/13F03A34 3: 00000000/13FFC0B8
4: 00000000/000814A0 5: 00000000/00000000
6: 00000000/00089668 7: 00000000/00081490
8: 00000000/00089668 9: 00000000/13FF2038
A: 00000000/00089038 B: 00000000/93F7C400
C: 00000000/00078B88 D: 00000000/000814D0
E: 00000000/93F7C6C0 F: 00000000/96087000
END OF SYMPTOM DUMP

This summary has nothing to do with the stuff you PMed to me.

PSW AT TIME OF ERROR 078D3000 960870C0 ILC 4 INTC 04

This is possibly useful. The PSW address is 160870C0. The high order bit in 960870C0 means the program is running AMODE 31; it is not part of the address. The rest of the PSW does not have anything useful for this dump analysis. ILC 4 and INTC 4 tells me the error was detected as a storage key error rather than a page fault or segment fault detected by the virtual memory hardware.

DATA AT PSW 160870BA - 40404040 00000000 FFFFFFB2

The PSW points to the exact middle of the 4 words. ILC 4 means you subtract 4 bytes from the PSW address, so the failing instruction is 40400000. If my memory is correct, that's a store halfword of register 4 at location 0 in virtual storage, which is usually not allowed for most programs. In any event, the storage pattern indicates

• Your program has overlayed itself with junk, OR
• Your program has branched into a data area.

The contents of registers 14 and 15 suggest the second bullet seems more likely.

And that's enough for nuthin.

Hello,

Has anyone verified that the exact same load modules are being executed in both environments?

Steve, can you please enlighten on "•Your program has branched into a data area."? Sorry couldn't understand it..

We did a display of before calling ProgB which shows the data and length correct. Also tried displaying the occurs clause also which also had correct data.

What information needs to be exactly upon in the dump to get into details because I had checked the offset and couldn't trace much or might be doing something wrong somewhere?

Yes Dick. We regenerated both the modules in Endevor but still face problem in UAT region whereas in dev region we couldn't recreate it.

As you said we tried with the same load in development for which it goes fine. We also tried to retrieve the element from endevor to development, that also didn't work

Is there any possibility that endevor is behaving different?

What is the setting of option SSRANGE in your compiles?

IN both the environments it as SSRANGE. We checked all the compiler options and it looks the same. RMODE=ANY and AMODE=31 (in both env and both pgms).
Only difference in UAT was DASD SIZE (HEX) 00024000 (in Prog B) and DASD SIZE (HEX) 00015000 (prog A) in the Link edit MODULE ATTRIBUTES: that gets displayed below the MODULE MAP

Anything else we need to check in compiler options?