And while headlines might indicate the language had fallen into disfavor, the amount of COBOL in use continues to grow, with 800 billion lines running in production systems daily, according to a global survey conducted last year by enterprise software firm Micro Focus. COBOL is considered strategic by 92% of survey respondents, and over half said they expect their organizations to keep running their COBOL applications for at least another 10 years.
I feel like COBOL is one of those things that can guarantee you a career. If you know COBOL, you will most likely find a job and have a good career future, but it’s probably not going to be anything sexy or anything that has the (albeit tiny) opportunity of making you filthy rich – but you won’t ever be without a job for long either.
I’ve worked with some of these old school mainframes in the government sector. On the one hand few candidates out of university are learning mainframes, which obviously limits the competition. But on the other hand it’s so niche and mainframe skills are not broadly marketable for typical tech employers. It’s mostly greybeards maintaining existing projects. Some of them have to end up retooling and applying to conventional tech jobs say when the government contracts dry up. The goal of every mainframe contract I’ve worked on was to modernize and gradually transition away from the mainframe. There may be some investing in more cobal, but I honestly think that’s the exception rather than the norm.
But what about running COBOL outside mainframes?
jgfenix,
I’ve never seen that, but may as well ask if anyone else here has?
Edit: I know some government departments migrating to java.
I have read that COBOL is difficult to replace because it uses fixed point arithmetic and binary coded decimals natively. You don’t want rounding errors when dealing with cash so using Java or another languages is problematic.
jgfenix,
It depend on if the language supports fixed point arithmetic. This is absolutely trivial in C++ due to operator overloading. It’s easy enough to implement in other OOP languages too but without syntactic sugar it’s a bit less clean…
https://github.com/tools4j/decimal4j
Databases like mysql handle fixed point numbers and arithmetic fine.
For a little bit of trivia; many mainframe applications actually store numbers, dates and whatnot as EBCDIC text characters. They’re not actually stored as numbers at all. Furthermore due to the way VSAM files sort records, you’ll often see applications storing those text values as 1’s compliment. For example 2000 and 2023 might be 7999 and 7976 in order to sort the numbers (aka text) backwards. This text representation is generally why the “year 2000 problem” was so prevalent in mainframes. Systems using binary representations typically roll over at completely different dates.
https://en.wikipedia.org/wiki/Year_2038_problem
Well I know of one company that might do it in the US Car industry (their software occasionally generates “Cobol back end” errors). They lease servers for 15 years and the contract auto-renews if you don’t cancel it exactly on renewal day by phone, basically making it near impossible to get out. The actual product is terrible, and they seem incompetent at even programming it to do the things they want. It’s not unheard of outside of mainframe, but it’s definitely more of a sunk cost/terrible company thing to see. Whether it’s on mainframe or something else seems far less important than where you can live while specializing in Cobol; you’d be limited to the handful of places to still using it.
dark2,
I run the risk of overgeneralizing here, but “sunk cost” perfectly describes why many mainframe shops have continued using mainframes for so long. It might be holding them back like an anchor, but they want to believe they’re holding an asset for all the money that they’ve already paid over so many years.
I saw an interesting clip blaming ancient mainframe tech for some of the major outages being experienced by southwest airlines and having to cancel thousands of flights during peek periods. Even flights that would have been fine have to be canceled because legacy systems are having trouble running in a timely fashion.
“The Airline Industry’s Problem with Absolutely Ancient IT”
https://www.youtube.com/watch?v=1-m_Jjse-cs
It’s funny to think that we all use modern apps and websites to book and manage flights, but they are communicating with ancient mainframes systems on the back end. I can imagine a lot of these airlines want to replace these systems & APIs with something more modern, but at the same time legacy systems are the backbone holding hundreds/thousands of systems together and it’s tough to replace any tech that has become a deep rooted defacto standard. I’ve been involved in some large migrations (although not as big as the airline industry, haha) and I can attest it can get very complicated quickly.
To be fair, half of that video is BS. The reason airlines use an antiquated system to communicate available seats to each other is that getting major players to communicate play ball with each other (especially in this age of cutthroat competition and ticket purchases routed through company websites to increase “ancillary income opportunities”) is hard, so the old system is something everyone agrees on. The other half of the video does make a point.
kurkosdr,
Yes, it’s what I meant by antiquated systems being the backbone. Even if some airlines have the motivation and means to migrate to a new network, the entire industry has to do it in unison. The level of investment and coordination needed to replace something like that is insane and the statistical odds of it happening without a glitch are almost nil.
I think that, given the challenges, the best software engineering approach could be build and deploy the new system and simultaneously provide users a proxy that transparently converts requests to give existing airline systems access to the new network while airlines plan their own conversions at their own pace.
This would mean any new features (like those in the video) may not be available everywhere on day 1, but at least there’s a viable path for eventual support. However the video brings up another point, which is that airlines may not be particularly motivated to help consumers with cross carrier booking in the first place. So there may actually be an incentive to resist an improved network or experience 🙁