AS/400-iSeries Starter Kit

Getting a handle on AS/400 file types can be puzzling. If you count the various types of files the AS/400 supports, how many do you get? The answer is five. And 10. The AS/400 supports five types of files — database files, source files, device files, DDM files, and save files. So if you count types, you get five. However, if you count the file subtypes — all the objects designated as OBJTYPE(*FILE) — you get 10. Still puzzled? Figure 20.1 lists the five file types that exist on the AS/400, as well as the 10 subtypes and the specific CRTxxxF (Create xxx File) commands used to create them. Each file type (and subtype) contains unique characteristics that provide unique functions on the AS/400. In this chapter, I look at the various types of files and describe the way each file type functions.

Structure Fundamentals

If there is any one AS/400 concept that is the key to unlocking a basic understanding of application development, it is the concept of AS/400 file structure. It's not that the concept is difficult to grasp; it's just that there are quite a few facts to digest. So let's start by looking at how files are described.

On the AS/400, all files are described at four levels (Figure 20.2). First is the object-level description. A file is an AS/400 object whose object type is *FILE. The AS/400 maintains the same object description information for a file (e.g., its library and size) as it does for any other object on the system. You can look at the object-level information with the DSPOBJD (Display Object Description) command.

The second level of description the system maintains for *FILE objects is a file-level description. The file description is created along with the file when you execute a CRTxxxF command. It describes the attributes or characteristics of a particular file and is embedded within the file itself. You can display or print a file description with the DSPFD (Display File Description) command.

The file subtype is one of the attributes maintained as part of the file description. This allows OS/400 to present the correct format for the description when using the DSPFD command. This also provides OS/400 with the ability to determine which commands can operate on which types of files. For instance, the DLTF (Delete File) command works for any type of file on the system, but the ADDPFM (Add Physical File Member) command only works for physical files. OS/400 uses the description of the file to maintain and enforce each file's object identity.

The third level of descriptive information the system maintains for files is the record-level description. This level describes the various, if more than one, record formats that exist in the file. A record format describes a set of fields that make a record. If the fourth level of description — field descriptions — is not used when creating the file, the record format is described by a specific record length.

