MVS TOOLS AND TRICKS OF THE TRADE AUGUST 2006 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. CBT TAPE PACKAGING Every once in a while in this column, I like to present a summary of the recent CBT Tape contributions and updates, in the hope that I've mentioned something which will be of immediate use to you. I'm very grateful that people are constantly solving their own problems at work by writing tools for themselves, but I am far more grateful that they are sharing their tools with the whole world, by sending them into the CBT Tape collection to make all our lives easier. Since I'm the proprietor of the collection, I'm in a good position to tell you about what has recently changed. But today, I'd rather emphasize more about the processes that go into creating and maintaining the collection, in the hope that you'll make better use of its many software packages and tools. The CBT Tape collection was founded by Arnold Casinghino in 1975. I have been its proprietor since 1990. If you don't already know about it, the CBT MVS Utilities tapes contain a free collection of MVS utilities, tools, suggestions, and generally helpful things for people working with MVS and supporting MVS. The collection has a website, which you can find by doing a www.google.com search for "CBT Tape", with the site appearing at or near the top of the search. You do not need a password to access the utilities, nor do you need to be a "member of anything" or of any organization. The stuff is free for all, although it is only really useful for MVS practitioners. There are many "really heavy-duty, tried and tested" utilities and utility packages in this very large collection. Two "tapes" are supported: the "original" CBT Tape, which gets updated every few months, and the "CBT Overflow Tape" which contains other utilities, that either didn't fit on the "regular" tape, or older versions of the same utilities that are on the regular CBT Tape. The CBT Overflow Tape is updated whenever there is a necessary change, but quite a bit less often than the "regular" CBT Tape. On the website, which is supported by Sam Knutson, there is an "Updates page" that is supported by me. All of the new contributions that have arrived since the entire tape version was last cut, are posted to the Updates page of the CBT Tape website. These may be changed, as the authors fix things, but I generally like to make sure that a package which is posted to the Updates page, already works. Therefore, you can usually consider a package or program from the Updates page safe to use, but there might be some more bug fixes or improvements before the author is satisfied. Of course, since the CBT Tape collection is a volunteer enterprise, no liabilities are assumed by anybody (see the posted Disclaimer on the website). But practically speaking, that does not diminish the usefulness of these tools for us in the MVS world. We do try our best to make sure that these tools are good, and work properly. The CBT Tape collection is organized by "files". These correspond to actual files on an actual tape. The individual files can be uploaded to an MVS system, and each file usually converts, on MVS, to a pds, or partitioned dataset, although some of the older (tape) files convert to a sequential file. File 001 of each tape (i.e. the regular CBT Tape, and the CBT Overflow Tape) consists of an FB-80 sequential documentation file. And File 003 of each tape consists of JCL to unload all the files from the actual physical tape. File 002 of each tape is source for an Assembler program that compresses or decompresses blanks from the tape files. This program, for historical reasons, is named CBT973. Data representation of the tape files differs, depending whether the file is on a physical tape or a tape image, or whether it was downloaded directly from the website. But the result, no matter where you originally got the CBT Tape file from, is the same. It is usually a pds on your MVS system, with the package or programs ready to install, and with documentation included. Let me tell you about the data representation differences between the website files and the actual tape files. The "website" files are in zipped TSO XMIT format. So when you download a website CBT file to your PC, you first unzip it, and then upload it in BINARY to your MVS system as a fixed blocked (FB), LRECL=80 sequential file. After that, you then execute a TSO RECEIVE INDS(yourfile.XMI) command against it, to (usually) produce a partitioned dataset on MVS. On the other hand, the files from the tapes are mostly in CBT973 compressed format, except for the first three files which are uncompressed, and the JCL from File 003 in each tape, will supply proper instructions to create each file in its proper format (usually a pds) on your MVS system. Again, no matter what the origin of the file, whether it be from the website or from a real tape or tape image, the result should be the same, once the file was moved to the MVS system. And it usually is a pds. What about "CBT version numbers"? Each entire CBT Tape contains a version number and a date. These appear at the beginning of the tape documentation on File 001. This tells you the general level of all the utilities from all the files on that tape. For example, if you have File 182 from CBT Tape Version 470, then you know which level of the PDS program package (which resides on File 182) you have. More specifically, to fine-tune the versioning, I have included a "versioning" member for most of the CBT Tape files, which I automatically produce, that is pds member $$$#DATE. See Figure 1 for one example of this member. This member is produced by a CLIST that I wrote, called GENDAT, which is on CBT File 006. File 006 contains tools that I myself use to generally maintain the tape, and you can use them too, if you want to. (That's why I make them publicly available.) As of this writing, the version number of the latest entire CBT Tape is Version 471. And I am currently accumulating the updates for Version 472. These are on the Updates page of the CBT Tape website. The latest "entire tape version" of all the CBT Tape files is on the "CBT" page of the CBT website. CBT FILE DOCUMENTATION The CBT Tapes were originally "purely MVS" entities, and they were produced to be exclusively installable and usable on MVS systems. However, the world has now changed, and people write their documentation in Microsoft WORD and in Adobe PDF formats. Text representations of the doc in EBCDIC are getting much rarer nowadays, and so I have to handle that situation when I prepare a CBT Tape file for distribution. As far as I know, the MVS system doesn't have a tool that runs under it, which will read either WORD or PDF documentation formats directly. So what I do is to upload a byte-for-byte FB-80 representation of the WORD or PDF data to MVS, and insert it in to the CBT Tape file as a separate member. In order for the user of the file to read this documentation, that pds member has to be downloaded in BINARY to a PC, and either WORD or an ADOBE reader (depending on the format) has to be opened against the PC version of that file. The file (of course) cannot be read directly on the MVS system, and I do not like this idea, but this is the reality of our current world and I have had to adapt to it. I used to spend many hours converting the WORD format doc files into FB-80 text representations, to conform with the way the file doc used to be distributed in former years. This was because there still were some MVS sites that ran without PC support, and I felt that those places wouldn't be able to fully benefit from the packages if they could not read the documentation that came along. But nowadays, I generally leave any WORD or PDF doc as is, because the readership generally has access to PC software, and someone who is running in a "purely MVS" environment with only directly attached "green screens" is a very rare bird, indeed. CBT FILE PACKAGING When somebody submits their materials for inclusion into the CBT Tape collection, I generally have to do a considerable amount of work. My work consists of making sure that the package is "installable" and that it works. I don't have time to actually test all of the packages which are submitted, especially if they are for an MVS add-on like CA-1, which I don't run at my own installation. My general policy then is: I must make sure that the package can be easily installed by a reasonably trained MVS systems programmer. Once the package is out there, I assume that it will be tested by anyone who needs it, and that they will report bugs or design defects (if any) back to me so they can be corrected, and the package will then be further improved and fixed. There is a general situation which I have to address when I'm packaging the submitted materials. The CBT MVS tapes are designed to run, and be used, on MVS systems. Many people nowadays, with hybrid computing environments as they are, do not actually write their software, even if it is to be used on MVS, on MVS systems. And so the data representation of the submitted materials might be ASCII, with carriage return and line feed characters appended, and the lines of the source code might be longer than 80 characters. Other differences may be present in the submitted materials, which could make them quite incompatible with the traditional MVS data formats. So what do I do? The answer is that I still try to MVS-ize the submitted materials as much as possible, without compromising the integrity of the installation process. My attitude is that I will try to put the materials, or fold them, into FB-80 format somehow. If that can be done, then I'm reasonably happy. And the folding and/or data conversion processes must be easily and accurately reversible, too. Several repackaging tools are available for this purpose, which are either present on MVS systems already, or which are installable for free on MVS. The first is the TSO TRANSMIT (XMIT for short) command, and the second is IEBUPDTE, and its user-written counterparts, OFFLOAD and PDSLOAD. The TSO XMIT command will take VB or FB data of almost any format, and convert it into FB-80 immediately, using its optional OUTDSN( ) keyword parameter. The effect of this XMIT repackaging is reversed by the TSO RECEIVE command, with its INDS( ) keyword parameter. A drawback to the use of the XMIT command for packaging CBT files, is that it requires the presence of TSO/E on the MVS system. Pre-TSO/E MVS systems do not contain the XMIT (or RECEIVE) TSO commands, so a pds member which is in XMIT format, cannot be easily interpreted on those systems without an auxiliary tool. This situation might occur nowadays if someone is running MVS 3.8 under the Hercules emulator on a PC. For those people who need a tool for the PC to interpret XMIT-format files that have been downloaded to the PC, there is a tool called XMIT-manager that (I believe) is (still) available at the CBT website. One of the principal purposes of using the XMIT TSO command to reformat data, is to convert pds'es into FB-80 sequential files, so they can be loaded into an FB-80 format pds for inclusion in a CBT Tape file. If the data is already in FB-80 format, but it is a pds, the pds can be "sequentialized" using the MVS IEBUPDTE program. The idea of IEBUPDTE (as we use it) is to load each member of the pds into a sequential file, but with a separator line consisting of an ./ ADD NAME=memname card that is in between each member. IEBUPDTE can be used to both create the sequential file from the pds, and to reload the pds from the data in the sequential file. The OFFLOAD and PDSLOAD program combination from CBT Tape File 093, can do this also. But OFFLOAD and PDSLOAD has two more advantages over IEBUPDTE. First, OFFLOAD (to create the sequential file from the pds) and PDSLOAD (to reload the pds from the sequential file) will preserve ISPF statistics of the members, if they are present. Second, OFFLOAD and PDSLOAD are not restricted to LRECL=80 data, as IEBUPDTE is. Please see CBT Tape File 093 for another set of tools, called UPDTE and UNUPDTE, which do something similar to OFFLOAD and PDSLOAD. A good reason for representing an unloaded pds in IEBUPDTE format on a CBT Tape file, as opposed to XMIT format, is that the data is basically unchanged, but the data from the separate pds members has just been strung together, one member after another. An advantage is that this data can still be read directly (especially on pre-TSO/E systems) and it does not need an intermediate program (TSO RECEIVE) to make it readable and usable. So, using a combination of IEBUPDTE format and XMIT format pds members, I have been able to re-package non-MVS data on MVS systems in a reproducible and reversible manner. Therefore, I can package a product on MVS, which was not designed to fully run on MVS. Even a zipped file can be directly uploaded to MVS as FB-80 and folded over. So using "modern methods", there is still really a lot of flexibility in creating "mixed" packages for distribution on an MVS system. SUMMARY My hope this month has been to give you some more insight into how MVS software packaging can be used to contain some non-MVS software data. Also, I hope that you'll gain some appreciation into the process of making people's software products that were submitted to the CBT Tape, distributable and installable in a standard manner. For those of you who aren't so familiar with these processes, I'd bet that after reading this article, it'll be much easier to install programs and packages from the CBT Tape collection. Best of everything to all of you, and I hope to see you here again next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. A CBT File Versioning Member, $$$#DATE. This is a sample versioning member for a CBT Tape file (File 743), which shows when the file was last updated, and how many records it contains. Thus, you can trace exactly which version of the file that you have. The CLIST called GENDAT from File 006 produced this member. REGULAR CBT TAPE - VERSION 472 FILE: 743 ORIGINAL DSNAME: SBGOLOB.CBT472.FILE743 --------------- --RECFM-LRECL-BLKSIZE-DSORG FB 80 5600 PO PDS117I 17 MEMBERS COUNTED; CUMULATIVE SIZE IS 4,511 RECORDS TIME THIS PDS WAS SHIPPED: 07/05/06 09:02:55 GMT-4:00