Description of DR_DRCT
Download count: 6 this month, 1739 altogether.
Downloads for DR_DRCT:
VMARC archive: v-36K
These are a couple of tools created to deal with little VM directory-related emergencies, plus some other directory-related tools.
- MOVEDRCT EXEC lets you move and change the size of the DRCT area.
- MAPADASD EXEC finds CMS-formatted areas on a DASD pack.
- EXAMDASD EXEC displays CPFMTXA info for a range of DASD.
- DIRSUB EXEC creates a subset of a specified USER DIRECTory.
- RDIRSUB EXEC creates a subset of a specified USER DIRECTory. (RDIRSUB is kind of the complement of DIRSUB.)
- VM2EAV EXEC copies a VM system to a single volume, including creating and applying the new USER DIRECTory.
MOVEDRCT EXEC is the primary reason for this package. Mostly you are expected to use it when you issue DIRECTXA and get the message
HCPDIR760E NOT ENOUGH SPACE ALLOCATED FOR DIRECTORY EOJ DIRECTORY NOT UPDATEDNow what do you do? One trick to know is that DIRECTXA avoids writing over the old directory, so when you make little modifications to the USER DIRECTory and apply them by issuing DIRECTXA, you are effectively able to use only half the DRCT space. So you can create a temporary tiny USER DIRECT and DIRECTXA it -- there will be plenty of room -- and then do a DIRECTXA for your too-big USER DIRECT. Obviously this works only to a point, and there is some risk (see history below).
The desirable solution is to increase the size of the DRCT allocation. This involves some work with CPFMTXA, and while the steps are not difficult, you likely would need to do some research to figure out what those steps are, and it is easy to make a mistake. With MOVEDRCT EXEC, you simply create the DIRECTory you want, specify the size and location of the DRCT space as minidisk A01 of user $DIRECT$, and run the program. System administrators commonly include special NOLOGged UserIDs such as $DIRECT$ to delineate special areas on DASD, so there is likely to be such a UserID and "minidisk" already. You will have to figure out where you want your new DRCT area to be, though, and it needs to be on the same DASD as before. In the standard VM install, there is no significant unused space on the DASD with the DRCT area; you will have to identify some minidisk(s) that are not being used or that can be moved somewhere else.
MAPADASD EXEC is a tool to attempt to recover diskmap information from a DASD. It identifies areas allocated as PERM and tests for regions formatted as CMS minidisks. The output is a file with a list of such areas, presented as a disk mapping by PERM area.
EXAMDASD is useful when trying to guess the use of unknown DASD which you find yourself owning.
DIRSUB creates a subset of a directory. The subset includes just the
UserIDs you specify, plus any PROFILEs those UserIDs INCLUDE.
RDIRSUB does the same thing, except the subset created is of all the
UserIDs except those you specified. RDIRSUB works by running
DIRSUB with the complement (relative to the entire directory) of the
list of UserIDs specified.
-- Using MOVEDRCT EXEC --Presumably you have the USER DIRECTory you desire, which will tell you the address and label of the DASD holding your DRCT area (on the first non-comment line). Another way of discovering the DASD holding your DRCT area is to use the CP command QUERY ALLOC DRCT. Using this directory, e.g. with the help of the DISKMAP tool, determine where you would like your DRCT are to be on that DASD. Typically you will be making the new DRCT area larger than the existing area, so you will need to sacrifice some existing minidisks. Be sure to move these minidisks elsewhere or decide there is nothing there you want, because the new DRCT area will be CPFMTXA formatted, thus wiping out any previous contents of the sacrificed minidisks. Once you have chosen the new place for the DRCT area, indicate it in the directory file by adding or modifying the entry for user $DIRECT$, using that user's A01 minidisk to reserve the area. For example, if you have decided to use the 150 cylinders starting at cylinder 2345, and the disk label is "COWBOY", the entry would be
USER $DIRECT$ NOLOG MDISK A01 3390 2345 150 COWBOY RHaving prepared the new directory, invoke MOVEDRCT with
MOVEDRCT targetdasd dirfilename <dirfiletype <dirfilemode>>
-- Using MAPADASD EXEC --Determine the real address of the DASD you wish to inspect. Make sure you have the necessary privileges (A, B, G) and access to CPFMTXA. Then simply invoke the EXEC:
MAPADASD targetdasdThere are some conditions, e.g. if the target DASD is attached to another user, when the program will be unable to proceed. Fix the problem and try again, or use the program on some other system where the DASD is available and not in use. Note that MAPADASD EXEC does not modify the DASD it is examining, so it is safe to use from another system in order to circumvent access inconveniences. The program produces an output file with filename MAPADASD and filetype the DASD address.
-- Using EXAMDASD EXEC --This simple EXEC is handy for quickly looking at the CP formatting information for DASD over a range of addresses, which helps you discover which are set up for use as paging space, minidisks, etc. SSI ownership information, if present, is also displayed. Invoke as
EXAMDASD 1staddr lastaddr
-- Using DIRSUB EXEC and RDIRSUB EXEC --DIRSUB EXEC creates a file consisting of the directory entries of a specified list of UserIDs, plus any PROFILEs they INCLUDE. It is a subset of the directory specified as the input parameter, consisting of only those UserIDs' entries and the PROFILEs they reference. This is useful in creating or adding to directories when you wish to copy only some subset of the entries in an existing directory. To use, modify the EXEC by listing at the end of the program the UserIDs you want (replacing the existing list, which serves as an example). More detailed instructions are in comments at the beginning of the EXEC. RDIRSUB EXEC works the same way (actually building a new DIRSUB EXEC), except you list the UserIDs you don't want. One use for RDIRSUB is for extraction of all the user entries added since install, and the EXEC as supplied includes exactly the UserIDs from a z/VM 6.4.0 install. Note that RDIRSUB re-writes the list of UserIDs in DIRSUB EXEC, so if you have a version of DIRSUB EXEC that you want to keep, be sure to make a copy before running RDIRSUB EXEC.
-- Using VM2EAV EXEC --VM2EAV EXEC copies a multiple-volume VM system to a single volume. The single volume is expected to be big, EAV DASD, hence the name. Now that DASD sizes are large enough, it is practical to put your entire VM system on one volume. But the VM install does not (at the time of writing) give you this option. VM2EAV EXEC takes care of the moving. It creates a new USER DIRECTory, does CPFMTXA, SALIPL, and DIRECTXA as well as DDRing minidisks. PAGE and SPOL (and optionally TDSK) space are also allocated, so you can have a complete one-pack system if you so choose. See the EXEC for more detail. Also included is VM2EAV DATA, an example of the data file you will need to supply so that the EXEC knows what to do. (Note that due to contention, performance with a one-pack system is not going to be as good as if I/O can be spread over multiple volumes. If you expect to be performance limited, a one-pack system is probably not a great idea.)
-- History --The first two EXECs were written in connection with a problem we were having during testing: the DRCT area filled up so that we could not add anything to the directory without removing something else. MOVEDRCT EXEC is the straightforward fix for this problem -- just make the DRCT area bigger. But before we got around to creating it, we were using two directories alternately -- the big one we wanted, and a tiny one to temporarily allow more room. We made the mistake of not including in the tiny directory the UserID on whose minidisk the directory copies were stored. So having issued DIRECTXA and accidentally logged off, we had no way to go back. The files were still out there somewhere, but we needed to do a DEFINE MDISK to access them, and we didn't know where the minidisk was. MAPADASD EXEC is useful for this situation, narrowing down the possibilities to a practical number.
Who is "we"? Well, the one with a VM web page is Tim Greer.