Mainframe Techies Are A Dying Breed 566
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.)
Employers' fault... (Score:5, Insightful)
I think being a mainframe admin would be a blast (maybe I just don't know better), but in my eight years of sysadmin work, I've never touched a mainframe. Every job posting I recall coming across required previous experience.
Re:Employers' fault... (Score:5, Informative)
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.
Re:Employers' fault... (Score:5, Informative)
Re:Employers' fault... (Score:4, Informative)
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.
Re:Employers' fault... (Score:4, Funny)
I'm not quite dead, you insensitive clod :-)
Re:Employers' fault... (Score:4, Insightful)
I was under the (possibly mistaken) impression that most CS schools were harping on C/C++ because if you knew them, you could learn almost any language quickly because >50% of them are based on C, use C syntax, use C++ object constructs, etc...
Re:Employers' fault... (Score:5, Funny)
Oh, not THAT kind of RPG... ;-)
Re:Employers' fault... (Score:5, Interesting)
And even with trying to learn it at home, the production machines cost so much and are usually so business critical, you're going to have to really luck out to find a position where you'll ever even be allowed to touch the thing... On the flip side, I guess once you're in that world your job would be pretty stable, simply by virtue of the same barriers to entry in the field.
Re:Employers' fault... (Score:3, Informative)
Initial Program Load. The mainframe guys I've worked with have told me it's basically a reboot.
Re:Employers' fault... (Score:3, Informative)
Multiple Virtual Storage. There's a conceptual overview from the Unix geek viewpoint in ESR's upcoming book, The Art of Unix Programming [catb.org] .
Or... (Score:4, Interesting)
Yeah, thats it! I'll just buy myself a mainframe and...oh wait.
The problem is that the only way to get mainframe experience today is to have access to one.
Who does?
Still, I think the closest thing we can get is playing with Linux from the ground up. As a Solaris user, I can say that a lot of the internals are the same. Except, of course, that all the non-gnu versions of software suck compared to their Linux equivalents.
In fact, when I think about it, the biggest problem is employer disbelief. Can you admin Mainframes if you can admin Linux boxes? Pretty close:
-You can know NFS,AFS, and Samba
-You can know Apache
-You can know X11
-You can know sendmail/postfix
-You can know telnet/ssh/rsh
-You can know how to install security updates
I could be wrong, but I think the stuff that you don't know beyond this boils down to quirks that are dependent upon the specific mainframe.
Unless, of course, you're talking about those really old mainframes that do less than my computers do (though they're more reliable), and serve only one very, very specific purpose. For those I should think it would be obvious why there aren't more people working on it. It's way too specialized. You want somebody that knows the accounting system for one bank on a VAX that was put there in 1975 and hasn't been changed since? Talk to the guy that wrote it. How will anyone else know?
Re:Or... (Score:3, Funny)
Tell me about it.
Re:Or... (Score:3, Informative)
Re:Or... (Score:4, Informative)
mvs emulator.
JCL... the horror.... the horror
Re:Or... (Score:3, Insightful)
My understanding is that some 20-30 year old predecessor to MVS (or OS/390 or z/OS) is in the public domain, but obtaining more recent versions is very expensive (unless you use a pirated version - anyone know a z/OS warez site?).
And what you will need is more than the OS, there are other utilities that are also licensed by IBM and cost a fortune.
You might be able to learn a bit of JCL and some basic TSO commands on Hercules + an ancient mainframe OS, but you would not b
Re:Or... (Score:5, Informative)
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.
Re:Or... (Score:3, Insightful)
What no vi??! You've got to be joking. I've yet to meet a platform without at least a couple crappy clones. Next you'll tell me regular expressions are not available and you're using a C compiler without ANSI support.
Seriously though, any system not supporting the tools you mention would seem halfway dead already. I'd figure the only thing such an environment would be good for is jumping to something more useful. P
Re:Or... (Score:3, Informative)
Nope, not joking, never even heard rumours of vi on big iron, but you'll probably have xedit, which is a very powerful editor in it's own right. I easily prefer xedit to vi (yuk), it does some things better than emacs too. You're scripting language on any IBM platform is REXX - which is also your editor macro language.
Re:Or... (Score:3, Interesting)
It may be cultural (coming from an IBM mainframe background) but I tend to think of mainframes as from IBM, Hitachi, Amdahl, Honeywell, ICL, Fujitsu etc - basically designed for reliability, ridiculous levels of connectivity and huge data throughput. I know a big Sun box is at least as powerful as a small (older?) mainframe but there you go. I suppose it's more a matter ot role than power?
Some of the brands I list may no longer exist (or be
Re:Or... (Score:5, Informative)
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.
You just hit on the problem. (Score:3, Interesting)
But as you said, we "obviously have no idea how it works" because it's hard to find out! The mainframe world is a separate place, secret, etc.
So how do we change that?
And is mainframe admin worth it financially?
Re:You just hit on the problem. (Score:3, Interesting)
I'd be interested in knowing that myself. I'm an ex MVS sys prog that jumped to Unix administration about 10 years ago because it was a lot more lucrative.
Dependending on what the money is these days, it may be a good time to jump back.
In 1992, mainframers were a dime a dozen, Unix admins were as rare as hen's teeth. Looks like that situation is quickly being reversed.
Comment removed (Score:4, Informative)
Re:Or... (Score:5, Informative)
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.
You're wrong, d00d (Score:3, Funny)
Actually, it would be funny
Re:Employers' fault... (Score:5, Insightful)
> previous experience.
Takes a long time, but it will become a self-resolving problem. The existing "old guard" will eventually die out (either literally or via retirement) and create a demand in the market.
This will either cause companies to lower their standards or discard the old mainframes.
It would make good business sense to address the problem before it reaches critical mass (ie, so much of the old guard is gone that there's no way to train newbies), but if the Y2K problem was any indication, foresight isn't a prerequisite for running a business.
Re:Employers' fault... (Score:5, Insightful)
I would of course agree with the frustration tech workers seeking employment right out of college, and workers in general for that matter. It's hard to get experience when everyone wants it to give you a job, but that's not really the problem when it comes to network and sysadmin positions.
It's perfectly sensible to require people who run something as complicated as a mainframe, or even network administration, or a half a dozen other things require strong experience. However if these companies want to have people available to work on these systems in the future they also have to provide opportunities for people to gain this experience without having to rely on them for full administration. That is to say companies should be hiring more PFY's so that they can train the next generation of administrators through real life experience.
Employers don't want to do this of course because it involves having an extra employee, but they would be much better off in the long term if they had people who had real experience.
Of course an additional problem with this sort of thing is unrealistic pay expectations among tech workers in general. No one is going to hire a PFY for 60,000 a year, but there are still many people on slashdot who believe that 50,000 is a ridiculously low salary for a full time job. So while a lot of it is employers being cheap, it's also somewhat us being unrealistic.
Re:60,000 too high? (Score:3, Insightful)
Now the junior admin is still necessary, but the "junior" is something of a misnomer; The job is hardly entry-level now. Another factor:
Re:Employers' fault... (Score:4, Interesting)
The SA people at my new job are all around 60, but that is not an issue because they are aiming to finish migrating away from the platform - even if it bankrupts them, and it cost my previous employer zillions - in around 3 years.
What does that tell us?
You don't know better... (Score:3, Informative)
Though I'm not a mainframe admin, I've never met one who liked their job. If (and that's a big IF) you can find documentation, it's usually unreadable, or useless. There aren't any FAQ's, no man pages, and no tutorials. (try googling for MVS or JCL sometime - I guarantee you won't find anything useful on the web.) ALL of your documentation will come from IBM, and it's written to tell you how to use a command, but not wh
Re:You don't know better... (Score:4, Informative)
Ok, I don't work on IBM, but the documention for our system comes in PDFs on a CD-Rom and is of pretty good quality.
It is 25 years since I worked on IBMs and their manuals were pretty poor back then, but no idea now.
If you don't have access to a live mainframe for testing purposes, forget learning how to use one. Ok, I'll go with that one. Now learn unix from scratch with no machine to learn on. Now to the next part of your 'rant':
there is a search utility which searches for words, a word being a variable-name or a token such as 'case' or 'printf'. It applies standard rules for the language it thinks it is scanning
I must admit to not knowing what the first two do. If they are scripting languages, there is a proprietary one implemented which interfaces very well with the OS.
If you think a mainframe comes without a comfortable text-editor, stop smoking that crack. It just does not look like vi or emacs. I habitually use 4 different ones, some full-screen and some line-based.
wrong in our case. System software is written in C so the compiler is included
in other news (Score:3, Funny)
We should take immediate action (Score:5, Funny)
Re:Actually... (Score:3, Informative)
Mainframe development work (Score:4, Insightful)
Re:Mainframe development work (Score:5, Interesting)
Also, the long lifetime of the mainframes means there's an abundance of various applications that depends on them in all departmens of an organisation that use mainframes. Changing, (heck, even finding those applications
Also, much of the infrastructure in the airline, train and other similar industries are based on mainframes, and they won't switch anytime soon, since it would require massive investments and many, many rounds trying to get all the involved partnes to agree on a common platform.
So, that there is money to earn on mainframe platform is not surprising, but, at least from my view, most of it will be maintainance/integration.
Mainframe operation 101 (Score:5, Funny)
*hit with broom*
That's all you need to know.
This is so true! (Score:3, Funny)
I remember the wonder of getting our first horizontal autoloading nine-track tape. It had a high density of 1600 bpi.
A question... (Score:4, Funny)
Re:A question... (Score:3, Funny)
A very large "computer" (some are more comparable nowadays to an advanced calculator) to which remote terminals connect in order to function. In short, big ugly was-once-super-powerful computer that is the master of a network or portion thereof.
Look for something like a big box with lots of wires, maybe some tapes attached, a little rust on the side, and a weeping IT admin beside it.
Re:A question... (Score:5, Funny)
mainframe n. An obsolete device still used by thousands of obsolete companies serving billions of obsolete customers and making huge obsolete profits for their obsolete shareholders. And this year's run twice as fast as last year's.
pretty accurate.Re:A question... (Score:5, Informative)
Re:A question... (Score:3, Informative)
Huh? Stuffing FUD in there or what? (Score:5, Insightful)
How does linux freshen the mainframe labor pool, and not the Unix/Windows NT pool?
Linux ain't System/36 or MPE or any other mainframe OS. And show me one linux app that's written in COBOL. (The language exists, but I've never seen it put to use).
This is a self correcting problem. A good admin/coder can pick up mainframe stuff when he needs to. All the 50+ year olds are still working the jobs they got when they were 30. When they die off/retire, younger folks will pick it up.
I mean, hell, I picked up enough about MPE and FORTRAN and COBOL to do my job inside of a week. And I got competent with S/36 and RPG at my last job.
It aint rocket science. It's like a skilled machinist learning to shoe horses.
Re:Huh? Stuffing FUD in there or what? (Score:5, Insightful)
Re:Huh? Stuffing FUD in there or what? (Score:5, Informative)
COBOL on Linux (Score:3, Informative)
Shameless plug: Acucorp, Inc. [acucorp.com] 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!
Re:Huh? Stuffing FUD in there or what? (Score:5, Interesting)
I've worked in banks/credit unions my entire career, and this is my take.
In my experience, a LOT of financial software is written in COBOL.
I'm not talking about Quicken, I'm talking about the applications which take in hundreds of thousands of transactions in databases which boggle the mind.
I know for a fact that the core processing portion of ITI Software [itiwnet.com] is written mainly in COBOL, as I ran the server there for over 4 years. I won't call it a mainframe (even though the superiors did) because the software package ran in Win2k Server using some really odd "MCP" (Master Control Program) stuff that is by far the most picky, strangely configured software I've ever come across. These "mainframes" were sold and configured by Unisys, who are definitely in bed with ITI as far as hardware/software support is concerned.
Most of the database per se is large "Flat Files", just a long stream of 0's and 1's and other data, seperated by special characters. During the daily processing of checks and various transactions, these files are updated, and it is these files which are utilized during daily operation.
It's a terribly arcane way of doing things, but if it ain't broke...
You'd also be surprised at the amount of robust win32 software that is written to interact with such dinosaur programming.
When I first encountered this system (where you have to enter process numbers and "AX" to send commands: for example "1234AX Y" to answer a y or n question a cobol program asks for) I thought they were kidding. Nope, this is how some banks actually process work, transactions, and reports/statements.
Also, any COBOL programmer made a FORTUNE with the whole Y2K thing. I know I specifically lost many days of my life in testing, especially with the federal government in utilizing their old DOS software (FEDLINE) and testing for year 2000 compliance.
Re:Huh? Stuffing FUD in there or what? (Score:3, Interesting)
Obviously, you've never worked on a mainframe. It's not like Java or UNIX, where you can google the web and come up with useful documentation. You have to be trained to use a mainframe in a college environment; you can't learn it by picking up an O'Reilly book and cramming
Re:Huh? Stuffing FUD in there or what? (Score:4, Informative)
Some Quick Finds from Google:
Your hello world:
http://www.roesler-ac.de/wolfram/hello.htm [roesler-ac.de]
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/ [texasrock.com] (Nice collection of links)
College is fine and dandy, but that's not the only way to learn something.
Re:Huh? Stuffing FUD in there or what? (Score:4, Informative)
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.
No place to experience/learn (Score:5, Interesting)
And I personally wouldn't mind learning how to use a mainframe-type thing, but where am I going to find my own mainframe to muck about with? Everybody's got (or can get access to) a linux box to "learn Unix" on. Where on earth am I going to find an S/390? Try and get ahold of an Itanium with OpenVMS (which isn't really "mainframe" mainframe, is it?)?
Re:No place to experience/learn (Score:4, Informative)
Maybe you should look here [conmicro.cx].
(It's an emulator for the ESA/390, etc.)
Eli
So, the admins are old. (Score:5, Insightful)
What's the problem, here? If the 50-year-old programmer is the only one who knows jack about mainframes, hire the 50-year-old programmer. Don't whine about not having enough qualified programmers, when what you really want is just-out-of-college programmers that you can bully into working for you at half the salary of someone with real experience.
Re:So, the admins are old. (Score:3, Insightful)
I think the general idea is that the 50-something programmer will most likely wish to retire soon.
I'm old enough to remember when companies kept their employees on long enough to offer them retirement plans. . . and I'm only 28. So if the 50-something wants to retire "soon"--which is probably on the order of 10-15 years--that still gives you several years where you'll have his expertise available not only to do the job but to train newer and younger programmers as well. There's really no good reason n
Re:So, the admins are old. (Score:4, Insightful)
Re:So, the admins are old. (Score:4, Interesting)
In another 20-30 years, they will be saying this about Java and C++ programmers. Sometimes I feel like putting down money on which 20-something pierced and tattoo'd open systems nut is going to become the 50-year old curmudgeon.
Low pay (Score:4, Informative)
Finally an IT field that is NOT over populated (Score:2)
I must be unique, but employable when times get worse then they are now..
"now accepting job offers"
main frame techies (Score:3, Insightful)
Let me get this right... (Score:4, Funny)
Darn, I was just starting to get working on my Fortran...
Legacy (Score:5, Interesting)
The reasons for keeping the legacy systems are obvious: cost of conversion, proven correctness, etc. However, I still think the scalability and reliability (e.g.: redundancy, resource pooling, load balancing, etc.) of NoW (Networks of Workstations) will in time push both the mainframe and nearly anachronistic programming language Cobol out the door. It's a simple matter of economics: it costs less to design, construct, implement, maintain and re-tool the different components of a distributed system as opposed to that of a mainframe.
Culler [berkeley.edu]'s paper on NoW is a classic.
Re:Legacy (Score:4, Insightful)
Here's the scenario: A hdd fails, the system automatically calls IBM and a tech is dispatched the same day. I get paged, and meet a tech at the front door.
IBM Tech
I heard you have a drive failure here
Me
I do??
IBM Tech
No problem, I have a drive right here, it will only take a second to swap it out
He swaps out said drive, zero down time, and nary a performance hit because a hot spare came online. You have got to love that kind of service and uptime, and just plain reliability.
Re:Legacy (Score:5, Insightful)
A case can be built for the verity of that assertion as applied to the mainframe situation.
Re:Legacy (Score:3, Funny)
Yup, I first heard that back in 1981. Given enough time I'm sure that will be true. Of course, given enough time a room full of Eminems with tape recorders could eventually record some music.
Heavily Sarcastic reasoning for this (Score:3, Funny)
I can code cobol. But I'd rather gouge out my eyes with a sharp stick.
Re:Heavily Sarcastic reasoning for this (Score:3, Funny)
I think you just made an insightful observation.
At 22 you ain't done shit yet.
--Richard
Yeah right ... (Score:3, Insightful)
Basically the "Computer Science Business" degree plan is designed to make cobol monkeys for either the school, statefarm, kraft, or caterpillar who still rely heavily on cobol for day-to-day operations. What's the catch? In less than 10 years all the formentioned companies will be converted to either a .NET or Java platform to control all their operations. COBOL's last major reworking was done 18 years ago, it's time to switch to something new.
I hate cobol and I always will, if I ever see an VSAM or coding paragraph again I'll probably freak. I'd rather work at McDonalds than be a COBOL monkey. I don't think I'm alone with my views either, as this article proves. These systems are old, prone to crashes, and not supported by level one support anywhere. They have heavy maitenance price tags and it's for this reason that it is more economical for these companies to completely rewrite their systems. IBM Running on Linux will NOT save COBOL, it's a dead language, just some people still speak it.
Death to cobol you worthless language.
Re:Yeah right ... (Score:3, Insightful)
That's what they said 10-20 years ago, when those systems were new.
"Don't worry about that pesky 2 digit year thing. These systems will not be around that long."
Re:Yeah right ... (Score:5, Interesting)
I work for a financial institution. We run a fairly small IBM mainframe using OS/390. Our basic software for keeping up our loan accounts is 95% VS COBOL II and 5% Easytrieve Plus (a report writer language). Our files are straight VSAM--no databases to be found. Yes, it's antiquated, and yes, it works. We process information on about 150,000 loans nightly.
Several years ago, our CIO decided that mainframes are teh sux0r and that he wanted to replace it, and our COBOL loan systems, with "state-of-the-shelf" technology. He embarked on a four-year search to find a server-based system that could do what our users wanted and still process accruals, maintenance, and all the other assorted number-crunching on 150,000 loans, every night. Meanwhile, he decreed that all future development would be done using Microsoft technology--Windows NT/2000 as the platform, SQL Server as the database, Visual Basic 6.0 (!) as the language.
The first client/server development effort went twelve months over schedule and $2 million over budget. The second, in my programming group, only went in on time (but way overbudget) because we got some kick-ass VB6 programmers willing to work 75-hour weeks for 3 months. We quickly expanded to have a dizzying number of "data marts" and databases and report writers and little disconnected client/server apps...all of them fed by the mainframe. From nothing, we went to 300+ servers in 3 years at tremendous cost and tremendous headache.
Now, they are rewriting another bank system off COBOL--oh, but Microsoft no longer supports us using VB6/COM+, so now it's
Meanwhile, six of us keep those COBOL loan applications purring like an old Chrysler 225 slant six engine. It's not pretty, but by God, it works. Day after day after day, with no real drama, the numbers crunch and the money rolls in. They could be doing everything new still on the mainframe with some of the newer mainframe tools--but basically, our upper management has decided that Green Screens Are Evil. That's the only reason we're spending the money we're spending.
Oh yeah, that four-year journey for a replacement system? Ended in failure. No NT/W2000-based distributed system out there could even get close to the performance we required. Unix systems came closer, but Unix is a four-letter word around here--it's Microsoft or bust, baby, we ARE Bill Gates' bitch!
There's no substitute for a mainframe and COBOL when you've got to move huge amounts of data around on mission-critical financial systems, and do it with near-perfect reliability. Distributed systems don't have the rock-solid reliability, yet. They may someday, but not now.
So welcome to reality, Junior. COBOL isn't going anywhere anytime soon. Better pay attention in class! Either that, or learn to say, "Would you like a McTurnover with that?"
Aerospace is seeing this... (Score:3, Interesting)
We are not dead, we just (Score:5, Insightful)
But M$ exchange cluster design and management pays MUCH better.
Help Wanted (Score:5, Funny)
Mainframe Techies are a dime a dozen--the real challenge is finding competent PDP8/E techies these days!
Plunk your modern so-called "computer whiz" in front of one, and their first reaction is invariably one of the following:
Comment removed (Score:5, Insightful)
Re:"mostly in their 40s" -- oh no! (Score:3, Insightful)
Law firms have lots of younger junior partners just itching for a step up, and paralegals and other staff behind them.
But who's waiting to take over for the COBOL programmers? No one now, no one coming soon, and no one in the forseeable future. That's the problem.
Comment removed (Score:4, Insightful)
Re:"mostly in their 40s" -- oh no! (Score:3, Insightful)
Where I work, their idea of "retraining" us COBOL jockeys was to send us to MCSD 5-day cram refresher classes--never mind that none of us had coded VB6 before in our lives--and then expect us to get an MCSD certification, without EVER using the stuff in the wild. Once they realized that we couldn't do that, all training was withdrawn. Anything we want we have to get on our own, which is OK, that's the way things go--but we won't be given any opportunity to actually use the stuff unless we
Re: (Score:3, Insightful)
solution (Score:3, Interesting)
How to get new mainframe techies (Score:5, Informative)
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 [conmicro.cx]. 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 [cbttape.org], which is a great resource for the mainframe community in general.
A Non Issue (Score:3, Insightful)
Employers target these people and train them. I know. I was one of them.
I went to a school called Chubb in New Jersey, which is run by the Chubb Insurance company. It was originally an inhouse training development center for Chubb so they could train new employees on their mainframe systems. It got very popular and they opened it up to outside companies to make a few bucks. It has gotten very popular and is located in several states now.
The companies who need mainframe workers know about schools like Chubb. The only thing that has changed at Chubb over the years as it became less of a Chubb training center is that they have to cater to the people who do know about current technology, so they also offer non-mainframe curriculum. But as far as I know (haven't been there in 10 years), mainframe is still their bread and butter.
India to the rescue? (Score:3, Insightful)
They have a habit of showing up at our doors for that kind of thing, whether we need them or not.
How to Tell a Mainframe Techie (Score:3, Funny)
9. "If you can't submit the program in batch mode, it just ain't worth submitting"
8. They're the guys with spot welders in their briefcase.
7. Compared to what they are used to, any PC or Mac is a portable computer
6. They know EBDIC, but to them edlin is a newfangled thing.
5. They know DB. They don't know Debian
4. They don't trust any machine under 3000 lbs.
3. They come home from a hard day's work with hands covered in soot and burnt oil.
2. The telltale COBOL on the resume
1. They knew all about dangling chads and punch cards without having to read Slate
Re:How to Tell a Mainframe Techie (Score:3, Funny)
10) They view a PC/MAC as a dumb terminal "with this neat copy/paste thingie."
9) They know EBCDIC and are totally annoyed that numbers sort before letters in ASCII.
8) They are also annoyed that PC keyboards use the new-line key as ENTER.
7) "Fiber optic cable" means a 36-pair trunk. Anything less is just a device jumper.
6) They think that less than eight fiber paths to any device constitutes an I/O bottleneck.
5) They laugh at COBOL programmers. To their faces.
4) The largest program they ever wrot
Free Mainframe Emulator - Hercules (Score:3, Informative)
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!Re: (Score:3, Informative)
Ugh: T-Rex? (Score:3, Funny)
I am constantly being ribbed by a younger guy here about being an old ex-mainframe guy. He is always going on about how there were dinosaurs crawling about when I was programming on them. Now IBM comes out with a new model called "T-Rex". I can feel a new verbal assault coming on ...
Couldn't IBM have call it something like Mainframe Extreme or something a bit more trendy?
Learn by doing it... (Score:3, Insightful)
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.
Advising a High School Student (Score:4, Interesting)
What path would a kid take to get into real datacenter hardware?
Re:Advising a High School Student (Score:3, Funny)
Go work for Unisys, IBM, CSC or EDS. Volunteer for the mainframes - there probably won't be much competition. Your colleagues will laugh at you, and tell you all about their "hot" Java skills. Quit after 5 years and become a contractor. Laugh at your former colleagues who're discovering that their skills are a cheap commodity now.
This Article Sets Up Future H1B visa increase (Score:3, Insightful)
Some things never change......
easiest way to learn mainframe... (Score:4, Informative)
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
Mainframe emulators running under Linux (Score:4, Informative)
Okay (Score:3, Interesting)
WE wll know they are bigger, mroe robust, fault tolerant, etc, and run weird operating systems, and people only use weird languages on them like rexx and cobol and fortran.
What is the gain? Why are these languages used? What is the real deal with mainframes, and why would anyone other than a legacy operation want one nowadays?
Words from a COBOL coder (Score:4, Interesting)
I just finished taking a Java course so I could have a way out of my COBOL-dreary job.
The grass is always greener...
From the Devil's IT Dictionary (Score:3, Insightful)
I'm a fugitive from the law of averages? (Score:3, Insightful)
Old Bastard Sysadmins (Score:3, Funny)
Sometime in 1993 we had meetings where the clueless manager would ask us the uptime so should could put it on her report. Our group would report the different servers we ran with a 50 to 100 day uptime but the old guy who ran the 3081 would claim 4767 days or 13 years or 17 billion microseconds depending on the week.
At some point we were told everyone was going through "team training" and we were the second group scheduled. We made the people running the team training cry and the had to postpone it for a few days while they could collect their thoughts (and feelings?) A second revolt was led by the Old Bastard Sysadmin at teh mention of a group hug.
At the time I had been doign sysadmin work for 8 years but the Old Bastard Sysadmin taught me some of the finer points of being a BOFH.
It's not the same mindset at all. (Score:3, Informative)
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.
Locomotives are still around (Score:5, Insightful)
Locomotives / freight trains are still used regularly. They serve a need that cannot be met with automobiles or even 18-wheelers. For Joe Sixpack and his family, an automobile is definitely a more efficient way to cross the country. For ABC Florist who relies on fresh cuttings, locomotives take too long - trucks are better. But for XYZ Furniture ordering fifty sofas, twenty-five coffee tables, one thousand various lamps, etc., it would take a large number of trucks (each having a driver to pay) vs. twelve cars in a freight train (one driver to pay).
There is a use for mainframes in particular industries - personal computers and servers aren't the be-all end-all answer to every computing need.