In MQ v9.3.5.0 a change has been implemented to improve how zHyperWrite is enabled for use, to make it simpler for users to know if they are attempting to use zHyperWrite. This addresses an issue where a queue manager's capability to perform zHyperWrite is incorrectly recorded which would lead to confusion for users and unutilised zHyperWrite capabilities.
What's Changed?
Previously, when a user had set the value of ZHYWRITE(YES), the queue manager would check if it believes it had the capability of performing zHyperWrite’s for log writes. If the capability was yes then zHyperWrite were attempted, if not then normal logging would be used. However, a drawback was discovered in that the queue manager assessed its zHyperWrite capability at start-up despite the potential for this state to change. If the queue manager checked the zHyperWrite capability whilst it was temporarily unavailable it could result in a scenario in which zHyperWrite will not be attempted until the queue manager is restarted.
To rectify this situation the behaviour of zHyperWrite has changed. Now, irrespective of a log's perceived zHyperWrite capability, the queue manager will always attempt to utilise zHyperWrite if configured to do so (via ZHYWRITE(YES)). This enhancement ensures that zHyperWrite is used whenever possible, with the queue manager falling back to the normal method if zHyperWrite cannot be used. This behaviour occurs seamlessly at no measurable cost to the cost of logging.
Key Changes in Behaviour:
- Display Log now indicates “YES” on logs if ZHYWRITE(YES) is set regardless of capability, while the previous behaviour with CAPABLE and NO remains for when ZHYWRITE(NO).
- The stats QJSTHWC and QJSTHWE, gathered from SMF 115 records, now reflect these changes to zHyperWrite usage. QJSTHWC represents the number of zHyperWrite capable logs, while QJSTHWE represents the number of logs attempting to use zHyperWrite during an interval. With ZHYWRITE(YES), all logs attempt zHyperWrite now, thereby incrementing QJSTHWE for each log used. However, as QJSTHWC's log capability is determined at queue manager start-up, this can result in scenarios where QJSTHWE is greater than QJSTHWC.
- he messages CSQJ116E and CSQJ117E remain unchanged despite these changes, as they are indicators of zHyperWrite configuration issues and the absence of zHyperWrite capable logs. They can still provide the user with valuable insights, despite their accuracy being potentially compromised by the stale log capability.