The initial request

The initial request to start a Sale business transaction is handled by the MNU001 and SAL001 programs. When a terminal user selects the Sale menu option, the menu program MNU001 links to the SAL001 program to service the request. SAL001 establishes a unique reference for this instance of the Sale business transaction and starts it.

Figure 12 shows, in COBOL pseudocode, how SAL001 creates and starts an instance of the Sale business transaction.

Figure 12. Pseudocode for the SAL001 program. SAL001 creates and starts an instance of the Sale business transaction.
Identification Division.
Program-id. SAL001.
Environment Division.
Data Division.
Working-Storage Section.
01  Sales-Reference               pic x(36) value low-values.
    .
01  Process-Type                  pic x(8)  value 'Sales'.
    .
Linkage Section.
01  DFHEIBLK.
    .
01  DFHCOMMAREA.
    .
Procedure Division using DFHEIBLK DFHCOMMAREA.
In-The-Beginning.
    .
    .. create unique sales reference ..
    .
    EXEC CICS DEFINE PROCESS(Sales-Reference) PROCESSTYPE(Process-Type)
                 TRANSID('SALE')
                 PROGRAM('SAL002')
             RESP(data-area) RESP2(data-area) END-EXEC
      .
    EXEC CICS RUN ACQPROCESS
                 SYNCHRONOUS
             RESP(data-area) RESP2(data-area) END-EXEC
    .
    EXEC CICS RETURN END-EXEC
End Program.

Creating the business transaction

To create an instance of the Sale business transaction, SAL001 issues a DEFINE PROCESS command. The PROGRAM option of DEFINE PROCESS defines a program to run under the control of CICS® business transaction services--a root activity program that typically manages the ordering and execution of the child activities that make up a business transaction. In this case, the program is SAL002, which is the root activity program for the Sale business transaction.

The PROCESS option uniquely identifies this business transaction instance from others. (The creation of a unique reference is managed by the user. Typically, you might use a customer reference or account number.)

The PROCESSTYPE option categorizes the business transaction by assigning it a process-type of 'Sales'. Categorizing your processes (business transactions) in this way means that you can browse details of individual processes--and their constituent activities--more easily.

The TRANSID option serves a number of purposes:

Security
If security is active, CICS performs a security check to see if the requestor has authority to use the specified transaction identifier (transid). Thus, in this example, there would be a check on whether the requestor is authorized to create a new instance of the Sale business transaction.
Externals
When a business transaction is started, its root activity program begins executing, and any external inquiry such as CEMT shows work being done under the root activity’s transaction identifier.

In the Sale application, the Sale business transaction is started under the control of the MENU transaction; however, the actual start of an instance of the Sale transaction occurs when control is passed to the root activity program, SAL002. At this point, the transaction identifier changes from MENU to SALE.

Root activity
Later restarts of a root activity may be required to deal with child activities that are executed with the RUN ACTIVITY ASYNCHRONOUS command (the child activities are executed asynchronously with the root activity, are not included in its unit of work, and have different transaction identifiers).

In the Sale application, the SAL002 root activity program is attached under the SALE transaction identifier to deal with the Delivery, Invoice, and Payment activities, that all execute asynchronously, under separate UOW scope, and under different transaction identifiers.

Monitoring and statistics
The transaction identifier can be used to track resource usage for monitoring, statistics, and accounting purposes. It allows monitoring and statistics information to be related to a CICS business transaction services process.

DEFINE PROCESS is a synchronous request and control is returned to the requesting program when BTS has accepted the request and added the process to the set that it is currently managing.

The addition of the process is not committed until the current unit of work has taken a successful syncpoint. If the requesting task abends before the syncpoint is taken, the request to add the process is canceled. (Thus it is not possible to enquire on or to browse the process until the syncpoint has been taken.)

Starting the business transaction

To start this instance of the Sale business transaction, on return from the DEFINE PROCESS request SAL001 issues a RUN ACQPROCESS command. A program can "acquire" a process in two ways: by defining it, or by issuing an ACQUIRE PROCESS command. Here, SAL001 has acquired a process by defining it; thus the RUN ACQPROCESS causes the SAL002 program specified on the DEFINE PROCESS command to be executed.

Using RUN causes the process to be activated in a separate unit of work from that of the requesting transaction, under the transaction identifier specified on the TRANSID option of the DEFINE PROCESS command. (A LINK ACQPROCESS command would have caused SAL002 to be executed in the same unit of work as MNU001 and SAL001, and under the same TRANSID, MENU.) The advantages of giving a process a separate TRANSID from that of its creator are explained in Creating the business transaction. The SYNCHRONOUS option on the RUN command causes SAL002 to be executed synchronously with SAL001.

Although a RUN ACQPROCESS command causes a process to be activated in a separate unit of work from that of its requestor, the start and finish of the activation are related to the requestor’s syncpoints. In the example application, the SAL002 root activity runs its first child activity (Order) synchronously and as part of its own unit of work. If the Order activity is successfully completed (in the business sense as well as the transactional sense), the Sale business transaction will be accepted. If not, it will be rejected. "Accepted" means committed--this instance of the Sale transaction will be ready to start its next activity. "Rejected" means rolled back--this instance of the Sale transaction will no longer exist.

Related concepts
Overview of the Sale application
The root activity
Transferring input and output data
Using the BTS API to write business applications
Related reference
Overview of BTS API commands
BTS application programming commands
[[ Contents Previous Page | Next Page Index ]]