|
HP OpenVMS Systems Documentation |
|
HP OpenVMS Version 8.3 New Features and Documentation Overview
4.3 Examples
Example of Mastering Optical Media
The following sequence of commands shows how to create a 600 MB CD-R media recording on a CD-capable recording device, using an LD disk LDA600:. Its storage copy file is stored on the device DISK$SCRATCH:. The sequence assumes that a blank CD-R disk is loaded into the target DQA0: drive. A directory is created, and the user's LOGIN.COM file is copied into the directory. After recording is complete, the recorded media contains a single OpenVMS directory called [DATA].
Example of Formatting and Recording Data onto a DVD
The following example shows how to format and then record the data stored on a LDA600: disk master onto a DVD+RW drive and its associated DVD+RW media. This media is located on device DQA0:.
Chapter 5
|
symlink readlink unlink realpath lchown lstat |
For more information on symbolic links and POSIX pathname processing,
see Chapter 12 of the HP C Run-Time Library Reference Manual.
5.1.2 Byte-Range Locking
The C RTL supports byte-range file locking using the F_GETLK, F_SETLK,
and F_SETLKW commands of the
fcntl
function, as defined in the X/Open specification. The OpenVMS lock
manager is used to implement this feature. Byte-range file locking is
allowed across clusters. You can only use offsets that fit into 32-bit
unsigned integers. For more information, see the
fcntl
function in the HP C Run-Time Library Reference Manual.
5.1.3 New C RTL Functions
In addition to the symbolic link functions listed in Section 5.1.1, the following new functions based on the X/Open specification have been added to the C RTL:
crypt setkey encrypt fchmod |
The CRTL ships header files for users to call TCP/IP. These headers have had numerous problems, making some of them unusable for anything beyond trivial TCP/IP programming.
Previously, corrected headers have shipped with several releases of
TCP/IP in their examples area. This enhancement to the C RTL now places
those corrected headers in the C RTL header library (DECC$RTLDEF.TLB).
For more information, see the C RTL section of the OpenVMS Version 8.3
Release Notes.
5.2 CDSA for OpenVMS and Secure Delivery
CDSA Version 2.2 for OpenVMS is based on the CDSA open source project. In addition, the CDSA implementation on OpenVMS is based on the Intel V2.0 Release 3 reference platform. New features in CDSA Version 2.2 for OpenVMS include Secure Delivery and support for HRS (Human Recognition Service Standard). These features are described in the following list.
For more information, refer to HP Open Source Security for OpenVMS, Volume 1: Common Data Security Architecture.
For additional information about CDSA, see the Common Data Security Architecture Web site at the following location:
OpenVMS V8.3 now supports the ability for a process to declare a sub-second deadlock wait time for the lock manager. This can be done with the $SET_PROCESS_PROPERTIES system service and the new item code PPROP$C_DEADLOCK_WAIT. The sub-second deadlock wait time overrides the system parameter DEADLOCK_WAIT time. In addition, the $GETJPI system service and F$GETJPI lexical function allow the retrieval of this time by using the item codes of JPI$_DEADLOCK_WAIT and DEADLOCK_WAIT. See the HP OpenVMS System Services Reference Manual and HP OpenVMS DCL Dictionary for more information on the usage.
The system parameter DEADLOCK_WAIT is in second units, so the smallest value you can set is 1 second. The sub-second deadlock wait time set via the system service $SET_PROCESS_PROPERTIES is valid only for the current image and is cleared during image rundown. The parameter passed is in 100nsec units and cannot exceed 1 sec. If the value is too small, then it is increased to a minimum value of 10msec. You can also call this system service to clear a previously set sub-second value by passing a parameter value of zero. Note the following example:
[...] #define TEN_MSEC 100000 uint64 dead_wait; uint64 prev_value; // // Set a 0.5 second deadlock wait time for the current process // dead_wait = 50 * TEN_MSEC; status = sys$set_process_properties ( 0, 0, 0, PPROP$C_DEADLOCK_WAIT, dead_wait, &prev_value ); [...] |
The following sections describe new features of the OpenVMS Debugger on
OpenVMS Version 8.3.
5.4.1 Improved C++ Support for Operator Names
Support has been improved for C++ operator names, now on Alpha systems as well as Integrity server systems. In particular, user-defined operator names are now supported. Prior to this change, you would have to enclose an operator name in %NAME.
For example:
DBG> SHOW SYMBOL /FULL operator ==
routine C::operator==
type signature: bool operator==(C)
code address: 198716, size: 40 bytes
procedure descriptor address: 65752
DBG> SET BREAK operator==
|
Now available on Alpha systems as well as I64 systems, the OpenVMS Debugger can now set modules automatically, making use of an explicit SET MODULE command optional. There are two reasons for this feature:
DBG> SET BREAK X\Y |
Now on Alpha systems as well as Integrity server systems, the SHOW STACK command accepts a /START_LEVEL=n qualifier that directs SHOW STACK to begin displaying stack information at call frame level n.
For example, to see the stack information for only frame 3, type the following command:
DBG> SHOW STACK/START=3 1 |
To see the details for the 4th and 5th stack frames, type the following command:
DBG> SHOW STACK/START=4 2 |
Now on Alpha systems as well as Integrity server systems, the default
data type for untyped storage locations has been changed from longword
(32 bits) to quadword (64 bits). Note that storage locations with data
type information will continue to be displayed according to the related
type.
5.4.5 Improved Overloaded Symbol Support in SHOW SYMBOL Command
Now on Alpha systems as well as Integrity server systems, the SHOW SYMBOL command has been enhanced to recognize overloaded symbol names. Previously, it just printed the various overloaded names. With the enhancement, it now prints each name and the associated information with that name. For example:
DBG> show symbol/full g
overloaded name C::g
routine C::g(char)
type signature: void g(char)
address: 132224, size: 128 bytes
routine C::g(long)
type signature: void g(long)
address: 132480, size: 96 bytes
|
The GNAT Pro (Ada 95) compiler is now supported on OpenVMS for Integrity servers systems. For information on this product, contact AdaCore directly.
Note that HP is not porting the HP Ada (Ada 83) compiler from OpenVMS
Alpha to OpenVMS for Integrity servers.
5.4.7 Debugging Programs Loaded into P2 Space Now Supported
The OpenVMS Version 8.3 Debugger now allows you to debug programs
loaded into P2 space.
5.4.8 SET WATCH Command Has Been Improved
Watchpoints on a location in memory (called static watchpoints) sometimes fail to notice writes by asynchronous system services and on occasion, might even cause failures of writes by asynchronous system services. For example, an asynchronous write by SYS$QIO to its IOSB output parameter may fail if that IOSB is being watched directly or even if it simply lives on the same page as an active static watchpoint.
The debugger now attempts to notice this condition. When it suspects a problem, the debugger warns the user about potential collisions between static watchpoints and asynchronous system services. For example:
DBG> g
%DEBUG-I-ASYNCSSWAT, possible asynchronous system service and static watchpoint collision
break at LARGE_UNION\main\%LINE 24192+60
DBG> sho call
module name routine name line rel PC abs PC
*LARGE_UNION main 24192 00000000000003A0 00000000000303A0
*LARGE_UNION __main 24155 0000000000000110 0000000000030110
FFFFFFFF80B90630 FFFFFFFF80B90630
DBG> ex/sour %line 24192
module LARGE_UNION
24192: sstatus = sys$getsyi (EFN$C_ENF, &sysid, 0, &syi_ile, &myiosb, 0, 0);
|
Type HELP MESSAGE ASYNCSSWAT in the debugger to learn more about the
actions to take when this condition is detected.
5.4.9 Not a Thing (NaT) Support for Integer Registers
Previously, the debugger did not inform the user when an integer register's NaT bit was set. The user had to examine the register's bit in the %GRNAT0 register to learn this information. In the following example, integer registers R9 and R10 have their NaT bits set:
DBG> ex %r9:%r12 TEST\%R9: 0000000000000000 TEST\%R10: 0000000000000000 TEST\%R11: 0000000000000000 TEST\%SP: 000000007AC8FB70 DBG> ex/bin grnat0 <9,4,0> TEST\%GRNAT0+1: 0110 DBG> |
The debugger now displays the string "NaT" when the integer register's NaT bit is set. For example:
DBG> ex %r9:%r12 TEST\%R9: 0000000000000000 TEST\%R10: NaT TEST\%R11: NaT TEST\%SP: 000000007AC8FB70 DBG> ex/bin grnat0 <9,4,0> TEST\%GRNAT0+1: 0110 DBG> |
Users can still see the actual physical value in a NaT register by specifying a type override. For example:
DBG> ex %r10 TEST\%R10: NaT DBG> ex/quad %r10 TEST\%R10: 0000000000000000 DBG> |
The debugger now automatically loads the symbol table for a module when
the module names appear in a path name. Previously, a command like SET
BREAK M\R, for example, would fail with an "unknown symbol R" error if
the symbols for module M were not loaded. Now, the command succeeds;
the debugger loads the symbols for module M first and is then able to
locate the symbol R.
5.4.11 Improved Support for C++ Destructors
The debugger now recognizes C++ destructor names. Previously, the user was required to enclose the destructor name with the %NAME lexical. This is no longer required. The following example shows the new behavior:
DBG> examine C::~C
C::~C: alloc r35 = ar.pfs, 3F, 01, 00
DBG>
DBG> ex/source ~C
module CXXDOCEXAMPLE
37: ~C() {}
|
5.4.12 Support for C++ Template Names
The debugger now recognizes and supports C++ template names. For
example:
DBG> e Map<string, int>::operator[] Map<string, int>::operator[]: alloc r34 = ar.pfs, 1E, 05, 00 |
The debugger now provides partial support for programs written in Ada.
The debugger understands most Ada constructs, including packages, child
units, procedures, variables, simple data types, and modular types.
Support for more complicated data types, such as tagged types and
pointers to unconstrained arrays, is expected in a future release.
5.5 Kerberos for OpenVMS
Kerberos Version 3.0 for OpenVMS is based on MIT Kerberos V5 Release 1.4.1. (The previous version of Kerberos, Version 2.1, was based on MIT Kerberos V5 Release 1.2.6.)
New features in Kerberos Version 3.0 are described in the following list.
Kerberos performs authentication as a trusted third-party authentication service by using conventional (shared secret key) cryptography. Kerberos provides a means of verifying the identities of principals, without relying on authentication by the host operating system, without basing trust on host addresses, without requiring physical security of all the hosts on the network, and under the assumption that packets traveling along the network can be read, modified, and inserted at will. 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.
For more detailed information, refer to HP Open Source Security for OpenVMS, Volume 3: Kerberos.
For information about downloading the latest version of Kerberos for OpenVMS, see the following Web site:
For additional information about Kerberos, see the MIT Kerberos Web site at the following location:
| Previous | Next | Contents | Index |