Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!HTIKHT5.BITNET!S211KENO
From: S211KENO@HTIKHT5.BITNET.UUCP
Newsgroups: mod.computers.vax
Subject: Re: DCLTABLES horror story
Message-ID: <8701171523.AA12180@ucbvax.Berkeley.EDU>
Date: Fri, 16-Jan-87 06:07:00 EST
Article-I.D.: ucbvax.8701171523.AA12180
Posted: Fri Jan 16 06:07:00 1987
Date-Received: Sat, 17-Jan-87 18:50:49 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 33
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.

To protect files on the system disk I run a batchjob every night.
One of the reasons is I don't like the VMS file protections after a
installation of a new VMS release (for example, images like AUTHORIZE.EXE
are world executable).

One of the things this job does is
$ SET PROTECTION=W SYS$SYSDEVICE:[SYS%.SYSLIB]*.*;*
$ SET PROTECTION=W SYS$SYSDEVICE:[SYS%.SYSEXE]*.*;*
etc.
for every specific system directory (except [SYS%.SYSCOMMON] of course)

So if there is a problem with a software installation placing things not
in the common directories users start complaining the next morning...
This sounds a little bit cruel, but I think it's better than
messing up your system directories (users on root A running version X,
users on root B running version Y, that's REAL horror).
By the way, I've seen similar problems with
. a recent INGRES V5.0 installation (third party) and
. with SHELL V1.2 (second party) , creating
  an empty SYS$SPECIFIC:[SHELLEXE] , which the IVP didn't like (neither did I)

----------
Kees.       S211KENO@HTIKHT5.BITNET