Updated: 11 December 1998

OpenVMS Version 7.2
New Features Manual

The OpenVMS Debugger contains the following new features:

• Windows client/server interface
• Heap Analyzer displays 64-bit space (Alpha only)
• Support for C++ Version 5.5 and later (Alpha only)
• PTHREAD Command

The following sections describe these OpenVMS Debugger enhancements. For more detailed information, see the OpenVMS Debugger Manual.

4.14.1 Client/Server Interface

The OpenVMS Debugger Version 7.2 features a new client/server interface that allows you to use Windows-based client applications to debug programs that reside and run on OpenVMS VAX or Alpha systems.

The OpenVMS server provides a fully cached DCE-RPC interface that can support up to 32 simultaneous client connections. These connections can occur across mixed desktop platforms such as DECwindows Motif, Windows NT, and Windows 95. Typically, a single client/server connection is maintained; however, additional parallel connections can be initiated to support team debugging, remote support, or classroom training.

Client applications are available for DECwindows Motif, Microsoft Windows NT, and Windows 95 systems. These clients are capable of running remote debug sessions with OpenVMS servers over TCP/IP, DECnet, or UDP network transports. Each client can support simultaneous connections to an unlimited number of OpenVMS servers on both VAX and Alpha platforms.

All Windows clients are implemented with Microsoft Visual C++/MFC and include additional features such as access to web-based HTML documentation and user-definable buttons for accessing other desktop tools (including Telnet sessions for managing the servers).

The new client/server interface provides new flexibility for debugging OpenVMS applications. You can run several sessions simultaneously from a PC, share debugging context between several users on different PCs, and swap back and forth between different debugging sessions.

The new client/server environment supports the following types of configurations:

• One-to-One (one server; one client)
  A typical debugging configuration.
• One-to-Many (one client; multiple servers)
  This allows the client to switch between different sessions to debug related or interacting programs simultaneously.
• Many-to-One (multiple clients; one server)
  This allows several users to collectively debug a single program, or to use the session as a teaching tool.
• Many-to-Many (multiple clients; multiple servers)
  This allows many users to team debug multiple programs.

These different configurations can consist of any combination of OpenVMS VAX and Alpha servers and Windows clients (Intel and Alpha). In addition, DECwindows Motif clients can simultaneously access debugging sessions on these configurations.

4.14.2 Heap Analyzer Displays 64-Bit Space (Alpha Only)

The Heap Analyzer has been enhanced to display 64-bit address space when required. The Heap Analyzer also displays 64-bit addresses where appropriate, but uses 32-bit addressing when that is sufficient.

The Zoom pulldown menu has two new entries to help scale the view of the entire memory space used by programs that take advantage of 64-bit address space. These new entries are:

• Extremely Far
• Extraordinarily Far

A new pulldown menu, the View menu, contains entries for the views listed in the Views window. Entries include:

• All Views
• Images
• P0 Regions
• P2 Region (if accessed by a 64-bit system routine in the program being analyzed)
• Pxx Region (named virtual region created by $CREATE_REGION_64)

These new features of the Heap Analyzer makes it much easier to debug OpenVMS applications that use the 64-bit address space.

4.14.3 Support for C++ Version 5.5 and Later (Alpha Only)

OpenVMS Version 7.2 provides you with the ability to debug C++ programs with the OpenVMS Alpha debugger. Specifically, the OpenVMS Alpha debugger supports the following C++ features:

• C++ names and expressions, including:
  • Explicit and implicit this pointer to refer to class members
  • Scope resolution operator (::)
  • Member access operators: period (.) and right arrow (->)
  • Template instantiations
• Setting breakpoints in:
  • Member functions, including static and virtual functions
  • Overloaded functions
  • Constructors and destructors
  • Template instantiations
  • Operators
• Calling functions, including overloaded functions
• Debugging programs containing a mixture of C++ code and code in other languages

This new support enables you to use the OpenVMS debugger to debug OpenVMS Alpha applications written in DEC C++ Version 5.5 and later.

4.14.4 PTHREAD Command

When debugging programs that use DECthreads Version 3.13 or greater, you can directly access the DECthreads Debugger with the PTHREAD command.

The syntax of the PTHREAD command is

PTHREAD command

where command is a valid DECthreads Debugger command. The OpenVMS Debugger passes the command to the DECthreads Debugger for execution. You can get help on DECthreads debugger commands by typing PTHREAD HELP. For example:

