MVS TOOLS AND TRICKS OF THE TRADE November 1993 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer IEHMAP, AND OTHER STORIES. I have a bunch of things to say today. I hope they'll be helpful to you, or at least they should set you thinking. We systems programmers are living in a changing world, and probably many of us are rethinking where we'll fit--where our niche will be in the future. Repositioning is probably on the minds of most of us, either in the back of our mind, or in the front. To my thinking, MVS isn't going away at this point. It's just too high-powered and does too much to be replaced by anything else. Although other systems are chipping away at its low end, MVS, on the large IBM mainframes, is extremely powerful and getting more so. IBM is a huge company even after its own "downsizing" process. The computing requirements of large installations are still best met by MVS, which is quite economical when it's called upon to do a lot of work. So in the forseeable future, MVS will have to be supported. Perhaps not by so many people, but there'll still be a job market for many of us. Nevertheless, while we are personally rethinking our future directions, we have to keep in mind the possibility of growing into some new skills. One possible direction is in software development. In many shops, the writing of code is being lifted away from the responsibilities of the average MVS systems programmer, who is spending more time installing someone else's code. Nevertheless, if a person manages to accumulate skills in manipulating components of the operating system through assembler language, there are jobs available to write "code for the masses" at many software houses. Again, this is not for everyone. Many people, justifiably, might want to learn a completely different and marketable skill. This suggestion is only for someone who wants to make a commitment in the direction of writing MVS software, or for someone who wants to stay in the systems programming field at an installation to become more skilled. However, the ironic question arises: In our new world of mostly OCO packaged software, how is it possible to develop your assembler programming skills from the MVS system programmer's job platform? I'll answer this as follows: It's a multi-pronged effort. First, you might try to study your installation's system and JES exits, for the purpose of understanding exactly what they do and how they do it. Second and far more important, there are tremendous storehouses of MVS coding examples, free for the looking. These begin with the CBT MVS Utilities Tape, which can be ordered through NaSPA. The CBT Tape not only contains a huge number of working programs to use and study, but it contains a pointer to other sources of such code through file 071, which shows you what's contained on many other public tapes. Third, there is a marvelous book which is far too under-used for its immense value. This book literally takes us to school. It directly and simply teaches us most of the advanced skills we have to know in assembler programming for the operating system. Among many other topics, this book explains: macro writing, channel programming, dynamic allocation in assembler programs, many ways of accessing a pds, issuing operator commands from a program, abend recovery using SPIE, ESPIE, STAE and ESTAE methods, writing SVC routines, and almost any other programming principle you'd like to know. It's a big book. It's title is: "Advanced Assembler Language and MVS Interfaces" by Carmine Cannatello, and it's published by John Wiley and Sons in New York City. You can call Diane Cerra at 212-850-6660, to order. Carmine Cannatello's book is an unbeatable combination with the CBT Tape, when both are taken together. In fact, the CBT Tape now contains all the coding examples from Carmine's book in machine- readable form, on file 069. How can you use this combination? You can look at any program on the CBT tape that you want to study. Then you can study the relevant parts of Carmine's book, where he teaches you the coding principles involved. Fantastic. Too bad nobody knows about this. You can be the first on your block to get on the bandwagon. After you're really skilled, you can try disassembling and studying pieces of system code. I'm not telling anyone to violate licensing agreements. I'm just suggesting that there is a large opportunity for permissibly and legitimately obtaining great skill and benefit through the use of disassemblers. We'll leave that study for a future column. But we are about to reap enormous reward from someone else's expert use of disassembly. The next story follows. IEHMAP. IEHMAP is mostly a VTOC and catalog listing tool, with many options and facets. To anyone who's an oldtimer in this field, IEHMAP is an old program. In fact, its 50-page user manual bears the date, October 1975. This belies the truth. IEHMAP has been thoroughly modernized and revamped by Guy Albertelli, who works for B.F. Goodrich in Brecksville, Ohio. The modernization process was not so simple. IEHMAP was only available in object code. Guy Albertelli disassembled some of its modules, and worked from there. IEHMAP had been available (on the older CBT Tapes) in object decks only, but it was free public code. After his disassembly process, Guy Albertelli made some massive updates at the source level. As a result, IEHMAP is now a very speedy program, using CVAF access to VTOCs. I can testify that I was able to map 250 volumes, mostly 3390 models 2 and 3 and some 3380K's, using the new IEHMAP, in eight minutes and change, on our large ES/9000 processor. The most complicated listing of a single volume takes a small fraction of one minute. That's pretty darn fast. This new version of IEHMAP is available on CBT Tape Version 337 or later, file 083. If you have an older CBT Tape, you should order a new one. To run IEHMAP, there's only one piece of basic JCL, which is illustrated in Figure 1. The important part of running IEHMAP is in the control cards. This is true because in Guy Albertelli's version, you do not have to specify a special DDNAME for each volume allocated. Guy's version of IEHMAP will dynamically allocate a DDNAME pointing to each volume that is accessed. To learn about IEHMAP's control cards, you should print out its manual, called $MAPDOC. You should also print Guy Albertelli's update notes, called $DOC390. Both of these are members of the pds which comes from CBT Tape File 083. The control cards I want to discuss are: NAME, MAP, CATLG and ATTRIB. Other related control cards are described in the $MAPDOC document. I would strongly advise reading Guy Albertelli's detailed caveats in the $DOC390 document. Do not try and use some of the more tricky functions of IEHMAP unless you have a spare scrap volume to play with. It's best to stick to the simpler functions that we'll describe now. One more item before we start. Guy Albertelli introduced the VSAM and ICF Catalog support to IEHMAP. Reading an ICF/VSAM catalog requires APF authorization for IEHMAP, which wasn't required before. That's because the reading of an ICF or VSAM catalog requires either entry of a password by the operator (each time), or JFCB password bypass, which allows a straightforward reading of the catalog without entering any passwords. The setting of the JFCB password bypass bit during catalog OPEN, is what requires running in KEY 0, and hence the authorization. Functions of IEHMAP which don't require the catalog read, will probably work if the program is not being run authorized. Please be aware of this consideration. Now to the meat. Running IEHMAP with the simple control card of "NAME VOL=volser" will produce an alphabetical listing of all datasets on the disk pack. If "MAP" is used as a control card instead of "NAME", then a track map of all datasets and extents sorted by CCHHR, is produced in addition to the alphabetical listing of datasets. MAP is probably the most common keyword that you'll use. Individual free extents are shown in the track map as "AVAILABLE". The "CATLG VOL=catvol,CNAME=catalog.name" control card will list the entire contents of a catalog, which could be VSAM or ICF. Finally, the "ATTRIB VOL=volser" will list all members of partitioned datasets on a volume, including their linkedit attributes (if load modules) and/or SSI values. See Figure 2 for exact coding of some of these control cards. IEHMAP also provides extensive filtering capability to limit these listings. These capabilities are described in detail in the $MAPDOC document. At the very least, you should use IEHMAP to map disk volumes, using the "MAP VOL=volser" control cards. This JCL should become a part of every systems programmer's stock in trade. And IEHMAP is very, very fast. See Figures 3, 4, and 5 for an illustration of these most commonly used IEHMAP functions. Space is running out now, and I'll have to postpone telling more "stories" until next time. Please play with this new version of IEHMAP. You'll be pleasantly surprised at its speed and the detail in its reports. Most people will probably scratch their heads and ask how IEHMAP can do so much, so fast. Good luck and much success in all your endeavors. See you next time. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. Basic JCL to run IEHMAP. Once this JCL is in place, the significant variations are in the choice of control cards. //IEHMAPA JOB (,SYSTM,99,99),S-GOLOB,CLASS=Q,MSGCLASS=V,NOTIFY=&SYSUID //* //SEQUNLD EXEC PGM=IEHMAP <=== from File 083 of CBT //STEPLIB DD DISP=SHR,DSN=SYS2.TECH.USER.LOADLIB <=== authorized //* because of VSAM/ICF catalog password bypass //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSIN DD * control cards /* * * * * * * * * * * * * * * * * * * * * * * * Figure 2. A few of the control cards available in IEHMAP. NAME - Produces an alphabetical dataset listing for a disk pack. MAP - Produces an alphabetical dataset listing for a disk pack, plus an extent list for the pack, sorted by CCHHR and showing free space extents. CATLG - Lists the entries of a CVOL, a VSAM catalog, or an ICF catalog. For VSAM or ICF catalogs, the CNAME keyword must name the catalog, and the VOL keyword must name the volume containing the catalog. ATTRIB - Lists the members of partitioned datasets on the given volume, showing directory entry information for the members. IEHMAP is very fast, and these results are obtained extremely quickly. //SYSIN DD * NAME VOL=SMB021 MAP VOL=SMB021 CATLG VOL=SMB021,CNAME=STAFF.CATLG ATTRIB VOL=ESACAP /*