Amq6125e An Internal Ibm Mq Error Has Occurred

[Gaby Zenz]

Theimplications of the DST change for WebSphere MQ are fairly straightforward. In summary, there are no issues with the WMQ runtime (on either the servers or clients) as WebSphere MQ uses UTC and is essentially oblivious to DST. There are some issues surrounding the Java runtime environments supplied with WebSphere MQ. This is all well documented in a TechNote on IBM.com.

This should not cause any errors within the queue manager. WebSphere MQ allows applications to generate identifiers externally to the queue manager, which therefore may reuse identifiers (although this is something that we strongly discourage). As a result, duplicate identifiers have never been something that we could absolutely prevent, and therefore are generally able to handle.

It is possible that duplicate identifiers may cause problems in the logic of some WebSphere MQ applications which rely on these IDs. For example, it may cause applications to get an incorrect reply message, or for message groups to contain incorrect members, or message sequence numbers to be reused. How significant a problem this will be is entirely dependent on the design of the WebSphere MQ application, and how it handles these values.

WebSphere MQ Publish/Subscribe stores information on SYSTEM.BROKER queues, and uses MsgIds to retrieve it. As such, it is possible that duplicate message identifiers could cause errors in the WebSphere MQ Publish/Subscribe Broker.

Consider a message which has a specified time-to-live after which it becomes eligible to be discarded (if it has not already been got from the destination queue). In these cases, the queue manager stores the time that the message arrives, and uses this to perform comparisons with the current time to identify if a message should expire.

If the system clock changes after such a message is put, then it is possible that messages may be expired too soon, or not expire when intended. This may cause a problem for applications which rely on message expiry.

With persistent messages, the stored arrival time will be written to disk and will be restored after the restart of a queue manager. Restarting a queue manager after changing the system time will therefore not resolve any such problems.

Consider a WebSphere MQ application which performs an MQGET and specifies that it wants to wait for a message for a period of time before timing-out. If the system clock changes after the MQGET is issued, but before a message is got or the time-out occurs, then the time change may cause some applications to remain in the MQGET call for longer or shorter than was intended.

This is unlikely to cause a significant problem in most instances, however this is again dependent upon the application design. Restarting the queue manager would ensure that any possible issues for this particular problem are prevented.

TriggerInterval is a queue manager attribute used to restrict the number of trigger messages. It is intended to allow for a queue server that ends before processing all the messages on the queue. The purpose of the trigger interval is to reduce the number of duplicate trigger messages that are generated.

Changes to the system clock during triggering may cause the trigger interval to be generated too early or too late. Whether this causes a problem depends on how significantly TriggerInterval is being relied upon in a given environment.

Changes to the system clock could cause an extra heartbeat to be generated or for one to be missed. It is unlikely that this would cause a problem, however restarting affected channels should be sufficient to resolve any issues that arise.

Whether this causes a significant problem will depend on how much the batch interval is relied upon to ensure that batches are committed. For example, in an environment where BatchSize is set so high that it is never reached, then moving the system clock backwards a long way could result in a notable wait before messages are committed. Typically, however, most customers have BatchSize set to a value that is sufficient to avoid this.

Whether this causes a problem will depend on how these events are being handled and used, however it is likely that unexpected queue service interval events will be relatively easy to match up with a server time change.

There are places within WebSphere MQ where timestamps are collected for displaying to the user, such as the creation and last-alteration date of queue managers and queue manager objects. These values are not used by the queue manager for processing, so should not cause any problems other than potentially misleading or confusing a system administrator with values which may appear to be incorrect.

The best practice is to avoid any changes to the system clock in the first place. Once a system has become confused because of changes to the time, there may be no clear way to resolve the situation (e.g. to identify what how messages with duplicate message identifiers should have been handled).

It is worth highlighting that, unlike distributed platforms, there are in fact specific problems when making time changes on iSeries systems running WebSphere MQ due to the use of the journal. This is explained in the WebSphere MQ System Administration Guide for iSeries.

In this post, I have outlined a number of implications of changes to the time on a system with WebSphere MQ running. This should not be taken as a definitive list of all possible implications, and there may be other issues that I have not considered.

With one exception (potential problems in WebSphere MQ Publish/Subscribe in the event of duplicate MsgId values), none of these implications are issues which would cause errors or problems in the queue manager operation. And most of the issues can be resolved by restarting the queue manager or channels in use.

The implications outlined generally issues which may cause confusion in the logic of applications connecting to WebSphere MQ if the unexpected behaviour is not handled correctly. For example, a change to system time which causes messages to be got later than intended is not going to cause errors within the queue manager, but may cause problems for the application concerned.

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.

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.

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.

3a8082e126