cetron%ced@CS.UTAH.EDU.UUCP (04/10/87)
I have over and over found the only reliable way is to shut everything down and do it at once...... While my management is as bewildered as yours, mine last almost 2 days work when he demanded to keep running while I installed and test a new BRU (rsx's sorta equivalent to backup) - and while it recreated his entire directory, every file was empty......I don't get questioned much anymore and can often be found doing updates saturday night at 3am.... -ed cetron Computer Services Manager (this is a professional reply, must use title) Center for Engineering Design (-: Univ. of Utah.,
MOORE@UTHSCSA.BITNET.UUCP (04/10/87)
Well its me again. I have another question about policy at different sites. My last question of this type netted one response, but I will try again. We have four VAXen in a cluster with 9 RA81s that are dual ported with two HSC50s. When we install software on the cluster (eg. new versions of FORTRAN or Datatrieve) we will disable logins on all four machines, since anything the installation procedure touches is accessible to all of the machines. We don't have any real schedule for software installation. We will generally wait until two or three products have arrived so we can get them all done at once. Management is complaining that it is absurd to disable all four machines for the installation of software. And that at least some of the machines should be up at all times. I could take one machine down and install the software, but... I would like to establish a software installation policy and put this one to bed. You can help me do this. Please tell me what your software installation policy is. A couple of lines will do. I just want some ideas. Mark Moore The University of Texas Health Science Center San Antonio, Texas
nagy%43198.hepnet@LBL.ARPA.UUCP (04/10/87)
Being a relatively fearless system manager, I've installed "minor" items like new compiler versions on live systems on a VAXCluster and then just logged into the "other" system and used INSTALL to REPLACE the shared images. Datatrieve and others were done on semi-live systems due to the lenght of time required for the install and other factors (more complex products). Factors in installing on live systems are: - updating the shared images on the other nodes (can be easily done with INSTALL REPLACE). - a user might interfere with the install by using the HELPLIB at the time the installation attempts to put a new module into the library. - new DCLTABLES can be installed on other nodes by the same INSTALL trick as above. But users must logout and back in to use the new tables. - others I've probably forgotten.