HP Object Code Accelerator Manual

OCA and NonStop Debugging Tools

Contents 7. Debugging OCA Programs

STRIP

6-2

OCA and TNSVU

6-3

OCA and Accelerator

6-3

6-4

OCA and EPTRACE

6-4

7. Debugging OCA Programs

Differences Between Debugging TNS and Accelerated Programs

7-1

7-2

Memory-Exact Points

7-2

Nonexact Points

7-2

A Strategy for Debugging

7-2

A. Data Type Correspondence and Return Value Sizes

Figures

Figure 1-1.

The Acceleration Process

1-1

Figure 1-2.

User Program Execution Modes on TNS/E Systems

1-2

Figure 1-3.

Comparing TNS and Accelerated Object File Sizes Without a Symbols

Region

1-3

Figure 1-4.

Comparing TNS and Accelerated Object File Sizes Without a Symbols

Region

1-4

Figure 3-1.

Passing Parameters in Registers

3-6

Figure 4-1.

OCA Online Help Example

4-5

Figure 6-1.

Translating using the Accelerator and OCA

6-3

Figure 6-2.

Translating using OCA and the Accelerator

6-4

Tables

TNS Misalignment Handling Methods

2-15

OCA Options

5-2

Integer Types, Part 1

A-2

Integer Types, Part 2

A-3

Floating, Fixed, and Complex Types

A-3

Structured, Logical, Set, and File Types

iii

Contents

Tables (continued)

A-4

A-4

Pointer Types

A-5

Tables (continued)

What’s New in This Manual

Manual Information

Object Code Accelerator Manual

Abstract

This manual describes how to use the Object Code Accelerator (OCA) to optimize TNS object code for HP TNS/E systems. OCA processes files for the Guardian environment.

Product Version

N/A

Supported Release Version Updates (RVUs)

This publication supports G06.27 and all subsequent G-series RVUs, and H06.03 and all subsequent H-series RVUs until otherwise indicated by its replacement publication.

Part Number

528144-003

Published

September 2005

Document History

Part Number

528144-001

528144-002

528144-003

Product Version

Published

April 2005

July 2005

September 2005

New and Changed Information

This edition of the manual supports the release of the Object Code Accelerator (OCA) on G-series systems.

Section 2, Preparing Your Program for TNS/E Systems

About This Manual

OCA allows you to improve the performance of programs that run on TNS/E systems.

OCA optimizes TNS programs to take advantage of the TNS/E architecture and processes TNS object files to produce accelerated object files.

Most TNS object code that has been accelerated runs faster on TNS/E systems than

TNS object code that has not been accelerated. Most programs written for TNS systems do not require changes to run on TNS/E systems, either with or without acceleration.

The OCA Manual describes:

•

How OCA works and how to determine which programs to accelerate

•

The changes that you must make to run your TNS object on TNS/E systems; most of these changes only affect low-level TAL programs

•

The changes that you must make to your TNS object code before processing it with OCA

•

OCA syntax and command options

•

How to set OCA options to eliminate certain variances

Audience

This manual is intended for systems and applications programmers familiar with HP systems, the HP NonStop operating system, and the source languages of the programs to be accelerated. The manual contains all the information needed to use

OCA.

How to Use This Manual

The following table guides you to the sections you should read, depending on what tasks you want to perform:

If you want to:

Run a TNS program on a TNS/E system

Accelerate a TNS program

Read the following sections:

Section 1, Introduction

Section 2, Preparing Your Program for TNS/E Systems

Section 3, Preparing Programs for Acceleration

Section 4, Using OCA

Section 5, OCA Syntax and Option Summary

Section 6, Using OCA with Other NonStop Tools

Debug an accelerated program

Section 7, Debugging OCA Programs

Understand errors and warning messages

Section 8, Error and Warning Messages

About This Manual Notation Conventions

Notation Conventions

Hypertext Links

Blue underline is used to indicate a hypertext link within text. By clicking a passage of text with a blue underline, you are taken to the location described. For example:

This requirement is described under Backup DAM Volumes and Physical Disk

Drives on page 3-2.

General Syntax Notation

This list summarizes the notation conventions for syntax presentation in this manual.

UPPERCASE LETTERS. Uppercase letters indicate keywords and reserved words. Type these items exactly as shown. Items not enclosed in brackets are required. For example:

MAXATTACH

lowercase italic letters. Lowercase italic letters indicate variable items that you supply.

Items not enclosed in brackets are required. For example:

file-name

computer type.

Computer type

letters within text indicate C and Open System Services

(OSS) keywords and reserved words. Type these items exactly as shown. Items not enclosed in brackets are required. For example: myfile.c

italic computer type.

Italic computer type

letters within text indicate C and Open

System Services (OSS) variable items that you supply. Items not enclosed in brackets are required. For example:

pathname

[ ] Brackets. Brackets enclose optional syntax items. For example:

TERM [\system-name.]$terminal-name

INT[ERRUPTS]

A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list can be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example:

FC [ num ]

[ -num ]

[ text ]

K [ X | D ] address

vii

About This Manual General Syntax Notation

{ } Braces. A group of items enclosed in braces is a list from which you are required to choose one item. The items in the list can be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example:

LISTOPENS PROCESS { $appl-mgr-name }

{ $process-name }

ALLOWSU { ON | OFF }

| Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example:

INSPECT { OFF | ON | SAVEABEND }

… Ellipsis. An ellipsis immediately following a pair of brackets or braces indicates that you can repeat the enclosed sequence of syntax items any number of times. For example:

M address [ , new-value ]

…

[ - ] {0|1|2|3|4|5|6|7|8|9}

…

An ellipsis immediately following a single syntax item indicates that you can repeat that syntax item any number of times. For example:

"s-char

…

Punctuation. Parentheses, commas, semicolons, and other symbols not previously described must be typed as shown. For example:

error := NEXTFILENAME ( file-name ) ;

LISTOPENS SU $process-name.#su-name

Quotation marks around a symbol such as a bracket or brace indicate the symbol is a required character that you must type as shown. For example:

"[" repetition-constant-list "]"

Item Spacing. Spaces shown between items are required unless one of the items is a punctuation symbol such as a parenthesis or a comma. For example:

CALL STEPMOM ( process-id ) ;

If there is no space between two items, spaces are not permitted. In this example, no spaces are permitted between the period and any other items:

$process-name.#su-name

Line Spacing. If the syntax of a command is too long to fit on a single line, each continuation line is indented three spaces and is separated from the preceding line by

viii

About This Manual Notation for Messages a blank line. This spacing distinguishes items in a continuation line from items in a vertical list of selections. For example:

ALTER [ / OUT file-spec / ] LINE

[ , attribute-spec ]

…

!i and !o. In procedure calls, the !i notation follows an input parameter (one that passes data to the called procedure); the !o notation follows an output parameter (one that returns data to the calling program). For example:

CALL CHECKRESIZESEGMENT ( segment-id !i

, error ) ; !o

!i,o. In procedure calls, the !i,o notation follows an input/output parameter (one that both passes data to the called procedure and returns data to the calling program). For example:

error := COMPRESSEDIT ( filenum ) ; !i,o

!i:i.

In procedure calls, the !i:i notation follows an input string parameter that has a corresponding parameter specifying the length of the string in bytes. For example:

error := FILENAME_COMPARE_ ( filename1:length !i:i

, filename2:length ) ; !i:i

!o:i. In procedure calls, the !o:i notation follows an output buffer parameter that has a corresponding input parameter specifying the maximum length of the output buffer in bytes. For example:

error := FILE_GETINFO_ ( filenum !i

, [ filename:maxlen ] ) ; !o:i

Notation for Messages

This list summarizes the notation conventions for the presentation of displayed messages in this manual.

Bold Text. Bold text in an example indicates user input typed at the terminal. For example:

ENTER RUN CODE

?123

CODE RECEIVED: 123.00

The user must press the Return key after typing the input.

Nonitalic text. Nonitalic letters, numbers, and punctuation indicate text that is displayed or returned exactly as shown. For example:

Backup Up.

About This Manual Notation for Management Programming Interfaces

lowercase italic letters. Lowercase italic letters indicate variable items whose values are displayed or returned. For example:

p-register process-name

[ ] Brackets. Brackets enclose items that are sometimes, but not always, displayed. For example:

Event number = number [ Subject = first-subject-value ]

A group of items enclosed in brackets is a list of all possible items that can be displayed, of which one or none might actually be displayed. The items in the list can be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example:

proc-name trapped [ in SQL | in SQL file system ]

{ } Braces. A group of items enclosed in braces is a list of all possible items that can be displayed, of which one is actually displayed. The items in the list can be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example:

obj-type obj-name state changed to state, caused by

{ Object | Operator | Service }

process-name State changed from old-objstate to objstate

{ Operator Request. }

{ Unknown. }

| Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example:

Transfer status: { OK | Failed }

% Percent Sign. A percent sign precedes a number that is not in decimal notation. The

% notation precedes an octal number. The %B notation precedes a binary number.

The %H notation precedes a hexadecimal number. For example:

%005400

%B101111

%H2F

P=%p-register E=%e-register

Notation for Management Programming Interfaces

This list summarizes the notation conventions used in the boxed descriptions of programmatic commands, event messages, and error lists in this manual.

About This Manual Change Bar Notation

UPPERCASE LETTERS. Uppercase letters indicate names from definition files. Type these names exactly as shown. For example:

ZCOM-TKN-SUBJ-SERV

lowercase letters. Words in lowercase letters are words that are part of the notation, including Data Definition Language (DDL) keywords. For example: token-type

!r.

The !r notation following a token or field name indicates that the token or field is required. For example:

ZCOM-TKN-OBJNAME token-type ZSPI-TYP-STRING. !r

!o.

The !o notation following a token or field name indicates that the token or field is optional. For example:

ZSPI-TKN-MANAGER token-type ZSPI-TYP-FNAME32. !o

Change Bar Notation

Change bars are used to indicate substantive differences between this manual and its preceding version. Change bars are vertical rules placed in the right margin of changed portions of text, figures, tables, examples, and so on. Change bars highlight new or revised information. For example:

The message types specified in the REPORT clause are different in the COBOL85 environment and the Common Run-Time Environment (CRE).

The CRE has many new message types and some new message type codes for old message types. In the CRE, the message type SYSTEM includes all messages except LOGICAL-CLOSE and LOGICAL-OPEN.

Figure 1-1, The Acceleration Process, on page 1-1 illustrates the acceleration process.

Introduction

OCA processes TNS object code to produce accelerated object code. On TNS/E systems, accelerated object code runs significantly faster than TNS object code. This section describes how OCA works, how to determine which programs to accelerate, and the cost in time and space to accelerate your programs.

How the Object Code Accelerator (OCA) Works

OCA takes as input an executable TNS object file and produces as output an accelerated object file. The accelerated object file contains both the original TNS code and the logically equivalent optimized Itanium instructions (accelerated object code).

Figure 1-1. The Acceleration Process

TNS

Compiler

TNS Object File

TNS

Object Code

OCA

Accelerated Object File

TNS

Object Code

Accelerated

Object Code

VST0101.vsd

OCA produces for each TNS instruction its functional equivalent on the TNS/E system, in the form of either:

•

A sequence of zero or more (usually more than one) Itanium instructions

•

A call on a millicode routine

In the first and more common case, OCA treats a TNS instruction as though it were a macro instruction, expanding it into Itanium instructions. In the second, OCA treats a

TNS instruction as though it were a call on a closed subroutine, referred to as a millicode routine. Millicode routines are sets of Itanium instructions that implement various complex TNS instructions and low-level functions such as exception handling, real-time translation routines, and floating-point and quad arithmetic. Millicode is functionally equivalent to TNS microcode.

OCA can produce only optimized Itanium instructions for TNS instruction sequences whose exact meaning can be determined before runtime. In cases where the exact meaning cannot be determined until run time, the program makes a transition into TNS code and executes the original TNS instructions.

Figure 1-2, User Program Execution Modes on TNS/E Systems, on page 1-2 shows

1 -1

Introduction How the Object Code Accelerator (OCA) Works

two of the execution modes available to user programs on TNS/E systems: TNS mode and accelerated mode.

•

TNS mode is the operational environment in which TNS instructions execute. On

TNS/E systems, TNS instructions are implemented by millicode routines.

•

Accelerated mode is the operational environment in which Itanium instructions generated by OCA execute. On TNS/E systems, Itanium instructions execute directly on the Itanium processor.

Figure 1-2. User Program Execution Modes on TNS/E Systems

TNS Object File

Accelerated Object File

TNS

Object Code

TNS

Object Code

Accelerated

Object Code

TNS

Instructions

TNS

Instructions

Itanium

Instructions

Millicode

Itanium

Instructions

TNS/E Processor

VST0102.vdd

OCA runs on TNS/R and TNS/E systems, and produces the same output in both environments: a file containing both the original TNS/R code and its Itanium code equivalent. Accelerated object files can run on both TNS/R and TNS/E systems, although TNS/R systems ignore the Itanium code.

OCA can process bound, executable object programs generated by B40 and later releases of the C, COBOL85, FORTRAN, Pascal, and TAL compilers. OCA processes executable object programs that run only in the Guardian environment. (You cannot accelerate object programs generated by the COBOL 74 compiler.)

OCA ENABLE OFF command to disable inadvertent acceleration. See OCA and

1 -2

Introduction OCA Translation Mode

OCA Translation Mode

You explicitly accelerate your TNS program as part of the build or install process.When you explicitly accelerate your program in this way, you are immediately alerted of any error conditions.

If you do not want to accelerate a TNS object file, you can use the Binder CHANGE

Binder on page 6-1 for further information about Binder commands that work with OCA

and the Binder Manual.

Usage Consideration

•

If a program calls a user library and that library is not already accelerated, procedures in that library execute in TNS mode.

OCA Resource Requirements

OCA, like an optimizing compiler, is both CPU-intensive and memory-intensive. Try to run OCA on a lightly loaded processor with more than 16MB of physical memory. OCA uses large amounts of the extended segment heap area (about 135 KB per 1000 TNS instructions). Much of this virtual memory must remain in physical memory to avoid page faults that slow OCA. Accelerating large programs on processors with less than

16MB of physical memory can lead to unacceptable performance.

Accelerated object files require more disk space and memory space than TNS object files.

Figure 1-3, Comparing TNS and Accelerated Object File Sizes Without a Symbols

Region, on page 1-3 shows that an accelerated object file, without a symbols region,

requires about twice as much disk storage space as the corresponding TNS object file.

Figure 1-3. Comparing TNS and Accelerated Object File Sizes Without a

Symbols Region

TNS Object Code

Binder Region

Accelerated

Object Code

VST0103.vdd

Figure 1-4, Comparing TNS and Accelerated Object File Sizes Without a Symbols

1 -3

Introduction OCA Resource Requirements

Region, on page 1-4 shows that an accelerated object file, with a symbols region,

requires about 25 percent more disk storage space than the corresponding TNS object file. You can strip the symbols region from the accelerated program without affecting performance. However, accelerate the TNS object file with the symbols region and then strip the symbols region. OCA produces more efficient code from source TNS object files that contain a symbols region than those without the region.

Figure 1-4. Comparing TNS and Accelerated Object File Sizes Without a

Symbols Region

TNS Object Code

Binder Region

Symbols Region

Accelerated

Object Code

VST0103.vdd

The inline code expansion factor measures the worst-case increase in main memory required for accelerated code; the typical increase is less. It is the number of bytes of

Itanium code divided by the number of bytes of TNS code. Itanium instructions are 32 bits and TNS instructions are 16 bits; thus, a one-to-one instruction matching produces an inline expansion factor of 2. The OCA listing reports the inline code expansion factor.

The typical inline expansion factor in executable Itanium code compared to TNS code is 2 to 4 times. In one typical OLTP application, the code pages working set for the HPsupplied system code increased approximately 190 percent on a TNS/E as compared to a TNS system.

1 -4

Introduction Cross-Platform Acceleration

Cross-Platform Acceleration

OCA is supported on G-series, and H-series systems, enabling you to accelerate TNS object files on the TNS/E platform for execution on the TNS/E platform. (A file with a

TNS region only cannot be executed on the TNS/E platform). The TNS/R acceleration equivalent, Accelerator, is supported on G-series RVUs, enabling you to accelerate

TNS object files on the TNS/R platform for execution on the TNS/R platform. Having both accelerators available on both platforms enables you to use either the TNS/R or

TNS/E platform to create files that can be executed with improved performance on either platform.

General Considerations on page 2-1, discusses hardware and software release

1 -5

Preparing Your Program for

TNS/E Systems

Most TNS programs written for the HP NonStop operating system run on TNS/E systems without modification. Variances between TNS and TNS/E systems, however, might require modification in some programs, particularly low-level TAL programs.

This section steps you through:

•

issues that affect moving programs between any two different models of HP

NonStop systems.

•

Variances in TNS and Accelerated Code on page 2-4 discusses the changes you

must make to programs because of variances between TNS and TNS/E systems.

•

Data Alignment in TNS and Accelerated Code on page 2-13 discusses the data

alignment requirements for TNS code and the OCA. It also describes how to use the Misalignment Tracing Facility diagnostic tool.

General Considerations

This section discusses hardware and software release issues that affect moving programs between any two different models of HP NonStop systems. You must consider these issues when you prepare a program to run on TNS/E systems, whether or not you plan to accelerate the program. These issues include results after an overflow, checking segment limits, segment length, and supported operating system releases.

Results After an Overflow

Multiplication and division results after an overflow are undefined on all HP systems.

Each HP system generates different overflow results depending on the specific hardware and algorithms used for the operation. Do not depend upon overflow results being the same on TNS/E systems as they are on TNS systems.

All TNS instructions for integer multiplication and division operations (except the LMPY instruction) on TNS/E systems have undefined and incompatible TNS overflow results:

IDIV DDIV QDIV LDIV

IMPY DMPY QMPY

All TNS instructions for addition and subtraction operations and the LMPY instruction have compatible overflow results on all TNS and TNS/E systems:

IADD DADD QADD LMPY

ISUB DSUB QSUB

INEG DNEG QNEG

2 -1

Preparing Your Program for TNS/E Systems Checking Segment Limits

Detection Guideline

•

Examine source code that explicitly disables overflow traps to make sure it tests for arithmetic overflow with the $OVERFLOW function. Also look for user written trap handlers that return after an overflow. It is good coding practice always to test for overflow, not just after multiplication and division operations.

Required Changes

•

Programs that expect multiplication or division operations to overflow must explicitly test for overflow and establish the desired overflow answer. Programs can test for overflow by:

•

Using the TAL $OVERFLOW function or the COBOL85 ONSIZE error clause immediately after the arithmetic statement that might overflow

•

Examining the bits of the operands

•

Refer to the Guardian Programmer’s Guide for information on writing overflow traps handlers.

Example

The following TAL code explicitly tests for overflow.

FIXED(0) count, time, result;

CODE (RDE; ANRI %577; SETE); ! Disable overflow traps result := count * time;

IF $OVERFLOW THEN ! Test immediately for overflow result := 0D; ! Fix the overflow result

Checking Segment Limits

Erroneous programs which access memory beyond the logical end of a memory segment may fail differently and at different moments on TNS, TNS/R, and TNS/E systems, due to differences in memory page sizes. A segment's requested logical size, in bytes, is rounded up to a whole number of pages, where the page size depends on the host machine and NSK software release. Memory pages are 2Kbytes each on TNS

CISC systems, 4K or 16Kbytes on TNS/R systems, and 16K or 64Kbytes each on

TNS/E systems. Erroneous program references beyond the requested logical end of the segment, but before the actual end of that last memory page, will go undetected.

As a result of these differences, addressing past the logical end of segments may fail later or not at all depending on the system. You can notice this difference when debugging addressing errors.

Detection Guidelines

•

Addressing errors are reported as "illegal address reference" traps which are generally fatal. Earlier machines are stricter than newer machines and trap out on

2 -2

Preparing Your Program for TNS/E Systems Extended Segment Size more cases of bad addresses that are slightly too high, because of their smaller page sizes.

For example, the following figure shows a TNS/E system with an extended segment of

3.5 memory pages. On TNS/E systems, a program can reference data in addresses from the end of the allocated segment until the end of the memory page (area x between %h00083800 and %h00083FFF) without an exception.

Page

Addresses (%H)

00080000 - 00080FFF

00081000 - 00081FFF

00082000 - 00082FFF

4 x

00083000 - 000837FF

00083800 - 00083FFF

VST0201.vdd

Required Change

•

If your programs reference data beyond a segment’s logical limit, eliminate these references.

Extended Segment Size

The operating system now defines the maximum size of the "selectable" extended data segment at address 0x0008000 to be 127.5 MB (0x07F80000) on all systems.

Operating system releases before C30 defined the limit to be 128 MB. The

ALLOCATESEGMENT, SEGMENT_ALLOCATE_, and RESIZESEGMENT system procedures no longer allocate selectable segments larger than 127.5 MB.

These size limits do not apply to "flat" segments allocated at other addresses, a feature supported on TNS/R and TNS/E systems, but not on TNS CISC. The starting addresses dynamically assigned to flat segments may be different on TNS/R and

2 -3

Preparing Your Program for TNS/E Systems Variances in TNS and Accelerated Code

TNS/E, and the dynamic limits on flat segment sizes (due to other nearby segments) may be different on TNS/R and TNS/E.

Detection Guideline

•

If your programs allocate selectable segments larger than 127.5 MB, or a combination of flat segments larger than the program's own 31-bit address space allows, ALLOCATESEGMENT and SEGMENT_ALLOCATE_ return error -2.

Required Change

•

Change your programs to use the new maximum segment size if they allocate selectable segments larger than 127.5 MB.

•

Flat segments (at addresses other than 0x0008000 .. 0x07FFFFFF) have performance and size advantages over selectable segments (which must all timeshare the memory space at 0x0008000.. 0x07FFFFFF). For best performance, it is recommended (but not required) to convert selectable segments into flat segments with non-overlapping addresses, and eliminate the associated expensive frequent calls to USESEGMENT or SEGMENT_USE_. This is also recommended

(but not required) for native-mode programs.

