Re: D/R Code

[Phil Smith III]

Mike Walter <[EMAIL PROTECTED]> wrote:
>IMHO, such a command needs to be set in many ways, including but not 
>limited to:
>- Permit it to be set as an authorized/restricted CP command (perhaps 
>permitting a limited number of Privclass G "SET" commands for apps to 
>use?)
>- Permit it to be set by the SYSTEM CONFIG file (perhaps based on CPUID 
>via SYSTEM_IDENTIFIER)
>- Permit it to be set by SALIPL screen
>- Permit it to be set by as a LOADPARM from the CP IPL command
>- Permit it to be set as a LOADPARM by CP SHUTDOWN REIPL

It doesn't meet all of these, but SET PRODUCT can be (ab)used to do most of 
this...

...phsiii

Re: D/R Code

[Fran Hensler]

Robert -

No, it's not a lot of work. it's all automatic thru one EXEC on
AUTOLOG1.  No manual intervention of any kind.

My DR FLEX-ES system has the same serial number as my production
system so checking the CPUID is not an option.

/Fran
-
On Fri, 5 Oct 2007 07:54:08 -0500 Robert P. Nix said:
>That seems a lot of work, when you could just ask the system who it is, and
>set the system's name based on its serial number.
>
>On the TCPIP front, again, you can just have two config files w/ the system
>name as the FN, and be done with it. No editing at startup.
>
>--
>   .~.Robert P. Nix Mayo Foundation
>   /V\RO-OE-5-55200 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."
>
>
>
>
>
>On 10/4/07 5:04 PM, "Fran Hensler" <[EMAIL PROTECTED]> wrote:
>
>> We have two FLEX-ES systems on opposite ends of the campus.
>>
>> The DR system does not have as many tape drives as the production
>> system.  The production system has a drive at 0591 but the DR system
>> does not.
>>
>> In the AUTOLOG1 DIRECT I haveDEDICATE 0591 0591
>>
>> When AUTOLOG1 starts up it does a   CP Q V 0591   and if it doesn't
>> exist I know I am on the DR machine.
>>
>> AUOTLOG1 also has write access to TCPMAINTs 198 disk.  If I am not
>> on the production machine then an EXEC on AUTOLOG1 changes the IP
>> address in PROFILE TCPIP, DETACHES 198 and then AUTOLOGs TCPIP.
>>
>> If 0591 exists I know I am on the production machine so I just DETACH
>> it and continue with the production startup.
>>
>> /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years
>>  [EMAIL PROTECTED] +1.724.738.2153
>> "Yes, Virginia, there is a Slippery Rock"

Re: D/R Code

[Stracka, James (GTI)]

Wow, the UPSI switch in DOS JCL!  I have not used that since 1976.  That
brings back some memories.  Thanks

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, October 05, 2007 9:50 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: D/R Code



How about a "CP SET/QUERY UPSI" like they have in DOS :-)   
  




"Huegel, Thomas" <[EMAIL PROTECTED]> 
Sent by: The IBM z/VM Operating System  

10/05/2007 09:43 AM 
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU 
cc
Subject
Re: D/R Code







Personally I like the idea of being able set a CP system
variable. CP SET SYSTEM VARIABLE 'variable name' 'variable data'. 
That way each installation could easily customize how they
wanted to use the variables. Maybe even allow x-system variables.   
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of Mary Anne Matyaz
Sent: Friday, October 05, 2007 8:36 AM
    To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: D/R Code

We run a lot of things off of the system name, so it needs to be
the same, whether we are on processor A, processor B as real dr or
processor B as test DR. 
MA

On 10/5/07, RPN01 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote: 
That seems a lot of work, when you could just ask the system who
it is, and
set the system's name based on its serial number.

On the TCPIP front, again, you can just have two config files w/
the system
name as the FN, and be done with it. No editing at startup. 

--
  .~.Robert P. Nix Mayo Foundation
  /V\RO-OE-5-55200 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."





On 10/4/07 5:04 PM, "Fran Hensler" <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:

