12. Calling Programs – ILE RPG in Easy Bytes – IBM i and ILE RPG Self-Study Tutorials

Unit 12 examines modular programming and shows you how RPG programs can communicate with one another by passing data values as parameter arguments. You also learn how to define prototypes and procedure interfaces. In addition, this unit compares two methods for passing parameters and discusses the advantages of each technique. Finally, it outlines the use of data areas to provide external data to a program, as well as to pass information to other programs without using parameters.

This course is a unit of the ILE RPG in Easy Bytes series, a complete introductory ILE RPG programming self-guided tutorial.

One-Time Payment

$29.95

Members Only

FREE

MEMBER PRICING

Series: ILE RPG IV in Easy Bytes

Instead of paying for each unit individually, you may purchase a membership which will automatically enroll you at a discount in the entire “ILE RPG in Easy Bytes” series.

Calling Programs

When a program execution reaches a Callp statement, control passes to the called program–a separate *PGM object. The called program runs until it reaches a Return statement, and then control returns to the calling program at the statement immediately following the original call. The flow of control with a call is like that of an Exsr operation, except that a call invokes an external program (or a subprocedure, which we’ll discuss in the next unit) rather than a subroutine internal to the program.

The Procedure Interface

The called program should also use a prototype definition to describe the corresponding list of parameters that it is to receive from the caller. The prototypes in each program must match each other. That is, they must have the same number of parameters, and the corresponding parameters between the two programs must have the same data attributes.

Passing Parameters and Changing Values

Once the prototype and procedure interface definitions are in place in both the calling program and the called program, the caller can pass parameters to the called program, and the called program can use the parameters during the course of its processing. Prototypes also offer some flexibility in the method the system uses to pass those parameters. RPG employs two methods for passing parameters between programs:

Return and *INLR

If the LR indicator is also on when the Return is executed, the system releases any resources tied up by the called program. A subsequent call to the program causes it to start again as though for the first time. However, if LR is not on within the called program when it returns, it remains activated.

Fitting the Pieces

The calling program includes two items: A prototype definition to describe the parameters to pass The Callp operation to execute the call The called program contains the following: A prototype definition to describe the parameters to receive A procedure interface to receive the parameters and define their variables The Return operation to return control to the calling program In the following example snippets, program AR000 calls AR002, passing it three parameters:

Data Areas

Data areas are system objects you use to share data between programs within a job or between jobs. However, one program does not have to call another to share the data if the data resides in a data area, nor does a calling program have to pass parameters to a called program to share the data. You can use data areas to store information of limited size (up to 2,000 bytes), independent of database files or programs.

Legacy Code

Legacy Code (Calling Programs)

They can also use an older operation—Call (Call a Program)—in place of Callp to call external programs. Fixed-Format Prototypes To use D-specs to define a prototype, code PR in columns 24–25 (Ds): *..