Re: Unique ID

That might be enough to be unique - but not necessarily. The processors are so fast, and multiple jobs could be entering new records and get the same timestamp all the way down to microseconds. The resolution of the clock used to be down to every 8 microseconds - since 6.1 it is down to every 1 microsecond.

But I have run into getting duplicate timestamps at a customer, and that even with some processing in between - amazing how fast these things are now!

Hence my use of the MI TOD - and now even THAT is no longer guaranteed to be unique on multi-core boxes. See this page at IBM's support site -

http://tinyurl.com/6m6prnp

It has an example of non-unique output - on a 6.1 box - and those are supposed to be resolved down to the microsecond in the MATTOD API.

HTH
Vern

On 5/2/2012 9:08 AM, Stone, Joel wrote:

Are you sure that we aren't moving the goal posts here?

The OP was LESS about uniqueness and MORE about identifying NEW records. For this, wouldn't a time stamp to the micro-second be satisfactory?




-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Wednesday, May 02, 2012 8:11 AM
To: Midrange Systems Technical Discussion
Subject: Re: Unique ID

Agreed - the use of a timestamp, even out to microseconds, is no longer
trustworthy as to uniqueness. And even the MI TOD value, which used to
be documented to produce a unique value - it doesn't anymore - in the
world of multiple cores. It used to report the clock ticks, which were
every 8 microsecs - at 6.1 the resolution went to 1 microsec - even so,
I've run tests that product the same value.

So this specification, well, I'm inclined to trust it until I see a
reported problem - I looked up the spec (RFC4122) and find this
interesting statement -

Since a UUID is a fixed size and contains a time field, it is possible for values to rollover (around A.D. 3400, depending on the specific algorithm used).


That should be enough for uniqueness, right? It doesn't depend on any
particular machine architecture, so far as I can tell - this RFC comes
out of the DCE work, which was a joint effort of companies like HP and
IBM and others. So the TOD issues are not part of it, so far as I know.

The algorithms are listed in the RFC, viewable at
http://www.ietf.org/rfc/rfc4122.txt

Of course, for short-term, other methods are needed - to get an object
name, UUID won't work - it's 128-bits (16 bytes) and a character
representation is 32 long.

Interesting stuff - for another day - but it can be trusted, I'm sure.

Vern

On 5/2/2012 6:19 AM, rob@xxxxxxxxx wrote:

Well, I clicked the link and I read
"The UUID is unique as an identifier across all time and space and is
consistent with the Open Systems Foundation (OSF) Distributed Computing
Environments (DCE) version 1 UUID specification described in the DCE's
"Architecture Environment Specification/Distributed Computing: for Remote
Procedure Calls", Appendix A."

Across all time and space sounds pretty darn unique to me.


Rob Berendt