It happens twice a year, and until recently, it was a manual operation. I’m referring to the “spring ahead and fall back,” bi-annual adjustment of operating system time. Often, this is referred to as fast time (summer) or slow time (winter); more commonly, it’s referred to as daylight-savings time (summer), other time, or real-time.
Not all time zones in the world adjust for summer and winter time. In fact, it’s not unusual for entire countries to not observe daylight-savings time. Even some states/provinces within a country may not adjust for the time change.
Those areas that participate in the time change usually do it at 2 a.m. on the last Sunday in October and the first Sunday in April. While that’s usually OK for the users, if your time change technique is manual, then someone must be present, awake, and reasonably coherent to make it happen.
If you must adjust the time, let’s make it easy, automatic, and painless. If you don’t need to adjust the time at your current employer, then let’s acquaint ourselves with the technique for future needs.
In the early days, the accepted way to accomplish the time adjustment was to shut down and re-IPL and have operations key in a SET DATE=xx/xx/ xx,CLOCK=hh/mm/ss command with the new time. This method was simple, effective, and straightforward. However, it also was time-consuming; the change required interrupting processing for up to 30 minutes. Years ago, many sites didn’t require 24x7 operations, minimal interruptions to the processing cycle, worldwide user locations, and lights-out (or near lights out) operations, so it was acceptable.
As hardware changed and automated systems initialization became a reality, the process changed. We still shut down the system but we then changed the real CPU date/clock via the hardware console, enabled the Time of Day (TOD) clock, and re-started everything. The CPU date/time and all subsystems’ date/ time were the same, and z/VSE automatically issued a SET/DATE/CLOCK command under the covers. We still had processing interruption and a manual procedure for actually changing the date/time.
Somewhere during this time, z/VSE developers added the ZONE option to the SET command. Having the ZONE option allowed the hardware clock to be set to Greenwich Mean Time (GMT), and by issuing a SET ZONE=WEST/05/00 during z/VSE IPL, the z/VSE time was set to five hours west of GMT; in other words, Eastern Standard Time. ZONE command options allow for EAST or WEST of GMT from 00/01 until 23/59.
By simply changing the SET ZONE command in the z/VSE IPL procedure to SET ZONE=WEST/04/00, cataloging the IPL procedure and re-IPLing, the time would be changed to four hours west of GMT, Eastern Daylight-Savings Time.
By setting the hardware clock to GMT time and z/VSE to local time, the problem of e-mails having incorrect times (earlier or later times based on GMT) was also resolved.
Now, several z/VSE systems running on the same CPU could easily, consistently, and almost automatically reflect the actual time at the user’s remote location. An example is two z/VSE systems residing on the same processor at any physical location: VSE1 serving the East Coast could have Eastern Standard Time, and VSE2 serving the West Coast could have Pacific Standard Time simply by specifying a SET ZONE command in each z/VSE with different values.