Obtaining Mainframe Experience w/o a Mainframe?

Nice2Cats asks: "So I'm reading all over about how companies are desperate for people who know how to work mainframes, especially now that IBM is shipping them with Linux. But how -- short of a course with Big Blue or some other exercise in expensive formal education -- can I acquire even the most basic information or experience with big iron? There doesn't seem to be many tutorials or introductions online; what would be nice, but I can't seem to find either, would be a simulator that would run on a PC. All I want to know is if I like enough to be seriously interested."

Comments

It's really very easy

[elmegil]

The same way as everyone else got mainframe experience in the old days: Entry Level Position.

Re:Simulator?

[Lionel Hutts]

That's either the least educated comment I've read around here in a while, or the best-crafted troll. In any case, I'll bite:

Do you have any idea how little raw CPU power (not that they call them CPUs) a traditional mainframe has? They said mainframe, not supercomputer!

Yes, yes, they have lots of fancy I/O processors and whatnot, and some modern big iron is different, but there should be no problem running simple software on an IBM mainframe simulator, if one exists and you don't actually intend to support many users on it.

Training

[Mr. Piddle]

Do companies do training, anymore? Or, do they expect everyone to learn everything of relevance on their own time with their own resources or at the expense of a prior employer? Or, are there such a surplus of qualified canidates milling about that even thinking about making a horizontal career change is laughable?

For example, while the author of the article above wanting to learn mainframes is cute, would any company give a damn if he already has several years experience but didn't already learn the ins and outs of mainframes hands-on in a former employer's "enterprise" environment?

It just seems that ground-floor opportunities are a myth. Ugh.

Re:Training

[ComputerSlicer23]

Hmmm, don't take this the wrong way... but C++ isn't something you pick up in a week or two, I've been coding in C/C++/ObjectiveC professionally for 6 or 7 years now. Sure you can use it to do everything you could so in say Pascal in a week no problem.

A couple of weeks of C++ experience won't teach you the nuances of the STL, how templates work, the strange rules about operator overloading. It won't teach you in's and out's of the pretty large C/C++ standard libraries. You won't know anything about the sublties of the multi-inheritance issues. You won't know about the nooks and cranies involved in overloaded function call parameter resolutions. That's the kind of expertise you need to be able to do serious C++ work. It's something that takes at least a year or two of experience, and dedication to learning the ins and outs of it all. They are better off paying some fresh out of college grad less money to learn in all likelyhood then they are you. They have the same degree you have, that you claim will make you competent in a couple of weeks. Why should they pay you extra?

You've got it all backwards, the semantics of the language are what are important. In fact, I'll go so far as to claim that your experience might make you a worse candidate for using C++ then your fresh out of college grad. You have knowledge and expectations about how you think things should work. You think you know what the semantics are. However, subtle differences in the semantics can lead to very poor code, where you end up fighting the language the tools to get the job done.

Java, which I don't know, I am told is really difficult to be very good at, if you aren't extensively familiar with the ins and outs of the areas. Simple stuff with J2EE, like certain containers can't deal with threads. Stuff like how overloading works, the difference between the object type Integer, and the base type int. The differences between the various JVM's. The sublties of hooking up the various intrumentation tools. There is an extremely large standard library, and knowing how it works, and which pieces are how old, and what is compatibile with with versions of the JRE's is very important. Just knowing the syntax, and that inner classes are a feature, and that there are no pointers, and there are no functions not attached to a class, doesn't make you Java programmer. Sure you can have a cursory knowledge of Java in a couple of weeks. Great, I'm not terrible interested in paying you experince programmer wages so you can learn the tool. There are entry level jobs out there for Java. They'll be thrilled to have someone with programming experince.

Just because you have a degree in Astro-areo dynamics, and have experience designing parts on for the Shuttle engine, doesn't mean you have the necessary skill to be a drop in replacement for a engine designer for Dodge trucks. A guy fresh from college who studied the Engineering methodologies of Dodge for the 6 months in a case study, is probably much more qualified then you are, for very similar reasons.

My first programming gig, was pretty much, we higher you for twice what McDondald's pays you, and we'll throw you in the deep end of the pool 3 months, if you still floating at the end of that, your a keeper. I got plenty of lessons at the school of hard knocks, they had a couple of very good senior programmers who kept the rookies on track, and bailed them out if things got out of control. I made good money for what I knew, and 2 years later, I did in fact know a lot about C/C++. My next job, I spent a bunch of time writting ObjC. Spent 18 months learning the ins and outs of the OpenStep Runtime making not much more the the first job, and I learned a lot about Oracle and being a DBA. I learned a lot about Solaris, Linux, and WindowsNT during all that too. Then, I finally got a good job, for someone who had experience in C++, and needed some expertise in doing SA work, and I had to build a schema, and pick a backend RDBMS system to run the company's core data on. I finally was considered worthy of the task.

