On 24-Sep-2015 11:52 -0600, Peter Dow wrote:
I have a program that uses HSSFR4 to open a template spreadsheet,
add data to it, and write it out as a different spreadsheet.
It works fine under my profile, and that of a colleague, but when
the user tries it, it fails with the MCH6801.
Said user's profile has no special authorities, and has limit
In the SQLRPGLE program it successfully does:
1277.00 rc = hssf_begin_object_group(200);
1285.00 book = HSSF_open('/home/Coop/CO0300 template.xls');
1296.00 sheet = HSSFWorkbook_getSheetAt(book: tx);
1298.00 row = HSSFSheet_getRow(sheet: 0);
And fails on
1299.00 hssf_text(row: 3: TITLE);
Message ID . . . . . . : MCH6801 Severity . . . . . . . : 40
Message type . . . . . : Escape
Date sent . . . . . . : 09/24/15 Time sent . . . . . . : 11:14:17
Message . . . . : Object domain or storage protection error for
offset X'0000000080000000' in object COOP_RPT_1USERID1 576813.
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 3.
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:
08-teraspace for OS/400 PASE memory address X'0000000080000000'.
X'40000000000000009F9DD58090000000' 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.
The full details of F6=Print or the full details from a spooled joblog taken with LOG(4 0 *SECLVL) shows additional context; context that was not collected\provided in what was chosen via the copy\paste snippet included above. The joblog including messaging since the request until the completion of the logging of the failure of that request [everything up until the next request] could provide an indication of possible additional actions that can be performed to effect even more logging [for the next occurrence] or an indication if such additional logging is already in effect.
Job: COOP_RPT_1 User: USERID1 Number: 576813 Thread: 00000186
Type Program Statement Procedure
1 QCMD QSYS /01C7
CO0300R ARLIB _QRNP_PEP_CO0300R
CO0300R ARLIB 26700 CO0300R
CO0300R ARLIB 129900 OPENSPREADSHEET
HSSFR4 UTLIB 24800 HSSF_TEXT
HSSFR4 UTLIB 23400 SS_TEXT
QRNXUTIL QSYS 132 _QRNX_JNI_ONE_CALL
QRNXUTIL QSYS 80 _QRNX_JNI_CHK_EXCP
QXJ9VM QJVM6032 14 FindClass__FP7JNIEnv_PCc
QRNXIE QSYS 1 _QRNX_CALL_FC_H
QRNXIE QSYS 2 _QRNX_DFT_ERROR
QRNXIE QSYS 17 _QRNX_INQ
QRNXIE QSYS 5 InqMsg
Googling found something for violation type 4 (write protection
error) having to do with the Java caches when swapping profiles
(which the calling CL program does), but this is a type 3 (read
Any clues as to what is causing this?
I expect the only difference between RC4 and RC3 [possibly alternatively known as ET4 and ET3 or VT4 and VT3] is the effective _method_ that was utilized for referencing the storage; i.e. effective write to the storage is manifest as RC4 and effective read[-only] of the storage is manifest as RC3.
I suppose if the [pointer to the] IBM i PASE memory storage address may have been obtained while swapped, and later referenced while running with a different [the original lower\limited-authority] user profile, then perhaps that can give rise to the "protection violation". I get the impression however, that the "protection violation" is reference to a /protected page/ which seems more akin to a "domain violation" than an "authority violation".
A seeming oddity, is the FindClass between the JNI Check Exception and the RPG Runtime Call Function Check Handler; a LIC process dump at the point of the violation probably would be more informative.
Nonetheless, I believe the TechNote document N1012715 [presumably already found in the alluded searching] may explain the issue, regardless the example shown being for the write [vs read] violation type. That document includes the full context from the spooled joblog [but missing from the above quoted OP], which can be rewritten as the symptom string msgMCH6801 RC4 F/tia_fault T/QP2USER2 TM/QP2API TP/runpase_common stmt/2. That doc is found here; a snippet is included:
Title: Message MCH6801 is Thrown when Attempting to Start an IBM Technology for Java Virtual Machine Instance
Reference #: N1012715 Historical Number 537964645
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. ...
Java Core and Snap dumps are then created.
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:
In the case of WebSphere Application Server, you have the following options.