TS/MP Pathsend and Server Programming Manual (H06.05+, J06.03+)

For Pathsend calls not protected by the TMF subsystem, the proper recovery depends on the nature
of the request:
• Retryable requests that are not protected by the TMF subsystem can be repeated many times
without adverse effect. An example of this kind of request is a request to read a bank account
balance. Requests to retrieve data from a database are retryable requests.
For these requests, on backup takeover, the backup can simply reissue the request. The request
could be processed more than once by different server processes without resulting in data
corruption.
• Nonretryable requests that are not protected by the TMF subsystem cannot be processed more
than once without having adverse effects. An example of this kind of request is a request to
subtract $50.00 from a bank account balance.
For these requests, there is no way for the server class to detect duplicate requests; Pathsend
does not support checkpointing of Guardian sync IDs. Therefore, the backup process cannot
send the request again because the operation might be processed more than once. Because
the request cannot be safely retried, the Pathsend process cannot ensure that the request gets
processed at least once.
Because the request thread suspends while a checkpoint is in progress, checkpointing large buffers
can affect the performance of your application. You should checkpoint the entire context of
nonretryable requests, but avoid checkpointing unnecessary data: for example, data from retryable
requests or data that has not changed since the last checkpoint.
The LINKMON process or the ACS subsystem processes opens servers that are configured with
the TMF parameter OFF with a sync depth of 1, and I/O operations to the server process are
automatically retried if the primary process of a server process pair fails.
See the Guardian Programmer’s Guide for detailed information about checkpointing and sync IDs.
Security Issues
There are two levels of security to consider for Pathsend processes: security at the network level
and security at the server-class level. In addition, if you are using the RSC/MP) product, you can
provide additional security to control access to servers.
Network Security
If your Pathsend process is to access a Pathway server class on another system, the user ID of the
PATHMON process controlling the server class has to have corresponding user IDs and remote
passwords with these systems:
• The system where the requesting process is running
• The system where the PATHMON process is running
• The system where the server class is running
This level of security is required because the LINKMON process or the ACS subsystem processes
must be able to open the PATHMON process (to make link requests); the LINKMON process or
the ACS subsystem processes must be able to open the server processes (to send user requests);
and the PATHMON process must be able to open the server processes (to send startup messages).
All of these opens are performed with the PATHMON user ID.
NOTE: The user ID of the Pathsend process need not have remote passwords to the PATHMON
system or to the server-class system to access the server class. Moreover, the Pathsend-process user
ID need not be known on the PATHMON or server-class systems.
Server-Class Security
LINKMON processes or ACS subsystem processes perform authorization checks on each server-class
send operation to make sure that the user ID of the Pathsend process at the time of the send conforms
Basic Pathsend Programming 57