IBM Support

IT18728: MQ EXPLORER MFT PLUG-IN SHOWS TRANSFERS IN STARTING STATE EVEN THOUGH THEY HAVE COMPLETED

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

  • When using the Transfer Log page in the IBM MQ Explorer Managed
    File Transfer (MFT) plug-in to monitor file transfers taking
    place across an MFT network, transfers between a particular
    source and destination agent pairing show the transfers as
    "Starting" in "Completion State" column.  The transfers between
    these two agents are never moved to the "Successful" completion
    state even though the transfers did complete without error.
    
    Double clicking on these transfers and selecting the "XML" page
    from the transfer properties window shows the expected
    "started", "progress" and "completed" XML data from the transfer
    log messages published by the source agent but each is written
    under a "# STARTING" header.
    
    If the roles of the agents are reversed, such that the source
    agent becomes the destination agent and vice versa, then the
    final state of the transfer in the MQ Explorer is reported
    correctly as "Successful" once it completes.
    

Local fix

  • Ensure that the clocks on the system where each Managed File
    Transfer agent is running are synchronized.
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects users of the IBM MQ Explorer Managed File
    Transfer (MFT) plugin who:
    
      a) are monitoring file transfers in an MFT network using the
    Transfer Log page,
    
      b) have an agent pairing to perform file transfers where the
    system clock on the host upon which the destination agent is
    running is ahead of the system clock on the source agent's host,
    
      c) are using a version of the MQ Explorer that includes the
    fix for APAR IC99545, which includes:
    
        - WebSphere MQ V7.5.0.5, V7.5.0.6, and V7.5.0.7 Explorer
        - IBM MQ V8.0.0.1, V8.0.0.2, V8.0.0.3, V8.0.0.4, V8.0.0.5,
    and V8.0.0.6 Explorer
        - IBM MQ V9.0.0.0 and V9.0.0.1 Explorer
    
    
    Platforms affected:
    Windows, Linux on x86-64, Linux on x86
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    All agents periodically publish a status message to the
    SYSTEM.FTE/Agents topic tree on the MFT coordination queue
    manager that includes a list transfers that they have registered
    and the agent's perspective of each transfers' state.  Source
    agents for file transfers also publish transfer log messages,
    with an XML payload adhering to the "TransferLog" schema, to the
    SYSTEM.FTE/Log topic tree when transfers start, are running and
    have completed.  The MQ Explorer Managed File Transfer (MFT)
    plugin uses both agent status messages and transfer log "action"
    publications to determine the state of file transfers, which can
    then be reported in the Transfer Log page.  Transfer states that
    can be reported by the MQ Explorer include:
    
      - Queued
      - Starting
      - In progress
      - Recovering
      - Successful
      - Partially successful
      - Failed
      - Malformed
      - Cancelled
    
    
    APAR IC99545:
    
      http://www-01.ibm.com/support/docview.wss?uid=swg1IC99545
    
    fixed an issue where the final state of transfers would be
    reported incorrectly (for example as "Starting" rather than
    "Successful") if messages were delivered to or processed by the
    MQ Explorer MFT plugin out of order.  APAR IC99545 did this by
    comparing the time reported in transfer log XML publications and
    only updating the overall state of a transfer if a message was
    being processed with a timestamp later than the most recent
    known for that transfer log record; because "completed" action
    transfer log XML messages are always published by the source
    agent after any "progress" action messages, which are published
    before any "started" action messages.
    
    However, if the system clock on the host where the destination
    agent for a file transfer was running was ahead of the source
    agent's system clock (typically by a time period greater than
    the length of the time it takes the transfer to complete) then
    the file transfer state would have remained being reported as
    "Starting" or "In progress", for example, and not moved to the
    appropriate completion state, such as "Successful" or "Failed".
     This was because when the transfer log record in the MQ
    Explorer MFT plugin was updated using the status message
    published by the destination agent, a later time (as reported by
    the destination agent) was associated with it.  In this
    scenario, the time, as reported by that destination agent, was
    associated with the transfer log record which would be ahead of
    the time reported by the source agent in the subsequent action
    transfer log XML publications.
    
    Therefore, when the transfer then completes with the source
    agent publishing the "progress" and "completed" action transfer
    log XML messages to the SYSTEM.FTE/Log topic with a timestamp
    based off its host system, the time reported in these log
    messages are before that included in the destination agent's
    status publication.  As a result, the MQ Explorer MFT plugin
    would have deemed these publications as "old" message and would
    not update the overall transfer state.
    

Problem conclusion

  • The MQ Explorer Managed File Transfer plugin has been updated
    such that all messages (agent status and transfer log) reporting
    a change in the state of a transfer cause the MQ Explorer to
    update the reported transfer's state if the state change is
    valid.  The timestamps in the agent status messages and the
    action transfer log XML publications are no longer used to
    determine whether a state change should be honoured when
    processing a message because the clocks on the source and
    destination agent systems are not necessarily synchronized.
    Messages received or processed out of order will result in the
    MQ Explorer updating the overall status of a transfer if the
    resulting state change is valid.
    
    For example, consider four messages each reporting the state of
    single transfer, called A.:
    
      Message 1: Transfer A is in queued state
      Message 2: Transfer A is in starting state
      Message 3: Transfer A is running
      Message 4: Transfer A has completed successfully
    
    The state changes between the messages are all valid.  It is
    valid to move from a queued state, to a starting state, followed
    by an in progress / running state and then finishing with a
    successful state.
    
    However, if message 3 is processed after message 4, it is not
    valid for a completed transfer to have its state changed from
    "Successful" back to "In progress".  In this scenario, the
    overall state of the transfer is unchanged (remains as
    Successful) but any information such as an XML log message
    reporting individual files in the transfer are still added to
    the transfer log record and available to view in the MQ
    Explorer.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v7.5       7.5.0.8
    v8.0       8.0.0.7
    v9.0 CD    9.0.3
    v9.0 LTS   9.0.0.2
    
    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

    IT18728

  • 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-01-09

  • Closed date

    2017-04-27

  • Last modified date

    2017-06-20

  • 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":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
20 June 2017