tyvm, Mike. Sorry for misinterpreting your previous email, but I am glad I was wrong and everyone is on the same page about this, everything is "warm and fuzzy".
Mike Walter <mike.wal...@hewitt.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 09/27/2010 01:11 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 > You seem confident that this is doable with minimal risk ... I'm not sure how you can draw that conclusion from my post, I never mentioned 1st or 2nd level therein. Only that you can "COPYFILE CPLOAD MODULE fm -1CPLOAD MODULE fm (OLDDATE" before PUT2PROD ever gets involved. That was in response to your comment: "that PUT2PROD at Level1: steps on the current CPLOAD no matter what you do." Unless a CP change can be clearly identified as a trivial change (source code is terrific!), we always apply maintenance to the 2nd level system, perform that previously mentioned set of minimal-to-significant testing on 2nd level and only then re-apply the maintenance to 1st level. One of the worst feelings a sysprog can experience is when a system to which they recently applied maintenance crashes or fails to perform properly after the maintenance required an IPL. Perhaps the worst experience is when that newly re-built system won't even IPL. With z/VM's capability to run 2nd level test systems, there are few excuses for not having applied and tested CP maintenance before scheduling a 1st level IPL. Not everything can be tested 2nd level (e.g. can't always share the same 1st level hardware). But one can ALWAYS IPL the new CPLOAD MODULE 2nd level. On both 1st and 2nd level we maintain the same "COPYFILE CPLOAD MODULE fm -1CPLOAD MODULE fm (OLDDATE" process for backout purposes. Consistency is the hobgoblin of my little mind. :-) 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/27/2010 11:53 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 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:marcy.d.cor...@wellsfargo.com> > Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU < 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> > To 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> ] On Behalf Of Bruce Hayden Sent: Wednesday, September 22, 2010 7:27 AM To: 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 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> _____________________________________________________ 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. 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.
