On 01/15/2015 06:08 PM, Paul Gilmartin wrote: > On Thu, 15 Jan 2015 17:31:44 -0600, Joel Ewing wrote: > >> On 01/15/2015 03:29 PM, Ed Gould wrote: >>> On Jan 15, 2015, at 2:36 PM, Joel Ewing wrote: >>>> --------------------------SNIP------------------------------- >>>> If a PDSE library could have been multi-volume, that might have been one >>>> path to eliminate our requirement for PACK. >>>> >>>> -- >>> Joel: >>> I could SWEAR that in one of the announcements in the last year (or so) >>> that PDSE's would support multivolume. Or am I just incorrect. >>> > Wouldn't EAV be an alternative solution? Or is there another restriction? > (54 GB is *so* 20th Century.) > >> z/OS 2.1 "DFSMS Using Data Sets" (2014) still lists single-volume >> restriction for PDSE. But APAR "OA45917 NON-AMS PDSE CAN BE ALLOCATED >> AS MULTIVOLUME" reports that an unusable "not valid" PDSE can actually >> be allocated as multivolume via JCL in z/OS 2.1, closed FIN 2014-09-04. >> Perhaps the fix will be to make it valid? In any event too late for me >> -- been retired 3 1/2 years. > > -- gil >
PDSEs were originally also restricted to 65535 tracks per volume, but I notice that restriction was relieved at least by z/OS 1.10. It's probable that even 3390-27's would have been large enough to have allowed our installation to comfortably convert to unPACKed members in either a PDS or PDSE data set, but we were just beginning to phase in some 3390-27's when I retired, and at that point there was no motivation to expend unnecessary effort to change PDS PACK conventions that were working. The decision for an installation to use larger volume sizes, even a 3390-27, has implications for backup, recovery, DR support, and DASD management, which may or may not make that an appropriate or quick solution; although it is nice to have that alternative if no other solution exists. I would think it preferable to have the option of multivolume PDSEs, so that the decision of maximum installation DASD volume size could be based on other considerations and not be forced just by the requirements of a few exceptional data sets. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
