[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here

HP OpenVMS Version 8.2 New Features and Documentation Overview


Previous Contents Index


LBR$REPLACE_KEY

The LBR$REPLACE_KEY routine modifies or inserts a key into the library.

Format

LBR$REPLACE_KEY library_index ,key_name ,oldrfa ,newrfa [,flags]


RETURNS


OpenVMS usage: cond_value
type: longword (unsigned)
access: write only
mechanism: by value

Longword condition value. Most utility routines return a condition value. Condition values that this routine can return are listed under Condition Values Returned.


Arguments

library_index


OpenVMS usage: longword_unsigned
type: longword (unsigned)
access: read only
mechanism: by reference

Library control index returned by the LBR$INI_CONTROL routine. The library_index argument is the address of the longword that contains the index.

key_name


OpenVMS usage: char_string
type: character string
access: read only
mechanism: by reference

For libraries with ASCII keys, the key_name argument is the address of a string descriptor for the key.

For libraries with binary keys, the key_name argument is the address of an unsigned longword value for the key.

oldrfa


OpenVMS usage: vector_longword_unsigned
type: longword (unsigned)
access: read only
mechanism: by reference

Old record file address (RFA). The oldrfa argument is the address of a 2-longword array containing the original RFA (returned by LBR$LOOKUP_KEY) of the module header associated with the key you are replacing.

newrfa


OpenVMS usage: vector_longword_unsigned
type: longword (unsigned)
access: read only
mechanism: by reference

New RFA. The newrfa argument is the address of a 2-longword array containing the RFA (returned by LBR$PUT_RECORD) of the module header associated with the new key.

flags


OpenVMS usage: mask_longword
type: longword (unsigned)
access: read only
mechanism: by reference

If present, specifies the type of the key being replaced. The flag bits are:
Flag Bits Description
LBR$M_SYM_WEAK = 0x1 UNIX-style weak symbol attribute
LBR$M_SYM_GROUP = 0x2 Group symbol attribute

If this parameter is not present, NonGroup-Global is the assumed type. In this case, all type lists are searched and the entries removed. The new symbol is placed as the new NonGroup-Global definition with newrfa as the defining module.

If this parameter is present, it represents the flags for the type of symbol being replaced. The replacement is done in place without losing its position in the type list. If the symbol does not exist when the call to this routine is made, the new definition is placed at the end of the type list for the specified type.

Because there are now different symbol definition types, HP advises using the LBR$DELETE_KEY routine followed by the LBR$INSERT_KEY routine, when the old key and new key differ in definition type.


Description

If LBR$REPLACE_KEY does not find the key in the current index, it calls the LBR$INSERT_KEY routine to insert the key. If LBR$REPLACE_KEY does find the key, it modifies the key entry in the index so that it points to the new module header.

Condition Values Returned

LBR$_ILLCTL Specified library control index not valid.
LBR$_INVRFA Specified RFA not valid.
LBR$_LIBNOTOPN Specified library not open.

LBR$SEARCH

The LBR$SEARCH routine finds index keys that point to specified data.

Format

LBR$SEARCH library_index ,index_number ,rfa_to_find ,routine_name [, flags]


RETURNS


OpenVMS usage: cond_value
type: longword (unsigned)
access: write only
mechanism: by value

Longword condition value. Most utility routines return a condition value. Condition values that this routine can return are listed under Condition Values Returned.


Arguments

library_index


OpenVMS usage: longword_unsigned
type: longword (unsigned)
access: read only
mechanism: by reference

Library control index returned by the LBR$INI_CONTROL routine. The library_index argument is the address of the longword that contains the index.

index_number


OpenVMS usage: longword_unsigned
type: longword (unsigned)
access: read only
mechanism: by reference

Library index number. The index_number argument is the address of a longword containing the number of the index you want to search.

rfa_to_find


OpenVMS usage: vector_longword_unsigned
type: longword (unsigned)
access: write only
mechanism: by reference

Record's file address (RFA) of the module whose keys you are searching for. The rfa_to_find argument is the address of a 2-longword array containing the RFA (returned earlier by LBR$LOOKUP_KEY or LBR$PUT_RECORD) of the module header.

routine_name


OpenVMS usage: procedure
type: procedure value
access: read only
mechanism: by reference

Name of a user-supplied routine to process the keys. The routine_name argument is the address of the procedure value of a user-supplied routine to call for each key entry containing the RFA (in other words, for each key that points to the same module header).

This user-supplied routine cannot contain any calls to LBR$DELETE_KEY or LBR$INSERT_KEY.

flags


OpenVMS usage: mask_longword
type: longword (unsigned)
access: read only
mechanism: by reference

If present and nonzero, specifies the type, or all types, of the key provided. The flag bits are:
Flag Bits Description
LBR$M_SYM_WEAK = 0x1 UNIX-style weak symbol attribute
LBR$M_SYM_GROUP = 0x2 Group symbol attribute
LBR$M_SYM_ALL = 0x80000000 All symbols

The user routine is provided the symbol's type through an additional third parameter.


Description

Searches the library index for symbols with the given RFA and calls the supplied routine with those symbols.

Use LBR$SEARCH to find index keys that point to the same module header. Generally, in index number 1 (the module name table), just one key points to any particular module; thus, you would probably use this routine only to search library indexes where more than one key points to a module. For example, you might call LBR$SEARCH to find all the symbols in the symbol index that are associated with an object module in an object library.

If LBR$SEARCH finds an index key associated with the specified RFA, it calls a user-supplied routine with three arguments:

  • The key argument, which is the address of either of the following:
    • A string descriptor for the key name (libraries with ASCII key names)
    • An unsigned longword for the key value (libraries with binary keys)
  • The RFA argument, which is the address of a 2-longword array containing the RFA of the module header
  • The key's type whose flag bits are:
    Flag Bits Description
    LBR$M_SYM_WEAK = 1 UNIX-style weak symbol attribute
    LBR$M_SYM_GROUP = 2 Group symbol attribute

The user routine must return a value to indicate success or failure. If the specified user routine returns a false value (low bit = 0), then the index search terminates.

Note that the key found by LBR$SEARCH is valid only during the call to the user-supplied routine. If you want to use the key later, you must copy it.


Condition Values Returned

LBR$_ILLCTL Specified library control index not valid.
LBR$_ILLIDXNUM Specified library index number not valid.
LBR$_KEYNOTFND Library routine did not find any keys with the specified RFA.
LBR$_LIBNOTOPN Specified library not open.

4.8.6 Library Format Changed due to New UNIX-Style Weak Symbols

Because of the requirements of the Intel C++ compiler, the library format has been expanded to accommodate new UNIX-style weak symbols. Multiple modules matching key names of new UNIX-style weak symbols can now exist in the same library. The Librarian utility ignores the OpenVMS-style weak symbol definitions as it did in the past.

UNIX-style weak symbol definitions behave in the same manner as weak transfer addresses on OpenVMS; that is, their definitions are tentative. If a definition of a stronger binding type is not seen during a link operation, a tentative definition is designated as the definitive definition.

4.8.6.1 New ELF Type for Weak Symbols

A new Executable and Linkable Format (ELF) type was generated to distinguish between the two types of weak symbol definitions.

For modules with ABI versions greater than or equal to 2:

  • Type STB_WEAK represents the UNIX-style weak symbol (formerly, the OpenVMS-style weak symbol definition for ABI Version 1 ELF format)
  • Type STB_VMS_WEAK represents the OpenVMS-style weak symbol definition.

The Librarian supports both the ELF ABI versions 1 and 2 of the object and image file formats within the same library.

Note

The new library format (version 6.0) applies only to ELF object and shareable image libraries. Other libraries will remain at the version 3.0 format.

4.8.6.2 Version 6.0 Library Index Format

HP recommends using the new Version 6.0 libraries.

However, note that with the new library index format, the LBR routines open Version 3.0 and Version 4.0 ELF object and shareable image libraries in read-only mode. You cannot modify the library with the LBR routines or with the Librarian utility. Instead, you can convert your older version libraries to version 6.0 libraries using the following LIBRARY command:


$  LIBRARY/COMPRESS library-name

Using the Librarian utility to modify a Version 3.0, 4.0 or 5.0 ELF object or shareable image library causes the Librarian to automatically convert your library to a version 6.0 library.

Note

Once your library is at least version level 6.0 format, you cannot access the library with some older versions of the Library routines or Librarian utility. Doing so returns the LBR$_UNSUPLVL status, and causes the Librarian utility to display the following message:


%LIBRAR-F-OPENIN, error opening library-name as input
 -LBR-E-UNSUPLVL, unsupported library format level

4.8.6.3 New Group Section Symbols

Symbols may be relative to sections contained in an ELF entity called a GROUP. These groups, and the symbols associated with them, behave in a similar fashion as the new UNIX-style weak symbol definitions; that is, they are tentative definitions. The library must now allow multiple symbol definitions in the library's symbol name index for these types of symbols.

4.8.6.4 Precedence Ordering Rules

The following list describes the symbol types for the combinations of GROUP and UNIX-style WEAK attributes in order of their precedence from highest to lowest. Within these symbol types, the ordering of symbol associations is by time of insertion, from earliest to latest. This ordering is important because when the OpenVMS I64 Linker asks for a symbol resolution from the library, it is given the earliest inserted module instance of the symbol with the highest precedence.

  • NonGroup-Global symbols --Symbols that are not members of an ELF group and are not UNIX-style weak definitions. These symbols have the highest precedence. There may be only one definition of this type. If the symbol of this type already exists in the library, a subsequent symbol definition of this type returns an error.
  • Group Global symbols--Symbols that belong to an ELF section associated with a group and are not UNIX-style weak definitions. Multiple definitions of this type may exist in the library. These definitions are stored in a list, ordered by insertion time. Note that if a module definition in the list is replaced, it does not lose its current position in the list.
  • UNIX-style weak symbols--Symbols that have a UNIX-style weak binding and do not belong to a group. Multiple definitions of this type may exist in the library. These definitions are stored in a list, ordered by insertion time. Note that if a module definition in the list is replaced, it does not lose its current position in the list.
  • Group weak symbols---Symbols that behave as combined Group Global and UNIX-style Weak attributes. Multiple definitions of this type may exist in the library. These definitions are stored in a list, ordered by insertion time. Note that if a module definition in the list is replaced, it does not lose its current position in the list.

4.9 Linker Utility

Refer to Chapter 7 for information on the Linker utility.

4.10 HP OpenVMS Migration Software

HP OpenVMS Migration Software for Alpha to Integrity servers (OMSAI), also known as the binary translator, facilitates migrating OpenVMS Alpha applications to OpenVMS I64 systems by allowing you to translate the OpenVMS Alpha images into equivalent OpenVMS I64 images. When the translated image runs, the OpenVMS I64 transparently supports the image with an environment that allows it to run as if it were on an OpenVMS Alpha system. OMSAI consists of the Alpha Environment Software Translator (AEST) utility and a collection of programs and command files designed to ease the translation process.

For information on the availability of this feature, check the following web site:

http://h71000.www7.hp.com/openvms/products/omsva/omsva.html

4.11 POSIX Threads Features

The following sections describe the new features added to the POSIX Threads Library.

4.11.1 Lowercase Symbol Names for /NAMES=AS_IS Compilation

The POSIX threads library PTHREAD$RTL.EXE exports a number of symbol names (for the pthread API routines, predefined exception objects, and so forth). In prior releases, all letters in these symbols have been in uppercase. In OpenVMS Version 8.2, new lowercase variants of all the symbols are provided in addition to the existing uppercase symbols. These symbols facilitate use of the /NAMES=AS_IS qualifier that is present in a number of HP compiler products.

4.11.2 Support for Process-Shared Mutexes and Condition Variables

The POSIX Threads Library now supports process-shared mutexes and condition variables. Until now, these were supported only on UNIX systems. (Note, process-shared read-write locks are still supported only on UNIX systems.) The following pthread routines are now supported on OpenVMS Version 8.2:

  • pthread_condattr_getpshared
  • pthread_condattr_setpshared
  • pthread_mutexattr_getpshared
  • pthread_mutexattr_setpshared

4.11.3 SET and SHOW Commands Enhanced (I64 Only)

The DCL commands SET and SHOW have been enhanced to allow a user to query and change two main-image header flags, UPCALLS and MKTHREADS on OpenVMS I64 systems. In addition, you can use the SET IMAGE and SHOW IMAGE commands on both Alpha and I64 systems to set and show only I64 images.

The DCL command THREADCP continues to be available on OpenVMS Alpha systems.

4.11.4 New Routine Added to Thread Independent Services API

A new routine, tis_mutex_init_type , has been added to the Thread Independent Services API (TIS). This routine is similar to the existing routine named tis_mutex_init .


tis_mutex_init_type

Initializes the specified mutex object, establishing the mutex's type and name as specified by the caller.

Format

tis_mutex_init_type (mutex,type,name):

Argument Data Type Access
mutex opaque pthread_mutex_t write
type integer read
name char read

C Binding



#include <tis.h>

int
tis_mutex_init_type (
    pthread_mutex_t    *mutex,
    int   type,
    const char    *name );

Arguments

mutex

Pointer to a mutex object (passed by reference) to be initialized.

type

Value for the mutex type attribute. The type argument specifies the type of mutex that will be created. Valid values are:
  • PTHREAD_MUTEX_NORMAL
  • PTHREAD_MUTEX_DEFAULT
  • PTHREAD_MUTEX_RECURSIVE
  • PTHREAD_MUTEX_ERRORCHECK

name

Textual name to be associated with the mutex.

Description

This routine initializes a mutex object with the DECthreads default mutex attributes, except for mutex type and name, which are specified by the caller. A mutex is a synchronization object that allows multiple threads to serialize their access to shared data.

The mutex object is initialized and set to the unlocked state. Refer to the Guide to POSIX Threads Library for information on the types of mutexes.

The mutex name argument is a C language string and provides an identifier that is a meaningful to a person debugging a DECthreads multithreaded application. The name string should be a string literal, or other storage that will remain for the life of the mutex. The contents of the string are not copied as part of mutex initialization.


Return Values

If an error condition occurs, this routine returns an integer value indicating the type of error, the mutex is not initialized, and the contents of mutex are undefined. Possible return values are as follows:

0 Successful completion.
[EAGAIN] The system lacks the necessary resources to initialize a mutex.
[EBUSY] The implementation has detected an attempt to reinitialize mutex (a previously initialized, but not yet destroyed, mutex).
[EINVAL] The value specified by mutex is not a valid mutex, or the type specified by type is not a valid mutex type.
[ENOMEM] Insufficient memory exists to initialize the mutex.
[EPERM] The caller does not have privileges to perform this.

Associated Routines

tis_mutex_destroy()
tis_mutex_init()
tis_mutex_lock()
tis_mutex_trylock()
tis_mutex_unlock()


Previous Next Contents Index