13 ms·

Cobol Still Powers the Global Economy

256 points by psim1 7y ago

dlivingston 7y ago
> “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.
- lostmsu 7y ago
  I'd be curious to see one. That statement seems extremely improbable.
  - 6thaccount2 7y ago
    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).
    - lostmsu 7y ago
      Exactly because there are no public benchmarks.
    - 0815test 7y ago
      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.
      - bin0 7y ago
        Not in that sense, in the sense of "how many cart checkouts, wire transfers, other business logic transactions can I perform per unit x time?"
      - 6thaccount2 7y ago
        Like user bin0 said below, a mainframe can do 30k to 1.1M transactions like wire transfers in a second. They also have rediculously high up times and much higher security (probably mostly via obscurity). Unfortunately, they're insanely expensive.
        hermitdev 7y ago
        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.
        6thaccount2 7y ago
        I assume the focus is on big businesses and banks that can afford those numbers. Kind of like how KDB+ is so expensive as they're targeting a niche audience. Even though that is purely software.
        OskarS 7y ago
        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.
    - Smoosh 7y ago
      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. ----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 0
      - lostmsu 7y ago
        Elapsed time is the typical benchmarking metric, used, for example, by the language benchmarks game. Not sure what "abstract metrics" are you referring to.
        igouy 7y ago
        fyi "Measurements of performance" https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0/com.ibm.perf.doc/ids_prf_041.htm https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0... "Latency and Throughput" https://www.oreilly.com/library/view/web-performance-tuning/059600172X/ch04s02.html https://www.oreilly.com/library/view/web-performance-tuning/...
        lostmsu 7y ago
        I know what latency and throughput are. I am asking what "abstract metrics" previous commenter was referring to as opposed to these.
      - 6thaccount2 7y ago
        Thanks for the helpful background. I think what I said still stands though. 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.
  - ethbro 7y ago
    Not particularly. It's analogous to saying 'A 60 year old language has better compilers than younger languages.' Which doesn't seem especially provocative.
    - lostmsu 7y ago
      It is quite provocative, considering the amount of activity over compiler's codebase. Which in case of COBOL is likely very close to 0.
      - lboc 7y ago
        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'. [0] https://www-01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?synkey=B984385H82239E03&from=spf https://www-01.ibm.com/software/support/lifecycleapp/PLCDeta... [1] https://en.wikipedia.org/wiki/GnuCOBOL https://en.wikipedia.org/wiki/GnuCOBOL
- tapland 7y ago
  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.
  - randomerr 7y ago
    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.
    - tapland 7y ago
      And the company willing to fork out ??? to migrate.
  - kristopolous 7y ago
    Your day job, in 2019, is COBOL on OpenVMS? really? Tell me more. Is this new code? Are you using new hardware? Do you want my old alpha?
    - tapland 7y ago
      Been doing this for just over a year and mostly been doing new development where the need has just asrisen. 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!
      - HeWhoLurksLate 7y ago
        Shameless plug for r/homelab- if you're interested in doing server stuff at home, they're a great community to be a part of.
  - kragen 7y ago
    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?
- AnimalMuppet 7y ago
  The fastest processing language... for what? 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...
  - tasty_freeze 7y ago
    > The fastest processing language... for what? 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.
    - Tehdasi 7y ago
      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.
    - Annatar 7y ago
      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.
fc_barnes 7y ago
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.
- Lowkeyloki 7y ago
  I'd love to know more about what it does with fixed point math that's considered particular or special. Any links would be greatly appreciated. Even more curious to me is how COBOL squares as fast if it's stuck using fixed point math.
  - AnimalMuppet 7y ago
    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.
    - protomyth 7y ago
      And it's not like IBM hasn't spent the cash to get decent representations and accelerated hardware over the years.
  - rnhmjoj 7y ago
    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.
    - jacquesc 7y ago
      Not great for handling Bitcoin transactions. I would highly recommend against using Cobol for any new cryptocurrency projects.
    - Lowkeyloki 7y ago
beigeoak 7y ago
What an incredible website 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.
zeotroph 7y ago
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"? http://rosettacode.org/wiki/Factorial#COBOL http://rosettacode.org/wiki/Factorial#COBOL or also http://rosettacode.org/wiki/FizzBuzz#COBOL http://rosettacode.org/wiki/FizzBuzz#COBOL Is there a code example where Cobol shines in comparison to, say, Python?
- dmix 7y ago
  Oh no every time I visit Rosettacode I spend an hour looking up languages on Wikipedia. Today’s winner is dc > dc is the oldest surviving Unix language. https://en.wikipedia.org/wiki/Dc_(computer_program)?oldformat=true https://en.wikipedia.org/wiki/Dc_(computer_program)?oldforma...
  - sparkling 7y ago
    I'm amazed, it is even included in the latest MacOS release
    - dmix 7y ago
      It’s like awk/sed, it has to be packaged with any unixy system.
- js8 7y ago
  > 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.
tomlockwood 7y ago
> Some banks have spent hundreds of millions of dollars and several years migrating systems. 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-way-down/ https://increment.com/programming-languages/cobol-all-the-wa...
- flukus 7y ago
  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.
  - Quiza12 7y ago
    No extra onion sauce for you!
  - quickthrower2 7y ago
    Ergo you spent all your $ in the club!
segmondy 7y ago
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.
- RcouF1uZ4gsC 7y ago
  >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."
  - ethbro 7y ago
    The benefit of old code is that you've usually found all the bugs in 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.
    - gshdg 7y ago
      Until you need to update it to cope with Y2K or Y2K38 or GDPR or some other external factor...
      - ethbro 7y ago
        True. But changes of that natures vs reimplementing the entire system?
davidw 7y ago
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: https://en.wikipedia.org/wiki/Information_Rules https://en.wikipedia.org/wiki/Information_Rules
xxxpupugo 7y ago
...because people aren't willing to change it. That doesn't make Cobol sounds less like a fossil in any way. It will be go away eventually.
hermitdev 7y ago
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...
- icxa 7y ago
  > 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?
  - nexuist 7y ago
    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.
    - hermitdev 7y ago
      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.
aksss 7y ago
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.
mushufasa 7y ago
https://wordsandbuttons.online/if_i_were_to_invent_a_programming_language_for_the_21st_century.html https://wordsandbuttons.online/if_i_were_to_invent_a_program...
Aloha 7y ago
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.
- throwawayForMe2 7y ago
  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.
codr7 7y ago
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.
- kragen 7y ago
  When Pascal was published in 1970, COBOL was already 11 years old.
  - codr7 7y ago
    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.
orpheline 7y ago
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. It took four days to back everything out.
- tuananh 7y ago
  it’s painful indeed. my first real job out of college was at a bank too. migrating a system from cobol to java 6 at the time. scary time.
- throwawayForMe2 7y ago
  Standard procedure was to have a pre-batch and post-batch backup step. Any major problems you restore everything to the pre-batch state.
  - orpheline 7y ago
    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.
sys_64738 7y ago
I used COBOL when it was cool back in the 80s!
- pfundstein 7y ago
  COBOL was never cool. A year after it was created (in 1959) people were already predicting its demise. Yet here we are.
  - sys_64738 7y ago
    If you remove the Business part from COBOL then it is :)
  - protomyth 7y ago
    It might not have been cool, but the car you could buy during the 90's working on COBOL projects was pretty spiffy.
RickJWagner 7y ago
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. Ah, the memories. Long live COBOL.
apaprocki 7y ago
I was curious if anyone has published a decent chunk of “modern” COBOL since articles and stories never really link to large working systems. It turns out Walmart has! Enjoy: https://github.com/walmartlabs/zFAM/blob/master/Source/ZFAM007.cbl https://github.com/walmartlabs/zFAM/blob/master/Source/ZFAM0...
- nn3 7y ago
  Interesting it has a "come from". So the execution will stop somewhere, but it's defined somewhere else. That's worse than GOTO I would say. PERFORM 4200-COPY-ECR THRU 4200-EXIT.
_bxg1 7y ago
They still run it on actual mainframes? Wouldn't an emulator running on a modern machine be many times faster?
- protomyth 7y ago
  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.
- kryptiskt 7y ago
  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." https://en.wikipedia.org/wiki/IBM_zEnterprise_System https://en.wikipedia.org/wiki/IBM_zEnterprise_System
  - _bxg1 7y ago
    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".
    - illirik 7y ago
      There's a number of big differences between a modern IBM mainframe and commodity servers. For one, the architecture: https://en.wikipedia.org/wiki/Z/Architecture https://en.wikipedia.org/wiki/Z/Architecture
ajxs 7y ago
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?
- krastanov 7y ago
  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".
  - ajxs 7y ago
    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.
- hanniabu 7y ago
  > 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.
  - _trampeltier 7y ago
    If we can't change from COBOL to something else now, I have no idea how we could change todays software in 2050.
dav 7y ago
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.
anotherevan 7y ago
If your company is looking for training materials for COBOL or other mainframe technology, it might be worth taking a look at Interskill. https://interskill.com/ https://interskill.com/ or https://interskill.co.uk/ https://interskill.co.uk/ Disclosure: I work for them.
os7borne 7y ago
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.
- mrweasel 7y ago
  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. They cite: https://www.share.org/blog/mainframe-matters-how-mainframes-keep-the-financial-industry-up-and-running https://www.share.org/blog/mainframe-matters-how-mainframes-...
  - tapland 7y ago
    Looking at job listings over a few months this is easy to verify for the nordic countries.
- tapland 7y ago
  So do insurance companies in the nordic countries in Europe.
- tsjq 7y ago
  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.
  - jacobush 7y ago
    Maybe they had a digital "core" backend for reporting and such, even though front offices etc were on paper.
    - 7y ago
donkeyd 7y ago
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.
- hnarn 7y ago
  > The reason, I was told, was that they had many COBOL developers and not as many that were experienced in other languages. 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.
  - donkeyd 7y ago
    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.
    - consp 7y ago
      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.
      - donkeyd 7y ago
        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.
seventhtiger 7y ago
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.
- Ididntdothis 7y ago
  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...
  - seventhtiger 7y ago
    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.
    - Ididntdothis 7y ago
      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.
    - NikolaeVarius 7y ago
      I think that it will only disappear in the sense that the heat death of the universe is inevitable
_glass 7y ago
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.
aetherspawn 7y ago
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.
dejaime 7y ago
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.
- Nasrudith 7y ago
  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?
- jnty 7y ago
  Hang on - how are you paying for all these services? The money will almost certainly 'touch' a legacy banking mainframe at some point.
- artimaeis 7y ago
  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.
  - dejaime 7y ago
    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
jason_slack 7y ago
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.

256 points by psim1 7y ago

> “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.

lostmsu 7y ago
I'd be curious to see one. That statement seems extremely improbable.
- 6thaccount2 7y ago
  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).
  - lostmsu 7y ago
    Exactly because there are no public benchmarks.
  - 0815test 7y ago
    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.
    - bin0 7y ago
      Not in that sense, in the sense of "how many cart checkouts, wire transfers, other business logic transactions can I perform per unit x time?"
    - 6thaccount2 7y ago
      Like user bin0 said below, a mainframe can do 30k to 1.1M transactions like wire transfers in a second. They also have rediculously high up times and much higher security (probably mostly via obscurity). Unfortunately, they're insanely expensive.
      - hermitdev 7y ago
        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.
        6thaccount2 7y ago
        I assume the focus is on big businesses and banks that can afford those numbers. Kind of like how KDB+ is so expensive as they're targeting a niche audience. Even though that is purely software.
      - OskarS 7y ago
        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.
  - Smoosh 7y ago
    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. ----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 0
    - lostmsu 7y ago
      Elapsed time is the typical benchmarking metric, used, for example, by the language benchmarks game. Not sure what "abstract metrics" are you referring to.
      - igouy 7y ago
        fyi "Measurements of performance" https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0/com.ibm.perf.doc/ids_prf_041.htm https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0... "Latency and Throughput" https://www.oreilly.com/library/view/web-performance-tuning/059600172X/ch04s02.html https://www.oreilly.com/library/view/web-performance-tuning/...
        lostmsu 7y ago
        I know what latency and throughput are. I am asking what "abstract metrics" previous commenter was referring to as opposed to these.
    - 6thaccount2 7y ago
      Thanks for the helpful background. I think what I said still stands though. 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.
