info-kermit@ucbvax.ARPA (06/28/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Thu, 27 Jun 1985 Volume 2 : Number 39
Departments:
ANNOUNCEMENTS -
BITNET KERMSRV Reorganized
IBM VM/CMS Kermit in Pascal
MISCELLANY -
MS-Kermit 2.28 H-19 Emulation for IBM
Kermit Talk at National Prime Users Group
Kermit-TSO and the IBM 7171 Front End
About Commodore 64 Kermit V1.6
Apple II Kermit Status
C-Kermit Line Locking Problems, Cont'd
C-Kermit Problems: HP-9000, Racal-Vadic Modems, etc
----------------------------------------------------------------------
Date: Thu 27 Jun 85 13:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: BITNET KERMSRV Reorganized
BITNET users who get files from the Kermit file server, KERMSRV at CUVMA,
will notice that the BITNET Kermit distribution area has been split in two
in the same way as the CU20B area, as described in Info-Kermit V2 #33.
Those who may have missed the announcement are encouraged to read the file
KER:AAAUPD.HLP on CU20B (AAAUPD HLP on KERMSRV) to see what was done. In
particular, it should be noted that all the "bureaucratic" files (like lists
of versions, flyers, order forms, etc) have all been renamed to have names
starting with AA.
------------------------------
Date: Fri, 7 Jun 85 16:47 EDT
From: VIC@QUCDN.BITNET
Subject: IBM VM/CMS Kermit in Pascal
I have just sent you an updated version of my Pascalvs version of
KERMIT-CMS. This version eliminates the use of the LINEMODE call and
thus can be run as a self-contained module and should work with any
other Kermit without modification. There is a quick comparison of the
Assembler and Pascal version below.
COMPARING ASSEMBLER AND PASCALVS KERMIT FEATURES.
CMS Kermit Capabilities : ASSEMBLER PASCALVS
Local operation: No Yes
Remote operation: Yes Yes
Transfers text files: Yes Yes
Transfers binary files: Yes Yes
Wildcard send: Yes Yes
^X/^Y interruption: Yes Yes
Filename collision avoidance: Yes No
Can time out: No No
8th-bit prefixing: Yes Yes
Repeat count prefixing: Yes Receiving only
Alternate block checks: Yes Yes
Terminal emulation: No No
Communication settings: No No
Transmit BREAK: No No
Transaction logging: Yes No
Session logging: No No
Raw transmit: No Yes
Act as server: Yes Yes
Talk to server: No Yes
Advanced server functions: No Yes ****
Advanced commands for servers: No No
Local file management: Yes Yes
Handle Attribute Packets: No No
Command/init files: Yes No
Command macros: No No
**** Advanced server commands DIR,ERASE,and TYPE have been
implemented. All of the advance server functions will
respond if only to tell you it has not been implemented.
[Ed. - The files are in KER:CM2*.* on CU20B available via anonymous FTP
and as CM2* * via BITNET KERMSRV.]
------------------------------
Date: Wed, 19 Jun 85 17:36:58 pdt
From: tweten@AMES-NAS.ARPA (Dave Tweten)
To: Info-Kermit@CU20B
Subject: MS-Kermit 2.28 H-19 Emulation for IBM
MS-Kermit 2.28 msyibm.asm seems to have a bug, and what I interpret as
two "misfeatures".
The bug is that a line-wrap which requires a scroll-up does not produce
the scroll. As a result, the wrapped portion of the line overwrites
the first part for as many wrappings as are required. I observed this
by running "vi" on our 4.2 bsd system, using MS-Kermit 2.28 in H-19
emulation mode. I viewed a file with long lines. Line-wrap in the
middle of the screen worked properly. So did scroll-down (backward)
through multi-line lines. However, when I had "vi" scroll-up (forward)
through the file, each multi-line line that entered at the bottom of
the screen overwrote itself. When I used ^L to tell vi to repaint the
screen, overwritten lines were displayed correctly. When I repeated
the test, using MS-Kermit 2.27, everything worked correctly. I haven't
yet had time to find the source of the problem.
The first of the "misfeatures" is the addition of line-wrapping backspace.
My copy of the H-19 Operation Manual says clearly (on page 12) that
backspace:
Moves the cursor one space to the left. If the cursor is at
the start (left end) of a line, it will not move when you type
a BACK SPACE.
I believe that if Kermit is going to be advertized as emulating an
H-19, it ought to do so. I don't think this is a very serious
deviation, though, because I can't imagine a program sending a useless
backspace, confident that the H-19 will ignore it. Still, why
introduce incompatibilities?
The other "misfeature", though, is serious. H-19s will work in either
native or ANSI mode. Almost all of Kermit's escape sequences are from
the native set. Kermit's new "Enhanced Character Support" sequence
(ESC [ p1 ; . . . ; pn m) is the sole exception, being an extension of
one from the ANSI set. Unfortunately, it conflicts with the native set
"ESC [" sequence (Enter Hold Screen Mode), which is not implemented in
Kermit.
Both sequences are correctly interpreted by a real H-19 because it has
two more sequences which are not implemented in Kermit, "Enter ANSI
Mode" (ESC <), "Enter ZDS Mode" (ESC [ ? 2 h). To implement "Enhanced
Character Support" correctly, without stumbling over "Enter Hold Screen
Mode", the sequence should be honored only in ANSI mode. That would
require it to become "ESC < ESC [ p1 ; . . . ; pn m ESC [ ? 2 h". I
don't think the sequence is worth it without a general implementation
of ANSI mode.
One very good reason for Kermit to emulate an H-19 is that many systems
believe they already know about H-19s. If this advantage is not to be
lost, Kermit must stay as close to the H-19 as possible.
------------------------------
Date: Thu 20 Jun 85 13:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Re: MS-Kermit 2.28 H-19 Emulation for IBM
One of our problems is that we don't have a real H19, and the H19 manual
that we once had has disappeared (anybody want to donate one to the cause?).
Our PC's get used a lot as terminals to our IBM mainframes, and it is common
on those machines to display files that contain lines a full 80 characters
long, with a CRLF at the end. If you don't suppress LF after autowrap, then
these come out looking double spaced. We made the change mainly to make our
IBM mainframe users happy. Since this is inconsistent enough with the H19
definition to break "vi", we'll have to back out of this change; the next
release (2.28a, which contains fixes to the most glaring problems with 2.28,
namely the "get" filename truncation and the segment reordering) will
have this feature put back the way it was -- should be ready within a week
or so.
Having backspace wrap to the previous line was a suggestion from Greg Small
at Berkeley; I don't remember his motivation (Greg?). Aside from the the
fact that this deviates from the H19 definition, can you think of any
functional reason not to do it?
We thought about the ANSI mode business a bit before we put it in. It was
added because we needed the different kinds of highlighting for use with
3270 protocol converters (front ends for our IBM mainframes). We noticed
that there was a potential conflict between native ESC [ and the ANSI
lead-in sequence. But, we reasoned, since we don't support native ESC [
(can you think of any software that would send a hold screen command?), and
since we ignore unknown escape sequences (like Enter and Exit ANSI mode),
and since we're not trying emulate an ANSI terminal in all its glory, we
figured that no harm would be done. If some software wants to use the
character highlighting and does that by sending "ESC < ESC [ p1 ; ... ; pn m
ESC [ ? 2 h" then it will work just fine. It will also work if they just
send ESC [ p1;...;pn m by itself. If they really want to send a hold screen
command, it will have no effect (unless, I guess, the following characters
can be interpreted as p1;...pn m). But then, will any software that exists
ever actually send a hold screen command? You'd think that if the software
did not want additional characters to be displayed on the screen, it would
simply not send them, but perhaps I'm naive...
I realize these are touchy issues, but in my view the H19 emulator in Kermit is
just a stopgap. Soon, we expect to have a fully functional ANSI (VT102)
emulator available in the form of a loadable console driver, separate from
Kermit but distributed with it on the same terms. At that point, I think the
H19 code will become superfluous and will eventually wither away.
- Frank
------------------------------
Date: Sat 22 Jun 85 04:00:45-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Kermit Talk at National Prime Users Group
To: info-kermit@CU20B
A talk was given at the National Prime Users Group (NPUG) in Saint Louis
this week entitled "Kermit on the Prime: One shop's experience" by
Harvey J. Friedman of the International Pacific Halibut Commission.
The bug in Prime Kermit discussed in the talk was configuration dependant,
it only affects systems with printing characters for erase and or kill.
(It is also documented at Columbia in a .bwr file, but that file is not
in the distribution from Pulse (Prime users library...))
Apparently there is a need to cooridante the Pulse distribution with the
Columbia distribution. I have heard that there is a new version on Pulse
that supports assigned lines.
Bob Larson <Blarson@Usc-Ecl.Arpa>
[Ed. - Prime Kermit has always been one of the most difficult to manage.
Another problem has been that Prime computers can't read any of the tape
formats in which we distribute Kermit, including ANSI labeled ASCII (the
standard format for information interchange agreed upon by all major
manufacturers). Finally, in desparation, people in Prime's New York office
wrote a short Fortran program to read ANSI tapes, and we have to include a
copy of it on paper every time we send a tape to a Prime site. Even if
Prime refuses to support industry standard tape formats, you'd think the
user group (Pulse?) could solve problems like this.]
------------------------------
Date: Wed 25 Jun 85 11:51:32-EDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: Kermit-TSO and the IBM 7171 Front End
To: Sy.Daphne@CU20B.ARPA
I have the TSOS1.ASM file and it works fine with the Series/1. But when we
replaced the S/1 with an IBM 7171, we started having problems. The problem
was that when you were uploading to the TSO host, the file transfer would be
hung at random places. When I used the debug option, on TSO kermit, I found
that the transfer would stop right after the first CHECKSUM error.
Downloading works fine, and KERMIT is able to handle CHECKSUM errors just
fine, but when uploading, it just stops. I was wondering if anyone else was
experiencing problems similar to my, and if so, if anyone was going to add
support for the 7171 in the next release of KERMIT-TSO.
wing
------------------------------
Date: Wed 26 Jun 85 11:51:32-EDT
From: Daphne Tzoar <Sy.Daphne@CU20B.ARPA>
Subject: Re: Kermit-TSO and the IBM 7171 Front End
To: WingLee%ECLD@USC-ECL.ARPA
It sounds like the problem you are having should be a protocol issue and
shouldn't be related to whether you are using a S/1, 7171 or 4994. I'm not
sure why a bad checksum should affect the upload to TSO and not the download
from it. But, I will forward your message to Info-Kermit and the author of
the S/1 TSO Kermit. /daphne
[Ed. - To the best of our knowledge, the new VM/CMS Kermit works equally
well through straight ASCII async tty connections through 3705 and
equivalent front ends, through the Series/1 (4994?) front end doing 3270
protocol conversion, and likewise the 7171 front end. We hope that someone
at a TSO site will find a way to convert VM/CMS Kermit to TSO in such a way
that it can be built for either VM/CMS or MVS/TSO, either by conditional
assembly or by moving system-dependent primitives to a special module,
like C-Kermit or MS-DOS Kermit. Then, whenever the program gets fixed or
improved, everyone will benefit at once.]
------------------------------
Date: 26 Jun 85 19:08:07 EDT
From: Eric <LAVITSKY@RU-BLUE.ARPA>
Subject: About Commodore 64 Kermit V1.6
I neglected to include a suitable .INI file in the kermit distribution,
which is losing since it really needs an init file right now to startup in a
sane manner. You can instruct people with older versions of kermit to
download this file as an ascii seven-bit file before starting up the new
Kermit.
[Ed. - This file is now in KER:C64KER.INI on CU20B. It contains a strange
looking sequence of control characters -- don't be alarmed when you see them.]
By the way I thought I'd take this opportunity to address some of the
questions you've been sending my way lately (I've been really busy with a
new job and all):
Using C64 Kermit with a tape drive:
Very simply put, you can't. That is not without adding to the program and
not without huge delays in transmission. The C64 operating system uses the
same memory locations for the RS232 routines and the tape drive timing (both
of which are critical). I do *not* plan on adding any support whatsoever
for the tape drive.
Using Kermit with the C128 (no one's asked yet, but just in case):
It should be easy to use Kermit in C64 mode on the C128. There *should*
also be no problem with using it in 128 mode, but it would make more sense
to use the native screen mode for 80 columns. Since I don't have a 128 (and
don't plan on getting one), I cannot evaluate what is necessary to take
advantage of this. Anyone else who is interested in doing this should feel
free to give it a crack. The C128 should work nicer in native mode due to
the faster disk drive. On the other hand, you may just want to use CP/M
Kermit on it.
Eric
------------------------------
Date: Thu 27 Jun 85 00:20:45-EDT
From: Peter G. Trei <OC.TREI@CU20B.ARPA>
Subject: Apple II Kermit Status
>Date: Mon, 24 Jun 85 14:09 MDT
>From: "Mike Armstrong {mba}" <Armstrong@UNCA-MULTICS.MAILNET>
>Subject: Apple 2 kermit
>Would you please tell me the current status of the Apple 6505 version of
>kermit. The latest version I have is V2.1 (V2.1A??) updated 30-JUL-84
>by Peter Trei (original by A.N.J. Moine)
Version 2.1a is still the latest released version. Development has is
currently rather slow: both Anton's and my real-world workload have
substantially increased in the past year, and I have been able to do rather
little for 4-5 months, and Anton none. (I am still distributing several
copies a week by mail).
If you feel like contributing code, my only request is that you inform me
and Anton about it before you start, to advoid duplication of effort.
Outstanding desired features and bugfixes include:
[Ed. - Anton indicates that he is out of the Apple II Kermit business now
and Peter should be regarded as the sole proprieter.]
1: On Apple 2c's, the cursor produces a bogus character when placed
over a lowercase alpha character. (Its ok after you move again).
2: Command files, so you can set up and dial your kermit more easily.
3: Support for the Videx and Apple 2c/e 80-column cards. (This is more
easily said than done. If you want to know why, ask me.)
4: Support for more varieties of serial interface (my current project).
5: A better bootstrapping procedure.
6: Server capability (a real toughie, since most apples have no clock).
7: VT102 emulation.
8: ProDos kermit. I am currently awaiting the arrival of my
order for a 'native code, optimising, ProDos Pascal compiler'.
6502 assembler can be macho, but its also a pain in the b*tt.
If you feel like taking any of these on, please tell me about it. I have a
number of ideas (and some code) for most of them. Everything being equal, I
expect to have a release out late summer/early fall with at least 3 and 4
fixed, more if possible.
>I am looking for a version that, in addition to the capability of V2.1,
>also handles the 80 col screen card and has the "insert-line",
>"delete-line", "delete-chars" and the "insert-chars"/"end-insert-chars"
>capability in the terminal emulation (for use with Multics full screen
>editing and menu features). Kermit65 acting as a server would also be
>very nice. However I don't have access to a Dec Tops/20 system to run
>the CROSS assembler so I cannot modify the source. (And I'm not
>convinced of my capability of doing it properly anyway.)
This is the VT102 emulation I mentioned earlier. I agree, it would be nice,
and I would like to include (I use Emacs too).
>Mike Armstrong - Honeywell, Canada (from University of Calgary's Multics
> system).
Peter Trei
oc.trei@cu20b
h: 212-5692371
w: 212-8153711
------------------------------
Date: Wed, 26 Jun 85 20:52:43 pdt
From: Scott Weikart <cdp!scott@Glacier>
Subject: C-Kermit Line Locking Problems, Cont'd
Instead of setuid, I think it would be much better to operate setgid. Then the
ownership of the lock file would be intact. I put uucp, cu, kermit, etc in a
group called dialer, for such situations. But then you have to convince your
administrator to allow /usr/spool/uucp to be writable by group (in my opinion,
this is much safer than making kermit setuid, especially if you keep regular
users out of the group). This has one annoying side-effect; kermit will no
longer be able to create a file in a directory that's not writable by the user
but is writable by the group that the user's shell is in [this is fixable for
system 3 and 5 - i'll send the code along - but not in v7 or BSD].
Another thought; if you did something like the above which would allow the user
to own the lock file (or if you write the uid into the lock file), then maybe
you could do the following to do a multi-stage kermit. start up a kermit,
connect, pop back to kermit and fork a sub-shell, then allow the user to start
up another kermit as long as she owns the lock file. I think this will work,
even though the original kermit still has the tty open. The user would not be
able to log out without exitting the original kermit. Of course, once the user
pushes a subshell she might forget about the open line until she logs out; it
would be nice to change the prompt in the subshell, but i'm not sure how to do
it in an exec.
[Ed. - Further contributions to this discussion are welcome. If the WHOLE
WORLD can come to a concensus about how Unix line locking should work, we can
make the program abide by it. But then somebody has to write the installation
manual, the user manual, and the environmental impact statement...]
------------------------------
Date: Thu, 27 Jun 85 15:22 EDT
From: WIBR@MIT-MULTICS.ARPA
Subject: C-Kermit Problems: HP-9000, Racal-Vadic Modems, etc
I was able to get the kermit package working on our HP-9000's. They
have a problem, however. I can call a foreign host (even myself),
login, run kermit on the foreign host and get files from the foreign
host OKAY. However, when I try to send stuff to the foreign host, I
have problems with packet sizes larger than 70 characters. I viewed the
data flow through the modem with a protocol analyzer and it seems that
everything looks okay: the sender keeps resending packets that are
NAK'ed by the foreign host. Even with packet sizes of 70, the sender
has to resend each packet something like ten times. At packet sizes of
around 40, the situation is much better. i don't THINK my lines are
excessively noisy (running "log packets" on either machine seems to
support this), but I'm confused.
[Ed. - Sounds to me like HP-UX has small input buffers for its serial
ports, and can't accept bursts longer than 40-70. Not much you can do about
this short of fooling with the kernel, or complaining to the vendor.]
Another thing: we have racal-vadic modems that do not conform to the
protocol that ckudia.c employs. Apparently, the old Racal Vadic's used
to send "ON LINE", and the new ones (at least the Maxwell series, as
well as the -PA and -PAR series) send "ONLINE" (your code searches for
"ON LINE"). Secondly, your code "acknowledges printout of dialing string"
by sending an extra <CR> after "(number)<CR>" when dialing the number.
The old Racal Vadic's required the extra <CR> --- the NEW ones, however,
do not. IN FACT, the new ones abort the dialing sequence when they
receive the extra <CR>.
Obviously, I had to change these two things when I wanted to get kermit
working -- I felt you might want to pass some of this information on to
others. The "ON LINE" vs. "ONLINE" discrepancy is not guaranteed by
Racal Vadic to be cleared up: some models MIGHT use one, and others
might still use the other. The business with the extra <CR> will go
away: I was guaranteed that Racal Vadic's won't require it from now on
(the newer models, that is).
[Ed. - Yuk. I guess this means we another modem type has to be added to
ckudia.c -- "NewRacalVadic". Alternatively, the code can be changed to do
something like what is done for the Hayes, which also has two ways of
answering ("verbal" and "nonverbal") -- feed it some innocuous command whose
response will tell you if it's a new or old style modem, and then set a flag
to that effect, which is used to control further interactions with it. This
method is preferable to simply adding "NewRacalVadic" as another modem type,
because how is the poor user to know whether her Racal-Vadic is new or old?]
One question: is there any effort by you folks to support Codex short-
haul modems in the near/distant future? Is there any perceived need?
(actually, I guess that's two questions)
[Ed. - The new ckcdia.c module is much easier to add new modems to than the
old one was, thanks to reorganization by Dan Schullman. Dan is currently
working on yet another release of that module; when that's ready, I'd
encourage you to add support for "NewRacalVadic" and "Codex" to it and send
it back to us.]
Thanks for your help. ---Matt G.
------------------------------
End of Info-Kermit Digest
*************************
-------