Bis BS2000 V10.0 war es nur möglich, den Zugang zu $CONSOLE über die Definition von berechtigten Benutzerprozessen in der Systemgenerierung (UCC-Anweisungen und starre Verknüpfung zu User-IDs) zu regeln. Die Berechtigungen der einzelnen Konsolen sind somit bereits in der Systemgenerierung festgelegt. Es handelt sich also um "generierte" Berechtigungsnamen.

Ab BS2000 V1 ist es möglich, bei der Anmeldung an $CONSOLE dynamische Berechtigungen zu verwenden. Nach der Anmeldung an die Anwendung $CONSOLE als logische Konsole mit dynamischem Berechtigungsnamen wird mit dem Kommando REQ-OP-ROLE die Berechtigung für eine bestimmte Menge von Kommandos und Routing-Codes angefordert. Die Anmeldung an $CONSOLE erfolgt über ein neues Format der Verbindungsnachricht.

	In CFS ist hierzu nach dem Eröffnen der Connection mit OCn$CONSOLE bei der Anforderung der Connection-Message folgendes anzugeben:

	$CONSOLE|@CONSOLE , user-id [, passwort] [, protv] [, DISCON=Y|N]

	Mit dem Parameter protv kann eine Protokollversion für die Konsolapplikation angegeben werden, die den zusätzlichen Austausch von Daten zwischen den Verbindungspartnern festlegt (siehe auch User-Makros NBBME, NBMAP). Die möglichen Werte sind: V00 | V01 | V02 .

	Mit $CONSOLE erfolgt die Anmeldung an das Operating als Terminal, mit @CONSOLE als Programm. Beide Möglichkeiten sind für den Benutzer absolut gleichwertig. Ein Unterschied besteht systemseitig darin, daß mit dem Parameter OPERATOR-ACCESS (siehe weiter unten) für eine User-ID der Konsolzugang lediglich für Terminals ($CONSOLE) oder Programme (@CONSOLE) zugelassen werden kann.

	Mit OPERATOR-PSW-CHECK (siehe unten) kann getrennt für Terminals und Programme festgelegt werden, ob das Passwort der User-ID bei der Anmeldung geprüft wird oder nicht.

	Mit OPERATOR-CHIPCARD (siehe unten) kann schließlich bei Konsolzugang als Terminal ($CONSOLE) eine oder mehrere Chipcard-IDs angegeben werden, die bei der Anmeldung gefordert werden. Diese, dem Joineintrag (der User-ID) zugeordneten Chipcard-IDs haben nur bei Zugang zu $CONSOLE eine Bedeutung. Andere dem Joineintrag zugeordnete Chipcard-IDs gelten nur bei einem Zugang zu $DIALOG.

Nach der erfolgreichen Anmeldung an das Operating muß sich der Benutzer mit dem Konsolkommando /REQ-OP-ROLE xxxxx einen Satz von Routing-Codes zuweisen, über die er verfügen darf. Mit der OPERATOR-ROLE wird somit auch die Menge der Kommandos bestimmt, die für den Benutzer in dieser Konsolverbindung möglich sind. Um eine Operator-Rolle xxxxx zu erstellen, müssen unter der Kennung SYSPRIV die folgenden Kommandos ausgeführt werden:

	/CREATE-OP-ROLE xxxxx , ROUTING-CODES=( .... )

	Hiermit werden die zu der Operator-Rolle gehörenden Routing-Codes und damit die ausgegebenen Meldungen und die erlaubten Konsolkommandos festgelegt.

	/MODIFY-OP-ATTRIBUTES USER-ID=user-id , ADD-OP-ROLE=xxxxx

	Hiermit wird die Zuordnung der Operator-Rolle zu einer User-ID festgelegt. Es wird also einer User-ID ermöglicht, diese Rolle über REQ-OP-ROLE zu beantragen.

	Ab BS2000 V3.0 und SECOS 4.0 ist es möglich, physikalische Konsolen in einem neuen inkompatiblen Modus zu betreiben. In diesem Modus muß sich der Operator anmelden, um an der Konsole Kommandos eingeben oder Meldungen beantworten zu können.

	Zur Anmeldung muß als erstes ein Kommando SET-LOGON-PARAMETERS eingegeben werden.

	Nach erfolgreichem LOGON ist mit dem Konsol-Kommando /REQ-OP-ROLE xxxxx ein Satz Routing-Codes anzufordern, über die der Operator verfügen darf.

	Die Abmeldung des Operators von der Konsole erfolgt mit EXIT-JOB.

	Über den Systemparameter NBCONOPI=N|Y wird bei der Systemeinrichtung festgelegt, ob die physikalischen Konsolen im alten (kompatiblen) oder im neuen inkompatiblen Modus betrieben werden sollen.

OP-LP	Es wird eine Liste mit den wesentlichen Merkmalen der Logon Protection für den Konsolzugang mit dynamischen Berechtigungsnamen (siehe oben) ausgegeben. Das Format der Liste ist auf Seite beschrieben.

	Für die User Option OP-LP existieren keine Selektionsparameter.