ml>> quite simply, use a serial counter just like many *nix
 ml>> mail programs do ;)

 MK> Sounds interesting.  Can (Does) that be generated by the
 MK> variables already onhand needed for header generation?

hunh? what variables? all i'm saying is to maintain a serial counter
somewhere and increment it each time a MSGID is used...

 MK> I'd much rather it be something already there and needed,
 MK> rather then adding an additional scan and/or input from the
 MK> user.  The bottomline is the user ought not to be concerned
 MK> about the creation of any variable other then the message

there is absolutely no reason the user has to have any involvement in the
MSGID creation... none of mine ever have been and neither have i other than
creating MSGID generation routines... of all of them, the serial counter is
the easiest, simplist and one less dangerous than any other... the only
danger is if the counter storage is lost somehow (ie: deleted) and it is
restarted at zero or whatever... this is about the only place that using
the system clock for the initial seed comes into play...

possibly something like using 4hex digits for as much of the julian day
number and reserve the last four hex digits for the serial counter... store
the entire mass in some storage area (ie: a file) and increment the last
four until they hit FFFF at which time you increase the JD portion by one
or even calculate a new JD for the current day and roll the serial counter
back to 0000...

no matter what is done, however, if the system clock is used for any
portion of the MSGID, there will always be a danger of generating dupe
numbers within the three year period...

 MK> he/she/it wishes to convert, who it is destined for and who
 MK> he/she/it is.  Also there are only eight characters in the
 MK> field after the space which if hex - the normal operating
 MK> procedure from my observations - only allows 32 bits total.  I
 MK> realize there are a number of approaches that could easily
 MK> deal with this but I'd prefer something that is predictable
 MK> and useable from a server's point of view.  Adding a random
 MK> routine is no real value as it increases operations whereas
 MK> using the time/date makes far more sense and with some thought
 MK> as to processing time would be the best.  If there where a few
 MK> more characters allowed in the second part after the space
 MK> that would have been super.  However, I don't think it would
 MK> be a good idea given the software already in use out there in
 MK> the cold, cruel world.

 MK> Of course simply not adding a MSGID is doable given it isn't a
 MK> requirement.  I am seriously thinking that might be the best
 MK> course of action and damn the consequences, full speed ahead!

too much of that already out there and causing some of the problems which
you are aware of...

)\/(ark