Table of Contents
- Overview
- What your application becomes
- How it runs (the big picture)
- What stays the same — and what changes
- What you configure
- Where to go next
- Summary
- Related articles
Audience: anyone new to a PL/I application migrated to Java with Heirloom — operations, developers, and technical decision-makers. A good first read.
Overview
Heirloom moves your mainframe PL/I application onto standard Java infrastructure while keeping its behavior the same. Your programs are translated into Java, compiled to ordinary Java bytecode, and run on a normal Java Virtual Machine (JVM) and application server — no mainframe, no emulator, and no rewrite of your business logic.
This article explains, at a high level, what your application becomes after migration and how it runs, so the more detailed "How to" guides make sense.
Note: Example names used in the other articles (queues, programs, transaction ids, connection strings) are illustrative. Your application keeps your names and your logic.
What your application becomes
| Before (mainframe) | After (Heirloom) |
|---|---|
| PL/I source | Translated to Java source, then compiled to standard Java bytecode |
| Runs in a mainframe region | Runs as a Java web application on a standard application server |
| CICS transactions | Same transactions, dispatched by the runtime; EXEC CICS preserved |
| BMS 3270 screens | Same screens, rendered to a terminal/web front end |
| DB2 via embedded SQL | Same EXEC SQL, executed over standard JDBC |
| IBM MQ messaging | Same MQI calls, connected to a real queue manager |
| VSAM / sequential files | Same file operations, mapped to backing stores |
The key point: your source behavior is preserved. Data types (DECIMAL, PICTURE, BINARY, BIT, CHARACTER, POINTER, AREA), arithmetic, string handling, and PL/I ON-conditions all behave as they did on the host — down to the byte layout of your records.
How it runs (the big picture)
- Your PL/I is translated to Java by the Heirloom compiler — one Java program per PL/I program.
- The Java is compiled with a Heirloom compiler plug-in that wires your programs to the runtime library (the component that provides PL/I data types, storage, built-in functions, and the CICS/MQ/SQL bridges).
- The result is packaged as a standard web application (WAR) and deployed to a Java application server, commonly inside a container.
- At run time, the application connects to your database (DB2), IBM MQ, and files using ordinary, configurable connections.
PL/I source ──translate──▶ Java ──compile──▶ Java app (WAR)
│
▼
Application server (JVM) ──┬─▶ DB2 (JDBC)
├─▶ IBM MQ
├─▶ Files / datasets
└─▶ Terminal / web front end (BMS screens)
Because the output is ordinary Java, you operate it with standard tooling: JVM options, application-server administration, container orchestration, and normal Java monitoring and logging.
What stays the same — and what changes
Stays the same
- Your business logic and program structure.
- Your
EXEC CICS,EXEC SQL, and MQ calls, BMS maps, and file definitions. - Transaction integrity: commit/rollback and syncpoint still apply, so database and message work is all-or-nothing within a unit of work.
- The exact data representation of your records.
Changes (operational, not logical)
- Where it runs: a JVM and application server instead of a mainframe region.
- How you connect to resources: standard, configurable connections (database URL, queue-manager coordinates, file locations) instead of mainframe definitions.
- How you operate it: Java/cloud-native tooling for deployment, scaling, and monitoring.
What you configure
Most of what you provide at deployment is connection and inventory configuration, not code:
-
Database: a JDBC connection (or datasource) for your
EXEC SQLprograms. - IBM MQ: queue-manager coordinates (queue manager, host/port, channel, credentials) and queue names.
- Application inventory: which programs and transactions exist, your files and their attributes, and any programs that start automatically.
- Runtime options: optional JVM settings for diagnostics and compatibility.
The companion "How to" articles cover each of these in detail.
Where to go next
- Run a transaction application → How to Configure and Deploy a Migrated CICS Application.
- Connect to your database → How to Configure DB2 / SQL Connectivity.
- Messaging → How to Use IBM MQ Messaging.
- Tuning & diagnostics → JVM Options & Runtime Configuration.
- Understand behavior → How the PL/I Runtime Manages Memory and How Transactions Are Managed.
Summary
- Your PL/I becomes a standard Java application — compiled, not emulated — and runs on a normal JVM and application server.
- Behavior is preserved: data types, arithmetic, conditions, record layouts, and your CICS / SQL / MQ / BMS surface.
- What changes is operational: where it runs and how it connects, both managed with standard Java tooling and simple configuration.
0 Comments