back to article COBOL-coding volunteers sought as slammed mainframes slow New Jersey's coronavirus response

The governor of New Jersey has asked COBOL-capable coders to volunteer their skills as the US state’s mainframe computers have struggled to cope with a surge of requests for benefits to help citizens through the coronavirus crisis. COBOL - common business-oriented language - was introduced in the early 1960s and achieved the …

  1. Anonymous Coward
    Anonymous Coward

    Volunteers?

    This is y2k part 2.

    BOOM.

    1. RachelG

      COBOL coders came out of retirement to help fix the y2k bug.

      That (the work done) was more than twenty years ago. They came out of retirement to do it twenty years ago. A lot of them probably just aren't around any more.

      Technical debt always comes due, but it can be paid in installments. Maybe "if it ain't broke don't fix it" isn't such a great idea after all.

      1. jake Silver badge

        Most of us who worked on COBOL for Y2K weren't retired quite yet. Some of us still aren't officially retired.

        There is nothing really wrong with the COBOL code we are talking about here. It's been cranking away for years, happily putting in work. All it needs is shifting over to faster hardware with better I/O. Which is available off-the-shelf, for a price. And no, it's not "cloud" crap. For example, I know for a fact that some of IBM's current gear will run COBOL that I wrote in the early 1970s unaltered.

        TPTB in New Jersey know this. They just want to avoid spending money. Especially money that'll be going to keeping the legacy code around for another 50 years ... because let's face it, that's exactly what'll happen if it can be made to handle the current crisis.

        1. This post has been deleted by its author

          1. yoganmahew

            @Blackjack

            "there are also problems like the bios ending being so old it just dies even if you keep changing the battery"

            I'll just leave that bit there.

            Your post makes me sad.

            1. Wzrd1 Silver badge

              "there are also problems like the bios ending being so old it just dies even if you keep changing the battery"

              I'm more worried about BIOS that was so old it says, "George Washington rejected this" in the firmware.

          2. iGNgnorr

            Despair

            "What is wrong is the ridiculousness of keep using software that's so old it was invented when computers didn't have enough memory to hold the full date of the year and keep replacing the hardware while keeping using the same software.

            Practicality the whole servers have been replaced by now, if anything remains of the old servers at all, and yet they keep using COBOL for them.

            Hard disks start to fail at about ten years if not earlier, wires and fans don't last forever, there are also problems like the bios ending being so old it just dies even if you keep changing the battery

            Buying cheap ends becoming expensive and replacing the whole servers with a version of Linux and up to date (By Debian stable standards) software would end saving the state a huge amount of money in the long run.

            Yes, there are newer versions of COBOL but this is the COBOL that was used in the eighties,;even if you want to keep using COBOL you should at least update to the modern version so there will be people left alive that can use it when the Year 2038 problem strikes."

            There are some absurd comments posted hereabouts, but this one is beyond ridiculous. Have you no clue whatsoever about managing computer systems? Even the Linux ones you seem to think are the answers to everyone's prayers?

            Yes, hard disks fail. You apparently don't know that it is possible to move data from old disks to new ones, and even if the old ones fail before you do that, you restore from backups. Maybe you've heard of RAID? If not, maybe should learn about it. You'll no doubt be shocked to know that shops which run large COBOL systems actually perform regular scheduled backups in case of worst case disk system failure. And know how to restore from them.

            Most systems which run COBOL at scale don't have BIOSes, but even if they did, BIOSes don't fail due to batteries. As for wires wearing out ... maybe the cheap eBay knock-offs you use for your 'phone, but not those used on business systems.

            What the version of COBOL originally used has to do with it is entirely beyond me. COBOL programs compiled 40 years ago on IBM mainframes will still run today. Assuming the source code hasn't been lost (this is actually a genuine problem) it can be recompiled with the current compiler, usually with no changes.

            1. Stoneshop

              Re: Despair

              What the version of COBOL originally used has to do with it is entirely beyond me. COBOL programs compiled 40 years ago on IBM mainframes will still run today. Assuming the source code hasn't been lost (this is actually a genuine problem) it can be recompiled with the current compiler, usually with no changes.

              Also, programmers that are well-versed in a particular language can usually adapt to older versions on the same class of systems with little effort. Maybe they'll have the occasional "Oh wait, that won't work here." moments just like you'd have with C, Perl or Python when working on an older code base. And the incantations to compile and link the code will not be substantially different from the previous build on that system, if at all.

              I've written Pascal on a DEC10, a VAX and, using Borland TP, on PCs. With the latter you get all kinds of options for screen manipulation that you don't readily have on a VT100, but no-frills line-based I/O needed little conversion, and I didn't need to touch the main processing routines when I moved stuff from the VAX to a PC.

            2. Dave 15

              Re: Despair

              Wires 'wear out'? Total cobblers, even my old 1950s car still has its original wires, hell a friend of mine whose car is from the 1920s still has mostly original wiring.. and those wires are subjected to vibration, heat, cold, dirt... all sorts.

              1. Mongrel

                Re: Despair

                "Wires 'wear out'?"

                A standard Lucas feature IIRC

                1. Piro Silver badge

                  Re: Despair

                  One just needs to top-up with magic smoke.

              2. juice

                Re: Despair

                > Total cobblers, even my old 1950s car still has its original wires, hell a friend of mine whose car is from the 1920s still has mostly original wiring.. and those wires are subjected to vibration, heat, cold, dirt... all sorts.

                Wiring can and does fail. The insulation can become brittle and easily damaged. Moisture can cause galvanic corrosion. Temperature changes can cause the metal to expand, contract and flex.

                To be fair, most of these things only become an issue when you want to change something. As anyone who's rewired a house or powered down a PC to replace a component can attest :)

                1. BebopWeBop
                  Joke

                  Re: Despair

                  And those electrons cause friction which accelerates the wear.

                  1. Precordial thump Silver badge

                    Re: Despair

                    Ohm my god!

                2. JoeCool Silver badge

                  Re: Despair & worn out wires

                  Sure some wiring can wear out - check out electric ranges that have been in use fo 10-20 years. But mainframes are in slightly more protected environments.

                3. Alan Brown Silver badge

                  Re: Despair

                  "To be fair, most of these things only become an issue when you want to change something"

                  Not always. It took me a while to track down the occasional smell of what seemed to be burning rubber in my flat - we thought it was smokers outside.

                  It turned out to be a segment of 1930s-era wiring that hadn't been disconnected in the 1970s when the building was rewired - and it wasn't burning up at the end that had been disturbed by the rewiring job.

                4. Bogbody

                  Re: Despair

                  Wires do "wear out" in terms of vibration making them brittle or old style insulation failing.

                  I'm looking at the mains drop wiring into my house ... fitted in the 1960's it's insulated with pitch and hessian. Sparkie said "get it changed" -- ukpower said "Ah -- ok ... but it'll have to wait for a post-Corona" world...... so yes wire does fail eventually. 50 years or so !!

            3. big_D

              Re: Despair

              Agreed. And the software back then was a hell of an investment, probably costing hundreds of thousands, if not millions to implement.

              The problem is, re-implementing that in something "more modern" would need a similar investment, at rates inflated for today's economy. These systems are usually unique and have been regularly extended over the decades. Doing a complete analysis of what it actually does, an analysis of what it actually needs to do and implementing a new system based on the findings would be prohibitively expensive.

              That is one of the problems that these public sector organisations have, as well as private companies. How do you tell your electorate that 10-15% of their taxes for the next five plus years will go towards replacing a system that already works?

              That is why many of these systems are still around, they are still "good enough" to carry on and nobody has the budget to even think about replacing them.

              1. Someone Else Silver badge

                Re: Despair

                How do you tell your electorate that 10-15% of their taxes for the next five plus years will go towards replacing a system that already works?

                You don't, you fire the nimrod who projected that, because s/he is clearly on the take.

            4. Wzrd1 Silver badge

              Re: Despair

              "What is wrong is the ridiculousness of keep using software that's so old it was invented when computers didn't have enough memory to hold the full date of the year and keep replacing the hardware while keeping using the same software."

              Yet, not a damned one of the complainers wanted to pay for coders to code for more modern architecture and software languages.

              Yet even more ignorantly, ignoring that IBM still sells the same general model mainframe, with much more modern circuitry, it just allows code re-use. I guess we were wrong when we accepted code that ran on an 8086 and an 80286 and stayed on the wrong path since...

              Still, I'm at a quandary, if the code is so antiquated as to require replacement, whyinhell would you recompile it to run on the newer, newer, newer hardware, as was repeatedly done before, but is still deficient and not addressing the current problem?

              Where is the BOFH when we need him?!

          3. GreyWolf

            You have made a hidden assumption, namely that they still have the source code for their COBOL. Not necessarily the case. I know of a major international business running vital UK infrastructure has only 25% of the source code for the management application. They cannot go anywhere. They are quite literally dumping the infrastructure in order to get out of running the software.

            We're all doomed, I tell you.

            1. Martin Gregorie

              How systems were all too often documented in the 60s and 70s

              Upvoted, but you missed something: the system design documentation is equally important (1), particularly if, as was common, the program code was uncommented and/or the 'system designer' decreed that some utterly incomprehensible and uninformative scheme for naming variables, paragraphs and sections must be used (2).

              The end result was that often the only surviving system documentation was the program source code and puzzling out what the system actually did from the code could be very difficult indeed.

              (1) System design documentation was typically hand written, held in ring binders and NEVER updated. Since any documentation of bug fixes or system enhancements was generally discarded when the job was done, or had never existed, what documentation still existed was soon utterly out of date and, consequently, was frequently binned whenever the design office shelves got full. The most extreme case of this I ever saw was at Smiths Industries in Cricklewood, where the System Analysts were kept as isolated as possible from the programing teams and had a policy of immediately scrapping all documentation once the system or patch had successfully gone live. This sort of shambles persisted until PCs and word processing became common in the late '80s. The first purpose-designed system documentation system I met was ICL's Advanced Data Dictionary, which was around on VME/B systems in the late '80s.

              (2) The worst example I ever saw was in an accounting package the ICL bureau I was working in mistakenly bought around 1970. It had a coding standard, but it was this:

              - data names were all of the form XX99 regardless of their level or usage, so you saw things like this

              FD CR01.

              01 CR02.

              05 CR03 PIC X(15).

              05 CR04 PIC S9(6).99 DISPLAY.

              ..... as a continuous sequence right through all the various card images the program could handle. Then you got to the records on mag tape, which started from MT01 and continued through all records in the various different tape files, started again from LP01 for printed output and - you guessed it - started again from WS01 for all working storage.

              - in PROCEDURE DIVISION, use of SECTIONS was forbidden and all labels had to be 5 digit numbers. They weren't even in numeric sequence and, guess what - there were no comments in the entire set of programs. IOW, just what causes this MOVE to be executed, what is it trying to achieve and what will the program do next:

              IF CR08 > WS11 MOVE CR15 TO WS23 GO TO 23500.

              The bureau wasted a heap of money buying that junk because it was utterly unmaintainable. I never heard whether they got their money back: all I know is that I designed and wrote a replacement using structured and meaningful names and that it was still in use and well regarded when I visited 4 years later - not bad, seeing that in the 70s that sort of system was designed for a life of around 3+ years.

              In summary, thanks to this sort of nonsense, why should there be any surprise that the old COBOL systems are still in use?

              They can't be replaced simply because nobody knows exactly what they do or how they do it and the cost of going through badly written, uncommented and undocumented code is prohibitive.

              As a more current comment, one of the really good things about Java is the javadocs utility. This generates nicely formatted HTML pages from the class and method level comments in source files. So, in principle, the system designers could deliver low-level design as a set of Java pages containing class and method level comments together with method skeletons and the documentation would be up to date because developers would update the comments as they modify the code. Sadly, however, judging by the standard of documentation I see in 3rd party Java packages, yer average developer today still can't be arsed to adequately document what he writes.

              1. Anonymous Coward
                Anonymous Coward

                Re: How systems were all too often documented in the 60s and 70s

                The problem is not COBOL. Of all the languages that I've written in, only COBOL is so clear and yes, extremely simple, that it defies most attempts to obfusticate it, for the sake of job security. Java can be written in as dense as the example you have detailed, if the programmers are looking for job security. What makes Java even better for Job Security is its strange tendency (in my experience, anyway) for every other release to have weird memory leaks. Now that's REAL Job Security, tracking down java bugs! And documentation??? Who needs steenkin' documentation? It's Job Security to just never have the time for documentation, so, it's the programmer who is the documentation.

                1. Anonymous Coward
                  Anonymous Coward

                  Like all things Java...

                  ...determining the impact of memory bugs is left as an exercise for the reader. Writing clear, complete, and useful documentation is as en exercise for the reader. Platform consistent GUI tools are left as an exercise to the reader. Pointers, being nasty and dangerous, are too much to expect the reader to understand or operate. In consolation, garbage will be collected, eventually, most of the time.

                  Java, I love you, despite I the reasons I hate you.

                2. Stork

                  Re: How systems were all too often documented in the 60s and 70s

                  An interesting story I read at the time of the Y2k work was that the Japanese had it easier. Job for life meant there was a real chance you were going to maintain your own code, so you might as well document it,

                  1. big_D

                    Re: How systems were all too often documented in the 60s and 70s

                    Back in the 80s, we were still company men and women, we still believed we'd be working for the same company when we retired. I managed around 15 years with the company I started work with, until they did a big downsizing in 2002 (5 figures) and I took the opportunity to start over in a new country.

                3. BebopWeBop

                  Re: How systems were all too often documented in the 60s and 70s

                  Ah - you can obfuscate in any language. I leave you to contemplate http://www.pbm.com/~lindahl/real.programmers.html

                  1. Someone Else Silver badge
                    Coat

                    Re: How systems were all too often documented in the 60s and 70s

                    Ah - you can obfuscate in any language.

                    Corollary: You can write FORTRAN in any language.

                4. batfink

                  Re: How systems were all too often documented in the 60s and 70s

                  But, but...Agile manifesto: "Working product is more important than comprehensive documentation".

                  What could possibly go wrong?

                  1. IB12345

                    Re: How systems were all too often documented in the 60s and 70s

                    “Working product is *more important* than comprehensive documentation.”

                    Correct. Our customers buy the functionality the software offers, not documentation. However, “more important” doesn’t mean that the documentation isn’t important.

                    In my experience, it’s normally project managers who consider it unimportant. Possibly because they are measured on hitting dates and budgets, not on code quality or maintainability.

              2. Tim99 Silver badge

                Re: How systems were all too often documented in the 60s and 70s

                Commented code: A post of 2 years ago - My experience 35 years ago...

                'We use to run projects based on the "Rule of Two":-

                Write code be twice as easy to understand than the team is capable of producing. Never put two or more expressions in the same line. Never write a function that addresses two or more business rules. Always write at least two lines of documentation for every function (Or, even every line of code). Always wait for at least version two of the tools that you are going to use to put software into a production environment. Stop writing code at two o'clock in the afternoon, then use the next two hours to check it (Then, if necessary, have a meeting about it - Which will be short because everyone wants to go home/down the pub).'

                1. big_D

                  Re: How systems were all too often documented in the 60s and 70s

                  I knocked up a product tracking system for a photo studio (I worked at an advertising and ecommerce agency that had their own studio), which photographed thousands of products a week.

                  I wrote the system in PHP with Zen, with HTML & CSS front end and a total of around 20 lines of JavaScript, in 2010, it used scanners to scan the barcodes of the products, in the 3 months of my notice period. Last year, I received a thank you on LinkedIn from the project manager that took over the project for the documentation I left behind - the PHPDoc ran to around 800 pages. But I kept everything simple, each class covered one business object, each method did one job and where it had to work on complicated data structures, they were broken out into individual private functions that did simple tasks of the whole.

                  The same when I left the next job, the administrator that took over from me contacted me to thank me for the documentation I left behind.

                2. Dave 15

                  Re: How systems were all too often documented in the 60s and 70s

                  The most important thing to document is what you expect the function to do, second limitations and assumptions

                  1. batfink

                    Re: How systems were all too often documented in the 60s and 70s

                    Yes agreed, but then this may differ from what it actually does.

                    Ah, that takes me back to the heady days of failing to debug my assembler code because I was looking at my in-line comments rather than looking at the actual code...

                3. Doctor Syntax Silver badge

                  Re: How systems were all too often documented in the 60s and 70s

                  "Always write at least two lines of documentation for every function (Or, even every line of code)."

                  Specifying quantity without quality doesn't necessarily help.

                  Hypothetical example:

                  Function name: AddTwoNumbers

                  Documentation:

                  Takes two numbers as argument

                  Returns sum

                  Yes, we can work that out from the function name. Now tell us something we can't - why you used this algorithm, why you didn't use something else, what the limitations are.

              3. Dave 15

                Re: How systems were all too often documented in the 60s and 70s

                Yeah.... but.... I have now worked in 2 companies since 2010 that had a policy of NO comments in the code, one even went through and actively deleted all comments, the stupid comment made by the so called architect was that comments got out of date, you should just read the code. The thought that the difference between what the code actually did and what the code should have done was the bug we were looking for didnt seem to gell as a though with the buffoon.

                Now add to that the idea that all requirements etc. are held in a seperate system like jira which is purged everytime IT think they need to save a few sheckles on storage cost and you have the modern EXACT replication of what you are complaining about. This is exactly true for modern systems, and frankly freed of the requirement to have a clue about the underlying operating systems or memory requirements for their 'classes' it seems most modern programmers like to have 200 layers of function calls, half of which do no more than swap argument orders to the next class they dont fully understand and repeat and repeat loading data from disks... this is why modern computers are so appalingly slow despite the massive increases in processor speed.

                I have done Cobol only once - to debug an old system, happy to debug another old system... after al good engineering skills do not care what the language is... just the same as I can fix my old car with imperial spanners and my new one with metric spanners... a spanner is just a tool for the job, its knowing how and when to use them that matters.

                1. sabroni Silver badge

                  Re: comments got out of date, you should just read the code

                  Notice you didn't argue with this bit.

                  Because you can't. Comments don't have to be updated when code is. When things have to be done quickly because money is being lost then updating the comments doesn't help get the fix into production quickly. The comments will be left, no longer explaining what the code does and that will cost someone lots of time later.

                  Write your code so it's clear to other readers what it does. The only place comments should be needed is where the business rules are so counter-intuitive you need to spell them out. There the comments merely explain that yes, the code is doing the apparently stupid thing it looks like it's doing because "business".

                  Code needs to be readable. It's fuck all use otherwise.

                  1. Doctor Syntax Silver badge

                    Re: comments got out of date, you should just read the code

                    "Comments don't have to be updated when code is. When things have to be done quickly because money is being lost then updating the comments doesn't help get the fix into production quickly."

                    You comment the changes as part of check in. You do have a version control system to check it into, don't you?

                  2. Boris the Cockroach Silver badge
                    Boffin

                    Re: comments got out of date, you should just read the code

                    What a load of horse .. err stuff

                    The comment rule I was always taught (and have taught ever since)

                    If you are writing a macro( CNC sub-routine code),

                    Document what the macro is to do, document the inputs, then document the outputs, thats all in the comments before any code is executed, then as you progress through the code, document what each part is suppossed to do.

                    And strangely

                    During the open university computery courses I subjected myself to... the same fucking rules applied

                    What may seem simple to you such as

                    Q1604 =( Q108*Sin Q1600) /( Q1601/360* Q1602) means fuck all to everyone else without any comments

                    PS the above code is from a macro to describe 3 axis cutter paths in 4 axis... there's lots more sins and cosines and at least one tan in there too

                    1. Someone Else Silver badge

                      @Boris -- Re: comments got out of date, you should just read the code

                      What a load of horse .. err stuff

                      I think the term you're looking for is "horse exhaust"

                      With a tip of the hat to Dan O'Neill, Odd Bodkins, The San Francisco Chronicle (in spite of itself), and a misspent youth....

                      1. jake Silver badge

                        Re: @Boris -- comments got out of date, you should just read the code

                        I think the actual term is "horse shit".

                        We're all (mostly) adults here. Tell it like it is. The easily offended can kiss my pasty white butt.

                        1. A.P. Veening Silver badge

                          Re: @Boris -- comments got out of date, you should just read the code

                          The actual PC term is "the end product of an adult, uncastrated, male head of cattle". And yes, I am aware it is a different species with a different quality of rose fertilizer.

                  3. Anonymous Coward
                    Anonymous Coward

                    Write clean code, but comment on context and motivations.

                    I spent today tracking down an issue which is a perfect example of why comments are needed.

                    Symptom: YAML configuration file causes application parser to throw an exception and die with stack trace, parser complains of invalid input.

                    Strangely Input is well formed, and all test are passing on CI.

                    The code basically does

                    ...

                    yaml_obj = YAML.new(some_properties);

                    utf8_txt = to_utf8_string(yaml_obj);

                    file.open("config.yml"){|fp|

                    fp.write(utf8_txt);

                    }

                    ...

                    The fix is to add a single newline.

                    literally

                    file.open("config.yml"){|fp|

                    // Java.IO.SequenceInputStream in combination with SnakeYaml barfs unless we do this

                    // as the resulting yaml document is not well formed with '---' , see #link-to-more-info.

                    utf8_txt.replace_inplace(/^---/,"");

                    fp.write(utf8_txt);

                    }

                    ...

                2. big_D

                  Re: How systems were all too often documented in the 60s and 70s

                  one even went through and actively deleted all comments, the stupid comment made by the so called architect was that comments got out of date, you should just read the code.

                  And I was taught, you always change the comments first, to reflect the changes you are about to make to the code, otherwise nobody can maintain it. Once the project was complete, the development team handed it over to support and support would refuse to accept the project as finished and supportable if the code was properly documented.

                  There were severe demerits for the development team, if they tried to hand over "unfinished" code, and unfinished also meant undocumented.

                  Likewise, all documentation was stored in a document management system and the final project documentation also printed and signed off, before being archived.

                  1. Doctor Syntax Silver badge

                    Re: How systems were all too often documented in the 60s and 70s

                    "Once the project was complete, the development team handed it over to support and support would refuse to accept the project as finished and supportable if the code was properly documented."

                    This!

                    Development is the process of launching the product into the maintenance cycle. If it's not maintainable that fails. Better still, however, one team owns the product throughout so documentation is self-defence.

                    1. big_D

                      Re: How systems were all too often documented in the 60s and 70s

                      Yes, oh and the typo, should be "unless the code was properly documented." :-D

                      Where I worked, we had development teams and support teams. The development teams were usually large and went from customer project to customer project, whereas the support teams for the customers were smaller and looked after dozens of supported systems. Therefore good documentation was critical to being able to support the system.

                      E.g. a project team with a project manager, consultants, analysts, designers, infrastructure specialists, programmers, testers etc. could easily run to 100 persons and the support staff were a manager and half a dozen programmers, who looked after everything the customer had in production.

                3. Someone Else Silver badge

                  Re: How systems were all too often documented in the 60s and 70s

                  Yeah.... but.... I have now worked in 2 companies since 2010 that had a policy of NO comments in the code, one even went through and actively deleted all comments, the stupid comment made by the so called architect was that comments got out of date, you should just read the code. The thought that the difference between what the code actually did and what the code should have done was the bug we were looking for didnt seem to gell as a though with the buffoon.

                  This (not commenting code) is actually one of the "best practices" with the Agile folks; the feeling that "coders" can't be arsed to keep comments up-to-date, so you might as well just not do them. I have had some interesting and animated "discussions" with at least two of the Agile Manifesto signatories about this very concept.

                  Dave15, you are correct in your analysis. Besides being able to compare the comments to the code, there is also this thing that just galls me: How in the fucking fuck can you call your self a programmer (much less a software engineer) if you are so fucking lazy that you just can't get your fingers to tap out a small explanation of why your latest opus dei was coded the way it was? Here is a perfect opportunity for self-aggrandizement, to show the world about how you are so much smarter than the rest of the plebs you work around...and you pass it up?

                  (And no, "self documenting code" isn't a thing. You can -- and should -- use descriptive symbol names, and straightforward techniques when ever possible. But sometimes it just isn't. So write some text, already, and get over it.)

                  1. jake Silver badge

                    Re: How systems were all too often documented in the 60s and 70s

                    The only reason they call it "agile" is because the proponents always seem to wriggle out of any blame when it goes TITSUP.

                    1. Field Marshal Von Krakenfart

                      Re: How systems were all too often documented in the 60s and 70s

                      Agile: We'll do that in the next sprint (or the one after,)

              4. Field Marshal Von Krakenfart
                Boffin

                Re: How systems were all too often documented in the 60s and 70s

                "system design documentation", what's that?

                "data names were all of the form XX99" - That looks like some sort of generated code to me, I have worked on one system where a lot of the application code was generated by Cobol programs that generated the application Cobol code by reading parameter files (screen layouts, file formats, standard I/O modules). I've seen the same thing done in Clipper.

                The worst Cobol code I've ever seen was written by ex-assembler programmers who wrote Cobol as if they were still writing assembler, jumping in and out of loops with GOTOs, freely mixing sections and paragraphs as control structures (PERFORM section-name THRU paragraph-name UNTIL....) and it would not be uncommon to find a GOTO in the loop.

                Contrary to what some else said, Cobol-74 is not always compatible with Cobol-85, Not all Cobol-74 programs will compile with later versions of the IBM m/f compiler. Another issue is that Cobol-74 compiles and links to 24-bit addressing mode, which is OK if you are calling programs with the same addressing mode but can cause the dreaded adressing exception if you call a program linked in 32 or 64 bit addressing mode.

                Still the New Jersey Department of Labor should be glad they don't have old PL/1 programs as the earlier versions of PL/1 have what IBM euphemistically call "depreciated language elements"

                Also see: Real Programmers and https://xkcd.com/378/

              5. Antipode77

                Re: How systems were all too often documented in the 60s and 70s

                When i was just starting as a COBOL programmer in the mid 1970s we had this dutch software company Volmac, which required using this method of assigning variable names. I seem to remember it was some quirk of the founder of the firm.

                As soon as i was back from the Volmac course i dropped this and used meaningful variable names.

            2. EVP

              If they’ve lost their source code, they get what they deserve. It’s not fault of COBOL.

            3. MrName

              Sadly all too common.

              I was tasked around Y2K to replace an out of date app. It had been happily running for years using a defunct DB (the company making it had literally collapsed) using their own bespoke language (no manuals). For this I did have access to some of the source which meant it was easier than all the other apps they were using.

              Their favoured replacement language: VB6

          4. The Man Who Fell To Earth Silver badge
            FAIL

            @Blackjack

            Sounds like your life experience is limited to web pages and phone apps. Yeesh.

          5. Stuart Castle Silver badge

            As noted above, not all computers have a BIOS, or NVRam, or an RTC (both of which require the battery). BIOSes and built in firmware are things that, if I understand correctly, didn't really exist until the late 70s/early 80s (I was born in 71, and didn't use a computer until the late 70s).

            Also, as the computers were not generally networked, the need to upgrade wasn't based on security. Even mainframes tended to operate on their own networks, so while Hacking was a very definite problem, it wasn't the problem it is today.

            The problem with old code is not that it will suddenly not work. I have an old Amiga upstairs that I dare say would work fine, assuming the capacitors in both the Amiga and the PSU have held up (this is not a given for either the Amiga or the PSU) with the same software I used in the early 90s.

            The hardware itself will fail from time to time, and as long as suitable spares are available, it can usually be fixed.

            Now, company requirements may change from time to time. This introduces the problem that the company may well have patched the original code to cope with changes, which can make things messy, especially if the original code or changes are not properly documented (and they rarely are in my experience).

            Now, you could argue that the moving the code to a new server would make things better, but it likely wouldn't. The code may take advantage of a particular feature (or even bug) present in the old computer system, or compiler, that isn't present on the new system (even if you go down the emulation route for the new system).

            Moving a company critical system to a new server (which may even have a different architecture) requires a *lot* of testing, Some systems require enough testing that it may actually be easier to design a new system to perform the same functions, particularly if you are dealing with a system built decades ago, and is now only running because you have spent years making small changes.

            It's not just a case of setting up a server, bunging the source code on to it (assuming the source code is complete), compiling it and running it. There is testing, and bug fixing, plus the downtime (for development and if the system fails).

            This is why people tend to shy away from updating core systems, even if they are decades out of date. It can potentially cost millions to replace the system, and may cause months, if not years, of disruption to the users.

            It should also be noted that in the development, testing and implementation of any reasonably large system, the actual cost of the hardware and software is actually a very small part of the total cost. There is the initial development, installation, and ongoing support (including training, bug fixing, upgrades and tech support). The cost of the ongoing support can be many times the cost of the hardware and software.

            That's not to knock Linux. I like Linux, and I know it provides the core infrastructure for millions of corporate networks, but the fact the OS itself is free makes little difference to the cost of installing systems on a corporate level.

          6. Anonymous Coward
            Anonymous Coward

            The problem is that kids like you grow up to be "programmers" and IT staff.

            No wonder the world of IT is 2 steps forward, one step back.

            thin computing <--> fat computing...

            individual storage/backups <--> site wide storage/backups

            The "new" ideas you come out with have been done before. People switch to marketing-flavour-of-the-day, and "lessons learnt" become "lessons forgotten"

            I still remember, many years ago, someone on usenet posting asking why his satellite box was becoming less responsive after a few days.

            An "expert" replied: "You should realise - A satellite receiver is basically a computer. And as you know, all computers need to be rebooted every 2 or 3 days if they are to work correctly.

            1. Dave 15

              Sadly many computers are like that, however a properly created embedded system should have been tested against memory leaks and th like and not need rebooting... however that requires people with some experience and knowledge.... as you say, sadly lacking in the hordes of computer graduates coming out of university. Once upon a time engineers (including the likes of Brunel) learnt by apprenticeship from people who had been through the mill themselves. Today you are discarded at 40 because the 'bright young things' have 'all the modern answers' and are therefore 'better' than us old fusspots who when you finally decipher the unintelligable crap that passes for a modern 'buzzword' used the idea 20 years back, found out its limitations and moved on to something better.

            2. Alan Brown Silver badge

              "And as you know, all computers need to be rebooted every 2 or 3 days if they are to work correctly."

              This is one of the things I rail against. Windows has people so trained to do this it can be bloody hard to PREVENT them doing so.

              I had *nix systems in schools during the the 90s which I ended up having to disconnect all front panel buttons, lock off the power cables and tell secretaries to NOT allow any "IT" or "technical" staff near because "reboot/power cycle" was their preferred solution.

              A 386-based system with 4MB ram and slow drives being forced to regenerate quotas because some twat hit the power switch isn't going to take kindly to the same twat deciding it's taking too long to boot and doing the same thing again. The fact that it was running slowly in the first place due to the room being nearly 50C (failed cooling - aka someone turned off the extractor fan) being something that _entirely_ escaped their attention....

              And of course there are the faults which carry on for _years_ because some bright spark keeps resetting the kit before a tech shows up on site to be able to diagnose said fault which only manifests after several days of operation.

        2. yoganmahew

          @jake

          "I know for a fact that some of IBM's current gear will run COBOL that I wrote in the early 1970s unaltered."

          Indeed, the z series is backwards compatible with assembler too (I'm still active).

          How did they end up in their legacys situation with their cobalts and their assemblers? Outsourcing, downsizing of anything that works, refusal to replace retirements, ignorant people in charge who fail to realise the importance of the IT systems they rely on; they're called mission critical for a reason.

          Cobol/assembler on mainframe (whether IMS or CICs or whatever (I program on whatever)) technically has no issues. It's a manpower issue. There just aren't enough people employed who know the business systems well enough to touch them, or even to understand them so they can be adequately specified.

          The big g will no doubt fire up its Cornerstone acquisition and convert to java. Imagine, if you will, a sprawling java monolith that can only be understood by looking at the original cobol and that still operates in the same way as the original... once you hit a hardware choke point (even in the cloud), you're f'd...

          1. Stoneshop

            ignorant people in charge who fail to realise the importance of the IT systems they rely on; they're called mission critical for a reason.

            A lot of businesses as well as government departments fail to realise that they're essentially an IT organisation, skinned to their outwards activities.

          2. John Brown (no body) Silver badge

            "There just aren't enough people employed who know the business systems well enough to touch them, or even to understand them so they can be adequately specified."

            That's the job of what used to be called a Systems Analyst. It should not matter what system they are analysing, manual, old computer or modern computer system, the job is to analyse how the system works and then improve it.

            1. EVP
              Terminator

              ”That's the job of what used to be called a Systems Analyst.”

              In my experience, everybody is a systems analyst nowadays. In the same manner as ’anyone can code’. Yeah right.

              The good part is that I don’t care anymore, not a single least significant bit.

              1. Dave 15

                or an architect

                Grief, have I seen some terrible attempts at that in the last few years, architects barely out of nappies without a clue producing incorrect, meaningless or no diagrams but instead going around bullshitting about processes (no not processors) that they also dont have a clue about.

                Its so annoying.

              2. Doctor Syntax Silver badge

                "In my experience, everybody is a systems analyst nowadays."

                In the olden days we used to be "analyst programmers".

            2. Anonymous Coward
              Anonymous Coward

              Not any more...

              We're "system architects" these days. (An inflated job title is cheaper than an actual pay rise.)

        3. Phil O'Sophical Silver badge

          No so much COBOL as the tools

          I would think that the problem isn't so much the language as the environment. Anyone who's familiar with modern procedural langauges shouldn't have much of a problem picking up COBOL. More of an issue will be finding people who are trained on Windows or Unix/Linux and getting them used to working in 1970s/1980s terminal-based environments with line editors, batch processing, obscure toolsets and all on systems with limited storage. Can you imagine a millenial Python/Linux programmer having to get to grips with IBM JCL and overlays configured by link-editors, all in maybe 1MB RAM and possibly with intermediate storage on serial tape? On a 3270 terminal?

          1. Fruit and Nutcase Silver badge

            Re: No so much COBOL as the tools

            I have to put up with millennial programmers who can't even write a simple Windows batch file, and for them RTFM means going looking for a YouTube video.

            1. This post has been deleted by its author

              1. The Man Who Fell To Earth Silver badge
                WTF?

                Re: No so much COBOL as the tools

                I have not used COBOL in 40 years, but a quick Google search indicates there are quite a number of "COBOL for Windows" development systems out there. For example

                Visual COBOL

                https://www.microfocus.com/en-us/products/visual-cobol/overview

                NetCOBOL for Windows

                https://www.gtsoftware.com/products/netcobol/netcobol-for-windows/

                1. OldSoCalCoder

                  Re: No so much COBOL as the tools

                  Micro Focus Cobol, used it for a decade. On pcs. Against IBM DB2 databases.

                  I think New Jersey's problem may not be a lack of actual Cobol programmers but how the current load can be managed, distributed. It sounds like they're not inventing new UIs, they're just having a problem handling the volume coming in.

                  1. BebopWeBop
                    Thumb Down

                    Re: No so much COBOL as the tools

                    I think NJs problem is that they want to get it on the cheap having neglected to either make sure they had adequate support for COBOL code or put the investment into retooling.

                    So maybe the shortage is people with the correct skillset who are able to drop their existing work and volunteer. Not that I think people might not be found to volunteer (I see it happening all around me), but in the US, what could best be described as punitive approaches to employees with little employment protection will make some of them think again before volunteering.

                    1. batfink

                      Re: No so much COBOL as the tools

                      Why should they be "volunteering"? If there's a requirement, it should be fucking paid for.

                      1. Anonymous Coward
                        Anonymous Coward

                        Re: No so much COBOL as the tools

                        NJ is a socialist state.

                2. MX9000

                  Re: No so much COBOL as the tools

                  1) Microfocus Cobol was garbage when I had to use it.

                  We'd "discover" typically, 20 bugs a month, and when the new monthly release came out, there'd just be 20 more new bugs.

                  2) Call IBM.

                  -They probably already have the IBM370 OS in a Virtual Machine, that they can run for you, in the cloud, for the next 6 months.

                  3) But, will new horsepower be enough?

                  Will they have to divide the input file by 26, based on Last name, to run "in parallel" from A-Z, on 26 virtual machines.

                  4) Can the code be successfully moved to a IBM370 OS VM?

                  Does IBM have snapshot capability for IBM370, can the build a new VM from a Backup?

                  1. Anonymous Coward
                    Anonymous Coward

                    Re: No so much COBOL as the tools

                    "IBM370 OS in a Virtual Machine, that they can run for you, in the cloud, for the next 6 months."

                    I have MVS 3.8j running on my iMac Pro - every once in a while I IPL it for old times sake.

                    I also have HP2000F Time-Shared BASIC - the computer I learned on starting in 1973 - running on my Mac.

                    Not just the OS, the actual computer! - I met the guy who decommissioned our high school system online about fifteen years ago. He had the last backup tape, and I was able to restore it using an open source emulator called SIMH. It can also simulate PDP-8, VAX and all kinds of other obsolete systems.

                    COBOL is not that hard if you have the source code. But as others have noted, if you're not a programmer analyst, you're never gonna figure that shit out.

                3. Someone Else Silver badge

                  Re: No so much COBOL as the tools

                  I have not used COBOL in 40 years, but a quick Google search indicates there are quite a number of "COBOL for Windows" development systems out there. For example

                  Visual COBOL

                  https://www.microfocus.com/en-us/products/visual-cobol/overview

                  NetCOBOL for Windows

                  https://www.gtsoftware.com/products/netcobol/netcobol-for-windows/

                  Oh, and don't forget Object COBOL1

                  https://supportline.microfocus.com/documentation/books/oc41books/opintr.htm

                  1No, its not an oxymoron, it's just a contradiction in terms....

                  1. jake Silver badge

                    Re: No so much COBOL as the tools

                    " quick Google search indicates there are quite a number of "COBOL for Windows" development systems out there."

                    Yep. Vim and EMACS have both been ported to Windows.

            2. Stuart Castle Silver badge

              Re: No so much COBOL as the tools

              Youtube video. Luxury. I learned C++ from a book (yes, a small item consisting of a thousand pages bound in covers). I learned Windows API from the Windows SDK documentation, and I learned Java from Javadoc.

              Also, a heck of a lot of messing around.

              1. EVP

                Re: No so much COBOL as the tools

                I fscking hate fscking video tutorials. Every fscking video every fscking time introduces the same fscking concepts beginning when the dinosaurs walked the Earth. The actual tutorial is perhaps 5% of the whole ’tutorial’ duration, if it’s a good one.

                Not that modern (written during the last 35 years) books on technical topics are much better. Gimme a good reference manual and I’m in heaven!

                Rant over. Thank you for reading and please accept my sincere apologies.

                (We need exploding head icon.)

                1. Anonymous Coward
                  Anonymous Coward

                  Re: No so much COBOL as the tools

                  agree - I hate some doofus lamely struggling through an incorrect explanation on youtube.

                  raspberry pi is the worst - every dumbass makes a badly done video about how to config this or that for raspberry pi.

                2. John Brown (no body) Silver badge

                  Re: No so much COBOL as the tools

                  "I fscking hate fscking video tutorials. Every fscking video every fscking time introduces the same fscking concepts beginning when the dinosaurs walked the Earth. The actual tutorial is perhaps 5% of the whole ’tutorial’ duration, if it’s a good one."

                  And very, very few have been scripted by someone who understands the education process. The vast majority waffle on about inconsequential then fly through the useful bits once and assume you learned all you needed to know and move on to the next bit. Anyone who has ever taught knows about structure, aims, objectives, teaching a point then building on it to the next point so you get a gradual build to the final summary/conclusion with some constructive repetition along the way.

                3. Anonymous Coward
                  Anonymous Coward

                  Re: No so much COBOL as the tools

                  Same here... My work is trying to stimulate us making little videos like TED talks and it makes me crazy... Deep-dive text is so much more efficient than video crap. You can run through it at your own speed and easily absorb the topics you need.

            3. Jou (Mxyzptlk) Silver badge

              Re: No so much COBOL as the tools

              > RTFM means going looking for a YouTube video

              Oh how I hate those google search results pointing to youtube videos. Five minutes "Blah blah my d* is the best" followed by five Minutes until the get to the actual stuff the claim to show in the title. And then they leave out several steps.

              In that time I skipped through 10+ webpages with text and found what I was searching for and found a lot of other information around my problem which prevents future problems. And found a more efficient way of doing it.

              To be fair: There are some good youtubers out there who get straight to the point and show a working solution, but they are not the majority.

              1. The Central Scrutinizer

                Re: No so much COBOL as the tools

                Don't even start me on YouTube tutorials. What a waste of disc space and viewers' time. There are precisely 9 useful tutorials out there.

                Someone should make a tutorial on creating tutorials. No, wait....

            4. John Lilburne

              Re: No so much COBOL as the tools

              So 14 months ago the millenials decided to import a system I wrote into a new application. Of course they decided to designer it with the help of architects that had no experience of such a system. When they presented it to me I pointed out the issues that they would have when the first pass was extended but that was ignored. Cos we are agilating and what does this old git know about anything. So they got a whole bunch of experts in to design the GUI based on the simplified model etc. Then 6 months ago they started to move onto stage 2 and all the issues of the architecture I warned them about hit hard and stalled the project. They are still trying to work out how to fix the architecture, but of course they've got a whole bunch of GUI wrapped around it now which means that they are loath to do what is really necessary as that will junk most of the GUI. Once they've worked out stage 2, stage 3 is going to cause even more issues and stage 3 is really why we'[ve started this in the first place. But hey we agilating so that can be ignored ...

              1. Doctor Syntax Silver badge

                Re: No so much COBOL as the tools

                In your place I might be tempted to get ahead of them and then ask "Is this what you're looking for?".

            5. Anonymous Coward
              Anonymous Coward

              Re: No so much COBOL as the tools

              ......and who knows what future damage is being caused by today's "citizen developers". If ever there was an oxymoron....

            6. Anonymous Coward
              Anonymous Coward

              Re: No so much COBOL as the tools

              If the YouTube videos are correct and get them the information--don't complain. It's the message not the medium, surely?

              But, it's a wonderful experience to run a command-line search with wildcards and have your techie millennial think you're doing magic ;-)

              1. BebopWeBop
                Facepalm

                Re: No so much COBOL as the tools

                It doesn't take much! My youngest son, who has been self-isolating for the last 6 months (well they are doing a games startup and i doubt whether they have met physically in 3 months at least), was stunned when I demonstrated how suitable very very short command line management could be used.

                But then he came to coding via a degree in Latin and Greek (! - I think he was reacting against getting an A in Maths and Further Maths Highers - his mum blames me), so I suppose he has to learn that his dad does have his uses (other than providing some of the funding) sometime

                1. Someone Else Silver badge
                  Coat

                  Re: No so much COBOL as the tools

                  But then he came to coding via a degree in Latin and Greek [...]

                  Then he should be proficient in APL....

                  1. no user left unlocked

                    Re: No so much COBOL as the tools

                    Ahhh the language where we spent more time arguing over the aesthetics of a piece of code than whether or not it actually worked......

                    I remember the old argument that being symbolic in its presentation a japanese coder could readily understand the work of an english man and vice-versa. If it was written by the individual with the lower level of proficiency then maybe?

                    I used to space my code out and made liberal use of lamp which annoyed the heck out of a couple of the purists. They just loved those dense code blocks.

                    1. jake Silver badge

                      Re: No so much COBOL as the tools

                      "Ahhh the language where we spent more time arguing over the aesthetics of a piece of code than whether or not it actually worked......"

                      Nonsense. First we made it work. Then we made it pretty.

                      1. Someone Else Silver badge
                        Coat

                        Re: No so much COBOL as the tools

                        In APL, if you worried first about making it work, you never got to the point of making it pretty.

              2. John Brown (no body) Silver badge

                Re: No so much COBOL as the tools

                "It's the message not the medium, surely?"

                Depends. The medium is incredibly accessible with little to no restrictions on who can post videos to it and little oversight on the content posted, eg outright illegal stuff that can take converted effort to get the site operators to acknowledge and get removed. In other words, in this case, the medium is part of the problem because there is so much more chaff than wheat and almost no curation.

            7. BebopWeBop

              Re: No so much COBOL as the tools

              Maybe WTFM is an approptiate replacement?

            8. Doctor Syntax Silver badge

              Re: No so much COBOL as the tools

              "RTFM means going looking for a YouTube video."

              The more experienced eventually discover Stackoverflow.

          2. bombastic bob Silver badge
            Devil

            Re: No so much COBOL as the tools

            back in the 90's when I worked with those older systems I'd typcally transfer the files to a windows system, edit it with something reasonable, then transfer the files back. But as I recall the HP systems I worked on also had a decent visual editor, so it wasn't that bad to just use THAT. Although the program I used to access the minicomputer was called 'Reflection' (and was a DOS application) it ran fine in windows 3.0 and was easy to use to transfer files back and forth. Mostly I did FORTRAN though, and a report writing language called 'QUIZ'. I did _some_ COBOL which I literally picked up by reading the manual for it.

            Anyone used to using Linux or one of the BSD's should be able to manage working on a mainframe as well. They _do_ have the same roots, unless you're one of those wimps that MUST use a GUI for _EVERYTHING_ (and wouldn't understand bash or command lines if they were face-slapped by it). Yeah I've seen mac users like that, even though OSX is FreeBSD underneath!

            maintenance coding, though, is usually not hard if you are not required to write things from scratch. Then you can just take what's already there, and fix it, and use the existing environment to do it.

            (How many systems have I done that with.... a LOT, from PDPs to HP/3000 to VAX to .PCs with DOS, Windows, Linux, FreeBSD, and even Macs)

            yeah, they could PAY me, but I'm not interested in volunteering. This chaos is all SELF-INFLICTED. by OVERREACTING to coronavirus by SHUTTING DOWN BUSINESSES (which creates the layoffs), and it is _NOT_ a solution to a pandemic problem, and I'm going to LET THEM (the gummint, that is) SUFFER until they (the bureaucrats and politicians) LEARN THEIR LESSON! In the interrim, they can solve the unemployment problem by LETTING THE BUSINESSES RE-OPEN, since NOW is the time to do that anyway. After all, why "enable" them to continue with the BAD (gummint) BEHAVIOR, if they're addicted to MISMANAGEMENT and ABUSE OF POWER like that.

            Or, they can PAY me.

            1. This post has been deleted by its author

            2. Anonymous Coward
              Anonymous Coward

              Re: No so much COBOL as the tools

              Your computer points were good, but your random caps and your fox-news outlook on coronavirus meant you get an overall downvote.

              If they didn't do a lockdown, your economy would suffer even more.. Ill people need care. Dead people can't work.

              Many parts of America still aren't taking is seriously.. That's why, for amount of cases, you're number one.

              Unless all your people get serious really soon, the only way you will be able to cover is to use your existing millitary might to plunder the world.... Sorta like you do already, but without bothering with the pretense of "protecting democracy" or having allies.

          3. J27

            Re: No so much COBOL as the tools

            Yes, because I happen to be a millenial programmer who's first job involved maintaining an obsolete billing system build on old an 3270 mainframe. There was no documentation, but we muddled through and even ended up scripting everything with terminal emulation software so we could be much more productive.

            Maybe the millenials you know are just idiots.

            1. John Brown (no body) Silver badge

              Re: No so much COBOL as the tools

              "Maybe the millenials you know are just idiots."

              Nah! You're just the exception that proves the rule :-p

            2. Fruit and Nutcase Silver badge

              Re: No so much COBOL as the tools

              Maybe the millenials you know are just idiots.

              Well, "You could say that, I couldn't possibly comment" was my reply to a colleague when that very term was used by them to describe one my charges

            3. Old Used Programmer

              Re: No so much COBOL as the tools

              Anybody who thinks a 3270 is a mainframe falls in the idiot category.

              1. Sceptic Tank Silver badge
                Trollface

                Re: No so much COBOL as the tools

                That's maybe why the script kiddie suffered: no documentation for 3270 COBOL anywhere to be found.

              2. Fruit and Nutcase Silver badge

                Re: No so much COBOL as the tools

                One of my millennials kept complaining about one of the applications that we occasionally used that was accessed using a 3270 Emulator - was adamant there was some thing wrong as it was not accepting input once everything was entered on the screen - what was befuddling them was the [Enter] key providing Cursor movement and not the "Enter" Function, which was mapped as default to the [Ctrl] (right side)

            4. Someone Else Silver badge
              Facepalm

              @J27 -- Re: No so much COBOL as the tools

              Yes, because I happen to be a millenial programmer who's first job involved maintaining an obsolete billing system build on old an 3270 mainframe.

              Uhh, dude...IBM 3270s were terminals. This is an understandable mistake, as being a millennial, you couldn't possibly grok the concept of one or more terminals being (hard-wire!) connected to a single computer.

              Maybe the millenials you know are just idiots.

              Well, I don't know you, but....

          4. Doctor Syntax Silver badge

            Re: No so much COBOL as the tools

            Also the tools who've "managed" themselves into this situation.

          5. IOM_MIKE

            Re: No so much COBOL as the tools

            What a load of tosh. Link edit overlays went out in the 60s. The mainframe has not stood still, The zSeries is fully 64bit with loads of memory. It can handle work loads well in excess of Intel machines. I would imagine that the WIntel code would have crumbled well before the COBOL code. There are plenty of visual development tools for COBOL and Assembler. The mainframe remains at the center of many enterprises because is up to the job. Nowadays it is more common to serve up the data through APIs rather than green screens.

            1. AlanS
              Boffin

              Re: No so much COBOL as the tools

              I was still using overlays in the early '80s. IBM370/165, 4Mb RAM, of which my partition was 256K.

            2. Anonymous Coward
              Anonymous Coward

              Re: No so much COBOL as the tools

              We're not talking about "nowadays", we're talking about maintaining programs designed and written in the 1970s. Still running in 1970s environments.

              Oh, and I was still using overlays on minicomputers in the 1980s, they only really went out when virtual memory came in, with the likes of BSD Unix and VMS.

            3. bombastic bob Silver badge
              Devil

              Re: No so much COBOL as the tools

              I was guessing AS/400, HP/3000, or VAX actually, not an old 360...

            4. Someone Else Silver badge

              Re: No so much COBOL as the tools

              The zSeries is fully 64bit with loads of memory. It can handle work loads well in excess of Intel machines.

              OK...but does it still use base-register addressing?

          6. Dave 15

            Re: No so much COBOL as the tools

            Not a chance... my pref was for a vt52 terminal and even DOS had an overlay linker. I love it when they complain about the limited memory and processor on their embedded system.... my first commercial PC, 8mhz on turbo, 512k ram, 32mb hard drive (biggest hard drive in the company). And what a step up that was from the z80 based computers I had been using which didnt even have a diskdrive... I remember wondering what sort of program would need all that ram... not even a program that used 24 serial ports (plug in cards) to collect data from users on 24 different capability terminals (some with barcode readers, some with 4 or 8 line displays etc etc)

        4. MrName

          They didn't care before now.

          The simple fact is, if this is limited now, it always was. The state just never felt like fixing the problem because the needs of the unemployed, or indeed the basic functions of government, weren't exactly a priority under people like Chris "I got my own beach" Christie. Now that the stakes are higher they suddenly rush to get volunteers to bail them out.

        5. big_D

          Yes, I worked on several Y2K projects, including some COBOL projects (E.g. CFS, PROTOS) during the late 80s and early 90s. I'm still at least a decade and a half away from retirement... Although at the current rate, I'll probably still be a decade and a half away from retirement in a decade and a half!

        6. Wzrd1 Silver badge

          Most of us who worked on COBOL for Y2K weren't retired quite yet. Some of us still aren't officially retired.

          No, just let go as the services are no longer needed.

          To then be brought back as a consultant at 10x the rate, thereby saving money in the Twilight Zone.

          Maybe I should pop by and introduce them to FORTRAN... ;)

        7. Wzrd1 Silver badge

          For example, I know for a fact that some of IBM's current gear will run COBOL that I wrote in the early 1970s unaltered.

          Famous wods last heard in 1999.

          Which 20 is it? 1920 or 2020? ;)

          Perhaps, some minimal changes?

        8. Someone Else Silver badge

          @Jake

          I know for a fact that some of IBM's current gear will run COBOL that I wrote in the early 1970s unaltered.

          It's likely that the box you posted your missive on will run COBOL that you wrote in the early 1970s unaltered. (Unless you were foolish enough to use the ALTER verb, but that is another story...). All you need is a proper compiler, and perhaps appropriate drivers to alias such things as 9-track tape drives and card readers that no longer exist (for good reason).

          Especially money that'll be going to keeping the legacy code around for another 50 years ... because let's face it, that's exactly what'll happen if it can be made to handle the current crisis.

          I dunno. It's likely that the cost of re-engineering the entire code base in something like Rust or Go <snicker/> will far surpass the cost of a hardware upgrade.

          1. jake Silver badge

            Re: @Jake

            Yes, this box runs the old COBOL code quite nicely. Unfortunately, it's a PEE CEE and doesn't have anywhere near the I/O capability of a mainframe. Which is the problem in the case in point.

            I still use my 9track tape and cards to support various clients.

            They'll probably re-code it in JavaScript ("so it'll run in a browser", of course). And no doubt require blockchain ... ::sighs::

            1. Someone Else Silver badge
              Alert

              Re: @Jake

              I still use my 9track tape and cards to support various clients.

              You got a 24-oh-whatever to connect to a "Pee-Cee"?!? Dude, I'm scared of you!

              1. jake Silver badge

                Re: @Jake

                "You got a 24-oh-whatever to connect to a "Pee-Cee"?!?"

                It's not all that hard. Most of the 1970[0] and later pre-PEE CEE computer peripherals had an HP-IB/GPIB/IEE-488 option (this can easily be retrofitted if needs be ... usually). Slackware drives most of it quite nicely with a little bit of tweaking, and the various BSDs make life even easier. (This last is subjective ... BSD and I grew up together.) You're on your own if you run Redmond[1] or Cupertino[2] consumerware ...

                The fun hack was convincing Slackware that yes, a 1963 IBM 1402 is indeed a valid printer, and gibberish is NOT what I intended to print.

                But usually the mainframe peripherals are connected to their respective mainframes as Gawd/ess intended. Some people meditate. I collect and restore big iron.

                [0] That's not a hard cut-off. In fact, the line is about as blurry as they get.

                [1] How in the hell can Microsoft release an operating system THAT obese, and yet not find room for a couple K worth of print drivers for a line of printers that'll probably happily take a direct hit during Armageddon and come out unscathed?

                [2] I rather suspect that Apple's underlying BSDness can be beat into compliance by a properly cognizant hacker. It's on my listie o'things t'do in my !copiousfreetime.

        9. Jaybus

          Also, it's not like the principles of what this code does have changed in the past few centuries. The old accounting and etc. COBOL code produces plain text output, albeit perhaps as EBCDIC text. Nevertheless it is very straight forward to create an app that calls upon the old code to do the heavy lifting and then translates the old EBCDIC text results to JSON and makes it available to the SaaS gobbling, web-based UI flavor du jour.

          Recompile, move to a VM on modern hardware, install translator app, and voila! This old code is turned into "cloud" crap.

      2. Public Citizen

        "If it ain't broke, don't fix it."

        Oh it's broken all right.

        The circuits for generating the reality check [external to the actual hardware and software requiring replacement with current kit] just haven't generated their output yet.

        Looks like New Jersey just had those circuits kick in, and with a vengeance that will express its full output come the November Elections.

      3. Pascal Monett Silver badge

        It's still a great plan - but only if you can still maintain it.

        When you can't maintain a thing any more, you should basically consider it broke and search for a replacement.

      4. LaFiend

        "if it ain't broke don't fix it"

        I'd say if you can't fix it if it does break, it's already broke.

      5. ssaunders

        As an "old and decrepit" former COBOL coder (the last code base I wrote was in '95), I am *almost* surprised that it is still being used by so many orgs, particularly in the US, *especially* after Y2K.

        I guess (just like 9-11 and COVID-19), "no one saw this coming". Typical governmental bureaucratic mindset: "We'll (eventually) get around to replacing it -- until then, what we have is still working".

    2. VE3ID

      Seems like they are trying to get enough people to create the Mythical Man-Month!

  2. Dan 55 Silver badge
    Unhappy

    if they find enough people and start the project now

    They might have the problem fixed (whatever it is) by the time a vaccine comes out next year.

    This virus seems to have caught a lot of people with their pants down, except probably Germany.

    1. BebopWeBop

      Re: if they find enough people and start the project now

      And certainly South Korea and Singapore.

      1. First Light

        Re: if they find enough people and start the project now

        Also a shoutout for the state of Kerala in India, where they are used to dealing with epidemics, there are tons of doctors per capita, and the politicians let the experts do their jobs.

      2. Stork

        Re: if they find enough people and start the project now

        Add Taiwan

        1. A.P. Veening Silver badge

          Re: if they find enough people and start the project now

          While you're at it, add Vietnam.

  3. Warm Braw

    Is that actually what they need?

    It sounds like they need capacity and they're unlikely to be able to get that by rewriting code at this point.

    Legacy COBOL programs tend to be tied to legacy databases and legacy hardware so it's unlikely blue-sky thinking will involve Azure any more than Cobalt.

    They probably need first to consider solutions like replicating the application on any spare hardware they can find and dividing the workload between them in such a way that the data can be consistently reconstructed later (such as by first letter of surname).

    1. Steve Davies 3 Silver badge

      Re: Is that actually what they need?

      IBM has lots of lovely Mainframe capability in its cloud. If you want to run on the latest hardware and can't stomach the upfront cost (although a lot less than two decades ago) then that's the place I'd turn to in a crisis.

      It sounds to me that they need to not only increase capacity but to make some coding changes. The latter is bad news when done in a crisis. 'Act in haste, repent later' sort of thing.

      Just think what strains the UK's benefit system is under... PErhas NJ is preferable. Remember in NJ you can't pump your own gas. (or that was the situation the last time I visited)

      1. Warm Braw

        Re: Is that actually what they need?

        It sounds to me that they need to not only increase capacity but to make some coding changes

        I just visited the State's job vacancies page to see if there were any clues as to their environment, to be greeted with the announcements:

        The application is not compatible with FireFox. Please use one of these browsers; Internet Explorer 11, Edge and Chrome

        and

        This site does not support browsing from a Mobile or Tablet device.

        Perhaps they need to spend less time on actively preventing things working - they might then have time to do the important stuff.

        1. Anonymous Coward
          Anonymous Coward

          Re: Is that actually what they need?

          "The application is not compatible with FireFox. Please use one of these browsers; Internet Explorer 11, Edge and Chrome"

          At my company, that just means they have that POS called Oracle running.

          1. bombastic bob Silver badge
            Facepalm

            Re: Is that actually what they need?

            since when would Oracle web front ends NOT support Firefox???

            That's just WORSE than SILLY, it's ARSE-ININE!

        2. bombastic bob Silver badge
          Devil

          Re: Is that actually what they need?

          If you write PROPER HTML code that does NOT rely heavily on scripting (particularly NOT things like JQuery or any OTHER "modern" abomination that does the same thing) you won't have this problem.

          I like tables with embedded 'style' values. It's easier to control the appearance of a specific page that way. And I keep any common CSS definitions *SMALL*. Anything more than a handful of things is TOO MUCH and needs re-design. [well HELL, _THERE_'s your problem! Your CSS definitions, when unmangled, is over 4000 lines! and what's that 16,000 line script thing DOING anyway?]

          I have NEVER found a web-based thing that could NOT be done entirely on the server. Sometimes it's a little kludgy to force it, but that does NOT mean it can NOT be done effectively [and even efficiently]. Unless you're doing a dynamic stock ticker with charts, you don't need script to update it once a second (or at ALL)! And click-through-scripts RARELY need to be there. Hyperlinks and buttons with forms. DUH! [on occasion I've done an on-click but that was for embedded touch-screen systems, for which you control the browser and everything else about it, and if I didn't SPECIFICALLY think it was a better way to do it I would NEVER have done it that way]

          And suddenly... your site looks good on Firefox, Chrome, Edge, Intarweb Exploiter, Safari, Opera, Konqueror, Midori, and even on mobile when you rotate the screen properly!

          (minus the stupid-script and ridiculous-styles just about ANY browser will look pretty good with your pages if you don't totally bork the formatting and include the 'viewport' meta tag)

        3. skeptical i
          FAIL

          Re: Is that actually what they need?

          re: "Perhaps they need to spend less time on actively preventing things working"

          Yes. This. I am appalled at the number of official and government websites that will not do a single thing without javascript, the latest greatest browser whiz-bangery, and so on. One would think that everyone on any device, browser, operating system should be able to access basic health/safety information. Sure, some pages may require special stuff (e.g., applying for unemployment (and/or whatever) will require the doo-dads to ensure secure encrypted connections) but that should be the exception to information accessibility and not the rule.

    2. bombastic bob Silver badge
      Devil

      Re: Is that actually what they need?

      for MANY such situations, SIMH comes to mind... (assuming there's a working simulator for their hardware, and chances are, there is).

      Back in the day gummints liked IBM and VAX and occasionally HP or Data General minicomputers. Later there was Sun and DEC Alpha and others I'm probably not aware of. So "how ancient" is it? In the worst case, if you can manage to hook up a tape drive or serial [or even ethernet] link to transfer stuff, SIMH might fix the problem...

    3. Wellyboot Silver badge

      Re: Is that actually what they need?

      +1 @warmbraw >>>data can be consistently reconstructed later<<< which may well be very simple.

      Making code modifications on the fly will only end in tears.

    4. Henry Wertz 1 Gold badge

      Re: Is that actually what they need?

      "It sounds like they need capacity and they're unlikely to be able to get that by rewriting code at this point."

      This. COBOL is designed pretty well for the use it's being put to, for record keeping and accounting. I took a COBOL class in 1999, honestly the way COBOL programs are written it's unlikely to have any loops or mounds of code executing that it doesn't actually need.

    5. Denarius Silver badge

      Re: Is that actually what they need?

      legacy databases ? Luxury that! More likely C-ISAM files aka indexed files. If a DB maybe IMS. Now there is a DB that will have skill shortages. Is DB2 40 years old ? C-ISAM on inside though. Can't see why recoding is needed if the issue is workload as others have pointed out. Upgrading hardware should work and that won't be free or fast even if possible. A full migration to new hardware will mean an updated OS ($$ katching $$$) and then the incompatibilities start, despite IBM trying hard for backward compatibility. IMHO, would be better to virtualise on mainframe emulator on a decent (gag, choke, splutter, Am I really saying this ?, choke) windows cluster running Hercules using a fast storage system. Should be able to avoid recoding but get boost in CPU, IO and memory speeds. Migrating data might be entertaining.

  4. sanwin

    Technical debt bites – but beancounters never get it in time.

    1. Someone Else Silver badge

      Technical debt bites -- but usually not the beancounters.

      Prolly because the beancounters just taste bad.

      1. jake Silver badge

        If they don't get bit, how would it know their flavo(u)r?

        My money's on the stench ...

    2. Dinanziame Silver badge
      Angel

      From the article: the least-convenient possible moment

      Strange how problems that only occur during catastrophic events always happen at the least-convenient possible moment

  5. jake Silver badge

    We've been saying an upgrade is necessary for literally decades.

    So now they want us to work for free? What kind of suckers do they think we are?

    If it was an accident, I'd do it for free ... but let's face it, long-term gross incompetence on the part of elected officials is hardly an accident. There is more than enough money in the state coffers to provide a better retirement for a couple dozen retired COBOL programmers who missed out on the dot com boom due to age.

    1. bombastic bob Silver badge
      Childcatcher

      Re: We've been saying an upgrade is necessary for literally decades.

      see icon </snark>

      1. Wellyboot Silver badge

        Re: We've been saying an upgrade is necessary for literally decades.

        In a political operating environment where the senior manager are also appointed by the elected officials the political benefit of any large public spend is assessed, then they spend the money on whatever makes them look good now, not for the benfit of the next seat warmer in 5-10 years time.

        1. Doctor Syntax Silver badge

          Re: We've been saying an upgrade is necessary for literally decades.

          "they spend the money on whatever makes them look good now, not for the benfit of the next seat warmer in 5-10 years time."

          In that case they should be spending money now, not looking for volunteers.

    2. martinusher Silver badge

      Re: We've been saying an upgrade is necessary for literally decades.

      To be fair, though, its quite likey that this system is conceptully nothing like the dot-com type software that we're all used to these days. It would have been a mechanization of a batch oriented data workflow, one that might well have started out life as maual and maybe had migrated to electromechanical tabulating systems at some point. Most of this wouldn't be recognized as 'computing' by most modern programmers (just as they won't make a lot of sense of antique computing hardware) so any attempt to modernize it without wholesale overhaul of the workflow (something that may run headlong into legal issues) will result in disaster.

      I don't think the problem's with COBOL, its not a difficult language to learn, but rather with the methodology behind the design, coding, testing and running of this type of system. Its a little world of its own.

      1. jake Silver badge

        Re: We've been saying an upgrade is necessary for literally decades.

        "its quite likey that this system is conceptully nothing like the dot-com type software that we're all used to these days."

        Who is "we", Kemosabe?

      2. Down not across

        Re: We've been saying an upgrade is necessary for literally decades.

        Most of this wouldn't be recognized as 'computing' by most modern programmers (just as they won't make a lot of sense of antique computing hardware)

        Antique computing hardware makes more sense than the modern. All my "relics" Just Work(tm).

        Too many (thankfully not all!) modern programmers also could do with pulling their heads out of their agile arses long enough to actually assess if what they;re doing and if it is the right solution to the problem in hand.

  6. Gene Cash Silver badge

    Volunteers? Seriously?

    If they don't have money to pay people, then it's obviously not a big problem.

    This is a textbook example of "Lack of planning on your part does not constitute an emergency on my part"

    1. BebopWeBop

      Re: Volunteers? Seriously?

      While I do agree with the sentiment, this might be a situation in which "You bastards. The lack of planning on your part constitutes an emergency on the rest of us"?

      1. A.P. Veening Silver badge

        Re: Volunteers? Seriously?

        If it is an emergency, there is no problem whatsoever with rounding up those bastards and putting them in front of a firing squad.

  7. Steve Channell
    Facepalm

    You can't make this sh1t up

    The problem will most likely be an array in working storage, which are defined like

    05 claim OCCURS 1000 TIMES.

    Fixed array sizes are not as daft as they seem, but were a mechanism to enable the scheduler to avoid over committing resources while scheduling jobs. For S/370 it was also used for 20-bit, 31-bit (XA), 64-bit (ESA/z) compilers to fit into smaller memory regions

    As with any engineering problem, it is not the one-line code change that takes the effort, but the elaboration of dependancies and testing that takes the effort. It might not be feasible withing the constraint of compiler, os, platform. That one-line change can grow into a quarterly upgrade.

    The "solution" is probably to run the batch multiple times, or force people to wait longer.. which brings us to the politics: "don't blame me, blame the IT" with the new twist "blame yourself/compatriots for not volunteering"

    1. GreyWolf

      Re: You can't make this sh1t up

      One subtlety here - they probably don't have the source code anymore......

      And you must take that seriously. I know of a major international company running vital UK infrastructure that has only 25% of the source code needed

  8. Anonymous Coward
    Anonymous Coward

    "cobalt [sic] computer skills"

    Nothing new here. My previous employer is still using COBOL based ERP, and fixes are still provided, along with minor development. Luckily no mainframes are used, just x86 servers, and the whole thing is used with the ACUCOBOL runtime binaries.

    regarding the cobalt skills...

    We had a couple of Cobalt Qubes to play with 20 (?) years ago. It was a reasonably cheap x86 NAS / Mail / Web server for small businesses.

    Easy to use since the underlying Linux was supposed to be used from the web UI. (as long as you knew what you were doing)

    As was the norm, the SUN hardware was much more cool looking than the contemporary traditional x86 servers.

    1. BebopWeBop

      Re: "cobalt [sic] computer skills"

      Talking about colours, I do fondly remember a Silly Graphics Indigo workstation. Very desirable at the time....

    2. bombastic bob Silver badge
      Trollface

      Re: "cobalt [sic] computer skills"

      as far as 'cobalt' is concerned - it was probably auto-corrected by a spell checker. They're lucky it wasn't turned into something more snark-worthy!

      And you know those teleprompter-only politicians, couldn't ad-lib a one-line kid's joke if their LIVES depended on it!

  9. Version 1.0 Silver badge
    Happy

    COBOL is still running

    So they have code written 40-50 years ago running fine but now overloaded and probably running on antiquated hardware - I still have an RL02 in the garage if they need some more storage.

    So what's the solution? Rewrite the code in Java or Rust? If they do that with today's coding methods do you think that there's any chance that the code will still be running in 40 years? Does anyone think it would even be running in 4 years?

    COBOL has a major advantage that it was created for specific business tasks like this, it is significantly self documenting and flexible so it's probably not going to be a big task to maintain the code and update the hardware to support faster access - and still be running the database in 2080 because training new programmers to maintain the code would not be difficult.

    1. Dan 55 Silver badge

      Re: COBOL is still running

      Rewrite the code in Java

      You'd have to be certified to start a new project now using Larry's Trojan Horse full of lawyers.

    2. Stoneshop
      Holmes

      Re: COBOL is still running

      Does anyone think it would even be running in 4 years?

      ITYM "... within 4 years?"

      1. A.P. Veening Silver badge

        Re: COBOL is still running

        Make that "... within 8 years", 4 is way too optimistic.

        One small problem though, 8 years is two election terms away, so completely out of bounds for any politician.

    3. bombastic bob Silver badge
      Devil

      Re: COBOL is still running

      "I still have an RL02 in the garage if they need some more storage."

      hence my earlier comment about SIMH

    4. Doctor Syntax Silver badge

      Re: COBOL is still running

      "training new programmers"

      That's the key phrase. Their issue is not with the difficulty, it's because it involves spending money training people and then paying them. What's worse those are the sort of people who have to know what they're doing whilst they themselves have been getting away without that for years.

      1. Dave 15

        Re: COBOL is still running

        They could adopt the British approach... .pay the square root of fuck all, then complain no one wants to do it, shut down all the training, complain we havent got anyone to do it and bung the whole lot out to Bangalore to prove it cant be done and then complain you have feck all jobs, feck all for people to do and that every menial task left in the UK needs you to import vast quantities of eastern europeans who havent been told the pathetic wages they are being offered wont allow them to live any better than 20 to a house on watery soup... then wonder why they feck off at the earliest possible chance as well.

        As long as the rich get richer the rest can feck ff to hell in a hand cart.

        Mind you, when covid-19 wipes out the western economies totally, kills millions because places like the UK havent even bothered training their millions of unemployed to be a nurse, maybe, like after the blackdeath, something, some attitudes, might (only might) change.

        In the meantime, still being told that after proving we can work from home us few remaining engineers will have to resume struggling through the rush hour traffic if our companies survive the depression and we survive covid because of course the fact we delivered while at home doesnt at all count as anything compared to our bum being glued to the chair our masters provide where they can monitor how many piss reaks we take.

        1. batfink

          Re: COBOL is still running

          Reg Rant Score: 99/100.

          Good job.

        2. tip pc Silver badge

          Re: COBOL is still running

          The thing is people are often more productive away from their work colleagues who pop over for a natter.

  10. ColinPa

    Solving the wrong problem...

    I suspect they do not need cobol programmers.

    1)They need application programmers if they need to fix application bugs

    2)They need to contact IBM and borrow a faster box. If they have space in the machine room, wheel it in, plug it in and restart. Old systems should still run on the new box. Neweer boxes have even more RAM.

    3)The box may be OK, but the database is not. A faster box may help, but not if they are having deadlocks or the applications have built in serializations. These days ever things should be in processors memory or disk cache

    4)There is an application bottleneck for problems like "hold this lock while I chat to the end user" a faster box will not help.

    I suspect techies know the problems - management do not understand.

    1. Anonymous Coward
      Anonymous Coward

      Re: Solving the wrong problem...

      I suspect techies know the problems - management do not understand.

      This is what separates good IT from bad - the ability to articulate the issue to the non-technical decision makers. If you can't explain why you need resources as well as explain the risks & benefits, then you are only doing half your job.

      1. bombastic bob Silver badge
        Trollface

        Re: Solving the wrong problem...

        they need Simon the BOFH to help 'em out

    2. bombastic bob Silver badge
      Trollface

      Re: Solving the wrong problem...

      "management do not understand."

      Yeah they need to wait "over by the window" while the schmott-people are working...

    3. Dave 15

      Re: Solving the wrong problem...

      Everything in processors memory or disk cache... of yes, the wonderful reason a 'modern' operating system takes two hours to start up and 3 to shut down, loading the world and its friends into cache.

      No, you just need to write it so you do the slow operations once, you dont waste time loading 65,000 colour icons for everything 20 times and recalculating the edge of a display window and what of the background no one gives a fig about you have to reload into the display memory. FFKS todays huge processor machines run like crippled slugs becuase of the stupidity of the idiots who program the operating systems and applications.

    4. tip pc Silver badge

      Re: Solving the wrong problem...

      “ 2)They need to contact IBM and borrow a faster box. If they have space in the machine room, wheel it in, plug it in and restart. Old systems should still run on the new box. Neweer boxes have even more RAM.”

      Most IBM mainframes are over provisioned.

      Buy the base model with base ram, cpu I/O Etc and the box is basically software throttled. Buy a better license and ibm enable more capability. CPU goes fairly, softwAre automatically retires it and brings in an already on box spare.

      Newer tin is often better because it uses less power and cooling, has faster interconnects etc for the same capability license but existing tin can go faster with the appropriate licence, obviously means spending money though.

  11. EarthDog

    It's mission critical! We need more help!

    Are you willing to pay for that help?"

    "It's not that critical"

  12. Anonymous Coward
    Flame

    Been there, done that, this isn't it

    In all seriousness I programmed and implemented unemployment insurance systems for states using COBOL on IBM 360/370 mainframes . . . 40 odd years ago.

    This sounds like a capacity problem which needs better hardware. Optimizing code might help, a little, but only if they have the source code and the documentation and they're willing to pay for a full time team of COBOL coders. Even then you're talking 2021.

    This also sounds like an excuse.

  13. J.G.Harston Silver badge

    Can I do it remotely? As with the PDP11 job some years ago, they want people on site now immediately at once, and I can't just abandon my life and go to the other side of the world.

    1. J.G.Harston Silver badge

      Wait a mo, they want UNPAID volunteers? Where does it say that? "Volunteer" isn't the opposite of "paid", *UNPAID* is the opposite of "paid", *CONSCRIPT* is the opposite of "volunteer".

      1. Imhotep

        In the US, it's generally safe to assume that "volunteer" = "unpaid".

        Hospitals and other organization that use unpaid labor commonly refer to them as volunteers.

  14. Elfoad Regfoad
    Coat

    An old joke

    Is it time to trot out the joke from 20 years ago about the about the COBOL programmer fed up with dealing with fixing Y2K programs? He has himself frozen until a better time. Unfortunately, there's a bug in the machine and he remains frozen for 9,800 years. When he's woken he's told it now the year 9998 and he's asked if knows COBOL because they have a Y10K problem.

    Icon: Perhaps it's time for me to leave

  15. Miss_X2m1

    New Jersey is a Financial Train Wreck

    Regarding fiscal soundness, New Jersey is in DEAD LAST PLACE when compared to the other 49 states in America. They have squandered money year after year. They owe BILLIONS OF DOLLARS to their pension funds. The level of corruption that you find at the local, county and state level is staggering. Ancient computers? Nothing surprises me when it comes to New Jersey.

    1. ecofeco Silver badge

      Re: New Jersey is a Financial Train Wreck

      This. Their computer problem is only a symptom of their real problems

  16. Richard Boyce

    Not just COBOL

    There are probably also old systems still happily running PL/I, which was the main language I used in the 70s and 80s. I'd love to work in that langauge again; it was a very nice and powerful language.

  17. Sam Adams the Dog

    This is not technical debt!

    Others have made the same point I'm making without using the words I just used.

    Technical debt is when you do a rush job and don't write your code in the manner currently mandated for maintainability and extensibility.

    There is no evidence that this happened when the code was written. And (pointed out by others) it's worked fine all along.

    This is purely the fact that the code and infrastructure are too slow to handle the suddenly increased load. A capacity problem, as someone else pointed out. They could upgrade their hardware (still possible, as others have pointed it out), or contract out the excess, presumably to IBM. The latter is presumably the wiser course because this rat will work its way through the snake in time.

  18. Merrill

    I wouldn't necessarily assume it is an IBM mainframe

    Until at least a few years ago, the local county's payroll ran on Unisys. And I don't know why it would have changed.

  19. Sleep deprived
    Happy

    Volunteer to program in COBOL?

    You'd have to pay me for that!

  20. Beaudog68

    It is the management of the environment

    The issue is neither related to Cobol nor a Mainframe Computer.

    IBM has continually provided newer versions of Cobol, with new features. The issue is the lack of investment by those that are maintaining to recompile or utilize new features.

    Stating infrastructure is 40 plus years old is also misleading as IBM releases new Mainframe architecture on a scheduled basis around 3 years. The Mainframe is not running out of capacity either as it is licensed at capacity levels, those responsible for contracts have decided to stick with what budgeted for in that capacity setting.

    The Mainframe is still the best at transactional processing, and used in many corporations and most in banking industry.

    The architecture is not the issue, but the people managing the architecture. I have seen instances of infrastructure management where the hardware is 20 plus years old and they also decided to not pay software maintenance charges making things non upgradeable.

  21. Sentar

    I learn and coded COBOL back in the 60's.

    I bet it has changed a lot since then to today's COBOL.

    Regards Carl

  22. Cobol

    Former COBOL programmer

    How can I help or apply. I was a COBOL/cics programmer for about 15 years.

  23. SVV

    we literally needed cobalt programmers

    Yes, every techie knows that to process higher numbers of a particular transaction per day, you need to add more programmers not more servers.

    However if they really do need to change the code, maybe because some ultra restrictive conditions for a claim were hard coded in that now need to be relaxed, then they of course are going to hit the Fred Brooks paradox whereby adding more and more people to a project makes it later and later. And I would definitely add this example to the list of false economies where penny pinching frugality increases long term costs.

  24. The-Land-of-Cobol

    When you have to grind the burger, COBOL is hard beat!

    Burroughs, Unisys, IBM, Microfocus, doesn’t matter.

    Collectively, there is still about 2 Billion lines of code still out there.

    Colleges do not teach COBOL and should!

    Us dinosaurs won’t live forever.

    1. Admiral Grace Hopper

      There's still a large amount of the United Kingdom's IT infrastructure running on ICL VME mainframes, as well as the fine manufacturer's you name. Sperry-Burroughs had a particularly fine salad bar in the canteen that I visited, I recall.

      1. Jan 0 Silver badge

        Do these mainframes run the ICL OS whose source code has been lost?

        1. Anonymous Coward
          Anonymous Coward

          The code for the OS hasn't been lost, indeed it's been re-implemented on Linux. The code for the compiler in which the OS and much of the superstructure was written is a different matter though.

  25. Anonymous Coward
    Anonymous Coward

    Volunteers? After they outsourced everything years ago?

    They want volunteers? They must be kidding. They, along with every financial and insurance institution in NJ outsourced all that work to India, Russia, Philippians and China, putting many programmers here out of work, and now they want volunteers.

    Any good COBOL, CICS, DB2 programmer, which these systems are likely built on, should demand a king's ransom, if they even want to do the work.

    Personally, if they want my services, my rates will be $2,400 per day for an 8 hr day, and $600 / hr for OT. That's the going rate for a good attorney.

    Many like me told them, when they told us that they were going to send the work abroad to cut costs, that we're changing careers and will not be available if and when the crap hits the fan. I think the crap just made a huge mess.

    1. A.P. Veening Silver badge

      Re: Volunteers? After they outsourced everything years ago?

      If they want my services, my rates are the same numbers but in Euros, I require a healthy relocation bonus (and a Green Card) as well as major fire power against that madness called IRS. I don't really mind paying taxes (pay more here and now than I would in the USA), but I strongly object to the global reach of the IRS and I want to be rid of them when I leave the USA.

      1. Miss_X2m1

        Re: Volunteers? After they outsourced everything years ago?

        Even WITHIN New Jersey itself, they have outsourced many jobs to private sector companies in order to eliminate job positions within the government.

      2. Dave 15

        Re: Volunteers? After they outsourced everything years ago?

        The main problem with the IRS is the 5000 page tax return. Never seen anything like it anywhere. When you leave just dont tell them where you go, they've not yet sent a hit squad for me

    2. Dave 15

      Re: Volunteers? After they outsourced everything years ago?

      I think you are being far too cheap... lawyers are 10 a penny really, millions of them around. If they go pleading to India for them to fix this it will cost them a quarter of a million to get a quote, they will pay through the nose and it wont get delivered anyway (see the NHS computer system for a UK government all time fuck up of biblical proportions.... one they still learnt the square root of fuck all from as they still use the same bloody French consultancy and the same bloody model... those in charge in the UK civil service are a bunch of anti British fuckwits who should all be hung drawn and quartered).

      You are needed, you can, and should, charge a bloody fortune, no more than that, enough that it hurts them right to the very core.

    3. batfink

      Re: Volunteers? After they outsourced everything years ago?

      So, having outsourced all their support, why are they not simply going to their outsourced supplier with this problem?

      Oh - didn't bother to include COBOL (or even Cobalt) support in the deal? Tough shit then. Why should anyone volunteer to sort out your self-inflicted problems?

  26. Anonymous Coward
    Anonymous Coward

    Volunteers?

    Healthcare workers are valiant an selfless, but they don't work without pay. What makes this guy think that they can get programmers, COBOL or otherwise to want to work for free?

    1. Doctor Syntax Silver badge

      Re: Volunteers?

      Arrogance.

    2. Dave 15

      Re: Volunteers?

      Its especially galling when you get the shove because someone else is 'cheaper' then get begged to help... they didnt give a flying fukc about you when they found someone cheaper so let them find out the hard way that when you show no loyalty yourself you cant expect any back. Companies also need to take note as they keep requiring dedication, loyalty etc etc from their workforce and then stab them in the back when they arent needed any more

      1. Alan Brown Silver badge

        Re: Volunteers?

        "Its especially galling when you get the shove because someone else is 'cheaper' then get begged to help..."

        ALWAYS ask how much they're paying. Start with 3 times your previous salary as a consulting gig then keep piling on fees until you see them blink.

  27. Beaudog68
    Meh

    It's the management of the environment

    The issue is neither related to Cobol nor a Mainframe Computer.

    IBM has continually provided newer versions of Cobol, with new features. The issue is the lack of investment by those that are maintaining to recompile or utilize new features.

    Stating infrastructure is 40 plus years old is also misleading as IBM releases new Mainframe architecture on a scheduled basis around 3 years. The Mainframe is not running out of capacity either as it is licensed at capacity levels, those responsible for contracts have decided to stick with what budgeted for in that capacity setting.

    The Mainframe is still the best at transactional processing, and used in many corporations and most in banking industry.

    The architecture is not the issue, but the people managing the architecture. I have seen instances of infrastructure management where the hardware is 20 plus years old and they also decided to not pay software maintenance charges making things non upgradeable.

    1. Alan Brown Silver badge

      Re: It's the management of the environment

      "I have seen instances of infrastructure management where the hardware is 20 plus years old and they also decided to not pay software maintenance charges making things non upgradeable."

      Yup. There's no money to do ANYTHING until the building is burning down around your ear but you're the bad guy for having pointed out the needs in the first place and now for saying how much it's going to cost.

  28. Admiral Grace Hopper

    COBALT?

    FFS.

  29. ColinPa

    This is 2 additional transactions a second

    206,000 a week - 5 days a week 8 hours a day is 1.4 new requests a second.

    What are they doing in their transactions You can do thousands of credit card transactions a second

    1. Stork

      Re: This is 2 additional transactions a second

      Or logging phone calls. I think I heard of 20 million entries per day in the old monopoly 's db in Denmark

  30. Confuciousmobil

    Cobalt

    Why does everyone assume he meant COBOL? He clearly says Cobalt.

    Any CAD designers out there that could help him?

    https://en.m.wikipedia.org/wiki/Cobalt_(CAD_program)

  31. TrumpSlurp the Troll
    Trollface

    Over thinking this?

    As another ex COBOL programmer this has been a touching nostalgia trip.

    However as some others have suggested this may not be a coding problem.

    Long experience with non-technical management suggest a sequence similar to:

    The system just won't cope with these numbers. We've been warning your for years that it is obsolete and under powered.

    Don't bother me with your problems. I want it fixed now!

    We need more powerful hardware. This system should cope. We can have it running in 6 weeks if you authorise the spend today.

    How much? You're kidding me. You're just trying to use a crisis to empire build. Get out and don't come back.

    Harry? Yeah, good. Yourself? Listen we have a minor computer problem. Can you find me some Cobalt programmers? Guys will be out of work now so there should be plenty of volunteers.

    1. AK565

      Re: Over thinking this?

      Silly me, I took all this as a given.

      I agree, but you forgot to mention that most non-tech management assumes that tech people don't understand what's "really" going on or how things "really" work in the "real" world. They also assume that tech people really want the equipment for their own pet projects that aren't work related.

      The whole volunteer thing is just absurd. Why would anyone do that? You want access to a person's skills? Then you pay for it. This applies across the board: programmers, doctors, nurses, interpreters, teachers, etc. It's a safe bet the people calling for volunteers aren't themselves volunteering.

      1. A.P. Veening Silver badge

        Re: Over thinking this?

        I'll volunteer (in my own country) about half a year after managers start volunteering their services and I'll retract that offer the moment managers quit volunteering. If they can keep it up for half a year, they will be about ready to appreciate my skills at their true value.

      2. Dave 15

        Re: Over thinking this?

        Is the guy asking for volunteers leading by example and voluteering himself? No, hes getting bloody well paid

        1. A.P. Veening Silver badge

          Re: Over thinking this?

          No, hes getting bloody well paid too bloody well

          FTFY.

  32. SecretSonOfHG

    There's a rather interesting twitter thread on this

    Where the chap (forgot the name) that ran the project described what happened when the state launched a project to replace these NJ systems with a single solution that managed the data previously held in a dozen of disparate systems.

    In summary, they wanted to integrate all data in a single place, only to find once the project started that it was close to impossible due to huge data quality issues. Legacy apps had no data validation whatsoever in even the simplest or most crucial data points. SSNs allowed dates, simple things like gender were not validated. So no way of replacing all these with a unified system without making significant investiments in the legacy data and their ways of processing data. That meant political battles between all the different management organizations that led nowhere because it was always the other's guy fault. And yeah, why fix what is not broken (from their miopic, cost-saving, ass-preserving perspective)

    All this compounded by an outsourcing partner whose program management kept punishing progress reports that were different from "all green, no issues" and firing staff that tried to raise issues.

    After some time and quite a sum of money wasted (millions of dollars) the project was abandoned.

    I'm sure that this story is all too familiar with many people around here.

  33. 2Fat2Bald

    Note how they want the work done for free. Work they could have paid for at any time in the last few decades.......

  34. haiku
    FAIL

    CYA anyone ?

    In short, a polician's standard fix for CYA: blame someone else.

  35. Anonymous Coward
    Trollface

    Unemployed COBOL programmers

    "This morning the Department of Labor reported that over the past week more than 206,000 new claims for unemployment were filed, meaning that in just the past two weeks alone more than 362,000 residents have filed for unemployment."

    And not a single one of these people looking for a job had any experience as a COBOL programmer! But I guess volunteers are cheaper than employees.

    1. jake Silver badge

      Re: Unemployed COBOL programmers

      "And not a single one of these people looking for a job had any experience as a COBOL programmer!"

      That's because COBOL programmers are only out of work when they want to be. I wrote this post back in January of 2009. It has remained true for the last 11 years. I rather suspect it'll still be true when my Granddaughter retires. She'll be 10 in September.

      COBOL is dead! Long Live COBOL!

  36. trevorde Silver badge

    Career choices

    Worked with an intern c2000 when Windows, COM and C++ were the latest, shiniest tech. Everyone was really excited about the tech and new toys, except him. We asked him about whether he'd be working with us on the bleeding edge after he graduated. He replied that he wanted to work on COBOL systems, much to our revulsion, disgust and horror. He pointed out that he'd always have a job. Not sure what happened to him but he's probably coining it right now.

    1. A.P. Veening Silver badge

      Re: Career choices

      And he was right. I don't want to work on the bleeding edge either as I don't like my blood being spilled, which is exactly why it is called the bleeding edge.

      And for about that same reason you'll never find me pushing the envelope, the pushing is always in the same corner where the stamp gets cancelled.

  37. ImpureScience

    Wait a minute...VOLUNTEERS? Damn, if it were PL/I and there were decent $$$ involved (MVS, TSO, Panvalet, and PL/I were us in the Before Time) I would do it in a NY minute, I'm right across the river.

  38. Mike Cresswell
    Joke

    Someone contact Scott Adams

    Bob the Dinosaur is a COBOL programmer if I remember correctly.

    1. A.P. Veening Silver badge

      Re: Someone contact Scott Adams

      You remember correctly, but isn't he extinct by now? Haven't seen him in ages (and I do receive the daily Dilbert).

  39. onebignerd

    The federal government has the same problem, they pay big money for Cobol programmers because they have alot of systems that depend on it. They did recently upgrade their oldest computer system which was about the same age as NJ's. But it isn't enough to get them out of the jam of ancient systems. They struggle to patch or update the newer systems/PCs they do have, which stretches back to the Regan Administration. The FBI was running ancient PCs even after 9/11 that were unable to use a mouse or run any modern software, still running an old mainframe using multiple databases that could not be synced. Only because their previous director was tech-phobic.

  40. AK565

    Volunteers???

    I'm really stuck on this point. My brain can't process that TPTB actually want highly trained professionals (of ANY field) to work for free. I get asking people to "volunteer" to come out of retirement and go back to work. But to ask them to work for free is pretty ballsy.

    Are TPTB working for free? I doubt it highly.

  41. Anonymous Coward
    Anonymous Coward

    OutSource Batch Proccessing To Maximize Production

    Back in the early 80's Northrop Data Center did a lot of Batch Proccessing for Large Companies during the 3rd Shift. New Jersey just might be suffering from a limited SIZE Data Center and they do NOT want to increase their current MAINFrame FootPrint; The downtime to increase the Data Center, they would then need to address the a SPOOLING and Capacity issue to increase Production I/O. So, for immediate Relief; They may need to OUTSOURCE via "Batch Processing", and the UCC1, UCC10, & UCC11 Scheduler will need to be modified to allow the Outsorced Bacth Proccessing to address the Proccessing request load. Call me, I could use the work during this "SHUTDOWN Period". Email me, Provide the CITRIX VPN Access, a Log in Code and access to the RERUN/RESTART and Tape Mangement System. .

  42. rafff

    COBOL programmers wanted

    Every so often I get asked if I will take on a COBOL job. My first question is: How much does it pay? The invariable answer is that they are still paying 1970s rates.

    Nuff said.

    PS Back in the day I did actually do some COBOL work, but that was 40 years ago.

    1. Dave 15

      Re: COBOL programmers wanted

      You cant be in the UK

      In the UK they dont pay 1970s rates, not even close. No, they offer less than they will pay in Bangalore and then threaten that if you dont work for that you wont get any benefits either

  43. HammerOn1024

    Murphy... party of one

    Governor Murphy... hum, since when did the peanut butter down side on the carpet crowed get into office? Oh yeah... New Jersey... right.

    Politicians have to save their pocket book.... err... "union constituents"... before any pesky non-highway or port infrastructure.

  44. oldfartuk

    I loved COBOL, it was the first high level language i learned in the 1980's on a PDP-8, to the sounds of the Strangers 'Golden Brown', and a 1966 A3 line printer Snoopy calendar on the computer room wall. It was a beautiful, elegant language, ideally suited for all of us with Aspergers.You could arange the code neatly, in logical ascending structure until you had reduced the entire program to

    Perform Program()

    Until end..

    Nothing that followed ever managed such elegance.Not even the quich eater Nikluas Wirth (if you arent old school you'll have no idea who he was).

    1. John R. Macdonald

      @oldfartuk

      I've done the same in PL/1, which has my preference over COBOL.

  45. James Anderson

    Just guessing

    But given the almost infinite scalability of zOS based systems I would guess they are stuck on the one architecture thar did not scale well. CICS/VSAM.

    The problem being only a single CICS region can own a VSAM dataset. So it rapidly becomes a bottle neck when the system is under heavy load.

    Back in the 80s most shops migrated their VSAM to DB2, allowing dozens of CICS regions to access the data simultaneously.

  46. ecofeco Silver badge
    FAIL

    Volunteers?

    I think I've hurt myself laughing.

  47. Alan Brown Silver badge

    Anyone with any sense

    Will pitch up asking 50 times the going rate

    I've been telling people for the last 15-20 years that if they really want to make money, learn COBOL and take the time to understand ancient systems - it's still around, all the old hands are dying off and nobody understands the installations well enough to port to new software(*), so managers are afraid to touch it

    However it's not just a matter of understanding the language, when you work with ancient code you usually also need to try and understand the mindset and culture of the prople writing it, for the simple reason that it will help you decode what they wrote.

    (*) Look at all the clusterfucks(**) resulting from inadequately thought out attempts...

    (**) Including NJ's previous attempts(***) (thanks to other posters for the pointer)

    (***) Ah, Mr Bond, I see you have returned, having discovered there are no other vendors who can assist you. No problem - but the cost will be $$$THISMUCH (5 times previous figure), we write the spec thorough;y based on what you learned last time, then we get 100% control of the project, no thirdparty buttinskis allowed or there will be penalty clauses invoked.

    But you're desperate? Oh dear, the cost just doubled.

    1. Alan Brown Silver badge

      Re: Anyone with any sense

      "But you're desperate? Oh dear, the cost just doubled."

      It should be noted that the term "seller's market" also applies to labour forces.

      Whilst we won't see the fivefold increase in peasant pay seen after the Black Death there have been spikes in worker pay and conditions following every major pandemic and 1918 essentially created the idea of the NHS/state provided healthcare

    2. jake Silver badge

      Re: Anyone with any sense

      50 times? That'd be pushing it a trifle. Experienced COBOL coders are already making several times the rate of an average "web programmer" (whatever that is).

      I've been recommending people buck the trend and learn COBOL and Fortran since they started dropping the two in favo(u)r of C back in the '80s. Not a month goes by without a former student dropping me an email thanking me for the advice ...

      1. Alan Brown Silver badge

        Re: Anyone with any sense

        "50 times? That'd be pushing it a trifle. "

        Not at all. NJ has already blown several tens of millions of dollars failing to sort this out.

  48. A_Melbourne

    It is a hoax guys. They are simply moving anyone with influenza into the Covid-19 category. Plenty of terminal cancer patients are diagnosed as Covid-19 without even a test - after death.

    https://www.armstrongeconomics.com/world-news/corruption/the-covid-19-fraud-its-massive/

    As for Boris Johnson, he always did have a reputation as being a scoundrel

  49. Herby

    Just remember...

    Micro-Focus Cobol is written in (are you ready for this?) Micro-Focus Cobol.

    Maybe that is a clue...

    Of course, we all know that S/360 Fortran 66 (H level) was written in Fortran-H. But that actually worked (most of the time, save for some instances of OPT level 2).

    1. jake Silver badge

      Re: Just remember...

      I'm not all that sure what your point is. Most folks consider self-compiling /self-hosting to be a good thing, for many reasons.

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