SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (09/15/86)
Info-Kermit Digest Mon, 15 Sep 1986 Volume 5 : Number 8
Today's Topics:
Prerelease Version of MS-DOS Kermit 2.29A Available for Testing
New Release of Kermit for Concurrent (nee Perkin-Elmer) 3200
New Kermit for Burroughs 7800 and A Series
Glut of Kermit Files (A Plea)
MS Kermit use of COM3
CMS Kermit under VM/XA/SF Clarifications
Distributing TAKE scripts.
Kermit 2.29 for Tandy 2000?
----------------------------------------------------------------------
Date: Fri 12 Sep 86 13:45:15-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Prerelease Version of MS-DOS Kermit 2.29A Available for Testing
Keywords: MS-DOS Kermit 2.29A, IBM PC, Rainbow
Cross-Ref: DEC Rainbow, see Rainbow
A prerelease test version of MS-DOS Kermit 2.29A is available for testing
on the IBM PC,XT,AT and compatibles, and the DEC Rainbow. This test version
is being released at this time mainly to help those who must use the program
for file transfer in half-duplex environments (e.g. with IBM mainframes or
certain HP or Harris minis) where line turnaround handshaking must be used;
version 2.29 has a bug that prevents this from working, and 2.29A fixes the
bug.
2.29A also includes some new features. These are not necessarily completely
developed or polished in this test release, but they appear to be mostly
functional and usable:
. Performance improvements, particular on the IBM PC family.
. Support for extended-length packets, up to 1000 bytes long.
. A script facility, almost identical to the one in DEC-20 Kermit.
. A TRANSMIT command, for raw uploading.
. An ECHO command.
. VT102 ANSI printer control support (IBM PC family only).
Extended-length packets may be enabled using the SET SEND/RECEIVE
PACKET-LENGTH command, and will be used if the other Kermit program supports
them. So far, only Kermit-11 (for PDP-11's with RSX, RT, RSTS, etc) does,
but version 3.1 of IBM VM/CMS mainframe Kermit, which will be announced
shortly (next week?) will also support long packets.
The script facility allows you to write "programs" of Kermit commands to
interact with the remote system. Scripts are typically used for dialing
modems, logging in on remote systems, or performing other routine and/or
complicated interactive jobs. The Kermit script is not a full-fledged
programming language (with variables, conditional branching, etc), but
differs from other popular script facilities by not differentiating script
commands from other program commands, so that all Kermit commands may be
freely intermixed in a script. The commands that were added specially to
support script execution include INPUT, OUTPUT, PAUSE, ECHO, plus various
SET options. The Kermit User Guide chapter for the DEC-20 (KER:K20MIT.DOC)
may be consulted for a complete description of the script facility.
Raw uploading is accomplished using the TRANSMIT command, which sends a
file "raw", a line at a time. It works like DEC-20 Kermit's TRANSMIT
command, and may (like any other Kermit command) be used in conjunction
with scripts.
The ECHO command includes \ooo escape sequence recognition for including
arbitrary characters in octal notation. This allows all sorts of fancy
special effects on the Rainbow by including VT100 commands in strings to
be echoed, and also on IBM PCs that have ANSI.SYS or similar console drivers
loaded.
ANSI printer support allows the PC to respond to host escape sequences
for printing selected regions of the screen, turning the printer on and
off, etc.
Version 2.29A is being put together by Joe Doupnik at Utah State University
(JRD@USU.BITNET), who also was responsible for version 2.29. The performance
improvements, bug fixes, and long packet support were done by Joe, and the
script facility came from James Sturdevant at AC Nielsen in Minneapolis,
and Joe integrated it into the new release.
The files are in KER:MSTIBM.BOO for the IBM family and KER:MSTRB1.BOO for
the Rainbow. Use any of the BOO-file decoders, KER:MSBPCT.*, to decode into
runnable .EXE files. A brief guide to the new features of 2.29A is in the
file KER:MST29A.HLP. No additional major functionality is intended for
2.29A, so please restrict your comments and suggestions to features that are
already in the program. Note that the MST*.BOO files may be replaced from
time to time as bugs are reported and fixed, up until the final release of
this version.
------------------------------
Date: Thu 11 Sep 86 10:29:15-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: New Release of Kermit for Concurrent (nee Perkin-Elmer) 3200
Keywords: Concurrent Kermit
Cross-Ref: Perkin-Elmer Kermit (see Concurrent Kermit)
This is to announce version 2.1 of Kermit for the Concurrent Computer
Company (formerly called Perkin-Elmer) 3200 series under OS/32 7.2.1 and
up, by Paul Mamelka, Southwest Foundation for Biomedical Research,
San Antonio, Texas. The major changes from version 2.0 of June 1985 are:
. Name change from Kermit-PE to Kermit-CO
. Horrible bug fixed caused by typo (RECKPT instead of RECPKT)
. Minor bugs also fixed
. First 3 letters of command or set option now sufficient for abbreviation
. SYSIO style now controlled by parity setting
. Selection of text, binary, contiguous file types
. End of record selection for text file transmission
. "File Warning" added (filename collision avoidance)
. Initialization file
. Automatic error logging
The new files replace the old ones as PERKIN.* in the Kermit distribution
(even though Paul sent them to us with the new prefix CON to denote the
company name change).
------------------------------
Date: Thu 11 Sep 86 11:44:59-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: New Kermit for Burroughs 7800 and A Series
Keywords: Burroughs Kermit
This is to announce Kermit for the Burroughs 7800 and other Burroughs large
systems (5000/6000/7000 and A series), written in Algol by Larry Johnson,
Dave Squire, and Katie Stevens at the Computer Center, University of
California at Davis. The program and user manual are in the Kermit
Distribution as B78*.*, alongside the other Burroughs mainframe Kermits,
B68*.* (for the 6800, from Quest Research, Inc), and B79*.* (for the 7900,
from THE--Technische Hogeschool Eindhoven). If any Burroughs aficionados
out there know if this new program makes either or both of the other two
redundant, please let us know so we can move them to a less critical area.
UC Davis has indicated willingness to supply this version of Kermit directly
to other Burroughs sites that request it directly from them. The address is:
David Squire
Senior Programmer, ID-1023
Systems Group, Computer Center
University of California, Davis
Davis, CA 95616 USA
------------------------------
Date: Fri 12 Sep 86 14:45:15-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Glut of Kermit Files (A Plea)
Keywords: Kermit Distribution
As Kermit's popularity escalates, more and more contributions of Kermit
programs show up on our doorstep. We know what to do with many of them:
new ones simply get installed (though often a good deal of file renaming
is necessary to avoid conflicts), etc. But what do we do when there are
multiple versions for the same system, or similar systems? In some cases,
we can't really tell when a version is redundant, because we don't know
enough about the systems involved (like the Burroughs mainframes mentioned
in the previous message). In other cases, two different people submit
totally different Kermit programs for the same system; should we keep both
(sometimes there are more than two!)? It would be most helpful if we could
get some feedback from the people who actually use these programs.
Here are a few items we could use some help with, as we try to clean up
our Kermit collection:
Apple II DOS - Does anybody use the native 6502 assembler version that was
based on an old release of the CROSS version? (By the way, a new,
native assembler version is under development at the U of Maryland, and
work is also being done on a new release of the CROSS version.)
Burroughs - Are all 3 versions (prefixes B68, B78, B79) necessary, or can
one or two of them be eliminated?
CDC - We have two CDC Cyber Kermits, one in Fortran, one in Compass. Do we
need both? Is one more portable, or clearly better in other ways, than
the other?
Commodore 64 - The "major" version is in CROSS, based on the Apple DOS version.
CROSS only runs on DEC-10s and DEC-20s, most of which are not long for
this world. Does anybody care enough about the C-64 to translate this
into a native assembler (if there is such a thing)? And what about the
other C-64 Kermit written in FORTH?
Data General MV Series with AOS, AOS/VS - We have several Kermits for these
systems. Most of these are quite old, primitive, buggy, and undocumented.
There are at least 3 or 4 separate efforts underway to replace them. I
have urged the various people or groups to get together and settle on a
single replacement. Watch Info-Kermit for news, or read the file
KER:AAWAIT.HLP in case you're interested in contacting any of these people
directly (this file contains a list of all the Kermit programs that we
know to be under development).
DEC PDP-11 - We have a main version (Brian Nelson's Macro-11 version) that
runs on all the DEC operating systems, but there's also an old OMSI Pascal
version just for RT-11. Does anyone use the Pascal version any more?
DEC Rainbow - Does anyone out there run QNX on the Rainbow? Have they tried
QNX Kermit? How about on the IBM PC?
DEC VAX/VMS - The main version is the Stevens Inst. of Tech. version written in
Bliss, but also distributed in Macro-32 source form. But there's also an
old Pascal version. Does anyone use the latter? Also, is anyone using
the VMS implementation of C-Kermit?
Gould/SEL 32 MPX-32 - We have two separate versions, both in Fortran, for this
system, prefixes GM1 and GM2. Do we need both? Can GM1 be retired?
Honeywell - All this Honeywell stuff is a mystery to me. In addition
to Multics Kermit (we have one version of this, but have heard that there
are several others floating around), there are two separate versions for
GCOS (one in B, one in C, prefixes HDP and HG, respectively), and two for
CP-6 (one in Pascal and one one in PL/6, prefixes HCP and HC6). Do we
really need all of these? How about "Level 6" or DPS-6? Can anyone who
really knows the Honeywell world recommend a consistent, minimal set of
good Kermit programs for the Honeywell line?
IBM 370 MVS/TSO - We have a couple different versions of Kermit for this
system, but they will all soon be replaced by a new comprehensive release
from the National Institutes of Health.
ICL/Perq - Does anybody still have Perq workstations? If so, can they tell
us if we really need two different Kermit programs for the Perq, both in
Pascal? (Prefixes PQK and PQ2.) If not, which one is better?
Intel - There are literally dozens of Kermit programs for Intel micros,
many of which we haven't either bothered to install. Some are for RMX
(or iRMX), some for ISIS. Can anybody who knows about Intel development
systems take a look at these and tell us which ones are redundant?
In addition to the MS-Kermit 2.29 Intel support modules, we have
specific Intel Kermit programs with prefixes RMX, I86, MDS, and MD2.
Software Tools - We have a version of Kermit written in Ratfor for use with
the Software Tools library. It reportedly runs on at least the HP-3000
and the Sperry 1100. Is anyone actually using it? Does anyone know if it
runs on any other systems?
Univac (oops, I mean Sperry (oops, I mean Burroughs)) 1100 - We have 3
Kermits for this one: prefixes ST (Software Tools), UN (Assembler), and
another UN (Pascal). Can any of these be sacrificed? At least, can one
of them (say, the assembler version) be considered the "main" one?
Victor 9000/Sirius 1 with MS-DOS - In addition to the support in MS-Kermit
2.29 for this system, there's also a C language version. Is anyone using
it?
Comments, comparisons, reviews, suggestions will be appreciated. The more
redundant material we can retire, the more room we have for new Kermit
programs, and the less often we have to add new tapes to the Kermit
distribution. Meanwhile, anybody who's considering writing a new Kermit
program or upgrading or fixing an old one, please contact Kermit
Distribution at Columbia before proceeding to make sure that your work
will not be duplicating someone else's. Thanks!
------------------------------
Date: 10 SEP 86 12:12-MDT
From: JRD@USU
Subject: MS Kermit use of COM3
Keywords: MS-DOS Kermit, COM3
In response to queries about use of more than two communication
ports with MS-DOS Kermit, I have compiled a few pointers.
MS Kermit, internally, does allow many serial ports: four directly and
as many as wished through rebuilding. As we all realize MS Kermit tries to
connect directly to the serial port hardware (the UART chip, if possible
so that characters can be read by an interrupt procedure. Hardware details
differ greatly among MSDOS machines so code for serial port specifics
is located in the system dependent module MSX---.ASM. The number of ports
visible on the Status screen is adjusted to match the kind of machine (model)
being used.
The system independent part of Kermit has a standard table of four
named ports, expandable to whatever size is needed, which hold nine bytes
of information for each port. That information is the baud rate index, flag
for local echo on/off, parity type flag, flow control bytes and on/off flag,
and handshake (line turn around) character and on/off flag. Expansion thus
uses little space. The system dependent module(s) examine this table to
decide how to setup the particular port. The table is found in file MSSCOM.ASM.
For IBM PCs and clones MS Kermit knows the hardware addresses
of COM1 and COM2, which have been specified by IBM. Higher comms port addresses
have not been standardized and thus are not mentioned in MS Kermit. However, it
is a simple matter to add new addresses to the list in MSXIBM and to readjust
the couple of tables which support the Set Port command (performed in MSXIBM).
The most recent (September) issue of PC Tech Journal has an article on
boards offering many serial ports, together with the range of addresses
provided by each board. It is unfortunate that the addresses near standard
comms ports are frequently used by other add-in hardware so that no consensus
exists for COM3 et seq. and hardware conflicts are common.
------------------------------
Date: Thu, 11 Sep 1986 13:47:00 EDT
From: Nick Gimbrone <NJG@CORNELLA>
Subject: CMS Kermit under VM/XA/SF Clarifications
Keywords: CMS Kermit
To clarify my question concerning CMS Kermit under VM/XA/SF. We currently
have and are running this operating system. The CMS we are running under it
is esentially identical to CMS R4 under an HPO system (we don't yet have
FILELIST and that ilk of commands up and we have a small mod to XEDIT to
address an LDEV problem). VM/XA does NOT support any TTY access. VM/XA/SF
only supports 3270s (real, or fake as with the 7171). When attempting to
run Kermit over a 7171 or Passthru (which works under VM/HPO and VM/SP
systems) under VM/XA/SF I get an addressing exception. I will eventually be
looking at this, but if anyone has already solved the problem I'd appreciate
hearing from them via the net. Thank-you.
------------------------------
Date: Thu, 11 Sep 1986 02:17 PDT
From: "Jeffrey Sicherman" <JAJZ801%CALSTATE.BITNET@WISCVM.WISC.EDU>
Subject: Subject: Distributing TAKE scripts.
Keywords: TAKE command, Script
Since one of the problems of using micro KERMITS with unfamiliar mainframes
is not knowing the necessary protocol parameters that may be required to
interface through front-ends and operating system peculiarities, a standard
way of distributing appropriate TAKE scripts on a system or site specific
basis would be desireable. Why not bootstrap them?
In particular, I would propose a
CONNECT TAKE [filename]
command for the local system. This would have the effect of CONNECTing to
the the host which should be running KERMIT in non-server mode (by
definition of the problems, we are not ready to send packets yet). The user
would then enter a new command:
GIVE [systemname]
on the host. Ignoring the optional name arguments for moment, the effect of
this would be that the local micro would interpret the lines coming from the
host not only as displayable data but as local commands, just as though a
local TAKE had been performed. Most likely these would be SET commands:
(almost) anything that would be valid in a local TAKE file (it would not be
wise to switch ports or line parameters at this point or invoke any
transfers or change of mode).
[Ed. - Well... It's a good idea, but complicated. The first pitfall is that
neither the host Kermit program nor the local one necessarily know what
parameters are really necessary -- for instance, if the connection goes
through an X.25 network, or bounces off a satellite, or is very noisy. The
user is the only one who really knows.]
Of course, a minimal subset of all possible commands would probably be
most appropriate for consistency across a broad range of micro
implementations; such a list would be sent when the GIVE is issued with no
systemname argument. It would establish the minimum conditions for a usable
and reasonably efficient exchange. Where differences are significant with
respect to different local systems, especially with regard to reliability or
efficiency, a systemname specification would send SETtings appropriate to
that combination. I have stated this as systemname rather than filename
since there is no reason that the responses could not be built into the
program rather than increasing the number of distribution files. This makes
it somewhat inflexible though, so there are good arguments on each side
(maybe I'm only arguing with myself) and I don't think the choice is
critical; either way will serve the purpose.
[Ed. - The problem here is that there are hundreds of programs to deal with,
and, because Kermit is a volunteer, cooperative, loosely organized effort
(at best), each program's syntax has its peculiariarities, despite the
efforts that have been made to settle on consistent terminology (e.g. in the
User Guide and Protocol Manual). Does this mean we have to change 50 or 100
programs to make them conform? Or does it mean that every mainframe Kermit
should have explicit knowledge of the variations in syntax used by all the
other Kermit programs? Unfortunately, both alternatives are impractical.]
The optional filename on the CONNECT TAKE command would cause the
received commands to be stored into a local file that could be TAKEn locally
for subsequent uses. Admittedly, this is not an error-free exchange but the
errors are likely to be noticeable to the operator when rejected by the
command processor and the process can be repeated. By saving an error-free
transmission, it need only be performed once or infrequently. For this
reason, a remote KERMIT implementation should probably announce the
existence of new values at initialization time when changes of significance
are made. If random (non-syndromatic) single character changes in
transmission are of concern (such as for decimal specifications of
block-check options, maximum lengths, framing character specifications) I
propose the following mechanism:
Define a new command called VERIFY which takes all the same operands as
SET but merely compares its target value to the current setting. If a
discrepancy exists, display an error message. By inserting SETs and VERIFYs
in the same GIVE transmission at appropriate intervals, most such errors
should be operator detectable. The implementation seems rather
straightforward to me since the same parsing could be used with a global
mode switch telling low level logic whether a store/call or compare/error is
to be invoked. A final possibility to minimize the possibility of an
erroneous transmission being used would to, either by default or command
variation, cause the commands in the take to be checked (and verified), but
only put into effect if no errors occur. This could be accomplished by
having an edit-only pass on initial receive and rereading the take
destination file if error-free. If the no-file-name variation were used, the
take stream could be stored in a temporary file and/or an internal buffer.
[Ed. - Kermit already has an automatic way for each Kermit program to
"configure" the other one with respect to settings for buffer size, packet
terminator, padding, timeout, etc., namely the Send-Init negotiation. These
packets provide a common intermediate representation for these parameters
and their values, something you don't get with textual SET commands, which
can vary from program to program (in fact, some programs don't have command
parsers at all, but use menus instead). Unfortunately, not everything can
be negotiated in these error-checked packets. Most notable are physical or
datalink settings like baud rate, parity, and flow control, because these
must already be set correctly before the Send-Init negotiation can take
place. And, still more unfortunately, these parameters are often unknown
(and sometimes unknowable) to the programs themselves. However, it is
possible to adopt some heuristics to get around some of the other problems,
and these can be fairly simple. One example would be automatic parity
detection -- when the program gets the first packet (S, I, Y, G, etc, which
will never contain 8-bit data), it can figure out what the parity is, if
any, and then adjust itself accordingly. This kind of trick seems more
practical and reliable than the proposed method of exchanging SET commands.]
------------------------------
Date: 11-Sep-1986 0946
From: g_hafner%wookie.DEC@decwrl.DEC.COM (Gary Hafner, DEC Littleton)
Subject: Kermit 2.29 for Tandy 2000?
Keywords: Tandy 2000 Kermit
1) Does anyone out there know of a version of MSKERMIT V2.29 that's been
modified for the Tandy 2000? If not, could someone take a minute and explain
what it would take to do such a thing? Being a mainframe-type of user rather
than a PC user, I don't really know a heck of a lot about MS-DOS, but I have
a relative that could use this program if there were some way to come up
with it (who knows, between the 2 of us we might even be able to come up
with it ourselves...).
[Ed. - The version of Kermit we have for the Tandy 2000 was based on an
ancient version of IBM PC Kermit, namely 1.20, when it was still a
single-module program just for the PC, adapted by Steve Padgett at the U of
Texas in Feb, 1984. The Tandy-specific code is under T2000 assembly
conditionals. It would be great if somebody could look at this code and
churn out MSX, MSY, and MSZ modules from it, to fit in with the current
multi-module MS-DOS Kermit.]
2) I understand there's already 2 files for the Tandy 2000, and one of them,
a file with a ".FIX" extension, appears to be in a form similar to the
"MSxxx.BOO" formats for other machines. Could someone jot down the names of
the programs that both create AND 'unscramble' this format? I'm not familiar
with it at all.
[Ed. - The .FIX file was a precursor to the .BOO file. It was a simple
4-for-3 (or was it 3-for-2?) encoding, but with no compression. The program
to decode the .FIX file (this was the only survivor of the species) was in
TA2EXE.BAS. However, as of now, both the .FIX file and the TA2EXE.BAS
program have been removed and replaced by a TA2000.BOO file, which you can
"un-boo" in the normal way, as described in MSBAAA.HLP. The .BOO file is
only about 18K long, compared with the 30K .FIX file (and 15K .EXE file).
The 8-bit binary .EXE file is now available in KB:TA2000.EXE, for those who
can FTP it directly from CU20B.]
------------------------------
End of Info-Kermit Digest
*************************
-------