IMS vs. DB2 vs. VSAM: Which Data Store Is Your Mainframe Actually Running On

VSAM: The File System Underneath Everything

VSAM (Virtual Storage Access Method) is not a database. It is an access method, which means a way for z/OS to organize records inside datasets and retrieve them again. IBM introduced it in the 1970s as the successor to ISAM.

It earns the “underneath everything” description because it sits below the databases rather than beside them. DB2 stores its tables in VSAM datasets. So the question is rarely whether you use VSAM. It is whether your applications talk to it directly.

KSDS, ESDS, RRDS and LDS Datasets

VSAM organizes data into four dataset types:

• KSDS (Key-Sequenced Data Set): records retrieved by a logical key such as an account number. The most common type by far.
• ESDS (Entry-Sequenced Data Set): records stored in the order they were written, read sequentially or by relative byte address.
• RRDS (Relative Record Data Set): records retrieved by relative record number, which allows direct access by position.
• LDS (Linear Data Set): a byte stream with no record boundaries. This is what DB2 uses for its table and index spaces.

 

Where VSAM Still Runs Today

VSAM carries production workloads in three places:

• CICS applications, where files are read and written directly by transaction programs running on CICS Transaction Server
• Underneath DB2, which stores table spaces and index spaces as linear datasets and its bootstrap dataset as a KSDS
• Batch processing, where sequential and keyed access to large files is still the fastest route

 

IMS: The Hierarchical Database

IMS (Information Management System) is IBM’s hierarchical database and transaction management system. IBM developed it in the late 1960s for NASA’s Apollo program, and it has been in continuous production use ever since.

Where a relational database organizes data into tables of rows and columns, IMS organizes it into an inverted tree. Data is reached by navigating from parent to child down a known path. That makes IMS extremely fast for access patterns you can predict in advance, and awkward for questions nobody anticipated when the database was designed.

IMS DB vs. IMS TM

IMS is the product. It has two major components that often get confused with each other:

• IMS DB (Database Manager) is the hierarchical database itself. It defines the database structure, stores the data, and handles queries and updates against it.
• IMS TM (Transaction Manager) is a message-based transaction manager. It handles message queuing, scheduling, security, formatting, logging, and recovery for the programs that process transactions.

 

A site can run both, or run IMS DB with CICS as the transaction manager instead of IMS TM. Knowing which combination you have matters, because it changes who owns the recovery process.

How Hierarchical Data Is Structured

IMS data is built from three units:

• A field is the smallest unit, equivalent to a single data item.
• A segment is the basic unit IMS reads and writes, made up of related fields.
• A record is a root segment plus every segment beneath it.

 

The relationships are physical. A child segment is reached through its parent, following pointers stored in the database. That is why IMS performs so well on predictable transactions, and why migrating it is hard: the relationships live in the structure itself, not in a schema you can read off.

DB2 for z/OS: The Relational Database

DB2 for z/OS is IBM’s relational database for the IBM Z platform. Data sits in tables of rows and columns and is accessed with SQL, which makes it the most familiar of the three to anyone who has worked with databases off the mainframe.

One note on spelling: IBM has styled the product “Db2” since 2017. Most people still write DB2, and both refer to the same thing.

How DB2 for z/OS Differs From Distributed DB2

DB2 for z/OS and DB2 for Linux, UNIX and Windows (LUW) share a name and a SQL dialect, but they are different products. DB2 for z/OS is built into the IBM Z architecture and engineered alongside the hardware, using z/OS facilities for locking, logging, and workload management. DB2 LUW runs as a standard software process on distributed platforms.

Do not assume DB2 skills transfer cleanly between them. Utilities, tuning, and recovery procedures all differ.

Why DB2 Still Sits on VSAM

DB2 stores its table spaces and index spaces as VSAM linear datasets, and its bootstrap dataset as a VSAM KSDS. VSAM handles the physical I/O while DB2 keeps control of buffering, logging, locking, and recovery above it.

This is why the earlier point matters. If you run DB2, you run VSAM whether you think about it or not.

How to Find Out Which Data Store You Are Running

If nobody can tell you what the system uses, the JCL and the application code will.

