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.
Matt, > I definitely see your point. However, is there a chance you'd > consider returning another positive return code to accompany the > "already in queue" message? In some cases, the "already in queue" > situation is an anomaly to be dealt with. > The text message CLEARLY DOES provide the desired information, but > the numeric value would be easier to handle. > I'm sure the code was thought through and wasn't written haphazardly > - and heck, it's been around for 14 years. > > Currently, the pqinsert return codes are: > -1 /* read error */ > 0 /* implied success (no text message needed)*/ > 1 /* operating-system failure */ > 2 /* couldn't open product-queue */ > 3 /* couldn't process input file */ > 6 /* couldn't initialize MD5 processing */ > > Might the following be considered? > 4 /* success, but all supplied files already in queue */ > 5 /* success, but some supplied files already in queue */ Would you really like to differentiate between some files already being in the queue versus *all* files already being in the queue? If not, then would the following suffice: 4 /* At least one of the files was already in the queue */ Because I don't know how people are using the "pqinsert" exit code, I can't make any promise other than I'll investigate the matter. Regards, Steve Emmerson Ticket Details =================== Ticket ID: DMB-963596 Department: Support IDD SCOOP Priority: Normal Status: On Hold