The second screen presented when creating a new field definition looks like this:

 This screen may be "pre-filled" with information. This occurs when:

• another field has been "copied" using options on the first screen.
• you are creating more than one field. Most input fields retain the values used to create the previous field.
• the new field has either been "copied" or refers to another field. The Extended Options action box will be displayed. This will allow you to select certain copy options. For example, if the option to copy help text is selected, all the help text for the copied or referenced field will be copied to the help text for the new field.

Input Options when Creating a New Field

These input options apply when creating a new field or amending an existing one:

Field Name

Mandatory. If not specified field creation cycle ends.

• First character must be A->Z, $, or @.
• Subsequent characters must be A->Z, 0-9, $, @, # or _ (underscore).
• Use of @ anywhere in field name is not recommended.
• Use of # as first character is not allowed.
• No imbedded blanks are allowed in the field name.
• Use alias name for COBOL or PL/1 long names.
• Use of names of more than 6 characters in length is not recommended. Although LANSA will create and use files that contain field names of more than 6 characters in length it may be difficult to use such files in your own RPG application programs. Refer to the RPG Programmer's Reference Guide.
• Avoid the use of field names like SQLxxx, as this may cause problems when used in functions that use SQL (Structured Query Language) facilities. (i.e. Command SELECT_SQL.)

Type

Mandatory unless reference field is specified. Must be A (alphanumeric), S (signed) or P (packed) for RDML fields. Additional field types for RDMLX fields are H (char), Z (DateTime), B (binary), E (date), M (time), I (integer), F (float), 1 (string), 2 (VarBinary), 3 (CLOB) and 4 (BLOB).

Keyboard Shift

Optional. If not specified, defaults to blank for an alphanumeric field and Y for a numeric field. Valid keyboard shifts are:

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

Length

Mandatory unless reference field is specified.

• Length is number of characters for type A.
• Total number of digits (including decimals) for type P or S.
• For type P this is NOT the same as the field byte length.
• The use of odd numbered lengths is recommended for type P or S.
• For type A must be in range 1 to 256.
• For type P or S must be in range 1 to 30.

Decimal Positions

Mandatory for type P or S unless reference field is specified. Ignored for type A (always set to zero). Must be in range 0 to 9. Must be less than or equal to length (total number of digits).

Reference Field

Optional. This is the name of the field which should be "referred" to, to determine the type, keyboard shift, length,  number of decimal positions, default value, edit code, edit word, input attributes and output attributes that are to be used in the definition of this new field.

These values are protected while the reference field is specified and they are automatically updated if the reference field is changed. Initially the prompt process/function is inherited but you can change these details if required.

The reference field must already exist in the dictionary before you can enter it here.

If the flag *IMPREFFLDNOPROP is in system data area DC@OSVEROP, the input and output attributes will not be protected but will still be updated if the reference field is changed. This is to provide compatibility with previous versions. For more information, refer to Version Dependency Data Area DC@OSVEROP.

Reference fields are mostly used to specify an attribute that is common to many similar fields. For example, a shipping company deals with many different types of ports, so they could define a field called PORT as an alphanumeric field of 5 characters.

Subsequent port fields such as PORTL (port of loading) or PORTD (port of discharge) would "refer" to PORT. If the definition of PORT was changed from 5 to 6 characters, both PORTL and PORTD would be changed automatically.

Description

Optional. If not specified, field name is used as default. Use of CUA standards for identification are recommended.

Label

Optional. If not specified, field name is used as default. Use of CUA standards for identification are recommended.

Column Headings

Optional. If not specified, field name is used as default. Use of CUA standards for identification are recommended.

Output Attributes List

Optional. If not specified defaults to either alpha (type A) or numeric (type P or S) system default values. Further information on output attributes is contained in DEFINE Parameters and OVERRIDE Parameters in the Technical Reference.

Valid output attributes are:

Attributes marked with * represent the field with the corresponding GUI WIMP construct. Refer to Guidelines, Hints, and Tips in GUI WIMP Constructs for more information.

In partitions that comply with SAA/CUA guidelines, these attributes may be used as well (and are in fact preferred to those in the previous list):

