Re: time/date as key fields

... I didn't have a second look to this. At the time I was working on this, we didn't have the time to wait for a fix or message "works as designed", anyway thanks for the renew of information

Dieter

--------------------------------------------------
From: "Crispin Bates" <cbates@xxxxxxxxxxx>
Sent: Friday, November 19, 2010 5:35 PM
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: Re: time/date as key fields

Dieter,

The documentation is extremely clear. It says "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."

I have run a lot of tests generating UUID's for unique session information.
I have never seen a duplicate, in fact I have read documentation that states
that it is forced to be unique in the hardware.

I have only run this on a power 6 570, so it's not the largest machine.

In fact, a simple google search comes up with this -
http://www-01.ibm.com/support/docview.wss?uid=nas35c6103fb07aae31686257050004d30e7

So, it was fixed at V5R3 for larger multi-processor systems. The point is,
according to the specs, it should be unique. What you came across was a bug.

I also saw your discussion on misc400, and you were told by Kent Milligan to
report it. If I had been you, I would have taken that advice...

Crispin.

----- Original Message ----- From: <dieter.bender@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, November 19, 2010 10:59 AM
Subject: Re: time/date as key fields

Crispin,

its definitly not unique. the documentation is not really clear, it says
most likely unique. I've tried to adress this in as400.misc, but didn't
get
exact response there too. So I did test it on my own and I've got
duplicate
values on a fast multi processor iron in a massive parallel scenario.

Dieter

--------------------------------------------------
From: "Crispin Bates" <cbates@xxxxxxxxxxx>
Sent: Friday, November 19, 2010 4:19 PM
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: Re: time/date as key fields

Dieter,

Do you have any reference that says that a UUID from _GENUUID is not
unique?

http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/rzatk/GENUUID.htm
says it is.

Are you saying it is not?

Thanks,

Crispin.

----- Original Message ----- From: <dieter.bender@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, November 19, 2010 9:07 AM
Subject: Re: time/date as key fields

... it depends, maybe for referential constraints, if there are database
relations.
BTW: genUUID on AS/400 is only most likely unique!!! Best choice would
be
an
identity column, if uniqueness is needed.

D*B

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.