Re: Is there a mainframe skills shortage?

Frank Swarbrick wrote:
http://searchdatacenter.techtarget.com/tip/0,289483,sid80_gci1249301,00.html
?track=NL-576&ad=583919&asrc=EM_NLT_1201842&uid=1303979

Frank


Very interesting article, with more meat in it than the various FUD being released about the "legacy" environment. A few of the links on the same page also bring a little more *sanity* to a discussion on mainframe skills.

I agree that much, if not most, activity is in replacing the mainframe OS with Linux, or other Unix-like OS, even on the existing hardware in some cases. Also, that does nothing for the areas that mainframes were, and still are, years ahead of most Win/Unix-like systems. Grid computing is about the closest anything comes to mainframe scheduling, except for it's limited use in a large transaction/database environment. The Integrated Recovery and Step Control I used on Sperry/Unisys mainframes is also years ahead of anything available, even on Sun 15K and other large fail-safe environments. Education is another point I agree with in the above article(s). It sucks! Hardware and operations are even more critical in their training requirements than programmers. They can't even find relevant training, much like programmers. It's also very difficult for current programmers to pass on their knowledge because they write COBOL programs to implement business rules, and today's crop is taught to implement algorithms with style.

When I had too much time on my hands in 1997-1999, I took a part-time position at the local Community College. We had the full Academic MF COBOL Suite-all the bells and options. There was a waiting list for the different levels of COBOL, CICS, and IBM ASM classes. Most of the students were from Russia, with the rest split between University students wanting some mainframe classes, and employees from several large Financial Corps in town-First Data, Mutual of Omaha,...

Scanning their website today, I noticed only a single COBOL I class each session this year, no IBM ASM-just Intel, and no CICS. I guess they have moved to more "modern" environments. It could be that the local jobs have been outsourced to Russia or India, and there is no local demand any more, or the companies do their own training.

My local Metro here (KS), JCCC, has converted to mostly teaching the vendor's certification classes, plus administering the tests-for the same price as the vendors. My experiences working with people with A+, M$ and Unix certifications, are not happy ones. The Brainbench Certs were *much* harder, and related to the real-world compared to Win, Red Hat, or Sun Certs.

In my view (or it used to be), the "modern" workplace is like the legacy workplace, a few good people can carry a lot of not-so-good ones. With the hype-riddled FUD being spouted by industry *experts*, who depend on FUD to keep their jobs, I don't see a bright future ahead. The education available today does not lend itself to helping, so far as the article's major points are concerned. Outsourcing => lower # jobs => less need for training => no classes. Articles like Frank linked to can help, if someone (that *counts*) pays attention.

Gary

"x"=someone else's term,*x* = as always.


Now some fun, but often true rants by *old* and *new* alike...

If the total workload cannot be ported or converted to run on Windows or Unix, it's obviously a management problem. (IRS? SSA?)

Yes, there is a shortage of IT people who work in the US (for Russian or Indian pay scales).

We need a 64-bit GUI OS, and 64-bit GUI software *before* we can replace the old mainframes (that somehow work with 32/36-bits and no GUI).

We need hardware that better supports batch/transaction/database environments, and that *can* run Windows-since Windows and the GUI-based programming paradigm *cannot* possibly be at fault.

It's *not* the fault of today's hardware. Just because the micro that started life as an embedded controller *still* doesn't have the instruction and data protection capabilities of most mainframes, or the fact that the PCI/DMA chips which were developed for small computers cannot compete with smart block mux I/O channel modules, or I/O processors with full access to memory *and* and up to several hundreds of concurrent I/O channels!

Higher concurrent, or parallel, rates of I/O, to and from memory, will result in faster throughput-for systems where file access, and database applications are in the majority.

The *amount* of mass storage available does very little to increase throughput, if the data is forced through a straw (even a big one), because it very often has to be moved before it can be used by a program. Caching in memory is nice, except it also restricts programs resident in memory, and often causes even more I/O. Many implementations will perform a swap to storage and back, before performing a memory to memory transfer, if the load on the CPU or system is less, or a channel can be configured as back-to-back or loop-back.

My PC with 4GB of memory can only use half of it because of the memory model/DMA/PCI designs used in the PC-ala M$ PAE memo, to avoid double buffering I need 64-bit capabilty, and another 4GB, which I guess leaves 32+ bits for me and my programs? :-)

How did my first mainframes, with only 1/1.5MB of memory and 48 channels get so much work done (world-wide weather database updated via 400 comm ports, and forecasts computed every 6 hours), when my PC is so much bigger, faster, and has more storage? I even have graphics too!

If this were a blog...
Gary
A PC or six
Several keyboards-stained with beer
A bag of marbles (underfoot)
A bag of chips and some dip(my neighbor)
..
..
.

Relevant Pages

  • Re: The New Roadmap
    ... know anything about both environments when writing portable code, ... That chewed up memory remains chewed ... especially with the differences between Generics and C++ ... Another great 'demo' technology that stores up long term trouble if you ...
    (borland.public.delphi.non-technical)
  • Re: Giant alien head on the tarmac
    ... Robert has such a creative imagination doesn't he? ... Typhon the evil mainframe. ... We have access to their computational power and memory storage. ... And there are other mainframes scattered about. ...
    (sci.astro)
  • Re: Irksome railway phraseology
    ... Roland Perry wrote: ... top-of-range (with more than a million pounds worth of memory). ... iirc The VME-B ICL mainframes I worked on in the mid 70's stored time as ... the design ran out of memory space long before it ran out ...
    (uk.railway)
  • Re: Dynamic memory in standard COBOL; using large data fields
    ... As has been pointed out by others, if you place the "allocated" storage routines ... COBOL compilers work in environments where there ... > not support the notion of dynamic memory. ...
    (comp.lang.cobol)
  • Re: prevent out of memory
    ... One of my build machines is a dual processor. ... > processor capacity, but out of memory. ... > I don't know about that, and I have been using mainframes since the IBM ... the CPU is just on of the many tools we use, and if we use it more ...
    (comp.os.linux.misc)