Mike, that's an excellent (and colorful) explanation and works really well if you are doing 2 sites in different places (or lpars). I think Mary Anne is looking at the same problem I am now. We have primary and then another site that is both disaster test and real disaster site. So the secondary LPAR (disaster recovery sometimes / disaster recovery test other times)( with its same CPUID & same LPAR name have to play two roles (so we have 3 sets of IP addressing needs - 3 sets of tcp config files and linux that needs to figure out which IP and hostname to play as...). I don't see a way around it without 2 SYSTEM CONFIG files that we'll have to automate keeping in sync (or zap pre-disaster IPL) and not depend on the sysprog to remember both ... and provide operations special instructions for real disaster vs. test disaster... I don't think we can do it all in one file.... I don't suppose one could change the SYSTEM_IDENTIFIER with a command... If we have the time.. our starter system can zap the config file to be the right thing.. but as we move to full mirroring.. we'd like to have it all automagical because the goal there is little to no time... I think i need an environment variable for CP :) (must be CP for linux to figure out its role). Marcy Cortes
"This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." _____ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, October 03, 2007 11:12 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] D/R Code You actually already have what you need, perhaps just not enough experience with z/VM yet to use it to best advantage. >From a session that I've presented at SHARE called "z/VM Installation - It's Installed, NOW What?" ---<snip>--- <Slide 43:> * We'll go though "Record Qualifiers" quickly as it could be consider an "advanced" topic. * But they are: * an important capability * is not obvious * and can be difficult to understand without an example... <Slide 43 Notes Page:> "Record Qualifiers" are the "System_Identifier"s used to limit the scope of the definitions which follow later in the SYSTEM CONFIG. <Slide 44:> * %% are wildcards, very important when running in an LPAR * yournode is returned by the command: CP QUERY USERID * E.g. JQPUBLIC AT BIGBLUE * Using REXX: parse value diag(08,'QUERY USERID') with self . ConfigSysID '15'x . * Not to be confused by CMS command "IDENTIFY", which comes from the 'nodeid' defined in the "SYSTEM NETID S" file. * If you have other CPUs AT YOUR SITE upon which you might recover. * So your system EXECs can act differently at a Disaster Recovery site (and users can tell, too). <Slide 44 Notes page:> See slide "SYSTEM NETID S2" later to understand the importance of LPAR number. In these examples "yournode", "RECOVERY", and "DISASTER" (based on matching CPU serial numbers) are arbitrary "System_Identifier"s, which will appear at the bottom right corner of logged on terminal, and can be displayed in response to the command "CP QUERY USERID". The "System_Identifier"s are also used to great advantage below this point in the "SYSTEM CONFIG" file. ---<snip>--- Note that the "CP QUERY USERID" returns the "SYSTEM_IDENTIFIER" from the matching CPUID in the "SYSTEM CONFIG" file and this is value displayed in the lower-right hand corner of your terminal, whereas the CMS command "IDENTIFY" returns the node ID from the matching CPUID in the "SYSTEM NETID S" file. That's a small, but important distinction when attempting to automate server startup. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Mary Anne Matyaz" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 10/03/2007 08:29 AM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject D/R Code Hello all. I need a few lines of code for a D/R situation. I need to know, in VM and Linux, if we are in a real D/R or in a test D/R. My plan is to default to a real D/R situation, then, if it's a test, execute a command from operator that asks if it is a test, and if so, place a variable somewhere, shutdown the linuxes and tcp/ip, make my necessary changes to point to different startups (primarily for IP addresses), and bring them up again. What I need is how to put the variable somewhere that other users can then access it... TIA for any insight/thoughts, etc... Mary Anne _____ 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. Emails 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 email.
