TS/MP 2.5 Pathsend and Server Programming Manual

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 2.5 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, see the Remote Server Call (RSC) Programming Manual.
Avoiding Coded PATHMON Names
SCREEN COBOL requestors 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 135) 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 51), 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 requestor 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 requestor 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 requestor can use multiple calls to
SERVERCLASS_DIALOG_BEGIN_, and the resulting dialog identifiers, to engage in multiple
simultaneous dialogs. As in the context-free case, the requestor can call SERVERCLASS_SEND_INFO_
after a server-class send operation to get detailed information about send initiation and completion
errors.
Either the requestor 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 requestor calls SERVERCLASS_DIALOG_ABORT_.
The requestor calls SERVERCLASS_DIALOG_END_ to clean up resources after the server has ended
or aborted the dialog.
As in context-free programming, the requestor can perform context-sensitive serverclass send
operations either waited or nowait. The requestor receives an error indication if the server process
has terminated or if it has ended or aborted the dialog.
Context-Sensitive Pathsend Programming 57