2 2 Some Dictionary Guidelines

Some suggested guidelines for the definition of fields stored in the data dictionary are as follows:

Dictionary maintenance should be assigned as a task to only one person within a project team, or even to just one person within an organization.

Remember the concept of the corporate dictionary when specifying any field attribute. You are setting and standardizing a "corporate" definition of the field. When defining descriptions, column headings, labels, attributes or edit details this is particularly important. Try to forget the image of this field as it will appear on a specific screen or report.

Fields must be named as per the previous section and all "iii" variations of the field must be defined in the dictionary.

Use alphanumeric fields whenever possible. Use the rule "if you don't want to add it up it should be alphanumeric". LANSA provides many facilities which work more easily on alphanumeric fields (e.g.: generic searching).

Descriptions for all fields must be provided and should make use of both upper and lowercase characters. The description should apply at a corporate level rather than at a specific application level. Use CUA standards for word casing and phrasing whenever possible. Avoid making descriptions too long.

Column headings should be precise, use upper and lowercase characters , and not be significantly wider than the field itself. This avoids wasting space on reports:

should be Part

Part Number Status ==========> Status

XXX XXX

Part Customer

Number Number Date Due

Field labels should always be specified. Upper and lower case characters should be used.

Part Number

Cust Number

Date Due

Input attributes should not normally be specified. The system default attributes should be correct for most fields.

In SAA/CUA compliant partitions the following input attributes should always be specified (in addition to any system default attributes):

PBEN	Panel body normal input field. For normal or non-significant fields (e.g. Zip Code).
PBEE	Panel body emphasized input field. For important, significant or key fields (e.g. Customer Number).

Output attributes should not normally be specified. The system default attributes should be correct for most fields.

In SAA/CUA compliant partitions the following output attributes should always be specified (in addition to any system default attributes):

PBCN	Panel body normal output field. For normal or non-significant fields (e.g. Zip Code).
PBCE	Panel body emphasized output field. For important, significant or key fields (e.g. Customer Number).

An edit code or edit word should be provided for every numeric field defined in the dictionary. A suggested basic standard for edit code usage is:

Y	For any form of date field.
4	For numeric fields that will never be negative.
M	For numeric fields that may be negative.

HELP text must be input for all fields defined in the dictionary.

A standard HELP text form should be set up and used as the basis for all field level HELP text input into the dictionary. Use of attributes and $$ substitution variables can vastly reduce the amount of keying required to input a field's HELP text. (Refer to Using Substitution/Control Values in HELP Text in the LANSA for iSeries User Guide and Substitution/Control Values in the Technical Reference Guide for more details.)

Using a standard layout for all HELP text produces a consistency across your entire application. End users will become familiar and comfortable with the layout used.

Any field that appears on a screen or a report should be defined in the data dictionary, rather than in the specific RDML function which displays the screen or produces the report.

This point should be emphasized to programmers used to "external" field definitions only being available when they use a file actually containing the field. In LANSA any field defined in the data dictionary can be used in any RDML function.

Some of the advantages of using the LANSA data dictionary for more than just defining the fields (or elements) which make up the records of files in the database are:

Less repetition of "work" fields. After a period of time most required work fields will already be in the data dictionary.

Fields in the dictionary can have HELP text. Those defined in programs cannot. This is particularly important for fields intended for display.