Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!GRINNELL.MAILNET!McGuire_Ed
From: McGuire_Ed@GRINNELL.MAILNET.UUCP
Newsgroups: mod.computers.vax
Subject: (none)
Message-ID: <8701162045.AA17103@ucbvax.Berkeley.EDU>
Date: Thu, 15-Jan-87 13:15:00 EST
Article-I.D.: ucbvax.8701162045.AA17103
Posted: Thu Jan 15 13:15:00 1987
Date-Received: Sat, 17-Jan-87 01:44:01 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 73
Approved: info-vax@sri-kl.arpa

>For a reason as yet unknown to both DCSC and Northeastern there was a
>copy of DCLTABLES.EXE in SYS$SPECIFIC:[SYSLIB]. When a cluster node is
>booted, the SYS$LIBRARY logical name is equated to
>SYS$SPECIFIC:,SYS$COMMON: IN THAT ORDER.

On our cluster, we don't have a DCLTABLES in SYS$SPECIFIC:[SYSLIB].  Or
at least, not usually.  A couple of times we have accidentally created
one, and had the same problem you did.  In particular, this happened
when we installed TeX.  The TeX installation guide told us to perform
the following operation:

$ SET COMMAND/REPLACE -
  /TABLES=SYS$LIBRARY:DCLTABLES -
  /OUTPUT=SYS$LIBRARY:DCLTABLES -
  TEX.CLD

The /TABLES qualifier read from the only DCLTABLES.EXE in SYS$LIBRARY
(the one in SYS$COMMON:[SYSLIB]), but /OUTPUT wrote to the first
directory in the search list (SYS$SPECIFIC:[SYSLIB]).  To fix the
problem, we performed the command using

  /OUTPUT=SYS$COMMON:[SYSLIB]DCLTABLES

>Thus, if there is a DCTABLES.EXE in SYS$SPECIFIC (as there was in this
>case) then it will get installed on boot EVEN THOUGH THE SYS$COMMON
>version of DCLTABLES.EXE was the one that was updated by the layered
>produces installation procedures.

Correct.  Normally, one only does this if one wants variants of
DCLTABLES for each member of the cluster.  And I wouldn't recommend it.

>When asked why there were multiple copies of DCLTABLES in multiple
>directories, the DCSC engineer was able offer no explanation other than
>"We don't know, it just happens sometimes."

Perhaps one or more of the layered products you updated was guilty of
the same mistake as the TeX installation.  Or, maybe you already had a
SYS$SPECIFIC copy of DCLTABLES before the installation.

>As a solution, The DCSC engineer had Mr. Johnson install, using the
>INSTALL utility, the SYS$COMMON:[SYSLIB] version of DCLTABLES.EXE and
>then delete, again with the install utility, the SYS$SPECIFIC:[SYSLIB]
>version of DCLTABLES.EXE. This was very shortly determined to be an
>ill-advised procedure. The SYS$SPECIFIC version was of course still in
>use and a delete pending flag was raised on its global sections. This,
>in turn, prevented anyone else from logging on to the system since a
>global section with a delete pending flag is effectively not usable.

A global section with a delete pending flag is certainly usable.  When
you deinstall a shareable image, it can't actually be removed from the
table until the last person connected with it logs off.  This does not
prohibit you from installing a new shareable image of the same name.
And users who log in between the deinstall and the reinstall simply get
connected to the disk file instead of any global section.

I would look for another reason for the inability to log on.  On our
system, when we installed TeX, users could not log on.  But this was
because the SYS$SPECIFIC copy of DCLTABLES was created from scratch with
default file protection of (S:RWED, O:RWED, G, W).  Users got protection
violation errors trying to log on.

Our solution was:

1. Deinstall SYS$SPECIFIC:[SYSLIB]DCLTABLES.EXE

2. Delete SYS$SPECIFIC:[SYSLIB]DCLTABLES.EXE (because we knew that the only
   difference between it and SYS$COMMON was the TeX commands and we were
   going to reinstall them in SYS$COMMON)

3. Insert TEX.CLD into the remaining SYS$LIBRARY:DCLTABLES.EXE that was
   in SYS$COMMON

4. Install SYS$LIBRARY:DCLTABLES.EXE