IBM Support


Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

APAR status

  • Closed as program error.

Error description

  • The Configuring monitor retry behavior for message-to-file
    transfers topic in the MQ V9.1 section of IBM Knowledge Center
    (which can be found at the following URI:
    .mq.adm.doc/m2f_mon_retry.htm) contains the following
    "If a message-to-file transfer that is triggered by a resource
    monitor fails and leaves the message group that triggered the
    monitor on the queue, that transfer is resubmitted at subsequent
    poll intervals. The number of times that the transfer is
    resubmitted is limited by the monitorGroupRetryLimit property of
    the monitoring agent."
    However, this functionality does not work. If a message-to-file
    transfer fails, it is never resubmitted or retried.

Local fix

  • Recreate the MFT resource monitor using the -c and -f flags to
    have the failed message-to-file transfers resubmitted.  In
    cases where the user wishes that the resubmitted transfer be
    updated in the MFT transfer log, they must remove the failed
    log entry using the MQ Explorer beforehand.

Problem summary

  • ****************************************************************
    This issue affects users of IBM MQ Managed File Transfer who
    have agents that perform message-to-file transfers.
    Platforms affected:
    IBM MQ V9.1 Managed File Transfer changed the way in which
    message-to-file transfers worked. Rather than destructively
    getting the messages as in previous releases, the source agent
    would browse the messages on the source queue during the
    transfer, and only delete them if the managed transfer was
    successful. This was done to prevent messages from being lost in
    the situations where a managed transfer failed part-way through.
    As a result of this change, the resource monitor retry
    functionality no longer worked. This functionality assumed that
    messages would be removed from the source queue during the
    transfer, and would be rolled back in the event that the
    transfer failed. This would cause the backout count of the
    messages to be increased. The resource monitor would then use
    the backout count to determine if a message on the source queue
    needed to be included in a managed transfer. The logic it would
    use is shown below:
    - If there is already a transfer with the same ID as that of
    message ID, then:
        - Do not submit a new managed transfer request for the
    - Else:
        - If the value of the agent property monitorGroupRetryLimit
    is set to -1 then:
            - Submit a new managed transfer for the message.
        - Else:
            - Check the backout count of the message.
            - If the backout count is greater than 1 and less than
    the value of the agent property monitorGroupRetryLimit:
                - Submit a new managed transfer for the message.
            - Else:
                - Leave the message on the queue.
            - End if
        - End if
    - End if
    However, as the messages were now browsed by the source agent,
    the backout count would always be zero. This meant that the
    resource monitor would never attempt to retry a failed
    message-to-file transfer.

Problem conclusion

  • To resolve this issue, MQ Managed File Transfer resource
    monitors have been updated to keep a count of how many times a
    message-to-file transfer has been attempted. Every time a
    message-to-file transfer is started, the monitor updates the
    The resource monitor will then compare the value of the agent
    property monitorGroupRetryLimit with the value of the counter,
    rather than the backout count of the message, in order to
    determine if a failed message-to-file transfer needs to be
    resubmitted or not.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    v9.1 LTS
    v9.2 CD    9.2.1
    The latest available MQ maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'

Temporary fix




APAR Information

  • APAR number


  • Reported component name

    IBM MQ MFT V9.1

  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


  • 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

    IBM MQ MFT V9.1

  • Fixed component ID


Applicable component levels

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"910","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
31 March 2021