info-kermit@ucbvax.ARPA (06/08/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Fri, 7 Jun 1985 Volume 2 : Number 33
Departments:
ANNOUNCEMENTS -
Kermit Distribution Reorganized
Kermit for Perkin-Elmer OS/32
Corrections to Burroughs 6800 Kermit
C-KERMIT 4C -
Problem with Remote Commands to C-Kermit Server in Binary Mode
Problem with C-Kermit for Version 7 on PDP-11
MISCELLANY -
FTP'ing from CU20B
Formfeeds, tabs, etc in C programs
DEC-20 Kermit in Local Mode
CPM-86 Kermit Dies after 64K
Need Kermit for NCR WS-300
Kermit for Cromemco?
----------------------------------------------------------------------
Date: Fri 7 Jun 85 15:18:29-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Distribution Reorganized
As contributions of Kermit programs continue to arrive, the Kermit
distribution area grows larger and larger. This week, the collection finally
grew so large that it would not fit on a 1600bpi labeled tape. The past
several days have been spent reorganizing the entire Kermit distribution
operation.
The biggest change is that there are now two major Kermit distribution areas,
which correspond to two Kermit distribution tapes (Tape A and Tape B).
Area/Tape B contains all the mainframe and minicomputer ("host")
implementations; Area/Tape A contains everything else -- the microcomputer
(PC, workstation) implementations, the manuals, and miscellany. Splitting up
the files this way allows room for a good amount of growth, and also lets
several versions (notably the U of Toronto Pascal Kermits for RT-11 and
VAX/VMS) be resurrected from the "Kermit-Extra" area.
Even though the files have been split into two directories, they still all
have (and must have) UNIQUE PREFIXES. No files with the same prefix will
appear in more than one directory (except the new AA files, about which see
below).
Many files have been renamed in a more sensible way. Previously, all the
"bureaucratic" files like VERSIONS.DOC, 00README.TXT, etc, were mixed in with
all the other files. Now (in addition to being rewritten), they have new
names, all starting with AA. In fact, all filenames now start with a letter,
since it turns out that some systems require that.
Old New What
(none) AAAREAD.ME Explains what all the AA files are.
00README.TXT AATAPE.HLP Talks about tapes (replaces ANSITAPE, OSSLTAPE)
(none) AANETW.HLP Instructions for getting Kermit via network
00README.TXT AAFILES.HLP Explains what the Kermit files are
CURRENT.DOC AAVNEW.HLP List of current versions, chronological
VERSIONS.DOC AAVSYS.HLP List of current versions, alphabetical by system
(none) AAWAIT.HLP List of versions we're waiting for
FLYER.DOC AAXFLY.DOC Flyer (now also includes order form)
COMMER.DOC AAXCOM.DOC Commercial policy, only the name has been changed
KLTR.TEX AAKLTR.TEX Cover letter, rewritten
The files that used to be VERSIONS.DOC and CURRENT.DOC been combined into
AAVERS.HLP. This is a list of versions, one on each line, showing the
following information:
Prefix, Operating Program Program Released
Tape Machine System Language Version yy/mm/dd Contributor
for example:
CMS B IBM 370 Series VM/CMS Assembler 2.01 85/05/20 Columbia U
Whenever a new version is installed, this file is updated and then sorted
several different ways to produce the following files:
AAVNEW.HLP -- Listed in reverse chronological order of release date
AAVOPS.HLP -- Listed alphabetically by operating system only
AAVPFX.HLP -- Listed alphabetically by prefix, regardless of tape
AAVSYS.HLP -- Listed alphabetically by machine and operating system
AAVTAP.HLP -- Listed by tape (A or B), then alphabetically by file prefix
The AA*.* files will appear in both Kermit distribution areas/tapes. A glance
at the appropriate file will make it easy to answer questions like "Is there a
Kermit for xxx?", or "Has there been a new release of Kermit for xxx since
yyy?", or "What is the prefix for zzz Kermit?", or "What tape is such-and-such
a Kermit on?"
Some Kermit program files were renamed:
Old New
20KERMIT K20MIT (needed to start with a letter)
170KERMIT CDCKER "
800KER LUXKER "
86KERMIT C86KER "
CMSKERMIT CMSKER (so Scribe could deal with the .MSS better)
Those who use the Internet, CCnet, or BITnet to get Kermit files from Columbia
should read KER:AANETW.HLP for details about network access. The BITnet area
(KERMSRV@CUVMA) is not yet reorganized -- that will take another week or two.
Those who use FTP or NFT to get files from CU20B should notice no difference
in the procedure, since the "logical name" KER: has been redefined to include
the new area in its search path; the fact that no prefix (except AA) appears
in more than one area should allow network file transfer to work as before,
except when you try to get ALL the Kermit files (would anybody really do
that?) -- if you tried to "MULTIPLE GET KER:*.*", you would wind up with only
the files from area A. If you need to refer to the B area explicitly, its
logical name is K2:, as in "MULTIPLE GET K2:*.*".
And a minor complication -- Macintosh Kermit is part of the CK*.* files, which
are on Tape B. But since the Mac is a micro, people will be upset if they
order the "micros" tape (A) and there's no Mac Kermit on it. So just the .HQX
files for CKMKER and CKMKEY have copies KER:, along with the CKMKER.DOC file.
However... since these files were also in K2:, their names have to be
something that doesn't start with CK; otherwise, people who tried to FTP CK*.*
would only get those three files and nothing else (because DEC-20 logical names
don't step). So they are called KER:MCKER and MCKEY...
------------------------------
Date: Mon 3 Jun 85 15:58:29-EDT
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Kermit for Perkin-Elmer OS/32
From Paul Mamelka, Genetics Dept, Southwest Foundation for Biomedial Research,
San Antonio, Texas:
[Here is] "Kermit-PE" for the Perkin-Elmer 3200 series computer under OS/32
operating system. We've been using the program for the past 3-4 months to
transfer data files between our various micros and a PE-3210, with good
success. It's also currently in distribution through the Perkin-Elmer
INTERCHANGE library, and we've had no reports of any serious problems yet.
As noted in the .DOC file, revision level 7.2.1, or higher, of OS/32 is
required to run Kermit-PE successfully, and any difficulties people have
with it will probably be related to the OS level they're using, or to some
special customization they've done to OS/32's BIOC device driver. Questions
relating to this might best be directed to:
Ron Stordahl
c/o INTERCHANGE Library
Perkin-Elmer Data Systems
2 Crescent Place
Oceanport, NJ 07757
Ron is fairly knowledgeable on the subject of BIOC, having implemented some
of the "unofficial" upgrades to the driver which let Kermit-PE run much more
efficiently under OS/32. He's distributing these upgrades through the
INTERCHANGE Library, along with Kermit-PE. I'll also be happy to answer
whatever questions I can from P.E. users who receive Kermit through your
channels.
Paul Mamelka
512-674-1410 x353
------------------------------
Date: Mon 3 Jun 85 16:00:23-EDT
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Corrections to Burroughs 6800 Kermit
The first release of Burroughs 6800 Kermit that was released 15 Feb 1985 had
a few bad lines. The following changes are necessary to the original
version; the version being distributed currently (KER:B68KERMIT.ALG, as of 3
Jun 85) incorporates them:
1) Delete the three lines containing the following sequence numbers:
12010600, 12012900, 12013000
2) Add the following lines between those numbered 12099000 and 13000000:
END 12099200
UNTIL RM:=*-CTS = 0 12099400
END D E B U G W R I T E ; 12099600
This should allow a clean compile of Kermit.
Randy McLaughlin
MetroII
360 Colborne St
St Paul, MN 55102
(612)227-9261
------------------------------
Date: Tue, 4 Jun 85 08:46:49 PDT
From: rich@cit-hamlet.arpa
Subject: Problem with Remote Commands to C-Kermit Server in Binary Mode
We have set up a PC/AT running Xenix as a file server using C Kermit server
mode. Users on our LAN can login and retrieve public domain software , etc. I
have set kermit server up using the switches "iwx" so binary files can be
xferred. The problem I now have is since no LF to CR LF conversion is done,
when PC-DOS machines connect and issues commands to the server ( like remote
help, etc. ) they get output with no CRs and hence get a jumbled display. Any
ideas on how to work around this?
Thanks..
Richard Fagen
Caltech Computing Support Services
rich@hamlet
[Ed. - Unfortunately, you can't have it both ways. C-Kermit could be changed
to always insert CR's when responding to remote commands (temporarily turn off
the "binary" flag), but unfortunately, it's impossible for the program to know
WHY the user put it in binary mode. It may be that she wants to run a program
that sends binary data to the screen for cursor control or even graphics. If
you're sure your users will never do that, then you can add a couple lines of
code to save and turn off the binary flag before doing a remote command, and
restore it when done.]
------------------------------
Date: 5 Jun 1985 15:21-PDT
Subject: Problem with C-Kermit for Version 7 on PDP-11
From: Geoffrey C. Mulligan (USAFA) <GEOFFM@SRI-CSL>
I compiled the 4C version of c-kermit under my v7 system on an 11/70 and when I
tried to run it I got a program too big error. Can anyone help?
geoff
[Ed. - The Pro/Venix version runs on what amounts to an 11/23 with no i&d
space with no problem, but it uses the "core-mapping" feature provided by the
Venix compiler and linker, which may or may not be available under V7 on the
PDP-11. If not, then you'll probably have to resort to overlays.]
------------------------------
Date: Sat, 1 Jun 85 00:32:00 PDT
From: Dave Flamm <flamm@AEROSPACE.ARPA>
Subject: FTP'ing from CU20B
I have a question regarding my ftp'ing from cu20b on the arpanet: I would
like to use "mget" to save effort, but it seems that I need a password to
change directories to <KERMIT>. Otherwise the filenames prefixed with
"<KERMIT>" are what get written to my directory, and these are so long that
the ends get truncated. The result is that the files overwrite each other.
I'd appreciate any advice in this regard.
Thanks,
Dave
[Ed. - You can't CD to a DEC-20 directory when logged in as ANONYMOUS through
FTP -- CD means something different to a DEC-20 than it does to UNIX (on a
DEC-20 CD, or "connect", gives you ownership rights). I'm having our network
gurus look into making FTP send only NAME.TYPE, rather than
DEVICE:<DIRECTORY>NAME.TYPE.N;P775252;AFOO etc etc. Does anyone know any
reason why the FTP server should send the fully qualified name? Of what
possible use could it be to a foreign system?]
------------------------------
Date: Fri 31 May 85 14:30:07-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Formfeeds, tabs, etc in C programs
One of the unportabilities of C-kermit is formfeeds and tabs in the source
code. They aren't hard to remove, but it can be slightly painful if such
a utility does not exist on the machine of interest. Here is a short program
to expand tabs, replace formfeeds with newlines, and remove line continuation
from C programs. (The line continuation is removed due to a documented lack
in Microwares Os9 C compiler, and should not be needed for other systems.)
It's not fancy, but it works. Input is from standard input, and output is
to standard output. (Please make sure not to convert spaces to tabs if you
make this program available.)
Bob Larson <Blarson@Usc-Ecl.Arpa>
/* dpp.c by Robert A. Larson */
/* dumb pre processor */
/* designed to convert C programs to a more usable format for Os9.
Microware C (6809) accepts tabs and formfeeds, but they make the
file hard to edit. Microware C does not accept macro or string
continuation.
*/
/* Expands tabs to spaces (tab=1 to 8 spaces, same as dec terminals)
Replaces FormFeeds with Newlines
Removes Backslash Newline sequences (Macro or string continuation)
*/
#include <stdio.h>
main(){
int c; /* c is the character being processed */
int p=0; /* p is the count of the number of characters in the current line */
while((c=getchar())!=EOF){
switch(c){
case('\\'):
if((c=getchar())!='\n'){
putchar('\\');
ungetc(c,stdin);
++p;
}
break;
case('\n'):
case('\f'):
putchar('\n');
p=0;
break;
case('\t'):
do{
putchar(' ');
} while(++p&7);
break;
default:
putchar(c);
++p;
}
}
}
------------------------------
Date: 06/02/85 22:12:56 EDT
From: TS0013@OHSTVMA
Subject: 20KERMIT in Local Mode
I am running TOPS-20 Kermit version 4.2(254)-1 in local mode talking to a
VM/CMS system. When I connect to the other host (VM) and after that host
sends a XOFF but before it sends a XON, I cannot seem to transmit a BREAK to
it using ^\B. This works fine when VM is reading input, but when VM is
doing output, it sends an XOFF to hold back input data. BREAK should not be
among that held back. Is this problem in Kermit or in our system, which is
version 5.3(5721)-5, front end version unknown. This problem is NOT
experienced with MS-DOS/IBM-PC Kermit.
...Phil Howard
[Ed. - Right, Kermit-20 should clear any XOFF'd condition when the user
tells it to send a BREAK. This will be in the next release.]
------------------------------
Date: Mon, 3 Jun 85 17:36:46 CDT
From: Gregg Wonderly <gregg%okstate.csnet@csnet-relay.arpa>
Subject: CPM-86 Kermit Dies after 64K
While trying to transfer a rather LARGE file from our VAX to a rainbow with
a hard disk, we keep getting an abort with a message saying that the disk
directory space is full. There is over 2 Meg free when this message is spit
out. A STAT of the file reveals that the file is 64Kbyte long. Could this
be the evil 64K segment problem that the Intel chip is so widly known for???
Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University
[Ed. - Answer from Ron Blanford, CONTEXT@WASHINGTON: "If the message says
the directory space is full, then this has nothing to do with the amount of
room left on the disk. Depending on how the Rainbow defines the hard disk,
there is probably an upper limit of 512 or 1024 directory entries that can
be used, each mapping 32 or 64K of disk storage. A large number of small
files on the disk could explain the problem; getting rid of some would
probably fix it."]
------------------------------
From: Bob Paver <PAVER@DELILAH>
To: info-kermit%cu20b@mcc
Subject: Need Kermit for NCR WS-300
We've got some NCR Worksaver 300's that need to talk to our VAX. NCR's
solution is something called ATE-2 which requires extra VT-100 modules and
which doesn't support RELIABLE file transfers. Therefore I'm looking for a
Kermit.
The hardware is actually made by Convergent Technologies. The OS is a
modified version of CTOS. The processor is an Intel 80186. Supposedly the
system will run MS-DOS, but we don't have it and I'd rather not mess with
another operating system in this application.
Any suggestions?
Bob Paver, MCC, 9430 Research Blvd., Austin, TX 78759, (512) 834-3316
------------------------------
Date: Thu 6 Jun 85 21:55:43-PDT
From: L. Brett Glass <G.GLASS@[36.48.0.2]>
Subject: KERMIT for Cromemco?
Does anyone know of a KERMIT (especially, one with a server) which will run
on a Cromemco System 300 under Cromix or CDOS? In particular, it would be
useful to get a version which already knows how to use the Z-80 front-end
cards supplied with these systems (Quadart, Octart, etc.). Please send
ANY information to <G.GLASS%LOTS-B@SU-SCORE.ARPA>....
[Ed. - Isn't Cromix a kind of Unix? Maybe C-Kermit could be tricked into
doing the job. Has anyone tried it? Is anyone working on Kermit for CDOS?]
------------------------------
End of Info-Kermit Digest
*************************
-------