MVS TOOLS AND TRICKS OF THE TRADE MARCH 2002 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. GLOSSARIES I for one, have often gotten the sinking feeling nowadays, that this field is running away from me. I've been doing this stuff (MVS sysprogging) for many years. I have much hard-won experience and knowledge. I know loads of tricks. And yet, when I see the new developments sprouting up like mushrooms all over the place, I often wonder if I can even think of an approach, how to keep up with all of them, even in a general way. Today, I'm going to tell you about a method that I've recently discovered myself. It's really simple and obvious. However, there are several zillion reasons why people don't do it. But I have resolved to personally adopt this practice, and I will not keep it a secret (much longer). Just about every IBM manual contains a section at the end, known as the Glossary. By definition, a Glossary is like a mini-dictionary. It is a short definition of terms, which the author(s) of the manual assume, that every reader does not know. So these special terms, acronyms, and technical expressions are defined, as they relate to the contents and context of the material in that manual. I've mentioned that there are several (zillion) reasons why people generally don't go about reading the Glossary of an IBM manual. A few of them are: 1. When they were children, they were told: "Only weirdos read the dictionary." 2. It's "boring". 3. If you are new to the field, you don't know hardly any of the terms, and reading the Glossary feels like reading a bunch of nonsense. These "reasons" may be countered by: 1. Think to yourself: "Who is forcing me now, to pay any regard to the things that some child told me, when I was a child? In fact, who was forcing me even then, to listen to that idiot?" (No one.) 2. Things you have a vested interest in learning about now, can't be too "boring". 3. Our experience shows that reading glossaries is most effective, when you already know the meaning of at least 60 percent of the terms. The Glossary just fills you in, on the few terms you don't know, and enlightens you better, on the ones you do know. A Few Obvious Things About What's in a Glossary Each IBM manual containing a Glossary, will define all the terms, only in the context as they relate to the material in that manual. For example, the acronym "SCDS" will be defined differently in an SMP/E manual, or a DFSMS/MVS manual. In each of these contexts, the term SCDS means a different thing, unrelated to what it means in one of the other contexts. Sometimes a Glossary contains misprints. I've seen manuals which mistakenly combined two separate dictionary entries into one paragraph. This is the fault of the print formatting software, or how the editor of the manual has used it. You have to use your head, at all times, when reading glossaries. You can't expect the Glossary to provide great detail. Only a bare definition is usually provided there, but it can be enough to get you enlightened on the subject. A technique to find more information about a word or expression, is to look it up in the Index of the same manual, and the detailed textual information describing the term and its use, will often also be pointed to, by that manual's Index. What Do You Expect to Gain? Have you ever felt really ignorant when talking to somebody about one of the new areas of MVS? If someone is talking TCP/IP to you, and you haven't dealt with TCP/IP much, it can be very embarrassing to admit that you don't know what they're talking about. If you're familiar with TCP/IP, just substitute some other new area of MVS, OS/390, or z/OS that you're not familiar with. Imagine talking to somebody and being very embarrassed. If you've gotten used to our "Reading the Glossary" technique, this difficult situation will happen to you (at most) only once. As soon as the first person has embarrassed you by talking about some new area you're not familiar with, you'll go to the Internet or the IBM cd-rom manual collections, find a manual relevant to that subject, and you'll read all the way through its Glossary, and maybe also the Introduction and the first chapter. That embarrassment will never happen again. It may take awhile for you to be able to be "talkative" about that subject, but at least your face won't turn red. This practice will be very useful when you attend SHARE or one of the other conferences. In such places, a lot of people can talk about many areas you don't have experience in. By reading the appropriate glossaries later, you can quickly broaden the areas of your exposure. A General Observation about "New Developments" Anybody who has written a new program with new functionality, realizes that to describe what's happening, new terms have to be invented. For example, I've been privileged to add about 30-odd new options to a formerly simple tape copying program. I'd bet that very few of you, in the audience, know what a LABLDUMP or a LABADDIN, a CHGVOL, or a LBDQUICK operation is. However, if I tell you in a few words, what new function my utility was trying to accomplish, just about all of you would clearly understand all these terms, in two minutes' time. Let me explain. The new terms I've mentioned above, pertain to a tape copying program called COPYMODS, which can be found on File 229 of the CBT MVS Utilities Tape. As COPYMODS was originally written, it was (and is) a tape copying program. COPYMODS makes exact copies of existing tapes. Its operation is as follows: The input tape (and up to 16 output tapes) are OPENed. A block of data is read from the input tape to a buffer area in the program. Then the same block of data is written out from the buffer, to each of the output tapes. The program (as it originally was written) stops, when it sees two consecutive tape marks in the input tape. Initially, this program was very simplistic, and it worked wonderfully, but it had some severe limitations. The main problems with COPYMODS come, when dealing with Standard Labeled (SL) tapes. COPYMODS runs using BLP (Bypass Label Processing), so it considers tape labels the same as any other data. Therefore, if COPYMODS would make copies of a SL tape, it would exactly copy the labels too. Therefore, the VOLSER of the output tapes would be exactly the same as the VOLSER of the input tape. This makes some difficulty on an MVS system, and it is inflexible, in a situation where you'd want to copy the data from one tape to another, but you want the output volume serial to be different from the input tape's VOLSER. So to solve this and other problems, I had to "teach" COPYMODS all kinds of things about Standard IBM Tape Labels. I "taught" the program to detect VOL1 labels, and HDRn, EOFn, EOVn, UHLn, and UTLn labels on the input tape. Now I can start explaining all the new terms I invented. They are easy to understand, once you get the idea what I was trying to do. And the same principles apply, when you're trying to understand some new functionality, program, or system, which IBM has written. Once you get the general idea about what IBM was trying to accomplish, you'll also get to easily understand the new terminology IBM has invented. And you can do the same thing backwards. By understanding the basics of the new terminology, you can then "read between the lines" and figure out what kind of new functionality IBM has created. So let's get back to COPYMODS, and I'll explain the CHGVOL term. Suppose you wanted to copy a tape, but you wanted the VOLSER of the output tapes to be different from that of the input tape. With the new COPYMODS, you can code PARM=CHGVOL. This will cause COPYMODS to write any new VOL1 label on the output tapes, to match the VOLSER that was coded in the JCL to create that output tape, instead of taking the VOLSER "mindlessly" from the input tape. By reading this definition, knowledgeable MVS people will also infer that I must have gotten the volume name information from the JCL, by doing a RDJFCB on the output tape, before or after I OPENed it. All this knowledge came from learning the definition of the CHGVOL term. See my sample Glossary in Figure 1. Now let me explain LABLDUMP, LABADDIN, and LBDQUICK. These terms were invented, because I wanted COPYMODS to be able to copy a complete set of Standard Labels from the input tape, out to a file. Then, after making an NL copy of the same tape (with my COPYSLNL program), I wanted to be able to resplice the set of labels in the file, back into the NL tape, to create an SL tape again. Today, you probably can't find such functionality in any other product, for free or for pay. That's why I invented these new terms. To copy all the labels from a Standard Labeled tape to a file, you code PARM=LABLDUMP in the COPYMODS EXEC card, and include a //LABLDUMP DD card to define the output file that will contain the set of labels. That's what LABLDUMP means. Now, to explain LABADDIN, it is the opposite operation to LABLDUMP. This happens when the input tape is Non-Labeled, and you want to splice a set of labels (previously created by a LABLDUMP operation) back in. You code PARM=LABADDIN in the EXEC card of the COPYMODS JCL, include a //LABADDIN DD card to point to the file of labels, submit the JCL, and you can create up to 16 output tapes, Standard Labeled, with your new labels spliced in. Now let's explain LBDQUICK. It's the same as LABLDUMP, and it requires the presence of a //LABLDUMP DD card in the execution JCL, except for one thing. You want to read an SL tape, and copy the Standard Labels out to a file, but you want to do it "quickly". (Let me interject that I've also put PARM=READ into the COPYMODS program, so it would only read the input tape without making copies.) So how is LBDQUICK different from LABLDUMP? LABLDUMP reads the entire tape, including the data, because when you're executing COPYMODS with LABLDUMP, you're usually in the process of making copies of the input tape, at the same time you're copying out the tape labels to a file. Suppose now that the tape contains a million short blocks, and only one file. (I have created such a tape. The program to do so, is also on File 229 of the CBT Tape.) If you only want to extract the labels from such a tape, the MVS system has to do I/O's to read every data block, before it gets to the end of the tape. This might take a long time. So I invented the LBDQUICK process to be run with COPYMODS when you also do PARM=READ, so it skips reading the data file, and gets to the labels themselves, more quickly. Now that we've explained these terms here, please look at Figure 1, where I've created "Glossary entries" to define them. You can judge for yourselves, if my Glossary helps you understand what is going on. I hope that this month, I've given you a little more insight, and another "angle", to help you in keeping up with developments in the MVS field. Best of luck to all of you, and I hope to see you again, next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. A Sample Glossary for the COPYMODS Program CHGVOL - A PARM or SYSIN option of COPYMODS, which causes COPYMODS to take the Volume Serial of the output tapes from the VOL=SER=volser name in the execution JCL. COPYMODS - A program, with many options, to copy tapes. COPYMODS can read an input tape and create as many as 16 output tapes at the same time. LABADDIN - A PARM or SYSIN option of COPYMODS, which takes a Non- Labeled tape as input, together with an external card- image file of tape labels, such as those created by a previous LABLDUMP operation of COPYMODS. Output tapes are Standard-Labeled, created by splicing each tape label set from the external file, around its corresponding data file of the Non-Labeled input tape. This parm requires a //LABADDIN DD card which points to a card-image (FB-80) file containing a set of tape labels with control cards, such as those created by the LABLDUMP process. LABLDUMP - A PARM or SYSIN option of COPYMODS, which copies all Standard Labels from the input tape to an external file. Extra control cards are created in the external file, to delimit each set of individual file labels. This parm requires a //LABLDUMP DD card which points to a card-image (FB-80) file. LBDQUICK - A PARM or SYSIN option of COPYMODS, intended for use together with PARM=READ, which copies all Standard Labels from the input tape to an external file, skipping the read of the tape data in between the labels. This parm requires a //LABLDUMP DD card which points to a card-image (FB-80) file.