25
Wed, Dec
0 New Articles

Getting Started: Building the ILE RPG Program and Navigating Legacy Code

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

Part two addresses the building of an ILE RPG program. It also demonstrates how to navigate legacy code.  Review Part one here: Getting Started: Sections & a Sample of ILE RPG Programs.

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

Building the Program

To create this program, you use an editor, such as SEU or LPEX, to enter the ILE RPG code into a source file member with a member type of RPGLE. A source file member is a set of data within a source file. Usually, a source file contains more than one member, each of which holds the source code for a single program. Once the source member contains all the necessary code, you then use the CRTBNDRPG (Create Bound RPG Program) command to compile the source and create the program. Figure 2.3 shows the prompted CRTBNDRPG command. The compiler generates a listing, which you use to verify the creation of the program or to find errors. Appendix B describes the tools you might use to edit and compile a program.

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Figure 1 

Figure 2.3: CRTBNDRPG command

Once the program is successfully created, execute it by using the CALL command. The output of your program is a spooled file, CUSTLIST, in an output queue. You can view the report by using the WRKSPLF (Work with Spooled Files) command, or you can release it to a printer.

Navigating Legacy Code

Earlier releases of RPG (Release 7.1 and earlier) identify the sections of a program by using different kinds of lines, called fixed-format specifications. Fixed format means that the location of an entry within a program line is critical to the entry’s interpretation by the RPG compiler. Although you can write most modern programs by using free-format coding, which does not have significant positional restrictions, you may encounter fixed format when you are maintaining existing programs. Good programming style prefers free-format coding, but you can freely mix fixed format and free format within the same program.

Each type of fixed-format specification has a particular purpose. Following are the specification types:

  • Header (Control) specifications—provide default options for the source
  • File specifications—identify the files a program is to use
  • Definition specifications—define variables and other data items the program is to use
  • Input specifications—depict the record layout for program-described input files
  • Calculation specifications—detail the procedure the program is to perform
  • Output specifications—describe the program output (results)
  • Procedure boundary specifications—segment the source into units of work, called procedures

Not all programs need every kind of fixed-format specification. Fixed-format specification types require a different identifier, or form type, which must appear in position 6 of each program line. A File specification line of code, for example, must include an F in position 6. For this reason, File specifications are commonly called F-specs.

Fixed-format specifications must appear in a specific order, or sequence, within your source code, with all program lines that represent the same kind of specification grouped together. The following list illustrates the order in which the specifications are grouped. Notice that the fixed-format specifications generally follow the same order as the free-format sections of a program.

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Table 1 

* Beginning with Release 7.2, you can mix File specifications and Definition specifications in any order.

Most specifications require fixed-position entries in at least part of the specification. The editor you use to enter your source code can provide you with prompts to facilitate making your entries in the proper location. (Appendix B provides more information about editors.)

Even though specifications are primarily fixed format, some also support a free-form area, where you can code keywords and values with little or no regard to their specific location within the free-form portion of the specification. Beginning with Version 5, RPG supports free-format calculation specifications, but—until Release 7.2—all other specifications must be fixed format.

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Note 1 

When you begin maintaining a fixed-format program, notice that an entry does not always occupy all the positions allocated for it within a specification. When that happens, a good rule is that alphabetic entries start at the leftmost position of the allocated space, and unused positions are to the right. Numeric entries, however, are usually right-adjusted, and unused positions are to the left.

Fixed-Format Specifications for a Sample Program

Let’s look at a fixed-format version of the example program and compare it with the free-format version shown earlier.

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Code 1 