All files have at least one record format, and logical files can have multiple record formats (we'll cover this topic in a future chapter). Applications perform I/O by using specific record formats. An application can further break the record format into fields by either explicitly defining those fields within the application or by working with the external field definitions if they are defined for a record format. While there is the DSPOBJD command and the DSPFD command, there is no Display Record Description command. You use the DSPF command and the DSPFFD (Display File Field Description) command to display or print the record-level information.

The final level of descriptive information the system maintains for files is the field-level description. Field descriptions do not exist for all types of files; tape files, diskette files, DDM files, and save files have no field descriptions because they have no fields. (In the case of DDM files, the field descriptions of the target system file are used.) For the remaining files — physical, logical, source, display, printer, and ICF — a description of each field and field attribute is maintained. You can use the DSPFFD command to display or print the field-level descriptions for a file.

Data Members: A Challenge

Now that you know how files are described, you need a challenge! We now need to consider a particular organizational element that applies only to database and source files, the two types of files that actually contain records of data. You may be saying, "Wait, you don't have to tell us that. Each file is described (as discussed), and each file has records, right?"

I wish it were that simple, but on the AS/400 there is an additional element of file organization, the data member, that has caused even the best application programmers to cry in anguish, just as Martin Luther did, until they discover the truth. Now that I have your attention (and you're trying to remember just who Martin Luther was — look under Church History: The Reformation), I will impart the truth to you and save you any future anguish.

Examine Figure 20.3, which introduces you to the concept of the file data member. You traditionally think of a file containing a set of records, and usually an AS/400 database file has a description and a data member that contains all the records that exist in that database file. If you create a physical file using the CRTPF (Create Physical File) command and take the defaults for member name and maximum number of members, which are MBR(*FILE) and MAXMBRS(1), respectively, you will create a file that contains only one data member, and the name of that member will be the same name as the file itself.

So far, so good. Now comes the tricky part. Believe it or not, AS/400 database and source files can have no data members. If you create a physical file and specify MBR(*NONE), the file will be created without any data member for records. If you try to add records to that file, the system will issue an error stating that no data member exists. You would have to use the ADDPFM command to create a data member in the file before you could add records to the file.

At the other end of the scale is the fact that you can have multiple data members in a file. A source file offers a good example.Figure 20.4 represents the way a source file is organized. Each source member is a different data member in the file. When you create a new source member, you are actually creating another data member in this physical source file. Whether you are using PDM (Programming Development Manager) or SEU (Source Entry Utility), by specifying the name of the source member you want to work with, you are instructing the software to override the file to use that particular member for record retrieval.

Consider another example — a user application that views both current and historical data by year. Each year represents a unique set of records. This type of application might use a database file to store each year's records in separate data members, using the year itself to construct the name of the data member. Figure 20.5 represents how this application might use a single physical file to store these records. As you can see, each year has a unique data member, and each member has a various number of records. All members have the same description in terms of record format and fields, but each member contains unique data. The applications that access this data must use the OVRDBF (Override with Database File) command to open the correct data member for record retrieval.

Wow! No database members... one database member... multiple database members... Why? That's a fair question. Using multiple data members provides a unique manner to handle data that uses the same record format and same field descriptions and yet must be maintained separately for business reasons. One set of software can be written to support the effort, but the data can be maintained, even saved, separately.

Having sorted through the structure of AS/400 files and dealt with data members, let's look specifically at the types of files and how they are used.

Database Files

Database files are AS/400 objects that actually contain data or provide access to data. Two types of files are considered database files — physical files and logical files. A physical file, denoted as TYPE(*FILE) and ATTR(PF), has file-, record-, and field-level descriptions and can be created with or without using externally described source specifications. Physical files — so called because they contain your actual data (e.g., customer records) — can have only one record format. The data entered into the physical file is assigned a relative record number based on arrival sequence. As I indicated earlier, database files can have multiple data members, and special program considerations must be implemented to ensure that applications work with the correct data members. You can view the data that exists in a specific data member of a file using the DSPPFM (Display Physical File Member) command.

A logical file, denoted as TYPE(*FILE) and ATTR(LF), is created in conjunction with physical files to determine how data will be presented to the requester. For those of you coming from a S/36, the nearest kin to a logical file is an index or alternate index. Logical files contain no data but instead are used to specify key fields, select/omit logic, field selection, or field manipulation. The key fields serve to specify the access paths to use for accessing the actual data records that reside in physical files. Logical files must be externally described using DDS and can be used only in conjunction with externally described physical files.

Source Files

A source file, like QRPGSRC where RPG source members are maintained, is simply a customized form of a physical file; and as such, source files are denoted as TYPE(*FILE) and ATTR(PF). (Note: If you work with objects using PDM, physical data files and physical source files are distinguished by using two specific attributes — PF-DTA and PF-SRC.) All source files created using the CRTSRCPF (Create Source Physical File) command have the same record format and thus the same fields. When you use the CRTSRCPF command, the system creates a physical file that allows multiple data members. Each program source is one physical file member. When you edit a particular source member, you are simply editing a specific data member in the file.

Device Files

Device files contain no actual data. They are files whose descriptions provide information about how an application is to use particular devices. The device file must contain information valid for the device type the application is accessing. The types of device files are display, printer, tape, diskette, and ICF.

Display files, denoted by the system as TYPE(*FILE) and ATTR(DSPF), provide specific information relating to how an application can interact with a workstation. While a display file contains no data, the display file does contain various record formats that represent the screens the application will present to the workstation. Each specific record format can be viewed and maintained using IBM's Screen Design Aid (SDA), which is part of the Application Development Tools licensed program product.

Interactive high-level language (HLL) programs include the workstation display file as one of the files to be used in the application. The HLL program writes a display file record format to the screen to present the end user with formatted data and then reads that format from the screen when the end user presses Enter or another appropriate function key. Whereas I/O to a database file accesses disk storage, I/O to a display file accesses a workstation.

Printer files, denoted by the system as TYPE(*FILE) and ATTR(PRTF), provide specific information relating to how an application can spool data for output to a writer. The print file can be created with a maximum record length specified and one format to be used with a HLL program and program-described printing, or the print file can be created from external source statements that define the formats to be used for printing. Like display files, the print files themselves contain no data and therefore have no data member associated with them. When an application program performs output operations to a print file, the output becomes spooled data that can be printed on a writer device.

Tape files, denoted by the system as TYPE(*FILE) and ATTR(TAPF), provide specific information relating to how an application can read or write data using tape media. The description of the tape file contains information such as the device name for tape read/write operations, the specific tape volume requested (if a specific volume is desired), the density of the tape to be processed, the record and block length to be used, and other essential information relating to tape processing. Without the use of a tape file, HLL programs cannot access the tape media devices.

Diskette files, denoted by the system as TYPE(*FILE) and ATTR(DKTF), are identical to tape files except that these files support diskette devices. Diskette files have attributes that describe the volume to be used and the record and block length.

ICF (Intersystem Communications Function) files, denoted by the system as TYPE(*FILE) and ATTR(ICFF), provide specific attributes to describe the physical communications device used for application peer-to-peer communications programming. When a local application wants to communicate with an application on a remote system, the local application turns to the ICF file for information regarding the physical device to use for those communications. The ICF file also contains record formats used to read and write data from and to the device and the peer program.

DDM Files

DDM (Distributed Data Management) files, denoted by the system as TYPE(*FILE) and ATTR(DDMF), are objects that represent files that exist on a remote system. For instance, if your customer file exists on a remote system, you can create a DDM file on the local system that specifically points to that customer file on the remote system. DDM files provide you with an interface that lets you access the remote file just as you would if it were on your local system. You can compile programs using the file, read records, write records, and update records while the system handles the communications. Figure 20.6 represents a typical DDM file implementation.

Save Files

Save files, denoted by the system TYPE(*FILE) and ATTR(SAVF), are a special form of file designed specifically to handle save/restore data. You cannot determine the file-, record-, and field-level descriptions for a save file. The system creates a specific description used for all save files to make them compatible with save/restore operations.

Save files can be used to receive the output from a save operation and then be used as input for a restore operation. This works just as performing save/restore operations with tape or diskette, except that the saved data is maintained on disk, which enhances the save/restore process because I/O to the disk file is faster than I/O to a tape or diskette device. Save file data also can be transmitted electronically or transported via a sneaker network or overnight courier network to another system and then restored.

We have briefly looked at the various types of files that exist on the AS/400. Understanding these objects is critical to effective application development and maintenance on the AS/400. One excellent source for further reading is IBM's Programming: Data Management Guide (SC41-9658).