Use Case
Turn Mainframe MIPS into Digital Services
Mainframes run the business reliably, but every new digital service adds cost. Offload reads to reduce MIPS and load on the core: ingest data once and serve all channels, including mobile, web, APIs and partners.
How Is MariaDB GridGain used for mainframe offload?
Mainframe offload moves high-volume reads and compute tasks onto the distributed in-memory caching layer while the mainframe stays the system of record. Read queries can be >80% of mainframe volume, so serving them from memory provides sub-millisecond responses, cuts MIPS/MSU consumption and reduces complexity.
Capabilities
What mainframe offload needs
Three capabilities make offloading work: live access to mainframe data, in-memory processing that absorbs read and write traffic, and compute that runs alongside the data instead of on the mainframe.
Real-time access
A data virtualization layer maps VSAM, CICS and sequential files to relational or NoSQL views outside of the mainframe, with no ETL or stale copy.
Read and write offload
Read-through serves hits from memory and optimizes disk access. Write-behind acknowledges writes in memory and flushes in bulk, flattening peak CPU and optimizing I/O.
Colocated compute
The compute grid runs SQL joins, aggregations and custom code in memory beside the data, moving reporting, risk analysis and fraud scoring off mainframe CPUs.
Mainframe modernization key patterns
The mainframe remains the system of record. MariaDB GridGain runs as a digital integration hub in front of the core, with data ingested from the mainframe in batches via data virtualization software or streaming updates with CDC tools.
Data integration
Turn data in formats such as VSAM, CICS, flat files and DB2 into unified, integrated, real-time views with joins and aggregations.
Phased modernization
Use MariaDB GridGain as an abstraction layer to decouple applications from the mainframe, then consider upgrading/migrating the mainframe data layer.
Code modernization
Turn legacy stored procedures and business logic into MariaDB GridGain colocated compute to offload the work and modernize the code base while preserving sub-millisecond processing.
Get started
Start building with MariaDB
One real-time database platform you can trust, for everything you run today and everything you build next.
Frequently asked questions
Mainframe offload moves high-volume reads, APIs and CPU-intensive processing onto a distributed in-memory layer while the mainframe remains the system of record. This reduces MIPS and gives applications access to real-time data.
Every query served from the in-memory data layer is a mainframe CPU and I/O processing that never happens.
Yes. The mainframe remains the system of record while an in-memory layer absorbs read-heavy requests from digital channels, including web, mobile, APIs, and partners. Applications access data through modern languages and standard interfaces, including SQL, REST APIs and JDBC/ODBC drivers.
Optimization, including offload, makes the existing mainframe more cost-effective and efficient. Modernization moves mainframe workloads to new platforms. In either case, offload is the first step: it cuts MIPS immediately and enables future migrations.
A data virtualization layer exposes VSAM, CICS and sequential files as virtual relational views over JDBC/ODBC, giving live reads with no ETL. For high-throughput, low-latency mainframe offloading, consider a hybrid pattern: DVM for the initial hydration to MariaDB GridGain. A CDC tool, like IBM IIDR or a CICS log reader, streams the ongoing real-time deltas into Kafka/GridGain as business transactions occur on the mainframe.