[LDM #GOE-694008]: Request for temporary IDD for NWA Demo

Hi Brad,

re:
> Can anyone shed some light on the readnoaaport log format entries.  For
> example, below the same product normally comes in with "cat 1" however on
> the 1514 issuance it came in with "cat 101" and the downstream LDM did not
> request the product from the queue and thus did not store it.

I am a bit suspicious about the comment "the downstream LDM did not
request the product from the queue and thus did not store it".  The LDM
REQUEST lines use regular expressions that match on the LDM/IDD Product
IDs.  If the REQUEST pattern used by the downstream matched the first
product, it should have also matched the second product since, as far
as I can tell from the listing you sent, the Product IDs are identical.

Questions:

- is your view that the downstream LDM did not request the product
  from the upstream based on not seeing the product processed on the
  downstream?

- did you use the LDM utility 'pqcat' to list products in the LDM
  queue on the receiving machine and prove that the product was not
  received (NB: this would have to have been done before the product
  got automatically scoured out of the LDM queue)?

re:
> Wasn't sure
> (1) what the cat field is, (2) how it is determined, and (3) what might
> cause the difference between the two be it an error in the product etc...

The 'cat'egory field is taken from the WMO ID of the product (for non-GRIB
products) or from a table for GRIB products.  It seems that two different
products had the same WMO ID (FXUS10s are not GRIB messages are they?), and
so 'readnoaaport' created the same LDM/IDD Product ID.  Since the product
sizes are different (and so, their MD5 signatures would be different) and
the times between LDM product queue insertion is large (so, presumably, the
old product would no longer be in the downstream LDM's product queue), the
product should have been sent to the requesting LDM.  Whether or not it is
seen in the downstream's file system depends on what the action was that did
the processing (for instance, the product created by the receipt of the new
product could have overwritten the one created by the previous on, etc.).

re:
> CORRECT FORMAT:
> 
> Jan 20 05:28:10 cpsbn1-hpcn readnoaaport[29052] NOTE: FXUS10 KWNH 200528
> /pPMDHMD inserted [*cat 1* type 4 ccb 2/0 seq 68910095 size 4791]
> 
> INCORRECT FORMAT (only happened once thus far):
> 
> Jan 20 15:14:50 cpsbn1-hpcn readnoaaport[29052] NOTE: FXUS10 KWNH 201514
> /pPMDHMD inserted [*cat 101* type 4 ccb 2/0 seq 69705248 size 2236]

Please let me know if the above does not make sense.

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