by cgarvis on 8/11/21, 12:40 PM with 63 comments
by cdumler on 8/11/21, 2:14 PM
I once interviewed for a COBOL position. It was a typical large financial institution. It was a lead position that wanted a migration plan out and then would lead to a team for me. I have a lot of systems integration and information management knowledge. I have worked on planning multi-year projects and migrating out of large systems like this before. The interview went well, and afterwards they showed me around the place and what they were doing.
I sat down again in the office with the hiring director, and I enquired about how long he has been with the company and what he has been working on. Turns out he had been hired in five years ago and had already attempted this once before without success. I knew without a doubt why they didn't have success, and it had nothing to do with COBOL.
Financial companies are highly risk adverse. COBOL developers know this. COBOL developers know that if the shop isn't COBOL their job is at risk. So, COBOL developers will constantly introduce "what about this risk" issues, which then must be considered in committee; thus, the company is eternally paralyzed. The fact that the director couldn't make it anywhere in five years meant nothing was going to change.
As I recall, I checked in a few years later and they were still in the same place. I suspect it might have been a decent place if all I wanted in life was a paycheck. They were nice people.
by restlessbytes on 8/11/21, 1:39 PM
You've then successfully ported your code base from one language for which it's really difficult to find programmers to another language for which it's really difficult to to find programmers.
by WJW on 8/11/21, 1:37 PM
If your first response to this is "but that would cost a fortune!", you are completely correct. The biggest illusion in software is that a "complete" program is now "done" and will need no more investment. Software is a machine for producing information, fundamentally not much different from a lathe or a textile loom. If your company depends on a piece of software to continue existing, it is now de facto a software company. Many institutions have not yet realized this and will run into existential problems within a few decades.
by bencollier49 on 8/11/21, 3:30 PM
For example, the COBOL might potentially have been on an ICL VME system. This will undoubtedly have a lot of support code written in things like SCL (System Control Language), and potentially even 68k assembly.
There are companies which specialise in migrating COBOL code from legacy environments. This can involve migrating the COBOL code itself to a different variant and rigorously testing it, and then often introducing utilities which replace operating system functionality which was present on the original mainframe.
The alternative is to "salami slice" bits of functionality into modern services written afresh, and slowly work towards decommissioning the old setup, but often this has to be done at the same time as a migration to modern hardware, due to the scale of the systems involved and the time taken for these sorts of projects to complete.
by lucozade on 8/11/21, 2:26 PM
Transpiling, to more or less any language, is the easy bit. By a very, very long way. The hard bit is everything else. I mean, do they really think they're the first people to think about using a transpiler over the last 30/40/50 years?
If they had said that they'd used their transpiler on a real production codebase and their transpiled code was now running in production in any volume, I'd be quite impressed. But they didn't say that because it's blatantly obvious from the tone of the article that that will never occur.
Now, I don't have any issue with people being ignorant of a subject that they don't understand. That's the norm for most people for most things. But I have to say that this level of naivety doesn't reflect well on their company. They clearly made no effort to understand the problem that they are purporting to solve. Is that really how they function as a company?
by Wildgoose on 8/11/21, 2:45 PM
Perhaps we should consider how we can regularly rewrite different parts of our software ecosystems using new languages and approaches while preserving the essential knowledge and security aspects of what we have already built?
The important part isn't the language that the code is written in, it is the full understanding of the problem and thus the solution provided.
by tyingq on 8/11/21, 1:43 PM
by philipswood on 8/11/21, 1:01 PM
I've been unfortunate enough to witness first hand what +-5,0000,000 lines of Natural Adabas code transpiled to +-15,000,000 lines of Java code looks like, and it was not pretty.
by pronoiac on 8/11/21, 4:48 PM
Phase 1: automation of cobol to (ugly) Java
Phase 2: make the code more idiomatic for (cleaner) Java
Phase 3: move the infrastructure to AWS
In the discussion, someone mentioned "There are commercial COBOL compilers available that compile to Java bytecode."
Offhand, if someone were still on cobol, I'm not sure if they'd trust the comparatively new Elixir, but I can also see leapfrogging being a thing. (And I know it's based on Erlang, which pre-dates Java.)
by tjalfi on 8/11/21, 9:51 PM
[0] https://stuff.mit.edu/afs/sipb.mit.edu/project/lisp2cobol/l2...
by forgotpwd16 on 8/11/21, 3:47 PM
That answering the what if question. The project itself is interesting.
by scns on 8/11/21, 2:02 PM
Sorry, no https availlable.
by vajrabum on 8/11/21, 6:53 PM
Also, I haven't seen any mention of any of the bits of the COBOL ecosystem here? No DB2, IDMS, IMS DB/DC, VSAM, CICS, REXX, JCL? These are a big part of why COBOL applications are sticky.
by rhabarba on 8/12/21, 12:21 AM
by sharklazer on 8/11/21, 1:36 PM