Some technologies return to our attention in a strange way.

Not because they are fashionable.
Not because every conference talks about them.
Not because young developers list them as their dream stack.

They return because they are still running somewhere important.

COBOL is exactly that kind of technology.

For decades, people have called it old, outdated or even dead. Yet many banking, insurance, accounting, government and enterprise systems still depend on COBOL programs or on environments where COBOL-style thinking remains relevant.

In those systems, fashion is not the point.

Accuracy is the point.
Stable data processing is the point.
Reports, batches, reconciliation, auditability and business continuity are the point.

That is why I started asking myself a simple question:

What if I refreshed COBOL after all these years?

Not as nostalgia. Not as an attempt to live in the past. More as a practical question: is there still value in combining programming experience, accounting logic, patience with long reports and an understanding of legacy business systems?

Why COBOL Interests Me Again

As a junior programmer in the years 1994-1996, I worked in an environment where business reports, batches, accounting data and older enterprise systems were part of everyday work.

At that time, development was not about polished web interfaces or cloud dashboards.

A lot of work was about:

  • reports,
  • printed output,
  • files,
  • account numbers,
  • balances,
  • monthly processing,
  • year-end processing,
  • errors hidden in long listings,
  • and finding out why totals did not match.

That is very close to the world where COBOL has historically been strong.

COBOL is not a language that impresses through elegant modern syntax. It was designed for business data processing. It belongs to a world of records, files, calculations, reports and procedures that must be correct.

In such systems, knowing syntax is not enough.

You must understand what the data means.

A difference of 0.01 EUR is not a detail.
A batch executed twice is not a small inconvenience.
A wrong control total is not just a cosmetic error.
An account balance that does not reconcile may represent a real operational or financial problem.

This is what makes the topic interesting to me: the meeting point between programming, accounting discipline and older enterprise systems.

COBOL as a Legacy Financial Niche

When people discuss programming today, most attention goes to JavaScript, Python, cloud platforms, AI tools, DevOps, frontend frameworks or mobile applications.

COBOL belongs to a different category.

It is a legacy financial and enterprise niche.

Typical domains where COBOL, mainframe systems or related legacy technologies still appear include:

  • banking,
  • insurance,
  • pension systems,
  • government benefit systems,
  • payroll,
  • invoicing,
  • accounting,
  • leasing,
  • payment processing,
  • clearing,
  • monthly and annual closing,
  • older ERP systems,
  • batch processing and reporting.

From a career perspective, this is interesting because it is not a mass market.

There are not many COBOL programmers. Younger developers often prefer newer technologies. At the same time, many organizations still need to maintain systems that cannot simply be rewritten because they are critical, complex and deeply connected to business processes.

The financial value is usually not in knowing COBOL keywords alone.

The value is in understanding what the system does:

  • why a report exists,
  • what a balance means,
  • why a control total matters,
  • how a batch changes business data,
  • what may happen if processing is repeated,
  • and how to change legacy code without breaking production.

That is where accounting experience and patience with old reports can become an advantage.

My Advantage Is Not Only Programming

If I said today:

I want to learn COBOL from zero.

that would not sound very strong.

A more accurate statement would be:

I have historical exposure to AS/400-style business environments, experience with accounting reports, a programming background and a current interest in refreshing COBOL, IBM i, mainframe concepts and financial batch processing.

That is a different profile.

It does not claim that I am currently a senior mainframe COBOL specialist. That would not be honest. But it does describe a realistic path:

  • historical exposure,
  • accounting-oriented thinking,
  • patience with reports,
  • software development experience,
  • interest in legacy business logic,
  • and willingness to refresh older enterprise technologies systematically.

In legacy systems, it is valuable to understand why a system was built the way it was.

Not everything should be replaced just because a newer framework exists. Sometimes the most important work is to understand the existing logic, document it, test it, wrap it, migrate it carefully or keep it running safely.

COBOL Today Is Not Only COBOL

If someone wants to work with COBOL systems seriously, the language itself is only one part of the picture.

COBOL often lives inside a larger operating and business environment.

In the IBM mainframe world, related topics may include:

  • COBOL,
  • JCL,
  • DB2,
  • CICS,
  • VSAM,
  • z/OS,
  • batch jobs,
  • return codes,
  • datasets,
  • spool output,
  • production schedules,
  • incident analysis.

In the IBM i / AS/400 world, the surrounding concepts may include:

  • IBM i,
  • historical AS/400 environments,
  • RPG,
  • COBOL,
  • CL,
  • DB2 for i,
  • 5250 terminals,
  • libraries,
  • objects,
  • spool files,
  • and older business applications.

So the real question is not only:

Can I write COBOL syntax?

The better question is:

Can I understand the environment, the data flow, the batch, the report, the business rule and the operational risk?

That is where legacy programming becomes domain work, not just language work.

Where Can Someone Try COBOL Today?

