You mention a good precaution that I should have highlighted : that if users cannot avoid moving the system clock backwards and want to protect against the risk of duplicate unique identifiers, then the safest precaution is to shut down the queue manager while the timestamps are repeated.

For example, if you need to move the clock back an hour, then end the queue manager for an hour so that it does not encounter duplicate timestamps.

I’ve updated my post to include this - thanks very much!

The UTC PutDate/PutTime is visible in the Message Descriptor and applications have been known to take these values to record timing information or calculate intervals. If the UTC system clock changes it can cause problems for such applications. I always recommend that applications include date/time stamps in the message data so that issues with UTC, time zone and DST changes are internalised to the application.

Some customer’s systems have their system clock set to the local time rather than UTC (ie. the time zone offset is zero), therefore the PutDate/PutTime appears to applications on local and remote systems to be the local time and they code reliance on this into their applications. This can cause application problems when the system clock is changed twice a year for DST. The above recommendation also applies in this case.

A big disadvantage of setting the system clock to local time is that at the end of daylight savings the system has to be shut down for a least an hour to avoid duplicate system times upsetting logs, journals etc.

Glenn, IBM Australia