Check Your JCL and Dataset Names

Look at the EXEC statements in your batch JCL to see which program is being run:

• IMS: DFSRRC00, the IMS region controller. Batch jobs against IMS databases run through it.
• VSAM: IDCAMS, the Access Method Services utility used to define, copy, and manage VSAM datasets.
• DB2: IKJEFT01, the TSO terminal monitor program, which runs the DSN command processor in batch. DB2 utilities run under DSNUTILB.

 

Look at Your CICS and Batch Programs

The application source tells you how the data is actually reached:

• IMS: EXEC DLI commands, or DL/I calls. In CICS, IMS databases are normally reached through DBCTL.
• VSAM: EXEC CICS READ, WRITE, REWRITE, or DELETE against a file name, with no database subsystem involved.
• DB2: embedded SQL, marked by EXEC SQL.

 

Ask Who Holds the DBA Role

The fastest answer is usually organizational. If someone carries the title of IMS DBA, you run IMS. If your DBAs write SQL and schedule REORGs, you run DB2. If nobody holds a database administrator title and the files belong to application and storage teams, you are almost certainly using VSAM directly, because VSAM has no database engine to administer.

Most Mainframes Run All Three

For most enterprises, the answer is not one of the three. It is all of them.

A typical z/OS site runs DB2 for newer relational applications, IMS for a high-volume core system built decades ago, and VSAM directly for batch files and CICS applications, with still more VSAM sitting underneath DB2. They accumulated over time, each added for a reason that made sense then.

This matters for planning. A migration or recovery plan built around one data store will quietly miss the others.

What Your Data Store Means for Migration

Your data store is usually the hardest part of any mainframe migration strategy. Code can be recompiled or converted. Data has to keep working exactly as it did.

VSAM to DB2 Migration

Moving from VSAM to DB2 means going from files to a relational schema. You gain SQL access, referential integrity enforced by the database, and schema changes that do not require rewriting every program that reads the file.

The work is in the conversion. VSAM files carry no schema, so the record layouts live in COBOL copybooks, and any program logic that depends on physical record order has to be found and reworked. Mainframe data migration is where these projects tend to run long.

IMS to DB2 Migration

IMS to DB2 means converting a hierarchy into relational tables. Organizations take it on to reduce their dependence on specialist skills and to open the data to modern applications.

It is the hardest of the three conversions. Parent-child relationships that IMS enforces through physical pointers have to be re-expressed as keys and joins, and access paths that made IMS fast can perform very differently once the data is relational.

DB2 for z/OS to Cloud

DB2 is the most straightforward starting point, because the data is already relational and already addressed with SQL. The obstacles are usually not the schema. They are everything around it: utilities, recovery procedures, batch windows, and applications written to assume mainframe response times.

What Your Data Store Means for Disaster Recovery

Your recovery position differs sharply by data store, and this is the part that tends to surprise people. DB2 provides point-in-time recovery through its own utilities, using active and archive logs. Recovery is a documented database procedure. IMS recovers through DBRC and its RECON datasets, which track database changes, image copies, and logs. Also a documented procedure, though it calls for IMS-specific expertise.

VSAM on its own has no forward recovery. For datasets defined as recoverable, CICS provides backward recovery, meaning it backs out incomplete transactions. Forward recovery, which reapplies committed changes after a media failure, requires a separate product such as CICS VSAM Recovery or a third-party equivalent. For datasets not defined as recoverable, neither CICS nor VSAM provides forward recovery logging at all.

If you run VSAM files directly and nobody can name your forward recovery tool, that is a gap worth closing before it gets tested. Our guide to mainframe disaster recovery when a legacy system goes down covers what tends to break.

Get a Clear Picture of Your Mainframe Data with BCL

You cannot plan a migration or a recovery strategy around a system you cannot describe. Knowing which data stores you run, what each one holds, and how each one recovers is the foundation for both.

BCL has supported enterprise mainframe environments for more than 40 years across financial services, insurance, healthcare, government, education, and manufacturing. We work in IMS, DB2, and VSAM environments every day, across hosting, disaster recovery, modernization, and re-hosting.

Contact us for an assessment of your mainframe data.