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-17
Targeting Example for COBOL: Using
ModuleTableSet (MTSS)
1. Use the OSS add_define command to give =DEPT and =EMPLOYEE the desired
values:
add_define =DEPT class=MAP file=\\TEST.\$DATA.HR1.DEPT
add_define =EMPLOYEE class=MAP
file=\\TEST.\$DATA.HR1.EMPLOYEE
2. Invoke the preprocessor, specifying a module-tableset-specification-
string with the -g option:
mxsqlco empcnt.ecbl -c empcnt.cbl -m empcnt.m \
-g moduleTableSet=TEST
3. The previous preprocessor step produces a pure COBOL file (empcnt.cbl) and a
module definition file (empcnt.m). The nmcobol utility compiles and links the
COBOL file and produces an executable (empcnt_test.exe), and the SQL/MX
compiler compiles empcnt.m. (The user directed nmcobol to name the
executable empcnt_test.exe to indicate that it was prepared for the TEST table
set). Because a module-tableset-specification-string is specified, the
module file produced by the SQL/MX compiler is:
/usr/tandem/sqlmx/USERMODULES/CAT.SCH.^EMP_CNT_MODULE^TEST^
If you want to rebuild the application to target a set of production files, you can do so
without changing the source file empcnt.ecbl:
1. Use the OSS add_define command to give =DEPT and =EMPLOYEE the values
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:
mxsqlco empcnt.ecbl -c empcnt.cbl -m empcnt.m -g \
moduleTableSet=PROD
3. The previous step again produces a pure COBOL file (empcnt.cbl) and a
module definition file (empcnt.m).
The nmcobol utility compiles and links the COBOL file, producing an executable
(empcnt.exe), and the SQL/MX compiler compiles empcnt.m.
Note. These two files (empcnt.cbl and empcnt.m) overwrite the COBOL and module
definition files the first time the application is built because mxsqlco does not check for
the existence of identically named files before it writes its output files. You can specify
different output file names to avoid this situation. You might not care that the second
COBOL and module definition files overwrite the first build’s files because they are easily
reproducible. Targeting Example for COBOL: Using a Build Subdirectory
on page 17-18
outlines a method to avoid overwriting files.