Very nice. Good work Frank. You’ve taught me something new. > On 21 Feb 2024, at 1:54 am, Frank Swarbrick <frank.swarbr...@outlook.com> > wrote: > > 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> on behalf of > Farley, Peter <0000031df298a9da-dmarc-requ...@listserv.ua.edu> > Sent: Tuesday, February 20, 2024 8:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU <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> On Behalf Of > Frank Swarbrick > Sent: Tuesday, February 20, 2024 1:01 AM > To: 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>> on behalf of > Farley, Peter > <0000031df298a9da-dmarc-requ...@listserv.ua.edu<mailto: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> > <IBM-MAIN@LISTSERV.UA.EDU<mailto: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>> 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> > > 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<mailto: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 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
