[mod.protocols.kermit] Info-Kermit Digest V5 #9

SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (09/17/86)

Info-Kermit Digest         Wed, 17 Sep 1986       Volume 5 : Number  9

Today's Topics:
          Announcing IBM Mainframe VM/CMS Kermit Version 3.1
                    MS-DOS Kermit 2.29A Prerelease
                      Announcing Kermit for DTSS
        CP/M-80 Kermit-80 Version 4.08 on Trial Release in UK
         Comment on MS-DOS Kermit vs Graphics Screen Display
                    Problems with Atari ST Kermit
                   Problems with MacKermit 0.8(34)

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

Date: 1986 Sep 9   20:05 EST
From: (John F. Chandler) <PEPMNT@HARVARDA.BITNET>
Subject: Announcing IBM Mainframe VM/CMS Kermit Version 3.1
Keywords: CMS Kermit, IBM Mainframe

   This is to announce CMS Kermit Release 3.1 for IBM 370-series mainframes
running VM/CMS.  The new version has been consolidated into a single source
file, but there is a new, optional, separate program which can be used for
loading Kermit into high memory (thereby allowing Kermit to invoke any CMS
program).  An effort has been made to keep the CMS-dependent parts of Kermit
together (many operations are performed using MACRO's which could be
redefined to fit, for example, TSO), but there are still many spots in the
code which implicitly assume the CMS environment.

Below is a list of the more important additions in Version 3.1:

1.  Massive reorganization and cleanup of source code.

2.  Advanced server functions.

3.  Basic and advanced commands to a local server from remote mode, driven
    by TAKE command file.

4.  Long packet protocol (type 0 extended headers).  Allow arbitrary foreign
    filespec in SEND and GET commands.  Provide optional prefix and suffix for
    outgoing file headers.

5.  CWD and SPACE commands along with SET DESTINATION.  The default filemode
    for SEND is taken from CWD.

6.  TYPE, ECHO, XTYPE, and XECHO commands (the latter two being Series/1
    transparent-mode analogs of the first two, useful for raw downloading).

7.  REMOTE KERMIT commands honored by CMS Kermit server, including SET, SHOW,
    TDUMP, TAKE, CMS, CP, STATUS, and SPACE.

8.  TEST mode for debugging.

9.  Optionally append to, rather than, replace, old files with duplicate names.

10. Optionally keep files even when the transfer is cancelled.

11. Send Attribute packets with file size, host system, and possibly file
    type and record format.  Receive and ACK attribute packets.

12. Option whether to search only the "home" disk and its read-only extensions
    or all accessed disks when the filemode is omitted from filespec.

13. Automatic recovery from line-noise interruptions on TTY lines.

14. Multi-column, two-level selective SHOW display.

15. New help text for HELP command.

[Ed. - Many thanks!  Version 3.1 began as 3.0 (which was never released),
consisting mostly of source-level reorganization, cleanup, bug fixes,
plus new keyword parsing and a new help command, by Vace Kundakci of
Columbia.  John made further contributions, including the new server
functions, Attribute packets, new SET and SHOW commands, the new CMS chapter
for the Kermit User Guide, the new installation procedure, and more.  Bob
Bolch of Triangle Universities added the extended-length packet support,
Clark Frazier of the Harvard B-School added features for raw downloading
through the Series/1 (XECHO and XTYPE).  The new version should also fix
most or all of the bugs that were reported by many sites (particularly by
Greg Small at UC Berkeley) since the release of version 2.  The new files
are in KER:CMS*.* on CU20B.  The old ones will be kept on CU20B for a while
as KO:CMS*.*.]

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

Date: Tue 16 Sep 86 12:41:47-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: MS-DOS Kermit 2.29A Prerelease
Keywords: MS-DOS Kermit

The MS-DOS Kermit 2.29A Prerelease that was announced in the previous digest
turned not to work with IBM mainframe Kermits.  It has been fixed in this
respect and replaced.  The new version is dated September 15 rather than
September 10th, and has been tested against VM/CMS Kermit with no problems,
using both 3705 (linemode) front ends and Series/1-style ASCII protocol
converters, and both regular and extended-length packets up to 1000 bytes in
length.  The test versions of MS-Kermit are in KER:MST*.* on CU20B and also
on KERMSRV as MST* * for BITNET access.

