HLI: Model 204 files and records

Overview

This topic describes basic Model 204 database structures, that is, files and records, for application programmers who are using the Host Language Interface facility.

For more information about files and records, see File design and Introduction to User Language.

Data files

A Model 204 file is a collection of records. Prior to version 7.5 of Model 204, a file could contain as many as 16.7 million records. With the FILEORG X'200' setting, available as of Model 204 V7.5, this upper limit increases to 48 million. The maximum number of files that can be accessed in one Model 204 job is 32,767.

Model 204 files have an inverted file structure, which means that they contain, in addition to the data records themselves, an index that points to records containing particular values of fields designated as retrieval or KEY fields. The index and data areas are physically separate parts of the file.

The data representation of an inverted file format is similar to the organization of a reference book such as Bartlett's Familiar Quotations. The main body of the book, that is, the data area, consists of groups of quotations. To help you find the quotations, the book provides an index that contains subject entries for as many subjects as are pertinent to the quotation, interspersed with title and author entries for a poem, speech, or other work.

The following Model 204 file types determine how data is stored:

Entry order
Unordered
Sorted
Hash key

You can use the four file types in any combination to make up a database. Each type of organization provides the inverted file capability, and any Model 204 file can be cross-referenced to any other Model 204 file.

The following sections briefly describe the different types of data files. For more information, see Choosing a file organization.

Entry order file

In an entry order file, Model 204 stores each new record in the next available space. During processing, Model 204 retrieves and processes the records in file storage order. Usually, the order is chronological.

Note: Entry order files are the most widely used Model 204 files. Entry order files provide all inverted file capabilities except unordered, sort, and hash key. To generate sorted output when processing entry order files, use the IFSORT call.

Unordered file

In an unordered file, Model 204 stores new records in any location where enough space is available to hold the records. Model 204 maintains for an unordered file a queue of pages with available space. When records are deleted, storage space becomes available. Model 204 uses pages from the queue to store new records.

When using unordered files, note that these files utilize disk space more efficiently if you delete records frequently in your HLI application.

Sorted file

When you specify the sorted file option and designate one field in a file as the sort key, the file is a sorted file. Model 204 uses an indexed sequential scheme for a sorted file, storing and processing records according to the values of the sort key.

Specify the sorted file option when creating the file, and designate the sort key field at file initialization. You can designate the sort key field as either mandatory or optional. When a sort key field is mandatory, Model 204 requires all records to contain this field. When the sort key field is optional, Model 204 accepts records in the file that do not contain the field.

You can retrieve records in a sorted file with a combination of special sort key retrieval conditions and the standard key field value conditions. Sorted files are useful for applications that produce many reports in the same sort sequence.

Hash key file

When you specify the hash key option and designate a particular field name as the hash key, the file is a hash key file. Specify the hash key file option when creating the file, and designate the hash key field at file initialization. Model 204 stores records in locations based on the value of the designated hash key. You can designate the hash key field as either mandatory or optional.

For example, you might designate SOCIAL SECURITY NUMBER as the hash key. You can then retrieve records on the basis of this key without performing an index search.

Note: Use a hash key file if all data records contain a unique or fairly unique key and if your HLI application performs most retrievals on the basis of that key alone.

File groups

A file group is a named collection of Model 204 files that Model 204 treats logically as a single file.

For example, you might define the file group BANK containing the files CHECKING, SAVINGS, and CARLOAN. Each file is accessible directly and is called by its own name (CHECKING, SAVINGS, and CARLOAN). All data in the three files is also available under the name BANK. Model 204 does not duplicate the data. Instead, a special table relates the group BANK to its member files.

You can define any number of file groups. File groups can have overlapping membership.

For example, nine individual state files can be processed as members of a file group, SOUTH, which represents a particular regional area. The same files can also be processed as members of a file group, USA, which represents the entire United States.

File groups are particularly useful for processing under the following conditions:

Regrouping and archiving files in aging data applications
Providing alias names for test and production files
Processing similar data that must be maintained in independent files

See Storing and using file group definitions (CCAGRP) for more information.

File model options

The following file models allow you to enforce filewide constraints on files and fields. To specify a file model, set the FILEMODL parameter when creating the file:

The NUMERIC VALIDATION file model, which causes Model 204 to perform numeric data type validation on fields defined as FLOAT or BINARY.
The First-Normal Form (1NF) file model, which ensures that the data within a file conforms to the rules for 1NF.

See FILEMODL parameter for more information.

Records

A record is a combination of related data fields that are defined in a Model 204 file. Records are variable in length and format. Model 204 does not restrict records to any predefined or fixed structure.

The structure of a Model 204 record does not limit the number of occurrences of a field in a record. Fields that appear more than once in a record are known as multiply occurring fields.

To save space under some conditions, a Model 204 file manager can preallocate space for occurrences of certain fields in a record. If fields are preallocated, only the specified number of occurrences can be added to a record. If fields are not preallocated, no space is reserved until data is added to the record.

Within a record, almost any number of fields can appear almost any number of times in almost any order. Within a file, the sequence and number of fields might vary from record to record.

Application programs retrieve data from Model 204 files strictly on the basis of individual field names and values. Therefore, applications are independent of the physical structure of the files and are not affected by changes or additions to the database.

See Record (File architecture) for more information.

Internal database record number

Model 204 uniquely identifies every record in the database by its file name and its internal record number. Each record in a file remains associated with a unique record number until the file is reloaded or until the record is deleted and its number reused by a new record.

Current record and the current file

During HLI job processing, Model 204 maintains information that identifies the current record, using the CURREC parameter, and the current file, using the CURFILE parameter.

No current record

On a single cursor IFSTRT thread, certain HLI calls set CURREC to -1, which is an invalid internal database record number, to indicate that there is no current record on the thread. Upon completion, the following HLI calls set CURREC to -1:

IFDREC
IFDSET
IFINIT
IFOPEN

Current record on a multiple cursor IFSTRT thread

On a multiple cursor IFSTRT thread, Model 204 assigns a value to CURREC, which is the internal database record number of the current record in the open cursor that was referenced in the call just processed.

Note that a cursor has no current record associated with it until one of the following HLI calls executes successfully and positions the cursor:

IFFTCH
IFFRN
IFSTOR

Once the open cursor is positioned at the current record, the HLI application can perform individual record processing functions. Any of the individual record HLI calls allowed on a multiple cursor IFSTRT thread can process the current record by referencing the name of the open cursor in the call.

Current record on a single cursor IFSTRT thread

On a single cursor IFSTRT thread, the CURREC value is the internal database number of the current record relative to the last set created for the last file opened on the current thread.

The current record is the one last referenced by IFGET, IFPOINT, or IFBREC.

Specifying a record number

Use the following calls to specify a particular record number:

IFFRN, specifying the cursor name, on a multiple cursor IFSTRT thread.
Note: IFFRN opens a cursor to the current record.
IFPOINT on a single cursor IFSTRT thread.

The record specified in the HLI call becomes the current record for processing.