MVS TOOLS AND TRICKS OF THE TRADE May 1992 Sam Golob MVS Systems Programmer sbgolob@cbttape.org MAKING THE MOST OF YOUR TOOLS. I think it's about time that I do one of those "philosophical" pieces again. I just came back from SHARE, and Dr. Robert Rannie of Northern Illinois University, one of the true "old timers" in this field, gave a gem of a talk on how he trains student systems programmers in the art of debugging. That's not what I'm going to speak about here, but there was a thread of horse sense through his marvelous session, that I feel obligated to borrow from, heavily. Professor Rannie emphasized what all good teachers do: fundamentals, fundamentals, and more fundamentals. "For debugging, look at the evidence of the problem, not in your source, but in the DUMP! YOU think you wrote perfect source code, but the machine didn't think so." "Memorize the most common op codes, so you can follow the program execution in the dump." "Use PRINT GEN, not NOGEN, so you can see what the macro expansions did." "Don't ask for help unless you've done a preliminary analysis, which you'd better learn how to do!" "Ask questions. There's no such thing as a dumb question. If you ask questions, you'll get to think of answers." I need this stuff myself, and I've been around for a while. One can never get enough of this kind of prodding. That's what makes good people out of ordinary people, and masters out of good people. Our current subject will be on fundamentals, too. Repetition is the mother of skill, and we can never have enough. Our subject is: "How can we use our existing tools better". Who am I to talk? Am I perfect? Most definitely not! But I like to observe people and to visit many other shops. Maybe some of the things I've noticed in my travels, could help ME to be a better systems programmer if I wrote them down. You can decide if they just possibly might help you too. PATTERNS AND WORKING HABITS. When I watch somebody else work, I'm struck by one observation more than anything else. There are some actions he or she can do much better than I can. Those skills make me feel utterly inferior to the person I'm watching. And there are other things that I can do far better than they can. I feel like the genius, when it comes to these skills. This has been my observation with almost any other person of some experience level. I have never found a practicing systems programmer who can't overwhelm me in some skill, nor I them, in some other skill. It just goes to show you that there's a lot to learn out there. The trick is to find out how each of us can do a bit better in learning more. I think it has to do with our states of mind. First, let each of us remember how it was when we started in this field. We all felt overwhelmed and uncomfortable. We started learning one thing and then another, hoping our status toward this work would somehow stabilize. When things finally did calm down, and we felt we had a handle on some part of the work, what happened? That's a crucial point in time. Just then, there's a tendency to fall into a pattern and comfortably do our everyday work. I call it a rut, but it's not all negative. We have to drive our newly learned skills into ourselves through repetition. The question is, how long should this "comfort zone" last? Sometimes that's not our choice. There's a new project to do, and we have to learn some new skills. Again we feel uncomfortable until we adjust to the new load, and learn enough to get by and to feel comfortable again. After a while for many of us, things stabilize to the point that we're not forced to do anything fundamentally new for quite a long interval. This is the time that makes a difference. We can either stagnate, or keep stretching ourselves and growing further. I know that most people, including myself, do varying amounts of both. CATALYSTS FOR GROWTH. It often takes a shock to get us moving in the direction of self-growth. Various things have pushed me in my career. Oftentimes I saw someone else ahead of me in a new skill, so I felt obligated to learn that skill. Sometimes I felt myself inadequate in an area of the work, such as debugging, so I forced myself to learn that area better. There were times when I was afraid for the future, so I felt the need to re-train in an area which was indicated by new trends. Finally, there was exposure to a lot of new code, such as when I found out about public domain software contributions, or about some new software tool that our installation bought. I wanted to expand into the new area, and I did. Everybody has experienced these forces at one time or another. What I want to expose here is a new thing altogether, something that very few people take action upon. It is different than all the other factors we mentioned before. But with this, we will be able to attain levels of mastery that are impossible if we just let things float and let circumstances carry us along. If this is made a habit, it will carry us very far. What I want to talk about is "thoroughness of mastery", or making the most of tools we already have. How long has it been since you studied the ENTIRE help member of some TSO command, or an entire section of a manual to master ALL the capabilities of one software tool? Do you know EVERYTHING that can be done with IEBGENER, or IEBUPDTE, or IEHPROGM? Do you know ALL of their control cards? Have you tried experiments with some of their more uncommonly used capabilities? If you haven't, you'd be surprised what lies next to your own front door. If you have, and the possibilities have started to excite you, there's the potential never to be bored again, and to be able to accomplish a lot more than you've ever dreamed possible! EXAMPLES, CON AND PRO. Most professionals use quality equipment. But what distinguishes a master, is mastery over his own equipment. It helps if the equipment is good, but it helps more, the better the user is able to use it. I once was riding on the New York subway, when I saw an unassuming fellow holding a black Nikon camera with a motor drive. Immediately, I went over to him and said, "you're a professional". He was very embarrassed, but he admitted to it. Professional "candid" photographers don't like to be noticed. But the equipment he was using, and the way he was using it, gave him away to me. Some of the great masters of photography have used very simple equipment, such as a Rolleiflex camera with a fixed lens. Many of the most famous photographs of all time were taken with simple cameras and lenses. At the other extreme, I know of a man who had a whole closet-full of the best Nikon cameras and lenses, and who hardly ever took a picture. Some of us complain that "our shops are cheap. They never buy tools for us." Others, who work for big shops with lots of tools, don't make the effort to conquer parts of their abundance. Most of us are at some middle ground, in between. That means there's room for all of us to improve, a lot more than we think! SOME EXAMPLES OF DIFFERENT SHOPS. I've worked at some MVS shops that had VM established there previously, and whose MVS systems were maintained by slightly retrained VM systems programmers. The most striking thing about the working methods of these people, was that they used vanilla IBM tools almost exclusively. They never heard of a CBT Utilities Tape, or a JES2 Mods Tape. Before making fun of them however, I was quick to notice that they knew much more about those IBM tools than I did. It usually turned out that they spent much more time looking at the utility manual than I did. I was embarrassed, and I learned something. For me, it was an improvement, and a lesson in general. You see, these people were forced by lack of MVS exposure, to try and make do with what IBM gave them. And they did remarkably well. Then there's the shop which purchased an expensive monitor for its systems, and all kinds of add-ons to MVS. They have 15 systems programmers. If you'd do a survey of their people to find out how many of them knew ten percent of the commands in OMEGAMON, or whatever monitor they had, it'd be surprising if three out of the fifteen could pass that test. With their monitors and all, could they actually shoot a tough system problem? Maybe one or two of them could. Other big shops do better than this. They really focus on in-house training and give incentives for knowledge among their people. These shops have a higher percentage of their staff who know what's going on, and can help the shop in a tight spot. The true measure of the programmers in all of these situations is: How well can they handle the tools they currently have? HOW ABOUT YOU? Where do you stand? Wherever it is, you can do something about your own situation. There is always the opportunity to learn something new in your own environment. When you ask a question, your mind starts to focus on looking for an answer. If you ask the question, "how much can I do with IEBGENER?" you'll soon find yourself looking at IEBGENER, trying to discover all you can about it. Everyone has IEBGENER. Everyone has TSO. Everyone has SMP. And so you never have to be bored. I have always pushed the idea that people should get some of the free tools. Some cynicism at many people's response to this has caused me to alter my plea to: "Whatever tools you have, learn to use them. Over and over. Better and better. You'll surprise yourself if you are patient, stick to an organized schedule, and keep working at it." Turn introspective. Discover the wealth that you already have. Then branch out later, once you have gotten mastery in an area. This is a good exercise, even to do it for only one tool, for one month. Anyone who takes this seriously, will discover a lot more joy in this work. It's nice to get up in the morning, all juiced up, with the prospect of discovering something new for yourself at work today. No one is so busy, all the time, that he (or she) can't do this for five or ten minutes on some days. Even if you're a strict nine-to-fiver (and there are some of those in our field who are very good), there is still ten minutes of your time to fit in for this, if you look for it. So think about it. No "Tools and Tricks" column is worth much, to a person who won't use the tools. I think I owe you at least one column to devote to this "digression". Good luck. Use your tools well. I'll see you next month.