COBOL’s youth culture
techbeacon.com
techbeacon.com
Then, in each of those files the variables had similar names in order to cut down on unique identifiers. WP100, WP101, up to the max number you needed at any given time. It was a nightmare. There was as much external documentation to keep track of all of this stuff as there was code.
On top of that, you could only build programs overnight in a batch process with the rest of the system, which was run by a different team in a different country (Spain, I believe). So you would write your program in the day, phone up the guys in Spain and explain that there was a new program going in and you were responsible for it. Problem was, if your program failed to build it would hold up the whole system, which HAD to be up and running and live again by the morning. This meant that every time you made a change that went into the nightly build you also had to be on call.
I remember eagerly watching the build queue at 1AM, waiting for my file's turn. Then immediately shutting everything down and going to sleep the moment it was successful. If it wasn't successful, well, then you had to fix it on the spot and phone Spain again to tell them to give it another try. Unfortunately, you rarely knew why it was failing.
Writing COBOL on the UNIVAC 490 series (30 bit word, FIELDATA character set), our files were on tapes. A tape request was submitted to the tape library, they would pull the tape(s) containing your file(s), and deliver them to the operations floor.
The customer would submit hand-written transactions, which would be sent to the keypunchers, who would punch them onto cards.
The tapes and transaction cards would be sent to the ops floor (where there was the actual computer). The operator would load the first tape in each file onto a UNISERVO tape drive, and go to the patch panel to run wires to assign logical devices to physical devices. ( https://www.computerhistory.org/collections/catalog/10266686... see page 57)
Then they would put the job deck into the card reader and enter the "UR" (read the Unit Record device) command into the console, which had a spool of paper, not a screen. When the program was awaiting input, they would load the transaction cards and give the console command to continue the program.
We did have a fearsome beast of a FASTRAND drum system for random-access storage, but that was just for executable code and temporary files.
Then you might well get called in the middle of the night, because one of the programs in the job aborted. They called it "aborted" then. Or ABEND (ABnormal END), if you were an IBM person. You would come in, read the core dump (reading core dumps was a valuable skill), and determine that there was a data problem in a transaction (e.g. an alpha character in a numeric field). You would find the offending card, pull it, tear it in half and set it aside to be addressed in the morning as a missing transaction, and tell ops to rerun the job. With luck, there were no bad cards after that one.
Tell that to kids today, and they won't believe you.
Sorry, I don't know German.
True, but the business context always changes. I doubt most of the payroll logic from 50 years ago is still in use today. Therefore someone needs to write new code, or change the old code.
> Many COBOL applications are large; rewriting them isn’t cost-effective—or even necessary.
Yes, your IBM sales rep makes sure of it.
What about the regulatory context?
I'm thinking of banks, for example.
It's probably even worse
* Banks still have very old codebases and changing anything is fear inducing for everyone (automated testing is a new things for a lot of teams)
* Banks control very little of their core software. They have a lot of vendors for the same thing. You will see multiple vendors delivering basically the same thing in different parts of the bank, and at the same time multiple versions of those vendor applications in diferent parts of the bank. Integrating this is a nightmare (it can take more than 1Y to move a tag in a XML).
* IT is still mostly used for marketing purposes in banks, it's not a way of doing things. The design/integration is mostly discussed/designed by functional people. They are great, but it does happen that they don't see the full implications of their choices till it is too late. Also, because this is a design 'from above' changing anything takes a lot longer. For any change you have to convince a lot more people till you get to the actual person that will have to do it.
* A lot more complicated management reasons. Nobody wants to take a hit on a new IT project, and few people have the IT & banking knowledge to move such a project (why would you? they pay is average). You cannot progress with just one of them. Places where these projects happen is mostly close to pricing/trading as those are seen as profit centers and the bank is more willing to fail a few times till it can build something decent. As you get closer to the guts of the bank things get more and more...problematic.
Edit: I had to add this. Central banks are also bad at IT, they do not set an example worth following. I consider this the main reason why all our interactions with banks are less than ideal online.
By the time the gains would be realized, the muck-a-muck will have moved on to a different company. They tend to think in quarters, not years.
You generally want to improve on what you have in some way (or else why do it?), but the line between the warts and requirements is blurry.
Incremental replacement is often a hard sell on the relationship side of things because the customer is seeing a reduction in functionality until everything is done. You can mitigate it and work around it, but it tends to excite waterfall urges which drives up risk.
You also have the fact that the organization keeps changing, so your target is also changing.
There is also an opportunity cost to the whole venture. All that time you spent rebuilding what you had could have been put into new ventures or back into core business.
If you look into modernization type efforts, you see a lot of failure and a lot of loss. That isn't to say it's impossible or that it isn't ever the right answer, but it definitely isn't safe or easy.
Each line on its own is indeed simple. But you have a few thousands or ten thousands of them in 1 transaction or batch process. And that batch process is just 1 in a long chain of batch processes. So you'll need to get a grip on 10-100K lines before you understand the whole process. Procedures are easily 1000 lines long, and any line in there can undo any other line if someone from 30 years ago did not find another way to fix a bug.
There is no abstraction, so code duplication is everywhere. 5 things that seem mostly identical, except in some edge cases means in reality 1 that is correct, 3 that were forgotten in the update process, and 1 that really is different.
Every company is different. As there is almost no human movement, and this is from before networking was widespread, knowledge from each company is an island on its own.
The thing is deeply legacy. Ideas like encryption, unicode, a hostile internet network, ... are alien to the COBOL world. The underlying assumption is that the central computer is holy, and humans need to adapt to its whims. You'd better change your name if it contains an accent not available in the local EBCDIC variant. Putting an € sign in a string? That newby char only exists for 2 decades, hope someone migrated to a code page containing it. On the pro side, Hacking attempts are only allowed in the business hours, as the thing switches to batch processing mode at night.
An organized testing methodology is rare. The cobol world depends on the knowledge of the programmer to remember the edge cases. No things like automated unit testing, maybe a private db with a few records.
The data model is horrible. Choose the size of a record and live with it. You want more chars? Find some spot that's still free and put it in there. The overlays, C unions on steroids, mean any location can contain anything, and any missing IF means you're overwriting someone else's data. I saw cobol devs argue for truncating email adresses. They'd done it with physical mail adresses too, and the mail still arrives. Those mail servers should learn to guess the missing chars at the end, just like the postal workers did.
You can use COBOL in a modern setting, but it is not COBOL itself that is the problem. It is the whole ecosystem around it.
And of course, they want you to have a 30% pay cut, as COBOL is easy.
Of course, the pensioning age of those cobolists might give them a reason in the extremely near future ;-)
The whole point seems to be to convince people to learnt hat so they don't have to rely on some near-retirement people and also able to pay them less.
Don't think for a second that the software engineering gravy train won't come to a screeching end as soon as supply catches up with demand.
I wouldn't even be surprised if us SE's eventually try to heavily license and gatekeep the industry like law and medicine, loading new workers up with 6 figures of debt and significant post bachelors requirements, in order to keep our salaries artificially high. Medicine in the US seems to be especially damaged by this.
From what I've observed by my conversations with friends and family in medicine, actual physicians increasingly do very little hands on work (with the exception of surgeons) and instead essentially just manage lesser educated technicians, especially RNs and advanced PAs, NPs, and CRNAs, who do the actual work. The physician essentially just stands around and observes but importantly takes most of the legal liability when things inevitably go wrong.
I think this is a huge part of the reason healthcare in the US is so expensive.
Perhaps the future of software engineering will look similar, with principle engineers and architects being like physicians. Extremely well educated, but almost no hands on experience writing code.
Ahh yes, the rest of the non-software companies in the world.
The GNUcobol implementation doesn't seem to support UTF-8 characters, that'd be awesome if it did, preventing even more awesome "screen/accept" input screens.
My big beef that I have with the language is that there is third party "extensions" built right into the language, which is very frustrating when trying to understand as a new user.
Geez, I wish it was as easy to build web apps the same way.
We first learnt Pascal. There is a lot to love about Pascal and in those days the Borland TurboPascal compiler was a breeze to use.
Then they dropped the COBOL hammer. We learnt programming this on our comp lab's mini computer. This was the most excruciating class of all.
Finally, we moved to C, followed by Compiler construction, Operating systems etc., The trauma of COBOL still lingers.
Luckily, I never had to touch COBOL as a professional.
ps: In India, for Comp Sci & Engg in those days, we had a fixed set of subjects for the first, second and third years. The fourth year is when we had two electives in each semester. The programming languages were mandatory during the second/third years.
I sometimes wonder what’s going to happen in about 40 years when some then Fortune 50 company who built their entire operation on Node suddenly can’t find Javascript programmers because they’re all retiring. :P
[0] https://www.cnbc.com/2020/04/06/new-jersey-seeks-cobol-progr...
I need to share this in all its glory. There is a working COBOL web framework. "Still got it!" it croaked from the corner.
The host system uses COBOL 1985 as far as I know and runs on the newest IBM hardware.
Learning resources: A script our teacher wrote and his exercises and one big IBM book as well as one German "Cobol insiders" book that is not available anymore.
As far as environment specific things: We have guidelines for our code of course but I am not aware of job control languages. But like I said, we aren't on the host system yet.
And working on old tech can still be fun.
Wish you luck going forward
> I had no experience with COBOL^W Perl before [my current] job, and I was surprised at how quickly I was able to get in and make my first commit
> “It does exactly what you tell it to do on a line [of code],” explains Stuart. ”Sometimes you get files that are 2,000 lines long, but they’re easy to understand because they simply do what they say they’re doing at that line.”
I don’t think COBOL is a good match for the programs I write in my spare time, but as a job it sounds nice. I guess the main problem if I were to find a job doing it would be the corporate culture at the kinds of companies that use it, but if I could do it remotely using my own workstation with any tools I choose I would do it.
To take C++ as an example (I love C++ btw, this isn't another C++ bashing), a line as simple as "variable1 = variable2;", could be doing all kinds of things (including not even assigning) because of the ability to overload the asignment operator. As someone reading this line of code for the first time, you don't really know for sure what is actually happening unless you also go and read the code for "=".
I guess it's easy to see the difference between "easy to read a line" and "easy to understand a whole program" now?
I admit though that some things are easier - but this is mostly due to architecture. You rely on one big host and one big database. You don't have to deal with a distributed system then. However it also limits the range of business applications that you can build with such a system.
Sort of like the underhanded C code contest, but optimizing for simple parts that create a complex whole.
All GOTOs. Is GOTO not powerful enough? Good news, we have GOTO DEPENDING ON. The destination of your GOTO is determined by a variable.
Youngsters may not realize just how bad GOTO based code can be. This is where the term spaghetti-code comes from. I still remember as a teenager, trying to understand how a BASIC maze generator program worked. I printed out several hundred lines of source and proceeded to study it. And eventually gave up after an hour.
I'm sure later variants of COBOL introduced blocks, loops and procedures. But that 50+ year old system will be all GOTOs...
Yeah, no thanks.
> working with massive mainframes
This is the kind of vapid marketing nugget that doesn't impress anyone that doesn't suffer from oxygen deprivation due to neck decorations. Why in tarnation should I care for overpriced obsolete technology? Do you see Google or FB investing in this? No? Ok then
> where everything is build on cheap stuff
pulled straight out of the IBM sales book I see
I won't touch anything that came out of those 3 letters
As if AD-Company's are any measurement for innovation, you could have said Oxide or hell even Amazon...but NOOO you take the lamest two Firm's out of the "FAANG"-Gang.
You obviously never worked with mainframes....that's sad.
Also there is no career growth with COBOL. Its a dead language. Learning it is as useful as learning a proprietary tool that is only used at one company. You’d be better off learning React, Rust, or some other language that can apply to several different companies.
That sounds exactly like modern software-stacks ;)
Living just in Switzerland (remember 3rd world country), 150-200k is not just a good but really good salary, but maybe i should move to San Francisco to learn what a good salary is...maybe i am ignorant to think that someone with 100k has a good salary, but who knows.
ADD 1 TO COBOL GIVING COBOLMy favorite example of this was a data entry routine that was insane - and lifted to a web interface circa 2004. “Turns out” when processing paper, several key transactions filtered through a gentleman, long since passed, who lost an arm in Korea. When paperwork was received, they were arranged and stapled in a way that accommodated his mobility limitations.
Every COBOL code base has stories like that, and there’s no functions or modern metaphors as it’s procedural. So your opportunities for code translation are really scoped to things that you can make a “black box”, never to be touched again.
Remember too this is shitty, unsexy, non-portable work. Top talent started looking elsewhere in the 90s, and often you’re left with a couple of people who understand how stuff works, then mostly folks who value stability over all else. Companies tend to pay for shiny skills, and the folks who really understand their business get second fiddle.
If you translate it so that is does effectively the same, the resulting code is nice.
Unfortunately only the former can be automated. Also, you need to understand the code to do the latter. But reading it is hard and the ones who wrote it are dead/pensioned.
One perspective on COBOL and why it is such a "write only" language is that it's barely a stone's throw from an Assembly Language with a verbose BASIC-like phrasing. (Well, historically BASIC derives from lessons learned from COBOL rather than the other way around, but from a modern perspective you get the gist.) Every single line has the readability of English, sort of, with that BASIC-like face. Every single line has just about the simplicity of your average basic processor op-codes, just like assembly. To do anything reasonably complex you need lots of lines building up layers of complexity from the simple instructions, just like assembly. Trying to figure out the high level control flow and analyze the overall logic, just like in any disassembly effort, becomes a mind's eye puzzle because there's few ways to visualize the abstractions in the code because the code is at too low of a level for good abstractions. There's no functions and classes, just lots and lots of little instructions. Endless instructions.
As with anything, its not about the programming language, its about the business context. COBOL outsourcing means having great documentation so they know what the fuck is actually going on in the codebase. Also, COBOL has less boilerplate than for example java. The boilerplate is not standardized and usually unique to each company, again highering the difficulty to outsource everything offshore.
Most succesfull approach seems to be to import 10 indian guys on premise, and have them work along your existing team.
Dont underestimate the effectiveness of a 59 year old cobol programmer who knows the program in and out, and knows exactly where to adapt something without breaking anything else. There are no dependency checks, linters or unit testing for most of these programs. You basically want 5 newbies working alongside one of these senior level programmers for a year or 2 before you confidently can let them retire.
talk to some people who work in banks, they have stories which could make your toes curl.
The only way out is to redo the whole system sometimes. It is not ease.
The code knowledge is secondary to the arcane domain knowledge.
I'm, in fact, surprised they never banded together into standardizing and sharing code and processes.
Engineers tend to look askance at categorizing different kinds of money. Granted, if you work in a business that has "profit center" and "cost center" mentality, you want to be in the part of the business that the suits associate with the good kind of cost, rather than the bad, no disputing that.
One reason why companies have unique code is that in fact the code reflects a business process, and they are in fact trying to compete via having better processes.
>The country that's spending more on software development than any other in the world is growing at a rate of roughly 2%/year.
What is the relationship here? Is this also the country that has the world’s biggest tech companies with the biggest growth in the world for the past 30 years?
https://marketplace.visualstudio.com/items?itemName=Micro-Fo...