[IDD #RGQ-935055]: Fwd: CONDUIT data from idd.unidata.ucar.edu

Hi Tom,

re:
> Tom....do we need to officially request CONDUIT connection and data
> from you to start getting that data?

No, not really.  We already have an ALLOW that will allow you to request
CONDUIT from idd.unidata.ucar.edu.

re:
> Tom <Priddy>,
> I changed ldmd.conf and pqact.conf, recreated ldm.pq and restarted ldm,
> but no data come in.
> I checked the connection is Ok.
> 
> [ldm@weather3 ~]$ ldmping idd.unidata.ucar.edu
> Nov 14 16:13:26 INFO:      State    Elapsed Port Remote_Host rpc_stat
> Nov 14 16:13:26 INFO: Resolving idd.unidata.ucar.edu to 128.117.140.3 took 
> 0.056041 seconds
> Nov 14 16:13:26 INFO: RESPONDING   0.503619  388 idd.unidata.ucar.edu
> Nov 14 16:13:52 INFO: RESPONDING   0.053589  388 idd.unidata.ucar.edu

When checking to see if an upstream is setup to ALLOW you to REQUEST
data via the LDM/IDD, I always recommend using 'notifyme' instead of
or in addition to 'ldmping'.  For instance:

<as 'ldm' on weather3>
notifyme -vl- -f CONDUIT -h idd.unidata.ucar.edu

re:
> ldmd.conf
> REQUEST CONDUIT "gfs\.t00z.pgrbf.*" idd.unidata.ucar.edu PRIMARY

This looks OK, but did you/Wanhong check to make sure that the extended
regular expression used will match anything?  This is easily done using
'notifyme':

notifyme -vl- -f CONDUIT -h idd.unidata.ucar.edu -p "gfs\.t00z.pgrbf.*" -o 3600

Since the trailing '.*' adds nothing to the extended regular expression
pattern, the following is better:

notifyme -vl- -f CONDUIT -h idd.unidata.ucar.edu -p "gfs\.t00z.pgrbf" -o 3600

I am running this as a test, don't see any listing from 'notifyme'.
This could be due to the pattern not matching anything, or it could
be due to there being no products that do match the pattern in the past
hour.  Another possibility is that the pattern matches, and there are
products that should match, but the clock on weather3 not correct so
that the request is for data in the future or in the past before the
earliest time in the queue of the LDM you are requesting from.

re:
> pqact.conf
> #GFS GRIB2 FILES (00Z)
> CONDUIT gfs.t(..)z.pgrbf([0-9]+).grib2
> FILE    data/grib/gfs/\1/gfs.t\1z.pgrbf\2.grib2
> #GFS GEMPAK FILE (00Z
> CONDUIT gfs.t(..)z.pgrbf([0-9]+).grib2
> PIPE    decoders/dcgrib2 -d data/gempak/logs/dcgrib2_CONDUITgfs.log
> -e GEMTBL=/export/home/gempak/NAWIPS-5.6/gempak/tables
> data/grid/gfs/\1/gfs.t\1z.pgrbf\2.gem

Are your pattern-action file actions correctly formatted?  Remember
that certain whitespace must be tabs, not spaces (e.g., between
CONDUIT and gfs, before FILE and PIPE, between FILE or PIPE and
the next argument in their respective lines, etc.).

My advice is to:

1) use 'notifyme' to verify that the upstream LDM has the products
   you want

2) fashion a pattern that you believe will match the products you
   want

3) test that pattern again using 'notifyme'

4) use that pattern in a pattern-action file action

5) test your incorporation of that pattern in your pattern-action
   file using 'ldmadmin':

ldmadmin pqactcheck

6) if the new/revised action does not cause any errors, send a HUP
   signal to the lead LDM process and it will tell your 'pqact'
   invocation(s) to re-read pattern action files:

ldmadmin pqactHUP

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: RGQ-935055
Department: Support IDD
Priority: Normal
Status: Closed