Refactoring COBOL safely and COBOL-to-Java risks

Tests come first

Old programs rarely have automated tests, and their specification is often out of date. Before changing anything, write characterization tests: tests that record what the program does now, including odd behaviour, rather than what someone thinks it should do. If a refactor changes an output, the test fails and you investigate before production finds it.

• Unit level: frameworks such as zUnit can stub file, DB2 and CICS calls so one program can be tested alone.
• Batch level: run the job with a fixed input and compare output files byte for byte with a saved baseline.
• Online level: replay recorded transactions in a test region and compare responses.

Modularising

Many critical programs are thousands of lines long with deeply nested logic. Safe steps, each followed by a test run:

1. Give paragraphs meaningful names and remove GO TO jumps where the flow can be expressed with PERFORM.
2. Move repeated record layouts into shared copybooks so every program uses the same definition.
3. Extract a well-bounded piece of logic, such as interest calculation, into a separate subprogram that is CALLed with a clear LINKAGE SECTION interface.
4. Separate business logic from input and output, so the same rule can be called from batch, CICS or an API.

Removing dead code

Dead code is code that can never run, or that no longer has any caller. It costs effort every time someone reads, tests or converts it. Static analysis can show paragraphs with no path to them and programs with no caller. But dynamic calls (a program name held in a variable), scheduler definitions and rarely-run jobs can hide real use, so confirm with runtime evidence collected over a full business cycle, including month-end and year-end, before deleting.

Program  ACCT0400   Lines 6,812
  Paragraphs never referenced ....... 23
  Copybooks included, unused ........ 4
  Dynamic CALL targets (unresolved) . 2   (WS-PGM-NAME)
  Last executed (runtime data) ...... month-end only

The two unresolved dynamic calls above are the warning sign: until you know which program names reach WS-PGM-NAME, you cannot say the candidates are really dead.

COBOL-to-Java: concepts

Conversion approaches range from automated line-by-line translation (fast, but the result often reads like COBOL written in Java) to re-engineering a function in idiomatic Java using the COBOL as a reference. Several vendors offer conversion tooling, and AI-assisted tools (for example IBM watsonx Code Assistant for Z) can suggest Java for selected services. All of them need human review and full regression testing. Java can also run on z/OS itself, close to the data, where it is eligible to run on zIIP processors.