I have limited experience with mainframe emulation, but from what I've seen, trying to do it in a live business environment is challenging at best because all of that old mainframe software was written with a lot of assumptions that don't apply to non-mainframe environments. Things like blazing-fast I/O, virtually guaranteed uptime of the mainframe, etc.

As one example, when I was a systems engineer, I got a call from a team that was trying to run a business application from z/OS in emulation on an x86 server. It was running incredibly slowly, even on a fairly beefy server. I looked in its data directory, and there were hundreds of thousands of individual files in a single directory. Not a tree. One directory. That might work fine on a mainframe, but just doing a dir or ls (depending on the host OS) took something like ten minutes.

Similarly, I remember some folks being dumbfounded at the idea that their batch processes needed error-handling when they were doing things that involved talking over the network, because when everything was running within that one giant IBM system, failures were pretty rare.

Those both sound like they should be easy to tack on when running in an emulator, but they're just the tip of the iceberg. When you have code that's 30-50 years old, written for a vastly different platform, there are going to be a lot of gotchas like that.

The authors emphasized in multiple places that moving off COBOL was a first-order project requirement.

I did find it interesting that the original system, and delivered overhaul, both ran Oracle databases. Overall transactional volume is low (500k/day). Perhaps the DoD has significant investments in stored procedures? Or perhaps Aurora is not ready for prime time in AWS Gov Cloud? (It’s no secret that AWS really struggles with keeping feature parity between Gov and commercial.)

The DoD has a significant investment in Oracle by name. In over a decade working around their systems, I've yet to encounter anything that couldn't be served by a mid-sized PG instance instead. The VAST majority of systems don't even register on 'performance' thresholds - they serve 5-50k users, almost entirely internal, etc. The 'bigness' of the program is its importance, rather than it's actual technical scale.

But there seems to be no business purpose justifying that requirement. They spent 30 months writing and refining a COBOL-to-Java transpiler instead.

Maybe the business purpose was to waste time and bill clients?

Which requirement? Moving off COBOL?

They mentioned numerous times that COBOL work was harder to staff and maintain.

Seems like a good reason to move to me.

I think that was somewhat implied in the article:

> "Difficulty finding qualified, affordable COBOL programmers."

Continuing to emulate the COBOL environment doesn't quite solve the problem that finding COBOL developers is becoming harder and harder.