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

Name Resolution
The SQL statements in the program must refer to database object names that exist on the production
system or that enable compile-time name resolution. When you move a program without compiled
modules to the production system and SQL compile there, follow these guidelines when referring
to tables or views in embedded SQL statements:
• If you expect the database object names to differ on development and production systems,
use class MAP DEFINEs (for SQL/MP objects only) or PROTOTYPE host variables (for embedded
SQL programs in C, C++, and COBOL only) in the SQL statements of the program.
• For hard-coded Guardian names of SQL/MP objects, make sure volume, subvolume, and file
names on the development system are the same as those on the production system. Omit the
node from the object names in the program. The object names will be qualified with the node
of the system on which the statements are compiled.
• If the volume and subvolume names on the development system differ from those on the
production system, omit the volume and subvolume from the SQL/MP object names in the
program. The object names are qualified with the default volume and subvolume of the system
on which the statements are compiled.
NOTE: This technique works only for database objects that exist in the same volume and
subvolume. If the program refers to database objects in different volumes and subvolumes,
you must hard code those volumes and subvolumes in the program.
◦ For embedded SQL programs in C, C++, or COBOL, you can override the default volume
and subvolume of unqualified objects by setting the volume and subvolume on the
command line during SQL compilation of the module definition:
mxCompileUserModule -d MP_VOLUME=\$vol MP_SUBVOLUME=subvol myprog.exe
mxcmp -d MP_VOLUME=\$vol MP_SUBVOLUME=subvol sqlprog.m
• For hard-coded logical names of SQL/MX objects, make sure that catalog, schema, and object
names on the development system are the same as those on the production system.
• If catalog and schema names on the development system differ from those on the production
system, omit the catalog and schema from SQL/MX object names in the program. The object
names are qualified with the default catalog and schema of the system on which the statements
are compiled.
NOTE: This technique works only for database objects that belong to the same catalog and
schema. If the program refers to database objects in different catalogs and schemas, you must
hard code those catalogs and schemas in the program.
◦ For embedded SQL programs in C, C++, or COBOL, you can override the default catalog
and schema of unqualified objects by setting the catalog and schema on the command
line during SQL compilation of the module definition:
mxCompileUserModule -d CATALOG=cat -d SCHEMA=sch myprog.exe
mxcmp -d CATALOG=cat -d SCHEMA=sch sqlprog.m
For more information, see the SQL/MX Programming Manual for C and COBOL.
Moving a Program to Production and Re-compiling its SQL Statements
These instructions explain how to move a program with its existing module definitions (either
embedded module definitions or module definition files) from a development system to a production
system. The program and any associated module definition files must be moved to the production
system, then the module definitions must be SQL compiled to produce new plans for their statements.
216 Managing Database Applications