S211KENO@HTIKHT5.BITNET.UUCP (01/16/87)
> 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
JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") (01/20/87)
Thank you all.
Most of the replies I have seen have delt with the effects of third
party vendors on a cluster. I went back and rummaged around my archives
and I found that the last installation of MINITAB did indeed do a
SET COMMAND. This was propbably the culprit although one reply
indicated that there might be at least one DEC product that can do the
wrong thing too.
I was also informed that the Relational Technology database system
INGRES v5.0 did the wrong thing. I have that sitting on my floor
right now. Thanks for the warning, I'll be on the lookout and will
scream bloody murder at RTI if their documentation doesn't point this
out.
As was pointed out to me, sometimes one can become too complacent
and self-secure with installation procedures that APPEAR to work all the
time. Appearances can deceive however and one might not get stuck untill
much later as happend in my case. I guess in pays to vigilant.
As to various statements concerning deleting of global sections
while still in use, I am still firmly convinced that there should be an
UNDELETE command for that. If there is enough information left around
for the section to be continued for users still using it then UNDELETE
or something should be doable. I'll have to look in the code sometime
but the delete pending message I got sounds like only one bit of
information. (as may be evident, I'm also convinced of the need for
command function symmetry especially at the system level, to an extent
of course)
Chris Johnson
Northeastern University
csnet: johnson@nuhub.acs.northeastern.edu
arpa: johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t: (617) 437-2335