Manage tranferable files

This section describes the Transfer CFT transfer management processes for sending and receiving files.

Sending a file

The file management facilities provided by Transfer CFT when sending files are:

  • File selection
  • End-of-transfer

File selection

  • File availability check. Transfer CFT checks that the file to be accessed has not been locked by an application other than Transfer CFT. If this is the case:
    • In sender server mode, the catalog entry corresponding to the transfer changes to the H state. Transfer CFT sends the partner a protocol diagnostic code indicating a file access conflict. In this case, the catalog entry of the receiver/ requester Transfer CFT receiving this protocol diagnostic code changes to the H state, DIAGI=635.
    • In requester mode, the catalog entry corresponding to the transfer remains in the D state, DIAGI=135. The transfer is attempted again after the predefined number of minutes without incrementing the RETRY sequence.
  • The calculation of the real size of the file sent (which depends on the systems and protocol used).
    • The size is used for dynamic allocation purposes at the receiver end.


This is the action on the sent file: deletion or resetting to zero of the file, or no action at all. See the FACTION parameter of the SEND command.

Receiving files

The facilities provided by Transfer CFT when receiving files are:

  • File selection
  • End-of-transfer

File selection

  • A directory can be implicitly created before the reception file is created
  • If the file has not been created, the disk space required to store the file received is dynamically allocated
  • If the reception file has been created before the transfer, the availability of this file is checked
  • You can use a temporary storage file
  • File existence check (FDISP parameter) and associated actions (FACTION parameter)


The temporary file is renamed with the name of the real file, if a temporary storage file has been used.

The following aspects are described below:

  • At the receiver end, the checking mechanisms and the steps taken to manage the file received during the file selection phase
  • At the sender and receiver end, the mechanism for dynamically allocating the disk space used to store the received file

Storing data

There are two ways to store received data:

  • Directly in a user file Closed , the name is defined in the FNAME parameter
  • In a temporary file Closed the name is defined in the WFNAME parameter, which is renamed on completion of reception with the name used for operation (FNAME parameter)

This method checks the integrity of the file received: the file is only available on completion of the transfer. During the transfer, an application cannot take possession of the temporary file.

Direct data storage

When data is stored directly in a user file, the following phases and checks occur.

Note Depending on the outcome of Phase 1, you may go to either Phase 2 or Phase 3 (1 to 2, or 1 to 3).

Dynamic disk space allocation at the receiver end

UNIX, Windows: These systems do not allow this type of allocation.

Before receiving a file, the receiver Transfer CFT attempts to allocate the disk space required given its knowledge of the size of the file to be received.

At the sending end, the FSPACE parameter of the SEND command defines the size of the file to be sent. The NSPACE parameter of the SEND command defines the size to be imposed on the receive file, at the partner end. If this parameter is not defined, it takes the value of the FSPACE parameter.
The FSPACE parameter does not usually have to be defined since for each transfer the Transfer CFT automatically locates the size of the file to be sent (check in the Transfer CFT Operations Guide corresponding to your OS, that this facility is effectively supported by the system considered).

At the receiving end, the FSPACE parameter of the RECV command defines the size of the receive file. If the transfer protocol used conveys the file size information, it supplies the value of the FSPACE parameter, when this parameter is not defined.
Transfer CFT makes sure that the space required for the receive file is available before activating the transfer.

Implicit directory creation

Available for UNIX file types, and Windows

In both cases of file creation by Transfer CFT or by an associated utility, namely creating a receive file or creating a service file via the CFTFILE or COPYFILE commands, the file creation operation may, in some cases, be preceded by a directory creation.

You can implicitly create a directory using the absolute path name, by then adding the special character immediately following the / (folder separator) as shown in the following example. Additionally all folders listed after the special character are implicitly created, so both NewLocation and NewSubfolder in the example.

Note You can use the cft.char.directory_protect parameter to change the special character value, for example from + to ?.


COPYFILE ifname=$CFTDIRRUNTIME/pub/MyTEST, ofname=$CFTDIRRUNTIME/+NewLocation/NewSubfolder/MyTEST

Related Links