Try this.
process pgmname(longmixed) nodynam
id division.
program-id. 'cgettime_test'.
data division.
working-storage section.
01 errno-ref pointer.
01 strerror-ref pointer.
01 len pic s9(9) comp-5.
01 display-x.
05 pic x occurs 0 to 1025 depending on len.
01 clock_id pic s9(9) comp-5.
01 timespec.
05 secs pic s9(9) comp-5.
05 nsecs pic s9(9) comp-5.
01 rc pic s9(9) comp-5.
linkage section.
01 errno pic s9(9) comp-5.
01 h_errno pic s9(9) comp-5.
01 strerror pic x(256).
procedure division.
call 'clock_gettime' using value clock_id
reference timespec
returning rc
if rc = zero
display 'seconds: ' secs
display 'nanoseconds:' nsecs
else
perform handle-error
end-if
goback.
handle-error.
call '__errno' returning errno-ref
set address of errno to errno-ref
call 'strerror' using value errno
returning strerror-ref
set address of strerror to strerror-ref
move 1025 to len
unstring strerror delimited by x'00'
into display-x count len
display quote display-x quote
exit.
end program 'cgettime_test'.
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Farley, Peter <[email protected]>
Sent: Monday, February 19, 2024 5:30 PM
To: [email protected] <[email protected]>
Subject: Re: Nanosecond resolution timestamps for HLL's?
My initial purpose is actually part of implementing COBOL-compatible min-heap
priority queue functions that return equal-priority nodes in FIFO insert order
when popped. A timestamp or some other monotonically increasing integer
tie-breaker provided with the input priority value is necessary to preserve
FIFO order when pushing new items into the queue. As Paul (gil) pointed out,
named counters might provide a similar function but would be far more
performance-expensive compared to a simple STCK value.
Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget
now), which isn’t ALL that far away. A MetalC implementation for STCK values
has been coded and works acceptably, as does of course a straight-forward
assembler implementation. Extension to use STCKE instead of STCK would be
trivial in either case, but of course that also doubles the space occupied by
the tiebreaker value. I would much prefer an IBM-maintained solution that
crosses the epoch barrier transparently.
A reasonably-well-performing implementation of the C function “clock_gettime()”
would probably do the trick, if it was callable from COBOL. David C. pointed
out in an earlier reply that IBM XL C now has this function, if I can figure
out how to invoke it from COBOL. IBM is not always very good at providing
illustrative examples for inter-language cases like this.
As for the actual business purpose, I’m not at liberty to discuss that.
Peter
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Binyamin Dissen
Sent: Monday, February 19, 2024 4:09 AM
To: [email protected]
Subject: Re: Nanosecond resolution timestamps for HLL's?
I don't understand how you will use this.
What is the business purpose?
On Sun, 18 Feb 2024 18:22:53 -0600 Peter Farley
<[email protected]<mailto:[email protected]>>
wrote:
:>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 simple that may
be for those of us who are already comfortable in assembler). In shops where
any new assembler functionality is proscribed or strongly discouraged can't or
would strongly prefer not to use assembler for this functionality.
:>The only HLL-callable function already provided in z/OS that I can find that
provides anything near that resolution is the LE Callable Services function
CEEGMT, but two calls to that service from a COBOL program in a row separated
by only a few calculations and a DISPLAY to SYSOUT produce identical values.
This is not good enough for high-volume processing needs. Every request for a
time value needs to generate a new higher value.
:>Is there any other place I am not yet looking which provides nano-second
resolution like STCK/STCKE and the linux function clock_gettime() besides an
assembler invocation of STCK/STCKE? z/OS Unix has not yet implemented the
clock_gettime() function anyway, so that is off the table. The calling HLL
here will be COBOL, so the C/C++ builtin functions "__stck" and "__stcke" are
not available. Would that they were, but they are not at this time. (Maybe
that calls for a new "idea" to IBM . . . ?)
:>HTH for any pointers or RTFM you can provide.
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
