Before using the following BIF examples, please read these warnings:
The supplied examples are in C and have been tested using Microsoft Visual C/C++ 6.0. If you do not use one of these compilers, you may encounter complex errors that will waste a lot of your time.
Note: The version of MS compiler bundled with Visual LANSA is optimized for compiling objects within the LANSA development environment only. To compile your own C/C++ Built-In Functions, you may need to install a full Microsoft compiler, typically by installing an appropriate version of Microsoft's Visual Studio product.
You, the developer, are TOTALLY and ABSOLUTELY responsible for the development, coding, testing, portability and maintainability of your user defined Built-In Functions. Although your LANSA distributor may be willing to help you design and develop user defined built-ins, they are not, in any way at all, obliged to do so.
LANSA Pty Ltd, the developers of the LANSA products, are always available to help with the design, coding, testing and portability of user defined Built-In Functions. Quotes for such work may be obtained by contacting LANSA Support at lansasupport@LANSA.com.au.
The Visual LANSA user defined Built-In Function facilities are much more powerful than the equivalent LANSA for i facilities. When producing Built-In Functions that use advanced facilities under Visual LANSA (that must also run under IBM i in RPG/400) you should carefully ensure that, during the design phase, you can in fact actually implement such advanced features in RPG/400.
Please note this warning carefully as Visual LANSA implementation opens up a whole new set of possibilities because it is generated in C, using a more advanced architecture than the LANSA for i RPG/400 implementation.
When you create a Built-In Function that has to run under IBM i as well as under Windows and Linux, you must ensure that any Windows and Linux feature that you use can also be "emulated" under IBM i.
For example, in a Visual LANSA user defined Built-In Function you can receive "variable" working lists and then retrieve (at run time) the number of columns in the list and the names, types, lengths and decimal precisions of each column in the list.
No such capabilities exist in the RPG/400 version. RPG/400 largely precludes the use of such "dynamic" facilities.