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:
Jim is the president and founder of imPower Technologies, where he provides professional IBM i training and consulting services. He is active in the IBM i community, working to help companies train their employees in the latest IBM technologies and develop the next generation of IBM i professionals.
MC Press books written by Jim Buck available now on the MC Press Bookstore.
 |
||
 |
|
Control Language Programming for IBM i Master the A-Z of CL, including features such as structured programming, file processing enhancements, and ILE. List Price $79.95 Now On Sale
|
|
||
 |
|
Mastering IBM i Get the must-have guide to the tools and concepts needed to work with today's IBM i. List Price $85.95
Now On Sale
|
|
||
 |
|
Programming in ILE RPG Get the definitive guide to the RPG programming language. List Price $95.95
Now On Sale
|
|
||
 |
|
Programming in RPG IV Understand the essentials of business programming using RPG IV. List Price $79.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online