[mod.protocols.kermit] Info-Kermit Digest V4 #11

SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (02/14/86)

Info-Kermit Digest         Thu, 13 Feb 1986       Volume 4 : Number 11

Today's Topics:
                MS-DOS Kermit 2.29 Not Forgotten
                  Re: MS-Kermit path suggestion
                     Problems with MSKERMIT?
                        Okstate Downtime
                            C-Kermit
                   THE FROG for 64-bit CDC's?

----------------------------------------------------------------------

Date: Wed 12 Feb 86 09:51:36-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: MS-DOS Kermit 2.29 Not Forgotten

In case you've been wondering what ever happened to MS-DOS Kermit 2.29,
or missed the earlier announcements of 2.28 jrd, 2.28 jrd/2, etc, here's
a brief status report.

Joe Doupnik at Utah State University (connected to us by BITNET), has been
putting an incredible amount of work into the forthcoming release (considering
that he, like all of us, has a "real job" to do as well).  He now has a
remarkably complete VT102 emulator built in to the program, without having
sacrificed the Heath-19 emulator.  In fact, since VT52, H19, VT100, and VT102
are all so closedly related, he's got them all in there.  Several test versions
of this have gone back & forth (well, mostly forth), and the last remaining
nits are being picked, with the terminal emulation as well as fine points
relating to operation under TopView, MS Windows, PC Network, with EGA board,
etc.  It seems that the fine points are what take the time (the old 80/20
rule) and raise the most hackles.

Once the nits are quelled (parents of young children will understand this
allusion), the final job will be to get the program working again on the
non-IBM MS-DOS systems -- Rainbow, etc.  I think the best idea is for us to
provide .EXE and .BOO files for those systems we can test (IBM family,
Rainbow, HP-150), and leave the others alone (at 2.27 or 2.28 level) until
somebody sends us new, tested ones.  So if you have any of the other MS-DOS
systems Kermit claims to support -- NEC APC & APC3, Victor/Sirius, HP110,
Wang, Apricot, Grid, Heath/Zenith, Sanyo, TI Professional, etc. -- please
be prepared to grab the source or object files when they become available,
build and test the new release, and send us a .BOO and/or .EXE file by
electronic mail (or postal mail on IBM PC format diskette), or put them 
somewhere where we can get them with FTP.

And I might as well make my usual pitch about diskettes -- when you have a
new version of Kermit working on your system, PLEASE send it on diskette
to an appropriate user group, "public domain" diskette service, or other
entity capable of reproducing and selling it by mail order at low cost
(what's low?  I'd say under $10 or $20 for a diskette) for the benefit of
all the PC/micro users in the world who don't have tape drives, network
access, or other "traditional" ways to get Kermit on their machines.

------------------------------

Date: Tue 11 Feb 86 10:59:22-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: Re: MS-Kermit path suggestion

