Yep, I have one of those. It is called $TSOCYA. And for those of us who came into the mainframe world just as SPF (yes SPF, before it was ISPF/PDF) was coming into use, we learned how to use the TSO EDIT command. Which is useful if you cannot get into ISPF. Also, from time to time, for whatever reason, when ISPF SUBMIT does not work, you can use the TSO SUBMIT command.
Of course, all of this is contingent on VTAM and JES2 coming up. If they do not, then a rescue system, alternate LPAR access, or a SA edit/utility program is in order. Last but not least, an updated copy of one's resume/CV, preferably not stored on the mainframe. "Confidentially doc, I am the wabbit." Bugs Bunny Sent with Proton Mail secure email. On Friday, March 7th, 2025 at 3:53 PM, Leonard D Woren <ibm-main...@ldworen.net> wrote: > 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
