Internal Files

From BR Wiki
Jump to: navigation, search

For most business applications, internal files are the most frequently used type of file. See also Open Internal.


The first record of every internal file is a header record which "remembers" the record length and other important information about the file.

Each record after the header record begins with a system-controlled byte used to mark records for deletion (see the -D option of the Copy command for information about removing records marked for deletion). As long as internal files are always processed as internal files, the header record and the delete byte are transparent to the programmer. Internal files use fixed-length records with no record delimiter.

Viewing the contents

The best way to see the contents of an internal file with a Business Rules program is to read the file and print its information in a formatted report that is visually meaningful (e.g., a new line for each record, spaces between fields, special numeric formats converted to ASCII digits, etc.).

Although it is possible to use the Type command to view the full contents of an internal file, the output is often unreadable due to lack of record delimiters and the presence of unprintable (non-displayable) characters where special numeric formats such as packed decimal are used. External files are similarly unreadable, but display files may easily be viewed in their entirety.

Use with SORT and INDEX

Internal files are the only type of file that can be used with Business Rules SORT and INDEX (ISAM) facilities. Data which is used for input to either the SORT or INDEX commands must be stored in internal files. Likewise, SORT or INDEX output files and the sort control file must be internal files.

File I/O

Internal files may be opened for INPUT, OUTPUT and OUTIN (which is a combination of input and output). Individual records or portions of individual records are easily updated by opening the file OUTIN. Sequential, relative, or keyed access methods can be used.

The statements that can be used for input from internal files are READ and REREAD. Output to internal files is accomplished with the WRITE and REWRITE statements. Records can be marked for deletion (made inactive) with the Delete Statement. The RESTORE file statement can reposition the file pointer to the beginning of the file or to a specified record.

Internal files provide several space-saving formats for storing numbers including binary (BB Format Specification), double- precision floating point (DD Format Specification), single-precision floating point, packed decimal (PD Format Specification), zoned decimal (ZD Format Specification), and (for S/23 compatibility only) long numeric floating point (LL Format Specification). See Format Specifications for more information about these and other formats that are available with internal files.

Version 3.9+ enables NFS and NetBui network record and file locks up to 2GB. However, versions 4.13+ supports larger files (exceeding 2GB) when OPTION 33 is specified. These larger files are NOT supported by NetBui which uses 30 bit record locking. Therefore use the client server model if you need to use NetBui with large files. See BRConfig.sys and Record Locking for more information.

Linked Files

Business Rules now supports LINKED files, which are Business Rules internal files that contain one or more sets of linked records. When their use is appropriate, linked files can be much faster than indexed files (probably two to three times as fast), and they require less overhead.

Program performance does not degrade when they increase in size. Also, records may be inserted at any point in a linked list.

However, two potential drawbacks are that corrupted link list files can be difficult to rebuild in the correct order. Also, there is no way to identify the order in which linked records are added to the file because of the way the system handles deleted records in linked list files.

Linked files are most useful for situations where you wish to attach a group of records to a master record, and the only way you will ever want or need to access those records is through the master record. An example usage is a customer maintenance program that allows the user to keep notes (up to 15 lines of 50 characters each) about each customer.

The following terms will be used to describe the operation and structure of linked files:

1.) {\b Linked file} - A file that is opened LINKED, INTERNAL. This file will ultimately contain one or more linked lists.
2.) {\b Linked list} - An entire set of linked records. A single linked file will usually contain several linked lists.
3.) {\b Linked list record} - Any record in a linked list, regardless of its position within that list. The first eight bytes of each linked list record are reserved for two fields:
(a) The next record pointer (positions 1-4)
(b) The previous record pointer (positions 5-8).

These are maintained by Business Rules and must not be overwritten by the program. While they are normally ignored, the program can access them with a statement such as the following:


Next record pointer - Positions 1 through 4 of each linked list record, which identify the next record in the linked list. If this pointer is set to 0, the record is the last one in the linked list. This pointer position is maintained by Business Rules and must not be overwritten by the program.

Previous record pointer - Positions 5 through 8 of each linked list record, which point to the previous record in the linked list. If this pointer is set to 0, the record is the first one (the anchor record) in the linked list. This pointer position is maintained by Business Rules and must not be overwritten by the program.


The first record in a linked list, and the basis for accessing linked list data from the master record. The record number of this anchor point should always be written out to the master file after the list is updated. (If an anchor record has been processed, KREC will return the record number of the anchor record for the current linked list, even if the file pointer is positioned at another record in that list.) The previous record pointer (positions 5-8) of an anchor record will always be set to 0.


The second and additional records in a linked list. The last record in a linked list will have a next record pointer of 0.

The following Business Rules instructions play important roles in the use of linked files:


OPEN internal now accepts the LINKED keyword, which specifies that the file to be opened consists of linked lists.
Also see Open Internal


In linked files, the RESTORE file statement plays two important roles.

1.) It can be used with the REC= parameter to reposition the file pointer to any specified record number.
2.) The next role of RESTORE is that it can be used without parameters to create a new anchor point for a linked list that you wish to add or insert.

Also see Restore File


The READ file statement now accepts the LINK=string parameter for Verifying that linked records belong to a master. It can be used only on LINKED files that have been opened using the KPSI7E4W2= and KLNE2E4W2= parameters
Also see Read file.


The WRITE statement may be used to insert a record into an existing linked list. (A linked list is not considered to be "existing" unless an anchor point has been established for it with a RESTORE statement.)
Also see Write.


The DELETE statement may be used to delete any anchor record or sub-record from a linked list. If REC= is not specified, the DELETE statement must be preceded by a successful READ of the record to be deleted.
Also see Delete Statement.

KREC(filenbr) function

KREC will return the record number of the most recently processed (read or written) anchor record.
Also see Krec(filenbr) in the Functions section.


The following error codes are specific to LINK. For full descriptions see each code individually.

4282 Data does not match LINK=

4283 Error in updating previous/next link

0606 Invalid element in OPEN

0702 File not opened KEYED or LINKED

0718 Key length conflict