Reason:
The maximum number of commands that have been on the OSF TSO queue as a percentage of the maximum number of commands that the queue can hold, is higher than recommended. That is, the maximum utilization reached by the OSF TSO queue is too high. This queue is where CA OPS/MVS sends TSO commands to be executed in the OSF TSO servers. The OSF execution scheduler dispatches these commands to OSF TSO servers as the servers become available to process work. If the queue utilization reaches 100% and occurrences of message OPS4349S with RC=4 have been issued since CA OPS/MVS started, then CA OPS/MVS has had failures in attempting to send a command to an OSF TSO server because the queue was full. Requested automation commands have failed to be executed.
Action:
You have multiple options to decrease queue utilization:
The first option would be to decrease the value of parameter OSFQADD which is currently &VAR1. This parameter sets the threshold that CA OPS/MVS uses to determine whether more OSF TSO servers need to be started. When the number of commands in the OSF TSO execution queue exceeds the value of the OSFQADD parameter, CA OPS/MVS starts another OSF TSO server unless the number of servers has already reached the value of the OSFMAX parameter. If your preference is for CA OPS/MVS to make use of the maximum number of defined OSF TSO servers to process the command load, then this may be the best option for you. With more servers executing commands, the queue utilization can be expected to decrease. A reasonable new value for OSFQADD would be to decrease it to &VAR2. It can be changed while CA OPS/MVS is active.
The second option for decreasing OSF TSO queue utilization is to increase the maximum number of commands that can be held in the queue. If your preference is to maintain, rather than increase, the number of CA OPS/MVS address spaces, then this may be the best option for you. A reasonable new value for OSFQUE would be to increase the current value &VAR3 to &VAR4. This option requires a restart of CA OPS/MVS.
A third option is to increase the value of the OSFMAX parameter which is currently &VAR5. If you are currently not using the maximum number 30 of defined OSF TSO servers to process the command load and prefer to not have longer command queues, then this option may be for you. That is, rather than further decreasing the value of parameter OSFQADD or increasing the value of parameter OSFQUE, a reasonable new value for the OSFMAX parameter would be to raise it by one. With more servers executing the commands from the queue, the queue utilization is expected to decrease. OSFMAX can be changed while the CA OPS/MVS is active.
You can start by lowering OSFQADD and then alternate between adding one to OSFMAX and reducing OSFQADD again. OSFQADD should never be lower than 2 and OSFMAX cannot be greater than 30. If queue is still full, a larger queue size OSFQUE is the last resort.
To modify the value of the parameters, use the OPSPRM function with the SET keyword, that is, OPSPRM('SET','OSFQADD','&VAR6'), or OPSVIEW option 4.1.1. Rerun this health check after a few minutes to see if the OSF TSO queue utilization is decreasing. The OSFQUE parameter can only be set at product initialization.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |