Slashdot Mirror
Retired Mainframe Pros Lured Back Into Workforce
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.'"
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
Note: I am to old to start to learn COBOL, this is stuff for young people... ;-)
Everything I write is lies, read between the lines.
I speak COBOL, FORTRAN and can do Job Control Language like an old pro, oh wait.
I also program in IBM 360/370 assembler. I'll bet that is almost a lost art.
hoping they hire them back to FUCKING MIGRATE ALREADY!
If Mainframe does not die by itself, we should kill it for the sake of the world.
NO SIG
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
-- Support a free market in the field of government
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.
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?
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.
from BSG: "Any return to COBOL will exact a price paid in blood."
I see VMWare bringing back a lot of the mainframe hardware concepts, such as: - Huge fricken box - Everything in the company runs on it As far as the "legacy" mainframe languages... IBM is still releasing OS updates to it's OS/400. Many business critical applications are still running strong in "legacy" programming languages like RPG. To name one... Bally's (yeah the same as the fitness center company) sells one of the leading CRMs in the Casino industry... running on a green console.
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 were alive today, he'd be spinning in his grave.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
You think the problem is coding, no it's the issue of a totally new harware and software costs. The mainframes may be relatively easy to convert... if only they knew what they did.
Re-engineering any complex system takes investment over a long period of time (documenting all processes and how it is achieved). Then any system can be copied using a experienced software engineer and possibly team of developers / testers.
But as building software seems less reliable than building anything else in the physical world (% of projects that fail), management may still be reluctant to "re-invent the wheel". Even if you say it's quicker and cheaper to redo, there has to be a business case put to the people that make the decisions. All too often workers dont do this and spent all their time working, not putting forward the need for further development.
I would have thought it's human nature to see IT staff and skills as a cost saving (when things were working fine). Then you are always going to get this situation where old IT skills are necessary?
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!
I'd take a 370 assembler job, if they existed! I enjoyed that more than any other language I've worked with. Heck, even with the old OS that ususally accompanies such work - threads? preemptive multitasking? Who needs em!
From memory, IBM's 370 macros came with source and cool code was shared freely between mainframe shops.
http://www.nypost.com/seven/06282009/news/regionalnews/nyc_hit_by_nerd_job_rob_176570.htm/
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 a college in Aurangabad, landed his
first job with IBM-India.
-snip-
Finance spokesman Sam Miller defended the contract.
"Our systems are so old that there are not many companies that have the
ability to work on them. IBM does," he said.
Surprisingly, NY City can't find any American's to work on these COBOL systems, but 25 year olds in India have the experience necessary.
Skip ------ See the latest from http://www.anArchyFortWorth.com
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?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Actually it is a problem that we can't get and keep the boomers retired. We will be the squeezed generation because they will hang on until they die and by then the younger ones will be kicking us out. No generational mindsets can change until people leave the workforce.
-Xen
From experience, just because you migrate from a mainframe doesn't necessarily mean you migrate from COBOL.
In the last mainframe environment I worked in, we ditched the "Big Blue Box" and put everything on an IBM Z-Series server running SCO-Unix.
We just emulated the environment. The OS was the same old junk and COBOL was still a bear to deal with.
We were able to run 4 mainframe "environments" though from this itsy-bitsy (comparably) server though...
Look at the silly, greedy business people trying to rehire retired COBOL coders...teeheehee.
I've experienced cases where packaged commercial products were avoided (although ideal for the purpose) in favor or using "in-house" coders because the former ends up under "capital" on the ledger. The silly, greedy business people figured keeping staff was the better option.
Of course, around /. it's take the pro-worker case for granted, as if every decision that eliminates a position is a silly greed business person mistake...teeheehee
grow up.
Every bank I worked for (and Telco, for that matter) does a reboot of it's Unix and Windows boxen, and a restart of the mainframe regions on Sunday morning. The systems are unavailable for 4-8 hours, depending on the system in question.
Software updates and patches are rolled immediately after that image backup and restart, so that there is an image to roll back to in case of problems.
Unlike your experience, Christmas/Year End is a "freeze" where only emergency patches can be done.
I do not fail; I succeed at finding out what does not work.
Odd by today's standards.
No flow-of-control stack. No local variables.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
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.
Nobody really knows 10+ languages. Some people have a good ability to guess which library functions to call in a certain specific context.
It's kind of like being able to "Hello, where's the facilities?" and read carburetor manuals in ten different languages. You know the field, and you learn enough to do a little handshake conversation with the people.
And, in this case, it's like knowing how to get around in your niche in ten Latin family languages and talking about learning enough, say, Japanese, to go there and try to work as an engineering manager on products for the Japanese market.
Although that example might not hit home if you're the kind of guy who thinks knowing the word "kiai" makes you both a jiujutsu master and a Japanese master.
I have seen C written like good CoBOL. You will not see CoBOL written like good C.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
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.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
How many banks are running on Google's systems?
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
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.)
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.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
heh.
Good analogy.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
FWIW, there have been a lot of attempts to modernize CoBOL, new coding environments, objects, etc.
I don't have enough experience with what they're doing (don't want to have that experience, I guess.) to know what they've done about reentrancy, but I suspect that the whole concept of reentrancy is foreign to the very people who like the grammar and syntax of CoBOL.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
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.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
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.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
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.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
...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.
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
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.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Don't get me wrong. Mainframe hardware is great for big database/large I/O type work. But the reason we tried to get away from hosting things on mainframes was what we referred to as 'the mainframe mindset'. Everything was a batch job, placed into a scheduling queue and done in its own good time. Any attempt to get our IT people to re-engineer the processes met screams and the "you just don't understand" howls reminiscent of leaving the toilet seat up at home. So we (engineering) bought a little Sun server and built our own engineering configuration control system.
We took a data release process that ran once a week (because the mainframe guys said it had to wait its turn behind the budget report jobs) and converted it to a "just in time" process. As a result, we eliminated a bunch of error prone, paper based interim change processes. No longer needed, since there was no longer any need to track changes made between weekly "release points". The factory loved us. The correct data was on line (web-based, which was something the mainframe people didn't 'get'). QA kissed our feet, not having to chase paper changes effective since the last batch run. But the IT guys screamed and pointed out how, if scaled up, the Sun server solution would be more expensive than a mainframe. If everyone went out and bought their own. So management went back to the mainframe. And the weekly batch job.
The new process could have been built on a DB hosted on that mainframe. But we never could pry the old, boney, arthritic hands of our IT department off the system. So whatever ran on the big iron had to run their way. So lets keep the mainframes. But retire the geezers.
Whew! That sure was cathartic.
Have gnu, will travel.
I used them in school in the 80s; know about channels, VMs, CICS, MVS etc... but what makes them a distinct entity? How is an E10K not a mainframe? Is it just EBCDIC and old system software?
If it is just EBCDIC and old system software; shouldn't the article read "even IBM can't figure out how their computers work", at least as a byline?
COBOL is just another language; any poor sod that had their head stuffed into the C++/JAVA/C# grinder should find it a welcome break. A bit like a tricycle rather than an oceanliner, but a vehicle that can actually move.
Thanks Ori!
I read this exact story in '98. Y2K. All those mainframes with COBOL code and nobody to write it because CompSCI majors didn't learn it anymore.
We always seem to muddle through.
Some voices, "what the hell are you doing to that frozen meat popsicle"
"Shutup!, it knows COBOL !" "It's a long dead duck, we dumped it years ago. Put him back in the icebox!"
"You idiot! It knows JCL and Procs and TSO and REXX, even ISPF and OS-390 and VSAM-KSDS..." "What? the old legendary languages? really!"
"What does it do! flap it's fingers on a set of metal keys! put it back! " It's starting to smell... again!...
"No. Wake it up, offer it money, lots of money... they used to like that..."
I can move my lips, croaking "Yeah money... lots of cool green money..." A Jolt, of liquid, my vision clears revealing a shiny new account statement.... full of big big numbers...
"Can you sit up... and while your recovering... read this sysdump for us... Oh and we need this job to finish in 30 minutes, or less. each night..."
"What's a Job listing? why does the paper have green bars? what are all these dead trees in here for?
what are you doing to do with that gun!" Shots and screams.... gurgling to silence.
What a tragic waste, of an accounts payable clerk....
Bring More money... Aaahhhhhh that's better...
Hungry... "Bring me something cold... a dish of revenge, fresh chilled bean counters, iced CFO for dessert, frozen outsauce on the side..."
Pass me that JCL abend listing? and keep the cold stuffed cost cutters coming...
Make em squeal. Client Pays!
No mercy billing, that's our policy mateys!
Take what you can, give nothing back!
Yo Ho Me Hearties!
Submit...
Eventually patch and paste will get you only so far. I dont have an issue with mainframes. I do have an issue with the fact that a lot of modern software, tools apps wont run on a lot of these older systems. They havent kept up so its like you have an old die hard piece of hardware that limits you because the software hasnt kept up.
The specialized hardware is what makes a z/Series machine appealing. If you wanted to run Z/OS for any real purposes, you still need licenses, and good luck talking IBM into selling one without a bundled HW/SW/support contract.
Now, if what you're talking about is a migration strategy in preparation for real iron, I can dig it. I even put together a Live environment to that end.
Sounds interesting; what does it mean?
Mr. Balmer go back to bed, you can count your stock options tomorrow to feel better.
google "32 trillion offshore needs IRS attention"
I know two of them.
Nice enough persons, however just because they can write RPG and queries on a green screen somehow got translated to the title of Director of IT.
Really though, their heads are up their ass when it comes to anything IT.
I say things which affects my Karma negatively. (and I don't care) For instance; All religion is false.
that a six figure salary for a programming job is impressive? here on the west coast, humble SysAdmins command that much after a few years; http://hrsalarycenter.salary.com/salarywizard/layoutscripts/swzl_salaryresults.asp?hdSearchByOption=0&hdSearchByOption=0&hdKeyword=Systems%20Administrator,%20Sr.&hdJobCategory=IT03&hdZipCode=94086&hdStateMetro=&hdGeoLocation=Sunnyvale,%20CA%2094086&hdJobCode=IT10000136&hdJobTitle=Systems%20Administrator,%20Sr.&hdfte=&hdCurrentTab=&hdNarrowDesc=IT%20--%20All
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, but when I see those problems on MySQL or PostgreSQL, I can fix them. I've replaced more than one MSSQL database with a MySQL setup, and often see orders of magnitude speed increases that I suspect are due to misconfiguration of the proprietary database. The open-source stuff is just plain easier to use, at least for Linux janitors like me, and has better support.
I'm sure Oracle and MSSQL are both fine databases if you know how to use it and you configure it correctly; I'm just saying that paying a lot of money doesn't relieve you from needing to know those things. You still need to pay for a technician who actually understands it. The advantage of the free (as in freedom) products is that there are a whole lot more people with real (that is, non-scripted, where you need to do something new or are expected to solve a problem beyond 'reboot and apply the redo logs') experience with the free databases than with multi-million dollar oracle installs, and that sometimes your expensive support people just shrug and say 'I don't know. why don't you upgrade your linux kernel.'
Sticking with the free stuff, using a search engine such as google gets you pretty good support for commonly used free software. Often better support than what you get when you pay lots of money for support.
Agreed, 110%... Back in 1985 & later in 1991, I took COBOL, & thought it was nasty, but, only because I had been exposed to BASIC in highschool & the semester before it with both available for the midranges/mainframes (which is what I had to work on back then) in academia environs. Yes, there is a difference in the degree of difficulty & tedium involved.
Per my subject-line, to perform output, doing PIC(X) stuff was a PAIN & took time to get right positionally (yes, I took COBOL 74 std. first time (on a VAX 1180 system), & later in 1991, I took the COBOL 85 std. (on an IBM AS/400), & it was pretty much the same game - readable, yes, but long & "drawn-out").
Sure, even in today's languages, sometimes, to format output correctly, you need "output masks" for things like strings & such, but it's not nearly the manual hassle COBOL puts on the coder.
Coders today may bitch about "how bad a language is" & all that, in today's HLL's... but, today's programming IDE's with code completion & less work performing I/O (most times) + large amounts of documentation (plus, the internet too) is much less labor involved.
The only language, imo @ least, that is more work (in most ways) is Assembly (which even in MASM, a more 'automated model' of that language imo) because it's probably the MOST "manual" language tool of all but even IT doesn't demand those damned PIC statements.
APK
P.S.=> Disclaimer: I haven't had to use COBOL for 17++ yrs., so, my memory of it may be a bit "dim", but that was my impression of it I was left with, especially by way of comparison to today's programmatic IDE tools, which ARE, far better/superior... apk
I thought we would be seeing a flood of 20 yearld 'consultants' with 30 years experience in COBOL in their resumes, all of it with some software company in India, already.
I'm too lazy to Google it, but if the language is so arcane and simplistic, wouldn't it be worthwhile to write a COBOL code generator so you can write code in something that doesn't suck? I realize that code generators are not always as expressive and/or sometimes don't follow conventions of said generated language, but getting 90% of the job done has to be better than trying to lure some old codgers out of their kid's basement right?
body massage!
not to rant, but I don't see anything "inadvertant" about the shortfall created by specifically firing the most experienced and knowledgable employees of a company/department. Bean-counter-led business models are almost reliably bad business models. /rant