This section examines the ways in which business transactions have traditionally been modeled by CICS® transactions, and some of the shortcomings of the traditional approach.
A business transaction is a self-contained business deal--for example, buying a theatre ticket. Some business transactions--for example, buying a newspaper--are simple and short-lived. However, many are not. Many involve multiple actions that take place over an extended period. For example, selling a vacation may involve the travel agent in actions such as:
Both the customer and the travel agent regard the purchase of the vacation as a single business transaction, as indeed it is, because each action only makes sense in the context of the whole. The example illustrates some typical properties of complex business transactions:
The basic building blocks used by CICS applications are the CICS transaction and the unit of work (UOW). Typically, a UOW is short-lived, because it is undesirable for it to hold locks for long periods, thus causing other UOWs to wait on resources and possibly abend. A CICS transaction consists of one or more UOWs. It provides the environment in which its associated UOWs will run--for example, the transid, program name, and userid. Typically, like the UOWs of which it consists, a CICS transaction is short-lived, because the aim should be for it to use CICS resources only while it is doing work--it should not spend long periods waiting for input, for example.
Before CICS Transaction Server for OS/390® Release 3, the largest transaction processing unit that CICS understood was the terminal-related pseudoconversation. A pseudoconversational application appears to a terminal user as a continuous conversation, but consists internally of multiple transactions.
Traditionally, application programmers have modeled business transactions using the basic CICS building blocks, transactions and units of work. However, there are problems. Here are some of them:
Typically, the individual actions that make up a complex business transaction are mapped on to CICS transactions. Usually, it is not practicable to map a whole business transaction on to a single, long-running CICS transaction (even if the transaction is divided into multiple units of work), because of resource constraints. The locks held by the UOWs would tend to be held for long periods; system performance would suffer, and transaction abends become frequent, due to deadlocks or contention for locked resources.
Mapping each individual action on to a CICS transaction is a more sensible option. However, this approach ignores the overall structure of the business transaction. Typically, the control logic necessary to glue the actions together ends up being spread between the various CICS transactions. Thus, the high-level logic required to control the overall progress of the business transaction and the low-level logic required to implement a specific business action become blurred. One effect is that the CICS transactions become less easy to reuse, because they are required to do more than implement a particular business action.
An even better option might be to separate the control logic in a single, top-level program that would be reinvoked whenever a new stage of the business transaction was ready to run. Each time it was invoked, the top-level program could run a transaction that implements a particular action of the business transaction. This would work similarly to a terminal-related pseudoconversation, in which terminal events cause successive transactions to be invoked. Unfortunately, in CICS releases prior to CICS Transaction Server for OS/390, Version 1 Release 3 this was not possible. A pseudoconversational application could be used only to simulate a single conversation with a terminal.
Long-lived business transactions are much more likely than short-lived transactions to span restarts of CICS (which may or may not be planned). To survive restarts, state data relating to the business transaction’s flow of control must be saved to a recoverable resource. Thought must also be given to how the business transaction is to be restarted after a restart of CICS.
CICS business transaction services extend the CICS API and provides support services that make it easier to model complex business transactions. How it does this is the subject of What are CICS business transaction services?.