overlord-enterprises.comoverlord-enterprises.com/manuals/overlord balancer...  · web viewthis the...

of 158 /158
OVERLORD Balancer System Manager and Reference Manual Version 7.1 Copyright © 1990-2020 by Overlord Enterprises, Inc. an Illinois corporation Copyright © 1990-2020 by Overlord Enterprises, Inc. 1

Author: others

Post on 28-Jul-2020

0 views

Category:

Documents


0 download

Embed Size (px)

TRANSCRIPT

OVERLORD Balancer

System Manager and Reference Manual

Version 7.1

Copyright © 1990-2020

by Overlord Enterprises, Inc.

an Illinois corporation

All rights reserved.

www.overlord-enterprises.com312-332-7024

Table of Contents

1 Introduction4 1.1 Important Notes on Using the OVERLORD Balancer with...5 2 Implementation6 3 Configuration8 4 Cpu Masks9 4.1 CPU Masks Specify Eligible CPUs9 4.2 Any Mask of All Zeros Means "Do Not Override"9 4.3 How Masks are Combined10 4.4 Special Programs and Regular Programs11 5 Main Configuration File: eCONF12 5.1 [A] LOG Information13 5.2 [B] CPUs and Multi_Rule14 5.3 [C] File Security16 5.4 [D] Force CPU Setting17 5.5 [E] Override CPU Setting18 5.6 [F] Override Priority19 5.7 [G] Performance Factors20 5.8 [H] CPU Sample Period21 5.9 [I] Statistics Info22 5.10 [J] User Rules24 5.11 [K] Terminal Rules25 5.12 [L] Program Rules26 5.13 [M] Process Rules27 6 Program Rules: eBALPROG28 6.1 Example29 6.2 Filename Patterns30 6.3 Special Handling of $SYSTEM.SYSTEM Programs31 7 Process Rules: eBALPROC32 8 User Rules: eBALUSER34 9 Terminal Rules: eBALTERM36 10 Performance Factors and Thresholds: eBALFACT38 11 Configuration Updater – UPD42 12 Terminal-Based Monitors43 12.1 MON – Performance Monitor43 12.2 Busiest Processes: CPU45 13 Library (BALLIB) and DLL (BALDLL)47 13.1 Activating from a Single TACL47 13.2 Linking the OVERLORD Balancer to other Programs49 13.3 NonStop Programs (process pairs)50 13.4 Shared-Memory Programs50 13.5 Un-linking Programs51 13.6 Combining User Libraries51 13.7 Upgrading the non-Native Library, BALLIB52 13.8 Technical Notes about (non-Native) User Libraries, like BALLIB54 14 TACL56 15 Pathway57 15.1 Pathmon and TCPs57 15.2 Servers58 15.3 But What About Static Servers?58 16 Netbatch60 17 TCP/IP61 18 SQLCI62 19 SNAX63 20 $CMON64 21 Compilers66 21.1 Example66 22 CA-Unicenter68 23 Safeguard69 24 ENFORM70 24.1 ENFORM Optimizer70 25 DSM71 26 rTACLBAK macro72 27 Appendex A: Log, Warning, Error and other Messages73 28 Index108 1.1.1 C109 1.1.2 D109 1.1.3 F109 1.1.4 L109 1.1.5 M109 1.1.6 O110 1.1.7 P110 1.1.8 S111 1.1.9 T112 1.1.10 U112 1.1.11 V112 1.1.12 W112

1 Introduction

The OVERLORD Balancer automatically controls the distribution of processes among cpus, by intercepting user- and program-generated requests to create new processes, and deciding which cpu and priority to use for each new process. This makes NonStop™ systems run more smoothly and respond better to unexpected processing demands and hardware/software failures, and eliminates many of the complexities normally involved in managing NonStop™ systems.

The OVERLORD Balancer's behavior on each NonStop™ system is determined by a set of (typically local) configuration files. Decisions about CPU and priority selection are always made relative to the target system; e.g. when a process on system \A creates a new process on system \B, the OVERLORD Balancer on system \B makes the balancing and priority decisions using the rules from its own configuration files.

The OVERLORD Balancer intercepts process creation requests only from creator processes that have been associated with the OVERLORD Balancer library, as described in “Linking the OVERLORD Balancer to other Programs” in Chapter 13, OVERLORD Balancer Library (BALLIB) and DLL (BALDLL). The ancestor process (creator) is associated with the OVERLORD Balancer through its user library; the rules for created processes are set up in the configuration files (details are in Chapter 3, OVERLORD Balancer Configuration). See Chapter 2, OVERLORD Balancer Implementation for more details, and a step-by-step implementation guide.

1.1 Important Notes on Using the OVERLORD Balancer with...

See the following for special considerations regarding each of:

· Chapter 14, OVERLORD Balancer and TACL

· Chapter 15, OVERLORD Balancer and Pathway

· Chapter 16, OVERLORD Balancer and Netbatch

· Chapter 17, OVERLORD Balancer and TCP/IP

· Chapter 18, OVERLORD Balancer and SQLCI

· Chapter 19, OVERLORD Balancer and SNAX

· Chapter 20, OVERLORD Balancer and $CMON

· Chapter 21, OVERLORD Balancer and Compilers

· Chapter 22, OVERLORD Balancer and CA-Unicenter

· Chapter 23, OVERLORD Balancer and Safeguard

· Chapter 24, OVERLORD Balancer and Enform

· Chapter 25, OVERLORD Balancer and DSM

2 Implementation

The OVERLORD Balancer is initially configured to run in passive mode. The OVERLORD Balancer will be loaded on the system and left idle until you are ready to begin using the automatic balancing capabilities. You will be able to monitor system activity, but the system will not dynamically balance load until links to the OVERLORD Balancer library or DLL have been established.

We suggest you review the following before proceeding, and feel free to contact OVERLORD Enterprises to discuss any questions or concerns you have. Many NonStop™ environments have unusual considerations, and we are used to dealing with them and helping you understand how best to proceed:

1. If you have not already done so, install and start the OVERLORD Balancer. The OVERLORD Balancer will then be running on your system in passive mode.

