WCE8760@TAMVENUS.BITNET.UUCP (01/18/87)
Fellow VAXlings, In the recent dialog of late, there has been a number of questions about DCLTABLES.EXE getting transplanted to the sys$specific root of a multi-root cluster. This strange occurrence has befallen me as well. These are the conclusions that I came up with, but may not neccessarily reflect the same situation that transpired at the original site that brought out the question. I was installing some product with VMSinstal, I think it was FMS. In any case the other processor, a 785, in my cluster started receiving compliants concerning the inability to utilize the new product after reboot. It was originally installed from the 8600. Upon further investigation, it was noticed that the DCLTABLES.EXE had a copy sitting up in the sys$specific:[syslib] directory root. We were supposed to be running a common system disk with a sys$common root that held most of our running images, including DCLTABLES.EXE. It had somehow during the vmsinstal, managed to get placed in the wrong directory root. After digging around in the kit's saveset and fooling around with the vmsinstal.com file I realized what was happening. This could be considered to be a foolish mistake on my part in the first place. I have about 40 layered products on my cluster and unfortunately have gained a false sense of security when it comes to software installations. In any case, I was running the installation from my personal account which is UIC [1,5]. Most system files are [1,4] or [1,1]. It turns out the installation procedure wants to place files in vmi$root, which should be sys$common for the DCLTABLES.EXE file on my system. However, the VMS logical search strings, in collusion with VMS aliases use the UIC pattern that currently exists on the file of interest to figure out where the file should be written root-wise. Some utilities can bypass the alias problem with an account that has privs. EDT for instance will always place the higher version in the same root, even if you are using a differnet UIC than the original version. SET COMMAND is not one of these such utilities. If you have a DCLTABLES.EXE file in the sys$common:[syslib] directory with UIC [1,4], and you subsequently issue the following command from an account with full privs and UIC [100,77]. You will find that there is now a new version of your tables file, but it now resides in sys$specific:[syslib]. SET COMM/TABL=SYS$SYSROOT:[SYSLIB]DCLTABLES/OUT=SYS$SYSROOT:[SYSLIB]DCLTABLES - somefile.CLD The plain fact is that this will happen with any file under similar circumstances. I don't know all the utilities that this behavior occurs with, but I can assure you that I now install everything from the system UIC. I believe CREATE also exhibits this behavior Chip Eagle Academic VAX Systems Manager, Texas A&M University College Station, Texas 77843 TEXnet: VENUS::WCE8760 BITnet: WCE8760@TAMVENUS (409)845-7594