7 12 1 CHANGE Parameters

You are here:

7.12.1 CHANGE Parameters

FIELD

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:

Change Command Special Option	Meaning
*REMEMBERED_VALUE_FOR_USER	Remembers the value of the specified field for the current user in the context of the current form or function.
*REMEMBERED_VALUE_FOR_USER_IN_SYSTEM	Remembers the value of the specified field for the current user in all contexts (within the current PC system).
*REMEMBERED_VALUE_FOR_FUNCTION	Remembers the value of the specified field for all users in the context of the current form or function.
*REMEMBERED_VALUE_FOR_SYSTEM	Remembers the value of the specified field for all users in all contexts (within the current PC system).

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.)

Special Value	FIELD type	Notes
*NULL	Integer, Float, or Boolean	Treat as per Signed/Packed, i.e. ZERO (For Boolean ZERO means Off/False)
*NULL	Date or Datetime	1900-01-01
*NULL	Time	Midnight (00:00:00)
*NULL	Char, String, Binary, VarBinary, CLOB, BLOB	Empty string. Note that this is considered equivalent to *BLANKS for comparisons. BLOB & CLOB: Filename is empty.
*NAVAIL	Integer, Float, Time or Boolean	As for Signed/Packed, i.e. *ZERO
*NAVAIL	Date,Datetime, Binary, VarBinary	FFC Error as cannot put character string into these fields
*NAVAIL	Char, String, CLOB, BLOB	As for Alpha. BLOB & CLOB: Filename is "N/AVAILABLE".
*DEFAULT	Any	Field default
*SQLNULL	Any	If the field does not have the ASQN attribute it is an FFC Error. Otherwise it is okay.
HIVAL LOVAL	Integer	Set to the maximum value (positive) for the integer. Set to the minimum value (negative) for the integer. If field has SUNS attribute, minimum is *ZERO.
HIVAL LOVAL	Boolean	Set to On/True. Set to Off/False.
HIVAL LOVAL	Float, Date,Time	FFC Error as no logical upper or lower, especially for Date, as different databases support different values.
HIVAL LOVAL	Datetime	TIMESTAMP_HIVAL TIMESTAMP_LOVAL
REMEMBERED_VALUE	CLOB, BLOB, Date, Time, Datetime, Integer, Float, Boolean	Store in the registry as a string, as per current fields.
REMEMBERED_VALUE	Char, String	There may be a limit to the size of the string that may be stored (Char/String allow up to 64Kb). If there is a limit, and the field size is greater than the limit, FFC Error. If there is no limit, or the field size is less than the limit, store in the registry as a String, as per current fields.
REMEMBERED_VALUE	Binary, VarBinary	There may be a limit to the size of the string that may be stored (Binary/VarBinary allow up to 32Kb). If there is a limit, and the field size is greater than the limit, FFC Error. If there is no limit, or the field size is less than the limit, store in the registry as a Binary.

PRECISION

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

Field Types

ROUND_UP

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.