How You Can Use 3GL DLLs or Shared Libraries
After you have compiled and linked your 3GL procedure source code into DLLs (as described in the Programming Guide), you must deploy those DLLs with your application image files, and ensure that the appropriate 3GL DLLs are made available to the OpenROAD runtime system when your application is run.
Note: As used in this guide, “DLLs” refers to both dynamic link libraries and shared libraries.
When you run a 4GL application (using RunDBApp or RunImage), you provide a list of DLLs to be searched when resolving 3GL procedure calls. When your 4GL application calls a 3GL procedure, the OpenROAD runtime system searches each of the DLLs in the list until it finds one containing the specified procedure. It then binds and executes that 3GL code.
There are three ways to provide this list of DLLs to the OpenROAD runtime system:
• Using the II_LIBU3GL environment variable
Set this environment variable to contain your list of DLL names (and paths). If you specify multiple DLLs, separate them with a semicolon.
The following example illustrates setting the environment variable on a Windows platform:
set II_LIBU3GL=
c:\mypath\mylib.dll; c:\mypath2\mlib2.dll
• Using the -m parameter
The -m parameter for RunDBApp and RunImage lets you specify the name of a different environment variable to contain your DLL list. If it is present, the -m parameter overrides any existing specification of II_LIBU3GL.
• Using the 3GL Procedure Editor
In the 3GL Procedure Editor, you can specify the DLL name that contains the 3GL procedure. If the full path is not included, then the DLL must reside in a directory on the Path environment variable. At runtime, if the specified DLL is missing or does not contain the procedure, OpenROAD will not look at II_LIBU3GL or the -m parameter to resolve the procedure.