Document revision date: 19 July 1999

The OpenVMS Registry can control access to OpenVMS Registry keys in the following two ways:

• Through NTLM security
  NTLM security uses NT credentials to control access to registry keys and can be used to control access to specific keys.
• Through OpenVMS security
  OpenVMS security uses OpenVMS privileges and rights identifiers to control access to the OpenVMS Registry database and cannot be used to control access to specific keys.

COM applications require read access to the COM registry keys and COM developers require read and write access to the COM registry keys. In COM Version 1.0 for OpenVMS (without authentication), COM for OpenVMS does not have NT credentials; as a result, COM Version 1.0 for OpenVMS uses OpenVMS security to control access to the OpenVMS Registry. Because you cannot control this OpenVMS Registry access on a per-key basis, you must grant all COM application read access to the entire OpenVMS Registry and you must grant all COM developers write access to the entire OpenVMS Registry. This means that the entire OpenVMS Registry, including the PATHWORKS portion not used by COM for OpenVMS, is accessible to COM applications and developers.

In COM Version 1.1 for OpenVMS (with NTLM authentication), COM for OpenVMS will use NT credentials to control access to specific OpenVMS Registry keys and remove the OpenVMS privileges and rights identifiers. This will protect those parts of the OpenVMS Registry that are not used by COM for OpenVMS.

4.4 Common File Qualifier Routines

OpenVMS Version 7.2 contains the UTIL$CQUAL routines, which allow you to parse the command line for qualifiers related to certain file attributes, and to match files you are processing against the selected criteria retrieved from the command line. The utility routines allow a user to select files and perform terminal I/O without the application writer performing these explicitly.

The common file qualifier routines begin with the characters UTIL$CQUAL. Your program calls these routines using the OpenVMS Calling Standard. When you call a UTIL$CQUAL routine, you must provide all the required arguments. Upon completion, the routine returns its completion status as a condition value.

The following table lists the common file qualifier routines.

Table 4-1 UTIL$CQUAL Routines

Routine Name	Description
UTIL$CQUAL_FILE_PARSE	Parses the command line for file qualifiers, and obtains associated values. Returns a context value that is used when calling the matching and ending routines.
UTIL$CQUAL_FILE_MATCH	Compares the routine file input to the command line data obtained from the parse routine call.
UTIL$CQUAL_FILE_END	Deletes all virtual memory allocated during the command line parse routine call.
UTIL$CQUAL_CONFIRM_ACT	Prompts a user for a response from SYS$COMMAND.

4.4.1 Using the Common File Qualifier Routines

Follow these steps to use the common file qualifier routines:

1. Call UTIL$CQUAL_FILE_PARSE to parse the command line for the common file qualifiers.
2. Call UTIL$CQUAL_FILE_MATCH for each checked file. UTIL$CQUAL_FILE_MATCH returns an indication that the file is, or is not, to be processed.
3. Call UTIL$CQUAL_FILE_END to release the virtual memory held by the common file qualifier package.

You may optionally call UTIL$CQUAL_CONFIRM_ACT to ask for user confirmation without calling the other common qualifier routines.

For more information about the common file qualifier routines, refer to the OpenVMS Utility Routines Manual.

4.5 DECthreads

This section contains information about new DECthreads features for OpenVMS Version 7.2.

4.5.1 Yellow Zone Stack Overflow (Alpha only)

DECthreads now provides a special protected area of memory between the usable stack region and the guard page. When accessed, the VMS exec un-protects this memory and a stack overflow exception is delivered to the user thread. This feature enables applications to catch stack overflow conditions and attempt recovery or graceful termination.

4.5.2 Read-Write Locks (Alpha and VAX)

DECthreads now supports use of multiple readers, single writer locks, also known as read-write locks, allowing many threads to have simultaneous read-only access to data while allowing only one thread to have write access at any given time. Such locks are typically used to protect data that is read more frequently than written.

As part of this support, the following new routines have been added to the DECthreads POSIX 1003.1c library:

• pthread_rwlock_destroy()
• pthread_rwlock_init()
• pthread_rwlock_rdlock()
• pthread_rwlock_tryrdlock()
• pthread_rwlock_trywrlock()
• pthread_rwlock_unlock()
• pthread_rwlock_wrlock()
• pthread_rwlockattr_destroy()
• pthread_rwlockattr_init()

DECthreads has improved its debugging support, allowing Compaq and third-party debuggers to better integrate with DECthreads. The 'pthread' debugging interface, previously only available via SDA is now available from the OpenVMS Debugger as well.

