Fixes are available
Closed as program error.
Using WebSphere MQ File Transfer Edition version 7.0.4 to transfer messages from an MQ queue to a file system fails with BFGBR0120E. Messages are retrieved from a source queue and successfully transferred to the destination agent's file system. However, the attempt to rename the temporary file (ending in a .part suffix) fails. As per normal processing, any remaining temporary files after the transfer are removed from the destination, deleting the transferred data, and the source messages lost. The error message BFGBR0120E is as follows: BFGBR0120E: Protocol bridge agent was unable to rename file <insert_0> to <insert_1> because <insert_2> Severity: 20 : Error Explanation: Protocol bridge agent was attempting to rename a file on the protocol file server but received an exception from the SFTP client. In addition, the Transfer Log in the MQ Explorer shows the transfer completion state as 'Failed' with the error code BFGIO0099E: The rename of temporary file <insert_0> to <insert_1> failed. The end result is that the data does not remain on the destination file system nor is it rolled back to the source queue.
Do not use temporary files for your managed file transfers. Add the following IO property to your agent.properties file for the destination agent: doNotUseTempOutputFile=true
**************************************************************** USERS AFFECTED: This issue affects users of WebSphere MQ File Transfer Edition performing message to file transfers to an SFTP server using a Bridge agent as the destination. Platforms affected: MultiPlatform **************************************************************** PROBLEM SUMMARY: Not setting a value for the 'doNotUseTempOutputFile' agent property means the agent writes to a temporary file at the destination and then attempts to rename this temporary file after the data has been successfully transferred. When performing a message to file transfer, if the rename operation fails, the temporary file is removed as per normal processing, and the source message is not rolled back to the source queue. This is because the syncpoint associated with the original get of the message is committed at the point of successful data transfer, before the rename operation occurs. Therefore, if the rename operation subsequently fails, WebSphere MQ File Transfer Edition would remove the temporary file from the destination but be unable to roll back the source message to the source queue. In this scenario, the data transferred would be lost. If an issue were to occur that prevents data being successfully written to the temporary file at the destination, then WebSphere MQ File Transfer Edition would rollback the message to the source queue. This issue occurs only during a failure to rename a temporary file.
When the MQ Explorer highlights a transfer in red in the Transfer Log with a completion state reading, 'Failed - BFGIO0099E: The rename of temporary file <insert_0> to <insert_1> failed' then the attempt to rename the temporary file, created during the transfer, was not successful. Due to the current design of WebSphere MQ File Transfer Edition it is not possible to roll a message back to the source queue of a transfer if a rename failure were to occur. Therefore the fix is not to delete the temporary file at the destination. A new agent property, 'deleteTmpFileAfterRenameFailure', has been created that accepts a boolean value ('true' or 'false'). By default this property has the value 'true'. Setting this property to have the value of 'false' will ensure that temporary files are not deleted from the destination if the rename operation was to fail. In this case, the transferred data will remain at the destination in a temporary (.part) file. This can then be renamed manually later. This property will affect both message-to-file and file-to-file transfers. Consider a file-to-file transfer with 'deleteTmpFileAfterRenameFailure=false' set in the destination agent's property file and a transfer request with a source disposition of delete. If a rename failure were to occur in this scenario, the source file would remain (would not be deleted by the source agent) and the data would also persist at the destination in a temporary (.part) file. Note how this differs from the message-to-file case. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Platform v7.5 -------- -------------------- Multiplatforms 184.108.40.206 Platform v7.0 -------- -------------------- Multiplatforms 220.127.116.11 The latest available 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 ---------------------------------------------------------------
Reported component name
WMQ FILE TRANSF
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
WMQ FILE TRANSF
Fixed component ID
Applicable component levels