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
