[fa.info-kermit] Info-Kermit Digest V1 #20

info-kermit@ucbvax.ARPA (04/17/85)

From: Frank da Cruz <SY.FDC@CU20B.ARPA>

Info-Kermit Digest         Wed, 17 Apr 1985       Volume 2 : Number 20

Departments:

  ANNOUNCEMENTS -
	New Macintosh Kermit on the Way
	Kermit for GUTS

  MISCELLANY -
	Changes to DEC-20 Kermit for TVT's, TAC's under Panda Monitor
	More Comments on Binary Files
	PCjr Peculiaries
	Kermit for GE Timesharing?
	CPM3 Generic Kermit on Osborne Executive?

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

Date: Tue 16 Apr 85 12:17:35-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Macintosh Kermit on the Way
To: Info-Kermit@CU20B, Info-Mac@SUMEX-AIM

Just to forestall any parallel development, this is to announce that
Columbia University is about to release a new Macintosh Kermit.  The
program is written in C using the SUMACC Unix-based cross development
tools, and is based on the new C-Kermit protocol modules.  It includes
VT102 terminal emulation with line and character insertion and deletion.
The terminal emulator and file transfer functions are done; the rest of
the user interface (dialog, display, and control windows) is being done
now.  We expect to announce an initial release within several weeks.

Columbia's Macintosh Kermit will be distributed on Columbia's Kermit
distribution tapes and via computer network, like other Kermit programs.
We recognize that Macintosh Kermit will be difficult to bootstrap,
especially at sites that do not have the SUMACC tools, so we would like to
place a few diskettes at sites where they will be most widely reproduced
and circulated, such as the member schools of the Apple University
Consortium.  Any other suggestions?  Unfortunately, Columbia simply does
not have the resources to get into the diskette production business, so
we are looking for sites that are willing to act as distribution centers.

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

Date: Wed 10 Apr 85 18:00:44-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Kermit for GUTS

