MJE - BPXI039I SYSTEM LIMIT SHRLIBRGNSIZE HAS REACHED 95%

Version 3
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    MainView for Java Environments


    COMPONENT:

    MainView for Java Environments



    QUESTION:

     BPXI039I SYSTEM LIMIT SHRLIBRGNSIZE HAS REACHED 95%  - any guideline?


    ANSWER:

     

    The idea behind the shared library region is the USS programs loaded there would be used by multiple processes. MV/JAVA does not deliver any such programs. they may be used on our behalf but, by definition, They are programs that are also used by others as well. We don't know what the customer is doing in their applications or what files have the ST_SHARELIB extended attribute set. Maybe the following snippets from the USS manuals will help you understand:

      

     Shared object libraries contain subroutines that can be shared by multiple processes. Programs using shared libraries contain references to the library routines that are resolved by the loader at run time. The loadhfs topic in z/OS UNIX System Services Programming: Assembler Callable Services Reference discusses both shared object library programs and the ST_SHARELIB extended attribute.

      

    The following apply to shared program libraries:

      
       
    • Executables that have the ST_SHARELIB extended attribute turned on are considered system shared library programs. System shared library programs are the most optimal way to share large executables across many address spaces in the system. These executables are shared on a megabyte boundary to allow for the sharing of a single page table (similar to LPA). 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.
    •  
    • If the program to be loaded is determined to be a shared library program (that is, if the ST_SHARELIB extended attribute is on), the loadhfs service queries the shared library region to determine if the target program is there.

      When a shared library program is loaded anew into the shared region or reloaded from the shared region, the program is mapped from the shared region into the private area of the calling address space. It is important to note that, because the program is not actually reloaded from DASD into the private area of each calling address space, but only remapped from the shared region, shared library programs are more efficient in their utilization of system resources than normal private area programs. For this reason, programs that are to be shared across several address spaces in the system are good candidates for identification as shared library programs.

      If a target program is not in the shared library region and cannot be loaded into the region because of its attributes, the program is treated like a private area program and is loaded into the caller's private area storage.

      Additionally, if the calling address space cannot accommodate the target address for the shared library program, the program is treated like a private area program.

    •  
    • In order for a program to be honored as a shared library program, certain conditions must be met:     
           
      • The program must be a z/OS UNIX program module; MVS library modules cannot be loaded into the shared region.
      •    
      • A sticky bit program that is found in the MVS search order is not honored as a shared library program.
      •    
      • The program cannot be a multiple-segment (split RMODE) load module; multiple-segment load modules are not supported in the shared library region.
      •    
      • The program must have read "other" permission and be link-edited as REENTRANT.
      •   
    •  
    • A shared library program can reside in a file system that was mounted with the NOSETUID operand.
      

    Executables that have the ST_SHARELIB extended attribute turned on are called system shared library programs. They are an optimal way of sharing large executables across many address spaces in the system. These executables are shared on a megabyte boundary to allow for the sharing of a single-page table (similar to LPA). 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.

      

    Guideline: 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 value of the SHRLIBRGNSIZE parameter in the BPXPRMxx parmlib member. If this value is set too high, the storage set aside for the mapping of the shared library region might 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 that is required to contain all of the shared library programs that are to be used on the system. Note that z/OS® UNIX attempts to map the entire SHRLIBRGNSIZE into the private region, not just the portion that contains programs. If the private region is too small to map the entire shrlibrgnsize, then this shared library region is not be used, A message is not issued to indicate that the shrlibrgnsize was not mapped.

     


    Article Number:

    000154813


    Article Type:

    FAQ/Procedural



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles