Multi-User Programming

This article describes the Multi-User Programming features of Business Rules!. All versions of Business Rules! -both single-user and multi-user -support most of these features; BRC encourages you to incorporate them into all your programs.

See also the Multi-User Programming category.

Centralized Processing vs Distributed Processing

There are two types of multi-user systems:

• those that use centralized processing, and
• those that use distributed processing.

Business Rules! operates the same on both, but the two systems carry some inherent differences in processing capability and speed that you should be aware of.

Distributed Processing

Each workstation in a distributed processing system has a CPU completely dedicated to its own tasks. Therefore, CPU-intensive jobs running on one workstation do not affect the performance of other workstations. Also, each workstation can have its own local data storage system (diskette or hard disk). The biggest disadvantage to a distributed processing system is its cost: each workstation is essentially a stand-alone computer, and comes with a comparable price tag. The IBM NetWork and the Novell NetWork are examples of distributed processing systems.

Centralized Processing

Centralized systems such as Unix and Linux offer very fast processing provided that not too many workstations are heavily using the system. When one workstation is processing a report, for example, and two others are processing keyboard (data) input, the throughput of the report will be significantly faster than it would be on a standard PC.

Once the basic system has been purchased, most centralized processing systems have a moderate to large price advantage over distributed processing systems.

Choosing a multi-user system

It is important to thoroughly evaluate your company's specific needs -both current and future -before deciding between a centralized or distributed processing system. Often there are no clear-cut answers to which type of system will work best for you, but the following three questions should help you determine your priorities:

1.) DOS Compatibility: How many of your workstations require the ability to run DOS programs?

2.) Type of Processing: How much demand will each workstation be putting on the system?

3.) Type of Printer: Will you primarily be using a local or a spooled printer?

DOS Compatibility

To run DOS programs on a centralized system, you may need to use a standard PC as a workstation and then utilize a terminal emulation package which allows you to switch between DOS and Unix or Linux. Depending on how many DOS workstations you need, this option could undermine the cost-effectiveness of a centralized system.

Type of Processing

There are two categories of processing. Data input and inquiry requires a great deal of attention from the operator and very little performance from the CPU. Update and report processing, on the other hand, uses as much CPU power as it can get until the job is complete. This type of processing uses roughly seven times more CPU power than data input and inquiry does.

As each workstation has its own CPU, CPU- intensive tasks are not nearly as draining to a distributed processing system as they are to a centralized system. A set of five workstations, all of which are primarily used for updating or reports, would probably operate more efficiently on a distributed processing system than it would on a centralized system. Centralized processing systems usually work best when only one or two workstations are drawing heavily on the CPU. A system of five workstations, three of which are used mainly for data input and the other two of which continually handle reports or updates would probably receive good results from a centralized system. The ability of a system to efficiently perform complex operations is, of course, hardware-dependent; as the power of the CPU increases, so can the number of CPU-intensive tasks.

Type of Printer

Use of a spooled printer on a distributed processing system requires much more system overhead than it does on a centralized processing system. The reason for this is that the centralized system handles most of the process internally, where as the distributed system must transfer data from the file server to the workstation and back again before it can go to the printer.

Multi-user Programming Considerations

All versions of Business Rules are set up to open files NOSHR (no sharing allowed) when a file-sharing parameter is not specified. This automatic default allows programs written for single-user systems to run on multi-user systems without problems -as long as only one workstation needs to access the files at any point in time.

Multi-user features may be coded in programs used on single-user systems in Business Rules. This is, in fact, strongly recommended even if you are not currently planning to move your programs to multi-user systems: the time that such implementations take while writing a program is minimal, compared to the time to add them later. With the growing popularity of multi- user computing, this small expenditure of time will be well rewarded in the multi-user marketplace.

Share spec Parameters

The primary advantage of multi-user systems is that they allow more than one user to access the same files at the same time. Occasionally, there are situations where you want to either limit or entirely restrict others access to a file while you are working on it. The share-spec parameters, available with Business Rules OPEN display, OPEN internal, and OPEN external statements, allow you to do this.

The share-spec parameter determines whether or not to permit other OPEN statements to access the current file; it does not restrict the input/output level of the current OPEN. Closing a file automatically releases the OPEN's share restrictions.

