Joel, I changed the PDS (via batch job as posted earlier) and that fixed the problem. Thanks very much for the helping hand.
From: Joel C. Ewing <[email protected]> To: [email protected] Sent: Wednesday, July 27, 2011 12:00:56 PM Subject: Re: CORRUPT PDS - I/O ERROR 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 ---------------------------------------------------------------------- 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
