The first thing I don't like about this is that it is very prone to human
error during the process of adding or removing images. This is just one
more, in a long list of files, that has to be edited each time a guest is
added. One more place for mistakes to be made.

I'd first create a central, agree-upon definitive source for the image names
and user ids. Ours are "penguin" files kept on autolog1 191. Every exec that
needs to run through the list of images links Autolog1 191 and reads the
penguin file for the system it's being run on.

When a new image is added, the one penguin file needs to be edited, and all
of the utilities and references immediately get the change, because they all
use the same source for the information. If something's messed up, you know
exactly where to look, and you know how many places it's messed up in: Just
one.

We run a two system CSE complex, so there are two penguin files, one for
each CEC. They're used for everything from autologging the images during IPL
to checking to see if they all are there or all ping. One stop shopping.

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




On 8/13/09 9:53 AM, "russell.gendr...@custserv.com"
<russell.gendr...@custserv.com> wrote:

> We have a little rexx exec we run in the morning to check the VM guests,
> It is divided up between system ID's and the layer 2 and layer 3 linux
> guests.
> 
> Small example:
> 
> 'MSG' '*' 'CKUSERID STARTING   '    /* CKUSERID STARTING             */
> 'MSG' '*' 'SYSTEM IDS          '    /* SYSTEM IDS                    */
> 'Q   ' 'DISKACNT                '   /*                               */
> 'Q   ' 'DTCVSW1                 '   /*                               */
> 'Q   ' 'DTCVSW2                 '   /*                               */
> 'MSG' '*' 'LAYER 2 GUEST IDS   '    /* GUEST  IDS                    */
> 'Q   ' 'NMDTOR04                '   /*                               */
> 'Q   ' 'NMDPOR02                '   /*                               */
> 'Q   ' 'TDCPNT01                '   /*                               */
> 'Q   ' 'TDCPNT02                '   /*                               */
> 'MSG' '*' 'LAYER 3 GUEST IDS   '    /* GUEST  IDS                    */
> 'Q   ' 'DFNORRUL                '   /*                               */
> 'Q   ' 'DFNORSTG                '   /*                               */
> 'Q   ' 'DFNORSTO                '   /*                               */
> 
> 
>  Russell Gendreau
> 
> 
> -----Original Message-----
> From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
> Behalf Of Dave Jones
> Sent: Thursday, August 13, 2009 9:31 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: How to tell how many linux running on z/VM?
> 
> Well, simple for you, Bill, with your mumble, mumble years of VM
> experience....:-) You already know that the ESAxxxx machines are
> Velocity products, FTPSERVE, PORTMAP, SMTP, etc. are part of the VM
> TCP/IP stack, and so forth. That knowledge may not be available to folks
> 
> just now getting their feet wet in a VM environment.
> 
> That's why I suggested the TRACK approach....it's an explicit and
> deterministic method for identifying Linux guests.
> 
> Have a good one.
> 
> Bill Munson wrote:
>> I too am confused as to why "Q NAMES" would not work ?
>> 
>> q names 
>> WATCHER  - DSC , MLXORA2S - DSC , MLXORA1S - DSC , MLXWP01S - DSC
>> MLXAP01S - DSC , MLXESS2S - DSC , MLXESS1S - DSC , DTCVSW1  - DSC
>> VSMPROXY - DSC , VMRMADMN - DSC , VMRMSVM  - DSC , VMBACKUP - DSC
>> VMUTIL   - DSC , ESAALERT - DSC , ESAWEB02 - DSC , ESAWEB01 - DSC
>> ESAADMIN - DSC , PERFSVM  - DSC , ESAWRITE - DSC , ESATCP   - DSC
>> RSCS     - DSC , ESASERVE - DSC , GCS      - DSC , VSMSERVE - DSC
>> SMTP     - DSC , REXECD   - DSC , PORTMAP  - DSC , FTPSERVE - DSC
>> SNMPD    - DSC , TCPIP    - DSC , DTCVSW2  - DSC , OPERSYMP - DSC
>> DISKACNT - DSC , EREP     - DSC , OPERATOR - DSC , NJ2W002  -L0004
>> VSM     - TCPIP 
>> Munson at zVM3; T=0.01/0.01 08:09:23
>> 
>> It is pretty easy to pick out the 6 LINUX guests running on my sandbox
> 
>> system
>>  
>> Bill Munson 
>> Sr. z/VM Systems Programmer
>> Brown Brothers Harriman & CO.
>> 525 Washington Blvd.
>> Jersey City, NJ 07310
>> 201-418-7588
>> 
>> 
>> 
>> 
>> sunny...@wcb.ab.ca
>> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
>> 08/12/2009 05:49 PM
>> Please respond to
>> The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
>> 
>> 
>> To
>> IBMVM@LISTSERV.UARK.EDU
>> cc
>> 
>> Subject
>> How to tell how many linux running on z/VM?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> I was asked to find out how many linux guests are running on our
> z/VM? 
>> the cp commands:Q N is not very suitable for this question.
>> What is the better way?
>> This message is intended only for the addressee. It may contain
> privileged 
>> or confidential information. Any unauthorized disclosure is strictly
>> prohibited. If you have received this message in error, please notify
> us 
>> immediately so that we may correct our internal records. Please then
>> delete the original email. Thank you. (Sent by Webgate1)
>> 
>> *************************** IMPORTANT
>> NOTE***************************** The opinions expressed in this
>> message and/or any attachments are those of the author and not
>> necessarily those of Brown Brothers Harriman & Co., its
>> subsidiaries and affiliates ("BBH"). There is no guarantee that
>> this message is either private or confidential, and it may have
>> been altered by unauthorized sources without your or our knowledge.
>> Nothing in the message is capable or intended to create any legally
>> binding obligations on either party and it is not intended to
>> provide legal advice. BBH accepts no responsibility for loss or
>> damage from its use, including damage from virus.
>> 
> ************************************************************************

Reply via email to