From BR Wiki
(Redirected from BRConfig.sys)
Jump to navigation Jump to search

The Business Rules! configuration file (generally referred to as the "BRConfig.sys") contains environmental specifications that support the use of standards to be applied across multiple operating environments. In other words when an environment changes your application need not change. Only the configuration file needs to change.

BRConfig.sys specifications are specified in a plain text file which Business Rules! automatically accesses at BR32.exe start-up. You can create and edit this file with any text editor. The line length is limited to 800 characters. See also Config for Beginners.

Invoking BRConfig.sys

Whenever Business Rules! is started with the BR32.exe command, it automatically searches for a Business Rules! configuration file. Unless you specify otherwise (as a parameter for the BR startup command), Business Rules! assumes that the configuration file is named BRConfig.sys (or BRCONFIG.SYS). Older versions of the Business Rules! configuration file defaulted to the name WBConfig.sys. If BRConfig.sys is not found then WBConfig.sys will be searched for and used if possible.

There is no limit to the number of configuration files that may exist. If you want Business Rules! to access a configuration file that has a name other than BRConfig.sys (or WBConfig.sys), you must specify its name as part of the BR start-up command. (See the explanation of the BR32.exe command or the Getting Started for more information.)

Business Rules! configuration files may include one or more of the system's BRConfig.sys specifications. A comment, when separated from the specification by one or more spaces, may follow each of these specifications. When Business Rules! is started, the screen displays BRConfig.sys specifications that contain errors. These errors are ignored (default settings are used for any specification with an error), and processing continues without interruption.

The remainder of this article contains details about individual BRConfig.sys specifications.

Each specification in the BRConfig.sys file may be followed by at least one space, an exclamation point (!) and a comment. Business Rules! will ignore everything after the exclamation point.

Note: If BR is unable to remove the WBServer.dat file when the first user logs in, it will attempt to truncate the file to zero bytes before proceeding.

Overriding BRConfig.sys specifications

Most specifications set in the BRConfig.sys file can be replaced or overridden in programs by using the syntax "execute 'config XXXXXXXX'" where "XXXXXXXX" is one of many available keywords and associated values. Config does not actually change the file; it simply overrides the specification in the file. CONFIG will take effect when a program is active. It may be used in a procedure file and it may be specified with the Execute statement.

A listing of the current specifications and their values can be viewed after Business Rules! is started by entering STATUS CONFIG at a command prompt from within Business Rules.


BR! 4.0+ automatically looks for a configuration file called BRConfig.sys and programs ending with .BR before looking for their .WB counterparts.

Starting with version 4.0, programs save as .BR files instead of .WB files. [Option 29 can be specified to suppress this feature.


All BRConfig.sys specifications and Config commands will accept an environment variable specified in the format %env-var%, where "env-var" is the name of an environment variable that has already been set up at the operating system level.

Whenever an environment variable specified in this format is encountered, Business Rules! will substitute the contents of the environment variable in the BRConfig.sys specification. If the specified environment variable is not defined at the operating system level, no substitution will occur. (In some cases an error will result, but in others the environment variable format will be accepted as a literal specification.)

The environment variable will probably be most useful for specifying user-specific information. The BRConfig.sys specifications for which it is expected to be most useful include Substitute and Include.



The Application_Name config specification sets the name used by BR for the following purposes:

May be set in the BRconfig.sys file or called dynamically using the Execute statement.

Introduced in Business Rules! 4.16.


See also: Attribute (disambiguation)

The Attribute config specification can be used to substitute attribute combinations, such as U/RGB:B, with square-bracketed letters, such as [X], called subattributes ("subatts").

The subattributes can be used in place of attribute combinations wherever they are allowed in programs. This will reduce coding time, repetition and program size. It will also increase portability, decrease processing time and encourage standardization.


Comments and Examples

The following BRConfig.sys ATTRIBUTE specification substitutes the attribute combination U/RGB:B with the subattribute [X].


Also, the contents of defined subattributes can be assigned (or copied) to other subattributes, but multiple subattributes cannot be combined by the assignment process. The following BRConfig.sys specification assigns the attribute combination U/RGB:B to the subattribute [X] and the attribute combination R/HRGB:R to the subattribute [A]. Then it assigns the current value of subattribute [X] to subattribute [E] and the current value of subattribute [A] to subattribute [W]:


Wherever attribute processing occurs (such as in PRINT FIELDS and INPUT FIELDS statements), Business Rules will now accept subattributes as long as they have been defined in CONFIG commands or in the BRConfig.sys file. If a subattribute is used but not defined, Business Rules will use the N default attribute setting (which is the same as the current Windows default setting).

The following BRConfig.sys spec assigns the attribute combination U/RGB:B to the subattribute [D]:


When the above attribute spec is active, the following INPUT FIELDS will display a 10-character field in underline (on a monochrome monitor) or in white letters on a blue background (on a color monitor).

20 INPUT FIELDS "1,1,C 10,[D]:X$"
CONFIG ATTRIBUTE [J]RH,font=ariel,slant,max

This specifies reverse highlight ariel italics maximum size.


ATTRIBUTE [sub-attribute] attributes [defined sub-attribute] [...] 
*in this syntax description, square brackets are required around the sub-attributes.


In the above diagram, the "subattribute" parameter represents any uppercase or lowercase letter from A to Z. The letter must be specified within square brackets, and the specification is not case sensitive. See the recommended list in the Technical Considerations section below for suggested assignments

The "attributes" parameter represents the set of specifications that identify the visual and control aspects of a screen display. Business Rules will use this attribute combination wherever it finds the preceding subattribute in a program. See Attribute (Screen) for the required syntax for the "attributes" parameter.

The "defined subattribute" parameter is a "subattribute" to which an attribute combination has already been assigned. The value of this "defined subattribute" is assigned to the "subattribute" which precedes it. This supports assignment of one subattribute's value to another.

Technical Considerations

1.) The ATTRIBUTE specification can also be used with the CONFIG command. See the "CONFIG" command below for more information.
2.) If an invalid character is entered as a subattribute, the 0863 Invalid Attribute Substitution Character error will be displayed.
3.) ATTRIBUTE allows you to set up to 26 combinations of attributes for reference in programs.
4.) The following subattribute-coding scheme was revised by BRC in early 1995, as follows:

Special Settings Used For Selection Operations

"A" - normal cursor bar (attr)
"B" - selected item - no cursor
"C" - cursor on selected item

Note: V is an unselected data item

Window This is the normal screen. By default, text is black and the window background is the same as that of the Windows default configuration. If a user changes his Windows colors, this background color will change accordingly.
Error This color scheme is used for error displays.
Information This type of window is also called a dialog box.
Menu A system menu.
Selection This is used for a point-and-shoot operation. These colors are often the same as the menu colors because they are both used for selection.

Special Selection Settings: These are used to identify the cursor bar in conjunction with a variety of situations.

The ATTRIBUTE specification includes the ability to specify the colors that are to be used in the Business Rules help screens that are accessed with the HELP$ function. Help files need not be edited or modified in any way to take advantage of this feature. In the following syntax diagram, the [HPROMPT], [HTEXT], [HLIGHTBAR] and [HMENU] parameters were previously undocumented:


The documented parameters affect the following aspects of Business Rules help displays:

[HPROMPT] On-line help prompts (i.e., "Press F2 for related topics")
[HTEXT] On-line help text
[HLIGHTBAR] On-line help's menu selection bar
[HMENU] On-line help menus

Recommended attributes

BRC recommends that you set up your on-line help attributes as shown in the ATTRIBUTE specification that follows. (See item 4 in the technical consideration section above for a list of standard subattribute assignments.)


Attribute Substitution Name Extensions

Attribute substitution names [xxx] may be up to 12 characters long. Fonts can be specified at the field level by assigning them to attribute substitution names.


CONFIG ATTRIBUTE [hilite_text]/#rrggbb:#rrggbb font=arial:slant:max

This specifies that [hilite_text] denotes foreground and background colors specified as #rrggbb with arial, italics, and maximum size font.

Font names with embedded spaces should NOT be enclosed in quotation marks. e.g. Font=Free 3 of 9

Screen and Attribute Statements Working Together

SCREEN statements can now use attribute substitution names. The more readable method for specifying screen attributes is to first define each attribute through an attribute substitution name and then reference them in SCREEN statements. This means that the ATTRIBUTE and SCREEN statements can be used to progressively build upon one another.

Attribute 70 (black on white) is the "normal" default for the Windows model.

Example 1: (this goes into your BRCONFIG.SYS file):

ATTRIBUTE [lime_black]/#00FF00:#000000
ATTRIBUTE [orange_white]/#FFA500:#FFFFFF
ATTRIBUTE [XX]UH/RGB:W font=arial:slant:max
! W and font= are ignored by Unix terminal support
SCREEN N [lime_black], U [orange_white], R [XX]

Example 2:

ATTRIBUTE [normal]/W:W    ! windows foreground and background
SCREEN N [normal]

The /#rrggbb:#rrggbb embedded syntax in FIELDS statements still overrides color for the corresponding fields, irrespective of SCREEN settings. Also supported is W, which may be specified in lieu of R, G, B and H, denoting use of current Windows colors.


/RG:W     -  yellow foreground on Windows background color

X attribute suppression

Option 24 suppresses recognition of the X attribute during INPUT SELECT operations. This is how versions prior to 3.8 worked, even though the documentation indicated that X applies to SELECT operations. Note- this is OPTION 25 in version 3.8.


The Font config specification is supported. See also Font (Config).

FONT fontname 3DFONT=fontname

This supports two fonts simultaneously, one for background and captions and one font for input fields.

Version 3.9+ supports the command STATUS FONTS. This will report all currently installed Windows fonts that are acceptable in a FONT statement. Also fonts can be changed dynamically via the CONFIG command.

Version 4.1+ allows specific proportional or non-proportional fonts for text, labels and buttons

Multiple fonts are now supported under Windows. The default is still SYSTEMPC. Any installed non-proportional font is permitted that is named in the following BRCONFIG.SYS statement:

BRCONFIG.SYS statement


Where the options are arial: modern: slant: width+ (etc.)

The above settings are used initially and as OPEN #0 font defaults. When a child window is opened it inherits the parent windows font settings. Window #0 inherits the OPENDFLT font settings each time it is opened. When typeface or family is specified in an Open statement, boldness, style and underline revert to these defaults unless they are also specified in the Open statement.

Size specifications do not revert to default values as a result of opening a window. They must be explicitly specified in order to change them. This is to allow for users resizing their displays and retaining those settings.

Individual controls inherit the font settings of the window the same way windows inherit settings.

The default font is the user's Windows default font. Separate fonts may be invoked for Labels, Buttons, and Text (data entry fields):

OPEN #0: "Srow=5,Scol=5,Rows=25,Cols=80,FONT=Arial", Display, Outin

(specifies a base font)

OPEN #0: "Rows=30,Cols=100,FONT.LABELS=Terminal,FONT.TEXT=Arial,FONT.BUTTONS=Lucida Console", Display, Outin

Font Qualifiers

  • Decor
  • Roman
  • Script
  • Swiss
  • Modern (fixed)
This is useful in addition to the font name for systems that don't have the specified font.
  • Light
  • Bold
  • Ital
  • Slant
  • Under
  • Small
  • Medium
  • Large
  • Max
Size is based entirely on font height.

Font Size Adjustment- adjusts the size of displayed text down to accomodate the horizontal space allocated for the text

Width: Determine the average caps + digits character width. Then reduce the font size until the number of characters times this average fits the BR field capacity.
Width+: Determine the average letter size considering both upper and lower case letters. Then apply the width limitation.
Width-: Make the font small enough to accommodate a string of capital W's.
NoWidth: Clear the Width adjustment setting.


OPEN #0: "Rows=30,Cols=100,FONT.LABELS=Terminal:bold:slant,FONT.TEXT=Arial,FONT.BUTTONS=Lucida Console", Display, Outin

The former FONTSIZE=99x99 parameter is only supported when GUI is OFF.


A BaseYear BRConfig.sys specification specifies the starting year of a 100-year window that Business Rules! will treat as the default century for the Days function when the century is not otherwise specified. BaseYear may also be executed from within a program with the Config BaseYear command or from within a program line with the Execute statement. The format is as follows, where "number" must be a value from 1900 to 2399. The default is 1900.

Start-up Default


If the century is not included in the Days value, Business Rules! assumes that all dates fall into the 100-year window specified by BaseYear. In cases where the 100 year window spans two different centuries, the year of the date passed by Days (00-99) is compared to the last 2 digits of BaseYear. If the year passed is equal to or greater than the last 2 digits in BaseYear, the century specified in BaseYear is assumed. If the year passed is less than the last two digits in BaseYear, the first century following the year specified in BaseYear is assumed.

Changing the value of BaseYear does not affect the "logical" value returned by the Days function. The returned value is still the number of days since January 0, 1900.

Important note

Dates prior to BaseYear can no longer be entered in M/D/Y format, as they will assume the next century. This does not affect dates already entered and converted to days. For example those stored in a history file would not be affected. If your application must work with dates wider than a 100-year range, the dates should be changed to show the century.


