Jim,
Check out SC24-6098-02 (z/VM Group Control System) Appendix A (Tailoring
and Building the GCS Nucleus) - subsection headed, "Creating a New GCS
Nucleus Build List". Items 7 and 8 at the bottom of page 544 through to
the top of Page 547) are what you need.
It's terse to the point of incomprehensibility unless you have prior
experience of nucleus addressing in a VM context (something which,
nowadays, fewer and fewer people have need of) but this is definitely
your, "official reference point".
Essentially, what you need to do is to widen the gaps between GCALP and
GCTZET (to expand Low Common Storage), and/or between GCTBHC and GCTEHC
(to expand High Common Storage) by changing / replacing the SLC ("Set
Location Counter") files referenced by the load list.
It's these, "gaps" which define the amount of Low/High Common Storage
("CSA" in z/OS parlance) available to a particular GCS group and it's thi
s
Common Storage which is used by VTAM (and any other app which needs to
share storage between separate tasks running in the group). As you're
carrying forward an existing update I'll assume that you can work out how
much increase you need by referring back to your previous system but, if
not, then ask again and maybe somebody a bit more current than I am on
VTAM will be able to offer some pointers.
The precise mechanics of WHAT to do are (IMV) fairly well-described in th
e
manual (albeit without any real explanation as to WHY) but if you want to
explore the background to this further - or have other questions - then
please say so and I'll try (no doubt along with others) to expand on the
above and clarify what's going on.
Don't forget to put in your notes that the GCS NSS definitions (DEFNSS
stuff) need to be reviewed / adjusted to match with whatever locations ar
e
used by the loadlist or you'll end up building a new nucleus in storage
and then saving the wrong stuff into the NSS - a practice that can be the
source of some serious head-scratching until the penny (dime?) drops ...
Regards
Jeff Gribbin
