On 10/15/2010 12:53 PM, Darth Keller wrote:
If the dataset is SMS managed, the second volume won't allocate until
you
fill up the first volume and a second volume is needed. Why is it that
you
want to allocate the 2 volumes?

As someone stated earlier - a primary allocation can not span 2 volumes
(for the most part).  However, you can have a primary allocation on 2
volumes - of course, they're not mentioning that with the JCL you were
given, you will also get 2ndary allocations on the 1st volume until you
run out of either allowed extents on that volume or space on the volume
and then would get the 2nd primary&  more 2ndary allocations.

That's a pretty simplified view and can be affected by the size of the
volumes your shop is using, the way your dataclas is defined, etc.

With that said, you Can get the primaries allocated on both volumes at
initial allocation time - if the storage class your dataset is assigned is
defined with the "Guaranteed Space" attribute. I'd have to hit the manuals
to know for sure whether it writes to the 1st primary, then the 2nd
primary, then 2ndary allocations on 1st volume, etc. or if you'll use all
the primary&  2ndary space on the 1st volume before using the second.

Another way to get your space allocated across multiple volumes would be
by striping which is controlled by the "Init Acc Response" attribute of
the storage class.  This would would cause your primary allocation to
split across a # of volumes to get you the desired intial access response
time.  When you write the DS out, you would send a write to the 1st
volume, the 2nd write goes to the 2nd volume&  so on.  There are
limitiation to this - IIRC you can only have 16 extents to a stripe.

These are both kind of old fashioned now days&  I'm sure that someone with
a lot more time and energy than me can hit the manuals and pick all my
thee's&  thou's apart - I don't care&  the reason I don't care is that you
really need to have this discussion with your storage administration staff
or whoever performs that function.  They should understand the SMS
environment and how it interacts with the hardware your shop has
available.  They need to have a clear understanding of what your needs
really are before they can tell you the best way to go.  For most
applications, the primary allocation on the 1st volume, plus it's
2ndaries, then the primary on the 2nd volume and so on is both the most
straight forward method and adequate for most application's needs.  If
your application has some very specific requirements, you need to have
that discussion as SMS is generally controls your allocations through the
rules&  definitions they've set up.

Hope that helps - dd keller


An SMS primary allocation *CAN* indeed extend across multiple volumes and across many, many extents - provided you use an appropriate SMS DATACLAS that allocates as Extended Sequential, with space constraint relief and with multiple volumes. If you do that you can actually request a primary allocation greatly in excess of a single volume and up to the max number of extents possible for extended sequential (127?) on each of as many volumes as required to make up the requested space. Since each volume can have a large number of extents, even disk fragmentation is unlikely to prevent allocation as long as the total free space in the target SMS storage group is sufficient.

This is GREAT for cases where you must generate a humongous output file, want to be sure you actually have the space before starting execution so you don't blow a lot of resources generating the file only to abort because it can't find another extent for the last few cylinders of data. It also eliminates the need for knowing the typical amount of free space that can be obtained on a single volume. You simply request as a primary space all the space you actually need for a successful run and if that much space is a available in the entire SMS pool you should get it.

The only "gotcha" here is that if you use RLSE to release unused allocated space, it will only release the unused space on the volume containing the EOF - any allocated space on following volumes that haven't yet been reached will remain until the dataset is deleted. This means if you ask for a 60,000 cylinder primary and only write 5 cylinders, you will be left holding a large amount of space on all the following continuation volumes that you don't need and probably cause problems for others. So care should be exercised before using this technique on datasets that vary widely in size from run to run.

--
Joel C. Ewing, Fort Smith, AR        jcew...@acm.org

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to