MVS TOOLS AND TRICKS OF THE TRADE January 1989 Sam Golob MVS Systems Programmer INTRO TO THE COLUMN, MISCELLANEOUS TOOLS, THE CBT TAPE This new column will appear monthly in "Technical Support". We are confident that most of our readers will increase their power, and the ability to do their jobs, through the practical tools and tips mentioned here. This forum will concentrate on tools available to all readers. The public domain literature for IBM mainframe operating systems is immensely large. Occasionally a reference may be made to a vendor product that will do the same job as one of these tools. However, I feel very strongly that EVERY MVS PERSON CAN GREATLY EXPAND THE RANGE AND SCOPE OF HIS WORK. ONE DEFINITELY DOES NOT HAVE TO BE LIMITED by the amount of money his company is willing to spend. Readers are encouraged to contribute techniques and advice to this column by writing to me care of the Editor. The contributor's name will be mentioned if his item is printed. Let me begin by mentioning some of the common PUBLIC TAPES which are available for what is essentially a handling charge. In my opinion, the most important is the CBT MVS Mods Tape from the Connecticut Bank and Trust Company. This tape, which is updated approximately once a month, has over 400 files on it, some of which contain major software packages and products. The SPLA MVS tape, the JES2 and JES3 tapes, and NaSPA's very own VIP tapes are also good sources of excellent things to help you. (Addresses and phone numbers for public tapes are available elsewhere in this issue.) Our initial concentration will be on the CBT tape, because of its vastness, and the breadth of its offerings. Two small things before we get down to some nitty gritty. First. THE FACT IS THAT TSO IS AN INTEGRAL PIECE OF THE MVS OPERATING SYSTEM. EVERYONE WHO HAS MVS, ALSO HAS TSO. Programs that are known as "TSO Commands" or "TSO Command Processors" can often do their good work, running in BATCH MODE, without using a TSO account. Another way they can be run, is from a SYSTEM CONSOLE using the TSSO product, available from the CBT tape or as a vendor product from BELLCORE. TSO Commands that require FULL-SCREEN MODE cannot be run in these alternate modes, however. I would therefore recommend even for "non-TSO" installations, that at least two or three TSO accounts be set up in the shop. This is not a "TSO prejudice" on my part. It is a means to immense power. Second. Let me say a word about assembler MACRO LIBRARIES. Most of the tools we are going to talk about are written in BAL assembler language and are supplied in the form of source code. Besides the usual macro libraries SYS1.MACLIB and SYS1.AMODGEN that are normally referred to, SYS1.ATSOMAC (or whatever prefix your shop has for it) may often be required in assemblies. Specialty macros used by each product are usually supplied with the product, or indications are given where the macros can be found. SYS1.AGENLIB, which has sysgen macros for MVS, will rarely be needed. A general related principle is that one should not use a tool unless the assembly was clean (return code 0), or he can account for every single line of code that gives condition code 4. If the assembly condition code was 8, the load module should not be used. Much care should also be paid to the linkedit step(s). Haste makes for unnecessary problems. Now to start. People often mention to me that the CBT tape is so vast, that they don't know where to begin looking. This then, is my first tip. Print out file 1 (the catalog) and look through it often. My favorite first files are from Jim Marshall of the US Air Force, files 300 (TSO commands) and 316 (batch utilities). This is an excellect collection of close to 200 programs, and is a good place to begin exploring. The very first thing I recommend installing is the UCLA fullscreen ZAP program from file 300. It is a straight assembly and linkedit of a load module, and it can be placed in any load library that the TSO account has access to. It not only replaces the batch AMASPZAP for 95 percent of applications, its "find" facility for hex and EBCDIC strings of data will make previously tedious "zapping" chores trivial. ZAP need only be authorized to zap a VTOC. In that capacity, it is an essential ingredient of my procedure (CBT tape file 29) to enlarge the VTOC of a disk pack "on the fly" without disturbing the users of the pack, or the datasets on it. A second useful tool to install right away from file 300 is "CDSCB" ("change the DSCB"), an authorized TSO command which changes any field of the VTOC entry (format 1 DSCB) of a disk dataset through the use of commands. This procedure is safer than zapping a VTOC entry directly, because you are assured that the correct fields are changed, and you're not "off by a byte or two", which might spell disaster. After looking at Jim Marshall's files a bit, I'd then recommend installing the fantastic PDS program package on CBT tape files 182, along with related utilities on files 296 and 112. The PDS package (at version 8.2 as of this writing) literally rolls HUNDREDS OF UTILITIES into one unified whole. My course of study on how to use the product, printed in the January, February and March 1988 issues of "Techical Support", is now included in the distribution dataset for PDS on file 182. File 270, from Kermit Kiser and the Washington State DP Service Center, is a large source of utilities, many of them original with that installation. File 149 from UCLA, and file 119 from Howard Dean, are some smaller collections that are good to look at. A short word about large packages on the CBT tape (as opposed to collections of utilities). TSSO on file 401 is a multipurpose software package that does TSO-like interactions with the MVS system consoles. Version 4.3 on the CBT tape is the last public-domain level of the product--it has since been "taken private" and its later versions are being sold by BELLCORE, Bell Communications Research, in Piscataway, New Jersey. TSSO lets you: execute TSO commands from a system console (as long as they are not "full screen" commands), suppress or highlight messages, enter MVS or VM commands automatically under CLIST control, or driven by an initial console message. It can do much more than that, and is worth installing. Some ideas of how TSSO has been put to use, are on the CBT tape file 399. DYNAMASK (file 400) from Steve Smith, allows an "instant EDTGEN" to define new generic unit names (e.g. SYSTSO, SYSWRK, etc.) without necessitating an IOGEN, or even an IPL. The CMD1 subsystem (file 261) is a multipurpose installation monitor and IPL-saver. I call it "the poor man's RESOLVE" (referring to the Boole and Babbage product). CMD1 is a true SUBSYSTEM and does not need JES2 or JES3. There are several hundred things it can do from the system console, including "displaying and zapping core", and it has a TSO interface. Pretty good, for something that's free. How about looking at JES2 Spool? The QUEUE program, available on the CBT tape (file 394 for JES2 1.3.6 or 2.1.5, file 393 for 2.2.0) and on the JES2 Mods tape, allows a TSO user to view any dataset on spool, including output that belongs to a running job. SYSLOG on spool, pending printout, held printout, and many other things can be shown, including JES2 control blocks which belong to a job. For JES3 users, there is a comparable program on the JES3 tools tape. Last but not least, are programs which make your TSO tube look like a SYSTEM CONSOLE, and allow authorized personnel to enter any console commands from TSO, as if they were at one of the operators' consoles. File 25 of the CBT tape from Texas Power and Light has the nicest programs for this purpose that I've seen. They have XA and non-XA versions. This package has some super options, such as automatic renewal of the console screen, display of last IPL, and display of past console commands from the in-core Master Trace Table. I want to conclude this month's column with one specific tip. That is so you don't leave with the impression that "he just told us to install a bunch of stuff from the CBT tape". This trick (from Jeff Broido of Broido Computer Consulting in New Jersey) concerns VSAM files, and is not to be done casually. In the proper context, it can be a life saver. It is based on the fact that VSAM datasets are protected from outside poking by two things: The PASSWORD bit in the format 1 DSCB (VTOC entry) is set on for READ-WRITE protection. (IDCAMS can get around it.) You can find out about the password bits by looking in the MVS Debugging Guide under control block DSCB1. There may be an expiration date in the DSCB also. This too, will block access by ordinary mortals (other than IDCAMS). What do you do if a couple of bytes have to be adjusted in a VSAM file or catalog, and IDCAMS won't let you get to the thing? Simply get into the VTOC with full screen ZAP (mentioned above) and turn off the password bit of the DSCB for the dataset. ZAP's "find" command makes it easy to get to the proper VTOC entry. Then if there's an expiration date (when you look around with ZAP you can see it), you can either zap it off, or use CDSCB to be more sure of yourself. Now, the protection is off, and the VSAM file can be poked around with fullscreen ZAP or another utility, as if it were any other dataset. When you've finished, reverse the steps, and turn the protection back on. That's it for now, we've run out of space. See you next month for more.