Start Here · Mainframes in Plain English

How to read this course

Words that might be unfamiliar are underlined with dots. Hover over one — or tap it on a phone — and a one-sentence explanation appears. You never have to leave the page to look something up.

Boxes like this one appear throughout. They restate the idea just explained, without any jargon at all. If a section loses you, skip to its plain box, then come back.

What a mainframe actually is

Start by throwing away the picture in your head. A mainframe is not an old computer. It is not slow. It is not a museum piece kept alive by nostalgia.

The common assumption

"A big old machine from the 1970s that companies are too scared to switch off. Underpowered, obsolete, waiting to be replaced by the cloud."

What it really is

A current-generation computer, sold new today, designed around one goal: never stop, and never lose a transaction. Built for enormous volumes of small, reliable operations rather than raw calculation speed.

A useful comparison. A cloud server is designed on the assumption that it will fail, so you run many of them and route around the dead ones. A mainframe is designed on the assumption that it must not fail, so the redundancy is inside the box: duplicated processors that check each other's arithmetic, memory that repairs itself, components you can replace while it runs.

The result is a machine that a large bank will happily run for years without a full outage, processing thousands of transactions per second, every one of them guaranteed either to complete fully or not at all.

Picture it

Cloud computing is a fleet of delivery vans. If one breaks down you send another; nobody notices.

A mainframe is the freight train. Slower to redirect, far more expensive to buy, and it moves an amount of cargo per hour that would need a very large number of vans — reliably, on a schedule, for thirty years.

Why they are still here

Not inertia. Four concrete reasons:

The work suits the machine. Card payments, insurance claims, airline bookings and payroll are all huge numbers of small, transactional operations. That is exactly what the hardware is tuned for.
The software works. A claims system written in 1988 and refined for thirty-five years encodes an enormous amount of hard-won business rule. Rewriting it means rediscovering all of it.
Compatibility is taken seriously. Programs compiled decades ago still run on hardware sold this year. Very little else in computing offers that.
The risk maths. If the system that moves money works, "replace it with something modern" is a proposal to trade a working thing for a possibly-working thing. That is a hard sell.

The two ways programs run

Almost everything on a mainframe is one of two shapes. You need both words.

Online transactions

Someone — or some system — asks for something and waits for the answer. A cashier swipes a card, a call centre agent looks up a policy, an app calls an API. Small, fast, thousands per second.

The equivalent of a web request hitting your API.

Batch jobs

A program that runs unattended from start to finish, usually overnight. Read a huge file, update millions of records, produce reports, go home. Nobody is watching it.

The equivalent of a nightly cron job or a scheduled data pipeline.

In plain English

Online = someone is waiting. Batch = nobody is waiting.

This distinction matters more than it sounds. Later in the course you will meet a batch job that changes millions of records without writing anything to the database's change log — which means a system copying that data elsewhere never finds out. That is the kind of problem this course is really about.

The one picture to hold: the warehouse

Everything in this course gets easier if you carry one physical image. Here it is, and the rest of the course keeps coming back to it.

Imagine a warehouse full of numbered shelves.

Hold this picture. Nine of the ten modules are about some detail of this warehouse: how shelves are numbered, how you decide which shelf a card goes on, what happens when a shelf fills up, and what the string costs you when you add or remove a card.

A numbered shelfpage

A fixed-size block of storage, about 4 KB. The unit the machine reads and writes. Reading one shelf is one disk operation — so "how many shelves did that touch?" is the performance question in this whole course.

A numbered slotline

A position on a shelf where one card sits.

Shelf + slotdb-key

The exact physical address of a card — "shelf 71003, slot 1". Fast to jump to. Changes if the warehouse is ever reorganised, which is why it must never become a permanent business identifier.

An index cardrecord

One stored item of data. The equivalent of a row in a table.

A labelled loop of stringset

A parent-child relationship, stored as real addresses written on the cards themselves. Follow the string and you reach the next child, then the next, then back to the parent.

A room in the warehousearea

A named block of shelves. It is what gets locked, backed up and restored as a unit.

Your finger in the card filecurrency

Where you are currently positioned. The database remembers this for you — and it remembers four different positions at once, which is the single biggest source of bugs in these systems.

A diary of every changejournal

Before any card is altered, the change is written to a log. This is what makes crash recovery possible — and it is also the thing replication software reads. If a change never reaches the diary, no copy of the data will ever hear about it.

The one real difference from a normal database

If you know PostgreSQL, MySQL or SQL Server, you already know how relationships usually work. You store a value in one table, store the same value in another, and the database matches them up when you ask.

how you are used to relationships working

employee table                  department table
+--------+---------+------+     +---------+---------------------+
| emp_id | name    | dept |     | dept_id | name                |
+--------+---------+------+     +---------+---------------------+
| 0028   | ARAKI   | 3200 | --> | 3200    | INTERNAL SOFTWARE   |
| 0031   | ELLIS   | 3200 | --> | 3200    |                     |
+--------+---------+------+     +---------+---------------------+
                     ^
                     |
        the link is a VALUE. The database
        finds the match by comparing 3200 to 3200.

