openFT prüft bei jedem File-Transfer- und File-Management-Auftrag
die Zugangsberechtigung des Benutzers zum System
die Zugriffsberechtigung des Benutzers auf die betroffene Datei
falls bei einem File-Transfer-Auftrag eine Vor-, Nach- oder Folgeverarbeitung angestoßen werden soll: die Berechtigung des Benutzer dazu
Der Benutzer muss die entsprechenden Berechtigungen durch die Angaben nachweisen, die er in den Operanden TRANSFER-ADMISSION und PROCESSING-ADMISSION für das jeweilige System macht. Transfer-Aufträge, in denen ausreichende Berechtigungen nicht nachgewiesen werden, werden abgelehnt.
Wenn FTAC nicht genutzt wird, muss der Benutzer in der TRANSFER-ADMISSION bzw. der PROCESSING-ADMISSION direkt die für die Prüfungen notwendigen Angaben machen (LOGON-Kennung, bestehend aus Benutzerkennung, Abrechnungsnummer und Kennwort). Wenn FTAC genutzt wird, kann statt der LOGON-Kennung eine in einem Berechtigungsprofil definierte TRANSFER-ADMISSION angegeben werden. FTAC entnimmt dann dem zugehörigen Profil die für die Prüfungen benötigten Angaben (d.h. die LOGON-Kennung, bestehend aus Benutzerkennung, Abrechnungsnummer und
Kennwort).
openFT prüft die Zugangsberechtigung des Benutzers mittels RACF-Aufrufen oder gegen die Einträge in der System-Datei SYS1.UADS, die Zugriffsberechtigung ebenfalls mittels RACF-Aufrufen bzw. durch Aufruf des PROTECT-Makros. Näheres siehe unten. Zu diesem Zweck muss openFT APF-autorisiert sein (siehe Abschnitt „Privilegierung von openFT“) oder die READ-Berechtigung auf SYS1.UADS besitzen. Es ist sichergestellt, dass openFT weder auf die SYS1.UADS noch auf Listen von RACF schreibend zugreift.
Da alle RACF-Aufrufe über den RACROUTE-Makro geführt werden, ist es möglich, am MVS-Router-Exit eine installations-spezifische MVS-Exit-Routine anzuschließen oder ein zu RACF kompatibles Software-Produkt wie z.B. ACF-2 oder TOP-SECRET zu verwenden. (Beim Anschluss von TOP-SECRET ist zu beachten, dass sich openFT gegenüber TOP-SECRET als "OSFSUBT" meldet, d.h. es muss "PGM=OSF" angegeben werden.)
Welche Voraussetzungen seitens eines RACF-kompatiblen Software-Produktes erfüllt sein müssen, damit openFT die Zugangs- und Zugriffsberechtigungen über dieses Produkt durchführen kann, entnehmen Sie bitte den Manualen zum jeweiligen Produkt.
Die Schnittstelle des MVS-Router-Exits ist im IBM-Manual "System Programming Library: Resource Access Control Facility (RACF)" beschrieben.
openFT greift auf die Datei SYS1.UADS über den DD-Namen DDUADS zu (siehe die entsprechenden DD-Statements in den Beispielen im Abschnitt „openFT als Job oder als Started Task“). openFT prüft nur bei der Bearbeitung des ersten Transfer-Auftrags nach
dem Laden und Starten des openFT-Lademoduls, ob die Datei SYS1.UADS verfügbar ist. Ist das nicht der Fall (DD-Statement fehlt, Datei ist nicht vorhanden oder nicht lesbar), dann greift openFT bis zur Beendigung des openFT-Lademoduls nicht mehr auf die SYS1.UADS zu; die SYS1.UADS wird bei der Bearbeitung aller folgenden Transfer-Aufträge als nicht verfügbar betrachtet.
Hinweise
Findet die Ablehnung des Transfer-Auftrags noch im Verlauf der synchronen Kommandobearbeitung statt, dann wird das NCOPY-Kommando mit dem Return-Code X'0C' beendet. Das gilt auch für die NCOPY-Programmschnittstelle.
Ob nach einer Ablehnung des Transfer-Auftrags eine Folgeverarbeitung (FAILURE-PROCESSING) stattfindet, hängt davon ab, in welchem FT-System der Transfer-Auftrag abgelehnt wird:
Wird der Transfer-Auftrag schon von der lokalen openFT-Instanz abgelehnt, findet in keinem der beiden beteiligten FT-Systeme eine Folgeverarbeitung statt.
Wird der Transfer-Auftrag erst vom fernen System abgelehnt, so findet im fernen System auch keine Folgeverarbeitung statt. Im lokalen System wird in diesem Fall die Folgeverarbeitung für den Fehlerfall (FAILURE-PROCESSING) angestoßen.
Ob der Transfer vom lokalen oder fernen System abgelehnt wurde, geht aus der ausgegebenen Meldung (z.B. FTR2047, FTR2169) hervor.