PROGRAM ENTRY POINT

For stand-alone programs, the area of the RPG program commonly referred to as the mainline calculations is known as the mainline procedure. This is also referred to as the program entry point. The program entry point is different from the generic program entry procedure (PEP) that is inserted into every program by the OS/400 binder.

The PEP receives control from a static or dynamic call to a program. It, in turn, transfers control to the user entry procedure (UEP). The UEP is the program's starting point. In stand-alone RPG programs, the UEP is the start of the RPG program cycle, which eventually leads to the first detail-time calculation, also known as the the mainline calculations.

In Table 10.2, three RPG program source code structure types are listed. These structures illustrate how procedures can be specified in RPG source files.

Table 10.2: Three Types of Source File Structures

Type	Source Code Structure	Description	Caveats
1	H F (global files) D (global data) C (mainline calcs) O (global output) P (begin proc1) D C P (end proc1) P (begin proc2) D C P (end proc2)	Stand-alone program. Evoked via call to the program name. Call must be dynamic, unless module is bound with othermodules, in which case the static call is required.	Procedures are essentially replacements for subroutines, orno procedures are specified. Entry point is the mainline procedure via a static or dynamic call to the program name. Subprocedures can be called if they are exported, but typically they are not exported.
2	F (global files) D (global data) P (begin proc1) EXPORT D C P (end proc1) P (begin proc2) D C P (end proc2)	Procedure module. Evoked via call to any exported procedure. Global data is available to each procedure. No mainline calculations are specified. Most procedures are exported. RPG program cycle overhead is inserted into the module.	The NOMAIN keyword is omitted but only procedures are included (no mainline calculcations). Use as a subprocedure library. The overhead of the RPG program cycle is not necessary; files are automatically opened and closed anyway. Larger-than-necessary module size. Can be used to create a service program.
3	H NOMAIN F (global files) D (global data) P (begin proc1) EXPORT D C P (end proc1) P (begin proc2) EXPORT D C P (end proc2)	Procedure module. Evoked via call to any exported procedure. Global data is available to each procedure. No mainline calculations are specified. The NOMAIN keyword on the header specification directs the compiler not to insert the RPG program cycle overhead.	NOMAIN keyword is included (no mainline calculations). Use as a subprocedure library. Smaller module size. Can be used to create a service program. Procedures intended for public use must include the EXPORT keyword on their procedure specification. Global data usually is not required.

Type 1 is either a stand-alone source program or the program entry-point module for a larger application. For stand-alone programs, it can be called directly and run from a command line. The module object from this type of program can be bound to run on its own or it can be statically bound to another module. The call interface to this type of program is through the dynamic CALL operation or the static CALLB and CALLP operations.

Type 2 is a procedure-only source program. It is used to store procedures that are called by other programs. The module object created from this type of source program must be statically bound to another module. Other programs or procedures may call this module's exported procedures. A major shortcoming with this type of source file is that the RPG program cycle is embedded into its *MODULE by the compiler. This additional overhead is unnecessary considering the Type 3 source file.

Type 3 is a procedure-only source file, similar to Type 2. It is used to store procedures that are called by other programs. The module object created from this type of source program must be statically bound to another module. Other programs or procedures may call this module's exported procedures. The main difference is the NOMAIN keyword. This keyword directs the compiler to avoid embedding the RPG program cycle overhead into the *MODULE. Type 3 is preferred over Type 2.

There is another type of module that can be generated. However, it is similar in structure to the Type 1 source file. When the CALLB operation is used, the module name can be used as the name of the program to call. This allows independent programs to be statically bound into one physical program object. With the exception of the CALLB operation, however, the interface between the two programs is the same as for the CALL operation:

• Full RPG cycle code is embedded into the generated module.

• The subprogram can be called via the mainline program.

• The program entry point in the subprogram is the first line of its mainline calculation specifications.

To further illustrate the Type 1 and Type 3 source file structures, an example Type 1 source file is shown in Figure 10.8 and an example Type 3 source file is shown in Figure 10.9.

Figure 10.8: Type 1 source file.

Figure 10.9: Type 3 source file with NOMAIN.