MVS TOOLS AND TRICKS OF THE TRADE OCTOBER 2006 Sam Golob MVS Systems Programmer P.O. Box 906 Tallman, New York 10982 Sam Golob is a Senior Systems Programmer. He also participates in library tours and book signings with his wife, author Courtney Taylor. Sam can be contacted at sbgolob@cbttape.org. Information about the CBT MVS Tapes can be found on the web, at http://www.cbttape.org. MVS KNOWLEDGE Sometimes I ask myself: "Just what have I learned in my 25-odd years in this field?" And when I really think about it, the answer is complicated. That's what I want to talk about today. With so many of us so-called "old timers" approaching retirement age, and with the IBM mainframe still extremely vital in today's industry, we have to ask the question about how we're going to groom new people to take care of the systems. So it makes sense for each of us to ask questions about "what we really know." Every person has a different head. So it makes a lot of sense that each of us has followed a different path in acquiring the MVS knowledge and practical know-how. I for one, went to a "computer programming school" and I also acquired some programming knowledge on my own. Later, I "grew into" a systems programming job, on the job, after having been a COBOL and ASSEMBLER programmer for a couple of years. Many other MVS sysprogs started as computer operators, and grew into systems programming after displaying a curiosity to understand what was inside the system they were operating. What were the guts of the system like? And maybe they also had ambition to make more money too, at a more skilled job level which was less boring than just operating the machine. Sysprogging is certainly a giant step up from computer operating, and it's a good opportunity for a bright person. Other people followed different paths--some were engineers before. So each person's mental makeup and background forms the patterns he or she will use, to angle for the knowledge necessary to build and maintain an MVS system. With all these differences, where is the common ground? Actually, I might want to answer this by saying that the knowledge itself is the equalizer. There's a certain core of knowledge and skill that everybody has to have. You have to know quite a bit about TSO and ISPF. You have to know at least something, about how SMP/E works. You have to know about datasets on MVS, and all the different data types, and about data management. You have to know about how programs work, and about how programs use system services. Nowadays, you also have to know about UNIX, and how to mount file systems and how to set up UNIX under MVS. And you have to know about the general processes of "moving datasets around" in order to be able to install software. Then also, you have to know about load parms, and PARMLIB, and about how the system starts up. And you have to be able to set all of that up, with a knowledge of which PARMLIB members need to be adjusted to give the system the proper tools to do what the installation needs it to do. After all this, you need a general knowledge of each system component, how it works, and how it interacts with the other system components. But that's not enough. You also need to know how to set all the components up, individually. So you need to know all the datasets they need, how to configure them, allocate them, and resize them. A basic knowledge of how system dataset placement affects system performance is also a must. You don't want to put a dataset that constantly gets RESERVEs on it, together with frequently used system datasets, together on the same disk pack. I mean c'mon, that's a "no no". And you've got to be aware of such issues. Experience is the best teacher, and acquiring experience takes time. Also, you often have to have an "issue" before the opportunity to acquire the experience presents itself. Suppose your installation is having a certain performance problem and you've been assigned to curing the problem. You have to find out why the problem occurs, which MVS components are affected, and in the process of doing that, you'll learn a bunch of "do's and don'ts". Those "do's and don'ts" then become an essential part of what you have to know. Each person builds up a collection of these cumulative experiences, and getting that knowledge takes you to the next level. You depend on your everyday tasks to enable you to deal with whatever may come up later. IBM itself has recognized that it needs to address the "training issue" for MVS sysprogs. When I broke into the field, the IBM manuals were a hodge-podge. There were maybe a hundred MVS books, and in order to find out something practical, you often had to look in four or five separate books and put the bits of knowledge together yourself, to be able to address even a relatively simple problem. Now, the books have been reorganized to put "practical information about a topic" together in one place, and IBM has also come out with its excellent multi-volume Redbooks, "ABCs of System Programming." The advent of the Redbooks in general, has allowed us to concentrate on learning one topic at a time in a practical way, and they have made our lives much easier. Then there's the big question of tools. When I started, I had to learn about all the basic IBM utilities and tools for MVS. After that, I found out that many IBM-supplied tools left much to desired, with their lack of user-friendliness and lack of scope. So I had to find out about, or write, many system-level tools myself. This involved much research and Assembler language programming, and it got me involved with the magnificent free collection of MVS tools known as the CBT Tape, from Arnold Casinghino at the (now defunct) Connecticut Bank and Trust Company. You almost can't be a systems programmer without knowing about the CBT Tape collection, where you can get everything for free. The CBT Tape collection is now online. Just do a www.google.com search for "CBT Tape", and the website for the collection should come out near the top. But this is just the beginning, and when I ask myself what I have been doing for 25-odd years, I have to answer that I have constantly been adding to my knowledge of the system, and to my knowledge of the necessary tools to handle problems and get information about each component of MVS. It's really very involved. I guess I've learned a lot. INDIVIDUAL APPROACHES As I said before, each person has his or her own head. So the special individual mental qualities which each person has, will contribute to his or her approach in learning this field. The bottom line in MVS systems programming, is to know as much as possible about how the operating system works. Each component is deployed at system start-up, and each gets its own control block information initialized, and each component is designed to interact in necessary ways, with some or all of the other components. You've got to find out about this, and you also have to find out how to fix it, if it's broken. My own teacher, Bill Mosteller, who wrote a book called "Systems Programmer's Problem Solver" has an introduction in the book from Gerald Weinberg, who likens sysprogging to being a soccer goalie. Most of the time, the action on a soccer field is not near the goalie, but he must always keep a vigilant eye on all the proceedings, and when the action gets near him, he must do everything he can to anticipate any problems and avoid them at all costs. Most people who watch a soccer game don't spend too much time looking at the goalie, unless he (or she) makes a good save, or gets the ball into a good starting position for his team. Nevertheless, no one would argue against the fact that the goalie's position is perhaps the most important position on the team, and without the goalie doing his or her job, the team wouldn't have much of a result. Same with the systems programmer, who installs the system and who must always be vigilant to prevent and fix problems. The systems programmer is also the last line of defense. So as an individual, what do I myself do to learn about the system? For myself, I am a big believer in exposure. I find that my head picks up what it sees. So I'll take a glance through the member lists in SYS1.LINKLIB, SYS1.CMDLIB, SYS1.MACLIB, SYS1.MODGEN, and the like, getting exposed to what the member names look like. I won't spend tons of time doing this, but at least I'm getting familiar with what names the programs and macros have. Most people don't find it practical to do that, but I do. When a system problem will occur that affects some component, I'll already have a bit of familiarity with some of the individual pieces which make up that component. I find that this will help me solve problems more quickly. It works for me. Somebody else I know, only reads manuals. Give him a manual, and he's a happy camper. When I worked with him, I tried to talk to him about my own techniques for learning about the system, and it was like talking to a wall. His head just didn't work that way. But he was a very effective and successful systems programmer nevertheless. He followed the directions in the manuals, and he was able to learn everything he needed to know, to do his job. He just didn't come up with the really creative and innovative and "off the wall" things that I tended to come up with. The shop needed both of us. And similarly, your shop needs you. If you have experience in this field, you already know something about how you approach things and how you try and learn new things, when you have to. Most people who are experienced, have a pretty good handle on their techniques. But I would say that maybe you should try and learn a few things once in a while, that you DON'T HAVE TO. You should stretch your mind a bit--go into the unknown. Look up something that's in some random area which you don't know about yet. Especially if you have a bit of free time. This is the kind of innovative activity which separates the "creative ones" from the ordinary people who do their job well. I think that you should spend some of your "free" working time "doing your own creative thing," as long as it doesn't interfere with your regular work. Done right, using your own individual head will add immensely to your effectiveness in the shop, and it will be a source of much benefit and satisfaction, but you've got to be careful to do it intelligently and not counter-productively. Don't work on something optional, when you have to be busy with some assigned task. Remember that you also learn tons, and get most of your good experience, while you're doing your assigned tasks. The optional stuff is only something you do, when "the action isn't on your side of the soccer field." And it's only a suggestion, not an obligation. If you stick to your obligations, you'll always be safer. THE BOTTOM LINE I think that the bottom line in all this, is to always try and add to your knowledge, and don't ever mind repeating some of your tasks which are routine. Repeating a task drives the techniques into your head. It is a rare piece of wisdom to know, that repetition of a task (in our field) is goodness, most of the time. Repetition makes a task second nature, and much of our effectiveness in deploying our knowledge, is that most of our actions have become second nature to us. Nevertheless, in some sense, a good sysprog should also let the computer make him or her lazy. If you use good tools and shorten the work, then the work gets done faster. It makes sense. So there's a balance between accustoming your head and your fingers to be able to work quickly, but you also shouldn't take the slow road if there's a fast road available. Again, the bottom line comes down to using your head and always acting intelligently. It's just like driving a car. When you're driving, you always have to be alert, make good decisions, and act responsibly. Same with sysprogging. That's how you'll be effective at this job. In a short space, I've had to try and summarize what goes into the making of an effective MVS system programmer. It does take a lot of experience in doing tasks and learning about the system. You have to take as much advantage as possible of your own talents. An "I can do whatever it takes" attitude is one of the most important things I've come across, too. But mostly, it's a willingness to keep learning about the system and about tools. It's a desire and a curiosity to learn about how the system works. And you have to mix in common sense, to protect your employer's environment. When I think about it, I suppose I've come a pretty long way in 25 years. So I wish all of you heaps of good luck and success in all ways. And I hope very much, that you'll come and visit here again, next month.