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.)

Comments

Employers' fault...

[darken9999]

Maybe if employers wouldn't require every employee to have such mass amounts of experience, there would be a few younger admins around. You know, almost like a junior admin... "Well, he knows how to admin a system, so we can teach him the specifics."

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...

[TCaptain]

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.

Re:Employers' fault...

[StandardDeviant]

Exactly. It's also very much a chicken-and-egg problem to get into the mainframe world, becuase the barriers to entry are much higher from the standpoint of working on the technologies at home to get that all-important First Job. It's easy to build a $500 linux server or buy a $1000 used ultrasparc sun machine to learn some unix and unix coding on, but ... how are you going to learn mainframe stuff? Half of that stuff isn't even documented in the trade press (unless O'Reilly has come out with Mainframe Crap in a Nutshell or something and I just haven't noticed... heck, even the acronym set for that skill area is completely divergent from what most of the rest of the tech world uses. DASD anyone? IPL? MVS? JCL? RPG? OPA? XYZ?) The closest I've ever seen to being able to toy with that sort of thing at home would be something like Hercules or buying a used AS/400 off ebay for a few grand (which isn't a mainframe but a lot closer than a generibox linux server ;))

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...

[Xzzy]

> Every job posting I recall coming across required
> 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...

[Anonymous Coward]

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).

Re:Employers' fault...

[Eskarel]

Well I would agree with the fact that it's the employers fault, but disagree on what it is thay are doing which causes it.

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:Employers' fault...

[captain_craptacular]

What school did you go to? I graduated 2 years ago and it was ALL about C/C++ and there was a required class in assembler (MIPS).

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...

[Vlad_the_Inhaler]

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.

Re:Employers' fault...

[LePrince]

Hire me ! I have plenty of experience with RPG. I finished Final Fantasy 1 to 3, 7 to 10, and I promise I'll do my best while working for you to finish the new releases on time. I also have good experience with Secret of Mana, Breath of Fire, 7th Saga, Zelda, and many others...

Oh, not THAT kind of RPG... ;-)

Re:Employers' fault...

[blincoln]

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.

Re:Employers' fault...

[Jay Maynard]

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 .

Re:Employers' fault...

[BrokenHalo]

Mainframe Techies Are A Dying Breed

I'm not quite dead, you insensitive clod :-)

A question...

[zutroy]

What the hell is a "mainframe"?

Re:A question...

[phorm]

Joke or serious question?

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...

[number6x]

According to the Devil's IT Dictionary:

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...

[pauls2272]

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.

Re:A question...

[fishbowl]

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.

Huh? Stuffing FUD in there or what?

[stratjakt]

"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."

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?

[TopShelf]

This more a symptom of employers concentrating on specific experience more than talented personnel. A fundamental skill that the vast majority of IS professionals have is the ability to LEARN and ADAPT. Unfortunately there's no buzzword that can signify this on a resume, so it gets ignored.

Re:Huh? Stuffing FUD in there or what?

[Elwood P Dowd]

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.

Re:Huh? Stuffing FUD in there or what?

[Thud457]

"This more a symptom of employers concentrating on specific experience more than talented personnel. A fundamental skill that the vast majority of IS professionals have is the ability to LEARN and ADAPT. Unfortunately there's no buzzword that can signify this on a resume, so it gets ignored."

Just goes to show why Management, Marketing and HR go to make up the axis of idiocy.
An engineer sees the problem of "we can't find experienced candidates" and comes up with the solution of "well, let's find some smart people and train them up".

Re:Huh? Stuffing FUD in there or what?

[Obiwan Kenobi]

And show me one linux app that's written in COBOL. (The language exists, but I've never seen it put to use).

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 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?

[gillbates]

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.

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 over the weekend. Don't get me wrong - I'm not saying you're stupid; it's just that IBM has gone to great lengths to ensure that the only documentation for mainframes is available through them, and their writers aren't exactly pulitzer winners, if you know what I mean. You simply can't pick up a book on the subject, or google the web, because no one is enthusiastic enough about mainframe programming to write the stuff down and publish it (either hardcopy or web.) It's kind of hard to learn something when there isn't any documentation.

And if you think otherwise, here's a challenge: Reply to this post with the JCL necessary to compile and run a COBOL program which will print out "HELLO WORLD". And then give the URL or a link to a book title where you found this information.

Re:Huh? Stuffing FUD in there or what?

[Valafar]

Here you go, smart ass (you really should know better than to put an obvious challenge up like that on /.)

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.html

And Some Miscellaneous Links for Main frame coding:

http://search390.techtarget.com/home/0,289692,sid1 0,00.html (Looks to be s/390 specific articles).

http://www.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?

[Arker]

How does linux freshen the mainframe labor pool, and not the Unix/Windows NT pool?

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

[Build6]

You know, I personally wouldn't mind learning Cobol, but I've got no place to "use" it on and develop anything that I'd find useful and therefore no way to both really "learn" it (gotta do an actual non-trivial project to really learn a language, no?) nor any reason to learn it "for" ("to possibly get a job" is no good).

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

[eli173]

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?

Maybe you should look here.
(It's an emulator for the ESA/390, etc.)

Eli

Re:No place to experience/learn

[Angry White Guy]

I actually have an old IBM system 38 at one of the buildings that my company owns. It's still there because we can't get it out without destroying the building. I'll let it go cheap :)

Re:No place to experience/learn

[ocelotbob]

Actually, you've just got to look around a bit. Do like you learn any other programming language, pick up a cobol book. Got one myself on the bookshelf. Both windows and Linux have Cobol compilers available, google for them and you'll find dozens of hits, including some open source versions.

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.

So, the admins are old.

[PhxBlue]

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.

[PhxBlue]

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 not to hire a 50-something, from a long-term economic standpoint; but then, no one's accused American companies of being able to see beyond the next fiscal quarter.

Re:So, the admins are old.

[Anonymous Codger]

50-year-old programmers aren't interested in innovation? We just want to clock time and go home? What a total load of bigotted BS. Attitudes like this are the reason older programmers have such a hard time finding work. I will look forward with pleasure to the day you celebrate your 50th birthday in your shipping crate home because the next generation of ignorant, biased young whippersnapper managers won't hire you.

Re:So, the admins are old.

[dogfart]

The 50-year-old programmer isn't usually interested in innovation and tends to shun such things as this "web crap" - they just want to clock in their time and go home. In some cases this is fine, but in others it's a big issue.

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

[yroJJory]

Well, at $14/hr I can hardly blame IT guys for not bothering to learn how to SysAdmin a mainframe!

main frame techies

[pigscanfly.ca]

I know a main frames adminstrator . Depending on what you mean by main frames , the newer unix based ones I wouldnt mind adminstering . The problem is that there are a whole wack of old crappy mainframes which are running legacy applications that very few people understanding sitting around . Now if there was somewhere to actually learn about how to handel those I would probably take the course ; but as it stands now most info systems degrees dont deel much with legacy applications . Maybe a college degree in legacy code / computing in addition to a BSC would be interesting (of course colleges would have to higher old qualified people) . An alternative would be "just read the manual" ; however if I "just read the manual" most places wont consider me comptenet (nor should they there are tones of undocumented "features") . What is really needed (if we are going to keep on using this legacy systems without relapcing them) is for a tech publisher to gather up a bunch of mainframe adminstrators and document all the undocument features in the older generation (and newer ones as well) of mainframes .

Not too surprising really

[Jack Wagner]

I've done a smattering amoung of work on mainframes and I always find it quite refreshing for myriad reasons. First and foremost I can charge premium bucks since it's all about supply and demand. Secondly, it's always a pleasure to get to work on a real computer since most of my work these days is spent on that heinous X86 scrap that society seems to think passes for computers these days.

Lets face it, working on a FreeBSD box after working on an old mainframe is like driving a VW bug with flowers all over it after driving a boss 69 camereo.

And finally since the skillset to work on these is above and beyond that which your average windows admin/coder has, I am fairly secure in my knowledge that I have job security.

It's like Rick Brooks said in the Mythical Man Month, if you are in the upper 5% of computer scientists you will always be employed making in the upper 1% wage group.

Warmest regards,
--Jack

Let me get this right...

[tamnir]

I have learnt Basic, Turbo Pascal, C, C++, Perl, Java, Python, Ruby and what not... But noooooo! Today, you must know Cobol to get a job!

Darn, I was just starting to get working on my Fortran...

Legacy

[Root Down]

The word "legacy" keeps popping up in correlation with mainframes, and this is really why most of them are still around - legacy code that no one wants to re-do for other systems. However, new applications are typically being written for scalable, multi-component architectures, not mainframes.
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's paper on NoW is a classic.

Re:Legacy

[override11]

while legacy has something to do with it, the 100% uptime (with voluntary IPL's) of our iSeries mainframe is very compelling.

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

[BitwizeGHC]

Bjarne Stroustrup has been known to observe that the primary difference between "legacy" systems and the systems replacing them is that the legacy system works and scales.

A case can be built for the verity of that assertion as applied to the mainframe situation.

Re:Legacy

[pauls2272]

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?

Re:Legacy

[bobKali]

NoW (Networks of Workstations) will in time push both the mainframe and nearly anachronistic programming language Cobol out the door

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

[Elpacoloco]

Us younger people don't have mainframes to play with. I'm 22 and I have never ever seen a mainframe. Anywhere. I don't even know what kind of software or operating system they have. Other than they might have a cobol compiler.

I can code cobol. But I'd rather gouge out my eyes with a sharp stick.

Re:Heavily Sarcastic reasoning for this

[repetty]

"I'm 22 and I have never ever seen a mainframe."

I think you just made an insightful observation.

At 22 you ain't done shit yet.

--Richard

Or...

[fireboy1919]

maybe we can learn it on our own!

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...

[doinky]

-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

Dude, when I used a mainframe for school back in the early 90s, none of that stuff except sendmail would have even REMOTELY been applicable. I think perhaps you don't know what mainframes _are_.

Re:Or...

[Brummund]

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.

Tell me about it. :-) A few weeks ago I was to install my app on a Solaris box. The clueful admins obviously didn't like to waste precious disk space on utilities not really necessary, and of course Sun's tar barfed on my GNU tar archives etc. After some time, I found the magic -i switch (I think it was), and was ready to deploy my app.

When I had deployed it and started testing, the app seemed to have a problem connecting to another host on the network. So, I
jumped into /bin/sh (why waste space on GNU bash?) and typed

$ ping hostname
sh: ping: not found

(And no, it wasn't a problem with PATH) :-)

Re:Or...

[awx]

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.

Re:Or...

[plopez]

http://www.conmicro.cx/hercules/

mvs emulator.

JCL... the horror.... the horror :)

Re:Or...

[belroth]

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.

You are wrong :-)
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...

[Vlad_the_Inhaler]

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.

Re:Or...

[finkployd]

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

Re:Or...

[dogfart]

And what do you use for the OS?

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 be qualified to do more than the most elementary tasks on any modern production mainframe.

If IBM was smart, they would release a z/OS for Linux package, including basic compilers and utilities, just for hobbyists and students.

Is anyone at IBM listening?

Re:Or...

[catfood]

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.

Re:Or...

[ebyrob]

perl, vi, emacs or anything you'd expect on a nix box ... tcp/ip may be a possibility

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. Perhaps in some cases it really would be more feasible to consider emulation instead of porting and/or rewriting. But if the question of getting onto something a little more mainstream isn't even being asked, that sounds like a recipe for disaster. (ie: someone else will do it for you, and gain a huge competitive advantage)

You want experts on Rexx, JCL, RACF/ACF2 and such? Train them *after* you hire them. Additional languages (and platforms) should be easy enough to pick up for any halfway decent programmer or sys admin.

For the record:
z/OS has POSIX 2 support.
os370 blech! Keep it away!
MVS has at least POSIX 1 support.
etc? not sure...

Re:Or...

[belroth]

What no vi??! You've got to be joking. I've yet to meet a platform without at least a couple crappy clones.

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.

Seriously though, any system not supporting the tools you mention would seem halfway dead already.

There are other tools, specific to the platforms, some better, some worse, most are just different.
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.

Re:Or...

[schatt]

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.
Solaris still correctly believes that not all tools belong in /bin. Fix your path to where the actual command is, and it will work.

Re:Or...

[belroth]

I wouldn't regard a Solaris box (even a big one) as a mainframe :-(
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 been taken over) but I bet they're all still in use!

Yeah right ...

[SuperDuG]

At my school for the undergrad degree plan of "Computer Science Business" you _HAVE_ to learn COBOL. I hated every minute of it because it's a pain in the ass and antiquated and outdated. We have an entire department dedicated to the maintenance of IBM MVS 390 systems that basically run the entire school. Everything from registration to classes to payroll is handled through a slew of cobol programs and frontends all designed almost 20 years ago.

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 ...

[YrWrstNtmr]

In less than 10 years all the formentioned companies will be converted to either a...

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 ...

[Moose4]

Now it's time to leave school and enter the real world...

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 .NET. So all the staff have to be retrained on .NET, at great expense and time. (But not us mainframe toads, of course, everybody KNOWS you can't teach a COBOL dog new tricks, just fire them when they've served their usefulness.)

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?"

Memories

[Infernon]

My entry into the IT world started at the fresh age of nineteen as the third shift operator for a Wang VS mainframe. While my previous experience was only with the Windows OS, the company that I worked for was very willing to hire someone who was green as long as they were willing to learn.
When the WANG died (Y2K!), they moved the application over to the Win32 side of things, but I was transferred to work with the IBM MVS mainframe that was used for another portion of the business. I still understand very little about the job that I did (mainly due to the ease of use that the Beta42 scheduled provided!), but remember hearing of how people that knew or were willing to learn the ins and outs of the mainframe were so few and far between. Eventually, I moved on to bigger and better things, but the mainframe still lives to this day and I've heard that they're having trouble finding decent operators:)

Aerospace is seeing this...

[Misch]

Aerospace is seeing this too. With the loss of a second Space Shuttle, there's a lot of push to have the US go back to rocket-based space travel. Well, what they forget is that we've lost a lot of that rocketry talent over the years to retirement/old age/death/whatnot... it would be pretty expensive to make the transition back.

We are not dead, we just

[Archfeld]

moved into more lucrative positions. Match my current salary and I'll go back to hexdump processing, IMS MTO, CICS batch, MVS/TSO, JES3/2, VM, REXX, DOS/VSE you name it. I've been a mainframe/mid-range support in nearly every environment around, I can even roll a VTAM sub-area :)
But M$ exchange cluster design and management pays MUCH better.

Help Wanted

[American AC in Paris]

Mainframe? Pah!

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:

1. "Why are there so many power switches?"
2. "Where's the keyboard?"
3. "Where's the monitor?"
4. "Where's the mouse?"
5. "Why does it sound like it's about to generate lift?"
6. "Does it support themes?"
7. "Let's see...'HCF' instruction? Hwa? Oh, I get it--Hardware ConFiguration!" *click* AIEEEEEEEEE!
8. "'Switch Register'? Sorry, I never register anything. It's a government ploy to learn my phone number and address!"

"mostly in their 40s" -- oh no!

[fmaxwell]

Cobol programers, still needed for legacy applications, are mostly in their 40s.

Oh no! People in their 40s will only want to remain in the work force for another 20 years or so. What will the companies do then? Train people? Not in the U.S.! All employees must be hired with all needed skills. We wouldn't want to spend money training them because that investment would be wasted when we laid them off and shipped their job over to India.

Nobody gets upset that most CEOs are in their 50s. No one is concerned that corporate attorneys are usually over 40. You don't see a panic because the average charter boat captain is in his 40s.

Working in the computer field is like living the movie Logan's Run. Once you are out of your twenties, everyone from management to your fellow tech workers thinks your time is over.

Or is it simpler than that? Maybe companies realize that they can underpay and overwork young, naive, single people but that people in their 40's with experience, families, and responsibilities will expect fair pay, benefits, and working conditions.

Re:"mostly in their 40s" -- oh no!

[Ian_Bailey]

The difference is that with CEOs, there are a whole bunch of executives waiting to climb the corporate ladder, just a litle bit younger. This progresses all the way down to the interns, fresh out of college/university.

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.

Re:"mostly in their 40s" -- oh no!

[fmaxwell]

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.

If COBOL programmers were paid as handsomely as executives and corporate attorneys, you would find plenty of people eager to learn COBOL.

This is not some big mystery. Why would someone in the IT field go that direction when COBOL programmers are paid more poorly, have less opportunity for advancement, and generally do less rewarding work? It's like paying teachers $20K per year and wondering why more people aren't getting teaching degrees.

The pay is the problem.

Re:"mostly in their 40s" -- oh no!

[Moose4]

Mod this guy up.

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 take a 50% pay cut to go to work as a "junior" programmer somewhere else.

Meanwhile, we see MCSDs, .NET and VB6/COM+ specialists, brought in off the street at higher pay grades and more money than 20-year veteran employee COBOL programmers. Unless they're on H-1Bs, in which case they get brought in at $20k under what even we're making.

If somebody is smart enough to be a good COBOL programmer for 15 years, they can learn new tools, even ones radically different. But instead companies will throw their older workers away--even though they're the ones that know the business processes--and bring in younger ones that they can work 90 hours a week and/or underpay.

Re:"mostly in their 40s" -- oh no!

[fmaxwell]

I cannot help but notice that people are in a company for 15-20 years, but still do not find themselves in a position to make these decisions.

Yet they feel comfortable complaining about the decisions made by the ones who are in that position.

If management is "comfortable" criticizing the work of those people who have chosen a career in software engineering, why shouldn't software engineers criticize the work (i.e., decisions) of those who have chosen a career in management? Many software engineers are in that field because they enjoy the work. They don't aspire to be managers. Criticizing them because they have not become managers is invalid.

COBOL on Linux

[Mark Hanson]

Linux ain't System/36 or MPE or any other mainframe OS. And show me one linux app that's written in COBOL.

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!

Don' t Go There

[DeltaOne18]

I used to be a COBOL programmer for an insurance firm. It wasn't by choice. I started out on a Java web app team and got transfered. I must say that there was a general lack of good technical knowledge about mainframe programming at the company (it didn't help they laided off some of the best guys) which made it even hard to do my job. Developing on the mainframe is much different, I find it more mondane and boring, then working with modern PCs and OO languages.

I am sure some people like it but I hated it and had to leave the company to get away from it since no one would transfer to my position.

--Kurt A web developer's weblog

solution

[ih8apple]

The solution to the shortage of mainframe programmers is obvious if you follow what I've been doing for the past 7 years. More of my work than ever is involved with integrating Java, C, or Visual C++/VB with mainframe applications. Whether through Screen Scraping, MQ Integration (like MQSI), CORBA, CICS, TCP sockets, or other mechanisms, a larger percentage of corporate bread-and-butter applications are living longer on the mainframe and extending their life through integration with web servers or application servers. As the COBOL teams die off, corporations will stop extending the mainframe's functionality on the mainframe itself and will continue to extend the functionality on the other tiers of the applications (on WebSphere, .NET Server or wherever). Almost all of the projects I've done started out as a stupid GUI front-end on Windows or a Web browser for an existing green screen application and then grew to include a lot of business logic and data storage on the non-mainframe tiers.

How to get new mainframe techies

[Jay Maynard]

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.

A Non Issue

[tealover]

There are always a level of IT employees who didn't go to school and get a CS degree. It may be a clerical worker trying to move up. A painter trying to hop on the bandwagon. For many of them, they don't really know the technology out there.

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?

[Tablizer]

I espect India to set up mainframe training centers and train hundreds of thousands in COBOL, JCL, etc.

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

[AtariAmarok]

10. They are those nice 80 year old men in the clean white coats...

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

[Rick.C]

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 wrote was 12K. The coolest was 160 bytes.

3) They know what the "National" character set is.

2) They wince at a 1.2-million line core dump, but they're glad they don't have to print it like they did in the old days.

1) They can read that core dump like it was source code.

Free Mainframe Emulator - Hercules

[Rick.C]

For all those who complain that they can't learn IBM S/370 at home on their PCs, go here and look down the right-hand side for Hercules links.

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:Free Mainframe Emulator - Hercules

[finkployd]

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.