> We have two FLEX-ES systems on opposite ends of the campus. 
>
> The DR system does not have as many tape drives as the
production
> system.  The production system has a drive at 0591 but the DR
system
> does not.
>
> In the AUTOLOG1 DIRECT I haveDEDICATE 0591 0591 
>
> When AUTOLOG1 starts up it does a   CP Q V 0591   and if it
doesn't
> exist I know I am on the DR machine.
>
> AUOTLOG1 also has write access to TCPMAINTs 198 disk.  If I am
not
> on the production machine then an EXEC on AUTOLOG1 changes the
IP 
> address in PROFILE TCPIP, DETACHES 198 and then AUTOLOGs
TCPIP.
>
> If 0591 exists I know I am on the production machine so I just
DETACH
> it and continue with the production startup.
>
> /Fran Hensler at Slippery Rock University of Pennsylvania USA
for 44 years
>  [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
+1.724.738.2153
> "Yes, Virginia, there is a Slippery Rock" 



  _  

<< ella for Spam Control >> has removed 13244 VSE-List messages and set
aside 12637 VM-List for me
You can use it too - and it's FREE!  www.ellaforspam.com
<http://www.ellaforspam.com/>


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.

Re: D/R Code

[Mike Walter]

IMHO, such a command needs to be set in many ways, including but not 
limited to:
- Permit it to be set as an authorized/restricted CP command (perhaps 
permitting a limited number of Privclass G "SET" commands for apps to 
use?)
- Permit it to be set by the SYSTEM CONFIG file (perhaps based on CPUID 
via SYSTEM_IDENTIFIER)
- Permit it to be set by SALIPL screen
- Permit it to be set by as a LOADPARM from the CP IPL command
- Permit it to be set as a LOADPARM by CP SHUTDOWN REIPL

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.



"Stracka, James (GTI)" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" 
10/05/2007 08:49 AM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: D/R Code






Great, but you would like that to be set automatically somehow, not 
manually after each IPL.
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On 
Behalf Of Huegel, Thomas
Sent: Friday, October 05, 2007 9:43 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: D/R Code

Personally I like the idea of being able set a CP system variable. CP SET 
SYSTEM VARIABLE 'variable name' 'variable data'.
That way each installation could easily customize how they wanted to use 
the variables. Maybe even allow x-system variables. 
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
Behalf Of Mary Anne Matyaz
Sent: Friday, October 05, 2007 8:36 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: D/R Code

We run a lot of things off of the system name, so it needs to be the same, 
whether we are on processor A, processor B as real dr or processor B as 
test DR. 
MA

On 10/5/07, RPN01 <[EMAIL PROTECTED]> wrote: 
That seems a lot of work, when you could just ask the system who it is, 
and
set the system's name based on its serial number.

On the TCPIP front, again, you can just have two config files w/ the 
system
name as the FN, and be done with it. No editing at startup. 

--
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55200 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."





On 10/4/07 5:04 PM, "Fran Hensler" <[EMAIL PROTECTED]> wrote:

> We have two FLEX-ES systems on opposite ends of the campus. 
>
> The DR system does not have as many tape drives as the production
> system.  The production system has a drive at 0591 but the DR system
> does not.
>
> In the AUTOLOG1 DIRECT I haveDEDICATE 0591 0591 
>
> When AUTOLOG1 starts up it does a   CP Q V 0591   and if it doesn't
> exist I know I am on the DR machine.
>
> AUOTLOG1 also has write access to TCPMAINTs 198 disk.  If I am not
> on the production machine then an EXEC on AUTOLOG1 changes the IP 
> address in PROFILE TCPIP, DETACHES 198 and then AUTOLOGs TCPIP.
>
> If 0591 exists I know I am on the production machine so I just DETACH
> it and continue with the production startup.
>
> /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 
years
>  [EMAIL PROTECTED] +1.724.738.2153
> "Yes, Virginia, there is a Slippery Rock" 



<< ella for Spam Control >> has removed 13244 VSE-List messages and set 
aside 12637 VM-List for me
You can use it too - and it's FREE!  www.ellaforspam.com

This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically 
indicated, this message is not an offer to sell or a solicitation of any 
investment products or other financial product or service, an official 
confirmation of any transaction, or an official statement of Merrill 
Lynch. Subject to applicable law, Merrill Lynch may monitor, review and 
retain e-communications (EC) traveling through its networks/systems. The 
laws of the country of each sender/recipient may impact the handling of 
EC, and EC may be archived, supervised and produced in countries other 
than the country in which you are located. This message cannot be 
guaranteed to be secure or error-free. This message is subject to terms 
available at the following link: http://www.ml.com/e-communications_terms/
. By messaging with Merrill Lynch you consent to the foregoing.

 

 
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

Re: D/R Code

[Rob van der Heij]

Following this thread, it looks like I am the only one who has
concerns about code in the system that will distinguish between
production, DR (and maybe even DR test). Most certainly you want such
checks only in your own code (which has no errors and does not need
testing) and not in the code that application folks write ;-)
Otherwise ugly things might happen when you need to move the system to
a new machine or so.

When I was involved with this, I tried very hard to make people use
functional checks only. So if your application needs to connect to
TCPIP, check for TCPIP being present and not whether you're in a
situation where TCPIP should not be present (assuming something
else will arrange to run the alternate stack that prevents the real
network to come up in D/R testing). But I think I lost that
eventually, and we settled on something in the LOGMSG iirc.

Rob

Re: D/R Code

[Thomas Kern]

I don't think this would be for application level usage but only for syst
em
initialaztion, SVM configuration, etc, before real users/apps get started
. 

I don't know if I would want a SAS covering exec to query a system variab
le
to see if it should run, but a SAS SVM should check its PRODUCT
enable/disable values. 

/Tom Kern
/301-903-2211

On Fri, 5 Oct 2007 16:29:36 +0200, Rob van der Heij <[EMAIL PROTECTED]> w
rote:

>Following this thread, it looks like I am the only one who has
>concerns about code in the system that will distinguish between
>production, DR (and maybe even DR test). Most certainly you want such
>checks only in your own code (which has no errors and does not need
>testing) and not in the code that application folks write ;-)
>Otherwise ugly things might happen when you need to move the system to
>a new machine or so.
>
>When I was involved with this, I tried very hard to make people use
>functional checks only. So if your application needs to connect to
>TCPIP, check for TCPIP being present and not whether you're in a
>situation where TCPIP should not be present (assuming something
>else will arrange to run the alternate stack that prevents the real
>network to come up in D/R testing). But I think I lost that
>eventually, and we settled on something in the LOGMSG iirc.
>
>Rob
>
=

Re: D/R Code

[Thomas Kern]

Any CP environment variable system needs to be initialized during system
IPL. A new SYSTEM CONFIG entry would be needed for initial variable names

and values. Again arbirary names with arbitrary string values. Through th
e
current SYSTEM CONFIG syntax, you could have different settings based on
different CPUID's. The benefit over the current situation would be that y
ou
could have a whole set of variables set rather than just one GATEWAY name
.
So for your home production system you could have settings for variables 
A B
C D E, and for your home test system have the same values for A B, with
different values for C D E. At your DR TEST site, you could have just a
value for A that indicates some DR scenario, and your OPERATOR profile co
uld
inspect A and ask the operator if this is a DR TEST or a real DR and set
values for B C D E appropriately. All other SVMs, inpsect the value that
they use, if it doesn't exist, exit, if it does exist, do whatever.

/Tom Kern
/301-903-2211


On Fri, 5 Oct 2007 09:49:38 -0400, Stracka, James (GTI)
<[EMAIL PROTECTED]> wrote:

>Great, but you would like that to be set automatically somehow, not
>manually after each IPL.
>
>   -Original Message-
>   From: The IBM z/VM Operating System
>   Subject: Re: D/R Code

>   Personally I like the idea of being able set a CP system
>variable. CP SET SYSTEM VARIABLE 'variable name' 'variable data'.
>   That way each installation could easily customize how they
>wanted to use the variables. Maybe even allow x-system variables.  
>

Re: D/R Code

[pfa]

How about a "CP SET/QUERY UPSI" like they have in DOS :-) 
 




"Huegel, Thomas" <[EMAIL PROTECTED]> 
Sent by: The IBM z/VM Operating System 
10/05/2007 09:43 AM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: D/R Code







