MVS TOOLS AND TRICKS OF THE TRADE AUGUST 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. NOVEL IDEAS Sometimes a new concept is born, which will revolutionize our technique as MVS systems programmers. Often, this new concept, when taken out of context, does not appear to be overly revolutionary and earthshaking. But it has that effect nevertheless. It is the result of thinking simply, but out of the mold and away from the "usual". For example, consider the idea of doing a TSO RENAME to a large number of datasets (which Steve Pryor talked about a couple of months ago in his Technical Support column). The TSO RENAME command does contain a provision to do a "generic rename" with one execution, but our experience shows that it often fails, claiming the lack of a sufficient workarea. And so, most of us do not often attempt to use the TSO RENAME command to rename more than one dataset at a time. Then what are the alternatives? They usually boil down to making a long list of TSO RENAME commands and executing them either under TSO-in-batch or as a CLIST. So now, the "revolutionary idea" has to enter. It is: What if you write a REXX exec in such a way, that the REXX exec generates the long list of TSO RENAME commands automatically, and you don't have to. That will save you time; it is almost as good as doing a generic rename with the RENAME TSO command, but it doesn't have the downside of the generic rename's unreliability. All the renames get done one dataset at a time. Extend this idea one step further. Why does the concept have to be restricted to running just the TSO RENAME command? Let it generate a long list of arbitrary TSO command executions, against say, all the datasets beginning with a given high level qualifier. Somebody has implemented this idea. It does not seem like a difficult concept to understand. But it does save a great deal of our precious time, and it certainly eliminates athleticism (see last month's column for an understanding of that term). I wouldn't mention this idea if it hadn't already been implemented somewhere, and been accessible to us. We normally don't deal in vaporware here. The "mass renaming" tool is on the CBT Tape collection, in File 635, and its generaliztion, to execute an arbitrary TSO command against all datasets in a LISTC LEV( ) list, is in File 636. These may be found on the Updates page of the CBT Tape web site (accessible with its own URL and also through www.naspa.com), or if a CBT Tape Version has already been cut, with these files included, they will be on the regular CBT Tape page of the CBT web site. The author of these REXX execs has made one additional comment. He tells me that in his experience, these REXX execs not only saved him time, as written, but they also serve as templates and models for writing additional REXX execs to do other, similar jobs. So the bottom line is that this pattern of novel thinking can grow to an abundance of time saving ideas. That's a pattern which is wise to cultivate, in our own thinking and our own approach to this job. WHEN IBM SAYS YOU CAN'T.... It is my experience that a lot of good ideas come when someone says "it can't be done". This stirs some creative juices within us, and we answer: "It can be done, and I'll be the one to do it!" Of course, not everyone is the one to do everything. But if you pick one project that is particularly dear to you, and concentrate on doing the research for it, you will get it done. You will do the "impossible", and you'll do a good job of it, too! Meanwhile, you might have to find someone else who has already accomplished a project that was a little lower on your own priority list, since you probably don't have time to write everything yourself. A good place to look, is the CBT MVS collection that we mentioned above. That is a place where a lot of people share the results of their pet projects, and you can find many tools which do wonderful things that IBM said "couldn't be done". For example, I've accomplished a few things that "couldn't be done" with my own projects. Since I'm the proprietor of the CBT Tape collection, and the collection still does reside on tape, it is no surprise that many of my own efforts have been concentrated around tape manuipulation. For instance, I have done extensive work on a formerly simple (but very elegant) tape copying program called COPYMODS (see File 229 of the CBT Tape collection). COPYMODS was designed to make "Xerox copies" of an entire tape--as many as 10 of them at a time--now I can make 16. Since COPYMODS had a few known limitations, I started by trying to take care of them. In the process, I wound up adding 60 or 70 new features to the program, enabling COPYMODS to do some hitherto impossible things and "go where no tape manipulator has ever gone before". A few things I can do with COPYMODS: I can write out all the tape labels from an SL tape, to an external file. I can then copy the tape to an NL target tape (or as many as 16 of them, if I have enough drives), stripping off any file that looks like a tape label. Then, I can splice all the labels back, sandwiching the NL tape's data files between the appropriate labels (which I may have edited meanwhile), creating a perfectly valid SL tape (or up to 16 of them) as a result. I can also INIT tapes with COPYMODS; I can copy some files from the beginning and stop where I want to. And I can do many more tricks, most of which IBM says you can't do. Another project: I have also produced a full set of utilities, with the help of my friend Vinh Vu, that can handle almost any need you have regarding the user messages in SYS1.BRODCAST. With these utilities, which are perfectly free, you can even back up SYS1.BRODCAST, send it to another system, reload it there, and expand it, together with all the user messages that are in it. IBM says that you can't delete a particular user's messages--only that user can. Our package can do it. Not only that, but you can also delete some of the user's messages and leave some. That used to be "impossible". We (this is in Vinh's part) can also print any user's messages out. We can do many more things too. All of that SYS1.BRODCAST stuff is in File 247 of the CBT Tape collection. The bottom line to all of this is a wonderful fact. IBM might say that you can't do something in the MVS operating system. But they usually provide tools for you to write a program, or a program package, that allows you to do the very things they say you can't do. It's a fact, Jack. IBM gives you the building blocks to make all kinds of novel tools for yourself. And then you'll be able to do whatever they said you couldn't. And an even nicer thing is, that you don't always need Assembler language. Sometimes REXX alone will do the trick very well. The important thing is to know what you want to do, and to think outside the mold. Look at it a bit differently than everybody else has. Get to analyze the essentials of the situation. See what system structures are involved, and find out how to get to them properly and most efficiently. I can show you hundreds of clever examples of what people have written--just look through the files of the CBT Tape to find many tools to do what IBM said "couldn't be done". People suggested these ideas to IBM too, once the deeds were accomplished. And later IBM added their own ways to do what they themselves had previously said "couldn't be done". Many "SHARE Requirements", which are requests to IBM to change, implement, or fix some facility, have originated from user-written works which did the same job first, on an informal basis. Those tools were on the CBT Tape for everyone to see, and then someone suggested the same idea to IBM. GOOD THINGS COME IN BUNCHES Recently I have been amazed by the fact that several people developed similar ideas independently, within a short span of time, and submitted them for inclusion in the CBT Tape collection. I am very happy to see such things occur when they do, and I like to encourage that. We got two automated system shutdown packages at nearly the same time, and we got several DASD space listing products, to mention a few of the things that have happened recently. I always include all versions of all of these similar contributions on the tape (provided that they work, of course), for the following reasons: First, there is cross-fertilization of ideas. Vendors who write software for pay, have a hard time understanding this concept. Vendors tend to hide their ideas from the other vendors, because they want to sell a product that is better than their competitors' products. So the vendors tend to be secretive. They hide their source code, and so forth. But when you write software for free, you don't care that somebody else knows about it. So each author who writes something similar to what the other guy wrote, can look at the other guy's work and improve his own, without worrying that anything might be wrong with such a practice. With free software, everybody can help everybody else, and it's all to the good. Secondly, it's been my experience that two different products which "do the same thing" are both useful, because circumstances will arise when one of them will stop working, while the other of them will still keep working. For example, in the arena of listing DASD space, MVS system changes have recently occurred that render programs which use the IEFEB4UV service useless, while those which use other methods of listing free DASD space will still work properly. So if you have access to several tools to list DASD free space, you won't be completely stuck when one of them stops working on a new MVS release. Therefore, I will put two different programs to do the "same job" on the CBT Tape, and I am happy to do it. I also encouraged the two authors of the MVS shutdown packages to look at each others' work, and they have both done so, enriching their own work in the process. The two automated shutdown packages are on CBT Tape File 588, from Sergey Makogonov, and on File 623 of the CBT Tape, from Hunter Zhou. Zhou also has an AUTOIPL piece too. The two authors use different methods to accomplish the "same result", but it gives us a comfortable feeling to have a choice as to which package to use. SOME ADDITIONAL THOUGHTS In my many years of handling and packaging free MVS software, I have seen a lot of people's opinions. And I have heard lots of people's particular needs for tools. My point of view is different than that of most MVS folks, because of this unique vantage point. And I'm here to help and to share that viewpoint. For instance, one thing I've seen is that there happen to be quite a few shops who are still running antiquated versions of the MVS operating system. Y2K has lessened the frequency of this, but since OS/390 1.3 is probably the earliest Y2K-compliant MVS release, you can bet that there are still a few shops running OS/390 1.3, either for budgetary reasons, or because somebody in management doesn't want to change. So the sysprogs who manage those systems have to adjust their tools accordingly, because they have no voice about upgrading--their hands are tied. Thus, if someone writes a tool that starts working at say, the OS/390 2.4 level--for instance, if it uses the Catalog Search Facility that was introduced at the 2.4 level--then the people at the OS/390 1.3 level can't use it. So the search for a substitute tool that also works for OS/390 1.3 often gets thrown into my lap. Thus it pays for me to know about several tools which do the "same job". Here's another thing I've seen quite a bit of. I've come across people who have spent much of their lives working for software vendors. A few of these people tend to be more sensitive than necessary about looking into other people's source code, or changing it. When you deal with free software, such concerns usually do not enter, but someone with a vendor mentality who is not used to freely available source, may feel that something is not proper, when it actually is proper. Of course it depends on the particular person, but this attitude can sometimes affect the working of a particular tool, if somebody with the ability, is afraid to fix the tool for public use. Free tools are accompanied by a different mentality than vendor-supported tools. Free tools are free to be fixed, in most cases, and that's how they can remain useful to the public over a long period of time. You shouldn't be afraid to fix a free tool, and to submit the fixed code for inclusion back into the CBT Tape. That's for everybody's benefit over the long run. Finally, I'd like share another bit of my experience. At first glance, you might think that I'm "rehashing the obvious", but I have observed that from an MVS perspective, it yields big dividends to dwell on this point. The idea is, we should notice that each person's experience and talents are different from everyone else's. Of course, that's obvious, but what's not obvious, is that a diversity of experience among people is to everyone's benefit, especially when it comes to sharing tools. We should all be thankful that we're all different from each other, rather than complaining that the other person doesn't think like we do. Because of the diversity of people and their experience, each one acquires the expertise to handle a different area in developing tools and techniques. I mentioned before that I was once asked to develop a set of utilities for manipulating SYS1.BRODCAST messages. And everyone else can benefit from that particular experience of mine. Other folks have had other needs, and they have developed tools appropriate to cope with them. To the extent that they have shared these tools, we have all of them available to us. So we have to be very thankful for those other people's different circumstances, because they constantly help us to solve our own problems. So in summary, I hope that I'm encouraging all of you to have your own novel ideas, and to develop them to the best of your own ability. And you shouldn't hesitate to use and benefit from the novel ideas of other people too. Please share some of your own ideas with us, and contribute them to a public collection like the CBT Tape. It's a good world out there, when people help each other. Have a good month, and I hope to see you here next time.