Hi Attila, 1.) Does not work, because LE does not support mixing of 64bit (JVM C code) and 31bit (Assembler, COBOL, PL/I) in the same LE enclave which is required for transactionality. When using 2 sets of modules (31bit and 64bit) it also introduces testing the modules from the same source twice and that e.g. Db2 does not have a precompiler for 64bit, so you cannot do Db2 calls in those modules anymore. Have not checked MQ.But the IBM labs are evaluating a way to support mixing 31bit modules and 64bit JVM, but it will still take some time.2.) I will have to investigate that. Thanks, Denis. -----Original Message----- From: Attila Fogarasi <fogar...@gmail.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Fri, May 1, 2020 12:43 am Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
If your application consists of 200+ modules with up to 8m working storage per module, then storage management becomes a key application capability. There are some solutions available, with or without programming. Presumably you have already used the LE storage tuning user exit to get insight into the heap and other storage usage. Perhaps worth looking at: 1. use of 64bit JVM ... this works very well in z/OS and would offload considerable 31 bit storage competition with your Cobol etc. modules. 2. you can write an application shell to alter LE behaviour, the interfaces provided by LE for this are documented in the LE Vendor Interfaces manual (which is available for anyone, not limited to vendors, but requires usage with care and skill to work effectively). I would say your application storage usage can be easily changed to be more efficient and avoiding the abends that you describe, without a complete re-architecture of this monolithic application. It just falls outside of the norm in terms of stressing storage management by LE and JVM (I've seen worse, and it is fixable). On Fri, May 1, 2020 at 3:40 AM Denis < 000001664d8ede6c-dmarc-requ...@listserv.ua.edu> wrote: > <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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
