ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

OPSH169W The high watermark for process block

book

Article ID: 182950

calendar_today

Updated On:

Products

OPS/MVS Event Management & Automation

Issue/Introduction

During our health check reporting we received a message  about SSEXEXITHICOUNT count number which is now at 40. 

----

 CHECK(CA_OPSMVS,[email protected])

 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 CA OPS/MVS main

     address space when the CA 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 CA OPS/MVS

     requires its own process block. If a process block is not available,

     then CA 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 CA

     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 CA 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

     CA-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 CA 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 CA 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 CA

     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 CA 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.

 

   Problem Determination:  n/a

 

   Source:  CA OPS/MVS

 

   Reference Documentation:  CA OPS/MVS Parameter Reference Guide Chapter

     3 - Memory/Storage Parameters

 

   Automation:  n/a

 

   Check Reason:  Ensure there are enough process blocks for

     CA OPS/MVS events

 

 

 

Environment

Release : 13.5

Component : OPS/MVS

Resolution

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.