I have a story where I took down a lpar. No stupidity though. I ran a batch job using only IBM tools and software. It took down a dev lpar (500 users and, let say, 10 ongoing projects. And some other things.)
IEBCOPY (copy, unload etc for several large VB pds) and (under i think) a rexx and maybe some other tools. The rexx was maybe compiled, long time ago so bad memory. No third party software. I had no special authority (well a little bit more than the normal dev, but nothing like a sysprog). It very effectively unalived the lpar. I got a civilized message from the production boss "Don't do that again!". I changed the approach a bit. Thomas Berg Mundus Vult Decipi Den fre 7 mars 2025 21:54Leonard D Woren <ibm-main...@ldworen.net> skrev: > And one of those TSO logon procs should have *no* DDs at all, for > desperation time. You can manually allocate stuff if it comes to > needing that proc. > > /Leonard > > > Mike Shaw wrote on 3/7/2025 10:23 AM: > > I once fat-fingered a JCL error into our one and only TSO logon proc, and > > had to keypunch in IEBUPDTE JCL and control cards to fix that logon proc; > > submitted that job through a locally attached card reader. > > > > Moral of the story: aAlways have multiple logon TSO/E logon procs > available! > > > > Mike Shaw > > MVS/QuickRef Support Group > > Chicago-Soft, Ltd. > > > > > > On Fri, Mar 7, 2025 at 8:01 AM Leonard D Woren <ibm-main...@ldworen.net> > > wrote: > > > >> At my first shop as "Senior MVS Systems Programmer" (45 years ago!), I > >> once edited the JES2 proc putting in extra DDs for old and new parmlib > >> JES2PARM members, using the convention that the old member had an @ > >> appended and the new member had a $ appended. Didn't test the proc, > >> or I would have found out that the system didn't like 9 character > >> member names. Then it crashed in the middle of the workday (MVS 3.8 > >> base on a 370/165 -- that's 2 strikes against reliability.) Operator > >> tries to IPL. I get called into the machine room because "JES2 won't > >> start". Uh oh, no way to fix this one without editing the proc. > >> Catch-22. > >> > >> I had previously requested and been denied a 3350 to build a > >> standalone rescue system. Cheapskates. This is not looking good. > >> Then I remember that they had switched from VS1 to MVS not too long > >> before I was hired, so I asked the operators to bring up the old VS1 > >> system. It had been long enough that none of them could remember some > >> command to configure the partitions to get the system all the way up. > >> I had never touched VS1 so I didn't know. Tick tick, the system is > >> down. Finally my boss shows up after his lunch time, discovers the > >> terminals dead, comes into the machine room, gets a quick explanation, > >> types in the command to get VS1 up. We bring up ACEP, my boss tries > >> to remember his password from that far back, we fix the MVS JES2 proc, > >> and IPL. > >> > >> The next day, I got my 3350 for a rescue system. Remember when a > >> complete MVS system including HASPACE could be squeezed onto a single > >> 3350? > >> > >> Lessons learned, all still relevant today: > >> 1. HAVE A RESCUE SYSTEM (and regularly refresh and test it.) Although > >> these days multiple systems sharing DASD can minimize this need as > >> long as they're not all sharing the same mcat/sysres/etc. > >> 2. Test changes to things like the JES2 proc while the system is up. > >> 3. Either be sure to remember your old passwords, or don't change > >> them. Ever. Very difficult to get today's security officers to > >> understand this one. This one has bit many shops that had to restore > >> the system from backups to get things up and running. > >> > >> /Leonard > >> > >> P.S. A few years ago I booted up an old OS/2 machine for the first > >> time in years. Uh, oh, what's the password? Fortunately, I > >> eventually remembered how pissed I was that IBM required passwords for > >> OS/2 (Winblows didn't, back then), then I remembered my password. > >> > >> > >> ---------------------------------------------------------------------- > >> 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 > > > ---------------------------------------------------------------------- > 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
