Date:         Tue, 8 Jul 1997 16:30:02 -0700
Reply-To:     PDORFMA@ucs.att.com
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         Paul Dorfman <PDORFMA@UCS.ATT.COM>
Organization: AT&T Universal Card Services
Subject:      Experience w/ mult-vol SAS libraries on MVS?
Content-Type: text/plain; charset=us-ascii

Tom Frenkel <frenkel@CUCIS.CIS.COLUMBIA.EDU> wrote:
 
>At our shop (MVS, with SMS storage management and HSM dataset migration;
>3390 disk storage), we have several large SAS libraries (about 1000
>cylinders each) that now need to get even larger ... to about 1700
>cylinders each.  Up to now, we have kept each SAS library on one DASD
>volume, but since we can't easily find any single volume with the space >we need, we are thinking about going the multiple-volume route.
>I have read Appendix 2 to the _SAS Companion to the MVS Environment_, as
>well as Barry Merrill's comments in the MXG Newsletters #23 and #26.
>There seem to be various approaches to multi-volume configuration, but,
>what with all the warnings that are included, I haven't seen any >approach that makes me feel too confident!  (And, to add to my >nervousness, the SAS libraries in question are of a "mission-critical" >nature.)  I'd like to hear from people who have tried to go >"multi-volume" in an environment like ours -- I'd like to find out what >worked, and what didn't.
>Oh -- one more complication in our shop: our DASD free space is quite
>fragmented.  Actually, this is the reason that we want to go >multi-volume in the first place!  But I realize that "Appendix 2" warns >that this fragmentation may interfere with the multi-volume process.
>Thanks for any "war stories" you could provide --
 
Tom:
 
Here at AT&T UCS, we work in approximately the same environment as
yours in terms that the DASD space is SMS managed. However, some
volumes called here 'private' are free of the SMS harness. Perhaps, this
is the reason I have been able to use the approach described in
the SAS MVS Companion with impunity. Of course, there is a drawback
(and I have no idea how to be rid of this one) - the serial numbers of
the volumes you choose have to be hardcoded, so the next time you are
writing to any of them (especially going to extents) you cannot be
quite positive that the sufficient space is available. However, if you
write to them just once when creating the SAS libraries and then merely
query the data and/or update them in a way that does not require to
create an extra copy of a dataset then you might be interested in
knowing that normally I take some precautions beforehand:
1. Go to QW and in 'S' option, list all the DASD information by number
   of free units descending.
2. Pick 5 non-SMS-managed volumes each of which has (to be on the sure
   side) twice the free space you need for one-fifth of your library.
3. Note the serial numbers of the volumes and use them to concoct a
   JCL the way SAS Companion describes it.
4. If you are planning to use indexes try to foresee as much as possible
   and create all of them as you are writing. Bear in mind that they
   do consume considerable DASD space (in my experience - 20 to 50 per
   cent relative to the main dataset volume; of course, these numbers
   may vary hugely).
This process has been pretty forgiving so far: in our shop, I have been
able to chop up to 4369 cylinders off a 3390 disk pack which gives me
at least 20,000 cylinders if I need it. Needless to say, I do not use
this kind of volume for too long a period of time - system people up
here are very nice folks but not that tolerable... However, with 1700
cylinders I would have little to worry about since it would require -
even with my safety margin - 680 cylinders off a disk pack which is
a mere fraction of about 10,000 available. You might note that our
DASD space here in UCS is more generous but, on the other hand, a file
of 20 million records by 500 bytes is like an average, so, relatively
speaking, we are in a similar situation. Last, not least, I would
take a peek at compression, too - that may save you a lot of DASD
space grief (the size of the lot depends on the nature of your data),
especially if you take time to read the corresponding chapter in the
Michael Raithel's book 'Tuning SAS Applications in the MVS Environment'
where the compression issues, particularly associated with performance,
are treated with both depth and clarity. By the way, it is a very
distinguished text in every other way as well.
 
Another technique used here which is virtually bulletproof and could
not care less about space fragmentation is to keep data in flat files
and use views to query the data. The privilege of using indexes
and the convenience of random access is certainly being lost but I feel
that a win-win solution could hardly be found, so we use this method
when data are very bulky, indeed (for instance, in the case of a file
having to swallow a snapshot of a sizeable part of the entire
database).
 
Hope it helps even though not all people here may share my opinion,
so let it be known that it is my own and only my own...
 
Paul M. Dorfman
SAS Consultant
AT&T UCS
(904)954-2419 (w)