Being ~just~ out of college, myself, I don't have the years of experience
of dealing with these IT decisions. Although, I can say that there NEEDS
to be more done at a training/college level. The problem has been
stated...that, unless there is a positive economy within a company, they
cannot even afford to try or buy a mainframe and the talent needed to run
it (which is less than if one had 200-400 Intel/Sun servers, for
instance...ok, that was biased ;)
Obviously, we have a huge shortage of college-age interest in mainframes
(but, not Linux, which I agree is a major key in solving this via
"crossover potential") due to a few factors such as: microsoft dominance
-over the years I grew up in the education system, for instance-, company
budget squashing, innovative IT's who can't go back to their managers to
tell them that they should get rid of the 100's of servers they bought a
few years ago to replace the mainframes that they should go back to (for
various reasons such as $$$, especially now)....and there are more factors
that I'm sure the professionals on the list can drum up in a heartbeat.
The necessary training (or even a simple base) is just NOT available to
most colleges...and, for a very obvious and practical reason...it's not as
popular and has been snuffed by a lot of college's who already use, or have
moved to, Unix boxes (of which are the popular college CS lab tools,
including Linux, of course). SU, for instance, has some courses which I
took as a CS major for my Comp. Engineering minor mostly (since Computer
Science is more theory-based in it's core). They teach an assembler course
(not IBM assembler, but it get's you going) and I also took a
microcode/assembler course that was the "sequel" to that one. That was
about it, unless they've changed their courses since. I'm sure some other
colleges have more than that...but, that's a good idea of what we are
dealing with.
Going to those assembler classes didn't go well for many of the
students...moaning and groaning for most of the way, especially in the
beginning. Why? Boo-hoo, it's not C++. In any case, there are students
like myself who DID find it fascinating to see how this complied C code I'd
been taught so much about was used as assembler...and then as
microcode...learning about fetching, the ALU and parallel computing, etc.
I wish they had 10 more courses, if I had known I'd be working here on the
z/VM product. After college, IBM trained me with assembler classes (which
was good, since IBM zSeries architecture is specific and quite different,
obviously) and OJT, of course. Which was more than sufficient.
Basically, from a college-age level, you can see that this will not change
much unless the demand grows to where it used to be. I hope that Linux and
zSeries (for one) can really step up the need, that companies will become
aware of the training situation and that this shortage can be alleviated
one day. But, first thing's first.
Doug Ponte
z/VM, CP I/O Development and Service
zSeries, IBM - Endicott, NY USA
*** disclaimer: These are the opinions of the poster, and NOT of IBM...and
this should be extremely obvious. ***
Greetings;
Re: the training comment. When I first started in DP there was always
one or two trainie operators and programmers on the staff. The first
place I worked we got them from a couple local business schools. We
never hired anyone straight out of college because they didn't know
anything about business DP. You just can't run a business app by
sucking all the appropriate records into memory and processing them
from a table!
I once had three trainees working for me on a big payroll project.
When the project was completed they got an excellent reference from
us and they all went out and got better jobs than I had. I should
have gotten a clue from that!
Anyway, OJT is the only way I have ever experienced that gets people
trained in the way things are really done. It is sort of a community
responsibility and until Corp. America realizes that there will
continue to be a shortage of people.
Good Luck!
Dennis
Coffin Michael C
<Michael.C.Coffi To: [EMAIL PROTECTED]
[EMAIL PROTECTED]> cc:
Sent by: Linux Subject: Re: Mainframe skill
shortage
on 390 Port
<[EMAIL PROTECTED]
RIST.EDU>
07/22/02 12:01
PM
Please respond
to Linux on 390
Port
I enjoyed reading this article, but disagree with some of the "conclusions"
reached, for example:
"People need to accept that there's going to be a shortage of mainframe
skills and a need to migrate off the mainframe."
If you believe (as I do) that a zero-downtime, ultra-scalable,
cost-effective mainframe mega-processor is the only way to run an
Enterprise, then why would business want to "migrate off the mainframe" to
less stable, less scalable, less cost effective (overall) hardware? I
think
that it is time for business to take a close look at this issue, which
effects them directly in the years to come, and decide to make an
investment
in their own futures by:
1. Paying fairly for mainframe talent.
2. Providing training for new talent for the years to come.
I have been working with mainframes and, more specifically, VM (and now
Linux/390 as well) since 1981, and as a VM Consultant since 1987. Despite
there being some "dry times", I've always found work. I know many other
mainframe employees and consultants that have given up on the mainframe
entirely because there is so little work, you frequently need to travel to
where the work is, and depending upon the geographic location compensation
may be ridiculously low (don't even THINK of taking a mainframe programming
contract in Florida - the "sunshine tax" will kill you!).
While the advent of personal computers has some value in the Enterprise
(i.e. your secretary can download pictures of Tom Cruise naked - something
difficult at best on the mainframe!), I still believe that the brunt of
most
corporate computing is, and should be, done on mainframes.
Personally, you'll have to pry my last mainframe from my cold, dead hands.
:)
Michael Coffin, VM Systems Programming Consultant
Internal Revenue Service - Room 6527
1111 Constitution Avenue, N.W.
Washington, D.C. 20224
Voice: (202) 927-4188 FAX: (202) 622-3123
[EMAIL PROTECTED]