IDMS does not do that. The link is not a value to be matched. It is a stored address, written invisibly onto the card itself, pointing at exactly where the related card physically sits.

how IDMS does it

card at shelf 75020 slot 1  (DEPARTMENT 3200)
   hidden on the card: "first child is at 71003:1"

card at shelf 71003 slot 1  (EMPLOYEE ARAKI)
   hidden on the card: "next child is at 71006:1"
                       "my parent is at 75020:1"

card at shelf 71006 slot 1  (EMPLOYEE ELLIS)
   hidden on the card: "next is back to the parent, 75020:1"
                       "my parent is at 75020:1"

        the link is an ADDRESS. Nothing is compared.
        You just go where the card tells you to go.

In plain English

A normal database works out relationships by matching values when you ask. IDMS already knows them, because the answer is physically written down.

That makes following a known relationship extremely fast. It also means the relationship is a real, physical thing that has to be maintained — and it means a record can be related to its parent while containing no data anywhere in it that says so. That last point causes most of the difficulty when copying this data to a normal database, and Module 02 goes into it properly.

If you know pointers

This is exactly the difference between a hash-join over two arrays and a doubly-linked list. Relational databases join; IDMS traverses. One is flexible and needs a query planner. The other is fast along the paths someone designed in advance, and has no way at all to answer a question nobody planned for.

Five consequences, one sentence each

Everything that feels strange about IDMS follows from that single design decision. Here is the whole list. Each of these becomes a module.

You write the route, not the question.
There is no query planner deciding how to get your data. The program says "go to this card, follow this string, read the next one" — so the access plan is the source code. (Modules 05 and 06.)
Physical layout is part of the design, not an implementation detail.
Which shelf a card lands on is declared in the database definition and visible to programmers. Getting it right is the difference between reading 3 shelves and reading 30. (Module 03.)
The database remembers where you are — four times over.
It tracks your position by record type, by relationship, by storage area, and overall. Move one and you silently move others. This is where the bugs live. (Module 05.)
There is no concept of "no value".
No NULL. Fifty years of programs have used spaces, zeros, or a date of 00000000 to mean "unknown" — and you have to find out which, per field, before copying anything. (Modules 07 and 09.)
The numbers are not stored the way you expect.
Text is in a different character encoding. Numbers are packed two digits per byte. A negative number can arrive looking like a typo. All of it converts silently and wrongly if you get it slightly off. (Module 09.)

So what is CA IDMS, exactly?

It is the database product built on the design above. Short history, because the names come up constantly:

Built in 1973. The design style it follows was standardised in 1971 by a committee called CODASYL — the same group that standardised COBOL.
Sold by Cullinane, then Cullinet, then Computer Associates from 1989, and owned by Broadcom today. That is why you see it called both "CA IDMS" and just "IDMS".
It runs on IBM mainframe operating systems, and there are banks, insurers, governments and railways running it right now.

Two corrections worth making early

It is not a hierarchy. A card can have several parents of different kinds. That makes it a network — a graph — not a tree.

It is not a primitive file system. It has proper transactions, crash recovery, locking and deadlock detection, and has had them since before most modern databases existed.

Why you specifically are here

You are heading into a project that copies data out of one of these systems into something modern — a cloud warehouse, PostgreSQL, a streaming platform. The tool doing the copying is Rocket Data Replicate and Sync.

The tool is not the hard part. The hard part is that the warehouse and the destination think about data differently, and every difference is a decision somebody has to make:

What the whole project is actually made of
In the warehouse	In your target database	The decision
A card with no unique number on it	A table needs a primary key	What identifies this row, if nothing in it is unique?
A string tying cards together	A foreign key column	Can it be empty? The source already answers this — copy its answer.
Cards in a deliberate order on the string	Rows have no inherent order	Was the order carrying meaning? If so it must become a column.
A date of `00000000`	`NULL`, or a real date	Does that mean "unknown", or something specific? Ask the business.
A change diary read continuously	Rows appearing in near real time	What happens when the diary is thrown away before you read it?

The honest summary of this course

Ten modules explaining how the warehouse works, so that when one of those decisions lands on your desk you can make it on evidence instead of guessing — and so that when the copy silently stops matching, you know where to look.

Vocabulary translator

Every term used in this course, with a plain explanation. Search it whenever something reads as noise. It is also always available at the glossary.

What to do next

Read Module 01 next.
It puts names to the machinery: what process actually holds the database, and how a program talks to it.
Do the modules in order the first time.
Each one uses the previous one. Module 10 — the replication module — assumes all nine before it.
Use the simulators.
They are not decoration. The one in Module 05 is a real, working database interpreter. You will understand "the database remembers four positions at once" in about ninety seconds of using it, and probably never from reading about it.
Do not memorise the vocabulary.
Hover over anything unfamiliar. The words stick by use, not by study.