Having both installed MVS 3.8 on hercules and worked as a sysprog on a very large OS/390 for a few years I'm going to have to really disagree with you on that. Sure some of the concepts are similar but almost nothing you learn on the MVS system is really going to carry over effectivly. WAY too much has changed.

Finkployd

Ugh: T-Rex?

[Ted Stoner]

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...

[dark-br]

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.

please mod parent down

[theuglykid]

I didn't gain any experience from school, because most schools don't seem to value mainframes anymore. This is probably because server vendors and their software vendors are more aggressively seeking institutions of higher education. These vendors seem to have more throw away money and more "progressive" marketing strategies by getting students "hooked" on to their own products(MS is really good at this game) early in their educations. This is great because some tof the graduates of today will be the managers of tomorrow and will hold the purse strings of their IT departments. WHat do you think a manager will purchase if given an opportunity? The tools (s)he's already familiar with. What will a forward thinking manager purchase when faced with a need to upgrade the system? Some will survey what the prospective employees are already familiar with (possibly to cut training costs). I gained my experience by never turning down an opportunity to work (and thereby learn). My future is secure.

I am a 25 year old programmer who spends 96% of the time working on OS/390 mainframes using JCL and MVS COBOL. Any other time is divided between Java and VB for special apps.

The team I work with (5 of us, total) is officially dubbed the "Legacy" team. Our total IT department is comprised of roughly 80 employees (so you can see how few are able to do or want to do what we can). I am the youngest on my team by 12 years. I would guess that the average age of our team members is 45 (not including me in the calc). The great thing is, because I am willing to work and I lack the offensive attitude of the parent comment, I make BANK.

I fear for you, but I don't fear you.

Advising a High School Student

[krasni_bor]

I was sitting with an 11th grader yesterday looking through the catalogs of some nearby technical colleges. I think the kid would be a really good sys admin for some serious hardware, but the tech schools seem to be focusing on PC stuff. The only thing I could figure out was that you'd have to start with the generic training in school and then go to Sun or IBM for more specific sysadmin training (in addition to the learning on the job track).

What path would a kid take to get into real datacenter hardware?

Re:Advising a High School Student

[sql*kitten]

What path would a kid take to get into real datacenter hardware?

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

[Cryofan]

This article is likely a setup article for other articles which will eventually oh-so-delicately suggest that more H1B programmers are needed from India because they supposedly still have the "old" technology, and we desperately need those old Indian skills, so therefore best that we increase the h1b programmer quota.

Some things never change......

easiest way to learn mainframe...

[svallarian]

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

Cobol?

[Mithrilhall]

Sweet! Those Cobol classes I had to take over the last two semesters are finally going to pay off!

You just hit on the problem.

[mindstrm]

Look how many geeks out there are *INTERESTED* in the idea, and would like to learn about it...

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.

[Amiga Trombone]

And is mainframe admin worth it financially?

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.

Mainframe emulators running under Linux

[shocking]

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!

Okay

[mindstrm]

Let's hear some specifics, if anyone has them, about WHY those mainframes are in use, and what advantages they have. Real numbers, if possible.

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?

Re:Okay

[easter1916]

What do you define as a legacy operation? "Legacy" is a term of abuse coined by those who want to make their technology seem better just by virtue of being newer. There are plenty of modern languages being used on midrange and mainframe systems -- Java, C++ and others.

WE wll [sic] know they are bigger, mroe robust, fault tolerant, etc

I think you just answered your own question.

Re:Okay

[Moose4]

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.

Locomotives are still around

[Ra5pu7in]

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.

Words from a COBOL coder

[grumwork]

I find it funny that all you Java/C++ coders are upset about not being able to learn COBOL to land mainframe jobs.

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

[Frankus]

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.

instead of denigrating mainframes and COBOL

[TheLoneGundam]

