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

[Support #RNB-718741]: Re: LDM 6.6.5 now available



Marc,

> I've run into a problem when trying to use the /p feature.
> 
> We have a local archive setup at AWC.  We use a separate pqact.conf to
> file our products in the archive.  We issue AIRMETs four times a day
> with the following WMO headers and possible PIL Ids:
> 
> WAUS41 KKCI WA[0-9][STZ]
> WAUS42 KKCI WA[0-9][STZ]
> WAUS43 KKCI WA[0-9][STZ]
> WAUS44 KKCI WA[0-9][STZ]
> WAUS45 KKCI WA[0-9][STZ]
> WAUS46 KKCI WA[0-9][STZ]
> 
> Every time there is an issuance, we essentially have 18 'separate'
> products. There are sometimes amendments to the AIRMETs, as well.
> 
> My pqact entries look something like this (for space, I just put in one
> of the AIRMETs, KBOS):
> 
> WMO   ^(WA)(US)(41) (KKCI) ([0-3][0-9])([0-2][0-9])([0-5][0-9]) ([A-Z]{0,3}) 
> */pWA[0-9](S)
> FILE  -close  
> /data/archive/(\5:yyyy)(\5:mm)\5/AIRMET/KBOS/sierra/ascii/\6/\1\2\3_\4_(\5:yyyy)(\5:mm)\5_\6\7_\8_\9_%s.txt
> WMO   ^(WA)(US)(41) (KKCI) ([0-3][0-9])([0-2][0-9])([0-5][0-9]) ([A-Z]{0,3}) 
> */pWA[0-9](T)
> FILE  -close  
> /data/archive/(\5:yyyy)(\5:mm)\5/AIRMET/KBOS/tango/ascii/\6/\1\2\3_\4_(\5:yyyy)(\5:mm)\5_\6\7_\8_\9_%s.txt
> WMO   ^(WA)(US)(41) (KKCI) ([0-3][0-9])([0-2][0-9])([0-5][0-9]) ([A-Z]{0,3}) 
> */pWA[0-9](Z)
> FILE  -close  
> /data/archive/(\5:yyyy)(\5:mm)\5/AIRMET/KBOS/zulu/ascii/\6/\1\2\3_\4_(\5:yyyy)(\5:mm)\5_\6\7_\8_\9_%s.txt

ASIDE: You should change the standalone "\5" backreference in your regular
expressions to "(\5:dd)" because, beginning with version 6.6.5, the resulting
string will be different for, for example, a product that has "31" in the
day-of-month field in the product-identifier and that arrives on June 30th.
The date of such products is ambiguous.  Prior to 6.6.5, the assumption was
that the product was for the previous month; with 6.6.5, the assumption is
that human error occurred and the product is for July 1st.

> The ([A-Z]{0,3}) expression is for possible amendments (most of the time, the 
> products aren't amendments) and */pWA[0-9](S) is for the PIL.
> 
> As you can see, we use the (S), (T), and (Z) to distinguish our files for the 
> archive.
> 
> The problem we are having is that we are not archiving all of these products 
> when we receive them.  I've tried to modify the regular expression, but we 
> still get the same problem.  This is completely random in nature - it is not 
> always the same product that we 'miss.'
> 
> For example, during our 1445 UTC product issuance this morning, we did not 
> archive WAUS43 KKCI 281445 WA3S and WAUS43 KKCI 281445 WA3Z.

The product-identifier examples of the products you missed don't have the string
"/p".  I assume the actual product-identifiers contain the string and that you
simply left them out of your email for brevity's sake.

> One thing I found curious, though, is that when I run a 'notifyme' command, 
> you'll notice that the first two entries don't show the PIL Id - and those 
> are the two that I didn't archive:
> 
> Jun 28 14:54:48 notifyme[2467] NOTE: Starting Up: localhost: 
> 20070628135448.716 TS_ENDT {{WMO,  "WAUS"}}
> Jun 28 14:54:48 notifyme[2467] NOTE: LDM-5 desired product-class: 
> 20070628135448.716 TS_ENDT {{WMO,  "WAUS"}}
> Jun 28 14:54:48 notifyme[2467] INFO: Resolving localhost to 127.0.0.1 took 
> 0.000466 seconds
> Jun 28 14:54:48 notifyme[2467] NOTE: NOTIFYME(localhost): OK
> *Jun 28 14:54:49 notifyme[2467] INFO:      535 20070628143040.133     WMO 
> 7267  WAUS43 KKCI 281445
> Jun 28 14:54:49 notifyme[2467] INFO:      265 20070628143046.182     WMO 7279 
>  WAUS43 KKCI 281445*
> Jun 28 14:54:49 notifyme[2467] INFO:      744 20070628143057.444     WMO 056  
> WAUS44 KKCI 281445 /pWA4S
> Jun 28 14:54:49 notifyme[2467] INFO:      162 20070628143057.444     WMO 054  
> WAUS44 KKCI 281445 /pWA4T
> Jun 28 14:54:49 notifyme[2467] INFO:      216 20070628143057.445     WMO 055  
> WAUS44 KKCI 281445 /pWA4Z
> Jun 28 14:54:49 notifyme[2467] INFO:      310 20070628143057.446     WMO 057  
> WAUS43 KKCI 281445 /pWA3T
> Jun 28 14:54:50 notifyme[2467] INFO:      162 20070628143758.574     WMO 608  
> WAUS45 KKCI 281445 /pWA5T
> Jun 28 14:54:50 notifyme[2467] INFO:      357 20070628143758.579     WMO 609  
> WAUS45 KKCI 281445 /pWA5S
> Jun 28 14:54:50 notifyme[2467] INFO:      305 20070628143804.580     WMO 642  
> WAUS45 KKCI 281445 /pWA5Z
> Jun 28 14:54:50 notifyme[2467] INFO:      465 20070628143806.583     WMO 679  
> WAUS46 KKCI 281445 /pWA6Z
> Jun 28 14:54:50 notifyme[2467] INFO:      162 20070628143808.591     WMO 680  
> WAUS46 KKCI 281445 /pWA6T
> Jun 28 14:54:50 notifyme[2467] INFO:      555 20070628143808.594     WMO 681  
> WAUS46 KKCI 281445 /pWA6S
> Jun 28 14:54:50 notifyme[2467] INFO:      885 20070628143914.680     WMO 303  
> WAUS41 KKCI 281445 /pWA1S
> Jun 28 14:54:50 notifyme[2467] INFO:      162 20070628143914.683     WMO 304  
> WAUS41 KKCI 281445 /pWA1T
> Jun 28 14:54:50 notifyme[2467] INFO:      162 20070628143924.702     WMO 378  
> WAUS42 KKCI 281445 /pWA2T
> Jun 28 14:54:50 notifyme[2467] INFO:      161 20070628143924.702     WMO 379  
> WAUS42 KKCI 281445 /pWA2S
> Jun 28 14:54:50 notifyme[2467] INFO:      266 20070628143924.702     WMO 387  
> WAUS41 KKCI 281445 /pWA1Z
> Jun 28 14:54:50 notifyme[2467] INFO:      216 20070628143928.714     WMO 424  
> WAUS42 KKCI 281445 /pWA2Z
> 
> Finally....My question is, why is this happening, and is there anything
> I can do to fix it?  Is there anything to the output of the notifyme
> command?

The reason the products weren't processed is likely because their 
product-identifiers
didn't contain the PIL.  This is consistent with the output from "notifyme", the
"pqact" entries, and the fact that they weren't filed.  

How were the products created?  Can you verify that their product-identifiers
did or did not contain the PIL?

> This only happens for the AIRMET entries that include the /p.  For all
> other AIRMET entries (in other pqact.conf's), everything works.
> 
> Thanks,
> 
> Marc

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: RNB-718741
Department: Support LDM
Priority: Normal
Status: Closed