From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: RE: Callable Mail and the New Mail Count
Date: 11 Oct 92 12:17:43 GMT
Organization: The Internet


	I have an application which uses the Callable Mail API to send a
	message to users, perhaps as often as every hour or so.  In order to
	prevent the users from having multiple copies of these messages (the
	mail tells them how many unseen notes are waiting for them in VAX
	Notes, based on their NOTES$NOTEBOOK), the program also uses the
	Callable Mail API to determine if there are any messages from earlier
	runs of itself (it uses a special sender address) in the user's
	NEWMAIL folder which are still flagged as unexamined.  If there are,
	it *DELETES* these messages before sending the latest incarnation.

Nifty application!

	Unfortunately, this messes up their new mail count, since apparently
	the API's MAIL$MESSAGE_DELETE() function does *not* decrement the new
	mail count.

I think the explanation is different.  The new mail count is only decremented
if a new mail message is read BY THE OWNER OF THE MAIL FILE.  If you SET FILE
to someone else's mail file (assuming you have appropriate access to it), you
can read stuff from their NEWMAIL folder (and it will, when read, even migrate
into the MAIL folder unless you move it elsewhere) - but their new mail count
will remain unchanged.  If you think about the files involved, the reason
why it has to work like this is obvious:  The new mail count is kept in the
VMSMAIL_PROFILE file, indexed by username.  Access to the mail file, and
ownership of that file, is determined by UIC.  There can be multiple usernames
with the same UIC; given just a mail file, it's impossible to determine with
certainty which username should be used to find the VMSMAIL_PROFILE record
to update.

One common way to get "out of sync" new mail counts is to have multiple
usernames with the same UIC and the same mail file.  (The different usernames
can easily be given distinct mail subdirectories, hence distinct mail files.
But if they are not, they'll all read the same mail file, but maintain
their own new mail counts independently.)

The mail routines keep track of whether your current mail file is the default
mail file for the process's username; only then will it update the new mail
count when a new message is read.  (Note that even here you can fool it by
reading the mail file through an alias directory entry.)

		     If the user comes in on Monday after the application has
	posted and deleted messges for Friday, Saturday, Sunday and Monday
	(leaving only Monday AM's message in the NEWMAIL folder), their new
	mail count includes the earlier, deleted messages.

	Obviously, if I'm using the Callable Mail API, I should be able to
	reset the new mail count.  But if I read it, decrement it and write
	it, I have a good size window where VMS mail might deliver a message
	(the user would then be at -1, rather than +1, from the *real* count).
	Is there some resource I could Enqueue, or some way to tell the
	Callable MAIL API to use exclusive access to the file for the (New
	Mail Count Fix/Delete Outdated Message) operation, that would cause
	any impending delivery to wait its turn?

I doubt it.  The problem is that it's the callable mail routines, not your
code, that has opened a channel to the file.  You'd have to get them to open
it for exclusive access - if YOU open it or lock it in any way, you'll lock
out the callable mail routines!

On the other hand, you shouldn't have to, if you FIRST send the replacement
message.  That way, the new mail count will be "pre-incremented", and you can
always safely subtract one from it.  Should the user happen to enter mail in
the brief interval between your adding the new message and deleting the old
and then decrementing the count, he'll see an "off by one" count, or even two
update messages - but that will be VERY rare, and no big deal even if it does
happen.
							-- Jerry