Terminal Considerations

This APPENDIX provides information about how the Screen I/O capabilities of Unix / Linux terminals may affect Business Rules programs. This information in is designed to help you make decisions about whether or not your application is suited for the reduced capabilities of some terminals. It is also designed to help you make decisions about programming standards for applications, which will run on Unix / Linux terminals.

Before you buy a terminal...

Unix / Linux terminals differ widely in their capabilities. If you are in the market for a terminal to buy for yourself or remarket to customers, you should be aware of what it can and cannot do. Some of the characteristics that you may specifically wish to check into include the following:

How many screen lines does the terminal support?

Many Unix / Linux terminal screens have 24 lines rather than 25. If the terminal has only 24 lines, the status line remains invisible unless the user presses the Esc key to see the it. (Pressing Esc again turns the status line off and makes the display operable again.)

When an error occurs on a 24-line terminal, Business Rules automatically displays the status line as if the user had pressed Esc. Once this has happened, the user must press Esc to turn the status line off before continuing with any actions to correct the error.

Programs which run on 24-line terminals should not be dependent on the MSG$ function or on the STATUSLINE specification's "string-expr" parameter, both of which put a specified message in the 25th line.

Do attributes occupy a space?

On many Unix / Linux terminals, display attributes occupy a space on the screen. This can make programs, which heavily utilize attributes -especially background color attributes -very unattractive. One way that you may be able to work around the problem is to use the BRConfig.sys SCREEN specification to remap your attributes. For example, you could use SCREEN to remap all R (red) attributes to display as N (normal).

Another programming technique to avoid when attributes occupy a space is fields that are very close together (one or zero spaces apart). The attribute will overwrite anything that appears in the space it must occupy, including a character or attribute from another field.

I/O windows and field help windows are also affected by terminals that use a space for the attribute. Note the following

1.) Screen positions 1,1 and 24,80 are reserved for attributes. Windows without borders must leave both these positions blank; windows with borders must leave these positions blank and they should leave 1,2 and 24,79 blank.

2.) The N= attribute and the border attribute (specified in the OPEN window statement) should be the same when windows are to be displayed on terminals that use a space for the attribute. If this is not done, the left and right sides of the border will disappear, as they will be overwritten by attribute characters.

3.) Field help windows operate somewhat differently on terminals that use a space for the attribute. Business Rules uses the same attribute which is specified for the text area of the window (with the N= parameter) for the border. Thus, the attribute, which is specified for the border, gets ignored.

Does the terminal support the graphics character set?

Some terminals do not support certain drawing characters, particularly the double-line and block characters. Programs should be designed to use the single-line character instead if non-support will be a problem.

On most Unix / Linux terminals, all the graphics characters between B3 and DE must be mapped in the wbterm.in file before they will be supported. Contact your dealer or ADS for supplemental documentation on this topic if you require additional information.