V73 Features
*Conan The Librarian (sorry for the slow response - running on an old VAX)
|
VMS Help V73 Features *Conan The Librarian (sorry for the slow response - running on an old VAX) |
|
The following topics summarize the new features for OpenVMS
Version 7.3.
| 1 - OpenVMS e-Business |
This section provides information on the e-Business technologies
that are included in the Compaq OpenVMS e-Business Infrastructure
Package with OpenVMS Alpha Version 7.3. This package provides
key Internet and e-Business software technology that enhances
the base OpenVMS Alpha operating system. These technologies are
licensed with the OpenVMS Alpha operating system.
The Compaq OpenVMS e-Business Infrastructure Package Version 1.1
contains the following software and accompanying documentation:
o Compaq Secure Web Server for OpenVMS Alpha Version 1.0-1
(based on Apache)
o Compaq COM for OpenVMS Version 1.1B
o Compaq Java 2 SDK, Standard Edition v 1.2.2-3
o Compaq Fast Virtual Machine (Fast VM) for the Java 2 Platform
on OpenVMS Alpha v 1.2.2-1
o Compaq XML (Extensible Markup Language) Technology Version 1.0
o Attunity Connect "On Platform" Package Version 3.0.0.4
o Compaq Enterprise Directory Services for e-Business Version
5.0
o Reliable Transaction Router (RTR) Version 4.0
o Compaq BridgeWorks Version 1.0A
Refer to the Compaq OpenVMS e-Business Infrastructure Package
Version 1.1 CD-ROM Booklet and the Compaq OpenVMS e-Business
Infrastructure Package Version 1.1 Software Product Description,
80.58.00 included in the e-Business package for more detailed
information.
For up-to-date information on OpenVMS e-Business technologies,
refer to the following web site:
http://www.openvms.compaq.com/business/index.html
The following sections briefly describe the e-Business software
and provide pointers and web sites for further information. Refer
to the Compaq OpenVMS e-Business Infrastructure Package SPD
for technology descriptions, other software requirements, and
licensing information. The technology on the e-Business CD-ROM
has been tested and qualified with OpenVMS Alpha Version 7.2-1
and later.
1.1 - Secure Web Server
Compaq Secure Web Server for OpenVMS Alpha (CSWS) is based
on the popular Apache Web Server from the Apache Software
Foundation. Building on the source code from the Apache Software
Foundation (http://www.apache.org), Compaq OpenVMS engineering
has incorporated and fully integrated OpenSSL with mod_ssl, the
most popular open-source implementations of SSL.
The product is also available to download from the CSWS web site:
http://www.openvms.compaq.com/openvms/products/ips/apache/csws.html
1.2 - COM for OpenVMS
Component Object Model (COM) is a technology from Microsoft that
allows developers to create distributed network objects. Digital
Equipment Corporation and Microsoft jointly developed the COM
specification. The Compaq COM for OpenVMS kit included on the e-
Business CD-ROM provides all the code and documentation you need
to install Compaq COM for OpenVMS on your system and to develop
COM applications.
1.3 - Java 2 SDK, Standard Edition
The Java Software Development Kit (SDK) provides an environment
in which to develop and deploy Java applications on OpenVMS
Alpha. Java applications can be written once and run on any
operating system that implements the Java run-time environment,
which consists primarily of the Java Virtual Machine (JVM).
The Java 2 SDK, Standard Edition, for OpenVMS Alpha kit is
included on the e-Business CD-ROM, or you can download this kit
from the Compaq Java home page at the following web address:
http://www.compaq.com/java/download/index.html
1.4 - Fast Virtual Machine for Java 2
The Compaq Fast VM for Java 2 is new Just-In-Time (JIT) compiler
technology designed to provide optimal Java run-time performance
on OpenVMS Alpha systems. The Fast VM for Java 2 offers
significant performance advantages over the Classic JIT provided
with the Compaq Java 2 SDK, Standard Edition.
The Fast VM for OpenVMS Alpha kit is included on the e-Business
CD-ROM, or you can also download this kit from the Compaq Java
home page at the following web address:
http://www.compaq.com/java/download/index.html
1.5 - Compaq XML Technology
The following components are provided on the e-Business CD-ROM
using open source software from the Apache Software Foundation:
o XML parsers in Java and C++
o XSLT style sheet processors in Java and C++
This technology provides applications the ability to parse,
generate, manipulate, validate, and transform Extensible Markup
Language (XML) documents and data.
1.6 - Attunity Connect On Platform
Attunity Connect is object-oriented middleware that facilitates
the development of applications that access, integrate, and
update data from multiple, heterogeneous sources across a wide
range of operating system platforms. With Attunity Connect, you
can extend the life of your existing data and applications and
preserve your significant IT investments.
The e-Business CD-ROM contains the Attunity Connect "On Platform"
Package for OpenVMS Alpha. You can also download the Attunity
Connect "On Platform" Package from the following OpenVMS web
site:
http://www.openvms.compaq.com/openvms/products/ips/attunity/
1.7 - Enterprise Directory Services
Compaq OpenVMS Enterprise Directory for e-Business combines the
best of both industry standard LDAPv3 and X.500 capabilities, and
delivers robust and scalable directory services across intranets,
extranets, and the Internet to customers, suppliers and partners.
Lightweight Directory Access Protocol (LDAP) support allows
access by a myriad of LDAP-based clients, user agents, and
applications. The X.500 support brings high performance,
resilience, advanced access controls, and easy replication across
the enterprise.
For further information, refer to the Compaq OpenVMS Enterprise
Directory for e-Business Software Product Description (SPD
40.77.xx) included on the e-Business CD-ROM in the Enterprise
Directory Services documentation directory.
1.8 - Reliable Transaction Router (RTR)
Reliable Transaction Router (RTR) is fault tolerant transactional
messaging middleware used to implement large, distributed
applications using client/server technology. Reliable Transaction
Router enables computing enterprises to deploy distributed
applications on OpenVMS Alpha and VAX systems.
Refer to the Reliable Transaction Router for OpenVMS Software
Product Description (SPD 51.04.xx) included on the e-Business
CD-ROM for additional information; or you can access the RTR web
site at:
http://www.compaq.com/rtr/
1.9 - Compaq BridgeWorks
Compaq BridgeWorks is a distributed application development
and deployment tool for OpenVMS 3GL applications. BridgeWorks
consists of a GUI development tool on the Windows NT desktop, a
server manager component on OpenVMS, and extensive online help.
BridgeWorks provides developers with an easy means to create
distributed applications using OpenVMS as the enterprise server
and Windows NT as the departmental server.
For more information on Compaq BridgeWorks, refer to the Compaq
OpenVMS e-Business Infrastructure Package Software Product
Description.
| 2 - User Features |
This section describes new features of interest to OpenVMS
users.
2.1 - DCL Commands and Lexical Functions
This section describes new and changed DCL commands, qualifiers,
and lexical functions for OpenVMS Version 7.3. The following
table contains a summary of these changes.
For more information, refer to the OpenVMS DCL Dictionary.
DCL Command Documentation Update
ANALYZE/IMAGE A new qualifier, /SELECT, has been added, along
with an example.
ANALYZE/OBJECT A new qualifier, /SELECT, has been added, along
with an example.
ANALYZE/PROCESS A new qualifier, /[NO]IMAGE_PATH, has been
added, along with an example.
DELETE A new qualifier, /BITMAP, has been added to
support Write Bitmap.
DELETE/INTRUSION A new qualifier, /NODE, has been added, along
with an example, to support Cluster-wide
Intrusion.
DIRECTORY A new qualifier, /CACHING_ATTRIBUTE, has been
added to support Extended File Cache (XFC).
DISMOUNT A new qualifier, /POLICY, has been added to
support Write Bitmap.
A new qualifier, /FORCE_REMOVAL, has been added
to support Volume Shadowing.
DUMP A new qualifier, /PROCESS, has been added.
INITIALIZE The INITIALIZE description has been updated to
include information about Extended File Cache
(XFC).
A new qualifier, /SHADOW, has been added to
support Volume Shadowing.
MOUNT The MOUNT command has been moved to the
OpenVMS DCL Dictionary from the OpenVMS System
Management Utilities Reference Manual.
The MOUNT description has been updated to
include information about Extended File Cache
(XFC).
A new qualifier, /POLICY, has been added to
support Write Bitmap.
SET AUDIT A new keyword, SERVER, has been added under the
LOGFAILURE, LOGIN, and LOGOUT keywords.
New text has been added to the /NEW_LOG
qualifier.
SET This new DCL command has been added to support
CACHE/RESET Extended File Cache (XFC).
SET DEVICE The following new qualifiers have been added
to support Volume Shadowing: /FORCE_REMOVAL,
/MEMBER_TIMEOUT, /MVTIMEOUT, /READ_COST, /SITE,
/COPY_SOURCE, /ABORT_VIRTUAL_UNIT.
SET DISPLAY The logical, DECW$SETDISPLAY_DEFAULT_TRANSPORT,
has been added to this command.
SET FILE Two new qualifiers, /SHARE and /CACHING_
ATTRIBUTE, have been added. The /CACHING_
ATTRIBUTE qualifier supports Extended File Cache
(XFC).
SET PROCESS The functionality of the qualifier, /[NO]DUMP,
has been extended to include other processes.
The /DUMP qualifier also has a new option,
NOW, to initiate an immediate dump of another
process.
SET RMS_ Two new qualifiers, /CONTENTION_POLICY and
DEFAULT /QUERY_LOCK have been added, and the examples
have been updated.
SET SERVER Added support for the Registry, including new
qualifiers and examples.
SET VOLUME A new qualifier, /[NO]WRITETHROUGH, has been
added to support Extended File Cache (XFC).
The /HIGHWATER qualifier is valid for Files-11
On-Disk Structure Level 5 disks.
SHOW CPU The following new qualifiers have been added:
/EXACT, /HIGHLIGHT, /OUTPUT, /PAGE, /SEARCH, and
/WRAP.
SHOW DEVICES A new qualifier, /BITMAP, has been added to
support Write Bitmap, along with examples.
The /FULL qualifier now displays the worldwide
identifier (WWID) for Fibre Channel tape
devices.
SHOW INTRUSION A new qualifier, /NODE, has been added, along
with an example, to support Cluster-wide
Intrusion.
SHOW LICENSE The qualifier, /CHARGE_TABLE, has been added as
a synonym for the /UNIT_REQUIREMENTS qualifier.
SHOW MEMORY The /CACHE qualifier and examples have been
updated for Extended File Cache (XFC).
The /FILES and /FULL qualifiers and examples
have been updated for Large Page Files.
SHOW RMS_ The example has been updated.
DEFAULT
SHOW SERVER This command has been added in support of the
Registry.
UNLOCK This command is now obsolete. Use the SET
FILE/UNLOCK command.
DCL Lexical Documentation Update
F$GETDVI The item codes, MT3_DENSITY, MT3_SUPPORTED, and
WWID have been added, and the MOUNTCNT item code
has been updated.
The item codes, DEVTYPE, DEVCLASS, and DEVICE_
TYPE_NAME have been updated, and an example
has been added. Tables 1-7 and 1-8 have been
removed.
F$GETQUI The JOB_STATUS item code list has been updated.
F$GETJPI The MULTITHREAD item code has been added.
F$GETSYI The MULTITHREAD and DECNET_VERSION items have
been added.
2.2 - Utility Routines Online Help
As of Version 7.3, online help now includes all the OpenVMS
utility routines that are described in OpenVMS Utility Routines
Manual, including the following:
ACL_Editor
BACKUP_API
CLI_Routines
CONV$_Routines
CQUAL_Routines
DCX_Routines
DECTPU
EDT_Routines
FDL_Routines
LBR_Routines
LDAP_Routines
LGI_Routines
MAIL_Routines
NCS_Routines
PSM_Routines
SMB_Routines
SOR_Routines
For OpenVMS Version 7.3, several online help topics have been
renamed, as follows:
Old Topic
Name New Topic Name
BACKUP BACKUP_Command
FDL FDL_Files
MAIL MAIL_Command
NCS NCS_Command
2.3 - MIME Utility
The following new commands and qualifiers have been added to the
Multipurpose Internet Mail Extension (MIME) utility:
Command Description
ADD/BINARY Sets the Content-Type to application/octet-stream
and Content-Transfer-Encoding to Base64. This
format can be used to represent an arbitrary
binary data stream.
SHOW option Displays information about the MIME environment.
Possible options are CONTENT_TYPE, FILE_TYPES, and
VERSION.
For more information about the MIME utility commands and
qualifiers, refer to the OpenVMS User's Manual.
2.4 - WWPPS Utility
The World-Wide PostScript Printing Subsystem (WWPPS) is a utility
that allows you to print a PostScript file with various language
characters on any PostScript printer. By embedding font data
within the PostScript printable file, you can print the language
characters even if the printer does not have the local language
character fonts.
For detailed instructions about using the WWPPS utility, refer to
the OpenVMS User's Manual.
For more information about the installation and administration of
the WWPPS utility, refer to the OpenVMS System Manager's Manual.
| 3 - System Management Features |
This topic describes new features of interest to OpenVMS system
managers.
3.1 - AlphaServer GS Series
OpenVMS Version 7.3 provides support for Compaq's AlphaServer
GS80, GS160 and GS320 systems, which was introduced in OpenVMS
Version 7.2-1H1, and includes:
o OpenVMS support for hard and soft partitions (Galaxy) on
AlphaServer GS160 and GS320 systems
o OpenVMS Resource Affinity Domain (RAD) support for
applications
o CPU Online Replace
3. 1.1 - Hard and Soft Partitions
Hard partitioning is a physical separation of computing resources
by hardware-enforced access barriers. It is impossible to read
or write across a hard partition boundary. There is no resource
sharing between hard partitions.
Soft partitioning is a separation of computing resources by
software-controlled access barriers. Read and write access across
a soft partition boundary is controlled by the operating system.
OpenVMS Galaxy is an implementation of soft partitioning.
The way customers choose to partition their systems depends on
their computing environments and application requirements. For
more information about using hard partitions and OpenVMS Galaxy,
refer to the OpenVMS Alpha Partitioning and Galaxy Guide.
3. 1.2 - Resource Affinity Domain (RAD) Support
OpenVMS Alpha Version 7.3 provides non-uniform memory awareness
(NUMA) in OpenVMS memory management and process scheduling,
which was introduced in OpenVMS Version 7.2-1H1. This capability
provides application support for resource affinity domains
(RADs), to ensure that applications running on a single instance
of OpenVMS on multiple quad building blocks (QBBs) can execute
as efficiently as possible in a NUMA environment. A RAD is a
set of hardware components (CPU, memory, IO) with common access
characteristics, and corresponds to a QBB in an AlphaServer GS160
or GS320 system.
For more information about using the OpenVMS RAD support for
application features, refer to the OpenVMS Alpha Partitioning and
Galaxy Guide.
3.2 - Daylight Savings Time
System parameter AUTO_DLIGHT_SAV controls whether OpenVMS
will automatically change system time to and from Daylight
Savings Time when appropriate. A value of 1 tells OpenVMS to
automatically make the change. The default is 0 (off). This is a
static parameter.
However, if you have a time service (such as DTSS), that time
service continues to control time changes, and OpenVMS does not
interfere. Do not enable automatic daylight savings time if you
have another time service.
For more information, refer to the OpenVMS System Manager's
Manual.
3.3 - CPU Online Replace (Alpha)
With OpenVMS Alpha Version 7.3, you can replace secondary CPUs on
a running system without rebooting, which provides increased
system maintainability and serviceability. This feature is
supported only on AlphaServer GS160/320 systems. Note that
replacing the primary CPU requires rebooting.
To use this feature, you must first download console firmware
Version 5.9B from the following location:
http://ftp.digital.com/pub/DEC/Alpha/firmware/
You can then use the following DCL commands to replace a CPU
without rebooting:
1. Direct OpenVMS to stop scheduling processes on the CPU:
$ STOP/CPU n
(n is the number of the CPU to be stopped.)
2. Power off the running CPU:
$ SET CPU/POWER=OFF n
3. When the light on the CPU module has turned from green to
amber, physically remove the CPU module from the system. Then
put in a new CPU.
4. Power on the CPU:
$ SET CPU/POWER=ON n
OpenVMS automatically adds the CPU to the active set of
processors.
Note that the Galaxy Configuration Utility (GCU) also supports
this capability.
3.4 - Class Scheduler
With OpenVMS Version 7.3, there is a new SYSMAN-based interface
for class scheduling. This new class scheduler, implemented on
both VAX and Alpha systems, gives you the ability to designate
the amount of CPU time that a system's users may receive by
placing the users into scheduling classes. Each class is assigned
a percentage of the overall system's CPU time. As the system
runs, the combined set of users in a class are limited to the
percentage of CPU execution time allocated to their class. The
users may get some additional CPU time if /windfall is enabled
for their scheduling class. Enabling the /windfall allows the
system to give a small amount of CPU time to a scheduling class
when a CPU is idle and the scheduling class' allotted time has
been depleted.
To invoke the class scheduler, you use the SYSMAN interface.
SYSMAN allows you to create, delete, modify, suspend, resume, and
display scheduling classes. SYSMAN command: class_schedule shows
the SYSMAN command, CLASS_SCHEDULE, and its sub-commands.
Table 4-1 SYSMAN command: class_schedule
Sub-
command Meaning
ADD Creates a new scheduling class
DELETE Deletes a scheduling class
MODIFY Modifies the characteristics of a scheduling class
SHOW Shows the characteristics of a scheduling class
SUSPEND Suspends temporarily a scheduling class
RESUME Resumes a scheduling class
By implementing the class scheduler using the SYSMAN interface,
you create a permanent database that allows OpenVMS to class
schedule processes automatically after a system has been booted
and rebooted. This database resides on the system disk in
SYS$SYSTEM:VMS$CLASS_SCHEDULE.DATA. SYSMAN creates this file
as an RMS indexed file when the first scheduling class is created
by the SYSMAN command, CLASS_SCHEDULE ADD.
In a cluster environment, SYSMAN creates this database file in
the SYS$COMMON root of the [SYSEXE] directory. As a result, the
database file is shared among all cluster members. By using
SYSMAN's SET ENVIRONMENT command, you can define scheduling
classes either on a cluster-wide or per-node basis.
If desired, a system manager (or application manager) uses the
permanent class scheduler to place a process into a scheduling
class at process creation time. When a new process is created,
Loginout determines whether this process belongs to a scheduling
class. Given process information from the SYSUAF file, Loginout
then class schedules the process if Loginout determines that the
process belongs to a scheduling class.
By using the SYSMAN utility to perform class scheduling
operations instead of $SCHED system service, you gain the
following benefits:
o You need not modify individual program images to control
class scheduling. You can add, delete, and modify scheduling
classifications from the SYSMAN utility.
o You can use SYSMAN to create a permanent class scheduling
database file which allows processes to be class scheduled
at process creation time and allows class definitions to be
preserved in case of a system reboot.
For more detailed information, refer to the following manuals:
OpenVMS Programming Concepts Manual, Volume I
OpenVMS DCL Dictionary: N-Z
OpenVMS System Services Reference Manual: A-GETUAI
3.5 - Dedicated CPU Lock Manager (Alpha)
The Dedicated CPU Lock Manager is a new feature that improves
performance on large SMP systems that have heavy lock manager
activity. The feature dedicates a CPU to performing lock manager
operations.
A dedicated CPU has the following advantages for overall system
performance as follows:
o Reduces the amount of MP_SYNCH time
o Provides good CPU cache utilization
3. 5.1 - Implementing
For the Dedicated CPU Lock Manager to be effective, systems
must have a high CPU count and a high amount of MP_SYNCH due
to the lock manager. Use the MONITOR utility and the MONITOR
MODE command to see the amount of MP_SYNCH. If your system has
more than five CPUs and if MP_SYNCH is higher than 200%, your
system may be able to take advantage of the Dedicated CPU Lock
Manager. You can also use the spinlock trace feature in the
System Dump Analyzer (SDA) to help determine if the lock manager
is contributing to the high amount of MP_SYNCH time.
The Dedicated CPU Lock Manager is implemented by a LCKMGR_SERVER
process. This process runs at priority 63. When the Dedicated
CPU Lock Manager is turned on, this process runs in a compute
bound loop looking for lock manager work to perform. Because
this process polls for work, it is always computable; and with
a priority of 63 the process will never give up the CPU, thus
consuming a whole CPU.
If the Dedicated CPU Lock Manager is running when a program calls
either the $ENQ or $DEQ system services, a lock manager request
is placed on a work queue for the Dedicated CPU Lock Manager.
While a process waits for a lock request to be processed, the
process spins in kernel mode at IPL 2. After the dedicated CPU
processes the request, the status for the system service is
returned to the process.
The Dedicated CPU Lock Manager is dynamic and can be turned off
if there are no perceived benefits. When the Dedicated CPU Lock
Manager is turned off, the LCKMGR_SERVER process is in a HIB
(hibernate) state. The process may not be deleted once started.
3. 5.2 - Enabling
To use the Dedicated CPU Lock Manager, set the LCKMGR_MODE
system parameter. Note the following about the LCKMGR_MODE system
parameter:
o Zero (0) indicates the Dedicated CPU Lock Manager is off (the
default).
o A number greater than zero (0) indicates the number of CPUs
that should be active before the Dedicated CPU Lock Manager is
turned on.
Setting LCKMGR_MODE to a number greater than zero (0) triggers
the creation of a detached process called LCKMGR_SERVER. The
process is created, and it starts running if the number of active
CPUs equals the number set by the LCKMGR_MODE system parameter.
In addition, if the number of active CPUs should ever be reduced
below the required threshold by either a STOP/CPU command or by
CPU reassignment in a Galaxy configuration, the Dedicated CPU
Lock Manager automatically turns off within one second, and the
LCKMGR_SERVER process goes into a hibernate state. If the CPU is
restarted, the LCKMGR_SERVER process again resumes operations.
3. 5.3 - Using with Affinity
The LCKMGR_SERVER process uses the affinity mechanism to set
the process to the lowest CPU ID other than the primary. You can
change this by indicating another CPU ID with the LCKMGR_CPUID
system parameter. The Dedicated CPU Lock Manager then attempts
to use this CPU. If this CPU is not available, it reverts back to
the lowest CPU other than the primary.
The following shows how to dynamically change the CPU used by the
LCKMGR_SERVER process:
$RUN SYS$SYSTEM:SYSGEN
SYSGEN>USE ACTIVE
SYSGEN>SET LCKMGR_CPUID 2
SYSGEN>WRITE ACTIVE
SYSGEN>EXIT
To verify the CPU dedicated to the lock manager, use the following
show system command:
$ SHOW SYSTEM/PROCESS=LCKMGR_SERVER
This change applies to the currently running system. A reboot
reverts back to the lowest CPU other than the primary. To
permanently change the CPU used by the LCKMGR_SERVER process,
set LCKMGR_CPUID in your MODPARAMS.DAT file.
Compaq highly recommends that a process not be given hard
affinity to the CPU used by the Dedicated CPU Lock Manager.
With hard affinity when such a process becomes computable, it
cannot obtain any CPU time, because the LCKMGR_SERVER process
is running at the highest possible real-time priority of 63.
However, the LCKMGR_SERVER detects once per second if there are
any computable processes that are set by the affinity mechanism
to the dedicated lock manager CPU. If so, the LCKMGR_SERVER
switches to a different CPU for one second to allow the waiting
process to run.
3. 5.4 - Using with Fast Path Devices
OpenVMS Version 7.3 also introduces Fast Path for SCSI and Fibre
Channel Controllers along with the existing support of CIPCA
adapters. The Dedicated CPU Lock Manager supports both the
LCKMGR_SERVER process and Fast Path devices on the same CPU.
However, this may not produce optimal performance.
By default, the LCKMGR_SERVER process runs on the first available
nonprimary CPU. Compaq recommends that the CPU used by the
LCKMGR_SERVER process not have any Fast Path devices. This can
be accomplished in either of the following ways:
o You can eliminate the first available nonprimary CPU as an
available Fast Path CPU. To do so, clear the bit associated
with the CPU ID from the IO_PREFER_CPUS system parameter.
For example, let's say your system has eight CPUs with CPU IDs
from zero to seven and four SCSI adapters that will use Fast
Path. Clearing bit 1 from IO_PREFER_CPUs would result in the
four SCSI devices being bound to CPUs 2, 3, 4, and 5. CPU 1,
which is the default CPU the lock manager will use, will not
have any Fast Path devices.
o You can set the LCKMGR_CPUID system parameter to tell the
LCKMGR_SERVER process to use a CPU other than the default. For
the above example, setting this system parameter to 7 would
result in the LCKMGR_SERVER process running on CPU 7. The Fast
Path devices would by default be bound to CPUs 1, 2, 3, and 4.
3. 5.5 - Using on AlphaServer GS Series Systems
The new AlphaServer GS Series Systems (GS80, GS160, and the
GS320) have NUMA memory characteristics. When using the Dedicated
CPU Lock Manager on one of these systems, the best performance is
obtained by utilizing a CPU and memory from within a single Quad
Building Block (QBB).
For OpenVMS Version 7.3, the Dedicated CPU Lock Manager does not
yet have the ability to decide from where QBB memory should be
allocated. However, there is a method to preallocate lock manager
memory from the low QBB. This can be done with the LOCKIDTBL
system parameter. This system parameter indicates the initial
size of the Lock ID Table, along with the initial amount of
memory to preallocate for lock manager data structures.
To preallocate the proper amount of memory, this system parameter
should be set to the highest number of locks plus resources
on the system. The command MONITOR LOCK can provide this
information. If MONITOR indicates the system has 100,000 locks
and 50,000 resources, then setting LOCKIDTBL to the sum of these
two values will ensure that enough memory is initially allocated.
Adding in some additional overhead may also be beneficial.
Setting LOCKIDTBL to 200,000 thus might be appropriate.
If necessary, use the LCKMGR_CPUID system parameter to ensure
that the LCKMGR_SERVER runs on a CPU in the low QBB.
3.6 - Enterprise Directory for e-Business (Alpha)
OpenVMS Enterprise Directory for e-Business is a massively
scalable directory service, providing both X.500 and LDAPv3
services on OpenVMS Alpha with no separate license fee. OpenVMS
Enterprise Directory for e-Business provides the following:
o Large percentage of the Fortune 500 already deploy Compaq
X.500 Directory Service (the forerunner of OpenVMS Enterprise
Directory for e-Business)
o World's first 64-bit directory service
o Seamlessly combines the scalability and distribution features
of X.500 with the popularity and interoperability offered by
LDAPv3
o Inherent replication/shadowing features may be exploited to
guarantee 100% up-time
o Systems distributed around the world can be managed from a
single point
o Ability to store all types of authentication and security
certificates across the enterprise accessible from any
location
o Highly configurable schema
o In combination with AlphaServer technology and in-memory
database delivers market leading performance and low
initiation time
For more detailed information, refer to the Compaq OpenVMS e-
Business Infrastructure CD-ROM package which is included in the
OpenVMS Version 7.3 CD-ROM kit.
3.7 - Extended File Cache (Alpha)
The Extended File Cache (XFC) is a new virtual block data cache
provided with OpenVMS Alpha Version 7.3 as a replacement for the
Virtual I/O Cache.
Similar to the Virtual I/O Cache, the XFC is a clusterwide, file
system data cache. Both file system data caches are compatible
and coexist in an OpenVMS Cluster.
The XFC improves I/O performance with the following features that
are not available with the Virtual I/O Cache:
o Read-ahead caching
o Automatic resizing of the cache
o Larger maximum cache size
o No limit on the number of closed files that can be cached
o Control over the maximum size of I/O that can be cached
o Control over whether cache memory is static or dynamic
For more information, refer to the chapter on Managing Data
Caches in the OpenVMS System Manager's Manual, Volume 2: Tuning,
Monitoring, and Complex Systems.
3.8 - ARB SUPPORT Qualifier Added to INSTALL Utility
Beginning with OpenVMS Alpha Version 7.3, you can use the /ARB_
SUPPORT qualifier with the ADD, CREATE, and REPLACE commands in
the INSTALL utility. The ARB_SUPPORT qualifier provides Access
Rights Block (ARB) support to products that have not yet been
updated the per-thread security Persona Security Block (PSB) data
structure.
This new qualifier is included in the INSTALL utility
documentation in the OpenVMS System Management Utilities
Reference Manual.
3.9 - MONITOR Utility
The MONITOR utility has two new class names, RLOCK and TIMER,
which you can use as follows:
o MONITOR RLOCK: the dynamic lock remastering statistics of a
node
o MONITOR TIMER: Timer Queue Entry (TQE) statistics
These enhancements are discussed in more detail in the MONITOR
section of the OpenVMS System Management Utilities Reference
Manual and in the appendix that discusses MONITOR record formats
in that manual.
Also in the MONITOR utility, the display screens of MONITOR
CLUSTER, PROCESSES/TOPCPU, and SYSTEM now have new and higher
scale values. Refer to the OpenVMS System Management Utilities
Reference Manual: M-Z for more information.
3.10 - OpenVMS Cluster Systems
The following OpenVMS Cluster features are discussed in this
section:
o Clusterwide intrusion detection
o Fast Path for SCSI and Fibre Channel (Alpha)
o Floppy disks served in an OpenVMS Cluster system (Alpha)
o New Fibre Channel support (Alpha)
o Switched LAN as a cluster interconnect
o Warranted and migration support
3. 10.1 - Clusterwide Intrusion Detection
OpenVMS Version 7.3 includes clusterwide intrusion detection,
which extends protection against attacks of all types throughout
the cluster. Intrusion data and information from each system are
integrated to protect the cluster as a whole. Member systems
running versions of OpenVMS prior to Version 7.3 and member
systems that disable this feature are protected individually
and do not participate in the clusterwide sharing of intrusion
information.
You can modify the SECURITY_POLICY system parameter on the
member systems in your cluster to maintain either a local or a
clusterwide intrusion database of unauthorized attempts and the
state of any intrusion events.
If bit 7 in SECURITY_POLICY is cleared, all cluster members
are made aware if a system is under attack or has any intrusion
events recorded. Events recorded on one system can cause another
system in the cluster to take restrictive action. (For example,
the person attempting to log in is monitored more closely and
limited to a certain number of login retries within a limited
period of time. Once a person exceeds either the retry or time
limitation, he or she cannot log in.) The default for bit 7 in
SECURITY_POLICY is clear.
For more information on the system services $DELETE_INTRUSION,
$SCAN_INTRUSION, and $SHOW_INTRUSION, refer to the OpenVMS System
Services Reference Manual.
For more information on the DCL commands DELETE/INTRUSION_RECORD
and SHOW INTRUSION, refer to the OpenVMS DCL Dictionary.
For more information on clusterwide intrusion detection, refer to
the OpenVMS Guide to System Security.
3. 10.2 - Fast Path for SCSI and Fibre Channel (Alpha)
Fast Path for SCSI and Fibre Channel (FC) is a new feature with
OpenVMS Version 7.3. This feature improves the performance of
Symmetric Multi-Processing (SMP) machines that use certain SCSI
ports, or FC.
In previous versions of OpenVMS, SCSI and FC I/O completion was
processed solely by the primary CPU. When Fast Path is enabled,
the I/O completion processing can occur on all the processors in
the SMP system. This substantially increases the potential I/O
throughput on an SMP system, and helps to prevent the primary CPU
from becoming saturated.
See FAST_PATH_PORTS for information about the SYSGEN parameter,
FAST_PATH_PORTS, that has been introduced to control Fast Path
for SCSI and FC.
3. 10.3 - Floppy Disks Served
Until this release, MSCP was limited to serving disks. Beginning
with OpenVMS Version 7.3, serving floppy disks in an OpenVMS
Cluster system is supported, enabled by MSCP.
For floppy disks to be served in an OpenVMS Cluster system,
floppy disk names must conform to the naming conventions for
port allocation class names. For more information about device
naming with port allocation classes, refer to the OpenVMS Cluster
Systems manual.
OpenVMS VAX clients can access floppy disks served from OpenVMS
Alpha Version 7.3 MSCP servers, but OpenVMS VAX systems cannot
serve floppy disks. Client systems can be any version that
supports port allocation classes.
3. 10.4 - New Fibre Channel Support (Alpha)
Support for new Fibre Channel hardware, larger configurations,
Fibre Channel Fast Path, and larger I/O operations is included in
OpenVMS Version 7.3. The benefits include:
o Support for a broader range of configurations: the lower cost
HSG60 controller supports two SCSI buses instead of six SCSI
buses supported by the HSG80; multiple DSGGB 16-port Fibre
Channel switches enable very large configurations.
o Backup operations to tape, enabled by the new Modular Data
Router (MDR), using existing SCSI tape subsystems
o Distances up to 100 kilometers between systems, enabling
more configuration choices for multiple-site OpenVMS Cluster
systems
o Better performance for certain types of I/O due to Fibre
Channel Fast Path and support for larger I/O requests
The following new Fibre Channel hardware has been qualified on
OpenVMS Version 7.2-1 and on OpenVMS Version 7.3:
o KGPSA-CA host adapter
o DSGGB-AA switch (8 ports) and DSGGB-AB switch (16 ports)
o HSG60 storage controller (MA6000 storage subsystem)
o Compaq Modular Data Router (MDR)
OpenVMS now supports Fibre Channel fabrics. A Fibre Channel
fabric is multiple Fibre Channel switches connected together.
(A Fibre Channel fabric is also known as cascaded switches.)
Configurations that use Fibre Channel fabrics can be extremely
large. Distances up to 100 kilometers are supported in a
multisite OpenVMS Cluster system. OpenVMS supports the Fibre
Channel SAN configurations described in the Compaq StorageWorks
Heterogeneous Open SAN Design Reference Guide, available at the
following Compaq web site:
http://www.compaq.com/storage
Enabling Fast Path for Fibre Channel can substantially increase
the I/O throughput on an SMP system. For more information about
this new feature, see Fast Path for SCSI and Fibre Channel
(Alpha).
Prior to OpenVMS Alpha Version 7.3, I/O requests larger than
127 blocks were segmented by the Fibre Channel driver into
multiple I/O requests. Segmented I/O operations generally have
lower performance than one large I/O. In OpenVMS Version 7.3,
I/O requests up to and including 256 blocks are done without
segmenting.
For more information about Fibre Channel usage in OpenVMS Cluster
configurations, refer to the Guidelines for OpenVMS Cluster
Configurations.
3. 10. 4.1 - Tape Support
Fibre Channel tape functionality refers to the support of SCSI
tapes and SCSI tape libraries in an OpenVMS Cluster system with
shared Fibre Channel storage. The SCSI tapes and libraries are
connected to the Fibre Channel by a Fibre-to-SCSI bridge known as
the Modular Data Router (MDR).
For configuration information, refer to the Guidelines for
OpenVMS Cluster Configurations.
3. 10.5 - LANs as Cluster Interconnects
An OpenVMS Cluster system can use several LAN interconnects for
node-to-node communication, including Ethernet, Fast Ethernet,
Gigabit Ethernet, ATM, and FDDI.
PEDRIVER, the cluster port driver, provides cluster
communications over LANs using the NISCA protocol. Originally
designed for broadcast media, PEDRIVER has been redesigned to
exploit all the advantages offered by switched LANs, including
full duplex transmission and more complex network topologies.
Users of LANs for their node-to-node cluster communication will
derive the following benefits from the redesigned PEDRIVER:
o Removal of restrictions for using Fast Ethernet, Gigabit
Ethernet, and ATM as cluster interconnects
o Improved performance due to better path selection, multipath
load distribution, and support of full duplex communication
o Greater scalability
o Ability to monitor, manage, and display information needed to
diagnose problems with cluster use of LAN adapters and paths
3. 10. 5.1 - SCA Control Program
The SCA Control Program (SCACP) utility is designed to monitor
and manage cluster communications. (SCA is the abbreviation
of Systems Communications Architecture, which defines the
communications mechanisms that enable nodes in an OpenVMS Cluster
system to communicate.)
In OpenVMS Version 7.3, you can use SCACP to manage SCA use
of LAN paths. In the future, SCACP might be used to monitor
and manage SCA communications over other OpenVMS Cluster
interconnects.
This utility is described in more detail in a new chapter in the
OpenVMS System Management Utilities Reference Manual: M-Z.
3. 10. 5.2 - Packet Loss Error
Prior to OpenVMS Version 7.3, an SCS virtual circuit closure
was the first indication that a LAN path had become unusable. In
OpenVMS Version 7.3, whenever the last usable LAN path is losing
packets at an excessive rate, PEDRIVER displays the following
console message:
%PEA0, Excessive packet losses on LAN Path from local-device-name -
_ to device-name on REMOTE NODE node-name
This message is displayed after PEDRIVER performs an excessively
high rate of packet retransmissions on the LAN path consisting of
the local device, the intervening network, and the device on the
remote node. The message indicates that the LAN path has degraded
and is approaching, or has reached, the point where reliable
communications with the remote node are no longer possible. It is
likely that the virtual circuit to the remote node will close if
the losses continue. Furthermore, continued operation with high
LAN packet losses can result in a significant loss in performance
because of the communication delays resulting from the packet
loss detection timeouts and packet retransmission.
The corrective steps to take are:
1. Check the local and remote LAN device error counts to see if a
problem exists on the devices. Issue the following commands on
each node:
$ SHOW DEVICE local-device-name
$ MC SCACP
SCACP> SHOW LAN device-name
$ MC LANCP
LANCP> SHOW DEVICE device-name/COUNT
2. If device error counts on the local devices are within normal
bounds, contact your network administrators to request that
they diagnose the LAN path between the devices.
If necessary, contact your COMPAQ support representative for
assistance in diagnosing your LAN path problems.
For additional PEDRIVER troubleshooting information, see Appendix
F of the OpenVMS Cluster Systems manual.
3. 10.6 - Warranted and Migration Support
Compaq provides two levels of support, warranted and migration,
for mixed-version and mixed-architecture OpenVMS Cluster systems.
Warranted support means that Compaq has fully qualified the two
versions coexisting in an OpenVMS Cluster and will answer all
problems identified by customers using these configurations.
Migration support is a superset of the Rolling Upgrade support
provided in earlier releases of OpenVMS and is available for
mixes that are not warranted. Migration support means that Compaq
has qualified the versions for use together in configurations
that are migrating in a staged fashion to a newer version of
OpenVMS VAX or of OpenVMS Alpha. Problem reports submitted
against these configurations will be answered by Compaq. However,
in exceptional cases, Compaq may request that you move to a
warranted configuration as part of answering the problem.
Compaq supports only two versions of OpenVMS running in a cluster
at the same time, regardless of architecture. Migration support
helps customers move to warranted OpenVMS Cluster version mixes
with minimal impact on their cluster environments.
The following table shows the level of support provided for all
possible version pairings.
Table 4-2 Warranted and Migration Support
Alpha
Alpha/VAX V7.2-xxx/
V7.3 VAX V7.2 Alpha/VAX V7.1
Alpha/VAX WARRANTED Migration Migration
V7.3
Alpha Migration WARRANTED Migration
V7.2-xxx/
VAX V7.2
Alpha/VAX Migration Migration WARRANTED
V7.1
In a mixed-version cluster with OpenVMS Version 7.3, you must
install remedial kits on earlier versions of OpenVMS. For OpenVMS
Version 7.3, two new features, XFC and Volume Shadowing minicopy,
cannot be run on any node in a mixed version cluster unless all
nodes running earlier versions of OpenVMS have installed the
required remedial kit or upgrade. Remedial kits are available
now for XFC. An upgrade for systems running OpenVMS Version 7.2-
xx that supports minicopy will be made available soon after the
release of OpenVMS Version 7.3.
For a complete list of required remedial kits, refer to the
OpenVMS Version 7.3 Release Notes.
3.11 - SMP Performance Improvements (Alpha)
OpenVMS Alpha Version 7.3 contains software changes that improve
SMP scaling. Designed for applications running on the new
AlphaServer GS-series systems, many of these improvements will
benefit all customer applications. The OpenVMS SMP performance
improvements in Version 7.3 include the following:
o Improved MUTEX Acquisition
Mutexes are used for synchronization of numerous events on
OpenVMS. The most common use of a mutex is for synchronization
of the logical names database and I/O base. In releases prior
to OpenVMS Alpha Version 7.3, the manipulation of a mutex
was completed with the SCHED spinlock held. Because the SCHED
spinlock is a heavily used spinlock with high contention on
large SMP systems and only a single CPU could manipulate a
mutex, bottlenecks often occurred.
OpenVMS Alpha Version 7.3 changes the way mutexes are
manipulated. The mutex itself is now manipulated with atomic
instructions. Thus multiple CPUs manipulate different mutexes
in parallel. In most cases, the need to acquire the SCHED
spinlock has been avoided. In cases where a process must be
placed into a mutex wait state or when mutex waiters must wake
up, SCHED will still need to be acquired.
o Improved Process Scheduling
Changes made to the OpenVMS process scheduler reduce
contention on the SCHED spinlock. Prior to OpenVMS Version
7.3, when a process became computable, the scheduler released
all IDLE CPUs to attempt to execute the process. On NUMA
systems, all idle CPUs in the RAD were released. These idle
CPUs competed for the SCHED spinlock, which added to the
contention on the SCHED spinlock. As of OpenVMS Version 7.3,
the scheduler only releases a single CPU. In addition, the
scheduler releases high numbered CPUs first. This has the
effect of avoiding scheduling processes on the primary CPU
when possible.
To use the modified scheduler, users must set the system
parameter SCH_CTLFLAGS to 1. This parameter is dynamic.
o Improved SYS$RESCHED
A number of applications and libraries use the SYS$RESCHED
system service, which requests a CPU to reschedule another
process. In releases prior to OpenVMS Version 7.3, this
system service would lock the SCHED spinlock and attempt to
reschedule another computable process on the CPU.
Prior to OpenVMS Version 7.3, when heavy contention existed
on the SCHED spinlock, using SYS$RESCHED system increased
resources contention. As of OpenVMS Version 7.3, the
SYS$RESCHED system service attempts to acquire the SCHED
spinlock with a NOSPIN routine. Thus, if the SCHED spinlock
is currently locked, this thread will not spin. It will return
back to the caller.
o Lock Manager 2000 and 180 improvements
There are several changes to the lock manager. For OpenVMS
Clusters, the lock manager no longer uses IOLOCK8 for
synchronization. It now uses the LCKMGR spinlock, which allows
locking and I/O operations to occur in parallel.
Remaster operations can be performed much faster now. The
remaster code sends large messages with data from many locks
when remastering as opposed to sending a single lock per
message.
The lock manager supports a Dedicated CPU mode. In cases
where there is very heavy contention on the LCKMGR spinlock,
dedicating a single CPU to performing locking operations
provides a much more efficient mechanism.
o Enhanced Spinlock Tracing capability
The spinlock trace capability, which first shipped in V7.2-
1H1, can now trace forklocks. In systems with heavy contention
on the IOLOCK8 spinlock, much of the contention occurs in fork
threads. Collecting traditional spinlock data only indicates
that the fork dispatcher locked IOLOCK8.
As of OpenVMS Version 7.3, the spinlock trace has a hook in
the fork dispatcher code. This allows the trace to report
the routine that is called by the fork dispatch, which
indicates the specific devices that contribute to heavy
IOLOCK8 contention.
o Mailbox driver change
Prior to OpenVMS Version 7.3, the mailbox driver FDT routines
called a routine that locked the MAILBOX spinlock and
delivered any required attention ASTs. In most cases, this
routine did not require any attention ASTs to be delivered.
Because the OpenVMS code that makes these calls already has
the MAILBOX spinlock locked, the spinlock acquisition was also
an unneeded second acquire of the spinlock.
As of OpenVMS Version 7.3, OpenVMS now first checks to see
if any ASTs may need to be delivered prior to calling the
routine. This avoids both the call overhead and the overhead
of relocking the MAILBOX spinlock that was already owned.
3.12 - SYSMAN Commands and Qualifiers
The SYSMAN utility has the following new commands:
o CLASS_SCHEDULE commands
The class scheduler provides the ability to limit the amount
of CPU time that a system's users receive by placing users in
scheduling classes.
Command Description
CLASS_SCHEDULE ADD Creates a new scheduling class
CLASS_SCHEDULE DELETE Deletes a scheduling class
CLASS_SCHEDULE MODIFY Modifies the characteristics of a
scheduling class
CLASS_SCHEDULE RESUME Resumes a scheduling class that has
been suspended
CLASS_SCHEDULE SHOW Displays the characteristics of a
scheduling class
CLASS_SCHEDULE SUSPEND Temporarily suspends a scheduling
class
o IO FIND_WWID and IO_REPLACE_WWID (Alpha-only)
These commands support Fibre Channel tapes, which are
discussed in Tape Support.
Command Description
IO FIND_WWID Detects all previously undiscovered
tapes and medium changers
IO REPLACE_WWID Replaces one worldwide identifier
(WWID) with another
o POWER_OFF qualifier for SYSMAN command SHUTDOWN NODE
The /POWER_OFF qualifier specifies that the system is to power
off after shutdown is complete.
For more information, refer to the SYSMAN section of the OpenVMS
System Management Utilities Reference Manual: M-Z.
3.13 - New System Parameters
This section contains definitions of system parameters that are
new in OpenVMS Version 7.3.
3. 13.1 - AUTO_DLIGHT_SAV
AUTO_DLIGHT_SAV is set to either 1 or 0. The default is 0.
If AUTO_DLIGHT_SAV is set to 1, OpenVMS automatically makes the
change to and from daylight saving time.
3. 13.2 - FAST_PATH_PORTS
FAST_PATH_PORTS is a static parameter that deactivates Fast Path
for specific drivers.
FAST_PATH_PORTS is a 32-bit mask. If the value of a bit in the
mask is 1, Fast Path is disabled for the driver corresponding to
that bit. A value of -1 specifies that Fast Path is disabled for
all drivers that the FAST_PATH_PORTS parameter controls.
Bit position zero controls Fast Path for PKQDRIVER (for parallel
SCSI), and bit position one controls Fast Path for FGEDRIVER
(for Fibre Channel). Currently, the default setting for FAST_
PATH_PORTS is 0, which means that Fast Path is enabled for both
PKQDRIVER and FGEDRIVER.
In addition, note the following:
o CI drivers are not controlled by FAST_PATH_PORTS. Fast Path
for CI is enabled and disabled exclusively by the FAST_PATH
system parameter.
o FAST_PATH_PORTS is relevant only if the FAST_PATH system
parameter is enabled (equal to 1). Setting FAST_PATH to zero
has the same effect as setting FAST_PATH_PORTS to -1.
For additional information, see FAST_PATH and IO_PREFER_CPUS.
3. 13.3 - GLX_SHM_REG
On Galaxy systems, GLX_SHM_REG is the number of shared memory
region structures configured into the Galaxy Management Database
(GMDB). If you set GLX_SHM_REG to 0, the default number of shared
memory regions are configured.
3. 13.4 - LCKMGR CPUID (Alpha)
The LCKMGR_CPUID parameter controls the CPU that the Dedicated
CPU Lock Manager runs on. This is the CPU that the LCKMGR_SERVER
process will utilize if you turn this feature on with the LCKMGR_
MODE system parameter.
If the specified CPU ID is either the primary CPU or a
nonexistent CPU, the LCKMGR_SERVER process will utilize the
lowest nonprimary CPU.
LCKMGR_CPUID is a DYNAMIC parameter.
For more information, see the LCKMGR_MODE system parameter.
3. 13.5 - LCKMGR MODE (Alpha)
The LCKMGR_MODE parameter controls usage of the Dedicated CPU
Lock Manager. Setting LCKMGR_MODE to a number greater than zero
(0) indicates the number of CPUs that must be active before the
Dedicated CPU Lock Manager is turned on.
The Dedicated CPU Lock Manager performs all locking operations
on a single dedicated CPU. This can improve system performance
on large SMP systems with high MP_Synch associated with the lock
manager.
For more information about usage of the Dedicated CPU Lock
Manager, see the OpenVMS Performance Management manual.
Specify one of the following:
Value Description
0 Indicates the Dedicated CPU Lock Manager is off. (The
default.)
>0 Indicates the number of CPUs that must be active before
the Dedicated CPU Lock Manager is turned on.
LCKMGR_MODE is a DYNAMIC parameter.
3. 13.6 - NPAGECALC
NPAGECALC controls whether the system automatically calculates
the initial size for nonpaged dynamic memory.
Compaq sets the default value of NPAGECALC to 1 only during the
initial boot after an installation or upgrade. When the value of
NPAGECALC is 1, the system calculates an initial value for the
NPAGEVIR and NPAGEDYN system parameters. This calculated value is
based on the amount of physical memory in the system.
NPAGECALC's calculations do not reduce the values of NPAGEVIR and
NPAGEDYN from the values you see or set at the SYSBOOT prompt.
However, NPAGECALC's calculation might increase these values.
AUTOGEN sets NPAGECALC to 0. NPAGECALC should always remain 0
after AUTOGEN has determined more refined values for the NPAGEDYN
and NPAGEVIR system parameters.
3. 13.7 - NPAGERAD (Alpha)
NPAGERAD specifies the total number of bytes of nonpaged pool
that will be allocated for Resource Affinity Domains (RADs) other
than the base RAD. For platforms that have no RADs, NPAGERAD
is ignored. Notice that NPAGEDYN specifies the total amount of
nonpaged pool for all RADs.
Also notice that the OpenVMS system might round the specified
values higher to an even number of pages for each RAD, which
prevents the base RAD from having too little nonpaged pool. For
example, if the hardware is an AlphaServer GS160 with 4 RADs:
NPAGEDYN = 6291456 bytes
NPAGERAD = 2097152 bytes
In this case, the OpenVMS system allocates a total of
approximately 6,291,456 bytes of nonpaged pool. Of this amount,
the system divides 2,097,152 bytes among the RADs that are not
the base RAD. The system then assigns the remaining 4,194,304
bytes to the base RAD.
3. 13.8 - RAD SUPPORT (Alpha)
RAD_SUPPORT enables RAD-aware code to be executed on systems
that support Resource Affinity Domains (RADs); for example,
AlphaServer GS160 systems.
A RAD is a set of hardware components (CPUs, memory, and I/O)
with common access characteristics. For more information
about using OpenVMS RAD features, refer to the OpenVMS Alpha
Partitioning and Galaxy Guide.
3. 13.9 - SHADOW_MAX_UNIT
SHADOW_MAX_UNIT specifies the maximum number of shadow sets that
can exist on a node. The setting must be equal to or greater
than the number of shadow sets you plan to have on a system.
Dismounted shadow sets, unused shadow sets, and shadow sets with
no write bitmaps allocated to them are included in the total.
This system parameter is not dynamic; that is, a reboot is
required when you change the setting.
The default setting on OpenVMS Alpha systems is 500; on OpenVMS
VAX systems, the default is 100. The minimum value is 10, and the
maximum value is 10,000.
Note that this parameter does not affect the naming of shadow
sets. For example, with the default value of 100, a device name
such as DSA999 is still valid.
3. 13.10 - VCC MAX IO SIZE (Alpha)
The dynamic system parameter VCC_MAX_IO_SIZE controls the maximum
size of I/O that can be cached by the Extended File Cache. It
specifies the size in blocks. By default, the size is 127 blocks.
Changing the value of VCC_MAX_IO_SIZE affects reads and writes to
volumes currently mounted on the local node, as well as reads and
writes to volumes mounted in the future.
If VCC_MAX_IO_SIZE is 0, the Extended File Cache on the local
node cannot cache any reads or writes. However, the system is
not prevented from reserving memory for the Extended File Cache
during startup if a VCC$MIN_CACHE_SIZE entry is in the reserved
memory registry.
VCC_MAX_IO_SIZE is a DYNAMIC parameter.
3. 13.11 - VCC READAHEAD (Alpha)
The dynamic system parameter VCC_READAHEAD controls whether
the Extended File Cache can use read-ahead caching. Read-
ahead caching is a technique that improves the performance of
applications that read data sequentially.
By default VCC_READAHEAD is 1, which means that the Extended File
Cache can use read-ahead caching. The Extended File Cache detects
when a file is being read sequentially in equal-sized I/Os, and
fetches data ahead of the current read, so that the next read
instruction can be satisfied from cache.
To stop the Extended File Cache from using read-ahead caching,
set VCC_READAHEAD to 0.
Changing the value of VCC_READAHEAD affects volumes currently
mounted on the local node, as well as volumes mounted in the
future.
Readahead I/Os are totally asynchronous from user I/Os and only
take place if sufficient system resources are available.
VCC_READAHEAD is a DYNAMIC parameter.
3. 13.12 - WBM_MSG_INT
WBM_MSG_INT is one of three system parameters that are available
for managing the update traffic between a master write bitmap
and its corresponding local write bitmaps in an OpenVMS Cluster
system. (Write bitmaps are used by the volume shadowing software
for minicopy operations.) The others are WBM_MSG_UPPER and
WBM_MSG_LOWER. These parameters set the interval at which the
frequency of sending messages is tested and also set an upper and
lower threshold that determine whether the messages are grouped
into one SCS message or are sent one by one.
In single-message mode, WBM_MSG_INT is the time interval in
milliseconds between assessments of the most suitable write
bitmap message mode. In single-message mode, the writes issued by
each remote node are, by default, sent one by one in individual
SCS messages to the node with the master write bitmap. If the
writes sent by a remote node reach an upper threshold of messages
during a specified interval, single-message mode switches to
buffered-message mode.
In buffered-message mode, WBM_MSG_INT is the maximum time a
message waits before it is sent. In buffered-message mode, the
messages are collected for a specified interval and then sent
in one SCS message. During periods of increased message traffic,
grouping multiple messages to send in one SCS message to the
master write bitmap is generally more efficient than sending each
message separately.
The minimum value of WBM_MSG_INT is 10 milliseconds. The maximum
value is -1, which corresponds to the maximum positive value that
a longword can represent. The default is 10 milliseconds.
WBM_MSG_INT is a DYNAMIC parameter.
3. 13.13 - WBM_MSG_LOWER
WBM_MSG_LOWER is one of three system parameters that are
available for managing the update traffic between a master write
bitmap and its corresponding local write bitmaps in an OpenVMS
Cluster system. (Write bitmaps are used by the volume shadowing
software for minicopy operations.) The others are WBM_MSG_INT
and WBM_MSG_UPPER. These parameters set the interval at which the
frequency of sending messages is tested and also set an upper and
lower threshold that determine whether the messages are grouped
into one SCS message or are sent one by one.
WBM_MSG_LOWER is the lower threshold for the number of messages
sent during the test interval that initiates single-message mode.
In single-message mode, the writes issued by each remote node
are, by default, sent one by one in individual SCS messages
to the node with the master write bitmap. If the writes sent
by a remote node reach an upper threshold of messages during a
specified interval, single-message mode switches to buffered-
message mode.
The minimum value of WBM_MSG_LOWER is 0 messages per interval.
The maximum value is -1, which corresponds to the maximum
positive value that a longword can represent. The default is
10.
WBM_MSG_LOWER is a DYNAMIC parameter.
3. 13.14 - WBM_MSG_UPPER
WBM_MSG_UPPER is one of three system parameters that are
available for managing the update traffic between a master write
bitmap and its corresponding local write bitmaps in an OpenVMS
Cluster system. (Write bitmaps are used by the volume shadowing
software for minicopy operations.) The others are WBM_MSG_INT
and WBM_MSG_LOWER. These parameters set the interval at which the
frequency of sending messages is tested and also set an upper and
lower threshold that determine whether the messages are grouped
into one SCS message or are sent one by one.
WBM_MSG_UPPER is the upper threshold for the number of messages
sent during the test interval that initiates buffered-message
mode. In buffered-message mode, the messages are collected for a
specified interval and then sent in one SCS message.
The minimum value of WBM_MSG_UPPER is 0 messages per interval.
The maximum value is -1, which corresponds to the maximum
positive value that a longword can represent. The default is
100.
WBM_MSG_UPPER is a DYNAMIC parameter.
3. 13.15 - WBM_OPCOM_LVL
WBM_OPCOM_LVL controls whether write bitmap system messages are
sent to the operator console. (Write bitmaps are used by the
volume shadowing software for minicopy operations.) Possible
values are shown in the following table:
Value Description
0 Messages are turned off.
1 The default; messages are provided when write bitmaps are
started, deleted, and renamed, and when the SCS message
mode (buffered or single) changes.
2 All messages for a setting of 1 are provided plus many
more.
WBM_OPCOM_LVL is a DYNAMIC parameter.
3.14 - Volume Shadowing for OpenVMS
Volume Shadowing for OpenVMS introduces three new features, the
minicopy operation enabled by write bitmaps, new qualifiers for
disaster tolerant support for OpenVMS Cluster systems, and a new
/SHADOW qualifier to the INITIALIZE command. These features are
described in this section.
3. 14.1 - Minicopy in Compaq Volume Shadowing (Alpha)
This new minicopy feature of Compaq Volume Shadowing for OpenVMS
and its enabling technology, write bitmaps, are fully implemented
on OpenVMS Alpha systems. OpenVMS VAX nodes can write to shadow
sets that use this feature but they can neither create master
write bitmaps nor manage them with DCL commands. The minicopy
operation is a streamlined copy operation. Minicopy is designed
to be used in place of a copy operation when you return a shadow
set member to the shadow set. When a member has been removed from
a shadow set, a write bitmap tracks the changes that are made to
the shadow set in its absence, as shown in Application Writes to
a Write Bitmap.
When the member is returned to the shadow set, the write bitmap
is used to direct the minicopy operation, as shown in Member
Returned to the Shadow Set (Virtual Unit). While the minicopy
operation is taking place, the application continues to read and
write to the shadow set.
Thus, minicopy can significantly decrease the time it takes
to return the member to membership in the shadow set and can
significantly increase the availability of the shadow sets that
use this feature.
Typically, a shadow set member is removed from a shadow set to
back up the data on the disk. Before the introduction of the
minicopy feature, Compaq required that the virtual unit (the
shadow set) be dismounted to back up the data from one of the
members. This requirement has been removed, provided that the
guidelines for removing a shadow set member for backup purposes,
as documented in Volume Shadowing for OpenVMS, are followed.
For more information about this new feature, including additional
memory requirements for this version of Compaq Volume Shadowing
for OpenVMS, refer to Volume Shadowing for OpenVMS.
3. 14.2 - Multiple-Site OpenVMS Cluster Systems
OpenVMS Version 7.3 introduces new command qualifiers for the
DCL commands DISMOUNT and SET for use with Volume Shadowing for
OpenVMS. These new command qualifiers provide disaster tolerant
support for multiple-site OpenVMS Cluster systems. Designed
primarily for multiple-site clusters that use Fibre Channel for
a site-to-site storage interconnect, they can be used in other
configurations as well. For more information about using these
new qualifiers in a multiple-site OpenVMS Cluster system, see the
white paper Using Fibre Channel in a Disaster-Tolerant OpenVMS
Cluster System, which is posted on the OpenVMS Fibre Channel web
site at:
http://www.openvms.compaq.com/openvms/fibre/
The new command qualifiers are described in this section. Using
DISMOUNT and SET Qualifiers describes how to use these new
qualifiers.
DISMOUNT/FORCE_REMOVAL ddcu:
One new qualifier to the DISMOUNT command, DISMOUNT/FORCE_REMOVAL
ddcu:, is provided. If connectivity to a device has been lost and
the shadow set is in mount verification, /FORCE_REMOVAL ddcu: can
be used to immediately expell a named shadow set member (ddcu:)
from the shadow set. If you omit this qualifier, the device is
not dismounted until mount verification completes. Note that this
qualifier cannot be used in conjunction with the /POLICY=MINICOPY
(=OPTIONAL) qualifier.
The device specified must be a member of a shadow set that is
mounted on the node where the command is issued.
SET DEVICE
The following new qualifiers to the SET DEVICE command have
been created for managing shadow set members located at multiple
sites:
o /FORCE_REMOVAL ddcu:
If connectivity to a device has been lost and the shadow set
is in mount verification, this qualifier causes the member to
be expelled from the shadow set immediately.
If the shadow set is not currently in mount verification, no
immediate action is taken. If connectivity to a device has
been lost but the shadow set is not in mount verification,
this qualifier lets you flag the member to be expelled from
the shadow set, as soon as it does enter mount verification.
The device specified must be a member of a shadow set that is
mounted on the node where the command is issued.
o /MEMBER_TIMEOUT=xxxxxx ddcu:
Specifies the timeout value to be used for a member of a
shadow set.
The value supplied by this qualifier overrides the SYSGEN
parameter SHADOW_MBR_TMO for this specific device. Each member
of a shadow set can be assigned a different MEMBER_TIMEOUT
value.
The valid range for xxxxxx is 1 to 16,777,215 seconds.
The device specified must be a member of a shadow set that is
mounted on the node where the command is issued.
o /MVTIMEOUT=yyyyyy DSAnnnn:
Specifies the mount verification timeout value to be used for
this shadow set, specified by its virtual unit name, DSAnnnn.
The value supplied by this qualifier overrides the SYSGEN
parameter MVTIMEOUT for this specific shadow set.
The valid range for yyyyyy is 1 to 16,777,215 seconds.
The device specified must be a shadow set that is mounted on
the node where the command is issued.
o /READ_COST=zzz ddcu:
The valid range for zzz is 1 to 4,294,967,295 units.
The device specified must be a member of a shadow set that is
mounted on the node where the command is issued.
This qualifier allows you to modify the default "cost"
assigned to each member of a shadow set, so that reads are
biased or prioritized toward one member versus another.
The shadowing driver assigns default READ_COST values to
shadow set members when each member is initially mounted.
The default value depends on the device type, and its
configuration relative to the system mounting it. There are
default values for a DECRAM device; a directly connected
device in the same physical location; a directly connected
device in a remote location; a DECram served device; and a
default value for other served devices.
The value supplied by this qualifier overrides the default
assignment. The shadowing driver adds the value of the current
queue depth of the shadow set member to the READ_COST value
and then reads from the member with the lowest value.
Different systems in the cluster can assign different costs to
each shadow set member.
If the /SITE command qualifier has been specified, the
shadowing driver will take site values into account when it
assigns default READ_COST values. Note that in order for the
shadowing software to determine if a device is in the category
of "directly connected device in a remote location," the /SITE
command qualifier must have been applied to both the shadow
set and to the individual device.
Reads requested for a shadow set from a system at Site 1 are
performed from a shadow set member that is also at Site 1.
Reads requested for the same shadow set from Site 2 can read
from the member located at Site 2.
o /READ_COST=y DSAnnnn
The valid range for y is any non-zero number. The value
supplied has no meaning in itself. The purpose of this
qualifier is to switch the read cost setting for all shadow
set members back to the default read cost settings established
automatically by the shadowing software. DSAnnnn must be a
shadow set that is mounted on the node from which this command
is issued.
o /SITE=(nnn, logical_name) (ddcu: DSAnnnn:)
This qualifier indicates to the shadowing driver the site
location of the shadow set member or of the shadow set
(represented by its virtual unit name). Prior to using
this qualifier, you can define the site location in the
SYLOGICALS.COM command procedure to simplify its use.
The valid range for nnn is 1 through 255.
The following example shows the site locations defined,
followed by the use of the /SITE qualifier:
$ DEFINE/SYSTEM/EXEC ZKO 1
$ DEFINE/SYSTEM/EXEC LKG 2
$!
$! At the ZKO site ...
$ MOUNT/SYSTEM DSA0/SHAD=($1$DGA0:,$1$DGA1:) TEST
$ SET DEVICE/SITE=ZKO DSA0:
$!
$! At the LKG site ...
$ MOUNT/SYSTEM DSA0/SHAD=($1$DGA0,$1$DGA1) TEST
$ SET DEVICE/SITE=LKG DSA0:
$!
$! At both sites, the following would be used:
$ SET DEVICE/SITE=ZKO $1$DGA0:
$ SET DEVICE/SITE=LKG $1$DGA1:
o /COPY_SOURCE (ddcu:,DSAnnnn:)
Controls whether one or both source members of a shadow
set are used as the source for read data during full copy
operations, when a third member is added to the shadow
set. This only affects copy operations that do not use DCD
operations.
HSG80 controllers have a read-ahead cache, which significantly
improves single-disk read performance. Copy operations
normally alternate reads between the two source members, which
effectively nullifies the benefits of the read-ahead cache.
This qualifier lets you force all reads from a single source
member for a copy operation.
If the shadow set is specified, then all reads for full copy
operations will be performed from whichever disk is the
current "master" member, regardless of physical location of
the disk.
If a member of the shadow set is specified, then that member
will be used as the source of all copy operations. This allows
you to choose a local source member, rather than a remote
master member.
o /ABORT_VIRTUAL_UNIT DSAnnnn:
To use this qualifier, the shadow set must be in mount
verification. When you specify this qualifier, the shadow
set aborts mount verification immediately on the node from
which the qualifier is issued. This qualifier is intended to
be used when it is known that the unit cannot be recovered.
Note that after this command completes, the shadow set must
still be dismounted. Use the following command to dismount the
shadow set:
DISMOUNT/ABORT DSAnnnn
3. 14. 2.1 - Using DISMOUNT and SET Qualifiers
The diagram in this section depicts a typical multiple-site
cluster using Fibre Channel. It is used to illustrate the steps
which must be taken to manually recover one site when the site-
to-site storage interconnect fails. Note that with current Fibre
Channel support, neither site can use the MSCP server to regain a
path to the DGA devices.
To prevent the shadowing driver from automatically recovering
shadow sets from connection-related failures, three steps must be
taken prior to any failure:
1. Every device that is a member of a multiple-site shadow set
must have its member_timeout setting raised to a high value,
using the following command:
$ SET DEVICE /MEMBER_TIMEOUT= x ddcu:
This command will override the SHADOW_MBR_TMO value, which
would normally be used for a shadow set member. A value for x
of 259200 would be a seventy-two hour wait time.
2. Every shadow set that spans multiple sites must have its mount
verification timeout setting raised to a very high value,
higher than the MEMBER_TIMEOUT settings for each member of the
shadow set.
Use the following command to increase the mount verification
timeout setting for the shadow set:
$ SET DEVICE /MVTIMEOUT = y DSAnnnn
The y value of this command should always be greater than the
x value of the $ SET DEVICE/MEMBER_TIMEOUT= x ddcu:.
The $ SET DEVICE /MVTIMEOUT = y command will override the
MVTIMEOUT value, which would normally be used for the shadow
set. A value for y of 262800 would be a seventy-three hour
wait.
3. Every shadow set and every shadow set member must have a site
qualifier. As already noted, a site qualifier will ensure that
the read cost is correctly set. The other critical factor is
three-member shadow sets. When they are being used, the site
qualifier will ensure that the master member of the shadow set
will be properly maintained.
In the following diagram, shadow set DSA42 is made up of
$1$DGA1000 and $1$DGA2000
<><><><><><><><><><><> LAN <><><><><><><><><><><>
Site A Site B
| |
F.C. SWITCH <><><><> XYZZY <><><><> F.C. SWITCH
| |
HSG80 <><> HSG80 HSG80 <><> HSG80
| |
$1$DGA1000 --------- DSA42 --------- $1$DGA2000
This diagram illustrates that systems at Site A or Site B have
direct access to all devices at both sites via Fibre Channel
connections. XYZZY is a theoretical point between the two sites.
If the Fibre Channel connection were to break at this point,
each site could access different "local" members of DSA42 without
error. For the purpose of this example, Site A will be the sole
site chosen to retain access to the shadow set.
The following actions must be taken to recover the shadow set at
Site A.
On Site A:
$ DISMOUNT /FORCE_REMOVAL= $1$DGA2000:
Once the command has completed, the shadow set will be available
for use only at site A.
On Site B:
$ SET DEVICE /ABORT_VIRTUAL_UNIT DSA42:
Once the command completes, the shadow set status will be
MntVerifyTimeout.
Next, issue the following command to free up the shadow set:
$ DISMOUNT/ABORT DSA42:
These steps must be taken for all affected multiple-site shadow
sets.
3. 14.3 - Using INITIALIZE With SHADOW and ERASE Qualifiers
The new /SHADOW qualifier to the DCL INITIALIZE command is
available. The use of the INITIALIZE /SHADOW command to
initialize multiple members of a future shadow set eliminates
the requirement for a full copy operation when you later create a
shadow set.
Compaq strongly recommends that you also specify the /ERASE
qualifier with the INITIALIZE/SHADOW command when initializing
multiple members of a future shadow set. Whereas the /SHADOW
qualifier eliminates the need for a full copy operation when
you later create a shadow set, the /ERASE qualifier reduces the
amount of time a full merge will take.
If you omit the /ERASE qualifier, and a merge operation of the
shadow set is subsequently required (because a system on which
the shadow set is mounted fails), the resulting merge operation
will take much longer to complete.
The INITIALIZE command with the /SHADOW and /ERASE qualifiers
performs the following operations:
o Formats up to six devices with one command, so that any three
can be subsequently mounted together as members of a new host-
based shadow set.
o Writes a label on each volume.
o Deletes all information from the devices except for the system
files containing identical file structure information. All
former contents of the disks are lost.
You can then mount up to three of the devices that you have
initialized in this way as members of a new host-based shadow
set.
For more information, refer to Volume Shadowing for OpenVMS.
| 4 - Programming Features |
This topic describes new features of interest to application and
system programmers.
4.1 - 3D Graphics Support
The PowerStorm 300 (PBXGD-AD) and PowerStorm 350 (PBXGD-AE)
graphics cards are now supported on Alpha-based systems. The
OpenGL 3D graphics API is now provided as part of the OpenVMS
base operating system. The version of OpenGL supported on the
PowerStorm 300 and PowerStorm 350 graphics cards is Version 1.1.
The implementation of OpenGL Version 1.1 for the PowerStorm 300
or PowerStorm 350 is designed to coexist with installations
of the Open3D layered product for older graphics cards. The
images shipped with OpenVMS are named DECW$OPENGLSHR_V11 and
DECW$OPENGLUSHR_V11. The _V11 suffix is used to distinguish the
OpenGL Version 1.1 images from the OpenGL Version 1.0 images
shipped with Open3D (DECW$OPENGLSHR and DECW$OPENGLUSHR).
Applications using only OpenGL V1.0 features may be linked
against either the Open3D images or the new Version 1.1 images.
Applications using OpenGL Version 1.1 features should be linked
explicitly against the Version 1.1 images.
For further information on OpenGL support for the PowerStorm 300
and PowerStorm 350, refer to the PowerStorm 300/350 Installation
Guide and Release Notes documentation shipped with the graphics
card.
WARNING
If 3D graphics will be used extensively, particularly in
an environment using multiple PowerStorm 300 and PowerStorm
P350s in a single system, read and strictly observe the
guidelines for setting SYSGEN parameters and account quotas
contained in the PowerStorm 300/350 OpenVMS Graphics Support
Release Notes Version 1.1 and the Compaq PowerStorm 300/350
Graphics Controllers Installation Guide shipped with the
graphics card. The Release notes can also be accessed on the
OpenVMS Documentation CD-ROM in the following directory:
Directory File Name
[73.DOCUMENTATION.PS_ P300_350_REL_NOTES.PS,TXT
TXT]
4.2 - 3X-DAPBA-FA and 3X-DAPCA-FA ATM LAN Adapters (Alpha)
The 3X-DAPBA-FA (HE155) and 3X-DAPCA-FA (HE622) are PCI based
ATM LAN adapters for Alpha based systems that provide high
performance PCI-to-ATM capability. The 3X-DAPBA-FA adapter offers
a 155 Mbps fiber connection; the 3X-DAPCA-FA adapter offers a 622
Mbps fiber connection.
The datalink drivers for these adapters function in a new
OpenVMS ATM environment. The new OpenVMS ATM environment is fully
compatible with the existing legacy ATM support and allows both
ATM environments to be configured on a single system. Also, the
LANCP management interface is the same for both ATM environments.
For additional information about the 3X-DAPBA-FA PCI HE155
ATM and 3X-DAPCA-FA PCI HE622 ATM LAN adapters, refer to the
following URL:
http://www.compaq.com/alphaserver/products/options
4.3 - COBOL RTL Enhancements
The COBOL RTL for both Alpha and VAX supports five new intrinsic
functions with four-digit year formats:
YEAR-TO-YYYY
DATE-TO-YYYYMMDD
DAY-TO-YYYYDDD
TEST-DATE-YYYYMMDD
TEST-DAY-YYYYDDD
The COBOL RTL for Alpha has improved performance for the DISPLAY
statement redirected to a file and for programs compiled with the
/MATH=CIT3 and /MATH=CIT4 qualifiers.
This RTL's handling of ON SIZE ERROR is now more compatible with
that of Compaq COBOL for OpenVMS VAX.
4.4 - Compaq C Run-Time Library Enhancements
The following sections describe the Compaq C RTL enhancements
included in OpenVMS Version 7.3. For more details, refer to the
revision of the Compaq C RTL Reference Manual that ships with
Compaq C Version 6.3 or later.
4. 4.1 - Strptime Function Is XPG5-Compliant
The strptime function has been modified to be compliant with
X/Open CAE Specification System Interfaces and Headers Issue
5 (commonly known as XPG5). The change for XPG5 is in how the
strptime function processes the "%y" directive for a two-digit
year within the century if no century is specified.
When a century is not otherwise specified, XPG5 requires that
values for the "%y" directive in the range 69-99 refer to years
in the twentieth century (1969 to 1999 inclusive), while values
in the range 00-68 refer to years in the twenty-first century
(2000 to 2068 inclusive). Essentially, for the "%y" directive,
strptime became a "pivoting" function, with 69 being a pivoting
year.
Before this change, the strptime function interpreted a two-digit
year with no century as a year within twentieth century.
With OpenVMS Version 7.3, XPG5-compliant strptime becomes a
default strptime function in the Compaq C RTL. However, the
previous nonpivoting XPG4-compliant strptime function is retained
for compatibility.
The pivoting is controlled by the DECC$XPG4_STRPTIME logical
name. To use the nonpivoting version of strptime, either:
o Define DECC$XPG4_STRPTIME to any value before invoking the
application.
OR
o Call the nonpivoting strptime directly as the function
decc$strptime_xpg4.
4. 4.2 - Nested Directory Levels Limitation Lifted (Alpha)
The Compaq C RTL I/O subsystem was enhanced to remove the
restriction of eight nested directory levels for an ODS-5 device.
This affects Compaq C RTL functions such as access, mkdir,
opendir, rmdir, and stat.
4. 4.3 - Improved Support for Extended File Specifications (Alpha)
The following sections describe improved Compaq C RTL support for
extended file specifications.
4. 4. 3.1 - Case Preservation
Programs linked against the Compaq C Run-Time Library DECC$SHR
can now preserve the case of file names on ODS level 5 disks.
This applies when creating or reporting file names. By default,
this feature is disabled. To enable this feature, enter the
following command:
$ DEFINE DECC$EFS_CASE_PRESERVE ENABLE
If file names are all in uppercase, use the following command to
convert the names to lowercase when reporting the name in UNIX
style:
$ DEFINE DECC$EFS_CASE_SPECIAL ENABLE
If file names are not all in uppercase, then DEFINE DECC$EFS_
CASE_SPECIAL ENABLE preserves case.
The commands to disable the preceding logical-name settings are:
$ DEFINE DECC$EFS_CASE_PRESERVE DISABLE
$ DEFINE DECC$EFS_CASE_SPECIAL DISABLE
The setting for the DECC$EFS_CASE_SPECIAL logical name, if not
set to DISABLE, supersedes any setting for the DECC$EFS_CASE_
PRESERVE logical name.
The DECC$EFS_CASE_PRESERVE and DECC$EFS_CASE_SPECIAL logicals
are checked only once per image activation, not on a file-by-file
basis.
4. 4. 3.2 - Long File Names
For OpenVMS Alpha Version 7.2, some basic Compaq C RTL I/O
functions (creat, stat, and the functions from the open family
of functions) were enhanced to accept long OpenVMS-style file
names for an ODS-5 device.
For OpenVMS Alpha Version 7.3, all other Compaq C RTL functions,
except chdir and the functions from the exec family of functions,
were also enhanced to accept long OpenVMS-style file names for an
ODS-5 device.
All C RTL functions that accept or report full file
specifications will process file specifications up to 4095 bytes
long, subject to the rules defined for the media format. For
file specifications in OpenVMS format, there are no special
restrictions. In situations where a full file specification
cannot be reported because the buffer is too short, the function
attempts to report the abbreviated name.
UNIX file names have the following restrictions:
o Names containing special characters, such as multiple periods,
caret, or multinational characters, may be rejected.
o A function call may report failure if the output buffer is
not large enough to receive the full name. For OpenVMS style
names, the reported name would contain a file ID-abbreviated
name. There is no representation of file ID-abbreviated names
defined for UNIX.
4. 4.4 - Exact Case Argv Arguments (Alpha)
Nonquoted command-line arguments passed to C and C++ programs
(argv arguments) can now optionally have their case preserved,
rather than being lowercased as in previous versions.
By default, this feature is disabled.
To enable this case preservation feature, define the logical
name DECC$ARGV_PARSE_STYLE to "ENABLE" and set the process-level
DCL parse style flag to "EXTENDED" in the process running the
program:
$ DEFINE DECC$ARGV_PARSE_STYLE ENABLE
$ SET PROCESS/PARSE_STYLE=EXTENDED
Enabling this feature also ensures that the image name returned
in argv[0] is also case-preserved.
To disable this feature, use any one of the following commands:
$ SET PROCESS/PARSE_STYLE=TRADITIONAL
or
$ DEFINE/SYSTEM DECC$ARGV_PARSE_STYLE DISABLE
or
$ DEASSIGN DECC$ARGV_PARSE_STYLE
The value of the DECC$ARGV_PARSE_STYLE logical is case-
insensitive.
4. 4.5 - Implicitly Opening Files for Shared Access
The Compaq C RTL was enhanced to open all files for shared access
as if the "shr=del,get,put,upd" option was specified in the open*
or creat call.
To enable this feature, define the logical name DECC$FILE_SHARING
to the value "ENABLE". The value is case-insensitive.
DECC$FILE_SHARING is checked only once per image activation, not
on a file-by-file basis.
4. 4.6 - Translating UNIX File Specifications
The Compaq C RTL was enhanced to allow interpreting the leading
part of a UNIX-style file specification as either a subdirectory
name or a device name.
The default translation of a "foo/bar" UNIX-style name to a
"foo:bar" VMS-style name remains the default.
To translate a "foo/bar" UNIX-style name to a "[.foo]bar" VMS-
style name, define the logical name DECC$DISABLE_TO_VMS_LOGNAME_
TRANSLATION to ENABLE.
DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION is checked only once per
image activation, not on a file-by-file basis.
4. 4.7 - New Functions
The Compaq C RTL has added the following functions in OpenVMS
Version 7.3:
fchown
link
utime
utimes
writev
4.5 - Fortran Support for 64-Bit Address (Alpha)
Support has been added to OpenVMS Alpha to allow Fortran
developers to use static data in 64-bit address space.
For more information about how to use this feature, refer to the
Fortran documentation.
4.6 - Large Page-File Sections (Alpha)
Page-file sections are used to store temporary data in private
or global (shared) sections of memory. In previous releases of
OpenVMS Alpha, the maximum amount of data that could be backed up
to page files was 32 GB per process (4 process page files, each 8
GB) and 504 GB per system (63 page files, each 8 GB).
With OpenVMS Alpha Version 7.3, the previous limits for page-file
sections were extended significantly to take advantage of larger
physical memory. Now images that use 64-bit addressing can map
and access an amount of dynamic virtual memory that is larger
than the amount of physical memory available on the system.
With the new design, if a process requires additional page-
file space, page files can be allocated dynamically. Space is
no longer reserved in a distinct page file, and pages are no
longer bound to an initially assigned page file. Instead, if
modified pages must be written back, they are written to the best
available page file.
Each page or swap file can hold approximately 16 million pages
(128 GB), and up to 254 page or swap files can be installed.
Files larger than 128 GB are installed as multiple files.
4.7 - Multipath System Services
The new Multipath system services provide the capability to
return path information and allow you to enable, disable, and
switch specific I/O paths to any device.
The concept of multiple I/O paths to storage devices was
introduced in OpenVMS Version 7.2-1. It is now possible to select
more than one I/O path to a device in the event that the path in
use should fail.
To assist in decision making when configuring a system's I/O
structure, the following DCL commands were made available to
allow you to display I/O path information and change the current
settings affecting these paths:
o SET DEVICE device-name/PATH=path-description-string/SWITCH
o SET DEVICE device-name/PATH=path-description-string/[NO]ENABLE
o SHOW DEVICE/MULTIPATH device-name
In OpenVMS Version 7.3, the capability to return path information
and allow you to enable, disable, and switch specific I/O paths
to any device is now implemented in the following new system
services:
o SYS$DEVICE_PATH_SCAN
This service returns path information for a given Multipath
I/O device. Each call to the service returns the name of one
of the paths to the device. A context argument is used to
maintain continuity between calls. This mechanism is similar
to the one currently used for SYS$GETDVI.
o SYS$SET_DEVICE[W]
Use this service to switch the selected path that handles I/O
to a device, or to enable or disable a path for future use in
the event of failover. When switching a path, the path change
is initiated at the time the request is made by the system
service.
The current functions of this service include forcing an
immediate path switch and enabling or disabling paths.
A synchronous version of this service, SYS$SET_DEVICEW, is
also provided. This service returns to the caller only after
the path switch attempt has been made. Should the path switch
fail, an error condition is returned to the caller.
Currently, $SET_DEVICE allows only one valid item list entry.
For additional information, refer to the OpenVMS System Services
Reference Manual.
4.8 - Multiprocess Debugging (Alpha)
For Version 7.3, debugger support for multiprocess programs has
been extensively overhauled. Problems have been corrected and the
user interface has been improved.
The multiprocess debugging enhancements include the following
features:
o Greater control over individual process and groups of
processes, including:
Execution of processes (or groups of processes)
Suspension of processes (or groups of processes)
Exiting processes (or groups of processes), with or without
exit handler execution
o Ability to create user-defined groups of processes
o Easier to start a multiprocess debugging session; the default
configuration of the kept debugger is for a multiprocess
session
o Applications that use $HIBER WAIT (LIB$WAIT, $SCHDWK, and so
on) can now be debugged in a multiprocess debugging session
These enhancements make it much easier to debug multiprocess
programs.
4.9 - Performance API
The Performance Application Programming Interface (API) provides
a documented functional interface-the $GETRMI system service-that
allows performance software engineers to access a predefined list
of performance data items.
For more information about $GETRMI, refer to the OpenVMS System
Services Manual.
4.10 - POLYCENTER Software Installation Utility Enhancements
PDL Changes shows the changes made to the product description
language (PDL) for the POLYCENTER Software Installation
utility.
Table 5-1 PDL Changes
Statement Description
execute upgrade New statement.
execute Modified to execute on a reconfigure
postinstall operation.
file Refinements made to their conflict detection
module and resolution algorithms. For example, when a
file from the kit contains the same non-zero
generation number as the same file already
installed, the file from the kit is selected
to replace the file on disk. Previously,
in this tie situation, the file on disk was
retained to resolve the conflict.
bootstrap block Obsolete. However, the utility will continue
execute release to process these statements in a backward
patch image compatible manner to support existing kits
patch text that might have used them.
Function Description
upgrade Enhanced to fully support version range
checking.
The POLYCENTER Software Installation Utility Developer's Guide
has been extensively revised for this release. Major improvements
include:
o Updated descriptions for most PDL statements.
o A comprehensive presentation on using custom command
procedures with execute statements (added to the Advanced
Topics chapter).
o New tables, diagrams, and examples.
4.11 - New Process Dump Tools (Alpha)
OpenVMS Version 7.3 contains new tools for processing dump files.
Note that these new-style process dump and process dump analysis
tools are not compatible with the old-style process dumps. That
is, if you have a problem you want to analyze with the new tools,
you must generate a new process dump using the new process dump
image.
The following sections describe the new tools.
4. 11.1 - DCL ANALYZE PROCESS DUMP (Alpha)
The DCL ANALYZE/PROCESS_DUMP command invokes the OpenVMS debugger
to analyze a process dump, giving you access to debugger commands
for your analysis. In OpenVMS Version 7.3, most of the old DCL
ANALYZE/PROCESS_DUMP qualifiers have no effect. Only the /FULL
and /IMAGE qualifiers are still valid. Both these qualifiers are
still optional.
/FULL now causes the debugger to execute the debugger SHOW IMAGE,
SHOW CALL, and SHOW THREAD/ALL commands after a process dump file
has been opened.
/IMAGE has been renamed to /IMAGE_PATH, and is now a directory
specification, rather than a file specification. /IMPAGE_PATH
specifies a directory in which to look for the debug symbol
information files (.DSF or .EXE files, in that order) that belong
to the process dump file. The name of the symbol file must be
the same as the image name in the process dump file. For example,
for MYIMAGE.DMP, the debugger searches for file MYIMAGE.DSF or
MYIMAGE.EXE.
Version 7.3 and later debuggers check for dumpfile image
specification and DST file link date-time mismatches and issue
a warning if one is discovered.
For more information about the DCL ANALYZE/PROCESS_DUMP command,
refer to the OpenVMS DCL Dictionary: A-M.
4. 11.2 - Debugger ANALYZE PROCESS DUMP Command
The debugger has a new command:
ANALYZE/PROCESS_DUMP/IMAGE_PATH[=directory-spec] dumpfile.
This command is available only in the kept debugger. The kept
debugger is the image you invoke with the command DEBUG/KEEP,
which allows you to run and rerun programs from the same
debugging session.
The qualifier /PROCESS_DUMP is required.
For more information, refer to the OpenVMS Debugger Manual.
4. 11.3 - Debugger SDA Command
The new debugger SDA command invokes the System Dump Analyzer
(SDA) to allow you to look at a process dump from within the
OpenVMS debugger. For example:
DBG> SDA
OpenVMS (TM) Alpha process dump analyzer
SDA> ..
.
.
SDA> EXIT
DBG>
This allows you to use SDA to analyze a process dump without
terminating a debugger session.
For more information, refer to the OpenVMS Debugger Manual.
4. 11.4 - Analyzing Process Dumps on Different Systems
You can analyze a process dump file on a system different from
the one on which it was generated. However, if there is a base
image link date/time mismatch between the generating system
and analyzing system, you must copy SYS$BASE_IMAGE.EXE from the
generating system and point to it with the SDA$READ_DIR logical
name.
For threaded process dump analysis on a system different from the
one on which it was generated, it may also be necessary to copy
and logically point to the generating system's PTHREAD$RTL and
PTHREAD$DBGSHR (POSIX Threads Library debug assistant).
4. 11.5 - Forcing a Process Dump
You can force a process dump with the DCL command
SET PROCESS/DUMP=NOW process-spec. This command causes the
contents of the address space occupied by process-spec to be
written immediately to the file named image-name.DMP in the
current directory (image-name is the same as the file name).
For more information about the DCL SET PROCESS/DUMP command,
refer to the OpenVMS DCL Dictionary: N-Z.
4. 11.6 - Security and Diskquotas
A process dump is either complete or partial. A complete process
dump contains all of process space and all process-pertinent data
from system space. A partial process dump contains only user-
readable data from process space and only those data structures
from system space that are not deemed sensitive. Privileged
or protected data, such as an encryption key in third-party
software, might be considered sensitive.
In general, nonprivileged users should not be able to read
complete process dumps, and by default they cannot do so.
However, certain situations require nonprivileged users to be
able to read complete process dumps. Other situations require
enabling a user to create a complete process dump while at
the same time preventing that user from being able to read the
complete process dump.
By default, process dumps are written to the current default
directory of the user. The user can override this by defining
the logical name SYS$PROCDMP to identify an alternate directory
path. Note that the name of the process dump file is always the
same as the name of the main image at the time the process dump
is written, with the file extension .DMP.
4. 11. 6.1 - Special Rights Identifiers
You can use the new rights identifier IMGDMP$READALL to allow
a nonprivileged user to read a complete process dump. You
can use the new rights identifier IMGDMP$PROTECT to protect
a complete process dump from being read by the user that
created the process dump. These rights identifiers are created
during the installation of OpenVMS Version 7.3 by the image
SYS$SYSTEM:IMGDMP_RIGHTS.EXE, which is also run automatically
during system startup to ensure that these rights identifiers
exist with the correct values and attributes.
If these rights identifiers have been deleted, you can run
SYS$SYSTEM:IMGDMP_RIGHTS.EXE to recreate them.
Note that IMGDMP$READALL has no attributes, but IMGDMP$PROTECT is
created with the RESOURCE attribute.
4. 11. 6.2 - Privileged Users
For this discussion, a privileged user is one who satisfies one
of the following conditions:
o Has one or more of the privileges CMKRNL, CMEXEC, SYSPRV,
READALL, or BYPASS
o Is a member of a system UIC group (by default [10,n] or
lower). Such users are treated as though they hold SYSPRV
privilege.
Holders of CMKRNL or CMEXEC can write complete process dumps.
Holders of any of the other privileges can read a process dump
wherever it has been written.
4. 11. 6.3 - Nonprivileged Users
To allow a nonprivileged user to write and read complete process
dumps, grant the rights identifier IMGDMP$READALL to the user.
If the IMGDMP$READALL rights identifier does not exist, run the
image SYS$SYSTEM:IMGDMP_RIGHTS.EXE to create it (see Special
Rights Identifiers). Then use AUTHORIZE to grant the rights
identifier to the user. For example:
$ DEFINE /USER SYSUAF SYS$SYSTEM:SYSUAF.DAT !if necessary
$ RUN SYS$SYSTEM:AUTHORIZE
UAF> GRANT /IDENTIFIER IMGDMP$READALL <user>
UAF> EXIT
Note that the user must log out and log in again to be able to
receive the rights identifier. A nonprivileged user with rights
identifier IMGDMP$READALL can read and write complete process
dumps without restriction.
4. 11. 6.4 - Protecting Process Dumps
You can allow a nonprivileged user to write a complete process
dump and at the same time prevent the user from reading the
process dump just written. To do so, perform the following
procedure:
1. If the IMGDMP$PROTECT rights identifier does not exist, run
the image SYS$SYSTEM:IMGDMP_RIGHTS.EXE to create it (see
Special Rights Identifiers).
2. Create a protected directory with rights identifier
IMGDMP$PROTECT.
3. Define protected logical name SYS$PROTECTED_PROCDMP to point
to the protected directory.
If DISKQUOTA is to be used on the disk containing the
protected directory, specify the maximum disk space to be
used for process dumps.
CAUTION
Do not grant IMGDMP$PROTECT to any user. It is granted and
revoked as needed by SYS$SHARE:IMGDMP.EXE from executive
mode while writing a process dump. If you grant it
permanently to a user, that user has access to all process
dumps written to the protected directory.
You can choose to set up additional ACLs on the protected
directory to further control which users are allowed to read
and write process dumps there.
Note that to take a process dump when the image is installed with
elevated privileges or belongs to a protected subsystem, the user
must hold CMKRNL privilege, and is by definition a privileged
user (see Privileged Users).
4.12 - RMS Locking Enhancements
This section introduces the new Record Management Services (RMS)
enhancements provided in this release.
4. 12.1 - RMS Locking Performance (Alpha)
The following sections describe RMS locking performance
enhancements that are in OpenVMS Alpha Version 7.2-1H1 and in
OpenVMS Version 7.3.
4. 12. 1.1 - RMS Global Buffer Read-Mode Locking
In the RMS run-time processing environment, the use of global
buffers can minimize I/O operations for shared files. This release
introduces read-mode bucket locking that minimizes locking for
shared access to global buffers. This new functionality:
o Allows concurrent read access to the global buffers. Accesses
are no longer serialized, waiting to acquire an exclusive lock
for a read access.
o Caches the read-mode lock as a system lock, which is retained
over accesses and only lowered to null when the lock is
blocking an exclusive write request. This functionality
significantly reduces both local and remote lock request
traffic (the number of $ENQ and $DEQ system service calls)
as well as associated IPL-8 spinlock activity and System
Communications Services (SCS) messages for a cluster.
o Does not increase lock resource names or the number of active
system or process locks on the system.
o Is functionally compatible in mixed version clusters that
include both Alpha and VAX computers.
This new functionality applies to read operations (using the $GET
and $FIND services) for all three file organizations: sequential,
relative, and indexed. It also applies to a write operation
(using the $PUT service) for the read accesses used for index
buckets the first time through an index tree for the write.
You do not need to make changes to existing applications to
implement the read-only global bucket locks. However, global
buffers must be set on a data file to take advantage of the
enhancement. Use the following DCL command, where n is the number
of buffers:
$ SET FILE/GLOBAL_BUFFER=n <filename>
For information about specifying the number of buffers, refer
to the OpenVMS DCL Dictionary. For general information about
using global buffers, refer to the section entitled Using
Global Buffers for Shared Files in the Guide to OpenVMS File
Applications.
In a mixed cluster environment where there may be high contention
for specific buckets, the Alpha nodes that are using read-mode
global bucket locking may dominate accesses to write-shared
files, thereby preventing timely access by other nodes.
With the new /CONTENTION_POLICY=keyword qualifier to the SET RMS_
DEFAULT command, you can specify the level of locking fairness at
the process or system level for environments that experience high
contention conditions.
For more information about using the /CONTENTION_POLICY=keyword
qualifier, refer to the SET RMS_DEFAULT section of the OpenVMS
DCL Dictionary.
4. 12. 1.2 - No Query Record Locking Option
This release introduces new functionality that can minimize
record locking for read accesses to shared files, thereby
avoiding the processing associated with record locking calls
to the Lock Manager.
In previous releases, if a file is opened allowing write sharing,
an exclusive record lock is taken out for all record operations
(both read and write). Applications may obtain record locking
modes other than the exclusive lock (default) by specifying
certain options to the RAB$L_ROP field. However, all the options
involve some level of record locking. That is, the options
require $ENQ or $DEQ system service calls to the Lock Manager.
The user record locking options include the RAB$V_NLK (no lock)
query locking option, which requests that RMS take out a lock
to probe for status and not hold the lock for synchronization.
If the lock is not granted (exclusive lock held) and the read-
regardless (RAB$V_RRL) option is not set, the record access fails
with an RMS$_RLK status. Otherwise, the record is returned with
one of the following statuses:
o RMS$_SUC - No other writers
o RMS$_OK_RLK - Record can be read but not written
o RMS$_OK_RRL - Exclusive lock is held (lock request denied) but
the read-regardless (RAB$V_RRL) option is set
When only the RAB$V_NLK option is specified, record access can
be denied. When both the RAB$V_NLK and RAB$V_RRL options are
specified, an application can guarantee the return of any record
with a success or alternate success status.
This release introduces the no query record locking option,
which allows applications to read records (using $GET or $FIND
services) without any consideration of record locking. This
option:
o Does not make a call to the Lock Manager
o Is equivalent to both RAB$V_NLK and RAB$V_RRL being set
except that the RMS$_OK_RLK or RMS$_OK_RRL status will not
be returned
This functionality is independent of bucket locks. It applies to
both local and global buffers and to all three file organizations
(sequential, relative, and indexed).
Three alternate methods for specifying the no query record
locking option are outlined in Methods Available for Specifying
No Query Record Locking.
Note the following:
o The first method allows the option to be enabled externally,
potentially without any application change.
o You should use any of the methods only as appropriate for
the application. In particular, you should check for any
dependency in an existing application on the alternate success
status RMS$_OK_RLK or RMS$_OK_RRL.
Table 5-2 Methods Available for Specifying No Query Record
Locking
To... Use This Method...
Disable query record Enter the following DCL command to request
locking at the that RMS use no query record locking for
process or system any read operation with both RAB$V_NLK
level. and RAB$V_RRL options set in the RAB$L_ROP
field:
$ SET RMS_DEFAULT/QUERY_LOCK=
DISABLE[/SYSTEM]
Keys on RAB$V_NLK and RAB$V_RRL options in
existing applications.
Enable no query Set the RAB$V_NQL option in the RAB$W_ROP_
record locking on 2 field.
a per-record read
operation. The RAB$V_NQL option takes precedence
over all other record locking options. Use
only if the current read ($GET or $FIND)
operation is not followed by an $UPDATE or
$DELETE call.
Enable no query Set the FAB$V_NQL option in the FAB$B_SHR
record locking at field to request that RMS use no query
the file level. locking for the entire period the file is
open for any read record operation with
both RAB$V_NLK and RAB$V_RRL options set
in the RAB$L_ROP field.
This option can be used with any
combination of the other available FAB$B_
SHR sharing options. Keys on RAB$V_NLK and
RAB$V_RRL options in applications.
RMS precedence for the no query record locking option is as
follows:
o The RAB$V_NQL option set in the RAB$W_ROP_2 field
o At file open (and applied, if RAB$V_NLK and RAB$V_RRL are set
for the read operation):
- The FAB$V_NQL option set in the FAB$B_SHR field
- The SET RMS_DEFAULT/QUERY_LOCK=DISABLE setting at the
process level
- The SET RMS_DEFAULT/QUERY_LOCK=DISABLE setting at the
system level. If the process /QUERY_LOCK setting equals
SYSTEM_DEFAULT (the default when the process is created),
RMS uses the system specified value.
For more information, see OpenVMS Record Management Services
Reference Manual.
4. 12.2 - Record Locking Options
RMS uses the distributed Lock Manager ($ENQ system service) for
record locking.
To help prevent false deadlocks, the distributed Lock Manager
uses the following flags for lock requests:
Flag Purpose
LCK$M_ When set, the lock management services do not
NODLCKWT consider this lock when trying to detect deadlock
conditions.
LCK$M_ When set, the lock management services do not
NODLCKBLK consider this lock as blocking other locks when
trying to detect deadlock conditions.
In previous releases, RMS did not set these flags in its record
lock requests.
With this release, you can optionally request that RMS set
these flags in record lock requests by setting the corresponding
options RAB$V_NODLCKWT and RAB$V_NODLCKBLK in the new RAB$W_ROP_2
field. For more information about using these options, refer to
the flag information in the $ENQ section of the OpenVMS System
Services Reference Manual: A-GETUAI.
4.13 - OpenVMS Registry
Beginning in OpenVMS Version 7.3, the $REGISTRY system service
and the OpenVMS Registry server have been enhanced to use the
Intra-Cluster Communications (ICC) protocol. ICC provides a
high-performance communication mechanism that is ideal for large
transfers. Using ICC eases restrictions on the amount of data
that can be transferred between the $REGISTRY system service
and the Registry server. These restrictions previously prevented
large key values from being stored and retrieved, and prevented
full searches of large databases. The changes made in OpenVMS
Version 7.3 result in an incompatibility between the OpenVMS
Version 7.2 $REGISTRY service and Registry server and the OpenVMS
Version 7.3 $REGISTRY service and Registry server. However, these
changes substantially benefit OpenVMS customers in this release
and in future releases, when we plan to further reduce these
restrictions.
Also in OpenVMS Version 7.3, registry operations are
client/server based, and as such require some length of time
for the server to respond to a request. If the server is too
busy or the timeout value is too small, or both, the server
will not respond in time and the $REGISTRY service will return
a REG$_NORESPONSE error. This does not necessarily mean that
the operation failed; it only means that the server was not able
to respond before the time expired. Most operations complete
immediately. However, Compaq recommends that you specify the
timeout value be a minimum of 5 seconds.
The new format of the $registry system service is:
$REGISTRY [efn], func, [ntcredentials], itmlst, [iosb] [,astadr]
[,astprm] [,timeout]
Note that astadr, astprm and timeout are optional arguments.
These optional arguments cannot be defaulted, which means that to
specify the timeout argument, you must specify astadr and astprm
(or specify them as 0). Some languages, such as Bliss and Macro,
provide macros to do this for you.
4. 13.1 - REG$CP Registry Utility
The REG$CP Registry Utility has been enhanced to use the timeout
argument. REG$CP commands now support a /WAIT=numberofseconds
qualifier, allowing you to specify the number of seconds to
wait for the Registry Server to respond to the command. /WAIT is
negatable (by using /NOWAIT). However, like the timeout argument,
Compaq recommends that you specify a minimum of 5 seconds.
The REG$CP Registry Utility has also been enhanced to display
security descriptors. The LIST command can now be used to display
the security descriptor associated with a particular key. This
includes the security descriptor structure itself, and may also
include Security Identifiers (SIDs), System Access-Control Lists
(SACLs), and Discretionary Access-Control Lists (DACLs). You
must have access to the key to display the security descriptor;
in other words, you must have proper credentials to read the
security information, or you must be suitably privileged.
For more information, refer to the OpenVMS Connectivity Developer
Guide, which is available on the OpenVMS Alpha CD-ROM in
directory [COM_ALPHA_011A].
4.14 - Alpha SDA Commands, Parameters, and Qualifiers
The OpenVMS Version 7.3 software release offers a number of new
Alpha SDA commands, parameters, and qualifiers. OpenVMS Version
7.3 also offers many new parameters and qualifiers for existing
commands.
For more detailed information, refer to the OpenVMS Alpha System
Analysis Tools Manual.
4. 14.1 - New Alpha SDA Commands
The following section lists and defines the new System Dump
Analyzer commands with their parameters and qualifiers.
4. 14. 1.1 - DUMP
The DUMP command displays the contents of a range of memory
formatted as a comma-separated variable (CSV) list, suitable
for inclusion in a spreadsheet.
The following table shows the parameter for the DUMP command:
Parameter Meaning
range The range of locations to be displayed. The
range is specified in one of the following
formats: Meaning
m:n Range from address m to address n
inclusive
m;n Range from address m for n bytes
The following table shows the qualifiers for the DUMP command:
Qualifier Meaning
/COUNT=[{ALL|records}] Gives the number of records to be
displayed. The default is to display
all records.
/DECIMAL Outputs data as decimal values.
/FORWARD Causes SDA to display the records
in the history buffer in ascending
address order. This is the default.
/HEXADECIMAL Outputs data as hexadecimal values.
This is the default.
/INDEX_ARRAY [={LONGWORD Indicates to SDA that the range
(default)|QUADWORD}] of addresses given is a vector
of pointers to the records to be
displayed. The vector can be a
list of longwords (default) or
quadwords. The size of the range
must be an exact number of longwords
or quadwords as appropriate.
/INITIAL_POSITION Indicates to SDA which record is
is the lowest addressed record if
/FORWARD is used, and the highest
addressed record if /REVERSE is used.
The initial position may be given as
a record number within the range, or
the address at which the record is
located.
/LONGWORD Outputs each data item as a longword.
This is the default.
/PHYSICAL Indicates to SDA that all addresses
(range and/or start position) are
physical addresses. By default,
virtual addresses are assumed.
/QUADWORD Outputs each data item as a quadword.
/RECORD_SIZE=size Indicates the size of each record
within the history buffer, the
default being 512 bytes. Note that
this size must exactly divide into
the total size of the address range
to be displayed, unless /INDEX_ARRAY
is specified.
/REVERSE Causes SDA to display the records
in the history buffer in descending
address order.
4. 14. 1.2 - SET_SYMBOLIZE
The SET SYMBOLIZE command enables or disables symbolization of
addresses in the display from an EXAMINE command.
The following shows the parameters for the SET SYMBOLIZE command:
Parameter Meaning
ON Enables symbolization of addresses
OFF Disables symbolization of addresses
There are no qualifiers for this command.
4. 14. 1.3 - SHOW_MEMORY
The SHOW MEMORY command displays the availability and usage of
those memory resources that are related to memory.
There are no parameters for this command. The following shows the
qualifiers for the SHOW MEMORY command, which are the same as for
the existing DCL command:
Qualifier Meaning
/ALL Displays all available information;
that is, information displayed by the
/FILES, /PHYSICAL_PAGES, /POOL, and /SLOTS
qualifiers. This is the default display.
/BUFFER_OBJECTS Displays information about system resources
used by buffer objects.
/CACHE Displays information about the Virtual
I/O Cache facility. The cache facility
information is displayed as part of the SHOW
MEMORY and SHOW MEMORY/CACHE/FULL commands.
/FILES Displays information about the use of
each paging and swapping file currently
installed.
/FULL Displays additional information about
each pool area or paging or swapping
file currently installed, when used with
the /POOL or the /FILES qualifier. This
qualifier is ignored unless the /FILES or
the /POOL qualifier is specified explicitly.
When used with the /CACHE qualifier, /FULL
displays additional information about the
use of the Virtual I/O Cache facility.
/GH_REGIONS Displays information about the granularity
hint regions (GHR) that have been
established. For each of these regions,
information is displayed about the size of
the region, the amount of free memory, the
amount of memory in use, and the amount of
memory released to OpenVMS from the region.
The granularity hint regions information is
also displayed as part of SHOW MEMORY, SHOW
MEMORY/ALL, and SHOW MEMORY/FULL commands.
/PHYSICAL_PAGES Displays information about the amount of
physical memory and the number of free and
modified pages.
/POOL Displays information about the usage of each
dynamic memory (pool) area, including the
amount of free space and the size of the
largest contiguous block in each area.
/RESERVED Displays information about memory
reservations.
/SLOTS Displays information about the availability
of partition control block (PCB) vector
slots and balance slots.
4. 14. 1.4 - SHOW_RAD
The SHOW RAD command displays the settings and explanations of
the RAD_SUPPORT system parameter fields, and the assignment
of CPUs and memory to the Resource Affinity Domains (RADs).
This command is only useful on platforms that support RADs. By
default, the SHOW RAD command displays the settings of the RAD_
SUPPORT system parameter fields.
The following shows the parameter for the SHOW RAD command:
Parameter Meaning
number Displays information on CPUs and memory for the
specified RAD
The following shows the qualifier for the SHOW RAD command:
Qualifier Meaning
/ALL Displays settings of the RAD_SUPPORT parameter fields
and the CPU and memory assignments for all RADs
4. 14. 1.5 - SHOW_TQE
The SHOW TQE command displays the entries in the Timer Queue. The
default output is a summary display of all timer queue entries
(TQEs) in chronological order.
There are no parameters for this command. The following shows the
qualifiers for the SHOW TQE command:
Qualifier Meaning
/ADDRESS=n Outputs a detailed display of the TQE at the
specified address
/ALL Outputs a detailed display of all TQEs
/BACKLINK Outputs the display of TQEs, either detailed
(/ALL) or brief (default), in reverse order,
starting at the entry furthest into the future
/PID=n Limits the display of the TQEs that affect the
process with the specified internal PID
/ROUTINE=n Limits the display of the TQEs for which the
specified address is the fork PC
4. 14. 1.6 - UNDEFINE
The UNDEFINE command causes SDA to remove the specified symbol
from its symbol table.
The following shows the parameter for the UNDEFINE command:
Parameter Meaning
symbol The name of the symbol to be deleted from SDA's
symbol table. A symbol name is required.
There are no qualifiers for this command.
4. 14.2 - Parameters and Qualifiers for Existing Commands
The following section lists and defines new parameters and
qualifiers for existing commands.
4. 14. 2.1 - REPEAT
The REPEAT command has the following new parameter:
Parameter Meaning
count The number of times the previous command is to
be repeated. The default is a single repeat.
The REPEAT command has the following new qualifier:
Qualifier Meaning
/UNTIL=condition Defines a condition that terminates the REPEAT
command. By default, there is no terminating
condition.
4. 14. 2.2 - SEARCH
The /STEPS qualifier of the SEARCH command now allows any step
size. In addition to the keywords QUADWORD, LONGWORD (default),
WORD, or BYTE, any value can be specified.
Qualifier Meaning
/STEPS={QUADWORD|LONGWORD|WORD Specifies the step factor of
|BYTE|value} the search through the specified
memory range. After the SEARCH
command has performed the
comparison between the value of
expression and memory location,
it adds the specified step factor
to the address of the memory
location. The resulting location
is the next location to undergo
the comparison. If you do not
specify the /STEPS qualifier, the
SEARCH command uses a step factor
of a longword.
4. 14. 2.3 - SET_OUTPUT
The SET OUTPUT command has the following new qualifiers:
Qualifier Meaning
/[NO]HEADER The /HEADER qualifier causes SDA to include a
heading at the top of each page of the output
file. This is the default. The /NOHEADER
qualifier causes SDA to omit the page headings.
Use of /NOHEADER implies /NOINDEX.
/SINGLE_ Indicates to SDA that the output for a single
COMMAND command is to be written to the specified file
and that subsequent output should be written to
the terminal.
4. 14. 2.4 - SET_PROCESS
The SET PROCESS command has the following new qualifier:
Qualifier Meaning
/NEXT Causes SDA to locate the next valid process in the
process list and select that process. If there are
no further valid processes in the process list, SDA
returns an error.
4. 14. 2.5 - SHOW_DEVICE
The SHOW DEVICE command has the following new qualifiers:
Qualifier Meaning
/CDT=address Identifies the device by the address of its
Connector Descriptor Table (CDT). This applies
to cluster port devices only.
/PDT Displays the Memory Channel Port Descriptor Table.
This qualifier is ignored for devices other than
memory channel.
/UCB=ucb- This is a synonym for /ADDRESS=ucb-address.
address
4. 14. 2.6 - SHOW_GCT
The SHOW GCT command has the following new qualifier:
Qualifier Meaning
/CHILDREN When used with /ADDRESS=n or /HANDLE=n, the
/CHILDREN qualifier causes SDA to display all nodes
in the configuration tree that are children of the
specified node.
4. 14. 2.7 - SHOW_LOCK
The SHOW LOCK command's qualifier /STATUS has the following new
keyword:
Keyword Meaning
DPC Indicates a delete pending cache lock
4. 14. 2.8 - SHOW_PFN_DATA
The SHOW PFN_DATA command has the following new qualifier:
Qualifier Meaning
/RAD Displays data on the disposition of pages among
[={n|ALL}] the Resource Affinity Domain on applicable
systems
4. 14. 2.9 - SHOW_POOL
The SHOW POOL command has the following new qualifiers:
Qualifier Meaning
/BRIEF Displays only general information about pool
and its addresses.
/CHECK Checks all free packets for POOLCHECK-style
corruption, in exactly the same way that
the system does when generating a POOLCHECK
crashdump.
/MAXIMUM_BYTES Displays only the first n bytes of a pool
[=n] packet; default is 64 bytes.
/STATISTICS [= Displays usage statistics about each lookaside
ALL] list and the variable free list. For each
lookaside list, its queue header address,
packet size, the number of packets, attempts,
fails, and deallocations are displayed. (If
pool checking is disabled, the attempts,
fails, and deallocations are not displayed.)
For the variable free list, its queue header
address, the number of packets and the
size of the smallest and largest packets
are displayed. /STATISTICS can be further
qualified by using either /NONPAGED, /BAP, or
/PAGED to display statistics for a specified
pool area. (Note that for paged pool, only
variable free list statistics are displayed.)
If /STATISTICS is specified without the ALL
keyword, only active lookaside lists are
displayed. Use /STATISTICS = ALL to display
all lookaside lists.
/UNUSED Displays only variable free packets and
lookaside list packets, not used packets.
4. 14. 2.10 - SHOW_PROCESS
The SHOW PROCESS command has the following new qualifiers:
Qualifier Meaning
/FID_ONLY When used with /CHANNEL or /PROCESS_SECTION_
TABLE (/PST), the /FID_ONLY qualifier causes
SDA to not attempt to translate the FID
(File ID) to a file name when invoked with
ANALYZE/SYSTEM.
/GSTX=index When used with the /PAGE_TABLES qualifier, it
causes SDA to only display page table entries
for the specific global section.
/IMAGES [= ALL] By default, /IMAGES now only displays the
address of the image control block, the start
and end addresses of the image, the activation
code, the protected and shareable flags, the
image name, and the major and minor IDs of the
image. If /IMAGES = ALL qualifier is used, it
also displays the base, end, image offset, and
section type for installed resident images in
use by this process.
/NEXT Causes SDA to locate the next valid process
in the process list and select that process.
It there are no further valid processes in the
process list, SDA returns an error.
/PST This is a synonym for /PROCESS_SECTION_TABLE.
4. 14. 2.11 - SHOW_RESOURCE
The SHOW RESOURCE command has the following new qualifier:
Qualifier Meaning
/OWNED Causes SDA to only display owned resources
4. 14. 2.12 - SHOW_SPINLOCKS
The SHOW SPINLOCKS command has the following new qualifier:
Qualifier Meaning
/COUNTS Produces a display of Acquire, Spin, and Wait
counts for each spinlock
4. 14. 2.13 - SHOW_SUMMARY
The SHOW SUMMARY command has the following new qualifier:
Qualifier Meaning
/PROCESS_ Displays only processes with the specified
NAME=process_name process name. Wildcards can be used in
process_name, in which case SDA displays
all matching processes. The default
action is for SDA to display data for all
processes, regardless of process name.
4.15 - SDA Commands for Spinlock Tracing
The OpenVMS Version 7.3 software release includes the new
Spinlock Tracing utility. With the implementation of this
utility, you can now tell which spinlock is heavily used, and who
is acquiring and releasing the contended spinlocks. The Spinlock
Tracing utility allows a characterization of spinlock usage, as
well as collection of performance data for a given spinlock on
a per-CPU basis. The tracing ability can be enabled or disabled
while the system is running, allowing the collection of spinlock
data for a given period of time without system interruption.
To use the Spinlock Tracing utility, SDA has implemented new
commands and qualifiers. These SDA commands and qualifiers are
described as follows:
4. 15.1 - SPL_LOAD
This command loads the SPL$DEBUG execlet. This must be done prior
to starting spinlock tracing. It has no qualifiers.
4. 15.2 - SPL_SHOW_COLLECT
This command displays the data collected for a specific spinlock.
It has no qualifiers.
4. 15.3 - SPL_SHOW_TRACE
This command displays spinlock tracing information. Qualifiers
for the SPL SHOW TRACE Command shows the qualifiers for this
command.
Table 5-3 Qualifiers for the SPL SHOW TRACE Command
Qualifier Meaning
/SPINLOCK=spinlock Specifies the display of a specific
spinlock, for example, /SPINLOCK=LCKMGR or
/SPINLOCK=SCHED.
/NOSPINLOCK Specifies that no spinlock trace information
be displayed. If omitted, all spinlock trace
entries are decoded and displayed.
/FORKLOCK=forklock Specifies the display of a specific
forklock, for example, /FORKLOCK=IOLOCK8 or
/FORKLOCK=IPL8.
/NOFORKLOCK Specifies that no forklock trace information
be displayed. If omitted, all fork trace
entries are decoded and displayed.
/ACQUIRE Displays any spinlock acquisitions.
/NOACQUIRE Ignores any spinlock acquisitions.
/RELEASE Displays any spinlock releases.
/NORELEASE Ignores any spinlock releases.
/WAIT Displays any spinwait operations.
/NOWAIT Ignores any spinwait operations.
/FRKDSPTH Displays all invocations of fork routines
within the fork dispatcher. This is the
default.
/NOFRKDSPTH Ignores all of the operations of the /FRKDSPTH
qualifier.
/FRKEND Displays all returns from fork routines within
the fork dispatcher. This is the default.
/NOFRKEND Ignores all operations of the /FRKEND
qualifier.
/SUMMARY Stops the entire trace buffer and displays a
summary of all spinlock and forklock activity.
It also displays the top ten callers.
/CPU=n Specifies the display of information for a
specific CPU only, for example, /CPU=5 or
/CPU=PRIMARY. By default, all trace entries
for all CPUs are displayed.
/TOP=n Displays a different number other than the
top ten callers or fork PC. By default, the
top ten are displayed. This qualifier is only
useful when you also specify the /SUMMARY
qualifier.
4. 15.4 - SPL_START_COLLECT
This command accumulates information for a specific spinlock.
Qualifiers for the SPL START COLLECT Command shows the qualifiers
for this command:
Table 5-4 Qualifiers for the SPL START COLLECT Command
Qualifier Meaning
/SPINLOCK=spinlock Specifies the tracing of a specific
spinlock, for example, /SPINLOCK=LCKMGR or
/SPINLOCK=SCHED
/ADDRESS=n Specifies the tracing of a specific spinlock
by address
4. 15.5 - SPL_START_TRACE
This command enables spinlock tracing. Qualifiers for the SPL
START TRACE Command shows the qualifiers for this command.
Table 5-5 Qualifiers for the SPL START TRACE Command
Qualifier Meaning
/SPINLOCK=spinlock Specifies the tracing of a specific spinlock.
/NOSPINLOCK Disables spinlock tracing and does not collect
any spinlock data. If omitted, all spinlocks
are traced.
/FORKLOCK=forklock Specifies the tracing of a specific
forklock, for example, /FORKLOCK=IOLOCK8 or
/FORKLOCK=IPL8.
/NOFORKLOCK Disables forklock tracing and does not collect
any forklock data. If omitted, all forks are
traced.
/BUFFER=pages Specifies the size of the trace buffer (in
Alpha page units). It defaults to 128 pages,
which is equivalent to 1MB, if omitted.
/ACQUIRE Traces any spinlock acquisitions. This is the
default.
/NOACQUIRE Ignores any spinlock acquisitions.
/RELEASE Traces any spinlock releases. This is the
default.
/NORELEASE Ignores any spinlock releases.
/WAIT Traces any spinwait operations. This is the
default.
/NOWAIT Ignores any spinwait operations.
/FRKDSPTH Traces all invocations of fork routines within
the fork dispatcher. This is the default.
/NOFRKDSPTH Ignores all of the /FRKDSPTH operations.
/FRKEND Traces all returns from fork routines within
the fork dispatcher. This is the default.
/NOFRKEND Ignores all of the operations of the /FRKEND
qualifier.
/CPU=n Specifies the tracing of a specific CPU
only, for example, /CPU=5 or /CPU=PRIMARY.
By default, all CPUs are traced.
4. 15.6 - SPL_STOP_COLLECT
This command stops the spinlock collection, but does not stop
spinlock tracing. It has no qualifiers.
4. 15.7 - SPL_STOP_TRACE
This command disables spinlock tracing, but it does not
deallocate the trace buffer. It has no qualifiers.
4. 15.8 - SPL_UNLOAD
This command unloads and cleans up the SPL$DEBUG execlet. Tracing
is automatically disabled and the trace buffer deallocated. It
has no qualifiers.
For more information, refer to the OpenVMS Alpha System Analysis
Tools Manual.
4.16 - System Services
The following table describes new and updated system services for
OpenVMS Version 7.3.
For additional information, refer to the OpenVMS System Services
Reference Manual.
System Service Documentation Update
$CHECK_PRIVILEGES The description of the 'prvadr' argument has
been updated.
$CLRAST This service has been documented for Version
7.3.
$DCLEXH The description has been updated, and a BASIC
example has been added.
$DELETE_INTRUSION This service has been updated in support of
Clusterwide Intrusion.
$DEVICE_PATH_SCAN This is a new service in support of
Multipath.
$DISMOU The following item codes have been added:
DMT$M_MINICOPY_REQUIRED, DMT$M_MINICOPY_
OPTIONAL, and DMT$M_FORCE.
$EXPREG The text for condition value, SS$_ILLPAGCNT,
has been updated.
$GETDVI The item codes, MT3_DENSITY and MT3_
SUPPORTED, have been added.
The item codes, DVI$_FC_NODE_NAME, DVI$_FC_
PORT_NAME, and DVI$_WWID, have been added.
The description for the DVI$_MOUNTCNT item
code has been updated.
$GETJPI The following item codes have been added:
JPI$_RMS_DFMBC, JPI$_RMS_DFMBFIDX, JPI$_
RMS_DFMBFREL, JPI$_RMS_DFMBFSDK, JPI$_RMS_
DFMBFSMT, JPI$_RMS_DFMBFSUR, JPI$_RMS_DFNBC,
JPI$_RMS_EXTEND_SIZE, JPI$_RMS_FILEPROT, and
JPI$_RMS_PROLOGUE.
The following item codes have been added for
Multithreads support: JPI$_INITIAL_THREAD_
PID, JPI$_KT_COUNT, JPI$_MULTITHREAD, and
JPI$_THREAD_INDEX.
The code example has been updated for VAX and
Alpha usage.
$GETRMI This is a new service in support of
Performance API.
$GETQUI The item code, QUI$V_JOB_REQUEUE, has been
added.
$GETSYI The item code, SYI$_SERIAL_NUMBER, has been
added.
$IO_PERFORM The 'porint' argument in the format section
has been changed to 'devdata, to match the C
prototype.
$MGBLSC The text for the 'inadr' argument has been
updated, and the SS$_INVARG condition value
has been added.
$MOUNT The following item codes have been added:
MNT$M_MINICOPY_OPTIONAL, MNT$M_MINICOPY_
REQUIRED, MNT$M_REQUIRE_MEMBERS, and MNT$M_
VERIFY_LABELS.
$PERSONA_QUERY Tables for Common, General, and NT item codes
have been added.
$PROCESS_SCAN The following item codes have been added for
Multithreads support: PSCAN$_KT_COUNT and
PSCAN$_MULTITHREAD.
$REGISTRY This service is now documented in the OpenVMS
System Services Reference Manual: GETUTC-Z
and online help.
$SCAN_INTRUSION This service has been updated in support of
Clusterwide Intrusion.
$SCHED The condition value, SS$_INCLASS, has been
added, and SS$_ILLSER has been deleted.
$SET_DEVICE This is a new service in support of
Multipath.
$SET_SECURITY The condition value, SS$_INVFILFOROP, has
been added.
$SET_SYSTEM_EVENT A new item code, SYSEVT$C_TDF_CHANGE, has
been added.
$SHOW_INTRUSION This service has been updated in support of
Clusterwide Intrusion.
$WAKE This service now accepts 64-bit addresses.
4.17 - TCPIP Files for SDA READ
Modules Containing Global Symbols and Data Structures Used by SDA
shows the TCP/IP files that contain global symbols for the VAX
and Alpha SDA READ commands.
Table 5-6 Modules Containing Global Symbols and Data Structures
Used by SDA
File Contents
TCPIP$NET_GLOBALS.STB Contains data structure definitions for
TCP/IP Internet driver, execlet, and ACP
data structures
TCPIP$NFS_GLOBALS.STB Contains data structure definitions for
TCP/IP NFS server
TCPIP$PROXY_ Contains data structure definitions for
GLOBALS.STB TCP/IP proxy execlet
TCPIP$PWIP_GLOBALS.STB Contains data structure definitions
for TCP/IP PWIP driver, and ACP data
structures
TCPIP$TN_GLOBALS.STB Contains data structure definitions for
TCP/IP TELNET/RLOGIN server driver data
structures
These files are only available if TCP/IP services has
been installed. They are found in SYS$SYSTEM, and are not
automatically read in when you issue a READ/EXEC command.
Modules Defining Global Locations Within the Executive Image
shows the TCP/IP files that define global locations within the
Executive Image for the VAX SDA command.
Table 5-7 Modules Defining Global Locations Within the Executive
Image
File Contents
TCPIP$BGDRIVER.STB TCP/IP Internet driver
TCPIP$INETACP.STB TCP/IP Internet ACP
TCPIP$INTERNET_ TCP/IP Internet execlet
SERVICES.STB
TCPIP$NFS_SERVICES.STB Symbols for the TCP/IP NFS server
TCPIP$PROXY_ Symbols for the TCP/IP proxy execlet
SERVICES.STB
TCPIP$PWIPACP.STB TCP/IP PWIP ACP
TCPIP$PWIPDRIVER.STB TCP/IP PWIP driver
TCPIP$TNDRIVER.STB TCP/IP TELNET/RLOGIN server driver
These files are only available if TCP/IP services has
been installed. They are found in SYS$SYSTEM, and are not
automatically read in when you issue a READ/EXEC command.
For more detailed information, refer to the OpenVMS VAX System
Dump Analyzer Utility Manual and the OpenVMS Alpha System
Analysis Tools Manual.
4.18 - Visual Threads Version 2.1 (Alpha)
Visual Threads is a unique tool that lets you debug and
analyze multithreaded applications. You can use Visual Threads
to automatically diagnose common problems associated with
multithreading including deadlock, mutex, and thread usage
errors. Also, you can use Visual Threads to monitor the thread-
related performance of an application, helping you to identify
bottlenecks or locking granularity problems. Visual Threads
helps you identify problem areas in an application even if the
application does not show specific symptoms.
Visual Threads includes the following features:
o Collects detailed information about significant thread-related
state changes ("events").
o Analyzes common threading problems automatically based on
predefined rules applied to the event stream.
o Rule customization for application-specific parameters and
actions.
o Automatic statistics gathering, by sampling the event stream.
o Categories of analysis: data protection errors (race
conditions), deadlocks, programming errors, lock activity,
performance.
o Graphical visualization of the frequency of thread-related
events and thread state, snapshots of historical program
state, and object-specific graphs for each collected
statistic.
o Lock activity profiling to reveal where various types of lock
activity are occurring in your application, including: Number
of Locks, Contended Locks, Locked Time, and Wait Time. Lock
activity is collected and displayed for individual locks.
o Summarizes the program run and provides reports.
o Threads Snapshot view displays the historical state of threads
represented at specific times in the main thread overview
graph.
o Find and Filter support in the Event Window to allow you to
quickly locate particular events.
o CPU Utilization Window shows the CPU percentage used by each
thread.
o Thread Transitions Window depicts each state change for a
detailed view.
For more information about these features, refer to the Visual
Threads product documentation, which is available on the OpenVMS
Alpha CD-ROM in directory [VISUAL_THREADS_021], or by using the
online Help system.
| 5 - Associated Products Features |
This topic describes new features of Compaq OpenVMS operating
system associated products. For a listing and directory
information on the OpenVMS associated products, refer to the
Guide to OpenVMS Version 7.3 CD-ROMs.
5.1 - Availability Manager
OpenVMS Version 7.3 contains Availability Manager Version 1.4.
Soon after the release of OpenVMS Version 7.3, Availability
Manager Version 2.0 will be announced on the following
Availability Manager web site:
http://www.openvms.compaq.com/openvms/products/availman/
Version 2.0 will include the following new features:
o A new internal infrastructure supports new operating system
features more easily and quickly.
o To support NUMA or OpenVMS "RADs" and to provide preliminary
support for Wildfire/Galaxy, the following features have been
implemented:
- A new Memory view of OpenVMS Alpha V7.3 nodes displays
RAD-related data.
- When monitoring OpenVMS Alpha V7.3 nodes, Availability
Manager displays a new single-process memory tab called
"RAD Counters."
- The CPU modes display includes the RAD for a CPU.
- The CPU process list shows the home RAD for each process.
- The Node summary display now includes the number of
configured RADs, the system serial number, and the Galaxy
ID of a node, if any.
o Displays now include additional switched LAN and NISCA data,
when available.
o New user-defined event notifications have been implemented.
o A built-in browser now displays online help.
o A built-in Java runtime environment is now included. (In other
words, you no longer need to install Java on the system.)
o ODS-5 file system support has been added.
o A new PGFLQUOTA process-level "fix" has been implemented.
o A simpler mechanism for site-specific configuration setup now
exists.
5.2 - Compaq Advanced Server (Alpha)
The Compaq Advanced Server Version 7.3 for OpenVMS is supported
on Alpha systems only, and is the only version of the Advanced
Server for OpenVMS supported on OpenVMS Alpha Version 7.3. New
features include the following:
o Member server role (allowing the server to participate in
Windows 2000 native-mode domains)
o Greater compatibility with a wide variety of clients and
legacy applications, with support of:
- Extended character sets, in addition to Extended File
Specifications
- Alias file names, created for shared files whose names do
not comply with the more restricted file naming conventions
of legacy applications such as MS-DOS
o Remote Windows NT printer management (SpoolSS) for printers
shared on the Advanced Server for OpenVMS
o DNS for resolving NetBIOS names
o Cluster load balancing using DNS to resolve the server cluster
alias name
o PCSI for installing the server
o Windows 2000 client and domain support
Earlier versions of the Advanced Server for OpenVMS (Versions
7.2 and 7.2A) must be upgraded to Version 7.3 to run on OpenVMS
Alpha Version 7.3. Both the current and earlier versions of the
Advanced Server for OpenVMS also run on OpenVMS Alpha Version
7.2-1.
For information about installing Advanced Server for OpenVMS,
refer to the Compaq Advanced Server for OpenVMS Server
Installation and Configuration Guide provided with the kit
documentation.
To access Advanced Server V7.3 for OpenVMS on OpenVMS Alpha
Version 7.3, clients must be licensed using the new Advanced
Server V7.3 license PAK: PWLMXXXCA07.03. For more information,
refer to the Compaq Advanced Server for OpenVMS Guide to Managing
Advanced Server Licenses.
For information about the latest release of the PATHWORKS for
OpenVMS (Advanced Server) product, supported on both OpenVMS
Alpha and VAX Version 7.3 systems, see Compaq PATHWORKS V6.0D for
OpenVMS (Advanced Server).
5.3 - Compaq DECwindows Motif
The Compaq DECwindows Motif for OpenVMS (DECwindows Motif),
Version 1.2-6 kit for OpenVMS VAX and OpenVMS Alpha is now
available. DECwindows Motif, Version 1.2-6 is a maintenance
release that delivers a full range of changes and enhancements
to your desktop. From faster batch scrolling to support for
the Common Desktop Environment (CDE) screen saver and lock
extensions, these changes are intended to provide you with a
more efficient, flexible DECwindows Motif environment that is
more in line with the OSF/Motif, MIT X11 Release 5 (X11 R5), and
Common Desktop Environment (CDE) standards. For a full list of
specific changes, enhancements, and corrections implemented in
this release, refer to the Compaq DECwindows Motif for OpenVMS
Release Notes.
5.4 - Compaq DCE for OpenVMS
This section describes the enhancements in Compaq Distributed
Computing Environment (DCE) for OpenVMS Version 7.3.
5. 4.1 - Compaq DCE Remote Procedure Call (RPC)
Beginning with OpenVMS Version 7.2-1, the NT Lan Manager security
in DCE RPC is fully functional.
5. 4.2 - New Ethernet Device Support
If DCE RPC does not recognize the Ethernet device in your system,
one new device may be added to the table of known devices by
defining the system logical DCE$IEEE_802_DEVICE to be the device
name of your Ethernet device.
For example, to define a single DE500 Ethernet device, set the
logical as follows:
$ DEFINE/SYSTEM DCE$IEEE_802_DEVICE EWA0
5. 4.3 - For More DCE Information
Refer to the OpenVMS Version 7.3 Release Notes for important
information about Compaq DCE for OpenVMS.
If you have the full DCE kit installed, you can use online help
for additional information:
$ HELP DCE
$ HELP DCE$SETUP
$ HELP DCE_CDS
$ HELP DCE_DTS
$ HELP DCE_IDL
$ HELP DCE_RPC
$ HELP DCE_SECURITY
$ HELP DCE_THREADS
You can also refer to the following documentation:
o Compaq DCE for OpenVMS VAX and OpenVMS Alpha Installation and
Configuration Guide (order number AA-PV4CE-TE)
o Compaq DCE for OpenVMS VAX and OpenVMS Alpha Product Guide
(order number AA-PV4FE-TE)
o Compaq DCE for OpenVMS VAX and OpenVMS Alpha Reference Guide
(order number AA-QHLZB-TE)
5.5 - DECram (Alpha)
DECram Version 3.0 supports the OpenVMS for Alpha platform only.
The following are the new features that can be found in this
release:
o In DECram for OpenVMS Alpha Version 3.0, DECram's capability
supports the use of shared memory for creation of RAM disks in
an Adaptive Partitioned MultiProcessing (APMP) environment.
This environment is also know as Compaq Galaxy Software
Architecture.
o On OpenVMS Version 7.2-1H1 or higher, the limit on the DECram
file size has been extended to 4,294,967,296 blocks.
o DECram for OpenVMS Version 3.0 is fully compatible with
DECram Version 2.3. There can be any combination of these
two versions of DECRam in a VMScluster.
o Multiple DECram devices can be members of a Volume Shadowing
for OpenVMS shadow set and can be served by Mass Storage
Control Protocol (MSCP) or QIO served.
o Volume Shadowing for OpenVMS will support shadow sets composed
of DECram devices and other disk class devices.
o A new DECram command interface (DECRAM>) can be used for
creating, initializing, and mounting DECram disks.
DECram Version 3.0 and supporting documentation are included in
the OpenVMS Version 7.3 CD-ROM in the [.DECRAM_030] directory.
5.6 - Enterprise Capacity and Performance (ECP)
Beginning with OpenVMS Version 7.3, the following Enterprise
Capacity and Performance (ECP) management tools will be provided
at no additional costs. The ECP Data Collector for OpenVMS
and ECP Performance Analyzer for OpenVMS will be available to
customers who have a valid license to operate OpenVMS Version 6.2
or later. These products are available from the following World
Wide Web site:
http://www.openvms.compaq.com/openvms/system_management.html
Software Support Services for these products are sold separately
and are available on an incremental basis. Please contact your
Compaq Services representative for further details.
5. 6.1 - ECP Collector
ECP Collector for OpenVMS Version 5.4 gathers performance and
capacity planning data on OpenVMS operating systems. OpenVMS data
collection has three main criteria; the amount of performance
data collected, the time interval, and the efficiency or amount
of overhead impacting the system. ECP Collector for OpenVMS
provides the following:
o Robust data collection set. It collects system metrics on over
250 OpenVMS performance parameters.
o Flexible data collection. The sampling rate of data can be
tuned down to sub-second intervals.
o Low overhead. Audited production systems have routinely shown
that ECP Collector for OpenVMS has less than a 1.5% impact on
the CPU.
Satisfying the needs of Enterprise Management, ECP Collector for
OpenVMS also contains an API that provides an interface for the
access of performance data. This interface converts the contents
of the .CPC data file generated by the data collector into a
formatted, comma-separated ASCII file that can then be used for
performance analysis and reporting programs.
5. 6.2 - ECP Performance Analyzer
Compaq's ECP Analyzer for OpenVMS Version 5.4, which runs under
Motif, analyzes the data provided by the ECP Collector for
OpenVMS data collector. ECP Analyzer for OpenVMS provides the
entry point into the data collector, and allows the user to
select the sampling rate and to view the performance data in
graphical format. The product provides historical information in
standard graphs based upon the requested time interval. Graphs
are provided for all common performance issues that need to be
analyzed including the CPU, the memory, and the I/O. ECP Analyzer
for OpenVMS provides both graphic (MOTIF-based) and tabular
reports for the data.
5.7 - Kerberos for OpenVMS
Kerberos Version 1.0 for OpenVMS Alpha and OpenVMS VAX, based on
MIT Kerberos Version 5 Release 1.0.5, is included on the OpenVMS
Version 7.3 distribution media. (Kerberos documentation provided
by MIT is included on the OpenVMS documentation CD-ROM in HTML
format.)
Kerberos is a network authentication protocol designed to provide
strong authentication for client/server applications by using
secret-key cryptography.
Kerberos was created by the Massachusetts Institute of Technology
as a solution to network security problems. The Kerberos
protocol uses strong cryptography so that a client can prove its
identity to a server (and vice versa) across an insecure network
connection. After a client and server have used Kerberos to prove
their identity, they can also encrypt all of their communications
to assure privacy and data integrity.
General information about Kerberos is available from the
following World Wide Web address:
http://web.mit.edu/kerberos/www/
5. 7.1 - New DCL Command KERBEROS
OpenVMS Kerberos is an authentication security product. It
allows for user authentication for a wide range of communication
programs such as RLOGIN, TELNET, and FTP.
Format:
KERBEROS [/ADMIN | /USER]
[/INTERFACE=[DECWINDOWS | CHARACTER_CELL]]
Qualifiers:
/ADMIN
Activates the Kerberos administration utility for the selected
interface.
/USER (default)
Activates the Kerberos user utility for the selected interface.
/INTERFACE=CHARACTER_CELL (default)
/INTERFACE=DECWINDOWS
Activates the display device requested, if available.
For more information, refer to the Kerberos for OpenVMS
Installation Guide and Release Notes.
5.8 - Universal LDAPv3 API (Alpha)
OpenVMS Version 7.3 includes the Lightweight Directory Access
Protocol (LDAPv3) Application Programming Interface (API) that
allows OpenVMS application developers, third-party applications,
and users to access LDAP directories anywhere in the enterprise,
intranet, extranet or Internet hosted by non-OpenVMS systems.
The multi-threaded API will automatically support both 64-bit and
32-bit applications and be Common Object Model (COM) aware.
The universal LDAPv3 API is certified with Microsoft's Active
Directory, Novell's NDS and Compaq's X.500 Version 4.0, and
supports various security mechanisms including Kerberos V5 and
Public Key Infrastructure (PKI).
The LDAPv3 kits are available from the following World Wide Web
address:
http://www.openvms.compaq.com/openvms/products/mgmt_agents/index.html
For additional information on the LDAPv3 API, refer to the
OpenVMS Utility Routines Manual.
5.9 - Compaq PATHWORKS V6.0D for OpenVMS (Advanced Server)
Compaq PATHWORKS V6.0D for OpenVMS (Advanced Server) is the only
PATHWORKS for OpenVMS server supported on OpenVMS Version 7.3
(in addition to Compaq Advanced Server V7.3 for OpenVMS). Earlier
versions of PATHWORKS for OpenVMS servers must be upgraded. For
more information, refer to the OpenVMS Version 7.3 Release Notes.
You can run PATHWORKS V6.0D for OpenVMS (Advanced Server) on
either OpenVMS Alpha Versions 7.3, 7.2-1, or 6.2, or on OpenVMS
VAX Versions 7.3, 7.2, or 6.2.
To access PATHWORKS V6.0D for OpenVMS (Advanced Server) on
OpenVMS Version 7.3, clients must be licensed using the license
PAK PWLMXXXCA06.00, PWLMXXXCA07.02, or PWLMXXXCA07.03. For more
information, refer to the Compaq Advanced Server for OpenVMS
Guide to Managing Advanced Server Licenses.
For information about the latest release of Compaq Advanced
Server Version 7.3 for OpenVMS see Compaq Advanced Server
(Alpha).
5.10 - Compaq Service Tools and DECevent
Compaq Services new web-based service tool functionality is
known as Web-Based Enterprise Services (WEBES). The Compaq System
Tools CD-ROM included in the OpenVMS Version 7.3 CD-ROM package
includes WEBES. (WEBES includes the Compaq Crash Analysis Tool
(CCAT) and Compaq Analyze components.) This is the supported
service tools for all AlphaServer DS, ES, and GS systems running
OpenVMS, except for the AlphaServer GS60 and AlphaServer GS140
platforms. The AlphaServer GS60 and GS140 platforms must continue
to use the DECevent diagnostic tool.
In addition to WEBES, the Compaq System Tools CD-ROM includes
DECevent, DSNLINK, and the Revision and Configuration Management
(RCM) tools.
DECevent and WEBES can be used together in a cluster.
Installation and documentation on the service tools are included
on the Compaq System Tools CD-ROM. Use the following web site to
access the most up-to-date service tool information:
http://www.support.compaq.com/svctools/
5.11 - TCPIP Services V5.1
The Compaq TCP/IP Services for OpenVMS product is the Compaq
implementation of the TCP/IP protocol suite and internet services
for OpenVMS Alpha and OpenVMS VAX systems.
TCP/IP Services provides a comprehensive suite of functions
and applications that support industry-standard protocols for
heterogeneous network communications and resource sharing.
5. 11.1 - New Features and Changes
The new features of Compaq TCP/IP Services for OpenVMS Version
5.1 include:
o A new kernel, based on Compaq Tru64 UNIX Version 5.1.
o Support for Internet Protocol Version 6 (IPv6).
o DHCP client support.
o Xterminal support using XDM.
o Services that can be restarted individually.
o GATED enhancements.
o BIND dynamic updates management enhancements.
o Cluster failover for the BIND server.
o Cluster failover for the load broker.
o Updated SNMP that supports AgentX.
o SMTP enhancements, including:
- AntiSPAM (configuration to control mail relay)
- SMTP SFF (Send From File)
- SMTP outbound alias
o Metric server logicals that can be changed without restarting
the Metric server.
o The DHCP server can be configured to dynamically update the
BIND database.
o TELNET client enhancements to support SNDLOC and NAWS.
o Support for the NFS V3 protocol in addition to the NFS V2
protocol in the NFS server.
o TCP options for improving certain performance characteristics.
For more information about configuring and managing these
services, refer to the Compaq TCP/IP Services for OpenVMS
Management guide provided with the TCP/IP Services for OpenVMS
Version 5.1 software.
5. 11.2 - Documentation
For installation instructions, refer to the Compaq TCP/IP
Services for OpenVMS Installation and Configuration manual.
The TCP/IP Services for OpenVMS Release Notes provide version-
specific information that supersedes the information in the
documentation set. The features, restrictions, and corrections in
this version of the software are described in the release notes.
Always read the release notes before installing the software.
The TCP/IP Services for OpenVMS documentation set includes the
following new items:
o Compaq TCP/IP Services for OpenVMS Guide to IPv6
This manual describes the IPv6 environment, the roles of
systems in this environment, the types and function of the
different IPv6 addresses, and how to configure TCP/IP Services
to access the 6bone network.
o Compaq TCP/IP Services for OpenVMS Tuning and Troubleshooting
This manual provides information about how to isolate the
causes of network problems and how to tune the TCP/IP Services
software for the best performance.
o Compaq TCP/IP Services for OpenVMS Management Command Quick
Reference Card
This reference card summarizes the TCP/IP management commands,
organizing them by function and component.
o Compaq TCP/IP Services for OpenVMS UNIX Command Reference Card
This reference card describes how to use UNIX utilities on
OpenVMS to manage TCP/IP services.
The following existing TCP/IP Services for OpenVMS manuals have
been updated for V5.1:
o Compaq TCP/IP Services for OpenVMS Installation and
Configuration
o Compaq TCP/IP Services for OpenVMS Management
o Compaq TCP/IP Services for OpenVMS Management Command
Reference
o Compaq TCP/IP Services for OpenVMS Sockets API and System
Services Programming
o Compaq TCP/IP Services for OpenVMS SNMP Programming and
Reference
|
|
