Besides complete transfer of the contents of a file, file transfer also aims at producing an authentic representation of the file structure. If identical structures are mapped to each other, as is the case with homogeneous links, authenticity is achieved without any problem, i.e. the binary code and the character representation are identical in the send and receive system. With heterogeneous links, however, it is usually not possible to obtain the binary code and the character representation in the receive system unchanged. For this reason, a distinction is made between text and binary transfer for file transfer with openFT. More details on file transfer with FTAM partners ca be found in the section "Special points for filetransfer with FTAM partners".
Text transfer
Text transfer is character-oriented, i.e. the presentation of the characters is retained. This applies both to characters in single-byte code such as ISO 8859 and to Unicode characters which are represented by multiple bytes. The record structure of the text file is matched to the system conventions of the receive system when the file reaches the receive system.
The “useful data” of a file to be sent per text transfer must not contain any characters which the receive system could interpret as control characters, e.g. X‘15‘ (EBCDIC linefeed) and X‘0A‘ (ASCII linefeed).
The following table show the allowed settings for text transfer:
Record structure in | Local system | Remote system | Direction | file type/ |
system-conformant | BS2000:DVS, PLAM | BS2000: DVS, PLAM | <-- / --> | Standard |
BS2000: DVS, | BS2000: POSIX, | <-- / --> | Standard | |
Unix system or | BS2000, z/OS | <-- / --> | Standard | |
Unix system or | Unix system or | <-- / --> | Standard |
For details on z/OS, please refer to the manual "openFT (z/OS) - Command Interface".
Binary transfer
Binary transfer is carried out such that the coding (binary representation) of the characters is retained. The design of the record structure can be controlled. In this way, openFT matches the record structure with the record structure of the receive system (systemconformant record structure). With the original record structure, the structure of the send system is retained. Furthermore, it is possible to employ your own system-dependent record structures using the FT-specific user format.
The following table show the allowed settings for text transfer :
Record structure in | Local system | Remote system | Direction | file type/ |
system-conformant | BS2000: DVS, PLAM | DVS, PLAM, z/OS | <-- / --> | Standard |
BS2000: DVS, PLAM | POSIX | <-- / --> | Standard | |
BS2000: POSIX | POSIX | <-- / --> | Standard | |
BS2000: POSIX | z/OS | <-- | text | |
Unix system or | Unix system or | <-- / --> | Standard | |
original record structure | BS2000: POSIX | DVS, PLAM | --> | binary |
BS2000: POSIX | Unix system or | <-- / --> | binary | |
BS2000: DVS, PLAM | Unix system or | <-- | binary | |
Unix system or | DVS, PLAM, z/OS | --> | binary | |
Unix system or | POSIX, Unix system or | <-- / --> | binary | |
User format | BS2000: DVS, PLAM | POSIX | --> | user |
BS2000: DVS2, | Unix system or | --> | user | |
BS2000: POSIX | Unix system or | <-- | user | |
Unix system or | DVS, PLAM, POSIX, | <--3 | user | |
No record structure | BS2000: DVS, PLAM | POSIX, Unix system or | --> | binary |
Unix system or | DVS, PLAM, z/OS | <-- | binary |
1<-- = fetching, --> = sending
2applies only for SAM files with variable record length (RECFORM=V)
3A file can be sent in user format provided that the file has been fetched in user format
ISAM and PAM files can be transferred between BS2000 systems and other systems as follows:
in transparent format, see "Transfer of various file types"
by specifying the target format, see the section "Heterogeneous transfer of PAM and ISAM files"
For details on z/OS, please refer to the manual "openFT (z/OS) - Command Interface".
Record by record transfer
Local Unix system or Windows system
When transferring files between Unix or Windows and BS2000 systems the structure of records can be important. If files are transferred from a Unix or Windows system to a DMS file, then you must increase the maximum record length if the block sizes generated by default for the DMS files are insufficient to accept the longest record. This is generally the case as of a net record length of 2024-2040 bytes.
Local BS2000 system
When DMS files are transferred between BS2000 systems, the file structure is not usually considered (the files are transferred block-by-block). The file’s record structure is significant in the following cases (the files are transferred record-by-record):
transfer between BS2000 and Unix systems, Windows or z/OS
extension of a file with a record structure
transfer of POSIX files
transfer of library members
In these cases, the maximum length of the records that are to be transferred should not exceed the following values:
Partner systems with openFT V10 and higher:
32768 bytes in files with fixed-length records
32760 bytes in files with variable-length records
Partner systems with openFT < V10:
32760 bytes in files with fixed-length records
32758 bytes in files with variable-length records
32248 bytes for compressed transfer (COMPRESS = *BYTE)
If files are transferred from Unix systems, Windows or POSIX to a DMS file then the maximum record length without the specification of the RECORD-SIZE parameter in the command may not exceed (2048*b-n) bytes, where b is the blocking factor of the BS2000 receive file. Default on NK-PVS disks is b=2, otherwise the default is b=1.
On K-PVS (K for Key) n=8, and on NK-PVS (NK for Non Key) n=20.
Local z/OS system
openFT (z/OS) usually takes into account the record structure during file transfer (exception: transfer of an unstructured sequence of binary data during file transfer with Windows and Unix systems). With record-by-record transfer the maximum length of the records to be transferred may not exceed the following values:
32760 byte in files with fixed-length records
32752 byte for files with variable record lengths (record length without record length field)
32248 byte for compressed transfer (COMPRESS = *BYTE)
Transfer with transparent file format
A special case is the transparent file format. This file format provides you with the option of passing through any BS2000 files over a variety of FT platforms to a BS2000 system, while retaining their original file attributes. This procedure is useful for distributing BS2000 files from a Unix based server or Windows server to BS2000 systems, for example. From the point of view of the intermediate processor, the files received, which cannot be used by this processor, are binary files. These files are then set up on the receive processor with their original attributes by openFT (BS2000).
Specific features in z/OS
openFT (z/OS) can act as a buffer for BS2000 files in transparent file format. However the transfer of these files must be initiated in the BS2000.
openFT does not provide any direct means of transferring z/OS files true-to-format (“transparent”) over FT platforms other than z/OS. However, you can use the TSO command XMIT to pack files in a neutral format and transfer them in this format as binary files with a fixed record length of 80 bytes. You do this, for example, by specifying -r=f80 in the openFT ft command in Windows or on a Unix system. The file can then be unpacked at the target system using the TSO command RECEIVE.
Heterogeneous transfer of PAM and ISAM files
You can transfer BS2000 PAM files onto a foreign system such as a Unix or Windows system or to z/OS and then retrieve them to BS2000 and store them there as PAM files. The foreign system can also have the initiative for this request. You can also transfer ISAM files from a BS2000 systems onto a foreign system. In all cases, the prerequisite for this is that openFT as of V11 is running on the foreign system.
To do this, proceed as follows:
Transferring a PAM file from BS2000 to a foreign system
Specify "sequential" as the target format in the transfer request. The file content is transferred without the end-of-file marker of the C runtime system and empty blocks are initialized.
The content of the PAMKEY and the architecture of the pubset are not transferred to the target system.Storing a binary file from a foreign system as a PAM file in BS2000
Specify "binär" as the file format and "block-structured" as the target format in the transfer request. All blocks apart from the final one are completely filled with data and the end-of-file marker of the C runtime system is appended at the end.If you transfer PAM files out of BS2000 and fetch them back again, the original pubset and the target pubset should, wherever possible, have the same block properties. If this is not the case, or if the content of the PAM keys is important for the file, you have to assume that the target file will become unusable. In the case of PLAM libraries, it is generally possible to retain the format during transfer. If the target pubset is NK4, the PLAM library must be converted with PAMCONV.
If a PAM file that has been swapped out is to be transferred back to a BS2000 system with openFT V10, it is stored as a sequential file with an undefined record format. The request is rejected under openFT with a Version < V10.
It is not possible to extend a PAM file by fetching a file from the foreign system.
Transferring an ISAM file to the foreign system
Specify "sequential" as the target format in the transfer request. The ISAM keys are integral parts of the records that are read and are therefore transferred with the file. However, they no longer have any function as index keys. The record format of the target file is to be the same as that of the ISAM file. The format used is compatible with FTP-BS2000.