Were both FORCE IMS and FORCE IMS,ARM rejected?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Denis [000001664d8ede6c-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, April 30, 2020 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!

<snip>
Wanna bet?

FORCE,ARM runs in the address space so would have been affected.
FORCE does not.</snip>
We had PMRs open on that, countless dumps. CANCEL and FORCE are rejected 
because the region is still registered with IMS.Sometimes the Mainview KILL 
worked, I think it calls CALLRTM directly under the covers without driving the 
FORCE or CANCEL command.Those address spaces were IMS message regions with an 
JVM to allow PL/I or COBOL Java interoperability.In one of the dumps a former 
collegue found a S806 trying to load a z/OS routine, I think but I am not sure, 
it was RTM related.After that IEFUSI was implemented and the hint was also 
added to the documentation for Java interoperability.But until today there are 
less but still noticable occurrences of regions that cannot be removed, some of 
them even live after IMS restart without being able to get rid of them.While 
the LE enclave runs with ALL31(ON) but there is no HEAP Option the prevents LE 
from allocating 24bit storage if the 31bit private between 2G and 16M is full, 
some of the assembler/COBOL programs in the mix with Java still use GETMAIN 
under the covers, which might allocate 24bit storage outside the LE enclave.We 
did not find an option (LOC=) for GETMAIN to fail the request, if above 16M and 
below 2G area has not enough room?!My guess is that the OutOfMemory conditions 
would behave more stable if LE and GETMAIN can be restricted to not allocate 
storage below 16M if the area between 16M and 2G is full.We also discovered LE 
storage fragmentation, with some newer COBOL modules in an application mix with 
e.g. 200 different modules within an address space, using e.g. 8M working 
storage areas, applications use cancel to not run out of storage with the side 
effect that after the cancel a program with 512k working storage occupies the 
beginning of the free 8M area and as such with the next larger working storage 
module being loaded and initialized, another 8M need to be allocated, because 
it needs to be continous for working storage. Leaving the module loaded is not 
an option, because the sum of all working storage areas would exceed 31bit 
private available which is around 800M.Because of the JVM the LE enclave never 
terminates, it lives for the lifetime of the IMS region, so in pre JVM times or 
without a JVM, one could parameterize that after a schedule for an IMS program 
ends, the LE enclave is recreated and as such is the HEAP area.
For now IMS regions are restarted every two hours to try to avoid running out 
of storage. So still looking for a better solution.Maybe 3 items would help, 
LOC=(ABOVE16 or whatever name is suitable), HEAP(...ABOVE) and a preserved area 
in LE that can be used for modules with large working storage but is not filled 
with smaller working storage modules, LE heap never shrinks.There need to be 
options to avoid clattering the storage below 16M, but there aren't.
Thanks, Denis.
-----Original Message-----
From: Peter Relson <rel...@us.ibm.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, Apr 30, 2020 3:09 pm
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!

<snip>
z/OS FORCE did not work
</snip>

Wanna bet?

FORCE,ARM runs in the address space so would have been affected.
FORCE does not.

<snip>
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.
</snip>

Of couse it is, if you change "some" to "most" or even "almost all". That
is because our customers demand it. That is why many programs written 40
and 50 years ago still work. Compatibility is the cornerstone of this
operating system (and even the machine architecture, particularly for
things available to problem state programs).

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
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

Reply via email to