MVS TOOLS AND TRICKS OF THE TRADE February 1990 Sam Golob MVS Systems Programmer sbgolob@cbttape.org SOME CHANGING TOOLS ON THE CBT TAPE; SLAC ASSEMBLER PART 2 This month's column is divided into two parts with one connection: that it pays for all of us, when each one of us makes a small contribution for the "public good". Yes, Virginia, there really is some hope in the world, and there are "little" ways in which we can all do some small thing which will benefit OURSELVES TOGETHER WITH OTHERS. The trick is to do a little at a time, and the accumulated effect adds up. Have you ever seen a tug of war? One of the two parts concerns the oft-mentioned CBT MVS Mods tapes, now distributed by NaSPA. Please remember that the CBT tapes help the entire MVS world by providing software and other assistance in the running of an installation. The demise of these tapes had been threatened by possible closing of a large data center where they had been put together. Not only will the CBT tapes survive, but a few glimpses of the ongoing "modification process" which keeps this tape so timely, will show how the willingness of one person (at a time) to enhance or fix a public program helps the entire public. The other piece of this month's story is an update to our ongoing narrative about the amazingly useful SLAC (Stanford Linear Accelerator Center) Modifications to Assembler H version 2. It also concerns efforts from the public. These are our efforts to convince IBM that it will be good for all (including IBM itself MOST of all) if the "SLAC Mods" would be incorporated into the Assembler H product "officially". PART ONE. The Ongoing Process of Updating a MODS Tape. I have often stated that the CBT MVS Mods Tape, which contains public-domain MVS software, is a vibrant, growing source of help to MVS installations. Continuing updates to the tape keep many of the included products compatible with the latest levels of the operating system. Handy software tools, previously found on the tape, become handier as interested programmers take the initiative to improve them further and further. The new versions 310 and 311 of the CBT tape that appear at this writing, contain a considerable number of new and improved files. For example File 187, a program to convert CLIST libraries from FB-80 format to VB-255 format and vice-versa, has been very useful, but the program had had some prominent bugs, especially in converting from VB-255 to FB-80 format. It has now been greatly debugged, and the current version works very well going in either direction. This development should aid any installations desiring to change their CLIST formats. The program on File 187 as debugged, should now make any such conversion completely effortless, because all CLIST libraries can now be quickly converted IN EITHER DIRECTION without fear (hopefully) of broken execution of some of the CLISTS. Another small example concerns the extremely helpful TAPEMAP program from File 299 of the CBT tape. About a year ago, I added CBT-tape support to the program, so that it could read member names from the compressed files of the CBT tape. That support somehow interfered with the proper page-ejection in the second TAPEMAP report, the one that shows the member names in the files. The problem of the page ejects baffled me greatly, and I had given up on it. Recently an interested programmer called Arnold Casinghino, the proprietor of the CBT tape, with a one-line fix to this page eject problem, so that the bug seems now to have been solved. I was of course relieved, and the public has been helped. I took the opportunity (once he was changing the file already) to supply Arnie with my version of TAPEMAP (page-eject fix merged in) that includes 3480 cartridge support in compatibility mode, so the public has been served more. This illustrates the process, and we can see a bit better how one contribution at a time, helps. One of the most significant additions to the newest versions of the CBT tape is File 134 from Greg Price of the State Electricity Commission of Victoria Province in Melbourne, Australia. These guys, bless their hearts, are on the other side of the world. I would definitely think twice before trying to phone them up (although I have phoned ONCE). However, no matter where they are physically, their work can been very helpful for all of US, and that is my point. The process can go on across the world and back. These fellows from Australia have worked over some of our most beloved programs from older CBT tapes, and have created super new versions of them. Those have been combined with some of their original creations, to produce this new File 134. We have public participation at its best here, and we all stand to benefit. Some of the objects of their "renovation" work are: UCLA Full Screen Zap. This incredibly handy disk zapping utility, most recently found on File 300 of the CBT tape, has several improvements in the File 134 version. First, it is now possible to zap ANY ITEM ON AN ENTIRE VOLUME, using the newly supported "FULLVOL" keyword. This keyword will cause fullscreen ZAP to access any track on the volume containing the dataset named at ZAP invocation. For example: ZAP dataset.name FULLVOL will cause ZAP to access track 0 of the volume containing the dataset. One can afterwards position to any track on the volume, using the "T" subcommand. In addition, the new subcommand VTOCDS4 can be used, to immediately position us to the Format4 DSCB or VTOC header, so we may quickly look at the VTOC or ZAP it. We can use the "full volume facility" to search an entire volume for any single character string, using the "F" or "find a string" subcommand. It's conceivable that we could test an entire disk volume for the presence of a virus, if we knew, for example, that the virus contained a particular string. This is a capability we did not have before. We should, of course, keep AUTHORITY for this out of the hands of most people, but for sysprogs it can be most helpful. It can SAVE IPLs (rather than cause them) if it is used with care and system knowledge. Some further examples of the use of these ZAP enhancements are: "clip" of an online pack (change of its volume serial). Normally, this is done with the pack offline using the ICKDSF "device support" program from IBM. In a real emergency, record 3 of track 0 can be accessed and the volume name changed with the pack online, if necessary. Back to File 134 and the work of those marvelous Australians. Many of you are undoubtedly familiar with the "REVIEW" TSO command from File 296 of the CBT tape. That command is a full-screen file browser, which is not dependent on ISPF at all. It can therefore be invoked from a TSO clist at any time TSO is up. For example, I have a CLIST that REVIEWs members of my SMPPTS library, so that I can browse my RECEIVED PTFs. The File 296 version, while being handy and a big improvement over TSO "LIST" or no tool at all, has several shortcomings. The most notable of these is its 1024-byte width limit. Even when REVIEW-ing a "wide" load module, only the first 1024 bytes of the record can be looked at. The Australian version can show even 32760 bytes of a single data record. It will also REVIEW entire PDS'es, supplying a really nice ISPF-like sortable member list in the process. That new version of REVIEW has other extended use as well. Since the wide record-browse capability is available, it is now possible to BROWSE TAPE FILES ON TSO using REVIEW. A CLIST called REVTAPE is provided, which shows you how to do this. One shortcoming that the "new" REVIEW has over the "old" one is the lack of some PF1 "HELP" support. Although the PF keys supported (except for PF1) are the same in both versions, the full-screen help prompts that are displayed in the File 296 version are missing from the File 134 version. Perhaps one of our readers will merge that code into the Australian code and send it back to the tape, or perhaps the Australians themselves may do so at a later date. In any case, you see the mutual help process that is going on here, which makes the public tapes so useful for us all. A file which is not a program, but which is nevertheless of great use, is the "ABEND" file. This is a TSO "help" member that tells us the meaning of the system abend codes. We thus can get the explanation of system failures online, so that we don't need to go to the message book so often. Greg Price extended the old file (in File 300 of the CBT tape) to include more recently introduced MVS abends, and also some vendor product user-abends. Thanks again, Greg. We COULD HAVE done it, BUT YOU DID IT, in the course of your regular work. We can see how the "we'll help each other" spirit of the public-domain utility tapes benefits us all, and depends on our contributions. People who send something in tend to think that they didn't do much, but that's not true. WHAT YOU DID, THE OTHER GUY DOESN'T HAVE TO DO. IT SAVES LARGE NUMBERS OF PEOPLE THE NEED TO DO THE SAME JOB OVER. When you add up the "small pieces" that each person or group contributed, you'll get a very large collection of tools and useful materials in total. But that is not all. Even "using the stuff alone", WITHOUT trying to send a fix in, also contributes to the public good. More exposure for the software tools encourages more debugging of defects. Your shop will benefit from the immediate use of the tools, and some benefit outside the shop will eventually accrue. One of the other staff members may fix something. Somebody at your shop could carry the program to another shop, and somebody there will send in a fix. ANY PARTICIPATION HELPS. NaSPA Headquarters at (414) 423-2420 distributes the CBT tape. Please call them and order it. Information on its current editors will be inside in File 1. PART TWO. The SLAC MODS to ASSEMBLER H - An Update In last September's "MVS Tools" column, I described some marvelous improvements to ASSEMBLER H version 2 that were accomplished through the "SLAC MODS", which are modifications to the IBM H-assembler. These covered the areas of reporting, language, and performance. Among the reporting modifications mentioned, were: full reporting of the NAMES and ORIGIN of any MACROS called, reporting of all active USINGs at each page break, and a level 4 error message to signal if any USING was coded that "broke the rules" for conflicting USING statements. The SLAC MODS offer many other reporting improvements, as well as performance enhancements and extensions to the assembler language rules. There exists a level of the SLAC MODS that has been applied to Assembler H at the 8906 PUT level, with full MVS instruction capability through ESA, and incorporating the DBCS support. This is supported outside of IBM. It is currently being beta tested on both MVS and VM, and it works very well. Negotiations are currently being conducted with IBM concerning the incorporation of the SLAC MODS into the IBM-distributed Assembler H. What my previous article lacked was illustrations. This supplement is intended to remedy that deficiency somewhat. Please note the several examples. However, they show only a few of the many extra capabilites. The SLAC MODS are actually very powerful and constitute a big improvement to the assembler. There is a problem concerning the distribution of our version of the mods. ASSEMBLER H Version 2 is a licensed program product of IBM, and our source updates include PTF code. As of this writing, negotiations are getting under way between IBM and the Stanford Linear Accelerator Center (SLAC) concerning legalities. We are hoping soon to get some clarity on these issues. (Perhaps by the time this article appears, the matter will have progressed further.) The ideal solution, of course, would be for IBM to absorb the mods, language enhancements included, and then everyone in the MVS and VM worlds could benefit. In order for them to do that, THEY HAVE TO FEEL THE NEED. CUSTOMER PRESSURE WILL BE THE ONLY WAY TO GET THEM TO ACT. I know, because I am speaking with the IBM management continually. PEOPLE MUST BECOME DISSATISFIED WITH THE ASSEMBLER. It is a good program, but it has glaring deficiencies. It doesn't tell you who and where your macros are. In a long program, you are NEVER sure which USING statements are active. DSECTs scattered throughout a program are very confusing--the SLAC enhancements help the programmer map them out. Non-referenced labels are reported by the modified assembler. One can find out if there are branches to a label or not. One can even request OPCODE and MACRO occurrence counts. There is a lot about IBM's assembler to be dissatisfied with. IT DOES NONE OF THESE THINGS. Regarding the language enhancements, for example: "labeled" and "associated" USING statements to conserve addressing registers, relaxation of the rules for defining global variables, and many others, we are in a "Catch-22" situation. Users of the SLAC Mods are hesitant to use the language enhancements in their code, because IBM's "vanilla" assembler currently won't handle them. On the other hand, the result is that not much experience has been gained with the language enhancements by users, so the advantages of having them are not widely known. Therefore it is hard to put pressure on IBM. I hope that in a future supplement, we can address the issue of these language enhancements to the assembler, and I can tell the people what the enhancements are. For now, look at the accompanying illustrations. If you want to have this capability, you can campaign for it with IBM. PLEASE RAISE A RUCKUS with your SE, with the support center, at IBM user group meetings, ANY WAY you are able to, and PLEASE WRITE A LETTER TO ME. I am very surprised by how people can put up with many inconveniences while they are programming in assembler or fixing assembler code, and not complain to IBM. They probably feel that IBM won't make a big coding effort. Well, folks, the coding effort has largely been made. Don't take the status quo for granted. You really CAN contribute to changing it, especially since the necessary code change already exists, and is operational. Finally, if you are currently NOT A LICENSEE of Assembler H and you see our illustrations, PLEASE LISTEN CAREFULLY. YOU CAN HELP THIS CAUSE MORE THAN ANYBODY ELSE! This may sound irrelevant to current ASM H users looking for an improvement, but IBM's main approach during our negotiations with them was: "Will these changes sell more Assembler H licenses?" This is the principal way that IBM upper management measures customer demand (silly as that may seem to us in this situation, with the Assembler being so pervasive in MVS and VM shops, and within IBM itself). NON-LICENSEES, PLEASE MAKE YOURSELVES HEARD! If IBM management senses that they will increase their licensee base by incorporating significant modifications to ASSEMBLER H, they will undoubtedly put much more effort into Assembler language development. What can you do? Please send a letter to me directly. My address is listed in this magazine in the PF1 column. Please make sure that my name appears on the envelope. I will try to directly forward all letters received to IBM management, and they will surely have effect. Second best, send a message to my NASCOM id, GOLOSHMA. Ask your SE or the support center how you can communicate with IBM directly or indirectly. Call the magazine and ask what else you can do to help, leaving your name and phone number. PLEASE DO SOMETHING. Such activity will wake IBM up from their deep sleep in the assembler language area. There is a very good chance that we can get some results, because IBM is largely driven by customer pressure. Thanks and good luck. See you next month.