1.  Zentrale Prüfroutine USRMOD
Die Prüfroutine von CFS (Modul USRMOD) wird nach jeder Maskeneingabe durchlaufen und prüft die Eingaben. Bestimmte CFS-Funktionen können damit einem engeren Kreis von besonders autorisierten Benutzern zur Verfügung gestellt werden. Die Prüfung, ob eine CFS-Funktion einem Benutzer zur Verfügung steht, erfolgt tabellengesteuert. Die vom Systemverwalter zu modifizierenden Tabellen stehen sich im Datenteil der Prüfroutine USRMOD. Als für den Betrieb von CFS Verantwortlicher sollten Sie das Assembler-Quellprogramm USRMOD (gespeichert in der CFS.S.LMSLIB) genau studieren.
Beschreibung der Prüftabellen
Für jedes Eingabefeld einer Maske gibt es eine entsprechende Prüftabelle in USRMOD:
Selektionsmaske
Feld Filename-Select TAB01
Feld User-Id TAB02
.........
Feld Variable Action TAB0C
Maske der Dateienliste/CFS-Editor
CFS-Kommandos TAB10
Action-Codes TAB11.
Jede Benutzereingabe in einem Feld einer CFS-Maske wird mit den in den entsprechenden Tabellen enthaltenen Mustereingaben verglichen. Bei Übereinstimmung wird aufgrund der User-Id-Tabelle (siehe unten) entschieden, ob die Eingabe unter der aktuellen User-Id erlaubt ist oder nicht (Authority-Reject).
Die Prüftabellen sind wie folgt aufgebaut:
Im Tabellenkopf befindet sich ein Default-Indikator, der festlegt, was zu geschehen hat, wenn die aktuelle Eingabe in der Prüftabelle für das Maskenfeld nicht enthalten ist (Eingabe akzeptieren bzw. zurückweisen). Im Anschluß an den Tabellenkopf folgen beliebig viele Tabellenelemente, die den zu prüfenden Benutzereingaben zugeordnet sind.
Struktur eines Tabellenelements
DC   AL1(len) Gesamtlänge des nachfolgenden Tabellenelements.
DC   C'ind' Indikator
C'_' der folgende String ist als Eingabe erlaubt.
C'-' der folgende String ist als Eingabe nicht erlaubt und führt zu einem Authority-Reject.
C'R' Es wird ein benutzerspezifischer Code zur Behandlung dieser Eingabe durchlaufen. Auf C'R' folgt unmittelbar die vier Byte lange Adresse der Unterroutine zur Behandlung der Eingabe.
DC   AL4(Sonderroutine) Nur falls ind = C'R': Adresse einer Unterroutine innerhalb von
USERMOD, die bei Tätigung der unten angegebenen Eingabe an
gesprungen wird.
DC   AL4(User-id Tab) optionale Adresse einer alternativen User-Id Tabelle für die aktuelle
Eingabe (Funktion der User-ID-Tabelle: siehe unten).
DC   C'string' Muster der Benutzereingabe.
Das Zeichen '*' wird als Beliebigkeitszeichen gewertet und hat zur Folge, daß an den entsprechenden Stellen in string ein beliebiges Zeichen stehen kann. Z.B. steht C'OC*' für die Benutzereingaben OC0, OC1, ..., OC9.
User-ID-Tabellen
Neben den Prüftabellen für die Benutzereingaben existieren User-Id Tabellen. Eine User-Id Tabelle enthält eine Gruppe von Benutzerkennungen. Bei Übereinstimmung der Eingabe in einem Maskenfeld mit einem in der entsprechenden Prüftabelle (siehe oben) angegebenen Muster wird aufgrund der User-Id Tabelle entschieden, ob die Eingabe unter der aktuellen User-Id erlaubt ist oder nicht (--> Authority-Reject). Am Anfang jeder User-Id Tabelle steht ein Default-Indikator. Dieser bestimmt, wie zu verfahren ist, falls CFS unter einer nicht in der User-Id Tabelle aufgeführten Benutzerkennung aufgerufen wurde (Eingabe akzeptieren / zurückweisen).
Neben den in der Standard User-Id Tabelle zusammengefaßten Benutzerkennungen können beliebig viele weitere Gruppen von Benutzerkennungen in sog. alternativen User-Id Tabellen definiert werden. Für jede in einer Prüftabelle aufgeführte Mustereingabe kann im Prinzip eine eigene User-Id Tabelle verwendet werden.
Aktivierung der USRMOD-Prüfungen
Die Prüfroutine USRMOD ist standardmäßig und aus Performancegründen nicht aktiviert und wird von CFS daher nicht aufgerufen. Um USRMOD zu aktivieren, kann in der gebundenen Programmphase CFS im 6-ten PAM-Block an der Spalte 49 das Zeichen 'X' eingetragen werden.
Eine weitere Möglichkeit zum Aktivieren von USRMOD sowie zum Modifizieren einer Anzahl weiterer Installationsparameter von CFS besteht darin, das Assembler Quellprogramm CFSMAIN in der CFS.S. LMSLIB den eigenen Erfordernissen entsprechend anzupassen. I.A. sind lediglich die Kommentarsterne bei den MVI-/MVC-Anweisungen zu entfernen. Der modifizierte CFSMAIN ist anschließend durch den Prozeduraufruf /DO CFS.S.LMSLIB(ASSEMB) zu übersetzen. Zum Schluß muß mit Hilfe des Kommandos /DO CFS.S.LMSLIB(CFSLNK) eine neue Programmphase erzeugt werden.
Zusammenfassung
Der Systemverantwortliche kann mit Hilfe des Prüfmoduls USRMOD eine Reihe von Eingabemöglichkeiten zusammenstellen. Für jede dieser Eingaben kann eine Gruppe von User-Ids festgelegt werden, unter denen die Eingabe erlaubt bzw. nicht erlaubt ist (Authority-Reject).
Da alle Benutzereingaben über die Prüfroutine USRMOD laufen, bevor sie von CFS interpretiert und ausgeführt werden, können Eingaben des Benutzers im USRMOD auch abgeändert werden.
2.  Datenschutz auf Benutzerebene
CFS trägt den Erfordernissen des Datenschutzes durch die im folgenden beschriebenen Einrichtungen Rechnung.
Eröffnen einer Connection: Bei Nachforderung des Logon-Passworts durch das BS2000 (PLEASE ENTER PASSWORD) wird dieses nicht in das Kommandogedächtnis der Connection eingetragen.
Bei Eingabe eines vollständigen LOGON-Kommandos inklusive Passwort nach OCn und 'PLEASE LOGON' wird das Passwort im Kommandogedächtnis der Connection mit C'SSS' überschrieben.
Einzelne Einträge des Kommandogedächtnisses (z.B. PASSWORD-Kommandos) können vom Benutzer explizit aus dem Gedächtnis gelöscht werden. Dies geschieht durch Betätigen der K3-Taste beim einzelschrittweisen Zurückgehen im Gedächtnis.
Connections: LOG-Dateien, die aufgrund der Eingabe LOG datei von CFS angelegt werden, sind grundsätzlich nicht shareable. Beim Logging in Nebenprozessen unter einer anderen Kennung oder auf einem anderen Host werden die LOG-Dateien stets unter der eigenen Benutzerkennung, d.h. dort wo CFS geladen wurde, angelegt.
LOCK: Sperren des Bildschirms bei kurzzeitiger Abwesenheit des Benutzers.
LOCK [passw] Der Bildschirm, an dem CFS geladen ist, wird gesperrt, bis der Benutzer im dunkel gesteuerten Feld das vereinbarte Lock-Passwort eingegeben hat. Der Benutzer kann sich von seinem Bildschirm entfernen, ohne daß eine andere Person in der Lage wäre, mit dem geladenen CFS weiter zu arbeiten, Connections zu benutzen oder im aktuellen Kommandogedächtnis zu blättern.
Wurde passw im LOCK-Kommando weggelassen, so gilt das zuletzt über SPL oder LOCK [passw] definierte Passwort.
SPL [passw] Set Password for Lock.
Es wird ein Passwort für ein später folgendes LOCK-Kommando definiert. Wird passw im SPL-Kommando weggelassen, so wird das Passwort in einem dunkel gesteuerten Feld angefordert.
3.  Datenschutzmaßnahmen mittels USRMOD/CFSMAIN
CFS bietet den Systemverantwortlichen an verschiedenen Stellen Hilfen, die es ihm gestatten, das Verhalten der Benutzer unter CFS zu kontrollieren, zu protokollieren und in bestimmten Bereichen auch einzuschränken.
Eine Instanz zur Kontrolle der Benutzereingaben ist der Prüfmodul USRMOD. Falls die i.f. beschriebenen Einrichtungen für Ihr Rechenzentrum gewünscht werden, so sind diese im ausgelieferten Quellcode des Prüfmoduls USRMOD zu aktivieren. USRMOD muß anschließend neu assembliert und in die CFSLIB gebracht werden. Außerdem ist in der Programmphase CFS mit Hilfe eines Indikators (siehe auch Quellprogramm von CFSMAIN in der CFS.S.LMSLIB) der Ansprung des USRMOD durch CFS zu aktivieren.
Modify von PAM-Dateien nur gegen Eingabe eines Passworts
Falls der Benutzer unter einer Kennung verschieden von TSOS mit CFS arbeitet und eine im Display angezeigte PAM-Datei modifizieren möchte (Modify-Kommando), so muß er zuvor in einem dunkel gesteuerten Eingabefeld ein CFS-internes, vom CFS-Administrator änderbares Berechtigungspasswort eingeben. Dieses CFS-interne Passwort ist an der entsprechenden Stelle im Quellprogramm des Moduls USRMOD zu ersehen. Nach zweimaliger Falscheingabe des Passworts wird die Funktion abgewiesen (Authority-Reject). Um die Routine R100 zur Passwortanforderung zu aktivieren, sind in TAB10 von USRMOD in allen Statements die Kommentarmarkierungen '*2*' zu entfernen. Die vorbereitete Routine R100 kann dahingehend abgeändert werden, daß das Passwort beim Modify von Dateien mit bestimmten, in einer Tabelle abgelegten Namen angefordert wird.
Selektion durch FSTAT $user-id. im Feld FILENAME-SELECT unterbinden
Falls der Benutzer nicht unter TSOS arbeitet und über FSTAT $user-id bzw. FSTAT :x:$user-id Dateien einer fremden Kennung selektieren möchte, so wird dieser Selektionswunsch von CFS abgewiesen. Um die Routine R300 zur Prüfung der Filename-Select Eingabe auf FSTAT und anschließendes $-Zeichen zu aktivieren, sind in TAB01 von USRMOD in allen Statements die Kommentarmarkierungen '*3*' zu entfernen.
Selektion von Dateien auf festgelegten fremden Kennungen über das Feld USER-ID unterbinden
Falls der Benutzer nicht unter TSOS arbeitet und über das Feld USER-ID Dateien aus "verbotenen" Kennungen (definiert in der Tabelle R400TAB) selektieren möchte, so wird dieser Selektionswunsch von CFS abgewiesen. Um die Routine R400 zur Prüfung der Eingaben im Feld USER-ID zu aktivieren, sind in TAB02 von USRMOD in allen Statements die Kommentarmarkierungen '*4*' zu entfernen.
Virtuelle Terminalnamen für Connections entsprechend den physikalischen Stationsnamen
Standardmäßig bildet CFS die virtuellen Stationsnamen für Connections nach folgender Regel:
CFS n xxxx.
n ist dabei die Nummer der im OC-Kommando angegebenen Connection (0 <= n <= 9) und xxxx die TSN des Prozeßes, in dem das Programm CFS aufgerufen wurde. Diese virtuellen Terminalnamen erlauben keinen direkten Rückschluß auf die physische Datensichtstation, an die der Nebenprozeß gebunden ist (= physische Datensichtstation, an der CFS aufgerufen wurde).
Um eine klare Beziehung zwischen den unter CFS eröffneten Nebenprozessen und den zugehörigen physischen Datensichtstationen herzustellen, ist eine Unterroutine (R200) im Modul USRMOD vorbereitet.
Hierbei wird davon ausgegangen, daß die Bezeichnung aller Datensichtstationen an irgendeiner Stelle des acht Byte langen Namens ein bzw. zwei redundante, d.h. stets gleichbleibende Zeichen aufweist. Z.B. könnten die Bezeichnungen der Datensichtstationen mit einem konstanten Prefix beginnen. Es folgt ein variabler Teil, mit dem die Datensichtstationen eine fortlaufende Nummerierung erhalten.
Wir nehmen an, daß die Stationsnamen aller Datensichtgeräte lauten: DSSxxxxx. xxxxx ist hierbei der wesentliche, nicht redundante Namensbestandteil, über den jede Datensichtstation eindeutig identifiziert wird.
Die Routine R200 im Modul USRMOD bildet die Namen der an einem bestimmten Datensichtgerät eröffneten Nebenprozesse (Connections) nach folgender Regel: Der ursprüngliche Stationsname DSSxxxxx wird zu #nSxxxxx abgeändert. Dies bedeutet, daß die ersten beiden redundanten Stellen des ursprünglichen Stationsnamens ('DS') durch die Zeichen '#n' ersetzt werden. n ist hierbei die Nummer der im OC-Kommando gewählten Connection.
Die Routine R200 tauscht auch einen vom Benutzer im OC-Kommando explizit angegebenen Stationsnamen gegen einen Namen der oben beschriebenen Bildung aus. Der Benutzer hat somit keine Chance, einen von ihm selbst gewählten virtuellen Terminalnamen für einen CFS-Nebenprozeß zu vergeben. Diese Art der zwangsweisen Namensvergabe hat nebenbei noch den Vorteil, daß in einer Connection n, CFS durchaus wieder geladen werden kann. In diesem neuen CFS der Stufe 1 kann mit OCn aber nicht wieder eine Connection n eröffnet werden, da dies eine doppelte Verwendung des gleichen Stationsnamens bedeuten würde.
Der Austausch der Stationsnamen wird standardmäßig nur bei Connections zu $DIALOG vorgenommen. Bei Connections zu UTM-Anwendungen kann der Benutzer nachwievor seine eigenen Terminalnamen entsprechend der KDC-Generierung angeben. Durch Entfernen eines Kommentarsterns in der Unterroutine USRMOD kann der Austausch der Terminalnamen auch für UTM-, $CONSOLE- und DCAM-Anwendungen forciert werden.
Die i.f. beschriebene Möglichkeit zur Begrenzung der Nebenprozesse unter CFS ist unabhängig vom Prüfmodul USRMOD.
Begrenzung der Anzahl der möglichen Nebenprozesse
Über eine Modifikation in der gebundenen Programmphase CFS (siehe auch Quellprogramm des Moduls CFSMAIN in der CFS.S.LMSLIB) kann auf einfache Weise die maximale Anzahl der unter CFS zu eröffnenden Nebenprozesse beschränkt werden.
Durch Eintragen einer Zahl n (0 <= n <= 9) in der 6. PAM-Seite der gebundenen Programmphase CFS in der Spalte 48 wird die maximale Anzahl der zu eröffnenden Connections auf n begrenzt. Für TSOS bestehen keine Einschränkungen.
Die Zahl n kann auch bei den Initialisierungsparametern im Modul CFSMAIN angegeben werden.
Beispiel: Durch Eintragen der Zahl 2 können maximal zwei Connections, z.B. 1 und 2 oder 3 und 9 eröffnet werden. Wie dieses Beispiel zeigt, ist die Anzahl der Connections, nicht aber die höchste Connection-Nummer beschränkt.
Abweisen von Connections der Stufe 2
Von einer Connection der Stufe 2 sprechen wir, wenn der Grundprozeß zu einer CFS-Connection ebenfalls wieder als Nebenprozeß eines übergeordneten Task abläuft.
Über eine Modifikation in der gebundenen Programmphase CFS (6. PAM-Seite, Spalte 40: C'N'; siehe auch Quellprogramm von CFSMAIN in der CFS.S.LMSLIB) kann auf einfache Weise verhindert werden, daß Benutzer Connections der Stufe 2 eröffnen.
Rückkehr aus einer Connection nur bei Eingabeaufforderung
Um Data-Stagnation Fehler im Zusammenhang mit eröffneten Connections zu vermeiden, kann festgelegt werden, daß der Benutzer eine Connection nur dann verlassen kann, wenn nachfolgend keine freilaufenden Ausgaben mehr zu erwarten sind. Dieser Zustand ist immer dann gegeben, wenn vom Benutzer eine, wie auch immer geartete Eingabe angefordert wird. Modifikation (6. PAM-Seite von CFS, Spalte 67): C'X'.
4.  Überwachung der Open Connection-Anforderung mit Hilfe einer Terminaldatei
In der Benutzerkennung, in der CFS installiert ist, also z.B. unter $CFS kann der Systemverwalter eine zentrale Datei CFSTERM (Fcbtype=Sam, Recform=V, Share=Yes) einrichten. In dieser Datei wird festgelegt, unter welchen Benutzerkennungen bzw. an welchen Datensichtstationen Connections zu welchen Anwendungen, Host-Rechnern und Benutzerkennungen eröffnet werden dürfen.
In der CFSTERM können 3 Arten von Prüfsätzen angegeben werden.
- Gewöhnliche Prüfsätze
- Default-Sätze
- Common-Sätze.
Die gewöhnlichen Prüfsätze haben folgenden Aufbau:
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1U2U2U2U2U3U3...
Zur Spalten-Orientierung bei der Erstellung der TERMFILE kann als erstes ein Satz dieser Art in die Datei eingebracht werden. Dieser Skalierungssatz ist nur für Editierzwecke und wird von CFS ignoriert.
Die Bedeutung der einzelnen Datenfelder:
UUUUUUUU User-Id. Dieses Feld wird mit der User-Id verglichen, unter der CFS geladen wurde.
Werden für U...U Spaces eingetragen, so ist die User-Id, unter der CFS geladen wurde, irrelevant (beim Vergleich wird stets ein Treffer gemeldet). Für jede Position innerhalb von U...U kann das Sonderzeichen '*' angegeben werden. '*' ist das Beliebigkeitszeichen und bedeutet, daß die entsprechende Stelle der User-Id für den Vergleich nicht herangezogen wird.
X vor U...U Auswahlindikator.
x = Space positive Auswahl. Es wird ein Treffer gemeldet, wenn U...U mit der User-Id übereinstimmt, oder wenn U...U auf Spaces oder '********' gesetzt ist.
x = '-' negative Auswahl. Es wird ein Treffer gemeldet, wenn U...U nicht mit der User-Id übereinstimmt, unter der CFS geladen wurde.
BB Sonderindikator für U...U
BB = 'P ' Im Feld U...U steht der Name des Datenstationsrechners, an dem die Datensichtstation angeschlossen ist und nicht die User-Id, unter der CFS geladen wurde. Mit U...U und S...S (siehe unten) ist die Datensichtstation somit im Netz eindeutig identifiziert.
Der P-Indikator ist von Nutzen, falls mehrere Datenstationen innerhalb eines LAN's existieren, die alle den gleichen Stationsnamen besitzen und sich nur durch ihren Prozessornamen unterscheiden.
SSSSSSSS Stationsname. Dieses Feld wird mit dem Namen der Datensichtstation, an der CFS geladen wurde, verglichen.
X vor S...S Auswahlindikator.
x = Space positive Auswahl. Es wird ein Treffer gemeldet, wenn S...S mit der Station übereinstimmt, oder wenn S...S auf Spaces oder '********' gesetzt ist.
x = '-' negative Auswahl. Es wird ein Treffer gemeldet, wenn S...S nicht mit der Station übereinstimmt.
C Connection-Nummer. Dieses Feld wird mit der im OC-Kommando angegebenen Nummer der Connection verglichen (1 bei OC1, usw.).
Steht an der Stelle C ein Blank, so kann die Connection-Nummer beliebig sein.
X vor C Auswahlindikator.
x = Space Falls die im OC-Kommando angegebene Nummer mit der in C angegebenen Zahl übereinstimmt, werden die nachfolgenden Bedingungen geprüft.
x = '-' Falls die im OC-Kommando angegebene Nummer nicht mit der in C angegebenen Zahl übereinstimmt, werden die im gleichen Satz nachfolgenden Bedingungen geprüft.
x = '<' Falls die im OC-Kommando angegebene Nummer kleiner ist als die im Feld C angegebene Zahl, werden die nachfolgenden Bedingungen geprüft. Insbesondere: Folgt auf '<' als letztes das Zeichen '-', so sind keine Connections mit einer Nummer kleiner als der unter C angegebenen erlaubt. Beispiel siehe Seite A3- und folgende.
x = '>' Falls die im OC-Kommando angegebene Nummer größer ist als die im Feld C angegebene Zahl, werden die nachfolgenden Bedingungen geprüft. Insbesondere: Folgt auf '>' als letztes das Zeichen '-', so sind keine Connections mit einer Nummer größer als der unter C angegebenen erlaubt. Beispiel siehe Seite A3- und folgende.
PPPPPPPP Partner. Dieses Feld wird mit dem Namen der im Nebenprozeß eröffneten Anwendung verglichen.
Standardwert bei Weglassung des entsprechenden Parameters im OC-Kommando ist '$DIALOG'. Weitere übliche Partnernamen können z.B. sein $CONSOLE oder Namen von UTM-/SAP-Anwendungen.
X vor P...P Auswahlindikator.
x = Space Der im OC-Kommando angegebene Partner muß mit dem in P...P angegebenen Partner übereinstimmen.
x = '-' negative Auswahl: Sind im Feld PPPPPPPP Blanks eingetragen, so wird durch die Angabe '-' bestimmt, daß keine Connections eröffnet werden können (Connections zu beliebigen Partnern sind nicht erlaubt).
x = 'C' Conditional: Falls der Name der Anwendung mit dem in P...P angegebenen Namen übereinstimmt, so werden die im gleichen Satz nachfolgenden Bedingungen geprüft.
x = 'N' Negative conditional: Falls der Name der Anwendung nicht mit dem in P...P angegebenen Namen übereinstimmt, so werden die im gleichen Satz nachfolgenden Bedingungen geprüft.
TTTTTTTT Virtueller Terminalname. Dieses Feld wird mit dem von CFS generierten bzw. vom Benutzer angegebenen Stationsnamen für den Nebenprozeß verglichen.
Standardwert bei Weglassung des entspr. Parameters im OC-Kommando ist CFSntttt (n = Nummer der Connection, tttt = TSN des Basisprozeßes).
X vor T...T Auswahlindikator.
x = Space Der im OC-Kommando angegebene Terminalname muß mit dem in T...T angegebenen Terminal-Namen übereinstimmen.
x = '-' negative Auswahl: Sind im Feld TTTTTTTT Blanks eingetragen, so wird durch die Angabe '-' bestimmt, daß keine Connections eröffnet werden können (Connections mit beliebigen Terminalnamen sind nicht erlaubt).
x = 'C' Conditional: Falls der virt. Terminalname mit dem in T...T angegebenen Namen übereinstimmt, so werden die nachfolgenden Bedingungen geprüft.
x = 'N' Negative conditional: Falls der virt. Terminalname nicht mit dem in T...T angegebenen Namen übereinstimmt, so werden die nachfolgenden Bedingungen geprüft.
HHHHHHHH Hostname. Dieses Feld wird mit dem Namen desjenigen Hostrechners verglichen, auf dem der zu eröffnende Nebenprozeß erzeugt werden soll. Als Platzhalter für den eigenen Host-Rechner kann die Zeichenfolge '$SAME   ' angegeben werden.
X vor H...H Auswahlindikator.
x = Space Der im OC-Kommando angegebene Host-Name muß mit dem in H...H angegebenen Host-Namen übereinstimmen.
x = '-' negative Auswahl: Sind im Feld HHHHHHHH Blanks eingetragen, so wird durch die Angabe '-' bestimmt, daß keine Connections eröffnet werden können (Connections zu beliebigen Hostrechnern sind nicht erlaubt).
x = 'C' Conditional: Falls der Host-Name mit dem in H...H angegebenen Namen übereinstimmt, so werden die nachfolgenden Bedingungen geprüft.
x = 'N' Negative conditional: Falls der Host-Name nicht mit dem in H...H angegebenen Namen übereinstimmt, so werden die nachfolgenden Bedingungen geprüft.
U1U1U1U1 User-Id des Nebenprozeßes. Dieses Feld wird mit der User-Id des zu eröffnenden Nebenprozeßes verglichen (nur bei Connections zu $DIALOG).
Als Platzhalter für die eigene Benutzerkennung kann die Zeichenfolge '$SAME   ' angegeben werden. Bei Eröffnung einer Connection zu $CONSOLE bzw. zu einer UTM-/SAP-Anwendung wird der Inhalt des Feldes U1...U1 nicht bewertet.
X vor U1...U1 Auswahlindikator.
x = Space Die Benutzerkennung, unter der der Anwender in der CFS-Connection arbeiten will, muß mit U1...U1 übereinstimmen.
x = '-' Die Benutzerkennung, unter der der Anwender arbeiten will, darf nicht U1...U1 sein.
U2U2U2U2 zweite User-Id für Nebenprozeß.
In einem Prüfsatz können bis zu 25 Benutzerkennungen hintereinander angegeben werden. Der Auswahlindikator vor U1...U1 bezieht sich auf alle angegebenen User-IDs.
Hinweise: Für jede zu prüfende Bedingung ist ein eigener Satz in der CFS-Termfile vorzusehen. Eine Kombination mehrerer abzuweisender Bedingungen in einem Datensatz ist nicht möglich.
Bei Verbindungen zu $DIALOG wird die Connection bei negativem Prüfergebnis erst nach erfolgtem LOGON abgewiesen.
Default-Sätze
Wird für die aktuelle Umgebung kein gewöhnlicher Prüfsatz in der Termfile gefunden, so werden, falls vorhanden, die Default-Sätze ausgewertet. Default-Sätze beginnen im Feld XUUUUUUUU mit der Record-Id '$DEFLT   '.
Bei Default-Sätzen werden nur die Felder XC bis XUn...Un zur Prüfung herangezogen. Es können beliebig viele Default-Sätze in der Termfile vorkommen. Sie werden stets alle der Reihe nach durchgeprüft. Erfüllt der aktuelle Connectionwunsch mindestens eine der Default-Bedingungen nicht, so wird er abgewiesen.
Common-Sätze
Werden für die aktuelle Umgebung gewöhnliche Prüfsätze in der Termfile gefunden, so werden diese zuerst der Reihe nach geprüft. Falls Common-Sätze in der Termfile vorhanden sind, so werden diese anschließend geprüft. Common-Sätze werden nicht ausgewertet im Default-Fall. Common-Sätze beginnen im Feld XUUUUUUUU mit der Record-Id '$COM     '.
Bei Common-Sätzen werden nur die Felder XC bis XUn...Un zur Prüfung herangezogen.
Es können beliebig viele Common-Sätze in der Termfile vorkommen.
Ablauf des Prüfvorgangs
Es werden anhand der User-Id, der Station, unter welcher CFS geladen wurde, sowie der im OC-Kommando angegebenen Connection-Nummer (= "Umgebung") alle Prüfsätze in der Termfile gesucht, deren Felder XUUUUUUUU, XSSSSSSSS und XC mit der aktuellen Umgebung übereinstimmen.
Falls der Auswahlindikator eines der Felder P...P, T...T oder H...H den Wert 'C' (= Conditional) besitzt, so wird auch dieses Feld zur Bestimmung der Umgebung herangezogen. Die nachfolgenden Felder in den Prüfsätzen der Termfile (XP...P bis XUn...Un) bestimmen, ob die Eröffnung der Connection erlaubt ist. Wenn dies nicht der Fall ist, so wird von CFS ein entsprechendes DC-Kommando generiert und die Verbindung wird abgebrochen. Bei $DIALOG geschieht dies aber erst nach dem vollständig (incl. Passwort) eingegebenen und ausgeführten Logon-Kommando.
Zu einer Umgebung (User-Id, Name der Datensichtstation, sowie Open-Connection-Nummer), bzw. zu einer teilqualifizierten Umgebung, können auch mehrere Prüfsätze in der Termfile existieren. In diesem Fall werden alle passenden Prüfsätze der Reihe nach ausgewertet. Nur wenn keine der Prüfungen ein negatives Ergebnis liefert, wird das Eröffnen der Connection erlaubt.
Die in der Termfile enthaltenen Datensätze müssen in keiner festgelegten Reihenfolge angegeben werden. Einzige Ausnahme: siehe das letzte der folgenden Beispiele.
Pro Datensatz kann in den Feldern XP...P bis XU1...U1 höchstens einmal der Negativindikator '-' angegeben werden. Eine Kombination von mehreren Negativbedingungen in einem Satz wird bei der Prüfung ignoriert.
Beispiele:
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
 TSOS
