My Surreal Experience with COBOL
mutt0-ds.github.io
mutt0-ds.github.io
At the end of the day, it’s just a thin layer over assembly.
I’m 2012-13 I wrote a Java -> COBOL bridge to directly invoke ‘MainFrame transactions’ from a JVM. Unlike the IBM solution, we never did anything with XML or text parsing and did everything using bit and integer manipulation. Java types and fields were annotated with their COBOL Record equivalents. Initially we used reflection which was fast but being Cowboys we made it even faster by using CGLib and writing custom classes at run time that could be JIT compiled.
This process was absolutely fascinating and it really took my career to the next level because a deeply understood what was happening in memory in both languages afterwards. It saved the company millions in license fees and we went from latency measured in seconds to below 8ms to invoke code.
The assumption that it is only 50+ year old legacy code running on dependable
but obsolete hardware, untouched by human hands in decades is wrong.
By the way, I'm not saying it doesn't suck. It's not something I ever intend to do in my life again.
I only did a couple of short paid stints with the language, back in the 1980s, but from my memory of it the biggest problem with it was the huge number of reserved words. One project therefore mandated that every identifier start with "100-"! The problem with globals was real, but contemporaneous Pascal had a globals problem too. There was a mechanism to interpolate source code of procedures; since the language had been designed back in the days of batch jobs elapsed compilation time didn't matter.
COBOL programmers tended to be isolated from the wider programming world and from people with a formal background in computer science. I arrived at that project too late to prevent them making design decisions like firing up a new executable for each transaction (expensive on VAX/VMS, but at least it was in the same process) or storing passwords in cleartext. They just did it the way they'd done it 15 years before on the big iron. It was a case of "I wish you'd been here 6 months ago to tell us about that, but it's too late now", or perhaps they were just being polite to the hired help.
You could argue that whatever the business-oriented language had been, those same people would have made the same mistakes. At least with COBOL, the language was such that they could be domain experts, for example accountants.
Funny anecdote about this. I used to work on a relatively old (early 1980s) COBOL and PL/1 codebase. Code was obviously a mess, as most of the files were written by non devs, and hardly had any comments.
There was this one though, that started with something like "this code handles currency conversions, and the author is long gone now; no one understands it, but if you need to modify it, please be aware that you may break all the business logic the bank relies on".
Code was modified once, in the late 90s, to support some Euro and Y2K oddities. No one else dared to touch it afterwards.
And without comments as the article says, you couldn't even document what it was for or where it gets changed.
https://www.microfocus.com/en-us/products/visual-cobol/overv...
Think positive, at least it isn't RPG, https://en.wikipedia.org/wiki/IBM_RPG
Why do people still use cygwin, and not WSL or an actual linux?
A. Cygwin works and has been around for a long time. B. Cygwin programs are native windows procs.
The notable exception is that I indirectly use MSYS2 (which is effectively a fork of cygwin) as part of using git for windows. Git for Windows includes an msys2 environment so that the portions of git that are written as shell scripts or perl scripts, etc can run properly. While you can launch the "git bash" directly, and pre-wsl that could be useful, the MSYS is mostly there because Git for Window's git.exe will automatically launch subcommands in that environment.
Since it's so lightweight, you can have, use, and throw away as many cygwin envs (folders) as you like.
It doesn't require any Windows subsystem, hypervisor, admin rights, Linux distribution or anything, and will even work on an XP machine should you need it.
Finally: much less bloat to run and store.
Lets not. It's old and compiled so comparing it so two scripting languages with massive runtimes is silly.
If you like that, I recommend you take a look at a language called FORTRAN (2 years older than COBOL and still used). And if you enjoy legacy and good design still being alive, LISP (1 year older) will blow your mind.
Getting rid of it was one of the reasons for Ada mandate, but as usual exceptions made it hard (PATRIOT is reportedly heavily JOVIAL based and a shitshow to program)
A federal agency had an IBM Mainframe and X.25 9600 baud satellite connections to local agencies all around the country (more than 200).
Every day they synchronize data between agencies sending plain txt tabular data. They were charged by amount of data they transferred.
We implemented a basic compression algorithm in COBOL because IBM C package was not available and expensive. We also implemented it in REXX [1].
The compression was very successful but the CPU went very high and affected other processes in the mainframe.
At the end the agency didn't implement it. End of story.
[1] https://en.wikipedia.org/wiki/Rexx and don't miss https://en.wikipedia.org/wiki/ARexx
Why so verbose? In today’s languages and document editors you can just insert a <page break> or EOF.
But I can understand why back then in documents they’d have to write out things like “Period. End of story.” without actual periods and control characters
(for people wondering, I am parodying the article)
Because it is in COBOL ;-)
The inventors of COBOL were keen on the "non-technical person" being able to understand the code. What they may not have valued or understood at the time was the need for future people "to understand who, why and how someone made that choice in the 60s". Largely, it was simply a matter of optimizing for space on the computer's storage media. In other words, saving punch cards. It was the practice at the time to keep the documentation, printed on paper, and the cards together.
Why create all those punch cards that the compiler is going to ignore, when you can simply use regular paper? Card punches and readers were finicky. Readers could only read so fast, and while they got faster and more reliable over time, in no universe were they going to match even a slow medium like 9-track tape.
Having said that, I wouldn't be too surprised if old green screen ATMs would have used COBOL. Ran on smaller computers and you could compile stuff with it.
Nowadays, I'd be surprised if it wouldn't just be your regular Java/.NET/C++ brouhaha. They should have phased out most ATMs running OS/2 by now, though.
These days it's more likely that the COBOL is somewhere in the IMS transactions (IBM bragged sometime in last decade that ~80% of ATM transactions are implemented on top of IMS at some point).
IMS is a navigational (CODASYL) database system with iirc a form of application server - what you'd call today a NoSQL database :P - designed for Apollo project supply chain handling.
I do take issue with the simultaneous statements that spaghetti code is unavoidable, and programs written in the language are easy to read.
It's either one, or the other, they're mutually exclusive.
This is nice for beginners who are still struggling with basic concepts. It allows to understand code incrementally.
But that does not mean that whole programs are also (comparibly!) easy to read. No, it is the opposite. If two languages are equally well made, but one focusses on small parts being easy to understand while the other one focusses on being very expressive, then a well-versed developer will have a much easier time with the more complex language. But an inexperienced one will struggle and have a much higher learning curve.
It is really a tradeoff. Similar to archiving files. You can choose to compress them very small, but this will cost more CPU and time (requires complex algorithms in many cases, see video-compression and potentially multiple passes) but decrease filesize. You can also choose low compression but a simple and fast one-pass algorithm can be used here.
Neither is inherental good or bad and it explains why people call languages simple or easy and others disagree. Because they are really talking about two different aspects.
I don't think there needs to be any tradeoff in the language itself for this. There will be tradeoffs in the complexity of programs to avoid it, but that seems to be true no matter the language.
Of course, the languages that are both easy to get started with, and at the same time, powerful enough for large systems to be written, result in a lot of very terrible programs, not because they are _bad_languages_(tm) but because they're a perfect balance between ease-of-use, flexibility and power to expand.
"easy" is always relative, so compared to what? Compared to a language that isn't well crafted? Sure. And in practice, most languages could be optimized a lot. But that is not what I was talking about and thinking like that only distracts you from the bigger picture.
My guess is social-media induced hyperbole. "A peek at COBOL," just doesn't have the same potential to bait clicks.
From what I recall (no personal experience), the pay is quite a bit less than big tech, with the downside of an antiquated language on the resume and nightmare codebases to deal with. Doesn’t sound like a good career move.
> From what I recall (no personal experience), the pay is quite a bit less than big tech, with the downside of an antiquated language on the resume and nightmare codebases to deal with. Doesn’t sound like a good career move.
FAANG salaries are kind of ridiculous, so using them as a base for a comparison is probably not going to lead to much insight.
The two exceptions are people with decades of experience that have the advantage of understanding the business logic they helped build during their time and the truly exceptional people out there that work as contractors for desperate companies unable to find people that can understand their systems.
So there is money in COBOL, but I don't think it's particularly accessible to anyone new. Maybe as more veterans retire, salary rates for new devs will go up. There is an interesting trade off between paying more to attract talent and taking the risk of migrating off a mainframe. COBOL is easy to teach, the hard part is maintaining the business logic that was built up over decades. Our parent company recently shut down their mainframe, but it took them nearly 7 years to complete that process. Many other companies have failed and wasted years and millions of dollars trying to migrate. It is massive challenge.
Also, mainframe has one of the oldest "meetup" groups which also supports new comers https://en.wikipedia.org/wiki/SHARE_(computing)
Regarding pay my guess is that it's not great if you only program COBOL. Like other stacks you need to know about the operating system, the source control system, the pipelines, scripting (JCL), etc. COBOL it's easy to learn since it's a very simple language but the rest of the stack is hard because you don't have access to them.
> 2021 Median yearly salary (USD) - $52,340 > 2022 Median yearly salary (USD) - $75,592
Source: https://survey.stackoverflow.co/2022/#technology-top-paying-...
How computer-ish. What else is it going to do at the end of the program?
I'd find it hard to work in a programming language that's all upper case and shouting.
IBM still churns out new releases of the programming language, where they keep tacking on support for all the things programmers of today want to do.
Here's a story for you.
Back in '02 when I was learning COBOL in school, the absolute worst sin you could commit was forgetting that STOP RUN or the period following it. If you did that, the mainframe would crash, and nobody could continue working on their assignments until somebody had called the operator and gotten them to reset the mainframe. The night before assignments were due, they had to pay someone overtime to stay up and be ready to hit the switch at any time because of this. And, of course, if you hadn't saved in a while, you lost your work.
At some point, we either found or were given a local IDE, which we then used to write code that we tested on the mainframe afterwards, and it was a game-changer. But also, the IDE used a later and better version of COBOL than the mainframe, so sometimes you'd write an instruction that worked locally and blew up on the mainframe, and you'd have to rewrite your whole everything to get around missing basic control flow structures.
Honestly, his "surreal" experience isn't caused by COBOL but his inability to understand a technology in its age and context. Why do we keep sharing content so little informed?
I would not recommend it. But it is like comment like not use gun to a Roman solider. In their times they are quite ok.
Imagine you use c or even c++ for business operation of just file in and out (using tape …). String processing … good luck
The closest analogy would be if you had some crazy late-90s Perl that relied on custom database and terminal drivers.
There's not much of a bandaid you can put on this to "modernize it" other than a rewrite.
I thought the spaghetti code in COBOL came from liberal use of GOTOs (e.g. following the execution path of the code is like following the path of a single spaghetti noodle in a plate of spaghetti).
COBOL introduced alternatives to unconditional jumps in the 60s. You can convert unconditional jumps to different control flow structures through static analysis. Plusfort does this for FORTRAN pretty well. I'm sure there's an equivalent tool for COBOL somewhere. The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor.
> The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor.
I'm not saying that's not a problem, just that it feels like it could be an anachronism to use "spaghetti code" to refer to that in the context of a COBOL program.