MODULE DEFINITION


RPG IV programs consist of one mainline procedure and zero or more subprocedures. A source file can contain just the mainline procedure, the mainline procedure and one or more subprocedures, or only subprocedures. When only subprocedures exist within a source file, the header specification within that source file should include the NOMAIN keyword. This keyword instructs the compiler to avoid automatically inserting the RPG runtime support for the program logic cycle. The program logic cycle typically is not required and it adds unnecessary overhead to the compiled object.

Source files that contain only subprocedures are permitted to contain data definitions outside the scope of any of the subprocedures.

Variables declared within the mainline procedure are called global variables. Variables declared outside of any subprocedure (where the mainline procedure would normally be placed) also are called global variables. Variables declared within subprocedures are called local variables. See the subheading Scope for more information on global and local variables.

Figure 6.2 contains the annotated source for an RPG program that contains a mainline procedure and one subprocedure.

click to expand
Figure 6.2: Source member with embedded procedures.

Modules are defined at the source file level. RPG programs can call other programs dynamically or statically. They also can call subprocedures; however, all subprocedures require the static call interface.

As shown in Figure 6.2, variables can be defined within the mainline RPG code or in a subprocedure. In this example, the subprocedure TOUPPER is embedded within the same source file as the mainline program. The TOUPPER procedure is called to convert a character string to capital letters.

When source files are compiled, the output from the compiler is a module. If a program is made up of only one source file, then only one module is generated. If a program is made up of multiple source files, multiple modules are generated. Those modules must be bound together to create a single program object that can be called and run. This program object is referred to as a machine readable object or as executable. Figure 6.3 illustrates this source-to-module-to-program transition.

click to expand
Figure 6.3: Source file transition to *PGM object.

RPG allows separately compiled and independent programs to be bound together to form a single program object. The source file for each program is compiled to generate a module. Each module can be bound to create independent program objects. The individual modules, however, also can be bound together to create one larger program object.

There are two distinctions between separately compiled, independent programs and single programs that are composed of several bound modules:

  • The single bound program is larger and is, by definition, a single-program object. In contrast, the separately compiled and separately bound programs are independent objects.

  • The method of evoking one program from the other for a single-bound program is through the CALLB operation. For independent programs, the CALL operation is used.

There are four types of RPG IV source program organizations that can generate an object module. These types of source programs, and the commands used to compile them, are listed in Table 6.1 and explained in the text that follows.

Table 6.1: Source Program Structures

Description

Compiler Command

Service Program[1]

Activation Group

Traditional, single-source file (all in one) RPG program.

CRTBNDRPG

No

[*]DFTACTGRP

Single-source file that utilizes one or more embedded subprocedures.

CRTBNDRPG

Yes

QILE (i.e., named activation group)

Source file that uses zero or more embedded subprocedures, and one or more external subprocedures.

CRTRPGMOD

Yes

[*]NEW

Source files containing only subprocedures.

CRTRPGMOD

N/A

N/A

[1]Indicates whether the generated

[*]MODULE can be bound into a service program. Also requires the NOMAIN keyword on the Header specification.

Traditional, Single-Source File RPG Program

The traditional, single-source file RPG type of program organization is typically used in legacy applications or in new applications that have a limited scope. These kinds of programs can be statically bound together by using the CRTRPGMOD and the CRTPGM commands instead of the single-source-to-program CRTBNDRPG command. If one large bound program is created, the CALL operations must be changed to the CALLB operation.

Single-Source File Using Embedded Subprocedures

The single-source file with embedded subprocedures is another kind of all-in-one program. The program is contained within a single source file and contains one or more subprocedures to perform various tasks. This type of program can be compiled using the single-source-to-program CRTBNDRPG command. However, the defaults for the command need to be changed. Specifically, on the AS/400, programs that contain subprocedures cannot be run in the default activation group. They must be run in another activation group. When compiling this type of source file, typically, the QILE activation group is specified.

Multiple Source Files with Embedded or External Subprocedures

For new applications, the most common type of program has multiple source files with embedded or external subprocedures. Typically, there is a main application source file. It contains call interfaces (i.e., CALL, CALLB, CALLP, or prototypes) to the other programs and subprocedures. The CRTRPGMOD compiler command is used to generate modules for each separate source file. Procedures used by the application should probably be exported with the EXPORT keyword. This allows them to be evoked from other modules within the application.

A typical scenario for this type of application is one where the application source file contains the mainline procedure and controls the program's flow (logic). The other source files contain supporting subprocedures. Normally, the header specification is embedded in the secondary source files with the NOMAIN keyword specified. This allows the compiler to avoid generating redundant RPG program cycle code directly into each module. Only the mainline procedure requires the RPG program cycle code.




The Modern RPG IV Language
The Modern RPG IV Language
ISBN: 1583470646
EAN: 2147483647
Year: 2003
Pages: 156
Authors: Robert Cozzi

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net