You can use OS agents to transfer files from one agent to another one. For this purpose, an agent must be installed on the source computer, and on the target computer. This topic describes the procedure of how the communication between the Automation Engine and the agents work. Files are transferred in a secured and encrypted way.
File Transfer Protocol
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 the sender fails to establish a connection because of Firewall settings, for example, the sender notifies the Automation Engine. The Automation Engine then sends the file transfer request to the receiver which now in turn tries to establish a connection to the sender. As soon as 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 will be 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. For details see Defining File Transfer Objects.
-
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.
-
OS/400 -
IFS file system: The available disk space is checked.
-
UNIX:
Depends on what is specified in the INI-file parameter ft_check_free_disk_space=
-
VMS:
The available disk space is checked.
-
Windows:
Depends on what is specified in the INI-file parameter ft_check_free_disk_space=
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.
File transfers continue even if a connection error occurs between the Automation Engine and the agents. As soon as the connection is re-established, the actual status of the file transfer is sent to the Automation Engine.
The following procedures are available for file transfers in order to ensure the reliable transfer of files:
| File transfer procedure | Explanation |
|---|---|
| Transmission security | The accuracy of transferred data is verified with an MD5 checksum verifier that is embedded in the data stream. Data is verified in packets. |
| 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. At particular intervals, the agents automatically create restart points while the files are being transferred (setting FT_RESTARTINFO_INTERVAL in the system variable 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 the major pare of a huge file has already been transferred. You can use the settings FT_RESTARTINFO_LIFETIME and FT_RESTARTINFO_CHECK inf the system variable UC_HOSTCHAR_DEFAULT to specify that status store files should be deleted. 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. 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. |
Depending on the agent platform, the status store files are stored in the following directories:
| Platform | Directory | File name | Peculiarity |
|---|---|---|---|
| Windows | The Temp directory of the agent |
FTNNNNNNN.sts where 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. |
Status store file per file transfer |
| BS2000 | The Temp directory of the agent | FTNNNNNNN.sts | Status store file per file transfer |
| Unix/VMS | The Temp directory of the agent | FTNNNNNNN.sts | Status store file per file transfer |
| OS/400 |
Depending on the INI-file parameter store_type= |
IFS: FTNNNNNNN.sts QSYS: Object with the name FTNNNNNNN and the type USRSPC |
Status store file per file transfer |
| NSK |
Sub-volume in the configuration file (see the NSK agent installation). |
The INI file of the agent: Section [FT-STATUS-STORE] |
Four Status store files that include all restart information |
| z/OS |
Status store dataset |
A Status store dataset that includes all restart information |
See also: