Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!qantel!lll-lcc!lll-crg!seismo!columbia!caip!brl-adm!brl-smoke!smoke!WANCHO@SIMTEL20.ARPA
From: WANCHO@SIMTEL20.ARPA
Newsgroups: net.micro.cpm
Subject: TAC usage
Message-ID: <4170@brl-smoke.ARPA>
Date: Fri, 26-Sep-86 09:48:32 EDT
Article-I.D.: brl-smok.4170
Posted: Fri Sep 26 09:48:32 1986
Date-Received: Tue, 30-Sep-86 19:23:50 EDT
Sender: news@brl-smoke.ARPA
Lines: 28

Both MODEM and the newer TMODEM have code for two methods of
negotiating network binary mode for the TAC user for the duration of
the file transfer on TOPS-20 systems.  One method assumes that the
monitor does not double the IAC character (FFH) and thus allows the
user program to send the appropriate sequences in-band to the TAC.
The other method assumes that the monitor always doubles the IAC
character and provides a particular monitor call to provide the
capability to do that negotiation.

The problem is that some monitors double the IAC character always, but
have no local mod to provide the capability to turn on network binary
mode.  Thus, as Mike says, the user must give the TAC commands:

@B O S
@B I S

in that order.  The side effect of the @B I S is that the user can no
longer give any more TAC commands for the remainder of the session
with that host.  (When the host closes the connection after the user
logs out, the TAC port is set back to normal.)

The situation is further complicated in that neither the MODEM nor
TMODEM program{ have compilation conditionals to allow for this third
case where the monitor does the IAC doubling, but does not provide for
a monitor call.  The solution in those cases is to send this message
to your system wizard and have them contact me to work out a fix.

--Frank