Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!ti-eg.CSNET"!"MCCORE::BOLTHOUSE
From: "MCCORE::BOLTHOUSE@ti-eg.CSNET".UUCP
Newsgroups: mod.computers.vax
Subject: RE: A small horror story at Northeastern Univ.
Message-ID: <8701131157.AA04908@ucbvax.Berkeley.EDU>
Date: Mon, 12-Jan-87 12:48:00 EST
Article-I.D.: ucbvax.8701131157.AA04908
Posted: Mon Jan 12 12:48:00 1987
Date-Received: Tue, 13-Jan-87 19:06:43 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 43
Approved: info-vax@sri-kl.arpa


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.