Shorter still:

?l2=length(diag(00))>40     /* We're running a 2nd level VM      */ 

Then something like:  If ?l2 then ... some 2nd level stuff...

Mike Walter
Aon Hewitt
The opinions expressed herein are mine alone, not my employer's.



"Frank M. Ramaekers" <framaek...@ailife.com> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
10/05/2010 03:39 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: IPL VM/VM Issues






To determine if you are running under 1st level VM or another level, us
this in your PROFILE EXEC (REXX):

/* Determine what level of VM (VM under VM) we are running */
 Parse value Diagrc(0) with rc 10 . 11 cc 12 . 17 D00Data 
 FirstLevel=(Length(D00Data)<=40) 
 MyLevel=Length(D00Data)/40 

 
Frank M. Ramaekers Jr.
 
 

-----Original Message-----
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Brian Nielsen
Sent: Tuesday, October 05, 2010 3:29 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: IPL VM/VM Issues

As others have pointed out, your L2 guest can't hurt your L1 system or 
other guests unless L2 has access to those disks.  Stating it from a 
different angle - you should never give your L2 guest access to anything

you don't want it to have access to.  It's no different than keeping
your 
z/OS and Linux guests from stepping on each other or your L1 system.
This 
guest just happens to be running VM.

For your IPL, if you've DDR'd your SPOOL volumes from L1 to L2, there is

no reason to do a COLD start.  Do a FORCE start instead.  Otherwise you 
need to rebuild or SPXTAPE LOAD the SDF files.

For TCP, what happens depends on what you have set up for your L2 guest.

If you gave it access to a real hardware (OSA, hipersocket, etc) then
you 
have other work to do to prevent IP conflicts.  If instead you've given
it 
access to a disconnected VSWITCH and/or virtual LAN, then it won't cause

any problems because it can't connect to anything.  And, yes, defining 
GRAFs and using DIAL is a standard practice.

Something you might want to look into is setting up your system so it 
recognizes whether it's at L1 or L2 or at DR so that it does the "right 
thing" for that situation.  There's several ways to do that, but you've 
gone down the path of diverging your L2 system from your L1 system.  At
my 
site I have it setup so that I can DDR my L1 system into my L2 guest,
into 
a couple different setups at my DR site, or into some unknown site, and
it 
comes up the way I want it to in each instance even if the others are 
running.  It makes life easier.  What you're doing is a great learning 
experience, and eventually you'll see the value in making your multiple 
systems easier to manage.

Brian Nielsen


On Tue, 5 Oct 2010 15:28:01 -0400, George Henke/NYLIC 
<george_he...@newyorklife.com> wrote:

>L2 is a cloned L1 directory except for the volsers in the Directory and
CF
>Parm files which have all been made unique, ie 540 becoming 54X.
>
>I plan to ipl as follows:
>
>system reset
>term conmode 3270
>set mach esa
>I 125b clear loadparm 009
>
>START COLD DRAIN
>
>To be safe, I suppose I should also add NOAUTO.
>
>L1 runs 5 z/OS machines and 3 Linuxes.
>
>They could be corrupted at L1 if I tried to bring them up in L2 at the
>same time  without GRS, MIM, or some other serialization product.
>
>I doubt TCPIP will work at L2 without some reconfiguring.
>
>So I should define some GRAFs and dial them.
>
>Not sure if my L2 entry in the L1 Directory needs 54XRES, 54XPAG,
54XSPL,
>54XW01, 54XW02 or whether I can just specify the IPL vplume, 54XRES,
and
>CP finds the rest from the Parm disk.

_____________________________________________________

This message contains information which is privileged and confidential and 
is solely for the use of the

intended recipient. If you are not the intended recipient, be aware that 
any review, disclosure,

copying, distribution, or use of the contents of this message is strictly 
prohibited. If you have

received this in error, please destroy it immediately and notify us at 
privacy...@ailife.com.






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. 

Reply via email to