DirMaint Considerations with the CMS Pipelines Runtime Library Distribution

Getting DirMaint 1.5 to Recognize the Runtime Library Level

If you use DirMaint 1.5 (prior to service level 9704, which includes PTF UV60087 for APAR VM61371) with the CMS Pipelines runtime library, both the DIRMAINT service machine and the DIRMAINT EXEC invoked by users will fail due to a check on the version of Pipelines being used. This check is performed in the DVHDIR EXEC (DIRMAINT EXEC, usually on the Y-disk) and in DVHPROF EXEC on DIRMAINT's 191 disk. The response to the "pipe query version" command differs between the VM/ESA version of Pipelines and the runtime library version. This throws off the parsing in the version check and causes DirMaint to refuse to work with an "unsupported version of Pipelines".

The following are the source change files that can be used to fix the two EXECs. You will have had to load the optional source onto a disk in order to use these fixes. If you do not have the optional source, you can modify the EXECs manually using these fixes as a guide.

DVHDIR M00001MM:
 
./ I 00320000          $ 325000 5000                  12/10/96 15:41:35
/*! M00001MM - Add support for runtime version of Pipes.  MMM          */PIPE
./ R 00960000          $ 961990 1990                  12/10/96 15:41:35
if pos('CMS/TSO',Pipe_version.1)>0 then                                  PIPE
    parse var Pipe_version.1 . ',' . v'.'r '(' .                         PIPE
else Parse Var pipe_version.1 . ')' v'.'r                                PIPE
 
DVHPROF M00001MM:
 
./ I 00525000          $ 527000 2000                  12/10/96 14:18:57
/*! M00001MM - Add support for runtime version of Pipes.  MMM          */PIPE
./ R 01410000          $ 1411990 1990                 12/10/96 14:18:57
if pos('CMS/TSO',Pipe_version.1)>0 then                                  PIPE
      parse var Pipe_version.1 . ',' . v'.'r '(' .                       PIPE
else Parse Var pipe_version.1 . ')' v'.'r                                PIPE

EXECUPDT should be used to regenerate the two EXECs using the COMPRESS and SID options. The resulting DVHDIR EXEC should be moved to the Y-disk (or wherever you keep it) and renamed to DIRMAINT EXEC. The DVHPROF EXEC should be moved to DIRMAINT's 191 disk.

Notes:

PTF UV60087 for APAR VM61371 provides support for VM/ESA 2.3.0, and has changed the method of making the check from using 'PIPE QUERY VERSION' to using 'PIPE QUERY LEVEL', and now works with the CMS Pipelines runtime library without modification. This PTF is included in RSU 9704 (and later).
There is more DirMaint information available online at http://www.vm.ibm.com/related/dirmaint, including information about several available New Function APARs.

Dealing with the Consequences of a Bug in CMS 12 Pipelines

A more serious problem that affects the source directory itself is also met when switching to the runtime library version of CMS Pipelines from CMS 12. A bug in the "crc" filter crept into the VM/ESA version of Pipelines in CMS 12. DirMaint uses "crc" to add a checksum to the end of every directory entry. Whenever you do an operation against a virtual machine (such as AMDISK, CMDISK, or anything that alters the entry), DirMaint checks its calculated checksum against the one recorded in the directory. Thus, the bad result returned by the "crc" filter in CMS 12 will have been recorded in each and every directory entry. The bug is documented in APAR VM59897, which was closed on 10/26/95. However, the PTF is not currently on an RSU tape.

The runtime library version of Pipelines does not contain this bug; its "crc" filter returns a correct value. Therefore, once you install the runtime version, DirMaint will be unable to match the recorded checksum value with the calculated value. You will be unable to do any operations against a directory entry, except GET and REPLACE. This problem will also occur if you apply the PTF, UM27508. Be warned: neither the APAR nor the PTF mentions the bug's effect on DirMaint.

Getting and replacing the entry will fix the checksum problem, as that forces DirMaint to recalculate the checksum and record the new value in the entry. However, with a large directory, it is not practical to get and replace every entry. You can force DirMaint to recalculate the checksums, but it requires destroying the source directory and then rebuilding it. If done carefully, this isn't as terrible as it sounds:

Do a backup of your current directory using the DIRM USER BACKUP command. Then disable DirMaint, so that no changes can be made to the directory until you are finished. In my case, I simply shut down DIRMAINT.
Log onto the DIRMAINT svm and access the 1DF and the 1DB disks.
Double check that the recent USER BACKUP file is on the 1DB disk. It never hurts to be extra careful.
Erase the USER DIRECT file from the 1DF disk and then copy the USER BACKUP file from the 1DB disk to 1DF and change its name to USER INPUT.
Restart DIRMAINT. You will receive message DVHPRO2002A, "Manual start is required for DIRMAINT. Enter DVHBEGIN when ready to start."
Enter "dvhbegin", and DirMaint will rebuild the directory from the USER INPUT file, recalculating the checksums. Once it is finished, the directory should be usable again.

Here's a listing of what my rebuild looked like:

VM/ESA V2.1.0   02/17/96 16:27
DMSACR1184E Directory ACADEM:DIRMAINT. not found or you are not authorized
........................................................................
 
PRODUCT:
IBM Directory Maintenance for VM/ESA (DirMaint)
5748-XE4 (C) Copyright IBM Corporation 1979, 1995.
Version 1 Release 5 Modification 0 Service Level 0000.
DMSACC724I 155 replaces A (191)
 
DVHPRO2008I ROLE = DIRMAINT
 
DVHPRO2010I TESTING USE OF MSGNOH ...
DVHPRO2002A Manual start is required for DIRMAINT.
DVHPRO2002A Enter "DVHBEGIN" when ready to start.
........................................................................
DIRMAINT MARIST.. - 1996/12/10; T=0.48/0.57 16:07:47
dvhbegin
DVHILZ3510I Starting DVHINITL with directory: USER INPUT E
DVHILZ3510I DVHINITL Parms: BACKUP QUIET NOCRCWARN
DVHILZ3509I Monolithic backup now exists as: USER BACKUP G.
DVHILZ3509I Continuing with execution.
DVHILZ3510I Starting DVHINITL with directory: USER BACKUP G
DVHILZ3510I DVHINITL Parms: BLDCLUSTER BLDLINK QUIET BLDDASD
DVHIZD3528W One or more DASD volume control files were created using
DVHIZD3528W default values for device characteristics.
DIRMAINT MARIST.. - 1996/12/10; T=45.93/46.91 16:11:15
DVHWAI2140I Waiting for work on 96/12/10 at 16:11:15.

Notes:

There is more information about this particular CRC bug available at http://www.vm.ibm.com/related/dirmaint/dirm_crc.html.
There are more answers to Frequently Asked Questions about DirMaint available online at http://www.vm.ibm.com/related/dirmaint.

Martha McConaghy / Marist College / urmm@vm.marist.edu

December 12, 1996

Updated:

May 14, 1998 by Mark Ritter, IBM DirMaint Support, ritterme@gdlvm7.vnet.ibm.com, to: (a) reflect the availability of PTF UV60087 for APAR VM61371 which provides support for VM/ESA 2.3.0 and eliminates the need for modifications to the DIRMAINT (DVHDIR) EXEC and the DVHPROF EXEC to use the CMS Pipelines runtime libraries; and (b) add links to other information about DirMaint.