APAR status
Closed as program error.
Error description
An IBM MQ Managed File Transfer (MFT) agent is using a resource monitor to initiate file transfers, and is configured to invoke a custom user exit when its trigger conditions are satisfied, before the defined task is started. When the resource monitor exit is first invoked, the result of running the exit and any supplemental information from the exit is included in the trigger log message published to the SYSTEM.FTE topic, as expected. However, with each subsequent log message published when the monitor is triggered, data from the previous trigger exit invocations are also present in the logged message. For example, after the third monitor trigger, the message which is logged contains the data: <monitorExits> <exit name="class com.ibm.mqmft.samples.exits.BasicMonitorExit"> <status resultCode="proceed"> <supplement>BasicMonitorExit processing complete. Returning PROCEED result code.</supplement> </status> </exit> <exit name="class com.ibm.mqmft.samples.exits.BasicMonitorExit"> <status resultCode="proceed"> <supplement>BasicMonitorExit processing complete. Returning PROCEED result code.</supplement> </status> </exit> <exit name="class com.ibm.mqmft.samples.exits.BasicMonitorExit"> <status resultCode="proceed"> <supplement>BasicMonitorExit processing complete. Returning PROCEED result code.</supplement> </status> </exit> </monitorExits> Each subsequent invocation of the monitor results in another <exit> element entry being added to the published XML document, resulting in very large messages and subsequent large amounts of filesystem storage space being used on the queue manager host system. If the agent is restarted, the number of <exit> elements resets back to a single instance.
Local fix
Problem summary
**************************************************************** USERS AFFECTED: This issue affects users of IBM MQ Managed File Transfer (MFT) who use resource monitors with user exits, and have configured the agent (using the "monitorReportTriggerSatisfied" property) to publish a trigger satisfied log message SYSTEM.FTE topic each time the monitor is triggered. Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: IBM MFT Resource Monitors can be configured to run a user exit (user supplied custom code) each time the monitor is triggered, as documented in the Knowledge Center on the following URL: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm .wmqfte.doc/monitor_user_exits.htm An MFT agent can also be configured to publish messages to the SYSTEM.FTE topic whenever a resource monitor's trigger condition(s) are satisfied, by using the agent property named: monitorReportTriggerSatisfied as documented in the agent properties tables on the URL: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm .wmqfte.doc/properties.htm When these two options were used together, and a IBM MQ Managed File Transfer resource monitor polled and determined that its trigger conditions had been satisfied, it invoked the defined resource monitor user exit(s). The result of the user exit invocation was then stored within a list on the resource monitor. When the agent subsequently published the message to the SYSTEM.FTE topic, the list of the user exit results was used to construct part of the XML monitor log message. The issue was that the list containing the results of the resource monitor user exit invocations was not being cleared between each task that was invoked by the resource monitor. The result of this was that the list of exit results continued to grow each time the user exit was invoked. As such, the size of the monitor log publications increased over time as later messages contained information about all of the previous exit invocations. For example, consider a simple resource monitor exit with class name "com.ibm.mqmft.samples.exits.BasicMonitorExit", that performs some processing and returns a PROCEED result code and a explanation message, as follows: MonitorExitResult result = new MonitorExitResult( MonitorExitResultCode.PROCEED, "BasicMonitorExit processing complete. Returning PROCEED result code." ); When this exit was called and the agent subsequently published the message, the message would contain the following XML: <monitorExits> <exit name="class com.ibm.mqmft.samples.exits.BasicMonitorExit"> <status resultCode="proceed"> <supplement>BasicMonitorExit processing complete. Returning PROCEED result code.</supplement> </status> </exit> </monitorExits> Each time the resource monitor's trigger condition was satisfied a new <exit> child element was added to the <monitorExits> element. For example, after the third satisfied trigger (which can be on separate polls of the resource monitor) the published XML document would contain the content for the <monitorExits> element as follows: <monitorExits> <exit name="class com.ibm.mqmft.samples.exits.BasicMonitorExit"> <status resultCode="proceed"> <supplement>BasicMonitorExit processing complete. Returning PROCEED result code.</supplement> </status> </exit> <exit name="class com.ibm.mqmft.samples.exits.BasicMonitorExit"> <status resultCode="proceed"> <supplement>BasicMonitorExit processing complete. Returning PROCEED result code.</supplement> </status> </exit> <exit name="class com.ibm.mqmft.samples.exits.BasicMonitorExit"> <status resultCode="proceed"> <supplement>BasicMonitorExit processing complete. Returning PROCEED result code.</supplement> </status> </exit> </monitorExits> even though the exit was invoked only once for the satisfied trigger condition. As the number of satisfied triggers increases, so does the number of additional <exit> elements within the trigger satisfied monitor log message published by the agent to the SYSTEM.FTE topic. The result of this over time was that ever increasing in size monitor log messages were being published to the Topic, until the agent was restarted.
Problem conclusion
The IBM MQ Managed File Transfer (MFT) resource monitor product code has been updated to clear the list of both resource monitor user exit results and supplement information between each task that is invoked by a resource monitor as trigger conditions are satisfied. This ensures that only user exit results and supplement information for the specific task created from an individual trigger is included in the monitor log trigger satisfied publication. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v8.0 8.0.0.8 v9.0 CD 9.0.4 v9.0 LTS 9.0.0.3 The latest available FTE maintenance can be obtained from 'Fix List for WebSphere MQ File Transfer Edition 7.0' http://www-01.ibm.com/support/docview.wss?uid=swg27015313 The latest available MQ maintenance can be obtained from 'WebSphere MQ Recommended Fixes' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037 If the maintenance level is not yet available information on its planned availability can be found in 'WebSphere MQ Planned Maintenance Release Dates' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309 ---------------------------------------------------------------
Temporary fix
Comments
APAR Information
APAR number
IT21305
Reported component name
WMQ MFT V8.0
Reported component ID
5724H7252
Reported release
800
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2017-07-05
Closed date
2017-07-25
Last modified date
2017-07-25
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WMQ MFT V8.0
Fixed component ID
5724H7252
Applicable component levels
R800 PSY
UP
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
25 July 2017