HP OpenVMS Systems Documentation

HP OpenVMS Version 8.2 New Features and Documentation Overview

When a system fails or aborts a shadow set, this significant event causes every shadow set to be reassessed by all other systems with that shadow set mounted. All active minimerge, full merge, or copy operations cease at this time, returning their resources to those systems. (However, if a system is performing a minicopy operation, that operation continues to completion.)

Those systems wait a predetermined amount of time, measured in seconds, before each attempts to manage any shadow set in a transient state. This pause is called a significant-event recovery delay. It is the total of the values specified for two system parameters, SHADOW_REC_DLY and RECNXINTERVAL. (The default value for each is 20 seconds.)

If the value of the significant-event recovery delay is the same on all systems, it is not possible to predict which systems will manage which shadow set. However, by making the value of the significant-event recovery delay different on all systems, you can predict when a specific system will begin to manage transient-state operations.

6.12.6 Managing Merge Operations

A merge transient state is an event that cannot be predicted. The management of merge activity, on a specific system for multiple shadow sets, can be predicted if the priority level settings for the shadow sets differ.

In the following example, there are four shadow sets, and the SHADOW_MAX_COPY parameter on this system is equal to 1. The value of 1 means that only one merge or copy operation can occur at the same time. This example illustrates how the priority level is used to select shadow sets when only merge operations are involved.

Two shadow sets are assigned a priority level and two have the default priority level of 5000.

The four shadow sets DSA1, DSA20, DSA22, and DSA42, are mounted on two systems. DSA20 and DSA42 are minimerge enabled.

$ SET SHADOW/PRIORITY=7000 DSA1:
$ SET SHADOW/PRIORITY=3000 DSA42:
! DSA20: and DSA22: are at the default priority level of 5000

In this example, when one of the systems fails, all shadow sets are put into a merge-required state. After the significant-event recovery delay time elapses, this system evaluates the shadow sets, and the operations are performed in the following order:

1. A minimerge operation starts first on DSA20, even though its priority of 5000 is lower than DSA1's priority of 7000. A minimerge operation always takes precedence over other operations. DSA20 and DSA42 are both minimerge enabled, but DSA20's higher priority causes its minimerge operation to start first.
2. A minimerge operation starts on DSA42. Its priority of 3000 is the lowest of all the shadow sets, but a minimerge operation takes precedence over other operations.
3. Because there are no other minimerge capable units, DSA1, with a priority level of 7000, is selected to start a merge operation, and it runs to completion.
4. A merge operation starts on DSA22, the one remaining shadow set whose priority is the default value of 5000, and runs to completion.

A copy transient state can be predicted by the user because it is the result of direct user action. Therefore, a full copy operation caused by adding a device to a shadow set is not considered a significant event in the cluster. The copy operation is managed by the first system that has an available resource.

In the following example, assume there are four shadow sets, and the SHADOW_MAX COPY parameter on this system is equal to 1. Recall that the shadow sets that are not assigned a specific level will have a default priority level assigned.

For the following example, assume that:

• DSA1, DSA20, DSA22, and DSA42 are mounted on multiple systems.
• Only DSA42 is minimerge enabled.
• DSA22 is already in a full copy state being managed on this system.
• DSA1 has a priority level of 7000.
• DSA42 has a priority level of 3000.
• DSA20 has a priority level of 3000.
• DSA22 has a default priority level of 5000.

The user adds a device to DSA1. This is not a significant event, and this system will not interrupt the full copy operation of the DSA22 in favor of performing the DSA1 full copy operation.

To expand on this example, assume that a system fails (a significant event) before the copy operations have completed. All shadow sets will be put into a merge required state. Specifically, DSA1, DSA20, and DSA22 are put into a full merge state, and DSA42 is put into a minimerge state.

After the significant event recovery delay expires, this system begins to evaluate all the shadow sets in a transient state. The operations take place in the following order:

1. A minimerge operation starts on DSA42 and continues until completion. This operation takes priority over other operations, regardless of its priority level.
2. A copy operation starts on DSA1. The full merge operation is not started because a copy operation takes precedence over a full merge operation.
3. A merge operation is started and completed on DSA1.
4. A copy operation is started and completed on DSA22.
5. A merge operation is started and completed on DSA22.
6. A merge operation is started and completed on DSA20.

Thus, in this example, the priority level is used to direct the priority of merge and copy operations on this system.

