Re: IODF Dynamic Activation Reversion
On 9/19/2016 1:46 PM, Jesse 1 Robinson wrote: I belong to 'hard-last' school because once HSA is updated, all systems want to IPL next with the new IODF. z/OS itself has no 'recollection' of what IODF it was using previously. If a soft activate needs to be backed out, the next IPL will come up matching HSA as long as you use the appropriate wild card characters in LOADxx. Changing a device from one type to another is actually accomplished by deleting the old device and adding the new one. Deletion generally requires 'FORCE' on the activate command. If the new IODF is wrong for any of the LPARs on the CEC, you may find yourself having to POR to set things right. 'TEST' is the right first step, but depending on what you're changing, you're usually instructed to specify FORCE on the hard activate, so you need to proceed with caution. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com I stand in agreement with my good friend and colleague, the distinguished gentleman from Southern California. You do SOFT activate on all images in the CEC, then HARD activate the final LPAR in the CEC. I did a Bit Bucket on using the HCD sysplex-wide activate as a time-saving procedure (We're Bad, We're Sysplex-Wide). You can grab it here (WTW): https://share.confex.com/share/122/webprogram/Handout/Session14648/Bit_Bucket_x2E.pdf Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IODF Dynamic Activation Reversion
I belong to 'hard-last' school because once HSA is updated, all systems want to IPL next with the new IODF. z/OS itself has no 'recollection' of what IODF it was using previously. If a soft activate needs to be backed out, the next IPL will come up matching HSA as long as you use the appropriate wild card characters in LOADxx. Changing a device from one type to another is actually accomplished by deleting the old device and adding the new one. Deletion generally requires 'FORCE' on the activate command. If the new IODF is wrong for any of the LPARs on the CEC, you may find yourself having to POR to set things right. 'TEST' is the right first step, but depending on what you're changing, you're usually instructed to specify FORCE on the hard activate, so you need to proceed with caution. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elaine Beal Sent: Monday, September 19, 2016 10:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IODF Dynamic Activation Reversion Thanks for the responses. Of course our change process will not allow saying it's never happened before as justification for not having a reversion plan. I always do a TEST before activations I've debated HARD first or SOFT first but doing HARD first is really contrary to our change procedures- that being changes should be rolled out DEV-->QA-->PRE-PROD-->PROD so it makes more sense to me (and is somewhat required for change management) to do SOFT until the last PROD and then do a HARD activate. Sometimes I hate change management! These particular changes are two fold 1) allowing some additional LPARs to some existing OSAs 2) redefining two OSAs from OSD to OSE I had the two options to 1 - continue through until changes are activated on all LPARs (SOFT on all except one HARD on the last PROD LPAR) 2 - POR from Jesse I see a (better) 3rd option 3 - IPL back to the old IODF If I'm understanding correctly, IPL is the only way for me to revert immediately without impact to other systems. Thanks, Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IODF Dynamic Activation Reversion
Thanks for the responses. Of course our change process will not allow saying it's never happened before as justification for not having a reversion plan. I always do a TEST before activations I've debated HARD first or SOFT first but doing HARD first is really contrary to our change procedures- that being changes should be rolled out DEV-->QA-->PRE-PROD-->PROD so it makes more sense to me (and is somewhat required for change management) to do SOFT until the last PROD and then do a HARD activate. Sometimes I hate change management! These particular changes are two fold 1) allowing some additional LPARs to some existing OSAs 2) redefining two OSAs from OSD to OSE I had the two options to 1 - continue through until changes are activated on all LPARs (SOFT on all except one HARD on the last PROD LPAR) 2 - POR from Jesse I see a (better) 3rd option 3 - IPL back to the old IODF If I'm understanding correctly, IPL is the only way for me to revert immediately without impact to other systems. Thanks, Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IODF Dynamic Activation Reversion
It's (thankfully) been a while since I stumbled into this quagmire, but I'm pretty sure that the rule is this: for any dynamic IODF activation, the *current* software IODF must match the *current* HSA IODF. That a software IODF retro-activation will eventually match the hardware IODF is not sufficient to allow dynamic activation to proceed. You don't however have to POR to extricate yourself. Two choices. 1. Slog on bravely through the activation steps until all OS systems on the CEC match the newly activated HSA IODF. Then go back to the previous level traversing the same steps in reverse. The intermediate state(s) may be messy, but as long as the systems stay up, you should be able to push on back the old status quo. 2. If (1) is not workable, you can IPL individual systems to get them back where you started. This depends on having DASD resident copies of the IODF than match the old unchanged HSA copy. Remember that name alone is not sufficient for a match. There is a token at the beginning of each IODF, which must match byte for byte between HSA and OS copy. ACTIVATE TEST should steer you away from this conundrum, but there are cases where you must specify FORCE on the hardware ACTIVATE. That keyword as always should give you pause. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Neubert, Kevin Sent: Thursday, September 15, 2016 5:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IODF Dynamic Activation Reversion What change are you making? Until you activate hardware, would expect all your software activations to be reversible. You shouldn’t have to POR until you lose the ability to dynamically get to where you want to be. Which more likely be due to lack of maintenance time, frustration, etc. and convenience of instant resolution. For example, bad change to your only OSA. You can’t logon to fix and go forward and you’re out of sync/unable to go backward. Have you tested the activation on all your systems and/or tested the software only change on a test system? The prior will highlight the changes and give you a better idea of the risk. For example, some changes to an existing definition actually result in a delete then add of the definition. So the respective definition would need to offline, not in use, etc. Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elaine Beal Sent: Thursday, September 15, 2016 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IODF Dynamic Activation Reversion I'm rolling out IODF changes dynamically, all SOFT and HARD on the final LPAR. Our change management rules have gotten more stringent and I need to define a reversion plan. If on say, the third LPAR something goes awry and we need to back out, are there options besides 1) POR or 2) continue on to HARD activate and then perform the process across all LPARs with the old IODF (soft on all except HARD on last) I have an old ETR that says I can back out on a SOFT activate but at that point dynamic activation is disabled. Thanks, Elaine 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
Re: IODF Dynamic Activation Reversion
What change are you making? Until you activate hardware, would expect all your software activations to be reversible. You shouldn’t have to POR until you lose the ability to dynamically get to where you want to be. Which more likely be due to lack of maintenance time, frustration, etc. and convenience of instant resolution. For example, bad change to your only OSA. You can’t logon to fix and go forward and you’re out of sync/unable to go backward. Have you tested the activation on all your systems and/or tested the software only change on a test system? The prior will highlight the changes and give you a better idea of the risk. For example, some changes to an existing definition actually result in a delete then add of the definition. So the respective definition would need to offline, not in use, etc. Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elaine Beal Sent: Thursday, September 15, 2016 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IODF Dynamic Activation Reversion I'm rolling out IODF changes dynamically, all SOFT and HARD on the final LPAR. Our change management rules have gotten more stringent and I need to define a reversion plan. If on say, the third LPAR something goes awry and we need to back out, are there options besides 1) POR or 2) continue on to HARD activate and then perform the process across all LPARs with the old IODF (soft on all except HARD on last) I have an old ETR that says I can back out on a SOFT activate but at that point dynamic activation is disabled. Thanks, Elaine -- 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
Re: IODF Dynamic Activation Reversion
Can't you just reactivate the previous IODF? > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Elaine Beal > Sent: Thursday, September 15, 2016 12:26 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IODF Dynamic Activation Reversion > > I'm rolling out IODF changes dynamically, all SOFT and HARD on the final LPAR. > Our change management rules have gotten more stringent and I need to define a > reversion > plan. > > If on say, the third LPAR something goes awry and we need to back out, > are there options besides > > 1) POR or > 2) continue on to HARD activate and then perform the process across all > LPARs with the > old IODF (soft on all except HARD on last) > > I have an old ETR that says I can back out on a SOFT activate but at that > point dynamic > activation is disabled. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IODF Dynamic Activation Reversion
I'm rolling out IODF changes dynamically, all SOFT and HARD on the final LPAR. Our change management rules have gotten more stringent and I need to define a reversion plan. If on say, the third LPAR something goes awry and we need to back out, are there options besides 1) POR or 2) continue on to HARD activate and then perform the process across all LPARs with the old IODF (soft on all except HARD on last) I have an old ETR that says I can back out on a SOFT activate but at that point dynamic activation is disabled. Thanks, Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
