One of perhaps many possibilities:
Include in the 2nd level userid directory entry something like:
CPU 00 CPUID 00DEAF
(where "00DEAF" can be any hexadecimal cpu serial number, I just like
"DEAF" because it's "DEAF to the world". You your heximagination).
Let's use an example of your production system having the real Serial
Number: 011234
and your 2nd level system using virtual serial number: 00DEAF
Remember: if you IPL your 2nd level sysres on the real HMC, it will come
up using PRODVM records below. Be careful to not IPL your 2nd level
system as the 1st level machine without careful consideration.
In *ONE SINGLE* "SYSTEM CONFIG", you can include "Record Qualifiers"
before each statement that required for the production, or 2nd level
statements.
In SYSTEM CONFIG you could include:
System_ID 2097 %%1234 PRODVM /* Production VM System */
System_ID 2097 %%DEAF 2NDLEVEL /* 2nd level VM system */
(the '%' is a single-character wild-card, allowing the CPUID match in any
LPAR)
The 4th words above (PRODVM or 2NDLEVEL) will display in the lower
right-hand corner of your 3270 terminals. It is also displayed in
response to "CP QUERY USERID", which makes it handy when writing EXECs
that work differently when running on each system:
cp query userid
OPERATOR AT PRODVM
or
cp query userid
M2WALTER AT 2NDLEVEL
In rexx, access that with command:
parse value diag(08,'QUERY USERID') with self . ConfigSysID . '15'x .
If ConfigSysID='PRODVM"
then do your production stuff...
else do your 2ndlevel stuff...
If you wish, you may include specific CONFIG file statements contained in
other files on the CFn disk. I dislike doing so because it makes it
harder to see everything in one place, but there can be reasons to do so:
PRODVM: IMBED PRODVM IMBED
2NDLEVEL: IMBED 2NDLEVEL IMBED
There are lots of SYSTEM CONFIG statements that are particular for
specific systems, for example:
PRODVM: System_Residence,
Checkpoint Volid VMR54A From CYL 21 For 9 ,
Warmstart Volid VMR54A From CYL 30 For 9
2NDLEVEL System_Residence,
Checkpoint Volid VTR54A From CYL 21 For 9 ,
Warmstart Volid VTR54A From CYL 30 For 9
PRODVM: CP_Owned Slot 1 VMSP01 OWN
2NDLEVEL: CP_Owned Slot 1 VTSP01 OWN
PRODVM: CP_Owned Slot 2 VMSP02 OWN
2NDLEVEL: CP_Owned Slot 2 VTSP02 OWN
CP_Owned Slot 3 RESERVED
CP_Owned Slot 4 RESERVED
CP_Owned Slot 5 RESERVED
Multiple record qualifiers can be included for any statement, e.g.:
PRODVM: 2NDLEVEL: some_config_statement needed on only those two systems
but not others.
All statements without a "record qualifiers" work as they do now - they
apply to all systems using this "SYSTEM CONFIG".
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"Collinson.Shannon" <shannon.collin...@suntrust.com>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
02/23/2010 12:49 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
is there a way to automatically select a certain system config based on
second level vs. first level ipls?
We?d like to be able to switch between two sets of ipl-volumes (respack +
spool + paging, I?d guess) to be able to switch between releases of the
operating system. Of course, we?d hopefully only go ?one-way?, but we?d
want the ability to swap back. I was thinking we could set up the system
config on each respack?s CF1 disk to kind of exclude the other respack?s
volumes, and then we were thinking of using the system config on CF2 as a
stripped-down ?second level? version, but it occurs to me (not quite
understanding VM maintenance all that much) that a put2prod command might
copy that stripped down system config over and screw us again. I?d love
to be able to use SYSTEM CONFIG if it?s getting started from a regular HMC
IPL, and maybe something like SYSTEM CONFIG2 if it?s second-level. Keeping
the main SYSTEM CONFIG in synch between the primary and alternate packs
will be fun enough without us having to wipe them out each time we test.
Is there any way for us to do that?perhaps a VM trick that we missed
because we read the wrong manual? Or is this just a really bad idea?one
only a z/OS sysprog would try?
Thanks!
Shannon Collinson
Systems Programmer, Mainframe Operating Systems
SunTrust Banks, Inc.
Mail Code GA-ATL-4030
250 Piedmont Ave. NE, Suite 1600
Atlanta, GA 30308
Tel: 404.827.6070 Mobile: 404.642.1280
Fax: 404.581.1688
shannon.collin...@suntrust.com
Live Solid. Bank Solid.
LEGAL DISCLAIMER
The information transmitted is intended solely for the individual or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or other
use of or taking action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you have
received this email in error please contact the sender and delete the
material from any computer.
SunTrust is a federally registered service mark of SunTrust Banks, Inc.
Live Solid. Bank Solid. is a service mark of SunTrust Banks, Inc.
[ST:XCL]
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient is strictly prohibited. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