There are three available share-spec parameters:-NOSHR, SHRI, SHR

NoShr

NOSHR (no share) indicates that the current workstation is has exclusive access to the file. No other opens are permitted to the same file until it has been closed. NOSHR is the default when a "share spec" is not specified.

NOSHR should be used to prevent others from accessing a file while a program is doing a batch update, purging a file of unwanted records, or using a temporary work file.

See File Name Locking for information on the PROTECT command and the OPEN statement's RESERVE parameter; these two instructions can prevent access to a NOSHR file while it is in transition from one program or command to another.

Since NOSHR is the OPEN statement default, neglecting to specify share-spec parameters in your programs may unnecessarily limit file accessibility when the programs are installed on a multi-user system. You can easily save a great deal of future time and tedium by specifying the appropriate file-sharing standards in all your programs, even if they are currently being designed for single-user systems only.

See Record Locking for more information.

ShrI

SHRI allows others to use the file for input only. Others may read but not change a file opened SHRI. This parameter is useful when a program is doing batch updates or multi-record updates.

Due to potential hazards that could be caused by changes to an internal file between sorting and printing a report, ShrI is the system default for both the SORT control file and the SORT input file. As an example of such a situation, consider a report that prints a customer master file in name order. The report would either appear to be out of order or it would produce an error if another user were to change or delete a record after it was sorted and before that particular record was printed.

The SORT and INDEX utilities depend on stable input data during the sorting or indexing process. Therefore, the default for the input file is ShrI. It is possible to override the default file-sharing attribute for SORT input files. The NoShr and Shr parameters may also be specified in the FILE specification of a SORT control file. Before specifying the Shr parameter, however, you should be sure to consider the possible effects to a report program if the file is changed before or while the report is being printed.

When ShrI is specified with a file opened for INPUT, OUTPUT, or OUTIN, all subsequent OPENs must be for input only (except when using multiple index files at the same workstation). If the file was previously opened for OUTPUT or OUTIN, a file-sharing error would occur on an attempt to open with ShrI. The table below summarizes the rules and errors that can occur with various combinations of file-sharing parameters and pairs of first and second OPENs, either both from the same workstation or from two different workstations.

See Record Locking for more information.

Shr

SHR allows others to read, write and update an open file. An individual record within this file may be locked during use when either OUTPUT or OUTIN is also specified and when the I/O statement utilizes the RESERVE parameter (RESERVE is the default, so explicitly coding it is not necessary). SHRU operates the same as SHR, but it is used only to maintain System/23 compatibility.

SHR allow others to freely access and update the file being opened. Use of this parameter maximizes the multi-user system's capabilities; however, it also increases system overhead (see Automatic Record Locking for ideas on reducing system overhead).

Unless otherwise specified, individual records within a file that is opened for SHR,OUTIN are automatically locked as they are read. See Record Locking for more information.

File Name Locking

In addition to the file-sharing facility described in the Share Specs, Business Rules! has the ability to reserve a full path name for the exclusive use of a workstation by means of the RESERVE parameter in either the PROTECT command or the OPEN statement. This is known as File Name Locking

The primary difference between file name locking with the RESERVE parameter and file locking with NOSHR is that RESERVE keeps a file locked even when it is not open. The RELEASE parameter can be used both in the PROTECT command and in the CLOSE statement to release a reserved file name. All file reservations issued from a particular workstation are automatically released when that workstation exits from Business Rules!. Another difference between NOSHR and RESERVE is that NOSHR affects other OPENs by the same workstation (except for multiple index files), but RESERVE does not.

The Protect Command

The PROTECT command requires a choice between one of four different parameters: RESERVE, READ, WRITE, or RELEASE (see PROTECT for a syntax diagram).

The "RESERVE" parameter prevents others from using the specified file or file name. "READ" allows all workstations to read file data (the file must exist), but not to change it (the file is write protected). "WRITE" removes the READ-only status and allows all workstations to READ and WRITE to the file. Both the READ and WRITE parameters refer to the current workstation as well as to others. "RELEASE" removes PROTECT RESERVE restrictions which have been initiated by the current workstation from the specified file. A RELEASE can only be done from the workstation that initiated the PROTECT restrictions.

