Filter
Top Products
Multiple Procedures Module
Chapter 4. Creating an Application Using Multiple
Procedures
The ability to code more than one procedure in an ILE RPG module greatly
enhances your ability to code a modular application. This chapter discusses why
and how you might use such a module in your application. Specifically this chapter
presents:
Overview of key concepts
Example of module with more than one procedure
Coding considerations
Refer to the end of this section to see where to look for more detailed information
on coding modules with multiple procedures.
A Multiple Procedures Module — Overview
An ILE program consists of one or more modules; a module is made up of one or
more procedures. A procedure is any piece of code that can be called with a
bound call. ILE RPG has two kinds of procedures: a main procedure and a subpro-
cedure. The way to call a subprocedure is with a prototyped call.
Note: In the RPG documentation, the term 'procedure' refers to both main and
subprocedures.
Main Procedures and Subprocedures
An ILE RPG module consists of a main procedure and zero or more subproce-
dures. (If there are subprocedures, the main procedure is optional.) A main proce-
dure is a procedure that can be specified as the program entry procedure (and so
receive control when an ILE program is first called). The main procedure is defined
in the main source section, which is the set of H, F, D, I, C, and O specifications
that begin a module. In V3R1, all ILE RPG modules had a main procedure and no
other procedures.
A subprocedure is a procedure that is specified after the main source section. A
subprocedure differs from a main procedure primarily in that:
Names that are defined within subprocedure are not accessible outside the
subprocedure.
No cycle code is generated for the subprocedure.
The call interface must be prototyped.
Calls to subprocedures must be bound procedure calls.
Only P, D, and C specifications can be used.
Subprocedures can provide independence from other procedures because the data
items are local. Local data items are normally stored in automatic storage, which
means that the value of a local variable is not preserved between calls to the pro-
cedure.
Copyright IBM Corp. 1994, 1999 33