SQL/MX 3.2 Management Manual (H06.25+, J06.14+)

The Similarity Check determines if the query execution plan of a statement is still valid. During the
Similarity Check process, the redefinition timestamps and Guardian names of runtime objects are
obtained and used during statement processing. This information is not saved for subsequent
executions or for multiple concurrent executions of the same program. Whenever a new process
starts, the Similarity Check is triggered when the statement is executed.
Starting with SQL/MX Release 3.2, you can use the mxrpm (module reprocess) tool to reprocess
the module files. The tool processes the module files and persists the results of Similarity Check and
Late Name resolution in the module files.
The tool reads the module files and invokes a Similarity Check on each of the SQL statements in
the module to determine whether the query execution plan is still valid. If the Similarity Check
passes, the redefinition timestamps for the SQL objects referred to in the statement are changed
to the redefinition timestamp available in the runtime object label. The Guardian name for the
primary partition is also updated. The tool also processes statements that use hard-coded object
names. For those statements, only the redefinition timestamps and Guardian names of the objects
are updated. When the program uses the new reprocessed module file, the Similarity Checks are
avoided, because the names and the redefinition timestamps match.
You can invoke the tool for a list of SQL modules or a single module file. The list of modules is
provided using an input file or on the command line. A map file containing the mapping of objects
between the development and the production system (or compile and runtime objects) is an
additional input to the tool. For more information, see the SQL/MX Reference Manual.
NOTE: The mxrpm tool supports only SQL/MX tables or views.
Distributing Programs Across Nodes
This subsection provides guidelines for running programs in a distributed database network.
For comprehensive information about managing a distributed database environment, see “Managing
an SQL/MX Distributed Database” (page 263).
For more information about how to code programs to query distributed database objects, see the
SQL/MX Programming Manual for C and COBOL.
Moving Applications to a Remote Node
To move an application to a remote node (where the metadata for the application’s objects does
not reside), move the application files and recompile the module definitions on the remote node.
Do not attempt to copy the module file for that application to the remote node. Note that this
approach risks generating a query plan on the remote node that differs from the query plan on
the original node.
For detailed instructions about how to move application files and modules to a remote node, see
“Moving Programs From Development to Production” (page 211).
Running Applications on a Remote Node
In a distributed database environment:
• You can always run a local Guardian or OSS application from the local node by running the
local program file.
• You can run a local Guardian or OSS application on a remote node by copying the application
to the remote node and running the remote program file there.
• To run a remote Guardian or OSS application from the local node, you must copy the
application from the remote node to the local node and then recompile the module definitions
for that application from the local node.
Distributing Programs Across Nodes 215