VM:Operator Console Definitions
Article ID: 48135
Updated On: 11-22-2024
Products
Issue/Introduction
VM:Operator Console Definition Overview
Resolution
VM:Operator has a highly flexible operator interface capable of simultaneously driving multiple 3270 display consoles. The layout of a VM:Operator console is controlled by either CONSOLE or USERID files. The filenames of these files provide a unique console identification for authorization purposes. USERID files must correspond to a user ID on the VM system who is authorized to use VMYIAMOP. CONSOLE filenames must NOT correspond to any user ID on the system and can be used only with the console devices. VM:Operator consoles themselves are highly configurable and typically run a number of 'windows' that are driven by VM:Operator processes that are called window managers. Users typically use PF keys to switch between these console windows. VM:Operator supports three basic types of consoles: the VM logon console, dedicated consoles, and IUCV connected consoles.
The VM logon console is the virtual machine console, that is, the terminal you use when you logon to VM. The VM logon console's virtual address is defined by the CP directory entry's CONSOLE statement and is usually 009 but can be any other address you choose. CP simulates a line mode console but many CMS commands (like XEDIT) will use it in full screen mode (assuming it's a display console which is almost always the case). VM:Operator can start a console on the VM logon console if you specify a CONSOLE statement in the VMOPER CONFIG file using the logon console's virtual device address.
Dedicated consoles are just 3270 display devices that are attached to the user ID running VM:Operator. CP never writes anything on dedicated consoles as they are controlled exclusively by VM:Operator. They are usually defined as dedicated devices in the CP directory entry but they can also be attached via the CP ATTACH command or dialed via the CP DIAL command. The later requires a SPECIAL 3270 device definition in the CP directory. Most users do not use dialed consoles due to security concerns and also because they are detached when the virtual machine is IPLed, but we typically make use of them for testing. The VMOPER CONFIG file would normally have a CONSOLE statement for each dedicated console. At startup time VM:Operator will attempt to start these consoles if they are defined in the VMOPER CONFIG file. Dedicated consoles can also be started on the fly using the VM:Operator CONSOLE START command.
The third type of console is the IUCV connected console. These consoles are started when the CMS user issues the VMYIAMOP command so we usually refer to them as VMYIAMOP consoles. When VMYIAMOP is running it displays the VM:Operator console as it is defined in the USERID file whose filename corresponds to the user ID. Typically system programmers use VMYIAMOP to temporarily get access to the operator environment to see what is going on from their own user IDs. They are temporary because system programmers also need their virtual machines for other things. VMYIAMOP can temporarily disconnect the IUCV connection and then later resume it, or it can terminate the connection. Some customers prefer to have their operators only use VMYIAMOP consoles. The reason for this is to improve operator accountability, particularly at shift change time.
Now days all VM systems are IPLed from the Hardware Maintenance Console (HMC) which, among other things, has the ability to emulate a 3270 operator console. VM can also be configured to use other emulated consoles for the operator (no one uses real 3270s anymore). At IPL time, the OPERATOR user ID will be automatically logged on to whatever console is defined by the CP configuration. If the OPERATOR user ID is also defined to run CMS, then VM:Operator can be brought up automatically from the PROFILE EXEC.
Many sites prefer not to allow their operators to have direct access to the all powerful OPERATOR user ID for security reasons. They use VM:Operator to actually protect the OPERATOR virtual machine from misuse. Because of this and other reasons, they want the OPERATOR user ID to run disconnected and use only dedicated or VMYIAMOP consoles. To implement this, VM:Operator has the DISCONN startup parameter which insures VM:Operator will disconnect the VM logon console before any VM:Operator consoles are started.
Sites that run the OPERATOR on 3270s other than the one emulated by the HMC (which can't be attached to a virtual machine) usually want to use the VM logon console as a dedicated console. This can be achieved using a recommended procedure run by the PROFILE EXEC that changes the VM logon console into a dedicated console. This is done by disconnecting the VM logon console, disabling the device, and then attaching it to the virtual machine using the CP ATTACH command. That way if VM:Operator is terminated the operators do not have direct access to the unprotected OPERATOR VM logon console because it is disconnected. This technique also prevents overflow CP messages (messages that occur too frequently to be handled by VM:Operator) from disrupting VM:Operator consoles and causing confusion for the operators.
Feedback