$DEFLT              >3-
Wurde CFS unter einer Kennung ungleich TSOS geladen, so können keine Connections mit einer Nummer > 3 eröffnet werden (für alle Connections > 3 sind beliebige Partnernamen nicht erlaubt: XPPPPPPPP = '-        '). Wurde CFS unter TSOS geladen, so können ohne Einschränkung alle Connections von 0 bis 9 zu beliebigen Partnern eröffnet werden.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
 TEST                 -$DIALOG
Für die Kennung TEST sind keine Connections zu $DIALOG erlaubt.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1U2U2U2U2
            DSS4711                     CVAR1     $SAME   ABC
            DSS4711                     CVAR2     $SAME   XYZ
Wurde CFS an der Datensichtstation DSS4711 geladen und wird per OC-Kommando ein Dialogprozeß zum Host VAR1 eröffnet (C vor VAR1: positiv conditional), so sind für das Logon-Kommando nur die eigene Benutzerkennung, sowie die zusätzliche Benutzerkennung ABC möglich. Bei Verbindungen zum VAR2 sind Nebenprozesse nur unter der eigenen, sowie unter der zusätzlichen Kennung XYZ möglich. Die Liste der zusätzlichen Benutzerkennungen kann auf bis zu 25 Einträge erweitert werden. Jeder Eintrag ist 8 Byte lang.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
            D4711
            D4712
            D4713
            D4714