The following procedure file illustrates the use of PROTECT to prevent others from using the customer file while deleted records are removed and the index is rebuilt:

PROCERR RETURN
PROTECT CUSTMAST,RESERVE
PROCERR STOP
SKIP DONE IF ERR <> 0
COPY CUSTMAST WORK[WSID] -D
FREE CUSTMAST
RENAME WORK[WSID] CUSTMAST
INDEX CUSTMAST,CUSTMAST.KEY,1,4,REPLACE
PROTECT CUSTMAST,RELEASE
:DONE
CHAIN "MENU"

If the PROTECT RESERVE instruction had not been issued for the above procedure, another workstation would have been able to open the file during the COPY; such an occurrence would prevent the FREE and RENAME commands from executing.

When PROTECT RESERVE is successful, other workstations are not allowed access to the full path name of the file. Business Rules consults an internal table of file reservations before beginning every OPEN process; if the specified file is reserved, the system returns a 4148 error (file sharing rules violated) without even accessing the disk. The SKIP command needs to only test ERR for zero or nonzero because the PROCERR RETURN forces ERR to be zero.

The PROTECT command may also be used to reserve a file's name even when the FREE command has been used to delete the rest of the file. This feature allows you to reserve a file, then delete the file while continuing to reserve the file's name. You can then rename the contents of another file to the reserved file name. You can even reserve files that do not exist.

The OPEN RESERVE parameter

As one of the options in the OPEN statement, the RESERVE parameter reserves the specified file name for exclusive use by the current workstation in the same manner as the RESERVE parameter in the PROTECT command does.

There are two ways to release a file which has been reserved with the OPEN statement by the current workstation: with the PROTECT command and with the CLOSE statement. Both must be initiated only by the workstation that initiated the restrictions. The command PROTECT XYZ,RELEASE releases restrictions placed on file XYZ by the RESERVE parameter in the OPEN statement. It also releases any previous restrictions placed on the file by PROTECT RESERVE. If the specified file is open when the PROTECT RELEASE command is issued, it remains open.

The statement CLOSE #1,RELEASE closes and releases file #1. All file restrictions, including any placed on the file by PROTECT RESERVE are released. When CLOSE is used without the RELEASE parameter, any file name reservations remain intact. The CLOSE statement may only be used to release a file, which is currently open.

Exception

The RESERVE and RELEASE parameters which appear in the PROTECT command and the OPEN and CLOSE statements are not fully supported by the IBM NetWork. At the time of execution of a RESERVE parameter, the IBM NetWork will check to make sure that a record is free, but it will not reserve the record (thus a RELEASE parameter will have no effect on this system).

Automatic Record Locking

Other workstations and other file numbers in the current program are unable to either read or write to a record when it is locked. Business Rules locks records read from within a file opened for SHR,OUTIN. Also, records can be locked by other I/O statements by using the RESERVE keyword.

Opening files for INPUT will now open them read only. THIS ALLOWS FILES WITH READ ONLY PERMISSIONS TO BE OPENED. A consequence of this is the undetectability of multiple opens input noshr. However, this poses no jeopardy to data. Any open requesting write permissions will not be allowed while the file is opened input noshr, and no input noshr will be allowed while the file is opened for writing, but two opens input noshr MAY be allowed on the same file at the same time. Under some circumstances, two attempts to open a file input noshr will fail and sometimes they won't. This is dependent on the operating system and what files are already opened. But, while restrictions have been loosened, they require no changes to your applications to assure data integrity.

Record locking protects a record from being read or changed by a second workstation while the first workstation is still accessing it. This allows multiple users to access the same file without the threat of damaging records that others are updating or changing. By default, Business Rules fifteen seconds for a locked record to become available before it returns a locked-record error (error code 0061) to the user requesting the second READ. The time to wait for a locked record can be defined in the OPEN statement using the WAIT= parameter.

The following table summarizes the default action, and the action when RESERVE and RELEASE are coded for each of the six I/O statements used with internal files. All except the DELETE statement may also be used with external files.

Record locking and unlocking does add to system overhead; if it is not necessary, you may wish to avoid it. The statement READ #1,RELEASE: may be used to read a record without locking it when the record will not be rewritten. You may also specify REREAD #1,RELEASE: or RESTORE #1: to release locked records which will not be updated.

