"MCCORE::BOLTHOUSE@ti-eg.CSNET".UUCP (01/12/87)
The problem you have experienced (DCLTABLES.EXE being in the wrong place)
is well known to our organization. The primary cause of such a problem
is generally unintelligent third-party software, especially those which
have not been reworked since the advent of search lists. We have seen
this crop up dozens of times, and nearly every time we can point to a
recent installation of a third-party product causing the DCLTABLES to
"move". Unfortunately, this problem cannot be detected until the next
installation, since DCL functions fine.
The root cause of the problem is search lists. When reading (searching),
a search-listed logical name, DCLTABLES.EXE will be found in both places
(SYS$SPECIFIC and SYS$COMMON) should it be present, and the tables from
SYS$SPECIFIC will be chosen first (see translation of SYS$SYSROOT!).
If no tables are present in SYS$SPECIFIC, then those in SYS$COMMON are
used. When writing the tables back to, say, SYS$LIBRARY:DCLTABLES.EXE,
they will go in SYS$SPECIFIC *unconditionally*. That's due to the
nature of search lists. Similarly, a $ COPY SYS$LIBRARY:A.DAT SYS$LIBRARY:
B.DAT may cause B.DAT to wind up in a different place than intended.
Start with A.DAT in SYS$COMMON and you'll see.
DEC installations generally try as hard as they can to put things in
SYS$COMMON. We dissected a few KITINSTAL.COMs upon discovering the
problem and verified this. We now try very hard to put new CLDs into
the DCLTABLES in SYS$COMMON. But sometimes we can't change the installation
procedures for third party stuff to comply, or we miss one. Then, when
the system manager calls us for support, we grin and say "Oh. SEARCH LISTS".
And he understands we've seen it sometime before. And we have to play all
sorts of nasty games ranging from getting backup copies of DCLTABLES.EXE
to reinstalling the software, depending upon when the improper installation
occurred.
So, this one isn't DIGITAL's fault, unless you can blame them for third
party vendors which haven't reworked their software within the 2 years since
VMS 4.0 was released...
David L. Bolthouse, Defense Electronics Information Systems, Texas Instruments
Ma Bell: 214-952-2059
Net: bolthouse%mcopn1@ti-eg.cs-net
Disclaimer: The opinions expressed above are mine, and if my employer knew
about them, I'd probably have several lawyers hanging around my
cube. What a fate.carl@CITHEX.CALTECH.EDU.UUCP (01/14/87)
> The problem you have experienced (DCLTABLES.EXE being in the wrong place) > is well known to our organization. The primary cause of such a problem > is generally unintelligent third-party software, especially those which > have not been reworked since the advent of search lists. We have seen > this crop up dozens of times, and nearly every time we can point to a > recent installation of a third-party product causing the DCLTABLES to > "move". Unfortunately, this problem cannot be detected until the next > installation, since DCL functions fine. Why can't the problem be detected before the next installation? Surely you could set up a procedure to invoke the VMSINSTAL procedure, then check the modification dates of any copies of DCLTABLES.EXE lying around in such directories when the procedure completes (if nothing else, you could have the site-specific shutdown procedure check to see if the current process has the file SYS$UPDATE:VMSINSTAL.COM open, and if it does, check for modifications that shouldn't have happened and permit the user to fix things up before the system has a chance to reboot and make the installation of the new image effective). > And he understands we've seen it sometime before. And we have to play all > sorts of nasty games ranging from getting backup copies of DCLTABLES.EXE > to reinstalling the software, depending upon when the improper installation > occurred. As I recall, VMSINSTAL likes to ask if you're satisfied with your backup of the system disk before it does anything serious. You shouldn't have much problem getting the backup copy of DCLTABLES.EXE off the save-set you told VMSINSTAL you had. And why need you reinstall the software (unless the procedure put other files in the wrong directories and edited the command language definitions it was installing to reflect that fact? Simply extract the definition from wherever it ended up (there's a program called VERB that's been around for years, runs under VMS 4.x, and whose source is only 96 blocks long [if you want a copy, let me know] that performs such extractions quite well), and then use the SET COMMAND command to put it where it belongs. If there's something about the problem that renders my observations invalid, please let me know before I run into the problem first-hand.