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

to the server class’s OWNER and SECURITY attributes. You set these attributes for server classes
at configuration time if those server classes are to be accessed by Pathsend processes.
The NonStop TS/MP System Management Manual describes how to set the SERVER OWNER and
SERVER SECURITY parameters in PATHCOM.
RSC/MP Client Security
RSC/MP workstation clients can be allowed or disallowed to communicate with specified Pathway
servers. You can set up security validation by creating an access control server (ACS). For more
information about creating an ACS, refer to the Remote Server Call (RSC) Programming Manual.
Avoiding Coded PATHMON Names
SCREEN COBOL requesters can send requests to Pathway server classes without having to specify
the name of the PATHMON process controlling the server class, because the TCP has a default
PATHMON process to send to. Pathsend processes, however, must specify the PATHMON name
of the server class to send to, because the Pathsend procedures provide no default PATHMON
name.
It is possible, however, to avoid coding PATHMON names in Pathsend programs. For example,
you can use ASSIGNs containing the PATHMON system and process name. Or, if the Pathsend
process is a Pathway server, the process can use the name of its creator as the default PATHMON
name to send to. This method of avoiding coding the PATHMON name is reliable as long as the
sending server is not associative, in which case its creator might not be a PATHMON process.
The Pathsend program examples BREQ and PATHSRV in “Examples” (page 129) use ASSIGNs to
avoid coding PATHMON names. The PATHSRV example also uses the creator default method just
described to avoid coding the PATHMON names.
Context-Sensitive Pathsend Programming
If you are writing a context-sensitive Pathsend program, you must follow the guidelines in the
previous subsection, “Basic Pathsend Programming” (page 52), and also perform additional
programming tasks. This subsection describes these additional tasks and other considerations for
context-sensitive programming.
Context-sensitive Pathsend programming involves establishing a dialog between a requester and
a server process in a server class, and then sending messages within the dialog. After the dialog
is established, the same server process is used for all the messages in the dialog; therefore, the
server can retain context between send operations.
A requester starts a dialog by calling SERVERCLASS_DIALOG_BEGIN_. This procedure returns a
dialog identifier to be used on subsequent server-class send operations, which are made by calling
SERVERCLASS_DIALOG_SEND_. The requester can use multiple calls to
SERVERCLASS_DIALOG_BEGIN_, and the resulting dialog identifiers, to engage in multiple
simultaneous dialogs. To send and receive messages larger than 32KB, use
SERVERCLASS_DIALOG_BEGINL_ and SERVERCLASS_DIALOG_SENDL_ procedures. You can use
a combination of these procedure calls depending on the size of the message to be used in the
Pathsend dialog. As in the context-free case, the requester can call SERVERCLASS_SEND_INFO_
after a server-class send operation to get detailed information about send initiation and completion
errors.
Either the requester or the server can abort the dialog, but only the server can end it. (The server
aborts the dialog by returning file-system error 1 (FEEOF) in its reply; it ends the dialog by returning
file-system error 0 (FEOK).) To abort the dialog, the requester calls SERVERCLASS_DIALOG_ABORT_.
The requester calls SERVERCLASS_DIALOG_END_ to clean up resources after the server has ended
or aborted the dialog.
As in context-free programming, the requester can perform context-sensitive serverclass send
operations either waited or nowait. The requester receives an error indication if the server process
has terminated or if it has ended or aborted the dialog.
58 Writing Pathsend Requesters