Notice that fixed-format RPG specifications do not require a semicolon delimiter. Fixed format traditionally uses an asterisk (*) in position 7 to denote a comment. You can also use slashes (//) to begin a comment in fixed-format code, but the comment cannot be on the same line as other code; it must be on a separate line.

Control Specifications

Control specifications (Control options) require an H in position 6. The remaining positions, 7–80, consist of reserved keywords, which have special values and meanings associated with them. Fixed-format control specifications mimic the function of the Ctl-opt instruction in free-format code. The keywords have no strict positional requirements—they can appear in any order and in any position 7–80. The following header shows the layout of a Control specification for the fixed-format variation of your program:

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Code 2 

File Description Specifications

The fixed-format File specification (F-spec) is comparable to the Dcl-f (Declare File) instruction covered earlier. All File specifications include an F in position 6. Each file a program uses requires its own File specification line. The following header shows the layout of a File specification and the completed File specifications for your program. Note that in addition to column positions, the ruler lines include prompts to help you remember where to insert required entries.

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Code 3 

Filename (Positions 7–16)

In positions 7–16 (labeled Filename++ on the ruler line), you enter the name of the file. Note that you code filenames, like other alphabetic entries, beginning in the leftmost position allowed for that entry—in this case, position 7. Simply leave blank all unneeded positions to the right of the name.

File Type (Position 17)

Position 17 (labeled I on the ruler line) specifies the file usage. It is the fixed-format equivalent of the Usage keyword used by the Dcl-f free-format instruction. The two types in this program are input (type I) and output (type O).

File Designation (Position 18 Input Files Only)

Every input file requires a file designation entry (position 18, labeled P). File designation refers to the way the program accesses, or retrieves, the data in the file. In the example, you retrieve data by explicitly reading records within your program, rather than by using the built-in retrieval of RPG’s fixed-logic cycle. In RPG terminology, that makes the file full procedural, so F is the appropriate entry for position 18. Because this designation applies only to input files, you leave it blank for the Custlist specification line. The Dcl-f free-format instruction has no entry for a file designation. All files that Dcl-f declares are assumed to be full procedural files.

File Format (Position 22)

The next required entry is file format. An E in position 22 (labeled F) stands for external format, which means that the file’s record formats are implicitly contained in the file itself. Chapter 3 explains externally described files in further detail. The Dcl-f free-format instruction uses externally described files as the default entry, so no entry is necessary when you use Dcl-f to declare an externally described file.

Device (Positions 36–42)

The Device entry indicates the device associated with a file. You enter the device names left- adjusted in positions 36–42 (labeled Device+). This entry corresponds to the Disk and Printer keywords used earlier in the free-format Dcl-f example.

Keywords (Positions 44–80)

The Keywords area of the File specification gives you an opportunity to amplify and specialize the basic file description in the positional area (positions 6–43) of the F-spec. RPG allows many reserved keywords (listed in Appendix A) in this area of the specification. These are the same keywords that the Dcl-f instruction uses. You can code more than one keyword on a specification line, in positions 44–80, without being too concerned about other positional requirements. Most RPG programmers, however, prefer to limit their code to one keyword per line. If a specification requires more than one keyword, you can simply continue coding them in the Keywords area on subsequent F-spec lines.

No other File specification entries are required to describe the files the sample program uses. In this introductory explanation, we’ve skipped some of the entries that are not needed in this program (we’ll cover them later).

Definition Specifications

Definition specifications, identified by a D in position 6, follow the File specifications in the fixed-format example. D-specs define to your program those data items that do not originate as fields in a file’s record layout. In the example, Endofpage is one such data item. The following shows the general layout of the Definition specification as well as the example code:

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Code 4 

This definition corresponds to the Dcl-s instruction in the earlier free-format example.

Data Item Name (Positions 7–21)

To define a standalone variable, you first name the variable anywhere in positions 7–21 (Name+++++++++++) of the line. The name need not begin in position 7. In fact, to aid readability, many programmers always leave position 7 blank to separate the data item name from the D in column 6.

Definition Type (Positions 24–25)

Definition specifications use positions 24–25 (Ds) to indicate the type of data item the line is defining. For a standalone variable, enter an S (for standalone) left-adjusted in these positions. In the free-format example earlier, the Dcl-s instruction serves the same purpose. Chapter 4 covers the other entries for other definition types.

Data Type (Position 40)

Position 40 (I) indicates what data type RPG uses to internally store a variable. For an indicator variable, enter an N (iNdicator) in position 40. Chapter 4 describes other possible entries for this position. Data type N corresponds to the Ind keyword used by the Dcl-s free-format instruction.

Keywords (Positions 44–80)

The Keywords area of the Definition specification provides an opportunity to further define the simple definition in positions 7–43. In this case, the example uses the Inz (Initialize) keyword to set Endofpage *On when the program starts.

Calculation Specifications

In the fixed-format example, the program’s main procedure is written using Calculation specifications. C-specs are identified by a C in position 6. The following shows the general layout of Calculation specifications:

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Code 5 

Notice that there are two general layouts. Most RPG operations use the first, traditional format (e.g., Factor 2, Result), and some use the second (Extended-Factor 2). You can freely intermix the two layouts. For the example, you need not be overly concerned about the differences between the two layouts; in fact, it may not even be obvious which operations are using which layout. The completed C-specs for the example program’s main procedure are as follows:

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Code 6 

Let’s compare the fixed-format C-specs with the free-format main procedure shown earlier.

Operation Code (Positions 26–35)

Positions 26–35 (Opcode(E)++) contain the operation code, left-adjusted. In general, these are the same operation codes the free-format example used, although fixed-format C-specs also support several obsolete operation codes that are no longer commonly used. Notice that the operation code must begin in position 26. Fixed-format calculations do not allow indenting.

Factor 2 (Positions 36–49)

Many operation codes use operand values (factors) to provide the compiler with the details necessary to perform the operation. In the example, the following lines specify a Factor 2 operand, left-adjusted, in positions 36–49:

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Code 7 

Some operation codes (though none in the example) also use a Factor 1 operand in positions 12–25 and a Result factor in positions 50–63.

Extended-Factor 2 (Positions 36–80)

Some operation codes, most notably Eval, support an Extended-Factor 2 in positions 36–80 as an alternative to the earlier shorter Factor 2. You can use the extended layout to code expressions instead of using simple operands. Operation codes that use the Extended-Factor 2 layout do not use Factor 1. In the example, these lines use the Extended-Factor 2:

Getting Started: Building the ILE RPG Program and Navigating Legacy Code - Code 7 

Notice that the Eval operation, usually optional in free-format code, is required when you are using fixed-format C-specs.

 

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

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: