Subj : txt2pkt.pl To : Maurice Kinal From : mark lewis Date : Wed Feb 09 2005 01:00 pm 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 * Origin: (1:3634/12) .