Kirby

Re:Training

[Carpathius]

At least in part I disagree. I've been doing professional programming and application development for over fifteen years now.

There is a *big* jump from procedural programming to OO programming, and there are those who I've seen have major problems making that jump. But that's not true in all cases. Once you understand the basic techniques in procedural and OO development, it's not that big a jump to move from language to language. It's mostly a matter of learning the libraries.

Can a C programmer learn C++ in two weeks? Maybe. It depends on many things, not the least of which is how good a developer the person is already. Will the best developer know all the ins and outs of C++ after two weeks? No, but that's unimportant. The best developer will *know* s/he doesn't know everything, and will be able to pick up those things as s/he progresses. Will he or she be competent? Yes. Will he or she be productive? Yes.

It really depends upon the person. Once when I left a position, the guy who was filling my spot didn't know why he should care about the difference between disk and RAM. He'll never be a decent developer. Yet there are people out there who can pick up Java when all they know is COBOL. (Real example.)

My point is that once you are truly a *good* developer, then most of the rest of it *is* syntax and libraries. OO is just another type of syntax, and someone who really understands programming will pick it up as well.

Sean.

Don't Bother

[perljon]

All technology has two humps. On the first hump, you make a lot of money because the technology is hot. For example, .net. Then because the technology pays alot of money, a lot of people get into it and the pay goes down because the employee supply goes up.

The technology becomes main stream and doesn't pay very much. Then, after a while, people start getting out of that technology. They retire. They become Pointy Hair Bosses. They get out of it. So the supply of knowledgeable employees goe down, and the pay goes back up. But the technology is dieing. It's days are numbered.

For the most part, mainframes are on the second technology hump. You only get paid alot because old foggies are the only ones who know anything about. Basically, it's a waste of time to pursue mainframe knwoledge, because it's pay heighth is fairly limited.

Solaris on the other hand is on the top of first hump. You can make a career out of knowing it. Linx on Micros is an up and comer on the hump. Windows is on the first hump. Mainframes are dieing.. just like cobol. Don't waste your time.

Re:Don't Bother

[Hellraisr]

Mainframes are dying are they?

Also, COBOL has been around for 50 odd years or so.. it has outlived other languages, and companies love it because their stuff that's years and years old will still compile and run, so they don't have to pay someone to rebuild from scratch.

My guess is you're an x86 programmer, aren't you? And you think that just because you never logged into a mainframe that nobody else is.

The biggest companies in the world still use them heavily, and as long as those companies still want the machines (they still do as their programs already run on them, and do so quite well), IBM et al will NEVER discontinue them.

Re:Buy a used mainframe

[crmartin]

An AS/400 would be kinda fun, but it is in no way a mainframe. In fact, as AS/400 is an emulator for a lovely machine of immensely weird architecture called the System/38 -- it had a "tagged" architecture, which means that it's essentially object-oriented hardware. It also has a 120-bit address space, in which all devices (memory, disk, tapes, floppies, networks etc) simply occupy parts of the address space. The emulator makes this rather baroque instruction set run on RISC-y underlying processors, and makes the processors transparent to the rest of the system: user software doesn't even know it's on PowerPC or something weird else. (There was even some discussion of doing VLIW processors, although I don't know what ever came of it.)

The other amazing thing is that OS/400 as of V3R6 has the whole bottom layer implemented in C++ from bare silicon on up. So far as I know, it's the only commerical OS that was actually implemented from using C++ and object-oriented all the way. (I participated in teaching the folks at IBM the C++ they needed to do this.)

The point is, though, that the IBM/360 series of mainframes are not the same.

Re:Linux on IBM negates "mainframe skills"?

[THEbwana]

They dont migrate away from zos to linux. They migrate from win and various unices to linuximages running in lpars on zos machines.

- This means that they need zos operators to setup the zos environment and linuxadmins to run the linux images running on the zos machine.
The problem lies in the availability of zos veterans who didnt stop learning things 10-20 years ago (and who are not retiring within the next couple of months). These veterans are needed to setup the system lpars, wlm, etc etc to provide the logical areas where linux is supposed to run. If this is not done properly, there will be no benefit in running Linux on zos compared to running Linux on i86 clusters -> IBM will sell less zos hardware.

The biggest problem for IBM (IMHO) is that it's so hard to get mainframe experience -> no one learns the platform -> they sell less hardware.
I recently saw a WebSphere zos assignment in London paying 2500 GBP / day. That's roughly 90 000 usd / month, clearly reflecting the supply and demand situation in this market segment. If IBM wants to continue selling their zos hardware they will have to give the slashdot crowd an easy and cheap route to gaining mainframe skills. /m