MVS TOOLS AND TRICKS OF THE TRADE MAY 2000 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. ACCUMULATING ASSEMBLER TECHNIQUES Newer MVS systems programmers are amazed at how much the "old-timers" know about the MVS operating system. It is manifestly true that the MVS (aka OS/390) operating system has a tremendous number of software parts and components which work together. And to a new person, the older practitioners seem to be thoroughly knowledgeable in them, while most newer MVS people (there are a few exceptions) scratch their heads in amazement, and wonder how. Today, I'd like to show the true reasons why the old-timers know so much about the "current" MVS systems. I would have "logically" surmised that the opposite should be the case, but that's not so at all. Old-timers have newer systems programmers (generally speaking) solidly beaten, when it comes to thorough "insider" knowledge of MVS internals. The main reason is that much of MVS is old code--25 or more years old. The second reason is that the OS/360 systems, through MVT, VS2, MVS/370, MVS/XA, and MVS/ESA have always been upwardly compatible. Most of the old programs will still run on the newer MVS systems. Therefore, MVS knowledge that has been built over time, usually does not become obsolete. The old facts continue to be true, for the most part. So as the systems get newer, the only things the older people have to learn, are the exceptions and the new features. The rest of their knowledge remains solidly intact, and it's just as true as it was 30 years ago. Newer people wonder if there's a way to catch up. I think there is, but it takes a lot of work, and a plan. Today, I'm here to provide the plan. You and I both, will have to do the work. THE ASSEMBLER BASIS FOR MVS KNOWLEDGE No matter what anybody says, the MVS operating system is written in Assembler Language. Of course, there's IBM's internal PL/1-like language, whether they call it PL/S, PL/AS, PL/X, or whatever. But everyone will admit that these languages were only made to quicken the development of what is essentially Assembler code. IBM needed an edge on its competitors, to be able to develop system-level code faster than the others could, so that's why they invented these proprietary languages. But I'll prove that their purpose was only to develop Assembler code; the output of these PL/whatever compilers is not an object deck--it's only Assembler source code! Since the Operating System was constructed using Assembler, it follows that utilities which manipulate Operating System constructs-- control blocks, system data, queues, or whatever--should also best be made, using Assembler. So where's the "edge" that old-time MVS system programmers have? It's in their Assembler skill, and specifically, in the fact that they know how to access the MVS components and data structures in Assembler language programs. Today is the "age of OCO". Source code for the system components and for utilities which manipulate them, is being hidden away by IBM, and much more so by the other software vendors. An up-and-coming systems programmer today, is handicapped by this trend. Where can you learn about system coding, if you can't see any code? Well, you can see SOME of the code. The older programs in the operating system, which aren't (yet) OCO (Object Code Only), are still available in the Optional Materials that you can order from IBM. Also, IBMlink supports a facility to "view system module" source code, even if it's OCO, provided that your installation is licensed for that product. But to a newer programmer, especially with today's emphasis on just installing products "out of the box", it's daunting to try and break in. You don't have so much time. And you just don't know where to start! THE PLAN. I have a plan how to break into learning about MVS system internals. Many have followed this plan, and succeeded to an amazing degree. In essence, this is really the same plan that the old-timers followed when they were breaking in--only at that time, it was the "official" way that systems programmers worked. Nowadays, it's only optional, at best. Today, you need to supply your own ambition. Under present-day job conditions, this motivation to grow doesn't usually come from the job itself. The idea of the plan is to write, or fix, your own system utilities, and thereby to accumulate knowledge about how to manipulate the MVS system parts. Each utility will access one, or several, MVS system components, and/or will manipulate some data. By gathering experience, first with one utility, then with another, then with still another, you'll eventually accumulate a great store of knowledge about many system components. All of this knowledge will serve you in good stead, for years to come. IBM isn't about to ruin all the code running in all the MVS shops, by changing the system so much, that the old programs won't work any more. Usually, it's easier to start by fixing a utility, than by writing it from scratch. In the old days, people would usually write their own utilities from scratch, and obviously, that gave the better training. But these days, with less job-induced motivation, and less time for the project, it's probably better to start by looking at somebody else's programs. Fortunately, we have enormous repositories of old utilities that are freely available for anybody to look at. The first source for ready-made utilities that have source code, is the CBT MVS Utilities Tape web site that is accessible online through the Internet. If you want more info on CBT Tape materials, you can email me. The CBT Tape web site has its own URL, and is completely publicly accessible, but if you're a NaSPA member, you can also get to it from the members only section of the NaSPA web site: www.naspa.net . Besides the CBT Tape web site, there are the older materials from the Xephon archives (1997 and back) that are available to non-subscribers of the Xephon journals. If you want to explore further, you can follow the links to other MVS-related sites from the CBT Tape web site, NaSPA's web site, or Eric Loriaux' web site at www.loriaux.com . The CBT Tape materials are actually available as a tape, or on cd-rom. For more information, email Sam Knutson at sknutson@cbttape.org, or contact the NaSPA office, or do both. Now that we know where to start looking for old utilities, how do we begin using the materials, and where do we break in? The answer is: look through the CBT Tape contents on File 001 of the CBT Tape, and pick something that seems interesting to you. Then go download the file(s) containing the source code, and start looking at it. Try the program, and see how it works externally. Then look at the code, and try and see how it does it's "magic". Gradually, the workings of the system components, as they are accessed, will unfold to you--one component at a time. Let's start with an example. Consider the COPYMODS program from File 229 of the CBT Tape. COPYMODS is a utility which allows you to make from one to ten duplicate copies of all files in a magnetic tape, including the labels. Obviously, in order to do this, the COPYMODS program requires that you have "BLP privilege" for your userid, in both the JES class and in the security system, because the program ignores all the label information in the output tape(s), and most of the label information in the input tape. The COPYMODS program requires the ddname IN for the input tape, and OUT1, OUT2, ... thru OUT10 optionally, for up to 10 output tapes. See Figure 1 for sample COPYMODS JCL. Why are we mentioning COPYMODS here? Because we want to learn some system internals information from the way COPYMODS works. And it'll be the same idea, from any other utility program you study. The COPYMODS program has to find out which ddnames you've coded in your JCL, in order to figure out which output files to open. You may want to make only one output tape, in which case you'd only code one output DD card, perhaps OUT1, or it could be OUT4 or OUT7. Or possibly you might want to make four tape copies, as illustrated in the sample JCL of Figure 1. Then you'd code four output ddnames, perhaps OUT1 thru OUT4. When the COPYMODS program starts executing, it has to determine which ddnames that look like OUT1 thru OUT10, are present in your JCL. Once you see how COPYMODS does this, you'll learn about the TIOT control block, and how to access ddnames in an Assembler program. This will be a piece of knowledge that you'll store up for the future. Look at the code snippets in Figure 2. You see how to access the beginning of the TIOT (Task IO Table) control block from the CVT (Communication Vector Table) that is the starting point for getting to most MVS system information. The beginning of the CVT is pointed to at virtual storage location X'10', or decimal 16. This was true at the beginning of OS/360, with real storage location X'10', and it'll probably always be true, as long as this operating system exists. Once you've got the TIOT and point to the first ddname, you can start checking for the presence of the ddnames you're looking for. If, in the future, you ever have to check for the presence of a ddname in a program, you'll always know how to do it. BUILDING FOR FUTURE KNOWLEDGE Now that you've seen a piece of this process, you can go about starting to accumulate knowledge for yourself. Pick a utility you like, and study its parts. Try and change the program a bit, using some of the other things you've already learned. Test the changed program out, to see if you've actually accomplished the result that you'd wanted to achieve. As you build success upon success, your knowledge will grow accordingly. And over the years, your own knowledge can build, even to the point of equalling that of the old-time experts. It all depends on your ambition. Good luck. I hope to see you again next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. Sample JCL to run the COPYMODS program from File 229 of the CBT MVS Utilities Tape. DD for the input tape is IN. DD for one to ten output tapes is OUTn, where n can be any number from 1 to 10. The COPYMODS program has to find out which output DD names are present. For this purpose, it must search the TIOT (Task IO Table) control block, and make a determination which output files to open. Note that the output VOLSER's are dummy names. MVS JCL requires that they be different from the input VOLSER. But the output tapes will contain exactly the same data as the input tape, including the labels, if any. //SBGCSCP JOB (A006,SYTM,99,99),S-GOLOB, // CLASS=Q,MSGCLASS=V,NOTIFY=&SYSUID //* //********************************************************** //* COPY 2 TAPES - EVERYTHING //********************************************************** //* //COPY EXEC PGM=COPYMODS,REGION=4096K //STEPLIB DD DISP=SHR,DSN=SYS2.MVSP.SDTS.USERLIB (authorized) //SYSPRINT DD SYSOUT=* //IN DD VOL=SER=CBT406,DISP=OLD,UNIT=NOSILO,LABEL=(,BLP) //OUT1 DD VOL=SER=CBT40A,DISP=OLD,UNIT=EXPORT,LABEL=(,BLP), // DCB=TRTCH=NOCOMP //OUT2 DD VOL=SER=CBT40B,DISP=OLD,UNIT=EXPORT,LABEL=(,BLP), // DCB=TRTCH=NOCOMP //OUT3 DD VOL=SER=CBT40C,DISP=OLD,UNIT=EXPORT,LABEL=(,BLP), // DCB=TRTCH=NOCOMP //OUT4 DD VOL=SER=CBT40C,DISP=OLD,UNIT=EXPORT,LABEL=(,BLP), // DCB=TRTCH=NOCOMP * * * * * * * * * * * * * * * * * * * * * * * Figure 2. Code from the COPYMODS program which checks if any ddnames from OUT1 to OUT10 are present in the JCL. DD names from the JCL, go into the TIOT (Task IO Table) control block, which is accessible from the CVT (Communication Vector Table) using the following code: This code hasn't gone "out of style" in 25 years, and it still works perfectly. This shows you how to access ddname information in an Assembler program. * * DETERMINE WHICH OUTPUT DD'S ARE PRESENT * L R2,16 R2=CVT L R2,0(,R2) R2=TCB WORDS L R2,4(,R2) R2=MY TCB L R2,12(,R2) R2=TIOT LA R2,24(,R2) R2=FIRST DD ENTRY TIOTLOOP CLC 0(4,R2),=XL4'00' END OF TIOT? BE OPENS YES CLC 4(8,R2),OUT1+40 OUTPUT FILE NUMBER 1? * Test hard-coded ddname in DCB * against TIOT entry coming from JCL. BNE TIOT1 NO OI FLAG1,OP1 YES. MARK ITS PRESENCE B TIOTNEXT CONTINUE LOOKING AT NEXT ENTRY TIOT1 CLC 4(8,R2),OUT2+40 OUTPUT FILE NUMBER 2? * Test hard-coded ddname in DCB * against TIOT entry coming from JCL. BNE TIOT2 NO OI FLAG1,OP2 YES. MARK ITS PRESENCE ****** thru TIOT9, similar code checking the 10 names. TIOTNEXT SR R3,R3 IC R3,0(,R2) R3=LENGTH OF DD ENTRY AR R2,R3 R2=NEXT DD ENTRY B TIOTLOOP GO CHECK IT * * OPEN ALL FILES * OPENS OPEN (IN,,SYSPRINT,OUTPUT) MVC FLAG3(2),FLAG1 SAVE INDICATION OF WHICH FILES ARE HERE TM FLAG1,OP1 OUTPUT 1 PRESENT? BZ OPEN1 NO OPEN (OUT1,OUTPUT) OPEN1 TM FLAG1,OP2 OUTPUT 2 PRESENT? BZ OPEN2 NO OPEN (OUT2,OUTPUT) ****** etc. Test thru 10 ddanmes. IN DCB MACRF=(E),DDNAME=IN,DEVD=TA,DSORG=PS,RECFM=U OUT1 DCB MACRF=(E),DDNAME=OUT1,DEVD=TA,DSORG=PS,RECFM=U OUT2 DCB MACRF=(E),DDNAME=OUT2,DEVD=TA,DSORG=PS,RECFM=U ****** etc. Thru the 10 output DCB's. * * * * * * * * * * * * * * * * * * * * * * * Figure 3. An excellent Assembler Language book for Systems Programmers. This book will teach you many techniques for accessing MVS operating system services. This book is a "must have" for all MVS systems programmers. Title: Advanced Assembler Language and MVS Interfaces Second Edition Author: Carmine A. Cannatello Publisher: John Wiley & Sons Inc. Professional, Reference and Trade Group 650 Third Avenue New York, NY 10158-0012 (800) 225-5945 x2497 ISBN: 0-471-36176-3