Document revision date: 30 March 2001

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.

How to Perform This Task

1. For each node:
   1. Log in to the node.
   2. Stop the TP_SERVER process using LMCP's CLOSE LOG command:

      $ RUN SYS$SYSTEM:LMCP LMCP> CLOSE LOG

      
      The CLOSE LOG command stops the TP_SERVER process, providing no software is using DECdtm services.
      If the CLOSE LOG command fails, do not continue this task. If you have already stopped the TP_SERVER process on other nodes in a cluster system, restart the process using the SYS$STARTUP:DECDTM$STARTUP.COM command procedure.

2. Add the following line to the SYS$MANAGER:SYLOGICALS.COM command procedure:

   $ ! $ DEFINE/SYSTEM/EXECUTIVE_MODE SYS$DECDTM_INHIBIT yes $ !

   
   If you created node-specific versions of SYLOGICALS.COM, edit all the versions.
   This stops the TP_SERVER process being created the next time you boot the system.

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

1. Deassign the logical name SYS$DECDTM_INHIBIT:

   $ DEASSIGN/SYSTEM/EXECUTIVE_MODE SYS$DECDTM_INHIBIT

   
   In an OpenVMS Cluster, use SYSMAN to deassign SYS$DECDTM_INHIBIT clusterwide.

2. Start up the DECdtm services process, TP_SERVER:

   $ @SYS$STARTUP:DECDTM$STARTUP.COM

   
   In an OpenVMS Cluster, use SYSMAN to start up the TP_SERVER process clusterwide.

3. Edit the SYS$MANAGER:SYLOGICALS.COM command procedure to delete the SYS$DECDTM_INHIBIT definition. This ensures that DECdtm services start automatically when you boot the system.

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:

• Symmetric multiprocessing
• Vector processing (available only on certain CPU models)

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 28.2.1
Monitoring a multiprocessing environment	Section 28.2.2
+Loading the vector processing support code	Section 28.4.1
+Configuring a vector processing system	Section 28.4.2
+Managing vector processes	Section 28.4.3
+Restricting access to the vector processor with ACLs	Section 28.4.4
+Obtaining information about a vector processing system	Section 28.4.5
+Loading the VAX Vector Instruction Emulation facility (VVIEF)	Section 28.4.6

This chapter explains the following concepts:

Concept	Section
Symmetric multiprocessing	Section 28.1
Primary and secondary processors	Section 28.1.1
Available and active sets	Section 28.1.2
Vector processing	Section 28.3
+VAX support for vector processing	Section 28.3.1
+The VAX Vector Instruction Emulation facility (VVIEF)	Section 28.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.

28.1.1 Primary and Secondary Processors

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.

28.1.2 Available and Active Sets

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.

28.1.3 Processor Capabilities

The processors in a multiprocessing system offer certain capabilities to the processes executing in the system. The following capabilities are supported:

• Primary
• Quorum
• Run
• Vector (VAX Only)

In addition, mechanisms exist to add and subtract other capabilities.

The Run capability affects CPU starting and stopping operations.

28.2 Managing SMP Environments

Managing symmetric multiprocessing systems (SMP) involves creating and monitoring a multiprocessing environment.

28.2.1 Creating 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 parameters:

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, refer to 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.

28.2.2 Monitoring a Multiprocessing Environment

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, refer to the OpenVMS DCL Dictionary; for information about the Monitor utility, refer to the MONITOR section in the OpenVMS System Management Utilities Reference Manual.

28.3 Understanding Vector Processing

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.

28.3.1 VAX Support for Vector Processing (VAX Only)

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.

28.3.2 VAX Vector Instruction Emulation Facility (VAX Only)

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 28.4.1) and activate VVIEF, there are few benefits.

See Section 28.4.6 for additional information about loading and unloading VVIEF.

28.4 Managing the Vector Processing Environment (VAX Only)

The following sections describe tasks for managing a vector processing system.

28.4.1 Loading the Vector Processing Support Code (VAX Only)

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 28-1.

Table 28-1 Settings of VECTOR_PROC System Parameter (VAX Only)

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.

28.4.2 Configuring a Vector Processing System (VAX Only)

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. (Refer to the OpenVMS System Management Utilities Reference Manual for additional information about this parameter.) Note that, prior to starting a vector-present processor, you should ensure that the vector processing support code (see Section 28.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).

Refer to the OpenVMS DCL Dictionary for additional information about the START/CPU and STOP/CPU commands.

28.4.3 Managing Vector Processes (VAX Only)

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:

• The amount of vector processing activity the configuration must accommodate
• The number of vector-present processors that are available in the configuration to service vector processing needs

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.

Systems that have heavy vector processing needs should be adequately configured to accommodate those needs. However, some mechanisms are available for tuning the performance of an existing configuration.

	privacy and legal statement
6017PRO_104.HTML