SY.CHRISTINE@CU20B.CC.COLUMBIA.EDU (Christine M Gianone) (09/14/88)
Info-Kermit Digest Tue, 13 Sep 1988 Volume 8 : Number 8
Departments:
ANNOUNCEMENTS -
Submission of new version of Kermit-UCSD (UCPECAN)
MS-DOS KERMIT -
MS-Kermit 2.31 Quirks
Re: MS-Kermit v2.31 Eats Nulls
MS-Kermit and the Novell File Server
Re: MS-Kermit 2.31 Tabs Bug (Feature?)
MS-Kermit: Five Bugs and a Whinge
Goto Label Bug in 2.31 August 15?
Problems with MS-Kermit 2.31 Graphics
MS Kermit 2.31 File Dates
MISCELLANY -
Kermit Through Protocol Converters Under CMS
Send digest submissions to Info-Kermit@CUNIXC, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CUNIXC.
Kermit files may be obtained over networks and by mail order. On the
Internetwork, use FTP to log in to host CUNIXC, CUNIXC.CC.COLUMBIA.EDU, a
VAX 8700 running UNIX (Ultrix). The IP host number is 128.59.40.130. You
should be able to to FTP to CUNIXC, login as user ANONYMOUS (any password)
and GET the desired files. The Kermit files are in directories kermit/a,
kermit/b, kermit/c, kermit/d, and kermit/e. You can also get Kermit files
over BITNET/EARN; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA. For detailed instructions, read the
file k1/aanetw.hlp (AANETW HLP on KERMSRV). To order by mail, request a
complete list of Kermit versions and an order form from Kermit Distribution,
Columbia University Center for Computing Activities, 612 West 115th Street,
New York, NY 10025 USA.
----------------------------------------------------------------------
Date: Sat Aug 20 08:10:52 1988
From: portal!cup.portal.com!R_Tim_Coslet@sun.com
Subject: Submission of new version of Kermit-UCSD (UCPECAN)
Keywords: UCSD Pascal Kermit, p-System, Pecan
I am submiting my version of Kermit-UCSD (Version 1.0, 17 Aug 88), currently
running on the Atari MEGA ST2 with the Pecan Software Systems Inc p-System,
and adaptable to Version IV p-Systems on other machines.
You should recieve 2 files: 1) a large (about 3300 lines) one containing the
source (UCPECA.PAS) and a smaller (about 300 lines) one containing the
documentation (UCPECA.DOC).
This version does not have everything I was planning on implementing and has
a few known bugs (listed in the .DOC file), but it does work (and is MUCH
better than any of the other versions of Kermit-UCSD I could find currently
in Kermit Distribution).
I hope to be able to provide an upgrade on this within about 6 months to one
Year.
I also hope to be able to send an encoded KERMIT.CODE file and a decoding
program, containing the entire program and implementation parts of the Pecan
Library Units, for people with Version IV p-Systems that can't afford or
don't need to purchase Pecan's Library. They will still have to go to USUS
to get a REMUNIT for their system though. The Pecan Licence permits this for
"non-commercial purposes" (but I am still checking with them to make sure
that they are satisified with my attachment of their copyright notice, so
there will be no problems).
R. Tim Coslet
Usenet: R_Tim_Coslet@cup.portal.com
BIX: r.tim_coslet
[Ed. - Many thanks, R. Tim! Those who are interested in bringing up this
program on other UCSD p-Systems besides the Atari are encouraged to do so,
and report back the results. The .DOC file tells how to reach Pecan and
USUS. The files are in kermit/c/ucpeca.* on CUNIXC, and in KER:UCPECA.* on
CU20B, and also available as UCPECA * from KERMSRV at CUVMA, and also can be
ordered on Kermit Tape C from Columbia.]
------------------------------
Date: Wed, 17 Aug 88 10:30 EDT
From: <RWMIRA01%ULKYVX.BITNET@cuvmb.cc.columbia.edu>
Subject: MS-Kermit 2.31 Quirks
Keywords: MS-DOS Kermit 2.31
Thanks, Joe, Kermit 2.31 is wonderful. I have noticed some minor problems
with 2.31 though. First the set up:
IBM-PS/2 Model 30, DOS 3.3, DEVICE=ANSI.SYS, FILES=20, BUFFERS=20
Kermit 2.31
We have an IBM 3081 that we connect to via a 7171. Our script file takes us
to the opening screen and leave us there. The last 2 lines of our script
file are:
TAKE IBM.INI ; Our keybindings file
CONNECT
The first problem has to do with connect. After a script executes and it
does a connect it starts with a clear screen. Apparently any data arriving
while we are defining keys is being stored somewhere besides the screen
buffer. When it connects we get a clear screen. To circumvent this
problem, the script file was changed to read:
TAKE IBM.INI ; Our keybindings file
OUTPUT \7 ; ^G causes the 7171 to repaint the screen and make sure
; that the keypad is in application mode.
CONNECT
In 2.30 this did not seem like a problem.
The second problem is really just an annoyance. If you have set your screen to
a non-white on black and you get into kermit and take a script file, sometime
between the last input/output command and connect command the screen flickers
white on black and then after the connect command it is ok. (Probably the
output \7 causes the 7171 to send an escape sequence to Kermit and it
reinstates the colors. Up to this point, all local kermit i/o was in the
non-white color. Upon exit of the script (ALT-X from connect) the local
kermit i/o is in white and any subsequent scripts/connects etc. are in white.
Sometimes if I immeditaly execute another script file the connect mode is in
non-white, but sometimes it isn't. Regardless, when I return to DOS, it is
back to white again. Like I said, not a problem just annoying. It may be
tied to the first problem.
The third problem is a bit more severe, but may not be a Kermit problem as
much as a PS/2 model 30 problem, however I have only noticed it in Kermit.
In the unlikely event that I have CTRL, SHIFT down and I press Left arrow and
mis-hit and probably hit several keys with my short stubby fingers, all of the
lights flash on the keyboard and it locks up. I am thinking that it is a BIOS
problem since it happened last night when I was in Turbo Pascal, but it didn't
lock the keyboard. I don't know what keys I hit to cause it, but my left hand
was in the vacinity of the LEFT shift, LEFT CTRL area and my right hand was in
the area of the editing keypad.
One other note and question. I was trying to transfer some stuff between my
PS/2 and my AT&T PC6300 at 115600 baud. The AT&T could not handle it. The
machine rebooted once and another time the SERVER on the AT&T would not respond
and we had to reset it. Slowing it down to the next lower baud rate worked
(56Kbps). Could it be the wierd AT&T bios? (By the by, the AT&T has the same
processor as the PS/2 8086 8Mhz)
Thanks,
Rob Miracle | Bitnet : RWMIRA01@ULKYVX CIS: 74216,3134
Programmer/Analyst-II | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu
University of Louisville | UUCP : ...psuvax1!ulkyvx.bitnet!rwmira01
"Incompetence is not an excuse." -- Anton Devious
[From jrd - Quote above is removing my favorite cover! Scripts and Connect:
These share a common buffer for the serial port but once a script command
draws from it the data are no longer available for Connect displays. The
OUTPUT and PAUSE commands read from that buffer to helpfully echo material
from the host and they keep doing it until there is 10 milliseconds of no
new incoming characters (10 millisec was needed for some modem responses).
Otherwise, Connect mode and scripts are not related.
Screen coloring: If the host sent an escape sequence such as ESC [ number m
then ANSI.SYS, or equivalent, if installed will see and react to it. There
is nothing Kermit can do about such DOS level activities.
Multiple keys on PS/2 Model 30s: I agree, it seems like a machine problem.
Superspeed and AT&T 6300's. I can't say much about that machine because one
was available to me for only one evening some time ago. Selected IBM PC clones
can run Kermit at 115KB, and I've never encountered a system corruption
problem with those which can't make that speed. I second the motion that the
Bios may be unusual.]
------------------------------
Date: Fri, 19 Aug 88 17:35 MDT
From: Pete Klammer 303/556-3915 <PKLAMMER%CUDNVR@vaxf.colorado.edu>
Subject: Re: MS-Kermit v2.31 Eats Nulls
Keywords: MS-DOS Kermit 2.31
May I second that emotion? It may be a misuse of KERMIT, but that's the way
life with tools is. Many's the time I wish to get a good log of exactly
what's spitting out some serial path, nulls and all. I respectfully request
that NULL and RUBOUT filtering be selectable.
--poko
[From jrd - Alas, there is no happy middle ground since most people use logs
to record worth while text for later editing and printing but many editors
cannot cope with NULLs. Also, these characters are frequently used as padding
so passing them quickly fills the serial port holding buffer; the reaction to
that was annoyance about performance when it was done as an experiment. We
have the idea that they should be displayed when DEBUG is ON, but not logged;
However, most releases have removed NULLs completely anyway. I'd suggest that
you make the simple changes to the sources to pass all the characters of
interest; see file msxibm.asm.]
------------------------------
Date: Tue, 23 Aug 1988 16:27:47 LCL
From: David Boeshaa <BOESHAAR%SUVM.BITNET@cuvmb.cc.columbia.edu>
Subject: MS-Kermit and the Novell File Server
Keywords: MS-DOS Kermit 2.31, Novell File Server
Greetings! and Grief!
I have been working with KERMIT 2.3x for some time and I think it is GREAT!
but I have a small problem with 2.31 15 Aug 1988.
We are running KERMIT from a Novell 2.0a file server and every download
gives the message "Not Enough Disk Space for File" but then downloads the
file anyway. I think this may be related to the new file size checking
(we have not EVER had this problem before and we are still running
2.31 17 July 1988 without grief).
Thanx and Thanx for a GREAT product!!!
David K. Boeshaar ACADEMIC COMPUTING SERVICES
______ SYRACUSE UNIVERSITY
/ | -------
| | BITNET: BOESHAAR@SUVM.BITNET
_________/ | NOISENET: (315) 443-3166
| * | SNAILNET: 215 Machinery Hall
/ SYRACUSE | Syracuse, NY 13244-1260 USA
|______________ |
|_ | Disclaimer: Any sufficiently advanced technology
|__| is indistinguishable from magic.
[From jrd - a known bug, fixed in the middle August update for IBM PCs. There
is a similar problem if the file destination is the screen or printer; fixed
recently but not in time for the update above. Sorry about that.]
------------------------------
Date: Mon, 15 Aug 88 21:05 EST
From: "Frank Rens" <RENS%UBVMS.BITNET@CUVMB.CC.COLUMBIA.EDU>
Subject: Re: MS-Kermit 2.31 Tabs Bug (Feature?)
Keywords: MS-DOS Kermit 2.31, Tabs
I have the same problem with the TABS being cleared by a CLEAR. Here's the
script...The tabs are OK before the clear but not after.
[Ed. - Script omitted.]
[From jrd - I finally found the bug: an uninitialized register at one place
which could (but never here!) clear the tab storage area when the CLEAR cmd
was issued. Fixed in the middle August maintence release for IBM PCs.]
------------------------------
Date: 24-AUG-1988 12:38
From: IN%"SYSKERMIT@VAX1.LANCS.AC.UK"
Subject: MS-Kermit: Five Bugs and a Whinge
Keywords: MS-DOS Kermit 2.31
Syskermit & Columbia:
I have recently made extensive use of MSKERMIT (various releases)
running on an XT-Clone while developing a new Kermit for a UK (Research
Machines) Micro. Obviously, I have been putting it through quite a lot of
hoops while testing my own code's reaction to error-situations and various
sequences of events. I have encountered the following five problems, which
are guaranteed not to be caused by misrunning of my new RM Kermit. They
have been identified while running at various speeds, on a short direct
"null-modem" wire connecting the two micros, with the MSKermit in normal
(not server or back-port) mode. Parity has in all cases been set to Even.
The clone is running MSDOS 3.20.
The different errors have different incidences in different releases
of MSKERMIT. See table below.
1. Unable to Resume Binary Mode.
When first loaded, MSKermit will happily transfer files in binary
with 8th-bit quoting. If a file is then transferred in 7-bit non-binary
mode, MSKermit will never revert to 8th-bit-quoting. It simply sticks
an "N" into the spar/rpar packet, no matter what it has been sent or what
command you give it. Main tests caried out while receiving, but I think
it is true in all circumstances.
[From jrd - I'm a little confused. MS Kermit lacks the concept of a 7-bit
non-binary mode transfer since there is no way within DOS to tag files as
binary or not. The conditions to use 8-bit quoting are the local side uses
parity plus the other side agrees on 8-bit quoting, or the other side requests
the quoting. However, I ran a series of tests and found that indeed Kermit
could remember an old 8-bit quoting state and then later respond with the 'N'
above (for No Can Do). Tracked down and fixed this past weekend. Thanks.]
2. Not Displaying Early E-Message.
If MSKermit is receiving and the other end sends an E-packet before
sending the F-packet, then this is not displayed in the "Last Error"
field. The packet is received OK, and can be seen as "Rpack" if debug
is switched on. (The error in question is, of course, "File not found";
this does not occur on most Kermits as they check for the presence of the
file before sending the S-packet.)
[From jrd - True, the packet type test had the code to do this but it was
not reached because an earlier test would fail to the file complete code
rather than the error handler code. Safe, but it omitted the error message.
Fixed now. Thanks.]
3. DEL *. Doesn't Work.
If the default disk has on it files which have no extension to their
names, then although they are correctly displayed in response to the command
"dir *.", the command "del *." gives the response "?Protected or no such
file(s).". "del a:*." gets the same response, but "del x*." works OK
(assuming there are files whose names start with "x").
[From jrd - That's a DOS characteristic since Kermit merely composes a DOS
command line with DEL followed by the user's filespec and submits the works
to COMMAND.COM. MS Kermit 2.28 and predecessors used FCBs and did deletion
file by file within Kermit; starting with 2.29 all FCB material was removed
and COMMAND.COM was employed. Compare results of these commands between
giving them within Kermit and then at the DOS prompt.]
4. F3 Setting Gets Lost.
When MSKermit is loaded and then cancelled by "Quit", if only Kermit
commands have been entered, then F3 causes MSDOS to repeat the command used
to load Kermit. However, if a DOS-type command is given at the Kermit-MS>
prompt (e.g. dir or del), then, after quitting, F3 brings up a null command.
[From jrd - DOS again. Kermit reads the keyboard at both DOS and Bios
levels. When DOS does the work the DOS typeahead buffer can be flushed.
Kermit, and probably most programs, make no effort to restore the contents
of the typeahead buffer private to DOS. This is not a fault.]
5. Hitting RTN Kills the System.
This is caused by hitting RTN [Return, Enter] unneccessarily and
repeatedly during normal running. Tests were done during a receive, but I
think it happens during send as well. You have to hit RTN quite frequently,
and MSKermit sends a NAK each time you do. Eventually an unpredictable loss
of status occurs. In the table below "Clean" means that you get back to a
Kermit-MS> prompt, and can continue (except you will find that there is a
packet or part of one in the input buffer). "Bad" means that, if you do get
back to a prompt, then you cannot continue, and when you quit you find MSDOS
won't work; or the display may go wild. If the display goes wild, then the
keyboard is quite dead. If you are able to quit, then the MSDOS disk-driver
has been overwritten in such a way that any attempt to use any disk gets the
"not ready error" response. (The details of this may depend on the nature
of the Clone, since I have had the same trouble with a completely different
communications program on the same machine.)
[From jrd - that's not happened on any of my clones. I can hold down the
Enter key and let it auto-repeat with no ill effects except the packet
retry count goes the exhaustion limit. If a keyboard helper or an unusual
Bios does not preserve registers in a standard way (Kermit is reading keys
via DOS during packet transfers) then disaster can strike any program. DOS
stack overflow can also occur under some versions of MS DOS. Similarly,
'adjusting' DOS's typeahead buffer can lead to wild results when that buffer
overflows. The problem has not been reported by others.]
6. Where's MSKERMIT.INI?
This is really a whinge rather than a bug. If MSKermit is not on the
default disk, i.e. you load it by a command such as "b:kermit", or get it
picked up by being in the PATH, then MSKERMIT.INI is not picked up even
though it is on the same disk as MSKermit has been loaded from. This is
true of all versions; and for all I know it may be impossible in MSDOS to
find out what disk the program has been loaded from.
[From jrd - Kermit does not know from which disk or directory it has been
loaded. The manual states that Kermit searches for MSKERMIT.INI, and Take
files, first in the CURRENT directory and then if necessary along the PATH=
string. DOS 2.X lacks the ability to inform a clever program about its
loading source. Thus, if the current disk were say C: and Kermit were loaded
by C> b:kermit and then the search would not include drive B: unless it were
stated in the PATH= string.]
Here is the incidence of bugs 1 - 5 in the different releases:-
\.
\. Bug: Text/Bin E-Message DEL *. RTNs F3
\.---- -------- --------- ----- ---- --
\.
Version \
------
2.26 No OK OK Clean Lost
(undated)
2.28 No OK OK Clean Lost
(undated)
2.29c No OK No Bad Lost
(23 Aug 87)
2.30 No OK No Bad Lost
(8 Jan 88)
2.31 No No No Bad Lost
(1 July 88)
I hope this is of some use to you. The only one which seems to me to
be at all serious is the inability to revert to binary-quoting after running
in text-mode.
Chris.
------------------------------
Date: Fri 26 Aug 88 16:39:07-PDT
From: Ted Shapin <BEC.SHAPIN@ecla.usc.edu>
Subject: Goto Label Bug in 2.31 August 15?
Keywords: MS-DOS Kermit 2.31, GOTO
I can't get this version of Kermit to recognize labels in loops?
This doesn't work:
set count 3
:TOP
echo Hello\13
if count goto top
echo Goodbye\13
Ted.
[Ed. - Yup, it's another bug in the label-finding code. A quick workaround
is to append a space to the label, followed by a comment, as in
:TOP ; (of loop)
Thanks also to B. Schneuwly, Joellen Windsor (an early Kermit developer!),
and others who reported this problem. Joellen also discovered the following
interesting workaround:
define %b loop
:loop
echo test
goto \%b
The problem should be fixed in the next release.]
------------------------------
Date: Wed, 31 Aug 88 14:38 GMT
From: <SCHNEUWL%CZHETH5A.BITNET@cuvmb.cc.columbia.edu>
Subject: Problems with MS-Kermit 2.31 Graphics
Keywords: MS-DOS Kermit 2.31, Olivetti
We have problems with Kermit 2.31, dated 15 Aug.
[Ed. - Loop label report omitted, see above.]
Graphics is another problem:
On a Olivetti M24 we don't get the same high(er) resolution display
as with MS-Kermit 2.30.
[Ed. - If Kermit can't automatically recognize your screen's resolution, use
the SET TERMINAL GRAPHICS ATT command. The next release should recognize
the Olivetti automatically.]
Furthermore I'd like to have the possibility to control whether the TEK4010
emulation does merge it's text with already existing pixels or does overwrite
as in 2.30.
[Ed. - Noted.]
------------------------------
Date: Wed, 31 Aug 88 12:17 MST
From: <JWINDSOR%ARIZRVAX.BITNET@cuvmb.cc.columbia.edu>
Subject: MS Kermit 2.31 File Dates
Keywords: MS-DOS Kermit 2.31, Attributes, File Dates
I am running MSKERMIT 2.31 dated August 15, 1988, on a PS2 model 50 under
MS-DOS 3.30. I have noticed the following 2 problems:
(1) [Ed. - Loop label problem report omitted, see above.]
(2) All files shipped to my PS2 from my VM/SP mainframe have the correct
creation date but they all have 12:00a for the creation time. This appears
to have been a problem with the July 1 version, too.
[Ed. - This is because VM/CMS Kermit reports the creation date but not the
time of creation, so MS-Kermit uses midnight.]
Joellen Windsor
Systems Programmer
------------------------------
Date: Fri, 29 Jul 88 22:40:53 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Subject: Kermit Through Protocol Converters Under CMS
Keywords: Kermit-370, Protocol Converters
Kermit-370, as released for CMS last winter, contained code designed to
allow file transfer through a variety of terminal emulators other than the
"usual" Yale ASCII type (Series/1, 7171, 4994, 9370 ASCII subsystem). The
code was, in fact, modelled after similar code that was demonstrated under
TSO, but I haven't heard any reports of success under CMS, and the only
negative report was for a device that hadn't been tried under TSO. I would
like to hear from anyone who has any kind of 3270 emulator other than the
Yale type (and other than the 3708, which is known to work with Kermit
already). The particular types of emulators which might be expected to work
include the MICOM 7400, the Datastream/Leedata 8010/8030/874 models, the PCI
1076 and 276, and possibly the Renex TMS-1. Any others which claim to
support a "graphics passthrough" mode are also likely candidates. I would
be interested in any results of trying Kermit with such emulators, whether
positive or negative (be sure to SET CONTROLLER GRAPH to the mainframe
Kermit before starting the transfer). Actually, I now have an update that
automatically detects non-SERIES1-type terminals and also some other updates
that may help in diagnosing the problems if the existing code should prove
not to work "as is."
[Ed. - John has done an amazing job with Kermit-370, but need help from
people who have equipment that he doesn't have access to. Any cooperation
will be much appreciated! Meanwhile, John is preparing a large batch of
updates to Kermit-370 for release -- watch Info-Kermit for announcements.]
------------------------------
End of Info-Kermit Digest
*************************
-------