KB Article #178119

Restarted transfer fails with an unexpected error 613

Problem

Network issue triggered a transfer retry


Using a load balancer that distributes the incoming transfers several CFTs.


Retried transfer reach the next CFT due the load balancer.


Transfer fails with error DIAGI 613 or 919 on the sender side



Resolution

In such an architecture, only a CFT multi-nodes on the receiver side will be up to deal with a transfer restart request.



Once interrupted (network), when the transfer is restarted it includes PeSIT details about the fact that it is a restart and not a new transfer.


Such a restart request, to be accepted, needs to reach a CFT where in the catalog you have the matching context (that is the transfer recorded into the CFT catalog with the same IDT and not already completed)



When the transfer restart reach a CFT where the IDT/context of the transfer exist but is recorded as terminated already, the receiver send back details to the sender so transfer is changed to completed.


Such issue can arrive when the network issue occurs before the sender receives the ACK Trans-end that have been sent already by the receiver.



For the "919 Restart context not available", you just reach a CFT where no trace of the transfer you want to restart exists, this is what you reproduced.



For the '613 FILE - (PeSIT) Transfer aborted by the remote end: the file to be created already exists', the CFT receiver reached, is of course not the initial receiver, have a completed transfer in it's catalog with the same IDT used in the restarts request. So the restart is of course refused. Note that here the IDT already recorded have nothing to do with the transfer restart request.



In the presented architecture, because the receivers/server machines have stand alone CFTs, the catalog information are not shared in between the CFTs.

So it is better to avoid the RETRY on the sender side and trigger new send for the failed transfer from the EXECSE procedure.