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.

Table 1. Changed Language Elements Since V3R1
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
Table 2. New Language Elements Since V3R1
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