The supported policy rule types are database request, file request, program request, storage, storage request, and time.
Use the database request policy rule type to define a threshold for the number of DB2® SQL requests performed by a user task, and take automatic action if the threshold is exceeded. The count includes SQL requests issued by exits. For example, a program that issues EXEC CICS FILE requests that are converted into SQL requests by CICS® VT counts both towards any file request threshold and any SQL count threshold.
Use the file request policy rule type to define a threshold for the number of EXEC CICS file access requests performed by a user task, and take automatic action if the threshold is exceeded. The threshold applies to a specific file command, for example READ. It is not a cumulative count of all file access requests. File requests are counted when an application makes a file control request, whether the request is successful or not. Requests are counted under the task for the application-owning region (AOR), whether the file is local or remote. Requests are not counted in the file-owning region (FOR).
Use the program request policy rule type to define a threshold for the number of EXEC LINK requests performed by a user task, and take automatic action if the threshold is exceeded. This rule type applies to LINK requests that are serviced locally or remotely, whether successful or not. Any task that is started in a remote region that services a DPL request is then outside of the scope of the rules that are applied to the task that issued the DPL, so any further LINK requests that the remote task might perform are not counted by the local task.
Use the storage policy rule type to define a threshold for the amount of storage that is allocated by a user task, and take automatic action if the threshold is exceeded. The threshold applies to a specific storage class, for example 31-bit task storage. It is not a cumulative count of all storage requests.
The threshold count includes all GETMAIN requests performed by a user task: both explicit EXEC CICS GETMAIN requests and implicit GETMAIN requests that occur in response to other EXEC CICS commands, for example EXEC CICS READ FILE SET. For task-related storage requests (task24, task31, and task64) the count is decremented when the task issues an explicit or implicit FREEMAIN. However, the counts for shared storage (shared24, shared31, and shread64) are NOT decremented when a task releases shared storage.
Use the storage request policy rule type to define a threshold for the number of GETMAIN requests performed by a user task, and take automatic action if the threshold is exceeded. This differs from the storage policy rule type, which is used to define thresholds that are based on the amount of storage allocated. The storage request threshold count contains the number of all GETMAIN requests performed by a user task: both explicit EXEC CICS GETMAIN requests and implicit GETMAIN requests that occur in response to other EXEC CICS commands, for example EXEC CICS READ FILE SET.
Use the time policy rule type to define a threshold for the amount of processor time that is used by a user task, and take automatic action if the threshold is exceeded. The time policy rule type differs from the other policy rule types in that the threshold is based on processor time, rather than a count of API requests, or the amount of storage allocated. Due to the way processor changes are recorded, it is not possible to count the processor time continually, so on occasions the threshold might be exceeded sometime before it is detected by this function, and if you were to compare monitoring data with policy threshold actions taken, you might see some discrepancy.
The time policy rule type compares the total processor time with the policy threshold value. However, the processor time value is not incremented until a task gives up control of a processor, so a task might greatly exceed a threshold before it gives up control of the processor and allows the check to occur. Even then, it is not until the task is redispatched and next issues an EXEC CICS call or calls a TRUE (for example an EXEC SQL call) that it checks whether the CPU time threshold is exceeded. If the threshold is exceeded and the rule action is abend, the abend happens after the command completes. If, for some reason, the task never gives up control, normal RUNAWAY processing, independent of any time policy processing, abends the task in the normal way if the task fails to give up control before the RUNAWAY time interval is exceeded.