Solving a Six-Decade-Old Problem
Many of the world’s most critical business applications run as CICS transactions against VSAM files. Banks depend on that combination for ATMs and teller systems, insurers for claims, airlines for reservations, manufacturers for inventory control, and governments for tax filings.
These applications work. They are fast, proven, and full of business rules nobody wants to rewrite. What limits them is not the code. It is a scheduling constraint that has nothing to do with business value.
The Cost of Taking Turns
CICS owns every VSAM file it has open, so a batch job that needs to update one waits its turn. That design dates to 1969, and the options for getting around it have not changed.
Close the file and take the application down, and the business loses access until batch finishes. Point users at a read-only copy, and the screens stay up but show yesterday’s data and refuse the updates people came to make. Loosen the file-sharing rules, and performance suffers while integrity problems go unsolved. Or move the data off VSAM and rewrite everything that depends on it, and a timing problem gets the most expensive answer there is.
Each is a workaround, and each concentrates risk into a narrow overnight period. A long-running job, a late input file, an unavailable dataset, or a botched restart pushes into the morning and takes availability with it.
Meanwhile the batch window is closing. The hours when batch once had the files to itself are no longer quiet. Customers expect to transact at midnight. Partners send files all day. Regulators want faster settlement. The batch schedule keeps absorbing work while the hours to run it keep shrinking, and teams spend more effort tuning batch than asking why every job has to run inside the window.
Batch as Just Another Transaction
SYSB-II, from H&W Computer Systems, lets batch update CICS-owned VSAM files while CICS stays online. Rather than prying a file away, it routes the batch job’s file requests through CICS, which performs each read, write, update, or delete and hands the result back to the batch program. To CICS, the batch job looks like any other transaction.
This is why SYSB-II settles the integrity question instead of raising one. Batch is not a competing second path to the data. It is the same path, so record locking, logging, rollback, and security govern batch updates exactly as they govern online work.
Nothing in your applications changes: batch programs and the business rules inside them stay as written. You choose which files and jobs SYSB-II manages, as few or as many as you want, and how often batch commits its work. It leaves every other VSAM file alone.
What Changes with SYSB-II
Batch runs when the work arrives, not when the clock allows. Payments post during the day, claims update as they come in, order feeds process on arrival, and downstream systems stop waiting for batch to release them.
Because SYSB-II handles file access as part of the job, nobody has to take files away from CICS and hand them back again. That nightly ritual disappears, along with the mistyped commands and missed handoffs it invites. And when a job does fail, recovery that once consumed a morning takes minutes.
Less work is left overnight, and the gains are easy to count: hours of CICS availability returned and job steps taken off the critical path. For the bank, the insurer, and the airline, the measure that matters is simpler. It is how much sooner the work reaches the person waiting for it.
Proven Under Pressure
H&W has built mainframe software since 1979. Its customers include financial institutions, insurance carriers, large enterprises, technology providers, distributors, universities, and government agencies. In all of them, a missed batch window becomes a public event.
The specifics vary. One organization needed to absorb rising transaction volume. Another had a fast-growing service line that outgrew its overnight hours. A third could not keep taking its applications offline to run batch. Each deployed SYSB-II, and each now updates CICS-owned VSAM files from batch while online applications stay available. There is no shutdown, no read-only copy, and no waiting for the batch window. See how others are using SYSB-II.
The common thread is not industry. It is that each had applications too valuable to rewrite and a batch schedule that had stopped fitting the business.
Beyond the Window
Tuning batch is still worth doing. But a shorter window is still a window, and depending on one is the real constraint.
Start with one job. Not the biggest, but the one whose timing causes the most friction. Run it under SYSB-II, measure the before and after honestly, and expand from there.
The goal is not to finish batch earlier. It is to let the business do important work when that work needs to happen.
Learn More
H&W Computer Systems specializes in mainframe availability. SYSB-II runs on current releases of z/OS and CICS Transaction Server. To talk through your batch window with an engineer, or to arrange a proof of concept on one of your own jobs, visit www.hwcs.com.
SYSB-II is a registered trademark of H&W Computer Systems, Inc. IBM, CICS, and z/OS are trademarks or registered trademarks of International Business Machines Corporation.