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

Reply via email to