[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[McIDAS #EXQ-796373]: McIDAS install

Hi Gilbert,

> I just saw this:
> The ADDE server definitely needs to be reinstalled. I just tried
> ./kickoff UPPER.BAT and saw this:
> Done
> FRMSAVE 2 /home/apache/weather/data/mcimages/hodos/apxhodo.gif
> Frame saved in /home/apache/weather/data/mcimages/hodos/apxhodo.gif
> HODO 72768 X X GRA=2 PRA=250 1050 INT=20
> RAOBCON: Cannot contact server (connect() failed)
> RAOBCON - Done
> RAOBCON failed, RC=1
> Accessing Dataset Name = RTPTSRC/UPPERMAND.ALL
> HODO: Cannot contact server (connect() failed)

I don't know why this happened (don't have _all_ of the details of what has
been done lately on climate).

I just logged onto climate as 'mcidas' and did the following:

1) renamed .bashrc to bashrc.sav


   Someone evidently copied ~mcidas/admin/mcidas_env.sh to .bashrc.  This is
   not needed nor is it desired when .bash_profile has been modified to
   read in settings in $HOME/admin/mcidas_env.sh.  Now, .bashrc does not
   exist, so the environment variables needed by McIDAS are being set by
   the construct:

if [ -e $HOME/admin/mcidas_env.sh ]; then
  . $HOME/admin/mcidas_env.sh

   Before I made this change, the MCDATA environment variable was being set
   to /workdata instead of /home/mcidas/workdata.

2) After correcting .bashrc, I logged off and then back on.  Now MCDATA is
   correctly being set.

   I then did the following:

   cd $MCDATA
   dataloc.k LIST

   After doing this, I noticed that several ADDE datasets were to be accessed
   from idd.unidata.ucar.edu.  Since this was incorrect (idd.unidata.ucar.edu
   is an IDD relay cluster, not an ADDE server), I changed the settings in
   /home/mcidas/data/LOCDATA.BAT from idd.unidata.ucar.edu to adde.ucar.edu.
   I then made the new settings active:

   <still as 'mcidas'>
   cd $MCDATA
   batch.k LOCDATA.BAT

   Now the client routing table entries are correct.

3) I verified that the ADDE remote server is working:

   <still as 'mcidas'>
   cd $MCDATA
   dataloc.k LIST RTPTSRC

   Group Name                    Server IP Address
   --------------------         ----------------------------------------
   RTPTSRC                      CLIMATE.COD.EDU

   <LOCAL-DATA> indicates that data will be accessed from the local data 
   DATALOC -- done



   Pos      Description                        Schema  NRows NCols Proj# 
Created DataDate
   ------   --------------------------------   ------  ----- ----- ----- 
------- --------
        8   SAO/METAR data for   08 JAN 2009   ISFC       72  7000     0 
2009007 2009008
        9   SAO/METAR data for   09 JAN 2009   ISFC       72  7000     0 
2009008 2009009
       10   SAO/METAR data for   10 JAN 2009   ISFC       72  7000     0 
2009010 2009010
       18   Mand. Level RAOB for 08 JAN 2009   IRAB        8  1500     0 
2009007 2009008
       19   Mand. Level RAOB for 09 JAN 2009   IRAB        8  1500     0 
2009008 2009009
       20   Mand. Level RAOB for 10 JAN 2009   IRAB        8  1500     0 
2009010 2009010
       28   Sig.  Level RAOB for 08 JAN 2009   IRSG       16  6000     0 
2009007 2009008
       29   Sig.  Level RAOB for 09 JAN 2009   IRSG       16  6000     0 
2009008 2009009

   This shows that the various datasets can be accessed, so the ADDE remote 
   does not need to be reinstalled.

> I am assuming that the ADDE server needs to be reinstalled?

I do not think so.

> Since McIDAS
> got wiped out and we started over, I am assuming this is a yes. It will be
> done later this afternoon or evening anyway.

No need.

> Also, COD/Tyler, take note: due to the mounting of the system, the
> McIDAS images weren't writing to the /home/apache/weather/data due to
> insufficient permissions. Images are now being written.

As far as I can see without spending too much time poking around, things
are working correctly in the 'mcidas' account.  If problems exist in the
script generation, then the problem is with the scripts.

I made a small adjustment to each *kickoff script on climate:

- remove the '-f' flag from the #!/bin/sh line.  This is not 

- added:

  export SHELL

  To each script.  This insures that the Bourne shell will be used to evaluate
  the script.  NB: this shouldn't be needed, but I have found that it was needed
  on some systems, and it does not harm.

Please let me know if you see any weirdnesses going forward...


Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
Unidata HomePage                       http://www.unidata.ucar.edu

Ticket Details
Ticket ID: EXQ-796373
Department: Support McIDAS
Priority: Normal
Status: Closed

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.