The practical question is simple:

Can COBOL still be tried at home?

Yes. But it is important to separate language practice from real enterprise-platform experience.

Option 1: Local Practice with GnuCOBOL

The simplest practical path is GnuCOBOL.

GnuCOBOL is an open-source COBOL compiler. It is not IBM z/OS and it is not IBM i, but it is a very useful way to refresh COBOL syntax, record structures, files and batch-style thinking.

With GnuCOBOL, it is possible to practice:

  • reading input files,
  • fixed-width records,
  • CSV-like processing,
  • VAT calculations,
  • subtotals,
  • control totals,
  • error reports,
  • sorted reports,
  • and simple accounting-style batches.

For Windows, a practical installation route is GnuCOBOL through MSYS2. It is not a replacement for mainframe or IBM i experience, but it is enough to answer the first question:

Do I still enjoy this kind of programming?

That is a useful question before going deeper.

Option 2: IBM Z Xplore and Mainframe Learning

For the IBM mainframe side, IBM Z Xplore is one of the more accessible learning paths.

It helps introduce the way mainframe environments work: commands, datasets, jobs and the operational mindset around them.

This matters because mainframe work is not only about writing code. It is also about understanding:

  • where the data lives,
  • how a job is submitted,
  • what a return code means,
  • how output is inspected,
  • where an error appears,
  • what can safely be changed,
  • and what should never be changed directly in production.

That operating discipline is part of the value.

Option 3: Open Mainframe Project COBOL Materials

The Open Mainframe Project also provides COBOL learning materials, including a COBOL programming course.

Structured materials like this are useful because they connect the language with the mainframe context instead of presenting COBOL only as a historical curiosity.

For a refresh path, this is better than jumping between random examples.

A structured course can help rebuild the basics:

  • divisions,
  • data definitions,
  • file handling,
  • procedural flow,
  • and simple business-processing tasks.

Option 4: IBM i / AS/400 Direction

Because my older experience touched the AS/400 type of world, IBM i is also relevant.

This path is different from ordinary local development. You do not usually install a real IBM i environment on a laptop like a Python or PHP project. Access typically requires a community system, a cloud/trial environment or a real company environment.

For IBM i, it is useful to understand at least the basics of:

  • 5250 terminal work,
  • libraries,
  • objects,
  • DB2 for i,
  • CL,
  • RPG,
  • COBOL,
  • spool files,
  • and batch-style business processing.

COBOL may be only one part of this ecosystem. In IBM i environments, RPG and CL can be just as important.

What I Would Build First

If I refresh COBOL seriously, I do not want to stop at a simple “Hello, world” program.

That proves only that the compiler works.

A better first project would be a small financial batch application.

For example:

A COBOL program that reads an invoice input file, validates records, calculates VAT, produces a summary report and writes a separate error report.

Such a mini project could include:

  • invoice number,
  • date,
  • customer or account code,
  • net amount,
  • VAT rate,
  • VAT amount,
  • gross amount,
  • validation of invalid rows,
  • subtotals by VAT rate,
  • grand totals,
  • an error file,
  • and a final printable report.

That is much closer to the real spirit of COBOL than a toy example.

It would also show whether I still have the patience for fixed structures, exact data handling and report-oriented programming.

A Practical Refresh Plan

My refresh plan would be deliberately modest and practical.

Step 1: Restore the Language Basics

I would start with the core structure:

  • IDENTIFICATION DIVISION,
  • ENVIRONMENT DIVISION,
  • DATA DIVISION,
  • PROCEDURE DIVISION,
  • WORKING-STORAGE SECTION,
  • FILE SECTION,
  • PIC definitions,
  • MOVE,
  • IF,
  • EVALUATE,
  • PERFORM,
  • READ,
  • WRITE,
  • COMPUTE.

The goal would not be to memorize everything immediately.

The goal would be to make the language feel readable again.

Step 2: Practice Files and Reports

COBOL makes most sense when data and reports are involved.

So I would focus on:

  • input files,
  • fixed-width structures,
  • record validation,
  • calculations,
  • output reports,
  • error reports,
  • and control totals.

That is also where accounting thinking becomes useful.

Step 3: Create a Small Portfolio Project

A project such as COBOL Accounting Batch Report would be a good small portfolio item.

The README could explain:

  • input structure,
  • business rules,
  • validation rules,
  • accounting checks,
  • expected output,
  • control totals,
  • and known limitations.

This would demonstrate more than syntax. It would demonstrate legacy business-data thinking.

Step 4: Learn the Surrounding Platform

If the local refresh still feels interesting, the next step would be platform context.

For the mainframe direction:

  • JCL basics,
  • datasets,
  • job submission,
  • return codes,
  • DB2 concepts,
  • and CICS at least conceptually.

For the IBM i direction:

  • 5250 terminal work,
  • CL,
  • DB2 for i,
  • libraries and objects,
  • spool files,
  • and RPG orientation.

