RT>> A MSGID is a valued item here, especially when it comes to dupe
 RT>> checking, so
 RT>> if you are able to generate them fast enough, then please do so.

 MK> Generating them fast isn't a big issue but making them
 MK> meaningful is a tad tricky given the accepted "standard", if I
 MK> can be so bold as to call it a "standard".

they aren't supposed to be meaningful... they're just a serial number
assigned to a message, for diety's sake...

 MK> If based on time and/or date (is there a difference?) then it
 MK> slows things down and given the current limitation makes it
 MK> even trickier and slower.  That is why I thought a base ID at
 MK> the start and incrementation within a loop for multiple
 MK> messages might be a better objective as it wouldn't add any
 MK> extra calls and is faster then calling localtime for each one,
 MK> which will produce dupes that aren't dupes if limited to
 MK> seconds on a fast machine.  This way it won't matter even if
 MK> the machine is slow enough to produce unique IDs using
 MK> seconds.  This method does speed things up and should produce
 MK> unique IDs for whatever length of years as bits allocated to
 MK> the "year" employed.

you're still looking too deeply... why go thru all that when you can seed a
counter at 0 (zero) and increment until it hits 2147483647 and then roll it
and start over at 0 (zero) again...

based on 365 days in a year, three years is 1095 days... dividing, that
gives us 1961172 messages per day...

surely that's enough and the method easy enough???

the "problem" is storing the serial counter...

another "problem" is that even with non-duped MSGID serial
numbers, it is possible for some software to see a false-dupe... they do
this because they aren't always looking at the MSGID but only at the header
of the message... some of them will go a tad further by looking at the
header plus some (maybe 30 or 40) additional bytes to try to see if the
message body is different... for this reason, i place the MSGID immediately
after the end of the message header and all other control lines then follow
that...

for some reason, i'm also thinking that the message headers that contain
seconds are stuck with a 2 second granularity in the same vein that billy's
file systems have been from the beginning... however, i've not the time nor
inclination to go rooting thru the archives to confirm this
"memory"...

)\/(ark