Personally I like the idea of being able set a CP system variable. CP SET 
SYSTEM VARIABLE 'variable name' 'variable data'.
That way each installation could easily customize how they wanted to use 
the variables. Maybe even allow x-system variables. 
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
Behalf Of Mary Anne Matyaz
Sent: Friday, October 05, 2007 8:36 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: D/R Code

We run a lot of things off of the system name, so it needs to be the same, 
whether we are on processor A, processor B as real dr or processor B as 
test DR. 
MA

On 10/5/07, RPN01 <[EMAIL PROTECTED]> wrote: 
That seems a lot of work, when you could just ask the system who it is, 
and
set the system's name based on its serial number.

On the TCPIP front, again, you can just have two config files w/ the 
system
name as the FN, and be done with it. No editing at startup. 

--
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55200 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."





On 10/4/07 5:04 PM, "Fran Hensler" <[EMAIL PROTECTED]> wrote:

> We have two FLEX-ES systems on opposite ends of the campus. 
>
> The DR system does not have as many tape drives as the production
> system.  The production system has a drive at 0591 but the DR system
> does not.
>
> In the AUTOLOG1 DIRECT I haveDEDICATE 0591 0591 
>
> When AUTOLOG1 starts up it does a   CP Q V 0591   and if it doesn't
> exist I know I am on the DR machine.
>
> AUOTLOG1 also has write access to TCPMAINTs 198 disk.  If I am not
> on the production machine then an EXEC on AUTOLOG1 changes the IP 
> address in PROFILE TCPIP, DETACHES 198 and then AUTOLOGs TCPIP.
>
> If 0591 exists I know I am on the production machine so I just DETACH
> it and continue with the production startup.
>
> /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 
years
>  [EMAIL PROTECTED] +1.724.738.2153
> "Yes, Virginia, there is a Slippery Rock" 



<< ella for Spam Control >> has removed 13244 VSE-List messages and set 
aside 12637 VM-List for me
You can use it too - and it's FREE!  www.ellaforspam.com

Re: D/R Code

[Stracka, James (GTI)]

Great, but you would like that to be set automatically somehow, not
manually after each IPL.

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas
Sent: Friday, October 05, 2007 9:43 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: D/R Code


Personally I like the idea of being able set a CP system
variable. CP SET SYSTEM VARIABLE 'variable name' 'variable data'.
That way each installation could easily customize how they
wanted to use the variables. Maybe even allow x-system variables.  

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of Mary Anne Matyaz
Sent: Friday, October 05, 2007 8:36 AM
To: IBMVM@LISTSERV.UARK.EDU
            Subject: Re: D/R Code


We run a lot of things off of the system name, so it
needs to be the same, whether we are on processor A, processor B as real
dr or processor B as test DR. 
MA


On 10/5/07, RPN01 <[EMAIL PROTECTED]> wrote: 

That seems a lot of work, when you could just
ask the system who it is, and
set the system's name based on its serial
number.

On the TCPIP front, again, you can just have two
config files w/ the system
name as the FN, and be done with it. No editing
at startup. 

--
   .~.Robert P. Nix Mayo
Foundation
   /V\RO-OE-5-55200 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."





On 10/4/07 5:04 PM, "Fran Hensler"
<[EMAIL PROTECTED]> wrote:

> We have two FLEX-ES systems on opposite ends
of the campus. 
>
> The DR system does not have as many tape
drives as the production
> system.  The production system has a drive at
0591 but the DR system
> does not.
>
> In the AUTOLOG1 DIRECT I haveDEDICATE 0591
0591 
>
> When AUTOLOG1 starts up it does a   CP Q V
0591   and if it doesn't
> exist I know I am on the DR machine.
>
> AUOTLOG1 also has write access to TCPMAINTs
198 disk.  If I am not
> on the production machine then an EXEC on
AUTOLOG1 changes the IP 
> address in PROFILE TCPIP, DETACHES 198 and
then AUTOLOGs TCPIP.
>
> If 0591 exists I know I am on the production
machine so I just DETACH
> it and continue with the production startup.
>
> /Fran Hensler at Slippery Rock University of
Pennsylvania USA for 44 years
>  [EMAIL PROTECTED]
+1.724.738.2153
> "Yes, Virginia, there is a Slippery
Rock" 




  _  

<< ella for Spam Control >> has removed 13244 VSE-List messages and set
aside 12637 VM-List for me
You can use it too - and it's FREE!  www.ellaforspam.com


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.

Re: D/R Code

[Stracka, James (GTI)]

That is why we have our users run an exec that tests the CPUID and
System Configuration file name.  You need to distinguish among:  Normal
production, Test CNR and Production CNR.  We want it to be completely
automated once the system is IPLed.

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mary Anne Matyaz
Sent: Friday, October 05, 2007 9:36 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: D/R Code


We run a lot of things off of the system name, so it needs to be
the same, whether we are on processor A, processor B as real dr or
processor B as test DR. 
MA


On 10/5/07, RPN01 <[EMAIL PROTECTED]> wrote: 

That seems a lot of work, when you could just ask the
system who it is, and
set the system's name based on its serial number.

On the TCPIP front, again, you can just have two config
files w/ the system
name as the FN, and be done with it. No editing at
startup. 

--
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55200 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."





On 10/4/07 5:04 PM, "Fran Hensler" <[EMAIL PROTECTED]>
wrote:

> We have two FLEX-ES systems on opposite ends of the
campus. 
>
> The DR system does not have as many tape drives as the
production
> system.  The production system has a drive at 0591 but
the DR system
> does not.
>
> In the AUTOLOG1 DIRECT I haveDEDICATE 0591 0591 
>
> When AUTOLOG1 starts up it does a   CP Q V 0591   and
if it doesn't
> exist I know I am on the DR machine.
>
> AUOTLOG1 also has write access to TCPMAINTs 198 disk.
If I am not
> on the production machine then an EXEC on AUTOLOG1
changes the IP 
> address in PROFILE TCPIP, DETACHES 198 and then
AUTOLOGs TCPIP.
>
> If 0591 exists I know I am on the production machine
so I just DETACH
> it and continue with the production startup.
>
> /Fran Hensler at Slippery Rock University of
Pennsylvania USA for 44 years
>  [EMAIL PROTECTED] +1.724.738.2153
> "Yes, Virginia, there is a Slippery Rock"


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.

