SQL/MX 3.2.1 Management Manual (H06.26+, J06.15+)

Converting Applications in a Production Environment
On a production system, convert applications that use globally placed modules to those that use
locally placed modules:
1. If you know which modules are used by programs that make up an application, skip this step.
Otherwise, use the mxCompileUserModule utility to determine which modules are used by
the programs that make up an application.
a. Copy the executable to an empty temporary directory.
b. From the OSS prompt, invoke mxCompileUserModule:
mxCompileUserModule -g moduleLocal
temp-directory/application-executable
The -g moduleLocal option of mxCompileUserModule generates a locally placed
module in the temporary directory. Using the temporary directory prevents disruptions to
the application and prevents overwriting of any existing modules.
c. Note the names of the module files that are generated in the temporary directory.
d. Delete the contents of the temporary directory.
If you are not using embedded module definitions, you can find the name of the modules
in the module statement of the Module Definition file (MDF).
2. Copy the globally placed modules you want to convert to the directory where you will deploy
the application. Do not move the globally placed modules because this would disrupt the
existing application environment.
If a module is used by more than one applications and all modules are being converted to
locally placed modules, copy the globally placed modules to each application directory that
uses the common module.
3. If it has not yet been done, copy the executables for each application associated with a locally
placed module to the same local directory as the module.
4. Before you create any new modules for the local environment, set the
MXCMP_PLACES_LOCAL_MODULES attribute ON in the SYSTEM_DEFAULTS table.
5. Depending on the application environment, use the appropriate management commands to
drain the currently executing applications, and restart the applications using the copy in the
local environment.
CAUTION: If a module is used by more than one application and at least one of those
applications continues to use globally placed modules, do not remove the global copy of the
module. Removing the global copy of a module used by an application disrupts the application.
6. Remove the shared global copies of the now unused modules. See “Removing Modules”
(page 231).
Managing Module Files and Their Applications During Fallback From SQL/MX
Release 3.2
For more information about managing modules when you fall back to a previous release of NonStop
SQL/MX, see the SQL/MX Installation and Upgrade Guide.
Backing Up and Restoring Programs
Make backing up and restoring programs part of both the day-to-day maintenance of program
files and the high-level strategy for backing up and restoring the entire database. The former should
include periodically storing copies of programs to safe locations (such as another disk, magnetic
tape, or another system). As a rule, you should back up programs before you make major changes
to the database.
Backing Up and Restoring Programs 233