[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030820: McIDAS 2003 LSSERVE Q. (cont.)
- Subject: 20030820: McIDAS 2003 LSSERVE Q. (cont.)
- Date: Wed, 20 Aug 2003 17:36:16 -0600
>From: "Thomas L. Mote" <address@hidden>
>Organization: UGa
>Keywords: 200308071535.h77FZeLd002958 McIDAS DSSERVE.BAT LSSERVE.BAT
Hi Tom,
>Sorry I didn't respond. We had a virus hit our computer lab (on the
>Windows partition... the systems dual-boot) during this first week of
>classes. What a headache!
We had the same thing happen here at UCAR. Luckily, the system admins
around here jumped on things quickly enough to limit damage.
>Plus, we're trying to get the changes made on the NOAAport system to
>conform with the GOES West channel departure.
I understand completely.
>We also saw our
>university block numerous ports due to the recent bout of viruses. I
>don't know if the McIDAS ports are open for ADDE access outside UGA.
They appear to be.
>Perhaps you can tell me; I can't get a straight answer from our
>(overwhelmed) networking ops people.
I tried two different tests:
- point at cacimbo from a McIDAS session here at the UPC
- logon to cacimbo as 'mcidas' and try a DSINFO IMAGE GINIEAST
(the 'mcidas' account on cacimbo is setup to go through the
remote ADDE server interface for all datasets hosted on
cacimbo)
The first test works fine for me:
DATALOC ADD GINIEAST CACIMBO.GGY.UGA.EDU
Group Name Server IP Address
-------------------- ----------------------------------------
GINIEAST CACIMBO.GGY.UGA.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
DSINFO I GINIEAST
Dataset Names of Type: IMAGE in Group: GINIEAST
Name NumPos Content
------------ ------ --------------------------------------
GE1KVIS 9999 GINI 1 km VIS East CONUS
GE4K12 9999 GINI 4 km 12.0 um East CONUS
GE4K39 9999 GINI 4 km 3.9 um East CONUS
...
but the second one, from cacimbo to cacimbo doesn't...
OK, I see what happened. The ADDE "pointing" (DATALOC) creates entries
in the file ~mcidas/data/ADDESITE.TXT. If one specifies the
DATALOCation by host name like:
DATALOC ADD GINIEAST CACIMBO.GGY.UGA.EDU
McIDAS stores the host name AND the IP address for the host in
~mcidas/data/ADDESITE.TXT. If the IP address for the host changes,
then the IP information stored in ~mcidas/data/ADDESITE.TXT will
be wrong. This can be corrected by running:
DATALOC HOST
or by running a DATALOC for any dataset to be found on the host:
DATALOC ADD GINIEAST CACIMBO.GGY.UGA.EDU
When either of these DATALOC commands are run, a gethostbyip id done
to lookup the IP address from the name and the result is restored
in ~mcidas/data/ADDESITE.TXT.
>I would be happy to let you look. I'm not sure we have the sat data
>configured correctly or not, but you can look. Our departmental techs
>are working on the getting the client systems back up now, so I have no
>remote system to try the ADDE access.
As I said above, I logged on and started poking around. What I see
tells me that by-and-large things are setup correctly, and since
fixing the IP address for cacimbo in ~mcidas/workdata/ADDESITE.TXT,
the access to datasets is working.
I do have questions about a couple of things:
- right now, you have a dataset named RTNIDS setup that points at
the NEXRAD Level III images that comprise the RTNEXRAD dataset:
/data/nexrad/NIDS/<station ID>/<product type>
Since the setup of the dataset uses the descriptors as "replaceables":
DIRMASK=/data/nexrad/NIDS/\ID/\TYPE/
FILEMASK=/\TYPE_*
and since the product types do not match the dataset descriptors:
RTNIDS/BREF1 ID=FTG != DIRMASK=/data/nexrad/NIDS/FTG/N0R/...
I suggest deleting the RTNIDS dataset definitions. This will
tidy things up a bit and should reduce confusion in the future.
In fact, I just deleted this definition (it can be restored
if necessary).
- the configuration file specfied for use with the RTNEXRAD dataset is
NNEXRAD.CFG (this definition is in ~mcidas/workdata/RESOLV.SRV).
Since this is the name of the default configuration file included in
the McIDAS distributions, I recommend changing it to UGANEXR.CFG.
This appears to be the way things were setup previously since the
file ~mcidas/workdata/UGANEXR.CFG exists and contains the same
definitions listed in NNEXRAD.CFG. I made the change in RESOLV.SRV
and LSSERVE.BAT before getting your go ahead since it was easy to do
and won't break anything.
- you have a RTGINI dataset defined, but it only includes GOES-East
images. I figure that htis is a holdover from when you only were
getting images from GOES-East from your NOAAPORT box. I recommend
removing the RTINI dataset definitions from ~mcidas/workdata/RESOLV.SRV
since all the data is accessbile from the datasets GINICOMP, GINIEAST,
and GINIWEST.
>One other problem I have seen is that some files (like GRID6*) are
>being dumped to my ~mcidas/workdata directory instead of my designated
>data directory (/data/mcidasd). I did a redirect.k LIST and the GRID6*
>entry wasn't there, so I checked my ~mcidas/data/LOCAL.NAM file (has
>the entry) and did a redirect.k REST LOCAL.NAM. A redirect.k LIST
>shows the entry still isn't there. Obviously, there is another step I'm
>missing.
What needed to be added was:
REDIRECT ADD GRID6 "/data/mcidasd
REDIRECT ADD MDXX010* "/data/mcidasd
REDIRECT ADD MDXX0110 "/data/mcidasd
REDIRECT ADD MDXX011* "/data/mcidasd
REDIRECT ADD MDXX0120 "/data/mcidasd
REDIRECT ADD ETAMOS.RA* "/data/mcidasd
REDIRECT ADD GFSMOS.RA* "/data/mcidasd
I ran these REDIRECT commands to setup the REDIRECTions, but the
LDM will need to be stopped and restarted to make sure that the
new definitions are used in creating new files.
As a review, I did the following:
1) fixed the name/IP problem in ~mcidas/data/ADDESITE.TXT
2) updated the dataset definitions in RESOLV.SRV (the file that is
actually used by the ADDE server) and LSSERVE.BAT
3) created a local GINI ADDE configuration BATCH file, UGAGINI.BAT
(in ~mcidas/workdata)
4) tidied up the locations of files in the NEXRCOMP dataset (not
mentioned above)
>If you'd like me to send you a password, I can.
I have it from before, but I don't have a correct password for 'ldm'.
On the LDM side:
- I see that the pattern in ~ldm/etc/pqact.conf for procesing 1 km floater
NEXRAD composites is incorrect. Here is what you have now:
#
# NEXRCOMP 1 km Regional BREF mosaic
FNEXRAD ^pnga2area Q5 (RM) (.*) (.*) (.*) (.*) (........) (....)
PIPE -close
decoders/bin/pnga2area
/data/nexrad/NEXRCOMP/1km/\4/\4_\6_\7
-l logs/ldm-mcidas.log
This should be:
#
# NEXRCOMP 1 km Regional BREF mosaic
FNEXRAD ^pnga2area Q5 (RO) (.*) (.*) (.*) (.*) (........) (....)
PIPE -close
decoders/bin/pnga2area
-l logs/ldm-mcidas.log
/data/nexrad/NEXRCOMP/1km/\4/\4_\6_\7
The differences are 'RO' instead of 'RM', and put the '-l logs/ldm-mcidas.log'
flag before the file name specification
- in all FNEXRAD pnga2area actions, you have the specification of the
log file after the specification of the output data file:
#
# NEXRCOMP 6 km National BREF mosaic
FNEXRAD ^pnga2area Q5 (RL) (.*) (.*) (.*) (.*) (........) (....)
PIPE -close
decoders/bin/pnga2area
/data/nexrad/NEXRCOMP/6km/\4/\4_\6_\7
-l logs/ldm-mcidas.log
The log file specification should come before the file name specification:
#
# NEXRCOMP 6 km National BREF mosaic
FNEXRAD ^pnga2area Q5 (RL) (.*) (.*) (.*) (.*) (........) (....)
PIPE -close
decoders/bin/pnga2area
-l logs/ldm-mcidas.log
/data/nexrad/NEXRCOMP/6km/\4/\4_\6_\7
I would have made these changes for you, but the login I have for 'ldm'
doesn't work. I will be more than happy to tune up your pqact.conf file
if you give me the 'ldm' password. Send it to my personal email address,
address@hidden, with no mention of the machine or account name
to which it applies.
>I appreciate your help.
No worries.
The problems just seem to be multiplying this week!
I _know_ what you mean!
Tom