SYSTEM@SLACTWGM.BITNET (12/16/85)
I recently started to use SET HOST/DTE, and ran into a number of
serious problems with some foreign terminals (notably Concept 100
and Ann Arbor 4080). After spending some time with the microfiche,
I found fixes for all these problems. From my limited perspective,
I don't see why DEC did things the way they did them in the first
place, so perhaps there is some hope for a permanent fix in the
future. I have submitted an SPR (attached below) on this matter, in
hopes that I won't be faced with repatching with every new release.
If any of you have seen similar problems, I hope you will also
bring them to DEC's attention. If anyone would like to receive a copy
of my patches (to RTPAD.EXE) which corrected my problems, my address
is
SYSTEM@SLACTWGM (on BITNET).
Ed Miller
Stanford Linear Accelerator Center
SPR re SET HOST/DTE
Date: 7 December, 1985
System: VMS 4.2
PROBLEM STATEMENT:
-----------------
Four problems are observed with SET HOST/DTE:
1) The 'null' character is not passed from the application
program to the command terminal.
2) The procedure aborts if the application program generates a
'bad' escape sequence.
3) The whole connection can 'hang', apparently because the
application program sends the XOFF character (as part of an
escape sequence).
4) Some terminals send escape sequences which contain the ASCII
character for ^\, thus unwittingly aborting the connection.
SPECIFICS:
---------
1) Suppression of nulls:
We have terminals that rely on the 'null' character for the proper
functioning of some of their cursor control functions. We observe
that these do not function properly when using SET HOST/DTE. If we
patch RTPAD to eliminate the suppression of nulls (in routine
READ_PORT_AST), the problem is corrected.
2) 'Bad' escape sequences:
We have applications which generate 'bad' escape sequences (SS$_BADESCAPE);
these cannot be run thru SET HOST/DTE, because it explicitly aborts when
a 'bad' escape sequence is detected. When RTPAD is patched
(in routine READ_PORT_AST) to ignore this error, the applications
run correctly.
3) Total 'hang' when application sends XOFF:
We have applications which send escape sequences which include the
XOFF character. Because SET HOST/DTE forces the port to have the
attribute TTSYNC, this character stops all transmission from
the RTPAD image to the port, leaving the RTPAD image effectively
'hung'. Even ^\ does not terminate the session. If RTPAD is
patched so that the port is set '/NOTTSYNC', the problem is avoided.
4) SET HOST/DTE aborts when terminal sends ^\:
We have terminals which send escape sequences which include
the ^\ character, causing the SET HOST session to be aborted
unintentionally.
REQUESTS/RECOMMENDATIONS:
------------------------
1) Suppression of nulls:
There would seem to be no significant reason to suppress the
transmission of nulls sent from application program to command terminal.
We request that you modify the RTDTE routines so that nulls will be
transmitted.
2) 'Bad' escape sequences:
It is not obvious why 'bad' escape sequences should be treated
as a fatal error. Indeed, it is not clear to us why they should
be treated as an error at all in this context. We hope you will
make a change in this direction.
3) Terminal characteristics:
The RTPAD program as currently written forces unconditionally
the HOSTSYNC and TTSYNC characteristics on both the command
terminal and the intermediate port. It is clear from our experience
that specifying TTSYNC on the intermediate port can be disastrous
in some circumstances. It is not at all clear to us what the
positive value of this choice might be in this context. It is also
not clear that DEC can select the proper attributes for these
two ports in a way which is universally acceptable to all users
of this facility. Hence what we would like to see is to give
the user control over these characteristics. One way to implement
this might be to add a qualifier to the SET HOST/DTE command, such as:
/[NO]CHARACTERISTICS
The default (/CHARACTERISTICS) would perform as presently, with SET HOST/DTE
making the decision for you. (You may want to review whether TTSYNC is the
best choice for the intermediate port.) However if /NOCHARACTERISTICS
were specified, the user would be responsible for setting appropriate
characteristics (using $ SET TERMINAL) for both his command terminal
and the intermediate port before executing the SET HOST/DTE/NOCHAR
command. (Since this command can be part of a command procedure,
it would be easy for the user to set up an appropriate command file
or files to serve his needs.)
4) SET HOST/DTE aborts on ^\.
The behaviour of SET HOST/DTE in this regard could be improved
in a number of different ways. One which comes to mind is to require
two successive ^\'s before terminating the session. Or perhaps
the SET HOST/DTE behaviour could be made the same as for SET HOST,
that is, that two successive ^Y's give you the option of aborting
the session.
-----(end of SPR)-------------------------------------