4.9 Portability Considerations
Process and Function Definitions
When working with processes, you should be aware of the following:
- 10 character names for processes will be truncated on the left to 8 characters. For this reason we recommend that you avoid the left side truncation of process names by having process names that are 8 characters or less.
- Special characters in names (i.e., characters that are not A - Z, 0 - 9 or _) are replaced according to position.
For example:
- A process named DEMPROC01 would be renamed EMPROC01
- A function named DC@FUNC would be renamed DC_FUNC
- A file named @FUNC would be renamed XFUNC.
and, interestingly:
- A process named CUSTPROC01 would be renamed STPROC01.
- A process named MUSTPROC01 would be renamed STPROC01.
- System commands can be attached to menus or action bars. However, these commands have meaning only to a specific operating system. This means that Windows commands have no meaning to IBM i just as IBM i commands will have no meaning in Windows.
- If you change the x_defppp.h file, all entry level processes should be recompiled
- DO NOT ignore warnings issued by the FFC (Full Function Checker) and code generators.
- If a partition has Display panel ids and Show date/time turned on, then for a given panel, if the panel id, date/time and panel title exceeds 60 characters the panel id will be dropped.
- Remember, functions are generated in C - refer to Generated Code C and SQL Considerations.
- Message handling is different
- Review function naming standards in Generated Code C and SQL Considerations.
Message Handling
When working with message handling with Visual LANSA, you should be aware of:
- Visual LANSA only supports message substitution variables of type *CHAR and *DEC. Other IBM i message types such as *HEX, *QTDCHAR and *BIN are not supported.
There are other IBM i internal message types such as *DTS, *SPP, etc that are not supported by Visual LANSA, just as they are not supported under IBM i in user defined messages.
- Visual LANSA is generally more forgiving and flexible than IBM i in handling substitution variables.
- Under IBM i every message substitution variable must be precisely defined and substituted in the message at execution time. This constraint is especially true of numeric values.
Rather than "cripple" Visual LANSA with the same very restrictive method, it was decided to leave it with a more flexible and open message substitution system.
The down side of this approach is that where Visual LANSA is building applications ultimately intended for IBM i systems, you must test message substitution variable processing under IBM i rather more rigorously than you have to under Visual LANSA.
- The "hiding" of packed decimal numeric message substitution values, inside what are to Visual LANSA alphanumeric fields, is not supported by Visual LANSA, in any way, shape or form.
- The use of IBM i special values, to control message text line formatting, etc., is not supported by Visual LANSA.