Should Banks Let Ancient Programming Language COBOL Die? (thenextweb.com) 383
COBOL is a programming language invented by Hopper from 1959 to 1961, and while it is several decades old, it's still largely used by the financial sector, major corporations and part of the federal government. Mar Masson Maack from The Next Web interviews Daniel Doderlein, CEO of Auka, who explains why banks don't have to actively kill COBOL and how they can modernize and "minimize the new platforms' connections to the old systems so that COBOL can be switched out in a safe and cheap manner." From the report: According to [Doderlein], COBOL-based systems still function properly but they're faced with a more human problem: "This extremely critical part of the economic infrastructure of the planet is run on a very old piece of technology -- which in itself is fine -- if it weren't for the fact that the people servicing that technology are a dying race." And Doderlein literally means dying. Despite the fact that three trillion dollars run through COBOL systems every single day they are mostly maintained by retired programming veterans. There are almost no new COBOL programmers available so as retirees start passing away, then so does the maintenance for software written in the ancient programming language. Doderlein says that banks have three options when it comes to deciding how to deal with this emerging crisis. First off, they can simply ignore the problem and hope for the best. Software written in COBOL is still good for some functions, but ignoring the problem won't fix how impractical it is for making new consumer-centric products. Option number two is replacing everything, creating completely new core banking platforms written in more recent programming languages. The downside is that it can cost hundreds of millions and it's highly risky changing the entire system all at once. The third option, however, is the cheapest and probably easiest. Instead of trying to completely revamp the entire system, Doderlein suggests that banks take a closer look at the current consumer problems. Basically, Doderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems.
Why not? (Score:3, Insightful)
Re: (Score:3, Insightful)
Java is far more likely to go the way of the dodo bird than is COBOL. COBOL is well-optimized for business data processing. It's a fine language. What does Java have over it? COBOL is many multitudes easier to learn, code with, read, and modify. Programming languages started getting more complex, harder to learn, and use starting with C++. And OO design and programming has failed in each and every goal for which it was originally proposed. I understand that most modern programmers have learned OO fr
Re: Why not? (Score:3, Insightful)
Cobol is a horrible business language. Unicode? No. Variable sized data fields! no.. Threads? No. Useful libraries? No. Integration with other components? No.
Just because it can add and subtract doesn't make it great.
It just makes it basic.
Re: Why not? (Score:5, Interesting)
Holy shit dude. I'm a vet C++ programmer and the last three years mobile developer for warehousing company. However about a year before my current job, I worked in an exclusive AS400 shop. RPGLE, COBOL, CL, you name, it was still using the stuff from back in the day.
The system was incredibly fragile and had insanely complicated builds with the labyrinth of binding directories, dependencies, the constant service program signature violations. Customers demanded new functionality and the system just had trouble keeping up. Old programmers would code crap like RPG still lacked arrays with abusing subfiles. They'd swear by using numeric indicators versus the new fancy types. Yeah, because IN73 being on tells me that I totally need to refresh the data on the screen. Eventually the company fired all of the RPG/COBOL programmers because they could never keep up with demand. They were short order replaced by an off the shelf solution and any new work was contacted out. I stayed on a few months more because I understood EDI and they needed someone to get that all setup on the new solution. Oh and it was Java based.
Point though, you sound exactly like those old guys. OO over complicates crap and you don't need all that fancy stuff, blah blah blah. I work and coded DDS, SQL, RPG, and COBOL with those people for five years and I knew their mentality was just setting them up for obsolescence.
The tech industry is brutal man and you've got to be a person keenly adept to rapidly adapt or you'll find yourself quickly no longer employed and lacking serious skills to find your next job. Two, besides myself, out of our group of nine found another job. Those two for jobs doing AS400 maintenance, took a pay cut for it, and RPGLE programmer with the State Government, smaller hit to the paycheck than the first guy. The rest of the group have nothing but their retirement savings to dip into. We all lost touch over the years but last I heard two or three more for jobs finally but had to eat the cost of moving elsewhere.
Seriously, the only thing that kept me above water was that I had skills in C++ and Java. And since then I've picked up containers with Linux and node.js plus Python and some big data (Hadoop and shit) just to what I assume is stay current.
That thinking of yours isn't a good kind in this industry. But I get it, when I worked with the AS400 folk, I had just turned 30 and so I was seen as the young whipper snapper etc. I had just left my last job of several years doing C++ and every gray beard (literally) there thought I was there to "think outside the box" and "shift paradigms" and really I was just there to mostly get a paycheck. Learning RPGLE and COBOL was fun but man those old guys they scoffed at any suggestion to get off a green screen or to make their monolith more modular. They would literally say, "stupid hipster just trying to make everything harder than it needs to be." And let me tell you, I didn't dress like a hipster.
Anyway, I know, way more memory lane than anyone asked for, but seriously, those guys' thinking ultimately led to their firing. I've worked in a few development teams but not a lot so can't say with a lot of experience, but my gut tells me that had they been just a wee more open to change and newer technologies, they might still be working at that place.
Re: (Score:3)
What gives you the very incorrect idea that the 'old' clode is single-threaded? IBM mainframes have supported multi-processing since 1965. Current models have up to 120 CPs in one image. And as for performance - there you are WAY out in left field. Many COBOL programs involve decimal operations, and in COBOL that translates to HARDWARE decimal operations. If you think you are going to get anywhere NEAR that performace with Python (snort), I'll have what you're smoking.
Re: (Score:3)
If you learn computing because you want to write a game, or a website, or an application, or manage a database. i.e. if you learn for the reasons that 99.99% of people learn for then COBOL is unsuitable. Any general purpose language would be more suitab
Re: (Score:3)
OO is good for cases where you have use for multiple instances of known items. That is applicable to many solutions but it comes with a cost too. That cost is added overhead caused by inheritance since not every object uses all stuff it inherits, only parts of it - especially when the model is built by many persons that need a very general solution to a problem.
Maintainability is also a problem when you get stuff that's obsoleted - it may be impossible to remove stuff from the parent objects because at leas
COBOL isn't hard to learn (Score:5, Insightful)
COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.
Whoever wrote this article unfortunately appears to subscribe to some bizarre employer-centric view that programmers and CS grads are not allowed to learn programming languages on-the-job. COBOL-coded systems are for back-end processing, not for customer-facing systems.
Re: (Score:3)
Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates. Honestly, if I was ten years younger, I'd probably delve into it myself. It is, after all, just a programming language, and hardly on the same level of trying to learn Sanskrit.
Re:COBOL isn't hard to learn (Score:5, Interesting)
Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates. Honestly, if I was ten years younger, I'd probably delve into it myself. It is, after all, just a programming language, and hardly on the same level of trying to learn Sanskrit.
As long as you have a real fall-back so your career doesn't dead end. What can easily happen is that you do X then more of X because it's the only place you get a salary/career development until you've done X so long nobody will really hire you for anything else. I see this with for example some SAP consultants, essentially SAP customers want to hire you for your SAP experience and the rest of the world doesn't care that you have a general IT degree 5 or 10 years ago because your experience is all SAP-specific and they don't run SAP.
Now they're probably safe since that ERP is burrowed so deep into many companies they'll never get out, but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position. That is if they'll even hire you or if they'd rather have a recent college graduate. Or you might have to relocate to find one of those increasingly rare positions that actually value your COBOL experience, which of course only makes it harder at the next crossroads.
If you write cell phone apps as a hobby and can show them a portfolio or something, maybe you'll get away with it. No, you're not a dinosaur who only knows an outdated language and best practices from 50 years ago. Or some other way to be able to transition away from that COBOL career more smoothly. Some of my older colleagues noted that the parking inspector at work used to be COBOL programmer some 20 years ago, they updated their skillset and apparently he didn't.
Re:COBOL isn't hard to learn (Score:5, Insightful)
COBOL was ubiquitous in the financial industry before SAP's predecessor was someone's dream. COBOL will take 10 years to get rid of *if* all users begin concerted efforts to do so, these transaction processing systems are too important to just 'replace' without careful planning, development, and most importantly defend against feature creep and being engineered into failure.
SAP is a baby. COBOL is grand dad. And grand dad still gets out of bed, does his work, and does it well. There is indeed a market for fresh COBOL programmers, and a decade before they need to move on to a new platform.
In a world where we are cautioned that we will have multiple careers as the job markets change and adapt, it's ludicrous to pretend that programmers can't move on to new languages, new platforms, new challenges. What is being said is "it's cheaper to hire new grads than to hire retrained experienced workers". That is sharp practice. Not nice, but profitable. And not new.
Re: COBOL isn't hard to learn (Score:4, Interesting)
Fretting that banks may have to pay to train software engineers to learn the tongue of their industry instead of getting to pay dirt cheap rates to retirees is very far from tugging at my heart strings.
There are banks and banks. I work at a hundred-year old bank where most of the COBOL programmers are between 30 and 45. The older ones have graduated to team lead, plain management, auditing, cost control, or other (presumably better-paying) posts. There are lots of people recruited out of school to work on COBOL (and Hadoop, and CICS, and Kafka, and OPC/TWS, and NodeJS, and if you only know one in two then you're not cross-platform).
This is good HR. There are people in HR whose job it is to plan out career paths and make sure on one hand that people don't get stuck with only outdated skills, and on the other hand that the bank doesn't get stuck with not enough people competent in a given skillset. If other banks don't have good HR, then I'm sorry for them but it's not my problem.
Yearly pay is not that great, but I have job security, I can go to the beach after work, and if you factor in that I have 56 weekdays off in a year it gets better... and bad pay is probably a consequence of having competent HR too.
Re:COBOL isn't hard to learn (Score:5, Funny)
SAP is more likely to go the way of the dinosaurs than Cobol.
Which reminds me of this joke:
Re:COBOL isn't hard to learn (Score:5, Interesting)
but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position.
You think that a systems migration won't need your legacy skills? You think that you won't pick up the skills for the new system during the migration?
Here's a more likely scenario: you do COBOL for 5 years and learn the entire problem domain that the COBOL system services. When the migration occurs with Java your knowledge will be indispensable, and you'll no doubt learn Java in the two years the migration takes to complete. At the end of the migration, you are still the expert in the problem and have new Java skills to apply your expertise.
It's exceptionally unlikely that the migration from COBOL will be so fast that you won't be able to learn the new implementation technology.
Re:COBOL isn't hard to learn (Score:5, Insightful)
Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates.
Oh, hell no. Universities and computer science departments are not trade schools, and we shouldn't be expecting them to teach any specific technology or language. That is not what the discipline is about. What they should be doing is producing graduates that grok and push the concepts that underlie computing in general. They should have a good grasp of algorithms, object oriented design, logic, and so forth. The language is incidental. A well educated grad should be able to pretty much pick up any language, and view it as simply another syntax, potentially with slightly different grammar. In practical terms, a good CS program is far closer to being an applied discrete mathematics degree, rather than a programming degree.
Re:COBOL isn't hard to learn (Score:4, Interesting)
I went to community college and we had an Associate's track in, basically, mainframe computing. AS/400, JCL, COBOL because we had several local firms that still maintained and ran mainframes (and last I checked, still do. I believe one tried to move to commodity hardware and rewriting the whole stack in Java, but I don't know if they finished that transition).
The problem with "just picking up COBOL" isn't necessarily the language, it's the whole system it's deployed on. There's no CLI that a Linux user would readily recognize (I found it easier to think of it like a BBS), the whole Jobs system is utterly alien to someone used to VAX/UNIX, etc etc. My local college also did a lot of that, but in the MIS department. The EE department started everyone out on VAX/VMS and Pascal, the CS department on C and qedit. :D They moved to Visual Studio not long after, though.
Re:COBOL isn't hard to learn (Score:4, Interesting)
Even if students coming out of a course should grok code in general, that doesn't mean they have discipline-specific skills in COBOL necessary to allow them to deal with this kind of code. Some of that stuff is learned over decades.
It's entirely the bank's fault for not taking on young employees and teaching them these new skills, and putting them with the veteran programmers and guaranteeing their jobs for life, with good pay and conditions. They have no one else to blame.
Had they done this, it wouldn't be a problem. COBOL would just be the language that banks use - nothing else. Banks seem to feel it's the universities responsibility to churn out skills that they might want some day, but without paying either the universities or the graduates ( through employment ) for their services.
They still have time for this - all they need to do is pay enormous amounts to programmers willing to sit with and replace aging veterans. Good luck to them. I hope the banks choke on this.
When I studied, we were forced to learn COBOL for precisely this reason. No one was ever hired, or taken on, or otherwise employed out of it - It was just one of those "Industry want this, so we're teaching this" situations, but the truth is that industry only ever want experienced programmers, but they want them to gain that experience somewhere else.
When we see COBOL programmers paid 1 million per year, like high-flying executives, we'll know they finally realized their value. In the mean time, maybe a few more executives should be prosecuted when they have losses due to COBOL bugs and failures, for running systems they refused to maintain, with foreseeable outcomes.
Re: (Score:2)
An academic degree is about the concepts and pushing the envelope--not specific job training like a vocational school. However, you do need to learn specific programming languages in order to not be detached from reality when dealing with them in theory. Theory gave us OO languages that are many multitudes more complex and harder to maintain than COBOL for the same data processing tasks. That's huge problem for which some background in COBOL might alleviate.
Re: (Score:2)
Oh, hell no. Universities and computer science departments are not trade schools, and we shouldn't be expecting them to teach any specific technology or language.
They should, OTOH, at least make some sort of attempt to teach some vaguely relevant language rather than going out of their way to teach to must useless academic wank they can come up with. The local Uni has taught, over the years, Apple Pascal, Eiffel, Prolog, Haskell, and other similar ones. It's like going through a catalogue of "languages you'll never be able to use in real life and that you'll never be able to get a job with" and drilling them into students. It's no wonder that a local software com
Re:COBOL isn't hard to learn (Score:4, Interesting)
At my college the low level CS classes were taught using Scheme. The idea was to use a language that nobody would ever in their right mind use in the "real world" to teach basic concepts like recursion without the student getting bogged down by implementation details specific to a language. Higher level classes were taught in Java so that we would have experience with a 'real' language. Also, there are some concepts that are nicer to work with in a powerful modern language, rather than shoehorning them in to an obsolete language not designed to support them.
Re:COBOL isn't hard to learn (Score:5, Interesting)
Exactly, if there's a demand for it, it'll be fulfilled. The article reads like something written by some recent CS grad, lets throw out this horribly uncool, unhip code that nevertheless can handle three trillion dollars of transactions a day and has been going for forty years and replace it with something that some Indian subcontractors slapped together using Ruby and MongoDB.
In a past life I worked for a bank. They decided to replace their existing Cobol on IBM big iron with Java on... something that wasn't big iron. After several years work and tens of millions of dollars spent and even more than that lost due to problems with the new, modern replacement systems, they threw in the towel and made their modern system screen-scraped 3270s because that shit just works, and keeps on working. It's now all Windows-based at the front end, but everything in the backend is still Cobol on mainframes.
Re: (Score:2)
COBOL is not your average Algol deriviative !
I'll grant the the 80-20% rule likely applies..
But things like Sequential vs Relative vs Indexed I/O, BCD (packed & zoned), multi-return option on PERFORM, etc...
I'd be more comfortable saying 'mediocre' instead of 'proficient'
Re: (Score:2)
That much is true, but it is tedious as fuck to use as a programming language.
Re: (Score:2, Insightful)
Re: (Score:2)
Only when you try to apply them to problems that are too far removed from their own domain of interest. In my experience, COBOL development is tedious even in the very domain for which it is intended - business oriented programming. You can do everything that you can in COBOL in python, for instance, and the resulting work would be just as readable and far less verbose.
COBOL programs lack elegance... they are the epitome of the saying "everything loo
Re: (Score:2)
But your python app wouldn't be doing millions of transactions a second on a system about as powerful as a mid range server... Nor would it run for the next 40 years given python's tendency to break the language every so often.
Re: (Score:3)
All programming languages are tedious as fuck to use.
Cobol is more tedious than more fuck.
Re:COBOL isn't hard to learn (Score:5, Insightful)
I agree the article's claim is dumb, but not for the reason you suggest. Finding programmers is easy (at least if you're willing to pay a reasonable wage,) and teaching them COBOL is easy as well (any decent programmer should be able to pick up a new language within a week or two.. especially if they're hitting the ground running and have no choice but to learn it.)
The problem is the business logic. Banking isn't particularly simple at the best of times, and all of those ancient systems will have decades worth of hacks built on top of the base logic for whatever corner cases, hardware workarounds and other tweaks that have been needed over the years. A new programmer learning COBOL will have to be wary of those kind of hacks until they understand them. A programmer trying to port the system to another language/system on the other hand will have to understand those hacks all (nearly) at once in order to make sure they properly get replicated.
I don't really see any reason beyond simply "new is better!" to do this. By the time they manage to fully port and test the new system, they'll be wanting to rewrite it again in the next fad-language-of-the-day. I mean name one "top" language today that's been around for more than about 5 years and doesn't already have people crowing about how its past its expiry date and everyone should be rewriting all their code in some other language. There's the occasional specific domain where that happens (C++ for performance-centric applications like games, Fortran for sciency things, Matlab for mathy things and the such) but anything even close to general purpose? Few if any.
Re: (Score:2)
The first question is if the system meets the needs as it exists, and what changes are ultimately needed.
I can see many things with banking today that don't work well in batch mode, but I have no idea how the banks work around that fact. I'm sure there are other examples as well.
Re: (Score:2)
I don't know specifics about what they do, and I'm guessing that would differ from one organization to the next anyway depending on their specific criteria and how clever their designers and programmers are.
But in terms of the COBOL language specifically, keep in mind that its still maintained. The last COBOL spec was released in 2014. That is, new features and paradigms can likely be built on top of existing software by just porting forward to a new compiler rather than switching languages all together.
Re: COBOL isn't hard to learn (Score:4, Informative)
Re:COBOL isn't hard to learn (Score:5, Insightful)
Once, many, many years ago, I had to look at some COBOL software to see how it was handling some data. Remarkably easy to read and I'd never seen the language before or since.
I don't think I'd have the patience to program in COBOL
But I have to say that if I were an IT manager responsible for hundreds of thousands of lines of that stuff that worked, I'd probably be REALLY reticent to scrap it in favor of something more "modern".
Re: (Score:2)
Or is it being driven from the employer, where they need someone experienced in an older language that isn't as popular, but are unwilling to PAY for the experienced person
Re: (Score:2)
COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.
All this may be true but why would they do that when, if they replaced it with something developed in the current century, they would not need to. A delivery company could train it's employees to drive horses and then use horse carts to make local delivery runs but why would they? Well perhaps for a sales gimick but otherwise using old technology often gives significant disadvantages beyond the need to train your employees.
Because it's cheaper.
Re:COBOL isn't hard to learn (Score:4, Insightful)
Referring to banks, not delivery drivers. The delivery company would use vans because it's far more efficient (ie cheaper). The bank would train COBOL devs because it's also much much cheaper than replacing a working system.
Depends on what you count (Score:2)
Because it's cheaper.
That depends on what you count. It might be cheaper in the short term to keep patching together an increasingly obsolete and aging system than to develop a new modern one but if you look at the longer term the higher maintenance costs add up. On top of this there is a lost opportunity cost: you could miss out on new, profitable technologies and methods if you have an older, less flexible system which is why banking innovation seems to be increasingly happening in companies outside the sector e.g. things li
Re:COBOL isn't hard to learn (Score:5, Insightful)
COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.
All this may be true but why would they do that when, if they replaced it with something developed in the current century, they would not need to. A delivery company could train it's employees to drive horses and then use horse carts to make local delivery runs but why would they? Well perhaps for a sales gimick but otherwise using old technology often gives significant disadvantages beyond the need to train your employees.
I've worked in legacy software for a long time... and here's the thing.
Those COBOL systems aren't off-the-shelf modern framework-driven standard software packages. These packages were custom-built and tailored to the business needs of *that particular institution* over many years. You can't plonk down a credit card and buy a replacement; there's no github repository for that kind of code; you can't knock one out in a couple of weekends in a code camp.
That business' processes have co-evolved with that software for better or worse. Replacing it means rebuilding it around the existing business.
The programmers that work with this old cruft know the ins-and-outs of the system -- and if they're smart, they've learned the business, and the business owners *know* they know it. When the business decides to replace it, that's when the developer steps up and says "I'll do it, here's the plan." You go in as Jr. Programmer, you come out as Sr. Software Engineer.
In 30 years I've written (whole or in part) 2 payroll systems, 1 full-financial system (AP, AR, GL, etc..), 1 room scheduling systems, one freight routing system and one tax filing system. Each one (for its time) very modern, but based on older shittier systems that had to be learned and maintained before that.
Re:COBOL isn't hard to learn (Score:4, Informative)
Given that most of this code was originally targeting systems from the 1960's and 70's, I can't imagine there being an insurmountable number of lines of code
According to Wikipedia, Gartner estimated about 200 billion lines of COBOL code in 1997. To put that in perspective, that's more than the total amount of open source C code tracked by OpenHub.net. Can you imagine persuading someone to rewrite all of that C code in a newer language?
No. (Score:5, Insightful)
Er...that's pretty much been the story since the 1990's (if not earlier) on.
>> mostly maintained by retired programming veterans
Er...if they're "maintaining" then they aren't "retired". This whole article sounds companies that whine about not being able to find skilled welders, etc. Well, open your wallet and the talent will materialize - see "IT security" for an example.
Re: (Score:2)
If the average age of your engineers doing the maintaining is 64, then you might as well recognize that you have a problem with retiring programmers.
Re: (Score:2)
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines [wikipedia.org]
Re: (Score:2)
This goes out to all of those complaining about not being able to take more than 3 days off for decades at a time - why in heck are you still working for that employer? I've certainly never had difficulty taking vacations, and I've worked at fortune-5 companies and tiny startups and everything in between. If you are silly enough to stay in a job that is not meeting your requirements when there are so many options that would, you have only yourself to blame. If unfair vacation policies were costing such co
Re: (Score:2)
The last full week I was able to take off was in 1983.
That's your fault.
So, take the opportunity. (Score:3)
Re: (Score:2)
COBOL is not for everything nor for everyone, but it does what it does well.
Few languages make the programmer describe the required input and output in so much detail before coding, which may be why it is well suited to financial systems.
How about a 4th option ? (Score:5, Insightful)
How about a 4th option ?
Fscking pay to train people. If COBOL knowledge means means a good paycheck and job stability - lots of people will want to do that.
I mean hydroponics and grow lights are all the rage now but i hear of no plans of migrating all the existing old-style dirt-based and sun-lighted vegetable gardens to that. Why ? Because people are still learning how to dig the dirt out in the sun.
BUGS (Score:4, Informative)
Re:BUGS (Score:5, Interesting)
COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain. With Banks, accountability is more important than functionality.
Said the person with very little knowledge of modern COBOL environments !
I'll grant that COBOL is not like PL/I, where 80% of the programmers know = 20% of the language.
However, COBOL has one of the richest I/O layers (ok, on par with PL/I) around.
Caveat Emptor - I intensely dislike the language (to damned verbose), but it and PL/I do pay fund my paycheck (just call me 'Dinosour Bob'). ... And Databases where not yet relational !
But the COBOL I learned was circa 1970s, when even COMPUTE was frowned upon (in school)
Modern COBOL has OO patterns, JNI integration, XML/JSON tooling, ... All to deal with the option of: ...)
* Keep the business logic in COBOL
* Provide the ability to work with newer toolchains (Java, XML, JSON,
So there is interoperability betwixt the green-screen and non-green-screen luser.
Re: (Score:2)
COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain.
That is the theory. The fact is, because even trivial things are awkward to do in Cobol, every Cobol program that lives more than a year promptly turns into a gigantic mind sucking unmaintainable pile of toxic sludge.
What is needed.. (Score:2)
..is a way to translate the old COBOL programs into a language-neutral specification that captures all of the business logic and edge cases that the old code handled
Then, a way to translate that specification into an appropriate modern language
Sounds like an interesting and lucrative research proposal
Re:What is needed.. (Score:5, Informative)
(FYI, the company is Asysco [asysco.com])
Re: What is needed.. (Score:5, Informative)
Absolutely wrong. One of the language's biggest selling point when it was first created is the source code is completely hardware agnostic. To demonstrate this, the developers compiled the same program (from the same deck of punched cards) on three different brands of computer, ran the program with the same deck of input data and got the exact same results. The only change they had to make was one card in the Environment Section, and all that card did was specify the target machine.
Re: (Score:2)
Cobal is a crazy nuanced language that is hardware specific.
Where in the world did you hear that? I'll admit that most production implementations using it today are usually AS/400 and Z-Series, but there are plenty of other operating systems that support it:
https://www.gtsoftware.com/net... [gtsoftware.com]
http://opencobolide.readthedoc... [readthedocs.io]
https://en.wikipedia.org/wiki/... [wikipedia.org]
https://www.microfocus.com/pro... [microfocus.com]
Re:What is needed.. (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
I'm learning micro APL on a Commodore Super-PET 9000 as a hobby. Unfortunately, I don't have access to an IBM mainframe at the moment.
It will probably never die (Score:5, Interesting)
Having spent quite a bit of time over the last two years to re-implement in Java a system developed by the government in COBOL, I can tell you that COBOL will probably never die. For example, keeping precise, penny-perfect calculations of dollar amounts in Java is actually quite a pain. This is especially true when the calculations involve dozens of hundreds of steps. My solution in Java has been based around BigDecimal, which makes the code very difficult to read. Aside from that, I have spent the vast majority of the time writing very extensive tests and chasing down really small numeric discrepancies. Guess what, if you decide to replace a COBOL system that does any appreciable amount of math, you would get to do the same thing. Plus, you will never be sure that you found all the bugs.
The project actually considered the possibility of licensing a commercial Cobol runtime for PC-based platforms (e.g., Windows, Linux, etc.), but that was not feasible for several reasons.
COBOL is still remarkably good at quite a few things and leaves out lots of the bells and whistles that tend to become distractions in the hands of undisciplined programmers. My only complaint about COBOL (especially old COBOL) is that the control flow is a real pain. Aside from that, it is definitely a workhorse of a language. No need to go killing it off yet.
Three trillion a day, you say? (Score:3)
Sounds like it might be worth training some new programmers.
You can re-write any or all of your legacy systems in modern languages (if you choose to undertake the cost and risk, of course), but one day they won't be modern any more, and there will be new modern languages, all with their advocates shouting about pieces of the sky falling.
Or you can leave these highly reliable core systems in place and suck up the cost of training new maintainers, and deal with the cost and problems of interfacing them with a "customer-centric" model. Of course, you may have to offer incentives to induce young programmers to use something that's not hip and modern, i.e. $$$
So customers can already do a lot of the work that used to employ bank tellers, billing/accounts staff, and travel agents. None of which changes the fact that "customer-centric" does not and never will have direct access to the core systems. Who cares if the back-end runs COBOL-sourced object code on a mainframe? Methinks people who advocate for C## and Java in core systems have no concept of core systems and their workflows.
So train the next generation of COBOL programmers (Score:4, Insightful)
Challenge accepted (Score:2)
Re: (Score:2)
That's an awesome way to get your foot in the door, but you'll cringe when you first have to debug a piece of 50-year old code that is poorly documented and written by someone long since retired or dead. :-)
This isn't a swipe at COBOL though; this could be true of any language.
Automatic Conversion (Score:2, Insightful)
It's been a while since I've touched COBOL, but it should be possible to develop a program that parses COBOL and outputs the equivalent in a modern language, even preserving the comments.
Since financial institutions seem to be completely unaware that programmers can quickly adapt to different languages, it would seem like an automatic conversion program could be quite profitable.
COBOL programmers aren't all old (Score:2)
There's a COBOL shop in my small town that contracts for corporations and the government. I know several COBOL specialists in their 30s. It's actually an extremely lucrative field to get into these days, with good pay and job security.
Rewriting all that COBOL code in some other language would be bound to cause major problems.
My brother and I were talking about this (Score:2)
Hopper? No. She's the grandmother of COBOL (Score:4, Informative)
Grace Hopper did not invent COBOL. Follow your own links - there is a whole list of who designed it, and none of them are Grace Hopper. She did lay lots of the foundations they worked upon of course.
To the question of should they replace it? About the same time as any other language should be replaced - it is a very silly question...
Re: (Score:3)
COBOL was ultimately designed by a committee, but Grace's early compilers had a lot of influence on the language design.
The military and other organizations found it difficult to build financial, logistics, and administrative software for multiple machines that each speak a different language, and thus formed a joint committee to create a common language. (Science and research institutions had FORTRAN for cross compatibility.)
Basically the COBOL committee grew sour with disa
Rule Number One (Score:2)
If it ain't broke, don't fix it.
Or use in-house education (Score:5, Interesting)
2 years ago in one of the banking centers in Denmark 12 new IT-candidate were educated in ... COBOL, CICS, mainframes, etc. The older generation were anxious about how the younglings adapt, but it appears it turned out well. They were excited about the robustness and scalability of the mainframes, not so much about COBOL, but could see it didn't make business sense to rewrite old software. New software is being developed in more modern programming languages.
source (Danish only): https://www.version2.dk/artike... [version2.dk]
Re: (Score:3)
Why is that a surprise? If people could master COBOL 50 years ago, why would they not be able to master it today?
Might be a hard sell to banks (Score:2)
This reminds me of something I heard years ago, which I wouldn't at all be surprised is still true: that there are systems at 'the phone company' (I assume they meant AT&T?) that have been sitting there for decades, running the whole time, that nobody even knows what it actually does anymore, but they do know that Bad Things happen if it stops working -- but all they can do whe
The answer is YES... YES ... YES (Score:2)
Give them hefty salaries (Score:3)
Should Banks Let COBOL Die? (Score:3)
Let's all jump on the current language of the week. It's of course preoptimized for Big Iron CPUs and IBM DB2 or Oracle databases. We'll write everything over again from scratch using the original business documentation (because who can read COBOL? -- that's the problem!) and this time Do It Exactly Right.
Those losers from decades ago just didn't know what they were doing at all. Stupideos.
And then: the month-after-next comes along.
And for those still running batch systems... (Score:2)
Re: (Score:2)
A colleague of mine in the 80's once said.... (Score:2)
Don't let COBOL die... (Score:2)
RH issue is a programming issue now? (Score:2)
Lets rewrite billions of lines of code and systems worldwide because we can not afford to hire COBOL devs (or make it attractive to other devs).
Oh, wait...
Let the invisible free hand of he market decide (Score:3)
No, please, don't (Score:2)
I have every intention of spending the twilight years of my career working on ancient systems for a huge premium, so I say keep it around for the rest of us.
Learning new language can be done quickly (Score:2)
as others have said here, its not at all hard to learn the language and many of us have. With the unemployment problems we have with american tech workers and the unemployment problem we have in the country (unlike the official statistics, the real number is more like 10-15% because people who have given up are not counted), its hard to argue that you cannot develop and train workers to work on this technology.
About 90% of learning the job is learning the *application specific* layout of the program, learni
Citibank Ad (Score:2)
They need to fix it, but they can't find any COBOL programmers! Doh!
I work with a former COBOL programmer (Score:3)
And he's a tedious pain in the A$$. Self-righteous, gloating over the shortcomings of the current crop of apps, reveling in the agony of the kids struggling to release even the most minimal upgrade without 3 fast followers and a deferred feature request until they get enough points banked to figure out something new. He loves their failures.
And our COBOL systems do hum along.
We spent $2 Billion over 7 years on a new core processing platform, written in something 'modern'. It was hell. And it is one of 7 core processes. We are now working on using 'Big Data' to replace another core platform, and I swear they feed it quarters to keep it running - yes, we abandoned Hadoop, but Cassandra isn't much better for my app, we never get the resources we need, and as they convert even these relatively simple apps, we go through a cycle of redesign/minimal deployment/discover massive problems/rewrite/deploy minimal features/add in necessary features/discover problems with all supporting systems/implement error handling and alerts/re-budget to accommodate the real cost/start a new feature cycle... Fortunately we measure most of these events in single-digit months instead of single-digit years. Good bye Websphere, we hardly loved ya.
COBOL need not be replaced for core, transaction-bases systems, but the pressure is enormous. For financial institutions, being able to count on reconciling cash flows reliably cannot be overvalued. Some stuff just has to work. It doesn't have to be 'modern', whatever the hell that means, it just has to work.
CSS in COBOL? (Score:2)
Is it possible to do CSS in COBOL?
I think someone might have tried.
Just pay enough. (Score:5, Interesting)
I remember this coming came up during the Y2K flap. COBOL programmers are dying out because companies have decided, for whatever reason, that they aren't willing to pay them much. A quick Google search--I don't know how reliable--shows me:
COBOL Sr. Software Engineer / Developer / Programmer $88,049
Java Sr. Software Engineer / Developer / Programmer $103,239
But that understates the difference because the various job titles shown for COBOL positions are predominantly lower-sounding and lower-paid positions.
As several have said, COBOL isn't hard to learn--I don't know it but I crammed it once for a test. Like all languages it takes a while to get good at it, but it's not specially difficult, nor is it specially bad.
The best strategy would be to render unto COBOL what is COBOL's--keep good legacy systems in COBOL--and pay enough to give people a reason to learn the language.
No. (Score:2)
Betteridge's law notwithstanding, the next question will be what to replace it with. And the attempts to answer that will devolve into a clusterfsck of trendy languages du jour. And by the time some poor bank has funded the effort to port to something, that something's advocates will have moved on and the replacements will claim that the choice was all wrong and divert the effort to their new favorite.
Language (Score:3)
Why does the language matter?
I have to learn all kinds of new, esoteric and niche languages all the time as part of my job.
Surely what you want is to hire a business or banking programmer and make sure they are then made competent in COBOL (gosh, maybe you could utilise your ageing COBOL workforce to teach him?), no different to bringing in a guy trained on a competitor's system and training him on YOUR system.
It worries me that a bank would be hiring a programmer who *can't* do several languages, especially languages that have been around for decades rather than languages utilising entirely different paradigms, or that can't pick up new ones as they appear.
If you hire some - I don't know, whatever the language of the moment is, say Java or something - programmer to replace all this system, you'll have a system tied into Java. Which will, as Java is starting to show, start to get replaced itself by the time that guy has gone and you've only got rookies running the place on the old-guy's code.
Massive expense, to be back to square one, after decades of dodgy code that was trying to stabilise.
Advertise for programmers, teach them COBOL as the "in-house" language. Then, so long as your business systems have the tools for them to create and execute those programs, you're sorted for a long time yet. You don't even need to care that every other bank in the world has moved to Java or whatever if you do it right and have standardised interfaces or conversion tools.
I think this is not related to "we can't find people who could program in COBOL" as much as "we already have a bunch of cheap outsourced programmers who only know Java and they can't learn anything else".
The time taken to familiarise yourself with such a critical codebase to the point of confidence in pushing your production code should VASTLY outweigh the time required to actually learn something like COBOL from scratch, in this kind of industry.
Re: (Score:2)
Re: (Score:2)
They are learning COBAL. The problem is the language is COBOL. Programmers should learn Hexadecimal and Binary (machine level code) and then go into application layer programming from there, but that is neither cool or trendy.
AFAIK there are still no viruses on MVS & VM systems. TPF and CICS still function wonderfully there is just a huge price to get into the game with a mainframe system vs. PC/minicomputers.
Re: (Score:2)
I was replying to an AC that referred to the language as COBAL, hence the intended misspelling.
I worked for a large financial corporation starting with peripheral operations on punch card readers, and microfiche printers long ago. I've worked with removable platter DASD, on DEC PDP-11/70's through Tandem Himalaya machines, then into Unix and Solaris on SUN and Cray hardware. It sounds like we have similar backgrounds. I did mention that there was huge price to just get into the game at the mainframe
Re: (Score:2)
The latter - it's cheaper. We just re-up'ed our IBM contract for another 2 years.
Re: (Score:2)
"Of course then ... then we get to JCL ... If you don't know what that is, imagine a scripting language in which spaces matter ..."
That would be bash -- or any other Unix shell script. However, I have to say that even at its most perverse, bash doesn't begin to approach JCL for pointless peculiarity. e.g. IEFBR14
Re: (Score:3)
Re: (Score:2)
Re: Translate COBOL to other languages? (Score:2)
The fundamental problem with auto-translating COBOL into something like C(++) or Java is the fact that the resulting code might be semantically-valid C(++) or Java that successfully compiles & runs, but it would probably be almost impossible for humans to make sense of, let alone safely modify in the future.
Re: (Score:3)
Re: (Score:2)
If Java, Python, and C support decimal operations, then why are a class, a module, or a library required? COBOL, on the other hand, directly supports decimal numbers. Two fixed point numbers can be read in, then operated on directly, then written out with no conversions. And the operations (add, subtract, multiply, divide, format, etc) are done with a single machine instruction (on a mainframe).
Re: (Score:2)
Re: (Score:2)
Huh? You can do binary integer and floating point arithmetic in any of those languages without any libraries, classes, or modules. You can only do decimal operations in those languages by either converting the decimal numbers to binary, operating on them, and converting back or by calling something written in a different language. Hiding those things elsewhere does not magically mean that the language supports decimal.
Re: (Score:2)