Reminder for locations "falling back" from Daylight Savings time to Standard time

[Don Johnson]

There are many new clients using CA Datacom who may not have dealt with the time change from Daylight Savings time (or Summer time) back to Standard time, and while the problems associated with this change become less and less over time, there are a few things you can do to make this change more successful.

 

Here is an overview from a TEC document titled "DST Instructions for CA Datacom/DB and CA Datacom/AD," which can also be found by searching for TEC433738.

For the change from DST back to Standard Time, the only area of concern with CA Datacom/DB is in performing a recovery using log records from this overlapping hour of time, should that be necessary. The same would be true for a CA Datacom/AD environment if you are doing RECOVERY function processing in your AD region. However, many products from CA that use AD do not require the use of the RECOVERY function.

The CA Datacom log records that are stored in the Log Area/Recovery Area (LXX/RXX) contain both an external date-time and astore clock value. Since the log does not allow a date-time step down, special care must be taken in RESTART or RECOVERY processing if performed across the time change boundary. For example, recovery should not process tapes with data that spans the time change boundary; recovery may need to be run twice -- once with the RXX from prior to the time change and a second time with the RXX from after the time change.

Until TIME_SYNC was introduced, at the end of Daylight Saving Time, all CA Datacom users had to either recycle their MUF region or accept that the MUF date-time would be wrong from the point of the time change until the region was next recycled. But, with TIME_SYNC, the process eliminates the recycle of the MUF region and immediately makes use of the new time.

Please refer to the TEC document above for details about the process to follow for z/OS and z/VSE.

[owen.williams2.2]

Hi Don,

 

Thanks for the reminder, but you're a little late (In Europe the "fall back" clock change occurred last weekend).

 

Regarding the the z/VSE instructions in the Tec Document, you say "Print and clear the PXX file (before time change).". There is no way to "clear" the PXX file while MUF is down (The PXX is automatically reset when MUF is started). For z/VSE this should be "Print the contents of the PXX file.".

 

Cheers,

Owen

[Don Johnson]

Owen, I knew that someone would catch my tardiness – I just happened to run into some comments about the US fallback, and realized that we didn’t send our normal “reminder” note last week. While we have a lot of US clients that might benefit from this, I know we have a lot of other clients in the world that would have appreciated the reminder, too, so I will try to be more diligent about putting this note out the next time around.

 

I will also amend the TEC doc with your comments about the VSE procedures, and will clarify anything else there that might be ambiguous. Thanks for pointing this out for me!

[Don Johnson]

Hi CADRE-ites!

 

Thanks to Owen's prompting, we have reworked this document, and hopefully it now has all the best information for you when you need to change the time. The document is still at the same TEC433738 identifier, and I would encourage you to download and review this so you are ready when the next change comes.