MVS TOOLS AND TRICKS OF THE TRADE SEPTEMBER 2005 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. POWER VERSUS SAFETY I became a systems programmer (many many years ago) after having been an applications programmer, and the first thing I noticed when I made the switch, was that basically (within some limitations) I didn't have to ask anybody for "authority" anymore. The "systems doctor" was expected to fix the system whenever any repair or change was needed, and for the most part, once I got my bearings and my tools together, I found that I could "cut through the ice" whenever I needed to. The application programmer mentality of "do I have permission to access this?" basically flew out the window when I became a sysprog, and eventually it became a distant memory to me. I was only reminded of it afterwards, when I would speak to an application programmer about something. This is not to say that I could do anything I wanted to, using my employer's system. I was there to protect and preserve, and to keep the system running properly and efficiently. I was not there to change it against their will, or to break it, God forbid. In other words, my mandate was to use the power wisely. And therefore I needed to have the power in the first place, perhaps to a greater extent than most of the other people who worked there. So this brings us to today's topic. I want to talk about the general idea of how much power should be put into our tools, but also HOW the power should be put in, to minimize risk. If we encounter a situation and we know what we're doing, we certainly want to be able to do what it takes, to get the job done easily, efficiently, and accurately. But on the other hand, we don't want to expose ourselves to damaging the system by entering some typographical error, and killing something major. Our tools should not ever let us do that, easily. The bottom line is that our tools should have reasonable and decent safeguards in a normal situation, but they should still leave us free to do something unusual or even quite bizarre, if the situation genuinely calls for it. That is my general opinion on this subject, if I'm ever asked to put it into one sentence. Of course it makes a difference if you have the flexibility of writing the tools yourself, or if you are using commercially written tools, which have already been written for you. You can't change a commercial vendor's code--you can only submit a "change request" to the vendor, and it might not be listened to. Nevertheless, in either case, I feel it is important for every sysprog to spend at least SOME time, thinking about this general idea of "power versus safety" in tools, because it will sharpen you up, and you'll certainly learn how to use all of your tools much better in either case, whether they be user-written, or commercial. We'll now show you a specific case of a specific tool, that will illustrate this entire concept. CDSCB VERSUS A DIRECT ZAP TO THE VTOC I'll start the discussion with an illustration of a specific tool that has a lot of power, but which is still pretty foolproof, so we see that we don't always have to sacrifice power to achieve safety. The tool is a free TSO command called CDSCB (Change the DSCB). CDSCB can be found on File 300 of the free CBT Tape collection of MVS tools. (Do a www.google.com search on "CBT Tape".) I think that CDSCB is a powerful tool which still has a high degree of safety, and therefore it comes close to satisfying my idea of making a tool reasonably foolproof, but still giving it a lot of capability when you really need to have it. CDSCB was written by Bill Godfrey, and updated by other people since, notably Greg Price. A version of CDSCB which uses RACF for authorization checking to see if you're entitled to use it, is found on CBT Tape File 301 (adaptation by Mike Cleary). CDSCB performs the trick job of "zapping the VTOC entry" of a dataset on disk, to change the dataset's properties. For instance, one thing you can do by zapping the VTOC, is to change the size of the secondary extents allocation of a dataset, telling the "volume management" component of MVS how much space should be allocated in each new extent, whenever the dataset needs more extents. There are actually two fields in the Format-1 DSCB which do this--one of them is a raw number, and the other one says whether that number refers to TRACKS, CYLINDERS, or BLOCKS. This information resides in the Format-1 VTOC entry for the dataset, and if you zap the VTOC entry to a different value, the change will be permanent. So obviously, you can't afford to make a mistake. A tool (like CDSCB) which formats the fields of a Format-1 VTOC entry, and which works at the "field level", will do a better job than a tool (like AMASPZAP) which forces you to find the correct field in the VTOC entry yourself. If you use CDSCB, you'll always zap the correct field (although not necessarily with the correct value). If you use AMASPZAP, you might change the wrong field altogether, and cause real havoc and damage to the dataset. So why is all of this useful, and why would you feel that it is necessary to do this? A typical situation is when IBM's shipped dataset secondary space allocations have to be changed. For example, when IBM ships a new system, the secondary extent values for their DLIB datasets might be very small, often set to only a track or two for tens or hundreds of DLIB datasets. This makes it difficult for SMP/E ACCEPT jobs which add a lot of maintenance, to run cleanly later. They bomb when each dataset runs to 16 extents, many of them only a track or two apiece. To change the secondary allocation of a group of datasets, you can set up a TSO-in-Batch job which runs CDSCB APF-authorized (see CBT Tape Files 185 and 186 for help with how to do that), and which runs CDSCB against each dataset which has to be changed. See Figure 1 for an illustration of some JCL that runs CDSCB as a TSO command in batch, to do this job. You can run CDSCB against hundreds of datasets on your DLIB volumes, and fix all their secondary extents, exactly the way you want, so the MASS ACCEPT jobs don't blow up later because of "lack of secondary extent space". For some syntax rules on how to run the CDSCB TSO command, see Figure 2. Just to complete the picture of what we're up against when we have to zap a Format-1 VTOC entry for a dataset, I've included Figure 3, which shows a "raw" Format-1 DSCB entry (presented to us by the fine Fullscreen ZAP program from CBT Tape File 300) with none of the fields formatted. And I've also included Figure 4, which shows the same data as formatted fields, which of course, are easier to find and change accurately. By showing you what CDSCB does in its specific area, I'm trying to jog your mind to think of other tools in other areas, which may be more foolproof than the ones you are currently using. If you find yourself repeatedly doing some tricky and delicate manipulations to system data, maybe you can search for a program or write a program that does the same job, but with less risk, and which is less prone to error. Or you can email me, or email IBM-Main or another news group, and ask the people there, if anyone knows of a less risky tool which can help you. HOW MUCH FLEXIBILITY SHOULD YOU LEAVE IN THE TOOLS YOU WRITE? As I said before, even if you don't write your own tools, you can still think and philosphize about this subject. The activity of thinking in this direction, will sharpen you up a lot. I recently had to write a syntax checker for IBM tape volser names. You would code a volser name of up to 6 characters in some JCL, and my program would try and make sure that the volser name was acceptable to MVS, before inserting it into a VOL1 label for a new tape. The IBM tape label manual ("Using Magnetic Tapes" - SC26-7412) says that all alphanumeric characters, and national characters, special characters, and the hyphen are acceptable in volume serial names. So my idea of running a proposed volser name through a translate table which converted invalid characters to blanks, might work out well, but if I restricted the table too much, it might convert a printable character into a blank in the middle of the volser name, and that would NOT be acceptable. So I decided to just include all EBCDIC printable characters as unchanged, uppercase all lowercase characters, and leave it at that. I couldn't be too exact in following "the IBM rules" or I might run into a different problem. But in doing this, I would allow you to code (possibly) invalid characters into a volser. My dilemma was: "How exact should you be?" Of course, I could have taken a different approach, and I could have rejected any questionable character by substituting a question mark there. Then I'd stop the job and and ask you to fix it up and run it again. But this wasn't possible to do in my specific case. The requirement was that I had to place a volser into the new tape the first time, without allowing any reruns. So I did my best, even though I allowed a remote possibility of entering something invalid into the volser. I had to weigh "foolproof" against "power" a different way. I figured that the possibility of introducing a weird character into a volser was remote. Most people do not make that type of typographical error often. So in that case, I had to compromise on "safety" just a bit, and opt for "power". SUMMARY Every programmer who writes system level tools, has to make decisions about "power versus safety". It is very useful for us to think about this subject too, whether we write our own tools ourselves, or we just use tools written by others. We are the "system doctors" and we make very important adjustments which affect the very health of the systems we protect. If we find ourselves doing some very delicate system-level job, and we sense that a slight mistake might put the entire system at risk, we might look for a better and more foolproof tool or method which can accomplish the same job in a less risky way. If you write your own tools, you might decide to compromise the "safety side" and allow your tool to do something bizarre and "push the envelope" a bit. Commercial tool vendors sometimes do this too, but in such cases, they make a decision to protect the tool against an unskilled user, by requiring a password for certain more risky functions, or by employing some other "safety net". The bottom line is that every tool we work with, has decisions built into it, which relate to the question of "power versus safety". In our own lives, we might look for tools which give us more power, most of the time. But sometimes, for example when we have to zap fields in a dataset VTOC entry, we really want to do that job in as foolproof a way as possible. So we have to be very aware of the big question of "power versus safety" at all times. I wish all of you well, and hope to see you here again, next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. Example of Running TSO Command CDSCB Under TSO-in-Batch CDSCB is an APF-authorized TSO command, which can do its magic in bulk, as follows: In the illustration, secondary space for SYS1.ACMDLIB is set to 5 cylinders, and secondary space for SYS1.ACSSLIB is set to 45 tracks. //TSOBATCH EXEC PGM=IKJEFT01 //STEPLIB DD DSN=my.authrzed.library //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * CDSCB 'SYS1.ACMDLIB' VOL(C4DLB1) SPACE(5) ALLOC(CYL) CDSCB 'SYS1.ACSSLIB' VOL(C4DLB1) SPACE(45) ALLOC(TR) /* * * * * * * * * * * * * * * * * * * * * * * * Figure 2. Syntax of the CDSCB TSO Command, which illustrates what it can do. )F FUNCTION - THE CDSCB (CHANGE DSCB) COMMAND MODIFIES A DATA SET'S FORMAT-1 DSCB IN A VTOC. SINCE THE FORMAT-1 DSCB CONTAINS INFORMATION CRUCIAL TO A DATA SETS' SECURITY AND INTEGRITY, (AND IN FACT TO THE WHOLE SYSTEM'S SECURITY AND INTEGRITY), THIS COMMAND MUST BE RESTRICTED TO SYSTEMS SUPPORT PERSONNEL. )X SYNTAX - CDSCB 'DSNAME' EXPDT(DATE) SHR VOL(VOLUME) UNIT(UNIT) CREATE(DATE) REFDT(DATE) DSORG(XX) RECFM(XX) LRECL(XX) BLKSIZE(XX) ALLOC(TR/CYL/BL) SPACE(SECONDARY-AMOUNT) PWR/PWW/NOP/RACF/NORACF ZAP(OFFSET VERDATA REPDATA) REQUIRED - 'DSNAME' DEFAULTS - NOTHING WILL HAPPEN IF NO CHANGES ARE SPECIFIED. ALIAS - NONE * * * * * * * * * * * * * * * * * * * * * * * Figure 3. A raw (unformatted) image of a Format-1 DSCB (VTOC entry for a dataset). The tool which produced this image is the Fullscreen ZAP TSO command from CBT Tape, File 300. Z A P ENTER VALID COMMAND ABOVE OR ? FOR HELP VERSION=3.2Z 24JUN05 F/SBGOLOB.B.ASM/ 00000 >E2C2 C7D6 D3D6 C24B C24B C1E2 D440 4040 |SBGOLOB.B.ASM | 00010 4040 4040 4040 4040 4040 4040 4040 4040 | | 00020 4040 4040 4040 4040 4040 4040 F1C3 C1D9 | 1CAR| 00030 E3C7 F100 0169 0010 0000 0001 0000 C9C2 |TG1...........IB| 00040 D4D6 E2E5 E2F2 4040 4040 4069 00D4 0000 |MOSVS2 ..M..| 00050 0000 0200 9020 6D10 0050 0000 0082 8000 |......_..&...b..| 00060 01C2 0A8C 02C1 E800 0001 0002 7800 0303 |.B...AY.........| 00070 4000 0200 0000 0000 0000 0000 0000 0000 | ...............| 00080 0000 0000 0000 0000 0000 0000 |............ | ***** SCAN MATCH ***** OFF: 0000 ( 0) ADDR: 00000 ( 0) DSN: VTOC FOR CARTG1 LEN: 008C ( 140) BASE: 00000 ( 0) CCHHR: 000000020C TTR: 00010C * * * * * * * * * * * * * * * * * * * * * * * Figure 4. A formatted image of the same dataset shown in Figure 3. This image was produced by the vendor product, StarTool FDM from Serena. The option was FIXPDS, followed by the option of "Update the Format-1 DSCB". ---------------------- FIXPDS: Format 1 DSCB Modification --------------------- OPTION ===> Current - DSN=SBGOLOB.B.ASM,VOL=SER=CARTG1 MEM= ----------------------------- DSCB1 at 000000020C More: Caution: many of the fields of the Format 1 DSCB can not be changed without compromising data set integrity. For more information using field level help, place the cursor on any of these items and press HELP OFF,LEN LABEL HEX VALUE DESCRIPTION (0,44) DS1DSNAM ===> SBGOLOB.B.ASM (2C,1) DS1FMTID ===> F1 Format identifier (2D,6) DS1DSSN ===> C3C1D9E3C7F1 Data set serial name (33,2) DS1VOLSQ ===> 0001 Volume sequence number (35,3) DS1CREDT ===> 690010 Creation date (38,3) DS1EXPDT ===> 000000 Expiration date (3B,1) DS1NOEPV ===> 01 Number of extents on volume (3C,1) DS1NOBDB ===> 00 Number of bytes used in last directory (3D,1) ===> 00 Reserved (3E,6) DS1SYSCD ===> C9C2D4D6E2E5 System code (44,7) ===> E2F24040404040 System code (last 7 characters) (4B,3) DS1REFD ===> 6900D3 Date last referenced (4E,1) DS1SMSFG ===> 00 System managed storage indicators (4F,1) DS1SCXTF ===> 00 Secondary space extension flag (50,2) DS1SCXTV ===> 0000 Secondary space extension value (52,2) DS1DSORG ===> 0200 Data set organization (54,1) DS1RECFM ===> 90 Record format (55,1) DS1OPTCD ===> 20 Option code (56,2) DS1BLKL ===> 6D10 Block length (58,2) DS1LRECL ===> 0050 Logical record length (5A,1) DS1KEYL ===> 00 Key length (5B,2) DS1RKP ===> 0000 Relative key position (5D,1) DS1DSIND ===> 82 Data set indicator flags (5E,4) DS1SCALO ===> 800001C2 Secondary allocation type and amount (62,3) DS1LSTAR ===> 0A8C02 TTR of last used track and block of data (65,2) DS1TRBAL ===> C1E8 Bytes remaining on last track used (67,2) ===> 0000 Reserved (69,10)DS1EXT1 ===> 01000278000303400002 Extent 1 in XX00CCCCHHHHCCCCHHHH (73,10)DS1EXT2 ===> 00000000000000000000 Extent 2 in XX01CCCCHHHHCCCCHHHH (7D,10)DS1EXT3 ===> 00000000000000000000 Extent 3 in XX02CCCCHHHHCCCCHHHH (87,6) DS1PTRDS ===> 0000000000 CCHHR of any associated Format 2 or 3 DSCB