IT21305: MFT resource monitor exits result in ever increasing number of child <exit> elements in monitor log published messages

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 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