Hi Barbara, thanks for the insights.Nevertheless, to me it looks like z/OS still is a 24bit operating system with some 31/64bit addressing and instructions as long as under the covers such old mechanisms need to be maintained and taken into account. If region termination requires space in 24bit LSQA, z/OS should at least reserve it silently behind the scenes without a need to put that on the agenda or todo list of system programmers and with enough space that the termination of an address space never stalls because of RTM running out of memory. It should be default and IEFUSI or the parmlib member optional.I think of it telling the management, we need to maintain this 24bit memory hole to allow for proper cleanup of anything within z/OS. These are the things that make z/OS look old and to be replaced and not considered modern, even if it is for a very good reason not losing compatibility for old modules, etc. Thanks, Denis.
-----Original Message----- From: Barbara Nitz <nitz-...@gmx.net> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU> Sent: Wed, Apr 29, 2020 10:26 am Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! >We had a similar issue in IMS regions, stalling after out of memory abend, no >way to get rid of them, IMS STO REG, z/OS CANCEL and z/OS FORCE did not work, >except with some vendor tool cancel that just gets rid of the address space >without proper cleanup that gets you closer to IPL.I wondered back then, how >dare the z/OS RTM routine doing getmains or module loads in a region that >abended with end of memory, does not make sense to me.The answer is probably, >it has been that way ever since and use IEFUSI.Why would terminating an >address space in 64bit or 31bit mode require loading 24bit routines, sounds >awkward?! The address space *task structures* (TCBs, PRBs, SVRBs, IRBs, CDEs) are all allocated in below the line LSQA. It has been that way since before MVS/XA, I think. The RTM2WA is allocated above the line. Also, there is no one 'RTM routine' that gets executed. When RTM gets control (remember PSW swap?) it doesn't *know* yet what it got control for. So it just needs to figure that out, which costs some storage. And recovery always goes back to the last PRB, which means that RTM gets control under a new PRB to ensure that things are not muddied by the recovery (think dump analysis). And then system integrity demands that proper cleanup is done (as in resource managers need to run), not to mention possible recovery routines that the application set up. Or the routine doing the cleanup. Terminating an address space without violating system integrity or hanging up the address space (or the system) is a very complex business. In a previous life I also had to deal regularly with IMS regions not terminating due to various reasons. In 50% of the cases the 'callrtm' program (which has now morphed into a variant of the force command) did the trick. In all other cases IMS needed to get recycled. I always took a dump to determine the TCB address that I needed to terminate (the bottom one that needs to terminate so everything above can terminate), and most of the time a few of those ominous 'non-cancelable' bits were on. What is worth more? System integrity or IMS restart? As for routines running in 24 bit - if it is an application routine, it *should* be at least located above the line. But some of the *system* routines *must* run in 24bit, IIRC. IBM has made a real effort over the years to put as much as possible above the line, without rewriting all of the operating system. And yes, IEFUSI is there to deal with reserving sufficient LSQA to be able to terminate cleanly. Barbara ---------------------------------------------------------------------- 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