Date: Thu, 4 Feb 1999 17:00:14 -0500
Reply-To: MICHAEL.RAITHEL@RAITHM49.CUSTOMS.SPRINT.COM
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: "Michael A. Raithel" <MICHAEL.RAITHEL@RAITHM49.CUSTOMS.SPRINT.COM>
Subject: (MVS) Re: Re: Job Bombing on MVS-insufficient workspace
Cybie Frontier dragged me (just kidding), into this
discussion by writing, in part:
>After having said all these, I also remember that the MVS
>Companion gives a reference to Michael Raithel's book
>regarding this. Sorry Michael, I have not yet reached that
>level, but could you possibly have a "neat" solution to
>this? :)
>
(Cybie's entire posting can be found beneath the Sig line,
below).
Cybie, this puts me in the uncomfortable position of having
to mention my book, "Tuning SAS Applications in the MVS
Environment," published by the SAS Institute, Inc. in 1995,
303 pages, book #55231:-) This book _IS_ mentioned in the
SAS Companion for the MVS Environment, Version 6, Second
Edition on pages 39, 151, and on the back cover. I am
shocked that you are using SAS under OS/390 (MVS) and do
not have a copy on your bookshelf (still kidding)!
Well, all seriousness aside, I did not respond to your
interesting posting because I saw that you got a lot of
good advice from some very talented SAS-under-MVS
programmers. You couldn't go wrong with most of the advice
that you got.
The bottom line is that free space on Work DASD's is
extremely variable, especially in organizations that have a
lot of batch job action. It is very hard to predict how
much space is available and how fragmented the various Work
DASD will be when you submit a particular job (unless you
know how to specifically look--hard to do for jobs
scheduled at oh-dark-thirty). I usually opt for a large
primary extent, and then smaller, more reasonable secondary
extents. Most of my batch SAS jobs have the following:
//STEP01 EXEC SAS,WORK='750,100'
or
//STEP01 EXEC SAS,WORK='2000,100'
I like to grab a big slice of Work SAS library DASD space
up front, and then deal with smaller chunks if I need them.
But, then, I know what I can get away with in my own
particular environment.
In the book, I don't cover your exact problem: running out
of space in the SAS Work library, mid-job, due to taking up
all of the extents. But, I _DO_ cover: not finding enough
space for the SAS job to initiate, and not finding enough
DASD Work space to take a secondary extent (on the SAS Work
Library) in Chapter 12, section: DASD Work Space
Shortages, pp.270 - 276. I don't think that it is cost
effective to buy the entire book for six pages, so I'll
briefly go over the five points, below. They may not apply
to your specific situation, but what the heck, somebody
might find them useful!
Five Ways to minimize the risk of DASD Work Space
shortages:
1. Decreasing the primary Work space allocation. If the
primary Work space allocation consistently fails, reduce it
to ensure that you get enough Work space for your job to
begin running. SAS batch jobs will not run if they cannot
allocate the primary quantity of SAS Work library space.
You should have secondary allocations set less than or
equal to the primary allocation amount. This works well in
sites where the Work DASD is very fragmented.
2. Increasing the size of the primary Work space
allocation. Another annoying situation is when the Work
data set cannot take a secondary extent. Sometimes if you
make your primary Work space allocation large enough, you
may be able to do all of your work within it. In this
scenario, you would specify smaller secondary allocations.
3. Manage the space within your own SAS Work Library. In
doing this, _YOU_ take control, and delete obsolete, never-
to-be-used-again, temporary SAS data sets from the SAS Work
Library via PROC DATASETS. I _HIGHLY_ recommend this
approach! But, then, I always make my bed and keep my room
clean...
4. Reschedule your application's time of execution. Though
this may seem like a Wimp's approach, it can be very
effective. In most organizations, the 9 - 5 time slot is
the heavy period of program submission, and thus Work DASD
space utilization. (Yes, yes, yes, we all know that it
differs by organization and may be 8 - 9 pm, or may be
heavier at night, etc.). By scheduling you batch job for
the quieter, non-batch-prime-time hours, you may have
enough space at your disposal to accomplish your goals.
5. Allocate the SAS Work data library on your own DASD. If
you own, or can borrow dedicated DASD, then you can control
exactly how much space you can allocate, and direct the
program to allocate the SAS Work Library on that particular
DASD. The override JCL might look like:
//SAS.WORK DD UNIT=3390,VOL=SER=ZEP001
Some organizations that I have worked for have "loaner"
DASD for special production jobs that need it. You might
check with your DASD administrator if this appeals to you.
The above points are hardly an exhaustive discussion of
each topic, but more of a "consider this method and its
positives" discussion. Obviously, some concepts have been
trivialized to fit this particular forum's medium.
To make this posting endless...
Regarding Multivolume SAS Data Libraries, the SAS Companion
for the MVS Environment, Version 6, FIRST EDITION, has a
great write-up. It is in Appendix 2, Multivolume SAS Data
Libraries, pp 531 - 534. I found this to be very helpful
in the past, and was amazed that it was dropped from the
Second edition of 'the companion. (Cybie, the only problem
with using this in your situation, is that you must
specifically know what DASD volumes you are going to use).
A cool way of increasing your SAS data library's space, on
or between DASD volumes, is via the XTENDLIB command. I do
not remember where I got this, and believe that it was
FAXED to me eons ago by the very helpful, hard working,
always there when you need them, SAS Institute Technical
Support. Here is an example of using XTENDLIB:
********************************************;
* ALLOCATE THE SAS PRIMARY/EXTEND LIBRARIES*;
********************************************;
LIBNAME MAINLIB 'CYBIES.BIG.SASLIB'
DISP=NEW UNIT=SYSDA
SPACE=(CYL,(1000));
LIBNAME EXTEND01 'CYBIES.EXTEN001.SASLIB'
DISP=NEW UNIT=SYSDA
SPACE=(CYL,(1000));
********************************************;
* XTEND THE LIBRARY. *;
********************************************;
XTENDLIB MAINLIB EXTEN001;
The code, above, allocates two new SAS data libraries, and
then specifies for the SAS System to consider the second as
an extent of the first.
Cybie, I guess that I do not really have any "neat" trick
to specifically solve your problem. Rather, I am zapped by
the same situation from time to time, myself. The things
that I recommended, above will help you to minimize running
out of DASD Work space. So, too will the expert advice
that you got from other posters!
Cybie, good luck in your forays into allocating space, the
final frontier!
I hope that this suggestion proves helpful now, and in the
future!
Of course, all of these opinions and insights are my own,
and do not reflect those of my organization or my
associates.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michael A. Raithel
"The man who wrote the book on performance" E-mail:
maraithel@erols.com
Author: Tuning SAS Applications in the MVS Environment
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Everything is funny as long as it is happening to somebody
else. -- Will Rogers
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Thanks to Shawn, Barbara, Carol, Frank, Carla, Rhoades,
>Tim, Michael, Ming,Kleonte for your suggestions. I was
>hoping for a disk span solution, got to try it tomorrow.
>Meanwhile, I decided to create a permanent dataset on Tape
>( and not a temprary dataset)to avoid the problem. It
>worked this time.
>However, it may not work the next time when I really need
>that extra workspace and creating permanent data on tape
>(even with a retention period of 1 day is not good
>enough).
>
>Maybe spanning the workspace is the only solution.
>Increasing the number of primary and secondary space from
>544,544 to 1000,800 may not be possible - each
>installation is different and they have different rules. >
>After having said all these, I also remember that the MVS
>Companion gives a reference to Michael Raithel's book
>regarding this. Sorry Michael, I have not yet reached that
>level, but could you possibly have a "neat" solution to
>this? :)
