The logical file format is as external as that of the physical file, so logical files can be used to redefine the record format for a program. Figure 6.1 shows a very simple example of how a program uses a logical file to give a different view of the data stored in a physical file. This example illustrates some of the functions that are available with the use of logical files.

Figure 6.1  Data and Program Independence

The example in the figure illustrates field selection. Each record in the physical file contains six fields; yet the program, through the logical file, only sees four of the fields. This ability to exclude fields from the logical file helps to enforce field-level security. Users can access only those fields they are allowed to see. This example illustrates only a small piece of how the AS/400 enforces security. We cover the topic in detail in Chapter 7.

Another function illustrated in the example is the capability to reorder the fields in the record. The positions of the gross field and the federal income tax (FIT) field in the logical record have been reversed from the way the fields are stored in the physical file. In other words, the program is independent of the order of the fields.

Still another function Figure 6.1 illustrates is the redefining or remapping of the record’s fields. The gross field in the physical file is stored as a seven-position, packed-decimal field with two positions to the right of the decimal point. The program is written, however, to expect the gross field as an eight-position, zoned-decimal field with two positions to the right of the decimal point. The logical file provides the view the program is expecting. It also provides the conversion between the packed- and the zoned-decimal formats.

The use of multiple logical files over the same physical file enables alternate access paths and data sharing for different programs. Figure 6.2 shows a second logical file for a second program that has been added to our simple example. Each program now has a different view of the records contained in the physical file, and each program can access only the fields that program is allowed to see. The fields in the two logical files that are the same allow the programs to share data.

Figure 6.2  Data Sharing

A very important point here is that each program sees the same physical data — there are no copies of the data. An update by one program is immediately seen by the other program. This capability to always have programs working on the current data, and not a copy, has been a characteristic of the System/38 and the AS/400 for almost 20 years.

Data Security

Logical files allow data to be secured at the record and field level. In the preceding examples, we saw how the field levels can be secured by omitting fields from the logical file. Not shown in our simple examples is the capability to select records. We can accomplish record-level selection with select and omit logic in the logical file. This lets users access only those records that meet the selection criteria.

If a user is not given access to a particular file, that file is secured. If a user who does not have authority to use the access path that shows gross earnings, for example, tries to run a program that uses that path, the program will fail. All logical and physical files in the AS/400 are system objects, and we need the proper authority before we can access one of these objects. Data security is accomplished with a combination of the logical files and the authorization-management component of the operating system.

For a given user who needs to access a particular physical file, we might

•  Give authority to the whole file, through authorization management

•  Give authority for certain types of file operations (e.g., read, but not update), through authorization management

•  Give authority to certain fields, using a logical file

•  Give authority to certain records, using a logical file

Data Integrity and Recovery

Integrity of the data in the database is crucial for any business. With multiple users accessing and changing the data simultaneously, it is possible for data to be corrupted. The AS/400 database provides several facilities to ensure data integrity.

Recovery facilities are also necessary in case something does happen either to corrupt the data or to make it unavailable. Several things that require some form of database recovery can happen in a system. We often think recovery is needed only because the hardware may fail. The AS/400 even has several functions to prevent the need to recover when there is a hardware failure; we usually call these availability functions. While hardware failures may be the most common reason for database recovery, programs also can fail, resulting in the need for recovery.

A complete discussion of data integrity and recovery would fill a book. In this section, we can only introduce and discuss briefly the facilities the AS/400 database provides. Later in the chapter, we will see how some of these facilities are implemented in the machine.

Journaling

A journal is a chronological record of changes made to a set of data. The purpose of a journal is to provide a means to reconstruct a previous version of the set of data. Several types of journaling are supported in an AS/400, including database journaling. When a change is made to a record in a database file that is being journaled, a copy of the record is written to the journal, along with information describing the cause of the change.

Two OS/400 objects support journaling. One is a journal, and the other is a journal receiver. The journal identifies which objects are to be journaled. The journal receiver contains the journal entries. Journal receivers can be written immediately to disk for safekeeping.

Each journal entry contains several pieces of information. Some of this information includes the file name, the library name, the program name, the relative record number, the time, and the date. The entry also has the job identification, the user, and the workstation. The copy of the changed record is written to the journal receiver along with this information. As an option, the AS/400 also can write a copy of the record before the change is made.