ESF User Exit modules, like
ESM Modules, are loaded at run time by ESF. In order for ESF to locate and load the correct type of module, and use it successfully,
certain rules must be followed. These rules depend on the operating system where
Enterprise Server is running.
By default ESF looks for exit modules in specific directories in the product installation area. For Windows, it looks in the
bin and
bin64 directories, for 32- and 64-bit processes respectively. For UNIX / Linux, it looks in the
lib directory. You can load the exit module from a different directory using ESF configuration options, as described in
To enable the ESF user exit through configuration.
ESF User Exit module files have a
base name, which is the part of the filename that identifies the module file. The base name is followed by a
suffix which includes the file extension (.DLL or
.so, and on UNIX/Linux platforms may include other characters either before or in the extension.
- For Windows platforms, your module must be a 32-bit DLL. The module
base name will be the filename up to the
.DLL extension. For example, the sample Referential Integrity module is supplied as
saf_refint_exit.dll, so its base name is
saf_refint_exit.
- For 64-bit Windows, if you will be using the exit with 64-bit Enterprise Servers, you will also need a 64-bit version of the
DLL.
- For UNIX and Linux platforms, your module must be a shared object. It must be built for thread-safe execution (for example
using the
cob -t command). You can create single-threaded and multi-threaded versions of the module, but we recommend avoiding the use of
separate threads in the module. For MFDS and 32-bit
Enterprise Server instances, you need a 32-bit version of the module; if you are running any 64-bit
Enterprise Server instances, you will need a 64-bit version. The module's
base name will be followed by a suffix which varies by platform, bitness, and threading mode.
- For 64-bit modules, the suffix begins with
64.
- For thread-safe modules, the suffix continues with
_t. If your module only comes in a thread-safe version (recommended), you can copy it or create links under both suffixes (with
_t and without it).
- The suffix then continues with the extension. On HP-UX, this is
.sl; on all other platforms it is
.so.
For example, suppose that you have created an ESF User Exit module and chosen the base name
my_exit for it.
On Windows, you would have a 32-bit version of this module named
my_exit.dll, and optionally a 64-bit version also named
my_exit.dll. Since they have the same name, they would have to be located in different directories, usually the product's
bin and
bin64 directories.
On UNIX, you would normally create four versions of your exit module and put them in the product's
lib directory:
| my_exit.so |
Single-threaded, 32-bit |
| my_exit_t.so |
Thread-safe, 32-bit |
| my_exit64.so |
Single-threaded, 64-bit |
| my_exit64_t.so |
Thread-safe, 64-bit |
The single-threaded versions can be thread-safe, as long as they do not create threads, so often
my_exit.so and
my_exit_t.so will be the same file, and similarly for
my_exit64.so and
my_exit64_t.so.