Re: Use sql to calculate a time difference between 2 records

Hi Joe

I've used the timestamp even out to microseconds and have found it not to be unique. Things can go so fast on these processors. There are a couple MI functions that do guarantee uniqueness - at least one is minimal in performance impact.

You can get a GUID from an MI function, GENUUID (Generate Universal Unique Identifier) - from its documentation, see this -

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

It generates a 16-byte value. There's a single parameter - first 4 bytes are an integer containing the bytes provided - has to be at least 32. Next 4 bytes are bytes available and are probably set on return - probably should be zeros on the call. The next 8 bytes should all be nulls (x'00'). The last 16 are where the gen'd UUID ends up - probably needs to be passed as nulls on the call. LOL - it never seems to hurt to use x'00's in parameters to MI functions.

Then there is MATTOD (Materialize Time of Day) or MATMATR (Materialize Machine Attributes) option 4 (I think). This returns an MI timestamp that is guaranteed to be unique - before v6r1 it was a CPU cycle counter - the first 49 bits from the left (I think) held the number of ticks - each tick represented 8 microseconds. V6r1 has added 3 bits to the tick counter, so it is every microsecond. The remaining bits are changed so that the value is always unique - no matter who calls it, no matter how many jobs call it at the "same time". This one is also easier to use - use the API Finder to get details.

Before v6r1, I am speculating that we probably could not get microseconds returned in the 8-microsecond tick intervals. That might account for multiple actions happening in the "same time".

I sometimes use this to gen a unique value for a filename - it is an 8-byte hex value - I use the cvtch (?) function to get a 16-character unique value.

Joe Pluta wrote:

Musselman, Paul wrote:

Alan--
Not an answer to your question per se...
We had an application that time stamped all of the transactions in its
log file. But they came in so fast that multiple records had the same
time stamp! The solution was to have the application delay for a
fraction of a second between writes so the time stamps were unique.

There are various ways to skin this cat. In most cases, job number and timestamp can't be beat. This is especially true if you have a called program to write the record. In the (nearly impossible) situation where you have a process that might write two records at the exact same time, you simply compare the timestamp with the previous timestamp and if they match, loop getting the timestamp until they don't match any more. This is a foolproof mechanism that only adds the overhead of a compare and a very rare delay.

I'm not sure what's required for a GUID, but my sense is that it's system wide it requires interprocess synchronization and thus could become a performance issue, especially as the number of processes rises.

Joe