MVS TOOLS AND TRICKS OF THE TRADE June 1991 Sam Golob MVS Systems Programmer sbgolob@cbttape.org DYNAMASK - CHANGING DEVICE NAMES ON A LIVE SYSTEM IN SECONDS. Have you ever had to add new disk volumes or switch some volumes around on short notice? Did you ever convert a disk volume from another application to TSO use, and be forced to remove it from SYSDA, so the programmers wouldn't clog the volume up with their test files? Were you ever forced to divide your cartridge drives into separate esoteric categories during production hours, to keep some of the devices clear for high priority work? How many times have you told your management that these maneuvers would require an IOGEN, or an MVSCP and an IPL? If you used DYNAMASK, you'd never have to give them such an answer. You'd simply tell them: "Give me a minute and I'll fix it up for you. DYNAMASK is found on File 400 of the CBT MVS Tape, distributed by NaSPA (414) 423-2420, and by the Share Program Library Agency at the University of Miami in Florida, (305) 284-6257. DYNAMASK is also available on the L.A. MVS Users Group Tape. Merv Hemp (818) 841-9470 is in charge of that tape. WHAT IS DYNAMASK? DYNAMASK is a program which rebuilds the "Eligible Device Table" of MVS, using control card input to change the original table. You set things up in a general way, with the MVSCP. Then you can adjust the device name setup on the fly, more finely, with DYNAMASK. DYNAMASK, at this writing, is completely supported through MVS/ESA 4.2. Steve Smith of Security Pacific Automation Company, does the support work. (Now at SERENA International in Burlingame, CA.) What is the Eligible Device Table (or the EDT) in MVS. The EDT is an incore table that has all your general unit names. You code the unit names in the "UNIT=" parameter of the DD card in your JCL. Each unit name is associated in the EDT with a list of device addresses which are eligible to be used with that particular unit name. When you ask for the unit name in your JCL, MVS uses the Eligible Device Table to find a particular device, such as a tape drive, that fits the requirements for the unit type you specified. As we said before, The EDT is generated, for pre-SP2.2 systems, by the IOGEN process, which consists of coding assembler SYSGEN macros to fit your unit and address configuration, and assembling them with "GENTYPE=(IO,x)", or "GENTYPE=EDT" as a parameter in the GENERATE macro. For SP2.2 and later systems, the MVSCP process was created for the purpose of separating IO-related system setup from the process of nucleus creation. IO-related information after SP2.2 is not in IEANUC01, the system nucleus. In vanilla (IBM-shipped) MVS, once the EDT information was put out, you can't change it without an IPL. There are lots of shops where it's hard to IPL very often. These shops don't have much flexibility in swapping devices around, even at SP 2.2 or above. DYNAMASK can be executed, almost at any time, by starting a PROC. DYNAMASK can create new general unit names for you, at will. DYNAMASK can also adjust existing unit names to include or exclude more devices from each name. I'd like to mention another fact before going into the particulars of how DYNAMASK works. In the "UNIT=" parameter of a DD card, one may actually hard-code a specific device unit address number. You can specify a particular tape drive to use, such as "UNIT=48C". When there are a lot of tape drives, you may not wish to be so specific. You may want to specify a general unit name, such as "UNIT=TAPE" if you don't care which drive you'll get. When an eligible tape drive becomes available, you'll get that drive. There are two types of general unit names. These are: generic unit names, and esoteric unit names. Generic unit names are device class numbers, for example: "UNIT=3480" or "UNIT=3400-6". Esoteric unit names are words that have to start with alpha characters the way pds member names do. Esoteric names are usually created to be descriptive of the devices to which they refer. Some examples are: "UNIT=CART", "UNIT=DISK3350", or "UNIT=SYSTSO". DYNAMASK can create new generic and esoteric unit names, and can assign devices to them. Your installation's unit name structure can be made creatively interesting in short order, or otherwise adjusted to the shop's needs. One more thing. Because of release dependencies, there are two different versions of DYNAMASK that are distributed on the CBT Tape File 400. The Pre-SP 2.2 version of DYNAMASK is called DYNAMSK7. The SP2.2 thru ESA 3.1.3 version is called DYNAMSK2. Support for SP4.1 is hopefully forthcoming, and is being developed at the time of this writing. It remains to be seen whether IBM's work on dynamic device reconfiguration in SP4.2 will obsolete DYNAMASK, or whether DYNAMASK, after being fitted for that SP4.2, will do the job better than IBM's effort. HOW IS DYNAMASK USED? The DYNAMASK program has to be authorized, and must be executed from an authorized library. DYNAMASK is generally invoked as a started task, which accesses a card-image dataset that has its execution parameters. These parameters tell DYNAMASK which addresses to move among which unitnames. The DYNAMASK data is in the form of commands which specify an add or delete indicator, a partial or complete unitname, followed by (partial) addresses or volume serial names to include or exclude. See Figure One for a sample DYNAMASK PROC, and Figure Two for sample data commands. DYNAMASK takes only a few seconds to execute. Steve Smith recommends (in writing) that the system should not have much activity while DYNAMASK is running. One day, I asked him how great that risk was (because I needed to run DYNAMASK in the middle of the day). He said that during a small window, while bit masks were being moved around, some job might try to allocate a dataset on one of the devices being affected. This could cause the job to have an error. But he said the risk was not too great, and he knew of one shop that triggered off DYNAMASK executions automatically, several times during the day, without apparent harm. Most usually, shops will run a DYNAMASK procedure started by a COMMNDxx or IEACMDxx member of SYS1.PARMLIB shortly after IPL. Generally, DYNAMASK is run when you have to move devices around, where it's inconvenient to prepare different MVSCP's and IPL. Most shops are constrained concerning IPL's. One bank has an automatic teller system that has only one hour of downtime allowed over several months. DYNAMASK helps that system over and over again. Most shops are not so constrained, but they find waiting for an IPL to be constrictive, and they would rather have an alternative if one were available. How do you set the DYNAMASK control cards up? I've decided to present the rules for DYNAMASK execution in Steve Smith's words. See Figure Three for DYNAMASK help information, which comes from Steve's comments in the assembler source code. OTHER PROGRAMS THAT ARE DISTRIBUTED WITH DYNAMASK. File 400 of the CBT Tape, which contains DYNAMASK, and the corresponding file on the L.A. MVS Users Group Tape, have other related programs included besides the two DYNAMASK versions. I'll quickly describe them. DYNASWAP provides the ability to swap all unitname EDT affiliations of two offline devices. Suppose one disk drive goes bad, and you move its data to another drive. You'd like the new drive to behave exactly as the old one did, as programmers execute jobs against the new pack's data. Problem is that the new drive is at a different address, and the unitname designations in the EDT are keyed to addresses, not to volume serial names. If you have a pack called TSO001 at address 2C9, it might behave differently than a renamed pack TSO001 at address 9A5. DYNASWAP will flip the EDT-defined properties of address 2C9 with those of address 9A5, if you ask it to. Then, the new TSO001 at 9A5 will behave in allocations, exactly as the old one at address 2C9 did. UCBMASK is a program which will perform the function of the VATLSTxx member in SYS1.PARMLIB, but that function can be done at any time, not just at IPL time. UCBMASK will change the mount attributes of many disk devices at once, according to the contents of control cards. The control cards for UCBMASK do not follow the format of the VATLSTxx cards. Look in the source code documentation for UCBMASK to learn the format of the control cards and the layout of the JCL to run the program. VATUCB will read the cards in an old-style (through SP2.2.0) VATLSTxx member and adjust the mount attributes of all those disk volumes accordingly. It will do the function of UCBMASK, but the control card format is exactly that of a VATLSTxx SYS1.PARMLIB member. It may be possible, if an old-style VATLSTxx member is coded for an SP2.2.3 system or higher, to execute the VATUCB program successfully. SYSUNITS is a program that will report unit addresses associated with a list of unitnames. The SYSUNITS program can be used to verify if the changes done by DYNAMASK are in effect. SYSUNITS performs a very useful reporting function in the "EDTGEN" area. IN SUMMARY. The subject of the "Instant EDTGEN" is dear to the administrators of installations who don't IPL frequently, and who move devices around often. The DYNAMASK program makes trivial work of an awkward MVS construction that device ADDRESSES, and not device volume serial names, determine membership in the community of devices defined by any unitname. DYNAMASK performs instant changes of unitname membership, either by address, or by volume serial name. No IPL is required to execute any of these changes on an MVS system. The convenience of DYNAMASK, together with related programs that are delivered with it, saves MVS installations much time, and eliminates grief among operations and systems people alike. DYNAMASK is currently supported through MVS/ESA 4.2. I hope this knowledge will help many of you run your shops better. In any case, we hope to see you again next month. Good luck. * * * * * * * * * * * * * * * * * * * * * * * FIGURE ONE. This is a sample procedure to execute DYNAMASK as a started task. Note that the control cards can be found in member DYNAMCTL of SYS1.PARMLIB. //DYNAMASK PROC M=DYNAMCTL,P='START IPL POSTPROCESS' //DYNAMSK2 EXEC PGM=DYNAMSK2,PARM=&P //SYSIN DD DISP=SHR,DSN=SYS1.PARMLIB(&M.) * * * * * * * * * * * * * * * * * * * * * * * FIGURE TWO. This is a sample deck of DYNAMASK control cards, laced with many comments in an attempt to describe what is going on. * Comment card, add all volumes with volser starting with SYSDA * to the SYSDA group of devices. SYSDA SYSDA* * Add volumes SYSDA1, SYSDA2, SYSDA3, SYSDA4 to unitname SORT. SORT SYSDA1,SYSDA2, * Comment card, the next card is continuation of the previous one. SYSDA3,SYSDA4 * Remove devices 48E and 48F from the generic unitname 2400-3. -2400-3 /48E,/48F * Add some devices to the category of units called TAPE1. TAPE1 /42*,/5*,/440-45F * Create a unit name called SYSVIO. Include volser SYSDA1 under * this unitname. Designate SYSVIO to handle VIO. +SYSVIO SYSDA1 * * * * * * * * * * * * * * * * * * * * * * * FIGURE THREE. Steve Smith's help notes to describe the rules for coding DYNAMASK control cards. DYNAMSK2 CONTROL CARD FORMAT STARTING IN COLUMN 1, PUT THE UNIT NAME TO BE CHANGED OR ADDED FOLLOWED BY A BLANK. THIS IS FOLLOWED BY VOLUME(S) AND/OR UNIT ADDRESS(ES) TO BE ASSIGNED TO THIS UNIT NAME. VOLUMES CAN BE SPECIFIED ONLY FOR DISK DEVICES FOR UNIT NAMES OF DASD ONLY. VOLUMES ARE OF THE FORM: ONE TO SIX CHARACTER VOLUME IDS. LIKEWISE, A MODEL VOLUME OF ONE TO FIVE CHARACTERS PLUS AN ASTERISK WILL SELECT ALL VOLUMES THAT MATCH THE MODEL. UNIT ADDRESS ARE OF THE FORM: SLASH (/) AS FIRST CHARACTER, FOLLOWED BY THE 3 DIGIT HEXIDECIMAL UNIT ADDRESS. LIKEWISE A MODEL 1 OR 2 DIGIT HEXIDECIMAL ADDRESS PLUS AN ASTERISK WILL SELECT ALL UNITS THAT MATCH THE FIRST GIVEN DIGITS. A RANGE OF UNITS MAY BE SPECIFIED AS FOLLOWS /CUU-CUU IF MORE THAN ONE VOLUME OR UNIT ADDRESS IS NEEDED, EACH IS SEPARATED BY A COMMA. IF MORE ENTRIES ARE REQUIRED THAN CAN BE CONTAINED ON ONE CARD, THE CARD CAN BE CONTINUED BY PLACING A COMMA AFTER THE LAST ENTRY. THE NEXT CARD MUST BE CONTINUED ON OR AFTER COLUMN 2. THE SPECIFIED UNIT NAME ASSIGNMENTS NORMALLY REPLACE ALL PREVIOUS ASSIGNMENTS. HOWEVER, IF A MINUS (-) PRECEDES THE UNIT NAME, THE SPECIFIED UNIT...VOLUME ENTRIES WILL BE EXCLUDED FROM THE EXISTING ASSIGNMENTS DERIVED FROM SYSGEN. IF A PLUS (+) PRECEDES A UNIT NAME, THAT UNIT NAME IS MARKED FOR VIO. AN ASTERISK (*) IN COLUMN 1 INDICATES A COMMENT CARD. A COMMENT CARD CAN BE PLACED ANYWHERE. SAMPLES: SYSDA SYSDA* SORT SYSDA1,SYSDA2, * COMMENT CARD, THE NEXT CARD IS CONTINUATION OF PREVIOUS SYSDA3,SYSDA4 -2400-3 /48E,/48F TAPE1 /42*,/5*,/440-45F +SYSVIO SYSDA1 IF THE SAME UNIT NAME IS SPECIFED MORE THAN ONCE, ONLY THE FIRST IS USED. ANY ERROR OR INVALID SPECIFICATION IN A UNIT NAME CAUSES THAT UNIT NAME NOT TO BE UPDATED. ANY ERROR OR INVALID SPECIFICATION IN A UNIT ADDRESS OR VOLUME WILL BE IGNORED AND THE UNIT NAME WILL BE UPDATED WITH ANY CORRECT UNIT ADDRESSES AND/OR VOLUMES. MISSING VOLUMES ARE IGNORED. ALL UNCHANGED UNIT NAMES FROM THE SYSGEN ARE RETAINED. ONLY UNIT NAMES TO BE CHANGED NEED BE SPECIFIED.