MVS TOOLS AND TRICKS OF THE TRADE AUGUST 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. HOW TO DO STUFF RIGHT I was tempted to call this column "Saving Your JCL", and a lot of what we want to talk about today, will have to do with that. However, I really want to be a bit more general, and talk about saving instructions about how to do each job, so you don't have to refresh your memory every time you try and do something over again. And you'll always get a consistent result, too. But having a policy and a method for saving your JCL is actually a very big part of this (more general) topic, of saving your stuff, when you've already done the job right. Over a period of years, I have watched many other systems programmers work, and I know that everybody has different habits, especially when it comes to the topic of saving JCL that was previously used. However, there are common threads in everyone's habits, and I think that this subject of saving JCL is well worth taking some time both to think about, and to talk about. I'll tell you about some of the things I've seen, and what I do myself. But I'd also appreciate it if people email me and show me their suggestions as well. JCL is used to execute (sometimes complicated) programs that run in batch. And due to the fact that these programs must often be called upon to carefully perform very detailed tasks, they therefore are endowed by their creators with a fairly involved set of controls in the form of keywords. Often those keywords have to be precisely specified, or the result you desire will not be obtained. For example, consider the job of the program ADRDSSU (DFDSS) to move a bunch of datasets from one disk pack to another. If you leave out just one keyword, this job will not work properly. For example, the datasets might be properly copied and recataloged, but the old datasets on the old pack would be uncataloged but not deleted. If that is not the result you want, it would be nice to keep a sample of the correct JCL handy. If it worked once, it will probably work again. When you re-run the old JCL for a new group of datasets and different disk packs, but with the same keywords, you'll still be almost sure that the job will run similarly to the way it did once before. Before we get into details, I feel it's worth mentioning one other fact which is obvious, but we don't think of it. Look at software utilities as if you were the writer, and not the user. Try to remember that since software programs are often written to do complicated jobs with multiple choices, the software writers and designers have to invent a usable set of controlling keywords for each utility they write. It isn't always easy for them to make the controlling keywords easy to learn and use. This was the topic of my November 2003 column called "Making Life Complicated". So for us now, the point is that often the software writers were not so successful in making their utility controls easy to learn. And therefore it might be hard to remember every controlling keyword which is necessary. If you leave out one keyword in some execution JCL or in the control of a TSO command, the whole darn thing won't work. It's almost like having a bug in a program, and often it's almost as pesky as finding a bug, to figure out what went wrong. So our recommendation is, that if you got it right at least once, save all the information about what you did. You'll be very glad later. SAVING YOUR JCL There are two aspects to saving your JCL. The first one is saving it, and deciding how many copies of similar JCL that you want to keep. The second one is finding the appropriate JCL for a job you want to do, among a set of JCL samples that you've already saved. If you've got a good "finding method" then it'll be easier to save more copies. If you don't, then you'll probably want to save as little as possible, but then you'll be more likely to be burned by not getting the keywords right, because you've saved too few examples to cover the ground. I guess that a big issue is WHERE to save your old JCL. I put mine in a plain pds, rather than in something like a PANVALET library. Pds'es are easier to back up (using IEBCOPY or the TSO XMIT command) and it is easier to find stuff there, using either ISPF Search-For or the free PDS command (from File 182 of the CBT MVS Utilities collection -- do a google search for the words "CBT Tape"). With PANVALET you have do some kind of ++SCAN, if you're searching for data by its content, rather than by member name. I make my JCL pds big, because I've got a good "finding method". For example, the JCL pds from one place where I worked for 6 1/2 years, has 2286 members, and I still have it. The JCL pds from another place where I worked for nearly 5 years, has 1522 members. My current JCL pds has 751 members, as of this moment. If you need more than one pds, you should certainly arrange that, but keep the names trackable, so you'll know where to look when you need to find the appropriate JCL sample. My boss at the first place (the 6 1/2 year one) used to complain that he could never find anything in my JCL pds. That's because he steadfastly refused to learn how to use the PDS command package. Back then, ISPF did not offer the luxury of having partial member lists (I think that concept was invented by Steve Smith in the PDS command package, and everybody else adopted it later.) My former boss was overwhelmed by having so many names to look at, in the member list. And after that, even if there were many similar but descriptive member names, like IEBCOP01, IEBCOP02 and so forth, he didn't know which of these he should look at. I did. I was comfortable. He wasn't. What was the difference? First of all, I could search my pds'es by member content, not just by member name. For example, if there was a sample IEBCOPY execution that had a member name of FLUBBUB, I could easily find it using a PDS subcommand in ISPF mode. The command is: FIND : /PGM=IEBCOPY/ THEN(MEMLIST) where the colon (:) means "look in all members". The resulting partial member list would yield all members containing the string "PDM=IEBCOPY", even if the member name was FLUBBUB. And it's much easier to search members in a partial member list than in a very long list. See? For me it was easy! Of course, when you design this, you have to figure if the JCL archiving method will only be used by you, or it will also be used by others. Other people will not be as familiar with the tools you are familiar with. So you have to take that into account. The other thing is portability. Using the OUTDSN keyword of the TSO XMIT command makes it easy to carry a pds with you, in sequential FB-80 format that can be downloaded to a PC and uploaded from a PC. It isn't that easy to back up a VSAM dataset with REPRO or some other utility, although it's quite possible too. So, if your archive was in VSAM format, like with the very unique ARCHIVER facility from Rick Fochtman in CBT Tape File 147, it might not be so easy to obtain a backup copy of it. This is something to take into account, ahead of time. Using a PDSE, rather than a pds, is also a factor. You never know where you'll have to restore the data, and with many older MVS systems, you might have a hard time getting a PDSE restored onto them. So it helps to DESIGN your JCL archive(s) and not just create them haphazardly. But if you've already created them haphazardly, you should take some time to redesign them and reorganize them. You'll be VERY thankful you did this, later on. COLLECTING GOOD ADVICE JCL isn't the only thing you can save. You can save instructions and advice about "how to do stuff right". One of my former colleagues claimed that he had a bad memory, so he would always write MANY details about how EVERYTHING got done, in pds members. Whenever I had to follow his act, I always appreciated this. After all, he DID the stuff before, and I didn't. If his memory was bad, mine (nonexistent) was even worse! So I was very grateful that he was so organized, and he wrote so much stuff down. As a result of my contact with this fellow, I was motivated to create a "how to" file on the CBT Tape, which would not contain programs, but which would contain a growing collection of miscellaneous advice, execution JCL, and all kinds of "how to" knowledge. Sometimes, you can't pay enough money to get advice like this. If, for example, a certain product won't install correctly unless you know a trick, you can save yourself many hours of work, if someone tells you the trick beforehand. I wanted to collect as much of this kind of stuff as possible. So File 570 of the CBT Tape is one place to try, if you need advice about how to do something. If you were fortunate enough to install a ServerPac from IBM, it would be a very helpful thing if you made a pds of all the generated jobs and advice, from the "installation jobs" section of the dialog. There might be 160 or so members there, but if you take the time to make pds members of them all to save for later, you will be very grateful. These members are full of practical "how to" knowledge, because you use these jobs to construct an actual MVS system from scratch. There's a lot of good JCL here. For example, in a "complete system replacement" execution of a ServerPac, the ALLOCDS job shows you working JCL about how to allocate ALL of the necessary system datasets for MVS. And you are pretty sure that this JCL should work properly. As a tip in constructing a pds member from a "browse-only" doc member from a ServerPac installation jobs list, go to the ISPF command line and type TSO ISRDDN. Then EDIT the CPPTEMP1 or CPPTEMP2 ddname, and you will be able to use the CREATE subcommand of ISPF EDIT to make a real pds member out of that material. Another good source for such JCL is in File 434 of the CBT Tape from Mark Zelden. These are in his ONEPAK** and TWOPAK** members, which help you construct a standalone one-pack or two-pack IPL'able MVS recovery system, from your current production system. A lot of good JCL is to be found in these members, and you can use the pieces, when you need to build an MVS dataset later. I would suggest (if you aren't already doing this) that you should make your own pds or sequential member, just for containing advice. Pretend that you have a bad memory, even if you have a good one. Look at a member of File 570 like SYSDOCB (from Bruce Bordonaro) if you would like to see one example of what you can do. If you have one of these datasets already, I'd appreciate it if you would email it to me, so I can add it to File 570 and use it to help everyone else. Don't hold back, even if you think your stuff is too system-specific. Someone else might have the same actual system need, and they will benefit from your particular and specific experience. That's what this collection is for. It is to help in specific situations, to show you how to solve specific problems or do a specific job. SUMMARY In our particular field of MVS sysprogging, we might go several years before we have to do a specific task twice. But when we need to get it right, we can't afford to make a mistake and have a system component fail afterward, just because we got a utility control keyword wrong in the JCL. So it behooves us to make it our business to save all JCL that has been proven to work. Sometimes we have done an install of a product, and we needed to learn some tricks to get it done. We might have to re-install or fix the same product, a couple of years later. In that case, it is surely helpful to have written down (in a dataset that you still have with you) what needed to be done then. So you should do it always, and not ever have to trip on the same thing twice. File 570 of the CBT Tape collection contains a lot of this advice already, but it is only from a few sources. We want this collection to grow. So please look it over, and see if you have something to add. Email it to me, and I'll see to it that your stuff gets added to the collection, so someone else can find it, and get this same kind of help. I hope that this month's piece will prove useful in making your work easier. Please join me again here, next month.