Also, as noted in the .HLP and .BWR files, when parity is set to NONE, all 8
bits of incoming characters are displayed on the screen during CONNECT.
This will cause consternation to users of systems (particularly the IBM PC
family) with 8-bit character sets.  This feature was added to accommodate
European and non-Roman-alphabet environments that really do have 8-bit ASCII
character sets, but it was erroneously tied to the PARITY setting.  In fact,
there are systems (like the DEC-20) which have 7-bit ASCII character sets,
but which send parity (e.g.  even) to the terminal, but don't require parity
coming from the terminal, and whose Kermit programs put the line into
transparent 8-bit mode for file transfer.  Until a new SET command is added
to select 8-bit or 7-bit terminal display, the workaround is to SET PARITY
SPACE during terminal emulation and to SET PARITY NONE for file transfer.

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

Date: Tue 16 Sep 86 13:11:57-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU> 
Subject: Announcing Kermit for DTSS 
Keywords: DTSS Kermit

A new version of Kermit has been written for Honeywell 6000 mainframes
running the Dartmouth Timesharing System (DTSS) in "Virtual PL/1" (VPL1) by
Philip Koch of the Dartmouth Kiewit Computer Center.  This is a relatively
esoteric Kermit since there are not very many DTSS installations, and of
them, few have VPL1 compilers.  However, brief instructions are included for
converting to non-virtual PL/1.  There's no manual or help file, but there
are some comments at the beginning of the source file, which is in
KER:DTSS.PL1 on CU20B.  Thanks to Philip Crowell of Dartmouth for sending
the program to us on tape.

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

Date: 11-SEP-1986 17:01:26
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK (Alan Phillips)
Subject:  CP/M-80 Kermit-80 Version 4.08 on Trial Release in UK
Keywords: CP/M Kermit
Cross-Ref: Kermit-80 (see also CP/M Kermit)

Bertil Schou at Loughborough University in the UK (OBSchou@UK.AC.LUT.MULTICS on
the UK JANET network) has now got his mammoth rewrite of Kermit-80 available
for test release. At the moment the files are available only by FTP in the UK
from his machine, but once the very worst bugs have been cleared we'll be
getting the files to Columbia for wider circulation. Bertil has sent in some
notes on what changes he's made: here they are:

Superficially,  there  is  little  real change  in  operation  of Kermit-80,
but  there  have  been some major jobs  tackled  like trapping BDOS calls and
multiple FCB buffering...

New bits for this version include:

               SET {SEND/RECEIVE} START-OF-PACKET character
               SET DIRECTORY-FILE-SIZE  (Shows  or hides  file  sizes  on
                       DIRectory displays)
               USER to set other user spaces
               RECEIVE to collect a file from a remote SENDer
               GET to collect a file from a remote SERVER
               SEND {local filename} {remote filename}
               TAKE to take command files from disk
               automatic  TAKE  KERMIT.INI  on default  disk  on  loading
                       KERMIT-80 (useful for SET BAUD etc.)
               much improved speed on DIRECTORY
               automatic  CLOSE-ing of a terminal connection if the  line
                       is  DROP-ped  (currently only for  an  Apple,  and
                       Torch  has  a dummy test for cntrl-] D in  connect
                       state)
               improved printer handling. (Kermit-80 sends an XOFF to the
                       host if the characters are comming in faster  than
                       they  are  printed.   This does not work  in  this
                       version,  as another option,  SET FLOW-CONTROL has
                       not been fully implemented - also,  I did not have
                       a printer to test this out on a Torch...)

On  the  negative side,  only LASM can be used  to  assemble  the source files.
I personally see no pont in being able to support several assemblers if LASM
can do the job, but then again, I have not  used  the MAC80 cross assembler...

All  source  files  have  been  renamed,  and  there  are  a  few additions.
All source files are named in the form:

               CPaxxx.ASM

where:

               a=S for system independent source files
               a=X for system dependent source files
               a=other letters for .HEX files etc.   These files have NOT
                       been created as yet.

The  system  dependent code has changed a  litle  too,  hopefully bringing  the
CPXSYS.ASM (formerly CP4SYS.ASM) file a  bit  more toward  a manageable  size.
There  is now the  possibility  for FAMILIES  of  systems,  like APPLE and
NorthStar  (also  Comart), which  contains  code  for computers of a single
type.   I  have immediately  gone against all this by creating a family with
the code for Torches, Cifers, Ithacas and Superbrains.  (This because we have
these systems here at Loughborough)

CPXSYS.ASM is largely unmodfied from CP4SYS.ASM.   Systems now in families
have their code duplicated in the relavent family file. CPXSYS.ASM  LINKs  to
the family file  if  appropriate.   In  due course,  I  hope to split off more
systems into "families" either on  their own,  or grouped  with other similar
systems.   I  know this is a half way step to true independent code for each
system, but  some systems are so close to others that I think it best  to group
them this way.

