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

[IDD #DSM-778794]: LAMP product feed change

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [IDD #DSM-778794]: LAMP product feed change
  • Date: Tue, 14 Aug 2012 14:01:32 -0600
Hi Jim,

re: LAMP products

> Well, these products appear to be back in their 'proper' feeds,
> ascii LAMP in DDPLUS and BUFR LAMP in HDS.

That was my observation also.

re:
> I looked again at an ascii LAMP product that came through the NGRID
> feed on the 19th of July and do not see any other binary characters
> other than RS which it always had and still does.

There must have been something that tickled the logic in our
NOAAPort ingest code into believing that the product was, in
fact, binary and so should be sent out in the NGRID feed.

re:
> I did not save any 'evidence' of it being in the NGRID feed (like
> output from pqcat) but both products were definitely in it, at
> least for some time. I had to request NGRID from some downstream
> hosts to get the products again.

I have no difficulty in believing that the ASCII LAMP products
were classified in the NGRID feed.  The question is exactly what
control character sequence caused the mis-classification!?

re:
> So I am out of theories, but I have a question. The feed type is
> determined at the entry point, but where is the entry point?

Entry point?  The determination of what feed a product is put
into is determined at the reception point -- the machine that
is ingesting the NOAAPort SBN feed.

re:
> Do we always get products from our local NOAAPort dish or could
> they have come from somewhere else in the IDD?

They could have come from elsewhere in the IDD.  The reason is that
there are at least 8 different sites running our NOAAPort ingest
code and feeding into the IDD.  This is the reason that I commented
in one of our first exchanges that the cause of the classification
change had to be in the products themselves since all sites running
our NOAAPort ingest code would have had to update their installations
near/at the same time AND there has been no new update to that code
for some time now.

re:
> thanks,

No worries.  If you see this flip-flop again, please grab a few of
the products sent in NGRID so we can examine them in detail.

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