11 ms·
Watsonx: IBM's code assistant for turning COBOL into Java
- deleted 3y ago[deleted]
- discmonkey 3y agoClassic misunderstanding of programming languages. The only thing stopping cobol from being "known" is these companies paying for it.
- SillyUsername 3y agoChicken and egg, companies stop paying, say no devs, devs not interested as no companies paying for it. Tell me that COBOL to Java porting pays $150K p/a and I'll be happy to take the job, at least for a year or 3.
- adra 3y agoYou work that as a contractor easy if you can find them. The problem is they're rarely hiring one offs to do this because these companies don't have engineering cultures, which is why they contract this shit to system integrators of the world like IBM, then they outsource the work to shoddy consultancy shops to maximize their profits doing basically zero work. If everything goes exceptionally bad (which it did at least in the case I was involved in), then they hire competent contractors to come in and save them from frighteningly large law suits. That's the new dev cycle of these legacy modernizations.. ahh
- mlhpdx 3y agoIt’s more than that. If you spend a couple or more years learning to maintain those systems, where else will you work? Will you find a co-founder or investor for a COBOL based system when you go “entrepreneur”? Maybe, but it better be a damn strong niche. Not moving forward with the software industry is a weird kind of conceit that separates these companies from the mainstream by far more than money.
- rightbyte 3y agoIt still comes down to paying enough money for someone to do it. Pay me twice what I make now and I'll switch to coding absurd legacy all-caps COBOL systems in a heart beat. Probably less then that too.
- serallak 3y agoI don't think it'd take two years to learn cobol, it should be less than that. But it will take much more than that to learn the gnarly codebase in use in those shops... And that is a skill that is certainly not transferable.
- exhilaration 3y agoI don't think it'd take two years to learn cobol, it should be less than that. There's a comment in this thread from a former consultant that completed a 4 week COBOL bootcamp before being sent to a client to write code!
- wombatpm 3y agoIt’s not the language, it’s the business rules and history. Why is this input file loaded and rechecked 3 times? Because 30 years ago a file load failed, breaking end of quarter reports. This was the fix: if we can read that file three times and it doesn’t change then we know it’s good
- ajross 3y agoPretty much exactly. There are wizards at Project Zero doing reverse engineering of systems at the hardware microcode level. Our own kens shows up every few weeks with transistor level explanations of devices whose designers are long since retired. And we're supposed to believe that no one in the world can figure out a batch-processed COBOL accounting system? Please. The talent is there, it's just that no one responsible for these systems wants to hire at that level. But in extremis they will, and the world will survive.
- tw04 3y agoPlenty of folks know COBOL - the problem is you need to entice someone YOUNG to learn it, which basically means overpaying them. If I'm an 18-year-old why would I focus on learning a programming language that puts me in a job with 0 chance of advancement? Sure I'm irreplaceable to the company, but I've also only got a handful of other places I could go if they treat me poorly or sunset their mainframe.
- tobyjsullivan 3y agoI’d be curious to know how we’re defining “overpaying” here. These companies have effectively accrued 50+ years of technical debt (they could have migrated off COBOL decades ago). Meanwhile, based on my limited experience with these industries, I’d be surprised if they even offer market rates to new hires.
- nobodyandproud 3y agoLet me up the ante. Why do we believe COBOL is yech-debt?
- pixl97 3y agoHell, after seeing both kind of applications (java vs cobol) by these bank/financial companies I am of the opposite mind. Those COBOL applications will keep working until the sun burns up or inflation makes the numbers so long they no longer fit in bounds. The java applications they write should fill you with terror.
- trealira 3y agoWhy do you say the Java applications at banks and financial institutions so bad? I'm not trying to contradict you or say you're wrong; I just want to know why. Not having ever seen this kind of software, I would assume that the existing COBOL applications are good simply because all the bad COBOL code was probably scrapped decades ago, an example of survivorship bias.
- jalk 3y agoThere seems to be plenty of cobol transpilers - anybody know why they can’t use those. Immediate thought was it’s just beating on the dead Watson horse.
- kjs3 3y agoIf they worked as effectively as they were touted, they'd have cleared out the cobol.
- pixl97 3y agoNo really, in fact I'd say the opposite. The issue with COBOL is any old idiot can't write it. If someone is touching the COBOL they are going in and making minor changes/expansions to an application that is older than the average HN user and those changes and expectations are well defined. With Java and/or language of the day your cheapest run of the mill contractor given exceptionally poor instructions will crank out X LOC per day where X is the required output for them to keep their job. Maintaining that code will be some other bastards problem.
- kjs3 3y agoI have no idea how that's the opposite of what I said. Transpilers haven't worked not because of how much or little the replacements are paid, or how well they do their job, but because there's more to moving from one computational ecosystem to another than just the language.
- grammie 3y agoCorrect, language transpilation is the easy bit, ensuring that execution and behavoir is the same as on the mainframe is tough, but also solved.
- grammie 3y agoHeirloom Computing, I am CTO, have transpilers for cobol and pl/1. code transpilation is the easy part. Create a Grammer for the source language, generate the ast, transform the ast to the target language ast and generate the code. Now make that generated code run and behave the same way as on the mainframe and give it all the subsystems that exist on the mainframe for transaction, file handling, security etc. This is the part that is difficult. Fortunately it's already solved and in production with our clients. So transpilers do work and are in production but our biggest competitor is inertia.
- dun44 3y agoRegarding IBM's use of technology widely known for hallucinating to translate sensitive source code: it sounds weird you think the primary objective here is to deliver something that properly translates from one language to another. But it is not - the primary objective is to get money from customers and investors. Delivering something that works is secondary, and honestly, optional. Many things in IT start making a whole lot more sense once you reexamine your beliefs about their purpose.
- datadrivenangel 3y agoEspecially for IBM! See IBM Watson for details.
- ProjectArcturis 3y agoI guess translating COBOL is somewhat less embarrassing than Watson being used to predict fantasy football scores.
- rcbdev 3y agoThis has been IBM's M.O. ever since acquiring PwC Consulting in the early 2000s. Even their downfall feels incredibly sluggish and geriatric.
- kjellsbells 3y agoIndeed. If you are the board of any publicly traded technology company right now, and you don't have an AI strategy that you are telling the market, your stock is going to take a beating as investors flock to those who do. The strategy doesnt need to have a lot of meat behind it. Once it was crypto, now its AI, tomorrow it'll be something else. But AI has really captured people's imaginations, which means even the most foggy investors are looking at it. That drives leadership behavior more than the tech itself
- elteto 3y agoThese systems have not been running untouched for 60 years. Regulatory environments change almost constantly and the code has to be updated accordingly. I don’t personally know anyone writing COBOL but I’m certain there’s plenty of people doing it. And to change the code you have to know it. So there’s really no 60 year old code that no one knows anymore. Also, at this point, if you are running on a dead platform and language and you know it, and haven’t addressed it, then it’s on you. I’ve been seeing these COBOL articles since the 2000s I believe.
- kjs3 3y agoI’ve been seeing these COBOL articles since the 2000s I believe. Since the '80s for me. And certainly the '90s, since these sort of zero-content articles were very popular in the runup to Y2K: "the entire world is going to end because there are no Cobol programmers anywhere in the world! Everyone panic!". It's still bullshit.
- zoom6628 3y agoAbsolutely. I've seen same since I started as a programmer in COBOL and assembly in early 80s.
- pixl97 3y agoI've seen some currently used COBOL that had it's like change date in the early 80s in the finance industry, so there some rather ancient programs out there. Of course this also means that these files have met the needs of the industry that long and bug free so why go messing with things that move 100s of millions/billions of dollars per day.
- uxp8u61q 3y agoEven if it's not handling billions of dollars a day... Why fix what isn't broken? Software isn't an end into itself, it's a tool to solve a business need. If the business need is met, there's not anything to fix.
- welcome_dragon 3y ago[flagged]
- hn_throwaway_99 3y agoThe flawed "economic analysis" in this article is so commonly brought out, but at this point we should just call it what it is: lying. There is no "shortage of COBOL programmers." Businesses are simply choosing what they will pay, and the market is responding appropriately. And this is also not just a case of naively shouting "duh, just pay them more" for a market that can't bear the increase in costs (i.e. some industries can only survive if there are available low cost workers - most of us aren't willing to pay $40 for a fast food burger, for example. Whether those industries should be around if they can only survive on low cost labor is another story...) It's not exactly like the financial world is scrounging for money. Businesses can either choose to pay their CEOs a hundred million or so, or they can choose to spread some of that money to COBOL programmers. The choice is theirs, but there is no "shortage".
- deleted 3y ago[deleted]
- nonrandomstring 3y agoI agree with you on the myth of "a shortage", and respect your strongly pro-market argument. Therefore "some industries can only survive if there are available low cost workers" suggests to me that those industries should simply die. Let more efficient industries that return more value to people thrive in their place?
- high_5 3y agoIt makes more sense to invest 100m $ in AI assistant for a year and then pay the CEO 120m/year the next one after firing the rest of the COBOL devs.
- gopher_space 3y agoI cut my teeth on financial COBOL back in the 90s and from my perspective the article isn't "lying", it's "completely divorced from reality". For the past three decades it's been cheaper to encapsulate these systems and extend functionality by working in a modern language, and so that's what everyone's been doing. The prime issue (imho) is that it's less expensive and better for everyone if you rewrite these systems from scratch, but that cost is still so prohibitive that it might not make sense to keep operating the company. The second issue is hardware availability, a bizarre omission on the author's part. Your org lifespan might entirely, predictably depend on how many spares a forward-thinking dev bought in the 70's. The third issue is fintech. Someone else has already raised the cash needed to rewrite from scratch, and what you can do about it is sell them your client list. From a personal perspective COBOL is such a pain in the ass to work with that I'd need a ruinous salary to be enthusiastic about the job.
- mperham 3y agoWe see this same article every year or so. Same song for 20+ years now.
- mlhpdx 3y agoI learned COBOL from curiosity (never using it professionally) in around 2010. It’s simple enough to read and use, but without having seen these legacy systems I don’t know what I don’t know. This is just one of many examples of organizations squeezing an impressive but foolhardy lifespan out of some systems. Some CEO or another should have come to the conclusion (sooner) that they run a business, not a museum.
- lucidguppy 3y agoThis is a management problem. Lack of long-term planning. People knew COBOL was "feature complete" DECADES ago. "If it ain't broke - don't fix it." does not mean "don't maintain the things you own - just let them run until they break - then fix them."
- kjs3 3y agoI hate to break this to you (large financial here, large COBOL installed base) but we're not just sitting around watching it run. We have hundreds of COBOL programmers, and they actually touch the code. I bet every day even. Crazy, right? Just because some low-knowledge 'journalist' in a low-content rag decorates their ad-delivery with a low-effort 'you should have outrage about something' articles doesn't mean you should buy into it.
- justahuman74 3y agoCurious if you happen to have a ball-park figure on what 2023 compensation looks like for a COBOL programmer
- ufmace 3y agoThe article title is clickbaity, but the actual point is the proposal of using LLMs to translate large amounts of legacy COBOL systems to more modern languages like Java. Doesn't seem terribly useful to me. I expect you could get a 90% solution faster, but the whole challenge with these projects is how to get that last bit of correctness, and how to be confident enough in the correctness of it to actually use it in Production. But then all of this has been known for decades. There are plenty of well-known techniques for how to do all that. If they haven't actually done it by now, it's a management problem, and no AI tech is going to fix that.
- matthewdgreen 3y agoHow hard is it to actually learn COBOL? It seems like a fairly simple language to pick up, but maybe the idiomatic COBOL used in these legacy systems is particularly nasty for some reason.
- the_only_law 3y agoLearning COBOL is the easy part. My understanding is the hard part is becoming familiar with insanely expensive, proprietary mainframe platform that’s you’ll find in most COBOL work. I know IBM has some sort of self training material, but I’m not sure if it’s enough to go from zero to qualified. Most work I see in the area seems to want established domain experts, not hackers who learn just enough to be dangerous.
- briHass 3y agoNot really much different from today: sure, you can 'learn' a new language in a few days, but you won't know the build tooling, deployment strategies, environment specifics, convention over config, and typical patterns/practices that will allow others to understand what you wrote.
- kochbeck 3y agoIt’s not that the mainframe is hard to learn. In fact, the environment is pretty easy to understand once you get past the archaic naming (but let’s not kid ourselves: on the POSIX side we’re still running t[ape]ar[chive] and other archaic tools too). In a way, the ease IS the problem: the runtime environment for COBOL (and other stuff on the mainframe) assumes that the underlying platform and OS deal with the really hard stuff like HA and concurrent data access and resource cost management. Which, on the mainframe, they do. Now, contrast that with doing the same thing in, say, a Linux container on AWS. From the stock OS, can you request a write that guarantees lockstep execution across multiple cores and cross-checks the result? No. Can you request multisite replication of the action and verified synchronous on-processor execution (not just disk replication) at both sites such that your active-active multisite instance is always in sync? No. Can you assume that anything written will also stream to tape / cold storage for an indelible audit record? No. Can you request additional resources from the hypervisor that cost more money from the application layer and signal the operator for expense approval? No. (Did I intentionally choose features that DHT technology could replace one day? Yes, I did, and thanks for noticing.) On the mainframe, these aren’t just OS built-ins. They’re hardware built-ins. Competent operators know how to both set them up and maintain them such that application developers and users never even have to ask for them (ideally). Good shops even have all the runtime instrumentation out there too—no need for things like New Relic or ServiceNow. Does it cost omg so much money? Absolutely. Omg you could hire an army for what it costs. But it’s there and has already been working for decades. God knows it’s not a panacea—if I never open another session of the 3270 emulator, it’ll be too soon. And a little piece of me died inside every time I got dropped to the CICS command line. And don’t even get me started on the EBCDIC codepage. Folks are like, “But wait, I can do all of that in a POSIX environment with these modern tools. And UTF-8 too dude. Stop crying.” Yup, you sure can. I’ve done it too. But when we’re talking about AI lifting and shifting code from the mainframe to a POSIX environment, the 10% it can’t do for you is… all of that. It can’t make fundamental architectural decisions for you. Because AI doesn’t (yet) have a way to say, “This is good and that is bad.” It has no qualitative reasoning, nor anticipatory scenario analysis, nor decision making framework based on an existing environment. It’s still a ways away from even being able to say, “If I choose this architecture, it’ll blow the project budget.” And that’s a relatively easy, computable guardrail. If you want to see a great example of someone who built a whole-body architectural replacement for a big piece of the mainframe, check out Fiserv’s Finxact platform. In this case, they replaced the functionality (but not the language) of the MUMPS runtime environment rather than COBOL, but the theory is the same. It took them 3 companies to get it right. More than $100mm in investment. But now it has all the fire-and-forget features that banks expect on the mainframe. Throw it a transaction entry, and It Just Works(tm). And Finxact screams on AWS which is the real miracle because, if you’ve only ever worked on general-purpose commodity hardware like x86-based Linux machines, you have no clue how much faster purpose-built transaction processors can be. You know that GPGPU thing you kids have been doing lately? Imagine you’d been working on that since the 1960s and the competing technology had access to all the advances you had but had zero obligation to service workloads other than the ones it was meant for. That’s the mainframe. You’re trying to compete with multiple generations of very carefully tuned muscle memory PLUS every other tech advancement that wasn’t mainframe-specific PLUS it can present modern OSes as a slice of itself to make the whole thing more approachable (like zLinux) PLUS just in case you get close to beating it, it has the financial resources of half the banks, brokerages, transportation companies, militaries, and governments in the world to finance it. Oh, and there’s a nearly-two century old company with a moral compass about 1% more wholesome than the Devil whose entire existence rests on keeping a mortal lock on this segment of systems and has received either first- or second-most patents every year of any company in the world for decades. It’s possible to beat but harder than people make it out to be. It makes so many of the really hard architectural problems “easy” (for certain definitions of the word easy that do not disallow for “and after I spin up a new instance of my app, I want to drink poison on the front lawn of IBM HQ while blasting ‘This Will End in Tears’ because the operator console is telling me to buy more MIPs but my CIO is asking when we can migrate this 40-year old pile of COBOL and HLASM to the cloud”). Mainframes aren’t that hard. Nearly everyone who reads HN would be more than smart enough to master the environment, including the ancient languages and all the whackado OS norms like simulating punchcard outputs. But they’re also smart enough to not want to. THAT is the problem that makes elimination of the mainframe intractable. The world needs this level of built-in capability, but you have to be a bit nuts to want to touch the problem. I have been to this hill. I can tell you I am not signing up to die on it, no matter how valuable it would be if we took the hill.
- pard68 3y agoI work for a company that develops and maintains code that "no one knows anymore" which helps run the US banking system. This article is ill informed fear mongering and the proposed "solution" is a joke.
- rabuse 3y agoCare to elaborate on this a bit? Some details would've been useful rather than just a "no u" comment.
- jacquesm 3y agoIt's spot on. This is such a crazy end run around the real issue that it won't solve anything, it replaces COBOL that apparently the people that need this don't understand with Java that they also won't understand because it will be translated from idiomatic COBOL, which has about as much to do with Java as it does with Prolog, Visual Basic or C. You'd need to be an expert in both Java and COBOL to make soup of it.
- Closi 3y agoAnd presumably this is why it requires an LLM rather than a transcompiler. You want to translate 'idiomatic COBOL soup' which has been added to over decades into clean structured (possibly OOP) code covered by a robust library of tests.
- pard68 3y agoThere isn't much to elaborate on. We are not hard up for COBOL or RPG devs, I'm sure some municipalities are but they are probably hard up for anyone who has the skills to make six figures. COBOL is used still for far more reasons than technical debt, there is good reason for the language and I doubt Java is even capable of replacing it. Even if an AI could write a 100% perfect Java version of COBOL, Java would fall flat on its face. COBOL and other languages like it are very performant languages, optimized over more than a half century.
- buro9 3y agohttps://www.glassdoor.co.uk/Salaries/cobol-programmer-salary-SRCH_KO0,16.htm https://www.glassdoor.co.uk/Salaries/cobol-programmer-salary... If it's so valuable to the industry that they have good people who know it, that should surely be reflected in the salary / comp for roles... And if that were high, people would learn it, but it's not high, it's arguably worse than just learning a little JavaScript
- halfdan 3y agoYou’re looking at salaries for COBOL programmers in the UK which is a small subset of an already small market.
- IshKebab 3y agoI've checked in America before and came to the same conclusion. There's an idea that COBOL programming pays vastly more than other languages, but it's just a myth. It might pay a little more, but more like 20% more. Certainly not enough to warrant a COBOL career. And I'm sure some consultants can earn vast sums fixing old COBOL code, but that's just because they're consultants. Consultants always earn vast sums.
- cowsandmilk 3y ago> Certainly not enough to warrant a COBOL career. I don't understand why people are claiming this sets your career to only ever write COBOL. I know plenty of people who started their careers with perl, but have been Java, JavaScript, TypeScript, Go, or Rust programmers at different points as their careers progressed. Someone overseeing a project migrating a COBOL monolith over time to a set of decoupled services in some other language would easily have a strong story for the timeless need of improving application architecture.
- aitchnyu 3y agoIndian companies take fresh graduates and train them into mainframe devs. I was a little sceptical about shrinking pool of highly paid people.
- moritzwarhier 3y agoWhat prevents future employees from learning this language? Its development might have stalled, but as long there is documentation, whenever COBOL code breaks, there is are humans who can learn to fix the issue. Even when all "COBOL cowboys" have died out.
- apstats 3y agoI feel like this solution was written by someone who hasn’t built software before. Doing a rewrite for the sake of a rewrite is not a good idea.
- high_5 3y agoSo... Having no COBOL devs left is a better one? What's the alternative then?
- apstats 3y agoYes - if we need them to people can learn COBOL it's not any harder to learn than many other programming languages.
- deleted 3y ago[deleted]
- stonogo 3y agoThere are plenty of COBOL devs; they're just not in the American labor market.
- dr_kiszonka 3y agoWould bumping starting salaries for Cobol devs to 150k, resolve it in the US? (I am assuming banks could afford it.)
- stonogo 3y agoNo, since that's not too much higher than starting salaries for Python programming at a medium-sized research institute, and there's no clear career progression for COBOL programmers.
- bluedino 3y agoNot sure what's worse, depending on LLMs, or IBM to fix your COBOL project.
- curious_cat_163 3y agoI would hazard that depending on LLMs is worse.
- haolez 3y agoI know of a retail company that hired IBM to get rid of its huge Clipper code base (around 1.5MM LOC). IBM told them that they would get rid of all Clipper in 2 years. 5 years later, IBM has a few containers (physical containers) in this company's parking lot, adapted as offices, full of engineers doing maintenance and new features on the Clipper code base.
- rcbdev 3y agoDuring my time at the company we never once talked about what the customer actually needed or wanted. Your story confirms my suspicion that this type of sales-driven development is just how IBM operates anywhere. The truth is, IBM has been bean counted to death. Their turnover rates are incredibly high, employees have to deal with utilization targets that they can't meaningfully do anything about and lines of communication are incredibly dysfunctional. Their global headcount has been quietly but steadily declining since the dawn of the 2000s and their whole EMEA business is riding on having good ties to the right people in the public sector. The result is that IBM's customers are increasingly unhappy. I do not see how this company is going to survive in its current form.
- hnbear 3y agoHaving had to support and migrate COBOL in a big financial the problems weren’t really related to the COBOL, but instead were: 1. The mainframe costs and support. These can be mitigated with migration to a platform like Microfocus to emulate it, but be careful you don’t replace your ultra reliable mainframe with some flakey Windows servers. 2. The embedded business logic. Within the 50-60 years of code there’s a ton a specific edge cases encoded for long forgotten business reasons. These make rewrites really hard as bugs and edge cases have long since become features or behaviors dependent apps are coded to rely on. It takes a ton of extra analysis work to understand what to keep and what to trash. 3. The cobol apps run in a challenging environment that’s also not well understood today. All the jobs in JCL, ISPF to manage things, and a system like CICS for input/output. It’s a huge change beyond just writing code in a regular IDE.
- DebtDeflation 3y ago>The embedded business logic. Within the 50-60 years of code there’s a ton a specific edge cases encoded for long forgotten business reasons. Honestly, this should be the top comment in the thread. The issue isn't COBOL being a hard language to learn or to translate to Java or not enough programmers or companies not being willing to pay people enough to work with it. The issue is the 50 years worth of business logic, added incrementally, over the years, with no documentation, blended into the original source, for reasons no one still working there remembers, as you stated. It's IF-ELSE statements all the way down and no one wants to touch a single one of them for fear of breaking something whose conditions might not even manifest themselves for months or years with no real way of even regression testing it.
- Closi 3y agoBut there is one way it can be done - lots of painstaking analysis of the Cobol source code to attempt to extract the business logic (which is incredibly slow). At least this is how we did it at my old work where we were replacing a mainframe system. In principle though, this is stuff that an LLM could do - assist with extracting some of this business logic and speed this process up (while porting it to a language that is easier to work with). While the LLM doesn't necessarily understand the business context, it can do basic analysis which will speed it up massively. It can also generate test cases across the whole codebase.
- Stratoscope 3y agoOne correction on the article: "watsonx" (yes, with a lowercase "w" - ugh) is an umbrella brand for several of IBM's "AI" related products. The actual product name for this one is "watsonx Code Assistant for Z", as the author could have found with a simple web search: https://www.google.com/search?q=watsonx+cobol+java https://www.google.com/search?q=watsonx+cobol+java https://newsroom.ibm.com/2023-08-22-IBM-Unveils-watsonx-Generative-AI-Capabilities-to-Accelerate-Mainframe-Application-Modernization https://newsroom.ibm.com/2023-08-22-IBM-Unveils-watsonx-Gene... Disclosure: I work for IBM in "watsonx Orders", an automated order taker for restaurant drive-thrus.
- dr_kiszonka 3y agoHow do you like the job? (Just curious, no relation with or friends at IBM.)
- Stratoscope 3y agoLike many large companies, IBM discourages us from engaging in "social media" (which I guess includes HN) on work-related questions. I felt that I could make an exception for the minor correction of the product name. It's probably not appropriate for me to comment here on how I like the job. I would be happy to discuss it privately with you or anyone else who is curious. My email address is in my profile; feel free to drop me a note and I will follow up with you.
- throwaway98797 3y agonot op appreciate the comment this exchange is what i show young people to demonstrate why you should never work for such companies (not signaling out yours specifically) human want to be human (tho a buddy of mine worked there with great benefits & $)
- ukuina 3y agoWhy is it bad for a company to have a social media or online comment policy?
- grammie 3y agoIt's a demo but the code that is transformed is trivial in the extreme. The whole approach of selecting small pieces is just not scalable. One small project i worked in was 22 million lines of cobol code, spread over 4000+ programs imagine having to select bits of code out of that.
- spindle 3y agoI believe that practically the whole barrier to getting rid of legacy COBOL systems is testing the replacement system. Of course it's possible but it's very very expensive ... I don't have numbers for how expensive, but I've worked on financial software in COBOL on a mainframe, and nothing was the least bit abstruse or scary or difficult about it except the worry that our test suite might not be comprehensive, no matter how much we worked on it (and we worked on the test suite about the same amount as we worked on all the rest of the code put together). But at least our test suite appeared to cover all the cases that eventuated when we ran our COBOL code. How confident would be be that it would cover all the cases that eventuated when we ran translated code? THAT is the problem (or at least was for us). Nothing at all to do with whether translating COBOL can be made easier.
- wokkel 3y agoNo, getting a 100% equivalent working Java system is trivial. But the goal is having something that looks like it was Java from the start not Java as written by a cobol expert. So proper use of classes. Not al globals. Sensible naming etc. The real cost is in maintenance of the code: having in idiomatic Java could help. Translating to idiomatic Java is very hard
- fbdab103 3y agoI think those companies would kiss you on the mouth and do any unspeakable acts you requested were you able to promise a 100% equivalent system in Java. There is a ton of industry experience in turning working-but-trash Java into something more maintainable.
- gumballindie 3y agoAnother marketing piece by IBM aimed at impressing inexperienced managers and developers. If they wanted to come up with a tool to rewrite Cobol they’d have come up with a standard transpiler.
- hedora 3y agoThe implicit assumption here is that developers will charge less to maintain code that was machine translated from cobol to java than they will to maintain the original code. I’d certainly want to be paid more to deal with the LLM output than the original source code. I don’t know cobol and I do know java, but that doesn’t enter into it from my perspective.
- delecti 3y ago> I don’t know cobol and I do know java, but that doesn’t enter into it from my perspective. Shouldn't it though? Maybe you (as an individual) would charge (or expect to be paid) more to maintain LLM code than bespoke code, banks know they won't have to pay as much to you (as a member of the collective of java engineers) than they would to a cobol dev. Really the implicit assumption is that cobol devs are fewer and more expensive than java devs.
- wredue 3y ago>it might be 80 or 90% of what they need Yeah. Not good enough. For the life of me, I cannot remember the name, but I remember we used another IBM tool to translate cobol to Java, and what it generated was horrific dogshit Java that also was 80-90% of the way there. Thing is that, unless you have very comprehensive testing laid out (lol. Find me a mainframe shop with comprehensive testing and I’ll smash my testicles in a hydraulic press), it’s impossible to know what it missed, and thus the 80-90% of the way there was effectively 0. We never did push forward with this tooling, but I strongly suspect that had we, the ROI would have been vastly net negative after horrendous business impacts.
- RickJWagner 3y agoI don't think it's worth it. Disclaimer: Started career in COBOL on mainframes. Hold Sun Certified Java Architect and Java Programmer certs. Have worked in professional Open Source (mostly Java middleware) for over a decade.) I'm not sure the Java will be more readable. Java's dependency/library spiderweb is much more complex and fragile. COBOL on the mainframe is maintained from a central position. COBOL won't have the attack surface Java will (see previous point about dependencies). I think it might be better to just train newbies on COBOL. Caveat: Maybe cloud economics can make a compelling budgetary argument.
- nunez 3y agoLiterally today I was checking out of a rental car center and the checkout person loaded up an emulated green screen mainframe program to complete the process. I know for sure that Avis's reservation system runs on mainframe. To me, that means that the business logic of rental car checkout and return is so complicated and/or nuanced, it is cheaper for rental car companies to find/retain mainframe developers to keep these running than it would be to re-platform onto commodity hardware. Also, given that basically every industry is powered by a handful of mainframes, it is surprising that COBOL/Fortran developers aren't making insane money like I thought they were.
- Exoristos 3y agoIt's cheaper to threaten their families.
- Kwpolska 3y agoI doubt the rental car system is complex. It was probably written decades ago and is now complete and bug-free. Keeping it running on a mainframe with emulated terminals is far cheaper than a modern rewrite, and the age/maintainability of their software is the least of their concerns.
- jillesvangurp 3y agoI helped a client with some dependencies on Avis and a few other car rental companies a while ago. They indeed have some really old, clunky software. At least judging from the data dumps I had to work with. Also some notable differences in the quality of the data between different providers that I had to work with. There are plenty of new mobility startups managing just fine without any Cobol or other legacy software. The issue companies like Avis have isn't their software but their lack of competitiveness and ambition level. The car rental business is always changing and they have to somehow adapt with it. And they struggle with that. It's not their software that holds them back but their dependence on things not changing. The software is just a reflection of how uncompetitive they are.
- pelasaco 3y agoI think there are better languages to try to convert to, and as long they run on top of JVM, it should be fine.
- kwanbix 3y agoI want to go back to doiyng COBOL programing, so that I can land a job to keep a system up to date. However, while learning COBOL is not that complicated, learning the mainframe part is, because it is very difficult to find a mainfrane to work on, and I have not yet found an emulator to learn on it.
- exabrial 3y agoCOBOL -> Misses the entire point of a legacy codebase. COBOL is not the problem. The actual problem is the missing knowledge from the engineers the CEO downsized and sent their work overseas. This boils down to three things: 1) figuring out the call patterns 2) figuring out the architecture 3) figuring out the business logic This is also why cowboy coders are dangerous in your organization, while having corporate standards and making your codebase self-consistent (aka "Clean Code") is the most valuable thing you can spend your time on. source: I made a bunch of dollar bills working on Java / EIS COBOL systems that needed to interact at wire speed, while not paying Big Blue for their EIS Gateway Software.