Hi Frank,

Agreed, you do have to be able to read “header” files and “translate” C types 
and structures to their COBOL equivalents.

I did notice you had not set the clock_id value, but I had already looked up in 
the C header file that CLOCK_MONOTONIC is binary zero and figured you just got 
lucky on the contents of WORKING-STORAGE for that field.  Isn’t that runtime 
option expensive (in CPU time) to use?

As it happens, there are a couple of sites to which I have access that do have 
the most recent COBOL V6.4 updates (“P231130” in the heading line), and I have 
recently been playing around with the new FUNCTION prototype capabilities.  
Neat stuff for sure.

BTW, what Binder SYSLIB library is needed to get those C runtime stubs linked 
into a COBOL calling program? CEE.SCEELKED or others?  Do we need to use one of 
those crazy-looking “side deck” thingamabobs?

Peter

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
Frank Swarbrick
Sent: Tuesday, February 20, 2024 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


You have to have some knowledge of C to be able to do it.  For example, I had 
to look at /usr/include/time.h to be able to known what types and sizes of the 
data fields are needed for COBOL.  And the whole __errno thing, I'm not sure 
how I figured that out.  It was some time ago.



Oh, by the way, I seem to have forgotten to explicitly set clock_id.  Luckily I 
have the runtime setting on which initiates working storage to low-values, and 
the clock_id value CLOCK_MONOTONIC is binary zero.  CLOCK_REALTIME, fwiw, is 
binary 1.  I got these from time.h as well. Anyway, I'd add those as 88 levels 
under clock_id and then set CLOCK_MONOTONIC to true before calling 
clock_gettime().



If you are lucky enough to have the most recent fix pack for Enterprise COBOL 
v6.4 you should be able to utilize function prototypes.  I don't have it, but 
I've been aware of this feature from the COBOL 2014 standard, so I think you'd 
do something like this:



id division.

function-id.

    Clock-GetTime as 'clock_gettime' is prototype

        entry—name is longmixed

        entry-interface is static.

data division.

linkage section.

01  clock-id                       pic 9(9) comp-5.

01  time-spec.

    05  seconds                    pic 9(9) comp-5.

    05  nanoseconds                pic 9(9) comp-5.

01  result-code                    pic 9(9) comp-5.

procedure division using value clock-id

                         reference time-spec

                   returning result-code.

end function Clock-GetTime.



This would be coded ahead of the main program.  Or better yet, placed in a 
copybook and "COPYed" in at the top of the main program

You'd then add to the calling program:



configuration section.

repository.

    function Clock-GetTime.



Then invoke the C routine like this:



    if Clock-GetTime(clock_id timespec) = zero

        [...happy path here...]

    else

        [...sad path here...]

    end-if



You don't have to code the repository entry if you just want to add the 
FUNCTION keyword before Clock-GetTime, e.g.

    if function Clock-GetTime(...) ...



You'd could also remove the "process pgmname(longmixed) nodynam", if you like, 
because those are handled by the enrty-name and entry-interface clauses of the 
function prototype definition.



Have fun!



________________________________

From: IBM Mainframe Discussion List 
<IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Farley, Peter 
<0000031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:0000031df298a9da-dmarc-requ...@listserv.ua.edu>>

Sent: Tuesday, February 20, 2024 8:39 AM

To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> 
<IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>

Subject: Re: Nanosecond resolution timestamps for HLL's?



Thank you very much Frank.  I will try this out on my system.



Would that such clear examples were available from IBM.



Peter



From: IBM Mainframe Discussion List 
<IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Frank 
Swarbrick

Sent: Tuesday, February 20, 2024 1:01 AM

To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

Subject: Re: Nanosecond resolution timestamps for HLL's?





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 
<IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 on behalf of Farley, Peter 
<0000031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:0000031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:0000031df298a9da-dmarc-requ...@listserv.ua.edu%3cmailto:0000031df298a9da-dmarc-requ...@listserv.ua.edu>>>



Sent: Monday, February 19, 2024 5:30 PM



To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>
 
<IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>



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 
<IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Binyamin Dissen



Sent: Monday, February 19, 2024 4:09 AM



To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>



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



<0000031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:0000031df298a9da-dmarc-requ...@listserv.ua.edu%3cmailto:0000031df298a9da-dmarc-requ...@listserv.ua.edu%3cmailto:0000031df298a9da-dmarc-requ...@listserv.ua.edu%3cmailto:0000031df298a9da-dmarc-requ...@listserv.ua.edu>>
 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to