Reason:
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. This health check provides a warning that CA OPS/MVS has reached the exception threshold value during the current life of the product or since the high water mark was last reset.
Action:
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 &VAR1, 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. 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.
If no applications can be modified in the short-term, increase the value of the PROCESS parameter. Based on the current value of parameter SSEXEXITHICOUNT and threshold value, a reasonable new value for PROCESS would be &VAR1.
To modify the value of the parameter, use the OPSPRM function with the SET keyword, e.g. OPSPRM('SET','PROCESS',' &VAR3 ') 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.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |