back to article IBM creates a COBOL compiler – for Linux on x86

IBM has announced a COBOL compiler for Linux on x86. News of the offering appeared in an announcement that states: "IBM COBOL for Linux on x86 1.1 brings IBM's COBOL compilation technologies and capabilities to the Linux on x86 environment," and describes it as "the latest addition to the IBM COBOL compiler family, which …

  1. Anonymous Coward
    Anonymous Coward

    Too late....

    Ten (hm.... twelve?) years ago this would have been a vital piece of information. In our company we did use IBM "mainframes" (yeah, no longer the bakkelit and steel kind, sadly enough) until then. For political reasons we were pushed to use the Siemens system (ok, make that more like.... 15 years ago), since it was a more local company. Migration started. Then they sold it to Fujitsu. Then Fujitsu said it won't continue development, and couldn't we all stop using those systems. Then they started charging higher prices for the systems. They are usually leased. Effort is underway to migrate everything to x86 based systems, but it is a large application landscape, and apparently the very well thought out assembler code (and the COBOL code) are really very finely tuned, and the modern systems struggle to achieve the same speed in their calculations. Might have something to do with the more "modern" (don't make me laught) programming languages, and the lost appreciation for cpu power and memory being limited ressources. Guess what, when you need to do a lot of these calculations concurrently these things do matter.

    With IBM's current offer we could have (maybe...) transferred a lot of the legacy code to x86 systems quite a bit faster. The need to rewrite stuff for the 21st century (so that not only greybeards can maintain it) still would be there, but we could get rid of that "mainframe" system rather sooner than later. Cost wise it would be appreciated.

    Cost-wise it is nonsense to use Oracle for everything new. Basically it negates the cost savings of the migration.... *head@desk*

    1. Peter Gathercole Silver badge

      Re: Too late....

      Many years ago, I was working for IBM's AIX support centre, and we were supporting the IBM VS-COBOL product.

      This was not an IBM compiler, but a slightly tweaked MicroFocus COBOL 'compiler' (I'll explain why that is on inverted comma's shortly).

      It was partly to support CICS/6000, which was a CICS implementation on the RS/6000.

      Although this was an IBM package, it was not actually a port of mainframe CICS, but a re-implementation using the Tuxedo transaction handler, which at the time was a Transarc product, before IBM bought Transarc.

      Although the RS/6000 was, on paper, faster than the mainframes available at the time, at least in CPU speed, the performance of CICS/6000 and the COBOL code was dire, such that the few people who actually trialled the systems to port their systems rejected them. The reasons why performance was slow was because CICS/6000 was effectively an emulation, and the COBOL 'compiler' was really a p-code compiler whose results were interpreted by a very large runtime.

      Within a few years, IBM deprecated their VS-COBOL compiler on AIX, telling customers to switch to the MicroFocus product in it's place, and also quietly withdrew the CICS/6000 system (shortly followed by Tuxedo itself).

      I wonder what compiler IBM currently ship for AIX (and probably Linux on x86). Let's hope they make a better job that they did for AIX in the past.

      1. cornetman Silver badge

        Re: Too late....

        > The reasons why performance was slow was because CICS/6000 was effectively an emulation

        I worked on CICS for AIX 2 & 3 on RS/6000 and I don't remember any emulation. It was a complete, from-the-ground rewrite in C. Would you care to clarify?

        1. Steve Channell

          Re: Too late....

          CICS/6000 mapped the CICS command interface (API) (not macros) to the Encinia TP monitor (not BEA/Oracle Tuxedo).

          Encinia was slower than CICS/ESA because it used Unix processes instead of the TCB threads and pipes instead of CSA.

    2. doublelayer Silver badge

      Re: Too late....

      "with the more "modern" (don't make me laught) programming languages, and the lost appreciation for cpu power and memory being limited ressources. Guess what, when you need to do a lot of these calculations concurrently these things do matter."

      Absolutely, but I have to wonder about a few things:

      1. The computers you're using to run the old assembly and COBOL probably cost more than cheaper modern computers. Have you calculated the various resource costs of using those modern computers? I can run an inefficient program on a modern computer and have it complete faster and cheaper than running an optimized program on an old computer. I can also produce an optimized program that will be even better on the modern computer.

      2. So your calculations are going slowly with some modern language you don't like. Have you tried multiple languages? There aren't a lot of COBOL systems running on modern hardware but there are a ton of C ones and C is also pretty fast. If C doesn't work, there are other low-level languages available which have execution speed as an important factor. If you're comparing assembly to Python, it's not a fair comparison.

      3. So you can't write it to run on modern computers, even in C. The assembly that was written decades ago was probably quite well-tuned. Have you considered writing well-tuned assembly again today if you need performance so badly? The people who write compilers know how to do it. Maybe it's not modern developers causing the problem, but comparing two very different approaches: one where people worked hard to speed it up and one where a straw replacement was created quickly and judged even faster.

      1. Anonymous Coward
        Anonymous Coward

        Re: Too late....

        Not to mention the resource costs of hiring somebody to work with COBOL or any of those ancient languages. I worked with COBOL, Assembly, and JCL on IBM MVS years ago in my first job out of college, so can somewhat relate.

        Just speaking for myself, I wouldn't abandon what I'm doing right now to go back to working with that stuff for less than a significant bump over what I'm making now. Maybe for $250k a year, and even then I'd have to think about it.

        I'd have to imagine a lot of people who might have some familiarity with those old languages might feel the same. They're probably late in their career (as I am), and wouldn't deviate from what will carry them through the remaining years until retirement for less than big bucks.

        A college kid out of college who knows more modern languages would probably be FAR cheaper than us old fogies who might have worked with COBOL in past lives. You could hire four of them for one of us I bet.

    3. J27

      Re: Too late....

      Oracle is for suckers. They price at that, "large enterprise lock-in" level. Unless you're already locked in, you'd be crazy to use it.

    4. StargateSg7

      Re: Too late....

      In the mid-90's I created a custom set of C/C++ pre-processor macros and instructions that allowed older programmers to code entirely in COBOL on standardized desktop Windows PC's directly within their modern C/C+ IDE system.

      That code was then converted to the typical of the 90's-era IBM 3090 and 2000-era newer Z-series mainframe instructions which ran 1960's era financial code at lightning speed! My filthy-rich COBOL coder friend made a MINT off that C/C++ MACRO COBOL-to-C preprocessor instruction set by keeping older Toronto, Chicago and New York financial institutions happy by upkeeping all that COBOL-based banking code STILL running today even in 2021. I can't believe the banks STILL run that 1960's COBOL-based financial services code in 2021 !!! Yikes!

      My COBOL programmer friend FINALLY retired a multi-millionaire to his houses in Florida, Toronto, Victoria (BC Canada), Paris (France) and some island off the Greek coast while I live in a shoebox in bloody expensive Vancouver! I noticed his message with him drinking large bottles of wine on a quiet and warm beach in Greece today!

      Oh Well! I missed that money boat rather badly!

      v

  2. Admiral Grace Hopper

    C120-ABOUT-TIME

    MOVE "ABOUT TIME" TO DISPLAY-RECORD-MESS.

    WRITE DISPLAY-RECORD.

    STOP RUN

    1. Warm Braw

      Re: C120-ABOUT-TIME

      The significant developments actually happened a while back - TX Series for Multiplatforms - making a CICS environment available on Linux (and AIX) and, similarly, DB2: COBOL only really continues to exist in a symbiotic/parasitic relationship with transaction management or database management middleware.

      As far as I can gather, this announcement simply means that there is an IBM alternative to the Micro Focus COBOL compiler that was previously the only option for porting your (DB2/CICS)+COBOL code to Linux.

  3. jake Silver badge

    If anyone is interested ...

    ... I've been using GnuCOBOL (Wiki) on Slackware (pkgs.org) for a while now. It works just as it says on the tin, with no histrionics. Recommended.

    1. big_D Silver badge

      Re: If anyone is interested ...

      Our old ERP system is written in MicroFocus COBOL, it is currently being replaced by a system written in Java. It was moved from UNIX and Linux to run under POSIX on Windows Server.

      The problem though, is that COBOL isn't COBOL. Each manufacturer put their own additions and formatting short-cuts into their own versions of COBOL, so you can run standard COBOL through just about any COBOL compiler, but if you have DEC COBOL code, it won't simply re-compile in Gnu or MicroFocus, you will need to do a lot of editing and re-formatting to get it to work - for instance, DEC COBOL did away with the specific column starts and maximum, 80 character line length way-back-when, along with caps-only. Porting just that change over to another COBOL compiler at the time meant a huge effort to re-format, and in many cases re-write, section of code to get the compiler to stop spitting the dummy (I assume that most implementations of COBOL have seen fit to dispense with the column usage and page width limitations in the meantime).

      If you have IBM COBOL code, having a native IBM COBOL compiler on the target platform is a huge saving in time and effort.

      Another area is optimization, if the compiler optimizes differently, you can end up with different results, as one mainframe sales rep learnt the hard way. We had an array of VAX minis in a data centre and the mainframe rep was trying to get us to switch. The company delivered a test machine for us to "play" with, along with a piece of demo software. We set aside a VAX for the tests and he told us the FORTRAN test program he brought to us on tape would keep the VAX busy for a few weeks, but the mainframe would be done in about a week and we should give him a call, once the mainframe was finished...

      By the time he was back in the office, there was a note for him to call us back. The VAX was finished. It turns out the VAX FORTRAN compiler had good optimization and the mainframe FORTRAN compiler didn't do such a good job. The mainframe compiled and ran the code as it was given. The VAX compiler worked out that the code had no inputs, did some stuff and then had no outputs. It worked out that no input + no output means it can optimize everything in the middle out of the executable! (The test program created a very large multi-dimensional array, filled it with random numbers, performed calculations on the array, then deleted the array, before ending.)

      1. jake Silver badge

        Re: If anyone is interested ...

        As I said, it works as it says on the tin. Give it a try, it'll cost you nothing but a bit of time[0] ... and at the very worst, you just might learn something.

        It is an approachable variation on the theme, but make no mistake, it's no mere toy. I've helped ween a couple companies off of big iron with it.

        [0] Yes, I know, we all have !copious free time ...

      2. RegGuy1 Silver badge

        Each manufacturer put their own additions

        So that's where M$ learned the power of Embrace, Extend, Extinguish.

  4. Anonymous Coward
    Anonymous Coward

    Whilst I applaud the effort it must have taken, I am pretty sure this is something someone had that IBM thought they could monetise. They will try to get people using it, then totally fail to support it because the one guy who wrote it and knew how it worked would have been 'let go' for being too old/expensive.

    1. Adelio

      Sad but probably true, IBM no longer cares about keeping people with skills, just cheap people!

  5. Eclectic Man Silver badge
    Happy

    [Aside] Storage media

    The picture shows storage media all of which I have actually used for real. Punched cards which we used for the 'O'-level course on Hatfield Polytechnic's DEC System 10 computer, 9" floppy discs for the ICL mini computer on which I tried to learn Cobol, 5.25" floppy which I used in my first job, 3.5" floppies on my first personal computer (an Amstrad PCW512) and which I once used to hack into a customer computer using the 'boot from floppy' attack (it's ok the customer was watching at tithe time), and a USB stick which I use nowadays.

    Of course now my camera uses SD cards to store the proof of my incompetence with technical equipment.

    1. John Arthur
      Meh

      Re: [Aside] Storage media

      I hate to be a pendant but weren't those large floppies 8" rather than 9"? Yes, I am an old pendant!

      1. nijam Silver badge

        Re: [Aside] Storage media

        > I hate to be a pendant

        Well, just hang on for now...

        1. John Arthur

          Re: [Aside] Storage media

          The use of the term pendant is perhaps confined to the UK and refers to an uppity news columnist calling Tim Worstall, sadly late of these pages, as a pendant when she was criticising him for being a pedant. So pendant it is from now on...

          1. Eclectic Man Silver badge

            Re: [Aside] Storage media

            Thank you, from now on I shall use the term "PENDANT ALERT" for all my typographic and syntactic 'corrections'.

        2. DaemonProcess

          Re: [Aside] Storage media

          when i was in ICL the dedicated word processor floppy disks were 10" a-hem.

          1. Warm Braw

            Re: [Aside] Storage media

            They go back in office automation rather longer than that!

          2. Admiral Grace Hopper

            Re: [Aside] Storage media

            It Can't Last (but it still lives on as one of the few parts of Fujitsu delivering a profit).

      2. JacobZ
        Coat

        Re: [Aside] Storage media

        As always, some people want to make it into a disk-measuring contest

        1. Sudosu Bronze badge

          Re: [Aside] Storage media

          They are so quick to whip out their floppies to compare.

      3. GruntyMcPugh Silver badge

        Re: [Aside] Storage media

        Yeah 8", I did a contract at a place that ran an old IBM System 34 with a floppy auto loader thingy, although I only worked on their AS/400.

        1. Eclectic Man Silver badge

          Re: [Aside] Storage media

          But I was using an ICL mini computer, not IBM, and I'm sure the floppy discs were 9".

          Although I grant you there is no ruler on the picture, so maybe the Register's esteemed authors could tell us what size the discs in the photo are?

          1. Richard Plinston

            Re: [Aside] Storage media

            > But I was using an ICL mini computer, not IBM, and I'm sure the floppy discs were 9".

            No, they weren't.

            ICL ME29 had 8 inch discs.

            ICL DRS20 Models 40 and 50 had 8 inch.

            I still have some 8 inch discs that were used in those systems.

            1. ghp

              Re: [Aside] Storage media

              Correct, first ICL floppy disks were 8". I hadn't heard about 9" before. Floppies that is.

              1. Anonymous Coward
                Anonymous Coward

                Re: [Aside] Storage media

                Well mine's a 9-incher.

                No, wait. I've just double checked. 2-incher.

                Where's it gone?

        2. QuiteEvilGraham

          Re: [Aside] Storage media

          Ha - my first job included looking after the payroll code (and weekly backups) on such a dinosaur.

          It had a line editor, so we used to make any program changes in CMS (which had, and still has, a very decent editor) and write the code to 8" floppies on our 4381 (which IIRC were for microcode updates, amongst other things, but conveniently accessible), walk downstairs and shove them into the system-34 for compilation. Allegedly it was an "office machine" but it could fairly heat up a non air conditioned room.

        3. Anonymous Coward
          Anonymous Coward

          Re: [Aside] Storage media

          I did sysadmin work on an IBM System/36 in college that had 8-inch floppy magazine readers. Ten disks per magazine IIRC.

          I'd start backups on that thing and let it run for a couple hours, just sitting there baby sitting swapping magazines.

          Wow, that brings back memories. Now I feel REALLY old.

          1. Alistair
            Windows

            Re: [Aside] Storage media

            I did sysadmin work on an IBM System/36 in college that had 8-inch floppy magazine readers

            ..... MAPICSII, SYS36, RPGII .....

            Dear GOD don't remind me of that mess, it was the 2nd or 3rd installation here in Canuckistan.

            1. jake Silver badge

              Re: [Aside] Storage media

              "Dear GOD don't remind me of that mess"

              It might have been a mess ... but I'll bet you use things you learned back then every time you troubleshoot a modern system. Things that kids today don't learn, because they are "archaic".

    2. beep54
      Happy

      Re: [Aside] Storage media

      There was nothing more exhilarating/demoralizing than finding your batch cards produced an endless supply of mostly (but not quite) blank pages. "Excuse me sir, but I think that's mine and that you should terminate it."

      1. Eclectic Man Silver badge

        Re: [Aside] Storage media

        One of our early tasks was to write a program in BASIC to print out a Christmas Tree. Most of us used the 'new line' command, but one lad used 'new page' and had a tall, but rather sparse tree.

    3. Steve Graham

      Re: [Aside] Storage media

      Didn't the Amstrad actually use 3-inch floppies?

      1. big_D Silver badge

        Re: [Aside] Storage media

        Yes, the Amstrad (and the Einstein) used 3" stiffies, not 3.5" semi-floppies. The 3" ones were double sided, in that the drive was single sided, but you could flip the disk over and use the back.

        1. GruntyMcPugh Silver badge

          Re: [Aside] Storage media

          and rectangular iirc.

          1. big_D Silver badge
            Coat

            Re: [Aside] Storage media

            The casing, yes. The disks themselves were still round, not oblong.

            Mines the one with the 3" disk with Arnor Protext in the pocket.

    4. Arthur the cat Silver badge

      Re: [Aside] Storage media

      Bah! No paper tapes!

      1. jake Silver badge

        Re: [Aside] Storage media

        "Bah! No paper tapes!"

        Of course not, silly! They've all been re-punched in Mylar for longevity.

    5. Rob Daglish

      Re: [Aside] Storage media

      Errr... didn’t the Amstrad PCW512 use 3” disks? I remember an Amstrad PC1512 which had twin 5.25” drives (although for a leg and half and arm, you could have a small HDD fitted in place of the second floppy), and then maybe an Amstrad PC2086 with twin 3.5” drives. If I remember rightly they both had a recess in the case for the monitor stand to sit in, and certainly one of them had a set of AA batteries to store settings...

    6. Roland6 Silver badge

      Re: [Aside] Storage media

      >Punched cards which we used for the 'O'-level course on Hatfield Polytechnic's DEC System 10 computer.

      Glutten for punishment?

      We switched to that nice blue folding paper tape that the Hatfield DEC10 had readers for and which if you had problems in the small hours could be fed through the teletype tape reader...

      So which year did you do your Hatfield Poly supported O-level - mine was '77 - we raised some eyebrows as 2 of us used more DEC10 resources than the entire A-level class. It was only natural that we would pursue a career in IT...

  6. Denarius
    Happy

    COBOL

    the language that never dies. The journos predicting its death do. Still have a soft spot for it, altho I never used it in anger

    1. Teiwaz

      Re: COBOL

      Yep, could do with a make-over to modernise it a little, just for presentation.

      not all in caps (all in caps looks so retro, and not in a good way).

      separate the Divisions into separate files (would look better, maybe a little more awkward to edit, maybe though)

      Still nothing quite so logical and readable as COBOL.

      1. Michael Wojcik Silver badge

        Re: COBOL

        COBOL has been modernized.

        OO COBOL? Check. Managed (CLR and JVM) COBOL? Check. Inline declarations and anonymous closures? Check. Support for popular IDEs? Don't know why those things are popular in the first place, but sure, why not. Web UIs and service interfaces? Check.

        And compilers have supported lower- and mixed-case COBOL source code for ages. And free-format (so no more worrying about columns), too.

        1. jake Silver badge

          Re: COBOL

          Aye ... But if you tell that to the young people today, they won't believe you.

    2. nijam Silver badge

      Re: COBOL

      > the language that never dies

      According to some analyses, it never actually counted as a language in the first place. It always looked like a load of upper case letters shaken up in a bin bag to me.

      > I never used it in anger

      which may account for you having a soft spot for it.

    3. Primus Secundus Tertius

      Re: COBOL

      The unbeatable feature of COBOL is its support for binary-coded-decimal arithmetic, in which you can represent a billion dollars, or a billion anything, to the nearest cent.

      Compare that with the "lousy floating point arithmetic" (*) of the IBM360 single precision, and you realise what the real world thinks is important.

      I once used BCD arithmetic on an IBM 1620 computer to calculate PI to 300 places.

      *Dijkstra, Structured Programming.

      1. Antron Argaiv Silver badge

        Re: COBOL

        I once used BCD arithmetic on an IBM 1620 computer to calculate PI to 300 places.

        ...as did I...on a CDC Cyber 74

        (in COMPASS assembly, IIRC...it was over 40 years ago!)

        ...or, was it e?

      2. Justthefacts Silver badge

        Re: COBOL

        This behaviour is trivially reproducible in C++, Python, Java, Rust, Ruby, and any other modern language.

        Any competent coder can do this by simply defining a new type “BCD”, plus some overloaded arithmetic operators on that type, in a matter of minutes.

        Or, more sensibly, just call in the relevant libraries in your language of choice:

        https://en.m.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software

        1. bazza Silver badge

          Re: COBOL

          The trick missed is that IBM's Power CPUs have a hardware coprocessor for BCD maths, whilst Intel chips don't. This gives them a big performance edge in some very specialised but very important applications.

          I recall South Korea once replaced an entire warehouse of Intel servers running its clearing system with a few racks of IBM gear, because of this.

          1. Michael Wojcik Silver badge

            Re: COBOL

            The z architecture has BCD in hardware. I don't recall Power having it.

            Often BCD arithmetic in COBOL programs is on items small enough that they can be represented with full accuracy in one of the native CPU types, so there's just a conversion penalty before and after a basic block of arithmetic operations. You don't need to do actual BCD arithmetic until the items get too large to fit in a 64-bit integer.

            In any case, the real USP of COBOL is that it's COBOL, and there's a lot of it. We (Micro Focus1) sell a whole heaping bunch of mainframe migration because there are so many mainframe COBOL applications which are enormous and stovepiped and embody business logic that's not documented anywhere. Rewriting those applications is a minefield. It's much safer to move them unchanged, or largely unchanged, to a new platform under emulation that supports mainframe aspects like CICS / IMS / JES environments and EBCDIC and mainframe pointers. And, yes, IBM mainframe COBOL dialects.

            And then, once your existing systems are running on the migration platform, you can start to modernize them. Integrate with other native or managed languages. Slap web UI front ends on. Wrap pieces as services. Scale out. Whatever.

            IBM selling a port of their COBOL compiler for Linux is only a small piece of the mainframe-migration puzzle. And GNU COBOL is nice (and Bruce TIffin deserves ample respect for the huge amount of work he put into OpenCOBOL and then GNU COBOL), but again, a COBOL compiler is only one of many ingredients for migrating existing COBOL mainframe applications.

            1"Micro Focus". Two words.

            1. whitepines
              Boffin

              Re: COBOL

              I was curious about that so I went to look at the Power ISA. There's an entire chapter dedicated to decimal floating point:

              https://wiki.raptorcs.com/w/images/c/cb/PowerISA_public.v3.0B.pdf

              Not sure any Linux compiler uses it though, or even what performance benefit would exist for real world applications.

      3. doublelayer Silver badge

        Re: COBOL

        "The unbeatable feature of COBOL is its support for binary-coded-decimal arithmetic, in which you can represent a billion dollars, or a billion anything, to the nearest cent."

        Er... That's pretty easy. That's an integer divided by a constant, and a pretty small constant. What's more complex is storing values to a lot more precision when they're not rational numbers, but we also can do that today too.

      4. Weylin

        Re: COBOL

        The BBC B Micro did binary coded decimal in hardware.

    4. Doctor Syntax Silver badge

      Re: COBOL

      I once got a handed a system to work on of which the C component was obviously somebody's "My first C program". "Somebody" was the boss and he'd been a COBOL programmer. He'd discovered macros and introduced a few - MOVE was one - to make it a bit more COBOL like. As I worked on it I realised that some of the code I needed to modify was wrapped up in some of the instances of the macros so eventually (fairly quickly, in fact) I just ran the whole thing through cpp. This was actually the distant 2nd or, as I discovered some months later, 3rd biggest problem that the system had.

    5. Antron Argaiv Silver badge
      Pint

      Re: COBOL

      Grace Hopper looks down, smiles knowingly.

      1. Admiral Grace Hopper

        Re: COBOL

        She does.

      2. jake Silver badge

        Re: COBOL

        "Grace Hopper looks down, smiles wickedly."

        FTFY

    6. big_D Silver badge

      Re: COBOL

      I used it a lot. I loved COBOL, you would bash out pages and pages of code, you actually felt like you had achieved something. Not as many pages of code as writing it in assembler, but more per line! :-D

      1. Version 1.0 Silver badge
        Happy

        Re: COBOL

        The great "feature" of COBOL is that you virtually never need to provide independent documentation of the code functions - it's so totally readable. Sure, you can create issues if you have problems but then just reread the code and it's normally completely obvious.

        Mathematics has not changed since COBOL first appeared so it's still functional because 1+1 still equals 2.

        1. J27

          Re: COBOL

          I've heard this said about every single programming language and it's never true. You need to know WHY the developer has it doing that math there.

          1. Michael Wojcik Silver badge

            Re: COBOL

            Yes. And while COBOL more or less encourages things like comments (the NOTE statement may have been the first explicit provision for long-format comments in source code) and meaningful variable names, that doesn't mean developers will use them.

            I don't know how many times I've had to search through multiple source files trying to figure out all the ramifications of someone's SET ws-ctrl-flag-foo-88 TO TRUE.

            And COBOL written in pre-COBOL-85 style, with punctuation instead of scope-delimiters, can hide control-flow errors. As can the inconsistent semantics of PERFORM across different COBOL implementations.

        2. big_D Silver badge

          Re: COBOL

          We still had copious headers to sections of code and functions. Even if the code should be self-documenting, pages and pages of move statements can become a doze fest. Also, adding or subtracting 2 variables is evident what it is doing, but not necessarily why it is doing it.

          We also had to add comments before and after our edits with our initials, date and the release number, for example.

        3. doublelayer Silver badge

          Re: COBOL

          "The great "feature" of COBOL is that you virtually never need to provide independent documentation of the code functions - it's so totally readable."

          Has this ever been true? About anything? I doubt it.

          No matter how nice the language looks, someone can find a way to make it unreadable. The easiest way that I've found is to split every function across multiple files, ideally containing split parts of unrelated functions. If multiple files are not available, just split up all the function parts and disperse them across one big file. If you use easy unclear names, lose single points of truth, always avoid abstracting out functions, always abstract out everything you can do, or write in JavaScript, your code can become unreadable really fast.

    7. jake Silver badge

      Re: COBOL

      "the language that never dies."

      As I first posted a dozen or so years ago (at least the first time here on ElReg), COBOL is dead! Long live COBOL!

  7. Just A Quick Comment
    Joke

    Readable? Concise?

    "Still nothing quite so logical and readable as COBOL"

    Finnegans Wake?

    Report on Probability A?

    1. nematoad

      Re: Readable? Concise?

      Ulysses?

      1. Eclectic Man Silver badge

        Re: Readable? Concise?

        I gave up on Joyce's 'Ulysses' around page 300 (of 900 in the Penguin classics edition). The language was occasionally elegant and inspiring, but not knowing Dublin at all, I could not follow the progress of Mr Bloom or Stephen Daedalus.

        Maybe I'll give it another go.

        'Stately, plump Buck Mulligan ... "

    2. disgruntled yank

      Re: Readable? Concise?

      Readable, perhaps. Concise I can't see.

  8. This post has been deleted by its author

  9. Anonymous Coward
    Anonymous Coward

    April Fools was last week.

    IBM is a week late with this one.

    But then again, that's very On Brand for IBM.

  10. DaemonProcess

    too late

    Yes this was needed by IBM about 13 years ago, they would have kept more customers if they had had the vision and weren't run by accountants. The internal MF lobby high up in IBM's US management is too powerful and even today is continuing to de-relevent (see wot i did there?) the company as a whole - by saying that people still have a route back to MF if the required performance can't be met. They haven't got a clue. Desperately holding on to the 1970s. Actually in 1989 I was briefly a COBOL programmer, you kind of get into it and it can be enjoyable up to a point.

  11. mmonroe

    ADD INSULT TO INJURY.

    PERFORM PLEASURABLE-ACT UNTIL SATISFIED.

    I'm sure I wasn't alone in putting these and similar statements in my code when I was a spotty faced programmer.

    1. Arthur the cat Silver badge

      SUBTRACT TOTAL-DEDUCTIONS FROM SALARY GIVING VERY-LITTLE.

  12. Arthur the cat Silver badge

    Party like …

    … it's 1959.

  13. HammerOn1024

    And the wayback machine

    Cloud == Servers == IBM

    Are we done yet?

  14. casperghst42

    Micro Focus will not be happy

    Micro Focus will not be happy as Cobol is their bread and butter.

    1. Michael Wojcik Silver badge

      Re: Micro Focus will not be happy

      I don't think anyone here is very worried.

      1. jake Silver badge

        Re: Micro Focus will not be happy

        I doubt anybody there cares at all.

        Horses for courses & all that.

  15. Blackjack Silver badge

    Yeah... Because you totally want that ACCOUNTING DATA TO GO OFFLINE when Internet or the server does.

    That would be freaking wonderful, don't you think?

    1. jake Silver badge
      Pint

      Truly wonderful!

      Clouds exist to give employees a day (or three) off, with pay, at random, throughout the year. As such, they are quite good for morale. Or was that more ale?

  16. fredesmite2

    my 1st programming language

    was cobol. 1978 ...

    used it in 1980 for a little while

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like