IBM Mainframe Forum

I can't remember if reading smaller blocks than BLKSIZE is a problem or not.

Actually, it's not a problem as long as the physical record size is a multiple of the LRECL. Yes, it gets an I/O error, but the error recovery determines that the record is OK and passes it up to the program.

People have been running jobs like this to correct DCB attributes for 50 years, though the BLKSIZE has changed. Just so long as the BLKSIZE you choose is greater than or equal to the BLKSIZE used create the PDS, you'll be OK.
Now NicC noted he would use BLKSIZE=0. Yes, that would be correct for a new data set, but not here. Others have noted 32720 or 32000 are inappropriate. True, but it does not matter here. We are trying to fix a problem, not continue use of the data set. This real data set will be abandoned anyway. We just have to transfer the uncorrupted members to a new, replacement data set.

Your next step is to prepare and run a job like this.
Now I cannot provide any reliable guidance as to what you should specify in the SPACE parameter, for two reasons.

• Allocated and used blocks is unreliable because BLKSIZE is unreliable. All I can say is it unlikely to be very large.
  In fact there is something seriously wrong with allocated and used blocks in the display we see.
• Rahulrkdd didn't provide any information about directory blocks.

You'll have to run this job at least twice. There are probably corrupted members that will have to be deleted for the job to run OK. I don't know if IEBCOPY will quit when it encounters a corrupted member or if it will go on to the next member. We'll just have to find out. If it quits it should tell you which member is corrupted. You can delete that member and rerun the job, or you can tell IEBCOPY to not copy the member on the rerun by adding an EXCLUDE MEMBER=xxx in the IEBCOPY control statements.

After rahulrkdd has the replacement data set he can delete the original data set and rename the replacement data set to match the original data set

Your PDS has RECFM=FA, which is also not what you want. But IEBGENER probably complains because RECFM=FA implies a blocking factor of 1, i.e LRECL and BLKSIZE must match.

Try again with


Note you don't need to enclose RECFM=, LRECL=, and BLKSIZE= in a DCB=(...) parameter.

Once you succeed, and the members can be read again, there probably will be a single member which still will raise an I/O error. You mignt want to find which one it is. The member name might also give you a hint about who was overwriting the DCB attributes.

If you need the content of the member despite the fact that it is not readily readable, e.g. in ISPF, you can run an IEBGENER using the "malicious" DCB attributes.



Reading data with changed DCB parameters will never corrupt the data set. It is only when you write to a data set that the DCB values may get overwritten.

you cannot use DISP=MOD for a PDS, in this case I would recommend OLD.

willy jensen wrote:you cannot use DISP=MOD for a PDS, in this case I would recommend OLD.

Wrong. When you write to a PDS, no matter what the DISP says - OLD, SHR, MOD, you always write after the end of the data set. MOD, in other words. MOD is perfectly valid for a PDS.

phunsoft wrote:... Note you don't need to enclose RECFM=, LRECL=, and BLKSIZE= in a DCB=(...) parameter.

Correct. But that's only been true for the last 30 years or so. I don't recall exactly when.

However I've been writing JCL for 50 years. Old habits die hard, especially when there is no good reason to change.

MOD is perfectly valid for a PDS.

Yes and no -- it can be specified but it may not work as desired. From the JCL Reference manual:

Disposition of partitioned data sets (PDSs and PDSEs)

z/OS MVS JCL Reference
SA23-1385-00

When you specify DISP=MOD or DISP=NEW for a partitioned data set (PDS) or partitioned data set extended (PDSE), and you also specify a member name in the DSNAME parameter, the member name must not already exist. If the member name already exists, the system terminates the job.

When you specify DISP=OLD for a PDS or a PDSE, and you also specify a member name in the DSNAME parameter, the data set must already exist. If the member name already exists and the data set is opened for output, the system replaces the existing member with the new member. If the member name does not already exist and the data set is opened for output, the system adds the member to the data set.

When you specify DISP=MOD for a PDS or a PDSE, and you do not specify a member name, the system positions the read/write mechanism at the end of the data set. The system does not make an automatic entry into the directory.

When you specify DISP=MOD for a PDS or a PDSE, and you do specify a member name, the system positions the read/write mechanism at the end of the data set. If the member name already exists, the system terminates the job.

So depending upon the specifics of the JCL, the system may terminate the job if you specify DISP=MOD.

At this point, I would try to recover from a backup. While the backup may not the most recent changes, it will resolve any DCB questions that you might have. Knowing the DCB information will help you resolve the problem.

Use command: HRECOVER blah.blah NEWNAME('blah.blah2')

Hi Pedro, I didn't understand "HRECOVER blah.blah NEWNAME('blah.blah2')"
Where should I enter this? and
What is blah.blah? DSN??

In response to your question from August 1st 2:20pm I suggested what you need to do at 04:30pm. Did you try this? If so, what was the result?