[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030722: McIDAS - Redhat Linux 8.0 - simple dataloc question (cont.)
- Subject: 20030722: McIDAS - Redhat Linux 8.0 - simple dataloc question (cont.)
- Date: Wed, 23 Jul 2003 08:13:30 -0600
>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