MVS TOOLS AND TRICKS OF THE TRADE NOVEMBER 2003 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. MAKING LIFE COMPLICATED One of the typical emotions that I feel in the MVS sysprogging business is: "Aw nuts. I have to learn a whole bunch of these new things." It's true. Every new component or utility that I have to learn to control, comes with its "instruction book" or as we say, "documentation." Each new piece of software has a vocabulary associated with it. There are keywords to learn. A certain keyword controls each piece of functionality. Sometimes these keywords are intuitively obvious, and the product is easy to master. Other times, they are horrendously new, as in the case of SMP/E, which contains controlling keywords that seem unrelated to anything that you already know, unless you're a real old-timer who remembers how to perform an MVS SYSGEN and apply PTFs the old way. Now let's put the shoe on the other foot. Imagine yourself as the software writer. You've written a piece of software to do a certain job, and you've written it to specifications. The software has to be usable, so you have to put someone in the driver's seat, who's going to use it. You have to give him or her the controls. What will they be? You have to decide that. In some cases, you have to invent them from scratch. As a software writer, I have had to do that. So therein lies the source of the "complication". The software writers have to create the controls to manage their software products' operations. And the users (in this case, US) have to learn to manage the beast, using whatever control mechanisms that the software writers (or their managers) have decided to invent. And usually you can't change things to your liking. All of the keywords and their meanings are hard-coded into the programs. You just have to accept them and use them as-is, or you don't get to manage that software product. So in summary, our life consists of learning how to use a lot of mechanisms and keywords that other people have invented. This makes our lives complicated. AN EXAMPLE FROM THE WRITER'S POINT OF VIEW I count myself fortunate to be on both sides of the fence. I am a software writer as well as an MVS sysprog. I have had to "create the beast" as well as having had to learn about beasts which others have created. Let me show you some keywords which I have had to invent, and the decision process which went into creating them. I have had to make the new words as intuitively understandable as I could. But on the other hand, I couldn't make them exactly the same as the words which were in other products. Perhaps I could have done a better job creating these words, and my software product would be easier to learn. I don't know, but I tried my best. It's really up to the users to make that judgment. Although I have written other things, I'm choosing the COPYMODS tape copying program (from File 229 of the CBT Tape collection) to write about. The reason for choosing COPYMODS (besides beating a dead horse--I've written about that program a lot in this column) is because I invented new functionality there, plus the ability to run the program in at least 30 different ways. This versatility necessitated the invention of new controls. And new controls meant more new keywords for you to have to learn. Sorry, guys! Anyway, look at the situation from my point of view. I'm trying to do anything you'd ever want to do while you're copying a tape. And I'm basking in the euphoria of BLP processing, where tape labels mean nothing special, and they're "just files" like any other tape files. I asked myself a question (ridiculous to most people--but from my angle it made perfect sense--this is the design phase, where the imagination can run rampant). The question was: "Could I copy a tape, but only copy the labels and not the data?" Of course I could. BLP processing in MVS ignores the labels as being anything special. If my program could recognize a file as being part of a tape label set, as opposed to being other data, it could easily be made to copy only the labels. Then the realists pipe in, and ask: "What kind of a tape would that give you? It'd be one with all labels, and no data." Maybe it'd be like a tape filled with null standard-labeled files, but the block counts would be wrong in the EOF1 labels, and the tape mark pattern would be wrong. MVS wouldn't be able to read it as a normal tape. So as the designer I ask myself another question: "As far-fetched as this scenario sounds, does it have a real and practical use?" I actually got a positive answer to this question, and it led to the invention of some really useful functionality in the COPYMODS product. The answer was: "Don't write the labels to an output tape, but rather write them to an external FB-80 disk file." That would accomplish two things. First, it would enable you to see all the tape's labels more easily. Second, if you'd somehow be able to strip the labels from the original tape in a copy operation, so you'd create a non-labeled tape out of the original, but you still had possesion of the physical labels separately, maybe you could splice them back after editing them, and create a new standard labeled tape. This operation would have a lot of potential practical use, such as being able to rename the tape datasets in a copied tape. I actually did it and got it to work. But I had to invent the controlling keywords. What should I call a "label dumping" operation when copying or reading a tape? I decided to invent the keyword LABLDUMP. It describes the situation, and it intuitively makes sense. But it's different from anything that's in any other product, and it gives you something else that you have to learn. In the COPYMODS program, LABLDUMP is not only a PARM or SYSIN keyword. It actually has to be a DD name also, to describe the FB-80 format file which will receive the label images that were read from the tape. Do you like my choice of the LABLDUMP keyword to control this operation? I could take a poll and ask your opinion. But the truth is that I have already written the product and decided on the keyword. People already have "production JCL" that uses this keyword. It can't be changed. Tough noogies. You have no choice! Sorry. Actually, in COPYMODS, I can add a synonym, or another keyword that means the same thing as LABLDUMP. But that would give you two more things to learn instead of one. Life is still complicated. What about the opposite operation of taking the external images of the labels and splicing them back into a non-labeled (NL) version of the same tape? I had to decide on a different keyword to describe that. I called it LABADDIN. This keyword is not only a PARM or SYSIN keyword in the COPYMODS program. It is also the extra DD name where you have to put the set of labels that you want to splice into your non-labeled tape. So if you want to use my product in this way, you have to learn two new words: LABLDUMP and LABADDIN. If you don't (or won't) learn to use them, you'll be deprived of using the label dumping and label adding functionality in the COPYMODS program. Can you get around that? Maybe there's some other program which does the same operation. But if it exists, and you can get (or buy) it, that program would also have its own special keywords that you'd have to learn. You can't get around the basic problem. You simply have to learn new keywords, and that's that. WHAT'S BEHIND OTHER FUNCTIONALITY? I was just looking at IBM's "Using Magnetic Tapes" manual on page 6. There, the manual describes the definition of attributes in a new dataset to be LIKE an old dataset, using the intuitively obvious LIKE keyword to point to a model DSCB. (A model DSCB is a VTOC entry that doesn't point to a real dataset but just contains dataset attributes.) What struck me was that the LIKE keyword doesn't copy ALL the attributes in the model DSCB but only some of them. The manual describes which attributes are copied and which are not. But the bottom line is that LIKE definitely does not mean "exactly like". There's more to this than meets the eye. What you see in the manual, reveals what was programmed into the product by the programmer. And if you read the manual carefully, you can figure out why it was done that way. What is not so up-front, is HOW it was done. But once you get that, you will definitely have a completely revised insight into the way MVS is constructed. A model DSCB is simply a VTOC entry, a FORMAT 1 VTOC entry to be exact. Fields in the VTOC entry describe the RECFM (record format) of the dataset, the LRECL (maximum record length) of the dataset, BLKSIZE (maximum block size), and so forth. It used to be that when you would refer to a model DSCB to describe dataset attributes, the older MVS systems would use more of them than nowadays. For example, if the model DSCB contained a specific block size, then that block size would have been copied to the dataset currently being OPENed, if it were not overridden via JCL, or overridden by having been filled in previously. But nowadays, with MVS functionality attempting to optimize disk utilization automatically, the manual says that the block size attribute is not copied from the model DSCB using the LIKE keyword. Neither is the expiration date copied, in most cases. So again, LIKE isn't really "exactly like". Programming-wise, what is happening is that the system program points to the location of the model DSCB on disk, and pulls the contents of the various fields out, probably using MVC (move character) instructions, moving them to fields in the DCB, and possibly the JFCB control blocks. When LIKE is invoked by the person running the JCL for the job, MVC (or similarly effective) instructions are invoked for only those fields of the model VTOC entry which are appropriate to the situation, and are not invoked to copy the other fields in the model DSCB. So when you code LIKE in some JCL, you are not specifying that every field in the VTOC entry will be used--only some of them. What you see here may be described as a kind of synergy between the programming specifications, what is in the manual, and the instructions that were actually coded in the system programs. Which came first? Usually the specifications and requirements came first. Then the program(s) were coded appropriately. And finally the manual describing how to use the program(s) was written or updated accordingly. But my point is that from our point of view, we usually see the manual first. Then we figure out what the programming specs probably were, and finally we get an insight into how the program was probably coded. The programmers do it one way, and we, the users, have to figure it out in the opposite order. So finally, I've made my point for the day. I feel that it is up to us, as MVS systems programmers, who are really "educated users" of system programs, to get a feel for how it is on the other end. What do the programmers of the utilities we use, have to go through? Then, when we've started to see our world through the programmers' eyes, we'll get to be more patient, and more tolerant of the learning process that we have to go through almost every day, mastering the use of so many keywords, instructions, and directions. I hope that in today's article, I've made it easier (mentally) to approach our daily duties. Much of what we do, is learning how to use new tools, or learning new features of old tools. So by placing ourselves in the programmer's mind and thinking about it, we'll see that we are really the ones who "got away easy". Best of luck to all of you. I'll see you here again next month.