DBG_1> PTHREAD HELP conditions [-afhwqrs] [-N <n>] [id]...: list condition variables exit: exit from DECthreads debugger help [topic]: display help information keys [-v] [-N <n>] [id]...: list keys mutexes [-afhilqrs] [-N <n>] [id]...: list mutexes quit: exit from DECthreads debugger show [-csuv]: show stuff squeue [-c <n>] [-fhq] [-t <t>] [a]: format queue stacks [-fs] [sp]...: list stacks system: show system information threads [-1] [-N <n>] [-abcdfhklmnor] [-s <v>] [-tz] [id]...: list threads tset [-chna] [-s <v>] <id>: set state of thread versions: display versions write <st>: write a string All keywords may be abbreviated: if the abbreviation is ambiguous, the first match will be used. For more help, type 'help <topic>'. DBG_1>

The PTHREAD command gives you direct access to the DECthreads Debugger within the context of a debugging session. This can provide much more information to help debug the application.

4.15 OpenVMS RTL Library (LIB$)

This section describes the RTL routine LIB$GET_LOGICAL.

4.15.1 LIB$GET_LOGICAL

LIB$GET_LOGICAL provides a simplified interface to the $TRNLNM system service. It provides most of the features found in $TRNLNM with some additional benefits. For string arguments, all string classes supported by the Run-Time Library are understood. The list of item descriptors, which may be difficult to construct in high-level languages, is handled internally by LIB$GET_LOGICAL.

See the OpenVMS RTL Library (LIB$) Manual for more information about routine LIB$GET_LOGICAL.

4.16 Record Management Services (RMS) Enhancements

The following sections describe the RMS enhancements included with the OpenVMS Version 7.2 release.

4.16.1 Coordinated Universal Time (UTC) Support

With OpenVMS Version 7.2, both RMS and the File Access Listener (FAL) have been enhanced to support the 128-bit Coordinated Universal Time (UTC) format for the exchange of date and time information about files (such as file creation or file revision).

With this enhancement, RMS and FAL support two formats for the exchange of file date and time information:

• New UTC format. This enhancement takes advantage of the DECnet Data Access Protocol (DAP) option for transferring times using the 128-bit UTC format. As of this version, this has been made the default for OpenVMS systems.
• Current 2-digit year format. A 2-digit year is used in the following 18-byte format in accordance with the DAP specification: DD-MON-YYHH:MM:SS

In previous versions of RMS and FAL, as part of their own implementation (not part of the DAP specification), the 2-digit year field pivoted about the year 1970. YYs from 70 to 99 map to 1970 through 1999; YYs from 00 to 69 map to 2000 through 2069. Thus, this scheme presents no Year 2000 problem for previous versions in the immediate future.

If the client requesting the file transfer in the system configuration message has set the system capability (SYSCAP) indicating "support for binary date/time format," OpenVMS will use the UTC format by default. And as of this version, it will be set for any OpenVMS client.

If the UTC capability is not set by a non OpenVMS client, then the current 2-digit year scheme will remain in effect. Note that the pivot around the 1970 year, implemented in the OpenVMS RMS and FAL code, is not part of the DAP specification; therefore, it cannot be presumed that either a pivot or a pivot around the specific year 1970 is implemented by non OpenVMS clients.

4.16.2 Support for New File Length Hint Attribute (Alpha Only)

RMS is now capable of storing, retrieving, and maintaining a file length hint. A file length hint is a pair of quadword integer fields (16 bytes) as follows:

1. Record count (bytes 0-7): the number of data records written to the file using record I/O ($PUT).
2. User data byte count (bytes 8-15): the total number of user data bytes in the file (excluding any overhead bytes added by RMS).

For sequential files with a record format of variable (VAR) or variable with fixed control (VFC) on an On-Disk Structure Level 5 (ODS-5) volume, RMS will maintain the file hint, provided:

• The file is written only using unshared RMS record I/O.
• The file does not have journaling enabled.

The XAB$_FILE_LENGTH_HINT item code may be used with an item list XAB on $OPEN or $DISPLAY operations to sense the file length hint values. A SETMODE may be used with a $CLOSE operation to set the file length hint counts. The SETMODE will override any counts that RMS may be concurrently maintaining.

The XAB$_FILE_LENGTH_HINT XABITM requires a 16-byte buffer for the two quadwords. These fields are maintained as a set: either both fields are valid or invalid.