Re: D/R Code

[Huegel, Thomas]

Personally I like the idea of being able set a CP system variable. CP SET
SYSTEM VARIABLE 'variable name' 'variable data'.
That way each installation could easily customize how they wanted to use the
variables. Maybe even allow x-system variables.  

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Mary Anne Matyaz
Sent: Friday, October 05, 2007 8:36 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: D/R Code


We run a lot of things off of the system name, so it needs to be the same,
whether we are on processor A, processor B as real dr or processor B as test
DR. 
MA


On 10/5/07, RPN01 < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >
wrote: 

That seems a lot of work, when you could just ask the system who it is, and
set the system's name based on its serial number.

On the TCPIP front, again, you can just have two config files w/ the system
name as the FN, and be done with it. No editing at startup. 

--
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55200 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."





On 10/4/07 5:04 PM, "Fran Hensler" < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:

> We have two FLEX-ES systems on opposite ends of the campus. 
>
> The DR system does not have as many tape drives as the production
> system.  The production system has a drive at 0591 but the DR system
> does not.
>
> In the AUTOLOG1 DIRECT I haveDEDICATE 0591 0591 
>
> When AUTOLOG1 starts up it does a   CP Q V 0591   and if it doesn't
> exist I know I am on the DR machine.
>
> AUOTLOG1 also has write access to TCPMAINTs 198 disk.  If I am not
> on the production machine then an EXEC on AUTOLOG1 changes the IP 
> address in PROFILE TCPIP, DETACHES 198 and then AUTOLOGs TCPIP.
>
> If 0591 exists I know I am on the production machine so I just DETACH
> it and continue with the production startup.
>
> /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years
>   [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
+1.724.738.2153
> "Yes, Virginia, there is a Slippery Rock" 




  _  

<< ella for Spam Control >> has removed 13244 VSE-List messages and set
aside 12637 VM-List for me
You can use it too - and it's FREE!   www.ellaforspam.com
<http://www.ellaforspam.com>

Re: D/R Code

[Mary Anne Matyaz]

We run a lot of things off of the system name, so it needs to be the same,
whether we are on processor A, processor B as real dr or processor B as test
DR.
MA

On 10/5/07, RPN01 <[EMAIL PROTECTED]> wrote:
>
> That seems a lot of work, when you could just ask the system who it is,
> and
> set the system's name based on its serial number.
>
> On the TCPIP front, again, you can just have two config files w/ the
> system
> name as the FN, and be done with it. No editing at startup.
>
> --
>.~.Robert P. Nix Mayo Foundation
>/V\RO-OE-5-55200 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."
>
>
>
>
>
> On 10/4/07 5:04 PM, "Fran Hensler" <[EMAIL PROTECTED]> wrote:
>
> > We have two FLEX-ES systems on opposite ends of the campus.
> >
> > The DR system does not have as many tape drives as the production
> > system.  The production system has a drive at 0591 but the DR system
> > does not.
> >
> > In the AUTOLOG1 DIRECT I haveDEDICATE 0591 0591
> >
> > When AUTOLOG1 starts up it does a   CP Q V 0591   and if it doesn't
> > exist I know I am on the DR machine.
> >
> > AUOTLOG1 also has write access to TCPMAINTs 198 disk.  If I am not
> > on the production machine then an EXEC on AUTOLOG1 changes the IP
> > address in PROFILE TCPIP, DETACHES 198 and then AUTOLOGs TCPIP.
> >
> > If 0591 exists I know I am on the production machine so I just DETACH
> > it and continue with the production startup.
> >
> > /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44
> years
> >  [EMAIL PROTECTED] +1.724.738.2153
> > "Yes, Virginia, there is a Slippery Rock"
>

Re: D/R Code

[RPN01]

That seems a lot of work, when you could just ask the system who it is, and
set the system's name based on its serial number.

On the TCPIP front, again, you can just have two config files w/ the system
name as the FN, and be done with it. No editing at startup.

-- 
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55200 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."





On 10/4/07 5:04 PM, "Fran Hensler" <[EMAIL PROTECTED]> wrote:

> We have two FLEX-ES systems on opposite ends of the campus.
> 
> The DR system does not have as many tape drives as the production
> system.  The production system has a drive at 0591 but the DR system
> does not.
> 
> In the AUTOLOG1 DIRECT I haveDEDICATE 0591 0591
> 
> When AUTOLOG1 starts up it does a   CP Q V 0591   and if it doesn't
> exist I know I am on the DR machine.
> 
> AUOTLOG1 also has write access to TCPMAINTs 198 disk.  If I am not
> on the production machine then an EXEC on AUTOLOG1 changes the IP
> address in PROFILE TCPIP, DETACHES 198 and then AUTOLOGs TCPIP.
> 
> If 0591 exists I know I am on the production machine so I just DETACH
> it and continue with the production startup.
> 
> /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years
>  [EMAIL PROTECTED] +1.724.738.2153
> "Yes, Virginia, there is a Slippery Rock"

Re: D/R Code

[Fran Hensler]

We have two FLEX-ES systems on opposite ends of the campus.

The DR system does not have as many tape drives as the production
system.  The production system has a drive at 0591 but the DR system
does not.

In the AUTOLOG1 DIRECT I haveDEDICATE 0591 0591

When AUTOLOG1 starts up it does a   CP Q V 0591   and if it doesn't
exist I know I am on the DR machine.

AUOTLOG1 also has write access to TCPMAINTs 198 disk.  If I am not
on the production machine then an EXEC on AUTOLOG1 changes the IP
address in PROFILE TCPIP, DETACHES 198 and then AUTOLOGs TCPIP.

If 0591 exists I know I am on the production machine so I just DETACH
it and continue with the production startup.

/Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years
 [EMAIL PROTECTED] +1.724.738.2153
"Yes, Virginia, there is a Slippery Rock"

Re: D/R Code

[Alan Altmark]

On Thursday, 10/04/2007 at 12:55 EDT, Thomas Kern <[EMAIL PROTECTED]> 
wrote:
> I also hope that IBM (Chuckie in particular) will not frown upon us 
using
> the SET PRODUCT commands for enabling/disabling customer functions.

Chuckie will not frown.  He's not aware of any "IBM use only" admonitions.

> Maybe if the documentation (unoffical fiction as it is) were to make its 
way
> into some customer's hands, a requirement could be written that matches
> fairly well and then be submitted to the appropriate User Groups.

I would rather the community come to its own conclusions as to what is 
needed, rather than using something the elves wrote.

Alan Altmark
z/VM Development
IBM Endicott

Re: D/R Code

[Arty Ecock]

Hi,

   I believe CERN had an implementation of CP Global variables (perhaps some of
 Dick Newson's goodies?)  A "CP SET VARIABLE" command would be very useful.

Cheers,
Arty

On Thu, 4 Oct 2007 16:27:29 -0500 you said:
>I always wanted a CP version of GLOBALV.  The SET part would be privilege=
>d=20
>of course, but the GET part would not be.  That way you could set=20
>variables in CP that could be retrieved by any virtual machine, like I'm=20=
>
>running a DR test, don't do that!
>
>--=20
>Dale R. Smith
>
>"Answers are easy.  It's asking the right questions which is hard."
>- Doctor Who
>
>On Thu, 4 Oct 2007 12:37:52 -0400, Alan Altmark <[EMAIL PROTECTED]>=
>=20
>wrote:
>
>>It seems something worthy of requirement.  The mechanism you describe ha=
>s
>>been invented, but it sits on a shelf on the Island of Misfit Toys,
>>unloved, waiting for someone ... anyone ... to take an interest.
>>
>>I should point out that SET PRODUCT conveniently comes with Diag 0x27C
>>(privclass ANY) to enable apps to find out if ENABLE or DISABLE has been=
>
>>set, as well as retreive the DESCRIPTION of the product.
>>
>>So, right now, yes, SET PRODUCT is the closest thing you have to a
>>system-wide name/value mapping function.
>>
>>Alan Altmark
>>z/VM Development
>>IBM Endicott

Re: D/R Code

[Dale R. Smith]

I always wanted a CP version of GLOBALV.  The SET part would be privilege
d 
of course, but the GET part would not be.  That way you could set 
variables in CP that could be retrieved by any virtual machine, like I'm 

running a DR test, don't do that!

-- 
Dale R. Smith

"Answers are easy.  It's asking the right questions which is hard."
- Doctor Who

On Thu, 4 Oct 2007 12:37:52 -0400, Alan Altmark <[EMAIL PROTECTED]>
 
wrote:

>It seems something worthy of requirement.  The mechanism you describe ha
s
>been invented, but it sits on a shelf on the Island of Misfit Toys,
>unloved, waiting for someone ... anyone ... to take an interest.
>
>I should point out that SET PRODUCT conveniently comes with Diag 0x27C
>(privclass ANY) to enable apps to find out if ENABLE or DISABLE has been

>set, as well as retreive the DESCRIPTION of the product.
>
>So, right now, yes, SET PRODUCT is the closest thing you have to a
>system-wide name/value mapping function.
>
>Alan Altmark
>z/VM Development
>IBM Endicott
>
=

Re: D/R Code

[Thomas Kern]

I thought that SET PRODUCT would be a bit more flexible than just the sin
gle
GATEWAY value that I am currently using. 

I also hope that IBM (Chuckie in particular) will not frown upon us using

the SET PRODUCT commands for enabling/disabling customer functions.

Maybe if the documentation (unoffical fiction as it is) were to make its 
way
into some customer's hands, a requirement could be written that matches
fairly well and then be submitted to the appropriate User Groups. 
 
/Tom Kern
/301-903-2211


On Thu, 4 Oct 2007 12:37:52 -0400, Alan Altmark <[EMAIL PROTECTED]>
 wrote:
>It seems something worthy of requirement.  The mechanism you describe ha
s
>been invented, but it sits on a shelf on the Island of Misfit Toys,
>unloved, waiting for someone ... anyone ... to take an interest.
>
>I should point out that SET PRODUCT conveniently comes with Diag 0x27C
>(privclass ANY) to enable apps to find out if ENABLE or DISABLE has been

>set, as well as retreive the DESCRIPTION of the product.
>
>So, right now, yes, SET PRODUCT is the closest thing you have to a
>system-wide name/value mapping function.
>
>Alan Altmark
>z/VM Development
>IBM Endicott

Re: D/R Code

[Alan Altmark]

On Wednesday, 10/03/2007 at 12:43 EDT, Thomas Kern <[EMAIL PROTECTED]> 
wrote:
> This is where it would be nice to be able to set (via SYSTEM CONFIG) an
> arbitrary name with an arbitrary value and be able to query it from any
> virtual machine. But without that we have to usurp other functions. I 
use
> the GATEWAY value, setting it in the system config based on which CPU I 
ipl
> on. Perhaps even the PRODUCT enable/disable statements could be used to 
add
> our own pseudo-PRODUCTs and enable then in our home system config, but
> disable in our DR system config. Then once things get straight at DR,
> manually issue the PRODUCT enable commands and xautolog the appropriate 
guests.

It seems something worthy of requirement.  The mechanism you describe has 
been invented, but it sits on a shelf on the Island of Misfit Toys, 
unloved, waiting for someone ... anyone ... to take an interest.

I should point out that SET PRODUCT conveniently comes with Diag 0x27C 
(privclass ANY) to enable apps to find out if ENABLE or DISABLE has been 
set, as well as retreive the DESCRIPTION of the product.

So, right now, yes, SET PRODUCT is the closest thing you have to a 
system-wide name/value mapping function.

Alan Altmark
z/VM Development
IBM Endicott

Re: D/R Code

[RPN01]

The code I use is:

/* Identify which system we're running on */
'Pipe CP Q GATEWAY' ,
'| Specs word 2 1' ,
'| Var SYSNAME'

Fairly concise and seems to cover most of the possibilities.

We run a CSE complex from a single SYSRES, so the system IDs are vastly
important. AUTOLOG1 checks, and performs differently on the individual
systems, and various other home-grown tools also have system-specific
behavior. Our SYSTEM CONFIG accounts for the two paired production LPARs,
two paired test systems, and an ³other² to catch any additional CPUids that
might fall our way Such as a disaster recovery site.

-- 
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55  200 First Street SW
 / ( ) \  507-284-0844   Rochester, MN 55905
^^-^^   - 
"In theory, theory and practice are the same, but ³Join the story...
Ride Ural.²
 in practice, theory and practice are different."

 


On 10/4/07 5:42 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> 
> How about having the AUTOLOGx userid's PROFILE EXEC issue a 'CP QUERY USERID
> AUTOLOGx' command, parse the output for the system id you're running on, and
> test whether you're running on your normal system or another (disaster
> recovery) system and act accordingly.

Re: D/R Code

[pfa]

How about having the AUTOLOGx userid's PROFILE EXEC issue a 'CP QUERY 
USERID AUTOLOGx' command, parse the output for the system id you're 
running on, and test whether you're running on your normal system or 
another (disaster recovery) system and act accordingly.

Re: D/R Code

[Dale R. Smith]

The way I have done this, (for CMS anyway), is to copy a specific file to
 
the Y-Disk at DR.  In my documentation for DR, I stated that if it was a 

DR test, then I would copy "DRTEST FILE" to the Y-Disk.  If it was 
a "real" DR, then I would copy "DRPROD FILE" to the Y-Disk.  The files ca
n 
contain anything, (my "DRTEST FILE" had "This is a Disaster Recovery 
Test!!!" in it and my "DRPROD FILE" had "This is a Real Disaster!!!" in 

it.  :-)> )  Then I would resave the appropriate CMS NSS systems, (of 
course).  This allowed us to have code in REXX execs that could test for 

