The TOD clock machine facility guarantees that each request to materialize the value of the TOD clock will receive a unique, monotonically increasing value. (wiht a few qualifiers that you can find in the TOD discussion)

Bruce

If you are looking at an 8 millisecond window, that is actually a LONG time. I would be sure to detect duplicates, and probably use the two characters to hold both a system id and a collision sequence counter to ensure uniqueness.

Personally, I would still go with a SQL sequence number and append a system id. SQL can generate and track sequence numbers in microseconds – much less time than the 8 millisecond window you mention.

responding to some of the issues raised.
Fastest – for the job requesting the ID. Multiple interactive jobs of course, so the ‘conventional’ standby of read a record, update it, write it back. is exremely suspect – though there are many, many incarnations on site here.
Unique is the main concern – and across systems, should objects be repatriated, or processing moved to share different boxes. Sequential woudl be useful, but if someone wants to know sequence, I say “let them examine the system creation date”

The 10 bytes is a backward compatibility thing, and though I can see a way to engineer it out, it needs radical re architecting to do so, and you all know the cost/benefit / test issues that come with ‘radical’

‘Tricky home brew’ – hate the stuff. (I have some in may past – haven’t we all?) packing a sequential number down into hex or better would be as far as I’d consider. Given there are 256 characters to a byte, then 2 bytes can represent 256×256 = 65000 values. Realistically, we probably want to restrict to alphanumerics so a radix 36 is OK, and 62 if we use lower case, but there are other implications in doing this kind of stuff (speed of translation being one)

GENUID – Having someone else work it out is good, but I see infrastucture issues using this approach, as the companents need to be accessable – quote “Restart the Platform Agent and the IBM Systems Director agent, if installed.”

So MI instructions for me -= thanks Bruce. The 8 microsecond granularity will just have to be a restriction. But speed of execution shoudl be like lightning. If this becomes a problem, then I’ll have to go with encoding the date/time into something other than hex.
At the end of the day, any routine like this should really acknowledge the possibility of two jobs making a request within the same 8 milliseconds – even though the processing is modestly complex, the ID requests could collide, so a ‘uniqueness test’ may be needed within the routine. ‘ has time moved on yet?’

Excellent suggestions.
I feel I should return the eventual code to some forum somewhere..

If there’s no need for sequential values, consider using the Materialize Machine Data MI instruction with option x’0004′. The time of day returned will be a unique value for the next 60 or so years and, using UTC, avoids any DST concerns related to local time being set back.

Both approaches need 8 bytes, leaving you 2 bytes for system identification.

That was the same problem I saw. The GENUUID function is quick and (technically) guaranteed unique “across all time and space” (whatever that means).

Then again, some of those bytes identify the system/hardware that the API runs on. Maybe it’s time to dig into the format of the UUID to see if six bytes can simply be discarded — if it’s never important to separate UUIDs by system thereby opening the possibility of duplicating “unique” numbers on two different systems.

Tom

Beware of using some tricky home-brew if you are thinking this will be a database key for searching/linking records. It is too easy to generate IDs that “clump” badly and cause database query optimizers to give up and do table scans. Pure integer sequence numbers usually work best.

If you do create your own, think about what a histogram of the resulting values might look like. If it would plot very flat horizontally, great. If you see a bunch of very tall spikes, your query optimizer is probably going to hate that as a possible index.

Nowadays, I’d probably just use a SQL sequence object and let the system take care of everything. See Creating and using sequences for a basic discussion. DB2 can cache a block of values to make a series available to a job to help speed generation.

Tom