-----------------------------------------<snip>---------------------------
Can anybody help me, how to setup multiple zone to follow above concept.
-------------------------------------<unsnip>----------------------------
What I always did was this:
1. Target zones was named to reflect the IPL folume set that it
represented. For example, if my IPL volume was IPL001, that was the name
of the target zone.
2. DLIB zones were named to reflect the first volume of the DLIB "set".
3. The DLIB set for the IPL volumes were related in SMP/E.
4. ONLY one DLIB set was maintained. Once a new release appeared in
shop, the old DLIB set was replaced and the new IPL set was defined. At
that point, maintenance, other that critical stuff, was ceased on the
existing IPL set.
5. The IPL set was defined using actual VOL-SER information, whereas the
DLIB set was defined using a separate UCAT; HLQ's were changed such that
the UCAT was used, rather than the MCAT.
6. In most cases, though not always, IPL set vol-ser information was
altered to the new set using a ZONEEDIT under SMP/E.
It may sound complicated but in our shop, no VOLSER is used twice in a
release or between releases for an IPL set. Releawse 1.10 was named
IP110a, IPL110B and IPL11C, and release 12 is being named IPL12A, IPL12B
and IPL12C. VOLSER substitutions in PARMLIB and cataloging with
VOL(******) DEVT(3390) save a LOT of pain. If a DSNAME is changed or
added, we include both the new and old names in the catalog during the
transition and our users are ABSOLUTELY FORBIDDEN from referring to
datasets on the IPL volumes except by name. On rare occaissions, we'll
install an alias for a dataset to make the transition between releases
but since SYSTEMS controls the compile/link procs, we get those updated
as soon as possible to reflect any changes and the dsname aliases go away.
Our management is very inflexible; we are not allowed to make changes
that require the applications staff to change anything. When System
Determined Blocksize became availabe, the SYSTEMS staff had to update
all the procs, both ours and applications', to take advantage of this.
I know, parts of this are short-sighted and overly stupid, but that's
the way it works here.
Rick
----------------------------------------------------------------------
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
