|
HP OpenVMS Systemsask the wizard |
|
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).
|