Variances in TNS and Accelerated Code

This section describes the variances between TNS and TNS/E systems that apply to

TNS object code and accelerated object code. The majority of these variances affect programs with user-written trap handlers or TAL programs with CODE statements.

Additionally, these variances point out program bugs that can be detected on one system type and not on another. Check your programs for variances in:

•

Trap handlers that use the register stack

•

Trap handlers that use the P register

•

Reserved instructions

•

Passing the address of P-relative objects

•

Nonprivileged references to system global data

•

Stack wrapping

•

Odd-byte references

•

Shift instructions with dynamic shift counts

Trap Handlers That Use the Register Stack

During program execution, the trap mechanism handles all error and exception conditions not related to input or output. User-written trap handlers differ on TNS and

2 -4

Preparing Your Program for TNS/E Systems Trap Handlers That Use the Program Counter

TNS/E systems because the register stack contents are imprecise at the moment of a trap. (The register stack consists of registers R0 through R7.)

•

On TNS systems, trap handlers can be declared as functions (return a value to a caller) and they can modify the register stack.

•

On TNS/E systems, trap handlers cannot be declared as functions and they can reliably examine and change only certain registers. User-written trap handlers must not alter the register stack.

User-written trap handlers on TNS/E systems can:

•

Print error messages and abend

•

Clear overflow and resume

•

Resume after a loop timer

•

Put values into global variables

•

Jump to a restart point by changing the trap variables P, L, ENV, space ID, and S

•

Save the register stack with the usual code statement of:

CODE (PUSH %777); ! Save register stack contents

However, the contents of the register stack are imprecise at the moment of a trap for programs executing on TNS/E systems. The contents of the register stack might not be the same as on TNS systems.

Refer to the Guardian Programmer’s Guide for information on writing overflow traps.

Detection Guideline

•

Find trap handlers by looking for calls to the ARMTRAP system procedure with parameters (address of label, address of data area). The ARMTRAP procedure specifies an entry point into the application program where execution is to begin if a trap occurs. You do not need to change ARMTRAP procedures with parameters of (-1,-1). These parameters cause programs to abend on traps. Trap handlers are usually small enough in both size and number to check visually.

Required Change

•

Change your programs to comply with the preceding restrictions.

Trap Handlers That Use the Program Counter

The reported program counter register, P, is imprecise for all code. Do not rely on the value of P to determine program flow, to inspect the TNS instruction word which triggered the trap, or to calculate the target of a jump.

Trap Handlers That Use the Register Stack on page 2-4 for guidelines on

2 -5

Preparing Your Program for TNS/E Systems Reserved Instructions

You can change the P trap variable to a valid restart point such as a cleanup point in the outer block, but do not perform arithmetic on P. For example, the results of the following operations are undefined:

INT trap_p = 'L' - 2; ! Location of the P register trap_p := trap_p '+' 1; ! Undefined trap_p := trap_p '-' 1; ! Undefined

Refer to

writing trap handlers.

Detection Guideline

•

Find trap handlers by looking for calls to the system procedure ARMTRAP with parameters (address of label, address of data area). The ARMTRAP procedure specifies an entry point into the application program where execution is to begin if a trap occurs. You do not need to change ARMTRAP procedures with parameters of (-1,-1). These parameters cause programs to abend on traps. Trap handlers are usually small enough in both size and number to check visually.

Required Change

•

Change your programs to comply with the preceding restrictions.

Reserved Instructions

Two TNS instructions previously reserved for the operating system have changed from nonprivileged to privileged instructions on TNS/E systems:

TOTQ - Test the Out Queue

RCPU - Read Cpu Number

These instructions continue to be nonprivileged instructions on existing TNS systems;

HP reserves the right to change them to privileged instructions.

Detection Guideline

•

Programs that use these instructions in the nonprivileged environment fail with an

Instruction Failure exception.

Required Change

•

Remove these instructions from nonprivileged programs.

Passing the Addresses of P-Relative Objects

Do not pass the address of a P-relative object to other routines in programs larger than one TNS code segment. Programs access the wrong object or an address fault occurs if you pass a:

•

16-bit address on TNS systems

2 -6

Preparing Your Program for TNS/E Systems Nonprivileged References to System Global Data

•

16-bit address on TNS/E systems

•

32-bit extended address on TNS systems

However, if you pass a 32-bit extended address on TNS/E systems, programs access the specified object and continue execution. This is a program error that TNS/E systems do not detect.

Do not write programs that rely on this feature. There is one supported exception to this restriction: you can pass user code addresses into user library, system code, or system library routines.

Detection Guidelines

•

Look for statements that pass a 32-bit extended address of a P-relative object to other routines.

•

Run your program on a TNS system. If the program runs correctly, your code is correct.

Required Change

•

Recode statements that pass a 32-bit extended address of a P-relative object to other routines.

Nonprivileged References to System Global Data

Only privileged programs can access system global data. When a nonprivileged program references system global data, results differ depending on the system:

•

On TNS systems, the program accesses the user global data segment, G, instead.

•

On TNS/E systems, the program fails with an Instruction Failure exception.

Detection Guidelines

•

Use a text editor to search for ‘SG” in programs to locate potential variances.

•

TNS/E systems terminate nonprivileged references to SG with an Instruction

Failure exception.

Required Change

•

Remove references to SG variables from nonprivileged programs.

Example

The following TAL procedure tries to use the system value at address SG[0], but on a

TNS system, the procedure uses whatever is at address G[0] in the user data

2 -7

Preparing Your Program for TNS/E Systems Segment Wrapping segment. For more information on how to access the system data segment, refer to the section on privileged procedures in the TAL Reference Manual.

INT cpuno = 'SG' + 0; ! SG equivalencing

INT .EXT xcpuno; ! Extended pointer

PROCEDURE foo; ! Nonprivileged procedure

BEGIN

IF cpuno = 1 THEN ! TNS/E system traps

BEGIN ! TNS system accesses G[0]

! Lots of code

END;

@xcpuno := $XADR(cpuno);

IF xcpuno = 1 THEN ! TNS/E system traps

... ! TNS system accesses G[0]

END;

Segment Wrapping

If a nonprivileged program tries to allocate and operate on variables partially lying across the end of the user data segment, results might differ depending on the system:

•

On TNS systems, the variable reference wraps back to the base of the user data segment.

•

On TNS/E systems, the variable reference is unpredictable; it might wrap or trap.

Nonprivileged programs cannot access SG.

Required Change

•

Remove from your programs any constructs that result in segment wrapping.

Change addressing operations so that they stay fully within the segment.

Example

The following examples show addressing operations that might not wrap back on the segment on TNS/E systems as they do on TNS systems.

STRUCT s(*);

BEGIN

INT i;

INT(32) d;

INT j;

END;

PROC exam;

BEGIN

INT .p (s);

STRUCT s2(s);

@p := -1; ! -1 = 65535 (unsigned), structure starts at

! the last word of the user data segment and

! goes past the end

2 -8

Preparing Your Program for TNS/E Systems Odd-Byte References

s2 ':=' p FOR $LEN(s2) BYTES; ! On TNS/E systems,

p.d := %h12345678%d; ! these operations

p.j := 6; ! might wrap or trap

END;

The structure defined by P starts near the end of the user data segment and goes past the end. On TNS systems, this addressing operation wraps back to G[0], as shown by the dotted line in the following figure. On TNS/E systems, this addressing operation might wrap or trap.

G [0]

G [65535]

SG [0]

User Data Segment

(Relative Segment 0)

System Data Segment

(Relative Segment 1)

VST0202.vdd

Odd-Byte References

When a language compiler applies a TNS word instruction to an operand with an oddbyte address, run-time results are unpredictable. The instruction might do any, or any combination, of:

•

“Round down” the misaligned address (as the TNS CISC processors always did)

•

Use the misaligned address without rounding it down

•

Cause the instruction to fail

The TNS instruction’s misalignment behavior depends on:

•

Operand size (16-bit, 32-bit, or 64-bit)

•

Execution mode

In TNS mode or accelerated mode, the action also depends on:

TNS opcodes such as QCMP

Although 64-bit integers with odd-byte addresses usually are not rounded down, they can be—QCMP is one such example.

The SCF attribute TNSMISALIGN (see Misalignment Handling on page 2-15)

2 -9

Preparing Your Program for TNS/E Systems Odd-Byte References

Contextual optimizations

How the instruction's result is used by later instructions

•

The varying behaviors and symptoms that misalignment errors cause can be confusing, for the following reasons:

•

A source program can produce erroneous TNS object code that seems to execute correctly until you change the source program in an apparently innocent way.

•

The program might behave differently in TNS mode than it does in accelerated mode. (Neither mode is better at avoiding alignment problems.)

•

The debugger might display a different value for a variable than the program sees, because the debugger never “rounds down” addresses.

•

The program might “round down” addresses for storage operations but not for subsequent retrieval operations of the same misaligned operand (or the reverse).

TNS/E systems do not support the same odd-byte references to doublewords (4-byte units) or quadruplewords (8-byte units) as TNS systems do. Odd-byte references are made when the least significant bit (bit 31) of an extended pointer is set.

•

TNS systems ignore bit 31 of an extended pointer and fetch or store data starting from the byte prior to the addressed one to ensure that the address is on a word boundary. This behavior is probably not what you intended.

•

On TNS/E systems, odd-byte references to doublewords or quadruplewords are unpredictable; programs might trap or they might continue executing. Extended pointers to variables accessed as doublewords or quadruplewords must not have their least significant bit set. If your program was written following good TAL programming practices, odd-byte references are not a concern.

In TAL, data types stored as doublewords or quadruplewords include INT(32),

FIXED(n), REAL, REAL(64), and INT(64). In C, data types stored as doublewords or quadruplewords include long, unsigned long, long long, float, and double.

You can use the Misalignment Tracing Facility to detect if your programs are using misaligned pointers.This tool detects where in the program the misaligned pointers are located so you can change the program to avoid misalignment. See

Misalignment

Tracing Facility on page 2-13 for more information.

Odd-byte references to words (2-byte units) result in compatibility traps.

Detection Guidelines

•

Look for odd-byte references to doublewords or quadruplewords.

•

Look for uninitialized pointers. Many odd-byte references to doublewords and quadruplewords result from uninitialized pointers (previously undetected programming errors).

Table 2-1 on page 2-15). FAIL can be unsafe on production systems, but is

2- 10

Preparing Your Program for TNS/E Systems Shift Instructions With Dynamic Shift Counts

Required Change

•

Remove odd-byte references to doublewords and quadruplewords from your programs.

Recommended Changes

•

Use pointer conversions as recommended for the source code language so that

TNS word instructions are never applied to odd-byte addresses.

•

