IBM Support

IT33894: SourceTransferStartExits can be invoked twice for the same managed transfer.

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

  • An IBM MQ Managed File Transfer agent is configured to run a
    SourceTransferStartExit at the start of every managed transfer.
    The design of the SourceTransferStartExit means that it only
    expects to be run once for each managed transfer. If the exit
    detects that it is has been run more than once for a managed
    transfer, the exit returns an ResultCode of CANCEL.
    Very occasionally, the SourceTransferStartExit is run twice for
    the same managed transfer. This causes the exit to return a
    CANCEL ResultCode, which results in the managed transfer being
    marked as "Failed".

Local fix

  • n/a

Problem summary

  • ****************************************************************
    This issue affects users of IBM MQ Managed File Transfer who
    have agents configured to run SourceTransferStartExits at the
    beginning of managed transfers.
    Platforms affected:
    When a source agent receives a managed transfer request, it
    performs the following steps:
    - Resolve the transfer item specification into a list of
    transfer items (files or messages) to transfer.
    - Run any SourceTransferStartExits.
    - Run any preSource programs or commands.
    - Contact the destination agent for the managed transfer, and
    perform the transfer negotiation.
    A destination agent can only act as the destination agent for a
    certain number of managed transfers at any one time. This is
    specified by the agent property "maxDestinationTransfers". If it
    is already acting as the destination agent for this number of
    managed transfers when it receives a new transfer negotiation
    request, it sends a reply back to the source agent indicating
    that it is currently too busy to participate in the new managed
    When the source agent receives this reply, it puts the managed
    transfer into a WaitingForDestinationCapacity state, and adds it
    to its backlog. After the time period specified by the agent
    property "senderTransferRetryInterval" has elapsed, the source
    agent resumes the managed transfer and sends a new transfer
    negotiation request to the destination agent again, to see if it
    is now able to participate in it.
    Now, in this situation, the source agent would incorrectly run
    any SourceTransferStartExits before contacting the destination
    agent for a second time. Depending on the design of the
    SourceTransferStartExit, this could result in unexpected

Problem conclusion

  • To resolve this issue, MQ Managed File Transfer has been updated
    so that source agents only run SourceTransferStartExits before
    they send the initial transfer negotiation request message to a
    destination agent. If the managed transfer subsequently goes
    into a WaitingForDestinationCapacity state (because the
    destination agent is already participating in its maximum number
    of destination transfers), then the source agent will not re-run
    any SourceTransferStartExits prior to sending the subsequent
    transfer negotiation requests.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    v9.1 LTS
    v9.2 LTS
    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

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

Document Information

Modified date:
10 October 2020