Similarly, system overhead can be minimized for all records processed by avoiding the use of SHR,OUTIN files. Changing to SHRI,OUTIN or SHR,INPUT will reduce system overhead.

While it is beneficial to avoid unnecessary overhead with file locking and unlocking, you should be careful to utilize this feature of Business Rules it is needed. The system overhead, which is created, is not so great that you should entirely avoid the use of files opened SHR.
File:Help0138.jpg

Locking Multiple Records

Multi-record update techniques using the RESERVE record parameter with the READ, REREAD, WRITE, REWRITE, RESTORE and DELETE statements can be used when several records must be locked and updated at the same time.

Whereas records are normally unlocked when they are rewritten or when another record is read, the RESERVE parameter in I/O operations indicates that previous locks are to remain in effect during and after the current operation. This allows for more than one record to remain locked at one time.

Since RELEASE is the default for previously locked records, RESERVE must be specified each time a file is referenced in READ, REREAD, WRITE, REWRITE, DELETE and RESTORE statements when you wish to keep previous record locks in the file intact.

An on-line order entry system which reads inventory records for all items on an order, verifies stock levels before accepting the order, then processes the order and updates stock levels, is an example of a situation where multiple record locking might be necessary. As the following sets of program lines illustrate, all records must be locked as they are read, and rewritten; then they are all unlocked. Notice that the RESTORE statements in lines 230 and 290 are used to release the locked records when they are no longer needed:

00200 FOR X=1 TO NUMBER OF ITEMS
00210 READ #3,USING 220,KEY=ITEM$(X),RESERVE:QTY,ALLOC
00220 FORM POS 60,2*B 4
00230 IF QTY(X)>QTY-ALLOC THEN RESTORE #3: :GOTO 100 !:! out of stock
00240 ALLOC(X)=ALLOC+QTY(X) : R(X) = REC(3) ! Save for update
00250 NEXT X
00255 FOR X=1 TO NUMBER OF ITEMS
00260 REWRITE #3,USING 270,REC=R(X),RESERVE:ALLOC(X)
00270 FORM POS 64,B 4
00280 NEXT X
00290 RESTORE #3: ! Release all record locks
00300 GOTO 100

An error will occur in the above program when one of the needed records has already been locked by another user. Adding IOERR 290 to the end of line 210 would trap the locked record and abort the processing of this order. NOTE that the record number of each record is save in line 240, making the REWRITE in line 260 much faster.

File Lockout Error Recovery

Use of the IOERR error condition and a corresponding error handling routine allows you to gracefully handle file lockout errors. The following set of program lines illustrate one such routine:

00100 OPEN #1:"NAME=....  IOERR CONFLICT
00500 CONFLICT: IF ERR=4148 THEN 600
00510 PRINT "Error ";ERR;" has occurred at line ";LINE
00520 LINPUT X$ : RETRY
00600 PRINT "A file requested on line"; LINE;"is in use."
00605 PRINT "Press <CR> to try again, OR F10 to end."
00610 LINPUT X$
00620 IF CMDKEY=10 THEN GOTO END OF PGM ELSE RETRY

Workstation ID (WSID)

When two workstations simultaneously run the same program, all output and temporary file names must be unique -or at least one of the programs will fail. The use of the workstation ID [WSID] as a suffix to the names of temporary files allows you to create unique file names. [WSID] may appear anywhere that a valid file name may appear. Business Rules workstation identifier, from the function WSID$, replaces [WSID] with the workstation's unique identifying number, when [WSID] is specified in file references as though the program performed the following replacement:

NAME$=SREP$(NAME$,1,"[WSID]",WSID$)

Business Rules accepts the [WSID] in lowercase letters ([WSID]), as it converts all file names to uppercase for processing. The [WSID] is treated as a special SUBSTITUTE default. Any form of the STATUS command can be used to display the current WSID.

Examples

FREE WORK[WSID]
INDEX CUSTMR,CUSTKEY.[WSID],1,5,REPLACE
00010 OPEN #1:"NAME=CUSTMR,KFNAME=CUSTKEY.[WSID]",INPUT,INTERNAL,KEYED

! An example of a SORT control file

