Compaq AAR-88LB-TE User manual

ReliableTransactionRouter
MigrationGuide
Order Number: AA–R88LB–TE
June 1999
This guide explains how to migrate from Reliable Transaction Router™
(RTR) Version 2 to RTR Version 3 on OpenVMS™ systems, and provides
information on new and obsolete features.
Revision/Update Information: This guide supersedes the Reliable
Transaction Router Migration Guide
for Version 3.1D.
Operating System: OpenVMS Versions 6.2, 7.1, 7.2
Software Version: Reliable Transaction Router Version
3.2
Compaq Computer Corporation
Houston, Texas

First Printing, December 1997
Revised, June 1999
COMPAQ COMPUTER CORPORATION SHALL NOT BE LIABLE FOR TECHNICAL
OR EDI‘ ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR INCIDENTAL OR
CONSEQUENTIAL DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE,
OR USE OF THIS MATERIAL. THIS INFORMATION IS PROVIDED "AS IS" AND
COMPAQ COMPUTER CORPORATION DISCLAIMS ANY WARRANTIES, EXPRESS,
IMPLIED OR STATUTORY AND EXPRESSLY DISCLAIMS THE IMPLIED WARRANTIES
OF MERCHANTABILITY, FITNESS FOR PARTICULAR PURPOSE, GOOD TITLE AND
AGAINST INFRINGEMENT.
This publication contains information protected by copyright. No part of this publication
may be photocopied or reproduced in any form without prior written consent from
Compaq Computer Corporation.
© Digital Equipment Corporation 1999. All rights reserved..
The software described in this guide is furnished under a license agreement or nondisclosue
agreement. The software may be used or copied only in accordance with the terms of the
agreement.
Compaq and the Compaq logo are registered in the United States Patent and Trademark Office.
The following are trademarks of Compaq Computer Corporation: AlphaGeneration, AlphaServer,
AlphaStation, DEC, DECconnect, DECdtm, DECevent, DECsafe, DECnet, DECwindows, DIGITAL,
DIGITAL UNIX, LAT, OpenVMS, PATHWORKS, POLYCENTER, TruCluster, Reliable Transaction
Router, VAX, and VMScluster.
The following are third-party trademarks:
AIX and IBM are registered trademarks of International Business Machines Corporation.
Memory Channel is a trademark of Encore Computer Corporation.
Hewlett-Packard and HP-UX are registered trademarks of Hewlett-Packard Company.
Microsoft is a registered trademark, and Windows 95 and Windows NT are trademarks of Microsoft
Corporation.
Oracle is a registered trademark of Oracle Corporation.
Solaris and SUN are registered trademarks of Sun Microsystems, Inc.
POSIX is a registered trademark of the Institute of Electrical and Electronics Engineers.
PostScript is a registered trademark of Adobe Systems, Inc.
UNIX is a registered trademark licensed exclusively through X/Open Company Ltd.
X Window System is a trademark of Massachusetts Institute of Technology.
All other trademarks and registered trademarks are the property of their respective holders.
This document was prepared using VAX DOCUMENT Version 2.1.

Contents
Preface ............................................................ vii
1 Introduction
1.1 Why Migrate?............................................... 1–1
1.2 Goals and Nongoals . . ........................................ 1–2
1.3 Reading Guidelines . . ........................................ 1–2
2 Installation
2.1 Cleaning Up the Old Version 2 Environment ....................... 2–1
2.2 Preserving the Old Environment ................................ 2–2
2.3 Can Both RTR Version 2 and Version 3 Coexist On the Same Node? ..... 2–2
2.4 Can RTR Version 2 and Version 3 Applications Coexist on the Same
Node? ..................................................... 2–2
2.5 Process Quotas .............................................. 2–2
2.6 Journal Issues .............................................. 2–3
2.6.1 Removing the Old Journal . . ................................ 2–4
2.6.2 Journal Compatibility ..................................... 2–4
2.6.3 Location and Naming Conventions ........................... 2–4
2.7 Rights and Privileges . ........................................ 2–4
2.8 Memory and Disk Requirements ................................ 2–4
2.9 Rollback to RTR Version 2 ..................................... 2–5
3 Architectural Changes
3.1 RTR Daemon Process . ........................................ 3–1
3.2 Command Server Process ...................................... 3–1
3.3 The Shared Library (LIBRTR.EXE) .............................. 3–1
3.4 The ACP Process ............................................ 3–2
3.5 Interprocess Communication . . . ................................ 3–2
3.6 Shared Memory Parameters . . . ................................ 3–2
3.7 Counters . . ................................................ 3–2
3.8 Quorum Issues .............................................. 3–3
3.9 Server-Process Partition States . ................................ 3–3
4 Network Issues
4.1 DECnet Support............................................. 4–1
4.2 TCP/IP Support ............................................. 4–1
4.3 Specifying a Preferred Transport ................................ 4–2
4.3.1 Supported Products ....................................... 4–2
iii

5 System Management
5.1 OpenVMS Quotas............................................ 5–1
5.2 Startup.................................................... 5–1
5.3 Creating Facilities . . . ........................................ 5–1
5.3.1 Naming Nodes . . . ........................................ 5–1
5.3.2 Modifying Facility Configurations ............................ 5–1
5.4 Interoperability ............................................. 5–2
5.5 Monitoring . ................................................ 5–2
5.5.1 RTR Version 2 Screens ..................................... 5–2
5.5.2 New Screens ............................................ 5–2
5.5.3 User Parsing of Monitor Output ............................. 5–3
5.5.4 User Customized Monitors . . ................................ 5–3
5.5.5 History Screens . . ........................................ 5–4
5.6 Remote Command Support .................................... 5–4
5.7 Partition Management ........................................ 5–4
5.8 Transaction State Management . ................................ 5–4
5.9 Using RTR Version 2 Command Procedures ....................... 5–4
5.10 Command Line Interface Support for RTR Version 2 API ............. 5–4
5.11 Interpreting Output from SHOW Commands....................... 5–4
5.12 Comparing RTR Version 2 and Version 3 Utility Commands ........... 5–5
6 Running Version 2 Applications
6.1 Comparison of OpenVMS API and Portable API .................... 6–1
6.2 Recompiling and Relinking .................................... 6–2
6.2.1 RTR Version 2 Applications Running on RTR Version 3 ........... 6–3
6.3 Running Applications Installed with Privileges ..................... 6–4
6.3.1 Running Clients That Share Channels . ....................... 6–4
6.4 Application Level Interoperability ............................... 6–4
6.5 Support for $GETTXI. ........................................ 6–4
6.6 Threaded Applications ........................................ 6–5
6.7 DDTM Support ............................................. 6–5
6.8 Current Issues .............................................. 6–5
7 Performance Tips
7.1 Process Quotas .............................................. 7–1
7.2 Journal Sizing .............................................. 7–1
7.3 RTR Startup Qualifiers ....................................... 7–1
7.4 Monitoring . ................................................ 7–1
7.5 Memory . . . ................................................ 7–1
7.6 Simultaneous Multiprocessing . . ................................ 7–2
8 Problem Diagnosis and Reporting
8.1 RTR Operator Log . . . ........................................ 8–1
8.2 RTR_ERROR.LOG File ....................................... 8–1
8.3 Dump File . ................................................ 8–1
8.4 Producing and Directing a Trace ................................ 8–1
8.5 Dealing with a Looping Process . ................................ 8–2
8.6 Contents of the RTR Journal File ............................... 8–2
iv

Index
Tables
2–1 OpenVMS Limits . ........................................ 2–3
2–2 OpenVMS Disk Requirements ............................... 2–5
3–1 RTR Executables . ........................................ 3–1
5–1 Interoperability Between Nodes .............................. 5–2
5–2 Obsolete RTR Version 2 Monitor Pictures ...................... 5–2
5–3 New RTR Version 3 Monitor Pictures . . ....................... 5–3
5–4 Changed SHOW COMMANDS ............................... 5–4
5–5 Obsolete OpenVMS RTR Utility Commands .................... 5–5
5–6 New OpenVMS RTR Utility Commands. ....................... 5–5
6–1 OpenVMS API and Portable API Comparison ................... 6–2
6–2 Application Interoperability . ................................ 6–4
v

