Page 1 of 1

Bad Member in a PDS

PostPosted: Fri Mar 29, 2013 9:01 am
by hdevang4u
Hi,

I have a huge PDS with more than 30,000 members in it. There is possibly a corrupted member in the PDS. Is there any JCL utility that can be used to identify the corrupted member?

Re: Bad Member in a PDS

PostPosted: Fri Mar 29, 2013 2:38 pm
by BillyBoyo
Talk to your technical people. They are less likely to destroy the whole thing whilst attempting to fix it.

30,000 members in a single PDS? How long does it take to add a new member called "A"? Don't experiment until you know the PDS is good :-)

Re: Bad Member in a PDS

PostPosted: Fri Mar 29, 2013 7:07 pm
by dick scherrer
Hello,

How might the member have become corrupt? What to you mean by "corrupt"? When did the problem occur?

Is there a backup just before the corruption occurred?

Re: Bad Member in a PDS

PostPosted: Fri Mar 29, 2013 7:18 pm
by enrico-sorichetti
There is possibly a corrupted member in the PDS.


The TS does not even know if there is one :geek:

Re: Bad Member in a PDS

PostPosted: Sat Mar 30, 2013 12:13 am
by steve-myers
BillyBoyo wrote:... 30,000 members in a single PDS? How long does it take to add a new member called "A"? Don't experiment until you know the PDS is good :-)
I'd like to know why the TS believes there is a corrupted member in the PDS!

The issue BillyBoyo raised about how long it would take to add a low member name in the collating sequence to the data set got me interested. I wrote a small Assembler program to add members M30000 through M00001, in that order. I did cheat in one respect. I did not attempt to write ISPF directory statistics. While I could have done that, it wasn't worth the effort for a throw a way program, but it did speed things up: the final directory used 1429 blocks, much less than the 5000 blocks required if the program wrote ISPF directory stats.

An Assembler programmer using BPAM to write to a PDS uses the STOW macro to add a member. When adding a member, the STOW macro does more than update the directory. It also writes a DASD end of file record for the member, and that requires a small amount of time.

I instrumented the program to collect the elapsed time required to execute the STOW macro. It rexorded the time in the next member it wrote. M29999 has the time required for the STOW macro for member M30000, and so on. M00001 has the time for M00002. I did not record the time for M00001.

Here are the raw times.

M00002 0.07 seconds
M00003 0.08 seconds
M00004 0.08 seconds
M30000 0.00 seconds