DEGROOT@HWALHW5.BITNET.UUCP (06/01/86)
To install software on a VAX using the standard INSTALL-procedure
DEC advises to remove all the users from the system.
This is a big inconvenience of you are maintaining a cluster
with over 100 users.
Minor software-upgrades, eg. a new version of the FORTRAN compiler,
can apparently be done during normal time-sharing.
- But it is not recommended by DEC to do so! -
The upgrading to VMS 4.3 showed that first a lot of work was
done in an alternate system-root (SYSF). This could have been done
with all the users on the system. Only in the final phase
all the software is moved to the main root (SYS0).
It should be possible to do software installation on a running
system perhaps in an alternate system-root and then
reboot your system enabling your newly installed software.
QUESTION: Do you have any hints, comments, remarks concerning
'software-installation-on-the-fly' ?
Tel. 08370- .KeesdeGroot (DEGROOT@HWALHW5.BITNET) o\/o THERE AINT NO
(8)3557 Agricultural University, Computer-centre [] SUCH THING AS
Wageningen, the Netherlands .==. A FREE LUNCH!
DISCLAIMER: My opinions are my own alone and do not represent
any official position by my employer.Magill@upenn.CSNET.UUCP (06/05/86)
--------------------------------------------------------------------
To install software on a VAX using the standard INSTALL-procedure
DEC advises to remove all the users from the system.
This is a big inconvenience of you are maintaining a cluster
with over 100 users.
Minor software-upgrades, eg. a new version of the FORTRAN compiler,
can apparently be done during normal time-sharing.
- But it is not recommended by DEC to do so! -
The upgrading to VMS 4.3 showed that first a lot of work was
done in an alternate system-root (SYSF). This could have been done
with all the users on the system. Only in the final phase
all the software is moved to the main root (SYS0).
It should be possible to do software installation on a running
system perhaps in an alternate system-root and then
reboot your system enabling your newly installed software.
--------------------------------------------------------------------
ARGGGGGG! Obviously you have much faith in the ability of a software
upgrade to work correctly and the way you expect, the first time !!!!
While I have done upgrades of such things as "application" level
programs on a live system, it is somewhat suicidal. Invariably, the only
person who has a problem is directly related to the boss and complains
about it and you get crucified. (That person only had a problem because
he/she tried to compile a program at just the instant when the compiler
was version a and the libraries version b.)
Upgrading a live operating system is just plain masochistic. Murphy says:
"you will cream someone important's directory and will do it in such a manner
as it will take two or three days to fix."
Besides, the upgrade will blow up half way through, forcing you to kick
everyone off while you spend days trying to rebuild the system from the
backup tapes you didn't take before you started. Not to mention that the
work which was done between your last backup and when the update blew up
will be absolutely critical to at least two phd dissertations and the
financial well being of the corporation.
Upgrading a live system is just asking for trouble. It's like running
backup with users on the system and forgetting the /ignore=interlock parameter.
Now you understand why systems programmers/administrators work early in the
mornings and weekends.... that's when you can throw the users off and they
don't/won't complain too loudly. Besides, unless you run a vanilla
(ie, no local modifications or system dependent programs or procedures),
you need to test weather or not you local stuff still works.
As for inconveniencing your users, what causes them to complain more:
not having the system for a period of time .... or ...
discovering that suddenly their programs and procedures no longer work.
Besides, 100 users is a pretty small user community try running a system with
3,000 to 5,000, users it's even more fun.
The alternate root trick can be made to work, but it usually involves far
more work than you save. Typically, you would use a completely separate
disk drive to build and test the system on and then boot from that drive
making it your system disk for evermore. That's not really reasonable to
do anymore because of the high capacity dirives, however.