7.95.1 OVERRIDE Parameters

COLHDG

DECIMALS

DEFAULT

DESC

EDIT_CODE

EDIT_WORD

FIELD

INPUT_ATR

LABEL

LENGTH

OUTPUT_ATR

SHIFT

TO_OVERLAY

Specifies the name of the field which is to be overridden. The field name must start with a # and be defined in the LANSA data dictionary.

Specifies the length to which the field is to be overridden. If the value *SAME is specified the length of the field is not to be overridden. For specific information on allowable field lengths see Field Types

"Incr/decr" value is used in conjunction with *SAME on the length parameter. The purpose of this field is to allow the length to be incremented or decremented by a specific amount. Permissible values are *PLUS, *MINUS and *NONE.

• *PLUS specifies that the field length attribute is to be increased.

• *MINUS specifies that the field length attribute is to be decreased.

• *NONE specifies that the field length attribute is to remain the same.

"# to incr/decr" value is used in conjunction with the *SAME value on the length parameter and is directly related to the "incr/decr" value. The purpose of this field is to specify the value by which the field length value is to be increased or decreased. Permissible values for this field are a numeric value or the value *NONE.

Specifies the number of decimal positions to which the field is to be overridden. If the value *SAME is specified then the decimal positions are not to be overridden. Otherwise a value in the range 0 to 63 must be specified.

"Incr/decr" value is used in conjunction with *SAME on the decimals parameter. The purpose of this field is to allow the decimal positions value to be incremented or decremented by a set amount. Permissible values are *PLUS, *MINUS and *NONE. *PLUS specifies that the field decimal positions attribute is to be increased. *MINUS specifies that the field decimal positions attribute is to be decreased. *NONE specifies that the field decimal positions attribute is to remain the same.

"# to incr/decr" value is used in conjunction with the *SAME value on the decimal positions parameter and is directly related to the "incr/decr" value. The purpose of this field is to specify the value by which the field decimal positions value is to be increased or decreased. Permissible values for this field are a numeric value or the value *NONE.

Specifies the 15 character label which should be assigned to this field. *SAME indicates the label is not to be overridden. In all other cases specify the override label in quotes.

Specifies the 40 character description that should be assigned to this field. *SAME indicates the field description is not to be overridden. In all other cases specify the override description in quotes.

Specifies the 3 x 20 character column headings that should be assigned to this field. *SAME indicates the column headings are not to be overridden. In all other cases specify the 3 override column headings required in quotes.

Specifies the field edit code for numeric fields. *SAME indicates the field edit code is not to be overridden. In other cases specify one of the edit codes from the list below as the override edit code:

Fields of type Integer, Signed, or Packed may have an Editcode or Editword, or may leave both as *SAME. However, Integer does not allow edit codes W and Y. All other field types must have EDIT_CODE(*SAME) EDIT_WORD(*SAME).

Edit codes supported by LANSA are shown in Standard Field Edit Codes.

Specifies the override edit word to be assigned to the field. *SAME indicates that the edit word is not to be overridden. In other cases specify the override edit word as required.

Use of edit words should only be attempted by experienced users as the validity checking done by LANSA is unsophisticated.

Fields of type Integer, Signed, or Packed may have an Editcode or Editword, or may leave both as *SAME. All other field types must have EDIT_CODE(*SAME) EDIT_WORD(*SAME).

Note that when overriding a field length and using EDIT_WORD(*SAME) you are specifying that the edit word associated with the data dictionary should be used. However, if the length or number of decimal positions used are different to the data dictionary definition the associated edit word may be invalid. In such cases it will be necessary to override the edit word as well.

Note also that the operating system handles edit words involving floating currency symbols on screen panels differently to how they are handled on reports. In such cases, it is suggested that a separate field (or a "virtual" field) is used for report production.

When an edit word is defined in LANSA via the RDML command language it should be enclosed in triple quotes as opposed to single quotes.

For example:

