If the FTP protocol is used then only communication via TCP/IP is possible. Furthermore, a number of special considerations apply when FTP servers are used compared to openFT partners. These are for the most part due to limitations in the FTP protocol:
No restart is performed.
Encryption is only possible for outbound requests to an FTP server that provides support for Secure FTP with the TLS protocol. This requires openFT-CR delivery unit to be installed.
If encryption of the user data is required and the FTP server does not provide encryption, the request is rejected. If encrypted transfer of the user data is required, the login data is also encrypted. If encryption of the user data is not required, the login data is encrypted if the FTP server provides this. No mutual authentication is carried out.
Coded character sets are only supported locally; specifications for the partner system cannot be transported by the FTP protocol.
When files with a record structure are transferred in binary format, the record structure is lost. The contents of the records are stored in the destination file as a byte stream.
File attributes are not supported by the FTP protocol. This means that the modification date and maximum record length are not taken over for the destination file.
Follow-up processing is only possible on the local system or by specifying the FTAC profiles.
The modification date cannot be taken over for the destination file. As a result, the modification date of the destination file is set to the transfer date. This is of particular importance when comparing file hierarchies.
The maximum record length of the send file is not passed to the receiving system. This has an impact when transferring files to a mainframe system such as BS2000 or z/OS. In this case, the default maximum record length applies in the receiving system.
The size of the send file is not passed to the receiving system. This has an impact when transferring files to a mainframe system such as BS2000 or z/OS. The maximum file size is derived from the default value that is used by openFT for primary and secondary allocation and by the maximum number of file extents defined by the system, see openFT manual "Concepts and Functions". If a file exceeds this size, the request is cancelled with the message: “File gets no more space”.
The 'do not overwrite' option can have a different effect because this option cannot be passed to the responder, and the initiator must check whether the file already exists in the partner system. This has the following consequences:
It is possible for a request with the ’do not overwrite’ option to overwrite a file that has been created by a third party in the period between the check being performed by the initiator and the actual transfer.
If 'overwrite' is specified in an admission profile and if the file to be transferred does not yet exist, a request using this profile will still be executed, even if 'do not overwrite' is set in the request.
If you access password-protected mainframe files with a standard FTP client, e.g. in text format (C'password') or hexadecimal format (X'0A6F73'), you must append the password to the name of the remote file separated by a comma.
Example
put localfile remotefile,X'0A6F73'
Please note that the other openFT functions (preprocessing and postprocessing, FTAC, etc.) can only be used if openFT is used as the FTP server on the system, where preprocessing and postprocessing are to be performed.
Problems may also occur when addressing FTP servers which send an unexpected layout when listing directories.