This is the reason our one-pack system has over the years evolved to a
two-pack system, with one non-SMS STORAGE volume and one SMS volume in a
unique storage group. On the two-pack system the ACS routines are
modified so that some of the routinely used storage classes are changed
to all map to that alternative storage group. This minimizes the
changes that are required to our production SMS and RACF environments
for use on our emergency system.
We use this system not only as an Emergency Recovery System but also as
an MVS test bed to test out new versions of IVP products or IBM
corrective maintenance before installation in production, and for that
purpose it is useful to support both SMS and non-SMS allocation. For
IVP testing we may add additional drives, but we always keep this system
in a state where the core operating system functions are confined to the
two main drives, and a stand-alone restore of those two drives is
sufficient to obtain a functioning z/OS.
Mark Steely wrote:
We are z/OS V1R7. I need to create a one pack IPL'able system. The only
question I have is how to handle temp allocations when you submit or
edit a file. Do you create an SMS routine to make all allocations go
through the same process and end up with the same storage group. how do
other site's perform this function.
Any help would be appreciated.
Thank You
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
