cmg@WATSUN.CC.COLUMBIA.EDU (Christine M Gianone) (08/29/90)
Info-Kermit Digest Tue, 28 Aug 1990 Volume 12 : Number 3
Today's Topics:
Duplicate Copies of Info-Kermit Digest V12 #1 and #2
Proposed Kermit Extension for SET FILE TYPE
And ANOTHER New Test Release of MS-DOS Kermit 3.02
A New Version of Kermit for OS/2 Presentation Manager
New Release UCPECAN Kermit V1.1
MS-Kermit 3.0x and German telephones
Looking for Stories
Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU,
requests for addition to or deletion from the Info-Kermit subscriber list to
Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET.
Kermit files may be obtained over networks and by mail order. On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files. The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e. Test versions are in kermit/test. Binaries are in
kermit/bin (use ftp in binary mode). You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA. For detailed instructions, read the
file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a
complete list of Kermit versions and an order form from Kermit Distribution,
Columbia University Center for Computing Activities, 612 West 115th Street,
New York, NY 10025 USA.
----------------------------------------------------------------------
Date: Tue Aug 28 17:44:54 1990-EDT
From: Christine M Gianone <cmg@watsun.cc.columbia.edu>
Subject: Duplicate Copies of Info-Kermit Digest V12 #1 and #2
Please disregard any duplicate copies of recent Info-Kermit
Digests.
------------------------------
Date: Thu Aug 16 17:44:54 1990-EDT
From: Christine M Gianone <cmg@watsun.cc.columbia.edu>
Subject: Proposed Kermit Extension for SET FILE TYPE
Keywords: Kermit Protocol, Labeled File Type
Kermit programs presently differentiate between text and binary files via
the SET FILE TYPE command. When the file type is TEXT, the Kermit program
that is sending the file converts the file's record format and character set
from its local form to a standard form, and the receiving Kermit program
converts from the standard form into its own local record format and character
set. When the file type is BINARY, the file is sent as-is, byte for byte.
These two ways of handling files are sufficient in many cases, but fall short
when one or both computers has a complex file system, such as the Macintosh or
DEC operating systems like VAX/VMS. The Kermit protocol includes a mechanism
for transmitting a file's attributes in a generic way, but these attributes
are of little use when the file is being received by a computer with a simple
file system, such as UNIX or MS-DOS, that can't do anything with them. And
they are not sufficient to convey every conceivable bit of information about
about every kind of file on every kind of computer.
To allow a complicated file to be transferred, a new file type is proposed:
SET FILE TYPE LABELED
Notice the spelling of "LABELED" (only one L between the E's). When this
setting is in effect, the sending Kermit sends not only the file's data, but
also system-dependent structural information about the file. Since this
information can be quite lengthy, it is sent as if it were file data, in data
packets preceding the actual file data, rather than in attribute packets. All
of this information is sent in binary mode (no conversions).
The receiver of the file can elect whether to act upon the label information,
or simply store it. Kermit programs for simple file systems need no changes,
and can still act as repositories for labeled files, to be sent back later to
the system of origin. On the other hand, labeled file transfers between like
systems (e.g. two VAX/VMS computers) will result in the reception of a file
with all the correct characteristics.
There are two possible modes of operation. The first (and safer) mode
requires human intervention on a per-file basis, but an automatic mode is also
possible.
DEFINITIONS
A "bare" file is a file stored on disk that does NOT contain, as part of
its contents, Kermit-constructed label information.
A "labeled" file is a file stored on disk whose contents include
Kermit-constructed label information.
FORMAT OF A LABELED FILE
This description applies to a labeled file as stored on disk and to a bare
file that has label information added to it by a sending Kermit.
BANNER The literal text string "KERMIT LABELED FILE:", just the twenty
characters within the quotes including the trailing colon, in 7-bit
ASCII. ASCII is used even on non-ASCII systems (like IBM mainframes
with EBCDIC).
IDLEN A 2-byte ASCII decimal numeric length field, with leading zeros if
necessary, for example "02".
SYSID The system ID, one of the codes listed on pp.275-278 of the Kermit
book. This is a string of 1 to 99 ASCII characters (but typically
1-3 characters), for example "D7" for VAX/VMS. The length of the
SYSID field is given by the preceding field (IDLEN).
LBLEN A 2-byte ASCII numeric length field, with leading zeros if
necessary, for example "00", "02", "09", "99".
LABEL A label field, 1 to 99 ASCII characters. The length is given by
the preceding length field (LBLEN). The LABEL field contains the
name of the file descriptor data that follows.
VALEN An 8-byte ASCII numeric length field, with leading zeros if
necessary, for example "00000512". Zero ("00000000") is a
permissible length for a value.
VALUE The value associated with the label, 0 to 99999999 bytes of
information about the file in system-dependent format. The labels
and the format and layout of the associated values for each system
type should be clearly defined and documented.
The sequence (LBLEN, LABEL, VALEN, VALUE) may be repeated for as many
labeled values are needed (if VALEN is zero, then VALUE is omitted).
CONTENT The file's contents, encoded in whatever form that, in combination
with the labeled values, allows for its eventual reconstruction in
its original form.
All fields in a labeled file are subject to whatever encoding, prefixing, or
compression options have been negotiated by the two Kermit programs.
REQUIRED LABELS
The following labels (composed of ASCII uppercase letters) are reserved, and
are required in every labeled file:
VERS The operating system version, e.g. "5.3-1". If there is no version
to be specified, this label must still be present, but with a
zero-length value.
DATA This is the final label. It always has a zero-length value, which
is followed immediately by the file's contents, as defined above.
EXAMPLE
A hypothetical example for VMS (ignore the indentation and line breaks;
the length fields are marked with L's):
LL LL LLLLLLLL LL LLLLLLLL
KERMIT LABELED FILE:02D704VERS000000055.3-103FAB00000512<512 bytes here>
03ACL00000723<723 bytes here>02DATA00000000<file's contents here>
LL LLLLLLLL LL LLLLLLLL
Note: FAB and ACL are not necessarily real labels.
EFFECTS ON THE KERMIT PROTOCOL
When SET FILE TYPE LABELED is in effect, the sending Kermit should include
the file type (") attribute, specifying a type of binary (B), if attribute
packets have been negotiated. Otherwise, there is no effect on the protocol
at all. In particular, a label-wise Kermit program can interoperate perfectly
well with another Kermit program that is completely ignorant of labeling, in
which case the latter program simply "archives" or "unarchives" the file,
labels and all (provided the user remembered to place it in binary mode).
This proposal does not rule out the system-independent type of file archiving,
based on file attribute packets, that is described in the Kermit book.
However, if the "system-dependent" attributes suggested by this proposal can
be worked out in a sufficiently generic fashion, this may lead to a more
effective type of transmission of complex files between unlike systems that
share similar types of file characteristics (block size, record format,
character set, carriage control, etc).
On the other hand, for the first pass at an implementation (for VMS), it might
make more sense to simply have a single system-dependent label, like "FAB",
whose value is simply the File Access Block, and perhaps another one like
"ACL" for its Access Control List. The two approaches do not rule each other
out.
USER INTERFACE
When SENDING a file, the user should first determine whether it is a bare file
or a labeled file. This can be done by visual inspection (looking at the
first 20 bytes), or from memory (e.g. because all labeled files have a
particular filetype, or are kept together in a certain directory). Then:
(a) If it is a bare file, use SET FILE TYPE LABELED if you want to send
label information too.
(b) If it is a labeled file, use SET FILE TYPE BINARY.
When receiving a file, use SET FILE TYPE LABELED if you want labels in the
incoming file to be interpreted and applied, and:
(a) The other Kermit is sending a bare file from a like system using SET
FILE TYPE LABELED, or:
(b) The other Kermit is sending a labeled file, of the receiving system's
system type, from any kind of system, without SET FILE TYPE LABELED.
The receiving Kermit program that has been given a SET FILE TYPE LABELED
command must inspect the incoming data. The first 30-36 bytes of the first
packet contain the BANNER, IDLEN, SYSID, and the first LBLEN, and LABEL (which
should be "04VERS"). If these five items are in correct format, and the SYSID
matches the program's own, then the program will accept the file in labeled
mode. Otherwise, it will treat it as a binary file and store all the data,
including BANNER, SYSID, LABELs, VALUEs, and all length fields.
If a receiving Kermit program has accepted the file in labeled mode, but then
encounters an unknown label or other inconsistency in the labeled file format,
it must interrupt the file transfer (by putting an X in the data field of the
first available ACK) and discard the file. This is because it cannot be
expected to back up and undo whatever label interpretation it has already done.
It is also conceivable that "similar" systems -- such as the DEC operating
systems VMS and RSX-11 -- might be able to honor each other's labels. This
eventuality should be allowed for, possibly with SET commands.
At the discretion of the programmer, a command such as SET FILE
LABEL-DETECTION { AUTOMATIC, MANUAL } could be installed. If so, the default
must be MANUAL, that is, processing of labeled files occurs only if the user
asks for it explicitly. For an arriving file, AUTOMATIC mode would detect the
BANNER, SYSID, and first LABEL and go into action as if the user had SET FILE
TYPE LABELED. When sending a file, the program would avoid adding surrounding
label information if the user had already SET FILE TYPE LABELED. This sort of
thing is obviously dangerous, and users should be cautioned about it.
POSTPROCESSING
Separate programs should be provided to translate a labeled file into a real
file, to be used in case the user forgot to SET FILE TYPE LABELED, or the file
was deposited by means other than Kermit. Such a program might have two
options (or come in two forms): interpret the labels, and simply strip the
labels.
ACKS
Thanks to Terry Kennedy and Frank da Cruz for suggesting this idea, and to Joe
Doupnik, John Chandler, and Paul Placeway for many valuable suggestions.
Comments welcome!
------------------------------
Date: Mon, 27 Aug 90 10:13:45 EDT
From: Christine M. Gianone <cmg@watsun.cc.columbia.edu>
Subject: And ANOTHER New Test Release of MS-DOS Kermit 3.02
Keywords: MS-DOS Kermit 3.02
From JRD's update notes since V12 #2:
48. Add recognition of IBM PC video boards STB VGA/EM Plus (Tseng 4000)
and Everex Viewpoint EV-678, from Terry Kennedy. The list of boards known
to Kermit for switching between 80 and 132 columns is now:
ATI EGA Wonder
AT&T
Everex Viewpoint EV-659, FVGA-673, EV-678, Micro Enhancer Deluxe
Paradise AutoSwitch EGA Mono
STB VGA/EM (Tseng TVGA)
STB VGA/EM Plus (Tseng 4000), VGA/EM-16, VGA/EM-16 Plus
Tseng Labs EVA board w/132-col kit installed
Tseng Labs UltraPAK mono/Hercules w/132 column modes
Video 7 Vega Deluxe w/ 132X25.COM driver installed and Video 7 VGA
49. Add a facility to the keyboard translator. Let key definition strings
of the form {\Kverb other material} activate an existing Macro if and
only if the verb is not in the list of those predefined for the keyboard
translator. If "verb" matches the name of a regular Kermit Macro execute
the Macro and stay on the Kermit command line; thus a CONNECT command is
needed to return to Connect mode. If verb does not match a Macro then do
nothing and stay in Connect mode. Be aware that searching tables for the
name of the verb uses many cpu cycles and will reduce performance.
Examples:
DEFINE Accumlate Receive, Connect
SET KEY \315 {\Kaccumulate}
Pressing the IBM PC "F1" key (code \315 above) makes the keyboard
translator see string {\Kaccumlate}, verb "accumlate" is not in the
predefined tables, and hence Kermit invokes the Macro named ACCMULATE.
That Macro puts Kermit into file receive mode and when the file, or
file group, transfer has been completed it returns to Connect mode.
DEFINE WP Take wp30.ini, Connect
SET KEY \316 {\Kwp}
This makes IBM PC key "F2" invoke macro WP which in turn reads in
and executes the contents of file WP30.INI. Kermit then returns to
Connect mode. Nothing happens if the user has not defined Macro WP.
Braces around the whole key definition are required so that the search
for the verb name is done while executing Connect mode rather than when
defining the key. If the braces are omitted then only the predefined
keyboard verbs are available; an error will be reported if the verb is
not one of these.
Text sent to the host may preceed and follow the \Kverb part. To avoid
confusion "Kverb" itself, but not the "\", may be placed in braces too,
such as:
DEFINE Accumulate cd c:\junkmail,Receive,Connect
SET KEY \315 {kermit\13\send foo.bar\13\{KAccumulate}exit\13}
the pieces: |_______________________||............||_____|
string to host do Macro string to host
This sends the string "Kermit<carriage return>Send foo.bar<carriage ret>"
to the host to invoke its Kermit and asks it to send file foo.bar. It
then invokes local Macro Accumulate to receive the file, and finally it
sends the string "exit<carriage return>" to the host. Braces around
KAccumlate deliniate it from the final string text.
There is no host command which can invoke these Macros; this protects the
PC against stray garbage text and unauthorized commands from the host.
Files changed are MSUIBM.asm (procedure keysv) and MSYIBM.asm.
50. Reinstate Dump screen: filename on Status display. msssho, msyibm
51. Correct a misprint in the National Replacment Character sets for Spanish.
Apparently a DEC typist inserted one accent mark too many in the table.
char value was is now
60h \96 accent accent just for reference
7bh \123 accent degree
7ch \124 degree n tilde
7dh \125 n tilde c cedilla
7eh \126 c cedilla tilde
Corrections are in file mszibm.asm
52. Embellish the VT300 character set abilities by permitting National
Replacement Character (NRC) sets to be "designated" by the host to a
particular Gn set table, viz:
Designator Mnemonic Description of Action
ESC ( <ident> SCS Designates 94 byte character set <ident> to G0
ESC ) <ident> SCS Designates 94 byte character set <ident> to G1
ESC * <ident> SCS Designates 94 byte character set <ident> to G2
ESC + <ident> SCS Designates 94 byte character set <ident> to G3
where <ident> is:
NRC country <ident> NRC country <ident>
British A Italian Y
Dutch 4 Norwegian/Danish ' (hex 60) or E or 6
Finnish 5 or C Portuguese %6
French R Spanish Z
French Canadian 9 or Q Swedish 7 or H
German K Swiss =
Example: ESC ) A loads the British NRC set (A) into G1 (the ")" part).
To load Latin1 into G1 use ESC - A because Latin1 is a 96 character set.
NRCs are all 94 character sets.
This embellishment does NOT turn on NRC operation in the Digital Equipment
Corporation sense. To follow DEC usage employ SET TERM CHARACTER-SET to
choose the country and have the host enable or disable NRCs by sending
CSI ? 42 h or CSI ? 42 l, respectively.
Changes are in file mszibm.asm.
53. Minor code corrections to parsing eight bit controls introduced by item 52.
File mszibm.
54. Incorporate support for Novell's TELAPI TCP/IP Telnet program. This
is selected by command
SET PORT TELAPI nnn.nnn.nnn.nnn
where nnn.nnn.nnn.nnn is the Internet address of the remote host, in
decimal.
Example: SET PORT TELAPI 129.123.1.11 (machine netlab.usu.edu)
TELAPI is a component of the Novell package LAN WorkPlace for DOS. At
Utah State University it was run with the Novell (ex-Excelan) EXOS 205T
Ethernet board (a smart mutiprotocol board supporting TCP with NetWare
IPX 802.3 style packets). Novell Utility TSU.EXE is not required.
SET PORT TELAPI must not be confused with SET PORT NOVELL(NASI); they
use very different communications methods.
Notes on this new faciity:
a) Hosts not on the local network will likely require their
Internet address and the local gateway to be specified with utility
ROUTE, such as
ROUTE ADD 128.59.39.2 129.123.1.254
The first address is watsun.cc.columbia.edu, in New York City,
and the second is that of a local gateway box (a cisco, Inc router
at Utah State University in Logan, Utah).
b) The communications channel is opened as an 8-bit wide BINARY
character at a time mode, thus Unix hosts may require Line Feed
(Control J) as a line terminator. See also item g) below regarding
character \255.
c) Included in this work is sending a BREAK signal as a Telnet
"Interrupt Process" command.
d) A status message is shown for 3 seconds if the connection cannot
be established.
e) Once an Internet number has been specified with SET PORT TELAPI it
will be retained for subsequent SET PORT TELAPI commands. Thus it
need be stated only once. SHOW COMMUNICATIONS will display the number.
f) The presence of the host can be checked by sending the two bytes
\255\246 which is Telnet signal "Are You There", and to which the
host is supposed to send back a bell or visible message. This can
be arranged easily by command SET KEY <key's ident here> \255\246
if SET TERMINAL CHARACTER-SET TRANSPARENT is selected.
See TCP/IP documents RFC-854 and RFC-855 for Telnet specifications.
g) Character \255 is special in Telnet; it introduces Options negotiation.
To send \255 as data it must be sent twice, as \255\255 or use the
new command SET SEND DOUBLE \255 to do this for Kermit packets.
Please be aware of this character when sending Binary files.
h) TELAPI version 3.5 sometimes has trouble hanging up a connection. It
will attempt creating a new one for each new session and can exhaust
its space (defaults to two of them) when an old one persists. The
only cure I know is to unload the TELAPI TSR (DOS command TELAPI -u)
or reboot the machine.
i) TELAPI version 3.5 is also notably slow in delivering characters to
terminal emulators. Expect an effective 2400 baud rate.
j) TELAPI uses Interrupt 14h with high numbered function calls. Beware
of using other Int 14h trapping programs simultaneously.
k) Kermit uses only the Internet number form of addressing for TELAPI
because the TCP "name resolver" (conversion of a name to a number)
is not available directly with TELAPI. Thus, full compliance with
TCP/IP specs is not available to Kermit or other external terminal
emulators using the TELAPI interface. The full specs recommend using
names and letting a separate group of machines, called Name Servers,
provide the Internet number via TCP/IP methods.
All the changes are confined to file msxibm.asm
55. Correct a real bug: if SET LOCAL ON and while in Connect mode Control-
PrintScreen (copy screen to printer) are active then Kermit crashes the
system. The reason is a stack overflow when the same function ends up
calling itself again by roundabout means. Adequate correction required
small revisions about what is or is not echoed locally. Now almost every
thing except DEC status reports is echoed (my real VT320 seems to do the
same). Affected files are msyibm.asm and mszibm.asm, done on 14 August.
56. Add Enviroment and command line SET COM1 and COM2 to the list as per
item 4 above.
57. Significant change to \%n variables defined as macro arguments. For each
Macro invocation first save variables \%0 through \%9, clear \%0..\%9,
define \%0 to be the name of the macro being invoked and \%1..\%9 as
the arguments to the macro. When the macro exits restore the previous
\%0..\%9 variables. This process nests naturally, and ARGC still
represents the one plus the number of macro arguments. C Kermit 5A and
MS-DOS Kermit 3.02 are now in agreement on these items.
Previously \%0 was not affected by macro invokation and \%1..\%9 were
not saved and restored around the macro. The new behavior may affect
scripts written in the past. File mssset.asm
58. Add alternative command syntax:
SET FILE COLLISION means the same as older SET FILE WARNING
and SET FILE COLLISION DISCARD is the same as SET FILE COLL NO-SUPERSEDE.
Changes are in mssset.asm and msssho.asm
59. Correct problems with REM LOGIN. Is the last of problems in this area?
60. Correct problems with CTS/RTS handshake timing and half duplex. Tnx to
Brian Holley for spotting them. msxibm.asm
61. Add DESQview support call to release the cpu timeslice when in Connect
mode and no character is available from the serial port. msyibm.asm
62. Modify the retry procedure to send a packet character to wait 60ms rather
than 10ms between each of five attempts. This may help situations where
a network device may be unresponsive for about 200ms between characters.
msscom.asm
More changes are expected.
The mstibm.boo file and the source files are in kermit/test on watsun and in
the T: area of KERMSRV. The binary .EXE file is available on watsun only in
kermit/bin/mstibm.exe. There is also a test 3.02 version for the DEC Rainbow,
contributed by Robert Weiner of Cooper Union. It is in kermit/test/mstrb1.boo
and kermit/bin/mstrb1.exe. The latest Rainbow test version tracks the non-IBM
specific portions of MS-DOS Kermit, and adds some new character translations
for screen dump and print screen. Thanks to Joe and Robert for their
continuing work on MS-DOS Kermit!
------------------------------
Date: Mon, 27 Aug 90 14:13:12 EDT
From: Christine M. Gianone <cmg@watsun.cc.columbia.edu>
Subject: A New Version of Kermit for OS/2 Presentation Manager
Keywords: OS/2 Presentation Manager Kermit
Contributed by Brian R. Anderson of Burnaby, BC, Canada. Here is the note
that accompanied Brian's submission:
"The version of Kermit contained herein is for OS/2-PM. It was written from
scratch by the author (Brian R. Anderson) in Stony Brook Professional
Modula-2. A two part article in the September/October 1990 issues of Dr.
Dobb's Journal describe this implementation (which is a port of an earlier
program that I wrote for DOS in Logitech Modula-2).
This program is public domain, and may be copied freely, modified/enhanced,
and distributed freely (in original or enhanced form).
Included on the disk are an executable version of the program
(PCKERMIT.EXE); 17 Modula-2 source code files (8 .DEF and 9 .MOD); icon and
resource files; make and linker response files, and the EXE definition file.
To recompile the program: M2MAKE PCKERMIT <cr>. The program includes:
Kermit single and multiple file transfer
TVI950 Terminal Emulation (optimized for IBM7171/PROFS)
Automatic renaming of files in case of name clash
Continuous display of communications settings"
Brian indicates that this program is the starting point for a program that
will be sold commercially. Further details are in the file O2AAAA.HLP.
The files are in the Kermit test area for now, pending reactions from the
Kermit user community:
watsun.cc.columbia.edu BITNET KERMSRV@CUVMA Comments
kermit/test/o2aaaa.hlp T:O2AAAA.HLP "boo" encoding of program
kermit/bin/o2aker.exe Executable program
kermit/test/o2aker.boo T:O2AKER.BOO "boo" encoding of program
kermit/bin/o2aker.ico Program icon
kermit/test/o2aico.boo T:O2AICO.BOO "boo" encoding of icon
kermit/test/o2asrc.jar T:O2ASRC.JAR Source code
The boo files can be decoded into the original binary files using any of the
msbpct programs available in kermit/a. The "jar" file is a text archive of
the source files that can be picked apart with a text editor or a simple
program. Brian's submission did not include a user manual.
Many thanks to Brian for contributing this program.
------------------------------
Date: Sat, 28 Jul 90 12:10:27 PDT
From: rochester!ames!claris!portal!cup.portal.com!R_Tim_Coslet@columbia.edu
Subject: New Release UCPECAN Kermit V1.1
Keywords: Pecan, USCD Pascal Pecan Kermit
I am submiting a minor upgrade to UCPECAN my Kermit-UCSD (Version 1.1).
You should recieve 2 files: 1) a large (about 1400 lines) one containing
the source (UCPUPD.PAS) and a very short one containing "installation
instructions" and a brief list of changes made to V1.1 by this upgrade
(UCPUPD.UPD). The changes are
1) Added a new Unit (DIR.FIXES) to work around problems
encountered with SFS. This update removes Limitation #4,
making BINARY file transfers exact in both SFS and AFS
implementations.
2) Fixed a bug that caused an incorrect time to be sent in
the attribute packet if no time was specified with the
creation date (this bug affected both AFS and SFS).
R. Tim Coslet
Usenet: R_Tim_Coslet@cup.portal.com
BIX: r.tim_coslet
[Ed. - Many thanks, R. Tim! The new files have been installed in the Kermit
Distribution C area. Keep up the good work!]
------------------------------
Date: Tue, 07 Aug 90 02:00:41 MEZ
From: "Gisbert W.Selke" <UPP101%DBNRHRZ1@cuvmb.cc.columbia.edu>
Subject: MS-Kermit 3.0x and German telephones
Keywords: MS-DOS Kermit 3.0, German
Here's a (partial) solution to a problem no-one besides me seems to have had:
I'm running MS-DOS Kermit over a 1200 bps line in what is yet West Germany.
For some obscure reason, the German PTT transmits the signal to my phone that
can be used to record the fee due. (No, I never had such a gadget. Maybe some
former owner of this flat had.) Unfortunately, the tone used for this is
right within the range used for 1200 bps transmissions. So, if I'm lucky,
I get a corrupted packet every 8 to 12 minutes (for local calls - much more
often for trunk calls); if I'm in terminal mode, however, I get some 10
scrambled characters on the screen. So far, so annoying. But you ain't seen
nothing yet: some of the garbage obviously contained shift-in/-out sequences,
so that I was left with funny graphics characters all over the screen
henceforward, where ordinary 7-bit ASCII should have been. The solution came
with one of the 3.02 revisions of MS-Kermit: 'set term char ascii g1' takes
care of the odd shift!
Still, some of the garbage even throws me out of that; apparently, it loads
a different character set into gx, where x = 1..3. So, if anyone has a way
of doing away with the disturbances altogether, any help/hints/pointers will
be appreciated, with software solutions muchly preferred.
\Gisbert c/o <UPP101.DBNRHRZ1.BITNET>
------------------------------
Date: Mon Aug 27 10:19:29 1990 EDT
From: Christine M Gianone <cmg@watsun.cc.columbia.edu>
Subject: Looking for Stories
... of how Kermit has been used in imaging and visualization applications,
including modelling, CAD, medical imaging, and so forth, for possible
publication. MS-DOS Kermit graphics, Kermit protocol imbedded in imaging or
CAD systems, whatever you know about ...
------------------------------
End of Info-Kermit Digest
*************************