$DEFLT                -$CONSOLE
Das Eröffnen von Connections zu $CONSOLE ist nur von Datensichtstationen D4711 bis D4714 möglich.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
                      C$CONSOLE CFSCON* 
$DEFLT                -$CONSOLE
Falls eine Connection zu $CONSOLE eröffnet wird (C vor $CONSOLE: positiv conditional), so ist im OC-Kommando zwingend ein Terminalname von der Form CFSCONx (x: beliebiges Zeichen) anzugeben.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
-TSOS       CFS*****  -
Wurde CFS nicht unter TSOS geladen, so können Nebenprozesse ohne Einschränkung eröffnet werden. Wird in einem dieser Nebenprozesse jedoch wieder CFS aufgerufen und ein OC-Kommando für eine beliebige Anwendung abgegeben, so wird dieses abgewiesen, sofern als virtueller Stationsname der von CFS generierte Standardname CFSnxxxx verwendet wurde.
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
$DEFLT              >3-
$DEFLT                -$CONSOLE
$DEFLT                                   $SAME
$DEFLT                                            $SAME   TEST
 TSOS               <7 
 TSOS               >6-
 ABCD                                    $SAME
 ABCD               >6-
 A*******                                $SAME    $SAME
 A*******           >6-
 XXX                                     $SAME    $SAME   XYZ
 XXX                >6-
