FBA LRECL 133 BLKSIZE 133 is almost certainly NOT correct. No one in
their right mind would create a blocked PDS that is effectively
unblocked with one record per block as you would be getting less the 5%
effective track utilization on any DASD made in the last 20 years.
Undoubtedly someone wrote a member to this PDS with batch JCL from a
program that had these DCB parameters hard-coded internally or with
these values hard-coded in the JCL and destroyed the correct values.
Until you fix the LRECL and BLKSIZE values to something that is
consistent with the old data you will continue to get I/O errors as
either the physical blocks in the PDS will be longer than the current
BLKSIZE or the physical blocks will not be a multiple of the current
LRECL, or both.
You need to run some free utility, like the VERIFY command under freebie
CBT utility PDS85 as others have already suggested, to find the true max
blocksize, which will almost certainly not be 133. Or a more
complicated approach if you have a utility like DFDSS would be to do a
hex dump of a track far enough inside the PDS to get past the directory
blocks and at least that should give you the size of some data blocks
and imply the LRECL (but unless you hit on a member that is multiple
blocks, you may not see the max block size). Then it should be an easy
matter to compute whether the max blocksize is a multiple of 133, or
possibly a multiple of 80, or some other value that would make sense in
the context of the data contained, and that will enable you to deduce
the true LRECL. I'm assuming here the original data was not RECFM VB.
If it was, about the only way to determine a compatible LRECL and
BLKSIZE is to find the largest BLKSIZE and then try an LRECL of that
value minus 4. That would at least allow reading the data, but a
complete scan of all logical records would be needed to find the minimum
acceptable value for LRECL.
Your 2nd problem is to find what not-so-bright programmer or application
caused the problem in the first place, as you could fix the problem and
have it immediately re-occur when they re-run the same flawed job step.
The problem is undoubted caused by a batch process because there is no
way the usual ISPF edit, move, copy processes would alter existing PDS
DCB attributes. When a batch job step sets the DCB attributes of a PDS
to bad values, the new member created when the problem was caused will
be readable, but it may be the only member readable. This should be a
clue as to where blame lies. If most members in the PDS were created
from ISPF and have member stats, then that would also narrow it down to
members without member stats. Of course if the guilty party recognized
their error, they might have deleted the bad member to hide the evidence.
Once you know the correct BLKSIZE and LRECL, use PDS85 commands to set
correct values, or JCL techniques previously mentioned in this thread to
set those values. That should make all the old members readable. The
RECFM FBA may also be suspect, but if the data is really FB this will
not prevent viewing the members. If none of the old members have
carriage control characters in column 1, then you should change RECFM to
FB as well.
Once you can get to all the old members, only members created with bad
LRECL or BLKSIZE might be unreadable. After deleting any of those
unreadable members, build a new PDS by copying all the members to a new
PDS and either rename or delete the old PDS as appropriate. Compress of
the old PDS would also eliminate the bad block sizes of deleted members,
but you might want to keep the original dataset around until you are
sure there is no chance of needing to recover any more member data.
Every time I have seen this problem with a PDS, it is because some
programmer got the bright idea of saving some batch report in an
existing PDS that was designed for other uses without understanding that
a PDS can only have one set of DCB attributes. A hard rule should be
that no batch job step should be allowed to write a PDS member without
first setting up JCL to write to an ordinary sequential data set and
verifying that the DCB attributes of the sequential data set can be made
consistent with those of the PDS. There are still ways to mess up, but
the odds are much better.
JC Ewing
On 07/27/2011 06:35 AM, esmie moo wrote:
Barry,
The STORAGE GROUP was backed up via HSM, what I didn't say correctly that the
volume was not backed up (full dump).
When I am able to do a browse of the dsn, all the members are displayed
correctly, however when I browse each member I get the following :
I/O error
When I press F1 for more info I get the following:
An I/O error was encountered reading the first record requested.
The DCB of the PDS is as follows, however I cannot be sure if it is correct
since this PDS was inherited from a client
Organization . . . : PO
Record format . . . : FBA
Record length . . . : 133
Block size . . . . : 133
1st extent cylinders: 5
Secondary cylinders : 2
Data set name type : PDS
From: "Schwarz, Barry A"<[email protected]>
To: [email protected]
Sent: Tuesday, July 26, 2011 3:57:31 PM
Subject: Re: CORRUPT PDS - I/O ERROR
If the storage group is not backed up, how did HSM ever back up a copy for you
to recover from? Was there a copy of the dataset on disk when you recovered it
from HSM? What was the command you used to perform the recovery? When you
browse the PDS, does the member list display correctly? What are the DCB
attributes of the PDS? Do they match what you think they should be? What is
the exact error message?
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of esmie moo
Sent: Tuesday, July 26, 2011 10:03 AM
To: [email protected]
Subject: CORRUPT PDS - I/O ERROR
Good Morning Gentle Readers,
When I try to browse a member of my pds I get a I/O error. I tried
browsing several members but I get the same error message. Is there a way
of fixing it? For some reason the storage group is NOT backed up so I
cannot restore it from an old backup. I recovered the PDS from a DFHSM
backup but when I try to browse any members I still get the I/O error. Is
there a work around to this problem or should I consider it lost?
...
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
