1) Only the sysprogs IPL with the different loadparm for the sandbox
2) Our operators do enter the load addresses for all other IPLs. Only one
icon per LPAR. Loadparm changes temporarily during OS migrations, but
the sysprogs usually do the first IPL and it is remembered.
We've had this discussion before I think. With 30 LPARs at the shop
I'm at, and with anywhere from 3-6 different sysres sets that get
rotated between the various sysplexes, we would need literally
hundreds of different load profiles / icons and it would be a
maintenance nightmare. Or the sysprogs would have to update
load addresses / loadparms for a profile as opposed to the operator
doing it at IPL time (which could be just as error prone). So I
don't see this as risky and in all the time I've been at this client
on and off over the last 14 years there has never been an instance
of an IPL from the wrong address (maybe because a typo most
likely leads to a failure).
If an operator can't read the IPL instructions from a piece of paper (or
online) from a change record that specifies the load address and/or
loadparm and follow those instructions properly, then it's time to
find another operator.
I have worked in small shops with only a few LPARs where it was handled
the way you do it. One size seldom fits all.
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
On Fri, 15 Jun 2012 08:25:06 -0700, Skip Robinson <jo.skip.robin...@sce.com>
wrote:
>Although we have only 'static' LPARs--which I interpret as always running
>the same SYSNAME in the same LPAR--you can handle virtually any
>combination of IPL parms by creating unique Load profiles with names
>suggesting their function. The idea of editing--entering characters on a
>keyboard--in preparation for a normal IPL strikes me as unacceptably
>risky. It's not about knowledge transfer. It's the consequences of a
>simple finger check at the single most crucial point in an IPL. I would
>not like to have to explain to management why I routinely subjected my
>operators to that level of jeopardy.
>
>.
>.
>JO.Skip Robinson
>SCE Infrastructure Technology Services
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>626-302-7535 Office
>323-715-0595 Mobile
>jo.skip.robin...@sce.com
>
>
>
>From: Mark Zelden <m...@mzelden.com>
>To: IBM-MAIN@listserv.ua.edu
>Date: 06/15/2012 06:19 AM
>Subject: Re: Change IEASYMxx via operator prompt
>Sent by: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu>
>
>
>
>On Fri, 15 Jun 2012 09:17:39 +0200, R.S. <r.skoru...@bremultibank.com.pl>
>wrote:
>
>>W dniu 2012-06-15 01:07, Skip Robinson pisze:
>>> Our operators never 'change IPL address'. They select the appropriate
>LOAD
>>> profile on the HMC before IPL. We don't find it necessary on a regular
>>> basis, but each LOAD profile can contain a unique LOADPARM value where
>the
>>> specified LOADxx suffix points to a unique IPLPARM member. That way no
>one
>>> has to edit anything on a regular basis. Each LOADxx can specify a
>unique
>>> concatenation of IEASYMxx members. All controlled by LOAD profile.
>>
>>That's really good approach for "static scenario" - always the same
>>system is IPLed of given LPAR. However sometimes there is a need to
>>"dynamically" change the system, for example this week we run MVS123,
>>next week we will run MVS456 on the same LPAR. In such case you have to
>>change IPL parameters. Of course there is still possibility to choose
>>IEASYMxx inplicitly, via LOADyy.
>>
>
>Exactly what I have to do. We have a couple of sandbox sysplexes (2 LPARs
>per sysplex) that have "static lpars". But I have to share a couple of
>other monoplex sandbox environments in a single LPAR. One of them
>is able to share the LOADxx member with the other sandboxes (the one
>up and running most often). The other one is just IPLed with a different
>LOADxx member when we need that system active.
>
>--
>Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
>mailto:m...@mzelden.com
>Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
>Systems Programming expert at http://expertanswercenter.techtarget.com/
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