This is to announce an implementation of Kermit for IBM mainframes running
GUTS (the Gothenburg Universities' Terminal System), a TSO-like timesharing
system installed at about 80 sites in Europe, Africa, and the USA.  It was
adapted by Stefan Lundberg of the Gothenburg Universities' Computing
Centre, Gothenburg, Sweden (STEFAN_LUNDBERG_GD%QZCOM@MIT-MULTICS) from the
University of Chicago's MVS/TSO Kermit, which was in turn adapted from
Columbia's VM/CMS version.

The files are available via anonymous FTP from CU20B as KE:GUTS.*.  Note,
KE:, not KER:.  Unfortunately, we are no longer able to fit all the Kermit
implementations in one place, or on one tape.  At some point in the coming
months, the Kermit distribution will have to be split in two with one
area (and one tape) containing the more popular versions, the other the
more esoteric.

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

Date: 10 Apr 1985  22:17 MST (Wed)
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Subject: Changes to DEC-20 Kermit for TVT's, TAC's under Panda Monitor

Frank,

The following are the changes I made to 20KERMIT.MAC.255 to add
support for a MONITR that doubles IACs and has new MTOPR% calls to
negotiate network binary mode.  Such support is in MRC's PANDA MONITR
which we are running now, and the MTOPR% codes are of MRC's making,
not yet DEC's.  I have made similar changes in MODEM available in the
usual place here (MICRO:<CPM.TOPS-20>).

--Frank

[Ed. - Thanks, Frank.  Rather than incorporating these changes into the
base version, I've left them in KER:20KERMIT.BWR on CU20B.  When and if
DEC ever makes up its mind how to handle this problem, Kermit-20 will be
changed to accommodate.]

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

DATE: 10-APR-1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: More Comments on Binary Files

I agree that filetype confusion will occur, thus the suggestion  that  a
system  and  user  INI file could define those types. The reason I would
like to see this is for a proposal here to archive  msdos  libraries  on
the  785  (amounting  to  several  tens of thousands of blocks) so users
could download things as they need them from the vax. The use of a  user
ini  file  with  filetype info for binary files would be able to set bin
mode for, say .COM files, only for that user.  While  it  clear  that  I
should  be able to set the attributes on the VAX side of the msdos files
and all should work right, that in itself could still be a mess.

The reason I implented  switching  to  binary  mode  via  filetype  (and
attributes)  in  the  first place was because the rt11 file system knows
nothing of attributes. Additionally, RSTS/E Basic+ 'compiled' files  are
stored  w/o  attributes,  though,  of course, RSTS/E supports the entire
FSC/RMS file structure when desired or needed. I did include a SET  FILE
NOAUTO command to disable checking for binary file transmission.

It  would  be  really  nice  if  Kermit-32  and  MSDOS  Kermits  support
attribute packets in at least the "I,"B and "A packets so the  recipient
could  decide  what action to take. I do this on Kermit-11 and it really
makes loading my PRO/350 from  my  23+  easy.  As  an  example,  William
Youngs  of  DEC/LDP  has  a  bulletin  board  on  a  730 where he places
scientific and eng software, his users that dial in  find  it  confusing
to be switching modes to get a .SAV image vs a .MAC or whatever.

One last note  (about VMS Kermit).   One problem that  comes up is  with
binary files that are fixed 512  with carriage control. These files  are
typically sav and task images loaded  onto the VAX via FLX or  EXCHANGE.
It would seem that the only (simple) way to be able to Kermit them is by
using CONVERT  on them  to remove  the 'carriage  control' attribute  to
none. I don't really care, but it may account for problems I have  heard
about from others running Kermit-32.

                                                brian nelson

[Ed. - Of course, what's needed -- and what we'll never get -- is a
"standard" for determining file attributes in a heterogeneous environment.
File types are one way, but Brian's own classic example -- VMS .COM files
(textual) vs CP/M .COM files (binary) -- points out the pitfalls of this
approach if used in isolation.  Another prominent example is TOPS-10/20
.EXE files (36-bit binary) vs MS/PC-DOS .EXE files (8-bit binary).
However, extending the file-type idea a bit might do the trick: a list
of file types and corresponding attributes such as Brian suggests could be
kept on a per-site basis, along with private lists for individual users,
but in addition a particular file could be stored along with a parallel
file having a special file type, say .KFA (Kermit File Attributes), which
would contain attribute information -- perhaps formatted according to the
Kermit Attribute Packet description in the Kermit Protocol Manual.  If
such a file were present, Kermit would use the specified attributes; if
absent, Kermit would use attributes from the user's or site's type list.
The obvious measures would also be necessary to allow a user to override
all of this on a per-file or per-file-type basis.  Specification and
coding of all this would be quite a job, but perhaps trivial compared with
explaining it to users...]

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

From: Paul Fishwick <Fishwick%upenn.csnet@csnet-relay.arpa>
Subject: PCjr Peculiaries
Date: Wed, 10 Apr 85 21:02 EST

I called you the other day asking a question or two about the
peculiarities of the PCjr with respect to my emulator.  After "carefully"
reading the Junior Doc. which someone sent me, it is quite clear why
Kermit works fine and mine did not: Page 2-126 tells all: "Without the
Internal Modem installed, the RS232 serial port is logically addressed as
COM1 in BIOS,DOS, and BASIC even though its address is still hex 2f8 using
interrupt level 3."

No wonder they canned the machine.  Personally, my design philosophy is to
use BIOS whenever possible then digress to lower depths if someone
specifies mark,space parity and for general interrupt handling - this is
what got me!

-paul

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

Date: Thursday, 11 Apr 85 09:37:53 PST
From: vax135!cornell!uw-beaver!tektronix!iddic!dhs@Berkeley
Subject: Kermit for GE Timesharing?

I'm looking for anyone who knows if a Kermit is running on GE
timesharing.  Apparently they use some sort of Honeywell processors with
a proprietary, non-standard operating system.  I would like to use
Kermit to upload messages for a Bulletin Board system I'm setting up.
My intuition is that somebody, somewhere has a Kermit running.  I made
the suggestion to GE, and they suggested that they are looking into what
it would take to make a Kermit available.

Thanks in advance,

Dave Straayer

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

Date:  Fri, 12 Apr 85 10:33 EST
From:  "Paul E. Woodie" <Woodie@MIT-MULTICS.ARPA>
Subject:  CPM3 Generic Kermit on Osborne Executive?
To:  Info-Kermit@CU20B.ARPA

I have gotten a copy of CPM3 generic kermit and am trying to use it on
my Osborne Executive through Telenet to a Multics machine.  I am having
trouble getting it to work at all -- it will send the first character I
type after I go into Connect mode and then die.  Is anyone using generic
cpm3 kermit sucessfully at 1200 baud on the Osborne Executive?  If there
is someone, or if you would like to share "war stories" with me, please
respond to me directly at MIT-Multics.  If the results of this episode
are successful an there is something useful resulting from this, I will
be happy to post it to Info-Kermit.

Thanks in advance,

Paul Woodie (Woodie.DODCSC at MIT-Multics)

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

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