MVS TOOLS AND TRICKS OF THE TRADE February 1996 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer EDIT AND SYSTEM RECOVERY. My systems programming teacher Jeff Broido used to emphasize a few principles. A very important one was to invest a little bit of time every day to learn new tools. Jeff used to say that the time spent playing with the new stuff, will definitely be saved later. You will get paid back. In my years of experience, I've found this to be very true. Most of us have a tendency to succumb to inertia at work. After a period of initial growth, we get to a point where we feel that if we got by yesterday, we can get by the same way today. Jeff's first principle, if followed as a habit, will help overcome this inertia and force us to have a more sustained professional growth. A second principle I learned from him, was always to have more than one way to do any job. In fact, the more ways you have, the better. On the systems level, anything can break, and one needs to have a way to recover from or circumvent such an occurrence. My favorite war story about this second principle concerns ICKDSF, the IBM utility which is used to initialize a disk pack. One might imagine that IBM would never allow an essential utility like ICKDSF to break. There are perhaps a few people in administrative positions who have a tendency to think like that. I once found a way to "clip" a disk pack (i.e. change its volume serial name) without using ICKDSF. I used the public domain Fullscreen ZAP program with its FULLVOL keyword to do the rename directly to the disk id record (track 0 record 3). A few months later, at a very critical time for us, ICKDSF did break, while MVS was running under VM. There was nothing IBM could do for us on short notice. ICKDSF under that circumstance was completely unusable. My little technique saved our whole project, without causing any noticeable impact to the users. It was like having a second key to your car, after you'd locked the first one inside. Today's topic will lean heavily on these two principles. Our current subject is about how to edit crucial datasets under emergency conditions, helping you to recover your system. This will prove to be very useful knowledge in itself. However, the mental approach which gave rise to this knowledge, comes directly from Jeff Broido's teaching: Invest some time every day to learn new tools. And always look for more than one way to do any job. These general principles have wider application than our specific "tips and tricks for the day". In the long run, it could be that you'll have even greater benefit from this mental approach than from the knowledge itself. With that said, let's talk about emergency editing and system recovery. EMERGENCY EDITING. WHY? Nowadays, I'd bet that most of us would think of the ISPF Editor when we think of editing a file. It wasn't always so, as old-timers will testify. Once upon a time, all that was available under OS was the line editor, called EDIT. Amazingly, EDIT is still around, and it is still effectively supported by IBM. From the MVT days, I remember that we had an editing product which allowed us to type over anything on a full screen. It was called FSE or Full Screen Edit. The version we had then was a vendor product, but there is a similar version of FSE which runs on MVS and is free. This version of FSE can be found on File 207 of the CBT MVS Utilities Tape, an independently produced tape that can be ordered through the NaSPA office. From now on in this column, when we talk about FSE, we'll mean the free MVS version from the CBT Tape. Following Jeff Broido's second principle, it pays to set up and learn to use FSE for emergency purposes. FSE consists of only eight small load modules, which you can assemble from source code. I'm sure that most shops can find a linklist library where these can be easily stowed away, to be ready if needed in an emergency. A logical question is: "Why should we need to go to this trouble?" Our practical answer: Sometimes ISPF, and the ISPF editor, can't be run. We could then certainly use a substitute file editor. Let's explain. ISPF needs a whole bunch of datasets allocated to your TSO session in order to run. DDNAMES required are: ISPLLIB for ISPF load libraries, ISPPLIB for panel libraries, ISPMLIB for message libraries, ISPSLIB for skeleton libraries, ISPTLIB for table libraries, ISPPROF for the ISPF profile dataset, SYSPROC for CLISTs and REXX execs, and possibly others. For most of these DDNAMES, if the concatenation of datasets belonging to that DDNAME cannot be allocated, ISPF won't work at all. The ISPF editor will therefore be unusable. Most of the time, these DDNAMES get allocated to your TSO session either through JCL in your logon procedure, or with dynamic allocation under your logon CLIST or REXX exec. If one dataset is missing somewhere, and a DDNAME isn't allocated because of it, what happens depends on the allocation method used. If the allocation is in the JCL for the logon proc, the entire TSO session is dead. If the allocation was done dynamically through the logon CLIST or REXX after the TSO session was started, only ISPF is dead. Either way, you still don't have the use of the ISPF editor. Clearly, one can see from here, that your session is safer if most of the datasets are allocated through a CLIST or REXX and not in the logon proc JCL. If you leave most of the allocations out of the JCL, doing them later through a CLIST or REXX exec, at least you'll still have a TSO session to work with, after any of these allocations fail. When the allocations from the logon proc fail, you don't even get in. Your TSO session goes down with a JCL error, the same as a batch job with a JCL error would. It's far better to have a less powerful TSO session, than to have no session at all to work with. Once you've taken the measures to start your TSO sessions using a "bare bones" logon procedure with later CLIST or REXX dataset allocations, we can talk about exploiting FSE. FSE will edit a dataset or a pds member with almost nothing being actually allocated to your TSO session. FSE is SMALL and consists of a few load modules only. FSE doesn't need the numerous dataset allocations that ISPF needs. Therefore you'll be able to fix PARMLIB members, PROCs in SYS1.PROCLIB and other crucial system elements if you get a minimal TSO session going, having FSE available from a linklist library. Everything we're saying about using FSE for emergency file editing also applies to using the IBM TSO line editor called EDIT. EDIT is a TSO command found in SYS1.CMDLIB, which is usually in the link list. Therefore, EDIT requires no additional dataset allocations. Also, EDIT is available on almost every MVS system, and normally needs no additional setting up. EDIT is just a bit tricky to use, and requires some prior practice (maybe about an hour or two) in order for the user to feel comfortable with it. So one might ask the question: Why do most of us feel helpless when ISPF isn't there? The answer is simply that we have not invested some time in preparing ourselves to use these other editing tools. GETTING STARTED WITH FSE. FSE consists of eight load modules which can be assembled from source code and link-edited to one of your linklist libraries. To invoke FSE from your TSO session, one need only enter the command: FSE 'dataset.name' plus perhaps an optional keyword. Full editing of a dataset or pds member can only be done if the dataset or member has sequence numbers, although browsing (invoked by the LIST option) can be done without any sequence numbers in the data. During an emergency, this limitation is usually minor. You're usually happy to be able to fix the SYS1.PARMLIB or SYS1.PROCLIB member that is wrong. However, the TSO EDIT command, which is somewhat less convenient to use than FSE, does not require sequence numbers in the data, although sequence numbers make the editing much easier. We will talk about the EDIT command soon. FSE is relatively simple to use, and its HELP member, which is partly shown in Figure 2, is quite short. You can effectively exploit FSE with about 15 minutes of practice. Although FSE is not crammed with sophisticated features, it gets the job done in a pinch, and is very easy to use and to learn. With FSE, you'll be fixing broken data in minutes. THE TSO EDIT COMMAND. Once, (not so) many years ago, the TSO EDIT command was the only available effective way for manipulating JCL, program source code, and CLISTs under TSO. Jeff Broido, in a recent conversation, told me that when the SPF editor (the precursor to the ISPF editor) first came out, people didn't want to use it. They were familiar with the EDIT command, and they resisted learning something new. What a reversal of roles to think that the former shop standard now has to be taught to programmers as an emergency editing tool! Let's get started. EDIT is easy to invoke, but once there, it's a bit tricky to use correctly. I'll try to mention some helpful hints to guide you on your way. SYS1.HELP on every system, contains a HELP member for the EDIT command. If you print this member off, and have the printed copy handy, you'll have a reference available for command syntax. That is very important in the absence of manuals. If you can get access to them, the TSO/E Command Reference and the TSO/E User's Guide are the good manuals. But the most important way to learn the EDIT command is to practice editing junk datasets and pds members. EDIT is invoked as a TSO command in the form: EDIT 'dataset.name' dataset-type process-type where "dataset-type" is a keyword expressing the data format of the dataset or member. Examples of dataset type can be CNTL, COBOL, ASM, CLIST, DATA, GOFORT, PLI, TEXT, and some others. "Process-type" tells EDIT the processing facts it needs to know. Examples of process-type are NEW, OLD, NONUM (to edit a non-numbered dataset). NEW tells EDIT to allocate a brand-new dataset; OLD tells EDIT to look for a dataset that already exists. Once you've invoked EDIT, you have to watch carefully for two different things at all times. First, you must always know where the current line pointer is. Second, you must always be aware of whether you are in the INPUT mode or EDIT mode of operation. INPUT mode treats everything typed in (including commands) as new file data. You have to be especially watchful about this because it is easy to corrupt your files by mistakenly INPUTting images of EDIT commands, which you'll have to delete later. EDIT mode allows you to enter subcommands to correct or change data that was already in the file. When you are in EDIT mode, you cannot add additional data records, unless you COPY or MOVE existing records to another place. Additionally, you must be aware if the dataset is numbered or non-numbered (NONUM). EDITing lines without sequence numbers is harder. It is best to start practicing with a numbered dataset. If you're editing a NEW dataset, you'll always enter in INPUT mode. If you edit an existing dataset, you enter in EDIT mode. The initial prompt that you're in INPUT mode is the word, "INPUT". The initial prompt that you're in EDIT mode is the word, "EDIT". INPUT mode treats everything you type, as data being inserted into a new data record. When ENTER is pressed in INPUT mode, and there is non-null data on the line, that line becomes a record, and everything typed afterward, goes onto a new line. In this context, it's a bit difficult to keep track of column alignment, unless you're used to it. All these data records will be inserted after the record being pointed to by the current line pointer. EDIT, especially if you don't have sequence numbers, will not automatically tell you where your current line pointer is. This is a tricky thing which confuses most people who are new to EDIT. You stay in INPUT mode until you enter a null line by pressing ENTER on a new line without entering any data. At this point, you'll be prompted with the word, "EDIT", which tells you that you are now in EDIT mode and you can start entering subcommands. Pressing ENTER in EDIT mode with no subcommand, will switch you to INPUT mode. Pressing ENTER in INPUT mode with no data, will switch you to EDIT mode. Each time you switch, you get the appropriate prompt. The first subcommand you should learn is LIST. LIST without any operands, will display the entire dataset or member on your tube, one screen at a time. At the completion of the display, the line pointer will point to the last line of the dataset. The next command is TOP, which points the line pointer to the top line of the dataset. BOTTOM points the line pointer to the bottom line of the dataset. DOWN nn moves the line pointer nn lines toward the bottom. UP mm moves the line pointer mm lines toward the top. LIST * , with no other operands, will display the current line, and leave the line pointer where it is. LIST * 2 , will display 2 lines at the current line pointer, and will then move the line pointer one line down. LIST * 3, will show 3 lines and move the line pointer 2 lines down. You have to play with this to get a feel for it. Jeff Broido recommends that the very first time you go into EDIT mode, you should enter the subcommand, VERIFY ON or V ON. VERIFY ON will prompt you each time a CHANGE command has successfully substituted one string for another. Otherwise, you don't get notified, though you need to do a LIST command anyway, to see what was done. I don't have space to teach you how to use EDIT here and now. The HELP members and manuals will assist you, but you have to practice adding and deleting lines, aligning each line to the proper column, changing strings of data, and so forth. Once you've done that, you should feel quite confident about (carefully) fixing PARMLIB and PROCLIB members. After having practiced with EDIT, you'll probably agree that FSE is much easier. I hope you've had fun listening to me, and I hope you have more fun practicing with these editing tools. Someday, this practice will pay you back. See you next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. A sample FSE (Full Screen Edit) screen, in the process of editing a JCL member in a partitioned dataset. This editor falls far short of having the power of the ISPF editor, but when ISPF will not come up, there is plenty of power to fix what needs fixing. This editor is free, and it comes from File 207 of the CBT MVS Utilities Tape. ==> PF ==>TOP OF DATA SET 170131 //IEHINIT JOB (rest of JOB card goes here) 170300 //* 170400 //****************************************************// 170500 //* INITIALIZE STANDARD LABEL ON A TAPE *// 170600 //****************************************************// 170700 //* 170800 //LABEL1 EXEC PGM=IEHINITT 170900 //SYSPRINT DD SYSOUT=* 171100 //T DD UNIT=(CART,,DEFER),DCB=TRTCH=NOCOMP,DSN=SBGHIT.INITT 171235 //SYSIN DD * 171335 T INITT SER=ABCDEF,OWNER='SAMGOLOB',DISP=UNLOAD 173000 /* 174000 // COL 1 Ý---Ý----Ý----Ý----Ý----Ý----Ý----Ý----Ý----Ý----Ý----Ý----Ý----Ý----Ý-- * * * * * * * * * * * * * * * * * * * * * * * Figure 2. Abridged HELP for the FSE (Full Screen Editor) native TSO command. This is a simple but capable file editor that doesn't take up much room or resources. FSE is not related to ISPF and doesn't need ISPF at all. In an emergency when ISPF does not come up and the ISPF editor is not usable, editing a dataset from SYS1.PARMLIB or SYS1.PROCLIB with FSE can save the day. )S SUBCOMMANDS - TOP,BOTTOM,PF,PB,HF,HB,FIND,DSN,AUTOSAVE,DELETE,UP,DOWN,INSERT, COLUMN,CHANGE,COPY,MOVE,SAVE,SAVEEND,END,RENUM,DONE,SUBMIT,PFK )F FUNCTION - THE FSE COMMAND IS USED TO CREATE OR MODIFY SEQUENTIAL DATA SETS, MEMBERS OF PARTITIONED DATA SETS OR THE BROWSING BACK AND FORTH OF UN-NUMBERED DATA SETS (DUMPS ETC..). IT ALLOWS THE SIMULTANEOUS UPDATE OF UP TO 21 LINES ON A CRT TERMINAL AND THE EXECUTION OF AN FSE SUBCOMMAND OR TSO COMMAND AT THE SAME TIME. )X SYNTAX - FSE 'DSNAME' NEW/OLD LIST/NOLIST CLIST/DATA/CNTL/ASM/PLI/COBOL REQUIRED - 'DSNAME' & BLANKS SEPARATING KEYWORDS DEFAULTS - OLD,NOLIST ALIAS - NONE NOTE - THE DATA SET MUST HAVE VALID LINE NUMBERS IN ASCENDING ORDER NOT EXCEEDING 999999, ELSE USER WILL BE ASKED TO EITHER RENUMBER IT OR END FSE SESSION.