We've introduced the CICS asynchronous API in previous blogs: new for the CICS TS 5.4 open beta, the asynchronous API enables a simple, supported asynchronous programming model for CICS. Using a parent-child model, the API allows a parent task to create one or more child tasks which run asynchronously to both the parent and each other, returning their results when queried by the parent task.

Previously, the API centered around two commands: EXEC CICS RUN TRANSID, which kicks off child tasks, and EXEC CICS FETCH CHILD, which fetched the results of the specified child task. With the open beta release at the end of 2016, we've introduced a third command: EXEC CICS FETCH ANY.


Previously, when a parent task wanted to get the results of a child task, it could only do so by querying a specific child. With EXEC CICS FETCH ANY, a parent task can make a more generic query for the results of any completed child task. Using FETCH ANY, application logic can be more flexible and process workload optimally, rather than in a fixed order which may not be the most efficient.

Use cases

The FETCH ANY command works best as part of applications which create multiple child tasks, but don't necessarily need the results of all of them, or don't require the results of the child tasks in any specific order. By processing the results of child tasks as they complete, FETCH ANY allows applications to minimize the amount of time they spend waiting for responses, and thus maximize responsiveness.

When comparing asynchronous and sequential processing, we looked at an example application which simulates a credit check, kicking off multiple child tasks which each perform one aspect of the credit check itself, such as checking an address, or getting a credit score. When getting results, it looked something like this, kicking off a series of FETCH CHILD commands:

                           COMPSTATUS  (CHILD-RETURN-STATUS)
                           ABCODE      (CHILD-RETURN-ABCODE)

It runs a FETCH CHILD command against each child task in turn, and doesn't progress if that child hasn't completed. Even if the second child is already done, the application continues to wait for the first, even though it doesn't matter what order the results return in. The FETCH CHILD command has its uses: in situations where the results of a specific child are required before the business logic can progress, the FETCH CHILD command is perfect – for other situations, FETCH ANY is often more efficient.

With FETCH ANY, the application can run much more efficiently. An EXEC CICS FETCH ANY command will return the results of any completed child task, no matter what order they were initiated in, and our example application will look more like this when getting results, using multiple FETCH ANY commands:

                           COMPSTATUS  (CHILD-RETURN-STATUS)
                           ABCODE      (CHILD-RETURN-ABCODE)

More flexibility, more efficiency

By allowing applications written with the asynchronous API to be more flexible in how and when they receive child responses, the new FETCH ANY command can make those applications faster and more efficient. Processing results as they come in, rather than in a fixed order, allows parent tasks to complete as soon as possible, further reducing the response times of asynchronous applications.

For more of the specifics of the FETCH ANY command, see the IBM Knowledge Center.

Join The Discussion

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