Page 1 of 1

Cool new JCL error!

PostPosted: Mon Apr 19, 2021 10:37 pm
by socker_dad
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?

Re: Cool new JCL error!

PostPosted: Tue Apr 20, 2021 12:37 am
by willy jensen
Could the job creating XXXXXXXX.P.FTPDCB.DATA(0) have failed, leaving a bad dataset?

Re: Cool new JCL error!

PostPosted: Tue Apr 20, 2021 2:09 am
by steve-myers
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.

Re: Cool new JCL error!

PostPosted: Tue Apr 20, 2021 2:42 am
by socker_dad
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).

Re: Cool new JCL error!

PostPosted: Tue Apr 20, 2021 1:26 pm
by willy jensen
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?