Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Businesses IT

Retired Mainframe Pros Lured Back Into Workforce 223

Posted by ScuttleMonkey from the come-back-so-we-can-fire-you-again dept.
itwbennett writes "Businesses that cut experienced mainframe administrators in an effort to cut costs inadvertently created a skills shortage that is coming back to bite them. Chris O'Malley, CA's mainframe business executive VP, says that mainframe workers were let go because 'it had no immediate effect and the organizations didn't expect to keep mainframes around.' But businesses have kept mainframes around and now they are struggling to find engineers. Prycroft Six managing director Greg Price, a mainframe veteran of some 45 years, put it this way: 'Mainframes are expensive, ergo businesses want to go to cheaper platforms, but [those platforms] have a lot of packaged overheads. If you do a total cost of ownership, the mainframe comes out cheaper, but since the costs of a mainframe are immediately obvious, it is hard to get it past the bean-counters of an organization.'"
This discussion has been archived. No new comments can be posted.

Retired Mainframe Pros Lured Back Into Workforce More

Retired Mainframe Pros Lured Back Into Workforce

Comments Filter:

  • Not a new phenomenon (Score:5, Interesting)

    by ls671 ( 1122017 ) * on Friday July 10, 2009 @05:22PM (#28655587) Homepage

    As early as 2002, I started to half-jokingly tell young co-workers that were asking that they should learn COBOL as a way to insure them a prosperous career. ;-) Back then, most schools were removing or had removed COBOL programming from their course list.

    I was half-jokingly telling them that by 2015 they should be earning 150-200K a year as a simple COBOL developer ;-)))

    See this article from last year saying basically the same thing :

    http://www.computerweekly.com/Articles/2008/08/07/231774/cobol-programmer-shortage-starts-to-bite.htm [computerweekly.com]

    Note: I am to old to start to learn COBOL, this is stuff for young people... ;-)

    • Being a maintenance programmer sucks. Designing is fun, and modern languages are far less tedious than their ancestors.

      But bloody hell, if I can make six figures writing cobol, I'll grab myself a cobol book and quit this programming job. A sucky day job isn't so bad when it means you can retire a decade earlier than otherwise.

      • Re:Not a new phenomenon (Score:5, Funny)

        by mcrbids ( 148650 ) on Friday July 10, 2009 @06:00PM (#28655913) Journal

        But bloody hell, if I can make six figures writing cobol, I'll grab myself a cobol book and quit this programming job. A sucky day job isn't so bad when it means you can retire a decade earlier than otherwise.

        My advice for new programmers has been exactly this: learn COBOL, study mainframes, move to large cities, make big bucks. Sure, you'll want to gouge your eyes out with a fork, but then you'll be able to afford to have robotic eyes grafted back in!

        As a second, I recommend that they learn Unix skills, c, and databases. Still lots of money there, and your original eyeballs will last longer. (It's the path I chose, and I do quite well for myself)

      • be prepared (Score:3, Interesting)

        by reiisi ( 1211052 )

        You not only have to know the application field pretty well (or have the bent to intuit it), but you will have to get used to living without local variables and to a one-call-deep call stack.

        Don't ignore the naming conventions. It's what they do to work around the lack of re-entrance.

        And never, never, never try anything fancy. If you can't keep the state machine in your head, trying to debug it interactively will eat your lunch and your breakfast, dinner, and midnight snacks, as well.

    • Oblig. Ref. (Score:4, Funny)

      by dugrrr ( 582161 ) on Friday July 10, 2009 @05:58PM (#28655907)
      from BSG: "Any return to COBOL will exact a price paid in blood."

    • Obligatory Followup (Score:2, Funny)

      by Anonymous Coward
      There was a programmer back in the 1990's that didn't want to mess with the whole Y2K issue. So he cryogenically had himself frozen, hoping that some day (after Y2K) he would be revived and live out his days peacefully.

      Some years later, sure enough he wakes up. Asking the nearest person what year it is, they reply, "It's the year 9999 and we need a COBOL programmer to help with this Y10K problem!"

      Yeah, it's an old joke. Now GOML!

    • Sounds familiar. In 1997 I took a course in system administration, and one of the other students there told me a similar anecdote:
      If you believe that guy, a few years ago, DEC had fired a bunch of experienced big iron programmers (albeit with nice severance packages). Later they found that their newly hired developers were good on PCs but had not much knowledge about mainframes. DEC ended up hiring the old guys back as consultants ;-)

    • Re:Not a new phenomenon (Score:4, Informative)

      by Greyfox ( 87712 ) on Friday July 10, 2009 @07:04PM (#28656371) Homepage Journal
      I was subjected to 3 semesters of that crap in college, which caused me to set my price for doing COBOL programming to $300/Hour (USD). It's an awful language which you write using awful tools in an awful operating system.

      I rather like mainframes in general though. Hell I can at least tolerate Fortran if it comes down to it. COBOL... not so much.

  • If you'll excuse the shameless self promotion, this book teaches UNIX security people how to use Mainframes: http://www.amazon.com/Mainframe-Basics-Security-Professionals-Getting/dp/0131738569/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1202746607&sr=8-1 [amazon.com]

  • Cobol vs. Data Entry (Score:4, Insightful)

    by c0d3r ( 156687 ) on Friday July 10, 2009 @05:47PM (#28655809) Homepage Journal

    I learned and taught cobol for awhile, and i can say that cobol is not too far from data entry. It is way too much work to do simple things, and it is way too weak of a language for most things. Its functionality is low that it takes a lot of code to implement simple things. The compiler gives you weird error messages. The language is archane. It is a very miserable language to write in, and I wouldn't code in it for less than several hundreds of dollars per hour, just because its so boring and takes way too much typing to do simple things that would be a snap in other languages.

    • it's no worse than C and many people use that every day. COBOL runs many many bank's accounting systems and has been doing it for decades, so it must have something going for it. i think the summary is right - people are crazy not to get into this field, mainframes are here to stay inspite of what many people think is a dead technology. in many cases ONLY a mainframe can do the work.

      • Re:Cobol vs. Data Entry (Score:5, Informative)

        by Qzukk ( 229616 ) on Friday July 10, 2009 @06:15PM (#28656015) Journal

        no worse than C

        Except for C having "+" "-" and "=" instead of "MULTIPLY units AND cost GIVING total"

        If Perl is the archetypal "write only" language, COBOL is the one true "read only" language.

        people are crazy not to get into this field

        The whole point of TFA was that entry level jobs where people could "get in" went away, then all the senior staff retired or expired, leaving the companies with nothing.

        • Re: (Score:3, Interesting)

          by mikael_j ( 106439 )

          The whole point of TFA was that entry level jobs where people could "get in" went away, then all the senior staff retired or expired, leaving the companies with nothing.

          I'd have to say that this is by no means unique for mainframe developers/admins, here in Sweden it seemed like no one was hiring entry-level coders or admins between 2002 and 2008 or so (it seems to have picked up now as companies realise that entry-level coders and admins can be paid less than some guy with 10+ years experience).

          Of course, if you looked in the job ads you could easily have been fooled into thinking there were plenty of entry-level jobs, until you read the requirements for just about every

        • Re: (Score:2)

          by McSnarf ( 676600 ) *

          COBOL has COMPUTE (which will give you +, -, * and /.)

          But STRING and UNSTRING in C?

      • Are you sure CoBOL is no worse than C?

        Or are you comparing apple fritters and ham sandwiches?

        I have seen C written the way people write good CoBOL.

        I have never seen CoBOL written like good C, and I know why.

        Has something to do with something called reentrancy.

    • Might I add one point, since this about programming on mainframes. Ken Thompson once said:

      "Using TSO is like kicking a dead whale along the beach!"

      Actually, TFA was about sysadmins, and not programmers.

    • Re:Cobol vs. Data Entry (Score:5, Interesting)

      by JPLemme ( 106723 ) on Friday July 10, 2009 @06:01PM (#28655931)
      And don't forget that in COBOL, not only is all of your data global to your program, in a typical batch cycle all of the data is global to ALL of the programs.

      I used to hate discovering that field XYZ was being modified in jobs that were completely unrelated to XYZ, because the programmer was too lazy to check the appropriate code out of the repository. "Why bother? I can make the change right here and it'll work just fine!"

      My favorite line was "Being on a COBOL dev team is like living in a dorm."

      • Re: (Score:2)

        by Lennie ( 16154 )

        Mainframes have 3 levels of virtualization, why do you run all these programs in the same memory space ?

        • "Because it works on my end, gotta be a problem on yours"

          Never heard that?

        • Yeah, I know it's an over-simplification, but do remember that your virtualization is one of the tools CoBOL programers use to get around its non-reentrant nature.

        • Re:Cobol vs. Data Entry (Score:4, Interesting)

          by JPLemme ( 106723 ) on Friday July 10, 2009 @09:17PM (#28657137)
          They weren't all running in one memory space -- they were all running on one common set of files. For example, you might have a system that accepts 15 files from various other systems, processes those files against a set of master VSAM files and/or against a database, and then creates a set of 15 files that get sent out to other systems. The system itself consists of a series of JCL jobs. Each job consists of multiple COBOL programs and utilities. It's just like bash, except in a way that's nothing at all like bash....

          But because any program which opens a file can change any data contained in the file, it's tempting to make tweaks wherever it's handy. Nobody claims it's good practice, but these systems have been under constant tweaking for 30 or 40 years by dozens of programmers. After the first decade nobody even knows what the programs were supposed to do in the first place. (Especially since they have names like AB1243A, where 3 of the 7 characters identify the application, leaving only 4 characters to describe what the program does.)

          So the typical bug-hunt consists of noticing that a field has the wrong value, and then checking each individual intermediate file from start to finish to see which job changed it. And if you're on a system that doesn't save its intermediate files it means running all the jobs one step at a time to see where the field gets modified. And THEN you have to open the program and find out what it's doing and why.

          It's not all that different from any other system that has data which is shared between various components, but somehow solving the problem using TSO makes it all seem so primitive.

          (XEDIT is one of the best text editors I've ever used, though.)

      • heh.

        Good analogy.

    • It is a very miserable language to write in, and I wouldn't code in it for less than several hundreds of dollars per hour, just because its so boring and takes way too much typing to do simple things that would be a snap in other languages.

      Couldn't you write in a more concise language, and have a simple compiler generate the equivalent COBOL code?

      Even if it couldn't reverse-translate existing COBOL code, it could make your life a lot easier for newly written code.

      • While my solution to not liking the language other people are using is to write a new ABI-compatible compiler, I'm told that most of industry frowns upon each developer in a team using his or her own language.

        • Standard CoBOL is not reentrant.

          Those coding standards are equivalent to having management do a full optimization pass on the pseudo-code and completely unrolling every call that goes more than one level deep.

        • Re: (Score:2)

          by kybred ( 795293 )

          I'm told that most of industry frowns upon each developer in a team using his or her own language.

          Been there, done that. I worked on a mini-computer that had only a Fortran IV compiler, but it did have a macro pre-processor that allowed you to write Fortran 99 looking code that would then be converted to Fortran IV for input to the compiler.

          A cow-orker of mine went a couple of steps farther; he used the general purpose macro pre-processor to allow him to write his code in his own language, which was then sent through two passes of the pre-processor, then through the Fortran 99 to IV pre-processor befo

    • I wonder if a sorta COBOL decompiler would be helpful. Something that would interpret COBOL into a modern language with 100% perfection (not neccesarily perfection in looking good but perfection in producing the same program bug for bug) ?? IS this possible?

      • They have those for RPG that translate the code into Java...and keep the original RPG as comments for reference. I'd guess they have those for Cobol too.

        The problem I see is that companies still don't have time to refactor that Java into something useful... so it's just "beginner" level java, copying the code. Also, those languages have little things that are direct data structures and processing modes that were emulations of old hardware and have no equivalent representation in a language like Java without

      • Re: (Score:2)

        by lgw ( 121541 )

        Cross compilers aren't hard, but the code they produce isn't at all easy to maintain. It's going to be far easier to maintain the COBOL than to maintain Java automatically generated from COBOL (well, right up until you can't buy a COBOL compiler for your platform).

        I've had to support code in one language that was automatically generated from another, and it is really a last resort.

      • Sounds great.

        Except you must realize that you are essentially talking about decompiling a language that is already in many ways at assembly language level.

    • And yet, for all the dissing you and other posters give COBOL - you can't ignore one salient fact: It's powered some pretty high power systems for decades. As the commercial says - "like a rock".

    • Re: (Score:3, Funny)

      by DNS-and-BIND ( 461968 )
      What do you mean? COBOL is such an easy language, it uses natural sentence construction. Why do you need specialized programmers, anyway? It can be easily used by managers to generate reports and suchlike.

      There's this new language on the horizon, though - it "basically" makes programming a snap for non-programmers, and is likely to eliminate the job of programmers entirely except for a few high-level system engineering projects.

      • "There's this new language on the horizon, though - it "basically" makes programming a snap for non-programmers, and is likely to eliminate the job of programmers entirely except for a few high-level system engineering projects."

        What nonsense!

        Anyone that has coded for a living knows that it is not X years experience coding that is the important thing, it is X years experience debugging, eventually getting to the point where you see the likely bugs before they happen and debug 'premeptively'. Most programmer

    • Re: (Score:2)

      by sukotto ( 122876 )

      So why has nobody bootstrapped themselves a bit by writing some libraries or extending/improving the language?
      Or at least written a good editor. It's been around for a long time. Hasn't some bored guru written his own vi/emacs clone for it in the last 40 years?
      Or improved the compiler to make the errors easier to understand?
      Or addressed any of the other complaints I've seen upthread?

      Seriously... Is there something about cobol that makes that effectively impossible?

  • I wonder... (Score:4, Funny)

    by fuzzyfuzzyfungus ( 1223518 ) on Friday July 10, 2009 @05:49PM (#28655827) Journal
    If recruitment would be any easier if the offer included the right to shout "Where is your 'right-sizing' now, bitches?" into the face of the nearest PHB at will, in addition to the fat salary?

    • Re:I wonder... (Score:5, Funny)

      by John Hasler ( 414242 ) on Friday July 10, 2009 @06:09PM (#28655983) Homepage

      "Sam? Sam, this is Frank, CIO back at Engulf and Devour. How is the transition away from the mainframe going? Well, listen. That's what I'm calling about. Yes, yes, I know you're retired, but the cloud isn't working out quite as we'd planned, what with the economy and all, and the kids are having a bit of trouble keeping ol' Betsy going. Yes, I did read that memo you wrote, and it turns out you had some good points. Listen, would you be up for a bit of consulting? Say, $100/hr, 100 hours minimum? Oh. That much? And a car and driver? Well, I'm afraid my budget won't quite stretch that far...No! Please don't hang up! Let me talk to the CEO and get back to you, ok? Please?"

      • While funny, also too true. Kicking someone in the rear in business often has the downside of the kick being returned. Usually harder.

        Interesting article considering how netbooks are taking off. "Users don't need all that power" argument. Pops up every 10 years of so (who ran those ads "The network is the machine"?) Yes, they do have their niche. Just doesn't fit mine.

        • Hey, as soon as I can do something akin to remote hosted agents, I won't need a powerful desktop. I figure we'll get something like that in a decade or two, but until then I have to do a lot of things myself.

  • VAX (Score:3)

    by C_Kode ( 102755 ) on Friday July 10, 2009 @05:57PM (#28655893) Journal

    We were just discussing VAX at work. I personally never got to work on one, but a guy I work with grew up learning on them. He said only guys his age really knew much about VAX and I said he was wrong as several guys I grew up with worked at banks that used them.

    Mainfames are like Cobol, they aren't going away until the systems that use them die.

    • Re: (Score:3, Informative)

      by John Hasler ( 414242 )

      A VAX is not a mainframe.

      • A VAX is a "minicomputer". It may be very large, and have rows of disk racks stretching down the aisle, it may even be large enough to hold another minicomputer inside itself as a console and monitor, and it may even look like an IBM 370 in many ways, but it is still a MINI computer. These things are often used as front ends or I/O processors to full mainframes.

        One big difference is the attitude of the software and machinery and staff. On a mainframe, everything is incredibly expensive and inevitably vit

    • Re: (Score:2)

      by lgw ( 121541 )

      A Vax is a minicomputer. The minicomputers really are dying. None of them are being made now, unless you count IBMs successor to the AS/400 (the iSeries?).

      OTOH, Big Iron still owns the business computing high end, with no real threat yet in sight.

    • VAX may be dead, but VMS is still very much alive. The popular OMX trading system runs on VMS/Itanium. It's the backend of many stock exchanges, including NASDAQ, ASX and HKEx derivatives. The systems seem very reliable with decent performance. (Definitely better than that .NET-based TradElect crap the LSE is now trying to drop like a hot potato.)

  • Run-on sentence FTW (Score:3, Insightful)

    by steveha ( 103154 ) on Friday July 10, 2009 @06:08PM (#28655973) Homepage

    O'Malley said in 2000 there were more people in system programming than there are today despite the workloads having quadrupled which is quite an anomaly.

    This is an actual sentence from the story. I guess reporters don't need to learn how to use clauses, and editors don't edit.

    If E. B. White [bbc.co.uk] were alive today, he'd be spinning in his grave.

    steveha

  • http://www.nypost.com/seven/06282009/news/regionalnews/nyc_hit_by_nerd_job_rob_176570.htm/ [nypost.com]

    NYC HIT BY NERD JOB ROB

    By SUSAN EDELMAN

    June 28, 2009 --

    It's a geek tragedy

    While the city vows to save and create jobs for recession-ravaged New Yorkers,
    one of its biggest contractors is importing techies from India, instead of
    hiring local computer nerds.

    -snip-

    "It was a dream come true," said Sunny Amin, 25, who traveled from his Mumbai
    home to the Big Apple -- his first US visit.

    Amin, who has an engineering degree from

  • Language gender (Score:2, Insightful)

    by oldhack ( 1037484 )

    You know how Cobol is uber verbose? Guess who were programming way back when: female secretaries.

    You see C with its almost autistic terseness? Who are using it? Buncha (male) nerds who can't talk.

    What's my point?

    I'll tell you after my next shot.

    How much Scotch do I need to drink before I become an honorary Scot?

    • Ok, I'm back.

      The point is, highland malt is it. Unless you want that smokey peaty stuff.

    • Your point is reentrancy.

      Reentrancy, and methods of managing complexity -- make a large state machine with a large grammar, or make a bunch of small state machines with small grammars?

      Of course, C does allow you to code like a CoBOL programer.

      The reverse is not true.

      I don't drink, but I'll see if I can't get lost in the implications of applying this to gender concepts while I go take care of some shopping for my wife.

  • The modern mainframe - Who cares about COBOL? (Score:5, Interesting)

    by Ken Hall ( 40554 ) on Friday July 10, 2009 @07:15PM (#28656455)

    I went from UNIX in the late 1970's to mainframe zOS (MVS/OS) to VM and Linux on the mainframe. Anything you can do on an Intel box (or a room full of them), you can do on a mainframe, cheaper and more reliably, once you get past the first big financial hit. I've seen the so-called cost studies that supposedly show the room full of Intel white boxes are cheaper. Once you factor in the "unseen" costs, like the article says, and get past the startup, the mainframe looks VERY good.

    Current mainframes aren't what people remember from the past. They're (physically) small, agile, and well suited to certain workloads (can you do 256 concurrent DMA transfers on an Intel box?). The problem is, the only companies that seem to be able to justify them for new workloads are ones that already have them for legacy work. IBM hasn't shown much interest in the low-end of the market (sell small boxen, then discontinue them, push licensed emulation, then kill it, etc).

    Our biggest problem is finding people who know the technologies. I give classes to our Linux SA's on this, and they're usually surprised at what the current zSeries boxes can do.

    Don't misunderstand, there are plenty of applications where Intel boxes make sense, I work both sides of the fence. I just hate to see mainframes maligned as "obsolete" by people who don't understand what they are now.

  • If I had to pick hardware and software as if my life depended on it - it would be an IBM mainframe with the latest and greatest version of MVS (or whatever the current name of it is) on it.

  • Bad bean counting (Score:4, Interesting)

    by Hoi Polloi ( 522990 ) on Friday July 10, 2009 @08:10PM (#28656779) Journal

    ...If you do a total cost of ownership, the mainframe comes out cheaper, but since the costs of a mainframe are immediately obvious, it is hard to get it past the bean-counters of an organization.

    I've found this to be true of many aspects of IT, not just concerning mainframes. I've watched customers struggle to get decent performance and constantly hit limitations with a certain database product (not Oracle) because it was virtually free and they didn't want to spend the capital cost on an Oracle license. The total man hours spent, time lost, etc on getting their "free" db up to speed vastly exceeded the cost of the Oracle licenses and they still have problems with it.

    • Finding people who know how to properly use oracle is a real bear. Sure, you can hire people with oracle experience, but most of them were the 'corporate DBA' types who don't know how to do anything out side of the script. I can't tell you how many clients I've seen struggling with their oracle installs; either because the system does not perform as promised, or because the 'cluster' needs to be rebooted every time one node crashes in an unexpected manner.

      Now, I'm just the Linux janitor, not a DBA,

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close