Why do I get JVMSHRC022E error messages when I start CICS TG z/OS?

Java Class Caching

From CICS TG v8 and up CICS TG enabled a setting that would cache java classes to allow multiple gateway daemons within an LPAR to consolidate class storage. This is designed to save resources and give a slight performance improvement. For this to work, the /tmp dir must be available for Java to create a sub-directory called javasharedresources where it stores the cache.

Sometimes customers encounter problems creating the cache. When this happens the following error message is seen:

JVMSHRC022E Error creating shared memory region

We've seen several causes for this:

1. Permission issues creating files under /tmp

2. Shared memory issues

3. Space issues.

.
1) Most often we see permission issues where the /tmp directory is restricted to the CICS TG user ID and a cache dir could not be created. In these cases there are two options customers consider: .

A. Move the cache to a location where CICS TG's user ID is permitted to write. See NOTE 1A below for instructions.

B. Disable the cache altogether. Each gateway will run without caching, similar to the behavior of CICS TG prior to v8. See NOTE 1B below for instructions on how to disable caching.

.
2) There are cases when shared memory issues occur, causing the following to be generated in addition to the JVMSHRC022E:

JVMSHRC337E Platform error message: shmget : EDC5129I No such file or directory.

The key here is the shmget portion of the message, which tells us there was an error doing a get of shared memory.

This sometimes seen after an IPL or after a JVM is killed or has crashed. Old meta-data points to a shared memory identifier that no longer exists. Until that has been corrected the class cache can not be accessed. The best thing to do in this case is to destroy the old cache along with its identifier and meta-data. The following command is used to do that.

CICS TG v8.x: java -Xshareclasses,name=cicstg800,groupAccess,destroy

CICS TG v9.x: java -Xshareclasses,name=cicstg900,groupAccess,destroy

The next time CICS TG starts the JVM will find no cache and will generate a new one automatically.

.
3) We have also seen rare cases where there is insufficient space in the /tmp directory. This can either be due to an actual lack of space in that directory or the shared memory page limit in BPXPRMxxx lib.

A. A default cache size of 16M is specified at startup. Make sure there is enough space in /tmp for this or point the cache to a location where there is sufficient size (NOTE 1A below).

B. Sometimes there is enough space in /tmp but we still get a space issue. Check IPCSHMMPAGES in BPXPRMxxx lib. If this is set too low it will prevent a cache of 16M from being created. The java recommendation for this is at least 4096.

.

NOTE 1A. Moving the cache location

By default java creates a javasharedresources dir under /tmp. On sites where the /tmp directory is locked this creation will fail. If a customer wishes to run with shared classes enabled they can specify a new location.

The ctgstart script currently specifies the following java directive: -Xshareclasses:name=cicstg800,groupAccess,nonpersistent,nonfatal

or

-Xshareclasses:name=cicstg900,groupAccess,nonpersistent,nonfatal

Users are not able to edit the ctgstart script so STDENV must be updated instead, adding to the CTGSTART_OPTS var the necessary java directive that will create a cache with a name and location of the customer's choosing.

So, if an administrator wishes to create a classcache called "ctgv9cache" in the directory /ctgtmp/ctgV9/javasharedresources, the following CTGSTART_OPTS would be specified (on one line):

CTGSTART_OPTS=-j-Xshareclasses:name=ctgV9cache,cachedir=/ctgtmp/ctgV9, groupAccess,nonpersistent,nonfatal

(If you have other options already specified in CTGSTART_OPTS you would add a space and append this directive. Make sure to include the -j prefix with no space between -j and -X.)

You would need to do this for all gateways on the LPAR that are going to share this cache.

.

NOTE 1B. Disabling Shared Classes

While most issues with class caching have been the minor ones noted above, there have been rare cases when the JVM hangs during initialization as it attempts to access a cache. When that occurs the gateway is never able to start. In cases like that it may be preferrable to disable class caching altogether. This can be done by editing CICS TG's STDENV, adding the -Xshareclasses:none directive to the CTGSTART_OPTS var:

CTGSTART_OPTS=-j-Xshareclasses:none

(Make sure to include the -j prefix with no space between -j and -X. If you have other options already specified in CTGSTART_OPTS you would add a space and append this directive.)