Correct method for overriding an edit word for a 5,2 numeric field requiring a trailing %:

   OVERRIDE FIELD(#INCREASE) TYPE(#DEC) LENGTH(5) DECIMALS(2)
            LABEL('Sales Increase') EDIT_WORD('''   .  %''')

Incorrect method for overriding an edit word for a 5,2 numeric field requiring a trailing %:

   OVERRIDE FIELD(#INCREASE) TYPE(#DEC) LENGTH(5) DECIMALS(2)
            LABEL('Sales Increase') EDIT_WORD('   .  %')

Refer to IBM manual Data Description Specifications for more details. See keyword EDTWRD.

Specifies the input attribute overrides that are required. *SAME indicates that no override of input attributes is required.

For information on allowable attributes for RDMLX fields see Field Types.

Valid input attributes for types A (alphanumeric), P (packed), and S (signed) are:

Attributes marked with an * represent the field with the corresponding GUI WIMP construct. Refer to GUI WIMP Constructs in the LANSA for i User Guide for more information

In partitions that comply with SAA/CUA guidelines the following attributes may be used as well (and are in fact preferred to those described above):

Specifies the output attribute overrides that are required. *SAME indicates that no output attribute overrides are required. In other cases specify the required output attribute overrides from the list below:

For information on allowable attributes for RDMLX fields see Field Types

Valid output attributes for types Alpha (A), Packed (P), and Signed (S) are:

Attributes marked with an * represent the field with the corresponding GUI WIMP construct. Refer to GUI WIMP Constructs in the LANSA for i User Guide for more information

In partitions that comply with SAA/CUA guidelines the following attributes may be used as well (and are in fact preferred to those described above):

Specifies the default value which is to apply to the field. *SAME indicates that no override of the field's default value is required. In other cases specify the override default value that is to apply to the field.

For information on what DEFAULT(*DEFAULT) means for RDMLX fields see Field Types

Default values specified can be:

• A system variable such as *BLANKS, *ZERO, *DATE or any other specifically defined at your installation.

• An alphanumeric literal such as BALMAIN.

• A numeric literal such as 1, 10.43, -1.341217.

• A process parameter such as *UP01.

• Another field name such as #ORDNUM.

Specifies that the field being overridden is to fully or partially overlay (ie: occupy the same storage locations) as the field referenced in this parameter.

It is invalid for RDMLX fields to be overlaid or overlay another field.

*NONE, which is the default value, indicates that the field is to occupy its own storage area and not to overlay any other field.

The only other allowable value that can be specified here is the name of another field defined in this program or the data dictionary, optionally followed by a starting position.

The TO_OVERLAY parameter is a powerful facility that allows a field to occupy the same storage (ie: memory locations) as another field. The power of this parameter means that you must understand exactly what it causes to happen and what problems you may cause yourself in using it.

The following notes and comments should be read in full before attempting to use this parameter:

• You must NOT overlay a field onto a field that is itself overlaid onto another field. This is NOT checked by the full function checker and may cause a compile failure.

• You should fully understand the IBM i data storage formats of character, signed/zoned decimal and packed decimal before attempting to overlay fields of varying types. Overlaying of fields means that you can easily cause invalid decimal data to be placed into decimal fields, thus causing your program to fail in an unpredictable manner.

• The start position component of this parameter allows you to overlay just a part of a specific field, rather than its entire length. The start position is a full byte position, even when using packed decimal fields. When you specify a start position you MUST ensure that you do not overlay the field beyond the end position of the field being overlaid.
  
  This is NOT checked by the full function checker. Failure to observe this rule can cause dangerous and unpredictable results.

• Array index fields must not be overlaid on or by other fields (in any context).

• A packed decimal field of even length can be overlaid on another field, however the RPG compiler will always interpret the overlaying field as the next highest odd length. For example, if the data dictionary contains 2 packed decimal (type P) fields of length 6,0 called #DEC6 and #OVR6 then the following will cause #DEC6 to be treated by the RPG compiler as a packed decimal (6,0) value:

            OVERRIDE FIELD(#OVR6) TO_OVERLAY(#DEC6)

         The #OVR6 will be treated by the RPG compiler as a packed decimal (7,0) value. There is no memory length problem here, both fields require 4 bytes of memory to be stored, it is just the way that the RPG compiler works that may cause a presentation length problem on reports.

• When the data validation commands RANGECHECK, VALUECHECK, DATECHECK, CALLCHECK, CONDCHECK, FILECHECK or SET_ERROR are used on an overlaying field they also set an error for the overlaid field. For example, if the data dictionary contains fields #INPUT (character length 3), #INPC1 (character length 1) and #INPC3 (character length 1), then this code accepts a 3 character field (#INPUT) from the workstation and validates that the first character is an A, B or C and also that the last character is an X, Y or Z:

                  OVERRIDE FIELD(#INPC1) TO_OVERLAY(#INPUT 1)
                  OVERRIDE FIELD(#INPC3) TO_OVERLAY(#INPUT 3)
                  REQUEST FIELDS(#INPUT)
                  BEGINCHECK
                  VALUECHECK FIELD(#INPC1) WITH_LIST('A' 'B' 'C')
                  VALUECHECK FIELD(#INPC3) WITH_LIST('X' 'Y' 'Z')
                  ENDCHECK

         When an error is triggered against overlaid fields #INPC1 or #INPC3 by the VALUECHECK commands, it is also triggered against the overlaid field #INPUT. This means that when the REQUEST command is (re)executed in an error situation, field #INPUT will be displayed in reverse video.

• You should consider the following points, if you are continually overriding fields into overlay positions in every program such as in this example:

                  OVERRIDE FIELD(#COMPANY) TO_OVERLAY(#ACCOUNT 1)
                  OVERRIDE FIELD(#DEPTMENT) TO_OVERLAY(#ACCOUNT 4)
                  OVERRIDE FIELD(#SECTION) TO_OVERLAY(#ACCOUNT 6)
                  OVERRIDE FIELD(#SUBACC) TO_OVERLAY(#ACCOUNT 7)

• The data model and/or function model behind your entire design may be slightly suspect. Clearly, there are 4 separate "elements": a company, a department, a section and a "subaccount" number. Why are they being aggregated into a field called "account"? Is this really necessary? Is it just being done because this is the way it was done before? What are the alternatives? Have they been fully considered and investigated? Do they offer a new and easier to understand system perspective to end users of the system?

• If the structure is to be implemented, then possibly the overlay logic should be moved to the "virtual field" area, thus centralizing the logic and saving programmers from having to repeat and maintain the logic in every program.

Specifies the keyboard shift to be used to override any existing keyboard shift. If no keyboard shift is specified then the value *SAME is assumed.

For information on what values of SHIFT, apart from *DEFAULT, are valid for each working field type see Field Types.

For working fields of type Boolean, SHIFT must be *DEFAULT.

*SAME indicates that the keyboard shift is not to be overridden.

Refer to the IBM manual Data Description Specifications for more details. Position 35 for display files is the entry that should be reviewed.