Example of Module with Multiple Procedures - IBM - RPG

Now let us look at an example of a multiple procedures module. In this ’mini-application’ we are writing a program ARRSRPT to produce a report of all customers whose accounts are in arrears. We will create the basic report as a module, so that it can be bound to other modules, if necessary. There are two main tasks that are required for this module:

  1. Determine that a record of an account from a customer file is in arrears.
  2. Format the data into a form that is suitable for the report.

We have decided to code each task as a subprocedure. Conceptually, the module will look something like that shown below.

Components of the ARRSRPT Module
Components of the ARRSRPT Module

Now consider the first subprocedure, InArrears, which is shown in Figure. InArrears is called by the main procedure to determine if the current record is in arrears. TIP When coding sub procedures that use global fields, you may want to establish a naming convention that shows the item to be global. In this example, the uppercase field names indicate DDS fields. Another option would be to prefix ’g_’, or some other string to indicate global scope. If the record is in arrears, the sub procedure returns ’1’ to the main procedure.

Source for Subprocedure InArrears
Source for Subprocedure InArrears

This shows the main elements that are common to all subprocedures.

  1. All subprocedures begin and end with procedure specifications.
  2. After the Begin-Procedure specification(B in position 24 of the procedure specification),you code a procedure interface definition. The return value,if any,is defined on the PI specification.Any parameters are listed after the PI specification.
  3. Any variables or prototypes that are used by the subprocedure are defined after the procedure interface definition.
  4. The return value, if specified, is returned to the caller with a RETURN operation.
  5. If the record is not in arrears, the subprocedure returns ’0’ to the main procedure.

For all subprocedures, and also for a main procedure with prototyped entry parameters, you need to define a procedure interface. A procedure interface definition is a repeat of the proto type information within the definition of a procedure. It is used to define the entry parameters for the procedure. The procedure interface definition is also used to ensure that the internal definition of the procedure is consistent with the external definition (the prototype). In the case of InArrears, there are no entry parameters.

Consider next the subprocedure FmtCust, which is shown. FmtCust is called by ARRSRPT to format the relevant fields of a record into an output record for the final report. (The record represents an account that is in arrears.) FmtCust uses global data, and so does not have any input parameters. It formats the data into two output fields: one for the name, and one for the address.

Source for Subprocedure FmtCust
Source for Subprocedure FmtCust

Finally, consider the last subprocedure of this application, FmtAddr. Notice that FmtAddr does not appear in the ARRSRPT module, that is shown. We decided to place FmtAddr inside another module called FMTPROCS. FMTPROCS is a utility module that will contain any conversion procedures that other modules might need to use.

This shows the source of the module FMTPROCS. Since this is a prototyped procedure, it needs the proto type to be available. So that the prototype can be shared, we have placed the prototype into a /COPY file.

Source for module FMTPROCS, containing subprocedure FmtAddr.
Source for module FMTPROCS, containing subprocedure FmtAddr.

FMTPROCS is a NOMAIN module, meaning that it consists only of subprocedures; there is no main procedure. A NOMAIN module compiles faster and requires less storage because there is no cycle code that is created for the module. You specify a NOMAIN module, by coding the NOMAIN keyword on the control specification.

The Entire ARRSRPT Program
The ARRSRPT program consists of two modules: ARRSRPT and FMTPROCS.This shows the different pieces of our mini-application.

The ARRSRPT Application
The ARRSRPT Application

This shows the source for the entire ARRSRPT module.

ILE RPG Complete Source for ARRSRPT Module
ILE RPG Complete Source for ARRSRPT Module

Note the following about ARRSRPT:

  • The definition specifications begin with the prototypes for the prototyped calls. A /COPY file is used to supply the prototype for the called procedure FmtAddr. The prototypes do not have to be first, but you should establish an order for the different types of definitions for consistency.
  • The date field CurDate is a global field, meaning that any procedure in the module can access it.
  • The main procedure is simple to follow. It contains calculation specifications for the two main tasks: the I/O, and an initialization routine.
  • Each subprocedure that follows the main procedure contains the details of one of the tasks.

Sample output for the program ARRSRPT is shown.

Output for ARRSRPT
Output for ARRSRPT

This show the DDS source for the files CUSTFILE and CUSTRPT respectively.

DDS for CUSTFILE
DDS for CUSTFILE

DDS for CUSTRPT
DDS for CUSTRPT


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM - RPG Topics