Cool new JCL error!



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

Cool new JCL error!

Postby socker_dad » Mon Apr 19, 2021 10:37 pm

We've been running this job for many years with this output designation and never had a problem:


//PS0010  EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=XXXXXXXX.P.FTPDCB.DATA(0),DISP=SHR
//SYSUT2   DD DSN=XXXXXXXX.P.TAPE.DATASET.DATA(+1),
//                DISP=(,CATLG,DELETE),UNIT=CART,
//                LABEL=(01,SL,,,EX{DT=990000),
//                DATACLAS=GDG,RECFM=FB
 


This is a generic procedure that is used to extract about 75 files from the same SYSUT1 file.

After years of executing beautifully, it gave the following error last night:

S013,20
An OPEN macro instruction was issued for a sequential data set using
queued access. BLKSIZE is not a multiple of LRECL, or LRECL is 0 with
RECFM=FB or RECFM=FBS, or BLKSIZE is not at least four bytes greater than
LRECL with RECFM=V.
 

The only thing I could do to get the job to run was to create a duplicate JCL with each file as its own step (tedious, to day the least) and add an "LRECL=" to each and every step. Of course, every extracted file has its own length. And even then, I had to add the BLKSIZE parameter to the last file to get it to extract.

Why would this suddenly change? Do I need to change the JCL so that each and every extraction file has all this information specified?
socker_dad
 
Posts: 9
Joined: Tue Sep 22, 2020 5:37 am
Has thanked: 0 time
Been thanked: 0 time

Re: Cool new JCL error!

Postby willy jensen » Tue Apr 20, 2021 12:37 am

Could the job creating XXXXXXXX.P.FTPDCB.DATA(0) have failed, leaving a bad dataset?
willy jensen
 
Posts: 336
Joined: Thu Mar 10, 2016 5:03 pm
Has thanked: 0 time
Been thanked: 44 times

Re: Cool new JCL error!

Postby steve-myers » Tue Apr 20, 2021 2:09 am

socker_dad wrote:We've been running this job for many years with this output designation and never had a problem:


//PS0010  EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=XXXXXXXX.P.FTPDCB.DATA(0),DISP=SHR
//SYSUT2   DD DSN=XXXXXXXX.P.TAPE.DATASET.DATA(+1),
//                DISP=(,CATLG,DELETE),UNIT=CART,
//                LABEL=(01,SL,,,EX{DT=990000),
//                DATACLAS=GDG,RECFM=FB
 


This is a generic procedure that is used to extract about 75 files from the same SYSUT1 file.

After years of executing beautifully, it gave the following error last night:

S013,20
An OPEN macro instruction was issued for a sequential data set using
queued access. BLKSIZE is not a multiple of LRECL, or LRECL is 0 with
RECFM=FB or RECFM=FBS, or BLKSIZE is not at least four bytes greater thanthe SYS
LRECL with RECFM=V.
 

The only thing I could do to get the job to run was to create a duplicate JCL with each file as its own step (tedious, to day the least) and add an "LRECL=" to each and every step. Of course, every extracted file has its own length. And even then, I had to add the BLKSIZE parameter to the last file to get it to extract.

Why would this suddenly change? Do I need to change the JCL so that each and every extraction file has all this information specified?

First, this not a JCL error.

Second, Mr. Jenson is correct, something went wrong in the task that created the data set specified by the SYSUT1 DD statement. Correct this problem.
steve-myers
Global moderator
 
Posts: 2087
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 235 times

Re: Cool new JCL error!

Postby socker_dad » Tue Apr 20, 2021 2:42 am

I wish the source dataset had become corrupted, then I would have a reasonable explanation.

I created a test copy of the production job, used the same input, but took the procedure and expanded it into the 67 steps for the extraction files, added the full DCB to each of the SYSUT2 datasets, and it ran perfectly.

Is it possible that there is some sort of system setting that would explain this change? I mean, I went back to 2018 and this has never occurred.

I opened a support ticket with our mainframe support group and I am waiting on a reply. If they get back to me, I'll post their explanation here (if they have one).
socker_dad
 
Posts: 9
Joined: Tue Sep 22, 2020 5:37 am
Has thanked: 0 time
Been thanked: 0 time

Re: Cool new JCL error!

Postby willy jensen » Tue Apr 20, 2021 1:26 pm

Two possible reasons, a change in the SMS definitions or a change in the program that creates the input dataset. Have you looked at the format of the input dataset?
Looking at your JCL, why do you have RECFM=FB in the first place and not just leaving it to IEBGENER to copy the DCB?
willy jensen
 
Posts: 336
Joined: Thu Mar 10, 2016 5:03 pm
Has thanked: 0 time
Been thanked: 44 times


Return to JCL

 


  • Related topics
    Replies
    Views
    Last post