IBM Mainframe Forum

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



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:

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?

Could the job creating XXXXXXXX.P.FTPDCB.DATA(0) have failed, leaving a bad dataset?

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

Select all

//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:

Select all

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.

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).

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?