What’s your fastest /’Unique number’ issue method?

5580 pts.
Tags:
AS/400 TimeStamp
IBM i
IBMi RPGLE
Timestamp
Once again I need to incorporate a mechanism which will issue a unique number as an object discriminator.

I'm sure we've all been there. - Incorporate a timestamp - quick and almost always unique, though this application will be busy, so the multiple 'threading' is attractive, Big problem is the length though, I only have 10 bytes.

Maybe pack the numbers into printable alpha numeric? use a radix of 36?

A record on a file (yawn) slow, need to Q for a lock, but a flexible way of doing it, and understandable by 'users'

a data area - its a file really, but maybe quicker to operate? same locking issues

A User space? - are they going to be quicker than data areas?

So - anyone any ideas? I can manage the bit about making it unique across systems by adding a boxID prefix (Darn - another byte lost!)

While I'd like to go with timestamp. I'm thinking I'm forced to use a sequential ascending number, so any helpful info / discussion about access times would be good.

Thanks All



Software/Hardware used:
IBM i

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 9  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    "Fastest" is tricky. Fastest for a single job? Fastest for many jobs in the same application? Since you discuss locks, it has to be across multiple jobs. And are you simply interested in "unique" or do you think sequential is required? (Sequential for a single job? Does it have to be sequential across multiple jobs or would that just be nicer if it was?) 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
    125,585 pointsBadges:
    report
  • BigKat
    if it wasn't for the 10 bytes limitation I'd be tempted to use the _GENUUID MI api (it needs 16 bytes though)
    7,935 pointsBadges:
    report
  • Kccrosser
    I agree with Tom Liotta - use a DB generated sequence number. By caching block values, this can be very fast. 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.
    3,830 pointsBadges:
    report
  • TomLiotta
    if it wasn’t for the 10 bytes limitation... 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
    125,585 pointsBadges:
    report
  • bvining
    If you're looking for a fast sequential value, consider an 8-byte integer stored in a *USRSPC. Access the *USRSPC location by pointer and use the Compare and Swap MI instruction to provide access control. 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.
    6,465 pointsBadges:
    report
  • Yorkshireman
    Thanks for all these, chaps. Great suggestions, and it all happens whilst I'm asleep! 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 256x256 = 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..
    5,580 pointsBadges:
    report
  • Kccrosser
    Obviously, if you are going to add 1-2 characters for system id, they should be appended to the right of the generated time component to ensure this is a good record key. Re converting to base-36, I used that in a large system back in 1996 to generate a globally unique 16-character id, where I needed to handle concurrent id generations from 1000+ independent workstations per system. 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.
    3,830 pointsBadges:
    report
  • bvining
    8 microseconds is the granularity of the clock, BUT the system uses trailing bits in the 8-byte value to provide unique values within the 8 microsecond interval (8 microseconds only requires use of the first 48 bits, leaving lots of room for accesses within the same clock tick by incrementing the trailing bits). Some instructions do allow you to bypass this uniqueness quality, but by default the MI Reference has this to say: 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
    6,465 pointsBadges:
    report
  • Yorkshireman
    [...] What’s your fastest/”Unique number” issue method? [...]
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following