File Transfer Procedure

This topic provides some technical background to how Automic Automation processes File Transfer objects. The Automation Engine sends the complete File Transfer request to the source Agent. This request also includes wildcard specifications in partially qualified file transfers. The source Agent is responsible for resolving this request and retrieving the files that should be sent.

Establishing a Connection

The source Agent (sender) first tries to establish a connection to the target Agent (receiver).
- If it succeeds, it transfers the files to the receiver.
- If it fails, the sender notifies the Automation Engine.
The Automation Engine sends the file transfer request to the receiver, which tries to establish a connection to the sender. When the connection is established, the receiver transfers the request to the sender.

Checking the Disk Space

Depending on the OS, the Automation Engine system checks the disk space on the target platform before it starts the file transfer. If there is not enough disk space, it is allocated.

BS2000

The estimated disk space that is required is allocated when the option Keep Original File Attributes is activated in the File Transfer object.
NSK

Disk space is not checked.
OS/390

Native file system: Disk space is allocated by using the attribute SPACE for the target of the file transfer.
OS/390

USS file system: Disk space is not checked.
OS/400
- Native file system: Disk space is allocated if either Keep Original File Attributes is set or the attribute SIZE is specified for the target.
- IFS file system: The available disk space is checked.
UNIX

Depends on what is specified in the ft_check_free_disk_space= INI file parameter.
VMS

The available disk space is checked.
Windows

Depends on what is specified in the ft_check_free_disk_space= INI file parameter.

Handling File Transfers

Each File Transfer establishes its own connection between the Agents. The files are always sent one after the other and, if the affected Agent supports this functionality, each file transfer is handled in a separate thread or process. This means that several file transfers are handled independently.

The Agents of the following operating systems support threads:

OS/400
Unix
Windows
z/OS

NSK handles each file transfer with a separate process. Therefore, the NSK Agent has a second port that is specifically used for file transfers.

Note: File Transfers continue even if a connection error occurs between the Automation Engine and the Agents. When the connection is re-established, the actual status of the File Transfer is sent to the Automation Engine.

Checks to Ensure Reliable Transfers

The following procedures ensure the reliable transfer of files:

Transmission Security

For File Transfers between non-TLS Agents

The accuracy of transferred data is verified with an MD5 checksum verifier that is embedded in the data stream. Data is verified in packets.
For File Transfers between TLS Agents

TLS Agents use SHA for message integrity. You customize the TLS/SSL settings for Agent authentication in the UC_AGENT_TLS_SETTINGS variable.
For File Transfer between TLS and non-TLS Agents

The TLS Gateway is not considered.

For more information see:

Consistency Check for Restarted File Transfers

You cannot repeat individual file transfer files selectively. Erroneous File Transfers can be repeated from the last restart point.

The Agent creates restart points automatically at particular intervals while the files are being transferred. Your administrator sets these intervals in the FT_RESTARTINFO_INTERVAL system variable (see UC_HOSTCHAR_DEFAULT - Host Characteristics). The Agent stores this information locally on its computer in status store files. If an error occurs, the File Transfer can be restarted from the file last restart point (restart option From last restart position). This function saves time especially if most of a huge file has already been transferred.

To ensure that the target file complies with the source file after it has been successfully restarted, the transferred data is checked against an MD5 checksum. When it creates the restart point, the system also retrieves the MD5 checksum and stores it in the status store file. The checksums differ if the partially transferred file has been changed on the computer of the receiving Agent. In this case, the restart results in an error.

Notes:

Use the FT_RESTARTINFO_LIFETIME and FT_RESTARTINFO_CHECK settings in the UC_HOSTCHAR_DEFAULT system variable to specify that status store files should be deleted.
To save transmission time, MD5 checksums of files that are smaller than 1 MB are not calculated.
You can deactivate the MD5 checksum by using the setting FT_USE_MD5 in the system variable UC_HOSTCHAR_DEFAULT.

Status Store Files

Depending on the Agent platform, the status store files are stored in the following directories:

Windows
- Directory: The Temp directory of the Agent.
- File name: FTNNNNNNN.sts
  
  NNNNNNN is the file transfer's RunID that has been converted to a 7-letter string. You can use the ALPHA2RUNNR script element in order to convert it to the regular 10-digit RunID.
One status store file per file transfer.
BS2000
- Directory: The Temp directory of the Agent.
- File name: FTNNNNNNN.sts
One status store file per file transfer.
UNIX/VMS
- Directory: The Temp directory of the Agent.
- File name: FTNNNNNNN.sts
One status store file per file transfer.
OS/400
- Directory: Depending on the store_type= parameter in the INI file parameter (Call API OS/400)
- File name: IFS: FTNNNNNNN.sts
  
  QSYS: Object with the name FTNNNNNNN and the type USRSPC
One status store file per file transfer.
NSK
- Directory: Sub-volume in the configuration file (see the NSK agent installation).
- File name: As defined on the INI file of the Agent, section [FT-STATUS-STORE] (Agent NSK).
Four Status store files that include all restart information
z/OS
- File name: Status store dataset. For more information, see Installing the Agent for z/OS.
A Status store dataset that includes all restart information.