Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!CITHEX.CALTECH.EDU!carl
From: carl@CITHEX.CALTECH.EDU.UUCP
Newsgroups: mod.computers.vax
Subject: RE: A small horror story at Northeastern Univ.
Message-ID: <870113192231.00d@CitHex.Caltech.Edu>
Date: Tue, 13-Jan-87 22:23:57 EST
Article-I.D.: CitHex.870113192231.00d
Posted: Tue Jan 13 22:23:57 1987
Date-Received: Thu, 15-Jan-87 06:55:40 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 38
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.

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.