Program-Described files - As the name suggests, program-described files are described entirely inside the RPG program; that is, the record layout must be detailed in the program source itself. 

By Brian Meyers and Jim Buck

Editor's Note: This article is excerpted from chapter 3 of Programming in ILE RPG, Fifth Edition.

Declaring a file as a program-described file prevents the compiler from retrieving the record layout or other file attributes from an external file description. Instead, the program uses two fixed-format specification types to provide the record layout: Input specifications and Output specifications.

Most programmers prefer to use externally described files, but if you must maintain a program written before that feature was available, you need to understand how the program works. Even today, it’s possible that a program-described file is appropriate; for example, if you are processing a flat file (i.e., one that is not parsed into individual fields), you will probably declare it as a program-described file. Let’s look at a version of the example program that uses program-described files. In addition to including Input and Output specifications, this program also makes some necessary changes to the File specifications and Calculation specifications. You can compare this variation with the one in Chapter 2, which uses externally described files.

File Specifications

To use program-described files in an RPG program, you must first make a few changes to the File specification:

The first significant change is in position 22 (labeled F on the ruler line); this entry designates the file format. An F in position 22 stands for fixed format, which means that this is a program-described file and that each record has the same fixed length. This entry is the trigger that signals a program-described file. All files, regardless of type, require an entry for file format—either an F for program-described files or an E for externally described files.

You define the record length in positions 23–27 (Rlen+) for each program-described file. Data file records can be any length from 1 to 99,999 bytes, but it is important that you code the correct value for this specification. When you compute the lengths of all the fields in Customers, you get a length of 145 bytes, so you enter 145, right-adjusted in positions 23–27. Most printers support a line of 132 characters. As a result, records of printer files (which correspond to lines of report output) are usually 132 positions long. Accordingly, output file Qprint is assigned a record length of 132 on its File specification. Qprint is an IBM-supplied printer file, one of several that are typically used for program-described reports. Externally described files do not require—indeed, do not allow—a record length entry because the compiler retrieves the correct length.

The other change you may notice in the F-spec for Qprint is the use of an IBM-supplied indicator for overflow. You could have used a named indicator (e.g., Endofpage) as in the earlier program. But most programs that use program-described printer files tend to use any of eight indicators built into RPG: OA, OB, OC, OD, OE, OF, OG, and OV. You code these indicators as *INOA, *INOB, and so on. Because these indicators are already a part of RPG, you need not further define them. These indicators work only with program-described files. For externally described files, use a named indicator or one of the reserved numbered indicators *IN01–*IN99. In the sample, you name indicator OF as the overflow indicator for Qprint by coding Oflind(*Inof) in the Keywords area of the appropriate F-spec.

Definition Specifications

Definition specifications define those variables that do not otherwise appear in a database file (see Chapter 2 for details about definition specifications). In this version of the program, you must use a D-spec to define the Count variable, which you use in the report. The U in position 40 (labeled I in the ruler line) indicates that Count is an unsigned integer. Entries in positions 33–39 (To/Len+) and 41–42 (Dc) specify that Count is five digits with no decimal places. Chapter 4 describes other possible entries for these positions.

Input Specifications

Fixed-format Input specifications (I-specs) describe the record layout for a program-described file. The layout includes the name of each field the program is to use, its relative location in each record, and its data attributes. Every Input specification has an I on column 6. The I-spec has no free-format equivalent:

Input specifications use two types of lines:

record identification entries, which describe the input records at a general level

field description entries, which identify the specific fields within the records

Together, these two types of lines describe the structure of the record layout for each program-described input file in the program. Each record identification line must precede the field entries for that record.

Record Identification Entries

Every record layout begins with a record identification entry containing the name of the input file in positions 7–16 (labeled Filename++ on the specification line). This name must match the entry on the File specification—in this case, Customers. The filename is a left- adjusted entry. Next, in positions 17–18 (labeled Sq), enter a Sequence code. This entry signals whether the system should check the order of records in the file as the records are read during program execution. Sequence checking is relevant only when a file contains multiple record formats (i.e., records with different field layouts). When sequence checking is inappropriate (which is usually the case), code any two alphabetic characters in positions 17–18 to indicate that sequence checking is not required. Many programmers use NS to signal no sequence. Because the Customers file contains a single record format, enter NS in positions 17–18.

Field description entries immediately follow the record identification entry. You define each field within the record by giving the field a valid name, specifying its length, and declaring its data type. Although you can define the fields of a record in any order, convention dictates that fields be described in order from the record’s beginning to its end.

Field Location (Positions 37–46)

You define a field’s length by specifying the beginning byte position and ending byte position of the field within the input record. The beginning position is coded as the from location (positions 37–41, labeled From+). The ending position is the to location (positions 42–46, labeled To+++). If the field is one-byte, the from and to entries are identical because the field begins and ends in the same location of the record.

Program-described character fields can be up to 32,766 bytes. Numeric fields can be up to 63 digits. Remember that for packed numeric fields, the number of bytes the field occupies is not the same as the number of digits; the I-specs indicate the number of bytes. The beginning and ending positions are right-adjusted within the positions allocated for these entries. You do not need to enter leading, nonsignificant zeros.

Decimal Positions (Position 47–48)

Numeric fields require a decimal position entry in positions 47–48 (labeled Dc), indicating the number of decimal positions to the right of the decimal point. A field must be numeric to use in arithmetic calculations or to edit for output, so it is important not to overlook the decimal position entry. When a numeric field represents whole numbers, the appropriate entry for its decimal positions is 0 (zero). Numeric fields can contain up to 63 positions to the right of the decimal point. Remember that the total length of the numeric field includes any decimal places (but not the decimal point itself or comma separators). To define a field as a character field, simply leave the decimal position entry blank.

Field Name (Positions 49–62)

The last required entry for a field description specification is a name for the field being described. This name, which you enter left-adjusted in positions 49–62 (labeled Field+++++++++), must adhere to the rules for valid field names in RPG. Within a record, a valid field name

• uses alphabetic letters, digits, or the special characters _, #, @, and $
• does not begin with a digit or an underscore
• does not include embedded blanks

In addition, a field name generally is 14 characters or fewer. This is a practical limit, imposed by the fixed-format nature of the Input specification.

The alphabetic characters can be upper case, lower case, or both. ILE RPG does not distinguish between letters on the basis of their case, but using a combination of uppercase and lowercase characters (e.g., capitalizing each word in the source code) makes your field names easier for others to understand.

Although not an ILE RPG requirement, it is good programming practice to choose field names that reflect the data they represent by making full use of the 14-character name limit. For example, Loannumber is far superior to X for the name of a field that stores loan numbers. Choosing descriptive field names can prevent your accidental use of the wrong field as you write your program and can help clarify your program’s processing to others who may have to modify the program.

Data Type (Position 36)

For most alphanumeric (character) or numeric fields, you can leave position 36 (labeled P) blank. But for fields that represent other types of data, you must make an entry in position 36 to tell the compiler the external data type of the field. Chapter 4 provides a complete examination of RPG data types. The sample program uses only character or numeric fields, so it does not require any entries here.

One more thing before we leave Input specifications: you may have noticed that the record layout described in the I-specs does not include all the fields from the Customers file. When the program does not use a field, that field need not appear in the Input specifications, but the remaining entries must reflect their correct position in the record layout. When a program does not use all the fields coded in the Input specifications, the compiler issues a warning, but this is not necessarily an error condition that prevents a successful compile. The following Input specifications, which include all the fields from the layout, also work: