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.