openFT (z/OS) can transfer the following types of files:
PS datasets including absolute and relative file generations
Members of PO and PDSE datasets (with the exception of object modules and programs)
VSAM files of type “entry-sequenced”
openEdition files (files belonging to the z/OS Unix Systems Services)
Migrated files, i.e. files swapped out with HSM.
The transfer of these files is performed sequentially. The files can be transferred homogeneously between two z/OS systems or heterogeneously with a non-z/OS system or a non-z/OS system. For homogeneous file transfer, all file types can be mapped to one another. Between z/OS and other platforms (heterogeneous link) it is possible to transfer files if the remote system also supports sequential files. With BS2000 systems, for example, SAM files and PLAM elements of the appropriate type can be exchanged.
The transfer of complete PO and PDSE datasets can only take place between two z/OS systems.
z/OS files may be located either on common disks or on private disks. For processing of files on private disks, the files must be cataloged and private disks must be properly connected to the system. For the processing of files on private media, the precondition is that the files are cataloged and that the private data medium has been properly connected to the system.
Please note that at the command interface, a c string must also be entered in the form C’...’ as otherwise (without the C) openFT would try to interpret the string as a fully qualified z/OS file name.
Primary and secondary allocation
When openFT receive files are created in z/OS, the primary allocation approximately corresponds to the (possibly estimated) size of the send file (at least 42 kilobytes, however) plus 128 kilobytes (DEFFSIZE/20). The secondary allocation approximately corresponds to a quarter of the size of the send file plus 512 kilobytes (DEFFSIZE/5). DEFFSIZE is a constant that is set to 2621440 by default. It can be modified by making an appropriate entry in the PARM member of the parameter library. See the manual "openFT (z/OS) - Installation and Operation".
If a PO/PDSE file is created by generating a member, the primary allocation is twice the size of the send file (at least 42 kilobytes, however) plus 256 kilobytes (DEFFSIZE/10). The secondary allocation is slightly less than twice the size of the primary allocation.
If the size of the send file is unknown to openFT internally (e.g. in the case of a file transfer with preprocessing and/or preprocessing using the FTEXEC command respectively), or if the size of the send file is not passed to the z/OS receiving system with the protocol used (as is the case, for example, with the FTP protocol), the primary allocation for the receive file in z/OS is 256 kilobytes (DEFFSIZE/10) and the secondary allocation is 2560 kilobytes (DEFFSIZE).
In the case of very large files, it is not always possible to reserve the entire space with a primary allocation, and there are also restrictions for secondary allocations. These limits depend partly on the hardware properties of the disks (a maximum of 65535 tracks per file on a volume) and partly on the current disk occupancy (in the case of multivolumes). For this reason, it is possible to restrict the maximum size of an allocation (both primary and secondary) to a maximum value MAXALLOC. See the manual "openFT (z/OS) - Installation and Operation". If the allocations calculated using the method described above do not exceed this threshold, MAXALLOC is of no significance.
Encoding
In z/OS systems, the content of text files is coded in EBCDIC. However, the conventional IBM EBCDIC variants differ from EBCDIC.DF.04; in particular, this affects language-specific special characters (e.g. "ä", "ö", "ü") and other special characters (e.g. "[", "]", "{", "}") which may be located at different positions of the code table in the different EBCDIC variants. openFT provides a range of character sets (code tables), and if necessary, a specific character set can be assigned to each file; see manual "openFT (z/OS) - Installation and Operation". Code conversion is performed by openFT, for instance between EBCDIC.DF.04 and IBM1047. This means that the FT administrator does not need to create any code conversion tables. It is, however, possible to set up your own code tables if the character set you require is not provided by openFT itself or by one of the supplied code tables.
A complete PO/PDSE data set is not converted if openFT as of V10 is used in the sending system. If this is not the case, steps should be taken to make sure that no conversion is carried out, otherwise it is possible that the control information in the destination file may no longer be correct.
The following files cannot be transferred by openFT:
Files with the attribute “unmovable” (data organization PSU)