6.12.8 Managing Transient States in Progress

SHADOW_MAX_COPY is a dynamic system parameter that governs the use of system resources by shadowing. Shadowing can be directed to immediately respond to changes in this parameter setting with the following DCL command:

$ SET SHADOW/EVALUATE=RESOURCES

This command stops all the current merge and copy operations on the system on which it is issued. It then restarts the work using the new value of SHADOW_MAX_COPY.

This command is also useful in other circumstances. For example, if a shadow set had a priority level of 0 or another low value, the SET SHADOW /PRIORITY=n command can be used to increase the value. Then, by using the /EVALUATE=RESOURCES qualifier, the priority of shadow sets in a transient state is reevaluated.

The /PRIORITY and /EVALUATE=RESOURCES command qualifiers can be used on the same command line.

When a significant event occurs, all of the SHADOW_MAX_COPY resources are applied. If the value of SHADOW_MAX_COPY is modified using the SYSGEN SET and WRITE ACTIVE commands, and then a SET SHADOW /EVALUATE=RESOURCES is issued, the new value of SHADOW_MAX_COPY has a direct and immediate affect.

To determine which system is controlling a transient operation, enter the following command:

$ SHOW SHADOW/ACTIVE DSAn:

To determine the priority values assigned to each shadow set, enter the following command:

$ SHOW SHADOW/BY_PRIORITY DSAn:

Table 6-1 summarizes the user-visible impact of transient state events from the viewpoint of a shadow set on one system in an OpenVMS Cluster system. For each type of transient state event, the effects on the shadow set, when a merge (full merge, HBMM, or controller minimerge) or copy (full or minicopy) operation was already underway, are listed. The terms Canceled, Restarted, Continued, and Suspended, described in the table key have the same meaning in this table as in Volume Shadowing for OpenVMS messages.

Note also the following characteristics of merge and copy operations:

• If both a merge and a copy are pending on a shadow set, the merge is done before the copy if and only if the merge is a minimerge. This applies to controller-based minimerges, host-based minimerges, full copies, and minicopies.
• If an event that specifies a delay occurs during the delay for some prior event, no additional delay is incurred. The merges or copies required for the current event are considered when the prior delay expires.
• If an event that specifies no delay occurs during the delay for some prior event, the merges or copies required for the "no delay" event are not considered until the prior delay expires.

Canceled---Operation is stopped so that it can be restarted or continued on any system that is eligible.
Restarted---Operation must start over again on the same system at LBN 0 when the operation is resumed.
Continued---Operation continues at the LBN where it left off when it was canceled or suspended.
Suspended---Operation is stopped such that the operation for that SS can be initiated, restarted, or continued only on the same system where the suspended operation was active.

This chapter provides an overview of the differences as well as considerations you should review before linking programs on OpenVMS I64 systems. Major topics include:

• Differences when linking on I64 systems as compared with linking on VAX and Alpha systems ( Section 7.1.1)
• New aspects of linking an image on OpenVMS I64 ( Section 7.1.2)
• New linker qualifiers and options ( Section 7.1.3, Section 7.1.4)
• New ways to use existing linker qualifiers and options ( Section 7.1.5)
• Expanded linker map file information for I64 ( Section 7.1.6)

For release notes on the linker, refer to the HP OpenVMS Version 8.2 Release Notes.

7.1 Linker Utility New Features

The purpose of the linker is to create images (that is, files that contain binary code and data). The linker ported to OpenVMS I64 is different from the linker on OpenVMS VAX and Alpha systems because it accepts OpenVMS I64 object files and produces OpenVMS I64 images. As on OpenVMS VAX and Alpha systems, the primary type of image created is an executable image. This image can be activated at the DCL command line by entering the RUN command.

The OpenVMS I64 Linker also creates shareable images. A shareable image is a collection of procedures and data that are exported via the SYMBOL_VECTOR option that can be called by executable images or other shareable images. Shareable images are included in an input file via a link operation that creates an executable or shareable image.

When linking modules, the primary type of input file to the OpenVMS I64 Linker is the object file. Object files are produced by language processors such as compilers or assemblers. Because the object files produced by these compilers are unique to the Intel® Itanium® architecture, some aspects of linking modules on OpenVMS I64 systems are different from linking on VAX and Alpha systems. Overall, however, the OpenVMS I64 Linker interface as well as functional capabilities (for example, symbol resolution, virtual memory allocation, and image initialization) are similar to those on OpenVMS VAX and Alpha systems.

