MVS TOOLS AND TRICKS OF THE TRADE December 1997 Sam Golob MVS Systems Programmer P.O. Box 906 Tallman, New York 10982 Sam Golob is a Senior Systems Programmer. REMEMBERING TSSO Systems programming professionals have long been known for creating clever tools and programs. Historically, this was encouraged by our environment, as manufactured and developed by IBM. MVS has always been an extremely robust operating system, with many parts and facilities. However, IBM seems to concentrate its programming efforts mostly on developing the system facilities themselves, leaving the utilities and fine touches mostly to others, and to later development. I'll explain. When IBM would release a level of the operating system, they would ship some raw tools for handling the system parts along with it. For example, to change an arbitrary disk file, IBM gave us the AMASPZAP (superzap) program, which works. To create a text file, IBM (in the past) shipped the EDIT TSO command, and later, they created the easier-to-use SPF and ISPF packages. No one of us can argue that AMASPZAP, EDIT or the ISPF editor cannot do its basic job. However, most of us, who are familiar with some of the non-IBM packages, will insist that the pure IBM-supplied tools do not provide the best ways of doing the job. IBM, it seems, concentrates its best efforts in providing the operating system and foundation structures. The more specialized and user-friendly tools and utilities for manipulating these structures are usually left for others to develop. By saying this, I don't mean to slight the enormous recent efforts of some of the IBM programming groups, notably the ISPF development group, and others, in improving their tools to make our lives easier. I just mean to point out the historical directions in our field. IBM usually would concentrate on developing a robust system first, and they'd usually try to improve the utilities later, or leave their improvement to others. My real point is, that anyone who is familiar with the free UCLA Fullscreen ZAP TSO command, as improved by Greg Price, will never want to use AMASPZAP to change a disk file, except in certain cases, for example, when TSO is down. Fullscreen ZAP is much easier to use: You see what you are doing on a full TSO screen. There is a FIND subcommand to locate data that needs changing. There are all kinds of "helpers" such as AND, OR, XOR, and setting an entire record to a given value. And you can always see the raw structure of the data (block size), and where the data is, on which cylinder and which track. You can easily find deleted disk data, and even change that. AMASPZAP, although quite capable, is far harder and more unfriendly to use, as everyone knows. Another thing to point out, is that IBM's later improvements often come because of suggestions from user groups, such as SHARE and GUIDE. The people who go to SHARE and GUIDE often get the ideas to tell IBM, from the user-developed tools and utilities which have appeared on the CBT MVS Utilities Tape, and in other sources of free code. User-developed code is probably the greatest source of IBM direction, for improvements to their utilities. That also includes IBM internally developed user-written code, which IBM programmers write for their own use, and not for general release. This takes us to our current topic, which covers several fields. We are going to talk about a product called TSSO, which can do several different things, depending on which version you are using. IBM has partially caught up with, or surpassed, some of TSSO's functionality. But IBM, to my knowledge, has not even addressed TSSO's original function. That's why I feel it's proper to talk about TSSO here. WHAT IS TSSO? TSSO, short for Time Sharing Subsystem Option, is a package of programs, several versions of which appear on the CBT MVS Utilities Tape. The primary function of TSSO is to allow the execution of TSO commands at an MVS Operator console, through the creation of a TSO-like environment that is driven from console commands, and creates responses as console messages. The later versions of TSSO have other important functions in addition to this. TSSO is also an MVS subsystem, which can either operate under JES2 or JES3, or without JES. TSSO operating without JES, is a powerful system recovery tool, because one can do dataset renames, string scans and replaces, and IEBCOPY executions, without JES2 (or JES3) being up. As I've said many times in previous columns, the CBT Tape is an independently produced huge collection of free System Programmer goodies, that can be ordered through the NaSPA office. All materials on the CBT Tape can be freely copied and used by anyone, although a few of them are "owned" and have copyright notices printed in them. The original version of TSSO, written by Bill Godfrey, is on File 306 of the CBT Tape. Bill Godfrey's TSSO contains only the basic TSSO function of allowing TSO commands to be executed at an operator console. TSSO takes the TSO terminal environment, and establishes an equivalent environment at the operator's console. In other words, with TSSO, the console operator has access to TSO commands and CLISTs. Of course, there has to be one significant limitation. TSO is a full screen environment. That being the case, there are two alternatives in the way messages can be sent to the screen of the TSO user. Messages can be sent to the screen either one line at a time, or else they can be sent in one burst, filling the screen all at once. The second way is called a full screen TPUT. The operator console is a line-mode environment, with console messages that come, one line at a time. One limitation of TSSO is now clear: Any TSO commands which put out terminal output one line at a time, are OK. TSO commands which issue a full screen TPUT, filling the screen all at once, are not OK. So you have to be intelligent under TSSO, deciding which TSO commands you can issue at the console. There is one further fact to note. TSO has two methods of issuing line output to a screen. One of these is via the TPUT TGET interface, and the other is by the PUTLINE, GETLINE, PUTGET interface. TPUT is easier to code in a program, but the output cannot be sent to print under TSO-in-batch (see my October 1997 column). PUTLINE is quite difficult to initially set up in a program, but the PUTLINE terminal output can be sent to print in a TSO-in-batch job. This same situation occurs in the TSSO console environment. Messages for a TSO user that were written using PUTLINE, appear at the console as replies to a command. Messages written using TPUT, do not appear. However, this does not mean that a TSO command which uses TPUT messaging, is ineffective. It may still do its job. For example, IBM's RENAME TSO command does not use PUTLINE replies. However, under TSSO, the RENAME command will definitely do its job, to rename a dataset or a pds member. TSSO has one additional advantage--it is also an MVS subsystem. As such, TSSO may be started using SUB=MSTR, and in that case, it will come up without JES. The TSO commands can then be executed without JES2 (or JES3) being up. TSSO thus becomes a system recovery tool, of great usefulness. TSSO can also be brought up under JES as well, and you can START TSSO,SUB=JES2 or JES3. If TSSO is brought up under JES, then the TSO SUBMIT and OUTPUT commands will work. If TSSO is started with SUB=MSTR, these commands, which need JES, will not work, but all the other line-mode TSO commands which don't need JES, will work quite well. I have used TSSO together with the PDS command processor (CBT Tape File 182 or 295) which invokes IEBCOPY using its COPY subcommand, and have copied entire datasets and members when JES2 was down. TSSO, operating without JES2, can save your shop in a rough situation, by allowing you to correct errors in your system initialization datasets. Through the PDS command, you can even add more directory blocks to the SYS1.PARMLIB or SYS1.PROCLIB datasets, when JES is down. A sample PDS subcommand to do this would be: FIXPDS EXPANDDIR(nn), where nn is the number of directory blocks you want to add, and PDS, through TSSO, is pointed to SYS1.PARMLIB or SYS1.PROCLIB. TSSO AS A TOOL FOR AUTOMATED OPERATIONS Back in 1985 and 1986, Marc Schare at Bellcore, working with a few other people there, extended the capabilies of TSSO into the realm of what we now call Automated Operations. Since TSSO creates a TSO-like environment, and CLISTs can run under TSO, Marc's idea was to use TSO CLISTs as a programming tool to respond and reply intelligently to console events, automatically. Before explaining the automated operations aspects of TSSO, I have to add a little history of the product. Bellcore's version of TSSO is on File 401 of the CBT Tape, and is called TSSO Version 4.3. TSSO Version 4.3 carries a Bellcore copyright notice, but permission was granted by them, for anyone to use the package as public domain non-supported software. Subsequently, Bellcore came out with a vendor version of TSSO which they called TSSO Version 4.4. They removed their "pay TSSO" from marketing, a year or two later. What remained for us, was the Version 4.3, which everyone could use for free. Dave Cartwright came out with some free enhancements to TSSO 4.3 a few years ago, and these were placed on CBT Tape File 402, without being merged with File 401. Guy Albertelli merged Cartwright's improvements with TSSO 4.3, and these were purposely kept separate on the CBT Tape, being placed in File 403. File 403, until recently, was the most advanced free version of TSSO. Recently, an anonymous donor upgraded the File 403 TSSO to run on OS/390. This was placed on File 404, in version 415 of the CBT Tape (not on the NaSPA cd-rom). With that done, let me explain how TSSO does console automation. Each console action and message reply is coded as an assembler macro, which gets assembled and linkedited into an AOF (Automated Operator Facility) load module. In TSSO terms, an AOF load module is called an AOF table. You can have many of these AOF tables, each containing a different collection of console actions. Only one AOF table is active at any one time. A single TSSO console command will activate or deactivate a given AOF table. This takes only a second or two. If you have to invent a new console action quickly, and all of your assembly source and JCL is in place, it only takes about two minutes to assemble, linkedit, and run the TSSO console command to activate your new AOF table which includes the new action. As part of the working mechanism of AOF, TSSO supplies special TSO commands which perform specific functions. Among these are the commands: OSCMD (to issue an MVS command and get a reply), OSASK (to ask the operator a question and get a reply), OSWAIT (to wait a specific amount of time), OSWTO (send a message to the operator), REPLY (reply to a message that has a message id), MULT (issue multiple commands on one line), CACHE (to control a cache controller), CPCMD (to issue a CP command if you're under VM, and get the reply in MVS), and others. These commands can either be used directly in a CLIST, or their execution is part of the action initiated through the AOF table entries. When all this is taken together, you see that TSSO actually supplies all the primitives to perform extensive automation of the operator console, and indeed, TSSO was one of the first console automation packages to come out. TSSO has the advantages that it is still available, and you can even use TSSO, while some other console automation package is also in place. I don't think that most of the other automation packages are TSO-like. If your shop has another automation package, TSSO can still be used to enter TSO commands at the console. Anyhow, I hope this month's discussion will stimulate you to take another look at TSSO, to use at your shop. The time so spent, will pay you back. Good luck. See you next month.