Hey Jame!

The best I can come up with for an 8 digit hex number is to use the the day
of the year for the first three hex digits, which can be obtained outside
the msg creation loop, and then get the next five hex digits inside the
loop by extracting microseconds, which there are a ton of in a 24 hour day.
 I tested it by adding; "use Time::HiRes qw/gettimeofday/;" to a
test MSGID generator.  It gets set with a line such as, "($seconds,
$microseconds) = gettimeofday;" and then the MSGID of each message
created in a loop using "sprintf("%03x%05x", $dayofyear,
$microseconds)".  Works great and is definetly unique for at least a
year, has logic to it, and thus could be easily employable in a database
(sortable by MSGID).  The only way to successfully dupe the MSGID would be
to pass a message(s), a year or multiple years later, on the exact same day
of the year, at exactly the right microsecond.  What are the odds over
three years of that occuring?  If it were up to me I would add two more hex
digits to the left hand side of the part of the MSGID after the space, and
then add the two digit year (0 - 99) and it would be unique for over a
hundred years for the low cost of two bytes to the total msg length.  A
lousy two stinkin' bytes would have made all the difference in the world. 
Sigh.

Anyhow that is as far as I care to go with this.  I think I went beyond the
call of duty seeing as it won't matter one lousy bit in the grand scheme of
things Fido.  But at least I feel it is the best I could come up with for a
useable MSGID.  It makes far more sense then anything else I've seen thus
far.  So unless you can suggest something better I plan to commit it to the
script but will probably use the 10 hex digit locally on the XML-RPC
server.  That way at least local messages shouldn't create dupes that
aren't dupes and a faster scanning procedure seeing messages will be
properly sorted within an archive.  Right?  "Screw the rest!!!",
I say.

Life is good,
Maurice

--- Msged/LNX 6.1.2