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.
Hi Harry, > To: address@hidden > From: Harry Edmon <address@hidden> > Subject: ldm 6.1 - change in behavior > Organization: University of Washington > Keywords: 200409282351.i8SNpxHP002118 LDM 6.1 The above message contained the following: > I start my rpc.ldmd processes with a "-m 10800". In the past if I > started the ldm with a new queue file it would get data 3 hours old. I > just tried this with the new ldm, it seems to have done it for some of > the feeds, but not all. Is this a bug? The first 100 lines of my > ldmd.log are attached. You've been relying on undocumented (or, at least, badly documented) behavior. The "-m max_latency" option specifies the maximum latency that a downstream LDM 5 will accept before responding with a RECLASS reply. It also specifies how far back to request data-products unless overridden by the "-o toffset" option (which must be less than "max_latency"). The value used for this "backlog" request will be adjusted, however, by the creation-time of the most recent data-product in the product-queue that matches the selection criteria -- but only if the creation-time is more recent than the current time minus max_latency. If the "-o toffset" option is used, then the backlog time isn't adjusted by anything in the product-queue. I know, this is horribly convoluted. I tried to keep the original logic. If you absolutely, positively must get data-products from 3 hours ago -- even if they're already in the product-queue -- then use the following: rpc.ldmd -m 10801 -o 10800 ... Regards, Steve Emmerson