Hardware Name

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.

Computable

In OpenVMS, when a process has the state COM, it means the process is in Computable state.

Explanation of COM State:

A process in COM state is ready to execute but is waiting for an available CPU.
It is placed in the computable queue (also called the scheduler queue) until the OpenVMS scheduler assigns it CPU time.
This state indicates that the process has all necessary resources (memory, I/O, etc.) to run but is waiting for its turn
in the CPU scheduling rotation.

Conclusion:

If a process is in COM, it is healthy and ready to run but is waiting for CPU allocation. If many processes are stuck in COM,
it may indicate high CPU contention.

Miscellaneous Wait

In OpenVMS, the MWAIT state of a process indicates that the process is in a modifiable wait state.

Meaning of MWAIT State:

A process in MWAIT is waiting for an event or resource but can be modified or interrupted (e.g., by a debugger or another process).
This is different from a non-modifiable wait state (HIB or LEF) where the process cannot be easily interrupted.

A process in MWAIT is typically waiting for:

- I/O completion (IO wait).
- A lock to be released (LCK wait).
- A timer expiration (TIM wait).
- A resource like a mailbox or event flag (MBX, EF).

Common Transitions Involving MWAIT:

- CUR (Current) → MWAIT: The process was running but is now waiting for an event.
- MWAIT → COM (Computable): The wait condition is satisfied, and the process is ready to run.
- MWAIT → HIB (Hibernating): If the process is explicitly put to sleep (e.g., via $HIBER).

Conclusion:

MWAIT is a normal state indicating that a process is waiting for an event but can still be modified or interrupted.
If a process remains in MWAIT longer than expected, further investigation (e.g., with SDA or system monitoring) may be needed.

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.