SQL/MX 3.2.1 Programming Manual for C and COBOL (H06.26+, J06.15+)

Program and Module Management
HP NonStop SQL/MX Release 3.2.1 Programming Manual for C and COBOL—663854-005
17-8
Managing Modules
Module search sequence
SQL/MX will search for the module file in the following locations, in the specified order:
1. The location of the program executable.
2. Locations specified in the OSS environment variable,
_MX_MODULE_SEARCH_PATH, followed by the locations specified in Define
=_MX_MODULE_SEARCH_PATH.
3. Each of the application DLL locations.
4. The system global module directory, /usr/tandem/sqlmx/USERMODULES.
Managing Modules
For an embedded SQL application to run properly, you must maintain the modules of
that application in either the /usr/tandem/sqlmx/USERMODULES directory or a
locally defined directory. For information on the consequences of mismanaged
modules, see Running an SQL/MX Application on page 15-72 (C/C++) or Running an
SQL/MX Application on page 16-51 (COBOL). For information on locally placed
modules, see Generating Locally or Globally Placed Modules on page 17-3.
Module management tasks include:

Securing the modules

Checking module dependencies by using the DISPLAY USE OF command

Removing modules
For more information, see the SQL/MX Release 3.2 Management Manual.
Module Management Behavior
By default, in SQL/MX Release 2.x, the SQL preprocessor generates a self-contained
application executable file that contains embedded module definitions. To obtain the
full benefit of the self-contained application code, avoid using the -x or -m options when
preprocessing embedded SQL source files of an application.
If you have applications that use module definition files, you can continue to generate
them by using the environment variable SQLMX_PREPROCESSOR_VERSION=800 and
certain preprocessor options, described under Influencing Module Management
Behavior. The SQL preprocessor generates a separate module definition file that
contains the translated SQL statements of an embedded SQL source file.
Note. You must ensure that the module file names are unique across all the locations. While
searching for the module files, if SQL/MX finds a module that matches the specified name, it
stops searching for the module file and might load the wrong module file.