|
HP OpenVMS Systemsask the wizard |
|
The Question is:
February 24, 2000
Hi!
We are writing a client/server product using the DIGITAL TCP/IP Services
via System Services routines ($QIO). Our server part consists of multiple
simultaneously running processes. These server processes communicate with
each other through OpenVMS m
ailboxes. Here is our problem. One of those processes must do two things
at the same time: it must poll several mailboxes for available data and it
must poll a socket channel, which has been through bind and listen $QIO
calls but not the accept call so
it does not block, for a pending client connection.
Here is the question.
Is there a way for that process to determine if the socket has a pending
client connection without going into the accept routine and therefore not
blocking the whole process. The use of threads and C Socket RTL is not
acceptable here for some other d
esign reasons. Maybe there is a system call that can be used to determine
the status of a listener socket or maybe even going into and looking at the
process or system global data structures.
The system that we support is Alpha OpenVMS 6.2.
We would really appreciate any ideas and suggestions on this. Thank you!
--Alexander Volnov, Information Builders, Inc.
The Answer is :
The OpenVMS Wizard generally recommends using asynchronous system traps
(ASTs), and triggering a routine to run when the operation completes.
Please see chapter 5 in the OpenVMS Programming Concepts manual:
http://www.openvms.digital.com:8000/72final/5841/5841pro_013.html#ast_sec
for details on ASTs -- mailboxes, TCP/IP sockets, and many other OpenVMS
interfaces have support for AST-based operations.
For information on setting up listener processes, please see:
http://www.openvms.digital.com:8000/72final/
6529/6529profile_002.html#listen_soc_sec
On more recent OpenVMS versions (V7.2 and later), consider using the ICC
support for on-node and intra-cluster communications.
The OpenVMS Wizard would also use the distributed lock manager for
process-level control and coordination, as this provides you with the
ability to operate within a cluster, and to transparently detect, handle
and recover from many common node and application failure scenarios.
For details on common asynchronous-programming pitfalls, please see
topic 1661.
|