[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Support #RNB-718741]: Re: LDM 6.6.5 now available
- Subject: [Support #RNB-718741]: Re: LDM 6.6.5 now available
- Date: Thu, 28 Jun 2007 10:04:43 -0600
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