3FILE CALL.FIL,,,SORTOUT.[WSID],,,,,A,N,SHR,REPLACE
RECORD I,34,1,C,'1','1'
MASK 35,2,C,A,37,3,PD,A

Multi-spooled Printers

All multi-user versions of Business Rules allow using more than one spooled printer. Printed output can be spooled to different types of printers (dot matrix, letter quality, etc.) or to printers dedicated to different special forms (checks, invoices, etc.). Also, printers can be selected after entering Business Rules. Support for multiple spooled printers allows programmers to intermix PRINT statements for two or more reports or types of forms in the same program.

We recommend designing your programs (even for single-user systems) with the maximum number of different printers. Each different type of printer can be identified by a programmer-assigned class number, which will be explained further below. Consider using different class numbers for each application area, paper form, paper width, volume requirements, color requirements and so forth.
At installation time, the various printer classes can be reduced or consolidated to the number of printers actually present, either by the operating system or through BRConfig.sys SUBSTITUTE specifications. This plan maximizes both power and flexibility; a system-wide change in printer classes does not require any changes in your individual programs, only in the BRConfig.sys file.

Unix / Linux Multiple Printer Support

A file-ref that begins with PRN: will always designate spooled printer output unless the PRN: has been mapped to something else through a SUBSTITUTE specification. The class number will directly translate to the Unix / Linux printer class that the output will be sent to. As the default printer class is 10, the Unix / Linux operating system must include at least one printer that is a member of printer class 10.
While the printer file is open, the STATUS FILES command will show a name similar to the following where ww is the workstation ID and xx is a number that makes the file name unique:

PRN:/10 /usr/tmp/WSPOOLww.xx

For local printer support, use a SUBSTITUTE specification that will change one or more printer classes to a Unix / Linux device name:

SUBSTITUTE PRN:/11,:/dev/tty15

Definitions and Overview

Lines printed by PRINT #255 go to the default printer. The default printer name is PRN:/10. since there is a default OPEN statement for the default printer, PRN:/10 is sometimes called the default printer open.

Based on a Unix / Linux convention, the 10 in PRN:/10 refers to the printer class. The printer class is an arbitrary two-digit number assigned by the programmer. One case where the printer class would be useful is a multi-user system with a letter-quality printer. Printer class 20 could be used in the OPEN statement for output that a customer might want on a letter-quality printer. When installing your software for a customer who decides not to start out with a letter-quality printer, but only has one dot-matrix printer which is used for class 10, insert the following in the BRConfig.sys file:

SUBSTITUTE /20,/10

This substitutes or replaces all /20 references with /10 in file names. The result of this one change is that all programs sending output to the letter-quality printer now send their output to the dot-matrix printer. Several months later, if the customer decides to add a letter-quality printer, the only change needed would be to remove the SUBSTITUTE specification from the BRConfig.sys file.

BRConfig.sys Substitute Specifications

The general purpose of the SUBSTITUTE specification is to replace all or part of a file name or path name in commands and OPEN statements before the command or statement is executed.

When applied to printer control, the SUBSTITUTE specification can change printer output to any other local printer spooled printer or file. SUBSTITUTE can be executed from BRConfig.sys when entering Business Rules, it can also be executed as part of the CONFIG command.

For example, suppose a system has a standard printer connected to PRN: (LPT1:) and another printer attached to LPT2:. If the standard printer is broken, or has a lot of jobs waiting to print, the following command could transfer standard printer output from device PRN: to the printer attached to device LPT2 for all subsequent printer opens:

CONFIG SUBSTITUTE PRN:/10,LPT2:

Whenever LPT2: is set up for spooling by your operating system, as is common for IBM NetWorks, the above command causes Business Rules to produce spooled output. To make this same change from within a program, perhaps based on an operator's response, the CONFIG command can be executed by the EXECUTE statement. For example:

100 EXECUTE "CONFIG SUB PRN:/10,LPT2:"

OPEN statements with just PRN: are syntactically acceptable, but can cause problems for printer substitutions, especially when other OPEN statements (in the same program or different programs) explicitly code printer classes with names like PRN:/12. SUBSTITUTE PRN:,PRN:/11 works fine for OPEN statements with just PRN:, but if you also have references to PRN:/12 in your code, then the same SUBSTITUTE will change PRN:/12 to PRN:/11/12. We discourage the use of plain PRN: to avoid these types of problems with SUBSTITUTE. Using PRN:/10 instead of just PRN: eliminates these SUBSTITUTE problems.