DATE("*MDY")     ! set default format
CONFIG BaseYear 1950
Print Days(010122)  ! assumes 01/01/2022
Print Days(010193)  ! assumes 01/01/1993

How it affects current applications

By simply placing BaseYear 1910 in your BRConfig.sys file, all dates entered and processed with the Days function will assume the 21st century for dates between 01/01/00 and 12/31/09. If you always use the results from the Days function when comparing dates, your programs should require no changes to continue working into the next century.


For disambiguation purposes, see also Break (command).

The Break config specification is used to specify the frequency with which Business Rules! checks keyboard input for Ctrl-A or function key (ON FKEY) operations.

The syntax of the BREAK spec is as follows:

The lines parameter indicates the number of program lines that should be executed before keyboard input is checked for a Ctrl-A or function key operation. Please note that lines refers to the amount of numbered program lines, not the number of statements (a single line can contain several statements). Also, note that the system breaks after the specified number of lines are executed; lines which are not executed (DIM, for example), are not included in the break count.

The start-up default for the BREAK spec is 8. Business Rules! checks the input buffer before execution of every line. Using a value greater than 8 will normally have very little impact on overall program performance and should not be used.


The following BREAK spec would cause Business Rules! to check keyboard input after execution of every program line:


The BREAK spec may also be executed within a program through use of the CONFIG command. This example would override the BRConfig.sys file's BREAK specification and cause keyboard input checking to occur after every six lines are executed:



The BRServer (a.k.a. WBServer in older versions) BRConfig.sys statement does not require a drive letter.

See also: WBServer.dat


The ChainDflt BRConfig.sys specification instructs the system to look for .BRO extensions before .BR extensions in file names. It can also be used with the Config ChainDflt command or within a program line using the Execute statement.

Comments and Examples

When you specify a program name in a CHAIN statement or LOAD command without indicating an extension, Business Rules! automatically assumes the extension is .BR unless you end the program name with a period, in which case Business Rules! assumes there is no extension. For example, if you specify PROG1, Business Rules! looks for a file with the name PROG1.BR. If it finds no file with that name, the system then looks for a file with the extension .BRO (an object file). The CHAINDFLT specification tells Business Rules! to look for a file with the .BRO extension before looking for one with the .BR extension.


Start-up Default

When no period and extension are specified in a file name, BR searches first for a file by the given name and a .BR extension. If no match occurs, it searches for a file by the given name and a .BRO extension.


1.) The CONFIG command can be used during program execution to override the BRConfig.sys file's CHAINDFLT specification.


The Collate BRConfig.sys specification indicates which collating sequence the system should use. It can also be used with the Config Collate command or within a program line using the Execute statement.

Also used in the Option (Statement).

Comments and Examples

A collating sequence provides the means for organizing the binary values that represent letters of the alphabet, numbers, and other symbols. Each binary value (and thus each letter, number, or symbol) is assigned a number. The number that a particular character is assigned will differ according the collating sequence being used. The COLLATE specification tells Business Rules! which collating sequence to use.


Start-up Default



COLLATE NATIVE specifies the ASCII collating sequence. In this sequence, the binary representations of the numbers 0-9 precede those of the uppercase letters A-Z, which in turn precede their lowercase counterparts. The numbers 0-9, then, are represented by ASCII codes 048-057; uppercase letters are represented by ASCII codes 065-090, and lowercase letters are represented by codes 097-122.
(See a complete listing of ASCII codes for details.)

The COLLATE ALTERNATE specification specifies a collating sequence similar to EBCDIC in that the numbers 0-9 follow uppercase and lowercase letters (other values will differ). With COLLATE ALTERNATE, 0-9 are represented by codes 176-195.

Technical Considerations

1.) The CONFIG command may be used during program execution to override the BRConfig.sys file's COLLATE specification.
2.) Business Rules! saves programs with whatever COLLATE option it is currently operating under. If you write a program when the system is using the default, for instance, the program runs with COLLATE NATIVE. If you resave the program when the system is using COLLATE ALTERNATE, however, the program then runs with COLLATE ALTERNATE.
3.) It is important to be consistent in your use of the COLLATE specification, as it affects all character comparisons-including AIDX, DIDX, MAX$, MIN$ and ORD A, as well as the SORT Facility's RECORD specification and character comparisons used in IF statements.
4.) The SORT function uses the current COLLATE specification unless a new one is specified in the SORT parameters. NOTE that the COLLATE ALTERNATE option overrides the FILE specification's "N" parameter when used with the SORT function (see Sort Facility for more information).
5.) Index files use the COLLATE option that is specified when the index is created or recreated; it does not matter what option is currently in effect in programs that use the index. See the Index command for a parameter to override this.

See Also

Collate Alternate

Collate Alternate

The Collate Alternate BRConfig.sys file's COLLATE ALTERNATE specification allows for string comparisons to be done in ascii while treating numbers as though they followed alphabet characters in the collating sequence. This revised collating sequence will be used whenever OPTION COLLATE ALTERNATE is specified in programs or when A (for alternate collating sequence) is specified with the sort control file's FILE specification.

An optional filename has been removed from CONFIG COLLATE ALTERNATE with version 4.16 Instead the default ALTERNATE table is used which simply moves the digits 0 - 9 above the alphabet ( starting in position 176 or x'B0' ). This rather crude translation is sufficient for most program logic that depended upon the EBCDIC character set. The data in the BR programs is processed in ascii with the exception of the relocated digits.

See Also


The Color BRConfig.sys specification is available as of 4.18.

It can be used to create color attributes (shortcuts) with:

Comments and Example


The keyword color means that the label in square brackets, in this case WARNING, will signify the hex color #FFFF00. Then you can use the label in place of the actual color CODES in your programs.

Color may be used with the config command, or used with the execute statement.

"Status Colors" lists all the color statements that you have in effect.

The COLOR specification controls the use of color as specified in INPUT FIELDS, RINPUT FIELDS and PRINT FIELDS statements.


COLOR [<label>] <name or #hex>

Start-up Default

Act upon color attributes when the monitor in use at start-up is a color monitor; ignore color attributes when the start-up monitor is monochrome.


The "N" parameter directs Business Rules! to ignore color attributes in PRINT FIELDS, INPUT FIELDS and RINPUT FIELDS statements.

The "Y" parameter directs Business Rules! to act upon indicated color attributes, even if the hardware is monochrome.

Technical Considerations

1.) The CONFIG command can be used during program execution to override the BRConfig.sys file's COLOR specification.
2.) When COLOR is not included in the BRConfig.sys file, Business Rules! automatically utilizes color and monochrome attributes according to the type of monitor being utilized. With no COLOR specification in the BRConfig.sys, execution of the following program line would cause monochrome monitors to display UH (underline and highlight), whereas color monitors would show R:B (red on blue background):
10000 INPUT FIELDS "4,4,C 20,UH/R:B":X$
3.) Perhaps the most useful application of the COLOR specification is the testing of monochrome or color attributes when working on a screen of the opposite type.

Command Console Colors

The SCREEN C [xx] specification determines the foreground and background colors of the command console. Running the following example program sets a white foreground and dark red background for the command console.

The name of this program is: COMCONSL.BR





The default under Windows is to reverse each field as it is entered, and to position the cursor at the end of the data. This type of processing can be turned off by specifying DATAHILITE OFF in the BRconfig.SYS file.


The above indicates that the user's Windows specifications for selected text should apply to highlighted text.


OFF can be used to turn this feature off.

Decimal Statement

The DECIMAL BRConfig.sys specification allows you to require the operator to type a decimal point when entering a numeric value that is formatted to include a fraction. This specification affects INPUT FIELDS/RINPUT FIELDS statements where the format of the numeric variable is X.X, as in the following example:

00010 INPUT FIELDS "10,10,N 7.2,R":NUMBER

The DECIMAL spec uses one of two parameters:

  • ASSUMED (the start-up default), or
  • REQUIRED. When DECIMAL REQUIRED is active, the operator needs to enter a decimal point for the above INPUT FIELDS value, only if a fractional part of a number is desired.

The following table compares the acceptable values for NUMBER when DECIMAL REQUIRED is active versus when DECIMAL ASSUMED is active.

1234.56 1234.56 1234.56
1234 56 err 0002 1234.56
123456 err 0002 1234.56
1234 1234.00 notice 12.34
1234. 1234.00 1234.00

The difference occurs when a decimal point is not entered. The DECIMAL spec may also be specified by the CONFIG command while Business Rules! is active.

It can also be used with the Config command or within a program line using the Execute statement.


The DimOnly BRConfig.sys specification can be used to prohibit the creation of new variables during program editing unless the variable has been defined by a Dim statement.


  1. Prohibit program entry of variable names which are not dimensioned.


It can also be used with the Config command or within a program line using the Execute statement.


The Drive BRConfig.sys specification abstracts ( translates ) hardware disk storage and network setups to make applications more portable. The Drive specification also allows Linux files to be accessed with MS Windows naming conventions.


DRIVE <drive letter>[:], <server-full-pathname>, [<client-full-pathname>], \[<subdirectory-name>]

"drive-letter" is the letter to be assigned and may be followed by a colon. Commas must be used as separators between parameters.

"server-full-pathname" is the OS full pathname and may include the OS drive reference (see examples below). Within BR this will appear to be the root directory on that drive.

"client-full-pathname" is optional and identifies the initial working directory on the client computer.

"subdirectory-name" is optional and specifies a directory beneath the directory specified in the second parameter. The specified name becomes the current directory and must be preceded by a forward slash. This parameter is case-sensitive; Business Rules will not translate uppercase specifications into lowercase letters.

Technical Considerations

  1. The first Drive specification identifies the initial current directory when Business Rules! is started.
  2. At least one Drive specification is required in the BRConfig.sys file. This makes it clear where the initial working directory is. While the Windows model permits startup with no Drive statement, and permits references to drives with no Drive statement, file sharing protection is not implemented for such drives.
  3. The only place that Drive can be specified is in the BRConfig.sys file; it is not valid with the config command.
  4. Drive statements must have four parameters. The third parameter may have a null value (be left empty). A backslash in the fourth parameter may be used to startup in the OS directory specified by the second parameter.

Comments and Examples

Business Rules! utilizes a file naming structure similar to MS Windows for file and path references. In BR pathnames backslashes ( \ ) are used to separate directory names even when running on Linux. Also on Linux all filenames specified in programs are set to lowercase when converting to OS filenames irrespective of the case used by BR programs. This is done to simulate case insensitive filenames. Note: this feature may be overridden by the FileNames configuration statement.

Windows uses case insensitive filenames, whereas all Unix derivatives (Linux and Mac) use case sensitive filenames. Therefore, the second parameter of the drive statement is case sensitive for Linux and Mac, but not for Windows. All other drive statement parameters are case insensitive.

The Windows model of BR permits accessing drives without drive statements, but the Status command does not report the configuration of such drives, and file and record locking is not performed on such drives. Therefore you are encouraged to get familiar with the drive statement, and begin using it.

Other BRConfig.sys statement pathnames are subject to preceding drive definitions. In other words any pathname references in the BRConfig.sys file (other than tose appearing in Drive statements) will be translated to OS pathnames via preceding Drive statements. To use actual OS pathnames in BR, begin the names with a colon (which is removed when the pathname is utilized by BR).

"drive-letter" is the Windows-like drive letter (A-Z) appearing in a BR program OPEN string filename (e.g. C:).

"server-full-path" is the actual OS full pathname to the directory referenced by the drive-id. (e.g E:\CUSTFILES or \\MYSERVER\CUST_SHARENAME\) Note that UNC names (beginning with \\server-name) operate significantly faster than drive letter mappings.

"subdirectory" is the parameter of an implied beginning CD command on the drive. BR acts as though your application changed to this subdirectory during startup.


Defines a network node (F:\MYAPP) as the C: drive and performs an implied CD \PRL on this drive during startup.

BR assumes that any references to undefined drives (F:, G:, etc.) refer to the root directory on those drives. Also, RECORD LOCKING IS NOT PERFORMED ON SUCH DRIVES. The Protect Reserve command only works on filenames that pertain to drives that are identified by a drive statement.

BR file search order during file OPEN processing

BR executable Windows Working Directory or Linux/MAC current directory at the time BR is invoked. Note that this may be different from the actual location of BR if a full pathname is given as the executable ( typically from within a startup script ). This "current working directory" is regarded as the BR executable directory.
BRConfig.sys Command Line Parameter or BR executable directory
WBCmd.wbh First Drive location
BRServer.dat BRServer configuration statement or first Drive location
BRSerial.dat BR executable directory
WBTerm.out BR executable directory
Initial 'current' directory First Drive location

Note that pathnames given in BRConfig.sys statements are subject to preceding DRIVE statements. To use actual OS pathnames, begin the names with a colon (which is stripped by BR).


The S/23-Drives BRConfig.sys specification, designed for Business Rules! compatibility with code converted from the IBM System/23, assigns up to nine System/23 drive numbers to DOS drive letters.