Für alle Kennungen außer TSOS, ABCD, beliebige Kennungen, die mit 'A' beginnen und XXX gilt:
- Es sind nur die Connections 0 bis 3 erlaubt. Es sind keine Connections zu $CONSOLE erlaubt.
- Es sind nur Connections im eigenen Host möglich.
- Es sind nur Dialogprozesse unter der jeweils eigenen, sowie unter der zusätzlichen Kennung TEST möglich.
- Für TSOS sind nur Connections 7 bis 9 gesperrt.
- Für die Kennung ABCD gilt das gleiche, jedoch sind Nebenprozesse nur am eigenen Host möglich.
- Für beliebige andere mit 'A' beginnende Kennungen sind Connections 7 bis 9 nicht erlaubt. Außerdem sind Nebenprozesse nur am eigenen Host und unter der eigenen Benutzerkennung möglich.
- Für die Kennung XXX gilt das gleiche, jedoch sind Nebenprozesse zusätzlich zur eigenen auch noch unter der Benutzerkennung XYZ erlaubt.
Hinweis:
Die Reihenfolge der Sätze in der Termfile ist für das Ergebnis der Prüfung nur insofern von Bedeutung, als die Sätze mit 'A*******' nach den Sätzen mit einer vollqualifizierten Benutzerkennung (z.B. 'ABCD____') angegeben werden müssen. Die gleiche Regelung trifft auch für das Feld S...S zu.
Durch die Verwendung von Common-Sätzen ($COM) kann das obige Beispiel auch in einer verkürzten Form realisiert werden:
XUUUUUUUUBBXSSSSSSSSXCXPPPPPPPPXTTTTTTTTXHHHHHHHHXU1U1U1U1
$DEFLT              >3-
$DEFLT                -$CONSOLE
$DEFLT                                   $SAME
$DEFLT                                            $SAME   TEST
 ABCD                                    $SAME
 A*******                                $SAME    $SAME
 XXX                                     $SAME    $SAME   XYZ
$COM                >6-
Beispiele für Termfile-Prüfungen finden Sie auch in der CFS.S.LMSLIB.
Hinweise zur Erstellung und Wartung der CFS-Termfile
- Um eine Termfile erstmalig zu erstellen, selektieren Sie mit Hilfe von CFS das Element TERMF0 aus der CFS.S.LMSLIB: SEL TERMF0,CFS.S.LMSLIB,CFSTERM . Der Skalierungssatz in der so erzeugten Datei CFSTERM dient als Orientierungshilfe für die von Ihnen neu einzutragenden Prüfsätze.
- Die Termfile muß shareable sein, so daß CFS von allen Benutzerkennungen darauf zugreifen kann. Falls im Modul CFSMAIN keine besonderen Eintragungen bezüglich des Namens der Termfile vorgenommen wurden, muß die Termfile unter der CFS-Kennung (z.B. unter $CFS) eingerichtet werden.
- Die Termfile kann empfindliche Daten, wie z.B. Benutzerkennungen, Namen von Datensichtstationen usw. enthalten. Diese Informationen sollten nicht im Klartext für jedermann zugänglich sein. Aus diesem Grunde sind die in der Termfile enthaltenen Daten zu verschlüsseln. Von CFS werden nur die verschlüsselten Informationen verarbeitet.
Der Vorgang des Verschlüsselns geschieht, indem der CFS-Administrator unter TSOS die Termfile zuerst entsperrt (/VERIFY CFSTERM,REPAIR=ABS). Anschließend ist folgendes Kommando einzugeben:  /EXEC (CONCH,$TSOS.CFSLIB). Auf die Frage nach der Input-Datei ist der Name der im Klartext vorliegenden Termfile anzugeben. Auf die Frage nach der Output-Datei ist der Name der zuvor entsperrten produktiven Termfile anzugeben. Die erfolgreiche Umsetzung wird anschließend bestätigt.
- Das entschlüsseln einer produktiven Termfile ist ebenfalls mit dem Modul CONCH möglich. Als Eingabedatei ist in diesem Fall die verschlüsselte Termfile und als Ausgabedatei die Datei im Klartext anzugeben. Das Verschlüsselungsverfahren ist umkehrbar.
- Aus Gründen der Datensicherheit sollte die Termfile vom CFS-Administrator auf ACCESS= READ gesetzt werden. In CFSMAIN kann außerdem ein READ-Passwort für die Termfile vereinbart werden. Vor jedem Zugriff auf die Termfile wird dieses Passwort von CFS abgesetzt und nach erfolgreichem Open sofort wieder freigegeben. Das ursprüngliche CAT-Kommando für die Termfile muß der Systemverwalter selbst vornehmen: /CAT CFSTERM,STATE=U,RDPASS=....
- Die Durchführung der in diesem Abschnitt beschriebenen OC-Prüfungen ist nur an das Vorhandensein der Termfile gebunden. Es sind weder Modifikationen im USRMOD vorzunehmen, noch sind irgendwelche Indikatoren im Modul CFSMAIN zu setzen. Es ist jedoch darauf zu achten, daß die Termfile den richtigen Dateinamen aufweist. Der benötigte Dateinamen kann ermittelt werden, indem nach Aufruf von CFS in der zweiten Maske mit Hilfe der K2-Taste in den Systemmodus verzweigt wird. Durch das AID-Kommando %D V'22A9'%XL30 wird der Name der benötigten Termfile angezeigt.
5.  Überwachung der CFS-Programmaufrufe mit Hilfe einer Userdatei
Der Systemverwalter kann eine zentrale Datei $user-id.CFSUSER erstellen (FCBTYPE=SAM, RECFORM =V, user-id ist hierbei die Benutzerkennung, unter der CFS installiert ist). In dieser Datei wird festgelegt, unter welchen User-IDs bzw. an welchen Datensichtstationen ein /EXEC $CFS durch den Benutzer erlaubt bzw. nicht erlaubt ist. In der Datei CFSUSER kann eine beliebige Anzahl von Prüfsätzen angegeben werden.
Die Prüfsätze haben folgenden Aufbau:
XUUUUUUUUBBXSSSSSSSS
(Zur Spalten-Orientierung bei der Erstellung der TERMFILE kann als erstes ein Satz dieser Art in die Datei eingebracht werden. Dieser Skalierungssatz ist nur für Editierzwecke und wird von CFS ignoriert).
Die Bedeutung der einzelnen Datenfelder:
UUUUUUUU User-Id. Dieses Feld wird mit der User-Id verglichen, unter der der Benutzer CFS aufgerufen hat. Werden bei U...U Spaces eingetragen, so ist die User-Id, unter der CFS geladen wird, irrelevant. In diesem Fall ist nur die nachfolgende Spalte S...S (Datensichtstation) für die Prüfung der CFS-Berechtigung von Bedeutung.
Für jede Position innerhalb von U...U kann das Sonderzeichen '*' angegeben werden. '*' ist das Beliebigkeitszeichen und bedeutet, daß die entsprechende Stelle der User-Id für den Vergleich nicht herangezogen wird.
X vor U...U Auswahlindikator.
x = Space positive Auswahl. Der Aufruf von CFS ist erlaubt, falls die User-ID, unter der sich der Benutzer angeloggt hat, mit der in U...U angegebenen Benutzerkennung übereinstimmt oder wenn U...U auf Spaces oder '********' gesetzt ist.
x = '-' negative Auswahl. Der Aufruf von CFS wird zurückgewiesen, falls die User-ID, unter der sich der Benutzer angeloggt hat, mit der in U...U angegebenen Benutzerkennung übereinstimmt oder wenn U...U auf Spaces oder '********' gesetzt ist.
x = 'C' Conditional: Falls die User-ID, unter der sich der Benutzer angeloggt hat, mit der in U...U angegebenen User-ID übereinstimmt, so wird der in S...S angegebene Name mit dem Namen der Datensichtstation verglichen, unter der CFS aufgerufen wird.
x = 'N' Negative conditional: Falls die User-ID, unter der sich der Benutzer angeloggt hat, nicht mit der in U...U angegebenen User-ID übereinstimmt, so wird der in S...S angegebene Name mit dem Namen der Datensichtstation verglichen, unter der CFS aufgerufen wird.
BB konstant Spaces.
SSSSSSSS Stationsname. Dieses Feld wird mit dem Namen der Datensichtstation, an der CFS geladen wurde, verglichen.
Für S...S und den davorstehenden Auswahlindikator X gelten analog alle für U...U gemachten Bemerkungen.
Werden bei S...S Spaces eingetragen, so ist die Datensichtstation, an der CFS geladen wird, irrelevant. In diesem Fall ist nur die Spalte U...U (User-ID) für die Prüfung der CFS-Berechtigung von Bedeutung.
Für jede Position innerhalb von S...S kann das Sonderzeichen '*' angegeben werden. '*' ist das Beliebigkeitszeichen und bedeutet, daß die entsprechende Stelle im Stationsnamen für den Vergleich nicht herangezogen wird.
X vor S...S Auswahlindikator.
x = Space positive Auswahl. Der Aufruf von CFS ist erlaubt, falls die Datensichtstation, unter der sich der Benutzer angeloggt hat, mit dem in S...S angegebenen Namen übereinstimmt oder wenn S...S auf Spaces oder '********' gesetzt ist.
x = '-' negative Auswahl. Der Aufruf von CFS wird zurückgewiesen, falls die Datensichtstation, unter der sich der Benutzer angeloggt hat, mit dem in S...S angegebenen Namen übereinstimmt oder wenn S...S auf Spaces oder '********' gesetzt ist.
x = 'C' Conditional: Falls die Datensichtstation des Benutzers mit der in S...S angegebenen Datensichtstation übereinstimmt, so wird die bei U...U eingetragene User-ID mit der Benutzerkennung verglichen, unter der sich der Benutzer angeloggt hat.
x = 'N' Negative conditional: Falls die Datensichtstation des Benutzers nicht mit der in S...S angegebenen Datensichtstation übereinstimmt, so wird die bei U...U eingetragene User-ID mit der Benutzerkennung verglichen, unter der sich der Benutzer angeloggt hat.
Im Anschluß an die Prüfsätze kann ein Defaultsatz angegeben werden. Im diesem Satz wird festgelegt, ob die Benutzung von CFS erlaubt ist oder nicht, falls weder die User-ID des Benutzers noch der Name der Datensichtstation in einem gewöhnlichen Prüfsatz gefunden wurde.
Der Default-Satz besitzt das Format: DEFAULT=Y | N
DEFAULT=Y bewirkt, daß CFS für die Benutzung zugelassen wird, falls in der CFS-Userfile kein Satz mit der User-ID oder dem Stationsnamen des Benutzers enthalten ist.
DEFAULT=N bewirkt, daß CFS für die Benutzung nicht zugelassen wird, falls in der CFS-Userfile kein Satz mit der User-ID oder dem Stationsnamen des Benutzers enthalten ist.
Standard: DEFAULT=Y
Beispiele:
XUUUUUUUUBBXSSSSSSSS
CTSOS       DSS4111 
CTSOS       DSS4112 
CTSOS       DSS4113 
CTSOS      -        
Unter der Kennung TSOS kann CFS nur an den Datensichtstationen DSS4711 bis DSS4713 aufgerufen werden. Von allen anderen Kennungen aus ist CFS ohne Einschränkungen benutzbar.
XUUUUUUUUBBXSSSSSSSS
-A10*****
Für alle Kennungen, die mit A10 beginnen, ist CFS nicht erlaubt. Für alle anderen Kennungen bestehen keine Einschränkungen.
XUUUUUUUUBBXSSSSSSSS
            DSS91***
