Mike Wojtukiewicz wrote:
John,
I'm going to echo back what you said to me as I understand it and see if I
have it right.
1 - INDIRECT cataloging used. Fine. It restores the datasets 1 for 1 with
where they now reside. All need be done is to change the IEASYMXX member,
IPL, and go.
Well...kind of. ServerPac always uses the ISPF tables to decide
where to allocate the data sets. If you saved your old
configuration and have not moved any data sets since, then if you
merge that saved configuration with the new work configuration
the data sets will be allocated on the same volumes.
Let's use an example. It's clearer, I think.
Suppose that today you have ZOS17A and ZOS17B as your target
volumes, and ZOS17A is the IPL volume. You built this system
using ServerPac, and saved the configuration. You use indirect
cataloging for this system, with the name of the second volume
derived from the name of the first using the system-set value of
the &SYSR1 symbolic to set the value of &SYSR2 in IEASYMxx, and
you use &SYSR1 and &SYSR2 in your catalog entries.
Tomorrow you get your z/OS 1.8 ServerPac. You choose Software
Upgrade and create a new work configuration by merging it with
the saved configuration from the z/OS 1.7 system. Now, the work
configuration for the 1.8 system looks *exactly* like the one for
the 1.8 system, except that any new data sets remain to be placed
on ZOS17A and Z0S17B and any that are no longer used will not be
allocated.
But--wait a minute--you can't have two ZOS17As and two ZOS17Bs
online at the same time (and anyway, your naming convention would
be screwed up if you used these names for a 1.8 system). So,
let's rename them in the ServerPac dialog to ZOS18A and ZOS18B.
So far, so good.
Uh-oh! There isn't enough space on ZOS18A for all the data sets
now, because some are larger than they used to be. OK, you say,
I'll move a few data sets to ZOS18B, which has more free space
than it needs.
What data sets do you move? Well, not SYS1.NUCLEUS; you want to
be able to IPL from ZOS18B. What about ISF.SISFLPA? Hmmm...do
you use SDSF? No? Then you can move it to ZOS18B and nobody
will really care that the master catalog can only really point to
it when one one set of volumes (ZOS18x or ZOS17x) is in use. So,
you move ISF.SISFLPA. (Maybe someday you'll care about this data
set. I hope so, it's a priced feature. ;-) That takes care of
the space problem on ZOS18A, and you can proceed.
Now you run through the jobs. All the data sets (except
ISF.SISFLPA) that are on ZOS17A for the 1.7 system will be
allocated and loaded on ZOS18A for the 1.8 system, and the same
goes for ZOS17B/ZOS18B. When you get all the way through the
process, the only updates to the master catalog will have been
made for:
1. ISF.SISFLPA, for which the catalog will now point to the
second volume (&SYSR2) rather than the first volume (&SYSR1).
Since you don't use SDSF, this does not affect the operation of
either the running system or the new one.
2. New data sets, for which the master catalog will point to the
symbol you put in the table used to run the (RECATDS?) job (OK,
it's been 2+ years since I worked on ServerPac, and I'm getting
fuzzy about things like job names).
When you IPL the 1.8 system, the catalog points to the right
volumes for all the data sets and all is well. When you IPL the
1.7 system, the catalog points to the right volumes for all the
data sets you actually *use*, and all is still well. No update
to IEASYMxx is needed because you based &SYSR2 off the value of
&SYSR1. To change which system you IPL from, just change the
device number you load from. This also simplifies operator
procedures for backout, etc.
2 - NO Indirect cataloging used. It restores the datasets in the same spots
they are now as in item 1 BUT then are recatalogued on the fly to the new
VOLSERS..
Assuming you merged with the saved configuration as above, yes,
mostly, except as noted above. This obviously poses a problem
for the existing system, which can no longer be IPLed, because
the catalog now points to different volumes. (Your problems
could start sooner than that, of course, if the existing system
is running! Don't do that.)
In BOTH cases it reads the CPAC repository to find out what the operational
datasets are. (i.e. their MVS datasetnames). If a dataset in either case is
moved it will restore the new dataset to the wrong volume unless one updates
the "repository"
The whole point of Software Upgrade is that your existing
operational data sets get used. A lot of people run through the
Full-System Replacement path and then discard the catalog, page
and spool data sets, etc. to reuse their existing ones. (This is
at least less work than trying to use them all on an existing
system, but still more work than SU in the recommended indirect
catalog environment with operational data sets located off target
and DLIB volumes, etc.)
So for Software Upgrade there are very few operational data sets.
I don't recall the ones on the short list of those that remain,
but CPAC.PARMLIB is one of them because it contains the tailored
IFAPRD00, and SYS1.IBM.PARMLIB is one of them because it contains
members that are associated with the level of software (like
CTRACE specification) rather than how you want the system to
act), both of which are intended to be placed on a target volume
and concatenated to your SYS1.PARMLIB data set. The others (page
and spool data sets, RACF data sets, etc.) are found using the
catalog.
<snip>
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[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
