For most users, only one user file group is required or useful. For details on all file groups, refer to Support for File Groups.
Default System Files
One system file is always present in the RAM file system in Group 1:
NOTE The RealView®manuals use the .out suffix for what the Verix V calls the .odb file. The RealView naming convention is avoided on Verix V-based products as other VeriFone products and tools traditionally use .out to denote executable program files. See the Verix, V Operating System Programming Tools Reference Manual for more information on the RealView compiling and debugging tools.
CONFIG.SYS Contains all environment variables used by the primary application.
FILE MANAGEMENT
Default System Files
User files are created, renamed, and deleted by the executing application program, as required. Verix V does not impose limits on the number of user files that can be created. However, expansion is limited by RAM availability.
.out Files When downloading .out files, it is important that the terminal performs a soft reset to enable execution of the newly downloaded .out file. Call the SVC_RESET or SVC_RESTART routine to perform a terminal reset.
File Handles In addition to opening any or all devices, applications can simultaneously open up to 30 user files.
It is possible, and occasionally useful, to open the same file more than once before closing it. Multiple file handles allow you to maintain multiple position indicators (seek pointers) within the file. Note that the limitation on the number of open files is based on the number of open handles, regardless of whether two handles happen to represent the same file. This limitation is system-wide. For example, if two applications each have nine files open, then a third application can open no more than twelve files. You can change the maximum value using the CONFIG.SYS variable *FILE, which can have a value between 10 and 224, default is 30.
Generic Files Generic files can contain any type of data, making them especially suitable for binary data. Data is accessed by byte address within the file so that any quantity of data can be read or written at any time, from any location within the file. In most applications, a fixed record length is used, typically based on the size of a data structure or union. With careful planning, VLR files can also be used.
Typically, a generic file has a static record size determined by the total amount of space used by a data structure such as:
typedef struct MyRecord MYRECORD;
NOTE It is strongly recommended that the application never attempt to use all “available”
memory, since a certain amount of “slack space” is needed for efficient operation.
A rule of thumb is to plan on leaving 10% of the total memory unused.
NOTE
To ensure that .out files execute after downloading, perform a terminal reset.
Default System Files
Each record in the file is defined by the structure MyRecord; the record length is simply the size of the structure, defined by the constant MyRecLen. Using generic files with variable-length records is discussed below.
Variable-Length Record (VLR) Files
VLR files allow data to be stored as records. The first byte in each record is a count byte (the number of bytes in the record, including the count byte), followed by data. Each record can have a maximum length of 254 data bytes.
VLR files are particularly suited to ASCII data and can contain arbitrary data, including embedded NULL characters. Data is accessed by record number rather than byte address, and requires that the file be processed from the beginning (first record, then subsequent records searched, until the correct record is found).
VLR files are best suited for chronologically sequenced records with little or no random access requirements.
Compressed Variable-Length Record (CVLR) Files
CVLR files are identical to VLR files with the addition of a compression algorithm applied to the data on reads and writes. This compression converts lowercase characters to uppercase, and stores numeric values (ASCII 0–9) as four bits. The compression and expansion of each record is handled by the file system and is transparent to the application.
Keyed Files Keyed files (also called paired files) are essentially CVLR files that use two records for every data record written. The first record (called the key) is followed by a data record. The key gives the data record an alphanumeric name or identifier, providing random access to the records. Keyed file access is considerably slower than VLR or CVLR files, as two records must be read for each data entry and a comparison of the key performed. From a timing performance perspective, keyed files are the least desirable.
Keyed files do have appropriate uses however. Since keyed files can be edited through the terminal keypad, they are ideal for holding data that requires
modification, such as download parameters (telephone numbers and terminal ID), and customer-specific information, such as a customer address.
The CONFIG.SYS file is a keyed file that can hold downloaded parameters and can be accessed from system mode using the EDIT menu selection.
NOTE Byte values greater than 0x5F cannot be correctly translated when this
compression is used and should not be included in the file. Access time for CVLR files is somewhat slower than for VLR files. File space savings are especially noticeable on data files containing a lot of numeric data stored as ASCII characters.
FILE MANAGEMENT
Default System Files
Keyed files can also create a database where information could be located by a key, such as an account number. Care must be taken when using keyed files in applications where speed and performance are critical.
The following system calls operate on keyed files:
• get_env()
• put_env()
• getkey()
• putkey()
Verix V File