Modernintermediate
Exposing Mainframe Logic as APIs
Understand the common patterns for exposing decades-old CICS/COBOL business logic as modern REST/JSON APIs without necessarily rewriting it.
Most mainframe modernisation is not rewriting COBOL. It is making existing CICS transactions callable over HTTP so that web and mobile front ends can use them.
Exposing a CICS program as a REST API is like adding a modern universal remote to a perfectly reliable old television — you're not replacing the TV's internal electronics (the proven business logic), you're just giving new devices a standard, modern way to control something that already works exactly as it should.
Key Concepts
1
The business logic is thirty years old, correct, and heavily tested. Rewriting it is the risk, not keeping
it.
2
CICS can serve REST directly. A URIMAP resource maps a URL to a program:
3
POST /api/customers/C0004521/balance
-> URIMAP -> CICS program GETBAL
-> JSON in, COMMAREA or container out, JSON back4
CICS handles the JSON conversion from a schema generated against the program's existing data structure. The
COBOL is not modified at all.
5
z/OS Connect is the broader product, sitting in front of CICS, IMS, DB2 and batch, providing one API
gateway with OpenAPI definitions, security and monitoring.
6
What actually needs doing, and it is not the plumbing. The hard part is that a CICS transaction is not
an API, and the differences are real:
7
Granularity. A screen-driven transaction does one step of a conversation. An API caller wants a complete
operation. Several transactions may need composing behind one endpoint.
8
State. A pseudo-conversational flow carries state in a COMMAREA between screens. An HTTP call is
stateless, so the state has to live somewhere — usually the caller, passed each time.
9
Errors. CICS returns abend codes and a message field. An API needs HTTP status codes and a documented
error body. Mapping one to the other is a design task, not a configuration option.
10
Performance changes shape too. A green-screen user makes a request every thirty seconds. A mobile app
with a hundred thousand users makes far more, in bursts, and the sizing of the region and the connection
pool was never done for that.
11
The pattern that works. Expose a small number of coarse, well-designed endpoints that compose the
existing transactions — not one endpoint per transaction, which pushes the mainframe's structure onto every
caller and freezes it there.
12
The argument to make in an interview. The logic is not the problem. It works, it is regulated, and it
has been correct for decades. What it lacks is an interface anything modern can call, and adding that is far
cheaper and far less risky than reimplementing the rules it encodes.
13
What the interviewer is probing.1. "How do you expose an existing COBOL program as an API?" Probing: the practical approach.
Stalls: "Rewrite it." Moves up: front it with z/OS Connect or a CICS web service, mapping the
COMMAREA or channel to JSON without changing the program.
14
2. "What is the main design risk?" Probing: the engineering judgement. Stalls:
"Performance." Moves up: exposing an internal record layout as the API contract, which couples
every consumer to the copybook forever.
15
3. "What about transaction semantics?" Probing: the depth. Stalls: "They are the same."
Moves up: an HTTP caller has no two-phase commit, so the API must define idempotency and
compensation rather than assuming a shared unit of work.
16
4. "What is the capacity concern?" Probing: the commercial reality. Stalls: "None." *Moves
up:* API traffic is unpredictable where batch and terminal load were not, and mainframe CPU is
billed — so rate limiting and caching matter.