If you run on IBM Z, you may still stop CICS overnight so batch jobs can update VSAM files. That pause might be necessary today, but it is no longer a requirement.  We will show you how to remove the trade-off between fresh data and uninterrupted access with VSAM file-sharing.   

The Value in One Paragraph

Through VSAM file-sharing, SYSB-II makes batch look like any other CICS transaction. Instead of forcing exclusive control of VSAM, it routes batch file I/O into the owning CICS region, executes under CICS rules (locking, journaling, backout), and returns the result to batch. Users keep working, jobs keep running, and these same processes can increase the productivity of applications that rely on VSAM. The result is higher availability, shorter or eliminated batch windows, more modern VSAM-based applications, and fewer SLA misses.  When customers can transact at any hour, they don’t bounce to a competitor or call the help desk later. They finish the order, file the claim, post the payment – right now. That’s the most important benefit of VSAM file-sharing: more completed work with fewer retries and less frustration.

The Problem: There is still a Batch Window for VSAM

Historically, VSAM datasets allocated to CICS were “owned” by the online region. Batch could not update those files until CICS closed them.  A design that made sense when online activity followed office hours. Today, we find that it collides with always-on digital channels, multi-region operations, and SLAs that assume upstream systems are current. The result is familiar in financial services, Insurance, and manufacturing: rushed mornings, delayed feeds, brittle handoffs between overnight processing and daytime activity, and the batch window that competes with revenue hours.

The Solution: How VSAM File-Sharing Enables Continuous CICS Access

File-Sharing eliminates the exclusive-open bottleneck. Batch jobs no longer force datasets away from CICS; they access files through CICS while the region stays online. With SYSB-II, when a batch step issues VSAM I/O, SYSB-II intercepts the call and routes it to the owning CICS region. CICS performs the read or write under its normal rules—record locking, journaling, backout, and, when relevant, two-phase commit—and returns the result to batch. Users keep working, jobs keep running, and data integrity remains under the same controls that protect online workloads.

How VSAM File-Sharing Works Behind the Scenes

SYSB-II uses the documented MVS subsystem interface and communicates over VTAM or TCP/IP and cross-memory services, translating batch I/O into EXEC CICS file commands. Code that runs inside CICS executes as a command-level transaction, so existing tooling, accounting, and operational safeguards continue to apply. It is important to note that SYSB-II is present in the CICS address space only while file-sharing batch jobs are active, keeping the path short and terminal response consistent.

Where teams feel the difference most:

• More hours of Revenue – Customer-facing services stay online during processing peaks.
  “We have reduced our batch window by 2 ½ hours. On our heaviest days, we are posting a million cash transactions during the day instead of at night.” 

• Fewer SLA Violations – overnight “catch-up” work diminishes as jobs run throughout the day.
  “The first week we didn’t close CICS felt strange—like we forgot a step,” our operations lead told me. “Then we noticed the quiet: no 2 a.m. scramble, no 7 a.m. backlog. We just… started the day.”

• Lower Operational Risk – incident recoveries align with CICS standards, improving consistency.
  “Since then, we have implemented what we call our automatic recovery, where if the batch job abends, the backout step executes automatically.”

We find that day-to-day operations remain familiar. You do not rewrite business logic, make source code changes, or refactor program flow. One of the biggest benefits to you is that you can keep the existing JCL and designate which VSAM datasets SYSB-II should manage. Batch steps continue to run under the batch address space between EXEC CICS calls, so monitoring and performance controls remain unchanged. Scheduling stays in the products you already use, and prioritization follows the CICS task management you have tuned.

• Task priorities and dispatching determine relative emphasis for interactive and batch tasks.
• Sync-point strategy controls lock duration and commit cadence, stabilizing response times.
• File-sharing across local, cross-region, or cross-system scenarios works without RLS or coupling facilities, simplifying deployment in complex environments.
• Elimination of manual File management: Open/close routines waste staff hours and introduce risk. SYSB-II automates file access and integrates with existing batch JCL.

Mainframe-Based Innovation 

Modernization isn’t just about cloud migration or refactoring. It’s about removing friction between technology and the business. Keeping CICS open while batch updates VSAM aligns online and back-office views of data in real time, reduces technical debt from workarounds, and provides a pragmatic path to continuous digital services without re-architecting reliable CICS applications. It also establishes a stable foundation for future integration projects.

Real-World Results

Results tend to be practical and measurable. One financial institution cut its nightly batch window roughly in half, accelerating statement runs and easing morning contention. In another environment, recovery times and data consistency after batch abends improved markedly because backout and journaling remained under CICS control.  One manufacturer that implemented VSAM file sharing was able to move to near-real-time processing after moving batch workloads to CICS. 

Test it Out for Yourself 

Start with one workload that routinely collides with business hours—EDI ingest, a pricing refresh, or end-of-day accounting—and run it as a pilot. Point SYSB-II at the VSAM datasets that process touches, enable file-sharing, and track two metrics: customer-visible availability and batch elapsed time. From there, expand coverage iteratively, guided by operational pain. We found that because SYSB-II intercepts I/O only for the datasets you specify, you can stage adoption across regions and lines of business. Any change is tough to accept in systems and jobs that are business-critical.  We made SYSB-II as easy to incorporate as we could to help with this transition.   We want you to do a side-by-side comparison of before-and-after behavior and ease of use.  

The Wrap Up

With VSAM file sharing, we do not ask you to change how your business runs; we remove a constraint on the business. By enabling batch update of VSAM through CICS, it extends the integrity, recovery, and control you trust to workloads that once forced downtime. The result is higher availability, fewer SLA misses, and a mainframe-based modernization win that shows up quickly on dashboards and soon after on the balance sheet. If eliminating batch windows without rewriting application code is the goal, start with one process, validate the operational lift, and scale by business value.  When your dashboards stay green at midnight and noon, you’ll know you’ve turned a nightly habit into a daily advantage.

Want to eliminate VSAM batch windows without rewriting a single line of code?
Read more about this benefit and other Common VSAM Problems and their Solutions.