Object Code Accelerator for TNS/X (OCAX)
Manual
HP Part Number: 746698-002
Published: April 2015
Edition: L15.02 and subsequent L-series RVUs
© Copyright 2015 Hewlett-Packard Development Company, L.P.
Legal Notice
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor’s standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall
not be liable for technical or editorial errors or omissions contained herein.
Export of the information contained in this publication may require authorization from the U.S. Department of Commerce.
Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation.
Intel, Pentium, and Celeron are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
Java is a trademark of Oracle and/or its affiliates.
Motif, OSF/1, UNIX, X/Open, and the "X" device are registered trademarks, and IT DialTone and The Open Group are trademarks of The Open
Group in the U.S. and other countries.
Open Software Foundation, OSF, the OSF logo, OSF/1, OSF/Motif, and Motif are trademarks of the Open Software Foundation, Inc. OSF MAKES
NO WARRANTY OF ANY KIND WITH REGARD TO THE OSF MATERIAL PROVIDED HEREIN, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. OSF shall not be liable for errors contained herein or for
incidental consequential damages in connection with the furnishing, performance, or use of this material.
© 1990, 1991, 1992, 1993 Open Software Foundation, Inc. The OSF documentation and the OSF software to which it relates are derived in part
from materials supplied by the following:© 1987, 1988, 1989 Carnegie-Mellon University. © 1989, 1990, 1991 Digital Equipment Corporation.
© 1985, 1988, 1989, 1990 Encore Computer Corporation. © 1988 Free Software Foundation, Inc. © 1987, 1988, 1989, 1990, 1991
Hewlett-Packard Company. © 1985, 1987, 1988, 1989, 1990, 1991, 1992 International Business Machines Corporation. © 1988, 1989
Massachusetts Institute of Technology. © 1988, 1989, 1990 Mentat Inc. © 1988 Microsoft Corporation. © 1987, 1988, 1989, 1990, 1991,
1992 SecureWare, Inc. © 1990, 1991 Siemens Nixdorf Informationssysteme AG. © 1986, 1989, 1996, 1997 Sun Microsystems, Inc. © 1989,
1990, 1991 Transarc Corporation.OSF software and documentation are based in part on the Fourth Berkeley Software Distribution under license
from The Regents of the University of California. OSF acknowledges the following individuals and institutions for their role in its development: Kenneth
C.R.C. Arnold, Gregory S. Couch, Conrad C. Huang, Ed James, Symmetric Computer Systems, Robert Elz. © 1980, 1981, 1982, 1983, 1985,
1986, 1987, 1988, 1989 Regents of the University of California.
Contents
About This Manual........................................................................................7
Supported Release Version Updates (RVUs)..................................................................................7
Intended Audience....................................................................................................................7
New and Changed Information in This Edition, 746698–002.........................................................7
How to Use This Manual...........................................................................................................7
Notation Conventions................................................................................................................7
General Syntax Notation......................................................................................................7
Publishing History.....................................................................................................................9
HP Encourages Your Comments..................................................................................................9
1 Introduction.............................................................................................11
How the Object Code Accelerator for TNS/X (OCAX) Works.......................................................11
OCAX Translation Mode.....................................................................................................12
Usage Consideration.....................................................................................................12
OCAX Resource Requirements..................................................................................................12
Cross-Platform Acceleration......................................................................................................13
2 Preparing Your Program for TNS/X Systems.................................................14
General Considerations...........................................................................................................14
Results After an Overflow....................................................................................................14
Detection Guideline.......................................................................................................15
Required Changes.........................................................................................................15
Example......................................................................................................................15
Checking Segment Limits....................................................................................................15
Detection Guidelines.....................................................................................................15
Required Change..........................................................................................................16
Extended Segment Size......................................................................................................16
Detection Guideline.......................................................................................................16
Required Change..........................................................................................................16
Variances in TNS and Accelerated Code...................................................................................16
Trap Handlers That Use the Register Stack.............................................................................17
Detection Guideline.......................................................................................................17
Required Change..........................................................................................................17
Trap Handlers That Use the Program Counter.........................................................................17
Detection Guideline.......................................................................................................18
Required Change..........................................................................................................18
Reserved Instructions...........................................................................................................18
Detection Guideline.......................................................................................................18
Required Change..........................................................................................................18
Passing the Addresses of P-Relative Objects...........................................................................18
Detection Guidelines.....................................................................................................18
Required Change..........................................................................................................19
Nonprivileged References to System Global Data...................................................................19
Detection Guidelines.....................................................................................................19
Required Change..........................................................................................................19
Example......................................................................................................................19
Segment Wrapping............................................................................................................19
Required Change..........................................................................................................19
Example......................................................................................................................19
Odd-Byte References..........................................................................................................20
Detection Guidelines.....................................................................................................21
Required Change..........................................................................................................21
Contents
3
Recommended Changes................................................................................................21
Example......................................................................................................................21
Shift Instructions With Dynamic Shift Counts..........................................................................22
Detection Guidelines.....................................................................................................22
Required Change..........................................................................................................23
Example......................................................................................................................23
Data Alignment in TNS and Accelerated Code...........................................................................23
Misalignment Tracing Facility...............................................................................................23
Misalignment Handling......................................................................................................24
3 Preparing Programs for Acceleration...........................................................26
General Considerations...........................................................................................................26
Run-Time Libraries..............................................................................................................26
User Libraries....................................................................................................................26
C Function Prototypes.........................................................................................................26
Binder and Inspect Symbols Regions.....................................................................................26
Variances in Accelerated Code................................................................................................27
Trap Handlers Using the ENV Registers.................................................................................27
Detection Guideline.......................................................................................................27
Required Change..........................................................................................................27
Passing Parameters in Registers............................................................................................27
Detection Guidelines.....................................................................................................28
Required Changes.........................................................................................................28
Examples.....................................................................................................................28
Arithmetic Left-Shift Sign Bit.................................................................................................29
Detection Guideline.......................................................................................................30
Required Change..........................................................................................................30
Example......................................................................................................................30
Non-Standard Procedure Call or Return RP Values..................................................................30
Required Changes.........................................................................................................30
Examples.....................................................................................................................31
Relationship Between Global and Local Data Blocks...............................................................32
Required Change..........................................................................................................33
Example......................................................................................................................33
Procedure Name Conflicts ..................................................................................................33
4 Using OCAX...........................................................................................34
Strategy for Using OCAX.........................................................................................................34
Invoking OCAX......................................................................................................................34
OCAX Command Usage Examples...........................................................................................35
Specifying the Code Space......................................................................................................35
Accelerating User Libraries and Shared Run-Time Libraries.......................................................35
Accelerating Programs With Embedded SQL..............................................................................36
Using Obey Files....................................................................................................................36
Comments.........................................................................................................................36
Example...........................................................................................................................36
Online Help...........................................................................................................................36
OCAX Listings........................................................................................................................37
5 OCAX Syntax and Option Summary...........................................................39
OCAX Syntax........................................................................................................................39
OCAX Options......................................................................................................................39
Translating a System Library................................................................................................40
SL Usage Considerations................................................................................................41
Translating a User Library...................................................................................................41
UL Usage Considerations...............................................................................................41
4
Contents
Specifying an Output File Name..........................................................................................41
Specifying an Obey File.....................................................................................................41
Obey Usage Considerations...........................................................................................41
Determining TNS Register Usage.........................................................................................42
Correcting a Function’s Return Values Size.............................................................................42
Diagnosing and Managing Register or Condition Code Inheritance..........................................42
Diagnosing Register or Condition Code Inheritance...........................................................42
Managing Register or Condition Code Inheritance............................................................43
IGNORE_IRn...........................................................................................................43
IGNORE_CC...........................................................................................................43
INHERITSRn.............................................................................................................43
INHERITSCC............................................................................................................44
IGNORE_IRn, IGNORE_CC, INHERITSRn, and INHERITSCC Usage Considerations..........44
6 Using OCAX With Other NonStop Tools.....................................................45
OCAX and Binder..................................................................................................................45
CHANGE.........................................................................................................................45
SHOW.............................................................................................................................45
STRIP................................................................................................................................46
OCAX and TNSVUX...............................................................................................................46
OCAX, OCA and Accelerator..................................................................................................46
Accelerating for Multiple Platforms.......................................................................................47
OCAX and NonStop Debugging Tools......................................................................................48
7 Debugging OCAX Programs......................................................................49
Differences Between Debugging TNS and Accelerated Programs..................................................49
Register-Exact points...........................................................................................................49
Memory-Exact Points..........................................................................................................50
Nonexact Points.................................................................................................................50
A Strategy for Debugging........................................................................................................50
8 Error and Warning Messages....................................................................51
Warning Messages.................................................................................................................51
Error Messages......................................................................................................................53
A Data Type Correspondence and Return Value Sizes......................................59
Glossary....................................................................................................63
Index.........................................................................................................85
Contents
5
Figures
1
2
3
4
5
6
7
8
9
The Acceleration Process...................................................................................................11
User Program Execution Modes on TNS/X Systems...............................................................12
Comparing TNS and Accelerated Object File Sizes Without a Symbols Region........................13
Comparing TNS and Accelerated Object File Sizes Without a Symbols Region........................13
Data Segments................................................................................................................20
Passing Parameters in Registers..........................................................................................29
The OCAX Translation Process...........................................................................................47
Translating Using Accelerator, OCA and OCAX..................................................................47
Translating Using OCA and OCAX....................................................................................48
Tables
1
2
3
4
5
6
7
8
TNS Misalignment Handling Methods................................................................................25
OCAX Options................................................................................................................40
Integer Types, Part 1.........................................................................................................59
Integer Types, Part 2.........................................................................................................60
Floating, Fixed, and Complex Types...................................................................................60
Character Types...............................................................................................................60
Structured, Logical, Set, and File Types................................................................................61
Pointer Types...................................................................................................................62
Examples
1
OCAX Online Help Example.............................................................................................37
About This Manual
OCAX allows you to improve the performance of programs that run on TNS/X systems. OCAX
optimizes TNS programs to take advantage of the TNS/X architecture and processes TNS object
files to produce accelerated object files.
Most TNS object code that has been accelerated runs faster on TNS/X systems than TNS object
code that has not been accelerated. Most programs written for TNS systems do not require changes
to run on TNS/X systems, either with or without acceleration.
The OCAX Manual describes:
•
How OCAX works and how to determine which programs to accelerate
•
The changes that you must make to run your TNS object on TNS/X 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 OCAX
•
OCAX syntax and command options
•
How to set OCAX options to eliminate certain variances
Supported Release Version Updates (RVUs)
This publication supports L15.02 and all subsequent L-series RVUs until otherwise indicated by its
replacement publication.
Intended 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 OCAX.
New and Changed Information in This Edition, 746698–002
This is a new manual.
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:
Read the following chapters:
Run a TNS program on a TNS/X system
Chapter 2, Preparing Your Program for TNS/X
Accelerate a TNS program
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Debug an accelerated program
Chapter 7, Debugging OCAX Programs
Understand errors and warning messages
Chapter 8, Error and Warning Messages
1, Introduction
2, Preparing Your Program for TNS/X
3, Preparing Programs for Acceleration
4, Using OCAX
5, OCAX Syntax and Option Summary
6, Using OCAX with Other NonStop
Notation Conventions
General Syntax Notation
This list summarizes the notation conventions for syntax presentation in this manual.
Supported Release Version Updates (RVUs)
7
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
Italic Letters
Italic letters, regardless of font, indicate variable items that you supply. Items not enclosed in
brackets are required. For example:
file-name
Computer Type
Computer type letters indicate:
•
C and Open System Services (OSS) keywords, commands, and reserved words. Type
these items exactly as shown. Items not enclosed in brackets are required. For example:
Use the cextdecs.h header file.
•
Text displayed by the computer. For example:
Last Logon: 14 May 2006, 08:02:23
•
A listing of computer code. For example
if (listen(sock, 1) < 0)
{
perror("Listen Error");
exit(-1);
}
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.
[ ] 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
{ } 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 }
8
| 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 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 ]…
Publishing History
Part Number
Product Version
Publication Date
746698–001
NA
February 2015
746698–001a
NA
March 2015
746698–002
NA
April 2015
HP Encourages Your Comments
HP encourages your comments concerning this document. We are committed to providing
documentation that meets your needs. Send any errors found, suggestions for improvement, or
compliments to [email protected].
Publishing History
9
Include the document title, part number, and any comment, error found, or suggestion for
improvement you have concerning this document.
10
1 Introduction
OCAX processes TNS object code to produce accelerated object code. On TNS/X systems,
accelerated object code runs significantly faster than TNS object code. This section describes how
OCAX works, how to determine which programs to accelerate, and the cost in time and space to
accelerate your programs.
How the Object Code Accelerator for TNS/X (OCAX) Works
OCAX 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 x86 instructions (accelerated object code).
“The Acceleration Process” (page 11) illustrates the acceleration process.
Figure 1 The Acceleration Process
OCAX produces for each TNS instruction its functional equivalent on the TNS/X system, in the
form of either:
•
A sequence of zero or more (usually more than one) x86 instructions
•
A call on a millicode routine
In the first and more common case, OCAX treats a TNS instruction as though it were a macro
instruction, expanding it into x86 instructions. In the second, OCAX 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 x86 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.
OCAX can produce only optimized x86 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.
“User Program Execution Modes on TNS/X Systems” (page 12) shows two of the execution modes
available to user programs on TNS/X systems: TNS mode and accelerated mode.
•
TNS mode is the operational environment in which TNS instructions execute. On TNS/X
systems, TNS instructions are implemented by millicode routines.
•
Accelerated mode is the operational environment in which x86 instructions generated by
OCAX execute. On TNS/X systems, x86 instructions execute directly on the x86 processor.
How the Object Code Accelerator for TNS/X (OCAX) Works
11
Figure 2 User Program Execution Modes on TNS/X Systems
OCAX runs on TNS/E and TNS/X systems, and produces the same output in both environments:
a file containing both the original TNS code and its x86 code equivalent. Accelerated object files
can run on both TNS/E and TNS/X systems, although TNS/E systems ignore the x86 code.
OCAX can process bound, executable object programs generated by B40 and later releases of
the C, COBOL85, FORTRAN, Pascal, and TAL compilers. OCAX processes executable object
programs that run only in the Guardian environment. (You cannot accelerate object programs
generated by the COBOL 74 compiler.)
OCAX 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 OCAX ENABLE
OFF command to disable inadvertent acceleration. For further information about Binder commands
that work with OCAX and the Binder Manual, see “OCAX and Binder” (page 45).
Usage Consideration
•
If a program calls a user library and that library is not already accelerated, procedures in
that library execute in TNS mode.
OCAX Resource Requirements
OCAX, like an optimizing compiler, is both CPU-intensive and memory-intensive. Try to run OCAX
on a lightly loaded processor with more than 16MB of physical memory. OCAX 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 OCAX. 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.
“Comparing TNS and Accelerated Object File Sizes Without a Symbols Region” (page 13) shows
that an accelerated object file, without a symbols region, requires about twice as much disk storage
space as the corresponding TNS object file.
12
Introduction
Figure 3 Comparing TNS and Accelerated Object File Sizes Without a Symbols Region
“Comparing TNS and Accelerated Object File Sizes Without a Symbols Region” (page 13) 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. OCAX produces more efficient code from source TNS
object files that contain a symbols region than those without the region.
Figure 4 Comparing TNS and Accelerated Object File Sizes Without a Symbols Region
The inline code expansion factor measures the worst-case increase in main memory required for
accelerated code. It is the number of bytes of x86 code divided by the number of bytes of TNS
code. The OCAX listing reports the inline code expansion factor.
The typical inline expansion factor in executable x86 code compared to TNS code is 5-7 times.
Cross-Platform Acceleration
OCAX is supported on L-series systems, enabling you to accelerate TNS object files on the TNS/X
platform for execution on the TNS/X platform. (You can execute a file with a TNS region only on
the TNS/X platform). The TNS/E acceleration equivalent, OCA, is supported on H-series, J-series
and L-series RVUs, enabling you to accelerate TNS object files for execution on the TNS/E platform.
With both the accelerators you can use the TNS/X platform to create files that are executed with
improved performance either on the TNS/E or the TNS/X platform.
Cross-Platform Acceleration
13
2 Preparing Your Program for TNS/X Systems
Most TNS programs written for the HP NonStop operating system run on TNS/X systems without
modification. Variances between TNS and TNS/X systems, however, might require modification
in some programs, particularly low-level TAL programs.
This chapter steps you through:
•
“General Considerations” (page 14), discusses hardware and software release issues that
affect moving programs between any two different models of HP NonStop systems.
•
“Variances in TNS and Accelerated Code” (page 16) discusses the changes you must make
to programs because of variances between TNS and TNS/X systems.
•
“Data Alignment in TNS and Accelerated Code” (page 23) discusses the data alignment
requirements for TNS code and the OCAX. 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/X 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/X systems
as they are on TNS systems.
All TNS instructions for integer multiplication and division operations (except the LMPY instruction)
on TNS/X 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/X systems:
IADD DADD QADD LMPY
ISUB DSUB QSUB
INEG DNEG QNEG
14
Preparing Your Program for TNS/X Systems
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, TNS/E, and TNS/X 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 2 Kbytes each on TNS CISC systems, 4 K or 16 Kbytes on TNS/R systems,
and 16 K or 64 Kbytes each on TNS/E and TNS/X 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 more cases of bad addresses
that are slightly too high, because of their smaller page sizes.
The following example shows a TNS/X system with an extended segment of 3.5 memory pages.
On TNS/X 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.
General Considerations
15
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/E and TNS/X systems, but not on TNS CISC. The starting addresses dynamically assigned
to flat segments may be different on TNS/E and TNS/X, and the dynamic limits on flat segment
sizes (due to other nearby segments) may be different on TNS/E and TNS/X.
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 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/X 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:
16
•
Trap handlers that use the register stack
•
Trap handlers that use the P register
•
Reserved instructions
Preparing Your Program for TNS/X Systems
•
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 TNS/X 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/X 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/X 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/X 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.
Variances in TNS and Accelerated Code
17
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;
trap_p := trap_p '+' 1;
trap_p := trap_p '-' 1;
! Location of the P register
! Undefined
! Undefined
Refer to “Trap Handlers That Use the Register Stack” (page 17) for guidelines on 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/X 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
•
16-bit address on TNS/X systems
•
32-bit extended address on TNS systems
However, if you pass a 32-bit extended address on TNS/X systems, programs access the specified
object and continue execution. This is a program error that TNS/X 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
18
•
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.
Preparing Your Program for TNS/X Systems
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/X 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/X 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 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;
INT .EXT xcpuno;
! SG equivalencing
! Extended pointer
PROCEDURE foo;
!
BEGIN
IF cpuno = 1 THEN
!
BEGIN
!
! Lots of code
END;
@xcpuno := $XADR(cpuno);
IF xcpuno = 1 THEN
!
...
!
END;
Nonprivileged procedure
TNS/E system traps
TNS system accesses G[0]
TNS/E system traps
TNS system accesses G[0]
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/X 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/X systems as they do on TNS systems.
STRUCT s(*);
BEGIN
Variances in TNS and Accelerated Code
19
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
s2 ':=' p FOR $LEN(s2) BYTES;
p.d := %h12345678%d;
p.j := 6;
END;
! On TNS/X systems,
! these operations
! might wrap or trap
In “Data Segments” (page 20), 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/X systems, this addressing operation
might wrap or trap.
Figure 5 Data Segments
Odd-Byte References
When a language compiler applies a TNS word instruction to an operand with an odd-byte
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:
•
20
◦
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.
◦
Contextual optimizations
◦
How the instruction's result is used by later instructions
The SCF attribute TNSMISALIGN (see “Misalignment Handling” (page 24))
Preparing Your Program for TNS/X Systems
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/X 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/X 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” (page 23) 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).
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 “TNS
Misalignment Handling Methods” (page 25)). FAIL can be unsafe on production systems, but
is recommended on test systems.
•
Remove odd-byte references to words from your programs.
Example
•
The results of the following program fragment are unpredictable on TNS/X systems.
Variances in TNS and Accelerated Code
21
REAL(64) .EXT RPTR;
STRING .EXT SPTR = RPTR;
@SPTR := @SPTR + 1d;
IF SPTR = 'Z' THEN ...
IF RPTR = 0.0L0 THEN ...
•
! Same pointer as RPTR
! OK
! Results are unpredictable
In the following example, an odd-byte address alignment error occurs on a TNS/X 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;
p.d := %habcd1234%d;
END;
! "nil" 4-byte pointer to structure
! Results are unpredictable
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/X systems. This 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/X systems accept 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/X 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
22
•
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.
Preparing Your Program for TNS/X Systems
Required Change
•
Recode statements that use dynamic shift counts greater than 31.
Example
In this example, the value of p being arithmetically shifted to the right 35 positions. The value of
p differs on TNS and TNS/X systems.
INT p, nbits, q;
p := -128;
nbits := 35;
q := p >> nbits;
! INT variables
!
!
!
!
!
Shift value of 35-bits
On TNS systems,
same as p >> 16, q = -1
On TNS/X 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 OCAX. 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 OCAX translates TNS 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/X 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/X 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 OCAX, the data misalignment issue might affect the following HP compilers. If
you use these compilers, see the appropriate data alignment addenda:
Compiler
T Number
Addendum
TNS C
T9255
C/C++ Programmer’s Guide Data
Alignment Addendum
TNS C++
T9541
TNS c89
T8629
TNS COBOL85
T9257
COBOL85 Manual Data Alignment
Addendum
TNS/R pTAL
T9248
pTAL Reference Manual Data Alignment
Addendum
TNS TAL
T9250
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
Data Alignment in TNS and Accelerated Code
23
by the persons who configure the system, by means of the 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.
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 OCAX)
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.
24
Preparing Your Program for TNS/X Systems
The “TNS Misalignment Handling Methods” (page 25) table lists and describes the possible settings
for TNSMISALIGN. Each setting represents a misalignment handling method. For more information
about TNSMISALIGN, see the SCF Reference Manual for the Kernel Subsystem.
Table 1 TNS Misalignment Handling Methods
Method
Description
ROUND (default)1
After rounding down a misaligned address, the system proceeds to access the address.
FAIL
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
1
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.
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.
Data Alignment in TNS and Accelerated Code
25
3 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/X systems that affect accelerated code only,
however, might require modification in some programs, particularly low-level TAL programs.
This chapter shows you how to prepare your programs for acceleration by OCAX:
•
“General Considerations” (page 26) discusses software development issues that
significantly affect the performance of accelerated code.
•
“Variances in Accelerated Code” (page 27) discusses the changes you must
make to programs because of variances between TNS and TNS/X systems that
apply only to accelerated object code.
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, H-series, J-series, and L-series systems. These run-time library routines have already been
accelerated for TNS/X 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, OCAX does not require the UserLib option when translating
programs that use a user library.
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.
OCAX generates code that assumes that the function returns an INT value. In most cases, OCAX
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
OCAX 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
26
Preparing Programs for Acceleration
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/X 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
Refer to the “Trap Handlers That Use the Register Stack” (page 17) for guidelines on 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, OCAX 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.
Variances in Accelerated Code
27
Detection Guidelines
•
OCAX emits Warning 15 if it suspects that a procedure uses a register that is implicitly set by
another procedure.
Warning 15: Procedure proc—name
a register register-number
in file filename inherits
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).
•
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,
OCAX 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.
OCAX 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. OCAX 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
“Passing Parameters in Registers” (page 29) shows the passing of parameters in registers coded
with the 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
CODE (LOAD L+3); ! Loads value on stack from data segment
28
Preparing Programs for Acceleration
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
OCAX discards the LOAD L+3 instruction, unless you specify ReturnsR0 Q to tell the OCAX to
preserve that value.
Figure 6 Passing Parameters in Registers
Arithmetic Left-Shift Sign Bit
In TNS object code (on both TNS and TNS/X 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 those of TNS object code,
but only if an overflow occurs. It is unlikely that programs knowingly use left-shift operations that
overflow.
Variances in Accelerated Code
29
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. OCAX 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, OCAX predicts the return value sizes and emits a run-time check to
make sure its predictions are correct. If OCAX makes an incorrect prediction, the program makes
a transition into TNS code at that point. OCAX, however, does not determine or predict the return
value size when the compiler-declared values in the Binder region conflict with OCAX’s control
flow analysis. In these rare cases, you must tell OCAX 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:
30
•
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.
Preparing Programs for Acceleration
For TAL or C programs:
•
Use the OCAX 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 OCAX
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 OCAX generates incorrect code. The following
TAL procedure returns three words implicitly and two words explicitly.
INT(32) PROC foo;
BEGIN
INT tag;
INT(32) value;
STACK 1;
?RP=7
RETURN 2d;
! Actually returns INT48
!
!
!
!
Put value on stack when not defined
Lie to TAL, suppress warning
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 after the RP directive,
while at run time the hardware knows that a value is on the stack.
The OCAX 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)
{
Variances in Accelerated Code
31
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;
};
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/X
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/X systems, the indexed global
variables might not be equivalent to local variables because of register optimization.
OCAX 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.
32
Preparing Programs for Acceleration
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. OCAX 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;
BEGIN
INT a,b,c,d; ! Local variables
c := 1;
f[4] := c+100; ! Undefined on TNS/X systems
b := c+3;
END;
If you execute this program on a TNS system or as TNS code on a TNS/X system, b = 104 at the
end of the procedure. If you accelerate this program and then execute it on a TNS/X 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. OCAX must determine the return value size for all procedures
called by a program. When OCAX 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.
Variances in Accelerated Code
33
4 Using OCAX
The OCAX program processes TNS object code programs and produces accelerated object code
programs. You can run OCAX only from the Guardian environment; OCAX does not support the
Open System Services (OSS) environment. This chapter describes:
•
“Strategy for Using OCAX” (page 34) describes a strategy for using OCAX.
•
“Invoking OCAX” (page 34) describes how to run OCAX from the Guardian environment.
•
“Specifying the Code Space” (page 35) describes the OCAX options that affect the code
space in which a program runs.
•
“Accelerating Programs With Embedded SQL” (page 36) explains how to accelerate user
libraries and programs that contain embedded NonStop SQL/MP or SQL/MX statements.
•
“Using Obey Files” (page 36) explains how to use obey files with OCAX.
•
“Online Help” (page 36) describes the OCAX online help facility.
•
“OCAX Listings” (page 37) describes OCAX listings.
Strategy for Using OCAX
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 OCAX option settings. The option settings provide the OCAX 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 OCAX, and can be corrected by setting the option and re-running OCAX.
1. Make sure that your program does not contain any of the variances described in “Preparing
Programs for Acceleration” or “Preparing Your Program for TNS/X 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 OCAX. If OCAX issues an error message, it does not produce an output file. Correct the
error and re-run OCAX.
5. Examine the OCAX listing. If there are any warning messages, investigate each warning, and
fix it if necessary. OCAX issues warning messages to call your attention to possible problems.
Refer to “Error and Warning Messages” for cause, effect, and recovery information about
warning messages.
6. Perform final testing on the accelerated program.
This is a quick and simple strategy for using OCAX. The following table guides you to the
appropriate sections to learn how to perform more advanced OCAX tasks.
To:
Refer to:
Make it more convenient to accelerate a program
“Using Obey Files” (page 36)
Accelerate a program with embedded SQL statements
“Accelerating Programs With Embedded SQL” (page 36)
Accelerate code that runs in user library, system code, or
system library space
“Specifying the Code Space” (page 35)
Invoking OCAX
OCAX runs as a Guardian process in the Guardian environment. You can invoke OCAX explicitly
on L-series and later releases using TNS/X NonStop server. When you invoke OCAX from the
34
Using OCAX
command line it takes the name of a type-100 TNS object file as an argument. You can specify
one or more OCAX options on the command line, but these are optional. See “OCAX Options”
(page 39) for a listing and description of all OCAX options. Once OCAX translates a TNS object
file, you can execute the accelerated type -100 file on an TNS/X system where it immediately
executes at full speed.
The ocax command invokes OCAX from the Guardian environment.
ocax [/ run-options/] input-file, [, ocax-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 OCAX is to process.
ocax-option-list
is zero or more OCAX options. See “OCAX 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 OCAX
using the gtacl command, pathnames must be fully qualified. See Section 5, OCAX Syntax and
Option Summary for instructions on how to invoke OCAX and a detailed description of each OCAX
option.
OCAX Command Usage Examples
The following examples show how the OCAX command is used:
•
OCAX accelerates the object file myobj and generates an accelerated object file named
myoca:
ocax myobj, OUTPUT_FILE myoca
•
OCAX accelerates the object file test1, generates an accelerated object file named test2, and
writes its listing to the file mylist:
ocax /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 OCAX 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 OCAX cannot be used as a user library or a shared run-time library at execution
time. See “Translating a System Library” (page 40) and “Translating a User Library” (page 41)
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:
ocax MyLib, OUTPUT_FILE MyLibAx, UL
OCAX Command Usage Examples
35
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.
OCAX 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. OCAX 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 OCAX options on the OCAX 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 OCAX command.
You specify an obey file as a run-option within the slashes that optionally follow the keyword ocax,
as in this example:
ocax /in fred/ input-file, output_file output-file
or in the ocax-options -list part of the command, following the semicolon:
ocax input-file, output_file output-file, obey fred
OCAX resolves partially qualified pathnames using the current working directory.
Obey files can contain any number of OCAX 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 Obey File” (page 41) for more information.
Comments
You can use comments in obey files to annotate the commands you specify to OCAX. (You cannot
use comments on the OCAX command line.) A comment can be on any line. This obey file also
directs OCAX 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
Online Help
To access the OCAX online help facility, enter ocax at a TACL prompt. This displays a brief summary
of the OCAX command syntax.
The following example illustrates the help text:
36
Using OCAX
Example 1 OCAX Online Help Example
>OCAX
OCAX - T0448H01 - 01Jan05 - (Dec 7 2004 11:27:33)
Copyright Hewlett-Packard, 1988-2005
OCAX Syntax Summary
ocax [/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 }
OCAX Listings
At each execution, OCAX produces a listing that reports on the acceleration it has just performed.
The following example shows a sample OCAX listing:
> ocax fred, output_file fredx
OCAX - T0892L01 - (Jul 10 2013 13:08:35)
Copyright Hewlett-Packard, 2010-2013
Option summary:
Output_File fredx
299344 TNS instructions; 598688 bytes
953698 X86 instructions; 4431922 x86 bytes
7.40 inline code expansion factor
TNS file name: fred
Binder region not present
Symbols region not present
Mips region not present
IPF region not present
Accelerated as User Code segment 0 through 5
0 Errors were detected
0 Warnings were issued
Accelerated file name: fredx
Accelerated for TNS/X on Jul 16 2013 08:48:19
OCAX Listings
37
Acceleration completed on Jul 16 2013 08:48:28
CPU Time 0:00:05.455
>
38
Using OCAX
5 OCAX Syntax and Option Summary
This chapter provides detailed information about using OCAX on the command line and how you
can use additional options to specify more advanced translation functions.
•
“OCAX Syntax” (page 39) describes how to run OCAX from the command line.
•
“OCAX Options” (page 39) details and provides examples for using options that can be
placed in the [, ocax-option-list] portion of the command line. Using additional OCAX options
is not required.
OCAX Syntax
To run OCAX from the command line, use the following syntax model:
ocax [/ run-options/] input-file [, ocax-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 OCAX command is:
•
OUT file-name, to specify to which file OCAX 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 OCAX 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; OCAX ignores the TNS/R and IPF regions of the TNS object file
if one exists.
If you do not enter a OUTPUT_FILE name, OCAX augments the input file with a new region
that contains x86 instructions provided the existing file is secured so that the OCAX invoker
has permission to replace the existing file. When OCAX augments an existing input file with
x86 instructions, it updates the file’s timestamp. If OCAX 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. OCAX displays this file in the listing if it needs to create this
second file.
ocax-option-list
is one or more ocax options, which are listed and described later in “OCAX Options” (page 40).
Each option keyword, along with any accompanying arguments, must be separated by a
comma from the next keyword.
Note that you cannot use comments on the OCAX command line. If you need to add comments to
any OCAX command line options, use an obey file. See “Specifying an Obey File” (page 41) for
more information.
OCAX Options
“OCAX Options” (page 40) lists the OCAX 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.
OCAX Syntax
39
Table 2 OCAX Options
Option
Purpose
See
SL
Explicitly accelerates the
entire non-native portion of
the system library
“Translating a System Library” (page 40)
UL
Explicitly accelerates a user
library
“Translating a User Library” (page 41)
OUTPUT_FILE output filename
Specifies the output code file
to a location that is different
from the input code file
location
“Specifying an Output File Name” (page 41)
OBEY obey filename
Specifies the name of an
obey file that OCAX should
read for further commands
“Specifying an Obey File” (page 41)
IGNORE_IRn proc-name
Directs OCAX to complete its “IGNORE_IRn” (page 43)
translation without issuing a
warning when it encounters
a procedure that inherits a
register
INHERITSRn proc-name
Directs OCAX to complete its “INHERITSRn” (page 43)
translation without issuing a
warning when it encounters
a register stack being used to
implicitly pass a non-stack
parameter to a procedure
IGNORE_CC proc-name
Directs OCAX to complete its “IGNORE_CC” (page 43)
translation without issuing a
warning when it encounters
a procedure that inherits
condition codes
INHERITSCC proc-name
Directs OCAX to complete its “INHERITSCC” (page 44)
translation without issuing a
warning when it determines
a condition code is passed
into and used by the routine
RETURNSRn
Tells OCAX which TNS
“Determining TNS Register Usage” (page 42)
registers are used for
implicitly passing parameters
from the named procedure
RETURNVALSIZE proc-name n
Directs OCAX to assume that “Correcting a Function’s Return Values Size”
the named procedure returns (page 42)
the named number of 16-bit
words as its return value
Translating a System Library
In the TNS/X environment, the non-native portion of a system library is explicitly accelerated by
the system building process. When you invoke OCAX and specify the SL option, this identifies the
code undergoing translation as the system library.
ocax [/ run-options/] input-file, SL
OCAX assumes if you do not use the SL option:
40
•
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
OCAX Syntax and Option Summary
SL Usage Considerations
•
OCAX does not permit incremental module accelerations before binding them together. You
must first use Binder to combine pieces of the system library before using OCAX to accelerate
the library.
•
Developers who build system library modules may perform trial accelerations using OCAX.
•
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 OCAX to suppress the warning that appears in the listing file
when it finds an inferred user library.
ocax [/ run-options/] input-file, UL
UL Usage Considerations
•
If you do not supply the UL option, OCAX 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, OCAX does not modify or
replace the input-file unless the input-file name is the same as the output-file name.
ocax [/ run-options/] input-file, OUTPUT_FILE output-file
output-file
is the name of the file to which the OCAX 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, OCAX 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 OCAX command line using the OBEY option.
ocax [/ run-options/] input-file, OBEY obey-file
obey-file
is the name of the text file that contains additional OCAX 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 OCAX 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 OCAX commands. A comment can be
on any line of an obey file, even if that line contains an option. A comment is defined as any
string introduced by two dashed (--) and is terminated by the end of a line.
•
OCAX does not recognize the TACL line continuation mark &.
OCAX Options
41
Determining TNS Register Usage
The RETURNSRn option tells OCAX which TNS registers are used for implicitly passing parameters
from the named procedure.
ocax [/ 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: RETURNSR0, 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. OCAX 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.
ocax [/ 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. OCAX 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 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
OCAX 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;
42
OCAX Syntax and Option Summary
CALL do_something;
i := jane
END;
•
If a code (RDE) statement appears to sample an as yet uninitialized ENV.NZ condition code,
OCAX can interpret this as a sampling of the caller’s condition code.
Managing Register or Condition Code Inheritance
OCAX 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 OCAX issues
Warning 15 or 16. Warning 15 displays when OCAX detects that a register from the TNS register
stack may hold an implicitly passed register value. Warning 16 displays when OCAX detects that
the condition codes may 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 OCAX to complete translation.
IGNORE_IRn
If you determine that OCAX is issuing Warning 15 falsely, use IGNORE_IRn to suppress further
issuance of Warning 15 and allow OCAX to complete procedure translation.
ocax [/ 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
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. OCAX error
message display the exact spelling and case for a procedure.
IGNORE_CC
If you determine that OCAX is issuing Warning 16 falsely, use IGNORE_CC to suppress further
issuance of Warning 16 and allow OCAX to complete procedure translation.
ocax [/ run-options/] input-file, IGNORE_CC proc-name
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. OCAX error
message display the exact spelling and case for a procedure.
INHERITSRn
Use the INHERITSRn option if you determine that OCAX 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 INHERITSRn should only be used when Warning 15 is not
spurious.This option directs OCAX to treat TNS stack register n as “live” on calls to the named
procedure. It also suppresses further issuance of Warning 15 and allows OCAX to complete
procedure translation.
ocax [/ run-options/] input-file, INHERITSRn proc-name
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.
OCAX Options
43
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. OCAX error
message display the exact spelling and case for a procedure.
INHERITSCC
Use the INHERITSCC option if you determine that OCAX 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 OCAX to
treat the condition code (CC) as “live” on calls to the named procedure. It also suppresses further
issuance of Warning 16 and allows OCAX to complete procedure translation. The option
INHERITSCC_ON is a synonym for INHERITSCC.
ocax [/ run-options/] input-file, INHERITSCC proc-name
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. OCAX error
message display the exact spelling and case for a procedure.
IGNORE_IRn, IGNORE_CC, INHERITSRn, and INHERITSCC Usage Considerations
44
•
If you specify a procedure name that does not exist, OCAX 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.
•
OCAX 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.
OCAX Syntax and Option Summary
6 Using OCAX With Other NonStop Tools
You can use OCAX with other NonStop products that operate on TNS object files.
•
“OCAX and Binder” (page 45)
•
“OCAX and TNSVUX” (page 46)
•
“OCAX, OCA and Accelerator” (page 46)
•
A TNS object file, after being augmented by both OCAX and OCA, can run fast on both
TNS/E and TNS/X machines, as described later in this chapter.
•
You can use Inspect to debug programs accelerated by OCAX. 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. For further information
about using OCAX with Inspect, see “Debugging OCAX Programs”.
OCAX and Binder
OCAX only processes fully bound ready-to-run TNS object files. When you use Binder with OCAX,
the Binder strips the TNS/R, IPF, and OCAX regions from a TNS object file and resets the OCAX’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 OCAX-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 OCAX ENABLE [ON | OFF] IN filename
ENABLE
controls whether or not OCAX can process a file.
[ON | OFF]
is the Binder default setting for OCAX ENABLE is ON. OCAX does not change the value of
this attribute. When OCAX ENABLE is set to OFF, OCAX may not operate on the object file;
file execution occurs in TNS mode.
SHOW
The SHOW command displays the current values for the attributes of an existing TNS object file.
SHOW
{OCAX ENABLE [FROM filename] }
{INFO
[FROM filename] }
OCAX ENABLE
displays whether or not OCAX 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 OCAX information when the program has been
accelerated using OCAX.
OCAX and Binder
45
STRIP
The STRIP command allows you to selectively remove the Binder, Inspect, TNS/R, IPF, or OCAX
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,
IPF, and OCAX regions (if any) in the file. If you specify the SYMBOLS, AXCEL, OCA, or OCAX
options, only those named attributes are removed from the file.
STRIP filename [, SYMBOLS | , AXCEL | , OCA | , OCAX]
filename
is the name of the TNS object file from which you want to remove the Binder, Inspect, TNS/R,
IPF, or OCAX 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 IPF region from the TNS object file. The IPF region contains OCAgenerated Itanium
code.
OCAX
removes the OCAX region from the TNS object file, containing OCAX-generated x86 code.
OCAX and TNSVUX
TNSVUX is an interactive tool that browses a static, type-100 TNS object file, including the OCAX
region generated by the Object Code Accelerator for TNS/X (OCAX). Using TNSVUX, 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 OCAX region headers
•
Names of system or library routines called
•
TNS and x86 instruction sequences
•
TNS instruction addresses and the TNS/X addresses of the equivalent x86 code sequences
See the TNSVUX Manual for further information.
OCAX, OCA and Accelerator
The TNS Object Code Accelerator for TNS/X (OCAX) translates TNS instructions to equivalent
x86 instructions. It augments the type-100 TNS object file with a new region containing these x86
instructions: the OCAX region. These augmented TNS object files execute significantly faster on
TNS/X machines than do unaugmented, interpreted TNS object files. TNS application programs
that have been translated by OCAX execute with increased performance on TNS/X, much like
programs that have been augmented by the Accelerator for TNS/R and programs that have been
augmented by the OCA for TNS/E execute with increased performance on their respective machines.
We refer to files translated by OCAX as having been “accelerated”, and “acceleration” for TNS/X
is the act of translation via OCAX.
46
Using OCAX With Other NonStop Tools
Figure 7 The OCAX Translation Process
The TNS/X native linker does not accept TNS object files as input. OCAX accelerates fully linked,
readyto-run, type-100 TNS object files for complete applications and complete libraries. No tool
(like XLLink for Accelerator-generated files) exists to link together OCAX-generated x86 code. You
can use Binder to combine TNS code files, then use OCAX to accelerate the complete application.
Accelerating for Multiple Platforms
The Accelerator (Axcel) and OCA process TNS object files to produce accelerated object files that
run significantly faster on TNS/R and TNS/E, respectively, than do plain TNS objects. The
accelerated object file contains both the original TNS instructions and the logically equivalent
optimized native instructions.
You can run OCAX on a TNS object file that has already been augmented by Accelerator or OCA
or both. OCAX adds a new region to the object file. You can accelerate your TNS object file with
any combination of OCAX and OCA, in any order, and the resultant object file runs fast on the
machines for which it was accelerated.
Figure 8 Translating Using Accelerator, OCA and OCAX
See the L-Series Application Migration Guide for TNS/X for further information about using OCAX.
OCAX, OCA and Accelerator
47
Figure 9 Translating Using OCA and OCAX
A TNS object file, after being augmented by both OCAX and OCA, can run fast on both TNS/E
and TNS/X machines.
The Accelerator for TNS/R does not tolerate object files that have been previously accelerated by
OCAX for TNS/X. To create an object file that contains both a MIPS region and an OCAX region,
you must accelerate for TNS/R first, then accelerate for TNS/X.
OCA version 75 and later is able to preserve an OCAX region.
OCAX and NonStop Debugging Tools
You can use either Visual Inspect or Native Inspect to debug programs accelerated by OCAX.
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. See
“Debugging OCAX Programs” for further information about using OCAX with Visual Inspect and
Native Inspect.
48
Using OCAX With Other NonStop Tools
7 Debugging OCAX Programs
You can use Inspect to debug programs accelerated by OCAX. 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 x86
instructions into which OCAX has converted your program, nor with the algorithms by which OCAX
has optimized your program.
This section describes:
•
“Differences Between Debugging TNS and Accelerated Programs” (page 49)
•
“A Strategy for Debugging” (page 50)
For a complete discussion of debugging TNS programs and accelerated programs on TNS/X
systems, refer to the Inspect online help, and the Inspect Manual.
Differences Between Debugging TNS and Accelerated Programs
TNS/X technology uses hardware and software components to increase program performance.
OCAX optimizes program performance for TNS/X systems to achieve optimal program performance.
Both the hardware features of native systems and the optimizations performed by OCAX 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/X-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/X system, the TNS/X 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 maintained, no change is required to run existing TNS
programs on TNS/X 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 memory-exact points.
By default, OCAX defines register-exact points only where necessary for correct execution; for
example, following procedure calls. Many statements have no register-exact 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 Inspect debugging commands (including modifying
memory variables) as if the program were on a TNS system.
Differences Between Debugging TNS and Accelerated Programs
49
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/X 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 OCAX.
Then accelerate a version of the program containing an Inspect symbols region and perform final
testing.
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/X 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/X system than it did on a TNS/E
system:
•
Try running the program on a TNS/E system without using OCAX.
◦
If the program runs incorrectly on a TNS/E system, the problem is in your program logic.
◦
If the program runs correctly on a TNS/E system and incorrectly on a TNS/X system, the
problem is almost certainly a TNS/X variance in your program. In this case, examine
your program for variances described in “Preparing Your Program for TNS/X Systems”
(page 14).
If your program runs correctly on a TNS/E system but does not run correctly on a TNS/X 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).
50
Debugging OCAX Programs
8 Error and Warning Messages
OCAX 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. OCAX does not produce an
executable object file if it finds error conditions. You must resolve all error conditions to accelerate
your program successfully.
NOTE: OCAX 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 OCAX warning and errors. It also describes recovery procedures, when
appropriate, from problems that OCAX detects.
Error and warning messages appear in summary form in the OCAX output listing.
Warning Messages
OCAX issues a warning when it finds a code construct for which it might have produced incorrect
code. OCAX 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 OCAX 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.
15
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. OCAX 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
OCAX 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 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:
Warning Messages
51
ocax [/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 OCAX ignores the condition. For
example:
ocax [/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,
16
Warning 16: Procedure proc-name in file filename inherits condition codes.
Cause
OCAX 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. OCAX’s static analysis suggests that the named
procedures can inherit the condition codes from their callers. See Diagnosing Register or Condition
Code Inheritance on page 5-6 for more 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:
ocax [/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 OCAX to ignore the condition by entering the IGNORE_CC option on
the command line. For example:
ocax {/run-options/] input-file, IGNORE_CC proc-name
23
Warning 23: The priv TNS-opcode opcode is not supported.
Cause
OCAX detects an unsupported TNS opcode in one code path. If you have specified the
Forbid_Obsolete_Ops option, OCAX cannot complete processing. Processing can continue with
a warning if Forbid_Obsolete_Ops option is not specified.
52
Error and Warning Messages
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.
36
Warning 36: The OUTPUT_FILE name filename could not be opened; output
is in zzzz0000.
Cause
The argument to OUTPUT_FILE is not a legal NonStop file name (for example, one that is too
long).
Effect
OCAX is not able to create an output file with an illegal file name. OCAX 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
OCAX 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.
2
Error 2: Cannot open file filename.
Cause
OCAX cannot open the file you specified.
Effect
OCAX is unable to accelerate a file it cannot open.Check your program to verify that inheriting
a register has actually occurred.
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.
3
Error 3: Cannot read file filename.
Cause
OCAX can not read the file name you specified.
Effect
OCAX 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.
4
Error 4: File filename is not a TNS object file.
Error Messages
53
Cause
You specified a non-TNS object file.
Effect
OCAX 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.
5
Error 5: File filename is a TNS OSS object file.
Cause
You specified a TNS OSS object file.
Effect
OCAX only supports native TNS object files.
Recovery
Convert this file to native mode using the TNS compilers and recompile.
6
Error 6: File filename is built using unsupported tools.
Cause
You built this file using unsupported tools.
Effect
OCAX cannot accelerate this file.
Recovery
Rebuild this file using a later version of the compiler and Binder.
7
Error 7: File filename is not bound and runnable.
Cause
This file is not fully bound and ready to execute.
Effect
OCAX cannot accelerate files that are not fully bound and ready to execute.
Recovery
Fully bind the object file and then translate it using OCAX. Do not use the ?NOFIXUP option in
your source code and do not use the SELECT FIXUPS OFF Binder command.
9
Error 9: Translation of file filename has been inhibited.
Cause
The Binder command CHANGE OCAX ENABLE OFF is set to prevent OCAX from translating
this file.
Effect
OCAX 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 OCAX.
54
Error and Warning Messages
10
Error 10: Unrecognized option text was provided.
Cause
OCAX read an option it did not recognize.
Effect
OCAX cannot accelerate this file because it does not recognize one or more options on the
command line.
Recovery
Recovery. Verify the spelling of all options and ensure that the command line contains only
OCAX command syntax. See “OCAX Syntax and Option Summary” for a listing and correct
spelling of OCAX syntax.
11
Error 11: Incorrect syntax was provided on the command line.
Cause
OCAX is unable to interpret your input on the command line.
Effect
OCAX cannot respond to your request for file translation.
Recovery
Verify the spelling of all options and ensure that the command line contains only OCAX command
syntax. See “OCAX Syntax and Option Summary” for a listing and correct spelling of OCAX
syntax.
12
Error 12: The SL option is in effect but file filename contains a main procedure.
Cause
OCAX detects a main procedure in the object file you specified, but you entered the SL option
on the command line.
Effect
OCAX cannot translate a library file that contains a main procedure.
Recovery
Remove the SL option from the command line and re-run OCAX.
13
Error 13: OCAX 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
OCAX cannot write the accelerated object to an unspecified file.
Recovery
Supply a file name after the OUTPUT_FILE option on the command line.
14
Error 14: OCAX expects a procedure name after the option-name
option.
Error Messages
55
Cause
You did not specify a procedure name after the IGNORE_IRn, INHERITSRn, IGNORE_CC, or
INHERITSCC options.
Effect
OCAX 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.
17
Error 17: The output file’s disk is full; translation halted.
Cause
OCAX must stop translation because there is insufficient space on the disk for the output file.
Effect
Translation stops and OCAX 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.
18
Error 18: Temporary working space is full; translation
halted.
Cause
There is insufficient disk space to accommodate the working space that OCAX needs to process
files.
Effect
OCAX cannot translate object files.
Recovery
Clear sufficient disk space to accommodate OCAX working space.
19
Error 19: Internal OCAX failure (text).
Cause
OCAX detected an internal consistency and has shut down.
Effect
OCAX cannot accelerate an object file.
Recovery
Document the text information in the message and immediately report this problem to your HP
analyst.
20
Error 20: Procedure proc-name in file filename is
nonresident, but contains the MXON instruction.
Cause
OCAX detected an instruction that enables mutual exclusion in a nonresident procedure.
Effect
OCAX cannot process this file. Mutual exclusion can only be used in resident procedures on
TNS/X systems.
56
Error and Warning Messages
Recovery
Modify the source code so that it declares the named procedure resident. You should then
recompile and rebind the program.
21
Error 21: The UL option is in effect, but file filename
contains a main procedure.
Cause
OCAX detects a main procedure in the object file you specified, but you entered the UL option
on the command line.
Effect
OCAX cannot translate a library file that contains a main procedure.
Recovery
Remove the UL option from the command line and re-run OCAX.
22
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
OCAX 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 OCAX.
24
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
OCAX cannot process this file; it can only read text files.
Recovery
Use an obey file with the filecode 101.
25
Error 25: Cannot read the obey file filename.
Cause
OCAX cannot read the obey file you specified on the OBEY command line.
Effect
OCAX is unable to read the options in this file.
Recovery
Supply an obey file that contains the appropriate options.
26
Error 26: Cannot open the obey file filename.
Error Messages
57
Cause
OCAX cannot open the obey file you specified.
Effect
OCAX 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.
34
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
OCAX 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.
58
Error and Warning Messages
A 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.
Table 3 Integer Types, Part 1
BASIC
8–Bit Integer
16–Bit Integer
32–Bit Integer
STRING
INT
INT(32)
INT(16)
C
char1
int in the 16-bit data model
int in the 32-bit or wide data
unsigned char
short
model
signed char
unsigned
long
unsigned long
COBOL
Alphabetic
PIC S9(n) COMP or PIC (n)
PIC S9(n) COMP or PIC 9(n)
Numeric DISPLAY
COMP without P or V,
1≤n≤4
COMP without P or V,
5≤n≤9
Alphanumeric
Index Data Item2
Index Data Item2
Numeric-Edited
NATIVE-2
—
INTEGER
Alphanumeric-Edited
FORTRAN
3
NATIVE-4
4
3
INTEGER*4
INTEGER*2
Pascal
BYTE
INTEGER
Enumeration, unpacked,
≤256 members
INT16
LONGINT
INT32
1
CARDINAL
Subrange, unpacked, n...m,
BYTE or CHAR value
0≤n and m≤255
parameter Enumeration,
unpacked, >256 members
Subrange, unpacked, n...m,
-32768≤n and m≤32767,
but at least n or m outside
0...255 range
SQL
CHAR
Subrange, unpacked n...m,
-2147483648≤n and
m≤2147483647, but at
least n or m outside
-32768...32767 range
NUMERIC(1)...NUMERIC(4) NUMERIC(5)...NUMERIC(9)
PIC9(1)COMP...PIC9(4)COMP PIC9(1)COMP...PIC9(9)
COMP
SMALLINT
INTEGER
TAL
Return Value Size (Words)
STRING
INT
UNSIGNED(16)
UNSIGNED(16)
1
1
INT(32)
2
59
1
2
3
4
Unsigned Integer
Index Data Item is a 16-bit integer in COBOL 74 and a 32-bit integer in COBOL85.
HP COBOL85 only.
INTEGER is normally equivalent to INTEGER*2. The INTEGER*4 and INTEGER*8 compiler directives redefine INTEGER.
Table 4 Integer Types, Part 2
BASIC
64–Bit Integer
Bit Integer of 1 to 31 Bits
DecimalInteger
INT(64)
—
—
—
—
FIXED(0)
C
long long
COBOL
PICS9(n) COMP or PIC 9(n) —
Numeric DISPLAY
COMP without P or V,
10≤n≤181
FORTRAN
INTEGER*8
—
—
Pascal
INT64
UNSIGNED(n), 1≤n≤16
DECIMAL
INT(n) 1≤n≤16
SQL
NUMERIC(10)...NUMERIC(18) —
DECIMAL (n,s)
PIC9(10)COMP...PIC9(18)
PIC9(n) DISPLAY
COMP INTEGER
TAL
FIXED(0)
UNSIGNED(n), 1≤n≤31
—
Return Value Size (Words)
4
1, 1 or 2 in TAL
1 or 2, depends on declared
pointer
1
HP COBOL85 only
Table 5 Floating, Fixed, and Complex Types
32-Bit Floating
64-Bit Floating
64-Bit Fixed Point
64-Bit Complex
BASIC
REAL
REAL(64)
FIXED(s), 0≤s≤18
—
C
float
double
—
—
COBOL
—
—
PIC S9(n–s)v9(s)
COMP or PIC
9(n–s)v9(s) COMP,
10≤n≤18
—
FORTRAN
REAL
DOUBLE PRECISION
—
COMPLEX
Pascal
REAWL
LONGREAL
—
—
SQL
—
—
NUMERIC (n,s)
—
PIC 9(n-s)v9(s) COMP
TAL
REAL
REAL(64)
FIXED(s), -19≤s≤19
—
Return Value Size
(Words)
2
4
4
4
Table 6 Character Types
60
Character
Character String
Varying Length Character
String
BASIC
STRING
STRING
—
C
signed char
pointer to char
struct {
Data Type Correspondence and Return Value Sizes
Table 6 Character Types (continued)
Character
Varying Length Character
String
Character String
unsigned char
int len;
char val [n]
};
COBOL
FORTRAN
Alphabetic
Alphabetic
01 name.
Numeric DISPLAY
Numeric DISPLAY
03 len USAGE IS NATIVE-21
Alphanumeric-Edited
Alphanumeric-Edited
03 val PIC X(n).
Alphanumeric
Alphanumeric
Numeric-Edited
Numeric-Edited
CHARACTER
CHARACTER array
—
CHARACTER*n
Pascal
CHAR or BYTE value
parameter
PACKED ARRAY OF
Enumeration, unpacked,
≤256 members
FSTRING
STRING(n)
CHAR
Subrange, unpacked, n...m,
0≤n and m≤255
SQL
PIC X
CHAR(n)
CHAR
PIC X(n)
TAL
STRING
STRING array
Return Value Size (Words)
1
1 or 2, depends on declared 1 or 2, depends on declared
pointer size
pointer size
1
VARCHAR(n)
—
HP COBOL85 only.
Table 7 Structured, Logical, Set, and File Types
Byte-Addressed
Structure
Word-Addressed
Structure
Logical (true or false) Boolean
Set
File
BASIC
—
MAP buffer
—
—
—
—
C
—
struct
—
—
—
—
COBOL
—
01-level RECORD
—
—
—
—
FORTRAN
RECORD
—
LOGICAL 1[1]
—
—
—
Pascal
RECORD, byte-aligned RECORD,
word-aligned
—
BOOLEAN
Set
File
SQL
—
—
—
—
—
—
TAL
Byte-addressed
standard STRUCT
pointer
Word-addressed
standard STRUCT
pointer
—
—
—
—
Return Value
Size (Words)
1 or 2, depends on
declared pointer size
1 or 2, depends on
declared pointer size
1 or 2, depends on
compiler directive
1
1
1
61
1
LOGICAL is normally defined as 2 bytes. The LOGICAL*2 and LOGICAL*4 compiler directives redefine LOGICAL.
Table 8 Pointer Types
62
Procedure Pointer
Byte Pointer
Word Pointer
Extended Pointer
BASIC
—
—
—
—
C
function pointer
byte pointer
word pointer
extended pointer
COBOL
—
—
—
—
FORTRAN
—
—
—
—
Pascal
Procedure pointer
Pointer,
byte-addressed
BYTEADDR
Pointer,
word-addressed
WORDADDR
Pointer,
extended-addressed
EXTADDR
SQL
—
—
—
—
TAL
—
16-bit pointer,
byte-addressed
16-bit pointer, word
addressed
32-bit pointer
Return Value Size
(Words)
1 or 2, depends on 1 or 2, depends on
declared pointer size declared pointer size
1 or 2, depends on
declared pointer size
1 or 2, depends on
declared pointer size
Data Type Correspondence and Return Value Sizes
Glossary
absolute pathname
An HP NonStop 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 IPF region) that result from processing
a TNS object file with the Object Code Accelerator (OCA) or the x86 instructions (in the OCAX
region) that result from processing a TNS object file with the Object Code Accelerator for TNS/X
(OCAX).
accelerated object
file
The MIPS RISC instructions (in the MIPS region) that result from processing a TNS object file with
the Accelerator or with the Intel® Itanium® instructions (in the Itanium instruction region) that
result from processing a TNS object file with the Object Code Accelerator (OCA).
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 than TNS object code that is not accelerated.
See also TNS Object Code Accelerator (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 Accelerator region of an object file. See also accelerated object
file.
access mode
The form of file access permitted for a user or process.
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.
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.
APE
See Application Program Examiner (APE).
API
See application program interface (API).
Application
Program Examiner
(APE)
A tool used to browse through TNS object files that have been accelerated by the Accelerator.
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
A TACL command you can use to associate a file name with a logical file of a program or to
assign a physical device to logical entities that an application uses.
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
63
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 TNS object code files for one or more compilation units to
create an executable TNS object code file for a TNS program or library. Used only with TNS
object file.
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.
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 native object code for TNS/R or TNS/E, breakpoints can be at any MIPS RISC instruction or
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 memory-exact point), not at
arbitrary instructions. Some 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. NonStop servers have multiple
cooperating processors rather than a single CPU. See also processor.
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 another process. The creating process becomes the parent process of the
new process. See also pathname component.
child process
A process created by the current process.
CISC
See complex instruction-set computing (CISC).
CISC compiler
See TNS compiler.
CISC processor
An instruction processing unit (IPU) that is based on complex instruction-set computing (CISC)
architecture.
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 read-only and execute-only segments are efficiently shared
among simultaneous executions 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
64
Glossary
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
See TNS code space.
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 instruction-set computing (RISC).
condition 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.
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).
creator
The process that causes a process to be built from a program file of another process. Compare
with multibyte character set and 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
A 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 data by electronic or magnetic methods, and allows it to be accessed
randomly.
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.
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.
dynamic loading
Loading and opening dynamic-link libraries under programmatic control after the program is
loaded and execution has begun.
65
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.
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
ime 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.
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 register-exact point.
exclusion mode
The attribute of a lock that determines whether any process except the lock holder can access
the locked data.
executable
See object code file.
executable object
file
See program 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 Itanium instructions, emulated TNS execution in TNS interpreted
mode, and emulated TNS execution in TNS accelerated mode.
explicit DLL
See explicit dynamic-link library (explicit DLL).
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.
extensible data
segment
An extended data segment for which swap file extents are not allocated until needed.
extent
A contiguous area on disk for allocating one 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.
66
Glossary
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.
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.
file lock
A mechanism that restricts access to a file by all processes except the lock owner.
file name
A string of characters that uniquely identifies a file.
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 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 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 a 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.
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.
file type
A designation for a file structure. See entry-sequenced file, key-sequenced file, relative file, and
unstructured 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 (:).
67
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.
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 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
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 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.
In an Open System Services (OSS) program, a header is the name of a file known to the run-time
library used by a process. In a Guardian environment C language program, a header is the file
identifier for a file known to the run-time library used by a process.
HP NonStop™
Kernel operating
system
The former name of the operating system for NonStop systems. See HP NonStop™ operating
system.
HP NonStop™
Open System
Services (OSS)
The product name for the OSS environment. See also Open System Services (OSS).
HP NonStop™
operating system
The operating system for NonStop servers.
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™
System EPIC Model
A processor (NSEA
processor)
The model designation for the TNS/E processor used in the Integrity NonStop NS16000 server.
68
Glossary
HP NonStop™
Technical Library
(NTL)
The application for accessing, searching, and viewing technical publications and support
information for NonStop systems. NTL is now on the HP Business Support Center at http://
www.hp.com/go/nonstop-docs (customer visible documentation) and the HP Service Access
Workstation at www.hp.com/go/nonstop-support-docs (restricted site for HP Support and other
internal users).
HP Tandem
Advanced
Command
Language (TACL)
The user interface to the 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.
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 processor module.
Contrast with active process.
input/output
process (IOP)
A running program (part of the NonStop operating system) that manages the I/O functions for
one or more ServerNet addressable controllers (SACs) of the same type.
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 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®
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
69
(OCA) creates this region and writes it into the TNS object file. A TNS object file that contains
an Itanium instruction region can execute in accelerated mode on TNS/E systems. Contrast with
MIPS region of a TNS object file.
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®
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 MIPS 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.
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 word and TNS word. See also MIPS RISC
word.
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.
interpreted mode
See TNS interpreted mode.
interprocess
communication
(IPC)
The exchange of messages between processors.
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).
IPF region of an
object file
he 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 and OCAX region of a TNS object file.
Kernel subsystem
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 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 kernelmanaged 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. Records in a key-sequenced file can be
updated or deleted. Contrast with entry-sequenced file and relative file.
keyword
A character sequence recognized by a command process.
KMSF
See Kernel-Managed Swap Facility (KMSF).
ld 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 nld utility and eld utility.
LDEV
See logical device.
legacy system
An operating system that is not open but from which applications must be ported or users
transferred.
70
Glossary
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. See
also dynamic-link library (DLL) and shared run-time library (SRL).
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 NonStop operating system image or a program from disk into a computer’s
memory so that the operating system or program can run.
2. To insert a tape into a tape drive, which prepares it for a tape operation (read or write).
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.
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 processor
1.
2.
The combination of equivalent processor elements in the NonStop Blade Elements that are
running in the same instruction stream in loose lock-step.
In a NonStop BladeSystem, a set of cores sharing the same memory. A logical processor
in a NonStop BladeSystem takes the traditional NonStop logical processor and extends it
to a multiprocessor:
•
One X and Y ServerNet interface per logical processor.
•
All IPUs in a logical processor share the same memory map (except small per-IPU
anchor area for low-level software).
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.
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 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 process identification number (PIN) that is 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 register-exact point and
nonexact point.
71
message system
A set of operating system procedures and data structures that handles the mechanics of exchanging
messages between processes.
millicode
The system’s lowest-level machine-dependent code, often coded in assembler language. TNS/R
millicode and TNS/E millicode are functionally similar to the microcode on TNS systems. The
system has several types of millicode, including machine interrupt handlers, operating system
primitives, routines implicitly called from native-compiled code, emulators for TNS floating-point
arithmetic, and emulators for privileged-only or long-running TNS machine operations.
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 Intel® Itanium® instruction region.
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.
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. See also Intel® Itanium®
word.
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 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/E native mode or TNS/R native mode.
native object code
See TNS/R native object code or TNS/E native object code.
native object file
See TNS/R native object file or TNS/E native object file.
native process
See TNS/R native process or TNS/E native process.
native signal
See TNS/R native signal or TNS/E native signal.
native-compiled
x86 instructions
See x86 instructions.
native-mode
library
A native-compiled loadfile associated with one or more other native-compiled loadfiles. A native
mode process can have any number of associated native-mode libraries. See also TNS/E library,
TNS library, and TNS/R library.
native-mode
source code
High-level language routines that can be compiled with either TNS/R native compilers or TNS/E
native compilers. These two sets of compilers accept the same language dialects.
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 ld utility and eld 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.
72
Glossary
noft utility
A utility that reads and displays information from TNS/R native object files. See also enoft utility
and xnoft utility.
nonexact point
A code location within an accelerated object file that is between memory-exact 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 memory-exact point
and register-exact point.
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.
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
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 Series
TNS/X
See TNS/X.
NonStop SQL
A relational database management system that provides efficient online access to large distributed
databases.
NonStop Technical
Library
See HP NonStop™ Technical Library (NTL).
NonStop™ Kernel
operating system
See HP NonStop™ operating system.
NonStop™ Series
TNS
See TNS.
NonStop™ Series
TNS/E
See TNS/E.
NonStop™ Series
TNS/R
See TNS/R.
NSAA
HP NonStop™ advanced architecture.
NSE-A processor
See HP NonStop™ System EPIC Model A processor (NSEA processor).
object code
accelerator (OCA)
See TNS Object Code Accelerator (OCA).
Object Code
Accelerator for
TNS/X (OCAX)
See TNS Object Code Accelerator for TNS/X (OCAX).
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).
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, TNS/E native object file, and TNS/X native object file.
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.
73
OCA-accelerated
object code
The Itanium instructions that result from processing a TNS object file with the TNS Object Code
Accelerator (OCA).
OCA-generated
Itanium instructions
See Intel® Itanium® instructions.
OCAX
1) The command used to invoke the TNS Object Code Accelerator for TNS/X (OCAX) on a
TNS/X or TNS/E system. (2) See TNS Object Code Accelerator for TNS/X (OCAX).
OCAX region
loading
A task performed when necessary by the TNS emulation software for TNS/X machines. This task
involves mapping into memory the x86 instructions and any tables needed at run time from the
OCAX region (called the x86 instruction region) of an OCAX-generated object file.
OCAX region of a
TNS object file
The region of a TNS Object Code Accelerator for TNS/X (OCAX)- generated object file, also
called the x86 instruction region, that contains x86 instructions and tables necessary to execute
the object file on a TNS/X system in TNS accelerated mode. The TNS Object Code Accelerator
for TNS/X (OCAX) creates this region. See also OCA-accelerated object code. Contrast with
Accelerator region of an object file and IPF region of an object file.
OCAX-accelerated
object code
The x86 instructions that result from processing a TNS object file with the TNS Object Code
Accelerator for TNS/X (OCAX).
OCAX-accelerated
object file
A TNS object file that has been augmented by the TNS Object Code Accelerator for TNS/X
(OCAX) with equivalent but faster x86 instructions. An OCAX-accelerated object file contains the
original TNS object code, the OCAX-accelerated object code and related address map tables,
and any Binder and symbol information from the original TNS object file. An OCAX-accelerated
object file also can be augmented by the Accelerator with equivalent MIPS RISC instructions and
by OCA with equivalent Intel Itanium instructions.
OCAX-generated
x86 instructions
See x86 instructions.
OCI
See TNS Object Code Interpreter (OCI).
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 message (the server). Contrast with two-way
communication.
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 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 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 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 HP NonStop™ operating system.
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 HP NonStop™ operating system.
OSS
See Open System Services (OSS).
OSS environment
See Open System Services (OSS) environment.
74
Glossary
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.
page mode
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.
PAID
See process access ID (PAID).
PARAM
A TACL command and a Subsystem Control Facility (SCF) command you can use to create a
parameter and give it a value. The TACL process stores the values of parameters assigned by the
PARAM command and sends the values to applications that request parameter values.
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 fully qualified file name.
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.
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.
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. Persistent 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
1. A program that has been submitted to the operating system for execution, or a program that
is currently running in the computer.
2. An address space, a single thread of control that executes within that address space, and the
system resources required by that thread of control.
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. 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 creator access ID (CAID).
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.
75
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 Dseries 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 reside in different enclosures, it is sometimes
called a logical processor. A processor is sometimes referred to as a central processing unit
(CPU), but NonStop servers 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.
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.
ready process
A process that is prepared to become active.
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
memory-exact point and nonexact point.
76
Glossary
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 entry-sequenced file.
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 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.
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
The information or confirmation supplied by a subsystem in reaction to a command. A response
is typically conveyed as one or more interprocess messages from a subsystem to an application.
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
See MIPS RISC instructions.
RVU
See release version update (RVU).
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.
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 process sequence number.
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, 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.
77
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)
A collection of procedures whose code and data can be loaded and executed only at a specific
assigned virtual memory address (the same address in all processes). SRLs use direct addressing
and do not have run-time resolution of links to and from the main program and other independent
libraries. Contrast with dynamic-link library (DLL). See also TNS/X native process.
signal
The method by which an environment notifies a process of an event. Signals are used to notify
a process when an error that is not related to input or output has occurred. See also TNS/R native
signal, and OSS signal.
signal handler
A function or procedure that is executed when a specific signal is delivered to a specific 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 or DVDs 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 NonStop system and can be ordered whenever a new release version update (RVU)
of the system software is available. A full SUT contains the current RVU of the 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 shared run-time library (SRL).
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 related files stored on a disk. All the files have the same volume and subvolume name,
but each file has a unique file identifier.
super ID
On 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).
SYSnn subvolume
A subvolume on the $SYSTEM volume where the new version of the NonStop operating system
image is located. Also located on the SYSnn subvolume is system-dependent and RVU-dependent
software. nn 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 NonStop operating
system image and operated as one computer. See also node.
system code
A logically distinct part of the NonStop operating system that consists of operating system
procedures shared by all processors.
System Code (SC)
See TNS code space.
78
Glossary
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
A logically distinct part of the NonStop operating system that consists of user-callable library
procedures and kernel procedures.
System Library (SL)
See TNS code space.
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. A 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 NonStop operating system with Open System Services (OSS)
interfaces. A system process does not have an OSS process ID.
TACL
See HP Tandem Advanced Command Language (TACL).
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 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 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 code. Contrast with TNS/R native mode and TNS/E native mode. See also TNS Object
Code Accelerator (OCA).
TNS C compiler
The C compiler that generates TNS object files. Contrast with TNS/R native C compiler and
TNS/E native C compiler.
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. 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/R native compiler and 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 Shared Millicode Library.
TNS emulation
software
The set of tools, libraries, and system services for running TNS object code on TNS/R systems
and TNS/E systems. On TNS/R systems, the TNS emulation software includes the TNS Object
Code Interpreter (OCI), the Accelerator, and various millicode libraries. On TNS/E systems, the
TNS emulation software includes the TNS Object Code Interpreter (OCI), the TNS Object Code
Accelerator (OCA), and various millicode libraries.
79
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/R systems and TNS/E systems by
using millicode, an interpreter, and either translation or acceleration. Contrast with MIPS RISC
instructions and Intel® Itanium® instructions.
TNS interpreted
mode
A TNS emulation environment on a TNS/R or TNS/E system in which individual TNS instructions
in a TNS object file are directly executed by interpretation rather than permanently translated
into MIPS or 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 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
TNS accelerated mode and TNS/R native mode.
TNS object code
The TNS instructions that result from processing program source code with a TNS compiler. TNS
object code executes on TNS, and 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 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
Accelerator for
TNS/X (OCAX)
A program optimization tool that processes a TNS object file and produces an accelerated file
for a TNS.X system. OCAX augments a TNS object file with equivalent x86 instructions. TNS
object code that is accelerated runs faster on TNS/X systems than TNS object code that is not
accelerated.
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. 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. On a TNS/E system, all shells for calling native library
procedures are segregated within the system code space.
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.
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 State Library
for TNS/X
A library of routines to access and modify the TNS state of a TNS process running on TNS/X.
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
80
Glossary
to a new process. No dynamic loading of code or creation of instance data segments is involved.
See also HP NonStop™ operating system.
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 must fit within the first 64 kilobytes. See
also compiler extended-data segment.
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 word, MIPS RISC word, and Intel® Itanium® word.
TNS/E
Refers to fault-tolerant HP computers that support the NonStop operating system and are based
on the 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 NonStop systems that use
NSE-x processors. Contrast with TNS and TNS/R.
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 C
compiler
The C compiler that generates TNS/E object files. Contrast with TNS C compiler and TNS/R
native C compilerTNS/R native C compiler.
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 and
TNS/R native compiler.
TNS/E native
mode
The primary execution environment on a TNS/E system, in which native-compiled 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. See also TNS/R native mode.
TNS/E native
object code
The 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 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 and
TNS/R native process.
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).
TNS/R
Refers to fault-tolerant HP computers that support the NonStop operating system and are based
on 32-bit reduced instruction-set computing (RISC) technology. TNS/R systems run the MIPS-1
RISC instruction set and can run TNS object files by interpretation or after acceleration. TNS/R
systems include all HP systems that use NSR-x processors. Contrast with TNS and TNS/E.
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 C
compiler
The C compiler that generates TNS/R object files. Contrast with TNS C compiler and TNS/E
native C compiler.
TNS/R native
compiler
A compiler in the TNS/R development environment that generates TNS/R native object code,
following the TNS/R native-mode conventions for memory, stack, 32-bit registers, and call linkage.
The TNS/R native C compiler is an example of such a compiler. Contrast with TNS compiler and
TNS/E native compiler.
TNS/R native
mode
The primary execution environment on a TNS/R system, in which native-compiled MIPS object
code executes, following TNS/R native-mode compiler conventions for data locations, addressing,
stack frames, registers, and call linkage. Contrast with TNS interpreted mode and TNS accelerated
mode. See also TNS/E native mode.
81
TNS/R native
object code
The MIPS 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 or
TNS/E systems.
TNS/R native
object file
An object file created by a TNS/R native compiler that contains MIPS 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. Contrast with TNS process and
TNS/E native process.
TNS/R native
signal
A signal model available to TNS/R native processes in both the Guardian and Open System
Services (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 both the Guardian and Open System
Services (OSS) environments. A TNS/R native user library is implemented as a special private
TNS/R native shared run-time library.
TNS/X
Refers to fault-tolerant HP computers that support the HP NonStop operating system and are based
on the x86 processor. TNS/X systems can run TNS object filesby interpretation or after
acceleration. TNS/X systems include all HP NonStop systems that use [processor name] processors.
Contrast with TNS, TNS/E, and TNS/R.
TNS/X library
A TNS/X native-mode library. TNS/X libraries are always dynamic-link libraries (DLLs); there is
no native shared runtime library (SRL) format.
TNS/X native C
compiler
The C compiler that generates TNS/X object files. Contrast with TNS C compiler, TNS/R native
C compiler, and TNS/E native C compiler.
TNS/X native
compiler
A compiler in the TNS/X development environment that generates TNS/X native object code,
following the TNS/X native-mode conventions for memory, stack, registers, and call linkage. The
TNS/X native C compiler is an example of such a compiler. Contrast with TNS compiler, TNS/R
native compiler, and TNS/E native compiler.
TNS/X native
mode
The primary execution environment on a TNS/X system,, in which native-compiled x86 object
code executes, following TNS/X native-mode compiler conventions for data locations, addressing,
stack frames, registers, and call linkage. Contrast with TNS interpreted mode, and TNS accelerated
mode. See also TNS/R native mode, TNS/E native mode, and TNS/X native mode.
TNS/X native
object code
The x86 instructions that result from processing program source code with a TNS/X native
compiler. TNS/X native object code executes only on TNS/X systems, not on TNS systems, TNS/R
systems, or TNS/E systems.
TNS/X native
object file
An object file created by a TNS/X native compiler that contains X86 instructions and other
information needed to construct the code spaces and the initial data for a TNS/X native process.
TNS/X native
process
A process initiated by executing a TNS/X native object file. Contrast with TNS process, TNS/R
native process, and TNS/E native process.
TNS/X native
signal
A signal model available to TNS/X native processes in both the Guardian and Open System
Services (OSS) environments. TNS/X native signals are used for error exception handling.
TNS/X native user
library
A user library available to TNS/X native processes in both the Guardian and Open System
Services (OSS) environments. A TNS/X native user library is implemented as a TNS/X 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.
TNSVUX
A tool used to browse through TNS object files that have been accelerated by the TNS Object
Code Accelerator for TNS/X (OCAX). TNSVUX displays x86 code in addition to TNS Code.
Contrast with Application Program Examiner (APE) and TNSVU.
Total Information
Manager (TIM)
See HP NonStop™ Technical Library (NTL).
transfer mode
The protocol by which data is transferred between a terminal and the computer system. See
conversational mode and page mode.
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.
82
Glossary
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
In the Open System Services (OSS) environment, the UID is the scalar view of the HP NonStop™
operating system user ID. The UID is used in the OSS environment for 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 NonStop operating system that consists of the code for user
processes.
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 database
A database within a 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 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 NonStop operating system user ID—a number called
the UID.
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, TNS/R native user library, and TNS/E
native user library.
2. A library loadfile associated with a program so that it emulates the user library feature of the
operating system on TNS systems. For position-independent code programs on TNS/R and TNS/E
systems, the user library is a dynamic-link library. It is treated as if it were the first library in the
program's libList; thus it is searched first for symbols required by the program. However, a user
library does not appear in the program's libList; instead, its name is recorded internally in the
program's loadfile. A program can be associated with at most one user library; the association
can be specified using the linker at link time or in a later change command, or at run time using
the process creation interfaces. (The /LIB …/ option to the RUN command in TACL uses these
interfaces.)
User Library (UL)
See TNS code space.
user name
A string that uniquely identifies a user within the user database for a node.
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 logical disk, which can be one or two magnetic disk drives. Volumes have names that begin
with a dollar sign ($), such as $DATA.
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 Itanium word is also 4 bytes (32 bits) wide,
beginning on any 4-byte boundary in memory.
x86 instruction
region
The region of a TNS object file that contains x86 instructions and tables necessary to execute the
instructions in accelerated mode on a TNS/X system. OCAX creates this region and writes it into
the TNS object file. A TNS object file that contains an x86 instruction region can execute in
accelerated mode on TNS/X systems. Contrast with MIPS region of a TNS object file and Intel®
Itanium® instruction region.
83
x86 instruction
region loading
Mapping the x86 instructions and any tables necessary at runtime into memory from the x86
instruction region of a TNS object file, performed when deemed necessary by the TNS emulation
software on a TNS/X system.
x86 instructions
Register-oriented x86 instructions that are native to and directly executed by a TNS/X system.
x86 instructions do not execute on TNS, TNS/R, and TNS/E systems. Contrast with TNS
instructions, MIPS RISC instructions, and Intel® Itanium® instructions.
x86 region of a
TNS object file
The region of a TNS object file that contains x86 instructions and the tables necessary to execute
the instructions in accelerator mode on a TNS/E system. OCAX creates this region and writes it
into the TNS object file. Contrast with MIPS region of a TNS object file and Intel® Itanium®
instruction region.
xld 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/X native object file. See
also eld utility, ld utility, and nld utility.
XLLink
An Accelerator-related tool invoked by SYSGENR only for TNS/R systems. XLLink binds together
separately accelerated modules of TNS library code to make system libraries. XLLink preserves
and fixes up the existing Accelerator-generated MIPS RISC code, avoiding the additional time
needed for a complete acceleration from TNS instructions. XLLink is not supported for program
files, user libraries, or shared run-time libraries.
xnoft utility
A utility that reads and displays information from TNS/X native object files. See also noft utility
and enoft utility.
84
Glossary
Index
Symbols
$OVERFLOW function, 15
?RP directive, 31
A
Accelerated Code
variances with TNS code
TNS code, 16
Accelerated mode
executing in, 11
Accelerated object file
size, 12
Accelerating
programs with embedded SQL, 36
strategy, 34
Acceleration
cross platform, 13
Accelerator
listings, 37
using, 34
using with OCAX, 46
Addition operations, 14
Address misalignment
causes of, 23
handling, 24
symptoms of, 21
tracing facility, 23
Addresses of P-relative objects, passing, 18
Addressing operations, 19
ALLOCATESEGMENT system procedure, 16
Arithmetic operations, 15
ARMTRAP
system procedure, 27
ARMTRAP system procedure, 17
B
Binder, 26
Binder region, 30
Binding
run-time libraries, 26
bit-shift operators, 22
C
C, 12
model-dependent libraries, 26
run-time libraries, 26, 28
C data type
void*, 30
C data types
double, 21
float, 21
long, 21
long long, 21
unsigned long, 21
C/C++
function prototypes, 26
odd-byte references, 17, 20
Checking
segment limits, 15
COBOL, 12
COBOL85, 12
Code Space
specifying, 35
Condition codes, 27
Control flow analysis, 26, 30
Cross platform acceleration, 13
D
Data block
relationship between global and local, 32
Data misalignment see Address misalignment
Data segment
user global, 19
Debugging, 49
differences between TNS and accelerated programs,
49
memory-exact points, 50
nonexact points, 50
register-exact points, 49
strategy, 50
Debugging OCAX programs, 49
Default misalignment handling method, 25
Disk space, 12
Division operations, 14
Double-word shift instructions, 22
Doublewords, 21
DROP, 27
DROP statements, 27
Dynamic shift counts, 22
E
EMS, 24
ENV register, 27
Event Management Service, 24
executingin, 11
Execution mode, 20
Execution modes
TNS, 11
Extended pointers, 21
extended segment size, 15
F
FAIL misalignment handling method, 25
FORTRAN, 26
pascal, 12
Functions
$OVERFLOW, 14
prototypes, 26
that return a struct, 30
85
G
G segment, 19
general considerations, 14, 26
I
IGNORE_CC, 40
IGNORE_IRn, 40
INHERITSCC, 40
INHERITSRn, 40
INHERITSRn option, 27
Inline code expansion, 13
Inspect symbols, 26
Instruction Failure trap (trap #1)
Trap #1, 25
Invoking OCAX, 34
L
Listings
OCAX, 37
Locating trap handlers, 17
M
Memory requirements, 12
Memory-exact points, 50
Messages
error, 51
warning, 51
millicode, 11
MISALIGNLOG attribute (SCF), 24
Misalignment see Address misalignment
Model-dependent libraries, 26
Multiplication operations, 14
N
Native Inspect
using with OCAX, 48
NATIVEATOMICMISALIGN attribute (SCF), 24
Non-standard procedure call, 27
Nonprivileged programs, 19
NOROUND misalignment handling method, 25
O
OBEY, 40
Obey Files, 36
Object Code Accelerator for TNS/X (OCAX)
functional overview, 11
introduction, 11
resource requirements, 12
OCAX
command usage examples, 35
debugging programs, 49
error messages, 51
invoking, 34
listings, 37
listings example, 37
option list syntax, 39
specifying file names, 34
specifying options, 34
use strategy, 34
86
Index
using, 34
using with Accelerator, 46
using with TNSVUS (TNS Viewer), 46
warning messages, 51
OCAX command options
IGNORE_CC, 40
IGNORE_IRn, 40
INHERITSCC, 40
INHERITSRn, 40
OBEY, 40
OUTPUT_FILE, 40
RETURNSR, 40
RETURNSRn, 40
RETURNVALSIZE, 40
SL, 40
UL, 40
Odd-byte references, 20
Optimization, 11
OUTPUT_FILE, 40
Overflow
results, 14
P
P register, 17
P-relative objects, passing address of, 18
Page size, 15
Segment limits, 15
Pascal, 12
Pointers
extended, 21
uninitialized, 21
Preparing programs for acceleration, 26
variances in accelerated code, 26
Preparing programs for TNS/X systems, 14
Data Alignment, 14
variances in TNS and Accelerated code, 14
Procedure calls
non-standard, 30
Procedure name conflicts, 33
Production systems, 25
PROGID attribute, 36
Program counter register, 17
Q
Quadruplewords, 21
R
RCPU instruction, 18
Register
diagnosing inheritance, 42
inheritance, 42
managing inheritance, 42
Register stack, 16
Register-Exact Points, 49
Registers
inheriting, 28
P, 17
passing parameters, 28
returning, 28
Relationship between global and local data blocks, 32
Reserved instructions, 18
RESIZESEGMENT system procedure, 16
Results after an overflow, 14
Return RP values, 30
Return value sizes, 30
RETURNSRn, 40
RETURNSRn option, 27
RETURNVALSIZE, 40
ROUND (default) misalignment handling method, 25
Rounding down addresses, 20, 23
RP values, 30
Run-time libraries, 26
S
SCF user interface
misalignment handling, 24
misalignment tracing facility, 23
Segment limits, 15
Segment wrapping, 19
SEGMENT_ALLOCATE_ system procedure, 16
SG pointers, 19
SG segment, 19
Shared run-time libraries, accelerating, 26
Shift instructions, 22
SIGILL signal (signal #4), 25
Single-word shift instructions, 22
size, 12
SL, 40
Source-level debugging, 48, 49
Specifying code space, 35
SQL, 36
SQLCOMP, 36
STACK statements, 27, 42
Stack wrapping, 17
Subsystem Control Facility see SCF user interface
Subtraction operations, 14
System
data segment, 19
System library
translating, 26
System procedures
ALLOCATESEGMENT, 16
ARMTRAP, 17
RESIZESEGMENT, 16
SEG MENT_ALLOCATE_, 16
T
TAL, 12
$OVERFLOW function, 15
?RP directive, 30
bit-shift operators, 22
CODE statements, 27, 42
DROP statements, 27
odd-byte references, 20
STACK statements, 27
USE statements, 27, 42
TAL data types
FIXED(n), 21
INT(32), 21
INT(64), 21
REAL, 21
REAL(64), 21
TNS machine state, 49
TNS mode, executing, 11
TNS object file, 12
TNS opcodes, 20
TNS Registers see Registers
TNS registers, 27
TNS system
access to SG, 19
checking segment limits, 15
instruction set, 18
overflow results, 14
privileged instructions, 18
segments, 15
TNS/E system
checking segment limits, 15
overflow results, 14
TNS/X system
checking segment limits, 15
page size, 15
segments, 15
TNSMISALIGN attribute (SCF), 21, 24
TNSmode, 11
TNSVUX
using with OCAX, 46
TNSVUX (TNS viewer), 46
TOTQ instruction, 18
Tracing facility, 23
Translating
user library, 26
Trap #1, 25
Trap handlers
checking overflow, 15
using P register, 17
using the ENV register, 17
using the program counter, 17
using the register stack, 17
variances, 16
U
UL, 40
UL option, 35
Uninitialized pointers, 21
Usage considerations
IGNORE_CC, 40
IGNORE_IRn, 40
INHERITSCC, 40
INHERITSR, 40
OBEY, 40
RETURNSR, 40
SL, 40
UL, 40
USE statement, 27
User data segment, 19
User libraries
accelerating, 35
87
User library
translating, 40
Using OCAX, 34
Using SQL, 36
V
Variances
addresses of P-relative objects, 18
between TNS and Accelerated, 16
code, 16
ENV register, 27
global and local data blocks, 32
odd-byte references, 20
passing parameters in registers, 27
privileged instructions, 18
procedure calls, 30
procedure name conflicts, 33
register stack, 17
registers, 27
SG pointers, 19
shift instructions, 22
stack wrapping, 17
trap handlers, 17
Visual Inspect
using with OCAX, 48
W
Warning, 51
Warning 15, 51
Warning 16, 51
Warning 23, 51
Warning messages, 51
88
Index