IBM Mainframe Forum

There is a job that runs everyday, it frequently abends with S0C4.
The fix that we do is restart the job from TOP after sometime.

The job executes ASM modules. The error message in the output log always shows this message:

.IEC999I IFG0TC0A,IFG0TC0B,PREMJ ,X ,DEB ADDR = 87408C,DSN = PRODDS1.IA7152
.IEF472I PREMJ X STEP03 - COMPLETION CODE - SYSTEM=0C4 USER=0000 REASON=00000011

The ABEND Code IEC999I occurs when a SINGLE OPEN is used to open multiple files.
The logic in the ASM cannot be changed because, the files are of different LRECLS.

Googling this error, advises to close the DCB. The CLOSE is however used in the ASM program.

The S0C4 abend is many a times due to storage allocation, the JCL does not have a REGION parm coded.

Please advise. Here is the JCL snippet and the Error Log :

JCL

//PREMJ JOB (5A01,5A01),PROD,CLASS=E,MSGCLASS=J,
// USER=PREMJ
//STEP01 EXEC LINK,C='PRODPLS.PI500000',
// C2='PRODPLS.ADTKPROD.LOAD',
// CC=9,
// LOAD='PEA.TEMP.LOAD'
//LNK.SYSIN DD *
ENTRY LI5A01AD
INCLUDE C(LI5A01AD)
INCLUDE C(LI5A0100)
INCLUDE C(LI5A01AC)
INCLUDE C2(CCARTABL)
NAME LI5A010X(R)
/*
//STEP03 EXEC PROCF4,SOURCE=LI5A0100,L='*',S='PEA.TEMP.LOAD',
// M=LI5A010X
//STEPLIB DD DSN=PEA.TEMP.LOAD,DISP=SHR
// DD DSN=SYS3.UNI.C31.LOADLIB,DISP=SHR
//* INPUTS TO PREMIUM REGISTRATION
//*-------A.IA7132 = ENTRI MISCELLANEOUS TRANSACTIONS
//X.FILEA DD DSN=A.IA7132(+0),DISP=SHR,LABEL=(,SL)
//*------- CONCATENATED DATASET
// DD DSN=PRODDS1.IA7152,DISP=SHR
//X.FILE1 DD DSN=A.EA0102(+1),DISP=(,CATLG,DELETE),
//* UNIT=CAR,LABEL=EXPDT=99000,VOL=(,,,99),
// UNIT=PRODLG,SPACE=(CYL,(5,5),RLSE),LABEL=EXPDT=99000,
// DCB=(SYS1.MODDSCB,RECFM=FB,LRECL=501,BLKSIZE=23046)
//*
//* TMF DD CARDS ARE CONTAINED IN A 'INCLUDE'. THIS IS DONE SO
//* CCYVCLT DATASETS
//* INCLUDE MEMBERS ARE IN SYS1.PROD.PROCLIB
//* TMFA00=TESTCICS.A00VS... = SYSTEM TEST DD'S
//* TMFP00=PRODCICS.P00VS... = PRODUCTION DD'S
//*
//*
// INCLUDE MEMBER=TMFP00
//*
//UNIUF DD DSN=SYS3.UNI.UNIUF,DISP=SHR
//UNICF DD DSN=SYS3.UNI.UNICF,DISP=SHR
//UNIDF DD DSN=SYS3.UNI.UNIDF,DISP=SHR
//UNIHF DD DSN=SYS3.UNI.UNIHF,DISP=SHR
//UNIACR DD SYSOUT=O,DEST=R49,
// DCB=(RECFM=FBA,LRECL=133,BLKSIZE=133)
//UNIRCR DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=80,BLKSIZE=080)
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
/*


ERROR LOG:

.19.31.06 JOB02896 IEA995I SYMPTOM DUMP OUTPUT 555
. 555 SYSTEM COMPLETION CODE=0C4 REASON CODE=00000011
. 555 TIME=19.30.58 SEQ=03859 CPU=0000 ASID=004D
. 555 PSW AT TIME OF ERROR 078D2000 896FD0D4 ILC 4 INTC 11
. 555 NO ACTIVE MODULE FOUND
. 555 NAME=UNKNOWN
. 555 DATA AT PSW 096FD0CE - D00C58A1 000058CA 001018BF
. 555 GR 0: 00000010 1: 00006330
. 555 2: 166063B8 3: 00000000
. 555 4: 00000000 5: 00000000
. 555 6: 00000000 7: 00000000
. 555 8: 00000000 9: 00000000
. 555 A: 166063B8 B: 00000000
. 555 C: 00000000 D: 000069D0
. 555 E: 80FCB3E8 F: 896FD0B0
. 555 END OF SYMPTOM DUMP
.19.31.06 JOB02896 IEC999I IFG0TC0A,IFG0TC0B,PREMJ ,X ,87408C,DSN = PRODDS1.IA7152
.19.31.06 JOB02896 IEF450I PREMJ X STEP03 - ABEND=S0C4 U0000 REASON=00000011 557
. 557 TIME=19.31.06
.19.31.07 JOB02896 U11-656 JOBNAME=PREMJ ,STPROC=STEP03 ,STSTEP=X ,AUTO SETUP PARMS
.19.31.07 JOB02896 ACS001I PREMJ 12 X LI5A010X ----- S0C4
.19.31.07 JOB02896 ACS001I PREMJ 13 STEP04 SORT ----- NXEQ
.19.31.07 JOB02896 ACS001I PREMJ 14 SM HDR ----- NXEQ
.19.31.07 JOB02896 ACS001I PREMJ 15 LNK LINKEDIT ----- NXEQ
.19.31.07 JOB02896 ACS001I PREMJ 16 LNKHIST IKJEFT01 ----- NXEQ
.19.31.07 JOB02896 ACS001I PREMJ 17 MSGCAN1 RGWTMSG ----- NXEQ
.19.31.07 JOB02896 ACS001I PREMJ 18 MSGCAN2 RGWTMSG ----- NXEQ
.19.31.07 JOB02896 ACS001I PREMJ 19 X DFSRRC00 ----- NXEQ
.19.31.07 JOB02896 +PREMJ Q JOB ABENDED - DBRC BEING INVOKED TO DETERMINE IF BACKOUT IS REQUIRED
.19.31.08 JOB02896 ACS001I PREMJ 20 DLIBKOUT IKJEFT01 ----- R0000
.19.31.08 JOB02896 ACS001I PREMJ 21 B DFSRRC00 ----- NXEQ
.19.31.08 JOB02896 ACS001I PREMJ 22 MSGOK RGWTMSG ----- NXEQ
.19.31.08 JOB02896 ACS001I PREMJ 23 MSGNG RGWTMSG ----- NXEQ
.19.31.08 JOB02896 +PREMJ Q PRODUCTION DB UPDATE FAILED, BUT, NEITHER BACKOUT NOR RESTORE REQUIRED
.19.31.08 JOB02896 ACS001I PREMJ 24 MSGNOBK RGWTMSG ----- R0000
.19.31.08 JOB02896 ACS001I PREMJ 25 WHOKNOWS RGWTMSG ----- NXEQ
.19.31.08 JOB02896 ACS001I PREMJ 26 MSGBKOUT RGWTMSG ----- NXEQ

Any help will be highly appreciated.

Thanks
Jai
Charlotte, NC

Hello,

The logic in the ASM cannot be changed because, the files are of different LRECLS.

What does the lrecl have to do with being able to modify the code?

If rerunning the job from the beginning "solves" the abend, it may be due to something not initialized properly or some problem with a linkedit.

What do the first 11 steps do?

Thanks for your response.

Googling the IEC999I code, it can be inferred that a Single open used for multiple files is causing the failure.
Concatenation of the datasets will not resolve as the program has logic based on LRECL of the i/p DSN. I should have put it this way rather than saying "The logic in the ASM cannot be changed because, the files are of different LRECLS."

The first step is a LINK step and there is no 11 steps.

Dick,

I also found reference to an earlier post from the archive: It is the exact same issue that I have currently:

The job will fail with S0C4 and runs fine when restarted from top after sometime.

http://ibmmainframes.com/archive/o_t__t ... ata31.html

Did you know if this issue was fixed ?

Thanks a lot in advance for your help.

Hello,

Did you know if this issue was fixed ?

The poster never replied. . .

The first step is a LINK step and there is no 11 steps.

The first "step" executes a PROC as does"step03". Sorry 'bout the 11 - my keyboard got carried away.

What does procedure LINK do? What does procedure PROCF4 do?

As i mentioned earlier, there may be a problem with the link edit.

If this is a normal production job, why does there need to be a re-link every run?

Dick,

Every time the job runs, it executes the COBOL program - CI5A01AD (Loadname - LI5A01AD in the LINK step)
This program calls the ASM module - SI5A0100 (Loadname - LI5A0100 in LINK step).
LINK and PROCF4 are home grown procs that are used for linking and execution of programs respectively.

If there is issue with LINK, willnot fai levery time ? This is a sporadic issue. The job is a daily job and it fails 5 on every 10 runs. The fix is restarting the job from top and I am breaking my head to fix this issue
the dead line to fix it is 2 weeks from now !!!

I was googling on S0C4 abend reason code. Will coding REGION=0M resolve the storage issue ? The SoC4 could be due to storage not being available, yout thoughts ???

Thanks,
Jai
Charlotte, NC

Hello,

Will coding REGION=0M resolve the storage issue ?

Possibly, though not usually (unless your job runs in multiple initiators, some of which will not support your job).

To repeat: "If this is a normal production job, why does there need to be a re-link every run?"What can be gained/supported by beginning the job with a linkedit every run? This is not normal. . . It is very possible that the failed executions have a problem in the link. I'd suggest very thoroughly reviewing the output from the linkedit of one of the failed runs.

If the linkedit has problems and the program is executed anyway, an 0c4 is often/usually the result.

Dick,

that is how most of the JCLS are coded in the PRPD environment here. The batch cycle consists of jcls/ trigger structures and most of the JCLs have the LINK and EXECUTE steps if calls are involved.
If the failure is due to LINK why is it that the job always fails in the STEP03 and not the prior step (LINK step).
Also, the job always has this message:

.IEC999I IFG0TC0A,IFG0TC0B,PREMJ ,X ,DEB ADDR = 87408C,DSN = PRODDS1.IA7152
.IEF472I PREMJ X STEP03 - COMPLETION CODE - SYSTEM=0C4 USER=0000 REASON=00000011

pointing to the dataset PRODDS1.IA7152.

Hello,

If the failure is due to LINK why is it that the job always fails in the STEP03 and not the prior step (LINK step).

Because the link may create an invalid executable module. When it is executed after the problem link, an abend occurs. The 0c4 is quite common because of some unresolved/invalid address and when the code tries to "go there" or "move to/from there", the abend is raised.

It almost sounds like the designers did not understand dynamic calls and so, they re-link for every execution to make sure they have the current verson of called modules - a very bad way to implement. . . .

Hello,

Please do not post in both forums. . . The post in the "other" forum has been removed.

Thank you,

d