Wednesday, January 31, 2007
The Long and Short of Subprocedure Return Values
User-defined functions in RPG, especially in the context of free-form calculations, can simplify programming tasks (and make calculation specifications more fun to write). However, you should keep in mind that return values are implicitly returned by value. Therefore, the same considerations that apply to VALUE parameters also apply to return values (see prior post on this subject).
In the general case, a value returned from a subprocedure is copied twice. The first copy occurs when the RETURN operation is evaluated, which copies the function's return value to a temporary location. The second copy occurs back at the call site, where the function result is copied from the temporary location to a variable in the caller's storage. If the return value is a varying-length data type, the temporary location is the full (declared) length of the varying length result.
So, it is important from a performance and storage perspective to strike some balance in the length of a character return value. You need to determine some practical limit to the size returned by your procedures.
As an alternative to returning a varying-length character string as a subprocedure return value, the programmer should consider returning the value in a parameter that is passed by reference (that is, an output parameter). That will reduce the storage requirements and eliminate one copy of the returned data, which can be significant for larger lengths (like 32K or more).
Sunday, January 28, 2007
RPG's VALUE Parameters Often Have Little
When the VALUE keyword is specified on the definition of a subprocedure parameter, it instructs the compiler to pass the parameter by value rather than by reference.
"By value" means that a copy of the argument value is passed, while "by reference" means that the address of the argument value is passed. By value is a safer way to pass data to a subprocedure (because the data cannot be modified), and for integer, float, and packed-decimal data types, it cannot be beat in terms of runtime efficiency.
However, passing character data types by value can be terribly inefficient in terms of storage and execution time. At each location that the subprocedure is called, the compiler will make a temporary copy of the VALUE character argument. If the parameter is also defined as varying length, two temporaries are effectively allocated, both with the full (declared) length of the varying length parameter. Imagine what that means if the parameter is 32K or longer.
As an alternative to defining a varying length VALUE parameter, the programmer should consider passing the parameter value by reference. This is accomplished by removing the VALUE attribute or replacing it with CONST.
Integer, float, and packed-decimal numeric types should continue to be passed by value when possible. In general, character data longer than 16 bytes should be passed by reference.
