7.9.1 CHANGE Parameters
Specifies the name(s) of the field(s), list(s) or expandable group expression which is/are to be changed.
Specifies the new value which field(s) nominated in the FIELD parameter are to take on. The new value specified can be another field name, an alphanumeric literal, a numeric literal, a system variable, a process parameter or an expression involving any of these in combination.
The VALUE parameter may also be specified as any one of the following "special" values when using an RDML field:
|
*NULL |
Indicates all alphanumeric fields should be set to blanks and all numeric fields to zero. |
|
*NAVAIL |
Indicates all numeric fields should be set to zero and all alphanumeric fields of less than 3 characters to blanks. Alphanumeric fields of 3 or more characters in length are to be set to as much of "N/AVAIL" as will fit into the field. |
|
*DEFAULT |
Indicates all fields should be set to their data dictionary or program defined default values. |
|
*HIVAL |
Indicates that all fields should be set to their highest possible value. For alphanumeric fields this means all bytes are set to hexadecimal X'FF'. For numeric fields this means all digits are set to 9 and the sign is made to be positive. |
|
*LOVAL |
Indicates that all fields should be set to their lowest possible value. For alphanumeric fields this means all bytes are set to hexadecimal X'00'. For numeric fields this means all digits are set to 9 and the sign is made to be negative. |
The following special options can be used in Visual LANSA applications:
|
The following table describes the behavior of RDMLX fields for special values. (Note that the behaviour of RDMLX Packed and Signed fields are the same as RDML fields of the same type.)
|
Specifies, for numeric expressions only, what precision is to be used for any intermediate work fields generated by the RDML compiler.
When a numeric expression is evaluated the RDML compiler, by default, attempts to compute the precision of any intermediate work fields. This is what happens when this parameter is not specified, or specified using the default values.
This logic is biased towards the precision of leading (or significant) digits. In some cases it may cause the loss of decimal precision. The PRECISION parameter is provided to allow you to manually specify the precision required in intermediate work fields.
For instance, if you multiply a 9,2 number by a 15,9 number, the logic determines that one of the numbers has 7 leading digits (the 9,2 one). Thus intermediate calculations will use a 15,8 work field which also has 7 leading digits. This may cause the loss of decimal precision.
To overcome this problem, and force intermediate work fields to use a predetermined precision, use the PRECISION parameter.
This parameter has 2 values. The first specifies the total number of digits (including decimals) that all intermediate work fields are to have. The second indicates how many of these are to be decimals. When specifying a PRECISION parameter you must specify both the total number of digits and the number of decimals.
For instance, PRECISION(15 6) indicates a total of 15 digits, 6 of which are decimals. Thus the work field has 9 leading digits and 6 decimals.
It would be unusual to code a PRECISION parameter in which the number of decimals required was less than the number of decimals in any individual field involved in the expression.
Also See
Specifies, for numeric and datetime expressions only, whether or not the result of the expression is to be "rounded up" before it is placed into the result field nominated in the FIELD parameter.
If this parameter is not specified, or specified using value *NO, then any decimal portion is truncated when it does not fit into the result field.
For instance, if you divide two integer values containing 3 and 2 and place the result into an integer field, you will get a result of 1.
However, if you use the ROUND_UP parameter, and an appropriate PRECISION parameter, you will get a resulting integer value of 2.
Always use the PRECISION parameter in conjunction with the ROUND_UP parameter to ensure that all intermediate work fields used to evaluate the expression have at least one more decimal position than the field nominated in the FIELD parameter.
If the intermediate work fields involved do not have at least one more decimal position than the field nominated in the FIELD parameter, then the ROUND_UP parameter will be ignored and treated as if ROUND_UP(*NO) was specified.
Datetime fields can have between 0 - 9 fractional seconds. The default behaviour on assignment of a long Datetime to a shorter Datetime will be to truncate fractional seconds. If ROUND_UP is specified, rounding of fractional seconds up will occur when this is appropriate.
The use of the ROUND_UP parameter equates directly to the RPG "half adjust" facility. In fact, using the ROUND_UP parameter simply causes the final mapping of the intermediate work field into the result field (in the translated RPG) to use the RPG "half adjust" option (provided that the intermediate work field has more decimal positions than the result field).
You may choose to refer to the appropriate RPG manual for more details of the mechanics of the "half adjust" facility.
|
Portability Considerations |
When this value is specified as *YES, you must specify an appropriate PRECISION value to ensure platform consistency in the results obtained. Failure to observe this rule may lead to rounding variances when your code is ported to different platforms. |