Gee, thanks, David, for sending me back to the land of confusion. 😉 In our case, Bob's suggestion of building the default directory setting the permissions to 1777 will work fine. We don't have any home-grown java applications and it appears from looking in the directory that the only thing using it is Mainview so we don't have to worry about application A stepping on application B.
Rex -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of David Frenzel Sent: Tuesday, June 2, 2026 8:08 AM To: [email protected] Subject: [EXTERNAL] AW: unix file permission question Hi, I am going to answer from the perspective of a Java person. The path you referenced is the default for the JVM to store the shared class cache (there is a lot of information here https://urldefense.com/v3/__https://eclipse.dev/openj9/docs/shrc/__;!!KjMRP1Ixj6eLE0Fj!rKrf1EUw_ppWqQXsMY3bSFLcdVmuiUBdhM0iQUwBZy8iyOBkzaNsJSlhWK5KD42Dd1bkhzJRr17YnOIDiXdyDvfwIZQCjhW0F0tp$ ). This is a file system location which contains the compiled classes which reduce JVM startup time. Whether the permissions should be 777 or 755 - or perhaps 775? It really depends on what your application (the process(es) using the shared class cache) does. Typically, you want to have one application instance populating the shared class cache, and others simply reuse them. This is when you would restrict the permissions to 755 or 775. OTOH, services tend to specify non-default paths to store their shared class caches, so they don't cobble up in /tmp. Some applications specifically make sure that the shared class cache has certain permission bits set. In your case it may be that, or it's as Bob said - your umask differs. There are also options to control the permissions. One is -Xshareclasses:groupAccess that specifically allows group access while the default is user access (775 as opposed to 755). There is also -Xshareclasses:cacheDirPerm=<permission> which allows you to specify the permission precisely. Also, there is an extra on z/OS which specifies that the directory permissions aren't changed to avoid generating RACF error messages. So, on other platforms the JVM is going to attempt to change the directory's permission if they aren't correct. On z/OS it won't. See: https://urldefense.com/v3/__https://eclipse.dev/openj9/docs/xshareclasses/*cachedirperm__;Iw!!KjMRP1Ixj6eLE0Fj!rKrf1EUw_ppWqQXsMY3bSFLcdVmuiUBdhM0iQUwBZy8iyOBkzaNsJSlhWK5KD42Dd1bkhzJRr17YnOIDiXdyDvfwIZQCjnnZoO4a$ I would generally suggest that people know what JVM applications they have, whether they use (or should use) the shared class cache and where these caches are stored. I'm not a big friend of simply letting everything pile up /tmp/javasharedresources and hope for the best. If you decide to put mkdir /tmp/javasharedresources into /etc/rc, please consider using mkdir -p /tmp/javasharedresources instead as it won't produce an error (File exists). Cheers - David ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
