MVS TOOLS AND TRICKS OF THE TRADE November 1989 Sam Golob MVS Systems Programmer sbgolob@cbttape.org NO-COST SUBSYSTEMS: TSSO, ETPS, AND CMD1 This month, I would like to begin with an endorsement for a unique book, which has helped me for years in my own career. It has recently come out in a second edition, and is available at a discount to NaSPA members. The book is entitled, "The Systems Programmer's Problem Solver", by Bill Mosteller, who worked as an MVS Systems Programmer for many years, with a good reputation. Now, Bill has gone into VM, and he works for Systems Center in Virginia. (I think he still has a good reputation.) "Systems Programmer's Problem Solver" is published by QED Information Sciences in Wellesley, Mass., and NaSPA has an agreement with them for a 15% discount to members. They have an 800 number, 1-800-343-4848. The book is composed of tidbits of good advice to people in our field. You do not have to work in MVS to benefit. As a matter of fact, when I first saw a copy, I was a DOS applications programmer. But its down-to-earth approach to the everyday realities of the programming life, hits home in many ways. Of course, the MVS SysProg will be in tune with the book on all cylinders, and will benefit directly from every page. IT'S MADE FOR US. But ALL programming personnel will empathize with the points Bill makes, and the stories he tells will strike a receptive chord in the heart of anyone in this profession. So I am going to (uncharacteristically) urge you to go out and spend a few bucks, and buy the book! It's practically guaranteed to multiply a return on your investment, if you count money saved for your company, "Brownie points" for you with your management, and a general increase in your satisfaction, that you're more competent and confident to do your job. HOLD ME TO IT. I don't expect (m)any complaints. * * * * * * * * * * * * * * * * * * * * Please note an important announcement as part of our topics for this month. It concerns the Connecticut Bank and Trust (CBT) MVS Mods tapes, which have saved my company hundreds of thousands of dollars over the past few years, and which should be a mainstay of every MVS System Programmer's arsenal. The hundreds of programs and software packages on these tapes, ALL PUBLIC DOMAIN, have provided tools to implement many of the suggestions in this column. Many of these packages provide equivalent or near-equivalent function to expensive vendor packages. In a few cases, I think that a facility provided on this tape may be EVEN BETTER than anything that is on the market. There has been some uncertainty at CBT, due to a drastic reorganization, concerning their ability to reproduce the tapes in the quantity necessary to supply our needs. In response to the situation, Arnold Casinghino (our benefactor, who produces the tapes) has agreed to keep NaSPA supplied with the current versions, so that anyone may order them from NaSPA. Please get into the habit of ordering the CBT tape from NaSPA, if you can. To offset the slightly increased cost, due to handling overhead, we suggest that several installations can pool, to share a single tape. The "Air Force" TAPE COPYING PROGRAM, on file 229 of the CBT tape, will make up to ten copies of a single tape at the same time--as many copies as you have drives. Arnie Casinghino himself, has used this program to cut the copies of the tapes that he sends out. OUR AIM IS TO MAKE THE TAPE GENERALLY AVAILABLE, IN ITS CURRENT VERSIONS. There are no restrictions on copying, and we would like to see that the tape be spread around as much as possible, for every shop's benefit. As far as making new versions of the tape, with changes, Arnie will try to continue doing that as long as he can. If for some reason, Arnie has trouble getting a system on which to do the updates, I will endeavor to keep them going myself, as long as necessary. NaSPA might then become the main distribution point. In any case, I hope that we can continue to keep the tape current, as a vibrant and responsive vehicle to supply the needs of this profession. It is important to make the point that packages on the CBT tape have often been kept close to sync with new levels of system software. Original contributors, and others, have bent to the effort, and kept many of these programs in touch with modern times. (The support, of course, is voluntary, and it varies from package to package.) Usually, if hundreds of companies use a package, SOMEONE is going to fix it for a new level. (And I'VE BEEN THE ONE, more than once.) Another consideration: because the CBT tape has often been in danger of becoming full, Arnie has gone through a series of mass deletions of old files. THEREFORE, MOST MATERIAL ON THE CBT TAPE IS FAIRLY NEW, and there is not much "dead wood" on it nowadays. So please keep in touch with notices in this column, and we'll try to bring you the latest news concerning the CBT Mods Tape. * * * * * * * * * * * * * * * * * * * * Now to the month's topic. First, I sincerely feel that we should publicly appreciate the efforts of Arnold Casinghino, who has exerted himself mightily for almost fifteen years to bring us the unbelievably rich CBT tape. This tape has gone through 310 release levels, STARTING FROM VERSION ONE. I always say that Arnie has to be a very fine person, because someone who isn't willing to help people, would have weaseled himself away from such a task long ago. I personally think (and would welcome correction from our readership), that perhaps 95 percent of MVS installations in this country possess, in house, programs that are either directly from Arnie's tape, or which were transported indirectly after originating from there. I suspect that the figure is actually higher. It is a good example for us to ponder, that one person, who sits in one chair, could do so much to help so many people and installations, simply by continuing to be "the swap shop" for such a length of time. One man's quiet dedication pays dividends for many. Thanks, Arnie. We wish you well, and hope you can continue to help. So in keeping with this, we'll talk about some more software items from the CBT tape that we haven't elaborated on previously in this column. Three unbelievably handy software packages to have at your side, are TSSO (Time Sharing Subsystem Option), ETPS (Emergency Tele-Processing System), and CMD1 (Command Subsystem). I have singled them out, because they are not only convenient tools, but they are of valuable aid in automating operations (in the case of TSSO), in monitoring the operation of the system (CMD1), and in bailing out the installation in cases of system emergency (all three packages). These three packages HAVE BEEN WRITTEN AS SUBSYSTEMS under MVS, and as such, THEY CAN FUNCTION WITHOUT JES2 OR JES3 BEING UP. Their utility value under circumstances of system distress, as well as under normal conditions, makes for the avoidance of standalone restores and other time-consuming and painful recovery practices. The function in these packages together, in my estimation, have what I'd call a "vendor package replacement value" of forty to eighty thousand dollars to a company. They are public-domain (not guaranteed in writing, etc.), but to obtain equivalent value from vendor products, an installation might have to spend the aforementioned sum, or more. In addition, most vendor products are not subsystems, and cannot be used to fix the system software if there is a problem with the primary subsystem (JES2 or JES3). TSSO is found on CBT tape file 401. A version of CMD1 which works under XA can be found on file 261, and ETPS is a part of file 353. The original version of TSSO is distributed on file 306, although it can be completely replaced by the version on file 401. A series of examples in the use of TSSO for automating operations, can be found on file 399. TSSO was originally written by Bill Godfrey (his version is on file 306 of the CBT tape) for the purpose of executing TSO commands from a system operator console. TSSO in its original form emulates a TSO environment (with CPPL and other control blocks), so a TSO command will execute under it. Responses from TSO commands executed under TSSO will appear on the system console, but only if the particular TSO command does its terminal I/O using the PUTLINE terminal interface, and not the TPUT interface. In either case, the command would be executed. However, it is obvious that one should choose TSO commands that use PUTLINE I/O to execute under TSSO, so that the response is reported to the issuer. One should also note that FULLSCREEN terminal I/O will cause TSSO to abend. (The system operator console is a TTY-type line-oriented environment). It follows that any TSO command doing fullscreen I/O must not be executed under TSSO. The version of TSSO on file 401 of the CBT tape (the public Bellcore version 4.3) completely supersedes Bill Godfrey's version. That version of TSSO (which carries a Bellcore copyright notice, but which is their last release as public-domain software) adds two additional functions. The main one is AUTOMATION OF CONSOLE OPERATIONS, and the second one is CONSOLE SECURITY. This is in addition to the ability to execute TSO commands from the system console, as mentioned before. I recently attended a fascinating session at a large IBM user group meeting. The speaker, who was from IBM, did an in-depth study of different types of console messages, for the purpose of learning how to use the messages to automatically drive system responses. The vehicle she used for doing the automatic replies (etc.) was IBM's NETVIEW(TM), which isn't cheap. Besides what I learned from her incisive and deep observations, I was struck by a big point. I COULD DO EVERYTHING WITH TSSO IN THE WAY OF CONSOLE AUTOMATION, THAT SHE SAID SHE HAD DONE WITH NETVIEW! I know that TSSO cannot do everything Netview can. But I found I COULD do with my TSSO, everything that this speaker mentioned, in the way of using messages to initiate new system actions. TSSO has the "console automation scene" pretty well covered. From the user's point of view, TSSO accomplishes console automation tasks through an assembled and linkedited module, called the AOF (Automated Operations Facility) Table. The active table can be instantly replaced with a new version or another module, through an operator ".RELOAD" command. Various types of actions can be specified in the table. Selected messages can be highlighted, lowlighted, or suppressed from the console (but not from the system log). Also, a message can be used to drive an operating system action, such as the execution of a system command. It is easy, for example, to simulate new system commands. One merely intercepts the "IEE305I syscmnd COMMAND INVALID" message from a particular invalid command, (one can specify the contents of the second word in the message to key on), and then an "OSCMD" reply can be issued to perform any action desired. Then, one merely suppresses the original "COMMAND INVALID" message from appearing on the console. Our shop uses one such "invalid command" to start JES2 with all the required parameters. The operators simply enter one command, and are relieved of the responsibility of getting all the JES2 start parameters right. Because a TSO-like environment is present in TSSO, IT IS POSSIBLE TO EXECUTE OPERATING SYSTEM COMMANDS OUT OF A CLIST, AND RETURN THE RESPONSES BACK TO CLIST CONTROL. The entire power of the CLIST environment can thus be brought to bear on the task of automating console activity. If you think about it, THIS IS BIG STUFF. Some examples of what people have done, appear in file 399 of the CBT tape, but they do not come close to exploiting TSSO's full capability. As far as we're concerned, the sky's the limit. We're free to use our own inventiveness to the fullest, in this arena. If you're running MVS under VM, a "CPCMD" command processor is supplied, to issue VM commands from MVS, that are executed by the underlying virtual machine. One can inquire about attached devices, paths, other VM users, and such. It is easy to attach or detach devices to MVS and to other machines as needed, too. VM users can figure the rest out for themselves. Just to entice the imagination, I'll cite a few examples of what people have done: Vary tape drives online or offline in selected bunches, trigger a response or a warning when spool space gets too full, reply to WTORs or to sequences of WTORs. One can start up everything after a new IPL; one can shut down the entire system in preparation for a new IPL, just with a single CLIST execution. This is with a single command to initiate each "intelligent" sequence of actions. One can set up all the operator consoles to proper (rollable) status at any time. (At IPL time this may be done in the PARMLIB COMMNDxx member.) Much manipulation can be accomplished with remotes. All the initiators can be set up to different configurations at different times of the day. Date conversions may be displayed on the console, using the power of CLIST string manipulations. I must emphasize that these are but a very few examples of what is possible. Space prohibits further elaboration of TSSO's console automation capabilities. The CONSOLE SECURITY feature must get some mention, although few installations use it. Console security requires that TSSO work together with a data security system, such as RACF, ACF2, or Top Secret. The result of console security is that OPERATORS HAVE TO LOG ON TO THE CONSOLE WITH A PASSWORD, BEFORE BEING ABLE TO ENTER COMMANDS. This has the effect of allowing the installation to track WHICH operators entered WHICH commands. Console security may also be of help for large installations that have many secondary operator consoles, some of them lying around in user areas. The feature may do something significant, in preventing unauthorized persons from entering commands at these consoles to manipulate the system. Now we'll talk about ETPS, and we'll finish up with CMD1. ETPS (or Emergency Tele-Processing System) comes from Brian Cook of Morton-Thiokol in the Chicago area. ETPS is a system to do NATIVE TERMINAL I/O in the event that important parts of an MVS installation, such as the primary JES, VTAM, or TSO, will not start. ETPS supports an ISPF-like BROWSE and EDIT, and allows the entry of IDCAMS commands to perform VSAM functions when "nothing else is up". The idea of ETPS is excellent, and the system really works in an emergency, "grabbing a terminal" without VTAM or BTAM and allowing you to fix the system. One must watch out, however, because native terminal I/O is not easy to write correctly, and the system has some bugs, especially in the editor. However, IT CAN BE A LIFE-SAVER, and it sure is a handy tool to have around for when you need it. In the more recent release of ETPS, the author has front-ended it with a TSO command, called ETPSTSO. This command allows a user to use the ETPS facilities under TSO, so as to gain practice with it under more normal conditions. If one already is familiar with using the ETPS facilities, one is all the better prepared in the event of an emergency. In short, ETPS is a good thing to have. The non-price is right, and it is one more nice safeguard between us and disaster. I might add at this point that one can get around some of the necessity for ETPS, by using a combination of TSSO and the PDS command (file 182, 296, and 112 of the CBT tape). If one brings up TSSO without JES, (this can be accomplished by "START TSSO,SUB=MSTR"), TSSO can still run any TSO line command which uses the PUTLINE terminal interface. That includes TSO EDIT and also the PDS package. PDS in particular, has a scan/replace that works by update-in-place, and which can be used to look at JES parms or PARMLIB members, to fix an ailing system. PDS will compress libraries that are full, add directory space to a library "on the fly", copy members from one library to another, and help in many other ways. My own emergency requirements have usually been satisfied with just this combination of tools. I cannot do proper justice to CMD1 (the Command Subsystem) here. CMD1 has many, many display and monitor functions, operated both from the system console and from a TSO userid. The closest thing I can compare it to, in a vendor package, is the "RESOLVE" package from Boole and Babbage, with its many "authorized" utility and monitor functions. I privately refer to CMD1 as "the poor man's RESOLVE". At this juncture I must point out that CMD1 is written as a subsystem, and it can do most of its functions "without anything else up" on the system. That can be helpful also. The greatest necessity for CMD1 at an MVS installation, is in its "authorized function" capability. One sometimes needs to make an address space NONSWAPPABLE, or CANCELABLE, or the like. Sometimes one needs to display and zap memory, to save the system at a crucial time. CMD1 has large capability in this area. Without some vendor package to fill that bill (usually costing in the neighborhood of forty thou), an installation can find itself helpless sometimes. Once (many moons ago, I must say) our own installation had to IPL when JES2 got into serious trouble, and even a "$pjes2,abend" command didn't work. With CMD1, I simply made it cancellable and cancelled it, or terminated its address space. DONE--no fuss. CMD1 has many display facilities too, to the point that one may get quite overwhelmed with them. For example, #J is a useful display of jobs and started tasks, etc. in the system. The various types of #I command show different types of SRM values, paging, swap activity, and other statistics. #V tells you all kinds of things about the mounted disk volumes. #FC displays CSA and SQA usage. And so on. There is a user guide, and you have to look for what you need to measure. A large part of CMD1 has been adapted for use under XA. This opens up a different area in our discussion of CMD1. Such a product is bound to change greatly, because of variations and enhancements in the underlying operating system. Traditionally in the history of CMD1, large numbers of modules had to be changed because of a new operating system release. In fact, the installation procedure of CMD1 reflects this greatly. You start with a set of modules for a lower system release than yours. Then you execute a CLIST against the install library, which renames a whole bunch of modules so that the next level of operating system becomes the currently installable level. This keeps going on, until you reach the level of operating system that you're at. Then you install the thing. This is really how it works, no joke! Anyway, this incredibly rich package is yours for the looking and taking. I must say that it takes up some LPA space. But you can often save that space in other ways, such as removing ISAM from LPA, if no one in your shop uses ISAM, for example. If you're really interested in tuning LPA, IBM has a Dallas Systems Center book that's good: "MVS Virtual Storage Tuning Cookbook", G320-0597. There's a chapter in there that says what you can remove from LPALIB to a link list library, so that the system will still work. Getting back to CMD1, it's very good, but not 100% guaranteed, because it's not formally supported. It does have a built-in safeguard to stop a command that doesn't work properly from damaging the system. I still think that the advantages of CMD1 far outweigh the deficiencies, and if your shop won't spend the money for the expensive utility and monitoring packages (probably not so good an idea), CMD1 will fill a lot of the void for you. Between all three of these packages, you and your shop can be a lot better off. Good luck. See you next month.