*Normally only PBCN and PBCE would be specified as output attributes. Refer to the IBM i SAA/CUA Implementation in the LANSA Application Design Guide for details of these attributes.

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 details. Keywords that should be reviewed are COLOR and DSPATR.

Input Attributes List

Optional. If not specified defaults to either alpha (type A) or numeric (type P or S) system default values. Further information on input attributes is contained in DEFINE Parameters and OVERRIDE Parameters in the Technical Reference.

Valid input attributes are:

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

* Normally only PBCN and PBCE would be specified as output attributes. Refer to the IBM i SAA/CUA Implementation in the LANSA Application Design Guide for details of these attributes. Note also 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 details. Keywords that should be reviewed are CHECK, COLOR and DSPATR.

Edit Code

Optional. However, use of edit codes for all numeric fields (type S or P) is strongly recommended. Edit codes supported under this version of LANSA are shown in Standard Field Edit Codes in the Technical Reference Guide.

Edit Word

Optional. Use of edit words should only be attempted by experienced users as the validity checking done by LANSA is unsophisticated. Invalid edit words may pass undetected into the system and cause subsequent failures when attempting to create database files or compile programs.

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

Default Value

Optional. If not specified, it defaults to *BLANKS (blanks) for alphanumeric fields (type A) and *ZERO (zero) for numeric fields (type P or S). Default value specified can be:

• A system variable such as *BLANKS, *ZERO, *DATE or any other specifically defined at your installation.
• An alphanumeric literal (in quotes) such as 'STATUS', 'JONES' or 'Australia'.
• A numeric literal such as 1, 10.43, -1.341217.

Optional Alias Name

Optional. If specified it must NOT:

• Be the same as any other field's name (including the field that is being created or amended).
• Be the same as any other field's alias name.

In other words, all field names and all alias names must form a unique list of names. The alias name facility is provided primarily for installations that use the COBOL or PL/1 programming languages. Refer to the specific IBM-supplied program reference manuals for the use of the ALIAS keyword. Name must conform to field naming conventions like the field name. COBOL or PL/1 language naming conventions are NOT checked.

System Field

Mandatory, but always pre-filled to NO. Allowable values are:

YES: This field is a system field and cannot be deleted from the data dictionary unless this field is specifically changed to value "NO". This value is used by LANSA to identify all the required LANSA system fields so that they will not be accidentally deleted from the data dictionary. It is also used to identify all the LANSA system fields that may be copied when creating a new LANSA system partition.

NO: This field is not a system field and can therefore be deleted from the data dictionary if there is no reason for the delete operation being refused (e.g. field is used in a file definition, etc).

Prompting Process/Function

Optional. If specified, these values nominate an RDML process and function that should be invoked to handle a "prompt request" made against the field being defined or changed. When specifying the name associated with a prompting process and function it is recommended that the process name be nominated as *DIRECT. This indicates to the prompt control procedures that the nominated function can be called in "direct" mode, without having to go through the associated process "controller".

Using *DIRECT has positive performance benefits, but when a prompting function is to be invoked this way it must use the FUNCTION OPTIONS(*DIRECT) command. Refer to CALL Comments / Warnings and FUNCTION Examples in the Technical Reference Guide for details of direct mode invocation of functions. A "prompt request" is made against a field when the user positions the screen cursor into a field, on its label, or on one of its column headings, and then uses the PROMPT function key. Normally the prompt function key is F4, but it may be assigned differently on your system.

When a reference field has been specified, initially the prompt process/function is inherited from the referenced field, but you can change it if required.

If the reference field's prompt process/function is changed, any of the fields referring to it which have the same prompt process/function (before the referenced field is changed) also have their prompt process/function updated.

For technical details of Prompt_Key Processing please refer to the Technical Reference Guide. For examples of prompting processes and functions please refer to What Happens When the PROMPT Key is Used in the LANSA Application Design Guide.

Initial Public Access

Mandatory, but always pre-filled to NORMAL. Allowable values are:

NORMAL: Other users can use this field, but cannot change or delete its definition in/from the data dictionary.

ALL: Other users can use this field and can also change or delete its definition in/from the data dictionary.

NONE: Other users cannot use this field, nor can they review, change or delete its definition in/from the data dictionary.