Ask HN: What Is the New COBOL? | Hacker News Reader

Ask HN: What Is the New COBOL?

2 pointsfreetanga8 comments

Hi. I’m running the IT department for a medium sized bank, and we are about to migrate a 70.000 programs and 1.200 tables from COBOL DB2 on mainframe - first to emulators for a few years,but a selective rewrite is in the air as well.

The thing I’m struggling to decide which tech stack to use - everyone has an opinion, but few people truly grasp the stress on reliability, maintenance, cost efficiency and long term support of the system holding all of your lifetime savings. Consultants telling me to write the beast in all sort of fancy languages, many which I consider a Fad which likely won’t exist in 10-15 years (minimum lifespan of rewrite)

So I wanted to pick HNs collective brain for suggestions on languages to pick. I was considering C, which we know well but is delicate to maintain (as in not every junior consultant can dangle well in it), or RUST (which I admit I don’t know but heard good things about)

Some additional info: We would be aiming at a functional rewrite, mostly service based. Front ends would be decoupled and served via APIs. Data layer will be abstracted to enable to shift CPUs loads in the future. Not a big fan of containers for this (but we do use them to scale our front end architecture)

Any ideas are welcomed. It’s a multi-hundred million investment and getting honest advice from someone not with a personal power play is hard. And rest assured this won’t be my only research, it’s just a soundness test

Many thanks f.

I think most banks bet on Java/the JVM.

C is too low level and, security-wise, too dangerous, and I would think any bank would say Rust hasn’t proven itself yet. I also would think it’s too low-level for typical banking software (that doesn’t mean no banking software should be written in it)

Database-wise, I would pick postgreSQL, but I’m not sure banks will want to pick a solution that isn’t backed by a large company.

Many thanks. Java is a clear candidate as well, of course. I have yet to catch up with the performance limits of Java and latest iteration of JVM, and also I am a bit wary of Oracle, the next IBM, on licensing squatting - just this week they came up with a paper claiming we owe them 2M in “extra migration licenses” despite having worked with them for 15 years and multiple generation migrations. But solid advice, thanks for your time.

My instinct would be to keep using COBOL on a mainframe. It's worked so far (presumably), and the headache of "getting it right" when you rewrite in another language seems enormous.

The emulator stage is that - zOS and DB2 emulation on x86 iron, at 50% cost (or so consultants claim - at least I can drive fear in IBM and lower costs if trials fail).

However we do feel complexity is creeping - some code is 50 yo - and a clean reboot might be the best way forwards. Also a lot of my team is edging towards retirement abs getting fresh COBOL talent is getting harder every day.

Not all the right motives, but puzzled together they start to make a case for change.

Have you ever heard of https://en.wikipedia.org/wiki/InterSystems_Cach%C3%A9 or the competitor linked from there https://en.wikipedia.org/wiki/GT.M ?

No, thanks. Looks like I have my reading list full for the next weekend :)

Get a bunch of little paper bags and fill them with different metal salts - then you can turn the money bonfire all kinds of colors!

Hahahaha, trust me, I have spent a big chunk of the last 25 years doing programs like these, and that made me a cheap tyrant regarding change requests and scope creeping. I am aware of what this can become, that is why I want to have a tight leash on design. Also, already hanged a “External Advisors will be shot on sight” outside the building.

Reply on news.ycombinator.com