>From: "Matthew J. Rosier" <address@hidden> >Organization: UNCA >Keywords: 200307202337.h6KNb1lo026615 McIDAS ADDE DATALOC BLIZZARD Hi Matt, re: DSINFO I BLIZZARD doesn't work >I am running/setting up everything as user mcidas, my environmental >variables are at the end of this message. Entering the command DATALOC LIST >BLIZZARD returns what you said it would. Hmm... If DATALOC LIST BLIZZARD returns back the correct stuff: DATALOC LIST BLIZZARD Group Name Server IP Address -------------------- ---------------------------------------- BLIZZARD ADDE.UCAR.EDU <LOCAL-DATA> indicates that data will be accessed from the local data directory . DATALOC -- done but DSINFO IMAGE BLIZZARD doesn't give anything, then we must be dealing with something more esoteric than normal. First, your environment variable settings are correct. My original idea was that the file ~mcidas/workdata/MCTABLE.TXT exists and it has an entry for the BLIZZARD dataset. The bind that 'mcidas' can get into is caused by the way I recommend that MCTABLE_READ and MCTABLE_WRITE are defined. McTABLE_WRITE defines which file DATALOC will modify when setting locations of datasets. MCTABLE_READ defines the list of files that will be read when looking for data files. The fact that MCTABLE_READ first searches a file that is not set in MCTABLE_WRITE was done so that the user 'mcidas', the superuser for the McIDAS package, can setup locations for datasets that will not be used by other users. The file set in MCTABLE_WRITE is purposefully located in ~mcidas/data since it is designed to be used by all folks running McIDAS at a site. 'mcidas' can then setup default DATALOCs for other users so they don't have to. To set locations in MCTABLE.TXT, 'mcidas' has do go in and edit the file by hand. Let's try this from scratch: - delete ~mcidas/workdata/MCTABLE.TXT (if it exists) - delete ~mcidas/data/ADDESITE.TXT - rerun the DATALOC for BLIZZARD: DATALOC ADD BLIZZARD ADDE.UCAR.EDU DATALOC LIST BLIZZARD DSINFO ALL BLIZZARD and let me know what happens. >As far as the LDM at UNCA - it does need to be upgraded, I don't even >remember what version we are running. I am not sure since storm2 is not returning back any stats at the moment. >I actually am fairly new to the LDM, I >set it up on my own PC back in February (5.2.2) (as a Linux newbie as well), >so it was a bit of a challenge, but not too bad. The setup of ingest by an LDM is fairly easy. Setting up the actions to be taken upon receipt of data can be quite complex depending on what one is trying to accomplish. >Also got GEMPAK up and running and now working on McIDAS :-) McIDAS should be much easier than GEMPAK ;-) Seriously though, setting up the data decoding in McIDAS is much easier than in GEMPAK. >Since Leigh is no longer at UNCA, I'm >guessing some of the responsibility of maintaining our lab machines will go >to me, which I don't mind at all. We are always here to help. It is in our own best interest to help a site get setup correctly since it cuts down on the mundane questions that invariably come in because of some small misunderstanding about how things work/should work. >However, if you are willing to do the LDM >upgrade for us and some of the tuning (which it certainly needs in order to >be brought "up to date") it would definitely help me and the department! Yes, I am willing to do the installation and ldmd.conf tuning. This takes only a few minutes once appropriate logins are available. Leigh had given me a login to storm2 at one point, but I forgot what the passwords were. I just tried to get on and storm2 doesn't seem to be accessible: % ssh storm2.atmos.unca.edu -l yoksas ssh: storm2.atmos.unca.edu: no address associated with hostname. >Of >course, I don't have the password for ldm or root either. I am surprised >Alex didn't respond to you, he is usually pretty quick about that stuff. It could be that the message got lost or was bounced as spam. I sent it out as part of a list of folks I was trying to get upgraded to LDM-6. >I'll e-mail him and see if I can get the password info from him, but >sometimes he is weird about that sort of stuff, but someone needs the info >if anything is ever going to get updated! Please let Alex know that I will be the one doing the work. He and I go way back. >Thanks again Tom, I appreciate your help. No worries. >SHELL=/bin/csh >GROUP=ldm >HOSTTYPE=i386-linux >PATH=/home/mcidas/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/X11R6/bin >USERNAME=mcidas >HOME=/home/mcidas >MCHOME=/home/mcidas >McINST_ROOT=/home/mcidas >MCDATA=/home/mcidas/workdata >MCPATH=/home/mcidas/workdata:/home/mcidas/data:/home/mcidas/help >MCTABLE_READ=/home/mcidas/workdata/MCTABLE.TXT;/home/mcidas/data/ADDESITE.TXT >MCTABLE_WRITE=/home/mcidas/data/ADDESITE.TXT >XCD_disp_file=/home/mcidas/workdata/DECOSTAT.DAT >MCGUI=/home/mcidas/bin >MCCOMPRESS=TRUE Cheers, Tom
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.