Page History
7.95.1 OVERRIDE Parameters
|
|---|
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
...
| Note |
|---|
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. |
|
|---|
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.
...
"# 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:
...
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.
...
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.
...
| Note |
|---|
| 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. |
|
|---|
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:
...
| Note |
|---|
| 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. |
|
|---|
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.
...
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.
...
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.
...