SQL/MX 3.1 Programming Manual for C and COBOL (H06.23+, J06.12+)

Program and Module Management
HP NonStop SQL/MX Release 3.1 Programming Manual for C and COBOL—663854-001
17-20
Targeting Example for COBOL: Using a Build
Subdirectory
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.
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^PROD^
After building the application for both sets of tables, the user can execute either
compiled executable and its corresponding compiled SQL.
When the empcnt_test.exe is run for the first set of tables, the user must again set
up DEFINEs =DEPT to reference \TEST.$DATA.HR1.DEPT and =EMPLOYEE to
reference \TEST.$DATA.HR1.EMPLOYEE.
The other set of tables is targeted if the user runs empcnt_prod.exe and sets up
DEFINEs =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
that the compiled SQL plans are read from module:
/usr/tandem/sqlmx/USERMODULES/CAT.SCH.^EMP_CNT_MODULE^TEST^.
These plans refer to the test environment tables, \TEST.$DATA.HR1.DEPT and
\TEST.$DATA.HR1.EMPLOYEE. However, the SQL/MX executor performs late name
resolution (see Late Name Resolution
on page 8-6). Because the run-time tables
(specified by setting up the DEFINEs for the production system) are different from the
compile-time tables, the executor performs a similarity check. If the two sets of tables
are similar, the plan is used. If the two set of tables are dissimilar, the plan is
recompiled. The advantage of compile-time name resolution is lost if DEFINEs are set
differently at run time than they were set at compile-time.
Targeting Example for COBOL: Using a Build Subdirectory
To avoid the problem where intermediate files and even the executable can be
overwritten when rebuilding for a new target, use OSS environment variables. In this
COBOL example, the same source file empcnt.ecbl is built twice using an OSS shell
script named empcnt.sh.
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-20
outlines a method to avoid overwriting files.