Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
Charles Mills wrote: *Most* time fields are built by the individual record cutting product. If a product wants to record time as Latvian Summer Time expressed in Roman numerals in its SMF records it is free to do so. Thus one cannot say SMF time fields are thus and such (unfortunately). Indeed true for record types 128 - 255. You fill in your own headers yourself when working with SMFWTM or SMFEWTM. Paul Gilmartin wrote: I'm shocked and dismayed. You mean that SMF (whatever that is) doesn't prefix a standard header to the information supplied by the record cutting product!? SMFWTM or SMFEWTM will fill in (partially) for you for 0 - 127, but still you can write in whatever you want with IEFU83 if you want. You are free to be shocked+dismayed. Join the already shocked auditors for free... ;-D My auditors once b*tched in my tired ears about this. Too bad. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
Yes, the first 18 bytes are consistent. I know of no inconsistencies there for IBM or non-IBM products. But beyond that point there is no consistent standardization of time (or other) even within IBM products (Types 0 - 127). Thus we have, within the beyond-18 data for IBM products SMF14RST - 0cyydddF Local SMF42PTS - STCK SMF119TN_NITime - 0cyydddF UTC etc. I could go on and on for non-time fields but this thread is about time fields. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, September 18, 2013 3:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CVTLSO, SMF, and RMF (was: Where environment variables ...) Charles Mills wrote: *Most* time fields are built by the individual record cutting product. If a product wants to record time as Latvian Summer Time expressed in Roman numerals in its SMF records it is free to do so. Thus one cannot say SMF time fields are thus and such (unfortunately). Indeed true for record types 128 - 255. You fill in your own headers yourself when working with SMFWTM or SMFEWTM. Paul Gilmartin wrote: I'm shocked and dismayed. You mean that SMF (whatever that is) doesn't prefix a standard header to the information supplied by the record cutting product!? SMFWTM or SMFEWTM will fill in (partially) for you for 0 - 127, but still you can write in whatever you want with IEFU83 if you want. You are free to be shocked+dismayed. Join the already shocked auditors for free... ;-D -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
Charles Mills wrote: Yes, the first 18 bytes are consistent. I know of no inconsistencies there for IBM or non-IBM products. Neither me, unless I missed something. But beyond that point there is no consistent standardization of time (or other) even within IBM products (Types 0 - 127). Thus we have, within the beyond-18 data for IBM products SMF14RST - 0cyydddF Local SMF42PTS - STCK SMF119TN_NITime - 0cyydddF UTC etc. And also for SMF70IST (0hhmmssF) and the queer format of SMF70INT (mmsstttF) or this fun one SMF70CYC (000F)! And remember that SMF42LTM (4 bytes) which is 'Time since midnight, in seconds.', mind you. ;-) Granted, usage type of each of those fields are different, but if you're not careful, you sit with wrong values especially at UNPK statement. I could go on and on for non-time fields but this thread is about time fields. Yes, AFAIK there are more sitting and waiting to ambush all of us. :-) *You should take your time to check up those time bits and pieces.* ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
SMF records are various. In particular, they confront very different temporal granularities. For some the resolution of an STCKE value is appropriate; for others the millisecond is the appropriate unit A standard header is innocuous, but standardizing their substantive timestamp formats would be inappropriate. Delusive exactitude is an old problem. The quotation is now hackneyed, but Emerson disposed of such issues long ago: . . . a foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
Can you tell me that an SMF 42 operation (PDS DESERV) confronts more temporal granularity than an SMF 14/15 operation (xSAM OPEN)? SMF 42 stores STCK but SMF 14/15 stores seconds*100. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Wednesday, September 18, 2013 8:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CVTLSO, SMF, and RMF (was: Where environment variables ...) SMF records are various. In particular, they confront very different temporal granularities. For some the resolution of an STCKE value is appropriate; for others the millisecond is the appropriate unit A standard header is innocuous, but standardizing their substantive timestamp formats would be inappropriate. Delusive exactitude is an old problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
I still, perversely(?), wish that every product which produces an SMF record would have a routine which can be invoked by the IFASMFDP routine which would reformat the record into a text only type output record. Perhaps in a documented XML format. Users could then fairly easily be able to read this using Java programs. Or download to another system, such as z/Linux or shudder/ Windows, to process. I like what the RACF people have done for the IRRADU00 (RACF activity) output. That's what I think would be _excellent_. On Wed, Sep 18, 2013 at 7:42 AM, John Gilmore jwgli...@gmail.com wrote: SMF records are various. In particular, they confront very different temporal granularities. For some the resolution of an STCKE value is appropriate; for others the millisecond is the appropriate unit A standard header is innocuous, but standardizing their substantive timestamp formats would be inappropriate. Delusive exactitude is an old problem. The quotation is now hackneyed, but Emerson disposed of such issues long ago: . . . a foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
Is my first sentence correct if I change it to The z/OS system clock is (if your shop follows best practices) set to Universal Coordinated Time (UTC, similar to Greenwich Mean Time or GMT).? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, September 17, 2013 5:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CVTLSO, SMF, and RMF (was: Where environment variables ...) SMF time fields are all over the map. Some are local, some are GMT, some are in STCK format, some are in hundredths of a second. Just for laughs, some are 0cyydddF and some are 0cyydddF . DB2 writes a shifted STCK format. *Most* time fields are built by the individual record cutting product. If a product wants to record time as Latvian Summer Time expressed in Roman numerals in its SMF records it is free to do so. Thus one cannot say SMF time fields are thus and such (unfortunately). Hmmm. I see the discussion of TAI and UTC in P[ro]Op but not sure I fully grasp what it all means relative to the actual setting of the system clock. The clock is set from the HMC on Power On, is that right? I don't have those manuals, at least not in front of me. What do the relevant manuals say and/or recommend? Yes, my writing is a little sloppy. What I mean is set the hardware clock to UTC-ish time as opposed to local time. I will clean up my writing if someone can straighten me out on the questions in the paragraph above. Interesting note in P[ro]Op: The reader should be aware of the fact that this publication contains many symbols, such as superscripts, that may not display correctly with any given hardware or software. The definitive version of this publication is the hardcopy version (which BTW does not exist anymore!) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, September 17, 2013 4:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CVTLSO, SMF, and RMF (was: Where environment variables ...) On Tue, 17 Sep 2013 16:08:26 -0400, Charles Mills wrote: Time Settings The zArchitecture hardware clock is (if your shop follows best practices) set to Universal Coordinated Time (UTC, similar to Greenwich Mean Time or GMT). I believe not. By best practice it is set (and steered by STP) to TAI - 10 seconds (strangely enough.) All described (often correctly) in at least 3 tables in the P[ro]Op. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
On 17 September 2013 17:32, Charles Mills charl...@mcn.org wrote: Is my first sentence correct if I change it to The z/OS system clock is (if your shop follows best practices) set to Universal Coordinated Time (UTC, similar to Greenwich Mean Time or GMT).? I think it's Coordinated Universal Time. Wikipedia claims that UTC is a compromise between English and French acronyms, and also suggests assimilation to the pattern of abbreviations for coordinated time (UT0, UT1, etc.) Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
SMF time fields are all over the map. Some are local, some are GMT, some are in STCK format, some are in hundredths of a second. Just for laughs, some are 0cyydddF and some are 0cyydddF . DB2 writes a shifted STCK format. *Most* time fields are built by the individual record cutting product. If a product wants to record time as Latvian Summer Time expressed in Roman numerals in its SMF records it is free to do so. Thus one cannot say SMF time fields are thus and such (unfortunately). Hmmm. I see the discussion of TAI and UTC in P[ro]Op but not sure I fully grasp what it all means relative to the actual setting of the system clock. The clock is set from the HMC on Power On, is that right? I don't have those manuals, at least not in front of me. What do the relevant manuals say and/or recommend? Yes, my writing is a little sloppy. What I mean is set the hardware clock to UTC-ish time as opposed to local time. I will clean up my writing if someone can straighten me out on the questions in the paragraph above. Interesting note in P[ro]Op: The reader should be aware of the fact that this publication contains many symbols, such as superscripts, that may not display correctly with any given hardware or software. The definitive version of this publication is the hardcopy version (which BTW does not exist anymore!) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, September 17, 2013 4:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CVTLSO, SMF, and RMF (was: Where environment variables ...) On Tue, 17 Sep 2013 16:08:26 -0400, Charles Mills wrote: Time Settings The zArchitecture hardware clock is (if your shop follows best practices) set to Universal Coordinated Time (UTC, similar to Greenwich Mean Time or GMT). I believe not. By best practice it is set (and steered by STP) to TAI - 10 seconds (strangely enough.) All described (often correctly) in at least 3 tables in the P[ro]Op. ... z/OS uses several independent methods for determining the local time offset when providing local time services to programs: To get UTC, one must subtract CVTLSO from the content of the (E)TOD clock. A recent thread here provoked one of our programmers to ask why we have CVTLSO set to 0 rather than the (current) IBM recommendation of 25 seconds. Our administrator answered: This problem goes way back to 2004 (z/OS 1.4). Back then -- and I don't know if it has changed -- SMF cut records and adjusted for the leap second setting. However, RMF cut records and *did not* adjust for the leap second setting. This inconsistency was causing problems when doing some reporting. The conclusion at the time is that no one absolutely required the leap second value be accurate so we just set it back to zero which worked around our problem. Will this be fixed? (Has it been already?) Naively, one might assume that STCKCONV might be used to convert the RMF timestamps to UTC. I suspect it doesn't. IBM refuses to document clearly what STCKCONV does, claiming it's common knowledge. I disagree. Prior to 1972, STCKCONV might have converted TOD values to GMT (now replaced by UTC). Any common knowledge gained then of TOD-to-GMT (UTC) conversion is obsolete; overcome by events. Things aren't as simple as they used to be. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
On Tue, 17 Sep 2013 17:28:44 -0400, Charles Mills wrote: *Most* time fields are built by the individual record cutting product. If a product wants to record time as Latvian Summer Time expressed in Roman numerals in its SMF records it is free to do so. Thus one cannot say SMF time fields are thus and such (unfortunately). I'm shocked and dismayed. You mean that SMF (whatever that is) doesn't prefix a standard header to the information supplied by the record cutting product!? Hmmm. I see the discussion of TAI and UTC in P[ro]Op but not sure I fully grasp what it all means relative to the actual setting of the system clock. The clock is set from the HMC on Power On, is that right? I don't have those manuals, at least not in front of me. What do the relevant manuals say and/or recommend? Damn! I'm starting to miss Bookie. Is there any way to link (URL) to a particular table in the P[ro]Op other than instructing the reader to download the thing and citing a section number? start with: http://what-if.xkcd.com/26/ The guy knows his stuff. Really. Which links to: http://tycho.usno.navy.mil/systime.html ... UTC-ish time ... YA time convention definition. I suppose it's as good as any. My surmise (conjecture) is that prior to the advent of UTC in 1972 the TOD was assumed to run on GMT. But GMT varied, unpredictably, but measurably from atomic time references, by less than one part in 10**7. This is certainly good enough for IT, but not for some scientific purposes (GPS, nowadays, e.g.). So UTC was invented, in 1972, to run at the TAI frequency, but with one-second offsets introduced sporadically to keep UTC within 0.9 seconds of UT1 (Earth Rotation, or GMT-ish time). At the introduction of UTC in 1972, GMT (UT1, whatever) was 10 seconds behind TAI. IBM elected then to respecify (needlessly, IMO) the TOD to run at the TAI rate, but rather than introducing a 10-second discontinuity (in the bad direction), 10 seconds behind TAI (perhaps better expressed as that now the TOD zero epoch is TAI 1900-01-01t00:00:10) So, prior to 1972, a simple congruential/affine computation sufficed to convert STCK results to GMT. STCKCONV does (I assume; IBM won't document it) correctly convert TOD to GMT in that era. Since 1972 (the only year so far with two leap seconds) STCKCONV (I assume) returns TAI-10 seconds -- a useless convention, but IBM didn't care to make it right. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
