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

Table Of Contents
9 Managing Database Applications
Managing an SQL/MX database includes supporting the operating requirements and access
requirements of application programs and maintaining valid application programs. Providing this
support and maintenance can include both performance-related and operation tasks.
This section addresses these application management tasks:
“Writing SQL/MX Applications to Recover From Temporary Network or Hardware Service
Interruptions” (page 209)
“Moving Programs From Development to Production” (page 211)
“Distributing Programs Across Nodes” (page 215)
“Ensuring Proper Name Resolution” (page 217)
Assigning Permissions for Running Database Applications” (page 218)
“Maintaining Query Execution Plan Validity” (page 219)
“Managing Modules” (page 220)
“Backing Up and Restoring Programs” (page 230)
For more information about migrating SQL applications across SQL/MX Releases, see the SQL/MX
Installation and Upgrade Guide.
NOTE: If you use NonStop SQL/MX, you cannot mix SQL/MP statements and SQL/MX statements
in the same application. However, you can use SQL/MX statements in the same application to
query both SQL/MP and SQL/MX database objects. For more instructions, see the SQL/MX
Programming Manual for C and COBOL.
Writing SQL/MX Applications to Recover From Temporary Network or
Hardware Service Interruptions
This subsection describes how SQL/MX applications can be written to recover from temporary
network or hardware service interruptions.
The SQL/MX file system automatically retries certain hardware and network errors, such as those
that generate the Guardian errors 200, 201, and 211. Some errors are retried continuously,
whereas others are retried up to three times, as indicated by the Nonstop Kernel message system.
In general, an SQL/MX application does not receive a Guardian error such as 200, 201, or 211
from NonStop SQL/MX when these conditions are transient and are resolved by the takeover of
the backup CPU or the prompt restoration of the network connection.
Any active transaction that does transaction work on a data volume incurs a unilateral abort when
the CPU for the primary DP2 process fails. This is fundamental to high performance with audited
tables and is true for Enscribe, NonStop SQL/MP, and NonStop SQL/MX. The transaction abort
is initiated by the backup DP2 process during an unplanned takeover.
TMF might also initiate an abort for some transactions. Typical TMF-based applications are designed
to redrive failed transactions.
When a transaction is aborted, an indication is placed in the SQL/MX diagnostics area with a
SQLCODE of 8839. This SQLCODE might not be the first returned code. To detect SQLCODE
8839, the application can examine the entries in the diagnostics area using the GET DIAGNOSTICS
SQL statement. For more information, see the SQLMX Programming Manual for C and COBOL.
The application can be designed to redrive a transaction that was aborted. To avoid a loop, the
redrive should not be attempted more than once. Note that when the TMF transaction has been
aborted by the system (SQLCODE 8839), the application can end the transaction with either
Writing SQL/MX Applications to Recover From Temporary Network or Hardware Service Interruptions 209