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 tttttttt 0cyydddF and some are 0cyydddF tttttttt. 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