There are two conditions in which SUBSTITUTE does not apply. The default class of 10 is added to a plain PRN: specification after file name substitution processing, thus automatically translating PRN: to PRN:/10. The second case is that //10 (a System/23 convention) is also converted to PRN:/10 after file name substitution processing; this means that you must specify a separate SUBSTITUTE specification for //10 if you wish to redirect this printer output to a non-default printer. (The other System/23 convention, device //11, is translated to AUX:).

Once a file is opened, STATUS FILES or FILE$(file-num) will reveal the full path name of the file or device actually opened. FILE$ without a parameter returns the file name of the last attempted open that was in error; this can be used to debug file name substitutions.

Use of class printers

Whenever OPEN statements are added to a program to access a printer (even on single-user systems), we recommend that you use a printer name of the form PRN:/xx where xx is a two-digit class number. This will standardize your printer names and make it easy to use the SUBSTITUTE specification to redirect printer output wherever you want.

On single-user systems, class is ignored. More specifically, all substitutions are processed, then any remaining "/xx" in "PRN:/xx" is discarded leaving simply PRN:. This means no SUBSTITUTE specifications are required to consolidate printer names. However, we still recommend coding multiple printer classes.

00100 OPEN #255:"name=PRN:/10",DISPLAY,OUTPUT
00120 OPEN #120:"name=PRN:/20",DISPLAY,OUTPUT ! letter quality

For example, the above two OPEN statements could still be rerouted to two different local printers using the following SUBSTITUTE specification:

SUBSTITUTE PRN:/20,COM2:

Without the SUBSTITUTE specification on a single-user system, lines 100 and 120 above would both ignore the class information and device PRN: would have intermixed output from PRINT statements using the two file numbers.

On multi-user systems, the class parameter can be very useful because there may be several printers, including more than one type or class of printer. A multi-user system might have three dot-matrix printers, a letter-quality printer, and a laser printer. We recommend the following standards for printer class names:

10-19 primary high speed printers
20-29 letter-quality printers
30-39 laser printers

Use the above class numbers in your programs as if all the printers exist. Then when installing your software at customer sites, if the customer only has one class 10 printer on a multi-user system, insert the following in the BRConfig.sys file:

SUBSTITUTE /20,/10
SUBSTITUTE /21,/10
SUBSTITUTE /30,/10  ! .. and so forth

This will substitute or replace all program class references in file names with the operational class /10. This set of substitutions is not necessary on single- user systems because class is ignored.

Some Unix / Linux programmers may remember that some Unix / Linux releases before 3.0 allowed printer redirection using a name format of PRN:report/class to allow a different name for each report. In 3.0, the report name is ignored. It may be supported in future releases when additional print spooling capabilities are implemented.

The reason for currently ignoring report name is that it sometimes caused problems when using SUBSTITUTE specifications to redirect printer output. If you had a system with many reports and each report had a different PRN: specification with an embedded report name, then it was difficult to get a single SUBSTITUTE specification to redirect all of your reports to another printer. SUBSTITUTE /10,/11 would usually work, but not if you also made use of //10 as a printer name. Therefore, Business Rules has been changed to ignore the report name because it discouraged the use of standard printer names. In future releases, when report name is re-activated, additional substitution options will be provided.

When printing the screen, operators should use Ctrl-P (see APPENDIX E for more information about this key function). Ctrl-P uses Business Rules SUBSTITUTE specifications to redirect output to the desired printer. Screen-printing initiated by the PrtSc key is outside Business Rules control. PrtSc output will be sent to LPT1: where the outcome depends on how the operating system treats LPT1: and whether it is spooled or local. On single-user systems, if there is no printer on LPT1:, there will be no PrtSc output; but if SUBSTITUTE has been used to change PRN:/10 printer output to COM2:, then Ctrl-P will print the screen t o COM2. Since operators at NetWork workstations have no immediate control over how LPT1: is assigned, using Ctrl-P is preferred for NetWorks because Business Rules does have control over Ctrl-P output and can direct the output appropriately.

