when relevant content is
added and updated.
SAN JOSE – One of the more popular sessions I attended this week at the Share user group conference was called “Things a Mainframer Needs to Know, But No One Ever Tells You.” The panel was a group of mainframe professionals who had been in the industry a while. A lot of the audience members, meanwhile, were newbies to the platform.
So here’s a quick rundown of their suggestions:
Documentation. From Mickey Scott, a senior IBM WebSphere software engineer (sarcastically): “So you’re the new guy. Ideally your environment is well documented by everyone there.” The reality is that may not be the case. So you need to start examining where everything is. One key suggestion from Scott was to look at the syslog.
“That’s all you need,” he said. “You should go through the whole log and see what happens when things are normal, so when you are asked to look at a problem, you don’t go chasing some message that is normally there.”
Start building your libraries. This doesn’t just mean manuals, although it does include that. It should also include MVS system codes, printouts of IBM Redbooks, JES2 commands, and JCL scripts. The list goes on and on. And the panelists recommended at least downloading them to a place that you can access even if you’re network connection is down.
Monique Conway, a technical lead for Tivoli software products, added that it’s a good idea to start saving all your JCL scripts. If (and she stressed if ) your company allows it, take those scripts home with you. Why?
“If you’re new to the mainframe, and this is your first job as mainframer and you’re spending all this time building up your JCL, then you go to another job, all that work is gone,” she said. “So when you build it up, take a copy and bring it home.” Again, she said, if your company allows it. If it doesn’t and you do it anyway, you may soon be looking for a new job.
Learn your acronyms. One of the audience members suggested this, saying that you should document all your acronyms and how to pronounce them. You’ll want to know that RACF is pronounced “Rack F” and not “R-A-C-F.” Scott chimed in that IBM tends to have a RAG in their organization — that is, a Random Acronym Generator. Yes, that sounds about right.
Learn how to work with IBM and other vendors. It’s probably best if the first thing you say to a vendor is something that I can’t print here. As one panelist put it: “A large part of what we do is deal with vendor problems, or problem vendors, depending on how you think of it.” Some key points to having a successful session with vendor support:
- Determine the true severity level of your problem, and not just the severity level that you (or your manager) thinks it is. You don’t want vendors to think you’re crying wolf all the time.
- Have your information at the ready: problem type, what happened, when it happened, and anything you’ve already tried to do before contacting them.
- Play nice, but at the time, be persistent if need be. The vendor might tell you that no one else has told them of the problem you’re having. A good answer, according to Steve Conway, the lead sysprog at Freddie Mac? “Somebody’s got to be the first to find the stuff.”
Learn Assembler. Although you don’t absolutely need to learn Assembler to be a mainframe system programmer, it can help when doing problem resolution because you’ll be able to read the system dumps and, as one panelist put it, can be the difference between being a systems administrator (which he likened to a janitor) and a great systems programmer.
Join Toastmasters. Eventually you’re going to have to give a presentation. Eventually you’re going to have to convince a manager to buy new hardware, or upgrade your software release. So it’s probably a good idea if you learned how to speak in public.
And finally: Get a big monitor. In this day and age of multitasking, the bigger the monitor, the better. In fact, get two monitors if you can get away with it.