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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Neubert, Kevin Sent: Thursday, September 15, 2016 5:17 PM To: [email protected] 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:[email protected]] On Behalf Of Elaine Beal Sent: Thursday, September 15, 2016 12:26 PM To: [email protected] 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 [email protected] with the message: INFO IBM-MAIN
