[Digital logo]
[HR]

OpenVMS Version 7.1 New Features Manual


Previous | Contents

If the SHOW CLUSTER command displays a high number of credit waits for the VMS$VAXcluster connection to a remote node, you might consider increasing the value of CLUSTER_CREDITS on the remote node. However, in large cluster configurations, setting this value unnecessarily high will consume a large quantity of nonpaged pool. Each buffer is at least SCSMAXMSG bytes in size but might be substantially larger depending on the underlying transport.

All nodes in the cluster do not require the same value for CLUSTER_CREDITS. For small or memory-constrained systems, the default value of CLUSTER_CREDITS should be adequate.

3.16.2 DEVICE_NAMING Parameter (Alpha Only)

DEVICE_NAMING is a bit mask indicating whether port allocation classes are used in forming SCSI device names.

Following is the bit definition:
Bit Definition
0 If 1, enable new naming.

3.16.3 GBLPAGFIL and GBLPAGES Parameters (Alpha Only)

Note that these two system parameters are now dynamic. You do not need to reboot the system after you change their values.

3.16.4 LAN_FLAGS Parameter (Alpha Only)

LAN_FLAGS is a bit mask used to enable features in the local area networks (LAN) port drivers and support code.

Following is the bit definition:
Bit Description
Bit 0 The default of 0 indicates that ATM devices run in SONET mode. If set to 1, this bit indicates ATM devices run in SDH mode.
Bit 1 If set, this bit enables a subset of the trace and debug messages in the LAN port drivers and support code.
Bit 2 If set, this bit enables all trace and debug messages in the LAN port drivers and support code.

LAN_FLAGS is a DYNAMIC parameter.

3.16.5 MC_SERVICES Parameters

The following MEMORY CHANNEL system parameters have been added. These parameters control the node behavior in a MEMORY CHANNEL cluster. For information about the individual parameters, see the OpenVMS Version 7.1 Release Notes.
Parameter Description
MC_SERVICES_P0 Controls whether other MEMORY CHANNEL nodes in the cluster continue to run if this node bugchecks or shuts down.
MC_SERVICES_P1 This parameter is reserved by Digital. Its value must be the same on all nodes connected by MEMORY CHANNEL.
MC_SERVICES_P3 Specifies the maximum number of MEMORY CHANNEL tags supported.
MC_SERVICES_P4 Specifies the maximum number of regions supported.
MC_SERVICES_P5 This parameter is reserved by Digital. Its value must be the same on all nodes connected by MEMORY CHANNEL.
MC_SERVICES_P6 Specifies MEMORY CHANNEL message size, the body of an entry in a work queue.
MC_SERVICES_P7 Specifies whether to suppress or display messages about MEMORY CHANNEL activities on this node.
MC_SERVICES_P8 This parameter is reserved by Digital. Its value must be the same on all nodes connected by MEMORY CHANNEL.
MC_SERVICES_P9 Specifies the number of initial entries in a single channel's free queue.

3.16.6 MSCP_CMD_TMO Parameter

MSCP_CMD_TMO is the time in seconds that the OpenVMS MSCP server uses to detect MSCP command timeouts. The default value for MSCP_CMD_TMO is 600.

If command timeout errors are being logged on client nodes, setting this parameter to a nonzero value on OpenVMS servers reduces the number of errors logged. Increasing the value of this parameter reduces the number of client MSCP command timeouts and increases the time it takes to detect faulty devices.

If you need to decrease the number of command timeout errors, Digital recommends you set an initial value of 60. If timeout errors continue to be logged, you can increase this value in increments of 20 seconds.

MSCP_CMD_TMO is a DYNAMIC parameter.

3.16.7 Reclamation Parameters

On Alpha systems, nonpaged pool reclamation algorithms have been changed to ensure that packets put onto lookaside lists are returned to variable pool in a timely fashion. Both gentle and aggressive reclamation algorithms have been changed to return more packets to variable pool.

The following new parameters are related to the changed reclamation algorithms, which are explained in the OpenVMS Version 7.1 Release Notes.

