Cobol Still Powers the Global Economy
tpr.org
tpr.org
While decyphering the remaining logic, I discovered what I think is the most evil programming construct I've so far seen; think goto is bad? Meet MOVE NEXT SENTENCE. COBOL is traditionally written in all uppercase (and historically EBCIDIC). So what does "MOVE NEXT SENTENCE" do? It's an unconditional jump to the next period, that's right '.'. Thats right, in a language where everything looks like it's yelling at you, you have to find a little tiny period to find where execution resumes. No labels, just a tiny couple of pixel round period. Fun...
Totally naive to COBOL here, why do you have to do it? You said you wrote some regexes for the pull and transform, why not pipe the source to a program that finds that period for you?
The problem isn't finding the destination, its what alternately happened been source and destination.
Also, if your reading on paper, CTRL-F isn't available. You're scanning those pages by hand. When you're sitting there, highlighter and pen in hand to make annotations and point out important shit, its a problem. End up with circles around the periods and arrows point to it with comments like "this is how we got to x from y."
Edit: also if you end up at the same place regardless of the source or from multiple sources. You can't keep the code for a level to find everywhere a jump emds up there.
"sentence".capitalize()
I'm not sure how and on which machines COBOL code is written and compiled these days but I reckon that piping it to grep, or similar tools, might simply not be an option on those machines.
Here's someone asking about doing just that:
https://serverfault.com/questions/356574/can-i-run-grep-agai...
[0] https://en.wikipedia.org/wiki/MVS#MVS/XA
(Edited to go back even further than OS/390)
ALTER LABEL1 TO PROCEED TO LABEL2
This will cause any gotos to LABEL1 to be redirected to LABEL2.
This is worse than older Fortran's arithmetic IF[0].
(although working in javascript of course any function can get redefined at any time so some things never change)
Cobol was first used in computers that are equivalent to $1.5 PIC18 microcontrollers https://www.microchip.com/paramchartsearch/chart.aspx?branch...
This was the first computer with a Fortran compiler.
IF (VALUE) 10, 20, 30
The three arguments after the value are labels that the program jumps to.
The equivalent of this line in C is something like this:
if (value < 0)
{
goto 10;
}
else if (value == 0)
{
goto 20;
}
else
{
goto 30;
}
#define LABEL1 LABEL2
Is there any language that can be worse than a macro and #ifdef-ridden C? I'm only half joking.
[1] https://riptutorial.com/cobol/example/19820/a-contrived-exam...
Of course, your point stands, and this has been a long standing issue for COBOL, especially since a missing or extra period is probably still syntactically correct.
I just finished refactoring a couple of COBOL programs to remove all of the periods from PD code - which is how I prefer it. Can't wait to see how it goes at code review!
https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/...
Wait, you never heard about exceptions?
In old non-proportional fonts on old CRT screens with low resolution, "." was a pretty noticable glyph. Typewriters tend to have rather noticable periods, too.
That convention truly was a child of its time.
So I think what you said it's true: conventions are indeed children of their times.
I thought this comment was born from naivety or bias, but after reading up on it a little further, it appears that it's true or close to true for many cases.
Edit: googled it and they use MIPS (millions of instructions per second).
They also have rediculously high up times and much higher security (probably mostly via obscurity).
Unfortunately, they're insanely expensive.
Mainframes weren't nearly as rock solid as their reputation in the 3 years of dealing with them that I had.
Mainframes were great at processes that need high IO.
I've not dealt with them in close to 20 years, so dont know how current x64 linux or Windows stacks line up.
Mainframes are hugely expensive. 20 years ago, entry level for the hardware was around $500k, IIRC. Dont think that even provided storage or software licenses. But, yeah, youve got one largely extremely reliable piece of big iron that can handle nearly all of your needs.
Kind of like how KDB+ is so expensive as they're targeting a niche audience. Even though that is purely software.
It matters, because otherwise any kind of performance number is meaningless. If it's just CPU processing, then 1.1 million is not that much. If it's doing some sort of network handshake/transaction with other mainframes, then it's VERY impressive.
----TIMINGS (MINUTES)----- -----PAGING COUNTS----
STEPNAME PROCSTEP RC EXCP CONN TCB SRB CLOCK SERV WORKLOAD PAGE SWAP VIO SWAPS
ENDES000 00 15522 2105 0.019965 0.000636 0.1 116946 BATCH 0 0 0 0Not sure what "abstract metrics" are you referring to.
"Measurements of performance" https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0...
"Latency and Throughput" https://www.oreilly.com/library/view/web-performance-tuning/...
In the PC world, my computer has a certain number of FLOPS even though it has no impact on my day to day work where I care more about RAM and such.
It's analogous to saying 'A 60 year old language has better compilers than younger languages.'
Which doesn't seem especially provocative.
Not perhaps in the same league as more fashionable languages, but certainly a fair distance away from 'close to 0'.
[0] https://www-01.ibm.com/software/support/lifecycleapp/PLCDeta... [1] https://en.wikipedia.org/wiki/GnuCOBOL
I do COBOL mostly in OpenVMS and only tinker with IBM in the weekends but it would be cool to see how it performs under the same circumstances compared to other languages.
We run Itanium (exciting that the first OpenVMS X86 boot was recently) and when/if I can afford a house it's going to have plenty of hard toys!
First, it's never going to be faster than assembly on the same machine. That is not possible.
Second, I bet it's not faster than Fortran at matrix multiplication. (And anyone who tries to do matrix multiplications in COBOL should be barred from touching a keyboard for the rest of their life.)
What it may be the fastest at is certain business calculations. And it may be the fastest at them because they are traditionally carried out in fixed-point arithmetic. IIRC (and I may not), some mainframes had specific instructions/opcodes for fixed-point math. If COBOL uses those, and other languages don't, then COBOL could in fact be the fastest... at fixed-point math calculations. That's still a long way from "the fastest processing language", though.
The claim sounds like someone has mistaken their little corner of computing for the whole universe...
It seems pretty clear from context that it means for doing report generation and accounting things that COBOL is known for, not for LINPACK.
> it's never going to be faster than assembly on the same machine.
You are being unhelpfully pedantic. It is not insightful to say an optimal assembly program is going to be at least as fast as a compiler for a higher level language.
How can that happen? One reason is choice of algorithms -- the same reason why two programmers using the same language to complete the same task can produce remarkably different results.
Another reason is profile-driven optimization -- in theory the assembly language programmer can do this too, but the effort of restructuring lots of handwritten code is too painful. Yes, it is done sometimes (eg, different inner loops for video codecs for different versions of x86 cpus).
Likewise, optimizers and superoptimizers understand the pipeline quirks of specific processors better than most people writing assembly language for x86-type processors and can produce better results.
The question ‘fastest at what’ is right there in the original quote - processing. Assembly isn’t commonly considered a ‘processing language’ and in the context processing is a term of art for the kind of batch processing tasks cobol was designed for.
Even that aside, we all ‘know’ assembly is the fastest. It’s a given. Nitpicking comments like that betrays a hostile attitude and lack of generosity of spirit. We shouldn’t have to post pages if caveats and justifications and hedging for a comment like that.
Attacks like this come across as intellectual grandstanding and aren’t actually contributing anything of value.
So I thought it was a reasonable criticism of an overly broad or at least very ambiguous assertion, regardless of its motivation. It’s quite common for the best arguments against an argument to come from people who are hostile to it for whatever reason. More carefully defining the scope of things where we would expect COBOL to get top performance marks would make the conversation far more informative and productive.
As for assembly, there is now a broad class of problems for which CPU assembly is far from the fastest solution, because GPUs are faster. Even on the CPU, there is a widespread (but usually false) belief that compilers beat expert assembly programming. So perhaps to you it's a vacuously true statement that adds no useful information, I read it as rebutting a belief many readers may really have (though, unfortunately, only as a bare assertion.)
I think it's unreasonable to expect every comment about every bit of technology, old or new, discussed on HN to come with pages of preamble, caveats and definitions of terms.
If something went wrong during a deployment, heaven help you. One time a pair of transposed digits got through testing and code reviews and into deployment. My colleague spotted it and called the management center to hold jobs... Thirty seconds too late.
It took four days to back everything out.
It all seemed horribly complicated and brittle to me at the time. Not sorry I don't work with it any more.
Like a whole tax form is how you’d do a Hello world.
And then we ported the runtime to render web pages over a web socket and that’s when things got really interesting. 20+ MLOC of legacy apps rendering directly to the web.
It’s such a flexible language and I absolutely enjoyed working on the run time and the other guys in the company really enjoyed writing in it.
Even if you had the original design documents, it is very likely that the code that runs now has widely diverged from the design documents in the past 50 years.
In addition, being risk averse for this kind of code is likely a good thing. With a rewrite, the best you can hope for is to do what you are doing now without running into bugs. At worst, you have lost a lot of money and reputation and may become bankrupt. The risk/reward tends to favor "if it ain't broke, don't fix it."
And if you've already found all the bugs, and it's performant enough, why would you ever rewrite it?
Sure, there's a maintainability issue, specifically with available developer talent.
But I feel like shepherding a mature, battle-tested codebase probably is more of an ops than a dev problem.
There’s going to be some point where you’ll be glad to have original specs and docs and source code on hand (along with a good COBOL dev) so you don’t have to decompile and reverse engineer the damn thing. (Which IIRC had to be done for a relatively large percentage of COBOL-era systems updated for Y2K.)
When I started gathering requirements from the city's rep who was my point of contact I asked them for any documentation they had such as use cases, functional specs etc. All they could provide was the original COBOL source code bound up in those huge 17"x14" binders; the one's that have the holes along each side from the old dot matrix printers with every other line having that faint light green background.
Well I'd never seen COBOL in my entire live and I could only look at the code for about an hour before my eyes started to bleed. Fortunately I was able to get restricted access to the system and it ended up being pretty easy to just reverse engineer the thing by mapping each green screen of the app to a corresponding web page. In the end I didn't need any original code or documentation to do the job.
I worked a contract for an android app like that: only source, no requirements, no tests, no docs. A little bit of incomplete commentary in the code. I would build it, run it, see it crash and hope the fixes I made didn't eliminate some important feature. IDK. Isn't that the way everything works now?
Or did you transition to a completely new system - new storage / database everything?
Is it implying that if you like doing innovative programming and learning more about new languages and your craft, you must have a short attention span?
It is also rather naive if it is believed that anything other than a tiny fraction of programming in the real world is actually innovative.
I can't help but feel that even back in the days, they would have been better served by Pascal with fix point math. The only convenient features I could spot were related to working with records in files, and Pascal has that covered.
Their Cobol implementation sort of, kind of supported subroutines but they were such a pain in the ass that code was usually copy-pasted instead.
The only thing about Cobol that I just can't stand so far is the optional filler "keywords" that allows code to look sort of, kind of like natural language. That's just wrong.
My point is that if you can implement Cobol, you can implement Pascal; and your users will be better off. Cobol has no inherent qualities from my experience that makes it a better choice.
That doesn't sound like a very good reason when you pair it with the fact that:
> Most of these people, however will start their pensions in a couple of years
Incredible oversight that will either lead to some potentially very serious consequences, or some very high consultancy costs.
I have another example of their oversight: In my team there was a single developer who was not a contractor. He was competent and an autodidact. It took them over 6 months to find a way to increase his pay, which would still be less than €4k if I remember correctly. The rest of the team were contractors getting paid well over €100 an hour, which (all costs considered) is about 2-3x more expensive. He left before they were able to give him a raise and replaced him with another contractor. This happens there all the time, because of stupid rules that make getting raises really hard, people leave and sometimes even get rehired as contractors for twice the cost. Everyone knows it happens, but nobody does anything to change it.
Technical debt is also a huge issue indeed, since focus is always on delivering new features, because that allows leadership to move to new positions. Delivering stable maintainable code/infra isn't visible.
https://werken.belastingdienst.nl/bd-update/ict-summercourse...
Even more curious to me is how COBOL squares as fast if it's stuck using fixed point math.
AFAIK this is only because modern CPU's have floating point units (https://en.wikipedia.org/wiki/Floating-point_unit), from memory these became common on home PCs around the time of the 486. A lot of early 3D games used fixed point because it was much faster for those that didn't have a co-processor installed.
Whether any of this is applicable to mainframes I don't know.
The main reason people use floating-point math is convenience. It's like dynamic typing: write your real quadratic equation solver with floating-point math and you can use it for everything, whether the values are 6.02e23 or 555e-9, at the expense of having to do extra computation at run-time, just like dynamic typing lets you implement a single hash table type that works for any type of value. But in fixed-point, unless you're using a pretty fancy language, you need to decide on the magnitude range of your values up front. Maybe 3e-6 to 3e5? Use 16.16. Maybe 4e-3 to 1e11? Use 24.8. It's a pain in the bohonkus. But it's faster, more portable (if reproducible results are necessary) and easier to reason about than floating point.
languages without oddities and gotchas do tend to lend themselves to stable systems
What exactly is fixed point math? The way I deal with currency is to use decimal floating point, ie 'decimal' in C#. Is fixed point simply using integers with and making your base unit cents, not dollars?
Decimal versus binary is orthogonal. A decimal fixed-point number means that N will be a power of 10, and usually clips the range such that there are fixed number of decimal digits available (e.g., between -1,000,000 and +1,000,000). A binary fixed-point number means that N will be a power of 2, and clips its range to fix the number of binary digits (e.g., between -1,048,576 and +1,048,576). Binary floating point means that the base in arithmetic is 2, whereas decimal floating point means that base in the arithmetic is 10. C#'s `decimal` type is a non-standard decimal floating point, which looks to make the mantissa be a binary range instead of a decimal range (i.e., the maximum is not 10^n - 1 for some n).
And now I'm doing cryptocurrency analytics. The basic unit of Bitcoin is the satoshi, and in the protocol, all transactions are denominated in satoshis. (Similarly, in ethereum, the base unit is the wei and all transactions are denominated as 256-bit words of wei.) And yet basically all exchanges are still using floats. Sometimes they quote them as strings to avoid round-off, sometimes it's double-precision, but internally, it's all just floating point math. So once again I find myself doing everything in terms of floats, even though the underlying financial instrument uses integer units of a very small denomination.
Now that there's a huge proliferation of cryptocurrencies, I wonder if we'll eventually see one that gives up on this point and defines money as IEEE 754 double-precision floating point numbers.
This isn't directly attackable, but you could potentially trick a trading algorithm into performing stupid trades by feeding it subtly inaccurate data. If you know the particular algorithm used, though, there are probably easier ways to construct adversarial inputs and trade against them. This is why virtually all trading shops keep their algorithms secret, and also slice up & mix their outgoing orders randomly so you can't observe the output of the algorithm.
Sounds like all there customers had already worked around the bugs and they didn't want to backtrack. Floating point can be horrible because not only do both sides have to use it but they have to process their calculations in the exact same way with the same order, with decimal types you will get consistent results.
Throw in some other complexities like different clients using different value precisions, different currencies having different fractional values (japan has no decimal places, a Kuwait cent is a thousandth of a dollar) combinations of those two and more, then using decimals/money types are just easier.
The commonwealth bank in Australia, one of the biggest four banks in the country, spent AUD$1B migrating away from COBOL.
https://increment.com/programming-languages/cobol-all-the-wa...
It's not so much something inherent to the language, but that it's what's in use and working. It was an early language so a lot of infrastructure was built on top of it over the years and it'd be very difficult and risky to change.
PERFORM 4200-COPY-ECR THRU 4200-EXIT.
http://rosettacode.org/wiki/Factorial#COBOL
or also http://rosettacode.org/wiki/FizzBuzz#COBOL
Is there a code example where Cobol shines in comparison to, say, Python?
Today’s winner is dc
> dc is the oldest surviving Unix language.
https://en.wikipedia.org/wiki/Dc_(computer_program)?oldforma...
Yes, processing (like tabulating) fixed-size records (like punch cards) with hierarchical structure. You can do that with Python's struct module but it might be more readable in COBOL.
Other than that somewhat domain specific task, no. Python has a lot more features and is a lot more general language.
They cite: https://www.share.org/blog/mainframe-matters-how-mainframes-...
And that massive data entry work was still less work than running the calculations and summaries and projections etc on paper alone.
https://interskill.com/ or https://interskill.co.uk/
Disclosure: I work for them.
With this kind of thing you never know when organizations move away from the technology en masse and it would be great to be in it at the time.
Now the other question is whether it makes sense to get into Cobol from a career or business perspective and I am not so sure about that...
It all ran on IBM mainframes (the size of a small car) surrounded by disks and controllers the size of refridgerators. All the hardware was kept in a glassed-in room with white-tiled raised floor. Most of the coding was done on dumb terminals, but a few applications still had punch cards.
Ah, the memories. Long live COBOL.
If anyone has any thoughts I'd appreciate it. I'm currently writing c++ software for making robots work, plus I have financial industry experience.
I am sure there's a lot of it running still, mission critical stuff, also that there are still a few teams creating new projects with it. So it is not dead by this definition. But if I'm honest, I can't name one single language that is.
So saying COBOL powers the global economy is indeed a stretch. Want to say Linux powers it? True, Intel powers it? True. COBOL... not so much. Imagine rewriting every COBOL system in the world, now change that into replacing all Intel cpus, ~~SQL~~ OracleSQL or MySQL databases or Linux kernels...
Edit: saying "SQL Databases" makes as much sense as saying "procedural programming languages", updating it to make more sense
SQL is a very high level of abstraction, to the point where the argument is a bit absurd when compared to a very concrete example of COBOL. Yes, if we had to rewrite everything that utilized SQL then it would take an incalculable amount of effort.
I feel like you're kind of hitting the nail on the head with the Linux kernel bit though -- yes we could replace all uses of the Linux kernel with one of the many alternatives available, but it would take a long time. More likely we'd see a major transition to one of the other available kernels. This is exactly the situation COBOL is in.
All this though -- and I think we're just talking about a semantic difference on the use of "%1 powers the %2". Arguably C, SQL, and Javascript provide the value to users which encourages them to spend their money which encourages further development. So okay, I think I follow where you're coming from. COBOL doesn't power the economy, it's just the most common form of infrastructure for us to extract value from the economy. That sound a bit more correct?
I beg to disagree here, swapping CPUs would definitelly prove to be extremelly costly in every possible way. Not only do the MoBo + CPUs themselves have a cost, but they also do not exist. That would mean a huge spike in AMD (or whatever vendor) demand, one that they don't even have the capacity to manufacture. On top of that, all the kernel optimizations over the years, which have a big impact in the overall costs of a cloud service, would be lost. All that ignoring the logistical side of swapping motherboards and CPUs, transport, risk and everything.
> SQL is a very high level of abstraction, to the point where the argument is a bit absurd when compared to a very concrete example of COBOL. Yes, if we had to rewrite everything that utilized SQL then it would take an incalculable amount of effort.
You're right. Let me swap that with OracleSQL or MySQL, that'd make more sense.
> I feel like you're kind of hitting the nail on the head with the Linux kernel bit though -- yes we could replace all uses of the Linux kernel with one of the many alternatives available, but it would take a long time. More likely we'd see a major transition to one of the other available kernels. This is exactly the situation COBOL is in.
Imo the Linux kernel position is not the same as COBOL. COBOL is mainly being maintained, whereas Linux is the current standard for new projects and will remain so for the foreseeable future. If we create a new project running on COBOL, or a new project running on a Linux server, those are two completely different situations.
> All this though -- and I think we're just talking about a semantic difference on the use of "%1 powers the %2". Arguably C, SQL, and Javascript provide the value to users which encourages them to spend their money which encourages further development. So okay, I think I follow where you're coming from. COBOL doesn't power the economy, it's just the most common form of infrastructure for us to extract value from the economy. That sound a bit more correct?
Yes, exactly my point. The economy is not "powered" by banks, it is powered by those who create economic value, and they do not use COBOL all that much.
This book is a great overview of the economics of these kinds of situations:
That doesn't make Cobol sounds less like a fossil in any way. It will be go away eventually.
The audio version has the quotes in the voice of the original speakers (probably because this is a radio).
There is an interactive timeline custom made for the content of the article.
Other audio logs can be accessed super easily via the drop down menu.
Incredible stuff.