When $VMCONS is used as a BS2000 console of the guest system, the message traffic is handled as a VC dialog via $VMCONS (see "Leading a VC dialog").
The guest system can be started up and operated via the VC dialog. An example of this is provided in the section "Example of ADMIN and VC dialog via $VMCONS".
Implementing a VC dialog via $VMCONS connection to KVP (SU x86)
A VC dialog on SU x86 is implemented as a special connection to the KVP console of the cons0<kvp-name> ID of the KVP via which the guest system’s IPL was initiated. BS2000 outputs to this KVP console are output via $VMCONS. Inputs in the VC dialog are forwarded via $VMCONS and the KVP to the guest system like inputs from this KVP console.
Implementing a VC dialog via virtual console (SU /390)
A virtual console is a device that is generated as a physical console at hardware generation of the SU /390 but does not actually exist. If the virtual console is used as a BS2000 console of the guest system, the message traffic is executed as a VC dialog via $VMCONS (see "Leading a VC dialog").
Inputs/outputs via a virtual console are emulated by $VMCONS and the VM2000 hypervisor for the relevant guest system via the physical console as message traffic.
The guest system is started up and operated via the virtual console. An example is provided in the section "Example of ADMIN and VC dialog via $VMCONS". You cannot use a virtual console for the monitor system.
Generating the virtual console
Virtual consoles must be generated as devices, see "Device peripherals on SU /390".
Assigning the virtual console
Free devices that can be assigned to a VM as a virtual console have the suffix (VC) in the outputs of VM2000 information commands.
Virtual consoles must be assigned explicitly by means of /ADD-VM-DEVICES with the operand TYPE=*VC. They cannot be assigned implicitly. Each VM/each guest system can be assigned one virtual console. A virtual console cannot be assigned to the monitor VM.
Virtual consoles of a VM have the suffix (VC) in the outputs of VM2000 information commands.
Leading a VC dialog
The following stages are involved in operating a guest system with a VC dialog:
| Establish a connection to $VMCONS via OMNIS (see "Establishing a connection to $VMCONS") or via a suitable DCAM application. |
| Open a VC dialog with the following VM2000 command:
You must specify the OMNIS connection name Up to eight VC dialogs can be conducted in parallel with one guest system. If |
| Enter BS2000 commands and statements for operating the guest system on the VM. |
| Terminate the VC dialog with one of the VM2000 commands
When you enter When the |
All the VC dialogs of a guest system have the same command and message authorization. When BCAM is active in the guest system, logical consoles (e.g. via OMNIS) with differentiated privileges and privileged user tasks can be used.
When data transfer in a VC dialog is interrupted, outputs of the guest system are recognized and are reported to the VM or VM2000 administrator in message VMS1602.
In the following cases, $VMCONS is temporarily not available:
automatic restart in the monitor system (see also "Restart routines in VM2000")
failure of OMNIS
failure of the terminal or the connection to the terminal
Guest systems that are only operated via $VMCONS cannot be operated during this time.
 | On SU /390, the outputs of the guest systems in this period are either buffered (if the system parameter NBMSGCSD=N is set) and output as soon as $VMCONS is available again or only output to the CONSLOG file (NBMSGCSD=Y). |
 | Outputs of the guest systems are not buffered on SU x86 during this time because the associated KVP console remains operable from the BS2000 viewpoint. In the event of a connection failure (i.e. not in the case of a restart), some messages are buffered by the VM2000 Agent. However, all outputs are stored in the CONSLOG file or in KVP logging. |
GS prefix
The GS prefix is used to assign input or output to a guest system. It comprises the string GSnn:. Where nn is the index of the VM on which the guest system is running (2 digits, padded to the left with zeros, e.g. GS03:).
By default, VM2000 adds the GS prefix to all outputs from a VC dialog. If the VC dialog is opened with TYPE=*VC(OUTPUT-PREFIX=*NO), output of the GS prefix can be suppressed.
If a number of dialogs are conducted across a single connection to $VMCONS, entries made in the guest system must include the appropriate GS prefix if the assignment has not already been carried out by the preceding command. If several OMNIS connections are used, both identifiers, i.e. the OMNIS connection name and the GS prefix, must be added to any input, e.g. XY01:GS02:P.END.
Message flow when operating the guest system (SU /390)
Since all messages between the virtual console and the guest system are handled by the VM2000 hypervisor and the monitor VM (path (1) in Figure 8), this places an additional burden on the VM2000 hypervisor and the monitor VM.
To relieve the burden on the hypervisor if there is heavy input/output traffic across the virtual consoles, it is possible to define logical consoles for the guest system (e.g. using OMNIS) when BCAM is active in the guest system (see the “OMNIS/OMNIS-MENU” manual [12]).
If the BS2000 command /ADD-CONSOLE-FILTER FILTER=*ALL,ROUTING-CODE=*ALL is entered in a VC dialog, the virtual console is placed in the so-called NOINF status. In this status, all unanswered messages which are to be distributed (indicated by % and to be sent via a routing code) are suppressed.
Normal operating is then carried out on the logical consoles (path (2) in Figure 8). The virtual console is then only used to display emergency messages and to eliminate problems if a logical console fails.
OMNIS functions “color control” and “message tables”
The functions “color control“ and “message tables“ are described in detail in manual “OMNIS/OMNIS-MENU” [12].
The connection to $VMCONS is established, as described in the section "Establishing a connection to $VMCONS", via the OMNIS command OPNCON, but with specification of TYP=UCON. The guest systems can then be operated like UCON partners by OMNIS with color control and message tables.
Recommendation for dialog design with the UCON partner type
When a connection is established with the partner type UCON, the OMNIS functions “color control” and “message tables” are also activated for the virtual console. Since these functions require a specific message format, you should note the following:
Suppress the output of the VM2000 welcome screen when the connection is established by specifying a partner characteristic other than
OMS(see the note in the section "Establishing a connection to $VMCONS").Only conduct one VC dialog (
/BEGIN-VM-DIALOG VM-ID=..., PASSWORD=...,TYPE=*VC) via this connection to $VMCONS with the partner type UCON.Conduct the ADMIN dialog via another connection to $VMCONS with the partner type DCAM or conduct the ADMIN dialog from a privileged user task.
Color control
Depending on the DISPLAY-MODE, the messages of the guest system are colored according to their meaning. The DISPLAY-MODE can be set with the operand of the same name in the OMNIS commands SET, OPTION and DECLARE-TERMINAL.
Message tables
Console messages of a guest system are received by OMNIS via the UCON interface and are output in the VC dialog. OMNIS message tables automate operation of the guest system. Message tables allow you to
have receipt of a message signaled acoustically (
BELL=YES)suppress output of unimportant messages (
DISPLAY=NO)reply to messages automatically (
REPLY='&VMP:&TSN.<text>')respond to messages with an operator command (
REPLY='&VMP:/<cmd>')
Like the OMNIS placeholder &TSN, with which the reply is directed to the task that triggered the message, the placeholder &VMP is also available. However, this only has to be used when, contrary to the recommended procedure, several VC dialogs are conducted using only a single connection to $VMCONS. &VMP can then be used to send the reply to the guest system that sent the message (REPLY='&VMP:...').
The prerequisite for this is that these VC dialogs must be working with a GS prefix, i.e. they must have been opened with /BEGIN-VM-DIALOG ...,OUTPUT-PREFIX=*YES.
The message tables are normally predefined and are set up when OMNIS is started (OMNIS startup file). However, they can be created or modified during operation (OMNIS command MDEF, where the INSERT operand has no relevance). The OMNIS command INF MTAB provides information on current message tables.