HP OpenVMS Systems Documentation

HP OpenVMS Alpha Version 7.3--2 Release Notes

V7.3-2

The most current TCP/IP header files ship with HP TCP/IP Services for OpenVMS Version 5.4. When Version 5.4 of TCP/IP Services is installed, the files are located in TCPIP$EXAMPLES. The one exception is <in6.h> . In the DECC$RTLDEF.TLB shipped with OpenVMS Version 7.3-2 <in6.h> is conceptually, but not textually, the same as the TCP/IP Services Version 5.4 variant in TCPIP$EXAMPLES.

5.3.30 glob Function Not Supported with /POINTER_SIZE=LONG

V7.3-2

The glob function is not supported when it is compiled with the /POINTER_SIZE=LONG qualifier. Unpredictable run-time errors can occur.

5.3.31 New 64-bit Function Support: Special Considerations

V7.3-2

The following functions offer new 64-bit pointer support in OpenVMS Version 7.3-2:

getaddrinfo        getpwnam
freeaddrinfo       getpwuid
sendmsg            getpwent
recvmsg

These functions previously offered only 32-bit support, even when compiled with /POINTER_SIZE=LONG. In order to preserve the previous behavior of 32-bit pointer support in these functions even when compiled with /POINTER_SIZE=LONG, these functions do not follow the normal convention for 32-bit and 64-bit support as documented in the HP C Run-Time Library Reference Manual for OpenVMS Systems.

To provide the new 64-bit support, the following variants of these functions and the corresponding structures they use have been introduced:

Function                        Structure
--------                        ---------
__getaddrinfo32                 __addrinfo32
__getaddrinfo64                 __addrinfo64
__freeaddrinfo32                __addrinfo32
__freeaddrinfo64                __addrinfo64
__recvmsg32                     __msghdr32
__recvmsg64                     __msghdr64
__sendmsg32                     __msghdr32
__sendmsg64                     __msghdr64
__32_getpwnam                   __passwd32
__64_getpwnam                   __passwd64
__32_getpwuid                   __passwd32
__64_getpwuid                   __passwd64
__32_getpwent                   __passwd32
__64_getpwent                   __passwd64

When compiling the standard versions of these functions, you get the the following behavior:

• With /POINTER_SIZE=32 specified, the compiler converts the call to the 32-bit version of the function. For example, getaddrinfo is converted to __getaddrinfo32 .
• With /POINTER_SIZE=64 specified, the compiler converts the call to the 64-bit version of the function. For example, getaddrinfo is converted to __getaddrinfo64 .
• When the /POINTER_SIZE qualifier is not specified, neither the 32-bit-specific nor the 64-bit-specific function prototypes are defined.

However, a similar conversion of the corresponding structures does not occur for these functions. This behavior is necessary because these structures existed prior to OpenVMS Version 7.3-2 as 32-bit versions only, even when compiled with /POINTER_SIZE=LONG. Implicitly changing the size of the structure could result in unexpected run-time errors.

When compiling programs that use the standard version of these functions for 64-bit support, you must use the 64-bit-specific definition of the related structure. With /POINTER_SIZE=64 specified, compiling a program with the standard function name and standard structure definition will result in compiler PTRMISMATCH warning messages.

For example, the following program uses the getaddrinfo and freeaddrinfo routines, along with the standard definition of the addrinfo structure. Compiling this program results in the warning messages shown in this example:

$ type test.c
#include <netdb.h>

int main ()
{
    struct addrinfo *ai;

    getaddrinfo ("althea", 0, 0, &ai);
    freeaddrinfo (ai);
    return 0;
}

$ cc /pointer_size=64 TEST.C

    getaddrinfo ("althea", 0, 0, &ai);
....^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value
"&ai" is "long pointer to struct addrinfo", which is not compatible with "long
pointer to struct __addrinfo64".
at line number 7 in file TEST.C;1

    freeaddrinfo (ai);
