 |
The Question is:
We are replacing an instrument that connected directly from an instrument to a
vax terminal server with a PC program. This program outputs data through the
com port to the same line. We are having some trouble getting the existing
program to work. We h
ave been experimenting with different terminator values. The way we interpret
the code is the vax fortran program should open the io port and wait until it
receives an STX character to begin transmission. Then capture the data and
end at the DLE. The p
rogram is staying in the status line until I logoff the port. Then we can see
the data string. Here is the following code if you have any
suggestions/insights:
FUNCTION = %LOC(IO$_READVBLK)
TERMINATOR(1)=2
TERMINATOR(2)=16
HIGH_PRIORITY=5
LOW_PRIORITY=4
ERR_FLAG=0
LEN=206
INPUT=' '
I=SYS$SETPRI(,,%VAL(HIGH_PRIORITY),)
STATUS = SYS$QIOW(%VAL(1),%VAL(TERM_CHAN),%VAL(FUNCTION),RSB,,
1 ,%REF(INPUT),%VAL(LEN),,TERMINATOR,,,)
IF(.NOT.STATUS)STOP
The Answer is :
The OpenVMS Wizard would discourage use of serial communications,
and would recommend use of a network connection. Asynchronous
serial communications are far slower and application-implemented
flow control support is problematic at best; network connections
are far faster and far more reliable, and reliable data transports
are readily available.
You will want to discuss the serial communications operations and
associated requirements or the network operations and the network
API present on the remote host with the appropriate Wizard.
If you choose to continue with the rather more difficult serial
communications approach, you will want to dedicate the serial device
to the application, by disabling typeahead on the port. (This is
discussed in the OpenVMS FAQ; please see the SET TERMINAL/NOTYPEAHEAD
/PERMANENT command.) The remote system may or may not have similar
requirements.
By "logoff the port", the OpenVMS Wizard will assume there is an
interactive session running; that there is a process logged into
the port. (The usual trigger for a login sequence and the initiation
of LOGINOUT on the port is unsolicited input; this incoming data is
how OpenVMS activates the initial processing of an interactive
session on an unallocated port.)
Once the port has typeahead disabled during startup -- disabling
the typeahead buffer prevents the incoming data from triggering a
login, whether the incoming data is intentional or due to messages
or data written out to the remote port by the remote application
or remote system software -- the application may/will want to issue
a IO$_SETMODE or IO$_SETCHAR $QIO[W] to re-enable the typeahead
processing temporarily, this should the application not be sufficiently
speedy for the operation. (The alternative to /NOTYPEAHEAD is to always
have the port allocated, and unfortunately there is a window where
unsolicited data can arrive when the application is not started yet
or not running -- the window for unsolicited input with /NOTYPEAHEAD
used is far smaller.)
You will want to verify the return status from the $setpri call
and all system service calls, and use the debugger to evaluate the
progress of the program. You will also want to use a serial line
communications data analyzer, if you wish a reliable view into the
serial communications traffic. You will also want to verify the
IOSB, as that specification and the subsequent verification of the
IOSB contents via $synch or otherwise is effectively a requirement
for reliable communications. (The OpenVMS Wizard always specifies
a unique IOSB and verifies the results regardless of the use of the
$QIO asynchronous call or the $QIOW synchronous call.)
Again, the use of DECnet or (more portable) IP network transport and
a network link is recommended over use of serial-based communications.
For general programming information, please see topic (1661). For
general debugging tips, please see (7552).
|
|
|
|
|
