For each file transfer request and file management request, openFT checks
the user's access authorization to the system (transfer admission)
the user's access authorization to the relevant file
if preprocessing, postprocessing or follow-up processing is to be triggered following a file transfer request: the user's authorization to do so.
Users must demonstrate their authorization by means of the specifications they make in the TRANSFER-ADMISSION and PROCESSING-ADMISSION operands for the system involved. Transfer requests in which authorization is not demonstrated satisfactorily are rejected.
If FTAC is not used, the user must make the entries required for checking his transfer admission directly in TRANSFER-ADMISSION or PROCESSING-ADMISSION (i.e.
LOGON ID consisting of user ID, account number and password). If FTAC is used, a TRANSFER-ADMISSION defined in an admission profile can be specified instead of the LOGON ID. FTAC will then read the information needed for the admission check from the relevant profile (i.e. the LOGON ID consisting of user ID, account number and password).
openFT checks the user's transfer admission using RACF calls or against the entries in the MVS system file SYS1.UADS. Transfer admission can also be checked using RACF calls or by calling the PROTECT macro (for more information, see below). To this end, openFT must be assigned APF authorization (see the section “openFT privileges”) or read access to SYS1.UADS. openFT does not have write access to SYS1.UADS or to RACF lists.
Since all RACF calls are handled by the RACROUTE macro, it is possible to connect an installation-specific MVS exit routine to the MVS Router exit or to use an RACF-compatible software product such as ACF-2 or TOP-SECRET (If TOP-SECRET is used, openFT identifies itself to TOP-SECRET as "OSFSUBT", i.e. "PGM=OSF" must be specified).
Information on the requirements which must be met by an RACF-compatible software product in order to enable openFT to perform system and data access control via this product is given in the product-specific manuals.
The interface of the MVS Router exit is described in the IBM manual "System Programming Library: Resource Access Control Facility (RACF)".
openFT accesses the file SYS1.UADS via the DD name DDUADS (see the corresponding DD statements in the examples in the section “openFT as a job or started task”). openFT checks whether the file SYS1.UADS is available; this check is carried out only during processing of the first transfer request after loading and starting the openFT load module. If this file is not available (DD statement is missing, file is not available or not readable, etc.), openFT no longer accesses the SYS1.UADS file until termination of the openFT load module. During the processing of all subsequent transfer requests, the SYS1.UADS file is considered to be unavailable.
Notes
If the transfer request is rejected during synchronous command processing, the NCOPY command is terminated with the return code X'0C'. This also applies to the NCOPY program interface.
Whether or not follow-up processing takes place following rejection of a transfer request (FAILURE-PROCESSING) depends on which FT system rejects the transfer request:
If the transfer request is rejected by the local openFT instance, no follow-up processing takes place in either of the two FT systems involved.
If the transfer request is rejected in the remote system, no follow-up processing takes place in the remote system. In this case, the follow-up processing for unsuccessful file transfer (FAILURE-PROCESSING) is initiated in the local system.
The message that is issued (e.g. FTR2047, FTR2169) indicates whether the local or remote system rejected the transfer request.