> The drawback to Mike's approach is that your system name changes at your
DR site.
True... but I *like* and *use* the different System_Identifier names!
> That would cause more problems than it would solve for us.
Perhaps, but when it is planned for it can be a huge benefit... (aside
from users knowing that they are running on a D.R. system, and perhaps not
expecting any changes to remain after the test is completed).
The System_Identifier from SYSTEM CONFIG is easily returned from rexx
code:
parse value diag(08,'QUERY USERID') with self . ConfigSysID . '15'x
.
Note: The CMS command "IDENTIFY" returns the nodename from "SYSTEM NETID
S2", not necessarily the same.
This permits service machines to take different code paths when running on
(e.g.) "VMPROD" vs 'RECOVERY" or "VMTEST" (2nd level).
Perhaps during D.R. certain service machines will use different hardware
addresses, not start some applications, or start other ones.
Examples include VTAM, and TCPIP. When those servers come up here, they
read "NODAL CONFIG Y2", and respond accordingly when matching the System
Config System_Identifier (node names have been changed below to be more
obvious):
---<snip>---
* This file is read by various REXX and GCS programs for use in
* normal operations and in disaster recovery both in Lincolnshire and
* at a disaster recovery vendor.
*SysCfgID Svm_Name Dtyp Rdev Comment
* CPC4 LPAR2 as of 20090214
PRODVM VTAM CTCA 0D61 'CTC 0D61 to SYSE, Read1'
PRODVM VTAM CTCA 1D61 'CTC 1D61 to SYSE, Read2'
PRODVM VTAM CTCA 0D62 'CTC 0D62 to SYSE, Write1'
PRODVM VTAM CTCA 1D62 'CTC 1D62 to SYSE, Write2'
PRODVM TCPIP OSA 0140 0140
PRODVM TCPIP OSA 0141 0141
PRODVM TCPIP OSA 0142 0142
* CPC4 LPAR2 as of Feb 2008?
PRODVM VTAM CTCA 0D71 'CTC 0D71 to SYSF, Read1'
PRODVM VTAM CTCA 1D71 'CTC 1D71 to SYSF, Read2'
PRODVM VTAM CTCA 0D72 'CTC 0D72 to SYSF, Write1'
PRODVM VTAM CTCA 1D72 'CTC 1D72 to SYSF, Write2'
PRODVM TCPIP OSA 0140 0140
PRODVM TCPIP OSA 0141 0141
PRODVM TCPIP OSA 0142 0142
* CPC4 LPAR3
TESTVM VTAM CTCA 0C50 'CTC 0C50 to SYSE, Read1'
TESTVM VTAM CTCA 0C51 'CTC 0C51 to SYSE Write1'
* CPC5 LPAR3 as of 20090214
RECOVERY VTAM CTCA 0D61 'CTC 0D61 to SYSE for SNA terminals, Read1'
RECOVERY VTAM CTCA 1D61 'CTC 1D61 to SYSE for SNA terminals, Read2'
RECOVERY VTAM CTCA 0D62 'CTC 0D62 to SYSE for SNA terminals, Write1'
RECOVERY VTAM CTCA 1D62 'CTC 1D62 to SYSE for SNA terminals, Write2'
RECOVERY TCPIP OSA 6051 0140
RECOVERY TCPIP OSA 6052 0141
RECOVERY TCPIP OSA 6053 0142
...
* Updated 20090215 mrw - Add TCPIP OSA support (HA$TCPTX on TCPMAINT 198)
---<snip>---
I prefer that our VM system IPL without any manual changes during a D.R.
test. After all: the sysprogs may have been casualties during the
disaster. OK, we *do* have to install a few product passwords for D.R.
serial numbers, but that is well documented, and pretty minimal (newer
contracts have stricter ISV requirements allowing us to run on any of our
machines).
Hardware differences when running on the bare metal (done when recovering
from our other data center) can be taken care of programmatically in this
manner without requiring manual intervention, and without running VM under
VM (making appropriate directory changes just to get the same device
addresses as prod).
Creating the "NODAL CONFIG Y2" file above meant that when hardware
addresses are changed, I don't have to search all over the place to find
references to those addresses - they are all in one place.
As usual, YMMV. After years of tweaking to speed up our D.R. (more or
less, the Operator IPLs VM from the "recovery" machine, responds to a
prompt from an EXEC called by OPERATOR's "PROFILE EXEC" asking if they
really do want to IPL on a machine with a different serial number. Then
the system comes up automatically adjusting for the processor change and
it's particular hardware addresses and own peculiarities.
During D.R. (after the mirrored and remote-copied DASD has been cut and
the network is up), once we are given the LPAR for VM, the VM IPL takes
the same 7-10 minutes it normally takes, and does not require a VM
sysprog. Of course, we're always standing by in case something breaks,
but this really does take all the "work" out of it at zero-dark-thirty.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"O'Brien, Dennis L" <dennis.l.o'br...@bankofamerica.com>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
07/15/2010 12:06 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Devices OFFLINE at IPL
The drawback to Mike's approach is that your system name changes at your
DR site. That would cause more problems than it would solve for us.
Dennis O'Brien
"If I could not go to heaven but with a [political] party, I would not go
there at all." -- Thomas Jefferson
-----Original Message-----
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Mike Walter
Sent: Thursday, July 15, 2010 08:48
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] Devices OFFLINE at IPL
Yes! Use the "Record Qualifiers" capability of the SYSTEM CONFIG file.
For example:
System_ID 2094 %%1234 PRODVM /* Production system at home */
System_ID 2094 %%5678 RECOVERY /* Planned-for D.R. system */
System_ID 2097 %%9876 DISASTER /* Even worse! */
PRODVM: ,
Devices ,
ONline_at_IPL 0000-0FFF ,
Sensed 0000-0FFF
RECOVERY: ,
Devices ,
ONline_at_IPL 1000-1FFF ,
Sensed 1000-1FFF
DISASTER: ,
Devices ,
ONline_at_IPL 0000-FFFF , /* Something very wrong, get 'em all */
Sensed 0000-FFFF
You can include multiple record qualifiers for each SYSTEM CONFIG
statement, too! E.g.
PRODVM: RECOVERY: ,
Operator_Consoles ,
0700 , /* location here */ ,
0701 , /* location here */ ,
0009 , /* 2nd level test sys */ ,
SYSTEM_3270 , /* HMC Integrated 3270 (SYSG)*/ ,
SYSTEM_CONSOLE /* HMC Linemode console (SYSC)*/
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"clifford jackson" <cliffordjackson...@msn.com>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
07/15/2010 10:24 AM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Devices OFFLINE at IPL
I have a production site and a DR site, the production site is being
mirrored to the DR site same volume labels but different address. In my
system config file I am using the Systems_Identifier with the CPU type,
CPUID and the SystemID, this tell me if I am on the production system or
the DR system, is there a way to add logic to the system config file to
control which DASD I want online and which I vary offline at IPL time,
without customizing the IOCP..
> Date: Wed, 14 Jul 2010 10:26:02 -0500
> From: r...@velocitysoftware.com
> Subject: Re: Devices OFFLINE at IPL
> To: IBMVM@LISTSERV.UARK.EDU
>
> That's one way, as long as the device numbers are never, ever used in
> this VM system. If they are, on the next IPL it will cause a little
> problem.
>
> Another possibility is to have an exec go through the DASD device list
> and vary off the devices based on whether the volume 'belongs' to the VM
> system. 'Ownership' is based on an identifier in the VOLID, eg: VM1RES,
> VM2WK1, etc.
>
> On 07/14/2010 10:11 AM, Billy Bingham wrote:
> >
> >
> > Would the following be the proper way to specify devices, in the
> > SYSTEM CONFIG file, that I don't want to come online at an IPL:
> >
> >
> > Devices ,
> > Online_at_IPL 0000-FFFF,
> > Sensed 0000-FFFF,
> > Offline_at_IPL 0500-050F
> >
> >
> >
> > Thanks,
> >
> > Billy
>
>
> --
> Rich Smrcina
> Phone: 414-491-6001
> http://www.linkedin.com/in/richsmrcina
>
> Catch the WAVV! http://www.wavv.org
> WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
The New Busy is not the too busy. Combine all your e-mail accounts with
Hotmail. Get busy.
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.
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.