All VDU and terminal information is now held in CPXVDU.ASM.  This is really the
last section in the older CP4SYS.ASM file.

A quick "schematic" of what happens at assembly time...

        LASM CPXTYP... this then assembles the following:

        CPXTYP
          |
          v
        CPSDEF
          |
          v
        CPXLNK
          |
          v          (CPXSYS acts as a sorter for FAMILY switching)
        CPXSYS-------+----------+-----------+-----------+----
          |          |          |           |           |
          v          v          v           v           v
        (rest  of  CPXTOR     CPXAPP      CPXNOR       CPX???  one of
        CPXSYS)      |          |           |           |      several
          |          |          |           |           |      Families
          +<---------+----------+-----------+-----------+----
          |
          v
        CPXVDU
          |
        <END of assembly>

Users  should  be  aware  of  the  change  both  to  the  linking information
and start of the overlay address.   There are two new entries in the table,
family (offset 6) and lptstat (offset 20h). The  former is a two byte pointer
to a text string for  a  FAMILY (or  null  if not used) and the latter a JMP to
a routine  giving the status of the printer.   This can be done through  BIOS,
but not  through BDOS.   Users with odd sorts of printers may need to add their
own code here.

There  have  also  been some bugs fixed in  some  of  the  system dependent
code, so you would be wise pulling all the source files across.

The overlay address is now 5000h, and will probably change before this
revision  is complete.   The speeding up of  multiple  file handling takes its
toll on memory,  as there are now 64-ish  FCBs buffered.  This speeds up the
DIRECTORY command no end.

With  the overlay address at 5000h there is still a lot of  space free for more
things to be added (about 800h bytes).

Things yet to be done - lots!

There have been moves trying to add other independent modules for other
terminal  emulators  other than  the  VT52.   Demands  for SERVER,  REMOTE
HOST...,  file compression, better TRANSMIT, % of file  sent  and/or Kbyets
sent/received as part  of  the  display diring  transfers,  a lot of cosmetic
tidying up as well as  even more systems to be added.   CP/M-80 is a slowly
dying DOS,  and I feel  inclined to leave some bits out,  like SERVER (how many
use really  large  winchesters  in CP/M-80  systems,  and  want  true
servers?).    Does  anyone  have  a  burning  desire  for   these facilities?
And if so, will YOU be willing to take on the job of implementing them?

        Bertil Schou.

[Ed. - Above you see the future of CP/M-80 Kermit -- comments and
suggestions will be relayed to Bertil -- get them in soon, before it's
too late.]

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

Date: 14 SEP 86 18:44-MDT
From: JRD@USU
Subject: Comment on MS-DOS Kermit vs Graphics Screen Display
Keywords: MS-DOS Kermit

        In the Kermit Digest V5 #7 Kenneth Van Camp, kvancamp@ardec, said
that his new display board was causing MS Kermit 2.29 (but not Crosstalk) to
drop characters arriving from the serial port.

        The critical things here are: does the display board turn off
interrupts during screen scrolling, does it use the standard color card
display memory address (B800H, vs B000H for the monochrome card), does it
use interrupt request lines reserved for the serial port, and might its Bios
(if any) intercept the normal Int 10h video interrupt to implement things
its own way? An answer of Yes indicates slower processing of screen data.
The slowest screen operation on my EGA equipped system is scrolling (runs
about 16 millisec per text line), and scrolling can be caused by receipt of
a line feed (rather than a carriage return). Loss of characters indicates
the serial port interrupt could not be serviced before another character
arrived at the port. Common delaying items include print spoolers, screen
savers, and many other items, all of which tie on to the system clock tic
interrupt and block interrupts for extended periods. If the display adapter
also keeps interrupts off for milliseconds then things will get lost.

        When the screen is scrolled Kermit has a lot of work to do. Before
scrolling it copies the top (or bottom, as appropriate to the scroll
direction) line to an internal buffer, asks the Bios to do its slow screen
scroll, and then if need be writes a new bottom (top) line from a buffer to
the screen.  MS Kermit 2.29a has a speedier algorithm for all of this; but
still, the limiting factor is the Bios. If the display adapter were to turn
off interrupts during its Bios scroll operation then that's that.

        The MS Kermit command Set Term Color 10 forces a fast screen update
which may aid Kenneth; it causes snow on IBM CGAs.

        Regards,
        Joe D.

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

Date: TUE, 26 AUG 86 17:10:04 GMT
From: C20228 @ UK.AC.PLYM.B
Subject: Problems with Atari ST Kermit
Keywords: Atari ST Kermit