....^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value
"ai" is "struct addrinfo", which is not compatible with "struct __addrinfo64".
at line number 8 in file TEST.C;1
$

When compiling for 64 bits, you must use the 64-bit-specific version of the related structure. In the previous example, the declaration of the ai structure could be changed to the following:

struct __addrinfo64 *ai;

Or, to provide flexibility between 32-bit and 64-bit compilations, the ai structure could be declared as follows:

#if __INITIAL_POINTER_SIZE == 64
    struct __addrinfo64 *ai;
#else
    struct __addrinfo32 *ai;
#endif

V7.3-2

Installation and Initialization

Installation of CDSA is done automatically when you install the operating system. However, you must be aware of the following considerations:

• Although the CDSA installation is part of the OpenVMS Alpha Version 7.3-2 installation, the setup and initialization of CDSA must be performed separately. Before you can use CDSA, you must perform the following manual procedure. You need the SYSPRV privilege to run this procedure. Enter the following command:

  $ @SYS$STARTUP:CDSA$INITIALIZE

  
  When a new version of CDSA is installed (for example, in an upgrade from field test to a production version, or to a new version of OpenVMS), you must run the CDSA upgrade procedure (@SYS$STARTUP:CDSA$UPGRADE). You should shut down any CDSA application before you run the upgrade procedure.
  It is not necessary to rerun the initialization or upgrade procedures when the system is rebooted. You also do not need to add the initialization or upgrade procedures to the OpenVMS startup procedures.
• Do not attempt to remove CDSA from your system. Use of the PCSI command PRODUCT REMOVE is not supported for CDSA, even though there is an apparent option to remove CDSA. (This option is due to the use of PCSI in the installation.) CDSA is installed together with the operating system and is tightly bound with it. An attempt to remove it from OpenVMS will not work cleanly and could create other undesirable effects. An attempt to remove CDSA will result in a message similar to the following:

  %PCSI-E-HRDREF, product CPQ AXPVMS CDSA Vn.n is referenced by DEC AXPVMS OPENVMS V7.3-2 -PCSI-E-HRDRF1, the two products are tightly bound by this software dependency

V7.3

This potential change in behavior is restricted to a CONVERT command that specifies both the /NOSORT qualifier and a collated key type on one of the keys in the output file.

The /NOSORT qualifier on a CONVERT command indicates that the primary key is already in sorted order in the input file and directs the Convert utility not to sort it. Prior to OpenVMS Version 7.3, the Convert utility had a defect that caused it to always sort the input file if some key specified for the output file had a collated key type, regardless of whether /NOSORT was specified. As of OpenVMS Version 7.3, the Convert utility has been fixed to appropriately obey the /NOSORT qualifier on the command line, even if one of the keys in the output file is a collated key.

This means that a convert operation that previously succeeded as a side-effect of the collated key defect may now produce %CONVERT-I-SEQ messages if the input file is not already in sorted order by the primary key and /NOSORT is specified on the command line. The /NOSORT qualifier should not be used if the input file is not already in sorted order by the primary key.

5.6 Debugger: Previous Versions of Client/Server Interface Not Supported

V7.3

The OpenVMS Version 7.3 debugger does not support previous versions of the client/server interface. You must install the client/server interface found in the kit on the distribution media, as identified in the following table:

These client kits are self-extracting .EXE files.

Once the appropriate executable file has been transferred to the PC, you can run the file to install the debug client on the PC. The InstallShield installation procedure guides you through the installation.

By default, the debug client is installed in the \Program Files\OpenVMS Debugger folder. You can also click Browse to select an alternate location.

5.7 Debugging Modes: Avoiding CPUSPINWAIT Bugchecks

V7.3-1

The OpenVMS operating system has a number of special modes of operation designed to help you debug complex hardware and software problems. In general terms, these special modes enable an extra level of tracing, data recording, and consistency checking that is useful in identifying a failing hardware or software component. These modes of operation are controlled by several system parameters: MULTIPROCESSING, POOLCHECK, BUGCHECKFATAL, and SYSTEM_CHECK.

