‘Killing’ CICS tasks with CICS Performance Monitor

A question often asked is, “What capabilities exist to ‘kill’ a task from a given CICS system via CICS Performance Manager?”. (Here we are using the term ‘kill’ to refer to the action provided by many performance management monitors.) CICS Performance Monitor bases its facilities on those of CICSPlex System Manager. CICSPlex SM itself is an EXEC CICS application, and therefore provides the ability to PURGE and FORCEPURGE tasks. Those facilities are exploited by CICS PM. Killing a task in a CICS region can have catastrophic consequences; for instance, no data integrity is guaranteed. As an example, consider the consequences of purging a task in a DB2WAIT condition. Having killed the task, the DB2 subsystem could subsequently post an ECB in the CICS system where the storage is no longer the requestor’s ECB. This could have disastrous results. Nevertheless, the customer may deem this risk acceptable. Whilst this is a concern to CICS system programmers or operators, this function is used in the scenario where a region would have to be brought down anyway to resolve the problem, and killing the task will allow the region to continue processing critical work for some time. An example would be resolving a problem in a trading organization just before the market closes. The problem is actually subtler than this, and can be broken down into the following items:

• Which system is the problem in?
• Which task do I want to kill?
• How do I kill it?

So, we need to know which task to kill before we can kill it. In order to understand this topic, some appreciation is required of the underlying architecture of CICSPlex SM (upon which CICS PM is built), along with a classification of types of work running within the CICS system, and the CICS system’s current state. CICSPLEX SM AGENT ARCHITECTURE CICSPlex SM (CPSM) provides single system image management through a network of CICS Managing Address Spaces (CMASs). These CMASs communicate with CPSM agents running in the target CICS regions. For example, these agents are responsible for INQUIREing and SETting the attributes of CICS resources. Communication from the CMAS to the CPSM agent is achieved through a communications agent, also running in the CICS region, which mediates requests from the CMAS. Communication with this agent is via MVS cross-memory services (not CICS communication services). The communications agent, query, and set agents, along with other CPSM infrastructure services, are initialized at CICS initialization via PLT processing. This establishes long-running tasks that, essentially, process requests for the lifetime of the CICS region. These resources run on the QR TCB. This does expose them to the possibility of being blocked because looping tasks dominate the QR TCB, or delayed through resource shortage (eg storage). CICS WORKLOAD TYPES CICS workloads can be classified into various types for the purposes of this discussion as follows:

• Normally executing tasks – the vast majority of CICS tasks. These are susceptible to a CEMT PURGE TASK command.
• Looping tasks – these are tasks that can be looping within themselves (and therefore susceptible to CICS runaway task detection process, ICVR process). They are looping through the CICS exec layer issuing EXEC CICS commands.
• Tasks in a purgable wait – these are susceptible to a CEMT FORCEPURGE TASK command.
• Tasks in a non-purgable wait (eg a DB2WAIT) – these are not susceptible to a CEMT FORCEPURGE command, but are susceptible to a kill command. It should be noted that the number of situations in which tasks are placed into a nonpurgable wait has reduced with each CICS release. For example, dispatcher and DB2 changes in CICS TS 2.2 have resulted in the ability to purge tasks in a DB2WAIT state without the need for kill.

CICS STATE The state of the CICS system can also play a role in being able to kill a task. If the system is at maxtask or is short on storage, then a new task (such as CEMT) cannot be dispatched. This is an instance where CPSM’s long-running task architecture will be able to issue the appropriate command, whilst base CEMT would not. The scenarios are summarized in Figure 1.

Class	CEMT	CPSM, CICS PM	Third Party Tools
A	Yes	Yes	Yes – normal stuff
B	No	Yes	Yes – eg region at maxtask
C	No	No	Yes – unable to dispatch on QR TCB
D	No	No	No – the rest

Class A is the majority of situations; Class B can still be performed by CPSM; Class C is a very small (and reducing) class because of CICS internal changes; Class D is minute and no-one addresses it. CICS PURGE PROCESSING The current CICS purge processing is as follows. Upon receipt of a purge request, the CICS dispatcher saves the purge request information. If the purge is not successful, a purge is retried each time the task is suspended, and a deferred abend request issued. The purge may be rejected because the task is not suspended, or the task is purge/forcepurge protected. OPPORTUNITIES TO EXTEND CICS TS IN THIS AREA CICS PM supports CICS TS 1.3 and CICS TS 2.2. Open Transaction Environment TCBs were introduced in CICS TS 1.3. These TCBs execute independently of the CICS QR TCB. It would be possible to provide communications endpoints and INQuire/SET services from an OTE TCB. In this way, management services would still be available when the QR TCB is hung up. Extensions to the ICVR and PURGE mechanisms could establish the need to kill a task; if not immediately attainable, this would be performed on subsequent traversal of the CICS exec layer. Other obvious places include RMI calls and DL/I command interfaces. This could exclude some of the current checks that are made to ensure data integrity. Purging of tasks could also be prioritized by age of the tasks. SUMMARY Some third-party performance products provide the ability to kill tasks in a CICS system. Extensions to CICS Transaction server have, in each release, reduced the need for such a function. The longrunning agent architecture of CICSplex SM also reduces the number of cases in which such a function is necessary. There is, however, a very small subset of scenarios where such a function is required. We are looking at ways in which to provide such function via CICS Transaction Server, which will be utilized by a future release of CICS Performance Monitor. Paul Johnson CICS Transaction Server Systems Management Planning/Development IBM Hursley (UK) © IBM Reprinted with permission