Did you oonsider responding with an automation tool and save your fingers? this is a well defined case where automation can help...
ITschak ITschak Mugzach Z/OS, ISV Products and Application Security & Risk Assessments Professional On Mon, Feb 15, 2016 at 10:30 PM, Joe Aulph <[email protected]> wrote: > In previous and current assignments I have, in test, destroyed a DB and > attempted an IPL, after 45 minutes of bleeding-finger console responses we > gave up and IPL'd off a good DB. > We have forced the DB offline, fail soft testing, and after 50-70 console > responses were able to get 1 TSO user logged on via UADS. > Then there was the day I cam into the office and my DB was GONE! Only > because I had a recent backup on an available volume, and a handy IBM tech > (thank you Russ) we had no real outage and lost only 4 hours of password > updates. > All of which underscores the point, you want a dozen different options > before you are forced to use UADS, and an on-line available copy of the DB > is a life saver. > > Cheers, > Joe > > On Mon, Feb 15, 2016 at 9:09 AM, John Eells <[email protected]> wrote: > > > I would not want to run with such an MPF exit or AUTORxx member active in > > production. You can have it there for emergencies and activate it with a > > SET command. This keeps the pain level of failsoft mode a lot more > > tolerable. We used to have a couple of such exits waiting in the wings > for > > recovery to automate operator approvals during system recovery, though at > > this point I can't recall specifically for what other messages they > > automated the responses. > > > > I absolutely agree with those who express a preference for a one-pack > > recovery system, by the way. But I'm a belt-and-suspenders kind of guy > and > > would still want one more last-ditch recovery option. > > > > > > Skip Robinson wrote: > > > >> This problem occurs so seldom that I never thought of automating a > >> response. As of R12 or so, we now have AUTORxx, which can reply to WTORs > >> very early in the IPL. Not sure who here would have to approve such a > >> change. The chances of mischief being perpetrated are minimal, but it > does > >> open a very small window for a clever miscreant. > >> > >> . > >> . > >> . > >> J.O.Skip Robinson > >> Southern California Edison Company > >> Electric Dragon Team Paddler > >> SHARE MVS Program Co-Manager > >> 323-715-0595 Mobile > >> [email protected] > >> > >> > >> -----Original Message----- > >>> From: IBM Mainframe Discussion List [mailto:[email protected]] > >>> On Behalf Of Ed Jaffe > >>> Sent: Sunday, February 14, 2016 07:37 AM > >>> To: [email protected] > >>> Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) > >>> > >>> On 2/13/2016 8:04 PM, Skip Robinson wrote: > >>> > >>>> This opinion is based on (thankfully) limited experience. If you are > >>>> forced to IPL without a usable RACF data base, you are totally > >>>> scr*wed. During IPL, operator will be prompted to allow even READ > >>>> access to *every* data set opened by *every* task except for a tiny > >>>> handful like JES that bypass integrity. By the time you get to the > >>>> point of actually logging on to TSO, operator's fingers will be > >>>> bleeding profusely. If at any time during this process, you are > >>>> god-forbid required to start over, yet more finger tips will have to > >>>> sacrificed. > >>>> > >>> > >>> We solved this with an MPF exit that would always reply 'Y' to each of > >>> those > >>> prompts (except for the first few IIRC). > >>> > >> <snip> > > > > -- > > John Eells > > IBM Poughkeepsie > > [email protected] > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
