MVS TOOLS AND TRICKS OF THE TRADE APRIL 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. TSSO REVISITED Free tools have their advantages and disadvantages. Let's look at advantages first. Last month, we discussed what happened to IBM's "unofficial" MCNVTCAT tool for generating DEFINE NONVSAM statements from VSAM catalog entries. We saw that a user-written replacement, Alastair Gray's RCNVTCAT REXX exec, has distinct advantages over IBM's tool. First, RCNVTCAT works better than MCNVTCAT, and it's easier to use. Second, IBM's MCNVTCAT was not written by IBM's programmers who write the MVS operating system, but by the CBIPO software distribution folks. That put MCNVTCAT into a category (like Field Developed programs) where IBM was not obligated to support it. Third, when the CBIPO went away, so did MCNVTCAT. But Alastair Gray, who wrote RCNVTCAT, can usually be persuaded to improve his tool. Alastair is not bound by IBM's internal bureaucracy and contractual obligations. So it's more likely that you can get support service from this private author than from IBM, at least in such a case. I recently asked Alastair myself for an improvement, and he made the requested code change for me within a couple of days. The "down side" of using free tools, is that sometimes they stop working when IBM comes out with a new release of the MVS operating system (OS/390, z/OS, etc.), and it's up to a knowledgeable user to fix the tool for the later version of the system. Sometimes a knowledgeable (and willing) programmer is available, and sometimes not. So unless you yourself have the know-how to fix the tool, you can be stuck. But often, the power of numbers comes to the rescue. This is especially true when the tool is in use by large numbers of people at many installations. In that case, more people have a vested interest in keeping the tool working, so if one person (perhapes an original author) doesn't fix it up, it's very likely that someone else will. This happens very frequently in the history of the more popular user-written tools. So we've seen some pros and cons. I think that an outweighing factor in favor of using user-written tools, is the presence of an active exchange forum where people send updates, and where prospective and current users can look for them. A tool which is distributed on such a forum has a greater likelihood of being fixed or improved in a timely manner. I'll explain with an example. A very good exchange forum for free MVS tools is the CBT MVS Utilities Tape and the CBT Overflow Tape, whose materials are (also) available online at www.cbttape.org. This forum allows the users of a tool to look online and see if an improved version has been made available. And if one of the users has made an improvement himself, he/she has a place to send it in, so other people can use it, test it, and derive benefit from it. Without having such a forum, the tendency is that one person makes an improvement to a tool, and that improvement does not easily find its way outside that programmer's own shop. Even a person's personal web site doesn't often enjoy widespread public access, but the Internet has made an improvement in the distribution of an individual programmer's works. Still, it is better to have a place where everyone knows they should look, like the CBT Tape web site. THE PLACE OF TSSO Today, I'm going to talk about a tool called TSSO (Time Sharing Subsystem Option). TSSO has been used at many shops over the years, and it illustrates the ups and downs of running user-written software very well. The basic idea of TSSO is to create a console environment (which runs as an MVS subsystem) where TSO line-mode commands can be executed. The TSO command (preceded by a subsystem character) is entered on an MVS console, similarly to when a TSO command is entered at the command line of a TSO session. And the resulting displays from the command (if any), which have to be in the form of PUTLINE line-mode output (no Fullscreen TPUTs are allowed), get written back to the console via WTOs. However, whether display output is produced or not, the command will still perform its action. For example, if you use IBM's TSO RENAME command to rename a dataset, no display output is produced, but the dataset is nevertheless renamed. TSSO is the brain-child of Bill Godfrey, who wrote the first version back around 1980, and Bill's version of TSSO, now on CBT Tape File 306, still does exactly what I've described. You can glimpse the enormous potential of having such a tool. For example, you can use IBM's RENAME, DELETE, and LISTD TSO commands to do dataset renames, deletes, and displays from an MVS console in a pinch. And with the free PDS 8.5 command package, you can compress a dataset, or copy dataset members to a different dataset, also from an MVS console. That's because the COPY and COMPRESS subcommands of the PDS 8.5 package will invoke IEBCOPY in foreground TSO, and TSSO creates a TSO-like environment at the console. And these same operations which are normally done only under TSO, now can actually be carried out without TSO being "up". An enormous improvement to Bill Godfrey's TSSO was made by Marc Schare in 1985-6 (Marc was then working at Bellcore) who took advantage of TSSO's TSO-like console environment so he could use CLISTs (now REXX execs too) and intelligently reply to MVS commands with them. Marc created a genuine "automated operations" environment built on top of the basic TSSO structure. Marc implemented sets of pre-assembled "AOF Tables" in TSSO, to automatically and intelligently respond to certain console messages with given replies. To protect the new power of this TSO-powered console environment against unauthorized use, Marc also implemented the concept of "console security" inside TSSO, years before IBM itself did that in native MVS. TSSO makes it possible to protect a console (using RACF, ACF2, or Top-Secret), so you have to logon to that console with a password, in order to enter commands. As MVS changed, TSSO eventually needed fixing and improvements. Guy Albertelli and Dave Cartwright wrote many of the initial fixes, and recently, for z/OS and the later OS/390 systems, Ed Jaffe wrote an extensive series of modifications to TSSO. TSSO can now be implemented in all the modern MVS environments. You can find the latest version of TSSO on File 404 of the CBT Tape collection, and the previous versions of TSSO (if you are still running an old version of MVS) may be found on the CBT Overflow Tape. So although TSSO came into some disuse for a while, Ed Jaffe's fixes have now made it possible for every MVS shop to run it. INSTALLING TSSO I recently installed TSSO on an OS/390 2.10 system, and found that it is not hard to implement. I obtained the File 404 pds from the CBT Tape collection, and made my own copy of it. I allocated a load library and ran the assembly job which was supplied, to assemble and linkedit all the load modules. One change had to be made to the source. It seems that the pound sign (back in 1980-1986) used to be an unused subsystem character, but now RACF uses it. So I had to change that. Now, I use a question mark (X'6F') instead of the pound sign (X'7B'). It is a one-byte change in module TSSOINI2, at displacement +B3. Once the load modules were created, I moved them into a system library. I made a RACF change, to create a userid called TSSO (similar to userid JES2), and added the subsystem name TSSO to the IEFSSNxx PARMLIB member. Then I had to re-IPL, which TSSO requires when it is first installed. The TSSO started PROC, which is distributed in File 404 as member TSSOPROC, has to be copied to SYS1.PROCLIB, renamed to TSSO and then customized. After the IPL, you then issue START TSSO from the console, or S TSSO,SUB=MSTR. At this point, I found that I could enter TSO commands from the console, when I preceded the command with a question mark (in my case). If you leave the default subsystem character as the pound sign, it won't work, because the system interprets the command intended for TSSO as a RACF command. I found that I could do dataset renames and such, if the the new TSSO RACF userid was given the proper access to them. I found I could compress datasets from the console by doing the following type of console command, which invokes PDS 8.5: ?PDS85 SBGOLOB.CBT.CNTL COMPRESS SHR and the command was carried out. I could also invoke CLISTs from the console when the CLIST library was put into the TSSO PROC under the SYSPROC ddname, and RACF READ access was given to the TSSO userid, for the CLIST library. For basic TSSO use, it is important to note that the TSSO proc looks exactly like a TSO logon proc, except that you EXEC PGM=TSSO instead of EXEC PGM=IKJEFT01. There are some extra ddnames at the bottom, for outputs (described in the supplied sample PROC). All of this is very simple to understand, and easy to get working. IMPLEMENTING AUTOMATED OPERATIONS One must understand that the Automated Operations piece of TSSO was written in 1986, at a time when the software vendors were only beginning to create the sophisticated Auto Ops packages of today. The talk of the time, was to be able to establish "operator-less machine rooms" that would only need intervention in the case of an IPL. So although the TSSO Auto Ops facilities (called the AOF component of TSSO) were a great leap forward for their time, they may seem quite primitive by today's standards. If your shop already has an Automated Operations package installed, TSSO AOF can still work side by side with it. I'd say that you should use the installed Automated Operations package for the "production work", and you can restrict the TSSO intervention into the console traffic to specialized "sysprog matters", so to speak. In other words, if you want to play, and you don't want to interfere in the normal Auto Ops functioning, you can use TSSO to do your own console replies and stuff, as long as it doesn't interfere with the normal production work. That said, I'll show you the externals of how TSSO AOF works. AOF console intervention is driven by an assembled load module, which is really a table. You decide which messages are to be replied to. You draw up a plan, and then you code (using the supplied macros) a source table of messages and their replies, following your plan, and using the TSSO macros. You assemble your table, place it into a load library that is referred to by the STEPLIB of the TSSO proc, and then you issue a .RELOAD command under TSSO (in my case the full command would be ?.RELOAD tablname) to load the table for use. An installation can keep a load library containing many AOF tables, and you can issue .RELOAD commands at any time to load different tables. So you can vary your control how TSSO will manage your console traffic. TSSO supplies a DISPAOF command to display all the commands and messages affected by the currently loaded AOF table. The whole maintenance and learning process is made easier by two sample members supplied in the TSSO install pds. Member ASMTAB is a CLIST which will automatically assemble, linkedit, and optionally .RELOAD any assembler source for a valid AOF table. And member AOFIVP is a sample coded table that is deliberately intended to show you as many possibilities of how to code a table entry, as possible. I don't have space to show you more about the TSSO package right now. For further information about how to use TSSO, look at member RELGDE43. But my point is to let you know that a modernized version of TSSO is now available, and it is free for the installing. You have the option of only using the TSO-command execution part of TSSO, or you can delve into using the Automated Operations facilities of TSSO as deeply as you prefer to. Once TSSO is in place, the systems programmer has a lot of flexibility to do maintenance on the system, and on datasets, which was not possible before. With TSSO in place, you can fix or compress datasets while you're at the console in the computer room. The product is now available and it runs on z/OS. It's my job to let you know. The rest is up to you. Best of luck to all of you. I'll see you again next month.