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.
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.
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.
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.
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.