IBM Mainframe Forum

[color=#000000][color=#4040BF]Hello Guys !!!

I have a problem while using INTRDR. I am running the job step given below

//INTRDRS1 EXEC PGM=IEBGENER
//SYSUT1 DD DISP=SHR,DSN=PFM.PFMXX.CANADA.SUBJOB9
//SYSUT2 DD SYSOUT=(,INTRDR)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY

PFM.PFMXX.CANADA.SUBJOB9 Contains a simple sort step given below
//PFMXX471 JOB ('3000-000000-07-M-00000000000'),
// 'S01529645-090611-0-S',CLASS=Q,MSGCLASS=H,
// NOTIFY=PFMXX
/*JOBPARM R=1403,S=ANY,P=PROC02
/*ROUTE PRINT CBIC
/*RCSROUTE DEST=CBIC
/*JBS BIND SYS.CV12
// JCLLIB ORDER=(LSE.PROCLIB)
//STEP1 EXEC PGM=SORT
//SORTIN DD DISP=SHR,DSN=PFM.XTAP.C6249.V1204A
//SORTOUT DD DSN=PFM.XTAP.C6249.V1299A,
// DCB=(LRECL=400,BLKSIZE=0,RECFM=FB),DISP=(,CATLG,DELETE),
// SPACE=(CYL,(30,150),RLSE)
//SYSOUT DD SYSOUT=*
//SYSPRINT DD *
//SYSIN DD *
SORT FIELDS=COPY
INCLUDE COND=(21,9,CH,NE,C'000000000')
//*

This sort step is abending with return code S0C4. Contents of JESYSMSG on JES2 is

IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000011
TIME=12.41.03 SEQ=26654 CPU=0000 ASID=0136
PSW AT TIME OF ERROR 078D0000 000165AA ILC 4 INTC 11
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 000165A4 - 4160300C 06404440 BCF64160
AR/GR 0: 9481058E/00012569 1: 94810300/00041FD0
2: 00000000/00000008 3: 00000000/00041F60
4: 00000000/0000004F 5: 00000000/00041FD0
6: 00000000/00041F6C 7: 00000000/00021EC4
8: 00000000/00041FD0 9: 00000000/00012708
A: 00000000/00012738 B: 00000000/00016168
C: 00000000/0000E000 D: 00000000/0000E000
E: 00000000/0001622C F: 00000000/0000E000
END OF SYMPTOM DUMP
IEF472I PFMXX471 STEP1 - COMPLETION CODE - SYSTEM=0C4 USER=0000 REASON=00000011

When I submitted this abended job manually it ran successfully.

Do you know the reason why the same job is giving s0c4 when triggered using INTRDR

[/color][/color]

Can you post the Sysout from the sort step as well, please.

After some thought, I would add ,DCB=(RECFM=F,LRECL=80,BLKSIZE=80) to the SYSUT2 DD statement.

Hello,

I'd also add the proper sysout class for the internal reader to the (,INTRDR) ?

dick scherrer wrote:Hello,

I'd also add the proper sysout class for the internal reader to the (,INTRDR) ?

I agree, though I don't think this had anything to do with the IEBGENER ABEND. The JCL Reference manual is unclear about what happens when an output class is not specified, though it explicitly states SYSOUT=(,) or SYSOUT=(,INTRDR) is allowed.

Hi Steve,

Thanks for "waking me up". . . I went back and re-read the initial post.

I agree, i don't know how the class might cause a subsequent 0c4, but several places i've been, the output doesn't go to the internal reader if not correctly specified. The problems i recall were in the step that "wrote" to the internal reader, not the submitted job. This depended (iirc) on how the system had been customized and possibly the operating system release/level.

The abend is coming from the sort step rather than the iebgner.

Might be interesting to see the informational/diagnostic messages produced by the problem run.

Well, I, too, went back to the original post. The TS did say "sort step," though the topic reads "triggering a job using INTRDR." The code in the DATA AT PSW section of the indicative dump reads as -

LA 6,12(,3) (though it could also be the last 4 bytes of an SS instruction)
BCTR 4,0
EX 4,X'CF6'(,11)
LA 6,??? (the last 2 bytes are missing)

The failing instruction is the EX. The contents of reg 4, X'4F' (79), or a length value 80, fits IEBGENER moving data from SYSUT1 to SYSUT2 using an MVC instruction executed by the EX instruction. Granted, this would also fit sort copying data from SYSIN, but I think that's less likely.

You and I both know how unreliable our topic starters are doing problem determination, so I just used the topic title rather than the "sort step" in the topic, and took the whole thing to mean an S0C4 submitting the sort job through the internal reader using IEBGENER.

IEF472I PFMXX471 STEP1 - COMPLETION CODE - SYSTEM=0C4 USER=0000 REASON=00000011

The stepname is the same as that of the sort step in the JCL shown. I suspect the corrective actions already suggested will make the problem go away.

I copied the gener step and the sort job and ran them no problem. The only changes made were:

1 - dataset names to use my names
2 - removed all the unnecesary stuff (from my systems point of view)

Select all
//PFMXX471 JOB ('3000-000000-07-M-00000000000'),
// 'S01529645-090611-0-S',CLASS=Q,MSGCLASS=H,
// NOTIFY=PFMXX
/*JOBPARM R=1403,S=ANY,P=PROC02
/*ROUTE PRINT CBIC
/*RCSROUTE DEST=CBIC
/*JBS BIND SYS.CV12
// JCLLIB ORDER=(LSE.PROCLIB)

So something does not add up. Because the JCL quoted is not in code tags we cannot tell, for sure, that it is pukka.

Funny, I did the same. Same results. I noticed the IEBGENER message about "something" being copied form input DCB to output.

If the IEBGENER is replaced by a SORT step to do the copy, you'd see all the dataset information and number of records.