SY.CHRISTINE@CU20B.COLUMBIA.EDU.UUCP (02/19/87)
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 20
Enter definition: z
and
set 4455 kexit
could be entered as:
set key
Press a key: <Alt-X>
Scan code is 4455
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
*************************
-------