If you are using one of these special modes (for example, to debug a device driver or other complex application), under certain conditions, generally related to high I/O loads, it is possible to incur a CPUSPINWAIT bugcheck. Specifically, any privileged code that runs for extended periods of time while holding a spinlock can cause a CPU spinwait bugcheck. Spinlocks are used to delineate the entry and exit points for critical sections, and should not be held continuously, as can occur in this situation.

To prevent a CPUSPINWAIT bugcheck, either use the system default settings for these system parameters, or reduce the loading of the system.

If you have reason to change the default settings, you can reduce the likelihood of encountering a problem by setting the SMP_LNGSPINWAIT system parameter to a value of 9000000.

5.8 HP COBOL Run-Time Library (RTL) for OpenVMS Alpha

V7.3-2

The HP COBOL RTL (DEC$COBRTL) has been updated to V2.8-670 for OpenVMS Alpha Version 7.3-2.

5.8.1 COBOL RTL and UNSTRING

V7.3-2

The COBOL RTL now correctly handles UNSTRING OR for cases where there is overlap in the DELIMITED BY strings.

5.8.2 COBOL RTL Detects Device Full on CLOSE

V7.3-2

The COBOL RTL now detects when the device is full on a CLOSE operation.

5.8.3 COBOL RTL and Record-Locking Restriction

V7.3-1

In certain circumstances with the START or WRITE statement, COBOL acquires multiple record locks with automatic record locking. If you encounter this situation, you can clear the record locks using either UNLOCK ALL RECORDS or CLOSE followed by OPEN.

5.9 Hypersort Utility

V7.3-2

The following notes concern the Hypersort utility. Hypersort has been updated for OpenVMS Alpha Version 7.3-2. The new version of Hypersort is V04-004.

As always, continue to use SORT32 as a workaround for any unresolved problems with Hypersort or any functionality not implemented in Hypersort.

5.9.1 CONVERT Performance with Large Files

V7.3-2

Hypersort now correctly handles CONVERT with large files. Previously, just a small change in working set extent could result in very poor Hypersort performance.

5.9.2 Hypersort and VFC Files Restriction

V7.3-2

Use of VFC files with Hypersort requires /FORMAT=RECORD_SIZE:n.

5.9.3 SORT and MERGE Can Hang with Large Input Files

V7.3-2

In some cases when Hypersort is dealing with a very large input file (typically greater than 4GB), Hypersort can hang or terminate with ACCVIO. If you encounter an ACCVIO or hang with Hypersort, the workaround is to use SORT32.

5.9.4 /FORMAT=RECORD_SIZE Restriction

V7.3-1

Hypersort supports /FORMAT=RECORD_SIZE:n for use with both SORT and MERGE, with the following two restrictions:

• In all cases, if the command-specified RECORD_SIZE is less than the longest record size (LRL) of any record in the input files, the records that are too long are truncated to the RECORD_SIZE size in the sorted output file and the diagnostic message %SORT-E-BAD_LRL is issued. In this situation, the output file should be discarded and the sort should be rerun. The RECORD_SIZE parameter for the SORT command should be revised to a value appropriate to the size of the largest record as shown in the listing of a DIR/FULL command for the input files.
• SORT and MERGE produce output sequential files from input indexed files. The %SORT-E-BAD_LRL diagnostic message can also be issued for this case.

V7.3-1

Hypersort does not fully support search lists and logical names used for input files and work files. SORT32 should be used when this is a problem.

5.9.6 Lack of Free Space for Work Files

V7.3-1

Hypersort does not properly terminate if free space is exhausted in all available sort work files. To avoid this restriction, allocate sufficient free space for the devices used for sort work files; or use SORT32 to detect that work file space has been exhausted.

5.9.7 Hypersort and SORT32 Performance: Working Set and Page File Quota

V7.3-1