the existence of one on the files and take different paths based on the 

result.  For example:

'ESTATE DRTEST FILE Y'
drtest = (rc = 0)
'ESTATE DRPROD FILE Y'
drprod = (rc = 0)
Select /* DR */ 
   When drtest Then ...
   When drprod Then ...
Otherwise
   ...
End /* Select DR */

or there might be something that we would run only in production and neve
r 
at DR:

If drtest | drprod Then
   ...
Else
   ...

Since we restored our production VM system via HiDRO, if we didn't do 
something like this, then some things would run that we didn't want to ru
n 
at a DR test, (for example, we normally run DB2/VM logical archives every
 
night, during a DR test we don't want to run them).  We also used this 

technique to start up our security manager, (Top Secret/VM), in warn mode
 
to allow testing without the ESM getting in the way, (but still logging 

access problems).  This was approved by management, of course.

-- 
Dale R. Smith

"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
- Doctor Who
 
On Wed, 3 Oct 2007 09:29:51 -0400, Mary Anne Matyaz 
<[EMAIL PROTECTED]> wrote:

>Hello all. I need a few lines of code for a D/R situation. I need to kno
w,
>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, shutdo
wn
>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 th
en
>access it...
>
>TIA for any insight/thoughts, etc...
>
>Mary Anne
>

Re: D/R Code

[Marcy Cortes]

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?"

-- 
 
*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... 

 
"Record Qualifiers" are the "System_Identifier"s used to limit the scope
of the definitions which follow later in the SYSTEM CONFIG. 


 
 
* %% 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). 
 


 
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. 
-- 

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"  


