SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (01/21/87)
Info-Kermit Digest Tue, 20 Jan 1986 Volume 6 : Number 2
Today's Topics:
MS-DOS Kermit 2.29b Test Prerelease for IBM PC, Clones, & Generic DOS
Issues for New MS-DOS Kermit Keyboard Translator
Kermit Thru DECserver 100's
MD? Kermits
----------------------------------------------------------------------
Date: 13 JAN 87 01:12-MDT
From: JRD@USU
Subject: MS-DOS Kermit 2.29b Test Prerelease for IBM PC, Clones, & Generic DOS
Keywords: MS-DOS Kermit
This most recent version of MS Kermit 2.29, identified as MS-Kermit
2.29b, has support for VT102 printer commands, long packets, and script
execution. Additionally, it has corrections to most problems known at this
time.
A new kind of MS Kermit, MSTCLO.BOO, is available for near-clones of
IBM PC's but whose serial port hardware is not similar. Here is a description
from the originator, Glenn Everhart of RCA:
This module is derived from MSXIBM.ASM and is intended for IBM PC
near-clones that differ in their serial I/O but emulate the IBM
BIOS. Such machines include Seequa Chameleon, DG/1, and others.
The idea is to use the VT100 emulation (which will work) but
use BIOS for all serial I/O. This is not interrupt driven and so
will (unfortunately) not be able to keep up well at high baud
rates. Nevertheless, it will be far better than the old Seequa
version which didn't emulate anything.
Note that this "semi-clone" version may also work on IBM equipment
in situations where the real IBM version will not, for instance when
communicating through a network communications server (e.g. on the token
ring) rather than a real asynchronous adapter (untested - guinea pigs?).
BUG FIXES AND INTERNAL IMPROVEMENTS:
MS Kermit 2.29 of May '86 (no letter) had two serious bugs. First
was an incompatibility with Hayes and similar internal modems: the modem
would hangup the phone when a file transfer completed or Connect mode
exited. We have tested this version with a real Hayes 1200B modem with
satisfactory results (whew!, but let's keep our fingers crossed).
Second was that extraneous null characters could be sent at the
start of a file transfer or when Connect mode was entered, causing certain
mainframes (e.g. IBM mainframes in linemode) and minis (e.g. HP-1000s) to
ignore packets (or worse), preventing file transfer from taking place. The
nulls are no longer transmitted.
In addition, there were numerous small problems throughout MS
Kermit, as might be expected, and those identified to date have been
addressed. One important one was the serial port was left active if one
PUSHed to DOS while in Connect mode.
Serious DOS errors are now trapped by Kermit to prevent Kermit from
being aborted with the serial port interrupt alive and with a couple of
other items redirected to Kermit itself. The most common such error is
"Drive Not Ready." Previously, these conditions would invoke the normal DOS
Critical Error proc which would request "Abort, Retry, Ignore?" and would
abort the program if Abort were chosen. Now, Kermit exercises a fourth
option, Fail the Operation, when these errors occur. Procedures spawning a
second copy of COMMAND.COM (DIR, etc) still can yield the A/R/I message but
it is harmless in this case. However, if such a message arises while Kermit
is in Server mode a human must still type the answer locally. The
implementation replaces the normal DOS Control-Break (^C) and Critical Error
handlers with Kermit's own handlers and restores the originals when Kermit
exits.
Numerous small bugs concerning negotiated parameters (8 bit quoting,
Block check types, etc) have been fixed; these mainly concerned Server mode
operations. The terminal emulator no longer responds to the answer-back msg
request; there is no answer-back message in the emulator. Screen handling
has been improved internally, but it still has a few glitches.
While in Connect mode 8 bit received data will be passed through to
the terminal processor if the Parity type is None, and the character will be
displayed from the system's 8-bit character set. If Debugging is ON then
characters with their high bit set will be displayed as a tilde and then a
code for the lower 7 bits; i.e., 10000001b is displayed as ~^A. (Note to
mail readers: due to network quirks these characters may be mistranslated;
the tilde is the funny wiggle character above the accent mark and the
control symbol is a caret.)
ADDITION TO SET DISPLAY COMMAND:
Set Display Regular | Serial | Quiet | 7-bit | 8-bit
The keywords 7-bit and 8-bit have been added to control display
of characters in connect mode. 7-bit is the default and 8-bit
becomes meaningless when parity is other than None. The Set Display
command accepts two keywords in one command, processed left to right.
ADDITION TO SET PROMPT COMMAND:
Special characters, such 8-bit Ascii or control characters like
escape, can be included in text of Kermit's prompt by specifying them as
octal numbers in the form \ooo where o is an octal digit. Escape itself is
\33. To return to Kermit's default prompt give the Set Prompt command
without text. The replacement prompt can be up to 80 characters long.
VT102 PRINTER SUPPORT (IBM PC version only, for now):
The MS Kermit VT-102 emulator now accepts ANSI printer control
sequences from the host, including Print Screen, Print Current Line,
Enable/Disable Auto Print, etc.
LONG PACKETS:
MS Kermit can now use packets up to 1000 bytes in length. The
transmitter selects the type of packet (Regular or Long) based upon the size
of the data to be sent in that particular packet; negotiations at the start
of a file transfer determine the maximum length. The receiver is prepared
to accept Long packets at any time up to a maximum length set by the user.
The commands Set Send Packet nnn and Set Receive Packet nnn the
maximum packet size; nnn can be as large as 1000. Kermit uses 94-byte
packets as its default maximum size; longer packets will be employed only if
the user gives the Set Send/Receive Pack commands above.
Long packets may be used in conjunction with any other Kermit
program that supports them. Currently, these include IBM 370 VM/CMS Kermit
3.1, PDP-11 Kermit (for RSX, RT, RSTS, etc), and MS-Kermit itself.
EFFICIENCY:
The IBM serial port interrupt routine, buffer handler for received
chars, and the packet assembly/disassembly routines Spack and Rpack have been
completely rewritten for efficiency, long packets, and high speed operations.
It is possible to operate at 38400 baud on a plain 4.77 MHz IBM PC provided
that the clock tick routine is not loaded with time consuming extras (Helpful
Utilities, print spoolers, screen savers, and the like). Long packet and
high efficiency code are system independent; fancy high speed operation code
is for IBM PC's and clones and the DEC Rainbow.
SCRIPTS:
A simple script and raw file upload facility has been written by Jim
Sturdevant and myself (Jim did the original version and we developed it from
there). The syntax and operation conform to the description of login
scripts in the Kermit book, and in the DEC-20 section of the Kermit User
Guide. This code is actually system independent.
Joe Doupnik
jrd@usu.bitnet
[Ed. - Many thanks, Joe! The three versions that you sent have been put in the
Kermit distribution for testing as MSTIBM.BOO (IBM PC family), MSTCLO.BOO
("semi-clones"), and MSTGEN.BOO (generic MS-DOS version, should run - slowly -
on any DOS machine). Further details about the printer control sequences and
the script facility are in MST29B.DOC. This second post-2.29 pre-release of
MS-Kermit comes without sources because the source is still undergoing
development towards the forthcoming "real" release, and is being issued
primarily to relieve the many Kermit users who have been affected by the
internal-modem and interpacket-null problems. If no serious flaws are
encountered, this release will replace 2.29 on our distribution diskettes;
therefore, IBM-PC Kermit users are strongly encouraged to get this new version
and try it out, and report any problems back to Info-Kermit. It has been
tested on a PC/AT at Columbia against VAX/Unix, DEC-20, and IBM VM/CMS (both
linemode and full-screen) Kermits, and seems to work as advertised.
The next true release of MS Kermit, to be called 2.30, will also include a
completely reworked key definition facility, which will allow key definitions
to work on any system covered by MS-Kermit, not just a select few, and will
allow Kermit "verbs" (like scroll back one screen, send a BREAK, toggle mode
line, etc) to be assigned to arbitrary keys. It will probably also include
some other features, like reporting of performance statistics. Volunteers
for testing the new code on systems that Joe does not have access to are most
welcome; such systems include the Wang PC, Victor 9000, HP-110 and 150, Sanyo
MBC, ACT Apricot, Heath/Zenith 100, Grid Compass, TI PC, etc. Please send
mail to Info-Kermit@CU20B if you'd like to volunteer. The IBM version also
needs rigorous testing under all the many and varied conditions our network
readers can subject it to: with various window and desktop managers, in
conjunction with different terminate-and-stay-resident (TSR) utilities,
with ANSI.SYS and its many replacements, with keyboard utilities like
ProKey, with networks like PC Network and Token Ring, with every conceivable
kind of host at the other end of the connection. This is one of the most
widely used pieces of software in the world and YOU are the quality control!
Internet users may get the new files from host CU20B.COLUMBIA.EDU using FTP,
login ANONYMOUS, any password. The files are KER:MST29B.* (documentation),
KER:MSTIBM.* (IBM version), KER:MSTCLO.* (semi-clone version), and
KER:MSTGEN.* (generic DOS version). The .EXE files are encoded as printable
".BOO" files, which may be decoded using any of the KER:MSBPCT.* programs.
If you're unfamiliar with Kermit network distribution at Columbia, first GET
the file KER:AAAREAD.ME, read it, and take it from there. BITNET users may
request the files from KERMSRV at host CUVMA; to get started you TELL
KERMSRV AT CUVMA HELP (or SEND/REM, or whatever the syntax on your host is).
The files should also show up at the Oklahoma State University (okstate)
UUCP Kermit server within a few days.]
------------------------------
Date: 13 JAN 87 23:00-MDT
From: JRD@USU
Subject: Issues for New MS-DOS Kermit Keyboard Translator
Keywords: MS-DOS Kermit, Keyboard Translation
[Ed. - The following message from Joe Doupnik, the current developer of MS-DOS
Kermit, who is working on the forthcoming release. The major area that has not
been addressed so far is the keyboard translation facility of Kermit.
Presently, this facility is available only in selected implementations: the IBM
PC family & compatibles, the DEC Rainbow, and maybe a couple others. The
reason it hasn't spread further is that it is done in a very system-dependent
way. The system dependence has obvious benefits: speed, and the ability to get
at every conceivable key combination (like Ctrl-Shift-Alt-a), but the lack of
portability is a drawback. The other major problem with the "old way" is that
certain functions, like screen rollback, modeline toggle, and BREAK
transmission, were hardwired to certain keys and could not be moved. The
recently released alternate Rainbow Kermit (MSVRB2) addressed this problem by
enumerating every conceivable Kermit function and allowing them to be assigned
to arbitrary keys by number. Anyone interested in these issues should grab
a copy of MSVRB2.DOC to see how this was done, and how it is presented to the
users. On the assumption that the keyboard translator will change, Joe
presents what he feels to be the relevant issues -- compatibility with old
key definition files, efficiency, portability, adaptability to changing
keyboard and system design, etc -- and solicits opinions.]
First, to answer the obvious question of "What would you like
in a keyboard translator?" Everything, naturally. Naturally, but ...
I see a number of main goals of a translator. Recall, the translator
is active only during Connect mode.
1. Almost any key should be able to emit (send to the other side)
any 8 bit character code (a char in my shorthand) or even a string of
them (a string). The binary null character is the only exception.
[Ed. - Why?]
2. Common Kermit functions such as send a break, show the system
status, toggle the printer on or off, and so forth should be assignable
to almost any key. Included in the function category are cursor movements
when a terminal emulator is used since some emulations require the movement
escape sequence to be different depending on the state of the emulator yet
we still think of left arrow as a left arrow key. Future functions should
be incorporatable with little effort. I refer to these function operations
as named Kermit "verbs", meaning do some complex pre-programmed operation.
3. Several keys could send the same character, string, or activate
the same "verb", without interference. Each key definition is distinct so
undefining one key does not undefine related keys.
4. Keys which are defined ought to be undefinable easily and those
defined ought to be shown upon demand either per key or the whole set.
5. Default definitions should be built-in for some emulators to reduce
the necessity of using a startup file of definitions, yet when such a file
is read into Kermit its contents should take precedence over existing
definitions. Any such file should be plain ascii, without control codes or
other unprintable characters. Similarly, old unused definitions should be
purged automatically if they occupy limited space; strings, in particular,
are space hungry.
6. A controversial point. The name of a key (what is on the keycap)
can be sacrificed in favor of an obscure number if by so doing that particular
Kermit is freed of a particular keyboard. IBM-AT and XT owners take note.
By referring to keys via the system's internal numerical mumbo-jumbo then
the system can tell us if key F12 exists without the translator having any
direct foreknowledge (i.e., code having been written with that key in mind)
of such keys. Clearly, the disadvantge is less spontaneous key defining
and muttered comments about technical persons while pondering keys versus
key-numbers. More on this technical aspect later since it does affect design
of a translator.
7. The manner of defining keys, that is the syntax of a Kermit
command, should be reasonably similar from machine to MS DOS machine so
that a single Kermit manual can explain matters for all. This has the
further hidden benefit of allowing more of the core translator code
to be used on all machines so that one improvement is shared immediately.
More elegant full color menus could be used where appropriate and when
someone implements them for a given machine.
8. Whatever may be done, the translator should not be a memory/cpu
hog, should not consume acres of Status or Set display space, nor should it
be visible to those people who would rather work without a translator.
Similarly, the translator should attempt to co-exist with resident keyboard
utilities such as SuperKey, ProKey, and the like with Kermit reading what
these resident utilities deliver.
9. A keyboard translator is not an editor nor a programming language
nor a cover up for a clumsy host nor anything more than a simple translator.
10. Finally, the syntax of definitions should permit unusual
string constructions with embedded control codes and spaces, full eight bit
character codes, and permit sufficient length to be useful as full remote
host commands. The definition should be printable for documenting on paper
and for editing; straight printable ascii. Such definitions could be entered
from an existing file and (not just or) directly from the keyboard.
That's my preliminary wish list. Item 6 will be of immediate
concern to many readers.
For purposes of illustration, let me describe one translator as a
user would encounter it.
;Defining a key:
; Command is SET KEY <key ident><whitespace><definition>
;
; <key ident> is
; a single ordinary ascii char or
; the numerical equivalent of an ascii char or
; a Scan Code written as a number or
; keyword SCAN followed by a number.
; ? Displays help message.
; Numbers and Binary codes are of the form
; \123 an octal number
; \o456 an octal number base letters o, d, x can be
; \d213 a decimal number upper or lower case
; \x0d a hex number
; \{b###} braces around above material following slash.
; Braces are optional, and the default number base is octal.
; The backslash character \ is required.
;
; <whitespace> is one or more spaces and or tabs.
;
; <definition> is
; missing altogether which "undefines" a key.
; \Kverb for a Kermit action verb; upper or lower case K is ok
; \{Kverb} ditto. Verb is the name of an action verb.
; text a string with allowed embedded whitespace and embedded
; binary chars as above. This kind of string may not
; commence with sequences \K or \{K; use braces below.
; {text} string confined to material within but excluding
; the braces. Note, where the number of opening braces
; exceeds the number of closing braces the end of line
; terminates the string: {ab{}{{c}d ==> ab{}{{c}d
; but {ab}{{c}d ==> ab.
; ? Displays help message and lists all action verbs.
;
; A key may be translated into any single 8 bit code.
;
; Comments can follow a Kermit action verb or a braced string; no
; semicolon is required since all are stripped out by the Take file
; reader before the defining text is seen by SET KEY.
;
; The current Kermit escape character cannot be translated without
; subtrafuge. Many keys can yield the same escape character.
;
; Examples:
; Set Key q z
; makes key q send character z
; Set Key \7 \33[0m
; makes key Control G send the four byte
; string ESC [ 0 m
; Set Key q
; undefines key q so it sends itself (q) again.
; Set Key \4455 \kexit
; defines IBM Alt-X to invoke the leave connect
; mode verb "exit" (Kermit's escape-char ^]c).
; Set Key \x0c Login \{x0d}myname\{x0d}mypass\x0d
; defines Control L to send the string
; Login <cr>myname<cr>mypass<cr>
;
;Showing a key:
; Command is SHOW KEY <cr>
; System prompts user to press a key and shows the definition plus the
; free space for strings and other definitions. Responding to the Press
; a Key prompt with a question mark produces a list of all defined keys.
Some example "verbs" are exit, send-a-break, status, toggle-mode-line,
toggle-printer, the four arrow keys, definitions for Function keys emulating a
VT102 terminal (for IBM and several other machines), and so forth totaling over
40 "verbs." 256 verbs are permitted if the space is set aside accordingly.
Strings are limited to a full Kermit command line of 128 characters, and a
nominal 1 K byte buffer is allocated to hold all multi-character strings; it
could be much larger. Single replacement characters come out of a pool of
definition packets set at say 100-200 possible definitions, or more if needed.
A European or Dovark keyboard typically would use single character replacements
and cost 4 bytes of table space per definition.
Additional technical comments on the example.
This example translator uses the number business to identify a
key. Such numbers are displayed by the Show Key command. The benefit to the
systems designer is the same code with only minor changes ports well to
an IBM PC or a Generic terminal driven device or just about any other
machine. It was also designed to be "unplugged" by using a replacement
code file if the space consumed were too much for a system; unplugging
means an assembly language file need only be substitued whole for another
without any editing.
Also, the numerical key identification scheme relies on the local
operating system to provide a key's magic number for tomorrow's fancy
125 key keyboard with attached mouse and telephone dialer without Kermit being
pre-designed for that device. A suprising new keycode is just another
number to the translator. In fact, the main body of the translator knows
precisely zero about keyboards! It sees a keycode number and follows
instructions in the translation tables. A short system dependent procedure
is charged with the easy task of obtaining a key response and delivering it
in standardized form to the main translator. Much easier on the programmer!
This example translator is "non-modal" in the sense that one key
always means the same thing. Modes could be introduced, such as when
examining the Status display a certain key could bring up details of the
serial port or packet parameters but do something else while Kermit is
acting as a terminal. The cost of modes is in space for code and extra tables
and a more complex key definition scheme (not to mention major headaches
concerning compatibility among different machines).
An actual implementation of this example uses about 6-7 Kbytes for
code plus tables. It works much faster than my speeded up IBM AT keyboard.
So, it's not perfect is it? What we will get is a combination of
your best ideas blended with the necessities of writing one for multiple
machines. It's a fine time to do a super job.
Regards,
Joe D.
------------------------------
Date: 13 Jan 87 07:55:00 EST
From: "INFOCEN - Greg Elder" <elder@wpafb-info2.ARPA>
Subject: Kermit Thru DECserver 100's
Keywords: DECserver
I've used KERMIT through DECserver 100's to communicate with and transfer to
VAX/VMS systems. I've run at 9600 baud with no problems. The only thing I
needed to do was set some of the parameters on the DECserver as described on
page 20 of the DECserver 100 Terminal Server User's Pocket Guide. This page
describes how to set up the DECserver for file transfers. Basically you
give the server these commands:
Local> SET BAC NONE FOR NONE LOS NONE
Local> SET BRO DIS FLO DIS LOS DIS
These commands turn-off the ability to have special switch characters
(backward, forward, and local switches) on the server and it disables flow
control, broadcast, and loss notification on the server. Hope this
information is helpful.
Greg Elder
elder@wpafb-info2
------------------------------
Date: Wed, 14 Jan 1987 02:19 PST
From: JAJZ801%CALSTATE.BITNET@WISCVM.WISC.EDU
Subject: MD? Kermits
Keywords: ISIS/MDS Kermit
Which of the two ISIS/MDS kermits should be considered the latest and
greatest ? The help files for each make it a little ambiguous with entries
about the same date (within a couple of months) and a comment that one was
received based upon the other which was upgraded soon after .... sigh. Is
there a real difference or what? (weak docs)
------------------------------
End of Info-Kermit Digest
*************************
-------