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.
Tom, Your idea of using pqinsert(1) to change the feedtype is a good one and should work. Use the "-i" option to have the MD5 checksum computed from the product-identifier and ensure that all product-identifiers are unique. This will allow the queue to contain the same data-product but with different feedtypes. > We have been having email exchanges with folks at the WOC about the best > way to include new products into the CONDUIT feed (CONDUIT originates > on machines at the WOC). > > Here is the body of an email that Patrick O'Reilley sent us yesterday > about how they are thinking of adding the products: > > Here's a rough dataflow diagram of the path of these data: > > TOC system socket => WOC system socket => WOC socket LDM => WOC CONDUIT LDM > => Unidata and others > > where the "socket" is a client/server software. > > When the WOC socket software inserts it into the "socket" LDM, there is a > default > feedtype it is assigned. There's not any flexibility to assign different feed > types. So since in the future, there may be products coming from the TOC to > the > WOC that aren't destined for CONDUIT via this path, I guess it's a good idea > to > assign it to EXP, and make that permanent. > > With this in mind, is there an easy or standard way to change the feedtype > between > LDMs? After the test, the products will be coming into the WOC CONDUIT LDM > as EXP > and we need them assigned to the CONDUIT feed type. > > We can think of a couple indirect ways but thought there may be a more > straightforward > method. > > Thanks! > Patrick > > In recap, the issue is that they want to send the new products to the CONDUIT > injection > machines using the LDM EXP feed type, and then have the new products > re-inserted into > the CONDUIT injection machines LDM queues in the CONDUIT feedtype. > > I commented to Patrick that it might be possible to re-insert the same product > into a queue where the original is still resident by assigning an MD5 > signature > to the re-inserted product (assign one, not let pqinsert calculate one). > > Questions: > > - would this circumvent the duplicate product rejection? > > I think that it would, but I wanted to make sure that there were not 'gotchas' > > - if the answer to the first question is yes, it seems to me that the best > thing to do is to assign the artificial MD5 signature to the product in > the EXP feed and let pqinsert calculate the signature when the product > is re-inserted as a CONDUIT product > > Any comments would be most useful... > > 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 > **************************************************************************** Regards, Steve Emmerson Ticket Details =================== Ticket ID: BIW-247121 Department: Support LDM Priority: High Status: Closed