MVS TOOLS AND TRICKS OF THE TRADE JANUARY 2007 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. A LITTLE BIT AT A TIME I am very thankful to mention, that this month's installment begins this column's nineteenth year. In that vein, I think it is appropriate to give proper credit to the old-timers in this field, and at the same time, to give encouragement to the newer people. Knowledge of MVS isn't easy to come by. The MVS system (whatever name you call it now--z/OS and so forth--it is still MVS) contains many intricate components, and IBM keeps adding more of them. Nevertheless, MVS is very special, because IBM does not often rewrite its oldest components, and those older parts of MVS (even if changed or improved somewhat) often work the same way that they did many years ago. So much of the old MVS knowledge still very much applies today. For that reason, we have to acknowledge the wisdom of the MVS old-timers, whose expertise was accumulated over many years, through many "wars" and experiences, and by their having dealt with many errors, either their own, or those that were imposed upon them by others. This experience, which cannot be replaced, was acquired over time, a little bit at a time. And every MVS practitioner acquires his or her OWN unique set of knowledge. The knowledge is a mixture of deep system information and "trivial" facts. Sometimes knowing one ISPF setting will save hours of unnecessary work. Other times, you have to have found out about the intricacies of some system control block, in order to solve a problem. Our expertise cannot be classified as "hard" or "easy". It can probably best be expressed as "a miscellaneous collection of stuff." Everybody who has spent a significant amount of time servicing the MVS system, knows this. So now, to encourage the new people. Us old-timers were all new people once. I remember my first systems programming boss "classifying" me as "light". I'm not sure how many people would say that about me today. BUT WE CAN ALWAYS LEARN, and that is the process. The real truth is that each person is "himself" or "herself". And every time we learn something new, we become a BETTER "himself" or "herself". That is one of the most important things we can know, not only in systems programming, but in LIFE itself. The more we concentrate on improving OURSELVES, and the less we concentrate on whether we're "better" or "worse" than the other person, the more accurately we will live our lives. Each of us is DIFFERENT than the next person. We can pick up good pointers and knowledge from them, but we are US, and we are NOT THEM. We NEVER will be THEM. We ALWAYS will be US. I have been fortunate to have had mentors. I have learned tons of stuff, a little bit at a time, from many (more experienced, and less experienced) people. A "less experienced" person is often more experienced than I am, but in a different area. So really, for people who have already had SOME experience, you can't classify anyone. For me, it's just so much joy to spend some time talking systems programming with somebody. I used to spend time on the phone with Greg Price and Bruce Leland and Steve Smith, John Kalinich and Rick Fochtman, and many many others. I've learned a lot of things from all of them. Sometimes what I learned seemed very trivial at the time, but it was "the little fact" that solved the problem which was then facing me. So in retrospect, I have to say that just about everything I know, was acquired a little bit at a time, from books, from other people, and from looking at the operating system itself, using tools. To finish this section, I have to mention that I get (or see) quite a few emails from people in other countries, notably India, who are starting to learn about MVS, and they are in various beginning stages. It is very instructive for me, to watch the progress of some of these people. I remember one guy, who started by asking very elementary questions, and within a few months, he was already doing stuff that I had no experience with. I was very impressed by him. Other people asked questions which showed that they may have had less "geniousy minds", but they were progressing nicely nevertheless. In my opinion, they are all doing valuable jobs. The world needs all of them. And to each of you I say: If you like this job, keep learning things about MVS, a little bit at a time. The knowledge will pay you back! MY EXPERIENCE, AND MY EXPOSURE I feel fortunate, that as proprietor of the free "CBT Tape" collection of MVS goodies, I get to see the many contributions from people all over the world, which come in to me. All of you can see the same stuff that I do. It is all available at the CBT Tape website, which can be easily found by doing a www.google.com search on "CBT Tape". Our website comes out at, or near, the top of the search items. The stuff at the CBT Tape website is all free, and you don't have to have any password or be a "member of anything" to have access to all the materials found there. But there's a difference between my view and yours. I don't have control as to when I get to see the stuff. And I don't have a choice as to what I want to see. If somebody sends something to me, I have to look at it then and there, no matter what kind of MVS tool it happens to be. I don't have a choice. It's my job to look at it, evaluate it, package it, and put it up. Please look at the "Updates page" of the CBT Tape website, so you can see all of the new contributions which have come in recently. I also have to deal with "tool questions" that people email to me. They ask whether we have a tool to solve a problem. Or else, it might be about one of our tools they are already using, which they either can't install, or can't get to work right. I have to deal with that, if and when the question comes in, and in a timely fashion. So my learning patterns are often directed by these considerations. Nevertheless I think you can profit by my sharing some of the things I've recently seen. And you can see that I too, in my situation, learn stuff a little bit at a time. DEALING WITH LEFT OUT DD NAMES As an example of something I've had to deal with recently, I'm deliberately choosing a topic that you don't usually come across as a systems programmer, but as an Assembler programmer. This information took me years to accumulate, a little bit at a time. Why did I pick this particular topic? Because every sysprog will encounter problems that are related to it, sooner or later, even if he or she doesn't do much Assembler coding. DD names are often left out of JCL; programs (and the system itself) react differently, depending on how they are coded, when a DD name is left out. So it is indeed useful for all of us to have some deeper knowledge in this area. When you write a program that OPENs and CLOSEs files, there's always the question of how you can protect that program from bombing when one of its DD names has not been coded in the JCL. Sure, you can just let the system react, but if the program code tries to OPEN (or CLOSE) one of its DCBs when the file is not there (because the DD name was left out of the JCL that executes the program) you'll get a nasty S0C1 abend, with very little indication where it came from. And as the program's writer, you don't want your program to be exposed to such a vulnerability. It's very disconcerting for a user of the program to see a big rotten abend, during what should be normal program execution, or maybe just a simple JCL error. So what can you do to protect the program from something that looks like a catastrophe? We'll deal with this systematically. First, you can test all the DD names in your DCBs that define the files, by doing a TIOT scan to see if the DD name was coded in the JCL at all. The TIOT is created from the JCL. Each DD name in the JCL produces one TIOT entry. And if a particular DD name doesn't show up during the TIOT scan, you know it wasn't coded in the JCL. Therefore, when the DD name is missing, you'll know it at this stage of the program execution, and you can take appropriate action before any further damage is done. If the file has not been allocated, you'll surely not try to OPEN or CLOSE it. A second measure you can take, right after an attempted OPEN, is to test the X'10' bit at decimal 48 bytes off the beginning of the DCB you've tried to OPEN. This bit is on, only after a successful OPEN, so you can see if the OPEN actually worked, and intercept any problems that may have occurred at that point, before the consequences escalate. If you want to see how to code a TIOT scan, many programs in the CBT Tape collection do it. One example is my version of the COPYMODS program from CBT Tape File 229 (at label TIOTSCAN). The IEFTIOT1 macro which describes the TIOT, is found in SYS1.MACLIB. Then there's a third action you can take. This one is more complicated, and requires some setup, but it's often worth it. It's the execution of a RDJFCB macro against the DCB. The RDJFCB macro brings a copy of the file's JFCB (one for each DD name is created at Allocation time by the Interpreter) into your program, and you can examine all the JFCB fields, either before, or after the OPEN. After the OPEN, any specific file characteristics hard-coded in the DCB itself are merged back into the JFCB, so after the OPEN, what's in the JFCB may not completely reflect everything that was coded in the JCL or in the catalog. The program's hard-coded DCB fields may also override your JCL at that point. Executing a RDJFCB against a particular DCB requires adding an EXLST parameter to the DCB, pointing to an area defined by an X'07' or X'87' header list, and a pointer to a 176-byte area in your program which will contain the copy of the JFCB. So it's a bit of work to set up, but once you've done it, it's easy, and it's there in your program for you to use. And it often pays. Knowing all the details of the characteristics of the particular file you're trying to access, gives you a lot of control before the OPEN, as to whether or not you want to OPEN the file, or whether you want to change the way you OPEN it. And (either before or after the OPEN), you can also have your program display many of the file's DCB characteristics at execution time, such as its actual name, the volume it's on, LRECL, BLKSIZE, DSORG, and so forth. Remember that the JFCB was created by the Interpreter (or by Dynamic Allocation), and it contains information about the actual files on your system which the program is trying to access. In skilled hands, RDJFCB is a very fantastic tool. Most of the information about using the RDJFCB macro is found in the z/OS DFSMSdfp Advanced Services manual. Most of the JFCB-related fields are described in the IEFJFCBN macro in SYS1.MACLIB. The JFCB extension is described by the IEFJFCBX macro. One more word about the JFCB before I close. Once you've done a RDJFCB macro BEFORE the OPEN, and you've brought a copy of the JFCB into your program, your program can modify some of the fields of the JFCB and use the copy of the JFCB that's in YOUR PROGRAM to OPEN the file, rather than the copy of the JFCB which the system had created. To do this, you don't execute an ordinary OPEN for the file, but rather an OPEN, TYPE=J. OPEN, TYPE=J has some restrictions, one example being that if you've modified the JFCB for a tape file to force BLP processing, your program has to be APF authorized to do the OPEN, TYPE=J. This is a system restriction, and in those special cases, you have to know about these things, to get them to work properly. (That's what experience is for. And the IBM manual talks about the subject.) CONCLUSION If there's one thing I've learned in my years as an MVS sysprog, it is that "a lot of knowledge only comes a little bit at a time." It is accumulated as you deal with specific situations, and as you overcome the problem that is facing you NOW. Over time, the facts accumulate in your head, and you get a bigger picture of what's happening. In turn, the bigger picture helps you understand more specific details, as you accumulate more knowledge and experience. You shouldn't try to learn too much, too fast. Usually, that doesn't work. But doing it this way, learning a little bit at a time, is a universal formula for success. I can testify to that. And so can almost everybody else. I wish all the best of everything to all of you, and as this column enters its nineteenth year, I'm hoping to see you back here again, next month and beyond.