10/03/2007 08:29 AM 


Please respond to
"The IBM z/VM Operating System" 




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 

Re: D/R Code

[Mike Walter]

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?"

--

?   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?


?Record Qualifiers? are the ?System_Identifier?s used to limit the scope 
of the definitions which follow later in the SYSTEM CONFIG.




?%% 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).




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.
--

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" 
10/03/2007 08:29 AM
Please respond to
"The IBM z/VM Operating System" 



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. 


<><><><>

Re: D/R Code

[David Boyes]

Another (prewritten) option would be to use the SYSVINIT code we developed for 
AUTOLOG1 use. You could define a runlevel for DEFAULT (your normal setup) and 
DISASTER (the disaster setup). SYSVINIT allows persistent variable setting, and 
it wouldn't be hard to look for a specific result from the IPL parms and set 
variables appropriately in a service. Then switching configurations is as easy 
as providing a IPL parm, or TELL AUTOLOG1 RUNLEVEL DISASTER or RUNLEVEL DEFAULT 
and watching things get sequenced automagically. 



From: The IBM z/VM Operating System on behalf of Mary Anne Matyaz
Sent: Wed 10/3/2007 12:26 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: D/R Code


Thanks All. Here's what I've come up with. I'm going to allow everything to 
come up on D/R without intervention if it is a real disaster. If I am testing, 
I will allow it all to come up, and 
IP won't work, so I'll bring TCPIP and the linuxes down, and XAUTOLOG AUTOLOG2 
Storage 6M. This way, if I'm in a test, programmatically I can q v storage from 
within autolog2 and make decisions based on that, one of which will be, if it's 
6M: 
define timezone DR1 west 00.00.01
so that other apps can check for the existence of that timezone, and if they 
find it, we are in DR test. 

MA

Re: D/R Code

[Mary Anne Matyaz]

Ron, that's fine for DR tests, but we need to be able to come up
automagically
if we're all gone in a real DR, so our main 'goal' is to run as if it's a
real DR and get the
whole way up with no intervention. So I'll have autolog come up, it will
fail, and in a test
I'll force the linuxes and tcpip, then start autolog with a parm. That way I
have
intervention on a test but not in a real dr.
Mary Anne

On 10/3/07, Ron Schmiedge <[EMAIL PROTECTED]> wrote:
>
> We have the PROFILE EXEC for AUTOLOG1 coded to stop and ask the
> operator whether to continue normal startup or not every time we IPL.
> In addition, the operator can use the SM reply to tell AUTOLOG1 to
> carry on but that we are in a disaster recovery.
> Like Kris, AUTOLOG1 does different things based on the operator's
> instructions - and it's not an operator doing this at a DR, its one of
> our tech support people, so there is a reasonable chance they know
> what to do :-)
>
> Ron
>
>
> On 10/3/07, Mary Anne Matyaz <[EMAIL PROTECTED]> wrote:
> > Thanks All. Here's what I've come up with. I'm going to allow everything
> to
> > come up on D/R without intervention if it is a real disaster. If I am
> > testing, I will allow it all to come up, and
> > IP won't work, so I'll bring TCPIP and the linuxes down, and XAUTOLOG
> > AUTOLOG2 Storage 6M. This way, if I'm in a test, programmatically I can
> q v
> > storage from within autolog2 and make decisions based on that, one of
> which
> > will be, if it's 6M:
> > define timezone DR1 west 00.00.01
> > so that other apps can check for the existence of that timezone, and if
> they
> > find it, we are in DR test.
> >
> > MA
> >
> >
>

