MVS TOOLS AND TRICKS OF THE TRADE FEBRUARY 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. EMULATION AND MVS I consider myself very fortunate to be able to witness our exciting era of change. Technological progress gives rise to new techniques, and new techniques give rise to further technological progress. As we go on and do our jobs every day, events continue to occur that change both our larger world, and also the way we do our normal everyday work. Some people may not like to always be moving in an ever changing set of surroundings, and I admit that it is more comfortable to be settled into a daily routine that doesn't vary too much. But there is a vibrant excitement to our time, which was not nearly as evident in former times. And I feel that it would be a great pity, not to both enjoy it and take advantage of it. For example, consider something as basic as hard drives for the PC. Today it is not uncommon to use 300 gigabyte attachable hard drives on your own personal computer at home. Now let's compare that size to an IBM "big-iron" mainframe disk pack, like a 3390 model 3. The capacity of a 3390 mod 3 is 2.7 gigabytes--that's all! Can you figure how many 3390-3 disk packs you'll be able to fit on ONE 300 gigabyte disk drive that you can hold in your hand? It's well over a hundred of them! And that's without even compressing them! So, the old mainframer will still pipe back and say that the numbers may not be lying, but practically speaking, you can't make use of PC disk space as mainframe DASD. Not so at all! FLEX-ES MVS systems use PC disk space as emulated MVS DASD. P/390s use PC disk space as emulated DASD. And even Hercules systems (legally run) use PC disk space as emulated DASD. To top it off, Hercules systems can use compressed DASD that averages one fifth the size, depending on how much real data is there. So what comes out of this (relatively small) technological development of having the availability of high-capacity PC hard drives? It comes out that the entire DASD situation on mainframe-based MVS systems has been completely revolutionized! Practically speaking, you can now carry an entire "DASD farm" around in your hand. That's not a small consequence, coming as it does, from just "one single technological development". Today I'd like to encapsulate the consequences to MVS, of four areas of change, all caused by some form of "emulation". These are: First, "terminal emulation" versus the old hard-attached "green screens". Second, "hardware instruction emulation" versus "real machines". Third, "virtual DASD" versus "real DASD". And fourth, "virtual tape" versus "real tape". I'll show you how each of these marvelous technological developments has revolutionized our entire MVS world view. And practically speaking, each of us will be able to immediately use more than a few new techniques taken from each one of these four areas of emulation. The direct benefits to all of us from these developments are REAL! They are not just news items. TERMINAL EMULATION VERSUS "GREEN SCREENS" In former times (i.e. for my first ten years in this business), I used to be extremely comfortable with the directly attached 3270 TSO "green screen" that was supplied with MVS. Every time I logged on and looked at that old familiar terminal, I felt that "I am at home. This is where I live." Then the PCs came along, and I had to be in Windows initially, before I could get onto TSO. It was disconcerting at first. I had to get used to using an emulator. Which emulator? Attachmate? QWS3270? IBM Personal Communications for Windows? Each one was different, and each was awkward in at least one way. In short, they were all a big pain in the neck. I finally settled on one emulator that I liked, and I always use that one. It was written by a friend of mine who is a fellow MVS systems programmer, and I get the feeling that he wrote it for US--for OUR TYPE OF PEOPLE. There is a lot of good information on the bottom of the screen, and everything is very customizable. This emulator is called Vista. It was written by Tom Brennan, and you can get it for yourself, over the web, from www.tombrennansoftware.com. Tom charges 30 dollars for a personal license, but he gives a free 30-day trial first, and you can install it on any computer that you personally use for yourself (if I understand his terms properly). Tom gives you a good deal. So whatever, whenever, and wherever I dial into something (as long as it is an MVS system), it always looks and feels the same, even if the system itself is physically sitting halfway around the world. Whatever terminal emulator you are using, you always have some advantages over the green screen. These are: Color control, which is much more easily done. Keyboard control. On Vista, you have individual control over which character any key stands for. CUT and PASTE. You can copy stuff between two completely different computer sessions, as long as they are both running as emulated sessions on the same PC. You never could do that with a green screen. You always had to have some physical transmission between two computer systems which was a direct connection, before you could copy data from one session to the other. IND$FILE. You can always upload and download files from the PC to the mainframe, when you have an emulated terminal. Font adjustments. These are easy to do on an emulated screen, and almost impossible on a green screen. Scripts and playback. Even though you can do this on the more sophisticated physical terminals too, it's much easier to set them up on an emulated terminal. So you see that once you have gotten used to working on an emulated TSO screen, it's a lot more flexible to do your own special stuff there, than it was on the (much more unforgiving) hardware terminals. I did know one systems programmer who insisted on having a directly connected terminal on his desk. But he was the only one who wanted that, in a very large shop. Everyone is entitled to his or her preference. That is part of the greatness of humanity--all people are created different! I actually took advantage of it. That person was able to fix something on the system one time, when nobody else's terminal worked. But the rest of the time, he wasn't able to enjoy all the other advantages that we had. HARDWARE INSTRUCTION EMULATION VERSUS "REAL MACHINES" It was after a NaSPA chapter meeting in 1990 when my friend George Shedlock gave me a long speech about how this fellow Marty Ziskind who worked for IBM was touting a mini-MVS machine called a P/390 that IBM was making. At that time it was hard to imagine an MVS machine that was smaller than two very large refrigerators. Most were much larger. This machine was going to be a PC with a special card in it, that emulated the MVS instruction set. All of the MVS hardware devices were emulated under OS/2 on the same PC. Such a thought was mind-boggling and amazing. It was a little too much for me to fully absorb at the time. The successor to the P/390 turned out to be a completely emulated machine that runs on a "plain PC" under Linux. It is the FLEX-ES machine from Fundamental Software, that does most of the MVS functions on an ordinary IBM PC. No special cards are needed. Everything is done with software emulation of hardware. So any new instructions which IBM wants to add, can be emulated by a new version of the FLEX software, instead of IBM having to make a new hardware card. The system only needs a proprietary hardware dongle that plugs into a USB slot on the PC, to protect the rights of the company that wrote the emulation software (Fundamental Software). And MVS runs on it. Imagine a 30 mip MVS machine in 64-bit mode that runs on hardware weighing only 5 pounds! You can carry it anywhere in a small suitcase, and it runs on battery power. It's perfect for a software developer, and now (under IBM's PWD program) it's actually semi-affordable (it costs "only" about 15 thousand dollars). A used P/390 is considerably cheaper, but you still have to get approved by PWD to qualify for the MVS software loan. And P/390s will only run in 31-bit mode (z/OS 1.5 is the highest release which supports 31-bit mode). On top of that, you need a P390/E card to execute the instructions to go that high with z/OS. The older P/390 card stops working after OS/390 2.10. It has long been a fact that PC software could be developed by almost anyone, because PC's were cheap. But MVS software had to be developed by someone working for a sizable company, because the machines it ran on, were very expensive. Now it's not quite so bad. IBM, with it's Partnerworld for Development (PWD) program, lends you the MVS software for nothing, if you register at PWD with them, and they approve of your filed software development plan. You have to own some hardware that can run MVS, like a P/390 or a FLEX-ES box. They're trying to help make it possible for (at least some) independent people, or for someone who doesn't have an MVS job right now (many people nowadays, unfortunately), to keep on working and exercising their hard-won MVS programming skills. So the technology has helped some of us, at least, during this current recession. The power of emulated MVS software is only made possible, because of the immense CPU speed (usually over 1.5 gigahertz) of the modern-day PC machines. Also, a physically tiny PC can now be equipped with well over 1 gigabyte of real memory. So there's plenty of storage on a new PC, for MVS to run in. The faster the CPU speed of the PC, the faster the emulated MVS machine can be. Fundamental Software has made some extra enhancements (such as their instruction cacheing, and their proprietary DASD format) to boost the speed up even more. Peripheral devices--DASD and even tape drives--are also emulated by the FLEX-ES software. And this brings us to our final two topics. EMULATED DASD The P/390 introduced emulated ckd and fba DASD to the world. When you run the P/390 configurator program, which uses its own set of emulation software that runs under OS/2, you can create 3380 or 3390 format mini-disks having as many cylinders as you want to specify, up to an architectural limit of 2 gigabytes. This takes us to the 3390 mod 2 range. To define a mod 3, which is bigger, the configurator manufactures two files. The first contains as many cylinders as can fit into 2 gigs, and the second contains the rest of them. I haven't played with P/390 disks that are bigger, but the architecture allows them to be defined. The PC file name is just suffixed with _1, _2, etc. When you specify the file name to the configuration file for the P/390, you just specify the _1 piece, and the system finds the rest of them. IBM distributes the system DASD for its ADCDs (Application Development CD-roms) in zipped P/390 format. All you have to do is to unzip the DASD files which are on their cd's, and define them to the configuration file of the P/390. When all of the disks are unzipped and defined to the P/390, you IPL the system and MVS comes up! Then you customize. This was unimaginable in former times (roughly until 1990). So on a P/390, you're only limited by how much hard drive space you have, as to how much DASD you can support on your MVS system. Unfortunately, the old microchannel PCs that ran the P/390 systems, didn't have very good IDE controllers, and my old model 750 P/390 will take a 200 gig Hitachi (i.e. IBM) disk drive, jumpered to 15 heads, and only use 7.5 gigs of that. What a waste! Fortunately, the newer PCs running FLEX-ES or even Hercules, will use all of their space capacity. And as we said before, you can carry a very huge DASD farm around on very few hard drives. And it can be ipl-able too! Actually, the revolution has really gone full circle, and there aren't many storage subsystems for MVS that use real 3390 hardware anymore. They are all PC disks under the covers, in RAID configurations or whatever, to boost their reliability. So the practical results of this disk revolution have already been implemented on most of our MVS systems. Only the external names haven't been changed. EMULATED TAPE When you talk about emulated tape, there are several different things which can be called that. One is the proprietary format of a "virtual tape library" where supposed tape files are really kept as disk files under the covers. That's not what we'll talk about here. Our immediate concern centers around P/390 and FLEX-ES type "virtual tapes", which contain the tape data as disk files. With these "virtual tape formats", the tape data blocks are sandwiched between "headers" that tell the emulated tape software how to jump from one tape block to the next, and where a "tape mark" is, to mark the end of a "tape file". For example, if you want to create a "tape" on a P/390 system, you satisfy the tape mount request with an OS/2 command called AWSMOUNT, that points to a file on PC disk, which is the supposed "tape". The FLEX-ES systems can deal with these virtual "AWS-format tapes" too, but they have their own format, called FAKETAPE. The FAKETAPE format really is like the AWS-format, but FAKETAPE has their own headers, and their architecture is currently a bit less flexible than the AWS-tape architecture for the P/390 virtual tapes. Now I'll show you how you can use these "virtual tape" formats to be able to keep your own tape collections on cd-rom or dvd-rom. And when you need the tapes again, you can convert them on any MVS system, to real tapes. I've written a set of programs that run on any MVS system, to make these conversions from tape to disk files. You can find these programs on File 533 of the Updates page of the CBT Tape collection of free MVS programs. Just do a www.google.com search on "CBT Tape". The programs are called VTT2DISK (tape to AWS-format disk), VTT2T2FK (tape to FAKETAPE), which go from real tape to these disk formats. And the programs to go the other way are: VTT2TAPE (AWS- format to real tape) and VTT2FK2T (FAKETAPE format to real tape). JCL to run these programs is provided in the File 533 pds. The one caveat is the format of the disk files on the MVS system. In order to treat an AWS-format disk file as a "virtual tape", it has to be a PC file. And PC files are just a long string of data on disk. On MVS systems, you can't have that. All MVS data has to be blocked. So when I created my AWS-format "tapes" or FAKETAPE-format tapes on MVS, I had to choose a blocking scheme. I chose Fixed Blocked, LRECL=80 format files on MVS, because they are easy to handle and send from one system to another. Therefore, if you want to use the "virtual tape" files that I create on MVS as "tapes" on a P/390 or FLEX-ES MVS system, they have to be downloaded in BINARY using FTP or IND$FILE to the PC system. If you want to take a FAKETAPE file or an AWS-format tape from a PC system and make a real tape from it using my programs, you have to upload them in BINARY to a pre-allocated MVS file in FB-80 format so they get folded over. Then my programs can read them and create real tapes from them. CONCLUSION Emulation of several kinds has revolutionized ALL MVS systems nowadays, and our working lives are affected in many ways. New DASD isn't old DASD anymore. It's all PC-type hard drives, in one form or another. An immmediate consequence is that IBM isn't changing the 3390 disk structure anytime soon, except to add more cylinder capacity to a logical volume. Tapes can now be archived as disk files. Full sized MVS machines can now be run on 5 pound notebook computers, and you can carry one around if you want to do that. A terabyte of MVS DASD can now be carried around in a small satchel. Life on the MVS scene is definitely different, and it has all been caused by emulation, in one form or another. So I hope you're all starting to think and explore the possibilities for yourselves. That big personal cartridge library can now be reduced down to a few cd-rom or dvd-rom disks. And you can go on from there. I wish the best of everything for all of you, and I hope to see you here again, next month.