Slashdot Mirror
Mainframe Techies Are A Dying Breed
dipfan writes "Great piece in today's Financial Times on the surprising survival of mainframes - but the problem in the US is finding experienced techies to run them: "55 per cent were over 50, compared with fewer than 10 per cent of those with Unix or Windows NT server skills." Cobol programers, still needed for legacy applications, are mostly in their 40s. Help is on the way, though, thanks to IBM's use of Linux, which "freshens the labor pool" according to the article." (See also this earlier post on the mainframe-operator labor pool.)
Agreed, another major problem is that for many mainframe sysadmin type situation, that stuff just isn't taught in school anymore.
Our program mainly focused on C, C++ and assembler, with a smattering of COBOL and RPG. I spent the first few months learning this stuff when I got hired. Where I am now, we've just spent months interviewing people for junior positions and none of them even had THOSE basics.
"I'm not a procrastinator, I'm temporally challenged"
Well, at $14/hr I can hardly blame IT guys for not bothering to learn how to SysAdmin a mainframe!
Jory
Maybe you should look here.
(It's an emulator for the ESA/390, etc.)
Eli
And when they decide to pay those mainframe devs with real money, some of us kids might be a little more interested in learning. I know a few guys with a ton of mainframe experience... they keep getting shuffled between giant companies, with pay cuts every time. Screw that.
There are no trails. There are no trees out here.
Shameless plug: Acucorp, Inc. makes COBOL development/runtime systems that run on pretty much any UNIX-like system, including Linux. We have lots of customers running on Linux from plain old PCs on up to the IBM S/390.
We had a booth at a recent LinuxWorld. Lots of people would walk by, do a double-take, and ask us, "COBOL on Linux?" Yep, believe it!
As others have noted, the biggest hurdle is that there's no good way for an interested geek to learn firsthand about mainframe systems and OSes. While Hercules takes care of the hardware, at least enough for people to run something to learn on, the same isn't true for the operating system. Modern IBM OSes are hideously expensive, for an individual (unless you're Bill the Gates), and there's been some persistent comments that they won't license them on Hercules anyway (although I have no direct knowledge of this, either way).
I've been advocating a hobbyist license for IBM OSes for use by individuals with Hercules for some time now. There's a white paper at http://www.conmicro.cx/ibmhobbyistlic.html. Aside from a few curmudgeons, and aside from the folks at IBM who make the decisions, the reaction I've gotten to this paper has been uniformly positive. I believe that it would help slow the slide, at least.
In the meantime, the interested can get a running copy of the last public-domain version of MVS from the CBT Tape web page, which is a great resource for the mainframe community in general.
Disinfect the GNU General Public Virus!
As far as finding an S/390 to work on, I'll admit it's hard to find the actual iron to bang on, but there's a damn good emulator for it. For learning OpenVMS, you don't have to use an Itanium; you can pick up an old VAX or Alpha for next to nothing off of ebay or the local surpluss place. Hell, if you don't want to get physical hardware, you can always emulate it; won't be fast, but it'll teach you the basics. And VMS-based systems are all over the board as far as their size goes. A single processor Alpha or VAX is very much a micro. A system or cluster with a dozen or so procs is getting into the midrange area, and the really big iron, like the VAX 7000, can ease into the high-end server/mainframe range when using VMS's built in insanely reliable clustering. Yeah, it'll be tough discovering a truly non-trivial project, but hey, that's part of learning.
Marxism is the opiate of dumbasses
Even when they did teach such things, it wasn't called "Mainframe SysAdmin". You mainly went to school for programming. If you wanted to go the "Systems Programmer" route, you usually started out as an operator (mounting tapes for backups, printing, managing queues), then moved your way into systems programming. Every place I ever worked at never referred to any position as "Mainframe sysadmin". The typical mainframe system is just to big/complex. While mainframe ideology has filtered it's way down to smaller machines, I frankly get tired of people thinking you can be a "sysadmin" for a mainframe. Sorry if I come off as a mainframe bigot, but that's where I started. Yes, I'm in my 40s (with a good 25 years more work ahead of me).
Sorry, but you're way off here. Mainframes are much different beasts to what you seem to be thinking of. They're not big PCs. And no, a VAX is not a mainframe, a VAX is a mini.
Feel that power? That's mah MOUSING FINGER
Cbttape.org is the mainframe version of open-source, but without any GPL license nonsense. We share freely or not at all!
Note that the 1978 version of IBM's MVS 3.8 operating system is public domain. This is what's included with Hercules. Source code is also freely available. The difference between MVS 3.8 and today's OS/390 is about the same as the difference between Win95 and WinXP. I.E., Win95 would give you a pretty good understanding of Windows, and WinXP just builds on that.There is a cookbook installation version with a step-by-step guide for neophytes - the MVS 3.8 Turnkey CD - follow the Voelker Bandke link.
Good luck, and when you're in Dinosaur Land - avoid the meat-eaters!You were 80% angel, 10% demon. The rest was hard to explain. - Over The Rhine
"Math in a song is good."-Linford
http://www.conmicro.cx/hercules/
:)
mvs emulator.
JCL... the horror.... the horror
putting the 'B' in LGBTQ+
All completely WRONG. Keep reading airplane magazines.
Distributed systems are 20+ years behind the mainframe in "scalability and reliability (e.g. redundancy, resource pooling, load balancing, etc)".
These are the WEAK POINTS of "distributed systems".
They are just starting the concept of LPARS (logical partitions) on midrange boxes. Something the mainframe been doing for many many years.
Don't even get me started on the inability of "distributed systems" to be secure or be recovered at Disaster Recovery.
One shop I work at, we have 6 different passwords to the various distributed systems they have implemented - everything from SAP/R3 to Peoplesoft.
They also had a study done from the Gartner Group about recovering all their new midrange distributed systems at a Disaster Recovery (this was post 9/11 because their plan prior to 9/11 was don't worry about DR). Gartner estimated that IF their systems could be recovered, it would take a minimum of 21 DAYS. What business will remain in business down a month?
The mainframe, of course, is recovered in less than 18 hours.
But that is the difference between the REAL WORLD and collegiate studies.
Paul
PS Would you rather pull a heavy wagon with a large horse or a hundred chickens?
For the most part most of the things you list are at best peripheral - they are now appearing but are not mainstream.
Learn z/OS (or os370, MVS etc) and or one of the VM family. Study Rexx, JCL and RACF/ACF2 and a few of the common utilities such as IEFBR14, IEHLIST, IEBGENR, IEBPTPCH (there are hundreds more). That lot may get you a junior post, unless a company is running a linux partition on their machine the linux skills will be next to useless. An old fashioned site (most, I suspect) will have no perl, vi, emacs or anything you'd expect on a nix box, and there is no gui, interaction is screen based, probably using ISPF under TSO. Connectivity is probably still using SNA although tcp/ip may be a possibility.
Some of the m/f software I mention may have been superceded, but the new versions build on the old. IBM are, deliberately, rarely revolutionary, evolution is their strong point. They do their best to ensure old programs run on new machines wherever possible.
I hereby inform you that I have NOT been required to provide any decryption keys.
Good Question. The mainframe where I work is the SMALLEST piece of equipment on the machine room floor. The most space is taken up by huge racks of NT servers. The next most by a huge RS6000 complex. The mainframe is dwarfed by comparision. The biggest difference between a mainframe and a midrange box is IO. The mainframe IO is much different from PCI or SCSI that midranges use. On current mainframes, you can move 24 gig into or out of central memory every second (this is doubling in the next generation mainframe - the Z990). Try that on a RS6000.
The mainframe I work on does not run under unix, it runs under a proprietary OS which originally predates unix by at least a decade. The only thing it has in common with unix is that it uses a command-line interface.
NFS, AFS, Apache, X11, sendmail/postfix, ssh/rsh have no counterparts on this mainframe - if we need something like that then we interface to a linux/NT machine.
Samba does have an equivalent, but it looks totally different.
The machine can act as a Telnet server, if you allow that.
The normal connection software is via software that emulates their old terminals, several companies sell different emulators.
Some of your TCP/IP knowledge could be of use, but that is all. You obviously have no idea how the thing works or what it can do (just as I have very little idea of kernel internals, for example) and an employer would see that immediately.
I worked on these beasts for almost 20 years before being confronted with linux. I can write primitive bash and perl scripts, and configure+administer a server. This makes me the only person in the group who can and makes me a 'linux expert' (!), they are that different.
Mielipiteet omiani - Opinions personal, facts suspect.
I consider myself to be a mainframe SysAdmin :-)
I started of programming them in Cobol, Fortran and Assembler and then gravitated to the systems-side of things. I first took over a site back in the late 80's (with around 10 years of experience back then) which tells you my age.
It is a lot of work, keeping on top of developments but it is possible.
Mielipiteet omiani - Opinions personal, facts suspect.
If you've got the free time, say 12-24 weeks or so...
Go buy an IBM Education card (around $3-$5k depending on which one you buy).
Head toward an IBM education center / Training center. (The one in Atlanta is very good).
And learn all you want for one low price. It's how I managed to learn AIX. Took me about 6 weeks to become very intimate with aix administration.
Steven V.
IBM CATE
I patented screwing your mom. But it got revoked for "prior art."
Were you to try to do ANYTHING with a mainframe (I'm thinking s/390 or z/OS here) armed with the knowledge you mentioned you would be so horribly lost it wouldn't even be funny.
Finkployd
Here you go, smart ass (you really should know better than to put an obvious challenge up like that on /.)
l
1 0,00.html (Looks to be s/390 specific articles).
Some Quick Finds from Google:
Your hello world:
http://www.roesler-ac.de/wolfram/hello.htm
And Another with MVS JCL:
http://www2.latech.edu/~acm/helloworld/asm370.htm
And Some Miscellaneous Links for Main frame coding:
http://search390.techtarget.com/home/0,289692,sid
http://www.texasrock.com/ (Nice collection of links)
College is fine and dandy, but that's not the only way to learn something.
You can get a mainframe emualtor (IBM 370 series here http://www.conmicro.cx/hercules/ They also have links to versions of various IBM OS's that you can download. Enjoy!
Fully aware the IBM minis are not mainframes, I'm going to back you up on this. Fresh outta college with my VAX/VMS and Sun experience, I find myself in a System/38 shop.
Oh. My. God.
Absolutely nothing is the same. There is just barely a command line on the '38. The database is practically part of the OS. There is no "shell" as we know it. The programming languages (AFAIK, just COBOL and RPGIII) were as far as you could get from C-ish stuff, lacking anything remotely like printf() or even puts() for output, handling input through a faux-VSAM file interface.
Totally, totally alien. I caught on reasonably quickly, but what a culture shock. I learned an amazing amount in the first few months.
They don't even use freaking ASCII! Barbarians!
IBM minis are a whole different world from the Unix family. I can say with some certainty that going from Unix to Microsoft OSen is much less of a jump than Unix to mainframes or proprietary minis.
Nothing moves data like a mainframe and nothing stays up like a mainframe. They are the most reliable platforms out there. IBM used the phrase "five nines" to describe it--99.999% uptime.
Now they're going to companies that already have a big mainframe investment in physical plant and people and saying, "Look, buy this new bigger box and move all your legacy COBOL apps over onto it. You'll still have enough room left over to run DB2 on it and use it as a database server, AND, set up several hundred instances of Linux and run Apache to run your website." The company gets to keep its old platform until such time as they want to move off it, they get a godawful fast database server, and they get a "Webserver farm" inside one box with far superior reliability to racks and racks of off-the-shelf PCs.
IBM jumping on the Linux bandwagon is really out of character, but it's a smart move.
"Settle down, Beavis. We've got an experiment to do."
IPL = forget what this stands for but it's basically a current instruction pointer or something isn't it?
Initial Program Load. The mainframe guys I've worked with have told me it's basically a reboot.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
MVS = IBM Mainframe OS don't know what it stands for
Multiple Virtual Storage. There's a conceptual overview from the Unix geek viewpoint in ESR's upcoming book, The Art of Unix Programming .
Disinfect the GNU General Public Virus!
The whole point is that it's different, if you can learn new stuff you can handle it - just don't expect it to be the same as anything else because it's not.
I hereby inform you that I have NOT been required to provide any decryption keys.
Real simple. You can run linux on IBM mainframes. They've done an excellent port and made it clear that they're committed to supporting it.
Now you still need a minimum old-school crew to run the actual mainframe stuff, but you can migrate your applications to Linux-in-a-VM instead of using Cobol JCL and all the other arcane mainframe stuff. So you get the best of both worlds - the incredible IO power of the mainframe can be harnessed to linux virtual machines, programmed maintained and administered by guys that don't need to know squat about the mainframe itself.
Places that are already using mainframes can continue to support all their legacy apps, but implement new systems in the linux environment with *nix people to run them. Eventually over the years the old systems are retired and the new ones are *nix, until there isn't really any need for anyone with what we think of as mainframe specific skills, except the service personel at IBM. And new buyers can get a clean start, never needing any real mainframe knowledge in house at all.
Well, presumably someone needs to learn enough to set up new VMs, but that's about it. Mainframes are incredibly resiliant and fault tolerant, you can blow out processors, hard drives and probably whole banks of memory without any interruption in service, even while the techs are installing new parts...
Let's see a mini or microcomputer where you can do that. Show me a mini/microcomputer that can push 20gig/second between memory and storage, and show it to me before the new mainframe comes out too, I understand it will be capable of 40gig/second.
These aren't supercomputers that can be replaced with beowulf clusters. They aren't computational giants at all - you definately can find minicomputers that can beat them in that arena. But there are many tasks where simply being able to do calculations quickly is not important. How many *nix database servers ever max their CPU? Most will run out of IO bandwidth before their CPU sees much load.
Mainframes are simply the pinnacle of reliability and IO power - these things can run huge mission-critical databases like nothing else. And thanks to the Linux porting, those databases can be run by anyone that could do the job on any other linux system, instead of being the sole preserve of dedicated mainframe people that are intimately familiar with dozens of ancient technologies most of us have never heard of.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Using sh as a normal user, /usr/sbin is not in your default path. ping on solaris is installed in /usr/sbin/ping, and depending on the security policies that your sysadmins have in place, may not be runnable by non-root users. /bin. Fix your path to where the actual command is, and it will work.
Solaris still correctly believes that not all tools belong in
Hundreds of comments, and I got to yours before I saw anything that resembled a clue. Thank you for pointing out that IO is what a mainframe is all about, and that there's not really a comparison to the PC world.
-fb Everything not expressly forbidden is now mandatory.
You had to write your own apps, and to do so, you had to know the hardware inside out and how to drive the devices directly.
20 years ago, after bitty-boxing for a big company, I was told that I had 3 months to learn how to program the big IBM mainframe.
So, the first thing I did was to show up in the girl-who-was-in-charge-of-the-big-iron's office and ask her for the hardware reference manuals. I might as well asked her to strip naked and go dance on the boardroom table. Why do you want to know that??? she asked me, blinking in disbelief. It took me three weeks to learn that it was a 16 bit machine.
Those people have no imagination; they have been carefully promoted from the ranks of the typing pool so that they don't represent any kind of threat to upper-management, so it's no wonder that they didn't find any problem with punch cards. Why would one want to have an interactive session with a computer is totally beyond them, and I'm not surprised that they'd think the idea quite subversive.
Heck, 3 years before, when I came to work for that company (in R&D), the coders were working on PAPER forms, which were sent to TYPISTS who PUNCHED CARDS (that was 1980, people!!!) so the program changes could be fed the dinosaur. There was only one guy with a terminal on his desk - we (in the R&D) figured that he must have been an important analyst - he had a TERMINAL!!!
Nope. The guy was the FILE MANAGER. Yup! The guy's job was to manage the files on the computer; in 1980 they still used DOS, which let your programs write directly to the sectors on the disks; he was MANUALLY allocating disk spaces for the files!!! But I disgress. (Fortunately, by the time I was asked to move on the mainframe, they had upgraded to VM and the lowly programmers had their own terminals (imagine the revolution!).
As I said, it was hard to learn anything valuable from those drones; however, what little information I was able to scrap together left me absolutely flabberghasted at the power and the cleverness of the hardware organization of the machine.
Then I also went on to diddle around with CMS, which I found absolutely rocking as a shell. And after three months of being paid diddling around with the big iron, I came one morning to work to find that my HP terminal (through which I accessed the IBM through a gateway) had been replaced by one of those real slick and huge IBM terminals with the huge 18 inch screen and the green phosphor and the clickety-click keyboard (with a solenoid clicker for good measure -and- to let you know that the keyboard repeated).
I was not working on the mainframe, maintaining garbage COBOL programs written 20 years before, or worse, changing ASSEMBLER programs. At least, there were a bit of PL/1 programs to change. It's a good thing that I was in the first of several huge layoffs batches that started to happen soon, because I would have quit anyways...
That experience left me with a bitter sense of total waste of ressources; fantastic hardware given to totally moronic people who should never have had anything more complex than a pencil in their hands.
This story reminded me of my old days as a S370 Assembler programmer at Databank in New Zealand. We had a nightly update banking system in assembler that would process all the deposits, withdrawls, interest, fees etc in 12 minutes from start to finish and contained over 300,000 lines of assembler. One module CF03AG had been hacked so much for so many years that it had run out of base registers for accessability,a dn we had to hack addressability somehow. The system was at one time use by the 4 main trading banks here in New Zealand, ANZ, BNZ, National Bank and Westpac. National Bank decided to leave and used computer system from Systematics in Little Rock. This NEW system was mainly COBOL. From 12 minutes from start to finish their new system took 4-6 hours to do the same job. It was great to learn progamming with Assembler on the mainframe. Today I can pick up any system in any language and can start working in it with pretty much no problems. I did use to have the odd "SOC7" nightmare when I mixed my packed decimals with my ... shit can't remember any more.
BXLE I think was my fav instruction