I don't think KERMIT is the proper place to make up for missing DOS functions.
I use the public domain DPATH30.COM which lets me search the path for files
to open so I only need one copy of MSKERMIT.INI.  There are other programs
that do the same thing, e.g. IBM`s File Facility in their personally developed
software line.

------------------------------

Date: 0  0 00:00:00 EST
From: "Steven Kaberline (313) 323-2248" <kaberline@ford-vax>
Subject: Problems with MSKERMIT?

I just recently built MS-KERMIT for my Victor.  It works 
great, with the exception that the status line at the bottom 
of the screen is trashed during a "SEND" or "RECEIVE" 
command??  The status line is correct during the "CONNECT" 
mode.  I've tried both the 2.28 and 2.28(jrd) versions, 
they both seem to have the same problem.  The IBM-PC version 
I'm also using does not do this, so it appears to be Victor 
specific?

I also downloaded (from CU20B) the MSVV90.BOO file described 
in the latest Kermit Digest.  When converted to the .EXE file 
and run, it demonstrates the same symptoms.

This is not a serious problem, but it is annoying.  Does 
anyone have any suggestions??

Thanks.

			Steven Kaberline
			Kaberline@FORD-VAX

------------------------------

Date: 11 Feb 86 20:24:58 CST (Tue)
From: vasoll%okstate.csnet@CSNET-RELAY.ARPA
Subject: Okstate Downtime

The Oklahoma State University Kermit Distribution service will not be available
from Saturday, February 15 until Monday, February 17 (if all goes well).  We
are in the process of changing from UNIX Version 7 to UNIX System V (actually
Perkin-Elmer's port of S5 called XELOS).  We anticipate some problems with
the Kermit Server portion of the Kermit service since the server code that we
use is based on C-Kermit 4.2 and the code that we added for path restriction
has never been tested on System V.  The real problem may be in the UUCP portion
of the service.  As I understand it System V is really picky about only talking
to systems that are in your L.sys (or Systems) file and I have not yet received
my System V source license (paperwork!) so I don't yet have the source to "fix"
this "problem" (actually it requires breaking a few features.... sigh..).

I will report back to this list when various parts of the service start working
again (hopefully within a week or so).

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll
ARPA:  vasoll%okstate.csnet@csnet-relay.arpa

------------------------------

Date: 11 Feb 86 18:38:26-MET (Tue)
From: Karl Kleine -- F Z I Karlsruhe <kleine%germany.csnet@CSNET-RELAY.ARPA>
Subject: C-Kermit

  We invested some work in C-Kermit.  base is 4C (050).  though this is
not the very latest, we hope it still is relatively current.

first:  bugs found in porting it to pcs / cadmus.  these are 68010 based
Unix machines running MUNIX, an adoption of System III by PCS.  PCS is a
Munich based German manufacturer of micros, so you know what the M stands for.
its american branch is CADMUS (Boston).  there were no real problems !!!
congratulations to the quality of your code !!! except for some places where
the authors obviously lived on a vax: the old pointer/int problem in C.
arguments to libary routines / system calls were 0 terminated instead of
(char *)(0). this made a difference on our system.  these places were
corrected to use the proper NULL constant.

second: brevity.  we shortend some of the strings printed, particularly in
the connect message.  we also suppress printing script lines unless logging
is active for the following reason:  we regularly connect from a local machine
(pcs) thru a local net (ungemann/bass net/1) to a couple of other different
machines.  mechanism: take files with scripts making the connection and
initiation of logins.  as this often occurs with visitors present we do not
like to have it all echoed on the screen -- there are some malvolent hackers
around, i'm afraid.

third: for the same setup as explained above we added the feature to supply
an alternate startup file instead of .kermrc as last [and usually only]
command argument.  i just type  kermit U750  which connects me from my pcs
to a unix vax.  very handy when you have lots of different hosts you connect
to -- i even use it to go thru various (local and public) networks to an
arpa machine in la right from my desk.

forth: another feature we missed in 4c(050) was file inclusion as typed
from the local terminal.  not all of the remote hosts have a kermit (yet)
and there are some utilities which do not like files, but only terminal
input.  furthermore, you need something for a 'pushing bootstrap'when
you want to bring kermit source over to the other system!  so we added
`ESCAPE I' in connect mode. It asks for a filename {we didn't do anything
fancy here -- maybe we could reuse code from other parts we didn't look at
-- this part certainly has to be redone, particularly to make the thing
the same for all target systems of C-kermit} and passes the chars in the
file tothe other side.  newlines are converted to carriage returns
(as you TYPE it) and a little delay was added.  the latter feature
was a pragmatic implementation hack to give the remote side a little
pause for digestion of the line sent.

these changes were made by a student of mine ond some by me myself.
all the code is made available to the public as is your policy, and
for all legal purposes we herewith transfer rights to columbia university.

if you wonder: the FZI of the mail header is "Forschungszentrum Informatik",
a non-profit research institute for applied research in computer science.
we are associated with (but independent of) the Technical University of
Karlsruhe.  I'm a scientist / project leader in the software engineering dept.

the rest of the message is a summary of all the changes, and we would like
that you incorporate them in newer kermit versions. the list was prepared
by the student; maybe the english isn't perfect.  if you wish, we can also
send the files, but hope this mail is in essence sufficient.

Karl Kleine
	csnet:		kleine@Germany
	usenet/eunet:	mcvax!unido!uka!kleine


[From Frank -- Some of these changes are already in 4C(057).  Most of the
others should wind up, in some form, in a forthcoming release.]

------------------------------

Date: Wed, 12 Feb 86 12:08:33 cst
From: knutson@huey.UTEXAS.EDU (Jim Knutson)
Subject: THE FROG for 64-bit CDC's?

I am no longer working with Cybers anymore so my support of Cyber Kermit
has become rather limited.  I would like to see support for it continue
on a "real" Cyber site (not this homegrown OS stuff).  Basically, the
support needed is finish server support and be willing to write tapes
for other CDC sites.  Perhaps a general cleanup of all the nasty 
conditional code is in order also.  Anyone willing to take this on should
contact me to obtain all the materials I have.

It is interesting to see that other sites are writing Kermits to run
on CDC equipment.  I can understand writing in Pascal but writing one
in Compass makes me shudder.  I have had to support several Compass
programs in the past and it is a nightmare when trying to make mods.
I wish them all the luck in the world in that endeavor.

Jim Knutson
ARPA: knutson@ngp.UTEXAS.EDU
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
Phone: (512) 471-3241

------------------------------

End of Info-Kermit Digest
*************************




-------