Preface
This guide explains how to migrate a Reliable Transaction Router (RTR)
environment and RTR applications from RTR Version 2 to RTR Version 3. It
assumes that the application continues to use the RTR Version 2 application
programming interface (API) without change. It also provides information on new
and obsolete features.
Audience This guide is written for RTR system managers.
The system manager should be familiar with the following aspects of the
OpenVMS operating system:
• DIGITAL Command Language (DCL)
• A text editor, such as EDT or EVE
The system manager should also be familiar with:
• Monitoring RTR performance
• Adjusting RTR performance
• Installation of RTR Version 2
• Making changes to the RTR environment
• Application use of the RTR Version 2 Application Programming Interface
(API)
• Applications running on RTR
Organization of This Guide
The following list can help you find information in this guide:
Chapter 1 Provides an introduction to the migration guide and summarizes new
and changed features.
Chapter 2 Describes changes to the installation procedure.
Chapter 3 Describes how the RTR architecture has changed.
Chapter 4 Describes changes to the network configuration that supports RTR.
Chapter 5 Describes changes important to the system manager.
Chapter 6 Describes changes to the RTR API.
Chapter 7 Describes performance and application tips.
Chapter 8 Describes problem diagnosis and reporting.
vii

Related Documents
The following documents provide more information about topics discussed in this
guide:
Document Title Description
Reliable Transaction Router
Installation Guide Describes how to install Reliable Transaction Router.
Reliable Transaction Router
System Manager’s Manual Describes how to configure, manage, and monitor Reliable Transaction Router
Reliable Transaction Router
Application Programmer’s
Reference Manual
Describes how to code RTR applications, and contains
full descriptions of RTR API calls.
Reliable Transaction Router
Application Design Guide Describes how to design applications that use RTR.
Reliable Transaction Router
Release Notes Describes new features, changes, and known restrictions for Reliable Transaction Router on all
supported platforms.
The following document is your best source for information on OpenVMS
procedures that you should be familiar with when using this migration guide:
Document Title Description
OpenVMS System Manager’s
Manual: Essentials Part one of a task-oriented guide to managing an OpenVMS system.
The following document is a useful source for writing applications on OpenVMS:
Document Title Description
DEC C Run-Time Library
Reference Manual for OpenVMS Describes use of the DEC C run-time library.
Reader’s Comments
Compaq welcomes your comments on this guide. Please send us your comments
by email to [email protected]. Include the title of the manual, date on the title
page, section and page numbers with your comments or suggestions.
Conventions
The following conventions are used in this document.
Convention Meaning
Ctrl/X While you hold down the Ctrl key, press another key or a pointing
device button.
Italic Indicates parameters whose values you must provide. For example,
if the procedure asks you to type file name, you must type the actual
name of a file.
Italic also indicates variables and the titles of referenced documents.
viii

Convention Meaning
monospace Indicates the actual commands, words, or characters that you type
in a dialog box, at a command prompt, or system output.
Note: Provides information of special importance.
/ A forward slash in command descriptions indicates that a command
qualifier follows.
. . . A horizontal ellipsis following an entry in a command line indicates
that the entry or a similar entry can be repeated any number of
times. An ellipsis following a file name indicates that additional
parameters, values, or information can be entered.
.
.
.
A vertical ellipsis in an example indicates that not all the data are
shown.
ix

1
Introduction
This document is intended to assist RTR Version 2 users to migrate to RTR
Version 3.
1.1 Why Migrate?
Migration to RTR Version 3 takes advantage of the new features and improved
capabilities of RTR Version 3. These include:
• Improved installation procedure using Polycenter Software Installation
Utility (PCSI), not VMSINSTAL
• Interoperability with multiple operating systems including:
OpenVMS (Alpha and VAX)
UNIX (DIGITAL UNIX, SUN Solaris, IBM AIX, HP–UX)
Windows NT
Windows 95 (client only)
• Improved ability to choose a primary server
• Use of more than one other node for a standby server
• Network transport selection (DECnet or TCP/IP)
• New SHOW command screens containing information about transactional
messages, resource managers, and some new state names
• New MONITOR pictures
• A new API, the Portable API
• Role clarification (Requestor changed to Client)
• Compatibility with Version 2 applications (no recompilation or linking
required)
• Use of mailboxes instead of OpenVMS cache and global sections for
interprocess communication
• Use of OpenVMS quotas, eliminating need for manually sizing configuration
parameters
• Enhanced partition management
• Enhanced journal management
• Exception logging
• Support for industry standard protocols for resource managers:
Microsoft DTC (Distributed Transaction Communicator) support
XA protocol
Introduction 1–1

Introduction
1.1 Why Migrate?
• Support for subtransactions or nested transactions
Additionally, other considerations are:
• New features will be implemented in RTR Version 3, not in RTR Version 2
• Some software problems will be addressed only in RTR Version 3 and not in
RTR Version 2
• Some improved capabilities are already available only in RTR Version 3
• More extensive release test coverage than with RTR Version 2
• RTR Version 3 tested for year 2000 compliance (RTR Version 3.1D, Version
3.2)
• Any residual year 2000 problems will be fixed only in RTR Version 3.1D or
later
Other changes introduced with RTR Version 3:
• New format and content of journal to improve security and flexibility of
transactional messaging
• Change of shared library name RTRSHR.EXE to LIBRTR.EXE
Note
There is no upgrade path for Windows 3.1 clients; applications must be
rewritten using the RTR Version 3 API.
1.2 Goals and Nongoals
The goal of this document is to assist the RTR Version 2 system manager in
planning and implementing the migration of an RTR Version 2 environment to
RTR Version 3.
It is not a goal of this document to instruct the system manager about RTR or
teach troubleshooting or analysis of the RTR environment.
1.3 Reading Guidelines
Read this document, the RTR Version 3 documentation and Release Notes before
beginning to implement an RTR migration to RTR Version 3.
1–2 Introduction

2
Installation
The installation for RTR Version 3 has changed significantly from Version 2. In
Version 2, the installation tool was VMSINSTAL; for Version 3, the installation
tool is PCSI. Follow instructions in the Reliable Transaction Router Installation
Guide to perform your RTR Version 3 installation.
Note
Reading Release Notes in RTR Version 3 is different from in RTR Version
2. See the Reliable Transaction Router Installation Guide for information
on installing the product and reading release notes.
In a cluster environment, a planned transition from RTR Version 2 to Version 3
could be done as follows:
1. Install RTR Version 3 on a single standalone node.
2. Bring up RTR Version 3 on the standalone node with the RTR application.
3. Verify that the application and RTR Version 3 work as expected. Resolve any
problems before proceeding.
4. Stop all transactions and RTR with the following commands:
$ RTR STOP RTR
$ RTR DISCONNECT SERVER
$ RTR DUMP JOURNAL
5. Examine the output of the DUMP JOURNAL command to verify that all
transactions have been flushed from the journal.
6. Bring down RTR Version 2 on the entire cluster.
7. Install RTR Version 3 on the cluster.
8. Start up RTR Version 3 on each node.
9. Verify that the application is running correctly on each node.
10. Verify that the application is running correctly on the cluster.
11. Verify that the application is running correctly throughout the RTR facility
and network environment.
2.1 Cleaning Up the Old Version 2 Environment
Before bringing up the RTR Version 3 environment, you will need to shut down
RTR Version 2 on client systems, let the RTR journal file clear, and then bring
up RTR Version 3. This should be part of the process you use in your planned
migration. See Section 2.6 for more information on checking journal files.
Installation 2–1

Installation
2.2 Preserving the Old Environment
2.2 Preserving the Old Environment
Applications that run in the RTR Version 2 environment on OpenVMS systems
will run in the RTR Version 3 environment on OpenVMS systems. However, as
part of your testing and verification of the new environment, you should check
that an RTR Version 2 application runs as expected after the upgrade.
You cannot mix RTR Version 2 and Version 3 routers and back-end systems; all
routers and back-end systems in a facility must be either RTR Version 2 or RTR
Version 3. Front-end systems can be either Version 2 or Version 3.
2.3 Can Both RTR Version 2 and Version 3 Coexist On the Same
Node?No, RTR Version 2 and Version 3 cannot coexist on the same node.
2.4 Can RTR Version 2 and Version 3 Applications Coexist on the
Same Node?
Under most circumstances, RTR Version 2 applications will run in the RTR
Version 3 environment unchanged, and RTR Version 2 and Version 3 applications
can coexist on the same node, and exchange messages.
Because the RTR Version 2 API is frozen, any new features requiring a change in
the API cannot be exploited from within an RTR Version 2 application. This may
be a reason to consider migration. Additionally, if portability is an issue, migrate
to RTR Version 3.
2.5 Process Quotas
RTRACP buffers all active transactions. All message information that was
previously kept in the shared memory RTR cache is now kept within RTRACP
process memory.
Because of the use of mailboxes to handle message traffic, mailbox quotas should
generally be set larger than in Version 2. These quotas or limits include:
• AST queue limit
• Byte count limit for both the application and ACP
• Buffered I/O count limit
• Direct I/O count limit
• Paging file limit
• Timer queue entry limit
Table 2–1 provides estimates of values for these limits.
Note
Values in Table 2–1 supersede values previously documented.
2–2 Installation

