SQL/MX Programming Manual for C and COBOL (G06.24+, H06.03+)

Program and Module Management
HP NonStop SQL/MX Programming Manual for C and COBOL—523627-004
17-14
Targeting Example for C: Using ModuleTableSet
(MTSS)
If you want to rebuild the application to target a set of production files, you can do so
without changing the source file (empcnt.sql):
1. Use the OSS add_define command to give =DEPT and =EMPLOYEE the table
location to target a different set of files:
add_define =DEPT class=MAP file=\\PROD.\$DATA.HR1.DEPT
add_define =EMPLOYEE class=MAP \
file=\\PROD.\$DATA.HR1.EMPLOYEE
2. Invoke the preprocessor, specifying a module-tableset-specification-
string with the -g option and a different value:
mxsqlc empcnt.sql -c empcnt.c -m empcnt.m \
-g moduleTableSet=PROD
3. The previous step again produces a pure C file, empcnt.c, and a module
definition file named empcnt.m.
The c89 utility compiles and links the C file, producing an executable, and the
SQL/MX compiler compiles empcnt.m. The executable is named
empcnt_prod.exe to denote that it was prepared to use the module files that are
targeted to use the production set of tables.
Because a module-tableset-specification-string was specified, the
module file produced by the SQL/MX compiler is:
/usr/tandem/sqlmx/USERMODULES/CAT.SCH.^EMP_CNT_MODULE^PROD^
After building the application for both sets of tables, you can execute, in any order,
either compiled executable (empcnt_test.exe or empcnt_prod.exe) with its
compiled SQL.
When empcnt_test.exe is run for the first set of tables, you must set up DEFINEs
=DEPT to reference \TEST.$DATA.HR1.DEPT and =EMPLOYEE to reference
\TEST.$DATA.HR1.EMPLOYEE.
When empcnt_prod.exe is run, you must set up DEFINE’s =DEPT to reference
\PROD.$DATA.HR1.DEPT and =EMPLOYEE to reference
\PROD.$DATA.HR1.EMPLOYEE.
You can set up DEFINEs to reference the production environment set of tables, and
then use the empcnt_test.exe executable (or vice versa). The result of this action is
Note. These two files (empcnt.c and empcnt.m) overwrite the C and module definition
files that were written the first time the application is built. mxsqlc does not check for the
existence of identically named files before it writes its output files. Although you can
specify different output file names to avoid this situation, you might not care that the
second C and module definition files overwrite the first build’s files because they are easily
reproducible. However, if you want to preserve the output of the preprocessor and avoid
overwriting files, see Targeting Example for C: Using Build Subdirectory
on page 17-15 or
Targeting Example for COBOL: Using a Build Subdirectory on page 17-18.