A4IT
Services / Mainframe modernisation
05 / 08
Mainframe modernisation · COBOL, DB2, JCL, CICS and IMS

Know what the mainframe does. Then move it, piece by piece.

A4IT reads COBOL, DB2, JCL, CICS and IMS applications, writes down what they really do and moves them to Java or .NET on PostgreSQL or SQL Server, one function at a time. Reverse engineering comes first: an inventory, the data flows and the business rules, in documents your own people can check. The old system keeps running until the new one gives the same results. You work directly with Tim De Smedt, without middlemen.

Discuss your system → What we deliver How an engagement runs

What you get, what stays yours, where it stops

Said before the first meeting
You get
  • An inventory of programs, jobs, copybooks, tables and files, with what calls what
  • Business rules in plain language, each traced to the code it comes from
  • A migration plan in steps, each with its own scope, estimate and way back
  • New code in version control, with tests that compare old and new results
Stays yours
  • The source code, old and new, and every document we write
  • Your data and your environments: we work with the access you grant
  • The decision per component: keep, wrap, rewrite or retire
  • The freedom to continue with your own team or another supplier
Boundaries
  • No big-bang switch: old and new run side by side until results match
  • No machine-converted code handed over as the result: every program is read and tested
  • No mainframe operations or systems programming
  • No promised saving or end date before the inventory is done

What we deliver

Seven building blocks · take one or all
01 · Understand

Inventory and assessment

Before anything moves: what is there, what is still used and what depends on what.

Programs and jobs
COBOL programs, copybooks, JCL jobs and procedures, CICS transactions and IMS components, listed with their size and last change.
Dependencies
Which program calls which, which job runs after which, and which tables and files each of them reads or writes.
Dead and duplicate code
Programs that no job or transaction starts any more, and copies that drifted apart. What is not used does not have to be migrated.
Risk and effort
A written view per component: keep, wrap, rewrite or retire, with the reasons and a rough size.
02 · Understand

Reverse engineering and documentation

The knowledge is in the code and in a few heads. We put it on paper while both are still available.

Business rules
Calculations, validations and exceptions taken from the code and written in plain language, with a reference to the program and paragraph.
Data model
DB2 tables, VSAM files and copybook record layouts described as one data model, including the fields whose meaning changed over the years.
Batch flows
JCL job streams drawn as flows: what starts when, with which input, producing which output, and what happens when a step fails.
Checked with your people
Each document is reviewed by someone who knows the business. Where code and memory disagree, that is recorded and decided.
03 · Understand

AI-assisted analysis

Language models read COBOL faster than people do. They also get it wrong, so every result is checked against the code.

Explaining programs
A model summarises what a program or paragraph does, as a first draft for the analyst. See AI consulting.
Finding rules and links
Where a field is set, a rule is applied or a table is updated, searched across the whole code base instead of one program at a time.
Checked by a person
Nothing a model produces enters the documentation or the new code without a review and a test.
Your code stays where you decide
A local model or a service you approved, chosen with you. The analysis can also be done without language models.
04 · Connect

Interfaces around the mainframe

Often the first step is not to replace anything, but to let new software reach what is there.

APIs in front of transactions
A REST API in front of existing CICS or IMS transactions, so a web application or a partner can use them without a terminal screen.
File exchange
Sequential files and VSAM extracts converted reliably: EBCDIC, packed decimals and fixed-length records into formats other systems read.
DB2 access
Read access to DB2 for reporting and new applications, or a copy kept in step where the mainframe must not carry extra load. See automation & data.
Described and versioned
Every interface has an OpenAPI contract or a file specification under version control, so nobody has to read a copybook to use it.
05 · Modernise

Rewrite to Java or .NET

One function at a time moves to a platform that developers are easy to find for. See software development.

Rewritten, not transliterated
The new code is designed from the documented rules, in ordinary Java or C#. Not COBOL line by line in another syntax.
Batch
JCL job streams become scheduled batch jobs on Spring Boot or .NET that can be restarted and report the same control totals.
Online
CICS and IMS screens become web screens or APIs on Spring Boot or ASP.NET Core. Keyboard operation stays for the users who are fast with it.
Order of work
We start with a part that has clear boundaries and low risk. Each step goes to production before the next one starts.
06 · Migrate