Hypersort and SORT32 use different sorting and work file algorithms. Either sort utility may be faster depending on the input file and the memory/disk/CPU configuration. Make sure that working set extent is at most one third of page file quota with either Hypersort or SORT32.

5.9.8 Hypersort and SORT32 Performance with Variable Length Records

V7.3-1

SORT32 and Hypersort allocate fixed sized slots for sort work files based on the longest record length (LRL) information in the file. To improve sort performance, try to set LRL information in the file as close as possible to the actual longest record length. Poor initial performance may be the result of sorting some files produced by C programs, because the LRL is set higher than needed (to 32767).

5.9.9 Input Asterisk (*) Restriction

V7.3

Hypersort does not support asterisk (*) as an input file specification.

5.9.10 Work File Directories Restriction

V7.3

Hypersort work files must be redirected to directories that allow multiple file versions that can handle the number of requested work files. This restriction also exists in SORT32.

5.10 Librarian Utility: PGFLQUOTA Should Exceed 23000

V1.5

The OpenVMS Alpha LIBRARIAN sometimes does not inform you of errors during compression, data reduction, or data expansion operations. This problem occurs if the account or process in which the LIBRARIAN is running has a low PGFLQUOTA process quota. Operation failure is not readily apparent because the $PUTMSG system service always returns a status of SS$_NORMAL, even when the system service fails. However, when a failure occurs, the LIBRARIAN returns a status other than Success.

To work around this problem, run the compression, data reduction, or data expansion operation in an account with a PGFLQUOTA process quota greater than 23000. In addition, ensure that your command procedures check the return status from the LIBRARY command.

5.11 Lightweight Directory Access Protocol (LDAP) API

The following sections contain release notes pertaining to the LDAP API.

5.11.1 The Routine ldap_get_option Returns Error -1 When ld Is NULL

V7.3

Using a value of NULL for the ld parameter in a call to ldap_get_options() results in an error of -1 being returned, rather than the routine returning a set of global default data.

5.11.2 The Routine ber_flatten() Fails to Detect Mismatched Braces

V7.3

The routine ber_flatten() does not correctly detect the situation where '{' and '}' format modifiers in a BerElement are incorrectly matched.

5.12 Linker Utility

The following sections describe release notes pertaining to the Linker Utility.

5.12.1 Linker Appears to Hang When Many Files Are Specified

V7.3-2

When the RMS_RELATED_CONTEXT linker option is on (the default is RMS_RELATED_CONTEXT=YES) and a nonexistent file is specified in a list of files for the LINK command, the linker's call to LIB$FIND_FILE takes a long time to complete and the linker may appear to hang. Depending on the number of files being linked and the use of logical names in their specification, the linker may take hours to finish because LIB$FIND_FILE locates every combination of the missing file's prefix before displaying a "file not found" message. Note that you cannot terminate the linker process with Ctrl/Y after the linker has called LIB$FIND_FILE.

Workaround

Specify /OPTION in the LINK command. When you press Return, the linker waits for you to enter information into an options file. When you are finished, press Ctrl/Z. To avoid the problem described in this release note, include the following items in the options file:

• On the first line, specify this option:

  RMS_RELATED_CONTEXT=NO

  
  With the RMS_RELATED_CONTEXT option set to NO, any missing file listed in this options file will generate an immediate "file not found" message.
• On subsequent lines, specify the files to be linked, using full file specifications (in the form disk:[dir]filename.ext) for every file. Full file specifications are required because when you specify RMS_RELATED_CONTEXT=NO, file name "stickiness" is disabled.

For example, consider the following LINK command:

$ LINK DSK:[TEST]A.OBJ, B.OBJ

If you want to specify this command with RMS_RELATED_CONTEXT=NO, you would specify /OPTION and then enter full file specifications for the files to be linked, as follows:

$  LINK SYS$INPUT:/OPTION
RMS_RELATED_CONTEXT=NO
DSK:[TEST]A.OBJ, DSK:[TEST]B.OBJ [Ctrl/Z]
$