Re: D/R Code

[Ron Schmiedge]

We have the PROFILE EXEC for AUTOLOG1 coded to stop and ask the
operator whether to continue normal startup or not every time we IPL.
In addition, the operator can use the SM reply to tell AUTOLOG1 to
carry on but that we are in a disaster recovery.
Like Kris, AUTOLOG1 does different things based on the operator's
instructions - and it's not an operator doing this at a DR, its one of
our tech support people, so there is a reasonable chance they know
what to do :-)

Ron


On 10/3/07, Mary Anne Matyaz <[EMAIL PROTECTED]> wrote:
> Thanks All. Here's what I've come up with. I'm going to allow everything to
> come up on D/R without intervention if it is a real disaster. If I am
> testing, I will allow it all to come up, and
> IP won't work, so I'll bring TCPIP and the linuxes down, and XAUTOLOG
> AUTOLOG2 Storage 6M. This way, if I'm in a test, programmatically I can q v
> storage from within autolog2 and make decisions based on that, one of which
> will be, if it's 6M:
> define timezone DR1 west 00.00.01
> so that other apps can check for the existence of that timezone, and if they
> find it, we are in DR test.
>
> MA
>
>

Re: D/R Code

[Thomas Kern]

I like that even better since at DR I always have to use the SAPL screen 
to
get my system console right. Just add the extra NAME=Value entries righ
t
there. And it should not be restricted to a single predefined variable na
me,
but let me do IPLCODE=xx IPLREASON='DR Recovery at YY'.

/Tom Kern

On Wed, 3 Oct 2007 18:50:33 +0200, Kris Buelens <[EMAIL PROTECTED]> 
wrote:

>Or, what about an arbitrary parameter the operator could pass on the SAP
L
>screen (alongside CONS=xxx etc)  that one could query, e.g; IPLREASON=
.
>Because: maintaining an extra SYSTEM CONFIG is often forgotten.
>

Re: D/R Code

[Kris Buelens]

Or, what about an arbitrary parameter the operator could pass on the SAPL
screen (alongside CONS=xxx etc)  that one could query, e.g; IPLREASON=.
Because: maintaining an extra SYSTEM CONFIG is often forgotten.

2007/10/3, Thomas Kern <[EMAIL PROTECTED]>:
>
> This is where it would be nice to be able to set (via SYSTEM CONFIG) an
> arbitrary name with an arbitrary value and be able to query it from any
> virtual machine. But without that we have to usurp other functions. I use
>
> the GATEWAY value, setting it in the system config based on which CPU I i
> pl
> on. Perhaps even the PRODUCT enable/disable statements could be used to a
> dd
> our own pseudo-PRODUCTs and enable then in our home system config, but
> disable in our DR system config. Then once things get straight at DR,
> manually issue the PRODUCT enable commands and xautolog the appropriate g
> uests.
>
> /Tom Kern
>
>
> On Wed, 3 Oct 2007 18:28:54 +0200, Kris Buelens <[EMAIL PROTECTED]>
> wrote:
>
> >Our disaster backup process stores a control file on AUTOLOG1 191 when t
> he
> >backup of that minidisk is taken (a very short while) and it is erased
> >afterwards.  The PROFILE EXEC of AUTOLOG1 checks for the presence of thi
> s
> >file, if found; it prompts the operator to ask if it is really an IPL af
> ter
> >a disaster; it will not continue until the operator sends an SMSG YES or
>
> >NO.  This prompt is required as there is a -small- chance that VM dies w
> hile
> >AUTOLGO1 is being backed up on the disaster tapes.  If the operator repl
> ies
> >YES, AUTOLOG1 and AUTOLGO2 will take very different actions, so that onl
> y
> >VMBACKUP & co will be started as to enable restoring the VMBACKUP ta
> pes.
> >
> >Testing the CPUID is only good when after a disaster you IPL on another
> >CPU.  But, what if you have fatal disk problems (or someone whiping out
> your
> >resident).
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: D/R Code

[Thomas Kern]

This is where it would be nice to be able to set (via SYSTEM CONFIG) an
arbitrary name with an arbitrary value and be able to query it from any
virtual machine. But without that we have to usurp other functions. I use

the GATEWAY value, setting it in the system config based on which CPU I i
pl
on. Perhaps even the PRODUCT enable/disable statements could be used to a
dd
our own pseudo-PRODUCTs and enable then in our home system config, but
disable in our DR system config. Then once things get straight at DR,
manually issue the PRODUCT enable commands and xautolog the appropriate g
uests.

/Tom Kern  


On Wed, 3 Oct 2007 18:28:54 +0200, Kris Buelens <[EMAIL PROTECTED]> 
wrote:

>Our disaster backup process stores a control file on AUTOLOG1 191 when t
he
>backup of that minidisk is taken (a very short while) and it is erased
>afterwards.  The PROFILE EXEC of AUTOLOG1 checks for the presence of thi
s
>file, if found; it prompts the operator to ask if it is really an IPL af
ter
>a disaster; it will not continue until the operator sends an SMSG YES or

>NO.  This prompt is required as there is a -small- chance that VM dies w
hile
>AUTOLGO1 is being backed up on the disaster tapes.  If the operator repl
ies
>YES, AUTOLOG1 and AUTOLGO2 will take very different actions, so that onl
y
>VMBACKUP & co will be started as to enable restoring the VMBACKUP ta
pes.
>
>Testing the CPUID is only good when after a disaster you IPL on another
>CPU.  But, what if you have fatal disk problems (or someone whiping out 
your
>resident).

Re: D/R Code

[Kris Buelens]

Our disaster backup process stores a control file on AUTOLOG1 191 when the
backup of that minidisk is taken (a very short while) and it is erased
afterwards.  The PROFILE EXEC of AUTOLOG1 checks for the presence of this
file, if found; it prompts the operator to ask if it is really an IPL after
a disaster; it will not continue until the operator sends an SMSG YES or
NO.  This prompt is required as there is a -small- chance that VM dies while
AUTOLGO1 is being backed up on the disaster tapes.  If the operator replies
YES, AUTOLOG1 and AUTOLGO2 will take very different actions, so that only
VMBACKUP & co will be started as to enable restoring the VMBACKUP tapes.