Comments and Examples

The primary advantage of the S/23-DRIVES specification is that it supports drive assignments without depending upon the hardware configuration; nonexistent drives can be routed to an existing drive.


Start-up Default



"Drive letter" is the drive to which a System/23 drive should be assigned. This parameter may be repeated up to nine times.

The System/23 drive number is indicated by the ordinal position of the drive letter parameter. In the default specification S/23-DRIVES ABCCCCCCC, for instance,
System/23 drive 1 goes to drive A;
System/23 drive 2 goes to drive B;
System/23 drives 4-9 go to drive C.

Other specifications, such as S/23-DRIVES ABCDDDDDD or S/23-DRIVES ACBCCCCCC, work in the same manner.

Technical Considerations

  1. The CONFIG command can be used during program execution to override the BRConfig.sys file's S/23-DRIVES specification.
  2. Although the S23-DRIVES statement may continue to function in current versions of Business Rules! (4.1+), it is no longer supported.


The Execute config specification causes BR! to execute a command upon startup. In the event a command is already provided in the startup icon, this statement will be ignored. This enables the automatic startup of applications under Windows client server and on the MAC (previously available only on Unix/Linux/AIX).

 EXECUTE "command"

Note that this statement, as well as any others can be conditioned on a specific login name by beginning the statement with:

 @login_name (followed by whitespace)

where login_name is the applicable login name.


Execute can also be used throughout a BR program to override most BRConfig.sys configurations, for example:

EXECUTE "config xxxxxx" 

See also Execute command.


Many editors are supported for BR! Source code.

The purpose of the EDITOR statement is to identify the program used by the EDIT command.

Editor "editor-program" [ REMOVE ] [NOWAIT]

While the Editor specification is normally placed within a BRCONFIG.SYS file, it can also be specified with the Config command or within a program line using the Execute statement to issue the Config command.


An Editor Statement could be typed in the command console like:

 Config Editor "C:\Program Files\NotePad++\NotePad++.exe"

Or added to BRConfig.sys like:

 Editor "C:\Program Files\NotePad++\NotePad++.exe"

Or perhaps added to BRConfig.sys, but only applicable to an individual user (Herbert) like:

@"Herbert" Editor "C:\Program Files\Mills Enterprise\MyEditBR\MyEditBR.exe"

REMOVE and NOWAIT affect the way the EDIT command uses the editor program. REMOVE causes BR to remove the source file when editing is complete.

See also

Known Third Party Editors

These editors can process .wbs/.brs Business Rules! Editable Source code.

Environment Variable Simulation

The ENV$ function, which is used to interrogate the BR environment, has been expanded to permit the simulation of setting an environment variable with configuration statements.

  CONFIG SETENV  SIZE  '10 x 24'

This allows a program to use ENV$("SIZE") to retrieve the value "10 x 24", (quotes excluded). In the event SIZE was previously defined in the environment it will *appear* as set to the new value for the duration of the BR session.

See SETENV for more details.


The FieldBreak Min_Spaces BRConfig.sys specification controls the automatic division of input fields into separate controls. If Min_Spaces is N, then N or more consecutive blanks denote a new subfield.

In BRConfig.sys:

FieldBreak Min_Spaces 2

From the command console:

Config FieldBreak Min_Spaces 2

Additionally UnderScore Off may be specified, i.e.:

Config FieldBreak Min_Spaces 2, UnderScore Off

Available in Business Rules! 4.16+.

It can also be used within a program line using the Execute statement.


For disambiguation purposes, see also the full screen processing section Field Help.

The FieldHelp config specification (available for use in the BRConfig.sys file and with the CONFIG command) identifies the text attributes and border type that are to be used whenever field help windows are specified in INPUT FIELDS, RINPUT FIELDS, INPUT SELECT and RINPUT SELECT statements.


Diagram Defaults

  1. N (Normal) attribute or retain previous setting.
  2. S (single-lined) border or retain previous setting.

Start-up Default



The "N=" keyword is used to identify the monochrome or color attributes which are to be used for text that appears in the field help window. It must be followed by the desired attributes. See Attributes for more information about the options and syntax for this parameter.

The "BORDER=" keyword must be followed by one of six border specifications. Four of these specifications have been pre-designed:

  1. "B" indicates that the border is to be blank (this works well when followed by the R (reverse) attribute);
  2. "D" indicates a double-line border (some terminals may not allow this, in which case a single-line border is displayed instead);
  3. "H" indicates that a shadowed or highlighted border should be used,
  4. "S" indicates that a single-lined border should be used.

The "corners" and "8 chars" border specifications can be used to custom design field help window borders. Business Rules accepts valid line drawing characters for each of these specifications (pressing Ctrl-\\ allows you to access graphics characters with the 0-9 and period (.) keys). To use the "corners" parameter, you must specify only the top left and bottom right graphics characters (in that order). To use the "8 chars" parameter, you must specify the characters to be used for all corners and all sides. However, as of 4.3, Border=H and "8 chars" are no longer supported except that a new OPTION 62 permits S, D, B, H or an eight character string followed by a colon and then attributes.

The "attributes" parameter may be specified immediately after the border specification (no spaces). The attributes specified here will affect the visual display of the border itself. See Attributes for more information about the options and syntax for this parameter.

Technical Considerations

  • The CONFIG command can be used to override the BRConfig.sys file's FIELDHELP specification.
  • The FIELDHELP specification is the only Business Rules instruction that can be used to specify the appearance of text and borders for field help windows. The N= and BORDER parameters that you may see in other Business Rules specifications (such as OPEN window, PRINT border, INPUT FIELDS, RINPUT FIELDS, INPUT SELECT and RINPUT SELECT) have no effect on field help windows; instead, they affect windows which are opened as separate files.
  • Although abbreviations should not be used with the BRConfig.sys file, the FIELDHELP keyword may be abbreviated to FI when it is specified with the CONFIG command.
  • See Terminal Considerations for special considerations for Unix / Linux terminals when using field help windows.
  • It is important to understand that field help windows are separate from windows that are opened with the OPEN window statement. The FIELDHELP specification affects the border type and attributes of field help windows only.


The FileNames BRConfig.sys specification controls the appearance of newly created files. It can also be used with the Config command or within a program line using the Execute statement.


Mixed case uses the NAME= string unmodified, and permits searching only on Unix when no case sensitive match is found. Other platforms ignore the SEARCH keyword.

Long Filename Support

Version 3.9 supports long filenames with a variety of alternatives with respect to case sensitivity. Unix defaults to case sensitive, and Windows defaults to case insensitive. Business Rules! defaults to lower case on all platforms, unless overridden by a FILENAMES configuration statement.

Specify FILENAMES LOWER_CASE when running both Windows standard model and Linux/Unix client server at the same time. This will align file naming between the two platforms with maximum processing speed.


The FlowStack Config specification allows you to change the size of the flow stack, which is the memory area that holds return information for the GoSub statement and user-defined functions.


Start-up Default

FLOWSTACK 100 (version 4.3+)


"Integer" is a decimal number that represents the number of calls the flow stack can hold. This number must be greater than 9.

Technical Considerations

  1. FlowStack may only be specified in the BRConfig.sys file; it is not valid with the Config command.
  2. An error message (9003) appears when the flow stack is too small to handle the number of concurrently active GoSubs or functions.
  3. The flow stack memory area is taken from available user memory.
  4. The Status Stacks command shows the current stack settings.


The Font parameter for BRConfig.sys is supported:

FONT fontname 3DFONT=fontname

This supports two fonts simultaneously, one for background and captions and one font for input fields.

Multiple fonts are now supported under Windows. The default is still SYSTEMPC. Any installed non-proportional font is permitted that is named in the following BRCONFIG.SYS statement:

Version 3.9+ supports the command STATUS FONTS. This will report all currently installed Windows fonts that are acceptable in a FONT statement. Fonts can also be changed dynamically via the CONFIG command.

Version 4.1+ allows specific proportional or non-proportional fonts for text, labels and buttons

BRCONFIG.SYS statement


Where the options are arial: modern: slant: width+ (etc.)

The above settings are used initially and as OPEN #0 font defaults. When a child window is opened it inherits the parent windows font settings. Window #0 inherits the OPENDFLT font settings each time it is opened. When typeface or family is specified in an Open statement, boldness, style and underline revert to these defaults unless they are also specified in the Open statement.

Size specifications do not revert to default values as a result of opening a window. They must be explicitly specified in order to change them. This is to allow users to resize their displays and still retain those settings.

Individual controls inherit the font settings of the window the same way windows inherit settings.

FONT can also be used with the config command or from within a program using the execute statement.

See also Fonts.



If FORCE VISIBILITY is ON, then, upon opening a new child window, this causes labels, text boxes, and buttons that underlay the new window to be copied to this new window. Underlying portions of fields on the parent window that span across child window boundaries also get copied to the child window. This simulates the way the old BR console works with see-through windows.

References to controls that begin in the portion of the parent window that is covered by the child window are converted to corresponding addresses on the child window.

Before running the following example, type CONFIG FORCE VISIBILITY ON from command line. In this example, a picture, a label, a button, and a textbox are printed to the graphical console. When a child window is opened, the label, the button, and the textbox are copied from the parent window to the child window. The picture does not get copied.

The name of this example is: FORCE_V.BR

00100    PRINT FIELDS "5,3,P 3/5": "Matrix.ico"
00200    PRINT FIELDS "2,3,C 5": "ABCDE"
00300    PRINT FIELDS "3,3,C 6,,B20": "WXYZ"
00400    INPUT FIELDS "4,3,C 4": VAR$
00500    OPEN #1: "srow=2,scol=2,rows=10,cols=15,border=S,parent=0",display,outin
00600    INPUT #1, FIELDS "8,1,C 4": VAR$

Also, try running this program with VISIBILITY OFF.


CLOSE FREE clears the underlying parent area and copies the child window controls to the parent window.

In this example, a picture, a label, a button, and a textbox are printed to a child window of the graphical console. The child window is then closed using CLOSE FREE. As a result, the label, the button, and the textbox are copied from the child window to the parent window. The picture does not get copied.

The name of this example is: CLOSFREE.BR

00100 OPEN #1: "srow=2,scol=2,erow=10,ecol=15,border=S,parent=0",display,outin
00200 PRINT #1, FIELDS "1,1,P 3/5": "Matrix.ico"
00300 PRINT #1, FIELDS "4,1,C 5": "ABCDE"
00400 PRINT #1, FIELDS "5,1,C 6,,B20": "WXYZ"
00500 INPUT #1, FIELDS "6,1,C 4": VAR$
00600 CLOSE #1, FREE:
00700 KSTAT$(1)

Note that FORCE VISIBILITY has no effect on GUI controls (such as GRID and LIST). Only labels, text, and buttons are processed by FORCE VISIBILITY. This feature accommodates certain old BR window behaviors in existing programs. It should not be used for new development.


The ForStack config specification changes the size of the For/Next stack, which keeps track of each different variable incremented in a program's For/Next loops.

Comments and Examples

The For/Next stack counts loop variables by name, regardless of how many times they are used in a program. Thus, if I is used as a loop variable (FOR I = 1 TO...) once in a program, it takes up one For/Next stack variable. But if I is used twenty times as a loop variable, it still takes up just one For/Next stack variable.


Start-up Default

FORSTACK 100 (version 4.3+)


"Integer" is a decimal number that represents the number of variables the For/Next stack should hold. This number must be greater than 4.

Technical Considerations

  1. ForStack may be specified only in BRConfig.sys; it is not valid with the config command.
  2. An error message (error code 9004) appears when a program uses more than the allotted number of For/Next variables.
  3. The flow stack memory area is taken from available user memory.
  4. The Status Stacks command shows the current stack settings.

Graphic Image Cache (Client Server Only)

The caching of Picture images on the client is available. Whenever a picture is sent to a BR client the image is saved on the client along with its filename. If another reference is made to the same image (while caching is on), the cached image is used instead of re-forwarding the image to the client. A config statement can turn caching off or on:


The default is CACHE_ON

This setting may be overridden on a case by case basis by specifying CACHE_ON or CACHE_OFF following the image filename, for example:

00100 MYIMAGE$="mugshot.jpg,CACHE_OFF"  to temporarily override cache default


00200 PRINT FIELDS "1,10,P 3/7,, 20" : "mugshot.jpg,CACHE_OFF"    ! temporarily overrides cache default



The Graphic_LineDraw BRConfig.sys specification controls the appearance of borders around windows.

A Problem

Older programs often used GRAPHIC_LINEDRAW and ASCII linedraw characters to create borders. However, if these programs are run in updated versions of BR with CONFIG GUI OFF and a wide screen, the characters appear as dashes instead of smooth lines.

Instead of this: (which can be re-captured by resizing the screen to the "right" size)

The Solution

To solve this, continue to run the program with CONFIG GUI OFF, and download the following image files to solve the problem: DRAWLINE.BMP and/or DRAWSUNK.BMP from the WinUtil file of the ftp site. These files should be placed in the BR executable folder or, if running in client server mode in version 4.1 or 4.2, in the client executable folder. Version 4.3 accesses these files on the server in all configurations.



The following linedraw modes are supported with GUI ON:

CONFIG GRAPHIC_LINEDRAW THIN        (Default BR thin line sunken)

The following linedraw modes are supported with GUI OFF:

RAISED is the default with GUI OFF.

THIN or THINSUNK (with GUI ON) indents line draw characters giving a bit more conservative appearance.

Lines are drawn on a window by using PRINT FIELDS and linedraw characters. Linedraw characters are generated via the numeric keypad using the numbers 0-9 and . when you are in linedraw mode. To toggle linedraw mode on and off, press Ctrl backslash (CTRL \). See diagram for clarification:

Custom linedraw sets may be used by modifying the bitmaps DRAWLINE.BMP and DRAWSUNK.BMP.

This feature is supported by the CONFIG command and becomes effective upon the next OPEN of window #0. Using EXECUTE allows you to set it from within the program.

It is also possible to use these commands within a Screen Paint program to design your screens. A Screen Paint program would be based on a Rinput Fields map of the screen.


Below is a sample program for printing these borders:

Remember to press CTRL\ to type in the linedraw images.


The HelpDflt BRConfig.sys specification indicates the help topic keyword and file names that are to be referenced whenever Ctrl-Y is pressed during program processing. It also establishes the default file name for the HELP$ function.

Comments and Examples

The HELPDFLT specification takes effect only when a program is running. The indicated topic keyword and file names are accessed when the <HELP> key is pressed during RUN mode. The file name specified is also accessed when <HELP> is pressed during INPUT mode, unless the programmer has overridden the default file name in HELP$.



"Keyword" is the topic name that has been assigned to the menu or text that is to appear when Ctrl-Y is pressed.
"Filename" is the name of the help text file within which the keyword can be found.

Start-up Default

There is no default file name established for help when a program is running. The file name parameter becomes required in the HELP$ function. Pressing the <HELP> key (except during INPUT mode) will have no effect on a running program because ON HELP SYSTEM operates as ON HELP IGNORE.

Technical Considerations

The CONFIG command can be used during program execution to override the BRConfig.sys file's HELPDFLT specification.

The HELP file search now uses the following directory sequence
- Current Directory
- Base Node of First Drive Statement (where second param points)
- BR Starting Directory Note that the HELPDFLT statement refers to filename not dirname.


The Icon environmental variable can be set during the execution of a program by use of SetEnv.

When the special Icon environmental variable is set it will change the icon which the business rules! application displays.

SetEnv("Icon","myicon.ico") sets the icon for the window and the taskbar to the icon specified by the second parameter (e.g. myicon).

00100 SetEnv('Icon','Myicon.ico')


The Include BRConfig.sys specification may be used to specify the name of a file that contains additional BRConfig.sys information. The syntax is as follows:

Filename is a standard BR (drive qualified) filename. If a full path is specified and the INCLUDE statement occurs before a relevant DRIVE statement, use an OS filename by preceding the full name with a colon.

An unlimited number of INCLUDE specifications may be used in the BRConfig.sys file and its related INCLUDE files. INCLUDE specifications may be nested up to 10 levels deep.

INCLUDE may be used in conjunction with the BRConfig.sys environment variable call to specify different configuration files for each user. For example, after all the common BRConfig.sys specifications, specify the following:

INCLUDE %USER%  ! include printer statements file according to USER

You can then set up different printer files for each user. Just be sure to set the variable USER to the desired filename (at the operating system level) before starting Business Rules!.

BRconfig.sys INCLUDE statements are relative to the location of the file containing the INCLUDE statement (the parent). CONFIG command INCLUDE statements are relative to the current directory at the time the command is issued.

This is not available in BR 3.9 and before.



The Keyboard BRConfig.sys specification instructs the system to generate a sequence of key actions each time a particular key is pressed. The ESC key may also be remapped with the Keyboard specification.

Keyboard can also be set using the Config command, or from within the program using the execute statement.

Comments and Examples

The Keyboard specification allows you to customize the keyboard to your needs. A four-digit keyboard scancode/character value ("aaaa," "bbbb," etc.) represents each key. Pressing the key represented by "aaaa" generates the sequence indicated as "bbbbccccdddd..."

For example, if the following Keyboard specification is included in BRConfig.sys, pressing the F7 key will generate the seven letters REPLACE:

KEYBOARD 0700,005200450050004C004100430045

You can also add Enter on the end by adding 000D; this eight letter version allows you to execute the REPLACE command with a single keystroke. This same technique (keyboard macros) can be used for any frequently used command.

Here are a few of the Scan codes (for a complete list see Scancode ):

Key Scan Code
Tab 09
Shift+Tab 07
Down Arrow 0A
Up Arrow 0B
Left Arrow 0E
Right Arrow 0C
F7 0700
Shift+F7 1100
Alt+Down Arrow E300


Start-up Default

Use no keyboard translations.


"Scancode" is a four-digit keyboard character value which represents the key to be pressed. When the key represented by the first scan code in the diagram is pressed, Business Rules! simulates the pressing of all the keys indicated by the second set of scancodes.

Technical Considerations

1.) You can use as many KEYBOARD specifications as you wish in the BRConfig.sys file.
2.) KEYBOARD specifications are portable because they use a set of scancodes from within Business Rules.

To determine the Business Rules standardized scan codes, run the following program:

00010 LET X$=KSTAT$(1)
00020 PRINT UNHEX$(X$)
00030 GOTO 10

Each time you press a key, the scancode for that key is displayed. This program can be used to find the keyboard scan code for every key or key combination except CTRL-A, since pressing CTRL-A pauses the execution of the program.

If you want to remap CTRL-A, the scan code for CTRL-A is 01.

KEYBOARD statements may now be executed by the CONFIG command to accomplish dynamic keyboard remapping. Also the keyword CLEAR may be used to remove specific or all previous specifications.

CONFIG KEYBOARD CLEAR		clears all prior keyboard statements
CONFIG KEYBOARD 0100 CLEAR	clears the definition for scancode 0100

This significantly enhances the capabilities of BR. For example, you can temporarily make a program uninterruptable.

Also, scancodes that were previously required to be four hex digits long no longer require leading zeroes, for example:

CON KEY  0A 6A756D70   ! ^J -> "jump"

Note that CONFIG abbreviations are allowed in commands, but not in actual BRCONFIG.SYS file statements.


As of 4.3, the debug versions of BR now expect you to use a LOGGING configuration statement. This enables BR to post exit messages during unexpected terminations.

The Logging config statement is provided for logging configuration errors, and should be placed in BRConfig.sys:

LOGGING <loglevel>, <native-OS-logfile-name> [, UNATTENDED] [, DEBUG_LOG_LEVEL=<integer>] [, +CONSOLE]

Loglevel is the maximum level of detail to be logged. The Logging Level is meant to specify the level of detail to be logged, with greater detail logged at higher log levels:

0 MAJOR_ERROR causes major problems during execution
1 NOTABLE_ERROR unexpected error likely to cause problems

System generated warning messages such as OS failures and abnormal exits.

2 MINOR_ERROR unexpected error that can be ignored

System generated warning messages such as OS failures and abnormal exits.

3 MAJOR_EVENT starting program, exiting, shelling ...

System generated warning messages such as OS failures and abnormal exits.

4 SECURITY_EVENT logons, logon attempts etc
5 MINOR_EVENT individual commands ...

User Logon data, including any attempts.

6 Starting a BR program, exiting.
8 Commands such as COPY plus shell calls with parameters.
9 DEBUGGING_EVENT added for debugging purposes
11 Any PRINT output that goes to the console is also logged (GUI ON only).
12 TRACE, and DISPLAY messages.
13 Lots of what the system is doing now messages.

Logfile denotes where the logging records will be kept. Note that Logfile is a native OS filename. Second and subsequent occurrences of the LOGGING statement may omit loglevel and logfile.

The UNATTENDED keyword will cause BR to run in unattended mode, without a startup screen and until a program begins to await operator input, when it will exit. Config LOGGING loglevel logfile [UNATTENDED] is now supported on linux (4.2) and this will exit BR if the program starts to wait for keyboard entry.

DEBUG_LOG_LEVEL (available as of 4.3) specifies the log level for debugging log messages independently of the standard log level. If not specified, the Debug_Log_Level is set to the standard loglevel.

+CONSOLE (4.3) applies only when GUI is ON and specifies that all logging messages also go to the console and the console is to be left visible when not attached to MyEditBR. (Console logging output is supressed when GUI is OFF.)


LOGGING 2, logfile

shows unsupported escape sequences encountered.

LOGGING 5, logfile

shows unsupported escape sequences encountered plus intentionally ignored escape sequences.


shows unsupported escape sequences encountered, and runs BR in 'Unattended' mode, bypassing start-up screen and terminating BR at the end of processing or when input is required. Supported in 4.18 in Windows and 4.20 under Linux.


runs in Unattended mode without log file.

Any config messages that occur after this config statement will be sent only to the logfile, mostly with NOTABLE_ERROR. It avoids displaying those REMed out statements in front of operators.

Any config messages that occur before the config statement logging will be sent only to the screen. These will cause BR to pause a few seconds so that the messages can be viewed.

Logging Messages (4.3)

Message Levels are compared with Log Levels during the filtering process. Like log levels, there is greater detail logged at higher log levels:

The following types of messages are written to the LOGGING file:

1. Config error messages based on their assigned level of importance.

2. DEBUG_STR() messages where message-level is equal to or less than the DEBUG_LOG_LEVEL:

Log levels 0, 1, 2 and 3 System generated warning messages such as OS failures and abnormal exits.
Log level 5 or above User Logon data, including any logon attempts.
Log level 6 or above Starting a BR program, exiting.

Any DEBUG_STR() calls with a level >10 are deemed to be message level 10.

Commands such as COPY plus shell calls with parameters are logged with system generated warning messages such as OS failures and abnormal exits.

LOGGING PDF printing events

Logging was added to PDF creation. Logging of minor events that happen during the printing process are logged at log level 8. Errors are logged at a lower level. Logging was also improved with respect to loading older versions of pdflib. Note- As a diagnostic, the following command is quite useful: DIR >PDF:/READER

The following messages are written to the LOGFILE:

Log level 11 or above Any PRINT output that goes to the console is also logged (GUI ON only).
Log level 12 or above TRACE, and DISPLAY messages.
Log level 13 or above Lots of what the system is doing now messages.

Log Level Indication is given in Log Messages The (6) here is the log level:

 (6) - 08/25/2011 11:33:53

Setting logging to log file logfile.txt log level 10.

 (6) - 08/25/2011 11:33:53

The BRConfig.sys file is C:\Users\dan\programs\cygwin\home\dan\br-wx\br\winbuild\dllbuild\output\brconfig.sys

See Also

Logging Abnormal Termination

A logging capability is provided for handling BRServer failures. An error log file in the BRServer directory is appended to when a BRServer process is abnormally ended. Also, a client msgbox is displayed when an assertion failure or program crash occurs. On Unix systems, the system error log is also updated. Keepalive failures are also logged here.



Login Name$ can refer to the CONFIG parameter or the internal function:


The Login_Name$ BRConfig.sys specification may be substituted during BRConfig.sys statement interpretation. Specify LOGIN_NAME$ (case insensitive) anywhere in a BRConfig.sys statement to have the user's name appear in the statement. For example:


Defines drive G: as the user's home directory.

You can also SET the LOGIN_NAME$ with LOGIN_NAME$("newname").

Internal Function

The Login_Name$ internal function contains the operating system user login name. This can also be set with LOGIN_NAME$("newname").

The priority of the LOGIN_NAME variable setting is:

1) BR startup command parameter (@name)
2) Workstation operating System user login name
3) BRCONFIG.SYS "LOGIN_NAME name" statement

These alternatives support the assignment of login name in all models. This can significantly simplify the tailoring of BRCONFIG.SYS files through use of the @name statement prefix. Instead of having to place a separate BRCONFIG.SYS file on each client system, the client's could specify the login name of the user, and a common BRCONFIG.SYS file could contain the custom statements for all users, beginning the custom statements with @name for each login name. For example:

BR  @myname  run menu

BRCONFIG.SYS includes:

@myname WSID 25

@UserName in the BR startup command may also be used to override the windows environmental variable UserName in the Login_Name$ internal function.


You can conditionally execute any statements in your BRconfig.sys based on the windows/linux login of the user running BR by preceeding the line with @login_name.

@myname run menu
@lgomez WSID 25

This can significantly simplify the tailoring of BRCONFIG.SYS files through use of the @name statement prefix. Instead of having to place a separate BRCONFIG.SYS file on each client system, the clients could specify the login name of the user, and a common BRCONFIG.SYS file could contain the custom statements for all users, beginning the custom statements with @name for each login name.

If the windows login name contains spaces or periods, you must encapsulate it in quotes

@"Joe Tester"  WSID 11


The MaxRecall BRConfig.sys specification defines the number of commands that Business Rules! should remember for subsequent recall with the F2 key.

Comments and Examples