For more information about the RMS_RELATED_CONTEXT option, refer to the OpenVMS Linker Utility Manual.

Example

The following example shows how the linker appears to hang when file DOES_NOT_EXIST.OBJ is included in the list and the RMS_RELATED_CONTEXT option is not specified (and therefore defaults to YES).

$  DEFINE DSKD$ WORK4:[TEST.LINKER.OBJ.]
$  DEFINE RESD$ ROOT$, ROOT2$, ROOT3$, ROOT4$, ROOT5$, DISK_READ$:[SYS.] (1)
$  DEFINE ROOT$ WORK4:[TEST.PUBLIC.TEST]
$  DEFINE ROOT2$ WORK4:[TEST.LINKER.]
$  DEFINE ROOT3$ WORK4:[TEST.UTIL32.]
$  DEFINE ROOT4$ WORK4:[TEST.PUBLIC.]
$  DEFINE ROOT5$ WORK4:[TEST.PUBLIC.TMP]
$  LINK/MAP/FULL/CROSS/EXE=ALPHA.EXE  RESD$:[TMPOBJ] A.OBJ,-
_$  RESD$:[SRC]B.OBJ,C,DSKD$:[OBJ]D.OBJ,E,RESD$:[TMPSRC]F.OBJ,-
_$  RESD$:[TEST]G.OBJ,RESD$:[SRC.OBJ]H,RESD$:[COM]DOES_NOT_EXIST.OBJ
[Ctrl/T] NODE6::_FTA183: 15:49:46 LINK CPU=00:02:30.04 PF=5154 IO=254510 MEM=134 (2)
[Ctrl/T] NODE6::_FTA183: 15:49:46 LINK CPU=00:02:30.05 PF=5154 IO=254513 MEM=134
[Ctrl/T] NODE6::_FTA183: 15:50:02 LINK CPU=00:02:38.27 PF=5154 IO=268246 MEM=134
[Ctrl/T] NODE6::_FTA183: 15:50:02 LINK CPU=00:02:38.28 PF=5154 IO=268253 MEM=134
[Ctrl/T] NODE6::_FTA183: 15:50:14 LINK CPU=00:02:44.70 PF=5154 IO=278883 MEM=134

1. This command defines logical names and equivalents.
2. Each time you press Ctrl/T, the CPU and IO values increase, but the MEM and PF values do not, indicating that LIB$FIND_FILE is being called.

As shown in the following example, using an options file to set RMS_RELATED_CONTEXT to NO causes the link operation to finish immediately when it encounters the missing file.

$  DEFINE DSKD$ WORK4:[TEST.LINKER.OBJ.]
$  DEFINE RESD$ ROOT$, ROOT2$, ROOT3$, ROOT4$, ROOT5$, DISK_READ$:[SYS.]
$  DEFINE ROOT$ WORK4:[TEST.PUBLIC.TEST.]
$  DEFINE ROOT2$ WORK4:[TEST.LINKER.]
$  DEFINE ROOT3$ WORK4:[TEST.UTIL32.]
$  DEFINE ROOT4$ WORK4:[TEST.PUBLIC.]
$  DEFINE ROOT5$ WORK4:[TEST.PUBLIC.TMP.]
$  LINK/MAP/FULL/ CROSS /EXE=ALPHA.EXE SYS$INPUT:/OPTION
RMS_RELATED_CONTEXT=NO
RESD$:[TMPOBJ]A.OBJ,RESD$:[SRC]B.OBJ,RESD$:[SRC]C,DSKD$:[OBJ]D.OBJ
DSKD$:[OBJ]E,RESD$:[TMPSRC]F.OBJ,RESD$:[TEST]G.OBJ
RESD$:[SRC.OBJ]H,RESD$:[COM]DOES_NOT_EXIST.OBJ [Ctrl/Z]

%LINK-F-OPENIN, error opening DISK_READ$:[SYS.][COM]DOES_NOT_EXIST.OBJ; as input
-RMS-E-FNF, file not found
$