A physical file is the only type of file that contains data. Physical files are used for the permanent storage of identically formatted entries (each entry being a record).
To display basic information about physical files, you can run the Display File Description (DSPFD) command.
A record format is a template that defines the fields contained in each record. This template has the names of the fields, the type of data each field can contain, the maximum length of each field, and other characteristics of the fields.
To display the record format of a physical file, use the Display File Field Description (DSPFFD) command. This command can send its output either to the display or to the printer.
Physical files can contain only one record format. There are two ways to migrate multiformat files from nondatabase systems, such as the System/36, to the i5:
Use a single database file that contains a single-character field as long as the record. Define the record within your programs. This method negates the advantages of the external file definition, which is convenient to use.
Keep each record type in a separate physical file and put them together with a simple logical file. This method lets you keep the external file defi-nition, but it involves more work.
Record formats are coded using Data Description Specifications (DDS), which are described in Chapter 22.
A file is not necessarily composed of one piece. Physical files can be divided into file members. Each member of the file uses the same record format, but contains a different set of records.
For example, one member of your General Ledger file could contain the journal entries for the month of April, while another member could contain those for May. In fact, you could have a separate member for each month of the year.
You can put members to many uses, but they do have an inherent risk. Most file operations assume you want to work with the first member of the file (which is the only member if there is only one). To process any other member of the file, you have to override the file. The file override points to a different member in the file.
Picture the following scenario: Your company has several manufacturing plants, and you want to use separate members in each of the files where you keep their data. You write a program that processes several of these files. You accidentally neglect to override one of them, and your program then processes the correct information for all but one of the files. The program still reads (and possibly updates) the records in the first member instead of the correct member.
File members are a good concept, but you probably should avoid them. Instead of using multimember database files, consider using separate files in different libraries.
Physical files can be database files or source files. Database files contain information such as accounts receivable, open shop orders, hotel reservations, and the like. Database files are the types of files you would use to keep your company records.
Database files can have two different organizations: arrival sequence or keyed sequence. Arrival sequence means that records are retrieved in the order in which they are stored. Keyed sequence means that records are retrieved in an order according to the values of one or more key fields.
Here are some of the commands you can use with database files:
Create Physical File (CRTPF). Use this command to create a new physical file. You can give this command a record length (with the RCDLEN parameter) or the name of a source file member that contains the DDS for the record format.
If you use RCDLEN, the file contains only one character field, as long as the record, with the same name as the file. This is the "flat file" concept. To use this kind of file, you need to define the internal fields in each program that uses the file.
If you use DDS, the file contains the fields described in the DDS and, if the DDS describes key fields, the file is considered of keyed organization (indexed). You can't create a keyed file without DDS, except with the BLDINDEX procedure in the System/36 Environment.
When you use the CRTPF command, you also can specify how many members you want to allow as maximum (MAXMBRS parameter) and the maximum number of records (SIZE). Consider specifying SIZE(*NOMAX) for all physical files you create because it will save you headaches.
Delete File (DLTF). Deletes a file and all its members. You cannot delete a physical file if you have created logical files based on it. You must first delete all the logical files based on the physical file and then delete the physical file itself.
Clear Physical File Member (CLRPFM). Deletes all records contained in a member of a physical file.
Reorganize Physical File Member (RGZPFM). Removes all the deleted records from a physical file member and optionally resequences the records. The RGZPFM command can be run without deleting logical files that may be built on the physical file.
Change Physical File (CHGPF). Allows you to change some of the characteristics of a physical file, such as maximum number of members or records within a member.
The Change Physical File command is the fastest way to add or remove fields from records in an existing database file. Specify a source file (SRCFILE) and member (SRCMBR) that contain the new DDS specifications of the file. The file will be created based on the new specifications. Any logical files based on the database file will be automatically rebuilt as well. The existing data in the records will be retained unless you rename or remove a field name, in which case the data in the renamed field will be lost.
Add Physical File Member (ADDPFM) and Remove Member (RMVM). You can use these commands to add or remove a member in a physical file.
Rename Member (RNMM). Used to change the name of a file member.
Display Physical File Member (DSPPFM). Lets you see the records contained in a physical file member. You can send the output to the screen or the printer.
Copy File (CPYF). Use the CPYF command to copy from one file into another. If you specify TOFILE(*PRINT) or TOFILE(QSYSPRT), the CPYF command prints the list of records. CPYF has several parameters that let you select which records to copy.
If you accept the default values of the CPYF command, you will not get an exact copy of the file being copied. The FRMRCD parameter defaults to the *START value, which will cause the CPYF command to copy the file using the keyed access path of the file. If you specify a 1 in the FROMRCD parameter instead, the records will be copied in relative record number sequence, which is much faster!