Pressing the F2 key while Business Rules! is in READY mode causes the most recently executed command to be displayed on the screen. Pressing F2 again causes the second most recent command to be displayed, and so on. The MaxRecall specification sets a limit on the number of commands that Business Rules! will recall before it re-displays the most recent command. Pressing F3 always recalls the most recently executed command; it also resets the pointer used by the F2 key.



"Integer" is a one or two-digit number from 1 to 300.

Start-up Default

MaxRecall 200

Technical Considerations

The Config command can be used during program execution to override the BRConfig.sys file's MaxRecall specification.

Max_Sort_Memory nn MB

Max_Sort_Memory sets the maximum amount of work memory used for sorting and indexing. This prevents long sorting operations from dominating a workstation's memory.

Non-GUI mode (4.15+)

Non-GUI mode ignores GUI statements when they are encountered as of 4.15.




See also Option (disambiguation).

These are some of the Options you can use in the BRConfig.sys file. Most may also be enabled by use of a Config Option statement. Most can be disabled with a Config Option [number] Off statement.

These can be used within a BR program, for example:

00010 Execute "Config Option 1"

Or can be set at the time of BR32.exe launch by a line being placed in BRConfig.sys like:

Option 37

Option Description Supports
Config Option X Off
INVP Normal input of commas and periods is interchanged in PIC, N, NZ, L, G and GZ format specifications to support European- style numbers. (From INPUT FIELDS)
1 FORM A*C 10, default to 1 if A<1 Yes (4.18+)
2 keyboard values less than 0x20 not ignored Yes (4.18+)
3 set print flags
4 pads to record length for display out if EOL=NONE Yes (4.18+)
5 default to ISAM (index type 4). The normal default is BTREE (index type 7)
6 keep path=0 defaults to change to path when exiting BR same as when entered, as in UNIX
7 use old style syntax checking of IF statements Yes (4.18+)
8 use old style loop counter for keyboard - 2nd Option on break
11 don't clear unreferenced variable Yes (4.18+)
13 sets the number of milli-seconds for scancodes wait e.g Option 13 200 (this number can be incremented by 20 till it reaches 400)
14 allow multiple locks on same record from duplicate opens, for same file opened twice at same station Yes (4.18+)
15 suppress indentation of comment continuation Yes (4.18+)
16 omit display of loaded file name Yes (4.18+)
17 don't consolidate 4205 error codes Yes (4.18+)
18 BR ignores any century value - where century is omitted from the date Yes (4.18+)
19 subtract one from dates after 2/2000 for SCO pre version 5
21 make date$(0) yield 12/31/1899 Yes (4.18+)
22 The system will automatically create new indexes in BTREE2 format and will keep track of which files utilize BTREE2 indexes. It will audit and if needed rebuild
23 make IOERRs not move file pointer forward to next record. BR will advance the record pointer when a successful read I/O operation occurs, even when a CONV (conversion) error takes place during the read operation. This Option lets the IOERR exit condition occur only when the record pointer is not advanced Yes (4.18+)
24 disable X attributes during SELECT. Prior to BR version 3.9, this Option had a different meaning. Originally, Option 24 specified that a file should be freed and recreated when opened REPLACE to avoid a NOVELL failure to truncate the file. But BR *now* automatically truncates. If it can't for some reason, THEN it will remove the file and recreate it. Effective with BR 3.9+, Option 24 suppresses the recognition of the "X" attribute during INPUT SELECT operations. BR versions prior to 3.9 operated this way by default - without the Option - even though the documentation indicated that X applies to SELECT operations. Yes (4.18+)
25 make file$(0) be CON: (if in Windows) Yes (4.18+)
26 suppresses the creation of .BAK files during Replace Yes (4.18+)
27 Ignore Invalid Y2K Key Data (err 4120) Yes (4.18+)
28 Force all CONFIG PRINTER statements to specify a printer. Yes (4.18+)
29 Save programs as .WB files. (Default is .BR) Yes (4.18+)
30 server side printing for client-server. Yes (4.18+)
31 suppress native windows printing; treat WIN:/ as direct printing Yes (4.18+)
32 Supress notification of error 6245, which indicates an invalid or unsupported (by BR) escape sequence has been printed during Native Windows Printing. Yes (4.18+)
33 ( 30 31 32 64 ) (default is 31) Record locking for large file support. The problem addressed by this Option was that BR doesn't actually lock records, but locks a byte corresponding to each record in a zone way beyond the actual file. The filespace doesn't really have to exist to allow locking. This permits ODBC and other report writers to access locked records. BR also uses this zone to arbitrate the types of Open allowed. With BR 3.9, some file sizes were growing into the zone, and records were being locked inadvertently.
  • Option 33 30 1GB maximum bytes in a data file.
  • Option 33 31 (The default 2GB limit)
  • Option 33 32 (4GB Limit)
  • Option 33 64 Turns on 64 bit locking
34 sends print screen images to PRN:/10 instead of PRN:/SELECT. Yes (4.18+)
35 Honor keepalive timeout (no longer available) Yes (4.18+)
36 Enables the cursor during INPUT SELECT This Option is needed for some hand held scanners that do not have the ability to display in reverse image. Yes (4.18+)
37 With versions 4.14+, BR returns: FKEY value of 116 when exiting a field with right arrow.

With OPTION 37 on BR returns an FKEY value of 104 which is the same as the down arrow. This (104) is how BR worked previously.

Yes (4.18+)
38 This suppresses an error caused by specification of an N in the trailing attribute position. This Option is provided only for legacy purposes. Yes (4.18+)
39 Suppresses the automatic right alignment of labels ending with a colon. Yes (4.18+)
40 Show hot text as buttons by default. Normally hot text does not appear as a button unless the fkey value is preceded with a B. This Option can be selectively overridden by preceding the fkey value with an H. Yes (4.18+)
41 Ignore GUI statements when they are encountered in non-GUI mode. Yes (4.18+)
42 Suppress automatic drive mapping during Windows shell calls. Yes (4.18+)
43 INPUT SELECT changes fields before returning control; use old style Input Select with respect to setting CURFLD to the NXTFLD value when a selection is made. Yes (4.18+)
44 Make the mouse wheel produce the same result as the arrow keys when control is returned to a program via the E, L or X field attributes. Without this Option, the mouse wheel returns Fkey results of 124/125 (up arrow/down arrow). With this Option it returns 102/104 during INPUT FIELDS and 105/106 during INPUT SELECT operations (normal arrow key responses). Note: Option 44 is NOT needed to use the mouse wheel. It only pertains to Fkey results with E, X or L. Yes (4.18+)
45 Allows the old method of extended field specification in addition to the new method. Yes (4.18+)
46 Normalizes numpad + and - keys. This removes Field Plus / Minus special processing, which is no longer needed with Datahilite field clearing. Yes (4.18+)
47 Enable the continued use of PRINTER= in OPEN statements. Yes (4.18+)
48 Note- OPTION 48 functionality was changed in version 4.2.

If OPTION 48 is not specified, ENTER will return an FKEY value of zero and a double-click will return any FKEY value assigned to the field. Use OPTION 48 only to have the ENTER key return any FKEY value assigned to the field.

Yes (4.2+)
49 Use relative path for spool file name passed in SPOOLCMD. Yes (4.18+)
50 Suppress theme usage for text controls. This enables the Windows classical look under XP. Yes (4.18+)
51 Reuse deleted records for all files. This is an old unpublished and untested Option for re-use deleted records during WRITE operations. Deleted records will be RE-USED, and then lost permanently. Yes (4.18+)
52 Enable the second click of a double click operation to produce its own interrupt with FKey value 201. Yes (4.18+)
53 Allow mouse positioning inside a field other than the current field. Without this Option clicking anywhere in a non-current active input field will process it as though the field were entered via the arrow keys. Yes (4.18+)
54 Exit BR! at any console command prompt with a message box showing program name and line number:clause. Waiting for input by a program has no affect.
55 Some fixed width fonts have characters that aren't exactly the same width as the other characters. This can present column alignment problems. This option slows down printing slightly, but positions each character individually instead of streaming the data to the printer and letting the the data self align. Yes (4.18+)
56 Srch return -1 instead of 0 when no match is found.
57 Clear Fkeys of inactive Q combo box fields. Yes (4.18+)
58 On FnKey has been disabled in 4.20+ (use On FKey instead), however this option restores recognition of FnKey . Yes (4.20+)
59 Make CurCol (not NxtCol) work the old way: use cursor position instead of field start for CURROW/COL ???
60 allows 4.2 to edit and save programs while maintaining 4.18 compatible formatting so that 4.18 can still run those programs. If this is used you may not utilize 4.2 features. NO
61 Do not Map a Drive if not explicitly defined by DRIVE statements BRConfig.sys
62 Use Draw Line Border Specification (Otherwise report error!).
63 Allow INPUT SELECT to input data; INPUT SELECT "Reads Data", We should use INPUT FIELDS W=with ^LABEL instead!
64 15 Allows max network delay for passing data to client.
65 Ignore ON ATTN statements.
66 The secret key to be used for encryption.
67 Data Hilite on every INPUT FIELDS statement.
68 Prevent stretching printed fonts. Yes
69 ignore file closing errors during end or chain Yes?
  • Same as Option 54 (exits on any command console prompt) but allows Relaxed parameter to allow for some debugging.
  • 4.32+ ON SOFLOW IGNORE overrides line error handlers as in previous versions
* Yes and Relaxed (4.30+)
71 Prevent auto complete for editable combo boxes (added in 4.32 ish) Yes?
72 Prevent auto complete for select combo boxes. (added in 4.32 ish) Yes?
73 Treat IGNORE as a label reference for line level error handlers Yes?
74 Adds the WSID to the temporary edit file names. (added in 4.3) Yes
97 set network retries per second (default is 5)
98 turn OFF check for all NULL in read / writes
99 turn ON check for all NULL in read / writes


See also: Printing, Error 0701

The PAGEOFLOW BRConfig.sys specification allows you to change the number of printable lines as used by the PAGEOFLOW error condition. If you are still using PAGEOFLOW for page overflow processing in report and listing programs, this option can be used to accommodate paper lengths other than 11 inches.


The "int" parameter is a whole number greater than 0 that identifies the number of lines to print before generating a PAGEOFLOW condition.

Start-up Default

If PAGEOFLOW is not included in the BRConfig.sys file, PAGEOFLOW automatically takes effect after 60 lines have been printed.



Technical Considerations

The CONFIG PAGEOFLOW command can be used during program execution to override the BRConfig.sys file's PAGEOFLOW setting.


The PrintDir configuration statement places a copy of all print files spooled by BR into the specified directory. When BR sends the file to the spooler, it makes a copy of the file using the main active program name with a suffix of the channel number (default is 255).



The +DATE, +TIME and +LOGIN_NAME pertain to the output base filename. The \LOGIN_NAME keyword inserts a directory name after directory-path. +CHANNEL replaces the filename suffix prt with the channel number of the Open statement used to create the report.

For example, a payroll program (PRREG) prints a register using the following open statement:

OPEN #40: "Name=PRN:/LASER2,Recl=133", DISPLAY, OUTPUT

BR stores a copy of the report in {pathname}\PRREG.40

This option is also available through the CONFIG command.

Optional Keywords

The PRINTDIR statement has the following optional keywords (as of 4.3):

( Note- each keyword is separate and must be separated from preceding specifications by one or more spaces. )

+DATE Adds the system date to the report filename.

+TIME Adds the system time to the report filename.

+LOGIN_NAME Adds the user’s login name to the filename.

+CHANNEL Adds the OPEN file number to the filename (previously the default file suffix).

RAW Stores the PRINTDIR file in an untranslated format. This permits subsequent printing of the output to a variety of destinations with corresponding printer translation specifications. (e.g. TYPE filename PRINTER_TYPE=NWP >display-file –or- TYPE filename >DIRECT:/HP where HP is a case sensitive Windows printer name substring )

\LOGIN_NAME Stores the file in a subdirectory to the specified directory-path which is named the same as the user’s login name.



Produces a display file:



Produces a display file:


which can subsequently be TYPEd using various printer definitions.


Also see the Printing section.

The Printer specification allows you to specify which printer to use. It translates hex character strings for the printer or for display files, allowing you to customize Business Rules! to a particular printer.

1.) Multiple PRINTER translations are supported by the BRConfig.sys file as of Business Rules! release 3.30. PRINTER translations may additionally be referenced through use of the PRINTER= parameter in the OPEN statement (see "OPEN display" in the Statements section for more information).

You can specify PRINTER specifications for up to nine named printers and one default printer in the same BRConfig.sys file. The full path name used to open the printer/display file must be specified after the word PRINTER and before the "2B...." specifications start. The keyword INIT can be used to specify the initialization string for each printer. This initialization string is sent to the printer/display file with every OPEN statement for that name. If no translation exists for a string for the named printer, the default translation for that string is used.

The keyword PRINTER= is allowed in the open string for display and printer files. This keyword names a printer translation that is used instead of the NAME= string for performing PRINTER string replacements. For example:

PRINTER INIT 1B57001B2D00      !default initialization
PRINTER 2B0045582B,1B5701      !default - expanded
PRINTER 2B0045582D,1B5700 	    !default - CANCEL EXPANDED
PRINTER C:\\BR\\PTEST INIT 1B2D00     !initializes the file ptest
PRINTER C:\\BR\\PTEST 2B00554C2B,1B2D01   !set underline mode for ptest
PRINTER C:\\BR\\PTEST 2B00554C2D,1B2D00  !cancel underline mode for ptest
2.) The PRINTER specification now provides a much easier to use and easier to read system of creating printer substitution tables. It allows translation tables to be specified for up to nine named printers and one default printer.

Comments and Examples

The PRINTER specification replaces all occurrences of the first hex character string with the second string. Both strings may be of varying lengths. Multiple PRINTER specifications are permitted.


The revised syntax (incorporating all enhancements since release 3.2 for the PRINTER spec is as follows. Business Rules! continues to support the old 2B... printer substitution sequence, but ADS recommends that you utilize the new system in all new development projects and update the old system as is convenient.

Diagram defaults

1.) For default printer.
2.) Do not reset value of LINESPP.
3.) Substitute to null (nothing).

Start-up Default

Ignore the 2B020500hhvvll sequence.


"Printer name" is the file name and path of the printer to which this PRINTER specification applies. The PRINTER spec will be activated whenever the specified printer name is opened with the PRINTER= parameter in an OPEN display statement. If PRINTER= is not used in the OPEN display statement but the NAME= string identifies a printer, Business Rules! will attempt to match the NAME= string to the printer name.

NOTE that all of the BRConfig.sys PRINTER specs together may specify no more than nine different printer names. A tenth set of PRINTER specs that lists no printer name may be specified as the default.

When the "printer name" parameter is not used, the PRINTER spec is assumed to apply to the default printer translation table. Business Rules! activates the default printer translation table whenever PRINTER= is not specified in the OPEN display statement and Business Rules! is unable to match the printer named in the OPEN display's NAME= string to a PRINTER specs "printer name."

The "INIT" keyword indicates that the succeeding "output string" should be sent whenever the specified printer is opened. For easiest reading of the BRConfig.sys file, Business Rules Corp recommends that the first PRINTER spec for each printer include the INIT string.

The "LPP ##" parameter sets the value of Business Rules! LINESPP function. ## has to be a number from 1 to 255. For more information about the usefulness of this parameter, see "LINESPP" in the Functions section.

The "substring" parameter is a PRINT string that Business Rules! should watch for and substitute with "output string" wherever it occurs. It must be enclosed within square brackets ([]) and followed by a comma when specified. This "substring" parameter is the key to the PRINTER specs easier-to-read format.

It would typically consist of an English-like term that identifies the printer code being sent. A few possible examples are: _E_G for turn bold on, __P for set characters per inch to 10, and [ITAL-] for turn italics off. The same string would be used in a Business Rules! PRINT statement when the desired printer feature is to be executed.

The "output string" parameter identifies the printer escape sequence that should be sent whenever the specified "substring" is included in a PRINT statement. Business Rules! allows any combination of hex codes, octal codes and literal strings (in quotes) for the "output string" parameter. The requirements for specifying the "output string" are:

1.) Hexadecimal codes are specified without quotation marks. The letters A through F may be in uppercase or lowercase. Any combination of tabs, new lines, spaces and commas may be used to increase readability and will be ignored, unless they appear inside quotation marks (in which case they will be assumed to be literals). See Appendix H for a complete list of hex codes.
2.) Octal codes must be specified as part of a literal string. See "Literal strings" below for more information.
3.) Literal strings must appear within quotation marks, and may include octal codes when specified in the format shown below. See Appendix H for a complete list of octal codes.

The following formats or characters, when used in a literal string, have the specified meanings:

\\### Octal value (backslash followed by three digits)
\\b Backspace
\\E or \\e Escape; same as CHR$(27) or octal \\033
\\f Form feed
\\l Line feed
\\n Newline
\\r Return
\\t Tab
^x Control-x (x may be any character)
\\^ Caret (^)
\\~ Tilde (~)
\\: Colon (:)
\\ Backslash (\\); same as CHR$(92)
\\" Double quote mark ("); same as CHR$(34)


"LPP 48" in the following PRINTER spec causes Business Rules! LINESPP function to be set to 48. "[LPP 48]" is a PRINT string that should be substituted with the "\\Ep48" escape sequence whenever it is used. "\\Ep48" is the escape sequence that causes the specified printer (in this case the default printer) to set lines per page to 48.

PRINTER LPP 48 [LPP 48],"\\Ep48"

A Business Rules! statement that would activate the above PRINTER spec is as follows:

PRINT #255:"[LPP 48]" ! set page length to 48 lines

The following example uses an output string that includes both a hex code and a literal string:


The first character in the "from hex string" must be 2Bh, which is the ASCII code for the "+" character; the second character must be less than 20h or greater than D0h.
All occurrences of the "from hex string" will be replaced with the "to hex string."
The "EPSON" parameter supports the System/23 2B020500hhvvll translation for Epson printers. You may want to try this specification before any other, as it handles the translation for any printer with an Epson-compatible prom.

The "IBM23" parameter supports the System/23 2B020500hhvvll translation for the IBM System/23 Datamaster printer. Use of this printer with a PC requires the use of a separate hardware/software product, PC23-Print.

The "IBMCOLOR," "OKIDATA," and "OKIDATA84" parameters support the System/23 2B020500hhvvll translation for IBM Color, OKIDATA and OKIDATA 84 printers.

Technical Considerations

1.) PRINTER may be specified only in the BRConfig.sys file; it is not valid with CONFIG.
2.) A useful general definition of the PRINTER specification is as follows:

This specification, by instructing the system to ignore the "+" in all sequences beginning with "+ Esc", allows your program to support different printers without code changes.

3.) If you write a program that specifies custom printer escape sequences, you can later change those escape sequences with the PRINTER specification -as long as the "+" character begins the program sequence and as long as the second character is less than 20h or greater than D0h.

Printer Initialization

The maximum length of printer initialization strings has been expanded from 32 bytes to 64 bytes.


Also see PRINTING and Category:Printing

The PrintScreen config option specifies how output to the printer and/or to a substitute file for PRN:/10 should be handled when Ctrl-P is pressed.

You can direct where ctrl-P printscreen images will print


"GUI" will print from the GUI console. If the config statement PRINTSCREEN GUI is specified in conjunction with a Windows printer (WIN:/printer or PREVIEW:/...) the printscreen will be graphical. PRINTSCREEN GUI defaults to WIN:/SELECT, so it is not necessary to specify the PrintScreen device. Including "OFF" after "GUI" will print from the BR command console.

"REPLACE" affects output only when a file substitute is specified for PRN:/10. In this event, REPLACE causes the previously existing file to be replaced each time Ctrl-P is pressed.

"APPEND" affects output only when a file substitute is specified for PRN:/10. In this event, APPEND causes new printscreen data to be appended to the previously existing file. Prior to the existence of the BRConfig.sys PRINTSCREEN specification, Business Rules! handled all Ctrl-P output to a substitute file for PRN:/10 as if PRINTSCREEN APPEND had been specified (this option continues to be the default).

"NEWPAGE" affects all Ctrl-P output, whether or not a file substitute is specified for PRN:/10. It causes a form feed to be output after each Ctrl-P.

"NEWPAGE-OFF" affects all Ctrl-P output, whether or not a file substitute is specified for PRN:/10. It prevents a form feed from being output after each Ctrl-P. This option is used as the default when no NEWPAGE option is specified.

"Printer-spec" can be replaced by one of the following, where "Printer-name-substr" refers to a case sensitive substring of an actual Windows printer name:

  • PRN:/printer-name-substr
  • WIN:/printer=name-substr
  • DIRECT/printer-name-substr
  • PREVIEW:/printer-name-substr


1.) If a file substitute is specified for PRN:/10, APPEND is the default (this is the same default as previous versions of Business Rules! used). If no file substitute is specified for PRN:/10, this option is not applicable.
2.) NEWPAGE-OFF. (This default applies regardless of whether or not a file substitute is specified for PRN:/10.)
3.) The keyword SELECT may be used in lieu of an actual printer name to let the operator select the printer.

Comments and Examples

In the following example, a SUBSTITUTE specification is used to send all PRN:/10 output (including Ctrl-P) to the file PRNFILE. The PRINTSCREEN specification then indicates that each output to the file via Ctrl-P should be followed with a form feed. As neither REPLACE nor APPEND is specified, Business Rules! will automatically append all Ctrl-P output to PRNFILE.


Assuming that the above BRConfig.sys specifications were active, the following CONFIG SUBSTITUTE command would clear the file substitution for PRN:/10 and cause all output to this device name to return to the printer. Since PRINTSCREEN NEWPAGE remains active at this point, each Ctrl-P output would continue to be followed with a form feed:


The following CONFIG PRINTSCREEN command halts the output of a form feed after each pressing of Ctrl-P:



The RD BRconfig.sys specification sets the tolerance level for assuming two values are equal. The value of the RD specification affects operation of the AIDX, DIDX, INT X, IP X and STR$ Internal Functions, the SORT utility's RECORD specification, numeric comparisons used in IF and FOR statements, and the printing of a number in default format (PRINT X).

(Not available in BR! Version 4.03jx or before)

Comments and Examples

Business Rules floating point numbers are precise up to the first 15 digits, whether the digits occur before or after the decimal point. The value of the RD specification indicates how many decimal digits should be considered meaningful in numeric comparisons. And when formatting a numeric value for output it rounds at the RD position. It has no effect on internal mathematical processing.

For most applications, the RD default should be used. The RD specification is only needed when the data includes very large numbers (100 million or greater) or very small numbers (less than .00001).

If changing the RD value is necessary, it is important that you change it properly. Using an RD value that is too high could cause unpredictable and invalid results. Using an RD value that is too low could cause Business Rules to overlook a significant difference between two numbers.

The best way to determine the appropriate setting for your needs is to find the largest number, with the most number of decimal positions, that your application will be using in numeric comparisons (remember, RD has no effect on actual math performed internally). Starting from the left-most digit of the number, you should then count 15 digits to the right and draw a line after that digit. (If there are less than 15 digits in your number, draw a line after the last digit.) Now, count the number of digits between the decimal point and your line. Subtract at least one, but preferably two. The number you end up with is the RD setting you should specify.

For example, assume that the following number is the largest that would be used in numeric comparisons for a particular application.


Counting from the left-most digit, 15 digits over would bring you to the 5, after which you should draw a line:


The number of digits between the decimal point and the line is 6. Subtract two from that and the result is 4, which would be the appropriate value for your system. What this accomplishes is to discard the rightmost two digits of precision for comparison and display purposes. So even though BR uses an internal precision of 15, for situations where many additions and/or subtractions are performed this effectively drops the precision back to 13 significant digits.

To understand the significance of the RD specification, it is important to understand that adding or subtracting a number with other numbers many times has a predictable loss of precision. (Any language that uses binary floating point numbers will lose precision in this manner.)

A "worst case" illustration of the loss of precision that can occur would be if a very large number (99,000,000) were repeatedly added to a very small number (.01). As the following table shows, this process would have to occur 94 times before it would affect IF comparisons when the RD value is set to 6. When the RD value is set to 5, the same process would have to occur 932 times before it would affect IF comparisons.

RD Loop Count Variance
6 94 0.00000051
5 932 0.00000501
4 9321 0.00005001
3 over 10001

While the above worst case is an unlikely occurrence with real data, it does highlight the potential for problems if more than 1000 numbers are added or subtracted and the resulting figure is in the 100 million or larger range. Note that the difference in a number printed on a report is still at least 1000 times too small to show up as a penny rounding error.

In contrast to the worst case, a more "typical case" illustration could add a very large number (99,000,000) to a randomly selected small number between .01 and .99. When RD is set to 6, it would take 1930 computations of this type to cause a rounding error. With an RD of 5, it would take more than 10,000 such computations to cause a rounding error:

RD Loop Count Variance
6 1930 -0.00000051
5 over 10001

The following table shows the various levels of addition/subtraction precision supported by RD settings:

RD Precision # Digits Precision
RD 12 1.12 #.############
RD 11 2.11 ##.###########
RD 10 3.10 ###.##########
RD 9 4.9 #,###.#########
RD 8 5.8 ##,###.########
RD 7 6.7 ###,###.#######
RD 6 7.6 #,###,###.######
RD 5 8.5 ##,###,###.#####
RD 4 9.4 ###,###,###.####
RD 3 10.3 #,###,###,###.###
RD 2 11.2 ##,###,###,###.##

  • The default value of 6 will allow a value of 999,999,999.999999 to be output, input and displayed. But if you were to add a large quantity of numbers in the 100,000,000 range that also had fractional amounts, you could get an inaccuracy at the fifth and sixth decimal positions.



"Integer" is a number from zero to fifteen that represents the number of decimal places to be used in numeric comparisons.

Start-up Default