4.6 DIGITAL DCE Remote Procedure Call (RPC) Functionality

Beginning with OpenVMS Version 7.2, Remote Procedure Call (RPC) functionality is integrated into the operating system. RPC provides connectivity between individual procedures in an application across heterogeneous systems in a transparent way. This functionality uses the DIGITAL Distributed Computing Environment (DCE) RPC, but also provides the ability to use the Microsoft RPC Application Programming Interface (API) as well as the DIGITAL DCE RPC API. Using RPC, an application can interoperate with either DIGITAL DCE or Microsoft RPC applications. If security is required, you can use either Microsoft's NTLM security or (by installing the full DIGITAL DCE Run-Time Kit) DCE Security.

The RPC daemon allows client/server RPC applications to register their specific endpoints. Registering endpoints allows remote clients of the application to find the server application's entry point on the system.

The DIGITAL DCE Application Developer's Kit (separately licensed) is required to develop RPC applications, but the resulting applications may be installed on any OpenVMS Version 7.2 system, or any supported OpenVMS system where the full DIGITAL DCE Run-Time Kit is installed. The DIGITAL DCE Run-Time Kit, although shipped on the OpenVMS CD-ROM, is licensed with the OpenVMS operating system and does not require the purchase of additional software licenses.

4.6.1 Starting and Stopping RPC

The RPC daemon can be started or stopped with the following new command files:

• DCE$RPC_STARTUP.COM
• DCE$RPC_SHUTDOWN.COM

These command files are located in the directory SYS$COMMON:[SYSMGR].

To start the RPC daemon, execute the DCE$RPC_STARTUP.COM procedure. The following option may be specified:

• [NO]CONFIRM
  Turns user prompting on or off. CONFIRM is the default.

To stop the RPC daemon, execute the DCE$RPC_SHUTDOWN.COM procedure. The following options may be specified in any order:

• [NO]CONFIRM
  Turns user prompting on or off. CONFIRM is the default.
• CLEAN
  Deletes all entries from the RPC endpoint database.

RPC endpoints can be managed using the RPC Control Program (RPCCP). To invoke this utility, enter the following command:

$ RUN SYS$SYSTEM:DCE$RPCCP.EXE

You can type help at the system prompt for information about parameter usage.

4.6.3 Limiting RPC Transports

The RPC daemon can limit what protocols will be used by RPC applications. To restrict the protocols that can be used, set the logical name RPC_SUPPORTED_PROTSEQS to contain the valid protocols. Valid protocols are ncadg_ip_udp, ncacn_ip_tcp, and ncacn_dnet_nsp. Separate each protocol with a colon. For example:

$ define RPC_SUPPORTED_PROTSEQS "ncacn_ip_tcp:ncacn_dnet_nsp"

This definition prevents RPC applications from registering endpoints that use TCP/UDP.

4.6.4 For More Information

Refer to the OpenVMS Version 7.2 Release Notes for important information for existing users of DIGITAL DCE for OpenVMS.

For additional information about DIGITAL DCE for OpenVMS, use online help or refer to the following documentation:

• Digital DCE for OpenVMS VAX and OpenVMS Alpha Installation and Configuration Guide
• Digital DCE for OpenVMS VAX and OpenVMS Alpha Product Guide
• Digital DCE for OpenVMS VAX and OpenVMS Alpha Reference Guide

As of OpenVMS Alpha Version 7.2, VLM applications can use Fast I/O for memory shared by processes through global sections. In prior versions of OpenVMS Alpha, buffer objects could be created only for process private virtual address space. Database applications where multiple processes share a large cache can now create buffer objects for the following types of global sections:

• Page file-backed global sections
• Disk file-backed global sections
• Memory-resident global sections

Buffer objects enable Fast I/O system services, which can be used to read and write very large amounts of shared data to and from I/O devices at an increased rate. By reducing the CPU cost per I/O request, Fast I/O increases performance for I/O operations. Fast I/O improves the ability of VLM applications, such as database servers, to handle larger capacities and higher data throughput rates.

For more information about how to use Fast I/O and buffer objects for global sections, see the OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features.

4.8 Fast Path Support (Alpha Only)

Fast Path is an optional, high-performance feature designed to improve I/O performance. Fast Path creates a streamlined path to the device. Fast Path is of interest to any application where enhanced I/O performance is desirable. Two examples are database systems and real-time applications, where the speed of transferring data to disk is often a vital concern.

Using Fast Path features does not require source-code changes. Minor interface changes are available for expert programmers who want to maximize Fast Path benefits.

