Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!udel!haven!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: news.software.b
Subject: Re: Ideas for Message-ID's
Message-ID: <1991Mar29.032900.548@ni.umd.edu>
Date: 29 Mar 91 03:29:00 GMT
References: <3427@litchi.bbn.com> <1991Mar22.050749.22115@looking.on.ca> <b2x77c.9uo@wang.com>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland, College Park
Lines: 21
Nntp-Posting-Host: sayshell.umd.edu

In article <b2x77c.9uo@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>The number of safe characters is way below 85 unfortunately.  But above
>36 it really doesn't do you a lot of good.  If you want to crunch 31 bits
>of timestamp and 15 bits of process ID into a string,

I had an interesting thought; on BSD flavored systems with
gettimeofday(), you will always get a unique time returned (provided
the clock is not reset, but only slewed using adjtime()).  If
gettimeofday() is called more than once between clock interrupts, such
that the same time would have been returned, the low order bits of
tv_micro are farbled to ensure a unique value.

You might just dispense with the process id completely, and use a
unique time value composed of the time (though in that case, you've
got 64 bits 'o time, 32 each in tv_sec and tv_usec in struct timeval).
See, another reason to run NTP to synchronize your clocks and to beat
on your vendors that can't get a UNIX kernel to keep correct time and
not drop clock interrupts..

Just a random thought, 
louie