MVS TOOLS AND TRICKS OF THE TRADE JANUARY 2001 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. TAPES AND THEIR LABELS In doing the business of MVS (and OS/390) systems programming, everybody has tasks. In a sense, your "experience" consists of the sum of all the tasks you've done, the knowledge about the system that you've gathered, and your attitude. Attitude is very important. My first boss, many years ago, impressed on me that you have to face every task and every problem with a "can do" attitude. You go into the problem with a mind set, that "I can solve this!" With such an approach, and with persistence and creativity, you almost certainly will solve your problems and accomplish your tasks. Everybody's particular experience in the systems programming business is somewhat different from everybody else's, but there is overlap. The overlap, or "common factors" in MVS systems experience, makes it possible for us to talk to each other, and to learn from the problems that other people have had to solve. Usually, a problem that we're currently faced with, has been handled effectively by someone else too. An Internet forum such as the IBM-MAIN list (see my April 1999 column) provides a place to trade experiences on a topic. Also, one can look in the large utility collections such as the CBT Tapes, which are available online as well. There, you can see coding examples and tools that can also help you solve your work-related problems. My own experience has forced me to often deal with tapes. For some of us, tape processing is peripheral, or even non-existent. Most of us deal with tapes once in a while. Some of us, especially if we've been setting up a tape management system, or a virtual tape system, or a tape robot, have had to deal with tapes very often. In my travels, I've had to make tapes and copy tapes. I've had to convert Standard Labeled (SL) tapes to Non-Labeled (NL) tapes. Going the other way, from NL to SL, is very difficult, but I've solved that too. Today, I'd like to share some of my very extensive experience with tapes, so that you can add my experiences to your own store of knowledge. LABELED and NON-LABELED Tapes. Tapes contain sequential files, and are sequential by their very nature. Practically the only "direct" thing about a tape is the "Locate Block" channel command, which you can read about in the tape hardware book I'll mention later, and that's sequential too. Tape files are broken into physical blocks. The BLOCKS are separated from each other by un-recorded spaces on the tape, called "interrecord gaps", and the FILES are separated from each other by special hardware-generated character sequences called "tape marks". So, to summarize what a non-labeled tape looks like, there are blocks of data which comprise the first file, each separated from the next by an interrecord gap, and at the end of the file, there is a tape mark. The blocks of the second file follow, followed by a tape mark. Finally, after the last file on the tape, there are two tape marks in a row. This marks the end of data on the tape. If that's what a non-labeled tape looks like, then what are tape labels, what do they do, and how do they make a tape into a Standard Labeled tape? Tape labels are files too. They are in a special format which the MVS operating system recognizes, so that they are not treated as data files. Nevertheless, in reality, tape labels are also files, but we have to understand the format they are in, and how they relate to the "real data" that is on the tape. On a "Standard Labeled" IBM tape, or SL tape for short, the label files consist of groups of 80-byte unblocked records, which surround each data file. The label file which precedes each data file, consists of the "header labels", and the label file which follows each data file, consists of the "trailer labels". In front of the header label file group at the very beginning of a tape, there is a special record called a Volume Label, or VOL1 label, which defines the Volume Serial name of the tape, and the "tape owner". So an SL tape file on a tape really consists of three files. The first file is the VOL1 label followed by a set of header labels, followed by a tape mark, and this is followed by the data file. After the data file is a tape mark, followed by a set of trailer labels. If that file is the last file on the tape, the trailer labels are followed by two tape marks. Otherwise if other files follow, there is one tape mark after the first file's trailer labels, and then comes another similar three-file "sandwich". You see that an SL tape actually has three times as many files, as an NL tape has. That's because an SL tape has each data file sandwiched between two label files. The MVS operating system tape I/O routines use some of the information that is in the tape labels, to tell the job about the nature of the tape files. Tape label information, when you process a tape as Standard Labeled, gets merged into the DCB information and the JCL information to help fill in the fields of the JFCB (Job File Control Block). At this point, I should mention the two IBM books that are most valuable in dealing with tapes. One book is the obvious one--this is the DFP book called "DFSMS: Using Magnetic Tapes". The OS/390 2.10 version of this book has number SC26-7341. The second book is harder to find, because it is a "hardware book", but it is invaluable nevertheless. This is the "IBM 3480 Magnetic Tape Subsystem Reference" which has number GA32-0042. There is an equivalent 3490 book which is just as useful. These books show you the channel program commands you can use to actually manipulate tapes on tape drives. These books can be thought of as the "Principles of Operation" books for tapes and tape drives. The "System 390 'Green Card'" also contains the Magnetic Tape EXCP instruction codes as well, but the "card" doesn't contain the amount of detail and the programming hints that the hardware books do. COPYING TAPES Most JCL-centered methods for copying tapes, are oriented to copying one tape file at a time. They are not geared to taking an entire tape with all its files, and making a duplicate of it. Furthermore, if you want to copy some of the files from one tape to another using "conventional methods", you usually have to resort to a multi-step job. If you happen to be dealing with a tape that has 500 or more files, multi-step methods can get awkward. However, we have better ways of copying tapes. Let's examine the simple principles that go into copying a tape, and after you see them, you'll see how silly it is, to try and copy a multi-file tape, one file at a time. As one more preface, I have to mention BLP tape processing. Usually, the MVS operating system looks at a tape label as if it were something "special", and not just a tape data file. If you specify LABEL=(n,SL) or LABEL=(n,NL) in your JCL, and the tape you mount is a Standard Labeled tape, the system will attempt to read the contents of the VOL1 label and the first set of headers. If you write your own program, you can't read the labels themselves as files, unless you tell the MVS operating system to ignore them. You do that, by specifying the parameter LABEL=(n,BLP). BLP processing, to bypass looking at tape labels, is a restricted function in most shops. Its use can be controlled either through JES JOBCLASSes, or through RACF, and the average programmer usually can't use BLP processing. However, since we're the system doctors, we sometimes need this tool, and you should know how it can be invoked in your shop. If you want to see a coding example of how to get around BLP restrictions, see File 171 from the CBT Tape collection. The DITTO and TAPEMAP programs there, get around BLP restrictions. Now, how do you copy an entire tape, in principle? Using BLP, in order to regard any labels as files, you'd simply open the input tape, open the output tape, read the first file on the input tape, and copy its blocks to the output tape. When you come to the first tape mark, you'd write a tape mark on the output tape. Then you'd go read the next file on the input tape and copy the blocks. At the end of that file, when you encounter a tape mark on input, you write a tape mark on output. You continue in the same manner, until you encounter two consecutive tape marks, and then you stop, confident that you've copied the entire tape, end to end. Is this true? Almost, but not entirely. When is it NOT true? If you use two consecutive tape marks as a stopping point in reading and copying a tape, sometimes you'll stop too soon. This happens if you're copying a Standard Labeled tape using BLP processing, and one of the files contains no data. Then, you'll have a set of header labels followed by a tape mark separating the header labels from the data file. But in this case there is no data. So there is another tape mark separating the (nonexistent) data from the trailer labels. Since there is no data separating those two tape marks, they are now consecutive, and a dumb tape-copying program that stops whenever it sees two tape marks, will stop after having copied these header labels only. The rest of the tape files will be erroneously ignored. You can see, and use, an actual program which operated this way. It is the old COPYMODS program from File 229 of the CBT MVS Tape. The original version of COPYMODS, which stopped blindly after two tape marks, can now be found as member COPYMODO on File 229. It is clear that in order to solve this copying problem, you have to inform the (COPYMODS) program about the presence and format of standard IBM tape labels. I have done this, and have added many improvements to the COPYMODS program. COPYMODS is currently at Level 042, and you should spend some time looking at this code with its accompanying documentation. There is now some advanced and sophisticated knowledge in the COPYMODS program, and you can get a lot of practical help in processing tapes, if you look there. On File 229, I've also included a program, called COPYSLNL, which can strip the standard labels off a tape, and just create an NL version of the same tape. Its action is very simple. When COPYSLNL sees a 3-file SL sandwich, it skips the headers, copies the data file, skips the trailers, and writes a tape mark. All of this action is very straightforward, and these programs can handle a tape with few, or very many files, in exactly the same way. Tape handling, using such programs, becomes a far simpler matter than it was previously. What's in a Tape Label? You can see the full format of tape labels readable on an MVS system, by looking at the book: "DFSMS: Using Magnetic Tapes", which I mentioned before. We'll just talk about the standard EBCDIC MVS formats here. In general, tape labels contain printable characters exclusively. Header labels consist of two records: the HDR1 label and the HDR2 label. Trailer labels look like header labels for the most part, and they come in two flavors: EOF1 and EOF2 (end-of-file), or EOV1 and EOV2 (end-of-volume). The only difference between a HDR1 label and an EOF1 or EOV1, is that the EOF1 and EOV1 labels have the "block count" field filled in. As the system wrote the tape file, it counted the number of blocks written, and this number was inserted into the block count field (at +54 bytes for 6 bytes) of the trailer labels. The corresponding field in the HDR1 label is zeroes. EOF2 and EOV2 labels are identical in content to the corresponding HDR2 labels. I'd say that the difference between the information in the HDR1 labels and the HDR2 labels is generally that the HDR1 label data is independent of dataset characteristics. The information about what kind of data is in the file, is roughly speaking, contained in the HDR2. For example, the DSNAME, original volser, dataset sequence number, volume sequence number, creation date, and expiration date, are among the fields included in the HDR1. The HDR2 contains the record format, block length, record length, tape density, creating jobname/stepname, and other dataset attributes. You can easily see the difference in the general nature of the information. If MVS reads a tape file as Standard Labeled, then the label information is available to be merged with the JCL DD card information, and can be used to execute the job step. Therefore it is important that the information be correct. I'm telling this to you for a good reason. The more sophisticated functions of my version of the COPYMODS program allow the user to control all the information contained in the tape labels of copied tapes, so I'm emphasizing that you should look in the "Using Magnetic Tapes" book to familiarize yourself with those fields in the tape labels, that the MVS system processes. These fields are called "functional fields" in that book. If you take a few minutes to familiarize yourself with tape label fields that the system uses in processing a tape, you'll be at a big advantage when you execute tape jobs. I hope you've gained some valuable information by reading this month's column. As this column goes into its thirteenth year, I wish you all the best of luck and success. See you again next month!