Beginning with OpenVMS Alpha Version 7.1, Fast Path supports disk I/O for the CIXCD and the CIPCA ports. These ports provide access to CI storage for XMI- and PCI-based systems. In Version 7.0, Fast Path supported disk I/O for the CIXCD port only.

Fast Path is not available on the OpenVMS VAX operating system.

For more information, see Table 1-1 and Section 4.21.5 in this manual, and refer to the OpenVMS I/O User's Reference Manual.

4.9 Fast Skip for SCSI Tape Drives

If you access your tape drive via your own user-written program, you can use a new modifier, IO$M_ALLOWFAST, to control the behavior of the IO$_SKIPFILE function.

In the past, OpenVMS has always skipped files on tape by using skip-record commands to perform the motion. This has essentially simulated skip-by-filemarks, and while this functions correctly, this type of skipping can be quite slow at times as compared to what a tape can achieve by using skip-by-filemarks commands.

In V7.2, OpenVMS allows the tape driver to be set up to use skip-by-filemarks where the user permits. Modern tape drives keep track of the end of logical data, so MKdriver can use these facilities to position correctly if these features exist on a tape drive. (If they do not, the old skip-by-records skipping is used.)

The skipping-by-filemarks, when used, will correctly sense the end-of-tape provided the tape ends in double EOF. Utilities such as Backup and file structured copy, which use ANSI formatted tape, need the end positioning to be set correctly, and they work fine with the new skip method. They already continue skip-file operations across null files if they exist.

Some third-party utilities may, however, depend on the documented behavior of stopping a skip-by-files on double EOF marks on tape. To accommodate this, OpenVMS assumes by default the use of the old skip-by-records form of tape motion.

Because this form of positioning may be as much as 100 times slower than skip-by-files, OpenVMS provides two additional features:

1. The magtape ACP and Backup uses an added function modifier in their IO$_SKIPFILE commands to tape (IO$M_ALLOWFAST) that permits them to use the skip-by-filemarks command. This modifier is also transmitted across TMSCP, if all systems are at the 7.2 level.
2. The SET MAGTAPE command has a new qualifier, /FAST_SKIP. For more information on this qualifier, see Section 3.8 in this manual, and refer to the OpenVMS DCL Dictionary: N--Z, and online help.

This section briefly describes new features and capablilities pertaining to the command line interface and the callable interface (SOR routines) of the OpenVMS Alpha high-performance Sort/Merge utility. This information is of interest to both general users and programmers.

For more information about these new features, and about using the OpenVMS Alpha high-performance Sort/Merge utility, refer to the OpenVMS User's Manual and the OpenVMS Utility Routines Manual.

4.10.1 High-Performance Sorting with Threads

Support for threads has been added to the high-performance Sort/Merge utility. This enables enhanced performance by taking advantage of multiple processors on an SMP configured system.

To obtain best performance when using the high-performance Sort/Merge utility on a multi-processor machine, your program should be linked with the /THREADS_ENABLE qualifier.

4.10.2 Indexed Sequential Output File Organization

Support for indexed sequential output file organization has been added to the high-performance Sort/Merge utility.

You may now specify the /INDEXED_SEQUENTIAL file organization qualifier.

4.10.3 Output File Overlay

Support for output file overlay has been added to the high-performance Sort/Merge utility.

You may now specify the /OVERLAY qualifier to overlay or write an output file to an existing empty file.

4.10.4 Statistical Summary Information

Partial support for statistical summary information has been added to the high-performance Sort/Merge utility.

You may now specify the /STATISTICS qualifier with the following fields:

• Records read/input (SOR$K_REC_INP)
• Records sorted (SOR$K_REC_SOR)
• Records output (SOR$K_REC_OUT)
• Input record length (SOR$K_LRL_INP)

The new intra-cluster communication (ICC) system services, available on Alpha and VAX, form an application programming interface (API) for process-to-process communications. For large data transfers, the ICC system services are the highest-performance OpenVMS application communication mechanism, superior to standard network transports and mailboxes.

The ICC system services enable application program developers to create distributed applications with connections between different processes on a single system, or between processes on different systems within a single OpenVMS Cluster system.

The ICC system services do not require a network product. The communication uses memory or System Communication Services (SCS).

The ICC system services:

• Allow the creation of both client and server processes
• Maintain a simple registry of servers and services
• Manage security of the server process namespace and access to server processes
• Establish connections between these processes and transmit data between these processes
• Provide 64-bit buffer and address support

The ICC system services provide the following benefits:

