Once upon a time, CICS applications may have been single-purpose, self-contained units. Executing in solitude with the incredible throughput and reliability of the platform, the CICS application did its job – and still does, but the times they are a changing.
Our expectations of the humble CICS application have grown: we want more insight, more capacity, and smarter processing to maintain that competitive edge. Applications that began life taking input from a terminal now have to interface with data stores, programs across multiple systems, and invoke requests to external services.
“We are asking more from CICS applications
and we want the results sooner”
Perhaps you started off with one simple database of customer details, but over a number of application enhancements, system consolidations, and business acquisitions spanning several geographies, you now have to fetch data across all parts of the organisation to build up a complete view of the customer.
Or maybe a new business objective means you need to pull together a number of dispersed services which are provided across your organisations systems.
We are asking more from CICS applications and we want the results sooner. New applications have aggressive response time goals to meet SLAs and improve client satisfaction, whilst existing apps have to be enhanced without affecting overall response times.
If any of that sounds familiar, then you’re in good company!
A day in the life of Alan
Alan, our senior CICS application programmer, has been asked to create a new app. The app will need to aggregate all the data for a customer, and run some checks to provide a tailored experience. This involves calling other systems in the organisation as well as web services served by other organisations.
Alan’s aims are simple: to write quality code with a defect-free algorithm that meets the objectives in a timely manner.
Alan begins as usual, by writing some code to step through what needs to be done: call the first service and deal with the response, call the second service and deal with the response, then – you guessed it – call the third service and deal with the response.
The diagram below shows what happens when you call services sequentially.
But what if you could execute those services in parallel? The application’s response time will be reduced because the time spent waiting for responses occurs simultaneously.
Even if you don’t have multiple services to call, you can still make response time savings if you can continue processing in the caller thread while waiting for a service response.
By running the service request in a different transaction to the caller, the caller itself is free to continue doing something else, be that business logic or calling another service. Later on, when the result is required, the caller can request the results of the service. If the called service has returned by then, great – if not, then at least time spent waiting is reduced.
Using an asynchronous model
Asynchronous processing isn’t a new idea – but it might not be something Alan is used to. In the past, Alan has tried to create an asynchronous processing model for CICS, but struggled with complexity and unstable results.
In his home-grown asynchronous framework, Alan has a lot of possibilities to consider:
The two new CICS API commands introduced in the CICS TS 5.4 open beta,
EXEC CICS RUN TRANSID and
EXEC CICS FETCH, enable simple, intuitive development of an asynchronous programming model in CICS. Using the new API commands, an application developer can run an asynchronous transaction in CICS, passing and consuming data with ease and reducing the challenges associated with home-grown asynchronous infrastructure.
“two new asynchronous API commands introduced in CICS TS V5.4 open beta
enable simple, intuitive development of an asynchronous programming model in CICS”
EXEC CICS RUN TRANSID command starts a new child transaction which will run asynchronously to the parent transaction. Similar in principle to an
EXEC CICS START command, the difference on the
RUN is that a returned
CHILD parameter enables future coordination of passed data.
Coupled with the
EXEC CICS FETCH command, you can specify a previously
RUN child transaction to fetch results from. CICS handles coordination between the parent and child transactions, and if a channel is specified, CICS containers can be used to easily pass and return data from the child transactions. Also exposed on the
FETCH command is the completion status of the child transaction for easy, transparent processing.
The CICS asynchronous API commands remove many of the maintenance, management, error and edge-case issues previously associated with asynchronous processing. They enable application developers to concentrate on efficient business logic rather than infrastructure code.