3.16.7.1 NPAG_AGGRESSIVE Parameter (Alpha Only)

NPAG_AGGRESSIVE specifies the percentage of packets that are to remain on a nonpaged pool lookaside list after an aggressive reclamation pass. (Default: 50)

NPAG_AGGRESSIVE is a DYNAMIC parameter.

3.16.7.2 NPAG_GENTLE Parameter (Alpha Only)

NPAG_GENTLE specifies the percentage of packets that are to remain on a nonpaged pool lookaside list after a gentle reclamation pass. (Default: 85)

NPAG_GENTLE is a DYNAMIC parameter.

3.16.7.3 NPAG_INTERVAL Parameter (Alpha Only)

NPAG_INTERVAL specifies the number of seconds between gentle reclamation passes. (Default: 30)

NPAG_INTERVAL is a DYNAMIC parameter.

3.16.8 New RMS Parameters

This section presents information about the RMS_HEURISTIC and RMS_DFLRL parameters.


Note

The purpose of the RMS heuristic feature is to provide improved interoperability for existing applications using RMS to access files created by PATHWORKS. However, this is a change in behavior that may have an adverse effect on some applications.

See the Guide to OpenVMS File Applications and the DCL command SET RMS_DEFAULT for more information about the heuristic feature.

3.16.8.1 RMS_HEURISTIC Parameter

RMS_HEURISTIC controls whether RMS analyzes selected sequential files to determine if they are normal text or binary files. If RMS_HEURISTIC is enabled (with a value of 1), RMS analyzes sequential files with both a record format (RFM) of STM and a longest-record-length (LRL) of 0 when the files are initially opened.

By default in OpenVMS Version 7.1, the heuristic is disabled systemwide.

RMS_HEURISTIC is a DYNAMIC parameter.

3.16.8.2 RMS_DFLRL Parameter

If RMS_HEURISTIC is enabled (with a value of 1), RMS_DFLRL specifies the longest-record-length (LRL) file attribute value that RMS should use when it determines that a file with a record format of STM, STM_LF, or STM_CR and an LRL of 0 is a normal text file (rather than a binary file). See also the system parameter RMS_HEURISTIC.

The default value of RMS_DFLRL is 0; this value indicates that the internal RMS default value of 32767 is used.

RMS_DFLRL is a DYNAMIC parameter.


Chapter 4
Programming Features

This chapter describes new features relating to application and system programming on this version of the OpenVMS operating system.

4.1 Very Large Memory Management Features (Alpha Only)

OpenVMS Alpha Version 7.1 provides extended, additional memory management features that facilitate Very Large Memory (VLM) support on OpenVMS systems. Memory-resident global sections and shared page tables provide support for database, data warehouse, and other very large database (VLDB) products. With the new extended additional VLM features, database products and data warehousing applications will be able to realize increased capacity and performance gains.

Memory-resident global sections allow a database server to keep larger amounts of hot data cached in physical memory. The database server then accesses the data directly from physical memory without performing I/O read operations from the database files on disk. With faster access to the data in physical memory, run-time performance increases dramatically.

Shared page tables allow the same database server to reduce the amount of physical memory consumed within the system. Because multiple server processes share the same physical page tables that map the large database cache, an OpenVMS Alpha system can support more server processes. This increases overall system capacity and decreases response time to client requests.

Also, with shared page tables, the database server startup time is dramatically reduced because server processes can map memory-resident global sections hundreds of times faster than traditional global sections. With a multiple gigabyte global database cache, the server startup performance gains can be significant.

For more information about using the new OpenVMS Alpha VLM features, see OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features.

4.2 Backup Utility: New Application Programming Interface (API)

The BACKUP application programming interface (API) gives application programs access to BACKUP functions that are available to an interactive user via the DCL command BACKUP. The use of the BACKUP API provides the following benefits:

Through the BACKUP API, application programs can save individual files or the contents of entire disk volume sets. The BACKUP API also enables application programs to retrieve information about files or disk and tape volumes.