Set the system’s SCF attribute TNSMISALIGN to either FAIL or NOROUND (see

recommended on test systems.

•

Remove odd-byte references to words from your programs.

Examples

•

The results of the following program fragment are unpredictable on TNS/E systems.

REAL(64) .EXT RPTR;

STRING .EXT SPTR = RPTR; ! Same pointer as RPTR

@SPTR := @SPTR + 1d;

IF SPTR = 'Z' THEN ... ! OK

IF RPTR = 0.0L0 THEN ... ! Results are unpredictable

•

In the following example, an odd-byte address alignment error occurs on a TNS/E system because the program illegally references a nil pointer. The extended pointer P contains a byte address. When P is set to -1, the structure starts on an odd-byte boundary; therefore, the program might trap or it might continue executing.

STRUCT s(*);

BEGIN

INT i;

INT(32) d;

INT j;

END;

PROC test;

BEGIN

INT .EXT p(s);

@p:= -1d; ! "nil" 4-byte pointer to structure

p.d := %habcd1234%d; ! Results are unpredictable

END;

Shift Instructions With Dynamic Shift Counts

The implementation of TNS instructions for signed arithmetic and unsigned logical shifts with dynamic shift counts differs between TNS and TNS/E systems. This

2- 11

Preparing Your Program for TNS/E Systems Shift Instructions With Dynamic Shift Counts difference applies to both single-word (16-bit) and double-word (32-bit) shift instructions.

For single-word shift operations with dynamic shift counts:

•

TNS systems accept counts within the range of 0 to 255. Shift counts of 16 to 255 are treated as 16.

•

TNS/E systems counts within the range of 0 to 31. Shift counts of 16 to 31 are treated as 16. Shift counts greater than 31 give undefined results.

For double-word shift operations with dynamic shift counts:

•

TNS systems accept counts within the range of 0 to 255. Shift counts of 32 to 255 are treated as 32.

•

TNS/E systems accept counts within the range of 0 to 32,767. Shift counts greater than 32 are treated as 32.

Dynamic shift counts that fall outside the acceptable ranges give undefined results.

The ALS, LLS, ARS, and LRS instructions implement single-word shifts and the DALS,

DLLS, DARS, and DLRS instructions implement double-word shifts.

The TAL compiler generates these instructions for the bit-shift operators ('<<', '>>', <<, and >>) if the operand to the right of the operators is not a constant. These instructions can also be found in TAL CODE statements. Refer to the appropriate system description manual for more information about the TNS instruction set. Refer to the

TAL Reference Manual for details on TAL bit-shift operators.

Detection Guidelines

•

Use a text editor to search for ALS 0, LLS 0, ARS 0, and LRS 0 in TAL CODE statements. Make sure that the operands for these instructions do not use shift counts greater than 31.

•

Use a text editor to search for the TAL bit-shift operators: unsigned left and right shift ('<<' and '>>') and signed left and right shift (<< and >>). Make sure that in cases where the left operand is a 16-bit unit and the shift count is dynamic, the count is never greater than 31.

Required Change

•

Recode statements that use dynamic shift counts greater than 31.

Examples

In this example, the value of p is arithmetically shifted to the right 35 positions. The value of p differs on TNS and TNS/E systems.

INT p, nbits, q; ! INT variables p := -128;

2- 12

Preparing Your Program for TNS/E Systems Data Alignment in TNS and Accelerated Code nbits := 35; ! Shift value of 35-bits q := p >> nbits; ! On TNS systems,

! same as p >> 16, q = -1

! On TNS/E systems,

! same as p >> (35-32), q = -16

Data Alignment in TNS and Accelerated Code

This section describes the data alignment requirements for TNS code and the OCA. It also describes how to use the Misalignment Tracing Facility diagnostic tool.

On TNS systems, a word is 16 bits. The TNS instruction set includes data access instructions that use 32-bit byte addresses that must be even-byte aligned (that is, aligned 0 modulo 2) for correct operation. This requirement remains even after the

OCA translates TNS code into RISC code. In TNS mode and accelerated mode, addresses that are odd-byte aligned (that is, aligned 1 modulo 2) are called misaligned.

TNS processors consistently “round down” misaligned addresses (that is, they ignore the low-order bit).

TNS/E processors handle the misaligned addresses of TNS programs inconsistently, rounding down some but not others and behaving differently in TNS mode and accelerated mode. These problems do not occur in programs that follow all of the programming rules for TNS languages, but compilers cannot catch misaligned addresses that are computed at run time.

The behavior of TNS programs with misaligned addresses on TNS/E processors is almost impossible to predict. If you are not sure that your program has only aligned addresses, you can use the tracing facility to detect whether programs are using misaligned pointers, and if so, where. You should then change the programs to avoid misalignment.

In addition to the OCA, the data misalignment issue might affect the following HP compilers. If you use these compilers, see the appropriate data alignment addenda:

Compiler

TNS C

TNS C++

TNS c89

TNS COBOL85

TNS/R pTAL

TNS TAL

T Number Addendum

T9255 C/C++ Programmer’s Guide Data Alignment Addendum

T9541

T8629

T9257

T9248

T9250

COBOL85 Manual Data Alignment Addendum pTAL Reference Manual Data Alignment Addendum

TAL Programmer’s Guide Data Alignment Addendum

Misalignment Tracing Facility

The misalignment tracing facility is enabled or disabled on a system-wide basis (that is, for all processors in the node). By default, it is enabled (set to ON). It can be disabled

(set to OFF) only by the persons who configure the system, by means of the

2- 13

Preparing Your Program for TNS/E Systems Misalignment Tracing Facility

Subsystem Control Facility (SCF) attribute MISALIGNLOG. Instructions are in the SCF

Reference Manual for the Kernel Subsystem.

Note.

HP recommends that the MISALIGNLOG attribute be left ON (its default setting) so that any process that is subject to rounding of misaligned addresses will generate log entries, facilitating diagnosis and repair of the code. Only if the volume of misalignment events becomes burdensome should this attribute be turned OFF.

When a misaligned address causes an exception that RVUs prior to G06.17 would have rounded down, the tracing facility traces the exception.

Note.

The tracing facility does not count and trace every misaligned address, only those that cause round-down exceptions. Other accesses that use misaligned addresses without rounding them down do not cause exceptions and are not counted or traced. Also, only a periodic sample of the counted exceptions are traced by means of their own EMS event messages.

While a process runs, the tracing facility:

•

Counts the number of misaligned-address exceptions that the process causes (the exception count)

•

Records the program address and code-file name of the instruction that causes the first misaligned-address exception

Because a process can run for a long time, the tracing facility samples the process

(that is, checks its exception data) periodically (approximately once an hour). If the process recorded an exception since the previous sample, the tracing facility records an entry in the EMS log. If the process ends, and any exception has occurred since the last sample, the operating system produces a final Event Management Service (EMS) event.

The EMS event includes:

•

The process’s exception count

•

Details about one misaligned-address exception, including the program address, data address, and relevant code-file names

Sampling is short and infrequent enough to avoid flooding the EMS log, even for a continuous process with many misaligned-address exceptions. One sample logs a maximum of 100 events, and at most one event is logged for any process.

If misaligned-address exceptions occur in different periods of a process, the operating system produces multiple EMS events for the same process, and these EMS events might have different program addresses.

For more information about EMS events or the EMS log, see the EMS Reference

Manual.

Table 2-1 lists and describes the possible settings for TNSMISALIGN. Each setting

2- 14

Preparing Your Program for TNS/E Systems Misalignment Handling

Misalignment Handling

Misalignment handling is determined by the following SCF attributes, which are set system-wide (that is, for all processors in the node) by the persons who configure the system:

•

MISALIGNLOG

•

TNSMISALIGN

•

NATIVEATOMICMISALIGN (applies only to programs running in TNS/R native mode, and therefore, does not apply to the OCA)

MISALIGNLOG enables or disables the tracing facility.

TNSMISALIGN applies to all programs running in TNS mode or accelerated mode, but not to programs running in native mode.

represents a misalignment handling method. For more information about

TNSMISALIGN, see the SCF Reference Manual for the Kernel Subsystem.

Table 2-1. TNS Misalignment Handling Methods

Method

ROUND

(default)*

FAIL

Description

After rounding down a misaligned address, the system proceeds to access the address

Instead of rounding down a misaligned address and proceeding to access the target, the operating system considers the instruction to have failed.

For a Guardian process, this failure generates an Instruction Failure trap

(trap #1). By default, this trap causes the process to go into the debugger, but the program can specify other behavior (for example, process termination or calling a specified trap-handling procedure). For information about trap handling, see the Guardian Programmer’s Guide.

For an OSS process, this failure generates a SIGILL signal (signal #4). By default, this signal causes process termination, but the program can specify other behavior (for example, entering the debugger or calling a specified signal-handler procedure). The signal cannot be ignored. For information about signal handling, see the explanation of the sigaction()

function in the

Open System Services System Calls Reference Manual.

NOROUND The system uses the operand’s given odd address (not rounded down) to complete the operation. If the operation is an atomic operation, atomicity is no longer guaranteed.

* Use this method on production systems to avoid changing the semantics of old TNS programs. FAIL could cause possibly fatal Instruction Failure traps in faulty TNS programs. NOROUND might change the semantics of some faulty programs.

2- 15

Preparing Your Program for TNS/E Systems Misalignment Handling

The method that you choose does not apply to every misaligned address, only to those that would have been rounded down in RVUs prior to G06.17.

Note.

ROUND and NOROUND misalignment handling are both intended as temporary solutions, not as a substitute for changing your program to ensure that it has only aligned addresses.

Programs that depend on NOROUND misalignment handling cannot be safely migrated to all present and future HP NonStop operating system platforms or to systems configured with

ROUND or FAIL misalignment handling.

Programs that depend on ROUND misalignment handling cannot be safely migrated “as is” to future HP NonStop operating system platforms or to systems configured with NOROUND or

FAIL misalignment handling.

General Considerations on page 3-1, discusses software development issues that

2- 16

Preparing Programs for

Acceleration

Most TNS programs written since the C30 RVU of the operating system can be accelerated without modification. Variances between TNS and TNS/E systems that affect accelerated code only, however, might require modification in some programs, particularly low-level TAL programs.

This section shows you how to prepare your programs for acceleration by OCA:

•

significantly affect the performance of accelerated code.

•

Variances in Accelerated Code on page 3-2, discusses the changes you must

make to programs because of variances between TNS and TNS/E systems that apply only to accelerated object code.

It assumes that you have already prepared your programs for TNS/E systems, as described in

Section 2, Preparing Your Program for TNS/E Systems

General Considerations

The following software development issues significantly affect the performance of accelerated programs. Note that none of these issues is a variance.

Run-Time Libraries

The HP C/C++, HP COBOL85, HP FORTRAN, HP Pascal, TAL run-time libraries, and the Common Run-Time Environment (CRE) library, are configured as part of the system library on D-series, G-series, and H-series systems. These run-time library routines have already been accelerated for TNS/E systems. To save time in accelerating your programs and to produce the smallest possible accelerated object files, do not bind the run-time library routines into your programs. In particular, HP recommends that you do not bind COBOL85 run-time library routines into your

COBOL85 application programs. At process creation, the operating system resolves external references to run-time library routines.

You must continue to bind into programs that contain C/C++ routines the appropriate

C/C++ model-dependent library file, such as CLARGE or CWIDE. Refer to the C/C++

Programmer’s Guide for details.

User Libraries

When you accelerate your user library, supply the UL option.

Unlike Accelerator or AXCEL for TNS/R, OCA does not require the UserLib option when translating programs that use a user library.

3 -1

Preparing Programs for Acceleration C Function Prototypes

C Function Prototypes

The C/C++ compiler uses function prototypes to determine the return value size for calls to routines declared in separate modules or to routines declared later in the same module. If you do not specify a function protoype, the C/C++ compiler assumes the function returns an INT value. On the TNS architecture, the object code runs correctly if either the function returns an INT value or no value. OCA generates code that assumes that the function returns an INT value. In most cases, OCA can process object files compiled without C/C++ function prototypes, but the resulting accelerated object code is often inefficient and makes numerous transitions into executing TNS code. If possible, use C/C++ function prototypes for all of your C/C++ routines.

Binder and Inspect Symbols Regions

OCA uses information from the Binder region and the Inspect symbols region of an object file to help perform control-flow analysis and optimizations. It can process most files without this information, but the resulting accelerated object code is often inefficient and makes numerous transitions into executing TNS code. If possible, accelerate object files that contain the Binder and Inspect symbols regions. After accelerating a program, you can strip the symbols region from it without impacting performance.

Variances in Accelerated Code

This section describes the variances between TNS and TNS/E systems that apply to accelerated object code. Check your programs for variances in:

•

Trap handlers that use the ENV register

•

Passing parameters in registers

•

The arithmetic left-shift sign bit

•

Non-standard procedure call or return RP values

•

The relationship between the global and local data blocks

•

Procedure name conflicts

Trap Handlers Using the ENV Registers

The value of ENV.RP is undefined for accelerated programs. For compatibility with

TNS processors, your trap handlers must set ENV.RP to 7 if they resume execution from a trap to a global restart point.

The condition codes N, Z, and K are undefined for traps that occur when executing accelerated object code. Do not write trap handlers that:

•

Base their decisions on these register values

•

Resume to points that expect these register values to be valid

Trap Handlers That Use the Register Stack on page 2-4 for guidelines on

3 -2

Preparing Programs for Acceleration Passing Parameters in Registers

Refer to the

writing trap handlers.

Detection Guideline

•

Examine your programs to determine if their trap handlers comply with the preceding restrictions. Find trap handlers by looking for calls to the system procedure ARMTRAP with parameters (address of label, address of data area).

ARMTRAP specifies an entry point into the application program where execution is to begin if a trap occurs. You do not need to change ARMTRAP (-1,-1) procedures that cause programs to abend on traps. Trap handlers are usually small enough in both size and number to check visually.

Required Change

•

Change your programs to comply with the preceding restrictions.

Passing Parameters in Registers

When processing a TAL program, OCA assumes that only those registers that contain an explicit value to pass or return hold meaningful values for procedure calls and returns. Procedures can pass values implicitly using TNS registers with CODE and

STACK statements or the misuse of USE and DROP statements. A procedure inherits a register if it is passed a register by a calling procedure. A procedure returns a register if it returns a register to a calling procedure. To get a correctly accelerated program in these cases, you must use the INHERITSRn or RETURNSRn options to specify which registers are used to pass parameters to or from a specified procedure.

For a discussion of TNS registers, refer to the appropriate system description manual.

Detection Guidelines

•

OCA emits Warning 15 if it suspects that a procedure uses a register that is implicitly set by another procedure.

Warning 15: Procedure <proc-name> in file <filename> inherits a register <register-number>

Warning 15 can be a false warning if:

•

The calling procedure employs a use register and does not drop it before the call.

TAL USE and DROP statements are often used to optimize repetitive references to localized expressions or iteration variables.

•

The procedure is not written in TAL. (See Note below for C programs).

Figure 3-1 on page 3-6 shows the passing of parameters in registers coded with the

3 -3

Preparing Programs for Acceleration Passing Parameters in Registers

•

The procedure calls the Debug process.

Note.

The library function

CLIB^EXTFNAME^TO^INTFNAME contains an uninitialized register variable in C30 versions of the HP C library released before 01DEC90. When this is the case, OCA generates incorrect code; a program might cause a run-time trap or overwrite user variables.

To get a correctly accelerated program, you must do either a full or replacement bind of the library and then accelerate the program again. To do a replacement bind, enter the following commands in Binder:

1. ADD * FROM object-file

2. ADD CODE CLIB^EXTFNAME^TO^INTFNAME FROM C-library, DELETE

3. BUILD object-file

Required Changes

•

If a called procedure inherits registers from a calling procedure, you must use the

INHERITSR option to specify the registers that are passed by the calling procedure.

INHERITSRn procedure-name where n = 0, 1, 2, …, 7, (the register number) and procedure-name is the name of the called procedure.

OCA emits a warning for called procedures that might inherit registers.

•

If a called procedure returns registers to a calling procedure, you must use the

RETURNSRn option to specify the registers that are returned by the called procedure.

RETURNSRn procedure-name where n = 0, 1, 2, …, 7, (the register number) and procedure-name is the name of the called procedure.

Make sure you specify the correct procedure. OCA emits Warning 15 for calling procedures that might inherit registers that are returned from a procedure they call.

You must specify the called procedure in the ReturnsR option.

Note.

HP strongly recommends that you remove this coding practice from your programs because it will not be supported in future software releases.

Examples

USE statement. Procedures can also pass parameters in registers by using TAL CODE statements. For example, the following fragment ending a procedure leaves a value on the register stack, although RP implies that no value is returned.

PROC Q;

! Lots of code

3 -4

Preparing Programs for Acceleration Passing Parameters in Registers

CODE (LOAD L+3); ! Loads value on stack from data segment

CODE (STRP 7); ! Set RP=7, imply no value returned

CODE (EXIT);

When the PCAL instruction in the following fragment calls procedure Q, it uses the value left on the register stack.

CODE (PCAL Q);

CODE (STRP 0); ! Set RP=0, use value on stack

CODE (STOR L+4); ! Stores value on stack to data segment

OCA discards the LOAD L+3 instruction, unless you specify ReturnsR0 Q to tell the

OCA to preserve that value.

3 -5

Preparing Programs for Acceleration Arithmetic Left-Shift Sign Bit

Figure 3-1. Passing Parameters in Registers

Inherits Registers

Procedure Alpha passes a value in register 7 to procedure Beta. Procedure Beta assumes that it inherits one register. OCA emits Warning 15 for procedure Beta.

Specify "InheritsR7 Beta" to get a correctly accelerated program.

INT X;

PROC Alpha;

BEGIN

USE A;

A:=4;

CALL Beta;

END;

PROC Beta;

BEGIN

USE B;

X:=B;

END;

Returns Registers

Procedure Beta returns a value in register 7 to procedure Alpha. Procedure Alpha assumes that it inherits one register. OCA emits Warning 15 for procedure Alpha.

Specify "ReturnsR7 Beta" to get a correctly accelerated program.

INT X;

PROC Alpha;

BEGIN

CALL Beta;

USE A;

X:=A;

END;

PROC Beta;

BEGIN

USE B;

B:=4;

END;

VST0301.vdd

Arithmetic Left-Shift Sign Bit

In TNS object code (on both TNS and TNS/E processors), arithmetic left-shift operations preserve the existing sign bit and shift the remaining bits. The operation discards data shifted out from bit one. An arithmetic left-shift operation loses significant bits of the arithmetic value if it tries to change the sign bit (bit zero). This loss of significant bits is a kind of overflow, although the system never traps.

In accelerated object code, an arithmetic left-shift operation does not preserve the sign bit. Instead, bit zero is included in the bits being shifted. The results might differ from

3 -6

Preparing Programs for Acceleration Non-Standard Procedure Call or Return RP Values those of TNS object code, but only if an overflow occurs. It is unlikely that programs knowingly use left-shift operations that overflow.

Detection Guideline

•

Look for arithmetic left-shift operations that overflow.

Required Change

•

Remove arithmetic left-shift operations that overflow from your programs.

Example

In TNS object code, the value of I is 0, while in accelerated object code, I= %100000.

INT I;

I := %040000 << 1; ! Overflow in accelerated object code.

Non-Standard Procedure Call or Return RP Values

Procedures and subprocedures in TAL and C/C++ can return a different number of words in the register stack than the number declared in the routine’s source code. OCA determines the return value sizes for most of these procedures from information found in the Binder region and its control flow analysis. In some cases, OCA predicts the return value sizes and emits a run-time check to make sure its predictions are correct.

If OCA makes an incorrect prediction, the program makes a transition into TNS code at that point. OCA, however, does not determine or predict the return value size when the compiler-declared values in the Binder region conflict with OCA’s control flow analysis.

In these rare cases, you must tell OCA the size of the value returned by a procedure.

Required Changes

For TAL programs:

•

Recode your program. HP recommends that you remove this coding practice from your programs because it will not be supported in future software releases.

Change your programs to pass parameters using the proper TAL syntax, if possible. You can also use the RETURNVALSIZE option.

For C/C++ programs:

•

Recompile your C/C++ program if it contains functions that return the type “void *” and it was compiled with a version of the HP C/C++ compiler released prior to

01DEC90. You can also use the RETURNVALSIZE option.

•

Recompile your C/C++ program if it contains functions that return a struct by value and it was compiled with a version of the HP C/C++ compiler released prior to

15JUN91. You can also use the RETURNVALSIZE option.

For TAL or C programs:

3 -7

Preparing Programs for Acceleration Non-Standard Procedure Call or Return RP Values

•

Use the OCA RETURNVALSIZE option to specify the correct return values.

•

For procedures with one return value size, specify:

RETURNVALSIZE procedure-name value where procedure-name is the name of the procedure, and value is the number of 16-bit words returned by the procedure. Use this option for functions whose return values cannot be declared in TAL, such as 48-bit integers. You can also use this option for C functions that return the type “void *” or return a struct by value. Specify 1 word for NOXMEM (small-memory model) and 2 words for

XMEM (large-memory model).

•

For procedures with more than one possible return value size (depending on the exit taken from the procedure), specify:

RETURNVALSIZE procedure-name UNKNOWN where procedure-name is the name of the procedure, and UNKNOWN tells

OCA to check the return value size for each procedure call. Use this option for functions where the number of words returned is dependent upon run-time logic.

Examples

•

The declared size of a function (procedure or subprocedure) return result value in the Binder region must match the actual return size or OCA generates incorrect code. The following TAL procedure returns three words implicitly and two words explicitly.

INT(32) PROC foo; ! Actually returns INT48

BEGIN

INT tag;

INT(32) value;

STACK 1; ! Put value on stack when not defined

?RP=7 ! Lie to TAL, suppress warning

RETURN 2d; ! Defined return value, does not match

! value returned on the stack

END;

•

This shows how the TAL compiler view of the register stack differs from the actual run-time register stack. The TAL compiler believes that the register stack is empty

3 -8

Preparing Programs for Acceleration Non-Standard Procedure Call or Return RP Values after the RP directive, while at run time the hardware knows that a value is on the stack.

TAL compiler view of register stack at procedure return

Value

Run-time view of register stack at procedure return

Value

VST0302.vdd

The OCA option RETURNVALSIZE must be used for this procedure to return the three values correctly:

RETURNVALSIZE FOO 3

Function f returns the type “void *” in this C example. You must either recompile this program with a version of the C/C++ compiler released on or after 01DEC90 or specify a RETURNVALSIZE option.

void *f(void)

{

return((void *) 0);

} main()

{

char *cp;

cp = f();

}

Instead of recompiling, you can use the following RETURNVALSIZE option to produce a correctly accelerated program:

RETURNVALSIZE 'f' 2

•

This example shows a function that returns a struct by value. You must either recompile this program with a version of the C /C++ compiler released on or after

15JUN91 or specify a RETURNVALSIZE option.

#pragma runnable

#include <stdioh> nolist

#include <stdlibh> nolist struct TAG {

int I;

long L;

3 -9

Preparing Programs for Acceleration Relationship Between Global and Local Data Blocks

}; struct TAG Foo (void); /* function returns type TAG */ struct TAG Foo (void)

{

struct TAG *ATagStruct;

ATagStruct = (struct TAG *) malloc ( sizeof (struct TAG));

ATagStruct->I = 1;

ATagStruct->L = 2;

return *ATagStruct; /* by value */

} main ()

{

struct TAG TagStruct;

TagStruct = Foo();

printf ( "TagStruct is %d %ld, should be 1 2\n",

TagStruct.I, TagStruct.L);

}

Instead of recompiling, you can use the following RETURNVALSIZE option to produce a correctly accelerated program:

RETURNVALSIZE 'Foo' 2

Relationship Between Global and Local Data Blocks

Do not assume that global and local data blocks have the same relation to one another on TNS/E systems as they have on TNS systems. For example, on TNS systems it is possible to write TAL code that accesses local variables by indexing global variables.

On TNS/E systems, the indexed global variables might not be equivalent to local variables because of register optimization.

OCA does not detect when programs dangerously manipulate values between the global and local data blocks. The accelerated code might execute, but the results would be incorrect.

Required Change

•

You must remove this coding practice from all programs.

Example

•

In the following program, the global variable f, an integer, is accessed as an array in the local block of the program. OCA does not see the address of the array access, f[4], as equivalent to the variable c in the local data block.

INT f; ! Global variable

PROC Test MAIN;

3- 10

Preparing Programs for Acceleration Procedure Name Conflicts

BEGIN

INT a,b,c,d; ! Local variables

c := 1;

f[4] := c+100; ! Undefined on TNS/E systems

b := c+3;

END;

If you execute this program on a TNS system or as TNS code on a TNS/E system, b = 104 at the end of the procedure. If you accelerate this program and then execute it on a TNS/E system, b = 4.

Procedure Name Conflicts

A program can call several procedures of the same name, as long as each of the procedures resides in a different code space. For example, a program can call a system library procedure named File_Close_ and a user library procedure named

File_Close_. Each of these procedures can have a different return value size. OCA must determine the return value size for all procedures called by a program. When

OCA processes such a program, it resolves the name conflict in favor of the system library procedure. This can result in an incorrectly accelerated program. HP strongly recommends that you do not give your procedures names that conflict with system procedure names.

A Strategy for Using OCA on page 4-1 describes a strategy for using OCA.

3- 11

Using OCA

The OCA program processes TNS object code programs and produces accelerated object code programs. You can run OCA only from the Guardian environment; OCA does not support the Open System Services (OSS) environment. This section describes:

•

•

Invoking OCA on page 4-2 describes how to run OCA from the Guardian

environment.

•

Specifying the Code Space on page 4-3 describes the OCA options that affect the

code space in which a program runs.

•

Accelerating Programs With Embedded SQL on page 4-3 explains how to

accelerate user libraries and programs that contain embedded NonStop SQL/MP or SQL/MX statements.

•

Using Obey Files on page 4-4 explains how to use obey files with OCA.

•

OCA Listings on page 4-6 describes OCA listings.

•

Online Help on page 4-5 describes the OCA online help facility.

A Strategy for Using OCA

This basic strategy shows you how to accelerate a program that runs in user code space, does not contain embedded SQL statements, and does not contain TAL CODE statements. This strategy uses the default OCA option settings. The option settings provide the OCA with additional information about the program to be accelerated. For the vast majority of programs, the default settings for these options result in a correctly accelerated program. Either the options are concerned only with performance, or they can be set to the “wrong” value safely; that is, their misuse is detected and reported by the OCA, and can be corrected by setting the option and re-running OCA.

1. Make sure that your program does not contain any of the variances described in

Section 3, Preparing Programs for Acceleration or

Section 2, Preparing Your

Program for TNS/E Systems

of this manual.

2. Compile and bind your TNS object program. For optimum results, retain both the

Binder and Inspect symbols regions.

3. Debug the TNS version of your complete program.

4. Run OCA. If OCA issues an error message, it does not produce an output file.

Correct the error and re-run OCA.

5. Examine the OCA listing. If there are any warning messages, investigate each warning, and fix it if necessary. OCA issues warning messages to call your attention to possible problems. Refer to

Section 8, Error and Warning Messages

for cause, effect, and recovery information about warning messages.

Using Obey Files on page 4-4

4 -1

Using OCA Invoking OCA

6. Perform final testing on the accelerated program.

This is a quick and simple strategy for using OCA. The following table guides you to the appropriate sections to learn how to perform more advanced OCA tasks.

To:

Make it more convenient to accelerate a program

Accelerate a program with embedded SQL statements

Accelerate code that runs in user library, system code, or system library space

Refer to:

Accelerating Programs With Embedded SQL on page 4-3

Specifying the Code Space on page 4-3

Invoking OCA

OCA runs as a Guardian process in the Guardian environment. You can invoke OCA explicitly on D40 series and later releases using TNS/R and TNS/E NonStop servers.

When you invoke OCA from the command line it takes the name of a type-100 TNS object file as an argument. You can specify one or more OCA options on the command line, but these are optional. See

OCA Options on page 5-2 for a listing and description

of all OCA options. Once OCA translates a TNS object file, you can execute the accelerated type -100 file on an TNS/E system where it immediately executes at full speed.

The oca command invokes OCA from the Guardian environment.

oca [/ run-options/] input-file, [, oca-option-list] run-options is zero or more standard run-time options, as described in the TACL Reference

Manual. Each option keyword, along with any accompanying arguments, must be separated by a comma from the next.

input-file is the name of the file containing the TNS object program that the OCA is to process.

oca-option-list is zero or more OCA options. See

Section 5, OCA Syntax and Option Summary

for a detailed description of each option. Each option keyword, along with any accompanying arguments, must be separated by a comma from the next keyword.

Partially qualified pathnames are resolved using the current working directory. If you run the OCA using the gtacl

command, pathnames must be fully qualified. See

Section 5, OCA Syntax and Option Summary for instructions on how to invoke OCA

4 -2

Using OCA OCA Command Usage Examples

and a detailed description of each OCA option.

OCA Command Usage Examples

The following examples show how the OCA command is used:

•

OCA accelerates the object file myobj and generates an accelerated object file named myoca: oca myobj, OUTPUT_FILE myoca

•

OCA accelerates the object file test1, generates an accelerated object file named test2, and writes its listing to the file mylist: oca /OUT mylist/ test1, OUTPUT_FILE test2

Specifying the Code Space

A code space is a part of virtual memory reserved for user library code and system library code. For each code space, a compiler generates different code and places different restrictions on the run-time library and language features that can be used.

Refer to the appropriate language manuals for details.

You can specify to OCA whether an object file is to be run as user library (UL) or system library (SL). Use the option UL for user library and SL for system library. Note that user library code not identified as such to OCA cannot be used as a user library or a shared run-time library at execution time. See

Translating a System Library on page 5-3 and Translating a User Library on page 5-3 for more information.

Accelerating User Libraries and Shared Run-Time Libraries

To accelerate a user library or a shared run-time library, accelerate the TNS object file as user library code by specifying the UL option. In the following example, the TNS user library MyLib is accelerated and written to the MyLibAx file: oca MyLib, OUTPUT_FILE MyLibAx, UL

Accelerating Programs With Embedded SQL

To accelerate programs that contain embedded NonStop SQL/MP statements, you must perform the following steps in sequence:

1. Compile

2. Bind

3. Accelerate

4. SQLCOMP

If you reaccelerate a program, you must follow by rerunning SQLCOMP.

Obey File on page 5-4 for more information.

4 -3

Using OCA Using Obey Files

OCA outputs an accelerated object file that does not have the same file label as the input TNS object file. The file label contains the PROGID attribute that determines the ownership of an executing process for NonStop SQL/MP. OCA turns off the PROGID attribute of the accelerated object file. To set the PROGID value, use the SQL ALTER

PROGRAM statement or the Safeguard security subsystem interface. Refer to the

NonStop SQL/MP Reference Manual or the Safeguard Reference Manual for details.

Using Obey Files

In the Guardian environment, you can provide OCA options on the OCA command line itself, in a text file whose name is given as a command-line option, or both.

The text file is referred to as an obey file. An obey file can include any option that can be given on the command line, including other obey file invocations. Any number of obey files may be invoked within an OCA command.

You specify an obey file as a run-option within the slashes that optionally follow the keyword oca, as in this example: oca /in fred/ input-file, output_file output-file or in the

oca-options

list part of the command, following the semicolon: oca input-file, output_file output-file, obey fred

OCA resolves partially qualified pathnames using the current working directory.

Obey files can contain any number of OCA options. The list of options can be as long as you like, with any number of comma-separated options on each line. Options that take an indefinite number of arguments can be followed by a blank-separated list of such arguments. Each option, together with all its arguments, must appear in its entirety on a single line, and not be continued onto a following line. See

Specifying an

Comments

You can use comments in obey files to annotate the commands you specify to OCA.

(You cannot use comments on the OCA command line.) A comment can be on any line. This obey file also directs OCA to read more options from the obey file

MOREOPTS.

Example

•

The following example displays the contents of an obey file:

-- obey file fred

inheritscc MYPROC

obey moreopts -- get more options from file moreopts

4 -4

Using OCA Online Help

Online Help

To access the OCA online help facility, enter oca at a TACL prompt. This displays a brief summary of the OCA command syntax.

The following example illustrates the help text:.

Figure 4-1. OCA Online Help Example

>OCA

OCA - T0448H01 - 01Jan05 - (Dec 7 2004 11:27:33)

OCA Syntax Summary

oca [/run-options/] input-file [, option-list ]

input-file

is the name of a fully bound, runnable, type-100 TNS code file.

option-list

is one or more command line options:

[ { SL }

{ UL }

{ OUTPUT_FILE output-file }

{ IGNORE_IRn proc-name }

{ INHERITSRn proc-name }

{ IGNORE_CC proc-name }

{ INHERITSCC proc-name }

{ OBEY obey-file-name }

4 -5

Using OCA OCA Listings

OCA Listings

At each execution, OCA produces a listing that reports on the acceleration it has just performed. The following example shows a sample OCA listing:

OCA - T0448H01 - 01Jan05 - (Dec 7 2004 11:27:33)

Option summary:

INHERITSCC

48 TNS instruction words; 96 bytes

102 Itanium bundles; 1632 bytes

17.0 inline code expansion factor

2.12 Itanium bundles per TNS instruction

TNS file name: $GOLD.MYFILES.OBJECT

Binder region present

Symbols region not present

Mips region not present

Accelerated as User Code segment 0 though 0

0 Errors were detected

0 Warnings were issued

Accelerated file name: $GOLD.MYFILES.AOBJ

Accelerated for TNS/E on Dec 11 2004 15:19:14

Acceleration completed on Dec 11 2004 15:19:18

CPU Time 0:00:00.148

OCA Syntax on page 5-1 describes how to run OCA from the command line.

4 -6

OCA Syntax and Option

Summary

This section provides detailed information about using OCA on the command line and how you can use additional options to specify more advanced translation functions.

•

•

OCA Options on page 5-2 details and provides examples for using options that can

be placed in the [, oca-option-list] portion of the command line. Using additional oca options is not required.

OCA Syntax

To run OCA from the command line, use the following syntax model: oca [/ run-options/] input-file [, oca-option-list]

run-options

is one or more standard run-time options, as described in the TACL Reference

Manual. The most useful option for the oca command is:

•

OUT

file-name

, to specify to which file OCA is to write its listing. If no file is entered, the listing is written to the specified hometerm.

Each option keyword, along with any accompanying arguments, must be separated by a comma from the next.

input-file

is the name of the file containing the TNS object program that the OCA is to translate. The file must be fully bound, runnable, and of file code type 100 or 180.

The input file may have been previously accelerated; OCA ignores the TNS/R region of the TNS object file if one exists.

If you do not enter a OUTPUT_FILE name, OCA augments the input file with a new region that contains TNS/E instructions provided the existing file is secured so that the OCA invoker has permission to replace the existing file. When OCA augments an existing input file with TNS/E instructions, it updates the file’s timestamp. If OCA cannot augment an existing file, it tries to create a second file in the same subvolume with a name in the form “ZZZZnnnn” where n is a placeholder for a number. OCA displays this file in the listing if it needs to create this second file.

Options, on page 5-2. Each option keyword, along with any accompanying

5 -1

OCA Syntax and Option Summary OCA Options

oca-option-list

is one or more oca options, which are listed and described later in

Table 5-1, OCA

arguments, must be separated by a comma from the next keyword.

Note that you cannot use comments on the OCA command line. If you need to add

comments to any OCA command line options, use an obey file. See Specifying an

Obey File on page 5-4 for more information.

OCA Options

Table 5-1, OCA Options lists the OCA options and provides a quick overview for each

option. The rest of this section describes each option in detail. Note that:

•

Option keywords are not case-sensitive.

•

Guardian file names are not case-sensitive.

•

Procedure names are case-sensitive.

•

If you plan to supply a large number of options, it is convenient to use an obey file

See the obey command.

Table 5-1. OCA Options (page 1 of 2)

Option

Purpose

Explicitly accelerates the entire non-native portion of the system library

OUTPUT_FILE

<output filename>

OBEY <obey-

filename>

IGNORE_IRn

<proc-name>

Explicitly accelerates a user library

Specifies the output code file to a location that is different from the input code file location

Specifies the name of an obey file that OCA should read for further commands

See

Translating a

System Library on page 5-3

Translating a

User Library on page 5-3

Obey File on page 5-4

IGNORE_IRn on page 5-7

INHERITSRn

<proc-name>

IGNORE_CC

<proc-name>

Directs OCA to complete its translation without

issuing a warning when it encounters a procedure

that inherits a register

Directs OCA to complete its translation without issuing a warning when it encounters a register stack being used to implicitly pass a non-stack parameter to a procedure.

Directs OCA to complete its translation without

issuing a warning when it encounters a procedure

that inherits condition codes.

INHERITSRn on page 5-7

IGNORE_CC on page 5-7

issuing a warning when it determines a condition

5 -2

OCA Syntax and Option Summary Translating a System Library

Table 5-1. OCA Options (page 2 of 2)

Option

INHERITSCC

<proc-name>

RETURNSRn

RETURNVALSIZE

<proc-name> <n>

Purpose

Directs OCA to complete its translation without

code is passed into and used by the routine.

Tells OCA which TNS registers are used for implicitly passing parameters from the named procedure

Directs OCA to assume that the named procedure

returns the named number of 16-bit words as its

return value

See

INHERITSCC on page 5-8

Translating a System Library

In the TNS/E environment, the non-native portion of a system library is explicitly accelerated by the system building process. When you invoke OCA and specify the SL option, this identifies the code undergoing translation as the system library.

oca [/ run-options/] input-file, SL

OCA assumes if you do not use the SL option:

•

That a TNS object file that contains a main program is a user code file

•

That a TNS object file that does not contain a main programs is a user library file

SL Usage Considerations

•

OCA does not permit incremental module accelerations before binding them together. You must first use Binder to combine pieces of the system library before using OCA to accelerate the library.

•

Developers who build system library modules may perform trial accelerations using

OCA.

•

System library components do not require translation before OSBuild.

Translating a User Library

The UL option allows you to explicitly identify a file undergoing translation as a user library. Specifying the UL options directs OCA to suppress the warning that appears in the listing file when it finds an inferred user library.

oca [/ run-options/] input-file, UL

5 -3

OCA Syntax and Option Summary Specifying an Output File Name

UL Usage Considerations

•

If you do not supply the UL option, OCA interprets any ready-to-run object file containing no main program as a user library.

•

You can accelerate a user library explicitly without specifying the UL option.

Specifying an Output File Name

Use the OUTPUT_FILE option to specify an output code file name whose location is different from the input code file location. When you use the OUTPUT_FILE option,

OCA does not modify or replace the input-file unless the input-file name is the same as the output-file name.

oca [/ run-options/] input-file, OUTPUT_FILE output-file

output-file is the name of the file to which the OCA will write its output: that is, the accelerated object file.

input-file

and

output-file

can be the same. If you specify an output file that already exists, OCA attempts to delete it to make room for a file of the same name. If it cannot delete that older file, it creates a file with a name of the form “ZZZZnnnn” to use instead, and tells you in the listing that it did so.

Specifying an Obey File

You can specify additional command line options in a text file called an obey file and then specify the obey file on the OCA command line using the OBEY option. oca [/ run-options/] input-file, OBEY obey-file

obey-file-name

is the name of the text file that contains additional OCA command line options.

OBEY Usage Considerations

•

An obey file can contain any options that can appear on the command line, including a nested OBEY option and each obey file can contain an unlimited number of OCA options.

•

The list of options in an obey file can be as long as you need and contain any number of comma-separated options on each line. Each option and all of its arguments must appear on a single line; it may not be continued on a separate line.

•

You can insert comments into an obey file to annotate OCA commands. A comment can be on any line of an obey file, even if that line contains an option. A

5 -4

OCA Syntax and Option Summary Determining TNS Register Usage comment is defined as any string introduced by two dashed (--) and is terminated by the end of a line.

•

OCA does not recognize the TACL line continuation mark &.

Determining TNS Register Usage

The RETURNSRn option tells OCA which TNS registers are used for implicitly passing parameters from the named procedure.

oca [/ run-options/] input-file, RETURNSRn proc-name

RETURNSRn

where the value of n is one of each TNS data register that could be implicitly passing parameters from the named procedure. Values for RETURNSR are:

RETURNSR1, RETURNSR2, RETURNSR3, RETURNSR4, RETURNSR5,

RETURNSR6, or RETURNSR7.

proc-name

is a procedure name. Procedure names are case sensitive so specify a procedure name using the exact spelling and case as it appears in the Binder region of the object file. OCA error message display the exact spelling and case for a procedure.

Correcting a Function’s Return Values Size

The RETURNVALSIZE option corrects the misdirected value of RP so that program execution remains in accelerated mode. oca [/ run-options/] input-file, RETURNVALSIZE proc-name num-

bytes proc-name

is a procedure name. Procedure names are case-sensitive so specify a procedure name using the exact spelling and case as it appears in the Binder region of the object file. OCA error message display the exact spelling and case for a procedure.

num-bytes

is the named number of 16-bit words in the return value.

Diagnosing and Managing Register or Condition Code

Inheritance

In TAL programs you can use the USE, STACK, and CODE statements to write procedures that implicitly pass parameters in the TNS register stack. HP does not recommend this practice. If your programs do pass parameters in TNS registers, you

5 -5

OCA Syntax and Option Summary Diagnosing and Managing Register or Condition

Code Inheritance can use the INHERITSRn option to generate correct code, though it is best to modify the source code to eliminate this practice and then reaccelerate the program.

Diagnosing Register or Condition Code Inheritance

OCA can falsely warn of register or code condition inheritance. This can be because either:

•

The procedure calls DEBUG

•

The caller declares a USE variable that was declared, but has not yet been initialized at some procedure or supersedure call.

For example the following code sample contains an uninitialized USE variable that is not DROPped before a procedure call:

PROC fred;

BEGIN

USE i;

CALL do_something; i := jane

DROP i;

END;

Restructure the code sample to DROP or defer the USE variable before the call:

PROC fred;

BEGIN

USE i;

DROP i;

CALL do_something; i := jane

END;

•

If a code (RDE) statement appears to sample an as yet uninitialized ENV.NZ condition code, OCA can interpret this as a sampling of the caller’s condition code.

Managing Register or Code Condition Inheritance

OCA warns you if a procedure appears to use a CC or R0..R7 register value before the register is set by that procedure. If a Warning 15 or Warning 16 is displayed it could signify one of a few manageable conditions, including one where the procedure expects to “inherit” the register from a calling procedure. The following options help you manage conditions when OCA issues Warning 15 or 16. Warning 15 displays when

OCA detects that a register from the TNS register stack may hold an implicitly passed register value. Warning 16 displays when OCA detects that the condition codes may

5 -6

OCA Syntax and Option Summary Diagnosing and Managing Register or Condition

Code Inheritance be inherited from the calling procedure. These warnings appear rarely and may in fact not reflect register inheritance. Use the following options to suppress these warnings and allow OCA to complete translation.

IGNORE_IRn

If you determine that OCA is issuing Warning 15 falsely, use IGNORE_IRn to suppress further issuance of Warning 15 and allow OCA to complete procedure translation. oca [/ run-options/] input-file, IGNORE_IRn proc-name

IGNORE_IRn where the value of n is one of each TNS data register that could appear to be inherited. Values for IGNORE_IR are: IGNORE_IR0, IGNORE_IR1, IGNORE_IR2,

IGNORE_IR3, IGNORE_IR4, IGNORE_IR5, IGNORE_IR6, or IGNORE_IR7.

proc-name

IGNORE_CC

If you determine that OCA is issuing Warning 16 falsely, use IGNORE_CC to suppress further issuance of Warning 16 and allow OCA to complete procedure translation. oca [/ run-options/] input-file, IGNORE_CC proc-name

proc-name

INHERITSRn

Use the INHERITSRn option if you determine that OCA is issuing Warning 15 because a TNS register stack is being used to implicitly pass a non-stack parameter to the procedure. Note that Warning 15 is usually spurious and INHERITSR

should only be used when Warning 15 is not spurious.This option directs OCA to treat TNS stack register

as “live” on calls to the named procedure

It also suppresses further issuance of Warning 15 and allows OCA to complete procedure translation. oca [/ run-options/] input-file, INHERITSRn proc-name

5 -7

OCA Syntax and Option Summary Diagnosing and Managing Register or Condition

Code Inheritance

INHERITSRn

where the value of n applies to each register that is inherited. Values for

INHERITSR are: INHERITSR0, INHERITSR1, INHERITSR2, INHERITSR3,

INHERITSR4, INHERITSR5, INHERITSR6, or INHERITSR7.

proc-name

INHERITSCC

Use the INHERITSCC option if you determine that OCA is issuing Warning 16 because a condition code is passed into and used by the routine. Note that Warning 16 is usually spurious and INHERITSCC should only be used when Warning 16 is not spurious.This option directs OCA to treat the condition code (CC) as “live” on calls to the named procedure. It also suppresses further issuance of Warning 16 and allows

OCA to complete procedure translation. The option INHERITSCC_ON is a synonym for INHERITSCC.

oca [/ run-options/] input-file, INHERITSCC proc-name

proc-name

IGNORE_IRn, IGNORE_CC, INHERITSRn, and INHERITSCC Usage

Considerations

•

If you specify a procedure name that does not exist, OCA ignores the procedure and continues translating without generating a warning.

•

Procedures rarely expect arguments that are passed into TNS registers. Confirm that your procedure uses this calling convention and verify the exact spelling of the procedure name and the TNS register number.

•

Supply a valid INHERITSRn or INHERITSCC option to prevent additional false register inheritance warnings to display about the caller procedure and other procedures it calls.

•

OCA diagnoses the appearance of “inherited” registers with a warning assuming the condition is false unless an INHERITS_Rn option is supplied. The

IGNORE_IRn option suppresses this warning.

OCA and Binder on page 6-1

5 -8

Using OCA with Other NonStop

Tools

You can use OCA with other NonStop products that operate on TNS object files.

•

•

OCA and TNSVU on page 6-3

•

OCA and Accelerator on page 6-3

•

OCA and NonStop Debugging Tools on page 6-4

•

OCA and EPTRACE on page 6-4

OCA and Binder

OCA only processes fully bound ready-to-run TNS object files. When you use Binder with OCA, the Binder strips the TNS/E and TNS/R regions from a TNS object file and resets the OCA’s attributes in the TNS header, based on what Binder commands you use. See the Binder Manual for further information about how to use the Binder.

You can use the following Binder command with OCA-generated TNS object files:

•

CHANGE

•

SHOW

•

STRIP

CHANGE

The CHANGE command allows you to modify the attribute values of an existing TNS object file:

CHANGE OCA ENABLE [ON | OFF] IN filename

ENABLE controls whether or not OCA can process a file.

ON|OFF is the Binder default setting for OCA ENABLE is ON. OCA does not change the value of this attribute. When OCA ENABLE is set to OFF, OCA may not operate on the object file; file execution occurs in TNS mode.

6 -1

Using OCA with Other NonStop Tools SHOW

SHOW

The SHOW command displays the current values for the attributes of an existing TNS object file.

SHOW

{OCA ENABLE [FROM filename] }

{INFO [FROM filename] }

OCA ENABLE displays whether or not OCA can accelerate the TNS object file specified in the

FROM portion of this command.

INFO displays the attributes for the TNS object file specified in the FROM portion of this command. SHOW command output also displays OCA information when the program has been accelerated using OCA.

STRIP

The STRIP command allows you to selectively remove the Binder, Inspect, TNS/R, or

TNS/E regions from the named TNS object file. If you enter STRIP filename at the command line without any additional options, Binder strips only the Binder and

Symbols regions and retains the TNS/R and TNS/E (if any) regions in the file. If you specify the SYMBOLS, AXCEL, or OCA options, only those named attributes are removed from the file.

STRIP filename [, SYMBOLS | , AXCEL | , OCA] filename is the name of the TNS object file from which you want to remove the Binder,

Inspect, TNS/R or TNS/E region.

SYMBOLS removes the Inspect region from the TNS object file. The Inspect region contains debugger symbol tables from the TNS object file.

AXCEL removes the TNS/R region from the TNS object file. The TNS/R region contains

Accelerator-generated TNS/R code.

OCA removes the TNS/E region from the TNS object file, containing OCA-generated

TNS/E code.

6 -2

Using OCA with Other NonStop Tools OCA and TNSVU

OCA and TNSVU

TNSVU is an interactive tool that browses a static, type-100 TNS object file, including the TNS/E region generated by the Object Code Accelerator (OCA). Using TNSVU, you can display a variety of information about a file’s contents such as:

•

General or detailed information about one or more procedures

•

Names of millicode routines

•

Contents of the TNS or TNS/E headers

•

Names of system or library routines called

•

TNS and TNS/E instruction sequences

•

TNS instruction addresses and the TNS/E addresses of the equivalent TNS/E code sequences

See the TNSVU Manual for further information.

OCA and Accelerator

The Accelerator (AXCEL) processes TNS object files to produce accelerated object files. These accelerated objects run significantly faster on TNS/R systems than do plain TNS objects. The accelerated object file contains both the original TNS instructions and the logically equivalent optimized TNS/R instructions.

You can run OCA on a TNS object file that has already been accelerated using the

Accelerator (Axcel). OCA adds a new region (TNS/E region) to the object file. You can also accelerate a TNS object file using both OCA and the Accelerator in any order. The resultant object file runs accelerated on both TNS/R and TNS/E machines. For example, you can run OCA on a TNS object file that has previously been accelerated for the TNS/R environment using the Accelerator.

Figure 6-1. Translating using the Accelerator and OCA

TNS

Compiler

TNS

Object Code

Axcel

TNS

Object Code

Accelerated

Object Code

(RISC)

OCA

TNS

Object Code

Accelerated

Object Code

(RISC)

Accelerated

Object Code

(Itanium) vst0604.vsd

and rarely necessary. See Section 7, Debugging OCA Programs for further information

6 -3

Using OCA with Other NonStop Tools OCA and NonStop Debugging Tools

You can also run Accelerator on a TNS object file that has been previously accelerated for the TNS/E environment by OCA:

Figure 6-2. Translating using OCA and the Accelerator

TNS Compiler

and Binder

TNS Object

Code

OCA

Code

Accelerated

Object Code

(Itanium)

AXCEL

TNS

Object Code

Accelerated

Object Code

(RISC)

Accelerated vst0604.vsd

(Itanium)

See the H-Series Application Migration Guide for further information about using OCA and the Accelerator.

OCA and NonStop Debugging Tools

You can use either Visual Inspect or Native Inspect to debug programs accelerated by

OCA. Source-level (symbolic) debugging of accelerated programs is very similar to

TNS programs. However, machine-level debugging of accelerated programs is limited,

about using OCA with Visual Inspect and Native Inspect.

OCA and EPTRACE

EPTRACE is a performance investigation tool designed for the Guardian environment.

It reports detailed counts of trap events and provides a complete trace log of these events so you can locate, diagnose, and resolve all trap-causing locations in a program.

EPTRACE reports two types of information in the trace log:

•

Counters

Reports individual counters for each process, including interrupt processes.

The per-CPU totals equal the sum of all process counters.

•

Traces

6 -4

Using OCA with Other NonStop Tools OCA and EPTRACE

•

Locates particular events when you enable tracing. To report traces you must enable the tracing function using the SHOW command

•

EPTRACE reports these event trace items:

•

Current program name and PIN

•

Time

•

Event Type

•

Stumble subclass

•

Trapped program location (native IA-64 IP, TNS P and/or translated IA-64I

IP). Locations within system libraries are included, but not separately counted or separately traced.

•

Trapped operand addresses

Differences Between Debugging TNS and Accelerated Programs on page 7-1

6 -5

Debugging OCA Programs

You can use either Visual Inspect or Native Inspect to debug programs accelerated by

OCA. Source-level (symbolic) debugging of accelerated programs is very similar to

TNS programs. However, machine-level debugging of accelerated programs is limited, and rarely necessary.

When debugging accelerated programs, you do not need to be concerned about the

Itanium instructions into which OCA has converted your program, nor with the algorithms by which OCA has optimized your program.

This section describes:

•

•

A Strategy for Debugging on page 7-2

For a complete discussion of debugging TNS programs and accelerated programs on

TNS/R systems, refer to the Visual Inspect online help, the Inspect Manual, and the

Debug Manual.

Differences Between Debugging TNS and

Accelerated Programs

TNS/E technology uses hardware and software components to increase program performance. Hardware features that result in increased program performance include the pipelining of instructions, which allows multiple instructions to be executed in parallel, and an increased number of general purpose registers. OCA optimizes program performance for TNS/E systems by reordering instructions to achieve optimal program performance.

Both the hardware features of native systems and the optimizations performed by OCA might result in some debugging and execution differences when compared with execution on TNS systems. The primary debugging difference for accelerated programs is that at some points, a program might not have the same state that it would on a TNS system.

Exact points are points at which there is a direct correspondence between the state of an accelerated program and the state it would have if executed on a TNS system.

When debugging an accelerated program, exact points do not exist at all program locations. When a program is not at an exact point, memory and TNS registers might not be current. To make debugging easier than with most TNS/E-based systems,

Visual Inspect and Native Inspect determine the consistency of the program state, classifying exact points as either memory-exact or register-exact points. These points give you information about your program, such as if memory and registers are current.

When executing TNS instructions on a TNS/E system, the TNS/E system maintains the

TNS machine state (the register stack, S, P, ENV, and L registers) as if you were running your program on a TNS system. Because the TNS machine state is

7 -1

Debugging OCA Programs Register-Exact Points maintained, no change is required to run existing TNS programs on TNS/E systems and, with very few exceptions, debugging is the same.

Register-Exact Points

Register-exact points are locations in an accelerated program at which the values in both memory and the TNS register stack are the same as if the program were executing on a TNS system. No optimizations cross register-exact points. Complex statements might contain several such points: at each function call, privileged instruction, and embedded assignment. Register-exact points are a subset of memoryexact points.

By default, OCA defines register-exact points only where necessary for correct execution; for example, following procedure calls. Many statements have no registerexact point. Register-exact points are the only points at which an accelerated program makes transitions to and from executing TNS instructions. Some complex statements might contain several register-exact points, particularly at each function call.

At register-exact points, you can safely use all Visual Inspect, Native Inspect, or

Inspect debugging commands (including modifying memory variables) as if the program were on a TNS system.

Memory-Exact Points

Memory-exact points are locations in an accelerated program at which the values in memory (but not necessarily in the register stack) are the same as if the TNS/E program were running on a TNS processor. Displaying memory variables gives accurate results at memory-exact points. However, modifying memory variables at these points might not reliably affect the program’s subsequent actions because the changed variable might have already been loaded in registers. Most source statement boundaries are memory-exact points. Register-exact points are a subset of memoryexact points.

Nonexact Points

Nonexact points are locations in an accelerated program that are not memory-exact points. Most code locations in an accelerated program are nonexact points. At nonexact points, the TNS program state is not consistent, displayed memory might not be current, and the reported current program counter location is only approximate.

Attempting to modify memory at a nonexact point might result in the data being overwritten by a subsequent store operation.

A Strategy for Debugging

In general, debug the TNS object code version of your complete program before running OCA. Then accelerate a version of the program containing an Inspect symbols region, using the Visual Inspect or Native Inspect, and perform final testing.

Preparing Your Program for TNS/E Systems .

7 -2

Debugging OCA Programs A Strategy for Debugging

When your program executes in TNS accelerated mode, the debugger allows you to set breakpoints only at exact points. Displaying memory variables provides accurate results at all exact point. You may only use Inspect debugging commands that modify memory or display registers in the TNS register stack at register-exact points. If the program is not at a register-exact point, modifying memory variables may not affect the program’s subsequent actions as the variable values might have already been loaded into the TNS/E registers.

When executing in TNS accelerated mode at code locations that are between exact points, the TNS program state is not consistent, displayed memory may not be current, and the reported current program counts is only approximate. If you try to manually modify memory when between exact points new data may be ignored by a subsequent store operation.

If your accelerated object code behaves differently on a TNS/E system than it did on a

TNS/R system:

•

Try running the program on a TNS/R system without using OCA.

•

If the program runs incorrectly on a TNS/R system, the problem is in your program logic.

•

If the program runs correctly on a TNS/R system and incorrectly on a TNS/E system, the problem is almost certainly a TNS/E variance in your program. In this case, examine your program for variances described in

Section 2,

If your program runs correctly on a TNS system but does not run correctly on a TNS/E system, accelerated or unaccelerated, the problem might be a timing error. This is rare and only affects such timing-sensitive programs as input-output processes (IOPs).

7 -3

Error and Warning Messages

OCA issues an error or warning message when it finds a code construct that it cannot accelerate, or when it cannot understand input options or input file format. OCA does not produce an executable object file if it finds error conditions. You must resolve all error conditions to accelerate your program successfully.

Note: OCA options are not case-sensitive, but procedure names are case-sensitive. To avoid an error, procedure names must match the names in an object file exactly.

This section documents OCA warning and errors. It also describes recovery procedures, when appropriate, from problems that OCA detects.

Error and warning messages appear in summary form in the OCA output listing.

Warning Messages

OCA issues a warning when it finds a code construct for which it might have produced incorrect code. OCA cannot automatically distinguish between a benign situation and a dangerous situation, so you must check the code manually as recommended by the specific message. An OCA session that produces warnings also produces an executable file. Investigate the cause of each warning to make sure that the accelerated file will execute correctly.

Warning 15: Procedure <proc-name> in file <filename> inherits register <register-number>.

Cause. This message displays in TAL programs when TNS code appears to reference a register before setting a value in that register. In TAL programs, the USE,

STACK, and CODE statements can be used to write procedures that implicitly pass parameters in the TNS register stack. HP discourages this practice and it is not supported in accelerated customer code. OCA assumes that procedure parameters are pushed on the memory stack and that the TNS registers are pushed on the memory stack. The values in the TNS registers are not subsequently used by the called procedure. When a procedure references a register before resetting it, it is said to “inherit a register” because the value in the referenced register must have been inherited from a calling procedure. See Register Inheritance Diagnosis for more information.

Effect. OCA accelerates this program despite the message. This message can sometimes display when inheriting a register has not occurred. For example, there may be no inheritance of registers if the procedures makes a call to Debug or if the caller

8 -1

Error and Warning Messages Warning Messages declared a USE variable that was not DROPped before the procedure call. For example:

PROC fred;

BEGIN

USE i; i:= jane;

DROP i;

CALL do_mine;

END;

Check your program to verify that inheriting a register has actually occurred.

Recovery. In TAL programs that pass parameters in registers you can either:

•

Modify the source code to eliminate the implicit parameter passing through the register, then reaccelerate your program

•

Reaccelerate your program supplying the appropriate INHERITSRn options on the command line. For example: oca [/run-options/] input-file, IGNORE_IRn proc-name

You can also introduce an ”inherit a register” warning if you enter an incorrect

INHERITSRn or INHERITSCC option; a warning appears about the caller procedure and other procedures it calls.

If you determine that an “inherit a register message” occurs when there is no “inherit a register condition”, you can:

•

Enter the IGNORE_IRn option at the command line so that OCA ignores the condition. For example: oca [/run-options/] input-file, IGNORE_IRn proc-name

•

For programs that contain an uninitialized USE variable that is not DROPped before a procedure call, you can restructure the program to DROP, or defer the

USE variable before the call. For example:

PROC fred,

BEGIN

USE i, i ;= jane,

DROP i,

CALL do_mine,

END,

Diagnosing Register or Condition Code Inheritance on page 5-6 for more

8 -2

Error and Warning Messages Warning Messages

Warning 16: Procedure <proc-name> in file <filename> inherits condition codes.

Cause. OCA assumes that procedures do not reference condition codes (the N and Z bits of the ENV register) before they perform some work (such as an arithmetic operation or call to a system procedure) that resets the condition codes. OCA’s static analysis suggests that the named procedures can inherit the condition codes from their callers. See

information.

Effect. The translation continues, but would be incorrect if the procedure were to reference the condition codes before performing some work that would reset them.

Recovery. If you determine that inherit code condition message occurs when there is no “inherit a code condition”, you can either:

•

Eliminate this coding practice from your TAL procedure and then rebuild and reaccelerate

•

Reaccelerate your program using the INHERITSCC option on the command line.

For example: oca [/run-options/] input-file, INHERITSCC proc-name

If you determine that inherit condition code message occurs when there is no inherit code condition, you can direct OCA to ignore the condition by entering the

IGNORE_CC option on the command line. For example: oca {/run-options/] input-file, IGNORE_CC proc-name

Warning 23: The priv TNS-opcode <opcode> is not supported.

Cause. OCA detects an unsupported TNS opcode in one code path. If you have specified the Forbid_Obsolete_Ops option, OCA cannot complete processing.

Processing can continue with a warning if Forbid_Obsolete_Ops option is not specified.

Effect. An illegal instruction failure occurs if this code path is executed with the

Forbid_Obsolete_Ops option specified.

Recovery. Verify that there are not unsupported TNS opcodes in any executable code paths.

Warning 36:

The OUTPUT_FILE name <filename> could not be opened; output is in zzzz0000

8 -3

Error and Warning Messages Error Messages

Cause. The argument to OUTPUT_FILE is not a legal NonStop file name (for example, one that is too long).

Effect. OCA is not able to create an output file with an illegal file name. OCA instead leaves the augmented TNS file in a temporary file whose name is displayed in the message.

Recovery. Offer a valid filename as an argument to the OUTPUT_FILE option.

Error Messages

OCA issues an error when it finds a code construct that it cannot accelerate, or when it cannot understand input options or the input file format. The original TNS object file remains unchanged. Error messages are numbered 2 through 34.

Error 2: Cannot open file <filename>.

Cause. OCA cannot open the file you specified.

Effect. OCA is unable to accelerate a file it cannot open.

Recovery. Verify the filename. You should also verify you have permission to open this file. If needed, have the appropriate person alter the file permission so you can open it.

Error 3: Cannot read file <filename>.

Cause. OCA can not read the file name you specified.

Effect. OCA is unable to accelerate a file it cannot read.

Recovery. Verify you have read permissions for this file. If needed, have the appropriate person alter the file permission so you can read it.

Error 4: File <filename> is not a TNS object file.

Cause. You specified a non-TNS object file.

Effect. OCA cannot accelerate a non-TNS object file.

Recovery. Verify that the specified file has been compiled and bound correctly using

TNS compilers and the Binder.

Error 5: File <filename> is a TNS OSS object file.

8 -4

Error and Warning Messages Error Messages

Cause. You specified a TNS OSS object file.

Effect. OCA only supports native TNS object files.

Recovery. Convert this file to native mode using the TNS compilers and recompile.

Error 6: File <filename> is built using unsupported tools.

Cause. You built this file using unsupported tools.

Effect. OCA cannot accelerate this file.

Recovery. Rebuild this file using a later version of the compiler and Binder.

Error 7: File <filename> is not bound and runnable.

Cause. This file is not fully bound and ready to execute.

Effect. OCA cannot accelerate files that are not fully bound and ready to execute.

Recovery. Fully bind the object file and then translate it using OCA. Do not use the

?NOFIXUP option in your source code and do not use the SELECT FIXUPS OFF

Binder command.

Error 9: Translation of file <filename> has been inhibited.

Cause. The Binder command CHANGE OCA ENABLE OFF is set to prevent OCA from translating this file.

Effect. OCA cannot accelerate this file.

Recovery. This file must be emulated in interpretive mode. If needed, use Binder to enable file translation and then re-run OCA.

Error 10: Unrecognized option text was provided.

Cause. OCA read an option it did not recognize.

Effect. OCA cannot accelerate this file because it does not recognize one or more options on the command line.

only OCA command syntax. See Section 5, OCA Syntax and Option Summary for a

8 -5

Error and Warning Messages Error Messages

Recovery. Verify the spelling of all options and ensure that the command line contains

listing and correct spelling of OCA syntax.

Error 11: Incorrect syntax was provided on the command line.

Cause. OCA is unable to interpret your input on the command line.

Effect. OCA cannot respond to your request for file translation.

Recovery. Verify the spelling of all options and ensure that the command line contains

only OCA command syntax. See Section 5, OCA Syntax and Option Summary for a

listing and correct spelling of OCA syntax.

Error 12: The SL option is in effect but file <filename> contains a main procedure.

Cause. OCA detects a main procedure in the object file you specified, but you entered the SL option on the command line.

Effect. OCA cannot translate a library file that contains a main procedure.

Recovery. Remove the SL option from the command line and re-run OCA.

Error 13: OCA expects a file name after the OUTPUT_FILE option.

Cause. You did not supply an output file name after you specified the OUTPUT_FILE option on the command line.

Effect. OCA cannot write the accelerated object to an unspecified file.

Recovery. Supply a file name after the OUTPUT_FILE option on the command line.

Error 14: OCA expects a procedure name after the option-name option.

Cause. You did not specify a procedure name after the IGNORE_IRn, INHERITSRn,

IGNORE_CC, or INHERITSCC options.

Effect. OCA cannot accelerate this file unless you supply a procedure name after these options.

Recovery. Add a procedure name to the command line following the IGNORE_IRn.

8 -6

Error and Warning Messages Error Messages

Error 17: The output file’s disk is full; translation halted.

Cause. OCA must stop translation because there is insufficient space on the disk for the output file.

Effect. Translation stops and OCA does not create an output file or augmented input file.

Recovery. Clear sufficient disk space for the output file or augmented input file to reside.

Error 18: Temporary working space is full; translation halted.

Cause. There is insufficient disk space to accommodate the working space that OCA needs to process files.

Effect. OCA cannot translate object files.

Recovery. Clear sufficient disk space to accommodate OCA working space.

Error 19: Internal OCA failure (text).

Cause. OCA detected an internal consistency and has shut down.

Effect. OCA cannot accelerate an object file.

Recovery. Document the text information in the message and immediately report this problem to your HP analyst.

Error 20: Procedure <proc-name> in file <filename> is nonresident, but contains the MXON instruction.

Cause. OCA detected an instruction that enables mutual exclusion in a nonresident procedure.

Effect. OCA cannot process this file. Mutual exclusion can only be used in resident procedures on TNS/E systems.

Recovery. Modify the source code so that it declares the named procedure resident.

You should then recompile and rebind the program.

8 -7

Error and Warning Messages Error Messages

Error 21: The UL option is in effect, but file <filename> contains a main procedure.

Cause. OCA detects a main procedure in the object file you specified, but you entered the UL option on the command line.

Effect. OCA cannot translate a library file that contains a main procedure.

Recovery. Remove the UL option from the command line and re-run OCA.

Error 22: The UL options and the SL options are both set.

Cause. You have entered both the UL and SL options on the same command line.

Effect. OCA cannot translate a file with both the UL and SL options specified on the same command line.

Recovery. Specify either the UL or SL option on the command line and re-run OCA.

Error 24: The obey file <filename> is not a text file.

Cause. The obey file you specified on the OBEY command line has an invalid type.

Effect. OCA cannot process this file; it can only read text files.

Recovery. Use an obey file with the filecode 101.

Error 25: Cannot read the obey file <filename>.

Cause. OCA cannot read the obey file you specified on the OBEY command line.

Effect. OCA is unable to read the options in this file.

Recovery. Supply an obey file that contains the appropriate options.

Error 26: Cannot open the obey file <filename>.

Cause. OCA can not open the obey file you specified.

Effect. OCA is unable to process a file it cannot open.

Recovery. Verify that the obey file is specified on the command line, secured correctly, and contains no open errors.

8 -8

Error and Warning Messages Error Messages

Error 34: A bad RETURNVALSIZE argument of value was given for procedure <proc-name>.

Cause. The argument provided to the RETURNVALSIZE command line option was not an appropriate numerical value.

Effect. OCA cannot interpret the specified arguments as a number of 16-bit words returned by the named procedure.

Recovery. Specify a valid address in the RETURNVALSIZE option.

8 -9

Data Type Correspondence and

Return Value Sizes

The following tables contain the return value size generated by HP language compilers for each data type. Use this information when you need to specify values with the

Accelerator ReturnValSize option. These tables are also useful if your programs use data from files created by programs in another language, or your programs pass parameters to programs written in callable languages.

Refer to the appropriate NonStop SQL/MP programmer’s guide for a complete list of

SQL data type correspondence. Also note that the return value sizes given in these tables do not correspond to the storage size of SQL data types.

Note.

COBOL includes COBOL 74, COBOL85, and SCREEN COBOL unless otherwise noted.

If you are using the Data Definition Language (DDL) utility to describe your files, see the Data Definition Language (DDL) Reference Manual for more information.

A- 1

Data Type Correspondence and Return Value Sizes

Table A-1. Integer Types, Part 1

BASIC

COBOL

8-Bit Integer

STRING char[1] unsigned char signed char

Alphabetic

Numeric DISPLAY

Alphanumeric-Edited

Alphanumeric

Numeric-Edited

16-Bit Integer

INT

INT(16) int in the 16-bit data model short unsigned

PIC S9(n) COMP or PIC (n)

COMP without P or V, 1

≤ n

≤

Index Data Item [2]

NATIVE-2[3]

32-Bit Integer

INT(32) int in the 32-bit or wide data model long unsigned long

PIC S9(n) COMP or PIC 9(n)

COMP without P or V, 5

Index Data Item [2]

NATIVE-4 [3]

≤ n

≤

FORTRAN

Pascal BYTE

Enumeration, unpacked,

≤

Subrange, unpacked, n...m, 0

≤ ≤

INTEGER [4]

INTEGER*2

INTEGER

INT16

CARDINAL [1]

BYTE or CHAR value parameter

Enumeration, unpacked,

256 members

Subrange, unpacked, n...m,

-32768

≤ ≤ least n or m outside 0...255 range

INTEGER*4

LONGINT

INT32

Subrange, unpacked n...m,

-2147483648 m

≤

≤ m outside -32768...32767 range

SQL CHAR NUMERIC(1)...NUMERIC(4)

PIC9(1)COMP...PIC9(4)COMP

SMALLINT

NUMERIC(5)...NUMERIC(9)

PIC9(1)COMP...PIC9(9) COMP

INTEGER

INT(32) TAL STRING

UNSIGNED(16)

INT

UNSIGNED(16)

1 Return Value

Size (Words)

[1] Unsigned Integer

[2] Index Data Item is a 16-bit integer in COBOL 74 and a 32-bit integer in COBOL85.

[3] HP COBOL85 only.

[4] INTEGER is normally equivalent to INTEGER*2. The INTEGER*4 and INTEGER*8 compiler directives redefine

INTEGER.

A- 2

Data Type Correspondence and Return Value Sizes

Table A-2. Integer Types, Part 2

BASIC

COBOL

FORTRAN

Pascal

SQL

TAL

Return Value

Size (Words)

64-Bit Integer

INT(64)

FIXED(0) long long

PICS9(n) COMP or PIC 9(n)

COMP without P or V, 10

≤ n

≤

INTEGER*8

INT64

Bit Integer of 1 to 31

Bits

NUMERIC(10)...NUMERIC(18)

PIC9(10)COMP...PIC9(18)

COMP INTEGER

FIXED(0)

UNSIGNED(n), 1

≤ n

≤

INT(n) 1

≤

UNSIGNED(n), 1

≤ n

≤

1, 1 or 2 in TAL

Decimal Integer

Numeric DISPLAY

DECIMAL

DECIMAL (n,s)

PIC9(n) DISPLAY

1 or 2, depends on declared pointer size

[1] HP COBOL85 only

Table A-3. Floating, Fixed, and Complex Types

BASIC

COBOL

FORTRAN

Pascal

SQL

TAL

Return Value

Size (Words

32-Bit Floating 64-Bit Floating 64-Bit Fixed Point

REAL REAL(64) FIXED(s), 0

≤ s

≤ float double --

REAL

DOUBLE

PRECISION

PIC S9(n–s)v9(s) COMP or PIC 9(n–s)v9(s)

COMP, 10

≤ ≤

REAWL

REAL

LONGREAL

REAL(64)

NUMERIC (n,s)

PIC 9(n-s)v9(s) COMP

FIXED(s), -19

≤

COMPLEX

64-Bit Complex

A- 3

Data Type Correspondence and Return Value Sizes

BASIC

Table A-4. Character Types

Character

STRING signed char unsigned char

COBOL

FORTRAN

Alphabetic

Numeric DISPLAY

Alphanumeric-Edited

Alphanumeric

Numeric-Edited

CHARACTER

Pascal CHAR or BYTE value parameter

Enumeration, unpacked,

≤ members

Subrange, unpacked, n...m, 0

≤ and m

SQL PIC X

CHAR

TAL

Return Value

Size (Words)

STRING

[1] HP COBOL85 only.

Character String

STRING pointer to char

Varying Length Character String

-struct {

int len;

char val [n]

};

01 name.

03 len USAGE IS NATIVE-2 [1]

03 val PIC X(n).

Alphabetic

Numeric DISPLAY

Alphanumeric-Edited

Alphanumeric

Numeric-Edited

CHARACTER array

CHARACTER*n

PACKED ARRAY OF

CHAR

FSTRING

STRING(n)

CHAR(n)

PIC X(n)

STRING array

1 or 2, depends on declared pointer size

VARCHAR(n)

1 or 2, depends on declared pointer size

Table A-5. Structured, Logical, Set, and File Types

BASIC

COBOL

FORTRAN

Pascal

SQL

TAL

Return Value

Size (Words)

Byte-Addressed

Structure

RECORD

RECORD, byte-aligned

Byte-addressed standard STRUCT pointer

1 or 2, depends on declared pointer size

Word-Addressed

Structure

MAP buffer struct

01-level RECORD

RECORD, word-aligned

Word-addressed standard STRUCT pointer

1 or 2, depends on declared pointer size

Logical (true or false)

LOGICAL [1]

1 or 2, depends on compiler directive

Boolean

BOOLEAN

Set

Set

File

File

[1] LOGICAL is normally defined as 2 bytes. The LOGICAL*2 and LOGICAL*4 compiler directives redefine LOGICAL.

A- 4

Data Type Correspondence and Return Value Sizes

BASIC

COBOL

FORTRAN

Pascal

Table A-6. Pointer Types

Procedure Pointer Byte Pointer

--function pointer

-byte pointer

Procedure pointer

Pointer, byte-addressed

BYTEADDR

SQL

TAL

Return Value

Size (Words)

1 or 2, depends on declared pointer size

16-bit pointer, byte-addressed

1 or 2, depends on declared pointer size

Word Pointer

-word pointer

Pointer,

word-addressed

WORDADDR

16-bit pointer, word addressed

1 or 2, depends on declared pointer size

Extended Pointer

-extended pointer

Pointer, extended-addressed

EXTADDR

32-bit pointer

1 or 2, depends on declared pointer size

than TNS object code that is not accelerated. See also TNS Object Code Accelerator

A- 5

Glossary

absolute pathname. An Open System Services (OSS) pathname that begins with a slash (/) character and is resolved beginning with the root directory. Contrast with

relative pathname .

accelerate. To speed up emulated execution of a TNS object file by applying the

Accelerator for TNS/R system execution or the Object Code Accelerator (OCA) for

TNS/E system execution before running the object file.

accelerated mode. See

TNS accelerated mode .

accelerated object code. The MIPS RISC instructions (in the MIPS region) that result from processing a TNS object file with the Accelerator or the Intel® Itanium® instructions (in the Itanium instruction region) that result from processing a TNS object file with the

Object Code Accelerator (OCA).

accelerated object file. A TNS object file that, in addition to its TNS instructions (in the

TNS region) and symbol information (in the symbol region), has been augmented by the Accelerator with equivalent but faster MIPS RISC instructions (in the MIPS region), the Object Code Accelerator (OCA) with equivalent but faster Intel® Itanium® instructions (in the Itanium instruction region), or both.

Accelerator. A program optimization tool that processes a TNS object file and produces an accelerated object file that also contains equivalent MIPS RISC instructions (called the

MIPS region). TNS object code that is accelerated runs faster on TNS/R processors

(OCA) .

Accelerator region of an object file. The region (called the MIPS region) of an object file that contains MIPS RISC instructions and tables necessary to execute the object file on a TNS/R system in accelerated mode. The Accelerator creates this region. Contrast with

OCA region of an object file . See also

accelerated object file .

access mode. A file attribute that determines what operations you can perform on the file, like reading and writing.

active backup. A programming technique used to achieve fault tolerance in application programs. In active backup programming, a program executes as a process pair: a primary process, which performs the application processing, and a backup process, which is ready to take over execution if the primary process fails.

active process. The process that is currently using the instruction processing unit of the processor module. Contrast with

inactive process .

address space. The memory locations to which a process has access.

application program interface (API) .

Glossary- 1

Glossary alternate key

alternate key. A sequence of characters other than the primary key used as an alternate index to records in a key-sequenced file.

alternate-key file. A key-sequenced file that provides the relationship between alternate keys and primary keys.

ancestor. The process that is notified when a named process or process pair is deleted.

The ancestor is usually the process that created the named process or process pair.

ANSI. The American National Standards Institute.

API. See

application program interface (API). A set of services (such as programming language functions or procedures) that are called by an application program to communicate with other software components. For example, an application program in the form of a client might use an API to communicate with a server program.

ASSIGN. An association of a physical file name with a logical file name made by the TACL

ASSIGN command. The physical file name is any valid file name. The logical file name is used within a program. The ASSIGN is therefore used to pass file names to programs.

AXCEL. The command used to invoke the Accelerator on a TNS/R or TNS/E system.

binary semaphore. A software tool used to synchronize processes. Binary semaphores provide a way for several concurrently-executing processes to share a resource.

Using binary semaphores, an executing process can hold exclusive access to the shared resource. Other processes execute until they need to use the resource, then enter a wait state until the resource becomes available.

Binder. A programming utility that combines one or more compilation units’ TNS object code files to create an executable TNS object code file for a TNS program or library.

Used only with

TNS object file s.

Binder region. The region of a TNS object file that contains header tables for use by the

Binder program.

binding. The operation of collecting, connecting, and relocating code and data blocks from one or more separately compiled TNS object files to produce a target object file.

BREAK mode. A mode of process execution where a process gains exclusive access to a terminal when the BREAK key is pressed. BREAK mode is established using

SETPARAM function 3 or SETMODE function 11.

BREAK owner. The process that receives the Break-on-device message when the BREAK key is pressed. The establishment of BREAK ownership is achieved using

SETPARAM function 3 or SETMODE function 11.

memory-exact point ), not at arbitrary instructions. Some

Glossary- 2

Glossary breakpoint

breakpoint. An object code location at which execution will be suspended so that you can interactively examine and modify the process state. With symbolic debuggers, breakpoints are usually at source line or statement boundaries.

In TNS/R or TNS/E native object code, breakpoints can be at any MIPS RISC instruction or Intel® Itanium® instruction within a statement. In a TNS object file that has not been accelerated, breakpoints can be at any TNS instruction location. In a

TNS object file that has been accelerated, breakpoints can be only at certain TNS instruction locations (see

source statement boundaries are not available. However, breakpoints can be placed at any instruction in the accelerated code.

CAID. See

creator access ID (CAID)

central processing unit (CPU). Historically, the main data processing unit of a computer.

HP NonStop™ servers have multiple cooperating processors rather than a single CPU.

See also

processor .

child process. A process created by another process. The creating process becomes the parent process of the new process. See also

pathname component .

CISC compiler. See

complex instruction-set computing (CISC)

and TNS compiler

CISC processor. An instruction processing unit (IPU) that is based on complex instruction-set computing (CISC) architecture.

checkpoint. A line in a program at which specified information is copied from the primary process of a process pair to the backup process. This line then becomes the restart point for the backup process in the event that the primary process should stop due to processor failure.

child process. A process created by the current process.

CISC. See

complex instruction-set computing (CISC) .

client. A software process, hardware device, or combination of the two that requests services from a server. Often, the client is a process residing on a programmable workstation and is the part of an application that provides the user interface. The workstation client might also perform other portions of the application logic.

client application. An application that requests a service from a

shared memory

. Execution of remote procedure calls is an example of a client application.

code file. See object code file .

code segment. A segment that contains executable instructions of a program or library to be executed plus related information. Code segments can be executed and also accessed as read-only data but not written to by an application program. These readonly and execute-only segments are efficiently shared among simultaneous executions

code, and system library code. See TNS code space .

Glossary- 3

Glossary code set of that program or library. Therefore, they are read from disk but are never written back to disk. See also

TNS code space .

code set. Codes that map a unique numeric value to each character in a character set, using a designated number of bits to represent each character. Single-byte code sets use 7 or 8 bits to represent each character. The ASCII and ISO 646 code sets use 7 bits to represent each character in Roman-based alphabets; these code sets are very limited and are not appropriate for international use. The single-byte ISO 8859 code sets use 8 bits to represent each character and can therefore support Roman-based alphabets and many others including Greek, Arabic, Hebrew, and Turkish. Multibyte code sets represent characters that require more than one byte, such as East Asian ideographic characters.

code space. that part of virtual memory reserved for user code, user library code, system

compiler extended-data segment. A selectable segment, with ID 1024, created and selected automatically in many (but not all) TNS processes. Within this segment, the compiler automatically allocates global and local variables and heaps that would not fit in the TNS user data segment. A programmer must keep this segment selected whenever those items might be referenced. Any alternative selections of segments must be temporary and undone before returning.

completion code. A value used to return information about a process to its ancestor process when the process is deleted. This value is returned in the Process deletion message, system message -101.

complex instruction-set computing (CISC). A processor architecture based on a large instruction set, characterized by numerous addressing modes, multicycle machine instructions, and many special-purpose instructions. Contrast with

reduced instructionset computing (RISC) .

condition code. A status returned in the Environment Register by some file-system procedure calls to indicate whether the call was successful. A condition-code-greaterthan (CCG) indicates a warning, a condition-code-less-than (CCL) indicates an error, and a condition-code-equal (=) indicates successful execution.

conversational mode. A mode of communication between a terminal and its I/O process in which each byte is transferred from the terminal to the processor I/O buffer as it is typed. Each data-transfer operation finishes when a line-termination character is typed at the terminal. Contrast with

page mode .

CPU. See

central processing unit (CPU) .

cpu, pin

. In the Guardian environment, a number pair that uniquely identifies a process during the lifetime of the process, consisting of the processor (CPU) number and the process identification number (PIN).

multibyte character set and

Glossary- 4

Glossary creator

creator. The process that causes a process to be built from a program file of another process. Compare with

ancestor

creator access ID (CAID). A process attribute that identifies, by user ID, the user who initiated the process creation. Contrast with

process access ID (PAID)

current selectable segment. The selectable segment that can be accessed by a process.

A process specifies the current selectable segment by calling the USESEGMENT or

SEGMENT_USE_ procedure to select one of a set of alternative selectable segments.

D-series system. A system that is running a D00 or later version of the operating system.

data segment. A virtual memory segment holding data. Every process begins with its own data segments for program global variables and runtime stacks (and for some libraries, instance data). Additional data segments can be dynamically created. See also

flat segment and

selectable segment .

data space. The area of virtual memory reserved for user data and system data.

deadlock. A situation in which two processes or two transactions cannot continue because they are each waiting for the other to release a lock.

DEFINE. An HP Tandem Advanced Command Language (TACL) command you can use to specify a named set of attributes and values to pass to a process.

DEFINE name. An identifier preceded by an equal sign that can be used in place of an actual name to identify a DEFINE in a procedure call. See

DEFINE .

disk drive. A device that stores and accesses data on a magnetic disk. Random access to addressable locations on a magnetic disk is provided by magnetic read/write heads.

dispatching. The task of making a process active, permitting it to use the processor to execute.

distributed system. A system that consists of a group of connected, cooperating computers.

download. The process of transferring software from one location to another, where the transferring entity initiates the transfer.

dynamic-link library (DLL). A collection of procedures whose code and data can be loaded and executed at any virtual memory address, with run-time resolution of links to and from the main program and other independent libraries. The same DLL can be used by more than one process. Each process gets its own copy of DLL static data. Contrast with

shared run-time library (SRL) . See also

TNS/R library .

dynamic loading. Loading and opening dynamic-link libraries under programmatic control after the program is loaded and execution has begun.

Glossary- 5

Glossary duplicate key

duplicate key. A sequence of characters that makes up the same value in a key field in more than one record in the same file.

EDIT file. In the Guardian file system, an unstructured file with file code 101. An EDIT file can be processed by either the EDIT or PS Text Edit (TEDIT) editor. An EDIT file typically contains source program or script code, documentation, or program output.

Open System Services (OSS) functions can open an EDIT file only for reading.

elapsed time. Time as measured by the processor clock, independent of the state of any process.

eld

utility. A utility that collects, links, and modifies code and data blocks from one or more position-independent code (PIC) object files to produce a target TNS/E native object file. See also

ld utility

and

nld utility

emulate. To imitate the instruction set and address spaces of a different hardware system by means of software. Emulator software is compatible with and runs software built for the emulated system. For example, a TNS/R or TNS/E system emulates the behavior of a TNS system when executing interpreted or accelerated TNS object code.

enoft

utility. A utility that reads and displays information from TNS/E native object files.

See also

noft

utility .

EPTRACE. A performance investigation tool for Open System Services (OSS) and

Guardian environments running H-series RVUs. It is designed to count, trace, locate, and provide a log of millicode-corrected misalignments in TNS stumble events.

Enscribe. A database record management system.

entry-sequenced file. A file in which each new record is stored at the end of the file in chronological sequence and whose primary key is a system-generated record address.

Contrast with

key-sequenced file and

relative file .

exact point. See

memory-exact point

and

executable. See

object code file .

execution mode. The emulated or real instruction set environment in which object code runs. A TNS system has only one execution mode: TNS mode using TNS compilers and 16-bit TNS instructions. A TNS/R system has three execution modes: TNS/R native mode using MIPS native compilers and MIPS instructions, emulated TNS execution in TNS interpreted mode, and emulated TNS execution in TNS accelerated mode. A TNS/E system also has three execution modes: TNS/E native mode using

TNS/E native compilers and Intel® Itanium® instructions, emulated TNS execution in

TNS interpreted mode, and emulated TNS execution in TNS accelerated mode.

exclusion mode. The attribute of a lock that determines whether any process except the lock holder can access the locked data.

explicit dynamic-link library (explicit DLL) .

Glossary- 6

Glossary executable object file

executable object file. See

program file

explicit DLL. See

explicit dynamic-link library (explicit DLL). A dynamic-link library (DLL) that is named in the libList of a client or is a native-compiled loadfile associated with a client.

export. To offer a symbol definition for use by other loadfiles. A loadfile exports a symbol definition for use by other loadfiles that need a data item or function having that symbolic name.

EXTDECS file. See

external declarations file .

extended data segment. See selectable segment .

external entry-point (XEP) table. A table located in the last page of each TNS code segment that contains links for calls (unresolved external references) out of that segment.

extensible data segment. An extended data segment for which swap file extents are not allocated until needed.

extent. A contiguous area of a disk allocated to a file.

external declarations file. A file containing external declarations for Guardian procedure calls. There are several such files relating to the high-level programming language you are using and the version of the operating system.

file. An object to which data can be written or from which data can be read. A file has attributes such as access permissions and a file type. In the Open System Services

(OSS) environment, file types include regular file, character special file, block special file, FIFO, and directory. In the Guardian environment, file types include disk files, processes, and subdevices.

file code. An integer value assigned to a file for application-dependent purposes, typically identifying the kind of information the file contains.

file description. See

open system .

file identifier. In the Guardian environment, the portion of a filename following the subvolume name. In the Open System Services (OSS) environment, a file identifier is a portion of the internal information used to identify a file in the OSS file system (an inode number). The two identifiers are not comparable.

filename. In the Open System Services (OSS) environment, a component of a

pathname

containing any valid characters other than slash (

) or null. See also file name .

file name. A string of characters that uniquely identifies a file.

Glossary- 7

Glossary file lock

In the PC environment, file names for disk files normally have at least two parts (the disk name and the file name); for example, B:MYFILE.

In the Guardian environment, disk file names include an Expand node name, volume name, subvolume name, and file identifier; for example,

\NODE.$DISK.SUBVOL.MYFILE.

In the Open System Services (OSS) environment, a file is identified by a

pathname

; for example,

/usr/john/workfile

. See also

filename .

file lock. A mechanism that restricts access to a file by all processes except the lock owner.

file name. A unique name for a file. This name is used to open a file using a FILE_OPEN_ or OPEN procedure call and thereby provides a connection between the opening process and the file.

file-name part. That portion of a file name that occurs between two periods, before the first period, or after the last period. Node name, file ID, process name, process qualifier, device name, and volume name are all examples of file-name parts.

file-name pattern. A sequence of characters including the asterisk (*) and question mark

(?) that matches existing file names by expanding each asterisk to zero or more letters, digits, dollar signs ($), and pound signs (#) and replacing each question mark with exactly one letter, digit, dollar sign, or pound sign.

file-name piece. One or more consecutive parts of a file name separated by periods.

file-name subpart. An element of a file-name part separated from the next element by a colon (:).

file number. An integer that represents a particular instance of an open file. A file number is returned by the FILE_OPEN_ or OPEN procedure and is used in all subsequent input/output procedures to reference the file. Internally, the file number is an index into the file table.

file serial number. A number that uniquely identifies a file within its file system.

file system. In the Open System Services (OSS) environment, a collection of files and file attributes. A file system provides the namespace for the file serial numbers that uniquely identify its files. Open System Services provides a file system (see also

ISO/IEC IS 9945-1:1990 [ANSI/IEEE Std. 1003.1-1990], Clause 2.2.2.38); the

Guardian application program interface (API) provides a file system; and OSS Network

File System (NFS) provides a file system. (OSS NFS filenames and pathnames are governed by slightly different rules than OSS filenames and pathnames.) Within the

OSS and OSS NFS file systems, filesets exist as manageable objects.

On an HP NonStop™ system, the Guardian file system for an Expand node is a subset of the OSS virtual file system. Traditionally, the API for file access in the Guardian environment is referred to as the Guardian file system.

file type. A designation for a file structure. See entry-sequenced file ,

Glossary- 8

Glossary file type

In some UNIX and NFS implementations, the term file system means the same thing as fileset. That is, a file system is a logical grouping of files that, except for the root of the file system, can be contained only by directories within the file system. See also

file system .

key-sequenced file

relative file , and

unstructured file

flat segment. A type of logical segment. Each flat segment has its own distinct address range within the process address space that never overlaps the range of any other allocated segments. Thus all allocated flat segments for a process are always available for use concurrently. See also

logical segment

and

selectable segment

fully qualified file name. The complete name of a file, including the node name. For permanent disk files, this consists of a node name, volume name, subvolume name, and file ID. For temporary disk files, consists of a node name, subvolume name and a temporary file ID. For a device, it consists of a node name and a device name or logical device number. For a named process, it consists of a node name, and a process name. For an unnamed process it consists of a node name, CPU number,

PIN, and sequence number. Contrast with

partially qualified file name .

graphical user interface (GUI). A user interface that offers point-and-click access to program functions.

group list. An Open System Services (OSS) process attribute that is used with the effective group ID of the process to determine the file access permissions for the process.

Guardian. An environment available for interactive or programmatic use with the HP

NonStop™ operating system. Processes that run in the Guardian environment usually use the Guardian system procedure calls as their application program interface.

Interactive users of the Guardian environment usually use the HP Tandem Advanced

Command Language (TACL) or another HP product’s command interpreter. Contrast with

Open System Services (OSS) .

Guardian environment. The Guardian application program interface (API), tools, and utilities.

Guardian services. An application program interface (API) to the HP NonStop™ operating system, plus the tools and utilities associated with that API. This term is synonymous with Guardian environment. See also

Guardian .

Guardian user ID. See HP NonStop™ operating system user ID .

GUI. See

graphical user interface (GUI) .

header. An object that, when specified for inclusion in a program’s source code, causes the program to behave as if the statement including the header were actually a specific set of other programming statements. A header contains coded information that provides details (such as data item length) about the data that the header precedes.

Open System Services (OSS) .

Glossary- 9

Glossary HP NonStop™ Open System Services (OSS)

HP NonStop™ Open System Services (OSS). The product name for the OSS environment. See also

HP NonStop™ Kernel operating system. The former name of the operating system for HP

NonStop systems. See

HP NonStop™ operating system user ID .

HP NonStop™ operating system user ID. A

user ID within an HP NonStop system. The

Guardian environment normally uses the structured view of this user ID, which consists of either the

group-number, user-number

pair of values or the

group-name.user-name

pair of values. For example, the structured view of the super ID is (255, 255). The Open System Services (OSS) environment normally uses

the scalar view of this user ID, also known as the UID , which is the value

(

group-number

* 256) +

user-number

. For example, the scalar view of the super ID is (255 * 256) + 255 = 65535.

HP NonStop™ operating system. The operating system for HP NonStop systems.

HP NonStop™ System EPIC Model A processor (NSE-A processor). The model designation for the TNS/E processor used in the HP NonStop NS10000 server.

HP NonStop™ Technical Library (NTL). The application for accessing, searching, and viewing technical publications and support information for the HP NonStop server. NTL replaces Total Information Manager (TIM).

HP Tandem Advanced Command Language (TACL). The user interface to the HP

NonStop™ operating system. The TACL product is both a command interpreter and a command language. Users can write TACL programs that perform complex tasks or provide a consistent user interface across independently programmed applications.

HP Transaction Application Language (TAL). A systems programming language with many features specific to stack-oriented TNS systems.

hybrid shared run-time library (hybrid SRL). A shared run-time library (SRL) that has been augmented by the addition of a dynamic section that exports the SRL’s symbols in a form that can be used by position independent code (PIC) clients. A hybrid SRL looks like a dynamic-link library (DLL) to PIC clients (except it cannot be loaded at other addresses and cannot itself link to DLLs). The code and data in the SRL are no different in a hybrid SRL, and its semantics for non-PIC clients are unchanged.

implicit library import library (imp-imp). See

import library .

implied user library. A method of binding TNS object files that have more than 16 code segments. Segments 16 through 31 are located in the user code (UC) space but are executed as if they were segments 0 through 15 of the user library (UL) code space.

This method precludes the use of a user library. Binder now supports 32 segments of

UC space concurrently with 32 segments of UL code space, so the implied user library method is not needed in new or changed TNS applications.

processor module. Contrast with active process .

Glossary -10

Glossary import

import. To refer to a symbol definition from another loadfile. A loadfile imports a symbol definition when it needs a data item or function having that symbolic name.

import control. The characteristic of a loadfile that determines from which other loadfiles it can import symbol definitions. The programmer sets a loadfile’s import control at link time. That import control can be localized, globalized, or semiglobalized. A loadfile’s import control governs the way the linker and loader construct that loadfile’s searchList and affects the search only for symbols required by that loadfile.

import library. A file that represents a dynamic-link library (DLL) and can substitute for it as input to the linker. Import libraries facilitate linking on auxiliary platforms (that is, PCs) where it is inconvenient to store the actual DLLs.

inactive process. A process that is not currently using the instruction processing unit of the

input/output process (IOP). A system process that drives one or more input/output units attached to the processor module through input/output channels and controllers.

interprocess communication (IPC). The exchange of messages between processes in a system or network.

Inspect region. The region of a TNS object file that contains symbol tables for all blocks compiled with the SYMBOLS directive. The Inspect region is sometimes called the

SYSnn subvolume .

INSPSNAP. The program that provides a process snapshot file for the Inspect subsystem.

installation subvolume (ISV). A subvolume containing files that perform a specific function during the installation process, such as organizing documentation in a specific location, providing the components of the HP NonStop™ operating system image (OSIMAGE), and containing files that are used after the installation process.

instance. A particular case of a class of items or objects. For example, a process is defined as one instance of the execution of a program. Multiple processes might be executing the same program simultaneously. Also, instance data refers to global data of a program or library. Each process has its own instance of the data.

instance data. For each process using a dynamic-link library, a data segment area containing the global variables used by the library.

Intel® Itanium® instructions. Register-oriented Itanium instructions that are native to and directly executed by a TNS/E system. Itanium instructions do not execute on TNS and

TNS/R systems. Contrast with

TNS instructions and

RISC instructions

TNS Object Code Accelerator (OCA) produces Itanium instructions to accelerate TNS object code. A TNS/E native compiler produces native-compiled Itanium instructions when it compiles source code.

can execute in accelerated mode on TNS/E systems. Contrast with native .

Glossary -11

Glossary Intel® Itanium® instruction region

Intel® Itanium® instruction region. The region of a TNS object file that contains Itanium instructions and the tables necessary to execute the instructions in accelerated mode on a TNS/E system. The Object Code Accelerator (OCA) creates this region and writes it into the TNS object file. A TNS object file that contains an Itanium instruction region

Intel® Itanium® instruction region loading. Mapping the Itanium instructions and any tables necessary at runtime into memory from the Itanium instruction region of a TNS object file, performed when deemed necessary by the TNS emulation software on a

TNS/E system.

Intel® Itanium® word. An instruction-set-defined unit of memory. An Itanium word is 4

bytes (32 bits) wide, beginning on any 4-byte boundary in memory. Contrast with TNS word

and word

. See also native .

interpreted mode. See

TNS interpreted mode .

interactive mode. A mode of operation that is characterized by having the same input and output device (a terminal or a process) for the session. If a terminal is used, a person enters a command and presses Return. If a process is used, the system interface waits for the process to send a request and treats the process in the same manner as a terminal. Contrast with

noninteractive mode .

interrupt. The mechanism by which a processor module is notified of an asynchronous event that requires immediate processing.

interval timer. A 16-bit register that is incremented every microsecond.

IOP. See

input/output process (IOP) .

IPC. See

interprocess communication (IPC) .

Kernel subsystem. In G-series and H-series release version updates (RVUs), the subsystem for configuration and management of the Subsystem Control Facility (SCF) subsystem managers that are generic processes, some system attributes, and the

ServerNet X and Y fabrics.

Kernel subsystem manager process. The

graphical user interface (GUI)

that starts and manages other generic processes, some system attributes, and the ServerNet X and Y fabrics in G-series release version updates (RVUs). The $ZZKRN Kernel subsystem manager process is started and managed by the $ZPM persistence manager process.

Kernel-Managed Swap Facility (KMSF). A facility by which the operating system manages virtual memory using swap files that it owns. Each processor has at least one kernel-managed swap file that provides the swap space needs of all of its processes.

key-sequenced file. A file in which each new record is stored in sequence by primary key value, and whose primary key is either a user-defined or a system-defined value.

Kernel-Managed Swap Facility (KMSF) .

Glossary -12

Glossary KMSF

Records in a key-sequenced file can be updated or deleted. Contrast with

entrysequenced file and

relative file .

KMSF. See

keyword. A character sequence recognized by a command process.

LDEV. See

logical device .

utility. A utility that collects, links, and modifies code and data blocks from one or more position-independent code (PIC) object files to produce a target TNS/R native object file. See also

eld utility

and

nld utility .

legacy system. An operating system that is not open but from which applications must be ported or users transferred.

library. A generic term for a collection of routines useful in many programs. An object code library can take the form of a linkfile to be physically included into client programs, it can be an OSS archive file containing several linkable modules, it can be a loadfile, or it can be a system-managed collection of preloaded routines. Source-code libraries fall outside the scope of this glossary.

library client. A program or another library that uses routines or variables from that library.

library file. See

library .

linking. The operation of collecting, connecting, and relocating code and data blocks from one or more separately compiled object files to produce a target object file.

load. (1) To transfer the HP NonStop™ operating system image or a program from disk into a computer’s memory so that the operating system or program can run.

local millicode. Emulation millicode routines that are physically copied into each TNS program code file when accelerated for TNS/E. These are a small and frequently used subset of the full set of accelerated-mode millicode routines located in the system’s

TNS Emulation Library . The program’s calls to its local copy of these routines are

faster and more compact than DLL calls to the external library.

logical device. (1) An addressable device, independent of its physical environment.

Portions of the same logical device may be located in different physical devices, or several logical devices or parts of logical devices may be located in one physical device. (2) A process that can be accessed as if it were an I/O device; for example, the operator process is logical device LDEVOPR.

logical device number. A number that identifies a configured logical device. A logical device number can be used instead of a device file name when opening a device file.

logical memory. The portion of virtual memory that can be accessed by any process in nonprivileged mode.

Intel® Itanium® instruction region .

Glossary -13

Glossary logical page

logical page. (1) 2048 contiguous bytes of memory. (2) The size of a printed page given as a number of lines.

logical processor. See

processor .

logical segment. A single data area consisting of one or more consecutive 128-kilobyte unitary segments that is dynamically allocated by a process. The two types of logical segments are selectable segments and flat segments. See also

selectable segment

and

flat segment

logical processor. The combination of equivalent processor elements in the processor slices that are running in the same instruction stream in loose lock-step.

login. The activity by which a user establishes a locally authenticated identity on a server.

Each login has one login name.

login name. A user name associated with a session.

logon sequence. The process through which the HP NonStop™ server to be managed is determined, the security constraints to interact with that server are met, and a connection with that server is established.

low PIN. A PIN in the range 0 through 254.

main memory. Data storage, specifically the chips that store the programs and data currently in use by a processor.

memory-exact point. A potential breakpoint location within an accelerated object file at which the values in memory (but not necessarily the values in registers) are the same as they would be if the object file were running in TNS interpreted mode or on a TNS system. Most source statement boundaries are memory-exact points. Complex statements might contain several such points: at each function call, privileged instruction, and embedded assignment. Contrast with

nonexact point .

message system. A set of operating system procedures and data structures that handles the mechanics of exchanging messages between processes.

MIPS Computer Systems, Incorporated. RISC processor manufacturer.

MIPS region of a TNS object file. The region of a TNS object file that contains MIPS instructions and the tables necessary to execute the instructions in accelerator mode on a TNS/R system. Accelerator creates this region and writes it into the TNS object file. Contrast with

MIPS RISC instructions. Register-oriented 32-bit machine instructions in the MIPS-1 RISC instruction set that are native to and directly executed on TNS/R systems. MIPS RISC

instructions do not execute on TNS systems and TNS/E systems. Contrast with TNS instructions and

Intel® Itanium® instructions

. See also Intel® Itanium® word

Glossary -14

Glossary MIPS RISC word

Accelerator-generated MIPS RISC instructions are produced by accelerating TNS object code. Native-compiled MIPS RISC instructions are produced by compiling source code with a TNS/R native compiler.

MIPS RISC word. An instruction-set-defined unit of memory. A MIPS RISC word is 4 bytes

(32 bits) wide, beginning on any 4-byte boundary in memory. Contrast with

TNS word

and

word

millicode. RISC instructions that implement various TNS low-level functions such as exception handling, real-time translation routines, and library routines that implement the TNS instruction set. Millicode is functionally equivalent to TNS microcode.

multibyte character set. A means for identifying written characters for national languages that require more than one byte to represent a single character.

multiprocessing. Two or more processes running in parallel by executing on different processing modules.

multithreaded process. A process that performs more than one operation concurrently.

Contrast with

single-threaded process .

named process. A process to which a process name was assigned when the process was created. Contrast with

unnamed process .

native. An adjective that can modify object code, object file, process, procedure, and mode of process execution. Native object files contain native object code, which directly uses

MIPS or Intel® Itanium® instructions and the corresponding conventions for register handling and procedure calls. Native processes are those created by executing native object files. Native procedures are units of native object code. Native mode execution is the state of the process when it is executing native procedures.

native mode. See

TNS/R native mode

and TNS/E native mode .

native-mode code. Object code that has been compiled with TNS/R native compilers to run on TNS/R systems or with TNS/E native compilers to run on TNS/E systems.

native-mode library. A native-compiled loadfile associated with one or more other nativecompiled loadfiles. A native mode process can have any number of associated nativemode libraries. See also

TNS library and

TNS/E library .

native-mode source code. High-level language routines that can be compiled with TNS/E native compilers. These two sets of compilers accept the same language dialects.

native object code. See

TNS/R native object code

and

TNS/E native object code

native object file. See

TNS/R native object file and

TNS/E native object file .

native process. See

TNS/R native process and

TNS/E native process .

native signal. See TNS/R native signal and TNS/E native signal .

Glossary -15

Glossary native signal

nld

utility. A utility that collects, links, and modifies code and data blocks from one or more object files to produce a target TNS/R native object file. See also

eld utility

and

ld utility .

node. A system of one or more processor modules. Typically, a node is linked with other nodes to form a network.

node name. The portion of a file name that identifies the system through which the file can be accessed.

noft

utility. A utility that reads and displays information from TNS/R native object files. See also

enoft utility

nonexact point. A code location within an accelerated object file that is between memoryexact points. The mapping between the TNS program counter and corresponding

RISC instructions is only approximate at nonexact points, and interim changes to memory might have been completed out of order. Breakpoints cannot be applied at nonexact points. Contrast with

message system and

nonretryable error. An error condition returned by the file system that cannot be recovered by retrying the operation even after operator intervention. Contrast with

retryable error

NonStop™ Kernel operating system. See

NonStop™ Series TNS. See temporary disk file .

NonStop™ Series TNS/E. See

TNS/E .

NonStop™ Series TNS/R. See TNSVU .

NonStop Technical Library. See HP NonStop™ Technical Library (NTL) .

NonStop Kernel Open System Services (OSS). An application program interface (API) to the Tandem NonStop Kernel and associated tools and utilities. See

Open System

Services (OSS)

for a more complete definition.

NonStop SQL. A relational database management system that provides efficient online access to large distributed databases.

NSAA. HP NonStop™ advanced architecture.

NSE-A processor. See

HP NonStop™ System EPIC Model A processor (NSE-A processor) .

noft

utility. A utility that reads and displays information from TNS/R native object files. See also

enoft

utility .

TNS Object Code Accelerator (OCA) .

Glossary -16

Glossary noninteractive mode

noninteractive mode. A mode of operation that usually involves a command file (an EDIT file that contains a series of commands). Contrast with

interactive mode .

object code accelerator (OCA). See

object code file. A file containing compiled machine instructions for one or more routines.

This file can be an executable loadfile for a program or library or a not-yet-executable linkfile for some program module. On other systems, an object code file is also known as a binary or as an executable.

object code interpreter (OCI). See TNS Object Code Interpreter (OCI) .

OCA. (1) The command used to invoke the TNS Object Code Accelerator (OCA) on a

TNS/E system. (2) See

TNS Object Code Accelerator (OCA) .

OCA region loading. A task performed when necessary by the TNS emulation software for

TNS/E machines. This task involves mapping into memory the Intel® Itanium® instructions and any tables needed at run time from the TNS Object Code Accelerator

(OCA) region (called the Itanium instruction region) of an OCA-generated object file.

OCA region of an object file. The region of a TNS Object Code Accelerator (OCA)generated object file, also called the Intel® Itanium® instruction region, that contains

Itanium instructions and tables necessary to execute the object file on a TNS/E system in TNS accelerated mode. The TNS Object Code Accelerator (OCA) creates this region. See also

OCA-accelerated object code . Contrast with

Accelerator region of an object file .

OCA-accelerated object code. The Intel® Itanium® instructions that result from processing a TNS object file with the TNS Object Code Accelerator (OCA).

OCA-accelerated object file. A TNS object file that has been augmented by the TNS

Object Code Accelerator (OCA) with equivalent but faster Intel® Itanium® instructions.

An OCA-accelerated object file contains the original TNS object code, the OCAaccelerated object code and related address map tables, and any Binder and symbol information from the original TNS object file. An OCA-accelerated object file also can be augmented by the Accelerator with equivalent MIPS RISC instructions.

OCA-generated Itanium instructions. See Intel® Itanium® instructions

OCI. See

TNS Object Code Interpreter (OCI) .

object code library. Synonym for

library

object file. A file generated by a compiler or linker that contains machine instructions and other information needed to construct the executable code spaces and initial data for a process. The file may be a complete program that is ready for immediate execution, or it may be incomplete and require linking with other object files before execution. See also

TNS object file ,

TNS/R native object file , and

TNS/E native object file .

message (the server). Contrast with two-way communication

Glossary -17

Glossary one-way communication

one-way communication. A form of interprocess communication where the sender of a message (the requester) does not expect any data in the reply from the receiver of the

open system. A system with interfaces that conform to international computing standards and therefore appear the same regardless of the system’s manufacturer. For example, the Open System Services (OSS) environment on HP NonStop™ systems conforms to international standards such as ISO/IEC IS 9945-1:1990 (ANSI/IEEE Std. 1003.1-

1990, also known as POSIX.1), national standards such as FIPS 151-2, and portions of industry specifications such as the X/Open Portability Guide Version 4 (XPG4).

Open System Services (OSS). An open system environment available for interactive or programmatic use with the HP NonStop™ operating system. Processes that run in the

OSS environment usually use the OSS application program interface. Interactive users of the OSS environment usually use the OSS shell for their command interpreter.

Synonymous with Open System Services (OSS) environment. Contrast with

Guardian

Open System Services (OSS) environment. The HP NonStop™ Open System Services

(OSS) application program interface (API), tools, and utilities.

opener table. A data structure maintained by a server process containing information about processes that have the server process open. Typically, the server uses this table to check that incoming requests originate from valid openers.

operating system. See

operational environment. The conditions under which your system performs. These conditions include the devices and communications lines that are made active and the system and application processes that are started at system startup.

OS. See

Open System Services (OSS) .

OSS. See

OSS environment. See

Open System Services (OSS) environment .

OSS process ID. In the Open System Services (OSS) environment, the unique identifier that identifies a process during the lifetime of the process and during the lifetime of the process group of that process.

OSS signal. A signal model defined in the POSIX.1 specification and available to TNS processes and TNS/R native processes in the OSS environment. OSS signals can be sent between processes.

OSS user ID. See

HP NonStop™ operating system user ID .

page. A unit of virtual storage for disks and processor memory. The size of a disk page is

2048 bytes. The size of a memory page varies depending on the processor type and the software release.

fully qualified file name .

Glossary -18

Glossary page mode

page mode. A mode of communication between a terminal and its I/O process in which the terminal stores up to a full page of data (1920 bytes) in its own memory before sending the page to the I/O process. Contrast with

conversational mode

PAID. See

process access ID (PAID)

PARAM. An association of an ASCII value with a parameter name made by the TACL

PARAM command. You can use PARAMs to pass parameter values to processes.

partially qualified file name. A file name in which only the right-hand file-name parts are specified. The remaining parts of the file name assume default values. Contrast with

pathname. In the Open System Services (OSS) file system and Network File System

(NFS), the string of characters that uniquely identifies a file within its file system. A pathname can be either relative or absolute. See also ISO/IEC IS 9945-1:1990

(ANSI/IEEE Std. 1003.1-1990 or POSIX.1), Clause 2.2.2.57.

pathname component. See filename

partitioned file. A logical file made up of several partitions that can reside on different disks.

Generic key values determine the partition on which a given record resides.

permanent disk file. A file that remains on disk until it is explicitly purged.

persistent process. A process that must always be either waiting, ready, or executing.

These processes are usually controlled by a monitor process that checks on the status of persistent processes and restarts them if necessary.

PFS. See

process file segment (PFS) .

physical memory. The semiconductor memory that is part of every processor module.

PIN. See

process identification number (PIN) .

primary extent. The first contiguous area of disk allocated to a file. See also

segment .

primary key. A unique value that identifies a record in a structured disk file.

primary path. The path between the processor module and controller that is currently being used.

priority. An indication of the precedence with which a process gains access to the instruction processing unit.

process. A program that has been submitted to the operating system for execution.

Multiple submissions of the same program run multiple processes.

process access ID (PAID). A user ID used to determine whether a process can make requests to the system, for example to open a file, stop another process, and so on.

creator access ID (CAID) .

Glossary -19

Glossary process control block (PCB)

The process access ID is usually the same as the creator access ID but it can be different; the owner of the corresponding object file can set the object file security such that it runs with a process access ID equal to the user ID of the file owner, rather than the creator of the process. Contrast with

process control block (PCB). An operating system data structure that contains information about the resources and environment of a process.

process descriptor. A process name returned by a Guardian procedure call.

process environment. The state and contents of the code and data spaces, stacks, and register values that exist when the processor module is executing instructions that are part of a user or system process.

process file name. A file name that identifies a process.

process file segment (PFS). An extended data segment that is automatically allocated to every process and contains operating system data structures, file-system data structures, and memory-management pool data structures.

process handle. A D-series 20-byte data structure that identifies a named or unnamed process in the network. A process handle identifies an individual process; thus, each process of a process pair has a unique process handle.

process ID. In the Guardian environment, the content of a 4-integer array that uniquely identifies a process during the lifetime of the process.

process identification number (PIN). A number that uniquely identifies a process running in a processor. The same number can exist in other processors in the same system.

See also

process ID .

process name. A name that can be assigned to a process when the process is created. A process name uniquely identifies a process or process pair in a system.

process pair. Two processes created from the same object file running in a way that makes one process a backup process of the other. Periodic checkpointing ensures that the backup process is always ready to take over from the primary if the primary process should fail. The process pair has one process name but each process has a different process identification number (PIN).

process qualifier. A suffix to a process file name that gets passed to a process when the process is opened. Its use is application-dependent.

process sequence number. A subpart of a process file name that allows the process to be identified over time.

processor. (1) A functional unit of a computer that reads program instructions, moves data between processor memory and the input/output controllers, and performs arithmetic operations. Because a processor is composed of several hardware components that

central processing unit (CPU) , but HP NonStop™ servers

Glossary -20

Glossary program reside in different enclosures, it is sometimes called a logical processor. A processor is sometimes referred to as a

have multiple cooperating processors rather than a single CPU. (2) One or more computer chips, typically mounted on a logic board, that are designed to perform data processing or to manage a particular aspect of computer operations.

program. See program file .

program file. An executable object code file containing a program’s main routine plus related routines statically linked together and combined into the same object file. Other routines shared with other programs might be located in separately loaded libraries. A program file can be named on a RUN command; other code files cannot. See also

object code file .

ready process. A process that is prepared to become active.

read-only data segment. An extended data segment, the contents of which a process can read but cannot alter. The contents of a read-only data segment can be shared across processors.

record block. A collection of data records written to or read from a mass storage medium using one I/O operation. Record blocks are usually used with magnetic tape to speed

I/O.

record lock. A lock held by a process or a transaction that restricts access to that record by other processes.

reduced instruction-set computing (RISC). A processor architecture based on a relatively small and simple instruction set, a large number of general-purpose registers, and an optimized instruction pipeline that supports high-performance instruction execution. Contrast with

complex instruction-set computing (CISC) .

register-exact point. A synchronization location within an accelerated object file at which both of these statements are true:

All live TNS registers plus all values in memory are the same as they would be if the object file were running in TNS mode or TNS interpreted mode or on a TNS system.

All accelerator code optimizations are ended.

Register-exact points are a small subset of all memory-exact points. Procedure entry and exit locations and call-return sites are usually register-exact points. All places where the program might switch into or from TNS mode or TNS interpreted mode are register-exact points. Contrast with

message system

and nonexact point

relative file. A file in which each new record is stored at the relative record location specified by its primary key, and whose primary key is a relative record number.

Records can be updated or deleted. Contrast with

key-sequenced file

and

entrysequenced file .

release version update (RVU) .

Glossary -21

Glossary relative pathname

relative pathname. In the Open System Services (OSS) file system and Network File

System (NFS), a pathname that does not begin with a slash (

) character. A relative pathname is resolved beginning with the current working directory. Contrast with

absolute pathname .

release version update (RVU). A collection of compatible revisions of HP NonStop operating system software products, identified by an RVU ID, and shipped and supported as a unit. An RVU consists of the object modules, supporting files, and documentation for the product revisions. An RVU also includes a set of documentation for the overall RVU.

rendezvous. A distributed operation that exchanges data to achieve synchronization among the processor elements of a logical processor.

RVU. See

reply. A response to a requester process by a server process. Contrast with

request .

request. A message formatted and sent to a server by a requester. Requests also include status messages such as CPU up and CPU down messages, which are placed on the intended recipient’s process message queue ($RECEIVE file) by the operating system.

Contrast with

reply .

requester. A process that initiates interprocess communication by sending a request to another process. Contrast with

server

response. See

reply .

retryable error. An error condition returned by the file system that can be corrected by repeating the operation that caused the error. Sometimes operator intervention is required before the retry, for example to put paper into an empty printer. Contrast with

nonretryable error .

RISC. See

reduced instruction-set computing (RISC)

RISC instructions. Register-oriented 32-bit machine instructions that are directly executed on TNS/R processors. RISC instructions execute only on TNS/R systems, not on TNS systems. Contrast with

TNS instructions .

segment. In general, a contiguous sequence of logically related pages of virtual memory.

The pages of the segment are individually swapped in and out of physical memory as needed. Within a loadable object file, one of the portions of the file that is mapped as one unit into virtual memory as the file is loaded. See also

code segment and

data segment .

segment ID. A number that identifies an extended data segment and specifies the kind of extended data segment to allocate.

process sequence number .

Glossary -22

Glossary selectable segment

selectable segment. A type of logical segment formerly known as an extended data segment. The data area for a selectable segment always begins with relative segment

4, and this area can be dynamically switched among several selectable segments by calls to the Guardian SEGMENT_USE_ procedure. The effect is similar to a rapid overlaying of one large data area. See also

logical segment and

flat segment .

sequence number. See

server. (1) An implementation of a system used as a stand-alone system or as a node in an

Expand network. (2) A combination of hardware and software designed to provide services in response to requests received from clients across a network. For example,

HP NonStop™ servers provide transaction processing, database access, and other services. (3) A process or program that provides services to a client or a requester.

Servers are designed to receive request messages from clients or requesters; perform the desired operations, such as database inquiries or updates, security verifications, numerical calculations, or data routing to other computer systems; and return reply messages to the clients or requesters. A server process is a running instance of a server program.

shared data segment. An extended data segment that can be accessed by more than one process.

shared memory. An interprocess communication mechanism that allows two or more processes to share a given region of memory.

Shared Millicode Library. An intrinsic library containing privileged or TNS-derived millicode routines used by many native-compiled programs and by emulated TNS programs.

This library includes efficient string-move operations, TNS floating-point emulation, and various privileged-only operations. These routines are mode independent. They comply with native calling conventions but can be directly invoked from any mode without changing execution modes.

shared run-time library (SRL). An object file that the operating system links to a program file at run time. See also

TNS/R native shared run-time library (TNS/R native SRL) .

signal. A means by which a process can be notified of or affected by an event occurring in the system. Some signals are used to notify a process when an error not related to input or output has occurred. See also

TNS/R native signal and

OSS signal . Contrast

with

trap .

signal handler. A procedure that is executed when a signal is received by a process.

single-threaded process. A process that performs only one operation at a time. Contrast with

multithreaded process

site update tape (SUT). One or more tapes that contain each target system’s site-specific subvolume and various products. Each product contains a softdoc and a complete set of files. A SUT is delivered with every new HP NonStop™ system and can be ordered whenever a new release version update (RVU) of the system software is available. A

shared run-time library (SRL) .

Glossary -23

Glossary SRL full SUT contains the current RVU of the HP NonStop operating system and all product software that has been ordered with it. A partial SUT contains a subset of products for the current RVU.

SRL. See

startup sequence. A convention for sending and receiving certain messages while starting a new process. By convention, the new process receives an Open message, followed by a Startup message, an Assign message for each ASSIGN in effect, a Param message if there are any PARAMs in effect, and then a Close message.

state information. In active backup programming, information about a program’s execution environment that is periodically sent from the primary process to the backup process.

In the event of a primary process failure, the backup process uses the state information to take over execution at or near the logical point of failure.

stop mode. An attribute that a process can use to protect itself from being stopped by other processes.

structured file. A disk file in which records are saved according to a predefined structure.

See

relative file .

key-sequenced file , and

entry-sequenced file for examples. Contrast

with

unstructured file .

subvolume. A group of files stored on disk. These files all have the same subvolume name but each has a different file ID. For example, $DATA.INFO identifies the subvolume named INFO on the volume $DATA. An example of a file name is

$DATA.INFO.RESULTS.

super ID. On HP NonStop™ systems, a privileged user who can read, write, execute, and purge all files on the system. The super ID is usually a member of a system-supervisor group.

The super ID has the set of special permissions called appropriate privileges. In the

Guardian environment, the structured view of the super ID, which is (255, 255), is most commonly used. In the Open System Services (OSS) environment, the scalar view of the super ID, which is 65535, is most commonly used.

superuser. See

super ID

SUT. See

site update tape (SUT) .

SYS

subvolume. A subvolume on the $SYSTEM volume where the new version of the

HP NonStop™ operating system image is located. Also located on the SYS

subvolume is system-dependent and release version update (RVU)-dependent software.

is an octal number in the range %00 through %77.

system. All the processors, controllers, firmware, peripheral devices, software, and related components that are directly connected together to form an entity that is managed by one HP NonStop™ operating system image and operated as one computer.

HP Tandem Advanced Command Language (TACL) .

Glossary -24

Glossary System Code (SC)

System Code (SC). See

TNS code space

system code. A logically distinct part of the HP NonStop™ operating system that consists of operating system procedures shared by all processors.

system entry-point (SEP) table. A table used on TNS systems that stores the XEP entry value for each TNS operating system procedure entry point.

system generation. The process of creating an operating system to support a particular system configuration and release version update (RVU).

System Library (SL). See

TNS code space .

system library. A logically distinct part of the HP NonStop™ operating system that consists of user-callable library procedures and kernel procedures.

system process. (1) A privileged process that comes into existence at system-load time and exists continuously for a given configuration for as long as the processor remains operable. (2) An HP NonStop™ operating system process, such as the memory manager, the monitor, and the input/output (I/O) control processes. The files containing system processes are invoked by ALLPROCESSORS paragraph entries. (3) A part of a single copy of the HP NonStop operating system with Open System Services (OSS) interfaces. A system process does not have an OSS process ID.

TACL. See

TAL. See HP Transaction Application Language (TAL) .

temporary disk file. A file stored on disk that will be purged automatically as soon as the process that created it stops.

TIM. See

HP NonStop™ Technical Library (NTL) .

TNS. Refers to fault-tolerant HP computers that support the HP NonStop™ operating system and are based on microcoded complex instruction-set computing (CISC)

technology. TNS systems run the TNS instruction set. Contrast with TNS/R

and

TNS/E .

TNS accelerated mode. A TNS emulation environment on a TNS/R or TNS/E system in which accelerated TNS object files are run. TNS instructions have been previously translated into optimized sequences of MIPS or Intel® Itanium® instructions. TNS accelerated mode runs much faster than TNS interpreted mode. Accelerated or interpreted TNS object code cannot be mixed with or called by native mode object

TNS/R native mode and

TNS/E native mode

TNS C compiler. The C compiler that generates TNS object files. Contrast with TNS/E native compiler .

Shared Millicode Library .

Glossary -25

Glossary TNS code segment

TNS code segment. One of up to 32 128-kilobyte areas of TNS object code within a TNS code space. Each segment contains the TNS instructions for up to 510 complete routines.

TNS code segment identifier. A seven-bit value in which the most significant two bits encode a code space (user code, user library, system code, or system library) and the five remaining bits encode a code segment index in the range 0 through 31.

TNS code segment index. A value in the range 0 through 31 that indexes a code segment within the current user code, user library, system code, or system library space. This value can be encoded in five bits.

TNS code space. One of four addressable collections of TNS object code in a TNS process. They are User Code (UC), User Library (UL), System Code (SC), and System

Library (SL). UC and UL exist on a per-process basis. SC and SL exist on a per-node basis.

TNS compiler. A compiler in the TNS development environment that generates 16-bit TNS object code following the TNS conventions for memory, stacks, 16-bit registers, and call linkage. The TNS C compiler is an example of such a compiler. Contrast with

TNS/E native compiler .

TNS Emulation Library. A public dynamic-link library (DLL) on a TNS/E system containing the TNS Object Code Interpreter (OCI), millicode routines used only by accelerated mode, and millicode for switching among interpreted, accelerated, and native execution modes. See also

TNS emulation software. The set of tools, libraries, and system services for running TNS object code on TNS/E systems and TNS/R systems. On a TNS/E system, the TNS emulation software includes the TNS Object Code Interpreter (OCI), the TNS Object

Code Accelerator (OCA), and various millicode libraries. On a TNS/R system, the TNS emulation software includes the TNS Object Code Interpreter (OCI), the Accelerator, and various millicode libraries.

TNS instructions. Stack-oriented, 16-bit machine instructions that are directly executed on

TNS systems by hardware and microcode. TNS instructions can be emulated on

TNS/E and TNS/R systems by using millicode, an interpreter, and either translation or acceleration. Contrast with

reduced instruction-set computing (RISC)

and Intel®

Itanium® instructions .

TNS interpreted mode. A TNS emulation environment on a TNS/E system in which individual TNS instructions in a TNS object file are directly executed by interpretation rather than permanently translated Intel® Itanium® instructions. TNS interpreted mode runs slower than TNS accelerated mode. Each TNS instruction is decoded each time it is executed, and no optimizations between TNS instructions are possible. TNS interpreted mode is used when a TNS object file has not been accelerated for that hardware system, and it is also sometimes used for brief periods within accelerated object files. Accelerated or interpreted TNS object code cannot be mixed with or called

by native mode object code. See also TNS Object Code Interpreter (OCI) . Contrast

Glossary -26

Glossary TNS library

with

TNS accelerated mode ,

TNS/R native mode , and

TNS/E native mode .

TNS library. A single, optional, TNS-compiled loadfile associated with one or more application loadfiles. If a user library has its own global or static variables, it is called a

TNS shared run-time library (TNS SRL). Otherwise it is called a User Library (UL).

TNS mode. The operational environment in which TNS instructions execute by inline

interpretation. See also accelerated mode .

TNS object code. The TNS instructions that result from processing program source code with a TNS compiler. TNS object code executes on TNS, TNS/R, and TNS/E systems.

TNS Object Code Accelerator (OCA). A program optimization tool that processes a TNS object file and produces an accelerated file for a TNS/E system. OCA augments a TNS object file with equivalent Intel® Itanium® instructions. TNS object code that is accelerated runs faster on TNS/E systems than TNS object code that is not

accelerated. See also Accelerator and

TNS Object Code Interpreter (OCI) .

TNS Object Code Interpreter (OCI). A program that processes a TNS object file and emulates TNS instructions on a TNS/E system without preprocessing the object file.

See also

TNS Object Code Accelerator (OCA) .

TNS object file. An object file created by a TNS compiler or the Binder. A TNS object file contains TNS instructions. TNS object files can be processed by the Accelerator or by the TNS Object Code Accelerator (OCA) to produce to produce accelerated object files. A TNS object file can be run on TNS, TNS/R, and TNS/E systems.

TNS procedure label. A 16-bit identifier for an internal or external procedure used by the

TNS object code of a TNS process. The most-significant 7 bits are a TNS code segment identifier: 2 bits for the TNS code space and 5 bits for the TNS code segment index. The least-significant 9 bits are an index into the target segment's procedure entry-point (PEP) table. On a TNS/E system, all shells for calling native library procedures are segregated within the system code space. When the TNS code space bits of a TNS procedure label are %B10, the remaining 14 bits are an index into the system's shell map table, not a segment index and PEP index.

TNS process. A process whose main program object file is a TNS object file, compiled using a TNS compiler. A TNS process executes in interpreted or accelerated mode while within itself, when calling a user library, or when calling into TNS system libraries.

A TNS process temporarily executes in native mode when calling into native-compiled parts of the system library. Object files within a TNS process might be accelerated or not, with automatic switching between accelerated and interpreted modes on calls and

returns between those parts. Contrast with TNS/R native process

and

TNS/E native process .

TNS stack segment. See TNS user data segment .

Glossary -27

Glossary TNS State Library for TNS/E

TNS State Library for TNS/E. A library of routines to access and modify the TNS state of a

TNS process running on TNS/E.

TNS system library. A collection of HP-supplied TNS-compiled routines available to all

TNS processes. There is no per-program or per-process customization of this library.

All routines are immediately available to a new process. No dynamic loading of code or creation of instance data segments is involved. See also

must fit within the first 64 kilobytes. See also compiler extended-data segment .

TNS user data segment. In a TNS process, the segment at virtual address zero. Its length is limited to 128 kilobytes. A TNS program's global variables, stack, and 16-bit heap

TNS user library. A user library available to TNS processes in the Guardian environment.

TNS word. An instruction-set-defined unit of memory. A TNS word is 2 bytes (16 bits) wide,

beginning on any 2-byte boundary in memory. See also Intel® Itanium® word

native ,

and

word .

TNS/E. Refers to fault-tolerant HP computers that support the HP NonStop™ operating system and are based on the Intel® Itanium® processor. TNS/E systems run the

Itanium instruction set and can run TNS object files by interpretation or after acceleration. TNS/E systems include all HP NonStop™ systems that use NSE-x processors. Contrast with

temporary disk file .

TNS/E library. A TNS/E native-mode library. TNS/E libraries are always dynamic-link libraries (DLLs); there is no native shared runtime library (SRL) format.

TNS/E native compiler. A compiler in the TNS/E development environment that generates

TNS/E native object code, following the TNS/E native-mode conventions for memory, stack, registers, and call linkage. The TNS/E native C compiler is an example of such a

compiler. Contrast with TNS compiler .

TNS/E native mode. The primary execution environment on a TNS/E system, in which native-compiled Intel® Itanium® object code executes, following TNS/E native-mode compiler conventions for data locations, addressing, stack frames, registers, and call linkage. Contrast with

TNS interpreted mode

and TNS accelerated mode .

TNS/E native object code. The Intel®® Itanium® instructions that result from processing program source code with a TNS/E native compiler. TNS/E native object code executes only on TNS/E systems, not on TNS systems or TNS/R systems.

TNS/E native object file. An object file created by a TNS/E native compiler that contains

Intel® Itanium® instructions and other information needed to construct the code spaces and the initial data for a TNS/E native process.

TNS/E native process. A process initiated by executing a TNS/E native object file. Contrast with

TNS process .

Total Information Manager (TIM). See HP NonStop™ Technical Library (NTL) .

Glossary -28

Glossary TNS/E native signal

TNS/E native signal. A signal model available to TNS/E native processes in both the

Guardian and Open System Services (OSS) environments. TNS/E native signals are used for error exception handling.

TNS/E native user library. A user library available to TNS/E native processes in both the

Guardian and Open System Services (OSS) environments. A TNS/E native user library is implemented as a TNS/E native dynamic-link library (DLL).

TNSVU. A tool used to browse through TNS object files that have been accelerated by the

TNS Object Code Accelerator (OCA). TNSVU displays Intel® Itanium® code in addition to TNS code.

TNS/R. See

NonStop™ Series TNS/R .

TNS/R library. A TNS/R native-mode library. For a PIC-compiled application, TNS/R libraries can be dynamic-link libraries (DLLs) or hybridized native shared runtime libraries (SRLs). For an application that is not PIC compiled, TNS/R libraries can only be native SRLs.

TNS/R native mode. The operational environment in which native-compiled RISC instructions execute.

TNS/R native object code. The RISC instructions that result from processing program source code with a TNS/R native compiler. TNS/R native object code executes only on

TNS/R systems, not on TNS systems.

TNS/R native object file. A file created by a TNS/R native compiler that contains RISC instructions and other information needed to construct the code spaces and the initial data for a TNS/R native process.

TNS/R native process. A process initiated by executing a TNS/R native object file.

TNS/R native shared run-time library (TNS/R native SRL). A shared run-time library

(SRL) available to TNS/R native processes in the Guardian and OSS environments.

TNS/R native SRLs can be either public or private. A TNS/R native process can have multiple public SRLs but only one private SRL.

TNS/R native signal. A signal model available to TNS/R native processes in the Guardian and OSS environments. TNS/R native signals are used for error exception handling.

TNS/R native user library. A user library available to TNS/R native processes in the

Guardian and OSS environments. A TNS/R native user library is implemented as a special private TNS/R native shared run-time library.

transfer mode. The protocol by which data is transferred between a terminal and the computer system. See

conversational mode and

page mode .

NonStop™ operating system user ID . The UID is used in the OSS environment for

Glossary -29

Glossary trap

trap. A software mechanism that stops program execution and holds the cause of a processing problem. In TNS and accelerated execution modes, traps occur as the result of errors that are not related to input or output. Contrast with

signal .

trap handler. A location in a program where execution begins if a trap occurs. A process can specify a trap handler by a call to the Guardian ARMTRAP procedure.

two-way communication. A form of interprocess communication in which the sender of a message (requester process) expects data in the reply from the receiver (server process). Contrast with

one-way communication .

UID. A nonnegative integer that uniquely identifies a user within a node.

In the Open System Services (OSS) environment, the UID is the scalar view of the

functions normally associated with a UNIX user ID.

unnamed process. A process to which a process name was not assigned when the process was created. Contrast with

named process .

unstructured file. A disk file that has no structure known to the disk process. Contrast with

structured file .

user code. A logically distinct part of the HP NonStop™ operating system that consists of the code for user processes.

user database. A database within an HP NonStop™ node that contains the user name, user ID, group ID, initial working directory, and initial user program for each user of the node.

user data stack. The first 64K bytes in the user data segment in a TNS process. It is the only 16-bit byte-addressable area. It is the primary area for static and dynamic data as well as for saving procedure call and return information.

user ID. The unique identification of a user within a node.

In the Guardian environment, the term user ID usually means the structured view of the

HP NonStop™ operating system user ID . In the Open System Services (OSS)

environment, the term user ID usually means the scalar view of the HP NonStop™ operating system user ID—a number called the

UID

User Library (UL). See

TNS code space

user library. (1) An object code file that the operating system links to a program file at run

time. A program can have only one user library. See also TNS user library

and TNS/E native user library

user name. A string that uniquely identifies a user within the user database for a node.

Glossary -30

Glossary user process

user process. A process whose primary purpose is to solve a user’s problem. A user process is not essential to the availability of a processor module. A user process is created only when the user explicitly creates it. Contrast with

system process .

virtual memory. A range of addresses that processes use to reference real storage, where real storage consists of physical memory and disk storage.

volume. A disk drive or a pair of disk drives that forms a mirrored disk.

word. An instruction-set-defined unit of memory that corresponds to the width of registers and to the most common and efficient size of memory operations. A TNS word is

2 bytes (16 bits) wide, beginning on any 2-byte boundary in memory. A MIPS RISC word is 4 bytes (32 bits) wide, beginning on any 4-byte boundary in memory. An Intel®

Itanium® word is also 4 bytes (32 bits) wide, beginning on any 4-byte boundary in memory.

Glossary -31

Index

A

Accelerated code variances with TNS code

TNS code variances with Accelerated code

2-4

Accelerated mode executing in

Accelerated object file size

1-3

Accelerating progams with embedded SQL

strategy

4-1

Acceleration cross platform

Accelerator

listings

using

using with OCA

Accelerator command listing produced by

4-6

Addition operations

Address misalignment causes of

handling

symptoms of

tracing facility for

Addresses of P-relative objects, passing

Addressing operations

2-8

ALLOCATESEGMENT system procedure

Arithmetic operations

ARMTRAP

3-3

ARMTRAP system procedure

2-5 ,

3-3

B

Binder region

3-2 ,

3-8

Index -1

Bit-shift operators

2-12

C

C generic pointers

3-8

model-dependent libraries

run-time libraries

C data types double

float

long

long long

unsigned long

void*

c89 utility flags

Checking segment limits

CISC

COBOL

COBOL85

Code condition diagnosing inheritance

5-5

inheritance

5-5

managing inheritance

5-5

Code space specifying

CODE statement

CODE statements

Comment facility

Complex instruction-set computing

(CISC)

Glossary-4

Cross platform acceleration

1-5

C/C++ function prototypes

odd-byte references

2-9

Index

D

Data block relationship between global and local

Data misalignment

See Address misalignment

Data segment system global

user global

Debug

Debugger

Debugging differences between TNS and accelerated programs

memory-exact points

native systems

nonexact points

strategy

synchronization points

TNS/E systems

with Native Inspect

with Visual inspect

Debugging OCA programs

Default misalignment handling method

Disk space

Division operations

Doublewords

Double-word shift instructions

DROP

DROP statements

Dynamic shift counts

E

EMS

2-14

ENV register

EPTRACE using with OCA

Error 10

8-5

Index -2

Error 11

Error 12

Error 13

Error 14

Error 17

Error 18

Error 19

Error 2

Error 20

Error 21

Error 22

Error 24

Error 25

Error 26

Error 3

Error 34

Error 4

Error 5

Error 6

Error 7

Error 9

Error messages

Event Management Service

2-14

Execution mode

2-9

Execution modes accelerated

TNS

Extended pointers

2-10

Extended segment size

extended segment size

F

FAIL misalignment handling method

FORTRAN

FORTRAN, Pascal

Functions prototypes

that return a struct

$OVERFLOW

Index

G

G segment

general considerations

2-1 ,

Global data block

H

Help, online

4-5

I

IGNORERn

IGNORE_CC

usage considerations

IGNORE_IRn

usage considerations

Inherits register

INHERITSCC

usage considerations

INHERITSRn

usage considerations

INHERITSRn option

Inline code expansion

1-4

Inspect symbols region

Instruction Failure trap (trap #1)

See Kernel Managed Swap Facility

Invoking OCA

4-2

K

Kernel Managed Swap Facility

Glossary-12

KMSF

L

Listings, OCA

4-6

Local data block

Locating trap handlers

M

Machine-level debugging

6-4 ,

Memory requirements

1-3

Index -3

Memory-exact points

Messages error

warning

Millicode

MISALIGNLOG attribute (SCF)

2-14 ,

Misalignment

See Address misalignment

Misalignment tracing facility

2-13

Model-dependent libraries

Multiplication operations

N

Native Inspect

using with OCA

NATIVEATOMICMISALIGN attribute

(SCF)

Nonexact point

7-2

Nonprivileged programs

NonStop Kernel Open System Services

(OSS)

Glossary-16

Non-standard procedure call

NOROUND misalignment handling method

2-16

O

OBEY

Obey Files

Obeyfile using

Object Code Accelerator (OCA) functional overview

1-1

introduction

1-1

resource requirements

1-3

using with Binder

using with Inspect Symbols region

OCA command usage examples

debugging programs

error messages

8-1

Index

OCA invoking

listings

listings example

option list syntax

specifying file names

specifying options

use strategy

using

using with Accelerator

6-3

using with EPTRACE

using with Native Inspect

using with TNSVU (TNS Viewer)

6-3

using with Visual Inspect

warning messages

8-1

OCA command

IGNORERn

IGNORE_CC

INHERITSRn

input-file

obey-filename

options

output-file

run-options

OCA command options

IGNORE_CC

IGNORE_IRn

INHERITSCC

INHERITSRn

OBEY

OUTPUT_FILE

RETURNSR

RETURNSRn

RETURNVALSIZE

OCA commands

INHERITSCC

5-8

options

5-2

Index -4

OCA options

INHERITSRn

RETURNSRn

RETURNVALSIZE

Odd-byte references

Online help

Operating system extended segment size

privileged instructions

Optimization

OSS signal defined

Output filename

OUTPUT_FILE

Overflow results

P

P register

Page size

Pascal, TAL

Passing parameters in registers

Pointers extended

uninitialized

void *

Preparing programs for acceleration

variances in accelerated code

Preparing programs for TNS/E systems

Data Alignment

variances in TNS and Accelerated code

Privileged instructions

Procedure calls non-standard

Procedure name conflicts

3-11

Production systems

PROGID attribute

4-4

Program counter register

Index

P-relative objects, passing the address of

Run-time libraries

Q

Quadruplewords

2-10

R

RCPU instruction

Reduced instruction-set computing

(RISC)

inheritance

managing inheritance

Registers inheritance of

3-4

passing parameters in

3-4

7-2

Relationship between global and local data blocks

Reserved instructions

RESIZESEGMENT system procedure

Results after an overflow

Return RP values

Return value sizes

Returning parameters in registers

RETURNSR

RETURNSRn

RETURNSRn option

RETURNVALSIZE

ReturnValSize option

RISC

RISC instructions

ROUND (default) misalignment handling method

2-16

Rounding down addresses

RP register

Index -5

S

SCF user interface misalignment handling and

misalignment tracing facility and

2-14

Segment limits

Segment wrapping

2-8

SEGMENT_ALLOCATE_ system procedure

SG pointers

SG segment

Shared run-time libraries, accelerating

Shared run-time library

Shift instructions

2-11

SIGILL signal (signal #4)

Signal defined

Glossary-23

Signal handler defined

Glossary-23

Single-word shift instructions

2-12

5-2 ,

Source-level debugging

6-4 ,

Specifying code space

SQL

SQLCOMP

STACK statements

STACK statment

Stack wrapping

Subsystem Control Facility

See SCF user interface

Subtraction operations

Synchronization points

memory-exact

nonexact

System data segment

System library translating

Index

System procedures

ALLOCATESEGMENT

ARMTRAP

RESIZESEGMENT

SEG MENT_ALLOCATE_

T

TAL

bit-shift operators

CODE statement

CODE statements

DROP statements

odd-byte references

STACK statement

STACK statements

USE statement

USE statements

$OVERFLOW function

?RP directive

TAL data types

FIXED(n)

INT(32)

INT(64)

REAL

REAL(64)

TNS machine state

TNS mode, executing in

TNS object file, size of

TNS opcodes

TNS register

TNS Registers

TNS system access to SG

checking segment limits

instruction set

overflow results

privileged instructions

segments

TNSMISALIGN attribute (SCF)

TNSVU using with OCA

TNSVU (TNS Viewer)

TNS/E system checking segment limits

overflow results

page size

segments

TNS/R native signal defined

Glossary-29

TOTQ instruction

Tracing facility

2-13

Transitions into TNS code

Translating system library

user library

Trap defined

Trap handler defined

Trap handlers checking overflow

using the ENV register

using the P register

using the program counter

using the register stack

variances

Trap #1

U

5-2 ,

UL option

Uninitialized pointers

2-10

Usage considerations

IGNORE_CC

IGNORE_IRn

INHERITSCC

INHERITSRn

Index -6

Index

Usage considerations

OBEY command

SL command

UL command

USE statement

User data segment

User libraries accelerating

User library translating

Using OCA

4-1

Using SQL

V

Variances addresses of P-relative objects

between TNS and Accelerated code

2-4

ENV register

global and local data blocks

odd-byte references

2-9

passing parameters in registers

3-3

privileged instructions

procedure calls

procedure name conflicts

registers

SG pointers

shift instructions

stack wrapping

trap handlers

Visual Inspect

using with OCA

W

Warning 15

Warning 16

Warning 23

Warning messages

Warnings

Special Characters

$OVERFLOW function

?RP directive

3-8