With RTR Version 3, there are several considerations for improving performance. These are described in the following sections.

7.1 Process Quotas

OpenVMS process quotas should be increased to accomodate the use of mailboxes for processes. Check the RTR Installation Guide for the specific formula to use.

7.2 Journal Sizing

With RTR, the larger the journal, the more time it takes to read it. This can affect failover in some circumstances. Due to the new journal format, journal files need to be created larger than in RTR Version 2 to accomodate the larger transaction identification implemented for RTR Version 3. Monitor the journal file periodically to make it the most effective size for your RTR environment.

7.3 RTR Startup Qualifiers

RTR startup qualifiers have changed. You no longer provide specific configuration information, but use OpenVMS quotas; RTR Version 3 manages configuration requirements.

7.4 Monitoring

Monitoring is an important tool for evaluating performance on RTR facilities and between RTR nodes. It provides you with direct feedback on the performance and characteristics of your RTR system and its applications.

Additionally, because RTR Version 3 monitoring uses RTRACP heavily, doing constant monitoring can affect performance. If monitoring is affecting performance on your RTR system, use a longer monitoring interval than the default (2 seconds). Use the RTR MONITOR command with the /INTERVAL=seconds qualifier to increase the monitoring interval.

You generally use a different monitoring interval when debugging a new environment, facility, or application than when you are in production. This is not different between RTR Version 2 and RTR Version 3.

7.5 Memory

RTR Version 3 requires more memory than RTR Version 2. Monitor the RTR and application processes for increased page fault rates, and increase process memory quotas if required.

7.6 Simultaneous Multiprocessing

With RTR Version 2, threaded applications could use Symmetric Multiprocessing (SMP) effectively. In RTR Version 3, SMP will not provide the performance advantages of RTR Version 2. The single control process of RTRACP in RTR Version 3 does not take advantage of an SMP configuration. Similarly, because with RTR Version 3 there is only a single command server, you cannot gain advantages associated with the ability in RTR Version 2 to run command servers on different processors. However, applications can run multiple concurrent servers as in RTR Version 2.

RTR Version 3 provides a new error log and logical names to assist tracing errors including:

• the RTR operator log file, capturing events that occur, and useful for diagnosis of problems
• the RTR_ERROR.LOG file
• the dump file (.DMP), a binary crash dump that, if needed, must be sent to your support service

Always initiate an operator log in your RTR$STARTUP.COM procedure. Place it in a disk partition separate from the RTR journal or database.

8.2 RTR_ERROR.LOG File

The RTR error log is new with RTR Version 3. The RTR_ERROR.LOG file captures the call stack and counter information in a form readable by a human when a crash occurs, and can be read even when no dump is available. With RTR Version 2, the only log captured was the operator log, named by the operator. The operator log remains in RTR Version 3, and the new crash dump log provides additional information.

8.3 Dump File

The system logical name RTR$DUMP_DIRECTORY points to the crash-dump directory. The logical name specified by the user can be set in RTR$STARTUP.COM.

To produce a dump, the procedure is the same as in RTR Version 2 (in unsupported mode, type DEBUG ACP to get a crash dump).

8.4 Producing and Directing a Trace

To start and stop a trace, use the SET TRACE command. To perform a trace, use the following procedure:

1. set log/file= filename	Starts your log of the trace. This captures the trace of the specified subsystem in the specified file.
2. set mode/unsupported	Sets mode to unsupported.
3. set trace/subsystem= name	Starts the trace. Valid names are RTR subsystem names such as API and JNL.
or set trace/subsystem=(API, CIF, CRM)	Starts the trace on subsystems API, CIF and CRM.
4. set mode/nounsupported	Sets mode to supported.
.	Trace continues.
.	Trace continues.
5. set mode/unsupp	Sets mode to unsupported.
6. set trace	Stops the trace.
7. set mode/nounsupp	Sets mode back to supported.

Running a trace can affect performance, so be sure to turn it off again when done (see step 6).

8.5 Dealing with a Looping Process

If your system appears to be hung, this may be caused by an RTR process looping. To analyze the problem, do the following:

1. Enter the SHOW PROCESS RTRACP/CONTINUOUS OpenVMS command.
2. Examine the running process, which will be in computable mode. PC samples typically assume values with a narrow range, or recur frequently.
3. Lower the priority of the ACP process.
4. Enter the OpenVMS ANALYZE/SYSTEM SET PROCESS RTRACP command.
5. Enter the SHOW CALL/NEXT command until you see PC values corresponding to RTR software.
6. If you cannot resolve the performance issues yourself, send the logs and your process output to DIGITAL Multivendor Customer Services using normal problem reporting channels.

With RTR Version 2, the only way to examine the content of journal files was to stop the ACP. With RTR Version 3, you can do this without stopping RTR using the DUMP JOURNAL command.