Page History
[ 
|../../index.htm#lansa/dsnb3_0010.htm]
You are here:
...
The Benefits
The full benefits of LANSA's centralized Repository will be achieved if certain standards are adopted and rigorously enforced. These include:
...
- 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.
...
- 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.
...