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.
Local Event Flag
On OpenVMS, the Local Event Flag is a synchronization mechanism that allows a process to wait for one or more event flags
to be set before continuing execution. Here's how it works:
Key Concepts
Event Flags:
OpenVMS maintains 64 event flags (numbered 0-63) for each process, divided into:
- Local event flags (0-31)
- Common event flags (32-63) that can be shared between processes
Local Event Flag:
A process can wait for one or more local event flags (0-31) to be set using system services.
Characteristics
Process-Specific: - Local event flags are only visible to the process that owns them. No Queuing: - Multiple wait requests on the same flag don't queue - only one wait is satisfied when the flag is set. Automatic Clearing: - Some system services automatically clear event flags after a wait is satisfied.
Used for Synchronization:
Commonly used to coordinate between different parts of a process or between a process and AST (Asynchronous System Trap) routines.
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.
CPU in Detail - CPU State
In OpenVMS, the CPU state is a system parameter that indicates the current operational status of a CPU in a multiprocessing
(MP) system. The possible states you listed (RC, PA, PP, CV, PV, PMV, PL) are abbreviations representing different CPU states.
CPU States in OpenVMS:
RC (Reserved Compute)
The CPU is reserved for compute-bound processes (high-priority computations).
Typically used for real-time or high-performance workloads.
PA (Primary Available)
The CPU is available for general use and can execute any process.
This is the default state for primary CPUs in an OpenVMS system.
PP (Primary Present)
The CPU is physically present but not necessarily available for scheduling (e.g., still initializing or in a transitional state).
May transition to PA once fully operational.
CV (Cluster Visible)
The CPU is visible to other nodes in an OpenVMS Cluster but is not necessarily available for local process scheduling
Used in clustered environments for load balancing.
PV (Pooled Virtual)
The CPU is part of a processor pool (used in Capacity-Based Licensing environments).
Can be dynamically allocated to different nodes in a cluster.
PMV (Pooled Virtual and Member Virtual)
The CPU is both pooled (available for cluster-wide use) and a member of a virtual machine (if running under virtualization).
Used in complex virtualized or cloud-based OpenVMS environments.
PL (Pooled Licensed)
The CPU is part of a licensing pool (used with OpenVMS Capacity-Based Licensing).
Allows flexible CPU activation based on license agreements.
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.
CPU in Detail - CPU State
In OpenVMS, the CPU state is a system parameter that indicates the current operational status of a CPU in a multiprocessing
(MP) system. The possible states you listed (RC, PA, PP, CV, PV, PMV, PL) are abbreviations representing different CPU states.
CPU States in OpenVMS:
RC (Reserved Compute)
The CPU is reserved for compute-bound processes (high-priority computations).
Typically used for real-time or high-performance workloads.
PA (Primary Available)
The CPU is available for general use and can execute any process.
This is the default state for primary CPUs in an OpenVMS system.
PP (Primary Present)
The CPU is physically present but not necessarily available for scheduling (e.g., still initializing or in a transitional state).
May transition to PA once fully operational.
CV (Cluster Visible)
The CPU is visible to other nodes in an OpenVMS Cluster but is not necessarily available for local process scheduling
Used in clustered environments for load balancing.
PV (Pooled Virtual)
The CPU is part of a processor pool (used in Capacity-Based Licensing environments).
Can be dynamically allocated to different nodes in a cluster.
PMV (Pooled Virtual and Member Virtual)
The CPU is both pooled (available for cluster-wide use) and a member of a virtual machine (if running under virtualization).
Used in complex virtualized or cloud-based OpenVMS environments.
PL (Pooled Licensed)
The CPU is part of a licensing pool (used with OpenVMS Capacity-Based Licensing).
Allows flexible CPU activation based on license agreements.