@John, am I correct that if they are west of Greenwich (the Americas, basically) they've got a real problem if the TOD clock is set to local time and they want to "make it right"? Basically, they have to let the box sit idle for five or more hours so that actual UTC time catches up to their previous TOD clock setting, and DB2 does not step all over itself?
If OTOH they are in the UK or east of Greenwich (EMEA, Asia) then things are much simpler: just set the TOC clock correctly, set the timezone, and go, correct? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John McKown Sent: Tuesday, November 08, 2016 6:17 AM To: [email protected] Subject: Re: Time Change Problem #1398 On Tue, Nov 8, 2016 at 7:52 AM, Christopher Brown <[email protected]> wrote: <snip > If you have no timezone parameter in the CLOCK member, then the local time will be set to the "UTC" time as shown in the above message. Your client is wallowing in the deep, dark past. DB2 logs run off of the TOD clock (usually set to UTC) and pays _no_ attention to the local time. The same with IMS. CICS does pay attention to the local clock, but a simple CEMT PERFORM,RESET command will fix that right up. Or simply recycle the CICS region (likely what your client does if they run CICS<shudder>). UNIX processes are "who knows" but given what you've said, I'd think it likely the client doesn't do much with UNIX. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
