|
You will need access to the Digital TCP/IP Services programming
documentation, as well as the OpenVMS Programming Concepts manual.
:I've been recently working on some TCP/IP links
:between some of our Alpha systems and some PC's
:to exchange some data. I work at a sys$qio level
:since I can't find the ucx$ipc.olb anywhere!!!
:(shouldn't it be in sys$library???)
The socket library is implemented via a DEC C shareable image,
and a UCX shareable image. For information on shareable images,
see http://www.partner.digital.com/www-swdev/pages/Home/TECH -
/faqs/ovms/ovms-shexe-cook.html.
In this specific case, direct calls to the OpenVMS I/O subsystem
(calls at the level of sys$qio or sys$qio[w]) do not generally use
nor need any UCX components other than the BGDRIVER device driver.
See the UCX documentation for details on programming via the QIO
interface to the BG: device, as well as the OpenVMS Programming
Concepts Manual, as well as the OpenVMS I/O Users Reference
Manual -- this lattermost document shows the sys$qio-level interface
to a number of different device drivers present in OpenVMS (the UCX
drivers are not included in this manual), and is included here
only to provide you with some general background information on
the sys$qio programming interface.
:Anywayz, at QIO-level I send and recieve data without
:any kind of problems. The only problem is that
:each time I read from the net with a IO$READVBLK
:or similar, my application get's stuck there until data
:is sent to me. This is a serious problem since it may
:happen that I have data to send but until something
:is sent to me I dont get that data over!!!
If using the sys$qiow call or a sys$qio call followed by sys$synch,
this is expected behaviour.
:The question is: Is there a way I can read from the
:net with some kind if timeout value??? I've already
:done some routines to do this kind of stuff with
:mailboxes, and all works ok. But I can't do a
:IO$READVLK + IO$M_NOW when reading the NET,
:coz I get as a result ILLEGAL FUNCTION!!!
Use the sys$qio, with the specification of an AST on completion.
Be careful around the allocation of the IOSB -- it must be in memory
that is valid and is not shared with any other (parallel) calls over
the life of the asynchronous sys$qio call, and use lib$get_ef to pick
a unique event flag. (The AST can complete the processing once the
packet is in the buffer, or can set a flag or send a message to other
non-AST code via interlocked queue, interlocked bitflag, event flag,
etc.)
Be aware that function modifiers such as "IO$M_NOW" are device-specific,
and the individual bits do not necessarily have the same meanings across
all device drivers.
Also be aware that a non-zero event flag *and* an IOSB should be
explicity specified on all system services that permit either (or
both) arguments. Do not allow these arguments to default.
Always check the return status from the system service, and
always check the status of the asychronous portion of the call
in the IOSB
:Who are you? and what do you do????
I am a wizard. I work magic.
|