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

1. 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.
2. 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

  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 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.

See also:

• File Transfers (JOBF)
• File Transfer Attributes
• Partially Qualified File Transfer
• Executing File Transfers
• Restarting File Transfers
• Reports for File Transfer Objects