back to article Retiring greybeards force firms to retrain Java, .NET bods as mainframe sysadmins

New IT grads and Java and .NET jockies are being re-trained to run mainframes by big companies desperate to replace a generation of IT staff giving up work. That’s according to Compuware, who has released a study that says CIOs are growing concerned about the looming skills shortage in their mainframe rooms. They are …

COMMENTS

This topic is closed for new posts.
  1. Chris Miller

    The logical action would be to migrate these systems onto a modern platform (probably rewriting them from the ground up). But this will never happen because: (a) it requires thinking over a timescale longer than 6 months; and (b) it involves spending money over the next few years (i.e reducing this year's bonus) to avert inevitable catastrophe later on.

    1. sandman

      Building from the ground up

      As Chris says, it would most likely involve building from the ground up. Many of these systems are more patched than Frankenstein. Over the years (most likely decades) functionality has been added to the basic systems, often programmed in different languages by people who left long ago.

      It is a genuine nightmare for many of the larger institutions.

      1. John Smith 19 Gold badge
        Unhappy

        Re: Building from the ground up

        "Many of these systems are more patched than Frankenstein. Over the years (most likely decades) functionality has been added to the basic systems, often programmed in different languages by people who left long ago."

        Correct.

        Here's the thing.

        CTO "I want to scrap all our old CICS/COBOL that's been written over the last 40 years and rewrite it in C++/Java/ML/LISP/WTF is the language De Jour"

        Board "Why"

        CTO It'll be easier to maintain (and it'll look great on my CV. And if I can make the systems administration work as well I'll be a God)

        Board "So what are the risks?"

        CTO "It'll take years, (look at Nationwide migration to SAP), cost 100s of $/£/Em and cause massive disruption.

        Board "And give us what we already have?

        CTO "Yes."

        Board "And is it likely your successor would want do the same, but with a different language?"

        CTO "Yes. (To the man who only knows VB everything is a button)."

        Board "I think we can can unanimously say that you can f**k right off with that plan."

        They might not care what they use for their gambling qualitative trading systems but when it comes to tracking what their customers owe them on a large scale banks are very conservative

      2. Shugyosha
        Headmaster

        Re: Building from the ground up

        "Many of these systems are more patched than Frankenstein"

        I hate myself for it, but I'm unable to move on until I've pointed out that Frankenstein is not particularly reknowned for being patched up. Frankenstein's creation however...

      3. Bakana

        Re: Building from the ground up

        Sadly true. The real problem is that, over those decades, both bad coing proactices and bad "Management policies" have Encouraged that Frankenprogramming.

        Policies like "Change it, but don't Remove the old code until the New Code have been running for at least six months." Yes, I've Seen it. What generally happens is that no one Ever has time to go back six months later and identify the code that Should have been removed. Besides, if you DO and a mistake is made, someong gets the Axe.

        I once had a single program that needed 3 very Simple Changes, the the FrankenCode was so bad that I could not get the changes to work. I had to get the specifications for the Entire Process (Thank god someone still Had them) and go through the entire program identifying all the dead code that No Longer executed under Any Circumstance.

        After I removed that, I was able to make the required change in 20 minutes.

        The program then ran perfectly, executed 20% Faster and the sourced code went from over 30,000 lines of code down to about 12,000.

        And it only took 2 weeks to perform the Analysis of the FrankenCode to achieve the results that could probably have been done in less than an Hour if Good Programming practices had been followed instead of arbitrary practices written by a Manager who knew Nothing about Programming but Lots about CYA.

      4. Michael Wojcik Silver badge

        Re: Building from the ground up

        Many of these systems are more patched than Frankenstein. Over the years (most likely decades) functionality has been added to the basic systems, often programmed in different languages by people who left long ago.

        We regularly hear from potential customers inquiring about decompilation, as they don't even have the source code for their back-office apps.

        When they do have source, it's often a vast amount of code, only a small fraction of which was actually used to produce the current set of binaries - but no one knows what fraction. There are tools to help analyze these massive legacy-system code bases (we sell some of them), but even budgeting that effort is difficult.

        I think Chris has hugely underestimated the cost of reconstructing legacy enterprise applications from scratch - as in, by several orders of magnitude. And the large majority of IT projects that large fail.

    2. Yugguy

      Actually this is being done in the financial institution I work for, but transferring the functionality of the core account system away from an old but stable solution is a MASSIVE undertaking and will take us several years. You can't just port it, you have to produce a brand new solution that does the same as the old one and takes the same inputs and produces the same outputs. There ISN'T an off-the-shelf new solution that can simply integrate with all our other systems.

      And yes, the COBOL coders who look after the existing system aren't getting any younger.

      1. Caff

        migrate off mainframe

        We just did it here in Irish Life ( recently aquired by great west life )

        migrated all the CLOAS code over to .NET and used microfocus enterprise server to keep a lot of the old cobol packages working.

    3. Anonymous Coward
      Anonymous Coward

      @Chris

      I think there's most likely actually one main factor which weighs in the most: boffins who believe that maintaining the status quo (even if this means training new people) will be cheaper in the overall than doing a full migration.

      And to be perfectly honest I can't really tell if they're right or wrong, it would most definitely depend on the environment and the way the company is doing. Most of all such a project would be huge (generally speaking anyway) and really demand some rock solid management and coding skills (the coding should be obvious; management to make sure it all comes together).

      So from that point of view I also think there's some logic to be found in keeping things as they are. Although I do agree with you; a rebuild would bring in a lot of new opportunities.

      1. Chris Miller

        @ShelLuser

        You make a good point. IM(NV)HO, the time to start the migration is when your existing systems are still reasonably hale and hearty. Free prediction: within the next 5 years, a major financial institution will crash and burn because they will suffer a catastrophic systems failure from which they're unable to recover. That should focus the minds of the risk managers.

        1. kiwimuso
          Happy

          Re: @ShelLuser

          @Chris Miller

          Yeah, and I bet that the catastrophic systems failure will NOT be on the mainframe side of things.

          It will be caused by 'modern' systems which have been poorly designed, written and integrated in the first place.

          But then, as a now happily (hence the smile icon) retired mainframe programmer (Assembler no less) who has written stuff for the banking industry and airlines with a side sprinkling of COBOL and PL/I, I would say that, wouldn't I.

          I wish I could have 2 icons, as my second one would be the beer icon, which would cause the first icon, and which I have more time for these days anyway.

    4. Bakana

      migrate these systems onto a modern platform

      If you research to various corporations which have Tried that "solution" you will find Lots of projects that Crashed and Burned and very few Success stories.

      Of those that didn't crash & burn, the majority either took 3 times as long as promised or are Still trying to find the end of that rainbow.

      It took a while, but there are very few major corporations left that Haven't already Tried that particular "Fix" and the managers who Survived are understandably reluctant to stick their necks out because many of them owe at least one Promotion to the departure of the guy who convinced upper management that "This is a Great Idea".

    5. Daniel B.
      Boffin

      COBOL

      The problem with a lot of these things is that they run on System/390 (which we now know as z/OS) and use stuff that only those familiar with S390 know: CICS, TSO, ISPF, COBOL, RACF, OMVS … if you know what any of those things are, you're probably better qualified than most people in IT these days. Note that I said "you know what it means", not "know how to do stuff with that".

      It also doesn't help that a lot of stuff from the mainframe's heyday was done in COBOL, which was all the rage back then in business realms up until Dijkstra rightfully slammed it and fell out of favor. (Sadly, nobody was able to do the same to Visual Basic.) Maybe the only thing worse than having to work with VB6 code or COBOL has to be MUMPS, and that language will also live for eons thanks to its usage in the US healthcare system.

      Some banks have been migrating their code to better languages like Java, but some of these projects take years or decades, and even then they only get something like "now we got 40% COBOL code in our core systems". Most of them have simply made some kind of "core system" for the lower-level stuff, and simply develop middleware stuff on top of that. Because nobody wants to be the team that broke the bank's code!

      1. davemcwish

        Re: COBOL

        And TELON....

        1. Anonymous Coward
          Anonymous Coward

          Re: COBOL

          COBOL? I never could get on with fancy high level languages like that. Stick with BAL - it is difficult to get simpler than that :~)

          1. Anonymous Coward
            Anonymous Coward

            Re: COBOL

            BAL? Pfft. Languages are for n00bs. If you aren't flipping switches then hitting a "RUN" button, you're taking the easy way out.

      2. Michael Wojcik Silver badge

        Re: COBOL

        The problem with a lot of these things is that they run on System/390 (which we now know as z/OS) and use stuff that only those familiar with S390 know: CICS, TSO, ISPF, COBOL, RACF, OMVS …

        COBOL is most definitely not exclusive to IBM mainframe OSes, and never has been. CICS, TSO, and ISPF all run on multiple platforms. I'm not aware of any non-z RACF implementation, but RACF ain't that complicated; we have an implementation of the major SAF APIs and features (which I wrote) for our product line. OMVS, of course, is only of interest if you're running MVS or zOS, so I'll give you that one.

        if you know what any of those things are, you're probably better qualified than most people in IT these days

        Well, yes. Better-looking, too.

        COBOL, which was all the rage back then in business realms up until Dijkstra rightfully slammed it and fell out of favor

        Dijkstra's "How do we tell truths that might hurt?" screed is hardly a sensible commentary on programming languages. The man was a fine computer scientist, but that piece is pretty much the feeblest essay he ever wrote; it's nothing more than an extended rant, with no actual argument to make. Nearly every one of his points is an absurd generalization that fails to hold up under any sort of rational consideration, much less be supported by empirical data.

        And COBOL did not "[fall] out of favor" in 1975 when Dijkstra wrote "truths that might hurt". It remained the preeminent business programming language for at least another couple of decades. 4GLs and similar DSLs, though they played a role as far back as the '60s, didn't really gain traction until the early '80s (note that's when the term "4GL" was coined). Some other business programming languages such as RPG and PL/I had significant market share, but nothing like COBOL's. Visual BASIC and Java both appeared in the 1990s.

        the only thing worse than having to work with VB6 code or COBOL has to be MUMPS

        There are more things in Heaven and Earth, Horatio.

        Some banks have been migrating their code to better languages like Java

        OK, I'll bite. What makes Java a "better language" than modern COBOL?

  2. Pete 2 Silver badge

    in a free market there's no such thing as a skills shortage

    > CIOs are growing concerned about the looming skills shortage in their mainframe rooms

    Merely an unwillingness to pay the salaries that supply and demand indicates as the going rate.

    Having said that, there does come a time when the cost of employing specialists becomes greater than the cost of "de-specialising" and replacing the niche kit with more generic solutions that the new generation of cheap, trained and plentiful staff have the knowledge to support.

    Knowing when that time is and planning for the eventuality is one of the basic jobs of senior IT management. However, when the CIOs and their direct reports keep their heads in the sand, spend all their time focused on the immediate and not the strategic, this is the inevitable consequence. That's just the cost of being out of touch with market trends.

    1. Destroy All Monsters Silver badge

      Re: in a free market there's no such thing as a skills shortage

      This.

    2. ElReg!comments!Pierre

      Re: in a free market there's no such thing as a skills shortage

      Unfortunately it takes more than 6 month to train a skilled sysadmin able to make _real_ iron work reliably.

      1. Tom 13

        Re: it takes more than 6 month to train a skilled sysadmin

        While true, it doesn't mitigate the primary premise: if managers had been valuing the skill they now find to be in short supply, people would have been training for the mainframes.

        Here's the thing. I was in high school when the Sinclair and TRS-80s were being released. A friend of my mother's worked at IBM and passed along manuals for some of their stuff to me. Mainframes and minis. At the time people were predicting the demise of mainframes. It still hasn't happened. I don't work on the big iron myself, my area of specialization is on the micros. But I don't foresee the death of mainframes even after 10 years. There are some things they just do better than anything else out there. And the people who are migrating from "old iron" to "modern platforms" will discover that to their dismay.

    3. Phil W

      Re: in a free market there's no such thing as a skills shortage

      While I understand the sentiment, since the IT sector in general is known for not always offering competitive wages because the posts and skills are undervalued by management, there certainly can be such a thing as a skills shortage.

      If there are no people, or only a very limited number of people, with the skills you are looking for then that's a skills shortage.

      An extreme example is, for instance, if you wanted to employ someone who could speak a language like Arawá, Aka-Bo or Esselen, you'd be out of luck since there's no-one alive who speaks them any more.

      More realistically from an IT and mainframe point of view, the number of people with knowledge and experience of these platforms is dwindling. Certainly there are people alive who know them, but many of them have retired and have no interest in being employed again.

      Of the ones that are working, some of that number may not wish to leave the job they have, salary is not the only motivation to take a new job or leave a current job.

      1. Warm Braw

        Re: in a free market there's no such thing as a skills shortage

        Except the problem here is not dying languages. This ancient technology is often documented a lot better than its modern counterpart because it dates from a time when technology was sufficiently expensive you could afford to employ technical writers. COBOL, CICS or JCL are not really hard things to pick up from the manuals.

        The real problem is that the business processes are not properly documented and the fact that, say, there's logic resulting from a merger back in 1987 that means the third digit of the account code results in special processing ever third tuesday is lodged firmly in the heads of the support staff and nowhere else.

        That means you can neither accurately rebuild the systems from the ground up, nor solve the support issue by simply retrotrending the IT staff. It also means that exactly the same problem will occur in 25 years time with all the newfangled Java and .NET code - or much likely a worse problems as there won't still be dusty manuals on the shelves to remind you, when the online documentation is long gone, exactly when the Validate() method of that System.IdentityModel.Selectors.X509CertificateValidator object gets called.

        1. DB2DBA

          Re: in a free market there's no such thing as a skills shortage

          Bingo!

        2. cordwainer 1

          Re: in a free market there's no such thing as a skills shortage

          . . .the third digit of the account code results in special processing ever third tuesday is lodged firmly in the heads of the support staff and nowhere else.

          This is, indeed, the biggest problem I've encountered in a 30-year career. Worse, no matter how many times someone fails or forgets to tell a new IT hire some crucial detail, almost never is that detail added to internal documentation or training materials (assuming either even exists).

          In my admittedly very personal opinion, and recognizing there are numerous exceptions:

          It's a scathing indictment of the IT industry that with all the amazing developments on the "T" side, we fail so miserably at communicating the most basic "I", both to each other and the end users we support.

          We can not blame non-IT management or budget cuts alone for IT professionals' continued problems communicating effectively with each other, nor repeated failures to document critical processes and procedures, then actually follow them.

          I hesitate even to comment on the extent to which egos and territorialism have contributed to these problems. However, there is no doubt certain "historical" attitudes continue to bedevil us, and negatively affect others' overall impression of IT and those who labor in the field. Sadly, in far too many cases, IT staff have only themselves to blame for the lack of cooperation and support they receive from the non-IT side.

          Certainly there are times when a business must change to meet the needs of an increasingly technological world. However, IT must move away from the attitude that the "latest and greatest" is always the best, or that business "should" or "must" alter itself to fit that technology. The emphasis of IT should always be the safety, integrity, and usability of Information, without which there would be no need at all for most of our shiny Technology.

          1. Bakana

            Re: in a free market there's no such thing as a skills shortage

            I can offer one example of where the problem gets Magnified.

            An acquaitance who absolutely Loves the C Family of languages because it is very Easy to write code that you CANNOT tell what it does from reading the source code.

            He gleefully explains to anyone who asks him WHY? that:

            "If it was hard for me to Write, I want it to be even Harder for the next guy to understand."

            He's a Big Fan of the Obfuscated C Code Contest.

    4. TheOtherHobbes

      Re: in a free market there's no such thing as a skills shortage

      >in a free market there's no such thing as a skills shortage

      There's no such thing as a free market.

      And if it takes 5-10 years to train up the next generation of specialists, you can offer as much as you want and still not find the people you need. Especially if your current systems have so many undocumented features you have no way of knowing what they actually do - certainly not to the point where you can consider replacing them.

      At some point the industry is going to have to stop building clockwork breaks-when-you-look-at-it IT and start building smart adaptive IT. But that's at least a couple of generations away, and we probably won't have banks or other institutions in their current form when it happens.

      1. BlueGreen

        Re: in a free market there's no such thing as a skills shortage @TheOtherHobbes

        caveat, I've no experience in banking however

        > And if it takes 5-10 years to train up the next generation of specialists

        That's a damn big 'if'. I don't buy it.

        Now in particular this

        > Especially if your current systems have so many undocumented features

        and from @Warm Braw

        > say, there's logic resulting from a merger back in 1987 that means the third digit of the account code results in special processing ever third tuesday is lodged firmly in the heads of the support staff and nowhere else.

        This, if true, would indicate a TOTAL FAILURE OF PROCESS and therefore A TOTAL FAILURE OF AND BY MANAGEMENT. Where you have tens or hundred of billions of £££ in your care, you don't hack like a garage startup.

        1. Tom 13

          Re: a TOTAL FAILURE OF PROCESS

          If all you have is a college degree in business management (or the equivalent), I can see where you'd believe that. All it takes is a couple years of real world experience to disabuse you of that notion.

          The big bosses have all agreed that because of the way the balance sheets work, the merger should go ahead. None of them have a clue about the incompatibility of the systems, but the guys they hired tell them there are technical solutions to those problems. And the deadlines are unrealistic with no one hired to write the documentation (I know I worked in exactly that field before I moved to break/fix deployment side). So you find the inelegant but workable hack that binds the systems together and maybe even have good intentions of coming back later to fix it properly. Except that the next big merger has come along and you're back in the same fix again next year.

          Two jobs back we had a kludge of a system one of our divisions depended on. It was written in Delphi 2.0 using the Borland Database Engine 5.03 with some Crystal Reports 7.02 something or other I don't remember any more (not a programmer, just the poor schmuck installing the crap). The sexy language at the time was an early iteration of Visual Studio .Net. Now, we could get the BDE installed without too much trouble (well document on the install and two patches) and even the Delphi 2.0 wasn't a problem. Crystal Reports however turned out to be rather a problem AND rather a serious sticking point. The bit that I can't remember was a very, very, specific version of Crystal. From it you could select a subset of functionality that could be run from the network without actually requiring a Crystal install on the desktop. Apparently the next letter revision undid that bit of uniqueness. But the specific letter revision didn't run on the developers machines when we migrated from Windows 2000 to Windows XP. So we patched it. And 8 months later started getting reports about problems with inconsistencies from the user community. It turned out that whenever a developer updated a module with the new version of Crystal, it broke the inter-operability of that shared store on the network. About 30 employees were using the system, but it was tracking hundreds of millions of dollars in research money that was being distributed by the government to various medical research groups. Yeah, not pretty. They brought in a bunch of people who were going to port the data to a new program they were writing in a modular mode with modern software. About 6 months later I was part of a 50% RIF in the IT department. But the last I heard, the new program wasn't nearly as functional as the old one, and still had issues with inconsistencies in the reports.

          I don't think anybody anywhere along the chain had bad intentions. But the end result was a serious problem at a midsized company (less than 500 employees, certainly nowhere near the Fortune 10000 in terms of market share). In a company with even longer lines of communications, I don't see things improving any.

          1. BlueGreen

            Re: a TOTAL FAILURE OF PROCESS @Tom 13

            > a couple years of real world experience

            I have a lot more than that. I maintain such failures are management issues.

            > None of them have a clue about the incompatibility of the systems

            management failure

            > but the guys they hired tell them there are technical solutions to those problems

            They had better have good, solid, technical reason to believe these guys they hired, else they are bullshittees who hired bullshitters to lay on the bullshit in thick, soothing layers. In which case, management failure.

            > And the deadlines are unrealistic

            Who set the deadlines? Management failure

            > with no one hired to write the documentation

            guess what? :)

            This is all management failure at one level or other, or multiple levels. This may be down to stupid short-termism of the stock market, but that's another matter.

            On to your description of woe, there's not enough info there for me to try and allocate a blame. In that case there may not be one (just maybe). However,

            > but it was tracking hundreds of millions of dollars in research money that was being distributed by the government to various medical research groups. Yeah, not pretty

            suggests that this core piece of dosh tracking code was seriously underfunded. If so, who was to blame.

            I'm familiar with a lot of this kind of crap. I've been in it before. I do sympathise. In one job a few years ago they got very excited when I mentioned I had delphi 5 because it turned out their product was based on D5 and the only D5 compiler + library install they had was on the programmer's development laptop (nope, no install disk). Disaster waiting to happen. So I gave them mine (Embarcadero refused to give them D5 under any circumstances, even if we paid the full price for the latest delphi (8 I think it was)).

            Management failure in not having all the software their business depended on? You tell me.

            > I don't think anybody anywhere along the chain had bad intentions.

            Sometimes management failure is inherited from previous management but however the penny lands, 'no bad intentions' <> competent planning. The fact that that's how the many organisations operates, just on on the edge of disaster, doesn't change the fact that this is wrong.

            Yes, the real world depresses me often because I have to live in it.

            1. Tom 13

              @BlueGreen

              They had better have good, solid, technical reason to believe these guys they hired, else they are bullshittees who hired bullshitters to lay on the bullshit in thick, soothing layers. In which case, management failure.

              I'm not usually in the room when those decisions are made. But I had a bird's eye view once. The guy making the decision wasn't a bullshitter. He was in fact, the sort of boss I'd like to work for if all bosses were like him. He wanted to find reasonable technical solutions to business issues, pay everyone a fair salary, and have everyone get along. His technical skills were rusty but he knew his stuff in the day and sometimes it still came in handy. They weren't shiny because he'd been placed in a position where he had to deal too much with people who didn't have his outlook on the business. We interviewed three people for a Help Desk Manager position. One of them bored me to tears and I couldn't remember a thing about him. Governmental functionary type but his accomplishments resume looked good. Another one was bright, energetic, and marked off a couple boxes on the quota sheet. In a different environment I would have hired her in a heartbeat. One problem with her stood out. We didn't have a lot of documented processes. What we had was learned by apprenticeship. And while management was trying to move us more toward an ITIL model it was a hard slog. For almost every question she referred checking the documented processes. She wouldn't have lasted two weeks in our environment. The third person was the one I liked. Sounded like he had come from an environment that started like ours, but made significant progress on documenting the processes and was leaving the company in a better place than he'd found it. He'd survive our environment and might even be able to fix some stuff. The Boss hired the first guy. His thinking was he'd be better able to handle some of the contentious office politics than the other two, and what he really needed was someone to offload that work to so he could focus on the other stuff that he really needed to. His rationale wasn't bad. And during the second interview his skill set sounded like it was going to be a decent fit to where we expected our company to be in a couple of years. I was RIFed about 6 months later (made sense from a purely business perspective, no need for the assistant to the manager when you only have half the people). Through the grapevine I heard that a couple months after that the guy broke his leg skiing, and 6 month after that found himself a new job. Yes, after the hire was made it turned out the guy was a really good BSer. But I don't think my boss was looking to be the bullshitee. And while I'm usually fair at smelling the BS, I didn't recognize how much of it he was laying on myself. It's not necessarily bad intentions, sometimes it is just a bad result.

              suggests that this core piece of dosh tracking code was seriously underfunded. If so, who was to blame.

              No one. When it was written it wasn't known that it was going to last as long as it did and that 15 years down the road it would be handling that much stuff. It was expected to last the length of a smallish five year contract and that it did quite well. But it got re-used because it existed, and more and more contracts were won and added to it. And until the switch to XP it all just kept on working. Keep in mind were talking about a company trying to make money managing government grants. The government regards that as more of a public service than something a private company should make money from, so margins are always razor thin. It's all well and good to argue that good management would have had a code review every time a contract was added and that all risks would be identified and factored into the cost of the contract. The reality is there are always unknown risks.

              If there are no real-world examples of success, it is time to give up on the ideology no matter how right it feels.

              I'm not saying I haven't gone off on the exact same rant you are when I've had a bad day. And God it feels good to rant like that. But if good management as described by you succeeded we'd see a hell of a lot more of it than we do.

              1. BlueGreen

                Re: @BlueGreen @Tom 13

                > If there are no real-world examples of success, it is time to give up on the ideology no matter how right it feels.

                Hmm. I've seen abundant failure due to clear deficiencies due in turn to bad management. So many it hurts. When I see problems grow expensively because someone didn't do the right thing earlier sometimes as little as a few days earlier, when it is known good practice to do X, and X wasn't done due to the boss, it's bad management.

                I've been through too much to accept what you say. Favouritism in hiring an promotion, outright nepotism, underpayment of good staff so they left (despite having the money to pay), childish tantrums at staff cos they had a row at home with hubby, lack of process, lack of automation, disregard of the opinions of professionals, psychopathic bullying, failure to evaluate technical alternatives because they (bosses) weren't technical guys so didn't understand the pros and cons so assumed they didn't matter (common), also - my favourite - rating people's worth by how much you pay them rather than what they contribute (familiar?).

                I don't accept what you say, sorry.

                Interesting story you gave and you make a good point, sometimes the boss isn't to blame. Here's mine: I had an excellent boss, a real good guy (one of the very few I've ever had). A reasonable guy that, quite reasonably, expected his staff to behave reasonably. Well, there was some office politics that I got caught up in that was seriously damaging a critical project which he'd put me in charge of. It nearly sank this project which most likely would have bankrupted the company. He did his best but in the end he just could not stop a few guys trying to bust my work (some weird professional jealousy, and looking back I handled it badly too). He just could not sort out that situation because these guys were not going to be reasonable or rational. The main troublemaker could not be sacked for reasons I can't give; he was effectively untouchable.

                We got it done but it was close and a scarring experience (and we got it done because he fought to get me the resources he could when I asked for them. He was a good guy).

                BTW this guy's competent, professional attitude to management in other areas showed me what could be done by good management. He was my "real-world examples of success", even if a large chunk was in adversity.

                > The government regards that as more of a public service than something a private company should make money from, so margins are always razor thin.

                The government as procurer squeezing too hard thus putting a valuable service at risk - does that sound like bad management to you? Note that my definition of management here may be going further than yours, which is where we may be crossing wires.

                1. Tom 13

                  Re: @BlueGreen @Tom 13

                  I've been through too much to accept what you say. Favouritism in hiring an promotion, outright nepotism, underpayment of good staff so they left (despite having the money to pay), childish tantrums at staff cos they had a row at home with hubby, lack of process, lack of automation, disregard of the opinions of professionals, psychopathic bullying, failure to evaluate technical alternatives because they (bosses) weren't technical guys so didn't understand the pros and cons so assumed they didn't matter (common), also - my favourite - rating people's worth by how much you pay them rather than what they contribute (familiar?).

                  Yeah I've seen all of that too. And given the rants here on the board, smart money is on most of the rest of the posters here have too. But that's the problem: with so many of us seeing so much bad management out there and so little good management it moves from anecdotal to data. If the data say the Darwin is favoring "bad" management, there must be something to it. I don't know what. And I suppose for the people that I know, its good for them that I act on what I've described as your "ideology" even as I question its validity.

                  I'd probably like you as a boss. And my personal beliefs mirror yours on this issue. But we sure don't seem to be winning the war so I have to start asking "Why?"

                  1. BlueGreen

                    Re: @BlueGreen @Tom 13

                    > I'd probably like you as a boss

                    Wow, that is indeed a compliment! Whether I could live up to it... I really, really don't know. But thanks!

                    > so I have to start asking "Why?"

                    That's a difficult one and I have a view that's unsatisfactory but it just might have some validity. I'll think it through and post tomorrow, maybe.

                    In the meantime I by coincidence picked up this and am currently reading it (and this is the first ever management book I've read, it just caught my eye 2nd hand) http://www.amazon.com/The-Effective-Executive-Peter-Drucker/dp/0887306128 which is making me think hard, and may prove very valuable. It is also blessedly short and free of bullshit. It may prove useful to you too, and may go some way towards answering your question.

                  2. BlueGreen

                    Re: @BlueGreen @Tom 13

                    Ok, to try to answer your question "so I have to start asking "Why?""

                    People will accept crap, indeed demand it, if said crap is what's hot for the moment.

                    People will typically buy the cheapest, often through ignorance, sometimes even if they know better ("buy cheap pay twice" never takes root in their head, as my otherwise decent landlord is finding out).

                    People demand short term results. This is often said about the stock market - cash now, screw the future. That's a recipe for short-term thinking.

                    Conclusion - end consumers are in a sense managers, and collectively, rather poor ones. Their sheet quantity is perhaps the predominant driver.

                    To a more specific comment of yours "If the data say the Darwin is favoring "bad" management, there must be something to it".

                    Yesss... there is. People are getting what they demand (see above). In the short term (less than a year) this forces the creation of short term thinking. Long term investment seems to be discouraged.

                    But your mention of Darwin is a bit misleading I think. Darwinian evolution as you mention it seems to suppose vertical transmission of beneficial attributes, but organisations are highly porous and valuable components (ie. people) come and go in decades or years or sometimes months, which makes me think their existence has a lot of what looks like horizonal gene transfer (Horizontal gene transfer). Therefore good attributes (people) are not be preserved (they leave) and bad attributes can seep in (get hired). If the environment of a business is poor, good stuff gets diluted out almost osmotically unless much care is taken.

                    The analogy is flawed but it seems to have some truth, I think.

                    Well, that's my take and it may be crap but it's my best shot. Even if it has explanatory value it doesn't tell you how to fix the problem. It's pretty bleak in that respect. Sorry.

                    Also see cordwainer 1's post for an interesting take.

                    (On a somewhat less bleak note, we do have some control. I note that the personality types that create businesses sometimes tend to the arrogant, power-hungry and slightly sociopathic end of the spectrum (this is *not* a criticism, just an observation). Reasonable, measured, people like many posting here are not the types to bull ahead think the world owes them so we tend to end up being employees. Well, personally speaking, I'm trying to set up a business because I've had enough working for others. I may fail - failure *is* an option - but I'm damn well going to try. How about you?

                    Wish me luck).

              2. CowardlyLion

                Re: @BlueGreen

                What does RIF stand for in your comment?

                None of the definitions I can find seem to fit...

                http://acronyms.thefreedictionary.com/RIF

                1. Tom 13

                  Re: @BlueGreen

                  Reduction in Force (workforce). These days you usually see it as "right-sizing" the company or redundancies.

        2. The Stolly

          Re: in a free market there's no such thing as a skills shortage @TheOtherHobbes

          "Where you have tens or hundred of billions of £££ in your care, you don't hack like a garage startup."

          Oh yes you do.

        3. Michael Wojcik Silver badge

          Re: in a free market there's no such thing as a skills shortage @TheOtherHobbes

          > say, there's logic resulting from a merger back in 1987 that means the third digit of the account code results in special processing ever third tuesday is lodged firmly in the heads of the support staff and nowhere else.

          This, if true, would indicate a TOTAL FAILURE OF PROCESS and therefore A TOTAL FAILURE OF AND BY MANAGEMENT.

          Welcome to the real world. We see this sort of thing all the time.

          Where you have tens or hundred of billions of £££ in your care, you don't hack like a garage startup.

          Oh, and you were doing so well, too.

          1. BlueGreen

            Re: in a free market there's no such thing as a skills shortage @TheOtherHobbes @Michael Wojcik

            > Welcome to the real world. We see this sort of thing all the time.

            Yes, it's my world too. You may not believe this but recently I was ***explicitly*** told not to document a complex data structure. By the boss. You could not make it up.

            > Oh, and you were doing so well, too.

            :(

    5. Fatman

      Re: in a free market there's no such thing as a skills shortage

      This portion of your last paragraph needs some editing, which I offer below:

      However, when the CIOs and their direct reports keep their heads in the sand up their asses, spend all their time focused on the immediate bettering the next quarter's numbers and not the strategic, this is the inevitable consequence. That's just the cost of being out of touch with market trends.

      FTFY!!!

      Hey El Reg, where's the NO SHIT, SHERLOCK icon???

    6. Rick Giles
      Linux

      Re: in a free market there's no such thing as a skills shortage

      "the new generation of cheap, trained and plentiful staff have the knowledge to support"

      Thanks to Microsoft, anyone can claim they are a Systems Administrator because they can click the mouse button.

    7. Baruch Atta

      Re: in a free market there's no such thing as a skills shortage

      "...a mis-applied software patch from a team in India, and came after the bank had cut hundreds of IT staff to help cut costs....."

      Date: 1950

      Place: electric company.

      Issue: bill to millions of customers for their electric service.

      So, imagine 10 million customers, and each one must get a "reading" by a rep, then the rep's reports must be received, added to each customer's file (in file cabinets). Then each month the file must be pulled, the numbers added, the bill written, mailed and stamped. Then the bill must be received, the check read, the file pulled, the check amount added in, the file returned. Also, files must be checked for customers that failed to pay that month.

      For each 1000 customers, there must be at least one clerk. So for 10 million customers, there are 10,000 clerks doing the work of reading, file pulling, writing bills, receiving payments, and so on.

      Fast forward to 2014.

      Same electric company.

      Same 10 million customers. Same rates, reading meters, billing, receiving payments.

      But now it is all automated.

      Instead of 10,000 clerks, there are 20 programmers.

      Imagine!

      But wait. The management thinks that they pay too much to the programmers. The programmers are squeezed, and five are let go. Now management can boast that they "saved" a million dollars by firing 10 programmers.

      No, the programmers "saved" the company 100 million dollars by automating the billing.

      Seems pretty stupid. But then, it is a management decision.

      Lesson learned: DON'T SKIMP ON PROGRAMMING! ! !

  3. Jim 59

    Literally

    I know I know, grammar sniping is the lowest form of commentardery, but-

    It’s the mainframe that often holds customer accounts – it’s literally where the money sits

    sorry and all that.

    1. fandom

      Re: Literally

      You are complaining about the meaning of words, that has nothing to do with grammar.

      And dictionaries now say that "literally" means "figuratively", you have already lost the war, move on.

    2. Vector

      @Jim 59 Re: Literally

      Besides, in this case, the classic application of the term is correct. In modern banking institutions, most of the money is nothing more than a digital representation which is literally stored and secured on their mainframes.

    3. Bakana

      Re: Literally

      Well, when so much "Money" is now nothing more than an Entry in a Database with no actual Physical existence, the word "Literally" is Correct.

      Unless you don't count the Hard Drives where the database is stored as part of the Mainframe.

  4. Admiral Grace Hopper

    Funnily enough, I've just been having a conversation about how to make COBOL and attractive option for recent graduates as without new blood to fettle the old code there's going to be a very expensive re-write coming down the line. 20 years convinced that COBOL would be retired before I was, now I'm not so sure.

    1. Peter 39

      right on

      There was quite a bit of interest around that time of Y2K but that quickly died out.

      The situation has not improved since then - quite the opposite. This will be an expensive "upgrade".

    2. Pete 2 Silver badge

      > how to make COBOL and attractive option for recent graduates

      Rename it to object.Cobol and start writing games in it.

      We already have a trendy language (Python) that is following the 1960's FORTRAN mistake convention of making whitespace significant. Sexing up COBOL shouldn't be too difficult,

      1. Pirate Dave Silver badge
        Pirate

        Hey, at least it's not Object.RPG with OpenGL extensions...

        1. John Smith 19 Gold badge
          Unhappy

          PPirate Dave

          "Hey, at least it's not Object.RPG with OpenGL extensions..."

          You do realize there are probably 4 people who read this that know what you're talking about?

          1. Peter Gathercole Silver badge

            Re: PPirate Dave

            Yes, I had a chuckle. My first job out of University forced me to learn RPG II, after I had been taught PL/1, APL and 6502 assembler (it was a long time ago) and taught myself C.

            In my acrimonious exit interview (they did not offer me any pay rise - not even a cost-of-living one after my first year, even though I had become the most effective programmer in RPG in the department measured by speed to completed correctly functioning program, and it was not just me saying that), I likened RPG to a rather restricted assembler language. And in hindsight, I think that I was being generous!

            Still, I'm grateful, as I moved on to be a long-term UNIX admin, which is what I am still doing.

            1. John Smith 19 Gold badge
              Unhappy

              @Peter Gathercote

              " I likened RPG to a rather restricted assembler language. And in hindsight, I think that I was being generous!"

              Historically RPG was a language for programmers whose only previous experience was assembler language.

              Fixed format upper case 5 character "opcodes" is exactly how a lot of assemblers have been laid out.

              BTW 3 address instructions with conditional execution flags --> ARM Assembler.

              RPG IV is meant to be much nicer, free format, lower case allowed, external subroutines etc.

              1. Peter Gathercole Silver badge
                Alert

                Re: @Peter Gathercote @John Smith

                Fortunately, I've never had to work with RPG again. In fact, I do so little programming now other than shell and awk that I have to think hard about writing anything.

                I have no problem with using condition flags like RPG and pretty much every assembler I've ever used. But at the time I was being told that RPG was a high level language superior to PL/1 or C, and that is why I made the comparison with such scorn.

                I think I still have my RPG II programmers card somewhere which lays out, at the same pitch as an 80 character card, all of the different phase card layouts (Aaaaargh - suddenly remembered about the input exception phase - The Horror!)

                1. John Smith 19 Gold badge
                  Unhappy

                  Re: @Peter Gathercote @John Smith

                  "But at the time I was being told that RPG was a high level language superior to PL/1 or C, and that is why I made the comparison with such scorn."

                  That really was a LOL moment.

                  TBH with time I have come to realize there is a simple truth.

                  If your support tools are flexible enough any language can be a viable development environment.

                  The trouble is that there seem to be very few tools that a)Language neutral enough and b)powerful enough to be applied to any language.

          2. Pirate Dave Silver badge

            Re: PPirate Dave

            "4 people who read this that know what you're talking about?"

            Judging from the comments, there's only 3... ;)

            I did some RPG in a class back in the late 80's, and touched it again very briefly in the late 90's. Can't say I liked it either time. I guess it's good for what it was designed for, but brrr<shiver>, not my style at all. COBOL, however, I liked. Go figure. I could work as a COBOL programmer and not feel like I was missing out. And I've got 20 years until retirement. Maybe I should polish my resume and leave my Ivory Tower...there might be good money to be made.

            1. John Smith 19 Gold badge
              Happy

              Re: PPirate Dave

              ""4 people who read this that know what you're talking about?"

              Judging from the comments, there's only 3... ;)"

              Well I did say "probably."

              Guess I was a bit over optimistic.

      2. Herby

        Spaces significant??

        "We already have a trendy language (Python) that is following the 1960's FORTRAN mistake convention of making whitespace significant"

        I'm sorry, but in Fortran the only place spaces are significant is in strings. You can leave them out in all other cases. In fact many Fortran compilers did just that as a first pass of the source code. It made for smaller intermediate files, when secondary storage was at a premium. Of course in PL/1 you had whitespace, but there you could use keywords as identifiers and the context would sort it out.

        Yes, a parser for Fortran is a wild beast.

        1. This post has been deleted by its author

        2. Pete 2 Silver badge

          Re: Spaces significant??

          > in Fortran the only place spaces are significant is in strings

          Tenses.

          That may well be the case now, but I made a point of saying 1960s FORTRAN. In the case of F4 (from personal memory) the first 6 columns were reserved for label numbers and if column 1 contained a "C" that line was deemed a comment.

          1. Peter Gathercole Silver badge

            Re: Spaces significant?? @Pete 2

            That was imposed as much from the physical media being used to contain the program as anything else.

            In the 1960's, everyone programmed on punched-card. You absolutely wanted to have card numbers on the card (not labels), and in a standard format, so that when you dropped your 500 card deck and the elastic band broke, you could stuff it through a card-sorter to put them back in sequence. The next column was, as you point out, a comment indicator. The rest of the card image was free-form, although with only 72 characters to play with, you could not really afford to be too generous with the use of spaces.

            It was not only Fortran that did this. Pretty much any language from the era did the same, and COBOL and RPG were even more strict about which columns things should be in.

      3. Michael Wojcik Silver badge

        Rename it to object.Cobol and start writing games in it.

        COBOL has been an OO language since the mid-1990s.

        I admit I am aware of few games written in it, though.

        1. Bakana

          I admit I am aware of few games written in it, though.

          Catch the Wumpus?

  5. The BigYin

    I'd love to do that

    I started out doing COBOL, now I'm a Java jockey. Moving back to mainframes would mean getting away from all the MS shit that I have to deal with day-in, day-out.

    Where do I sign up?

    1. DB2DBA

      Re: I'd love to do that

      "Moving back to mainframes would mean getting away from all the MS shit that I have to deal with day-in, day-out."

      Wrong. All the front end pieces are java. You'll be spending all your time figuring out what is going wrong with the Rube Goldberg connection system this time...

  6. Brewster's Angle Grinder Silver badge

    The story here is that companies are training people themselves. I nearly fell of my chair when I read that.

  7. PassiveSmoking

    Software rot is a business expense

    Nobody seems to take the fact that software isn't like traditional machinery, it needs to be constantly evolved and updated. Of course machinery needs maintainence (and eventual replacement) too, but typically of the "oil this, replace that worn out part" sort.

    Businesses usually take the limited life of machinery into account, but not the limited life of software. That's an attitude that needs to change, there needs to be plans in place to keep software up to date and if necessary ported to new platforms, otherwise this is the exact situation you'll end up with.

    1. Anonymous Coward
      Anonymous Coward

      Re: Software rot is a business expense

      Nobody seems to take the fact that software isn't like traditional machinery, it needs to be constantly evolved and updated.

      Actually, it is. There are many manufacturing techniques that were once state of the art but have gone the way of the dodo. For example, if you want to manufacture a spare for that aircraft component designed in the 50s, you might be horrified to find that you need to emulate something called a rubber press, or a drop-hammer, or even electron-beam welding. The difference with software is that within living memory it's gone from being regarded as something ephemeral that would be replaced with the next product, to something baked-in to systems that are expected to last for decades.

  8. qwertyuiop
    Thumb Up

    Life in the old dog eh?

    I got my first job as a trainee programmer 35 years ago this summer and learned COBOL on an ICL mainframe, later transferring to IBM mainframes. I remember in my second week at work picking up a copy of "Computing" and reading the banner headlines that COBOL was dead and soon nobody would be using it. I wondered seriously if I'd made a big mistake.

    Time passed. COBOL became un-sexy and was never mentioned. Then the world woke up to the "Millennium Bug" and suddenly grey-haired COBOL programmers were coming out of retirement and earning mahoosive amounts of money. And now this article...

    When Commander Grace Hopper "built" a language she built it to last!

  9. Anonymous Coward
    Anonymous Coward

    I was in a university not so many years ago (3? 4?), and one of the option modules was on IBM mainframes with JCL and COBOL. IIRC the course was funded by IBM, so that shows that they're trying to build up at least a little bit of exposure to the set-up.

    It didn't seem to be as dire a language as everyone was making out; but I think as someone said above -- if you can't draw pretty pictures on the screen with it you're not going to attract the kids who all think they want to work in the games industry.

    Seeing other people who took that module with me on LinkedIn, etc. though -- none of them appear to have moved into that market. The jobs don't seem to be their in the same scale as those for C#, Java, etc. -- and those I did see offered ridiculously low salaries (18-20k for graduate).

    1. I ain't Spartacus Gold badge

      I suspect this is a big problem. Companies have been using the same people for years to keep the stuff maintained. Probably paying them quite well, as when they threaten to leave, it's suddenly realised how much of the system documentation is in their heads.

      But not bothering to renew the resource by taking on anyone young. You can always poach a greybeard from someone else. So why bother getting 20 year-olds in, who you'll have to pay to train? Now they're finding out the answer.

      Sainsbury's tried to outsource all that messy mainframe stuff a few years ago. It was a horribly expensive mistake they had to reverse. The problem is that your stock control and POS stuff is complex, interlinked and totally vital to a retailer. If you're out of stock of the thing someone needs, they'll often go to a shop that does have it - and then buy the rest of their shopping their too.

      A smaller retailer I used to work for went for the worst of both worlds. All the COBOL type people were contractors. Great for the headcount, but I suspect it meant that there were no permanent employees with a picture in their head of what the mainframes were actually doing. Which is madness. It seems pretty brave to have no in-house control of systems that if they fail would destroy the business in a month.

    2. Anonymous Coward
      Anonymous Coward

      IBM itself needs new blood for mainframes

      They just don't want to train them themselves (not that they could - no IBM internal training resources any more).

      IBM is constantly trying to find reasons for the older, experienced and expensive people to leave the company, but now find that they don't have the skill in-house to support their customers. It's all going to end very badly if you ask me!

      In my view, COBOL suited many business processes really well, and in a way that object oriented languages really can't, at least not efficiently. I never liked it myself, but I only worked in business programming for a year or so, and even then not in COBOL.

      1. Bakana

        Re: IBM itself needs new blood for mainframes

        "COBOL suited many business processes really well,"

        It was there in the very Nane of the language: COmmon Business Oriented Language.

        Grace Hopper's design objectives were met better with COBOL than any language since.

        As far as I've ever been able to tell, most of the "Object Oriented" had One of several primary design objectives:

        "Make the Designer Famous."

        "Get the Designer a PHD."

        "Make the Designer a Tenured Professor."

        Occasionally all 3 objectives came into play.

  10. Tzhx

    Searching CWJobs for 'COBOL' returns around 10 positions. Most of them either high-level or short-term contract. Searching for JCL returned 0.

    Searching for C#, you get over a thousand.

    Not really surprising people aren't being attracted to it, so picking a few of your new batch of Java or .Net bodies is probably the only way to get people into this field.

    Which is a little sad. I'd quite like to go back to COBOL / IBM mainframes -- but #### me if I'm going to apply to be a Java or C# developer.

    1. Bakana

      CWJobs may not be the best place to search for COBOL Jobs.

      There are other sites with Hundreds of listings.

      The people who Post job listings tend to "cluster" on sites where the same set of job skills they are looking for show up in other people's listings.

  11. Anonymous IV
    Thumb Down

    It shouldn't take more than a couple of days...

    "What does Richards suggest CIOs should do to address the shortage in a more coordinated manner? First, profile your IT people by age, skills and the applications and systems they are responsible for. Next, capture and record their knowledge so it can be passed on to new people..."

    So years and decades of mainframe experience can be captured and recorded, in a sort of rapid "job handover" process? Mr Richards, you have found the secret of the universe.

    1. Tom 13

      Re: in a sort of rapid "job handover" process?

      Business use to have a decent planned handover process. Of course there was nothing "rapid" about it, but it worked fairly reliably. The old hand took on an apprentice for a number of years and brought him up to speed. When the old hand retired, the apprentice became the old hand and at some point sought out a new apprentice.

      1. Tzhx

        Re: in a sort of rapid "job handover" process?

        Always two, there are. A master, and an apprentice.

        1. Mycams
          Alien

          Re: in a sort of rapid "job handover" process?

          COBOL really is the "dark side" then.

    2. Pascal Monett Silver badge

      @Anonymous IV

      Sorry, but I fail to see where it is said that the process should only take a few days.

      Capture and record means meetings with the people working the processes, lengthy Q&A sessions to ensure that everything said is taken down, extensive review of the notes to produce a proper process detail report, and review and quality checks to ensure that the report mirrors reality.

      Anybody with a brain can see that the whole thing is going to take time.

      What I find very interesting is to find out that the accountants and MBAs/Senior Whatchamacallits didn't notice that they needed to ensure proper training for their personnel. COBOL has had the reputation of the dodo for decades already, it's not new. So how could these extremely (self-)important people NOT see this coming ?

      These are bankers. The first rule of making money is that you sometimes have to spend some to make some, and sometimes you have to spend some to keep making more. It would seem that banks (like many big-name companies that have gone astray in the past 2 decades - looking at you HP) have also been taken over by pure accountants, the kind who break out in hives as soon as they see an invoice or an expense report, and start shivering if the next quarterly report is not better than the last.

      It is time those kind of accountants go back to where they belong : dungeons. Let them sit on piles of gold and see if it gets more comfortable with time.

    3. Denarius
      Thumb Up

      Re: It shouldn't take more than a couple of days...

      @Anon4: Spot on. I vaguely remember "knowledge engineering" in expert systems classes I had to do in the 1980s. Problem seemed to be the issue of meta-knowledge. Most experts don't know what and how they know. Only BS merhcants claim that. How do you capture and record knowledge that no-one knows exists ? All those little quirks for historical reasons. Personal programmer idiosyncrasies. Unauthorized changes made at 02:40 to get critical system going again in emergency fix, forgotten about after falling asleep from 30 hour day.. Not to mention staff who know they will be dumped the moment the PHBs smell a bonus, so things get forgotten. Finally, is documentation up to date and read ? . Fully documented and available in correct location and staff bother to read it.

      ITIL is not part of the solution, it is part of the problem as currently implemented in most organisations. Make change process tedious, process ridden, slow, managed by rude process droids obsessed with their process, unable to seethe organisational needs will result in undocumented quick fixes because it is just too hard.to do change control.

      Finally, years of bitter experience give job longevity a great advantage. Corporate and technical knowledge give the owner an unappreciated understanding that no document can, no matter how clever the reader.

  12. Tom 7

    As Nelson Muntz says

    har haar!

    1. I ain't Spartacus Gold badge

      Re: As Nelson Muntz says

      My brain insisted on reading that as Nelson Mandela.

      I was confused for a few moments, until sanity re-asserted itself. One of these days I really must learn to read...

  13. David Roberts
    Pint

    Mainframe Sysadmins?

    Is it just me?

    I though mainframe *programmers* wrote in COBOL.

    [Which used to be at least partly self documenting because of the 'simple everyday words' syntax.]

    Sysadmins often have to know more arcane stuff - although it is {mumble} decades since I was system support for ICL mainframes.

    Just out of interest I Googled 'IBM Sysadmin' and found

    "The IBM DB2 System Administrator job role skill set specializes in problem determination and problem source identification of DB2 Databases and Instances, issues on Unix, Linux and Windows operating system. Skills and Responsibilities include: Technical knowledge of DB2 Engine commands and their applications on system level , Unix, Linux, and Windows Operating System commands, functions and capabilities; ability of addressing technical aspects of DB2 engine issues. Experience in iSeries/DB2 developer/DBA, iSeries operating system and architecture knowledge, Command Language Programming (CLP) on the iSeries, Implementer (iSeries change control tool), DB2 and SQL."

    No mention of JCL or COBOL.

    Perhaps the DB2 malarkey doesn't run on mainframes?

    Then again

    "Must know COBOL, JCL, CICS , Db2. Experience in Unix, MF Cobol (execution of COBOL programs in UNIX environment) is preferable."

    So exhuming crusty old COBOL programmers with a smattering of CICS and JCL may not be the full requirement (unfortunately, should I ever get bored of retirement).

    Still, no explicit mention of .NET and C#.

    Anyway, nearly time for my warm drink and nap.

    Beer, because that is what being retired is all about :-)

  14. hypernovasoftware

    How many of the hot shot gui programmers are going to want to work on boring mainframes?

    That's the real question.

    1. Anonymous Coward
      Anonymous Coward

      "How many of the hot shot gui programmers are going to want to work on boring mainframes?"

      Now I have picked myself up from the floor, and wiped tears of laughter from my cheeks ...

      That question presupposes that there exist "hot shot gui programmers".

      In my experience, that is not even close to a statement of truth.

      1. MissingSecurity
        Trollface

        re: hot shot gui programmers

        Arn't they the people who couldn't make it as Graphic Designers, and didn't want to take a job as a barista?

      2. hypernovasoftware

        I had my tongue in my cheek while posting that.

  15. Martin Gregorie

    On the benefits of keeping knowledge in your own head

    Far away and long ago (in the mid '90s actually) I was working with a bought-in package that interfaced an ATM network to a bank's accounting system. The system worked well but its documentation was, ahem, sparse, and so we relied on our accumulated experience with using it and with reading the code to customise it for new sites.

    Much of the code carried the name of one particular programmer who was obviously rather good at cutting code and distinctly less so at documenting it. In due course we ran into a difficulty on one installation that resulted in this programmer appearing on site. He turned out to be a really nice guy with a proper enthusiasm for beer, top programming skills and had been in the business a long time. I got to know him fairly well and once asked him about the documentation. He had an excellent reason for its deficiencies: he was due to retire in 2-3 years and told me there was no way he was going to rewrite the documentation any time soon because he knew he'd be tossed out the door by his money-grubbing American management the moment he'd completed it.

    1. Anonymous Coward
      Anonymous Coward

      Re: On the benefits of keeping knowledge in your own head

      what an ar$ehole.

      1. Mr. Chuck
        Go

        Re: On the benefits of keeping knowledge in your own head

        That expertise represents a working lifetime of training, experience and insight. Do you think that would matter to most managers looking to cut headcount or outsource? Not a bit.

        There are arseholes in play, but you have failed to identify the right ones. Stick to your .net toys if that gives you pleasure, and let the grownups run the real systems.

    2. Bakana

      Re: On the benefits of keeping knowledge in your own head

      A personal favorite was a problem we had that was causing Multiple crashes over several days. The old "Stay all night, go home and crash for 3 hours, take a shower and come back for another 24 hours" sort of problem.

      Eventually, we narrowed the problem down to a 3rd party vendor product that had run over the weekend where the 3rd shift operator had Changed a run time parameter from what was documented. We looked in the manual to find out What the changed parameter was supposed to do. It Wasn't Documented. So, we got the Vendor Rep on the phone. He found the Programmer because their Internal docs didn't cover it either. One of the Questions that came up was "How Much data can this product handle?"

      The answer that came back was:

      "It shouldn't be a problem, we tested it with Huge Files."

      "How Huge?"

      "3 Million entries"

      "We have 30 Million and Growing."

      A moment of silence. "Oh."

      We finally came up with the answer but we never Did get the Revised User Manual they promised us.

  16. Me19713

    In the old days (70's in my case), IBM ran a really good educational system on a regional basis for all things mainframe. In some courses (thinking Basic Assembly Language for starters) there was a serious reading assignment and an exam on the first day - fail and they would send you home. There were even specialized schools for specific industry segments such as Financial.

    If IBM wants to keep their Z-series relevant, they need to bring those courses back (with some updates, of course -- we learned SNA, not IP in those days!).

    john

    1. Philip Lewis

      Put BAL on your CV and put it out there ... you might be surprised how many calls you get!

      1. John Smith 19 Gold badge
        Unhappy

        @Philip Lewis

        I remember seeing one of the "Shaums Outline Series" on "IBM Assembler Language Programming".

        Presumed it meant IBM PC programming.

        Actually was 360/370 BAL.

        I suspect it's a topic with few 3rd party textbooks.

        1. Bakana

          Re: @Philip Lewis

          "I suspect it's a topic with few 3rd party textbooks."

          Older programmers who Still Have some of those older textbooks and manuals can often sell them for more than they cost New, thanks to Inflation and the "out of Print" nature of the subject matter.

    2. DB2DBA

      System z training

      Interestingly, IBM is no longer in the business of directly providing training. If you go to their training and education website you'll find the courses are offered through several vendors, but not IBM. They have a university initiative which provides prepared curriculum and system access to enable schools to offer courses is assembler, COBOL, DB2 and the like. I suspect that the results are mixed as I'm seeing some of these programs being shuttered. SHARE has its own zGen inititive. In a recent web conference the 20 somethings had some interesting insights. All mentioned that they thought a college education was not necessary to the job of sysadmin (sysprog) and as I recall at least one and maybe more stated that they prefered working with the green screen rather than a GUI, in part for the arcane nature of it, but also its efficiency.

  17. roselan
    Trollface

    upgrade to XP already!

  18. earl grey

    capture and record their knowledge

    (1) not that easy

    (2) as soon as some mucky-muck thinks they have it, i'll be booted and some minioni off-shore will get my job at a tithe.

    (3) you're not going to distill 40 years experience into a training manual for some newbie. I've probably forgotten more than most will ever learn

    PL/1, Cobol, Unisys assembler, Mapper 4GL ECL, JCL - - - don't do any of that stuff any more

  19. Anonymous Coward
    Anonymous Coward

    Of course the banks will be happy to pay £millions because 'you have to pay market price for talented people'.

    In any event it doesn't matter. Crypto currencies are delivering distributed, decentralised and fair investment banking to the masses that will enable Joe Bloggs to compete with the likes of these City Spivs.

  20. noominy.noom

    I had to check the date on this story. I've read it at least five times since the late 1990s. I'm not a betting man but I would be willing to bet a figurative (or according to fandom above literal) dollar/pound/euro that in ten years I will have read the same story two more times.

  21. Rottenham

    "Sixty six per cent fear that the impending retirement of the mainframe workforce after 30 years in the job will hurt their business."

    Once, training one's employees was the norm. Then they decided it was better to replace the employees with someone already trained. Now the dance shifts back to the other foot.

    How can I not smile?

  22. Bakana

    COBOL & GUI.

    Strange as it may seem, there is already at several dialects of COBOL that do handle GUI type code. they are mostly marketed by small firms trying to pick off some of the low hanging fruit on Windows & Linux systems.

    They recognize that COBOL succeeded remarkably well in one of Grace Hopper's most important design criteria: COBOL code is Very Easy to read and understand and has one of the shortest learning periods of any computer language for native English speakers.

    That's a large part of WHY most Univeersities don't want to teach it any more. Publish or Perish is the biggest culprit in the exile of COBOL from most college curriculum.

    A) It's really tough to find anything "New & startling" to say about something that has been around ro 40 years.

    B) If you DO manage to come up with something to say, it's really easy for people to spot any inadvertant errors in your source code examples. If your paper is composed around the C family of languages, OTOH, you can Bluff and insist that "it Works Fine on MY Compiler & My Computer so the problem is all in Your OS."

    This becomes a serious problem for those corporations who DO attempt to get people trained in COBOL. The company I was at a few years back wanted several of their new hires (Recent Graduates) trained in COBOL. They approached the local University to set up a couple courses. The University demanded a Fee from the company equal to twice the normal tuition for a course at that University before they would offer the course and refused to Add the course as an option for their current IT Undergraduates even though the company projected that they would be in need of at least a Dozen new graduates with COBOL skills every semester for the forseeable future.

    This was one of the Megabanks that has critical systems running a COBOL system that would cost $100s or Millions of dollars to replace.

    The Bank Knows the problem.

    They've already been severly burned by consulting firms that promised to "Rebuild" their systems in a "Modern" language and failed in spectacular fashion after spending enough Millions to make those failures "Career Ending" for the executives and managers who "Sold" the projects to upper management.

  23. Herby

    Risks??

    The problem with risk managers is that they only quantify one risk: The risk of doing something (in this case rewriting old programs). They never seem to want to quantify the less obvious thing, the risk of NOT doing something (in this case letting the older programs survive on tribal knowledge).

    Some one needs a clue-by-four.

    1. Bakana

      Re: Risks??

      "the risk of NOT doing something"

      I actually Met Grace Hopper a couple times.

      That was one of the things she maintained should be in the Top 3 Questions you Must ask about Every Project proposal.

  24. Herby

    Suggestion:

    Have the GCC people include a Cobol compiler (as a standard part). At the present time it seems to be just hype (close, but no cigar!).

    Look, it could help!

    1. jake Silver badge

      @Herby (was: Re: Suggestion:)

      Yes. See GNU Cobol. It's been functional for five or six years now.

  25. Bakana

    Root Problem

    The root of the problem is the fact that too many of the Managers in these megacorporations came out of the MBA Programs at place like Harvard & Yale where they got taught that the only thing that mattered is Next Quarter and that Long Term (Ie, 10 Years) planning was unnecessary because lots of great "Quarterly Success" would somehow Magically guarantee Long Term success.

    Oh, and besides, if you Job Hop every year, you can get Bigger Raises and Faster Promotions so it doesn't matter what sort of financial or technical damage you leave in your wake because you won't be there when the waste matter hits the rotary impeller anyway.

    1. Mr. Chuck
      FAIL

      Re: Root Problem

      Don't get me started on MBA's. I first encountered one of these horrid things in the mid 80's and nothing I've seen or heard by these clowns since has led me to change my initial, extremely unfavourable impression.

      A degree in Empty Suit? Yes please!

    2. John Smith 19 Gold badge
      Unhappy

      @Bakana

      "where they got taught that the only thing that mattered is Next Quarter and that Long Term (Ie, 10 Years) planning was unnecessary because lots of great "Quarterly Success" would somehow Magically guarantee Long Term success."

      One of the base rules of "Operations Research" was that optimized sub systems do not naturally lead to a system that is optimized overall.

      I guess they don't teach much OR on MBA's.

  26. Denarius
    Meh

    Object COBOL ?

    Rings a bell. Making anything clunky, slow, and resource hungry with objects was a fad not long ago. Fujitsu put out Visual COBOL. Believe it is abandonware now. Pity, it looked like mainframe code so much, otherwise not bad. Might have had a use for retraining Delphi/Visual anything programmers to keep bank systems going. For those of a FOSS bent, OpenCobol is still going. Could the bankers in search of cheaper hardware wind up porting to OpenCobol on linux clusters in a decade or so? The irony

  27. Mr. Chuck

    I don't think so...

    Document and hand over your job so some snot-nose .net dev or code-wallah from India can do it for less?? And, most likely, badly??

    Stuff em. I hope the mainframe admins have the sense to make the banks squirm on the hook. You want advanced systems cared for and fed, you pay for it.

  28. John Smith 19 Gold badge
    Unhappy

    My favorite legacy system

    Univac assembler program --> IBM360 Univac emulator -->IBM 370 in emulation mode -->3090 mainframe hardware.

    Back in the Y2K days.

    Of course by now the bank must have scrapped it now.

    Right?

    1. Anonymous Coward
      Anonymous Coward

      Re: My favorite legacy system

      ClearStream?

  29. FunkyEric

    It's all risk based

    Once the risk of the current system failing catastrophic exceeds the risk of catastrophically breaking things by migrating it, then and only then will they do anything about it.

    1. John Smith 19 Gold badge
      Thumb Up

      Re: It's all risk based

      "Once the risk of the current system failing catastrophic exceeds the risk of catastrophically breaking things by migrating it, then and only then will they do anything about it."

      Sadly that works for me.

      Thumbs up for deep management insight.

  30. jake Silver badge

    I've been pointing this out for years.

    IMO, the CIO in the article is off by about two decades, maybe close to four ... Gut feeling is the numpty thinks corporate databases will somehow manage to move to iFads, despite the lack of I/O.

    As a side-note: Is my Brother's Wife the only one who has noticed that Google Maps is dreadfully slow to render on any given query? Desktop PC architecture simply doesn't scale when it comes to massive I/O.

    Want a job until you decide to retire? Learn COBOL and Fortran (and K&R C, if you're young enough to have more than a couple decades before retirement).

    1. Bakana

      Re: I've been pointing this out for years.

      "Desktop PC architecture simply doesn't scale "

      That is part of why IBM, a few years ago, was having a nice financial boom when they discovered that they could migrate Linux systems to Mainframe Iron running Linux images under VM. All those dedicated boxes (As many as 500 Very Expensive servers) could be imaged on the Mainframe and not only run Faster, but the AC Bill alone was $100,000 / Year cheaper.

      Part of it was that, with Dedicated servers, any "Extra " cycles on an individual box were difficult, if not Impossible, to use. So, if you had a box that was only 65% busy, the other 35% was Idle and wasted.

      On the Mainframe, the OS just handed those cycles to another job and kept on chugging because the Mainframe OS has 40 Years of MultiTaking, Multi Processor experience and has been Optimized up the wazoo to handle Massive processing loads.

      1. jake Silver badge

        @Bakana (was: Re: I've been pointing this out for years.)

        I've been running Slackware S/390 on an LPAR or three for nearly a decade.

        See: http://forums.theregister.co.uk/forum/containing/551527

  31. Johnny C

    Mainframe systems people shortage ???

    I worked on DOS, then VS1, then MFT, then MVS, and lateley z/OS platforms. Totally scalable, very fast and very secure. Never hacked and never went down. Only down time was when we upgraded to a new model CPU. Even moving all data on dasd was done while system(s) kept running at full speed using TDMF or PPRC...etc. I had over 40 years in a single company thru buyouts and name iterations, going public, then back private and then some new tech managers got hired and 'my position was being eliminated', whatever that means. A measly 6 weeks severance and out the door. Amazing that I can not find another position in the Tampa, FL area that pays decently. I keep reading these news flashes that CIO's are worried about the retiring boomers that grew up supporting the IBM mainframes, are now retiring in droves and there might be a system support shortage. I think the issue is no company seems to want to pay what the position is worth, with 20, 30 or 40 years experience. I continue looking but I find it unreal that the technology sites show a job offer looking for many years experience with almost every mainframe acronym there is, for 40k or 50k per year.

    Still looking !!!

    1. Bakana

      Re: Mainframe systems people shortage ???

      "I find it unreal that the technology sites show a job offer looking for many years experience with almost every mainframe acronym there is, for 40k or 50k per year."

      Hey, that's a great rate if you happened to live in Mumbai.

      Thank Congress for the H1-B Visa.

  32. tony2heads

    “'Poor performance' is now being viewed as a defect,” Richards reckoned.

    What ! from a banker!

    I am astounded.

  33. Derek Britton (Micro Focus)

    Application Value is Key

    Many banks’ mainframe systems run on applications that hold business logic captured in millions of lines of COBOL code. Irrespective of IT strategy, what most of those systems have in common is a heritage of providing immeasurable business value. Those systems and applications, in one sense, are the business.

    While those who know how to code in COBOL are becoming far fewer and, as the article mentions, are already reaching retirement age, this doesn't equate to a skills gap. Recent incarnations of tooling for mainframe COBOL systems provide a much richer and more unified environment enabling a far broader pool of developers to tackle core system tasks. Using Eclipse or Visual Studio IDEs, COBOL application development, even for mainframe systems, can be streamlined to be as rapid and responsive as today’s organizations need.

    It’s also great news that big companies are training Java and .NET graduates to build the next generation of developers, yet this education should start earlier. A recent Micro Focus survey found that a huge 73% of academics running IT courses at universities around the globe do not include COBOL programming as part of their curriculum. The industry as a whole needs to consider the continued demand for skills for the systems that continue to run organizations. A growing number in academia are recognizing this and putting COBOL back on the syllabus, but others need to follow suit.

    Tackling broader concerns around IT complexity, slow delivery cycles and new architectural strategies need also to be addressed simultaneously, as issues surrounding perceived inflexibility, constraints on delivery speed and return all conspire to negatively impact the reputation of mainframe systems. Technology that de-mystifies complexity and accelerates the delivery cycle alleviates a number of concerns and will help salvage the reputation of those systems within the business.

    Derek Britton (Micro Focus)

This topic is closed for new posts.

Other stories you might like