This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Gilbert, re: > 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 > RAOBCON SPD 850 OLAY COLOR=3 GRA=2 CINT= H8SPD DASH=ALL > 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 Reason: 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 fi 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 directory. DATALOC -- done Then: ptlist.k RTPTSRC/PTSRCS FORM=FILE ALL 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 server 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 needed/used/correct. - added: SHELL=sh 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... Cheers, Tom -- **************************************************************************** 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