I'm ignorant of this. But did a search in IBMLink. It appears that there are "shared libraries" in z/OS UNIX which are loaded somewhere? (not documented where). The size of this area is specified in the SHRLIBRGNSIZE parameter. The load modules loaded into this area are .so UNIX "dynamic subroutines" which are marked as shareable in the filesystem via the "+l" extattr attribute. This area is them mapped into every UNIX address space into "high private". I would guess this would eventually involve IARVSERV. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A9B0/5.0 and http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A6A1/20.0?SHELF=IEA2BKB2&DT=20101208204043
The larger the area, the more high private is lost in every UNIX address space which attempts to load a shared library. And the more ECSA is used for mapping tables. It appears that if it is too small, it is not used at all and each shared library is loaded into the user's address space as if it were not shared. This increases I/O. So I guess "shared library" region size is like an LLA for UNIX shared libraries. But I don't read of any way for "obsolete" modules to be purged and their storage reclaimed. And there doesn't appear to be any way to actually determine what is loaded. I would guess into some address space or data space controlled by the UNIX kernel. You could find all the possibilities by searching all of your mounted filesystems for files with the extended attribute of "l" specified. find / -ext l >~/list.of.shared.library.files The above will likely run a fair amount of time. I'd do it in batch. In: https://www-304.ibm.com/ibmlink/sis/viewAparDoc.wss?context=aparAndUsage&documentIds=OA18803&searchWords=SHRLIBRGNSIZE&libraryType=D&lc=en&cc=US <quote> For a BPX1LOD (loadhfs) syscall request, when the module cannot be loaded as a user-shared library program, it should be loaded into user private storage as non-shared. This is not happening, and the loadhfs() syscall is failing with rsn091E03B7 JRShrStgShortage due to MAXSHAREPAGES being exceeded. </quote> https://www-304.ibm.com/ibmlink/sis/viewAparDoc.wss?context=aparAndUsage&documentIds=OA04183&searchWords=SHRLIBRGNSIZE&libraryType=D&lc=en&cc=US <quote> Change current statement as follows: The storage used in the user address space to establish the mapping to the shared library region is from the high end of private storage; | in most cases, it does not interfere with the virtual storage used by the application program. Add the following paragraph: The amount of storage that is carved out of the high end of private storage of each address space that loads a system shared library object is based on the SHRLIBRGNSIZE parmlib parameter value. If this value is set too high, the storage set aside for the shared library region mapping could interfere with the private storage requirements of each of these address spaces. For this reason, the value specified for SHRLIBRGNSIZE should be the minimum size required to contain all of the system shared library programs that are to be used on the system. </quote> https://www-304.ibm.com/ibmlink/sis/viewEskbDoc.wss?context=aparAndUsage&documentIds=swg21178068&searchWords=SHRLIBRGNSIZE&libraryType=E&lc=en&cc=US <quote> Problem(Abstract) What are the consequences (for example, are there abends) of specifying a SHRLIBRGNSIZE that is not large enough for all the shared-library-eligible (that is, have the "l" extended attribute set) programs that are accessed? Resolving the problem If the shared library cache is not big enough, then z/OS will revert to normal storage use and the load module will be loaded into the broker address space. </quote> On Sat, 2011-10-29 at 23:46 -0400, Lizette Koehler wrote: > SHRLIBRGNSIZE -- John McKown Maranatha! <>< ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
