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.
Erik, The "-overwrite" option wasn't specified, so incoming data-products were appended to the output file. Apparently, products with WMO sequence number 330 and 331 were received in different order by the two LDM-s -- resulting in the output files being different. If there's more than one path from the source to the destination, then the order of data-products can't be guaranteed. > This is the 2nd example that I find way more frequently. This is > probably related to the queue size, but I just want to confirm. > > In this and other files, the verify1 version of the file always has a > little extra bit of data that prevents it from matching exactly with > the version that verify2 produces. > > These files are created with the following pqact.conf entry: > > WMO > ^(FT)(US|AK|GM|PU|CA|HW|PA|PQ)(3|4)..(TJ|PA|PG|PH|PK|PM|PW|KA|KB|KC|KD|KE|KF|KG|KH|KI|KJ|KK|KL|KM|KN|KO|KP|KQ|KR|KS|KT|KU|KV|KX|KY|KZ)(.*) > FILE -strip /u1/data/%m%d/TAF.%m%d%y > > These pqact entries seem to work differently - they record all matches > throughout the day into a single file. So somewhere along the line, > verify1 is catching slightly more than verify2. Regards, Steve Emmerson Ticket Details =================== Ticket ID: WSH-264242 Department: Support LDM Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.