MVSTOOLS.SEP MVS TOOLS AND TRICKS OF THE TRADE by SAM GOLOB Sam Golob is a senior systems programmer at Newsweek, Inc. He is an expert in MVS maintenance using SMP. I do not consider myself a more knowledgeable MVS systems programmer than most of you esteemed readers out there. All of you have your "pet tricks" and clever ways of doing things. All of you have some experience that I don't have. We all tend to take our own knowledge for granted, and we tend to think everyone else does things pretty much the same way we do. Well it just ain't so. I get a big charge out of going to another data center just to see how they do things. I happen to have a very long commute to work (approximately 80 miles), and just about every MVS shop that is located between Central New Jersey and Northern New Jersey is can be on my way to work. My boss (bless his heart) is very understanding about my flexible hours as long as I put in the proper amount of time at the job. Therefore, I visit friends at other data centers quite often. Each data center does things very differently. Everyone has a different hardware configuration and often they have different levels of the operating system software. The varied scattering of vendor products in each site also contributes to the different working methods used by each individual programmer. Every person's working history has resulted in a unique perspective. One person has written a lot of JES2 exits. The next person has run JES3. Another person has to contend with all kinds of DASD management rules. One person has to administer RACF and interface between RACF and different devices; another shop has ACF2; still others have no security at all or they still use MVS passwords. These differences in environment force every individual to have a unique set of tools and way of doing things. People in our profession are starting to recognize that we can't do it all alone. There is power in numbers and in mutual help. Anyone who belongs to a local user group or has gone to SHARE or GUIDE (and now NaSTEC) can testify that their "modus operandi" has been improved in some way -- a lot of times in many ways. Why do you read Technical Support anyway, if not to expand your knowledge and benefit from what someone else has learned? What am I getting at? Simply this. You don't have to be an all- around expert to help somebody else. Each one of us comes up with something pretty slick once in a while; it comes with the territory. That's part of what we get paid for, because if a robot or an untrained person could do our jobs, we'd all be out of work. Don't think for a moment that someone else came up with the same slick idea you did. Others have different problems. They are working in different shops. No one else can benefit from your work, unless you do one of several simple things: o Tell your friends. o Bring the matter up at a user group meeting. o Write something up and upload it on NaSCOM. o Submit your idea to one of the MVS public-domain tapes. o Write a note to this magazine or write an article. My friends, I am no different than any of you. All I've ever done is share my experiences. If you profit from anything I am saying, I assure you that many other people in the profession can profit just as much from what you have to say. Remember, what goes around comes around. By becoming an active participant in your profession, you will make a lot of new friends who share the same interests as you. What have you got to lose? The SLAC Mods This month features a marvelous product extension that, unfortunately, not too many people know about. It's a series of improvements and enhancements to IBM's Assembler H Version 2 called the SLAC Mods for Assembler H. The SLAC Mods were written by Gregory J. Mushial of the Stanford Linear Accelerator Center in California. They are one neat piece of work. People who know about them hope that the SLAC Assembler H will provide IBM with future direction in remedying some of the glaring deficiencies in MVS (and MV) Assembler H Version 2. (Be it known that the mods were originally developed under VM.) This is not to knock IBM completely. Assembler H is a very good product that we all depend upon. Its main problem is that it "knows" more than it tells. None of the MVS (or for that matter OS) assemblers indicate, conveniently in one place, which macros were used by your assembly. The assembler has to "know" the information, because it must pull the text of the macros out of a library and process the material in detail. That the assembler won't give the full names of the macros it found, and that it won't provide even a summary report about them is absurd beyond belief. All the DOS and VSE assemblers create a list of macro names hit by the assembly, and they have done so since the beginning of time. The old IFOX00 assembler has some mods on the CBT and SPLA tapes (CBT file 300 called $$MACROX), that show which macros were found by an assembly. I am grateful to Bill Godfrey for writing them, and I used them extensively for a time, but you can go only so far in today's world with IFOX00. You need assembler H. I was so interested in such a mod for assembler H, that I wanted to write it myself. But not wanting to reinvent the wheel, I nosed around to see if the work was already done. That's how I found the SLAC Mods from Greg Mushial. The SLAC Mods have a beautiful macro reference at the beginning of the assembly that will list which macros are MISSING and which ones are INLINE, but that is only one small piece of what the mods can do. There are four types of enhancements: o Improvements to the assembler reports. o Extensions to the Macro Language. o Extensions to "Open Code" Assembler Language. o "Run time" improvements. The Main Attractions The two most immediately useful modifications are the MACRO listing and the USING listing. The macro reference is turned on by the assembler option "MSRC." Sources for "COPY CODE" are also shown together with the MACRO origins that are displayed. The MACRO listing, which points out the LIBRARY NAME and VOLUME SERIAL where each macro was found, comes in very handy when packaging code to be sent out somewhere. The listing provides verification that all the necessary macros in the right versions are included with the code being shipped. Also, when a software product is assembled, it's very useful to know what macros are involved with the code, and where they came from. The listing of all "USING" assembler statements, found at the top of each page, makes it much easier to fix code. The "UMAP" assembler option turns this feature on. Since the tied-up registers are conveniently displayed, the programmer won't be tempted to reuse them to hold some data and thus introduce bugs into the program. This beats conducting a lengthy search through pages and pages of code, with a large possibility of missing a USING statement somewhere. All the USINGs are visibly clear at the top of the page, so no more guesswork. Another annoying assembler inconvenience that is addressed by the modifications concerns the location counter. A programmer can be searching through the code looking for some particular displacement and all of a sudden, the numbers aren't right. This is often due to a DSECT stuck in the middle of the main code. The location counter is showing the DSECT displacements, and it is hard to tell what the current location is. Two improvements address this. The first one is a change in the header display for the location counter. At the top of a page that has begun in the middle of a DSECT, the header says "D-LOC" instead of the usual "LOC." The regular location counter header "LOC" is shown when the page header falls in the middle of a CSECT. Thus, a quick glance at the top of the page will inform the programmer what part of the code is being displayed. The second improvement is the DSECT CROSS REFERENCE at the beginning of the assembler listing, created if the option "DXREF" is turned on. This lists all DSECTS assembled with the program, the line number at which each begins, and their length in hex. Using the DSECT CROSS REFERENCE, a programmer can visualize the parts of the listing in advance, to "scope out" where the DSECTs are. Other Reporting Enhancements It is possible to get "OPCODE COUNTS," which include counts of how many times a MACRO was hit, as well as how many times an opcode was hit. This is turned on by the option "OPCNTS." A "NON-REFERENCED SYMBOL LIST" can be printed at the end of the assembler listing, if you turn on the option "NRLIST." This is a list of all labels that have not been referenced by code in the assembly. It may not be desirable to eliminate these labels; they may be important to help follow the coding logic. Seeing all of them together can give a programmer an edge in improving the coding design. The old IFOX00 option "LIBMAC" was improved and reinstated. This option had been dropped altogether from Assembler H. Programmers seldom used this option, which prints the full source of all found macros right in the listing. IFOX00 printed all of the macro source after the "END" statement. Assembler H, which can have multiple "END" statements if its "BATCH" option is used, evidently caused confusion as to where the expanded macro source should fit in the listing. The SLAC ASSEMBLER H puts them in the listing, right before the expansion of the macro is printed. Thus, a comparison of SOURCE with EXPANSION can conveniently be done, in the rare instances when it's needed. Another change is apparent in the assembly listing. When looking at a LABEL CROSS REFERENCE or "XREF" listing, you'll notice that some of the statement numbers are underlined. This occurs when the assembler determines that the operation being performed was trying to change the value of the referenced field. It is an attempt to show the difference between INQUIRY and UPDATE with reference to statement labels. At a glance, the reader can tell if the location is being UPDATED or merely referenced. Again, the programmer is being helped to zero in quickly on a specific reference. An EXCP count of READS and WRITES to the SYSUT1 work file of the assembler is provided at the end of the listing. It's also possible to force an incore assembly, using the "NODISK" option. Since no I/O is done to the work file when "NODISK" is set on, the assembly is significantly more efficient than if "DISK" is on. The problem with this is that if you run out of core when "NODISK" is on, the assembler aborts. To avoid the abort, just keep "DISK" on. The SLAC Assembler always shows how much main storage would be necessary if the user wished to force the assembler to avoid using the work file. This report will indicate whether an incore assembly of this particular code would have been safe, considering the amount of REGION that you are running with. These constitute most of the reporting changes in the full assembly listing itself. The SYSTERM file was also changed around considerably to enhance its usefulness to the programmer. The SYSTERM File The SYSTERM file is intended to provide a summary of the success or failure of the assembly to the programmer. As its name describes, the output has to be short, so a programmer at a "limited view" terminal can check the assembly quickly. Most of the SYSTERM changes in the SLAC Assembler were designed to remove the clutter from what should be a simple listing. Here are a few of the changes. The DECKID (name field of the first TITLE card) is printed on each SYSTERM summary, to help avoid confusion when doing multiple assemblies in one run with the BATCH assembler option. A "clean" SYSTERM listing now contains only the statements "ASSEMBLER DONE" and "NO STATEMENTS FLAGGED." The rest is suppressed for the sake of clarity. For errors in macro calls, the SYSTERM is simplified and made to look more like the assembler listing. Only essential material to diagnose problems is printed. Language and Run Time Enhancements The SLAC Mods have introduced new freedom in the macro language and in conditional assembly. In open code, a completely new concept of "LABELED USINGS" and "QUALIFIED USING REFERENCES" force an address to be resolved by a particular active USING, when several are active at the same time. This construct prevents unnecessary tying-up of registers to resolve addresses. More details on these language changes can be found with the SLAC Assembler documentation. Run-time changes, besides the possibility of forcing in-core assemblies, include the possibility of using an ASSEMBLER SYSPRINT EXIT. Also, it is no longer necessary to have the macro library with the longest LRECL first in the SYSLIB concatenation. The new assembler is smart enough to find the library with the longest record length in the concatenation and to allocate the size of its buffers accordingly. The Current and Future Status of the SLAC Mods Many programmers are happy to use the SLAC Assembler for the report changes, but are afraid to use the new language improvements for fear that IBM will not pick up on these enhancements. Then they would not be able to transport any extended code to a place that has the "ordinary" assembler. What can be done about this situation? First, if you are licensed for Assembler H Version 2 from IBM make an effort to acquire the SLAC Assembler, too. The reporting enhancements will make your programming jobs easier and more enjoyable, with the existing assembler language. Second, please urge your IBM "Systems Engineer" to file a "PASR" Enhancement Request with the Assembler H development group. Request that the SLAC enhancements for Assembler H Version 2 be absorbed into the main IBM product, so everyone can benefit. Also, the burden of supporting the mods for new assembler changes will be lifted from non-IBM personnel. Then everyone will be able to use the new language extensions and the efficient register usage, without fear of portability problems. IBM has a good record of responding to a mass of PASR requests. If you take the time to cast your vote, IBM will surely feel the pressure and the need for the changes. Meanwhile, there exists a version of source updates, now in beta- test, that combines the unchanged SLAC Mods with the new ESA opcodes. This has been coordinated with further updates that correspond to Assembler H source changes through PUT Level 8902. Several obstacles must be cleared before I can inform licensees of Assembler H Version 2 how to get this new set of updates. I hope to be able to get more information to you soon, hopefully by next month. Good luck in all your endeavors. See you next month. /* 2567