Just be sure when you rename CPLOAD MODULE to keep same FILE TPE (MODULE). Such 
as CPLOLD MODULE.

This way, if you need to fall back to the old CP nucleus, you may PF9 
(filelist) from the SAPL screen and select CPLOLD MODULE.

Ray Waters

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of George Henke/NYLIC
Sent: Monday, September 27, 2010 11:54 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Applying Maintenance - Best Practice


There seems to be a difference of opinion about how safe it is to simply rename 
the cpload and apply maintenance at Level 1 instead of burning it in on Level 2.

You seem confident that this is doable with minimal risk. others say never make 
changes without first implementing them at Level 2 first and at least IPLing.



Mike Walter <mike.wal...@hewitt.com>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>

09/27/2010 12:20 PM
Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>


To

IBMVM@LISTSERV.UARK.EDU

cc

Subject

Re: Applying Maintenance - Best Practice







George,

There's nothing keeping you from making a backup copy (using COPYFILE with
the "OLDDATE" option of course!!) of CPLOAD MODULE to another name before
you run PUT2PROD.

We keep up to 9 levels of backout CPLOAD MODULEs around on the (enlarged)
CF1 and CF2 disks, using a making standard similar to a z/OS GDG:
The current one is CPLOAD MODULE
the next oldest is -1CPLOAD MODULE
the next older than that is -2CPLOAD MODULE and so on.
The original date and time of the file is always retained.

That way there's no worry about renaming modules to back out (we can
shuffle names later of we choose), and we can easily tell operations to
IPL with a LOADPARM to bring up SALIPL, telling them to load '-1CPLOAD'
(or -2CPLOAD, etc.).

OTOH, I can't remember the last time we had to back out a CPLOAD MODULE.

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





"George Henke/NYLIC" <george_he...@newyorklife.com>

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
09/24/2010 01:44 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Applying Maintenance - Best Practice







So, I guess the "bottom line" is that there is no *silver bullet*, no
*shortcut*, for even the smallest change, that PUT2PROD at Level1:
steps on the current CPLOAD no matter what you do.
is unacceptable, without shaking down the change on Level 2 first and
having a backup.

If anyone knows otherwise, please let me know.



"Frank M. Ramaekers" <framaek...@ailife.com>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
09/24/2010 10:38 AM

Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Applying Maintenance - Best Practice








I think the answer to your question is yes?    I assume, that any problem
discovered are not insurmountable that they have to be backed out (instead
additional fixes may need to be applied).

This is correct.   From my FLASH2ND EXEC:

/*--------------------------------------------------------------------*/
/* FLASH2ND  - FLASHCOPYs the 1st level VM DASD                       */
/*                                                                    */
/* 1)  Verify all flash drives are available (!._rDest variable)      */
/* 2)  Show a confirmation list of source & destination drives        */
/* 3)  FLASHCOPY CP_OWNED drives and rename destination drives        */
/* 4)  Create a copy of current direct and modify for 2nd level       */
/*     (2USER DIRECT) changing CP_OWNED volumes and updating the      */
/*     2nd level directory (Uses F123 as 123 for DIRECTXA).           */
/*     (This also places a copy of this new directory source on       */
/*     second level MAINT's 191 disk, this MAINT's F191 disk.)        */
/* 5)  Modify the SYSTEM CONFIG modfying the CP_OWNED volumes         */
/*                                                                    */
/* Note:  This can also be used to make a backup of the system for    */
/*        quick recovery (this set of DASD is IPL w/o change).        */
/*--------------------------------------------------------------------*/


Frank M. Ramaekers Jr.






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of George Henke/NYLIC
Sent: Friday, September 24, 2010 9:32 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Applying Maintenance - Best Practice


ty for sharing this.

One question though:

It is ok to apply the maintenance to the production system, Level 1, your
1st step, as long as you do not run PUT2PROD at that time there?

Also I noticed you do not use the SYSTEM CONFIGURATION parm disk fallback,
but just point to the FLASH COPIED disks if there is a problem.


"Frank M. Ramaekers" <framaek...@ailife.com>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
09/24/2010 10:26 AM


Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Applying Maintenance - Best Practice











Here?s what I do:

1)                   Apply Maintenance to production system
2)                   Flash production DASD to test packs (using different
naming conventions)
Actually, I have a REXX program I wrote that not only changes the name,
but updates the SYSTEM CONFIG, directory and updates the directory on the
test packs.
3)                   Bring up the 2nd level VM
4)                   Run PUT2PROD on 2nd level
5)                   Test 2nd level

If satisfied with the testing:

1)                   Flash production DASD to backup packs (can be the
same as the test packs, again using a different naming convention)
2)                   PUT2PROD on the production system
3)                   IPL the updated system
4)                   Any problems, I can immediately IPL the ?backup?
system (copy prior to PUT2PROD)




Frank M. Ramaekers Jr.








From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of George Henke/NYLIC
Sent: Friday, September 24, 2010 9:02 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Applying Maintenance - Best Practice


Is there a procedure for applying maintenance selectively such that  a
full system backup is not necessary beforehand?

In other words, save the old CPLOAD and just point to the new CPLOAD at
IPL and if need be simply fallback to the old CPLOAD.

I know the CF1 Parm Disk backup supports this.

