Paul Gilmartin wrote: > Yes, but the important distinction is that, in contrast > to the CVT fields, neither TZ nor any other environmental > setting needs to be changed semiannualy.
True. But I bet most z/OS mainframe folks are happy it still works the way it does now. Why? Not everybody wants to or can afford to change their time zone offset at the same time that the civil clocks are changed. And, not every system is in a location that observes Daylight Saving Time. Of course, there could be yet another parameter that indicates whether or not THIS system observes DST, and another parameter that indicates the magnitude of the DST change (not all locations around the world adjust the clock by exactly one hour for "Summer Time" or whatever they call it). But, even if z/OS had all of this additional automatically-effective parameterization available, I bet that a significant plurality would not "take advantage" of it, and instead elect to handle it manually, across an IPL, just like they do now. If OS/360 had done it right to begin with, and had the DST parameters, calculations and corrections built in from the very beginning, we would not have the problems we now have because all subsystems and applications would have been able to handle DST-instigated local clock discontinuities from the very beginning; every programmer would have known that time-sensitive programs had to be coded to do so. But, that was not to be the history we now regret. UNIX, coming along later, did it just a little bit better. -- 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
