IT31633: Managed transfers come out of recovery and immediately fail witha BFGIO0410E error.

APAR status

• Closed as program error.

Error description

• An IBM MQ V9.1.0.4 Managed File Transfer protocol bridge agent
  (PBA) is configured to connect to a remote file server using the
  SFTP protocol. While acting as the source agent for managed
  transfers, the PBA experiences an issue which prevents it from
  being able to connect to the file server. This causes it to put
  the managed transfers into recovery.
  
  Intermittently, when the managed transfers come out of recovery,
  they are immediately marked as "Failed", with the supplementary
  message:
  
  BFGIO0410E: The protocol server name has not been specified, and
  no default protocol server has been defined for the protocol
  bridge.
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects users of IBM MQ Managed File Transfer who
  have protocol bridge agents (PBAs) that act as the source agent
  for managed transfers.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  IBM MQ Managed File Transfer protocol bridge agents (PBAs) are
  used to transfer files to and from remote file servers, using
  either the FTP, SFTP or FTPS protocols. For every managed
  transfer, a PBA creates an internal object that represents the
  connection to the file server involved in that transfer. The
  object is created when a managed transfer is "opened", and
  closed when the managed transfer is "closed".
  
  If the PBA is acting as the source agent for managed transfers,
  then it will "open" and "close" a managed transfer at various
  points during the lifetime of that transfer.
  
  - The transfer is "opened" when the PBA performs the initial
  processing of the managed transfer request. Once the initial
  processing has been completed, the transfer is "closed".
  - When the managed transfer starts, a TransferSender thread
  within the agent will "open" the transfer. After all of the file
  data has been processed, the TransferSender thread "closes" the
  transfer.
  - At the end of the managed transfer, the managed transfer is
  "opened" so that the source agent can perform the final
  processing of that transfer, before "closing" it.
  
  Now, if a PBA was unable to connect to a file server for some
  reason while processing a managed transfer, the TransferSender
  thread for that managed transfer would put into recovery so that
  it could be retried later. The TransferSender thread would then
  perform some other work before "closing" the transfer and
  removing the internal object associated with it.
  
  Due to a timing issue, it was possible for the managed transfer
  to come out of recovery and start running on a new
  TransferSender thread before the original TransferSender thread
  had "closed" the transfer. In this situation, the following
  sequence of events would occur:
  
  - The second TransferSender thread would check to see if the
  managed transfer was "opened". It was, so the thread proceeded
  with the transfer.
  - The original TransferSender thread then finished its work, and
  "closed" the managed transfer. This resulted in the internal
  object, which represented the connection to the file server for
  that managed transfer, being closed.
  - Some time later, the second TransferSender thread tried to
  access the internal object, so that it could use the connection
  to the file server. However, because the transfer had been
  "closed", the internal object was no longer accessible. As a
  result, the managed transfer was marked as "Failed" with the
  error:
  
  "BFGIO0410E: The protocol server name has not been specified,
  and no default protocol server has been defined for the protocol
  bridge."
  

Problem conclusion

• To resolve this issue, an "open count" has been added to the
  internal object representing connections to a file server. The
  "open count" is incremented whenever a thread within an agent
  "opens" a managed transfer, and decremented when a thread within
  the agent "closes" the managed transfer. The internal object is
  only removed once its "open count" has dropped to zero.
  
  This ensures that if:
  
  - A managed transfer running on one TransferSender thread goes
  into recovery.
  - And then comes out of recovery and restarts on a new
  TransferSender thread before the first TransferSender thread has
  finished.
  
  then the internal object representing the connection to the file
  server for that managed transfer will not be closed off when the
  first TransferSender thread finishes. It will be available for
  use by the second TransferSender thread, and will only be closed
  when that TransferSender thread exits.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v9.1 CD    TBC.
  v9.1 LTS   9.1.0.6
  
  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

  IBM MQ MFT V9.1

• Fixed component ID

  5724H7272

Applicable component levels