An application program calls routine BACKUP$START with an argument that points to a variable-length array, which consists of option structures that specify the required BACKUP operation. Each relevant BACKUP qualifier is represented by an option structure or combination of option structures. The call to BACKUP$START in combination with the option structures in the variable-length array form the equivalent of a BACKUP command at the DCL level.

The option structure types are defined in the language definition file (for example, BAPIDEF.H).

For more information about the Backup utility, see the OpenVMS Utility Routines Manual.

4.3 Byte and Word Instruction Emulator: Now Part of the Installation Kit (Alpha Only)

The Byte and Word Instruction Emulator, which required a separate installation in OpenVMS Alpha Version 7.0, is now completely integrated into the OpenVMS Alpha Version 7.1 kit. This emulator executes the following Alpha processor instructions when they are not implemented directly by the microprocessor:

Some new versions of Alpha compilers can generate these instructions if the code developer specifically requests it. If you run an image with these instructions in it, and your Alpha hardware does not support them, the Byte and Word Instruction Emulator will perform the specified instructions.

As a supplement to the emulator, an Emulator utility (EMULATOR_UTIL.C) is also included and is located in SYS$EXAMPLES. Comments in this file show you how to build and use the Emulator utility to perform the following tasks:

4.4 C Function Prototypes: Documented in the System Services Routines (Alpha Only)

With OpenVMS Alpha Version 7.0, SYS$LIBRARY:SYS$STARLET_C.TLB provided C function prototypes for system services. For OpenVMS Alpha Version 7.1, these prototypes are documented in the OpenVMS System Services Reference Manual along with the macro formats.

For each prototype, the manual provides the correct syntax (which shows the arguments the function accepts in the order in which it expects them), a description of each argument, and the type of data returned by the function.

4.5 DECwindows X11 Display Server: Upgraded to Version 11, Release 6

OpenVMS Version 7.1 supports the latest version of the DECwindows X11 display server which has been upgraded from Version 11, Release 5 (X11 R5) to Version 11, Release 6 (X11 R6). Included in this upgrade are the following new extensions supported by the server. Note that the version of the X Window System compatible X programming library (Xlib) currently shipped with DECwindows Motif Version 1.2-4 for OpenVMS does not support these new extensions.

4.6 Ethernet Media Types: Now Selected from the Console (Alpha Only)

Prior to OpenVMS Version 7.1, the SYS$EWDRIVER LAN device driver sensed the Ethernet media connections BNC, AUI, and Twisted Pair automatically. The LAN adapters supported by this driver include the DE435, DE450, DE500, and Tulip integral Ethernet device. Their device name under OpenVMS is EWx0, where x is the controller letter.

In OpenVMS Version 7.1, this driver uses a console environment variable to select the proper media connection. For each EW device recognized by the console, there is a console environment variable called EWx0_MODE, where x is the controller letter. This variable is set with the following command:

>>> SET EWx0_MODE media_selection

where media_selection is one of the following:

During the OpenVMS boot sequence, a message is sent to the operator's console that shows which media was set by the console and handed to the device driver. For example, if the EWA0_MODE console environment variable is set to FAST, the following message is displayed at the console:

  %EWA0, Fast(100baseT) mode set by console 

If a console environment variable is set to an unsupported media type, the driver attempts to sense or negotiate the media type automatically. This type of media sensing and negotiation, called auto negotiation, is supported by the DE500-AA Ethernet adapter.

In some cases, an Alpha system console might assign a controller letter to an adapter differently from OpenVMS Alpha. You should issue a SHOW CONFIGURATION command at the console to determine the correct letter designation for each adapter. In the case of different controller letter assignments, the letter designation in the message broadcast to the console by the driver may not agree with the console setting.

If the system is already running OpenVMS Alpha, you can issue the following LANCP command to select the proper media type:

$ MCR LANCP SET DEV EWx0/MEDIA=media_selection

where media_selection is one of the following:

4.7 Fast Ethernet Adapters: Support for the DE500-AA Adapter (Alpha Only)

Support for the DE500-AA PCI Fast Ethernet adapter has been added to OpenVMS Alpha Version 7.1. This device supports twisted pair media at speeds of 10Mb/s and 100Mb/s at full or half duplex performance. This device also supports automatic negotiation (auto negotiation) as proposed in the IEEE 802.3 standard.

Auto negotiation provides a method to detect the operational characteristics supported by a host device at the other end of the network link, negotiate common abilities, and configure the link accordingly. The driver can also detect changes in the link dynamically and renegotiate communication characteristics accordingly. Auto negotiation always selects the highest common operating mode possible between the two link partners. For the DE500-AA adapter, the highest operating mode is 100Mb/s full duplex unless programmed to a lesser mode.

Auto negotiation is enabled or disabled in two ways: by setting a console environment variable or by using the LANCP utility under OpenVMS. When both link partners enable auto negotiation, the OpenVMS driver selects a common operating mode, if possible. The OpenVMS driver can dynamically detect changes in the link and renegotiate a new operating mode automatically. The driver then broadcasts a message to the operator console similar to the following:

  %EWB0, Auto Negotiation detected link down 
  %EWB0, Fast(100baseT) Ethernet connection selected 

Note

For the OpenVMS driver to properly select an operating mode, both the local and remote hosts must have auto negotiation enabled.

4.7.1 Enabling Auto Negotiation with the Console Environment Variable

To enable auto negotiation using a console environment variable, issue the following command at the console:

>>> SET EWx0_MODE AUTO-NEGOTIATE

where x is the controller letter designation assigned to the DE500-AA adapter by the console.

To disable auto negotiation using the console environment variable, the operating mode has to be explicitly selected. The following example shows how to disable auto negotiation and enable the DE500-AA adapter to operate at 100Mb/s full duplex:

>>> SET EWx0_MODE FASTFD

where x is the controller letter designation assigned to the DE500-AA adapter by the console.

4.7.2 Enabling Auto Negotiation with LANCP

To enable auto negotiation under OpenVMS, issue the following LANCP command:

$ MCR LANCP SET DEV EWx/SPEED=AUTONEGOTIATE

where x is the controller letter designation assigned to the DE500-AA adapter by OpenVMS.

To disable auto negotiation under OpenVMS, the operating mode has to be explicitly selected. The following example shows how to disable auto negotiation and enable the DE500-AA to operate at 100Mb/s full duplex using the LANCP utility:

$ MCR LANCP SET DEV EWx/SPEED=100/FULLDUPLEX

where x is the controller letter designation assigned to the DE500-AA adapter by OpenVMS.

4.8 Kernel Threads Features

The following sections describe the new kernel threads features included in OpenVMS Version 7.1.

Kernel threads permit concurrent processing over all central processing units (CPUs) in a multiprocessor system by allowing a multithreaded application to have a thread executing on every CPU. Concurrent processing is comparatively faster than a single thread of execution through one CPU.

However, not all images are safe for use with threads. An application is thread-safe if threads do not interfere with each other during their independent execution. One example of interference is when two or more threads modify a common memory location without synchronization. This situation can lead to incorrect and inconsistent results. Using kernel threading, where the threads run concurrently on multiple CPUs, can greatly aggravate this problem. By disabling multiple kernel threading for a process, an application runs much less risk of encountering this problem.

Use the new kernel threads features when you have determined that your application is threads-safe and want to enable the kernel threading environment. Alternatively, you can use the THREADCP tool if the image has already been built. To find out whether an image is thread-safe, consult with the image provider.

4.8.1 Linker Utility: New /THREADS_ENABLE Qualifier

The new linker qualifier /THREADS_ENABLE allows you to turn the new kernel threads features on and off on a per-image basis.

The principal benefit of threading is to allow you to launch multiple paths of execution within a process. With threading, you can have some threads running while others are waiting for an external event to occur, such as I/O. The multi-threading kernel of OpenVMS Alpha can place threads on separate CPUs for concurrent execution; this can enable a process to run faster.

