Users may see the following message during Sysview initialization or anytime a JVM process is attempting to be killed:
07.29.30 S0805991 GSVX998E (JVMDATA) USS$035E BPX1KIL (kill) failed, reason JRNotPermitted (276 x'114')
Release : 17.0; 16.0
Component : SYSVIEW
The specific reason text (JRNotPermited 276) and hexadecimal reason code ('114') identifies a scenario where SYSVIEW has insufficient authority to issue a USS Process Kill command against a specific or group of process ids (PIDs).
The error message identifies both the reason code text and hexadecimal reason code; understanding how to identify both are required resolve this issue:
Identified in the USS$035E error message, information on the Reason Code Text can be found in SYS1.MACLIB member "BPXYERNO".
JRNOTPERMITTED EQU 276 * You are not permitted to signal
* to the specified process ID
You'll notice that the "276" value from the error matches the member information, confirming the correct reason code text is being viewed.
Confirming the reason code text above, users may review z/OS UNIX System Services Messages and Codes manual (linked below) to identify the JRNOTPERMITTED 'x114' message; the action for this error is:
"To "Reissue the request specifying a PID that you are authorized to send a signal to, or reissue the request from a superuser ID."
Behind the scenes, Sysview attempts to issue the USS UKILL command against the PID but lacks sufficient authority. The action message notes to allow the issuer SuperUser Authority to issue OMVS commands; while this action would allow this command to be successfully issued, site security restrictions make this an unrealistic option to implement with many customers.
Reported occurrences identify this flavor of the USS$035E error to only occur on a subset number of systems. If this is true, users can test SYSVIEW authority with a manual attempt to kill a JVM process via the UPROCESS command. If the test PID is killed successfully, the issue may reside with security relating to the JVM job. However, a failed test indicates a difference in security definitions and a review between a working and non-working system is recommended.
NOTE: When JVMDATA starts, it first makes an attempt to find the Java version of each JVM that's running by opening a USS process that issues the command "java --version". If that command takes a long time to respond, it can lead to a "zombie" process that needs to be killed. Thus, we issue a KILL against the process. Only one java --version command is issued, although an MVS MODIFY command can be issued against the SYSVIEW main address space to retry the java --version command for all unique Java home directories found. This command is documented here and would look be similar to:
MODIFY sysview,MODIFY JVMDATA,VERIFY ALL.
Not having the Java version known would not cause any problems in SYSVIEW or in the JVM. The only impact is the Java version will not be listed on the SYSVIEW JVMLIST or JVMVERS commands.