![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
This example shows how to create a transaction log for a new node, whose SCSNODE name is WHITE.
In this example, the cluster members and the locations of their transaction logs are as follows:
| Node | Directory Containing Log |
|---|---|
| BLUE | DISK$LOG3:[LOGFILES] |
| RED | DISK$LOG2:[LOGFILES] |
Neither node has a node--specific version of SYLOGICALS.COM.
Decide the size and location of WHITE's transaction log:
| Node | Size of Log (in Blocks) | Disk |
|---|---|---|
| WHITE | 5000 | DUA4 |
Mount the disk DUA4 clusterwide:
$ MOUNT/CLUSTER/SYSTEM DUA4: LOG4
Create a directory for the transaction log:
$ CREATE/DIRECTORY DISK$LOG4:[LOGFILES]
Redefine SYS$JOURNAL:
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL - _SYSMAN> DISK$LOG2:[LOGFILES], DISK$LOG3[LOGFILES], DISK$LOG4:[LOGFILES] SYSMAN> EXIT
Edit the SYS$STARTUP:SYLOGICALS command procedure to update the SYS$JOURNAL definition. Then create the transaction log:
$ RUN SYS$SYSTEM:LMCP LMCP> CREATE LOG/SIZE=5000 DISK$LOG4:[LOGFILES]SYSTEM$WHITE.LM$JOURNAL LMCP> EXIT
This section describes how to remove a node if you are using DECdtm services.
How to Perform This Task
If you have a standalone machine, perform steps 1 to 8 only.
Caution
Follow all the steps carefully. Taking shortcuts can lead to data corruption.
DUMP/ACTIVE SYSTEM$node.LM$JOURNAL
DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL dirspec[,...]where dirspec is the full specification of a directory containing one or more transaction logs. List all the directories that contain any transaction logs other than the transaction log of the node you are removing. You can list the directories in any order.
Example
This example shows how to remove the node BLUE. In this example, the cluster members and the locations of their transaction logs are as follows:
| Node | Directory Containing Log |
|---|---|
| BLUE | DISK$LOG3:[LOGFILES] |
| RED | DISK$LOG2:[LOGFILES] |
| WHITE | DISK$LOG4:[LOGFILES] |
None of the nodes has a node--specific version of the SYLOGICALS.COM command procedure.
Log in to node BLUE.
Stop all the software that uses DECdtm services. Then find out if BLUE's transaction log contains any active transactions:
$ RUN SYS$SYSTEM:LMCP LMCP> DUMP/ACTIVE SYSTEM$BLUE.LM$JOURNAL Dump of log file DISK$LOG3:[LOGFILES]SYSTEM$BLUE.LM$JOURNAL . . . Total of 0 transactions active, 0 prepared and 0 committed. LMCP> EXIT
Redefine SYS$JOURNAL:
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL - _SYSMAN> DISK$LOG2:[LOGFILES], DISK$LOG4:[LOGFILES] SYSMAN> EXIT
Edit the SYS$MANAGER:SYLOGICALS.COM command procedure to update the SYS$JOURNAL definition.
Archive BLUE's transaction log. Then shut down node BLUE:
$ @SYS$SYSTEM:SHUTDOWN.COM . . . Should an automatic system reboot be performed [NO]? NO
Restart the software that uses DECdtm services. Then reconfigure the cluster:
$ @SYS$STARTUP:CLUSTER_CONFIG.COM
Cluster Configuration Procedure
1. ADD a node to a cluster.
2. REMOVE a node from the cluster.
3. CHANGE a cluster member's characteristics.
4. CREATE a duplicate system disk for BLUE.
Enter choice [1]: 2
.
.
.
Updating network database...
The configuration procedure has completed successfully.
By default, DECdtm services start automatically when you boot the computer. The DECdtm process, TP_SERVER, then checks for a transaction log, and continues checking until it finds one.
Disable DECdtm services if you do not use, and do not plan to use, any software that uses DECdtm services. This saves memory and CPU time.
In an OpenVMS Cluster, disable DECdtm services on all the nodes in the cluster.
$ RUN SYS$SYSTEM:LMCP LMCP> CLOSE LOG
$ ! $ DEFINE/SYSTEM/EXECUTIVE_MODE SYS$DECDTM_INHIBIT yes $ !
Enable DECdtm services only if you have previously disabled them and you now want to run software that uses DECdtm services.
How to Perform This Task
$ DEASSIGN/SYSTEM/EXECUTIVE_MODE SYS$DECDTM_INHIBIT
$ @SYS$STARTUP:DECDTM$STARTUP.COM
Example
This example shows how to enable DECdtm services in a cluster environment.
Deassign SYS$DECDTM_INHIBIT, then start up the TP_SERVER process.
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO DEASSIGN/SYSTEM/EXECUTIVE_MODE SYS$DECDTM_INHIBIT SYSMAN> DO @SYS$STARTUP.DECDTM$STARTUP.COM SYSMAN> EXIT
Edit the SYS$MANAGER:SYLOGICALS.COM command procedure to delete the SYS$DECDTM_INHIBIT definition.
The OpenVMS operating system supports the following special environments:
This chapter describes how to set up and manage these special processing environments.
Information Provided in This Chapter
This chapter describes the following tasks:
| Task | Section |
|---|---|
| Creating a multiprocessing environment | Section 26.2.1 |
| Monitoring a multiprocessing environment | Section 26.2.2 |
| +Loading the vector processing support code | Section 26.4.1 |
| +Configuring a vector processing system | Section 26.4.2 |
| +Managing vector processes | Section 26.4.3 |
| +Restricting access to the vector processor with ACLs | Section 26.4.4 |
| +Obtaining information about a vector processing system | Section 26.4.5 |
| +Loading the VAX Vector Instruction Emulation facility (VVIEF) | Section 26.4.6 |
This chapter explains the following concepts:
| Concept | Section |
|---|---|
| Symmetric multiprocessing | Section 26.1 |
| Primary and secondary processors | Section 26.1.1 |
| Available and active sets | Section 26.1.2 |
| Vector processing | Section 26.3 |
| +VAX support for vector processing | Section 26.3.1 |
| +The VAX Vector Instruction Emulation facility (VVIEF) | Section 26.3.2 |
A multiprocessing system consists of two or more CPUs that address a common pool of memory and that are capable of executing instructions simultaneously.
The OpenVMS operating system supports a tightly coupled, symmetric multiprocessing (SMP) system. In a tightly coupled SMP system, all processors execute a single copy of the operating system and have equal access to all operating system code and system resources. OpenVMS SMP dynamically selects the CPU where a process will run based on process priority.
A multiprocessing system can function as an isolated entity, a node in a network, or a member of an OpenVMS Cluster environment. Multiprocessing and uniprocessing systems run the same operating system, although multiprocessing can be enabled only on selected VAX and Alpha processors. All processors in a multiprocessing environment must be at the same hardware and firmware level to guarantee that a given processor is capable of resuming the execution thread of a process that had been executing previously on another processor in the system.
In a multiprocessing system, one processor has the responsibility of starting other processors in the system. The primary processor is that processor in the system that is either logically or physically attached to the console device. As such, it is the processor that is the target of the console commands that boot the multiprocessing system. In this role, only the primary processor performs the initialization activities that define the operating system environment and prepare memory for the entire system. In addition, the primary processor serves as the system timekeeper, maintaining the system time and monitoring the timer queue for the expiration of its elements. In this sense, all processors in a multiprocessing system that do not have these responsibilities are known as secondary processors.
An available set is made up of the processors that have passed the system's power-on hardware diagnostics and may or may not be actively involved in the system. Together, the primary and the secondary processors comprise the multiprocessing system's available set.
The active set is the subset of the VAX or Alpha system's processors that have passed power-on diagnostics and are actively participating in system operations. The operating system identifies each processor in these sets by its CPU ID, a value prevalent in the syntax and displays of certain DCL and utility commands.
The processors in a multiprocessing system offer certain capabilities to the processes executing in the system. The following capabilities are supported:
In addition, mechanisms exist to add and subtract other capabilities.
The Run capability affects CPU starting and stopping operations.
Managing symmetric multiprocessing systems (SMP) involves creating and monitoring a multiprocessing environment.
You can control the membership and character of a multiprocessing system at boot time by setting system parameters designed for these purposes. Among the system parameters that manage a multiprocessing system are the following:
| Parameter | Function |
|---|---|
| MULTIPROCESSING | Determines which synchronization image is loaded into the operating system at boot time |
| SMP_CPUS | Determines which processors are brought into the multiprocessing environment from the available set at boot time |
For more information about these and other system parameters, see the OpenVMS System Management Utilities Reference Manual.
You can add an available processor to the active set at boot time, or you can add it later using the DCL command START/CPU. The DCL command STOP/CPU removes a processor from the active set.
SMP Extension License
On Alpha systems, you must register the SMP Extension License if you have an SMP system. This license upgrades the Operating System Base License and all Interactive User licenses to the matching multiprocessing level of your system.
Because the SMP Extension License grants all the rights the existing Base and User licenses provide at the uniprocessing level, reinstalling those licenses when you upgrade to a multiprocessing system is unnecessary. When your system is upgraded to a new multiprocessing level, add an SMP Extension License to your existing license.
Several operating system features provide special information about the character, capabilities, and status of a multiprocessor system. They include the DCL command SHOW CPU and the Monitor utility.
Obtaining Information About a Multiprocessor
Configuration
The SHOW CPU command displays three levels of information describing the configuration and status of a multiprocessing system:
| Level | Command Example | Display Contents |
|---|---|---|
| Summary | SHOW CPU | Indicates which processor is primary, which processors are configured, and which processors are active; displays the minimum revision levels for processors in the system and the setting of the MULTIPROCESSING system parameter; and indicates whether multiprocessing is enabled. |
| Brief | SHOW CPU/BRIEF | Produces information from the summary display; lists the current CPU state and the current process (if any) for each configured processor. |
| Full | SHOW CPU/FULL | Produces information from the summary display and displays additional information; lists the current CPU state, current process (if any), revision levels, and capabilities for each configured processor; indicates which processes can be executed only on certain processors. |
For more information about the DCL commands relating to SMP, see the OpenVMS DCL Dictionary; for information about the Monitor utility, see the MONITOR section in the OpenVMS System Management Utilities Reference Manual.
A single data item, having one value, is known as a scalar. A group of related scalar values, or elements, all of the same data type, is known as a vector.
Traditional (scalar) computers operate only on scalar values, and must process vector elements sequentially. Vector computers, on the other hand, recognize vectors as native data structures and can operate on an entire vector with a single vector instruction. Because this type of processing involves the concurrent execution of multiple arithmetic or logical operations, a vector computer can routinely process a vector four to five times faster than a traditional computer can using only scalar instructions.
Vector processors gain a further speed advantage over scalar processors by their use of special hardware techniques designed for the fast processing of streams of data. These techniques include data pipelining, chaining, and other forms of hardware parallelism in memory and in arithmetic and logical functional units. Pipelined functional units allow the vector processor to overlap the execution of successive computations with previous computations.
The VAX vector architecture includes sixteen 64-bit vector registers (V0 through V15), each containing 64 elements; vector control registers, including the vector count register (VCR), vector length register (VLR), and vector mask register (VMR); vector functional units; and a set of vector instructions. VAX vector instructions transfer data between the vector registers and memory, perform integer and floating-point arithmetic, and execute processor control functions. A more detailed description of the VAX vector architecture, vector registers, and vector instructions appears in the VAX MACRO and Instruction Set Reference Manual.
Those VAX systems that comply with the VAX vector architecture are known as vector-capable systems.
A VAX vector processing system configuration includes one or more integrated scalar-vector processor pairs, or vector-present processors. Such a configuration can be symmetric, including a vector coprocessor for each scalar, or asymmetric, incorporating additional scalar-only processors. Depending upon the model of the VAX vector processing system, the scalar and vector CPUs of vector-present processors can be either a single, integral physical module or separate, physically independent modules. In either case the scalar and vector CPUs are logically integrated, sharing the same memory and transferring data over a dedicated, high-speed internal path.
Like VAX scalar processing systems, a VAX vector processing system can participate as a member of a VAXcluster or a node in a network, or be run as a standalone system.
The VAX Vector Instruction Emulation facility (VVIEF) is a standard feature of the OpenVMS operating system that allows vectorized applications to be written and debugged in a VAX system in which vector processors are not available. VVIEF emulates the VAX vector processing environment, including the nonprivileged VAX vector instructions and the vector system services. Use of VVIEF is restricted to user mode code.
VVIEF is strictly a program development tool, and not a run-time replacement for vector hardware. Vectorizing applications to run under VVIEF offers no performance benefit; vectorized applications running under VVIEF execute more slowly than their scalar counterparts.
The operating system supplies the VVIEF bootstrap code as an executive loadable image. Note that, in the presence of OpenVMS vector support code, VVIEF remains inactive. Although it is possible to prevent the loading of vector support code in a vector-present system (see Section 26.4.1) and activate VVIEF, there are few benefits.
See Section 26.4.6 for additional information on loading and unloading VVIEF.
The following sections describe tasks for managing a vector processing system.
By default, in a VAX vector processing system, the system automatically loads the vector processing support code at boot time. You can override the default behavior by setting the static system parameter VECTOR_PROC as described in Table 26-1.
| Value | Result |
|---|---|
| 0 | Do not load the vector processing support code, regardless of the system configuration. |
| 1 | Load the vector processing support code if at least one vector-present processor exists. This is the default value. |
| 2 | Load the vector processing support code if the system is vector-capable. This setting is most useful for a system in which processors have separate power supplies. With this setting, you can reconfigure a vector processor into the system without rebooting the operating system. |
You can add a vector-present processor to or remove it from a multiprocessing configuration at boot time by using the system parameter SMP_CPUS, or at run time by using the DCL commands START/CPU and STOP/CPU. Note that the operating system treats the scalar and vector CPU components of a vector-present processor as a single processor, starting them and stopping them together.
At boot time, the setting of the system parameter SMP_CPUS identifies which secondary processors in a multiprocessing system are to be configured, including those processors that are vector present. (The operating system always configures the primary processor.) The default value of --1 boots all available processors, scalar and vector-present alike, into the configuration. (See the OpenVMS System Management Utilities Reference Manual for additional information on this parameter.) Note that, prior to starting a vector-present processor, you should ensure that the vector processing support code (see Section 26.4.1) is loaded at boot time. Otherwise, processes will be able to use only the scalar CPU component of the vector-present processor.
To bring secondary processors into a running multiprocessing system, use the DCL command START/CPU. To remove secondary processors from the system, use the STOP/CPU commands. Again, you must ensure that the vector processing support code has been loaded at boot time for the vector CPU component of vector-present processors started in this way to be used.
Note, however, that a STOP/CPU command fails and generates a message if it would result in the removal of a vector-present processor that is the sole provider of the vector capability for currently active vector consumers. In extreme cases, such as the removal of a processor for repair, you can override this behavior by issuing the command STOP/CPU/OVERRIDE. This command stops the processor, despite stranding processes.
When a STOP/CPU/OVERRIDE command is issued for a vector-present processor, or when a vector-present processor fails, the operating system puts all stranded vector consumers into a CPU-capability-wait (RSN$_CPUCAP) state until a vector-present processor is returned to the configuration. To any other process that subsequently issue a vector instruction (including a marginal vector consumer), the system returns a requested CPU not active message (CPUNOTACT).
See the OpenVMS DCL Dictionary for additional information on the START/CPU and STOP/CPU commands.
The operating system scheduling algorithms automatically distribute vector and scalar processing resources among vector consumers, marginal vector consumers, and scalar consumers. However, VAX vector processing configurations vary in two important ways:
In a configuration that has more vector consumers in a system than scalar-vector processor pairs to service them, vector consumers share vector-present processors according to process priority. At a given priority, the system schedules vector consumers on a vector-present processor in a round-robin fashion. Each time the system must schedule a new vector consumer on a vector-present processor, it must save the vector context of the current vector consumer in memory and restore the vector context of the new vector consumer from memory. When such "slow" vector context switches occur too frequently, a significant portion of the processing time is spent on vector context switches relative to actual computation.
6017P074.HTM OSSG Documentation 22-NOV-1996 14:23:06.48
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.