Paul Gilmartin wrote: > I'm confused. I thought STCKCONV takes as input a TOD > clock value, and if you operate as IBM recommends, TOD > clock values are always GMT.
STCKCONV takes a TOD clock-FORMAT value as input. What that is, or what that input represents, is YOUR business. STCKCONV is just a conversion service, provided as a built-in function by z/OS. STCKCONV will convert _any_ TOD STCK- or STCKE-format TOD clock timestamp value to its corresponding "human readable" time and date (although its output is in packed decimal, so you first have to convert it to zoned decimal before you can actually print it). > How can the [program I illustrated] give the correct result > if STCKGMT is read from a log file written on the other side > of a Daylight/Standard or Leap Second boundary? If by the phrase "correct result" you mean "actual LOCAL TIME" then it can't and won't. That is not what I was trying to show you. I was demonstrating and illustrating the fact that that, for input to STCKCONV, you HAVE TO ALREADY HAVE a corrected local time stamp value (in STCK or STCKE format) in order to get the correct LOCAL TIME out of the STCKCONV service. The purpose of the program was to demonstrate that you can't get what you call the "correct result" out of STCKCONV with JUST a TOD clock value. If you have TOD clock values recorded in a data set (such as a log file of some sort) then you will simply have to know (if you did not also record the contemporaneous values of the LSO and LDTO fields) and be able to reproduce them. In some cases, of course, this information is known. For example, the value of CVTLSO is pretty constant, and can actually be looked up in a table whose argument is GMT, because when LSO changes and, in the past, has changed, is set by international agreement and is published. So that does not need to be recorded with the STCK[E] values, if you are willing to go to the trouble of looking it up in a table. The value of LDTO is simply time zone-dependent, and if you know the time zone of the machine that produced the data then that can be looked up in another table. There are two boundary conditions that are difficult to deal with, but for the most part, unless you are writing an operating system or a product, you don't really need this data recorded. It's easier of course if you do have it, but it costs you an extra 16 or 32 bytes in your log records or whatever. -- WB ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
