Cross-posted to MVS-OE and IBM-MAIN. Follow-ups on IBM-MAIN, if possible. Prompted by curiosity, I'm trying to understand the handling of the storage allocated for the Shared Library Region. I understand SHRLIBRGNSIZE defines the size of the region that is allocated in address spaces for loading system shared DLLs. I also understand that reserving this space can be suppressed via environment variable _BPXK_DISABLE_SHLIB.
Now here come some assumptions and questions I hope someone can shed some light on: - The whole Shared Library Region is GETMAINed in subpool 230 key 0 upon first reference, i.e. when the first system shared DLL is loaded. True/False? - Each DLL starts on a new megabyte boundary. It will be mapped via shared page table into any address space also loading this DLL. True/False? - Any space in the megabyte area not used by this DLL is unused. Does a reference to that unused area throw a page translation exception? - Once the Shared Library Region is established for an address space, does it automatically see any and all DLLs previously loaded by any other address space into the area (provided it has execute authority for the DLL? What if multiple threads are active in an address space with different thread authority? - If an address space is not allowed to "see" some shared DLLs loaded by other address spaces, how is that mapped into the shared library in that address space? Will accessing that storage throw a segment translation exception? - Is the storage of a shared library region DLL ever returned, e.g. after all references to that DLL have been cleared, explicitly by dlldelete() or by RTM? Finally, some performance question. It seems (at least here) that the system shared library facility is only used for Java DLLs. We're fighting with storage limits in our CICS AORs. In todays world of plenty of real storage, I think the drawback of running with SHRLIBRGNSIZE=16 (the minimum allowed) is not really noticable by batch jobs, WAS regions, CICs regions. Java is loaded once for WAS and CICS, and those are lonrunning STCs. Batch jobs might be a different case since, but we don't have a lot of Java batch (yet). Opinions? -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
