2.3 Portability Considerations
Data Dictionary 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 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. Refer to SQL/ODBC Grammar:Keywords in Generated Code C and SQL/ODBC Considerations.