Testing the CPUID is only good when after a disaster you IPL on another
CPU.  But, what if you have fatal disk problems (or someone whiping out your
resident).

2007/10/3, Brian Nielsen <[EMAIL PROTECTED]>:
>
> We run the same configuration both live and at DR.  The only 2 things don
> e
> different at DR are to manually FORCE off AUTOLOG2 (there is a 1 minute
>
> delay which allows this to be easily done) and to manually XAUTOLOG
> TCPIPDR (which runs in *addition* to the normal TCPIP stack).
>
> AUTOLOG2 brings up all the LINUX guests, which need to be restored first.
>
> If needed, the individual LINUX guests can be forced off.
>
> The TCPIPDR stack masquerades as the various gateways that the LINUX
> guests use and forwards everything to the external router IP used at DR.
>
> The DR I/O configuration leaves out the OSA addresses in use at the home
>
> site and includes a new OSA address for use only by TCPIPDR.  This
> prevents the VSWITCHes from passing traffic directly to an OSA, allowing
>
> the TCPIPDR stack to route all the traffic.  This setup means we don't
>
> have to update IP stacks.
>
> Brian Nielsen
>
>
> On Wed, 3 Oct 2007 09:29:51 -0400, Mary Anne Matyaz
> <[EMAIL PROTECTED]> wrote:
>
> >Hello all. I need a few lines of code for a D/R situation. I need to kno
> w,
> >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, shutdo
> wn
> >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 th
> en
> >access it...
> >
> >TIA for any insight/thoughts, etc...
> >
> >Mary Anne
> >
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: D/R Code

[Mary Anne Matyaz]

Thanks All. Here's what I've come up with. I'm going to allow everything to
come up on D/R without intervention if it is a real disaster. If I am
testing, I will allow it all to come up, and
IP won't work, so I'll bring TCPIP and the linuxes down, and XAUTOLOG
AUTOLOG2 Storage 6M. This way, if I'm in a test, programmatically I can q v
storage from within autolog2 and make decisions based on that, one of which
will be, if it's 6M:
define timezone DR1 west 00.00.01
so that other apps can check for the existence of that timezone, and if they
find it, we are in DR test.

MA

On 10/3/07, Brian Nielsen <[EMAIL PROTECTED]> wrote:
>
> We run the same configuration both live and at DR.  The only 2 things don
> e
> different at DR are to manually FORCE off AUTOLOG2 (there is a 1 minute
>
> delay which allows this to be easily done) and to manually XAUTOLOG
> TCPIPDR (which runs in *addition* to the normal TCPIP stack).
>
> AUTOLOG2 brings up all the LINUX guests, which need to be restored first.
>
> If needed, the individual LINUX guests can be forced off.
>
> The TCPIPDR stack masquerades as the various gateways that the LINUX
> guests use and forwards everything to the external router IP used at DR.
>
> The DR I/O configuration leaves out the OSA addresses in use at the home
>
> site and includes a new OSA address for use only by TCPIPDR.  This
> prevents the VSWITCHes from passing traffic directly to an OSA, allowing
>
> the TCPIPDR stack to route all the traffic.  This setup means we don't
>
> have to update IP stacks.
>
> Brian Nielsen
>
>
> On Wed, 3 Oct 2007 09:29:51 -0400, Mary Anne Matyaz
> <[EMAIL PROTECTED]> wrote:
>
> >Hello all. I need a few lines of code for a D/R situation. I need to kno
> w,
> >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, shutdo
> wn
> >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 th
> en
> >access it...
> >
> >TIA for any insight/thoughts, etc...
> >
> >Mary Anne
> >
>

Re: D/R Code

[Brian Nielsen]

We run the same configuration both live and at DR.  The only 2 things don
e 
different at DR are to manually FORCE off AUTOLOG2 (there is a 1 minute 

delay which allows this to be easily done) and to manually XAUTOLOG 
TCPIPDR (which runs in *addition* to the normal TCPIP stack).

AUTOLOG2 brings up all the LINUX guests, which need to be restored first.
  
If needed, the individual LINUX guests can be forced off.

The TCPIPDR stack masquerades as the various gateways that the LINUX 
guests use and forwards everything to the external router IP used at DR. 
 
The DR I/O configuration leaves out the OSA addresses in use at the home 

site and includes a new OSA address for use only by TCPIPDR.  This 
prevents the VSWITCHes from passing traffic directly to an OSA, allowing 

the TCPIPDR stack to route all the traffic.  This setup means we don't 

have to update IP stacks.

Brian Nielsen


On Wed, 3 Oct 2007 09:29:51 -0400, Mary Anne Matyaz 
<[EMAIL PROTECTED]> wrote:

>Hello all. I need a few lines of code for a D/R situation. I need to kno
w,
>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, shutdo
wn
>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 th
en
>access it...
>
>TIA for any insight/thoughts, etc...
>
>Mary Anne
>

Re: D/R Code

[Stracka, James (GTI)]

We use different System Configuration files for each situation then run
a WHERERWE EXEC which checks the CPUID and FN from QUERY IPLPARMS,
having made that a class "G" command.  The return code from WHERERWE can
then be checked.
 

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mary Anne Matyaz
Sent: Wednesday, October 03, 2007 9:30 AM
To: IBMVM@LISTSERV.UARK.EDU
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


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.

Re: D/R Code

[Huegel, Thomas]

I think that if you set different SYSTEM_ID's in the SYSTEM CONFIG file for
each of your situations you can then code different TCPIP startups for each
SYSTEM_ID and it will 'automatically' use the start up for that particular
system. RSCS works the same way.
For other applications you can use the Q GATEWAY command to see which system
you are running. 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Mary Anne Matyaz
Sent: Wednesday, October 03, 2007 8:30 AM
To: IBMVM@LISTSERV.UARK.EDU
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 



  _  

<< ella for Spam Control >> has removed 13149 VSE-List messages and set
aside 12580 VM-List for me
You can use it too - and it's FREE!   www.ellaforspam.com