Please note that the destination file is generally not protected from being overwritten by other users while the time the request is being processed. If the transfer is interrupted, for example, then other users may be able to write to the destination file. Access protection differs in the individual systems:
BS2000 systems
openFT (BS2000) uses a file lock which protects the files if the transmission is interrupted and between the time of accepting and processing the FT request. This protection does not apply to library members and POSIX files.
When a file transfer request is accepted, a lock is set on each file to be transferred. Only read access is granted to other users for the send files; no access is permitted for the receive files. The BS2000 command SHOW-FILE-LOCK indicates whether a file has been locked by openFT and lists the transfer ID’s involved. File locks are automatically removed on unloading the subsystem.
The mode of operation of openFT dictates that a receive file which already exists can only be overwritten if both read and write access are available for this file. For file access, the specifications of the ACL (Access Control List) and BASIC-ACL must be adhered to.
The following table shows the conditions under which the FT user can access a BS2000 file:
Access mode | Conditions for file access |
Read of a sending file |
|
Overwrite an existing |
|
z/OS systems
openFT (z/OS) protects send and receive files against simultaneous (write) accesses only if data is in fact being transferred, i.e. if the request is in the ACTIVE state. It follows, that the send and receive files are not protected, if the file transfer has not yet begun or has just been interrupted.
If openFT attempts to access a send or receive file which is locked (for example, because another FT job is already accessing it), the FT job is rejected or terminated.
For a member of a PO or PDSE data set, this means:
When a member of a PO or PDSE data set is to be read (send file), no other member of the same data set may be open for writing or only for reading when the request is issued, nor be opened before the end of the file transfer.
When a member of a PO or PDSE data set is to be written (receive file), neither another member of the same data set, nor the data set itself may be open when the request is issued or opened before the end of the file transfer. In this case (receive file), even the display of the member list can cause the FT job to be aborted (for example when a send request is started from the menu interface, see manual "openFT (z/OS) - Command Interface", or the use of the PDF function "member list" in general).
When an FT request is aborted because of an attempt to access a locked file, an error message is output.
Other systems
In other systems, for example Unix and Windows systems, or even in BS2000 systems in the case of POSIX file or library elements, the user is solely responsible for guaranteeing exclusive access to the files to be transferred . In these systems, the file cannot be occupied exclusively by openFT, not even during file transfer.
The user him/herself must therefore ensure that (the data and file attributes) in the file to be transferred are consistent throughout the entire duration of the FT request. This applies to both the send and receive files. The danger of eventual inconsistencies resulting from multiple accesses can be reduced, for example, by means of access restrictions (Unix system: chmod command). It is also possible to transfer the file to a different name or to a temporary directory and to rename it or move it to a different directory only after file transfer has been completed successfully using follow-up processing.