Re: QtmmSendMail weirdness: as if two jobs were fighting over the same message *STMF

On 10-Jan-2012 17:11 , James Lampert wrote:

We just had a report of a situation that is, as stated in the
subject line, as if two jobs were fighting over the same message
*STMF.

A QMSF job was told to send the file, but it disappeared before it
could do so.

Anybody ever heard of such a thing?

I recalled that Scott K had replied to a similar message, suggesting that in order to meet a requirement of the QtmmSendMail API, a file name should be generated "unique"; e.g. using the temporary STMF name API. So I searched and found the thread. The author of the thread with "Subject: More QtmmSendMail trouble" has been omitted ;-)
http://archive.midrange.com/midrange-l/200803/msg00466.html

Seems that if the alluded requirement is not met, then two requests can attempt to access the same file, possibly referencing since-replaced data, or as described, referencing a file being\been unlinked. That was something I recall having been discussed in other messages, but the closest I found [within results of the former search] was the following message which implies such a race condition is possible using a non-distinct file name, due to how the API and server work:
http://archive.midrange.com/midrange-l/200603/msg00641.html
"using the QtmmSendMail API then it needs to create a MIME-encoded file somewhere in the IFS. When the API returns control, it has not really sent the email, it has queued it for processing and unlinking (don't ask about this in /tmp!) somewhat asynchronously by the MSF subsystem. If the same IFS file name is used each time"... "allow the MSF subsystem to actually send the email and unlink the stream file. Where I have coded using QtmmSendMail, I have attempted to use a unique file name for each MIME-encoded IFS file to take into account the asynchronous implementation of the email processing kicked off by the QtmmSendMail API."

Regards, Chuck