During our health check reporting we received a message about SSEXEXITHICOUNT count number which is now at 40.
----
CHECK(CA_OPSMVS,OPSMVS_PARM_PROCBLK@OPSMAIN)
SYSPLEX: XXPLEX SYSTEM: Snnn
START TIME: 02/25/2020 08:34:51.609715
CHECK DATE: 20180117 CHECK SEVERITY: MEDIUM-DYNAMIC
CHECK PARM: THRESHOLD(80%) AGE(6)
The current value of parameter PROCESS is 40
The current value of parameter SSEXEXITHICOUNT is 40
The current value of parameter SSEXEXITFAILURES is 241
* Medium Severity Exception *
OPSH169W The high watermark for process block usage SSEXEXITHICOUNT has
reached the number of allocated process blocks PROCESS, moreover failed
attempt to allocate a process block has occurred.
Explanation: The PROCESS parameter determines how many process blocks
are allocated in the extended private area of the OPS/MVS main
address space when the OPS/MVS address space initializes.
Allocating the right number of process blocks is critical. The
number cannot be too low, because each event processed by OPS/MVS
requires its own process block. If a process block is not available,
then OPS/MVS will not capture or respond to the event, which in
turn could lead to undesirable results on your system. Furthermore,
setting the value too high has its own implications; the number of
process blocks you specify may use so much virtual storage that
OPS/MVS fails to function correctly. The value of the
SSEXEXITHICOUNT parameter indicates the high water mark for the
number of these process blocks. The SSEXEXITFAILURES parameter
displays the number of failed attempts to allocate a process block
from the process block pool because there were no process blocks
available.
This health check provides a warning that OPS/MVS does not have
process blocks available for any event or request.
System Action: The system continues processing, however AOF event
processing will not occur for events where a process block cannot be
obtained.
Operator Response: Report this problem to the system programmer.
System Programmer Response: It is critical that a process block is
available for any event or request that passes through the
OPS/MVS AOF event processing, even if a rule does not process the
event. A frequent cause of process block depletion, particularly as
the value of the SSEXEXITHICOUNT parameter gets closer to 40, is
inefficiently coded automation. To identify such automation, from
within OPSVIEW option 4.1.1, view the SSEXEXITHIDATE and
SSEXEXITHITIME parameters to determine the date and time of the high
process block usage when the SSEXEXITHICOUNT value was reached. This
high water mark count was reached on 2020/02/02 at 05:55:04. Use
SSEXEXITFAILDATE and SSEXEXITFAILTIME parameter to displays the date
and time when the last process block allocation failure occurred.
Last block allocation failure occurred on 2020/02/25 at 00:00:00.
Using the OPSLOG, locate the date and time as indicated via these
parameters. From the OPSLOG command line issue
'DISPLAY TRACE1 RULE COUNT DATE TIME'
, attempt to identify the OPS/MVS application or applications
(rules and OPS/REXX programs) that were executing during this high
usage period. Common application bad practices are creating logic
within rules to 'trigger' other rules, such as having a MSG rule
issue a command to trigger a CMD rule. Additionally, the triggering
of REQ rules from within rules (via ADDRESS OSF "OPSREQ...") instead
of triggering an OPS/REXX program can cause process block depletion.
Contact Support if technical assistance is needed in reviewing
the OPSLOG to identify process block usage issues.
SSEXEXITFAILURES parameter, which displays the number of failed
attempts to allocate a process block, is 241. Increase the value of
the PROCESS parameter. Based on the current value of parameters
SSEXEXITHICOUNT and threshold value, a reasonable new value for
PROCESS would be 60.
To modify the value of the parameter, use the OPSPRM function with
the SET keyword, e.g. OPSPRM('SET','PROCESS','60') and restart
OPS/MVS. The PROCESS parameter can only be set at product
initialization. Possible number of process blocks can be between 10
and 250. Always discuss the PROCESS parameter with Customer
Support before setting it to a value higher than 100.
To reset high water mark for the number of used process blocks
SSEXEXITHICOUNT to zero, use OPSVIEW option 'Set/Display product
parameters' or OPSPRM function with the SET keyword
OPSPRM('SET','SSEXEXITHICOUNT',0). You could rerun health check in
SYSVIEW with RUN command or reset it with REF command to update
heath check status.
OPS/MVS
Over increasing Process Blocks could result in unforeseen storage conditions, so the recommendation is to first review the type and amount of automation events going on at the high water usage mark.
The PROCESSHIGHDATE and PROCESSHIGHTIME will point to the area of the OPSLOG to review when the high water mark for process blocks occurred. The most common event type leading to these messages is when a large number of initiators are started or stopped at the same time. Therefore, we recommend a controlled, staggered approach to stopping or starting initiators. Either issue the commands for a range of initiators, or consider a rule and/or REXX similar to the below:
ADDRESS OPER "C($PI1-10) NOO"
a = OPSWAIT(2)
ADDRESS OPER "C($PI11-20) NOO"
a = OPSWAIT(2)
ADDRESS OPER "C($PI21-30) NOO"
a = OPSWAIT(2)
Note: for 13.5 release, ensure all Hyper Fixes are applied, if not on 13.0.0000 complete release.