Prior to version V8.0, FT products in BS2000 protected a file to be transferred only during the active transmission, i.e., when the file was opened by openFT using DVS. Consequently, if the transmission was interrupted or even if the transmission had not yet begun, both files involved could be potentially accessed and modified. Such changes could not always be detected on restarting openFT, thus resulting in the creation of inconsistent receive files.
As of V8.0, openFT uses an operating system mechanism to protect transfer files (however, this protection is not possible for library elements and Posix files):
When a file transfer request is accepted, a lock is set on each file to be transferred as early as possible. Only read access is granted to other users for the send files; no access is permitted for the receive files.
This lock remains set - so long as the FT subsystem is loaded - until the request has completed.
The BS2000 command SHOW-FILE-LOCK indicates whether a file has been locked by openFT and, if it is, shows the transfer ID (or, when sending, possibly a list of transfer IDs) of the request involved. Such locks, and other file locks as well, can be reset by the system administrator at his/her own discretion in emergency situations by using the command REMOVE-FILE-ALLOCATION.
Using SHOW-FILE-TRANSFER ... PUBSET=, the FT administrator can have all the requests displayed that have locked files on a defined pubset. The administrator can selectively delete these requests using CANCEL-FILE-TRANSFER ... PUBSET=.
On unloading an FT instance (STOP-SUBSYSTEM FT or DELETE-FT-INSTANCE), all the locks held by openFT are cleared and reset upon reload (START-SUBSYSTEM FT or CREATE-FT-INSTANCE) for all files affected by existing requests. For information on what the FT or system administrator must therefore take into consideration, see section “Starting and stopping openFT”.
In addition to this mechanism, openFT also implicitly checks the integrity of the transferred data by communicating with openFT partners version V8.1 and later. The scope is defined in the transfer request:
In the case of requests with encryption, the transferred file content is also checked(TRANSFER-FILE ... DATA-ENCRYPTION = *YES).
In the case of requests without encryption, an integrity check of the file content can be activated explicitly
(TRANSFER-FILE ... DATA-ENCRYPTION = *ONLY-DATA-INTEGRITY.If neither encryption nor the integrity check are activated then only the integrity of the request description data is checked
(TRANSFER-FILE ... DATA-ENCRYPTION = *NO).
If an error is detected then restartable requests attempt the transfer again. Requests that cannot restart are aborted.