DB2 and data migration

From DB2 to PostgreSQL or SQL Server, with proof that nothing was lost or silently changed.

Schema
Tables, keys, indexes and constraints mapped to the target database in versioned migrations. Decimal precision, dates and character sets are decided explicitly.
Embedded SQL
The SQL inside the COBOL programs and the stored procedures is listed and rewritten for the target database, DB2-specific constructs included.
VSAM and files
Files that serve as a database become proper tables. Record layouts with REDEFINES and OCCURS are unpacked into a clear structure.
Trial runs and reconciliation
Repeated full migrations on a copy, with row counts and totals compared, until the real one is routine.
07 · Prove

Parallel run and cut-over

A migration is finished when the new system gives the same answers, not when the code compiles.

Results compared
The same input goes through old and new. Output files and table contents are compared automatically; every difference is explained or fixed.
Parallel run
Old and new run side by side for an agreed period, including a period closing where the application has one.
Cut-over with a way back
A written cut-over plan with a rehearsal, a decision moment and a route back to the old system.
Switching off
A component is retired only when nothing calls it any more. Its programs, jobs and data are archived as agreed.

How an engagement runs

Small steps · a decision after each
  1. Intake
    A call of thirty minutes: your system, your reason to change, your constraints.
    30 minutes
  2. Inventory
    Programs, jobs and data listed, with dependencies, risks and a plan in steps.
    Inventory + plan
  3. Reverse engineering
    Rules, data model and flows documented and checked with your people.
    Written documentation
  4. Migrate in steps
    One function at a time, each compared against the results of the old system.
    Parallel run
  5. Cut-over and retire
    Switch with a way back, then switch off the old part.
    In production

Technology

Chosen per case · nothing is mandatory
MainframeCOBOL, JCL, CICS, IMS
DataDB2, VSAM, sequential files, copybooks
TargetJava, Spring Boot, .NET Core, C#, PostgreSQL, SQL Server
InterfacesREST APIs, OpenAPI, XML & XSLT, file exchange
AnalysisLanguage models (local or approved service), BPMN, Confluence
DeliveryGit, Jenkins, JIRA, automated comparison tests

Good fit, and not a fit

Saves both of us a meeting
A good fit when
  • A COBOL application still runs the business and the people who know it are leaving
  • Nobody can say with confidence what the system does in every case
  • You want to leave the mainframe in steps, or open it up first
  • Someone who knows the business can review documents and answer questions
Not a fit when
  • Everything must be replaced in one weekend
  • The source code is gone and only compiled programs remain
  • You are looking for a tool that converts everything automatically
  • You need mainframe operations, or a large team on site next week

Questions about mainframe modernisation

All questions →
01Do we have to leave the mainframe?

No. Sometimes documenting the system and putting interfaces around it is the right result. The inventory shows what is worth moving; the decision is yours, per component.

02How long does a migration take?

That depends on the size, on how the parts depend on each other and on how much time your people have to review. After the inventory you get a plan in steps with an estimate per step. We name no duration before that.

03Do you use automatic code converters?

Tools help with the inventory and the analysis. The new code is written by developers from the documented rules, because converted code tends to be COBOL in another syntax that nobody wants to maintain.

04Is our source code sent to an AI service?

Only if you approve it. The analysis can run on a local model, on a service you approved, or without language models at all. See AI consulting.

05Our COBOL people retire soon. What comes first?

Reverse engineering, while they can still check the result. Documentation they have reviewed is worth more than any reconstruction afterwards.

06Who does the work, and how do we follow it?

Tim De Smedt and the core development team, directly. You follow it through the documents, regular demos and an issue list you can open at any time. See how we work and project management & analysis.

Tell us what runs on your mainframe. We will tell you where we would start.

Reply within three business days.Discuss your system →How we work