RD 6

Technical Considerations

1.) The CONFIG command can be used during program execution to override the BRConfig.sys file's RD specification.
2.) Using RD values larger than 8 will most likely result in unexpected rounding as RD 8 only support values up to 9 million.
3.) When numbers larger than 99,999,999.99 are used in comparisons, the RD value should be set to three or four.
4.) In special situations where changing the RD value is not desirable, the ROUND function may be used to stop rounding errors from accumulating. See Functions for more information.
5.) The RD specification affects the STR$ function since the number of significant decimals is not specified by STR$. If the number to be converted is large and the number is the result of many computations, one of the following two techniques should be used to truncate the number and accomplish the required results instead. The CNVRT$ function may be used with a PIC format or N specification or the STR$ function may be used in conjunction with the ROUND function. The following examples show each of these techniques:
CNVRT$("N 15.2",NBR)
6.) If it is undesirable to do any rounding of a number, either with the RD specification or with the ROUND function, the next best way to get an accurate comparison is to subtract potentially large numbers that are the result of many calculations and compare the result. By using IF A-B>=.01 instead of IF A>B, the desired variance is specifically tested for.
7.) A useful program for experimenting with extreme numeric values is;
00010    INPUT FIELDS "5,10,L 20,u": num_var
00020    PRINT FIELDS "7,10,L 20": num_var


{{::Rem (config)}}


The RpnStack config specification changes the size of the RPN stack, which holds the locations of each active variable in the current statement and the locations of statements suspended by a user-defined function call.


Start-up Default

RpnStack 1000 (version 4.3+)


"Integer" is a decimal number representing the number of variables that the RPN stack can hold. It must be greater than 49; the default is 200 variables.

Technical Considerations

  1. RpnStack may be specified only in the BRConfig.sys file; it is not valid with Config.
  2. An error message (error code 9002) appears when an RPN stack is too small for the program in use.
  3. The amount of RPN stack memory available depends on the depth of function calls and complexity of expressions. Normally the RPN stack is cleared at the completion of each statement. However, stacked entries are suspended on the RPN stack when a function call is made.
  4. The Status Stacks command shows the current stack settings.


The Screen brconfig.sys specification provides brief notation for controlling display attributes of PRINT FIELDS, INPUT FIELDS, and RINPUT FIELDS statements. These are single letter references intended to denote common display characteristics such as Normal, Bold, Highlighted or Reverse. At one point Underline was a supported convention, although it has now come to represent text-entry.

As in the case of screen attributes, certain SCREEN specifications, including Blink (B is now Bold), are no longer functional.


Start-up Default

SCREEN B 80,H 08,I 00,N 07,R 70,S 07,U 01

The second example indicates that the command console defaults to the N specification.


Each of the parameters in the SCREEN syntax is composed of a pair of specifications: a display attribute (B, H, I, N, R, S, or U), and "##" (a two- digit hexadecimal code). A space must always separate the display attribute from the hexadecimal code.

The following table identifies the intended use of each of the display attributes. Note that S may be used to set characteristics of the status line, although the S specification does not apply as an attribute in for PRINT FIELDS, INPUT FIELDS and RINPUT FIELDS.

 B  Blink
H High intensity
I Invisible
N Normal
R Reverse
U Underline
 S  Status line
C Command Console

The "##" portion of each SCREEN parameter originally denoted with a two digit hexadecimal code representing the characteristics to which the display attribute should be assigned. The hexadecimal codes were as follows:

 80  Blink
40 Background red
20 Background green
10 Background blue
08 High intensity
04 Foreground red
02 Foreground green
01 Foreground blue
70 (black on white) is the "normal" default for the Windows model.

Now, however, the two hexadecimal digits should be replaced by ATTRIBUTE names such as:

 B	[bold]
H [hilight]
I [invisible]
N [normal]
R [reverse]
U [text-entry]
S [status-line]
C [cmd_console]

The ATTRIBUTE names must also appear in ATTRIBUTE BRConfig.sys statements.
Note that ATTRIBUTE definitions may specify font in addition to color.

The preferred form of the SCREEN statement is therefore:

SCREEN B [bold], H [hilight], I [invisible], N [normal], R [reverse], U [text-entry], S [status-line], C [cmd_console]

See also Command Console Colors. The SCREEN C xx specification determines the foreground and background colors of the command console.

Screen OpenDflt

The Screen OpenDflt config specification

SCREEN OpenDflt "Srow=nn, Scol=nn, Title= {Application Name}, Buttonrows=nn", N 70 ...other screen statement attributes

Specifies the window parameters for opening the main screen when information is displayed prior to explicitly OPENing window #0.
This is the normal way of specifying attributes of the main BR window. See Open Window for a full description of window attributes that may also be specified here.


SPOOLCMD is mainly useful for producing print files for Linux and MAC systems. In Windows systems the DIRECT://printer-name is preferred. Also see the PRINTING section.

Basically, SpoolCmd provides a description of how to print data sent to the printer.

Business Rules supports independent spoolers on all systems. The BRConfig.sys SPOOLCMD specification will make a shell call to issue the necessary spool command whenever printing is done. When this is invoked the spooler is responsible for removing the spool file created by Business Rules.



The spool command and its parameters can be specified in a CONFIG command or in the BRConfig.sys file as follows:

Business Rules can also make substitutions as follows in parameters specified with SPOOLCMD (they're all optional):

[SPOOLFILE] substitutes the name of the spool file, as determined by Business Rules.

[NAME=] substitutes the name of the printer file as specified in the OPEN display statement's NAME= string. For example, PRN:/10.

[QUEUE] substitutes the queue name as specified in the OPEN display statement. In the following example, "queue" would be substituted for [QUEUE]: PRN:queue/10.

[PRINTER] substitutes the "printerclass" string as specified in the OPEN display statement. For example, PRN:/printerclass.

[COPIES] substitutes the value of the COPIES= parameter as specified in the OPEN display statement.

[WSID] substitutes the user's workstation ID.

[PROGRAM] substitutes the name of the program that is loaded at the time that the printer is closed.

The [QUEUE] and [PRINTER] parameters can be used almost interchangeably. They are simply a versatile way to pass specifications from the Open (or SUBSTITUTE) statement to the spooler.

NOTE: The spoolfile created by Business Rules will not automatically be deleted.

SPOOLCMD supports the -w flag which avoids the use of a DOS shell command when calling Windows applications directly. The Windows Client SPOOLCMD syntax is:

  SPOOLCMD [@] [-w] command  parm-1 parm-2 ...

SPOOLCMD honors BR drive substitution on the command itself, for example:

 DRIVE  J:,M:\myapp,j,\

This finds 'spooler' in M:\myapp\mylib.

See also:

Config Spoolcmd

As of 4.3, the CONFIG command supports the SPOOLCMD spec, which enables any system spooler to work with BR. See the "SPOOLCMD" specification in the BRConfig.sys Specification section for additional information. On DOS and NetWork versions, OPENs to PRN: will return error 6298 when the following two conditions are true:

1) SPOOLCMD is not specified
2) The printer is not ready.


The SPOOLPATH BRConfig.sys configuration statement specifies where print spool files are temporarily stored during printing. Use it to specify a full OS pathname:

SPOOLPATH  :/br/spool       - Linux or MAC example -

SPOOLPATH defaults to a spool directory that runs off of the BR root of the first drive statement. If no such spool directory exists and SPOOLPATH is not specified then BR creates one. For example:

DRIVE   J:,C:\BR,x,\MYAPP   

with no SPOOLPATH statement would result in spool files being placed in:


The status of SPOOLPATH and REMOTESPOOLPATH settings are displayed in response to the STATUS SUBSTITUTE command (not the STATUS CONFIG command). Instead, STATUS SUBSTITUTE displays the status of SPOOLPATH and REMOTESPOOLPATH.

Client Spoolpath

For client / server configurations, SPOOLPATH @: client-pathname Sets the remote spool path on the client. This is also where PDF files are created.

The statement format is: SPOOLPATH @::client-OS-fullpath


The '@:' tells BR that this path is on the client, or remote. The second colon in the example tells the client that this is not a relative pathname.

SPOOLPATH can be set concurrently for both client and server by specifying two SPOOLPATH statements. BR creates print files in the server spool directory during printing and forwards them to the client when the print file is closed.

The client-pathname has some unique characteristics:

  • Relative paths are assumed to be OS pathnames relative to the CLIENT_CURRENT_DIR folder, or the client startup directory if CLIENT_CURRENT_DIR is not specified.
  • If a full pathname is specified it must begin with a colon. (e.g. @::X:\path ). Otherwise, it will be preceded with the path to the client current working directory.
  • Specifying a relative remote pathname is not compatible with CLIENT_CURRENT_DIR SYNC.

See also:


The StatusLine Config specification allows the status line to be turned off on 25-line terminals. An optional message to replace the status line may also be specified. STATUSLINE has no effect on 24-line terminals.

1.) When a program is changed, Business Rules! will display the program name in reverse video. When the program is saved or replaced, the attribute is changed back to normal. This should help programmers keep track of whether or not they need to save or replace their programs. The INSERT message will appear on the status line when Business Rules! is in insert mode, even if the status line is off.

HOLD mode is activated by the Ctrl-T keystroke and, where permitted by the terminal protocol, by Ctrl-S.

2.) The BRConfig.sys STATUSLINE spec supports the ROWCOL parameter to specify whether or not the current row and column of the cursor is displayed on the right side of the status line. If ROWCOL is on, the information will be displayed in row:column format. If ROWCOL is off, the Business Rules! release number will be displayed in the same area. The format of the specification is as follows:


The default for STATUSLINE ROWCOL is OFF.

Comments and Examples

The use of STATUSLINE OFF makes a 25-line terminal operate essentially the same as a 24-line terminal: the status line is blank until an error occurs, at which time Business Rules! automatically enters HOLD mode and displays the status line with the error code. (The user must then leave HOLD mode to resume program execution.) The main difference between using a 24-line terminal and using a 25-line terminal with STATUSLINE OFF is that STATUSLINE OFF allows an optional message to be specified for the 25th line; also, STATUSLINE OFF continues to respect SCREEN S specifications that alter the attribute in the 25th line.


Diagram Default

Leave status line blank.

Start-up Default



The "ON" parameter (functional only when specified with the CONFIG command) overrides previous STATUSLINE OFF specifications and turns the status line back on.

The "OFF" parameter turns the status line off. It may be followed by the "string-constant" parameter, which represents a message that is to be displayed in the status line. Quotation marks are not required in the string constant; they will be passed as part of the message to the status line if included. The special characters' E0-EF and ESC xx may be used in the string constant to change the attribute for the message.

Technical Considerations

STATUSLINE may be specified with the CONFIG command.

See Also


The Style BRConfig.sys specification alters the appearance of program lines to suit varying tastes for capitalization and indentation. It can also be used with the Config style command or within a program line using the Execute statement.

Comments and Examples

Some features of STYLE's INDENT parameter will not take effect until a program is either listed to a file or saved in source and then reloaded. These actions cause lines that are subordinate to FOR, DEF and blocked IF statements to be indented an additional amount according to their level of subordination. The following program lines contain three sets of lines which are subordinate, or fall beneath the execution of other lines:

  1. lines 30 to 50 are subordinate to the FOR statement in line 20;
  2. line 40 is subordinate to the FOR statement in line 30;
  3. line 80 is subordinate to the DEF statement in line 70:
00010 !
00020 FOR Y=1 TO 5
00030     FOR X=1 TO 10
00040         PRINT X
00050     NEXT X
00060 NEXT Y
00070 DEF FNX
00080 LET X=2
00090 FNEND

Assume that the following STYLE specification was active when the above lines were typed in:


If so, the previous lines would be listed as follows upon execution of the LIST command:

00010 !
00020  FOR Y=1 TO 5
00030      FOR X=1 TO 10
00040          PRINT X
00050      NEXT X
00060  NEXT Y
00070  DEF FNX
00080  LET X=2
00090  FNEND

If the following program lines were saved in source while the same INDENT parameter remained in effect, they would appear as follows upon reloading (note that the subordination described above is illustrated in this listing):

00010 !
00020 FOR Y=1 TO 5
00030   FOR X=1 TO 10
00040     PRINT X
00050   NEXT X
00060 NEXT Y
00070 DEF FNX
00080   LET X=2
00090 FNEND

The effects of STYLE's COMMENTS parameter differ according to whether it is acting on a comment which follows a statement or not. Also, STYLE COMMENTS specifications may be disabled for individual comments when the comment begins with a period. Imagine that the following CONFIG command is in effect:


The following two examples show how STYLE responds when comments do not follow a statement. The comment in line 10 would disable the impact of COMMENTS MIXED because the first character is a period. Line 20 utilizes the COMMENTS MIXED specification but because the comment does not follow a statement, the first letter in each word is capitalized.

00010 ! . capitalization control is disabled for this comment
00020 ! With Mixed, 1st Letter Of Each Word Is Capitalized

