Post-transfer file renaming

You can configure  post-transfer, file renaming on the receiver side of a flow. The file is renamed on transfer completion, in the post processing phase, and includes a configurable retry mechanism.


  • When using a group of files in homogeneous mode, you cannot use post-transfer file renaming.

How to configure

To enable the renaming option for a given flow (CFTRECV) set FACTION to RETRYRENAME.



Use the following uconf parameters to customize the retry mechanism.

Parameter Default Value Description
cft.server.transfer.rrename.retry_delay 60 seconds 1-65535

Delay in seconds between two retries for renaming.

If the file is not successfully renamed after the first retry_delay, the time doubles for the next retry period. For example, if the file is not renamed after 60 seconds (when using the default value), the next retry occurs in 120 seconds, and so on.

cft.server.transfer.rrename.max_retries 10 1-65535 Maximum number of retries.



Following a successful renaming, CFTF33I is displayed.

Once the maximum number of retries is reached, the transfer moves to the YK state, displays a DIAGI=156, a DIAGP=RETRYRENAME, and a DIAGC= RETRYRENAME MAX RETRIES REACHED.

Additional rename/retry log messages include CFTF32E and CFTF34E.


Information in the catalog displays the number of retries performed.

Work flow

The retry and rename (R) option is the first step of the (Y) phase.


If you have several transfers with RETRYRENAME set for the same FNAME in a single flow, the transfers are queued based on their date/time of the end-of-transfer (DATEE, TIMEE).

Example of spooling and renaming files

This example combines the use of the serialization with the rename/retry mechanism to ensure a spooling of file transfers without overwriting an un-consumed file at the destination.

  • Our user defines a transfer flow, for example DailyReport,based on a transfer state (acknowledgement) using the serialization option.
  • Several applications generate Report files for the flow; these file transfer requests are queued.
  • The source Transfer CFT for the flow executes the first file transfer request, Report1.
  • The target Transfer CFT receives Report1.
  • Post-processing makes the file available to a target application, and immediately sends an acknowledgment to the source. This enables the next file transfer in the queue to be executed.
  • Upon receiving the acknowledgement, the source Transfer CFT executes the next transfer request Report2. However:
  • If the file no longer exists on the target (it was consumed by a target application), the cycle repeats as above.
  • If the file still exists on the target Transfer CFT, then the next new file transfer ( Report2) enters a retry cycle while it waits for the previous file to be deleted (moved/copied).

Example configuration

Create models

Create a sender side model:

CFTSEND id=DailyReports,



Create a receiver side model:

CFTRECV id=DailyReport,





Define post-processing

Post-processing should include an acknowledgement so that the next queued transfer request is triggered. Additionally, your post-processing script can include, for example, a message to indicate that the file has been received and renamed, and is ready to be consumed by the target application.

end part=&part,




send part=&part,




msg='&fname ready to consume by target application'

...[at this point the file is consumed by the target application]...

end part=&part,idt=&idt,istate=no,diagc='FILE CONSUMED'

Enter command to send files

send part=paris,



send part=paris,



send part=paris,



Check output files

Sender side

17/01/26 18:01:43.31 CFTR12I SEND Treated for USER \dupont <IDTU=A000002C PART=PARIS IDF=DAILYREPORT>

17/01/26 18:01:43.37 CFTR12I SEND Treated for USER \dupont <IDTU=A000002D PART=PARIS IDF=DAILYREPORT>

17/01/26 18:01:43.37 CFTR12I SEND Treated for USER \dupont <IDTU=A000002E PART=PARIS IDF=DAILYREPORT>

17/01/26 18:01:43.43 CFTT57I Requester transfer started <IDTU=A000002C PART=PARIS IDF=DAILYREPORT IDT=A2618014 >

17/01/26 18:01:43.43 CFTT58I Requester transfer ended <IDTU=A000002C PART=PARIS IDF=DAILYREPORT IDT=A2618014>

17/01/26 18:01:44.38 CFTT59I Server reply transferred <IDTU=00000000 PART=PARIS IDM=DAILYREPORT IDT=A2618014>

17/01/26 18:01:44.40 CFTT57I Requester transfer started <IDTU=A000002D PART=PARIS IDF=DAILYREPORT IDT=A2618015 >

... (etc. for each transfer)

Receiver side

17/01/26 18:01:43.43 CFTT57I Server transfer started <IDTU=A000002F PART=NEWYORK IDF=DAILYREPORT IDT=A2618014 >

17/01/26 18:01:43.43 CFTT58I Server transfer ended <IDTU=A000002F PART=NEWYORK IDF=DAILYREPORT IDT=A2618014>

17/01/26 18:01:43.43 CFTT88I+<IDTU=A000002C WFNAME=pub/FTEST NBC=7104>

17/01/27 18:01:43.43 CFTF33I Rename to FNAME=pub/myreport done <IDTU=A000002F PART=NEWYORK IDF=DAILYREPORT IDT= A2618014>

17/01/26 18:01:43.45 CFTS03I _ exec/myreport.cmd executed <IDTU=A000002F PART=NEWYORK IDF=DAILYREPORT IDT=A2618014> (0.013008 sec)

17/01/26 18:01:44.37 CFTR12I END Treated for USER \dupont : DIAGC value was "" and is now "READY TO CONSUME"

17/01/26 18:01:44.38 CFTH60I reply transfered <PART=NEWYORK IDS=00005 IDM=DAILYREPORT NIDT=2618014>

17/01/26 18:01:44.40 CFTT57I Server transfer started <IDTU=A000002H PART=NEWYORK IDF=DAILYREPORT IDT=A2618015 >

Related Links