Installation
2.5 Process Quotas
Table 2–1 OpenVMS Limits
Limit Name OpenVMS Name Value for ACP Value for Application
AST queue limit ASTlm 2000 or more
Byte count limit Bytlm 32K + (32K * appn †) Not less than
100K
Buffered I/O count
limit BIOlm Not less than 3 * appn
Direct I/O count limit DIOlm 2000 or more
Paging file limit Pgflquo Not less than 200K
Timer Queue Entry
limit TQElm 2000 or more
†In the table, appn is the number of application processes.
For more information on these limits, see the OpenVMS System Manager’s
Manual: Essentials.
2.6 Journal Issues
With RTR Version 3 software, the format and content of the transaction journal
have changed. In general, if you upgrade or migrate to RTR Version 3 but
continue to use the RTR Version 2 API and DECnet, you can use your existing
application without change, However, if an RTR Version 2 application stored
and used a transaction ID, the changed transaction ID format of RTR Version 3
can cause problems to that application. To correct such a problem, change the
application.
A journal file resides on each RTR back-end system. This is not a change from
RTR Version 2. Before you shut down RTR Version 2 to bring up RTR Version 3,
you must deal with your journal file, using the following procedure:
1. In the Version 2 environment, stop all clients so that no new transactions can
be initiated.
2. Monitor the Version 2 journal file to check the status of all current
transactions.
3. When all transactions are complete and the journal file is empty, you can
delete the journal file at this point, and shut down the entire Version 2
environment as follows:
a. Shut down RTR applications.
b. Shut down RTR Version 2.
c. Install RTR Version 3.
d. Bring up RTR Version 3 including performing the following tasks:
i Start RTR Version 3.
ii Create the new journal file.
iii Create the new operating environment, for example, define facilities.
iv Start the application.
Installation 2–3

Installation
2.6 Journal Issues
2.6.1 Removing the Old Journal
To verify that the new journal is running correctly, use the DUMP JOURNAL
command to verify that transactions are processing as expected, and to be sure
that all transactions have completed before bringing down RTR to install RTR
Version 3.
There is no need to save the old journal file once all transactions have cleared.
2.6.2 Journal Compatibility
RTR Version 2 journal files are incompatible with RTR Version 3 journal files. No
tools exist to migrate RTR Version 2 journal files to the RTR Version 3 journal
file.
2.6.3 Location and Naming Conventions
With RTR, the journal records transactions for use during recovery when
required. You specify the disk location for the journal file with the CREATE
JOURNAL command. This is unchanged for RTR Version 3.
However, the location and naming conventions for the journal have changed for
RTR Version 3.
In RTR Version 2, journal files reside on each back-end node in:
dev:[RTRJNL]filename
In RTR Version 3, journal files reside on each back-end node in:
dev:[RTRJNL.SYSTEM]nodename.Jnn
Group names are used for naming RTR journal files.
2.7 Rights and Privileges
You need the same rights and privileges to manage the RTR environment and
RTR applications in Version 3 as in Version 2.
To manage RTR, you must have one of the following OpenVMS system rights or
privileges: OPER, SETPRV, RTR$OPERATOR. To use the RTR API rtr_request_
info, you must have the following right: RTR$INFO.
To run an application, you must have the following OpenVMS privilege:
TMPMBX.
2.8 Memory and Disk Requirements
Generally, RTR Version 3 may make more demands on system memory than RTR
Version 2, which can cause performance reduction. Adding more memory may be
useful in improving performance.
Table 2–2 lists the OpenVMS requirements for space on the system disk. These
sizes are approximate; actual size may vary depending on system environment,
configuration, and software options. For additional details, see the Reliable
Transaction Router for OpenVMS Software Product Description.
2–4 Installation