7.1.1 Differences When Linking on OpenVMS I64 Systems

Although linking on OpenVMS I64 systems is similar to linking on OpenVMS Alpha systems, some differences exist. The following qualifiers or options are ignored by the OpenVMS I64 linker:

• /REPLACE
• /SECTION_BINDING
• /HEADER
• PER_PAGE---The per_page keyword in /DEMAND_ZERO=PER_PAGE (the per_page keyword will be supported in a future release, although with a slightly different meaning)
• DZRO_MIN
• ISD_MAX

The following qualifiers and options are not allowed by the OpenVMS I64 Linker:

• /SYSTEM
• A file spec keyword with the /DEBUG= qualifier
• The base address must be null in CLUSTER=cluster_name,base_address...
• BASE=
• UNIVERSAL=

The following list contains new qualifiers that are supported by the OpenVMS I64 Linker:

• /BASE_ADDRESS
• /SEGMENT_ATTRIBUTE
• /FP_MODE
• /EXPORT_SYMBOL_VECTOR
• /PUBLISH_GLOBAL_SYMBOLS
• The GROUP_SECTIONS and SECTION_DETAILS keywords for the /FULL qualifier

These qualifiers and options are described in the following sections.

7.1.1.1 Data Types of Symbols must Match on I64

On OpenVMS Alpha, there can be a symbol that is defined as a piece of data but referenced as if it were a function. There is no way, using the Alpha object language, that this situation can be detected by the linker.

But on OpenVMS I64, the linker can detect a symbol's data type mismatch. The OpenVMS I64 linker receives information which marks a symbol as a function (FUNC), a piece of data (OBJECT) or unknown (NOTYPE). It also receives relocations which tell the linker when to create a function descriptor for symbols that are defined or referenced as a function.

If the types of a symbol are not unknown (not NOTYPE), they must match. If the definer sets the type as unknown, the referencer type cannot be a function.

For example, take the two modules FIRST.C and SECOND.C:

FIRST.C

#include <stdio.h>

int a;
int aa;
extern int second ();


void main () {

        printf ("The address of 'a'  is %x\n", &a);
        printf ("The address of 'aa' is %x\n", &aa);
        second ();
}

SECOND.C

#include <stdio.h>

extern int a();
extern int aa();

void second () {

        printf ("The address of 'a'  is %x\n", &a);
        printf ("The address of 'aa' is %x\n", &aa);
}

When you link FIRST and SECOND, you get the following informational messages (based on the symbol descriptors) and warning messages (based on the relocations) from the linker:

$ link first,second
%ILINK-I-DIFTYPE, symbol AA of type OBJECT cannot be referenced as type FUNC
        module: SECOND
        file: DISK$USER:[JOE]SECOND.OBJ;5
%ILINK-I-DIFTYPE, symbol A of type OBJECT cannot be referenced as type FUNC
        module: SECOND
        file: DISK$USER:[JOE]SECOND.OBJ;5
%ILINK-W-RELODIFTYPE, relocation requests the linker to build a function
descriptor for a non-function type of symbol
        symbol: A
        relocation section: .rela$CODE$ (section header entry: 19)
        relocation type: RELA$K_R_IA_64_LTOFF_FPTR22
        relocation entry: 1
        module: SECOND
        file: DISK$USER:[JOE]SECOND.OBJ;5
%ILINK-W-RELODIFTYPE, relocation requests the linker to build a function
descriptor for a non-function type of symbol
        symbol: AA
        relocation section: .rela$CODE$ (section header entry: 19)
        relocation type: RELA$K_R_IA_64_LTOFF_FPTR22
        relocation entry: 4
        module: SECOND
        file: DISK$USER:[JOE]SECOND.OBJ;5

To eliminate these informational and warning messages, change the type of the symbols "A" and "AA" to be a function or a piece of data. For example, change the declarations in FIRST.C to functions:

#include <stdio.h>

int a();
int aa();
extern int second ();


void main () {

        printf ("The address of 'a'  is %x\n", &a);
        printf ("The address of 'aa' is %x\n", &aa);
        second ();
}

int a () {
        return 1;
}

int aa () {
        return 1;
}

After this change, your link will be free of informationals and warnings:

$ link first,second
$

Another alternative is to change the references to "A" and "AA" in SECOND to be references to data.