home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
e
/
mail.87a
< prev
next >
Wrap
Text File
|
2020-01-01
|
654KB
|
15,302 lines
12-Jan-87 12:52:43-EST,21964;000000000000
Mail-From: SY.CHRISTINE created at 12-Jan-87 12:48:56
Date: Mon 12 Jan 87 12:48:56-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #1
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12270368802.71.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Mon, 12 Jan 1986 Volume 6 : Number 1
Today's Topics:
CUVMA bitnet link down 1/15 - 1/18
New Rainbow MS-DOS Kermit with VT-220 Emulation
C-Kermit and CRLF
Bug in C-Kermit
Xenix on IBM-PC/AT & SCO Xenix V
Kermit and Procomm
ASCII uploads using Kermit on the VAX
Kermit & DECserver 200's
Send/Receive Overlap Implementation Flaw
Function key map for PC Kermit
ISIS-II Kermit/bootstrap wanted
----------------------------------------------------------------------
Date: Fri, 9 Jan 87 11:46:24 est
From: Alan Crosswell <alan@curta.columbia.edu>
Subject: CUVMA bitnet link down 1/15 - 1/18
Keywords: BITNET
The communications controller for CUVMA's Bitnet link is scheduled to
be down from 7:00AM EST 1/15/86 through 8:00PM EST 1/18/86.
Directly connected nodes "upstream" (relative to CUNYVM) of CUVMA:
CUVMB, CUVMC, CUCCA, CUCHEM, CUCEVX, CUCSVM, CUGSBVM,
CUCSVM, CUTCV1, CUTHRY, GECRDVM1, NYSPI, NYUCCVM, NASAGISS.
This also means the BITNET-CCNET gateway at CUVMA will be unreachable
during this time.
------------------------------
Date: 19 Dec 1986 2150-EST
From: David L. Knoell, Basic American Food Company, Vacaville, CA 95696
Via: EIBEN@MARLBORO.DEC.COM
Subject: New Rainbow MS-DOS Kermit with VT-220 Emulation
Keywords: MS-DOS Kermit, Rainbow Kermit, Terminal Emulation
My company uses multi-vaxen (clustered and DEC-neted) including 8600,780's
and mult-micro VAXens. We also have many Rainbows and so have a vested
interest in their use as it relates to the VAX. It seemed a shame that DEC's
firmware only emulated a VT102 even though the keyboard looks exactly like a
VT220. For a while it didn't make much difference since VMS didn't know what
a VT220 was anyway. Now we are using SEDT under VMS and it sure does know
what a VT220 is. Well, one thing led to another and there were a few bugs in
MSXRB1 and also in the Rainbow's firmware which needed fixing and I've never
liked software which pre-empts any keys for its own selfish use without
giving the user a way to override, so...
New & Improved DEC Rainbow MS-Kermit Features:
1 o Full VT220 Terminal emulation including User Defined Keys.
All VT220 escape sequences are supported except the down-line
loadable character stuff. Insert Characters (ICH) and Erase Characters
(ECH) as well as Selective Erase in Line/Display are fully implemented.
Enhancements such as "turn off" character attributes are also included.
2 o Full VT102 printer port support as well as a VT240 "printer-to-Host"
loop-back enables Kermit to operate as a cheap "line-monitor".
3 o Interactive (during Connect) "Hot-key" definition of any key. Keys can
be assigned to ascii strings or to a "special-function). These
assignments are temporary for a single connect session but do override
all other key assignments except VT220 user defined keys. Over 80 special
functions are provided which include all ms-kermit standard functions
such as "prev screen,prev line,next screen,dump screen,print screen etc".
Many additional functions have been added which can be assigned either
temporarily via "connect mode help" or with the standard ms-kermit
SET KEY function. This usage is upward compatible with the current 2.29
release.
4 o Kermit functions currently assigned to keys with "embedded code" can be
disabled so a user can customize his kermit via SET KEY in a mskermit.ini
file. An example "ini" file is included which duplicates the current
"hard coded" functions.
5 o A "connect mode" interactive help section was added which
contains all sorts of goodies. In fact each of the functions selectable
from the "Main Help Menu" are also available as "special functions" and
can be assigned to any key. The current funtions include: Show All Keys;
Set Key to Special Function; Set Key To Ascii String; Special Interactive
Status; Show Kermit Internal; Set File Name. Chars keyed are in reverse
video, chars received in normal video. Control chars and sequences as
well as escape sequences are brite. In this mode most control/escape
sequences are not actually done however there are some exceptions.
Down-line loaded user defined key sequences are done as well as shift
keys to application mode etc..
7 o Improved scroll buffer management provides up to 20 screens of 132 chars
each. This is 480 lines of video memory and is allocated if enough free
memory is available. If not enough is available then less is allocated
on a line by line basis. The memory management has been improved so that
it always reflects exactally what has been received. All video attributes
are supported including double wide/hi stuff. If you scroll back and a
character is received to be put on the screen; then the scroll management
routines restore the screen before modifying video memory. The dump to
printer/disk routines also handle the character set shifts required to use
the Rainbow's multi-national character set and VT100 graphics.
8 o Source code has been re-organized along the same lines as the IBM version.
Author: David L. Knoell
Basic American Food Company
PO Box 1140
Vacaville Ca 95696
[Ed. - Many thanks! The .BOO file, sample initialization file, and extensive
documentation have been installed in the Kermit distribution areas as
MSVRB2.* (to distinguish them from the "mainline" Rainbow version, MSVRB1.*).
The program identifies itself as "Rainbow + MS-Kermit V2.29.1 4 July 86".
To turn on all the new functions, you have to TAKE the file MSVRB2.INI.
Unfortunately, we can't simply replace the old version, because the work done
by David duplicates -- incompatibly, of course -- much work that has already
been done on the next release of MS-Kermit by Joe Doupnik (yes, David and Joe
have now been put in touch with each other). Since the VT-220 emulation and
other improvements are so useful, this version is being released as an
alternate, more or less dead-end, Rainbow MS-Kermit. It seems to work as
advertised (tested on a Rainbow 100B), with one caveat: typing Ctrl-S (for
instance, to give a Search command to EMACS) freezes (XOFFs) the Rainbow
until a Ctrl-Q (XON) is typed. The source code for this version has been
sent to Joe to see if it can be adapted to the new release.]
------------------------------
Date: Thu, 1 Jan 87 17:32:11 PST
From: hoptoad!gnu@lll-crg.ARPA (John Gilmore)
Subject: C-Kermit and CRLF
Keywords: C-Kermit, UNIX Kermit
Re: Info-Kermit Digest V5 #20
>[Ed. - We can't reproduce this problem on our 4.2BSD (Ultrix 1.1, really) VAX
>750, but it's probably related to the well-known bug which inserts an
>extraneous CRLF into standard output every 4096 characters (this only happens
>with the -k option). There's nothing in the C-Kermit code that inserts this
>CRLF, so it must have something to do with Unix's blocking. Does anybody have
>an idea what must be done to convince Unix to leave out the CRLFs -- some
>kind of mysterious ioctl or fnctl applied to stdout, maybe?]
No such luck -- no Unix stdio that I've seen inserts CRLF's. Certainly not
4.2BSD's. What you write is what you get. Kermit *is* writing the CRLF
somewhere; maybe sometime when it thinks it's writing to the user's
terminal, it's actually writing to the data stream. Since under the -k
option both go to standard output, this would not be hard to do. I looked
in the kermit sources (though I don't run it here) and kermit seems to be
using stdout for all kinds of things, e.g. printing error messages that
should probably go to stderr instead.
You can probably debug this using dbx to watch what is happening in the
stdout buffer, e.g. "trace _iob[1]._buf" or some such. It'll be slow, since
it looks after each instruction or source line, but it should catch it for
you.
[Ed. - We'll look again, thanks.]
------------------------------
Date: 10-JAN-1987 11:30:56
From: mfmail!nwbuts!gas@uucp.wessex
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Bug in C-Kermit
Keywords: C-Kermit
I appear to have discovered a bug in C-kermit. We are currently running
version 4C(057) but I have also tried it on (061) with the same effect.
The problem occurs in sending files with file-type binary, and results in
the file being truncated. If the last sequence is a multiple-character
escape, which wont fit into what should be the penultimate packet, then
after that packet has been sent the flag (first) says that EOF has been
reached and gives up, although there is still a sequence to send.
I have looked at this and the problem seems to be in ckcfns.c in the routine
getpkt, but I have not yet worked out a fix. I would be grateful to know if
anyone else has already fixed the problem.
Gordon Scott
(Micro Focus, 26 West Street, Newbury Tel - 0635 32646)
[Ed. - This appears to be to be a real bug in the getpkt() function. A
cursory inspection of the source shows that the solution might be as simple
as moving the return() statement like this:
} else if (first == -1) { /* EOF from last time? */
first = 1; /* Setup for next time. */
return(size = 0); /* <--- delete this */
} else x = 1;
/* Do any leftovers */
for (size = 0; (data[size] = leftover[size]) != '\0'; size++)
;
*leftover = '\0';
if (first == -1) return(size); /* <--- and add this */
This is totally unverified; reports welcome. Thanks!]
------------------------------
Date: Wed, 7 Jan 87 00:55:42 EST
From: nelson@NLM-VAX.arpa (Gary Nelson)
Subject: Xenix on IBM-PC/AT & SCO Xenix V
Keywords: Xenix, C-Kermit, SCO Xenix
In response to request for users of C-Kermit 4D061 on SCO Xenix:
My configuration: IBM-PC/AT
SCO Xenix Release 2.1.3 (Update E & F)
CRC problems - none, all 3 block checks work fine to any system I use:
IBM-PC - MSDOS, MS-Kermit v2.29
Intel 310 Xenix, C-Kermit
DEC VAX 11/780 - BSD 4.3
DEC PDP-11/70, RSX11m-Plus
I agree, fixed several(??) releases ago.
However, the dial command did not work after updating to the release of SCO
Xenix V. The following diff file corrects problem in ckutio.c that broke
the dial command. Note, if you are on SCO Release 2.1.0 - DO NOT include
this fix, leave the 4D061 version as released alone - it works fine. The
nap() mod is not neccessary - just saw it and changed it to use an available
facility.
********** start of diff file **********
14a15,27
> /* Modification history:
>
> 23-NOV-86 Gary B. Nelson, Nelson Associates, Manassas, VA
> As a consequence of my new release of SCO Xenix V2.1.3
> breaking kermit:
> Mods to msleep to use nap(), note -> add "-lx" to
> LNKFLAGS in the makefile.
> Mods to tthang to make it work again, with this new release
> of XENIX (symptom was that the dial command
> stopped working, a problem that was incorrectly
> diagnosed by ?? as seen on the usenet a few days ago).
> */
>
527d539
< #ifndef XENIX /* xenix cannot do close/open when carrier drops */
532d543
< #endif
1416,1418c1427
< #ifdef XENIX
< #define CLOCK_TICK 50 /* millisecs per clock tick */
< #else
> #ifndef XENIX
1420d1428
< #endif
1431a1440,1446
> #endif
> #endif
>
> #ifdef UXIII
> #ifdef XENIX
> nap( (long) m );
> #endif
********** end of diff file **********
------------------------------
Date: 16 Dec 86 17:15:00 GMT
From: ihnp4!inuxc!pur-ee!uiucdcs!uxc.cso.uiuc.edu!crimmins@UCBVAX.BERKELEY.EDU
Subject: Kermit and Procomm
Keywords: Procomm
Re: Kermit and Procomm
/* Written 1:38 pm Dec 15, 1986 by vanzandt@uiucdcsp.cs.uiuc.edu in
uxc.cso.uiuc.edu:comp.sys.ibm.pc */
> Would someone please explain (in full detail) to me how to get Procomm 2.4
> to do Kermit transfers. I can get Xmodem to work fine, I can get Kermit to
> Kermit to work fine, I just can't get Procomm to Kermit to work...
It seems that you do not have your parity set the same on both sides, or
your packet lengths are not the same. On the Procomm side, I have usually
selected a packet lenght of 90. My guess, however, is that the parity is
set different on the two programs. Even if your host is set for no parity,
your Kermit might be looking for even parity. Look at the status screen on
Kermit to verify that it is set the same as Procomm. The parity on Procomm
will always correspond to what you are communicating at.
I have had no problems using Procomm to transfer vi Kermit to and from
uiucuxc. If you need more help, contact me at the address below or call our
office at 244-0608. Good Luck!
Dan Crimmins
University of Illinois at Urbana-Champaign
Computing Services Office - Micro Consulting Dept.
ARPA: crimmins@uiucuxc.cso.uiuc.edu
BITNET: crimmins@uiucuxc.bitnet
CSNET: crimmins@uiucuxc.csnet
UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!crimmins
------------------------------
Date: 21 Dec 86 06:22:47 GMT
From: MARKS-ROGER@YALE.ARPA
Subject: ASCII uploads using Kermit on the VAX
Keywords: VAX Kermit, Modems
I've never been able to get an error-free ASCII upload to my local VAX; the
average is an error about every 20 lines. At first I suspected Flash (would
be sad, since it's a fine terminal program) but now I find the same problem
with Uniterm. Even Kermit logs a zillion errors, many of which are fatal.
Now I suspect my Avatex 1200 (not 1200hc) modem. Can anyone shoot down this
theory for me by claiming successful uploads with that model?
I should point out that I get nary an error on downloads of any kind to the
ST.
Finally, to those of you who are waiting for the STEDT I promised, I'll send
it as soon as I get this problem licked.
Thanks.
Roger
------------------------------
Date: Thu 1 Jan 87 15:38:50-EST
From: Eric R. Crane <EC0N@TE.CC.CMU.EDU>
Subject: Kermit & DECserver 200's
Keywords: DECserver
We have just ordered some DECserver 200's and are wondering what special
considerations we will need when using KERMIT to transfer files to Vax VMS
systems over these lines.
Eric R. Crane
Carnegie Mellon University
Computation Center
Systems Software
Eric.Crane@TE.CC.CMU.EDU (Arpa)
R602EC0N@CMCCVB (Bitnet)
[Ed. - We encountered numerous difficulties trying to get Kermit to work on
Ultrix and TOPS-20 when connected through DECserver-100s (aka LAT boxes).
There are many parameters that have to be set correctly, and in some cases
the host's LAT service may have to be modified to allow input in bursts as
long as a typical Kermit packet. In TOPS-20's case, Kermit packet sizes had
to be cranked down to about 40 until this was fixed. Anyone who has
experience using Kermit through the DECserver-200 (or -100) is encouraged to
pass along any tips.]
------------------------------
Date: Wed, 7 Jan 87 17:43:49 PST
From: gts%violet.Berkeley.EDU@berkeley.edu (Greg Small)
Subject: Send/Receive Overlap Implementation Flaw
Keywords: Send/Receive Overlap
Apparently many Kermit implementations still have the old send/receive overlap
flaw. The problem is receiving while sending a packet. The receive buffer
should be cleared AFTER the current packet is sent. All implementers should
check their implementations and correct them if flawed.
The symptom is continuous retries while sending a file, usually resulting in
an abort. The retries occur about as rapidly as data packets would be sent,
e.g. once a second at 1200 baud (contrasted to 5-10 seconds for a timeout).
Normally Kermit sends data packets and receives ACKnowledgements
alternately. Abnormal conditions may cause the remote Kermit to send an ACK
or NAK while the local Kermit is sending a data packet. Because the local
Kermit did not clear its receive buffer or cleared it before sending the
packet rather than after, it reads the ACK received while it was sending.
This causes the local Kermit to resend the packet while the remote Kermit is
replying to the previous packet, so the overlap cycle repeats until an abort
or the timing is disturbed.
This has an additional twist for half-duplex Kermits such as IBM ASCII 37x5
and the Series/1-4994-7171 (physically full-duplex but logically
half-duplex). Because Kermit-CMS controls the channel, its ACK/NAK
guarantees that the received data packet will be bad, which in turn
guarantees another NAK, which guarantees another overlapped send, etc.
repeating the cycle.
The problem is more likely at 1200 baud where the packet takes almost a full
second to send (96 chars/120 cps) and much less likely at 9600 baud where
the packet takes only .1 seconds because the remote Kermit is less likely to
respond in less than .1 seconds. It is also more likely for long files
because the probability of the triggering event is greater.
Since we could not modify all Kermit versions in the field, we modified our
Kermit-CMS 2.01 to prefix 120 NULs to any NAK sent. This guarantees that
the receiving Kermit will not see the NAK until after it has stopped
sending.
Greg Small (415)642-5979
Personal Computer Networking & Communications gts@opal.Berkeley.EDU
214 Evans Hall CFC ucbvax!jade!opal!gts
University of California, Berkeley, Ca 94720 SPGGTS@UCBCMSA.BITNET
[Ed. - A more concrete illustration of this problem would be helpful - which
systems & Kermit versions, which one is sending & which receiving, etc.
We've never seen this behavior at Columbia, with our mix of IBM (linemode
and fullscreen) and DEC (DEC-20 and Unix) mainframes, MS-DOS micros, etc.]
------------------------------
Date: 8-JAN-1987 14:38:56
From: DGM1@UK.AC.YORK.VAXA
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Function key map for PC Kermit
Keywords: MS-DOS Kermit, Key Map
Please find enclosed a comprehensible (???) function key map for ibm pc
running ms-kermit 2.29 showing the vt-102 keypad. Has anybody had any
thoughts on a special version for the new (looks almost like a vt1xx) pc
keyboard?
Cheers,
Doug
Doug Moncur, Microsystems Advisor, Computing Service, University of York,
Heslington, York YO1 5DD
janet: DGM1@uk.ac.york.vaxa :: phone 0904-430000x487/5969
**** here goes...
ibm_pc/vt_102 keypad mapping for mskermit_2.29
<<EXPLANATION>>
+-------------------+
vt_102 equivalent for <SHIFT+FKEY>---> | 3 |
edt equivalent (U/CASE means GOLD)---> | char SPECINS |
ibm keytop---------------------------> |<<<<<<<< F5 >>>>>>>|
vt_102 equivalent for <FKEY>---------> | 7 |
edt equivalent (U/CASE means GOLD)---> | page COMMMAND |
+-------------------+
+-------------------+-----------------+
| 6 | , |
| cut PASTE | del_c UND_C |
|<<<<<<<< F1 >>>>>>>|<<<<<<< F2 >>>>>>|
| PF1 | PF2 |
| gold | help |
+-------------------+-----------------+
| 1 | 2 |
| word CHNGCASE | eol DEL_EOL |
|<<<<<<<< F3 >>>>>>>|<<<<<<< F4 >>>>>>|
| PF3 | PF4 |
| fndtxt FIND | del_l UND_L |
+-------------------+-----------------+
| 3 | enter |
| char SPECINS | enter SUBS |
|<<<<<<<< F5 >>>>>>>|<<<<<<< F6 >>>>>>|
| 7 | 8 |
| page COMMMAND | sect FILL |
+-------------------+-----------------+
| 0 | . |
| line OPEN_LINE | select RESET |
|<<<<<<<< F7 >>>>>>>|<<<<<<< F8 >>>>>>|
| 9 | - |
| append REPLACE | del_w UND_W |
+-------------------+-----------------+
| | |
| | |
|<<<<<<<< F9 >>>>>>>|<<<<<< F10 >>>>>>|
| 4 | 5 |
| advance BOTTOM | backup TOP |
+-------------------+-----------------+
------------------------------
Date: Mon, 12 Jan 1987 02:28 PST
From: JAJZ801%CALSTATE.BITNET@WISCVM.WISC.EDU
Subject: ISIS-II Kermit/bootstrap wanted
Keywords: ISIS-II Kermit
Is there anyone who can provide a copy of ISIS-II (Intel MDS) Kermit on 8"
single or double density ISIS-formatted diskette or a cheap and easy
bootstrapping method for it. Cable specs would be appreciated for the
latter, if provided.
Jeffrey Sicherman
JAJZ801@CALSTATE.BITNET
------------------------------
End of Info-Kermit Digest
*************************
-------
20-Jan-87 18:48:17-EST,24754;000000000000
Mail-From: SY.CHRISTINE created at 20-Jan-87 18:47:08
Date: Tue 20 Jan 87 18:47:07-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #2
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12272531160.313.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
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
*************************
-------
26-Jan-87 12:01:53-EST,23438;000000000000
Mail-From: SY.CHRISTINE created at 26-Jan-87 12:00:19
Date: Mon 26 Jan 87 12:00:19-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #3
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12274029966.329.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Mon, 26 Jan 1987 Volume 6 : Number 3
Today's Topics:
Announcing Kermit for PICK (REALITY) OS on Microdata Systems
Announcing Kermit for the CIE 680/XX Microcomputer
Announcing Kermit for the MODCOMP Classic running MAX IV OS
Kermit BITNET Distribution
Wang Kermit 2.29a Works!!!
Mskermit Version 2.29 Keys for the IBM PC
Bad Filenames in MS-DOS Kermit Version 2.29
MS-DOS Kermit Version 2.29b
Problems Compiling C-Kermit on ATT 3BX Systems
Update on Commodore-64/C-128 Kermit Wanted
----------------------------------------------------------------------
Date: Thu 22 Jan 87 15:13:03-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for PICK (REALITY) OS on Microdata Systems
Keywords: PICK Kermit
This is to announce a version of Kermit for the PICK operating system,
contributed by Joe Fisher, a computer consultant in Austin, Texas. This
first release, 0.2C, is written in DATA/BASIC (with some Microdata assembler
subroutines), and has been successfully run only on the Microdata (now
McDonald Douglas) REALITY systems under version 4.2E of the REALITY (the
original PICK) operating system. It is very much still in the development
stage (as reflected by the version number) and a great deal of work will be
necessary in order to bring it up to the expectations of the Kermit user
community. It will transfer error-free data however, and has been used with
a number of other Kermits, including IBM PCs with MS-DOS, DEC Pro-350 with
P/OS, VAX/VMS, PDP-11 with RSX, etc. The programs have been transferred to
PICK 1.3 running on the IBM PC-XT and testing is underway. Changes in the
I/O code will have to be made there but operation should be more reliable
than on the Microdata.
For the purposes of Kermit distribution, the numerous files have been packed
together into two large files, PICK.BAS and PICK.DOC -- source and
documentation, respectively. Each file-within-a-file starts with a line of
the form
<<< name >>>
in which "name" is the actual name of the original file. The files are
available in KER:PICK.* on CU20B, and as PICK * from KERMSRV at CUVMA on
BITNET.
------------------------------
Date: Fri 23 Jan 87 12:12:15-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for the CIE 680/XX Microcomputer
Keywords: CIE Kermit
This is to announce a version of Kermit for the CIE 680/XX microcomputer,
contributed by David S. Lawyer of the University of California at Irvine.
This program is only a stopgap measure until a later version of Kermit (the
so called C-Kermit for example) can be ported to the CIE. One exception to
this may be for CIE's which only have 256K of RAM. Since this kermit code
(when compiled) is much shorter than the C-Kermit, it will run well on
computers with limited RAM memory. This Kermit represents a modification to
the "UNIX Kermit" of 1981-1983.
NOTE TO NON-UCI USERS: UCI= The University of California at Irvine.
This Kermit program was developed for use at UCI and may not work as well
elsewhere without additional modifications.
The program named kerm (source code kerm.c in the C language) is a program
modified at UCI for use on the CIE computer which adheres to the Kermit
protocols. You may use Kermit to connect to a remote host, and then log on
to it using the connect command. Then you may either: use your CIE like a
fairly dumb terminal connected to the remote (i.e. have a session on the
remote computer) or utilize both the CIE Kermit and the Kermit on the remote
to transmit files between the remote and the CIE.
For the purposes of Kermit distribution, the numerous files have been packed
together into four large files, CIE680.C, CIE680.ANN and CIE680.BWR
CIE680.HLP -- source, this message, a beware file and limited documentation,
respectively. Each file-within-a-file starts with a line of the form
<<< name >>>
in which "name" is the actual name of the original file. The files are
available in KER:CIE680.* on CU20B, and as CIE680 * from KERMSRV at CUVMA on
BITNET.
------------------------------
Date: Fri 23 Jan 87 12:46:10-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for the MODCOMP Classic running MAX IV OS
Keywords: MODCOMP Kermit
This is to announce a version of Kermit for the MODCOMP Classic running
under the MAX IV operating system, contributed by BOB BORGESON, of SETPOINT,
Inc., 10245 Brecksville Rd., Brecksville, Ohio 44141. This release is
version A.0., and is written in FORTRAN and Assembler and should be compiled
with a FR5 compiler and assembled using the M5A assembler. The program has
been tested between the MODCOMP and an IBM PC running PROCOMM, a Macintosh
with Red Ryder and a micro-VAX with Kermit-32. MODCOMP Kermit has been
donated to the MODCOMP user group, MUSE.
For the purposes of Kermit distribution, the numerous files have been packed
together into three large files, MODCMP.ASM, MODCMP.ANN and MODCMP.DOC --
source, this announcement and documentation, respectively. Each
file-within-a-file starts with a line of the form
<<< name >>>
in which "name" is the actual name of the original file. The files are
available in KER:MODCMP.* on CU20B, and as MODCMP * from KERMSRV at CUVMA on
BITNET.
------------------------------
Date: Fri, 23 Jan 87 10:39:40 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Kermit BITNET Distribution
Keywords: BITNET, KERMSRV, EARN
I recently ordered Mcintosh Kermit from KERMSERV at CUVMA to be sent here to
the University of Liege in Belgium. This was on the 11th of this month. 12
days after, I just received CKMKER.HQX from the net. I am still waiting for a
DOC file. And I had promised it for 20th. Now, during that time, I've had
some peeping into BITNIC's RSCS queue. It used to amount to a mean 400 to
800 files. I have been amazed by the number of apparently huge Kermit files
(QUKERMIT) waiting for a chance to go. Short files take over larger ones and
get reasonable delays. Now my suggestion. Why not spare a sattelite channel
and install a Kermit redistribution site on the net this side the atlantic?
The problem being where and how to raise interest, you might take advantage
of Info-Kermit to ask for candidates. If you give away the file server and
claim for reasonable disk space and maintenance time, I think there might
well be some candidates. The only problem is, consequently, traffic load.
It costs nothing to ask anyway. Sincerely yours.
[Ed. - Sorry for the inconvenience. Are there any BITNET (EARN) sites in
Europe that would be willing to act as BITNET Kermit file servers? We
(Columbia) would be glad to send periodic tapes. KERMSRV software is
available for VM/CMS, written in Columbia Wylbur Exec language, and for
VAX/VMS written in DCL. A Kermit BITNET file server could also be
implemented using LISTSERV, which is already widely used in Europe. The
collection currently stands at about 50 megabytes, and growing. Meanwhile,
European sites might find it easier to take advantage of the European Kermit
tape distribution centers, one at Lancaster University serving the UK and
Eire, and for continental distribution, "Club Kermit" based in France, a
DECUS VMS SIG-style tape distribution tree.]
------------------------------
Date: Tue 20 Jan 87 00:09:01-EST
From: Christopher P. Lent <OC.PEDHEM@CU20B.COLUMBIA.EDU>
Subject: Wang Kermit 2.29a Works!!!
Keywords: Wang PC, MS-Kermit
I got the Wang-PC version of Kermit working. I also included all the 2.29a
modules and they seem to work perfectly.
So now all it's missing is:
Modem control for hangup
Define/show Key
Terminal Emulator (beyond WANG BIOS support).
Actual port names corresponding to Kermit's idea.
(Currently COM1 and COM2 are equivalent to AUX).
Many things work now which didn't before:
A. SET BAUD works (up to 19200 baud!)
B. Status no longer crashes kermit with "Divide overflow".
C. 2.29a commands (transmit,pause,input ... )
I'm working on the missing parts but I figured I'd send along a MSTWNG.EXE and
MSTWNG.BOO file to allow some of the rest of the world to get going while I
finish this up.
The version number on this version is:
Wang (CP Lent 19 Jan 87) Kermit-MS V2.29a 1 Oct 86
Chris Lent
OC.PEDHEM@CU20B.COLUMBIA.EDU (ARPA)
PEDHEM@CUCCFA (BITNET)
ihnp4!philabs!phri!cooper!chris (UUCP)
[Ed. - Thanks! The files have been placed in KER:MSTWNG.BOO and
KB:MSTWNG.EXE, and the new Wang support will be included in the next
release.]
------------------------------
Date: Mon, 19 Jan 87 09:38 EST
From: <MICHOT@UBVMS.BITNET>
Subject: Mskermit Version 2.29 Keys for the IBM PC
Keywords: MS-DOS Kermit, IBM PC Keyboard
Hi - regarding Doug Moncur's mapping of VT100 keys for use with MS Kermit
2.29 for the IBM PC keyboard; here at the University Of Buffalo the Micro
Information Center distributes MS Kermit 2.29 to students, faculty and
staff. A locally written, 140K ASCII file is included, discussing specific
file transfer/emulation situations, especially in VMS and CMS. Here is a
fairly long excerpt from the file. If you are interested in receiving the
entire 140K file, please send a blank IBM PC diskette with a written request
and return mailer to Micro Services Group, University Of Buffalo, Computing
Center, Buffalo, NY 14260. Please note that no electronic requests will be
acknowledged. However, I can send the entire file to Columbia University if
you feel it is worth considering as an addition to your current MS Kermit
distribution files.
Hope this helps- MICHOT = Micro Services Staff
michot@ubvmsc.bitnet
MS Kermit 2.29 uses the IBM PC function key area for these
functions. The IBM PC numeric keypad area DOES NOT correlate
to the VT100 keypad area in MS Kermit 2.29. In the IBM PC
function key area, the following diagram shows how the PC
function keys are defined as VT100 keypad keys:
(shifted function keys)
+---------+ +---------+ +---------+ +---------+
F1 | PF 1 | F2 | PF 2 | SF1 | KeyPad | SF2 | KeyPad |
| | | | | 6 | | , |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F3 | PF 3 | F4 | PF 4 | SF3 | KeyPad | SF4 | KeyPad |
| | | | | 1 | | 2 |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F5 | KeyPad | F6 | KeyPad | SF5 | KeyPad | SF6 | Enter |
| 7 | | 8 | | 3 | | |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F7 | KeyPad | F8 | KeyPad | SF7 | KeyPad | SF8 | KeyPad |
| 9 | | - | | 0 | | . |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F9 | KeyPad | F10| KeyPad | SF9 | Not | SF10| Not |
| 4 | | 5 | | Used | | Used |
+---------+ +---------+ +---------+ +---------+
To function effectively in CMS, you need to know what function
keys on the IBM PC perform what function in CMS. The
following diagrams illustrate how you would use the IBM PC
function keys (and shifted function keys) in CMS:
(shifted function keys)
+---------+ +---------+ +---------+ +---------+
F1 | PFK1 | F2 | PFK2 | SF1 | PFK9 | SF2 | PA3 |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F3 | PFK3 | F4 | PA1 | SF3 | PFK10 | SF4 | PFK11 |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F5 | PFK4 | F6 | PFK5 | SF5 | PFK12 | SF6 | Clear |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F7 | PFK6 | F8 | PA2 | SF7 | | SF8 | Insert |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F9 | PFK7 | F10| PFK8 | SF9 | | SF10| |
+---------+ +---------+ +---------+ +---------+
The next diagram scopes out the IBM PC function key
definitions using the XEDIT CMS Editor with MS Kermit 2.29:
(shifted function keys)
+---------+ +---------+ +---------+ +---------+
F1 | Help | F2 | SOS | SF1 | | SF2 | |
| | | Lineadd | | | | |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F3 | Quit | F4 | BRKKEY | SF3 | Rgtleft | SF4 | Spltjoin|
| | | | | | | |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F5 | TabKey | F6 | SChange | SF5 | Cursor | SF6 | Clear |
| | | 6 | | Home | | Cmd line|
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F7 | Redisply| F8 | | SF7 | | SF8 | Insert |
| Subcomm | | | | | | |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F9 | Backward| F10| Forward | SF9 | | SF10| |
| | | | | | | |
+---------+ +---------+ +---------+ +---------+
The next diagram illustrates the EDT full screen editor
keypad definitions that would be used on the IBM PC
function key area using MS Kermit 2.29:
(shifted function keys)
+---------+ +---------+ +---------+ +---------+
F1 | Gold | F2 | Help | SF1 | Cut | SF2 | Del C |
| | | | | [Paste] | | [Und C] |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F3 |Find Next| F4 | Del L | SF3 | Word | SF4 | Eol |
| [Find] | | [Und L] | |[Cngcase]| |[Del Eol]|
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F5 | Page | F6 | Sect | SF5 | Char | SF6 | Enter |
| [Cmd] | | [Fill] | |[Specins]| | [Subs] |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F7 | Append | F8 | Del W | SF7 | Line | SF8 | Select |
| [Repl] | | [Und W] | |[Open Ln]| | [Reset] |
+---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+
F9 | Advance | F10| Backup | SF9 | Not | SF10| Not |
| [Bottom]| | [Top] | | Used | | Used |
+---------+ +---------+ +---------+ +---------+
Press GOLD get first to get bracketed [] functions
------------------------------
Date: Mon 19 Jan 87 22:44-EST
From: Ed Barton <EB%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Bad Filenames in MS-DOS Kermit Version 2.29
Keywords: MS-DOS Kermit
The IBM-PC implementation of Kermit 2.29 does not catch filenames that are
actually device names. This was a great deal of trouble to figure out,
though perhaps the problem should have been obvious when it occurred. For
example, if the file AUX.C is transferred to IBM-PC Kermit, Kermit will get
an error trying to write device AUX, which is how MS-DOS interprets the
filename AUX.C. AUX.C should have been changed to XAUX.C or something.
------------------------------
Date: Mon, 19 Jan 87 21:07:55 est
From: Joel Seiferas <joel@rochester.arpa>
Subject: MS-DOS Kermit Version 2.29b
Keywords: MS-DOS Kermit
During a file transfer, in both 2.29a and 2.29b, the "File name" and
"KBytes transferred" data usually flash only briefly on my screen before
disappearing. I'm working at 1200 baud, over a phone line; and I am dis-
playing on an IBM Monochrome Display, via a 64K IBM EGA. My PC is an early
one, but I have updated the BIOS and replaced the 8088 with an NEC V20. My
screen driver is Fansi-Console 2.0.
Joel Seiferas
joel@rochester
------------------------------
Date: Tue, 13 Jan 1987 11:40 EST
From: Lawrence Fan <GYACC@CUNYVM>
Subject: Problems Compiling C-Kermit on ATT 3BX Systems
Keywords: C-Kermit, UNIX Kermit, ATT 3BX
I am having a compile problem with C-Kermit 4D(061) on ATT 3BX systems. I
get warnings when I compile. Not enough to kill the process but
nevertheless, trouble. The 'make' did finish and I do have wermit and it is
able to run... but the warnings are bothering me. I am enclosing the
warnings when I do 'make att3bx':
cc -DUXIII -DATT3BX -DDEBUG -DTLOG -i -O -c ckuusr.c
"ckuusr.c", line 1047: warning: illegal pointer combination, op =
"ckuusr.c", line 1048: warning: illegal pointer combination, op =
cc -DUXIII -DATT3BX -DDEBUG -DTLOG -i -O -c ckutio.c
ckutio.c: 23: extra tokens (ignored) after directive
ckutio.c: 94: extra tokens (ignored) after directive
ckutio.c: 451: extra tokens (ignored) after directive
ckutio.c: 1151: extra tokens (ignored) after directive
ckutio.c: 1166: extra tokens (ignored) after directive
ckutio.c: 1574: extra tokens (ignored) after directive
"ckutio.c", line 950: warning: illegal pointer combination, op ==
cc -DUXIII -DATT3BX -DDEBUG -DTLOG -i -O -c ckudia.c
"ckudia.c", line 583: warning: illegal pointer combination, op !=
"ckudia.c", line 623: warning: illegal pointer combination, op =
"ckudia.c", line 624: warning: illegal pointer combination, op =
cc -DUXIII -DATT3BX -DDEBUG -DTLOG -i -O -c ckuscr.c
"ckuscr.c", line 253: warning: illegal pointer combination, op =
Thanks a lot for your help.
[Ed. - There are two problems. First, your compiler is complaining about
"extra tokens" after #endif and #else directives in ckutio.c, the most
heavily conditionalized module of C-Kermit. These "tokens" are merely the
proprocessor variables (like ATT3BX) from the matching #if, added for
clarity. Most compilers don't complain about them, and they don't seem to
be causing any real problem. Perhaps in the next release they should be
turned into real comments, e.g. "#endif V7" will become "#endif /* V7 */".
All the other messages ("illegal pointer combination") have to do with the
signal() function; see signal(2) in your Unix manual. 'signal()' is
supposedly declared (in <signal.h>) like so:
int (*signal(sig,func))();
int sig;
void (*func)();
i.e. 'signal' is a pointer to a function that returns an integer (see p.195
of the C book). The 'func' is either a symbol, such as SIG_IGN, defined in
<signal.h>, or a pointer to an integer function that you supply. Symbols
are defined like so in <signal.h>, at least on my 4.2BSD system:
#define SIG_IGN (int (*)())1
i.e. a pointer to an imaginary function that returns a constant of 1 (did I
say that right?) When you invoke signal() to associate a new function with
a particular signal, it's supposed to return a pointer to the function that
was previously associated with that signal, allowing you to save, restore,
and test the interrupt structure. Thus Kermit does things like:
int (*istat)(), (*qstat)();
> istat = signal(SIGINT,SIG_IGN); /* Let the fork handle keyboard */
> qstat = signal(SIGQUIT,SIG_IGN); /* interrupts itself... */
:
:
signal(SIGINT,istat); /* Restore interrupts */
signal(SIGQUIT,qstat);
and
> if (signal(SIGINT,SIG_IGN) == SIG_IGN) ... ;
Your compiler is complaining about the statements marked with ">" because it
believes there is a type mismatch between signal() and istat, qstat, and
SIG_IGN. Check the definition of signal() in your system's <signal.h> and
see if you can find out why, then let us know. The rest of the "illegal
pointer combinations" are of the same nature. If some new release of the
ATT 3BX C compiler and/or header files is causing this problem, we'll have
to do something special within ATT3BX conditionals, since the current setup
seems to cause no problems on other systems. Let's hear it for portability...
Can any ATT 3BX System V experts out there shed any further light?]
------------------------------
Date: 15 Jan 87 06:22:28 GMT
From: ggw@ethos.UUCP (Gregory Woodbury)
Subject: Update on Commodore-64/C-128 Kermit Wanted
Keywords: Commodore-64
A few months ago, someone asked if there were any plans to update the C-64
kermit for a native mode C-128 kermit. I have been watching with bated breath
for a reply (but apparently in vain). It seems that with the expanded memory
available in the 128 that a significantly better version could be made, without
requiring the users to resort to the CP/M mode to get a better kermit. Any
information on this project would be appreciated.
Gregory G. Woodbury The usual disclaimers apply
CEO, Research Triangle C-64/128 User's Group
{duke|mcnc|rti-sel}!ethos!ggw The line eater is a boojum snark!
------------------------------
End of Info-Kermit Digest
*************************
-------
5-Feb-87 12:23:07-EST,19235;000000000000
Mail-From: SY.CHRISTINE created at 5-Feb-87 12:18:13
Date: Thu 5 Feb 87 12:18:13-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #4
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12276654667.181.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Wed, 4 Feb 1987 Volume 6 : Number 4
Today's Topics:
MS-DOS Kermit 2.29b
Note for Testers of MS Kermit 2.29b.
MS-DOS Key Definitions
Kermit Keyboard Redefinition
Keyboard Translator
Bugs in WART
Commodore-64/C128 Kermit
Rationale for C-Kermit's approach to DTR?
Kermit for Apple // ProDOS?
----------------------------------------------------------------------
Date: 26 JAN 87 21:02-MDT
From: JRD@USU
Subject: MS-DOS Kermit 2.29b
Keywords: MS-DOS Kermit, 2.29b
RE: Kermit Digest V6 #3
Ed Barton reported that MS DOS interprets incoming filenames
such as AUX.C as meaning send the contents to device AUX. He recommends
Kermit rename the file to XAUX.C or similar. I just tested this situation
by having a VAX send this note as AUX.C to my micro running PC DOS 3.21.
The file was automatically renamed to AUX00001.C because AUX was recognized
as an existing file. This is with MS Kermit 2.29b. Earlier versions may
not detect the device name.
There are circumstances where device names are wanted as file
destinations, a serial printer connected to COM1 (AUX) is one of them.
Another small complication is that MS DOS character devices are known by
their names (CON, AUX, PRN, and the like) so that non-standard drivers
can have names in conflict with incoming files without Kermit being
aware of the sensitive names. MS Kermit knows nothing about real device
names per se and relies on DOS itself to reveal a potential conflict.
A workaround is to use an override filename when receiving such a file:
Kermit-MS> Receive Foo.bar
replaces the incoming filename with Foo.bar.
Joel Seiferas said the file transfer screen flashed on only
momentarily with his IBM PC w/Fansi-Console 2.0. Kermit follows DOS's
rules for the display. I suggest he try again without Fansi-Console
because such utilities trap video i/o and apply their own rules. Kermit,
of course, is completely unaware of the Helpful Utility and does not
need an ANSI interpreter. There was an earlier problem with Fansi-Console
when Kermit displayed the Connect mode status line; Fansi-Console's author,
Bob Smith, fixed that this summer.
My local tester of Zenith 100 Kermit version 2.29b says that it
works! One bug concerned cursor addressing after toggling the mode line
while in Connect mode. He promised to bring around tech documentation on the
Z100. Until advantage can be taken of those details I think we ought to try
out MSK 2.29b on the Z100. Therefore, following this note is file MSTZ10.BOO
for the Z100.
Regards,
Joe D.
[Ed. - Thanks Joe! The .BOO file for the Zenith 100 is in KER:MSTZ10.BOO if
anyone wants to test it. See message from Joe below.....]
------------------------------
Date: 26 JAN 87 22:11-MDT
From: JRD@USU
Subject: Note for Testers of MS Kermit 2.29b.
Keywords: MS-DOS Kermit, Z100 Kermit, Zenith 100 Kermit
Notes for testers of MS Kermit version 2.29b
The Kermit Digest, Volume 6 number 3, 20 Jan 1987 contained a list
of improvements and new features found in maintainence release 2.29b. A
slightly longer version is reproduced below. As the Digest notes, we want to
make sure the present material is in good shape so the next major release,
2.30, will be more stable. So, the pleasant task of current testing is to
exercise Kermit, discover problems, and relay symptoms and even solutions
to Columbia or myself.
One possible problem is MS Kermit will attempt to send 94 byte
packets to a remote host which asks for smaller ones.
Another is a HANGUP command in a script might clear the modem DTR
and RTS signals so that the next serial port operation thinks they are still
active whereas the modem is asleep.
A concern is detection of the XON/XOFF flow control characters when
parity is being used. With the new allowance of 8 bit characters an incoming
8 bit character could appear as XON or XOFF with the high bit set. Testing
is needed here.
Similarly, the new ANSI printer control needs testing.
Terminal emulation in IBM Kermit is clearly a target for bug hunts.
Difficulties with line wrapping and the like using various editors is a
common problem. If you are using a popular Helpful Utility (the terminate
and stay resident kind) and note an anomoly try to detect if the H.U. is the
culprit so that other users will know of likely pit-falls. Sometimes it is
hard to note what are proper versus observed operations; an annotated LOG is
a good starting point since I can try to repeat the offending character
sequences. Escape characters in a LOG file are best translated to "ESC" or
other printable code for network transmission; a .BOO file also works if an
English description is sent along with it.
We are especially interested in knowing if MS Kermit 2.29b
successfully communicates with a wide varitey of hosts and through various
communications front-end devices. At this stage Kermit knows little about
Local Area Networks; your experiences would help.
Thanks for your time and help,
Joe Doupnik
jrd@usu.Bitnet
Center for Atmospheric and Space Sciences
Utah State University
Logan, Utah 84322
(801) 750-2982 (work)
[Ed. - The updates to MS-DOS Kermit 2.29b are described in KER:MST29B.UPD]
------------------------------
Date: Mon 26 Jan 87 20:07:46-EST
From: D. M. Rosenblum <DR01@TE.CC.CMU.EDU>
Subject: MS-DOS Key Definitions
Keywords: MS-DOS Kermit, Keys
In the INFO-KERMIT digest, Vol. 6, No. 2, Joe Doupnik asks for comments
about what users would like in a Kermit key translation system. One thing
that I would like (that I have asked about before) is the ability to specify
key translations that may take effect (and be disabled) only on the receipt
of certain character sequences from the remote host.
For instance, on a real VT1xx terminal (or a VT52, for that matter), there
are certain escape sequences that the host can send that will cause the
keypad keys to generate something other than their normal characters; there
are other escape sequences that the host can send that will cause the keypad
keys to revert to their normal characters. What would be nice is to be able
to specify a set of key definitions that should take effect automatically
when such an escape sequence is received from the host, and should cease to
be in effect when the escape sequence that would normally turn off the
alternate definitions is received ("cease to be in effect" here would imply
reverting back to either the default key definitions, or possibly some
user-specified defaults -- in other words, the user should be able to
define, say, the long keypad "+" key on an IBM-PC keyboard to mean one thing
most of the time, but to mean something else when the host has sent the
escape sequence that puts the keypad into alternate keypad mode, and to
revert back to his/her "most of the time" definition when the host sends the
escape sequence that puts the keypad back into normal mode). Since Kermit
is emulating a VT102, the escape sequences that have this effect are
well-defined (the only reason I'm not mentioning them here is that I don't
have a VT1xx manual readily available at the moment), and one wouldn't have
to accomplish the impossible task of thinking of what the right escape
sequences should be to have this effect.
Daniel M. Rosenblum, Ph.D. candidate,
School of Urban and Public Affairs (SUPA), Carnegie-Mellon University
ARPAnet (Internet): DR01@TE.CC.CMU.EDU
CSnet: use the appropriate gateway to ARPANET
BITnet: DR01%TE.CC.CMU.EDU@CMUCCVMA or DR01%TE.CC.CMU.EDU@WISCVM;
DR01@CMCCTE or DR01@CMCCTE.CCNET may work from some sites.
CCnet (DECnet): DR01@CMCCTE or DR01@TE.CC.CMU.EDU or DR01@CMCCTE.#DECnet
CMSPVX::SPPHDR01 (VAX DECnet only)
------------------------------
Date: Tue, 27 Jan 87 17:45:50 EST
From: "Roger Fajman" <RAF@NIHCU>
Subject: Kermit Keyboard Redefinition
Keywords: MS-DOS Kermit, Keys
I would really like to see the keyboard translator get away from numeric
codes. It's very unfriendly and thus discourages people from using the
facility. One way to do this while still maintaining machine independence
is to allow the key names and code names to be defined via Kermit commands.
Then one person has to suffer once for each type of machine (to define the
correspondence between key names and scan codes. It also allows things like
new F12 keys to be handled without changes to Kermit. Here is a sample
syntax:
To define keys:
<command> ::= SET KEY <key-name> <key-def>
<key-def> ::= <key-item>
| <key-item> <key-def>
<key-item> ::= <number> [to represent an ASCII code]
| <quoted-string>
| <key-name> [to refer to another key definition]
| <Kermit-function>
| <code-name> [to refer to a predefined code sequence]
<Kermit-function> ::= ESCAPE
| BREAK
| PRINTON
| PRINTOFF
etc.
<number> is any of the following:
decimal integer
octal integer suffixed with the letter O
hex integer with a leading digit and suffixed with X
Suffix letters could be either case.
Alternatively, the backslash notation could be used for
octal and hex.
<quoted-string> is zero or more characters enclosed in single or
double quotation marks. If a quotation mark of
the same type as the enclosing ones is contained
in the string, it must be doubled.
To define the correspondence between the names of keys and scan codes:
<command> ::= SET KEYNAME <key-name> SCAN <number>
To define names for ASCII codes, escape sequences, etc.:
<command> ::= SET CODENAME <code-name> <code-def>
<code-def> ::= <code-item>
| <code-item> <code-def>
<code-item> ::= <number>
| <quoted-string>
| <code-name>
Of course, there should be corresponding SHOW commands for each of the set
commands, but I will omit their definitions.
Examples:
Make q key send z:
set key q "z"
assuming:
set keyname q scan ### [### represents the scan code for the q key]
Make control-G key send ANSI attributes off sequence:
set key cntl-g normal
assuming:
set keyname cntl-g scan ### [### represents scan code for control-G]
set codename esc 01bh
set codename normal esc "[0m"
Define control-L to send login sequence:
set key cntl-l "login" cr "myname" cr "mypass" cr
assuming:
set keyname cntl-l scan ### [### represents scan code for control-L]
set codename cr 0dh
The advantage of this scheme is that only once per different kind of machine
does someone have to sit down and set up a file of SET KEYNAME commands to
establish the correspondence between names of keys and scan codes. Everyone
would then use these names by having a TAKE command for the definition file
in their MSKERMIT.INI file.
Likewise, people could define files of code sequence names. Some obvious
sets of useful definitions are the mnemonics for ASCII control codes and
VT102 escape sequences. Again, many people could benefit from the work of
one person in setting up such definition files.
Once such definition files were available, people could redefine the
keyboard without having to think about scan codes, numeric values of ASCII
codes, or obscure escape sequences.
What do you think?
Roger Fajman
------------------------------
Date: Tue, 20 Jan 87 21:25:26 EST
From: Russell Nelson <bh01@clutx.BITNET>
Subject: Keyboard Translator
Keywords: Keyboards
Well, I have experience with two keyboard translators.
Freemacs
Freemacs is a programmable editor that supports the IBM-PC and Z-100. It is
freely copyable, hence the name, and source is available. I anticipate that
people will want to port it to other MS-DOS machines besides these two, and
of course you always have a keyboard problem. The module that contains the
dependent code has a keyboard translator that translates the keys into
strings. I use strings because the programming language is very string
oriented, and they are more self- documenting than numbers.
Windows
Windows will run on any MS-DOS machine for which a driver can be written.
Specifically, Windows has a keyboard driver, which translates the keycodes
into three sets of numbers: the required virtual keys (every driver must
supply them; they include all ASCII characters plus a few like F1 through
F10), the optional virtual keys (like Left, Middle, and Right for the
optional mouse buttons, F11 through F16, etc)., and the machine dependent
virtual keys. All but the machine dependent keys are standardized. F12
returns the same code for all machines on which it exists.
Both are reasonable solutions. I believe that the Windows version is better
IF you let the user input the names of the required and optional keys. The
code for the names can be looked up in a table. I think that it is
resonable to expect the user to look up the machine dependent keycodes.
-russ
GEnie: BH01
BITNET:BH01@CLUTX
uucp: decvax!sii!trixie!gould!clutx!bh01
------------------------------
Date: 28-JAN-1987 14:08:40
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
From: Chris Kennington (cjk@uk.ac.salf.r-d)
Subject: Bugs in WART
Keywords: C-Kermit, WART.C
I have been setting up the WART preprocessor as a general tool on my
MSDOS micro (i.e. not part of a unix or similar MAKE), and have found the
two following problems:-
1. It won't discard a comment on the states line (and so won't even
process its test-program). Correction is to insert a call
to "rdcmnt(fp)" in routine "rdstates()" if after the line
"if (isspace(c) ......" you come out with c == '/'.
Note that this problem shows up with a very odd diagnostic,
as the routine then attempts to insert a null state into
the table, and the algorithm always gives a match on a null
state.... You'd still get the diagnostic if there was
garbage on the line.
2. Under MSDOS using Aztec-C, because of the anomalous way that this
compiler treats '\n', you get a .c program output in which many
of the lines are separated by LFs, not by CRLF pairs (as required
by MSDOS). Feeding this to Aztec blows the compiler. The
outputs from printf() are OK, since Aztec puts in a CRLF pair
when '\n' is found in a format-string; but the copying
routines using "putc(c,fp)" calls come to grief. Simplest
cure I can think of (tho' not efficient) is to replace all
these calls by ones to "outc(c,fp)", where this is coded:-
outc(c,fp)
char c; FILE fp;
{
if (c == '\n') putc('\r',fp);
return(putc(c,fp));
}
For more generality, this could be conditionally compiled
with a simple macro for outc(), depending on a #ifdef.
I may do a bit more generalizing on the WART program, to make it
suitable for programs which have several state-tables in them, possibly
nested one within the other. If so, I will feed the resulting prog back to
you (both Lancaster & Columbia).
Chris Kennington (cjk@uk.ac.ucl.cs)
[Ed. - Thanks for the comments on Wart -- we'll put them in its "beware
file" for now.]
------------------------------
Date: Wed, 28 Jan 87 21:39:25 est
From: "Ray Moody" <aij@s.cc.purdue.edu>
Subject: Commodore-64/C128 Kermit
Keywords: Commodore-64 Kermit
RE: Inquiry in the Info-Kermit Digest V6 #3
The posting made several months ago is not mine, but I am currently
working on C64/C128 Kermit. Some of the features I _PLAN_ to add include
support for the C128 80 column screen and VT100 emulation.
I do _NOT_ plan to have this version of Kermit run in native 128 mode.
The 80 column screen can be accessed in C64 mode, and we are not out of
memory yet. I see no reason to seperate C128 Kermit form C64 Kermit.
If you have any features you want to have added to C64/C128 Kermit, please
send me Email.
Ray Moody
aij@s.cc.purdue.edu
pur-ee!s.cc.purdue.edu!aij
------------------------------
Date: Tue, 27 Jan 87 11:01:03 CST
From: Dave Capshaw <capshaw@MCC.COM>
Subject: Rationale for C-Kermit's approach to DTR?
Keywords: C-Kermit, DTR
What is the rationale for the way that C-Kermit 4D(061) manipulates DTR? To
hang up the phone, C-Kermit uses ioctls to explicitly clear and set DTR
which leaves DTR asserted even after Kermit exits. (This is what surprised
me.) What is the advantage of this approach over having DTR simply follow
the open/close state of the line?
[Ed. - The ioctl's are in the function tthang(), in the file ckutio.c, under
the Berkeley conditionals (apparently ATT-type systems do it another way --
setting the baud rate to zero). The code clears DTR, sleeps half a second,
then restores DTR. Are there any Unix wizards out there who can explain why
(a) this is necessary, or (b) why it should not be done. I hesitate to
simply remove the ioctl that restores DTR, because somebody must have put it
there for a reason... Also, I assume that close() does not affect the state
of DTR?]
------------------------------
Date: Tue 27 Jan 87 00:51:38-PST
From: Mark Crimmins <CRIMMINS@CSLI.Stanford.EDU>
Subject: Kermit for Apple // ProDOS?
Keywords: Apple II Kermit, ProDOS
There was some talk a while back in the Digest about various people
developing a version of Kermit for Apples that would (i) support 80 column
displays, and (ii) use the ProDOS operating system. I KNOW there's a demand
for this --- does anyone have a working version of such a thing yet?
Thanks,
Mark Crimmins
CRIMMINS@CSLI.STANFORD.EDU
------------------------------
End of Info-Kermit Digest
*************************
-------
18-Feb-87 18:04:40-EST,23191;000000000000
Mail-From: SY.CHRISTINE created at 18-Feb-87 18:00:37
Date: Wed 18 Feb 87 18:00:37-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #5
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12280124870.69.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Wed, 18 Feb 1987 Volume 6 : Number 5
Today's Topics:
New Release 2.0 of Kermit/TSO
Kermit Article in Computerworld
Subscription to Info-Kermit Digest Via LISTSERV
Info-Kermit Digest Subscription
New Info-Modems mailing list
C-Kermit on ATT3B2 (Revised)
Re: C-Kermit Compile Problems on AT&T 3BX
Complaints about AT&T 3BX Kermit
C-Kermit 4D(061) on the Masscomp
/Q in Fansi-Console
Fansi-Console and Tallscreen
Bad Filename in MS-DOS Kermit Version 2.29
MS-DOS Kermit and Mouse Definitions
MS-Kermit Key Definitions
Prime Kermit and Kermit Sliding Windows
Intel MDS Kermit
CMS TAKE File for Mac Kermit National Characters
----------------------------------------------------------------------
Date: Tue, 3 Feb 1987
From: Fritz Buetikofer <M70B@CBEBDA3T.BITNET>
Subject: New Release 2.0 of Kermit/TSO
Keywords: TSO Kermit
Good new year ... good news !!!
Finally I found time to implement long packets into Kermit/TSO !
After reading thorougly the documentation of long packets and sliding
windows, I decided to try an implementation of long packets only, because
you don't get any full duplex channels on a TSO system (Here I refer to the
letter of Roger Fajman of Tue, 30 Jul 1985). To my astonishment the changes
for long packets were not so many !! And after one day of testing I had the
first transfer with long packets running. As we are connected via a local
area network to the host, I decided to start with a maximum packet size of
1K, which seems to be wide spread. Then I thought it would be useful, to set
the checktype automatically to 3 (CRC), if the packet size exceeds a certain
limit, which I put to 256 chars. In this period I found severe problems in
this Kermit version, because it sent wrong checktypes in certain cases. So I
had to fix this too ...
At this point I'd like to send a 'thank you' to the makers of Kermit-MS. As
the latest test version of Kermit-MS supports long packets, I had a good
test partner for my version.
In the past time I had some questions about the extended ascii table,
supported in my Kermit version. I think I should explain a little bit more
what I mean with this feature:
In early days of filetransfer, people usually sent programs to and fro, and
these programs normally included only characters in the range of ASCII
32..126. And all text formating was done on the micros. But later, people
wanted to share the text documents with others. And these texts include now
simple graphics characters, greek chars and in Europe our special
characters, the 'Umlaute'! There I thought it should be possible to specify
on the mainframe side a table (or maybe only a table-extension). And in the
original CMS version of Victor Lee I found this table and implemented a full
ASCII table according to the character set of the IBM PC. When I tranfer
files from my MAC I have to modify this table using an external file with
SET ATOE's.
Well, these are all notes I'd like to append to this new Kermit version.
Changes have been made mainly to the Pascal source, the assembler
subroutines to be able to handle 1K packets instead of 94 chars, in the
documentation file and some little modifications in the install procedure
... so you have to get all TS2KER files !!
I hope you enjoy this new version and take profit of the increased transfer
rate of up to 200% (with long packets) !!
Fritz
[Ed. - Vielen Dank, Fritz! And sorry for the delay in installing your new
version. The TS2KER.* files have all been replaced, and the TS2DS.* files
remain the same. This TSO Kermit version is an alternative to the NIH TSO
Kermit; the two versions have different sets of features. Comparative
reviews would be appreciated. There is still at least one other TSO Kermit
program waiting in the wings, the TSO implementation of the "Portable 370
Kermit". Watch Info-Kermit for further announcements.]
------------------------------
Date: Wed 18 Feb 87 1:00:00
From: Howie Kaye <howie@cunixc.columbia.edu>
Subject: Kermit Article in Computerworld
Keywords: Computerworld
For anyone who is interested, there is an article about Kermit in
Computerworld this week (February 16), on page 43. "Kermit leaps in
popularity" is the exact title, written by Christine Gianone and Frank da
Cruz.
/Howie
[Ed. - Thanks for mentioning the article, Howie. More Kermit articles are
expected in the future.]
------------------------------
Date: 1987 Feb 9 14:48 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
Subject: Subscription to Info-Kermit Digest Via LISTSERV
Keywords: LISTSERV
Service to BITNET subscribers through the LISTSERV redistribution system
seems to be stable now, so I'm ready to do my part in relieving the load at
WISCVM by dropping my direct subscription to the Kermit Digest. With only
one exception, the issues have arrived via the BITNET redistribution no more
than a day later than via direct mail and typically within a few hours. It
might be a good idea to announce these hopeful statistics to the list as a
whole and to urge all BITNET subscribers to switch to LISTSERV membership.
John
[Ed. - Thanks to all of you who have subscribed to LISTSERV@UGA to relieve
the WISCVM load. Your help is greatly appreciated. After trying this out
and making sure it works, please be sure to drop your direct Info-Kermit
subscriptions. See message below to find out how to subscribe to LISTSERV.]
------------------------------
Date: Wed, 11 Feb 87 09:59:54 EST
From: "Alan H. Holland" <FEAHH@VTVM1>
Subject: Info-Kermit Digest Subscription
Keywords: LISTSERV
I saw the article in Info-Kermit Digest about the problem with ARPANET
congestion. I have subscribed to the Info-Kermit Digest redistribution
being done by LISTERV at UGA on BITNET. You may remove my name from the
original distribution being done at CU20B.
You may wish to advise your other BITNET subscribers of this redistribution
service. For a user on an IBM VM/CMS system on BITNET, the syntax to
subscribe to the Info-Kermit Digest redistribution would be:
TELL LISTSERV AT UGA SUB I-KERMIT user's-real-name
where user's-real-name may contain blanks and periods and does not require
any quote marks.
------------------------------
Date: Fri, 6 Feb 1987 23:49 MST
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: New Info-Modems mailing list
Keywords: Info-Modems
Announcing a new Internet mailing list INFO-MODEMS@SIMTEL20.ARPA, a
discussion group of special interest to modem users. Info-Modems is
gatewayed to/from Uucp's "comp.dcom.modems".
The mail archives on SIMTEL20 for this list are:
<ARCHIVES.MODEMS>MODEMS-ARCHIV.TXT for the current messages
<ARCHIVES.MODEMS>MODEMS.ARCHIV.ymmdd for the older messages
The files are available via ANONYMOUS FTP for those with TCP/IP access to
the Internet.
Submissions to the group should be addressed to Info-MODEMS@SIMTEL20.ARPA
and administrative requests to Info-MODEMS-Request@SIMTEL20.ARPA.
--Keith Petersen <Info-Modems-Request@SIMTEL20.ARPA>
------------------------------
Date: Thu, 29 Jan 87 11:56:16 PST
From: rag@june.cs.washington.edu (David Ragozin)
Subject: C-Kermit on ATT3B2 (Revised)
Keywords: C-Kermit, AT&T 3B2
Here is a corrected version of my earlier note in which "ckcdeb.h" was
incorrectly referenced instead of "ckcker.h". Changes marked by ! in margin.
>From rag Thu Jan 29 09:10:57 1987
>To: info-kermit@cu20b.columbia.edu
>Subject: C-Kermit on ATT3B2
>
>On my new 3b2/400 with C-FP+ floating point C compiler, the only "serious"
>problem encountered arose from the fact that <sys/types.h> defines
!"typedef unsigned char unchar". Since "ckcker.h" gives a #define unchar(a)
>MACRO, it was necessary to make the following changes:
! 1) In each module including both types.h and ckcker.h, they
> had to be included in that order.
! 2) The #define unchar(c) in ckcker.h had to be preceeded by
> #ifdef unchar
> #undef unchar
+ #endif
>Sorry I don't have access to my machine right now to check exactly which
>modules were affected.
>
>(These changes were applied to (061) version code).
>
>By the way, has anyone had success using C-Kermit on a 3B2/400 to gain
>access to a "bi-directional" port? (The 3b2 with sysV.3 at least, has
>a "uugetty" process which looks for logins on a port, but will allow
>a local user to gain access for outgoing use. The protocol for gaining
>access isn't clear to me - it seems to be connected with locking the
>port line before you try to open it. What else must be done - special open
>or ??? - is unknown to me at this time. By the way - doesn't looking to see
>if you can lock a line and actually locking it, before you try to open it
>for exclusive use make sense in general?)
------------------------------
Date: Wed, 28 Jan 87 15:04:27 EST
From: rutgers!unirot!citibank!halloran@seismo.CSS.GOV
Subject: Re: C-Kermit Compile Problems on AT&T 3BX
Keywords: C-Kermit, AT&T 3BX
I ran a make on the 4D(061) source obtained from okstate using a
3B15 under V.2.1.1 and had no errors as described. The preprocessor
apparently handled the #endif XXX without problems, nor did I have pointer
problems with the signal() calls.
I suggest he check his makefile for any funny redirection of include
directories, etc. The problem doesn't seem to be in the standard makefile
or code.
Bob Halloran, Consultant
UUCP: rutgers!unirot!halloran DDD: (201)251-7514 eve ET
CSNet/ARPA: unirot!halloran@rutgers.edu ATTmail: RHALLORAN
------------------------------
Date: Mon, 2 Feb 87 09:40:02 CST
From: Christian G. Herzog <ihnp4!laidbak!zog@ucbvax.Berkeley.EDU>
Subject: Complaints about AT&T 3BX Kermit
Keywords: AT&T 3BX Kermit
RE: Info-Kermit Digest V6 #3
In regards to the blurb on complaints when porting to ATT3Bx systems :
Starting with System V Release 3, signal() is now defined
as returning a pointer to a function returning void.
This was kind of makes sense since you couldn't use the return
value of a signal function anyway. Signal probably would have
been defined this way from day one if the 'void' data type
had existed.
Chris Herzog
ihnp4!laidbak!zog
Lachman Associates
------------------------------
Date: Mon, 9 Feb 87 14:24:24 CST
From: sun!soma.bcm.tmc.edu!rice!masscomp-request@seismo.CSS.GOV (Stan Barber)
Subject: C-Kermit 4D(061) on the Masscomp
Keywords: C-Kermit, Masscomp Kermit
I have finally taken time to check out the C-Kermit release of late last
year on the Masscomp family of computers. Here are the results of the test:
"make rtu" makes a working version except the usualy problems with the uucp
spool locking problems.
"make bsd" makes a working version if it is used in the ucb environment with
the enclosed modifications make to the ucb environment libc.a. The problem
with the spool locking remains.
I also provide a version of the acucntrl program for the masscomp that can
toggle the getty on the line and provide line locking if needed. So people
can add "-DNEWUUCP" to the CFLAGS line if they use this program.
Finally, I tested the dial command with our Hayes modems, and it doesn't
work. I have not tested why. I will try to test it out sometime.
Here is the "fix" to allow "make bsd" to work on the masscomp.
This "fix" is unsupported, but it does seem to work.
#!/bin/sh
# this program will a bug in the ucb universe libc that seems
# to remain uncorrected on the Masscomp
# even with the new release of the run-time libraries.
# You must be the superuser to use this.
ar x /.attlib/libc.a ttyname.o
ar r /.ucblib/libc.a ttyname.o
rm ttyname.o
ranlib /.ucblib/libc.a
exit 0
Stan Barber, Moderator
mod.computers.masscomp (or comp.sys.masscomp)
masscomp-request@soma.bcm.tmc.edu
------------------------------
Date: Thu, 29 Jan 87 21:48:57 est
From: Joel Seiferas <joel@rochester.arpa>
Subject: /Q in Fansi-Console
Keywords: MS-DOS Kermit, 2.29b, Fansi-quick
Jim Celoni (Celoni@Score.Stanford.EDU) solved my problem with the file
transfer screen in 2.29b for the IBM PC: ``The file transfer screen is
incompatible with Fconsole 2.0's /Q1 option. Fansi-quick really does speed
things up, so all I do is toggle it before and after the transfer. Good
thing they put /Q1 /Q0 on keystrokes... +j'' This does solve the problem.
Joel Seiferas
joel@cs.rochester.edu
------------------------------
Date: Fri, 06 Feb 87 19:56:58 EST
From: "Roger Fajman" <RAF@NIHCU>
Subject: Fansi-Console and Tallscreen
Keywords: Fansi-Console, Tallscreen
> Joel Seiferas said the file transfer screen flashed on only
> momentarily with his IBM PC w/Fansi-Console 2.0. Kermit follows DOS's
> rules for the display. I suggest he try again without Fansi-Console
> because such utilities trap video i/o and apply their own rules. Kermit,
> of course, is completely unaware of the Helpful Utility and does not
> need an ANSI interpreter. There was an earlier problem with Fansi-Console
> when Kermit displayed the Connect mode status line; Fansi-Console's author,
> Bob Smith, fixed that this summer.
The problem that I encountered with the displaying of the attributes of the
status line in MS-Kermit 2.29a was related to Tallscreen, not Fansi-Console.
Bob Smith, the author of Tallscreen, provided a fix.
The problem was that the video attributes of the status line were not
displayed correctly. The information itself was properly displayed.
The confusion probably arose because part of Tallscreen is a replacement for
ANSI.SYS. It is, however, a completely separate product from Fansi-Console,
which also replaces ANSI.SYS.
Roger
------------------------------
Date: Wed, 28 Jan 87 15:39:42 est
From: Bennett E. Todd III <ecsvax!bet@mcnc.org>
Subject: Bad Filename in MS-DOS Kermit Version 2.29
Keywords: MS-DOS Kermit
RE: Info-Kermit Digest V6 #3
>From: Ed Barton <EB%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
>Subject: Bad Filename in MS-DOS Kermit Version 2.29
>
>The IBM-PC implementation of Kermit 2.29 does not catch filenames that are
>actually device names. [...]
and a fine thing, too! I can print files from remote systems by downloading
to a file named "prn".... This is a DOS "feature", and is quite well
documented in elementary DOS tutorial materials. It's nice that this feature
(allowing access to character-special devices via names in the filename
space) isn't disabled by some well-meaning hackery. Allow the system to
behave as documented! (Note: I do NOT intend here to claim that MS-DOS is
particularly correct in its documented behavior; that is a separate issue).
If you don't like the current behavior of MS-DOS vis-a-vis filenames
matching device names, there is an undocumented DOS interrupt which can be
used to change it. It is called the AVAILDEV function, and is stacked up on
the same DOS function number as the SWITCHAR function. Specifically, to
prevent prn.dat from referring to the printer (or any other such device name
overriding) issue the following machine language instructions (the debugger
can be used to make a .COM file to run these):
mov ax,3703h
xor dl,dl
int 21h
-Bennett
------------------------------
Date: Mon, 02 Feb 87 21:58:22 EST
From: "James H. Coombs" <JAZBO@BROWNVM>
Subject: MS-DOS Kermit and Mouse Definitions
Keywords: MS-DOS Kermit, Microsoft Mouse
I am thinking about writing a Microsoft Mouse menu for use with Kermit.
Is anyone interested in sharing definitions/ideas? Thanks. --Jim
P.S. I am primarily interested in experimenting with using the mouse
when emulating a VT100 on an IBM mainframe (CMS, XEDIT, etc.), but it
might be best to concentrate on supporting such Kermit functions as
Push to DOS. One problem that I see immediately is that cursor movement
is sluggish; the speed at which one can move a mouse makes this sluggishness
obvious and problematic. Comments, suggestions?
------------------------------
Date: Mon, 9 Feb 1987 11:46:06 CST
From: Dan DeNise <KERMIT@UMRVMB>
Subject: MS-Kermit Key Definitions
Keywords: MS-DOS Kermit, Key Definitions
I just got Info-Kermit Digest V6 #4 today, and felt moved to respond to
Roger Fajman's suggestion of adding SET commands for key names. I don't
like it. It would add bulk to an already bulky program and reading and
decoding key name definitions as well as key definitions would make startup
even slower than it is now.
I think a simpler and better solution is to add a prompted version of the
SET KEY command.
set key q z
could be entered as:
set key
Press a key: q
Scan code is
Enter definition: z
and
set 5 kexit
could be entered as:
set key
Press a key: <Alt-X>
Scan code is 5
Enter Definition: kexit
This would facilitate interactive key definitions by not forcing people to do
a SHOW KEY command to find the scan code before doing each SET KEY commmand.
I also think Kermit should be able to write the current key definitions to a
file. The most appropriate form, of course, is a series of SET KEY commands,
ready to be TAKEn in MSKERMIT.INI.
Dan DeNise
C0016@UMRVMB.BITNET
------------------------------
Date: Sun 1 Feb 87 01:14:52-PST
From: Bob Larson <BLARSON@USC-ECLB.ARPA>
Subject: Prime Kermit and Kermit Sliding Windows
Keywords: Prime Kermit, Sliding Windows
I've noticed a couple of problems in prime kermit:
The character '*' is converted to the wildcard character '@' in filenames.
Since '*' is a legal character in filenames, this can cause problems. This
is why you can't use a relitive pathname such as '*>subdir>file' in a get
command from another system.
Wildcard characters '+' and '^' are not expanded unless the pathname also
contains an '@'.
The default window size is much bigger than the tipical terminal input
buffer, so windowed kermit operation may be slower than non-window unless it
is set to something reasonable. (2 or 3)
Parity is not set or unset consistantly on outgoing data. Specificly, the
parity bit is set on the quote character in the send-init packet and not in
the data packets.
I'm working on a new version, modernized (requires 20.0 or later primos)
with connect mode and several other new features. In my test version, I've
noticed that the NAK of most desired on receiving a short packet tends to
cause the same packet to be sent numerous times. (The errors were caused by
receive buffer overflow.) Delaying the NAK of the most desired (which has
already been NAKed once) until the receive buffer is empty seems to me to be
a better policy, but I havn't actually tried it.
[Ed. - Thanks! Your message was added to PRIME.BWR.]
------------------------------
Date: Wed, 04 Feb 1987 13:40 PST
From: JAJZ801@CALSTATE.BITNET
Subject: Intel MDS Kermit
Keywords: MDS Kermit
A while ago in the digest I questioned if anyone knew which Kermit version
for the intel MDS's was most current in view of closely spaced revision
dates. I have examined both versions and the MD2* files are obviously
enhanced with respect to functionality.
However, in examining them carefully, the implementation of the new
features, principally server commands (not server mode) appears to have been
done with block-copy type editing since many text strings are duplicated
even where not exactly appropriate. Moreover, the logic does not completely
support the protocol manual specifications: It will not handle long replys
and interprets any ACK reply as init information instead of display text.
This all seems rather harmless and I don't doubt that it works for the
implementor, particularly since the comments and many menus and prompts
specifically refer to a VAX as the remote host machine and may not have had
widespread testing.
I am undertaking a correction of these features and also adding support
for several low-level enhancements: binary quoting, alternate checksums,
long (and extra long) packets, repeat prefixing, and character parity. Will
probably also add xon-xoff control and server mode later. In conjunction
with this I am reorganizing the source along more functional lines and to
balance module size somewhat (many MDS's still operate on painfully slow
floppies and have 808x chips ... compiles can take a while). I notice that
several other people are working on modifications (according to the AAWAIT
file), mostly to upper level features such as TAKE, SETs, menus, which I am
not addressing. I would like to contact them for cooperative purposes but no
network addresses are listed.
If any are on the net, I would appreciate being contacted to coordinate
and merge changes.
Jeffrey Sicherman
JAJZ801@CALSTATE.BITNET
------------------------------
Date: Fri, 06 Feb 87 09:22:45 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12.BITNET>
Subject: CMS TAKE File for Mac Kermit National Characters
Keywords: CMS Kermit, Macintosh Kermit, National Characters, EBCDIC, ASCII
I told you some time ago of national characters and an emerging IBM EBCDIC
set called "table 500" to support them. I've composed an according
conversion table to be TAKEn on CMS KERMIT for use with MacKermit.
Pitifully, it's only useful in file transfer mode. I see no way in terminal
mode (on the 7171) that would not involve screen codes translation on the
Mac. By the way, there is still the problem of the "OPTION dot" key that is
nowhere to find on our national keyboards. We have : (colon) where you have
"." (dot) and our dot is the shifted key to the right of your M (which is
our ",?" (isn't that easy?)). Neither OPTION ":" nor "." (which needs the
shift key) nor others yield the interrupt. Do you have a hint? Or wouldn't
there be a more "international" choice to be chosen in a future version?
Here goes my file for anyone it can help:
[Ed. - Thanks, Andre. We've never seen a European Macintosh Keyboard. Can
anyone else offer any hints? Meanwhile, Andre's translation table has been
added to CKMKER.BWR and CMSKERM.BWR.]
------------------------------
End of Info-Kermit Digest
*************************
-------
27-Feb-87 17:39:26-EST,20339;000000000000
Mail-From: SY.CHRISTINE created at 27-Feb-87 17:38:14
Date: Fri 27 Feb 87 17:38:14-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-kermit Digest V6 #6
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12282480091.78.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Fri, 27 Feb 1987 Volume 6 : Number 6
Today's Topics:
Kermit Becomes Finalist in Fluegelman Award
MS-DOS Kermit 2.29b Test Prerelease for IBM PC, Clones, & Generic DOS
Bug in QK-Kermit TV4010 Emulation
ProDOS Apple // Kermit
An Apple// ProDOS 80-col Kermit
Differences between Unix C-Kermit and Amiga C-Kermit
Kermit over DECserver-200
SET ETOA/ATOE in CMS KERMIT
C-Kermit on SCO Xenix V
Kermit & Curses Box Function Problem?
MacKermit on a 128K Machine?
Kermit-Intel (MLINK)?
Apple 2 GS and Kermit?
C-Kermit on an AT&T 7300?
----------------------------------------------------------------------
Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Kermit Becomes Finalist in Fluegelman Award
Keywords: Fluegelman Award
Kermit has been selected as one of the 11 finalists for the First Andrew
Fluegelman Award. The award is given for "a substantial, innovative
contribution to the personal community in commercial, shareware, or public
domain software". The award was established in 1986 by PCW Communications,
Inc. to commemorate Fluegelman's contributions to the software field;
Fluegelman developed PC Talk, "the first easy-to-use and powerful
communications program for the PC". The annual award is made possible
through a fund which was established in his name after his death in July,
1985. Six reputable judges are currently evaluating Kermit software.
------------------------------
Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: MS-Kermit 2.29B for IBM PC Family Installed
Keywords: MS-Kermit
A "maintenance release" of MS-DOS Kermit for the IBM PC family and compatibles
has been installed in the Kermit distribution as the preferred PC Kermit
version, to bridge the gap between version 2.29, which has several serious bugs
(the worst two: it can't transfer files when using half duplex line turnaround
handshaking, and it has trouble with certain internal modems), and 2.30, which
will be the next major release. The interim release is dubbed 2.29B, dated 19
Feb 87, and fixes most known bugs and problems in 2.29. It is essentially the
same as the version announced in Info-Kermit V6 #2 on 20 Jan 87, but with a
couple additional bug fixes. Starting now, this will be the version that comes
on our PC Kermit distribution diskette.
The program is in KER:MSTIBM.BOO (decodable into an .EXE file using an MSBPCT
program), and the list of corrections is in KER:MSKERM.BWR. This version also
contains, in "preview form" some of the new featues planned for 2.30, including
ANSI printer control, Kermit script language, and extended-length packet
support. Description of these new features is in KER:MSR29B.UPD. Sources for
this version are not available, since they are still undergoing rapid change as
2.30 is readied for release. Profuse thanks to Prof. Joe R. Doupnik of Utah
State University for the tremendous amount of work and skill that went into
this release, and is also going into 2.30, and to the many volunteers who
helped test the various fixes and changes. Much more will be said about this
when 2.30 is released.
------------------------------
Date: 2-FEB-1987 09:02:30
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Bug in QK-Kermit TV4010 Emulation
Keywords: QK-Kermit
We have been trying to implement the QK - tv4010 version of kermit running
under MS-DOS on an IBM and an IBM clone and have run into some difficulties.
First of all there is a bug in the connect.pas source file for the tv4010
where a comment has been placed in the middle of the definition for the tab
spacing, this is easily overcome by moving the comment. Other problems have
not proved so easy to solve:
Once the file has been compiled with the relevant Turbo Graphics routines
we tried to do some graph plotting with routines from simpleplot on a VAX
under VMS4.3, we then discovered you need the file 4x6.fon on the disk, with
this we got some rather poor and sometimes unintelligable text. Our graph
plotted well enough but that was it, the emulator did not seen able to cope
with being told to leave graphics mode, the only way out I could find was to
reboot the micro !!!! and then run kermit again. Does anyone have a lead on
this problem?
Another strange problem came to light. On running one of our VAX FORTRAN
programmes which runs perfectly well on a standard terminal and under Kermit
2.29a on the micros, and which does not involve graphics we found that it
gives different results ??!!?? (No we don't believe it either!!)
I hope these comments will be of some use, and perhaps there is someone
around who has encountered and overcome them.
Yours,
Graham Barlow (GKB1@UK.AC.YORK.VAXA)
[Ed. - Thanks for the comments -- they've been kept as KER:QKMSTV.BWR.]
------------------------------
Date: Fri, 06 Feb 87 17:26 EST
From: Mark B. Johnson <CDTAXW@IRISHMVS>
Subject: ProDOS Apple // Kermit
Keywords: ProDOS, Apple II Kermit
In response to Mark Crimmins' query in Info-Kermit Vol 6, #04, there does
exist a very nice 80-column, interrupt-driven, ProDOS version of Kermit for
the Apple II series. Ted Medin has done a great job with the Stevens
version and is currently up to V3.73 which works well in 80-column mode and
with ProDOS. It runs as a shell program so it must be used with
BASIC.SYSTEM, and currently it has to be installed (originally) under DOS
3.3. It supports both DOS 3.3 and ProDOS and works with several serial
interfaces.
I am currently working on a version specific to ProDOS 16 and the IIGS, and
I hope when finished to pare it back for ProDOS 8 with mouse support on the
rest of the II line. Check the file AAWAIT on KERMSRV for more details on
all the Apple II Kermits.
Mark
[Ed. - Because of some uncertainty about who's doing what to which version,
Ted's Kermit hasn't been installed in the Columbia Kermit distribution yet.
See below.]
------------------------------
Date: Tue 10 Feb 87 13:41:08-PST
From: Mark Crimmins <CRIMMINS@CSLI.Stanford.EDU>
Subject: An Apple// ProDOS 80-col Kermit
Keywords: Apple II Kermit
My query in a previous Digest was rewarded: Ted Medin replies,
>From: Ted Medin <MEDIN@NOSC-SHARK.ARPA>
>To: crimmins@csli.stanford.edu
>Subject: kermit
>Message-ID: <M1987$000847.MEDIN-T.MEDIN@NOSC-SHARK.ARPA>
>
> We have been running 80 cols for a couple of years and prodos for
>a year or so. Ftp to nosc-shark.arpa as anonymous then:
>
> cd ker*mit. - dont forget the .
> hash - so you can see the bytes fly (or crawl)
> get readme - read this for instructions
> dir - you will need this after reading
>
> Ted
The program works great. It's a shell to BASIC.SYSTEM, has all the usual
functions, and even a limited server mode. For some reason I haven't
tracked down yet, though, a program run after leaving this kermit, but
without rebooting ProDOS, will often crash (this makes it not so good a
thing to run from a /ram disk, etc.).
I also received several promising messages of fancy Apple Kermits in the
works for the IIGS, and for II's with mouse-interfaces, etc. Can't wait.
Mark
------------------------------
From: rutgers!lll-lcc!cae780!videovax.TEK.COM!stever@columbia.edu
Date: Fri, 20 Feb 87 08:52:39 PST
Subject: Differences between Unix C-Kermit and Amiga C-Kermit
Keywords: C-Kermit, Amiga Kermit
A few months ago, I received copies of C-Kermit 4D(060) for both our
VAX and my Amiga. Since I am by nature curious, I diff-ed the files
that both had in common. I found some interesting things (e.g., in
the Unix source for ckwart.c, there was a missing parameter in an
"fprintf" statement), some changes one would expect (e.g., a bunch
of added "#if[n]def AMIGA . . . #endif" constructs), and lots of
seemingly unnecessary changes.
In a number of the Amiga ckc* and cku* files, form feeds (^L) were
substituted for the blank lines or "/*Form Feed*/" comments that were
present in the Unix version. When one diffs the two versions of
ckucmd.c, ckuusr.c, ckuus2.c, and ckuus3.c, reams of output showing
the spacing changes obscure the real differences between the two files.
In these same files, the Amiga versions have "printf" substituted for
each occurrence of "printf2" and "printf3". The following usage counts
were obtained with grep:
Amiga Unix
----- ----
/ printf 52 13
ckucmd.c { printf2 0 33
\ printf3 0 7
/ printf 104 63
ckuusr.c { printf2 0 31
\ printf3 0 14
/ printf 7 1
ckuus2.c { printf2 0 4
\ printf3 0 2
/ printf 36 31
ckuus3.c { printf2 0 4
\ printf3 0 1
It is my understanding that the intent is that C-Kermit be compilable on
any compiler (no matter how old), even if it does not support variable
numbers of arguments. Thus, the Amiga versions of these files are not
compatible with the generally-distributed C-Kermit sources. I do not
understand why these changes were made, as they serve only to relieve
the C preprocessor of an insignificant burden. (I would hope that all
the compilers available for the Amiga can handle a "#define printf2
printf"!)
Not only do these changes make the supposedly "common" parts of the
Amiga C-Kermit source unique, they also cause diff to produce reams of
output, obscuring the true nature of the differences between the Amiga
sources and the Unix sources.
An even more serious consideration to Amiga owners (myself included), is
the risk of becoming cut off from the mainstream of C-Kermit development.
Recently (Info-Kermit Digest, Vol. 6 No. 1), Gordon Scott reported a bug
that seems to reside in ckcfns.c. Since this file was not modified
significantly by the Amiga C-Kermit developers, a fix could be installed
simply by recompiling with the updated file. However, if a bug is found
in ckucmd.c or ckuus[r23].c, we would have to depend on the people who
did the port to the Amiga to update the source files, or hand-install
the changes from the diffs.
I realize that C-Kermit propagates primarily by volunteer labor, and that
those who keep it all together at Columbia have relatively little control
over the individual implementations. I would hope, though, that gentle
persuasion will be applied to those who charge down unmarked paths, thus
increasing the entropy of C-Kermit.
I would be happy to write a letter containing these thoughts to the
developers of the Amiga version of C-Kermit. However, I do not wish to
hassle them if my understanding is incorrect. Please let me know what
the situation is with regard to the Amiga version, and if you think a
letter to the Software Distillery would help.
Steve Rice
{decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
[Ed. - You will find most of your complaints are addressed in 4D(061), released
in September 86 -- one of its main purposes was to replace the Amiga support,
putting the rest of C-Kermit more or less back the way it was.]
------------------------------
Date: 27 Jan 87 07:11 +0100
From: W._Michael_Terenyi%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject: Kermit over DECserver-200
Keywords: DECserver-200
Re: Info-Kermit Digest V6 #1
We use Kermit over our DECserver-200's without any problems.
Our configuration is:
VAX8300-DEBNT(BI Ethernet Interface)-DECserver-200/MC(with modem control)-
Sytek LocalNet-20 (Broadband LAN)-any PC (AT, XT, HP150, Apple). The ports
on the DECservers are configured for a dedicated service to our VAX, i.e.
the DECserver is invisible for the user who seems to be connected to the VAX
directly. We have a speed of 9600 baud and XON/XOFF flow control (as opposed
to Greg Elder's opinion mentioned in Kermit Info Digest V6 #1).
Best regards, Michael.
Real Name: Wolfgang Michael Terenyi
MAILNET: W._Michael_Terenyi_(SANDOZ)@QZCOM.MAILNET
ARPANET: W._Michael_Terenyi_(SANDOZ)%QZCOM.MAILNET@MIT-MULTICS.ARPA
JANET: W._Michael_Terenyi_(SANDOZ)%QZCOM@UK.AC.YORK.KL
BITNET: P1117@QZCOM
CompuServe: 76067,1434
Telephone: +43 222 867511-616
G3 Fax: +43 222 867018
Telex: 132287 sfi a
Real Address: SANDOZ Research Institute
Brunner Str. 59
A-1235 Vienna
Austria, Europe
------------------------------
Date: Mon, 23 Feb 87 14:35:23 SA
From: "Kai U. Leppamaki" <LK-KLE@FINHUT>
Subject: SET ETOA/ATOE in CMS KERMIT
Keywords: VM/CMS Kermit
Andre Pirard (and others, including myself) have made alternative translation
tables to be used with CMS KERMIT. The problem is, however, that modifications
introduced simply by SET ETOA/ATOE commands only work on IBM 7171 (or similar)
protocol converter lines where file transfer is based on "transparent" mode
operation (i.e. no EBCDIC<->ASCII conversion done by the operating system).
On half duplex "dumb" tty-lines (3705 or the like) the ETOA & ATOE tables
must not modified. They must match the system tables in order to have KERMIT
working at all !
However, I have modified CMS KERMIT 3.1 to include additional translation
tables. They only affect transmitted data within KERMIT but not the way
packets are coded/decoded. The user may freely modify these new tables but
not the original tables which still must remain intact.
I trust Andre's translation tables are fully compatible with my modifications
although not applicable here in Finland - different tables must be developped
for each language and/or national convention. I have composed Finnish tables
for the Mac and IBM PC character sets.
Kai U. Leppamaki
TeKoLa (= Helsinki University of Technology, Computing Centre)
Espoo, Finland
Acknowledge-To: <LK-KLE@FINHUT>
------------------------------
Date: Tue, 10 Feb 87 08:24:53 est
From: jl42#@andrew.cmu.edu (Jay Mathew Libove)
Subject: C-Kermit on SCO Xenix V
Keywords: C-Kermit, SCO Xenix V
I am attempting to use C-Kermit (dated April 1986, from CMCCTE::PK:<KERMIT>)
on an IBM PC/AT compatible (as yet, no compatibility problems- been running
for over a year) configured with two serial ports, com1: and com2: with a
modem attached to com1. I can use the modem fine from DOS, but under the
S.C.O. Xenix System V version 2.1.3 that I have just installed I can not
convince CKermit to talk to the modem. The XENIX system has allowed calls to
come in, and indicates that it should work with communication software (it
has uucp utilities that I am clueless about) so I think it must just be an
idiosyncrasy that I don't know how to deal with between CKermit and my
machine.
If anyone has information about getting CKermit to run on an SCO XENIX V
operating system on an AT, please help!
Thanks in advance-
Jay Libove
jl42@andrew.cmu.edu
jl42@cmuccvma.bitnet
------------------------------
Date: Friday, 6 February 1987 16:52-MST
From: nosc!humu!uhmanoa!uhccux!todd@SDCSVAX.UCSD.EDU (The Perplexed Wiz)
Subject: Kermit & Curses Box Function Problem?
Keywords: MS-Kermit, Curses Box Function, Terminal Emulation
Does anyone have a fix for the Kermit H19 and VT102 emulation modes? I've
noticed that at least one curses function does not work correctly with
Kermit: box. I am fairly sure of this because I switched to the Mark of the
Unicorn PC/InterComm VT100 emulator to make sure it was not some PC
flakiness causing the problem. The curses functions worked fine using the
PC/InterComm emulator.
Given the following conditions:
Ultrix 1.2 (sort of 4.2bsd) on a VAX 8650
set term=vt100
Kermit 2.29 on any kind of PC, AT, or clone
CGA or EGA display
C program using curses' box function
The symptoms are:
Only the top and right edges are displayed
move'd alphanumerics sometimes appear and sometimes don't
after a refresh() call.
Thanks....todd
Todd Ogasawara, U. of Hawaii Computing Center
UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!todd
ARPA: uhccux!todd@nosc.ARPA
INTERNET: todd@UHCC.HAWAII.EDU
------------------------------
Date: Sun, 15 Feb 87 11:58 EST
From: Mark B. Johnson <CDTAXW%IRISHMVS.BITNET@wiscvm.wisc.edu>
Subject: MacKermit on a 128K Machine?
Keywords: Mac Kermit
Is anyone successfully using MacKermit V0.8(34) on a 128K machine? I am sure
we had done it here sometime back, but I have tried it recently with several
different versions of the Finder and System and keep getting system crashes
when trying to Send files. We are sure it is the System and Finder, and are
wondering if anyone who might be doing it successfully could send us their
configuration. Thanks again.
------------------------------
Date: Thu 29 Jan 87 08:53:33-CST
From: David M. Gracia <DGRACIA@STL-HOST1.ARPA>
Subject: Kermit-Intel (MLINK)?
Keywords: MLINK, Wyse PC
Does anyone have any experience running Kermit on a Wyse pc talking to
Kermit under MLINK on an Intel 310 If so, I need to know your secret. I am
not having any luck getting it to run. Thanks.
Dave
------------------------------
Date: Wed 25 Feb 87 17:36:33-GMT
From: Alan Greig <CCD-ARG%dundee-tech.ac.uk@Cs.Ucl.AC.UK>
Subject: Apple 2 GS and Kermit?
Keywords: Apple II Kermit, GS
Has anyone tried apple kermit on the GS ? I have had a query from someone I
sent a kermit disc saying that they can't get it to run on the GS. Well I
don't have a GS...
It seems they are using DOS 3.3 and the Super Serial Card. I thought the GS
had a built in serial port which emulated a slot card. If so what happens
when u plug in another card ? Kermit runs and goes into connect mode but
neither seems to receive or transmit although the escape sequence does
return to kermit command level. I've pointed out all the usual pitfalls with
Apple kermit such as serial chip not initialised but it doesn't seem to
help.
Any pointers from anyone using the GS and/or SSC card with kermit welcome.
Alan Greig
Computer Centre
Dundee College of Technology
Janet: Alan@UK.AC.DCT (Alan%DCT@UK.AC.DUNDEE)
Arpa: Alan%UK.AC.DCT@CS.UCL.AC.UK
[Ed. - See message above about the Apple II GS.]
------------------------------
Date: Thu, 26 Feb 87 12:28:40 PST
From: zz1ml%sdcc3@sdcsvax.ucsd.edu (Michael Laver)
Subject: C-Kermit on an AT&T 7300?
Keywords: C-Kermit, AT&T 7300
Has anyone had any luck creating a C-Kermit for the AT&T 7300 (the "Unix
PC"). Both "make sys3" and "make sys3nid" leave me with the error message
Stop. Don't know how to make chcdeb.h
I downloaded the shar files to an IBM PC, read them into the 7300, and
converted the case of the filenames.
Any help would be appreciated.
--Mick Laver
laver@sdcc3.ucsd.edu
------------------------------
End of Info-Kermit Digest
*************************
-------
10-Mar-87 13:02:24-EST,25737;000000000000
Mail-From: SY.CHRISTINE created at 10-Mar-87 13:01:20
Date: Tue 10 Mar 87 13:01:20-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #7
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12285313268.189.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Tue, 10 Mar 1987 Volume 6 : Number 7
Today's Topics:
New iRMX Kermit
Announcing Kermit for Computervision
Announcing Kermit for the TI Explorer
Announcing New FLEX Kermit for the Motorola 6809
Announcing 2 New Apollo Kermit Versions
Announcing Updated C86PRO.A86
CDC Cyber Kermit Version 3 Available Running NOS
Cyber Kermit V3 vs. THE OTHERS
Announcing a new Concurrent/Perkin-Elmer/Interdata 3200 Kermit
Long packets
Problems With VAX/VMS Kermit
VMS Kermit Bug
Occasional loss of trailing newline.
C-Kermit on an AT&T 7300?
Re: SET ETOA/ATOE in CMS KERMIT
----------------------------------------------------------------------
Date: January 23, 1987
From: Robert L. Stanis, Grinnel College, IA
Subject: New iRMX Kermit
Keywords: iRMX, Intel
Here is version 2.41 of iRMX Kermit. With version 2.41, all I/O routines
have been written using system calls so both the 534 and 544 communications
boards should work without problems. Any other communication boards should
work too, but this has not been tested here. This version is an update of
the PL/M version. The current author is still Albert Goodman.
Version 2.42 was updated for the iRMX-286 operating system at the University
of Illinois. We had previously sent them version 2.41, which runs on
8086-based machines. It may make the most sense to refer to these as
separate implementations of Kermit since they are not compatible across CPU
boards/operating systems, even though the sources are similar.
Bob Stanis
Grinnell College
Noyce Computer Center
Grinnell ,Iowa 50112
[Ed. - Since it's not really clear from this letter what we have, this new
version is being installed as KER:IRMX.*, and the old version will remain as
KER:I86KER.*. If indeed these two versions are redundant, would some kind
Intel iRMX system user please let us know?]
------------------------------
Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for Computervision
Keywords: Computervision Kermit
This is version 1.21 of Computervision Kermit, written in Fortran S,
submitted by Val Jawks, 435 CPB, Bringham Young University, Provo, Utah
84602. This version was converted from John Lee of RCA Lab's HP1000 Kermit.
The files are in KER:CVKER.*. There are two files; source and help.
------------------------------
Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for the TI Explorer
Keywords: TI Explorer Kermit, Lisp
This is Release 1.0 of TI Explorer Kermit, written in Common Lisp,
contributed by Brian Carb and Steve Ford of UNISYS Corporation, PO Box 500,
Bluebell, PA 19424. This implementation was developed as a joint effort
between Sperry Corporation and Texas Instruments Incorporated. You should
be using Sperry Release 2.1.1 or TI Release 2.1 of Explorer software. When
Release 3.0 is available, this software will probably no longer work, and an
updated version will be distributed by Sperry and TI. This implementation
has been successfully tested in conjunction with Kermit implementations for
Sperry 1100, DEC Vax, DEC 2060, and Sperry and IBM PCs (KERMIT-MS).
The TI Explorer Kermit files have been renamed and are in KER:EXPLRE.*.
Files are separated by *** FILENAME ***, and are available via FTP at CU20B
(login as user ANONYMOUS, any password) and via KERMSRV on BITNET (SMSG RSCS
MSG CUVMA KERMSRV HELP).
------------------------------
Date: Wed 11 Feb 87 11:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing New FLEX Kermit for the Motorola 6809
Keywords: FLEX Kermit, 6809, Motorola 6809
This is to announce a new version of FLEX Kermit for the Motorola 6809,
written in July 1986, by Jur van der Burg, Nettelhorst 56, 2402 LS Alphen
aan den Rijn, The Netherlands. This is version 3.0, written in C (Compiled
with Introl (c) compiler)
Kermit for FLEX has its roots in the (old) UNIX version. It is enhanced in
several ways, such as data logging, server mode etc.
It should run on about any version of the FLEX-09 (tm) or SK*DOS (tm)
operating system. It requires 48K of memory. Hardware dependent things are
kept in the files FLK.H and FLIO.C .
FLEX-09 KERMIT has most of the features specified in the KERMIT Protocol
Manual.
[Ed. - The new files can be found in KER:FL2KER.*. The old files remain in
KER:FLXKER.*.]
------------------------------
Date: Wed 11 Feb 87 11:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing 2 New Apollo Kermit Versions
Keywords: Apollo Kermit
This is to announce a new version of Apollo Kermit developed by Control Data
Corporation (Apollo version 2.8) and another new version (Apollo version
2.7) which came in about the same time from Gordon Sands of Marconi Space
Systems. If anyone is interested in putting ALL of these new features into
one Kermit program, please let us know. Until then, please test the new
versions.
The version (2.8) developed by Control Data Corporation implements the
protocol as outlined in the Kermit Protocol Manual, Fifth Edition. The
Kermit version is the Pascal one that Beckman Instruments obtained from
Columbia and fixed some bugs. It will now handle binary files properly.
This implementation of Kermit is designed to run as a "remote" Kermit and
therefore does not implement any of the "local" Kermit commands. Apollo
Kermit 2.8 is particularly suited for running in 'server' mode and
implements QBIN partially. 8-bit quoting is always done in this version; it
is not optional. See the Kermit protocol description where is describes the
use of 'N' and 'Y' in the QBIN field of the initialization packet.
[Ed. - The new files have replaced the older ones as KER:APOLLO.*.
KER:APOLLO.ANN is this file. KER:APOLLO.HLP contains documentation for
running KERMIT on the Apollo and communicating with an IBM-PC. There are
three source files for KERMIT on the Apollo. The source files are
KERMITB.PAS, KERMITIO.PAS, and EXISTF.C. The files are separated by:
/*----- end of file ----- */ and stored as KER:APOLLO.PAS.]
The version (2.7) from Gordon Sands of the Technical Computing Dept.,
Marconi Space Systems has added several facilities to the Apollo (Pascal)
version of Kermit. In particular, the new version can drive a screen without
Graphics Primitives. Gordon developed this to enable a user on one node to
drive an RS232 port on another, but it should also be usable on an attached
terminal (Trevor Wright's query in NEWS01V2).
The main other facilities are:
repeat count processing,
filename hashing,
RECEIVE followed by filename,
more error etc. messages to the screen and
SET TIME and TIMEOUT.
SET parameters GRAPHICS and NORMAL control whether graphics are used to
drive the screen and whether filenames are normalised.
There are further details in a revised .HLP file and in comments at
the start of the source file.
[Ed. - These files have been put in KER:AP2KER.*. Now there are 2 Apollo
versions -- APOLLO.* and AP2KER.*. The old Apollo Kermit is now in
KO:APOLLO.*]
------------------------------
Date: 16-FEB-1987 13:58:40
From: SYSKERMIT%vax1.central.lancaster.ac.uk@CS.UCL.AC.UK
Subject: Announcing Updated C86PRO.A86
Keywords: C86 Kermit
This is to announce an update to C86PRO.A86, by Chris Lock of Nottingham
University. It makes the C86 Kermit resilient to packets being echoed back
to it. Chris did it orginally for a specific implementation talking to a
specific wierd British mainframe, but this part of his code should be of
general use in all the C86 implementations.
Alan
[Ed. - Thanks! The new files have replaced the old ones in KER:C86PRO.*.
This is protocol module for CP/M-86 Kermit. If anyone wants to rebuild
the program for a particular system, this source can now be used.]
------------------------------
Date: Mon 16 Feb 87 18:18:05-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: CDC Cyber Kermit Version 3 Available Running NOS
Keywords: Cyber Kermit, CDC Kermit, CDC Cyber Kermit
A new version of Kermit is available for CDC Cybers running NOS. This
version (3.0) was developed by Steve Roseman, Lead Systems Programmer,
Lehigh University Computer Center (LUSGR@LEHICDC1.BITNET). It is derived
from the U of Texas Fortran 5 Kermit, with NOS/BE and UT2D support removed.
It contains the following new features and changes:
. Wildcard file names on the SEND command and server GET command.
. Local and permanent file SEND and server GET.
. A DIRECTORY command and server REMOTE DIRECTORY command.
. Automatic recognition of DISPLAY CODE, 6/12 ASCII, and 8/12 ASCII file
text modes on SEND. Receives 6/12 ASCII by default.
. The SET FILE-MODE command allows BINARY and TEXT file types.
. Supports repeated character compression (if the micro Kermit allows).
. Supports long file transfer packets up to 1000 characters (if the
micro Kermit allows).
. Cyber Kermit no longer affects the parity of your terminal connection.
[Ed. - The files have been named to KER:CD3KERM.*. The KER:CYBKER.* files
still remain in the KERMIT-2 directory as well, and the old version that
supports NOS/BE is in KERMIT-3. And... we expect yet another version to
arrive someday that will support NOS/VE. See message below for a comparison
of the various Cyber versions.]
------------------------------
Date: 23 FEB 1987 13:32 EST
From: Steve Roseman <LUSGR@LEHICDC1.BITNET>
Subject: Cyber Kermit V3 vs. THE OTHERS
Keywords: Cyber Kermit
Below is a comparison between the 3 Cyber Kermit versions:
CDC KERMIT V2 vs V3:
V2 advantages: Provides NOS/BE and UT2D support; removed in V3.
Slightly smaller memory requirements.
V3 advantages: More features, including long packets, wildcard file names,
repeat prefixing, DIR command and REM DIR server command,
editable HELP file.
CYBER (MANCHESTER) vs. V3:
Manchester Advantages: Much smaller memory requirements (importance reduced
by non-swap code and longer packets).
Faster (less CPU usage).
Probably slightly faster transfer rate with standard
length packets.
Some users think it is the 'greatest Kermit since
sliced bread'.
V3 advantages: See above.
Readable/maintainable code.
63 character set NOS site support (not very important).
If it was my choice, I would keep the CDC Kermit V2 for the remaining
NOS/BE sites. We can't abandon them. I would abandon the Manchester
version. It's a small, fast version, but the unreadable code and, now,
comparative lack of features, make it less desirable. Or keep it around, it
doesn't take too much food. It's up to you.
Steve Roseman
------------------------------
Date: Mon 16 Feb 87 18:18:05-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing a new Concurrent/Perkin-Elmer/Interdata 3200 Kermit
Keywords: Concurrent Kermit, Perkin-Elmer Kermit, Interdata 3200 Kermit
This is to announce a new Kermit version (1.0) configured for
Concurrent/Perkin-Elmer/Interdata 3200 series Super-Minicomputers running
OS/32, by Creighton J. Miller, Department of Speech, Theatre, and
Communication Disorders, Louisiana State University, Baton Rouge, LA.
According to Creighton J. Miller:
This program has been developed and installed on a Perkin-Elmer 3210 system
with 1 Mbyte of memory, under OS32MT72, Revision 0. All program code except
for the I/O modules, has been written in "primitive" FORTRAN which should
prove to be highly portable (even to other machines) compact and fast. All
I/O utilizes system-level versatility through run-time access to PE's SVC1
I/O handler, whose operations could be easily duplicated on most other
mini's in a single added subroutine (image mode read-/write-and-proceed
calls and echoless reads).
In developing this program, much reference has been made to code from
Kermit-PE 2.0, developed by Paul Mamelka and currently available from either
Columbia University or PE-Interchange: The primary reasons for developing
PE-Kermit being a desire to enhance program size/speed/portability issues
and to incorporate binary file transfers (eventually raw transfers as
well...), plus a few added "bells and whistles" I'd had in mind.
Although no warranty of the routine is either expressed or implied, feel
free to use/distribute/alter the code at will --- so long as it is put to no
explicitly commercial applications: I think you'll be impressed by this
Kermit's relatively gentle and forgiving nature. I would be happy to
exchange information, comments or just pleasantries with those of you who
find some use for the logic.
A complete set of installation/development/message files is included
with the code, as an aid to fellow-travelers on the road to intersystem
communications. They'll work as-is on a properly prepared 3200 series PE
system; properly prepared meaning in this case, OS32MT72.0 or higher OS and
BIOC with an enabled, 80 byte (minimum) typeahead cue, plus the sysgened
MASK=X'FF' option. Please note that the interactive message file,
KERMIT.HLP, is an IN-dexed file with an 80 character record length, and
holds binary information. Each line is structured as follows;
1. BYTES 00-03 => length in bytes (binary) of the
message line which follows
2. BYTES 04-[length+4] => message line, in image
form.
Program size ranges from 22k bytes, using FORT7-O, through 25k bytes,
using FORT6 (you'll need assembly access to OS/32 7.2.0's SVC1, like that
included in SYS7IO.FTN), to about 38k bytes, using FORT7-D. You will
discover SIGNIFICANTLY enhanced response times for the program with the
optimizing compilers.
Transfers have been accomplished between both a PE-3210 and a PE-8/32
(as Hosts) and Zenith Z-148 (4.7 and 8 meg clocking), IBM XT, IBM AT and
Kaypro 2000 Pc's, at baud rates ranging from 300 through 9600, over
dedicated and modem links. These have been used for both ASCII and BINARY
data, with full-sized packets (94 bytes). MS-Kermit 2.26 was the usual
Caller routine, but MS-Kermit 2.28, and Procomm 2.1 and 2.3 have also been
used (Procomm 2.1 has quirks which effectively prevent binary transfers).
[Ed. - These files are in KER:PE2KER.*. The old files are still in
KER:PERKIN.*; if anyone can demonstrate why we should keep the old version,
or can say definitively that this new one can replace it, please let us
know. Our Kermit tapes runneth over...]
------------------------------
Date: 1987 Feb 20 09:38 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
Subject: Long packets
Keywords: Protocol Extensions
One of the concerns in sending long packets is that the communication link
may suddenly change in such a way that the agreed-upon packet size becomes
unsendable. Since checkpointing the I/O on the source file may be awkward
or impossible, the recommended procedure of error recovery by resending only
about half of the failed packet requires a method for cutting the packet
buffer without separating a prefix byte from its suffix. I offer the
following algorithm for finding a suitable cutting point. Assume here that
'#', '&', and '~' are the Control, 8th-bit, and Repeat quote characters and
that M is the desired index into the packet buffer BUF. I use 'ne' for the
Not-equal operator.
1. N = M
2. Go to 5
3. N = N - 1
4. N = N - 1
5. If BUF(N) = '#' then go to 4
6. If BUF(N) = '~' and BUF(N+2) ne '~' then go to 3
7. If N > M - 5 or BUF(N+1) ne '#' or BUF(N+2) ne '#' then go to 10
8. N = N + 2
9. Go to 7
10. N = N + 1
11. If BUF(N) = '#' then return (N+2)
12. If BUF(N) = '~' then return (N)
13. If BUF(N) = '&' then go to 10
14. Return (N+1)
Note that if 8th-bit or Repeat prefixing is turned off, the tests in step 13
or in 6 and 12 would fall through. Also note that steps 7-9 take care of
multiple quoted-control-quotes (if Repeat prefixing is off), but that the
repeat count threshhold will have to be set at 4 (at least for characters
that do not require any other prefixing) in order to avoid another possible
run-back in steps 3-6.
John
------------------------------
Date: Tue, 24 Feb 87 16:30:32 CST
From: "Jeff Balvanz" <GR.JLB%ISUMVS.BITNET@wiscvm.wisc.edu>
Subject: Problems With VAX/VMS Kermit
Keywords: VAX/VMS Kermit
We have been having some problems with VAX/VMS Kermit here at ISU and I'm
wondering if anyone can offer some advice. Here are some of the problems:
1. When uploading to VAX from MS-Kermit 2.29 (Zenith Z-158) using an
eight-bit communications line, SET PARITY NONE on both ends usually results
in 16 retries and no packets sent. Setting parity to EVEN on both ends
causes a file to be uploaded, but often with repeated characters in the file
(as in "This is a miiiiiiiiiiiiiiiiistake.") making the upload unusable.
However, setting the parity back to NONE on both sides after an unsuccessful
upload at EVEN sometimes results in a successful transfer. It drives us
nuts because sometimes no parity works just fine, and some files will
transfer successfully with EVEN parity. The files that give repeating
characters are normal text files, and it is (to me, anyway) impossible to
determine any difference between the files that work and those that don't.
However, a file that doesn't work once usually will repeat the behavior.
2. Downloading files with FORTRAN carriage control to MS-Kermit 2.29 (or, I
suspect, any other local Kermit) results in the message "Illegal file type"
from VMS Kermit. APPENDing the file to a normal file created with the
CREATE command causes it to download just fine. According to the source
code this was supposed to be fixed in VMS Kermit v 3.2.
We are running VMS version 4.5 and VMS Kermit version 3.2.076, just
assembled from MACRO source gotten from Columbia over BITNET since the VMS
upgrade. Any suggestions? I'd be happy to correspond with someone over
BITNET if it will help.
Jeff Balvanz
Manager, Microcomputer Services
Iowa State University Computation Center
GR.JLB@ISUMVS.BITNET
------------------------------
Date: 19-FEB-1987 13:34:51
From: PG_HARE@UK.AC.OPEN.ACS.VAXA
Subject: VMS Kermit Bug
Keywords: VAX/VMS Kermit
Help!
Kermit 3.2.077 keeps crashing out when I use it. I eventually tracked down
the problem to be tied up with the length of the filename involved; rather
than there being something wrong with the file itself.
If the filename is 'too long' Kermit crashes out with an access violation.
This is demonstrated by the two examples below. In the first, I have used a
short-cut to specify the file I want to send, in the second the full file
specification is given.
Paul Hare
PS. This problem is critical where we are concerned since the file transfers
that are causing Kermit to crash are under the control of a third-party
application package; so nothing can be done to avoid long file names.
[Ed. - Thanks for the report. We've sent it to the VMS Kermit authors.]
------------------------------
Date: Mon, 19 Jan 87 09:50:36 PST
From: rutgers!lll-lcc!cae780!videovax.TEK.COM!stever@columbia.edu
Subject: Occasional loss of trailing newline.
Keywords: C-Kermit, VAX Kermit
I have run into an occasional problem with C-Kermit dropping the last
character in a file. This was first observed in old versions of C-Kermit
running on our VAX (a "beta release" from sometime in the Spring of 1985)
and on my Amiga (an early hack of unknown pedigree). I had hoped this
problem would go away with version 4D(060), which we are now running on the
VAX and I am using on my Amiga. Unfortunately, the problem still exists.
In Info-Kermit Digest V6 #1, Gordon Scott reported discovery of a bug
that may be related (I don't know how newlines are transmitted).
The description Gordon gives is consistent with the apparently random
nature of the problem I encounter, although my transfers are in text mode.
An occasional file will lose the trailing newline. If the newline is
appended and the file transmitted again, the newline is again lost.
However, not all trailing newlines are lost. Most files are transmitted
without problems.
[Ed. - Thanks, we'll take a look at all the evidence you've gathered, and
hope we'll home in on the problem & fix it.]
------------------------------
Date: Thu, 26 Feb 87 12:28:40 PST
From: zz1ml%sdcc3@sdcsvax.ucsd.edu (Michael Laver)
Subject: C-Kermit on an AT&T 7300?
Keywords: C-Kermit, AT&T 7300
Has anyone had any luck creating a C-Kermit for the AT&T 7300 (the "Unix
PC"). Both "make sys3" and "make sys3nid" leave me with the error message
Stop. Don't know how to make chcdeb.h
I downloaded the shar files to an IBM PC, read them into the 7300, and
converted the case of the filenames.
Any help would be appreciated.
--Mick Laver
laver@sdcc3.ucsd.edu
[Ed. - The real name of the file is ckcdeb.h, not chcdeb.h -- could that
be the problem???]
------------------------------
Date: 1987 Mar 2 13:17 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
Subject: Re: SET ETOA/ATOE in CMS KERMIT
Keywords: CMS Kermit
The proposal of having more than two ASCII/EBCDIC tables is not a new
one. The following diagram shows the various translations a file must
undergo in sending and receiving and why Kermit could logically maintain
four tables instead of two in an IBM mainframe environment.
* *
File ---> Buffer ---> Packet ---> Buffer ---> TTY (Sending)
ETOA ENCODE ATOE sys
1 2 3
* *
TTY ---> Buffer ---> Packet ---> Buffer ---> File (Receiving)
sys ETOA DECODE ATOE
4 5 6
Nonetheless, only two tables should suffice in practice, given the
following assumptions:
1. System tables 3 and 4 are invertible for all codes of interest,
2. tables 3 and 4 are mutual inverses for all ASCII codes 32-126 plus
at least two different control characters (such as SOH and CR), and
3. the media marked with asterisks (*) above have only 7-bit data.
Bear in mind that the original reason for allowing the user to modify
Kermit's translation tables was to adapt to operating systems with
peculiar tables 3 or 4, not to permit extended 8-bit ASCII fonts. In
any case, tables 2 and 5 must be the inverses of 3 and 4, respectively,
but, since Kermit uses 7-bit ASCII for making packets, the second half
of table 2 is unused and, thus, might as well be the same as the second
half of table 6. As long as tables 3 and 4 are inverses, I see no reason
why the "used" half of table 2 (which equals the first half of table 4)
should not also match the first half of table 6. In other words, the
system tables should accurately reflect the local standards for
7-bit-ASCII-to-EBCDIC conversion. The same line of reasoning also leads
to the conclusion that tables 1 and 5 can be identical. Half of each
table is invariant at a given installation, being anchored in the local
definition of 7-bit-ASCII-to-EBCDIC, but the other half is free for
tailoring to any purpose -- there could be separate definitions of
8-bit-ASCII codes for different target machines. Suppose that one or
more of the above assumptions are false:
1. If table 3 (or table 4) is not invertible, then Kermit can't work.
2. If tables 3 and 4 are not inverses, then Kermit must have four
different tables after all. Are there, in fact, any installations
where this is the case? If so, why can't the tables be rationalized?
3. If an installation provides 8-bit data lines, then tables 3 and 4
are entirely filled, and tables 2 and 5 are entirely invariant, but
only if Kermit tries to use 8-bit codes in packets. Are there, in
fact, any installations where this is the case? If so, then is the
gain in efficiency from using 8-bit codes (for text) really worth the
trouble of maintaining separate translation tables?
------------------------------
End of Info-Kermit Digest
*************************
-------
26-Mar-87 18:37:56-EST,21598;000000000000
Mail-From: SY.CHRISTINE created at 26-Mar-87 18:37:03
Date: Thu 26 Mar 87 18:37:03-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #8
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12289568685.59.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Thu, 26 Mar 1987 Volume 6 : Number 8
Today's Topics:
Announcing Kermit for the Sinclair QL
Announcing Kermit for TRS-80 Model II
Announcing Kermit for Data General running RDOS
UUDECODE for BITNET
AP2 (Apple and Apollo) Kermit Name Clash
KERMSRV access
Re: Problem with VAX/VMS Kermit
Request for DTR control in VAX/VMS Kermit
Re: SET ETOA/ATOE in CMS KERMIT
More on ASCII/EBCDIC translation
TRS Model 1
C-Kermit changes needed for Zilog systems under Zeus 3.21
C-Kermit for AOS
Kermit-11 Problem Discovered and Solved
SANYO MBC555 AND KERMIT
----------------------------------------------------------------------
Date: 13-MAR-1987 11:20:54
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Announcing Kermit for the Sinclair QL
Keywords: Sinclair QL Kermit
It has come to my notice that there is a demand for Kermit on the Sinclair
QL. As I've written an automated file server to connect several QL's to a
Xenix machine that is based on the Kermit protocol, I feel I ought to let
you have what I've accomplished on the basis of providing a development
source for anyone interested in taking it further. There is a full
description of how the version developed and what it can and cannot do in
QLKERM.DOC
I would recommend users to use floppy or RAM disks due to the slow and
unreliable nature of the Microdrives. Floppy disks are an essential requirement
for any further development.
The source files have been renamed to fit the standard 6.3 convention. To
compile from source they have to be renamed as follows:
Current Name Original Name Usage
------------ ------------- -----
QLKERM.DOC QLK_DOC usage and comments
QLKERM.LNK QLK_LINK Metacomco linker control file
QLKMAIN.C QLKMAIN_C main module
QLKKER.H QLKKER_H main header file
QLKSWITC.C QLKSWITCH_C state table switcher
QLKUS1.C QLKUSR1_C top level command parser
QLKUS3.C QLKUSR3_C parameter setter
QLKUSR.H QLKUSR_H parser header file
QLKCMD.C QLKCMD_C command prompter/editor
QLKCMD.H QLKCMD_H editor header file
QLKFNS.C QLKFNS_C base level functions
Compilation also needs stdio_h, ctype_h and qdos_h as supplied with the
Metacomco 'C' development kit.
Suggestions for enhancements are:
A proper terminal emulator ( preferably VT100 ) - the need for this is
so great that I could be tempted to do this myself if only I could obtain an
example 'C' source ( for any machine ).
Rebuilding wider functionality, including the help, that I have removed
to minimise storage requirements.
Please note that I will be moving to a new job in Cambridge in mid-April, so
would like to wash my hands of QLKermit, as it were, but I would be happy to
answer any queries people may have.
Robert Coughlan,
Department of Surgery,
Liverpool University,
PO Box 147,
Liverpool L69 3BX
UK
(051) 709 - 0141 x 2670
[Ed. - Thanks for the new Kermit version. The files are in KER:QLKER.*
available using FTP to CU20B (login user ANONYMOUS - any password) and
through BITNET via KERMSRV.]
------------------------------
Date: Mon 23 Mar 87 11:26:46-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for TRS-80 Model II
Keywords: TRS-80 Kermit
A new version of TRS-80 Kermit has been developed by Serge G. Kruk, Systemes
Temps Reel, 1030 Hodge, St-Laurent, Quebec, Canada H4N 2B7 ((514) 748-0515).
This implementation of the Kermit protocol is for the Radio-Shack Model II
running under TRSDOS. This version of the Kermit protocol implements only
send and receive capabilities using the one-character checksum.
Known Bugs include:
- Command parsing and recovery is minimal.
- During a file transfer, TRSKER remains silent. Only the noisy
- disk accesses of the equipment will tell you that a transfer is
in progress. (But completion status is unambiguous...)
- TRSKER uses the TRSDOS clock interrupt services to timout an
unanswered packet but it does'nt seem to work all the time...
[Ed. - These files are in KER:TR2KER.* available through BITNET via KERMSRV
and by using FTP to connect to CU20B.]
------------------------------
Date: Mon 23 Mar 87 11:26:46-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for Data General running RDOS
Keywords: Data General Kermit, RDOS Kermit
This version is a modification for RDOS of the version of Torbjorn Alm & Per
Lindberg for the ABC-800. It was modified by Remi Castonguay. The only
file sent to Columbia was the source code, written in BASIC.
[Ed. - The BASIC code is in the file KER:RD2KER.BAS. Please report any bugs
to Info-Kermit@CU20B.]
------------------------------
Date: Fri 20 Mar 1987 11:51:19 CST
From: Mark S. Zinzow <MARKZ@UIUCVMD>
Subject: UUDECODE for BITNET
Keywords: UUDECODE, BITNET
When mail goes somewhere via bitnet there are two problems. One is that
tabs get eaten by ASCII <--> EBCDIC conversion, which is a pain for source
code text. The other is that trailing spaces are stripped off. This is nice
for cutting useless characters from mail, but uuencoded files suffer. My
enhancement is to put the spaces back. Someone has written a uuencode that
puts an extraneous character at the end of each line which also solves the
bitnet problem on the sending end.
I realize that the four if's in outdec would be better rewritten as one
for loop, but I was tired when I fixed this last night and it works close
enough.
[Ed. - Thanks! This version of UUDECODE is in KER:UUDECO.C.]
------------------------------
Date: 13-MAR-1987 11:20:54
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: AP2 (Apple and Apollo) Kermit Name Clash
Keywords: Apple Kermit, Apollo Kermit
Doubtless you've had a lot of people telling you this, but we now have two
Kermits with prefix AP2! (one is the new Apollo stuff, the other the very
old Apple native assembler version).....
Alan
[Ed. - No, Alan, you were the only one who mentioned this. Ooops... The
new version of Apollo Kermit, formally named AP2*.* is now named APL*.* in
KER:. Thanks for catching this.]
------------------------------
Date: 03/17/87 14:41:34 CET
From: UF02%DDAGSI3.BITNET@wiscvm.wisc.edu
Subject: KERMSRV access
Keywords: KERMSRV
Hello! I want to bring some information regarding KERMSRV access to your
attention.
In INFO-KERMIT V6 #7 you wrote that KERMSRV can be accessed from BITNET via
'SMSG RSCS MSG CUVMA KERMSRV HELP'. This command is only valid for VM
machines, I suppose. We have a MVS (Man Versus System) machine here where I
can only use
'SMSG KERMSRV AT CUVMA HELP'. But all I get is 'INVALID COMMAND HELP'.
The correct form to get an answer is 'TELL KERMSRV AT CUVMA HELP'. Then I'm
notified that 'KERMSRV INFO' has been sent to me and it really arrives!
I hope this information is of some use for you.
Frank Schwab
069/798-8238
Institut fuer theoretische Physik
Robert-Mayer-Str. 10
D-6000 Frankfurt/M.
[Ed. - Sorry about the confusion. The KERMSRV syntax changes with every
machine it seems. Here's what we know about so far:
VM/CMS: TELL KERMSRV AT CUVMA HELP (or SMSG RSCS MSG CUVMA KERMSRV HELP)
MVS/TSO/E: TELL KERMSRV AT CUVMA HELP (may be site dependent)
VMS JNET: SEN/REM CUVMA KERMSRV HELP
UNIX UREP: netexec cuvma msg cuvma kermsrv help
Does anyone have any additions or corrections?]
------------------------------
Date: Tue, 10-MAR-1987 19:28 PST
From: Mike Iglesias <MIGLESIAS%UCIVMSA.BITNET@wiscvm.wisc.edu>
Subject: Re: Problem with VAX/VMS Kermit
Keywords: VAX/VMS Kermit
As I remember, you can't rebuild VMS Kermit from the macro sources because
they're not all up to date (some are from 3.2.076, some from 3.2.077). You
have to take the KERMIT.HEX (not sure about the file name) file and de-hex
it using VMSDEH.MAR, also available from columbia. I reported it a long
time ago (when 3.2.077 was released), but I guess it hasn't been fixed yet.
Version 3.2.077 fixes your problem with FORTRAN carriage-control files.
I've never seen your problem with the parity settings; I always use no
parity from MS-DOS Kermit v2.28/2.29 and have never had any problems
transfering files to our VMS systems.
Mike Iglesias
University of California, Irvine
miglesias@ucivmsa.bitnet
iglesias@ics.uci.edu
[Ed. - We expect a newer release (3.2) from Stevens shortly.]
------------------------------
Date: Thu, 12 Mar 87 10:38:09 aest
From: Andrew Hunt <munnari!rpepping.oz!ANDREW@seismo.CSS.GOV>
Subject: Request for DTR control in VAX/VMS Kermit
Keywords: VAX/VMS Kermit
Would it be possible for the implementors of VMS Kermit to add modem (DTR)
control to the program. This would involve setting DTR on on the KER$COMM
line (maybe if only different from TT:) and implementing the HANGUP command
to allow it to be cleared. This would make it compatible with MS-Kermit
V2.29+ and allow easier use with modems and terminal switchers whih require
DTR to be set before they will lissen to you.
Many thanks in advance, ...Andrew HUNT, CSIRO Radiophysics, Australia.
------------------------------
Date: Tue, 03 Mar 87 09:03:10 SA
From: "Kai U. Leppamaki" <LK-KLE@FINHUT>
Subject: Re: SET ETOA/ATOE in CMS KERMIT
Keywords: VM/CMS Kermit
I trust you still have your sketch readily available so I'm using the same
ETOA/ATOE table numbers you did.
You saw no reason why the first half of table 2 (and 4) should not match the
first half of table 6. On our site they mostly do not ! On a site which
uses national (7 bit) character sets the first half of table 6 may vary from
file to file i.e. the user may have used the local national (7 bit ASCII)
character set for one file and the American convention for another. This is
very often the case when one receives text files from various parts of the
world.
Since the system table (4) can represent only one of the conventions there
is an apparent need for an independent table which can be freely modified on
the fly. On our site the system tables (for tty lines) have not been
modified and they still reflect the American convention. This is to minimize
the effort needed to maintain the tables. Most of the text files use the
Finnish national character set (ASCII or EBCDIC) but many do not.
The problem originally raises from the stupid fact that the national char
replacements are different in EBCDIC than in ASCII !! E.g. the Finnish
"umlauted" upper case "A" (two dots on top) replaces the left bracket in
ASCII whereas in EBCDIC it has stolen the place of a "#" !
This is why we cannot get along with only one translation table but need at
least two alternatives. The tables 2 & 5 must always match the system tables
3 & 4 (and never really need to be modified) whereas tables 1 & 6 must match
the character set CURRENTLY in use.
With only 8 bit "multinational" ASCII sets (with the first 128 codes
matching the American usage) your reasoning obviously holds but not if 7 bit
national variations are used !
Do you agree ?
------------------------------
Date: 1987 Mar 17 14:26 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
Subject: More on ASCII/EBCDIC translation
Keywords: ASCII/EBCDIC Translation
It seems that the European experience includes a problem I didn't
consider in my analysis of the number of distinct A/E translation tables
needed in a Kermit-370. In essence, the problem is that different
conventions for the national characters can exist for different terminals
and off-line sources of text, and the differences can affect the 7-bit
half-table for ordinary "ASCII" characters. This is similar to what
happened after the replacement of 026 keypunches with 029's (BCD with
EBCDIC). I'm afraid that a complete solution is beyond the scope of Kermit
because, in all likelihood, there are already files on disk at such sites
making use of the differing conventions. In the case of BCD vs. EBCDIC, the
FORTRAN compilers (for example) were equipped with optional automatic
translation of the input source. Sadly, the situation is more complicated
when one considers all varieties of text, but something of the sort might
still be possible. As a fallback position, though, it would be necessary to
adopt a scheme that does an extra translation, either by making a translated
copy (as in using the COPYFILE TRANS option for CMS users) or by translating
before writing on disk in the first place (as in the extra Kermit tables).
The former approach solves the problem for all time (old files using one
convention can be converted at any time), but the latter would seem to be
more efficient (at least, if used consistently). Adding such a Kermit
function would require two new SET commands. Does anyone have any ideas on
what they should be called?
John
------------------------------
Date: Mon, 16 Mar 87 21:03:01 EST
From: Charles L Oei <burdvax!thing2.PRC.Unisys.COM!oei@seismo.CSS.GOV>
Subject: TRS Model 1
Keywords: TRS Kermit
I have several remarks though that you might want to put into a .BWR file
for future users of Kermit for the TRS80 Model 1 running TRSDOS 2.3:
Of the files that are distributed, a person really only needs to see:
TRSMIT.DOC.1 and TRSMAKE.BAS.1
The others are either Z80 assembly language source code (for good latenight
reading), or miscellaneous/extraneous files that are of no real consequence.
[TRSDNLD.BAS.1 when downloaded and ran produces correct checksum, but
the resultant /CMD file doesn't seem to run correctly (at least the couple
of times I tried it -- it could otherwise, but I didn't want to invest any
more time since TRSMAKE did work satisfactorily).]
When TRSMAKE.BAS is downloaded and ran, don't worry about that it says
that the checksum is wrong, it's probably just fine. Here are the checksums
that TRSMAKE says it should be and what I get, respectively: 976487 976454
There are two problems (of any real consequence) with the resulting
KERMIT/CMD file:
1) not so bad is that vt52 emulation doesn't work
2) The other is that I couldn't talk w/ other Kermits unless I set
set the parity to "space". The Kermit on the other end doesn't
have to set its parity to space though. [After this, all
went well].
Also, some annoying things that I had with it were:
in terminal "connect" mode, I have no cursor;
the <break> key in command mode doesn't appear to "abort" a command,
but the <clear> key seems to do the trick anyway;
in "connect" mode, the <control> key designation doesn't work either.
Oh, and probably some other minor things too, but overall, it's great.
At least it works and sends/receives files better than raw transfers
sans error checking.
Thanks to Stan Barber and the original writers of CP/M 80 Kermit.
Charles Oei
[Ed. - Thanks for the report. It's now in the TRSMIT.BWR file.]
------------------------------
Date: 19-March-1987
From: J.M.Saunders, British Aerospace plc
Subject: C-Kermit changes needed for Zilog systems under Zeus 3.21
Keywords: C-Kermit, Zilog, Zeus
At present we have two Zilog 8000 systems running Zeus 3.21. Detailed below
are the changes made in order to get a working version: they are mostly to get
around apparent compiler bugs.
Kermit was built using "make sys3". We got around the setjmp and longjmp
problem by defining these to be the same as longret and setret in include
files.
The changes to C-Kermit for Zilog were contained in ckutio.c and ckufio.c
CHANGES TO CKUTIO.C:
These can be split into 3 parts: ensuring the terminal settings were read and
set correctly, getting non-canonical processing to work correctly, and making
the lockfile format compatible with that of current software.
1. Terminal settings
The ioctl call did not put the terminal settings into the termio structure, and
any modifications made were ignored. This was traced to an apparent bug in the
compiler, which was cured by changing the storage class of the termio structure
from static to the default in the variable declarations
2. Non-canonical mode
As soon as the interactive prompt appeared, Kermit returned to Unix command
level. This was traced to the terminal settings. If the wait time setting
c_cc[5] is non-zero, ^A's are sent whilst the machine is waiting. These were
being interpreted as EOF characetrs instructing Kermit to tidy up and exit.
The problem is cured by setting c_cc[5] to zero in all cases where
non-canonical mode was used (modes set in concb and conbin)
3. Lockfile
uucp on the Zilog requires the username and terminal of the person using the
remote line and not a pid number. The changes made (apart from variable
declarations) were in look4lk :
CHANGES TO CKUFIO.C:
The problem here is to do with file names being garbaged when wild card
characters were used. The name of the first file to be transferred was being
corrupted, due to corruption of the pointer to it. This had no visible
explanation and was put down to a compiler bug. The fix is in the form of a
kludge that ensured that the 0th location in the array was not used (i.e. names
are stored from element 1 onwards). Changes were made in the znext, znewn and
fgen functions as below:
OTHER BUGS:
The only other bug found was that trailing nulls are sometimes removed from
binary files in transfer.
J.M. Saunders,
Daisy CAE Support Engineer,
British Aerospace plc,
Naval and Electronic Systems Division,
Dept 399, FPC 126,
PO Box 5,
Filton, Bristol, UK BS12 7QW
[Ed. - Many thanks for the report! The code differences have been omitted from
the above, as some of them are fairly lengthy, but this entire message
including the code has been added to CKUKER.BWR (the Unix Kermit "beware"
file).]
------------------------------
Date: Wed, 11 Mar 87 16:51:33 EDT
From: LAMB@Lids.mit.edu (RHL)
Subject: C-Kermit for AOS
Keywords: C-kermit, AOS
Last I looked there seemed to be no C-kermit for the Data General AOS
operating system. So Ive hacked up a version. All functions (server, local)
seem to work fine on our machine but id like to try it on others before
making it public. Is anyone else with a DG machine willing to try C-kermit?
My machine: MV20000
Operating SYS: AOS/VS V7.53 (with MV/UX overlay unix)
C compiler: AOS C V3.21
My goal is to make C-Kermit work under AOS/VS only. Send feedback to
Lamb@lids.mit.edu
or ..ihnp4!mit-eddie!lids!lamb
Thanx , Rick Lamb
[Ed. - The same thing has also been done elsewhere, and we're expecting it
to arrive "any day now".]
------------------------------
Date: Mon, 23 Mar 87 13:00 EST
From: Lewis M. Dreblow - PSYCH at UFFSC
Subject: Kermit-11 Problem Discovered and Solved
Keywords: Kermit-11
I wish to inform the user community of a problem which occurred with the
K11 release of Kermit. I was trying to use kermit on a 11/23 running RTV5
and TSXV5. I had no trouble using the release as a server, but kept getting
hung whenever I tried to do a get or send to another remote server. It
didn't matter what machine was on the server end. After about a month of
tearing my hair out I discovered that I had TSGENed IOABT = 0 which caused
TSX to wait for IO completion on jobs. This seemed fine at TSGEN time, but
due to the .ABTIO MCALL in K11PRT caused kermit to hang for two minutes at
every get or send command.
Thus, users should be aware that they have to either (1) TSGEN IOABT = 1
or (2) at the command line (or in a command file) prior to running kermit
issue the SET IO ABORT command. You may want to remember to SET IO NOABORT
after running kermit as well.
[Ed. - Thanks for the report; it's been added to the K11.BWR file.]
------------------------------
Date: 17 Mar 87 00:37 GMT
From: cfac-cso @ Walker-EMH.arpa
Subject: SANYO MBC555 AND KERMIT
Keywords: SANYO Kermit
I have just obtained a copy of Kermit and attempted to run it on my Sanyo
MBC555 with video interface card. I am using XXXMBC.XXX version of Kermit
and I cannot utilize the autoanswer function of my Smartmodem 300 utilizing
my RadioShack model 100. Does anyone have any suggestions?
G. Lyford
CFAC-CSO@WALKER-EMH
------------------------------
End of Info-Kermit Digest
*************************
-------
9-Apr-87 12:07:07-EST,25455;000000000000
Mail-From: SY.CHRISTINE created at 9-Apr-87 12:04:06
Date: Thu 9 Apr 87 12:04:06-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #9
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12293167167.203.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Thu, 9 Apr 1987 Volume 6 : Number 9
Today's Topics:
Version 3.3.111 of VAX/VMS Kermit Available
New Kermit Available for Apple II DOS and ProDOS
New Version of Kermit now Available for Commodores
Commodore-64 GEOS Kermit Available
Announcing a new version of ISIS Kermit
Re: TRS-80 Model I/III Kermit
AT&T 6300 File Transfer Problems Solved
UUCP Source Copyright Status - IMPORTANT
Kermit on the Macintosh II
Re: Kermit on the Macintosh II
Kermit for the Mac SE
MacKermit 34 on 128K
Sanyo Kermit and Auto Answer Modem Mode
XENIX Clock Tick and Kermit
CP/M-80 kermit for the Epson PX-8
----------------------------------------------------------------------
Date: Mon 6 Apr 87 15:38:15-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Version 3.3.111 of VAX/VMS Kermit Available
Keywords: VAX/VMS Kermit
This is to announce VAX/VMS Kermit Version 3.3.111, from Bob McQueen at
Stevens Institute of Technology.
This version is a maintenance version only and does not contain any major
development work. This version has been tested under VMS 4.3, 4.4, and 4.5.
It will definitely not run under pre-4.0 releases of VMS (version 3.1 of
VMS Kermit was the last version that would do so; it is still kept in the
Kermit distribution as VMSV31.HEX).
The major change is the addition of a TRANSMIT command for raw file upload.
There are also internal improvements and bug fixes involving the CONNECT
command, IBM mainframe communication, etc.
The task image is encoded in hex format using the VMSHEX program, and is
decodable with the VMSDEH program. This release includes modified versions of
the hexify/dehexify programs, contributed by Eric McQueen (no relation) of Utah
State University; they allow 16-bit, 24-bit, or 32-bit addresses, and VMSDEH
recognizes each kind automatically. The new release of Kermit-32 is hexified
with 32-bit addresses, and so requires this new version of VMSDEH to decode it.
------------------------------
Date: Fri 3 Apr 87 15:35:48-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: New Kermit Available for Apple II DOS and ProDOS
Keywords: Apple Kermit
This is to announce a new release (3.75) of Apple II Kermit that runs under
both Apple DOS 3.3 and ProDos, from Ted Medin (MEDIN@NOSC.MIL). It includes
new LOG, SERVER, and SET commands, the ability to do XON/XOFF, printer control,
VT52 emulation improvements, timeouts, support for various 80-column cards and
for a variety of communication cards including:
Apple Comm Card
CCS 7710
Hayes Micromodem II
Microtec Comm Card
Super Serial Card
and it has extended-length packet support.
The program is based on the previous release of Apple II Kermit, which remains
available (for now) as KER:APP*.*, because it's not yet clear at what point
these two versions diverged, and whether the old version has been serving as
the basis for parallel developments. The new version is in KER:A2*.*, and is
written in a dialect of the CROSS assembler language, and comes with a cross
assember (A2XASM.*) written in C to assemble it; this cross assembler can be
run on a Unix system (Berkeley or Ultrix, and possibly any other Unix system,
so long as it runs on a 2's complement, rather than 1's complement, machine).
It might also be possible to assemble it with the Merlin assembler after some
minimal editing, except that the source file is too big and would need to be
broken into pieces (anyone who succeeds in doing this is encouraged to report
back the actual procedure).
The memory size of this version of Kermit is currently $7000 so it should
run on a 32K Apple.
------------------------------
Date: Wed, 25 Mar 87 02:28:04 est
From: "Ray Moody" <aij@s.cc.purdue.edu>
Subject: New Version of Kermit now Available for Commodores
Keywords: Commodore Kermit
ANNOUNCING
Commodore 64/Commodore 128 Kermit Version 2.0(57)
The new features include:
1) Bug fixes.
2) VT100 emulation.
3) Commodore 128 support.
4) Fresh bugs.
1) Bug fixes.
I fixed the bug that prevented people from using a standard VT52
termcap entry when emulating a VT52. The problem was when UNIX wanted to
scroll the screen in moved the cursor to what it thought was the bottom line
(the 24th) and sent a line feed. On the Commodore, this didnt scroll the
screen. The cursor was moved to the 25th line.
The fix for this bug was to reduce the size of the screen to 24
lines. The 25th can be used as a status line by programs like sysline (see
below).
This change obsoletes the termcap entry for Kermit 1.7. Use a
straight VT52 termcap. You can add so=\Eo:se=\En if you desire.
IMPORTANT: If you use the old Kermit termcap entry, strange things
happen!
2) VT100 emulation.
Kermit 2.0 will emulate a VT100. Type "set terminal-emulation
vt100". Kermit recognizes most of the VT100 escape sequences, and all of
the popular ones such as start underline, start flashing, set scrolling
area, and others.
Kermit 2.0 will support a status line like that generated by
sysline(1) in VT100 mode. To do this, you must add the hs, ts, fs, and ds
termcap entrys. The interesting part of my .login file is:
set noglob
set term=(`tset -SQ -m '<2400:vt100' -m 'unknown:?regent20'`)
if ($term[1] == vt100) then
setenv TERM vt100
setenv TERMCAP $term[2]"hs:ts=\E7\E[m\E[25;0H:fs=\E8:ds=\E7\E[25;0H\E[2K\E8"
else
setenv TERM $term[1]
setenv TERMCAP $term[2]
endif
unset noglob
Note that Kermit 2.0 will work with a standard VT100 termcap, but if
you dont add the hs, ts, fs, and ds fields, you cant use a sysline.
3) Commodore 128 support.
Kermit 2.0 will support the 80-column chip in the Commodore 128. To
use this, boot your Commodore 128 in C64 mode. At the prompt, type "set
screen-driver commodore-128".
4) Fresh bugs.
There are probally alot of fresh bugs in this version. If you find
any, pleas let us know!
The commands that have been changed in this version are:
set vt52-emulation on -> set terminal-emulation vt52
set vt52-emulation off -> set terminal-emulation none
(added) -> set terminal-emulation vt100
show vt52-emulation -> show terminal-emulation
set screen-width 80-columns -> set screen-driver 80-columns
set screen-width 40-columns -> set screen-driver 40-columns
(added) -> set screen-driver commodore-128
There are many more things I want to add in the future, such as the
ability to change the screen colors, a file-type compatible with C-power
files, Improved VT100 emulation, key bindings for the extra keys on the
C128, etc.
These will get done in due time.
So much for the features. To get a copy of Kermit 2.0, the only place that
you will be able to get it FOR SURE is from Columbia U or on diskette from:
Dr. Evil Laboratories
P.O. Box 190
St. Paul, IN 47272
Why this place that you have never heard about? Well, this company is a
third mine, and it is the only place I know of set up to distribute disks on
any kind of regular, reasonable basis. To get it, just send $5.00 to cover
the disk and postage. I want to stress that Kermit is PUBLIC DOMAIN, and
may be freely copied. Dr. Evil Labs can't afford to give it away because
supplies cost $$. Dr. Evil Labs isn't out for your buck, as it sells
shareware exclusively (i.e. Do you know of anyone rich from selling
shareware?? Of course not!).
One more thing. The manual with this new version is still the same manual
that was released with v1.7(52). My roommate, Kent Sullivan, is going to
completely revise the manual to reflect all of the new features. It will be
released as soon as the final 2.XX version is finished. He should do a good
job, as he is a Professional (Technical) Writing major. He said that if
anyone has any complaints/ideas about the manual to drop me a line, or him
directly at:
corvair@ec.ecn.purdue.edu
pur-ee!ec.ecn.purdue.edu!corvair
Ray Moody
aij@s.cc.purdue.edu
pur-ee!s.cc.purdue.edu!aij
[Ed. - The new files are in KER:C64V2.*, available with FTP at CU20B (user
ANONYMOUS - any password) and through KERMSRV on BITNET. There is no HEX
file available for the new code. If anyone would like to get the new source
and make a HEX file for Kermit distribution, it would be appreciated. See
message below for another possible new Commodore Kermit version for GEOS.]
------------------------------
Date: Tue, 31 Mar 87 04:40 CST
From: <JOHN@UKANVAX.BITNET>
Subject: Commodore-64 GEOS Kermit Available
Keywords: Commodore-64
This is a "vaporware" announcement of a version of Kermit for the Commodore
64. Any comments, suggestions, hints, wishes, mumbles, or other
communication is invited.
I am especially interested in bugs and problems encountered in Kermit
implementations. Especially useful would be discussion on methods (tricks?)
to make this implementation of Kermit "robust".
Machine: Commodore 64
Operating System: Berkeley Softworks' GEOS, if we can get
technical info. on it.
Programming Language: 'C' and 6502 Assembly
"Seriousness": The authors are college students, developing
this on their spare time. We are 85% dedicated to
completing the project as scheduled.
Tentative Schedule: Testing will (hopefully) begin 3rd
quarter '87.
We are aware of one other implementation of Kermit for the
'64 that is based on the Apple version. The implementation
we are writing will have more features, including
(hopefully) VT100 emulation in 80 columns.
We also have plans of porting the program to an Atari 800 in
the future. (It will run under ATARI DOS.)
A few notes: now we are 95% committed to completion
it WILL run under GEOS, but early versions may not.
How much in demand is VT220 emulation? We are considering it, but is the
selective erase and special character attributes bold and blink important?
Thee selective erase looks NOT FUN. The downloadable character sets are out
for sure..Not enough resolution on the '64.
For that matter, what kind of terminal would it be good to emulate in
addition to the VT220?
Thanks to anyone who writes,
John
------------------------------
Date: Mon 6 Apr 87 12:20:47-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing a new version of ISIS Kermit
Keywords: ISIS Kermit
Announcing a new version of ISIS Kermit created by Bill Boyd, Hughes
Aircraft Company, Fullerton, CA, from a version (MDS) received from Columbia
University via the DSSO department of Intel. It incorporates some
enhancements inspired by the Kermit version from Leigh Instruments (MD2) as
well as a number of other enhancements. All of the ISIS Kermit files have
the prefix "MDS". For more information on this version, see file
MDSAAA.HLP.
The ISIS Kermit provides dumb terminal emulation and file transfer for Intel
Series II, Series III and Series IV computers running the ISIS operating
system. It has the basic Kermit features and some additional ones.
According to somone who used some Kermit material from the new Kermit tapes,
the installation command file for Intel iRMX-86 (I86) is incomplete. This
version of ISIS Kermit differs in several ways from the earlier (MDS)
version. See the .DOC file for more details.
William H. Boyd, Jr.
Hughes Aircraft Company
Bldg 635 M/S KA266
1901 W. Malvern Ave.
Fullerton, CA 92634
[Ed. - Thanks! The new Verison has replaced the old one in KER:MDS*.*. The
old version is now stored in KO:MDS*.*]
------------------------------
Date: Fri, 27 Mar 87 11:28:32 CST
From: cortex!sob%soma.UUCP@rice.edu (Stan Barber)
Subject: Re: TRS-80 Model I/III Kermit
Keywords: TRS-80 Model I/III
As a point of interest, I will try to get out a new version of TRSMIT for
the MODEL I/III computers sometime before the end of summer. If you have
some features you'd like to see, send a note to sob@rice.edu.
Stan Barber
------------------------------
Date: Thu, 26 Mar 87 12:26 MST
From: Kevin J. Gray <GRAYK@BYUVAX>
Subject: AT&T 6300 File Transfer Problems Solved
Keywords: AT&T 6300, Modems
KERMIT USERS:
About a year ago I reported some problems running Kermit on the AT+T
6300. The problem was an excessive number of retries and failed transfers.
A few months later I saw a message in the digest reporting similar problems
due to overheating of a voltage regulator on a modem. This turned out to be
the problem in my case also but I was unable to correct it by removing the
cover as was mentioned. After four months and three tries the manufacturer
was unable to correct the problem. The offending modem is marketed under
many brand names. It is recognizable by eight LED's on the front of the
case. I got a refund, bought a quality internal modem, and over the past
six months have averaged less than 1 retry per 1000 packets transferred.
------------------------------
Date: Wed, 1 Apr 87 17:43:39 PST
From: blarson%castor.usc.edu@usc-oberon.ARPA (Bob Larson)
Subject: UUCP Source Copyright Status - IMPORTANT
Keywords: UUCP Kermit
In article <122@njitsc1.UUCP> bc@njitsc1.UUCP (Bill Cheswick) writes:
>In article <7319@boring.mcvax.cwi.nl> jack@boring.UUCP (Jack Jansen) writes:
>The point is, why should we use those icky uucp protocols that are
>hardly documented, and unused except in some proprietary sofware
>Because it is faster. Compare the transfer speeds of uucp and kermit: you
>only get about half your baud rate in kermit file transfers. uucp does
>better.
Kermit with full duplex windows should aproach 75% effeciency on
binary files, and about 95% on ascii text files. UUCP will do worse
than windowing kermit on lines with high latency. (Satelite links,
fast "9600 baud" half-duplex modems.) (Kermit can work with up to 32
outstanding acks, UUCP is 2 I think.) The large packet option of
kermit will do better than that in some situations.
>Of course, the real problem is that kermit is still inefficient.
The problem is kermit was designed for environments present in the
real world, and UUCP for an ideal world. Many unix administators have
trouble trying to get UUCP to work through real-world modems, port
selectors, multiplexors, etc.
> (They said
>they were thinking of improving the protocol a couple of years ago. I wonder
>if anyone has worked on it...)
The extentions you are talking about are called "full-duplex windows" and
"large packets". Both are present in the most recent protocol manual,
and there are implementations available from Columbia university.
Unfortunatly, neither are in the Unix implementation C-Kermit yet. Of
course, all correct kermit implementations should work with all
others, whether any specific enhancement is present or not.
>And while you are looking for a protocol, how about using one that transmits
>files in both directions at the same time? There are many protocols that
>have solved this problem already.
I've thought of proposing such an extension to kermit.
>Actually, I use kermit quite often, and like it. But shouldn't a program
>that may be responsible for a lot of telephone use be as efficient as
>possible?
As efficient as practical. Squeezing a few percent more out a phone
conversation by limiting yourself to a single vendor for software is a
trade-off that should be examined closly.
People seriously interested in kermit can read the info-kermit digest on
mod.protocols.kermit. Info-kermit-request@cu20b.columbia.edu can be
contacted if you need an arpanet/bitnet subscription. There is also a book
on kermit by Frank da Cruz, I have not yet read it.
Kermit is available via arpanet ftp, bitnet, uucp from okstate, and on
tapes. The request address above should be willing to send the details if
needed.
Bob Larson
Arpa: Blarson@Usc-Eclb.Arpa
Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson
seismo!cit-vax!usc-oberon!castor.usc.edu!blarson
[Ed. - It should be noted that long packets and sliding windows are not
necessarily easy to implement in Unix Kermit, due to the fact that Unix's
kernel terminal buffers are not very big -- 256 bytes or so. Since Unix
Kermit transfers files in rawmode (in order to avoid 8th-bit prefixing when
not required by the communication link), it cannot do XON/XOFF flow control,
so that long packets or a windowful of short packets would overrun its
buffers. One solution would be to always do 8th-bit quoting, which would
allow the avoidance of rawmode. But that would add overhead, and it would
also cause problems with the Kermit programs that can't do 8th-bit quoting.
------------------------------
Date: Fri 20 Mar 87 11:01:04-EST
From: MacIntosh User Group <UG.CUMUG@CU20B.COLUMBIA.EDU>
Subject: Kermit on the Macintosh II
Keywords: Macintosh II Kermit
While in California for the AppleWorld sideshow I was left alone for
two hours with a Mac II during which time I had opportunity to pop a Kermit
disk into its gaping maw . . . You may be happy to know that, as far as I
could tell, the program seemed to run just fine. According to Didier Diaz,
the Mac II project coordinator, about 30 to 40% of the programs written for
the Mac don't run on the II due to their not following "Inside Macintosh"
stringently enough. He was happy to see Kermit faring so well by
comparison.
Just thought you might like to know this bit of trivia.
Father Mack +
(a.k.a.: Fr. Larry D. McCormick,
President, CUMUG)
------------------------------
Date: Fri 27 Mar 87 09:57:57-EST
From: Robert Cartolano <US.RTC@CU20D.COLUMBIA.EDU>
Subject: Re: Kermit on the Macintosh II
Keywords: Macintosh II Kermit, Mac SE
It is good to hear. Kermit works well with the Mac SE also. I think Apple
is still working on compatibility, and when they get through, they expect
90% of all programs to run on the II.
Rob
------------------------------
Date: Mon 6 Apr 87 08:59:23-EDT
From: David Zubrow <SS89@TB.CC.CMU.EDU>
Subject: Kermit for the Mac SE
Keywords: MacKermit
Has anyone had success using Kermit with the Mac SE? I'm using a US Robotics
modem and the version of Ckmker from Sumex-Aim. The cable from the computer
to the modem is one that is wired to match a MacPlus. Whenever I log into a
remote host I get the connect tone, I might even get so far as to login, but
after a few characters are displayed on my screen the modem hangs up and gives
a "NO CARRIER" message. I'm at a loss as to whether the problem is the modem
or the software or the cable. Obviously, those are things I will change, not
the computer!
Thanks for your help,
Dave Zubrow
Committee on Social Science
Research in Computing
CMU
------------------------------
Date: Wed, 1 Apr 87 22:23:12 pst
From: uw-apl!apl-em!dunlap@beaver.cs.washington.edu
Subject: MacKermit 34 on 128K
Keywords: MacKermit
> Date: Sun, 15 Feb 87 11:58 EST
> From: Mark B. Johnson <CDTAXW%IRISHMVS.BITNET@wiscvm.wisc.edu>
> Subject: MacKermit on a 128K Machine?
> Keywords: Mac Kermit
> Is anyone successfully using MacKermit V0.8(34) on a 128K machine? I am sure
> we had done it here sometime back, but I have tried it recently with several
> different versions of the Finder and System and keep getting system crashes
> when trying to Send files. We are sure it is the System and Finder, and are
> wondering if anyone who might be doing it successfully could send us their
> configuration. Thanks again.
I think MacKermit V0.8(34) is too big for a 128K Mac. I have experimented a
bit by taking out the VT100 fonts and the "blank cursor" which had been
added using the Resource Mover according to Davide Cervone. Without those
it gets a bit farther in sending and receiving files. In the receive cases
where three dialog boxes are overlaid it bombs. And when sending it bombs
when trying to display the files to chose in a dialog box. I have tried
this with slightly different results (but not good) using both the original
(Summer 1984) system and finder as well as the March 1985 update which
includes finder version 4.1.
John Dunlap Applied Physics Lab, University of Washington
dunlap%apl-em%uw-apl%uw-beaver@washington.edu
[Ed. - Thanks for the report, it's been added to the "beware" file.]
------------------------------
Date: 1987 Mar 27 17:24 EST
From: Bob Babcock <PEPRBV@CFAAMP.BITNET>
Subject: Sanyo Kermit and Auto Answer Modem Mode
Keywords: Sanyo Kermit
I saw your message in Info-Kermit digest complaining that you couldn't use
auto-answer mode on your modem with Sanyo Kermit. I can think of two
possible problems. One is that Hayes compatible modems have a command to
set the number of rings before answering, with zero rings meaning never
answer. I think the usual default is to answer after one ring, but perhaps
not. More likely, the problem is with DTR. I don't remember offhand how
Sanyo Kermit leaves DTR set when not connected, but it could be telling the
modem to disconnect, which might reasonably be interpreted to mean don't
auto-answer either. There is probably either a modem command or a switch
you can set to force DTR always high. See if this makes it auto-answer.
Also, there is a version of Sanyo Kermit which requires the video board, and
has the same VT-100 emulation code as the IBM version. Right now it's at
the 2.29a level, but I hope to bring it up to 2.29b or 2.30 in the not too
distant future. There is also an independently developed Sanyo Kermit with
a VT-100 emulator which does not require a video board. Last I heard, this
version was being upgraded from 2.28 to 2.29.
------------------------------
Date: 30 Mar 87 20:44:01 GMT
From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr)
Subject: XENIX Clock Tick and Kermit
Keywords: XENIX, C-Kermit
Re: Info-Kermit Digest V6 #8:
In C Kermit there is code which assumes that for XENIX the CLOCK_TICK
should be 50. Xenix/286 runs 50 ticks per second, and the value should
be in milliseconds per tick (20). Older version ran 20 ticks/sec. There
is a simple solution fos all USG versions, SysIII and later:
#include <sys/param.h>
#define CLOCK_TICK 1000/HZ
This works for all systems with less than 1000 tick/sec, and avoids having
to change the value for other machines. Machines with fast clocks (such as
Cray2, once every 4.1ns) will need some minor modifications to this code.
2nd:
C Kermit compiled with the Xenix option doesn't reset the DTR line when
performing a connect after a hangup (via ^\H). With the SysV option the DTR
works correctly, but the lock file doesn't get handled correctly. If anyone
has a fix for this it wold be desirable to have the line become active after
hangup without reselecting the device.
bill davidsen sixhub \
ihnp4!seismo!rochester!steinmetz -> crdos1!davidsen
chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)
------------------------------
Date: Tue, 31 Mar 87 08:33:05 EST
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: CP/M-80 kermit for the Epson PX-8
Keywords: CP/M-80 Kermit, Epson PX-8
As a general warning, while this version works quite well downloading files
to the RAM disk, it seems to hang up and get into trouble when used with
Epson's external 3 1/2 inch diskette unit. When files of more than moderate
size are downloaded, the first 15Kb or so are transferred without
difficulty, then the number of retries suddenly goes 'way up, becoming about
1:1 with the number of packets. It finally grinds entirely to a halt.
These problems are speed independent (they occur at 1200 baud, and they
occur at 19.2Kbaud in about the same place). And they do NOT occur when the
default "disk" is the A: ram disk, only with the external diskette drive.
Fixes or suggestions would, of course, be welcome.
------------------------------
End of Info-Kermit Digest
*************************
-------
8-May-87 12:50:42-EDT,22980;000000000000
Mail-From: SY.CHRISTINE created at 8-May-87 12:48:51
Date: Fri 8 May 87 12:48:51-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #10
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12300766567.9.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Thu, 07 May 1987 Volume 6 : Number 10
Today's Topics:
Use of KERMSRV@UOFT02.BITNET
IBM PC Kermit on the New IBM Personal System/2 Series?
MS-Kermit Works on IBM PC2/30
MS-Kermit Works on IBM PC2/50
Kermit-MS 2.29 Modem Problems
Local Echo Problem with MS Kermit 2.29B
MSVIBM.BOO Problems
Printer Control in MS-Kermit 2.29B
Apollo Kermits (Pascal and C)
Apollo Kermit bug
ISIS Kermit - fixes and frustrations
QL Kermit HEX Needed
Commodore Kermit .HEX file Needed
Bugs in new Apple Kermit (A2)
Bug in Amiga C-Kermit
C Kermit on Motorola Delta SVR3
Bugs in Sperry Univac Kermit
----------------------------------------------------------------------
Date: Mon, 20 Apr 87 08:12 EST
From: <BRIAN@UOFT02.BITNET> (brian nelson)
Subject: Use of KERMSRV@UOFT02.BITNET
Keywords: KERMSRV
I would like to point out a couple of problems with requests to the Kermit
bitnet server here at Toledo. The first is that attempts to see if Kermsrv
is 'logged in', ie, SEN/COM UOFT02 CPQ U KERMSRV or SM RSCS MSG UOFT02
KERMSRV CPQ U KERMSRV will ALWAYS fail. This is a VMS node running Jnet and
jnet treats server processes in a manner unlike VM does.
For all pratical purposes, Kermsrv is always running. If a message is sent
to it, and for some reason its not there, Jnet will tell you.
Secondly, KERMSRV can ONLY respond to interactive messages, it can not
process mail. I see several attempts per day to send it mail.
I hope this clarifies any confusion regarding the server here.
Brian Nelson
------------------------------
Date: Fri 3 Apr 87 12:26:06-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: IBM PC Kermit on the New IBM Personal System/2 Series?
Keywords: IBM PC System/2
Now that we've seen IBM's announcements for their new line of PCs, is there
anyone out there who can say whether IBM PC Kermit (2.29B or earlier) runs on
them? If not, what are the symptoms? If so, are there any peculiarities?
------------------------------
Date: Wed, 8 Apr 87 17:55:12 PDT
From: gts@violet.berkeley.edu (Greg Small)
Subject: MS-Kermit Works on IBM PC2/30
Keywords: MS-DOS Kermit
MS-Kermit 2.27 ran OK [under DOS 3.3 on the PC2/30] with the serial port so the
serial UART and interrupt controlers are compatible. Requires distribution of
software in 3.5" floppy format.
------------------------------
Date: 14 April 1987, 11:15:11 CST
From: C03640JP@WUVMD.BITNET (Michael Palmer)
Subject: MS-Kermit Works on IBM PC2/50
Keywords: MS-DOS Kermit
Am coming to you now from a model 50. Kermit ... work[s] fine with it.
------------------------------
Date: Wed, 6 May 87 13:26 EDT
From: HOLLEY <BOB@SER>
Subject: Kermit-MS 2.29 Modem Problems
Keywords: MS-DOS Kermit, Modems
Our data center began distributing Kermit-MS 2.29 in the later part of last
fall. Several weeks after we began, it became obvious that version 2.29
would not work for users who had internal modems. In January, we learned of
version 2.29B, which appeared to address the internal modem problems, and we
began to distribute that.
We thought all our problems were solved, but now we have several people with
internal Hayes 1200B "short card" internal modems (at least one of those has
his modem card plugged into a true IBM-XT), who seem to be having troubles
even with 2.29B. In addition, we just came across the following article in
the March/April issue of the University Computing Services Newsletter of the
University of Oklahoma:
HAYES MODEM INCOMPATIBLE WITH KERMIT
There is a new Hayes internal modem which is incompatible with Kermit-MS
version 2.29. The modem is model 1200-B, the same designation used for
previous models. The distinction is that it is on a half-length or "short
card." Short cards are about 7 inches long.
This incompatibility is distressing because Hayes modems are generally
acknowledged as the industry standard and Kermit-MS supports Hayes
compatible modems. The Hayes short-card modems fail to establish a
connection when used with Kermit-MS version 2.29. They may be incompatible
with other software as well. They do work with Hayes SmartCom software and
earlier versions of Kermit-MS. Hayes-compatible modems from other vendors
work with 2.29. This problem is unlikely to be resolved in the near future.
(Reprinted from the University of Nebraska at Omaha Campus Computing
Newsletter, March/April 1987)
It is not entirely clear whether the above article is referring to the
original release of Kermit-MS 2.29 or to Kermit-MS 2.29B. One is led to
suspect the latter, though, as we never found ANYONE with an internal modem
of any kind that could get 2.29 to work.
Is there really some particular problem with Hayes 1200-B "short-card"
internal modems and Kermit-MS 2.29B?? If there is, we would like to warn
our users not to purchase this particular equipment.
Thank you for your kind attention.
Robert M. Holley
Director, User Ed & Pubs
Southeast Regional Data Center
Florida International University
Miami, Florida
BITNET Addresses: BOB@SERVAX or BOB@SER
[Ed. - The current developer of MS-Kermit tested 2.29B with a loaner Hayes
1200B half-height card, and it worked successfully. Another user with an
Everex half-height Hayes clone also reported successful operation. Can anyone
else with these modems report further, so that if any additional fixes are
needed, they can get into 2.30 before its final release?]
------------------------------
Date: Thu, 16 Apr 87 10:24:37 CDT
From: pyle@ngp.utexas.edu (Keith Pyle)
Subject: Local Echo Problem with MS Kermit 2.29B
Keywords: MS-DOS Kermit
One of my co-workers asked me to report that there is apparently a bug in
the handling of local echo with MS Kermit 2.29b. When transferring files to
or from a CMS system (CMS Kermit 3.1), he has noted that the first character
typed as a command to the CMS Kermit will be displayed but that subsequent
characters do not appear until after the return is entered AND the CMS
Kermit has processed the command.
Keith Pyle pyle@ngp.utexas.edu
[Ed. - We are unable to reproduce this problem, using PC/ATs and a VM/CMS
system running the same version of CMS Kermit. Has anyone else experienced
a problem like this?]
------------------------------
Date: 26 April 1987, 16:38:47 EST
From: Aharon Friedman 516-282-7979 FRIEDMAN at BNLVMA
Subject: MSVIBM.BOO Problems
Keywords: MS-DOS Kermit
I have problems with that file. It stalls the computer after running
msbpct on it.
Aharon Friedman
[Ed. - Most likely the .BOO file was the victim of a nonstandard ASCII/EBCDIC
translate table somewhere on its journey between its home on CUVMA and your
PC. The .BOO file has been successfully decoded at many other BITNET sites.]
------------------------------
Date: 29-APR-1987 10:53:36
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Printer Control in MS-Kermit 2.29B
Keywords: MS-DOS Kermit
Printer control from vn 2.29b of IBM Kermit is fine in the sense that it
appears to correctly handle flow control etc.
However, if you are expecting to use the power of the printer via escape
sequences then you will be disappointed.
There are two modes for controlling the printer port directly from the
terminal line : Esc [ 5 i and Esc [ ? 5 i. The former is used to select
a transparent mode (no screen echo), while the latter selects a
conversational mode (with screen echo).
The important point about transparent mode is that no escape sequences
received by Kermit in this mode should be interpreted for the screen's
purposes - they should all be passed on unchanged to the printer, with
the sole exception of the escape sequence which closes the printer port
( Esc [ 4 i ).
Version 2.29b does no such thing - it interprets an escape sequence and
appears to remove the escape and the character following from the stream
of data. This is consistent with a primitive two byte escape sequence
model beloved of VT52 and other simple terminal protocols.
It has another related failing : since Kermit appears to regard nul as a
padding character to be thrown away at liberty, it continues to do this
in transparent printer mode. Some printers (e.g. the Epson family)
feature nul as a required part of an escape sequence. More important
perhaps is that more recent printers have started to offer a downloading
facility for character sets. A character definition of course is
supplied as a sequence of bytes rpresenting the rows of the matrix, and
nul is the value required for an empty row.
I know I may be asking the printer support module to run before it can
walk, but I hope you can appreciate the importance of the matter.
Cheers : Norman Bridges.
------------------------------
Date: Tue, 31 Mar 87 14:05:09 MST
From: "Tim E. Barrios" <barrios%asu.csnet@RELAY.CS.NET>
Subject: Apollo Kermits (Pascal and C)
Keywords: Apollo Kermit
Thanks for fixing the ^Y's in the file. Now, it looks like there is one
key character that is missing from the following lines causing a syntax
error when compiled:
567, 577, 850, 1282, and 1442
my guess is that the character is '&'. this might have been related to the
^Y problem.
About the 'C' version, it's been almost a year since I messed with it, but it
had something to do with a difference between the Unix sys5 include library's
'.h' (some record's struct statement) and what the kermit source expected.
The person who is working on that problem is:
wicinski@nrl-css (arpa net)
we have kept in touch concerning both versions on the apollo.
thanks,
tim barrios
[Ed. - See message below...]
------------------------------
Date: Fri 3 Apr 87 15:34:12-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: Apollo Kermit bug
Keywords: Apollo Kermit
I'm sorry that the Pascal source file I sent you for Apollo Kermit had some
errors in it.
For reasons I have not yet found, when I sent APOKERMIT.PAS from the Apollo
to the DEC 20 using TOPS 20 KERMIT version 4.2(253), alll the "Y" characters
turned into "control-Y's", and all of the "&" characters were missing. When
I sent the same file to an IBM-PC using KERMIT-MS version 2.29b, the file
was sent correctly.
[Ed. - All of the changes have been made so the Apollo Kermit should be ok
now.]
------------------------------
Date: 17 Apr 87 17:48:00 EDT
From: John R. Williams <JWILLIAMS@ARI-HQ1.ARPA>
Subject: ISIS Kermit - fixes and frustrations
Keywords: ISIS Kermit, MDS Kermit, iPDS
For those of you who have implemented Bill Boyd's latest version of ISIS
Kermit (see the Digest, Volume 6, Number 9) I have an interim fix for the
problem of losing characters in Connect mode and a plea for help concerning
the program's performance. I have not been able to contact Mr. Boyd.
First, the fix. This will allow at least some of you to operate in Connect
mode at 4800 and 9600 baud. It will still occasionally miss characters at
4800 baud and consistently miss 1 or 2 characters per line at 9600 baud,
but in my case, at least, 9600 baud Connect mode operation is now usable, if
not perfect.
In the Connect Module, find the statement that looks something like this:
if ready(port) > 0 then call putc(getc(port, 0);
Declare a temporary variable, such as "i", and then enclose the above
statement in a DO loop, like this:
declare i byte;
.
.
.
do i = 1 to 200;
if ready(port) > 0 then call putc(getc(port), 0);
end;
This causes the program to read the input port 200 times for every time it
checks for keyboard input. The loop termination value 200 was determined
empirically. You may find that another value works better for you. I also
replaced "putc" with "co", which bypasses the status checking provided by
"putc". That may not provide any real benefit.
Next, performance considerations. You may be interested to know that in my
system file transfer at 19200 baud occurs with no errors. The only problem is
that screen output at 19200 is pure gibberish - it misses 50 to 70 per cent of
the characters, even with the fix noted above.
The performance problem that concerns me with the new version, however, is
that for some reason when receiving files the time between packets is
excessively long, averaging about six seconds! The old version is at least 10
times faster under the same circumstances, and I cannot find any code
differences to account for it. The delay is apparently in procedure RPACK
where it waits to receive the SOH. If anyone has an explanation and a fix for
this condition, I am most anxious to hear from you!
All my experience with ISIS Kermit has been using a Series III MDS, with a
Winchester disk, connected directly to a VAX 11/782 terminal port (no modem).
The VAX is running VMS Kermit-32 version 3.2.77 under VMS 4.4.
Also, if anyone has had any success using ISIS Kermit on an iPDS, I'd like to
share experiences with you. In my version, the iPDS receives VAX files OK but
fails miserably when sending.
John
[Ed. - Thanks. This note has been put into the file KER:MDSMIT.BWR.]
------------------------------
Date: Wed, 22 Apr 87 11:38:17 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: QL Kermit HEX Needed
Keywords: Sinclair QL Kermit
Probably not many Sinclair QL users own a disk drive nor do they have the C
compiler available. Couldn't someone send a hex file to be included in the
Kermit library? Thanks in advance.
[Ed. - If someone could send a .HEX file for this Kermit version, we would
be glad to include it in the regular Kermit Distribution.]
------------------------------
Date: Wed, 22 Apr 1987 14:53 EST
From: Ray Moody <MOODY@PURCCVM>
Subject: Commodore Kermit .HEX file Needed
Keywords: Commodore Kermit
I have received several requests to create a .HEX file for Commodore
Kermit Version 2. I don't have a program that can create .HEX files. Is it
possible for someone else to create the .HEX file?
Ray Moody
aij@s.cc.purdue.edu
ihnp4!pur-ee!s.cc.purdue.edu!aij
moody@purccvm.BITNET
[Ed. - Can anyone create a .HEX file for Commodore Kermit and send it in for
redistribution, or send some kind of .HEX-file maker & decoder to Ray?]
------------------------------
Date: 24-APR-1987 10:31:30
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Bugs in new Apple Kermit (A2)
Keywords: Apple II Kermit
Alan Thomson of our Chemistry department reports a few problems with the new
A2 Apple Kermit. These were found using a non-interrupt driven Mountain
Hardware CPS card (the driver for which will be sent over to you soon):
1. When using GET, A2 Kermit lingers around doing things internally for long
enough to miss the first few characters of the server's response. After
timing out and retrying things settle down to work OK.
2. After issuing FINISH the Apple side waits for 5 seconds before reissuing
its command prompt.
------------------------------
Date: Sat, 25 Apr 1987 00:50 CST
From: Ian Horstmeier <HORSTMIH@UREGINA1>
Subject: Bug in Amiga C-Kermit
Keywords: C-Kermit
I recently received this from a friend of mine regarding C-kermit for the
Amiga. Perhaps this information will be useful.
Subject - Re: Using VT100/KERMIT and IBM systems
Summary - The fix for C-Kermit
The reason that C-kermit on the Amiga doesn't work with the IBM, is because
the parity is not set! I got my version of C-Kermit from kermserv@cuvma
on BITNET, and it still contains this bug. In the CKICON.C module, look
in the connect mode function. In about the middle of it, there is a call
to the output a character function ttocq(c). This needs to be changed to
ttocq(dopar(c)). There! It now works with IBM and sets parity correctly.
According to the comments in the code, Kermit does its own parity checking
and the serial.device is always in 8 bit no parity. I always use kermit on
the mainframe and the vax. One thing you will notice is that the standard
amiga keymap does not generate codes to be compatible with anything! I am
in the process of writing a keymap module for amiga c-kermit to make it look
like a vt100. Good luck!
Walter Reed
UUCP : ihnp4!umn-cs!ndsuvax!ncreed
Bitnet: ncreed@ndsuvax OR NU105451@NDSUVM1
[Ed. - Thanks for the fix -- it's been added to CKIKER.BWR. Further reports
would be appreciated.]
------------------------------
Date: 29 Apr 87 16:41:05 GMT
From: seismo!gatech!mcdchg!heiby@columbia.edu (Ron Heiby)
Subject: C Kermit on Motorola Delta SVR3
Keywords: C-Kermit
Hi! I just finished bringing up C Kermit 4D(061) on a Motorola Delta system
running System V/68 Release 3.0. I found some minor problems that I thought
should be mentioned.
The entry in the makefile (ckuker.mak) for "att3bx" and the corresponding
#define for "ATT3BX" is actually not dependent on the AT&T 3B architecture.
It is for the AT&T Basic Networking Utilities (BNU), also called "Honey
DanBer UUCP". This version of uucp is standard with System V Release 3
as it comes from AT&T and as implemented on the Motorola systems. I suggest
changing the makefile and define to something more like "hdbuucp" or something
like that. Of course, HDB is not restricted to System V releases, so the
"-D" for it should probably be seperate from any particular "make" target.
The "beware" file for C Kermit talks about a name confilict on "unchar" for
ATT 3Bx systems. This is really a System V Release 3 issue and is also
the case for the Motorola implementation. I tried the suggested fix, of
"-Dunchar=myunchar" in the makefile and, as expected, it didn't help. I
edited the files used for my build to change "unchar" to "myunchar". There
are other references to be changed for non-UNIX builds. The files I changed
for this were: ckcker.h, ckcpro.w, ckcfn2.c, and ckcfns.c.
System V Release 3 has re-defined the signal(2) system call as:
extern void (*signal())();
instead of:
extern int (*signal())();
This means that lines in ckudia.c, ckuusr.c, and ckuscr.c must be changed
to avoid illegal pointer combination errors. I just changed "int" to "void"
in each case. Better (more general) would be to use a typedef based on a
define, like "SVR3" (which might also cause the BNU locking code to be used).
The C compiler that comes with SVR3 is no longer so forgiving of random tokens
following preprocessor directives. Convention has been to do things like:
#if FOO
code
#else !FOO
other code
#endif FOO
This causes warnings on both the #else and #endif. Correct would be:
#if FOO
code
#else /* !FOO */
other code
#endif /* FOO */
Several places in ckutio.c had to be changed for this.
Also, ckcdeb.h includes some #include lines for "vax11c" which are not
of legal format. Even though they are bounded by #ifdef/#endif, the
pre-processor still sees them and barfs. I changed the conditionals
surrounding them to cause them to actually be commented out, if "vax11c"
were not defined. This problem could be construed to be a bug in the
C Pre-processor, but I don't have a copy of a current ANSI spec, so am
not sure.
Here are context diffs of the code changes I made. "orig" is the original code
as I received it. "save" is the code as I modified it to compile properly.
[Ed. - This message, and the diffs, have been added to CKUKER.BWR, and will be
looked at for the next release. Thanks!]
Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix
Motorola Microcomputer Division (MCD), Schaumburg, IL
"I am not elsewhere."
------------------------------
Date: TUE, 14 APR 87 14:34:41 GMT
From: ROGER @ UK.AC.TPB
Subject: Bugs in Sperry Univac Kermit
Keywords: Sperry Kermit, Univac Kermit
I recently acquired a copy of Sperry UNIVAC KERMIT written in assembler,
for use on a non front end site.
After a little tinkering , to get it to work with our setup , I discovered
a couple of little coding bugs. I must admit I'm not the world's greatest
programmer in @MASM, but I THINK (underline that in italics) I've sorted them
out:
There was a bug in the SHOW SEND routine that caused the SEND STARTOFPACKET
displayed to be the RECEIVE STARTOFPACKET, and a bug in the SHOW RECEIVE
routine that caused it to display the SEND STARTOFPACKET.
No prizes for guessing what had happened !!!!
The actual parameters in the SHOW list had been juxtaposed; simply
swapping over lines 2281 and 2300 in the original source should cure the
problem.
Another more serious problem was that when assembled with MDLFE=0 and
DCPFE=1, the code still expected to find a couple of entrypoints that
weren't there: they'd not been assembled because of a conditional directive.
My cure is rather elegant, but as I've no idea what I've done it may not be
the right one. All I did was to move the offending reference, in line 2613 to
only occur in the conditional directive immediately following it. that is line
2613 was inserted AFTER the IF MDLFE statement.
That seems to have cured it, it now @MASM's without errors, and @MAP's
without errors. I've succesfully used it in SERVER mode with a PC clone
running CROSSTALK, so I assume I've done the right thing.
If anyone else has any tips or points Id like to hear from them.
Jason LoCascio,
British Gas PLC
59 Bryanston Street
LONDON
W1
(01) 723-7030 ext. 1289
Or I can be contacted at THAMES POLYTECHNIC , via JANET :-
ROGER @ 000045399000.TPB.SPCP.FTP.MAIL
(We are not registered in NRS yet)
------------------------------
End of Info-Kermit Digest
*************************
-------
-------
21-May-87 15:52:34-EDT,23406;000000000001
Mail-From: SY.FDC created at 21-May-87 15:51:32
Date: Thu 21 May 87 15:51:32-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #11
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12304207696.34.SY.FDC@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Thu, 21 May 1987 Volume 6 : Number 11
Departments:
ANNOUNCEMENTS -
Mailing List Problems
New Release of NIH TSO Kermit
New TSO Kermit for the 3708 Front End
New Version of CDC Cyber NOS Kermit
Announcing Kermit for Lilith Workstation in Modula-2
New Release of Acorn BBC Kermit
New C-Kermit for the Sinclair QL version 1.10
Another New Kermit for Sinclair QL
Version 1.01 of Kermit for HP86/87 Available
Announcing Kermit for ICL PC Quattro
New Apple II Kermit 3.75 Driver for Mountain Hardware CPS Card
Kermit Tape Reader Sperry/Univac/Unisys Systems
REPORTS -
Apple ][ Kermit Comments
Unix V.3 & kermit
VMS Kermit HELP files
Qkermit problems
QUERIES -
MVS/TSO Kermit to work with Amdahl V7 & V8?
Sending BREAK from Toshiba 3100?
Is Kermit available for Digital VAXmate?
Kermit for Wang VS-100?
----------------------------------------------------------------------
Date: 21 May 87 3:22:00PM EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Mailing List Problems
Due to many changes in network host tables recently installed on CU20B,
there was a lot of trouble mailing the last Info-Kermit digest, V6 #10.
Some people got 0 copies, some got 1, some got 2. If you receive this one
but didn't receive the last one, send a note to Info-Kermit-Request@CU20B to
get a copy. If you got an extra copy, just send it back (just kidding).
Since #10 was sent out, the mailing list has been corrected to mostly agree
with the new host tables. Apologies for the inconvenience.
------------------------------
From: "Roger Fajman" <RAF@NIHCU>
Date: Tue, 28 Apr 87 01:53:55 EDT
Subject: New Release of NIH TSO Kermit
Keywords: TSO Kermit, IBM Mainframe Kermit
Xref: MVS/TSO, see TSO
This is to announce release 1.0.1 of NIH MVS/TSO Kermit, which fixes some
installation problems. There were problems with the installation JCL,
assembling the table module under assembler FX, and using MVS/370 instead of
MVS/XA. I think that these have all been fixed. The bugs in NIH TSO Kermit
itself are currently being worked on. I hope that we will have a release with
those fixes in a few weeks.
[Ed. - Thanks, Roger! The new files are in KER:TSN*.* at CU20B, or TSN* *
on BITNET, available from KERMSRV at CUVMA, and will appear on Kermit Tape B.]
------------------------------
Date: 15 May 87 1:23:45
From: Christine M. Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: New TSO Kermit for the 3708 Front End
Keywords: TSO Kermit, MVS/TSO Kermit, 3708 Front End
And here's still another new TSO Kermit. This is actually the original,
primitive version 1.0, modified to support the 3708 front end, add missing
error messages, and tested under MVS/XA and TSO/E. The modifications were
done by Geoffrey S. Mendelson, Sungard Central Computer Facility in
Philadelphia, and sent in on tape. The source files are available in
KER:TS3*.* for anonymous FTP from host CU20B, in TS3* * on CUVMA for BITNET
retrieval via KERMSRV, and will appear on Kermit Tape B. Let's hope that
the 3708 support can be integrated into (one of?) the "mainline" TSO
Kermits, and eventually also into the forthcoming portable 370 Kermit.
------------------------------
Date: 12-MAY-1987 15:58:49
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: New Version of CDC Cyber NOS Kermit
Keywords: CDC Cyber Kermit, NOS Kermit
Xref: Cyber, See CDC
Here is version 1.30 of Kermit for CDC Cyber running NOS 2.4, written by
Allison Ballard and Paul Jarvis of Imperial College, London. This version
has support for sliding windows, and is written in Compass.
The files you should get are:
NOSKER.BWR - "Beware" file
NOSKER.CAP - NOS Kermit capabilities at a glance
NOSKER.DOC - User manual
NOSKER.INS - Installation instructions
NOSKER.SRC - Source program
Alan Phillips, Lancaster University
[Ed. - Thanks for sending these files, Alan, and thanks to Allison & Paul at
Imperial College for writing the program. This puts the number of CDC Cyber
Kermits at 4. This version has been added to Tape C, since Tape B is
getting rather full. Hopefully in the future, the two Compass versions can
be merged. The files are available for network access as KER:NOS*.* on
CU20B and NOS* * on CUVMA (BITNET).]
------------------------------
Date: 15 May 87 4:01:32PM EDT
From: Christine M. Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for Lilith Workstation in Modula-2
Keywords: Lilith Workstation Kermit, Modula-2
This is to announce Kermit for the Lilith Workstation, written in entirely
Modula-2 by Matthias Aebi, Institut fuer Informatik, University of Zuerich,
Switzerland. While certain dependencies on the Lilith Medos file system are
implicit in the program, it should be readily portable to any system that
has a Modula-2 compiler.
The files are in KER:M2*.* (actually, K3:, i.e. it goes on "Tape C"),
available for anonymous FTP from CU20B, or M2* * via KERMSRV from BITNET
host CUVMA. M2*.MOD are the Modula-2 source files; M2*.DEF are the symbol
definition files. M2KERM.HQX is a Macintosh Word formatted user manual to
be unpacked on a Mac by BinHex; M2KERM.DOC is the same, but saved "text
only" as a plain ASCII file and then edited by hand to remove excess blank
lines & rejustify the paragraphs (apologies to Matthias for whatever
mangling this may have caused). There's another BinHex document,
M2TITLE.HQX, whose original name was something about TitelBlatt (i.e. Title
Page), but I couldn't find the accompanying application to display it on the
Mac. Many thanks to Matthias for contributing this version, and to
Columbia's Carlos Albuerne for actually bringing it to us on a Mac diskette.
------------------------------
Date: 15-May-1987 12:16:44
From: Christine M. Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: New Release of Acorn BBC Kermit
Keywords: Acorn BBC Micro Kermit
Xref: BBC Micro, See Acorn
This is to announce version 1.45 of Acorn BBC Kermit from Alan Phillips of
Lancaster University (SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK),
which replaces version 1.30 of April 1986. The program runs on Acorn models
B, B+, B+128, and Master 128, with Acorn DFS, 1770 DFS, ADFS, Econet, or any
other Acorn-compatible filing system.
Version 1.45 comes with numerous big fixes and improvements, new
documentation (including a 124-page manual), and a new version (1.50) of
Alan's free 65c02 assembler (which can be used to assemble the program by
those who don't have the ADE assembler).
The new version is in KER:BBC*.* (really K3:, or Tape C), for anonymous FTP
from CU20B, and as BBC* * on BITNET/EARN from KERMSRV at CUVMA. The file
BBC145.ANN lists in detail the changes to BBC Kermit since version 1.30.
The source is in BBCKER.ASM, which is actually the concatenation of many
smaller files (explained in comments at the top).
Version 2.0 of BBC Kermit (which will appear in "many months") will support
sliding windows. Thanks to Alan for producing this new version and sending
it to us over BITNET.
------------------------------
Date: 8-MAY-1987 14:50:05
From: Jonathan Marten
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: New C-Kermit for the Sinclair QL version 1.10
Keywords: Sinclair QL Kermit
It seems that new versions of Kermit for the Sinclair QL are appearing thick
and fast, and this parcel is no exception. I have taken the original C
version written by Robert Coughlan of Liverpool University and greatly
expanded it, replacing may of the features which were removed from its
C-Kermit base to reduce its size; and also added some new ones. These
include default devices, file name translation and transfer interruption;
however server mode is not supported, which the BCPL version in [.QL2] does.
It also does not support the Q-Connect module or any form of flow control
other than CTS/RTS. It however includes most of the interactive command
parser features of full C-Kermit. Hopefully you (or someone out there!)
will find a use for it.
Full documentation is supplied in QLKER.DOC. This version is written to be
compiled using the Metacomco C development system. The files need to be
renamed before compilation.
If it turns out that somebody is interested in using this version, I would
be pleased to receive bug reports or improvement suggestions.
Unfortunately, I have no electronic mail address so I cannot support them
that way. Perhaps some other way could be found.
Jonathan Marten
89 Austen Road
Farnborough
Hampshire GU14 8LG
ENGLAND
(0252) 521894
[Ed. - These files have replaced the old version as KER:QLK*.* on CU20B for
anonymous FTP access. The old version is in KO:QLK*.* for now. BITNET
users may ask KERMSRV at CUVMA for them as QL* *, and they are on Kermit
Tape C for mail orders from Columbia.]
------------------------------
Date: 1-MAY-1987 14:50:11
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Another New Kermit for Sinclair QL
Keywords: Sinclair QL Kermit
Author - David Harper, Dept. of Applied Maths, Liverpool University
(SX36 @ UK.AC.LIV.IBM)
This version of Kermit for QDOS is written in BCPL and is based upon
C.G.Selwyn's Tripos implementation. [Ed. - We never saw the Tripos version.
If anyone out there cares about it, we can try to unearth it.]
The main features are:
(1) It is executed as a QDOS job and so it can run in parallel with other
jobs, including SuperBasic. This means that all the facilities of the
QL are available, even when file-transfer is in progress.
(2) It can operate in both local and server mode - the latter is ideal for
transfer between the QL and another micro, which can view the QL as a
remote 'mainframe'.
(3) A simple teletype terminal-emulator is provided for use when the QL is
required to communicate with a mainframe.
(4) Software support is provided to allow QL-Kermit to be used with the
Tandata QConnect communications device. This is recommended when
the remote mainframe uses XON/XOFF handshaking, since the QL hardware
can only do CTS/RTS handshaking.
(5) The TAKE command is provided to allow the user to put often-used
sequences of Kermit commands into a file.
(6) A HELP command is provided to remind the user of the commands which
can be issued. In addition, HELP SET displays all the SETtable
options.
Copies of QL-Kermit can be obtained by sending a formatted microdrive or
3.5 inch disk with a padded SAE to
David Harper
Dept of Applied Maths and Theoretical Physics
The University
P.O. Box 147
Liverpool L69 3BX
ENGLAND
(This address is only valid until September 1987, and only within UK)
At present, the source code files and the EXECable code just fit onto a single
microdrive. They occupy about 207 blocks. In view of probable future
extensions, it might be advisable to send two microdrives or a disk if you want
both source code and EXEC code files.
The BCPL source code should be compiled using Metacomco's BCPL Development Kit
(Vn. 2.0 or after).
[Ed. - This new implementation of QL Kermit is in KER:QL2*.* on CU20B,
QL2* * on CUVMA for BITNET KERMSRV access, and on Kermit Tape C.]
------------------------------
Date: 29-APR-1987 15:36:36
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Version 1.01 of Kermit for HP86/87 Available
Keywords: HP86 Kermit, HP87 Kermit
On its way to you is version 1.01 of Kermit for the HP86/87, by Martin Rootes
of Sheffield City Polytechnic, UK. This release cures some flow control
problems in version 1.00.
The files for this release are:
HP8KER BOO Complete program - plus file header for boot programs.
HP8KER BAS Complete program - no comments, includes null lines.
HP8KRC BAS Complete program - with comments.
which should replace the existing ones. All other files are unchanged.
[Ed. - These files are in KER:HP8*.* on CU20B, HP8* * on CUVMA, and are
available on Kermit Tape A (moved from Tape C).]
------------------------------
Date: 13-MAY-1987 14:20:57
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Announcing Kermit for ICL PC Quattro
Keywords: ICL PC Quattro Kermit, Concurrent CP/M-86
Here is a Kermit for ICL PC Quattro and PC 2 micros running Concurrent
CP/M-86 (Concurrent DOS). It's by Chris Lock, Nottingham University. I
think I sent these long ago, but they seem to have got lost somewhere.
The files in this lot are:
CN8ICM.A86,CN8IPR.A86,CN8XIC.A86,CN8XIC.H86,CN8XIC.MSG
The CN8I*.ASM files are slight modifications to the system-independent files
that this version has to have in order to work. The changes aren't
appropriate to other implementations.
[Ed. - Thanks, Alan. These files have been added to the other Concurrent
CP/M-86 Kermit files in K3:, and placed in KERMSRV for BITNET/EARN access,
and on Kermit Tape C.]
------------------------------
Date: 14-MAY-1987 09:20:11
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: New Apple II Kermit 3.75 Driver for Mountain Hardware CPS Card
Keywords: Apple II Kermit, Mountain Hardware CPS Card, CPS Card
Files A2CPS.HEX and A2CPS.M65 contain the hex and source respectively to use
the Mountain Hardware CPS card with Apple Kermit 3.75.
The driver is contributed by Alan Thomson, Department of Chemistry,
Lancaster University, Lancaster, UK (JANET mail address
CHA001@UK.AC.LANCS.VAX2)
[Ed. - Thanks! The files are in KER:A2CPS.* on CU20B, and similarly on
CUVMA KERMSRV, and included with Apple II Kermit 3.75 on Tape A.]
------------------------------
Date: April 21, 1987
From: Mike Lucich (via tape)
Subject: Kermit Tape Reader Sperry/Univac/Unisys Systems
Keywords: Sperry, Univac, Tapes
We here at Ft Leavenworth initially had a rough time reading the KERMIT
release tape on our Unisys (aka Sperry, Univac) 1100 mainframe and send you
the following program in the hope others will find it usefull.
We run both assembler and Pascal versions of KERMIT on our mainframe and
have made several minor changes to accomodate MS-DOS KERMIT Version 2.27
through our ancient C/SP front end processors. Fortunately with MSKERMIT
version 2.29 these kludges are no longer required (the ability to set
handshake to any character solves our problems nicely).
Please feel free to refer any Unisys users with problems with KERMIT to us,
if we might help them. Also please return our tape with the latest KERMIT
distribution to the address above. We thank you!
Mike Lucich
USA ISC DOIM
Unisys Support Team
ATTN: ATZL-GMO-IA
Ft Leavenworth, KS 66027-5700
[Ed. - The COBOL program that reads a file from a Kermit tape (the format is
either EBCDIC OS Standard Label Format V or else ASCII ANSI Label Format D;
it's not clear from the message, most most likely it's the EBCDIC tape,
since this program itself arrived on an EBCDIC tape)... is in
KER:UNIVAC.INS, along with this message.]
------------------------------
Date: 11-MAY-1987 09:33:49
From: Martin J Carter <majoc@uk.ac.nott.maths>
Subject: Apple ][ Kermit Comments
Keywords: Apple II Kermit
I've seen mentions recently in the Digest of Apple ][ Kermit, and I thought
I'd add my two penn'oth.
I have a rather battered Apple ][ Europlus, which I inherited with the
office, and am attempting to use a Kermit which announces itself as
"Stevens/CU-Apple ][ Kermit-65 ver 2.1a" (all in uppercase, as I'm working
with the naked original, without benefit of 80-column card or safety net),
which I pulled from Lancs last month and installed as per docs (but without
any bug patches not already in APPLEK.HEX). We are having several problems,
which are probably related.
1) When I attempt to transfer a file to the Apple, the name gets mangled,
consistently: "applek.hex" becomes "!00,%+.(%8", at least on my screen.
(Numbers and punctuation get through OK, but the resultant filename can
never be kosher, so all you can do with the received file is delete it with
FID.) This *only* happens when RECEIVEing or GETting files from a host
which sends the filename in lower case (in the F packet (?)). There's ways
round it, but it's messy, and had me short-circuited for quite a time.
2) When I do SHOW ALL, many of the responses show up as blanks: VT52, IBM,
LOCAL-ECHO, EIGHT-BIT-QUOTING, FILE-WARNING, and FILE-BYTE-SIZE.
3) Text files transfer from the Apple OK, and binary files appear to
transfer also, but turn out to be parity-stripped on arrival. (Note that
EIGHT-BIT-QUOTING and FILE-BYTE-SIZE are amongst those reported as blanks by
SHOW above.) Debugging refused to work as well, which is at best confusing.
On further investigation, it turns out that the binary image generated by
APPDXL from APPLEK.HEX ends somewhat further on than implied by the "save
file length" parameter L$4E00 used in the documentation. When I used the
slightly larger value L$5000, Problem (2) went away, and I've no doubt so
did Problem (3). (Should the docs be fixed, or just post a "beware" file?)
I've just yesterday pulled the A2 AppleDOS/ProDOS Kermit from Lancs, so I'll
let you know if Problem (1) has persisted into this version. In the
meantime, since the Stevens/CU APP Kermit is still around, I thought it best
that others profit by my blunderings.
Yours in plaster,
Bruised of Nottingham <majoc@maths.nott.ac.uk>
[Ed. - Thanks for the report, which we've added to the .BWR file for this
version. Meanwhile, any comments from users of any of the various Apple II
Kermit programs?]
------------------------------
Date: Tue, 12 May 87 09:03:31 EDT
From: Russell Nelson <bh01@clutx.bitnet>
Subject: Unix V.3 & kermit
Keywords: Unix System V.3
Have you heard anything about using kermit with Unix V.3? AT&T has a new
terminal driver (uugetty) for modem lines that does not work well with
kermit.
I've finally got 'cu' working. kermit dies because uucp owns the port.
I've tried changing ownership and protection on the port. cu or uugetty
keeps changing them back.
[Ed. - If users of Sys V.3 can supply details or fixes, we'll include them
in the next release of C-Kermit.]
------------------------------
Date: 15-APR-1987 15:18:59
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: VMS Kermit HELP files
Keywords: VMS Kermit
Any idea what's happened to VMSSYS.HLP and VMSUSR.HLP? They don't seem to
exist any more (people are asking me where the help info is on the new
TRANSFER command.....) Alan
[Ed. - I'm not sure what the difference is between them and the current
VMSMIT.HLP, but the old files you mentioned have been put back in the VMS
Kermit distribution, in hopes that someone will straighten them all out.]
------------------------------
Date: Wed, 13 May 87 10:42:36 GMT
From: CAPURSO@IBACSATA
Subject: Qkermit problems
We are linking our computing resources using kermit and all went ok
using Unix-kermit , CMS-Kermit , Ms-Dos kermit downloaded from Columbia.
But we had some problems using QKERMIT emulating TEK4010.
1 - we got QKMSTV.HEX, converted to QKMSTV.EXE
2 - we got source, recreated the overlay KERMIT.000
3 - we got QKVT1.TBL, renamed KEYTABLE.DAT
4 - we get an error when a graphical application starts writing:
TURBO GRAPHICS error #1 in procedure #0 . Press Return
we give RETURN and all goes ok. STRANGE ... ?
We read on QKMSTV.BWR that perhaps we need the file 4X6.FON . SURE ?
5 - we rebuilt KERMIT.000 using QKMSVT, because we DO have TURBO PASCAL
but NOT the graphical toolbox . Then, we renamed KERMIT.000 and all
went OK. We have the plots, but why don't you distribute also the
overlays? THANK YOU - MARIO
[Ed. - Your comments have been forwarded to the contributor, VIC@QUCDN.]
------------------------------
Date: Tue, 31 Mar 87 12:43 EST
From: JFisher@MIT-MULTICS.ARPA
Subject: MVS/TSO Kermit to work with Amdahl V7 & V8?
Keywords: MVS/TSO Kermit
We have two IBM/370 plug-compatibles (Amdahl V7 & V8) on which we have tried
the MVS/TSO Kermit from Toronto with indifferent success. We got it to work
on the V8 but not on the V7; the version on the V8 has twice died for
reasons uncertain/unknown. We are contemplating trying to adapt the NIH
version (which runs under MVS/XA)to our non-XA systems. We would GREATLY
like to communicate with anyone out there in the IBM world whose
configuration approximates ours, for exchange of information.
We run MVS 3.8, SP 1.3.4 ; the TP packages in the host are ACF/VTAM V2.1
and TCAM10. The TP front-end packages are ACF/NCP 2.1 (SDLC) and EP (2703)
(Async/Bisync).
If you are listening and would be willing to share your experiences, please
send mail to JFisher @ MIT-MULTICS.ARPA. Thanks in advance !
------------------------------
Date: Thu 14 May 87 00:16:01-EDT
From: Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>
Subject: Sending BREAK from Toshiba 3100?
Keywords: Toshiba 3100, BREAK
I ported MSKERMIT to my Toshiba 3100, but BREAK does not seem to work. Does
anybody have any experience with this problem? I am using the Toshiba internal
modem.
Michael
------------------------------
Date: Thu, 7 May 87 16:07 CST
From: <MCGUIRE%GRIN2.BITNET@CUVMB.COLUMBIA.EDU>
Subject: Is Kermit available for Digital VAXmate?
Keywords: VAXmate Kermit
Has anyone ported Kermit to the Digital VAXmate? The VAXmate is IBM
compatible, and includes MS-Windows. I can't find a way to bootstrap Kermit.
The standard package apparently does not include a language or the assembler.
Thanks in advance for any help.
Ed McGuire
Systems Coordinator
Grinnell College
MCGUIRE@GRIN2.BITNET
[Ed. - Since the VAXmate is IBM compatible, you should be able to execute
MS-Kermit directly from an IBM PC or AT Kermit diskette. If you don't have
a Kermit diskette, you should be able to use the "baby Kermit" in BASIC
(listed in the Kermit book) to bootstrap it (the VAXmate comes with BASIC,
right?). Reports about the operation of IBM PC Kermit on the VAXmate would
be most welcome.]
------------------------------
Date: Thu, 14 May 87 05:16:27 PDT
From: Ted Medin <MEDIN-T@SHARK.NOSC.MIL>
Subject: Kermit for Wang VS-100?
Keywords: Wang VS-100
We need a kermit for the wang vs-100 can anyone help us.
Ted
mailing address "medin@nosc.mil"
[Ed. - Many people have requested Kermit for Wang VS systems over the years,
but no one has ever volunteered to write one. Is there anyone out there who
might be equipped to do this?]
------------------------------
End of Info-Kermit Digest
*************************
-------
3-Jun-87 14:10:57-EDT,16159;000000000000
Mail-From: SY.CHRISTINE created at 3-Jun-87 14:10:24
Date: Wed 3 Jun 87 14:10:24-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #12
To: info-kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12307597157.167.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Wed, 3 Jun 1987 Volume 6 : Number 12
Today's Topics:
New IBM PC Kermit with Tektronix Emulation
QK-Kermit Answers
Macros for VAX/VMS EDT in MS-Kermit 2.28
Apple II Kermit Answers
Sending BREAK from Toshiba Lap Tops
UNIX V.3 & Kermit
IBM PC Kermit 2.29b Screen Color Bug
Handshake Bug in MS Kermit 2.29
Inconsistent Length of BREAK in MS-Kermit
Patches for HP-150 Kermit Problems
Kermit Has Made It To the Board Level
Does Perkin-Elmer Kermit Work?
----------------------------------------------------------------------
Date: Monday, 18 May 1987 15:37:59
From: BJH6@UK.AC.CAMBRIDGE.PHOENIX (BJH6%CAM.PHX@UK.AC.CAM.ENG-ICF)
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: New IBM PC Kermit with Tektronix Emulation
Keywords: Tektronix Emulation, MS-Kermit
I have developed an IBM TEK emulation for KERMIT, and am sending you the
.BOO file. The notes below are intended for a .BWR file - I have called the
version MSTEK.BOO.
This is a version of KERMIT 2.29 with a built-in Tektronix emulator. Please
note:
1. This version will work with IBM CGA graphics, or any software that emulates
it. It will not work with Hercules, but should work on an EGA card, but only in
CGA resolution.
2. The TEK emulation is not complete - in particular, the characters are IBM's
own character set and there is no MARGIN 1. All vectors should, however, be
correctly positioned in relation to one another, though the aspect ratio may
not be perfect. In addition, a cross-hair facility is provided. Use arrow keys
to move the cross-hairs, and SHIFT-arrow for faster movement.
3. TEK mode is entered from VT or other mode upon receipt of the sequence ESC
FormFEED (hex 1B 0C); you can exit from TEK mode either when ESC-US (hex 1B 1F)
is sent by the host, or by pressing the Kermit escape key (CTRL-], by default).
4. Please send any comments/problems to:
Brian Holley
Faculty of Economics and Politics
University of Cambridge
BJH6%CAM.PHX@UK.AC.CAM.ENG-ICF
[Ed. - Thanks, Alan, for passing this along, and thanks to Brian for
contributing his work. The .BOO file only, along with this message (no
source) is available in Kermit distribution as MSTIBT.*. Some alternate
versions of Tektronix emulation may also appear for IBM PC Kermit, and there
is some reason to hope that one of these may be incorporated into the next
real release, 2.30, although if new code keeps showing up at the present rate,
the next release may never see the light of day...]
------------------------------
Date: Thu, 21 May 87 16:53 EDT
From: VIC@QUCDN.BITNET
Subject: QK-Kermit Answers
Keywords: QK-Kermit
In response to the item about QK-Kermit in Info-Kermit V6 #11, all the problems
you mentioned are related to the use of the Graphic ToolBox and the use of
overlays. I have a new version of Qk-kermit which eliminates the use of the
Graphic Toolbox and overlays.
I will send this version off to Columbia as soon as I make sure that the CP/M
code will be compatable with the MS-DOS code.
Victor Lee (613)-545-2033
[Ed. - Thanks Victor! We will include it as soon as Columbia receives it.]
------------------------------
Date: Wed 1 Apr 87 12:23:47-EST
From: D. M. Rosenblum <DR01@TE.CC.CMU.EDU>
Subject: Macros for VAX/VMS EDT in MS-Kermit 2.28
Keywords: VAX/VMS EDT, MS-DOS Kermit
I finally wrote up some macros that let me get at VAX/VMS EDT in MS-DOS
Kermit 2.28 for the IBM-PC. (They may be totally inappropriate for other
keyboards.) Like actual Zenith-19 terminals, these emulate the EDT keys by
position, rather than by name. (I realize that 2.29 is doing VT100-family
support, but CMU isn't yet using 2.29, and I presume a lot of folks out
there still use 2.28 or earlier versions.) To use them, go into EDT change
mode, escape back to KERMIT, issue a DO SETEDT command, and connect back to
the VAX; then when you're done, after you exit EDT, escape back to KERMIT,
issue a DO CLEAREDT command, and connect back to the VAX. The documentation
of which keys do what is in the command file (at the end of this message).
By the way, the point that I made some time back about the kind of emulation
that I'd like to see is that I'd like to have MS-Kermit, if it's doing
Zenith-19 emulation, automatically do the user-defined macro SETEDT when it
receives an ESC = sequence from the host, and do the user-defined macro
CLEAREDT when it receives an ESC > from the host. (Of course, the names of
the macros don't have to be SETEDT and CLEAREDT, but the idea is that the
user should be able to define key settings to be invoked and revoked
respectively on receipt of ESC = and ESC >.) I believe that the VT100 uses
those same old VT52 escape sequences to get the alternate and normal keypad
(these are apparently different from the ANSI standards, which, according to
another source, are allegedly ESC [ > 7 h to go into alternate keypad mode
and ESC [ > 7 l to go back to normal keypad mode).
[Ed. - Yes, may people have requested such macro definitions. They have
been put into a file called KER:MSIEDT.INI.]
------------------------------
Date: Thu, 21 May 87 22:54:49 EDT
From: friedman@topaz.rutgers.edu (Gadi )
Subject: Apple II Kermit Answers
Keywords: Apple II Kermit
[Ed. - This is in response to the "Apple ][ Kermit Comments" in V6#11
from Martin J Carter.]
You'll probably get lots of replies, but.. Your problem (1), in which the
name gets mangled, is caused by the lack of a lower case display chip in your
apple. Without one, all lower case characters are displayed as symbols. If
you want to still use this kermit, (the newer one is MUCH better). You should
make sure your file names are upper case.
Gadi
ARPA: friedman@topaz.rutgers.edu
UUCP: {harvard, seismo, ut-sally, sri-iu}!rutgers!friedman
CMS: RUTGERS!SYSOP (CMS is DOWN. Long live CMS)
------------------------------
Date: Mon, 25 May 87 11:53:50 EDT
From: "Roger Fajman" <RAF@NIHCU>
Subject: Sending BREAK from Toshiba Lap Tops
Keywords: Toshiba, MS-DOS Kermit
> I ported MSKERMIT to my Toshiba 3100, but BREAK does not seem to work.
> Does anybody have any experience with this problem? I am using the Toshiba
> internal modem.
The Toshiba internal modem for the Toshiba 1100+ and 3100 does not transmit
break signals. Toshiba says that, yes, it works that way. A company called
Megahertz makes an internal modem for the 1100+ and 3100 called the T1200
that does send break signals. I have tried it for a short time and found no
problems. We just purchased an 1100+ with a T1200 modem, but the modem was
backordered. After it arrives, I will be able to say more. Inability to
send a break signal seems to be a fairly common problem among the cheap 1200
bps modems. I have encountered it several times before.
The address for Megahertz is
Megahertz Corporation
2681 Parley's Way, Bldg. 2-102
Salt Lake City, Utah 84109
Telephone: 800-33-TURBO
801-485-8857
I believe that the list price for the T1200 is $400.
[Ed. - In general, Kermit does not work with internal modems unless the
modem mimics the serial port exactly, or there is explicit code in the
Kermit source which knows about that particular internal modem. MS-DOS
Kermit 2.29B reportedly does work with Hayes and Hayes compatible full and
half-card internal modems, however.]
------------------------------
Date: 26 May 87 19:38:11 GMT
From: gatech!mcdchg!heiby@RUTGERS.EDU (Ron Heiby)
Subject: UNIX V.3 & Kermit
Keywords: C-Kermit
Russell Nelson <bh01@clutx.bitnet> says:
> Have you heard anything about using kermit with Unix V.3? AT&T has a new
> terminal driver (uugetty) for modem lines that does not work well with
> kermit.
>
> I've finally got 'cu' working. kermit dies because uucp owns the port.
It isn't the driver that's new. The program "uugetty" is a replacement for
"/etc/getty" that has knowledge of the same lock files that cu and uucp use.
Use of "uugetty" allows a port to be used as either incoming or outgoing on
demand, without administrator intervention.
One solution to Russell's problem is not to use "uugetty" on the line(s)
he wants to use kermit with. On a system with very few modems this is
pretty limiting. When I brought kermit up on my SVR3 system, I made the
kermit program suid to uucp. This allowed it to manipulate the lock files
and the port just fine. It seems, though, that kermit doesn't really expect
to be running suid, so this "solution" just creates a fairly large security
hole. (I turned off the suid bit when I found out.) As I mentioned in a
note a couple of weeks ago, the make target for "att3bx" is only used for
the HDB lock file protocol. Since uugetty is only available with HDB (as
far as I know), perhaps the same target and #define could be used to insert
code to deal with kermit running suid. My guess is that all that is needed
is a "setuid(getuid());" after the lock is created and port opened
successfully. Probably belongs shortly after the call to ttlock() in ttopen().
I haven't completely tested it, but this seems to work ok on my system. I
also had to comment out the call to access() that checks to see if the lock
directory is writable, as access() uses the real uid of the caller instead
of the effective uid, which is what we want. We then depend on the actual
creat of the lock file's return code to indicate a problem.
These changes might not be a bad idea for all UNIX versions of kermit.
Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix
"Small though it is, the human brain can be quite effective when used properly"
[Ed. - Thanks for the info. We'll try to do something about this in the
next release of Unix Kermit.]
------------------------------
Date: Mon, 18 May 87 15:52:37 edt
From: snorthc@nswc-g.ARPA
Subject: IBM PC Kermit 2.29b Screen Color Bug
Keywords: MS-DOS Kermit
If you set the color with the mskermit.ini to bright white on blue
(set term 1, 37, 44), the color will change during certain full screen
applications. We first discovered this with the 4BSD program more. The
color is fine until you press the space bar for the next segment of text,
then the text changes to dull white or grey on blue. We have an office
automation program called Office Power that causes the same color change.
Further information: We have reproduced these results on IBM ATs, Compaq
286s and Z-248s with various brands of EGA cards and monitors. If you press
the ESC-chr and then c and then another c, your color will be reset.
[Ed. - From JRD: snorth@nswc-g.arpa (no real name) today commented that
telling Kermit to use a Connect mode screen of bright white on blue (Set Term
Color 1 37 44) later resulted in ordinary white on blue as an application ran
on the host machine. This is correct since the host machine is sending a
command to set the screen that way. An escape sequence of ESC [ 0 m meaning
reset all video attributes does this. The difficulty regarding Kermit is that,
first it is running on systems which designate ordinary white to be a poor
light grey (yes, on my AT+ega+Multisync system too), and second the bold
colors still need to be under control of the host for other emphasis.]
------------------------------
Date: Thu, 21 May 87 14:46:42 MEZ
From: C0034008%DBSTU1.BITNET@wiscvm.wisc.edu
Subject: Handshake Bug in MS Kermit 2.29
Keywords: MS-DOS Kermit
I think I have found a bug in MSDOS-Kermit version 2.29 for IBM-PC. Our
configuration is an IBM PC/AT-02 connected via interface to an IBM /370 with
VM/SP Rel.4.
Using CMS-Kermit version 2.1 in the server mode everything was allright
except the GET command failed. But talking to the CMS-Kermit 3.1 server
mostly each command ended in the message 'Invalid server command'. Only the
REMOTE commands worked correctly. An observation with a linemonitor pointed
out that MSDOS-Kermit sends a NUL byte at the beginning of a packet.
Actually at the GET command it was the second packet which had a leading NUL
byte. Version 2.28 has not this bug ( but it is not as comfortable as 2.29).
Because I'm not a great programmer in MASM I added a condition to the outchr
routine in module msxibm, which skips if the character is a NUL.
Unfortunately now it is impossible to set padding char NUL.
Of course this isn't a satisfactory way and I hope that you can give me a
better solution to this problem.
Thank's in advance for you efforts
Matthias Brocks
[Ed. - This is a known bug of MS-DOS Kermit 2.29. The latest release
(2.29B) fixes the problem. It's in MSTIBM.BOO in the Kermit distribution.]
------------------------------
Date: Fri 22 May 1987 09:08:05 EDT
From: <SS@LL.ARPA>
Subject: Inconsistent Length of BREAK in MS-Kermit
Keywords: MS-DOS Kermit
I had problems with the break character on my COMPAQ 386 using MSKERMIT.
MSKERMIT for the IBM-PC and compatables uses an instruction loop to time the
length of a break character (based on the timing of a 4.77Mhz 8088) and the
faster the machine the shorter the break. I patched the assemly program to
calebrate the break on startup correctly.
Hope this helps with your problem.
[Ed. - The next release will generate BREAKs of constant duration,
independent of the CPU clock speed.]
------------------------------
Date: Thu, 21 May 87 11:59:41 EDT
From: uwvax!seismo!wucs1!wuphys!hpuslma!coalson@ucbvax.Berkeley.EDU
Subject: Patches for HP-150 Kermit Problems
Keywords: HP Kermit
I contacted Bill MacAllister who had mentioned a fix for 8-bit transfers
using kermit on an hp150 in msvhp1.bwr. The following is a dif of my
msxhp1.asm file after making the changes from a listing he sent me. I have
tried it as a local kermit and it seems to work. I haven't tried it with
the hp150 working as a remote kermit or as server.
[Ed. - The patch has been added to the file KER:MSVHP1.BWR and forwarded
to Joe Doupnik for the next release.]
------------------------------
Date: Wed, 27 May 87 11:49:03 EDT
From: rmcqueen (Robert C McQueen) @ sitvxb
Subject: Kermit Has Made It To the Board Level
Keywords: Terminal Emulation
According to the May 18th Network World:
AST Research, Inc. recently unveiled a 2 port terminal emulation board. The
board will do VT220 terminal emulation, and file transfer using the Xmodem
or Kermit protocols. The article states the board has an 80186 on it and
128kb memory. The board will handle 5 windows (2 VT220 sessions, a DOS
session and two notepads.).
Different.
Bob
------------------------------
Date: 20 May 87 15:24:38 GMT
From: msmith@gauss.rutgers.edu (Mark Smith)
Subject: Does Perkin-Elmer Kermit Work?
Keywords: Perkin-Elmer Kermit
Hi! Is there anyone out there that is successfully running Kermit in any
version on a Perkin-Elmer? Has anyone ever heard of anyone running it
successfully on a Perkin-Elmer. If so, please respond by E-mail to me or
call me at (201) 894-7732 between 9am and 4:445 pm EDT.
Thanks.
mark
[Ed. - Reportedly, the Perkin-Elmer Kermit versions work. Is there reason
to believe this is not the case?]
------------------------------
End of Info-Kermit Digest
*************************
-------
24-Jun-87 13:22:21-EDT,17514;000000000001
Mail-From: SY.CHRISTINE created at 24-Jun-87 13:21:37
Date: Wed 24 Jun 87 13:21:37-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #13
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12313093302.169.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Wed, 24 Jun 1987 Volume 6 : Number 13
Today's Topics:
Kermit Paper Newsletter V1 #2
QK-KERMIT Version 2.7 Tek4010 Emulation
New Commodore Kermit (version 2.0) files
DECmate CP/M Kermit fixes
F11 & 12 on new AT keyboards
Announcing MS-DOS Kermit 2.29C
Bugs in Apollo Kermit 2.8
Bug in Mac Kermit 0.8(034) Using 2-byte Checksums
Kermit with Tek emulation (MSTIBT.*)
Missing files for Apple II UCSD Kermit?
Apple 2e/CPM/Kermit?
Kermit for HPUX 5.1?
Unix Kermit in Background?
HP-150 Kermit?
----------------------------------------------------------------------
Date: Mon 15 Jun 87 12:21:33-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Kermit Paper Newsletter V1 #2
Keywords: Kermit Paper Newsletter
The Kermit Distribution group at Columbia University Center for Computing
Activities are in the process of preparing V1 #2 of the Kermit Newsletter
(V1 #1 appeared last July). In addition to giving the non-network-connected
world news about the latest Kermit versions, we'd also like to publish some
articles from Kermit users all over the world who are putting Kermit to good
(and possibly interesting or unusual) uses. We would be especially
interested in stories about how Kermit is used to somehow benefit humanity
(or other creatures), or to foster international cooperation, to make life
easier for the disabled, etc etc. For many, Kermit is used for mundane
purposes like saving money. We'd like to hear about that too. Although we
distribute Kermit programs to thousands of sites, and probably millions of
users, we get very little feedback on how Kermit is actually used. We'd
like to get this kind of news in any form, at any time, but if you'd like to
see it published in the Kermit Newsletter, please send it soon, and keep the
article fairly short (say 100-500 words).
Also, if anyone has any semi-technical general-interest contributions to make,
e.g. using Kermit over LANs, or through public networks, etc, these would also
be most welcome.
Whether you wish to contribute or not, you can be added to the subscriber
list by sending your mailing address to Info-Kermit@CU20B, or to Kermit
Newsletter, Columbia University, 612 West 115th Street, New York, NY 10025
USA. This process won't be necessary if you received the first issue, or if
you've ever ordered Kermit material from us by mail, in which cases you're
already on the list.
------------------------------
Date: Thu, 11 Jun 87 11:29 EDT
From: VIC%QUCDN.BITNET@wiscvm.wisc.edu
Subject: QK-KERMIT Version 2.7 Tek4010 Emulation
Keywords: QK-Kermit
An updated version of QK-KERMIT v2.7 which provides tek4010 emulation is now
available. This version does not require the use of Turbo Graphic toolbox and
it does not require overlays. Most of the problems, questions and difficulty
in using QK-kermit 2.6 were related to the toolbox and overlays, so this should
mean v2.7 should be a much easier simpler version to implement and use. Only
the CGA version is ready. Hercules and EGA versions will be coming later.
Victor Lee
(613)-545-2033
bitnet : VIC@QUCDN
[Ed. - Thanks, Victor! The new release is in KER:QK*.* on CU20B, available
with anonymous FTP, and on CUVMA as QK* * for BITNET KERMSRV access. The new
release includes IBM PC and Kaypro II support, Apple II support will come
a bit later.]
------------------------------
Date: Fri, 12 Jun 87 23:31:14 EST
From: "Ray Moody" <aij@j.cc.purdue.edu>
Subject: New Commodore Kermit (version 2.0) files
Keywords: Commodore Kermit
Two new files have been submited to CU20B for distribution.
C64V2.HEX is the hex file that everyone has been waiting for! It can
be de-hexed with C64DXL, which is the same program that de-hexes Kermit1.7.
Instructions are available in section 4.3 of C64KER.DOC.
C64V2.INI is a basic program that can be run to create a kermit.ini file
that will work with Kermit version 2.0. Most version 1.7 init files will work
with kermit V2, however, there are some that will not.
As always, I welcome suggestions for improvements and bug reports.
Ray Moody
ihnp4!pur-ee!j.cc.purdue.edu!aij
aij@j.cc.purdue.edu
moody@purccvm.BITNET
[Ed. - Thanks Ray! These files have been put in KER:C64V2.HEX and
KER:C64V2.INI available using FTP to CU20B, user ANONYMOUS (any password) or
through BITNET using KERMSRV. This message is in KER:C64V2.HLP.]
------------------------------
Date: 16 Jun 87 15:43:21
From: Charles J. Lasner (OC.LASNER@CU20B)
Subject: DECmate CP/M Kermit fixes
Keywords: DECmate Kermit
The latest version of KERMIT-80 for the DECMATE II, III, III-PLUS version of
CP/M-80 (version 4.05) will not properly work when attempting a connection
between the DECMATE and a remote half-duplex KERMIT such as CMS-KERMIT.
This is due to the default action of the 6120 processor within the DECMATE
which does all i/o for the Z80. All occurrences of XON/XOFF (aka <^S>/<^Q>
or DC1/DC3) are eaten by the 6120 for flow control purposes which is
normally not a problem.
When connected to a half-duplex KERMIT such as CMS-KERMIT, the XON (<^Q>)
character is used to formally turn around the line. Since the 6120 absorbs
all such characters, KERMIT-80 hangs when attempting this (retrying with
<CR> will actually work slowly!).
a/o this writing, this problem also exists with DECMATE II MS-DOS KERMIT, so
a work-around is imperative.
A partial fix is available in the files: CP4DMF.ASM, .HEX, and CP4DMU.ASM,
.HEX. Each program comes with a short help (.HLP) file to explain its
operation.
[Ed. - Thanks, Charles! The new files are installed in KER:CP4DMF.*
and KER:CP4DMU.* on CU20B for anonymous FTP access, and also on CUVMA
for BITNET KERMSRV access (as CP4DMF * and CP4DMU *).]
------------------------------
Date: Thu 18 Jun 1987 18:43:27 CDT
From: Mark S. Zinzow <Markz@Uiucvmd>
Subject: F11 & 12 on new AT keyboards
Keywords: MS-DOS Kermit
The program to activate scan codes in the Info-IBMPC Digest V6#45 works fine
with MS-Kermit 2.29B in allowing the definition of function keys F11 and
F12. If you don't already subscribe to I-IBMPC on our listserv, you can
find the digest on LISTSERV 193 in the file I-IBMPC 87-00052. The digest
entry is self explanatory, but for those who find downloading easier than
debug or MASM, I've put F11F12.COM on our kermit disk in binary form.
I would suggest executing F11F12 in your AUTOEXEC.BAT file so that it's
always installed when you wish to run kermit.
Then all you need to do is modify your 7171KEYS.DEF file. Here is an
example that I've tacked on the end of mine (7171ADD F11 on the kermit disk):
;
; Additional definitions for use with F11F12.COM
; PF11 assigned to F11
set key scan 133
\033-
; PF12 assigned to F12
set key scan 134
\033=
; PF21 assigned to shift F11
set key scan 647
\033o
; PF22 assigned to shift F12
set key scan 648
\033p
Some of you may prefer to redefine all the shift codes to PF13-PF24, but
I prefer to remain consistent with the 10 key definitions.
[Ed. - Thanks! The Kermit key definition mechanism will change in the
forthcoming release (2.30 -- see next message), but the mechanism for
activating the F11 and F12 keys may still be useful.]
------------------------------
Date: Mon 15 Jun 87 12:21:33-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing MS-DOS Kermit 2.29C
Keywords: MS-DOS Kermit 2.29C
MS-DOS Kermit 2.29C is now available for testing on the IBM PC, Zenith
100/200, the NEC APC III, HP-150, HP-110 and Portable Plus (untested), and
Grid Compass (also untested). A generic version is also available. The
.BOO files are in KER:MST*.BOO and descriptions of the updates can be found
in MSR29C.UPD. The sources are not yet available because they are still
undergoing last-minute revisions. Thanks to Joe Doupnik of Utah State
University for all his time and effort. Please test this version on your
system and report the results, so that we might be able to announce MS-DOS
2.30 soon.
------------------------------
Date: 8-JUN-1987 14:20:28
From: JDLee1@UK.AC.LOUGHBOROUGH.MULTICS
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Bugs in Apollo Kermit 2.8
Two problems/bugs that I have come across with apollo kermit 2.8 First, the
apollo seems to store ascii files with just a newline between records, and
apollo kermit 2.8 does not map newline into CR LF when sending files.
However it does the correct translation when receiving files. Second,
apollo kermit 2.8 does not correctly implement 8 bit prefixing. If the
other system says that it cannot 8 bit prefix it puts an N in the packet in
place of the 8 bit prefix character requested by apollo 2.8 This is wrongly
interpreted by apollo kermit as a request to use the N character as the
prefix character with the result that all N characters in the file become
Control-N at the destination file.
Tim Lee Pafec Ltd, Strelley Hall, Strelley, Nottingham
phone 0602 390649 ext 556
[Ed. - Thanks for the report. It's been added to the "beware file" for
Apollo Kermit. Any volunteers to fix and test it?]
------------------------------
Date: 10-JUN-1987 17:35:59
From: DB_WILSON@UK.AC.OPEN.ACS.VAX
Subject: Bug in Mac Kermit 0.8(034) Using 2-byte Checksums
Keywords: MacKermit
I have found a problem using Macintosh Kermit with two byte checksums when the
data packet can have bytes with the eighth bit set. The resulting checksum is
consistent with such bytes being negative in the range -128 to -1, i.e. bytes
are treated as signed -128..127 rather than unsigned 0..255. The Kermit book
makes it clear (c.f. page 224) that the latter is correct.
The workaround is easy - don't use two byte checksums for binary files.
Regards,
David.
[Ed. - Thanks for the report, which we've added to the Mac Kermit "beware
file." The problem will be looked at in the next release of C-Kermit.]
------------------------------
Date: Thu, 11 Jun 87 14:09 EDT
From: Walter Bourne <WMBSC@CUVMA>
Subject: Kermit with Tek emulation (MSTIBT.*)
Keywords: Tek Emulation
I have run into two problems with the Tek emulation. The first is that it
displays certain characters meant as padding. SAS/Graph, for instance,
sends a string of ^V's (hex 16) after the clear command. These appear as
small blocks half the normal character height across the top of the page.
The bell SAS rings at the end of the plot is also displayed as a triangle
pointing right. There are sometimes what looks like part of a Tek vector
command printed in the upper left after the bell.
The second problem is that it loses some data when filling large areas
solidly at higher baud rates (over 1800). SAS, running on an IBM CMS
system, apparently uses no handshaking and the close spacing of the vectors
doesn't allow the program to catch up during the move portion of the
command????
Walter Bourne,
Ass't Director
Center for the Social Sciences
420 West 118 St., Rm 814 SIA
New York, NY 10027
Tel: 212-280-3038
[Ed. - Thanks for the report, Walter. It's been forwarded to the developers
and added to the (previously nonexistent) MSTIBT.BWR file.]
------------------------------
Date: 17-JUN-1987 11:23:37
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Missing files for Apple II UCSD Kermit?
Keywords: Apple II Kermit
We need a version of UCSD Kermit on an Apple II for getting some files off an
Apple II onto a PC Clone. I've downloaded the sources, but can't track down a
copy of SYSTEM.ATTACH and ATTACHUD. Do you have these, or does anyone know
where they can be obtained?
Chris Murphy
Computer Centre
Oxford Polytechnic
[Ed. - Any users of UCSD Pascal Kermit on the Apple II out there who can help?]
------------------------------
Date: 15 Jun 87 19:48:08 GMT
From: samples@renoir.Berkeley.EDU (A. Dain Samples)
Subject: Apple 2e/CPM/Kermit?
Keywords: Apple II Kermit
I am having trouble getting kermit running. Any help would be appreciated.
My hardware configuration is
* Officially enhanced Apple 2e
* PCPI ``Starcard'' (Applicard) with Z80B
* Hayes Smartmodems (I have access to the 1200 and the 2400)
* SuperSerial Card
I got kermit off the simtel20 PD archives PD:<CPM.MODEM>CP405HEX.ARK (thanks
much to those who spend their time [and money?] keeping these archives
open!). Using the accompanying instructions I configured kermit for the
``generic'' CP/M system using the IOBYTE. Much to my surprise, it was able
to talk to the modem on the first try! (Magic is always surprising.) Much
to my disappointment, characters are being dropped. I cannot seem to get
the Hayes modem into its ``monitor'' mode to set registers, autodial, etc.,
and not every character I type at the keyboard is being echoed, and not
every character I type make the geblinken lights on the modem light up. It
looks like some sort of handshake or speed problem between the PCPI system
software and the SSC. At first I thought the Hayes and the Super Serial
Card were trying to talk at different baud rates, but a lot of messing
around and writing test programs convinced me this is not what is happening.
E.g., the SSC and the modem work fine under SmartTerm, but then they don't
under kermit. I thought maybe the Hayes Smartmodem 2400 was not being
initialized properly under kermit, so I tried the Hayes 1200 under kermit,
and it experiences the same problem.
I want to use kermit under CP/M since SmarTerm requires a re-boot and wipes
out my AE RamWorks ramdisk.
Any help would be much appreciated! What am I missing? Is there a Kermit
configuration overlay specifically for my configuration?
Mail to samples@berkeley.edu. If there is sufficient interest, I will post
a summary.
Thanks in advance,
Dain
A. Dain Samples, 573 Evans, UC Berkeley, samples@arpa.berkeley.edu
(All opinions expressed herein are mine, and do not reflect the opinions of
anyone that does not want them to.)
------------------------------
Date: 15 Jun 87 19:09:02 GMT
From: rochester!steinmetz!ebstokes@vdsvax..arpa (Stokes Edward B)
Subject: Kermit for HPUX 5.1?
Keywords: HPUX, Kermit
We have an HP 9836 (Series 200) microcomputer which is running HPUX 5.1
(hp's flavor of unix, basically system V). We would like to have a cheap
reliable interface to an Ultrix VAX via an existing RS232 line. CU works OK,
but doesn't do even the most simplistic checking of files that are
transferred. Does anyone have any experience with HPUX Kermit ? It does not
have the familiar "server" mode which is available in most versions,
consequently we've not had much luck making it work. Thanks in advance. Ed
Stokes
ebstokes@ge-crd.arpa
[Ed. - Regular C-Kermit 4D(061) is said to work under HP-UX if you build it
with the "sys5" option. However, it lacks support for some of the HP 9836
specific features, some of which may appear in the next release.]
------------------------------
Date: Wed, 17 Jun 87 11:40:38 PDT
From: dbercel@Sun.COM (Danielle Bercel, MIS Systems Programming)
Subject: Unix Kermit in Background?
Keywords: C-Kermit
Is anyone aware how to run Unix Kermit in the background? The version we
have here seems to want tty access and even though the commands are coming
from a script we cannot run it in the background.
Any suggestions?
danielle
UUCP: {hplabs,decvax,}!sun!toto!{danielle,dbercel}
COM: dbercel%toto@sun.com
ARPA: dbercel@sun.arpa
[Ed. - The -q option, given on the command line, is intended to "quiesce" the
tty and allow the program to run in the background, when invoked with a "&"
on the end of the command line.]
------------------------------
Date: Wed, 17 Jun 87 14:10 EST
From: Mark B. Johnson
Subject: HP-150 Kermit?
Keywords: HP-150 Kermit
Could anyone be so kind as to send us the HP 150 version of MS-Kermit on
diskette? We cannot transfer anything to the one here on campus due to an
outdated BASIC. We would be ever so grateful ...
Mark Johnson
Univ. of Notre Dame
[Ed. - This is a popular request. Does anyone know of an HP User Group that
we could submit a Kermit diskette to for distribution. In the near future,
there is a possibility that Kermit Distribution at Columbia will be able
to provide this service, but until then...... ??]
------------------------------
End of Info-Kermit Digest
*************************
-------
14-Jul-87 16:21:16-EDT,23547;000000000000
Mail-From: SY.CHRISTINE created at 14-Jul-87 16:19:31
Date: Tue 14 Jul 87 16:19:31-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #14
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12318368566.191.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Tue, 14 Jul 1987 Volume 6 : Number 14
Today's Topics:
Patched up MSTIBM.BOO (beta test) for testing
Update to Tek emulator for IBM PC Kermit
Announcing Kermit for Tripos systems
Announcing a New Acorn Version of Kermit
Announcing ICL 2900 VME Kermit Version 1.01
Announcing Kermit for the Harris H100-1 Running VOS
Announcing Kermit for the TI990 DX10
Kermit and the Toshiba 3100 Internal modem (2 messages)
Kermit for Mac II
MAC II and mailing list
Kermit on the MAC SE?
Unix Kermit in Background
Getting the files SYSTEM.ATTACH and ATTACHUD
Kermit for the RTE-6 OS?
Files Needed for the DG Nova Running RDOS?
Man page for BSD C-Kermit?
Vax to IBM 370 File Transfer
Help with C-Kermit on Cyber
C-Kermit Problem on a SUN 3/160
----------------------------------------------------------------------
Date: 28 JUN 87 17:31-MST
From: JRD@USU
Subject: Patched up MSTIBM.BOO (beta test) for testing
Keywords: MS-DOS Kermit
Following this note is the latest MSTIBM.BOO file which has fixes for
problems known to date and the added items: CTTY support, version banner on
file transfer display, errorlevel returns, auto-cleanup of Macros, retention
of full file statistics for last send, and Set Term Roll On | Off (default
is Off). Ident is 2.29C dated 27 June 1987.
Cured reported problems: Set Key in a Macro echos its status lines;
backspacing at the Set Key definition prompt crashed the system.
One cannot use the regular numeric keypad as a general dispatch area for
umpteen functions per key, just three per key is the limit. Suggest using the
Function keys for this purpose; they are designed to support four per key.
The Num Lock key does what it should, sets numeric mode; Shift can be added
on top to get a third function per key. Control-Break key combination is now
predefined to send a BREAK out the comms port, so does Alt-B.
When Kermit Pushes to DOS from within Connect mode Kermit sends a flow-off
character (XOFF), if flow control is active, to suspend the remote host and
later a flow-on (XON) character when resuming Connect mode. It does not do
this if the Push occurs at the Kermit prompt level since sending a stray
character at that time might wakeup a remote host or communications black
box when we were doing only local work.
Regards,
Joe D.
[Ed. - Thanks Joe! Those of you who are testing the new Kermit on IBM PCs
and compatibles (including PS/2s) are encouraged to grab the new version from
KER:MSTIBM.BOO on CU20B and try it out. The bug-reporting period will soon
be over.]
------------------------------
Date: 18-JUN-1987 09:47:32
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Update to Tek Emulator for IBM PC Kermit
Keywords: Tek Emulation, MS-DOS Kermit
Brian Holley has expanded his Tek emulator version of MS-Kermit 2.29 to
use CGA/EGA and Hercules cards, and also to run on Olivetti (M24??). The
files are KER:MSTIBT.BWR and KER:MSTIBT.BOO. This update to the BOO file
should cure the problem Walter Bourne reported in Info-Digest 13.
The latest version of the TEKtronix 4010 emulator for MSKERMIT has the
following facilities:
1. Support for: CGA, EGA, Hercules, Olivetti
2. To switch from one of the graphics facilities to another, use the command:
SET TERMINAL GRAPHICS xxx
where xxx can be one of CGA, EGA, Hercules, Olivetti
3. The line drawing algorithm writes direct to screen memory and is therefore
much faster than in the previous version; it will, however, almost certainly
cause problems under Topview, Windows or other windowing systems.
Please note:
4.The TEK emulation is not complete:
(a) characters are all based on an 8 by 8 matrix, giving 80 characters
across the screen (90 for Hercules), and 25 lines (CGA), 43 lines (EGA
and Hercules), or 50 lines (Olivetti). (A 4010 has 74 by 32)
(b) there is no MARGIN 1.
All vectors should, however, be correctly positioned in relation to one
another, though the aspect ratio may not be perfect. In addition, a cross-hair
facility is provided. Use arrow keys to move the cross-hairs, and SHIFT-arrow
for faster movement.
5. TEK mode is entered from VT or other mode upon receipt of the sequence ESC
FormFEED (hex 1B 0C); you can exit from TEK mode either when ESC-US (hex 1B
1F) is sent by the host, or by pressing the Kermit escape key (CTRL-], by
default).
6. Please send any comments/problems to:
Brian Holley
Faculty of Economics and Politics
University of Cambridge CB3 9DD
BJH6@UK.AC.CAM.PHX
[Ed. - Thanks, Alan! The new file is in KER:MSTIBT.BOO. Remember, this is
still "vanilla" 2.29, with Tek emulation added. Tek emulation probably will
not make it into 2.30, but here's something that can be used (at least on
IBM PCs with CGAs) till then.]
------------------------------
Date: 29-JUN-1987 10:14:55
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Announcing Kermit for Tripos systems
Keywords: Tripos Kermit
Here's a version of Kermit to run under the Tripos operating system (a high
portability system devised at Cambridge University, England, that has
appeared on various machines and is the basis of Amigados.). This version,
written by C.G.Selwyn of Metacomco Ltd, is in BCPL, based on the old C
Kermit from the Protocol Manual. There's no documentation for it,
unfortunately.
[Ed. - Thanks Alan. The source code can be found in KER:TRIPOS.* available
by FTP to CU20B, user ANONYMOUS (any password) or through BITNET using
KERMSRV.]
------------------------------
Date: 29-JUN-1987 10:14:55
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Announcing a New Acorn Version of Kermit
Keywords: Acorn Kermit, C-Kermit
This is the Kermit for the Acorn Cambridge Workstation, contributed by Acorn
Computers Ltd.
Users of this Kermit might like to know that it is available on disc from
Acorn at a cost of #50 to cover media and handling.
C-Kermit is a completely new implementation of Kermit, written modularly and
transportably in C. The protocol state transition table is written in wart,
a (non-proprietary) lex-like preprocessor for C. System-dependent primitive
functions are isolated into separately compiled modules so that the
program should be easily portable among Unix systems and also to non-Unix
systems that have C compilers. This document applies to Unix
implementations of C-Kermit, and in most ways also to the VMS
implementation.
[Ed. - Thanks for submitting this version Alan. The files are in KER:AC*.*.]
------------------------------
Date: 29-JUN-1987 10:14:55
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Announcing ICL 2900 VME Kermit Version 1.01
Keywords: VME Kermit
SWURCC VME Kermit Version 1.01
This version of VME Kermit is the standard version. If the communications
device for terminal connection to VME is an ASG, VME Kermit may not work.
This is because of a VME bug. Once this bug has been fixed the standard
version will run via ASG. If you find that VME Kermit will not run via ASG
please contact SWURCC for details of a modification to circumvent the bug.
David Lord (SWURCC)
[Ed. - Thanks David. The files have replaced the old ones in KER:VME*.*.
The old files have been placed in KO:VME*.* for now.]
------------------------------
Date: Tue 30 Jun 87 11:24:29-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for the Harris H100-1 Running VOS
Keywords: H100 Kermit
This program was written using Harris Fortran 77 on a Harris H100-1
computer (VOS 4.1.1 operating system) by Skip Russell, Division of
Biostatistics, Washington University in St. Louis (c04689sr@WUVMD.BITNET)
It was tested at up to 9600 baud against Columbia University's "MSKERMIT"
version 2.27 on an IBM PC/AT running DOS 3.0.
This version (1.04 April, 1987) added code to the first version to allow GETs
of file groups using the "?" wildcard character. The program was came out of
a need to transfer files between the aging Harris 100 and an IBM PC.
Skip Russell wrote this program especially for Harris computers which are
configured with a "MUX" as opposed to the more recent CNP or DMACP I/O
processors, since the Pascal-based Harris Kermit which was already in
existence does not accommodate such a configuration. As such, he has not
taken advantage of many of the special features offered by those devices
(notably timeouts and buffered I/O via "hot read"), but have opted instead
for simpler, albeit less efficient, modes of communication. In any case,
this program should work properly on a Harris machine in any configuration.
The files are in KER:H100*.*.
------------------------------
Date: Tue 30 Jun 87 11:24:29-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for the TI990 DX10
Keywords: TI990 Kermit
This version (1.0) of Kermit for the Texas Instrument DX10 was written by
Paul W. Madaus, Johnson Controls, Inc., 507 E. Michigan St., Milwaukee, WI
53201. His cover letter follows:
The Kermit source was originally designed to run on the Sperry(UNIVAC) 1100.
He has chosen to convert and implement this version of Kermit onto the
TI-990 DX10 systems. The conversion of system specific procedures was
straightforward, the basic protocol of the UNIVAC version was written in
standard Pascal, and of all the versions tested for conversion, the UNIVAC
version produced an acceptable amount of errors upon initial DX10
compilation (not a deciding factor - but very influential). Before
continuing further, he wishes to credit the original UNIVAC version (2.0) of
this program to:
Edgar Butt (last known address)
Computer Science Center
University of Maryland
College Park, Maryland 20742
His method of re-design will consist of removal or conversion of all UNIVAC
system dependent software, addition of a command parsing mechanism, addition
of interactive command control, addition of several new Kermit commands,
addition of simple tty type terminal emulation via connect cmd, addition of
remote as well as local Kermit execution, and addition of a Pascal XOR
function for 7th and 8th bit setting and resetting. This program makes use
of TI Pascal extensions but does not include any non-TI Pascal structures.
Program was compiled and linked at DX10 REL. 3.7.0 and DX10 Pascal REL.
1.8.0. THE TI Pascal configuration process was not used only for greater
simplicity and easier portability.
[Ed. Thanks Paul. The files have been placed in KER:TI9*.*]
------------------------------
Date: Tue, 30 Jun 87 11:19:39 EDT
From: "Roger Fajman" <RAF@NIHCU>
Subject: Kermit and the Toshiba 3100 Internal modem (more!)
Keywords: Toshiba 3100, Modems
I recently received the Megahertz T1200 internal modem for my Toshiba 1100+.
It seems to work fine with Kermit.
[Ed. - This is good news. See message below.]
------------------------------
Date: Mon 29 Jun 87 17:05:48-EDT
From: Christopher P. Lent <OC.PEDHEM@CU20B.COLUMBIA.EDU>
Subject: Kermit and the Toshiba 3100 Internal modem (more!)
Keywords: Toshiba 3100, Modems
RE: "Roger Fajman" <RAF@NIHCU> message in a former Kermit digest.
Well, there are two work-arounds and a solution for the Toshiba 3100
internal modem:
First the solution:
Toshiba has come out with replacement for the internal modem which DOES send
a break. A friend of mine got his replaced by Toshiba. Toshiba had him ship
his modem out and they sent a replacement. I've tested the new internal
modem card and it DOES send a break with Kermit 2.29A and 2.29B. It also
sends a break and a long break with Kermit-MS V2.29C (Development for 2.30)
7 Jun 87 . Also the Kermit HANGUP function works fine.
I imagine Toshiba's replacement policy is a "if you call, we MAY tell you
about it" type deal, but I would guess the most effective route would be to
call Toshiba directly.
The part number on my friend's box is: PA7438E B (is B for Break ? :-)
The Work-Arounds:
One workaround (which I have not tested) might be to set the baud rate down
to 45.5 and send a null (via CTRL-] 0). This should simulate a BREAK well
enough.
A second workaround is to get an external modem and use that. The integral
serial port on the T3100 does send breaks and handle the modem signals
properly.
Hope this helps,
Chris Lent
cbosgd!philabs!phri!cooper!chris
OC.PEDHEM@CU20B.COLUMBIA.EDU
------------------------------
Date: Fri, 26 Jun 87 21:02:06 PDT
From: dhare@Sun.COM (Dwight Hare)
Subject: Kermit for Mac II
Keywords: MacKermit
My version of Kermit, 0.8(34), immediately bombs on my new Mac II.
Is there a version of Kermit which runs on the Mac II?
Dwight Hare
dhare@sun.com
[Ed. - Reportedly, MacKermit 0.8(34) works on the Mac II. Comments?]
------------------------------
Date: Sun, 5 Jul 87 18:54:57 pdt
From: Alex Woo <woo@ames-pioneer.arpa>
Subject: MAC II
Keywords: Mac Kermit
I recently purchased a MAC II and discovered that the SUMEX version
of Kermit 0.8 failed to even startup. Is there an updated version?
Thanks
Alex Woo, MS 227-2 | wu@ames-aero.arpa
NASA Ames Research Center | woo@ames-nas.arpa
Moffett Field, CA 94035 | {seismo,topaz,lll-crg,ucbvax}!
Phone: (415) 694-6133 | ames!pioneer!woo
{hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!pioneer!woo
[Ed. - We had earlier reports that Mac Kermit worked OK on the Mac II and
the Mac SE. What could be the hidden factor that makes it work for one
person but not another? Anyway, there will soon be a new release of Mac
Kermit that can be compiled directly on the Mac under Megamax C, so that
Macintosh wizards can start finding and fixing problems. Watch Info-Kermit
for announcements.]
------------------------------
Date: Tue 30 Jun 87 11:24:29-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Kermit on the MAC SE?
Keywords: MacKermit, VAX/VMS Kermit
"rozycki%thebay.dec@decwrl" is trying to use MacKermit 0.8(34) on a MAC SE
to communicate with a VAX/VMS system running Kermit 3.3.111. It is a direct
connection using a printer cable. A connection can be made but file
transfer is not successful. Various parity settings have been tried. Has
anyone has a similar experience?
------------------------------
Date: Tue, 30 Jun 87 15:17:16 BST
From: Gordon Scott <seismo!mcvax!mfmail!gas@columbia.edu>
Subject: Unix Kermit in Background
Keywords: C-Kermit
In response to the query about running Unix Kermit in background
(Info-Kermit Digest V6 #13 ) there are a few other things to note as well as
using the -q flag.
-q appears to have no effect on some of the output from the script module
and to get round that one I generally just redirect the standard output.
Another point is that the documentation about errors in take files being
fatal in background is wrong for 4C(061), although it was correct in
4C(057).
It also took me a while to realise that protocol timeouts are not fatal to
the job in background - kermit will keep retrying for a while and then go on
to the next command.
Gordon Scott
Micro Focus Ltd
(mcvax!ukc!mfmail!gas)
[Ed. - Thanks for the comments; these problems should be fixed in the next
release of C-Kermit.]
------------------------------
Date: Sun, 28 Jun 87 22:32:00 pdt
From: hplabs!cae780!amdcad!ames!well!samlb@ucbvax.Berkeley.EDU
Subject: Files SYSTEM.ATTACH and ATTACHUD for Apple II UCSD p-System Kermit
Keywords: Apple II, UCSD p-System
In article <12313093302.169.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Chris writes:
>SYSTEM.ATTACH and ATTACHUD. Do you have these, or does anyone know
>where they can be obtained?
>
>Chris Murphy
>Computer Centre
>Oxford Polytechnic
Both are available from the International Apple Corps in Daly City,
CA, USA -- and probably from his local Apple User Group in England . . .
Sam'l Bassett, Semantic Engineer -- My words & ideas are for sale!
34 Oakland Ave., San Anselmo CA 94960; (415) 454-7282
UUCP: {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb;
Compuserve: 71735,1776; WU Easylink ESL 6284-3034; MCI SBassett
------------------------------
Date: 28 June 87 21:33-EST
From: MLCARSON@MTUS5
Subject: Kermit for the RTE-6 OS?
Keywords: RTE Kermit
I'm looking for a version of Kermit that will work on the RTE-6 operating
system with a HP12966A interface using a DVA05 driver. We have three such
interfaces: one for a HP2645A terminal, one for a HP2622A terminal, and one
that is shared by a PC and another HP terminal via 1200 baud modem. I have
a version of Paul Schumann's Kermit but I believe it requires either a
12040B/C or 12792B/C multiplexer. I can't even try this Kermit because its
on a 5.25" PC formatted disk. I can't just upload it to the HP editor
because of the ENQ/ACK protocol that is taking place. Is there anyway of
getting around this? If there is a Kermit out there that works, how do I
get it on the HP? Could you please help me with this problem or point me to
someone who could? It would really be appreciated. Thank you.
------------------------------
Date: 1-JUL-1987 10:23:05
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Files Needed for the DG Nova Running RDOS?
Keywords: DG Nova Kermit
It's been pointed out to us that the files for Kermit in Fortran-5 for DG
Nova machines running RDOS (prefix RDO) are incomplete. There are include
references to SETSETUP.FR and F5ERR.FR, and these files aren't in the set,
and what they may contain isn't obvious.
Does anyone know what's in the files, or has anyone got copies?
Alan Phillips
[Ed. - These are probably DG files that come with DG Fortran. Anyway, the
person who contributed the Fortran version of RDOS Kermit is long gone.
The forthcoming release of C-Kermit will support DG C environments; it has
been tested on AOS/VS, but not RDOS, however the C environment is supposed
to be consistent across all the DG product lines.]
------------------------------
Date: 6 Jul 87 18:29:01 GMT
From: hao!boulder!sigi!tag@RUTGERS.EDU (Tinsley A. Galyean)
Subject: Man page for BSD C-Kermit?
Keywords: C-Kermit
I am looking for a man page for the latest version of C-Kermit BSD.
C-Kermit, 4D(061) 8 Sep 86, 4.2 BSD
The source I have did not have a man page with it. If you have one that you
wrote yourself or otherwise found would you please mail me a copy.
Thank You
tag
tag@boulder.colorado.edu (CSNET or ARPANET)
...!{nbires,hao}!boulder!tag (UUCP)
[Ed. - The man page, such as it is, is in KER:CKUKER.NR on CU20B, and comes
with C-Kermit in the normal distribution.]
------------------------------
Date: Wed, 08 Jul 87 11:16:58 EDT
From: "Bob Klein" <KL2@NIHCU>
Subject: Vax to IBM 370 File Transfer
Keywords: VAX/VMS Kermit, TSO Kermit
A user at our site is trying to transfer a file from a Vax (under VMS 4.5)
to our IBM 3090 running MVS using Vax Kermit 3.1.066. He can set up the
connection but can't even get the transfer started. I noticed in the
Info-Kermit Digest V6 #9 that there is a new release of VAX/VMS Kermit
(3.3.111) which contains bug fixes for among other things IBM mainframe
communications. Does anyone have any experience doing file transfer between
a Vax and a 3090 (or other 370 model) running MVS. The version of Kermit on
our mainframe is NIH TSO Kermit. Thanks in advance for any pointers.
------------------------------
Date: 24 Jun 87 15:40:00 MST
From: <darieb@sandia-2.arpa>
Subject: Help with C-Kermit on Cyber
Keywords: C-Kermit, Cyber
I am attempting to put CKUKER onto the CDC NOS VX/VE system. This (hybrid)
system is supposed to be SVID compatible. I can get the makefile to work
just fine with "make sys3" or "make sys3nid" as the instructions say. When
I execute ("wermit"), the prompts seem to be missing carriage returns and/or
line feeds (e.g. the help ("?") directive produces a list which does not
line up, and seems to be going off the page 'til wraparound.) This makes
output hard to read.
Even worse, the input seems to have a one-character buffer... typing
anything causes Kermie to interpret each character as if it were the full
command. Trying "server" will get 6 errors, one for each letter which is
either an illegal command or not long enough for Kermit to distinguish which
particular command is being requested. The only things which work are helps
("?", "h") and a few of the other commands uniquely determined by one letter
and requiring no other argument.
I am not a C or UNIX guru, but am learning at a regular pace. I've tried
stabs in the dark by having ckutio use ICANON for tty and console lflag
values -- but I really don't know what's happening. I fear that the strang
CYBER environ- ment of UNIX (called VX) sitting atop NOS/VE which is
dual-mode with NOS may be doing very strange things to I/O. The local CDC
VX/VE expert is stumped.
HELP! Anybody have a similar problem?
Declan A. Rieb
Sandia National Laboratories, Division 2614
Albuquerque NM
Phone: (505) 844-6338
DARIEB@SANDIA-2.ARPA
------------------------------
Date: 8-JUL-1987 10:05:25
From: V Paramananda (PS) <ananda@uk.ac.ucl.cs>
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: C-Kermit Problem on a SUN 3/160
Keywords: C-Kermit
We are having trouble with a version of C Kermit installed on a Sun 3/160
workstation within the Department of Photogrammetry and Surveying at UCL. It
appears impossible to get the system set up as a virtual terminal so that
that it can initiate transfers from other Kermits, in this case a VAX within
UCL. We can set up the line /dev/ttyb on thisd Sun without any apparent
problems. However, when the line is connected there is no response from
remote hosts at the other end of the line. It is unlikely that the hardware
is a fault, as the UNIX utility function 'tip' is able to establish
connections without problems.
Could you please reply to:
oneill@uk.ac.ucl.cs
Thankyou,
Mark O'Neill,
Dept of Photogrammetry and Surveying
UCL,
Gower Street,
Londow WC1E 6BT UK.
Tel: 01-387-7050X2743
------------------------------
End of Info-Kermit Digest
*************************
-------
28-Jul-87 14:33:21-EDT,21024;000000000000
Mail-From: SY.CHRISTINE created at 28-Jul-87 14:32:07
Date: Tue 28 Jul 87 14:32:07-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #15
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12322019030.199.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Tue, 28 Jul 1987 Volume 6 : Number 15
Today's Topics:
Reorganization of Files on Kermit Tapes
Announcing Kermit68K, a Portable 68000 Kermit Program
A New MSTRMX.* Available
MacKermit 0.8(34) on the Macintosh II (4 messages)
7171 MSKERMIT.INI for MS-DOS 2.29C Kermit
Problem with C-Kermit on SUN
Binary File Transfers
Time Loop for Prompts in Script Files
MSKERMIT for the DEC Rainbow
Bootstrap version of Kermit-CMS 3.1
Portable Kermit for IBM 370's
VMS Kermit Buffering Problem
----------------------------------------------------------------------
Date: Mon 27 Jul 87 12:52:37-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Reorganization of Files on Kermit Tapes
Keywords: Kermit Tapes
Due to the recent influx of new Kermit versions, Kermit Distribution has grown
from 3 to 5 tapes. Tape A still contains the more popular microcomputer (PC,
workstation) Kermit implementations; Tape B still contains the more popular
mini and mainframe Kermit implementations (IBM mainframes, C-Kermit, DEC OS's,
etc); Tape C contains additional micro versions (overflow from Tape A); Tape D
contains additional mini and mainframe versions (overflow from Tape B); and
Tape E contains machine readable copies and text formatter source for the
Kermit User Guide, Protocol Manual, and Byte Article and other large documents,
including old mail archives. Apologies for any inconvenience this might cause
to tape customers. Those who access Kermit files by network should notice no
difference.
------------------------------
Date: Sat, 18 Jul 87 12:26 N
From: <BAGNARA@IBOINFN.BITNET> (Roberto Bagnara)
Subject: Announcing Kermit68K, a Portable 68000 Kermit Program
Keywords: 68000, Motorola 68000, OS-9
I'm very pleased to announce that, after 1 year of work, the OS9/68000 version
of Kermit68K pre-release 1.0.00 is ready to be distributed.
Kermit68K/OS9 is an implementation of Kermit68K for microcomputer systems
running the OS-9/68000 operating system from Microware. Kermit68K is patterned
after UNIX C-Kermit, however it is written completely in Motorola 68000
assembly language to allow easy portability to 68000 based systems without C
compilers. The OS-9 system specific modifications were performed by Steve
Williams of the Electrical and Computer Engineering Department at the
University of Texas at Austin.
Kermit68K has been designed and written to be (among other things) portable.
This means that it can be implemented on any 68000 based machine with any
operating system (really also on machines without an operating system).
Furthermore (being highly modular, ROMable etc.) it is suitable for
nonstandard, specific applications (e.g. automatic data transmission from a
remote acquisition station to a database host computer).
I hope, by pre-releasing Kermit68K at this time, to involve experts of other
operating systems/machines. People willing to try other implementations of
Kermit68K (for example under UniFLEX, PDOS, VERSADOS, CPM/68K etc.) shouldn't
hesitate to contact me at any time. The type and amount of work necessary is
deducible by reading the distribution file K6GSYS.ASM (the only system
dependent module).
Finally I want to remind the potential users of Kermit68K/OS9 that we, I and
Steve, need a strong feedback; there are many things to test and correct.
Furthermore I'm continuously upgrading the program and I should take many
decisions, so users suggestions will be very useful to me. Please, feel free
to contact me at any time. Cordially,
Roberto Bagnara
Ordinary Mail: Roberto Bagnara
Physics Department
Bologna University
via Irnerio, 46
40126 BOLOGNA
Italy
Bitnet: Bagnara@Iboinfn
DECnet: 39937::BAGNARA
Arpanet, Usenet: bagnara%iboinfn.bitnet@wiscvm.wisc.edu
[Ed. - Many thanks Roberto! The files are in KER:K6*.* avaialable via ARPAnet
by FTPing to CU20B, user ANONYMOUS (any password) or through BITNET using
KERMSRV.]
------------------------------
Date: Monday July 27, 1987 12:57 PM PDT.
From:<JAFW801%CALSTATE.BITNET@wiscvm.wisc.edu>
Subject: A New MSTRMX.* Available
Keywords: MS-DOS RMX Kermit
This is to announce the test release of version 2.29C of Kermit for both the
RMX86 and RMX286 Operating Systems. Relevant files are MSTRMX.BOO, for RMX86,
and MSTRX2.BOO, for RMX286, MSTRMX.DOC, and MSERMX.P86.
[Ed. - Thanks to jafw801%calstate.bitnet@wiscvm.wisc.edu for sending these
.BOO files. The are in KER:MSTRMX.BOO and MSTRX2.BOO. Please try them out
and send reports to Info-Kermit@CU20B.]
------------------------------
Date: Tue, 21 Jul 87 16:53 EDT
From: MLM@PITTVMS
Subject: MacKermit on the Macintosh II
Keywords: MacKermit
Is there a Kermit for the Macintosh II? We have tried Macintosh Kermit
version .8(34) with the system crashing.
Mark Medice, Academic Computing, Univ. of Pittsburgh.
[Ed. - See messages below...]
------------------------------
Date: Thu, 23 Jul 87 13:22 EDT
From: <LUIS@YULIBRA.BITNET>
Subject: MAC II Kermit Problems.
Keywords: MacKermit
Does anyone have a version of Mac Kermit for the Mac II? It seems that
the current version 0.8(34A) Oct/85 starts to load but then the standard
restart error message appears.
Also, is there a version of the program to define the new keyboard for the
Mac II?
Thanks in advance to anyone that posts an answer.
Luis Strauch
York University
Toronto, Canada
BITNET: LUIS@YULIBRA
[Ed. - See messages below...]
------------------------------
Date: 15 Jul 87 01:37:24 GMT
From: jww@sdcsvax.ucsd.edu (Joel West)
Subject: Kermit & Mac II (V6 #14)
Keywords: MacKermit
The only thing that obviously affects one Mac II and not the other is the
Monitors setting. Some programs that get fancy blit directly to bitmaps but
I doubt MacKermit 0.8 does this.
0.8 (34) crashes nicely (with 2-bit monochrome pixmaps) about 10 subroutine
calls deep on the stack frame.
Megamax C has a problem with System 4.1, incidentally, although a new
release may fix this. However, I hope that the released version will be
compatible with either MPW C or LightspeedC, as these seem to be the two
most popular implementations nowadays. I would say MPW is probably the
preferred compiler for large jobs but you're more likely to find volunteer
workers who have Lightspeed.
MPW provides Megamax-style C string conversions if you want it, while
LightspeedC has 16-bit ints like Megamax. Converting either one shouldn't
be too bad, although the Lightspeed code generation won't be
68020-compatible until the next release (due Real Soon Now).
Joel West, Palomar Software, Inc. (c/o UCSD)
{ucbvax,ihnp4}!sdcsvax!jww or jww@sdcsvax.ucsd.edu
[Ed. - The new release will indeed be Megamax, but volunteers to convert
to MPW or Lightspeed will be gratefully accepted!]
------------------------------
Date: Mon, 20 Jul 87 14:09:03 EDT
From: Charlie C. Kim <cck@cunixc.columbia.edu>
Subject: Mac Kermit and Mac II
Keywords: MacKermit
MacKermit works on a Mac II; however, the Sumacc C compiler runtime
library does not. Unfortunately, the current version of MacKermit is
built with the Sumacc C compiler. The problem is the traps and calls
to various in-rom/ram packages on the Macintosh are built in-line, on
the stack as I remember, by the Sumacc C compiler runtime libraries.
This doesn't work too well on a 68020 based system like the Mac II
because the 68020 has an instruction cache.
If you are willing to live with a (moderate) performance degradation,
simply turn off the instruction cache with following MPW asm program:
Machine MC68020
nocache main
clr.l d0
movec d0,cacr
rts
ENDP
end
Simply "restart" your machine to turn the cache back on.
Charlie C. Kim
User Services
Columbia University
Here's the corresponding compiled program in binhex 4.0 format:
---------------- CUT HERE ----------------
(This file must be converted with BinHex 4.0)
:#@j[)'PMB@0SC3""8&"-2j!%!*!)!@qqk!#3"!%!N!-",!#3!b`!N!0$!4JQEJ!
@)'hkZL*Z!!J`%8'm(rrP3#K`!!!H&!*(!2m#H#i!!J#3!d&38%`rN!3!N!S*R`#
3"N&38%`rN!3!N"LG*p!U!*!'!@m"DN(ZrIBI%$mm!2p1V3&53qlqpR"!)YK63'l
k3QG"l[lf,`J[,J!12bi!$%KZrrj1Z[ib%"pR%MmZrri[,J!),bi!%NkY!(*J$%*
R,bi!##m,6Ud!FNcI')"1AL"Ih[`!%Nl3d&*23d968dm!N!3,SJ9J!!j19[cq)'i
!#%2Zr`#3""J!N!-S!!!#!*!%#!#3!b!!!$mm!!'Tm!#3!``!N!-"F!"1H`!#6R8
!!!%!N!-",!#3!b`!N!0$!!,Sk!AL!*!$(!!q!!"$6d4&!!%!#J!!rrmJ!*!)!3!
!&!!!(!!#k'`%6@&TE[M5!:
[Ed. - Thanks Charlie! This message has also been added to the CKMKER.BWR
file.]
------------------------------
Date: Thu 16 Jul 1987 11:12:40 CDT
From: Mark S. Zinzow <Markz@Uiucvmd>
Subject: 7171 MSKERMIT.INI for MS-DOS 2.29C Kermit
Keywords: MS-DOS Kermit, Protocol Converters, .INI Files
I have finished translating the MSKERMIT.INI file to 2.29C and
got the typos out.
[Ed. - Thanks, Mark! For now, the file is in KER:MSI71C.INI. We'll have to
find some better naming scheme... This file should go a long way towards
helping the many people who are confused by the new key redefinition syntax.]
------------------------------
Date: 8-JUL-1987 10:05:25
From: V Paramananda (PS) <ananda@uk.ac.ucl.cs>
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Problem with C-Kermit on SUN
Keywords: C-Kermit
We are having trouble with a version of C Kermit installed on a Sun 3/160
workstation within the Department of Photogrammetry and Surveying at UCL. It
appears impossible to get the system set up as a virtual terminal so that
that it can initiate transfers from other Kermits, in this case a VAX within
UCL. We can set up the line /dev/ttyb on this Sun without any apparent
problems. However, when the line is connected there is no response from
remote hosts at the other end of the line. It is unlikely that the hardware
is a fault, as the UNIX utility function 'tip' is able to establish
connections without problems.
Mark O'Neill,
Dept of Photogrammetry and Surveying
UCL,
Gower Street,
Londow WC1E 6BT UK.
Tel: 01-387-7050X2743
[Ed. - Many people are using C-Kermit on SUNs to communicate with VAXes.
We'd need more information before we could diagnose the problem -- exactly
which version of C-Kermit are you running? Exactly how are you connected
- direct line, modem, local net, ...? Are there any error messages?
Meanwhile, could someone who is successfully using C-Kermit on a SUN please
pass along any hints?]
------------------------------
Date: 15 Jul 87 16:35:52 GMT
From: tjh+@andrew.cmu.edu (Tom Holodnik)
Subject: Binary File Transfers
Keywords: Binary Files
In Frank da Cruz' Kermit reference, he states that the command "set
file type binary" issued at both ends will enable encoding of binary data
streams into ascii characters.
In all the versions of Kermit I have seen (Kermit 2.29, C-Kermit 4D(061)), this
option is unavailable. The reference states that this facility may not be
available on every version, but I was wondering what versions of Kermit it was
available for, and whether there were any plans to incorporate it into future
versions for the PC, or for Unix systems.
I'm sure that it may be simple to implement this into the CMU version of
Kermit, but it makes sense to have some standardization, eh?
Thanks,
Tom Holodnik
Carnegie-Mellon University
[Ed. - You're confusing a couple issues. SET FILE TYPE BINARY means that
no representation-level data conversion will be done -- no ASCII/EBCDIC
translation, no conversion of line terminators from one system to another,
etc. In other words, the bytes of a file are sent as is. The default is
mode for file transmission is TEXT, in which files are represented as
streams of ASCII characters, with lines (records) delimited by CRLFs. Now,
after these conversions are done, Kermit encodes data for transmission.
First, all nonprintable characters are converted to prefixed printables.
For instance, Control-M becomes #M. Second, if parity is in use on the
communication line, a second printable prefix (normally &) is inserted before
any byte whose high order data bit is 1, so &#M would be the encoding for
binary 10001101 (Ctrl-M with its 8th bit on). All Kermits do the control
prefixing, whereas 8th bit prefixing is an optional and negotiated feature.]
------------------------------
Date: 20 Jul 87 20:47 EST
From: chang%england.tcpip@ge-crd.arpa
Subject: Time Loop for Prompts in Script Files
Keywords: Script Files
I'm a summer intern at GE's Corporate Research and Development in Schenectady,
New York. I've been working on a script file to automatically upload a file
from the pc to the mainframe.
I'm a little frustrated with the time loop requirement for the anticipated
prompts. Is there some way that the next command in the script file be
executed upon seeing the anticipated prompt? Right now, I've something like
"INPUT 15 Enter Access Code"; and depending upon the time specified, the
waiting period will vary up to the specified time even though the anticipated
might have appeared before 15 seconds or the specified time has elapsed.
Thanks,
Ben
[Ed. - There must be something wrong. If MS-Kermit encounters the input
string, it proceeds to the next command right away. Therefore, it must not
be matching the string. Maybe parity is the culprit?]
------------------------------
Date: Mon, 20 Jul 87 14:43:05 EDT
From: "James J. Steiner" (CCL) <steiner@ARDEC.ARPA>
Subject: MSKERMIT for the DEC Rainbow.
Keywords: DEC Rainbow Kermit
Does anyone have experience with the enhanced MSKERMIT for the DEC Rainbow
100 written by David Knoell. I down loaded a copy two months ago and found
that it doesn't work as described in its documentation. Particularly the
'print controller' escape sequence doesn't work. also the information in
the help screens status doesn't agree with the information shown when you
use the status command. This is a very fine program otherwise but I often
use screen bypass printing provided by the 'print controller' sequence in
the Rainbows native vt100 mode.
Thanks,
Jim Steiner
steiner@ardec.arpa
(201) 724-6066
------------------------------
Date: 1987 Jul 22 13:21 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Subject: Bootstrap version of Kermit-CMS 3.1
Keywords: CMS Kermit, TSO Kermit, Portable IBM Kermit
With the release of Kermit-CMS 3.1 it became possible to choose a bootstrap
form of the program that loads Kermit into free storage and permits
execution of any and all user programs underneath Kermit. However, I know
of one user who consistently found the bootstrap program to halt with a
message claiming a lack of storage. I have finally traced the problem to
the length of his GLOBAL list of TXTLIB's, but before I do anything else
about it, I would like to know:
1. Has anybody besides me and this one other user tried out the bootstrap
form of Kermit-CMS? The module is only about 400 bytes long and is
accompanied by a TEXT file. The difference in operation is that the
bootstrap version will execute user-area CMS commands (e.g., COPYFILE)
while the traditional form will not.
2. Has anybody who tried out the bootstrap version encountered problems
like the one I described (error message DMSLIO109S VIRTUAL STORAGE
CAPACITY EXCEEDED, followed by return code 108)? Any other problems,
for that matter?
John
------------------------------
Date: 1987 Jul 23 20:15 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Subject: Portable Kermit for IBM 370's
Keywords: CMS Kermit, TSO Kermit, IBM 370 Kermit, Portable IBM Kermit
There is a new development in Kermit for the IBM 370 architecture,
namely, a generic Kermit. The new Kermit is descended from the original
Kermit-CMS 1.0, but it differs from its cousins in that the system-
specific functions (such as disk I/O, system interaction, and terminal
I/O) are segregated into a separate section of code.
The initial implementation (the CMS version) has been completed and
tested, and a preliminary TSO version has been written. When the latter
has been debugged, it can replace all of the existing TSO Kermits (by
virtue of supporting both line-mode and Series/1-type terminals, as well
as offering most capabilities supported by Kermit-CMS 3.1, plus many
more.) The hitch is that debugging the TSO version requires someone
with access to a TSO environment. Anyone wishing to help bring the new
TSO Kermit to completion (and thereby acquiring it soon) should send me
a note, either by E-mail or post. For that matter, anyone wanting to
port Kermit-370 to any other operating system should do so as well.
BITNET: PEPMNT@CFAAMP
Internet: PEPMNT%CFAAMP.BITNET@WISCVM.WISC.EDU
Post: John F. Chandler
Center for Astrophysics M/S 63
60 Garden St.
Cambridge, MA 02138
[Ed. - Volunteers, please! Our disks are becoming choked with alternate
TSO Kermit versions -- this one for 3705s, that one for Series/1, another
for 3708, etc etc.]
------------------------------
Date: Thu, 23 Jul 87 12:10 EST
From: JOHNSON <@cis.upenn.edu:JOHNSON@nbc.upenn.edu>
Subject: Kermit Buffering Problem
Keywords: VAX/VMS Kermit
I am a Kermit user and would like to ask you for help with a specific
problem. Can anyone help with a buffering problem we are having when using
Kermit to connect to an out going line from a VAX 11/750 to a University-
wide network at the University of Pennsylvania.
Kermit (version 3.2.076) is installed on our system. The University of
Pennsylvania has installed a fiber optic network throughout the University
with a T-1 phone link from the network to New Bolton Center where we are
located. ( The campus at New Bolton Center (NBC) is located about 40 miles
from Philadelphia and serves as the center for large animal teaching and
research for the Vet School of the University.) The NBC campus has been
provided with fiber optic links to the main buildings on the NBC campus.
Currently, three systems are connected to the network, the VAX 750 is one of
them. Because it is not possible to provide direct network access to all
users at NBC, I would like to give our VAX users access to the network
through the VAX.
Connecting to the network through Kermit has been no problem; however,
buffer overruns prevent the connection from being useful. File transfers
seem to work OK, but, when using Kermit in connect mode, receiving large
amounts of data at the originating terminal always results in lost
characters. It seems that the terminal sends an XOFF, but the host sending
the data continues to send, and data is lost at the receiving terminal.
I have tried changing terminal buffer sizes with no success. I have spoken
with the network administrator about XOFF settings on the network lines. He
assures me that the network is set correctly. Also, we have enabled the
alt_typeahead setting for the terminal lines. We have had no success with
any of these remedies.
The following diagram may help to explain the connections.
Originating terminal--> VAX--> Network--> Remote Host *** seems to work OK
Remote Host--> Network--> VAX--> Originating Terminal *** lost characters
I would greatly appreciate any help you could give me with the problem.
Thanks,
Kaye Johnson
NBC
University of Pennsylvania
[Ed. - We have heard similar reports about VMS Kermit losing characters when
during CONNECT. Reportedly, the CONNECT code could be done in better ways.
Unfortunately, the authors of VMS Kermit aren't going to be able to spend much
more time on it. We hope that the VMS support in C-Kermit will be souped up to
the extent that it can start being used in place of Kermit-32. Meanwhile, your
setup may be a "worst case" in that it could take a long time for XOFFs to
propogate back through the network, depending on how flow control works in
your network.]
------------------------------
End of Info-Kermit Digest
*************************
-------
7-Aug-87 12:08:04-EDT,27034;000000000000
Mail-From: SY.CHRISTINE created at 7-Aug-87 12:07:12
Date: Fri 7 Aug 87 12:07:12-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #16
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12324614090.159.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Fri, 7 Aug 1987 Volume 6 : Number 16
Today's Topics:
Announcing C-Kermit 4E(066), a Test Release
DG Kermit Announcement
Announcing MS-DOS Kermit 2.30 for RMX86 & RMX286
New MSPCTRAN program in Turbo Pascal
Update to BOO-maker program MSBMKB.C
Modcomp Kermit Files Now Complete
Re: "Okstate" Leaving the Net
MS-DOS Script PAUSE Command
Re: Bootstrapping CMS Kermit
Re: Kermit Buffering Problem
Re: Kermit & Mac II (V6 #14)
Re: DG Nova (V6 #14)
C-Kermit on PDP-11/23 running UNIX V6
----------------------------------------------------------------------
Date: Thu 6 Aug 87 12:19:49-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Announcing C-Kermit 4E(066), a Test Release
Keywords: C-Kermit, Unix, Macintosh, VAX/VMS, Apollo, Aegis, Commodore
Keywords: Amiga, Data General
This is to announce an experimental new release of C-Kermit for Unix, VAX/VMS,
the Apple Macintosh, Apollo Aegis, the Commodore Amiga, and Data General
AOS/VS.
I've tested this version on various Unix systems (Ultrix 1.2 & 2.0 on various
VAXes, AT&T System V on a 3B20, and 2.9BSD on a Pro-380), but not on anything
else. Since I'm about to leave on vacation for several weeks, I'd appreciate
it very much if during that time people could try it out on all the other
systems it hasn't been tested on, including Macintosh, Apollo, Amiga, VMS, Data
General, and many Unix variants (Xenix, Venix, Zeus, etc, especially in local
or dialout mode), and report back to Info-Kermit@CU20B.COLUMBIA.EDU, especially
if they have fixes to contribute.
The new release is 4E(066). The major changes from 4D(061) (September 86)
include:
. Support for long packets (but not sliding windows).
. Performance improvements: less copying of received data, more efficient
i/o, especially when receiving files.
. C-Kermit now takes its init file always, even if invoked with command-line
action arguments.
. Easy escape from packet mode (^C^C at any time).
. A file bytesize mask to 'set file type {text, binary} {7, 8}' so that
Kermit can be used to strip 8th data bit during file transfer (e.g. of
Wordstar files), independent of parity setting. Default 8.
. A new 'set terminal bytesize {7, 8}' command. Default 7.
. A 'set retry' command to adjust packet retransmission limit.
. Support for the Macintosh with Megamax C, so that for the first time
Mac Kermit can be built directly on the Mac.
. New support Data General AOS, AOS/VS, MV/UX and possibly RDOS & other
DG operating systems.
. New support for Apollo Aegis.
. Continued support for the Commodore Amiga.
. New 'make' options for sys5r3, CIE Regulus, HP-UX, IBM IX/370, Zilog,
and some others.
. Better statistics reporting.
. Major bugs fixed:
- Loss of trailing control characters at end of file when sending.
- 2-character checksum now works with 8-bit binary files.
- Background/take-file interaction fixed (maybe?).
- Insertion of spurious CRLF at position 4096 when doing 'kermit -k'.
- Parsing of multine 'get' command (again).
. Many minor bugs fixed.
Benchmarks show a slight improvement in efficience when sending files with
regular length packets, and large improvement when receiving files, and a very
dramatic improvement when receiving files when using parity. The improvements
are most noticable on systems where the CPU is the bottleneck. For instance,
transferring a 16K text file between a VAX-11/750 and a Rainbow at 9600 baud,
using even parity and 94-character packets, the following effective baud rates
were observed:
C-Kermit Version
4D(061) 4E(066)
Send 3500 3920 (a 12% improvement)
Receive 800 4223 (a 428% improvement)
Use of long packets improves efficiency even more, up to a point (a function of
the packet length and the particular system) past which it degrades again. A
good length for VAXes seems to be 300-800, where we get effective baud rates in
the 50-80% range (provided we have clean lines and no retransmissions) --
higher efficiency at lower baud rates, and even higher in all cases when
compression can be done. For instance, the following efficiencies were
observed when sending the typical Unix 8K program core image (which has lots of
0's in a row) at 9600 baud from a Rainbow to each of two typically loaded
VAXes:
------ VAX 8700 ------- ------- VAX 750 -------
Packet Effective Effective
Length Baud Rate Efficiency Baud Rate Efficiency
40 4481 47% 3414 36%
94 6518 68% 4217 44%
200 7170 75% 4780 50%
300 7966 83% 4780 (peak) 50%
500 7966 83% 3773 39%
800 8962 (peak) 93% 2757 29%
1000 7966 83% 2390 25%
By the way, a caution to those who are running Ultrix 2.0 on VAX 8700's: Kermit
(any version), and probably any program like Kermit, doesn't work very well at
9600 baud on DMZ's with fast PC's like IBM ATs or PS/2s, but does OK at 4800
and below, or at 9600 baud with slower PCs like Rainbows, PC-1's, etc. But
Kermit works fine with the same PCs on 750s, 8650s, and other non-BI VAXes.
A plea for help with the non-Unix versions:
. For all versions, there's been a change to CKxTIO.C (the system-dependent
terminal i/o and interrupt procedures for system x) that allow for much more
efficient operation with parity; the change is in ttinl(), and I tried to
apply it to the various modules, probably incorrectly (and in some, I hadn't
the slightest idea what to do). All but the Unix version (ckutio.c) are
untested.
. The Data General, Apollo, and Amiga support comes from Phil Julian and Jack
Rouse at SAS Institute. Their work applied to 4D(061), and I tried to
integrate it into the new version. I'm sending them a tape with the new
files so they can test it out; meanwhile, if people with Data General
systems can try to build from the source and report on the results, that
would be great, especially if it still works.
. The VMS support hasn't changed, except for the ttinl() business. I have
a volunteer who's souping up the VMS support for C-Kermit (in light of
the "stable" status of Stevens Kermit-32), and will send him a tape, and
hope to get results back in a couple months.
. The Macintosh support is a major new change. It now compiles directly
on the Mac, under Megamax C, thanks to Jim Noble of Planning Research
Corp, who will also get a tape. Again, this support was added to 4D(061),
and needs to be rebuilt for 4E(066). If anybody can try this, please report
back. And if it works, send in new CKMKER.HQX and CKMKEY.HQX files for 4E.
And if anybody wants to try converting it to Apple MPW C, or Lightspeed C,
etc, that would be good too.
The files are in KER:XK*.* on CU20B.COLUMBIA.EDU (available via anonymous FTP)
and XK* * on CUVMA (available via BITNET KERMSRV), and will be on Kermit Tape
B, and should also show up at Oklahoma State U for UUCP access within a couple
weeks. The new files don't replace the current C-Kermit files (CK*.*), and
will not do so until all the systems demonstrably work. In order to use these
files, you have to rename them to CK*.* (or ck*.*) so that the various
Makefiles and other build procedures work, and the include (.h) files have the
right names. There's a program to do this, XKTOCK.C, which should be fairly
portable (if it doesn't work, the files can be renamed by hand).
Since the collection of files is quite large, you might want to make a
judicious selection if obtaining them over networks:
Group Size Description
KER:CKC*.* 111K Required for all systems.
KER:CKW*.* 13K Wart, required for all systems.
KER:CKU*.* 545K For Unix, VMS, Data General, Apollo. Includes Unix docs.
KER:CKM*.* 488K Macintosh specifics.
KER:CKI*.* 96K Amiga specifics.
KER:CKD*.* 892K Data General specifics.
KER:CKV*.* 67K VAX/VMS specifics.
Total size approximately 2.2MB
KER:CKP*.* (these files don't exist yet, but "P" is reserved for IBM PC)
KER:CKH*.* (not available yet, reserved for Harris, see below)
(On BITNET/EARN, leave out the KER: and replace the period by a space.)
A detailed list of changes is in the file XKUKER.UPD, and the documentation
(CKUKER.MSS, .DOC, .BWR, .NR) has been revised to reflect the new features.
Thanks in advance to anyone who is willing to take a shot at evaluating and/or
fixing all of this, and apologies for releasing it and then disappearing.
And thanks to the many people (listed in the XKUKER.UPD file) who contributed
to this release.
Finally, if you succeed in building and running this program for a any system
at all besides VAXes with Ultrix, please report back the system, OS, OS
version, and maybe some particulars like maximum baud rates, best packet size,
problems, idiosyncracies, and tricks.
- Frank
P.S. I just got a tape from David Wilson of the Waisman Center in Madison,
WI, with C-Kermit 4D(061) support for Harris computers with DMACPs or CNPs
(whatever those are!), but according to his letter, major changes were required
to the system-independent (CKC*.*, CKU*.*) modules. It's too late to try to
integrate this with the new stuff. Maybe in September.
------------------------------
Date: Fri, 15 May 87 16:05 EDT
From: CCPHIL@TUCC.BITNET <Phil Julian, SAS Institute>
Subject: DG Kermit Announcement
Keywords: C-Kermit, DG Kermit
The new Kermit for the Data General computers is ready for initial release.
This Kermit is the Unix Kermit version 4D(061) with DG-specific modules for
file I/O (ckdfio.c), terminal I/O (ckdtio.c), and the connect command
(ckdcon.c). This version supports all the features that Unix Kermit provides,
except for the DIAL command and the SCRIPT command. The program was developed
under AOS/VS rev 6 and rev 7.54, and with recompilation it may work on other
Data General systems, such as AOS/RT32 and MV/UX. Version 3.21 of the C
compiler was used to develop the source.
In addition to the usual features of C-Kermit, some additional features are
available for the DG Kermit.
* Data General wild cards and special symbols are supported when
referencing files, including the following set: # + - * ^ = @
* Fully qualified pathnames can be used to get or send files.
Sub-directories are entered if the # character is used.
* DG and non-DG terminals are supported, so that character deletes occur
correctly on-screen for any terminal device.
* Batch mode operation is supported.
* I/O redirection of the "xeq" command is supported.
* Baud rates up to 38400 are supported, and other additional baud rates
are supported (enter "help set baud" at the Kermit prompt).
* Terminal emulation on a dial-out line from the DG is very fast, and has
been tested up to 19200.
* The initialization file, .kermrc, is executed even when Kermit is used
in command line mode.
* The local space command accepts a directory parameter.
Documentation is also supplied (ckdker.doc), which is adapted to the Data
General from the regular Unik Kermit document (ckuker.doc). Installation
guidelines are included (ckdker.hlp), and cli macros assist in compiling and
installing the source code. A "beware" file lists all known bugs and quirks
(ckdker.bwr).
Data General users can get C-Kermit version 4D (061) in DG tape format,
including all source, binaries, and program files. I finally got around to
loggin onto the NADGUG bulletin board, and announced C-Kermit. When someone
wanted to know how to get a copy of the program, I asked for a volunteer to
distribute DG Kermit tapes. I got an immediate response. Please add this
address and information about providers of DG Kermit:
Send a tape and return postage to
Randy Burndt
Data Processing Manager
American Urological Association
6750 West Loop South
Suite 900
Bellaire, Texas 77401
and he will send you Kermit and some other DG utilities.
Thanks to Randy and the NADGUG BBS for a quick response.
Phil Julian
BITNET: CCPHIL@TUCC
Usenet: rti!sas!julian
Phone: 919-467-8000
[Ed. - Many thanks, Phil! These files are included with the new C-Kermit 4E
files, KER:XKD*.*, plus some conditional compilation code in some of the XK[CU]
modules. Let's hope that the 4E can be brought up quickly on the DG, and that
the tape volunteer will get a copy.]
------------------------------
Date: Tuesday August 4, 1987 4:41 PM PDT.
From:<JAFW801%CALSTATE.BITNET@wiscvm.wisc.edu>
Subject: Announcing MS-DOS Kermit 2.30 for RMX86 & RMX286
Keywords: MS-DOS Kermit, RMX Kermit
This is to announce the test release of version 2.29C of Kermit for both the
RMX86 and RMX286 Operating Systems. Relevant files are MSTRMX.BOO, for
RMX86, and MSTRX2.BOO, for RMX286, MSTRMX.DOC, and MSERMX.P86.
In addition to all of the changes that have gone into MSKermit in nearly four
full versions since 2.26, wildcard send, full RMX paths and file names, easing
of previous restrictions on RUNable commands, and performance improvements have
been added at the RMX end.
Wildcard send has been implemented through use of an auxiliary command, WC,
whose source is in MSERMX.P86. A comment header includes SUBMIT file contents
to generate the command for both OS's. As a fortuitous fallout to wild card
implementation, a list of file names may be used wherever Kermit accepts a wild
card file specification, as long as all files in the list are in the current
default directory. For example:
SEND READ.ME.FIRST,*X*.A*,*.OBJ,ETC.ETC
works. Try to say that in DOS! Similarly, when Kermit is in SERVER mode, it
will respond to a GET file-name-list from the local Kermit.
The WC command is only necessary for wildcard sends. Kermit works fine
without it. If used, it should be in one of the default search directories.
It and Kermit needn't be in the same directory. The WC command isn't
otherwise totally useless. Try "WC ?able,movie*" as an alternative to
"DIR$ FOR ?able,movie*".
Note that all version 2.29C's aren't identical. Kermit is a living,
changing in real-time thing. If the version ID were changed with every
discrete instance of Kermit, the alphabet would be exhausted in less than
one month. While comments are solicited, any "How come this one's not the
same as that one?" or "Why's that turkey's got a later version than my
superb system?" will be referred to this paragraph, if we're in a good mood.
[Ed. - Many thanks! The files are in KER:MSTRMX.* and MSERMX.P86 available
through APRAnet by FTPing to CU20B as user ANONYMOUS (any password) and via
BITNET using KERMSRV.]
------------------------------
Date: Thu, 30 Jul 87 22:03 CST
From: <LOWEY@SASK.BITNET>
Subject: New MSPCTRAN program in Turbo Pascal
Keywords: MSPCTRAN
I am sending a Turbo Pascal program which does the same thing as the
MSPCTRAN.BAS file. I got tired of waiting so long to translate the .BOO
files I receive so often from Columbia, so I decided to re-write the
MSPCTRAN.BAS program in Turbo Pascal. This sped up the translation
considerably. On my IBM-AT clone, running at 10 Megahertz and using a hard
disk, unpacking the MSTIBT.EXE file using the BASIC program took over 7
minutes. This program does it in 22 seconds. Using floppy diskettes the
speed improvement should be even faster, because I buffer more of the output
in memory than the BASIC program does.
I have tested the program using Turbo Pascal version 3.01C and 2.00B. I
tried it on the MSTIBT.BOO file. Doing a file compare on it when it is
finished shows that the BASIC and PASCAL versions are identical except for
the last few bytes, which are different because the files are padded out to
a block size of 128 characters. This will not effect the KERMIT program
because these padding characters are not really part of the program.
There is nothing in this program which is specific to IBM computers, so it
should compile fine using the generic MS-DOS version of Turbo Pascal. There
is some Turbo Pascal specific code (the BLOCKWRITE and STRING[255] portions
especially) but the program should be easily transportable to other pascals.
I hope you find this useful. Consider it partial repayment for the
excellent service Columbia is doing for the Computing community.
Kevin Lowey
Computing Services
University of Saskatchewan
LOWEY@SASK (bitnet)
...!alberta!sask!lowey (uucp)
[Ed. - Many thanks! This goes into the collection, along with the
assembler, C, and Basic versions, as KER:MSBPCT.PAS.]
------------------------------
Date: 30-JUL-1987 14:06:06
From: David Sizeland <dsurgery@uk.ac.lon.umds.uxt>
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Update to BOO-maker program MSBMKB.C
I have made some mods to msbmkb.c as it doesn't run properly on Unix systems
as is. The changes are in the code to open the output file. Under Unix,
open won't create the file if it doesn't exist, you have to use creat
instead. Also, I am not sure about the 0x1ff in the open for the input
file, the compiler doesn't give an error but it is certainly superfluous.
The diffs are from the old file to the new.
David.
[Ed. - Thanks, your diffs have been added to MSBMKB.BWR.]
------------------------------
Date: 7-Aug-87 0:0:0 EDT
From: Christine M. Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Modcomp Kermit Files Now Complete
Keywords: Modcomp
The version of Kermit that was announced for the Modcomp Classic running
under the MAX IV operating system, contributed by Bob Borgeson, of SETPOINT,
Inc., announced in Info-Kermit V6 #3, 26 Jan 87, had a bunch of files missing.
The missing files have been restored, and the program should now be complete.
The files are in KER:MOD*.*.
------------------------------
Date: 4-Aug-87 0:0:0
From: Mark Vasoll <vasoll@a.cs.okstate.edu>
Subject: Re: "Okstate" Leaving the Net
Keywords: Okstate
In article <2293@a.cs.okstate.edu>, I write:
> The system "okstate" will be leaving Usenet as of August 14th. All
> News and uucp mail connections will be dropped.
I haved received several mail messages asking how this will affect our
UUCP Kermit Distribution. The answer is, not at all. We will continue
to provide access to the full collection of Kermit sources via both
direct UUCP connections and via our custom Kermit server. The only
change will be that the support address is now "uucp-support@a.cs.okstate.edu"
and will only be reachable via the Internet as mentioned in my original
posting.
Mark Vasoll
Computing and Information Sciences Internet: vasoll@a.cs.okstate.edu
Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers, seismo,
Stillwater, Oklahoma uiucdcs}!okstate!vasoll
[Ed. - Also, in view of the new reorganization of Kermit distribution
into 5 areas, it'll take a while for OK State to reflect the new
arrangement. Patience, please.]
------------------------------
Date: Wed, 29 Jul 87 12:17 MDT
From: <JRD@USU.BITNET> (Joe Doupnik jrd@usu.Bitnet)
Subject: MS-DOS Script PAUSE Command
Keywords: MS-DOS, Script Files
In the latest Kermit Digest Ben Chang, chang%england.tcpip@ge-crd.arpa
commented that he experienced unstable delay times when using the MS Kermit
script command PAUSE. The timing was found to be machine dependent in a
subtle DOS way and has been rewritten to avoid the effect. The release
Kermit will time accurately on all machines having a DOS timeofday clock.
Ben might also want to try the long script example from the new MS Kermit
manual for transparently loading files to/from the host. For quick
reference and relaying here is a pair to implement
DOS-prompt> send filespec
where filespec can have wildcard characters. It differs only trivially from
the manual example.
Regards,
Joe D.
[Ed. - Thanks, Joe! Your script example has been placed in KER:MSTIBM.SCR.
The manual Joe mentions is still in preparation, but will be released with
the real 2.30, probably in early September.]
------------------------------
Date: Wed, 29 Jul 87 11:52:52 EDT
From: BJ CAMERON (SYSTEMS DEVELOPMENT) <HESSE@WATDCS>
Subject: Re: Bootstrapping CMS Kermit
Keywords: CMS Kermit
In reply to John Candler's query about the bootstrap form of Kermit-CMS 3.1:
There is another option not mentioned in the documentation which also permits
running user programs underneath Kermit (e.g. COPYFILE).
When LOADing the Kermit module use the RLDSAVE option. For example:
LOAD KERMIT (RLDSAVE
GEN KERMMOD
You can then load Kermit as a nucleus extension with the following EXEC.
/*
FUNCTION: NUCXLOAD THE KERMIT MODULE TO FREE UP THE USER AREA
CREATED BY: HESSE@WATDCS 86/11/12
*/
address command
parse upper arg arg_string
'NUCXLOAD KERMMOD'
KERMMOD arg_string
'NUCXDROP KERMMOD'
[Ed. - Thanks! Your comments have been added to KER:CMSKERM.INS.]
------------------------------
Date: 29 JUL 87 23:05-PDT
From: Iglesias%UCIVMSA.BITNET@wiscvm.wisc.edu
Subject: Re: Kermit Buffering Problem
Keywords: VMS Kermit
In response to the query about VMS Kermit typeahead buffering in Info-Kermit
V6 #15:
Try setting /ALT (alternate typeahead buffer) on the line you want to use
with KERMIT. This gives you a bigger input buffer, so you won't get (as
many) data overruns. I believe that you can set the size of the alternate
typeahead buffer with SYSGEN if you want to make it bigger. I have all my
outgoing lines configured that way (via SYSTARTUP.COM so it's permanent) and
it helps a lot.
Mike Iglesias
University of California, Irvine
------------------------------
Date: Wed, 29 Jul 87 17:37:59 EDT
From: Paul Placeway <paul@tut.cis.ohio-state.edu>
Subject: Re: Kermit & Mac II (V6 #14)
Keywords: MacKermit, MAC II
In article <12322019030.199.SY.CHRISTINE@CU20B.COLUMBIA.EDU> you write:
>Date: 15 Jul 87 01:37:24 GMT
>From: jww@sdcsvax.ucsd.edu (Joel West)
>Subject: Kermit & Mac II (V6 #14)
>Keywords: MacKermit
...
>MPW provides Megamax-style C string conversions if you want it, while
>LightspeedC has 16-bit ints like Megamax. Converting either one shouldn't
>be too bad, although the Lightspeed code generation won't be
>68020-compatible until the next release (due Real Soon Now).
>
> Joel West, Palomar Software, Inc. (c/o UCSD)
> {ucbvax,ihnp4}!sdcsvax!jww or jww@sdcsvax.ucsd.edu
The last sentence is interesting, but partially untrue. While the current
release of LightSpeed C dosn't support 68020 code, the 68020 is a propper
superset of the 68000. LightSpeed does run, and does produce good, working
(although 68000) code on a Mac II. Not too supprising since THINK did
follow all the rules that Apple set down for Mac software (not everyone
does: MegaMax did NOT).
In short, LightSpeed C does run on a Mac II, and does produce working
code (VERY QUICKLY) on a II.
Paul Placeway
Department of Computer and Information Science
ARPA: paul@ohio-state.{arpa,csnet}
UUCP: ...!cbosgd!osu-eddie!paul
[Ed. - All the more reason for someone to look at bringing up the new
Mac Kermit (announced above) on the Mac II, and possibly adding support
for Lightspeed or MPW C.]
------------------------------
Date: Wed, 29 Jul 87 14:25:26 edt
From: xyzzy!meissner@rti.rti.org (Michael Meissner)
Subject: Re: DG Nova (V6 #14)
Keywords: DG Nova Kermit
In article <12318368566.191.SY.CHRISTINE@CU20B.COLUMBIA.EDU> you write:
> Date: 1-JUL-1987 10:23:05
> From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
> Subject: Files Needed for the DG Nova Running RDOS?
> Keywords: DG Nova Kermit
>
> It's been pointed out to us that the files for Kermit in Fortran-5 for DG
> Nova machines running RDOS (prefix RDO) are incomplete. There are include
> references to SETSETUP.FR and F5ERR.FR, and these files aren't in the set,
> and what they may contain isn't obvious.
>
> Does anyone know what's in the files, or has anyone got copies?
>
> Alan Phillips
>
> [Ed. - These are probably DG files that come with DG Fortran. Anyway, the
> person who contributed the Fortran version of RDOS Kermit is long gone.
> The forthcoming release of C-Kermit will support DG C environments; it has
> been tested on AOS/VS, but not RDOS, however the C environment is supposed
> to be consistent across all the DG product lines.]
Ughhh, the DG C compiler only supports the 32-bit MV/eclipse systems (RDOS
runs on the 16-bit Eclipses and Novas). The operating systems that the
DG C compiler supports are:
AOS/VS propritary
AOS/RT32 propritary real-time subset of AOS/VS
AOS/DVS propritary distributed AOS/VS
MV/UX Unix System V hosted on top of AOS/VS
DG/UX Native System V/BSD unix
To my knowledge, the only C compiler that supports RDOS or AOS, is from
a company called IPT. Sorry for any confusion.
Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner
[Ed. - Oh. So we can wipe RDOS off the C-Kermit list...]
------------------------------
Date: Tue, 28 Jul 87 12:57:12 PDT
From: Samuel_Lam%UBC.MAILNET@MIT-Multics.ARPA
Subject: C-Kermit on PDP-11/23 running UNIX V6
Keywords: C-Kermit, PDP-11 Kermit
Has anyone got a working version of Kermit for a PDP 11/23 running Unix
version 6? The C compiler on this system is very limited and does not
handle #ifdef.
Thanks in advance for any help.
[Ed. - C-Kermit is probably hopeless for V6. Best hope would be the
old, old Unix Kermit from the 5th edition protocol manual, in KER:UX*.*,
or maybe Chris Kennington's portable C Kermit, KER:CUC*.*. Good luck!]
------------------------------
End of Info-Kermit Digest
*************************
-------
21-Aug-87 14:29:38-EDT,20220;000000000000
Mail-From: SY.CHRISTINE created at 21-Aug-87 14:28:20
Date: Fri 21 Aug 87 14:28:20-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #17
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12328309797.166.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Fri, 21 Aug 1987 Volume 6 : Number 17
Today's Topics:
New IBM PC .BOO File
Kermit 80 Version 4.08 (pre-release)
CDC Cyber Kermit Version 3 Available
Very Fast MSBPCT.PAS Program
COM3 Kermit
QK-Kermit QKKER.PAS File Bug
Re: EBCDIC Definition
CMS Kermit Initialization Files
Re: Bootstrapping CMS Kermit
Re: CMS 3.2 X-binary (2 messages)
Kermit 0.8(35)
C-Kermit Problem
Missing Files in RDOS Kermit Explained
Transferring Other File Types in ProDos Kermit
----------------------------------------------------------------------
Date: Mon, 17 Aug 87 21:45 MDT
From: <JRD@USU.BITNET> (Joe Doupnik)
Subject: New IBM PC .BOO File
Keywords: MS-DOS Kermit
I am sending another .BOO file with the usual trimmings plus better handling
of network packets for Token Passing systems and single buffered network
boards.
Regards,
Joe D.
[Ed. - Thanks Joe! The new .BOO file is dated 16 Aug 87 and is in
KER:MSTIBM.BOO available through ARPAnet by FTPing to CU20B, user ANONYMOUS
(any password) and through BITNET at CUVMA using KERMSRV. Thanks to all who
have been testing past versions of MS-DOS Kermit. Please test this one and
send in comments, etc.]
------------------------------
Date: 29-JUN-1987 10:14:55
From: OBSchou@UK.AC.LOUGHBOROUGH.MULTICS (Bertil Schou, Loughborough U, UK)
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK (Alan Phillips)
Subject: Kermit 80 Version 4.08 (pre-release)
Keywords: CP/M Kermit
After an incredibly long gestation peroid, here is hopefully an updated
version of Kermit-80 V4.05. Kermit-80 V4.08 is issued for testing purposes
only. I want any feedback about problems generated in this revision, or
others desperately want fixing.
Superficially, there is little real change in operation of Kermit-80, but
there have been some major jobs tackled like trapping BDOS calls and
multiple FCB buffering...
New bits for this version include:
SET {SEND/RECEIVE} START-OF-PACKET character
SET DIRECTORY-FILE-SIZE (Shows or hides file sizes on
DIRectory displays)
USER to set other user spaces
RECEIVE to collect a file from a remote SENDer
GET to collect a file from a remote SERVER
SEND {local filename} {remote filename}
TAKE to take command files from disk
automatic TAKE KERMIT.INI on default disk on loading
KERMIT-80 (useful for SET BAUD etc.)
much improved speed on DIRECTORY
automatic CLOSE-ing of a terminal connection if the line
is DROP-ped (currently only for certain systems).
improved printer handling.
On the negative side, only LASM can be used to assemble the
source files. I personally see no pont in being able to support
several assemblers if LASM can do the job, but then again, I have
not used the MAC80 cross assembler... Comments on assembler
compatabilities, please!
[Ed. - Thanks! The new files -- source only, no hex -- are in KER:CX*.*.
The old CP/M version remains in KER:CP*.*. Please report back bugs
problems, etc, as well as positive indications of what systems this new
version works on.]
------------------------------
Date: Thu 20 Aug 87 13:41:48-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: CDC Cyber Kermit Version 3 Available
Keywords: CDC Cyber Kermit
A new version of Kermit is available for CDC Cybers running NOS. It is derived
from the U of Texas Fortran 5 Kermit, with NOS/BE and UT2D support removed. It
contains the following new features and changes (items 8 through 10 are new for
Version 3.3.)
1. Wildcard file names on the SEND command and server GET command. A '*'
stands for any 0 or more characters. A '?' stands for any one character.
For example:
*BUG All files ending in BUG.
*DOG* All files containing DOG.
F* All files starting with F.
F?X* All files whose names start with F and contain X in the
the third position, followed by 0 or more characters.
2. Local and permanent file SEND and server GET. If no local files match the
request, the user's permanent file catalog is searched.
If the specified file name is preceeded by 'L:', only local files are
sent. If preceeded by 'P:', only permanent files are sent.
3. A DIRECTORY command and server REMOTE DIRECTORY command. Lists local
(by default) or permanent file names. Accepts wildcards and/or L: and
P: specifications (above).
4. Automatic recognition of DISPLAY CODE, 6/12 ASCII, and 8/12 ASCII file
text modes on SEND. Receives 6/12 ASCII by default.
The SET FILE-MODE command allows BINARY and TEXT file types.
SET TEXT-MODE allows AUTO to set automatic recognition (above), or
DISPLAY, 6/12-ASCII, or 8/12-ASCII to force a specific character
translation for TEXT file mode.
BINARY file mode stores characters as 7.5 8-bit characters per 60 bit
Cyber word.
5. Supports repeated character compression (if the micro Kermit allows).
6. Supports long file transfer packets up to 1000 characters (if the
micro Kermit allows).
Use the SET RECEIVE PACKET 1000 command within Cyber Kermit to enable
long packet receive. To send long packets, enter the above command in
your micro Kermit, if it supports long packets.
7. Cyber Kermit no longer affects the parity of your terminal connection.
If you have trouble sending or receiving files, check your parity
setting. On the Cyber, the parity at login is set to NONE. Note that
changing your terminal class (TC parameter) via TRMDEF or %TC=?? will
reset your parity setting.
8. ***New for V3.3*** (May, 1987)
Kermit will take commands from the file KERMINI at startup time. You
may use this to set non-standard parameters, start up an server
automatically, etc. Kermit will first look for a local KERMINI, then
for a permanent file KERMINI.
9. ***New for V3.3***
There is now a TAKE filename command to direct Kermit to read its
commands from a local or permanent file. It searches for local and
permanent files like the SEND command, above.
10. ***New for V3.3***
When files are being received by the Cyber, Kermit will now attempt to
use up to 3 characters of the micro's filename's extension as part of the
Cyber's file name. This allows file transfers of the form LONGNAME.*
to proceed with fewer file name conflict problems.
Please contact me if you have any problems with Cyber Kermit Version 3.
Steve Roseman
Lehigh University
LUSGR@LEHICDC1.BITNET
(215) 758-3987
[Ed. - Many thanks Steve! These files have replaced the old files in
KER:CD3KER.*.]
------------------------------
Date: Thu, 13 Aug 87 11:46 EDT
From: Helmut Waelder <ZRWA001@DTUZDV1>
Subject: Very Fast MSBPCT.PAS Program
Keywords: MSBPCT.PAS
Here is a completly new version of MSBPCT.PAS written in turbo pascal.
It was developed for maximum speed. On my PC it decodes the MSKERM.BOO
file in about 9 (nine) seconds.
[Ed. - Many thanks. The source code has replaced the old one in KER:
MSBPCT.PAS.]
------------------------------
Date: Sat 4 Jul 1987 14:17:29 CDT
From: Mark S. Zinzow <Markz@Uiucvmd>
Subject: COM3 Kermit
Keywords: MS-DOS Kermit, COM Ports
I had not recieved the Kermit Info-Digest V6N13 when I sent my note to the
IBM PC Info-Digest regarding my hacked copy of MS-Kermit 2.29 that supported
Com3. Even though it took over a week for the files MSR29C.UPD and MST*.BOO
(MSTIBM.BOO in particular) to show up on KERMSRV at UOFT02 after they did on
KERMSRV at CU20B, I have them now and recomend them over my version.
Joe did not wait for me to update my modifications (I don't blame him; I was
taking too long) for version 2.3 so com3 & com4 support are in MS-DOS Kermit
2.29C. Since my version is obsolete I will not be sending it to those who
have requested it from me. If you really need the old version of kermit
with COM3 support, send me another request and I'll send a BOO file of the
binary. I do not plan to distribute the soure because it is both large
(about 1 MB), obsolete, and contrary to C.U.'s policy of distributing source
to minor releases.
Electronic Mail U.S. Mail
ARPA: zinzow%uiucuxe@a.cs.uiuc.edu Mark S. Zinzow, Research Programmer
BITNET: MARKZ@UIUCVMD.BITNET Computing Services Office
To BITNET from ARPA or UUCP: University of Illinois at Urbana-Champaign
MARKZ%UIUCVMD.BITNET@wiscvm.wisc.edu 150 Digital Computer Laboratory
CSNET: zinzow%uiucuxe@uiuc.csnet 1304 West Springfield Ave., Urbana, IL 61801
USENET/UUCP: {ihnp4,convex,pur-ee,cmcl2,seismo}!uiucdcs!uiucuxc!uiucuxe!zinzow
Phone: (217) 244-1289 Office: CSOB 109 ihnp4!pyrchi/
------------------------------
Date: Thu, 23 Jul 1987 23:45 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: QK-Kermit QKKER.PAS File Bug
Keywords: QK Kermit
After getting QKKER.PAS from CU20B via FTP I attempted to edit QKKER.PAS to
split the individual files. I noted that quite a few seemed to be missing
so I sent a note to the author. Here is his reply:
>Date: Wednesday, 22 July 1987 13:32-MDT
>From: VIC%QUCDN.BITNET at wiscvm.wisc.edu
>To: kpetersen at SIMTEL20.ARPA
>Re: QK-Kermit
>
> The file QKKERM.PAS should contain all the source files for both
>MsDos and CP/M version. I seems as though you have a truncated
>QKKERM.PAS file. The file should contain about 5462 lines. The last
>thing in the file is the KEYTABLE.DAT file. It maybe that someone
>along your network path maybe truncating long files.
After receiving that I decided to get the file again and look at it with
EMACS on the mainframe. What I found was a single control-Z at the end of
RECVFILE.PAS.
END ; (* ------- RECVFILE procedure -------*)
^Z <-----the control-Z was here
(* ===FILE============ CONNECT.PASVT100 =========================== *)
(* ================================================================== *)
(* Global Var and Procedures for Connect Procedure. *)
(* ================================================================== *)
On CP/M or MSDOS most editors see a control-Z as end-of-file. I have
removed the control-Z and the fixed file is temporarily available via FTP in
PD:<MSDOS.TEMP>QKKER.PAS from SIMTEL20.ARPA. No other changes were made.
Please let me know when you get it so I can delete the file.
--Keith Petersen
[Ed. - The offending Ctrl-Z has been removed from our copy.]
------------------------------
Date: Wed, 29 Jul 87 22:30:16 EDT
From: Peter DiCamillo <CMSMAINT@BROWNVM>
Subject: Re: EBCDIC Definition
Keywords: EBCDIC
There's a definition in Appendix G of IBM System/370 Principles of
Operation, GA22-7000. The most convenient reference, which also includes
ASCII, is the "yellow book", System/370 Reference Summary, GX20-1850.
Peter
------------------------------
Date: Thu, 30 Jul 87 02:18:17 PDT
From: rutgers!ames!lll-tis!ptsfa!rhc@columbia.edu
Subject: CMS Kermit Initialization Files
Keywords: CMS Kermit
Re: Info-Kermit Digest V6 #15:
I have a question related to CMSKERMIT. According to the documentation, one
should be able to create initialization files which KERMIT reads and
executes upon startup. One is described as (SYSTEM) KERMINI and the other
is described as (USERID) KERMINI. What I am having trouble understanding is
exactly what the FILENAME FILETYPE would be in the CMS environment for
either file. I realize the (USERID) KERMINI would be located on the user's
"A" disk, but is the filename KERMINI, and if so, what filetype?
Thanks!
(all standard disclaimers apply - your actual baud rate may vary,
depending upon atmospheric and cosmic disturbances)
Robert Cohen San Ramon, California {ihnp4,lll-crg,qantel,pyramid}!ptsfa!rhc
[Ed. - Answer: SYSTEM KERMINI is the name of the system-wide init file,
and (USERID) KERMINI is on your disk, with (USERID) replaced by your own
user ID. E.g., if your user ID is FOO, the file is FOO KERMINI.]
------------------------------
Date: 1987 Aug 10 14:29 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Subject: Re: Bootstrapping CMS Kermit
Keywords: CMS Kermit
The RLDSAVE option does not exist under CMS release 3 or earlier.
RLDSAVE+NUCXLOAD is clearly the method of choice under release 4 and beyond
(as long as Kermit doesn't somehow get loaded into LOW nucleus free
storage). In fact, one might choose to leave Kermit in place as a permanent
system extension, rather than issue a NUCXDROP after each invocation.
------------------------------
Date: 1987 Aug 10 13:05 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Subject: Re: CMS 3.2 X-Binary
Keywords: CMS Kermit
> I noticed that v-binary downloads F files
> just as binary does. That makes the user bound to specify not only the file
> RECFM F, but also the LRECL when he uploads F files.
> It would be easier if he had concern of neither RECFM nor LRECL.
> Do you see any any other straightforward way to transport CMS files, DISK
> DUMP excepted?
As a matter of fact, there is a way for transporting files for eventual
reconstruction on a system like the original one. The method is called
archiving. Kermit-CMS is halfway there -- it generates attribute info that
could be saved away by the micro Kermit and passed along with the file to
the target host. What is missing is a well-thought-out scheme for deciding
precedence among the possible sources of attribute info. We must remember
that "most" micro Kermits do not support file archiving, so the mainframe
must continue to assume that the usual source of attributes will be the
user, via SET commands. I haven't thought it all out myself, but perhaps
Kermit-370 could merge any attributes received via A-packets and then
restore the defaults.
John
------------------------------
Date: Wed, 12 Aug 87 09:57:00 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Re: CMS 3.2 X-Binary
Keywords: CMS Kermit
>As a matter of fact, there is a way for transporting files for eventual
>reconstruction on a system like the original one. The method is called
>archiving. ...
Yes, but as you say, everyone has to deal with attributes packets, keep them
somewhere and send them back. It is a long way until they all do so. If we
agree an archive file is of no use on the archiver other than resending as
is for reconstructing, why not think of the archivee including the
attributes in the data itself, just where the archiver would think of
putting them? As with CMS, the data format itself may have to be adapted for
reconstruction anyway (also think of the Mac forks...). If the CMS V-BINARY
or like were to segment fixed length files, the only missing information
would be RECFM, LRECL and timestamp to do so.
------------------------------
Date: Fri, 7 Aug 87 16:03:11 PDT
From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
Subject: Kermit 0.8(35)
Keywords: MacKermit
I've tested the Megamax version briefly on my Plus, talking to a 4D(061) on
my Sun 3/52, and it seems to work fine. I've posted a short note to
comp.sys.mac, reporting that 0.8(35) is now available and relaying your
request for people to complete the 4D(066) port and/or port the whole thing
to MPW or LightSpeed C.
[Ed. - Thanks for the feedback on MacKermit. And thanks to all of you
who have sent in comments, complaints, etc. about the new C-Kermit in
general. I am keeping them all together for the author to review.]
------------------------------
Date: 8-JUL-1987 10:05:25
From: V Paramananda (PS) <ananda@uk.ac.ucl.cs>
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: C-Kermit Problem
Keywords: C-Kermit
We are having trouble with a version of C Kermit installed on a Sun 3/160
workstation within the Department of Photogrammetry and Surveying at UCL. It
appears impossible to get the system set up as a virtual terminal so that
that it can initiate transfers from other Kermits, in this case a VAX within
UCL. We can set up the line /dev/ttyb on thisd Sun without any apparent
problems. However, when the line is connected there is no response from
remote hosts at the other end of the line. It is unlikely that the hardware
is a fault, as the UNIX utility function 'tip' is able to establish
connections without problems.
Could you please reply to:
oneill@uk.ac.ucl.cs
Thankyou,
Mark O'Neill,
Dept of Photogrammetry and Surveying
UCL,
Gower Street,
Londow WC1E 6BT UK.
Tel: 01-387-7050X2743
------------------------------
Date: 12-AUG-1987 11:23:39
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Missing Files in RDOS Kermit Explained
Keywords: RDOS Kermit
The missing files SETSETUP.FR and F5ERR.FR in RDOS Kermit (RDO) have now
been explained. SETSETUP.FR is a mistyping for STDSETUP.FR, which is
included in the conatenated sources; F5ERR.FR is a standard DG Fortran
support filem which ought to be included with the Fortran compiler.
------------------------------
Date: Wed, 12 Aug 87 12:39 EDT
From: TMPLee@DOCKMASTER.ARPA
Subject: Transferring Other File Types in ProDos Kermit
Keywords: ProDos Kermit, Apple Kermit
Kermit 3.75 (and presumably the later ones too) is only "designed" to
handle four file types: TXT, BIN, INT, and BAS, the standard DOS 3.3
types. As far as I can tell, the only type it does something funny with
is the TXT type -- it converts from ordinary ASCII to Apple's hi-bit
ASCII, but it may also do something special with INT and BAS.
To get it to handle something else (in my case, WordPerfect's $A0 type)
one can fool it into using any file type code you want for the binary
mode. To do this you need to change two bytes in the program.
At location $4995 there is a string A9 06 CD
(LDA #06
CMP ...)
At location $4A2A there is A9 06 8D
(LDA #06
STA ...)
(the locations will presumably differ in other versions, but my guess is
that the same sequence will be there someplace)
The first is where it is checking that the file type of a file you are
about to transmit is what you say it should be, the second is where it
is setting the file type of a file it is about to receive.
If you want it to handle any other file type, change the 06 (the ProDos
file code for binary files) in both locations to whatever other file
type you want. (in my case, $A0 for WordPerfect files.) Save the
changes. Then whenever you want to handle that file instead of TXT go
to the kermit command mode and SET FILE-TYPE BINARY.
(Of course, if you want to handle binary, or yet another type, you'll
have to change the two locations again.)
(No guarantees, comments welcome)
TMPLee@DOCKMASTER.ARPA
[Ed. - Thanks for the report. It has been added to the .BWR file.]
------------------------------
End of Info-Kermit Digest
*************************
-------
4-Sep-87 13:18:05-EDT,27813;000000000000
Mail-From: SY.CHRISTINE created at 4-Sep-87 13:17:03
Date: Fri 4 Sep 87 13:17:02-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #18
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12331966835.200.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Fri, 4 Sept. 1987 Volume 6 : Number 18
Today's Topic:
C-KERMIT -
Kermit 0.8(35)
Mac Kermit 0.8(35) report
Experimental C-Kermit 4E(066) Works on SCO Xenix
Test C-Kermit Feedback on SCO Xenix
C-Kermit 4E(066) on Convex C1
Experimental Kermit 4E(066) Mostly Works on Gould Powernode 6000
More about Experimental Kermit on Gould
Trouble with C-Kermit 4E(066) Init File???
New xkuker (C-Kermit) Bugs on Pyramid
C-Kermit 4E Amiga .BOO File
C-Kermit 4E(066) on Amiga, and Long Packet Problem
4E(066) Long Packet Problem Followup
C-Kermit on Pro 350 / Venix V1
C-Kermit Version 4E(066) Results on Celerity, Pyramid, 3B20
Bugfix for C-Kermit 4E(066) on Pyramid
C-Kermit 4E fixes for BSD 4.3
Problems with C-Kermit 4E(066) on VAX/VMS
C-Kermit 4E Problems on Tandy 16A/6000 and Arete 1200
C-Kermit 4E Feedback
C-Kermit Lock Files
----------------------------------------------------------------------
Date: Fri, 7 Aug 87 16:03:11 PDT
From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
Subject: Kermit 0.8(35)
Keywords: Macintosh Kermit, C-Kermit
I've tested the Megamax version briefly on my Plus, talking to a 4D(061) on my
Sun 3/52, and it seems to work fine. I've posted a short note to
comp.sys.mac, reporting that 0.8(35) is now available and relaying your
request for people to complete the 4D(066) port and/or port the whole thing to
MPW or LightSpeed C.
------------------------------
Date: Fri, 14 Aug 87 16:03:11 EDT
From: Ben Cranston <ZBEN@UMD2.UMD.EDU>
Subject: Mac Kermit 0.8(35) report
Keywords: Macintosh Kermit, C-Kermit
Preliminary testing of Mac Kermit 0.8(35) indicates everything functional.
I STILL have to change the Inbound End-Of-Packet character from 13 to 10
(015 to 012) to communicate with one of our hosts, which insists on sending
even parity and terminating output "records" with both a CR and LF.
When I reported this problem over a year ago, we thought the problem was
parity bit related, based on some comments in the Kermit history file.
Based on an accidental observation in our latest testing, it now occurs to
me that there is another explanation.
Scenario one:
Packets from the host end with an even parity CR LF (0215 0012) but Kermit
erroniously thinks the 0215 from the serial port and the 0015 from the
"protocol" menu are not the same character. Setting 0012 to be the end of
packet character causes the end of packet to be correctly recognized,
as a LF already has even parity and thus needs no added parity bit.
A comment from the history file about "putting SCC into 8 bit mode always
and doing parity ourselves" started us thinking in this direction.
Scenario two:
Packets from the host end with CR LF. Kermit correctly recognizes CR as the
end of the packet, but incorrectly interprets the LF as the end of another
record. This empty record somehow confuses the protocol. Setting LF to be
the end of packet character causes the CR to be interpreted as just one more
data character after the packet but before the end of the record.
In checking out this new Kermit I grabbed a file of test data, downloaded it
to the Mac, uploaded it back, and compared it against the original version.
Unbeknownst to me, the particular file I chose had an explicit linefeed
character embedded in the data at one point. Somewhere in the
download-upload process this linefeed was changed into a real newline,
creating a one-line discrepancy between the two files.
Now, I'm quite sure the LF -> newline mapping was not happening on the host.
Nor is it a problem with Mac filesystem semantics, as the Mac uses CR and
not LF as its newline character. If some routine in Kermit is confusing
LF with CRLF it could cause this kind of behavior.
Another interesting observation was that the "retransmit" indicator on the
screen seemed to be incrementing by two. That is, it would read 1, 3, 5,
7, 9, 11, and so on until the transfer timed out. Like two records were
going by each time or something...
If anyone can suggest an experiment that would differentiate between these
two scenarios, and wouldn't take massive efforts to perform, I would be
interested in hearing about it...
I do have MPW installed, and have access to Lightspeed. Conversion from
Megamax might be complicated by the fact that Megamax has 16 bit INTs and
MPW has 32 bit INTs. I have converted a few simple programs and so have
some experience in the area. If nobody else takes up the gauntlet I suppose
I could be persuaded to take it on, if only to fix the aforementioned bug...
Ben Cranston <zben@umd2.UMD.EDU>
Computer Science Center Systems Group
The University of Maryland
[Ed. - There have been numerous complaints over the last couple years that
C-Kermit cannot properly cope with incoming packets that are delimited by
CRLF. We have never been able to reproduce the problem. Your descriptions
might help. Will try to track it down.]
------------------------------
Date: Sun, 9 Aug 87 15:28:56 edt
From: jl42+@andrew.cmu.edu (Jay Mathew Libove)
Subject: Experimental C-Kermit 4E(066) Works on SCO Xenix
Keywords: C-Kermit, Xenix
I brought the experimental sources to my SCO Xenix 2.1.3 system (running on an
IBM PC/AT compatible, made by PCs Limited) and compiled them directly, no
trouble (make xenix).
Jay Libove
Arpa: jl42@andrew.cmu.edu Bitnet: jl42@drycas.bitnet
UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP: ...!{pitt | bellcore} !darth!libove!libove
------------------------------
Date: Tue, 11 Aug 87 23:04:22 PDT
From: guyton%condor@rand-unix.ARPA
Subject: Test C-Kermit Feedback on SCO Xenix
Keywords: C-Kermit, Xenix
I'm running SCO Xenix 2.2 on a 386, and have (so far) three comments re the
new test version of kermit ...
1) Why all the wait(0)'s instead of wait((int *)0) as mentioned
in the comments? Any machine that has sizeof(int) != sizeof(* int)
is going to need that typecast, and there's no reason I can think
of why the code wasn't fixed when the comment was applied.
[Ed. - I wasn't sure if this should apply to all systems, guess it should be
changed as you suggest.]
2) A couple of files included "file.h" erroneously. I ifdef'd it out
for xenix, but I guess it should be omitted for others as well.
[Ed. - This is a horrible problem; no two systems seem to agree about what
is in file.h or where it is. Notice that other SCO Xenix people did not
report this problem...]
3) I've included a very quick implementation of modem support for Concord
2400 bps modems.
Oh, I modified the xenix make to use large model w/out even trying the
default, don't know if that would have worked or not.
Follows are my diffs,
Jim
[Ed. - Thanks! Diffs added to XKUKER.BWR for now.]
------------------------------
Date: Wed, 12 Aug 87 14:07 EST
From: Mark B. Johnson <CDTAXW@IRISHMVS>
Subject: C-Kermit 4E(066) on Convex C1
Keywords: C-Kermit, Convex
We got C-Kermit up and running without (so far) any problems on a Convex C1
minisupercomputer running Convex UNIX V6.0. The make bsd option worked
without change. I will report any problems as they crop up.
Mark Johnson
Univ of Notre Dame
------------------------------
Date: Mon, 10 Aug 87 17:56:50 MDT
From: Mike Niswonger <CNISWONGER@SIMTEL20.ARPA>
Subject: Experimental Kermit 4E(066) Mostly Works on Gould Powernode 6000
Keywords: C-Kermit, Gould Powernode 6000
Just picked up the experimental Kermit and brought it up on a Gould
Powernode 6000 (dual processor) running UTX 2.0. This system thinks it is
BSD 4.3, so i just made "BSD". So far everything looks good, but tests are
still incomplete - I'll post a complete report in a couple of days when I have
had a chance to test more options.
I had to try long packets first. Everything works fine at 1000 char
packets between MSKermit 2.29C and the new kermit at 9600 baud. The effective
baudrate was about 6800 baud, or about 71% efficency. I'll try and find the
optimum baud rate and packet length later this week.
Mike
------------------------------
Date: Wed, 12 Aug 87 18:24:37 MDT
From: Mike Niswonger <CNISWONGER@SIMTEL20.ARPA>
Subject: More about Experimental Kermit on Gould
Keywords: C-Kermit, Gould Powernode 6000
In continuing my debug on CKermit 4e(066) I found a problem in
trying to send with long packets. Negotiations look OK, but send packets
go to maximum size without long packets. Long packets are accepted in the
other (receiving) direction. Nice for uploads, but . . .
[Ed. - Probably related to "set send packet-length" command, see below.]
I'll get copies of the log files and send them to you. During debug
I also noticed a problem with F111 format debugs - sometimes they get a <CR>
in them at the end of the data which causes an overprint on the data when I
send it to the printer. I'll try and track these down. Let me know if you
hear of any other bugs.
Mike
------------------------------
Date: Tue, 11 Aug 87 14:36:38 CDT
From: moore@ncsc.ARPA (Moore)
Subject: Trouble with C-Kermit 4E(066) Init File???
Keywords: C-Kermit
have you folk heard any complaints about .kermrc being ignored in the new unix
release of kermit 4e(066) 4 aug 87, 4.2bsd? maybe i'm doing something stupid
(again).
jim
[Ed. - There have been a couple reports of this, but we can't reproduce on
our own 4.2BSD (really Ultrix 2.0) VAX. Kermit 4E(066) finds the .kermrc
file if it's in the home directory, even if you're cd'd to another directory,
or else in the current directory if there's not .kermrc in your home
directory. The way the program finds the home directory name has not changed
in many releases (it's just getenv("HOME");).]
------------------------------
Date: Tue, 11 Aug 87 17:00:12 EDT
From: MATTHEWS <matthews@vax1.acs.udel.edu>
Subject: New xkuker (C-Kermit) Bugs on Pyramid
Keywords: C-Kermit, Pyramid
I have found two problems so far with the newest version 4E(066) of kermit.
Here is what happens when you try to run it on Pyramids version of UNIX (OSx).
Script started on Sun Aug 9 23:56:57 1987
udccpyr1% cd
udccpyr1% cat .kermrc
echo
echo set file type BINARY
set file type BINARY
echo set file names LITERAL
set file names LITERAL
echo
set prompt "C-Kermit@pyr1>"
udccpyr1% cd /usr/tmp/kermit
udccpyr1% ./wermit
set file type BINARY
set file names LITERAL
C-Kermit, 4E(066) 4 Aug 87, 4.2 BSD
Type ? for help
set file type binary 8
bad
?Invalid - bad
Fatal: Kermit command error in background execution
udccpyr1%
script done on Sun Aug 9 23:58:00 1987
I get no prompt or anything, it just exits with this error message. It
appears as though it thinks I want to run it in the background. I compiled
kermit the same exact way with the "bsd" flag on both machines and it does
different things on each one.
[Ed. - I noticed some similar behavior on a system running 2.9BSD. The problem
can be traced to the conint() function in xkutio.c, where the program attempts
to determine whether it's running in the background by testing some signals,
etc. Apparently, there is no universally valid way (at least none that I know
of) for doing this, so the same test will give different results on different
systems. If Kermit thinks it's running in the background, then errors in
'take' files (including .kermrc) are fatal. Unix wizards are invited to take a
look at the conint() function and suggest a better way of checking for
background operation.]
The second minor bug that I discovered when trying to run kermit on our Vax
8650 running 4.3 BSD is that SET PROMPT isn't working correctly. A command in
a .kermrc file such as "set prompt C-Kermit@vax1>" doesn't change the prompt.
It appears to work okay when you type it at command line.
[Ed. - Yes, that's a bug. It'll have to be fixed. See below.]
Sorry I can't be specific to where exactly the problems are within the source;
I only kept it on the machines long enough to compile it. I have a 1000 block
quota.
John Matthews
------------------------------
Date: Sat, 29 Aug 87 15:37 EST
From: <RICK@QUCDNAST.BITNET> (Rick Pim)
Subject: C-Kermit 4E Amiga .BOO File
Keywords: C-Kermit, Amiga
The Aug 7 info-kermit digest mentioned a new release of C-Kermit
for, amongst other things, the Amiga. According to the directory I looked
at of cki* *, the BOO file is new. The digest requested comments/etc, so I
ordered the BOO file and decoded it today. According to the header once
it's running, the version is 4D. It has at least one of the same bugs as 4D
(parity does not work).
[Ed. - Right, we don't have an Amiga .BOO file based on the new version yet.
We were hoping somebody would make one. See next message.]
------------------------------
Date: Wed, 12 Aug 87 10:25:42 pdt
From: cit-vax!ametek!walton@RUTGERS.EDU (Steve Walton)
Subject: C-Kermit 4E(066) on Amiga, and Long Packet Problem
Keywords: C-Kermit, Amiga
Well, I grabbed C-Kermit 4E(066) from CU20B, and have been able to compile and
link a running version on my Amiga using Manx Aztec C V3.40b. In the process,
I added the appropriate include files and the DOSFH and FILENO macros for Manx
C to ckiutl.c and ckitio.c; diffs will follow shortly. (One thing which was
easy: parity can be ignored in ttinl(), since the Amiga's serial.device
handles it itself, and passes characters to Kermit with the parity bit already
stripped.)
However, I have hit what appears to be a major bug: 4E(066) will not use long
packets when talking to itself. I have built the BSD version of 4E(066) on
our 4.3BSD 780 using "make bsd", and tested it in a loop mode by phoning the
machine from one of its own dialout lines. After a "set send packet-len 150"
and "set receive packet-len 150" on both ends, it does not use long packets,
but rather the standard ones. This also happens when connected to the 780
from my Amiga at home.
One minor bug, easily fixed: the help information for set send packet-len
still says that the maximum packet length is 94.
Stephen Walton, walton@ametek.UUCP
Ametek Computer Research Div.
610 N. Santa Anita Ave.
Arcadia, CA 91006 USA
818-445-6811
[Ed. - See next message.]
------------------------------
Date: Fri, 14 Aug 87 14:28:04 pdt
From: Steve Walton <cit-vax!ametek!walton@RUTGERS.EDU>
Subject: 4E(066) Long Packet Problem Followup
Keywords: C-Kermit
After reading the docs for 4E(066) (RTFM, right?) I tested it again talking to
itself on my 4.3BSD 780. This time, the only set command I did was a "set
receive packet-length 300" on the receiver. This time, long packets were
used. If I also naively do a "set send packet-length 300" on the sender,
short packets are used. I think this is still a bug, but not quite the one
I'd reported previously.
[Ed. - "set send packet-length" is used to override negotiations. Apparently
it doth override them too much. This will have to be fixed.]
------------------------------
Date: Sat, 22 Aug 87 14:21:56 cst
From: ihnp4!sask!reid@seismo.CSS.GOV (Irving Reid)
Subject: C-Kermit on Pro 350 / Venix V1
Keywords: C-Kermit, Venix, Pro-3xx
Is anyone else running C-Kermit on Venix V1? I'm having all sorts of
problems - dial scripts always crash, crashes at >300 baud, etc. I'm
dragging down the new experimental version to see if it gets better; I'll
let the world know how that turns out.
[Ed. - We had Venix V1 systems here once, but no longer, so were unable
to test the new C-Kermit on them. Anybody?]
As an aside, for those of us with limited bandwidth to the outside world
would it be possible for new versions to come with a concise list of which
files have changed, so we don't need to take the whole thing? Better yet,
since many people in the Unix world have Larry Wall's "patch" program, new
versions could be distributed as diff's against the old; this should save
lots of network time for such a large program.
[Ed. - Desirable, but in this case, all the files changed, and in most cases
the diffs would be larger than the original files.]
- irving - (reid@sask.uucp or {alberta, ihnp4, utcsri}!sask!reid)
"Warning: don't use braces, tildes, circumflexes or double quotes as
delimiters - chaos will result"
------------------------------
Date: Tue, 25 Aug 87 16:08:53 PDT
From: Mick Laver (ACC Microconsulting) <zz1ml%sdcc3@sdcsvax.ucsd.edu>
Subject: C-Kermit Version 4E(066) Results on Celerity, Pyramid, 3B20
Keywords: C-Kermit, Celerity, Pyramid, ATT 3B20
The new C-Kermit compiled succesfully under BSD 4.3 systems on Vaxes and a
Celerity, under Sys V on a 3B20, and under the Pyramid 90X's "dual-universe"
bsd4.2/sys5. Also compiled under VMS 4.5, but I didn't test it there other to
determine that it compiled and ran.
Results:
Worked ok on all 4.3 and Sys V systems (see below).
Did NOT work on the Pyramid. While it would compile and run, if you said
"send file" or "receive" it would go back to the C-Kermit prompt. Command
line send or receive just went back to system prompt. One of our systems
programmers looked at it briefly and couldn't find the problem. He said he'd
look further and I'll send a follow-up if he gets anywhere.
[Ed. - See next message for Pyramid fix.]
Binary tranfer problem: Our 4.3 VAX C-Kermit would send binaries incorrectly
if no parity was used with extended packets. If 8th bit prefixing was used
(set parity space on MS-DOS Kermit 2.29b) the files would go OK. When
"normal" sized packets were used binary xfer worked fine either way.
[Ed. - This one will have to be checked...]
Mick Laver, ACC Internet: laver@sdcsvax.ucsd.edu
C-010 U.C.San Diego UUCP: ...!sdcsvax!sdcc3!zz1ml
La Jolla, CA.92093 Ph: (619) 534-4060
------------------------------
Date: Tue, 25 Aug 87 00:43:07 EDT
From: Paul Placeway <paul%tut.cis.ohio-state.edu@ohio-state.ARPA>
Subject: Bugfix for C-Kermit 4E(066) on Pyramid
Keywords: C-Kermit, Pyramid
I ftp-ed the sources for beta 4E from cu20b, and had a bit of a problem making
it work on a Pyramid 98x under the BSD universe. After poking around a bit, I
discovered that the ttpkt() routine was failing when everything seemed fine,
so I looked hard at the code and discovered what looks like a place where
someone forgot to flesh out an #ifdef. After changing ckutio.c in the
following way, C-Kermit seems to work fine. Here are my diffs...
*** ckutio.c.orig Thu Aug 20 11:43:52 1987
ckutio.c Mon Aug 24 23:54:58 1987
***************
*** 912,917
ttflui(); /* Flush any pending input */
return(0);
#endif /* bsd4 */
#endif /* myread */
#endif /* not uxiii */
912,920
ttflui(); /* Flush any pending input */
return(0);
#endif /* bsd4 */
+ #else /* myread */
+ ttflui(); /* Flush any pending input */
+ return(0);
#endif /* myread */
#endif /* not uxiii */
Paul Placeway
Department of Computer and Information Science
SNail: The Ohio State University
2036 Neil Ave. Columbus OH USA 43210-1277
ARPA: paul@ohio-state.{arpa,csnet}
(soon): paul@cis.ohio-state.edu
UUCP: ...!cbosgd!osu-eddie!paul
(soon): ...!cbosgd!cis.ohio-state.edu!paul
[Ed. - Many thanks!]
------------------------------
From: Markku Toijala <mcvax!kolvi!mto@seismo.CSS.GOV>
Date: Wed, 26 Aug 87 14:52:48 EET DST
Subject: C-Kermit 4E fixes for BSD 4.3
Keywords: C-Kermit
I have been setting up C-kermit 4E on microvax II running BSD 4.3. Here are
the modifications I found necessary:
1) Add seteuid/seteguid to allow (remote) shell commands when using
csh as login shell. In 4.3 it seems that csh checks for uid/gid
before starting itself. Effects can be seen when you run sgid to give
only kermit access to an outgoing line.
[Ed. - This area wasn't addressed by 4E(066); older releases are the same.]
2) KERMRC was defined only in ckuusr.c, but also ckuus2.c used it to
get init filename -> you did not get indication of it with "show para".
Moved the stuff to ckuusr.h
[Ed. - Right you are, "show" doesn't list the init file name. This will be
fixed.]
3) Moved setting of default prompt to take place before reading .kermrc.
Now you can have "set prompt" command in it ...
[Ed. - Right again.]
4) Removed . from Extendend-length packets ... - string.
There may still be something wrong with long-packets, but i have not had time
to look at that yet.
[Ed. - Yes, see above.]
Markku Toijala ! UUCP: kolvi!mto
Helsinki University of Technology ! Internet: mto@kolvi.hut.FI
Otakaari 5 A ! EARN: PUH-MT@FINHUT.BITNET
SF-02150 Espoo, Finland ! tel: +358 0 4512011
[Ed. - Many thanks! Diffs added to XKUKER.BWR.]
------------------------------
Date: 27 Aug 87 10:55:00 EST
From: "SRLVX2::KABERLINE" <kaberline%srlvx2.decnet@ford-vax>
Subject: Problems with C-Kermit 4E(066) on VAX/VMS
Keywords: C-Kermit, VAX/VMS
Recently downloaded the new experimental new release of C-Kermit, version
4E(066). I compiled and tested it on both systems I have access to, a
Masscomp (unix), and a VAX 8600 running VMS V4.5. I am writing this to report
a few minor problem I've noticed, mostly when running under VMS:
1. During the building of wermit under VMS, I got an error
message while linking:
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, SYSCLEANUP
%LINK-W-USEUNDEF, undefined symbol SYSCLEANUP referenced
in psect $CODE offset %X00000B6E
in module CKUUSR file CKUUSR.OBJ;1
[Ed. - Right, a syscleanup() function should be added to CKVTIO.C. It doesn't
necessarily have to do anything...]
2. Under VMS, the "cwd" command does not appear to work?
[Ed. - This is done by the function system(), defined in CKVFIO.C, called
with the argument PWDCMD, which is apparently undefined for VMS. Oops!]
3. A "dir" command is *NOT* equivalent to a "dir *.*" command under
VMS; both commands produce identical output on the Masscomp.
4. Finally, I can't seem to get the long packets to work. I
set the send and/or receive packet size on both ends, then
try to send a file from/to VMS/Unix. The files transfer OK,
but when I then do a "show parameter" command, the packet
sizes displayed is 94??
[Ed. - You should avoid "set send packet-length" and only use
"set receive packet-length" on the receiving end, till "set send
packet-length" is fixed.]
Haven't noticed anything else yet, but I'll keep experimenting and report
anything else I might discover.
Thanks!
Steven Kaberline (Kaberline@ford-vax)
Ford Motor Company
Scientific Research Labs, Rm. S-3061
P. O. Box 2053
Dearborn, MI 48121 USA
(313) 323-2248
------------------------------
Date: Thu, 3 Sep 87 08:26:14 EDT
From: Marshall_DeBerry@um.cc.umich.edu
Subject: C-Kermit 4E Problems on Tandy 16A/6000 and Arete 1200
Keywords: C-Kermit, Tandy 16A/6000, Arete 1200
I've tried out the new 4E(066) release on a Tandy 16A/6000 and Arete 1200 under
System V.2. One problem I've noticed is that if you try to get the status
of the transfer, as soon as you type Cntrl A, the transmission begins to
send %T's, and eventually times out. This was during file transmissions
between the Arete and MTS Kermit. It was also reproducible between the
Arete and Tandy machines.
[Ed. - This sounds like something pretty specific to your machine; Ctrl-A
status reports work ok on the machines we've tested. I hope you can track it
down.]
Another had to do with setting long packets. If I set the Tandy end to send
at a length of 900, and the Arete end to receive at 900, when I put the Tandy
end into server mode, the transmission begins, but terminates immediately with
an OK. If I only put the receive end at a length of 900, things go fine. (900
is just an arbitrary number I picked) .
[Ed. - Right, see above.]
The program compiled cleanly on both machines, except that on the Tandy end
(running under Xenix 3.1.2), I had to include <sys/types.h> for one of the
files in which void is used.
------------------------------
Date: Mon, 17 Aug 87 21:45 MDT
From: <JRD@USU.BITNET> (Joe Doupnik)
Subject: C-Kermit 4E Feedback
Keywords: C-Kermit, ATT Unix PC
A couple of comments on the new test C Kermit:
1. signal() returns type "int" on my Unix PC running AT&T sys5r3, just like
everyone else, yet the conditionals in the code specify "void" for only
sys5r3. So here we have an exception to the cast in steel Standard Edition of
Unix from the horse's mouth. Btw, release 3 here means 3.0 whereas in-house at
AT&T they are up to 3.5 at last reading.
[Ed. - Oh, so sys5r3 is not the same everywhere... Well, since the type cast
for signal() is the only difference in Kermit between sys5r3 and sys5r2 (or,
for that matter Sys3), then use "make sys3" or "make sys5" (which is an alias
for "make sys3").]
2. The file statistics display indicates files are always transferred with
type 1 block check, even though I have type 3 set in both .rkermit and on the
remote machine and sometimes set it that way by hand in C Kermit.
[Ed. - Will investigate this.]
3. When the dust settles Lint (no pun intended) ought to be run across the
code to pick up the loose ends. My Lattice C compiler on the AT machine is
more picky than the standard Unix compilers and lets me know to do better next
time, sigh. You'd think it wanted us to be (gag) Pascal programmers. On the
other hand, you may have done so and we are seeing Unix vs ANSI in action.
Can't win either way.
[Ed. - No, I was scared to Lint it, but I will.]
4. Otherwise, it works just great! Throughput is way up. Whereas the
previous release yielded about 10-12Kbaud across STARLAN to my AT this version
indicates 18+Kb the same way. That's with 1000 byte packets.
Regards,
Joe D.
------------------------------
From: sob@watson.tmc.edu (Stan Barber)
Subject: C-Kermit Lock Files
Date: 20 Aug 87 21:26:17 GMT
Keywords: C-Kermit, Unix Lock Files
I should point out that C-Kermit(041) does handle lock files correctly under
BSD4.3 with the 4.3UUCP locking structure. This creates a lock directory
(/usr/spool/uucp/LCK) that is publically writable and each program (except
kermit) using the locking protocol is smart enough to test for dead locks
(coming from programs that aborted and did not remove its lock).
Stan
[Ed. - Presumably, this is also true for 4E?]
------------------------------
End of Info-Kermit Digest
*************************
-------
10-Sep-87 16:54:08-EDT,27020;000000000000
Mail-From: SY.FDC created at 10-Sep-87 16:53:23
Date: Thu 10 Sep 87 16:53:23-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #19
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12333579082.204.SY.FDC@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Thu, 10 Sep 1987 Volume 6 : Number 19
Today's Topics:
New Copy of MSTIBM.BOO
Documentation for MS-Kermit 2.29C and 2.30
Proposed Extensions to Kermit Protocol
Update to UCSD p-System Kermit for Terak
C-Kermit on the Unix PC
4E(066) on NCR Tower Works Fine
Sperry 1100 Kermit Retires
More on Multiple CDC Kermits
Kermit 80 Version 4.08 (pre-release) Files
EBCDIC and ASCII Definitions
Transferring WordPerfect Files
MSBPCT.PAS
7171 Causes CMS Kermit Problems When Flow Control Used
Need HP150 Kermit on diskette
Kermit for a Bondwell?
VMS Kermit version 3.2.076 STATUS Command
----------------------------------------------------------------------
Date: Wed 2 Sep 87 10:09:44-EDT
From: Christine Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: New Copy of MSTIBM.BOO
Keywords: MS-DOS Kermit
Some people were experiencing problems downloading the new KER:MSTIBM.BOO
(2.29C, 16 Aug 87) file. There is now a new copy, same name, which we have
downloaded and un-BOO'd with no difficulties. No release changes have been
made to this version.
------------------------------
Date: Thu 10 Sept 87 15:36 EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Documentation for MS-Kermit 2.29C and 2.30
Keywords: MS-Kermit 2.29C
In response to the many complaints and questions about the latest MS-Kermit
pre-release: Some of the more obvious incompatibilites between 2.29B and
2.29C (which is pretty much what 2.30 will look like) are:
- SET KEY and SHOW KEY commands use different key identifications and
syntax. This is a big one.
- CLEAR command now means clear serial port buffer rather than clear key
and macro definitions. Key and macro definition string space is now
garbage collected, so a CLEAR command for them is no longer necessary.
- CLRINP command is gone (replaced by CLEAR).
- Numbers of the form \nnn now default to decimal rather that octal.
- "LOG filespec" replaced by "LOG SESSION filespec" and "LOG PACKET
filespec".
- The LOCAL command prefix has been removed from 2.30.
Most of these incompatibilities will break your MSKERMIT.INI or other command
or script files, but each has a rationale. A draft version of the manual for
2.30 (which applies to 2.29C as well) has just been completed. It's in
KER:MST29C.DOC (SCRIBE text formatter source in KER:MST29C.MSS) on CU20B and in
MT29C * on CUVMA for KERMSRV access. Suggestions for the final draft are most
welcome.
------------------------------
Date: 14th August 1987
From: Chris Kennington (cjk%r-d.salford.ac.uk@cs.ucl.ac.uk)
Subject: Proposed Extensions to Kermit Protocol
Keywords: Kermit Protocol Extensions
I am currently implementing a Kermit facility to go into a
private ViewData system. This is a commercial contract, so what the
customer says he needs has to be supplied. We may end up with something
which ought to be called "Kermit compatible" rather than Kermit, but that's
life. The environment is MSDOS on a micro; hence the multithreading nature
of the code, which I discussed with you a few months ago.
There are two specific things which the user requires beyond the
normal Kermit protocol. He wants other parts of the host program to be able
to send messages (single-liners) to the terminal's screen at any time during
a file transfer; and he wants the terminal to flip automatically from
connect into send or receive mode any time it starts to receive a I/S/R
packet from the host (so that the transfer can be fully initiated from the
host end, the converse of server operation).
I would like to fit these in in as clean a way as possible. My
current plan is as follows, but I should be glad of comments, particularly
if you either think there is a better way or have plans for extension of the
protocol in either of these directions.
Chris K.
MESSAGES TO SCREEN
This must be divided into two cases; message going in the same
direction as the data, and message going against the data.
For the first case, I propose to define a new type of packet
which can be interleaved with the data-packets. Rather than choose a new
letter I propose to reuse the generic message (G-M) codes. Normal rules for
sequencing would apply.
For the second case, I propose just to put data into the next
ACK, starting the data with a blank so that it cannot be confused with a
cancel-transmission request.
The first suggestion is not backwards-compatible unless it is
counted as a new "capas". I would like to be able to negotiate it, so that
the same program could be used to work both standard Kermits and the Kermit
facility in this customer's integrated ViewData terminal program.
The second ought to be transparent to existing Kermits.
AUTOMATIC TERMINAL RESPONSE
I propose that, whenever in connect mode, the terminal Kermit
detect any SOH received, check to see whether the next few characters are
compatible with the header of a Kermit I, S or R packet, and if so flip into
the appropriate transfer mode. At the end of the transfer it would flip
straight back to Connect mode. The rationale is that, in a ViewData system,
the user always feels that he is working the ViewData host rather than a
local micro, so he wants to have host-commands (sent in terminal mode)
executed forthwith.
The ViewData screen-driving protocol does not make use of SOH as
a control character as far as I know.
When working to a normal host Kermit, this code would never be
triggered except by some unexpected binary garbage.
[Ed. (Frank) - Your ideas sound reasonable. We considered the idea of
screen messages when first designing the protocol, but didn't include them
because there could be no guarantee that the user would be there to read
them.
You can put anything in an ACK you want, so long as you start it with a
space, and it won't interfere with existing Kermits. Let's say that if an
ACK to a data packet contains text starting with space, then the text is to
be displayed on the screen (or added to the user's mailbox, transaction log,
or whatever), or can be ignored altogether (as existing Kermits will do).
For messages in the same direction as the data, I'd actually recommend a new
packet type, "M", rather than a G packet of subtype M, because a G packet
only occurs at the start of a transaction. The use of such a packet would
indeed have to be negotiated. Let's provisionally assign capability bit #6
for this. This would mean that we overflow into the second capability word,
and have to set the low order bit in the first one to indicate that this has
happened. Obviously, M packets will not be sent unless both Kermits set
capability bit #6 in the negotiation phase. Does anyone have any serious
objections to this protocol extension? Like all other extensions, it's
compatible with existing versions, because it won't be used unless both
sides agree.
Automatically flipping into protocol mode when a packet arrives during connect
is an implementation decision, but probably there should be a command to defeat
this. Not only must you worry about noisy lines, but also those cases where
the user might actually display a file that contains examples of Kermit
packets, and also for debugging purposes.]
------------------------------
Date: 19-AUG-1987 11:11:20
From: Nick Rothwell, University of Edinburgh.
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Update to UCSD p-System Kermit for Terak
In the following you will find two of the pieces of UCSD pSystem Kermit
which I've altered to handle text files properly - binary file transfer is
right out because, apart from anything else, the pSystem II.0 BIOS can't
read/write binary files byte by byte correctly, so that's a non-starter.
I originally fixed the bug that the receive routines expected the sequence
'#M#J' to occur together, so a '#M' at the end of a message followed by '#J' at
the start of the next got things confused. The final fix is to totally ignore
all '#'-codes except the sequence '#M#J' (whether adjacent or not), so as to
ensure reliable text file transfer *without* confusing the filing system with
unexpected control characters.
The changes are to RECSW.TEXT and KERMIT.TEXT which are part of the
concatenated source [.UCT]UCTERAK.PAS. Diff listings for these two files are
below.
Nick Rothwell, Laboratory for Foundations of Computer Science,
University of Edinburgh.
ARPA: nick%{cstvax,itspna}.ed.ac.uk@cs.ucl.ac.uk
JANET: nick@uk.ac.ed.{cstvax,itspna}
UUCP: <Atlantic Ocean>!mcvax!ukc!{cstvax,itspna}!nick
[Ed. - Many thanks, Nick. Your changes have been placed in UCTERAK.BWR.]
------------------------------
Date: Sat, 5 Sep 87 18:06:19 EDT
From: David Herron E-Mail Hack <david@ms.uky.edu>
Subject: C-Kermit on the Unix PC
Keywords: C-Kermit, Unix PC
Joe Doupnik of USU.BITNET says "signal() returns type 'int' on my Unix PC
running AT&T sys5r3 ..."
He's getting confused over the numbering scheme(s) for SysV's.
The SysV on the Unix PC is NOT the same SysV as the mainstream that is
currently up to SysVr3.1 (i.e. a little past SysVr3). The SysV there
started as Convergent's port of SysVr1 (or r0, since they hadn't subdivided
SysX's into "releases" at that time) ... This port was different from the
standard SysV of the time (for instance, it had full-fledged virtual memory
... something which didn't get into the mainstream SysV until one of the
sub-releases of SysVr2).
The current version of Unix PC SysV is 3.5.1. It has had some SysVr2
features tossed in and eventually may be re-integrated with the mainstream
versions, but is still a different version of Unix.
Hope this clears up some confusion -- you may want to put these remarks into
a README of some sort in the CKermit distribution.
BTW, some people here had fixed up a C-Kermit which worked well with the Unix
PC's, but they didn't think about sending in their code. I'm going to point
them at this experimental version and get them to re-do their stuff for this
version... and by-golly, I think they'll send in their stuff to y'all this
time around too ... :-)
------------------------------
Date: Sat, 5 Sep 87 19:00:39 edt
From: lbafrin@tecnet-clemson.ARPA
Subject: 4E(066) on NCR Tower Works Fine
Keywords: C-Kermit, NCR Tower
I sure am glad we're back in touch with Info-Kermit, here at the TECNET
project at Clemson University. (Due to network problems, we had been
offline for more than a year.) As soon as I saw (in the latest digest) that
4E(066) had long packets, I FTPed it from CU20B, ran the "make sys3" on our
NCR Tower 32 running NCR's Tower O.S. version 3.something (flawless "make,"
by the way), and then started testing. I'm happy to report that it works
just fine (except for the "too powerful" "set send packet-length" command as
previously reported in the Digest), and it even cleared up a *long*-standing
problem we've had with using it to upload via TELENET and even parity to the
Tower 32, a problem whose source we were never able to pinpoint (Kermit,
Tower, or TELENET?) despite a huge number of hours of debugging time.
Keep up the great work, froggers!
-- Larry Afrin
TECNET Project
Dept. of Computer Science
Clemson University
lbafrin@tecnet-clemson.arpa
------------------------------
Date: Tue 1 Sep 87 13:42:01-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Sperry 1100 Kermit Retires
Keywords: Sperry 1100 Kermit
The University of Wisconsin is retiring its Sperry 1100, and Paul Stevens,
the author of Sperry 1100 Kermit, will no longer be able to actively
support the program. Is anyone out there willing to take over? Volunteers
please send mail to Info-Kermit@CU20B.COLUMBIA.EDU, or write to the Kermit
Distribution address (network-connected volunteers preferred). Thanks to
Paul for all his contributions to Kermit culture over the years!
------------------------------
Date: Thu, 11 Dec 86 14:02:15 cst
From: knutson@huey.cc.utexas.edu (Jim Knutson)
Subject: More on Multiple CDC Kermits
Keywords: CDC Kermit
RE: [Steve Roseman <LUSGR@LEHICDC1.BITNET>: More on Multiple CDC Kermits]
Personally, I feel that the CDC versions of kermit for the version I wrote
(the fortan version), should probably be split into seperate versions. The
code for trying to manage several operating systems and approximately 5
different character sets is horrendous. I would be in favor of ripping out
all non-nos code (that means NOS/BE and, sniff, UT-2D). A NOS/VE version
will probably have to be done seperately because of the word size
differences and all. I have not had many calls from NOS/BE sites lately and
very few calls from NOS/VE sites as well.
However, I must say that I really haven't been maintaining the Cyber version
of Kermit for quite a while now so perhaps my suggestions should be tempered
by that.
------------------------------
Date: Sun, 23 Aug 1987 15:02 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: Kermit 80 Version 4.08 (pre-release) Files
Keywords: CP/M Kermit
With great expectations I today got the KER:CX*.* files for the CP/M Kermit
4.08. Imagine my surprise to find that all the ASM modules which previously
had been individual files for ease in editing were now all together in one
HUGE 780k file!!!
The ONLY reason that LASM was used in the first place, instead of the stock
CP/M assembler, was so the pseudo instruction LINK could be used at the end
of each module.
The present form of the source code is, in my opinion, unusable. Bertil has
removed ALL tabs from the source, making it even larger. His reasoning was
that people were messing up the source by getting it through hosts that
change a tab to a single space. This is probably true, but the file is too
large to handle. It must be broken down into its individual modules again
to make it manageable by potential users. I can't even edit it on my CP/M
DDDS 1.2 megabyte floppy system.
Keith
[Ed. - Our fault. We had to crunch the files together because of a severe
space problem on our tapes. As you know, file marks are expensive. The
idea is that once some CP/M aficionados like yourself get a chance to try it
out and bless it, it can replace the old CP/M Kermit files, KER:CP4*.*, and
then there will be plenty of room to store the files separately. For now,
and for FTP access only, the .ASM source files are available separately as
K7:CP*.ASM on CU20B (note, K7). Please take them and try them out, and send
any comments to Info-Kermit@CU20B, whence they will be relayed to the
author, Bertil Schou at Loughborough University in England, who is anxious
for feedback. By the way, the files were joined together using a simple
Unix Bourne shell script, a copy of which is in K7:JOIN.SH. They were
unjoined with a C program, which is in K7:UNJOIN.C.]
------------------------------
Date: Mon, 24 Aug 1987 10:15:10 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: EBCDIC and ASCII Definitions
Keywords: EBCDIC, ASCII, Multinational Character Sets
EBCDIC definition from the "Principles of operations" IBM manual only covers
English characters and is old story.
There is now an ISO 8859 definition for EBCDIC. It extends the code to other
languages needs. Because you can imagine all languages don't fit in a 256
set, the standard is split into mutltiple definitions of which the most
widely used is ISO 8859/1 (Latin Group 1). It is a superset of the former
EBCDIC, but shows some trouble with the former loose definition of brackets,
vertical bar and exclamation mark.
IBM has started using ISO 8859/1 with its so-called table 500. They have a
3274 RPQ 7L0577 and various peripheral support for it.
ASCII has its own ISO extended definition(s?) too, but I'm sorry not to know
the number. However I can say IBM now started using it in an alternate
codes definition for its new PS/2 microcomputers series. They put it a name
of their own blend: "Code page 850".
So, if anyone does not know what to do with undefined EBCDIC and ASCII
codes, here is the answer to increase a program's usability by a factor.
These standards are probably not well known in America, because of little
need, but it's relieving that IBM now accepts international standards and
uses its position to promote them.
[Ed. - 7-bit ASCII is ANSI standard X3.4 and ISO 646 and CCITT T.50.
ANSI X3.32 specifies graphic renditions for control characters.
ANSI X3.41 and ISO 2022 give 8-bit code extension techniques for ASCII.
ANSI X3.134.1 & ISO 4873 specify an 8-bit code for information interchange.
ANSI X3.134.2 specifies an 8-bit ASCII multilingual character set.
ISO 6937 specifies coded character sets for text communication.
See discussion about Swedish character sets in Info-Kermit V5 #1, 14 Jul 86.]
------------------------------
Date: Wed, 26 Aug 87 19:59 CDT
From: Dave Bell - ACADEMIC CONSULTANT (U. of Winnipeg) <UOWDJB@UOFMCC>
Subject: Transferring WordPerfect Files
Keywords: WordPerfect
I'm having problems transferring a WordPerfect file. The file I'm trying to
transfer (PC to a VAX) contains the WordPerfect document plus the printer
ESC codes. When I try to Kermit it across I get the following error from
the VAX Kermit:
%KERMIT32-E-REC-TO-BIG Record to big for kermits internal buffer.
Can anybody help with this, as I'm a novice user of Kermit I'd appreciate
any help I could get. Thanks in advance.
David Bell
Academic Consultant
Computer Services
E-mail: UOWDJB@UOFMCC.BITNET
V-mail: 204/786-9494
S-mail: Computer Services,
The University of Winnipeg,
515 Portage Avenue,
Winnipeg, Manitoba,
Canada R3B 2E9
[Ed. - Most likely, Wordperfect is delimiting lines with special codes,
rather than CRLFs, so that the VAX does not recognize the intended lines as
separate records. Rather, it sees them all as one very long record, which
causes its record buffer to overflow. Unfortunately, VMS Kermit doesn't
provide a mechanism to expand the buffer size. Workarounds would be (a)
transfer it as a binary file, or (b) translate to regular ASCII text before
transmission.]
------------------------------
Date: 30 Aug 1987 20:58-CDT
From: SAC.DYESGPF@E.ISI.EDU
Subject: MSBPCT.PAS
Keywords: MSBPCT, .BOO Files
After I read about the improved performance of MSBPCT.PAS (compared to
MSBPCT.BAS) I down-loaded this file from Columbia and tried to use it. My
compiler gave 33 warnings and 50 errors. I am using a MicroSoft v3.11
compiler which is essentially a UCSD compiler with system enhancment.
Additionally, I have modified the BEGXQQ module (specifically the DOSXQQ)
routines to allow full use of the MS-DOS v3.xx function requests and full
access to registers. This has not presented any problems when modifying and
recompiling programs created prior to making the mods.
I assume that this program was written for turbo-pascal since it is not
compatible with either "standard" or UCSD PASCAL (yes - there are switches
which can be entered on the command line to make the MicroSoft PASCAL
compiler act like a less capable compiler).
If anyone knows a source for a public domaine turbo compiler, I would
appreciate pointers. Since I mostly program in assembly and turn to PASCAL
only when string manipulation is too complex or the program is exteemly long
I will not spend my money on a turbo compliler.
Although I realize there may be some who disagree with me, I suggest that any
future postings in PASCAL be more generic in nature.
Al Holecek
SAC.DYESGPF@E.ISI.EDU
[Ed. - We can't discourage people from writing in Turbo Pascal -- it's fast,
cheap, and a lot of people have it. Microsoft or IBM Pascal may be more
standard, but it's less common in the world due to price. Anyway, there are
versions of MSBPCT also written in Assembler and C. The C version is also
available in .BOO file form, so you don't need a C compiler to run it, just
MSBPCT.BAS to translate it to .EXE form (and then you don't need MSBPCT.BAS
any more.]
------------------------------
Date: Mon, 31 Aug 87 11:09:50 CST
From: Mike Sorsen <SORSEN@WUVMD.BITNET>
Subject: 7171 Causes CMS Kermit Problems When Flow Control Used
Keywords: CMS Kermit, 7171, Yale IUP
There is a bug in the 7171 that causes CMS Kermit file transfers to abort in
the middle of a SEND after a large number of retries. The symptoms are that
during a SEND by CMS Kermit through a 7171 CMS Kermit violates the Kermit
protocol by retransmitting a packet before other Kermit can respond when
XON/XOFF flow control was used by the receiver or when XON/XOFF flow control
was used by other hardware in between the 7171 and the receiver.
This bug was observed using CMS KERMIT 3.1 running under VM/SP 3.1 (PUT 8409
SLU 311) through a 7171 at EC A31864 to MS-DOS Kermit version 2.29b.
I have not done any testing with 4994s or Series/1 boxes running the
Yale IUP. They provide the same function as the 7171 for an IBM host.
The sequence of events is this:
CMS Kermit sends a packet using transparent write/read. The receiver or
other hardware in between the 7171 and the receiver sends a pacing stop
(XOFF) and then a pacing start (XON) to the 7171 while the packet is being
sent by the 7171. The 7171 performs the pacing, but when the transparent
write part of the transparent write/read is complete it ends the transparent
read prematurely, returning X'93' (XOFF) to Kermit as the reply to the
packet sent out. CMS Kermit rejects this and retransmits the packet, which
causes a breakdown of the Kermit protocol. The breakdown occurs because the
recieving Kermit usually starts transmitting an ack to CMS Kermit while the
packet is being retransmitted.
I am currently chasing this problem though the IBM support structure, but I
doubt that they will issue a new EC for this problem.
Circumventions:
Set the 7171 flags so that XOFF is not a valid termination of a transparent
read. See page 4-20 of 'IBM 7171 Reference Manual and Programming Guide',
IBM publication number GA27-0021. This has been tested at our site and
found to circumvent the bug even though the XOFFs are being transmitted
during the transparent write part of the transparent write/read order and
this flag concerns the transparent read part of the order.
or
Change the CMS Kermit datastream so that CMS Kermit uses a transparent write
order instead of a transparent write/read order. The CMS Kermit code is
written to allow for either order in the write datastream. The byte at label
WRRD (X'128E' in my assembly) should be changed from X'05' to X'00'. I have
not tested this circumvention.
Mike Sorsen <SORSEN@WUVMD> or <SORSEN@WUCFUA.WUSTL>
Computer Services Systems Group - Campus Box 1152
Washington University - St. Louis, Missouri 63130
Phone: (314) 889-6460
[Ed. - Thanks for the report Mike. This has been added to the CMSKERM.BWR
file.]
------------------------------
Date: 2 Sep 87 00:02:33 GMT
From: sri-unix!cole@RUTGERS.EDU (Susan E. Cole)
Subject: Need HP150 Kermit on diskette
Keywords: HP150 Kermit
I am trying to help someone who has an HP150 obtain a copy of Kermit on a 3
1/2" disk in a format the HP150 can read. The person says she has no
compilers or assemblers so we can't download source code and put the program
together on the 150.
So -- does anyone know how she can get it?
Thanks.
Susan Cole
usenet: !hplabs!sri-unix!cole
ARPA: cole@unix.sri.com
[Ed. - A popular request. Any volunteers? For that matter, are there any
volunteers to distribute ANY versions of Kermit on native media for ANY
systems that Columbia cannot provide?]
------------------------------
Date: Wed, 12 Aug 87 15:54:10 MEZ
From: Erich Neuwirth <A4422DAB%AWIUNI11.BITNET@wiscvm.wisc.edu>
Subject: Kermit for a Bondwell?
Keywords: MS-DOS Kermit
I have a problem with a Bondwell 8 amd Kermit.
I have tried 3 different versions:
MSVIBM hangs the system completely.
MSVGEN does not work. Either it states
Disk error reading device COM1
Abort, Retry, Ignore?
or when i have done
set port 2
I get
?Warning: Cannot open com port
Enter a file handle.
and so on.
Entering 3 does not help, then the system again hangs completely.
MSVCLO works almost
In connect mode it works fine, but as soon as I get out of that mode
status shows baud rate set to 1800. Resetting it and issueing any
transfer command (get, receive, remote dir ....)
generates an error msg about not being able to communicate to host
and then again the baud rate setting is shown to be 1800.
I think the com port must be rather uncoventional in that machine.
Does anybody have any experiences?
P.S.: Setting the other machine to a baud rate of 1800 does NOT help.
------------------------------
Date: Fri, 4 Sep 87 14:47 EST
From: <PEPAP@CFA1.BITNET>
Subject: VMS Kermit version 3.2.076 STATUS Command
I have checked the documentation for recent releases of Kermit-32 and I see
no mention of a problem I have just noticed in version 3.2.076: when I issue
the STATUS command after finishing one or more transfers, the display shows
an effective data rate that is either 0 or garbage (approximately 2**32).
Is this a feature that has never been properly implemented? Has it been
fixed in subsequent releases without being mentioned in the announcements?
We are now running VMS 4.4 - does that have anything to do with the problem?
[Ed. - Wierd. We tried it on VMS Kermit 3.1 and 3.3 under VMS 4.3 and got
correct reports in both those versions. Don't have a copy of 3.2 handy, but
it seems unlikely that it would be broken in 3.2 but not 3.1 or 3.3...]
------------------------------
End of Info-Kermit Digest
*************************
-------
16-Sep-87 19:21:41-EDT,25511;000000000000
Mail-From: SY.FDC created at 16-Sep-87 19:21:07
Date: Wed 16 Sep 87 19:21:07-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #20
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12335178842.151.SY.FDC@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Thu, 16 Sep 1987 Volume 6 : Number 20
Today's Topics:
Announcing C-Kermit 4E(067)
Xenix Experimental C-Kermit 4E(066)
C-Kermit 4E(066) Support on Control Data 180 Mainframes with VX/VE
New Release of Kermit-11 for PDP-11s
Cover on following mstibm.boo (dated 16 Sept)
Insert mode in Kermit 2.29c
Info-Kermit Digests Available in Indexed Form
New Organization of Distribution Tapes Reflected at Okstate
MacKermit on an SE
MacKermit 0.8(35)
Comments on Recent Kermit Digest Items
Re: Proposed Extensions to Kermit Protocol
Kermit-32 STATUS Command
Prime Kermit Source Unpacking
WordPerfect files
Kermit Protocol Curiosity
----------------------------------------------------------------------
Date: Tue 15 Sep 87 18:24:28-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Announcing C-Kermit 4E(067)
Keywords: C-Kermit, Unix, VMS
Now that the beta test of version 4E(066) of C-Kermit (announced in V6 #16)
has had some time to fester, and some good bug reports (and fixes!) have
trickled in, it's time to announce a new release, 4E(067). This one
includes only fixes for the reported bugs, plus a couple of minor additions.
It was tested with VAX Ultrix 2.0 and VAX/VMS 4.3. If it checks out OK on
other systems too, it will replace 4D(066) as the standard C-Kermit release.
Checking out OK means that it is not inferior to 4D(066) in any way, so that
no harm would be done by the replacement. The changes include:
- Fix to allow C-Kermit to run on Pyramid & similar systems.
- The wild "set send packet-length" command was tamed.
- Allow "set prompt" to work, even from init file.
- Problems with packet retransmissions in response to CRLFs should be gone.
- Added dial support for the Concord Condor CDS 220 2400b modem.
- Changed Xenix compilation options a bit.
- New make options for CDC VX/VE, "clean", and "lint".
- Set effective group & user IDs on BSD systems for csh command execution.
- Fix parsing of "show parameters".
- Fix parsing of "remote cwd" from take-command file.
- Breakup of source lines longer than 80 characters.
- Supply missing functions & symbols for VAX/VMS.
- Cosmetic & lint-suggested changes.
See the file xkuker.upd for details. The affected files are (just so you
don't have to transfer the whole 2.5MB collection again):
xkcfns.c, xkcfn2.c, xkcmai.c, xkudia.c, xkufio.c, xkutio.c,
xkuusr.h, xkuusr.c, xkuus2.c, xkuus3.c, xkvfio.c, xkvtio.c,
xkuker.bwr, xkuker.mak, xkuker.upd, xkvker.bwr
available as usual from CU20B via anonymous FTP or on BITNET from CUVMA
via KERMSRV.
There are no new binaries or hex files. People with Unix (any flavor, esp.
Xenix), VAX/VMS, Data General AOS, Macintosh, Apollo, or Amiga systems are
urged to get these files and build the new version from source. Anyone who is
equipped to build this program from source for the Macintosh or Amiga is
further exhorted to do that, and then report any bugs or fixes (or better
still, report if there aren't any!), and if the result is usable, send in
the .HQX or .BOO file.
If no significant problems are reported with the Unix, VMS, or Macintosh
implementations within a few weeks, 4E(067) will become the standard
distributed version of C-Kermit, so that we don't have to carry the CK*.* and
XK*.* files side by side, and that will make room for some new additions to the
"popular minis and mainframes" area (Tape B).
Thanks to everyone who sent in bug reports, suggestions, and fixes -- Joe
Doupnik, David Herron, Steve Walton, Paul Placeway, S.O. Lidie, Jim Guyton,
Phil Julian, Markku Toijala, and many others.
------------------------------
Date: Sun, 13 Sep 87 03:27:29 edt
From: jl42+@andrew.cmu.edu (Jay Mathew Libove)
Subject: Xenix Experimental C-Kermit 4E(066)
Keywords: C-Kermit, Xenix
A thought - you commented (or someone commented) that the "other Xenix
people" (paraphrase) did not report the trouble of redefined stuff from
include files. Well, from the kermit digest it appears that I am the only
other one who reported to you on Xenix CKermit, and this fits as I have
modified my system include files to avoid certain redefinition problems.
Certain modules include redefinitions IF certain other modules have been
previously included. I have #ifndef I_modname'd the sections that would be
repeats, and I define I_modname when a module is included. Hope this
explains the lack of problems in this respect on my end.
Jay Libove
Arpa: jl42@andrew.cmu.edu Bitnet: jl42@drycas.bitnet
UUCP: ...!{uunet, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP: ...!{pitt | bellcore} !darth!libove!libove
[Ed. - OK, the "#include <sys/file.h>" statements are removed from ckutio.c
and ckufio.c in 4E(067). Thanks!]
------------------------------
Date: 12 SEP 1987 22:49 EDT
From: "S. O. Lidie" <LUSOL@LEHICDC1.BITNET>
Subject: C-Kermit 4E(066) Support on Control Data 180 Mainframes with VX/VE
Keywords: C-Kermit, CDC, VX/VE
Xref: Control Data, see CDC
I have ported C-Kermit to Control Data's Unix product, VX/VE 5.2.1. VX/VE
runs under control of NOS/VE, the Cyber 180 operating system.
Only a few mods were needed, all to CKUTIO.C. They were mostly for
selecting line discipline 0, because VX/VE defaults to a special line
discipline 1. The diff outputs for CKUTIO.C and the makefile follow.
Here are some effective baud rates (ebr) at various line speeds and packet
sizes. These rates are essentially the same for both send and receive, so I
averaged them:
1200 4800 9600
----------------------------------
Packet Size:ebr 250: 950 250:5300
500:1000 500:3600 500:6400
1000:1000 1000:3800 1000:6900
83% 79% 72%
Perhaps you would include the following mods into C-Kermit:
[Ed. - Omitted from message, included in 4E(067).]
------------------------------
Date: Fri 11 Sep 87 12:15:37-EDT
From: Brian Nelson <BRIAN@UOFT02.BITNET>
Subject: New Release of Kermit-11 for PDP-11s
Keywords: PDP-11, RSX, RSTS, RT11, P/OS, VA4224 Modem
Kermit-11 3.58 for PDP-11s with DEC and DEC-like operating systems (RSTS/E,
RSX11/M, RSX11/M+, RT11, TSX+, IAS, P/OS, Pro/RT, etc) is now available.
It replaces release 3.54 of September 1986. Changes are relatively minor; they
include:
. SET PHONE TONE/PULSE, SET PHONE BLIND
. VA4224 modem support.
. Allow linking with I/D space under RSTS/E, RSX11M+.
. Fix command macro display (SHO ?)
. Add Ctrl-A status report during local-mode transfers.
. Dynamic record buffer allocation, bigger buffers for I/D space.
. Conditional .INCLUDE's for assembly on RT11 V4 and P/OS.
. Fix sending BREAK for XL on RT11
. SET LINE TTN:/[NO]ALLOCATE for RSTS/E
[Ed. - Thanks, Brian! The new files are in KER:K11*.*, including new
documentation (K11USR.*), available from host CU20B via anonymous FTP
(Internet) or NFT (CCnet), and from host CUVMA on BITNET via KERMSRV.]
------------------------------
Date: Sat, 12 Sep 87 22:55 MDT
From: <JRD@USU.BITNET> (Joe Doupnik)
Subject: Cover on following mstibm.boo (dated 16 Sept)
Keywords: MS-DOS Kermit
The current MSTIBM.BOO file follows (dated 12 Sept) if you want to
do anything with it at this time. I'm off Sunday am to meetings all week.
Regards,
Joe D.
[Ed. - Not sure what's new in this one, but it seems to work OK, so it
replaces the 2.29C version dated 16 August as KER:MSTIBM.BOO on CU20B
(MSTIBM BOO on CUVMA). There's also a somewhat updated draft of the manual
in KER:MST29C.DOC. Feedback appreciated, as the real 2.30 release draws
ever nearer.]
------------------------------
Date: Fri, 11 Sep 87 23:27:06 EDT
From: "James H. Coombs" <JAZBO@BROWNVM>
Subject: Insert mode in Kermit 2.29c
Keywords: MS-DOS Kermit
I asked about this before but have not seen a response. How about providing
some method for making it clear when one is in insert mode? Ideally, the
cursor would get fat. This is a serious weakness in Kermit's terminal
emulation capacities. The problem is aggravated by the fact that insert mode
is automatically toggled off by certain operations. One does not really know
what the mode is until one starts typing. YTERM provides such feedback, so it
obviously can be done.
--Jim
[Ed. - Probably not in the near future. 2.30 is about ready to release.
And also this feature would tickle a bug in early IBM PC ROMs discussed in
past issues of Info-Kermit and Info-IBMPC. Anyway, a real VT100 doesn't do
this... (standard copout).]
------------------------------
Date: Fri 11 Sep 87 11:45:49-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digests Available in Indexed Form
Keywords: Info-Kermit, Digest, Kermit Digest, Index
Info-Kermit Digests Volumes 3 - 6 have been indexed and paginated, so that
information can be easily looked up by topic. The indexed versions, suitable
for printing, are in KER:IMAIL.85B, KER:IMAIL.86A, KER:IMAIL.86B,
KER:IMAIL.87A. Indexing will proceed retroactively back to Volume 1, time
permitting.
------------------------------
Date: Thu, 10 Sep 87 16:22:14 -0500
From: Mark Vasoll <vasoll%a.cs.okstate.edu@RELAY.CS.NET>
Subject: New Organization of Distribution Tapes Reflected at Okstate
Keywords: OK State, UUCP, Dialup Kermit File Access
The new five tape organization of the Kermit distribution has
been duplicated on the Oklahoma State University UUCP and Kermit
server system. The following is the new layout.
/usr/spool/uucppublic/kermit-a -- Tape A (microcomputer versions)
/usr/spool/uucppublic/kermit-b -- Tape B (mini/mainframe versions)
/usr/spool/uucppublic/kermit-c -- Tape C (more micro versions)
/usr/spool/uucppublic/kermit-d -- Tape D (more mini/mainframe versions)
/usr/spool/uucppublic/kermit-e -- Tape E (documents and misc.)
See the "aafiles.dir" file in each directory for exact contents or refer to
"aavers.hlp" for tape name and file name prefixes on specific versions.
Mark Vasoll
Computing and Information Sciences Internet: vasoll@a.cs.okstate.edu
Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers,
Stillwater, Oklahoma uiucdcs}!okstate!vasoll
[Ed. - Thanks, Mark! And thanks for continuing to provide this valuable
service.]
------------------------------
Date: Sun, 13 Sep 87 12:41:28 edt
From: "Robert B. Stam" <stamr%cs.unc.edu@RELAY.CS.NET>
Subject: MacKermit on an SE
Keywords: MacKermit, Macintosh SE
Here's a copy of the fix I had to use to get Kermit to run on an SE (as
opposed to a Plus or earlier). This is a copy of an article posted to
comp.sys.mac
In a recent posting I commented that I was not able to get MacKermit to run
correctly on my Mac SE, and that it seemed to be a problem with fonts. A
local insightful chap suggested that MacKermit as delivered from columbia
might not have a FOND resource. In fact it does not (this is true of both
ckmker.hqx and xkmker.hqx). The fix is as follows:
1) Make a copy of MacKermit.
2) Run Font/DA mover
3) Close the system file fromt the left window
4) Click the left Open button with the option key down (the option key tells
it to open all kinds of files, like MacKermit)
5) Find and open the original copy of MacKermit
6) Click the right Open button with the option key down
7) Find and open the duplicate copy of MacKermit
8) Select and remove the 2 fonts (VT100 etc...) from the right hand window
(ie, from the copy of MacKermit)
9) Select and copy the 2 fonts (VT100 etc...) from the left hand window, thus
copying the 2 fonts from the original copy of MacKermit to the
duplicate copy of MacKermit
10) Close everything and quit. MacKermit should now work.
This is not quite the NOP operation it looks like. When Font/DA mover moves
a font it looks to see if the destination has the appropriate FOND resource,
and if not it adds it.
Many thanks to Oliver Steele of UNC who guessed what the problem was and
suggested that I look for the FOND.
Happy Kermitting ...
Robert B. Stam CSNET: stamr@unc.cs.unc.edu
UNC Computer Science Department ARPA: stamr%unc@mcnc.org
Sitterson Hall 083A UUCP: {ihnp4|decvax}!mcnc!unc!stamr
Chapel Hill, NC 27514 Phone: (919) 962-1826
[Ed. - And many thanks to you for sending in the solution, which has been
added to the Mac Kermit "beware" file.]
------------------------------
Date: Mon, 14 Sep 87 11:08:37 EDT
From: Warren Bell <wbell%gpu.utcs.toronto.edu@RELAY.CS.NET>
Subject: MacKermit 0.8(35)
Keywords: MacKermit
I was under the impression that there was a new version of Kermit for
the Macintosh, with version number 0.8(35), but when I requested
CKMKER.HQX from KERMSRV@CUVMA, I received version 0.8(34), dated March 1986.
Will the new version be available on the Bitnet server?
-Warren Bell
(wbell@gpu.utcs.toronto.edu or wbell@utorgpu.bitnet)
[Ed. - The new version is XKMKER.HQX, not CKMKER.HQX. And even that is not
so new -- it's based on the 4D(061) sources, but changed to compile under
Megamax C, and with a couple cosmetic changes. I hope somebody out there
will build a version of MacKermit, let's call it 0.8(36), from the new C-Kermit
4E(067) sources, and maybe even add material to the dialog boxes to allow
selection of long packets and other new features, and then send in the
resulting .HQX file (and any modified XKM*.* sources).]
------------------------------
Date: Fri, 11 Sep 87 23:39 MDT
From: <JRD@USU.BITNET> (Joe Doupnik)
Subject: Comments on Recent Kermit Digest Items
Keywords: Kermit Protocol Extensions
Regarding the latest Kermit Digest (V6 #19):
1. Chris Kennington's embedded file transfer controls while in Connect mode.
The SOH + stuff combination is a little delicate, as Frank also mentioned.
What about an extension of a DEC escape sequence set: ESC [ ? etc ? This
would be easy to parse and would help maintain ruggedness of the code and
also would not cause a false alarm if transparent printing were active.
The host side would need to start a file transfer with it and the current
version of Kermit-MS can tolerate it as a packet lead-in sequence.
[Ed. - See discussion below.]
2. Dave Herron and Unix version numbers. Thanks Dave. My manuals all say
plain jane sysVr3 and now I know (I think). C-Kermit works solidly on my Unix
PC after removal of the void cast on signal(), for what its worth.
3. Dave Bell and sending WordPerfect files to Kermit-32. Yup, the binary
nature of those files requires SET FILE TYPE BINARY on the VMS side.
[Ed. - More about this below.]
4. Kermit-32 has math problems with effective baud rate. True indeed.
Local Kermit-32 version is 3.3.111 and it solidly reports 2**32.
[Ed. - See below.]
5. Eric Neuwirth and the Bondwell PC. Eric, more than the serial board is
non-standard with your machine. Try Kermit-MS version 2.30 when it appears
and if that hangs your system it is time to find a friend with computer
experience.
6. From Jim Moore, moore@ncsc.arpa: sees "4i" at end of transparent
printing. An old problem fixed some time ago.
[Ed. - i.e. fixed in current MSTIBM.BOO, version 2.29C.]
7. From Walter Mischel, psy1.mischel@cu20b: Control-@ does not send
a null. That's a keyboard definition affair. The real IBM keyboard does
not send a null from any key combination since it is the same as a Control
Break to the Bios. It can be added to the current key definitions as
Set Key \1283 \0
Perhaps this should be made a default definition.
[Ed. - A real VT100 doesn't send a null from ^@ either...]
8. From David Cargo, dscargo@hi-multics.arpa: top rank keys are coupled
to similarly labeled keypad keys for key definitions. Old problem since
fixed. The keypad is fully 'aliased' to separate such keys and allow the
keypad itself to be reconfigured without affecting the top rank keys.
Regards,
Joe D.
------------------------------
Date: 1987 Sep 11 23:21 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Subject: Re: Proposed Extensions to Kermit Protocol
Keywords: Kermit Protocol Extensions
In response to the suggestion of automatic resumption of Protocol mode upon
receipt of any SOH, I'd like to point out that noisy lines are not only
problem. Many Kermits can (and some must) use a packet-marking character
other than SOH, and it seems a pity to trigger on SOH (or on the current
packet character) trusting that said character will never occur for
non-Kermit reasons. I think it would be better to implement a special
Connect-mode command to put the micro-Kermit back into Protocol mode. After
all, in Connect mode, Kermit listens for "commands" from the remote host and
updates the screen accordingly -- why not just extend the terminal emulation
language by adding one new escape sequence? Upon receipt of that command,
the micro could pop into server mode and await instructions. Note that the
remote host can then do more than just send files -- it can issue the whole
range of server-mode commands to change settings and even upload files.
------------------------------
Date: Wed, 16 Sep 87 16:38:23 BST
From: Chris Kennington (CJK@SYSD.SALFORD.AC.UK)
To: John F. Chandler (PEPMNT@EARN.CFAAMP)
Cc: info-kermit @ cu20b.columbia.edu
Keywords: Kermit Protocol Extensions
John:
Thanks for your thoughtful comments (suggesting a terminal
escape-sequence to trigger local Kermit into protocol mode).
I take your point that any auto-triggering ought to be on the
current Start-of-Packet character, not "hardwired" to SOH. I'd also intend
that the implementation should check pretty thoroughly that the next few
characters are compatible with the header of one of the Kermit packets legal
at this point (S, I etc.).
From the point of view of my (commercial) client, the objective was
to achieve a local Kermit which would flip into protocol mode as soon as the
user gave the appropriate command to the host Kermit (in connect mode). The
proposed environment is one where the relatively naive user thinks of his
local equipment as an intelligent terminal, not a computer. As far as he is
concerned, he always thinks he is talking to the mainframe host.
The ESC-sequence idea has attractions because it's controllable
(though some thought would be needed to pick an appropriate sequence,
presumably from one of the ANSI "local implementation" sets). The
disadvantage is that, as an extension to the Kermit host protocol, there
would be a delay before the majority of mainframe host Kermits implemented
it. My client, as always, wants it yesterday; and wants it to work
independent of the level of Kermit on the host.
I shall probably proceed with the trigger-on-"SOH" logic, if only to
see how it works. But I am in favour of defining an extension to the
protocol which permits, in effect, limited communication between the two
Kermit state-machines embedded in the connect data-stream. There might be a
number of other things which could usefully be done, such as setting the
start-of-packet character itself. This sounds like an idea to be threshed
around generally.
Chris K.
[Ed. - Anyone who adds this kind of mechanism to a Kermit program should
also provide a way for the user to override it, in case of accidents and for
debugging. About the "Kermit escape sequence" -- since any Kermit program
can emulate any terminal whatsoever, or for that matter may make use of any
built-in firmware, external terminal device driver, or even an external
terminal, then how can you pick a sequence guaranteed not to collide with
any conceivable terminal's repertoire of escape sequences? (The world isn't
composed only of ANSI terminals -- we also have HP's, DG's, etc etc).
Looking for a Kermit packet does indeed seem to be the best route.]
------------------------------
Date: Fri, 11 Sep 87 23:55 CDT
From: <GE00707@SWTEXAS.BITNET>
Subject: Kermit-32 STATUS Command
Keywords: Kermit-32, VMS Kermit
In light of the comments about STATUS not working, it doesn't work for us in
versions 3.0 or 3.3. We're running VMS 4.5 (VAX 8650). (Usually we
download files to IBM PCs, running ProComm 2.4.2.)
MM
VMS Kermit-32 version 3.3.111
Kermit-32>stat
Totals for the last transfer
Characters sent 188
...
Effective data rate 4294967106 baud
[Ed. - This is wierd. It seems to be independent of Kermit version, but
dependent on VMS version. A real baud rate is displayed by 3.1 and 3.3
of VMS Kermit under VMS 4.3... Anyway, it seems Kermit-32 is headed for
extinction, and development is picking up on the VMS version of C-Kermit,
which doesn't have any problems reporting the effective baud rate.]
------------------------------
Date: Sun, 13 Sep 87 22:29:42 EDT
From: ciaraldi@cs.rochester.edu
Subject: Prime Kermit Source Unpacking
Keywords: Prime Kermit
The source for Prime Kermit is in one big file, PRIME.PLP. CU20B has a
program PRIMES.FTN which breaks it into its component files automatically.
Unfortunately, this program doesn't work. It looks for lines of colons
separating the files. PRIME.PLP has lines of pound signs. The program also
messes up finding file names. I'm trying to fix the program, but I am
wondering if anyone has already got it working.
The alternative way of splitting the file is to use EMACS. We have this,
but it truncates the file after 5000 lines, so that doesn't help either.
If I get it working soon I'll let you know.
Mike Ciaraldi
------------------------------
Date: Mon, 14 Sep 87 15:56:28 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: WordPerfect files
Keywords: WordPerfect
WordPerfect files are, in fact, binary ones, with funny line delimiters and
several other such things -- it is not just printer ESC codes. To transfer,
you must either:
- Treat the file as binary, as suggested in Info-Kermit. It, after all,
*is* binary. Use SET FILE TYPE BINARY to VMS Kermit.
- Use WordPerfect's "convert" program to encode it into seven-bit ASCII
graphic characters.
If you really have a WordPerfect printer output file (rather than the file
that WordPerfect actually operates on) then the problem is the same, but
only the first solution -- binary transmission - will do you any good.
------------------------------
Date: Wed, 16 Sep 87 06:11:51 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Kermit Protocol Curiosity
We have run into a small protocol curiosity when using a strange mix of
equipment. It seems to parallel another strange mix, so the problem may be
general enough to be worth consideration. The problem:
- We start with a terminal concentrator that requires (or is most easily
configured with) a "parity none" arrangement. In our case, the concentrator
speaks RS232 asynch on the PC side and TCP/IP Telnet on the network side.
- The network -- specifically, either the concentrator or the host at the
far end -- won't negotiate an eight-bit "binary" transfer of data, so binary
information must be transmitted with 8th-bit prefixing.
- But, while the protocol manual seems to provide for me to force 8th-bit
prefixing by sending a character other than N or Y, most versions of kermit
ask for this feature only if parity is set on (non-none). If we turn parity
on, the terminal concentrator, which checks it, gets very upset.
In addition to our TCP/IP problems, this seems to parallel some difficulties
we've observed with some complex protocol converter arrangements that make
ASCII devices speak 327x at the far end of complex links.
We can, of course, get around this by "hexifying" the files prior to
transmission, but that is what 8th-bit quoting is supposed to save us. So,
this is a bit of a plea for either an
SET EIGHTH-BIT-QUOTING ON option or
some way to say
SET PARITY NONE-but-don't-transfer-eight-bit-data-without-quoting
[Ed. - Not really a protocol issue, but an implementation decision. This
is the first time we ever heard of an environment where 8th-bit quoting
is necessary and at the same time parity is proscribed. But my goodness,
how do explain something like this to the "naive user". The manual is
already hundreds of pages thick!]
------------------------------
End of Info-Kermit Digest
*************************
-------
18-Sep-87 18:37:53-EDT,23774;000000000000
Mail-From: SY.FDC created at 18-Sep-87 18:37:17
Date: Fri 18 Sep 87 18:37:17-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #21
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12335695150.160.SY.FDC@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Fri, 18 Sep 1987 Volume 6 : Number 21
Departments:
ANNOUNCEMENTS -
Announcing NIH TSO Kermit Version 1.1A
Announcing C-Kermit for Convergent Technologies CTOS
Announcing Kermit v2.8a for Apollo
Info-Kermit Digest BITNET Delivery in Danger
News about Kermit Programs for VAX/VMS
Kermit User Guide and Protocol Manual Available in Portuguese
C-KERMIT -
C-Kermit 4E(067) on VAX/VMS Bug Report
C-Kermit 4E(066) Support for Amdahl UTS Half Duplex Systems
C-Kermit 4E(066) on Apollo, IBM RT, Microvax II Bug Report
Patches to C-Kermit for Phone Directory
MS-DOS KERMIT -
SCANCHEK Program for IBM-PCs
MS-Kermit 2.29C on 3COM LAN
Problem with TurboBASIC and MSBPCT.BAS
MAC KERMIT -
Mac Kermit Can't Receive Files Whose Names Start With X?
Decoding KERMSRV's .HQX Files?
MISCELLANY -
Re: Kermit Protocol Curiosity
----------------------------------------------------------------------
From: "Roger Fajman" <RAF@NIHCU>
Date: Wed, 16 Sep 87 18:44:10 EDT
Subject: Announcing NIH TSO Kermit Version 1.1A
Keywords: TSO Kermit, MVS/TSO Kermit, IBM 370, NIH
Version 1.1A of NIH TSO Kermit is now available. It contains fixes for a
number of bugs, but no new functions. The following four files were
updated: TSNKER.TXT, TSNKER.BWR, TSNKER.OBH, and TSNKER.ALP. The new
version is available from Columbia in the usual ways and directly from NIH
(at no charge) by sending a letter and a tape to
Joseph D. Naughton
Chief, Computer Center
National Institutes of Health
Building 12, Room 2244
Bethesda, MD 20892
A new version is under development that does contain new functions such as
(1) long packets, (2) 7171 protocol converter support (being developed
elsewhere), (3) multiple commands on a line, (4) multiple file names in a
SEND or GET command, (5) better handling of data set name collisions, and
(6) other things I can't remember at the moment. No release date has been
established for this version.
[Ed. - Thanks, Roger! The four new files are available in KER: on CU20B for
anonymous FTP (Internet), from KERMSRV on CUVMA (BITNET), and on Kermit
distribution tape B.]
------------------------------
Date: Fri, 11 Sep 87 08:45:32 edt
From: ecsvax.uucp!joeld@mcnc.org (Joel Dunn)
Subject: Announcing C-Kermit for Convergent Technologies CTOS
Keywords: Convergent Technologies, CTOS, NGEN, Burroughs B20, BTOS, C-Kermit
Keywords: VT100 Emulation
Over the last year, I have been gradually porting C-Kermit 4.2(030) march 85
to CTOS, a multi-tasking proprietary operating system that runs on Convergent
Technologies NGEN micro computers. I re-wrote the comm line I/O, disk I/O,
and video I/O, and added a rudimentary VT100 emulation option. The protocol
code is pretty much as I got it, as is the command parser and things like that.
I use it fairly regularly, both as a terminal emulator and for text and binary
file transfers to my local Unix machine running C-Kermit.
My port is not perfect, but I would like to offer it up to the "Kermit Gods"
if you are at all interested. I know it is based on "old" source, but that
is what I was able to easily get at the time I started this project, back in
the summer of '86. I only worked on it as time permitted, so that's why it
took me a year to get it where I thought it worked.
Joel Dunn
UNC-Chapel Hill
Administrative Data Processing
440 W. Franklin Street
Chapel Hill, NC 27514
RJD@UNC.BITNET
{backbone}!mcnc!unc!dunn.UUCP
{backbone}!mcnc!ecsvax!joeld.UUCP
[Ed. - Many thanks, Joel! There have been many requests for CTOS Kermit over
the years, and also for BTOS (for Burroughs B20, etc, which is supposed to be
compatible). It would be much appreciated if anyone can report on whether this
version also works on BTOS. CTOS Kermit has been put in KER:CT*.* on CU20B,
CT* * on CUVMA, and on Tape C of the Kermit distribution. Since you've gone to
the trouble to develop most of the system-dependent C-Kermit code for CTOS, I
hope that someone will take the next step and adapt it to the current version
of C-Kermit, so we don't have to carry a redundant set of files.]
------------------------------
Date: Fri, 18 Sep 87 14:12:18 +0200 (Central European Sommer Time)
From: XBR4D715@DDATHD21.BITNET (KLaus D. Schmitt THD Inst. f. EEV FB17)
Subject: Announcing Kermit v2.8a for Apollo
Keywords: Apollo, Pascal
Some time ago I got Kermit for Apollo from Netlib. We installed this version,
but had some trouble with SEND command (nothing could be send from Apollo !).
We examined the sources from Netlib and corrected them with the result, that
all works quite well on our DN 3000 communicating with some PC's and VAXen.
Please note, that the source includes kermitio.pas in the file kermit.pas.
existf.c is no longer needed !
Greetings from Europe
Klaus D. Schmitt
Inst. for El. Power Supply
Technical University Darmstadt
F R G
[Ed. - Gruess aus Nord-Amerika, und vielen Dank, Klaus! Kermit 2.28a replaces
APOLLO.PAS in Kermit Distribution. Meanwhile, if anybody knows the difference
between APOLLO.* and APLKER.* (both Pascal Kermits for the Apollo, apparently
cousins descended from version 2.6?), let us know! If they can be reconciled
into a single version, we could free some space and alleviate some confusion.]
------------------------------
Date: Wed, 16 Sep 87 13:03:34 PDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Info-Kermit Digest BITNET Delivery in Danger
Keywords: Info-Kermit Digest, BITNET, LISTSERV
As of December 1, 1987, the WISCVM Internet/BITNET mail gateway will go out of
service because of the heavy load this function has placed on their system.
There are currently about 150 entries in the Info-Kermit distribution list that
go through the WISCVM gateway. Although Columbia has its own BITNET mail host,
CUVMA, experience has shown that routing through CUVMA to BITNET does not work
for most addresses. This is because the To: list does not appear as part of
the message (and nobody would want it to, since it's about 600 lines long!),
and the protocol for a mailer to send the recipient list to the receiving mail
agent varies among BITNET sites. Anyone who receives the Info-Kermit Digest
through WISCVM is urged to advise us of an alternate address, or to register
with a LISTSERVer near you. For instance, you could subscribe through Tulane
University by typing the following command (from a VM/CMS system):
TELL LISTSERV AT TCSVM SUB I-KERMIT your-name
where your-name is your actual name, which may contain spaces, etc. After
you have done this, make sure you get delivery of at least one Info-Kermit
digest from UGA, and then you can send a message to Info-Kermit-Request@CU20B
telling us to drop you from our own distribution list.
Other LISTSERV sites that can redistribute Info-Kermit include Brown University
(BROWNVM), the University of Georgia (UGA), and the University of Guelph
(CANADA01). Eventually, Columbia University (CUVMA) will join them. Other
BITNET and NETNORTH sites with LISTSERVers, particularly in mid- and far west
North America, as well as EARN sites in Europe, are also encouraged to
volunteer to distribute Info-Kermit mail. There will be more news about this
in future digest, I hope.
------------------------------
Date: Wed, 16 Sep 87 13:03:34 PDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: News about Kermit Programs for VAX/VMS
Keywords: C-Kermit, VAX/VMS Kermit, VAX/VMS C-Kermit
Keywords: VAX/VMS Fortran/Pascal Kermit
Cross-Ref: VMS, See also VAX/VMS
If you attended the Nashville DECUS Kermit session, you may have heard Bob
McQueen announce that continued development of VAX/VMS Kermit-32
(KER:VMS*.*) at Stevens Institute of Technology is probably a lost cause.
VMS Kermit was developed by Bob McQueen and Nick Bush at Stevens from 1982
until the most recent (and probably final) release, 3.3.111, in April 1987.
Nick left Stevens some years ago, and Bob and his staff are too tied up in
other projects to continue their Kermit work. Many, many thanks to Bob,
Nick, and SIT for one of the most ambitious and popular Kermit
implementations, and for many contributions to the Kermit protocol itself.
Kermit-32 is written in the Bliss language, DEC's "corporate implementation
language" (originally developed at CMU). Bliss never gained popularity among
DEC's customers; few sites have Bliss compilers. If there are any VMS Bliss
sites out there who are willing to take over maintenance and development of
Kermit-32, please come forward!
Not entirely parenthetically, it should be noted at this point that there is
also a VMS Kermit written in a combination of Pascal and Fortran, last released
by Bruce Pinn and Philip Murton at the University of Toronto in 1984
(incidentally, this is based on Toronto's OMSI Pascal Kermit for RT11, the
first high-level language Kermit program). To my knowledge, no further
development is planned on this program either. Some sites that are
uncomfortable running Kermit-32 because they don't have Bliss compilers use
this version instead (it's in KER:VX*.*).
It now appears that all further work on VMS Kermit will concentrate on the C
version, of which release 4E(067) was announced in the previous Kermit
digest (KER:XK*.*). Development of VAX/VMS support for C-Kermit has been
taken over by:
Jamie Hanrahan
(uucp: {akgua | hplabs!hp-sdd | sdcsvax | nosc}!crash!pnet01!jeh)
(arpa: crash!pnet01!jeh@nosc.mil)
(internet: jeh@pnet01.CTS.COM)
(US Mail: c/o Simpact Assoc., 9210 Sky Park Ct., San Diego CA 92123)
Jamie is working from the latest stuff. If you're a VMS VAX-11 C and/or RMS
expert (preferably on the net) and would like to help out, please contact
Jamie. Similarly, if you have any suggestions, bug reports, fixes, etc, for
C-Kermit on VMS, send them to Jamie, cc to Info-Kermit@CU20B. Among the
improvements we hope to see are better performance during CONNECT and more
detailed knowledge of the VMS file system. Thanks to Jamie for taking this on!
------------------------------
Date: Wed, 16 Sep 87 13:03:34 PDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit User Guide and Protocol Manual Available in Portuguese
Keywords: Kermit Documentation, Portuguese
Ricardo B. Ghirlanda of Telecomunicacoes Brasileiras S.A., Brasilia, Brazil
(pardon the missing diacritical marks) has translated the Kermit User Guide and
Protocol Manual (5th Editions, somewhat behind the times) into Portuguese.
These manuals have been placed into KER:POR*.* on CU20B (POR* * on CUVMA):
PORTUG is the Portuguese User Guide (Fifth Edition).
PORTPM is the Portuguese Protocol Manual (Fifth Edition).
PORTTT is a manual describing a Kermit-based file transfer service
The original files were in 8-bit IBM PC WordStar (.WSD) format, which can't be
included in Kermit distribution. The files of type .HEX are "hexified"
versions of the WordStar files, which can be dehexified back into the original
8-bit WordStar format by a simple program that puts each pair of hex digits
back together (a sample program is listed in PORTAA.HLP). The files of type
.TXT are 7-bit ASCII files produced from the WordStar files by stripping the
high-order bit of each 8-bit byte. These are pretty much readable on a
terminal or printer; diacritics are mostly done with backspace-overstrike, etc.
Thanks to Mr. Ari Lopes Cunha of Brasilia for submitting this material.
If you have Kermit documentation translated into any new languages, please send
them in. This is especially appropriate now that we have a special place to
keep them (Tape E). I've seen (or heard of) Kermit manuals in German, Italian,
Hungarian, and Japanese, but have never received machine-readable versions.
------------------------------
Date: 17 SEP 1987 15:57 EDT
From: Steve Roseman <LUSGR@LEHICDC1.BITNET>
Subject: C-Kermit 4E(067) on VAX/VMS Bug Report
Keywords: C-Kermit, VAX/VMS C-Kermit
Running C-Kermit 4E(067) under VMS V4.5 seems to work so far, with 3 problems.
1. The user needs a BYTLM quota of at least 5000 to execute a "! xxx" command,
"DIR", or "SPACE". Otherwise the job just hangs up.
[Ed. - This doesn't happen to me under VMS 4.3, unless somebody raised my
BYTLIM (whatever that is!) without my knowing it.]
2. With a sufficient BYTLM, the above work, but if any are done, C-Kermit
leaves behind a subprocess when it exits. Re-entering C-Kermit and
executing any of the above starts up (and then leaves behind again)
another subprocess. Repeat until your job hangs up.
3. A "! LOGOUT" command kills the subprocess in which it executes; another
"! xxx" command just hangs, since C-Kermit doesn't seem to know it's
gone.
Fairly minor problems, but file transfers run well with 1000 char packets.
Steve Roseman
Lehigh Univ.
PS: in Vol 6, number 20, you mention a new MSTIBM.BOO. One thing that
has been fixed is flow-control after ^S and no ^Q (e.g. ^X^S^X^Z save and exit
EMACS).
[Ed. - Thanks for the bug reports, Steve. They've been passed along to Jamie.]
------------------------------
Date: Mon, 14 Sep 87 19:12+0600
From: Darren R Besler <dbesler@cc.uofm.CDN>
Subject: C-Kermit 4E(066) Support for Amdahl UTS Half Duplex Systems
Keywords: C-Kermit, Amhdahl, UTS, Half Duplex, IBM 370
This is in regard to the experimental version of C-Kermit, version 4E(066).
The installation here at the University of Manitoba is the following:
Processor: Amdahl 5870
Oper Sys: UTS/V running under VM
Comm Ctlr: Amdahl 4705
Due to the above machine configuration we are running UTS in half duplex mode.
C-Kermit is written to work in full duplex mode. I have made appropriate
changes to allow running in half duplex mode. These changes have been embedded
amongst #ifdef HALFDUPLEX or #ifdef FULLDUPLEX constructs. Could these changes
be incorporated into the next version of C-Kermit?
The files modified are the following:
ckucmd.c
ckuker.mak
ckutio.c
Here is the cdiff for ckucmd.c
Darren R Besler
Dept. of Computer Services
University of Manitoba
Winnipeg, Manitoba, Canada
[Ed. - Diffs omitted, added to KER:XKUKER.BWR, but the diff for ckutio.c is
missing. Building C-Kermit for half or full duplex operation according to
a compile-time option may not be the best method, however. What if there
are both full- and half-duplex connections to the same system? E.g. an IBM
or Amdahl mainframe with 3705 half-duplex ASCII TTY lines, and full-duplex
7171 protocol converters...]
------------------------------
Date: FRI, 18 SEP 87 13:05:17 MESZ
From: R02KER@DHHDESY3.BITNET
Subject: C-Kermit 4E(066) on Apollo, IBM RT, Microvax II Bug Report
Keywords: C-Kermit, Apollo, IBM RT PC, MicroVAX II, Ultrix
C-KERMIT 4E(006) 4 AUG 87 REPORT:
APOLLO Domain/IX DN3000, SR 9.5.1 SYS5, C-Kermit 4E(066) 4 Aug 87
Generated with 'make sys5'
When using '.kermrc' or using the 'take' command
the 'C-Kermit>' prompt is not present and then
any invalid command brings the message
'Fatal: Kermit command error in background execution',
after which C-Kermit terminates.
IBM PC RT 6150, AIX 2.1, C-Kermit 4E(066), AT&T System III/System V
Generated with 'make sys5'
Cracks up with 'Bad system call - core dumped' when using '.kermrc'
or using the 'take' command
Pervious version worked ok
For this version do not use 'take', set line and speed at kermit
command level
[Ed. - The above two problems are caused by the check for background
operation in conint(), module ckutio.c. If someone can figure out what
the code should be to determine whether Kermit is running in the foreground
or the background on these systems, please send it in! Meanwhile, the
workaround is to always have conint() set the variable backgrd to 0. Of
course, then you can't really run it in the background...]
MICRO VAX II, Ultrix 1.2A, C-Kermit 4E(066) 4 Aug 87, 4.2 BSD
Generated with 'make bsd'
Runs O. K., except the tty line hangs after use.
Extended packet works.
[Ed. - I tried it in remote mode on a MicroVAX II with Ultrix 2.0, and
it didn't hang the line after use. Are you talking about remote or local
mode?]
Regards, Ray Koluvek
------------------------------
From: ames!pluto!warren@phri (Warren Burstein)
Date: 13 Sep 87 17:22:26 GMT
Subject: Patches to C-Kermit for Phone Directory
Organization: Industrial Automation Systems - New York, NY
Keywords: C-Kermit, Phone Directory, Dial Command
These patches add to ckermit a "set phone" command. Aliases are recognized in
the "dial" command. My .kermrc is now full of "set phone" commands.
The new command looks like
set phone pacx 280-8050
After this command, I can say
dial pacx
I don't know how to make a "patch" file so here is a shar of all the diffs.
I didn't use any fancy methods to store phone numbers, it didn't seem worth the
effort.
[Ed. - Pretty neat. Thanks, Warren. For now, the code will be kept in
XKUKER.BWR.]
------------------------------
Date: Sat, 12 Sep 87 16:57:57 EDT
From: Phil Benchoff <BENCHOFF@VTVM1>
Subject: SCANCHEK Program for IBM-PCs
Keywords: IBM PC Key Codes, MS-DOS Kermit
Enclosed is SCANCHEK.C and SCANCHEK.BOO for IBM-PCs. This program displays
BIOS scancodes and MS-Kermit 2.29C key idents. It is useful to determine key
idents while defining MS-Kermit keyboard definitions.
The source will compile with Computer Innovations C-86 or Borland Turbo-C.
Special thanks to JRD for providing details of MS-Kermit keyboard handling and
modifications to the code. Please add it to the distribution if you think it
will be useful.
[Ed. - Thanks! The files have been renamed MSUCHK.C and MSUCHK.BOO to fit the
Kermit file naming scheme.]
------------------------------
To: "Joe Doupnik" <JRD@USU>
From: "Roger Fajman" <RAF@NIHCU>
Date: Thu, 17 Sep 87 18:32:03 EDT
Subject: MS-Kermit 2.29C on 3COM LAN
Keywords: MS-DOS Kermit, 3COM Ethernet, Netbios
One of our people here tried a quick PC-PC test with MS Kermit 2.29C running
over a 3COM Ethernet with 3Plus software. He found two things:
(1) Kermit would not work with version 1.0 of the 3COM Netbios.
The 1.2 version seemed to work, but he did not try a lot of
things. Apparently 1.0 is a less than complete implementation
of Netbios.
(2) The SET PORT NET command appears not to upcase its argument.
The value he used had letters in it that had to be entered
in upper case in order to work.
Roger
------------------------------
Date: Thu, 17 Sep 87 10:52:05 CDT
From: moore@ncsc.ARPA (Moore)
Subject: Problem with TurboBASIC and MSBPCT.BAS
Keywords: BOO File Programs, BASIC, TurboBASIC, MS-DOS Kermit
Has anyone commented on TurboBASIC not working properly with MSBPCT.BAS? I
recently downloaded both the .BAS and .BOO files to create an executable;
GW-BASIC and QuickBASIC 3.0 executely nicely, but TurboBASIC chokes on line
300; in fact, as nearly as I can tell, the program just stops executing
completely.
------------------------------
Date: Thu, 17 Sep 87 11:43:43 PDT
From: kevin@ACC-SB-UNIX.ARPA (Kevin 0'Gorman)
Subject: Mac Kermit Can't Receive Files Whose Names Start With X?
Keywords: Mac Kermit
I found this in ckmker.bwr in the 4E(066) distribution. I ran into a very
similar problem I thought I would pass along.
> Occasionally, files transferred to the Mac with apparent success will be
> empty. This happens very rarely and cannot be reproduced. It has only been
> reported twice, once on a Hyperdrive system, and once on a Mac with a Tecmar
> disk after the screen had been dumped to the printer. (this problem may be
> rectified in edit (33), which now terminates on failure to close, attempting
> to report an appropriate error.) One user claimed to be able to reproduce
> the problem by using Mac Kermit to GET any file whose name starts with X from
> the Unix Kermit server (yet others can't reproduce it this way).
I was reading the Kermit distribution from a VAX running 4D kermit, and 4.3 BSD
with a Mac Plus running 0.8 Kermit. The VAX was running as server, and I
requested x*. I would get the first file okay, but all others would pass
by VERY fast, with the notation "Discarded" and "K bytes: 0" on the Mac.
When I renamed that first file, that had arrived okay, so that it was no longer
selected by x*, I got the new first file okay, but all others were passed over.
This repeated ad infinitum. I renamed all files on the VAX so that none began
with "x", and they came across just fine.
Another thing I noticed, that may bear on this, is that the renaming of the
files did not agree with the documentation. Some of my files had more than
one period in the name (I originally was trying to get compressed files named
like ckusr.c.Z), and I found that the mac reported the filename being recieved
as CKUSR.CXZ. I gathered that it was changing things so that there were never
more than 1 "." in a filename. I can't tell which system did this.
Since "x" is special in this way, the special code may be munging incorrectly
on subsequent files of a set. I dunno. I just thought I would pass along
instructions on how to repeat this.
[Ed. - There appears to be something very wrong with Mac Kermit's filename
collision avoidance algorithm...]
------------------------------
Date: 2 SEP 1987 18:31:20 EDT
From: "Richard E. Lynch" <VM10CA@WVNVM>
Subject: Decoding KERMSRV's .HQX Files?
Keywords: Mac Kermit, BinHex
Hello, This is Rich Lynch at WVNET. I just downloaded some of your KERMSRV
files and one of them is a .HQX file which has a comment at the top. The
comment says the file must be converted with the BINHEX Ver 4.0 program.
Is this program available from KERMSRV and if not where might I get a
copy ? Thanks in advance.
...Rich
[Ed. - BinHex is a "shareware" program for which (to my knowledge) source is
not available. There is no way for us to distribute binaries on KERMSRV or on
magnetic tape (the explanation is tedious). BinHex is, however, on our Mac
Kermit distribution diskette, which you can order by mail.]
------------------------------
From: "Roger Fajman" <RAF@NIHCU>
Date: Thu, 17 Sep 87 16:43:11 EDT
Subject: Re: Kermit Protocol Curiosity
Keywords: 8th-bit Prefixing, Parity
Have you tried setting the parity in Kermit to SPACE? The 7-bit ASCII
characters will look the same on the line as with parity NONE (8th bit zero),
but Kermit will know that the 8th bit is not available for data and should
request 8th bit prefixing.
[Ed. - Obvious answer, should have thought of it... Thanks also to Bruce
Cowan of SFU for responding similarly.]
------------------------------
End of Info-Kermit Digest
*************************
-------
22-Sep-87 16:18:31-EDT,26099;000000000000
Mail-From: SY.FDC created at 22-Sep-87 16:17:30
Date: Tue 22 Sep 87 16:17:30-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #22
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12336718279.34.SY.FDC@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Tue, 22 Sep 1987 Volume 6 : Number 22
Departments:
ANNOUNCEMENTS -
Some LISTSERVers Allowing Info-Kermit Subscriptions (2 messages)
MS-DOS KERMIT -
New .BOO File for Intel iRMX Version of MS-Kermit
Clear Keys on MS-Kermit 2.30?
MS-DOS Kermit 2.29C Maximum Packet Size
MS-DOS Kermit 2.29C Problem with IRMA Board
MS-DOS Kermit 2.29C Send-As Name?
MS-DOS Kermit 2.29C Color and Intensity
Losing Interrupts on IBM PC and PS Systems
VAX/VMS KERMIT -
Kermit-32 Escape Sequence and VT330 Terminal
C-Kermit 4E on VAX/VMS Bug Report
MISCELLANY -
Native Media for Commodore-64 Kermit
Kermit and the IBM 7171
Kermit for Tandy 6000?
8th-Nit Prefix Bug in Kermit For TRS80 Model IV (M4)
----------------------------------------------------------------------
Date: Sat, 19 Sep 87 15:22:16 FIN
From: The Head of the Post Office <POSTMAST@FINHUTC>
Subject: Some LISTSERVers Allowing Info-Kermit Subscriptions
Keywords: Info-Kermit Digest, BITNET, LISTSERV
There already is a peered LISTSERV-list called I-KERMIT that distributes
Info-Kermit Digest. (Here it is called IKD for some historical reason...)
This is part of our configuration file for this list.
* Peers= I-KERMIT@UGA,I-KERMIT@MARIST,I-KERMIT@TCSVM
* Peers= I-KERMIT@CLVM,I-KERMIT@EB0UB011,I-KERMIT@RUTVM1
* Peers= I-KERMIT@UBVM,I-KERMIT@DEARN,I-KERMIT@VTVM2,I-KERMIT@BNANDP11
*
* Owner= HAROLD@UGA (Harold Pritchett)
I think that all the BITNET users could be (should have been ?) transferred
to this list.
Petri Autio
[Ed. - Thanks for the list, Petri! See next message for more information.]
------------------------------
Date: Tue, 22 Sep 87 11:57:19 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Info-Kermit Digest Distribution by LISTSERV
Keywords: Info-Kermit Digest, BITNET, LISTSERV
So far, the following BITNET sites have indicated (perhaps indirectly) that
they maintain LISTSERVers capable of handling Info-Kermit Digest
subscriptions. Thanks to each of these sites for providing this service.
Node Country Name
BNANDP11 Belgium Facultes Univ Notre Dame de la Paix, Namur
CANADA01 Canada University of Guelph, Ontario
FINHUTC Finland Helsinki U of Technology,
EB0UB011 Spain Univ Autonoma Barcelona
BROWNVM USA Brown University, Providence, RI
MARIST USA Marist College, Poughkeepsie, NY
RUTVM1 USA Rutgers University, New Brunswick, NJ
TCSVM USA Tulane U Computing Services, New Orleans, LA
UBVM USA SUNY Buffalo, NY
UGA USA U of Georgia
VTVM2 USA Virginia Polytech Institute, Blacksburg, VA
CLVM USA? Clarkson U ERC (where is it?)
DEARN West Germany Gesellschaft fuer Schwerionenforschung
Hopefully, we'll be adding CUVMA (Columbia University, NY, USA) to the list
very soon. Other BITNET/EARN/NETNORTH sites, especially in areas far from
the locations above, are encouraged to volunteer. Meanwhile, if you're a
BITNET subscriber, please, "TELL LISTSERV AT nearest-node SUB I-KERMIT
your-name". When you start getting the LISTSERV copy, send a message to
Info-Kermit-Request@CU20B and ask to be removed from our list. This way,
there should be no interruption in service when the WISCVM Internet/BITNET
mail gateway goes out of service on December 1.
We are also attempting to gradually remove WISCVM dependencies from our own
list. Last week we sent out a test message to all the BITNET sites on the
Info-Kermit mailing list to see which ones could accept mail directly from
CU20B. The results are still coming in, but those sites that seem to have
received the mail successfully have had their entries changed to bypass the
WISCVM gateway.
------------------------------
Date: Thu, 10 Sep 1987 08:57 PDT
From: JAFW801@CALSTATE.BITNET (Jack Bryans)
Subject: New .BOO File for Intel iRMX Version of MS-Kermit
Keywords: Intel, iRMX, RMX Kermit, MS-DOS Kermit
Here's the latest .BOO file for the Intel iRMX version of MS-DOS Kermit,
based on the current 2.29C MS-DOS Kermit development version. There's also
some acommpanying documentation.
[Ed. - Thanks, Jack! It has been put in KER:MSTRMX.BOO and .DOC and
MSTRMX * on CUVMA. Feedback solicited!]
------------------------------
Date: Thu, 17 Sep 1987 15:58 CDT
From: William Bruce Curtis <NU024414@NDSUVM1>
Subject: Clear Keys on MS-Kermit 2.30?
Keywords: MS-DOS Kermit
Is it possible to provide a replacement for the old CLEAR command which
cleared all the key definitions? When using mskermit to log on to several
different systems it is very convenient to be able to clear all the key
definitions without exiting from mskermit and restarting it. For example we
use a fairly long take file to customize the keyboard when logging on to CMS
but when logging on to UNIX a vanilla Heath-19 is preferred. Several users
here have complained about 2.29c's lack of a clear key command. I realize
that the clear command should clear the port as described in the book but
could we please get some command to clear all of the keys put back in before
2.30 is released?
[Ed. - Yes, 2.30 will contain a command SET KEY CLEAR.]
------------------------------
Date: Fri, 18 Sep 87 11:34:15 CDT
From: James Gregory <jgregory@ALMSA-1.ARPA>
Subject: MS-DOS Kermit 2.29C Maximum Packet Size
Keywords: MS-DOS Kermit
I'm in the process of putting the most recent 2.29C through its paces. When
the set send and receive packet commands are issued, the response indicates
there is a maximum value of 9024 bytes, however, the current implementation
only supports 1000 bytes. Just thought I'd bring this to your attention in
case it was an oversight. I realize that the 9024 byte limit is supported
by the protocol, however, it seemed you would want the response to be
specific to the current implementation.
[Ed. - Will be fixed in 2.30 to report the actual maximum size.]
------------------------------
Date: Fri, 18 Sep 87 11:19:45 MDT
From: John Shaver Modernization Office <steep-mo-m@HUACHUCA-EM.ARPA>
Subject: MS-DOS Kermit 2.29C Problem with IRMA Board
Keywords: MS-DOS Kermit, HP Vectra, IRMA Board
I have a Vectra, an HP AT Clone. I have sidekick and an IBM terminal emulator
called IRMA resident in RAM with 640K. I have about 450K left. The
significant difficulty came from 2.29C refusing to let me use COM2 as a port.
I have, am and continue to use Port 2 with 2.29.
[Ed. - From JRD: The serial port handling in 2.29C is much different from
previous releases. In particular, the port is tested before use. The
various levels which a user sees are messages such as "Port not available",
"This port uses the Bios", and nothing at all (which is best of all). The
first message is shown if the Bios work area in low memory indicates the
port was not found by the machine's boot code (COM1 is at 40:00H and COM2 is
at 40:02H, and normally hold 03f8H & 02f8H, respectively). The second
occurs if the port was found but the UART chip was not the kind which Kermit
can control (an 8250). Diagnosis then proceeds by noting the kind of
message, removing some add-in software, removing the IRMA board, and finally
calling for help (with additional system details).]
------------------------------
Date: 21 Sep 1987 23:41-CDT
From: SAC.SAC-LMR@E.ISI.EDU
Subject: MS-DOS Kermit 2.29C Send-As Name?
Keywords: MS-DOS Kermit
Thank you for improving Kermit. The changes have made a menu-driven
system for accessing the host much easier to write.
I have found 1 minor glitch so far - All caps must be used when specifying
the remote file name in the "SEND" command. If lower case is used, the file
created on the host has a name with ASCII char 22 preceding each letter.
I.e. using the name "test" as the remote file name will produce a file on
the host named "^Vt^Ve^Vs^Vt".
[Ed. - This is actually a documented feature. If it was done the other way,
you couldn't specify a lowercase name if you had to.]
------------------------------
Date: Mon, 21 Sep 87 16:21:41 CDT
From: James Gregory <jgregory@ALMSA-1.ARPA>
Subject: MS-DOS Kermit 2.29C Color and Intensity
Keywords: MS-DOS Kermit, Terminal Color, Terminal Intensity
Cross-Ref: Color, see Terminal Color
When I am using 2.29C as a terminal emulator with "set term color 1 10 37
44", the high intensity character display is behaving questionably. While
using "more" on a UNIX system (e.g.), the first page will display in high
intensity. The next and following pages will display in low intensity. If
I enter the escape sequence "^]c" followed by "connect", characters begin
displaying in high intensity again. I tested this behavior using the "vi"
editor, also. When the display went to low intensity, presumably because
the remote system sent the correct escape sequence to cause such behavior, I
escaped back to the local system, reconnected, and entered "^L" to redisplay
the current page. The page then displayed in high intensity. If the change
in attributes was the result of character sequences generated by the remote
system, I expected to see consistency. I assumed the editor was
retransmitting the same escape sequences.
This observation is not new to the current test version. I withheld
bringing it to your attention earlier. I thought this type of incident
would be so common that it would either be corrected or accounted for in the
info-kermit digest prior to release of 2.30.
Testing was done on an MS-DOS 3.1 Zenith Z-248 with an EGA.
[Ed. - From JRD: I know what you mean about the intensity bit. My Unix PC
does the same thing to me. It's 'ok' though when we realize the host is
explicitly sending a no-bold attribute command every now and then. Kermit
uses the screen attributes active when Connect begins and they might well be
bold white on blue and switches when the host so commands. The real dilemma
is PC color screens are unsatisfactory in 'normal' intensity whereas DEC
terminals are good that way. Also DEC terminals can control the background
intensity but PC's usually cannot. To provide a variation of intensity
required by the host applications software we are then stuck with normal
meaning rather dim. It's a pain which IBM needs to address. Does that help?]
------------------------------
Date: Mon, 07 Sep 87 09:43:06 ULG
From: Andre PIRARD <A-PIRARD%BLIULG12.BITNET@WISCVM.WISC.EDU>
Subject: Losing Interrupts on IBM PC and PS Systems
Keywords: MS-DOS Kermit, IBM PC, IBM PS/2
[Ed. - From a recent Info-IBMPC Digest.]
>... IBM, 3Comm and Microsoft have been pretty cavalier about losing
interrupts in the past. ... says Billy.
And the beat goes on. Here is a problem I reported to IBM:
>When a communication program drives an asynchronous adapter by interrupts
>and a national keyboard driver is used, typing while line input is being
>displayed produces screen garbage. Keyboard interrupts are an infrequent
>and long process and assigned higher priority (1) than frequent and short
>communication interrupts (3,4) (why?). Their drivers send the 8259 EOI
>just before IRET, as most regretfully do. Consequently, even if cpu
>interrupts are enabled, the 8259 will not request communication interrupts
>to the processor until the very end of keyboard interrupt processing,
>which, if excessive, causes communication line overrun. DOS 3.2 KEYBBE
>(on XT), for example, is near the limit, and causes occasional overrun at
>9600 baud.
>
>But 3.3 KEYB (on PS/2 30!) is far beyond and does it nearly for every
>keystroke. CTL-ALT-F1ing KEYB (to the original ROM presumably) removes
>the problem. Rotating 8259 priorities (OUTing C1H to 20H) solves the
>problem for KEYBBE, but not for KEYB (why?). But assigning the keyboard
>interrupt lowest priority also shuffles the other ones. In particular,
>the timer interrupts get the next to lowest. Is this practice advisable?
And some more comments for INFO-IBMPC:
What frightens me is that the problems are worse on 3.3 PS/2 30 than on a
plain XT or AT. I was expecting maturity from PS/2.
The priorities are as follows (0 highest):
0: timer ticks
1: keyboard
2:mouse (generally)
3,4: communication
5,6: disk and diskette
7: printer
Generally, BIOS and MSDOS as a whole are careful not to disable processor
interrupts too long unnecessarily, even during interrupt processing. There
could be occasional exceptions to this, but I never experienced any in
communication.
But with the host of available TSR programs hooking onto interrupt vectors,
the situation may change. If such a program acts as a front end, it cannot
decently enable interrupts without presuming what its followers do and need,
and it will necessarily perform before 8259 EOI anyway. For this reason,
such programs should act after the original sequence if possible, when
interrupts can be enabled for sure, except for another reason, the stack
growth nightmare. It is therefore important to write or choose such
programs carefully. The TSR programs problem is all the more acute as timer
and keyboard interrupts are the most favored for hooks.
[Ed. - From JRD: Columbia sent me a copy of your comments on interrupt
latency when national keyboard sets are employed. That explains a rash of
comments from PS/2 model 30 users concerning lost serial port characters.
Your comments are exactly on target concerning clearing the 8259 chip. If
you were to peek at the MS-Kermit/IBM serial port interrupt routine you
would see the 8259 being cleared as quickly as possible before doing the
reminder of the work, for this very reason. Interrupts are also enabled as
quickly as possible because I know the stack will not grow out of control.
Let's hope that Microsoft/IBM listen carefully. They are already being told
that OS/2 has severe interrupt latency problems when multitasking Real and
Protected mode windows together.]
------------------------------
Date: 18 Sep 87 8:38 -0600
From: Grant Delaney <delaney%wnre.aecl.cdn%ubc.csnet@RELAY.CS.NET>
Subject: Kermit-32 Escape Sequence and VT330 Terminal
Keywords: VAX/VMS Kermit, VT330
A note of caution the Kermit-32 escape sequence is also the terminal reset
and self test sequence for the new DEC VT330 terminal. The escape sequence
should therefore be changed before a connect if you want to get out again.
[Ed. - Kermit-32's default escape sequence is Ctrl-]C. C-Kermit's is
Ctrl-\C.]
------------------------------
Date: 17 Sep 87 12:23:00 MST
From: <darieb@sandia-2.arpa>
Subject: C-Kermit 4E on VAX/VMS Bug Report
Keywords: C-Kermit, VAX/VMS Kermit
I've just downloaded the newest XK* versions to VAX VMS 4.5. It compiled
without a hitch, using the XKVKER.COM. It even transferred a file OK.
However, there are a couple of problems.
I'm running an IBM PC/XT at 9600 Baud using the VTERM 4010 Version 2.0
software from Coefficient Systems Corporation, which supplies a pretty good
VT102 emulation. Connection is through COM1: to a Gandalf LDS120 line
driver, into a Gandalf (I think) port contender device, thence to a VAX
8600. No DECNET. The BLISS version of KERMIT works OK.
- The SHOW command produces a lot of unprintable characters in the
header lines of the table ("send" and "receive"), after which
several of the lines contain gibberish. After the SHOW, things go
back to normal (except see below)
- After many commands are executed, and the C-Kermit> prompt shows,
typing another command responds with "?invalid - xxx". Typing an
erase-line character (CTRL-U on VMS) before doing anything else
will erase 3 characters of the prompt, indicating that three characters
must have been received by VMS from the terminal(?) I can easily
get around this problem by habitually typing <CTRL-U>command...but who
wants to?
Is it possible that I need to SET TERMINAL to something different before
executing Kermit? Or are there indeed spurious characters being sent by
C-Kermit? At any rate, this version works OK, but the BLISS version is the
system standard here.
Declan A. Rieb, Division 2614 DARIEB@SANDIA-2.ARPA
Sandia National Laboratories (505) 844-6338
Albuquerque, NM 87185-5800
[Ed. - Can anybody help with this? I've tried the same thing on a VAX 780
with VMS 4.3, but can't make it happen. There seems to be a recurring theme
over past weeks -- all versions of VMS Kermit (Bliss, C, different releases)
seem to print various kinds of garbage when you give the SHOW or STATUS
commands under VMS 4.4 or later. What's going on???]
------------------------------
Date: Sat, 19 Sep 87 11:17:47 -0500
From: ray@j.cc.purdue.edu (Ray Moody)
Subject: Native Media for Commodore-64 Kermit
Keywords: Commodore-64 Kermit, Diskette Volunteers
>[Ed. - A popular request. Any volunteers? For that matter, are there any
>volunteers to distribute ANY versions of Kermit on native media for ANY
>systems that Columbia cannot provide?]
This probably is not worth posting, but if you are making a list of people who
can distribute Kermit on native media, we wish to be included.
[Ed. - Yes it is! We do keep such a list. It's AADISK.HLP, and we've added
you to it. I hope others will follow your example and volunteer with disks
and formats that Columbia cannot provide -- the many CP/M formats, 8-inch
diskettes, Xenix Kermit diskettes, SUN tape cartridges, etc etc.]
We will provide Commodore-64/Commodore-128 Kermit V2.0 on a 1541 disk.
(soon V2.1 and maybe Commodore plus-4 kermit.....) We ask $5.00 to cover
the costs of postage, handling, and the disk. We stress that Kermit is in
the public domain. The $5.00 is only so we can recover the costs of
postage, handling and the disk. We will be able to continue to provide this
service for the foreseeable future. Please send U.S. funds. We regret that
we will not be able to provide source code in this format because it will
not fit on a 1541 disk. Our mailing address is:
Dr. Evil Laboratories
P.O. Box 190
St. Paul, IN 47272
Ray Moody
ray@j.cc.purdue.edu
ihnp4!pur-ee!j.cc.purdue.edu!ray
moody@purccvm.BITNET
Kent Sullivan
ihnp4!pur-ee!corvair
------------------------------
Date: Mon, 21 Sep 87 17:10:43 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Kermit and the IBM 7171
Keywords: IBM Mainframe Kermit, IBM Series/1, CMS Kermit, VTAM, XON/XOFF
Cross-Ref: 7171, see IBM Series/1
I once wrote a communication/ftp program that we have been using on the
Series/1 and 7171 for several years without much problem. For several
reasons too long to explain here, we decided to convert it to the Kermit
protocol. It now works beautifully with another micro Kermit or in IBM 370
TTY mode, but the 7171 is such that it causes nasty problems. I'll explain
them mainly on the IBM370 list, but I think some facts I learned from
experience with my former program can be of general interest to 7171 users.
1) The S/1 style protocol converters run in two modes: terminal emulation
and transparent mode. File transfer uses transparent mode. In this mode,
the host (370) outputs data (write phase), then switches to read phase to
get the reply. The 7171 always uses interrupt driven RS232 I/O to a 340
bytes input buffer (the S/1 uses a smaller buffer, but uses DMA in
transparent mode). This means that when using packet sizes larger than 340
bytes, XON/XOFF pacing protocol MUST be used. It implies that the micro
Kermit use it, but also that it not be disabled on the 7171 side. Failing
that, I/O that once looked OK on a lightly loaded 7171 may suddenly go wrong
when the load increases. And I have seen what go wrong means: a buffer
overflow may cause complete deadlock of the communication port and need a
DTR drop to recover it.
2) Considering that it is best to always use (or at least allow) XON/XOFF in
file transfer raises another problem. The 7171 will receive XON/XOFF as
pacing during write phase, but not during read phase. Moreover, XOFF is
defaulted as an end-of-input character. It may happen that timing problems
cause an XOFF sent by the external device during write phase to effectively
arrive during read phase and end it with null input. For this reason,
allowing XON/XOFF as pacing must be paired with disabling XOFF as an
end-of-packet character. That is the system programmer setting bit X'1000'
at DC00:0008 in the 7171 NVRAM.
3) The 7171 may end an inbound packet prematurely on certain types of
transmission errors I could not determine. This process looks like
auto-catalytic. Once started, chances are high the host is assaulted by an
awful lot of short packets it NACKs. It seems the reason is turning the
line to read phase in the middle of a character the external device
trustfully sends. Because a single error is multiplied, the 370 Kermit
retry count should be set as high as possible. On the other side, the
external device (micro) must expect a flood of NACKs in response to a single
packet. It is therefore essential to purge the input buffer as late as
possible, I do it just before sending the end-of-packet character.
Question: does any Kermit reply before the eop? If yes, it would be better
to purge before sending the checksum.
4) There is no provision in the 7171 to recover from a lost XON, nor in the
370 to timeout. To avoid deadlock, the micro must implement its own
recovery. At least XON should be sent to the 7171 after a timeout. I also
send "clear screen" to allow the host to recover from loosing fullscreen
mode as well as "transmission error reset" and "purge input buffer". The
last two may be unnecessary, but are harmless anyway.
5) The maximum packet size is 1920, a screensize buffer. Better use 1900 to
allow for some extraneous characters. Around 950 is a good choice as little
performance gain is (usually) observed beyond and because it eases faster
resynchronization when two packets stick together.
I think these facts (and maybe others, welcome) will help to run file
transfer with the 7171 much more reliably.
Now that's not all. There are problems with VTAM and the fact that being a
half duplex device in file transfer mode, the 7171 would normally call for
handshaking. But I'll continue these, resorting to 370 Kermit internals, on
the appropriate list.
This gives but a faint idea of the mess 370 Kermit people have to deal with.
Believe me how thankful one has to be for their patience and work against a
beast said to be working as designed!
------------------------------
Date: 21 Sep 87 19:19:30 GMT
From: kent@soma.bcm.tmc.edu (Kent Hutson)
Subject: Kermit for Tandy 6000?
Keywords: Tandy 6000, Xenix, C-Kermit
Does anyone know where I can find a Kermit program that will work on a Tandy
6000 running Xenix? I have tried C-Kermit from Columbia, but had a lot of
trouble getting it running. I would like some suggestions for getting
C-Kermit running if you know what the problem might be.
Kent Hutson
Baylor College of Medicine, Houston, Texas
[Ed. - Others have complained of being unable to get C-Kermit working on the
Tandy 6000. Previous versions reportedly worked, but it seems that the
system was so slow that the program had to be compiled in a special way.
For one thing, is Tandy Xenix still based on Unix V7? If so, then you have
to do "make v7" rather than "make xenix" to build the program. And before
you do that, look in the makefile for special hints about "TRS-80 Xenix".]
------------------------------
Date: 6-SEP-1987 21:32:56
From: RHBNCSU@UK.AC.RHBNC.VAXA (Tom Bourke)
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: 8th-Nit Prefix Bug in Kermit For TRS80 Model IV (M4)
Keywords: TRS-80 Model 4 Kermit
Cross-Ref: Tandy, see also TRS-80
This is a note to explain the problem that arises under the use of Tandy
Model IV Kermit and Kermits that follow the protocol to the last letter. It
also gives a temporary solution, while I am informing Gregg Wonderly, an
American who wrote the Model IV implementation, but I'll also look into
providing a fix 'cos I'm using the darned thing!
Anyway, on with the problem. The protocol manual suggests that Kermits make
the best use of the communication lines they have access to. As a result,
machines communicating over 8-bit lines should use the full 8-bits unless
parity of some form or another is in use. As a result, if you are using
'proper' 8-bit lines, you shouldn't prefix the 8th bit prefixing character,
'cos you won't be sending any 8th bit prefixes anyway! The Tandy Model IV
implementation of Kermit ignores this wonderful piece of information and takes
every '&' character as an eighth bit prefix. As you have guessed this does
wonderful things to program listings! (Especially ones in 'C'!)
The instant (!) solution to this problem is to tell the host machine that it
is dealing with a machine that doesn't like the eighth bit. SET PARITY
SPACE has been working here on the VAX <-> Tandy Model IV's. At the same
time, the Tandy Model IV should have eighth bit prefixing turned on.
------------------------------
End of Info-Kermit Digest
*************************
-------
9-Oct-87 12:51:13-EDT,26114;000000000000
Mail-From: SY.CHRISTINE created at 9-Oct-87 12:50:12
Date: Fri 9 Oct 87 12:50:12-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #23
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12341136990.20.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Wed, 7 Oct 1987 Volume 6 : Number 23
Departments:
ANNOUNCEMENTS -
New MSTIBM.BOO for IBM PC MS-Kermit 2.29C
Maintenance Release 2.3 of Pascal TSO Kermit
Version 3.79 of Apple II Kermit Available
Version 2.8 QK Kermit Available
MS-DOS Kermit 2.29C for RMX
Release 1.2 of Kermit for HP264x
New Kermit Documentation in German
MS-DOS KERMIT -
Need help with iRMX Kermit
MS-DOS Kermit 2.29C Session Logging
Bug in MSTIBT 2.29/tek3
Kermit with Tek4010/4014 Emulator
UNIX KERMIT -
C-Kermit for Tandy 6000
Tandy Kermit Question in V6 #22
Suspending C-Kermit
C-Kermit and Berkeley Unix job control (crtl-Z)
C-Kermit for Umax 4.2 on Encore
Minor Bug in C-Kermit under Ultrix
Modem Control without Carrier
MISCELLANY -
Kermit for Convergent Tech Wanted
Data General One Help Needed
Re: Data General One Help Needed
DPS8 Kermit and X25
AAFILES.DIR on CU20B Kermit Areas
Kermit-68K Problems for OS-9
----------------------------------------------------------------------
Date: Sun, 27 Sep 87 18:41 MDT
From: <JRD@USU.BITNET> (Joe Doupnik)
Subject: New MSTIBM.BOO for IBM PC MS-Kermit 2.29C
Keywords: MS-DOS Kermit 2.29C
A new MSTIBM.BOO, dated 8 Oct 1987 is available for testing. This has the
improvements to allow Control-C to kill commands and pop the current TAKE
file with them. I added a key definition to make Control-@ send a null
character by default, as many have requested.
This edition also has changes to ignore DEL characters when using the VT102
terminal emulator, to implement the \; char pair as a literal semicolon in
Take files and Macros (vs seeing the ; as a comment introducer), to ensure
that error packets emitted before the file capabilities sequence is
completed are sent with a block check of 1 byte, and to apply the SET
DISPLAY 8/7 bit filter to the log file (when DEBUG is active the logging is
forced to 8 bit mode).
And, at long last, the DEC Rainbow version has been updated to 2.29C,
more or less compatible with the IBM version. The .BOO file for this is
in KER:MSTRB1.BOO.
[Ed. - Thanks Joe! The new files ahve replaced the old ones in
KER:MSTIBM.*, available thru Arpanet by FTPing to CU20B, user ANONYMOUS (any
password) or thru BITNET using KERMSRV. We're homing in on the real, final
release of 2.30! The draft manual for 2.30, which also applies to 2.29C,
remains available as KER:MST29C.DOC, and will change from time to time,
until we get it right... (or until the program we're trying to describe
stops changing).]
------------------------------
Date: 01 OCT 87 15:13 GMT
From: M70B@CBEBDA3T.BITNET (F.Buetikofer, Help desk UNI Bern)
Subject: Maintenance Release 2.3 of Pascal TSO Kermit
Keywords: TSO Kermit
After a hot summer while I did not very much additional work on my
TSO-Kermit, I encountered some hidden bugs ... and fixed them.
The biggest problem was a system connected with 300 baud (!) to our
mainframe. TSO Kermit didn't check for the right Y packet to come in, and
continued sending. This should be fixed now. Another not official goodie is,
that my kermit should understand attribute packets (they are logged to the
KERMIT.LOG file, so I can analyse what's coming from the micro).
I'm appending the hottest version of Kermit (Pascal and documentation)
so you can put it in the distribution library.
Thanks and regards ... Fritz
[Ed. - And thanks to you! The new files are in KER:TS2KER.PAS and
KER:TS2KER.DOC. The other KER:TS2*.* files remain unchanged.]
------------------------------
Date: Wed, 30 Sep 87 08:46:42 PDT
From: Ted Medin <MEDIN-T@SHARK.NOSC.MIL>
Subject: Version 3.79 of Apple II Kermit Available
Keywords: Apple II Kermit
Here are some significant changes from 3.75
1. Command additions/changes
a. swap bs/del keys
b. set terminal vt100/vt52/monitor
c. catalog
d. delete file
e. modem - talks to hayes modem via file kermit.modem
f. set file-type other - if you know the hex type you can set them all
2. Kermit now initializes by reading file kermit.init
3. Kermit now supports //c & //gs
4. Bug fixes by the gross
5. Finally some one wrote a driver for the cps card - thanks Alan Thomson
6. Thanks to the following for their help. Rich Fincher, Mark Johnson,
Grant Delaney, Paul Close and a host of others who i may have forgot.
You may have been forgotten but your name is probably in the source
with the code you inspired.
[Ed. - Thanks, Ted! The new files have replaced the previous ones in
KER:APP*.* on CU20B, etc etc.]
------------------------------
Date: Fri, 11 Sep 87 13:41 EDT
From: VIC@QUCDN.BITNET
Subject: Version 2.8 QK Kermit Available
Keywords: QK Kermit, Turbo Pascal, IBM PC, Tektronix Emulation
Version 2.8 adds graphics input (GIN) to the TEK4010 emulation and it provides
code for Hercules card and EGA card inaddition to the regular CGA card. The
are also other minor improvements and bug fixes, many of which were provide to
me by G.W.Selke.
Victor Lee
[Ed. - Thanks! The files are available in KER:QK*.* on CU20B and QK* * on
CUVMA.]
------------------------------
Date: Mon, 28 Sep 1987 09:38 PDT
From: JAFW801%CALSTATE.BITNET@wiscvm.wisc.edu (Jack Bryans)
Subject: MS-DOS Kermit 2.29C for RMX
Keywords: RMX Kermit
The latest test release (V2.29C) of MS-Kermit ported to RMX86 and RMX286
includes a completely new and expanded configuration option, the addition of
SET/SHOW KEY, and support for 10 ports. Previous restrictions on port
redefinition have been removed. See KER:MSTRMX.DOC for details.
KER:MSTRMX.BOO is for RMX86 and KER:MSTRX2.BOO for RMX286. The approximate
vintage of the underlying MS-Kermit modules (MSS*) is mid-August.
[Ed. - Many thanks!]
------------------------------
Date: 1987 Sep 28 22:18 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Subject: Release 1.2 of Kermit for HP264x
Keywords: HP Kermit
At long last, the new release of Rover-Kermit is ready. The update
consists of new versions of HP264X.ASM, HP264X.HEX, and HP264X.MSS,
and the latter should provide a new HP264X.DOC as well. The following
are the most important of the changes and improvements in Release 1.2:
1. Two-byte checksums.
2. Mnemonic commands for setting parameters.
3. More elaborate display of current settings.
4. ^X/^Z interruption.
5. Retain filespec on RAM file.
6. Display any characters received while waiting for handshake.
7. Fixed bug in creating repeat strings from runs longer than 94.
8. Flush data communication buffer before starting any transaction
(except the first in a given session).
9. The ROLL and HOME keys now work for the conversation workspace.
[Ed. - Thanks, John! The files are in KER:HP2*.*.]
------------------------------
Date: Fri 9 Oct 87 09:36:54-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: New Kermit Documentation in German
Keywords: German
Gisbert W. Selke of the Wissenschaftliches Institut der Ortskrankenkassen
in Bonn, West Germany, has written an introduction to Kermit for German-
speaking users, with examples from MS-DOS Kermit 2.30 and Modcomp Kermit.
The files are in KER:GERMIT.*, available via anonymous FTP from CU20B,
or as GERMIT * available from KERMSRV at CUVMA on BITNET. Thanks to
Gisbert for the contribution, as well as many useful suggestions concerning
the new MS-Kermit manual, and "national character" support in MS-Kermit.
------------------------------
Date: Thu, 24 Sep 87 10:28:17 EDT
From: dfs@nadc.arpa (N. Topping)
Subject: Need help with iRMX Kermit
Keywords: IRMX Kermit
I have been experiencing problems trying to implement the IRMX version 2.41
of Kermit (Kermit version developed by Grinnell College 87/03/04).
I am trying to implement Kermit on an Intel 80286 running iRMX release 6. I
am unable to receive files from a remote computer. The iRMX kermit says it
is receiving but never completes or returns any error messages. I am also
unable to send files using iRMX kermit because kermit aborts with a "FILE
NOT FOUND" error message. (This error message is printed whether or not the
file to be sent exists.) I have no clue to what file it is complaining
about.
If anyone has any helpful hints or information about working versions of
iRMX Kermit or how to fix these problems with iRMX Kermit 2.41 please send
mail directly to me at dfs@nadc.
Thanx in advance,
dfs@nadc
[Ed. - Try using the fancy new RMX Kermit that's based on MS-Kermit,
KER:MSTRX2.BOO, announced in the previous message.]
------------------------------
Date: Thu, 24 Sep 87 15:08:14 -0700
From: Richard Nelson <nelson@Q2.ICS.UCI.EDU>
Subject: MS-DOS Kermit 2.29C Session Logging
Keywords: MS-DOS Kermit
The new version is excellent - thanks. I have an IBM/AT with EGA/ECD,
Irma, and internal Hayes 1200B. When I dial my local Unix system and
LOG SESSION, the ATDT commands appear in the log file in readable ASCII,
but the logged-in Unix session in h19 mode is completely unintelligible.
Screen dumps come out fine. Since LOG worked fine for me in the last
version I had (v 2.27), this probably isn't a Kermit bug, but I need
assistance/advice in how to correct the problem, since taking a screen
dump won't do for recording long sessions.
Thanks Again,
Richard Nelson
nelson@q2.ics.uci.edu
[Ed. - The next release (the current test release?) now uses 7-bit bytes
for the LOG file if you have SET DISPLAY 7 (which is the default), or if
PARITY is not NONE. If you have SET DEBUG ON, however, the log file will
have 8-bit bytes.]
------------------------------
Date: Tue, 22 Sep 87 17:37 CST
From: <LOWEY@SASK.BITNET>
Subject: Bug in MSTIBT 2.29/tek3
Keywords: MS-DOS Kermit, Terminal Emulation
There appears to be a minor bug in the Tektronix terminal emulation in
MSTIBT version 2.29/TEK3. Sometimes, when the cursor position is supposed
to move without drawing anything, it instead draws a thin black line.
Normally you hardly notice it, but if the program is drawing text, or doing
a lot of short movements and short lines to draw an object, then it can make
the letter or object unreadable.
Kevin Lowey -- University of Saskatchewan Computing Services
[Ed. - This bug report has been forwarded to the author in England, who says
that a new release based on 2.29C will be arriving shortly.]
------------------------------
Date: 2 Oct 87 18:15:50 GMT
From: jem97@leah.Albany.Edu ( Jim Mower)
Newsgroups: comp.sys.ibm.pc
Subject: Kermit with Tek4010/4014 Emulator
Keywords: MS-DOS Kermit, Tektronix
I'm having some problems getting the Kermit executable from CUVMA
to run on my Zenith 248. I've downloaded mstibt.boo (ascii
translation of executable) and msbpct.bas (basic conversion program
that creates mstibt.exe from mstibt.boo), run the basic program on
mstibt.boo, got mstibt.exe, ran it and got 'program too large to
fit in memory.' Has anyone else had this experience or a happier
one?
[Ed. - Apparently the sender of the previous message had better luck.
Maybe you were done in by an ASCII/EBCDIC gremlin somewhere along
BITNET.]
------------------------------
Date: 29 Sep 87 05:26:45 GMT
From: cbmvax!vu-vlsi!devon!paul@RUTGERS.EDU (Paul Sutcliffe Jr.)
Subject: C-Kermit for Tandy 6000
Keywords: C-Kermit, Tandy Kermit
I have C-Kermit 4D(061) running (very well, thank you) on a Tandy 6000
using Tandy Xenix 3.1.2.
Xenix 3.0 is supposed to be a System III look-alike, but it has alot
of V7 stuff still. As I recall, though, I used "make xenix" after
having made a few tweaks to the Makefile and some of the .c files.
The "special hints" are mostly directed at the older (VERY V7) version
of Xenix 2.3 (Tandy version 1.x.x).
I'll put together some diffs and pass them along for you to post, if
you want.
Paul Sutcliffe, Jr.
UUCP (smart): paul@devon.UUCP
UUCP (dumb): ...{rutgers,ihnp4,cbosgd}!bpa!vu-vlsi!devon!paul
[Ed. - Please do!]
------------------------------
Date: Wed, 23 Sep 87 08:43:02 EDT
From: Marshall_DeBerry@um.cc.umich.edu
Subject: Tandy Kermit Question in V6 #22
Keywords: Tandy 6000, Xenix, C-kermit
Regarding your question about the Tandy 6000 in Info-Kermit Digest V6 #22:
I am currently running 4D(061) kermit on such a machine with no problems.
My machine has 512K memory and a 15 Meg hard drive. It runs at 6Mhz. I
have not experienced any problems with "slowness", as other's have often
described. As a matter of fact, my machine is in reality on old Model II
that was upgraded to essentially a Model 16a, which is my case is equivalent
to a Model 6000 now. Anyway, the Xenix that Tandy current supports is Xenix
3.1.2, which is pretty much like system III. Note that all the versions of
kermit I have compiled on my machine have been done under Xenix 3.xx. The
earlier version of Xenix that Tandy put out for the first Model 16's was
done from a version 7 Unix base. I have had no expericence with the older
Xenix. However, if you are using that version, you really should pay the
$99.00 to Tandy and upgrade to version 3.xx. (At least it was $99.00 about a
year and a half ago).
Anyhow, to compile C-Kermit on a 6000 under Xenix 3.xx, you need to do
two things:
1). Look in the source files for the use of identifier "void". If you
find that identifier in a file, make sure you put the include
line "#include <sys/types.h>" at the top of that file with the
other include statements.
2). Say make sys3, and wait awhile. If your system is fully loaded,
ie, about 90% full on the hard drive, and little memory, you may
not be able to compile the program. Make space on your hard drive
(down to around 75% free), and try again. It may take as long as
a half hour to compile.
Note that I recently compiled the experimental C-Kermit (the "new release")
on a 6000 under Xenix 3.1.2 with no problems, save for the "void" identifier.
Also note that I am the only user of my machine, ie, I don't have other
users running out of tty ports. I can't tell you what running kermit
is like on a 6000 with 2-3 other users.
I hope this information is of help to Tandy 6000 owners trying to get Kermit
up and running.
------------------------------
Date: Wed, 23 Sep 87 02:29:56 edt
From: hagan@operations.dccs.upenn.edu (John Dotts Hagan)
Subject: Suspending C-Kermit
Keywords: C-Kermit
I have just installed version 4E(067) on Ultrix-2.0 and have discovered
a change (hopefully a bug).
I used to be able to ^Z (suspend) out of kermit's "C-Kermit>" prompt and
all was cool. Now it exists and leaves the terminal trashed (in cbreak
mode I believe).
Is this a bug?
--Kid.
[Ed. - Sounds like one. See next message.]
------------------------------
Date: Thu, 1 Oct 1987 15:27 CDT
From: William Bruce Curtis <NU024414@NDSUVM1>
Subject: C-Kermit and Berkeley Unix job control (crtl-Z)
Keywords: C-Kermit
Is there a reason that cntrl-Z is trapped in the new release of C-Kermit?
The user document for C-Kermit says that Kermit can be stopped using cntrl-Z
(job control under Berkeley Unix) but the following code in the conint routine
in ckutio.c traps the keyboard generated stop signal (SIGTSTP) and causes the
program to exit.
#ifdef SIGTSTP
signal(SIGTSTP,SIG_IGN); /* Keyboard stop */
#endif
I have commented out the code and C-Kermit seems to work fine plus it can be
stopped from the keyboard with ctrl-Z just like the earlier releases.
Thanks,
Bruce Curtis
------------------------------
Date: Saturday 26 Sep 87 3:22 PM CT
From: Jay Ford (U of Iowa) <JNFORDPB%UIAMVS.BITNET@wiscvm.wisc.edu>
Subject: C-Kermit for Umax 4.2 on Encore
Keywords: C-Kermit
I acquired the XK*.* files for C-Kermit 4E(067) for use on an Encore
Multimax running Umax 4.2 (somewhere between BSD 4.2 & 4.3). The
"make bsd" ran flawlessly, but I ran into trouble with the tty
locking. The resulting "wermit" tries to use /usr/spool/uucp as the
lock directory, but we don't have the permissions set to allow this.
However, there is a /usr/spool/locks directory which does have
appropriate permissions, so I added a make type of "umax" which uses
this path in ckutio.c. Following are this diffs for ckuker.mak &
ckutio.c.
% diff Makefile.orig Makefile
24a25
> # for Encore Multimax Umax 4.2, "make umax"
211a213,217
>
>
> #Encore Umax 4.2 (between bsd 4.2 & 4.3)
> umax:
> make wermit "CFLAGS= -DBSD4 -DUMAX -DDEBUG -DTLOG"
% diff ckutio.orig.c ckutio.c
793a794,796
> #ifdef UMAX
> char *lockdir = "/usr/spool/locks";
> #else
794a798
> #endif /* umax */
------------------------------
Date: Thu, 01 Oct 87 23:52:57 EDT
From: moore@UTKCS2.CS.UTK.EDU
Subject: Minor Bug in C-Kermit under Ultrix
Keywords: C-Kermit, Ultrix
In C-Kermit 4E(067) 14 Sep 87, 4.2 BSD:
When compiling under Ultrix 2.0, using the vcc C compiler (which is slightly
better than pcc), C-Kermit doesn't compile cleanly, due the the existence
of several #ifdef vax11c lines in some of the .h files. These have been used
to denote VAX/VMS specific code. The vcc compiler pre-defines the symbol
vax11c on Ultrix just as it does on VMS. C-Kermit can be made to compile
cleanly on both Ultrix and VMS if these lines are changed to #ifdef vms.
Keith Moore
UT Computer Science Dept. Internet: moore@utkcs2.cs.utk.edu
107 Ayres Hall, UT Campus CSnet: moore@tennessee
Knoxville Tennessee BITNET: moore@utkcs1
[Ed. - Thanks for the useful hint!]
------------------------------
Date: Wed, 30 Sep 87 9:39:15 EDT
From: Brian Vaughan <vaughan@VAX.BBN.COM>
Subject: Modem Control without Carrier
Keywords: Masscomp Kermit, C-Kermit, Modems
I am trying to set up Kermit on a Masscomp running RTU 3.1a UNIX with a
Telebit Trailblazer 18000 baud modem (Hayes like). The Kermit used is
version 4.2 and came from Masscomp's user library.
My problem is in controlling the local modem when not connected to another
remote modem (no carrier). The ideal solution is a new kermit command organized
like the DIAL command to get around the unix clocal control.
Does anyone out there know of such an improvement?
Please send a copy of your reply directly to me as I'm not a regular reader
of Info-Kermit.
If a newer version of Kermit includes what I need, could you include detailed
instructions on where and how to pick up a copy? I'm still a little wobbly
in net land.
Thanks in advance.
------------------------------
Date: Fri, 18 Sep 87 15:06:07 EDT
From: sanchez@gmu90x.UUCP (Jim Sanchez)
Subject: Kermit for Convergent Tech Wanted
Keywords: Convergent Technologies,CTOS,BTOS,Burroughs B26
I need a source for or pointer to a terminal emulator supporting kermit for
the Burroughs B26 series workstations. These are basically convergent
technologies units with a slightly modified CTOS operating system. I have a
PLM compilier for this system if only sources are available. Please email
me if you know where I can get such an animal. Thanks in advance.
Jim Sanchez, Sytek Inc.
301-520-5100
UUCP:..!uunet!pyrdc!gmu90x!sanchez or ..!hplabs!sytek!jim
ARPA: sytek@nswc-wo.arpa
[Ed. - Presumably, the C-based Convergent CTOS version announced in
Info-Kermit V6 #21 should also work on Burroughs B20-series systems with
BTOS. Has anyone tried this yet?]
------------------------------
Date: Mon, 28 Sep 1987 13:08 CDT
Sender: L-HCAP List <L-HCAP@NDSUVM1>
From: Bob Puyear <NU025213@NDSUVM1>
Subject: Data General One Help Needed
Written-by: Rick Alfaro (FidoNet)
Keywords: DG1 Kermit
I recently aquired a DG 1 with an internal modem. Unfortunately the only
communications program that I hvae found to work with the internal modem is a
special version of Crosstalk for the dg 1. I am totally blind and use a
speech synthesizer and screen reading software with my system. The screen
reading program will only voice data written to the screen via normal dos
calls. Crosstalk takes incoming data and writes it driectly to the screen
thereby making it unavailable to the speech program. I am trying to find a
shareware program like Procomm or Telix that will work with the DG 1 internal
modem. Maybe there is a patch available somewhere for one of the exsisting
comm programs. I would appreciate any info that will help me solve this
problem. Thanks in advance. Rick Alfaro
[Ed. - See message below.]
------------------------------
Date: Mon 28 Sep 87 15:17:10-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Data General One Help Needed
Keywords: DG1 Kermit
In response to Rick Alfaro's request for a communication program that will
work with the DG/1, doing only DOS calls to the screen, he might want to try
MS-DOS Kermit. The latest release senses the absence of a true 8250 UART and
then does only DOS calls to the port, and if you "set terminal none", it will
also do only DOS calls to the screen. Furthermore, if you "set display
serial", its file transfer display will make sense to a speech program (in
fact, this mode was designed specifically for that purpose). Version 2.29C
of MS-DOS Kermit is available from Columbia University on diskette by mail
order, or over BITNET or other networks. Feedback about its utility (not only
on the DG/1, but also the IBM PC family or any MS-DOS machine) for the blind
and/or deaf would be much appreciated. - Frank
-----------------------------
Date: Fri, 02 Oct 87 16:18:40 GMT
From: GAYE@FRSAC11.BITNET
Subject: DPS8 Kermit and X25
Keywords: DPS8 Kermit, X.25
I would like to use kermit on a DPS8 machine runnig GCOS 8
1) What I understand Kermit DPS 8 is doing:
+-+
+------+ |D| +------+
| | |A| asynchronous line |micro |
| DPS 8|----|T|----------------------| |
|kermit| |A| |kermit|
+------+ |N| +------+
|E|
|T| virtual terminal
+-+ and file transfer
2) What I would like to do:
+-+
+------+ |D| | X25 | +-+ +------+
| | |A| X25 | public| X25 |P|asynch. |micro |
| DPS 8|----|T|------| |-------|A|--------| |
|kermit| |A| |network| |D| line |kermit|
+------+ |N| | | +-+ +------+
|E|
|T| virtual terminal
+-+ and file transfer
I don't know very much about the Datanet
Anybody thinking that I have any chance to do that ?
What kind of thing I have to do on the Datanet or anywhere else ? Some
people in France tell me that the data coming out of the Datanet with X25
are always encapsulated in DSA frames. Is that true ?
I am completely lost ...
Thank you in advance.
Gerard H. Gaye
Cisi-Telematique
CEN Saclay, BP 24
91190 Gif sur Yvette
France
gaye@frsac11 (bitnet)
------------------------------
Date: Wed, 23 Sep 87 13:39:11 +0200
From: Hans Anton Aalien <hans@ifi.uio.no>
Subject: AAFILES.DIR on CU20B Kermit Areas
Keywords: AAFILES.DIR
Are you aware that the automatic update of the AAFILES.DIR files has stopped?
If you were not, now you are. I often found those files useful for more
detailed "detective" work on the distribution areas, so I would like the
service to be restarted. If you could invent a file name to identify directory
(i.e. tape) as well, I think that would be an advantage -- e.g. AAFIL1.DIR ...
AAFIL5.DIR, AAFILB.DIR, AAFILT.DIR, etc.
Hans
[Ed. - You're right! The automatic daily batch job that does this has been
restarted. Good idea about the names -- they've been changed as you
suggested.]
------------------------------
Date: Sat 19 Sep 87 12:47:34-PDT
From: Bob Larson <BLARSON@ECLA.USC.EDU>
Subject: Kermit-68K Problems for OS-9
Keywords: 68000 Kermit, OS-9
To build k6 on my FHL QT+ (osk version 1.2, 2.1 is on the way) it needed
a couple of simple fixes:
The reference to "/d0" in the makefile needs to be changed to "/dd". (/dd
should work on any system configured as recomended by microware.)
The "use defsfile" line in all source modules needs to be changed to "use
/dd/defs/defsfile". (Again, /dd is the standard place to keep this.)
Connect has a MAJOR problem: it converts incoming /r to /r/l, and ignores
the following /l. This does not work with systems that put null padding
between (tops20) or with ANY full-screen program. (My z29 emulates a z29
just fine, thankyou.) My attempt to fix this did not work.
Oh well, I wasn't in to desperate of need for a third kermit implementation
for my system. I really should finish the C-Kermit port enough to make it
distributable, and update it to the latest verison of c-kermit.
Bob Larson
[Ed. - Thanks for the comments, Bob. They've been added to KER:K6OAAA.BWR,
and forwarded to the program's author.]
------------------------------
End of Info-Kermit Digest
*************************
-------
23-Oct-87 15:28:48-EDT,28224;000000000000
Mail-From: SY.CHRISTINE created at 23-Oct-87 15:25:25
Date: Fri 23 Oct 87 15:25:24-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #24
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12344835260.39.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Fri, 23 Oct 1987 Volume 6 : Number 24
Departments:
ANNOUNCEMENTS -
RE: Info-Kermit Digest V6 #23 Multiple Copies
Kermit HEX file for the Amstrad PCW
MS-DOS iRMX Kermit Documentation
MS-DOS KERMIT -
Use of Kermit by the Disabled
Space Key on MS-Kermit 2.29c
MS Kermit 2.29C Report or Query
Problem with Input Translation and 'SET DISPLAY 7'
Kermit 2.29C VT-102 Emulation
Kermit-MS v2.29c
MS-Kermit 2.29c Comments
Kermit with Zenith COM3
Printing through a PC (2 messages)
MACINTOSH KERMIT -
MacKermit, Key Redefinition
MacKermit 0.8(35) bug?
Mac Kermit CKMKEY & XKMKEY
MacKermit 0.8(35) Can't Save Settings File
Mac .HQX files
MISCELLANY -
Thanks on CONNECT.PASVT100
Kermit Versions and Packet Size
VMS: No Default Terminal Line for Transfers
----------------------------------------------------------------------
Date: Wed 14 Oct 87 15:19:29-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: RE: Info-Kermit Digest V6 #23 Multiple Copies
Keywords: Info-Kermit Digest
You may have gotten 2 different versions of Info-Kermit Digest V6 #23.
The first digest was sent out and was lost somewhere in the network.
Meanwhile, thinking that digest was not sent out, I added some other
messages and sent out yet another version of the digest. Sure enough,
both copies got sent. Keep the latest copy (with the German documentation
message in it). I apologize for any inconvenience this may have caused.
------------------------------
Date: 15-OCT-1987 13:34:27 GMT +01:00
From: SYSKERMIT%vax1.central.lancaster.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Kermit HEX file for the Amstrad PCW
Keywords: Amstrad PCW
The system-dependant HEX file for the Amstrad PCW was sent to us by
Phil Wade of Hull University computer centre.
Regards,
Steve Jenkins.
[Ed. - Thanks Steve and Phil. This HEX file is in KER:CP4PCW.HEX available
from Arpanet by FTPing to CU20B, user ANONYMOUS (any password) and GETting
the file or thru BITNET using KERMSRV.]
------------------------------
Date: Tue, 22 Sep 1987 09:00 PDT
From: JAFW801%CALSTATE.BITNET@wiscvm.wisc.edu (Jack Bryans)
Subject: MS-DOS iRMX Kermit Documentation
Keywords: iRMX Kermit, MS-DOS Kermit
MSKERMIT, the richest and most widely used implementation of KERMIT for the
small computer, has been ported to iRMX86 and iRMX286. The .DOC file
discusses differences between KERMIT and MSKERMIT, where KERMIT refers to
the RMX version and MSKERMIT refers to the DOS program. Users unfamiliar
with MSKERMIT may prefer to read this in conjunction with MSKERM.DOC.
[Ed. - Thanks Jack! The file is in KER:MSTRMX.DOC.]
------------------------------
Date: Tue 20 Oct 87 09:51:19-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Use of Kermit by the Disabled
Keywords: MS-DOS Kermit 2.30, Disabled
In preparing version 2.30 of MS-DOS Kermit for release, we are trying to
make the program as useful as possible for people with disabilities like
motor impairment, blindness, or deafness. This program provides terminal
emulation and file transfer for PCs in the IBM PC family, for IBM
compatibles, the DEC Rainbow, and many other MS-DOS systems, and it is
available free of charge by copying from someone who has it, downloadable
over networks and BBS's, or by mail order for a modest distribution fee
from Columbia University or various diskette services. There are
several factors that could inhibit Kermit's use by the disabled:
. The escape sequence to get back to Kermit after connecting to a remote
system is Control-Rightbracket followed by C. People who can only press one
key at a time should not be required to enter control sequences. Similarly,
people with only one hand should not be expected to type control characters
beyond their reach. The new release will allow the Kermit escape-back or
other CONNECT-level escape commands to be assigned to single keys, like F1.
So far so good.
. The screen display during file transfer has fields for the filename,
the number of packets transferred so far, the number of bytes, etc. These
fields are updated randomly, so that Kermit's output during file transfer
would make little sense when redirected to a Braille or voice device. SET
DISPLAY SERIAL remedies this.
. During terminal emulation, Kermit bypasses DOS and the BIOS and writes
directly to screen memory. This would also bypass any special drivers
installed by people with voice or Braille output devices. The command SET
TERMINAL NONE turns off terminal emulation and uses DOS for all screen
writes, allowing DOS or BIOS-level drivers to be used.
. In order to allow the widest possible range of key redefinitions, Kermit
uses the BIOS to obtain key scan codes, thus bypassing any DOS-level console
drivers, like ANSI.SYS (but not BIOS-level drivers like SuperKey and
ProKey). Kermit can be directed to use DOS to obtain key codes, but then
the distinction is lost between various keys (like the digit "2" above the
"Q" and "W", and the digit "2" on the numeric keypad). However, when DOS is
used, there is an apparent problem in DOS itself when multiple characters
are assigned to a single key (involving nonblocking character reads). Thus
BIOS-level keyboard handling could potentially bypass DOS-level drivers
distributed with special keyboards, but DOS-level drivers could have
annoying restrictions.
Please help us to make the program as useful as possible by answering the
following questions (or offering any other comments):
1. If you are directing screen output to a voice, Braille, or other device,
please let us know what the device is, how the redirection is done, and (if
you know it) whether the redirection is at the DOS, BIOS, or hardware level.
Also, are there screen drivers for the deaf that translate sounds (like the
terminal beep) into special visual effects? Again, at what level do they
operate?
2. If you have a special keyboard, keyboard replacement, or keyboard driver,
please let us know about it. Does the driver operate at the DOS, BIOS, or
hardware level? Does the device look like a real keyboard to the system's
BIOS?
3. What about TDD modems? Clearly, Kermit or other ASCII-based
communication programs are not compatible with Baudot-only TDD systems.
Translating between ASCII and Baudot is not a practical solution, because
the ASCII alphabet is more than twice the size of Baudot. Packet-mode
file transfer would be impossible because the Kermit packets could not be
uniquely reconstructed on the receiving end. Presumably there is movement
in the TDD world away from Baudot to ASCII code?
4. Any other considerations we may have overlooked?
Thanks for your help!
Frank da Cruz
Columbia University
Center for Computing Activities
612 West 115th Street
New York, NY 10025 USA
Network addresses:
SY.FDC@CU20B.COLUMBIA.EDU (Internet)
FDCCU@CUVMA (BITNET)
...uunet!columbia!cu20b!sy.fdc (Usenet)
------------------------------
Date: Tue, 22 Sep 1987 09:36 CDT
From: William Bruce Curtis <NU024414@NDSUVM1>
Subject: Space Key on MS-Kermit 2.29c
Keywords: MS-DOS Kermit
There seems to be an error in the show key command for mskermit 2.29c.
Space, ctrl-space, alt-space and shift space all show up as the same scan
code. This is also true for the scan program that was mentioned in the
lastest digest (msuchk.boo). We have an application where we want to define
alt-space to somethng else.
Thanks,
Bruce
[From jrd - ALT/Control/Shift Space all yield the same scan code. True. The
IBM Bios says the space bar is unaffected by these modifier keys and Kermit
uses largely what the Bios reports. There are plenty of modified Function keys
around (some nearly out of reach above normal keys).]
[From jrd - While on this subject, there have been several requests to allow
the RETurn key to be separated from a duplicate found on some numeric keypads.
This seems reasonable until the regular RET key is undefined and then it sends
nothing at all! Overall, this is a messy situation because Kermit has no
advance information about the keyboard and which keys send what. Not only
that, but the duplicate RET may even return the same scan code as the regular
key, depending on which keyboard is being examined. I've tried my machine with
and without this feature and have ended by cursing it when I've undefined it
once too often without thinking. The subject is not entirely closed but the
odds are not favorable for a neat solution.]
------------------------------
Date: Thu, 24 Sep 87 16:59 EST
From: "GLENN EVERHART, 609 486 6328" <EVERHART%ARISIA%rca.com@RELAY.CS.NET>
Subject: MS Kermit 2.29C Report or Query
Keywords: MS-DOS Kermit
I have been attempting to create a MSKERMIT.INI file for the 2.29c rev of
Kermit and have hit what appears to be a brick wall. The keypad I want to
create basically uses the bottom 4 rows of the IBM AT keypad to look exactly
like the bottom 4 rows of a VT100 keypad, with PF1 thru PF4 mapped to F1-F4 and
F7-F10 acting as arrow keys. This is a particularly easy configuration to
remember and use.
In 2.29b and earlier, SET KEY SCAN could be used this way since the keypad 5
key had a different scan code from the 5 key above the main keyboard. In 2.29c
this appears to have changed. Moreover, it's not clear that ANY definition is
now possible to recapture this desirable behavior, since SHOW KEY now shows the
two "5" keys alike (note I have to be in numlock mode to get any scan code back
at all).
I'd like to request that some disambiguating method be re-inserted in the code
if possible before 2.30 is frozen. It's very handy to have access to all the
keys, in spite of the IBM screwups in the keypad 5 key case.
Glenn Everhart
Everhart%Arisia.decnet@ge-crd.arpa
[From jrd - The most recent version separates the keypad items from the
typewriter top rank aliases, such as the numbers. Of course, keypad 5 was
damaged by IBM so to use it at all the keypad must be shifted into numeric mode
by either NumLock or Shift keys. See if the current version is better for your
application.]
------------------------------
Date: Fri, 25 Sep 87 17:18:45 +0200
From: hans@ifi.uio.no
Subject: Problem with Input Translation and 'SET DISPLAY 7'
Keywords: MS-DOS Kermit
I connect to mainframes which (normally) use 7-bit ASCII characters for text.
By convention the characters [\]/{|} (following ASCII Z/z) are interpreted as
national (Norwegian) letters -- and not the standard brackets/braces, etc.
The IBMPC uses 8-bit ASCII, including the national letters (above ASCII 127).
To use the PC as a terminal, I have six "SET KEY" commands, and corresponding
"SET TRANSLATION IN" commands to do the mapping, the first pair being
"SET KEY \146 \91" and "SET TRANS IN \91 \146".
All goes well with the Aug 12 edition, but with the new (12 Sep) version
(MSTIBM.BOO.18,19 on CU20B), my input translations don't work any more.
But that's just what the latest manual (MST29C.DOC) tells me, too:
"The sequence of applying filters to received characters is: ....
4. translate if TRANSLATION INPUT is ON
5. if LOG SESSION is active then copy character to file
6. pass character to the terminal emulator which does:
.... else
if SET DISPLAY is 7-BIT then remove high bit before use."
The TOPS20 and unix systems I use normally send parity with output characters,
so I rely on (the default) "SET DISPLAY 7-bit". But then, of course, my newly
translated Norwegian letters are garbled.
Can my problem be solved with another combination of commands? If not,
could you consider changing the sequence of actions, referred to above?
Or is there another possibility? I really hope something can be done!
Hans A. ]lien, Inst. of Informatics, Univ. of Oslo, Norway (hans@ifi.uio.no)
[From jrd - Log file shows high bit in many characters even when Set Display 7
bit is active. That's the way it is designed presently, logging is done
between the Set Translation filter and the Set Display filter. Maybe we should
apply the 7/8 bit filter to the log file as well. On the same subject, some
Unix systems like to send characters with parity almost no matter what one
tells the operating system. On mine, stty -parity does not seem to help much
either, but then that machine wins more battles than me.]
[From jrd - In response to Hans ]lein: It seems that his TOPS-20 system uses
parity frequently and he uses SET DISPLAY to remove the high bit. I think the
proper thing to do is use SET PARITY xxx to remove the high bit from the
communications line and then the two filters above should produce the desired
National characters with SET DISPLAY 8-bit. Parity of MARK (or occassionally
SPACE) is acceptable to most 8-bit systems and chops off the high bit upon
reception (as well as stimulating 8 bit quoting on file transfers).]
[Ed. - Even though DEC systems like the DEC-20, VAX, etc, normally send parity
during a terminal session, the Kermit programs put the communication line into
8-bit "binary" mode for file transfer, so that 8th-bit quoting is not
necessary.]
------------------------------
Date: Tue, 29 Sep 87 16:01:17 mdt
From: Richard Cook <cook@TRAMP.COLORADO.EDU>
Subject: Kermit 2.29C VT-102 Emulation
Keywords: MS-DOS Kermit
I had noticed the problem with using terminal emulation in 2.29C, but what
seems to be happening is that some programs/utilities will try to use
reverse video when they see a VT-102. The escape characters sent to reverse
the video also reverse the intensity so that if you had white on blue you
get low intensity characters from then on (as in the status line). This is
"fixed" temporarily by escaping back to the PC (I'm on an IBM AT) and
reconnecting, but the next reverse video flips things back again. This
happens, for example, when I use the rn program to read Info-Kermit and rn
tries to highlight the subject field. The problem does not occur with the
original 2.29 Kermit.
[From jrd - Some utilities program the MS Kermit/IBM screen back to dim
(normal) intensity. That is correct. The host can change the attributes,
including intensity. The current Kermit is "smarter" and allows the screen to
show two levels of intensity, which are required by some applications. I think
we are stuck with that behavior until IBM changes matters or I add yet one more
Set Terminal command to change colors rather than intensity.]
------------------------------
Date: Fri, 2 Oct 87 09:10 EST
From: <BESSON@VUVAXCOM.BITNET>
Subject: Kermit-MS v2.29c
Keywords: MS-DOS Kermit
When using Kermit-MS version 2.29c to run GNU Emacs on a Vax, I find that
Ctrl-@, the command to set the mark, no longer works; it just rings the
bell with no other message. The mark is set properly with version 2.29.
Any ideas would be appreciated.
M. Besson
Villanova Univ.
[Ed. - The new MSTIBM.BOO, dated 8 Oct 1987, announced in Info-Kermit Digest
V6 #23 has an added key definition to make Control-@ send a null character
by default, as many have requested.]
------------------------------
Date: Wed, 23 Sep 87 14:07 EDT
From: "Ken Van Wyk, User Services, ext. 4988" <LUKEN@VAX1.CC.LEHIGH.EDU>
Subject: MS-Kermit 2.29c Comments
Keywords: MS-DOS Kermit
I've been playing with Kermit 2.29c quite a bit and I have a couple
comments/suggestions to make.
First, I really like being able to assign a Kermit "verb" to a key. This is a
very useful feature that was sorely lacking in earlier versions, in my opinion.
An additional verb that I would like to see is "quit", which actually exits
kermit, regardless of whether or not there are any pending commands in (say) an
MSKERMIT.INI file.
Also, I would *LOVE* to see a command line parameter (say, -F) which instructs
Kermit to read from a file *OTHER* than MSKERMIT.INI. This would greatly ease
the job of building a menu driven interface (for the rest of the world) around
Kermit. A command line could then read, for example, KERMIT -F
C:\KERMIT\VAX.INI or KERMIT -F C:\KERMIT\IBM.INI or something like that. Any
takers?
[Ed. - Good ideas, but no prognosis for whether such a feature will make it
into 2.30.]
Some users have also asked for COM3 and COM4 support in Kermit. Is this going
to work in 2.30?
[Ed. - 2.30 contains hooks for COM3 and COM4. See KER:MST29C.DOC for how
to use them.]
Finally, is 2.30 going to work on a Z-100? Is anyone working on that? If so,
will it support VT-100 (or 102...)? I know of a few Z-100 users who would
deeply appreciate this, myself included.
[Ed. - We need a Z-100 wizard to help with this. Any volunteers?]
Thanks!
------------------------------
Date: Thu, 15 Oct 87 07:47:40 PDT
From: Steve Dennett <DENNETT@SRI-NIC.ARPA>
Subject: Kermit with Zenith COM3
Keywords: MS-DOS Kermit 2.29C, Zenith
There has been some previous discussion of versions of MS-DOS Kermit that
use the (IBM?) COM3 port. Zenith, in the Z248 (80286) PC sold in large
quantities to the government, includes its own non-IBM-compatible COM3 port
on a board called the Z-304. One of our programmers is trying to adapt some
comm software for us, and is having a terrible time, and getting information
from Zenith is an uphill battle.
Has anyone successfully adapted Kermit (or any other comm program) to run
with *this* board's COM3 port? If so, I'd really appreciate pointers to the
code, esp. that used for handling interrupts when receiving information.
Thanks!
Steve Dennett
dennett@sri-nic.arpa
------------------------------
Date: Wed, 14 Oct 1987 08:06 -
From: Peter W. Day <OSPWD@EMUVM1>
Subject: Re: Printing through a PC
Keywords: MS-DOS Kermit 2.29B, Printing
>Date: Wed, 14 Oct 87 12:40:38 GMT
>From: Dermot O'Beirne <DOBEIRNE@IRLEARN>
>Subject: Printing through a PC
>
>Can anyone tell me how to set up our system to allow host printing
>commands to print through the parallel Centronics type and / or second serial
>RS232 ports of a PC when in VT100 emulation mode using KERMIT 2.29.
Kermit-MS (ver 2.29b) supports a PC-attached Printer using the ANSI defined
sequences
escape left square bracket 5 i (Print on)
escape left square bracket 4 i (Print off)
Send the "print on" sequence followed by the text to print followed by the
"print off" sequence. Anything between these sequences will be directed
to the PC-attached printer instead of the screen.
On an IBM computer, you are out of luck unless you can somehow send a character
which gets trabslated to an ESC. This is possible through a 7171 protocol
converter, but I don't know about other types of IBM ASCII connections.
Peter Day
Emory University
[Ed. - Thanks for the help, Peter. See Joe's message below also.]
------------------------------
Date: Wed, 14 Oct 87 10:22 MDT
From: Joe Doupnik <JRD@USU.BITNET>
Subject: Printing through a PC
Keywords: MS-DOS Kermit 2.29C, Printing
Your mainframe can send a pair of escape sequences to the PC which,
if everything is working properly, will relay further bytes directly to the
PC's main printer (PRN).
The sequence to start this "transparent printing" operation is
ESC [ 5 i which is Media Copy On or DEC's Controller Print ON
and
ESC [ 4 i turns off this mode.
Neither sequence is printed and nothing shows on the screen. This operation
and other similar kinds are described in the manual accompanying MS Kermit
version 2.30 (when it appears sometime next century).
A similar pair drives both the screen and the printer:
ESC [ ? 5 i turns it on (DEC's Auto Print On)
and ESC [ ? 4 i turns it off again.
Support of these is recent so be sure to get the latest MS Kermit
from Columbia (and yes, it is still volatile).
Regards,
Joe D.
------------------------------
Date: Tue, 6 Oct 87 14:17:45 EDT
From: BJ CAMERON (SYSTEMS DEVELOPMENT) <HESSE@WATDCS>
Subject: MacKermit Key Redefinition
Keywords: MacKermit
I recently received a version of MACKERMIT 8(34) from the Bitnet server at
Columbia. I was wondering if there is a way to access the extra keys
available on the new style keyboards? Is there a list of scan codes that
get returned for these keys?
[Ed. - Currently, no. The new keyboards and systems have an entirely
different way of handling the keyboard than is coded into Mac Kermit. Some
people in various places are working on an update, but there's no estimated
release date yet.]
------------------------------
Date: Mon, 21 Sep 87 16:57:03 EST
From: Bob Blackmun <ACC00RRB@UNCCVM>
Subject: MacKermit 0.8(35) bug?
Keywords: MacKermit
I have downloaded MACKermit 0.8(35) (otherwise known as XKMKER.HQX) from
CUVMA, run it through BinHex 4.0, and find that it changes my keyboard
definition file (created by XKMKEY.HQX) unless I first lock the keyboard
file. Is this normal? (I have not had this experience with the previous
(CKMKER.HQX, version 0.8(34)) version.)
[Ed. - Since we have had so many complaints about this, it must be "normal".
Let's hope a new release will appear soon that corrects these and other
problems, especially when Mac Kermit is run on the Mac II or SE. Meanwhile,
see messages below.]
------------------------------
Date: Mon, 28 Sep 87 10:39:20 EST
From: Bob Blackmun <ACC00RRB@UNCCVM>
Subject: Mac Kermit CKMKEY & XKMKEY
Keywords: MacKermit
We are having problems with CKMKEY 0.8 (6) and/or (7). Both versions
appear to clobber the terminal file while saving it, even if no changes
are made to the file. Is anyone else having similar problems? We have
found that CKMKER 0.8(35) does the same thing unless the terminal file
is locked. What are we doing wrong!!
[Ed. - Nothing, sad to say. But see next message.]
------------------------------
Date: Mon 12 Oct 87 22:39:11-PDT
From: Jim Lewinson <a.Jiml@GSB-HOW.Stanford.EDU>
Subject: MacKermit 0.8(35) Can't Save Settings File
Keywords: MacKermit, Settings
If told to, MacKermit SAYS it is saving the settings file on top of an
existing settings file, but it doesn't really do it. The old settings
remain. However, if you save it under a new name, it works just fine.
Then you can rename the new file to the old name and all works nicely.
However, it is a bug.
Jim
P.S. I'll bet you are going to add a message to end of this saying:
"Added to .BWR file". :-)
[Ed. - Added to .BWR file.]
------------------------------
Date: Mon, 28 Sep 87 22:57:31 PST
From: jww@sdcsvax.ucsd.edu (Joel West)
Subject: Mac .HQX files
Keywords: MacKermit, BinHex
Most user groups have a public domain disk that includes
Binhex V4.0
which is the program for encoding/decoding a complete Macintosh binary file
to printable characters. If you intend to be sending/retreiving Macintosh
documents or programs from KERMSRV or anyone on the mail system, you should
obtain a copy. (Also, as noted, it's on the Columbia Mac disk.)
------------------------------
Date: Wed, 23 Sep 87 17:59 EDT
From: DESCALANTE@rcca.bbn.com
Subject: Thanks on CONNECT.PASVT100
Keywords: QK Kermit
As it turns out, I had downloaded the QK-Kermit on July 20, and the Ctrl-Z
problem got me. Hadn't bothered looking at it much since then. Now I have
the right connect file and the KEYTABLE.DAT file, so thanks for the help.
Now for two by-the-ways:
1) Now that it compiled beautifully, seems to be having problems talking to
KERMIT32 on our VAX, although the terminal emulation is fine. Haven't
spent more than an hour on it, though, so haven't really isolated the
problem.
[Ed. - Try the new version announced in Info-Kermit Digest V6 #23 and see if
that makes the problem go away.]
2) Picked up Frank da Cruz's book, called something like "KERMIT - A File
Transfer Protocol" a month or so ago, since I'm much more familiar with
the whims of XMODEM than KERMIT and wanted some help. It's really
excellent in all three areas I noted -- as a comm tutorial, a KERMIT
reference, and programmer's guide. Thanks to Frank for taking the time
to write such a readable and thorough explanation of the protocol. Has
it been publicized anywhere on the net, or is he being quiet/modest
about it?
[From Frank - Thanks for the nice words. There was actually a totally immodest
announcement of it in Info-Kermit V5 #13 (Oct 8, 86).]
Anyway, once more, thanks for the help and the book.
David Escalante
------------------------------
Date: Mon, 12 Oct 87 08:27 EDT
From: GARTLEY@ALCOA.COM
Subject: Kermit Versions and Packet Size
Keywords: Kermit Features
Last week I downloaded Kermit for the MAC, IBM, and VMS. I found that the
IBM version 2.29b supports packet sizes greater than 90 bytes. After tring
the MAC 0.8(35) and VMS 3.3.111 I found both of these versions do not have
this feature implemented. Is there any versions that support larger packet
sizes. The main reason I would like this version is for file transfers on
our broadband lan.
Is there a table that lists the optimum packet size and data rate.
John Gartley
Gartley%alcoa.com@relay.cs.net CSnet
Gartley@atdncf.alcoa.com ARPAnet
[Ed. - The only versions (so far) which contain long packet support are
MS-DOS 2.29C (soon to be 2.30), CMS Kermit 3.1, PDP-11 Kermit, and VAX/VMS
C-Kermit 4E (the C version, not the Bliss version). The next time somebody
builds Mac Kermit from the current C-Kermit base, it too should support long
packets. The documentation of each Kermit program should give "capabilities
at-a-glance" (many do). Meanwhile, it would be useful to have a document
that lists the features of each Kermit program in a table. Hopefully, we
will get around to producing such a document. Volunteers are always
welcome.]
------------------------------
Date: Tue, 13 Oct 87 16:13 N
From: <HELMUT@HNYMPI51.BITNET> (Helmut Feldweg)
Subject: VMS: No Default Terminal Line for Transfers
Keywords: VAX/VMS Kermit
I'm new on this list, so the following question undoubtedly has been
asked before. Still, I don't know the answer:
We are running KERMIT-32 (version 3.0.051) on our VAX 11/750 running
VMS 4.4 using logical terminal lines generating terminal names
like _LTAn: where n increases by one for every user logged in
since the last shutdown of the system. It happens occasionaly that our
system managers manage to keep the machine alive without a shutdown
over a period of time, so 'n' will exceed 999. Our version of KERMIT
doesn't like terminal numbers greater 999 (= terminal names exceeding
8 characters). It says 'no default terminal line for transfers' and
refuses to accept any command. A way out is to create a new process
via "$ SET HOST node", where the trouble with high numbers doesn't occur,
but this is a boring procedure.
Any hints to avoid this?
Helmut Feldweg
Max-Planck-Institut fuer Psycholinguistik
Nijmegen, The Netherlands
e-mail: helmut@hnympi51.bitnet
[Ed. - Run version 3.2 or 3.3 of VMS Kermit, which contain a fix for this
problem.]
------------------------------
End of Info-Kermit Digest
*************************
-------
6-Nov-87 17:28:47-EST,26624;000000000000
Mail-From: SY.CHRISTINE created at 6-Nov-87 17:27:48
Date: Fri 6 Nov 87 17:27:45-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #25
To: Info-kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12348538470.64.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Fri, 6 Nov 1987 Volume 6 : Number 25
Today's Topics:
New 2.29C Test Version with Support for Enhanced Keyboards, etc.
Announcing Mac Kermit 0.9(36)
Initial Impressions of Mac Kermit 0.9(36)
Use of Kermit by the Disabled
Easylink and C-Kermit
How to Get C-Kermit for Data General AOS/VS?
Amiga Kermit
VMS 4.6 Bug Report with C-Kermit 4E(067)
Mapping Kermit65's Vt100 emulation to GS & //e Keypad
MS-Kermit and IBM Mainframes
RSTS V7.0 Kermit Wanted
More on C64 Kermit V2.0
Diffs for C-Kermit 4D(061) and Tandy 6000
Long Packets in CD3KERM
Long Packet Support in Apple Kermit
Tektronix Excerciser Needed
----------------------------------------------------------------------
Date: Mon, 26 Oct 87 21:27 MST
From: <JRD%USU.BITNET@CUVMA.COLUMBIA.EDU> (Joe Doupnik)
Subject: New 2.29C Test Version with Support for Enhanced Keyboards, etc.
Keywords: MS-DOS Kermit 2.29C, Enhanced Keyboards
I found a safe way to test for the IBM Enhanced keyboard and use it if
found. The improved keyboard translator was tested locally on a PCs Ltd 386
with the Enhanced keyboard, on two PCs Ltd 286's (one supporting the
keyboard and the other <mine!> with an older Bios which does not), and a
Zenith 151 PC clone which also predates Enhanced keyboards. Systems having
the new keyboard and a compatible Bios can use F11, F12, the separate arrow
keys, plus digit 5 and asterisk and forward slash keys on the keypad as
essentially new keys. This means NumLock can be toggled on for a numeric
keypad and still let the separate arrow keys operate as regular arrow keys.
Status and Help displays were tweaked by one column to provide readable
results for 40 column displays. The terminal emulator works just fine with
40 columns (excepting both the status line and drop down help menu) since I
made the dynamic screen size improvements this summer. Try DOS MODE CO40 or
similar to see this in action.
This one also fixes (?) the reported problem of an extra character occurring
between the packet's EOL and Handshake chars causes loss of the packet, and
it fixes a mangled Set Handshake command (crunched in a general cleanup
recently).
Regards,
Joe D.
[Ed. - Thanks, Joe! The new version is, as usual, in KER:MSTIBM.BOO, and
the manual draft, KER:MST29C.DOC, has been altered to reflect the new
changes. This release, however, has (at least) one minor bug. ASCII RUB
(DELETE) appears on the screen as a little house. You can fix this by putting
the following statements in your MSKERMIT.INI file:
SET TRANSLATE INPUT ON
SET TRANSLATE INPUT \127 \0
This glitch will be removed in the next (pre)release.]
------------------------------
Date: Wed, 28 Oct 87 18:43 GMT
From: <MACMAN%CZHETH5A.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Announcing Mac Kermit 0.9(36)
Keywords: Macintosh Kermit
Some times ago Carlos Albuerne was so kind to pass my Modula-2 version
of Kermit to you. In his letter he mentioned that you might be glad about
some help with the Macintosh version. So I'm happy to be able to send
you a new enhanced binary version of the program. It's a port to MPW C
including many bug fixes and new features. Here is a short (unordered and
incomplete) list of the changes I made to the program:
# The Cursor with open desk accessories now works correctly
# Long packets now supported
# Dialog boxes cleaned up
# New program icon
# Settings files are no longer TEXT
# Changed "Restore ResourcesE" to "Load ResourcesE"
# Reformatted many parts of the source to be better readable
# Settings can now be written back to an already existing settings file
# Server mode: added directory listing feature
# Added multifile (folder) send
# Added Server "Delete" file command
# Added Server "Space" command
# Server mode: Stop Alerts are not displayed (e.g. User cancelled transaction
stopped server operation)
# Get whole folder content from the server with filename ":"
# Menu command keys added to menus
# Support of menu command keys
# Menu command key and FKEY flag now saved with settings
# Accept end of transmission with keydown (not only mousedown)
# Added terminal settings dialog
# Added non-transparent terminal mode
# Added smooth scrolling option to terminal emulation
# Added underline cursor option to terminal emulation
# Added display of protocol version to "About Kermit" dialog.
# Fixed a bug in ckmtio which caused problems with the parity bit when
receiving form an IBM host for example.
# Added a simple Take file interpreter
# Added session logging
# Added transaction logging
# Added a completly new keyboard management (CKMKEY is no longer necessary)
# "Keep" flag settable by user
# statistics in about dialog
# rewrote parts of the window handling routines: windows are now
highlighted according to the userinterface guidelines
Thanks to the good code generation of the MPW C compiler just porting the
source saved about 20 kBytes of binary code. Rewriting parts of the source
saved some more kBytes. This results in a new version with all the new
features added but about 6 kByte smaller than version 0.8(35).
I hope you will like the new version which I think could be called 0.9(36).
Please tell me where and how to send the source code (preferably a BITNET
address). Today I read about Paul Placeway of Ohio State University who seems
to be working on a new version too. Unfortunately I don't have an address to
contact him directly. So I leave it up to you, how to handle the integration
of the sources. Unfortunately I will not be able to continue the work on
MacKermit at the moment, because the company who payed for the three weeks of
development wants me to do some work which pays for them too. Nevertheless I
will try to write a documentation for the new version. I will keep you
informed about this.
Matthias Aebi
PS: Please do not try to reply via the source address of this message. I
normally do not have access to this account. Use one of the two adresses below
instead:
BITNET: K116430@CZHRZU1A
USENET: ...!mcvax!cernvax!unizh!aebi
[Ed. - Many thanks, Matthias! It should be noted that this contribution came
out of the blue, and it may or may not be reconciled with other work in
progress. Thus, it may become the "mainline" Mac Kermit, it may become a dead
end, or it may be integrated with the work of some other people. But if it
works as advertised, it should be a definite improvement on the current
versions, so please take it and try it out. Reports and reviews are most
welcome. Does it work on all Macs? All but the original 128K Mac? Support
old and new keyboards, file systems, etc? Meanwhile, we're making an attempt
at getting Matthias's sources to other Mac Kermit developers in hopes of
combining the best of all versions.]
------------------------------
Date: Thu, 29 Oct 87 17:07:50 PST
From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
Subject: Initial Impressions of Mac Kermit 0.9(36)
Keywords: MacKermit
I've spent the last half-hour playing around with Kermit 0.9(36) on a Mac
Plus running System 3.2, connected via a 9600 baud hardwired line to a TIP
which opens TELNET connections to various local hosts in-house. I tested
0.9(36) against 4E(067) running on a Vax 8650 under Ultrix 1.2.
Notes from my fiddle-about:
1) I was able to puzzle out the method for remapping some of the keys
on the Mac Plus keyboard to do what I wanted. The big clue was that
one persuades Kermit to send a control character by using the
sequence "\nn", where "nn" is the decimal representation of the
ASCII character desired. Unfortunately, it's difficult to confirm
the setting of a key that has been mapped in this fashion; when you
hit the same key to check the setting, you typically see a small
empty box (the standard "Unassigned font code" character in the Mac
font structure). It'd be nicer if Kermit reconverted unprintable
characters to the \nn notation before displaying them.
2) I wasn't able to figure out how remap a key so that it would send a
Break. This was possible under 0.8(34) and (35) using a _very_
obscure function mapping; I haven't discovered the equivalent under
0.9(36).
3) The send and receive packet-sizes, and perhaps some of the other
protocol-related information, isn't being restored properly when you
load a settings file; the packet size returns to the default of
90. Some of the protocol information (block-check type, for
example) is being saved and restored properly, though.
4) The screen image is not restored properly after a dialog box is
erased (e.g. after a download, or after changing the settings). The
problem appears to be most acute if the screen was trying to scroll
during the erase-and-refresh process; I suspect that the scroller
and the screen-refresher are stepping on each other's feet.
5) The ability to receive 900-byte packets makes an _amazing_ different
in the speed of a download in my 9600-baud TELNET environment.
6) If you save a settings file "on top of" an existing settings file
of the same name, 0.9(36) does not copy the old version's
window-placement information when it creates the new version.
This is most noticable if the old version had been moved onto the
Mac desktop; the new version is not visible on the desktop, but is
instead found in the disk's (or folder's) window. 0.8(34) did this
correctly, by copying the old version's window/position information.
7) I like the smooth scrolling, and the ability to use a thin-underline
cursor rather than an eye-searing blinking-block.
Conclusion: not at all bad for a beta version; it'll really be nice
when the current set of glitches are tracked down and persuaded to
move to Tumbolia.
Here are the results for the Mac II:
1) I had noticed that some of the field labels in the protocol-setup
box were either misplaced, or only partially present, when I ran
0.9(36) on a Mac Plus under System 3.2. These fields all appear to
be OK when the same version of Kermit is run under System 4.1 on
my Mac II. I'm not sure whether the difference is in the System
itself, or in the fonts.
2) The scrolling/refresh conflict I noticed on 3.2/Plus is also present
in the 4.1/Mac II environment.
3) I reported that some of the protocol-configuration information wasn't
being saved and restored in the settings files. I found last night
that the "send packet-length" information is saved and restored OK,
but that the "receive packet-length" always reverts to 90.
4) Smooth scrolling on a Mac II in 8-bit-pixel mode is incredibly slow
(much slower than smooth scrolling on a Plus).
5) Over a 1200-byte dialup line to a Tip which was telnet'ed into a
Sun 3/110 running SunOS 3.4, 800-byte packets worked just fine for
both "send file" and "receive file".
------------------------------
Date: Mon, 26 Oct 87 09:21:11 PST
From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
Subject: Use of Kermit by the Disabled
Keywords: Disabled, MacKermit
I might suggest that people with motor impairment might wish to consider
running CKMKER on a Macintosh, and make use of the new "Easy Access"
capabilities of the Macintosh operating system.
"Easy Access" is a standard, free (bundled) utility which permits the use of
the Macintosh window environment with a single finger (or any similar
manipulating digit such as a mount-stick, forehead-mounted pointer, etc). It
includes several capabilities, including "sticky keys" (touching a modifier
key such as Shift or Option once will "press" it for the duration of the next
keystroke; touching the modifier twice will "lock" it until it is touched a
third time) and "Mouse keys" (permits the user to move the cursor around on
the screen by using the arrow keys on the keypad, and "click" the mouse button
by typing a single digit on the keypad).
Of course, "Easy access" doesn't solve any of the problems relating to
Braille output, voice output, etc.
------------------------------
Date: Fri, 23 Oct 87 10:05:59 EDT
From: pisces!wells@compass.UUCP (Ian Wells)
Subject: Easylink and C-Kermit
Keywords: C-Kermit, Easylink
I would like to use Kermit (C-Kermit) with scripts to upload and download
electronic mail to Easylink - Western Union's electronic mail system.
I am planning on using this from a Sun running Berkeley Unix and a Motorola
system in Europe using System V Unix. Who should I contact to find someone
who might have written such a script?
(-: IanWells COMPASS Wakefield MA USA think!compass!wells +617 245 9540 :-)
------------------------------
Date: 13 Oct 87 13:40
From: BRADLEJP@SNYPLABA
Subject: How to Get C-Kermit for Data General AOS/VS?
Keywords: Data General Kermit, AOS/VS Kermit, C-Kermit
It appears that there is a beta version of Kermit in C for AOS/VS. I have a
directory of the files on KERMSRV, and believe that the necessary files have
XKD as the first three letters. Is this correct?
Assuming that your response is yes, we would like to receive these files via
BITNET, but have some questions about the KERMSRV commands. We will be making
the request from a Burroughs A-10 mainframe (not having a BITNET
implementation for our DG machine). Are the files ASCII text files, or are
some of them binary? We understand that the files are in "V-format," but are
not sure what this means (no experience with the IBM world). Could you please
tell me what the physical layout of the files is, and what KERMSRV command
would be best to use to request them?
Thank you very much
[Ed. - The files are all ASCII text. The binaries are encoded printably,
and a decoder is included among the XKD*.* files. The ones you need are
XKC* *, XKU* *, XKW* *, and XKD* *. Tell KERMSRV at CUVMA to send you each
of these groups. Once you get them, you have to rename XK*.* to CK*.* if
you want to compile from source.]
------------------------------
Date: Fri, 16 Oct 87 21:31:24 CDT
From: Phil Howard <PHIL@UIUCVMD>
Subject: Amiga Kermit
Keywords: C-kermit, Amiga Kermit, VM/CMS Kermit
I have obtained all the files identified in the file CKIAAA.HLP from the
BITNET Kermit server. I FTP'd these to a UNIX system and then downloaded them
to my Amiga using an older version of Kermit that was already on a disk
someone gave me. My C compiler has not arrvied yet so I can't compile the
source but I did go ahead and run the basic program (CKIBOO.BAS) to convert
the boot file (CKIKER.BOO) into what I thought should be a runnable file. The
file did not run and AmigaDOS said it was not a runnable object program. It
had almost the same size as the older one, and the beginning stream of
characters was similar as best as I could it by typing them on the screen.
1. Is that the proper procedure, to convert the boot file into a runnable
object program?
2. Does anyone who is on a VM/CMS system on BITNET have an already converted
runnable object program that they know work (cause they ran it) that
they can send me? I would prefer it be sent from a VM/CMS to a VM/CMS
system to be sure it does not undergo brain damage from ASCII/EBCDIC
conversion gremlins; remember it's a binary.
[Ed. - The problem is probably ASCII/EBCDIC gremlins as you surmise. No one
else has complained so far, but then we have no way of knowing if anyone
else has tried this yet! Can anybody help?]
------------------------------
Date: 19 Oct 87 10:49:00 EDT
From: "ETD1::LABOVITZ" <labovitz%etd1.decnet@afwal-aaa.arpa>
Subject: VMS 4.6 Bug Report with C-Kermit 4E(067)
Keywords: VAX/VMS Kermit, C-Kermit
I have just compiled the source modules for C-Kermit 4E(067) under VAX/VMS 4.6
on our VAX 11/785, using the supplied XMVKER.COM file. During the final
link of the KERMIT executable, the following warning message is produced
by the linker:
%LINK-W-MULDEF, symbol SYSTEM multiply defined
in module C$UNIX file SYS$COMMON:[SYSLIB]VAXCRTL.OLB;1
While I have not had a chance to confirm this with our DEC Software Analyst
(he's on vacation until next week), this seems to be directly attributable
to the new VMS 4.6 C Run Time Library.
Other than producing a warning message, however, our new version of KERMIT
seems to be running well thus far. If any other problems arise, I will forward
them to Info-Kermit, otherwise it will soon replace our current version
of KERMIT-32.
LT Stuart Labovitz
arpa: LabovitzSL@Afwal-aaa.ARPA
arpa: Labovitz%Etd1.DECNET@Afwal-aaa.ARPA
[Ed. - Thanks for the report. It's been forwarded to the new C-Kermit/VMS
developer and added to the XKVKER.BWR file. Since compilation and linking
were tested with VAX-11 C 2.3 on VMS 4.6, and this problem didn't arise,
the culprit is indeed most likely the runtime system.]
------------------------------
Date: 21 Oct 87 20:57 -0600
From: Grant Delaney <delaney%wnre.aecl.cdn%ubc.csnet@RELAY.CS.NET>
Subject: Mapping Kermit65's Vt100 emulation to GS & //e Keypad
Keywords: Apple II Kermit, Kermit-65
For version (3.79): The attached patch when executed will Apple Kermit's Vt100
function keys into the Keypad. You will still have to use Open-Apple with the
keypad keys. This should also work with Apples numeric keypad
Key Pad VT100 Function Keys
___________________________________________________________________
| | | | | | |FNDNXT | Dellin |
| clear | = | / | * | Gold | Help | Find | Undlin |Gold
|--------------------------------|----------------------------------|
| 7 | 8 | 9 | + | Page |section|append | DLword |
| | | | | command | Fill |Replace|Undlword|Gold
|--------------------------------|----------------------------------|
| 4 | 5 | 6 | - | Advance | Backup| Cut | DelChar|
| | | | | Bottom | top | paste |undlchar|Gold
|--------------------------------|----------------------------------|
| | | | | word | EOL | Char | |
| 1 | 2 | 3 | | ChngCas | DelEol|SpecIn | Enter |Gold
|------------------------| enter |-------------------------| |
| | | | BLine |Select |SubStit |
| 0 | . | | OpenLine | Reset | |Gold
_________________|_______|_______|___________________________________
========================== cut here ==========================
BLOAD KERMIT379
CALL -151
6AFB:2E 18 3D 2F 2A
6B00:37 38 39 2B 34 35 36 2D 31 32 37 38 39 2B 34 35
6B10:36 2D 31 32 33 0D 30
BSAVE KERMIT379.GS,A$1000,L$6900
[Ed. - Thanks, your message has been added to the APPKER.BWR file.]
------------------------------
Date: Tue, 13 Oct 87 09:59:53 EDT
From: Claude Goldman <CLAUDE@BROWNVM>
Subject: MS-Kermit and IBM Mainframes
Keywords: MS-DOS Kermit, Protocol Converters, IBM Mainframe
I have several questions/suggestions about using kermit on an IBM PC
to connect to IBM mainframes via a 7171's.
1 - Is it possible to indicate the status of the VT102 status lights
in some way? In particular it can be very frustating not knowing
when you are or are not in insert mode.
[Ed. - The four VT102 LEDs are shown in the Kermit mode line. But they
don't necessarily reflect whether the terminal is in insert mode, only
that the host sent the sequences to turn the lights on or off.]
2 - When emulating a 3270 type terminal it would be very handy to be
able to assign different colors to different field attributes, i.e.
protected/unprotected high/low, foreground/background (now possible),
etc. This would be handy for full screen programs in Rexx, Xedit,
Focus, etc.
3 - I could not do ascii file transfers when parity was set to none.
Any ideas why?
[Ed. - Because the 7171 and IBM mainframe use parity. If you don't tell
MS-Kermit about this, checksums will appear to be wrong.]
------------------------------
Date: Sat, 17 Oct 87 12:24 GMT
From: <KERMIT@CZHETH5A.BITNET>
Subject: RSTS V7.0 Kermit Wanted
Keywords: PDP-11 Kermit, RSTS Kermit
I am here with Hansruedi and we are looking for a way to connect a PDP-11/34
running under RSTS V7.0 to a 11/73 under RSTS V9.3. For internal reasons we
would like to keep V7.0 on the old machine and therefore we are looking a
RSTS-Kermit for V7.0. We asked Brian already for that problem, and he says he
is not sure whether he still has such an old backup binary version of
RSTS-Kermit, because compiling the old source on his new 9.5 RSTS will not
necessarily garantee to run on our old machine. Therefore, would you know of an
existing RSTS V7.0 runnable Kermit ( HLP- and EXEC-files) or would it possible
that you deposit an "Wanted" call into the KERMIT-infobox. Hoping to find in
our account some morning such a nice RSTS V7.0 version of KERMIT. Thanking you
in advance, we remain with best regards also from Hansruedi
otto.
------------------------------
Date: 14 Oct 87 21:36:54 EDT
From: FFO04688@UDACSVM
Subject: More on C64 Kermit V2.0
Keywords: Commodore 64 Kermit
I have had some success with the new version of Kermit. It seems to do a
pretty good job of supporting the VT100 protocol. A couple of things that I
noticed:
1. Boot file dosen't work properly. I have to load the main file and
run it.
2. Delete key on keyboard is mapped as Rubout (very annoying) You
have to press the F7 key for backspace. This can be dealt with
(at least on UDEL vaxes) by issuing an 'stty dec' command to the
c-shell. This could probably be fixed via a custom termcap entry
(or more drastically) changing the program's translation table.
Note: This could be a problem with our VT100 termcap, but I
doubt it as I have never had a problem with any other
VT-100 emulators.
3. Send command dosen't seem to work properly with C-kermit's receive,
I have to put the host into server mode and issue commands to the
server to transfer files properly.
I'm interested in hearing about anyone else's experiences with the package.
Rob Elkins
ARPA: relkins%trillian@udel-relay
------------------------------
Date: Wed, 21 Oct 87 22:20:18 EDT
From: cbmvax!vu-vlsi!devon!paul@RUTGERS.EDU (Paul Sutcliffe Jr.)
Subject: Diffs for C-Kermit 4D(061) and Tandy 6000
Keywords: C-Kermit 4D(061), Tandy Kermit
In Info-Kermit Digest V6 #23, I said I'd send the diffs along to compile
C-Kermit on a Tandy 6000. Here they are. Note that they assume that one is
running Tandy Xenix 3.0 or greater.
Install these diffs in the "stock" 4D(061) C-Kermit distribution, and then
type "make trs16" to compile. In reality, you only need to make the
modification to the makefile (ckuker.mak); the other diffs just make the
startup banner agree with the operating system version -- I didn't like
kermit saying "Xenix/286" on my 68000!
- paul
[Ed. - Thanks! Just the makefile entry is reproduced below. The full diffs
have been added to KER:XKUKER.BWR.]
#Tandy 16/6000 with Xenix 3.0
trs16:
make wermit "CFLAGS= -DTRS16 -DXENIX -DUXIII -DDEBUG -DTLOG \
-DM_VOID -Dvoid=int -F 3000 -n" \
"LNKFLAGS = -F 3000 -n"
------------------------------
Date: 24 OCT 1987 20:36 EDT
To: <INFO-KERMIT@CU20B.COLUMBIA.EDU>
From: Steve Roseman <LUSGR%LEHICDC1.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Long Packets in CD3KERM
Keywords: CDC Kermit, Long Packets
My feelings are crushed! In V6 #24, you didn't mention that long packet
support has been in CDC Cyber Kermit V3 (CD3KER) since March. The guy 'Ed.'
who makes comments on each letter to Info-Kermit forgot about us. Just
because Cybers aren't as popular as VAXes, IBMs, and PCs.....
Steve Roseman
Lehigh University
[Ed. - Oops, sorry! Cybers might not be as popular as IBM PCs, but one
Cyber costs about as much as about 1000 of them...]
------------------------------
Date: Mon, 26 Oct 87 12:13:49 PST
Subject: Long Packet Support in Apple Kermit
From: Mick Laver (ACC Microconsulting) <zz1ml%sdcc3@sdcsvax.ucsd.edu>
Re: Your response to John Gartley about long packet support (KD 6:24).
The Apple II Kermit (ver 3.79) also supports packets up to 250 characters.
Use SET RECEIVE (OR SEND) PACKET FA (or less). It works well with C-Kermit
4E(067).
Mick Laver, C-010 Internet: laver@sdcsvax.ucsd.edu
UCSD Academic Computing Center UUCP: ...!sdcsvax!sdcc3!zz1ml
La Jolla, CA.92093 BITNET: laver@ucsd.BITNET
[Ed. - Oops again. This all comes from not having a comprehensive database
of what Kermit versions have which features. Someday... For that matter,
add the new Mac Kermit 0.9 to the list.]
------------------------------
Date: Fri 30 Oct 87 16:48:53-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Tektronix Excerciser Needed
Keywords: VAX/VMS, Tektronix Emulation
Does anybody have a VAX/VMS program that will put a Tektronix 4010 emulator
through its paces? If you're willing to contribute to development and testing
of a new Kermit release, please send your program to me by electronic mail
(if it's not too huge) in hex format (as produced by the VMSHEX program that's
supplied with VMS Kermit). Thanks!
Frank da Cruz
SY.FDC@CU20B.COLUMBIA.EDU (Internet)
FDCCU@CUVMA (BITNET)
------------------------------
End of Info-Kermit Digest
*************************
-------
11-Dec-87 17:10:26-EST,29573;000000000000
Mail-From: SY.CHRISTINE created at 11-Dec-87 17:09:25
Date: Fri 11 Dec 87 17:09:25-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #26
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12357710174.26.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Fri, 11 Dec 1987 Volume 6 : Number 26
Departments:
ANNOUNCEMENTS -
Japan DECUS, November 1987
New Release of DEC-20 Kermit
Latest Test Release of RMX86 & RMX286 Kermits
OS-9 Kermit Available for Eltec Eurocom-3
KERMIT File Protocol on COMPUSERVE
Finally Kermit on Compuserve
FTPing Files From Columbia
Kermit Network File Organization
UNIX KERMIT -
RE: VMS 4.6 Bug Report with C-Kermit 4E(067)
Re: Amiga Kermit
C-Kermit on Apollo
C-Kermit on Minix?
Macintosh KERMIT -
MacKermit with multilingual 7171
[Andre PIRARD: MacKermit with multilingual 7171]
Mac Kermit 0.8(35) on the Mac II
MacKermit 0.9(36) Initial Impressions
MacKermit 0.9(36) B3 Testing
Macs, Versaterm and Kermit Errors
MISCELLANY -
IRMX86 Kermit -- I've found it!
----------------------------------------------------------------------
Date: Thu 10 Dec 87 09:40:03-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Japan DECUS, November 1987
Keywords: Japan DECUS, DECUS
Sorry for the long delay since the last Info-Kermit digest. The week of
November 16, we were in Japan at the invitation of Japan DECUS to make
presentations at the 1987 Japan DECUS Symposium and at NTT, which was quite
an experience.
The DECUS presentations were accompanied by simultaneous translation into
Japanese, for which the attendees, usually about 80-100 per session, wore
special headsets, like at the UN.
Our first presentation was "Kermit, Current Status, Future Directions," in
which 30-minutes were devoted to Kermit history, philosophy, the mechanics
of Kermit development and distribution, and an overview of some of the new
and forthcoming Kermit releases; a brief technical talk was given on the
Kermit protocol performance enhancements (data compression, long packets,
sliding windows); and Ken-Ichiro Murakami of NTT, Japan's "Kermit-san",
spent some time speeking about special considerations for use of Kermit in
Japan -- versions for Japanese computers, use of and conversion among the
various Japanese character sets, Japanese translations of the Kermit
manuals, etc. (Some of this session got written up in Nov 30 Digital News,
Page 10.)
A 3-hour "Fast-Paced Kermit" course was also conducted for about 40
students, consisting of 2 hours lecture and an hour of practice (using PCs
and a MicroVAX running VMS), with Japanese translation.
We were charmed by the hospitality and generosity of our hosts, and we were
pleasantly surprised at the high level of knowledge of, interest in, and
support for Kermit in Japan.
- Chris & Frank
------------------------------
Date: Fri 11 Dec 87 15:34:19-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: New Release of DEC-20 Kermit
Keywords: DEC-20 Kermit
I never thought I'd touch this program again, but it contained a thoughtless
restriction, namely that it wouldn't let you issue commands to servers unless
you were in local mode (e.g. after dialing out through another line). This
prevented you from putting a bunch of commands (multiple SENDs and/or GETs,
followed by FINISH) into a TAKE file, TAKing the file, escaping back to the PC
and putting it in server mode. The new release, 4.2(260), removes this
restriction so long as the commands (like GET, FINISH, BYE) are issued from
TAKE files. The old problem of inferior process capabilities not getting set
right, e.g. after a PUSH command, is also fixed. The new version is in
KER:K20MIT.MAC on CU20B. - Frank
------------------------------
Date: Tue, 01 Dec 87 10:52:47 PST
From: JAFW801%CALSTATE.BITNET@CUVMA.COLUMBIA.EDU (Jack Bryans)
Subject: Latest Test Release of RMX86 & RMX286 Kermits
Keywords: RMX Kermit
The latest version mostly brings the RMX Kermits up to date with more recent
MS-Kermit sources. The documentation (MSTRMX.DOC) has been edited to clarify
issues reported by users and to include information on obtaining Terminal
Support Code fixes from Intel for the ^W problem.
[Ed. - Thanks Jack! The new files have replaced the old ones in
KER:MSTRMX.BOO, KER:MSTRX2.BOO, and KER:MSTRMX.DOC.]
------------------------------
Date: Mon 2 Nov 87 18:37:00-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: OS-9 Kermit Available for Eltec Eurocom-3
Keywords: OS-9 Kermit, Eltec Eurocom-3
I got the following letter.... 21 October 1987
"I appreciate very much the idea of Kermit and I'm a happy user of OS-9
Kermit, VAX-Kermit-32, and the Kermit facility of Smarterm (MS-DOS).
Therefore I like to offer my knowledge and services to other people:
OS-9/68000 Kermit Implementation for ELTEC EUROCOM-3
Media: 5.25" DSDD 96tpi standard OS-9 diskette (others on request)
comprising source, executable object, user manual (including hints
for use of /t1) and actual info about Kermit and other implementations.
Order by prepayment of sFr. 30.- to post-office account 60-52873-4 or
with accompanying check or by charging to account (sFr. 50.-) from
Beat Brunner, Hinterherdschwand 30, 6020 Emmenbruecke, Switzerland.
Thanks for your services.
Sincerely yours,
Beat" (No network address)
------------------------------
Date: Thu, 19 Nov 87 22:39:45 EST
From: "Joseph A. Bruno" <B562JB4G@VB.CC.CMU.EDU>
Subject: KERMIT File Protocol on COMPUSERVE
Keywords: CompuServe Kermit
When I logged onto COMPUSERVE today, the "what's new" messages informed me
that the KERMIT file transfer protocol is now supported. I tried to
download a small file and it worked OK form me. I am using KERMIT-11 on a
PDP-11 with the TSX+ operating system. I think you should let other users
know about this through the news letter and ask for feedback when others try
it with different versions of KERMIT especially if they have problems.
------------------------------
Date: Sat 14 Nov 87 10:02:24-PST
From: Bob Larson <BLARSON@ECLA.USC.EDU>
Subject: Finally Kermit on Compuserve
Keywords: Compuserve Kermit
(Compuserve is probably the largest commercial bbs.)
Compuserve is now beta testing their implemintation of the kermit protocol
in the os9 sig. (Presumably it is in their other sigs that do beta tests as
well.)
My understanding is it is a rather limited version that can only do single
file sends and receives. Nobody has yet said if it supports full duplex
windows, long packets, or other optional features of kermit and I havn't yet
tested it. (Compuserve charges extra for bad service, so it may be in no
rush...)
------------------------------
Date: Sun, 15 Nov 87 07:27:28 EST
From: eric@EDDIE.MIT.EDU (Eric Van Tassell)
Subject: FTPing Files From Columbia
Keywords: FTP
Hi,
Are you trying to discourage ftp's? I have been trying for a month
to get VMS kermit to MIT and continually been amazed at the abyssimally low
transfer rates. What's up?
eric@eddie.mit.edu
[Ed. - Apparently many people have been having problems FTPing files from
Columbia's computers. Someone is checking on the problem. Sorry for an
inconvenience.]
------------------------------
Date: Sun 8 Nov 87 02:22:45-PST
From: Jim Lewinson <a.Jiml@GSB-WHY.Stanford.EDU>
Subject: Kermit Network File Organization
Keywords: Kermit Files
I am a little confused about the organization of the Kermit directories
on CU20B these days.
As far as I can see, there are two sets of directories, <KERMIT-n> n=2,3,4,5
which I assume are used for creating tapes, and
<KERMIT-EXTRA>, <KERMIT-BINARIES>, <KERMIT-TOOLS> (?) which I don't know what
they do any more.
Which of these sets of directories are still being maintained? Which ones
are accessed when someone asks for a file by saying KER:file.ext to FTP?
If both are being maintained, would it be possible to get a AAFILx.DIR file
for each of them. There currently seems to be an AAFILB.DIR file in
both <KERMIT-2> and <KERMIT-BINARIES>, but they are of drastically different
sizes. (However, both seem to be recent.)
Sorry to be a bother about this, but I am trying to make sure that our local
set of directories are up to date so that people at Stanford can pull out
of them instead of putting any more load on CU20B.
Jim
[Ed. - Apparently, this has been confusing for other users as well. All the
Kermit files can be found by using the logical name KER:, which will direct
the user to either KERMIT, KERMIT-2 ..... etc. We'll try to make an effort
to keep AAFILx.DIR files in all these directories.]
------------------------------
Date: Tue, 10 Nov 87 14:44 CST
From: <MCGUIRE%GRIN2.BITNET@CUVMA.COLUMBIA.EDU>
Subject: RE: VMS 4.6 Bug Report with C-Kermit 4E(067)
Keywords: C-Kermit, VMS Kermit
> Date: 19 Oct 87 10:49:00 EDT
> From: "ETD1::LABOVITZ" <labovitz%etd1.decnet@afwal-aaa.arpa>
> Subject: VMS 4.6 Bug Report with C-Kermit 4E(067)
>
> I have just compiled the source modules for C-Kermit 4E(067) under VAX/VMS
> 4.6 on our VAX 11/785, using the supplied XMVKER.COM file. During the
> final link of the KERMIT executable, the following warning message is
> produced by the linker:
>
> %LINK-W-MULDEF, symbol SYSTEM multiply defined
> in module C$UNIX file SYS$COMMON:[SYSLIB]VAXCRTL.OLB;1
>
> While I have not had a chance to confirm this with our DEC Software Analyst
> (he's on vacation until next week), this seems to be directly attributable
> to the new VMS 4.6 C Run Time Library.
>
> [Ed. - Thanks for the report. It's been forwarded to the new C-Kermit/VMS
> developer and added to the XKVKER.BWR file. Since compilation and linking
> were tested with VAX-11 C 2.3 on VMS 4.6, and this problem didn't arise,
> the culprit is indeed most likely the runtime system.]
Was C-Kermit/VMS really tested under VMS V4.6? Before VMS V4.6, there was
no `system' function in the VAX C runtime library. Starting with VMS V4.6,
Digital provides a `system' function. The error message basically
indicates that the linker was provided with two routines named `system'.
It sounds like the developer of C-Kermit/VMS implemented `system' in the
code, and that it now conflicts with the new V4.6 standard `system'.
It should be straightforward for VMS V4.6 users to remove the definition
of `system' from the C-Kermit/VMS code and recompile/relink. Perhaps the
developer can find some nifty way to define `system' conditionally
depending upon which VMS version is being used.
Ed
------------------------------
Date: Wed, 11 Nov 1987 14:27:29 EST
From: John Owens <OWENSJ%VTVM1.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: Amiga Kermit
Keywords: C-Kermit, AMiga Kermit
>I have obtained all the files identified in the file CKIAAA.HLP from the
>BITNET Kermit server. I FTP'd these to a UNIX system and then downloaded them
>
> they can send me? I would prefer it be sent from a VM/CMS to a VM/CMS
> system to be sure it does not undergo brain damage from ASCII/EBCDIC
> conversion gremlins; remember it's a binary.
>
>[Ed. - The problem is probably ASCII/EBCDIC gremlins as you surmise. No one
>else has complained so far, but then we have no way of knowing if anyone
>else has tried this yet! Can anybody help?]
Typically, the ASCII/EBCDIC translation tables used by Kermit and FTP on your
VM/CMS system should match those used by your protocol converters, and, if
your system people are reasonably diligent, they probably do. The problem
comes when you have an EBCDIC file that was originally ASCII and was converted
to EBCDIC using a different table. The way I got around this problem for
Kermit BOO files was to use VM/CMS Kermit with no local translation table,
since its table matches that used at Columbia. Our installation had
a SYSTEM KERMINI that changed the translation table, so I just created
a SYSTEM KERMINI A with one line: ECHO NULL KERMINI
then transferred the file with kermit. If you must use FTP, you're
out of luck as far as I know, unless you want to give the UNIX dd
translation tables a shot: use BINARY FTP mode, then say, on the UNIX
system, "dd if=ebcdic-file of=ascii-file conv=ascii". Good luck!
-John Owens
Virginia Tech Communications Network Services
OWENSJ@VTVM1.BITNET owens@vtopus.cs.vt.edu
+1 703 961 7827 john@xanth.UUCP
------------------------------
Date: Tue, 3 Nov 87 23:59:40 est
From: seung%husc8@harvard.harvard.edu (Seung)
Subject: C-Kermit on Apollo
Keywords: C-Kermit, Apollo Kermit
Has anyone tried running C-Kermit on an Apollo DOMAIN/IX system? The
sources build OK when I type "make bsd" but Kermit gives various error
messages when I try to run it. The most common ones are "Warning, problem
getting exclusive access," and "Warning, problem relinquishing exclusive
access." I am working on an Apollo DN3000 running 4.2 BSD DOMAIN/IX SR9.6.
The version of C-Kermit is 4D(061).
Sebastian Seung
[Ed. - The problems you're seeing have to do with the UUCP lock files.
Since you're probably running a single-user system, you don't have to worry
about these anyway. The messages are harmless.]
------------------------------
Date: Mon 9 Nov 87 10:35:12-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: C-Kermit on Minix?
Keywords: C-Kermit
Has anyone tried C-Kermit (preferably version 4E(067)) on Andy Tanenbaum's
Minix (Unix v7) OS for the PC?
------------------------------
Date: Fri, 6 Nov 1987 12:38:30 ULG
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: MacKermit with multilingual 7171
Keywords: MacKermit, 7171, EBCDIC
This message describes problems to adapt MacKermit screen and keyboard
drivers, especially to international requirements in terminal mode. I have
read that a revision of the keyboard handling is planned. So, it must be the
right time to contact the right person about this. Could you please forward
this message to him/them? I am of course willing to discuss the problem and
carry out related tests needing a national keyboard.
We have settled our mind here (Belgium) to use Kermit micro to CMS mainframes
communication and file transfer. This is done mainly through 7171's.
The new scheme I have worked out with John Chandler and the IBM-Kermit group
now allows to perform correct ASCII-EBCDIC conversion of the ISO multilingual
character set during files transfer.
In terminal mode, there is no way to have the 7171 use 8-bit data. I however
used a trick to support a limited set of the ISO covering our own nationals.
This works by having the micro send special escaped sequences for these codes.
The 7171 parses these sequences and works out the correct character. On
return however, the 7171 cannot be instructed to send escape sequences, so I
used the control codes that were not used to another purpose. This is why the
terminal mode set is limited.
This requires some logic on the micro side. I have implemented it in our
traditional ftp, now converted to the Kermit protocol.
But here is the problem. Mac people use Mac Kermit (I neither feel able nor
eager to program the Mac, and MacKermit is fine the way it is). But they're
crying out for their national characters in terminal mode. The following two
facts prevent me to implement the above scheme:
- Escape characters received by the Mac terminal mode do not display at all.
Is this the result of its own ANSI driver or an incomplete font?
Some control over the display of the *complete* set of non-action characters
is needed. Possibly by simply specifying a specially tailored font?
Can this be done now?
- MacKermit keyboard driver is wonderful at building the required escaped
sequences with appropriate setup. But using our national characters
requires that some of them be composed by a succession of a dead key
(bearing an accent) followed by the underlying letter. This composition is
normally done by the appropriate (localized) keyboard interface layer wich
I understand is bypassed by MacKermit.
Using the standard keyboard interface (and still allow for codes conversion
and escaping) would be simpler in terms of keyboard independence, but would
restrict the keys combinations to those effectively used by the interface.
I do not have enough insight of the Mac to propose a solution to this
point, but I feel it should sound reasonable to suggest a compromise such as:
Is is possible to have the MacKermit keyboard driver normally receive the
keyboard codes through the full interface and however steal selected
keystrokes at the hardware level when instructed to do so by the setup
tables, with conversion possible at both levels?
Or is there even a simpler solution?
This would not only solve the problem, but also make the keyboard setup
a much more simpler task (every new Mac I saw needed an adjustment).
I hope to help finding minor modifications that could enhance MacKermit.
I understand that not being able to carry on tests on unavailable hardware
is a problem. This is why I will be glad to help towards this.
Andre.
[Ed. - See message below.]
------------------------------
Date: Fri, 6 Nov 87 17:41:31 EST
From: paul@ohio-state.arpa (Paul W. Placeway)
Subject: [Andre PIRARD: MacKermit with multilingual 7171]
Keywords: MacKermit
At first glance, this looks like quite a problem. According to what I have
read about the new Apple keyboard mapping standards, It shouldn't be a problem
to define any key to produce any sequence (of up to 255 chars, I believe)
8-bit sequence, or use any key as a deadkey for a following one (<Option-e o>
for example). The other advantage is that it allows an abstraction away from
the hardware level, so that the same map will do the "right things" for a Mac
512 keyboard, and also recognize and deal with the control key on the IIgs and
the "USS Serritoga" keyboards.
One of my goals for the display code is to be able to display an 8 bit wide
character set, so that people who don't happen to speak only American English
(the majority, of course) can have extended character sets. Fortunately,
Apple is very aware of the "language barrier", and has a system designed to
deal with it.
In other words, it isn't a problem, and I will keep this in mind when working
on the Mac stuff.
-- Paul W. Placeway Dept. of Computer & Info. Science
(now) paul@ohio-state.arpa 2036 Neil Avenue Mall
(soon) paul@tut.cis.ohio-state.edu Columbus, OH 43210-1277
(in a pinch) ...!cbosgd!osu-cis!tut!paul (614) 292-0915
------------------------------
Date: Mon, 9 Nov 1987 17:12:01 ULG
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Mac Kermit 0.8(35) on the Mac II
Keywords: MacKermit
I have downloaded MacKermit 0.8(35) on a Mac II (and adjusted the keyboard
table using 0.8(6) on an SE). It performs great for what I have tried
(terminal mode and file transfer with VM CMS).
But I happened to QUIT it and enter MacWrite while my CMS session was still
active. After a while, the system bombed in my back, while completely idle.
Suspecting comm line interrupts, I restarted the system and Kermit. A message
appeared on the refreshed screen indeed. I quit again and sent my session yet
a message. The system bombed again after some mouse clicks. This happened
several times with varying interval between message and the time the crash
occurs. Everything looks like the line interrupts are kept enabled to nowhere
code. This happened with System 4.1 (french) and Finder 5.5 on an SE or
Multifinder 6.0B2 ona a II. I could not reproduce it with 0.8(34) (on the SE
of course).
------------------------------
Date: Mon, 9 Nov 87 22:26:33 CST
From: brian@sally.utexas.edu (Brian H. Powell)
Subject: MacKermit 0.9(36) Initial Impressions
Keywords: MacKermit
Regarding:
>Date: Thu, 29 Oct 87 17:07:50 PST
>From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
>Subject: Initial Impressions of Mac Kermit 0.9(36)
>2) I wasn't able to figure out how remap a key so that it would send a
> Break.
Enter \bs (short break) or \bl (long break). This is explained if you
click "help" in the "Set key macros..." dialog.
>4) The screen image is not restored properly after a dialog box is
> erased (e.g. after a download, or after changing the settings).
I find this to be a pretty common happening, and it needs to be fixed
soon.
I don't know if you're really soliciting BeWaRes or not for this version
of MacKermit, but here are some, all regarding MacKermit 0.9(36).
Other problems I have found:
* I'm unable to set command-spacebar to NUL. It keeps wanting to set it to
"\177" when I try to set it to "\0".
* The meta-key option (for the option key) is not available. I want my
meta-key back, so I'll probably dump this version of kermit and go back to my
other terminal program (uw) and the old kermit. The old ckmkey could set
modifier keys to act as meta-keys. (I want a real meta-key, not just one
that prefixes with ESC.) Actually, if you fiddle around with "Set key
macros...", it's possible to set some meta-key combinations explicitly. I
haven't gotten it to behave rationally, yet, but there are possibilities
there. One also runs into the old problem of dead-keys. (e.g., you have to
press option-e twice to get it to register.) There are ways to work around
dead keys.
* In the "set modifiers" dialog, if I choose to make both control and clover
act as a control key, only the control key really acts like a control key.
clover-b, for instance, sends a 'b'. This forces me to "Set key macros..."
for each clover-key. (Which is how I found out that cmd-spacebar can't be
set to NUL (above).) I'm not sure if this is a bug in the code or a bug in
the dialog box for letting me choose both modifiers at the same time.
* (An oldy but a goody) I like it when the (mouse) cursor disappears when I
start typing. (Using ObscureCursor in QuickDraw.) I wish kermit did this.
* When "Menu Clover-keys active" is turned off, I'd like the clover-keys to
disappear from the menu. It's too confusing to an unready user to see those
cmd-equivalents listed in the menu but semantically disabled.
* In certain instances, things I type to the "Set key macros..." dialog get
sent to the host as well. This can be duplicated by choosing "Set key
macros..." and typing option-`. Click OK twice and type something (say 'f').
The host echoes `f.
I look forward to the real MacKermit.
Brian H. Powell
UUCP: ...!uunet!ut-sally!brian
ARPA: brian@sally.UTEXAS.EDU
_Work_ _Not Work_
Department of Computer Sciences P.O. Box 5899
Taylor Hall 2.124 Austin, TX 78763-5899
The University of Texas at Austin (512) 346-0835
Austin, TX 78712-1188
(512) 471-9536
------------------------------
Date: Tue 1 Dec 87 00:48:18-PST
From: Jim Lewinson <a.Jiml@GSB-WHY.Stanford.EDU>
Subject: MacKermit 0.9(36) B3 Testing
Keywords: MacKermit
I grabbed a copy of this from CU20B to try it out, and I still can't get the
Keyboard stuff to do what it used to do for me. The OPTION key used to
ONLY insert an ESCAPE in front of the keystroke, and make no other changes.
Pressed What I want What IS
Sent Sent
OPTION d ESC d ESC d
OPTION SHIFT D ESC D ESC D (Not too important)
OPTION SHIFT . ESC > ESC . (IMPORTANT)
I use the latter keystrokes all the time to get to the end of a file. I
suspect other people may use OPTION SHIFT 4 to get the EMACS spell checker.
(In fact, I might start using this, now that I think of it.) I suspect I
may also use OPTION SHIFT 3 for Query-Replace, but not often enough to
notice it.
If I had to give up a feature to get this, I would get rid of the concept
of Modified/Unmodified. Kermit is generally used to talk to other machines
in 7 bit ASCII. The ability to send a E with an accent grave on it sounds
really neat, but isn't very useful when you get down to it.
I wouldn't worry too much about trying to get the window postion of the new
settings file right. After all, you did write a new file, and this is
something that I do very very rarely. Usually, it is just to create a new
version for a different speed or something similar, so I usually create a
new file anyway.
I tried to use the long packets, but the Unix machine I was trying to use
only has a short packet Kermit on it. I thought I grabbed a new
long-packet one, but I guess I got the wrong one.
I did use 0.9(36) B2 to transfer B3 down, and it seemed to do a fine job,
except it transfered the files I told it to, not the ones I wanted. :-)
I guess a little more DWIM is needed in that department. (Or maybe a little
less DIMWitted behaviour on my part. :-) )
Jim
------------------------------
Date: Tue, 10 Nov 87 09:07 GMT
From: OBSchou@UK.AC.LOUGHBOROUGH.MULTICS 11-NOV-1987 11:11
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Macs, Versaterm and Kermit Errors
Keywords: MacKermit, Versaterm
We have been using both the "formal" Mac Kermit based on "C" kermit and a
terminal emulator/file transfer packaged called Versaterm at Loughborough with
mixed success.
We selected Versaterm as the suggested terminal emulator and file transfer
program over the distributed Mac Kermit for two reasons: terminal emulation was
far better, and could also "do" Tektronix emulation, and more importantly,
appeared to be more reliable in Kermit transfers than Mac Kermit.
However, we have had a rash of file transfer problems, resulting in truely
garbled data at the Mac end. (Early bits of the file keep appearing thoughout
the file, not all the file is available even though the transfer says it has
completed, etc.) Closer investigation showed an unusual bug in Multics
(Amaranth) Kermit. We FTP-ed the files to a VAX and again tried to transfer
the files to the Mac, with similar results. It therefore seems as if Versaterm
is not a good as it is made out to be.
Has anyone else used Versaterm and had problems, and better still come up with
som work-arounds?
In anticipation, Bertil Schou.
------------------------------
Date: Wed, 28 Oct 87 17:08:23 EST
From: dfs@nadc.arpa (N. Topping)
Subject: iRMX86 Kermit -- I've found it!
Keywords: RMX Kermit
About a month ago I made an appeal for information on Kermit for iRMX86.
Apparently there was some discussion, confusion and advice generated by this
request. I say "apparently" because I did not personally read any messages
since I do not subscribe to this mailing list. As a nonsubscriber, I asked
that responses be mailed directly to me (dfs@nadc). However I received only
one direct response from Jack Bryans (Thanks!) and he alluded to these
kermit-digest discussions.
I am posting this message to inform the Kermit community that I have finally
located a version of iRMX86 Kermit that works. I found the name of Larry Grim
of Mesh Inc. in the "aawait.hlp" file. I contacted Larry and he graciously
provided the Kermit source code (ASM86) and documentation. Larry's iRMX86
version of Kermit was developed for an Intel 86/310 sometime in 1985. He
developed this iRMX86 Kermit by converting the IBM PC DOS version of Kermit.
The conversion effort was sponsored by the Dupont Corporation.
Since Larry does not have network access to the Kermit repository, I promised
him that I would inform the Kermit community of his accomplishment and
volunteer to mail his Kermit source and documentation to the Kermit
repository. If the keepers of Kermit are interested in obtaining this version
of Kermit, please let me know (by direct response, please!) where to mail it.
All credit and questions regarding this version of KERMIT should be referred
to:
Larry Grim
Mesh, Inc.
2802 Bethel Rd.
Oxford, PA
215-932-3709
Sincerely,
(dfs@nadc)
Michael Lipczynski
Veda, Inc.
Warminster PA.
215-672-3200
P.S. We assembled and linked iRMX86 Kermit (with no modifications!!) on a OEM
system that contains an Intel 8026. We have not had any problems so far.
[Ed. - We seem to have no end of Kermits for Intel iRMX and MDS systems, and
so far have little idea which to keep and which to throw out. For (i)RMX,
we have the ones with prefixes RMX, IRM, and I86, plus Jack Bryan's new
version based on MS-Kermit 2.29C (MSTRM*), and for MDS systems we have the
MDS programs and the MD2 ones. Comparative reviews would be appreciated.
Meanwhile, you might want to coordinate with Jack Bryans about whether the
iRMX Kermit you've described should be added to maze at Columbia, or maybe
Jack's version will make it unnecessary.]
------------------------------
End of Info-Kermit Digest
*************************
-------
18-Dec-87 16:00:41-EST,26409;000000000000
Mail-From: SY.CHRISTINE created at 18-Dec-87 15:59:24
Date: Fri 18 Dec 87 15:59:23-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #27
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12359532433.39.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Fri, 18 Dec 1987 Volume 6 : Number 27
Today's Topics:
Departments:
ANNOUNCEMENTS -
IBM PC Kermit with Tektronix 4010 Emulation Available for Testing
Info-Kermit BITNET Subscribers Moved to LISTSERV
Changes to Okstate Kermit Distribution Service
Kermit Available for the HP-125 CP/M Business Computer
MS-DOS KERMIT -
Kermit-MS and >25-Line EGA Modes
More Comm Ports for MS-Kermit?
UNIX KERMIT -
Suspending C-Kermit under 4.2 BSD
C-Kermit Problems
MISCELLANY -
Trouble Building CMS Kermit
Kermit-PE (Concurrent 3200, OS/32) Bug Fix
Need Kermit on a VAX 730 under VMS 4.0
Red Ryder's Kermit Send Fails
Re: BOO File Problems
Kermit 3.79 on Apple 2c
Kermit Found for Convex
Need Kermit for IBM System 9000
Kermit Wanted for Old RSX-11m v3.2
----------------------------------------------------------------------
Date: Thu, 17 Dec 87 00:11 MST
From: <JRD%USU.BITNET@CUVMA.COLUMBIA.EDU> (Joe Doupnik)
Subject: IBM PC Kermit with Tektronix 4010 Emulation Available for Testing
Keywords: Tektronix Emulation, MS-DOS Kermit, EGA
File MSTIBM.BOO, dated 16 Dec 1987, is on the way. It includes Tektronix 4010
graphics terminal emulation (plus Tek 4014 line-drawing commands) for the IBM
PC with EGA, CGA, or Hercules graphics adapter, or no graphics board at all
(Kermit automatically senses which board is in place). Tek emulation can be
invoked in two ways:
(1) SET TERMINAL TEK (or by toggling terminal type with Alt-Minus), and
(2) from within DEC or Heath mode when the host transmits ESC-Formfeed.
Return to DEC/Heath mode upon receipt of Ctrl-X, or SET TERM VT102 (or
anything other than Tek). On color systems, the prevailing fore- and
background colors are used. On systems with sufficient graphics memory, both
the text and graphics screens are saved for restoral after escaping back and
reconnecting.
There's also a corresponding version of "generic" MS-DOS Kermit, MSTGEN.BOO,
naturally without the Tek emulation.
Joe D.
[Ed. - Many, many thanks, Joe! This is a great piece of work. It is based on
Brian Holley's (Cambridge U, UK) adaptation of Tek code that was originally
written for the TI PC version of Kermit by Joe Smith (Colorado School of
Mines). Joe has seamlessly integrated it into the mainline Kermit, and added
many features in the process. We've tested the result on PCs, XTs, and ATs,
and it works, and it goes fast! So far, the manual (MST29C.DOC) does not
describe the Tek emulation in any detail, but a few preliminary notes can be
found in MSTIBM.HLP. The new Kermit version itself is in MSTIBM.BOO. These
files are in KER: on CU20B.COLUMBIA.EDU, available via anonymous FTP, or
available as MSTIBM * from KERMSRV at CUVMA on BITNET. If no serious problems
are encountered, this could be "it" -- the real 2.30 release.]
------------------------------
Date: Thu 17 Dec 87 17:15:03-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit BITNET Subscribers Moved to LISTSERV
Keywords: BITNET, LISTSERV
As announced a while back, the WISCVM mail gateway between BITNET and the
other networks (Internet, CSnet, CCnet, etc) ceased operation on December
15th. There were still 105 subscribers of Info-Kermit using this gateway.
Some of these subscribers were lists in themselves, so it's hard to know how
many people at how many sites are involved.
Before this edition of the Info-Kermit Digest was sent, all of these
subscribers were moved to a new LISTSERV-based distribution, I-KERMIT@CUVMA.
If this happened to you, you should have received by now a notification from
your friendly neighborhood LISTSERVer.
From now on, anyone who wants to subscribe to the Info-Kermit Digest from a
BITNET site should send mail to LISTSERV@CUVMA, with the body of the message
as follows:
SUBSCRIBE I-KERMIT your personal name
Similarly, if you are getting Info-Kermit mail from a LISTSERVer, and you
want to cancel your subscription, send mail to I-KERMIT@CUVMA, with the
body of the message saying
UNSUBSCRIBE I-KERMIT
For more information about LISTSERV, send mail to LISTSERV@CUVMA, with the
message body saying "HELP" (for a short getting-started message) or "INFO GEN"
for a longer explanation of what LISTSERV is, along with the most common
commands.
Most of the subscribers that were moved had to be entered as "Name Unknown"
because the personal names were not kept in our present distribution list. If
you receive mail that refers to you in this manner, you can tell LISTSERV your
actual name by sending it a SUBSCRIBE request that includes your name. It
should correct the current entry, rather than make a duplicate one.
------------------------------
Date: Mon, 14 Dec 87 12:57:22 -0600
From: Mark Vasoll <vasoll@a.cs.okstate.edu>
Subject: Changes to Okstate Kermit Distribution Service
Keywords: Okstate
We have made some changes in our communications system that will now allow
us to offer 2400 bps access as well as the old 300/1200 access via both
Kermit and UUCP. The login information has not changed, except that upon
receiving a carrier, you should send the following
<carriage return>
<delay about 2 seconds>
<carriage return>
In UUCPeese, that's:
"" \r\d\d\r ogin: uucpker word: thefrog
or in a C-Kermit script:
~0 ~r~d~r ogin: kermsrv work: piggy
Since new hardware is involved, there may be problems. It would be most
helpful if you could send uucp-support@a.cs.okstate.edu a message describing
any problems with approximate time (don't forget the timezone) and date.
Also, your UUCP system name would be helpful if you were trying to use UUCP.
Thanks,
Mark Vasoll
Computing and Information Sciences Internet: vasoll@a.cs.okstate.edu
Oklahoma State University UUCP: {cbosgd, ihnp4,
Stillwater, Oklahoma rutgers}!okstate!vasoll
[Ed. - Thanks Mark. This information has been added to the file
KER:AANOKS.HLP.]
------------------------------
Date: Tue, 8 Dec 87 13:45 PST
From: <MAILER@UWALOCKE>
Subject: Kermit Available for the HP-125 CP/M Business Computer
Keywords: CP/M Kermit, HP-125
I have a version of CP/M Kermit for the Hewlett-Packard HP-125 (a short-lived
CP/M machine produced in the early 1980's and intended for the business
office.) It is based on version 4.05 of 1985. It will send/receive files
over both Data Comm Port 1 and Data Comm Port 2 (although the latter can only
be done in 7-bit bytes -- HP's restriction) and will emulate a VT52 as well as
responding to HP terminal escape sequences with VT52-Emulation OFF. Would you
be interested in this version, even though it is not current?
By the way, I am using an HP-125 because a company called Maryland Computer
Services (now part of a company called Enabling Technologies) modified it for
voice-access with special software for the blind. I am a blind systems
programmer on a DECsystem-10 here.
Please send any reply to MAILER@UWALOCKE. Please place on the subject-line
of your message the phrase dec10%"bpa".
Michael Freeman-MORF
Bonneville Power administration
P.O. Box 491
Vancouver, Wa 98666
[Ed. - Thanks! The system-dependent hex file, plus the above message,
have been installed in KER:CP4HP1.* on CU20B. Michael will be sending the
sources to Bertil Schou in England, who's been working on CP/M-80 Kermit,
so that HP-125 support will be in the next release.]
------------------------------
Date: Wed 2 Dec 87 21:43:18-EST
From: Jim Celoni S.J. <su.Celoni@CU20B.COLUMBIA.EDU>
Subject: Kermit-MS and >25-Line EGA Modes
Keywords: MS-DOS Kermit, EGA
I'm using Kermit-MS now on an AT compatible w/ EGA & ECD in 34x80 mode.
I've also used it at 42x80 and 57x80, all as heath-19 (except changing
the termcap li entry), using ega35, ega43, and ega58 mode-setting programs.
I'm happy Kermit-MS 2.29c handles more than 24 lines intelligently!
------------------------------
Date: Mon, 14 Dec 87 17:34 EST
From: <JBLAIR%LOYVAX.BITNET@CUVMA.COLUMBIA.EDU>
Subject: More Comm Ports for MS-Kermit?
Keywords: IBM PC Comm Ports, COM3 and COM4, MS-DOS Kermit
I was attempting to alter the MS-DOS version of Kermit so that it would access
COM3: or COM4:, but to no success. I was wondering if there were any standards
to the interupt vector addresses and the end-of-int value. I have the
addresses of the data/status/port for com 3 & 4, but the values of MDINTC3/4,
MDINTO3/4, MDINTV3/4, and EIOCOM3/4 are a mystery. Can anyone help with an
explanation of how these values are obtained? Is there someone else that I
should be asking?
Thank you
Bryan Blair a.k.a JBLAIR@LOYVAX
[Ed. - There are indeed no standards. The current prerelease of MS-DOS
Kermit, 2.29C (soon to be 2.30), includes hooks to allow users to access
their COM3 or COM4 ports. These are documented in the MS Kermit manual,
MST29C.DOC, which must be used in conjunction with your expansion board's
technical manual.]
------------------------------
Date: Wed, 9 Dec 87 14:28:25 -0500 (EST)
From: ww0n+@andrew.cmu.edu (Walter Lloyd Wimer, III)
Subject: Suspending C-Kermit under 4.2 BSD
Keywords: C-Kermit
Has anyone fixed C-Kermit so that it can be suspended using ^Z (SIGTSTP)
without leaving the terminal in cbreak and no-echo mode?
If not, I believe I have. Let me know and I'll send the changes.
Walt Wimer
Data Communications
Carnegie Mellon University
[Ed. - We've received a number of fixes for this. They're listed in
KER:XKUKER.BWR on CU20B, and will be added to the next release.]
------------------------------
Date: Sun, 8 Nov 87 21:59:05 EST
From: Phil Ritzenthaler <ritzenth%andy.bgsu.edu@RELAY.CS.NET>
Subject: C-Kermit Problems
Keywords: C-Kermit
I have had a small problem occur with the new C Kermit (4E(067)). I was
uploading a 92K file from my PC (using 2.29b) to a VAX 11/785 running Unix
4.3 BSD using a packet length of 500 bytes. This was a VERY local call.
I had 3 errors that occured during transmission and whin doing a 'diff' against
the original file there were problems . . . some "Y#5"'s, many "#"'s, and then
many more "@"'s. It looked to be the length of 1 500 byte packet.
Could you clue me in on what occured? Are the larger packet lengths
unresonable and not possible in the "real world"?
Again, thanks . . .
Phil Ritzenthaler |USnail: University Computer Services
Computer Graphics Research Specialist | 241 Math-Science Bldg.
UUCP :.!cbosgd!osu-cis!bgsuvax!ritzenth | Bowling Green State University
CSNET: ritzenth@bgsu.edu | Bowling Green, OH 43403-0125
ARPA : ritzenth%bgsu.edu@relay.cs.net | Phone: (419) 372-2102
[Ed. - If anybody can reproduce this problem, please send in the exact scenario
so we can fix it!]
------------------------------
Date: Thu, 29 Oct 87 11:53:41+0700
From: indovax!ranti@uunet.uu.net (Benny Ranti )
Subject: Trouble Building CMS Kermit
Keywords: CMS Kermit
I am research assistant at Comp. Sc. Center Univ. of Indonesia. I have
tried to compile Kermit CMS source program (sixth edition, rev. 2 based on
IBM 360/370 Assembly Lang) on IBM 4361 (under VM/CMS). We found an error
during the compilation, the error was "undefined code" for STAX instruction
within INTINI routine. We have looked at IBM's book but we didn't find STAX
as a mnemonic.
Another thing, do you have Kermit source for VSE/SP ?
I am looking forward to hearing a good news from you.
Please contact me:
my uucp address is:
uunet!indogtw!indovax!ranti
[Ed. - The STAX macro is in the TSOMAC macro library. Like it says in the
intallation instructions for CMS Kermit, you have to GLOBAL TSOMAC before
assembling.
There is presently no Kermit for DOS/VSE. But with the new "portable 370"
Kermit nearly ready for release, it should be a simple (?) matter for a DOS/VSE
programmer to add support for that system, following the methods used for
VM/CMS and MVS/TSO. Watch Info-Kermit for announcements.]
------------------------------
Date: 8-DEC-1987 14:54:26 GMT
From: Diane Lowe, CAP Industries.
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Kermit-PE (Concurrent 3200, OS/32) Bug Fix
Keywords: Perkin-Elmer Kermit
I have recently discovered a bug in our version 2.0 of Kermit-PE (Concurrent
3200, OS/32).
At the OS/32 Mainframe end, when trying to SET DEBUG ON, the following Fortran
error message occurred;
ERR 301 (OOC8AO) :ON
VALUE 20 FOR SPECIFIER > MAX VALUE ALLOWED:14
TASK PAUSED
This can be resolved by adding the following line to KERMIT.LNK
OPTION LU=21
Regards,
Diane Lowe.
[Ed. - Thanks Diane. Although are currently sending out 2.1 (9/11/86) of
PE-Kermit, we have created a KER:PERKIN.BWR to add your fix.]
------------------------------
Date: 25 Nov 87 16:57:23 GMT
From: oldeng@gpu.utcs.toronto.edu (Dictionary of Old English)
Subject: Need Kermit on a VAX 730 under VMS 4.0
Keywords: VAX/VMX Kermit
I need to get any version of Kermit up on our DEC VAX 11/730. It is running
VAX/VMS 4.0, right now, and the only compiler we have is a version of a
C compiler from Whitesmiths.
We can transfer ASCII to it right now, through various means, but binaries so
far have been a problem.
Also, the only removable media we have are RL02 cartridges, and the tiny
DECTAPE II's. RL02 aren't very popular, and I am not sure if we can directly
read or write DECTAPE II's. If we can get a binary of a kermit on an RL02,
it could be a solution, but so far, we haven't been able to find anyone.
Another alternative is to do something similar to "uuencode" a binary of
kermit, transfer it via ASCII, then "uudecode" it on the VAX. The only
problem is, we don't have such utilities. We might need a source for that
in Whitesmith's C, or get the binary... which brings us back to the same
problem.
SO, if anyone can suggest anything that we can do to get Kermit running
on our VAX, it would be much appreciated.
Also, please respond by Email if possible.
--Tak Ariga
Internet: oldeng@gpu.utcs.toronto.edu
BITNET: oldeng@UTORGPU
Phone: (416) 978-8883 {office}
++ Dictionary of Old English == University of Toronto == Toronto, Canada ++
[Ed. - VMS Kermit is available in hex file format as VMSMIT HEX, available
from KERMSRV at CUVMA, along with a Macro-32 decoder program, VMSDEH MAR,
which you can assemble, link, and run, to produce a runnable Kermit. See
the file VMSAAA HLP. Or, if anybody wants to volunteer to send Kermit on
an RL02 or tape cassette...]
------------------------------
Date: Wed, 09 Dec 87 13:27:53 -0800
From: Alastair Milne <milne@Q2.ICS.UCI.EDU>
Subject: Red Ryder's Kermit Send Fails
Keywords: Red Ryder
I have been trying to send a textfile created with IdeaLiner from a 512K Mac
to C-Kermit under a UNIX copy called DYNIX, running on a Sequent. The file
goes across, and no error is reported, but when I look at it on the UNIX
system, there are no linebreaks at all. In fact, "wc" counts 0 lines for it
I can't even use "vi" on it: the single undelimited line is far too long.
But the linebreaks are definitely there on the Mac. Apart from the fact
that MockWrite shows that text properly broken, a byte-level examination
with ViewEdit in MacTools shows an ASCII 13 at the end of each line.
I doubt whether it can be anything do to with the UNIX kermit. I've
already used it often for exchanging files with DOS (Kermit 2.29C) and the
p-System, and the files go across perfectly intact.
I am using the Kermit built into Red ryder 9.2; I don't know which version
of C Kermit is on UNIX. I have tried all the switch settings I can find
that might add CR's or LF's at linebreaks, but they make no difference.
I've even tried fiddling with newline mode in the VT100 emulation, even
though Kermit should have all terminal emulation turned off.
This is a considerable and unexpected hindrance. Could somebody please
tell me how to get the line breaks preserved across the transfer? My work
on the Mac is for nothing if I can't get it to where our group works on the
Sequent.
I have tried getting a file from UNIX, using Red Ryder Kermit receive. It
works fine: all the linebreaks are where they're supposed to be. But
sending is hopeless.
Please help.
Thanks again,
Alastair Milne
[Ed. - I can't comment on Red Ryder, but if it were Mac Kermit, I'd guess
that you were sending the text in binary mode, so that the CRs which are
used on the Mac to delimit text lines were not being translated into CRLFs
during transmission, which means that Unix Kermit won't see any line breaks,
and so will just store the bare CRs, which are not line delimiters in Unix.]
------------------------------
Date: 11 Nov 87
From: RECK@DBNUAMA1.BITNET (Gisbert W.Selke)
Subject: Re: BOO File Problems
Keywords: MS-DOS Kermit, .BOO Files
Xref: BOO Files, See .BOO Files
I was doubting my sanity some time ago when I had serious problems with
MS-Kermit boo files, too. It turned out to be a local EBCDIC -> ASCII
conversion problem, and after some experimenting I found a way to get my boo
files transferred in a reliable way - the un-booed executables do work.
The problem is mainly that the boo format uses all the characters from
ASCII-zero (ASCII 48) to ASCII-tilde (ASCII 126). Included in this set are
some characters for which no standard EBCDIC <-> ASCII conversion rule
exists; assuming that characters and digits are OK (they will be, won't
they?!?), the extra characters needed are:
colon ":"
semicolon ";"
less than "<"
equals "="
greater than ">"
question mark "?"
at-sign "@"
left square bracket "[" (at our place, EBCDIC hex 'AD')
backslash "\"
right square bracket "]" (at our place, EBCDIC hex 'BD')
caret, up-arrow "^" (in EBCDIC, usually negation sign)
underscore "_"
accent grave "`"
left curly brace "{"
vertical bar ":" (maybe "|" in some EBCDIC places)
right curly brace "}"
tilde, quiggle "~"
You should check if all these characters are transferred properly with
whatever procedure you use to get files to your Amiga. The ones that caused
trouble here were the up-arrow/negation-sign, the vertical bar and the
square brackets. So I used XEDIT to translate these particular characters
into inconspicuous sequences which got transferred properly; I wrote the
following XEDIT macro file to accomplish this:
SET LRECL 255
SET TRUNC 255
SET ARB OFF
SET HEX ON
TOP
* For transferring boo files to PC via IRMA board and IRMA software:
* translate characters which will not transfer properly otherwise:
:0 C /^/`not`/ * *
:0 C /|/`vba`/ * *
:0 C /X'AD'/`lbr`/ * *
:0 C /X'BD'/`rbr`/ * *
Remember to invoke XEDIT with a greater width, i.e.
XEDIT <file name> <file type> (width 255 noprof
This also makes sure you're not hampered by any profile which sets
trunc or lrecl to something inconvenient. Executing the above macro
file results in a file with greater line lengths: your file transfer
utility should be able to cope with that.
Also note that at some places, apparently ASCII left and right square
brackets are translated to EBCDIC "" (cent) and "|" (continuous
vertical bar), respectively; you might have to check that, although
I never encountered that with CUVMA files.
Well, I hope this at least gives you some clues, even if it isn't a
ready solution to your problem.
Happy kermitting,
\Gisbert
P.S.: I am enclosing a brief description of the boo format which
I prepared for a booing programme - for what it's worth.
C BOO FORMAT FILES
C
C IT IS NOT MEANT TO BE A TRANSFER PROTOCOL REPLACEMENT; IT
C JUST MAKES TRANSFER POSSIBLE ACROSS LINES (E.G., DATA NETWORKS)
C WHEN NO KERMITS ARE AVAILABLE OR ONE OF THEM CAN'T COPE WITH
C BINARY STUFF.
C
C BEWARE OF GREMLINS, THOUGH; ESPECIALLY EBCDIC <-> ASCII
C TRANSLATION MAY BE A PROBLEM FOR SOME OF THE CHARACTERS ...
C
C BASICALLY, 3 BYTES = 24 BITS ARE ENCODED INTO 4 CHARACTERS
C BY DIVIDING THEM INTO 6-BIT-PIECES AND THEN ADDING ASCII-ZERO
C TO MAKE THESE PIECES PRINTABLE. THE RESULT LIES IN THE RANGE
C ASCII-ZERO TO ASCII-SMALL-O. - IN ADDITION, NULL COMPRESSION
C TAKES PLACE; CONSECUTIVE NULL BYTES (WHICH OCCUR FREQUENTLY
C IN EXECUTABLE FILES, E.G.) ARE ENCODED WITH A TILDE LEAD-IN
C FOLLOWED BY THE NUMBER OF NULLS (UP TO 78), AGAIN RENDERED
C PRINTABLE BY ADDING ASCII-ZERO. THE RESULTING CHARACTER IS IN
C THE RANGE ASCII-ZERO (WELL, ASCII-TWO OR -THREE, REALLY) TO
C TILDE (ASCII CODE 126). - CHUNKS OF FOUR CHARACTERS BELONGING
C TOGETHER (RSP. TILDE AND NULL REPEAT COUNT) SHOULD NOT BE
C DIVIDED ACROSS LINES. A LINE HAS A MAXIMUM LENGTH OF 76
C CHARACTERS. - IN ADDITION, THE FIRST LINE OF THE FILE CONTAINS
C THE NAME OF THE ORIGINAL FILE (IF KNOWN - OTHERWISE A DUMMY NAME)
C AND NOTHING ELSE.
C
------------------------------
Date: Thu, 5 Nov 87 22:31:58 EST
From: ciaraldi@cs.rochester.edu
Subject: Kermit 3.79 on Apple 2c
Keywords: Apple II Kermit
I have been using Apple Kermit 3.79 on an Apple 2c and find it works great!
Terminal emulation and transfers at 2400 baud with no missing characters,
VT100 emulation including keypad, the works! But there's one minor
problem...
While characters received from a remote system over the modem come through
OK at 300, 1200, and 2400 baud, those generated by the modem itself are
often garbled.
For example, when you type "AT" the modem is supposed to reply "OK".
Sometimes this works and sometimes it comes out as "O+". Similarly, when
you reach the other machine the modem sends you "CONNECT", but this NEVER
comes through on the screen--it's always something like "CO%&T"
(sorry, don't remember the exact sequence).
It looks like the computer cannot handle characters that arrive too close
together. I tried this on two different 2c's, and one has a much bigger
problem than the other.
Has anyone seen this problem? Is it a Kermit or a 2c problem? At first I
thought it was a matter of not responding to interrupts in time, but since
it even happens at 300 baud this doesn't seem likely.
I though it might be that the 2c was looking for 2 stop bits, but the source
code seems to be initializing the port properly (not that I'm a 2c expert!).
The 2c manual says something like "Peculiarities in the 2c's baud rate
generator may require changes in the data format" in the section on setting
data bits, stop bits, and parity. Could that be it? Did different
revisions of the 2c have different peculiarities? Is there a workaround?
I foresee this will be a problem if a script facility is ever added to Apple
Kermit, as it will be hard to do input matching to look for prompts if they
cannot be received reliably.
Reviewing the manual, I realized that this problem of not getting the modem
prompts correctly will also mess up the MODEM command in Apple Kermit, since
it waits to receive the string "CONNECT" from the modem.
Mike Ciaraldi
University of Rochester Computer Science Department
ciaraldi@cs.rochester.edu
[Ed. - This report has been added to KER:APPKER.BWR.]
------------------------------
Date: Mon, 7 Dec 87 15:22 EST
From: <ACCESS@ALCANKTN.BITNET> (Shawn Allin - Alcan KRDC Computer Services)
Subject: Kermit Found for Convex
Keywords: Convex Kermit
I sent a question to you concerning the availability of Kermit for a Convex
supercomputer some months ago, and at that time you were unaware of a version
for it. I just thought I'd get back to you with the news that there is now a
version running on it.
The only identification I have found on it so far is "UCL Remote-only Kermit,
V15B, March 1986".
I can look into it more, if you want further information.
Regards,
Shawn Allin
Alcan International Ltd.,
P.O. Box 8400,
Kingston, Ont.,
Canada K7L 4Z4
(613) 541-2178
Bitnet: ACCESS@ALCANKTN
(ALLIN@QUCDNSUR is alternate address if routing tables aren't updated yet)
[Ed. - We don't seem to have it in our collection. If someone can send it
in, along with some more information about the machine and operating system
(apparently this is not the Convex that runs Unix), we'd be glad to add it
to the Kermit distribution.]
------------------------------
Date: Wed, 25 Nov 87 15:32 EST
From: GARTLEY%alcoa.com@RELAY.CS.NET
Subject: Need Kermit for IBM System 9000
Keywords: IBM System 9000 Kermit
Please help.
I am looking for a version of Kermit that will run on an IBM System 9000
Pascal V1.2 CSOS.
I do not know what all that means but that was on the operating manual (This
is not my system ).
Thanks
John Gartley
Gartley@alcoa.com (CSnet) or
Gartley@aldncf.alcoa.com (ARPAnet)...after 1-DEC-87
------------------------------
Date: Wed, 18 Nov 87 22:14 EST
From: Bryan Lally <M014BL02@VB.CC.CMU.EDU>
Subject: Kermit Wanted for Old RSX-11m v3.2
Keywords: RSX Kermit, PDP-11
Help!
For reasons we won't go into, I need a KERMIT for a PDP-11 system running
RSX-11m v3.2. This means RMS v1, not v2. Anyone got one? The new ones
won't work, 'cause they need RMS v2. Replies to:
bryan lally
M014BL02@cmccvb.cc.cmu.edu
M014BL02@cmccvb.bitnet
------------------------------
End of Info-Kermit Digest
*************************
-------
28-Dec-87 20:25:39-EST,23568;000000000000
Mail-From: SY.FDC created at 28-Dec-87 20:25:05
Date: Mon 28 Dec 87 20:25:05-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #28
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12362202240.25.SY.FDC@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Mon, 28 Dec 1987 Volume 6 : Number 28
Today's Topics:
Announcing IBM Mainframe VM/CMS Kermit Version 4.0
MacKermit Status?
Version 0.9(36)b4 of Macintosh Kermit Available for Testing
Kermit News
Request for Kermit Information
VAX/VMS Cluster and Kermit Problem
Non-Bug Report, MS-Kermit, CP/M Kermit (Kaypro)
Kermit 3.79 on Apple 2c
IBM 370 Mainframe UTS24-Kermit?
Kermit & Everex Modems?
----------------------------------------------------------------------
Date: Mon, 1987 Dec 21 12:08 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Subject: Announcing IBM Mainframe VM/CMS Kermit Version 4.0
Organization: Harvard/Smithsonian Center for Astrophysics
Keywords: IBM 370 Kermit, VM/CMS Kermit, CMS Kermit
Xref: IBM Mainframe, Also see IBM 370
Xref: VM/CMS Kermit, Also see VM/CMS Kermit, IBM 370
This is to announce CMS Kermit Release 4.0 for IBM 370 series mainframes
running the VM/CMS operating system. The program is now a member of the
generic family Kermit-370 and appears in the Kermit distribution under a new
prefix: all CMS-specific files begin with IKC, while generic Kermit-370 files
begin with IK0 (I K Zero). Kermit-CMS no longer consists of a single source
file. Instead, the source is split into sub-files, some generic and some
CMS-specific. The separate pieces are to be recombined into a single
composite source (or made into a macro library) for installation. See the
file IKCKER.INS for instructions. Generally, the files formerly known as
CMSKERM.* have been replaced by new IKCKER.* files. The companion TSO Kermit
Release 4.0 is still in the testing and debugging stage, but should be
available soon. Anyone interested in helping to get Kermit-TSO ready for
release should contact John Chandler <PEPMNT@CFAAMP.BITNET>.
Below is a list of the more important additions in Version 4.0:
--- generic features ---
1. Code reorganization into generic 370 and system-specific sections.
2. Optional separate translation tables for counteracting the system
conversion of terminal I/O.
3. New GIVE command for saving a modified translation table.
4. A new, RAW debug mode for recording the packet traffic as actually
sent and received on "GRAPHICS" and "SERIES1" devices.
5. Preservation of the case of commands as typed, with uppercase
conversion of only those words that must be uppercase.
6. New SET MARGIN command for limiting the width of a file to be sent.
7. Settable tab stops for Kermit's conversion of tabs to spaces
(alternative to the default 1, 9, 17, etc.).
8. Replace SET SERIES1 subcommand with new SET CONTROLLER. Support for
multiple terminal controller types.
9. New DIRECTORY and HOST subcommands following Kermit standard.
10. Combination of file-attribute SET subcommands (FILE-TYPE, LRECL, and
RECFM) into a new group SET FILE.
11. Separate retry limits for initial and subsequent packet exchanges.
12. Pad binary records on disk with nulls, rather than blanks.
13. Automatically tune packet length when sending long packets according
to heuristic optimum based on sparse Poisson statistics, provided
that transmission errors do occur.
14. Expand STATUS report to include the number of files in the last
transfer, throughput statistics, heuristic optimum packet length
(when long packets are enabled), and the reason for any file
rejection based on A-packets.
15. New command TDUMP NAMES to display the list of files sent in the
last transfer.
16. Add file creation date to A-packet repertoire.
17. REMOTE COPY and REMOTE RENAME commands to a server at the other end.
18. Allow long packets through a 7171 with VTAM.
19. New type D-BINARY for binary files with undelimited variable-length
records.
20. SET 8-BIT-QUOTE. Allow 8-bit data where possible via SET PARITY.
21. SET SYSCMD, so that Kermit can be told to try "illegal" subcommands
as host system commands instead of just rejecting them.
22. SET PROMPT subcommand.
23. Do not forget parameters specified by the other Kermit in I-packets.
24. Keep track of truncated records during a RECEIVE operation and
report the count in STATUS; also call truncation an error after
everything is received.
25. SET HANDSHAKE subcommand to alter or suppress handshake character
Kermit-370 sends out after each packet.
--- CMS-only features ---
26. System commands issued through Kermit via the subcommands CMS or
HOST are automatically passed on to CP if (a) CMS rejects them and
(b) IMPCP is set ON.
27. Kermit subcommands may be executed directly from CMS EXEC's.
28. Reject files known (via A-packets) to be too big for available
storage.
29. Bypass user translation tables and set TERMINAL SCROLL CONT for
protocol mode on TTY lines.
30. KERMBOOT avoids the loading problem (VIRTUAL STORAGE CAPACITY
EXCEEDED) due to large GLOBAL TXTLIB's and preserves the untokenized
command line so that Kermit may be given mixed-case or long words as
part of the initial commands.
[Ed. - Thanks, John! And thanks to all who helped put this new program
together. This is a kind of milestone in Kermit development. It should allow
the many IBM mainframe operating systems to run a common, advanced version of
Kermit. All that's necessary is for some volunteers who are expert in
MVS/TSO, DOS/VSE, MUSIC, MTS, GUTS, and the various other 370 OS's to step
forward and fill in the system-dependent modules for their systems (as John
points out, the TSO version is nearly complete, but still needs some testing
and debugging). If you want to volunteer to help, please contact John
directly, cc to Info-Kermit@CU20B. The files are in KER:IK*.* on CU20B,
available via anonymous FTP, or on BITNET as IK* *, available from KERMSRV on
host CUVMA, and replace the files whose names started with CMS.
By the way, some of you may have seen an article in Digital News, November 30,
called "Advanced Kermit Version Available Soon for VAXs" (p.10). It reported
on part of our talk at Tokyo DECUS, in which we described John's portable IBM
mainframe Kermit. The editors at Digital News felt that putting "VAX" in the
headline would give the article more of a DEC slant, but it's obviously
misleading.]
------------------------------
Date: Sat, 28 Nov 87 13:59:06 PST
From: Dwayne Virnau... <INFO-MAC-REQUEST@SUMEX-AIM.STANFORD.EDU>
Subject: MacKermit Status?
Keywords: Macintosh Kermit
Greetings from the INFO-MAC moderator, keeper of the sacred INFO-MAC
archives. Files in the archives are available to anyone on the ARPAnet or
BITNET, and specifically to some 10,000 people who subscribe to the INFO-MAC
mailing list. The latest version of Kermit for the Macintosh I have is
0.8(34), which does not work well (at all?) on the Mac2. So, a few
questions:
What is the latest version of Kermit for the Macintosh? How can I obtain a
copy of it? I have FTP access, and would prefer to avoid tape or disk
distribution.
And on a slightly different note, what is the proper way to make this
request? Since I am INFO-MAC I field hundreds of questions from people who
expect me to know every detal of the Macintosh, I apologize if INFO-KERMIT
is not the proper address. But I am also hoping you might be able to direct
me.
Many thanks,
Dwayne Virnau...
Moderator, Info-Mac
[Ed. - A new MacKermit was sent to us by Matthias Aebi of the Eidgenossische
Technische Hochschule in Zuerich, who also wrote Kermit for the Lilith
workstation, announced in Info-Kermit V6 #25, November 6, 1987. Since then,
Paul Placeway at Ohio State has been working on it. See the next message for
news about this.]
------------------------------
Date: Mon, 21 Dec 87 16:35:01 EST
From: paul@ohio-state.arpa (Paul Placeway)
Subject: Version 0.9(36)b4 of Macintosh Kermit Available for Testing
Keywords: Macintosh Kermit
Following is a BinHex 4-ified copy of MacKermit 0.9(36)b4. I have made
several changes to Matthias' code:
The C-Kermit part of 0.9(36)b4 is based on the (absolutly vanilla) 4E(067)
code. I didn't have to edit any of the ckc* files a bit (ckmpro.c is just a
warted ckcpro.w with the standard Mac patch).
The backslash-number characters in the key macro code are now done in Octal
(just like C does). Also, one can do control characters symbolically:
\^A --> Control-A.
Macro strings are stored as Pascal strings throughout now, so that one can
make a macro that includes NUL (ASCII 0).
MacKermit now has MultiFinder support. It understands how to give away time
slices, has the SIZE (-1) resource, and will do background file transfers
(timeslicing multiple times per packet). (In the process, the file xfer
dialog became modeless).
It has the FOND resource in the source files now (so SEs should be happy).
I added the extra stuff to the emulator so that VAX TPU will get along with
it.
Clayton Elwell added the ANSI insert multiple characters command
(ESC [ n @) to the emulator.
I also added a few extra bells and whistles:
. flashing/nonflashing cursor option
. visible bell option
. extra status indicators in the file xfer dialog,
. the mouse cursor is hidden on every key typed,
. the menu command characters option default is now dependant on the type of
keyboard that the user is running (set for keyboards with a CTRL key, unset
for all others), and
. there is now a default set of key macros and modifiers (arrow keys do VT100
arrow key commands, BACKSPACE -> DEL, backquote -> ESC, command-backquote
and control-backquote -> plain backquote).
Have fun,
-- Paul
[Ed. - Thanks, Paul! (And Matthias too!) This new version is supposed to run
on any Macintosh, and to correct the various problems that many of you have
reported not only with 0.8(34), but also some of the newer prereleases. It
should run on the entire Mac family with no special fussing about fonts or
other minutia. But it probably will not fit into an original 128K Mac (does
anyone still have such a thing?) The new Mac Kermit is still not a finished
product, however. Some finishing touches are required to the key definition
feature, and in some other areas too. And the manual has yet to be written.
Comments and reviews are welcome, and hopefully we'll have a final release
(maybe this time it'll actually be called 1.0!) soon, complete with source in
MPW C. The program and documentation (such as it is) are in KER:XKM936.* on
CU20B, and KXK936 * on CUVMA.]
------------------------------
Date: Thu, 3 Dec 87 10:53:25 EST
From: Phil Ritzenthaler <ritzenth%andy.bgsu.edu@RELAY.CS.NET>
Subject: Kermit News
Keywords: Kermit News, Newsletter
Is this newsletter still being printed? I just had Vol.1 No. 1 pass across
my desk (slow, aren't they!) and I was wondering if there have been other
issues?
[Ed. - Yes, we just mailed out Volume 2 Number 1 (the second issue). Anyone
who was on the mailing list for the first issue should also receive the
second one. Plus the thousands of people who have ordered Kermit from us
since August 1986, or who have requested to be added to the mailing list.
Meanwhile, this time (unlike the first) we have an on-line version, available
for FTP'ing, etc. It's in KER:NEWSV2.N1 on CU20B, or NEWSV2 N1 on CUVMA.]
------------------------------
Date: Fri, 4 Dec 87 09:23:36 mst
From: modular!earley@arizona.edu (Joe Earley)
Subject: Request for Kermit Information
Keywords: Kermit Protocol
Would you please send me some information about Kermit. I've heard good
things about it and am hoping Kermit's capabilities exceed those of a package
we have developed in-house.
Specifically, we are interested if Kermit can do the following:
o do file transfers which leave intact most VMS file header information,
o do file transfers between Unix and VMS and retain file attributes,
o handle arbitrary packet sizes to take advantage of clean lines,
o have a 'talk' mode to do remote logins,
o do automatic dialing and login to the remote host,
o do session logging,
o encoding of nonprintable characters to get around PBX's which act
upon control characters,
o do file transfers in an unattended batch mode.
We have only been on the net for about one month. Our only access to the
outside world is through arizona. We cannot directly get to an archive site
that I know of, so we can't get any previous information put into the Kermit
news group. Thanks for any information you can give us.
Joe Earley, Modular Mining Systems, Tucson, Arizona 85714
USENET: {ihnp4,allegra,cmcl2,noao}!arizona!modular!earley
INTERNET: modular!earley@arizona.edu
[Ed. - Kermit protocol, as defined, can do everything you ask. Actual
implementations, on the other hand, vary according to which features they
include. Let's look at your list:
o Do file transfers which leave intact most VMS file header information?
Currently, no. If you want to preserve VMS file headers, you have to hexify
the VMS files first and dehexify them on the other end, using a special
utility that comes with Kermit. Then you get the entire RMS FILES-11 FAB
structure, or whatever it's called. Future versions of VMS Kermit may
transfer this information directly, using Kermit's File Attribute mechanism
(as PDP-11 Kermit currently does).
o Do file transfers between Unix and VMS and retain file attributes?
Currently, no. In the future, VMS and Unix Kermit will be built from common
C-language sources, and should be able to handle file attributes.
o Handle arbitrary packet sizes to take advantage of clean lines?
Normal Kermit packets are 96 bytes long at most. Extended-length packets (a
different format) may be up to about 9K in length. Many Kermit programs
support this option, including C-Kermit for VMS and Unix. Some
implementations (see the CMS Kermit announcement above) even vary the packet
size according to prevailing line conditions.
o Have a 'talk' mode to do remote logins?
Yes, most Kermits -- including practically all PC or microcomputer Kermits --
include terminal emulation. So do VMS and Unix Kermit.
o Do automatic dialing and login to the remote host?
These features are found in some Kermits, but not all. Unix Kermit includes
both a "dial" command (with accompanying modem control) and a script language.
MS-DOS Kermit includes a script language, etc.
o Do session logging?
Most Kermit programs that perform terminal emulation can also do session
logging.
o Encoding of nonprintable characters to get around PBX's which act
upon control characters?
This is a hallmark of the Kermit protocol. It encodes all packets as lines
of printable text.
o Do file transfers in an unattended batch mode?
Yes. This is a built-in part of the Kermit protocol.]
------------------------------
Date: Tue, 15 Dec 87 04:46:33 PST
From: fayr%armory.DEC@decwrl.dec.com (Rich Fay SPO-103/1 POLE 1-6)
Subject: VAX/VMS Cluster and Kermit Problem
Keywords: VAX/VMS Kermit
My name is Rich Fay from Digital. I work at the Springfield Plant. We are
having a problem using KERMIT with our VAX cluster as described below:
We are using VMS 4.6 and have the last 3 versions of VMS Kermit including
V3.3.111. All of them exhibit the same problem I will now describe. We are
using MSKermit 2.29 and CPM ROBIN KERMIT V 4.05, (this problem only occurs
when logging in through a modem, or a Hardline that is connected through an
interface that uses modem protocols).
Sample Session follows;
dial up and logon
$Kermit
VMS Kermit-32 version 3.3.111
Kermit-32>set file type binary
Kermit-32>server
Kermit Server running on VAX/VMS host. Please type your escape sequence to
return to your local machine. Shut down the server by typing the Kermit BYE
command on your local machine.
12:12:58.14 %KERMIT32-F-TIMEOUT, device timeout
12:12:58.75 %KERMIT32-E-RECERR, Receive error - !AS
12:12:59.14 %KERMIT32-F-TIMEOUT, device timeout
12:12:59.56 %KERMIT32-E-RECERR, Receive error - !AS
12:12:59.96 %KERMIT32-F-TIMEOUT, device timeout
12:13:00.38 %KERMIT32-E-RECERR, Receive error - !AS
It seems that this problem only exists on vax systems that belong to a
cluster. I also have an RT11 system running KERMIT version 3.53 with RT11
verison 5.4 and am using a DZV11M on an 11/23+, the DZ is connected to a hard
line to the VAX. This system exhibits the same problem as the Robin and the
Rainbow. From home, I dialed up a system that is not on the cluster and all
works very well. I then try dialing up a system on the cluster and get
immediate failure.
I have posted this problem to the Digital KERMIT notes conference and noone
seems to have a solution to our problem. We are hoping that you will be able
to shed some light on this problem. Is there some special hardware/software
setups that must be done on the cluster to make KERMIT work properly??
Thanx in advance for any help you can offer to this problem.
Regards,
Rich Fay
Return address is: FAYR@HEFTY.DEC.COM.
[Ed. - As noted previously, VMS Kermit-32 (the Stevens version, written in
Bliss) is a "stable" product (to use the corporate euphemism). This message
was circulated to various VAX/VMS cluster sites, and they reported no such
problem. Can anybody reproduce it or suggest a cure? Meanwhile, development
on the new C-language VMS Kermit continues.]
------------------------------
Date: Sun, 20 Dec 87 15:15:39 PST
From: jeh@pnet01.cts.com (Jamie Hanrahan)
Subject: Non-Bug Report, MS-Kermit, CP/M Kermit (Kaypro)
Keywords: CP/M Kermit, Kaypro Kermit, MS-DOS Kermit
I've used both CP/M Kermit and MS-Kermit between my Kaypro 8 and my brand-new
HyperTurboWhizzoSchizo-AT clone to the VAXes at work and various other large
machines, but until recently, I'd never tried transferring files between my
machines; so when it came time to move some dBASE II databases to the AT
clone, I approached the project with some trepidation.
The AT follows the RS232C standard of using a male connector for a DTE port,
but the Kaypro (also wired as a DTE) does not, so I needed a gender changer
in addition to my modem eliminator cable (which has two females). Before
attempting file transfers I decided it'd be best to just CONNECT the two
machines and see if characters typed on one would appear on the screen of
the other.
This worked the first time.
Time to try transferring a .DBF file. Put the AT in RECEIVE mode, and SEND
from the Kaypro...
This, too, worked the first time. Wait a minute, things aren't supposed to
be this easy... I'll run this .DBF through dBASE III+'s II-to-III converter
and see if it hiccups on anything.
Looks perfect. The rest of the .DBFs, index files, and program files
went just as easily.
You people do good work!!!!
(I'm sure this is old hat to you, but with all the bug reports you must get,
I figured you'd appreciate something a little different...)
Merry Christmas,
--- Jamie Hanrahan
(uucp: {cbosgd | hplabs!hp-sdd | sdcsvax | nosc}!crash!jeh)
(arpa: crash!jeh@nosc.mil)
(internet: jeh@crash.CTS.COM)
[Ed. - Thanks, Jamie! It's always nice to get reports like yours.]
------------------------------
Date: Mon, 21 Dec 87 06:45:04 PST
From: adelman@LBL.Gov (Kenneth Adelman)
Subject: Kermit 3.79 on Apple 2c
Keywords: Apple II Kermit
> I have been using Apple Kermit 3.79 on an Apple 2c and find it works great!
> Terminal emulation and transfers at 2400 baud with no missing characters,
> VT100 emulation including keypad, the works! But there's one minor
> problem...
>
> While characters received from a remote system over the modem come through
> OK at 300, 1200, and 2400 baud, those generated by the modem itself are
> often garbled.
>
> Has anyone seen this problem? Is it a Kermit or a 2c problem? At first I
> thought it was a matter of not responding to interrupts in time, but since
> it even happens at 300 baud this doesn't seem likely.
This sounds like a familiar problem. In order to save a few dollars, the Apple
//c's serial interface was clocked with a signal which was already present on
the motherboard and very close to the right frequency rather than adding a few
dollar crystal and clocking the 6551 ACIA at the right frequency. As a result,
the Apple interface runs a few percent slower than the advertised baud rate,
and won't talk to some modems. This problem is not present on any of the other
Apples, and perhaps Apple fixed it on the later //c's by adding the crystal.
I seem to recall someone saying that Apple would fix the problem if you could
convince your dealer that it exists. Apparently the serial interface talks to
Apple's modems just fine. The other solution would be to find a 6551 ACIA spec
sheet which would tell you what frequency crystal you need and what pins on
the 6551 to connect it across. Presumably you would need to cut one trace and
add the crystal.
Ken
------------------------------
Date: Wed, 16 Dec 87 15:44:47 PST
From: senderow%janus.Berkeley.EDU@berkeley.edu (Dan Senderowicz)
Subject: IBM 370 Mainframe UTS24-Kermit?
Keywords: UTS24 Kermit, IBM 370 Kermit
Does anyone have a working version of Kermit for a 370 mainframe running
UTS24? Thanks. Dan.
[Ed. - C-Kermit has code in it to support UTS24 (a kind of half-duplex Version
7 Unix for IBM mainframes from Amdahl Corp), and this code was used at several
sites in the past, but apparently it does not work at Berkeley. Can anybody
who's still running UTS24 help? This is one case where "portable 370" Kermit,
announced above, probably does not apply.]
------------------------------
Date: 8 Dec 87 07:58:24 GMT
From: amdcad!amdcad.AMD.COM!indra@ames.arpa (Indra Singhal)
Subject: Kermit & Everex Modems?
Keywords: Everex Modem, Internal Modem, MS-DOS Kermit
I just began subscribing to this group. I was told that there
had been a posting about a quirk in Everex modems that interfered
with proper Kermit operation on their modems. If any on of you
has a copy of the proceedings of the discussion, please
e-mail to me.
Thanks...
-I said so... & said it for myself. Indra K. Singhal
{ucbvax,decwrl,allegra}!amdcad!indra or amdcad!indra@decwrl.dec.com
[Ed. - MS-DOS Kermit 2.29 for the IBM PC family did indeed have trouble
dealing with Everex or Hayes half-card internal modems. Version 2.29B and
later fix the problem. Try the current 2.29C release in KER:MSTIBM.*.]
------------------------------
End of Info-Kermit Digest
*************************
-------
