7.95.1 OVERRIDE Parameters

COLHDG

DECIMALS

DEFAULT

DESC

EDIT_CODE

EDIT_WORD

FIELD

INPUT_ATR

LABEL

LENGTH

OUTPUT_ATR

SHIFT

TO_OVERLAY

FIELD

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.

LENGTH

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

Type Notes for Length parameter *DEC or synonym *PACKED If the field is an RDML field, changing the length to 31 or higher will make the working field an RDMLX field. *SIGNED If the field is an RDML field, changing the length to 31 or higher will make the working field an RDMLX field. *DATE Dates are fixed size (always 10) incr/decr must be *NONE # to incr/decr must be *NONE *TIME Times are fixed size (always 8) incr/decr must be *NONE # to incr/decr must be *NONE *DATETIME 19, 21-29. The various lengths influence the number of fractional seconds. This must be made clear. A length of 19 means no fractional seconds, 21 - 29 means 1 - 9 fractional seconds. The DECIMALS parameter has no impact. incr/decr must be *NONE # to incr/decr must be *NONE

 

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

Notes:  

Until release 4PC E2, LANSA supported up to 15-digit long numeric fields. PC E2 introduced support for 30-digit long numeric fields. Please note that when you use this command to override the length of fields which are 15 digit or less with a length of greater than 15, specify *DBOPTIMISE in the OPTIONS parameter of the FUNCTION command to ensure backward compatibility.

Similarly, do not override the length of a field that is now at least 15 digits long with a length of 15 digits or less without specifying *DBOPTIMISE. This restriction arises from the fact that when support for longer numeric fields was introduced, existing I/O modules could not handle conversion of 8-byte fields to 16-byte fields or vice versa.

DECIMALS

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.

LABEL

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.

DESC

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.

COLHDG

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.

EDIT_CODE

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.

EDIT_WORD

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.

INPUT_ATR

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:

Attribute Description / Comments A P S AB Allow to be blank. Y Y Y ME Mandatory entry check required. Y Y Y MF Mandatory fill check required. Y Y Y M10 Modulus 10 check required.   Y Y M11 Modulus 11 check required.   Y Y VN Valid name check required. Y     FE Field exit key required. Y Y Y LC Lowercase entry allowed. If you do NOT set this attribute, refer to PC Locale uppercasing requested in Review or Change a Partition's Multilingual Attributes in the LANSA for i User Guide. Y     RB Right adjust and blank fill.   Y Y RZ Right adjust and zero fill.   Y Y RL Move cursor right to left. Y Y Y RLTB Tab cursor right/left top/bottom. Valid in SAA/CUA partitions only. Affects all screen panels in function. Y Y Y GRN Display with color green. Y Y Y WHT Display with color white. Y Y Y RED Display with color red. Y Y Y TRQ Display with color turquoise. Y Y Y YLW Display with color yellow. Y Y Y PNK Display with color pink. Y Y Y BLU Display with color blue. Y Y Y BL Display blinking. Y Y Y CS Display with column separators. Y Y Y HI Display in high intensity. Y Y Y ND Non-display (hidden field). Y Y Y RA Auto record advance field Y Y Y SREV Store in reversed format. This special attribute is provided for bi-directional languages is not applicable in this context. Y N N SBIN Store in binary format. This special attribute is provided for repository fields & is not applicable in this context. Y N N HIND HINDI Numerics. Display using HINDI numerals. Refer to Hindi Numerics in the LANSA for i User Guide. N Y Y CBOX * Check Box Y N N RBnn * Radio Button Y N N PBnn * Push Button Y N N DDxx * Drop Down Y N N

 

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

Attribute Description / Comments ABCH Action bar and pull-down choices PBPT Panel title PBPI Panel identifier PBIN Instructions to user PBFP Field prompt / label / description details PBBR Brackets PBCM Field column headings PBGH Group headings PBNT Normal text PBET Emphasized text PBEN * Input capable field (normal) PBEE * Input capable field (emphasized) PBCH Choices shown on menu PBSC Choice last selected from menu PBUC Choices that are not available PBCN Protected field (normal) PBCE Protected field (emphasized) PBSI Scrolling information PBSL Separator line PBWB Pop-up window border FKCH Function key information

 

Note: Normally only PBEN and PBEE would be specified as input attributes. Refer to SAA/CUA Implementation in the LANSA Application Design Guide more details of these attributes. Also note that only one color can be specified for a field. Use of colors may affect other attributes. Refer to IBM manual Data Description Specifications for more details. Keywords that should be reviewed are CHECK, COLOR and DSPATR.

OUTPUT_ATR

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:

Attribute Description / Comments A P S GRN Display with color green. Y Y Y WHT Display with color white. Y Y Y RED Display with color red. Y Y Y TRQ Display with color turquoise. Y Y Y YLW Display with color yellow. Y Y Y PNK Display with color pink. Y Y Y BLU Display with color blue. Y Y Y BL Display blinking. Y Y Y CS Display with column separators. Y Y Y HI Display in high intensity. Y Y Y ND Non-display (hidden field). Y Y Y SREV Store in reversed format. This special attribute is provided for bi-directional languages is not applicable in this context. Y N N SBIN Store in binary format. This special attribute is provided for repository fields & is not applicable in this context. Y N N Urxx User Defined Reporting Attribute. Provides access to IBM i DDS statements for printer files. Refer to User Defined Reporting Attributes in the LANSA for i User Guide. Y Y Y HIND HINDI Numerics. Display using HINDI numerals. Refer to Hindi Numerics in the LANSA for i User Guide. N Y Y CBOX * Check Box Y N N RBnn * Radio Button Y N N PBnn * Push Button Y N N DDxx * Drop Down Y N N

 

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

Attribute Description / comments ABCH Action bar and pull-down choices PBPT Panel title PBPI Panel identifier PBIN Instructions to user PBFP Field prompt / label / description details PBBR Brackets PBCM Field column headings PBGH Group headings PBNT Normal text PBET Emphasized text PBEN Input capable field (normal) PBEE Input capable field (emphasized) PBCH Choices shown on menu PBSC Choice last selected from menu PBUC Choices that are not available PBCN * Protected field (normal) PBCE * Protected field (emphasized) PBSI Scrolling information PBSL Separator line PBWB Pop-up window border FKCH Function key information

Note: Normally only PBCN and PBCE would be specified as output attributes. Refer to SAA/CUA Implementation in the LANSA Application Design Guide for more details of these attributes. Also note that only one color can be specified for a field. Use of colors may affect other attributes. Refer to IBM manual Data Description Specifications for more details. Keywords that should be reviewed are COLOR and DSPATR.

DEFAULT

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.

TO_OVERLAY

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.

SHIFT

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.