Policy system rules

System rules define the action to be taken when something of interest happens in a CICS® system, such as a resource state change, a threshold being crossed, or an unusual system state or action. Policies that define system rules can be deployed either to a stand-alone CICS region or with a CICS platform. They cannot be deployed with a CICS application.

Types of system rules

The supported system rule types are as follows:

AID threshold
Use this rule type to define the action to be taken when an EXEC CICS START request that meets all of the following conditions is issued:
  • The TERMID option is specified with a value that is the same as the terminal where the transaction is running.
  • The FROM option is specified.
  • The INTERVAL and TIME options are not specified.
  • The request would cause the current number of AIDs in the CICS system to exceed a threshold.
Bundle available status
Use this rule type to define the action to be taken when the available status of a bundle that declares application entry points changes from or to a specific state. To restrict the action to specific bundles, specify the bundle filter in the rule definition. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.

If a bundle is deployed with a CICS application, the messages and events that are produced when a bundle available status rule is triggered contain the application context information.

Note:

Bundle available status rules are not applicable to any bundles that do not declare application entry points.

Bundle enable status
Use this rule type to define the action to be taken when the enable status of a bundle changes from or to a specific state, or when the enable status of a bundle changes from a specific state to another specific state. To restrict the action to specific bundles, specify the bundle filter in the rule definition. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.

If a bundle is deployed with a CICS application, the messages and events that are produced when a bundle enable status rule is triggered contain the application context information.

Db2® connection status
Use this rule type to define the action to be taken when the status of a Db2 connection changes from or to a specific state. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.
DBCTL connection status
Use this rule type to define the action to be taken when the status of the connection between CICS and DBCTL changes from or to a specific state. If you want the specified action to be taken only when the status change is made by a specific user ID, specify the user ID filter in the rule definition.
Note: DBCTL connection status rules will not trigger for changes in the status of a DBCTL connection during CICS initialization when the DBCTLCON=YES system initialization parameter is specified.
File open status
Use this rule type to define the action to be taken when the open status of a CICS FILE resource changes from or to a specific state. To restrict the action to specific file resources, specify the file filter in the rule definition. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.
File enable status
Use this rule type to define the action to be taken when the enable status of a CICS FILE resource changes from or to a specific state. To restrict the action to specific file resources, specify the file filter in the rule definition. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.
IBM® MQ connection status
Use this rule type to define the action to be taken when the status of a connection between CICS and IBM MQ changes from or to a specific state. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.
Note: IBM MQ connection status rules will not trigger for changes in the status of a CICS-MQ connection during CICS initialization when the MQCONN=YES system initialization parameter is specified.
IPIC connection status
Use this rule type to define the action to be taken when the status of a IPIC connection (IPCONN) changes from or to a specific state. To restrict the action to specific IPIC connections, specify the connection name filter in the rule definition. If you want the specified action to be taken only when the status change is made by a specific user ID, specify the user ID filter in the rule definition.
Message
Use this rule type to define the action to be taken when CICS issues a DFHxxnnnn message or when CICSPlex® SM issues an EYUxxnnnn message. To restrict the action to a specific CICS or CICSPlex SM message, specify the message ID filter. To restrict the action to specific instances of a message, specify one or more message insert filters. If you want the specified action to be taken only when the message is issued by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter.
Not all CICS or CICSPlex SM messages result in evaluation of a message system rule. No message system rules are evaluated for messages that are issued by the EC, EP, or MP components of CICS, that is, all DFHECnnnn, DFHEPnnnn and DFHMPnnnn messages. In addition, events are not emitted for message system rules that specify the event action for these messages:
  • CICS initialization messages that are issued before event processing starts. Event processing is started before phase 2 initialization PLT programs are run.
  • CICS termination messages that are issued after event processing stops. Event processing is stopped after all shutdown PLT programs have run.

You can determine whether a message system rule will be evaluated for a specific message, based on its description in CICS messages. If a message description contains a list titled XMEOUT parameters/Message inserts, you can define a message system rule for it; otherwise, the message is not enabled for message system rules. For example, you can define a message system rule for message DFHFC0208 but not for message DFHDU0205.

