Wenn $VMCONS als BS2000-Konsole des Gastsystems verwendet wird, dann wird der Nachrichtenverkehr als VC-Dialog über $VMCONS abgewickelt (siehe "Führen eines VC-Dialogs").
Über den VC-Dialog kann der Startup und das Operating des Gastsystems durchgeführt werden. Ein Beispiel dazu finden Sie im Abschnitt "Beispiel zum ADMIN- und VC-Dialog über $VMCONS".
Realisierung eines VC-Dialogs über $VMCONS-Anschluss an KVP (SU x86)
Ein VC-Dialog auf SU x86 wird realisiert als ein spezieller Anschluss an die KVP-Konsole der Kennung cons0<kvp-name> desjenigen KVPs, über den der IPL des Gastsystems eingeleitet wurde. BS2000-Ausgaben auf diese KVP-Konsole werden über $VMCONS ausgegeben. Eingaben im VC-Dialog werden über $VMCONS und das KVP wie Eingaben von dieser KVP-Konsole an das Gastsystem weitergeleitet.
Realisierung eines VC-Dialogs über virtuelle Konsole (SU /390)
Eine virtuelle Konsole ist ein Gerät, das bei der Hardware-Generierung der SU /390 als physikalische Konsole generiert, aber nicht vorhanden ist. Wird die virtuelle Konsole als BS2000-Konsole des Gastsystems verwendet, wird der Nachrichtenverkehr als VC-Dialog über $VMCONS abgewickelt (siehe "Führen eines VC-Dialogs").
Ein-/Ausgaben über virtuelle Konsole werden von $VMCONS und dem VM2000-Hypervisor für das jeweilige Gastsystem als Nachrichtenverkehr über die physikalische Konsole emuliert.
Über die virtuelle Konsole wird der Startup und das Operating des Gastsystems durchgeführt. Ein Beispiel dazu finden Sie im Abschnitt "Beispiel zum ADMIN- und VC-Dialog über $VMCONS".
Für das Monitorsystem kann keine virtuelle Konsole verwendet werden.
Generieren der virtuellen Konsole
Virtuelle Konsolen müssen als Geräte generiert werden, siehe "Geräteperipherie an SU /390".
Zuordnen der virtuellen Konsole
Freie Geräte, die einer VM als virtuelle Konsole zugeordnet werden können, sind in den Ausgaben der Informationskommandos von VM2000 durch den Suffix (VC) gekennzeichnet.
Virtuelle Konsolen müssen mit /ADD-VM-DEVICES, Operand TYPE=*VC explizit zugeordnet werden. Sie können nicht implizit zugeordnet werden. Jeder VM/jedem Gastsystem kann eine virtuelle Konsole zugeordnet werden. Der Monitor-VM kann keine virtuelle Konsole zugeordnet werden.
Virtuelle Konsolen einer VM werden in den Ausgaben der Informationskommandos von VM2000 durch den Suffix (VC) gekennzeichnet.
Führen eines VC-Dialogs
Die Bedienung eines Gastsystems im VC-Dialog wird in folgenden Schritten durchgeführt:
| Verbindungsaufbau zu $VMCONS über OMNIS (siehe "Verbindungsaufbau zu $VMCONS") oder über eine geeignete DCAM-Applikation. |
| Eröffnen eines VC-Dialogs durch das VM2000-Kommando
Der OMNIS-Verbindungsname Mit einem Gastsystem können bis zu acht VC-Dialoge parallel geführt werden. Bei Angabe von |
| Eingabe von BS2000-Kommandos und -anweisungen zur Bedienung des Gastsystems auf der VM. |
| Beenden des VC-Dialogs durch eines der VM2000-Kommandos
Bei Bei |
Alle VC-Dialoge eines Gastsystems besitzen die gleiche Kommando- und Meldungsberechtigung. Wenn BCAM im Gastsystem aktiv ist, dann können logische Konsolen (z.B. über OMNIS) mit differenzierter Privilegierung und privilegierte Benutzertasks eingesetzt werden.
Wenn der Datentransfer eines VC-Dialogs unterbrochen ist, dann werden Ausgaben des Gastsystems erkannt und mit der Meldung VMS1602 an den VM- bzw. VM2000-Administrator gemeldet.
In folgenden Fällen steht $VMCONS vorübergehend nicht zur Verfügung:
automatischer Restart im Monitorsystem (siehe auch "Wiederanlaufroutinen von VM2000")
Ausfall von OMNIS
Ausfall des Terminals oder der Verbindung zum Terminal
Gastsysteme, die nur über $VMCONS bedient werden, können in diesem Zeitraum nicht bedient werden.
| Auf SU /390 werden die Ausgaben der Gastsysteme in dieser Zeit entweder zwischengespeichert (wenn der Systemparameter NBMSGCSD=N ist) und ausgegeben, sobald $VMCONS wieder verfügbar ist, oder aber nur in die CONSLOG-Datei ausgegeben (NBMSGCSD=Y). |
| Auf SU x86 werden die Ausgaben der Gastsysteme in dieser Zeit nicht zwischengespeichert, weil die zugehörige KVP-Konsole aus BS2000-Sicht betriebsbereit bleibt. Bei einem Verbindungsausfall (also nicht bei einem Restart) werden einige Meldungen vom VM2000-Agenten zwischengespeichert. Alle Ausgaben werden aber in der CONSLOG-Datei bzw. im KVP-Logging gespeichert. |
GS-Präfix
Das GS-Präfix kennzeichnet den Bezug einer Eingabe oder einer Ausgabe zu einem Gastsystem. Es besteht aus der Zeichenfolge GSnn:. Dabei ist nn der Index der VM auf der das Gastsystem abläuft (2 Ziffern, linksbündig mit Null aufgefüllt, z.B. GS03:).
Standardmäßig wird allen Ausgaben des VC-Dialogs von VM2000 das GS-Präfix vorangestellt. Bei der Eröffnung des VC-Dialogs mit TYPE=*VC(OUTPUT-PREFIX=*NO) kann die Ausgabe des GS-Präfix unterdrückt werden.
Werden mehrere Dialoge über eine Verbindung zu $VMCONS geführt, muss, falls die Zuordnung nicht durch das vorangehende Kommando bereits erfolgt ist, den Eingaben an das Gastsystem das passende GS-Präfix vorangestellt werden.
Bei Verwendung von mehreren OMNIS-Verbindungen ist es in diesem Fall nötig, beide Identifikationen, den OMNIS-Verbindungsnamen und das GS-Präfix, einer Eingabe voranzustellen, z.B. XY01:GS02:P.END.
Nachrichtenfluss bei der Bedienung des Gastsystems (SU /390)
Da der gesamte Nachrichtenverkehr zwischen virtueller Konsole und Gastsystem über den VM2000-Hypervisor und die Monitor-VM abgewickelt wird (Weg (1) im Bild 8), entsteht zusätzlicher VM2000-Hypervisor- und Monitor-VM-Overhead.
Zur Vermeidung des Overheads bei starkem Ein-/Ausgabeverkehr über die virtuelle Konsole können bei aktivem BCAM im Gastsystem (z.B. über OMNIS) logische Konsolen und privilegierte Benutzertasks für das Operating im Gastsystem eingerichtet werden (siehe Handbuch „OMNIS/OMNIS-MENU“ [12]).
Wird im VC-Dialog das BS2000-Kommando /ADD-CONSOLE-FILTER FILTER=*ALL,ROUTING-CODE=*ALL eingegeben, wird die virtuelle Konsole in den so genannten NOINF-Zustand gebracht. In diesem Zustand werden alle unbeantwortbaren, zu verteilenden Meldungen (durch % gekennzeichnet und über einen Routing-Code zu senden) unterdrückt.
Das normale Operating erfolgt dann über die logischen Konsolen (Weg (2) im Bild 8). Die virtuelle Konsole dient dann nur noch zur Anzeige von Emergency-Meldungen und zur Behebung von Problemen bei ausgefallener logischer Konsole.
OMNIS-Funktionen „Farbsteuerung“ und „Meldungstabellen“
Die Funktionen „Farbsteuerung“ und „Meldungstabellen“ sind detailliert beschrieben im Handbuch „OMNIS/OMNIS-MENU“ [12].
Der Verbindungsaufbau zu $VMCONS erfolgt, wie auf "Verbindungsaufbau zu $VMCONS" beschrieben, über das OMNIS-Kommando OPNCON, jedoch unter Angabe von TYP=UCON. Dann können die Gastsysteme wie UCON-Partner von OMNIS mit Farbsteuerung und Meldungstabellen bedient werden.
Empfehlung für die Dialoggestaltung mit dem Partnertyp UCON
Durch einen Verbindungsaufbau mit Partnertyp UCON werden die OMNIS-Funktionen „Farbsteuerung“ und „Meldungstabellen“ aktiviert. Da diese Funktionen ein bestimmtes Nachrichtenformat voraussetzen, sollten Sie Folgendes beachten:
Unterdrücken Sie die Ausgabe des VM2000-Begrüßungsbildschirmes beim Verbindungsaufbau durch Angabe einer Partnercharakteristik ungleich
OMS(siehe Hinweis auf "Verbindungsaufbau zu $VMCONS").Führen Sie über diese Verbindung nur einen VC-Dialog (
/BEGIN-VM-DIALOG VM-ID=...,PASSWORD=...,TYPE=*VC) mit Partnertyp UCON zu $VMCONS.Führen Sie den ADMIN-Dialog über eine andere Verbindung mit Partnertyp DCAM zu $VMCONS oder führen Sie den ADMIN-Dialog aus einer privilegierten Benutzertask heraus.
Farbsteuerung
Die Nachrichten des Gastsystems werden, abhängig vom DISPLAY-MODE, entsprechend ihrer Bedeutung eingefärbt. Der DISPLAY-MODE kann mit dem gleichnamigen Operanden in den OMNIS-Kommandos SET, OPTION und DECLARE-TERMINAL eingestellt werden.
Meldungstabellen
Konsolmeldungen eines Gastsystems werden von OMNIS über die UCON-Schnittstelle empfangen und im VC-Dialog ausgegeben. OMNIS-Meldungstabellen automatisieren das Operating im Gastsystem. Über Meldungstabellen können Sie
den Meldungsempfang akustisch anzeigen (
BELL=YES)die Ausgabe unwichtiger Meldungen unterdrücken (
DISPLAY=NO)Meldungen automatisch beantworten (
REPLY='&VMP:&TSN.<text>')auf Meldungen mit einem Operatorkommando reagieren (
REPLY='&VMP:/<kdo>')
Analog zum OMNIS-Platzhalter &TSN, mit dem die Antwort an die meldungsauslösende Task geleitet wird, gibt es den Platzhalter &VMP, der jedoch nur verwendet werden muss, falls, entgegen der Empfehlung, unter einer Verbindung zu $VMCONS mehrere VC-Dialoge geführt werden. Mit Hilfe von &VMP kann dann die Antwort an das Gastsystem, das die Meldung gesandt hat, übermittelt werden (REPLY='&VMP:...').
Voraussetzung dafür ist, dass diese VC-Dialoge mit GS-Präfix arbeiten, d. h. mit /BEGIN-VM-DIALOG ...,OUTPUT-PREFIX=*YES eröffnet wurden.
Die Meldungstabellen werden normalerweise fest definiert und beim Start von OMNIS aufgebaut (Startup-Datei von OMNIS). Sie können aber auch im laufenden Betrieb erstellt oder geändert werden (OMNIS-Kommando MDEF, dabei ist der Operand INSERT ohne Bedeutung). Informationen über aktuelle Meldungstabellen erhalten Sie mit dem OMNIS-Kommando INF MTAB.