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

To delete the locally placed module file cat.sch.locmod1 from its local directory, enter:
rm /usr/local01/CAT.SCH.LOCMOD1
In some cases, you might want to remove all modules of an application. For specific details, see
the grouping technique of module management naming in the SQL/MX Programming Manual for
C and COBOL. To delete all the module files of a group, enter:
rm /usr/tandem/sqlmx/USERMODULES/*.*.MYGROUP^*
Consequences of Removing Module Files
If you try to run an application that refers to a deleted module, you might encounter problems.
Deleted Modules of Embedded SQL Programs in C, C++, or COBOL
If you try to run an embedded SQL program in C, C++, or COBOL that refers to a deleted module,
NonStop SQL/MX returns an error message that indicates that the module could not be opened
because it no longer exists:
ERROR[8809] Unable to open the module file name
After removing modules of an embedded SQL program in C, C++, or COBOL, you must again
SQL compile (that is, run mxcmp or mxCompileUserModule) the application’s modules. Otherwise,
the next attempt to run the application causes Error 8809. For more information, see the SQL/MX
Programming Manual for C and COBOL and the SQL/MX Messages Manual.
Converting Globally Placed Modules to Locally Placed Modules
You might mix globally placed modules and locally placed modules in a development environment.
However, in a production environment, you should choose globally placed modules or locally
placed modules and not mix the two. For more information about managing the coexistence of
globally placed modules and locally placed modules in the same environment, see the SQL/MX
Programming Manual for C and COBOL.
You can convert applications that use globally placed modules to those that use locally placed
modules in these environments:
• “Converting Applications in a Development Environment” (page 232)
• “Converting Applications in a Production Environment” (page 233)
Converting Applications in a Development Environment
To build the application in a development environment as if it were a new version of the application:
1. Before you create new locally placed modules, set the MXCMP_PLACES_LOCAL_MODULES
attribute ON in the SYSTEM_DEFAULTS table. Consequently, if you do not specify the -g
moduleLocal command-line option in mxCompileUserModule or mxcmp, a locally placed
module is created by default.
2. Change all build scripts for the application being converted so that the current directory is the
directory where the application executables exist. Alternately, change the build scripts so that
the SQL compilation step (mxcmp or MxCompileUserModule) uses the -g moduleLocal
command-line option.
3. Rebuild and test the application as you would any new version of an application.
4. When you deploy the application in the production environment, copy any compilation scripts
that replace the previous compilation scripts.
5. If you recompile the modules in the production environment, change the compilation script so
that it is consistent with the changes made in Step 2.
6. Remove the shared global copies of the now unused modules from the
/usr/tandem/sqlmx/USERMODULES directory.
7. Start the new version of the application.
232 Managing Database Applications