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
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.