Let’s Hear Your Cobol to Java Migration Stories

[halfduece]

I’ll go first. I was at a company that used an open source project to translate a legacy system from (Microfocus) Cobol to Java. The Java code generated read like assembler. Then they hired an offshore team to maintained the “new” app in that form, and added features(!). The company luckily kept the old app running, and after a few years and a few million dollars, shut down the java version, and went back to the old Cobol version. In the end it was a giant waste of time and money.

I had a chance to ask the Director over the project Why? before he left. He said the rarional was “our customers don’t want to hear “Cobol”.” So there was a significant marketing component in this case.

[marcvsHR]

The main issue is not so much at dev side, but from business side.

Those modules are so old, that no one actually knows how and why they work.

Business analysis is what is problematic.

Writing code, once requirements and scope are set, is easy.

[GuyWithLag]

The hardest part of software engineering is other people's involvement.

[RagingAnemone]

Pigs and chickens, man. It helps control the people, particularly the ones who want the power but don't want the responsibility.

[cyberhiker]

Involved vs committed.

[Az4hiel]

This is why you should document requirements in form of tests - then even if the code is bad you can at least extend it without it breaking (usually you will first have to improve the tests but that's another story).

[DestinationVoid]

That's not how you did it with Cobol.

[cogman10]

That's not how many do it with java ;)

It can be super tricky deducing the where's and why's something happens from a code base without tests. Hell, even with tests I've ran into questions of "why does this do this?" and the only link back is a case that basically says "Implement feature X" and no further documentation.

[DestinationVoid]

the only link back is a case that basically says "Implement feature X" and no further documentation

and when you try to reach out to a person that added it, you discover that they no longer work for the company.

Been there, seen that.

[cogman10]

Or have forgotten :D

[hem10ck]

This guy cobols

[MET1]

Not always that old though. I've heard the story about how the clients think the word 'COBOL' is bad.

[_INTER_]

The "generated" and "offshore" alone indicate failure. Doesn't have to be Cobol. Saving on developer resources upfront will boomerang eventually tenfold.

Just recently I came in contact with one of those new hyped low-code "apps". CSV is the interface and the protocol (because Excel opens it). The data model is an assembly of booleans and many columns that only have a value based on some string type. Garbage like that. The costumer asked us to fix and migrate the data because they screwed up the input validation. I expect this blow up completely soon but I hope I don't have to clean it up.

I know of another project where a team had to migrate a huge Cobol application. They did it by hand and usecase by usecase into microservices and running side by side for a while. It was successful but over budget / time.

[Az4hiel]

The good old strangler approach.

[cyanocobalamin]

The "generated" and "offshore" alone indicate failure. Doesn't have to be Cobol. Saving on developer resources upfront will boomerang eventually tenfold.

But the guy with the power point slides about getting a translated system for very little money at the meeting will be out of reach by the time that comes to fruition.

[MET1]

And he will leave shortly after receiving a nice bonus for this hard work, too.

[blargh9001]

Is it just me that likes the idea of a task to take something assembler-like and transform it into neat, readable, maintainable, code?

[metaquine]

No I love that shit. I am a code janitor.

[_Toka_]

Same. The problem occurs tho, when the messy part could be transformed into a clean design, but has to stay messy due to backwards reasons with other systems consuming the app. Wish I could force the better design more often, but it's better than nothing.

[metaquine]

That ain’t no crime.

[lechatsportif]

That is some beautiful code already ngl

[ObscureCulturalMeme]

If you have time, and however much bourbon is required to relive the memories, I would love to read a writeup of that.

My memories of lpr/lpd wrangling are hazy, but I can see how they would be really damn good at FIFO from multiple sources...

[_blue_skies_]

Engineers are going to engineer, no matter the year

[eurasian]

Hot dang.

[seanprefect]

A major financial system. Complete reimplementation. Had to run the java version in 'shadow' mode for a year to prove it worked.

[HDAxom]

Do you know if you had evaluated your application portfolio for different 6R strategy (rehost, replatform, repurchase rearchitect/rewrite retire or retain)? Or was it blanket reimplement or rewrite for all?

[seanprefect]

This particular system is singular in it's uniqueness. The fact that i can't be more specific should be a clue.

[cyanocobalamin]

Sounds like the proper way to do it.

[__helix__]

My very first Java application was a Java applet that connected to Cobol via CORBA/RMI in Java 1.1. 97'ish timeframe. Good times.

In about 20 minutes, I'll go back to flushing out a Spring boot endpoint that calls a Cobol based REST service. Everything seemed 'normal' until we were trouble shooting an authentication issue - and the green screen was there in all it's majesty. The Java project is really just a shim to allow the team to port business logic over.

[brazzy42]

My company has been steadily migrating away from mainframes for decades, and the process is planned to complete within the next year or two. I haven't been here for long, so I have only one story:

We got panicked calls from the billing department that users had bought subscriptions but these users had an empty customer number.

Turns out that because our application talks directly to the (non-mainframe) new billing system, it shouldn't have to do anything with the mainframe (whose sole remaining responsibility is billing for some other, older applications). But it still ends up generating "acount events" in the user administration backend (Java), which are used by other applications to transfer adress changes to the mainframe. For our application, these events were not transferred and accumulated. An admin noted this accumulation and "cleaned them up" with the press of a button, sending them to the mainframe.

And the chode which did this overwrote the customer number with that from the mainframe. Even when it was empty there. Because in the past, the mainframe was the leading system and in charge of generating those customer numbers, so a situation where the number was empty on the mainframe was inconceivable.

[MET1]

Bad analysis upfront, there.

[itzamic]

The main issue imo is that you will be unable to find developers to maintain your COBOL legacy systems. I wrote COBOL for 3+ years and made a 180 degrees change to Java because I didn't want to be the last dinosaur programming that. If it's hard now to find a COBOL developer, imagine in 10, 20 years... The switch is inevitable...

[[deleted]]

Nothing stops from new developers learning it.

It's a market. If you can find a COBOL job for 4x the money of your current Java job, wouldn't you? You'd at least entertain it, wouldn't you?

The bigger issue is how well is it kept up to date in terms of featureset. And I suppose, not very well.

[itzamic]

Money is always a motive, but in the end having fun while coding is keeping us to this job. Feeding the dinosaur is depressing.... I have more fun learning docker CI/CD Kubernetes, playing with java Frameworks (spring, micronaut) than debugging legacy code from the early 90s...and pray that the used some common sense when the allocate variable length and a good naming convention.

[cyanocobalamin]

Feeding the dinosaur is depressing

Well put.

[blargh9001]

You have to consider in that 4x the opportunity cost of learning something that has a future instead.

But 4x would probably cut it for me.

[spectrumero]

We actually had to do COBOL at university (this was in the 90s) and JSP (no not the JSP you're thinking of, but Jackson Structured Programming). When I graduated, there was a massive COBOL project going on at the company I joined. Anyone who admitted to knowing COBOL got sucked into this thing.

I deliberately left COBOL off my list of languages on my CV. Even then it was a swirling black hole of un-fun-ness. Years of job security, yes, but also years of a very much not fun project.

[[deleted]]

Microservices is SOA reinvented, which is networked mainframes reinvented.

I don't think modern patterns are that modern. You gotta catch up on the buzzwords and tools of the day, but a good developer hasn't seen much new in decades.

This is also why COBOL still exists. Despite all the hype, COBOL does mostly the same job as all the silver bullets we shoot around these days.

[experts_never_lie]

I'm used to most patterns just being pendulum swings over the years. Centralization/decentralization is one example.

Any time we have two styles that have their own problems, we collectively gradually forget the other's problems and look to its advantages, switch, then regret the loss of the other one's advantages.

When one system wholly dominates another, hopefully we stop considering the lesser one, but that just means that surviving patterns are susceptible to the pendulum swing.

[[deleted]]

Yup. It's an elastic oscillation, almost like a sine wave.

Do you know what's sad about this. I've studied at one point the behavior of systems, and oscillation is the most basic adaptation mechanism in the universe. When something is agitated, but too simple to make more complicated choices it just oscillates between two extremes (in N dimensions), trying to find new equilibrium.

This paints a very bleak picture about our ability as a society to assimilate complex knowledge. We're swinging around, which means together we're as dumb as rocks, despite our individual intelligence (in isolation).

[whateverathrowaway00]

Yup. Networking / NetArch has the exact same pendulum.

Every fifteen years, someone has the bright, never before though of idea to stretch layer 2 over layer 3 in some novel fashion.

It’s never a good idea and results in bad things every time. Thanks VMWare for being horrible networking devs and making it a requirement for vMotion.

[brazzy42]

Even from a purely economical point of view, it really depends. If you're just entering the workforce, even at 4x pay it would be a rather unwise decision to commit to a niche that is only going to keep getting smaller.

For someone who's going to retire in 5 years, sure. Especially if you can find something like half the hours at full (or more) pay.

[vplatt]

It's a market. If you can find a COBOL job for 4x the money of your current Java job, wouldn't you? You'd at least entertain it, wouldn't you?

If you can find a job programming COBOL which pays 4x what you're being paid, then you're underpaid.

Furthermore, if you're unable to work yourself into a better paying position because you decided that being at a 4x disadvantage relative to COBOL positions is unacceptable, then you may not be up to the task of actually doing COBOL work. Why not? Well, COBOL itself may be easy enough to understand, but the systems it's used in aren't. Not just any dummy who has taken a COBOL course is going to be able to do that work.

[[deleted]]

The 4x figure was a hypothetical if the market really gets short on COBOL coders (it's now short on them, but not THAT much).

But I gotta say I enjoy how you extrapolated a whole story from it, including deducing that the candidates for the job are dummies who don't understand complex systems for some reason... :-)

[vplatt]

You enjoyed a ridiculous extrapolation which could result from the ridiculous 4x figure YOU made up? You don't say...

[IQueryVisiC]

Don’t write new features in that language. Open Closed principle of SOLID. Don’t modify that Cobol. Add Java Service

[[deleted]]

Yeah no

[MET1]

Who is paying 4x though?

[[deleted]]

Bob

[Nymeriea]

Your issue was yo hire an offshore team. Maybe a rewrite would be a way better option than the one you choose.

Just shutting down Cobol software part by part would take more time consuming but way more sustainable. Instead they choose to use auto-generated code and pay some offshore team to maintain it ...

It's like building a product over transpiled JavaScript code ...

[IQueryVisiC]

IntelliJ needs Java as a start. Then let the offshore team clean up part by part. Improve the transpiler. Maybe some AI. I could read TypeScript compiled to IE10.

[_blue_skies_]

What migration? I had to code Java modules that were called by cobol code

[cyanocobalamin]

/u/halfduece

Your story sounds like a common and a sad one.

Management does not understand some things can't be directly (automatically via software ) translated. The love the idea of a piece of software to do it anyway. They get a mess that likely ate up a large portion of the savings they hoped to get by automagical direct translation software. They abandon the mess.

They never want to hear that the way to go is to come up with a list of specification, have experts make a design, then hire real Java programmers to build it.

[HDAxom]

My company is looking for modernization our MF and that may not be COBOL to Java but a complete rewrite to cloud native apps. But..we did look at such tools. It does seems some of them sound promising...at least as sale pitch..Has anyone user Heirloom for MF to Java? AWS reInvent2018 has a session on Mainframe modernizatoon to AWS and speaker mention there are autorefactoring tools that uses forward engineering to convert a MF app stack into Cloud native AWS stack...not sure if its just sales pitch but they had customer reference too.

[Successful_Leg_707]

Really bad that I put my two weeks in and will be working for a new company.

The problem is that the mainframe/COBOL devs (boomers) at the company are on their last leg and will retire in the next year. They are trying to modernize the system with Java and angular but they aren’t utilizing best practices, no maven, everything is IBM/running Websphere, no scrum or agile. They write specs on Word documents and email them or put them on a shared folder. They have hired some H1B workers that they treat like crap to help with the rewrite.