Installation
2.8 Memory and Disk Requirements
Table 2–2 OpenVMS Disk Requirements
Requirement RTR Version 2 RTR Version 3
Disk space
(installation) 40,000 blocks (20MB) 50,000 blocks (25MB)
Disk space
(permanent) 24,000 blocks (12MB) 36,000 blocks (18MB)
2.9 Rollback to RTR Version 2
To restore the RTR Version 2 environment if RTR Version 3 does not work with
your applications as expected, use the following procedure:
1. In the RTR Version 3 environment, stop all clients so that no new transactions
can be initiated.
2. Monitor the RTR Version 3 journal to check the status of all current
transactions. Once all transactions are complete and the journal is empty,
you can proceed to the next step.
3. When all transactions are complete, and the journal file is empty, delete the
journal, and shut down the entire RTR Version 3 environment as follows:
a. Shut down RTR applications.
b. Shut down RTR Version 3.
$ RTR STOP RTR
$ RTR DISCONNECT SERVER
c. Remove RTR Version 3 by issuing the following command:
$ product remove RTR
d. Deassign the logical name RTRSHR with the OpenVMS DCL command:
DEASSIGN/SYSTEM/EXEC "RTRSHR"
e. Install RTR Version 2 using VMSINSTAL.
– Answer yes to the VMSINSTAL questions on purging files replaced by
the installation, and running the IVP.
– If you receive the message "The IVP has completed successfully" ,
RTR has been successfully installed.
f. Bring up RTR Version 2 including performing the following tasks:
i Start RTR Version 2.
ii Create the RTR Version 2 journal.
iii Create the RTR Version 2 operating environment.
iv Start the RTR Version 2 application.
Installation 2–5

3
Architectural Changes
RTR Version 3 introduces certain process and other architectural changes. The
following sections highlight these changes.
3.1 RTR Daemon Process
In RTR Version 3, a new RTR daemon process (called RTRD) is used by the
RTRACP process to build TCP/IP connections for internode links. The RTR
daemon process is present only on systems with IP networking installed and with
IP enabled as an RTR transport (see Chapter 4, Network Issues, for information
on setting your network transport).
3.2 Command Server Process
The command server process name is RTRCSV_<username>.
In RTR Version 2, a command server was started for every user login invocation
to RTR to enter operator commands. With RTR Version 3 there is one command
server per node for each user logged in through a common user name.
Note
Command server timeouts are the same in RTR V3 as in RTR V2.
3.3 The Shared Library (LIBRTR.EXE)
In RTR Version 3, LIBRTR supersedes RTRSHR. This library module LIBRTR
contains most of the RTR code, in contrast with RTR Version 2, where only
RTR code specific to application context was contained in RTRSHR. All RTR
Version 2 binaries have been superseded by the two executables LIBRTR.EXE
and RTR.EXE, in RTR Version 3. Table 3–1 shows the executables of RTR
Version 2 and Version 3.
Table 3–1 RTR Executables
RTR Version 2 RTR Version 3
RTRSHR LIBRTR
RTR RTR
RTRCOMSERV Now part of LIBRTR.
RTRACP Now part of LIBRTR. (continued on next page)
Architectural Changes 3–1

Architectural Changes
3.3 The Shared Library (LIBRTR.EXE)
Table 3–1 (Cont.) RTR Executables
RTR Version 2 RTR Version 3
RTRRTL No longer apply.
3.4 The ACP Process
The RTR Application Control Process (ACP) handles application control, and has
the process name RTRACP. This is unchanged from RTR Version 2.
3.5 Interprocess Communication
In RTR Version 2, global sections (cache) were used for interprocess
communication. In RTR Version 3, interprocess communication is handled
with mailboxes. Each RTR process, including any application process, has three
mailboxes to communicate with the RTRACP process:
• Read
• Write
• Beacon/Control
3.6 Shared Memory Parameters
With RTR Version 2, the SHOW RTR/PARAMS command showed the following:
• Maximum links
• Maximum facilities
• Maximum relations
• Maximum processes
• Cache pages
The /PARAMS qualifier is obsolete in RTR Version 3, and the parameters it
showed no longer apply. In RTR Version 3, these parameters are handled with
OpenVMS mailboxes, which you can check using OpenVMS procedures. See the
OpenVMS System Manager’s Manual: Essentials for more information.
3.7 Counters
In RTR Version 2, shared memory in global sections was directly accessible
using the RTR command server. In RTR Version 3, process counters are still
kept in shared memory, but they are accessed from the command server through
RTRACP. Thus, accessing these and other counters involves communicating with
RTRACP. Other counters are contained within the address space of the ACP.
3–2 Architectural Changes