One of my last jobs as an intern in 2004 was to rewrite an old batch process COBOL app in C# and ASP.Net. App was basically input about 6 fields, and based up some rules. It really wasn't terribly complicated, but I had to read the source to understand exactly what it did. It was also my real exposure to COBOL. Took me a while to realize that around 60 printed pages of the 80ish page program was nothing but hard coded data tables and rules, when this, then that, etc. Once I realized that, it was a few simple regexs to pull that and transform to xml (was early 2000s...).
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...
yeah, it's funny. This would be like car people (or pick any other group) in forums, pointing to some super popular car made 50 years ago and then making fun/light of all the crazy stuff the best engineers at the time felt was necessary.
Arithmetic IF and COBOL's ALTER statement were reasonable solutions at the time but that doesn't make them any easier to use or understand in the present.
That arithmetic IF sounds really useful for the kind of numerical applications typically written in Fortran. Isn't it only bad because every other language uses IF as a boolean conditional?
Your C #define is done at compile time. This Cobol's alter example [1] seem to do so at runtime. Thus labels can be considered modifiable points. Actually, it's kinda interesting... does it support chains? Alter A->B and B->C, does GoTo A call C? If i now alter X->A then A->D and GoTo X, where do you end up? C? D? Hope you can at least undo that with something like alter A->A. Actually, I probably don't even want to know. Hope using it gives a big warning in whatever tools Cobal devs use.
It's self-modifying code, which is not the same thing as metaprogramming, which utilizes unexpanded expressions (often macros) which then get expanded in the final evaluation.
The term meta programming in languages like Ruby and many others tends to
be taken to include the language ability to dynamically alias (or create) methods at runtime. I don't think I can remember having seen it used to mean something as restrictive as you suggest
I don't think it is "MOVE NEXT SENTENCE".
The NEXT SENTENCE clause is part of an IF statement. COBOL is usually coded with every statement a sentence, terminated with a period. The exception is nested statements (such as IF statements), where you don't apply a period inside the nesting. The NEXT SENTENCE clause is used to exit the nested logic and continue at the next statement after the period.
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!
> 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.
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.
I know that refers to an even earlier period but... it is funny how in telegrams (real telegrams, not the chat application) the period was replaced by the STOP word because it could be often misprinted, because it was really tiny and a printing artifact could be read as a period.
So I think what you said it's true: conventions are indeed children of their times.
> you have to find a little tiny period to find where execution resumes. No labels, just a tiny couple of pixel round period.
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?
COBOL programs reside on mainframe computers, an environment that's entirely alien to someone who's used to UNIX-like environments where you have something like a pipe.
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.
FYI on IBM mainframes, MVS has included an integrated Unix environment since 1993 [0]. This continues to be developed and supplied with the latest versions of z/OS :)
Today they write/edit COBOL programs in IBM WebSphere Studio Application Developer (today named IBM Rational Application Developer for WebSphere Software) which is a commercial version of Eclipse with several mainframe related plugins. So they use usual Eclipse editors with remotely located files and they can find these periods without grep - just with CTRL+F...
My experience was that while the IDE was available and picked up by newer developers, the majority of developers at the mainframe shop where I worked avoided it as much as possible for pretty much the same reasons seasoned UNIX devs prefer working via command line and text editor.
I don't think it would have been a hassle for him specifically (could always just ctrl/cmd + f....), he's moreso lamenting the fact that this is an actual feature i.e., if you actually wanted to program in COBOL for some reason you'd actually have to deal with this, which makes its inclusion insane.
Yeah, it wasn't an issue of doing CTRL-F, it was about making sense of that flow when the control jumps you multiple screens of code.
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.
I worked on Y2K remediation fixing COBOL programs I'd never seen before at a large oil company. It's an easy-to-understand language by design. The complexity of dealing with the apps/jobs wasn't the code or the impact analysis, but just the volume of work -- the endless test cases. The nice thing about those systems was that because they were financial apps, success was pretty black or white. Either things balanced and agreed with production or didn't. But sooo many green bar reports. Killed many green bar trees in '98. My theory is that if you like programming, preferences aside, you'll appreciate the beauty in any language, COBOL's no exception once you grok it. May not be sexy but I've seen sexier languages come and go in 20+ years.
> “I think there is a misconception about [COBOL]. A misunderstanding about it as far as it being old. Usually in technology we think because it is old it is irrelevant,” he said. “But it’s still the fastest processing language out there.”
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.
I think it mostly stems from IBM compiler optimizations for their mainframes (which is most of today's COBOL), and not the language itself.
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.
You surely know more about COBOL than I do, but what about decimal arithmetic? I mean if the problem domain requires arithmetic correctly rounded to thousandths, with the operands loaded from fixed text fields and the results stored in fixed text fields, COBOL gives you that directly in the language, and presumably on a relatively efficient form. I don't know if using instructions like 8086 DAA and AAA is a win on today's CPUs, but surely avoiding the sequence of long divisions to convert from binary to decimal is a win (if what you're doing between input and output is, like, an addition and a multiplication by 1.0575, or something). Are you thinking that maybe some C++ template Decimal class with some integer parameters is going to beat GnuCOBOL on an amd64?
I wish I could give you a good answer, but I really haven't dug deep into the pros of the language. If you see any review of this I'd love to read it as well.
I've been able to get the same or very similar performance with modern languages that are a lot easier to debug. It just a matter of developers and management letting go of the old ways.
Why? It is fairly close to the metal and runs on hardware DESIGNED to be fast for transactions. IBM mainframes aren't even expressed in flops but some other unit designed to represent transactions per second.
Edit: googled it and they use MIPS (millions of instructions per second).
Well, in the mainframe world, people don't typically measure in MIPS or FLOPS for day-to-day work. It's all about efficiency and throughput. We care about actual elapsed time, and resource consumption rather than some abstract benchmarking metric. Part of this is because a batch job will NEVER get 100% of the CPU, because it is sharing the system with so many other processes.
What do you mean by "transactions" in this context? I don't think either COBOL or old IBM mainframes support software transactional memory (STM) as that's a fairly exotic technique that's mostly seen in the context of Haskell and the like, even though it does seem interesting as a model for concurrency.
Probably more obscurity than actual security, in my experience. I once knocked off about 10k users off of a dev mainframe LPAR simply by running a SQL query (crashed DB2 and the underlying OS). With someone with more experience than I had, probably could have been exploitable. It was an accident, but it happened.
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.
I'm a little bit confused by the terminology here. What exactly is a "transaction", in a lower-level sense? What does it consist of? Is it pure CPU processing of one data structure to another? Is it shuffling things around in a (local? remote?) database? Is negotiating a transaction with another mainframe somewhere else over TCP?
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.
You tend to have two types of processing done in a mainframe, batch and online. Transactions usually refer to online work. In the old times, it used to be someone connecting in 3270 and issuing a bunch of "transactions" to bring up screens and perform various operations. Now, it would likely involve a web layer. The server part can be CICS for example, but they are others.
Think of them as application servers.
Proper batch jobs tend to perform even faster.
There is a few reasons to that, one of them is the full integration of the systems (ie: the batch has "shared" memory access to the database, basically it's a big stored procedure).
Both IBM Enterprise COBOL [0] and GnuCOBOL [1] are in active development, and recent releases (September 2017 for both) appear to include support for the COBOL2014 standard.
Not perhaps in the same league as more fashionable languages, but certainly a fair distance away from 'close to 0'.
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.
I reckon the guy in the article was referring to COBOL basically having fixed sized data structures. Having all your data structures of a fixed size does allow for alot of optimizations that would otherwise not be available.
However, you can make fixed size data structures in any language, and the benefits of this is somewhat moot with the large caches and fast CPUs (compared to IO) of modern computer systems.
Actually it's very insightful since there are a lot of people who believe that a modern compiler can beat hand-written assembler code. Raising awareness about assembler and how the machine actually works equates to better working conditions for everyone, as we'll have more competent and knowledgeable colleagues then.
Modern compilers can often beat hand-written assembler code in practice. Theoretically they can't, but we don't live in the theoretical world. The common belief is true because most people understand the distinction.
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.
Case in point. What you belive is a myth. It's not true. A compiler will never be able to beat a human at writing assembler code. Read any tutorial at constructing compilers to understand why.
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.
I agree all the indignation is a bit much. The B in COBOL stands for Business, so, surprise, it's good at business stuff. It's right there on the label.
I am not familiar with this sense of the term “processing”, so perhaps it's less widely understood than you think. I assumed that in the context it meant the kind of processing the Central Processing Unit and Graphics Processing Unit in my hand computer does, which is pretty broad.
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.)
If you don't know, look it up or ask a question. Launching into argumentative nitpicky screeds that are actually it turns out irrelevant to the point in discussion is just annoying.
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.
My first gig out of college was maintaining Cobol at a bank for two years. Some of the programs were 20+ years old, and we made changes monthly - it always seemed like a fantastic rate of churn.
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.
That's basically what we did. The problem here was that processing was split into eight or so steps across ~25 streams of work between the backup steps and was far enough along the output files were generated, revving their generation number. Those files fed something like thirty follow-on jobs, so all the file generations had to be backed out before processing could run.
It all seemed horribly complicated and brittle to me at the time. Not sorry I don't work with it any more.
At my last job they had a custom variant of COBOL and hey I don’t know why everyone is playing it down. It was beautiful. You could make a full GUI form with full validations in like only a few lines of code.
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.
Cobol is mostly likely around because no one knows exactly what the code does. Missing design documents & decisions don't help either. Companies making money are risk adverse, they won't risk killing their golden goose over a rewrite, it's often companies that are not making money that go on massive rewrites believing that new tech will give them the Midas touch towards profit.
I had a contract about 10 years ago for a major city's water department. The contract was to convert an internal application for customer billing, written in COBOL running on the mainframe to a web application backed by Oracle.
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.
> All they could provide was the original COBOL source code ...
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?
I almost did a FORTRAN subcontracting gig like this to translate an old but accurate simulation of a mechanical system to Python. I literally got a binder full of FORTRAN to start with, though eventually (to my great relief) the guy I was going to work under got me digital copies. Didn't pan out anyway, though, since he didn't win the contract.
Reverse engineer and replace. It turned out the green screens were pretty simple to grok where everything was either the non-editable display of a record or the editable display of record. And the transitions from screen to screen were very deterministic so a one to one mapping of screens to web pages wasn't that difficult.
The new system was backed by an Oracle DB and that was provided, with schemas defined and another engineer was responsible for the ETL of the mainframe data to the Oracle DB. This was obviously helped a lot.
>Missing design documents & decisions don't help either.
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."
How ironic, isn't it. For some reason, everything written before the 90's still manages to work on particular platforms while everything after has been deprecated month by month.
I agree that making the change is preferable to reimplementing. Just saying you can’t assume that an old and battle tested codebase is an ops problem rather 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.)
Working at a large bank, a Cobol programmer once told me the use cases are very narrow, but that it's extremely dependable once deployed into production. To be a little blunt though, to process statements and track transactions with high dependability, it works well when you repel anyone with a low attention span or someone has a strong desire for learning new languages and programming paradigms. You need and want programmers who are more about making the same kind of sausage day in day out rather than innovation because at the end of the day, the bank statement and transactions are trivial but extremely important problems. In other words, it's an older programmer's workshop.
This comment appears to be fairly insulting. Is it implying that older programmers can't / won't / wouldn't like doing innovative programming?
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 once had a boss who was an old Cobol Cowboy, he walked me through a financial system that's still in use.
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.
I am aware, Cobol wasn't standardized until 1970 though.
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.
I had an assignment at the Dutch Tax Service and was surprised to learn that they were still actively developing new software in COBOL. The reason, I was told, was that they had many COBOL developers and not as many that were experienced in other languages. Most of these people, however will start their pensions in a couple of years, so they'll have nobody to maintain this stuff.
The Dutch government is unfortunately known for having IT projects fail constantly, they've already accumulated an enormous technical debt. They outsource a lot because the current staff is either close to retirement or just can't be motivated anymore to put in the effort. Hearing this is the least surprising to be honest.
I've done quite a bit of work in Dutch government IT and would like to add that the failure of these projects is often because of politics and constantly changing requirements. IT is often working really hard and doing the best they can, but scope creep, forced deadlines and constant changes in leadership make it nearly impossible to actually do things right.
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.
Yup, I told someone who worked there this and they agreed, but explained that their management doesn't seem to plan that far ahead. I'm not even sure they're really aware that this is coming.
That is one of the management's primary jobs to foresee this ... I know there are multiple layers of useless management in these institutions but this is basically saying they are incompetent at their job.
You are completely correct. There are so many levels of management that I never really fully grasped it and most managers are focused on their own personal growth, in stead of the performance of their units.
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.
My understanding is that part of COBOL's longevity stems from its particular handling of fixed-point math being a specified requirement of various financial contracts. Odd to see this write-up not mention fixed-point math, actually.
It's been interesting to observe this impedance mismatch in practice. My first job was writing software for a startup that sold to quant hedge funds. I did a bunch of research on my own, and one of the best practices I ran across was do not use floating point to represent money. Represent everything in terms of integer units of the most basic currency unit (usually cents), to avoid round-off errors. Then I took this information to my CEO, who shot me down on the basis that all their customers used floating point for their internal models, and so I'd be needlessly introducing friction.
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.
Seems like someone familiar with inflection points in floating point representation could pull an Office Space-style skimming scheme against a floating point based system by perfectly legal means simply by making a lot of transactions of carefully selected sizes.
Interesting idea. Most of the inflection points I've observed have actually been at transaction/analytics boundaries. Transactions are in integer units, analytics are in floating point. It's done this way because many algorithms (including most linear algebra, statistical, and machine-learning algorithms) operate on floats for efficiency, while transactions operate on ints for accuracy.
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.
Floating-point precision can work depending on the financial application. If you are back-testing on exchange data, your simulation code only buys or sells at the bid or ask prices, so even if the signal has floating point imprecision, it doesn't really affect the result. On valuation work, getting the inputs into a DCF/reverse DCF right is much more important than exact precision. I realize this is vastly different than writing an accounting application, but for most hedge funds, it probably won't make a difference to use floats vs. decimals.
> Then I took this information to my CEO, who shot me down on the basis that all their customers used floating point for their internal models, and so I'd be needlessly introducing friction.
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.
both COBOL and even RPG both excel at business math and on many systems you can put any face you want on these programs in the back end and just leverage years if not decades of work.
languages without oddities and gotchas do tend to lend themselves to stable systems
(I could google this but I feel like a discussion would be more fun!)
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?
In fixed point math, the decimal point (the units digit) is "fixed" at a particular value instead of "floating". A fixed-point number is an integer that represents values as a multiple of 1/N, so fixed-point multiplication requires adding an extra divide-by-N and fixed-point division requires adding an extra multiply-by-N. A floating point number represents numbers as a pair (e, m) such that the result is m * b^e (where b is the base, see below).
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).
You're thinking wrong. If your problem domain needs fixed point math (think financial data), then COBOL isn't "stuck" using it. COBOL is privileged to use it, and may well be faster than something that has to use a library to do it.
Why do you say stuck? What do you think is better at handling currency? I can think of integers (multiples of the smaller denomination) or fractions (which are quite slow), definitely not floats.
I agree that fixed point is the way to go for currency. But I read that as meaning COBOL didn't have floating point data types at all. I'm guessing that assumption was wrong. The advantage to floating point math over fixed point is speed. If it wasn't for that, nobody would ever want to use floating point.
No, fixed-point math is typically faster than floating-point math (except if you have many, many more transistors devoted to the floating-point.) The only time floating-point is ever faster than fixed-point in practice is when (1) your points really are floating, so 13 decimal places of precision is fine, but the magnitude of the result ranges over many orders of magnitude (Fourier transform results and calculator apps being good examples); and when (2) the floating-point hardware can't be used for fixed-point calculations and would just sit idle if you didn't find something to run on it.
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.
> The advantage to floating point math over fixed point is speed.
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.
IBM hardware has supported packed decimal arithmetic for... ever? The z9 hardware onwards includes decimal floating point (IEEEsomethingorother) support[0] (sizeable PDF warning).
Is it fixed point math or decimal floating point? These are not the same, but fixed point is fairly trivial to reimplement on any platform; there's even an official "embedded C" extension that adds support for it.
I hear a lot about the uptime of cobol/mainframe based applications, but the entire Commonwealth Bank ATM and eftpos systems used to go down for an hour or two at 3AM every Sunday, back in the day this was nightclub close and time for a kebab and caught me out quite a few times. It's been much better since they migrated.
I'm a bit young to have had any contact with COBOL, but I've worked in financial institutions implementing mission-critical code handling customer transactions in other languages. The first thing that springs to mind to ask is, what kind of features does COBOL offer to make these processes safer and less bug-prone? At least 75% of the code and associated reams of unit testing I've seen written in these applications is to deal with weird input and edge-cases. Is there anything specific about COBOL that is especially suited for dealing with this kind of task? I've never seen anything written about static analysis or formal modelling either. Is the compiler especially attuned to catching potential errors? Is there implicit run-time bounds checking and analysis like in Ada et al?
No, nothing like that. It is simply the first language ever used for these tasks (first language to be designed to look anything like English too). The language is so old that one of its designers is also the person that introduced the notion of "compiler".
Thank you, that's very interesting to know. I had guessed that there wasn't much, based upon its vintage, but I'd have thought that it must be very robust at some level to have dominated a mission-critical financial niche for so long.
> what kind of features does COBOL offer to make these processes safer and less bug-prone?
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.
My day job is writing German COBOL, i.e. ABAP. The language changed a lot and is quite usable, except they don't have namespaces. But the worst is all of the cruft that accumulated. Not just of legacy code, but also in the language itself. So many different paradigms, old frameworks, everything is still working. On the other hand it is very high level for the job to be done. SQL can be directly embedded and there is a syntax check. There are a lot of integrated tools that are heaven and hell in the same time. The database migrations are so easy, but source code management, deployment is hell.
Looking at the absurdly long code required to make factorials work makes you wonder what conveniences we are all used to without really appreciating them. And which ones will future programmers take for granted but are too niche now - maybe async/await or the borrow checker concepts, or is programming mostly "done"?
> Is there a code example where Cobol shines in comparison to, say, Python?
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.
3 years ago I learned that large insurance companies in India still use COBOL. That fact blew my mind. This fact (Estimates as high as 80% of financial transactions use... COBOL) further blows my mind as I thought only Indian financial institutions are rigid. Clearly not.
A Danish news article on the death of mainframes (or their unwillingness to die) where they have some stats that says that 10 out 10 of the largest insurance companies still use mainframes for they core systems. So learning that large insurance companies run Cobol isn't that surprising.
that's quite interesting! esp considering these ones went digital not so long ago. and makes me super curious why they went with Cobol? is it coz PSU -> lowest price bidding -> Cobol ? just blind guessing here.
I've heard this sentiment about Cobol often. As someone who has never seen Cobol or used it, how hard would it be for me to specialize in Cobol maintenance and porting? Is it really as impenetrable as it seems, requiring years of experience, or can someone like me work through a few books and get on it?
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.
I have used FORTRAN quite a bit and I assume that the situation with Cobol is similar. If you go into it with an open mind you will soon see common patterns that look crazy from a more modern language point of view but were widely used in that language. My FORTRAN code was full of GOTO which looks horrible today but that's how things got done and once you are used to it it makes sense.
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...
Is it a bad idea? I see articles like this all the time, and job postings with decent pay, $100k+ on Indeed. Maybe long term it's a bad idea to invest in a technology that's bound to disappear.
I would expect the number of actual jobs or contracts to be pretty low. Maybe better to attend a data science boot camp and make 100k+ that way with a better path to the future.
My first programming job (29 years ago!) was a COBOL gig. I worked for a company that wrote banking software, most of it COBOL and a little Assembler.
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.
From what I understood when I worked at LiveNation, every time you buy a ticket from Ticketmaster the transaction flows through some ancient spaghetti COBOL, probably running in Phoenix.
I really want to get a job writing COBOL. However, nobody will give me a chance at it. I recently applied for a few jobs in my area but they wanted 10+ years of COBOL so I was turned down. I learned in college (however would need to re-learn) and I really enjoyed it. I also enjoy financials and data.
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've had a limited exposure to COBOL and I consider it quite elegant for the problems it's trying to solve, particularly for column oriented transactional data processing, I found it interesting that on System Z, all of the IO, is done in the JCL that you use to start the program, not in the program itself.
In the JCL you just specify how to link the logical IO definitions in the program to the actual physical IO objects (real file names etc.) in the environment. The IO statements are still in the program.
I hate how the title says "powers the global economy" when it should be "powers banking systems". I spend a lot of money on many things, my smartphone, gsuite, slack, Netflix, Amazon, Dropbox, games, tools, hardware, and I would guess most of that stuff never touched Cobol. Meanwhile I pay 1usd monthly for my bank (which, btw already migrated). So saying it "powers the global economy" is definitely a bit of a stretch.
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.
When you spend the money on those things your bank or credit card merchant processes every one of those transactions. Cobol is almost always doing the day-end processing on those systems. Hence, while the products you use don't directly rely on COBOL, the fact remains that COBOL is powering the economic transactions that allow those businesses to exist currently.
My point is, COBOL is responsible for a really small % of said value per value transaction between me and said services. Linux, [Oracle/My]SQL, Java, JavaScript, C, anything from router firmware to Intel cpus powering the VMs is more relevant than said COBOL code.
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
Intel CPUs across the world can almost painlessly be swapped for AMD CPUs right now and only a small fraction of users would have to change anything.
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?
> Intel CPUs across the world can almost painlessly be swapped for AMD CPUs right now and only a small fraction of users would have to change anything.
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.
Why and where are you paying for your bank? Serious question I haven't seen any that do such a thing barring "low balance surcharges". Are there any benefits over one which pays you interest for your deposit?
The term from economics that describes the situation well is "switching costs". They're very high in this case, as comments regarding banks migrating away indicate.
This book is a great overview of the economics of these kinds of situations:
Modern mainframes are quite powerful machines:
"The dual frame z14, launched in July 2017, and the single frame z14, launched in April 2018, are based on the z14 chip, a 10-core processor running at 5.2 GHz. A z14 system can have a maximum of 240 Processing Unit (PU) cores, 170 of which can be configured to the customer's specification to run applications and operating systems, and up to 32 TB usable redundant array of independent memory (RAIM), some of which can be configured as Virtual Flash Memory (VFM). Each PU can be characterized as a Central Processor (CP), Integrated Firmware Processor (IFP), Integrated Facility for Linux (IFL) processor, Integrated Information Processor (zIIP), Internal Coupling Facility (ICF) processor, additional System Assist Processor (SAP) or as a spare."
I assumed "mainframe" automatically meant "computer from no later than the early 90s", since these days we just call them servers. Similar to how I'd assume "microcomputer" automatically means "desktop from no later than the early 90s".
No. IBM does I/O like you wouldn't believe. Plus, computers that call for service by themselves tend to allow people some sleep at night. There is an interesting history tidbit on the introduction of the NeXT Cube where Steve Jobs mentions it has mainframe like I/O.
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...