DEFAULT=N
Die Benutzung von CFS ist nur an Datensichtgeräten erlaubt, deren Namen mit DSS91 beginnen.
Hinweis:
Die Reihenfolge der Sätze in der Userfile ist für das Ergebnis der Prüfung von Bedeutung. Siehe hierzu Beispiel 1 oben.
Beispiele für Userfiles finden Sie auch in der CFS.S.LMSLIB.
Hinweise zur Erstellung und Wartung der CFS-Userfile
- Um eine Userfile erstmalig zu erstellen, selektieren Sie mit Hilfe von CFS das Element USERFIL1 aus der CFS.S.LMSLIB: SEL USERFIL1,CFS.S.LMSLIB,CFSUSER . Der Skalierungssatz in der so erzeugten Datei CFSUSER dient als Orientierungshilfe für die von Ihnen neu einzutragenden Prüfsätze.
- Die Userfile muß shareable sein, so daß CFS von allen Benutzerkennungen darauf zugreifen kann.
- Die Userfile kann empfindliche Daten, wie z.B. Benutzerkennungen enthalten. Diese Informationen sollten nicht im Klartext für jedermann zugänglich sein. Aus diesem Grunde sind die in der Userfile enthaltenen Daten zu verschlüsseln. Von CFS werden nur die verschlüsselten Informationen verarbeitet.
- Der Vorgang des Verschlüsselns geschieht wie bei der Termfile mit Hilfe des Moduls CONCH. Die nähere Vorgehensweise ist im Abschnitt "Hinweise zur Erstellung und Wartung der Termfile" auf Seite A3- beschrieben.
- Aus Gründen der Datensicherheit sollte die Userfile vom CFS-Administrator auf ACCESS= READ gesetzt werden. In CFSMAIN kann außerdem ein READ-Passwort für die Userfile vereinbart werden (siehe Feld USERFPSW im Datenteil am Ende von CFSMAIN). Vor jedem Zugriff auf die Userfile wird dieses Passwort von CFS abgesetzt und nach erfolgreichem Open sofort wieder freigegeben. Das ursprüngliche CAT-Kommando für die Userfile muß der Systemverwalter selbst vornehmen: /CAT CFSUSER,STATE=U, RDPASS=......
- Die Durchführung der in diesem Abschnitt beschriebenen Berechtigungsprüfungen ist nur an das Vorhandensein der Userfile gebunden. Es sind weder Modifikationen im USRMOD vorzunehmen, noch sind irgendwelche Indikatoren im Modul CFSMAIN zu setzen. Es ist jedoch darauf zu achten, daß die Userfile den richtigen Dateinamen aufweist. Dieser kann im Datenteil des Moduls CFSMAIN definiert werden (Feld USERFILE).
6.  Protokollierung der Benutzeraktivitäten
CFS bietet die Möglichkeit, alle CFS-Aufrufe zusammen mit Datum, Uhrzeit, TSN, Benutzerkennung, Abrechnungsnummer und Modus (Dialog/Enter) in einer Protokolldatei festzuhalten. Bei der Beendigung von CFS wird ebenfalls ein Protokollsatz mit der TSN, sowie der gesamten Verweilzeit in CFS in Minuten) ausgegeben.
Die Protokollierungsfunktion wird bei der Installation von CFS eingeschaltet, indem der Name der Protokolldatei von '*DUMMY' auf einen echten Dateinamen gesetzt wird. Dies kann geschehen durch eine Modifikation im 6. PAM-Block von CFS ab der Spalte 201. Näheres hierzu siehe Quellprogramm CFSMAIN in der CFS.S.LMSLIB. Die Protokolldatei (falls sie noch nicht existiert) wird von CFS shareable gemacht und mit einem Read-Passwort versehen.
Neben dem Aufruf von CFS können wahlweise die folgenden Benutzeraktivitäten protokolliert werden:
- Eröffnen einer Connection per OC-Kommando
- File-Transfer Anforderungen mittels Kommando/Action-Code FT oder Variabler Action ONXFT
- Modifizieren einer Datei im CFS-Editor.
- Fehlermeldungen des Connection-Handlers lassen sich für Testzwecke protokollieren.
Für eine Beschreibung der Aktivierung der verschiedenen Protokollierungen wird auf das Quellprogramm CFSMAIN in der CFS.S.LMSLIB verwiesen.
7.  CFS.PDFILE für besondere Print-/FT-/RDAC-Kommandos
Mit der PDFILE wird dem CFS-Administrator und jedem einzelnen CFS-Benutzer die Möglichkeit geboten, gewissen alphanumerischen Mnemo-Codes (PDmn) bestimmte Remote-Drucker, Print-Kommandos, File-Transfer- oder RDAC-Profile zuzuordnen.
Die CFS.PDFILE ist eine gewöhnliche mit EDT erstellbare SAM-Datei, die 3 verschiedene Arten von Sätzen kennt:
- Kommentarsätze können an beliebiger Stelle eingestreut werden und beginnen in Spalte 1 mit einem Stern ('*').
- Header-Sätze beginnen in Spalte 1 mit '$'. Ab Spalte 2 folgt
a) ein Gerüst von Parametern für das Kommando /PRINT (ISP).
b) der String 'PRINT-FILE', gefolgt von einem Leerzeichen und Parametern für ein PRINT-FILE Kommando (SDF) oder
der String 'PRINT-DOCUMENT', gefolgt von einem Leerzeichen und Parametern für ein PRINT-DOCUMENT Kommando (SDF).
c) der String 'FT', gefolgt von einem Leerzeichen und Parametern für ein FT (File-Transfer) Kommando von CFS. Für die Beschreibung der Parameter siehe CFS-Benutzerhandbuch, Kapitel 7 (Kommando FT) und Kapitel 12 "File-Transfer mit FT-BS2000/RDAC".
Beispiel: FT ,,,HOST1,USERID2,ACCNB2,C'PASS',,,,TO,YES.
d) der String 'RDAC', gefolgt von einem Leerzeichen und Parametern für ein RDAC-Kommando von CFS (File-Transfer/Ausdruck mit RDAC). Für die Beschreibung der Parameter siehe CFS-Benutzerhandbuch, Kapitel 7 (Kommando RDAC) und Kapitel 12 "File-Transfer mit FT-BS2000/RDAC". Beispiel: RDAC ,,,DRUCKER2,,,,TO,SPACE=E,HEADER=YES.
Im Fall a) und b) wird vorausgesetzt, daß der Dateiname der erste Parameter des Kommandos ist und zum Zeitpunkt des Ausdrucks einer Datei von CFS selbständig eingesetzt wird. Bei den Print-Parametern stehen die Sonderzeichen '*' stehen als Platzhalter für den Namen eines im PDN generierten Remote-Druckers.
Im Fall c) und d) werden durch die ersten drei Kommas die Parameter datei1, datei2, passw übergangen. Der Parameter datei1 wird zum Ausführungszeitpunkt durch den Namen der mit dem Action-Code PD markierten Datei versorgt. Für datei2 wird der gleiche Name wie datei1 eingesetzt.
Ein Header-Satz kann bis zu 2048 Bytes lang sein. Falls die PDFILE jedoch mit EDT bearbeitbar sein soll, ist die maximale Satzlänge auf 256 Bytes begrenzt.
Falls in einem Header-Satz der String '********' als Platzhalter für den Device-Namen angegeben wurde (z.B. DEV=********), so werden von CFS die nachfolgenden Mnemo-Device Zuordnungssätze (siehe unten) solange gelesen, bis ein Satz mit dem Mnemo-Code mn (entsprechend dem Action-Code PDmn) gefunden wird. Der in diesem Satz zugeordnete Drucker (Spalte 3 bis 10) wird dann an die Stelle von '********' im DEV- oder in sonstigen Print-Operanden eingefügt.
Die Sonderzeichen '#' stehen für den im PD-Action-Code angegebenen Mnemo-Code. Falls in einem Header-Satz die Sonderzeichen '#' vorkommen, so wird an den entsprechenden Stellen der im PD-Action-Code angegebene Mnemo-Code direkt in die Parameter für das Print-Kommando übertragen. Für einen Header-Satz der die Zeichen '#' enthält, sind somit keine Mnemo-Device Zuordnungssätze (siehe unten) erforderlich.
Auf einen Header-Satz der Art a) bis d) folgen ein oder mehrere Mnemo-Zuordnungen (PDmn).
- Mnemo-Zuordnungssätze beginnen in Spalte 1 mit einem Zeichen ungleich '*' und '$'. Die Felder haben folgendes Format (siehe auch Beispiel auf der nächsten Seite):
Spalte 1-2 Mnemonic mn des Action-Codes PDmn (mn: alphanumerisch, linksbündig). Der Mnemo-Code darf nicht mit den Zeichen B, E oder S enden.
Spalte 3-10 DCAM Device-Name des Remote-Druckers / Name des Hostrechners für FT.
Für den virtuellen Device-Namen ???????? wird beim ersten Ansprechen des zugehörigen Mnemo-Codes durch den Benutzer ein realer Device-Namen angefordert. Dieser Name bleibt während der CFS-Session solange gültig, bis er evtl. durch ein Kommando APD device geändert wird.
Spalte 11-80 beliebiger Text (Beschreibung des Druckers, Standort, usw.) bzw. Blank.
Die gesamte Liste aller Beschreibungen wird durch Angabe des Action-Codes PD? am Bildschirm ausgegeben.
Falls in einem Header-Satz die Platzhalterzeichen '*' für den Device-Namen nicht angegeben wurden (z.B. CONTROL=PHYS,FORM=STD,LOOP=C8,CHARS=(82E,82R) ), so ist der Device-Name in dem nachfolgenden Mnemo-Device Satz nur aus formellen Gründen erforderlich. In diesem Fall ist lediglich der Mnemo-Code von Bedeutung. Über diesen wird die Zuordnung zu dem Print-Kommando mit den im vorausgehenden Header-Satz angegebenen Parametern hergestellt.
Zuordnungsalgorithmus Mnemo-Code <--> durch CFS erzeugtes Print-/FT-/RDAC-Kommando:
Action-Code PDmn: Es wird die Bezeichnung mn in den Spalten 1 bis 2 der PDFILE gesucht.
Falls ein Satz mit der angegebenen Bezeichnung gefunden wurde, wird der vorausgegangene Header-Satz ($...) zur Ermittlung des auszuführenden Kommandos gesucht.
Alle in den Print-Parametern des Header-Satzes vorkommenden '*'-Zeichen werden sukzessive durch die entsprechenden Stellen des Device-Namens ersetzt, sofern der Device-Name nicht auf ???????? lautet (virtueller Device-Name, siehe oben). In dem so gebildeten Print-Kommando ist lediglich noch der Name der Datei offen. Dieser wird von CFS vor der Ausführung des Kommandos eingefügt.
Falls kein Satz mit dem angegebenen Mnemo-Code gefunden wurde, so wird der erste Header-Satz gesucht, in dem mindestens ein '#' vorkommt. Wird ein derartiger Header-Satz gefunden, so wird der im PD-Action-Code angegebene Mnemo-Code sukzessive für jedes der 1 bis 2 '#'-Zeichen substituiert. Dabei ist folgendes zu beachten: Ist im PD-Action-Code ein 1-stelliger Mnemo-Code angegeben (PD5) und im Header-Satz wird ein 2-stelliger Mnemo-Code erwartet (##), so wird der PD-Mnemo-Code intern auf 2 Stellen erweitert (PD05).
Trifft keiner der oben beschriebenen Fälle zu, so wird am Bildschirm eine Fehlermeldung ausgegeben "Header-Record/Station-Record missing in PDFILE".
Mit Hilfe des Action-Codes PD (bzw. PD?) kann sich der Benutzer eine Liste aller installierten Mnemo-Codes und deren Zuordnung zu den entsprechenden Print-Kommandos, bzw. Remote-Druckern ausgeben lassen.
Der Name der PDFILE und die Kennung kann vom CFS-Administrator im Patch-Bereich von CFS frei bestimmt werden (siehe Quellprogramm CFSMAIN).
Eine zentrale, von allen Benutzern zu verwendende CFS.PDFILE muß shareable sein. Es kann sich jeder Benutzer aber auch seine eigene PDFILE erstellen und per FILE-Kommando zuweisen: /FILE pdfile,LINK=PDFILE.
Beispiel für eine PDFILE:
$CONTROL=PHYS,FORM=SX1,LOOP=C8,CHARS=(82E,82R)                                      
Z1        zentraler Laserdrucker; Format 1 (siehe RZ-Spezifikation)                 
$DEV=********,FORM=H810                                                             
A0DRU1    Tischlaser Raum 418, Format: 8 LPI, Schrift: 10 CPI                       
..............                                                                      
                                                                                    
H0DRU8               Raum 502, Format: 8 LPI, Schrift: 10 CPI                       
$PRINT-FILE ALT-USER=*NONE,DEVICE-NAME=********,START-OUTPUT=STD                    
A3DRU1    Tischlaser Raum 418, Format: 8 LPI, Schrift: 12 CPI                       
B2DRU2               Raum 422, Format: 8 LPI, Schrift: 12 CPI                       
..............                                                                      
                                                                                    
X ????????           virtueller Devicename zum Mnemo-Code X.                        
$FT ,,,********,USERID0,ACCOUNT0,C'pass',/DO succ-proc,/DO fail-proc,*BS2000,TO,YES 
F0HOST0   File-Transfer nach HOST0, User-Id USERID0                                 
F1HOST1   File-Transfer nach HOST1, User-Id USERID0                                 
$RDAC ,,,********,,,,TO,YES,SPACE=E,HEADER=HDR1                                     
R0DRUCK10 RDAC-Drucker 10                                                           
R1DRUCK11 RDAC-Drucker 11                                                           
..<3 _ 10><11__________________________________________________________________2048>
|    |        |
|    |        [___ Beliebiger Kommentar. Dieser wird bei Eingabe 
|    |              des Action-Codes PD / PD? für alle definierten
|    |              Drucker angezeigt.
|    |
|    [Device-Name des Druckers/Host-Rechners.
|
[__ 2 Stellen Mnemo-Code: Beschreibung des Druckers und des besonderen Formats.
8.  Installation von CFS
Die Installation von CFS erfolgt durch Einspielen eines ARCHIVE-Bandes unter einer beliebigen Benutzerkennung, z.B. unter $CFS. Folgende Anweisungen sind hierzu notwendig:
/EXEC $ARCHIVE
F NA=($TT08.,RENAME=$CFS.)
I FROM=(CFSxxx),DEVICE=xxxx,L=SYSOUT,REP=ALL
END
Die Dateien CFS, CFSLIB und CFSHELP sollten auf die Eigenschaft SHARE=YES überprüft werden.
In der mit dem Magnetband ausgelieferten Version sind die Standardwerte der CFS-Kommandos und Optionen so eingestellt wie in Kapitel 18 "Parameter ändern" beschrieben.
Hiervon abweichende Standardeinstellungen können realisiert werden auf Benutzerebene mit Hilfe von Startup-Dateien. Startup-Dateien enthalten Kommandos, die nach Aufruf des Programms automatisch ausgeführt werden. Jeder Benutzer kann hier seine individuellen Parameter-Voreinstellungen festlegen.
Eine RZ-globale Änderung der Standardwerte wird erreicht durch das Vorschaltprogramm CFSMAIN. Dieses in Assembler-Sprache geschriebene Programm wird im Source-Code ausgeliefert und steht unter dem Namen CFSMAIN in der CFS.S.LMSLIB zur Verfügung. Über CFSMAIN können Parameter-Voreinstellungen in CFS geändert, sowie Datenschutzeinrichtungen aktiviert werden.
Beispiele:
- Aktivierung des Prüfmoduls USRMOD. Nach jeder Eingabe wird dieser Modul durchlaufen, wobei die Benutzereingaben geprüft bzw. modifiziert werden können.
- Bestätigung durch den Benutzer vor dem Überschreiben von bestehenden Dateien, z.B. bei Select, Copy, Add, Erase.
- Maximale Anzahl der zu eröffnenden Connections.
- Zeichen für das Kommandogedächtnis in Connections (Standard: '-').
- Standard User-Option für die Dateiselektion.
- Namen von CFS-internen Dateien. Z.B. Name einer Protokollierungsdatei, in der alle CFS-Aufrufe durch die Benutzer festgehalten werden können.
- Namen der OMLs für Standard-Softwareprodukte, die von CFS unterstützt werden.
z.B. OMLPERCON, LMSLIB, FMSLIB, FMS.LNKLIB, SYSOML.FLAM, EDTLIB, TOM.TI.LNKLIB.
Im Quellprogramm CFSMAIN sind alle derzeit realisierten Änderungsmöglichkeiten zusammen mit einer kurzen Beschreibung aufgeführt.
Zur Änderung einer Option auf einen vom Standard abweichenden Wert genügt es in der Regel, den Kommentarstern aus dem Source-Code zu entfernen und damit den entsprechenden MVI-/ MVC-Befehl zu aktivieren.
Das vom Systemverwalter modifizierte Programm CFSMAIN ist mit der Prozedur ASSEMB aus der CFS.S.LMSLIB zu übersetzen. Die angegebenen Makrobibliotheken in dieser Prozedur sollten zuvor überprüft und ggf. korrigiert werden. Der Aufrufparameter &PLAM der Prozedur ASSEMB ist standardmäßig auf ON gesetzt, was bedeutet, daß die CFSLIB im Format einer PLAM-Bibliothek vorliegt.
Damit die gewünschten Modifikationen in CFS wirksam werden, muß das Programm CFS neu gebunden werden. Hierfür sind die Prozeduren CFSLNK und CFSLNK1 in der CFS.S.LMSLIB vorgesehen. Im Normalfall ist die Prozedur CFSLNK zu verwenden. Die Prozedur CFSLNK1 sollte nur benutzt werden, wenn Nachlademodule aus der CFSLIB wie MODR oder USRMOD fest in CFS eingebunden werden. Hierzu ist auch eine Modifikation in CFSMAIN notwendig.
Bei einer späteren Auslieferung von CFS können die oben dargestellten Schritte abgekürzt werden bzw. entfallen, sofern folgende Vorgehensweise eingehalten wird:
Die bisherigen Dateien CFSLIB und CFS.S.LMSLIB in Sicherungsdateien kopieren:
/COPY CFSLIB,CFSLIB.ALT
/COPY CFS.S.LMSLIB,CFS.S.LMSLIB.ALT.
Die alten Versionen dieser Dateien stehen damit auch nach dem Einspielen der neue CFS-Version noch zur Verfügung.
Die Module CFSMAIN, USRMOD, MODR und eventuell weitere benutzerspezifische Module sind aus der alten CFSLIB in die neu ausgelieferte CFSLIB zu übertragen. CFS ist anschießend neu zu binden (DO CFS.S.LMSLIB(CFSLNK/CFSLNK1) ).
Die Adressen der CFS-Parameter sind aufwärtskompatibel zu zukünftigen Versionen von CFS. Aus diesem Grunde kann auch der alte Modul CFSMAIN mit einer neuen CFS-Programmversion zusammengebunden werden. Im aktuellen Quellprogramm CFSMAIN werden in der Regel zusätzliche Modifikationsmöglichkeiten enthalten sein, die es in der alten CFS-Version noch nicht gab. Aus diesem Grunde empfiehlt es sich, das alte Quellprogramm von CFSMAIN mit der neu ausgelieferten zu vergleichen (EDT-Compare), die im alten CFSMAIN vorgenommenen Modifikationen in das neue Quellprogramm zu übertragen und die zusätzlichen Möglichkeiten zur Modifikation von Parametern entsprechend den RZ-Bedürfnissen zu aktivieren.
Für die Namen der CFS-internen Dateien, die standardmäßig auf die Namen $TSOS.CFSxxxx voreingestellt sind, gilt folgendes: Über den Linknamen ECERDLOD wird die Benutzerkennung ermittelt, von der das Programm CFS geladen wurde (z.B. $CFS.). Ist diese Kennung verschieden von TSOS, so wird in den internen Dateinamen die Standard-Benutzerkennung $TSOS. gegen diejenige Kennung ausgetauscht, unter der CFS geladen wurde (z.B. $CFS.). Der Austausch der Benutzerkennung wird nicht durchgeführt, falls die User-Id eines internen Dateinamens bereits auf einen Wert ungleich TSOS geändert wurde (siehe entsprechende MVC-Befehle im Initialisierungsteil von CFSMAIN).
Der Systemverwalter kann verschiedene Versionen des Produkts CFS zur Benutzung freigeben. Hierzu sind die Namen der Dateien CFS, CFSLIB, CFSHELP und evtl. die Jobvariable CFS.MESSAGE mit einer Versionssuffix .nnn bzw. .Vnnn zu versehen (z.B. CFS.945, CFSLIB.945, CFSHELP.945). Die so erzeugten neuen Dateinamen müssen in CFSMAIN nicht eigens bekannt gemacht werden. Die Namen werden nach einem ähnlichen Automatismus wie oben beschrieben mit den korrekten Versionsbezeichnungen ergänzt.
Falls CFS auf PC's mit 9750-Terminalemulationen betrieben wird, so ist es u.U. notwendig, vor Aufruf des Programms den Prozeßschalter 2 zu setzen. Das Setzen dieses Prozeßschalters kann auch über CFSMAIN automatisch vorgenommen werden.
CFS-Bulletin
Der Systemverwalter hat die Möglichkeit, in einer Jobvariablen einen bis zu 240 Byte langen Text für ein Bulletin an alle CFS-Benutzer zu hinterlegen. Dieser Text (z.B. "Neues CFS im Einsatz. Die Änderungen gegenüber der bisherigen Version erhalten Sie, indem Sie im Feld FILENAME-SELECT ?all eingeben und im nachfolgenden Menue den ersten Punkt ankreuzen.") wird bei jedem Aufruf von CFS im unteren Teil der Selektionsmaske einmal angezeigt. Bei der zweiten und allen folgenden Ausgaben der Selektionsmaske innerhalb des gleichen CFS-Laufs wird der Bulletintext nicht angezeigt. Die Jobvariable für den Text des Bulletins hat den Namen CFS.MESSAGE und muß unter der Kennung eingerichtet werden, unter der auch CFS gespeichert ist, z.B. $CFS Die Jobvariable muß außerdem shareable sein. Nach gegebener Zeit kann die Jobvariable vom Systemverwalter nonshareable gemacht, oder ganz gelöscht werden.
Benutzereigene FSTAT-Routine zum schnellen Kataloglesen
Der Systemverwalter hat die Möglichkeit, zum Zwecke einer beschleunigten Katalogverarbeitung eine eigene FSTAT-Routine in CFS zu integrieren. Diese Routine erhält als Eingabeparameter in Register 1 die Adresse der Parameterliste für einen FSTAT-Makroaufruf von der Art FSTAT datei,bereich,länge, LONG,MF=L. Aufgrund der in dieser Parameterliste abgelegten Parameter ist der Katalogeintrag für die gewünschte Datei in der gewünschten Länge im angegebenen Bereich bereitzustellen. Dieses Bereitstellen des Katalogeintrags kann durch direktes Kataloglesen mit Hilfe einer P2-Routine oder durch Ausführen eines FSTAT-Makros geschehen (FSTAT MF=(E,(1)).
Aufrufkonventionen:
R1 Adresse der Parameterliste
R13 Adresse einer 72 Byte langen Save-Area
R14 Returnadresse in CFS
R15 Ansprungadresse des Benutzermoduls
Die Registersicherstellung im Benutzermodul sollte nach den Standardkonventionen erfolgen:
STM   14,12,12(13)             (Ansprung)
 ...
LM    14,12,12(13)             (Rückkehr)
Returncodes:
Im Register 15 ist beim Verlassen der Routine ein Returncode an CFs zurückzugeben.
R15 = 0: Katalogeintrag für die gewünschte Datei wurde erfolgreich bereitgestellt.
R15 > 0: Katalogeintrag konnte für die gewünschte Datei nicht bereitgestellt werden.
R15 kann in diesem Fall z.B. mit dem DMS-Fehlercode gefüllt werden.
Die Einbindung der benutzereigenen FSTAT-Routine erfolgt über CFSMAIN durch Entfernen des Kommentarsterns vor der MVC-Anweisung, die die V-Adresse der Routine in den globalen CFS-Datenbereich überträgt. Durch Binden von CFS mit Hilfe der DO-Prozedur CFS.S.LMSLIB (CFSMAIN) wird die Benutzerroutine über Autolink oder durch eine explizite Include-Anweisung (INCLUDE FSTAT [, bibliothek] ) in CFS integriert.
Hinweis: Die FSTAT-Routine wird, falls aktiviert, stets zum Lesen der Katalogeinträge für die zu selektierenden Dateien verwendet. Dies gilt auch in den Fällen, in denen das Programm CFS unter Benutzerkennungen, die keine Privilegierung besitzen, geladen wurde.
9.  Ausgelieferte Dateien
CFS Gebundene Programmphase.
CFS.S.LMSLIB LMS-Bibliothek im PLAM-Format mit CFS Quellprogrammen, Prozeduren und Beispielen. Eine Beschreibung des Inhalts dieser Bibliothek folgt weiter unten.
CFS.SYSTEM.SYMBOLS Hilfsdatei zur symbolischen Anzeige verschiedener Systemtabellen (z.B. TCB/XVT) unter der CFS-Komponente TAS (Task Services).
CFS.README Diese Datei enthält Hinweise zum Thema "CFS als Subsystem".
CFSHELP Texte für die Helpfunktion von CFS.
CFSHELP-E Texte für die Helpfunktion von CFS in englischer Sprache. Bei Bedarf muß diese Datei in CFSHELP umbenannt werden.
CFSLIB Nachladebibliothek für CFS (PLAM-Format).
SYSSSD.CFS.xxx CFS-Subsystemdeklaration für verschiedene BS2000/OSD-Versionen.
Inhalt der Bibliothek CFS.S.LMSLIB
J/ASSEMB Übersetzungsprozedur für die in der Bibliothek gespeicherten Quellprogramme CFSMAIN, USRMOD, TEST, PREMOTE usw. Die Namen der Makrobibliotheken sind auf BS2000 Version 9.5 ausgerichtet. Als Übersetzungsprogramm wird ASSEMBF verwendet.
J/ASSEMB10 Wie oben. Die Namen der Makrobibliotheken sind jedoch auf BS2000 Version 10.0 ausgerichtet. Als Übersetzungsprogramm wird ASSEMBF verwendet.
J/ASSEMB11 Wie oben. Die Namen der Makrobibliotheken sind jedoch auf OSD V1 ausgerichtet. Als Übersetzungsprogramm wird ASSEMBH verwendet.
J/CFS.DO.CONV.CFSLIB Prozedur zur Umsetzung der CFSLIB in eine OML (LMR-Format).
J/CFS.DO.MIX.SDF Prozedur zum Einfügen der mitgelieferten Syntax-Datei CFS.SYNTAX in die zentrale Syntaxdatei von SDF. Die Prozedur setzt das Programm SDF-I voraus. Nach fehlerfreiem Ablauf der Prozedur sind die BS2000-Kommandos CFS und NP implementiert. Diese können nach dem nächsten Systemstart benutzt werden. Eine funktionelle Beschreibung der Kommandos finden Sie in der DO-Prozedur CFS.DO. START.
J/CFS.DO.PRINT DO-Prozedur zum Ausdrucken laseraufbereiteter CFS-Hardcopies. Zugehörig hierzu: CFS.ND-/HPFILE. Der Systemverwalter muß die PROC-Anweisung dieser Prozedur evtl. noch bezüglich der verwendeten HP-/NDFILE, sowie bezüglich der verwendeten Zeichensätze anpassen. Hinweise hierzu sind in der Prozedurdatei enthalten.
J/CFS.DO.START Diese Prozedur wird benötigt, falls das SDF-Kommando CFS im BS2000-System implementiert wurde (siehe hierzu auch die Dateien CFS.DO.SDF und CFS.SYNTAX). Nach Eingabe des Kommandos CFS wird diese DO-Prozedur zum Starten des Programms aufgerufen.
J/CFSHT CFS-Holdertask. Diese Enter-Datei muß vom Systemverwalter unter TSOS gestartet werden. Der Holdertask ermöglicht es Nicht-TSOS Benutzern, die User Option OPEN zu verwenden. Dem Benutzer werden in einer Liste alle Dateien angezeigt, die von Tasks eröffnet sind, welche unter der eigenen Kennung laufen. Der Holdertask ermöglicht es ferner, den momentanen Inhalt von sequentiellen Output-Dateien mit dem Action-Code D sichtbar zu machen. Außerdem können bestimmte TSOS-Kommandos dem nichtprivilegierten Benutzer zur Verfügung gestellt werden. Siehe hierzu auch die Beschreibung zum Element X/CFS.HTCMD weiter unten.
J/CFSLNK CFS-Binderprozedur. Hiermit wird aus den Modulen CFSMAIN und CFSUP eine ablauffähige Programmphase CFS gebunden.
J/CFSLNK1 CFS-Binderprozedur. Es werden zusätzliche Module wie z.B. MODR, USRMOD eingebunden, die sonst über LINK nachgeladen werden.
J/CFSLNK2 Prozedur zum Binden eines Großmoduls CFS. Weitere Informationen siehe CFS-Benutzerhandbuch, Kapitel 17 ("CFS als Unterprogramm").
J/GENHELP Prozedur zum Erstellen einer benutzereigenen Help-Datei CFSHELP. USER . Der Benutzer kann auf die Texte in dieser Help-Datei durch das Kommando ?USER zugreifen.
J/JESLNK Prozedur zum Binden eines Großmoduls JES aus dem benutzerspezifischen Vorlaufmodul JESMAIN und dem JES-Hauptmodul. Diese Prozedur ist nach jeder Änderung von JESMAIN aufzurufen.
J/REP Prozedur Eintragen des CPU-Reps in den aktuellen Modul MODR.
J/TASHT TAS-Holdertask. Diese Enter-Datei muß vom Systemverwalter unter TSOS gestartet werden. Der Holdertask ermöglicht es Nicht-TSOS Benutzern, eine eingeschränkte Auswahl der von der Komponente TAS angebotenen Funktionen zu nutzen. Die Auswahl der dem Benutzer zugänglichen Funktionen wird durch die maximale Testprivilegierung seiner Benutzerkennung geregelt. Für eine ausführliche Beschreibung wird auf das Quellprogramm S/TASMAIN in der CFS.S.LMSLIB verwiesen.
M/... Makros, die zum Übersetzen der mitgelieferten Quellprogramme (CFSMAIN, usw.) benötigt werden.
S/CEXIT0A Quellprogramm für Connection-Exit zur Prüfung der Benutzereingaben. Bezüglich der Aufrufparameter siehe entsprechende Inline-Dokumentation.
S/CFSHELP.HELPTABS Copy-Daten zur Generierung der CFSHELP.USER-Datei. Die Daten sind als Beispiel gedacht und können beliebig ergänzt oder durch andere Texte ersetzt werden.
S/CFSHELP.USER.MENUE Daten zur Generierung einer benutzereigenen Helpdatei CFSHELP. USER. Die Daten sind als Beispiel gedacht und können beliebig ergänzt oder durch andere Texte ersetzt werden. Das vorliegende Datenelement zeigt den Aufbau von Menues mit Verweisen auf die zugehörigen Textpassagen.
S/CFSMAIN Quellprogramm des Vorschaltmoduls für CFS. Im Quellprogramm selbst sind die Möglichkeiten der Änderung von CFS-Standardeinstellungen dokumentiert. Weitere Informationen siehe A 2-.
S/CONV Quellprogramm für benutzereigene Variable Actions. Das Programm realisiert die Variable Action ONXCONV. Benutzereigene Variable Actions müssen in Klammern angegeben werden (z.B. ONX(CONV) ). Weiterführende Informationen zu Benutzerexits finden Sie in Kapitel 17 des CFS-Benutzerhandbuchs.
S/FREE Quellprogramm für benutzereigene User Options. Das Programm realisiert die User Option FREE. Benutzereigene User Options müssen in Klammern angegeben werden. Weitere Informationen zu Benutzerexits finden Sie in Kapitel 17 des CFS-Benutzerhandbuchs.
S/IFUQ Quellprogramm des gleichnamigen Run-Moduls für die CFS-Prozedursprache (*RUN IFUQ .... ). Die Funktionen des Moduls sind im Quellprogramm beschrieben.
S/JESEXIT... Quellprogramme aller existierenden Benutzerexits in JES. Die entsprechenden Schnittstellen sind in einem eigenen Dokument beschrieben.
S/JESMAIN Quellprogramm des Vorschaltmoduls für die Komponente JES. Im Quellprogramm selbst sind die Möglichkeiten der Änderung von JES-Standardeinstellungen dokumentiert. Weitere Informationen finden Sie auch am Ende des Manuals JES-Benutzerbeschreibung.
S/PREMOTE Quellprogramm für einen benutzereigenen Action-Code. Das Programm realisiert den Action-Code PDxx. Benutzereigene Action-Codes müssen in einer internen Tabelle deklariert werden. Näheres hierzu siehe Programm CFSMAIN. Für eine Beschreibung der Funktionalität von PREMOTE siehe A 2-. Weiterführende Informationen zu Benutzerexits finden Sie in Kapitel 17 des CFS-Benutzerhandbuchs.
S/SETLEN Quellprogramm des gleichnamigen Run-Moduls für die CFS-Prozedursprache (*RUN SETLEN .... ). Die Funktionen des Moduls sind im Quellprogramm beschrieben.
S/SVAR Quellprogramm des gleichnamigen Run-Moduls für die CFS-Prozedursprache (*RUN SVAR .... ). Die Funktionen des Moduls sind im Quellprogramm beschrieben.
S/TASMAIN Quellprogramm des Vorschaltmoduls für die Komponente TAS. Im Quellprogramm selbst sind die Möglichkeiten der Änderung von TAS-Standardeinstellungen dokumentiert.
S/TEST Beispiel für ein Hauptprogramm, das CFS als Unterprogramm aufruft und bestimmte Funktionen nutzt. Weiterführende Informationen hierzu finden Sie in Kapitel 17 des CFS-Benutzerhandbuchs ("CFS als Unterprogramm").
S/USRMOD Quellprogramm des Moduls zur Aktivierung von Datenschutz- und Berechtigungsprüfungen bei einzelnen CFS-Funktionen. Eine ausführliche Beschreibung des Vorgehens finden Sie auf Seite A 2-.
VSNSP Quellprogramm für das CFS-Kommando (VSNSP). Benutzereigene Kommandos müssen in Klammern angegeben werden.
X/CFS.HPFILE Zeichensatz zum Ausdruck von laseraufbereiteten CFS-Hardcopies an 3352-Laserdruckern (HP-Druckern).
X/CFS.HPFILE.027 Zeichensatz zum Ausdruck von laseraufbereiteten CFS-Hardcopies an 3352-Laserdruckern (HP-Druckern). Für SPOOL Version 2.7.
X/CFS.HTCMD Diese Datei enthält die Angaben um privilegierte TSOS-Kommandos nicht-TSOS Benutzern zur Verfügung zu stellen. HTCMD ist eine Hilfsdatei zu J/CFSHT (CFS-Holdertask).
X/CFS.MENUE Beispiel für eine Menue-Datei. Näheres siehe Kapitel 10 des CFS-Benutzerhandbuchs ("Menue-System", Abschnitt "Format der Menue-Datei").
X/CFS.MENUE.FORMAT.x Beispiel für Maskendateien des Menue-Systems für Connections. Näheres siehe Kapitel 10 des CFS-Benutzerhandbuchs ("Menue-System für Connections", Abschnitt "Benutzerspezifische Gestaltung der Menue-Maske").
X/CFS.NDFILE Zeichensatz zum Ausdruck von laseraufbereiteten CFS-Hardcopies an 3350-Laserdruckern (ND-Druckern).
X/CFS.PDFILE Beispiel für eine PDFILE. Näheres siehe A 2- bzw. Beschreibung des Elements S/PREMOTE weiter oben.
X/CFS.SYNTAX Mit SDF-A erzeugte Syntax-Datei für die BS2000-Kommandos CFS und NP. In der Syntax-Datei ist der Name der DO-Prozedur zum Starten von CFS eingetragen (Standard: $CFS.CFS.DO.START). Die Benutzerkennung der Prozedur muß u.U. korrigiert werden.
X/CFS.SYSTEM.SYMBOLS Datei zur symbolischen Anzeige bestimmter Systemtabellen wie TCB und XVT durch das SHOW-Kommando der Komponente TAS (Task Services).
X/CFS.USERLIB.BEISPIEL PLAM-Bibliothek mit interessanten Anwendungsbeispielen für CFS-Prozeduren.
X/CFS.USERACT.BEISPIEL Datei zur Definition benutzereigener Action-Codes (%xy). Für weitere Informationen siehe CFS-Benutzerhandbuch, Kapitel 6. Nach dem Selektieren auf Platte sollte die Datei in CFS.USERACT umbenannt und shareable gemacht werden.
X/CFSHELPx.EXE Selbstextrahierende Archive mit den Windows-Hilfe Dateien zu CFS/TAS/JES/JESG. Die Dateien sind auf Platte zu selektieren und anschließend mit FTP im Binärformat zu einen DOS/Windows 3.1/Win 95/Win NT-Rechner zu transferieren. Nach korrekter Übertragung können die Dateien auf dem DOS-Prompt durch Aufruf des Kommandos CFSHELPA bzw. CFSHELPB entpackt werden. Dies sollte in einem Verzeichnis x: abc erfolgen, in dem die CFS Winhelp-Dateien letztendlich stehen sollen. Anschließend sind unter Windows zwei Icons mit folgender Befehlszeile zu erstellen:
winhelp xabc cfs.hlp
winhelp xabc info.hlp
X/CFSHELP-E Texte für die Helpfunktion von CFS in englischer Sprache. Bei Bedarf auf Platte selektieren, shareable machen und in CFSHELP umbenennen.
X/CFSTERM.0 Leerformular für CFS-Termfiles. Über eine Termfile kann geprüft werden, ob Benutzer bestimmte Connections eröffnen dürfen. Für ausführliche Informationen siehe A 2-.
X/CFSUSER.1 Beispiel für eine CFS-Userfile. Über eine Userfile können bestimmte User-ID's /Bildschirme von der Benutzung des CFS ausgeschlossen werden. Für ausführliche Informationen siehe A 2-.
X/CFS.SYSSSD.. Subsystemdeklarationen zu CFS für die verschiedenen BS2000/OSD-Versionen.