info-kermit@ucbvax.ARPA (05/17/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Thu, 16 May 1985 Volume 2 : Number 28
Departments:
C-KERMIT 4C -
C-Kermit 4C Changes
Problems with the V7 version of C-Kermit 4C
C-Kermit 4C for 2.9bsd/xproc
C-Kermit 4.2 OS9/68000, First Implementation Report
C-Kermit File types, file transfer problems
UNIX Kermit 4C Comments
MISCELLANY -
New mackermit--double-clicking on a saved settings file
Re: New mackermit--double-clicking on a saved settings file
Kermit hangs on bye/finish
Re: Info-Kermit Digest V2 #27
Using Kermit to back up your micro's hard disk
Update on the OK State Kermit Server
Kermit for TI-990?
HP Portable (HP110) Kermit?
----------------------------------------------------------------------
Date: Thu 16 May 85 19:36:17-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: C-Kermit 4C Changes
A few changes have been made to C-Kermit 4C to solve some of the recently
reported problems. The new files are in <CKERMIT>*.* on CU20B, available via
anonymous FTP. The biggest modification changes the way the program determines
whether it's in local or remote mode. Rather than just comparing strings,
which doesn't work in many cases, the program now asks the system. This should
allow C-Kermit to function correctly in remote mode when invoked by a user
logged in on the "back port" of a workstation (like the Pro-350/380 under
Venix) which is normally used from its console in local mode. Some other bugs
concerning "set line" were fixed at the same time -- the program now puts the
speed back to -1 when going from local to remote mode; it no longer erroneously
sets the tty name string when the desired line can't be opened (e.g. because
"Permission denied"). These changes affected many modules, because the calling
convention to ttopen() had to be changed.
The following messages mention other bugs and fixes in today's version of the
C-Kermit files. Note that the problem reported by Dave Tweten that the
C-Kermit server on System V systems does not respond to "remote" commands
(other than "remote help") has not yet been fixed; Dave is still trying to
track it down. On the other hand, only Dave has complained about this. Are
there other users of C-Kermit 4C under System V that are also experiencing this
problem? Are there any who aren't???
------------------------------
Date: Thu, 16 May 85 15:41:27 edt
From: randy@nlm-vax (Rand Huntzinger)
Subject: Problems with the V7 version of C-Kermit 4C
I had some difficulty getting the C-Kermit 4C to compile and run on our Codata
Version 7. Here are the diffs of the ckutio.c file and the Makefile which I
ended up using. The main problems were:
1. The absence of the xproc variable definition.
2. The nlist stuff had to be changed for our system.
3. A bit of fluff in the makefile.
We have a binary license, so I didn't have direct access to the name of a
variable which is a pointer to the proc table, so I had to use the address of
the proc table (which I knew from the bit of source we have to be called proc).
I also had to change the name of nproc for our version 7. Yuk, there has got
to be a better way.
Also, why is makefile in the object list for making "wermit"? It seems that
this would crash every make for any kind of system.
[Ed. - Oops, a mistake, now fixed.]
Here are the diffs I used.
Rand Huntzinger
randy@nlm-vax
[Ed. - Diffs omitted.]
------------------------------
Date: Thu, 16 May 85 16:29:36 CDT
From: Gregg Wonderly <gregg%okstate.csnet@csnet-relay.arpa>
Subject: Re: Problems with the V7 version of CKermit 4C
What Randy did looks reasonable. Seems that there is some difference
in whether his "_proc" value is the address of a pointer to the proc array,
or the address of the array itself. Anyway, this situation makes it get
real hairy when you don't have the source I suppose. On our system, the header
file <sys/proc.h> has the definiton of what "_proc" or "proc" really is. I
put the documentation in the MAKEFILE for this reason. Damn I wish someone
would choose a standard version of UN*X and use it. Maybe SYS5R2 will help.
As soon as we get what Randy has off of your VAX, I will add a good solid
description of what is really happening, and the possible exeptions. Maybe
this will clear some things up. Go ahead and add his diffs to ckutio.c.
They will probably be necessary on some systems.
[Ed. - Randy's diffs added to ckutio.c.]
------------------------------
From: Paul Graham <unr70!unrvax!pjg@seismo.ARPA>
Date: 15 May 1985 1011-PDT (Wednesday)
Subject: C-Kermit 4C for 2.9bsd/xproc
Cc: ron@seismo.ARPA
Our version of the 2.9bsd <sys/proc.h>:
/* $Header: /usr/include/sys/RCS/proc.h,v 1.2 85/01/17 11:31:30 root $ */
/* $Log: proc.h,v $
* Revision 1.2 85/01/17 11:31:30 root
* Distribution version, RCS integrated
* */
indicates that the struct xproc has been superseded by the union p_un.
This is an informational message at this time. If time permits we may
undertake the changes to ckutio.c. However after short reflection it seems
this may require a -D for 2.9 as well as V7.
Paul Graham 702/784-6007
University of Nevada Reno
UUCP (seismo, ucbvax!menlo70)!unr70!unrvax!pjg ARPA unr70!unrvax!pjg@seismo
[Ed. - Maybe the changes added above for V7, which seem to address this
proc business, might help. In any case, any changes to make C-Kermit
actually work under 2.9bsd would be most welcome, the sooner the better so
that 4C can become the real, distributed version. If anyone wants to help
these folks out, don't hesitate to volunteer!]
------------------------------
Date: Wed, 15 May 85 19:21 MET
From: Matthias Bohlen <bohlen%v750.ira%germany.csnet@csnet-relay.arpa>
Subject: C-Kermit 4.2 OS9/68000, First Implementation Report
These are the first things I noticed when trying to compile
C-Kermit 4.2 on my OS9/68000 system. If I only had time...
1. I wrote a new makefile, because OS9 "make" is different
from UNIX "make".
2. Form feeds had to be eliminated (C compiler reports
errors), back-slash for line continuation was accepted
by the C preprocessor.
[Ed. - Presumably these can be removed by a filter in the os9 makefile?]
3. I shortened many strings in ckmain.c, ckusr2.c
[Ed. - So have we in version 4C.]
4. Possible programming error found in ckcmd.c (line 959,
deals with word-delete):
*bp++ == NUL;
as a single statement has little effect (68000 C gives
a warning message here), but "*bp++ = NUL;" would be an
erroneous cure, if bp<cmdbuf after the preceding for-
loop! I suggest:
bp++;
[Ed. - Thanks.]
5. Strange construct (similar to 4.) in ckuser.c:
"*xargv++;" as a single statement; what is intended?
Maybe only xargv++, but maybe "(*xargv)++" ?
My compiler gives a warning here (same as 4.).
[Ed. - Thanks again -- it should be simply argv++.]
6. Return value type mismatch in ckuser.c:
"return(sstate);" returns a char as a default "int"
result of "parse". Similar situations in ckfns.c and
ckfns2.c. My compiler gives a warning here.
[Ed. - I don't think this does any harm since sstate will never be set to
a value that can be sign-extended as a result of char/int conversion.]
7. Strange construct in ckuser.c:
if (x = (cmcfm()) < 0) return(x);
My compiler gives a warning here: "possible degenerate
assignment in test". Hope, it performs the assignment!
There are similar constructs in ckusr2.c and ckusr3.c.
[Ed. - Thanks, should be "if ((x = cmcfm()) < 0) return(x);".]
8. ckusr3.c: Expressions with little effect:
turnch == y;
*s2--;
both as single statements. Again the question: What is
intended?
[Ed. - Again, thanks. Changing to "turnch = y" allows the "set handshake"
command to work as advertised. Before, it always set the handshake character
to XON, no matter what your command said.]
9. ck?unx.c: The whole conditional compilation stuff con-
fuses me. I think, I'll remove it and write special
OS9/68k files ckxo9k.c and ckzo9k.c. ckz does not re-
quire much change.
[Ed. - Good idea. I suggest using "9" to designate os9-specific files,
as in "ck9tio.c", in the nomenclature of version 4C (in which the file names
were changed).]
10. ckdial.c and cklogi.c need SIGALRM (undefined in all
OS9/68000 header files).
11. Assembler reports errors about the C-generated code,
if a variable of storage class "extern" is called
"cc". The compiler gives the name directly to the
assembler, where it collides with the name for the
condition code register of the 68000! Really funny!
[Ed. - I assume you can handle this by doing something like "-Dcc=xcc" in
the makefile.]
I have much work to do in the next weeks, so I cannot
continue on C-Kermit for some time, but I keep trying.
Matthias Bohlen <Mattes@Germany>
[Ed. - The changes marked by "thanks" above are reflected in the files
currently in <CKERMIT> on CU20B, available via anonymous Internet FTP.
The files also include some other minor changes, noted below.
Please send reports to Info-Kermit regarding either problems or success
building and/or running C-Kermit version 4C under 4.1bsd, Xenix, PC/IX, and
other as-yet unreported systems, so that I'll know when the program is
stable enough to be declared a "real" release. Thanks!]
------------------------------
Date: Wednesday, 15 May 1985 05:48:25-PDT
From: d_schullman%sarah.DEC@decwrl.ARPA (Dan Schullman 223-7468)
Subject: C-Kermit file types, file transfer problems
It would be real nice if I could do something like:
REMOTE SET FILE TYPE ...
so that as I alternate file types, I don't have to keep
FINISHing, CONNECTing, and reSERVing in order to change
the file type.
[I agree. This would be an extension to the protocol that we'll probably
have to make.]
Running VMS KERMIT V3.1.66 today with C-KERMIT 4C on
VENIX V2 FT2 and trying to transfer a binary file on
a line that VMS thought was /NOEIGHTBIT, I was able
to send it to VMS okay, but kept getting Q%Q%Q's when
trying to get it from VMS. Eventually I told C-KERMIT
to use "space" parity and that got it working. Can
you explain this? Is this more confusion over number
of data bits versus parity?
[To get VMS Kermit to work on a /NOEIGHTBIT line, you have to give VMS
Kermit an explicit SET PARITY command. In your case, telling the opposite
Kermit worked too, because it told VMS Kermit that parity was being done,
and therefore to use 8th-bit prefixing.]
Yesterday (and previously) while trying to get or send
text files between KERMIT 4C on a Sys-V VAX and VENIX V2 FT2,
I had problems with file specifications of "*", whereas
"*.*" seemed to work.
[I believe that this problem can be explained as follows: The C-Kermit send
command expands its argument into a list of all files that match. If you give
it the "*" argument, then the list will include the files "." and "..", which
are really directories. When going through the list, C-Kermit checks each file
to make sure it's readable ("ordinary") using stat(), and it skips files (like
directories) that are not. The trouble comes in because System V has two ways
of saying whether a file is ordinary, whereas Kermit was only checking one way.
In the file ckufio.c, function zchki() makes the following check:
x = buf.st_mode & S_IFMT; /* Isolate file format field */
if (x != S_IFREG) {
debug(F111,"zchki skipping:",name,x); /* Not readable */
return(-2);
}
System V will also return a 0 for a readable file, so the check should be
if ((x != 0) && (x != S_IFREG)) {
This change is in the latest CKUFIO.C in <CKERMIT> on CU20B. System V
experts, please speak up if there is a better way to do this!]
------------------------------
Date: 15 May 1985 1059-EDT
From: LCG.KERMIT @ DEC-MARLBORO
Subject: UNIX Kermit 4C Comments
A few remarks on Kermit 4C, which I downloaded from Market and compiled on my
Masscomp RTU 2.2 system.
1) using the "make sys3" command, the 4C kermit appears to
work just fine on my Masscomp, no problems encountered so
far, but all I've really tried is the "connect" mode,
and ascii/binary file transfers to/from a DEC-20 and a VAX.
2) The new Kermit works just fine with my Racal-Vadic modem, contrary
to what was indicated in the latest Digest? Maybe the problem
is in the bsd vs. sys3 compilations?
3) The only peculiarity I noticed with the new version so far is
if I "set modem-dialer racalvadic" and then do a "show parameters",
it still lists the modem-type as "direct" rather than "racalvadic",
even though the "dial" command works fine? If I set the modem
type to something else, e.g. "hayes", and do a "show parameters",
then the modem-type is reported as "hayes". A bug somewhere,
but certainly minor.
[Ed. - Code has been added to the "show command" to know about the
various modems, in <CKERMIT>CKUUSR.C on CU20B.]
Here in this building at Ford we have a DEC-20, a dozen or so
Masscomp's, about 40 assorted PDP-11's, several IBM PC's, about
50 Victor's, 2 VAX 780's, 5 VAX 730's, two Prime's, 3 Apollo's,
and several Computervision systems. We have Kermit installed
on most of these systems and find it quite adequate for low-volume
file transfers. Best of all, it's free!! Keep up the good work!!
[Ed. - Which Kermit are you running on your Victors? It would be a
great help if someone could make the necessary system-dependent modules
for MS-DOS Kermit to support the Victor, so we could discard some of
the hokey old versions that are now in use.]
Steve Kaberline
Ford Motor Company
Scientific Research Labs, room S-3061
P.O. Box 2053
Dearborn, MI 48121
(313) 323-2248
------------------------------
Date: Wed, 15 May 85 17:15:41 EDT
From: edwards%h-sc4@HARVARD
Subject: New mackermit--double-clicking on a saved settings file
It complains that it can't find an application to open.
Bill Edwards
Harvard Arts and Sciences
Computing Services
[Ed. - See answer below.]
------------------------------
Date: Wed 15 May 85 21:28:59-EDT
From: Bill Schilit <Sy.Bill@CU20B>
Subject: re: New mackermit--double-clicking on a saved settings file
To: edwards%h-sc4@HARVARD
The problem is that either the bundle bit is not set in the kermit
application or the creator is not set to KERM -- or both of these.
If you downloaded your kermit application from the RSRC file then
you will need to set these values using the set file utility. This
is outlined in the doc file that comes with the distribution.
You should be seeing two different icons, one for the settings file
and one for kermit itself. If you don't see these then you need to
run setfile.
- Bill
------------------------------
Date: Wed, 15 May 85 11:47:10 CDT
From: Gregg Wonderly <gregg%okstate.csnet@csnet-relay.arpa>
Subject: Kermit hangs on bye/finish
In the latest info-kermit, I noticed some talk about kermit hanging on
a bye or finish command. We had this problem talking to the VMS KERMIT on
our 11/780. The problem seems to be that the server gets the bye/finish
packet ok. It then sends an ACK. Immediately following this, the program
terminates. At slow baud rates, we believe that the system does some clean
up and buffer flushing before the entire packet gets sent. This tends to
keep the entire packet from being sent. Might be wise to get some of the
authors to put "sleeps" into the code where applicable.
[Ed. - C-Kermit has the appropriate sleeps.]
------------------------------
From: dual!ptsfa!abm@Berkeley
Date: Wed, 15 May 85 13:50:36 pdt
Subject: Re: Info-Kermit Digest V2 #27
RE: Kermit CMS & Sim3278 & Profs & PCdos Kermit 2.26
I have been using PCDOS Kermit to access PROFS with moderate success. We
have just installed a major LAN & related network facilities that
allows a large group of users who were using Simware's AZPC2 @ 1200 baud
to move up to 9600. Unfortunately, AZPC2 is written in basic ... and you
can guess the results at the higher line speed. I am hoping that this will
provide an opportunity to overcome "not a supported product" phobia on a
large scale, because I don't think anything but kermit can satisfy all our
requirements in the near term.
Here are the questions/problems:
1. One requirement is the ability to download/upload from the PROFS (read
3270) environment. This presently doesn't work because CMS release 1.0
supports only tty terminals. Does release 2.0 use standard 3270 calls,
or does it talk specifically to the Series 1/Yale package? What are the
odds 2.0 will work with Sim3278 and how much work do you think it will take?
[Ed. - It talks specifically to the Series/1 Yale package. CMS Kermit will
not work with an unmodified Sim3278, but if you have source, you can modify
Sim3278 to accept the same escape codes for entering "transparent mode" that
the Series/1, 7171, and 4994 accept. Making Kermit work over 3270-like
connections in general is a much harder problem, requiring major extensions
to the Kermit protocol itself. This was discussed at some length in
Info-Kermit Digest V1 #11, June 84.]
I am assuming that you know more about Sim3278 than I know about the Yale
package. Sim3278 runs on the VM host as a "diconnected process" (I think
that's the terminology), so we come through the Comten front ends like
normal async terminals until we get to CP and "dial sim3278".
2. I am using vt52 emulation under Sim3278. I have done 'set key ~' for my
functions, etc. but since local echo is on, the escape sequences garbles
the screen. In order to get around this problem, I plan to install the
following kludge:
module: msyibm.asm @ trnou2:
if the first byte of the macro sequence is a sentinal (probably 0ffh),
check if local echo is on, and, if so, turn it off and set a flag.
Check the flag after sending the macro, and, if on, turn local
echo back on. (I also plan to include a second sentinal to allow
a macro starting with a sentinal to be echoed -- I don't know why
you would want to do this, but its best not to fool with mother
nature (or Bell or Blue or ...).)
I think this can be done with 20 or so statements in this one function.
Please let me know if you think there is a better way to handle this. I
will send you the code fragment when it is working.
[Ed. - No need to add code to MS-Kermit; this is addressed by Sim3278 code
already -- each terminal definition has a flag indicating whether a
character is left by hitting a function key; if so, Sim3278 will erase it
after CR is entered.]
3. I don't have a good environment to test kermit at 9600 baud. My limited
testing looks OK. Do you anticipate any problems?
[Ed. - No.]
4. Sim3278 doesn't support highlighting for the vt52 (bless their hearts),
which makes PROFS' calendar system unusable (not quite everyone considers
this an improvement). We probably have the clout to get this fixed on
our own, but do you happen to know of any easy answers. I don't know
much about VM, and at this point our support people are very supportive
about solving kermit problems ... but thanks to them I'm starting to get
"good" at vm/cms.
[Ed. - The Heath-19 emulation in IBM PC MS-DOS Kermit will have highlighting
in the next release, 2.28, coming soon.]
I hope I haven't overloaded you with questions. Any guidance you can
provide will be greatly appreciated.
Al Margolis
Pacific Bell, 120 Montgomery Street, Room 330, San Francisco, Ca. 94104
ihpn4,dual!ptsfa!abm
------------------------------
Date: Wed, 15 May 85 18:04:54 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
To: sy.fdc@cu20b.ARPA
Subject: Using Kermit to back up your micro's hard disk
Since the prospect of backing up even a modest (10 mbyte) hard disk onto
floppies is unpleasant, I have taken to using Kermit for backups. I use a
Rainbow (MS-DOS 2.11, MS-Kermit V2.27) and a VAX 750 (4.2BSD, C-Kermit, now
version 4C), hooked over a 9600 baud line. Backing up the (full) hard disk
takes about 8 hr, and can comfortably be done overnight. This process
worked just fine after I made one small change in MS-Kermit.
As you will realize, the most convenient way to handle this particular
backup is to make an image of the MS-DOS directory tree at the Unix end,
and to make a giant MS-DOS batch file using local "cd" commands and
MS-Kermit "remote cwd" commands to move stuff. That is, the process
involves
o Building (manually) a copy of your micro's hard disk directory tree at
the Unix end,
o From the top of this tree running C-Kermit (with file type binary) as a
server, and
o Using the command-line control available in MS-Kermit by means of a big
batch file that looks like
cd \
mskermit send *.*
cd dir1
mskermit remote cwd dir1
mskermit send *.*
cd ..
mskermit remote cwd ..
...
and so on through the tree until
mskermit finish
Building the batch file is much eased by having a program like "tree"
to lay out all the directory names. It is in any case easier than just
sitting for an hour changing floppies every 3 minutes.
You will realize, however, that the impediment to all this is the fact that
the "remote cwd" command in MS-Kermit demands a password for the new
directory and will not accept input from a batch file for that purpose.
This may be a limitation in the protocol, but it seems to me that "remote
cwd" should request a password only if the other Kermit demands it (Unix,
of course, does not password-protect directories).
To solve this problem, I simply removed the code in MS-Kermit that requests
and processes the password. This is easily done, although the code is not
in front of me so I don't remember exactly where it lives. Perhaps there
should be an option in future versions of micro kermits to omit the
password request (or two commands: "remote cwd" to skip password, "remote
cwdp" for password-based systems).
In any case, backing up this way is a pleasure beyond words compared to the
bad old days, and I commend it as YACUK (Yet Another Creative Use of Kermit).
Tony Movshon
[Ed. - The next release of MS-DOS Kermit will fix the Password prompt and
input to work the same way as the rest of the command parsing, so that the
REMOTE CWD command will be usable from batch files and Kermit command files.]
------------------------------
Subject: Update on the OK State Kermit Server
Date: 15 May 85 11:19:26 CDT (Wed)
From: Mark Vasoll <vasoll%okstate.csnet@csnet-relay.arpa>
I have notice some people (already) having problems with getting our server
to talk to them. The problem is that they *must* use EVEN parity due to a
limitation of our communications equipment. Sorry I forgot to mention this
earlier.... UUCP bypasses this limitation in a rather gross way with which
I will not clutter up the C-Kermit code.
I also forgot to mention that when people issue a REMOTE DIRECTORY command
on our system, they should be prepared for more than 600 lines of output.
It is usually better to read the 00README.TXT file (using REMOTE TYPE
perhaps) and then do the REMOTE DIR with some kind of wildcard (like
"REMOTE DIR ck*").
Mark
[Ed. - The file KER:OKSTATE.TXT now contains an up-to-date summary of how
to get Kermit files from Oklahoma State U using either UUCP or Kermit.]
------------------------------
Date: Wed, 15 May 85 11:55:23 cdt
From: ihnp4!umn-cs!ncs-med!bi@Berkeley (Bob Isch)
Subject: Kermit for TI-990?
Does anyone have a version of kermit available for TI-990 mini-computers
running DNOS or DX10? Any pointers or ideas would be helpful. Thanks, -bi
Bob Isch -bi (612) 893-8137 ihnp4!umn-cs!ncs-med!bi
------------------------------
Date: Tue, 14 May 85 19:08:42 pdt
From: Todd H. Ogasawara <ogasawar%cod@Nosc>
Subject: HP Portable (HP110) Kermit?
Is there a Kermit for the HP Portable (aka HP110) lap portable?
Thanks in advance for any leads?
Todd Ogasawara, Computer Sciences Corp.
NOSC-Hawaii Laboratories
UUCPmail: {akgua,allegra,decvax,ihnp4,ucbvax}!sdcsvax!noscvax!ogasawar
------------------------------
End of Info-Kermit Digest
*************************
-------