Troubleshooting
Problem
This describes a known issue of a message MCH6801 being thrown when attempting to create an instance of the IBM Technology for Java Virtual Machine. It is most often seen in the WebSphere Application Server Network Deployment (ND) environment.
Symptom
The following message is thrown when attempting to create an instance of the IBM Technology for Java Virtual Machine in IBM i 5.4 and later. The issue was originally reported in a WebSphere Application Server (WAS) Network Deployment (ND) environment where the DMGR and nodeagent application servers were configured to run as QEJBSVR user profile. There was also a federated WAS ND profile containing two application servers. Both application servers were configured to run under their own user profile and not use QEJBSVR.
MCH6801 Escape 40 08/18/09 16:28:37.421329 < 000000 QP2USER2 QSYS *STMT
From Program . . . . . . . : tia_fault
To module . . . . . . . . . : QP2API
To procedure . . . . . . . : runpase_common__FiPvT2
Statement . . . . . . . . . : 2
Thread . . . . : 00000008
Message . . . . : Object domain or storage protection error for offset
X'0700000010000138' in object APPSVR QEJBSVR 112935.
Cause . . . . . : A program tried to use a blocked instruction, access a
system domain object, or make invalid use of a protected page. The violation
type is 4. The violation type indicates the type of error: 1-Object domain
violation. 2-Test Pointer Target Addressability (TESTPTA) violation. 3-Read
protection error. 4-Write protection error. The space class is X'08'. The
space class designates the type of space for a storage protection error or
TESTPTA violation for a space pointer: 00-primary associated space (includes
space objects). 01-secondary associated space. 02-implicit process space for
automatic storage. 03-implicit process space for static storage. 04-implicit
process space for activation group-based heap storage. 05-constant space.
06-space for handle-based heap storage. 07-teraspace offset
X'0700000010000138'. 08-teraspace for OS/400 PASE memory address
X'0700000010000138'. X'800000000000000000008017E0000138' is a pointer to the
storage for a protection error or TESTPTA violation for a space pointer.
Some violations may be suppressed at low system security levels.
Java Core and Snap dumps are then created.
Cause
The main cause of the MCH6801 message and JVM creation failure is due to the lack of permission by the current user profile to the shared class cache the JVM is configured to use.
Here is the scenario that will cause this issue to occur.
There are three profiles each containing their own JVM, a WebSphere Deployment Manager (DMGR), nodeagent, and application server. The DMGR and nodeagent JVM are configured to run as the QEJBSVR user profile and have a shared class configuration of "-Xshareclasses:name=webspherev61,groupAccess,nonFatal -Xscmx50m". The application server is configured to run as a separate profile, USERPROF for example, and has a shared class configuration of "-Xshareclasses:name=webspherev61,groupAccess,nonFatal -Xscmx50m". Notice that all three JVMs are configured to use the same shared class cache name. Typically in this configuration, the DMGR profile will be started first. Thus, it will create the shared class cache used by all three application servers. Because of this, the owner of the shared class cache will be the QEJBSVR user profile and the group profile will be *NONE. The permissions on the shared class cache give read and write permission to the owner and the group categories, and there are no permissions for the other category. Because the application server runs under a separate user profile that is a member of the QEJBSVR group profile, it falls under the other category for permission to the shared class cache. And since the other category does not have permission to the shared class cache, the custom user profile does not have permission. Thus, the shared class cache is opened as read-only and the MCH6801 is thrown because the JVM is unable to write to the cache.
Resolving The Problem
If the JVM receiving the MCH6801 is configured to share a class cache with other JVMs that run under a different user profile, the JVM running under the user profile that does not own the shared class cache must be configured to use a different shared class cache. It would be a security risk for IBM to set the shared class cache permissions for the other category to read and write.
To configure the JVM to use a different shared class cache, set the following generic JVM argument:
-Xshareclasses:name=newName,groupAccess,nonFatal -Xscmx50m
In the case of WebSphere Application Server, you have the following options.
If the issue is occurring in a WAS ND environment or you have not switched the application server profile to run under a different profile yet, you have the following two options to configure the generic JVM argument:
Option 1
(WebSphere Application Server v8.5 console instructions. These instructions might be slightly different, based on your version of WebSphere.)
| 1. | Log into the IBM WebSphere Administrative console. |
| 2. | Click on Servers -> Server Types -> WebSphere application servers. |
| 3. | Click on your application server name. |
| 4. | Under Server Infrastructure, expand Java and Process Management. |
| 5. | Click on Process Definition. |
| 6. | Under Additional Properties, click on Java Virtual Machine. |
| 7. | Edit the Generic JVM args field and append the following: -Xshareclasses:name=webspherev70_profileName,groupAccess,nonFatal -Xscmx50m |
| 8. | Click OK and save to the master configuration. |
| 9. | Restart the WebSphere Application Server for the change to take affect. |
Option 2
Start the Qshell environment. On the i5/OS CL command line, run the STRQSH command and then execute the following commands:
| 1. | cd <app_server_root>/bin where app_server_root is the install root of the WebSphere Application Server. |
| 2. | wsadmin -profileName <was-profile>, where was-profile is the WAS profile of the Application server. |
| 3. | set jvm [$AdminConfig getid /Server:<server-name>/JavaProcessDef:/JavaVirtualMachine:/] where server-name, is the WAS Application Server name. |
| 4. | set curargs [$AdminConfig showAttribute $jvm genericJvmArguments] |
| 5. | set newargs [concat $curargs "-Xshareclasses:name=webspherev70_<profile-name>,groupAccess,nonFatal -Xscmx50m"] where profile-name is the "run as user" i5/OS profile described above in this page. |
| 6. | set attrs [subst {{genericJvmArguments $newargs}}] |
| 7. | $AdminConfig modify $jvm $attrs |
| 8. | $AdminConfig save |
If the issue is occurring in a WAS Express or Base environment and you have already switched the application server over to run under a different user profile than QEJBSVR, here is how you can set the generic JVM argument to allow the JVM to start:
| 1. | Locate the server.xml file. |
| 2. | WRKLNK OBJ('/qibm/userdata/websphere/appserver/v7/nd/profiles/<profileName>/config/cells/<cellName>/nodes/<nodeName>/servers/<serverName>/*') |
| 3. | Enter option 2 next to the server.xml file. |
| 4. | Search for the "jvmEntries" xml tag. (Do not include the quotes). |
| 5. | On the "jvmEntries" tag line, locate the "genericJvmArguments" property. |
| 6. | Change the property to the following: WAS v7.0 genericJvmArguments="-Xshareclasses:name=webspherev70_profileName,groupAccess,nonFatal -Xscmx50m" WAS v6.1 genericJvmArguments="-Xshareclasses:name=webspherev61_profileName,groupAccess,nonFatal -Xscmx50m" |
| 7. | Press F3 two times to save and exit. |
| 8. | Start the application server. |
Historical Number
537964645
Was this topic helpful?
Document Information
Modified date:
18 December 2019
UID
nas8N1012715