20010108: Multiple active Installations of McIDAS in same account

>From: Rita Edwards <address@hidden>
>Organization: NASA/MSFC
>Keywords: 200101081628.f08GSvo02818 McIDAS

Rita,

>I have received a request to install McIDAS-X 7.7
>on a SGI running IRIX 6.5.6f.  The issue is that
>the users do NOT want the 7.5 version removed until
>the 7.7 version has been tested.  Thus the question,
>can I place multiple active installation of McIDAS?

Yes.  I do this here for development purposes.

>My original thought was to set up an symbolic link
>for the home directory of McIDAS.  However, that 
>would not allow the users of the 7.5 version to
>continue work, while the testing of 7.7 is being
>conducted.

I took a different approach.  Please see below.

>My second thought was to use the ideas from
>your documentation "Testing the Build," 
>and have a script to set the environment variables 
>for a test session.
>
>However, I am not sure if this will provide the
>full functionality the user will require.  In 
>addition, I am unclear on about the impact of
>system resources.

The test setup is something I would not use for a lot of McIDAS
activity.  It works OK for testing, but I think that it has too
many negatives for use of two versions in parallel.

>Any ideas on tricks to pull this off?

Here is what I do (this is a little long, but I think it is pretty
clear, so hang in there):

1) the HOME directory for my 'mcidas' user is the "standard"
   /home/mcidas.

2) I _never_ put any "real" data files in /home/mcidas/data.  Instead,
   I put all data files off in either a separate directory or, better
   yet, on a different file system in a directory like /data/mcidas

3) I _never_ install a McIDAS distribution into /home/mcidas (i.e.,
   my McINST_ROOT is never defined to be /home/mcidas.  Instead, I
   install in a subdiretory of /home/mcidas.  In my situation, I not
   only want to keep different versions of McIDAS around and usable,
   but I also want to build the same distribution of McIDAS for
   different operating systems in the same account.

   To accomplish the needed separation, I create a set of SHELL
   definition files (i.e., .cshrc for the C shell which I use) that are
   setup to access an individual release of McIDAS or are for a
   particular operating system.  The OSes that I support are Solaris
   SPARC, Solaris x86, Linux, AIX, OSF/1, IRIX, IRIX64, and HP-UX.  My
   installation directories and corresponding C shell configuration
   files for these OSes are:

   home directory               C shell configuration file
   ----------------------------+--------------------------
   /home/mcidas/solaris         cshrc.solaris
   /home/mcidas/solarisx86      cshrc.solarisx86
   /home/mcidas/linux           cshrc.linux
   /home/mcidas/aix             cshrc.aix
   /home/mcidas/osf1            cshrc.osf1
   /home/mcidas/irix            cshrc.irix
   /home/mcidas/irix64          cshrc.irix64
   /home/mcidas/hpux            cshrc.hpux

   My main .cshrc file does a case switch on `uname -s` to figure out
   which cshrc.xxx file to source.  This way when I login, my
   environment is setup correctly for whatever OS I am running in:

# Set operating system name and release

   setenv OS      `uname -s`
   setenv RELEASE `uname -r`

   switch ($OS)
   case SunOS:
       switch ($RELEASE)
       case 4*:
           echo McIDAS-X is not supported under SunOS 4.x
           breaksw
       case 5*:
           switch (`uname -m`)
           case sun*:
               source $HOME/cshrc.solaris
               breaksw
           case i86pc:
               source $HOME/cshrc.solarisx86
               breaksw
           default:
               echo Unknown Solaris platform
               exit
           endsw
           breaksw
       default:
           echo Unknown SunOS version
           exit
       endsw
       breaksw
   case IRIX:
       source $HOME/cshrc.irix
       breaksw
   case IRIX64:
       source $HOME/cshrc.irix64
       breaksw
   case AIX:
       source $HOME/cshrc.aix
       breaksw
   case HP-UX:
       source $HOME/cshrc.hpux
       breaksw
   case OSF1:
       source $HOME/cshrc.osf1
       breaksw
   case Linux:
       source $HOME/cshrc.linux
       breaksw
   endsw

   Of course, the MCPATH, MCTABLE_READ, MCTABLE_WRITE, etc. settings
   in the cshrc files for the different OSes have to be setup correctly
   for things to work.

4) Step 3 is enough for running McIDAS on different operating systems,
   but it is not enough to be able to quickly swap in a new version of
   McIDAS on a particular operating system.  For this I do some
   additional setup that is fashioned after what users are advised to
   do for our LDM.  For different versions of McIDAS I have different
   install (McINST_ROOT) targets:

   /home/mcidas/mcidas77   ->  McIDAS-X 7.70
   /home/mcidas/mcidas76   ->  McIDAS-X 7.60
   etc.

   Since I may want to use McIDAS from one setup that looks "standard"
   (i.e., McINST_ROOT=/home/mcidas), I make links to the distribution
   to be used in the HOME directory of 'mcidas'.
   
   <login as 'mcidas'>
   cd /home/mcidas
   ln -s mcidas77 runtime
   ln -s runtime/bin bin
   ln -s runtime/data data
   ln -s runtime/inc inc
   ln -s runtime/tcl tcl
   ln -s runtime/help help
   ln -s runtime/man man
   etc.

   After doing this, the job of switching use between one version of McIDAS
   and another is very simple: just change the link for runtime:

   rm runtime
   ln -s mcidas76 runtime

   After doing this, I would be using the 7.6 version of McIDAS instead
   of the 7.7 version.

   I should mention that I only use this runtime setup for builds on
   one OS.  Since Solaris SPARC is the most popular OS in the Unidata
   community, the builds in the /home/mcidas/mcidas76 and
   /home/mcidas/mcidas77 directories are for Solaris SPARC.


I can tell you that this setup works nicely for me.  Also, at least one
Unidata site has adopted the same setup and seems pretty pleased with
it.

>Thanks for any help,

The above sketch of how I have setup my system may not be detailed enough
to "get" right off.  Please let me know if something seems lacking.

Tom Yoksas