What's the valid reason for setting the CLOCK00 to the physical location? I can't think of one.
Generally, I'd think consistency would be the primary reason, and if there's any automatic processing (e.g. batch scheduling) based on the local time, you (I assume) would not want that going out-of-synch with the users. sas On Tue, Dec 5, 2017 at 9:51 AM, Dana Mitchell <[email protected]> wrote: > Not strictly only for DR, back in the 00's I worked with moving several > CEC's and datacenters around some, we had CEC's in Eastern, Central time > zones, users in Eastern, Central and Mountain zones, and CECS moved to > Central, then Mountain time zone, we always kept the local time offset set > to the user's local time. This was a 'Bronzeplex' so the users mostly > stayed with their primary LPARs. > Dana > > On Tue, 5 Dec 2017 12:44:14 +0000, Dyck, Lionel B. (TRA) <[email protected]> > wrote: > >>A question came up this morning - when doing a DR where the DR environment is >>in a different time zone from the production environment, should the CLOCK00 >>TIMEZONE be updated for the physical location of the DR environment? >> >>I can see valid reasoning for doing either - what is your approach (and why)? >> >> >>-------------------------------------------------------------------------- >>Lionel B. Dyck <sdg>< >>Mainframe Systems Programmer - TRA >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
