C H A P T E R  7

Asynchronous START Transactions

This chapter describes how transactions begun with the START command can affect the operation of your region.


Transactions Do Not Appear to Start

If transactions do not appear to start, execute the kixdump -A command, which produces a report that is useful for debugging. CODE EXAMPLE 7-1 shows a sample report that has four pending transactions that were initiated with the START command: a START with data, a START with no data, a triggered START, and a background START.

CODE EXAMPLE 7-1 kixdump -A Output--Example

10/03/2001 14:48:10 kixdump     :entering version 7.2 - 09/24/2001
 
Shared Asynchronous Start List
-----------------------------
 
Application: <All Blanks>
KIXSYS: </net/haven/home/test/primer>
 
>> Node No: 1 <<
 
Trans Id: SRTD           |   Trigger Time:     Wed Oct 3 14:47:53 2001
Term  Id: <C001>         |   Started Data Len: 15
Item No:  1              |   Start Code:       SD
Protect:  Yes            |   Req Id (in hex):  73 6F 6D 65 72 65 71 64 
RTranid:  ABCD           |   RTermid:          <WXYZ>
RQueue:   1234           |   SysId:            <All Blanks>
 
>> Node No: 2 <<
 
Trans Id: ACCT           |   Trigger Time:     Wed Oct 3 14:47:53 2001
Term  Id: <C001>         |   Started Data Len: 0
Item No:  0              |   Start Code:       S
Protect:  No             |   Req Id (in hex):  34 30 30 30 31 00 00 00
RTranid:                 |   RTermid:          <All Blanks>
RQueue:                  |   SysId:            <All Blanks>
 
>> Node No: 3 <<
 
Trans Id: SRTD           |   Trigger Time:     Wed Oct 3 14:47:53 2001
Term  Id: <C001>         |   Started Data Len: 0
Item No:  0              |   Start Code:       QD
Protect:  No             |   Req Id (in hex):  34 30 30 30 32 00 00 00
RTranid:                 |   RTermid:          <All Blanks>
RQueue:                  |   SysId:            <All Blanks>
 
>> Node No: 4 <<
 
Trans Id: BGTR           |   Trigger Time:     Wed Oct 3 14:47:53 2001
Term  Id: <All Blanks>   |   Started Data Len: 0
Item No:  0              |   Start Code:       S
Protect:  No             |   Req Id (in hex):  34 30 30 30 32 00 00 00
RTranid:                 |   RTermid:          <All Blanks>
RQueue:                  |   SysId:            <All Blanks>
*** End of Asynchronous Start List - 4 entries printed ***
 

If the transaction in question is listed in the report, see if it is to run against a terminal. If it is, determine if the terminal is installed or busy by running the kixdump -G command, which displays a formatted report showing the status of the terminals defined in the TCT. If the terminal is not installed or is busy, that is the reason the transaction is not running.

If the transaction is not listed in the report, or if it is listed but the terminal is not the problem, check to see if transaction processors are available to execute the transaction. Use the kixdump -u command to display a report on the status of transaction processors.


Transactions, Temporary Storage, and Their Effect on Performance

When a transaction issues an EXEC CICS START to start another transaction asynchronously, the transaction processor sends a message to the Sun MTP interval control processor (unikixstrt) requesting the START. In an attempt to avoid flooding the message queue used for sending messages to unikixstrt, the transaction processor suspends activity for 2 seconds if it finds that the queue depth is greater than the number of transaction processors configured in the VSAM Configuration Table (VCT). This slight delay might affect system performance when several transactions are issuing START commands.

unikixstrt maintains a list of pending START requests. START requests might be pending for several reasons, among them:

The unikixstrt process tries to ensure that the transaction it is scheduling to START has the resources it needs for execution.

If a transaction is to START with data, the transaction processor writes the data (commonly referred to as FROM data) to the Sun MTP temporary storage file, TEMPSTG, which is a VSAM KSDS file. All writes to TEMPSTG are cached writes, so the performance of these transactions should improve.

A START with data followed by a RETRIEVE in the transaction begun with the START command is essentially a WRITEQ TS followed by a READQ TS, which is a VSAM WRITE followed by a VSAM READ and DELETE operation, as far as the data is concerned. If the VSAM operations involved degrade performance despite cached writes, alternative methods for passing the data to the transaction begun with the START command can be used. One method is to do a WRITEQ TS MAIN for the data and pass the temporary storage queue name to the transaction in the QUEUE option of the START command. This avoids VSAM disk I/O and should boost performance.