6.2 The Repository

The Benefits

The full benefits of LANSA's centralized Repository will be achieved if certain standards are adopted and rigorously enforced. These include:

• Control who is authorized to add and update details in the dictionary.

• Make sure elements and fields are defined only once.

• Ensure that whoever is authorized to maintain the repository details is committed to the concept of using a corporate-wide vision. Every element should be considered for its impact on the whole organization, not just for one program in one application.

• All designers and application developers should refer to the repository for the definition of an element.

Using a centralized Repository may extend the design phase of a project but this will easily outweigh the benefits achieved during the development and maintenance phases.

Consistency in validity checking, error messages and the names used on screens and reports and provides immeasurable benefits to end users.

Some Repository Guidelines

Some suggested guidelines for the definition of fields stored in the repository 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).

• All packed decimal fields should be of odd length.

• 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

                     XXX                                  XXX

                     XXX                                  XXX

 

• Only one or two lines of the column heading should be used. For example:

                   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 i 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 repository can be used in any RDML function.
  
  Some of the advantages of using the LANSA repository 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.

• More comprehensive cross-referencing capabilities.

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

Portability Considerations for Repository Definitions

When working with fields, you should be aware of the following:

• The following field attributes are supported: ND LC VN AB RZ M10 M11 FE RA PBIN PBFP PBBR PBCM PBGH PBNT PBET PBEN PBEE PBCN PBCE PBSI SBIN

• Numeric fields that may contain a negative value and are presented on user interface panels should always have an edit code or edit word specified. e.g. IBM i presents -1 as "J" but X_UIM (Visual LANSA  User Interface Manager) presents it as "1"

• Numeric fields that have a decimal component and are presented on user interface panels should always have an edit code or edit word specified such that a decimal point is always shown.

• A complex logic check that calls a 3GL program is not supported.

• Some system variables have fixed values because they have no real meaning outside of an IBM i context. For example:

*JOBD is always QBATCH

*CPU_NUMBER is always 0

*GUIDEVICE is always Y

*OUTQNAME is always QPRINT

*OUTQLIB is always QGPL

*MSGQNAME is always the job name

*MSGQLIB is always QGPL

*GROUP_OWNER is always *USRPRF.

 

• Some system variables have new values. For example*CPUTYPE can vary depending on the platform.

• When working with fields on files that have the attribute Convert special characters in field names set to Yes, you should be aware of the following when table columns are created from the field names:

• Special characters in names (i.e., characters that are not A - Z, 0 - 9 or _ ) are replaced according to position. For example: a field named DC@FLD would be renamed DC_FLD; a field named @FLD would be renamed XFLD.

• Names that are recognized as SQL keywords will have their second character changed to an underscore. For example: a field named SECTION would be renamed S_CTION.

• Avoid naming any new objects with a name that conflicts with an SQL keyword. Again this prevents automatic renaming.