The most significant (sign) bit of each quadword is used to indicate whether the associated count is valid. A sequential file with VAR or VFC format that is created on an ODS-5 volume, had any data added to it using RMS record I/O ($PUTs), and has met the conditions indicated above should have valid counts. If, however, at some point in time, some data are written to a file using RMS block I/O, for example, then the sign bits will be set on file deaccess to indicate the counts are invalid. The last count maintained in each field is retained as a hint of what its last valid value was, but the sign bit being set indicates it is stale.

If these fields have never been modified by RMS for a file on an ODS-5 volume, then the contents of each quadword will be 8 bytes of 0xFF. For example, after a file originally created and maintained on an On-Disk Structure Level 2 (ODS-2) volume is converted from ODS-2 format to ODS-5 format, these fields will contain 8 bytes of 0xFF.

The counts in these fields are invalidated if a truncate-on-put is done, except if the truncate is to zero.

If a SENSEMODE using this item code is requested for a non-ODS-5 file, the contents returned for each quadword will be 8 bytes of 0xFF. A SETMODE using this item code for a non-ODS-5 file will be ignored.

The file length hint is not supported for DECnet operations; it is ignored. If a SENSE is attempted, 8 bytes of 0xFF will be returned to the user buffer for each quadword.

4.16.3 New Qualifier for the Analyze/RMS_File Utility

With OpenVMS Version 7.2, the Analyze/RMS_File utility has a new qualifier /UPDATE_HEADER. The /UPDATE_HEADER qualifier attempts to update the following attributes in the header of the file: longest record length (LRL) and/or file length hint attribute. You must use this qualifier in combination with either /STATISTICS or /CHECK (the default). This qualifier only applies to sequential file organizations and is ignored for any other file organization.

For more detailed information, see the OpenVMS Record Management Utilities Reference Manual.

4.16.4 File User Characteristics Item for XAB (XABITM)

With OpenVMS Version 7.2, the file user characteristic item XAB$_UCHAR_PRESHELVED is available for use with the XAB (XABITM) item list of RMS. The XAB$_UCHAR_PRESHELVED item indicates that a file is shelved but also kept online.

For more detailed information, see the OpenVMS Record Management Services Reference Manual.

4.16.5 RMS Global Buffer Performance Enhancements

OpenVMS Version 7.2 includes two enhancements that improve RMS global buffer performance. The two enhancements are as follows:

• RMS implements a new algorithm for global buffer management that dramatically improves scalability. The performance associated with the previous algorithm effectively limited the maximum number of global buffers on large, shared files. With this change, you may increase the number of global buffers on these files to the full limit of 32,767 to fully exploit large memory systems.
• RMS now synchronizes access to the global section that is used for RMS global buffers by using inline atomic instruction sequences rather than distributive locking. This change allows more concurrent access to the section, particularly on symmetric multiprocessing machines (SMP).

The first change benefits those who wish to use very large global buffer counts. The second change helps any application using global buffers where contention on the global section itself is a bottleneck.

In OpenVMS Alpha Version 7.2, the scheduling algorithm for soft affinity has been improved. Soft affinity allows a kernel thread to be scheduled on the last processor on which it has run. This capability preserves its investment in the cache and translation buffers.

The new algorithm bases its decision on whether a soft affinity process should execute on the current CPU by collecting and using process scheduling data. The system collects more information about how processes are performing on each CPU by collecting the following data at each process priority level:

• Process runtime
• Process waittime (how long it waited on the COM queue before it was selected to run)
• Interrupt time incurred by the process

Soft affinity can be enabled in two ways:

• The $SET_IMPLICIT_AFFINITY system service enables soft affinity for a particular process or as the default for all future processes.
  The CAP$V_IMPLICIT_ALL_THREADS flag enables soft affinity for all kernel threads in a process.
• The new DCL command SET PROCESS/AFF=SOFT enables soft affinity for a process.

Prior to OpenVMS Alpha Version 7.2, the DCL command SET PROCESS/AFF/SET=1 enabled hard (or explicit) affinity for a process, but there was no DCL command that enabled soft affinity. As of OpenVMS Alpha Version 7.2, the qualifier /AFF has hard and soft values associated with it. If neither is specified, the default is hard, which preserves the previous behavior.

In OpenVMS Alpha Version 7.2, the DCL command SHOW PROCESS/ALL displays the soft affinity setting. This command displays the following new line:

Soft affinity: on

or if soft affinity is not enabled:

Soft affinity: off.

Two system parameters are associated with soft affinity:

• AFFINITY_SKIP
  In OpenVMS Alpha Version 7.2, AFFINITY_SKIP is obsolete.
