Mainframe Operators Needed

blueforce writes "Computer World is reporting that there's a shortage of skilled mainframe workers on the horizon. Quote: "Getting IT professionals, especially young ones, interested in learning mainframe work isn't easy." No kidding. While I've never worked on a mainframe, I have worked on AS/400's. 3 words - Mind Numb ing. Perhaps it's time for a more long-term solution to the problem. Interesting nonetheless. Who'da thunk it - a shortage in IT. What's next, COBOL?"

Comments

Why would it be mind-numbing?

[Effugas]

I don't entirely understand why mainframe work should be much more mind-numbing than point-and-click or shell-hopping. Would somebody with AS/400 experience explain what makes administration of the machines completely non-automatable, and thus requiring massive amounts of repetitive input?

--Dan

Re:Why would it be mind-numbing?

[bsd_usr]

Administration? I never knew there was administration to an AS/400. Ours just runs and runs and runs by magic. It doesn't have problems. It doesn't go down. It just works. Period.

Okay, seriously. The only work I ever have to do with the AS/400 is maybe kill users off the system when I need to backup. Or, move spool files from queue to queue when a printer gets really busy printing other stuff. AS/400's are built for business number crunching and business data warehousing. That's it, nothing more and nothing less.

There are no themes to play with on an AS/400. Well, I guess you can change the color of a green screen client access session, but that's about us much themeing as you get. Why? Because it's for working, not playing.

Most applications on the AS/400 are written in RPG which I bet most people would these days would not like to program in. I don't like it much either so I never bothered to learn it. But you can also use Java to access the data as well.

But RPG is so powerfull on an AS/400 that you really don't need anything else. You can create screens in RPG, business reports, and more. You can also use RGP to create CGI apps for web based applications. Maybe one day I should learn RPG.

The hardware support is like no other. Although, working with Twin Axial cabl is a pain in the ass. But, it gets the job done quite well. I have about Twin Ax 40 devices (give or take) on one AS/400. That's terminals and printers. Not counting the numerous RF scanners as well. Not sure how many of those we have. Maybe like 30 or more. I'm also not counting the network printers as well. There's like 5 of those.

We also have another warehouse which uses our AS/400 through a fractional T-1 private line. They have RF devices there too that use the AS/400.

It's a workhorse. Nothing more, nothing less. It might not be the fastest of them all. But who cares when you have stability and durability and all the great features of an AS/400.

Although, like I said before AS/400's are for business. So don't expect to see them in the scientific fields and stuff. I guess for every problem there's a tool. For business, it's the AS/400.

I guess it can be mind numbing because it isn't very glamorous or fun. It's user interface can be called ugly, but at least it's functional and fast.

Re:Why would it be mind-numbing?

[Nate237]

I've spent the last two years trying to get up to speed on OS/390, and I'm still very green.

It is a different world altogether.

Take a look at Unix, DOS, and Windows. Many of the concepts are similar. You have files, directories, fairly straight forward users and groups, etc. Even MacOS is similar in some ways, like having a directory hiearchy, files, and so on.

In the mainframe world (btw, an AS/400 is midrange, not a mainframe), its a whole different ballgame. The concept of a filesystem is not the same. You have PDSs (partitioned datasets), libraries (similar), and sequential datasets. PDSs are entities that contain members (like files). PDSs can not have PDSs in them, so there isn't a hierarchy.

OS/390 and z/OS do have OpenEdition, which is the Unix part of the operating system. It uses HFS (hierarchical file system), which is more like the standard Unix file/directory system.

Things are put into motion by submitting jobs. These jobs are written in JCL (job control language). The jobs are submitted to JES2 or JES3 (Job Entry System), which is the subsystem responsible for job control.

On top of all of that, there are several other subsystems. You'll usually see security handled by IBM's RACF, CA's ACF2, or CA's TopSecret. Then there are other subsystems such as CICS, CA-IDMS, or IMS that have their own programs running within them. Then add products like MQSeries, DB2, Websphere, etc.

You very rarely, if ever, run into someone who handles all of these components. Almost all shops have separate teams. Maybe a security team that handles RACF or ACF2, a CICS team, DB2 team, and so on.

I've found the most difficult barrier to learning the mainframe to be the lack of comprehendible documentation and tutorials available on the web. I find myself always having to query others who have years of experience already under their belts, or having to dig deep within IBM's documentation sites, usually into several books at once.

Mainframe Operators

[raydobbs]

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.

Only part of the issue

[msobkow]

That's only part of the issue. I didn't learn squat about sysadmin tasks in University, because the focus is on teaching you how to think about software development, not how to use a particular tool or platform -- that's what tech schools are for.

A far bigger issue, as was already pointed out, is the mind-numbing tedium of being a mainframe operator. Alas, the same applies to being an operator on any system, as your main job is to swap media for backups, stock the print servers, and act as remote fingers when support staff call in on a page.

Regardless of platform, the only operators I knew who were happy with the job were middle-aged people who were more concerned about job stability than job challenge/fullfillment. Many of them were highly skilled, knew more about the systems than the developers, and would have made good developers. They just didn't want the pressure and insecurity that comes outside the data center.

As to "learning VB and Office", it sounds more like a tech school than a university. I've never heard of VB or Office being considered part of the programming course on a university campus. I have seen it offered as a half-credit course to help out students who have no prior experience with basic office automation tools, but who need the basics in order to be able to prepare and submit their coursework.

Another issue with getting people to consider a career as an operator is that the job stability is a smokescreen. Who wants to take a job for lower pay, that has little or no challenge to it, requires dealing with pissed-off user managers, and is subject to termination whenever someone gets a brain-fart about "saving" by outsourcing?