When you specify the /THREADS_ENABLE qualifier, the OpenVMS linker sets the appropriate bits in the image header of the image being linked. These bits control the following:

Note that in OpenVMS Version 7.1, only OpenVMS Alpha systems honor these control bits.

Following are explanations of how to disable the kernel threading environment for a process during the execution of images that might not be thread-safe.

Format

LINK /NOTHREADS_ENABLE (default)

LINK /THREADS_ENABLE[=(MULTIPLE_KERNEL_THREADS,UPCALLS)]

Qualifier Values

Description

The new image header bits allow you to control your threads environment on a per-process basis rather than systemwide. The image activator examines the new bits in the image header to determine the environment in which the image is to run.


Caution

The OpenVMS linker does not analyze whether the image can be safely placed in a multiple kernel threads environment. The linker sets only the control bits.


Examples

#1
$ LINK /NOTHREADS_ENABLE
 
 

This command keeps the MULTIPLE_KERNEL_THREADS and UPCALLS bits clear in the image header. It is the default.

#2
$ LINK /THREADS_ENABLE

This command sets the MULTIPLE_KERNEL_THREADS and UPCALLS bits in the image header of the image that is being built.

#3
$ LINK /THREADS_ENABLE=UPCALLS

This command sets only the UPCALLS bit in the image header of the image that is being built.

#4
$ LINK /THREADS_ENABLE=MULTIPLE_KERNEL_THREADS

This command sets only the MULTIPLE_KERNEL_THREADS bit in the image header of the image that is being built.

4.8.2 THREADCP Tool (Alpha Only)

THREADCP can be used to enable the new threads features for an image which, for whatever reason, will not be rebuilt.

The tool provides the ability to ENABLE, DISABLE, and SHOW the state of the thread control bits in an image's header.

The THREADCP command verb is not part of the normal set of DCL commands. To use the tool, you must define the command verb before invoking it.

When using this tool, an input file name is a required parameter with all qualifiers. All qualifiers and parameters can be abbreviated to the first character. When the SHOW qualifier is used alone with the THREADCP command, the file name can contain wildcard characters.

Once the THREADCP command verb is defined, the control bits can be set or cleared using the /ENABLE and /DISABLE qualifiers, respectively.

The ENABLE and DISABLE qualifiers require the names of the control bits to be modified. One or both control bits can be supplied. The user must have write access to the file. If the image is currently being executed or is installed it cannot be modified. If no control bit is specified, the default is to operate on both bits.


Examples

#1
$ SET COMMAND SYS$UPDATE:THREADCP.CLD

This command defines the THREADCP command verb.

#2
$ THREADCP/SHOW TEST.EXE

This command checks the current setting of the control bits for the image TEST.EXE.

#3
$ THREADCP/SHOW SYS$SYSTEM:*

This command checks the current setting of the control bits for all SYS$SYSTEM images.

#4
$ THREADCP/ENABLE=(MULTIPLE_KERNEL_THREADS, UPCALLS) TEST.EXE

This command sets both bits for the image TEST.EXE.

#5
$ THREADCP/DISABLE=(MULTIPLE_KERNEL_THREADS, UPCALLS) TEST.EXE

This command clears both bits for the image TEST.EXE.

Note: In general, it is recommended that only the link methods shown in examples 1 or 2 be used.

4.9 LAN Emulation: Over an ATM Network (Alpha Only)

OpenVMS Version 7.1 supports local area network (LAN) emulation for Ethernet over asynchronous transfer mode (ATM) networks. By implementing an emulated LAN over ATM, you enable a group of ATM stations to act like a traditional LAN. You can then bring some of the benefits of ATM's speed to your Ethernet networks. Emulated LAN over ATM allows you to run your existing applications unchanged, while the computers on which your applications are running are connected to an ATM network.


Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

[HR]

  6480P004.HTM
  OSSG Documentation
   5-DEC-1996 13:49:51.77

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal