  Asynchronous Serial Communications? 
 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).
 
 Answer written or last revised on  31-MAY-2003 
