Availability Guide for Application Design

Designing Applications for Change
Availability Guide for Application Design—525637-004
10-27
Changing a NonStop SQL/MP Program or Database
3. A new version of PROGC is compiled and added to the program file.
Because PROGC loops indefinitely, it never returns to PROGB and, therefore, is never
called after its first invocation. The old version of PROGC therefore continues to
execute.
To ensure that all programs are upgraded within an appropriate period of time, your
application should periodically return to the highest level. In this example, the
application should periodically return to PROGA.
The limitation on upgrading your TCP application in this way is that you cannot
upgrade your highest-level program, because it never gets called after it is first
invoked.
Changing a NonStop SQL/MP Program or
Database
Using the HP NonStop SQL/MP product, you can design and develop applications that
tolerate change better than with any SQL product from any other vendor. You can
upgrade your application or restructure your database, in many cases, without bringing
the application down. If the application must be brought down, tools are available to
keep the downtime to a minimum.
Traditionally, an SQL database can become unavailable for extended periods while
performing physical reconfiguration tasks such as:
•
Adding an index
•
Splitting a partition
•
Moving a partition
•
Adding or reloading data from a single source into multiple partitions
Using other vendors’ equipment, these kinds of changes can make a large database
unavailable for several days. With only minor programming considerations, such
actions on an NonStop system typically require your database to be unavailable to the
application for one minute or less.
Change management can cause downtime of an SQL application when:
PROGA PROGB PROGC PROGE
PROGD
PROGF
VST900.vdd