What's New in V3R6/V3R2?
The major enhancement to RPG IV since V3R1 is the ability to code a module with more than one procedure. What does this mean? In a nutshell, it means that you can code an module with one or more prototyped procedures, where the procedures can have return values and run without the use of the RPG cycle.
Writing a module with multiple procedures enhances the kind of applications you can create. Any application consists of a series of logical units that are conceived to accomplish a particular task. In order to develop applications with the greatest flexibility, it is important that each logical unit be as independent as possible. Independent units are:
- Easier to write from the point of view of doing a specific task.
- Less likely to change any data objects other than the ones it is designed to change.
- Easier to debug because the logic and data items are more localized.
- Maintained more readily since it is easier to isolate the part of the application that needs changing.
The main benefit of coding a module with multiple procedures is greater control and better efficiency in coding a modular application. This benefit is realized in several ways. You can now:
- Call procedures and programs by using the same call operation and syntax.
- Define a prototype to provide a check at compile time of the call interface.
- Pass parameters by value or by reference.
- Define a procedure that will return a value and call the procedure within an expression.
- Limit access to data items by defining local definitions of variables.
- Code a module that does not make use of the cycle.
- Call a procedure recursively.
The run-time behavior of the main procedure in a module is the same as that of a V3R1 procedure. The run-time behavior of any subsequent procedures differs somewhat from a V3R1 program, most notably in the areas of procedure end and exception handling. These differences arise because there is no cycle code that is generated for these procedures.
Other enhancements have been made to for this release as well. These include:
- Support for two new integer data types: signed integer (I), and
unsigned integer (U)
The use of the integer data types provides you with a greater range of values than the binary data type. Integer data types can also improve performance of integer computations.
- *CYMD support for the MOVE, MOVEL, and TEST operations
You can now use the *CYMD date format in certain operations to work with system values that are already in this data format.
- Ability to copyright your programs and modules by using the COPYRIGHT
keyword on the control specification
The copyright information that is specified using this keyword becomes part of the DSPMOD, DSPPGM, or DSPSRVPGM information.
- User control of record blocking using keyword BLOCK
You can request record blocking of DISK or SEQ files to be done even when SETLL, SETGT, or CHAIN operations are used on the file. You can also request that blocking not be done. Use of blocking in these cases may significantly improve runtime performance.
- Improved PREFIX capability
Changes to the PREFIX keyword for either file-description and definition specifications allow you to replace characters in the existing field name with the prefix string.
- Status codes for trigger program errors
Two status codes 1223 and 1224 have been added to indicate trigger program errors.
The following tables summarize the changed and new language elements, based on the part of the language affected.
Language Unit | Element | Description |
---|---|---|
File description specification keywords | PREFIX(prefix_string {:nbr_of_char_ replaced}) | Allows prefixing of string to a field name or a partial rename of the field name |
Definition specification keywords | CONST{(constant)} | Specifies the value of a named constant, or indicates that a prototyped parameter that is passed by reference has a constant value |
PREFIX(prefix_string {:nbr_of_char_ replaced}) | Allows prefixing of string to a field name or a partial rename of the field name | |
Operation codes | RETURN | Returns control to the caller, and returns a value, if specified |
Language Unit | New | Description |
---|---|---|
Control specification keywords | COPYRIGHT('copyright string') | Allows you to associate copyright information with modules and programs |
EXTBININT{(*NO | *YES)} | Specifies that binary fields in externally-described files be assigned an integer format during program processing | |
NOMAIN | Indicates that the module has only subprocedures | |
File description specification keywords | BLOCK(*YES |*NO) | Allows you to control whether record blocking occurs (assuming other conditions are met) |
Definition specification keywords | ALIGN | Specifies whether integer or unsigned fields should be aligned |
EXTPGM(name) | Indicates the external name of the prototyped program | |
EXTPROC(name) | Indicates the external name of the prototyped procedure | |
OPDESC | Indicates whether operational descriptors are to be passed for the prototyped bound call | |
OPTIONS(*NOPASS *OMIT *VARSIZE) | Specifies various options for prototyped parameters | |
STATIC | Specifies that the local variable is to use static storage | |
VALUE | Specifies that the prototyped parameter is to be passed by value | |
Built-in functions | %PARMS | Returns the number of parameters passed on a call |
Operation codes | CALLP | Calls a prototyped program or procedure |
Specification type | Procedure specification | Signals the beginning and end of a subprocedure definition |
Definition type | PR | Signals the beginning of a prototype definition |
PI | Signals the beginning of a procedure interface definition | |
blank in positions 24-25 | Defines a prototyped parameter |