> Somewhere in the mists of time I got the idea that multi-volume (or > stripped) dumps were not supported. I think I ran into this 10 years > ago (before stripping). Was that ever the case? > > I vaguely recall having a dump that needed several volumes and AMDPRDMP > would not touch any volume after the first.
I haven't been an end user of SADMP in the time frame of concern to you. I'm certain that the first support that you saw from it for multi-volume dump data sets would have had you telling it in sequence to use the primary volume, overflow to the 2nd, .... The recent changes to SADMP related to multi-volume support have all occured in the 21st century. Greg Dyck, a regular contributor to IBM-MAIN, is the authority on most of them. (1) The first support shipped was for conventional, multi-volume data sets, support made available in the middle of the lifetime of z/OS V1R2. You allocated and initialized them with the aid of an AMDSADDD REXX exec that addressed the fact that SADMP doesn't do z/OS catalogs by writing a block at the beginning of each volume that enumerated all the other volumes spanned. The record, if you looked closely, revealed thinking that SADMP should dump to multiple data sets, not just to multiple volumes spanned by one. I played the villain on that one and said that I didn't want to get IPCS into the business of dealing with data set groups as an additional basic concept. SADMP would exploit the multiple volumes in parallel, cutting down the dumping time somewhat less than N-fold for an N-volume data set. What it did was classic multi-volume writing, not striping as DFSMS knows it. (2) The 2nd support added extended format data sets to those supported because extended format was the first to allow more than 64K tracks per volume to be used. I think that was delivered in the middle of the lifetime of z/OS V1R4. The fine print said that you could use neither the compression nor the striping features of extended format data sets. Each physical volume that SADMP could see matched one volume seen by applications using the data set after a z/OS IPL. SADMP used the multi-volume data set just like a conventional one but could get more data on a volume if that made sense. PRDMP left the scene long before any of this happened. IPCS has always "supported" multi-volume dumps and was designed to index randomly-ordered dump records, but performing well in the face of really large instances of multi-volume SADMPs has been a challenge. That remains the case although we've made a dent in the performance concerns - hopefully soon enough so you don't get the brunt of them. The best advice that I can give on that front is to copy the dumps out of the multi-volume data set where SADMP wrote it before commencing analysis using IPCS COPYDUMP. Place the copy in an extended format data set that exploits striping and compression capabilities of DFSMS, and make the original multi-volume data set available for use whenever it may be needed again. We're putting logic in COPYDUMP to recognize how SADMP scatters data across the volumes, writing out the copy much as though SADMP had been given the time to write the dump to just one volume. Bob Wright - z/OS MVS Service Aids ---------------------------------------------------------------------- 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
