MVS TOOLS AND TRICKS OF THE TRADE DECEMBER 1999 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. USING XMIT TO PACKAGE MVS FILES I remember years ago, how difficult it seemed to bridge the communication gap between different computer systems. Companies used to pay small fortunes to consultants, to try and get two different computer systems to "talk to each other". Nowadays, life is far smoother, since almost all of those old problems now have solutions. The standardizaton of protocols, and the introduction of the Internet, with the global communication opportunities it offers, now makes it possible for users on enormously different hardware platforms to easily interact with each other. Today, I want to talk about transferring files from one MVS system to another MVS system, even though there may be many other different computers in between. If you know how to do it, it's quite safe and easy. If you don't, achieving sure-file error-free transmission might appear like an impossible dream. I don't claim to have definitive, exhaustive knowledge on this subject. I'm just coming to suggest some easy ways to do the job. Who might need this knowledge? The truth is that we all do, but I can state some specific examples. For instance, you might receive PTF fixes from a vendor over the Internet, and they have to be correct, "byte-for-byte", obviously. You might want to send a dump or some other problem data, back to the vendor. This data also has to be correctly transmitted, otherwise the vendor's support personnel might mis-diagnose your problem. Programmers might want to send programs or data files to each other, and of course, they don't want any errors arising from the transmission, either. As the proprietor of the CBT MVS Utilities Tape, I confront this situation daily. People send me files, as contributions for the tape, and I send files back to the contributors, for their re-examination and approval. TSO XMIT AND RECEIVE COMMANDS Any upload or download mechanism which handles file data, is greatly aided in its accuracy, if the data is in a simple, standard form. For example, 80-byte card-image data is simple, and it can be handled by many computer systems. Reducing more complicated data into the 80-byte fixed blocked format, is of great help in ensuring accurate transmission of the data. A number of years ago (July 1994--in this column), I wrote about IBM's ancient IEHMOVE program, which has the capability of reducing very complicated data formats into 80-byte records. At that time, I did some experiments. I found that IEHMOVE-formatted data would be transmitted far more reliably, being FB-80-byte records, than other forms of sequentially unloaded data, such as IEBCOPY-format RECFM=VS files. Of course, I wasn't Internet-ready at that time. I was using protocols such as ZMODEM and XMODEM to transfer the files. Nevertheless, the simpler the file format, the more reliable the transmission, I found. IEHMOVE is ancient and hard to use. Since then, IBM has come up with an easier solution for us, even though that probably wasn't their intent. This newer solution is to put our data into TSO XMIT-format, using the OUTDSN( ) keyword of the XMIT command. This process gets the data temporarily into FB-80-byte sequential file format, and then TSO RECEIVE, with the INDSN( ) keyword, can put it back into its original format, after the sequential file has been transferred to a different machine. TSO XMIT (TRANSMIT) and RECEIVE were developed for a different purpose than IEHMOVE was, even though, for our uses, the results are similar. While IBM was enhancing "old TSO" to bring out TSO/E, they developed a method of having TSO users send data across NJE lines through JES. JES2 and JES3 both, are highly compatible with 80-byte records, so it was natural to try and put other data formats into handy 80-byte chunks. This made it easy to send the data across JES-defined transmission lines. When the data would arrive at the destination MVS system, the TSO RECEIVE command was there, to convert the 80-byte data back to its original format. The TSO XMIT command, in its normal use, transparently packages the data into 80-byte records, sends it across the JES NJE lines to the destination system, and waits for the TSO RECEIVE command to be deployed there, to retrieve the transmitted data. In the usual usage of TSO XMIT, you never see the re-formatted data. However, TSO XMIT has an OUTDSN( ) keyword parameter, in which there is no data transmission--just data reformatting. The OUTDSN form of the TSO XMIT is the one we'll use for our purposes. When the OUTDSN parameter is coded in XMIT, the total format is: TSO XMIT node.userid DSN(your.dataset) OUTDSN(your.fb80.data) . When OUTDSN is coded in a XMIT command, the node.userid doesn't really matter because the data is not sent. You could code A.A for node.userid just as well. But since the command and data encoding formats for XMIT were designed for data transmission to another node, the node.userid parameters have to be there. TSO XMIT sends you the misleading message that so many blocks and so many records of data were sent to such-and-such node. It really isn't so. If OUTDSN was coded, that amount of data was just reformatted, not actually sent. What do you do with the reformatted data? If it's on an MVS system, all you need do is to issue the TSO RECEIVE command with the INDSN( ) parameter as follows: TSO RECEIVE INDSN(your.fb80.data) . RECEIVE will tell you the name of the dataset and ask you if you want to proceed. At that point, you can enter a command "DSN" and tell RECEIVE to put your data in a dataset of your own naming. Otherwise, if you just press enter, RECEIVE will create a dataset with the original dataset name, minus the sender's high-level qualifier, plus your own high-level qualifier. That's the externals of how TSO XMIT works to reformat data into FB-80 pieces. TSO XMIT can reformat sequential data of any record length, or partitioned datasets--even pds'es containing load modules. Once TSO XMIT (with OUTDSN) has done its initial job, what can be done further? The answer is: "the sky's the limit". One usual path is to download the XMIT-format MVS data to a PC, in binary (i.e. with no ASCII translation or carriage control-line feed), and then send it across the Internet to another PC, upload it in binary to another MVS system, and RECEIVE it there. You don't need NJE connections at all. If the dataset is large, you can zip it on the PC before sending it to another side of the world. Then it can be unzip'ed at the destination, uploaded to MVS, and RECEIVE'd. It all sounds great, and it is. But how can you ensure error-free transmission of the data? And if you want to read the data while it's on the PC, can you? Let's address the first question first, and the second question second. First, how can you ensure error-free transmission of XMIT-format data? One way was developed by Ron MacRae of Amdahl UK. Amdahl UK had a support problem. They wanted to distribute their PTF fixes across the Internet in XMIT-format. But if an error crept into the data, they had no way of checking for it on the receiving end, at the user site. Further, they wanted to stack multiple XMIT-format files into one bundle. Sometimes they had a pack of several hundred PTFs, all in XMIT format. If they'd transmit them all separately, how could the user site determine that all the PTFs in the package had reached them? Maybe several were left out. However, if all the PTF XMIT files would be put into a single bundled file, and that single file sent, you could then unbundle the stack at the receiving end, and get the entire contents back out. To solve both the error-checking and bundling problems, Ron MacRae developed two REXX execs. One exec, called OSTARXMT, would create a bundle of stacked XMIT-format datasets on the sending MVS system. The other, called OSTARREC, would look at this bundle on the receiving MVS system, check each XMIT-format dataset in the bundle for errors, call TSO RECEIVE to reconstitute each error-free dataset, and do so for every dataset in the bundle. The system works very well. You can obtain the software for Amdahl UK's system on File 365 of the CBT MVS Tape collection, which is available online. Just go to www.naspa.net, click on "Online CBT Tape", click on "Download CBT", and download File 365. Amdahl's OSTARXMT system works by adding 8 bytes of error checking information to each 80 byte line of XMIT-format data. The LRECL of the resulting data is 88. In transmitting this data across the Internet, you have to be sure to set ftp (if you use ftp) so it knows the data records are 88 bytes long. Or you can pre-allocate the destination file on the receiving system with LRECL=88. That caveat taken care of, Amdahl's system works great. Check it out! An alternative means of minimizing transmission errors is to zip the XMIT-format files on the PC before transmission over the Internet. PKZIP has CRC error checking built in, so the integrity of the transmission from PC to PC can be quite well assured. But the problem with this method is the link from PC to MVS system. Usually, unless you know you have a reliable unzipping tool that works on MVS, you have to unzip the data file on the receiving PC, so you're only uploading an unchecked data file from PC to MVS mainframe. On the other hand, Amdahl's system checks for errors in the entire MVS-to-MVS transmission process, and in my opinion, it's better. By the way, Amdahl's system incorporates IBM's free TRSMAIN data compression product, optionally. If the OSTARXMT and OSTARREC execs "know" where to find TRSMAIN (i.e. what library it's in), then they automatically compress and decompress the files to be transmitted. You can download the TRSMAIN load module from: ftp://service.boulder.ibm.com/s390/mvs/tools/packlib Looking at XMIT-format FILES on the PC. TSO XMIT-format files have become very popular as a way of packaging MVS files on the web. The CBT Tape web site has adopted a standard of storing the CBT Tape files (which are sequential or partitioned datasets) in pkzip'ed TSO XMIT-format. Therefore, if you download one of these files to the PC and unzip it, usually with the intent of uploading it to the mainframe, you might be struck with the idea of looking at the data on the PC first. Can this be done? To accomplish this, you'd need a "PC-based un-XMIT utility". Dave Alcock has dedicated a part of his web site: http://www.ticnet.com/davea/mvs to a study of possible un-XMIT utilities. I've found it very instructive to go there and look at what he's shown. But in fact, there's now an inexpensive commercial un-XMIT utility that's part of Tachyon's File Tools, which works wonders on a PC in dealing with XMIT-format MVS files. Tachyon's utility, called TUX (Tachyon un-XMIT), will unload an XMIT-format pds file into a subdirectory, with all the source members translated as ASCII text files automatically, so you can read them on the PC. Load module pds'es are de-linked by TUX into MVS-compatible object decks, with each load module de-linked into a separate object file in the subdirectory. The action of TUX is amazingly quick, and TUX also has a nice GUI interface for Windows 9x included. A neat application of the Tachyon un-XMIT utility is to view CBT Tape files on the PC, which you've downloaded from the CBT Tape web site. These files, when unzipped, are XMIT-format files. Using Tachyon's un-XMIT against them, will create a separate file for each source member, translated into ASCII, which you can read or print on your PC. CBT Tape aficionados can use this utility a lot. The Tachyon license will let you take the program home too, so you can look at CBT source directly, from your home PC. Therefore, if you're so inclined, you can learn a lot at home, in your spare time. I might as well mention that the Tachyon File Tools also include a PC-based un-IEBUPDTE utility to separate IEBUPDTE-format MVS files into separate ASCII text files in a PC subdirectory. This tool is called TUU (Tachyon un-UPDTE). Tachyon File Tools can be obtained from Tachyon Software: http://www.tachyonsoft.com/tachyon , phone 303-722-1341 . I highly recommend the use of the Tachyon File Tools, if you want to frequently look at MVS files on a PC. A Few Words About XMIT. In closing, I just want to mention that XMIT, although a utility to put data into FB-80 format, is really a packager for the output of other MVS utilities. For instance, XMIT-format for a pds is really an IEBCOPY-unloaded file, broken up into 80-byte records in such a way that you can put it back together again (with TSO RECEIVE, which re-invokes IEBCOPY). TSO XMIT and RECEIVE can process sequential and partitioned non-keyed datasets, with practically any RECFM. They do not process ISAM or VSAM datasets. I hope you've found this month's discussion useful. If you're sending files or programs far away, you can profit greatly from what we've said. Just for teasers, I'd like to mention that you can even send a SYS1.BRODCAST dataset (which is keyed) to another site. Using the BCMDUMP program from File 247 of the CBT Tape, you can create a FB-130 sequential file containing the data from the keyed SYS1.BRODCAST file. Then you can use XMIT to make the file FB-80, download it to a PC, zip it, and send it anywhere. At the other end, you reverse the steps and use either the BCMREST or BCMEXPND programs from File 247 to re-create a keyed SYS1.BRODCAST format file from the FB-130 BCMDUMP file, that is functionally equivalent to the original one. Other tools from File 247 will allow you to read or write messages directly to and from the copy. Best of luck to all of you. We'll hopefully see you in one piece, after the beginning of Y2K.