A fix is available
APAR status
Closed as unreproducible in next release.
Error description
When an out of syncpoint publish operation starts a new UOW, but the publish fails, the messages put inside the publish are backed out; however the (now empty) UOW is not ended. On subsequent publish operations this UOW is reused and will not be ended until the task ends (for long running tasks such as channels this leads to an increase in the number of log records in the unit of work that must be shunted and a consequent increase in the amount of data logged). . Addtional symptoms: CSQJ160I Long-running UOW found CSQR026I Long-running UOW shunted
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Out of syncpoint publishes, that create * * a nested unit of work, such as a * * message that meets the topic delivery * * criteria (NPMSGDLV/PMSGDLV) for all * * subscribers, that fail to successfully * * complete do not terminate the * * associated UR. * **************************************************************** * RECOMMENDATION: * **************************************************************** Publish/Subscribe based work may result in a nested unit of work being created. These are created when a message meets the criteria for the topic attributes NPMSGDLV and PMSGDLV, which may result in the put to the topic failing if the message fails to be delivered to subscriptions specified in the attribute. If the work fails to complete successfully, such as the case of a failed put, the nested UOW is backed out, but in the case where a new UR was created to handle the nested UOW, this is not terminated. This results in the UR remaining present, resulting in additional persistent work reusing this UR. This can result in the UR being considered long running, and being shunted. If a large number of messages reuse this UR, the UR may result in the logs being filled at a higher rate, due to more space being required to shunt the log records.
Problem conclusion
Temporary fix
********* * HIPER * *********
Comments
Nested unit of work processing has been updated to detect if a nested UOW is required, in the case where another UR is currently active. A nested UOW will only be created when correctly required.
APAR Information
APAR number
PI27399
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
100
Status
CLOSED UR1
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-10-10
Closed date
2014-11-25
Last modified date
2015-02-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PI27881 UI23432
Modules/Macros
CSQERSAV CSQIDEL3 CSQIRSAV CSQLRSAV CSQMRSAV CSQMSUSB CSQMTPUT
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UI23432
UP15/01/16 P F501
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 February 2015