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: > Well, as it turns out, I deleted your last response to me, which > isn't on your support server yet...weather3's hard > drives are failing, our network outside of NIU Weather in my departmental > office blew up, so I had to help with that...and the phone to the hard > drive vendor for warranty replacement is temporarily down. Can you play a > country song for me here? ;-) What's up with you and hard disks? We rarely see a disk go out... re: > OK, but here's the deal: RTIMAGES, which is what stopped on October 1, I > think, should point to weather2. I just looked on weather.admin at the > config, and it shows it is pointing there, so I have no idea why it is > pointing to weather for an outdated dataset. OK, I am confused. I logged onto weather.admin as 'mcidas' and did a 'crontab -l' to see what is run out of cron. Here is what I see: # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.5141 installed on Thu Aug 18 10:43:43 2005) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) 00,12,27,42,57 * * * * /home/mcidas/kickoff /home/mcidas/workdata CFDGONLY.BAT #00,6,12,18,24,30,36,42,48,54 * * * * /home/mcidas/kickoff /home/mcidas/workdata CFDGONLY.BAT 00,3,5,8,10,13,15,18,20,23,25,27,30,32,35,38,40,43,45,47,50,53,55 * * * * /home/mcidas/kickoff WEATHERWATCH.BAT 1,2,4,6,7,9,11,12,14,16,19,21,22,24,26,28,29,31,33,34,36,37,39,41,42 * * * * /home/mcidas/kickoff WEATHERWATCH.BAT 44,46,48,49,51,52,54,56,57,58,59 * * * * /home/mcidas/kickoff WEATHERWATCH.BAT It looks like you have 3 entries that each run WEATHERWATCH.BAT from your /home/mcidas/kickoff script. The first uncommented entry, however, is apparently trying to run /home/mcidas/workdata?? Your kickoff script expects the 1st passed parameter to be the name of a McIDAS BATCH file: #!/bin/sh -f # Set environment variables using Bourne shell syntax MCHOME=/home/mcidas MCDATA=$MCHOME/workdata MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help MCLOG=$MCDATA/crontab.log MCTABLE_READ="${MCHOME}/data/ADDESITE.TXT" PATH=$MCHOME/bin:$PATH LD_LIBRARY_PATH=/usr/local/lib:/lib:$MCHOME/lib:/usr/lib # export the environment variables so that they can be used export MCHOME MCDATA MCPATH MCTABLE_READ PATH LD_LIBRARY_PATH # set logging of stdin and stdout to $MCLOG exec 2>$MCLOG 1>&2 #exec 2>$MCLOG 2>&1 #exec 2>/dev/null 1>&2 # cd to $MCDATA and run the script whose name was passed in on the command line cd $MCDATA mcenv << EOF batch.k $1 exit EOF # Done! exit 0 The first entry should, therefore, always fail. Also, I looked at WEATHERWATCH.BAT and see that it basically runs WWDISP which uses by default data from the RTWXTEXT dataset. Your setup is pointing to weather2.admin.niu.edu for RTWXTEXT: <as 'mcidas' on weather.admin> cd $MCDATA dataloc.k LIST RTWXTEXT Group Name Server IP Address -------------------- ---------------------------------------- RTWXTEXT WEATHER2.ADMIN.NIU.EDU <LOCAL-DATA> indicates that data will be accessed from the local data directory. DATALOC -- done I see that the GIF file to be created by WEATHERWATCH.BAT does, in fact, get created (I changed the logging entry in /home/mcidas/kickoff to write to the log file /home/mcidas/workdata/crontab.log; it was writing to /dev/null). So, given your crontab entries, the content of /home/mcidas/kickoff, and the content of /home/mcidas/workdata/WEATHERWATCH.BAT, I am not sure what is failing for you. Question: - which system (weather, weather2 or weather3) is running a cron-initiated script that is failing? re: > That should point to > weather2. I save no GRID data, so that should point to you by default. OK. re: > All text weather info should point to the local machines; I do save things > like watches, warnings, METARS. Again, the setup in the 'mcidas' account on weather.admin is to point at weather2.admin for the weather text dataset, RTWXTEXT. re: > All images though, as appropriate, should > point to weather2 where the datasets aren't sent to the LDM (for example, > SSEC's 30 minute image update files). Which machine is running a cron job that is supposed to access image data? Which BATCH file is supposed to process image data? I think it must be CFDGONLY.BAT (/home/mcidas/workdata/CFDGONLY.BAT). A quick look at the copy of CFDGONLY.BAT on weather and weather2 shows that it will try to access images from the GINIEAST dataset, and presumably, it will try to access this dataset on weather2.admin. When I try to list images from the GINIEAST dataset, I get nothing: <as 'mcidas' on weather2> dataloc.k LIST GINEAST weather2-niu Mci-163$ dataloc.k LIST GINIEAST Group Name Server IP Address -------------------- ---------------------------------------- GINIEAST WEATHER2.ADMIN.NIU.EDU <LOCAL-DATA> indicates that data will be accessed from the local data directory. DATALOC -- done cd $MCDATA weather2-niu Mci-164$ imglist.k GINIEAST/GE1KVIS Image file directory listing for:GINIEAST/GE1KVIS imglist.k: done However, when I try to access the data locally, it works: dataloc.k ADD GINIEAST LOCAL-DATA Group Name Server IP Address -------------------- ---------------------------------------- GINIEAST <LOCAL-DATA> <LOCAL-DATA> indicates that data will be accessed from the local data directory. DATALOC -- done weather2-niu Mci-167$ imglist.k GINIEAST/GE1KVIS Image file directory listing for:GINIEAST/GE1KVIS Pos Satellite/ Date Time Center Band(s) sensor Lat Lon --- ------------- ------------ -------- ---- ---- ------------ 71 G-13 IMG 11 NOV 10315 22:45:19 41 88 1 imglist.k: done So, the BIG question is why remote access to the dataset is failing while local access succeeds while at the same time local and remote access to RTWXTEXT and RTIMAGES works!? I have been looking into this strangeness for the past two hours now, and I still don't have an answer for you. I will keep looking (and scratching my head). Until I can figure out what is going on, you may want to point at a different ADDE server for the GINIEAST data; I suggest adde.ucar.edu. Here is what you should do: <as 'mcidas' on the machine(s) running the script(s) that display GINIEAST data> cd $MCDATA dataloc.k ADD GINIEAST adde.ucar.edu 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: HPW-941884 Department: Support McIDAS Priority: Normal Status: Closed