JOHNC%CAD2.DECnet@GE-CRD.ARPA (01/13/87)
> Following is an outline of a problem I recently encountered here at > Northeastern University. It points up the fact that I am possibly too > trusting in nature. It also shows the level of competence of DEC. I > thought I would let everyone in on it. The writer then describes a layered product installation of several products and problems with Pascal invokation due to scrambled DCL table entry. > 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. 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. Yup. That's the way rooted directories on a cluster work. You can use this to your advantage; one way is described in a later message on 9 january to get specific commands or applications available on one node only. > 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." To be kind this answer was unhelpful. To be > truthful this answer points up a dreadful lack of knowledge > on the part of DEC an DEC's support staff of their own > installation procedures. I think that's unfair. DEC installation procedures almost certainly don't create the extra copy of DCLTABLES in the specific root. If they do, that's a SPRable problem. It's more likely that a third party product installation either does or tells the system manager to run $SET COMMAND and modify the DCLTABLES for the system. If this is done without reflection then you'll get a new DCLTABLES in the system specific root of the system from which SET COMMAND was run. It'd be nice if Colorado customer support told you that, but it's not their responsibility to know what third party software does. > 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. Well, that's not a very good solution. It sounds like they had you do the INSTALL stuff in the wrong order. Everybody logged in has their hooks into DCLTABLES. That is a reason to fault Customer Support. > To solve this new problem, caused by implementing the > above DCSC advised procedure, the SYS$SPECIFIC version of > DCLTABLES.EXE had to be renamed and the system had to be > rebooted IMMEDEATELY causing inconvenience to users logged > on at the time. I think it was a false hope to think you could fix this without a reboot - "If it sounds too good to be true it probably isn't true" At a minimum you probably would have had to get everybody logged out. I have worked in a university environment, and I know you hate to reboot; sometimes it's just necessary though. You'd been a day and a half with the problem. Rebooting sounds like a relatively painless way to solve it, especially since it should have been only one node which required the boot. Your flame at DEC is, I think, unwarranted. They didn't come up with the optimal solution to your problem, but it was _your_ problem, not theirs. The warning about multiple DCLTABLES is a good one. I'll go check my system specific roots again right now, for that and all other sorts of things which belong only in common. Housecleaning isn't fun but it's necessary. John Child General Electric Aircraft Engines