MSGID: 2:280/464.113 5c9fc367   
   REPLY: 1:3634/12.73 5c9fbf47   
   Hey mark!   
      
    ml> to avoid separate programs generating the same serial number...   
      
   That can be dealt with by assigning points to the different programs.  Using   
   the offline messaging example, if the converter from user to BBS has it's own   
   point address and increments from it's start up time, then there will never be   
   any duplication of MSGIDs, they will always be unique even if the 8 nibble hex   
   string is exactly the same as your Golded MSGID which I note is using   
   1:3634/12.73, which we've already determined is using unixtime to generate the   
   8 nibble hex string.  For argument's sake, say you offline packer uses   
   1:3634/12.74 and happens to coinicide with 5c9fbf47 while assigning an 8   
   nibble hex string to a message in an incoming offline packet, then the   
   resulting MSGID will be "MSGID: 1:3634/12.74 5c9fbf47" instead of ""MSGID:   
   1:3634/12.73 5c9fbf47".  Also it should never collide with any other program's   
   MSGID if they all have their own point address even when the initial hex   
   string is identical and therefore the following incremented hex strings.   
      
    ml> maybe QWKE but the readers on the user's end just don't   
      
   Another reason I never got into offline readers.  What I am currently doing is   
   definetly offline messaging but the messages generated are a stripped down   
   version of the packed MSG format with a single unixtime used to generate the   
   obsolete ftn datetime stamp as well as a hex string for the MSGID.  It is very   
   nice.   
      
    ml> in pascal back in the day, you had byte, word, real, int and   
    ml> longint   
      
   I am uncertain as to when "back in the day" was.  However when I first learned   
   F77 way back when, an int was 32 bits, whether signed or unsigned.  What   
   Pascal is calling an int would be called a short (16 bits) and they could also   
   be signed or unsigned.  If I recall correctly, long could be either 32 bits or   
   64 bits depending on the platform and it seems to me the on the VAX/VMS system   
   I was working on back then, it was 64 bits.  Most of the stored data (9 track   
   tape) were 32 bit floats with an ASCII 512 byte header for individual records   
   or files or whatever the kids these days are calling them.  Compression was   
   (is?) definetly vorbotten.  Also all datetime stamps were in UTC.  That was   
   all that mattered.   
      
    ml> there's still a lot of older embedded systems in place   
      
   I have absolutely no doubt about that.   
      
    ml> i suspect it was for extremely accurate timing capabilities   
      
   For sure but if the error is over 30 times the resolution (1ns) then extremely   
   accurate is out the window.  I am not sure what the resolution for modern   
   atomic clocks might be but I am sure that neither of us has direct access to   
   them and even if we did we couldn't take advantage of the increased accuracy.    
   I certainly don't have anything handy that could even come close.   
      
   Life is good,   
   Maurice   
      
   ... Don't cry for me I have vi.   
   --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)   
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)   
   SEEN-BY: 15/2 18/200 123/1970 154/10 203/0 221/0 226/17 229/107 354   
   SEEN-BY: 229/426 452 1014 240/5832 249/206 317 400 280/464 5003 310/31   
   SEEN-BY: 317/3 322/757 342/200 393/68 396/45 423/120 633/280 770/1   
   PATH: 280/464 229/426