MVS TOOLS AND TRICKS OF THE TRADE DECEMBER 2002 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. TRICKS WITH TAPES - PART I - Tape Concepts I feel it's unfortunate that Systems Programmers sometimes aren't too familiar with the internals of tape processing. Tape processing is one of the simpler parts of MVS to learn about. Tape processing is, by its nature, sequential and one-dimensional. Everything stretches out in a line. This makes tape processing more easily understood than, say, DASD (direct access) processing, which, by its intrinsic nature, is two-dimensional. For example, let's compare tape labels with direct access disk (DASD) labels. The MVS tape volume label is an 80-byte unblocked record, and it is the first record on the tape. The header records for the first file on the tape immediately follow the tape volume record. It's hard to find an arrangement which is simpler than that. On the other hand, the DASD volume label is record 3 of track 0 of the DASD volume. And it is not completely simple to find out where the files are located on the disk pack. The DASD volume record has to point to the beginning CCHHR location of the disk file directory, otherwise known as the VTOC (Volume Table Of Contents). The VTOC points to the starting CCHHR location of each of the disk files. And even that may not be as simple as it could be, because in order to improve file search efficiency, IBM sometimes introduces an extra "VTOC Index" file into the mix. The header record of the VTOC (also known as the Format 4 DSCB) tells you whether you need a VTOC index file to correctly find all the disk files. Or, if the header record says so, you may not need a VTOC Index file, and the VTOC itself does it all. So the question remains: If tape processing is so simple, then why don't more people know about its innards? I think the answer is, that the MVS operating system hides the tape labels from general view. Most people, even systems types, don't get everyday glimpses at the internal contents of the tape labels. So, it's "out of sight--out of mind", and most people don't get to find out what's happening. THE BEGINNINGS OF TAPE TRICKERY Today we are going to talk about manipulations which you can do to individual tapes. We are not taking Tape Management Systems, such as CA-1 (TMS), CA-Dynam/TLMS, or RMM into account. All of our maneuverings will be done with one tape, or with a small number of tapes. However, I can recommend a wonderful tape-manipulation package that can be used to bulk-handle many tapes on a "production level". The package is called TelTape, from Cartagena Software (www.cartagena.com). TelTape can be used to simplify tape migration efforts, and it can copy, or otherwise deal with, thousands of tape volumes at a time. TelTape can run inquiries and updates to the Tape Management System, at the same time it is copying the tapes. So if you need help in migrating most of your tape volumes to an automated tape library or if you're doing something similar, I'd suggest giving TelTape a try. And TelTape is just a good general "tape utility" to have. I'll start uncovering the innards of tape files with a discussion of BLP (Bypass Label Processing). Without talking about BLP, it's hard to uncover the information about tapes, which the MVS system hides. BLP processing can be used to uncover whatever tape information the MVS system covers up. BLP tape processing is the same thing conceptually, as NL (non label) tape processing, except that if you specify NL in the LABEL parameter of your tape DD JCL, and you mount a Standard Labeled tape, the MVS system intercepts that situation, and asks you to mount a truly non-labeled tape. Using BLP, it isn't so. MVS, operating the tape handling under BLP, regards a tape label file the same as just any other file. Therefore, using BLP, you can dump the contents of the label files, and do just anything else you might want to do with them, including changing them while you're copying the tape. Not everybody in an MVS shop has the power to do BLP processing. In the JES2 initialization parms, you can specify whether a job, submitted under a particular job class, is allowed to use BLP processing. And RACF (or another MVS security package) has the capability of controlling which users, or which groups are eligible to run BLP processing on tapes. In RACF's case, you define a resource called ICHBLP under the FACILITY class, and grant at least READ access for that resource. Then, the user or group with READ access to that resource, can run a job using BLP access to tapes, again, provided that the JES2 job class allows it too. Once you can do BLP processing, and you can treat tape label files as though they were any other files, then you can understand the simple process of copying one tape to another, the way it should be. Let me explain: A tape file consists of "blocks" which are grouped into "files", and the files are separated from each other by "tape marks". Tape marks are special character sequences which the tape hardware recognizes, as separators between the tape files. Blocks of data within the same tape file, are not separated by tape marks, but by gaps of tape which are unwritten upon. These are known as "interrecord gaps". Interrecord gaps separate tape BLOCKS. Tape marks separate tape FILES. Therefore, copying one tape to another tape, merely consists of reading the blocks on the input tape, writing them unchanged to the output tape, and whenever you encounter a tape mark on the input tape, just write a tape mark on the output tape. There are programs which do exactly this. One program which is famous for carrying out this task, is called COPYMODS, and you can find it on File 229 of the CBT Tape collection, a huge collection of free MVS software which is accessible from the web. The TelTape vendor package, mentioned above, has a tape copying utility which works this way too. Other vendors, such as Innovation Data Processing with their FATAR utility, have programs which do much the same thing. There are 5 or 6 other free programs on the CBT Tape collection which are also capable of copying entire tapes in a similar way to this. At this point, I'd like to mention why many programmers are confused by such a process of copying one tape to another, which is so simplistic that it is hard to imagine anyone having difficulty understanding it. The reason for not understanding it, is because these programmers confuse the process of "copying tape files" with the process of "copying entire tapes". Usually, the key to the misunderstanding is not having BLP power. If you don't have ready access to BLP power, it's hard to find a utility that'll copy all the tape blocks and their tape labels for you. Therefore, many programmers, when extracting the contents of one tape, to put it on another tape, have to do it one file at a time. So they'll copy one file to disk, then copy that disk file to an output tape, and then they'll do the same for the next file, and so forth. If that is what they're doing, they might never be sure they've gotten to all the files, and copied the entire tape. Copying one file of a tape at a time, is also a time consuming and exhausting process, whereas, making a "Xerox Copy" of a tape, by copying all its blocks and labels, is a very simple job, and it's usually quite fast. TAPE MAPPING AND TAPE COPYING TOOLS A "tape mapping" tool is a worthy complement to a "tape copying" tool. The two of them go together, sometimes even in the same program. The idea of a tape mapping tool is to tell you what's on a tape, without any outside help. A tape mapping tool reads the tape blocks and files, and reports whatever it's been programmed to "find out". A tape mapping tool will tell you what needs to be copied from a tape, and after the tape has been copied, it will tell you whether you've gotten all the original tape's data files into the copy. Some examples of free tape mapping tools are TAPEMAP from either File 299 of the CBT Tape, or a different variation from Leonard Woren at http://ldworen.net . Other such free tape mapping programs are TAPESCAN, from File 102 of the CBT Tape, or SS0104 from File 266 of the CBT Tape. It is not so well known, but TAPESCAN can also be used to copy tapes, as well as map them so you can determine their contents. The COPYMODS program, although it is normally used to copy tapes, will also do a fairly good job of mapping the contents of a tape, when it is run with the proper options. Vendor tools which can map tapes are supplied with TelTape from Cartagena Software Ltd, with FATAR from Innovation Data Processing (the FDR people) and from other vendors too. And don't ignore MVSDITTO from IBM. Among the free tape mapping programs, TAPEMAP and TAPESCAN are very different from each other both in purpose, and in the appearance of their reports. They'll nicely illustrate the great variations that are possible among tape mapping programs. Both TAPEMAP and TAPESCAN operate by reading a tape, block by block and file by file. Let's examine some of the differences between them. First let's consider TAPESCAN. The main purpose of TAPESCAN is to examine, in some detail, the DATA that is on a tape. TAPESCAN was designed for techies. Therefore, TAPESCAN is oriented to show much of the raw data on a tape, rather than to make an interpretation of the tape's contents for English-speaking people. So we find that the main TAPESCAN report consists of an interpretation of the tape labels, if any exist, followed by a hex dump of the first 100 bytes of the first "n" blocks of each file. By default, n=4. That is, TAPESCAN, run without PARM alteration, will display the first 100 bytes of the first 4 blocks of each tape file. Every tape mark encountered on the tape is noted, and counted. Also, the end of the TAPESCAN report will format a lot of the tape label information for each file (if the tape is SL), so that you get a summary of the file contents on the tape, too. For good measure, TAPESCAN gives you a byte count for "data plus label" bytes on the entire tape. So you see that TAPESCAN is very nitty-gritty down-to-bytes centric in its approach. I personally think that it was designed only to dump only the beginning bytes of each tape block, and only the beginning tape blocks of each file, as a reaction to what the IBM DITTO program shows. Using DITTO (the predecessor of MVSDITTO), if you want a hex dump of the contents of a tape, a tape file, or a tape block, you usually have to print the WHOLE block, or the WHOLE file, which is very bulky to print and to look at. Usually, when examining a tape dump, you want to scope out the forest, and not be stuck in the middle, examining a few huge trees (and requiring an entire forest-full of paper, to print the whole thing out). TAPESCAN's report is a really good compromise, in showing you as much of the byte content of the tape as you care to see, but not obscuring the overall view as to what the entire tape contains. TAPEMAP is not like this at all. TAPEMAP is "contents centric", and not "byte centric" in it's approach. When you map a tape with TAPEMAP, you want a summary and an accurate picture of what the entire tape contains. You also want to make sure that the tape labels didn't fool you, so you want to be able to compare what the tape labels tell you, with the result of an actual scan of the tape's files and their blocks. There's one other important thing about TAPEMAP: Last but not least, if the tape contains files which were created in known formats, for example, a file created by IEBCOPY, or by IEBUPDTE, or by FDR (and about 8 others), you'd like to find out about the details of that, too. If a partitioned dataset has been dumped to tape, it'd also be nice to know what all its member names are. TAPEMAP tells you all of these things. TAPEMAP produces two reports when reading a tape. One (which it always produces) gets written to the SYSPRINT ddname. TAPEMAP's SYSPRINT report contains general "label and scan" tape file information, interpreted for easy reading. The other report, which displays special information about some tape files--such as all the pds member names--which come from the special formats (such as IEBCOPY), gets written to the SYSPRNT2 ddname. If no files from the input tape are in special formats, then the SYSPRNT2 ddname is not written to. TAPEMAP is one of the few programs that probably tells you more, if you run it without PARMs, than if you run it with PARMs. Without PARMs, TAPEMAP will produce both the SYSPRINT and SYSPRNT2 reports, and it will compare file information for each tape file, that was gotten from the labels, and from an actual scan of the data. For instance, if a certain file's tape label says that its block size is 32760, but actually, the largest block on the file has only 21000 bytes, TAPEMAP will reveal that situation to you, in a very clear way. The PARMs in TAPEMAP operation tend to restrict the reports produced, more than expand them, so it's probably best to always run TAPEMAP without any PARM at all, although File 299 of the CBT Tape will show you what PARMs are available for TAPEMAP. You're welcome to experiment with them. My recommendation is, that if you really want to start getting a handle on the contents of your tapes, you should become familiar with running the TAPEMAP and TAPESCAN programs. I feel that the knowledge of "what's on a tape" is an essential requirement in a system programmer's general knowledge. As I said before, it's not that "large" a topic, and most of the details can be easily grasped. It's a question of merely taking some time to investigate, and I hope I've given you a start. I'm planning to have two more articles on tapes. Next month, I'd like to talk about some tape copying tricks that many of you might never have heard about, or even thought of. The following month, I'd like to discuss the topic of writing tape data, using EXCP (maybe with a little BSAM thrown in). I wish all of you the best of everything, and I'm hoping to see you then.