With respect to the use of MQ the biggest challenge is timeouts (MQREASON 2033). There may be several reasons for a MQ timeout and timeouts always appears when we least expect it. In this tip I will give you a method to measure MQ response times before they become timeouts.

Every single message in MQ is equipped with a Message Descriptor called MQMD. In this area there are two field called PUTDATE and PUTTIME. They are both 8 bytes long and contains the date (YYYYMMDD) and the time (HHMISSHU) for when the message was created by a MQPUT or MQPUT1. When your program issues a MQGET to receive the message you can calculate the time the message was staying in the queue. Just extract PUTDATE and PUTTIME from the actual date and time when the MQGET was issued.

If your MQGET is waiting for a certain message to arrive and receives a timeout (MQREASON 2033) instead then you do not have any PUTDATE/PUTTIME available, but if you have measurements for the previous messages you have been waiting for then you have an indicator telling you whether the problem appeared out of the blue or just is a culmination of response times getting worse. Maybe you can in fact issue warnings about possible future timeouts when you know the MQ response time patterns for your application. Maybe it is even possible for you to automatically issue actions to prevent further increase in response times.

Please be aware that the method is only accurate down to 1/100 of a second and only when the clock is synchronised down to an accuracy of 1/100 of a second between the platforms involved in the MQPUT/MQGET pair. If MQPUT and MQGET are issued within the same sysplex you can rely 100% on your measurements, but if one of the platforms are a Windows or UNIX server not running on the mainframe then you must consider using this tip very carefully. The clocks on the different platforms may be out of sync and you may risk to get funny results like negative response times.