- ethbro 7y ago
  Not particularly. It's analogous to saying 'A 60 year old language has better compilers than younger languages.' Which doesn't seem especially provocative.
  - lostmsu 7y ago
    It is quite provocative, considering the amount of activity over compiler's codebase. Which in case of COBOL is likely very close to 0.
    - lboc 7y ago
      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'. [0] https://www-01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?synkey=B984385H82239E03&from=spf https://www-01.ibm.com/software/support/lifecycleapp/PLCDeta... [1] https://en.wikipedia.org/wiki/GnuCOBOL https://en.wikipedia.org/wiki/GnuCOBOL
tapland 7y ago
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.
- randomerr 7y ago
  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.
  - tapland 7y ago
    And the company willing to fork out ??? to migrate.
- kristopolous 7y ago
  Your day job, in 2019, is COBOL on OpenVMS? really? Tell me more. Is this new code? Are you using new hardware? Do you want my old alpha?
  - tapland 7y ago
    Been doing this for just over a year and mostly been doing new development where the need has just asrisen. 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!
    - HeWhoLurksLate 7y ago
      Shameless plug for r/homelab- if you're interested in doing server stuff at home, they're a great community to be a part of.
- kragen 7y ago
  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?
AnimalMuppet 7y ago
The fastest processing language... for what? 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...
- tasty_freeze 7y ago
  > The fastest processing language... for what? 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.
  - Tehdasi 7y ago
    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.
  - Annatar 7y ago
    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.

fc_barnes 7y ago

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.

Lowkeyloki 7y ago
I'd love to know more about what it does with fixed point math that's considered particular or special. Any links would be greatly appreciated. Even more curious to me is how COBOL squares as fast if it's stuck using fixed point math.
- AnimalMuppet 7y ago
  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.
  - protomyth 7y ago
    And it's not like IBM hasn't spent the cash to get decent representations and accelerated hardware over the years.
- rnhmjoj 7y ago
  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.
  - jacquesc 7y ago
    Not great for handling Bitcoin transactions. I would highly recommend against using Cobol for any new cryptocurrency projects.
  - Lowkeyloki 7y ago

beigeoak 7y ago

What an incredible website 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.

zeotroph 7y ago

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"? http://rosettacode.org/wiki/Factorial#COBOL http://rosettacode.org/wiki/Factorial#COBOL or also http://rosettacode.org/wiki/FizzBuzz#COBOL http://rosettacode.org/wiki/FizzBuzz#COBOL Is there a code example where Cobol shines in comparison to, say, Python?

dmix 7y ago
Oh no every time I visit Rosettacode I spend an hour looking up languages on Wikipedia. Today’s winner is dc > dc is the oldest surviving Unix language. https://en.wikipedia.org/wiki/Dc_(computer_program)?oldformat=true https://en.wikipedia.org/wiki/Dc_(computer_program)?oldforma...
- sparkling 7y ago
  I'm amazed, it is even included in the latest MacOS release
  - dmix 7y ago
    It’s like awk/sed, it has to be packaged with any unixy system.
js8 7y ago
> 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.

tomlockwood 7y ago

> Some banks have spent hundreds of millions of dollars and several years migrating systems. 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-way-down/ https://increment.com/programming-languages/cobol-all-the-wa...

flukus 7y ago
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.
- Quiza12 7y ago
  No extra onion sauce for you!
- quickthrower2 7y ago
  Ergo you spent all your $ in the club!

segmondy 7y ago

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.

RcouF1uZ4gsC 7y ago
>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."
- ethbro 7y ago
  The benefit of old code is that you've usually found all the bugs in 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.
  - gshdg 7y ago
    Until you need to update it to cope with Y2K or Y2K38 or GDPR or some other external factor...
    - ethbro 7y ago
      True. But changes of that natures vs reimplementing the entire system?

davidw 7y ago

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: https://en.wikipedia.org/wiki/Information_Rules https://en.wikipedia.org/wiki/Information_Rules

xxxpupugo 7y ago

...because people aren't willing to change it. That doesn't make Cobol sounds less like a fossil in any way. It will be go away eventually.

hermitdev 7y ago

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...

icxa 7y ago
> 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?
- nexuist 7y ago
  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.
  - hermitdev 7y ago
    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.

aksss 7y ago

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.

mushufasa 7y ago

https://wordsandbuttons.online/if_i_were_to_invent_a_programming_language_for_the_21st_century.html https://wordsandbuttons.online/if_i_were_to_invent_a_program...

Aloha 7y ago

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.

