Slashdot Mirror
Mainframe Operators Needed
blueforce writes "Computer World is reporting that there's a shortage of skilled mainframe workers on the horizon. Quote: "Getting IT professionals, especially young ones, interested in learning mainframe work isn't easy." No kidding. While I've never worked on a mainframe, I have worked on AS/400's. 3 words - Mind Numb ing. Perhaps it's time for a more long-term solution to the problem. Interesting nonetheless. Who'da thunk it - a shortage in IT. What's next, COBOL?"
I don't entirely understand why mainframe work should be much more mind-numbing than point-and-click or shell-hopping. Would somebody with AS/400 experience explain what makes administration of the machines completely non-automatable, and thus requiring massive amounts of repetitive input?
--Dan
The problem is that no one teaches mainframe operations in schools, you basically need to learn by being dropped into it - and not screwing up everything. Fewer and fewer businesses are willing to invest in promising new talent to learn these legacy systems, but their own mainframe gurus are retiring or dying off - so eventually this corporations will 'bleed out' skill-wise.
And no, the mainframe cannot be replaced by a client-server solution. I listened to this moron chant throughout school - mainframes are not dead. REALITY CHECK - there are just some applications where a mainframe makes more sense. Mainframes can handle enormous amounts of data without having to break it up for a cluster, or without being bogged down with I/O like most client-server type solutions. Mainframes are great when you need to handle databases with tons of information in it - and you need to consistantly dig through it. Most machines cannot handle it, and will buckle. Mainframes almost never buckle, unless you are testing new stuff on them (naughty newbie - that's what a test LPAR is for) or you do funky things to them.
I wouldn't want to learn how to operate mainframes even if it were available. After all I choose CS because I love playing with interesting technology, not maintaining some 50 year old stuff thats going to be switched off sometime anyway.
And even if there's a shortage - I don't care. If I were after the money I'd got a business degree.
That's only part of the issue. I didn't learn squat about sysadmin tasks in University, because the focus is on teaching you how to think about software development, not how to use a particular tool or platform -- that's what tech schools are for.
A far bigger issue, as was already pointed out, is the mind-numbing tedium of being a mainframe operator. Alas, the same applies to being an operator on any system, as your main job is to swap media for backups, stock the print servers, and act as remote fingers when support staff call in on a page.
Regardless of platform, the only operators I knew who were happy with the job were middle-aged people who were more concerned about job stability than job challenge/fullfillment. Many of them were highly skilled, knew more about the systems than the developers, and would have made good developers. They just didn't want the pressure and insecurity that comes outside the data center.
As to "learning VB and Office", it sounds more like a tech school than a university. I've never heard of VB or Office being considered part of the programming course on a university campus. I have seen it offered as a half-credit course to help out students who have no prior experience with basic office automation tools, but who need the basics in order to be able to prepare and submit their coursework.
Another issue with getting people to consider a career as an operator is that the job stability is a smokescreen. Who wants to take a job for lower pay, that has little or no challenge to it, requires dealing with pissed-off user managers, and is subject to termination whenever someone gets a brain-fart about "saving" by outsourcing?
I do not fail; I succeed at finding out what does not work.
Why do you consider it mindnumbing? I'm 27, and I've been working with AS/400s for about 4 years. They aren't anymore mindnumbing than running an *nix CLI, or point and clicking all day. On a side note, the AS/400 is quite the machine. I could sit and name all the great things it can do that are better and faster than any Intel system, but it'll still be labeled "mindnumbing" because it doesn't play solitaire.
I went to college for this?...
When the Mac first came out, I spent about six months reading technical manuals for IBM's OS370. I wanted to actually work with mainframes, but the people that ran the shops acted like it was some holy grail or something, as though you had no chance of setting FOOT in a data center unless you knew a super-secret magic chant or something. I still think the big iron is fascinating, but I've never been quite motivated to resume my interest (the salaries don't really help, either).
As for C++ programmers - someone made a comment regarding competition among "qualified" c++ programmers. I'd argue that the ability to toss some code into a class so that it compiles with a C++ compiler does NOT a C++ programmer make. If you count only those who know both the language, and how to use it effectively, I'd guess that your competition goes way down.
Disregard anything Computer World has to say. The problem in this industry isn't the fact that there isn't any skill around. I'm sure there are young bucks out there that would love to wrap their heads around a mainframe system even if just for the experience; including myself. The problem is that most human resources departments don't know what the hell they are looking for and/or don't have qualified staff to hire for such positions. The people who get their hands dirty and the skill on the "big machines" are usually apprentices of sorts. People who learn and make their living in the academic community or scientific community. They tend to stay in these communities and never leave; ie, they take care of their own. On the business side of thing there needs to be inroads made in the human resource depts everywhere, even if it means hiring someone technical with a business degree or something of the sort. Or maybe training a technical liason for the purposes of hiring and deeming what actually makes sense because looking in the want ads is like reading the comics.
As for someone highly qualified looking through the want ad's nowadays really allows me to see which companies not to bother with and which to send my resume off to. The shortage has nothing to do with lack of skill.
Well, I've got a batch process that is about to go into our production realm next week that processes 4 million customer accounts every night. Close enough?
You just have to understand the performance aspects of the various J2EE components. You probably wouldn't want to implement a huge batch process using entity beans with container managed persistance if you could do the same with stateless session beans. You probably wouldn't want to use a remote interface if your process is running on the same server and can use a local interface, etc...
J2EE is still fairly young but they've added tons of performance sensitive features to the spec. Also, every server vendor has included their own optimizations to get around the most common performance hurdles. It's a rapidly maturing technology.
But, I can't get a job doing this. I can't find anywhere to provide training. I can't get a job, because everyone wants 3 years experience in everything under the sun.
Can someone tell me where I can get training and experience when no one is teaching mainframes and no one is hiring unless one has 2-3 years experience?
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
- Run some java apps on it
... there is a full blown Java2 1.4 VM available (what better platform to run a Java VM on but one that implements the concept of VM at it's core) - Run Linux apps -- Suse, Redhat, & TurboLinux (I think) distros available to run in a logical partition
- Run Apache2 web servers
- Run AIX apps on it
This ain't your father's AS400btw: Did you know that when IBM changed the CPU on the AS400 from a 48bit CISC system to a 64bit RISC system (PPC based) there was almost zero application programming changes required
mm
Indeed. Just for fun, we have a test machine that sits outside our firewalls. It is HIGHLY amusing to look at the logs. Of course you can filter out the automated attacks, script kiddies, etc....but occasionally you get the cracker types attempting to figure out what the hell they've stumbled on. We run very weak passwords on it (this box is mostly just for fun, and we could care less if it did get rooted), and still most people can't figure out how to get a remote prompt since we use only VT-MGR protocol and not telnet. Makes for a few laughs anyway.
Geek used to be a four letter word. Now it's a six-figure one.
If anyone's really interested in learning about modern mainframes, I run a general interest site about mainframes. You're very welcome to visit: http://www.sysprog.net .
.
And for anyone who complains that all mainframers are boring old greybeards (not me), try http://www.sysprog.net/quotes.html
To clear up some serious confusion, mainframes are the very large business systems IBM , Hitachi and Fujitsu make. IBM calls its mainframes the zSeries (z800 for Linux and z900 for z/OS). The AS400 is a midsize computer, not a mainframe. A mainframe is to a PC as a race car is to a bicycle. Anyone still need to ask why some of us love working on them?
Please don't be put off by people who think that mainframe programmers all work in COBOL on green screens in CAPITALS. That hasn't been true for decades. I program in C and Java and use XML and so on. The difference is that mainframes are much more complicated systems than workstations. Call it a challenge, if you like.
Celia Redmore
First, read this so you know my background.
I moved into computer operations management primarily to maintain control of my environment and earn a measly $1.00 more an hour to start. I had been under supervisors who made bad technical decisions in my judgement, and did not like the experience.
The job was hell on earth, and largely due to the nature of people who choose to do that job. This poster got it right, it's basically a haven for people who have the intelligence to do the job and the desire to hide out from a 'normal' job. We are not talking your team players here.
The 24x7 shifts mean job security, yeah, but also the constant wear and tear on nights and weekends meant anti-social behavior is reinforced amongst people who are self-selecting for it anyway.
The fact that I was one of them did not help as I wanted to be as lazy and non-team oriented as the rest of them but could not due to my position. I did not start out as a good leader type to begin with, and had to painfully learn the craft of training and stick and carrot with many ugly lessons learned the hard way.
One of the biggest problems we had was that we could not seriously threaten termination for anything but the most grevious of errors due to the lack of suitable replacements. The systems we run HAVE to run successfully 24x7, no exceptions period. So you cannot just plug in any dweeb with six months of VB/networking at the local community college. So training means standing over them to make sure the processes get done without failure, and takes overtime and care to make sure the mission critical stuff isn't destroyed.
Getting rational reasonable operators who were good and not insane was a difficult thing to accomplish. I literally had situations where bowling alley managers interviewed for me, and later I had to ask myself if I wouldn't have been better off hiring them instead of the jerk we got.
I am even now having to deal with the operator conundrum as a sysprog as some new guy screwed up our monthly database reorg apparently because he thinks he is a genius and understood his instructions without asking or calling.
The solution for our company re: replacement has been to outsource for new operators, try them out to see if they actually know what they are doing, and hire them if they work out.
There IS an operator advancement process at our company- select operators have made it into my systems area and others become Operations Analysts, doing similar work but more on an operationalized basis rather then systems. The Ops analysts are sharp sharp people and just as good as many of the sysprogs. So those posters who are concerned about ops being dead end should make sure there is a similar path before hiring on.
The whole experience was probably good for me as a human being as I am more likely to be sympathetic and understanding of both sides of the management and employee experience. But I am very very soured on ever BEING in ops management ever again and I would have to be very very hungry to ever consider it.
Most ex-ops people I work with feel the same way- it's kind of like helpdesking, it's a job and someone has to do it, but we aren't planning on doing it. And that is your opportunity to grab a job.
________________________________________ History Must Not Fall Into The Wrong Hands ___________________________________