The most significant change in the boot process is the use of a new “MemoryDisk” boot method.

This small disk image is contained in the file SYS$COMMON:[SYS$LDR]SYS$MD.DSK. During boot, this device is represented as DMM0:; when connected as a logical disk at runtime, it is also represented as LDM1:

The minimum bootable VSI OpenVMS kernel occupies approximately one hundred and eighty files.

On prior architectures, during a network installation, the OS Loader (an EFI application) constructed a memory-resident, pseudo system disk containing a set of the essential directories found on a system disk. It then parsed a list of files, downloading and copying each file into its proper directory. The boot process ran from files in this memory-resident disk, eventually reaching a point where it could mount the real system disk and use runtime drivers for ongoing file access. The initial memory-resident disk was then dissolved.

This relatively slow and complex process resulted in an OS Loader that needed to understand VSI OpenVMS disk and file structures and was tied to the specific device and version of VSI OpenVMS being booted. It also required special primitive boot drivers for every supported boot device. Back when VSI OpenVMS ran on a limited set of systems from a single vendor, this was manageable, but for x86-64 we expect the OS to run on a much wider variety of systems.

The new MemoryDisk boot method eliminates most of this complexity and decouples the OS Loader (Boot Manager) from a specific device or instance of x86-64 VSI OpenVMS (V9.2-1). Instead of downloading a list of files and constructing a pseudo system disk image in memory at boot time, a single pre-packaged MemoryDisk container file (SYS$MD.DSK) is provided on distribution media (the Installation Kit) and on every bootable VSI OpenVMS system device.

The MemoryDisk contains all of the files that are required to boot the minimum VSI OpenVMS kernel. The Boot Manager loads the MemoryDisk into memory and transfers control to the secondary bootstrap program (SYSBOOT.EXE). It can do this using the physical BlockIO and FileIO drivers provided by UEFI, eliminating the need for VSI OpenVMS boot drivers and knowledge of VSI OpenVMS file systems. All of the files required by the dump kernel also reside in the MemoryDisk, allowing the dump kernel to directly boot from the pre-loaded MemoryDisk.

As the Boot Manager loads the MemoryDisk, it performs several security and integrity checks before transferring control to SYSBOOT.EXE. Errors in these checks are deemed fatal and result in clearing memory and performing a system reset. Future production releases of VSI OpenVMS will use “signed” kernel files, validated by SYSBOOT at load time.

An important concept to keep in mind is that the MemoryDisk is a container file that is structured as a bootable system disk, having its own (inner) boot blocks and GPT Partition Table, but containing only those files which are required by the early boot process; hence, a mini-kernel. When the system is running, the OS uses symlinks to direct file references to their actual location for any files that reside inside the MemoryDisk.

The contents of the MemoryDisk must be kept up to date. Any changes to these MemoryDisk-resident files through parameter file modifications, PCSI kit or patch installation, etc., require the operating system to execute a procedure to update the MemoryDisk container. This assures that the next boot will use the new images. This is handled by system utilities and is, for the most part, transparent to end users. The command procedure SYS$COMMON:[SYSUPD]SYS$MD.COM handles updating the MemoryDisk container.

The MemoryDisk is a Logical Disk (LD) container file named SYS$COMMON:[SYS$LDR]SYS$MD.DSK. Because this is an actual bootable disk image, it implements its own (inner) boot blocks consisting of a Protective Master Boot Record (PMBR), a GUID'ed? Partition Table (GPT) and multiple disk partition table entries (GPTE's).

The MemoryDisk image contains two ODS-5 structured partitions (signatures: X86VMS_SYSDISK_LOW and X86VMS_SYSDISK_HIGH) and one FAT-structured UEFI partition (signature: X86_EFI).

An installed system disk also has its own (outer) boot blocks consisting of GPT structures and three partitions, similar to the MemoryDisk. The outer boot blocks contain a pointer to the MemoryDisk. Therefore, we can boot a system disk, extracting the MemoryDisk from it, or we can directly boot a MemoryDisk. Direct boot of a MemoryDisk is primarily a development feature with some future uses.

During a normal boot from an installed system disk, the Boot Manager uses the outer boot blocks to locate and extract the MemoryDisk (SYS$MD.DSK) from the system disk. The MemoryDisk image is loaded into memory, represented as disk DMM0: and once the logical disk is connected (as LDA1:), it becomes the system device until the boot process reaches a point where it can mount the full, physical system disk. At that point, DMM0: is set offline but is retained in case the dump kernel needs to boot.

During a network installation, the entire Installation Kit image is downloaded into memory as DMM1: and (using the outer boot blocks) the embedded MemoryDisk DMM0: is extracted from the kit. In this one special case and only for the duration of the installation procedure, we have two memory-resident disk images: the Installation Kit (DMM1:) and the MemoryDisk contained within the Installation Kit (DMM0:). Both of these memory-resident disks are serviced by the new MemoryDisk driver: SYS$DMDRIVER.EXE

