MVS TOOLS AND TRICKS OF THE TRADE AUGUST 2004 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. ANATOMY OF AN MVS BATTLEWAGON During World War II, one of the most feared naval vessels was the big Battleship. The Battleship was the closest thing to being a floating army--it was as big as a medium sized city, and its versatility, in the kinds of weapons it could bring to bear in almost any situation, was almost unparalleled. Proper use of the Battleship in the war, would lead in large part, to mastery and control of the seas. One of these huge Battleships, for whatever reason, was usually referred to in the Military very affectionately, as a "Battlewagon." In MVS, we have a class of tools which are like the "naval battlewagons." They are the great tool packages, which contain a large number of options, parms, or subcommands. One of these tools will be able to perform a large variety of different operations and functions. Such "MVS Battlewagons" come in two categories: There are commercial tools like Omegamon from Candle Corp, and Resolve from BMC Software, and DP Technician from Data Processing Techniques, among many others. And then there are the free "multi-talented" tools that are available to everyone, such as REVIEW from Greg Price (CBT Tape File 134), the PDS program package (CBT Tape File 182) written largely by Bruce Leland and Steve Smith, and which is currently being maintained by John Kalinich, and the free MXI product (CBT Files 409 and 410) from Rob Scott at Rocket Software, among many others. Many of these fantastic free products can be obtained from the CBT Tape collection on the web. Do a google search on "CBT Tape". Today, we'll talk about the kind of mentality that goes into developing a "one tool does it all" kind of tool package. And just as importantly, we'll make some recommendations for the users of such a package, as to how (and why) to become an expert in using the many functions that it contains. WHY ONE TOOL AND NOT MANY? We might ask the obvious question, as to why a developer would want to create one single tool that has many options and choices, as opposed to a collection of many specialized "single function" tools that are separate programs from each other. (I personally have created one large package of each type, so I have some insight into this.) I think there are several reasonable answers. The principal motivation to begin creating what will eventually become an "MVS Battlewagon" might be termed "accessibility to an MVS component." For a program to gain this accessibility, the programming task is often quite non-trivial. For example, the free PDS program package begins its operation by OPENing a partitioned or a sequential dataset, and setting up an environment. Once the PDS program has gained access to that dataset and has set up its working environment, you have a very large choice of manipulations which you can do, like adding more pds directory blocks, changing the attributes of one or more load modules, editing a pds member, and so forth. But the idea here, is that the same coding has provided your basic access to the dataset, and once we have the access and the special environment, now we can "do something." It's a pity and a waste to repeat the (sometimes very complicated) coding which gave you this initial access. A second reason for developing a multi-function package is actually an consequence of "accessibility." To see what I mean, you can put it like this: "The first thing you do is to get into the building. Once there, you can start exploring its rooms." Each particular building has different rooms and a different layout than other buildings have. In two different buildings, there are many completely different areas to explore. And each area of exploration is intrinsically tied up to that building's particular architecture and layout. So similarly, each multi-function package has usually gained access to a component of the MVS operating system or its data. Once there, the creator(s) of the package feel(s) motivated to "make the most" of this exposure to that environment. One asks questions like: "I have access to the innards of a pds. What would be useful for me to be able to do?" Or, "I am reading or copying a tape. I have access to every byte that is on it. How is this useful to me and what functions can I make easy, which previously were hard?" Or, "I know how to access a large variety of MVS control blocks. How can I make that information readily available? Which control block fields can I usefully display, and which, if any, can I safely alter?" An essential additional ingredient in creating a multi-function tool package is to have written a fairly simple mechanism to add new options to the package. If such a mechanism is already in place, then the tool package will tend to keep growing, because the program structure makes it easy to add new stuff. ` For example, in my COPYMODS tape copying program, which is rapidly becoming an MVS Battlewagon in the area of tape copying, tape reading, and tape measuring, I have invented a table-driven parse engine, that converts PARM or SYSIN keywords into option bit settings. Thus, the COPYMODS program can easily use these bit settings to control its various features. As of this writing, I have already used up 45 option bits out of a possible 80. (See CBT Tape File 540 for this parser as a separate entity, and see the COPYMODS program on CBT File 229 for this parser in its practical use.) The free PDS program (CBT Tape File 182) on the other hand, is a TSO command, so it has a big PARSE CSECT, which provides PDS with a fairly easy mechanism to add new keywords using IBM's IKJPARS facility. In fact, all of the big MVS tool packages already have some easy and standard way to add a new feature in, without too much additional effort on the part of the programmer. Now comes the question of why such a big tool package will tend to grow even further. What motivates the growth? What kind of force will cause the programmer(s) to want to include some new features? We can begin answering this in several ways. First, user demand has always been a traditional driver in the further development of MVS functionality. IBM itself is mostly driven by customer demand, when developing new features of MVS. And the tool developers, who pick up where IBM left off, do pretty much the same thing, too. There is a small twist on this when it comes to free MVS software. Somebody who is writing a commercial product ultimately wants to make money. But someone who is doing the development for free, will sometimes include a feature in the product simply for completeness, or "because it is there," or "because he can." So a "Free MVS Battlewagon" might sometimes become better than a commercial product, actually because money doesn't enter into it. However money is a great motivator too, and a commercial developer always wants to create a good and reliable product, that is well supported, and is fit to sell. ILLUSTRATIONS AND EXAMPLES Now I'll show you a concrete case of how a package can start expanding and growing in many directions. Let's take a quick look at the REVIEW TSO command processor program, from File 134 of the CBT Tape collection. The original REVIEW TSO command, found on the CBT Tape, was written by Bill Godfrey around 1980 as a handy, but limited-use, full screen file browser. REVIEW had an enormous advantage, in that it does not need ISPF to function. REVIEW can run under raw TSO in READY mode. Let's get a glimpse at REVIEW from its beginning to the present. In the beginning, REVIEW could only browse a sequential file. A member of a pds had to be expressly specified. You couldn't display a pds directory under REVIEW, and pick out a member to look at. REVIEW could always look at load modules as well as FB and VB files. But originally as written by Bill Godfrey, its width range was only until 1080 bytes. If the load module you were browsing was wider, the old REVIEW would stop looking when it got to 1080 bytes. In the mid-80s, I was tempted to expand the capabilities of REVIEW myself, but I never did so. Then, in 1990, Greg Price from Australia submitted his highly souped-up version of REVIEW to the CBT Tape, and Greg has been improving on the code ever since. The original REVIEW program from Bill Godfrey was around 4000 lines of code. Greg Price's current version (38.0) contains well upwards of 40000 lines of code, and it now even contains a file editor that is not unlike ISPF's editor. A full 32760 byte width is, of course, present in the current REVIEW version. PDS member lists can be displayed. And of course, VSAM and HFS files can be browsed with the new REVIEW too. REVIEW's fantastic facility to look at (and format) SMF files, is world-famous. And you can REVIEW files on tape. I don't have the space here to go through all the iterations of Greg's improvements to REVIEW since 1981, but you can see them in the REVIEW source code on CBT Tape File 134. REVIEW has all the elements that are present in an MVS Battlewagon, though. It is easy to add new options, and if you're working with a dataset browser, there are many new capabilities that you can dream up, using your own imagination and other people's suggestions. REVIEW is definitely a fertile plant that grows in MVS Battlewagon territory. The PDS command package from CBT File 182 is an MVS Battlewagon, par excellence! In 1987 and 1988, I must have spent over 400 hours on the phone talking to (authors) Bruce Leland and Steve Smith, discussing how to use all the 50-or-so subcommand options that were (then) found in their version of the PDS commnand utility package from File 182 of the CBT Tape. The result was a series of tutorial magazine articles in 1988 that was published in "Technical Support" magazine. These can be found in CBT File 182 as members $PDSARTn, n=0,1,2,3. I had been privy to seeing a considerable part of PDS's development, and its growth had followed a typical Battlewagon pattern. Bruce Leland kept incorporating code from other free pds-managing utilities into the PDS package as new options, and Bruce also wrote many other original new utility functions. Steve Smith did the ISPF part. Steve invented the multi-purpose member list, long before IBM (in ISPF) or SPIFFY (from ISOGON) made them. The PDS product grew and grew. Over the years, I can safely say that I myself contributed nearly 200 suggestions for PDS product improvement, which were actually incorporated into both the free product, and its vendor-supported successor (from Serena). I'll conclude with my own experience, by contrasting my tape copying package called COPYMODS (from CBT File 229) with my SYS1.BRODCAST manager set of utilities on CBT File 247. COPYMODS has become a full-fledged Battlewagon, with at least 45 options, as it is currently coded. On the other hand, my SYS1.BRODCAST manager package consists entirely of separate programs, with only Vinh Vu's magnificent ISPF interface, to unify them. Why the difference? ONE BATTLEWAGON VERSUS A COLLECTION OF PROGRAMS I think the main reason why my SYS1.BRODCAST manager utilities didn't become a battlewagon, was the lack of unity with the SYS1.BRODCAST file access and the command parsing. I had found it easier to put separate functionality into separate programs because: First, some of the mechanisms of file access were different in the different program functions. Second, to me the programs were easier to test, when they were separate entities, and third, it was hard to make a uniform parsing mechanism that would encompass all of the functionality required, and it would still work in a simple way. In short, the SYS1.BRODCAST manager stuff just didn't lend itself easily to a unified processing framework. However, I did foresee that some of the separate programs should be unified by an ISPF platform (a "shell", so to speak) that would make them work together. After my own attempt to create such a platform, I saw that my friend Vinh Vu, who is a whiz at that stuff, would be able to create a far better ISPF environment than I could. Vinh's package (which is the BCMISPF member oF CBT File 247) shows a table of all TSO users with undelivered messages, and gives you the option of displaying them, printing them, or deleting all or some of them. So the multi-utility functionality is not provided in one program, but rather in the ISPF dialog that calls some of the separate programs. Others of the programs (BCMSCAN, BCMCLEAN, BCMXPORT, BCMDUMP, BCMREST, and BCMXPAND) are designed to be run in batch. And still others (BCMUSADD, BCMUSDEL) are special purpose TSO commands, which are front ends for the TSO macro service called IKJIFRIF, that adds or deletes single userids from the SYS1.BRODCAST dataset. So in the case of this package, it seemed to me that a better idea than having one program to "do it all", would be to have a shell that calls some of the separate programs. Vinh Vu has created that, and I am very satisfied with the result, because it is easy to use. On the other hand, the COPYMODS program lends itself far better to the "battlewagon concept". Tape copying is one process. You read the tape blocks into a data buffer, and you write them out to output tapes from that buffer. While that one process is being done, all of the tape blocks and tape marks are passing before your eyes, so you can exercise a wide variety of options to determine how you want to change them in the copied tapes, or simply if you want a "read only" run. As you read the input tape, you can format or process any, or all, of the tape label fields as you see fit. I have already dreamt up 45 separate options to run, to vary the controls, and I have more of them on my wish list. So when there's one process of file access (i.e. "accessiblity" as we mentioned before) and there are a lot of different things you may want to do once you've achieved that access, then that situation lends itself very well to the battlewagon concept. But if the various functions required, call for too much difference in the way they are carried out, it is probably better to unify the functionaity in some other way. CONCLUSION I hope that after reading this article, you resolve to learn more about some of the multi-function utility packages you already use, and that you'll start to try and use at least one new package that is freely availalble. I can guarantee that all the effort you put in this direction, will be promptly paid back in satisfaction and saved time. It is granted that you'll have to be "burdened" to learn (possibly many) new keyword controls, but that effort will be paid back to you by a quality high-powered "battlewagon" product. All the best of everything to all of you, and I hope to see you here again next month.