COBOL: Thinking about it wrong
gcn.com
gcn.com
COBOL seems to be a straightforward language by modern standards. Any programmer with experience with imperative languages should be able to pick it up. Learning the language itself cannot be a real barrier.
The barrier seems to be the enormous amount of legacy code that has to be digested and understood. But wouldn't that barrier be pretty much the same regardless of the programming language. I mean, if it were 800 billion lines of Perl code, would that make the problem any easier?
So isn't the real problem that we have 800 billion lines of legacy code that needs to be understood and maintained; it just happens to be written in COBOL?
However, in my company (insurance) we have 3 COBOL systems (thanks to mergers) and one is on a rapid track for decommissioning not because it is COBOL, but because it is COBOL written in an obscure framework that was never popular and also coded in a non-English language, requiring knowledge of that language to understand the business logic. We can outsource some mainframe maintenance but not that one. The other mainframes will be around for at least the next 10/15 years.
Even today, you can grab Gnu COBOL and learn the language.
What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to learn it, as far as I know.
This could be what you mean, but isn't the problem here one of access? I know just enough about JCL, CICS, etc to be dangerous, and never found any of the mainframe systems to be that difficult to learn (it's all basically batching, queueing, scheduling...) but without access to a mainframe, it's kind of a non-starter to actually get hands-on with any of this stuff. IE: thanks to the multi-decade shift to open source, we've got generations that have that skill set because it was accessible.
I get that 40 years ago it made sense for a bank processing thousands of transactions per day to have a big computer to do that.
But today that could be done on a laptop with a Python script. Has the compute needs really grown proportional to the speedup of the hardware?
I never learned Cobol, but I learned programming in the 90's on the AS/400 where Cobol and RPG were the primary 2 languages. I obviously used RPG. They are both easy to learn and powerful for what they were meant for but they are also commonly used to create massively monolithic programs where massive transaction programs are all written in a single file or with a lot of "copybooks". It makes it a lot harder to reason in your head what is going on as well as the side effects. Things like unit tests are just non-existent so it is just difficult to make changes because of the potential consequences. Especially when these monoliths are handling such important data.
We wrote our RPG in a very API driven fashion where we avoided monoliths. I think you pay a small performance penalty for this but it always made our code easier to maintain.
Of course it also takes a very long time to compile these programs so the Edit/Compile/Debug cycle is not fun or productive.
and yeah legacy code of really sauron like
Specifically the snippets I've seen do some in-line SQL to get its data, some business logic and then updates. The logic is rarely in a procedure that takes parameters, because that doubles the number of lines of code you need. So the only way to test it is to bring up a database, insert some test data, assert and clean up the database again. Which is a lot harder since "insert some test data" gets complicated because of different constraints and triggers etc. Then running it regularly is harder than it should, there's no SQLite equivalent database so you typically need to run it on a mainframe etc.
I've worked on replacing a piece of functionality from COBOL to Java, and I was working from the business requirements that was basically a large spreadsheet of conditions and results. E.g. if age > 67 and not retired but have more than 3 kids, etc then this value. The code I wrote was gnarly because of all the combinations of different conditions, nested ifs 3-4 layers etc. And then there was ambiguity if multiple conditions hit, which one took precedence. I asked if I could look at the equivalent COBOL and the actual logic was about 10 lines long (not including headers, comments etc). Wish I had seen that before I started coding. It was quite readable and well commented too. So the actual language isn't _bad_, but the lack of tooling around it is severely lacking.
No.
800 billion lines of COBOL = 1 million lines of BASIC
A gross exaggeration, of course, but after 7 years of COBOL, I discovered BASIC and instantly became 10X of my former self.
I would never go back. I get enough overhead from my bosses. I don't need it from the tech too.
'You should do it, man!' Yeah, sure. I'd already suffered through the liquidation of my entire department in 2018, the prospect of the heat around COBOL dying down and facing that once again with the additional stain of 'oh, what've you been doing? Cool, popular JS frameworks? No, COBOL? Pass.' on my CV during my next round of interviews didn't seem at all appealing.
That mentality should set the expectation for anyone looking into a COBOL job. It's not just this job, it's the next one.
That's pretty much the last thing that I'd worry about. A company that evaluates potential hires that way is not a company that's worth working for, in my opinion. And most companies I've encountered wouldn't think that way.
However once you are outside of the SV bubble you will notice a lot of companies dismiss candidates based on their tech stack. The only time I’ve ever seen an inexperienced tech stack hire is from personal referrals from someone already working at said company.
My experience is entirely outside the SV crowd.
Cobol ain't going away anytime soon, but it certainly might limit what jobs you can get other places depending on the hiring algorithm.
Company I work for still uses AS400, which has been released in 1988 just after I was born. We have a dev who supports it. This isn't a small company either.
COSTCO is still using and a lot of huge organizations.
I'm focused on newer tech C#, .NET, Blazor but I do interact with DB2 database which is the backbone of that old system.
At one of my interviews somewhere I mentioned that a lot of apps I'm writing are just extending AS400 and the dude interviewing me was really hyped up. He has spent a lot of time with the green screen in his younger years. The job had nothing to do with AS400, but that conversation got me an easy offer.
What I'm getting at is that you aren't going to find a ton of jobs where you are working on COBOL but somehow avoiding Java when the two are connected at the hip on the platforms they are used on.
Anyone who knows anything about COBOL knows that there’s rarely such a thing as “only COBOL”. The majority of the remaining COBOL shops are IBM mainframe, which means it isn’t just COBOL-CICS, JCL, VSAM, IMS, DB2, TSO, ISPF are all in the mix as well (maybe not all of them at the one site). And if you aren’t doing it on an IBM mainframe, it is probably deeply integrated into some other platform - e.g. PeopleSoft still uses COBOL for some of its batch jobs (especially payroll), and while I’ve never looked at its COBOL code, I’m sure it isn’t vanilla COBOL either, it has some PeopleSoft specific calls in it. Or maybe you are doing Oracle Pro*COBOL (SQL precompiler for the Oracle RDBMS). It’s really no different than Java - who does “just Java”, as opposed to J2EE or Spring or whatever?
From what I know, considering it's not "just" banks but pretty much any long running financial business (IE insurance companies), I believe it's one of the most used but least talked about technologies out there.
It was pretty fascinating to see how it all came together. Also despite the languages age after analyzing it for a length of time it was clearly elegant for that type of financial processing.
We live in a world where many of the software languages we use really do matter. If all Ruby interpreters disappeared overnight it would cause global havoc. Real panic. Trillions of dollars of damage.
But because we've learned to rely on these languages continued existence we can undervalue any one of them, including COBOL. I don't because I've thought about it and concluded that we're essentially building on things akin to writing or mathematics. Our building blocks are vital, even if they're easy to take for granted.
The web site might be JS, but actually booking the seat is in all likelihood going through PARS/IPARS. Which runs on an IBM mainframe.
If you are always chasing the latest language and get high on syntactic sugar, you are likely going to be a problem for management if you work at an IT shop because you'll be writing important one-off programs in various languages that people after you will be required to support or rewrite.
John Carmack wanted to hire only C++ devs when he was at Oculus but had to relent and hire JavaScipt bros because of Meta.
TCO isn't just a question on your business class exam.
My conclusion was, if ever I want to do business data (transaction) processing, I'll learn it.
I also programmed a mainframe, with JCL on punch cards, in assembler and PL/1, in college; I'm glad I did; without that experience it might be hard to appreciate how radical and revolutionary unix was.
And yeah, she still gets offers for consulting work, but she wants no part of it. She's done working.
You know you're in trouble when "There's a syntax file for VSCode." is the height of your modernity.
All of it. GNU Cobol exists, as do proprietary solutions from companies like Micro Focus that target the JVM and .NET (which is what you're looking for for a real COBOL solution).
But why is it so important to run COBOL on Ubuntu? If you need Linux, create a Linux LPAR on your mainframe.
> What's the package manager for OSS packages?
COBOL code runs Western civilization. Not having muh NPM is a feature, not a bug.
> You know you're in trouble when "There's a syntax file for VSCode." is the height of your modernity.
Dude. COBOL has entire modern IDEs written for it.
I think IBM would disagree with you, given how much they've pushed Linux (and, therefore, Linux web servers running Node and kin) on their mainframes. You won't be installing much of anything like that on a midrange system, but Linux on Z is pretty well established.
Anyway those environments are downright sclerotic (the worst thing about working with COBOL that nobody mentions). They didn't even let me install Firefox on my work laptop. They had people doing web dev, obviously, but the mainframe teams were more, let's say, conservative.
I am, but I don't think your point is a bad thing- especially if it means less javascript :)
Or use the super secret hidden unix mode.
(and get stuck in an ed prompt. Fun times ?).
The easiest way to get z/OS install media is to sign up for zPDT – it costs many thousands, but still a lot cheaper than what IBM charges for z/OS for an actual physical mainframe – and then you get the the ADCD media with that. The problem is, starting with z/OS 1.15, IBM began encrypting the ADCD media. As part of the installation, the media is decrypted, using the key on the hardware dongle – but the decrypted copy is watermarked with the dongle ID, meaning that IBM can trace back any leak to the individual customer responsible for it. This means people are no longer willing to publicly share ADCD media, although I've heard rumours of some people passing it around privately, only to trusted individuals. Someone could reverse-engineer the watermarking and remove it, but I'm not aware anybody has done that–I think people would still worry, what if they failed to completely understand the watermarking, and hence some of it survived?
Never got it installed, but yeah, it's easy enough to find.
Reliability - most large-scale Linux systems are based on a distributed model - the app runs on a cluster containing dozens/hundreds/thousands of servers, if a single server has a hardware fault, the app just keeps on working and at worst some user might get an error which goes away if they retry. So, no point in spending $$$$ to maximise the reliability of any individual node.
By contrast, many mainframe customers have just one mainframe, and if it breaks they go down - which means the mainframe hardware has to be super-reliable, filled with redundancy, error detection/recovery, etc - and you pay $$$$ for all that redundancy.
IBM mainframes can be clustered - e.g. z/OS Parallel Sysplex - but only the largest sites do that. The maximum supported cluster size is 32 - I wonder if anyone actually runs one that big, 32 mainframes would be horrendously expensive - while Linux clusters with hundreds or thousands of nodes are quite common.
In fact the very first visual compile/debug environment was written in COBOL over 40 years ago: Micro Focus's Animator (from which Microsoft paid to use the patents in their Visual products iirc).
I’m pretty bullish about the importance of COBOL, but while I have a lot of respect for the people working with it right now, it’s not something I’d recommend to someone at the start of their career.
https://gnucobol.sourceforge.io/faq/index.html
> GnuCOBOL implements a substantial part of the COBOL 85, COBOL 2002, COBOL 2014 and upcoming COBOL 202x standards, as well as many extensions from existing COBOL compilers.
It's also in the Ubuntu package repos, from a quick check.
The GCC Cobol aspirant recently gained compliance with Cobol-85
https://lwn.net/Articles/922951/
There is active Free Software development on Cobol tools.
COBOL is designed for handling well formed input data, process them, and then return well formed output to the next step in the chain (on the mainframes this is coordinated by JCL but I'm not sure how you do it on Linux).
It’s part of the fabric of our society, but it’s still a pain to work with.
That being said, I feel that the article made very weak arguments so I don't blame anyone for perpetuating the stereotypes. These are things such as mentioning which industries it is used in, but not being specific as to how it is used (which is important since COBOL seems to be a domain specific language) and relying upon authority when claiming it is modern.
I distinctly remember at the time really enjoying learning to code in it - it spoke to my logical-thinking (but quite young) brain a lot.
However, after college, for whatever reason I didn't use that COBOL knowledge at all. If only I knew then what I know today - that COBOL is still somewhat in demand and that if only I kept in with it over the years, I could quite probably have made quite a good living from it.
Young me was quite naive and silly ;)
Back in the day, memory was very small, and hard disks were unavailable or very limited in capacity, so many COBOL programs used tapes as input, output, and temporary storage. OPEN INPUT REVERSED meant you could write out a temporary file to a tape, close it, and then immediately re-open it to start reading it back in (albeit backwards), without having to wait for the tape to rewind in between. It was particularly used to speed up external sorting algorithms (although those were more commonly done in assembler than COBOL, to maximise efficiency)
For application details, see Knuth volume 3 [2], which even has a fold-out chart illustrating tape (and tape operator) movements involved in various sorting algorithms[3].
In brief, reading backwards allows you to use tape as a stack.
[1] https://www.ibm.com/support/pages/system/files/inline-files/...
[2] https://archive.org/details/B-001-001-250/page/299/mode/1up
[3] https://archive.org/details/B-001-001-250/page/n356/mode/1up
COBOL was not the issue, it was all the "webizied" front end developed for people to use via a browser that had the issues. A couple of articles came out with details that, as usual, the mainstream press ignored.
Somewhere early in my career, I worked with an accounting app that thought a double float is good enough for a ledger. It was not. We spent too much time trying to track down discrepancies when closing the book for the year, only to find out that a double float is not precise enough for bookkeeping. Lesson learned.
Maybe that was true 20 years ago.
https://medium.com/the-technical-archaeologist/is-cobol-hold...
> Overall we assume that the reason so much of civil society runs on COBOL is a combination of inertia and shortsightedness.
Well, there's more to it. Unfortunately, the better a programming language is, the easier it is to understand, change and also replace code.
And in reverse, a bad language is therefore harder to replace and more likely to stay.
Mind that I'm not saying that cobol is bad or was a bad choice. This is really a general thing, but I believe it applies to cobol at the current time.
* Is a type in the standard library "baked in"? I lean towards no, but I'll give the language A for effort anyway.
1) Python - added to the standard library in 2003.
2) C - no.
3) Java - BigDecimal in the standard library.
4) C++ - no.
5) C# - built in.
6) VB - Currency type kinda does what you'd want, but doesn't scale down very far.
7) Javascript - no. (Use https://github.com/MikeMcl/bignumber.js)
8) SQL - Yes. But check your dialect.
9) PHP - No.
10) Go - No. (Use https://pkg.go.dev/github.com/shopspring/decimal)That's a fact. A couple of years ago, I had to brush off my JCL skills for a job. It reminded me of why I was so happy when I didn't have to use JCL anymore.
2) only opinion no meat
3) paper pointed to is a one pager with stats incl. numbers from stackoverflow
Not saying that there is not an argument to be made that the Cobol/Mainfram approach has it advantages. It is a straight jacket but some applications are really efficient compared with what is done these days.
https://www.zdnet.com/article/cobol-grace-hoppers-gift-to-th...
That goal a flop, so programmers had to take over.
Wasn't there a Cucumber/Gherkin story here really recently? That grew out of Fit/Fitnesse (from Ward Cunningham of "tech debt" and "the wiki" fame), which was intended to have business folks write test cases to define how the delivered software would work. And as many people in the Cuke threads pointed out, Cuke fails, too. (As did Fitnesse.)
https://en.wikipedia.org/wiki/FitNesse
Bottom line: There is a ridiculous impedance mismatch between the business side of the house and engineering. Engineering attempts to create a programming language for MBAs is not a solution, but an expression of that mismatch.
Not quite; it (FLOW-MATIC, rather) was designed so that senior management could feel that they could read their organization's code.
> I suggest a reply to those who would like data processing people to use mathematical symbols that they make the first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.
* Can you build "modern" style software in COBOL? - Sort of yes.
* Should you build a new system today using COBOL? - Absolutely not.
* Is ANY of the COBOL code you run into in the wild going to be architected in a recognizable way to modern sofware engineers? - lol no.
The management class doesn't want to hear this. Their only goal is to lower maintenance costs on their legacy systems by bringing in new people to ensure lower wages, so they fund all this nonsense about this very dead language.
"What is it with these nerds that don't want to write COBOL code? It's all just coding, isn't it?"
You know they're desperate when they resort to astroturfing.
They go to that level of weirdness because replacing the existing codebase would not only be much more expensive, but would introduce a great deal of risk that they aren't willing to take on.
A transpiler would not really address the needs of that sort of company.
https://tsri.com/news-blog/u-s-department-of-defense-mainfra...
A long time ago, I wrote a Tandem COBOL to C# and WPF translator (https://github.com/GartzenDeHaes/cobol2cs). The key bits are:
- COBOL UI's run in a customer written environment that provides security, navigation, and session data. In the system that I wrote, there's a WPF application that provides these services.
- Convert SCREEN COBOL to C#. The Tandem uses a VT6530 that is similar to an extended IBM 3270. There are client-side protected fields and scrollable areas that need to be emulated in WPF.
- Convert COBOL servers to C#. The Tandem has a 3-tier architecture where the screen programs talk to services running in a middle tier through an network layer called PATHWAY. These can be converted to classes and be created on demand in C#.
- Remote access to SQL/MP databases. Tandem has a Java Servlet environment that can be used as a data access layer. The transpiler generates these Servlets and the C# data access layer.
Unrealistic. This would be equivalent to 100.000 linux kernels.