IBM Mainframe Forum

dick scherrer wrote:I'm curious how much was being written to the problem member at the time of the problem - might the pds have filled and then returned to the non-full state after the abend?

Actually, that's not possible. All normal output processing to a PDS (with the exception of IEBUPDTE UPDATE=INPLACE or IMASPZAP "zaps") write to the end of a PDS. If you get an ABEND, the space is gone.

I, too, would be curious about the contents, if any, of the output member, though if there was already a member BA51MGV1 you could well be looking at the old copy of the member.

Hello,

Are the pointers in the pds updated with each write? I would hope that this happened when the file/member was closed

Aslo possibly useful is knowing just what program RWRDWT does. . .

dick scherrer wrote:Hello,

Are the pointers in the pds updated with each write? I would hope that this happened when the file/member was closed

Aslo possibly useful is knowing just what program RWRDWT does. . .

My experience suggests that DS1LSTAR & DS1TRBAL get updated, and I think at CLOSE (or perhaps at STOW for full PDS processing) rather than at each write. The equivalent DCB fields are updated with each write. For this situation, where the DCB integrity is questionable, I would not bet DS1LSTAR/DS1TRBAL are updated. I, too, would like to see the program, but I'd be reluctant to debug it, though we could quickly check if there is a SYNAD "exit" and if it is properly written. It's actually moderately difficult to write a correct SYNAD exit.

For you beginners, DS1LSTAR contains the resume point or end of data, and DS1TRBAL contains the number of unused bytes at the end of the last used track, which data management uses for DISP=MOD or regular PDS output. These data areas are in the format 1 DSCB for the dataset.

An obersvation i should like to comment on is, 322 cylinders is an ridiculous amount of DASD for a proclib, methinks this has NEVER been compressed since PDS Creation date . . . : 2007/02/12.
Im now reminscing about scratching around the DASD to find a few cylinders to expand into, oh the good old days

I think halfteck has a valid point, though a PDS "compress" of a live PROCLIB is moderately risky: strange things will happen retrieving a member that is being compressed before the directory update at the end of the compress completes, and a "compress" of 300 cylinders will take several seconds elapsed time.

I have a utility used to recover deleted members. I'd love to run that program in non-update mode to get an idea how bad the situation is with this dataset. Another utility I have does an image copy of the source. It's not a true image copy in a sense, since the output does not have to be in the same disk addresses as the original, but each output track is a faithful copy of each source track, though the count records of the copy have the correct record addresses for the copy. Once the copy completes, do a "compress" of the copy. This should give the topic starter an idea of how long a "compress" of the original dataset would require. Oh well, the opportunity will never present itself to me.

One thing the topic starter should do that is perfectly safe is do a PDS copy of this PROCLIB dataset, and compare the space usage of the copy with the space usage of the original.

I once worked at a shop that had a user accessible PROCLIB similar to this. I don't recall the size of this disaster, but one day the directory filled up. It took a few days before the directory was expanded. The real problem with this dataset was abandoned members rather than space. I suspect the topic starter's PROCLIB has the same problem.