The type of data conversion depends on the openFT version that is used on the partner system.
Data conversion in the case of partners as of V10
Depending on the code class (ISO 8859 or DF04) and code variant n (n=1...10, 13, 15) of the local CCS, openFT as of V10 sends the data encoded in ISO 8859-n, DF04-n or UTF-8.
This has the following effect depending on the partner system and the encoding:
Files in Unix and Windows systems to which an ISO8859n CCS is assigned are no longer recoded in the event of send requests to Unix or Windows systems. In the case of transfers between Unix or Windows systems no recoding is now performed for the transfer itself if the same ISO8859n CCS has also been assigned for the target file.
In the case of transferring files belonging to the code classes ISO 8859 or DF04 between Unix and Windows systems and BS2000 or z/OS, recoding is performed at the receiving system (if necessary).
UTF-8 files are recoded at the receiving system (if necessary). Files to which a CCS is assigned that belongs neither to the ISO 8859 code class not to DF04 are recoded into UTF-8 at the sending system and into the CCS of the target file at the receiving system (if necessary).
UTF-16 files are recoded into UTF-8 at the sending system and into UTF-16 at the receiving system (if this is requested).
UTF-16 files generated by openFT possess the endian model and line break convention (LF or CRLF) appropriate to the platform in question.
UTF-8 files generated by openFT possess the line break convention (e.g. LF or CRLF) appropriate to the platform in question.
Data conversion in the case of partners < V10
The transferred data is coded in DF04-n. I.e. when file transfer is performed with openFT partners, the data is transferred in EBCDIC format (corresponds to CCS DF04-n). EBCDIC is used, for example, in BS2000 systems. In the case of transfers with openFT partners on Unix or Windows systems, text files are recoded in the partner system.
Notes for Unix and Windows systems
openFT converts text files when transferring to and from openFT partners as follows:
when retrieving a file into a Unix or Windows system from EBCDIC to ISO 8859,
when sending a file from a Unix or Windows system from ISO 8859 to EBCDIC.
Special characters or alternate representations not defined in ISO 8859 are not converted during code conversion. Files containing such characters should be transferred as binary files, and converted using a user-defined code conversion routine.
In the case of data transfer handled using the FTAM functionality, it is assumed that ISO 8859 is used for the transfer and for the local file with connections between third-party products and openFT partners < V10. No local recoding is therefore performed.
Text format
When sending, openFT assumes that the file to be sent is a pure ISO 8859 text file, which is structured as records separated by carriage returns/line feeds.
In certain situations, a conversion takes place, i.e. tab characters are expanded into blanks and end-of-line characters are eliminated. Depending on the situation (inbound, outbound) and the participating partners, the following applies:
Inbound requests:
Conversion to Unix or Windows is not available for send or receive operations on the inbound side.
Outbound requests issued by a Unix or Windows system:
Conversion never occurs when receiving requests.
Request-specific conversion (ft -tb= and ncopy -tb=, TabExpansion) is possible on send operations. By default, send operations to BS2000, OS/390 or z/OS partners are converted. In all other cases conversion does not take place.
Outbound requests which are issued in a BS2000, OS/390 or z/OS system:
Conversion never occurs when sending requests.
Conversion occurs when receiving requests, depending on the partner, i.e. conversion occurs for a Unix or Windows partner but not for BS2000, OS/390 or z/OS partners.
Binary format
openFT assumes that the file to be transferred contains an unstructured sequence of binary data. In the receiving system, a file is created with an undefined record length. The binary data is retained.
User format
When sending, openFT assumes that the file to be sent is structured by length fields in records. The first two bytes of each record must contain the length of that record, including the length of the record length field. When retrieving, openFT generates these length specifications in accordance with the record lengths in the remote system. The record contents are handled as binary data, i.e. not subjected to code conversion.
The record structure and the binary data are retained during transfer. The highest-order byte of the record length field is stored first in a Windows system.