I discovered a shared library facility for loading OMVS modules (for example .so) into storage which can be shared by all OMVS address spaces.
This is an unusual blog, in that I’ve written about a topic – then say “do not use it!
Phil Wakelyn of CICS strategy said….
The UNIX shared library region, this is not something we currently recommend – see this doc, and its now disabled by default in CICS at the JVM level using the variable
_BPXK_DISABLE_SHLIB=NOThe reasons for this is that that:
- It has negligible difference on JVM startup time
- It has a substantial negative impact on virtual storage below the bar, as storage is allocated from the high private area in MB chunks for each library (dll), so there is lots of wasted space and you can quickly use up 100MB or more. This has been a large customer support issue for CICS customers where space is very tight below the bar and MVS private storage SOS conditions are fatal.
- Shared libraries are loaded once per address space, so are cached at the address space level
Where are modules stored?
They are stored in a common area below the 31 bit line – so taking storage from all regions.
If you issue the command
D OMVS,L
it gives
BPXO051I 10.32.34 DISPLAY OMVS 293
OMVS 0010 ACTIVE OMVS=(00,01,BP,IZ,RZ,BB,ZW,PY)
SYSTEM WIDE LIMITS: LIMMSG=NONE
CURRENT HIGHWATER SYSTEM
USAGE USAGE LIMIT
...
SHRLIBRGNSIZE 58720256 65011712 67108864
SHRLIBMAXPAGES 0 0 409600 *
I made it larger than the default (4096) by using the operator command
SETOMVS SHRLIBMAXPAGES=409600
How do you load modules into the shared region?
You need to set the extended attribute +l for example
extattr +l /usr/lpp/java/J8.8_64/J8.0_64/bin/j9vm/libdbgwrapper80.so
When this module is loaded, it will be loaded into the shared region – if there is enough space.
Be careful how you reference the modules
You should use a consistent reference to files. For example
/usr/lpp/java/J8.8_64/libj9a2e.so is the same file as /Z24C/usr/lpp/java/J8.8_64/libj9a2e.so, but the shared library will treat them as two different objects, and load both of them. This will waste space.
How do you unload a module from the shared region
I reset the attribute using extattr -l. This did not unload it. When it was next loaded, it appeared to be unloaded from the shared region, and the file on disk was used.
How do you know what is in the shared region?
There is no IBM answer. There is a rexx exec OMVS command written by an IBMer
The syntax is
wjsigshl -p
This gives output
Usage Meg Used-Unused-Pgs Pathname
1 1 8 248 647857ED xxx/libracfimp.so
...
1 25 6349 51 647857EC xxx/compressedrefs/libj9jit29.so
...
Total Storage (Meg) 60
Total Module (Pages) 10146
Total Unused (Pages) 5214
Total Module Count 28
I changed /Z24C/usr/lpp/java/J8.8_64/J8.0_64/lib/s390x to xxx so the output would fit within the area.
Each modules gets storage in multiples of 1MB, so you waste space with small objects.
The used pages does not tie up directly with the size of the object on disk. For example for libjgsk8iccs_64.so
- using ls -ltr the size is 913408
- from the shared region mapping information is it 379648
It may be that there is information in the disk version which is not needed once the module is loaded.
How much space do I need?
I set the +l attribute for all of the .so objects in Java V8 SR 8. When I ran my Java program (which uses TLS) there were 28 modules loaded, and 60 MB of data used.
How do I turn it off for a job?
For your job, you can use the environment variable
_BPXK_DISABLE_SHLIB=YES
The documentation says
System shared libraries are disabled. When loading a program with the system shared library extended attribute (st_sharelib), the attribute is ignored and the program is loaded into the caller’s private storage. The _BPXK_DISABLE_SHLIB setting is propagated on both fork and spawn from the parent to the child process.
End words
Now you know how it works – do not use it.
I asked on one of the z/OS news groups if anyone used this facility and unusually I got no replies. It looks like it is not used in the z/OS community.
ColinPaice 