A message system rule will be evaluated regardless of whether or not a message is suppressed by either an XMEOUT global user exit program or the system initialization parameter MSGLVL=0.

MRO connection status
Use this rule type to define the action to be taken when the status of a MRO connection changes from or to a specific state. To restrict the action to specific MRO connections, specify the connection name filter in the rule definition. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.
Pipeline enable status
Use this rule type to define the action to be taken when the enable status of a CICS pipeline changes from or to a specific state. To restrict the action to specific pipeline, specify the pipeline name filter in the rule definition. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.
Program enable status
Use this rule type to define the action to be taken when the enable status of a CICS program changes from or to a specific state. To restrict the action to specific programs, specify the program name filter in the rule definition. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.

If a program is deployed with a CICS application, the messages and events that are produced when a program enable status rule is triggered contain the application context information.

Transaction class tasks
Use this rule type to define the action to be taken when the number of active tasks in a CICS transaction class goes above or below a specific threshold, which is represented by a percentage of the maximum number of active tasks in a transaction class (the MAXACTIVE value). The threshold is chosen from a predefined list of 50%, 60%, 70%, 80%, 90%, or 100%. To restrict the specified action to specific CICS TRANCLASS resources, specify the transaction class filter in the rule definition. For more information, see User tasks and transaction class tasks system rules.
Transaction abend
Use this rule type to define the action to be taken when a transaction encounters an unhandled abend.

To restrict the specified action to a specific abend code, specify the abend code filter in the rule definition. If you want the specified action to be taken only when the status change is made by a specific transaction or a task running under a specific user ID, specify the transaction ID or user ID filter in the rule definition.

A transaction abend system rule with the event action will not be evaluated for any transaction abend originating in any task that runs an event processing adapter program.

Transaction dump threshold
Use this rule type to set a maximum threshold for the total number of transaction dumps in a CICS region and define the action to be taken when the specified threshold is exceeded.
User tasks
Use this rule type to define the action to be taken when the number of active tasks in a CICS system goes above or below a specific threshold, which is represented by a percentage of the maximum user tasks in the CICS system (the MXT value). The threshold is chosen from a predefined list of 50%, 60%, 70%, 80%, 90%, or 100%. For more information, see User tasks and transaction class tasks system rules.

Using policy system rules to replace system events

System rules provide functional equivalence and map one to one to system events but with much simpler configuration, and they support four possible actions:
  • Issue a CICS message.
  • Emit a CICS event. For the event action, you can define items of static data to be emitted with the policy event and specify user-defined name for the event.
  • Reject EXEC CICS request.
  • Set z/OS WLM health open status.

A CICS message may be sufficient for your needs and system rules with this action are simple to adopt, avoiding the complexity that comes with supporting an event consumer. The CICS message could also be used with your existing automation products to trigger further automated actions.

However, if you wish to perform further analysis on the ‘event’ using tools such as IBM Decision Manager or IBM Operational Decision Manager, or if you wish to start a CICS task to perform some automated action, then the event action will be required. When an event occurs, that is, when a rule triggers, a CICS transaction is started to perform a customized action. When such a transaction starts, it’s going to need some information about the rule that was triggered. This information is contained in the data that was captured when the rule triggered and is available in a series of CICS containers. Policy rules greatly simplify this configuration because all the data that relates to a given rule type is captured by CICS and it’s left to the event consumer to choose what it needs and to ignore the rest. This means that you don’t have to choose which data to capture. In comparison, if you defined events, you had to choose which data to capture from a list of available data items for each event type; for example, for a FILE OPEN event, you chose from a list that includes the file name, the dataset name, the to- and from- open state, the file enable state, the transaction ID of the task that changed the state and the user ID under which that task was running. Although this can mean that more data is captured and emitted than is actually required by the consumer of the event, most policy events are only a few hundred bytes. The simpler configuration of a policy event, compared with a system event, more than makes up for the few extra bytes being emitted. For details on the data emitted for each policy rule type, see Data captured for a policy event.

While system events can still be defined and installed in CICS TS, support for system events is now deprecated and may be removed in a future release of CICS TS. Support for application events is unaffected and remains strategic.