• AFFINITY_TIME
  As of OpenVMS Alpha Version 7.2, AFFINITY_TIME specifies how long (in seconds) the number of voluntary waits a process has incurred should be counted before determining if the process is I/O bound or compute bound. The default value is 3 seconds.

This section contains information about security changes in OpenVMS Version 7.2.

4.18.1 Per Thread Security

This section discusses per-thread security, a new feature in OpenVMS Alpha Version 7.2.

Per-thread security permits each thread of execution within a multithreaded process to have an individual security profile. In OpenVMS Version 7.2, the impersonation system services and underlying system framework have been enhanced to support per-thread security profiles.

Security profile information previously contained in various process level data structures and data cells is now stored in a single data structure, the Persona Security Block (PSB), which is then bound to a thread of execution. All associated references within OpenVMS have been redirected accordingly. Every process in the system has at least one PSB that is the natural persona of the process. The natural persona is created during process creation.

Interaction between a thread manager (for example, the thread manager incorporated within DECthreads) and the security subsystem provides for the automatic switching of profiles as threads are scheduled for execution.

Refer to Appendix B, "Considerations for OpenVMS Systems" in the Guide to DECthreads for further information about threading capabilities available on OpenVMS systems.

4.18.1.1 Benefits

The primary consumer of per-thread security is a multithreaded server with threads that impersonate clients. These threads appear to the system as the clients in regard to audits, access checks, rights processing, and so on. This is a benefit to those writing a system level server application that processes requests on behalf of users. These applications can be coded using the DECthreads thread model and the system's built-in impersonation services to have the system automatically perform the security checking on behalf of the requesting client.

When kernel threads were implemented in the OpenVMS operating system, modifications to one thread's security information (privileges, rights, and identity information) could be inadvertently passed to another thread if the threads are scheduled on different processors simultaneously, as kernel threads are designed to do.

Per-thread security ensures that this security information is handled properly. Each user thread in a process has a fully separate security profile. When the user thread is scheduled, the security profile for that thread is automatically switched as well.

Refer to the OpenVMS Guide to System Security for more information about per-thread security.

4.18.2 Enhanced Persona Support

Previous versions of OpenVMS included system services that allowed a privileged OpenVMS process to create and use personae. These system services are as follows:

• $PERSONA_ASSUME
• $PERSONA_CREATE
• $PERSONA_DELETE

Enhancements and additions to these services are a new feature in OpenVMS Alpha Version 7.2. These enhancements support subject security credentials other than OpenVMS. Initially, Windows NT-style security credentials are supported.

4.18.2.1 New Persona System Services

The following new system services support persona lookup and retrieval and persona extensions. These system services are documented in OpenVMS System Services Reference Manual: GETQUI--Z. Refer to the OpenVMS Guide to System Security for additional information about these services.

• $PERSONA_CLONE
• $PERSONA_CREATE_EXTENSION
• $PERSONA_DELETE_EXTENSION
• $PERSONA_DELEGATE
• $PERSONA_EXTENSION_LOOKUP
• $PERSONA_FIND
• $PERSONA_MODIFY
• $PERSONA_QUERY
• $PERSONA_RESERVE

Using shared address data on OpenVMS Alpha systems improves performance at the following times:

• At run time, shared address data saves physical memory because of increased memory sharing between processes.
• At image activation, shared address data reduces CPU and I/O time because fixup is performed at installation time.

Related Terms

Explanations of terms related to shared address data follow.

• Image section
  An image consists of a number of image sections. An image section can contain:
  • Instructions (code)
  • Read-only data (constants)
  • Read/write data
• Shared known images
  You can make an image a shared known image by using the following command:

  $ INSTALL ADD image-name /SHARED

  
  When you enter this command, the Install utility creates global sections for read-only image sections, allowing the sections to be shared by all the processes that run the image.

• Address data
  One kind of image section contains address data. At execution time, address data sections are read-only. However, the addresses are not known until image activation; therefore, the image section is read/write until the end of image activation. Addresses for a shareable image generally vary with the process, because different processes are likely to have different collections of mapped images.
• Shared address data
  The shared address data feature assigns unique P1 space addresses for shareable images from the P1 image region. (The IMGREG_PAGES system parameter determines the size of the P1 space.) With the assigned address, the Install utility determines the content of an address data section when the image is installed. A global section is created to allow shared access to each address data image section.
  Executable (main) images can also use shared address data sections; these images are not assigned P1 addresses, however, because the base address for an executable image is determined when the image is linked.

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6520PRO_007.HTML