VSI OpenVMS is a three-partition system. Of the three disk partitions, the UEFI FAT-structured partition is the only partition that is recognized as a bootable partition by UEFI. Thus, during pre-boot execution, UEFI only sees this one partition and the files contained therein. This is where the VSI OpenVMS Boot Manager and any other UEFI executables reside. The other two ODS-5 structured partitions and the files they contain, remain invisible to UEFI.

Shell> MAP -B

A bootable VSI OpenVMS disk will have four device mappings associated with it; one file system (fsx:) device, where the Boot Manager resides, and three Block IO (blkx:) devices, representing the three partitions (one FAT and two ODS-5 partitions). Looking at these device paths, you will note that they contain, among other things, a PCI device path, a storage device type (SATA, Fibre, etc.) and a hard disk identifier (HD1, HD2, CD1, etc.). The bootable partition will always be shown as HD1. HD2 and HD3 are the ODS-5 partitions where the majority of VSI OpenVMS files reside.

If you want to launch a specific instance of the Boot Manager, then you will need to identify the UEFI fsx: device that is assigned to your desired boot disk (as you always had to do in Itanium systems). You can then switch to that fsx: device and to the \EFI\VMS folder where you will find and launch VMS_BOOTMGR.EFI. It is not always easy to sift through the UEFI device paths to locate your desired disk so it helps to familiarize yourself with device path nomenclature.

BOOTMGR> BOOT DKA0

BOOTMGR> BOOT fs2

When a BOOT command has been issued, the Boot Manager locates an "extent map" contained in the boot blocks of the target disk. The extent map contains the information required to locate and load the MemoryDisk and the secondary bootstrap image SYSBOOT.EXE which resides in one of the ODS partitions.

The Boot Manager loads the MemoryDisk and SYSBOOT.EXE using UEFI Block IO protocol and the LBA (Logical Block Address aka LBN) and size specified in the extent map. Because UEFI contains Block IO protocols for every supported type of boot device, we no longer need VMS-specific boot drivers. During early boot, while running memory-resident, SYSBOOT.EXE loads and uses the new VSI OpenVMS MemoryDisk driver (SYS$DMDRIVER). Later, during SYSINIT, device-specific runtime drivers are loaded for access to the full physical system disk.

The UEFI partition is implemented as a Logical Disk (LD) container file named [SYSEXE]SYS$EFI.SYS. This is a full implementation of the UEFI partition; the folders and filesare visible from the UEFI Shell including \EFI\BOOT, \EFI\VMS, \EFI\UPDATE and \EFI\TOOLS.

In order to allow the MemoryDisk itself to be a bootable entity, the MemoryDisk container file [SYSEXE]SYS$MD.DSK contains a reduced-functionality UEFI partition implemented as another Logical Disk (LD) container file named: [SYSEXE]MEM$EFI.SYS. Although there are no UEFI utilities in this boot-only UEFI partition, its (inner) boot blocks contain just enough information to locate and load SYSBOOT.EXE when the MemoryDisk is directly booted (this is a development feature).

To be technically complete, the installation files and kit must adhere to ISO-9660 structure and boot method. Per ISO specification, yet another copy of the UEFI partition exists as the ISO boot file. Per UEFI specification, the ISO boot file must be a UEFI partition instead of an executable image. Therefore, when an ISO DVD is detected by UEFI firmware, UEFI treats the ISO boot file as a file system partition and if the partition contains a UEFI application named \EFI\BOOT\BOOTX64.EFI. UEFI firmware automatically launches the application. In our case, this is a copy of the VSI OpenVMS Boot Manager. The net result is that the Boot Manager executes automatically when the Installation Kit file is assigned to an optical device or an Installation Kit DVD is inserted into the DVD drive.

Because of the automatic launch feature of DVD/optical discs that contain fsx:\EFI\BOOT\BOOTX64.EFI we strongly urge you to disconnect these devices after installation to prevent unwanted launching from the write-locked DVD device. After installation, you will want to launch the Boot Manager from fsx:\EFI\VMS\VMS_BOOTMGR on the installed disc.

There are several folders in the UEFI partition:

The following files may be found in the EFI\VMS and EFI\BOOT folders:

Additional files may appear as ongoing development occurs.

