Of course this article on microfocus.com is going to talk about how great Cobol is. Microfocus is one of the major Cobol vendors. That said I had a professor that made lots of retirement money off his Cobol abilities. He laughed and said he made more money fixing his optimizations for Y2K then he did in all the years he was a full-time professional Cobol dev.
COBOL – Still standing the test of time
81–90 of 104 posts
Re: COBOL – Still standing the test of time
#82COBOL is extremely good at what it does. I know of no other language that even approaches it.
* It has a data division which lets you describe nested, repeating, and overlapping data at the byte level with a clear, unambiguous notation.
* Numbers are treated as decimal values (generally) and math is likewise done in decimal, not binary.
* It is profoundly cross-platform. You can take a memory-map from one architecture, slam it to disk, transfer it to another machine with a different architecture, load it into memory, and have perfect fidelity.
What other languages have these properties?
Yes, it is clunky as hell. It is not good for many things. However, for its intended use, it is very good.
Re: COBOL – Still standing the test of time
#83> Cobol remains the language of choice Sigh , those single liner that both illustrate the ignorance and the status of the author. I’m an enterprise architect in banking , 6 month ago I was hired for IT Transformation. My mission was very simple « move the bank the out of mainframe » In 2 weeks or so I presented a Kafka based runtime based with JVM contracts that would enable the bank to perform in a near real-time ma…
> and writing interfaces and top of that piece of crap that can only process data at night or during the weekend. I worked on mainframes and this seems like some deliberate policy not a mainframe limitation. Also your Kafka+Java architecture is unlikely to still be supportable in 2 decades. Will have the same problems with Java and Kafka in the future as you have with Cobol today.
> Also your Kafka+Java architecture is unlikely to still be supportable in 2 decades. Will have the same problems with Java and Kafka in the future as you have with Cobol today.
I doubt that. Java has shown a huge commitment to backward compatibility; you can take code from 20 years ago and run it unmodified today. Kafka is younger but it's also a project that takes compatibility seriously.
Re: COBOL – Still standing the test of time
#84I've always thought that the reason COBOL is still "popular" is that it became an entrenched technology many years ago, and the cost of replacement is high enough (and it works fine doing what it's doing) that no one wants to invest the time and money to replace it's usage. This quote made me pause though, "COBOL remains the preferred choice for systems where application quality and operating cost remain important co…
The sentiment ITT seems to be overly dismissive of the value of a system that can reliably run for decades. How many of the new Kafka systems being stood up today would you realistically expect to still be running in 2061? How reliably do you expect those systems to perform over that 40 year period? The trade offs are quite apparent, but the value these systems provide is perfectly obvious too. I’m not sure I buy the…
> The sentiment ITT seems to be overly dismissive of the value of a system that can reliably run for decades.
In my experience it's a very narrow kind of reliability, where no-one cares whether the calculations are right as long as they're the same ones you've always run, and no-one's ever validated what or why is being calculated or sanity-checked it. Probably one of the vital constants in the system is 10x what it should be because someone made a typo it in 1982, but that's still considered "reliable".
> How many of the new Kafka systems being stood up today would you realistically expect to still be running in 2061? How reliably do you expect those systems to perform over that 40 year period?
If they were babied as much as the COBOL systems (no changes without months of testing, if data comes in in an incompatible format then we preprocess it...) then I'd expect them to last longer. They probably won't be, but if you decided to run the Kafka systems in a reliability-above-all-else way, I bet they'd do it better than the COBOL ones.
Re: COBOL – Still standing the test of time
#85My mother spent much of her career as a COBOL programmer, dating back to the early 80s. She retired in 2015 and quickly got bored. I talked her into accepting part-time contract work, something to keep her busy. She got flooded by recruiters. They all told her the same story: "Big Corp" is nervous because a critical system runs COBOL and the staff that used to support it have all either retired or died. She decided a…
I wonder why those big companies don't hire someone new and train them. I'm sure not everyone is interested in new techs. I for one is very interested in these "boring" techs but it's pretty difficult to train myself on these stuffs.
> I wonder why those big companies don't hire someone new and train them
They don't have enough work to train them on and whatever they have is actually critical enough to need someone experienced.
My partner was hired to be a COBOL programmer right out of college in 2004 & trained to work on AS/400s.
The problem was that everything was a small part of a big project, but you got no experience building a big project over its lifetime to see how it should be done. And on top of it, a lot of things which were "the right way" in 1991 wasn't so great in 2005. So a lot of work was actually bringing the existing work to code before you could do the tiny bit of work which is actually needed.
Re: COBOL – Still standing the test of time
#86I like the commenter on that page disagree with the stats but I would assert that COBOL is still the best business DSL ever written. the whole language is about doing typical business things. Mostevery other language I have used, looked at, is at the primitives level upon which one has to build the functions to make it equivalent to COBOL for writing a simple accounting program. Add to this it's IO is basically just…
Learning a dozen interchangeable ALGOL-family languages doesn't teach you much more than learning one or two. You'd get more out of learning an ML-like language, a Lisp, an array language, something like Prolog...
Re: COBOL – Still standing the test of time
#87> Cobol remains the language of choice Sigh , those single liner that both illustrate the ignorance and the status of the author. I’m an enterprise architect in banking , 6 month ago I was hired for IT Transformation. My mission was very simple « move the bank the out of mainframe » In 2 weeks or so I presented a Kafka based runtime based with JVM contracts that would enable the bank to perform in a near real-time ma…
> When you are reminded that Citibank lost 0.5 Billions because they spent 0$ on their UI, you may start to understand how much corporates world is rotten to its core and why mainframe is still there.
That wasn’t actually on a mainframe or in COBOL, it was an Oracle app (Oracle Forms/Reports, PL/SQL, Java, etc). And, it was a product from an Oracle subsidiary (OFSS), the software itself was not maintained in-house. Although, to complicate the story, that subsidiary was started by Citibank and then sold to Oracle in the mid-2000s.
So Citibank no longer directly controls the decision on whether the UI is updated, now that is up to Oracle. They can encourage Oracle to do that, and decide how quickly to upgrade if/when Oracle delivers it, but Oracle controls the actual UI. Or they could decide to look for a new product to replace it with.
(Disclaimer: former Oracle employee, was peripherally involved with OFSS banking products during my time at Oracle, although I never had anything to do with Citibank, and I never saw this specific banking product either.)
Re: COBOL – Still standing the test of time
#88I've always thought that the reason COBOL is still "popular" is that it became an entrenched technology many years ago, and the cost of replacement is high enough (and it works fine doing what it's doing) that no one wants to invest the time and money to replace it's usage. This quote made me pause though, "COBOL remains the preferred choice for systems where application quality and operating cost remain important co…
I wonder if it's less COBOL itself and more the entire architectural and design-decision stack associated with traditional COBOL software. I'd expect you might see similar concepts with Ada, except those come with security-clearance requirements too.
For example, the entire "mountains of dependencies" mindset feels relatively new. There was a time before .node_modules, Composer and Ruby Gems.
If your codebase is legitimately decades old, your dependencies are either "something we built 100%" or "something we bought/fully licensed and retain 100% control over our copy" Even if you aren't worried about a left-pad incident breaking the entire payroll system, you probably have compliance/audit mandates that are much more easily satisified by saying "here is the master disc that is untouched since the Carter administration".
I'd also expect that the mainframe/batch-processing mindsets have wildly different philosophies on reliability and performance than most consumer services. You can't get away with returning a cutesy animated gorilla and telling people to retry a $7 million B2B payment, or developing elaborate GraphQL-ready chainable APIs when your connected device is a 20-year-old fixed-function terminal with a few dozen kilobytes of working memory.
Now, I'm sure you can build to those same constraints in Python or Node or C# if you want to, but the ecosystem is not really built to support you. There's a lot more move-fast-and-break-stuff.
I've always been conceptually interested in COBOL-- I have that "born too late" mentality; I missed when "you work in the same room as THE COMPUTER" was impressive and you had to wear a labcoat. For me, the problem is how you get started in the sense of "what's the toy problems to even start grasping syntax and build flow." What's the COBOL answer to the "demo to-do list" for web technologies or the "half broken Blackjack game that doesn't actually pay correct odds" everyone wrote in interpreted BASIC in the 1980s? Are there even readily usable toy problems that play well to its strengths?
Re: COBOL – Still standing the test of time
#89Earlier quoted context omitted.
The sentiment ITT seems to be overly dismissive of the value of a system that can reliably run for decades. How many of the new Kafka systems being stood up today would you realistically expect to still be running in 2061? How reliably do you expect those systems to perform over that 40 year period? The trade offs are quite apparent, but the value these systems provide is perfectly obvious too. I’m not sure I buy the…
> The sentiment ITT seems to be overly dismissive of the value of a system that can reliably run for decades. In my experience it's a very narrow kind of reliability, where no-one cares whether the calculations are right as long as they're the same ones you've always run, and no-one's ever validated what or why is being calculated or sanity-checked it. Probably one of the vital constants in the system is 10x what it…
> If they were babied as much as the COBOL systems (no changes without months of testing, if data comes in in an incompatible format then we preprocess it...) then I'd expect them to last longer.
I'm skeptical on a pure hardware basis.
Your classic mainframe was a very expensive piece of kit and outfitted as such. Everything redundant, self-monitoring, and hot swappable. The hardware support and backwards compatibility runs into the decades.
Today we're renting a cloud service, that's made of pig-in-a-poke hardware. Reliable/high availability hardware is simulated with a bunch of disposable instances, at the cost of needing to design systems at the software level to sync and preserve data rather than having it built into the hardware.
I'd be pleasantly surprised if I can snapshot an AWS/Azure/GCP image today, and fire it up in 2041 with no changes. (Hell, we have no assurances they'll be offering native x86-64 hardware in 20 years)
Re: COBOL – Still standing the test of time
#90Earlier quoted context omitted.
> The sentiment ITT seems to be overly dismissive of the value of a system that can reliably run for decades. In my experience it's a very narrow kind of reliability, where no-one cares whether the calculations are right as long as they're the same ones you've always run, and no-one's ever validated what or why is being calculated or sanity-checked it. Probably one of the vital constants in the system is 10x what it…
> If they were babied as much as the COBOL systems (no changes without months of testing, if data comes in in an incompatible format then we preprocess it...) then I'd expect them to last longer. I'm skeptical on a pure hardware basis. Your classic mainframe was a very expensive piece of kit and outfitted as such. Everything redundant, self-monitoring, and hot swappable. The hardware support and backwards compatibili…
> Today we're renting a cloud service, that's made of pig-in-a-poke hardware. Reliable/high availability hardware is simulated with a bunch of disposable instances, at the cost of needing to design systems at the software level to sync and preserve data rather than having it built into the hardware.
Right, but Kafka's already set up to do that. I've worked on Zookeeper clusters that have been continuously up for 10 years - not the individual hardware, but the overall system was continuously available for all that time.
> I'd be pleasantly surprised if I can snapshot an AWS/Azure/GCP image today, and fire it up in 2041 with no changes. (Hell, we have no assurances they'll be offering native x86-64 hardware in 20 years)
We'll be able to emulate them, and even if not, the Kafka stack is all JVM-based, so you don't need x86 to run it.