JM> Now back to the creation side of things, as long as the MSGID line
 JM> is correctly formatted, contains an address and a unique serial
 JM> number, how can you even think it's non-compliant?

CRC's are not unique... here's one method of coming up with a serial
number... leonard posted it a while back and i've implemented it as it
stands. yes, even with the node number not being the last field as some
have suggested. to alter the implementation at this time would introduce,
even more, the possibility of generating a duplicate MSGID. it has been in
active use for almost the full 2.5 years since the following message was
posted -=B-)

===== snip =====
Area : FIDONet Developers Area (E)
Date : Apr 15 '94, 20:20
From : Leonard Erickson                                       1:105/51.0
To   : Paul Edwards
Subj : Re: EchoMail
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

 -=> Quoting Paul Edwards to Mikael St†ldal <=-

 PE> There is no requirement for there to be a MSGID kludge, and can you
 PE> honestly say that you have NEVER been at risk of violating the MSGID
 PE> standard, ie there was no possibility that you ever generated two
 PE> MSGID's the same within any 3 year period?  I certainly can't.

The identifier part of the MSGID is 8 hex digits. As a worst case,
there are 1096 days in 3 years. (assuming that there's aleap year in
there somewhere). There are 86400 seconds in a day. That gives 94694400
seconds. In HEX that's 5A4EC00. Note that this is *7* digits. The max
number of possible ID's is 100000000h. Doing the division gives 2Dh or
45d IDs for each second. I think we can live with a system that's
limited to tossing messages at 45/second. Or that tosses faster, but
won't let itself be run again until enough time has passed. 3.9
*million* messages per day is more traffic than anybody is likely to
generate!

As a *simple* method of doing this, have the program generate the
Julian Day Number (April 15, AD 1994 is JD#2449457). Then figure modulo
2048 of it. That's 49. Shift it to the right an appropriate number of
bits (multiply by 20 00 00 hex). That gives us 62 00 00 00 hex. And we
have 20 00 00 hex or 2,097,152 decimal message numbers per day. I think
that can be handled easily enough. Just generate a message number
(starting at 0 for the start of the day) and add it to the modified jd.

So we get:
        serial = (JD# mod $800) * $200000 + mnum

That's *not* that hard. And you can even allow for multiple tasks by
just allocated the least significant digit or digits. With 2 digits
allocated for a task number, that gives each task 8k numbers to
allocate per day. I think that's enough. :-)

For up to 16 tasks:
        serial = (JD# mod $800) * $200000 + num *16 +task #

For up to 256 tasks:
        serial = (JD# mod $800) * $200000 + num *256 +task #

.!. Unrecoverable Application Error: (A)bort, (R)etry, (B)uy Desqview ?
-!- Blue Wave/QBBS v2.12 [NR]
 ! Origin: Shadowshack (1:105/51.0)
===== snip =====

i trust that you noted there was no CRC calculations used. i also trust
that you noted that a simple, imcremental number is also used. any
questions? my implementation is a TP v6.0 unit. the source is not available
at this time. the unit provides access to one call from external code...
that call is GetMSGID. it is a function call and returns a simple 8
character string that just happens to be the HEX of the decimal number
generated.

)\/(ark