I have an ATARI 1040 ST with an ATARI C development kit. The kit has a
version of Kermit based on the old VMS/UNIX Kermit. This works but is not
really suitable for the uninitiated ATARI user (ie 1st Year Students). I
therefore set out to implement Bernhard Nebels GEM KERMIT 1.02 which you
have on file store at Lancaster.

1) Use VMS kermit to download the UUENCODED HEX files from LANC, get DECODE
program in C to decode above file. Compile DECODE program and feed it the
UUENCODED HEX files, results in KERMIT.PRG and KERMIT.RSC files now on disk.
Execute KERMIT.PRG it doesn't work !!! ATARI turns up its toes and displays
usual two bombs, then returns to desktop.

2) OK back to LANC file store, new message in 00BULL.TXT there is a new
version of the DECODE program in assembler, to correct missing spaces
problem. Right download it, and another copy of UUENCODED HEX file for good
mesure. Assemble DECODE program OK, now run it and feed it UUENCODED HEX
files, results in KERMIT.PRG etc etc.... execute Kermit ATARI experiences
fatal error, usual two bombs displayed, program returns to desktop.

3) OK now I'm really mad, back to LANC filestore. Transfer whole of ATARI C
source code (didn't really want to do it this way, but!). Write BATCH file
to compile all C source modules, link modules, KERMIT.PRG now appears on the
disk. Execute KERMIT.PRG ATARI treats us to a wonderful display of random
graphics and dither patterns, stand admiring random graphics for a while
before remembering that we are supposed to be running KERMIT. Try to regain
control of ATARI, to no avail, even reset leaves the machine with a duff
hard disk driver, finally resort to powering down and re-booting. Repeat
above three procedures on and off for about a week. finally give up in
disgust!!!!!

CAN ANYBODY HELP!!

Chris Rose
Micro-Support
Plymouth Polytechnic.

[Ed. - This is a good example of the paradox of Kermit -- you can't get
it unless you already have it...  Has anybody succeeded in making this
work?  Maybe a .boo file would be better than a UUENCODE file -- at least
.boo files don't have trailing blanks, and there's a .BOO-file decoder
written in C (KER:MSBPCT.C on CU20B).  It would also be most helpful if
someone could volunteer to ask as a provider of Atari ST Kermit diskettes,
or to induce an Atari user group to do it.  If this happens, please tell
us, so we can refer people who ask us.]

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

Date: Sat, 23 Aug 86 09:31:28 pdt
From: gould9!joel@nosc.ARPA (Joel West)
Subject: Problems with MacKermit 0.8(34)
Keywords: Mac Kermit

I've been using MacKermit for 1.5 years now and am very pleased overall.  I
use it every day even though I own two commercial (MacTerminal and
Microphone) programs which sit unused.  But... (You knew this was coming)

I'm having trouble with my MacPlus:
	1) The Receive dialog box is not compatible with HFS and
	   looks quite bizarre.
	2) I was unable to map keys on the Plus to other values.
	   (Has anyone else tried this?) My previous mappings
	   from my 512 days work fine, though.

[Ed. - All of our Macintosh programmers disappeared after 0.8(33).
The current version, 0.8(34), consists mostly of VT102 emulation
improvements by Davide Cervone of the U of Rochester.  No work has been
done to accommodate the Mac Plus.  It has been suggested that the resource
file can be edited to make the Receive-file box look right for the Mac+, by
making it the same size as the Send-file box.  The keypad stuff mostly works
fine with the Mac+ (at least on ours), provided you start with the VT100
Keypad startup file that's supplied on our distribution diskette, and on
CU20B as KER:CKMVT1.HQX (and .DOC).]

Also, a lingering nit-pick from day one:
  When starting a new file, the transaction dialog box should
  pull down the "Transferred OK" message from the previous
  file, as it is confusing to tell whether the msg is left from
  the previous file or is a status on the current file.

If there are any lingering key problems on the European macs or the Plus, I
would recommend the article "Be a Keyboard Sleuth" (by Joel West) in the
August 1986 MacTutor.  I can supply a paper copy to anyone who's interested
in doing further work on MacKermit or K-Config.

	Joel West			     MCI Mail: 282-8879

[Ed. - Mac Kermit does indeed need work.  The major thing that needs to
be done to it is translation to a native Macintosh C compiler, so that
a VAX or other Unix system with the SUMACC tools is not required to
modify the program.  Several people have expressed an interest in doing
this, but I don't think anyone has really started.  Also, there doesn't
seem to be any concensus as to the best C compiler for the job.
Suggestions welcome, volunteers even more welcome!]

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

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