On a physical Alpha server the hardware name is given by the used hardware.
Example: AlphaStation 500.
On a vtAlpha emulator the hardware name can be changed.
In vtMonitor, the value of the menu item Custom Model Name is used as hardware name by OpenVMS.
Hardware Model
On a physical Alpha server the System Marketing Model (SMM) is given by the used hardware.
Example: 1983 for an Alphaserver DS20.
On a vtAlpha emulator the System Marketing Model can be changed.
In vtMonitor, the value of the menu item SMM is used as System Marketing Model by OpenVMS.
Auto-boot action on emulator start
Auto-boot on a vtAlpha emulator is controlled by the console parameter auto-action.
Example: >>> set auto_action restart
The default action is: halt
Possible options:
HALT
The virtual Alpha will remain in the halt state. Manual intervention is needed to boot the operating system.
BOOT
After a boot, the operating system will be booted automatically. No manual intervention is needed.
RESTART
After a shutdown or an operating failure, the operating system will be booted automatically. No manual intervention is needed.
To make this work, a default boot device must be set.
Example: >>> set bootdef_dev dka0
Defines the default boot device to be disk DKA0.
Hibernate
In OpenVMS, a hibernated process refers to a process that has been placed in a waiting state(similar to suspension) but with
some unique OpenVMS-specific behaviors. Unlike traditional OS hibernation (where state is saved to disk),
OpenVMS hibernation is more like an efficient sleep state managed by the scheduler.
What Happens When a Process is Hibernated in OpenVMS?
1.
Process State Saved in Memory
The process remains in RAM (not written to disk, unless swapped out due to memory pressure).
Its execution context (registers, program counter, etc.) is preserved.
2.
No CPU Usage
The process does not consume CPU cycles while hibernated.
3.
Waiting for a Wake-Up Event
The process typically hibernates voluntarily (e.g., waiting for an event, I/O, or a timer).
It can be explicitly awakened by another process or a system event.
4.
Can Be Swapped Out
If system memory is low, OpenVMS may swap the hibernated process to disk (similar to paging).
Common Use Cases in OpenVMS
Batch Jobs - Pausing until resources are available. Real-Time Applications - Waiting for sensor input or timers. Inter-Process Coordination - Synchronizing with other processes.
Current
In OpenVMS, when a process has the state CUR, it means that the process is the currently executing process on the CPU.
Key Points:
- Only one process per CPU can be in the CUR state at any given time.
- The OpenVMS scheduler switches processes between CUR and COM states based on priority and scheduling policies.
CPU in Detail - State
In OpenVMS, the CPU state will show status information of a CPU.
RUN
The CPU is active.
STOPPED
The CPU is stopped.
CPU in Detail - System
This message appears in OpenVMS system displays (like SHOW CPU or MONITOR CPU) and provides information about the system its
clustering status and resource allocation:
Breakdown of the Components:
PRIMARY:
Indicates this node is the primary (first) node in the VMScluster.
QUORUM:
Shows that this system has quorum (enough voting members present to maintain cluster operation).
RUN:
The system is currently running (as opposed to being paused or halted).
RAD0:
Refers to Resource Affinity Domain 0 - this is related to CPU/memory affinity in NUMA (Non-Uniform Memory Access) systems.
Technical Context:
- In an OpenVMS cluster, the PRIMARY designation is important for certain cluster-wide operations.
- QUORUM status is critical - without it, the cluster might halt to prevent split-brain scenarios.
- RAD0 indicates the CPU's placement in the system's physical architecture, which can affect performance for memory-intensive operations.