Managing by policy
Chapter 5, “Applying a policy” on page 97 introduced IBM Customer Information Control System (CICS) Threshold Policy, and showed the steps involved in defining and deploying policies. This chapter provides information about more general aspects of CICS Policy, and describes how policy can be used to manage IBM CICS TS applications and platforms:
8.1 Benefits of CICS Policy
CICS Policy provides a way of controlling the behavior of CICS TS applications running in a CICS TS platform that is declarative, and that can be managed separately from the applications or platforms themselves. CICS Policy provides a step toward automating the behavior of a CICS TS environment. CICS Policy can be used to set an expectation for the resource usage of an application. CICS Policy can also be used to protect a CICS TS platform from unexpected resource consumption by the applications running on that platform.
Unexpected resource use might arise because the application has been written in such a way that it does not meet the guidelines for resource usage. Alternatively, the resource use might be because some error has occurred, causing a task to loop or behave in an undesirable way, or it could perhaps be a result of how a particular workload is driving the application.
The actions to be taken when a CICS Policy rule is contravened can be purely informational, or can lead to some kind of corrective action.
8.2 Reviewing CICS Threshold Policy
CICS Threshold Policy controls the behavior of applications by setting constraints on the resource usage by tasks running within an application on a platform. A CICS Policy contains one or more policy rules, where a policy rule defines a threshold condition, and the action to be taken if the threshold is exceeded. CICS TS supports several policy rule types, which determine the types of threshold conditions that can be defined. The tasks to which a policy rule applies depend on the scope into which that policy rule has been deployed.
The threshold limits apply to each of the tasks that fall within that scope, so that when any given task exceeds the resource usage specified by the policy rule, then the specified action is taken. In other words, the policy rules apply to individual tasks and not to an aggregated set of tasks.
This section provides some details about the policy rule types and threshold conditions that can be specified, and the policy actions that can be taken.
8.2.1 Policy rule types
The policy rule types that are supported by CICS TS are based on customer input about the types of resource usage that it would be most useful to be able control. Each of the rule types has a set of associated rule items, which enable the policy rule to be more granular. For example, the storage policy rule type has rule items ranging from 24-bit task storage to 64-bit shared storage. A rule item can be thought of as a qualifier to the overall rule type. Some of the rule types have a single rule item.
The policy rule types enable you to control the usage of the following areas:
•Storage. Storage can be managed based on the amount of storage used by a task (rule type of Storage), or the number of requests for storage made by a task (rule type of Storage Request). Within these rule types, there are rule items to enable you to specify the type of storage used or requested, whether it is task or shared storage, and whether it is 24-bit (below the line), 31-bit (above the line), or 64-bit (above the bar) storage.
This makes it possible to control, for example, the use of below-the-line storage by the tasks in an application. In some cases, the Storage rule type is most appropriate, because it manages the quantities of storage used by a task.
In other cases, it is a better fit to specify the number of requests to get storage that a task is allowed before the policy action should be taken. As an example, one of the uses of CICS Policy is to detect “rogue” tasks that are unexpectedly using too many resources, and a high number of storage requests might indicate that a task is looping.
•CPU or Elapsed time. The Time Rule type has Rule items for CPU limit and Elapsed time. The CPU limit rule item enables you to control tasks in an application or platform based on their usage of CPU. The Elapsed time rule item enables you to control tasks in an application or platform based on the amount of elapsed time for which they have been running.
CPU limit and Elapsed time are further examples of thresholds that might be used to detect rogue tasks. Elapsed time could also be used to help ensure that user response times do not become excessive.
•Data access requests. It is possible to control how many data access requests of various types are made by a task, either to a database using Structured Query Language (SQL) commands or to a file using CICS TS file control commands. A rule type of Database request enables you to specify the number of SQL commands made by a task.
The File request rule type provides control over the number of file accesses made by a task, and enables you to do so at the granularity of the types of request, whether these are read (Read), browse (Start browse, Read next, or Read previous), Read for update (Read update), Write, Rewrite, or Delete requests.
•Program links. The Program request rule type, with its rule item of Link, enables you to control how many programs a task links to. This rule type might be used to set an expectation about the complexity of applications.
•Start requests. The Start request rule type, with its rule item of START command, enables you to control how many other CICS TS transactions a task can asynchronously start. This rule type might be used to detect rogue tasks, such as a task that is looping.
•Sync point requests. The Sync point request rule type, with its rule item of SYNCPOINT command, enables you to control how many sync points, or sync point rollbacks, a task can take. This rule type might be used to detect rogue tasks.
•Transient data requests. The TD Queue request rule type has two rule items for READQ TD commands and WRITEQ TD commands. These rule items enable you to control how many requests are made to read or write transient data. This rule type might be used to detect rogue tasks, such as a task that is looping.
•Temporary storage requests. Temporary storage can be managed based on the amount of temporary storage used by a task (rule type of TS Queue bytes) or the number of requests for temporary storage made by a task (rule type of TS Queue request). Within the TS Queue bytes rule type, there are rule items to enable you to scope the policy to the particular type of temporary storage that it is, main or auxiliary.
Within the TS Queue request rule type, there are rule items to enable you to control how many read or write requests are made to temporary storage, and how many write requests are made to auxiliary or main storage. These rule types might be used to detect rogue tasks that are unexpectedly using too many resources, or to indicate that a task is looping.
The condition portion of a policy rule consists of a rule type (and optional rule item), an operator, a value, and the units of that value. For the CICS TS V5.2 threshold policies, the operator is always greater than, and the possible units that can be specified depend on the rule type. A policy rule also has a name, a description, and an action to be taken when the condition is met. Examples of policy rules are given in Chapter 5, “Applying a policy” on page 97.
8.2.2 Policy actions
The set of actions that can be specified when a policy threshold is exceeded provide an increasing amount of intervention into the behavior of the task. Therefore, this intervention implies an increasing degree of trust that is placed in the policy management’s ability to control the platform and applications for you.
The least intrusive action is to send a message that provides details about the task that has exceeded the policy threshold, and the threshold value that was exceeded. This is purely informational. The next action in terms of the amount of intervention is to emit an event, which could be used to drive additional processing within CICS TS or externally to CICS TS, sent to an event monitor, or combined with other events using an event engine such as IBM WebSphere Operational Decision Manager.
The most intrusive action is to cause an abend of the task that exceeded the policy threshold. The message action informs an operator that the policy threshold has been exceeded, and enables the operator to choose what further action, if any, should be taken. The event action introduces the possibility of automating any further action that should be taken.
Finally, the abend action automates the removal of the offending task from the system. Only one action can be specified for each policy rule, but a combination of policy rules could be used to take increasingly stringent action as a sequence of increasing threshold values
is exceeded.
is exceeded.
Each of the actions has predefined information associated with it. For the Issue message action, message DFHMP3001 is issued. For the Emit event action, a predefined event is formatted and emitted using the specified Event Processing (EP) adapter or EP adapter set. For the Abend task action, the task is ended with abend code AMPB and message DFHMP3002 is issued. The following subsections provide more details about each action, and the predefined information associated with it.
Send message policy action
Message DFHMP3001 contains information about the following items:
•The task number (trannum) and transaction ID of the task that exceeded the policy threshold.
•The name of the CICS bundle containing the policy definition that was used to deploy
the policy.
the policy.
•The name of the policy definition.
•The name of the policy rule that was exceeded.
•Details of the policy rule that was exceeded, including the RuleType, the Category (rule item), and the Threshold with its value and units. The Threshold is the actual limit derived from the value and the units. For example, for a policy rule that specifies that the amount of 24-bit task storage used by a task should not exceed 20 kilobytes (KB), the RuleType in the message would be Storage, the Category would be task24, the Value would be 20, the Units would be K, and the Threshold would be 20480.
•The CurrentCount, which is the amount of the resource used by the task at the time that CICS TS detected the threshold had been exceeded. The CurrentCount will often be a larger number than the Threshold, because of how CICS TS validates the task against the applicable policy rules.
The following list provides examples of CurrentCount:
– For a storage policy rule, the storage usage is determined when storage is allocated, so if a task acquires an additional 10 KB of storage when it already had 15 KB, then the CurrentCount will show 25600 although the Threshold might be 20480.
– For a CPU time policy rule, the CPU time is determined each time the task is dispatched, so it might have exceeded the CPU threshold by some amount.
Figure 5-10 on page 108 shows an example of message DFHMP3001.
Emit event policy action
When the Emit event action is specified in a policy rule definition, the EP adapter or EP adapter set to be used to emit the event must also be specified. The EP adapter or EP adapter set does not need to have been defined or installed when the policy rule is created. However, if it has not been installed and enabled by the time the policy first fires (or if there is a problem with the EP adapters), the event emission fails, and one of message DFHMP3003, DFHMP3004, or DFHMP3005 is issued with an explanation of the failure.
The EP adapter defines the event format and transport that are used to emit the event to an event consumer. If an EP adapter set is specified, multiple events can be emitted to multiple event consumers as a result of exceeding a policy threshold.
The contents of the event (or events) that are emitted for CICS TS policies are predefined, with standard event context information, including an event binding name of CICS Policy Event, a business event name of CICS_Policy_Event, and a capture specification name of CICS_Policy_Event_Capture_Spec. The event data contains similar information about the task and the policy rule as that provided in message DFHMP3001, but also contains details about the platform, application, and application version, and operation.
Abend task policy action
When the abend action is specified, the event is ended with abend code AMPB, preceded by issuing message DFHMP3002. Message DFHMP3002 contains the abend code plus the same detailed information as message DFHMP3001. Figure 5-10 on page 108 shows an example of message DFHMP3002 and the messages associated with abnormally ending
a task.
a task.
If more than one policy rule applies for a particular task and threshold value, the actions associated with the rules are processed so that any messages are issued first, then any events are emitted, and finally the task abend occurs if any rules specify an abend action.
8.3 Policy scope
The scope to which a policy applies is determined by how the policy is deployed. Figure 8-1 shows a simplified platform, which has a single region type, and onto which two applications have been deployed, each with two operations. This figure is used as a basis for illustrating the different scopes at which a policy can be deployed, and the user tasks to which the policy then applies.
Figure 8-1 Simple platform schematic to illustrate policy scoping
Policy definitions are created in CICS bundles, and the CICS bundle is the unit of deployment for policies. The term CICS Policy Bundle is used to refer to a CICS bundle containing one or more policy definitions (which themselves contain one or more policy rules). Policies can be deployed in a cloud enabled CICS TS environment to the following scopes:
•To a platform scope by including the CICS bundle containing the policy as part of the CICS TS platform project, so that the policy is deployed when the platform is deployed.
•To a platform scope by adding the CICS bundle containing the policy to an already active platform. The Add bundle operation from the Cloud Explorer enables a CICS Policy Bundle to be added to one or more region types within the CICS TS platform.
•To an application scope by including the CICS bundle containing the policy as part of the CICS TS application project, so that the policy is deployed when the application is deployed.
•To an application scope by including the CICS bundle containing the policy in the application binding, so that the policy is bound to the application when it is deployed to a specific platform.
•To an operation scope by specifying a policy scope within the bundle manifest of the CICS Policy Bundle. This relates the policy to a specific application operation, which has been defined by specifying an application entry point for this application. A policy scope names the policy resource and the operation.
Figure 8-2 illustrates platform scope for a policy. In this example, the policy has been deployed into region type R1 in the platform, either by deploying the policy as part of the platform, or by adding the policy bundle to the region type in the platform. The policy applies to user tasks that run as part of any application that is deployed to the platform region type, and to any operation in those applications.
Figure 8-2 Simple example of platform policy scope
Figure 8-3 illustrates application scope for a policy. In this example, the policy has been deployed into Application A1 by including the policy bundle in Application A1 when it was deployed. The policy applies to user tasks running as part of Application A1, and to both operations of Application A1, but it does not apply to user tasks running as part of
Application A2.
Application A2.
Figure 8-3 Simple example of application policy scope
The policy can also be deployed to the application scope by including it in an application binding used to deploy Application A1 to the Platform Region Type R1. The next section describes when it might be appropriate to include the policy in the application itself, and when it makes more sense to include it as part of the deployment of the application.
Finally, Figure 8-4 illustrates operation scope for a policy. In this case, a policy scope has been included in the CICS bundle manifest that associates the policy specifically with one of the operations of Application A2. The policy therefore applies to user tasks running for this particular operation of Application A2, but not to the other operation of Application A2, or to any user tasks running under Application A1.
Figure 8-4 Simple example of operation policy scope
When any given task is running in the platform, it might be possible that it is subject to several policy rules:
•Rules that apply to this task because it is running in a platform region type to which a policy has been deployed
•Rules that apply to this task because it is running as part of an application to which those rules apply
•Rules that apply specifically to the operation that the task runs under
Where multiple rules apply, those which specify a lower threshold are checked first.
When a task is first attached, the policy rules that apply to it in its environment are established. Those rules are applied to that task, even if at some point the flow of control passes to a different application scope.
8.3.1 Policy for applications
Policy can be deployed at an operation or application scope to control how an application behaves, or to set the expectation for its resource usage.
The application developer can make a statement about the expected limits within which the application should operate, by adding policies into the application. This means that the policies are an integral part of the application, and apply regardless of the environment into which it is deployed. Some policies might relate to any task running within the application, but others would be specific to particular operations.
An inquiry operation might have a policy limiting its use of below-the-line storage, where an update operation might be known to require a certain amount of storage below-the-line. It is quite simple to add entry points to an application, and then use those to specify policies at an operation scope.
There might also be some policies that vary depending on the environment into which the application is deployed. These policies should not be added as part of the application, but should be included in the application binding, to enable them to be varied, perhaps to introduce more stringent policies for QA testing.
8.3.2 Policy for platforms
Policy can be deployed to a platform scope to determine the behavior expected or required of applications deployed to the platform, or to “protect” the platform from applications that might experience difficulties.
For example, the platform might deploy a set of policy rules that place upper limits on the amount of storage, the number of program calls, and the amount of CPU used by applications deployed to the platform, to protect the platform from any tasks that might be looping.
Alternatively, in a platform that has distinct regions for accessing data, a policy might be deployed to the AOR region type that limits the number of data access requests that user tasks can make. This ensures that applications deployed to this platform have been suitably structured to isolate the pieces that access data.
8.4 Setting policy
There are various considerations to be taken into account when deciding whether to apply policy rules, what policy rules to apply, and what the threshold values should be.
For platform scope rules, one consideration is whether this is a development, test, or production platform, and another consideration is the nature of the applications that are to run on this platform. For a development platform, there might not be any policies deployed, so that there are no limitations on how the applications behave while they are being developed, or alternatively there might be some quite restrictive policies in place so that any problems can be quickly discovered.
In a production platform, policies are used to ensure that all applications can run successfully on the platform, with some policies ensuring that certain resources are not over-committed, and others perhaps limiting particular resources to quite strict thresholds.
For application and operation scopes, policies can be used to enable the application to have sufficient resources for its needs without exceeding the use that would be expected. For example, if an application needs to make a significant number of database accesses, a Database request policy might be included with the application that has a high threshold value.
If that application is deployed to a region type within a platform that is more restrictive in the database access that it allows, it will soon be discovered that the region type is not suitable for this application. If an application is not intended to make any updates to files, a policy with appropriate File request policy rules could be deployed to ensure that it does not do so.
This last example, of a policy to limit file updates, is a good example where multiple policy rules might be included in a single policy definition. There could be a policy rule for each of the file rule items that relate to file update requests.
Guidance from tools like CICS Performance Analyzer, from knowledge of the application, and so on, should be used to set appropriate policy values. CICS Performance Analyzer V5.1 and later provide information about the platform, application, and operation to which data relates. This information can be used to establish the normal use of resources by the application, and then inform the setting to be used in policy rules.
Another general consideration when defining and deploying policies is governance of the policy definitions. Policies should be regarded as similar to source code or system configuration settings, and controlled and managed using similar techniques, such as source code management. The packaging of policies with applications or platforms helps to provide the structure for doing this, but the choice of governance technique depends on the installation.
8.5 Policy scenarios
This section describes a few examples of policy rules, and how they could be used to manage the behavior of our example GeneralInsuranceCustomer application.
Use of the term policy in this book to refer to both the CICS TS threshold mechanism and the insurance policies managed by the GENAPP might be a little confusing. However, the CICS Policy mechanism is actually somewhat like an insurance policy, which spreads the risk across the CICS TS platform and is activated when problems occur.
The operation to Inquire on an Insurance Policy needs to be responsive (it might, for example, be issued by an insurance agent when a customer needs to make a claim). A policy can be deployed that checks the CPU time of tasks performing the Inquire operation, and emit an event to a monitoring dashboard, enabling the IT department to keep an eye on this time use.
Deleting an Insurance Policy is not critical to the overall performance of the application, so perhaps a policy could be used to limit its virtual storage usage, ensuring that it does not use a disproportionate amount at times when the CICS TS platform is busy.
The development platform might be used to catch some poor performance practices in the GeneralInsuranceCustomer Application before new versions of the application are made available to test. For example, policies installed in the development platform could check for excessive use of 24-bit storage, or for use of shared storage, which might make it difficult to deploy parts of the application across different cloned regions in a region type.
8.6 Concluding thoughts
This chapter has described how threshold policy rules can be used to control and automate the behavior of applications in a cloud-enabled CICS TS environment. The scope to which policies can be applied ranges from the tasks running on region types within a CICS TS platform, to tasks running as a result of individual operations within an application.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.