[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030820: McIDAS 2003 LSSERVE Q. (cont.)

>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