ml>> any questions?

 FE> Out of curiosity: how do you handle adjustments of the system
 FE> time ? Or do you just ignore this problem ?

at this time, i am looking at how the MSGID serial number in my current
implementation will be affected during daylight savings time adjustments on
local time since it is based on the local clock... i do have something in
the works that uses the TZ environment variable and two new environment
variables, DSTstart & DSTstop, that i've "created", to
determine when daylight savings starts and stops. with this, i can now
calculate UTC time at any time without having to require human intervention
when DST switches over... my DSTstart/stop EVs are based on the Novell
settings on Novell v4.xx servers...

ie:
 If the DSTStart environment string isn't present or is invalid, the
 USA Daylight Savings Time START setting is presumed.

 If the DSTStop environment string isn't present or is invalid, the
 USA Daylight Savings Time STOP setting is presumed.

 The format of the DSTStart and DSTStop environment variables is as
 follows... NO substitutions or conversions are allowed...

 '  in  at :'

  = first | second | third | fourth | fifth | last | next to last
  = Sunday | Monday | Tuesday | Thursday | Friday | Saturday
  = January | February | March | April | May | June |
               July | August | September | October | November | December
  = 24hour format = 0..23
  = 1..59

 Daylight Savings Time :
   USA þ starts FIRST Sunday in April at 02:00
       þ stops LAST Sunday in October at 02:00

  SET DSTstart=first sunday in april at 2:00
  SET DSTstop=last sunday in october at 2:00


i'd like additional DST start and stop times that i can include and test
for this library implementation...

with the above, i can now automatically set/adjust my clock, TZUTC and
other settings when needed ==WITHOUT== human intervention...

now tying the above in with your question above, if i determine that my
serial numbers are adversely affected by the DST time fluctuations, i can
always convert quite simply to using UTC time for that part of the serial
number calculations...

 FE> And how do you coordinate different tools with different / unknown
 FE> algorithms of MsgId generation ?

in my case, all my self-written tools use the same libraries. WRT MSGID
generation, my tools have no conflict or problems that i'm aware of...
MSGIDs generated by other packages i have no control over. i suppose that a
special MSGID package could be written and exectuted before scanning
outbound mail out of the bases that would ensure that all messages leaving
the system use it's MSGID instead of the one calculated by another program.
this would "ensure" that differing packages on the same system
will not cause a dupe MSGID problem. the only thing i can see that is
questionable is...

  1. altering the mail from it's "originally generated" format.
  2. altering a users messages.

#2 is important because there are offline readers and doors that are
(attempting) to do the MSGID thing. =MANY= of them are not generating the
REPLY line though :-(  ... anyway, if the user is keeping up with his
MSGIDs (for whatever reason he has) and they are being altered on the board
before being sent, then he may have a complaint...

as far as the network is concerned, i do not see this as a problem as the
network is not concerned with local issues... only with the mail once it
hits the transport...

 FE> My vague idea for this problem is, to extend the "address" part
 FE> of the MsgId by some product id. (?)

hummm... like the FTSCPROD codes? more numbers to assign and keep up
with... are they to be 16, 32, 64 or 128 bit ids??

 FE> How do you assign task numbers ? getpid() modulo 4096 is obviously
 FE> no good solution... ;-)

quite simply... SET TASK=1, SET TASK=2, etc...

i FORCE my tasks to have specific id numbers... these task ids are NOT
related to any ids the OS may generate to keep up with processing and
multitasking. i assign them specifically.

)\/(ark