Availability Guide for Application Design

Designing Applications for Change
Availability Guide for Application Design525637-004
10-24
Changing a NonStop TS/MP Application
Again, the application must perform some reinitialization in order to read in the new
exchange rates.
Application managers often reinitialize this kind of information by stopping and
restarting the application. This approach works fine if you have a period of inactivity in
which to do this. If you need operations 24 hours a day, 7 days a week, however, you
cannot stop your applications.
One solution to handling changes in initialization logic without stopping the application
works as follows. Suppose a server class contains the initialization logic you need to
reexecute. You must send an interprocess message to each member of the server
class. Each server class must contain logic to read this message and react by
reinitializing an input data table, closing a log file and opening a new one, and so on.
Sending this command as a transaction from a client or requester process will not work
because you cannot ensure that every member of the server class will receive the
request. Instead, you would create a separate process to send the interprocess
message to all members of the server class.
Changing a NonStop TS/MP Application
This subsection suggests some techniques that the reader might consider for
upgrading a client/server or requester/server application. Because of the experimental
nature of some of this information, where appropriate, it is presented as some ideas to
think about rather than as concrete examples of how to upgrade an application.
Using Message Versions and Server Upgrade
Upgrading a client/server application involves:
Upgrading the server
Upgrading each client
In a client/server application, the server must be able to work with the old-style and
new-style clients simultaneously, because it takes time to upgrade potentially hundreds
of clients. In a requester/server application where the TCP is the requester process,
upgrading the TCP can be done with a simple PATHMON command, as described
under Upgrading a TCP Requester on page 10-26. For client/server applications,
however, the logistics of upgrading the client are much more complex, because you
must either deliver and install floppy disks on each of potentially hundreds of
workstations or download a new copy of the client to each workstation.
In order to work with both styles of clients, the server might need to recognize different
message formats. Refer to Using Version-Labeled Interfaces for Intermodule
Communication on page 10-19 for guidelines on how to convert your application from
one message format to another.