Subject: Info-Kermit Digest V2 #15 Info-Kermit Digest Fri, 22 Mar 1985 Volume 2 : Number 15 Departments: ANNOUNCEMENTS - Corrections, Reminders, Notes New MVS/TSO Kermit Recalled New Kermit for Honeywell DPS-8 with GCOS New Kermit for TRS-80 Model 4 New Kermit for TRS-80 Color Computer with Radio Shack DOS UNIX KERMIT - C-Kermit Suggestions, Comments Installing Kermit on CADMUS (system V) C-Kermit Comments Revisited More C-Kermit Line Locking Problems ---------------------------------------------------------------------- Subject: Corrections, Reminders, Notes The previous issue of the digest was V2 #14; it was correctly labeled in the message "Subject:" field, but internally it said V2 #13. Sorry. I fell behind a little bit in mailing list additions, deletions, changes. They should be up to date now. There are currently 315 addresses in the Info-Kermit list, and many of them are themselves distribution lists. If you get this message and didn't want it, or didn't get it but did want it, then let me know. Some of the people who asked to be removed were not on in the first place, which means they must be getting Info-Kermit through a local redistribution list. In the previous issue I forgot to say that the new release of Brian Nelson's PDP-11 Kermit is available, as usual, via anonymous FTP from host CU20B. The files are KER:K11*.* (there are about 88 of them!); the file KER:K11FIL.DOC explains what they are. For those who haven't seen the following information before, or for a long time, here it is again, briefly: A complete collection of Kermit programs, documentation, and other files is available on CU20B, a DECSYSTEM-20, Internet host number 192.5.43.128, using the Internet FTP (File Transfer Protocol) facility: login via FTP (not TELNET) as user anonymous, any password will do, and GET or MULTIPLE GET the file or files you want. Several files are of special interest: KER:00README.TXT tells what files are available and how they are named. KER:VERSIONS.DOC lists existing versions and those in preparation. KER:CURRENT.DOC lists current versions chronologically. KER:FLYER.DOC gives ordering information for Kermit on magnetic tape. Kermit files are also available via BITnet ("SMSG RSCS MSG CUVMA KERMSRV HELP") and UUCP (from host okstate; see recent Info-Kermit messages). New files usually take a few days to find their way to these alternate sources. ------------------------------ Subject: New MVS/TSO Kermit Recalled The TSO Kermit modified at the University of Toronto for Series/1 front end support announced in the previous issue of the Info-Kermit digest has been recalled. It turns out that the modification allows it to work ONLY with the Series/1, and does not allow it to work over ordinary asynchronous connections. So now, we have three MVS/TSO Kermits: 1. The original, from U of Chicago: KER:TSOKERM.*, KER:TSODYNAL.* 2. (1), modified for Series/1: KER:TSOS1.ASM 3. The Rice University PL/I version: KER:TSORICE.HLP tells how to get it. Sorry for the confusion. ------------------------------ Subject: New Kermit for Honeywell DPS-8 with GCOS Contributed by John Huxtable of the University of Kansas in Lawrence, this new Kermit (unrelated to the other Honeywell GCOS Kermit donated by Terry Carlin of Honeywell) operates in remote mode only, is capable of acting as a Kermit server, and provides options supporting the different communications modes used on Honeywell mainframes, and all GCOS file formats. The files, including B language source, the executable program in packed-text form along with a Fortran unpacker, documentation, and ROFF documentation source, are available via anonymous FTP from CU20B as KER:HDPS8.*. ------------------------------ Here, finally, is the Model 4(p) Kermit for TRSDOS 6.1. I decided to go ahead and let you have it before I got all of the stuff that I really want to add, added. I named all of the files M4* noting that this did not confilict with any of the files we have in the distribution. [Ed. - Thanks, Greg! It looks like a very complete implementation, including VT52 emulation with key mapping and session logging, a full complement of SET commands, command and initialization files, and a script facility based on the INPUT/OUTPUT/PAUSE/CLEAR model with some extensions. The files are in KER:M4*.*, available via anonymous FTP.] ------------------------------ Subject: New Kermit for TRS-80 Color Computer with Radio Shack DOS Contributed by Wes Hubert of the University of Kansas, this new Kermit implementation runs on the TRS-80 CoCo with the Radio Shack disk operating system. It requires a machine with at least 16K memory and one disk drive, and the Radio Shack disk ROM 1.0 or 1.1. The program is available via anonymous FTP from CU20B as KER:CC*.*. ------------------------------ Date: 20 Mar 85 21:15:59-CST (Wed) Subject: C-Kermit Suggestions, Comments Just got a few more ideas of improvements to C-Kermit, and would also like to hear of anything that others have sent your way since you last posted the Bugs report. 1) How about making SET LINE look in a file for valid devices. We would like to let certain students go out through the network, and get onto other machines to use KERMIT. Since you can really create a LCK.. file for more devices than we would like, it would seem natural to limit the valid outbound lines, based on a file similar to /etc/passwd, where you have login names, passwords, and other info. This way, someone can not lock up the UUCPKER, UUCP, or CSNET lines. [Ed. - Several objections: (1) Adds yet more hair, and associated startup time to the program; (2) Doesn't really accomplish anything, since none of the other programs that use tty devices would honor this convention; (3) Starts moving Kermit into the category of software that can only be installed and maintained by the system manager -- something I want to avoid.] 2) After much frustration, I have decided that there probably really should be complete trapping of all interupts. It seems that Mark Vasoll, and my- self have this habit of hitting delete (Our ^C) in the middle of a command line when we mistype. If SIGINT is traped in the parser, and results in a parse error, than operation would be smoother. I have said something to you before about this, but now I think it is manditory that it be done. [Ed. - Yet more hair to be added to the program, but in this case, I'm afraid I have to concur; it's really bad to leave the user with an unusable terminal. I hope that we can let this question ride for a while, until after the next release. I have to do a huge amount of work to get the next release out -- merging in the VMS support, your own forthcoming V7 support, and much else -- and would prefer to have the interrupt stuff added on top of that by people who know more about these things than I do.] 3) I have already changed all printf's, that did not require any format translations, i.e. no "%s", "%d", etc... to calls to a function that I added in the chusr3.c module. This function is quite simply: outstr(s) char *s; { while (*s) putc(stdout, *s++); } This completely eliminates the problems associated with various systems different size buffers used in the printf() function. BUGS: There seems to be some problems with recognition of error packets when get is used to retrieve a file from another server. I found that when I asked for a file that did not exist, C-KERMIT kept retrying, while clearly there was a sequence of E%E%E%E%E% characters appearing on my screen. Haven't looked at this one yet, but hope to by this weekend. [Ed. - Strange. I can't reproduce this one. Please send more details.] [B Get also seems to be retrying an abnormal amount of times on certain files. This may be related to the double packet exchange that was recently discussed in the INFO-KERMIT digest. ------------------------------ Subject: Installing Kermit on CADMUS (system V) We have been using the Unix Kermit Server Program with our other kermits and have found it to be very useful. I sent you some implementation notes on the 4.1bsd versus 4.2bsd problem. Here is a new note on porting to the CADMUS. We using 'make sys3' on the CADMUS the software will compile with a warning about truncating a pointer to an integer in the files ckwart.c and ckzunx.c. When 'wart' (and 'wermit') are run they will die with 'segmentation violations' and core dump. The reason for this is the fact that the CADMUS C compiler uses 16 bit integers and 32 bit pointers. The routine malloc() was not declared as returning a character pointer (char *) and was therefore taken as returning a 16 bit integer (the default). The following change clears up the situation: char *malloc(); /* Needed by CADMUS, and probably many 68000's */ H. Morrow Long ITT-ATC Systems Center, 1 Research Drive Shelton, CT 06484 ------------------------------ Subject: C-Kermit Comments Revisited Well, I have a few responses: > ! cmd > should use the shell defined by the env var SHELL, if defined > "!cmd" should work for Unix consistency (not just "! cmd") > > [Ed. - The "!" command just does a system() of its argument. Rather than > write all the code to fork and pipe the desired shell, maybe users can > just live with typing "! csh xxx" or "! ksh yyy" if they want these > effects. A space is needed after "!" because "!" is a command keyword, > and whitespace must separate command fields. Removing this limitation > would probably make the command package a lot hairier. Maybe to alleviate > the confusion that this causes, the "!" should be renamed (back) to "shell". Using the right shell is common courtesy for interactive programs on Unix. The UW version of old C-Kermit does this, with one routine which works on all systems, I think. I understand about the parser, but "!cmd" is completely common on Unix. This may be worth special-casing if the parser can be short-cicuited on just this special case. Seems like it might be an easy bypass. > stat cmd > can't we get timing info to get effective baud rate? > > [Ed. - If you have given a "set speed" command (or -b option), then this > would be reasonable. Otherwise, the program would not necessarily have a > reliable way of determining the baud rate. I really tried to avoid all > this kind of system-dependent hair (system clocks, baud rates, etc) > because it tends to make the program grow out of proportion to its > functionality.] Fine, if it doesn't know, then it can't say, but *effective* transfer speed (not line baud rate) is the main use of the stat command anyway - I still have to use a stopwatch to figure out if it's running up to snuff, so the stat command may as well not exist. > command interface > Use the user's line kill char rather than hardwire to ^U. > Use the user's backspace char rather than hardwire to DEL/BS. > Respond to the user's interrupt char rather than hardwire to ^C. > Kermit not observing these is very annoying, since being able to > choose them is a nice (and often used) feature of Unix. This also > confuses novices. > > [Ed. - But the last guy said you should use something OTHER than the > user's line and char kill characters; can't please everyone. Also, > again the point about system independence. C-Kermit 4.0 was a pretty > clean program. 4.2 already has tons of hair added to the system-dependent > portions, and every time we add a system-related feature like this, it's > got to be added for n systems, and soon the program will be an enormous > pile of verbiage, buried somewhere in the middle of which will be the Kermit > protocol.] A question of user-friendly versus "let's all use DEC-20 control chars". The other guy had the right diagnosis, but the wrong cure: His problem goes away if you *turn off* the line kill and backspace in the tty driver (simple enough, while you're setting cbreak mode) and use the user's control chars *since they are doing the same things*. Ken Poulton (I think we're making progress - this is shorter than my last letter.) [Top-Level Ed. - I tend to agree with all this, but there are tradeoffs. One is that the program has to be maintainable, and the more system dependent features creep in, the less maintainable it becomes. Another is that the bigger it gets, the harder it is to shoehorn it into little systems (in several senses -- memory segmentation a`la Pro/Venix, memory occupation, disk space, time to load from disk, time to start up once loaded, etc etc. Let's see how the next release turns out, if I ever get time to work on it.] ------------------------------ Subject: More C-Kermit Line Locking Problems Two recently reported problems with C-Kermit "line locking" -- Problem 1: User tries to use a given line; ttopen() opens it, then calls ttlock(), which finds it locked, gives the appropriate message, and returns failure. User then exits from program. However, the ckx module still has a valid ttyfd for the line, so when doexit() is called, the line is closed. This tends to hang up the line on whoever was really using it. Problem 2: User does connect, which calls ttopen(), which reports the line is in use. However, since a valid ttyfd is left around, the next time the user does connect, it works even though someone else is using the line. Easy cure: If ttopen fails to get exclusive access, put the ttyfd back to -1. Better cure: Don't open the tty before calling ttlock. The only reason it's opened first is for the benefit of flock(). Just get rid of flock(); it doesn't do anything anyway. After calling ttlock, THEN open the tty, and then do the ioctl(ttyfd,TIOCEXCL,...) for those systems that support it. ------------------------------ End of Info-Kermit Digest ************************* -------