<snip> It was visible in JES but nothing could be done about it, it did neither accept cancel nor force. Fault Analyzer showed that the last thing that happened in the address space was trying to load some z/OS routines for termination (if it was not memory termination then it must have been task termination) and failed to load those routines because of an out of storage condition. </snip>
You might consider the possibility that JES2 or Fault Analyzer is in error if this is true. If force is not accepted then the address space no longer exists as far as the system is concerned. What exactly do you mean by "accept...force"? It is true that if memory termination fails because of some system error an address space could land in limbo. But that would not have anything to do with insufficient memory in the address space. And if the master address space (where memterm runs) has insufficient storage then some authorized program has screwed things up and you'll likely need to re-IPL (and find/fix that program). <snip> If task termination, which is an operating system function, requires storage in an address space with no storage left, it should ensure that there is always enough room for task termination. </snip> Unfortunately in the general case this is provably impossible. Just as it is provably impossible in the general case to detect infinite looping. I would guess that a huge percentage of customers have chosen a prudent approach with their user exits to prevent the vast majority of these cases, by limiting regions size somewhat, not allowing someone to allocate as user-region storage all available storage (whether below or above 16M or even above 2G). Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