The next two examples show how STYLE responds when comments do follow a statement. Again, the comment in line 10 would disable the impact of COMMENTS MIXED because the first character is a period. Line 20 utilizes the COMMENTS MIXED specification but now that the comment is following a statement it capitalizes only the first letter of the first word in the comment.

00020 LET X(7)=15 ! . capitalization control is DISABLED for this comment
00030 LET X(8)=25 ! With mixed, only 1st letter of 1st word is capitalized

Preferred Use of STYLE COMMENTS

STYLE COMMENTS MIXED is NOT the preferred use of the STYLE COMMENTS setting. Preferred is:


This setting leaves capitalization entirely up to the programmer. No changes are made. The INDENT keyword has 2 numeric parameters. The first specifies the number of spaces used for each indent increment. The second sets the minimum column where comments appear that follow program statements. In the above example:

00040    IF A > B THEN                     ! This comment starts in Column 45
00050       LET C = J                      ! So does THIS ONE.
00060    END IF


Diagram Default

Do not indent comments that follow statements or (when specified with CONFIG) retain previous setting.

Start-up Default



The top path of the syntax diagram allows you to specify your preferences for indentation. The "CLEAR" parameter (functional only when STYLE is specified as part of a CONFIG command) causes any previous INDENT specifications to be cleared and puts INDENT's start-up default values into effect.

integer: This parameter specifies the number of positions that each line (excluding lines that start with labels and comment lines that begin with !) is to be indented. Integer may have any value from 0 to 8.

column: This parameter may optionally follow the integer parameter. The column parameter indicates the column position to which comments should be indented. This parameter may have a value of 0 (no indent) or it may have any value from 20 to 60. Only comments which follow a statement are affected by this specification. Comments which are alone on a line or which follow a line label will not be indented.

It is important to note that some features of the INDENT parameter will not take effect until a program is either listed to a file or saved in source and then reloaded. For instance, lines that use manual indentation will not be indented by the INDENT parameter until the program has been saved in source. Also, lines that are subordinate to other statements such FOR or DEF will be indented an extra level upon saving to source (see the Comments section for an example).

BR differentiates between CONFIG STYLE INDENT 0 and CONFIG STYLE INDENT CLEAR. Both specifications previously maintained existing indentation. Now, CONFIG STYLE INDENT 0 does just the opposite: it strips all indentation out of a program when it is saved as source. CONFIG STYLE INDENT CLEAR, which remains as the default, does nothing to alter indentation. It is preserved when saved as source and reloaded.

The second through fifth paths of the syntax diagram are similar in that they all affect capitalization of the different elements in a program line. "KEYWORDS" affects the capitalization of all primary and secondary keywords; "LABELS" affects capitalization of line labels; "EXPRESSIONS" affects all non-literal expressions, including variable names and functions; and "COMMENTS" affects the text in REM comments and in the comments that follow exclamation points.

Four capitalization options are available for each of these elements
UPPER indicates that the element should be listed in uppercase;
LOWER indicates it should be listed in lowercase;
MIXED indicates it should be listed with the first letter in uppercase and the remaining letters in lowercase (see below for an exception);
CLEAR (functional only when STYLE is specified as part of the CONFIG command) indicates that any previous specification for that element should be cleared so that only the start-up default value remains in effect.

The MIXED parameter's effect on comments varies according to the type of comment. If the comment follows a Business Rules statement the first letter of the first word will be uppercase and the rest will be lowercase. If the comment does not follow a statement (if it is alone on a line, for instance), the first letter of each word is uppercase and the rest are lowercase. Capitalization specifications may be disabled for individual comments when the first character in the comment is a period (.).

The bottom path of the syntax diagram is functional only when STYLE is specified as part of the CONFIG command. The "CLEAR" keyword causes all previous STYLE specifications to be cleared from operation so that only the default values remain in effect.

Technical Considerations

  1. STYLE may be specified with the CONFIG command.
  2. The process of saving a file in source causes the current STYLE formatting to be saved with the file. This may be undesirable in certain instances, particularly with the effects of the INDENT and COMMENTS parameters (see above).
  3. Complete re-indentation occurs when a program is saved or listed with redirection.
  4. Once capitalization of comments has been saved in source with the file, there is no way to recover the style in which the comments were originally typed.
  5. The INDENT parameter never affects two types of program lines: those that begin with exclamation points, and those that begin with a line label.


The Substitute config specification substitutes all references to one file name string with another file name string in commands and OPEN statements.

You can now redirect the Ctrl-P (print screen) output to a file/printer of your choice by substituting 'PRN:/10' with the SUBSTITUTE specification. The following example sends Ctrl-P output to LPT2:


Comments and Examples

The following one-line addition to BRConfig.sys allows you to use a serial printer instead of a parallel printer as the default printer on DOS or NetWork systems:


On a Unix / Linux system, the following SUBSTITUTE specification changes the execution of programs written for the first serial port on a DOS system so that tty22 will be used instead:

SUBSTITUTE COM1:,:/dev/tty22

While Business Rules! is in execution, a single SUBSTITUTE specification may be specified or removed without affecting the remainder of the substitute table. The following example removes the substitution specified above from the substitute list (the BRConfig.sys file is not changed by this command, it is simply overridden):


All substitutions (except [WSID] substitutions) may be removed with the following command:



Diagram Default

Add the specified substitution to the substitution table.

Start-up Default

Use no file name substitutions.


"String1" is either a full or partial file name reference that is to be replaced with a substitution.

"String2" is either a full or partial file name reference that is to be used in place of all program references to string1.

The "CLEAR" parameter is functional only when SUBSTITUTE is specified with the CONFIG command.

When specified immediately after the SUBSTITUTE keyword, CLEAR removes all substitutions (including those previously specified with CONFIG) from the substitution list. When specified after the "string1" and "string2" parameters, CLEAR removes only the specified substitution from the list

Technical Considerations

  1. The CONFIG command can be used during program execution to specify or remove SUBSTITUTE specifications.
  2. Business Rules converts all SUBSTITUTE parameters to uppercase except those that begin with a colon.
  3. All Unix / Linux file name references must begin with a colon.
  4. See the Multi-User Programming chapter for more information about using SUBSTITUTE to change printers.
  5. The STATUS SUBSTITUTE command provides a listing of all currently active substitutions specified by CONFIG SUBSTITUTE or the BRConfig.sys file.

Substitute now supports both upper and lower case results.

00200 execute 'config SUBSTITUTE "XXX YYY" "AbCd EFg"'


The TypeAhead BRConfig.sys specification turns keyboard buffering on or off.


The default is TypeAhead ON (ON is not required); this causes keystrokes to be buffered. TypeAhead OFF will clear the keyboard buffer before input. This is desirable for beginning operators who may stack up several return keys waiting for a function to complete. BRC recommends that even when TYPEAHEAD ON is used, menu programs should clear the keyboard buffer before input with a statement such as the following at the beginning of the program:

00100 IF KSTAT$<>"" THEN GOTO 100 ! clear keyboard buffer

TYPEAHEAD can also be set using the CONFIG command, or from within a program using the Execute statement.


Diagram Default


Start-up Default

TypeAhead ON


The "ON" parameter turns keyboard buffering on, and the "OFF" parameter causes the keyboard buffer to be cleared before input.


The USERLEVEL specification identifies the learning level for which a program's field help windows should be automatically displayed. This specification allows you to selectively or fully turn off automatic display of field help windows for advanced users.

Comments and Examples

USERLEVEL works in conjunction with the "helpstring" parameter that is referenced by INPUT FIELDS, RINPUT FIELDS, INPUT SELECT and RINPUT SELECT statements. The very first item in the "helpstring" parameter identifies the minimum user level for which the field help is intended. For example, the following program line identifies 2 as the minimum user level for the field.

10 HELPSTRING$="2B;Type in your name;"

The message "Type in your name" will be displayed when the cursor enters the field as long as the current BRConfig.sys USERLEVEL is 2 or above. If USERLEVEL is set to less than 2, it will be necessary for the user to press the <HELP> key to see the field help window.


Start-up Default



USERLEVEL differentiates between four levels of expertise:

The "0" level is designed for the expert-plus user: it turns off all automatic displays of field help. Field help windows are displayed for the current field only when the <HELP> key is pressed.

The "1" level is designed for the expert user. It allows automatic display of field help only when the user level specified for the field is 1.

The "2" level is designed for the intermediate user. It allows automatic display of field help when the user level specified for the field is either 1 or 2.

The "3" level is designed for the novice user. It allows automatic display of field help when the user level specified for the field is 1, 2 or 3.

Technical Considerations

1.) USERLEVEL may be specified by the CONFIG command.
2.) When a field does not have a field help window, pressing <HELP> while the cursor is on the field causes Business Rules! to generate an error which may be trapped by the HELP error condition.
3.) When a field help window is being displayed for a particular field and the <HELP> key is pressed, Business Rules! generates an error which may be trapped by the HELP error condition (this allows two levels of help information to be programmed into an application). If the HELP error is not trapped, the pressing of <HELP> causes the field help window to be turned off.


The WorkPath config specification identifies a path location to be used for the Business Rules! Workfile. This was useful for directing the work path to a RAM disk.

Work File Naming

(4.2+)Work files other than EDIT work files have the same names they have in the past except their WSID also includes the SESSION ID digit and they are subject to the following WORKPATH enhancement:

  1. The fullpath portion of the existing WORKPATH statement is now optional.
  2. A second optional parameter is supported: [LOGIN_NAME] (case insensitive). This causes all work files (other that EDIT files) to be in the format filenameSESSIONID.login_name.suffix

For example:


Note that SESSIONID is retained and login_name is inserted with an extra period.

    WORKPATH  [LOGIN_NAME]     (just specify workfile name inclusion)
              - or -
    WORKPATH  C:\MYAPP\TMP  [LOGIN_NAME]    (workpath plus name inclusion) 

Files that are affected by WORKPATH: • BRSPOOL - client spool files • WBSPL - server spool files • PDF • SORT workfiles • INDEX workfiles • Other temporary workfiles that have been opened with wsid

EDIT work file names are not subject to WORKPATH name specifications. They also do not include WSID or SESSION. BR keeps workfiles separate for the same program name located in different directories, but does NOT attempt to separate multiple EDITing sessions either by the same user or different users.


  • WorkPath is not available for use with Config (command).
  • WorkPath drivename:\\directory where files will be processed


The WorkStack specification allows you to change the size of the work stack, which keeps track of temporary variables that are passed and localized during user- defined function calls, concatenations, or complex expressions.

Checking Values

The following environmental variables may be used to check your workstacks during a BR! session.


Also the command STATUS STACKS shows the current stack settings.


Start-up Default

WorkStack 500000 (version 4.3+)


"Integer" is a whole number that represents the number of bytes that the work stack may contain. It must be greater than 499 and may be arbitrarily high (e.g. up to 99 million bytes).

Technical Considerations

  1. WorkStack may be specified only in the BRConfig.sys file; it is not valid with the Config command.
  2. The amount of stack memory available depends upon several variables. You may need to monitor your memory usage to determine the optimal stack size for your needs.


The WSID config specification sets the Workstation ID (WSID$ and part of Session$). See the BR32.exe startup command for details on specifying the workstation ID at start-up by use of a command line parameter. While processing a Business Rules! program you will need to use WSID$ to check the value of WSID. The WSID In Use message tells who has the WSID.


Start-up Default

01 for single-user systems. It is based on hardware port for Unix and Linux, and based on order of sign-on for Windows.


"Integer" is any whole number from 1 to 999.

Technical Considerations

  1. WSID may be specified only in the BRConfig.sys file; it is not valid with the CONFIG command.
  2. When WSID is specified both in BRConfig.sys and in the BR startup command, Business Rules! uses the value in the BR startup command.
  3. The WSID integer may be followed with a plus sign (+) and an increment value, signifying that the login name may be assigned more than one WSID value.

Any BRConfig.sys statements that begin with an "@" character are ignored unless the Login_Name$ variable value matches the character string following the @ character. This will enable you to assign a block of WSID's to each user as follows:

@mary  WSID  10+1
@tom   WSID  13
@george WSID 16+1

This example allows Mary and George to have multiple logins, whereas Tom would only be allowed one login (omitting the increment value restricts Tom to only WSID 13).

WSID=UNIQUE gives each Windows session a new WSID. This differs from the default WSID assignment in that a fresh WSID is assigned for each new session under Windows. By default, each session on a Windows system is assigned the same WSID, with a new session ID number (up to 9 sessions).

WSID=UNIQUE has the disadvantage of requiring each session to be licensed (each session is considered to be a new user). That is, this feature ends up being significantly more expensive than multiple sessions.

BR supports multiple sessions in Windows client environments. Up to nine sessions per workstation are allowed without incrementing the number of users for licensing purposes. To support proper file sharing between multiple local sessions, a SESSION$ system variable is used, similar to WSID$. It consists of the WSID with the session ID (1-9) appended.

WSID=SESSION specifies that WSID will have the session number appended to it.

THIS CAN CAUSE PROGRAMS TO FAIL WITH INVALID FILENAMES, if proper care is not applied, because it extends the WSID by one character.