Compile your Built-In Function on IBM i
To compile and link it into a service program:
--> Edit the .C file via a standard source editor
| copy the .C and .ISB files to
| <base path for LANSA system>/x_lansa/source
| (base path for LANSA system is often <program library name>)
| (Use lowercase filenames, e.g. u_bif445.c)
|
|
| From a command entry screen with the LANSA program library
| in the library list:
| CALL DCXP8731 (U_BIFnnn x)
| (where x is Y if the service program is to be debug capable)
|
|
--- If errors detected
If no errors, test by executing an RDML function
that uses your built-in function.
Backup your .c and .ISB files and your U_BIFnnn service program.
(U_BIFnnn service program is created in the LANSA program library).
Tips & Techniques
- The resulting object is a DLL. It is called dynamically by your Visual LANSA application, so there is no need to recompile your Visual LANSA RDML function when you change your Built-In Function, but you should exit and restart your x_run "session", so that the new dynamic address can be resolved for the DLL.
- You should not recompile a DLL while it is active or in use.
The locking of an "in use" DLL is performed by the operating system. If you are testing a DLL and it fails many times it is possible that the operating system will get confused and indicate that the DLL is in use, even when it is not. To solve this problem, reboot your PC.
Typically this problem is indicated by some sort of "Cannot create run file" type of error during the compile and link process. The file is locked by the operating system and the compiler/linker cannot overwrite it.
- If your Built-In Function needs to work on Windows and Linux, try to use standard C functions. If you need to write code which is different (for example, to include different header files), use the following macros to distinguish between Windows and Linux code:
/* Windows code */
#ifdef X_OPERATING_SYSTEM_WIN
…
#endif
/* Standard code */
…
/* Linux code */
#ifdef X_OPERATING_SYSTEM_Linux
…
#endif