Or use IEBDG...

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Joel C. Ewing
> Sent: Thursday, June 21, 2012 6:00 PM
> To: [email protected]
> Subject: Re: [IBM-MAIN] SMS processing setup for secondary extents
> 
> On 06/21/2012 07:47 PM, Joel C. Ewing wrote:
> > On 06/21/2012 06:42 PM, Lizette Koehler wrote:
> >>> From: "Joel C. Ewing" <[email protected]>
> >>>
> >>> And better yet, also use a DATACLAS with the Extended attribute so
> >>> you are not constrained to only 16 extents per volume.
> >>>
> >>> With Space Constraint Relief. Extended attribute, and Dynamic Volume
> >>> Count, both primary and secondary allocations will use as many
> >>> extents and volumes as necessary to get the requested primary or
> >>> secondary space (not just the 5 extents for primary, 1 for secondary
> >>> limits of ordinary sequential dataset allocation), so fragmentation
> >>> of free space is less of an issue.  Since you are not guaranteed any
> >>> minimal amount of space for any individual extent, you also need the
> >>> larger extent count limit given by the Extended data set attribute
> >>> to insure that you are not artificially restricted by number of
> >>> extents from allocating available free space on the assigned volumes.
> >>>
> >>> Using these attributes you can even request a primary allocation
> >>> that spans multiple volumes and guarantee that step execution will
> >>> not even start if a large minimal primary space is unavailable, but
> >>> you have to be careful using this because at least in the past the
> >>> RELEASE option would not release allocated but unused space on
> >>> volumes that contained no written data, only on the last used volume
> >>> of the data set (so a multi-volume primary allocation used for a
> >>> very small dataset could consume a large amount of pool space on
> >>> subsequent unused volumes even after RELEASE).
> >>>     Joel C Ewing
> >>
> >>
> >> Joel, I am not sure that would apply to a PDS.  I know that for
> >> nonvsam sequential files that will work, but I am not sure if it is a
> >> PDS if it can go beyound 16 extents.  I have been looking through the
> >> manauls and cannot find a reference (info center - yuck).
> >>
> >> Can you comment?
> >>
> >> Lizette
> >
> > No, I'm pretty sure my remarks only apply to Extended Sequential
> > datasets and that there is no "Extended" support for PDS or PDS/E data
> > sets.  VSAM datasets can also be Extended, but they have their own
> > allocation rules.
> >
> > I interpreted the context of the original question to be about
> > sequential datasets since multiple GDG datasets were being merged --
> > and the ability to create and work with GDG datasets that happen to be
> > a PDS is not really documented and not generally known outside those
> > of us that needed the capability, tried it, and found it worked
> > (obviously you can't specify both a member name and a relative GDG
> > number in JCL because of syntax restrictions). I gathered from
> > discussion at one of the SHARE Q&A's over a decade ago that PDS/E's
> > can't be a GDS because the PDS/E designers didn't appear to be aware
> > that was one of the "features" of a PDS and the PDS/E implementation
> > explicitly disallowed such usage.
> 
> And I forgot to mention earlier that a simple way to test whether your
> sequential datasets are being allocated as expected is to set up a job to
> IDCAMS REPRO a moderately sized sequential dataset concatenated to
> enough copies of itself to build up a sequential dataset equivalent to about
> half a drive in the pool, and then use that concatenated to itself enough
> times as input to another REPRO to convince yourself that extents for a
> multi-volume output dataset are being allocated as expected and multiple
> volumes are being used -- being careful to delete all your "junk" datasets
> after inspecting the results.  There is an IBM utility designed explicitly to
> create a specified number of test records for a sequential dataset, but my
> recollection is that it is incredibly slow and a CPU hog - much faster to use
> IDCAMS REPRO.
> 
> --
> Joel C. Ewing,    Bentonville, AR       [email protected]
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to