This matters because job descriptions rarely ask for COBOL alone. They often ask for the ecosystem around it.

What Are the Realistic Options Today?

I would divide the possibilities into several realistic paths.

Option A: COBOL as a Personal Refresh

This is the lowest-risk option.

Refreshing COBOL can be a useful mental exercise even if it never becomes a job or contract.

It trains a different kind of programming discipline:

  • structured data,
  • careful calculation,
  • reports,
  • deterministic output,
  • and respect for business rules.

That is still valuable.

Option B: COBOL as a Supporting Specialization

This is the most interesting option for me.

Not to abandon everything else and become only a COBOL programmer, but to add a legacy-financial layer to my profile:

  • legacy financial systems,
  • COBOL refresh,
  • IBM i / AS/400 historical exposure,
  • accounting reports,
  • batch processing,
  • data reconciliation,
  • support and modernization.

That can be useful for organizations dealing with old systems, migrations, reporting problems or integration work.

Option C: A Bridge Between Business and Legacy IT

This may be even more realistic than pure programming.

Many legacy projects do not fail because nobody can write code. They fail because the organization no longer fully understands what the old code does.

A useful role may involve understanding:

  • what a legacy system calculates,
  • which reports are critical,
  • where reconciliation happens,
  • how data moves between systems,
  • what a mismatch means,
  • and how to modernize without losing business meaning.

That is a bridge role between business, accounting and IT.

Option D: Legacy Modernization and Verification

Many companies do not want to throw COBOL away immediately.

They need to:

  • document old logic,
  • identify dependencies,
  • expose interfaces,
  • migrate data,
  • compare old and new outputs,
  • run parallel processing,
  • and prove that the new system still produces correct results.

COBOL knowledge helps here even if the final target system is modern.

The ability to read the old logic can reduce modernization risk.

What I Should Not Pretend

It is important to be realistic.

COBOL is not an easy shortcut to money. The market is narrower. Many roles require real mainframe or IBM i exposure. Junior opportunities are limited. Onboarding can be slow. Documentation may be incomplete. Reading old code and investigating production batches is not for everyone.

It would also be wrong to claim that a local GnuCOBOL project is the same as real z/OS or IBM i experience.

It is not.

But it can be an excellent first step:

  • refresh the language,
  • test whether the work style still fits,
  • build a small proof of capability,
  • understand job requirements better,
  • and prepare for deeper IBM i or mainframe learning.

How I Would Position It Professionally

I would not describe this path as:

Looking for a junior COBOL position.

That would not capture the real value.

A better positioning would be:

Senior developer with accounting experience and historical AS/400 exposure. Focused on financial reports, batch processing, data controls and legacy-system support. Currently refreshing COBOL, IBM i, DB2 and related enterprise technologies.

That is honest.

It does not overclaim current mainframe expertise. But it does show a combination that may be useful: software development, accounting logic, patience with legacy data and willingness to work in systems where correctness matters more than trends.

Why This Is Interesting Now

Modern software development moves very fast.

Frameworks change. Cloud platforms evolve. AI coding tools are changing the way we write software. The industry often rewards speed, novelty and automation.

The COBOL world is almost the opposite.

It rewards continuity, caution, exactness, testing, operational discipline and respect for old business logic.

That contrast is part of the attraction.

Revisiting COBOL is not a rejection of modern software. It is a way to add another layer of understanding: how older systems preserve business processes, how financial data survives decades of change, and why modernization must be careful.

Conclusion

My plan is not dramatic.

I do not want to claim overnight that I am a COBOL or mainframe expert. I want to reopen this world systematically.

First, I would refresh COBOL locally with GnuCOBOL. Then I would build a small accounting-style batch project. After that, I would explore IBM Z Xplore, Open Mainframe Project materials and, depending on interest, IBM i / AS/400-related learning paths.

If the topic still feels right, it could become a useful supporting specialization:

Legacy financial systems, COBOL refresh, IBM i/mainframe orientation, accounting reports, batch processing and safe modernization of older applications.

And if it does not become a commercial path, it will still be a valuable return to a very disciplined kind of programming:

Read the data.
Understand the rule.
Calculate exactly.
Respect the system that still runs the business.

COBOL may not be modern.

But perhaps that is exactly why it is worth looking at again.

References

[1] GnuCOBOL, GNU Project: https://gnucobol.sourceforge.io/
[2] IBM COBOL for z/OS documentation: https://www.ibm.com/docs/en/cobol-zos
[3] IBM Z Xplore Learning Platform: https://www.ibm.com/z/resources/zxplore
[4] Open Mainframe Project COBOL Programming Course: https://openmainframeproject.org/projects/cobol-programming-course/
[5] Open Mainframe Project COBOL course on GitHub: https://github.com/openmainframeproject/cobol-programming-course