On z/OS the Java shared classes use shared storage. Data is added to the shared classes as the application process classes, so successive Java applications can use this shared data.

You can harden this to disk, so it is available across an IPL, using the snapshotCache command.

When restoring the snapshot, you need to be careful to get the file/semaphore/shared memory owner and permissions correct. I found the easiest way is to the the started procedure which runs the Java application to always do a restoreSnapshotCache. It is very easy to get the permissions wrong, and Java will not start.

A typical (for me) command is

/usr/lpp/java/J17.0_64/bin/java -Xshareclasses:cacheDir=/u/tmp/zowec,name=zoweGW,restoreFromSnapshot

What happens when you restore a snapshot?

Restoring from an “normal” userid with no authority

/usr/lpp/java/J17.0_64/bin/java -Xshareclasses:cacheDir=/u/tmp/zowec,name=zoweGW,restoreFromSnapshot
JVMSHRC721E The JVM is not configured to access the non-persistent shared cache snapshot file “/u/tmp/zowec/javasharedresources/C290M17F1A64S_zoweGW_G43L00”. To open the file, use ‘groupAccess’ sub-option.
JVMSHRC699E Failed to restore the non-persistent shared cache “zoweGW” from the snapshot

Using an “normal” userid and groupAccess gave

/usr/lpp/java/J17.0_64/bin/java -Xshareclasses:cacheDir=/u/tmp/zowec,name=zoweGW,restoreFromSnapshot,groupAccess
JVMSHRC020E An error has occurred while opening semaphore
JVMSHRC336E Port layer error code = -197360
JVMSHRC337E Platform error message: semget : EDC5129I No such file or directory.
JVMSHRC727E An error has occurred in creating the new non-persistent shared cache
JVMSHRC808I Compressed references shared cache “zoweGW” is destroyed. Use option -Xnocompressedrefs if you want to destroy a non-com pressed references cache.
JVMSHRC699E Failed to restore the non-persistent shared cache “zoweGW” from the snapshot

Using a userid with su (id = 0) userid, also failed to work for the same reasons

The userid ZWESVUSR is a nolog userid, so you cannot logon to TSO with it.

Become the cache owner

A superuser can issue

su ZWESVUSR

Then issue the restoreFromSnapshot command, and remember to issue “exit” to get out of su mode.

Do it as part of your application startup

I have a started task with userid ZWESVUSR and issue restoreFromSnapshot command from BPXBATCH. It could be the first step of your Java application startup.

For example, the JCL

//CCPCACH  JOB 
//* 

//RESTORE  EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD 
//SYSPRINT DD SYSOUT=* 
//SYSOUT   DD SYSOUT=* 
//STDOUT   DD SYSOUT=* 
//STDERR   DD SYSOUT=* 
//PARMDD  DD *
SH  /u/tmp/zowec/restore.sh 
//* 
// 

The script

#!/bin/sh 
set -x 
/usr/lpp/java/J8.0_64/J21.0_64/bin/java -Xshareclasses:cacheDir=/u/tmp/zowec,name=zoweGW,restoreFromSnapshot,groupAccess 

If the shared cache is active you get a message

JVMSHRC726E Non-persistent shared cache “zoweGW” already exists. It cannot be restored from the snapshot.

which can be ignored.

The restoreSnapshotCommand takes a few seconds to run.