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 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
ASGS 270 0.000631 0.000184 0.049629 0.000125 0.000137 30
ASGX 269 0.000284 0.000140 0.037569 0.000030 0.000038 10
ACHL 5390 0.000163 0.000036 0.196422 0.000036 0.000037 0

CPU time

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.

Response time

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.

Workload management

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.

Join The Discussion

Your email address will not be published. Required fields are marked *