throwawayForMe2 7y ago
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.

codr7 7y ago

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.

kragen 7y ago
When Pascal was published in 1970, COBOL was already 11 years old.
- codr7 7y ago
  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.

orpheline 7y ago

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. It took four days to back everything out.

tuananh 7y ago
it’s painful indeed. my first real job out of college was at a bank too. migrating a system from cobol to java 6 at the time. scary time.
throwawayForMe2 7y ago
Standard procedure was to have a pre-batch and post-batch backup step. Any major problems you restore everything to the pre-batch state.
- orpheline 7y ago
  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.

sys_64738 7y ago

I used COBOL when it was cool back in the 80s!

pfundstein 7y ago
COBOL was never cool. A year after it was created (in 1959) people were already predicting its demise. Yet here we are.
- sys_64738 7y ago
  If you remove the Business part from COBOL then it is :)
- protomyth 7y ago
  It might not have been cool, but the car you could buy during the 90's working on COBOL projects was pretty spiffy.

RickJWagner 7y ago

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. Ah, the memories. Long live COBOL.

apaprocki 7y ago

I was curious if anyone has published a decent chunk of “modern” COBOL since articles and stories never really link to large working systems. It turns out Walmart has! Enjoy: https://github.com/walmartlabs/zFAM/blob/master/Source/ZFAM007.cbl https://github.com/walmartlabs/zFAM/blob/master/Source/ZFAM0...

nn3 7y ago
Interesting it has a "come from". So the execution will stop somewhere, but it's defined somewhere else. That's worse than GOTO I would say. PERFORM 4200-COPY-ECR THRU 4200-EXIT.

_bxg1 7y ago

They still run it on actual mainframes? Wouldn't an emulator running on a modern machine be many times faster?

protomyth 7y ago
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.
kryptiskt 7y ago
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." https://en.wikipedia.org/wiki/IBM_zEnterprise_System https://en.wikipedia.org/wiki/IBM_zEnterprise_System
- _bxg1 7y ago
  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".
  - illirik 7y ago
    There's a number of big differences between a modern IBM mainframe and commodity servers. For one, the architecture: https://en.wikipedia.org/wiki/Z/Architecture https://en.wikipedia.org/wiki/Z/Architecture

ajxs 7y ago

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?

krastanov 7y ago
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".
- ajxs 7y ago
  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.
hanniabu 7y ago
> 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.
- _trampeltier 7y ago
  If we can't change from COBOL to something else now, I have no idea how we could change todays software in 2050.

dav 7y ago

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.

anotherevan 7y ago

If your company is looking for training materials for COBOL or other mainframe technology, it might be worth taking a look at Interskill. https://interskill.com/ https://interskill.com/ or https://interskill.co.uk/ https://interskill.co.uk/ Disclosure: I work for them.

os7borne 7y ago

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.

mrweasel 7y ago
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. They cite: https://www.share.org/blog/mainframe-matters-how-mainframes-keep-the-financial-industry-up-and-running https://www.share.org/blog/mainframe-matters-how-mainframes-...
- tapland 7y ago
  Looking at job listings over a few months this is easy to verify for the nordic countries.
tapland 7y ago
So do insurance companies in the nordic countries in Europe.
tsjq 7y ago
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.
- jacobush 7y ago
  Maybe they had a digital "core" backend for reporting and such, even though front offices etc were on paper.
  - 7y ago

donkeyd 7y ago

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.

hnarn 7y ago
> The reason, I was told, was that they had many COBOL developers and not as many that were experienced in other languages. 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.
- donkeyd 7y ago
  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.
  - consp 7y ago
    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.
    - donkeyd 7y ago
      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.

seventhtiger 7y ago

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.

Ididntdothis 7y ago
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...
- seventhtiger 7y ago
  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.
  - Ididntdothis 7y ago
    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.
  - NikolaeVarius 7y ago
    I think that it will only disappear in the sense that the heat death of the universe is inevitable

_glass 7y ago

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.

aetherspawn 7y ago

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.

dejaime 7y ago

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.

Nasrudith 7y ago
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?
jnty 7y ago
Hang on - how are you paying for all these services? The money will almost certainly 'touch' a legacy banking mainframe at some point.
artimaeis 7y ago
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.
- dejaime 7y ago
  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

jason_slack 7y ago

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.