A few smart guys will realize that anywhere there's a shortage there's money to be made. I am a mainframe 'techie' (systems programmer) and when I retire from the public payroll I should be able to do consulting for ten years or so at somewhat lucrative rates. As for .NET and some of the other 'remote computing' objectives - that's reinventing the old tube-and-mainframe model, just with prettier UIs. And on the third hand (hey, if we can count from 0 to 15 we can have three hands), the current levels of z/OS are Unix-branded, with all POSIX APIs, run HTTP servers, and do pretty much everything any other server can do (including SMB support so we can pretend to be Windows file and print servers just like Linux). I can stand to get more acquainted with "your" technologies like HTTP and Java to put them to use on my z/OS box. And I'm willing to SHARE the knowledge necessary for those of you that want to upgrade the skills necessary to take advantage of the looming skills shortage

You're wrong, d00d

[sql*kitten]

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.

Actually, it would be funny ;-)

I'm a fugitive from the law of averages?

[alumshubby]

I'm an early-40s guy who's retraining to be a programmer (been a tech writer), and I'd like to break into COBOL programming -- mainly because around here at least, it looks like the road less traveled.

But no one wants to learn mainframes...

[zazylawy]

I work at a large 3-letter acronym company where we develop for AIX, AS/400 and S/390. I'm one of the youngest there (and working exclusively on 390) and I can tell you right now that no matter what other posts here say, *almost no one* under the age of 40 seems to want to have ***anything*** to do with 390.

I don't see this trend changing, no matter how many people post on /. and say they'd love to get the chance play with a 390 to their heart's content. There are tons of bright, curious geeks where I work, but after a short time on 390, they tend to turn 180 degrees and run like mad!

People avoid it like the plague, and I honestly think some of them go out of their way to avoid learning *anything* about the VM and MVS side of things so that they're not dubbed "a 390 person".

390 has definitely grown on me and I'm looking forward to growing old and becoming a white haired "390 guru" ;-), but I certainly have a hard time seeing it becoming a sought after position simply because so much of it is archaic, difficult to learn and most importantly, not "glamorous".

Old Bastard Sysadmins

[thogard]

Years ago I worked for a group that ran a bunch of systems that didn't fit in with anything else in the MIS department. One of the systems was a very old IBM 3081. This thing had water cooling and boxes and boxes of storage devices. It was a serious bit of big iron.

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.

Both 390 and Linux skills are needed

[richman555]

After working with Linux on OS/390 (SLES 7)on my company's ZSeries mainframe is that you end up with 3 kinds of admins. Those who know the 390 side, those who know the Linux side, and some that know both. Knowing both operating systems is probably the toughest, however ultimately you can have Linux techs administering on mainframe hardware. Youll see fewer drive failures on the mainframe thats for sure and stop server sprawl. My company has a ton of vital legacy programs written on the 390 side of the fence while the Linux side is running large samba file shares, some apache webservers, and a few DB2 databases. All this said, this fall we are going live with a large scale ecommerce site using Websphere Commerce Suite 5.4 all under Linux on the mainframe (about 20,000 products online and many more skus). This is all replacing an always growing amount of server hardware that was NT4 based MS Siteserver Commerce Edition machines. This technology does have its merits!

It's not the same mindset at all.

[Pig Hogger]

25 years ago, I started diddling on bitty-boxen (PET, APPLE, Exidy Sorcerer, Cromemco). During that time, often you had no OS to speak of, and much less applications.

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.

S370 Assembler

[kiwirob]

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

Re:60,000 too high?

[lysium]

I beg to differ. The defacto trainiee is the Help Desk technician and the desktop technician. People who are beginning to know the fundamentals of computer/information systems. Many organizations will not even let IT/MIS staff log onto a server until they have demonstrated responsibile, intelligent actions. No one is going to allow trainees to operate production servers.

Now the junior admin is still necessary, but the "junior" is something of a misnomer; The job is hardly entry-level now. Another factor: the job pool is still overflowing with the gold-digging inept. So many untechnical (at heart) people are masquarading as IT workers, that it becomes necessary to offer more money simply to attract a level of competence.

Or these are just clever rationalizations. Funny, you speak of paltry living wages as a positive thing. You see, the corporate people on top of the pyramid will still be making "New York wages" while the techies join the rest of the wage slaves making "Missouri wages." So yes, the companies cannot afford to employ everyone at exaggerated salary levels: in the future, the executives will simply make certain to keep it only for themselves. This suspicion will always make me advocate higher wages for skilled labor.