In this article we explain how CICS can provide zero online downtime to established applications which use VSAM as their data store.

The scheme uses a CICS Global User Exit (GLUE) to seamlessly switch from one set of files to another while respecting transactional integrity, providing an additional alternative to ‘stop-the-world’ approaches which interrupt service to customers.

IBM provides a sample GLUE in this GitHub repository.

Limits and demands on 24x7 service provision

Many CICS applications store critical enterprise data in z/OS VSAM data sets. VSAM has been an appropriate and efficient choice for such data for decades and still provides unique operational characteristics.

However, one characteristic which many applications share is the need to take VSAM data sets offline on a periodic basis. For example, many business scenarios demand specific actions to mark the end of a business day and/or to prepare for the beginning of the next day. Other periodic events include weekly or monthly demands for reporting or archiving.

In the past, an end-of-day business event might typically coincide with the natural closure of business for the day - so it was a good opportunity for other data and media maintenance operations, as well as the daily functional business requirements to be satisfied.

While the end-of-day processing still has strong business justifications - such events are often baked-in to the business processes which the application supports - the disruption to service users is increasingly intolerable. For example, a core banking service might need to have a clearly defined end-of-day so that it is obvious when debit and credit activity from the day must be resolved for interest calculations. But at the same time, banking customers now expect to be able to make card payments or move money between their accounts 24x7.

Much additional effort has been expended to provide stand-in services or caches within architectural layers in front of the CICS VSAM applications which are the true systems-of-record, but these add complexity and expense, and additional components whose resilience must be assured for service delivery.

Can CICS help to provide zero online downtime for VSAM data?

Data access and transactional consistency for high-volume, mission-critical business services are amongst the primary capabilities of CICS Transaction Server.

Availability and resilience built on the strengths of the IBM Z platform and z/OS features such as Sysplex and Workload Management alongside complementary data base (IBM Db2), messaging (IBM MQ) and secure communication services mean CICS applications provide industry-leading qualities of service.

In 2025 a leading application ISV asked the question:

“Can CICS help to eliminate daily service downtime for our widely used application package?”

They truly understood the demands outlined above, but needed a robust and effective approach which would be minimally disruptive to their application and to the many clients who have it deployed.

Could we think of an innovation which fulfils the demands for simplicity, ease of adoption and performance while maintaining all the integrity and consistency expected by applications accessing data managed by CICS transactions?

Shrinking downtime to zero

Working with the ISV we looked at the overall end-of-day processing which included quiescing and closing the past day’s VSAM data sets for multiple minutes.

They had worked with their clients to remove unnecessary steps in the long-established process and optimize the remaining essential processing.

But this could only bring the interruption to service down so far - the service would still be seen by its users as unavailable in a certain window on a daily basis.

Quiescing, closing… or just switching?

Looking at the objectives of quiescing the workload using the data set and closing it, we saw that the purpose is often to switch to a new one for the next period.

Some known examples of the disruptive, “stop-the-world” operational processes close the data sets in order that there is a ‘hard’ division in time - an instant in time (but more likely to be minutes) when there are no online transactional updates involving the data sets.

Stopping the world is a two-stage process:

• quiesce the application access to the data sets. CICS allows in-flight transactions to complete, but denies new ones from accessing the file
• closing the data sets to disassociate them from any use by CICS applications.

In this closed state, typical operations might be to copy the ‘today’ data and make ready the ‘tomorrow’ data.

Once those actions in the quiesced state are complete, the data sets can be re-opened and made available to the applications.

Why does this have to be so disruptive? Can we do this differently?

CICS applications actually deal with Files - with a resource definition to link it to a data set. Every request to a file can also be mediated by the actions of a Global User Exit, XFCREQ and one thing the exit can do is change the name of the file.

This means that there is an opportunity to redirect file requests (both READ and WRITE) to a different file, and thus a different data set on a request-by-request basis.

Redirecting requests - the how and the when

The ability to modify the request made in the execution of an application program is one of the primary uses of CICS Global User Exits (GLUEs), and these have been a part of CICS TS for decades.

A exit program which is installed and enabled as a GLUE associated with processing of a CICS command receives the information passed from the application and, depending on what IBM allows, may modify the inputs to the CICS system code implementing the command.

For XFCREQ this includes changing the filename.

To meet the needs of the scenario described above, the exit selectively changes the filename but with awareness of task boundaries so that all use of a file for a task are consistent.

As well as using information about which filenames to switch, the exit implementation checks whether the task it is running under started before or after a chosen moment in time, which I will refer to as the “switch moment”.

By doing this, any application accesses to a given filename will be entirely consistent, but tasks which begin before the switch moment will access one set of files, and those that start after will be switched to a different set.

Thus the ‘old set’ of files will naturally quiesce as the ‘new set’ take over.

(This scheme does assume that tasks accessing the files in question are reasonably short in duration, otherwise the old set will be seen to remain active as far as the GLUE is concerned.)

The result is that it is unnecessary to explicitly quiesce and close the old set of files before the new set are used - if the new set are valid for the new time period after the chosen switch moment, then service is never interrupted.

Usage considerations

Overheads of exits

Enabling a GLUE carries a small linkage overhead as control is passed from CICS to the GLUE, plus the pathlength of the exit itself. The sample exit provided uses an in-memory map of files to switch and incurs no I/O or external service costs, so is minimal in its affect on CPU consumption.

Any overhead it does impose on the task will depend on how many File Control commands are executed by the task and how extensive the list of candidate files to be switched is.

Logical constraints

While the transactional consistency of the switch from one set of files to another is the whole point of this scheme, it could be that logical constraints extending beyond individual transactions exist in the design or implementation of the application.

Using this scheme introduces the possibility that two requests which start close together but either side of the switch moment will access different sets of files and that their lifetimes overlap so there might be updates into the new set which precede updates into the old set. Determination of the correctness of that requires knowledge of application assumptions and whether such overlapping updates could violate business logic constraints.

Also, since the file being switched from and the one being switched to are used concurrently until all the transactions using the older one have completed, the new file cannot be created from the quiesced state of the old file. If you need to initialise the new file from a ‘completed’ version of the old one, this scheme won’t work for you.

Summary

This scheme presents an opportunity to re-think the evermore painful impacts of service interruptions, however brief, when using VSAM data.

Eliminating the need to stop-the-world as far as services go in order to achieve a switch from an ‘old’ set of files to a ‘new’ set can be achieved with use of a small and efficient CICS exit.