Hey Jame!

What do you think about the following idea for MSGID generation?

If the function approaches the last 8 characters in the field as a bit
field then it has 32 bits to pllay with.  If the last 6 bits (little endian
style) are reserved for "seconds" - only the first message would
actually be seconds the rest incremented by one from that base - 6 bits
reserved for minutes, 6 bits for hours, 9 bits for day of the year, that
leaves 6 bits for the year which yeilds 64 unique states.  That is far more
then needed to assure the three year uniqueness "standard" of the
currently accepted length for that part of the MSGID and makes this a far
more usable dupe scanning variable.

Another approach could be to reserve the first 3 bits for "year"
(a base year) and follow the the rest above which could leave a remainder
of 3 bits for a message number within any generated pkt but then that
restricts pkt sizes to 8 messages per pkt.  I think I prefer the above
strategy out of these two options.

The beauty of either of these methods is that there is no need to change
the currently accepted implementation of MSGID and at least this function
would yeild a better accountable database that could be later employed for
dupe checking.

Personally I'd like an extra few bytes but that will freak out too many
programs that are in use out there.

Life is good,
Maurice

--- Msged/LNX 6.1.2