When I run the AMDSADMP macro, I use options for zero operator intervention:
...CONSOLE=SYSC,REUSEDS=ALWAYS... This puts messages on the HMC operator console (no worry about device condition) and specifies that the new dump overwrites any existing dump without prompting. The title will always be "*** TITLE PROMPTING WAS SUPPRESSED ***", but that's a small price to pay for an autopilot standalone dump. It's as close as you can get to fail-safe. I've never tried switching sysres volume with REIPL. . . 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: Barbara Nitz <nitz-...@gmx.net> To: IBM-MAIN@bama.ua.edu Date: 10/03/2011 09:51 PM Subject: Re: AUTOIPL (was Re: Health Check (IBMSVA,SVA_AUTOIPL_DEFINED) Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> >I'm not sure why Barbara is so opposed to AUTOIPL in principle, but I can >see where critical production might be problematic. *I* am not opposed to the function at all, just the opposite. My teamleader is. It took quite some strongarming for me to get him to agree to even test this, much less roll it out into production. Currently, it will be restricted to sysprogs only, so we don't have to come in on a weekend anymore just to drag the icon on the HMC (maintenance IPLs). I established the following policies: DIAG00: AUTOIPL SADMP(NONE) MVS(NONE) as default policy. Getting that line in was already a major fight. DIAGSA: AUTOIPL SADMP(5704,SMSYSC4) MVS(LAST) DIAGLA: AUTOIPL SADMP(NONE) MVS(LAST) DIAG&&: AUTOIPL SADMP(NONE) MVS(5703,573400M) with && being a system-specific name to re-IPL from another residence. Once this is established in production, I'll go to work on my team leader in getting the sadump permanently set in diagxx. >I've seldom seen a system truly hang (from XCF's point of view) for an >extended period and then miraculously recover. For what it's worth, I have. More than once. They were always loops during memterm processing in master address space, and a restart interrupt cured / would have cured them. We do NOT allow SFM to take automatic action (other than fencing). >AUTOIPL SADMP(cuua,SMSYSC) MVS(LAST) Thanks for mentioning that, Mark. From the books, I wasn't quite sure what to specify for loadparm and came up with AUTOIPL SADMP(cuua,SMSYSC4) MVS(LAST) (note the 4 after the console name). I just hope that that will not need the console and won't need any input other than what I did on the sadump program (which needs three times the enter key). Now to get my dear colleagues to remember to take an sadump when its needed!!!! > (Although I disavowed responsibility for the AutoIPL heath check >that Barbara didn't like, I was heavily involved in the design and >implementation of the AutoIPL function. So I don't object to being >the target of complaints about the function itself). Worked like a charm, as others have said. Testing the sadump option on the VARY will be next, and I like to get someone else to do it. Maybe they remember to take one when its needed then? When you IPL a new operating system via autoipl (does that work?), is there any gotcha other than to remember to always CLPA? If a system is in a tight loop (like memterm in master), will the sadump option on the vary command issued on *another* system, not the looping one (and assuming that an sadump policy is established) work? Or will it just get stuck behind whatever other messages XCF couldn't get at because it couldn't get the processor? Best regards, Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
