Re: Is there a mainframe skills shortage?

Pete Dashwood wrote:
"gary drummond" <spam@xxxxxxx> wrote in message news:HMydnSNXAPZcp5bb4p2dnA@xxxxxxxxxxxxxxx
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 guess you define "meat" as "That with which I agree"? :-)
Yes, for the most part. I didn't like some of what was said, but it was true. I was just identifying with his exposure of blanket "legacy" comments by the *experts*, while still being unhappy with the truth of many of his comments. Typical for me :-)

I thought it was distinctly vegetarian and have posted my reasons for thinking so, in this thread...:-)

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.

So why are people doing that? Are they stupid? Uninformed? Listening to Salesmen? What...?

Could it be that they actually get a better cost performance ratio by doing so...? Nah... never...!


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.

Totally arguable. During the course of my career I've seen systems I thought were pretty unique and outstanding, running on mainframes... Case in Point...I always loved the way the SCOPE OS on CDC Cybers would scatter files across various disk drives (unless you told it not to) so that it wrote them to the next sector that was becoming available on any system owned drive. I/O was phenomenal.

Same on the 1100/2200.

There were no DD s required; just a file
name and its organization. the system took total responsibility for storing your data and retrieving it when you wanted it back... great stuff!

Same on the 1100/2200, except file organization didn't count.

(The
same system queued and sorted physical disk addresses so it could service them with one seek, long before the IBM 3330 implemented that same functionality into firmware...).
Same, I think, if you mean it sorts to keep the heads going in the same direction, with the exception of high priority I/O.
The point is that there have ALWAYS been
outstanding and innovative features in various hardware systems (and, prior to 1981, that meant, primarily, "mainframe".)

Are these features any less valuable when they are superseded by an alternative approach? The answer is "yes" AND "no". Distributed systems across a network pass data around and get it back for you, probably in close to the same time the Cyber took.
A *bad* distributed design doesn't work well :-)
I was assigned as to SAC/USSTRATCOM HQ to implement a our new new FDDI network. (5 hosts and routers/concentrators) The IBM (2-3090s) were scheduled to be replaced with distributed databases on multiple hosts, not mine. When I left 10 years later, the network had grown, but the IBMs were still there. Distributed databases/hosts hadn't been able to do the job-the 10GB records were a problem...
RAID systems will provide the same security
your Unisys IRSC provided, even if they do it differently.
No, duplexed files/raid has been around awhile but that only relates to storage.
The IRSC was something I really hated at first, because I am performance driven, but it grew on me.
The bottom line is that it was Integrated Recovery (Comm,message queues, programs,databases) and could restore the system or a transaction to a prior point in time (a step-with multiple steps/program), and also replay everything after fixing whatever went wrong, if that's what you wanted.

We LOVE what we understand and are familiar with; we resist the idea it may be equalled or bettered by something else, we wot not of :-)...


Education is another point I agree with in the above article(s). It sucks!

Kind of a sweeping condemnation, isn't it? Does ALL education suck?
No, just what I've experienced or observed, with the exception of when I taught. My problems are talking and writing, not teaching. :-)

I don't think so. It is much better today than it was thirty years ago. I can remember getting bright eyed, bushy tailed, Computer Science grads, sitting them down and asking them to do a three file merge in COBOL...

Most of them didn't even know how to approach the problem, yet these same guys could write a random number generator based on a binary polynomial that would guarantee never to repeat within so many billion samples... (Not a lot of call for that in the Banking industry :-))

Today, they would look at you and say: "Why would you want to merge these sequential files when you could have updated directly to a Relational Database in ANY sequence you like and simply ORDERed the result set?" :-)

I guess that's progress... of a kind :-)
Now you are getting into the areas I, as a vendor, had to think about.

Let's test it to see if the cost of running a temp database (license maybe? Disk and cpu usage. Development costs.) are less than him learning how to do a merge. This ignores the fact that as a customer, for at least one shot, you will eat the additional costs. As a vendor, I could test it on one of many machines to see if it is a marketable idea, including expanding the idea to converting the whole application mix to a database. $$$ :-)

I don't think it is wrong for educational institutions to NOT teach COBOL when there are superior alternatives that are in greater demand in industry. The resources and time are limited; should an English Major be forced to learn Latin and Sanskrit? (There was a time when they were...)
It's back again. My son was told he had to have two years of a foreign language to get his math degree at UNL, but his 4 years in HS was OK. *I* hit the roof about the requirement for 30 hours of multicultural classes. I thought math was the universal language :-)

Some establishments are even querying the value of Old English for the English curricula... Have a degree, but can't read Beowulf in Chaucer's original dialect? How far away is the outrage that engenders in some English lovers, from: "Write commercial computer programs but can't write COBOL?"

The difference is that today's graduates are not completely useless when faced with commercial problems, even if they don't know COBOL. We see posts here all the time from people asking intelligent questions about COBOL formats, because they have never encountered them, but are being required to deal with them. COBOL may be strange to them, but programming is not. Look at Oliver...never encountered COBOL, expert in Java, picked COBOL up very quickly and required only passing help from this group to do so. There are others also...

A "programmer" can pick up COBOL fairly quickly; it may be much harder for a COBOLler to pick up programming.
I wouldn't know, I was an ASM and Systems programmer before COBOL, but then I screwed up and learned another 12+ of them. :-)

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.

Is it not possible to implement business rules by implementing "algorithms with style"? :-) The two may be less mutually exclusive than you think.
I have nothing against style. In most cases it is easier to read. What I objected to is the complaints they make about how the validation code didn't look as good as the rest of their code. Bad habits?

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.

Probably all of the above...

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.

Er... I think you meant if someone (that counts) agrees with your position. I am someone who has occasionally counted. I do pay attention; I don't necessarily agree (with you or the article). Being of a positive disposition, I don't like to simply disagree (I'd much rather say "yes" than "no"); that's one reason why I posted my reasons for disagreeing :-)
No problem, I know I'm opinionated, *but* (I read this somewhere) we can agree to disagree on things.
Gary
<snipped rants, even though they are quite good :-)>
I thought they were better than the rest of my post.

Pete.


Gary
.

Relevant Pages

  • Re: Is there a mainframe skills shortage?
    ... I agree that much, if not most, activity is in replacing the mainframe OS ... in a large transaction/database environment. ... I don't think it is wrong for educational institutions to NOT teach COBOL ... requirements than programmers. ...
    (comp.lang.cobol)
  • Re: Declining Cobol job market
    ... pursuing Cobol jobs. ... server side programming in PL/SQ. ... A lot of COBOL programmers (and RPG programmers, and Assembler ...
    (comp.lang.cobol)
  • Re: OT: Religion in CLC posts WAS: Re: MF Collection Class speed
    ... possible that Cobol programmers see themselves as defenders of an intellectual lost cause?The last hangers-on of an idea whose time has passed. ... The absolute power was a corrupting influence, just as it has been in certain other religions. ...
    (comp.lang.cobol)
  • Re: OT: Religion in CLC posts WAS: Re: MF Collection Class speed
    ... people to think about why COBOL is in the state it's in. ... a dollar for every time I have seen Business people put down by programmers. ... >> There are certainly parallels with religion in that. ...
    (comp.lang.cobol)
  • Re: Windows/Macro Language Info?
    ... I guess that means that unreal COBOL programmers realise that ... >>No system utility could possibly exceed the utility of a COBOL ... connection is made to a server database ...
    (comp.lang.cobol)