2. Review the configuration files -- we suggest you edit and read (on the NonStop Server, if you're going to make changes) the following files in order. Follow the links below for detailed documentation for each configuration file.

a. eBALCONF, the primary options configuration file.

b. eBALPROG, the program exceptions (rules) configuration file.

c. eBALPROC, the process exceptions (rules) configuration file.

d. eBALUSER, the user exceptions (rules) configuration file.

e. eBALTERM, the terminal exceptions (rules) configuration file.

f. eBALFACT, the factors (processor selection algorithm) configuration file.

3. If you made changes to any of the configuration files, run UPD or stop and restart the OVERLORD Balancer.

4. Associate the OVERLORD Balancer library with a copy of TACL, to test and observe the OVERLORD Balancer's behavior.

5. Briefly review the rest of the Balancer Library documentation to familiarize yourself with how it works.

6. While associating the OVERLORD Balancer library with other programs, we strongly recommended that you duplicate (FUP DUP) each program to a testing copy first. Associate the OVERLORD Balancer library or DLL with these copies, and then rename them after you have tested.

7. Link programs that run as nonStop process pairs to the OVERLORD Balancer, so it will place backup processes correctly.

8. The OVERLORD Balancer user library can be associated with any program that starts another process, by passing BALLIB or BALDLL as the user library to that program, or by using BIND to change a non-Native program's user library or ELD to change a TNS/E Native program's user library. If a program already has a user library or DLL, you can use BIND or ELD to combine the libraries' contents into a new library that provides both sets of functionality.

9. (optional) Start the terminal-based performance monitor (CPU) to observe the performance of your system and the behavior of the OVERLORD Balancer. Review the OVERLORD Balancer's log for details about the decisions it is making.

3 Configuration

Most of the OVERLORD Balancer's behavior is determined by the following configuration files, in the OVERLORD Balancer's default subvolume:

· eBALCONF is the main OVERLORD Balancer configuration file.

· eBALFACT selects factors (performance data items) to be considered and their relative importance, and sets thresholds for resources.

· eBALPROG declares programs which should be treated specially.

· eBALPROC declares processes which should be treated specially.

· eBALUSER declares users who should be treated specially and/or restricted to priority ranges.

· eBALTERM declares terminals whose programs should be treated specially and/or restricted to priority ranges.

Important:

After making changes to any of the above files, you can ask the OVERLORD Balancer to update its configuration accordingly by running UPD. Otherwise, changes will be implemented the next time the OVERLORD Balancer is stopped and restarted.

Please refer to Chapter 13, OVERLORD Balancer Library (BALLIB) and DLL (BALDLL) and Chapter 2, OVERLORD Balancer Implementation for more details.

4 Cpu Masks

4.1 CPU Masks Specify Eligible CPUs

In each of the Process (eBALPROC), Program (eBALPROG), User (eBALUSER), Terminal (eBALTERM), and main (eBALCONF) configuration files, eligible CPUs are specified using CPU Masks.

· A CPU mask must contain from four to sixteen binary digits (1s and 0s), corresponding to CPUs 0 through 15, from left to right. For example, "1101010000000000" selects CPU numbers 0,1,3, and 5. The short mask "1101010" means exactly the same thing ... the rightmost character (in this case a zero) is logically extended to the right to fill the rest of the sixteen positions.

· Nonexistent CPUs should normally not be masked out, i.e. you should set their bits to 1, not 0. This allows you to add hardware in the future without having to update these configuration files. The OVERLORD Balancer always ignores any nonexistent CPUs.

· 1111111111111111 (or 1111 in short form) means

"select the best of all available CPUs."

· 1100111111111111 (or 11001 in short form) means

"select the best of all CPUs other than CPU 2 and CPU 3."

4.2 Any Mask of All Zeros Means "Do Not Override"

· “0000000000000000” (or “0000“ in short form) means:

"do not override the originally-requested CPU."

This is extremely useful in the program rules (eBALPROG ) file, to instruct the OVERLORD Balancer not to balance particular programs. This can also be useful in the user rules (eBALUSER ) file, to define a user (e.g. super.super) whose specific-CPU requests are never overridden by the OVERLORD Balancer.

4.3 How Masks are Combined

Each process creation request handled by the OVERLORD Balancer may have multiple relevant CPU masks, which are combined to determine the eligible CPUs for that request.

The MULTI_RULE parameter in the main configuration file (eBALCONF ) specifies whether terminal/user CPU masks are combined (merged) with program/process rules, or whether the program/process masks overrule any relevant terminal/user CPU masks.

If MULTI_RULE is set to COMBINE_ALL or COMBINE_MASK , and ...

· 1110100111111111 is the relevant Program or Process mask, and

· 1110101111111111 is the relevant User mask, and

· 0011100011111111 is the relevant Terminal mask, and

· 1111111100000000 are the CPUs currently up, the combined mask is:

· 0010100000000000 -- all the masks are "ANDed" together

... so the OVERLORD Balancer would choose the best of CPUs 2 and 4 (the only CPUs with 1's in all the masks).

If the relevant masks have no CPUs in common, e.g. ...

· 1110100111111111 is the relevant Program or Process mask, and

· 1110101111111111 is the relevant User mask, and

· 0000011000111111 is the relevant Terminal mask, and

· 1111111100000000 are the CPUs currently up, the combined mask is now:

· 0000000000000000 when the masks are "ANDed" together

... this is not a "do not override" because none of the individual masks were all zeros. In a case like this, the OVERLORD Balancer ignores the Program, Process, User, and Terminal masks and selects the best of all available CPUs (and logs a warning message explaining what was done).

If MULTI_RULE is set to COMBINE_NONE or COMBINE_PRI, the CPU mask for the relevant process or program overrides any relevant terminal or user CPU masks; it is just as if the terminal and user rules were not present.

4.4 Special Programs and Regular Programs

In the user rules (eBALUSER) and terminal rules (eBALTERM) files, there are two masks (and two maximum priority settings) for each user or terminal ... one for "regular" programs and one for "special" programs.

Special programs are those that have matching records in the program rules (eBALPROG) or process rules (eBALPROC) files; regular programs are those that do not.

If you do not care to discriminate between special and regular programs, you may use a single mask (and a single maximum priority), or you may use the same mask (and same maximum priority) for both.

5 Main Configuration File: eCONF

eBALCONF [2] is the OVERLORD Balancer's main configuration file, and is read and processed by OVERLORD Balancer (process $ZPBR) when it is started. Portions of this file are also read and processed by OVERLORD Balancer when a full or partial reconfiguration is requested by UPD (see Chapter 11, OVERLORD Balancer Configuration Updater – UPD).

Note:

If you change the contents of this file, remember to either run UPD (see Chapter 11, OVERLORD Balancer Configuration Updater -- UPD) or stop and restart the OVERLORD Balancer, to make your changes take effect.

The individual eCONF parameters are described below in the same order they appear on the UPD screen. These parameters may appear in eCONF in any order:

· A [ ] LOG Information

· B [ ] CPUs and Multi-Rule

· C [ ] File Security

· D [ ] Force CPU Setting

· E [ ] Override CPU Setting

· F [ ] Override Priority

· G [ ] Performance Factors

· H [ ] CPU Sample Period

· I [ ] Statistics Info.

· J [ ] User Rules

· K [ ] Terminal Rules

· L [ ] Program Rules

· M [ ] Process Rules

5.1 [A] LOG Information

Parameter

Value

Recommended and DefaultValue

DATA LOG

ON or OFF

ON while testing, OFF for production, unless you want the output continuously. LOG can be turned ON and OFF as needed.

FILE LOGNAME

a file name

a spooler location, e.g. $S.#BAL.LOG

FILE LOGNAME specifies the process, file, or device to which the OVERLORD Balancer will write log messages. The name can be in network form, so the log can be located on a remote system.

The amount of data logged depends upon the number of process-creation requests made by programs linked to the OVERLORD Balancer. For each process creation the OVERLORD Balancer has intercepted; it will output three consecutive log messages, beginning with the words "Creator," "Program." and "Orig. CPU." These and all other possible messages are described in Appendix A, OVERLORD Balancer Log, Warning, Error, and Other Messages.

If you want to send the log information to more than one location concurrently, you can use an EMS collector and forwarding or printing distributor(s).

In order to facilitate review of the installation process, you may send this information to a terminal during installation (be sure that terminal's TACL is paused). After you have completed installation, we recommend you change the LOGNAME to a spooler or other hardware-independent location.

To log directly to a disk file, you should pre-create an entry sequenced Enscribe file, for example:

> FUP

File Utility Program - T6553G07 - (16APR2003) System \UKULELE

(C)1981 Tandem (C)2003 Hewlett Packard Development Company, L.P.

-SET EXT (50,500)

-SET TYPE E

-SET MAXEXTENTS 100

-SET BLOCK 4096

-SET BUFFERED

-SET REC 250

-CREATE logfile

5.2 [B] CPUs and Multi_Rule

Parameter

Value

Recommended and Default Value

DATA CPUS

four to sixteen binary digits (1s and 0s)

1111111111111111 (all CPUs)

DATA MULTI_RULE

COMBINE_ALL , COMBINE_PRI , COMBINE_MASKS , or COMBINE_NONE

COMBINE_ALL

DATA CPUS specifies a CPU Mask. The 1s and 0s correspond from left to right to CPUs 0, 1, 2... in the local system. By setting some of these to 0, you can prevent the OVERLORD Balancer from directing any new processes to the corresponding CPUs. In most environments, this mask should be set to all 1s (even if the system has less than 16 processors), allowing the OVERLORD Balancer to direct processes to the best-performing CPU among all the available CPUs, now and in the future. (It will never direct a process to a processor that is down or nonexistent.)

If you plan to remove a CPU from your system without a shutdown, you can set its bit to 0 beforehand, to begin "draining" that CPU (preventing new processes being created there).

DATA MULTI_RULE specifies how multiple and possibly-incompatible rules are applied at process creation time. When a process is created, there may be multiple rules that can apply to that process-creation. This parameter determines the way those rules are compared and combined:

COMBINE_NONE specifies that a Program or Process rule completely overrides any relevant Terminal or User rules. Only the program or process mask and priority are used. Terminal and User masks and priorities will apply only to process creations for which there is no Program rule and no Process rule.

COMBINE_MASKS causes the relevant Program or Process CPU mask to be combined with the relevant User and/or Terminal CPU masks, as discussed (with some examples) in Chapter 4, OVERLORD Balancer CPU Masks.

COMBINE_PRI causes similar behavior for priorities: the program or process 'fixed' priority (if specified) is compared to the User and Terminal maximum priority, and the lowest of all those priorities is used.

COMBINE_ALL means both COMBINE_MASKS and COMBINE_PRI.

Note:

Previous versions of the OVERLORD Balancer did not have a MULTI_RULE parameter, and behaved as if this parameter were set to COMBINE_NONE. If you want this version to behave exactly like the earlier versions, use COMBINE_NONE here. In most cases, however, the new recommended and default behavior (COMBINE_ALL) is better.

5.3 [C] File Security

Parameter

Value

Recommended and Default Value

DATA SECURITY

four consecutive letters or digits, corresponding to Read, Write, Execute, Purge

CUUU

The four characters set the permissions for Read, Write, Execute, Purge, using the following codes (all four must either be alphabetic or numeric):

· "0" or "A": any user (local)

· "1" or "G": member of owner's group (local)

· "2" or "O": owner ( local )

· "4" or "N": any user ( local or remote )

· "5" or "C": member of owner's group ( local or remote )

· "6" or "U": owner ( local or remote )

· "7" or "-": SUPER.SUPER only ( local )

5.4 [D] Force CPU Setting

Parameter

Value

Recommended and Default Value

DATA FORCECPU

ON or OFF

ON

ON: The OVERLORD Balancer will override all specific-processor requests, and will direct process-creation to the eligible CPU that can best handle additional work (subject to the process, program, user, and/or terminal restrictions in the eBALPROC , eBALPROG , eBALUSER , and eBALTERM files, if any).

OFF: The OVERLORD Balancer will not override all specific-processor requests; the OVERCPU parameter (below) determines how the OVERLORD Balancer behaves.

5.5 [E] Override CPU Setting

Parameter

Value

Recommended and Default Value

DATA OVERCPU

ON or OFF

ON

This parameter only affects the OVERLORD Balancer's behavior when FORCECPU (above) is OFF.

ON: The OVERLORD Balancer will override specific-processor requests when an attempt is made to start a program in a processor that is not valid (according to the process, program, user, and/or terminal restrictions in the eBALPROC , eBALPROG , eBALUSER , and eBALTERM files), and will direct process-creation to the processor that can best handle additional work. If the requested processor is valid (according to the relevant restrictions), the OVERLORD Balancer will not override it.

OFF: The OVERLORD Balancer will never override a specific-processor request. It will direct process-creation to the processor that can best handle additional work only when no specific processor was requested.

5.6 [F] Override Priority

Parameter

Value

Recommended and Default Value

DATA OVERPRI

ON or OFF

ON

ON: If the relevant Program or Process rule specifies a priority, that priority will be used regardless of what priority the creator requested. Additionally, depending on the setting of the MULTI_RULE parameter, the process may be forced to a lower priority specified in the relevant User or Terminal rule (if USERS or TERMINAL is ON .)

OFF: Program and/or Process priority and User and/or Terminal maximum priority will not be enforced.

This parameter enables or disables priority-enforcement for special processes and special programs, as described under Program rules (eBALPROG ) and Process rules (eBALPROC ), as well as maximum-priority enforcement for specific users and terminals as described under User rules (eBALUSER) and Terminal rules (eBALTERM).

5.7 [G] Performance Factors

Parameter

Value

Recommended and Default Value

DATA FACTORS

ON or OFF

ON

DATA FACTNAME

a valid disk file name

eBALFACT

ON: The performance factors' weights and thresholds declared in eBALFACT will be used.

OFF: Hard-coded defaults (as documented in Chapter 10, OVERLORD Balancer Performance Factors and Thresholds: eBALFACT) will be used.

5.8 [H] CPU Sample Period

Parameter

Value

Recommended and Default Values

DATA SAMPLE

integer number of centiseconds, in the range 10 - 6000

100 (one second) for most systems 300 (three seconds) for K100 and slower systems 250 (two and a half seconds) default if not specified

This the length of the period over which the OVERLORD Balancer checks the processor statistics on your system, in hundredths of seconds. Sampling once per second (Sample Period 100) is appropriate for most busy systems; sampling once every three seconds (Sample Period 300) is appropriate for lightly-used systems and systems with slower CPUs. Consider how many processes your system is likely to create within one sample period; keep it short enough to avoid sending multiple processes to the same CPU when they are being created "at the same time." The minimum allowed value is 10 (one-tenth of a second); the maximum allowed value is 6000 (one minute).

5.9 [I] Statistics Info

Parameter

Value

Recommended and Default Value

DATA STATS

ON or OFF

OFF unless you want to use MON or process the saved statistics

DATA STAT_PERIOD

integer number of centiseconds, in the range 300 - 1440000

3000 (thirty seconds)

FILE STATNAME

a valid disk file name

fBALSTAT

STATS ON: The OVERLORD Balancer can periodically save summary performance statistics to disk. This information is normally used only by the MON (terminal-based performance monitor) program. The STAT_PERIOD and STATNAME parameters determine how much data is written and whether or not it is retained from day to day. (For backward compatibility, the deprecated term STATRATE is accepted as an alternative spelling of STAT_PERIOD.)

STATS OFF: The OVERLORD Balancer will not save summary performance statistics to disk, and the MON program will not be available.

STAT_PERIOD is the length of time over which the summary performance statistics are periodically written to disk, in hundredths of seconds. This is also the period with which MON's terminal screen is refreshed. The default period is 30 seconds. The length of this period directly determines the size of the statistics file:

STAT_PERIOD

Statistics file size in pages (1728000/STAT_PERIOD)

Statistics file size in megabytes (33750/STAT_PERIOD)

3000 (30 seconds)

5760

11.3

6000 (60 seconds)

2880

5.7

18000 (3 minutes)

960

1.9

STATFILE: When the OVERLORD Balancer is started, and every day at midnight, this file is purged if necessary, and created with a primary extent large enough to hold 24 hours of statistics. This allows the MON program to obtain statistics without affecting the performance of the OVERLORD Balancer.

If the filename is specified as exactly eight characters ending in "MMDD", a new file will be created each day using the month and day numbers in place of the letters "MMDD." This allows you to keep the summary data for later processing. If you do this, you should also implement your own procedures to purge or migrate these files based on age. The DDL definition of this file is included in the text file sBALDDL.

5.10 [J] User Rules

Parameter

Value

Recommended and Default Value

DATA USERS

ON or OFF

OFF unless you want to enforce user-specific rules

FILE USERNAME

name of a file containing user- and group-specific rules

eBALUSER

ON: The OVERLORD Balancer will consult a user rules database (named in and built from the specified USERNAME file) when process-creation requests are made. This allows you to restrict processors and/or enforce maximum priorities based on the user-id or user-group of the creating process.

OFF: A user rules database will not be used.

5.11 [K] Terminal Rules

Parameter

Value

Recommended and Default Value

DATA TERMINAL

ON or OFF

OFF unless you want to enforce terminal-specific rules

FILE TERMNAME

name of a file containing terminal-specific rules

eBALTERM

ON: The OVERLORD Balancer will consult a terminal rules database (named in and built from the specified TERMNAME file) when process-creation requests are made. This allows you to restrict processors and/or enforce maximum priorities based on the "home terminal" of the new process.

OFF: A terminal rules database will not be used.

5.12 [L] Program Rules

Parameter

Value

Recommended and Default Value

DATA PROGRAM

ON or OFF

OFF unless you want to enforce program-specific rules

FILE PROGNAME

name of a file containing program-specific rules

eBALPROG

ON: The OVERLORD Balancer will consult a program rules database (named in and built from the specified PROGNAME file) when process-creation requests are made. This allows you to restrict processors and/or enforce specific priorities based on the program (object file) name of the new process.

OFF: A program rules database will not be used.

5.13 [M] Process Rules

Parameter

Value

Recommended and Default Value

DATA PROCESS

ON or OFF

OFF unless you want to enforce process-specific rules

FILE PROCNAME

name of a file containing process-specific rules

eBALPROC

ON: The OVERLORD Balancer will consult a process rules database (named in and built from the specified PROCNAME file) when process-creation requests are made. This allows you to restrict processors and/or enforce specific priorities based on the process name of the new process.

[2] (OVERLORD Balancer reads these parameters from its "IN" file. This file's name does not have to be eBALCONF , but that is how we refer to it throughout this documentation.)

6 Program Rules: eBALPROG

If the PROGRAM option in the eBALCONF file is set to ON, specific programs can be restricted to a subset of the CPUs on your system and/or forced to run at a particular priority. You can also use this file to have specific programs bypass automatic balancing.

Note that these program rules may be overridden by process rules (in eBALPROC ), when both apply during a particular process creation, because process names are more specific than program names.

If you change this file, remember to run UPD to make your changes take effect.

The following programs are automatically recognized as immovable, regardless of volume and subvolume, so it is not necessary to mention them in this file:

· CPU

· BINSERV

· COBOL2

· DIVER

· PEEK

· SCOBOLX2

· SQLCI2

6.1 Example

file progfile fPROG

#

# Program Name or Pattern CPU Mask Priority

#

data program $apps.credit.ycrb003 120

data program $system.system.pathtcp2 0000 170

data program $system.system.edit 001110 140

data program *.sys%%.tacl 130

"File ProgFile" specifies the name of the key-sequenced file the OVERLORD Balancer will create and maintain for the program rules.

Data Program: This creates a rule for a particular program (or collection of programs). There may be any number of Data Program records, in any order, but there should be no duplicates (each Program Name must be unique).

Program Name: The program name or pattern to which this rule applies. You should use a local-format name (i.e. without system name). See “Filename Patterns” and “Special Handling of $SYSTEM.SYSTEM (boot volume) Programs” below for important details.

Use CPUs: Optional -- omit for no effect, or enter four to sixteen binary digits. This is a CPU Mask for processes that are started with this program.

Priority: Optional -- omit for no effect, or enter a number in the range 1-199 to specify the fixed priority for processes that are started with this program.

6.2 Filename Patterns

Two types of "wild cards" are supported: filename patterns with one or more completely replaceable filename parts, i.e. "$*" (for volume name) or "*" (for subvolume or file name), and the special subvolume name "SYS%%" (which matches "SYS00" through "SYS77").

The rules may be supplied in any order. When a process creation is requested, the best matching rule is used, tested in the following order:

1. $volume.subvol.program

2. (if applicable) $volume.sys%%.program

3. *.subvol.program

4. (if applicable) *.sys%%.program

5. $volume.*.program

6. *.*.program

7. $volume.subvol.*

8. (if applicable) $volume.sys%%.*

9. *.subvol.*

10. (if applicable) *.sys%%.*

11. $volume.*.*

12. *.*.*

Filename Pattern Performance Consideration:

You can reduce the average number of tests the OVERLORD Balancer must make for each process creation, by using only a few of the above twelve rule pattern types.

6.3 Special Handling of $SYSTEM.SYSTEM Programs

Programs named $SYSTEM.SYSTEM.program are automatically tested against $SYSTEM.SYScurrent-NN and $SYSTEM.SYS%%. This makes it unnecessary to specify rules for (e.g.) both $SYSTEM.SYSTEM.FUP and $SYSTEM.SYS00.FUP. You should create a single rule using the filename (or a filename pattern) that matches the actual executable program file's name.

Note:

We presume that $SYSTEM is the name of your boot volume; if it is something else, that name, instead of $SYSTEM, is handled as we describe here.

7 Process Rules: eBALPROC

If the PROCESS option in the eBALCONF file is set to ON, specific processes can be restricted to a subset of the CPUs on your system and/or forced to run at a particular priority. You can also use this file to have specific processes bypass automatic balancing.

Note that these process rules override program rules (in eBALPROG), when both apply during a particular process creation, because process names are more specific than program names.

If you change this file, remember to run UPD to make your changes take effect.

Process names beginning with $Z and ending in a decimal (0-15 or 00-15), or hexadecimal (0-F), CPU number will not be moved from that specific CPU if started there, so it is not necessary to mention them in this file.

file procfile fBALPROC

#

# Use these CPUs..

# 0000000000111111

# Process 0123456789012345 Priority

# ------- ---------------- --------

DATA PROCESS $BIG1 1000000000000000 120

DATA PROCESS $BIG2 0100 140

"File ProcFile" specifies the name of the key-sequenced file the OVERLORD Balancer will create and maintain for the process rules.

Data Process: This identifies a particular process' rules. There may be any number of Data Process records, in any order, but there should be no duplicates (each Process Name must be unique).

Process Name: The process name to which these rules apply. Use a local-format ($xxxxx) process name.

Use CPUs: Optional -- omit for no effect, or enter four to sixteen binary digits. This is a CPU Mask for processes that are started with this process name.

Priority: Optional -- omit for no effect, or enter a number in the range 1-199, to specify the fixed priority for processes that are started with this name.

8 User Rules: eBALUSER

If the USERS parameter in the eBALCONF file is set to ON, each user's processes can be restricted to a subset of the CPUs on your system and/or limited to a maximum priority. You can also use this file to permit specific users to bypass automatic balancing.

Many customers use this to split a system which is shared by production and development or by divisions of the company into separate logical systems.

If you change this file, remember to run UPD to make your changes take effect.

Tip:

If the created process program file has the PROGID bit set, the rules for that program file's owner are used; otherwise, the rules for the creating process's current user id (process access id) are used.

file USERFILE fBALUSER

# Name or Comment User-ID Regular-pgm CPUs Special-pgm CPUs

# Max Max

# 111111 111111 Reg Spcl

# 0123456789012345 0123456789012345 Pri Pri

# --------------- ------- ---------------- ---------------- --- ---

data user Example.User 120,1 1111000011111111 1111000011111111 170 180

data user Example.Joe 120,200 0011000011 0011000011 170 180

data user Super.Super 255,255 0000000000000000 0000000000000000 199 199

data user Super group 255,-1 180

"File Userfile" specifies the name of the key-sequenced file the OVERLORD Balancer will create and maintain for the user rules.

"Data User": This identifies a particular user's rules. There may be any number of Data User records, in any order, but there should be no duplicates (each User ID must be unique).

User Name or Comments: You may (but need not) enter a descriptive comment or group/user name; anything that does not look like a group,user number is accepted and ignored.

User ID: The numeric group,user number to which these rules apply. Use decimal group,user numbers (e.g. 101,220) to identify a rule for a specific user. Use group,-1 (e.g. 101,-1) to identify a rule that applies to all users in a group not specifically identified. NonStop Server conventions require group and user numbers to be in the range 0 through 255.

Regular Program CPUs: Optional -- omit for no effect, or enter four to sixteen binary digits. This is a CPU Mask for regular programs that are started by this user.

Special Program CPUs: Optional -- omit to assume same value as Regular Program CPUs, or enter four to sixteen binary digits. This is a CPU Mask for special programs that are started by this user.

Maximum Regular Priority: Optional -- omit for no effect, or enter a number in the range 1-199 to specify the maximum priority for regular programs that are started by this user.

Maximum Special Priority: Optional -- omit to assume same value as Maximum Regular Priority, or enter a number in the range 1-199 to specify the maximum priority for special programs that are started by this user.

9 Terminal Rules: eBALTERM

If the TERMINAL parameter in the eBALCONF file is set to ON, each process assigned to that home terminal can be restricted to a subset of the CPUs on your system and/or limited to a maximum priority. You can also use this file to have specific terminals' processes bypass automatic balancing.

If you change this file, remember to run UPD to make your changes take effect.

file termfile fBALTERM

#

# Terminal Name

# Regular-pgm CPUs Special-pgm CPUs

# Max Max

# 111111 111111 Reg Spcl

# 0123456789012345 0123456789012345 Pri Pri

# ---------------------- ---------------- ---------------- --- ---

data term \HIMA.$asy01.#t01test 1111000011111111 1111000011111111 120 150

data term $all 1111000011111111 1111000011111111 140 150

data term \oslo.$ALL 0011 1111 90 140

"File TermFile" specifies the name of the key-sequenced file the OVERLORD Balancer will create and maintain for the terminal rules.

"Data Term": This identifies the rules for a particular terminal. There may be any number of Data Term records, in any order, but there should be no duplicates (each terminal name must be unique).

Terminal Name: The local or remote name of the "home terminal" to which these rules apply. Local terminals names may be entered with or without the system name, and will be expanded using standard Guardian filename expansion (i.e. the default system name at $ZPBR startup is used).

The "magic" terminal name "$ALL" can be used to establish rules for all terminals (not specifically named elsewhere in this file) on a particular system. "$ALL" matches any terminal on the local system that is not in this file, and "\OSLO.$ALL" match any terminal on the \OSLO system that is not in this file.

Regular Program CPUs: Optional -- omit for no effect, or enter four to sixteen binary digits. This is a CPU Mask for regular programs that are started with this home terminal.

Special Program CPUs: Optional -- omit to assume same value as Regular Program CPUs, or enter four to sixteen binary digits. This is a CPU Mask for special programs that are started with this home terminal.

Maximum Regular Priority: Optional -- omit for no effect, or enter a number in the range 1-199 to specify the maximum priority for regular programs that are started with this home terminal.

Maximum Special Priority: Optional -- omit to assume same value as Maximum Regular Priority, or enter a number in the range 1-199 to specify the maximum priority for special programs that are started with this home terminal.

10 Performance Factors and Thresholds: eBALFACT

The OVERLORD Balancer considers a number of performance factors while making CPU-selection decisions. Some of these performance factors may be more (or less) important in your particular environment than in others. This file allows you to configure the weight (importance) of each factor, and set thresholds to prevent use of CPUs that are almost out of particular limited resources.

This file is used only when DATA FACTORS is set ON in the OVERLORD Balancer's main configuration file (eBALCONF). If DATA FACTORSis OFF in that file, the "recommended and default" values in the table below are used. Those recommended values have proved to work extremely well in most NonStop™ systems; please do not make changes without reasonable consideration, and be sure to keep a record of what you changed and why.

If you change this file (and/or other configuration files), remember to run UPD to have your changes take effect.

#===========================================================

# factor number: 00000000001111 \__ see descriptions below

# 01234567890123 /

# --------------

data priFACT 11111111111111

data backFACT 11111111111111

#===========================================================

#===========================================================

# Factor Weight Threshold Factor #, Description

#===========================================================

data priCPU 20 < 100 ! 0, % processor (CPU) busy

data priMEM 5 < 100 ! 1, % of real memory in use

data priFLT 10 < 9999 ! 2, Page fault rate

data priRDY 50 < 9999 ! 3, Processor queue length

data priCHIT 0 < 9999 ! 4, Disk cache hit rate

data priDISC 0 < 9999 ! 5, Disk i/o rate

data priPCB 0 < 95 ! 6, % of low PCBs in use

data priDISP 10 < 9999 ! 7, Dispatch rate

data priHPCB 0 < 95 ! 8, % of high PCBs in use

data priMEMP 5 < 7 ! 9, Memory pressure

data priPTLE 0 < 99 !10, % of process TLEs in use

data priTLE 0 < 99 !11, % of TLEs in use

data priMEMQ 5 < 9999 !12, Mem. manager queue length

data priVMS 0 < 91 !13, % of VM Segments in use

#===========================================================

data backCPU 0 < 100 ! 0, % processor (CPU) busy

data backMEM 10 < 100 ! 1, % of real memory in use

data backFLT 0 < 9999 ! 2, Page fault rate

data backRDY 0 < 9999 ! 3, Processor queue length

data backCHIT 0 < 9999 ! 4, Disk cache hit rate

data backDISC 0 < 9999 ! 5, Disk i/o rate

data backPCB 30 < 95 ! 6, % of low PCBs in use

data backDISP 0 < 9999 ! 7, Dispatch rate

data backHPCB 30 < 95 ! 8, % of high PCBs in use

data backMEMP 5 < 7 ! 9, Memory pressure

data backPTLE 10 < 99 !10, % of process TLEs in use

data backTLE 10 < 99 !11, % of TLEs in use

data backMEMQ 0 < 9999 !12, Mem. manager queue length

data backVMS 10 < 91 !13, % of VM Segments in use

#===========================================================

Table 10.1. eBALFACT Factor Selection

Parameter

Value(s)

Recommended

DATA PRIFACT

14 ones and zeros, which individually enable (1) or disable (0) consideration of each of the performance factors (0 through 13 -- see the table below) when making balancing decisions for primary (non-backup) processes.

11111111111111

DATA BACKFACT

14 ones and zeros, same as above, used only when making balancing decisions for the backup processes in nonStop (fault tolerant) process pairs.

11111111111111

Table 10.2. Primary Processor Selection Factors

Factor

Recommended (and default) Weight

Recommended (and default) Threshold

Comments

priCPU

20

100 %

factor 0: % CPU busy

priMEM

5

100 %

factor 1: % of real memory in use

priFLT

10

9999

factor 2: Page fault rate

priRDY

50

9999

factor 3: CPU queue length

priCHIT

0

9999

factor 4: Disk cache hit rate

priDISC

0

9999

factor 5: Disk i/o rate

priPCB

0

95 %

factor 6: % of low PCBs in use

priDISP

10

9999

factor 7: dispatch rate

priHPCB

0

95 %

factor 8: % of high PCBs in use

priMEMP

5

7

factor 9: memory pressure

priPTLE

0

99 %

factor 10: % of PTLEs in use

priTLE

0

99 %

factor 11: % of TLEs in use

priMEMQ

5

9999

factor 12: memory manager queue length

priVMS

0

91 %

factor 13: % of VM segments in use

Table 10.3. Backup Processor Selection Factors

Factor

Recommended (and default) Weight

Recommended (and default) Threshold

Comments

backCPU

0

100 %

factor 0: % CPU busy

backMEM

10

100 %

factor 1: % of real memory in use

backFLT

0

9999

factor 2: Page fault rate

backRDY

0

9999

factor 3: CPU queue length

backCHIT

0

9999

factor 4: Disk cache hit rate

backDISC

0

9999

factor 5: Disk i/o rate

backPCB

30

95 %

factor 6: % of low PCBs in use

backDISP

0

9999

factor 7: dispatch rate

backHPCB

30

95 %

factor 8: % of high PCBs in use

backMEMP

0

7

factor 9: memory pressure

backPTLE

10

99 %

factor 10: % of PTLEs in use

backTLE

10

99 %

factor 11: % of TLEs in use

backMEMQ

0

9999

factor 12: memory manager queue length

backVMS

10

91 %

factor 13: % of VM segments in use

Explanation of Data Items

Factor: This is a keyword identifying a particular performance factor. There are two forms of each factor name, PRIxxxx and BACKxxxx, to separately configure behavior for creation of primary and backup processes.

Weight: This is the number of "points," in the range 0 to 1000, to be awarded the CPU which has the best value for this performance factor. Only one CPU is awarded the points corresponding to each performance factor, and the CPU with the highest score (most points) will be selected for the new process.

Threshold: This allows you to prevent the OVERLORD Balancer from selecting a processor that has exceeded any of the specified values, even though it may otherwise look like the "best" processor. The most frequent use of this is to prevent new processes going into CPUs that are almost out of low PCBs or Virtual Memory Segments, allowing you to run much "closer to the wall" than you would otherwise be able to do.

If every processor has exceeded one or more thresholds, the OVERLORD Balancer does its best to choose the "least bad of all bad choices" by preferring the processors that have exceeded fewer thresholds.

11 Configuration Updater – UPD

When you make OVERLORD Balancer configuration changes, they normally take effect the next time you start or restart the OVERLORD Balancer.

UPD is a terminal-based utility that allows you to make these configuration changes take effect immediately, without having to stop and restart the OVERLORD Balancer.

When run without specifying any options, UPD presents a terminal screen listing the various options that can be changed. Each option can be toggled on or off by entering the corresponding letter. UPD will work from any kind of terminal, including telnet.

TACL> RUN UPD

will display the list of configuration options which may be updated dynamically. Choose the options you wish to modify and then press the Enter or Return key:

OVERLORD Balancer v7.1 Configuration Updater r2504

Copyright 1990-2020 HP's licensor, Overlord Enterprises, Inc., overlord-enterprises.com

A [ ] LOG Info (close/open) H [ ] CPU Sample Period

B [ ] CPUs and Multi_Rule I [ ] Statistics Info.

C [ ] File Security J [ ] User Rules

D [ ] Force CPU Setting K [ ] Terminal Rules

E [ ] Override CPU Setting L [ ] Program Rules

F [ ] Override Priority M [ ] Process Rules

G [ ] Performance Factors N [ ] Reload ALL Options

Enter option(s) A through N, then RETURN to execute option(s) chosen

Enter reload option:

Non-interactive Mode

TACL> RUN UPD LM

will run the Configuration Updater non-interactively, just as if you had run it interactively and selected options L and M. In addition to saving time when you already know what you want to do, this can be run in scheduled batch jobs, for example, to have the OVERLORD Balancer use different rules at different times.

12 Terminal-Based Monitors

These terminal-based utilities, MON and CPU, work with any terminal or pseudo-terminal, including telnet.

On 653x terminals and compatible hardware or emulators, they refresh in place, take advantage of video attributes, and support the use of 653x function keys. On other terminal types they scroll and respond only to keyboard commands and Break (or Ctrl+C).

12.1 MON – Performance Monitor

TACL> RUN MON

OVERLORD Balancer v7.1 Performance Monitor r2504

Copyright 1990-2020 HP's licensor, Overlord Enterprises, Inc., overlord-enterprises.com

\WELTY - 2020-2-17 17:13:10 - updating every 30 seconds

CPU CPU% CPU Disp Fault Mem% Mem C-hit DiskIO lPCB% hPCB% VMseg P-cre

Nr Busy Queue /sec /sec InUse Prsur /sec /sec InUse InUse InUse /sec

-- ----- ----- ------ ------ ----- ----- ------ ------ ----- ----- ----- -----

0 39.14 .69 150.27 .13 73.31 6.00 9.20 57.70 21.12 33.21

1 22.59 .08 129.08 1.66 70.45 61.90 23.33 35.36 .03

2 47.04 1.17 210.93 .13 83.75 16.50 29.18 53.70 38.17 43.60

3 32.59 .58 193.31 1.14 60.23 72.90 23.22 35.02 .03

==> (Type 'H' for help)

OVERLORD Balancer v7.1 Performance Monitor r2504

Copyright 1990-2020, Overlord Enterprises, Inc., overlord-enterprises.com

Brief help for keys and function keys

-------------------------------------

0 or F16: display top processes in CPU 0

1-9 or F1-F9: display top processes in CPU 1-9

A-F or F10-F15: display top processes in CPU 10-15

V or SF1: go to next View (of the following three)

S or SF2: view current Statistics -- default

P or SF3: view Peak values since midnight

T or SF4: view Time those peak values occurred

Q, X, SF16 or BREAK: Quit (eXit)

H or any other: display this Help

(Press any key to resume)

· MON dynamically displays system-wide processor statistics periodically (by default, every 30 seconds -- see the eBALCONF STAT_PERIOD parameter).

· To view the Peak (highest) values of your system for the day, press P or Shift+F3.

· To view the time at which each of those Peak values occurred, press T or Shift+F4.

· To return to the performance statistics, press S or Shift+F2.

· To exit, press Q or X or Shift+F16, or use the Break key or Ctrl+C.

· To view the 20 busiest devices/processes in a specific cpu, press the corresponding number/letter or function key. This starts CPU in the selected CPU, with default parameters. Use the BREAK key or Ctrl+C to return to MON.

· 0 through 9 for CPUs 0 through 9

· A through F for CPUs 10 through 15

· F1 through F15 for CPUs 1 through 15

· F16 for CPU 0

12.2 Busiest Processes: CPU

> RUN CPU /cpu n / [optional parameters]

2020-01-02 11:25:30 \OSLO2.cpu01 OVERLORD Balancer Busiest Processes

Copyright 1983-2020 HP's licensor, Overlord Enterprises, Inc., overlord-enterprises.com

Process___ Program_or_Device_Info____ Home_Terminal________________ Pri %Busy

$WC508 $LARS2.OSLOOBJ.WBS508 \OSLO2.$HOME 149 .41

$:1:0 > (system monitor) \OSLO2.$TRM0.#A 201 .14

$SC540 $LARS2.OSLOOBJ.SYS540 \OSLO2.$HOME 149 .10

$LARS2 > Disk, subtype 34 \OSLO2.$TRM0.#A 220 .07

$:1:4 > (TMF monitor) \OSLO2.$TRM0.#A 205 .06

$DEMO > Disk, subtype 34 \OSLO2.$TRM0.#A 220 .05

$DC500 $LARS2.OSLOOBJ.DOC500 \OSLO2.$HOME 149 .04

$IC500 $LARS2.OSLOOBJ.INV500 \OSLO2.$HOME 149 .04

$IC501 $LARS2.OSLOOBJ.INV501 \OSLO2.$HOME 149 .04

$:1:81 $SYSTEM.SYSTEM.NETDUP \PARIS.$ZTN1.#PTY03 139 .04

$CC653 $LARS2.OSLOOBJ.CFD653 \OSLO2.$HOME 149 .03

$CC550 $LARS2.OSLOOBJ.CRP550 \OSLO2.$HOME 149 .03

$DC540 $LARS2.OSLOOBJ.ZZBI0000 \OSLO2.$HOME 149 .03

$PC474 $LARS2.OSLOOBJ.PRS474 \OSLO2.$HOME 149 .03

$PC470 $LARS2.OSLOOBJ.PRS470 \OSLO2.$HOME 149 .02

$KC425 $LARS2.OSLOOBJ.KIT425 \OSLO2.$HOME 149 .02

$RC485 $LARS2.OSLOOBJ.RNS485 \OSLO2.$HOME 149 .02

$PC473 $LARS2.OSLOOBJ.PRS473 \OSLO2.$HOME 149 .02

$ZMIOP > ZMIOP, subtype 1 \OSLO2.$TRM0.#A 209 .02

$:1:1 > (memory manager) \OSLO2.$TRM0.#A 210 .02

==> (Use BREAK (or ^C) to return)

· CPU dynamically displays the 20 busiest processes in a specific CPU.

· To exit or return to MON, use the Break key or Ctrl+C.

Optional Parameters

Three optional parameters to CPU allow you, when running it directly, to set its display interval and (for 653x-compatible terminals) receive additional feedback in the form of highlighting and bells or beeps for busy processes. These optional parameters (to the right of the ending "/") must be formatted as described here:

> RUN CPU /cpu 3/ 30 sec, 40, 30

Synopsis:

> RUN CPU /cpu n/ [nn {sec|min} [ , cc [ , ww]]]

The parameters affect CPU as follows:

1. Sample Interval -- the interval of time (in whole seconds or minutes) between screen updates: nn SEC or nn MIN.

2. Critical Limit -- when any specific process' CPU busy exceeds this percentage (specified as one or two digits), that process will be displayed in reverse video and the terminal's bell will ring. For 653x-compatible terminals only.

3. Warning Limit (must be less than the Critical Limit) -- when any specific process' CPU busy exceeds this percentage (specified as one or two digits), that process will be displayed in dim video (and will not ring the bell). For 653x-compatible terminals only.

EXAMPLE:

> RUN CPU /cpu 3/ 10 SEC,40,30

1. Refresh Rate = 10 Secs

2. Critical Threshold = 40%

3. Warning Threshold = 30%

The default parameters are: 10 secs, 40, 25

13 Library (BALLIB) and DLL (BALDLL)

The OVERLORD Balancer initially runs in a passive mode, i.e. it does not change the behavior of your system at all. You will be able to monitor system activity, but the system will not dynamically balance processor utilization until links to the OVERLORD Balancer library or DLL have been established.

13.1 Activating from a Single TACL

The OVERLORD Balancer may be tested and observed from a single TACL process by performing the following steps.

1. VOLUME to the current SYSnn subvolume (TACL's location)

> VOLUME $SYSTEM.SYSnn

2. Make a duplicate copy of TACL and call it TACLN.

> FUP DUP TACL, TACLN, SAVEALL

Note:

TACL and any copies of TACL (e.g. TACLN) should be in the current SYSnn subvolume, where the other TACL-related files like TACLBASE, TACLINIT, TACLSEGF, etc., are. Alternatively, you could duplicate those additional TACL* files to the location of your TACLN, for it to find and use.

3. Associate the OVERLORD Balancer library with the new TACLN.

> BIND CHANGE LIBRARY $SYSTEM.ZBAL.BALLIB IN TACLN

4. Start the new TACLN.

> TACLN/NAME/

If the OVERLORD Balancer ($ZPBR) is running and forcecpu or overcpu is enabled, the OVERLORD Balancer will automatically intercept process-creation requests made by each running copy of TACLN. Any process started by a TACLN will be placed into the best CPU (and priority, if so configured) by the OVERLORD Balancer, according to its default behavior and the rules you have configured. See Chapter 3, OVERLORD Balancer Configuration for more details.

TACLN can be started in place of the normal TACL for any terminal. Any user with TACLN instead of TACL will automatically get the best CPU and appropriate priority assigned for each process created from that TACLN. If the OVERLORD Balancer ($ZPBR) is not running, TACLN will behave like any normal TACL.

When you want to provide automatic balancing to all TACL users, rename TACL to TACLO (it will still be running), and rename TACLN to TACL. (Be sure you have TACLN's security and ownership the same as TACL's.) Existing TACLOs will continue to run without load balancing, but all new TACLs will benefit from the OVERLORD Balancer.

13.2 Linking the OVERLORD Balancer to other Programs

IMPORTANT !

Always make a copy of any program which you wish to link to the OVERLORD Balancer and use the copy you made while testing. You can later rename the programs to make the OVERLORD Balancer version available in place of the original. We suggest you use a consistent renaming convention, as in the TACL example above, e.g. (for Pathway) DUP PATHMON to PATHMONN. Link the OVERLORD Balancer library to the "N" copy and do your testing. When you want to put it into production, rename PATHMON to PATHMONO and rename PATHMONN to PATHMON. You may purge the "O" copy when it is no longer in use, or save it in case you want to revert quickly.

For non-native (file code 100) executables, associate the OVERLORD Balancer's BALLIB with the process-creating executable (myprog, in the following example) as follows:

> VOLUME $volume.subvol

> FUP DUP myprog, myprogN, SAVEALL

> BIND CHANGE LIBRARY $SYSTEM.ZBAL.BALLIB IN myprogN

> RENAME myprog, myprogO

> RENAME myprogN, myprog

For TNS/E native (file code 800) executables, associate the OVERLORD Balancer's BALDLL with the process-creating executable (myprog, in the following example) as follows:

> VOLUME $volume.subvol

> FUP DUP myprog, myprogN, SAVEALL

> ELD -change libname $SYSTEM.ZBAL.BALDLL myprogN

> RENAME myprog, myprogO

> RENAME myprogN, myprog

For TNS/R native (file code 700) executables, neither BALLIB nor BALDLL can be used, so process creations initiated by TNS/R Native processes cannot [4] be directly intercepted.

Note:

This limitation does not affect the creation of TNS/R Native processes by local or remote TNS or TNS/E creators, but it does affect the creation of any processes by TNS/R Native creators.

You must therefore arrange to have the interception of TNS/R native creators occur at TNS-mode or TNS/E creators instead, by doing any one of the following things:

· Run non-native (TNS-mode, axcelerated if desired) versions of the creators you wish to intercept.

· Arrange to intercept the process creation at a different point. For example (a well-tested and popular workaround), you can intercept LOGIN rather than TELSERV requests, for TCP/IP terminal sessions, and achieve essentially the same result.

· Add a TNS-mode (axcelerated, if desired) transient process between the TNS/R native-mode creator and its created processes, and associate that program with the OVERLORD Balancer library.

13.3 NonStop Programs (process pairs)

NonStop (fault tolerant) programs run as a process pair, i.e. two processes with the same process name in two different CPUs. If the primary (first) process of the process pair is placed by the OVERLORD Balancer (i.e. if the nonStop program is started from a TACL or other OVERLORD Balancer-linked ancestor), you should also associate the OVERLORD Balancer library with the nonStop program itself, so that the OVERLORD Balancer places its backup process correctly. In all cases the TACL (or other ancestor) only starts the primary process, and the primary process itself starts its own backup process. For this reason, you must associate the nonStop program's object file with the OVERLORD Balancer library, if the nonStop program's creator is associated with the OVERLORD Balancer library.

13.4 Shared-Memory Programs

Processes that share memory segments must all be running in the same processor in order to do that. To avoid problems for other users during installation, it is very important to make a copy of each program you wish to link to the OVERLORD Balancer. This allows you to link a copy of the OVERLORD Balancer and not change the original program. This precaution also ensures that you can revert back to the original programs, should you have reason to remove the OVERLORD Balancer.

13.5 Un-linking Programs

To dissociate or un-link a program from the OVERLORD Balancer library, run the program using the LIB parameter, without a library filename.

> RUN myprog / LIB /

If you want to accomplish the same thing without actually starting myprog, use RUND instead of RUN, and terminate the program (e.g. using INSPECT's STOP command) when it goes into debug.

13.6 Combining User Libraries

To use the OVERLORD Balancer to balance processes created by programs that already have a user library or user DLL, combine the OVERLORD Balancer library's procedures (code blocks) with the other user library's contents (code and data blocks), and build a new user library to use with those programs.

You should start with a user library that has not already been combined with a version of the OVERLORD Balancer library. If you do not have access to such a non-combined user library, you should remove the previously-added OVERLORD Balancer procedures before adding the new ones, as described below under Upgrading the OVERLORD Balancer Library.

Examples:

> BIND

@ CLEAR

@ SET LIKE library

@ ADD * FROM library

@ ADD CODE * FROM $SYSTEM.ZBAL.BALLIB

@ BUILD libraryN

@ EXIT

> ELD library $SYSTEM.ZBAL.BALDLL libraryN

Test the combined library by making copies of some of the programs that use the other user library, and pointing them to the new combined one (libraryN in the above examples).

To make OVERLORD Balancer available to all programs that use the non-Native user library, rename the user library at a time when no new copies of those programs will be started until all of the old ones have been stopped. (This is necessary to prevent "LIBRARY CONFLICT" errors with non-Native user libraries; there is no such requirement for Native user DLLs.)

Note

In TNS/E Native COBOL, a COBOL user library specified at compilation time cannot be overridden at run time. (There is no such restriction in TNS COBOL.) If you have such a program (a process-creating Native TNS/E COBOL program with a COBOL user library declared at compile time), you'll have to recompile that COBOL program to remove (or replace) the user library. Contact your Hewlett-Packard Global Customer Support Center (request level-2 support) if you'd like help accomplishing that.

13.7 Upgrading the non-Native Library, BALLIB

It is rarely necessary to replace BALLIB with a newer version, because most of the OVERLORD Balancer's processing is done outside the library. If you do have to upgrade BALLIB, you must do it at a time when you can stop and restart all programs linked to BALLIB. This is a restriction imposed by the NonStop kernel for non-Native user libraries; these considerations do not apply to the Native-mode BALDLL.

You must be prepared to stop and restart all programs that use BALLIB. Once the old BALLIB has been renamed (as described in the following procedures), it will be impossible to start new processes running programs linked to BALLIB until all processes running that program have been stopped. (This is not quite as bad as it sounds: you can have TACLs running, for example, that are linked to the renamed BALLIB; you just will not be able to start new TACLs until all the old TACLs have been stopped.)

Here is our suggested method of replacing BALLIB with a newer version. We assume TACL, PATHMON, and other programs have been associated with BALLIB and now you want to replace BALLIB with a newer version, called (for this example) NEWLIB:

1. Make a (temporary) duplicate copy of TACL just for this purpose -- but do not run it yet (and do not let anyone else run it).

> FUP DUP TACL, TEMPTACL, SAVEALL

2. Rename BALLIB and replace it with the new one. From this point forward you will be unable to start new TACLs, PATHMONs, and other programs that are linked (by name) to BALLIB, until all running copies of all those programs have been stopped.

> VOLUME $SYSTEM.ZBAL

> RENAME BALLIB, OLDLIB

> RENAME NEWLIB, BALLIB

3. Start the special TEMPTACL, and log on. This works only because no copies of TEMPTACL are running yet, so it is able to pick up the new BALLIB without causing a library conflict.

> TEMPTACL/NAME/

4. Log in to this TEMPTACL, and use it to stop all running TACLs (but not TEMPTACLs), and (if necessary) restart them using your normal procedures. Remember, they must all be stopped before any of them can be restarted. Here is one way to stop them all:

> STATUS *,PROG TACL, STOP

5. Log on to one of the new TACLs, and stop the TEMPTACL (or EXIT from it).

6. For each other program linked to BALLIB, stop all processes and restart them. As with TACL, you must stop all of them before you can restart any of them. For example, for PATHMON, you must shut down all PATHMONs (including Netbatch Plus, Viewpoint, etc.) before you will be able to start or restart any PATHMONs.

7. Purge OLDLIB and TEMPTACL when you are done.

13.8 Technical Notes about (non-Native) User Libraries, like BALLIB

A user library is a set of program functions and procedures that the Nonstop Kernel operating system associates with a program file at run time. User libraries (like object files) behave as read-only swap files for the executing processes that use them.

Binding User-Library Procedures

The first time you execute a program file, the NonStop™ operating system searches the optional user library to resolve each unresolved external reference before searching the code and library.

The operating system resolves an external reference by changing the call in the program file appropriately: that is, to point to the user library or to the system library. You can then run the program file repeatedly without satisfying the references again.

Run-time binding does not include copying the procedure into the program file. A program file can have one (and only one) user library associated with it.

Specifying a User Library

Only one user library can be associated with a program file at any time. Therefore, all concurrently executing processes created from a single program file use the same library file. You specify the user library for a program file by using one of the following:

· A compiler LIBRARY directive

· The Binder command SET LIBRARY (or CHANGE LIBRARY)

· The command interpreter RUN command LIB option

The Binder SET LIBRARY (or CHANGE LIBRARY) command overrides any LIBRARY compiler directives. The RUN command LIB option overrides both the Binder SET LIBRARY commands and the LIBRARY compiler directives.

Library Conflict (non-Native only)

The library file for a non-Native process can be shared by any number of processes. However, when a program is shared by two or more processes, all processes must have the same user library configuration; that is, all processes sharing the program either have the same user library, or they have no user library. A library conflict error occurs when there is already a copy of the program running with a library configuration different from that specified in the call to PROCESS_CREATE_.

For TNS/E Native-mode processes, no such restrictions exist. Different running copies of the same executable may use different versions of a user DLL at the same time.

14 TACL

TACL is one of the most important programs to load-balance, and has significant impact on the performance and operation of your system. Even if you have no interactive TACL users, it is likely that other software uses TACLs to accomplish some of its work. Read more about it in...

· Procedures for implementing or testing the OVERLORD Balancer with a single TACL and later applying it to all TACLs.

· The initial (cold load) TACL requires that the user library, BALLIB, be on $SYSTEM. [6]

· $CMON considerations -- what it does, when you do not need it, and when you still might.

· Procedure for upgrading or replacing the OVERLORD Balancer Library.

· If you run TACLs as nonStop (fault tolerant) process-pairs, you must also use the rTACLBAK macro.

[6] Technically, there is nothing special about the name $SYSTEM -- the initial TACL's library must be on whatever volume you cold load from.

15 Pathway

Automatically balancing Pathway is often one of the most helpful improvements the OVERLORD Balancer can provide.

PATHMON is responsible for starting all Pathway servers and TCPs. Usually the TCPs are static (though in development systems they are frequently dynamic). Pathway servers can be defined as static (NUMSTATIC = MAXSERVERS), dynamic (NUMSTATIC = 0), or both (MAXSERVERS > NUMSTATIC > 0).

Important Note for NonStop Pathmon and Pathtcp2 (fault tolerant process pairs)

When run as a nonStop process pair, Pathway tries to open its own object and library files with READ/WRITE access when a library like BALLIB has been associated with PATHMON or PATHTCP2.

Important:

You must therefore secure PATHMON, PATHTCP2, and BALLIB (or their renamed copies) to be writable by the user id(s) who start PATHMON.

This is not necessary if PATHMON and PATHTCP2 are run without backup processes.

15.1 Pathmon and TCPs

PATHMON itself and the TCPs (PATHTCP2) should usually be manually balanced -- analogous to the way you distribute disk processes or other hardware processes -- because they are large consumers of CPU cycles and memory, and usually need to be up all the time. This is easily accomplished by ensuring that PATHMON and PATHTCP2 (all copies of them, if you have them running from different locations) have a CPU Mask of all zeros (see “Any Mask of All Zeros Means "Do Not Override"” in Chapter 4, OVERLORD Balancer CPU Masks) in the eBALPROG file (see Chapter 6, OVERLORD Balancer Program Rules: eBALPROG). That way, when TACL (linked to the OVERLORD Balancer) starts PATHMON and when PATHMON (linked to the OVERLORD Balancer) starts its PATHTCP2s, the OVERLORD Balancer allows them to go into the specific processors you have them configured to run in.

15.2 Servers

Most servers should be declared dynamic (NUMSTATIC = 0), with a short CREATEDELAY (e.g. 1 second) and a reasonably short DELETEDELAY (e.g. 20 minutes), and you should let the OVERLORD Balancer choose the best CPU for each of these dynamic server processes. By having PATHMON linked to the OVERLORD Balancer (see “Linking the OVERLORD Balancer to other Programs” in Chapter 13, OVERLORD Balancer Library (BALLIB) and DLL (BALDLL)), the OVERLORD Balancer will choose the best CPU for each server process when it gets created.

Using dynamic servers, with the OVERLORD Balancer, usually gives better performance (better end user response time) than having "everything static" -- because it is better for Pathway to create a server process when it is needed, in a lightly-loaded CPU, than to have that server process already running in a CPU that is overloaded.

Using a short DELETEDELAY causes Pathway to delete server processes that have not been used for a while, freeing resources and giving the OVERLORD Balancer more opportunities to keep your system performing well.

15.3 But What About Static Servers?

There are some servers should not be dynamic:

· Servers that run with a specific process name that is opened by other processes.

· Servers that do a lot of "one time only" processing (initialization) when they start up.

For these servers, you should use a CPU Mask of all zeros in one of four places:

· In eBALPROG , for their specific program names.

· In eBALPROC , for their specific process names.

· In eBALUSER , if you can run them with a particular user id not used elsewhere.

· In eBALTERM , if you can run them with a particular home terminal not used elsewhere.

Remember to run UPD (or stop and restart the OVERLORD Balancer) after you make changes to any of the configuration files.

16 Netbatch

Associating the OVERLORD Balancer Library with Netbatch (or any other batch scheduler) will often significantly improve batch throughput and turnaround time, because each executor will go into the most responsive CPU at the time the job starts. (See “Linking the OVERLORD Balancer to other Programs” in Chapter 13, OVERLORD Balancer Library (BALLIB) and DLL (BALDLL).)

Associating the executor (TACL, NBEXEC, or other job processor) with the OVERLORD Balancer Library will help even more, by placing each job step or transient batch process into the best CPU.

You can also take advantage of CPU masks and priority restrictions (see Chapter 6, OVERLORD Balancer Program Rules: eBALPROG), to better manage your batch processes.

17 TCP/IP

> BIND CHANGE LIBRARY $SYSTEM.ZBAL.BALLIB IN LISTNER

(On TNS-mode systems)

> BIND CHANGE LIBRARY $SYSTEM.ZBAL.BALLIB IN TELSERV

(On Native-mode systems)

> BIND CHANGE LIBRARY $SYSTEM.ZBAL.BALLIB IN LOGIN

LISTNER dynamically starts FTP, SMTP, and other services you define in the TCP/IP "PORTCONF" configuration file, when they are needed. Without the OVERLORD Balancer, LISTNER creates each of these server processes in the same processor LISTNER is running in.

(This is probably why the TCP/IP Management and Operations Manual recommends that "LISTNER should be run in a CPU that is lightly loaded" and "that does not have a TCPIP process.") TELSERV or LOGIN creates a TACL process in a dynamic window for each terminal when it connects to TCP/IP. Without the OVERLORD Balancer, TELSERV or LOGIN creates each of these TACLs in the same processor TELSERV or LOGIN is running in.

(This is probably why the TCP/IP Management and Operations Manual also recommends for TELSERV, "it is best to choose a CPU that is lightly loaded.")

Solution: When linked to the Balancer library, LISTNER and TELSERV or LOGIN create each of those processes, when needed, in the best available processor, at the appropriate priority and subject to whatever restrictions you set in the Balancer configuration files. TCP/IP clients will get noticeably better performance from the TCP/IP servers (and you can safely ignore the processor-selection restrictions recommended in the TCP/IP manual).

18 SQLCI

Similar to TACL, SQLCI is an interactive and/or batch command executor which creates other processes to do a lot of its work.

By associating the OVERLORD Balancer Library with SQLCI, each of those other processes will be placed into the best CPU, improving their performance and system-wide balance.

Note that SQLCI2 must (by design) run in the same CPU SQLCI (or any other creator of SQLCI2). The OVERLORD Balancer understands this and automatically does the right thing.

19 SNAX

TACL> BIND CHANGE LIBRARY $SYSTEM.ZBAL.BALLIB IN CREATOR

The SNAX CREATOR creates application processes and/or command interpreters (e.g. TACLs) for users at SNAX/CDF and SNAX/XF terminals configured for LUNS (Logical Unit Network Support).

Without the OVERLORD Balancer, CREATOR uses the relevant SNAXUTL ESS table "APPLFILE" or "TACL" data to start each LUNS application when requested by a SNAX user: if a CPU number is specified in the ESS table, CREATOR uses that one processor for every copy of the application process; if no CPU is specified in the ESS table, CREATOR uses the next available processor (in numeric order) for each copy of the application process. This can easily lead to over-utilization of the specified CPU(s) when many users are using the same application.

Solution: When linked to the OVERLORD Balancer library, the SNAX CREATOR creates each application process in the best available processor, at the appropriate priority and subject to whatever restrictions you set in the OVERLORD Balancer configuration files. SNAX users will get noticeably better performance and, in most cases, you can use smaller and more easily managed ESS tables.

20 $CMON

$CMON is an optional process, written in any programming language, to which Guardian command interpreters (TACL and SQLCI) pass certain requests (for approval or modification) before they pass those requests to the operating system. There is no standard $CMON; each NonStop™ Server system may or may not have a $CMON written specifically for that system or copied from another system (or, e.g. from the ITUG library).

The OVERLORD Balancer gains control of process-creation after $CMON makes its recommendation (if any). While testing the OVERLORD Balancer, it is recommended to leave your $CMON as is (do not stop it or change its behavior). It is never necessary to stop or modify your $CMON when implementing the OVERLORD Balancer, because the OVERLORD Balancer's decisions override the CPU and priority choices made by $CMON.

Only after putting the OVERLORD Balancer into production or when measuring detailed performance comparisons should the following information be considered:

$CMON Details

$CMON can influence the following types of TACL/SQLCI user requests:

· Automatic TACL configuration (prior to LOGON)

· Requests to log on and log off (LOGON and LOGOFF)

· Requests to change passwords (PASSWORD and REMOTEPASSWORD)

· Requests to add or delete a user (ADDUSER and DELUSER)

· Requests to change a running process' priority (ALTPRI)

· Requests to start a process (RUN and implicit run)

Whether or not a $CMON is running and whether or not $CMON makes changes to the requested CPU and priority, the OVERLORD Balancer influences the process-creation request when TACL or SQLCI asks the operating system to create a process. The OVERLORD Balancer chooses the best processor and enforces your priority rules the same way, whether or not a $CMON has made an conflicting recommendation.

If your $CMON is only being used to select processors and priorities, you can safely stop running $CMON after implementing the OVERLORD Balancer for TACL and SQLCI.

If your $CMON is being used to substitute one program for another, or for any of the above security features, you may want to consider modifying it to minimize the delay $CMON adds to process-creation, if it is also making (now irrelevant) CPU and priority choices.

21 Compilers

The (non-native) NonStop Server compilers all use the same method of starting their helper programs, BINSERV and SYMSERV. BINSERV is always started in the same processor as the compiler (because they share an extended memory segment). SYMSERV is started in the next processor, or if there is no next higher processor, it is started in processor 0. For some compilers, a directive "SAMECPU 1" asks the compiler to create SYMSERV in the same processor as the compiler itself.

On D-Series and subsequent systems, it may be advantageous to use "SAMECPU 1" wherever it is available, because interprocess messages (between SYMSERV and the compiler) are faster within a single CPU.

On C-Series systems, it is probably never advisable to use "SAMECPU 1" because there is no interprocess message performance advantage within a CPU. If you are not routinely using "SAMECPU 1" -- or are using languages whose compilers do not support such a directive -- the OVERLORD Balancer can improve compile turnaround time by placing SYMSERV in the best available processor, providing much better parallelism than the default. (As with any OVERLORD Balancer-managed program, you can also control which processors and priorities are permitted -- see Chapter 6, OVERLORD Balancer Program Rules: eBALPROG.)

21.1 Example

(See “Linking the OVERLORD Balancer to other Programs” in Chapter 13, OVERLORD Balancer Library (BALLIB) and DLL (BALDLL) for details.)

> fup dup TAL, TALN, saveall

> bind change library $SYSTEM.ZBAL.BALLIB in TALN

> rename TAL, TALO

> rename TALN, TAL

From then on, any time TAL is used, the best processor would be chosen for SYMSERV which would most likely improve compile turnaround time. The same can be done with any other compiler for any other language.

If you have also associated the OVERLORD Balancer with TACL (see Chapter 14, OVERLORD Balancer and TACL) and/or with Netbatch (see Chapter 16, OVERLORD Balancer and Netbatch), the compilers as well as their helpers will be placed most efficiently.

22 CA-Unicenter

Associating the OVERLORD Balancer Library with CA-Unicenter (or any other batch scheduler) can significantly improve batch throughput and turnaround time, because each executor will go into the most responsive CPU at the time the job starts.

Associating the executor (TACL or other job processor) with the OVERLORD Balancer Library will help even more, by placing each job step or transient batch process into the best CPU.

You can also take advantage of priority restrictions, to better manage your batch (and other) processes.

23 Safeguard

> BIND CHANGE LIBRARY $SYSTEM.ZBAL.BALLIB IN OSMP

OSMP creates safeguard management processes (including per-CPU OSMONs -- see below) and command interpreters (e.g. TACLs) for users at Safeguard-controlled terminals. Without the OVERLORD Balancer, OSMP uses its own processor for every application process.

Solution: When linked to the OVERLORD Balancer library, OSMP creates each TACL (or other application process) in the best available processor, at the appropriate priority and subject to whatever restrictions you set in the OVERLORD Balancer configuration files. Safeguard terminal users will get noticeably better performance.

Important: In versions of the OVERLORD Balancer prior to v6.1, you must manually exclude OSMON (by placing it in the eBALPROG file) in order to allow Safeguard to put the OSMON processes in their appropriate CPUs. OVERLORD Balancer versions 6.1 and later automatically know how to handle OSMON and similar CPU-specific programs.

24 ENFORM

Read below (“ENFORM OPTIMIZER”) if you are using Hewlett-Packard's ENFORM OPTIMIZER -- otherwise you can just...

> BIND CHANGE LIBRARY $SYSTEM.ZBAL.BALLIB IN ENFORM

> BIND CHANGE LIBRARY $SYSTEM.ZBAL.BALLIB IN QP

ENFORM is a program which generates reports or extracts data from ENSCRIBE structured files. ENFORM usually starts a QP process to retrieve data from a file.

QP is a "query processor" started by ENFORM (and possibly by other programs). It in turn may start one or more SORT processes.

When linked to the OVERLORD Balancer library (see Chapter 13, OVERLORD Balancer Library (BALLIB) and DLL (BALDLL)), ENFORM will create its QPs, and the QPs will create their SORT processes, in the best available processors, at the appropriate priority and subject to whatever restrictions you have set -- see Chapter 3, OVERLORD Balancer Configuration. Enforms will get noticeably better turnaround and/or have less negative impact on your system's performance, depending on how you set ENFORM and QP priorities.

24.1 ENFORM Optimizer

ENFORM OPTIMIZER, a Hewlett-Packard product, adds its own user library to Enform. To use the OVERLORD Balancer along with ENFORM OPTIMIZER, you should combine the two user libraries (see “Combining User Libraries” in Chapter 13, OVERLORD Balancer Library (BALLIB) and DLL (BALDLL)). Doing so will give you all the performance advantages provided by the OVERLORD Balancer in conjunction with the improved query performance provided by the ENFORM OPTIMIZER.

25 DSM

You may want to adjust HP's Distributed Software Management infrastructure so that, when it replaces TACL and other objects with which you have associated the OVERLORD Balancer Library (see “Linking the OVERLORD Balancer to other Programs” in Chapter 13, OVERLORD Balancer Library (BALLIB) and DLL (BALDLL)), it does not remove that association. Otherwise, you will have to remember to do that manually any time you install a new release of TACL, PATHMON, or other HP-supplied object files you want the OVERLORD Balancer to intercept.

If you pre-link BALLIB with the desired products in their distribution or installation subvolumes, just as you would for an installed copy, the DSM will install a ready-to-run object with the OVERLORD Balancer library already associated.

Similar strategies work if you still use the traditional INSTALL, SYSGEN procedures instead of DSM.

26 rTACLBAK macro

This macro should be RUN from TACLLOCL and/or TACLCSTM, when you want to ensure TACL will have a backup process. Most TACLs do not need a backup process, and all TACLs run more efficiently without one. But if you need one, you should use this macro to be sure you get one every time the TACL is started.

rTACLBAK creates a TACL backup process in an available CPU, if the current TACL is named and does not already have a backup process. This ensures that the TACL runs with a backup process regardless of the CPU selected for its primary process.

That selected backup CPU number is normally irrelevant, because the OVERLORD Balancer will choose the appropriate CPU for the backup process when TACL requests its creation.

(This TACL macro is necessary to cause TACL to request creation of its backup process in a different CPU from the TACL's primary CPU -- otherwise TACL won't try creating a backup process when its actual primary CPU and specified backup CPU are the same, which can happen when the OVERLORD Balancer chooses the primary CPU and the backup CPU is hard-coded in the initial process creation request.)

27 Appendex A: Log, Warning, Error and other Messages

This section describes all the log, status, warning, and error messages that may be written to the Balancer's LOG and/or OUT files, as well as all possible process termination text messages.

Configuration status, warning, and error messages are written to OVERLORD Balancer's OUT file (during startup) or to UPD's OUT file (during reconfiguration). (If unable to write to the OUT file, they are written to the primary EMS collector, $0.) These messages are also written to the LOG file, if the LOG option is ON. (See “[A] LOG Information” in Chapter 5, OVERLORD Balancer Main Configuration File: eBALCONF.)

Activity log messages are written only to the LOG file.

Process termination text messages are returned to the process's creator. If that creator is a TACL, they are (by default) written to TACL's OUT file and are (always) accessible via TACL's :_completion structure. (Other process creators have their own ways of accessing process completion codes, termination text, and related information.)

All possible messages are described here, in alphabetical order (special characters and variable portions of the messages have been ignored while sorting them), and their descriptions refer to more detailed information, where appropriate.

timestamp OVERLORD Balancer backup is taking over because primary ABENDed.

(The timestamp is in yyyy-mm-dd hh:mm:ss form.) The backup process has taken over (and is now the primary process) because the previous primary process has ABENDed.

timestamp OVERLORD Balancer backup is taking over because primary CPU went down.

(The timestamp is in yyyy-mm-dd hh:mm:ss form.) The backup process has taken over (and is now the primary process) because the primary CPU is no longer available.

timestamp OVERLORD Balancer backup is taking over because primary stopped.

(The timestamp is in yyyy-mm-dd hh:mm:ss form.) The backup process has taken over (and is now the primary process) because someone or something has STOPped the previous primary process.

timestamp OVERLORD Balancer backup process has died.

(The timestamp is in yyyy-mm-dd hh:mm:ss form.) The backup process has died for one of many reasons (STOP, ABEND, trap, resource shortage, or CPU failure). Other messages will provide more details and will record the actions taken by the OVERLORD Balancer in response to this.

timestamp OVERLORD Balancer backup process was created in CPU cpu_number.

(The timestamp is in yyyy-mm-dd hh:mm:ss form.) The backup pr