The SYSTEM CONFIG file can have several CPUIDs specified, and can then be
sectioned off based on the system name associated with the CPUID.
Specifically, you get to specify the CP Owned volumes, so you have two
separate lists; one for SYSA and another for SYSB. In our case, we move the
CP Directory to another volume for each system, so the RES pack is shared by
both running systems. You can section the definition of the warm and ckpt
data, so they can be on different cylinders on RES for each system. Most of
the rest of the RES pack can be shared. R/W minidisks needed by both systems
can be handled with SYSAFFIN in the CP Directory.
Be sure that your CP Owned packs use different slots in the list; have the
first six slots be for SYSA and the second six be for SYSB. This puts you in
a very nice position to implement CSE, should you choose to do so.
AUTOLOG1 can decide what system it is on by various means, and can bring up
the necessary guests and service machines for that system.
TCPIP will bring up a configuration based on what system it is running on.
For service machines that don¹t play well in a shared environment, there¹s
SYSAFFIN in the CP Directory. DirMaint makes it easy to maintain the CP
Directory in sync on both systems.
So my suggestion would be, rather than copying the RES pack for the second
system, share the first.
It takes some planning, and a lot of beer, but you can run two systems with
one head (er... RES), given some forethought.
--
.~. Robert P. Nix Mayo Foundation
/V\ RO-OC-1-13 200 First Street SW
/ ( ) \ 507-284-0844 Rochester, MN 55905
^^-^^ -----
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
> From: Alan Altmark <[EMAIL PROTECTED]>
> Reply-To: The IBM z/VM Operating System <[email protected]>
> Date: Thu, 25 Jan 2007 10:44:37 -0500
> To: <[email protected]>
> Subject: Re: autolog profile exec logic
>
> On Thursday, 01/25/2007 at 08:34 CST, Mary Anne Link
> <[EMAIL PROTECTED]> wrote:
>> We are trying to get to a
>> point where we can quickly copy the res pack to other systems, and,
> based on
>> the system config fn specified on salipl, ipl a copy of that res pack to
>> bring up different systems.
>
> You want to be a bit careful with IDENTIFY. The value it returns is based
> on CPUID and SYSTEM NETID. If the CPU id is not present in SYSTEM NETID,
> it will return the System_Identifier from SYSTEM CONFIG. So if you're
> going get IDENTIFY to change what it returns based on the fn on salipl,
> you can't use SYSTEM NETID. If you don't use RSCS, no big deal, but if
> you do, then you'll need to play games with SET CPUID and SYSTEM NETID for
> the users who need RSCS. (With no matching entry in SYSTEM NETID,
> IDENTIFY will return "VIA *"; SENDFILE, etc. won't work correctly.)
>
>> Also, aside from system config, the tcpip files (which use system name),
> the
>> autologs, and having to keep all users in the user direct, can anyone
> think
>> of any snags in my plan?
>
> Copying the res pack (IPL volume w/PARM disk and directory) to another
> system is fine, but what are you doing for the remaining volumes that
> comprise the system?
>
> Alan Altmark
> z/VM Development
> IBM Endicott