But is there a way of applying maintenance so that it hits only a new
CPLOAD and not  the current CPLOAD.

Perhaps the answer is to save the current CPLOAD in the CF1 Parm Disk
configuration before applying the maintenance.

It is probably not "best practice", but is there such a procedure of
avoiding a full system backup before putting on any maintenance, or is
that taboo?

Marcy Cortes <marcy.d.cor...@wellsfargo.com>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
09/23/2010 04:00 PM



Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>




To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Applying Maintenance - Best Practice













We put it on 2nd level first.  Check that it IPLs, basically... not a lot
we can do there.
Then our vm test lpar.  Make sure everything comes up.  Maybe start a
Linux there.
Then our 2 Linux test/dev lpars, which run lots of servers.  Gets a lot of
exercise there.
Let it cook a few weeks.
Roll to the 6 production LPARs, starting usually with the 2 that don't run
Linux.  Then 2 Linux on a weekend and the other 2 on another weekend.

We have the z196 maint with RSU 1002 on all of test dev now (3 lpars).  On
both a z196 and a z10.   All is well, YMMV;)

Marcy

________________________________

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of George Henke/NYLIC
Sent: Thursday, September 23, 2010 10:58 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] Applying Maintenance - Best Practice



I suppose RSU maintenance gets burned-in at Level 2, whereas COR
maintenance goes right in to Level 1.

But , what bout PSP COR?  Level 1 or Level 2.





Scott Rohling <scott.rohl...@gmail.com>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>

09/23/2010 10:58 AM
Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>


To
             IBMVM@LISTSERV.UARK.EDU
cc

Subject
             Re: Applying Maintenance - Best Practice






I'd say it depends on the purpose of your 2nd level system.    Do what you
would normally do when applying maintenance...  do you put it on 1st or
2nd level first?   If your 2nd level system is meant to be a z/VM 'test'
system, then it seems like you're already committed to that level of
effort.

Scott Rohling

On Thu, Sep 23, 2010 at 8:30 AM, George Henke/NYLIC
<george_he...@newyorklife.com <mailto:george_he...@newyorklife.com> >
wrote:

Would you recommend putting this 5.4 zEnterprise compatibility maintenance
on at Level 1 or Level 2.

We currently have both environments for 5.4.

I suppose the quickest and easiest (maybe dirtiest too?) way is just to
put it on at Level 1 and fall back to CPOLD if there is a problem.

"Best practice" may call for putting it on at Level 2 first, but the
nature of the change may not warrant that level of effort.

There are, however, 45 or more prereq fixes also going on with these 2
APARs,  VM64879 VM64881.

Just interested in what everyone thinks.




Marcy Cortes <marcy.d.cor...@wellsfargo.com <
<mailto:george_he...@newyorklife.com>mailto:marcy.d.cor...@wellsfargo.com> >
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU <
<mailto:marcy.d.cor...@wellsfargo.com>mailto:IBMVM@LISTSERV.UARK.EDU> >

09/22/2010 11:01 AM



Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU <
<mailto:IBMVM@LISTSERV.UARK.EDU>mailto:IBMVM@LISTSERV.UARK.EDU> >


To
             IBMVM@LISTSERV.UARK.EDU 
<<mailto:IBMVM@LISTSERV.UARK.EDU>mailto:IBMVM@LISTSERV.UARK.EDU>
cc

Subject
             Re: What is the z/VM 5.4 Compatibility PTF for z196?








Also you want to check PSP on IBMLink and look for 2817DEVICE and see what
recent stuff is needed for that system type (or whatever one you are
installing).

________________________________

From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU <
<mailto:IBMVM@LISTSERV.UARK.EDU>mailto:IBMVM@LISTSERV.UARK.EDU> ] On Behalf Of 
Bruce Hayden
Sent: Wednesday, September 22, 2010 7:27 AM
To: IBMVM@LISTSERV.UARK.EDU 
<<mailto:IBMVM@LISTSERV.UARK.EDU>mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: Re: [IBMVM] What is the z/VM 5.4 Compatibility PTF for z196?


Look at the page <mailto:IBMVM@LISTSERV.UARK.EDU> 
http://www.vm.ibm.com/service/vmreqze.html for the
complete list of z/VM APARS for the zEnterprise.


On Wed, Sep 22, 2010 at 10:07 AM, George Henke/NYLIC
<george_he...@newyorklife.com> wrote:



            Marcy,

            Thank you for this information.

            Do you happen to know what PTF is needed to run z/VM 5.4 on
the z196.

            We will probably take your advice.

            We will probably bring up the z196 with 5.4 first and then
move 6.1 up to Level 1 afterwards.




--
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY 
<<http://www.vm.ibm.com/service/vmreqze.html>http://www.vm.ibm.com/service/vmreqze.html>
_____________________________________________________ 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.
_____________________________________________________ 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.
<http://www.vm.ibm.com/service/vmreqze.html>

________________________________
NOTICE:
This e-mail is intended solely for the use of the individual to whom it is 
addressed and may contain information that is privileged, confidential or 
otherwise exempt from disclosure. If the reader of this e-mail is not the 
intended recipient or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this communication in error, please 
immediately notify us by replying to the original message at the listed email 
address. Thank You.

Reply via email to