> As for implementing a heap, you say you don't care if it's a timestamp.
> Since heaps require single thread or a locking mechanism when
> elements are added / removed, why not just have a counter associated
> with the heap. Each time you add an element, you increment (or
> decrement) the
> Have you looked at the FORMATTED-TIME function?
Thanks Paul, I did look at the FORMATTED-TIME function, but the finest
resolution offered by that function is tenths of milliseconds (four fractional
decimal digits), not even micro-seconds (which would require six fractional
decimal digits).
>What guarantees uniqueness other than STCT(E)? Does the Sysplex Timer/ETR
>guarantee
>uniqueness across the plex?
>
>And monotonicity is a harsher constraint. In the Bad Old Days when each CPU
>had its own
>TOD and uniqueness was achieved by putting the CPU ID in the TOD programmable
>field
I have been reviewing all the documentation I can find to provide nano-second
resolution timestamps from a calling HLL batch program. STCK and STCKE
instructions of course provide this (and more) resolution, but using them from
any HLL besides C/C++ requires an assembler subroutine (however
Using the listserv web interface for the first time, so I hope this goes
through OK.
In testing the new V6.4 user-defined functions capability I have found that it
seems you cannot have a separately-compiled-and-linked user-defined function.
If you separately compile and link the function for
