Thu, Jun
4 New Articles

Programming in ILE RPG - Navigating Legacy Code

  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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.

Programming in ILE RPG - Navigating Legacy Code - Table 1

Programming in ILE RPG - Navigating Legacy Code - Table 1

Programming in ILE RPG - Navigating Legacy Code - Table 1 (cont.)

File Specifications

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

Programming in ILE RPG - Navigating Legacy Code - Table 2 

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.

Programming in ILE RPG - Navigating Legacy Code - Table 3 

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:

Programming in ILE RPG - Navigating Legacy Code - Table 4

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:

Programming in ILE RPG - Navigating Legacy Code - Table 5

James Buck
Jim Buck's career in IT has spanned more than 35 years, primarily in the college education, manufacturing, and healthcare industries. Past president (13 years) of the Wisconsin Midrange Computer Professional Association, he has served on several teams developing IBM and COMMON certification tests. Jim has co-authored several IBM i textbooks with Bryan Meyers that are used by many companies and in colleges worldwide. Other accomplishments include: recipient of the 2007 IBM System i Innovation - Education Excellence Award, 2014 COMMON President's Award, and 2013/2016/2017 IBM Champion - Power Systems.

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 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 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 Programming in ILE RPG
Get the definitive guide to the RPG programming language.
List Price $95.95

Now On Sale

Programming in RPG IV Programming in RPG IV
Understand the essentials of business programming using RPG IV.
List Price $79.95

Now On Sale



Support MC Press Online

$0.00 Raised:

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: