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
capabilities *YES.
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
protection error).
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:
[
http://www.ibm.com/support/docview.wss?uid=nas8N1012715]
Title: Message MCH6801 is Thrown when Attempting to Start an IBM
Technology for Java Virtual Machine Instance
Reference #: N1012715 Historical Number 537964645
"...
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. ...
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.
..."
midrange.com
