3 ms·

I’m curious why there aren’t more x -> x conversion/adapter tools available. Most languages have the same core data models/abstract concepts, if there really is

by sbr464 8y ago

I’m curious why there aren’t more x -> x conversion/adapter tools available. Most languages have the same core data models/abstract concepts, if there really is an enterprise/business demand for a product, usually some company would come up with a solution. Personally I’m curious about COBOL and learning from it’s design, but I’m intrigued by this question in general.

bitfhacker 8y ago
Hi! First post on here. The conversion/adapter tools exists. It's not a technical issue. The problem is that cobol applications are normally monolithic, and a migration to another system represents an huge risk because: 1) you migrate like a Big Bang migration, or; 2) you migrate step by step. Imagine a bank with applications running at 30 or 40 years without problems... Nobody in his perfect judgment will accept to have a Big Bang migration. The risk is too high. For migrating step by step, you must have a good bussiness case (it must compensate the risk), opportunity (you must be able to keep working in the Bussiness As Usual) and you must have the right people (people that have the knowledge in organization). If you don't have this three things it will be very hard to migrate Cobol to another language/platform. Usually Cobol is used in mainframe, so the right aproach (with less risk) IMHO is to migrate first COBOL from z/os to a Cobol in another platform (windows/*nux whatever), and then migrate Cobol gradually to another language.
- rectang 8y ago
  There can also be an intermediate phase of migrating from a hardware mainframe to a virtualized mainframe. I understand that's what TicketMaster did a while ago. > Hi! First post on here. Welcome, and very nice post. :)
sevensor 8y ago
> Most languages have the same core data models/abstract concepts There was a post on here not too long ago about COBOL's decimal arithmetic -- if you're not careful, your Java / Python / Ocaml is going to give you different numbers. So on the "core data model" front, there's more than meets the eye. Add to that the barrier to entry of working on mainframes: even if you install an emulator and play around with COBOL, you don't have a big COBOL codebase to work with, so you have no idea what you're going to see in a production system that was written 45 years ago. https://news.ycombinator.com/item?id=17636029 https://news.ycombinator.com/item?id=17636029 Not that I really believe we're headed for a COBOL crisis. COBOL systems will no doubt continue to rust in place and eventually reach irrelevance as they're decommissioned one by one during horribly mismanaged bank mergers. The exception is the federal government of the U.S., which will surely continue operating its COBOL systems until the end of time.
tyingq 8y ago
There is likely more to solve than just code. COBOL is often running in a proprietary environment with dependencies on things like job schedulers, databases, terminals, network protocols, character sets, etc. Check the COBOL job postings, and you'll see desired skills in TSO, JCL, CICS, Natural/Adabase, VSAM, etc. Or equivalents of those for OS/400, MPE, or VMS mid-range platforms.

by sbr464 8y ago

bitfhacker 8y ago

Hi! First post on here. The conversion/adapter tools exists. It's not a technical issue. The problem is that cobol applications are normally monolithic, and a migration to another system represents an huge risk because: 1) you migrate like a Big Bang migration, or; 2) you migrate step by step. Imagine a bank with applications running at 30 or 40 years without problems... Nobody in his perfect judgment will accept to have a Big Bang migration. The risk is too high. For migrating step by step, you must have a good bussiness case (it must compensate the risk), opportunity (you must be able to keep working in the Bussiness As Usual) and you must have the right people (people that have the knowledge in organization). If you don't have this three things it will be very hard to migrate Cobol to another language/platform. Usually Cobol is used in mainframe, so the right aproach (with less risk) IMHO is to migrate first COBOL from z/os to a Cobol in another platform (windows/*nux whatever), and then migrate Cobol gradually to another language.

rectang 8y ago
There can also be an intermediate phase of migrating from a hardware mainframe to a virtualized mainframe. I understand that's what TicketMaster did a while ago. > Hi! First post on here. Welcome, and very nice post. :)

sevensor 8y ago

> Most languages have the same core data models/abstract concepts There was a post on here not too long ago about COBOL's decimal arithmetic -- if you're not careful, your Java / Python / Ocaml is going to give you different numbers. So on the "core data model" front, there's more than meets the eye. Add to that the barrier to entry of working on mainframes: even if you install an emulator and play around with COBOL, you don't have a big COBOL codebase to work with, so you have no idea what you're going to see in a production system that was written 45 years ago. https://news.ycombinator.com/item?id=17636029 https://news.ycombinator.com/item?id=17636029 Not that I really believe we're headed for a COBOL crisis. COBOL systems will no doubt continue to rust in place and eventually reach irrelevance as they're decommissioned one by one during horribly mismanaged bank mergers. The exception is the federal government of the U.S., which will surely continue operating its COBOL systems until the end of time.

tyingq 8y ago

There is likely more to solve than just code. COBOL is often running in a proprietary environment with dependencies on things like job schedulers, databases, terminals, network protocols, character sets, etc. Check the COBOL job postings, and you'll see desired skills in TSO, JCL, CICS, Natural/Adabase, VSAM, etc. Or equivalents of those for OS/400, MPE, or VMS mid-range platforms.