Using the CICS asychronous API enables you to make the most of asynchronous processing in a flexible, supported way – but how does the API's
RUN TRANSID command compare to pre-existing alternatives such as
EXEC CICS RUN TRANSID vs.
EXEC CICS START
When it comes to starting other transactions, the
START command is the nearest existing relative of the new
RUN TRANSID command. To compare their performance, we ran two transactions:
ASGX issues ten
RUN TRANSID commands, and
ASGS issues ten
START commands. They both start the same transaction,
ACHL, and pass it a channel with 4KB of data as input.
The table below shows the CICS performance class monitoring data collected for our two transactions:
|Transaction||Number of Tasks||Average Response Time||Average User CPU Time||Total User CPU Time||Average QR CPU Time||Average QR Dispatch Time||Average DSCHMDLY Count|
As shown in the table, the average CPU time for the
ASGX transaction was 140 microseconds, compared to 184 microseconds for the
ASGS transaction. Bearing in mind that these two transactions each started 10
ACHL transactions, and the rest of application logic was exactly the same, the delta for each API command is 4 microseconds.
The table also shows that the response time for the average
ASGS transaction is 631 microseconds, compared to 284 microseconds for the
ASGX transaction. Because
EXEC CICS START is not a threadsafe command, each of the programs invoked during the
ASGS transaction were defined as 'concurrency required'. The figures in the DSCHMDLY count column reflect the additional change mode processing required.
EXEC CICS RUN TRANSID, on the other hand, is a threadsafe API command, so programs running on an open TCB won't require any change mode processing to complete the request.
In addition to the general performance improvements shown above, the workload initiated by
RUN TRANSID commands is automatically managed by CICS when a region is under stress. If there are too many child tasks in the system, the parent tasks which are issuing
RUN TRANSID commands will be automatically suspended and resumed as necessary, limiting the number of new child tasks being created.
For more information about how the asynchronous API performs, see Managing performance with the asynchronous API in the IBM Knowledge Center, and our in-depth breakdown of how a sequential application compares to an asynchronous one.