400 likes | 553 Views
RPG IV. Modular Programming Concepts - Chapter 10. Objectives. Calling programs Sharing data among programs through data areas Code procedures and prototypes. Modular Programming. Advantages of small, stand-alone units of code Reuse of units Easier to test
E N D
RPG IV Modular Programming Concepts - Chapter 10
Objectives • Calling programs • Sharing data among programs through data areas • Code procedures and prototypes
Modular Programming • Advantages of small, stand-alone units of code • Reuse of units • Easier to test • Changes made are less likely to cause unwanted side effects • Divide up application development among members of a programming team
Calling Programs • Three operations • CALL, CALLB, CALLP • Program A (Calling program) calls Program B (Called program) • Program B executes • When Program B reaches a RETURN control is passed back to Program A to the statement immediately following the call
Dynamic Binding • Code and compile programs separately • At runtime, the Calling program goes looking for the Called program • When the Calling program finds the Called program, the Called program is executed • Use a CALL for programs that are dynamic bound
Static Binding • Connecting program modules before runtime • Eliminates performance degradation found with dynamic binding • Compile source code with CRTRPGMOD (Create RPG Module) • Then bind the *Module objects with CRTPGM ( Create Program) • Use CALLB or CALLP for static bound
CALL (Call a Program) • The CALL operation passes control to the program named in factor 2 • Factor 2 may contain a field, array element, or named constant that specifies the name of the program to be called • You can include an optional (E) operation extender to monitor for errors that might occur
CALL - LR On • If the LR indicator is on when the RETURN is executed, the system’s resources that were tied up by the called program are released • Subsequent calls to that program causes the program to start up again as though for the first time
CALL - LR Off • If LR is off within the called program upon return, that called program remains activated • As a result, the values remain the same • Moreover, any files used will still be open
CALLB (Call a Bound Module) • Factor 2 must reference a *MODULE procedure that is contained within the same *PGM object at the calling program • Format of CALLB is identical to CALL • Factor 2 must contain a literal, a named constant, or a procedure pointer • Factor 2 cannot contain a field whose value is the procedure name
Passing Data Between Programs • RPG uses the PARM operation to indicate which field values are to be shared between programs • A list of PARMs in the calling program must have a list of corresponding PARMs in the called program • Each PARM requires an entry in the result field of the C Spec
Passing Data Between Programs cont.. • This entry may be a field, data structure, array or multiple-occurrence data structure • It cannot be and indicator, a literal, a label, a constant, or a table name • The data names do not need to be the same, corresponding PARMs in the two programs should have the same type and length
PLIST • PLIST identifies a list of parameters to be shared between programs • The PLIST requires an identifying entry in factor 1 in the calling program • The reserved word *ENTRY is used in the called program
Passing Data by Reference • RPG passes parameter arguments by passing the address of the storage location represented by the field (passing by reference) • Changes in called program result in changes in calling program
Passing Data by Value • When you use the result field in a CALL, the system copies the value of factor 2 field in the result field and passes the address of the result field to the called program
Procedures, Subprocedures and CALLP • A program may now consist of a main procedure and optionally one or more subprocedures • Subprocedures can exist either within the same module or in standalone modules, where they can be bound to and accessed by other programs
Subprocedure vs. Subroutines • Subprocedure can be created independently of the main program or main procedure • Subprocedure variables are local, subroutine variables are global
Calling Subprocedures • If the subprocedure returns a value, you invoke it the same way you invoke built in functions • If the subprocedure does not return a value, you use CALLP
Coding a Subprocedure • Code NOMAIN for procedure without a main module • Declare the procedure prototype • Begin the subprocedure • Declare the procedure interface • Calculation specs • RETURN a value or expression
Procedure Prototype • The prototype is required to be placed into the module where the procedure is defined and or main procedure • If the subprocedure is placed in the same source member as the caller, then only one prototype is needed • The prototype should match the Procedure Interface, because it also defines the interface to the procedure
Begin the Subprocedure • Includes the name of subprocedure • B in position 24 • Keyword EXPORT allows the subprocedure to be called by other modules within the program
Declare the Procedure Interface • Like *ENTRY PLIST with calls • First D spec defines the output parameter • Later D specs defines the input parameters • Then local variables are defined
RETURN a Value • The op code RETURN is used to return a value • The procedure is ended by a P spec and an E
CALLP(Call a Prototyped Procedure or Program) • Use the CALLP for calling procedures that do not return a value • Dynamic calls: • Use a prototype instead of PLIST • Use EXTPGM keyword • Use the optional (E) extender to indicate that the %ERROR function should be turned on if the call to the program ends in error
Passing Parameters by Value • Include the VALUE keyword for a parameter within a prototype • Pass the actual value instead of memory location • Called procedure must allocate its own memory for parameter • If the called procedure changes the value , the calling procedure will not recoginze the change
Passing Parameters by Read-Only Reference • To pass by value to dynamically called program • Passing parameters by read-only reference emulates pass by value to procedures • Include the CONST keyword for a parameter within a prototype
APIs • API’s are programs or commands built into the OS that let you access lower-level machine functions • API’s are used with the CALL operation
Data Areas • The system automatically creates a local data area (LDA) for each job in the system • You can also create more permanent data areas with the CL command CRTDTAARA • What are data areas used for?
Data-Area Data Structures • A U in position 23 of a data structure identifies it as a data-area data structure • If you do not name the data structure, the data structure contains information from the LDA • If you want the data structure to contain data from a different data area, you must provide a program name that matches the name of a data area in the system
Using *DTAARA DEFINE • Can access data-area without defining a data-area data structure • *DTAARA in Factor 1 • Result field must contain a field, data-structure subfield, or data structure (but not a data-area data structure) • Factor 2 contains external name of data area or *LDA • Must read and write contents
IN(Retrieve a Data Area) • “Reads” in the contents of data area • Factor 2 must contain the result field of a *DTAARA DEFINE • *LOCK as a Factor 1 entry, will lock the data from update by another program • *LOCK cannot be used with the LDA
OUT(Write Out a Data Area) • “Writes” out the contents of data area • Factor 2 must contain the result field of a *DTAARA DEFINE • The operation cannot be used unless the data area has already been retrieved • *LOCK as a Factor 1 entry, will lock the data from update by another program • *LOCK cannot be used with the LDA
UNLOCK(Unlock a Data Area) • Unlocks the data area reference in Factor 2 • Factor 2 must contain the result field of a *DTAARA DEFINE • *LOCK cannot be used with the LDA
Points to Remember • One way to implement a modular approach to programming is to break required processing into separate programs • These programs then can be used by other programs through the CALL operation • In RPG, all variables are global within a program, but local to the program
Points to Remember cont. • To share data between a calling and called program, PARMs are used in both programs to define the shared data • The PARMs appear either immediately following a CALL operation or as part of a named PLIST in the calling program and within an *ENTRY PLIST in the called program
Points to Remember cont. • The corresponding PARM variables in the calling and called programs share a common storage location • As a result, changes to a parameter’s value in one of the programs effects the corresponding parameter’s value in the other program • The AS/400 also provides data areas for sharing values between programs
Points to Remember cont. • Support for subprocedures, lets you create standalone routines, or user-defined functions • IBM offers several built-in system programs called API’s, which you can call from your RPG IV program to accomplish various kinds of lower-level processing
Points to Remember cont. • An LDA is automatically available for each job, you can define permanent data areas that any program can access • You can access the contents of a data area within an RPG program by defining a special data structure • Data contained in data-area data structures is automatically retrieved at the start and written back to the data area at the end