So you would hope the application could be abstemious with 24-bit to the point of allowing the aforementioned 6MB of 24-bit. But this still doesn't seem very scalable - unless termination was sequenced to use less instantaneous (not-E)LSQA. But then sequencing - call it "pacing" - would prolong the outage.
I have to ask, though, what is different about DB2 where DIST and DBM1 address spaces have many hundreds of balls in the air? (DIST through DBATs and DBM1 through prefetch, deferred write, castout engines.) Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/ or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Barbara Nitz <nitz-...@gmx.net> To: IBM-MAIN@LISTSERV.UA.EDU Date: 29/04/2020 09:27 Subject: [EXTERNAL] Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> >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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