• An easy-to-use conventional system service interface for interprocess communications within a cluster
• An interface usable for communications between processes within a single, nonclustered node
• An interface callable from all modes and from execlets as well as from images
• An easy-to-use interface giving access to high-speed interconnects such as Memory Channel
• An interface independent of the installation of any networking product
• An interface usable for nonprivileged clients and authorized (but not necessarily privileged) servers

The new system services enable application program developers to create connections between processes on the same or different systems within a single OpenVMS Cluster system.

These services are as follows:

• Open Association: $ICC_OPEN_ASSOC
• Close Association: $ICC_CLOSE_ASSOC
• Connect: $ICC_CONNECT and $ICC_CONNECTW
• Accept: $ICC_ACCEPT
• Reject: $ICC_REJECT
• Disconnect: $ICC_DISCONNECT and $ICC_DISCONNECTW
• Transmit Data: $ICC_TRANSMIT and $ICC_TRANSMITW
• Receive Data: $ICC_RECEIVE and $ICC_RECEIVEW
• Transceive Data: $ICC_TRANSCEIVE and $ICC_TRANSCEIVEW
• Reply: $ICC_REPLY and $ICC_REPLYW

Refer to the OpenVMS System Services Reference Manual: GETQUI--Z for additional information on the ICC system services.

4.11.3 Programming with ICC

Refer to the OpenVMS Programming Concepts Manual for information on programming with ICC.

4.11.4 ICC System Management and Security

Refer to the OpenVMS System Manager's Manual for information on ICC system management and security.

4.12 Java Development Kit (Alpha Only)

The Java Development Kit (JDK) is shipped with the OpenVMS operating system. This kit can be used to develop and run Java applets and programs on OpenVMS Alpha systems.

The JDK for OpenVMS systems contains a just-in-time (JIT) compiler. The JIT compiler provides on-the-fly compilation of your application's Java byte-codes and runtime calls into native Alpha machine code. This results in significantly faster execution of your Java application compared with running it using the Java interpreter. The JIT runs by default when you enter the JAVA command.

The JDK implements Java threads on top of native (POSIX) threads. This allows different Java threads in your application to run on different processors, provided that you have a multiprocessor machine. It also means that your Java application will run properly when linked with native methods or native APIs (such as DCE) that are also implemented using POSIX threads.

For more information, see the Java documentation in the following directory on your OpenVMS Alpha system where the JDK is installed:

SYS$COMMON:[SYSHLP.JAVA]INDEX.HTML

4.13 Kernel Threads Enhancements (Alpha Only)

OpenVMS Alpha Version 7.2 includes the following new kernel threads capabilities:

• Capacity for a larger number of kernel threads per process
• Ability to change the base priorities of all kernel threads with a single call
• Ability to detect a thread stack overflow

In the initial release of the kernel threads support, OpenVMS allowed a maximum of 16 kernel threads per process. This enabled an application to have threads executing on up to 16 CPUs at one time. With OpenVMS Alpha Version 7.2, the number of kernel threads that can be created per-process has been increased to 256. The maximum value for the MULTITHREAD system parameter has also been increased to 256.

4.13.2 New Method for Changing Kernel Thread Priorities

The SYS$SETPRI system service and the SET PROCESS/PRIORITY DCL command both take a process identification value (PID) as an input and therefore affect only a single kernel thread at a time. If you want to change the base priorities of all kernel threads in a process, a separate call to SYS$SETPRI or invocation of the SET PROCESS/PRIORITY command must be done for each thread.

In OpenVMS Alpha Version 7.2, a new value for the 'policy' parameter to the SYS$SETPRI system service has been added. If JPI$K_ALL_THREADS is specified, the call to SYS$SETPRI changes the base priorities of all kernel threads in the target process.

Also, the ALL_THREADS qualifier has been added to the SET PROCESS/PRIORITY DCL command which provides the same support.

4.13.3 Detecting Thread Stack Overflow

The default user stack in a process can expand on demand to be quite large, so single threaded applications do not typically run out of user stack. When an application is written using DECthreads, each thread gets its own user stack, which is a fixed size. If the application developer underestimates the stack requirements, the application may fail due to a thread overflowing its stack. This failure is typically reported as an access violation and is very difficult to diagnose. To address this problem, yellow stack zones have been introduced in OpenVMS Version 7.2 and are available to applications using DECthreads.

Yellow stack zones are a mechanism by which the stack overflow can be signaled back to the application. The application can then choose either to provide a stack overflow handler or do nothing. If the application does nothing, this mechanism helps pinpoint the failure for the application developer. Instead of an access violation being signaled, a stack overflow error is signaled.

	privacy and legal statement
6520PRO_006.HTML