When the Boot Manager is launched, it scans the system hardware to locate all bootable devices. A bootable device is one that contains a GPT (GUID'ed Partition Table) and minimally, a UEFI partition. If the GPT contains structures indicating the presence of VSI OpenVMS partitions, the volume details (labels, size, etc.) will be displayed as a bootable VSI OpenVMS device by the DEVICE command. Network devices that support the Intel UNDI (Universal Network Device Interface) protocol are also considered bootable.

When a BOOT command is issued, the Boot Manager attempts to locate the MemoryDisk inside the boot source device. It does this by scanning the boot block structures for a specific signature. If found, additional extent records in the boot block indicate the LBA (Logical Block Address) and size of the MemoryDisk. Up to twenty-four extent records can describe the full MemoryDisk image. Because all device access at this early stage uses physical block references, the Boot Manager can use the built-in BlockIO drivers provided by UEFI to load the MemoryDisk into system memory. This same method is used regardless of whether we are booting an installed system disk or an installation kit from an optical drive or over a network.

The MemoryDisk image, actually an LD (Logical Disk) container file, has its own set of boot blocks. We refer to these as the inner boot blocks. The MemoryDisk container file resides within the system disk image, which has its own set of boot blocks. We refer to these as the outer boot blocks.

When booting from a virtual or physical device, the boot source device's (outer) boot block contains the location (Logical Block Address) and size of the MemoryDisk and the relative location and size of SYSBOOT.EXE within the MemoryDisk. SYSBOOT.EXE is the initial VSI OpenVMS bootstrap program to be loaded and executed.

When booting the Installation Kit over a network, the VMS_KITBOOT.EFI utility downloads the entire Installation Kit image. It then launches the Boot Manager. The Boot Manager, using the outer boot blocks, locates, extracts, validates and loads the MemoryDisk from within the memory-resident Installation Kit image and then, using the inner boot blocks, locates, extracts, validates, loads, and executes SYSBOOT.EXE.

Before transferring control to SYSBOOT.EXE, the Boot Manager performs a variety of other tasks required to prepare the system for execution including allocation and initialization of boot-related data structures, such as the Hardware Restart Parameter Block (HWRPB), enumeration of devices and establishing the memory maps. It does this for both the primary kernel and the dump kernel.

If a Bugcheck occurs at any point after VSI OpenVMS is booted, the dump kernel is already resident in system memory (this includes the MemoryDisk and a separate copy of SYSBOOT.EXE). The crashing primary kernel passes control to the dump kernel, which will rapidly boot, perform its tasks, and reset the system. This independent dump kernel provides for faster crash dump and shutdown processing using runtime device drivers.

The operating system procedures that build and maintain the MemoryDisk must also maintain the inner boot blocks of the MemoryDisk and the outer boot blocks of the system disk's UEFI partition. If system files that reside within the MemoryDisk are updated, by installation of a patch kit for example, the involved utilities will invoke a command procedure (SYS$MD.COM) to create a new MemoryDisk image so that any changes will be preserved for the next system boot. The system files that reside within the MemoryDisk are not files that a user or system manager would typically need to modify unless you need to add customer-developed execlets to be loaded during boot.

There are several ways to set up a system to automatically launch the VSI OpenVMS Boot Manager. Because the VMS Boot Manager is a standalone UEFI application, it can be launched from one disk and boot another. This can lead to confusion when several bootable disks are present, so the user needs to be careful about how this is set up.

Most UEFI implementations maintain a path-like list of all file system devices. UEFI can use this path to search for specific files among multiple disks. Such searches begin with fs0: and continue incrementally for the remaining fsx: devices.

Depending on the capabilities of the current system, the Boot Manager will operate in one of the four distinct modes..

The Boot Manager evaluates and selects the most capable mode in the following order:

When using the VSI OpenVMS Boot Manager, you can usually connect a remote terminal session to use in parallel with the graphical display. You will need a remote connection anyway for OPA0 interaction when the system boots.

The remote serial connection always uses the architectural COM 1 port (port address 0x3F8). Currently, only COM 1 is supported. Remote terminal utilities include the popular PuTTY program or similar terminal utilities. You can also set up a console connection via network (tcp port 2023 etc.) or named_pipes (i.e., \\.\pipe\<name> typically limited to a common host system unless a proxy server is used).

Unfortunately, the number and variety of utilities and remote access methods, along with the unique behaviors of the various VM hosts, make console port setup exceedingly difficult to describe. You may need to do some reading and experimenting to arrive at what works best for you.

Some platform firmware and VM hosts do not support remote connections to the UEFI Shell. Others may support output-only (no keyboard input) until VSI OpenVMS is booted. In all cases, the VSI OpenVMS Boot Manager will suspend keyboard input after a BOOT command has been issued. This is because the UEFI keyboard drivers terminate once the boot has begun, and keyboard input will not resume until the VSI OpenVMS runtime drivers take over (just in time to support a conversational boot dialog).

Output can be routed to one or more serial ports even when operating in one of the graphical modes. This can be useful for logging console output to a terminal emulator. The Boot Manager itself, does not provide logging, although it has a screen capture feature.

When booted, VSI OpenVMS always assumes the use of COM 1 for OPA0 interaction, except in specific instances where hardware does not support legacy COM ports.

On systems that provide a graphical display, the Boot Manager will attempt to load an optional background image file that may be customized by the user. A default background image has been provided by VSI.

The background image file must adhere to certain guidelines pertaining to format, dimensions, color depth, location and name.

The file location and name must be fsx:\EFI\VMS\VMS_IMG.BMP. If this file is found and it meets the specified guidelines, it will be used by the Boot Manager.

The background bitmap image must be non-compressed, BMP format with 24-bit color depth. Image dimensions must be a minimum of 1024 x 768 pixels and ideally, 1920 x 1080 pixels to support most common HD resolution monitors. If the image is smaller than the current display, it will be tiled as needed to fill the display. If the image is larger than the current display, it will be cropped. Image scaling and rotation are not supported.

A region in the upper left corner of the image, measuring 900 x 144 pixels, is reserved for overlaying the various buttons and the VSI Logo. The user cannot alter the placement or color of the graphical controls, so any custom image should provide adequate contrast in this region to assure that the controls remain visible. Selected controls are highlighted in red, so this too should be considered when selecting a custom image (avoid red). A VSI Copyright statement will be overlayed along the lower edge of the image. The text output area will be overlayed on top of the provided image.

If no suitable background image is found, the Boot Manager will fall back to the rendered text mode. In this mode the full display dimensions will be used for output. If this full size display mode is desirable, the user may rename or delete the bitmap image file. This effectively prevents the Boot Manager from entering graphical modes.

Some remote server management utilities and VM hosts will run the Boot Manager within a child window that is smaller than the physical monitor. Without having specific interfaces to these various utilities, the Boot Manager is unaware of the size of its containing window and will attempt to size its display according to the physical monitor size. This results in the need to scroll the window to see the complete Boot Manager display.

To improve usability when confined to a child window, do the following:

This will cause the Boot Manager to recalculate its display height to fit the window. This can also be handy if you would like to shrink the Boot Manager to save screen space. Changes to the display size are preserved in response to a BOOT, EXIT or SAVE command. If you wish to restore the full display size, issue the LINES command specifying an excessively large number of lines and the Boot Manager will determine the maximum number of lines it can use with the current monitor.

Note that the Boot Manager does not currently support display width adjustment.

The Boot Manager supports a limited form of text scrolling. The PAGE UP/PAGE DN keys will redisplay prior pages of text output. The number of pages that can be recalled depends on the density of text on each page, but in typical use, six or more pages can usually be recalled, which is sufficient for most users. Page numbers at the bottom left corner will indicate which page is currently displayed.

Commands that produce more than a single page of output will automatically pause as each full page has been displayed and the user may enter Q to quit the current command output.

Although the Boot Manager is able to automatically control multiple-page output, the PAGE command can be issued to enter "Page Mode." This will cause the display to pause at the end of each page and wait for the user to press a key to continue. The display will be cleared as each subsequent page is displayed. Page Mode greatly improves the display performance when using remote server management utilities, particularly when the display is being sent to a Web Browser interface. You can disable Page Mode using the NOPAGE command.

Occasionally it is useful to capture boot process output for presentation or problem reporting. End-to-end logging of the boot process can be difficult to accomplish due to the many transitions that occur during the boot process. For example, the graphical or text mode Boot Manager runs within UEFI Boot context. It transitions into UEFI Runtime context as it transfers control to VSI OpenVMS.

In UEFI Runtime context and beyond, the Boot Manager has no access to UEFI file protocols, thus precluding UEFI file based logging. When VSI OpenVMS is able to initialize its Operator Terminal Driver it can commence logging to an VSI OpenVMS file. Seamless logging of output across these complex transitions is best accomplished by routing Boot Manager and Operator output to a terminal session where logging of session output is possible.

When booting VSI OpenVMS as a VM guest, the VM host will often provide a means of logging a session. You may also define a serial port for your Virtual Machine that can be directed to a TCPIP port and address. In this case, you can route the output to a terminal emulator to provide both scrolling and logging capability.

The Boot Manager COM x command, where 'x' is the x86 architecturally defined COM Port number (1 through 4), will cause Boot Manager output to be echoed to the specified serial port. COM 0 disables this function. You may route output to multiple ports by issuing additional COM x commands.

COM 1 (0x3F8) will become the default port for OPA0 terminal communications once VSI OpenVMS has booted, even if Boot Manager output was disabled via COM 0 command.

Your selected COM port routing is preserved when you issue a BOOT, EXIT, or SAVE command.

Occasionally it is useful to project the display to a larger screen for demonstration or training purposes. This can be problematic due to the number of display resolution changes that occur between power-up BIOS, UEFI, Boot Manager and VSI OpenVMS. Experience has shown that most modern projectors will synchronize to the resolution used by UEFI. This is fine for projecting the initial power-up sequence. Once you launch the Boot Manager, the resolution will almost certainly increase and some projectors are not able to recognize the change. To accommodate this, we recommend that you avoid enabling output to your projector until you have launched the Boot Manager. This allows the projector to synchronize to the active resolution used by the Boot Manager.

User input on x86-64 systems is typically provided by a locally attached keyboard. This may be a standard keyboard, a USB keyboard, a local or remote serial terminal or terminal emulator. Some systems require that the console keyboard be plugged into a specific port in order to recognize it as a boot keyboard. This is particularly true for USB keyboards on systems with firmware that doesn't yet support USB 3.x speeds. Refer to your specific system documentation.

Many x86-64 systems, particularly in the mid-range and low-end space, do not provide traditional (RS232/454) serial ports. Hardware design requirements, driven by certain retail/entertainment operating systems, forbid the use of these serial ports due to incompatibilities with plug-and-play strategies. The fear is that devices can be connected and configured, then removed or exchanged with other devices without notification to the operating system. For this reason, traditional serial ports have been replaced by USB ports as the de-facto standard for console input devices.

USB input devices have their own set of issues. USB operation requires an active System Timer interrupt and more system resources to be available than required by a simple RS232 serial port. Developers that need to work in the early boot stages should use traditional serial port input in order to avoid temporary loss of console input during boot.

As the system boots, the various input devices must transition to a runtime driver environment. During this transition, there may be a brief period of time (typically a second or two) when these devices become unavailable. For developers using the XDelta debugger, this problem is avoided by using a traditional serial port keyboard or special serial debug port device instead of the USB keyboard.

The Boot Manager and system firmware support a minimum subset of keyboard functionality as required to boot the system. Special function keys and languages other than English are not currently supported by the Boot Manager. Systems that provide a mouse, touch-pad or touch-screen input device should function as expected, but special features of these devices, such as gesture recognition or specialized buttons, are not supported in the boot environment. Some VM hosts, such as VirtualBox, do not report mouse movement at all in the UEFI environment.

The keyboard UP and DOWN Arrows operate a command recall buffer. The RIGHT and LEFT Arrow keys move input focus to the next or previous button in a circular chain of buttons. Whenever the Arrow keys highlight a button, the ESCAPE or ENTER keys will activate the highlighted button. If the user presses any key other than the Arrow keys, input focus is returned to the Boot Manager command line. The PgUp and PgDn keys redisplay pages. Pay attention to the page numbers in the lower left corner of the display. The number of pages that can be redisplayed depends on the density of text in each page, but typically up to six pages of output can be redisplayed.

VSI OpenVMS has traditionally been dependent on UEFI Environment Variables to control certain aspects of the boot procedures. For x86 VSI OpenVMS, more emphasis is being given to running as a VM guest operating system. We have noted an inconsistency among the behavior of some VM hosts with regards to how they handle UEFI Environment Variables.

While most VM host applications support interfaces for managing Environment Variables, some fail to provide persistence of these values across power cycles. Worse yet, some VM hosts fail to provide the fundamental interfaces and also fail to report errors when these standard UEFI features are not available.

In order to address this problem, the Boot Manager maintains an internal structure containing the required variables and attempts to store or retrieve these variables from both Environment Variable (if present) and a UEFI binary file, fsx:\EFI\VMS\VMS_ENV.DAT

Using a binary file to store environment variables works with the VM hosts that preserve such files across power cycles, although there remain some persistence issues. The VMS_ENV.DAT file should not be edited. Nothing in the file is critical and the file is deleted if it fails various validity checks.

Developers and Support Personnel may benefit from detailed messages during boot procedures. The source and verbosity of these messages are controlled by Boot Flags. However, most commonly used message controls have Boot Manager commands or buttons that are easier to use than hexadecimal flag values.

In an effort to manage the number of messages that VSI OpenVMS can produce during boot, VSI OpenVMS on x86-64 has defined a subset of Boot Flags to control messages from specific phases of the boot procedures. The Boot Manager provides commands and buttons to control each of these phase-specific messaging features.

The boot phases having their own boot message flags include: BOOTMGR, SYSBOOT, EXECINIT, SYSINIT, ACPI, HWCONFIG and DRIVER. Both graphical mode check buttons and commands are provided for each of these flags.

In addition to each phase-specific message flag, the command or button [NO]VERBOSE controls the extent of message detail.

%SYSBOOT-I-PARAM, Loaded Parameter File

If the VERBOSE mode flag is SET, extended debug information will be provided. These messages are not held to format requirements and will take whatever form the developers felt would be useful for detailed troubleshooting.

Boot Flags are a 32-bit mask of numeric constants that enable or disable specific boot related features. These features include Boot Modes, Boot Messages and a variety of less common features.

The definition of boot flags has changed for VSI OpenVMS x86-64. Many of the earlier flags no longer applied to the x86-64 architecture or served functions that were unrelated to booting.

For VSI OpenVMS on x86-64, we have reorganized the flags into three categories:

The Boot Manager presents graphical check-buttons for the most commonly used flags and commands to set and clear individual flags by name. Note however, that most VM hosts do not support mouse movement under UEFI, so if you wish to use the graphical buttons, you will need to press the arrow keys to select a button, then press ENTER to toggle the state of the button. As an alternative, you can use commands to control the flag states.

Each Boot Flag has a corresponding command to set or clear the flag. All such Boot Manager commands can be prefixed with NO to clear the flag. For example: PROGRESS sets the Progress Message flag and NOPROGRESS clears the flag. Most commands can be abbreviated to a minimum number of unique characters.

A FLAGS command is also available for managing the full set of available flags. Entering the FLAGS command without an additional value will display and interpret the current Boot Flag settings. In graphical modes, a chart of flag bits will also be displayed. To set or clear Boot Flags the desired HEXIDECIMAL value can be provided following the FLAGS command. For example, FLAGS 1070 would set Boot Flag bits 4, 5, 6 and 12, enabling general boot PROGRESS messages and additional messages from SYSBOOT, EXEC_INIT and ACPI facilities.

When setting new flag values, be aware that the value you enter will supersede flags that had been set previously. For this reason, you may want to use the FLAGS command first to see the current value, then adjust the value to enable or disable the flag bit/s you are interested in.

The Boot Manager saves your Boot Flags value in response to a BOOT, EXIT, or SAVE command. Flag values that were set during a BOOT command will also be preserved as the default boot command string to be used on subsequent boots.

Boot Manager commands use a very simple syntax.

A command verb is followed by an optional parameter separated by a space.

Command verbs can be abbreviated to the smallest number of characters required to assure uniqueness. Certain commands having significant effect must be entered in full as a means of verifying user intent.

Commands that set a flag or enable a feature, are typically cleared by prefixing the verb NO in front of the original command. For example, the PROGRESS command enables a flag to produce boot progress messages. The NOPROGRESS command clears the flag. In other words, the Boot Manager does not use SET, CLEAR, ENABLE, or DISABLE command precursors.

The Boot Manager provides a limited command recall buffer that can be accessed with the UP or DOWN arrow keys. The Boot Manager supports a limited form of scrolled output using the PG_UP and PG_DN keyboard keys.

It is unusual for the early boot process to produce large amounts of text prior to transfer to VSI OpenVMS, at which point the Operator terminal and logging are available. In cases where Boot Manager commands produce more lines of output than will fit on a single screen, the Boot Manager may pause the output as text exceeds each visible display page.

In cases where a permanent log of Boot Manager output is desired, output can be directed to a COM Port and Terminal Emulator. These features are described in their respective command descriptions.

When operating in Graphical mode, common commands are represented by rows of push buttons. If a pointing device (mouse or touch-pad) is active, the push buttons can be activated as you would expect for a graphical application.

If no pointing device is active, the push buttons can be selected using the right arrow or left arrow keys. The selected button will be outlined in red. To activate the selected button, press ENTER or ESC keys. If you press any other keys, input focus will return to the command line.

Your internal company web server can be used to serve installations. Because of the variety of available web servers, this document will focus on general setup steps only. It is assumed that the web server is accessible to your VM host and that your guest's network configuration is able to access this same network.

The first two files listed below can be found in the EFI partition of any installed VSI OpenVMS V9.2-1 system disk at fsx:\EFI\VMS\ or they can be copied from an Installation Kit DVD.

Once these files are posted to your web server, you must next prepare the target system/guest.

UEFI firmware provides HTTP/S protocols to support connection to web servers. The legacy PXE (Pre-eXecution Environment) protocol is being phased out in favor of more capable boot protocols. The most popular of these protocols is known as iPXE. For more information about iPXE, refer to http://www.ipxe.org

VSI provides a small UEFI-based web server boot utility based on iPXE protocol; the utility is called VMS_KITBOOT.EFI. This file can be found in the EFI partition of any installed VSI OpenVMS V9.2-1 system disk at fsx:\EFI\VMS\ or it can be copied from an Installation Kit DVD. VSI Support can also provide this image upon request.

VMS_KITBOOT.EFI automates most of the web server boot process. When launched from the UEFI Shell of your VM guest, the VMS_KITBOOT utility will identify your system hardware, configure a suitable network device, prompt for the IP address of your web server and handle the connection and download protocol for the Installation Kit. When VMS_KITBOOT has finished downloading the kit it will launch the VSI OpenVMS Boot Manager to boot the installation procedure.

VMS_KITBOOT.EFI can be executed from any UEFI file system disk, for example fs0:. A simple way to do this is to copy the file onto a FAT-formatted USB stick assigned to your target system/guest. VM users can also use a pre-packaged Virtual Disk containing this file in common virtual disk formats.

The Boot Manager provides a bridge between the UEFI pre-boot environment and the early phase of system boot (SYSBOOT). Once control is transferred to SYSBOOT, the Boot Manager keyboard is no longer available for input (due to limited USB support in VSI OpenVMS V9.2-1) and the Boot Manager display shows only XDELTA and Operator terminal output. Normal interaction with VSI OpenVMS must occur through remote terminal session connection for both keyboard input and display output.

A variety of terminal utilities can be used with VSI OpenVMS. Telnet, SSH, Pipes and TCP are the most commonly used methods. It would be impractical to document every known terminal utility, so this document focuses on Telnet and assumes that the user can translate the methods to their chosen terminal utility.

As a general guideline, VSI OpenVMS assumes control over command processing, so you should ENABLE character command mode as opposed to line mode and DISABLE any functions that would modify the command line terminators (Carriage Returns and Line Feeds). Terminal utilities that attempt to negotiate connection details should be set up to avoid doing so. For example, Telnet may attempt auto-negotiation whereas a Raw connection won't. The result is that you may need to adjust your Telnet session to avoid duplicate line feeds, although a Raw session should work without similar concern.

In the serial port setup of your VM guest and in your terminal utility, define your named pipe as \\.\pipe\pipe_name, where pipe_name is simply a unique name you provide.  Using named pipes requires that your terminal utility reside on your VM host system. To use named pipes over a different network node, you will need to use a Named Pipe Proxy server.

BOOTMGR> COM 1

The Boot Manager and UEFI use 115200 baud, 8 bit, 1 stop bit, no parity. It will auto-negotiage other baud rates.

Refer to the Chapter 7 section if you have problems establishing a terminal session.

VMSBOX gn$ telnet 10.10.XX.XX XXXX
Trying 10.10.XX.XX..
Will send carriage returns as telnet <CR><LF>.
Connected to 10.10.XX.XX.
Escape character is '^]'.


  ENABLED:  Console output to COM 1

BOOTMGR>

BOOTMGR> PROGRESS

BOOTMGR> BOOT

If you are performing a web server installation, the default device will always be the MemoryDisk DMM0:

BOOTMGR> DEVICE

%SYSBOOT-I-PFNMAP,      Created PFN Memory Map
%SYSBOOT-I-MAP_MEMDSK,  Boot memory disk remapped to S2 space
%SYSBOOT-I-MEMDISKMOUNT, Boot memory disk mounted
%SYSBOOT-I-ALLOCPGS,    Loader huge pages allocated
%SYSBOOT-I-LOADFILE,    Loaded file [VMSSCOMMON.SYSLIBJSYSSPUBLIC_VECTORS.EXE
%SYSBOOT-I-LOADFILE,    Loaded file [VMSSCOMMON.SYSSLDR]SYSSBASE_IMAGE.EXE
%SYSBOOT-I-LOADSYSIMGS, Base system images loaded
%SYSBOOT-I-INITDATA,    Key system data cells initialized
%SYSBOOT-I-POOLINIT,    Created Paged and Nonpaged Pools
%SYSBOOT-I-ALLOCERL,    Allocated Error Log Buffers
%SYSBOOT-I-PXMLCOPY,    Copied PXML Database to S2 space
%SYSBOOT-I-CREATECPUDB, Created the CPU Database
96SYSBOOT-I-REMAP,      Moved HWRPB and SWRPB to system space
%SYSBOOT-I-CPUID,       Gathered CPUID information
%SYSBOOT-I-REMAPIDT,    Remapped IDT to system space
%SYSBOOT-I-INITCPUDB,   Initialized Primary CPU Database
%SYSBOOT-I-INITGPT,     Initialized Global Page Table
%SYSBOOT-I-CREATEPFNDB, Created PFN Database
%SYSBOOT-I-REMAPUEFI,   Remapping UEFI Services
%SYSBOOT-I-EFIEXIT,     Exiting Boot Services
%SYSBOOT-I-LOADFILE,    Loaded file [VMSSCOMMON.SYSSLDR]SYSSPLATFORM_SUPPORT.EXE
%SYSBOOT-I-LOADFILE,    Loaded file [VMSSCOMMON.SYSSLDR]ERRORLOG.EXE
%SYSBOOT-I-LOADFILE,    Loaded file [VMSSCOMMON.SYSSLDR]SYSSACPI.EXE
%SYSBOOT-I-LOADFILE,    Loaded file [VMSSC0MM0N.SYSSLDRJSYSTEM_PRIMITIVES_6.EXE
%SYSBOOT-I-LOADFILE,    Loaded file [VMSSCOMMON.SYSSLDRJSYSTEM_SYNCHRONIZATION_UNI.EXE
%SYSBOOT-I-LOADFILE,    Loaded file [VMSSCOMMON.SYSSLDR1SYSS0PDRIVER.EXE
%SYSBOOT-I-LOADFILE,    Loaded file [VMSSCOMMON.SYSSLDR]EXEC_INIT.EXE
%SYSBOOT-I-LOADEXEC,    Execlets loaded
%SYSBOOT-I-PARMSCOPIED, System parameters copied to the base image
%SYSBOOT-I-TRANSFER,    Transferring to EXEC_INIT at: ffff8300.1084bce0 fs
HPET period is 69841279 fs
For virtual machines, hardtick frequency is 100 per second
EXESGQ_SYSTIME address ffffffff80000b08 value 00b384ed66eb000


        VMS Software, Inc. VSI OpenVMS (TM) x86_64 Operating System 
                    Copyright 2022 VMS Software, Inc.

  MDS Mitigation active, variant haswell(HASWELL/BROADWELL)
%SYSBOOT-I-MEMDISKMOUNT. Boot memorv disk mounted

$

As the boot proceeds, you will eventually reach the VSI OpenVMS Installation Menu. At this point, the installation procedures are similar to a traditional installation. You will be prompted to select your target device to install to and any optional kits you wish to install.

The VSI OpenVMS installation procedure will need to reboot the OS a couple times before it is complete. Upon each reset or reboot, your VM guest should return to the UEFI Shell> prompt. At this prompt, perform a normal system boot as follows:

BOOTMGR> AUTO BOOT

To cause the Boot Manager to be launched automatically you can do one of two things:

vms_bootmgr DKA100: -fl 0,0 

$ SET FILE/ATTR=RFM:STMLF STARTUP.NSH

Now when your guest starts the UEFI Shell, the firmware will recognize one of these methods and launch the Boot Manager. The Boot Manager will execute its countdown and if not interrupted by user input, automatically issue the boot command.

The dump kernel is a limited-functionality VSI OpenVMS Kernel designed to handle crash dump data collection, compression and storage.

During boot, the dump kernel is created in parallel with the Primary Kernel. It resides in a separate memory space and shares the MemoryDisk. The dump kernel requires only 512MB of memory.

The MemoryDisk remains in memory after the primary kernel is booted and the device associated with the MemoryDisk (DMM0) is set offline and write-protected. A logical disk device LDMn (where n is a device number) is created during boot, to allow access to files residing in the MemoryDisk using symlinks.

Having a second kernel for crash dump processing reduces the dependency on the crashing system and allows greater flexibility in collecting, compressing and writing to the dump device(s) using runtime drivers. VSI OpenVMS x86-64 does not use the traditional Boot Drivers.

The dump kernel is loaded, but does not boot until the primary kernel encounters a Bugcheck. The Bugcheck process prepares the crashing system (halting processors, identifying important areas of memory, etc.), then transfers control to the dump kernel's SYSBOOT image and the dump kernel boots.

The dump kernel, being resident in memory, boots quickly. A dump kernel-specific startup procedure: [SYSEXE]SYS$DUMP_STARTUP.COM executes the dump kernel's main image: [SYSEXE]SYS$DUMP_KERNEL.EXE. The dump kernel maps and collects the important areas of memory, compresses and writes the data to the dump file SYSDUMP.DMP for later analysis.

Once the crash dump has been processed and the dump file has been written, the dump kernel will invoke a power off or system reset to restart the primary kernel and re-arm a new instance of the dump kernel.

The dump kernel has a few new system parameters to control its operation. These are described in following sections.

To create a dump file on your system disk, use SYS$UPDATE:SWAPFILES.COM. When the command procedure requests a file size, start with 200000 blocks (extend as needed).

To create a Dump File on a different disk, use the following procedure. In this example, we will use DKA100 and System Root 0 (SYS0):

$ CREATE/DIR DKA100:[SYS0.SYSEXE]
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CREATE DKA100:[SYS0.SYSEXE]SYSDUMP.DMP/SIZE=200000
SYSGEN> EXIT
$

$ SET DUMP_OPTIONS/DEVICE=DKA100:

The changes are effective immediately. A reboot is not necessary.

The SYSGEN parameter DUMPSTYLE must be set. VSI OpenVMS V9.2-1 supports only selective (bit 0) and compressed bit (3) dump features. Setting DUMPSTYLE to 9 enables these features for a dump to the system disk. Dumping to a non-system disk is always enabled, and there is no need to set bit 2 in DUMPSTYLE.

$ RUN SYS$SYSTEM:SYSGEN
USE CURRENT
SET DUMPSTYLE 9
WRITE ACTIVE
WRITE CURRENT
EXIT
$

No reboot is required after changing Dump control parameters if WRITE ACTIVE is included in the SYSGEN dialogue.

When the dump kernel completes its tasks, it will execute a user-specified automatic action to restart or power off the system. Several parameters are involved in defining this behavior. The following is a description of how these parameters interact.

The flags OPC$REBOOT and OPC$POWER_OFF are set or cleared in response to SHUTDOWN parameters (or answers to SHUTDOWN prompts).

Additional failure modes are handled by performing a system RESET to the UEFI Shell> and any specified automatic actions that follow. These failure modes include:

Crash analysis is beyond the scope of this guide. The traditional VSI OpenVMS crash analysis tools are available. The command $ ANALYZE/CRASH {dumpfile} is a good starting point.

Some terminal emulators will attempt to take ownership of a serial port if it is not already in use. If this happens, the VMS_KITBOOT procedure or the VMS_BOOTMGR utility may consider the port as unavailable and fail to make a connection.

If this occurs, you need to follow a specific sequence when connecting.

If you wish to direct Console IO to a system running Microsoft Windows, we recommend using the PuTTY terminal emulator. You can download PuTTY from http://putty.org. MobaXterm is another excellent terminal utility.

Depending on how the system you are running your terminal emulator on is connected to the target system, you should select a RAW or TELNET session. The RAW option works well with VSI OpenVMS. If using TELNET, you will need to adjust various settings described below to avoid duplicate output and line termination issues.

PuTTY has several nice features that allow for control of your session. If you are working remotely using a SSH connection through your VPN, make sure that the IP Address Forwarding option is enabled (typically it is by default).

Set up your PuTTY session as follows:

telnet> mode char

telnet> mode line

When using CentOS as the host for VirtualBox, we initially had trouble getting a serial port connection working.

In the VirtualBox VM Ports setup, the COM 1 port is set up to forward serial traffic through TCP Port 2023, but it was not working.

It turned out that CentOS had not enabled port 2023. Below is the solution. This applies to CentOS Version 7, but probably works on other versions too.

You can see if port 2023 is enabled with the following command:

# firewall-cmd --list-ports

You will get a system output similar to the following:

            
        23/tcp
    

As you can see, only port 23 was enabled.

If port 2023 was not listed, then the following two commands will fix the issue. Note that the --permanent flag assures that the port will be enabled on subsequent boots.

# firewall-cmd --permanent --add-port=2023/tcp

# firewall-cmd --reload

Now check again with the --list-ports command to verify that it is now enabled.