I wish I was wrong.
$ c89 x.c CCN0767(I) The "C/C++ " feature of z/OS is not enabled. Contact your system programmer. FSUM3065 The COMPILE step ended with return code 16. FSUM3017 Could not compile x.c. Correct the errors and try again. ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Allan Staller <00000387911dea17-dmarc-requ...@listserv.ua.edu> Sent: Thursday, February 22, 2024 6:50 AM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Nanosecond resolution timestamps for HLL's? Classification: Confidential I believe the XL/C compiler is included in the z/OS license. XL/C++ I am not sure about. Your shop may never have used it, but I believe it is there. Check with your z/OS sysprog. -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Frank Swarbrick Sent: Wednesday, February 21, 2024 8:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nanosecond resolution timestamps for HLL's? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] The runtime is all part of LE. Our shop does not have the C/C++ compiler. Never had a business need for it. Never even looked in to it, so I don't know the cost. ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter <0000031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, February 21, 2024 5:42 PM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Nanosecond resolution timestamps for HLL's? Michael, I do not think it requires the C/C++ compiler to use the C RTL subroutines delivered in CEE.SCEELKEX. You only need the C/C++ documentation to look up the routine names, though working out how the C "header" files define the parameters and return value and translating those to COBOL would be challenging without the headers installed. Is any large commercial shop actually NOT licensing the XL C/C++ compiler these days? I would hope the cost is not be so prohibitive as to bedevil the bean-counters looking for $$ savings. Don't at least some vendor products coded in C/C++ require at least the RTL subroutines (and maybe also the C++ DLL's) installed in order to execute at all? Or is that all delivered in LE? Peter From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Schmitt, Michael Sent: Wednesday, February 21, 2024 6:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nanosecond resolution timestamps for HLL's? This requires a C compiler to be installed on z/OS, which doesn't come standard, correct? And if you had z/OS XL C, how would you bind this? I mean, is this one of those things where you're binding against a path on the OEMVS side? -----Original Message----- 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 12: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>> 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 ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- 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
