Availability Guide for Application Design

Designing Applications for Change
Availability Guide for Application Design—525637-004
10-23
Explicit Upgrade Action: Handling Changes in
Initialization Information
Procedures defined with the extensible attribute allow parameters to be added later.
This feature is particularly useful for parameters that you do not yet know about. You
simply declare the procedure as extensible so that you can add as many parameters to
it as you like at a later time. Again, when you do add parameters to the procedure or
function, existing callers do not need to change. Only procedures that need to access
the new capability need include the additional parameters in the call.
In C, functions can be declared as variable or extensible by including the _variable or
_extensible attribute in the function declaration. In TAL, you include the VARIABLE or
EXTENSIBLE attribute in the procedure declaration.
There is no equivalent of variable or extensible procedures in COBOL85. To use these
features from COBOL85 you must enter TAL or C.
Refer to the C/C++ Programmer’s Guide and the TAL Programmer’s Guide for
information on how to declare and call variable and extensible procedures from C or
TAL.
Avoiding Dependencies on a Specific Entity
To make upgrade easier, you should avoid code dependencies on a specific processor
or process. Software tied to a specific processor is a problem not only because it
makes processor replacement impossible without bringing the application down, but
also because it prevents several possible online software replacement techniques:
•
Online process pair replacement depends on the existence of a backup process
that runs in another processor.
•
Online replacement of operating system code depends on the ability of other
processes in other processors to take over the workload, or on the ability to
migrate a process to another processor.
Software dependency on a specific process name makes it difficult for an application to
implement replacement by itself, but it would still be possible for a system-level utility to
manipulate the process-name table.
Explicit Upgrade Action: Handling Changes in Initialization
Information
Many applications contain initialization information that needs to be periodically
updated. For example, your application might open a log file as part of its initialization
logic. Typically, it is not appropriate to use the same log file throughout the life of an
application. At some time, you would need to close the current log file and start logging
information to a new file.
Another example might involve an application that reads some information from a
remote table of exchange rate information as part of its initialization logic and uses its
local copy of that information to perform financial transactions. Perhaps once a day, the
database will be updated by some other application to reflect current exchange rates.