Novell NetWork Printer Support

On a Novell NetWork version of Business Rules, a file-ref that begins with PRN: will always designate spooled printer output unless the PRN: has been mapped to something else through a SUBSTITUTE specification. For local printer support, use a SUBSTITUTE specification that will map one or more PRN: specifications to a DOS device name:

SUBSTITUTE PRN:/11,LPT2:

The last digit of the class number specifies the Novell spooled printer number that you want the job sent to. Class 10 goes to printer 0, class 21 goes to printer 1, and so on. Using the first-digit of the class is still recommended for portability and readability (e.g., classes 10-19 for dot-matrix printers, classes 20-29 for letter-quality printers, etc.). SUBSTITUTE specifications can be used to change class numbers at Installation time. Class numbers can also be changed at execution time with the CONFIG command.

Business Rules creates its own disk files for spooling. The file names are formatted as follows: WSPOOLww.xxwhere ww is the workstation ID and xx is the first number between zero and 99 that makes the file name unique. No leading zeroes are included in ww or xx. While the printer file is open, the STATUS FILES command will show a name similar to:

PRN:/10 C:\WB\WSPOOLww.xx

Business Rules creates this file in the current directory without a leading path name. If using the default directory becomes a problem, then you can direct Business Rules to use a consistent directory for Novell spool files by using a SUBSTITUTE specification like the following:

SUBSTITUTE WSPOOL,C:\WBSPOOL\SPOOL

This will replace the WSPOOL in WSPOOLww.xx so that the file opened will be C:\WBSPOOL\SPOOLww.xx; thus, all spool files will be created in the C:\WBSPOOL directory.

The Novell spooler requires that these files be located on a sharable drive and that the user has both open and read permissions for the file. If either one of these conditions is not met, then Business Rules will return error code 4205 (access denied) when the printer file is closed. The disk file will be closed successfully and will remain intact on the default drive, but the file will not be sent to the printer.

In summary, OPEN file names are processed by the active list of SUBSTITUTE specifications. If after that processing, the name begins with PRN:, a spool file is created. The spool file name is also processed against the SUBSTITUTE list before the file is created.

IBM NetWork Printer Support

On the file server, use the IBM NetWork NET SHARE command to designate which ports on the server (LPT1:, LPT2:, etc) should be reserved for spooled (sharable) printers.

NET SHARE SPRINT=LPT1  ! Server LPT1: is spooled printer

On the workstations, use the NET USE command to designate which ports on the workstation should be logically connected to the spooled printers.

NET USE LPT2 \\SERVER\SPRINT ! workstation spooled printer

For each node on the NetWork (including the server) uses the Business Rules SUBSTITUTE specification to map PRN: names to the devices you would like to use.

SUBSTITUTE PRN:/11,LPT3: ! workstation local printer
SUBSTITUTE PRN:/10,LPT2: ! workstation spooled printer

When the printer is open, the STATUS FILES command or the function FILE$(file-num) will show the device name that PRN: has been mapped to.

Background Processing

Business Rules can now run as a background task on Unix and Xenix versions. The background mode capability allows you to run any Business Rules code that does not require keyboard interaction. Since the code runs in the background, you can run another process in the foreground at the same time.
To initiate background mode processing, be sure Business Rules is loaded as another session, then start the background Business Rules with one of the following commands:

BR "proc procname" -wsid >output.fil &

or

BR "run progname" -wsid >output.fil &

A new Unix session will be started in which Business Rules will begin executing the specified procedure or program without occupying the screen. All output that would normally be sent to the screen, including control codes, will instead be sent to the specified output file. Business Rules will remain active until it enters READY mode or until it encounters any need for input (including an error) from the keyboard, at which time it will automatically terminate.

If you must terminate the background process before it completes executing, use the Unix/Xenix kill and ps commands. See also (in your Unix documentation) the sh command's & parameter for information on initiating new processes.

If you are starting two or more background Business Rules processes in succession and the applications use the same files, you need to be aware that the second process can "overtake" the first since it does not have to reload code in memory. This may introduce file sharing problems which did not exist when the programs were run from two separate workstations.

Introducing a delay between starting the first and second processes will solve this problem. If two simultaneously executing applications do not share files, you should not experience this problem.