5-Feb-85 16:10:21-EST,5392;000000000001 Mail-From: SY.FDC created at 5-Feb-85 16:09:41 Date: Tue 5 Feb 85 16:09:41-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #1 -- New Unix Kermit To: Info-Kermit-Members@CU20B.ARPA cc: Info-Unix@BRL-TGR.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 5 Feb 1985 Volume 2 : Number 1 ANNOUNCEMENTS - New Unix Kermit Available for Testing ---------------------------------------------------------------------- My apologies for the long delay since the last issue of the Info-Kermit Digest, which was Vol.1, No.46, dated 31 December 1984. This first issue of Volume 2 is to announce a test release of the new Unix Kermit. In subsequent issues, I'll attempt to catch up on other overdue items. A new Kermit program has been written in C, initially for 4.2 Berkeley Unix. The features of this program include: . Full implementation of the Kermit protocol, except for Attribute packets: - Acts as server - Talks to server - All packet encoding and error checking options are provided - File transfer interruption - Filename collision avoidance - Binary and text file transfer . Modular construction for easy portability to other systems . An interactive command parser as well as Unix-style command line arguments . Command and initialization files . Piped operation . Improved terminal connect, with optional logging . Logs for debugging, packets, and transactions . Communication with IBM mainframes Several items on the wish list were not done for lack of time. They will probably be added in the future: . File attributes . Command macros . Login scripts . Raw file transmit The new program is called "C-Kermit" because it is intended as a basis for Kermit programs for any systems that have C compilers. Its version number is 4.0, to distinguish it from earlier releases of Unix Kermit, the most recent of which was 3.0. This prerelease test version of the program runs only under Berkeley Unix 4.2. We also intend to bring it to the following systems within the coming weeks: . DEC Pro-350 and Pro-380 with Venix (a Unix v7 derivative) . Amdahl UTS on IBM 370-series mainframes . Apple Macintosh (maybe) Support for other systems will have to be added elsewhere. The program is being "pre-released" at this time for two reasons: 1. It seems to be perfectly usable on Berkeley 4.2 systems, and is an improvement over the previous version. 2. The modular design may need some adjustment to accommodate certain systems. Before a great deal of additional coding is done, it is highly desirable to get the design and specification of the system-dependent modules stable. Therefore, please take the files, read the documentation, try running the program on your Berkeley Unix system if you have one, and send comments or bug reports to me as soon as you can. If you have a Unix system that is not Berkeley Unix, or a non-Unix system with a C compiler, please take a look at the system-dependent modules to see how they could be adapted to your system; again, if you have any suggestions or criticisms of the design, please let me know. I'm particularly interested in issues of portability. After a round or two of this, perhaps the design can be agreed upon, and then those who would like to contribute support for Version 6, System III, System V, Xenix, PC/IX, etc etc, can do so without fear of running into other people's changes for other systems. Before attempting to adapt C-Kermit to a new system, please let me know so I can tell you whether someone else is already at work on the same thing, and perhaps put you in touch. The files are on CU20B as KER:CK*.*, available via anonymous FTP. The file CKERMI.DOC provides user-level documentation as well as a description of the program organization and hints for adapting it to new systems. Within several days the files should also be available on BITNET via KERMSRV (to get started with KERMSRV, type SMSG RSCS MSG CUVMA KERMSRV HELP), and to Unix systems via UUCP from Oklahoma State University, Stillwater, OK. Here's how to UUCP to OK State: You need to set up "okstate" as a site in your "L.sys" UUCP dialing file using the information listed below. You can then issue the following command on your system: uucp okstate\!/u/kermit/ck\* /usr/spool/uucppublic (this example will retrieve the new Unix version of Kermit) The "/usr/spool/uucppublic" is chosen as the destination on your system since the destination must be WIDE OPEN (drwxrwxrwx) to everyone. You should not remove files from your uucppublic until the entire transfer is complete including any redials that are necessary. If you do remove some files our system may retransmit them, resulting in a higher phone bill for you. -- UUCP Login information -- Site Name : okstate Phone number : (405) 624-6953 (one line only) Login name : uucpker Password : thefrog Hours : 10:00pm - 10:00am central time (7 day per week) Problem : okstate!uucp-support (UUCP) reports : uucp-support%okstate@csnet-relay (ARPA) The phone number is for 300/1200 baud (bell compatible). ------------------------------ End of Info-Kermit Digest ************************* ------- 7-Feb-85 17:58:46-EST,4098;000000000001 Mail-From: SY.FDC created at 7-Feb-85 17:58:12 Date: Thu 7 Feb 85 17:58:12-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #2 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 7 Feb 1985 Volume 2 : Number 2 Topics: Unix Kermit 4.0 for Other Systems New Kermits on the Way ---------------------------------------------------------------------- Date: Thu 7 Feb 85 11:21:54-EST From: Frank da Cruz Subject: Unix Kermit 4.0 for Other Systems To: Info-Kermit@CU20B.ARPA Responses to the Unix Kermit 4.0 announcement have started to come in. As many of you pointed out, the makefile (ckermi.mak) did not work "out of the box", due to some last minute name changes. The errors were obvious, and most people got around them. There have been tentative volunteers to take care of support for various systems. Volunteers for systems not listed here should contact me so I can add you to this list, which will be kept up to date in KER:CKWHO.TXT on CU20B. If you're interested in contributing to any of the implementations listed below, be sure to coordinate with the contact, cc to me. What Who DEC VAX, 4.2 BSD SY.FDC@CU20B (Frank da Cruz) DEC VAX, Ultrix-32 SY.FDC@CU20B (Frank da Cruz) DEC Pro-350/380, Venix SY.FDC@CU20B (Frank da Cruz) IBM 370-series, Amdahl UTS SY.FDC@CU20B (Frank da Cruz) Apple Macintosh SY.WBC3@CU20B (Bill Catchings) Masscomp RTU 2.2 sob@RICE (Stan Barber) Coherent vortex!lauren@RAND-UNIX (Lauren Weinstein) Callan UniStar 300 with Unisoft 68000 System V Unix EBM@MIT-XX (Eliot Moss) ATT 3Bx, System V Chris@COLUMBIA-20 (Chris Maio) IBM PC, etc, PC/IX HFISCHER@USC-ECLB (Herm Fischer) IBM PC, etc, Xenix HFISCHER@USC-ECLB (Herm Fischer) Xenix HFISCHER@USC-ECLB (Herm Fischer) Os9 BLARSON@USC-ECLD (Bob Larson) Version 7 vasoll%okstate.csnet@CSNET-RELAY (Mark Vasoll) 2.9 BSD hipl!tony@NYU-CMSL2 (Tony Movshon) 4.2 BSD UUCP Line Locking hipl!tony@NYU-CMSL2 (Tony Movshon) By the way, there's some question as to whether UUCP line locking can actually be included in a program that distributed without any kind of license. ------------------------------ Date: Thu 7 Feb 85 17:42:42-EST From: Frank da Cruz Subject: New Kermits on the Way To: Info-Kermit@CU20B Quite a number of new Kermits have arrived in recent weeks, but have not yet been installed for distribution. They will be installed and announced over the next week or two. Here is a list: . Alpha Microsystems AM-1000, AM-100L and ELS super-micro systems, written in Alpha Micro 68000 assembler (which is different from the Motorola assembler) by Bob Rubendunst, Soft Machines, Champaign IL. . A new release of Kermit for the Cray supercomputer from Leah Miller at Los Alamos National Laboratory. . Sanyo MBC-550 support for MS-DOS Kermit, from Joe Smiley, Du Pont Co., Wilmington DE. . Burroughs 6800 Kermit from Scott Bertilson at Quest Research, Burnsville MN. . The source for the FORTH version of Commodore-64 Kermit, from Bob Detenbeck at the University of Vermont. . A new release of Harris 800 Kermit from Dave Wilson at University of Wisconsin. . Fujitsu Micro-16S support for CP/M-86 Kermit from C. Barker at World Institute for Science & Technology, Long Island City NY. . DG Dasher terminal emulation for MS-DOS Kermit from Duane Galbi, Maine-Endwell High School, Endwell NY. . Kermit in SP/Pascal for DG AOS and AOS/VS systems, also from Duane Galbi. ------------------------------ End of Info-Kermit Digest ************************* ------- 8-Feb-85 19:07:23-EST,14924;000000000001 Mail-From: SY.FDC created at 8-Feb-85 19:07:03 Date: Fri 8 Feb 85 19:07:03-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #3 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 8 Feb 1985 Volume 2 : Number 3 Departments: ANNOUNCEMENTS - MS-DOS Kermit for Sanyo MBC-550 New Cray Kermit Commodore-64 FORTH Kermit Source Available Kermit in Pascal for DG AOS, AOS/VS Systems UNIX KERMIT - More Unix Kermit Volunteers MISCELLANY - New MVS/TSO Kermit in PL/I Multics Kermit Fix Polo Kermit?? Sacred Characters, a Protocol Issue Kermit for PCjr ---------------------------------------------------------------------- Date: Fri 8 Feb 85 11:32:55-EST From: Frank da Cruz Subject: MS-DOS Kermit for Sanyo MBC-550 To: Info-Kermit@CU20B.ARPA This is to announce MS-DOS Kermit for the Sanyo MBC-550 from Joe Smiley, Du Pont Co, Wilmington DE. It requires DOS 2.11 or above. He has supplied the MSXMBC.ASM system-dependent module, plus an executable program file built from the version 2.26 sources (any volunteers to try building a 2.27 version?). He says he's still working on it, and will submit another version with full VT100 emulation at some future time. The files are on CU20B in: KER:MSXMBC.ASM - System-dependent module source KER:MSMBC.HLP - Help file KER:MSMBC.BOO - "boo" file for downloading KB:MSMBC.EXE - 8-bit binary program image ------------------------------ Date: Wed, 30 Jan 85 16:52:46 mst From: lfm@LANL (Leah F. Miller) To: sy.fdc@CU20B Subject: Cray Kermit ... has, to my knowledge, a current grand total of 4 installations: Los Alamos, Livermore Natl Lab, Sandia in Albuquerque, and Cray Research in Chippewa Falls, Wisc. So, that makes it rather a curiosity compared to some others which must have many hundreds of installations. But user acceptance has been immediate. No further updates planned. It's been a pleasure being associated with your activities. Leah Miller [Ed. - This is by way of announcing a new release of Cray-1 Kermit, which is now available on CU20B as KER:CRAY.*.] ------------------------------ Date: Fri 8 Feb 85 11:37:24-EST From: Frank da Cruz Subject: Commodore-64 FORTH Kermit Source Available To: Info-Kermit@CU20B.ARPA Bob Detenbeck of the University of Vermont has sent in the FORTH source screens for his Commodore-64 Kermit. They are in KER:C644TH.SCR on CU20B. There is also a short help file, KER:C644TH.HLP. ------------------------------ Date: Fri 8 Feb 85 16:55:09-EST From: Frank da Cruz Subject: Kermit in Pascal for DG AOS, AOS/VS Systems To: Info-Kermit@CU20B.ARPA This is to announce a version of Kermit for Data General machines running AOS and AOS/VS, written in SP/Pascal, contributed by Duane Galbi of Maine-Endwell High School, Endwell, NY. The files are in KER:AOSK2.*. The same person also contributed DG Dasher terminal support for MS-DOS Kermit, but this cannot be installed for distribution yet because changes were made to several modules, and these must be reconciled with other people's changes to the same modules. ------------------------------ Date: Fri 8 Feb 85 16:55:09-EST From: Frank da Cruz Subject: More Unix Kermit Volunteers To: Info-Kermit@CU20B.ARPA Since yesterday, several more volunteers have come forth, and some errors in the addresses of previous volunteers have been corrected. Below is the list as it stands. It continues to reside in KER:CKWHO.TXT on CU20B... Meanwhile, there seems to be agreement that the "UUCP line locking" business can be included in the Kermit program without legal entanglement if the code is original, and not lifted from a proprietary program like UUCP itself. Such code has already been contributed by Tony Movshon (see below), but is not installed for distribution yet. Another issue that is reported frequently is the length of the character string constants, particularly in ckuser.c. These will need to be shortened. What is the minimum longest string constant that the smallest C compiler will allow? Now I know why so many C programs print long messages using a printf for each line... DEC Pro-350/380, Venix SY.FDC@CU20B (Frank da Cruz) IBM 370-series, Ahmdah UTS SY.FDC@CU20B (Frank da Cruz) Apple Macintosh SY.WBC3@CU20B (Bill Catchings) Masscomp RTU 2.2 sob@RICE (Stan Barber) Coherent vortex!lauren@RAND-UNIX (Lauren Weinstein) Callan UniStar 300 with Unisoft 68000 System V Unix EBM@MIT-XX (Eliot Moss) ATT 3Bx, System V Chris@COLUMBIA-20 (Chris Maio) IBM PC, etc, PC/IX HFISCHER@USC-ECLB (Herm Fischer) IBM PC, etc, Xenix HFISCHER@USC-ECLB (Herm Fischer) Xenix HFISCHER@USC-ECLB (Herm Fischer) Os9 BLARSON@USC-ECL (Bob Larson), bdale@cmu-cs-g (Bdale Garbee) Version 7 vasoll%okstate.csnet@CSNET-RELAY (Mark Vasoll) 2.9 BSD hipl!tony@NYU-CMCL2 (Tony Movshon) 4.2 UUCP Line Locking hipl!tony@NYU-CMCL2 (Tony Movshon) Prime BLARSON@USC-ECL (Bob Larson) HP9000 Series 200 (HP9836) with HP-UX System III b-davis@utah-cs (Brad Davis) CP/M (Small C or BDS C) bdale@cmu-cs-g (Bdale Garbee) ------------------------------ Date: Wed, 16 Jan 85 15:58:40 CST From: FARRELL@RICE.BITNET To: SY.FDC%CU20B@COLUMBIA.ARPA Subject: New MVS/TSO Kermit in PL/I Rice has now completed implementing KERMIT under IBM MVS/TSO. This is a new implementation of KERMIT for the TSO environment rather than a rework of the VM/CMS code. It was written in IBM PL/I and a locally developed TSO command writing package (which is as of yet unreleased). Rice TSO KERMIT has been tested in MVS/SP 1.1.1 environment at Rice and the MVS/SP 1.3 environment at University of Chicago. This KERMIT is based on the version 5 protocol manual. It has been tested with PCKERMIT 1.20, MSKERMIT(IBM) 2.26, Rice MacKermit (in beta test), and MSKERMIT (IBM) 2.27. Server mode is also supported. We are ready to send an MVS load module, the source, and limited documentation. Because we have not yet released the command writing package used in the source, it is not possible for other users to compile the source. (We may decide to submit the package to the SHARE Library which would solve this issue.) Both Chicago and Notre Dame were able to install without modifications to the code containing calls to the command writing package. Thanks, Farrell Gerbode Rice University Computer Center [Ed. - Note, we've also received other MVS/TSO contributions, but these are based on the Chicago assembler version. A recent arrival from the University of Toronto has Series 1 support. This one will be announced when it arrives, and of course any news about the Rice MacKermit will also be passed along. Meanwhile, if somebody at the U. of Chicago (which produced the original MVS/TSO Kermit) could comment on how this version should be viewed -- a replacement for theirs, an alternate version that's only useful for PL/I sites, etc...] ------------------------------ Date: Wed 23 Jan 85 09:13:18-EST From: Paul Amaranth Subject: Multics Kermit Fix To: sy.fdc@CU20B.ARPA I think I got a fix for that strange problem that was reported in [V1 #44 of Info-Kermit]. This should work: The following code should be inserted into the procedure setup_terminal which is just before the end of the kermit_ module. My best guess is that an attempt was being made to change the fnp modes (which included half duplex) before the current transmission of text was completed. This code prevents that from happening. I talked to the fellow who experienced the problem and he said that it sometimes happened when receiving, but never sending. It also depended on system load. The only difference in the code is that on SEND, there is a time delay before the modes are changed, which would let any transmission complete. Oh well. This code has no effect on normal operation. [Ed. - For now, the patches are in the file KER:MUKMT.BWR.] ------------------------------ Date: Wed, 30 Jan 85 16:23:50 EST From: Dave Swindell Subject: Polo Kermit?? To: info-kermit@cu20b.arpa Does anyone know if a Kermit version exists for a Polo PC?? The Polo is supposedly 'IBM compatable' (what isn't), however, V2.26 IBM Kermit doesn't work on it. We haven't tried generic MS-DOS Kermit yet. I wanted to see if anyone else had any 'Polo' experience before I dive in any deeper! Dave Swindell BBN Labs [Ed. - Bill Catchings had a Polo for a evaluation. He says it is not in any way IBM compatible. They claim to be IBM compatible at the data file level; in other words they can both use the same 1-2-3 files. Let us know if generic MS-DOS Kermit works -- by the way, 2.27 generic Kermit has better support for fooling around with the port designators and file handles than 2.26 did.] ------------------------------ Date: Fri, 1 Feb 85 13:23 CST From: "David S. Cargo" Subject: Sacred Characters, a Protocol Issue To: INFO-KERMIT@CU20B.ARPA Here at Honeywell we are running into an issue that I'm sure others have encountered. I'll explain what we see happening and then ask for some discussion about what can be done. We have a number of systems which, for what ever reason, preempt certain printing characters. Sometimes these are the computer systems, and sometimes it is the network control hardware. Some of the typical characters that cause problems are the backslash (hex 5C, "\"), the pound sign (hex 23, "#"), the at sign (hex 40, "@"), and the tilde (hex 7E, "~"). These symbols are either escape characters (in which case they can make it through the network if they are doubled), hardwired editing characters, or network hardware command prefix characters. Some of the networks over which we want to use Kermit get very convoluted. There isn't any way we can see that would allow the problem characters to be doubled, or escaped in an adequate way. The only way we can see that avoids collision with "sacred" characters is to avoid using these characters at all, in much the same way that avoiding use of the control characters avoids problems. The questions that I see this presenting are: how to specify the characters that must be avoided, how to communicate the set of characters to be avoided from one Kermit to another, how to agree on the set, and how to handle the presense of such characters in the file (or data) being transmitted. The last question relates to another problem we have encountered, where the transmitted file contains characters used by the protocol ("#" for example). We can't always pick the protocol characters to match characters which are not used in the source file. What is a workable way to avoid that problem? Ideally, agreeing on the set of characters would be straight forward. Each side would be told what characters won't make it through if they are transmitted to the other end, so it won't transmit that set. Another alternative would be to not transmit any character in either set. The problems I see are in specifying the packet length (which is a number encoded into a character) and the checksum (which is a number of various size encoded into one or more characters). If some characters must be avoided some values become unrepresentable. That clearly isn't satisfactory. One possibility would be to add a character encoding mechanism which would take a packet, encode any of the forbidden characters before transmission, and reconstitute them upon receipt. This has the disadvantage of adding another layer to the protocol, requiring the negotiation of another character, and complicating the packet structure further (since its length on transmission would grow depending on the number of characters which had to be encoded). I am not sure that cure isn't worse than the disease. Still, it would provide a way for Kermits to communicate through even more hostile territory than they can now. We (at Honeywell) have pragmatic reasons for wanting some way of setting the characters that must be avoided. Others probably face the same problem. I want to open the issue up so it can be discussed, and ideally a solution agreed upon. It isn't an easy issue, but it is an important one. [Ed. - Kermit was designed on the usually correct assumption that any printable ascii character can make it from one end to the other unscathed. In the rare cases when a certain printable is sacred, like the '@' that is normally used as the TAC escape character, one can either change the Kermit programs involved to double the character (the normal method for passing escape characters through a device that looks for an escape character), or change the escape character to a nonprintable character that differs from Kermit's packet start, packet end, turnaround, and padding characters (if any), or put the device in "transparent mode". Beyond that, I'm afraid that the cure is indeed worse than the disease -- the likelihood that the required extra layers of protocol could be added to scores of existing Kermit programs (3 or 4 scores at last count) is pretty small. What's worse, the poor user would have to know to tell Kermit to do this!] ------------------------------ Date: Wed 6 Feb 85 18:08:05-EST From: Bdale Garbee Subject: kermit for pc jr. To: sy.fdc%CU20B@CMU-CC-TE Frank -- what is the status of kermit on the PC jr.? I keep getting asked about it, and it's getting harder to turn people away. I haven't done anything with the MSDOS version before.... reading back issues of info-kermit pointed me to msibmjr.*, which don't exist. Does v2.26 work, and if so, does it work only on the rs232 port? I think the guy who's really griping is using some sort of internal modem? Bdale [Ed. - The PCjr comes with a built-in modem and an RS232 port. Kermit 1.20 and later work on the PCjr's RS232 port but not on the modem. To use the RS232 port, you have to say 'set port 2', because it's COM2. We have no plans to make it work on the modem -- we don't have a PC to play with any more. Any volunteers?] ------------------------------ End of Info-Kermit Digest ************************* ------- 11-Feb-85 17:33:39-EST,14560;000000000000 Mail-From: SY.FDC created at 11-Feb-85 17:32:57 Date: Mon 11 Feb 85 17:32:57-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #4 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 11 Feb 1984 Volume 1 : Number 4 Departments: ANNOUNCEMENTS - Kermit for Alpha Micro 68000 Systems New Release of Harris 800 Kermit UNIX KERMIT - Data compression for C-Kermit fans System III Unix Kermit Bugs in C-Kermit 4.0 MISCELLANY - Kermit-MS in Color Sacred Characters, Cont'd ---------------------------------------------------------------------- Date: Mon 11 Feb 85 16:43:17-EST From: Frank da Cruz Subject: Kermit for Alpha Micro 68000 Systems To: Info-Kermit@CU20B.ARPA This is to announce Kermit for Alpha Microsystems AM-1000, AM-100L, and ELS super-micro computer systems, running AMOSL 1.2 or later, written in Alpha Micro 68000 assembler, contributed by Bob Rubendunst of Soft Machines, Champaign IL, and also contributed to the Alpha Micro User's Society and to the on-line AMUS network in Boulder CO. The files are in KER:AM*.* on CU20B, available via anonymous FTP. ------------------------------ Date: Mon 11 Feb 85 17:05:52-EST From: Frank da Cruz Subject: New Release of Harris 800 Kermit To: Info-Kermit@CU20B.ARPA This is to announce a new release of Harris 800 Kermit from Dave Wilson at the University of Wisconsin Academic Computing Center. It's written in Harris Pascal. For those Harris sites that do not have Pascal, a ready- to-execute load module is available from the Harris User Exchange. Thanks to Paul Stevens of MACC for sending it in. No mention was made of what the differences are between this version and the first one (September 84). The files are in KER:H800*.* on CU20B. ------------------------------ Date: Fri, 8 Feb 85 16:59:10 pst From: James Woods To: info-kermit@Berkeley Subject: Data compression for C-Kermit fans # "Shrivel up!" -- DEVO, from their American debut Taking advantage of the Lempel-Ziv data compressor now making the rounds on USENET/ARPANET, C-Kermit users may easily invoke the pair compress file | kermit -is - kermit -ik | uncompress for faster file transfer. How much faster? Well, the code, which runs wherever C compilers are sold, typically yields 50-60% reduction for text, 65-80% for formatted ASCII numerical data, and good rates for bitmaps. So, coupled with the fact that compress runs much faster than typical modem rates (> 60K baud on a VAX 11/750), we have a tidy savings, even after the 26.6% expansion induced by Kermit's "quoting" of control characters. The rates are somewhat less (5-10%) for machines limited to a 16-bit address space. The Kermit designers should be commended for not designing fancy data compression into the protocol itself. (This is tough to do with short packets in any case.) Of course, the Tinkertoy nature of UNIX pipelines is also indispensible for this clean separation of function. Advise for non-UNIX Kermit users -- weep! For a copy of the public domain compress code, contact Joe Orost at vax135!petsd!joe@berkeley. -- James A. Woods {ihnp4,hplabs}!ames!jaw (or jaw@amelia) [Ed. - I agree, pipes are neat. The 26.6% figure is not a fixed overhead of Kermit, by the way. Since 33/128 of the ASCII characters are non-printable, the 26.6% control-character prefixing overhead will occur only in files where all ASCII characters occur with equal frequency. In fact, most text files have only about 5% control characters. Kermit's own dumb data compression also pays off quite well sometimes -- most dramatically in short binary program files, where lots of contiguous memory is intialized to 0's.] ------------------------------ Date: Sun 10 Feb 85 23:46:41-PST From: Herm Fischer Subject: System III Unix Kermit To: SY.FDC@CU20B.ARPA Frank, ckmain: String length problems (134 & 1541). (512 max on Xenix) [Ed. - I've received reports of various maximum string constant or fprint argument sizes; the smallest so far is 128.] ckwart(178): index used in OR (arithmetic) expression... uncool. can only compare pointers to "NULL" for equality or lack thereof. index is called strchr in System III versions. [Ed. - Index will have to be defined inside wart, perhaps renamed to avoid lawsuits...] ckwart/main() lacks exit(0) which prevents System III make from going onto next make step automatically. Add exit(0) call at end of main(). [Ed. - Fixed.] ckuser: obesely oversized... break apart... many strings too long... [Ed. - Sigh... Let's only do this once.] ckxbsd and ckzbsd now outfitted with conditional compilations for: system III, bsd, Xenix, and PC/IX. I strongly support having only ONE set of "unix" modules. Anyway, that is how I did the System III (and PC/IX and Xenix 3.0 ) port. Am in final cleanup stages on it. re uucp Line Locking, I have already found two different System III versions which do it two different ways. Will compare your furnished example code to mine. Main problems are with ckuser right now: too large to handle with some compilers! several strings too long too! Herm ps - am getting messages from Xenix users with OLD version 7 based Tandy-distributed versions. It is highly doubtful that the C-Kermit for Xenix 3.0/Sys III will be retrofittable to V.7 based Xenixes. That early one was highly deficient in "unix-like" features... ------------------------------ Date: 9 February 1985 15:27-EST From: Ed Schwalenberg Subject: Bugs in C-Kermit 4.0 To: sy.fdc @ CU20B I am attempting to bring up C-Kermit 4.0 under 68000 Xenix. So far, I've encountered the following bugs: 1. ckxbsd.c function ttxin does a read(foo,bar,&count) instead of read(foo,bar,count). I don't see how this could ever have worked. [Ed. - Me neither... It's fixed now.] 2. ckxbsd.c functions ttinl and ttinc declare int c; and int ch; respectively, then do read(foo,&c,1), followed by c &= 0377. This doesn't work on machines like the 68000 that have bytes in the opposite order from VAXen. Declaring c (or ch) unsigned char fixes it, and obviates the need for the masking instruction which follows (assuming 8-bit chars). The function coninc does it right, though. [Ed. - Thanks for pointing this out; it's fixed now.] 3. ckxbsd.c function ttflui has the comment "What's this???" which agrees with the code, anyway. I see that you use one file descriptor for read and write; this code seems to think that by specifying FREAD as the argument to ioctl(TIOCFLUSH) you'll only flush input. I think it would be lots more clear and portable to have separate read and write channels. In any case, the Xenix documentation claims that the arg is ignored for TIOCFLUSH. [Ed. - 4.2BSD allows you to specify which queue's buffer to flush, read or write. For now, I just changed to comment.] 4. "C-Kermit> dir /usr/ed" results in ?File not readable, which seems to be deliberate. Is it? Why? [Ed. - Not deliberate; cmifi() checks to see if the specified file is readable, /usr/ed is a directory file, hence not readable. This will have to be fixed. Meanwhile, use "dir /usr/ed/*" or replace cmifi() with cmfld().] Other than that, it has gone very smoothly and well. Congratulations on a fine piece of work, especially the TENEX-style command completion. (I don't care for it as a user interface myself, but I'd much rather have ONE user interface than 2 (or 3, or 4...). [Ed. - Everybody wanted an interactive command parser, so I put in the one I liked best. I tried to make it easy for others to substitute other parsers to suit their tastes.] So now it works for 68000 Xenix, though I want to attack it with prof(1) and see if I can improve the performance (it loses packets over 2400 baud). [Ed. - C-Kermit works fine on a VAX with 4.2BSD at 9600 baud, using xon/xoff. It'll work even better when someone does a DMF32 driver that will support DMA. If you don't have xon/xoff, then tweaking performance is desirable so long as it doesn't interfere with portability.] ------------------------------ Date: Sun 10 Feb 85 00:53:26-PST From: Jim Celoni S.J. Subject: Kermit-MS in color To: Info-Kermit-Request@CU20B.ARPA Minor glitch in MS-DOS Kermit 2.27: When on a color display with foreground/background colors set, Kermit seems to ignore them and always write to the screen white on black, and the grey + key replaces the mode line with a black hole instead of writing background-colored spaces. +j [Ed. - Noted.] ------------------------------ Date: 8-Feb-85 20:26:40-PST From: wunder@FORD-WDL1.ARPA Subject: Sacred Characters To: info-kermit@CU20B.ARPA The "MMDF Dial-up Link Protocol" had a fairly complete mechanism for handling sacred characters. I use past tense because I think that CSNET is using MMDF II these days, and I have no information about that protocol. Anyway, here is a quick description of the MMDF sacred character (and packet length, and escape character) negotiation. This description is based on an April 1980 document called "MMDF Dial Up Link Protocol" by Ed Szurkowski. It is U. of Delaware report ud-nsf-csnet-81-002. Parts of this message are taken almost straight from that report, particularly the big diagram. This was the second version of a carefully designed protocol, and I think that Kermit could get some goodies here ("If you are going to steal, steal good."). MMDF uses a limited character set for the negotiotiation: 0-9, A-F. 16-bit packet checksums are always sent as four hex digits. The packet type is one hex digit, and the flags (Origin, EOF, and a two-bit sequence number) are in one hex digit. MMDF can actually work over a link that allows only hex digits, one escape character, and a way to send a delimited record (like following the packet with a CR). These are the packet types for the sacred characters (SC) negotiation: XPATH SC's in my transmit path (and my xmit packet size) XPATHACK acknowledge XPATH RPATH SC's in my receive path (and my rcv packet size) RPATHACK (guess) ESCAPE I will use this escape character ESCAPEACK (guess again) An XPATH packet looks like this: +-----+-----+-----+-----+-----+-----+-----+-----+-----+----//----+-----+ | Checksum | 2 |Flags|Max. Packet| Illegal Input Chars. | +-----+-----+-----+-----+-----+-----+-----+-----+-----+----//----+-----+ 1 2 3 4 5 6 7 8 9 40 Max. Packet is two hex digits which are the longest packet that this host can send. Bytes 9 through 40 are 32 hex digits which are an encoding of the illegal output characters for the host. The hex number is interpreted as a 128 bit vector (one bit for each ASCII character). If the bit is on (1) in the vector, that charcter cannot be transmitted by the host. An XPATHACK packet carries no data. It just acknowledges an XPATH packet. The RPACK packet looks exactly like an XPATH. It describes the limitations of a hosts receive path. After a host has successfully sent an XPACK and an RPACK, and received one of each from the other host, it chooses an escape character based on all this great information. The ESCAPE packet contains the normal header (checksum, type, and flags) and also has the chosen escape character encoded as (you guessed it!) two hex digits. This is the escape character that this host will use to transmit data. The other host chooses its own escape character. All illegal characters are sent escaped, either with special control character forms (like M for carriage return) or with the general ## form, where ## is two hex digits corresponding to the ASCII value of the character which has been escaped. The protocol is used like this: Host A Host B ---- - ---- - <--- XPATH [Host B's xmit limitations] XPATHACK ---> <--- RPATH [Host B's rcv limitations] RPATHACK ---> XPATH ---> [Host A's xmit limitations] <--- XPATHACK RPATH ---> [Host A's rcv limitations] <--- RPATHACK <--- ESCAPE [Escape character that Host B will use] ESCAPEACK---> ESCAPE ---> [Escape character that Host A will use] <--- ESCAPEACK DATA ---> <--- DATAACK [repeat as necessary] <--- DATA DATAACK ---> [repeat as necessary] QUIT ---> <--- QUITACK I threw the DATA and QUIT stuff in there so that all this wouldn't seem so pointless. DATA and QUIT are legal MMDF, of course. This shouldn't be that hard to add as an attribute (or maybe a capability bit) with some restructuring of the packet exchanges to keep the strict packet-ack rhythm of Kermit. Since Kermit philosophy forbids negotiations, the ESCAPE/ESCAPEACK might not fit in too well. The ESCAPE/ESCAPEACK must be done somehow, though, because the normal Kermit escape characters cannot escape arbitrary printing characters. In my opinion, the MMDF escaping is much much cleaner than the Kermit foobar-quoting approach, but compatability overrides elegance. Perhaps the Hex-quoting would be a separate mode. Sort of a "low gear" for weird communication paths. walter underwood [Ed. - This is undoubtedly a good approach. Too bad we didn't think of it when we designed Kermit. Again, the problems are: (1) getting the code into a significant subset of the Kermit implementations, and (2) educating users about it. The second problem is the worst -- how does a "naive" user know that if you are connected to Datex-P via a satellite link from Tymnet gatewayed via X.25 from an Internet host accessed through a TAC dialed through a (vendor-name-omitted) "smart" modem, ..., what the sacred characters are? It's hard to tell whether the effort to handle bizarre situations like this would be worth it. Maybe a good first step would be to learn exactly what roadblocks people are actually running into where an approach like this might help.] ------------------------------ End of Info-Kermit Digest ************************* ------- 13-Feb-85 18:02:00-EST,3269;000000000001 Mail-From: SY.FDC created at 13-Feb-85 18:01:09 Date: Wed 13 Feb 85 18:01:08-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #5 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Wed, 13 Feb 1984 Volume 2 : Number 5 Today's Topics: Kermit in Turbo Pascal 6800/6809 FLEX Kermit Color vs IBM PC Kermit Kermit 64 Problem ---------------------------------------------------------------------- Date: Wed 13 Feb 85 15:01:06-EST From: Frank da Cruz Subject: Kermit in Turbo Pascal To: Info-Kermit@CU20B.ARPA A preliminary version of Kermit written in Turbo Pascal is now available. It was written by Jeff Duncan (LSM.DUNCAN@DEC-MARLBORO) with an eye toward portability to the many systems that run Turbo Pascal, but the initial implementation is for the DEC VT-180 with CP/M-80. Kermit and/or Turbo aficionados are encouraged to comment upon it or send support for additional systems to Jeff. The files are in KER:TP*.*, available via anonymous FTP from host CU20B. ------------------------------ Date: Tue, 12 Feb 85 10:19 MET From: Decus <@csnet-relay.arpa,@germany.CSNET:decus@v750.ira> To: CC.FDC@COLUMBIA-20.ARPA Subject: 6800/6809 FLEX Kermit The "D68 User Group" has a Kermit for the 6800 and 6809 porocessors under the FLEX operating system. At present it is at the Alpa-Test stage. It is a minimal system (connect send receive exit) and has only been tested against a VAX/VMS Kermit by local users. If anyone has another 68xx version, is interested in comparing notes, or wants a copy when it is fit for release, they can contact: Peter Bendall Post Box 1313 2359 Hensted-Ulburg West Germany for more details. [Ed. - This will be announced when it arrives.] ------------------------------ Date: Mon 11 Feb 85 22:00:37-PST From: David L. Pike Subject: Re: Color vs IBM PC Kermit To: Info-Kermit@CU20B.ARPA I thought I'd comment on the issue of color for ibmpc kermit v 2.27. The reason for the white on black for the color display is that the variable 'curattr' is set at 07h in the file msyibm.asm, so that even if the ansi driver had a different setting this code would override it. It's fairly easy to insert your favorite value in there..... ------------------------------ Date: Tue, 12-FEB-1985 01:25 EST From: ALLAN TEO Subject: kermit 64 problem To: KERMSRV@CUVMA TO whom it may concern, I believe the current hex file for c64ker hex is corrupted in some way. The program will boot up on the commodore 64 but will crash after it has been properly saved and re - loaded. will some one in charge re-assemble another copy of c64ker m65? Thank You. (Many others have had this strange problem) [Ed. - The author of Commodore 64 Kermit (the CROSS version, not the Forth version) indicates that a new, more complete release will be available soon.] ------------------------------ End of Info-Kermit Digest ************************* ------- 15-Feb-85 18:30:42-EST,12221;000000000000 Mail-From: SY.FDC created at 15-Feb-85 18:30:18 Date: Fri 15 Feb 85 18:30:18-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #6 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 15 Feb 1984 Volume 2 : Number 6 Today's Topics: Kermit for Fujitsu Micro 16s with CP/M-86 Kermit for Burroughs 6800 Guide to MS-DOS Kermit Files New Unix Kermit Bug Report Feedback on "ckwart.c", etc. Sacred Characters, Cont'd ---------------------------------------------------------------------- Date: Fri 15 Feb 85 13:25:22-EST From: Frank da Cruz Subject: Kermit for Fujitsu Micro 16s with CP/M-86 To: Info-Kermit@CU20B.ARPA This is to announce Fujitsu Micro 16s support for CP/M-86 Kermit contributed by Chris Barker, World Research Institute for Science & Technology, Long Island City, NY. The program makes use of the Fujitsu's built-in ADM3A firmware for terminal emulation, and runs at speeds up to 9600 baud. The 86KERIO module submitted was for version 2.7 of CP/M-86 Kermit; I compiled it with the current version, 2.9, without apparent problems. The files are: KER:86*.A86 Source (all unchanged, except for addition of 86KERIO.FUJ) KER:FJ*.* Help and hex files available via anonymous FTP from CU20B. The author says he is also working on MS-DOS Kermit support for the same machine. ------------------------------ Date: Fri 15 Feb 85 13:25:45-EST From: Frank da Cruz Subject: Kermit for Burroughs 6800 To: Info-Kermit@CU20B.ARPA This is to announce Kermit for the Burroughs 6800, written in Algol by Randy McLaughlin, Metro-II, St Paul MN. The following files are included: KER:B68KERMIT.ALG Source of the B6800 Algol program. KER:B68KERMIT.NDL NDL "request sets" to replace READTELETYPE and WRITETELETYPE and associated DEFINE's. KER:B68KERMIT.DOC Documentation for B6800 Kermit. They may be anonymously FTP'd from CU20B. ------------------------------ Date: 05 Feb 85 19:54 +0100 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Info-Kermit@CU20B Subject: Guide to MS-DOS Kermit Files Hi, Frank (and all the rest of the Kermit crew at Columbia)! I miss very much a file with a complete breakdown on all the MS-prefixed files. Their number has grown beyond what is easy to manage. So, I made such a file. Here it is. My apologies for any mistakes. Hope you can keep it updated and include it in forthcoming releases of the tape. Share and enjoy! -Per Lindberg [Ed. - This very useful file, which guides your way through the bewildering array of dozens of MS*.* files, is available in KER:MSAAAA.HLP on CU20B -- the A's are so it will appear at the top of the MS*.* files in an alphabetical listing, hopefully attracting some attention.] ------------------------------ Date: Thu, 14 Feb 85 16:13:46 est From: Paul Placeway To: pritch@ohio-state.CSNET, sy.fdc%cu20b@csnet-relay.arpa Subject: New Unix Kermit Bug Report This may be old news, but I had problems bringing up Unix Kermit on a Sun Microsystems (BSD 4.2) computer. (This is ckermit as of Feb. 13 on BITNET.) Kermit would compile just fine, but would dump core when run. The fix is simple: change line 751 of ckuser.c from while (feof(tfile[tlevel]) && (tlevel > -1)) { /* If end of take */ to while ((tlevel > -1) && feof(tfile[tlevel])) { /* If end of take */ The problem is that the Vax cc(1) changes the order of the check in the if statement, but the Sun cc(1) dosn't, and so it trys to feof(tfile[-1]) which gives a core dump. Paul W. Placeway The Ohio State University (UUCP: cbosgd!osu-eddie!paul) (CSNet: paul@ohio-state) [Ed. - Thanks. The same thing happens on Pyramid and probably other Unix systems too. This fix now appears in the distributed copy of ckuser.c. Glad to hear that so little is required to make it work on the SUN.] ------------------------------ Date: Fri, 15 Feb 85 16:14:16 GMT From: Chris (K) To: info-kermit@cu20b.arpa Subject: Feedback on "ckwart.c", etc. Info & Frank: 1. WART Preprocessor: This does not compile as it stands on 11/44 under Berkeley 2.8 due to use of compiler extensions: - "unsigned char" not supported; - the same member-name may not be used in two different structure declarations unless the offset is the same. Fix is to delete line 44 and change all /CHAR/char/; and to change the member ->nxt of struct sym to ->next in lines 537, 596, 609. After these changes, it compiles but bombs with core-dump due to overlength printf string (see below). The culprit is "char *warning" on lines 66-70. Split this into 3 separate single-line strings and output by three fprintf's at line 137. [Ed. - I ran into the same problems with Wart under Venix and they're fixed in the current distribution copy, along with a replacement for the index() function, which turns out not to be portable.] 2. "printf()" lengths. The reason that wart bombed on Berkeley 2.8 is that printf() and its derivatives use a 128-byte buffer, for unpacking the formatted string into, before output. You are in dead trouble (with a core-dump) it any printf formats to longer than this. I suspect that this is a more stringent restriction than you will find in any of the micro-compilers. For what it's worth, Aztec-C for Z80 rejects strings of more than about 150 bytes. Please restrict the format strings used in printf() (& derivatives) to a single line of text; and think carefully about the resulting formatted length when strings are inserted by %s. In particular, you cannot expect to include the whole of a kermit data block and always get away with it. [Ed. - Everyone who's been working on moving C-Kermit to peanut-whistle Unix systems (like PDP-11's without I&D space) has been bitten by the printf buffer problem. As a newcomer to Unix, I must admit I was shocked that (a) there's any limitation at all, (b) the limit is so small on some systems, and (c) no checking is done for overflow. Various measures are necessary -- reducing the length of string constants, mostly in ckuser.c; using (f)puts instead of printf wherever possible. Some people are already working on this.] 3. End-of-File Markers (Visual). I don't think I trust file transfers in general. It's very nice to have some confirmation (apart from a matching closing brace) that the file you have in your hand is the whole of the one that the remote should have sent you. Could we have, as standard, something like a row of 30 asterisks at the end of every kermit source file? [Ed. - Good idea. Some day when I have time to add them to the end of 1000 files... 30K of asterisks!] 4. Menu for Parameters. The nicest way (at least to some minds) to set parameters on a micro is an interactive menu. I've written one (in C) for the RML 480Z Kermit; do you want it? It's not wholly transportable, but I can clean it up before sending. It uses up & down arrows to select parameter, right and left to toggle through up to 10 preassigned settings, alters a variable (displaying individually assigned value-description) and optionally calls an action routine as each is changed. 5 lines of help-text available on each parameter. Not yet implemented is a facility to enter a hex or char value for a parameter. No limit (except storage) to the number of parameters it will handle. I'd have to get RML's permission to release it, since they paid for the work; but I think it would be given. Of course, this is not a practical way to set parameters in Server mode; but I don't see Server being of much use on a single-user micro. I expect to make the 480Z answer an incoming PSTN call and respond to GET/SEND; and that's all. [Ed. - ckuser.c does attempt to provide menus for commands and settings by allowing you to type '?' any time in a command. This is "menu on demand" -- the experienced user need not be constantly confronted with menus, but inexperienced users can get them when needed. 'set ?' gives a menu of parameters; 'set parity ?' gives a menu of the parity settings, 'help set parity' gives a fuller explanation of parity, etc. All this works without knowing anything about the terminal -- no termcap, curses, no reliance on terminal-dependent function keys.] 5. General. It'll be some time before I can do anything much with the new C-Kermit, but it looks a fine job. In particular, it should be very easy to extract the whole of the protocol and parameter handlers for use on systems whose architecture and command-language differ markedly from unix. I will feed back info as I get on with it. Thanks. Chris Kennington. [Ed. - Thanks -- that's the idea. We hope to use ckprot.w and ckfns.c as the core of a new Macintosh Kermit -- the user and system interfaces will be totally different. There are a few other problems that have to be resolved, too. Perhaps the biggest one is reworking the logic used in switching between connect and protocol to prevent some Unix implementations from releasing and possibly hanging up the line whenever one escapes back to command level. Herm Fischer (HFISCHER@USC-ECLB) is working on this, plus some of the problems listed above, while creating versions of C-Kermit for System III, PC/IX, Xenix, etc. There should be some results to announce soon.] ------------------------------ Date: Fri, 15 Feb 85 02:21 EST From: Paul Schauble Subject: Sacred Characters, Cont'd To: sy.fdc@CU20B.ARPA About two years ago I did a study for Honeywell on all of the then current asynchronous communications protocols. The conclusion was that Kermit could not be implemented on their mainframes because they reserved @ as a non-changeable character delete. I believe that ARPANet users also have problems with this character. Because of the problems with various networks, forbidden characters have to be specified by the user. Just provide a SET that can be put in the start-up and assume that the implementor will build in those that are sacred to the operating system. You still have to communicate them to the other end. What I would like to see is a Kermit II protocol, that can be non-compatable with Kermit I. There is a lot of useful accumulated experience now, and it would be a real shame to not be able to use it. Kermit II would have windowing, sacred character negotiation, packet size negotiation, and maybe multiple logical channels. Is this politically possible? Paul [Ed. - I agree that these issues should be addressed by Kermit II -- there's not much chance of fixing all the Kermit I's out there. And while we're at it we could add some other things too: dynamically changing block check types (each packet tagged with its block check type, to avoid all the stupid negotion and confusion presently required to switch among them, and to allow Kermits to adapt themselves on the fly to changing line conditions), automatic detection of parity, allowance for negotiations occuring at any time during a transaction, a mechanism to allow a file transfer to be interrupted and continued (e.g. when a diskette fills up), etc, etc. But who has the time to write the specification, and who has the time to write the many implementations? Actually, it might not be so bad if the new C-Kermit is used as a starting point...] ------------------------------ End of Info-Kermit Digest ************************* ------- 19-Feb-85 11:51:07-EST,8058;000000000001 Mail-From: SY.FDC created at 19-Feb-85 11:45:51 Date: Tue 19 Feb 85 11:45:51-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #7 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 19 Feb 1985 Volume 2 : Number 7 Departments: ANNOUNCEMENTS - New Release of CP/M-80 Kermit UNIX KERMIT - Os9 C-Kermit Informal Work/Dicussion List C-Kermit Filenames, Dialing Problems With C-Kermit Options ---------------------------------------------------------------------- Date: 18 Feb 1985 23:39 PST From: Charles Carvalho Subject: New Release of CP/M-80 Kermit To: Info-Kermit@CU20B Version 4.05 of CP/M-80 Kermit is ready for testing. Basically, all I did was merge the changes I've received, with minor modifications. There will still be further releases after this (see below). Here are some quick notes on what's in v4.05: From Hal Hostetler: Remember the current port, and display it in the output from the STATUS command. Fix some screen positioning errors in the file transfer commands; clear the screen when file transfer is aborted with ^C. Support Lobo MAX-80 computer. From Paul Milazzo, Rice University: Extend H89 support (add SET SPEED and ability to send BREAK). Use BDOS version number to determine proper algorithm for disk space calculation. (CPM3 users no longer have to run the generic version) From Joe Smith, Colorodo School of Mines: Support the Northstar Horizon with Northstar CP/M and SIO-4 board. From Vanya J. Cooper, Pima Community College: Fix the checks for valid characters in CP/M filenames. The characters <>.,;:?*[]_%|()/\ are not permitted; lower case letters are converted to upper case. If the flag "ffussy" in the linkage section is set (at compile time, or by patching), we are more liberal. The other special characters are always permitted; this means you can erase those filenames with ampersands from within Kermit. Fix problems with reparsing "?" in filespecs; also check for legality of wildcards. Add a fairness count to the input loop in CONNECT mode, so that the keyboard doesn't get locked out when the printer is running the same speed as the modem line. Major improvements in logging: use the large buffer; allow logging to be suspended (Q) and resumed (R) during CONNECT mode; retain the logging status and filename across multiple CONNECT sessions, incidentally fixing the horrendous bug where a file could be overwritten if the FCB was reused between the LOG command and the CONNECT command; add the SET LOGGING ON/OFF commands to control logging (LOG enables logging and specifies the name of the logfile; SET LOGGING ON uses the last specified logfile or KERMIT.LOG if none was given). If the logfile already exists, it will be appended to, rather than overwritten. Add connect mode P command to toggle printer on and off. Add separate conditional for the Xerox 820; it's just different enough from the Kaypro to be a pain. The large buffer size has been dropped to 8K bytes (from 16K); this should help the systems that counldn't transfer larger files because of protocol timeouts while the buffer was being written to disk. I haven't implemented the commands to change the timeouts yet, which is the ideal solution. I received a fix for the DECmate to IBM problem (where the DECmate swallows the turnaround character), but it's not in this version. I also have a CP4SYS for multitudes of Apple configurations, from Jonathan Beeson and Francis Wilson of Columbia Teachers College, but it has persuaded me that it is time to split up CP4SYS.ASM. Not one version per system, yet, just per family. Most of the "inout"-type systems could stay together, for instance; with another file for the "iobyt" systems. I haven't tested version 4.05 extensively, but I have verified that it compiles for all machines. (I've also tried assembling some configurations with MAC80). The files are available via anonymous FTP from CU20B as KER:CP4*.*. A list of the specific files is in KER:CP4AAA.HLP. The previous version, 4.03, will still be available for a limited time as KO:CP4*.*. Users of Kermit on the various CP/M systems are encouraged to get the new version, try it out, and report how or whether it works to CHARLES@ACC, cc to Info-Kermit. ------------------------------ Date: Sat 16 Feb 85 00:54:02-PST From: Bob Larson Subject: Os9 C-Kermit Informal Work/Dicussion List To: info-kermit@CU20B Due to the interest in os9 kermit recently generated by the new Unix Kermit, I have created a redistribution list for people working on os9 kermit. If you want to be added or deleted from this list, send me mail. (There are currently six people on this list... pretty big for an obscure os.) To mail to the list, send it to me and I will remail it to the list if it is of general interest. Systems currently represented: 3 coco's, 2 non-coco 6809 (1 level 1, 1 level ?), and 1 os9/68000. Locations range from Los Angeles to Germany. Networks include arpanet, csnet, and usenet. Bob Larson Arpa: Blarson@Usc-Ecl.Arpa Csnet(?): Blarson%Usc-Ecl.Arpa@Csnet-relay Uucp(??): {ucbvax,seismo,harvard,uw-beaver}!blarson{@,%}Usc-Ecl.Arpa Others: Your guess is probably better than mine ------------------------------ Date: Sat, 16 Feb 85 11:09:53 pst From: Mark Seager To: SY.FDC@CU20B Subject: C-Kermit Filenames, Dialing I put the new version of C-Kermit up on our Vax 11/780 running UNIX 4.2 bsd last week. A few users have complained that kermit is messing around with the file names and they would like the ability to turn this "feature" off. Could another option be added so that no filename translation is done? [Ed. - You can disable the filename conversion with "set file naming literal" -- see the documentation.] Also, how does one establish a connection with another host with kermit over a modem line? I know how to get tip to dial another host and so forth, but when you exit tip our system hanges up the line. [Ed. - To do dialing, just give the "connect" command, then type the appropriate dialing commands directly to your modem (e.g. "ATD765-4321" for a Hayes-like modem), wait for a successful return code (for Hayes, a "1") then you're connected. No support is included for manipulating dialers, since there are too many different kinds, and the program is big enough (too big) already. By the way, even Kermit may give you some trouble with hanging up. The next release (this week or next, I hope) should work better -- no hanging up until the program terminates, or the line is changed.] Thanks, Mark (seager@lll-crg.ARPA) ------------------------------ Date: Fri, 15 Feb 85 23:30:25 CST From: Paul Milazzo Subject: Problems With C-Kermit Options To: Info-Kermit@CU20B.ARPA I really like the new C Kermit, but I have a small problem with it. At first glance, there doesn't seem to be any way to set block check type on the command line, or binary mode in the interactive mode. I finally tried "kermit -i", and then set block check type to 3 in interactive mode, and sent a file to my CP/M system. Sadly, the resulting file was somehow garbaged. Am I missing something? Thanks, Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX [Ed. - It's true, there's no block-check changing option on the command line. Easy to add, but the line has to be drawn somewhere. In interactive mode, use "set block-check 3" and "set file type binary". It's in the documentation.] ------------------------------ End of Info-Kermit Digest ************************* ------- 4-Mar-85 18:06:52-EST,18796;000000000001 Mail-From: SY.FDC created at 4-Mar-85 18:06:28 Date: Mon 4 Mar 85 18:06:28-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #8 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 4 Mar 1985 Volume 2 : Number 8 Departments: ANNOUNCEMENTS - Commodore-64 Kermit V1.3 Kermit-11 for TSX+ Getting PDP-11 Kermit by Phone Unix Shell Script for FTP'ing Kermit Files UNIX KERMIT - (Next prerelease C-Kermit coming this week, watch Info-Kermit) MS-DOS KERMIT - MS-DOS Kermit .BOO Files and Translation Table Troubles MS-DOS Kermit Key Redefinitions (Version 2.28 on the way, watch Info-Kermit) MISCELLANY - Kermit-32 3.0 vs VMS 4.0 Turbo Pascal Kermit for MSDOS systems. Kermit vs Sytek LocalNet 20 Kermit and TACs Crosstalk, Kermit, and India ---------------------------------------------------------------------- Date: 20 Feb 85 17:10:37 EST From: Eric Subject: Commodore-64 Kermit V1.3 To: sy.fdc@CU20B Version 1.3 is ready for release, along with documentation and a bootstrap procedure for people who do not yet have Kermit. The bootstrap procedure was written by Robert Scott Lenoil (Lenoil@Mit-XX) in CLU (available on DEC-20s' and Vaxen running UNIX, I believe). I hope to have a Fortran translation of the mainframe end shortly (it is really quite simple). This version of Kermit includes the following updates and fixes: 1) Full support for 1200 baud communications. a) Flow control, (XON/XOFF) b) Correct setting of baud rate, correcting errors in the standard RS232 Kernel routines. 2) File-Warning has been implemented, a la Apple Kermit. 3) VT52 emulation should work completely in 40 column mode. This includes printing of tabs! 4) You can set the word-size for communication (7 or 8 bit) 5) You need not exit and restart Kermit to bring into effect changes made in the communication parameters. 6) Server commands definitely work the *first* time. Enjoy! Eric [Ed. - The files are in KER:C64BOOT.* (the bootsrapping procedure), KER:C64DXL.* (the hexification program), and KER:C64KER.*. The program itself is written in CROSS, a derivative of the PDP-11 cross assembler which runs on the DECsystem-10 and DECSYSTEM-20 and generates code for various kinds of micros. The bootstrapping procedure consists of a short CLU program on the mainframe end, and a short Basic program on the C-64 end. Since most sites do not have the CLU language available, it is hoped that a version in a more common language, like C, Fortran, or Pascal, will appear soon (the CLU program is quite straightforward and should lend itself easily to translation). Meanwhile, executable versions of it are available in KB:C64BOOT.EXE (for the DEC-20) and KB:C64BOOT.VAX (for the VAX). KB: is the Kermit-Binaries area. Note that there is also another Kermit program for the Commodore-64 written in FORTH, which is available in KER:C644*.*; it has no accompanying bootstrap procedure.] ------------------------------ Date: Tue, 26-FEB-1985 11:01 EST From: Subject: Kermit-11 for TSX+ To: dftcu@cuvmb I am sending a hex file for TSX+ that works. The only restriction is that it uses virtual overlays. brian nelson [Ed. - The file is in KER:K11TSX.HEX.] ------------------------------ DATE: TUESDAY, 26 FEB 1985 FROM: BRIAN AT UOFT02 TO: SY.FDC AT CU20B SUBJECT: Getting PDP-11 Kermit by Phone I have been giving out info for people to log into my 11/70 to get current Kermit-11's. I think I may as well publish this instead of always getting calls about it. Number: 419 537-4401 After carrier, hit cr until prompted with a *. At this point type 12 followed by a carriage return. Response is SERVICE 12 START. Within a couple of seconds login will come up. Account is 254/3, no password. Instructions follow, this is a captive account running a DCL command file on RSTS T9.0. If you get SERVICE 12 UNAVAILABLE, try later. This procedure will change in June 1985 as the PDP 11/70 has been replaced by an 11/44 and a 11/785. ------------------------------ Date: Thu, 21 Feb 85 12:03:40 est From: randy@nlm-vax (Rand Huntzinger) To: info-kermit-request@cu20b Subject: Unix shell script for ftp'ing Kermit programs I have a Unix shell script (Bourne shell, sh) which, when given the prefix of a version of Kermit, or a list of prefixes, goes out and fetches those versions of the files from CU20B. Thus, the Unix command, getkermit ck cpm will start FTP, connect to CU20B, properly fetch C-Kermit and CPM Kermit and write the files in the current directory with Unix palatable file names. It properly changes modes from ASCII to TENEX when transferring binary files. I've found this script very useful in keeping the relevant versions of Kermit here up to date. I'm sure you at Columbia will appreciate that it encourages transferring only what you need. [Actually, I think you could transfer the entire distribution with the command "getkermit ''", but I haven't tried it] The only problem with this script is that it depends upon a bug in the Unix FTP program being fixed. In the vanilla 4.2 BSD ftp program, a mget (multiple get) command issued in tenex (binary) mode fails on the directory read. We've fixed that here, but it may not be fixed at all other sites. The text of the script follows, you can do with it what you see fit. [Ed. - It's in KT:UXFTP.SH. KT: is the Kermit-Tools area.] ------------------------------ Date: Thu, 21 Feb 85 14:14 EST From: Alan H. Holland To: Frank da Cruz Subject: BOO Files and Translation Table Troubles In my last note to you, I mentioned that I was having a hard time using MSPCTRAN.BAS to turn MSIBMPC.BOO into a executable EXE file. In your reply, you mentioned that the problem could be in a translate table somewhere. You will be happy to know that the trouble is at my end. MSIBMPC.BOO gets from KERMSRV thru BITNET to my account on our VM/CMS system intact. It is when I download it to my IBM PC that it gets hurt. At our particular VM/CMS site, there is a terrible confusion surrounding the ASCII tilde, the ASCII carat, and the EBCDIC not characters. During the download, the characters that were originally tilde and carat all get turned into tilde characters. Not good, but not your problem. I solved my problem by having KERMSRV send MSIBMPC.BOO to a VAX/VMS system to which I have access, and then downloading the file from there. That also allowed me to discover how the VM/CMS system was damaging the file, by comparing versions on the IBM PC and working backwards. --Alan Holland FEAHH at VPIVM1 on BITNET [Ed. - This sort of thing has proved a common problem on IBM mainframes. To this day, there is no consistent, "standard", invertible ASCII/EBCDIC translate table. This raises the interesting question of how Kermit packets, which themselves may contain any printable ASCII character, will survive in such an environment (see discussions of "sacred characters" in previous digest issues). The Kermit User Guide and Protocol manual list the recommended ASCII/EBCDIC translations.] ------------------------------ Date: 27 Feb 85 18:05:14 EST From: Ken Burner To: Info-Kermit@CU20B Subject: MS-DOS Kermit Key Redefinitions (Using Version 2.26). I have occasion to use both IBM and DEC systems frequently. I have a long list of key re-definitions for the IBM that are not needed on the DEC. Is there an easy way to "clear" all key bindings to the default setting without exiting and re-running the program? -Ken Burner [Ed. - We'll look into putting a command into the next release to do this. For now, the best thing is to have a key redefinition command file for each system you want to connect to, or else keeping Kermit in a RAM disk so that exiting and restarting isn't so painful.] ------------------------------ Date: Thursday, 21 Feb 85 11:04:34 EST From: rmcqueen (Robert C McQueen) @ sitvxa Subject: Kermit-32 3.0 vs VMS 4.0 To: Info-Kermit @ cu20b The Kermit-32 processing of LOCAL commands and incoming REMOTE commands does not work correctly under VMS 4.0. This is because Digital has changed how DCL and mailboxes interact. This will be fixed in Kermit-32 3.1 which we are now working on. Kermit-32 3.1 will also fix the problem with the CONNECT command when the user is on an RTA. This is because RTAs don't work exactly like terminals in all respects. It is hoped that we will be able to get this out in the next couple of weeks. ------------------------------ Date: Thu, 21 Feb 85 14:03 EST From: VIC@QUCDN To: sy.fdc@cu20b Subject: Turbo Pascal Kermit for MSDOS systems. I have written a Kermit in Turbo Pascal for IBM PC compatable computers. It has most of the features of the current MsDos version. Why reinvent the wheel? Why not build on the MsDos version? Although the current Kermit-MS has an overwhelming number of features, it is lacking in two areas which can not be corrected by adding more code. The two short comings are ease of use and ease of modification. A full feature Kermit written in turbo pascal can be completely compiled within 2 mins. Compare that with the 15 to 20 minutes for assembling each module of the KERMIT-MS. In addition pascal code is much easier to read than assembler. I am amazed at the amount of effort and coding that has gone into putting new features into KERMIT-MS. It must be hundreds of man-hours of effort. In my version of kermit, I have attempted to minimize the number of commands and options. I have also minimize the number of keystrokes. For example all option can be specified with just one command line. We can also change options as we CONNECT. eg.'CONNECT 9600 Full Odd ' This will connect modem at 9600 baud in full duplex mode and odd parity. It could be abbreviated as 'C 96 F O' An attempt was made to seperate the code into three areas. General kermit code, MsDos dependent code, and hardware dependent code. I expect I will have a CP/M version within a month for an KayproII and an Apple2E. [Ed. - This person has been put in touch with Jeff Duncan, who recently submitted another Turbo Pascal Kermit, but for CP/M. I hope the result will be a common Turbo version for MS-DOS, CP/M, and maybe Apple DOS.] ------------------------------ Date: Sunday, 24 February 1985 08:06-MST From: Jerry Lotto Subject: Kermit vs Sytek LocalNet 20 To: Info-Micro@BRL KERMIT can work over a SYTEK net (LocalNet 20). Some problems though. One thing that I have found to be reliable is to set all packet sizes to 80 characters. This is especially true of the new C-Kermit and VMS KERMIT. For MS-DOS KERMIT, receive and send packet sizes are set individually. I also tell the C-Kermit side that I want file type binary. If I am sending a 7-bit file the eighth bit does not get set anyway. This setup has worked transferring a file from a UNIX machine (in server mode) using telnet to another UNIX machine (a VAX) through a SYTEK connection to a line driver connected to a VMS vax running "vaxnet" who in turn passed everything to an IBM-PC AT. The transfer was a wildcard transfer of eight bit files without quoting in both directions at 9600 baud (slowest connection, and gave NO errors. Hats off to the KERMIT crew!) ------------------------------ Date: Wed, 27 Feb 85 14:09:34 EST From: Brian_Borchers%RPI-MTS.Mailnet@MIT-MULTICS.ARPA To: INFO-KERMIT%CU20B@MIT-MC.ARPA Message-ID: <229053@RPI-MTS.Mailnet> Our mainframe supports VT52's, but expects them to have AUTOWRAP set on. That is, if the cursor is in column 80, and another character arrives, the VT52 should move to the next line and put the character there. It turns out that MSKERMIT in HEATH-19 emulation mode doesn't do this. Is there anyway to get MSKERMIT to do this, and if not, would it be possible to include this feature in a future version of MSKERMIT? [Ed. - MS-Kermit 2.26 and later respond to escape sequences from the host to control line wrap. ESC v turns on line wrap, ESC w turns it off. Maybe a future release of the program will include a command to control this as well.] ------------------------------ Date: Mon, 25 Feb 85 15:49:04 EST From: Edward Haines Subject: Kermit and TACs To: sy.fdc @ cu20b.arpa Using Kermit with an InterNet Terminal Access Controller (TAC). There are some conditions that must be met to successfully use Kermit on a personal computer through a TAC. Flow Control The buffer size for a terminal port on a TAC is typically about 64 bytes. (The size is a configuration parameter.) Since the default packet size in Kermit is about 96 bytes it is quite likely that buffer overflow will occur. Some possible solutions: 1. Enable flow control in Kermit on the PC and on the TAC. Many PC versions of Kermit implement XON/XOFF flow control. In particular, the new MS-DOS version does for the IBM PC. To enable flow control on the TAC issue the TAC commands @Flow Input Start @Flow Output Start These are usually abbreviated @f i s and @f o s. Note that flow control is not compatible with binary mode (except see note below). 2. Make the packet size on the PC Kermit small enough to not overflow the TAC buffer, e.g. 60 bytes. I had patched the old MS-DOS Kermit to do this. On the new MS-DOS Kermit, there is a command to set the packet size. 3. Increase the buffer size in the TAC. This is not usually practical and won't be considered further. TAC Intercept Character. The default TAC intercept character is the AT-sign. The AT-sign is also required by the Kermit Protocol. Solutions 1. Have the PC Kermit automatically double AT-signs on output. This is probably the best solution in general. This feature is available on some PC implementations of Kermit. It is not yet available on the MS-DOS version. [Ed. - It's available in CP/M-80 Kermit 4.0x.] 2. Change the TAC Intercept character with the command @Intercept I generally use @I 6 which sets the intercept character to Ctrl-F. 3. Put the TAC into Binary mode. This has the side effect of disabling the Intercept character. It also will allow you to transfer binary files without special encoding. The TAC can be put into Binary mode with the commands @Binary Input Start @Binary Output Start Some host systems allow you to engage the binary mode from the host. [Ed. - DEC-20 Kermit has a command for this.] There are several problems with binary mode: Some host systems don't support it. You lose the ability to control the TAC from the PC. You lose the ability to do XON/XOFF flow control. Binary Files It is sometimes desireable to be able to transmit an 8-bit binary file between a host and a PC. The TAC (which implements the DDN Telnet Protocol) normally provides just a 7-bit ASCII path. Solutions 1. Enable binary mode (if possible) as described above. 2. Enable 8th bit prefixing (if available) in both Kermits. (This is usually done by enabling parity.) Notes 1. You will probably get the best throughput for ASCII files by keeping the packet size as large as possible and using flow control. 2. There is not much advantage in increasing the baud rate between the PC and the TAC beyond 1200 baud because of the realatively long turnaround time for the acknowledgement packet. 3. You may have problems when going through satellite hops or multiple gateways due to the occasional very long delays. This may result in Kermit giving up. I have also seen Kermit get into a sort of resonant mode where it sends each packet twice but is otherwise succesful. [Ed. - The resonating packets usually happen when one of the Kermit programs is not capable of flushing its input buffer. See the BYTE article for an explanation of this phenomenon. Long delays can be circumvented to some extent by increasing the timeout interval; many Kermits have commands to allow this.] 4. Only the first letter of a TAC command is required. 5. It is possible to set binary mode in only one direction. For example you can set Inbound binary and retain input flow control (XON/XOFF flow is in the opposite direction). You probably don't need outbound (input to the PC) flow control when using the Kermit protocol. Ted Haines [Ed. - This file will be kept for reference in KER:DDNTAC.HLP.] ------------------------------ Date: Tue 26 Feb 85 06:30:27-PST From: Richard H. Miller Subject: Crosstalk, Kermit and India To: Info-Kermit@CU20B.ARPA Some months ago I read a few messages concerning the use of KERMIT with Crosstalk XVI. Has anything come of this? Can one use the scripting features in Crosstalk with Kermit protocols? If so, I'd be very grateful for any help. [Ed. - I have no knowledge of any progress. We gave Microstuf our standard permission to include Kermit with their product (see KER:COMMER.DOC), but haven't heard anything since an announcement appeared in PC Week a few months ago.] Now a testimonial. One of our clients is a consortium of international agricultural research centers administered by the World Bank. This group of centers is foremost in the field, and represents the state of the art in agricultural research. As you might imagine, some of the centers are located in countries without data network access. One such center is in Hyderabad, India. During the past month, we have been using KERMIT (version 2.27) on our IBM PCs and XTs to transfer files to and from Hyderabad's VAX 780. It would be understatement to say that the use of international direct dial telephone between California and India is noisy. It's horrendous. However, by reducing the packet size and twiddling a few other parameters, we have had very good success. Thanks for a quality program. Rich Miller Telematics International Palo Alto, CA [Ed. - Thanks for the kind words; it's good to hear that Kermit may be involved in actually doing something beneficial for humanity.] ------------------------------ End of Info-Kermit Digest ************************* ------- 6-Mar-85 21:53:45-EST,3104;000000000001 Mail-From: SY.FDC created at 6-Mar-85 21:53:20 Date: Wed 6 Mar 85 21:53:20-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #9, C-Kermit Release #2 To: Info-Kermit@CU20B.ARPA, Info-Micro@BRL-VGR.ARPA, Info-Unix@BRL.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Wed, 6 Mar 1985 Volume 2 : Number 9 Second Pre-Release of C-Kermit for Unix ---------------------------------------------------------------------- Date: Wed 6 Mar 85 21:43:12-EST From: Frank da Cruz Subject: Second Pre-Release of C-Kermit for Unix To: Info-Kermit@CU20B This is to announce the second "pre-release" of C-Kermit. The first pre-release (version 4.0) occurred a month ago; the program included support only for Berkeley Unix. This new release (4.2) includes support for: . 4.x Berkeley Unix (VAX, SUN) . Generic AT&T System III, System V . Microsoft Xenix for the PC/AT . Interactive on the PC/XT (PC/IX) and other systems . DEC Professional 3xx with Venix 1.0 . NCR Tower All reported bugs have been fixed (or at least fixes have been attempted), and many of the restrictions lifted. "Dial" and "script" commands have been added, along with code to support modem control and dialers, uucp line locking, and the like. The program itself has been somewhat reorganized to be more adaptable to small environments: the larger modules have been split; long character strings have been shortened. Most of the new work was done by Herm Fischer of Litton Data Systems, Van Nuys CA (HFISCHER@USC-ISIB), and there were also contributions from many others in the form of bug reports and/or fixes. NCR Tower support came from John Bray at Auburn University. The new makefile (distributed as CKERMI.MAK) embodies procedures for building all the different versions. Since the program now runs on a variety computers, large and small, it would seem relatively safe to begin adding support for other systems without fear that the program will have to be completely reorganized (again). The only systems supported by C-Kermit so far are Unix systems; rather than create a separate ckx and ckz module for each such system (since these systems tend to differ in small places, but still have much in common), conditional compilation was used within these modules. If C-Kermit is to be adapted to non-Unix systems, then a full replacement of the ckx and/or ckz modules is probably indicated. This is what we will probably do in bringing the program up on the Macintosh. The files are available via anonymous FTP from Internet host CU20B (Internet number 192.5.43.128) as KER:CK*.*. They will appear at okstate (for uucp'ing) and on KERMSRV (BITnet) shortly. If you plan to adapt this program to a new system, be sure to let me know quickly so I can prevent duplication of effort and can put people with similar interests in touch with each other. ------------------------------ End of Info-Kermit Digest ************************* ------- 7-Mar-85 18:47:41-EST,12788;000000000001 Mail-From: SY.FDC created at 7-Mar-85 18:46:59 Date: Thu 7 Mar 85 18:46:59-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #10 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 7 Mar 1985 Volume 2 : Number 10 Departments: ANNOUNCEMENTS - Old Files Moved UNIX KERMIT - C-Kermit Modules for Regulus Unix Shell Script for ftp'ing Kermit Programs, Cont'd Bug in C-Kermit C-Kermit 4.2 Problems MISCELLANY - TSX+ Kermit-11 Clarification MS-Kermit and TopView Series-1 Support in IBM Mainframe Kermit Resonating Packets, Satellite Delays to India ---------------------------------------------------------------------- Date: 7 Mar 1985 1853-EST From: Frank da Cruz To: Info-Kermit Subject: Old Files Moved Since the Kermit distribution area on CU20B has grown sufficiently large that it will no longer fit on a single reel of tape in ANSI D format at 1600 bpi, several old versions of Kermit have been moved to KE:, the Kermit-Extra area. These are: KER:PC*.* - Version 1.20 of IBM PC Kermit. Replaced by KER:MS*.*. KER:CPM*.* - Version 3.9A of CP/M-80 Kermit. Replaced by KER:CP4*.*. KER:UX*.* - Version 3.0 of Unix Kermit. Replaced by KER:UX*.*. The old files are still accessible, but now they're in KE: instead of KER:. ------------------------------ Date: 1 Mar 1985 0953-EST From: Joe Smiley, Du Pont Co. Via: LCG.KERMIT@DEC-MARLBORO.ARPA To: Info-Kermit Subject: C-Kermit Modules for Regulus I have transferred two source files for C-Kermit ckzreg.c and ckxreg.c for using C-Kermit under the Regulus (Version 4.2) operating system. These were created from the Berkeley versions and have been tested (although not extensively). The modifications were minimal. [Ed. - These changes arrived too late to be included in C-Kermit 4.2, and would have been hard to add in any case, given the reorganization that the program has suffered in the meantime. I hope Joe can add the Regulus support to the new release and send these modules to us again. Meanwhile, if anybody needs them, they're available for anonymous FTP from KE:CK%REG.* -- note, KE:, not KER:.] ------------------------------ Date: Tue, 5 Mar 85 14:58:27 est From: randy@nlm-vax (Rand Huntzinger) To: Info-Kermit Subject: Unix Shell Script for ftp'ing Kermit Programs, Cont'd The following patch, applied to the 4.2 BSD ftp program, will allow mget to work in TENEX mode, as required by my shell script to retrieve Kermit versions from Columbia. It isn't a particularly elegant solution, but it's functional. [Ed. - The shell script (announced in V1 #8), along with the ftp patch (which is too long to include here) are in KT:UXFTP.* on CU20B (The Kermit-Tools area).] ------------------------------ Date: Wed, 6 Mar 85 19:13:15 cst From: Rusty Haddock To: sy.fdc@CU20B.ARPA Subject: Bug in C-Kermit Problem: With C-Kermit (on Ultrix/BSD4.2) in server mode talking to MS-Kermit on a TI Professional a "REMOTE DIR" command from the TIPC will be displayed without carriage returns - just line feeds. All of the REMOTE commands act this way. Cause: What appears to be the cause is that the C-Kermit command "SET FILE TYPE BINARY" affects ALL output from the UNIX system. whether it's file transfer or REMOTE command. Unfortunately, you must terminate the SERVER, do a "CONNECT", and then "SET FILE TYPE TEXT" to have the server output the CRLF pair for the REMOTE commands. Fix: Sorry, I have none (yet) as I'm not that familiar with the C-Kermit source code but it may very well be easy to fix. I would think that all that would need to be done is to have the BINARY TRANSFER flag (or some such indicator) unset when transmitting REMOTE command output and restored upon completion. Your time and consideration would be appreciated. Thanks, Rusty ARPA: Haddock%Waltz%TI-CSL.csnet@CSNet-Relay.arpa Rusty@Maryland CSNet: Haddock@TI-CSL USENET: {ut-sally, convex!smu, texsun, rice} ! waltz ! haddock [Ed. - Diagnosis correct. This problem will be fixed in the next release.] ------------------------------ Date: 7-Mar-85 12:29:17-MST From: wester@FORD-COS1.ARPA To: Info-Kermit@CU20B.ARPA Subject: C-Kermit 4.2 Problems I have just compiled the new ckermit on my 11/70 running Sys V. There is one problem in ckdebu.h. The typedef unsigned long LONG caused a compile error "misplaced long". Changing this to 'typedef long LONG' resulted in a clean compile. I have not completly tested, but a preliminary test seems to work o.k. While trying to compile it on my VAX running 4.1bsd I also encountered an error. In ckxunx.c there is a line '#include ' and references to two structures 'timevalue and timezone' that are expected to be in this include file. I do not have that include file although I do have a and a neither one has either of the two referenced structures. I don't have time at the moment to work on tracing the problem further. Keep up the good work. Kermit is the best "free" software I have seen in many years. Gene Wester [Ed. - Thanks! I haven't heard complaints about the typedef from other Sys III/V places. But that's what the typedefs in ckdebu.h are for -- change 'em to fit what your compiler can do. This is the first I've heard about the time stuff on 4.1; sys/time.h is used for a couple things -- getting the current date/time string (e.g. for time stamps in the various logs) and for operation of the millisecond timer in the function msleep. If anyone can supply these functions for 4.1, please send them in! Especially if there's a way to do it that works in both 4.1 and 4.2.] ------------------------------ DATE: THURSDAY, 07 MAR 1985 FROM: BRIAN AT UOFT02 TO: SY.FDC AT CU20B SUBJECT: TSX+ Kermit-11 Clarification To clarify a point, there is NO such thing as K11TSX.HEX or K11TSX.SAV. TSX+ users need to use K11XM or K11RT4, the first uses virtual overlays the later does not. The RT version of Kermit-11 ALWAYS determines at run time if it is on RT11, PRO/RT11 or TSX+ and loads the appropiate overlay for terminal i/o correspondingly. brian nelson brian@uoft02.bitnet ------------------------------ Date: Thu Feb 28 1985 21:19:09 From: Marco Papa To: info-kermit@CU20B Subject: MS-Kermit and TopView What are the recommended values of the parameters for MS-Kermit's PIF (Program Information File) to work under TopView? Marco USC Computer Science Dept. UUCP: ...!sdcrdcf!uscvax!papa CSNET: papa@usc-cse.csnet ARPA: papa%usc-cse@csnet-relay.arpa [Ed. - We fooled with it a little bit, but then lost our TopView disk. Here's the best we can remember: Program size 100K Does map screen Can't run in background Doesn't use 8087 Usurps all interrupts It's really a little smaller than 100K, and it really doesn't usurp ALL the interrupts. It would be nice if it could run in the background while transferring files, but since it fields interrupts from the port, you can't do it. And it can't run inside a window during connect mode because it writes directly to screen memory (at least if you have H19 terminal emulation "on"). If anybody wants to try this out and send back exact instructions on how to install Kermit-MS under TopView, we'll include them with the distribution.] ------------------------------ Date: Thu, 07 Mar 85 09:32:37 PST From: KARL@USCVM (Karl P. Geiger) To: (many people) Subject: Series-1 Support in IBM Mainframe Kermit [Ed. - This messages summarizes answers to a query broadcast over much of BITnet.] Greetings GentleBeings: Thank you all for your answers to my letter. I received many "I can help" and "Please help me!" replies. Briefly, UMDB people sent me a KERMIT module, VIC@QUCDN claims to have a running KERMIT written in Pascal, SPGGTS@UCBCMSA has a running version he is willing to send along, and NJG@CORNELLA has sent me some code plus mods to CMS in UPDATE format. Finally, Daphne Tzoar at Columbia (DFT@CUVMA) sends word that she is incorporating all the interesting mods for S/1 or 7171 support into Kermit and intends to release the new version in three to four weeks. Yale people have asked "Why aren't you using YTERM? We wrote it to support just what you want." My answer, and reason for annoying so many people on the net, is Yes, we are running YTERM in our IBM PCs, but we have DEC-20s, VAX/VMSs, Unixes (Unices?), and PR1ME Rabbits all which must talk to DEC Rainbows, PRO 350's, and CP/M machines. I use YTERM in my PC and PCTRANS to up/down load files to VM frequently, but I would like a more general tool to gain access to other systems. Kermit has become the standard by consensus. Personally, I intend to wait for Daphne to complete her work and release the new Kermit. I thank everyone else for their assistance, contributions, and hard work to get Kermit running at their sites. It makes more sense to me to use the 'standard' code which springs from the fountainhead, however. I will distribute the code I have received from UMDB and CORNELLA to those who want it. Thank you all again... :Karl ------------------------------ Date: 6 Mar 1985 1820-EST From: Joe Smith (JMS@C930.Tymnet) To: Frank da Cruz Via: LCG.KERMIT@DEC-MARLBORO Subject: Resonating Packets, Satellite Delays to India I too have noticed this problem, where KERMIT sends each packed twice. I have seen it between KERMITs that do clear the input buffer. It is not a deficiency in a particular implementation of KERMIT, but instead is a problem in the KERMIT protocol. The current operation, that of resending the entire packet when there is a timeout in getting an ACK, works only if the original packet got lost. It fails when the packet gets to the other end intact and was merely delayed in transit. What I have observed is the following: KERMIT-20 sends packet of data (call this 1A) KERMIT-PC sends an ACK, but it is delayed in the network KERMIT-20 times out, and sends a duplicate of the original (packet 1B) KERMIT-20 sees the delayed ACK 1A, sends packet 2A KERMIT-PC gets duplicate packet 1B, sends ACK 1B At this point, the delay in the network is not present. Therefore KERMIT-20 gets ACK 1B immediately after sending packet 2A. Since this is not what it was expecting, KERMIT-20 resends the data as packet 2B. KERMIT-PC may be confused as to why KERMIT-20 keeps sending every data packet twice, but it stores the right data on disk and ACKs both packets. For every other packet that KERMIT-20 sends, it gets an ACK for packet "N-1" when expecting the ACK for packet "N", and sends a duplicate packet "N". The KERMIT protocol needs to be revised. Whenever an ACK for packet "N-1" is received, it should be thrown away, the SEND TIMEOUT value be increased if possible, and KERMIT should resume waiting for ACK "N". This would allow the two KERMITs to get back in sync. I would like to make a suggestion for the KERMIT II protocol. Only send duplicate packets when an explicit NAK has been received. Send a different type of packet for timeout or user hitting the RETURN key. This packet must be distinct from all other packets, and come in at least 5 flavors. 1) HELLO, ARE YOU RECEIVING, THE LAST DATA PACKET I SENT WAS #123 2) YES, I AM RECEIVING, THE LAST DATA PACKET I GOT WAS #122 3) HELLO, ARE YOU STILL SENDING, THE LAST DATA PACKET I GOT WAS #456 4) YES, I AM SENDING, THE LAST DATA PACKET I SENT WAS #457 5) HI, I AM AS SERVER WAITING FOR YOUR COMMAND With this mechanism, KERMIT would not have to blindly clear the input buffer. [Ed. - Your diagnosis is correct. But rather than wait for Kermit II, it would be sufficient to employ the heuristic "discard redundant ACKs" which you suggest, and which was also suggested in the BYTE article. This is not really a protocol issue; it's more like an implementation decision, and can be added to any Kermit program. The worst that can happen is that the second ACK will not arrive within the timeout interval (which you are free to adjust on a per-packet basis), causing retransmission of the last data packet, which is what happens now. Maybe this trick will show up in the next release of C-Kermit.] ------------------------------ End of Info-Kermit Digest ************************* ------- 8-Mar-85 17:00:29-EST,15582;000000000000 Mail-From: SY.FDC created at 8-Mar-85 16:59:24 Date: Fri 8 Mar 85 16:59:23-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #11 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 8 Mar 1985 Volume 2 : Number 11 Departments: UNIX KERMIT - C-Kermit 4.2 ready for UUCPing from okstate Oklahoma State UUCP Information C-Kermit vs Line Locking (2 messages) C-Kermit Remote Host Commands vs Binary Mode (2 messages) MISCELLANY - Resonating Kermit Packets ---------------------------------------------------------------------- Date: 7 Mar 85 23:40:01-CST (Thu) From: Mark Vasoll To: Info-Kermit Subject: C-Kermit 4.2 ready for UUCPing from okstate Well, pre-release version 4.2 of C-Kermit has arrived safely from Columbia and is ready for UUCP downloading. We are planning to post this version to Usenet's "net.sources" newsgroup tomorrow (3/8/85). We hope to prevent another outbreak of postings by providing this *one* posting while C-Kermit V4.2 is hot off the presses. We will take all possible precautions to prevent some overzealous mailers (or News handlers) from getting hungry. Please direct all questions and problem reports regarding this message, the C-Kermit 4.2 posting, and the UUCP Kermit Distribution service to the following address. Your message will be routed to the person maintaining the distribution at that time. Mail sent to my personal login will be answered, but could be delayed several days. Our UUCP line will now be available on a 24 hour basis. Unfortunately, we still can offer only one line.... Of course we would welcome donations of equipment.... :-) UUCP Kermit Distribution Assistance: UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!uucp-support ARPA: uucp-support%okstate.csnet@csnet-relay.arpa Thanks, Mark Vasoll Department of Computing and Information Sciences Oklahoma State University ------------------------------ Date: 8 Mar 85 10:00:00-EST From: Frank da Cruz To: Info-Kermit Subject: Oklahoma State UUCP Information Here again is the information about UUCP access to the Kermit distribution from Oklahoma State U: UUCP access to the complete Kermit distribution is available from the Department of Computing and Information Services, Oklahoma State University, Stillwater, Oklahoma. You need to set up "okstate" as a site in your "L.sys" UUCP dialing file using the information listed below. You can then issue the following command on your system: uucp okstate\!/u/kermit/ck\* /usr/spool/uucppublic (this example will retrieve the Unix version of Kermit) I chose "/usr/spool/uucppublic" as the destination on your system since the destination must be WIDE OPEN (drwxrwxrwx) to everyone. You should not remove files from your uucppublic until the entire transfer is complete including any redials that are necessary. If you do remove some files our system may retransmit them, resulting in a higher phone bill for you. There are 2 files available that contain information about the entire distribution. We recommend that you retrieve these files first. They are "00readme.txt" which explains the file name conventions used, and "00directory" which is a complete listing (by name) of all files in the distribution. These files will enable you to choose the right files the first time to save those high dollar phone bills. -- UUCP Login information -- Site Name : okstate Phone number : (405) 624-6953 (one line only) Login name : uucpker Password : thefrog Hours : 24 hours per day, 7 days a week Problem : okstate!uucp-support (UUCP) reports : uucp-support%okstate@csnet-relay (ARPA) The phone number is for 300/1200 baud (bell compatible). The following is a sample L.sys line (\r is a carriage return). You might want to put a time restriction on Any. ("Any2100-900" in Illinois) okstate Any ACU 1200 405-624-6953 "" \r ogin: uucpker word: thefrog Just a few notes on how to best retrieve parts of the Kermit distribution using UUCP... - Install the proper L.sys entry and test it using the debugging option of UUCICO (-x). Repeat this step until you successfully complete a "no work" connection, this will verify that your L.sys entry is correct and will minimize frazzled nerves. - Retrieve the files `00readme.txt' and `00directory' with the following commands: uucp -c -d okstate!/u/kermit/00readme.txt /usr/spool/uucppublic uucp -c -d okstate!/u/kermit/00directory /usr/spool/uucppublic You will have to escape the exclamation point if you are using the C shell (i.e. ...okstate\!/u/kermit...). - Choose the versions of Kermit that you wish to transfer and issue the proper UUCP command. Some systems don't seem to like wildcards, but in any case the wildcards will have to be escaped from your shell. The following command would retrieve the files relating to C-Kermit: uucp -c -d okstate!/u/kermit/ck\* /usr/spool/uucppublic PLEASE NOTE THE USE OF /usr/spool/uucppublic! Unless you *really* understand how UUCP's protections work you should not change this! A number of people have queued >100 files and had their systems refuse to store them in out of the way places. This results in wasted phone time! - If you are having problems connecting to our system PLEASE send mail to {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!uucp-support - Kind words also make my day! Thanks, Mark Vasoll Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!vasoll ARPA: vasoll%okstate.csnet@csnet-relay.arpa [Ed. - This file is online at CU20B as KER:OKSTATE.TXT.] ------------------------------ Date: Fri, 8 Mar 85 01:23:45 est From: Ken Yap To: sy.fdc@cu20b.arpa Subject: C-Kermit vs Line Locking I like the new C Kermit but I wonder if a couple things could be made options instead of hardwired. The scenario: we use "tip" to do our dialing out, we are not even allowed to know the phone numbers. After reaching the other system and starting up a remore Kermit there, we suspend "tip" with ~^Z, then start up a local Kermit. Unfortunately the new Kermit gets in the way by: (1) checking for the absence of a lock file in /usr/spool/uucp and (2) requiring a "set speed" after the "set line" command. Could a new settable option called say, "pre-connected", be added to circumvent these checks? I believe others might be in the same situation. Thanks for a good piece of software. Ken ------------------------------ Date: Fri 8 Mar 85 07:51:07-PST From: Herm Fischer Subject: Re: C-Kermit vs Line Locking To: SY.FDC@CU20B I like the idea of having a "preconnected" test. But that probably is a site-level thing, rather than a end-user level thing. I'd not like end-users able to set preconnected and then access lines in an unlocked fashion. So, I'd recommend some -D flag when compiling kermit for that, say an augmentation to make which adds a "-DPRECONNECT" flag when it is compiled. Of course, this is hip-shooting, and may need some tweaking to work... Herm [Ed. - Before putting this line-locking code into C-Kermit, the Unix experts (including Herm) involved had a lengthy discussion of whether and how it should be done. There are many issues, and many strong opinions; the readership of Info-Kermit was mercifully spared. The resulting code is a compromise, which, as Ken points out, doesn't work at sites that do not allow users direct access to the line or modem. Since this arrangement is likely to be site-wide, then Herm's suggestion is probably the best way out. Note that the goal of this line-locking feature is to prevent two (or more) processes (like uucp, tip, or kermit) from using the same line at the same time, for reasons of security and data integrity. At the same time, it is important that the line-locking feature not deny access to a line which is actually free. There is a fine line separating these two requirements, and strong opinions about which side to favor in ambiguous situations.] ------------------------------ Date: Fri 8 Mar 85 13:28:31-EST From: Jeff Damens Subject: C-Kermit Remote Host Commands vs Binary Mode To: sy.fdc@CU20B.ARPA In the last Kermit Digest, there was a suggestion that commands like REMOTE HOST always do newline conversion instead of obeying the image (set file type binary) flag. This will make it impossible to use kermit as a filter for binary files - for instance, one might wish to pipe kermit output to a plot filter and issue the command "remote host graph | spline | ..." to generate a graph on a mainframe and plot it locally. A more general solution to the problem would be to allow the remote kermit to receive commands from the local kermit. Then the user could say something like "remote command set file type text" to change the image setting without connecting back to the remote system and restarting kermit. [Ed. - This is the "remote kermit" command, which has been in the protocol manual for a long time, but never implemented. Maybe next release... Meanwhile, the problem reported by Rusty Haddock in the last digest will not be solved as easily as I thought.] ------------------------------ Date: Fri, 8 Mar 85 14:22:25 GMT From: Cjk@ucl-cs.arpa To: info-kermit@cu20b.arpa Subject: Resonating Kermit Packets A few further points on pervasive packet duplication (or, for that matter, triplication etc.), following on Joe Smith's analysis in info-digest 10. This sort of problem (caused by network congestion, satellite delays etc.) is quite well understood by mainframe networking buffs. There are other ways it can get going as well as the route set out by JMS. Once started, with a Kermit-type protocol (which always retransmits on timeout), it is stable and will continue until there is a network error (which fixes it, since the lost packet will be replaced by its duplicate). The most authentic way to avoid it (without changing the packet-sequences) is to ensure that the sender, acknowledger and network have timeout/delay periods related so that: (2 * Tnet) < Tsend < (Tack - 2 * Tnet) for all expected values of Tnet. Unfortunately this is going to result in rather long delays when a send packet is lost unless Tnet is quite small (which it isn't). What happens on the network concatenation I use regularly (one X25 and one LAN with a low-performance gateway) is that there is a transmission delay in both directions, both ends time out, and there are then two complete sets of packets circulating. It so happens that I am dialling in to the X25 @ 300baud, so reception is quite slow. The modem lights show that reception is actually continuous, the duplicate ack being received while the next data packet is going out (the micro has interrupt-driven read). A simple and effective recovery mechanism is to flush the input buffer at the end of the block-transmit as well as at its beginning. This will destroy the head of the duplicate block, which is all that is needed. With variable network delay, it doesn't always work at once, but will in due course. There is a risk that this algorithm will destroy a needed block if the other end turns around very fast, so perhaps it's better as an option than always on. This way the timeouts do not need to be long, so recovery from lost data still takes place quite quickly. Note, incidentally, that if the micro was doing a half-duplex transmit, it would not see the incoming duplicate block; perhaps file transfer for micros should always be arranged to be in a pseudo-half-duplex mode! What seems essential to me is that the micro-Kermit keep its user informed of the arrival of duplicate blocks. Then at least he/she can either take evasive action or curse and start rewriting Kermit. Chris Kennington. ------------------------------ Date: 8 Mar 85 12:37:00-EST From: Frank da Cruz To: Info-Kermit Subject: Re: Resonating Kermit Packets Timeouts are a complicated issue. You want the timeout interval short enough to catch missing packets without inducing undue delays, but long enough to avoid spurious timeouts. In order to set the optimum timeout, you must know the speed of the communication line (the baud rate), the length of the packet being timed, the current network delay, the packet processing time (assembly/disassembly, data fetch/store), the load on the host, and maybe other factors as well. The problem is that not all of these quantities are knowable at a given time, and on some systems not at all -- for instance some systems provide no function to tell you the baud rate of a line. Network delays can appear and disappear suddenly, so a timeout adjusted on this basis will tend to be wrong at the endpoints of such events. A host which can monitor its load can adjust its own timeout accordingly (as DEC-20 Kermit does), but the Kermit on the other end has no way of knowing about this. A micro may have a small constant packet processing time for n K worth of packets, but when the next packet comes, it must take time out to dump its buffer to disk (CP/M-80 Kermit). Etc. The packet input buffer can be cleared at various times: 1. At the beginning of a transaction: Important for clearing out stacked up NAKs from an idle server. 2. Before reading a packet: Obviously a poor idea. 3. After reading a packet: Can't hurt. It will tend to work beneficially when the network delay or the remote system load is decreasing, and have no effect at other times. Most Kermit programs do this, and it is often sufficient for getting resonating Kermits back in sync. 4. Before sending a packet: Equivalent to the previous case, except that additional time has passed in processing the packet just received, so the likelihood of finding something in the buffer (like the beginning of an unwanted packet) is increased. 5. After sending a packet: The likelihood of finding characters in the buffer is still higher, but so is the likelihood that they will be characters from the packet you're looking for. The length of the switching delay between writing and reading is crucial. If the delay is negligible, it won't hurt to clear the input buffer after sending, providing the clear function can be executed quickly. If the delay is long, or unpredictable, then case 5 would be equivalent to case 2, and you'd never be able to read a packet. C-Kermit is an excellent vehicle for experimentation with these heuristics -- it's written in a high level language and runs on a variety of systems from small PC's to large timesharing systems, and the next release will most likely embody the results of our combined experience (experiments and results welcome!). ------------------------------ End of Info-Kermit Digest ************************* ------- 12-Mar-85 19:32:17-EST,12945;000000000000 Mail-From: SY.FDC created at 12-Mar-85 19:31:56 Date: Tue 12 Mar 85 19:31:56-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #12 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 12 Mar 1985 Volume 2 : Number 12 Departments: ANNOUNCEMENTS - Info-Kermit Mail Corrected Apollo (Pascal) Kermit UNIX KERMIT - C-Kermit and RTU 2.2 C-Kermit for Unix Version 7 C-Kermit vs 8-bit Files vs Parity HP 9000 Series 500 Kermit, suggestions... New C-Kermit for VMS MISCELLANY - Resonating Packets, Cont'd Wanted: Disk-Full Handling for Floppy Based Kermits ---------------------------------------------------------------------- Date: Tue 12 Mar 85 18:48:24-EST From: Frank da Cruz Subject: Info-Kermit Mail To: Info-Kermit@CU20B Apologies to those who received several issues of the Info-Kermit Digest twice. The duplication was not caused by mail delivery problems; these issues were directed at Info-Micro and Info-Unix as well as Info-Kermit because they contained announcements relevant to the new Unix Kermit, which has been the subject of some discussion on those two lists in recent weeks. BITnet members of Info-Kermit are now addressed through the Wisconsin gateway, WISCVM, rather than the Berkeley gateway, UCB-VAX, which is being phased out. If you're a BITnet subscriber and did not receive this message, let me know! ------------------------------ Date: Sun 10 Mar 85 20:04:45-EST From: PHY1.J-GROVES@CU20B Subject: Corrected Apollo (pascal) KERMIT To: sy.fdc@CU20B.ARPA The corrected version of the apollo (pascal version) kermit, as per our conversation of the past week, is ready. I have been using it for about a week now and it seems to work properly, within its original bounds. I expect to add a number of useful features to the present code, such as terminal emulation (the Cyber terminal that is presently emulated is not useful to me) and remote capabilities. I will forward these additions to you as soon as they are complete. Phil Kravitz [Ed. - The original copy of Apollo Kermit (Pascal version) a number of lines truncated in the source file. Phil has figured out what the missing characters must have been and restored them. The updated copy is in KER:APOLLO.PAS on CU20B, available via anonymous FTP.] ------------------------------ From: Stan Barber Date: Sat, 9 Mar 85 14:50:03 cst Subject: C-Kermit and RTU 2.2 To: sy.fdc@cu20b The generic SYSIII/SYSV version of kermit 4.2 seems to compile up just fine on RTU 2.2. I will examine the code more closely to see if there are refinements that might take better advantage of the system. Line locking seems to be the only problem when the /usr/spool/uucp file is writable by UUCP and root only. Stan [Ed. - I've received a lot of complaints about the uucp line locking. Before release of this version, all Unix experts agreed that /usr/spool/uucp would be publicly writable on all Unix systems. It turns out not to be true. In fact, on some systems it may not even be readable! This whole business is a can of worms. Why Unix did not, from the beginning, in all its forms, allow a tty device to be opened with exclusive access is beyond me... The next release of C-Kermit will come with some kinds of options as to how to handle line locking.] ------------------------------ Date: 9 Mar 85 16:43:30-CST (Sat) From: Gregg Wonderly To: sy.fdc@cu20b.ARPA Subject: C-Kermit for Unix Version 7 Frank, I have the Version 7 mods made to the new C-KERMIT (Release #2). The only necessary mods seem to be in the ck[xz]unx.c files. I still would like to do more testing, to make sure it really works properly. Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University [Ed. - This will be incorporated into the next release.] ------------------------------ Date: Sat, 9 Mar 85 17:38:07 est From: hipl!tony@nyu-cmcl2 (Tony Movshon) To: sy.fdc@cu20b.ARPA Subject: C-Kermit vs 8-bit Files vs Parity If the 4.2bsd C-Kermit file-type is set to binary, parity is set to anything other than none, and the remote kermit (in this case, the old Unix Kermit 3.0) does not accept 8th-bit prefixing, C-Kermit goes ahead and sends the file anyway, despite the fact that it must know that it's stripping and throwing away all the high bits. Surely it should report an error? [Ed. - The behavior is correct, but you're right, C-Kermit should report an error in order to give the user the chance to interrupt or cancel the file transfer if this effect is not desired. The next release will issue a message when this happens.] ------------------------------ Date: 10 March 1985 22:57-EST From: Yekta Gursel Subject: HP 9000 Series 500 Kermit, suggestions... To: sy.fdc @ CU20B I managed to get the new C-Kermit running on the HP 9000 Series 500 computers. This is a completely different machine than HP 9000 Series 200. The version of Unix we have is HP-UX 3.25 bqa. We will soon get the HP-UX version 4. I'll make it run on that as well. I do not mind supplying kermit support for HP 9000 Series 500 machines. I'll outline the changes that have to be made: I used the "make sys3" option with the following changes. 1) Remove the "-i" option from the CFLAGS and LNKFLAGS in the makefile. 2) In the line "wart ckprot.w ckprot.c; cc ... " replace "wart" with "./wart" in the makefile. The reason for this is that if "." is not in the current PATH, make will fail unable to find "wart". We have an open system, and "root" does not have "." in its path in order to prevent "trojan horses". People sometimes do funny things in an open system. Sigh. 3) In the file "ckxunx.c", on line 125: Comment out, or conditionalize out the line "#include ". This file does not exist in HP-UX, the definitions are in the kernel. Similarly, in the same file on line 138: Comment out, or conditionalize out the line "#include for the same reason. 4) In the file "ckzunx.c", on line 93: Comment out, or conditionalize out the line "#include ", for the same reasons stated above. After these changes, C-Kermit will compile and run just fine. Finally, a suggestion: How about making the string "C-Kermit" which appears in all error messages, disconnect messages, default prompt, etc.. user specifiable at compile time, with "-D" flag for example, so that one can "customize" C-Kermit for a given machine by replacing it with something that identifies the machine? This will make life easier if one is going through a whole bunch of kermits. Even with two of them, it is sometimes confusing if both of the machines are running C-Kermit. Best, Yekta ( YEKTA@MIT-MC ) [Ed. - Good idea; perhaps the string could also be tied to "set prompt" at runtime. I expect your HP-9000 changes will be incorporated into the next release.] ------------------------------ From: stew%lhasa.UUCP@harvard.ARPA Date: 10 Mar 85 22:52 EST To: harvard!sy.fdc@cu20b.ARPA Subject: New C-Kermit for VMS OK, everything appears to be working. I would say it is ready for an alpha test release. Following is a complete list of the changes I had to make: CKCMD.H Added a #define for CR. CKCMD.C Changed all putchar's to conoc's. We want unbuffered output here, and that means conoc, no? Likewise getchar -> coninc. conoc(CR) added under #ifdef vax11c at the end of the input line. [Ed. - This will not necessarily be in the released version; it might break the take command, and also interactive operation on certain versions of Unix.] CKCONU.C Wrote a version of conect() that doesn't use fork(). What it does instead is call a system specific function, contti(c, src), which returns when a character is available from either console or comm. line. Also, a function, cancio(), is called at the end of the NO_FORK version of conect(). CKDEBU.H Added the parameters GOOD_EXIT and BAD_EXIT. On VMS, exit(1) is the success exit, not exit(0). CKDIAL.C Used a timed ttinc() rather than alarm(). On VMS, an alarm will not break through a pending read, so this method of timing out will not work. CKFNS2.C Used GOOD_EXIT rather than 0 in a couple of exit()'s. CKLOGI.C Used a timed ttinc() rather than alarm(). See CKDIAL.C. CKMAIN.C Used GOOD_EXIT rather than 0 in a couple of exit()'s. CKUSER.C Added a #define KERMRC ".kermrc" or "kermit.ini" under an #ifdef vax11c. Also changed some exit()'s. CKUSR2.C Added 19200 baud to the help string under #ifdef vax11c CKUSR3.C Added 19200 baud under #ifdef vax11c CKXVMS.C New file. Originally, I had this combined with CKXUNX.C. The result was 40K. The original CKXUNX.C was 30K and CKXVMS.C is under 19.5K. What do you think? CKZVMS.C New file. Figures are 27K (est.), 22.5K and 14.5K. Stew [Ed. - C-Kermit for VMS will be incorporated into a future release, depending upon when it arrives.] ------------------------------ Date: Mon, 11 Mar 85 17:50:26 pst From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:poulton@hplabs.CSNET> To: cc.fdc@columbia-20 Subject: Resonating Packets, Cont'd I ran into a problem with buffer flushing which was intended to avoid this resonating packet problem. Kermit-32 already does a flush-after-read operation. However, when talking to the HP 3000, we found that it was flushing out the XON handshake character from the 3000, causing the transfer to go very slowly. (It was never discovered when talking to IBM systems because they apparently always had sufficient delay on the IBM side to let the VAX flush before the XON came. The 3000 can send the XON soon after sending out a packet.) Flushing is, of course, not needed when talking to half-duplex machines like IBMs or HP 3000s, so the temporary fix was simple: I now have a hacked version of Kermit-32 which simply omits the flush. The moral of the story: if you add flushing on every packet (in addition to the normal flush-at-start-of-transaction) PLEASE PLEASE PLEASE turn it off when in HANDSHAKE XON or IBM_MODE. And while I'm at it, here's another request to Kermit implementors: please separate HANDSHAKE XON from the PARITY and ECHO options commonly lumped into IBM_MODE. The HP 3000 needs HANDSHAKE XON, but not the others! Ken Poulton [Ed. - Buffer flushing and line turnaround handshake can coexist, using the trick found in the new C-Kermit -- If handshaking is being done, then just redefine the packet terminator to be the handshake character. Then, once the packet is read, you can go ahead and clear the buffer. "IBM-MODE" is a hack appearing in the early Kermits -- the ones that didn't have command macros or take files or lots of different SET commands -- to allow them to talk to IBM mainframes. It's shorthand for "set parity mark", "set duplex half", "set flow-control off", "set-handshake xon", "set timer on". It's site-dependent in that not all IBM mainframes use mark parity, but otherwise it tends to do the trick. More advanced Kermits have separate SET commands for all these parameters, and also may have TAKE commands and/or command macros to let you modify them appropriately or set up new macros, like "SET HP3000". Getting these features into older Kermits is just a question of somebody doing the work.] ------------------------------ Date: 10 Mar 1985 0415-EST From: LSM.SMITH at DEC-MARLBORO To: SY.FDC at CU20B Subject: Wanted: Disk-Full Handling for Floppy Based Kermits I would like to see a new feature in KERMIT which would allow the receiving KERMIT to tell the sending KERMIT to pause indefinitely. If properly implemented, this would allow the receiver to tell the sender to pause, exit to the Operating System, format a new floppy, run KERMIT again, and allow the sender to resume. (This last step would probably require the user to supply the name of the file to store the incoming data.) This way very large text files could be stored. [Ed. - I'd like to see it, too. This is a tough issue because it requires new protocol to be defined and implemented. A workaround using present apparatus is to "set incomplete keep" on receiving kermits that have that feature. When a disk fills up, go back to the sender, copy the unsent portion of the file into a new file, and then send that. Clumsy, but if the file was 300K long, and 299K was sent successfully, it beats having to resend the whole thing...] ------------------------------ End of Info-Kermit Digest ************************* ------- 15-Mar-85 17:27:57-EST,19023;000000000000 Mail-From: SY.FDC created at 15-Mar-85 17:27:11 Date: Fri 15 Mar 85 17:27:11-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #13 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 15 Mar 1985 Volume 2 : Number 13 Departments: UNIX KERMIT - C-Kermit for NCR Tower C-Kermit v 4.2 Bug Summary MS-DOS KERMIT - Kermit for DG One? MISCELLANY - Resonating Packets + Handshaking To Ack or to Write ... Kermit Packet Length ---------------------------------------------------------------------- Date: Wed, 13 Mar 85 22:58 EST From: Larry Afrin To: sy.fdc@cu20b.ARPA Subject: C-Kermit for NCR Tower I am pleased to report that C-Kermit compiles almost perfectly and runs beautifully on our NCR Tower System V machines. (The minor compilation error was due to a global variable being defined in one place and being redefined and initialized at a later point in the same module.) Of course, this compilation required the "make sys3" command, not the "make tower1" we used for the 1.02 machines. A note on the documentation: we're novices to Kermit, and the documentation didn't explain too well (in our opinions, anyway) what the relationship is between server mode and file transfers and remote commands. Briefly, what we were doing with Kermit was to login on two different machines, bring up Kermit on both, have one of them dial in to the other system's dial-in modem to which the other Kermit has already "allocated." Then one of us would try to "get" or "send" a file to the other, or one of us would enter "server" and the other would try "get" or "send". Needless to say, this did not work. What we finally did was to dig out an old issue of Byte magazine, which told us that a user on one machine should call up Kermit, dial in to another machine, call up Kermit on the remote machine, enter "server" to the remote Kermit, escape back to command mode in the local Kermit, and then try the "get" or "send" or whatever. -- Larry Afrin Dept. of Computer Science Clemson University [Ed. - Larry also reported, and sent fixes for, many problems with the NCR Tower OS 1.02 support. The fixes should appear in the next release. The problems resulted from my attempts at fitting John Bray's Tower code for release 4.0 into what had become 4.2, without being able to test it. The documentation is just a chapter from the Kermit User Guide, the first couple chapters of which are devoted to a general explanation of Kermit. The remaining chapters, of which the Unix Kermit manual is an example, give information for each major implementation, concentrating on the areas where it differs from the general description. I thought everybody had a Kermit User Guide...] ------------------------------ Date: Fri 15 Mar 85 14:02:40-EST From: Frank da Cruz Subject: C-Kermit v 4.2 Bug Summary To: Info-Kermit@CU20B.ARPA Many people have reported problems with (and suggested cures for) C-Kermit version 4.2. These reports have been (greatly) condensed into a file CKERMI.BWR ("beware"), which is reproduced below, and which will be kept up to date in the Kermit distribution area. Some of the people who sent reports or comments are John Bray (who supplied the Tower OS 1.02 support for v 4.0, which I broke), Gregg Wonderly (okstate), James Matheson (somewhere in England), Herm Fischer (Litton Data Systems), Monty Solomon (Creative Concepts), Marco Papa (USC), Yekta Gursel (MIT), John Zsarnay (CMU), Steve Grandi (NOAO), Dan Schullman (DEC), Larry Afrin (Clemson), Scott Weikart (Stanford), Dave Robinson (JPL). There were others too; the pile is pretty thick. -- SUPPORT FOR ADDITIONAL SYSTEMS: -- VAX/VMS: Added by stew%lhasa.uucp@harvard, not available yet (see below). 4.1BSD: C-Kermit built with "make bsd" does not work under 4.1. The date/ time stuff and line locking stuff are completely different from 4.2. Also, the directory format is different, so traverse() doesn't work. Specific support needs to be added for 4.1. (John Zsarnay@CMUA) Regulus: Submitted by Joe Smiley, DuPont Co. Extensive changes to 4.0 were too hard to fit into 4.2; hope Joe can add the Regulus support to 4.2. NCR Tower, OS 1.02: Submitted by John Bray, based on 4.0, fitted into 4.2, but it doesn't work in 4.2; it will be fixed. NCR Tower, System V: Works ok -- "make sys3" HP9000 Series 500: (from YEKTA@MIT-MC): Use "make sys3", but 1. Remove -i from CFLAGS & LI 2. In ckxunx.c, don't #include or ioctl.h. 3. In ckzunx.c, don't #include. Plexus P-60 Works ok with "make sys3", but doesn't always hangup even when hupcl is on (Scott Weikart, Stanford). Masscomp/RTU 2.2: Works ok with "make sys3" (Stan Barber, neuro1!sob@rice). Pro/Venix 2.0 (field test): Works ok with "make sys3", except the "unsigned long" has to be changed to "long" in ckdebu.h; may be a bug in the new compiler (Dan Schullman, DEC). SUN: C-Kermit 4.0 with 4.2bsd support was reported to run OK on the SUN after some bugs with long strings, char vs int, etc were fixed. There is now a report that version 4.2 doesn't even compile on the SUN because of the ^L's in the source file (can this be true???), and that once compiled (by removing ^L's) it doesn't transfer files at all, but just times out after many retries of the first packet (this report from daver@cit-vax). Has anyone had any luck with C-Kermit 4.2 on the SUN? -- BUG LIST -- General problems: - Conditionalizations are not done clearly. In some cases it might be better to have compile-time flags for features, rather than systems, or generic system names, rather than specific vendor/machine names, to avoid excessive nesting or OR'ing of compile-time variables. - It might also be better to have a -D in the makefile for the system name, rather than hard-coding it into the ck[xz]*.c modules. - Program's return code might be wrong in some cases (in 4.0, it was always zero; in 4.2 some attempt is made to return correct codes for failure and success). - "quiet" (-q) flag does not turn off all error messages. Direct use of fprintf(stderr,...) should be replaced by invocations of ermsg(). - The error messages should use the current prompt (changed via 'set prompt') rather than "C-Kermit" as a prefix, to make it easier to see which Kermit a message is coming from, if you have a C-Kermit on both ends of the line. - Interrupt handling is not done particularly well, and if the program crashes or is halted while it has the terminal in a not-normal mode during command parsing or file transfer, the terminal mode is not restored. Code should be added to trap quit or panic interrupts and restore the terminal before quitting or panicking. - Many people have asked for a system-wide startup file similar to the user's .kermrc file, perhaps with a conditional way to escape from it if the user has her own .kermrc file. This notion might be extended to include the entire hierarchy system -- home -- current directory. - A deeper problem with the initialization files is that the file is only taken when the program enters interactive command dialog. To be consistent, it should also be taken when the program is run via command line arguments. - Moving the program to VAX/VMS uncovered a few remaining Unixisms: . VMS uses program return codes with opposite sense from Unix; return code values must be conditionalized. . ".kermrc" doesn't work as a file name on most non-Unix systems. . There should be a more portable way of handling baud rates tables. ckzunx.c: - In zsout() & friends, "fprintf(fp[n], s);" should be "fputs(s, fp[n]);" or 'fprintf(fp[n], "%s", s)', to prevent core dumps when s happens to contain a '%'. ckxunx.c: - Many problems reported with "uucp line locking" -- . On some systems, uucp apparently ignores the lock and breaks in anyway. . On some systems, the lock directory is write-protected. . On some systems, the lock directory is read-protected. . Reportedly on some systems (Sys III?), using dial commands and a login script pointed at a line already in use by uucp will hang up the line on uucp. Unfortunately, a lot of code will have to be added to take care of the many different ways that sites are set up to handle line contention and assignment, probably selectable by makefile compiler switches (see below). ckdial.c: - Some systems do not allow users to manipulate dialers directly. - Not easy to add support for new dialers. - Some systems never return from the 100-character rawmode read (it is assumed return is immediate, indicating how much was obtained from the input buffer). - Timed read for connect/no carrier message from modem within a general timer on the whole operation does not work on some systems. - Some systems need to have the modem explicitly hung up; close() isn't enough; e.g. ioctl(ttyfd,TIOCCDTR,0) on 4.2bsd. - On some systems, the entire output from the dialer (e.g. "CONNECT") cannot be read in a single gulp, so the buffer should be appended to between successive reads, not overwritten. ckus*.c: - Some help messages still produce core dumps on some systems. Diagnosis: the strings in these messages ('help remote', 'help set' are mentioned most frequently) are still too long for some systems. Cure: shorten them some more, and maybe replace for (i=0; *s[i]; ++i) fputs(s[i], stdout); with while (*s[0]) fputs(*s++, stdout); in hmsga() to prevent possible references to tender memory. Also, replace all printf(msg) with printf("%s", msg); - The "directory" command produces a full recursive directory listing. It should only list the current directory. On bsd systems at least, the listing can be interrupted with a single ^C, which returns you to C-Kermit> command level. Diagnosis: ??? The program just does a system("ls -l"). Why doesn't this behave the same as "ls -l" typed at the shell? - Parser for the 'get' command doesn't respond well to editing; can go into infinite loops under some conditions. - The filename 'transaction.log' is too long for some systems, and gets truncated (no harm is done, but the user is not informed and may not be able to find the file). ckcmd.c: - Some systems (such as Venix/11) swallow the erase and kill characters when the terminal is in cbreak mode. If the erase and kill characters are are ^U and DEL, then these can't be used to edit C-Kermit interactive commands. Ditto for ^R. Diagnosis: sigh, let's hear for portability. Cure (if you can call it that): Add new SET commands to allow the erase, kill, and redisplay characters to be redefined. - There's no way to break a command line and continue on the next line. Cure: add code to allow "\" followed by CR (or LF, or FF) to accomplish this. Nobody really wants to put a real CR (LF, FF) in the middle of a command anyway, right? This will make take files and login scripts a lot more readable. - No way to put comments in take files. Cure: Add a ";" or "#" command? Trailing comments will be harder. Protocol (ckprot.w, ckfns*.c): - No way to interrupt a protocol transaction until after it starts successfully. For instance, no way to interrupt the timeouts and retransmissions of the initial packet when the other side is not responding, except for killing the whole program. Cure: check for keyboard "interrupts" during the send-init process. - When receiving from a non-timed-out Kermit and missing the Send-Init packet, no NAK is ever sent, and a deadlock occurs. Diagnosis: resend() is called to resend the previous packet; there was no previous packet, so it sends an empty line. Cure: Initialize the packet buffer with a NAK for packet 0? - When parity is in use and the other Kermit cannot do 8th bit prefixing, the user is not warned that binary files will not be transferred correctly. - 'set file names literal' does not work at all. ckconu.c: - Doesn't do any particular kind of terminal emulation. It wasn't meant to. Filters can be used for this. - Performance is poor on systems that can't check the input buffer. - As structured, connect mode can't include commands to toggle logging on and off or to change settings, because forks can't share variables. ckwart.c: - Has typedef for CHAR as "unsigned short" or "unsigned char". Cure: Have ckwart.c use the typedefs from ckdebu.h, like the regular Kermit modules do. makefile: - Replace "wart ckprot.w ckprot.c" with "./wart ckprot.w ckprot.c" because "." might not be in the current path. - It was suggested that the compound entry for making ckprot.o should be broken into two entries, one for ckprot.o, one for ckprot.c, to prevent unecessary recompilations. - Some of the problems caused by access restrictions on the uucp lockfile directory might be addressed by having the makefile check and then setting an appropriate compile switch, e.g. if [ -w /usr/spool/uucp ] then make bsd "... -regular flags" else make bsd "... -DNOLOCKING" fi [Ed. - This bug list will be kept up to date in KER:CKERMI.BWR on CU20B, available via anonymous FTP. Also, the list of who's working on what is also updated frequently; it's in KER:CKWHO.TXT.] ------------------------------ Date: Fri, 15 Mar 85 09:17:57 mst From: unmvax!wampler@LANL (Bruce Wampler) To: lanl!Info-Kermit-Request@cu20b.ARPA Subject: Kermit for DG One? I have been having great success with the IBM PC version of Kermit, then tried to run it on my new Data General One portable. It seems that the DG One is ROM call IBM compatible, but they apparently have used different serial port hardware than the 8250 - thus kermit (or Cross-Talk or ASCOM for that matter) will not run on the DG One. I haven't been able to get the DG tech ref manual yet. Has anyone done the port to the DG yet? Does anyone know what hardware they are using at the serial port? I'll try the port if no one has done it when/if I get the scoop on the hardware. Thanks. Prof. Bruce E. Wampler, UNM CS Dept. [Ed. - According to previous issues of the Info-Kermit digest, the DG/1 uses an 8251 communications processor instead of an 8250 for serial i/o. The "generic DOS" version of MS-DOS Kermit does not access the i/o chip directly, but rather uses only DOS calls. Thus one might expect it to work on the DG/1, but very slowly (can anyone confirm this?). Glenn Everhart at RCA, who modified an old version of IBM PC Kermit to run on the Seequa Chameleon, says that the Seequa version uses IBM ROM BIOS calls for this, so the Seequa version (KER:SEEQUA.ASM) might work on the DG/1 if the DG/1 emulates the IBM ROM BIOS. Has anyone tried this? Is anyone working on DG/1 support for MS-DOS Kermit?] ------------------------------ Date: Wed, 13 Mar 85 12:24:37 pst From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:poulton@hplabs.CSNET> To: cc.fdc@columbia-20.ARPA, cc.fdc@cu20b.ARPA Subject: Re: Resonating Packets + Handshaking >[Ed. - Buffer flushing and line turnaround handshake can coexist, using > the trick found in the new C-Kermit -- If handshaking is being done, then > just redefine the packet terminator to be the handshake character. Then, > once the packet is read, you can go ahead and clear the buffer. If the read of the line terminator char is done in the packet reading routine, I suspect that this will cause poorer performance. Once the packet is read, C-kermit should start preparing the next packet it will send, so it is *ready* when the XON handshake character comes. I will let you know whether this is a problem when I can get the new C-Kermit running on my 4.1BSD system (it doesn't, right now). Ken Poulton [Ed. - This would only be a consideration in Kermits that are totally interrupt-driven in packet processing; I don't know of any that are. See above about C-Kermit vs 4.1bsd.] ------------------------------ Date: Fri, 15 Mar 85 15:53:37 GMT From: Cjk@ucl-cs.arpa To: info-kermit@cu20b.arpa Subject: To Ack or to Write ... A minor point which arises from the discussion of timeouts & resonating packets. Have you thought carefully about whether a data packet should be ack'd before or after the data is written to disk? The main consideration seems to be that if the OS overlaps disk I/O with other work, then the "write-to-disk" call will complete quickly and it's safe to ack early; if the disk can occupy real time (during which the communications are dead), safer to delay the ack, write to disk & risk a remote timeout. There is a case for a switch, either dynamic or compile-option. Chris Kennington. [Ed. - The decision on when to ACK varies from system to system. Ideally, one should only ACK a data packet after one has processed it successfully. If there is a failure to write to disk, an error packet should be sent instead of an ACK. In practice, a disk write might take such a long time (e.g. on a slow floppy with a lot of data buffered for it in memory) that the ACK should go out first to reduce the chance that the other system will time out before the write is completed.] ------------------------------ Date: Thu, 14 Mar 85 12:12:13 EST From: Steve Carmody To: Frank da Cruz Subject: Kermit Packet Length With the advent of high speed, extremely reliable LAN's, has there been any discussion of increasing the maximum length packet size beyond 94? Because of the large number of existing kermit implementations, I'm assuming that any such change would have to "negotiated" by the two kermits during the SEND INIT sequence, in much the same way that other optional features are negotiated. [Ed. - It would be nice to allow longer packets, but since the packet length is expressed as a single character, there's no way to increase it without changing the protocol. This could be accomplished rather painlessly by (for example) using the currently unused lengths - 0, 1, and 2 - to specify that the first 2, 3, or 4 bytes of the data field give the actual packet length. This would, as you suggest, have to be negotiated at Send-Init time. This is just an idea; if the protocol is actually changed to allow a mechanism like this, some more thought will have to go into it.] ------------------------------ End of Info-Kermit Digest ************************* ------- 20-Mar-85 16:50:46-EST,20487;000000000001 Mail-From: SY.FDC created at 20-Mar-85 16:49:53 Date: Wed 20 Mar 85 16:49:53-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #14 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Wed, 20 Mar 1985 Volume 2 : Number 13 Departments: ANNOUNCEMENTS - New Release of PDP-11 Kermit Full-Featured MVS/TSO Kermit in PL/I from Rice University MVS/TSO Kermit Has Series/1 Support UNIX KERMIT - Manual Page for C-Kermit C-Kermit 4.2 comments Bad Bug in C-Kermit? C-Kermit on Pyramid? Making C-Kermit Work on the SUN C-Kermit on Four Phase 6300 C-Kermit on Callan Unistar 300 Want C-Kermit on PDP-11 with RT11 MISCELLANY - Offer to Provide C-64 Kermit Diskettes CP/M KERMIT and Start-of-Packet Apple II Kermit for ProDOS? Please help - Tandy 2000 Kermit ---------------------------------------------------------------------- DATE: WEDNESDAY, 20 MAR 1985 FROM: BRIAN AT UOFT02 TO: INFO-KERMIT AT CU20B SUBJECT: New Release of PDP-11 Kermit There is a new version of Kermit-11 available, version 2.26. The main reason for this release is TSX+ support. The changes from v2.24 are: 1. 35% thruput improvement for RSTS/E from changes in packet reading. 2. Added ^E,^X and ^Z aborts for sending files. 3. Added SET CONSOLE 7/8 for stripping the high bit off of characters in terminal emulation for P/OS to avoid odd characters. 4. More info in help file, particularily for binary file transfer. 5. Fix server replies (some replies had imbedded control characters. 6. Change default output record format to stream ascii for RSTS/E 7. Support is finished for TSX+. Sorry it took so long, but I do not have a TSX+ system. Others had to do the work (Ned Rhodes and Tony Movshon) 8. Changes % to ? in filenames for RSTS/E for GET and REMOTE DIR. Needed since some Kermits mangle the filename if you say GET MS???.* brian nelson BRIAN@UOFT02.BITNET ------------------------------ Date: Tue 19 Mar 85 19:42:29-EST From: Frank da Cruz Subject: Full-Featured MVS/TSO Kermit in PL/I from Rice University To: Info-Kermit@CU20B There is an advanced version of Kermit for MVS/TSO written in PL/I (tested in MVS/SP 1.1.1, MVS/SP 1.3, and MVS/XA) available from Rice University. It is not included in the Columbia Kermit distribution because full source is not provided, and the program cannot be built from the incomplete source that is provided. While Rice is willing to furnish the load module, this cannot be accommodated in our most common tape formats, like ANSI Format D, nor on non-IBM file systems (such as the DEC-20 and VAX/Unix systems from which Kermit is distributed). Therefore, those who would like to obtain this version of Kermit should order it directly from: Andrea Martin P.O. Box 1892, Dept ICSA Rice University Houston, TX 77251 Phone 713-527-4005 If the full source becomes available, then this version of Kermit will be included with the Columbia Kermit distribution. ------------------------------ Date: Tue 19 Mar 85 16:37:54-EST From: Daphne Tzoar Subject: MVS/TSO Kermit Has Series/1 Support To: info-kermit@CU20B.ARPA The assembler version of IBM MVS/TSO Kermit, which is an adaptation by the University of Chicago of Columbia's original VM/CMS implementation, has had support added by Charles Painter, University of Toronto Computing Services, for the Series/1 front end running the Yale ASCII Terminal Communications System V2.1. This allows PCs to transfer files using Kermit even when they are connected to IBM MVS/TSO systems that believe they are talking to 327x-style synchronous terminals, provided the protocol emulation is done by the Yale IUP. [Ed. - This replaces the Chicago TSO Kermit, since it is the same but with the addition of Series/1 support. It's available in the files KER:TSO*.* on CU20B and on BITNET via KERMSRV at host CUVMA. The documentation has not been updated at all, and is somewhat dated. Thanks to Philip Murton of U of T for submitting this new release. The forthcoming release of VM/CMS Kermit will also have Series/1 support.] ------------------------------ Date: Mon, 18 Mar 85 16:09:43 CST From: Stan Barber Subject: Manual Page for C-Kermit To: sy.fdc@cu20b Here is a possible manual page for Unix Kermit... Stan [Ed. - Stan's man page is available as KER:CKERMI.NR. We still don't have the single source that generates both Scribe and Nroff input, but this supplies the real man page that has been lacking up till now. Thanks, Stan!] ------------------------------ Date: Fri, 15 Mar 85 20:22:04 pst From: Ken Poulton To: Info-Kermit Subject: C-Kermit 4.2 comments I brought up C-Kermit 4.2 on my HP 9000 Series 500, at last. First of all, wow! This is a great package. My complements, especially on the command interface. It's really quite whizzy. In fact, I like it more than I expected I would (being a Unix die-hard). I also have a large number of comments on things that could go smoother. Although the list is long, remember that you have really done the job well, and I'm just working on perfection now. Rather than wait for time to make this a lengthy letter, I'm going to send you my notes on C-Kermit. Most of them are reasonably self-explanatory (famous last words). I expect some of them are being addressed already, and others I will be interested in doing. send cmd "send file [name]" is confusing syntax and precludes "send file file2..." which is what the Unix user expects "send file [-as name] [file [-as name]]..." more general [Ed. - True, but the command package does not have a facility for parsing alternates. I had to stop somewhere...] wildcards why not just use a shell to expand wildcards? Then wildcards are complete and consistent with normal usage. Surely speed is not an issue here. [Ed. - No special reason. The current way is more efficient, but you're right -- you miss the compatibility with the shell. Maybe somebody can try writing zxpand() and znext() functions that do it with a shell. On systems without shells or pipes, the present do-it-yourself model will still have to be followed.] ! cmd should use the shell defined by the env var SHELL, if defined "!cmd" should work for Unix consistency (not just "! cmd") "!" should get an interactive shell [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". Good point about this command invoking an interactive shell when no arg is given -- just like it does now if you say "! sh" or "! csh".] 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.] space cmd should do a du for space used [Ed. - Maybe; du can produce a lot of unwanted output if there are many subdirectories. If you really want it, say "! du" instead of "space".] 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.] interrupts behavior now is correct for interrupt in command-line mode (error packet, close line, exit) - you should not have to turn off interrupts in background - the shell is supposed to do that for you respond to the user's interrupt char rather than hardwire to ^C interrupts should be caught when running interactively !! (except in connect mode) - should act as ^B when transfer running - should *always* return to C-Kermit prompt after the first C-Kermit prompt (setjump/longjump does this rather trivially) - nearly every interactive program on Unix responds this way ^B doesn't work when send-init is failing [Ed. - I'm not an expert on Unix interrupts. But I don't believe the program is hardwired to trap ^C -- rather, it tries to catch SIGINT.] prompt default should be settable with cc -DPROMPT does "set prompt" affect error messages - especially those sent in error packets? all error messages should use the prompt-string (maybe without the >) to make errors easier to track down when running in the background [Ed. - Agreed.] line locking locking upon startup for -l argument is more intuitive than waiting for first connect command should allow you to connect if you own the lock file - maybe ask first in this case? [Ed. - Line "locking" aficionados are enouraged to carry on this discussion among themselves until the end of time. I already have a stack of correspondence on the subject about an inch thick. It's impossible to please everybody. In this case, you can't please ANYBODY.] script add ~d - delay for one second before sending next char for talking to slow network controllers (w/o typeahead) add ~x - XON (needed as the prompt char when talking to HP 3000 or IBM) [Ed. - The ~d (and maybe also a ~w for wait-for-input timeout) escapes are being added somewhere. Good idea about ~x.] ------------------------------ Date: Sun, 17 Mar 85 04:50:13 est From: Ken Yap To: sy.fdc@cu20b.arpa Subject: Bad Bug in C-Kermit? I have discovered that if C-Kermit is sending a file and it is interrupted with ^C for example, that file gets deleted. Surely this should only happen if the file is being received and "keep incomplete" is off? Ken [Ed. - You're right about what should happen, but on my 4.2 bsd system I can't reproduce the problem. Has anyone else seen this happen?] ------------------------------ From: trwrb!trwspp!spp3!kurisaki@Berkeley (Lance R. Kurisaki) Date: Mon, 18 Mar 85 09:36:24 pst To: info-kermit@cu20b.ARPA Subject: C-Kermit on Pyramid? Am I the only one who has had problems getting C-kermit V4.2 running on the Pyramid 90x (under 4.2 bsd)? It compiles fine, but doesn't do transfers. Lance Kurisaki {ucbvax|decvax}!trwrb!trwspp!kurisaki [Ed. - See the next message. I thought this had been fixed, but apparently it wasn't. Sorry!] ------------------------------ Date: Wed, 20 Mar 85 14:59:12 est From: oconnor@dcn9.arpa (Mike O'Connor) To: info-kermit@cu20b Subject: Making C-Kermit Work on the SUN I am in the process of installing 4.2 Kermit on my SUN system. There were no problems in compilation or in using Kermit to login to our local VMS system. File transfers, however, did not work. Kermit would send out the "send init" packet and then time out waiting for a reply. The problem turned out to be the definition of a local variable in the routine "ttinl". The variable "c" is defined as an integer instead of a char. Apparently when a byte is read and put into "c" the byte is placed in the high order byte of the integer. But when "c" is assigned to "dest[x]" the low order byte is used, filling "dest" with NULLs. After making the change to "ckxunx.c" (which is where "ttinl" is located) I used "make bsd" and am apparently up and running. I've used this version of Kermit to move half a dozen ASCII files from the SUN to the VMS system so far without any problems. Mike O'Connor [Ed. - Thanks, Mike! Presumably, this will also fix the Pyramid.] ------------------------------ Date: Tue, 19 Mar 85 13:45 MST From: "Kevin W. Laurent" Subject: C-Kermit on Four Phase 6300 To: Frank da Cruz I just wanted to drop you a short note to let you know that we got the new C-Kermit running on a Motorola Four Phase 6300 under UNIX. I've never seen a port go as smoothly as this one. We used `make sys3' and only had two problems--3 doubly defined variables (ncmd, nprm, nrmt) in ckcmd, and the problem in the makefile with ckprot mentioned in Digest #13. Thanks for doing such a fine job, everyone! [Ed. - Thanks to Herm Fischer for adding the Sys III/Sys V support, and to the manufacturers for providing fairly consistent implementations.] ------------------------------ Date: Tue 19 Mar 85 17:49:40-EST From: J. Eliot B. Moss Subject: C-Kermit on Callan Unistar 300 To: sy.fdc@CU20B The second pre-release version seems to work fine on a Callan Unistar 300, which uses the Unisoft System V port to the 68000. I have noticed nothing strange (beyond the bugs already reported), and it compiled fine as received. Thanks for the good work, everybody! Eliot [Ed. - I assume that one builds it with "make sys3", since it runs a System V variety of Unix.] ------------------------------ From: Dave Yost Date: 19 Mar 85 16:36:30 PST (Tue) To: info-kermit-request@cu20b Subject: Want C-Kermit on PDP-11 with RT11 Is anyone doing this port? Thanks. [Ed. - Somebody may try to produce a DECUS C version, nothing definite yet.] ------------------------------ Date: Sun, 17 Mar 85 20:48:14 est From: Robert Scott Lenoil To: sy.fdc@cu20b.ARPA Subject: Offer to Provide C-64 Kermit Diskettes I just posted the following message to USENET. Briefly, I offered to provide copies of diskettes containing Kermit for the Commodore 64 for seven dollars, to defray my costs (diskette, mailer, postage, wear and tear, and my time - which will be a lot, considering that I only own a single disk drive, and therefore will have to swap disks back and forth to perform a copy.) To address your problem (how to obtain Kermit) I thought I'd let you know that I am willing to provide Kermit diskettes to those people who are reluctant or unable to go through the downloading procedure. For $7.00 (U.S. funds), I will provide a diskette containing the executable code and documentation file. (Outside North America, please enclose an extra $1.00 to cover additional mailing expense.) Send requests and inquiries about Commodore-64 Kermit disks to the address below. Note that Kermit is written using the CROSS cross assembler which runs only on DEC-10's and DEC-20's; hence enclosing the source code would not be of much help. An additional problem is that the source code is larger than an entire 1541 diskette, and therefore would be too much trouble for me to copy. Please note that I am not conducting a business. I am making this offer to increase the availability of Kermit, which I hold to be a fine program. I must stress that Kermit may be copied free of charge, so long as this copying is not for "explicitly commercial purposes" (Taken from Columbia University's policy document on Kermit distribution), and those of you who wish to do so may download it free of charge from Columbia University machine CU20B (on ARPANET), using BITSERVE (from BITNET), or via UUCP from host OKSTATE. If people have questions, they can contact me by sending mail to lenoil@mit-eddie. Mit-eddie is on both the DoD internet and USENET, so I'm fairly accessible. Also note that I will not be at my present U.S. mail address for this summer, but my network mail will forward. Therefore, starting in June, it would be a good idea to first send me computer mail to obtain my current mailing address, rather than suffer the problems of delay and lossage of forwarded U.S. mail. Yours truly, Robert Lenoil 229 Commonwealth Avenue Boston, MA 02116 (USA) ------------------------------ Date: Fri 15 Mar 85 21:55:14-CST From: Stuart Schmukler Subject: CP/M KERMIT and Start-of-Packet To: sy.fdc@CU20B I have finished modifing the CP/M 4.04 kermit to support SOP (Start-Of-Packet) setting. The syntax I have chosen is: SET START-OF-PACKET enter character: !You type ^C, ^A etc. The additional code adds about 1KB to the CP4KER.HEX file so that the variable OVLADR is now 3600 for the CP4TYP.ASM file. Now that I have a KERMIT that is working for our IBM, the users want to be able to generate a BREAK. So I'll add BREAK code to the CP4TYP.ASM file for the MORROW MICRO DECISION I (UDI in the TYP defines) and others _IF_ some one sends me the code to do it. I have not been able to findout from Morrow's doc what UART they use (the KERMIT code does not help either). SaS PS: I have noticed that the RICE TSO KERMIT calls SOP 'marker'. Is there a "standard" syntax? [Ed. - "mark" is the term used for this field in the Kermit Protocol Manual, chosen primarily for its shortness. "Start-of-Packet" is a better phrase for users. Stuart's SOP changes for CP/M Kermit will be provided to Charles Carvalho, the current CP/M Kermit keeper, when they arrive; meanwhile, if anyone can help with the BREAK-sending code for the Morrow or any other CP/M systems whose Kermits still can't send BREAK, please do.] ------------------------------ To: info-apple@BRL-TGR.ARPA Subject: Apple II Kermit for ProDOS? Date: 18 Mar 85 10:31:00 PST (Mon) From: Stephen Is there a ProDOS version of Kermit running about somewhere? -- Stephen Willson ------------------------------ Date: 18 Mar 1985 23:32:31 EST From: ABN.BOYD@USC-ISID.ARPA Subject: Please help - Tandy 2000 Kermit To: INFO-KERMIT-REQUEST@COLUMBIA-20.ARPA Anyone feel charitable? I am a novice Kermit user actually attempted user that owns a new micro (TANDY 2000 w/256K,MASM,SOFTERM2000 comm package,BASIC,LOTUS, & MULTIMATE) on the Arpanet via ABN.BOYD@usc-isid. I have had virtually no success with either TA2000.ASM or MSGENER.ASM (modular) Kermit versions. I downloaded these two versions from CU20B, assembled, linked and attempted to download text and binary files with no success. TA2000.ASM would fail but clearly attempt to execute via timeouts. Repeated tries with KERMIT-20 in server mode were not successful. MSGENERIC assembled and linked (I double checked to insure all files were included) but it failed to properly open or identify the com port each time. Not sure I understand correct response to handle: prompt, but took program prompt/suggestion to use "3" each time. No success. Are there any Tandy 2000 users out there that could offer some advice or assistance. I do have SOFTERM 2000 comm package that correctly transfers micro to micro w/XMODEM protocol. I'll glady pay any phone charges if someone has an executable (.EXE) version that will use MSDOS 2.0 capable kermit. Joe Boyd 2109 Elvira St. Apt #902 Fayetteville, NC 28303 (919)-494-2203 ------------------------------ End of Info-Kermit Digest ************************* ------- 22-Mar-85 18:25:13-EST,15565;000000000000 Mail-From: SY.FDC created at 22-Mar-85 18:24:29 Date: Fri 22 Mar 85 18:24:29-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #15 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B 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 ---------------------------------------------------------------------- Date: Fri 22 Mar 85 13:45:54-EST From: Frank da Cruz Subject: Corrections, Reminders, Notes To: Info-Kermit 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. ------------------------------ Date: Fri 22 Mar 85 11:45:54-EST From: Frank da Cruz Subject: New MVS/TSO Kermit Recalled To: Info-Kermit 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. ------------------------------ Date: Thu 21 Mar 85 18:56:20-EST From: Frank da Cruz Subject: New Kermit for Honeywell DPS-8 with GCOS To: Info-Kermit@CU20B.ARPA 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.*. ------------------------------ Date: 20 Mar 85 13:43:35-CST (Wed) From: Gregg Wonderly To: sy.fdc@cu20b.ARPA Subject: New Kermit for TRS-80 Model 4 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.] ------------------------------ Date: Thu 21 Mar 85 19:01:49-EST From: Frank da Cruz Subject: New Kermit for TRS-80 Color Computer with Radio Shack DOS To: Info-Kermit@CU20B.ARPA 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) From: Gregg Wonderly To: sy.fdc@cu20b 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.] 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. ------------------------------ Date: Thu, 21 Mar 85 14:51:12 est From: decvax!ittvax!long@Berkeley (H. Morrow Long [Systems Center]) To: fdc@CU20B.ARPA@sy 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 ------------------------------ Date: Thu, 21 Mar 85 14:55:16 pst From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:poulton@hplabs.CSNET> To: cc.fdc@columbia-20.ARPA, cc.fdc@cu20b.ARPA 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.] ------------------------------ Date: Fri 22 Mar 85 10:34:23-EST From: Frank da Cruz Subject: More C-Kermit Line Locking Problems To: Info-Kermit 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 ************************* ------- 2-Apr-85 18:49:00-EST,9759;000000000000 Mail-From: SY.FDC created at 2-Apr-85 18:48:23 Date: Tue 2 Apr 85 18:48:23-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #16 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 2 Apr 1985 Volume 2 : Number 16 Departments: ANNOUNCEMENTS - New Edition of the Kermit User Guide Available Commodore-64 Kermit Bootstrap Program in C PDP-11 Kermit Problems and a Fix UNIX KERMIT - Problem with C-Kermit 4.2 Connect Command C-Kermit 4.2 on 4.1 BSD MISCELLANY - VTAM Translate Tables for TSO-KERMIT? Prime Kermit Bug MS-KERMIT 2.26/MULTICS-KERMIT and LU.EXE (binary file) Kermit for DG Eclipse running Calma DOS? ---------------------------------------------------------------------- Date: Mon 1 Apr 85 17:58:50-EST From: Frank da Cruz Subject: New Edition of the Kermit User Guide Available The sixth edition of the Kermit User Guide is now available. The major difference is that most of the chapters describing the specific implementations have been brought up to date. The introductory and main sections have also been fleshed out a little. The result, unfortunately, is substantially bigger than the previous edition. The new User Guide can be obtained via anonymous FTP from CU20B as KER:KUSER.DOC. The Scribe text formatter source is in KER:KUSER.MSS (and in all the files it "@includes"). ------------------------------ Date: Tue, 2 Apr 85 16:53 EST From: acdmayer@UOGUELPH.BITNET Subject: Commodore-64 Kermit Bootstrap Program in C Here's "c64boot.c", a program to download files to the C64, modelled on C64BOOT.CLU, for those who don't have CLU. Although written on a Unix system, the C code contains no kernel calls and should be fairly portable. Written by: Alastair Mayer, U. of Guelph, 2-Apr-85 [Ed. - It's in KER:C64BOOT.C on CU20B, available via anonymous FTP.] ------------------------------ Date: Sun Mar 24 1985 13:52:17 From: Marco Papa Subject: Problem with C-Kermit 4.2 I have encountered the following problem more than once now and on two different versions of C-Kermit (the Berkeley and PC/IX). While in "connect" mode, using an Hayes-compatible modem, randomly the program stops accepting input from the keyboard. Sometimes I can at least escape back locally and get the C-Kermit prompt, but sometimes there is no way to get out of it. On the other hand characters can continue to arrive from the line and are correctly displayed on the screen. Very distressing under PC/IX, most of the time I cannot escape back to the C-Kermit prompt, and the only thing that I can do is rebooting the system. I have seen this to happen at least once when garbage was coming in from the line. Has anybody experienced a similar problem? Marco Papa ------------------------------ Date: Wed, 27 Mar 85 02:58:08 pst From: Ken Poulton Subject: C-Kermit on 4.1 BSD I put C-Kermit up on 4.1 BSD. Doing it was really pretty easy: it turns out that the Tower OS must be a 4.1 port. Defining a general 4.1 version was mainly a question of selecting from the Tower, BSD4, and UXIII code already there; I only wrote two lines of C (but did lots of ifdef changes). I'll be sending those changes along with my other changes, hopefully next week. [Ed. - Once these changes arrive, it will take a good amount of time to fit them together with all the other changes -- I've got pile of notes and contributions over an inch thick...] ------------------------------ Date: 24 Mar 85 17:35 +0100 From: Michael_Evans_S-E-Banken%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: VTAM translate tables for TSO-KERMIT? I have assembled TSO-KERMIT for MVS/XA and have now run into exactly the problem described in the .BWR file: packets from TSO-KERMIT are just not getting through to the terminal. Our communications people know very little about the support of ASCII terminals under TSO. They tolerate rather than support these as the majority of our terminals are 3270s or compatibles, with no protocol converters. If KERMIT is going to work, I will have to do most of the work myself. We are using pure IBM communications products under MVS/XA on a 3081-KX or a 3084-QX. We have very recent releases of ACF/VTAM and ACF/NCP. I can find out the exact releases if this is needed to solve the problem. The ASCII terminals connect either directly to the 3725 TP controllers using the NTO software or via X25 networks using the NPSI software. And now my question: which translate tables must be altered in order that KERMIT will work ? I assume that we are using vanilla IBM- supplied tables throughout. There are just so many places where something could be going wrong that I would appreciate help in pointing the probable places to be changed. The TSO command TERMINAL has an operand CHAR which allows specific translations to be specified. However setting values with this does not seem to have the desired effect. The only hint is in the TSO Command Language Reference which under the CHAR operand says "Do not select characters which may be device control characters". I assume this refers to CTRL-characters such as . [Ed. - The IBM mainframe Kermit programs contain their own EBCDIC/ASCII translate tables. Data goes in and out of the program in EBCDIC, but ASCII is used internally so that the checksum can be computed correctly. When the IBM system sends Kermit's EBCDIC packets out an ASCII line, it translates from EBCDIC to ASCII (and conversely for incoming packets). Thus, Kermit's translate table must agree with the system's. If it doesn't, then the Kermit translate table can be changed. But note that Kermit's table is invertible; if your system's table is not invertible, you could have big trouble. Kermit's table corresponds to the one given in the IBM System/370 Reference Summary, GX20-1850-5.] ------------------------------ Date: Fri, 29 Mar 85 12:08:07 PST From: walton%deimos@cit-hamlet.arpa Subject: PDP-11 Kermit The version of Kermit-11 currently sent by KERMSRV is T2.24. I have installed this on our PDP-11/44 running RSX-11M-Plus version 2.1, and have two bugs to report, one of which I fixed. (1) In the subroutine assdev::, the starting label $1 is attached to the statement after the save registers statement. It should, of course, be attached to the save statement, otherwise the subsequent unsave sticks garbage into the registers and corrupts the stack pointer. Unfortunately, this did not fix the other problem, which is: (2) Packet receiving is totally dysfunctional when Kermit-11 is operating in local mode. We have a hard-wired dialout modem connected to one of our terminal lines (without the DSR and DTR lines hooked into our DZ11). Version 2.11 of Kermit-11 sent and received files just dandy over this line, but its terminal emulation was awful. Version 2.24 fixed up the terminal emulation and added several more Kermit commands, but in the process broke the file transfer. Debug mode of both Kermits confirms that packets sent by Kermit-11 are received by the remote Kermit, but the reverse is not true. ------------------------------ DATE: FRIDAY, 29 MAR 1985 FROM: BRIAN AT UOFT02 TO: SY.FDC AT CU20B SUBJECT: kermit and rsx Thanks for forwarding the note. The thing regarding rsx ASSDEV:: routine is odd, it must have been there since summer and no one caught it. Regarding packet transfer, that's the first I've heard of it; too often RSX systems seem to have quirks that are unique to the site -- it could be a config problem. After fixing the stack register save junk, I ran Kermit-11 under RSX-11/M+ v2.1 on an 11/44 hardwired to a Rainbow at 9600 baud. No problems were encounted using either the 11/44 or the Rainbow as servers. For those who need to know, in ASSDEV: move the 1$: to the save line. Only affects RSX (not P/OS) and only when the SET LINE command is used. File is K11M41.MAC brian nelson brian@uoft02.bitnet [Ed. - The aforementioned fix is installed in K11M41.MAC on CU20B and on BITNET KERMSRV.] ------------------------------ Date: Sun 24 Mar 85 23:14:41-PST From: Bob Larson Subject: Prime kermit bug To: info-kermit@CU20B.ARPA Prime Kermit is quoting the 8-bit character even when 8-bit quoting is not being done. Using defaults, this causes ampersands ('&') to be received as lower case f's by some versions of kermit, e.g. the old Unix Kermit that is the base of the current os9 kermit effort. ------------------------------ Date: Sat, 23 Mar 85 14:32 EST From: "Eric J. Swenson" Subject: MS-KERMIT 2.26/MULTICS-KERMIT and LU.EXE (binary file) I cannot seem to be able to transfer LU.EXE (on Multics) to my Z100 using MS-KERMIT 2.6. MULTICS-KERMIT claims "wrong packet type" and MS-KERMIT claims "unable to receive data". I have indicated to MULTICS-KERMIT that it should use binary mode, rather than text mode. What am I doing wrong? ------------------------------ Date: 24 Mar 1985 2135-PST From: FAE.WU at Ames-VMSB Subject: Kermit for DG Eclipse running Calma DOS? To: INFO-KERMIT at CU20B Does anyone have a version of kermit for a Data General Eclipse running Calma DOS? Alex Woo ------------------------------ End of Info-Kermit Digest ************************* ------- 3-Apr-85 15:32:32-EST,16357;000000000000 Mail-From: SY.FDC created at 3-Apr-85 15:31:44 Date: Wed 3 Apr 85 15:31:43-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #17, C-Kermit Bug List To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Wed, 3 Apr 1985 Volume 2 : Number 17 C-Kermit Bug List ---------------------------------------------------------------------- Here is the current bug list for C-Kermit Version 4.2, along with a list of implementations. This file is kept on line in the Kermit distribution areas as KER:CKERMI.BWR, but is being sent to Info-Kermit for the benefit of the many subscribers who don't have access to FTP or KERMSRV. The next release, which will incorporate fixes for most of the reported problems and support for most of the additional systems, will still be several weeks in coming; still plenty of time to send in more bug reports and suggestions. -- SUPPORT FOR ADDITIONAL SYSTEMS: -- 4.2BSD: "make bsd" works. 4.1BSD: C-Kermit built with "make bsd" does not work under 4.1. The date/ time stuff and line locking stuff are completely different from 4.2. Also, the directory format is different, so traverse() doesn't work. Specific support needs to be added for 4.1. Apparently very similar to the TOWER1 support. 4.1 support being added by Charles Brooks (brooks@edn-vax), and also by Ken Poulton (poulton@hplabs.csnet). 4.2 can be differentiated from 4.1 with "#ifdef MAXNAMLEN". ATT 3Bx systems: works ok with "make sys3", but works better if TCSETA changed to TCSETAW to allow i/o to drain before changing terminal modes; probably applies to all sys3/sys5 systems (chris@columbia-20). VAX/VMS: Added by stew%lhasa.uucp@harvard, not available yet (see below). Regulus: Submitted by Joe Smiley, DuPont Co. Extensive changes to 4.0 were too hard to fit into 4.2; hope Joe can add the Regulus support to 4.2. Motorola Four Phase 6300 - works fine with "make sys3" (KLaurent@DENVER) Callan Unistar 300 (68000) with Unisoft System V -- works fine with "make sys3" (EBM@MIT-XX). Cadmus 68000: Compiles ok with "make sys3", but core dumps because malloc() not declared (in wart and in ckzunx) as returning a char pointer; see below. NCR Tower, OS 1.02: Submitted by John Bray, based on 4.0, fitted into 4.2, but it doesn't work in 4.2; it will be fixed in next release. NCR Tower, System V: Works ok -- "make sys3" (except some problems reported when connected to IBM mainframes; see below). HP9000 Series 500: (from YEKTA@MIT-MC): Use "make sys3", but 1. Remove -i from CFLAGS & LI 2. In ckxunx.c, don't #include or ioctl.h. 3. In ckzunx.c, don't #include. HP9836U Series 200, HP-UX 2.0.0, rev B (BLO2@CMU-CC-TC): "make sys3", but need to add the following in ckxunx.c functions ttpkt() and conbin(); ttraw.c_cflag |= CS8; /* 8-bit chars */ ttraw.c_cflag &= ~(PARENB|CSTOPB|ISTRIP); /* no parity, 1 stop bit */ (This probably should be done in all sys3/sys5 systems). Plexus P-60 Works ok with "make sys3", but doesn't always hangup even when hupcl is on (Scott Weikart, Stanford). Masscomp/RTU 2.2: Works ok with "make sys3", except for line locking (Stan Barber, neuro1!sob@rice). Pro/Venix 1.x: Performance improvements and ability to interrupt transfers in progress need to be (and will be) added. Currently there is no "line locking" to prevent interference with/by uucp. Anybody know how Venix does this? Pro/Venix 2.0 (field test): Works ok with "make sys3", except the "unsigned long" has to be changed to "long" in ckdebu.h; may be a bug in the new compiler (Dan Schullman, DEC). SUN, 4.2bsd: C-Kermit 4.0 with 4.2bsd support was reported to run OK on the SUN after some bugs with long strings, char vs int, etc were fixed. There is now a report that version 4.2 doesn't even compile on the SUN because of the ^L's in the source file (can this be true???), and that once compiled (by removing ^L's) it doesn't transfer files at all, but just times out after many retries of the first packet (this report from daver@cit-vax); oconnor@cdn9 reports that changing the definition of the local variable "c" in function "ttinl" from integer to char fixes the problem. Pyramid 90x, 4.2bsd: Apparently same problem (and same fix?) as reported for SUN, above. -- BUG LIST -- General problems: - Unnecessary timeouts occur at low baud rates when parity is being done; in ckfns.c, inchr() is being called by inlin() with a timeout interval so small that MAXTRY could be exceeded before the whole packet was read. - Conditionalizations are not done clearly. In some cases it might be better to have compile-time flags for features, rather than systems, or generic system names, rather than specific vendor/machine names, to avoid excessive nesting or OR'ing of compile-time variables (do all C compilers support ORing?). - It might also be better to have a -D in the makefile for the system name, rather than hard-coding it into the ck[xz]*.c modules. - Program's return code might be wrong in some cases (in 4.0, it was always zero; in 4.2 some attempt is made to return correct codes for failure and success). Also see note about VMS return codes, below. - "quiet" (-q) flag does not turn off all error messages. Direct use of fprintf(stderr,...) should be replaced by invocations of ermsg(). - The error messages should use the current prompt (changed via 'set prompt') rather than "C-Kermit" as a prefix, to make it easier to see which Kermit a message is coming from, if you have a C-Kermit on both ends of the line. - The default prompt should be set from the makefile with -DPROMPT. - Program still core dumps from time to time because of (f)printf(string) statements; "help remote" and "help set" tend to exhibit this behavior. These printf's must be replaced by (f)printf("%s",string), or puts() statements, or something like "while (*s) putc(xxx, *s++);". - Local mode file transfer display could be improved. First, for systems like Macintosh that have fancy screen management, the screen() function should be provided additional information as to what the arguments are -- filenames or whatever -- so it can display them more intelligently. Second, on tty-style displays, the "percent done" could be shown by doing something like "0...1...2...3...4...5...6...7...8...9...". - Interrupt handling is not done particularly well, and if the program crashes or is halted while it has the terminal in a not-normal mode during command parsing or file transfer, the terminal mode is not restored. Code should be added to trap quit or panic interrupts and restore the terminal before quitting or panicking. - The shell's interrupt, delete, and kill characters can interfere with those used by the Kermit command parser. C-Kermit should use those already set up in the user's environment (how to get them?). - status command needs timing info, maybe also effective baud rate. - "!" command should not require a space after, should use the user's customary shell rather than sh, and if issued without an argument should start an interactive shell. - Many people have asked for a system-wide startup file similar to the user's .kermrc file, perhaps with a conditional way to escape from it if the user has her own .kermrc file. This notion might be extended to include the entire hierarchy system -- home -- current directory. - It would also be desirable to have a way of specifying alternate startup files on the command line, so that aliases could be defined for running Kermit on certain lines, at certain speeds, etc. - A deeper problem with the initialization files is that the file is only taken when the program enters interactive command dialog. To be consistent, it should also be taken when the program is run via command line arguments. - Moving the program to VAX/VMS uncovered a few remaining Unixisms: . VMS uses program return codes with opposite sense from Unix; return code values must be conditionalized. . ".kermrc" doesn't work as a file name on most non-Unix systems. . There should be a more portable way of handling baud rates tables. ckzunx.c: - ckzunx currently goes to a lot of trouble to traverse the directory in order to expand "*" and "?" in wildcards. Maybe it should just fork the user's customary shell and have it do the expansion. This would allow fancier filespecs to be given, like "~/ck*.[cwh]". But it would slow down features like filename completion and menus in the interactive command parser. - malloc() should be declared "char *malloc()" for systems that have pointers and integers of different lengths. - In zsout() & friends, "fprintf(fp[n], s);" should be "fputs(s, fp[n]);" or 'fprintf(fp[n], "%s", s)', to prevent core dumps when s happens to contain a '%'. - In zltor(), dc (dot count) is incremented for all dots in the filespec; not good if filespec is something like "../foo.bar". Reset dc to zero whenever a "/" is encountered. ckxunx.c: - Many problems reported with "uucp line locking" -- . On some systems, uucp apparently ignores the lock and breaks in anyway. . On some systems, the lock directory is write-protected. . On some systems, the lock directory is read-protected. . Using dial commands and a login script pointed at a line already in use by uucp will hang up the line on uucp. Cure for this and some other similar problems: tty should not be opened before calling ttlock. Unfortunately, a lot of code will have to be added to take care of the many different ways that sites are set up to handle line contention and assignment, probably selectable by makefile compiler switches (see below). - Under certain conditions, alarms used to timeout blocked reads are not cleaned up after a timeout occurs. - There's no good way to select baud rates higher than 9600. Most Unix systems don't supply symbols for them (unless you use EXTA, EXTB), and even when they do, the program has no way of knowing whether a specific port serial controller supports those rates. - 4.2 bsd systems with dialout modems should do ioctl(ttyfd, TIOCCDTR, 0); sleep(1); to hang them up upon close. Other systems that don't have a hangup function might need a trick like setting the speed to 0. - Venix/11 version 1 does have a nondestructive way to inspect a tty input buffer after all, so the ttchk() and conchk() functions can be provided for Venix to speed up connect mode significantly. ckdial.c: - Some systems do not allow users to manipulate dialers directly. - Not easy to add support for new dialers. - Some systems never return from the 100-character rawmode read (it is assumed return is immediate, indicating how much was obtained from the input buffer). - Timed read for connect/no carrier message from modem within a general timer on the whole operation does not work on some systems. - Some systems need to have the modem explicitly hung up; close() isn't enough; e.g. ioctl(ttyfd,TIOCCDTR,0) on 4.2bsd. - On some systems, the entire output from the dialer (e.g. "CONNECT") cannot be read in a single gulp, so the buffer should be appended to between successive reads, not overwritten. ckus*.c: - Some help messages still produce core dumps on some systems. Diagnosis: the strings in these messages ('help remote', 'help set' are mentioned most frequently) are still too long for some systems. Cure: shorten them some more, and maybe replace for (i=0; *s[i]; ++i) fputs(s[i], stdout); with while (*s[0]) fputs(*s++, stdout); in hmsga() to prevent possible references to random memory. Also, replace all printf(msg) with printf("%s", msg); - The "directory" command produces a full recursive directory listing. It should only list the current directory. On bsd systems at least, the listing can be interrupted with a single ^C, which returns you to C-Kermit> command level. Diagnosis: ??? The program just does a system("ls -l"). Why doesn't this behave the same as "ls -l" typed at the shell? - Parser for the 'get' command doesn't respond well to editing; can go into infinite loops under some conditions. - The filename 'transaction.log' is too long for some systems, and gets truncated (no harm is done, but the user is not informed and may not be able to find the file). - The variables ncmd, nprm, nrmt are doubly defined. ckcmd.c: - Some systems (such as Venix/11) swallow the erase and kill characters when the terminal is in cbreak mode. If the erase and kill characters are are ^U and DEL, then these can't be used to edit C-Kermit interactive commands. Ditto for ^R. Diagnosis: sigh, let's hear for portability. Cure (if you can call it that): Add new SET commands to allow the erase, kill, and redisplay characters to be redefined. - There's no way to break a command line and continue on the next line. Cure: add code to allow "\" followed by CR (or LF, or FF) to accomplish this. Nobody really wants to put a real CR (LF, FF) in the middle of a command anyway, right? This will make take files and login scripts a lot more readable. - No way to put comments in take files. Cure: Add a ";" or "#" command? Trailing comments will be harder. Protocol (ckprot.w, ckfns*.c): - No way to interrupt a protocol transaction until after it starts successfully. For instance, no way to interrupt the timeouts and retransmissions of the initial packet when the other side is not responding, except for killing the whole program. Cure: check for keyboard "interrupts" during the send-init process. - When receiving from a non-timed-out Kermit and missing the Send-Init packet, no NAK is ever sent, and a deadlock occurs. Diagnosis: resend() is called to resend the previous packet; there was no previous packet, so it sends an empty line. Cure: Initialize the packet buffer with a NAK for packet 0? - When parity is in use and the other Kermit cannot do 8th bit prefixing, the user is not warned that binary files will not be transferred correctly. - 'set file names literal' does not work at all. ckconu.c: - There have been reports that on some systems (e.g. NCR tower with Sys 5) C-Kermit stops listening for the escape character during connect. In one case, it was reported that this happened only with IBM mainframes with "set flow none". - Doesn't do any particular kind of terminal emulation. It wasn't meant to. Filters can be used for this. - Performance is poor on systems that can't check the input buffer. - As structured, connect mode can't include commands to toggle logging on and off or to change settings, because forks can't share variables. cklogi.c: - Script facility needs ~d for send-delays, ~x for XON, ~w for wait-for- input timeout; these will probably be added. ckwart.c: - Has typedef for CHAR as "unsigned short" or "unsigned char". Cure: Have ckwart.c use the typedefs from ckdebu.h, like the regular Kermit modules do. - Should declare malloc "char *malloc()" for systems that have pointers and integers of different lengths. makefile: - Replace "wart ckprot.w ckprot.c" with "./wart ckprot.w ckprot.c" because "." might not be in the current path. - It was suggested that the compound entry for making ckprot.o should be broken into two entries, one for ckprot.o, one for ckprot.c, to prevent unecessary recompilations. - Some of the problems caused by access restrictions on the uucp lockfile directory might be addressed by having the makefile check and then setting an appropriate compile switch, e.g. if [ -w /usr/spool/uucp ] then make bsd "... -regular flags" else make bsd "... -DNOLOCKING" fi ------------------------------ End of Info-Kermit Digest ************************* ------- 4-Apr-85 18:35:51-EST,9641;000000000001 Mail-From: SY.FDC created at 4-Apr-85 18:34:37 Date: Thu 4 Apr 85 18:34:37-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #18 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 4 Apr 1985 Volume 2 : Number 18 Departments: ANNOUNCEMENTS - New Kermit for Honeywell CP6 New Release of Kermit for Intel ISIS MDS System New Release of Apollo/Aegis Pascal Kermit Kermit for Sanyo 1100 MBC with CP/M-80 2.2 MISCELLANY - UK Kermit Resposibilities Need KERMIT for DG/One Unix Questions MS-KERMIT 2.26/Multics-KERMIT KERMIT on M6800 ---------------------------------------------------------------------- Date: Thu 4 Apr 85 17:05:13-EST From: Frank da Cruz Subject: New Kermit for Honeywell CP6 Contributed by Cheryl Ann Poostay of Bucknell University, this new Kermit implementation is based upon the University of Toronto Pascal VMS Kermit, and provides the basic remote Kermit services. The files are in KER:HCP6*.*, available, as usual, via anonymous FTP from host CU20B. ------------------------------ Date: Thu 4 Apr 85 17:02:50-EST From: Frank da Cruz Subject: New Release of Kermit for Intel ISIS MDS System Submitted by Teresa Koo of Intel in Santa Clara, this releases fixes some problems in the previous release (for instance, the previous release could not send files to VMS), and adds some new documentation (the previous release had none). The files are in KER:MDS*.* on CU20B. ------------------------------ Date: Thu 4 Apr 85 17:06:59-EST From: Frank da Cruz Subject: New Release of Apollo/Aegis Pascal Kermit From Steve Case of Control Data, this new release fixes some bugs and adds a SET FILE_TYPE command to allow transfer of binary files. The new version (2.6) replaces the old one (2.3) as KER:APOLLO.* on CU20B. ------------------------------ Date: Thu 4 Apr 85 18:06:17-EST From: Frank da Cruz Subject: Kermit for Sanyo 1100 MBC with CP/M-80 2.2 Contributed by Randall Simmons of Southwest Texas State University, this implementation is based on version 3.6 of CP/M-80 Kermit. Since the main Kermit distribution area is very tight on space, the files have been placed in KE:CPMSYO.* (note, KE:, not KER:) on CU20B. Perhaps someone who has a Sanyo 1100 will move this support into the current version of CP/M-80 "modular" Kermit (version 4.05). ------------------------------ Date: Wed, 3 Apr 85 11:50:32 BST From: Chris-on-Fridays Subject: UK Kermit Resposibilities Kermiteers: A meeting was held in the bar at Sheffield last Monday evening, at which there were a number of Kermit-interested people present. We threshed out some policy about who looks after what. The effect is:- 1. Lancaster will look after Kermit sources and try to keep a list of who-has-what. They will get new tapes from Columbia about 4 times a year, and pull in other stuff by ARPA-ftp. They will keep all this (or as much as possible) online and available by NIFTP or Kermit. The "who-has-what" is really a list of names of those who have running binaries on transferrable media, and are willing to supply floppies etc. 2. I will keep a mailing-list here (info-kermit@ucl-cs) of all known interested parties in UK (and possibly Europe if we have connectivity). Anybody who wants his/her name added to or deleted from this list, mail me (cjk@ucl-cs). Anybody who wants to distribute info to the UK Kermit fraternity, mail it to info-kermit@ucl and our mailing system will expand and forward. 3. I will serve as a relay for info from Columbia which is not new versions of Kermits. This principally means the information digests. As each one comes in I will move it into /44d/kermit/infodig and send a copy of its contents-header to info-kermit@ucl-cs; you can then extract it either by NIFTP or by Kermit. In line with this, I am removing the majority of the source texts from the /44d/kermit directory. They are in any case now about a year old. I will try to hold as much text information online as possible. If anyone has trouble importing the larger documents, let me know. I could split them up into chapters. Chris K. ------------------------------ Date: Wed, 3 Apr 85 08:55 EST From: Wiedemann@RADC-MULTICS.ARPA Subject: Need KERMIT for DG/One To: info-kermit@CU20B.ARPA We have need for a KERMIT for our new Data General/One portable. These are IBM clones with the exception of the communications UART. In an effort to keep power consumption to a minimum, DG opted for an 82C51 UART instead of the 8250 the IBM uses. This precludes the DG/One from using IBM communi- cations software. If necessary, I can provide a driver routine (in 8086 assembler) from the DG/One programmers manual which details the command structure for the 82C51 as well as the DG/One power management scheme. Thanx for your help! Wolf Wiedemann RADC-MULTICS [Ed. - Many have expressed interest, but no one has offered the driver routine before.] ------------------------------ Date: Wed 3 Apr 85 16:18:25-EST From: Frank da Cruz Subject: Unix Questions A couple possible solutions for C-Kermit problems: 1. Recursive directory listings produced by "directory" command, or by server when given "remote directory" with no argument or "*" -- use "ls -ld" rather than "ls -l". I checked in 4.2bsd, ATT System V, and Venix manuals, and all support "ls -ld". Are there any Unix systems that don't? 2. It is considered desirable to use the user's shell for any system commands, or executing "!" commands. Can this be done in all versions of Unix by making a string of the form "$SHELL -c " concatenated with the desired command, and then feeding it to system()? Not elegent, but then neither is fork/pipe creation/deletion. ------------------------------ Date: Wed, 3 Apr 85 18:53 EST From: "John C. Klensin" Subject: MS-KERMIT 2.26/Multics-KERMIT Well, MS-KERMIT works, but you have probably gotten into the midst of the Multics kermit mess. Without reciting the history and boring everyone else, there are four known versions of Multics kermit on the MIT Multics machine, none completely satisfactory. They are, in no particular order: Oakland version I, as modified by MIT (the one you find if you don't do anything special). This version does not do binary transfers correctly, and sometimes randomly decides that it is in eighth-bit quoting mode, resulting in some arbitrary character being consistently garbled. This version understands something about Multics text files, and translates names to lower case, and so forth. The MIT modifications, in addition to the text handling, include making the thing work satisfactorily with the X.25 PDNs. A further modification of Oakland version I, with the 8th bit bug fixed and some additional code to properly canonicalize text to Multics standards. Oakland version II, which is believed to have a few of the same problems for MIT use as version I, including difficulties with the X.25 PDNs and mode-setting problems for some other devices. It also lacks the extensive transaction-tracing facilities that were added to the versions above in the process of getting them working. This version is, we believe, the version that exists as the official Multics kermit at Honeywell. Calgary/Honeywell "official" kermit prerelease. This version, which, unlike the others, has a user interface consistent with other Multics subsystems and quite similar to the ARPANET user ftp program on Multics, is the precursor of what will eventually be released. It does not have the special text canonicalizing features of the first and second versions listed above and is arguably not too bright about the handling of names. It does binary downloads correctly ONLY in seven-bit mode, with eighth-bit quoting on; it will not do them when told to use an eight-bit data path. This bug is claimed to be fixed in the official release, which will certainly get here someday. At MIT, we are ignoring Oakland II, and have stopped work on the MIT modifications to Oakland I (we have not even bothered to install the second version mentioned above). We are concentrating our efforts on trying to find problems and suggest fixes to Calgary/Honeywell Multics kermit, which seems to work if you are careful. If you have further problems, or cannot figure out which version here is which, the IS Microcomputer Center has official responsibility for kermit on MIT-Multics and you may want to contact them. ------------------------------ Date: 23 March 1985, 20:32:28 MEZ From: Bernhard Nebel +49/30/314-5494 NEBEL at DB0TUI11 TU-Berlin Sekr. FR 5-8 Franklinstr. 28/29 D-1000 Berlin 10 Subject: KERMIT on M6800 Dear Daphne, I've written a KERMIT for a M6800 running under MDOS (a operating system written by myself), which is similar to MINIFLEX V1.0 (Technical Systems Consultant). But anyway, it should be possible to rewrite the operating system interface. Are you interested to receive the KERMIT? - Bernhard [Ed. - Anyone interested? Send him mail.] ------------------------------ End of Info-Kermit Digest ************************* ------- 9-Apr-85 20:11:08-EST,13772;000000000000 Mail-From: SY.FDC created at 9-Apr-85 20:10:25 Date: Tue 9 Apr 85 20:10:25-EST From: Frank da Cruz Subject: Info-Kermit Digest, V2 #19 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 9 Apr 1985 Volume 2 : Number 19 Departments: ANNOUNCEMENTS - ANSI Tape Program for Prime Computers Commodore-64 Boostrap Program in SIMULA IBM MAINFRAME KERMIT - CMS Kermit and Linemode EBCDIC, ASCII, and All That ASCII in Kermit Docs Re: EBCDIC, ASCII, and All That MISCELLANY - Text vs Binary Files in Kermit Another CP-6 Kermit on the Way B6900 Version of Kermit Using NDL2? ---------------------------------------------------------------------- Date: 9 Apr 1985 1829-EST From: LSM.DUNCAN at DEC-MARLBORO Subject: ANSI Tape Program for Prime Computers Attached is a program written in Fortran-66 which will read variable record length ANSI (Format D) tapes on a Prime computer. Since Fortran-66 is provided with all Prime machines, all Prime customers should be able to compile and run it. I have only briefly tested it, but it appears to work as advertised. Much thanks should go to the Prime New York office. Ron Couch, a senior analyst there wrote it, and Dave Tichane provided me with a copy to send to you. In order to help you out, I am willing to send a (paper) listing of it to anyone who needs it. Please send a request to LSM.DUNCAN at DEC-MARLBORO, Prime X.MAIL DUNCAN -ON EN.C6, or U.S. mail to: Jeff Duncan Prime Computer Inc. 492 Old Connecticut Path MS 21-02 Framingham, Ma. 01701 I hope this new program will help out the many Prime people who have had difficulty with your tapes. Jeff [Ed. - Many, many thanks to Jeff, Ron, and Dave. Prime computer sites have had a terrible time reading the ANSI tapes we sent them up till now. The program is in KER:PRIMET.FTN, available via anonymous FTP from CU20B.] ------------------------------ Date: 08 Apr 85 14:19 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Subject: Commdore-64 Boostrap program in SIMULA Here is a version of the C64BOOT program written in SIMULA for DEC-10/20 computers. I have commented this version a little more than previous versions of C64BOOT in other languages, to make it simpler for someone who needs to re-write it into yet another language. Note two important points: ALL echoing of characters from the CBM by the HOST must be suppressed. Also the echoing of a line feed when the CBM sends a carriage return. The delimiter between lines sent to the CBM-64 should be only carriage return, not carriage return-line feed. [Ed. - Thanks, Jacob! The program is in KER:C64BOOT.SIM, available via anonymous FTP.] ------------------------------ Date: Fri, 5 Apr 85 10:11:03 est From: KRAMER Subject: CMS Kermit and Linemode Has anyone tried to get the VM/CMS Kermit working using the LINEMODE patches from Queens Univ with a YALE ASCII/Series 1 front end (or an IBM4994)? Better yet, does anyone have KERMIT working useing the Transparent mode options with the YALE Ascii package? [Ed. - The soon-to-be-released version 2.00 of VM/CMS Kermit will include the ability to operate transparently through the Series/1 front end with the Yale ASCII package. The U of Chicago's MVS/TSO Kermit was modified at the U of Toronto to do the same thing, but the Toronto version ONLY works through the Series/1-Yale front end; it's in KER:TSOS1.*.] ------------------------------ Date: Thursday, April 4, 1985 at 9:36 PM EST From: Norman Ramsey Subject: EBCDIC, ASCII, and all that I am at my wits' end trying to cope with CMS, CMS-KERMIT, and the godawful problem of ASCII/EBCDIC translation. I am working with two sites, CORNELLA and MITVMA, that use DIFFERENT translation tables. I believe that BOTH tables are noninvertable, and I am ready to flog the engineer who designed EBCDIC. All this notwithstanding, I would be happy (nay, ecstatic), if I could somehow just send the RAW BITS from an ASCII machine (such as my IBM PC) and an IBM mainframe. I would be happy with seven bits. I would be happy with eight bits. I'm beginning to think the best I can hope for is six bits, and that only be encoding everything as alphanumeric, comma, period, blank, and such characters as we hope will always be translated *RELIABLY* independently of the vagaries of the various sites. Such as, f'rinstance: my site (CORNELLA) translates an ASCII backslash into an EBCDIC cent sign (hex 4A) and back again. Too bad no other site seems to do that. But you don't want to hear this... Norman Ramsey zsyjartj@cornella.bitnet ------------------------------ Date: 04/09/85 17:39:11 EDT From: TS0013@OHSTVMA Subject: ASCII in Kermit docs I am curious about which version of ASCII is really the one on which Kermit is based. The KERMIT PROTOCOL MANUAL says that The 1968 version of ASCII, X3.4, is used. Appendix V of the same manual shows X3.4-1977. The major point I am aware of in the 1977 version is that the broken or "split" vertical bar has been "fixed" back to a solid vertical bar. The name for it is now just "vertical bar". Locally on our IBM systems, we have a homegrown standard for the translation of ASCII to EBCDIC and EBCDIC to ASCII. This local standard is based on the fact that early development and standard- ization of PL/1 insisted on using the exclamation point, stylized like a vertical bar, for logical OR. A compromise was reached at some point making the code for exclamation to be either a solid vertical bar or an exclamation. I still see documents around that describe this mess. I think this was implemented in 1968. In 1977 ANSI decided to fix the mess and make the broken vertical bar into a solid one, and the exclamation was to be only that. What resulted here was that the translations still change the CODE for character number (octal)21 into a vertical bar in EBCDIC. This has led to much confusion around here. The management here was only recently aware that there were even any such changes in ANSI. I guess they will learn that "standards never are". What I am curious of is just what standard is Kermit based on. Is it using some specific standard, or perhaps trying to track a moving target (ASCII) ? ------------------------------ Date: Fri 5 Apr 85 10:49:27-EST From: Frank da Cruz Subject: Re: EBCDIC, ASCII, and all that My sympathies to all. ASCII/EBCDIC translation will always plague us. Those who are interested in the sordid history -- and there's a lot of it -- are referred to the book "Coded Character Sets, History and Development" by C.E. Mackenzie, Addison-Wesley (1980). There are two "standards" for translation between ASCII and EBCDIC: [CACM] "Correspondences of 8-Bit and Hollerith Codes for Computer Environments -- A USASI Tutorial", a working paper of the ANSI X3 Committee, published in CACM, vol.11, no.11, pp.783-789 (Nov. 1968) [IBM] "System/370 Reference Summary", GX20-1850-5, IBM Corporation, 6th ed. (1984) (earlier editions presumably have the same table) The former more closely approximates a formal standard since it comes from the appropriate ANSI committee, but the latter is used more commonly in practice, since it is promulgated by the major manufacturer of equipment for which ASCII/EBCDIC translation is necessary. To complicate matters, both ASCII and EBCDIC went through many fundamental changes over the years; EBCDIC went through a long evolution from Hollerith and BCD to its present state, and there have been at least four distinct ASCII alphabets: those of 1963 (no lower case letters), 1965 (lower case letters added, some new graphics added, others switched around), 1967 (ANSI X3.4-1968: several graphics moved and/or redefined), and the current 1977 version (X3.4-1977: vertical bar plugged). Many translation tables are relics from these early days of rapid change; they were correct (i.e. useful) in the context in which they were created but now cause problems, most commonly with the following characters: ASCII CACM IBM ASCII value EBCDIC EBCDIC graphic decimal Hex Hex Comments ! 33 4F 5A 4F in IBM is a solid vertical bar [ 91 4A AD 4A in IBM is a cent sign ] 93 5A BD 5A in IBM is an exlamation mark ^ 94 5F 5F Listed in IBM as a "not sign" | 124 6A 4F IBM has 3 vertical bars -- 4F, 6A, and FA The Kermit translate table corresponds to the IBM table (with either 1968 or 1977 ASCII) and works at most sites. Unfortunately, this is not to say that sites at which it does not work are using the CACM table; many sites have reported problems with the translation of characters where IBM and CACM agree, including curly braces "{}", backslash "\", and tilde "~". It seems to be a relatively common practice for sites to "customize" their translate tables, for reasons such as those mentioned above. The IBM (and hence the Kermit) table is invertible, provided one sticks to using only the EBCDIC 4F vertical bar, which is solid in EBCDIC and 1977 ASCII, and broken in 1968 ASCII (and on most current ASCII terminals and printers). The only way to get IBM systems (VM/CMS systems, anyway) to allow raw data in and out a TTY line is to modify VM by adding the null translation table along with an appropriate CP command to invoke it. It does not necessarily do any good to preprocess your data (e.g. hexify it), because Kermit packets contain not only data, but also control fields which may contain any printable ASCII character. ------------------------------ DATE: TUESDAY, 9 APRIL 1985 FROM: BRIAN AT UOFT02 SUBJECT: Text vs Binary Files in Kermit A proposal to assist in Kermit binary file transfers. A common problem in Kermit file transfers is that of having to switch between 'bin' (or 'fixed') modes and 'text' modes. While some Kermits, such as the MS/PC DOS and Kermit-11/RT11 versions don't care what about this (RT makes no distinction), Kermit-11, Kermit-20 and Kermit-32 do. This problem becomes acute when one sets up a BB for downloading text and exe (tsk,sav,...) files to micros. We need a means to automate the switching from text mode to image mode. Kermit-11 currently uses two methods to do this, one, if the file is not sequential implied CR then Kermit-11 sets itself to 'binary' mode, ie, it uses RMS-11 direct access macros to read the file. Also, it will check the filetype to see if a match occurs, and if so, sets itself to binary mode for that file. This is done since RSTS/E and RT can have files that ARE binary but have no ufd data to say so. Additionally, if Kermit-11 finds that a file is 'binary' it will tell the other Kermit (if it said it can handle attributes via the CAPAS field) such. Also, if Kermit-11 finds itself talking to another Kermit-11 it will (for RSTS/E and RSX and P/OS) send a copy of the file header (the RMS-11 IFAB). Now, for the problem. We need a consistant means of setting 'binary' xfer mode. Kermit-11 has in it a hardwired list of filetypes that shoud be sent 'binary'. This is ok most of the time, exceptions do occur. Like a .COM file is a command procedure under VMS and RSTS V9 (which I am field testing) but under CPM it is quite another thing. The proposal is this: The Kermit program should look for a file that contains a list of filetypes that the system manager considers to be 'binary'. If found, switch to image mode. Also, we should think about attribute packets, at least in so far as 'I' format file. brian nelson brian@uoft02.bitnet [Ed. - Brian's note points out a fundamental problem with Kermit, and in fact with any file transfer mechanism, especially between unlike systems. Brian's scheme would help a lot, but it would have to be combined with all sorts of other heuristics, different on each system, to behave as desired. For instance, to tell the difference between a VMS .COM file (a textual command file) and a CP/M .COM file (an 8-bit binary file), one would have to examine the data itself.] ------------------------------ Subject: Another CP-6 Kermit on the Way Date: 04 Apr 85 20:19:50 PST (Thu) From: Mike Iglesias Lee Hallin at Honeywell LADC (in Los Angeles) has also got a KERMIT for Honeywell CP-6 systems. His has SERVER mode, some fancy debugging features, etc. It's not completely done yet. He's planning on submitting it to the KERMIT distribution when it's done. We've been testing it for him for about 3 weeks. Just thought you'd like to know. Mike Iglesias University of California, Irvine [Ed. - When it rains, it pours...] ------------------------------ Date: 5 Apr 1985 12:32-PST Subject: B6900 Version of Kermit Using NDL2? From: Geoffrey C. Mulligan We have a B6900 running NDL2 and I am interested in getting Kermit running. Has anyone written a version of Kermit using NDL2? ------------------------------ End of Info-Kermit Digest ************************* ------- 17-Apr-85 10:40:34-EST,10107;000000000000 Mail-From: SY.FDC created at 17-Apr-85 10:40:05 Date: Wed 17 Apr 85 10:40:05-EST From: Frank da Cruz Subject: Info-Kermit Digest V1 #20 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B 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 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 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" 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:). --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 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" 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 ************************* ------- 25-Apr-85 16:38:05-EST,10330;000000000001 Mail-From: SY.FDC created at 25-Apr-85 16:36:48 Date: Thu 25 Apr 85 16:36:48-EST From: Frank da Cruz Subject: Info-Kermit Digest V2 #21 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 25 Apr 1985 Volume 2 : Number 21 Departments: ANNOUNCEMENTS - New Macintosh Kermit Prerelease Available for Testing VMS Kermit 3.1.066 Available Kermit-11 BITnet Server Available MISCELLANY - S-1 Mark IIA Kermit Commodore-64 KERMIT - a problem Kermit for Royal Alphatronic PC? Apple II Kermit Support for CCS7710 Serial Card? Looking for Kermit for GOULD ---------------------------------------------------------------------- Date: Thu 25 Apr 85 14:27:09-EST From: Frank da Cruz Subject: New Macintosh Kermit Prerelease Available for Testing To: Info-Kermit@CU20B, Info-Mac@SUMEX-AIM This is to announce a pre-release version of Columbia Macintosh Kermit. This program is equivalent to the new C-Kermit in its capabilities, implementing the full range of encoding, compression, and block check options, and includes a fairly complete VT102 terminal emulator and a Macintosh-style user interface. The program is based on C-Kermit, and shares the same C language source for the protocol-related modules (but the version of these protocol modules is later than the currently released version of Unix Kermit). Macintosh Kermit is presently built using the SUMACC Unix-based cross development environment; a future release might also allow it to be built using a Macintosh-resident C language development system. This pre-release is intended primarily for evaluation at sites familiar with Kermit. We are soliciting helpful and constructive comments, suggestions, and detailed, specific bug reports. There are some features we haven't put in, but MAY add in later releases; these are listed just so that everyone won't feel compelled to suggest them: . A manual (currently only short help and beware files are included) . Key mapping, including redefinition/relocation of control and meta keys . Somewhat more intelligence about Macintosh file attributes & structure . XON/XOFF . Server operation (Macintosh acts as server) . Screen save/rollback (maybe) The program is currently about as big as a program can get on a 128K Mac (the SUMACC system does not provide dynamic segment loading). Some of the missing features, particularly screen save/rollback and key mapping, could put it over the edge. The files are available for anonymous FTP from CU20B as *.*. The file CKAAAA.HLP tells what the files are. The file CKMKER.HLP contains user documentation (just a little) and installation instructions (most people will want to simply download the binhex'd MacKermit resource), and CKMKER.BWR lists the known bugs and limitations. This prerelease is not really intended for wide distribution. It is mainly to get what we've done so far into the hands of those on the net who will be able to make useful contributions (in the form of bug reports, criticisms, and suggestions) which will be filtered into the first "real" release of MacKermit for general consumption. Please send all such reports to Info-Kermit@CU20B. ------------------------------ Date: Monday, 22 Apr 85 21:17:41 EST From: nbush (Nicholas Bush) @ sitvxb.ccnet Subject: VMS Kermit 3.1.066 Available I have finally put together a copy of VMS Kermit which should be suitable for release. This fixes all the bugs I know of (unless I forgot some minor ones) as well as adding a couple of new features. Here is a summary of the changes (also found in VMSV31AN.RNO/MEM): There have been a number of new features and fixes to VAX/VMS Kermit-32 3.1.065. 1. Send packet buffer size was increased to allow for maximum size Kermit packets. It was previously 4 bytes too short. 2. When sending FORTRAN carriage control files, if the first character is not a valid carriage control character, it will be passed along instead of thrown out. 3. CONNECT no longer fails in strange ways on DECnet terminals. 4. Two (or more) RECEIVE commands in a row now work. 5. Kermit-32 now has a TAKE command (also "@"). Kermit-32 also performs an automatic TAKE of VMSKERMIT.INI or whatever file is pointed to by the logical name VMSKERMIT. 6. LOCAL and REMOTE commands which spawn a subprocess now work correctly under VMS 4.x. 7. Terminal names longer than 7 characters now work (VTAnnnnn). The limit for a physical terminal name is now 16 characters (I hope DEC doesn't up it anymore). 8. VMS 4.x added more bits to the field where the terminal parity was. Ensure we only change the parity. 9. STATUS command had the headers backwards. Fix headers to correspond to data values being output. 10. SET IBM_MODE now simply sets the individual items. The values for IBM mode can be specified at link time by defining the global symbols: 1. IBM_MODE_CHARACTER = character value of handshake character 2. IBM_MODE_ECHO = 1 for local echo, 2 for no local echo 3. IBM_MODE_PARITY = (0 = none), (1 = mark), (2 = even), (3 = odd), (4 = space). If not specified, Kermit will continue to use DC1, local echo and odd parity for IBM_MODE. 11. Kermit-32 now has a SET HANDSHAKE nnn command to set the handshaking character. This is any octal value or the keyword NONE to turn off handshaking. ------------------------------ Date: 24 APR 85 10:58-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: Kermit-11 BITnet Server Available There is a BITNET Kermit server running on node UOFT02 with username of KERMSRV. This is intended to facilitate transfer of fixes or mods to Kermit-11 over Bitnet. It is a very simple-minded server, all it can do is return file(s) and directory listings. The system is a VAX 11/785 running VMS 4.1 with jnet. All file naming conventions must follow VMS rules, as in: VMS requestor: $ SEN/REM UOFT02 KERMSRV SEND K11CMD.MAC CMS requestor: CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11CMD.MAC Wildcarding is available. No directory names or logical names can be present in the filename. No binary files (.sav and .tsk) files are available via bitnet. As always, the Kermit-11 edit history is in K11CMD.MAC. brian@uoft02.bitnet ------------------------------ Date: Wed, 17 Apr 85 19:36:02 pst From: John Bruner Subject: S-1 Mark IIA Kermit Here at the S-1 Project at Lawrence Livermore National Laboratory we are doing supercomputer research. We have completed our current generation machine, the S-1 Mark IIA and we recently brought up multiuser UNIX on it. The S-1 talks to the outside world through attached I/O processors. At the present time there are no network connections and we haven't finished debugging the magnetic tape. We were forced to use a very contorted path to transfer files to the S-1 from our VAXes. Recently, however, we were successful in bringing up a very simple KERMIT on a serial line. Now we transfer source files in and out via a 9600 baud link to our VAX. The S-1 Mark IIA is probably the largest machine so far to run KERMIT, and almost certainly is the largest machine which depends upon KERMIT for access to the outside world. (The S-1 Mark IIA has an 80ns cycle time, a very complex instruction set, and 128 megabytes of main memory.) The availability of KERMIT made life much nicer for us as we finished our UNIX port. While I anticipate that UUCP will supplant KERMIT, I wanted you to know how much we appreciated having it. (Besides, I thought you might find it amusing that such a large machine benefitted greatly from it.) ------------------------------ Date: 21 Apr 85 14:48 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Commodore-64 KERMIT - a problem I have been testing Commodore-64 KERMIT version 1.3 with mixed success. Two problems ocurred: (a) 1200 baud did not work for file transfer (but worked OK in CONNECT mode). (b) After having started Commodore-64 KERMIT, the SEND command did not work. If however, I first made a GET command, then SEND did work after that. My test were made against a computer with CP/M-86 KERMIT. [Ed. - Your message has been relayed to the author, who is working on a new release of the program.] ------------------------------ From: pur-ee!pur-phy!duncan!mike@Berkeley Date: Thu Apr 18 15:44:19 1985 Subject: Kermit for Royal Alphatronic PC? Does anyone know where I could get a copy of Kermit for the Royal PC? I would really appreciate any info. Mike ------------------------------ Date: 22 Apr 1985 10:08:22 EST (Monday) From: John Shaver STEEP-TM-AC 879-7602 Subject: Apple II Kermit Support for CCS7710 Serial Card? Is there a Kermit for the Apple CCS7710 serial card? If not is there an assembly source for another similar source which might be adapted? ------------------------------ Date: Mon 22 Apr 85 17:16:14-EST From: Peter G. Trei Subject: Re: Apple II Kermit Support for CCS7710 Serial Card? The CCS7710 card should be supported in the next release, which is getting near. We hope to add a number of cards in this one. peter ------------------------------ Date: Mon, 22 Apr 85 14:40:50 EST From: Pamela J. Saia Subject: Looking for Kermit for GOULD I am looking for KERMIT which runs on a GOULD Concept 32/27 computer operating system:mpx rev 3.2A Prefer Fortran 77 but any information would be appreciated. Please respond to this address or call Gary Gustafson at (617)861-4178 (Hanscom Airbase) Thank you ------------------------------ End of Info-Kermit Digest ************************* ------- 30-Apr-85 17:05:53-EDT,16209;000000000000 Mail-From: SY.FDC created at 30-Apr-85 17:04:48 Date: Tue 30 Apr 85 17:04:48-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #22 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 30 Apr 1985 Volume 2 : Number 22 Departments: ANNOUNCEMENTS - Second Pre-Release of Columbia Macintosh Kermit Kermit for the Burroughs B7900 Minimum files for running VMS Kermit 3.1 MACINTOSH KERMIT PRERELEASE #1 FEEDBACK - .HQX file for new Mac Kermit Clarification on version #'s Comments on MacKermit Prerelease MacKermit Bug Report Problem and question re Mackermit MISCELLANY - Rainbow 100+ Kermit-MS vs MS-DOS 2.11? Kermit for Grid Compass? ---------------------------------------------------------------------- Date: Tue 30 Apr 85 15:37:44-EDT From: Frank da Cruz Subject: Second Pre-Release of Columbia Macintosh Kermit To: Info-Kermit@CU20B, Info-Mac@SUMEX-AIM This is to announce the second pre-release of Columbia Macintosh Kermit, version 0.6(4). It fixes a few problems with the first pre-release that were reported to Info-Kermit. These are discussed in detail in the messages below, but briefly they are: . Version number incorrect -- 0.5(0) should have been 0.6(1) . Bare CR's rather than CRLF's in .HQX file . Saved settings files not correctly closed in all cases . Transferred files not correctly closed in all cases . Can't get back to Switcher using Apple menu . Outgoing filenames not converted to uppercase . Certain limitations and features not documented The files are available via anonymous FTP from CU20B as *.*, and replace the earlier files in the same area. These are the new or changed files: CKAAAA.HLP List of files CKMFIO.C Macintosh file i/o CKMKER.BLD (new) Instructions for building CKMKER.BWR Beware file -- list of bugs, edit history CKMKER.HQX Binhex'd MacKermit resource file CKMKER.MAK Makefile CKMKER.RC Resource Compiler input CKMKER.RSRC MacKermit resource (8-bit binary) CKMSAV.C Settings Saver CKMSUM.C (new) SUMACC fiddling CKMUSR.C User Interface CKMUTL.C Utilities The first "real" release of this program will coincide with the next release of Unix C-Kermit, upon which it is based. This will probably be a few weeks hence, so in the meantime, keep sending comments and suggestions to Info-Kermit@CU20B. ------------------------------ Date: Tue, 23 Apr 85 09:36:02 EST From: Frank da Cruz Subject: Kermit for the Burroughs B7900 This is to announce a new Kermit implementation written in Algol for the Burroughs B7900 computer, contributed by Drs. B.J.M. Morselt, Technische Hogeschool Eindhoven, Netherlands. The files are in KER:B79*.*, available via anonymous FTP from CU20B. ------------------------------ Date: Friday, 26 Apr 85 17:34:04 EST From: nbush (Nicholas Bush) @ sitvxb.ccnet Subject: Minimum files for running VMS Kermit 3.1 Reply-to: SIT.BUSH @ CU20B To: Info-Kermit @ CU20B It is not necessary to have all of the VMSxxx files in order to put up VMS Kermit 3.1. If there is no reason for the site to rebuild Kermit from sources, the only files needed are: VMSMIT.HEX - "Hexified" copy of the .EXE file for Kermit-32 VMSDEH.MAR - Source for dehexifying program VMSMIT.RNH - RUNOFF source for .HLP files. Alternately, VMSUSR.HLP and VMSSYS.HLP can be retrieved. VMSV31AN.MEM - Description of changes between v3.0 and v3.1 If there is some need to rebuild Kermit from the Macro-32 sources, you will need to include VMS*.MAR, VMS*.COM and VMS*.MSG. If Kermit is to be rebuilt from the Bliss sources, retrieve VMS*.BLI, VMS*.MSG, VMS*.REQ, VMS*.COM and VMSGEN.MAR. Note: If you do not have a Bliss compiler, there is no reason to get copies of the .BLI and .REQ files, since the .MAR files include the Bliss source listing. Likewise, if you have a Bliss compiler there is no reason to get copies of the .MAR files (except VMSGEN.MAR), since they are just built from the Bliss sources. Hopefully, this will cut down on the file transfer times for those who need a new copy of Kermit-32. - Nick [Ed. - Note that several files were either missing or were left over from the old version when the announcement of this new version first appeared in the last digest; they are now correct. The files are KER:VMSGLB.MAR, KER:VMSMIT.MAR, and KER:VMSSYS.MAR. Also, apologies for not mentioning in the initial announcement that the files are available as KER:VMS*.* via anonymous FTP from CU20B.] ------------------------------ Date: Mon 29 Apr 85 09:14:29-CDT From: Bob Subject: .HQX file for new Mac Kermit To: sy.fdc@CU20B This may be a problem on my side, but both times I transferred copies of CKMKER.HQX to our DEC-20 here, the file came over with ONLY CR's at the end of each text line. A quick TECO job (showing my age) fixed it but thought I'd mention it--just in case there's something wrong on your side. I've only used the new Kermit a couple of times so far and really like what I see. Thanks for all the good "stuff" you and your people do. Bob Paver [Ed. - Sorry, the .HQX file has been fixed to have CRLFs rather than just bare CR's between the lines.] ------------------------------ Date: Mon, 29 Apr 85 01:21:44 pdt From: Harry Saal Subject: Clarification on version #'s To: info-kermit@cu20b.ARPA I ftp'd the mackermit.hqx file from on cu20b and the .hlp file that is there also. The .hlp file refers to a version V0.6(1), but looking at the About Mackermit screen on the Apple Menu says that the version available for beta-test is V 0.5(0). Thought you would like to know about this so you can track down problems against the current version. [Ed. - The first pre-release contained all the advertised features and bugs, but the version number was wrong. The new release has an appropriate version number.] ------------------------------ Date: Sat 27 Apr 85 09:19:33-PST From: Doug Brutlag Subject: Comments on MacKermit Prerelease To: info-kermit@CU20B After using MacKermit to communicate with both a TOPS-20 system at 1200 BAUD and MSKERMIT on an IBM PC at 9600 BAUD I have noted the following problems which were not mentioned on CKMKER.BWR. I should mention that I got KERMIT.HQX from CU20B Thursday evening the day of the announcement and I am running it on a 512 K Mac but configured with Switcher to be in 128 K. 1) KERMIT does not SEND/RECEIVE files from the DEFAULT disk. Instead it always looks at the disk from which it has been launched. This is inconvenient since you must always have a copy of MacKermit on the disk which contains your data. | We tested SENDING from a second disk to DEC and VAX Kermit, it | works. Select the file and volume you want in the SFGetFile | dialog. Please Supply further information if this is still a | problem. | | For GET you can specify the disk name when you specify the | file name -- "Startup:foo.c" -- this is a MAC standard done by | the file manager. 2) SAVED SETTINGS files are not actually closed until after you QUIT MacKermit properly so if you SAVE SETTINGS and then reboot and try to RESTORE SETTINGS from that file you get an Error reading file -39. If you actually QUIT MacKermit and then relaunch it, you can then RESTORE from a SETTINGS file. | This problem has been fixed in MacKermit V0.6(4), a FlushVol | was added after a close. 3) There also seems to be a problem with properly closing transferred files. If one downloads a series of files to the MacKermit and then uses switcher to move to the FINDER those files are not visible on the desktop or in the opened Disk window. If you RELAUNCH a new finder the files appear. The files are present in File Selection menus and hence it is just their icon that appears missing from the finder. Most other applications I have used that create new files set something in those files that cause the FINDER to generate their icon when you switch to it in Switcher. | This has been fixed in MacKermit V0.6(2), we added a FlushVol | in the file close routine and now all works well. 4) In the communications SETTINGS menu the PORT and AUTOWRAP settings do not darken when selected. | Will document. These are not supported. 5) If one starts a file transfer and something is wrong at the other end (like forgot to start kermit) it takes a long time for KERMIT to time out. It would be nice if in addition to the CANCEL FILE and CANCEL GROUP buttons there was an ABORT button like Control-C in MSKERMIT. Either this or to document the Command-. on the file transfer progress window would be helpful. | Will display Command-. message. 6) If one types in a filename in lower case in the file transfer window when sending to a TOPS-20 system, the file name on TOPS-20 comes out in lower case!! This makes it very difficult to reference the file to delete or to type it. One has to type control-V before every character of the name in order to reference filenames in lowercase on TOPS-20. Is there any way one could prevent MacKermit from sending TOPS-20 a lower case filename but still allow this for UNIX systems? | There is code to uppercase outgoing filenames. When the "AS" | filename is specified in the SEND dialog MacKermit does not do | file name conversion. We changed the dialog to no longer | stuff the "AS" filename. Also we found a bug in the file name | conversion routine which failed to deposit a NULL at the end | of the converted name. These two changes made to MacKermit | V0.6(1) should solve your problems. | | We had not noticed this problem because TOPS-20 is doing | conversion for us, it can for you too by using the most recent | version of 20 kermit, 4.2(255). 7) The Close box in the MacKermit window does nothing. It might make a nice way to Quit the program. | Matter of taste. 8) Sending DATA files to and from other kermits worked fine but whenever I tried to send a Resource fork (I tried sending BINHEX 4.0) it always hung (and always on the same packet, 9 for BINHEX 4.0). | We tried sending Binhex 4.0 and other resource files from | MacKermit to a VAX/Unix and DEC-20 Kermit and could not reproduce | this problem. What version Kermits are you using, what are | the parity settings? Does anyone else have this problem? 9) Terminal emulation: The display supports all VT100 commands I tried and works well with display programs on TOPS-20, but key board support is lacking. The Numeric keypad does not send standard VT100 characters, nor is the command=numeric keypad setting implemented. Also MacKermit does not respond to the ALTERNATE KEYPAD APPLICATION command from the host. The Command key works nicely for the rest of the keyboard even with shifted characters and unshifted ones. It would be nice if the OPTION key worked like a META key, either setting the eighth bit OR sending an escape character before each character typed. The latter implementation has the advantage that it works over 7 bit networks. | All known. Some of this may be addressed in future versions. In general MacKermit works very well and I think you have another winner on your hands. Doug Brutlag ------------------------------ Date: 28 Apr 1985 1534-PDT (Sunday) From: Elgin Lee To: Info-Kermit@cu20b Subject: MacKermit Bug Report I just picked up MacKermit -- it looks very good! I think I've found a couple of bugs, though: 1. Double-clicking on a settings file doesn't work -- I get system error 02 on startup. | We haven't seen this problem and can't reproduce it. It | sounds like your finder is running the settings file instead | of the CKMKER file. This would occur for example if you | modified your settings file to be type APPL instead of type | TEXT; or you forced the finder to run the settings file by | using the magic command-option-shift-capslock-double-click. 2. With Switcher 2.0, using the Apple menu to get back to the Switcher doesn't work. Command-\ does work, however. I have no problem getting the Apple menu route to work in other applications. | This problem has been fixed in MacKermit V0.6(3). 3. Trying to switch between active MacKermit and MacTerminal programs doesn't work. I either get system code 02, continuous rampaging through memory, or a never-ending sequence of alert boxes telling about error at the Serial Port -- error -28. I'm not sure if this is a Switcher bug or MacKermit bug, but I thought I'd mention it anyway. I've had no trouble switching between two active MacTerminal programs. | Not totally true. If one of the two programs closes the port | on the other these things can happen, but otherwise we've used | that combination fine. Definitely a proceed-at-your-own-risk | situation. Maybe we'll install some recovery for the error | that occurs when the serial port is closed from beneath | MacKermit. Well, that's about it. Other than that, MacKermit looks very good. Elgin Lee EHL@SU-NAVAJO.ARPA ------------------------------ Date: Mon, 29 Apr 85 01:25:57 pdt From: Harry Saal Subject: problem and question re Mackermit To: info-kermit@cu20b.ARPA 1. I tried using MacKermit 0.5(0) (??) when I had the analog watch desk accessory running in the corner (it is on info-mac..). I did not get any characters from the keyboard handled by mackermit. When I closed down the accessory, all was ok. SOmeone is guilty... | MacKermit only accepts input if the terminal emulator is the | front window. We decided at one point that this would be | a good thing because otherwise typein to desk accessories is | accepted by Kermit. A better solution would be to check for | active rather than front window. This will be inserted in | our to do list. 2. Question about 9600 baud operation. Can I use it for server/host file xfers, if I do not have a response window open, and am just going from file to file and not the screen? The comments about 9600 baud being a problem in the HLP and BWR documents put me off.... | 9600 baud is fine, just loses some chars if a number of | screens are sent continuously. No problems during protocol. 3. By the way: THANKS A LOT for this. I was struggling with the old simple buggy MacK and this seems to do what I was looking for. Now I am about to see about using the IBM PC-Kermit for a server implementation, driven by MacKermit as Users. It looks like MacKermit running against UNIX C-kermit was fine when I tried it. Next to beat on the PC.,.. wish me luck!!!!!!!!!!!!! ------------------------------ Date: Mon 29 Apr 85 08:09:06-EDT From: Harry Berger Subject: Rainbow 100+ Kermit-MS vs MS-DOS 2.11? To: info-kermit@CU20B I tried using version 2.27 of kermit on a Rainbow 100+ under MS-DOS 2.11 without any success. Once I entered the CONNECT command nothing further will happen. Has anyone else come across the same problem? If so what needs to be done to get around the problem. [Ed. - I have had confirmation that 2.27 MS-DOS Kermit works OK on the Rainbow under MS-DOS 2.11 on a hardwired connection. The only problems I can imagine would involve the pesky business of DTR dropping, detection, etc, which seems to change with every DOS version. Anybody out there with DOS 2.11 and Kermit 2.27 that can shed some light on this?] ------------------------------ Date: Sun, 28 Apr 85 00:07:55 est From: Alan Parker To: SY.FDC@CU20B.ARPA Subject: Kermit for Grid Compass? Are you aware of a kermit for Grid Compass 1101? -Alan [Ed. - Not me. Anyone out there working on one?] ------------------------------ End of Info-Kermit Digest ************************* ------- 3-May-85 19:10:57-EDT,18128;000000000000 Mail-From: SY.FDC created at 3-May-85 19:10:30 Date: Fri 3 May 85 19:10:30-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #23 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 3 May 1985 Volume 2 : Number 23 Departments: ANNOUNCEMENTS - New Minor Release of DEC-20 Kermit MACINTOSH KERMIT - Mac Kermit bomb New Mackermit problem MacKermit V0.6(4) Comments MacKermit and Disk Default C-KERMIT - C-Kermit for Amdahl UTS? C-Kermit under Xenix? (Several Messages) C-Kermit with Compressed Files Bug in C-Kermit MS-DOS KERMIT - Kermit 2.27/Rainbow MS-DOS 2.11 Data General D200 Terminal Emulation for IBM-PC Kermit? KERMIT for TI-PRO with TI Internal Modem? MISCELLANY - To Ship Files up to a Cray ---------------------------------------------------------------------- Date: Thu 2 May 85 14:31:52-EDT From: Frank da Cruz Subject: New minor release of DEC-20 Kermit To: Info-Kermit@CU20B.ARPA This is to announce a minor new release of DEC-20 Kermit, version 4.2(256), which fixes several small problems: . Kermit-20 would ACK an EOF packet even if it couldn't close the incoming file. . Remote directory commands with no arguments to Kermit-20 server sometimes crashed Kermit-20. . I/O errors (e.g. quota exceeded) while writing debug log file would crash Kermit-20 . . Incoming filenames that started with dot could not be reasonable renamed by Kermit-20. . The "push" command message was misleading if "push" command issued from prompt level. . The "server" command message was misleading if Kermit-20 in local mode. The source file is in KER:20KERMIT.MAC, the binary in KB:20KERMIT.EXE, and a list of known bugs and restrictions for this version in KER:20KERMIT.BWR, all available from CU20B via anonymous FTP. Other files (documentation, etc) have not changed. ------------------------------ Date: Wed 1 May 85 01:16:37-PDT From: Richard Furuta Subject: Mac Kermit bomb I have a Mac Kermit configuration file in which all I've done is set the speed to 1200 baud. I can start Kermit without trouble by double clicking on that file. If, however, I duplicate the file with the Macintosh clover-D command and then try double clicking the copy to start Kermit, I get a system error, ID=03. This is repeatable. [Ed. - The problem was that SUMACC had an erroneous definition. A workaround has been installed in the current release, 0.6(5), and the problem reported to the SUMACC folks.] I am also having difficulty convincing a VM/CMS Kermit to talk to this one but that is probably my own fault for not being comfortable on the IBM machine. I can't get anything at all to happen. We speak to the IBM 4381 thorugh an "IBM 7171 ASCII Device Control Unit." What should the proper settings be on both ends? What settings correspond to the "IBM" setting mentioned in the Kermit User's Manual? [Ed. - We use Mac Kermit to talk to our VM/CMS Kermit all the time. HOWEVER... we're not going through a 7171 (equivalent to a Series/1 with the Yale IUP). The reason you can't transfer files through it is that the 7171 is merrily converting your packets into the ASCII equivalent of 3270 screen commands. The solution: wait until version 2.00 of VM/CMS Kermit comes out (next week, I hope), which will include code to communicate through front ends like this.] ------------------------------ Date: Wed, 1 May 85 08:47 CDT From: Stewart_French Subject: New Mackermit problem I am attempting to use the New Mackermit and am having an interesting problem. I have the following setup that I use to communicate with our VAX/VMS system. I have Kermit version 3.0.052 for VAX/VMS. [Ed. - Diagram omitted.] The Novation talks to the Mac at 8-bit no parity, then converts it to 7-bit odd parity to talk with the LAN (Novation command "%F 2" converts to 7-bit odd parity) over the phone lines. The novation intercepts '%' characters, the LAN intercepts '~' characters. Both can be changed. I want to transfer simple ascii text files (at least for now). The old MacKermit worked just fine when I made the attention characters CONTROL-G for the novation. I did not have to change the LAN attemtion character '~'. The new MacKermit will not talk at all through this set up. It immediately attempts retransmissions until it fails. Can you help me?? -Stewart French french%ti-eg@csnet-relay [Ed. - The problem is that the new Mac Kermit does data compression using tilde ('~') as the lead-in character for a compressed sequence. If the old Kermit worked at all, it was only because your data never happened to contain a '~' character.] ------------------------------ Date: Thu, 2 May 85 9:31:32 EDT From: Dave Swindell Subject: MacKermit V0.6(4) Comments I just finished installing MacKermit V0.6 on a thin Mac and thought I would pass on a few comments. All of the major commands I tried, such as SEND FILE, RECEIVE FILE, GET FILE, and the REMOTE commands worked as advertised. I was a little supprised to see that I had to open a special window on the MAC in order to see the output from the remote servers (I tried MacKermit with a Tops-10 Kermit as well as CKermit). Might it be better to offer distinct 'CONNECT' and 'CLOSE Connection' menu items on the Mac? This would make the program more similar to its counterparts on other microprocessors. [Ed. - You're right about the remote command window -- it should pop up automatically for remote commands that cause text to be sent back. Mac Kermit is connected by default mainly because there's no reason not to be, and this seems more in keeping with the Macintosh style.] The VT102 (?) terminal emulation worked well, for the most part. MacKermit correctly processed the ANSI codes for screen erase, cursor positioning, video attributes, and scroll region select. I was not able to generate any of the special line drawing characters which are present on a VT1xx terminal equiped with AVO (advanced video option). Will these characters be supported in the final release?? [Ed. - Mac Kermit uses an ordinary system fixed-width font for terminal emulation; no VT100 drawing characters, nor double-width/height equivalents are available in that font, and won't be added to Kermit in the forseeable future because of space restrictions.] As a final comment, I noticed that when I used the RECEIVE FILE command, I could not specify a new file name for the received data, as is possible with Kermit-65 and MS-Kermit. You are given this option when you GET files from a remote server. I think that the ability to specify a new name for received files is important and hope that the this feature will be added to the 'real' release of MacKermit. [Ed. - Agreed; this will be in a future release.] All in all, I was very pleased with the New MacKermit. I was able to transfer resource and data files with no problems. Thanks for all of the hard work! Dave Swindell BBN Labs ------------------------------ Date: Fri 3 May 85 10:34:14-PDT From: Doug Brutlag Subject: MACKERMIT AND DISK DEFAULT I am still having difficulties with MacKermit 0.64 not receiving files onto the default disk. When you use GET.. from a server at the other end, MacKermit always saves all the files on the disk from which Kermit was launched. If you change the DEFAULT disk from internal to external using DISKINFO disk utility MacKermit still stores files on the internal disk. Most other Mac software respects the setting of Default disk and does all of its file i/o to the default disk. I tried your suggestion of GETing files and specifying the disk name in the AS box like this: GET *.INIT AS EXT-DISK:*.INIT. MacKermit stored the first file on the EXT-DISK but with the filename *.INIT (!). Then it stored all subsequent files with there normal file names on the internal disk. Maybe I should have just specified EXT-DISK: with no filename but it sure would be nice if MacKermit would save to the default disk like WORD, FILE, MacWrite, MacDraw etc... Doug Brutlag PS. I noticed that the Command-. abort was still not documented in the file-transfer progress box, nor did the number of Kilobytes register when GETing files from a server. [Ed. - We're working on new send/receive dialog boxes, but they won't be ready for a while.] ------------------------------ Date: 2 May 1985, 18:38 EDT FROM: ACDMAYER%UOGUELPH.BITNET@WISCVM Subject: C-Kermit for Amdahl UTS? What is the state of the UTS version of C-Kermit (4.2)? If it is going to be a while before it's released, maybe I will do the conversion myself. (At least as best as UTS will allow). (ALASTAIR MAYER ) [Ed. - We have UTS version 2.4 at Columbia, but we're about to retire it in favor of their new system V version. I gather that everyone else will be doing the same, since Amdahl is "desupporting" the old one after six months, and it doesn't cost much (at least to universities) to upgrade. Since they seem to be shipping the new one now, it would be a waste to adapt C-Kermit to the old one. If you want to adapt C-Kermit to the old UTS, be my guest. But wait until the new C-Kermit comes out (version 4C, probably next week).] ------------------------------ Date: Wed, 1 May 85 08:09:37 pdt From: Bob Rendler Subject: C-Kermit under Xenix? Does anyone have Ckermit running on an IBM PC/AT under Xenix? Following the instructions in the makefile we did a "make xenix" to make kermit on the PC. We are having problems with 'connect'. When the carriage-return is typed to get the prompt to log into the remote we get "Communications Line Failure". We are using the same line for MSkermit and do not experience this problem. Thank you. Bob Rendler [Ed. - See below.] ------------------------------ Date: Monday, 29 April 1985 14:47-MDT From: Jim Scardelis Subject: C-Kermit under Xenix? Has anyone gotten C-kermit successfully running under Xenix 3.0? I have given up trying to get it to run on an IBM PC/AT Xenix system... Jim Scardelis ------------------------------ Date: Fri 3 May 85 09:32:57-PDT From: Herm Fischer Subject: C Kermit and Xenix for the IBM PC/AT C Kermit does indeed run on the IBM PC/AT Xenix. You should have no problem if you use "make xenix" to make it. The IBM PC/AT has been one of the prime development machines for the recent versions of C Kermit, and thus your query surprises me. If you totally fail to be able to get C Kermit up, the only suggestion I could make is to obtain a binary copy directly from another PC/AT which is using it. It has been tested on "stock AT's", "xtal-speedup AT's", modems, modems using the old serial cards, and LANs with flow control. Herm Fischer [Ed. - Versions prior to 4.2 lacked the data-carrier-detect/CLOCAL code that overcomes the most commonly reported problems. The next release, version 4C, will have additional improvements in this area.] ------------------------------ From: trwrb!trwspp!spp3!kurisaki@Berkeley (Lance R. Kurisaki) Date: Fri, 3 May 85 08:00:46 pdt Subject: C-Kermit with Compressed Files In volume 2 number 4 of Info-Kermit, James Woods tells us how we can use the kermit to transfer compressed files, and increasing the effective transfer rate. I have been trying to use kermit in the way described and have been having some problems. When I receive a file "passively" with the "-k" option, kermit seems to be adding a leading CR, so that when this is piped to compress, it comes back with "not in compressed format". This happens even on text files. Has this behavior been noticed by others, or am I doing something wrong here? By the way, I'm using 4.2 C-Kermit to transfer files between two Pyramid 90x's under the 4.2bsd universe. Lance Kurisaki {ucbvax|decvax}!trwrb!trwspp!kurisaki ------------------------------ Date: Thu, 2 May 85 21:16:29 edt From: xp!tony@nyu-cmcl2 (Tony Movshon) Subject: Bug in C-Kermit This one may be known, but it should be fixed. A user under the misapprehension that it is necessary to "set line" to his home tty (i.e. if you are already on /dev/tty05, "set line /dev/tty05") will be permitted to do this. He may also "set baud" to something other than the current line rate. At that point, "connect" connects you to your own terminal, at a different baud rate. !>poof Subject: KERMIT for TI-PRO with TI Internal Modem? I have looked on the DEC-Marlboro system CURRENT.DOC file, but I don't find a TI-PRO version of KERMIT for the TI-INTERNAL modem. Joe Smith's version 2.27 is for the normal sync/async card, and using an external modem. If you know of any version for the TI internal modem, please let me know. If there is no official notice of a version, can you include my query in a future issue of KERMIT DIGEST? Also... I have tried Joe Smith's TI-PRO v.2.27 with Tek4010 emulation. When I run a SAS job on our IBM4341, specifying a device type of TEK4010, I get rows of horizontal bar characters across the top of the screen in addition to my graphics, and if the SAS job results in normal text characters as part of the output (such as labels on a pie chart), the text gets printed on the screen right after the two rows of horizontal bars. It appears that real cursor positioning, and intended cursor position requests are not working so good. [Ed. - I trust you told the PC that you were talking to an IBM system, using "do ibm" or the appropriate "set" commands.] I understand that Joe Smith has left CSM. Is anyone else aware of the problem I have described? How can a fix be pursued? (I am not familiar with internals of the KERMIT programs. I just enjoy its functionality in my work with mixed computer systems at TI.) Richard Berke Texas Instruments Equipment Group PO Box 405 MS 3454 Lewisville, Texas 75067 (214) 462-5918 ------------------------------ Date: Wed, 1 May 85 13:48:56 mdt From: djw@LANL.ARPA (David Wade) Subject: To Ship Files up to a Cray I have been getting a lot of long distance phone calls from people trying to talk to the crays with kermit. They don't have our mskermit.ini file to make a few simple changes to make the cray kermit work better. Therefore, here it is: set baud 1200 set parity even define cray set end 23, set send padch 26, set send padding 1 This makes a few adjustments to the "end, padch, & padding" characters. If you adjust your kermits to: set the "end of packet" character to ^W (Control W) i.e. 23 set the "padding" character to ^Z (Control Z) i.e. 26 set the number of padding characters to 1 These changes will allow you to talk with the Cray kermits directly. There is a special case at Los Alamos that applies to people coming in over arpanet. The front end machine runs an abbreviated Unix(tm) system and that includes the Unix kermit. Use that one to get your files to Los Alamos if you are on Arpa. Then convert the files to "Standard Text format" and "Move" them to the Cray of your choice. ------------------------------ End of Info-Kermit Digest ************************* ------- 7-May-85 19:42:44-EDT,2135;000000000000 Mail-From: SY.FDC created at 7-May-85 19:42:02 Date: Tue 7 May 85 19:42:02-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #24 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 7 May 1985 Volume 2 : Number 24 Announcing Version 2.00 of CMS Kermit ---------------------------------------------------------------------- Date: Mon 6 May 85 17:49:51-EDT From: Daphne Tzoar Subject: Announcing Version 2.00 of CMS Kermit To: info-kermit@CU20B.ARPA Version 2.00 of Kermit-CMS is now available. Some of the new features are: - Prefixing of the "8th bit". This allows CMS Kermit to send or receive fixed format binary data, such as microcomputer binary files. - The maximum record length allowed has been increased to 64K for both incoming and outgoing files. - Repeat count prefixing has been added to speed up transmission. - Support for two character checksum and three character CRC. - New debugging mode to log packets. - Input to command parser allowed from command line. Multiple commands should be separated by the linend character. After execution of these commands, Kermit returns control to CMS. - Support for Series/1 front end with Yale ASCII package. - Server operation. - Upon startup, read commands from two init files: SYSTEM KERMINI and (USERID) KERMINI (that is the userid of the person running Kermit). Add TAKE command. - Allow system manager to change ASCII/EBCDIC translation tables to conform to the various specifications of different systems. Also, bypass user translate tables when sending and receiving data. Work on CMS Kermit continues. Daphne Tzoar Columbia University Center for Computing Activities [Ed. - The files are available on CU20B as KER:CMS*.* via anonymous FTP, and on BITnet via KERMSRV at CUVMA. Included is a new Kermit User Guide chapter for CMS Kermit.] ------------------------------ End of Info-Kermit Digest ************************* ------- 10-May-85 19:11:10-EDT,8090;000000000001 Mail-From: SY.FDC created at 10-May-85 19:10:35 Date: Fri 10 May 85 19:10:35-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #25, C-Kermit 4C Announcement To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 10 May 1985 Volume 2 : Number 25 C-Kermit 4C Available for Unix, Macintosh, and VAX/VMS ---------------------------------------------------------------------- Date: 10 May 1985 7:01pm From: Frank da Cruz Subject: C-Kermit 4C Available for Unix, Macintosh, and VAX/VMS Release 4C of C-Kermit is now available. It does not embody major functional changes over the previous version, 4.2 (note, the version number style was changed to avoid confusion with Berkeley Unix version numbers), but has many bugs fixed and includes support for many more systems, including: . Berkeley Unix 4.2 (Columbia U) * . Berkeley Unix 4.1 (Charles Brooks, EDN) * . ATT System III and System V (Herm Fischer, Encino CA) * . Unix Version 7 (Gregg Wonderly, Oklahoma State U) * . Berkeley Unix 2.9 (based on V7) . Some "custom" Unix-like systems, including: * - PC/IX on IBM PC/XT (Herm Fischer) * - Xenix on IBM PC/AT (Herm Fischer) - DEC Pro/Venix Version 1 (improved performance & functionality) (Columbia) * - NCR Tower OS 1.02 (didn't work before, allegedly fixed) (John Bray) . And two major non-Unix systems... - Apple Macintosh (Columbia U) * - VAX/VMS (Stew Rubenstein, Harvard; Martin Minow, DEC) Adding support for all these new systems has been a network-wide effort. Although every attempt has been made to ensure that adding support for system B did not break the program for system A (and adding support for C did not break A and B, etc etc), some of the key contributors have become unavailable since sending in their code and have not been able to test it. The implementations marked with an asterisk above have not been tested in the very latest edit; they worked recently and should work now, but this cannot be guaranteed. I would appreciate it if users of each of these systems could report back to Info-Kermit indicating whether the program works on their system, and if not, what the symptoms are and if possible include fixes. * Legalisms Copyright notices have been added to all the source modules to reduce the possibility that restrictions upon distribution and redistribution of the Kermit source code could be imposed by ATT or ATT sublicensees. * Distribution File Names Since so many more systems are now supported, it has become necessary to devise a more sensible naming scheme for the source files. This was done, and is described in the file CKAAAA.HLP. The files have all been (re)named accordingly. * Protocol Many changes have been made to the protocol modules and header files shared by all the systems that run C-Kermit. The changes are listed in detail in the CKUKER.UPD file; a few of the major ones are: . Organizational changes to allow better support for mouse/window systems. . The method for mapping between CRLF and a system-dependent newline character is now selectable at compile time, rather than hardwired into the program. . In the last release of this program, files transfer would occasionally omit bytes and the end of a file; this no longer happens. . R, X, or F packets sometimes had garbage characters preceding their intended contents; this no longer happens. . The file output function did not return a failure code upon i/o error or disk full, so failed transfers were reported as OK; this no longer happens. . Unix-specific symbols or values (like init file name, program return code) that were hardwired are now compile-time symbols. * Unix In addition to the support for extra Unix and Unix-like systems, several functional changes were made to the program: . Interactive command lines and lines in take files may now be continued on new lines by putting a single '\' character at the end. This can make long script commands more readable. . Some attempt is made to recover from i/o or disk full errors when writing to the session log during connect. . Support for new modem dialers added - Racal-Vadic, Penril, Cermetek, etc. . Script command has a few new escapes: ~d(elay), ~w(ait), ~x(on). . Long strings and/or (f)printf arguments have been shortened enough for them to work on all systems (let's hope!) . File renaming and name collision avoidance is improved. . Directory command is no longer "recursive". . '!' command now invokes user's login shell instead of always using sh. * VAX/VMS: C-Kermit has been adapted to VAX/VMS; the result has been tested successfully, but not extensively. The main deficiencies are probably in the areas of performance and intelligence about the VMS/RMS file system. C-Kermit for VMS should not be regarded as a replacement for the Stevens Institute of Technology Bliss implementation, but reports as to its usefulness are solicited. * Macintosh: A prerelease of this program appeared a couple weeks ago. Since then, thanks to many helpful bug reports from the net, many improvements have been made: . Parity settings should now mostly work. . Improved file dialog boxes, available now for GET, RECEIVE as well as SEND. . Many new file settings available (text/binary, data/resource, supersede/ preserve, etc), savable in the settings file (Note, settings files have new format, old ones can no longer be used). . ASCII text files now stored correctly, so Mac applications can use them. . Remote command window pops up automatically when needed. . Mac Kermit can be a limited server, responding to SEND, GET, BYE, FINISH, and REMOTE HELP commands. . Various changes relating to selection/specification of disk/volume/folder. . The beginnings of a manual (CKMKER.DOC). Several major areas will have to be attacked in subsequent releases (in order of priority): . Key redefinition, support for function keys, keypad, etc. . Saving screen contents into a file. . Support for XON/XOFF during terminal emulation. . Support for additional VT102 features. . Modem dialer support. . Login scripts. . Raw file upload. . Printer support. . Translation to a native Macintosh C compiler so you don't need a VAX to build the program (with conditional support for SUMACC left in), and so that the program can grow by taking advantage of dynamic segment loading, which SUMACC doesn't support. We are working on the first two items ourselves; contributions in other areas would be welcome. Macintosh C-Kermit has been successfully tested in conjunction with DEC-20s and VAXes (full duplex mainframes) at speeds up to 9600 baud, with IBM mainframes (half duplex, handshake, various kinds of parity) on both ASCII async ports and 3270-emulation ports at speeds up to 4800 baud, and with another Macintosh in server mode at speeds up to 57.6K baud. It runs on 128K and 512K Macs and on the "Macintosh-XL", standalone or with the switcher. * Distribution The files have been placed on CU20B in the area . The area has been removed. The previous releases of C-Kermit (4.2) and MacKermit (Steve Engel's original from Harvard) will remain in KER: until we receive reports verifying that the new version installs and works as advertised on all the systems listed above. Prompt reports would be appreciated, so that we can start putting the new C-Kermit on our distribution tapes. The files may be obtained via anonymous FTP from Internet host CU20B as *.*. The file CKAAAA.HLP explains what all the files are. Be sure to read the appropriate "beware" (.BWR) file before installing or running the program -- these files list all known bugs, restrictions, and peculiarities of each implementation. ------------------------------ End of Info-Kermit Digest ************************* ------- 13-May-85 19:37:17-EDT,7482;000000000000 Mail-From: SY.FDC created at 13-May-85 19:36:47 Date: Mon 13 May 85 19:36:47-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #26 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 13 May 1985 Volume 2 : Number 26 Departments: C-KERMIT 4C Bug in New Macintosh C-Kermit C-Kermit 4C Bugs DIALUP DISTRIBUTION Kermit Distribution Available via Kermit Server Change Of Kermit-11 Update Procedure MISCELLANY - Computer Vision Kermit? ---------------------------------------------------------------------- Date: Fri 10 May 85 21:38:53-EDT From: Bill Schilit Subject: Bug in New Macintosh C-Kermit To: sy.fdc@CU20C I sent a file from the Mac, I started a new transaction and emergency- exited with Command-.; C kermit deleted my file. [Ed. - Oops, sorry. This bug effects Mac Kermit only, even though the guilty code appears in the common protocol module -- only the Mac can cancel a transaction before the first data packet has been sent. The emergency exit code should not delete any files. The code is now fixed, see below.] ------------------------------ Date: Sun, 12 May 85 15:46:35 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) Subject: C-Kermit 4C bugs I got a copy of C-Kermit 4C, Friday evening, May 10. I built it on both our 4.2 bsd Vax and on one of our System V Vaxes. I found three new problems, and noticed that a fourth problem I've been trying to find in C-Kermit 4.2 is still present, though in a slightly changed form. They follow, in no particular order. 1. When getting a binary file, if the local kermit is the 4C bsd version, all will go well except that at the end, "Z [discarded]" will appear. [Ed. - This problem was introduced by adding code to zchout() to check when putc returns an error code -- the old char/int/sign-extension mixup.] 2. In server mode, remote commands issued by C-Kermit cause version 4C to hang the transfer with a continuous stream of NAKs. The remote commands I tried were "rem dir" and "rem host ls -l". The tests below were conducted with "rem dir". I tested the following combinations: [Ed. - This problem was introduced by adding code at the last minute to make the Macintosh version work better and then assuming it still worked on Unix.] 3. C-Kermit 4C Racal-Vadic modem support doesn't work with our Racal-Vadic modem on the System V machine. The bsd machine's modem line has been munged by uucp and needs superuser service, so I can't test that over the weekend. The gross behavior is the same behavior I observed with an early version of the dialer code, which was sent to me by Herm Fisher: it always times out. With Herm's code running on our bsd machine, I inserted prints to stderr, and observed that the conversation with the modem went as expected, until the actual dialing began (modem says "DIALING: "), at which point the modem seemed to go to sleep. My version of Racal-Vadic support (inserted into version 4.2) works. As I told Herm, by reading his code, I couldn't see why his shouldn't work. It did use the input buffer flushing routine (which was a no-op under 4.2's Vax bsd version) whereas my code does reads, but I modified the 4.2 buffer flushing routine to actually do something, and that didn't seem to help. [Ed. - Herm's away for the month, and I don't have a Racal-Vadic modem to fool with. If you or anyone can offer code that works, please send it in!] 4. Sending a binary file to C-Kermit often doesn't work. This isn't new with version 4C. I've been trying to track it down in version 4.2. Though it isn't entirely new, as you can see below, the variety of behavior has become richer. [Ed. - Same problem with zchout().] That's the C-Kermit bug picture as I see it. Unfortunately, I won't be able to pursue them further, in the immediate future. Other deadlines approach, you understand. For the time being, I think we'll continue using version 4.2. It has fewer bugs which impact us. [Ed. - Thanks for the quick report. We've fixed (I think) all but the Racal-Vadic modem support problem. The new files are in as CKCFN*.C, CKUFIO.C, CKVFIO.C, CKMFIO.C, CKCPRO.W, CKCKER.H, CKCMAI.C, and CKMKER.HQX (and .RSRC) available from CU20B via anonymous FTP. Some reorganization was required to fix bug number 2, and it has not been tested in the VMS version. Again, everyone who's interested please take these files away and try them out and report back whether they work on all the various systems and machines. Once the major kinks are out, C-Kermit v4C can be added to the normal distribution -- tapes, okstate (see below), etc.] ------------------------------ Subject: Kermit Distribution Available via Kermit Server Date: 10 May 85 12:03:41 CDT (Fri) From: Mark Vasoll We have set up a specialized version of the C-Kermit server that will allow access *only* to the Kermit Distribution area on our system. This service will be sharing the phone line with the UUCP account, so the line will probably be busy quite a bit. Anyway, access to the Kermit Distribution area is now available using the following dialing/login information: UUCP KERMIT SERVER Phone: (405) 624-6953 Phone: (405) 624-6953 Login name: uucpker Login name: kermsrv Password: thefrog Password: piggy The UUCP distribution will function as before. The KERMIT SERVER login will drop you right into a conversation with the server. The best place to start after logging on is "REMOTE HELP", followed closely by "REMOTE DIR". Mark ------------------------------ Date: 13 MAY 85 11:12-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA To: info-kermit@cu20b Subject: CHANGE OF KERMIT-11 UPDATE PROCEDURE This to announce that Kermit-11 updates should now be obtained from the University of Toledo's VAX 11/785 instead of the PDP 11/70, which is being removed from service. The dialup number for the VAX is (419) 537-4411. The front end is a Dual PACX 4, which will autobaud on a CR and then prompt for 'Service Class ', which is VX785A. The VMS username is KERMIT with a password of KERMIT. All source files are in KER: and Kermit-11 binaries are in KERBIN:. Please note that the VMS Kermit-32 server should be set to FILE TYPE FIXED in order to transfer any .SAV or .TSK files. This also means that a Kermit-11 getting files from the VMS server should have SET FIL BIN set for task and save images. brian nelson brian@uoft02.bitnet ------------------------------ Date: Thu, 9 May 85 21:58 CDT From: "David S. Cargo" Subject: Computer Vision Does anybody out there have a version of Kermit working for Computer Vision computer aided design systems? David S. Cargo (Cargo@HI-Multics) ------------------------------ End of Info-Kermit Digest ************************* ------- 14-May-85 19:36:33-EDT,7039;000000000000 Mail-From: SY.FDC created at 14-May-85 19:36:08 Date: Tue 14 May 85 19:36:08-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #27 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 14 May 1985 Volume 2 : Number 27 Departments: C-KERMIT 4C - C-Kermit 4C Bugs (Still) Missing File for C-Kermit VMS Make Procedure VMS C-Kermit 4C Works LCK files, parity, "backing out", aborting FINISH, make errors MISCELLANY - VM/CMS Kermit 2.00 vs IBM 7171 MSTIPRO Kermit with Internal Modem and TEK-4010 ---------------------------------------------------------------------- Date: Tue, 14 May 85 16:15:21 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) Subject: C-Kermit 4C Bugs (Still) I just finished getting the changed source files you recommended in the latest digest, and rebuilding on both a 4.2 bsd Vax and a System V Vax. I retested for the "rem dir"-hangs-on-NAKs problem. It's still there. I used the bsd Vax as the local Kermit, and the System V Vax as the remote. [Ed. - Dave reports the other problems fixed for these systems -- binary files transfer ok, etc. But sending any "remote" command to the C-Kermit 4C server on the System V VAX times out. The 4.2bsd VAX C-Kermit 4C server handles "remote" requests just fine, no matter what system they come from, even from itself. Anybody who can figure this one out will be a hero.] ------------------------------ Date: 13 May 85 14:05 EDT From: (David H M Spector) Subject: Missing File for C-Kermit VMS Make Procedure I found a problem with the distribution kit for C-Kermit. The VMS com file called "ckvmak.com", which becomes "CCMAKE.COM" is a copy of ckver.com, the 'makefile'. Attempting to run the make file will cause lots of errors as the com file goes into an endless loop. David Spector NYU/acf Systems group [Ed. - Sorry! The correct file is now installed as CKVMAK.COM, available via anonymous FTP from CU20B.] ------------------------------ Date: Tue, 14 May 85 13:04:15 EDT From: stew@harvard.ARPA (Stew Rubenstein) Subject: VMS C-Kermit 4C Works Seems to work OK; I have not tested it extensively, but things mostly work. There are some problems with file name canonicalization (it doesn't strip off version numbers before sending). This is with the new modules announced Monday. [Ed. - Thanks, Stew. I'm glad I didn't break your code too badly...] ------------------------------ Date: Monday, 13 May 1985 13:26:55-PDT From: d_schullman%sarah.DEC@decwrl.ARPA (Dan Schullman) Subject: LCK files, parity, "backing out", aborting FINISH, make errors Is it possible to clear the LCK* files on an interrupt? When I accidentally leave the line as a "modem" line and can't open it, an interruption leaves the LCK* file for the line around. Yes, and it is done in many cases -- e.g. when ^C is typed, when various fatal errors occur -- the program goes through doexit(), which is supposed to clear any lock file. But some other interrupts are not presently caught, and some can never be (e.g. if the process is killed from another process, or the system crashes). I agree this is an area that needs improvement. The new manual (CKUKER.DOC) discusses the perils of lock files in greater detail than the previous one did. I had trouble copying a binary file (but not a text one), and thought it was a KERMIT 4C/4.2 incompatability. Eventually turned out to be a parity problem. I don't understand why text files copy okay but binary ones don't. I thought KERMIT "packaged" the transmission so that only ASCII graphics would be used. Both "ends" were set for the same parity ("none"), and as stated I WAS able to copy text files. This should be fixed in the current (circa Monday, May 13) release of version 4C of the program. There seems to be some interactions with quoting from the command line. For example, try: ! echo "this should \07 ring" Even escaping the backslash doesn't help. This will have to be looked at. Meanwhile, you can always use a real control-G in the string -- it works both in shell commands and in Kermit's own echo command. Is there a way to "abort" questions if one has "gone down the wrong path"? For example, if one has answered the "from file" question and wants to get out of the "to file" question. I tried EOF (Control-D) but that didn't work. Currently no, short of typing Control-C, which gets you out of the program entirely. This too will have to be looked at. I often "hang" trying to do a FINISH, BYE, etc. Is there a way to abort these operations without exiting KERMIT? As mentioned in previous mail, this is sometimes because the remote server has returned to command mode for some unknown reason. Currently, there is no way to "abort" a protocol operation before data packets start to flow, short of typing ^C. This is true of most Kermits. Macintosh Kermit is an exception. Unix Kermit will have to have a more powerful interrupt facility added to it to fix this and several of the other problems you've mentioned. In building KERMIT on a SYS-V VAX, I got the following in addition to problems caused by multiple includes of types.h by ckxunx.h. "ckuser.c", line 916: warning: illegal combination of pointer and integer, op = These problems should be fixed in the current release. ------------------------------ Date: 14 May 1985 0954-EDT From: LCG.KERMIT@DEC-MARLBORO Subject: VM/CMS KERMIT 2.00 vs IBM 7171 I installed CMS kermit on our 3032 system that uses a 7171 front-end. I had to comment out two lines to get everything to work. At OKDEV - 3, remove 2 lines: * clc cons772,temp * bne baddev After that change, everthing worked. Thanks to Columbia for another great version, Wade Missimer Abbott Labs [Ed. - Thanks; this hint has been added to the CMSKERMIT.BWR file.] ------------------------------ Date: Thu 9 May 85 21:41:48-EDT From: Joe Smith (415)794-2512 Subject: MSTIPRO Kermit with Internal Modem and TEK-4010 In reference to Richard Berke's questions, 3-May-85. 1) The file KERMIT:MSTIPRO.HLP on MARKET tells how to use the internal modem on a TI Professional. This functionality was added before version 2.27 was released, but appearantly did not make it to VERSIONS.DOC. 2) The Tektronix emulation is for line drawing only. Since the system I developed it on drew labels using pen strokes, no attempt was made to make the alpha cursor track the graphics cursor. 3) Full HEATH-19 emulation is being added. The new maintainer is: Dan Smith (303)273-3396 Colorado School of Mines Computing Center 1500 Illinois Street Golden, CO 80401 ------------------------------ End of Info-Kermit Digest ************************* ------- 16-May-85 19:58:58-EDT,25017;000000000000 Mail-From: SY.FDC created at 16-May-85 19:58:30 Date: Thu 16 May 85 19:58:30-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #28 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B 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 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 *.* 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 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 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 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 : /* $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 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 [Ed. - The changes marked by "thanks" above are reflected in the files currently in 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 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 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 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 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 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 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 ************************* ------- 17-May-85 18:35:52-EDT,11036;000000000000 Mail-From: SY.FDC created at 17-May-85 18:35:13 Date: Fri 17 May 85 18:35:13-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #29 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 17 May 1985 Volume 2 : Number 29 Here is HP110 Kermit Omnet gives very silly criticism of KERMIT C-Kermit 4C for 2.9BSD Minor Kermit-11 Update On The Way Printing Kermit Docs on X2700? KERMIT for BBS's? ---------------------------------------------------------------------- Date: Fri, 17 May 85 14:30:34 mdt From: dwf@LANL.ARPA (Dave Forslund) Subject: Here is HP110 Kermit Attached is the file MSXHP110.ASM which is the system-specific source for MS-KERMIT running on the HP110 Portable. It should be used in place of MSXGEN.ASM in making the executable. We have used this code for about 2 months. The MSXGEN.ASM file from CU20B was modified by Chuck Aldrich here at Los Alamos and allows the changing of baud rates and the selection of the serial port or the internal modem. However, we have not tested the internal modem code. The default setting is the serial port (Port 1) and 9600 baud. The HP110 does not have built-in Basic, so the .BOO file bootstrapping technique won't work. But it does have a built-in terminal program which can be used to capture a file. The terminal program also has the XMODEM protocol built in. This can be used to capture binary files. The way we brought the source over was to download it with MS-KERMIT on an IBM-PC and move the file to the HP110 with the special IBM board that HP makes which allows the two machines to communicate directly to each other's disks. We have also modified the Turbo-Pascal Kermit to run under MS-DOS on the HP110. If you have Turbo-Pascal, then you could use it to ship over the MS-Kermit source, or executable. David Forslund (dwf@LANL.ARPA) [Ed. - Thanks! The source file has been placed in the Kermit distribution area as KER:MSXHPX.ASM, and the above message (plus some parts that were left out) in KER:MSXHPX.HLP. Note the strange filename -- Unfortunately, MSXHP110 is not distinguishable within six characters from MSXHP150, which was already there.] ------------------------------ Date: 16 May 85 13:22 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Omnet gives very silly criticism of KERMIT The following very silly and mean criticism of KERMIT was given in a newsletter called "Sciencenet/news" published by Omnet, Inc., 70 Tonawanda Street, Boston, MA 02124. First a picture is given of a princess, frightened by an ugly frog, and saying the words: "YYYYYUK! You're incompatible!". Then comes the following text: Software of the Month: KERMIT The Incompatible Trying to adjust to the fast-paced world of micro-computers instills its own brand of future shock on everyone. What we long for is simplicity and consistency, byt instead seem to get arbitrary rules and conventions. Recently, a new group of users, who had been using the public comain communications software KERMIT, signed on with SCIENCEnet. They hoped to be able to continue use this software package, which they had already mastered. KERMIT is a perfectly good communications package, - providing that you limit yourself to communicating with other systems which are also using KERMIT! And that's where the catch is. Some communications software packages, KERMIT among them, only allow files to be sent between computers using the same software. The advantage is that it allows for a certain amount of error checking to take place. This is advantageous because it eliminates problems introduced by bad phone lines over long distances. (Since calls to SCIENCEnet are local, this isn't likely to be a problem.) Many commercial communication packages offer the best of both worlds. For instance, using a micro software package such as Crosstalk, micro-to-micro file transfer with error checking over phone lines is possible. But, and this is the critical point, with most commercially available communications software packages, it is also possible hook up to SCIENCEnet to talk with all other systems. And herein lies the difference: with KERMIT, alas! the package only talks to other KERMITs; it won't talk to SCIENCEnet -- or anybody else! --- --- --- My comment on the above: No file transfer protocol with error correction facilities will be able to talk to any computer except a computer which implements the same file transfer protocol. The only possible way to do something more would be to write a file transfer program which can switch between several different protocols, and there is nothing in KERMIT which forbids such implementations. Because of its wide acceptance in the scientific community, KERMIT is however certainly the protocol which has largest changes of being possible to use between different makes of computers. The correct formulation of the above message in "Sciencenet/news" should perhaps read like this "We have not implemented KERMIT on our computer, therefore we think KERMIT is bad for you (and us)!". [Ed. - Thanks for the kind words, Jacob. The silliest part about the article is that Kermit is a particular file transfer protocol -- it's not commercial a product like Crosstalk that may embody several different protocols -- so of course it's incompatible with other file transfer protocols. There are indeed many commercial and public domain programs that provide Kermit alongside one or more other protocols, usually in conjunction with a fancy terminal emulator and lots of menus. In addition, many of the Kermit programs in the Columbia distribution allow "raw file capture" for getting files from systems that don't have Kermit; some allow "raw file transmission" as well. I wonder what system SCIENCEnet runs? Kermit is available at last count for about 120 machine/operating system combinations.] ------------------------------ From: Paul Graham Date: 16 May 1985 1713-PDT (Thursday) Subject: C-Kermit 4C for 2.9BSD Ok, when I first sent in the report on the 2.9 problem I was in debug mode and hadn't looked at ckutio.c from a global perspective. I have since, and understand the initrawq() stuff. It is completely unecessary in 2.9 which has the same tty-i/o as 4.2. So unless someone else is looking at the problem I will convert the 2.9 version to use 4.2 style i/o (FION etc.). This still may require a change to the makefile (which I had no problems with BTW). PS - The proc table is the in-core table of process info, which can be examined in V7 to find out how many characters are in the input queue (yuck). [Ed. - I guess this means we'll soon have a BSD29 conditional, which takes the BSD4 path for tty i/o and the V7 path for everything else.] ------------------------------ Date: 17 MAY 85 09:40-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: Minor Kermit-11 Update On The Way A minor update of Kermit-11 will be sent to Columbia on 20-May. It fixes a problem in requesting 8bit quoting with parity, minor TSX+ problems again (fixes thanks from Ned Rhodes), and a couple of new SET options to control file creation superceding and determination of 'binary' files. As soon as I put P/OS back on my pro and test it this weekend I will send it along. This is the version that will be on all the SIG tapes at spring Decus. Meanwhile, updates can be obtained as described earlier from my 11/785 via either UOFT01 KERMSRV (bitnet) or the dialup procedure stated last week. brian nelson ------------------------------ Date: Fri, 17 May 85 11:13:11 EDT From: poole@NUSC-ADA Subject: Printing Kermit Docs on Xerox 2700? Does anyone know of or have public domain fonts for the XEROX 2700II laser printer? The Kermit docs don't format properly with a 10 cpi font, which is all we have. We will be ordering more fonts form XEROX, but the internal paperwork takes a couple of months. Thanks for your time, Ken Poole 401-841-2648. [Ed. - Maybe this question should be sent to Laser-Lovers. I thought that the Scribe device drivers provided by Unilogic for any particular device supported the minimal font set for that device and did not require you to have any special fonts. If the Kermit docs don't format properly with the fonts you have, maybe your Scribe database is messed up -- wrong width information, for instance. By the way, at Columbia we print our Kermit manuals and other Scribe MSS files on the Xerox 9700 in Univers10 font, on the Imagen LBP-10 with CMR10, and on various less interesting devices -- lineprinters, Diablos, plain text for online doc files, etc -- with very little trouble. Of course, the fancier the device -- and the Scribe support for it -- the better the results. This brings up a related question: why do we use Scribe, rather than, say, a public-domain formatter like TeX? The reason is simply that TeX can not produce plain text doc files for online reading or for printing on ordinary terminals and printers. Scribe is widely available (implementations exist on DEC-10/20's, VAXes (UNIX and VMS), IBM mainframes, etc), and Scribe-like formatters are also included with various microcomputer word processing systems like Final Word, Perfect Writer, etc.] ------------------------------ Date: 17-MAY-1985 14:58 EST From: WILLIAMS3@IU-BACS.MAILNET Subject: KERMIT for BBS's? Has anyone implemented KERMIT in an electronic BBS ? We would be interested in obtaining a copy. Here at IUPUI we have an BBS that is written in BASIC, and runs on an IBM PC-XT and uses XMODEM. Since we are giving KERMIT programs away free we feel it would be nice if our BBS also allowed file transfers using KERMIT. Jim Griffin Microcomputer Systems Group IUPUI 799 W. Michigan ET-1023 Indianapolis, IN 46202 Incidently, we use KERMIT on all our mainframes and are very pleased with its operation. [Ed. - The only one I know about is FIDO, which supports Kermit, Modem7, Xmodem, and some other protocols, and provides electronic mail via FIDONET, using dialup between nodes at prescheduled times. FIDONET mainly runs on MS-DOS systems (like the DEC Rainbow, the IBM PC family, etc). The FIDO-related files are available on ARPANET from SIMTEL20 via anonymous FTP from the directory MICRO:; if you don't have FTP access to ARPANET, I can't say how to get them, but you can mail to Douglas Good or Scott Aschcraft, CMP.DOUG@UTEXAS-20.ARPA (FIDO SYSOPs) for more information.] ------------------------------ End of Info-Kermit Digest ************************* ------- 27-May-85 19:35:57-EDT,27690;000000000001 Mail-From: SY.FDC created at 27-May-85 19:35:29 Date: Mon 27 May 85 19:35:29-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #30 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 27 May 1985 Volume 2 : Number 30 Departments: C-KERMIT VERSION 4C - More Changes to C-Kermit Version 4C File Sizes Reported by C-Kermit C-Kermit v4 to Apollo C-Kermit 4C Comments/Bugs C-Kermit on TRS-Xenix Kermit 4C Broken "Dial" Command for PC/IX 1.1 C-Kermit 4C (16 May) Local-Remote Bug? Status of 4C on 2.9bsd Wart Mods C-Kermit for Eunice MISCELLANY - Lisp Machine KERMIT Kermit-11 BITnet Distribution: Correction IBM PC/AT Serial Port Compatibility AT Serial Port Compatibility IBM Asynch Adapter at 19.2Kb and Beyond Appeal to the Netherlands Kermit for IAS? IAS AND KERMIT Need Help with Kermit-TSO and 7171 Converting New VM/CMS Kermit to MVS/TSO? Kermit for the NorthStar horizon and USR S-100 modem. Formatting documentation for Xerox 2700 Commodore 64 Kermit Diskette Availability Kermit for Wang VS or OIS? Two Faces of Kermit ---------------------------------------------------------------------- Date: Mon 27 May 85 16:41:12-EDT From: Frank da Cruz Subject: More Changes to C-Kermit Version 4C Quite a few minor changes have been made to the working (but not yet really released) copy of version 4C of C-Kermit. The major functional change is that several of the 'set' parameters have been separated into 'set send' and 'set receive' pairs to allow inbound and outbound packet parameters to be set separately. Some changes have been made to the command parsing functions -- the major result is that the multiline local-mode 'get' command now works as advertised, and in addition can be escaped from if you change your mind in the middle of it. Many minor bugs were fixed, some of which are reported in the messages below. Reportedly, problems still exist on ATT System III and System V based systems in the areas of dialing, modem control, and so on. A special "3bx" makefile option was added for ATT 3B-series systems to accommodate their special handling of uucp lock files. Users of these System III/V systems are encouraged to try out the new files and report problems (and fixes?), so we can finally make version 4C "real". The files are on CU20B, in CK*.*, as of 7:30pm EST 27 May 85. Only the Unix and VMS versions have been affected by the recent changes; a new Macintosh release should be ready shortly. ------------------------------ Date: Monday, 20 May 1985 08:26:04-PDT From: d_schullman%sarah.DEC@decwrl.ARPA (Dan Schullman) Subject: File Sizes Reported by C-Kermit When SENDING a file, the displayed size of the file being sent is wrong. It appears that 32kb-->63.99kb, 96kb-->127.99kb, etc. are shown as zero. And that 64kb-->95.99kb, 128kb-->159.99kb, etc. are shown as ( size mod 64kb ). The actual size of the transferred file is fine. [Ed. - The problem is that zchki() returns the size of the file as its value, but zchki() is not declared to be long. Also, it uses a regular int internally to hold the size. The files ckufio.c, ckvfio.c, ckcfns.c, and ckucmd.c have been changed to use longs where necessary, so that file sizes will look right on machines that have short ints.] ------------------------------ Date: Sun, 19 May 85 15:48:00 pdt From: Neal Holtz Subject: C-Kermit v4 to Apollo I finally got around to doing what I said I would in early March - port C-kermit to Apollo (Aegis) environment. I waited for a newer version, 4.2(030). As of this writing, I have only had it running for a few hours, so obviously I have a lot of testing to do yet, but early results are very encouraging. The standard Apollo C-library is very compatible with most Sys III (and some 4.2) -- the only exception is configuring serial lines and the console. I probably could have added about 100 lines to ckxunx.c and ckzunx.c, but I thought they were getting unmanageable with all the IFDEF's, so I made equivalent ckxaeg.x and ckzaeg.c mostly by ripping out most of the compile time control. There were couple of very trivial changes in a couple of other places, but it went very smoothly. When I have had a chance to do more testing, I will forward a few comments. Currently, the TOPS-20 style command parser is being used. That doesn't fit in with the Apollo environment as well as I would like (though it certainly is usable). Haven't decide whether I will retain it. Will probably decide to do whatever causes the least work and disruption (i.e. retain it). Will gladly supply my changes to whoever wants them. [Ed. - The modules other than ckufio (formerly ckzunx) and ckutio (formerly ckxunx) that need modifications to accommodate Apollo Aegis now have them, and the Apollo-specific modules will be announced when they arrive.] ------------------------------ Date: Wed, 22 May 85 09:55:41 -0100 From: hans@oslo-vax (Hans A. ]lien) Subject: C-Kermit 4c Comments/Bugs I had no trouble building v.4c on our vax 11/780 running 4.2bsd unix. However, i have recognized a few problems / minor bugs. I must apologize for not being very familiar with neither unix nor c, so I have no definitive fixes to offer. But anyway: 1) It seems as some terminal output isn't printed to the terminal while the file transfer is proceeding in the background. As a result, the process stops waiting for terminal output. First of all, there are messages of the kind "Warning: ...", which are printed on stderr. I would very much appreciate that such messages be output similarly to messages like "filename => FILENAME ...", WHICH come through nicely. [Ed. - These messages only appear at the start of a transaction, and they are generally important enough that you should want to see them -- like, "Warning, problem getting exclusive access", meaning that somebody else might be using the same communication line at the same time. Once the line is assigned to you, no further warning messages are issued.] The other problem I have noticed, concerns indication of naks. They are indicated by "N", but unlike ".", they demand the process in the foreground to proceed. Once again, I think such output should be allowed to a job in the background. Hopefully, this works OK if -q (quiet) is set, but I haven't tried. [Ed. - I can't reproduce this, nor can I find any code that seems to exhibit this behavior.] 2) I have recognized a minor error in the Tops20-like command parser, which results in repetition of default items by pressing several characters. Try for example CKermit>log trans. [Ed. - It was an error, all right. It's fixed now. Thanks for spotting it.] 3) Regarding command line options, my opinion is that a "bye" option should be included, in addition to, or if the number of options should not grow further, instead of the "finish" (-f) option. I think most people use such an option to end a file transfer session, typically performed with a simple list of commands making up a script. Does anyone (dis)agree? [Ed. - The major restriction on the number of command line options is that the command line help message should fit on one screen.] hans@oslo-vax.arpa Hans A. ]lien, Institutt for informatikk, University Of Oslo, Norway. ------------------------------ Date: Tue, 21 May 85 16:04 MDT From: RMark@DENVER.ARPA Subject: C-Kermit on TRS-Xenix I now have kermit 4C(044) running on TRS-Xenix, a Unix v7 system. Both startup and file transfer are much slower than with kermit version 3. The makefile parameters required are: PROC=_proc DIRECT=-DDIRECT NPROC=_Nproc BOOTFILE=/xenix A fix was required in ckutio.c. Robert Mark, USGS, Menlo Park, CA [Ed. - Fix installed in ckutio.c, and the makefile (ckuker.mak) edited accordingly.] ------------------------------ Date: Tue May 21 1985 14:11:11 From: Marco Papa Subject: Kermit 4C broken "dial" command for PC/IX 1.1 I encountered the following problems with installing and running Kermit 4C for PC/IX 1.1 on a PC/XT with Hayes compatible modem. 1. Makefile problem. PC/IX's "make" does not seem to like \'s to continue lines. Taking out the \'s at the end of lines, and making one long line, fixes it. [Ed. - A warning to this effect has been inserted in the .bwr file, but it's funny we didn't here this one before, especially since a lot of development was done on a PC/IX system.] 2. Dial feature broken. The "dial" command does not work any more. Executing the following set of commands: > set line /dev/tty1 > set speed 1200 > set modem-dialer hayes > dial 743-0000 will work up to the setting of the modem type. The dial command ALWAYS returns with the message: "Sorry, can't hang up the line" I have not looked up in ckdial.c yet, but I believe the message comes from there. I know that there is no problem with my modem switch settings, since Kermit 4.2 runs just fine. Also, since dial does not work, I cannot test the script command. [Ed. - This has been fixed. There are still reportedly problems with DTR during dialing on some systems.] 3. Lock file left around. This is related to the "dial" problem above. When dial fails, the "exit" command leaves the lock file around (/etc/locks/tty1 for example), so that one has to manually delete it, before set line will work again. The lock file is correctly deleted on exit, when dial is not executed. Connect, send and receive seem to work just fine. [Ed. - The ttopen() code in ckutio has been reworked to be more careful about leaving lock files around.] Also, ckuus2.c makes the C optimizer run out of space under PC/IX. Marco Papa UUCP: ...!sdcrdcf!uscvax!papa CSNET: papa@usc-cse.csnet ARPA: papa%usc-cse@csnet-relay.arpa ------------------------------ Date: Sat, 25 May 85 11:29:07 pdt From: rag@uw-june.arpa (David Ragozin) Subject: C-Kermit 4C (16 May) local-remote bug? Running C-kermit, 4C (16 May) on 4.2 BSD Unix. Problem: Issue "set file type bin" Then "send file" and on completion do "show para" mode now shows as "local" instead of "remote" Now when I get mode back to remote by "set line", then do a send of a text file, on return the mode is local. Apparantly going into binary file mode flips some flag which controls the mode setting on returns from at least the send type transaction. [Ed. - Oops - this bug was introduced into 4C (the 16 May version) and has just been fixed. It actually had nothing to do with binary mode.] (By the way, I could find no way to "document" this via any of the log functions, since the "session logging" only works for local mode logging while this bug requires that I record what appears on my screen from a remote kermit.) [Ed. - Try "kermit | tee xxx" -- the transcript will go into file xx. Or use script on systems that have it.] ------------------------------ From: Paul Graham Date: 23 May 1985 1218-PDT (Thursday) Subject: Status of 4C on 2.9bsd As I suspected in my heart of hearts the transition from the 7th Ed. is not going to quite as simple as I might have liked. Currently the 2.9 version will not act as server or in the remote mode. Nor will it receive files in the local mode (it will get a file from a server). If anybody has solved all of these problems please let me know. Else sometime next week it should percolate to the top of the stack, and I should have some time for it once again. Please drive carefully. Paul Graham 702/784-6007 University of Nevada Reno UUCP (seismo, ucbvax!menlo70)!unr70!unrvax!pjg ARPA unr70!unrvax!pjg@seismo ------------------------------ Date: Sat, 25 May 85 18:24:36 cdt From: knutson@ut-ngp.ARPA (Jim Knutson) Subject: WART mods The following are a couple of context diffs for getting wart running on an MS-DOS machine with the CI-C86 C compiler. The problems that were fixed had to do with 1) not ignoring trailing text on #else and #endif 2) Stripping comments within quotes and 3) not recognizing \f as a whitespace. [Ed. - diffs omitted, changes installed in ckwart.c.] ------------------------------ Date: Wed, 22 May 85 23:01 EST From: Larry Afrin Subject: C-Kermit for Eunice I don't remember if I explained this in an earlier message, but Eunice 3.2 is a hybrid of 4.1bsd and 4.2bsd (with a touch of Version 7 thrown in, from what I can deduce from how the time-of-day functions work), that runs under VMS. A new version of Eunice, version 4.0, is coming out "VERY soon", sort of in conjunction with the brand new release of VMS 4.1. Eunice 4.0 is reputedly going to be a full 4.2bsd implementation under VMS. Now, seeing as how Kermit 4C can be installed under VMS directly, and seeing as how Eunice 4.0 is supposedly going to be 4.2bsd straight up and down the line, you may want to defer from adding any Eunice-specific support into the next Kermit version, which I understand from you will be version 4C. You may especially want to avoid using *my* mods since they're meant for Kermit 4.2, which I think you've indicated is now obsolete, sort of. -- Larry Afrin Dept. of Computer Science Clemson University lbafrin@clemson if you're on CSNet lbafrin.clemson@csnet-Relay if you're on ARPANet [Ed. - I agree with Larry -- Eunice support is probably not worth including. This is very much the same situation as Amdahl UTS, whose new version is pure system V, and whose old version is some kind of hybrid. If anyone is desparate for Larry's Eunice Kermit, they may want to contact Larry directly.] ------------------------------ Date: Fri, 24 May 85 14:53 CDT From: "Mark L. Ahlstrom" Subject: Lisp Machine KERMIT I now have the Lisp machine Kermit running "pretty well" on Symbolics Lisp machines. I should be shipping it back to George Carrette at LMI in a couple of weeks to have him retest it on LMI Lisp machines and incorporate some recent LMI changes. Hopefully, the first release to Columbia is within a couple months of being "real". By the way, your information should be updated to show that the lmkermit will be written in Zetalisp rather than Common Lisp. The info that it was Common Lisp evidently came from an earlier plan that George Carrette had to develop the code on another machine. --Mark ------------------------------ Date: 21 MAY 85 10:46-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: Kermit-11 BITnet Distribution: Correction I just noticed that I said UOFT01 KERMSRV in my note about getting the new Kermit-11. It should have been UOFT02 KERMSRV. See Kermit Digests numbers 2-21 and 2-26. ------------------------------ Date: 15 May 85 06:52:09 GMT From: Pat Chewning To: Info-IBMPC@USC-ISIB Subject: IBM PC/AT Serial Port Compatibility I am having trouble with my AT receiving serial data at baud rates over 1200. I suspect that it has something to do with the incompatibility of the serial controller used on the AT versus the PC. Here's the set-up: IBM AT AST ADVANTAGE! multifunction board that has the serial port. (Uses 16450 chip?) Kermit Software (Also tried-out a copy of Crosstalk with same results) [Both these software packages were written for PC] Using the same physical RS232 line, I have no problem doing data transfers at 9600 baud using a Compaq [IBM PC Clone]. The problem shows up at baud rates greater than 1200 (although occasionally at 1200 baud as well). The characters are not wrong, but the problem is missing characters. Transmitting characters works fine, its only on receiving that I have a problem. The manual that came with my serial card indicates that some incompatibility exists between the serial controller chip used in the AT and the controller chip used on the PC. It suggests that some software written for the PC may not operate properly on the AT. Does anyone know what those differences are, and in particular, what specific changes need to be made to Kermit [I have a source] so that it will work on the AT? Pat Chewning [Ed. - See below.] ------------------------------ Date: 16 May 1985 10:22:14 PDT Subject: AT Serial Port Compatibility From: Richard Gillmann Sounds like you have the Professional Graphics display. This has the unfortunate effect of interfering with the serial ports at speeds over 1200 baud. ------------------------------ Date: Thu 16 May 85 13:57:53-EDT From: Charlie C Kim Subject: IBM Asynch Adapter at 19.2Kb and Beyond Using an interrupt based system, as has been indicated, it is definitely feasible to run the IBM serial card at speeds greater than 9600 baud. (In fact, you'll probably need an interrupt based system at any speeds above 1200 or so). On an AT, I've been using Kermit, which is interrupt driven for the serial IO, for file transfer to and as a remote terminal for a 4.2 Unix system (Vax 750 with DMF's--the DMF is a serial/parallel board for the VAX which has a maximum speed ot 19.2KB on serial lines) at 19.2KB without any problems. I've also tried it at 56KB between two PC's (one AT, one PC-1) and between a PC-AT and Macintosh without any problems. I've also be able to use the COM_PKG/INT_PKG pair in the IBMPC library to communicate from a PC-AT to the above mentioned VAX at 19.2KB; again without any problems. So, empirical evidence supports the results. As as side note, I should note that I've used communications packages which were incapable (on a PC/XT) of going above 1200 baud without losing characters; I suppose these were not interrupt driven. Charie C. Kim Columbia University Center for Computing Activites ------------------------------ Date: Thu, 23 May 85 14:26:27 BST From: Cjk@ucl-cs.arpa Subject: Appeal to the Netherlands To anyone in Holland (= The Netherlands): Is there anyone in the Netherlands running Kermit who could help me by providing a mainframe Kermit for demonstration purposes? This would be to demonstrate that a micro-Kermit actually works. If so, please mail me soonest as "cjk @ ucl-cs", on either ARPA or JANET. Chris Kennington. ------------------------------ Date: 24 MAY 85 14:50-N From: DEGROOT@HWALHW5 Subject: Kermit for IAS? 1. Some users keep asking for a KERMIT version for the operating system IAS on the PDP11. I understand that IAS is an obsolete operating system. Previous KERMIT-versions for RSX could be generated for IAS. The current versions of PDP11 KERMIT give not any notice of IAS. Is there a KERMIT for IAS? [Ed. - There is some hope that Kermit-11 will be adapted to IAS. There is at least one very large IAS site that has indicated some willingness to do this, but there is no definite commitment or timetable -- see below.] 2. The file CURRENT.DOC indicates version 3(124) for K10-KERMIT. The right version number for the DEC10-KERMIT should be 2(124). [Ed. - Thanks for pointing out the mistake.] Kees de Groot (DEGROOT@HWALHW5) Computer Centre Agricultural University Wageningen The Netherlands ------------------------------ Date: 24 MAY 85 09:30-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: IAS AND KERMIT I just got a call yesterday from the EPA about IAS and Kermit. They have some 30 systems running IAS version 3.1 and have volunteered to port it to IAS. The main problem with IAS is that RMS-11 version 2 is only supported on IAS 3.2, which many sites seem to have decided not to install. I expect that these folks at the EPA will have Kermit-11 running on IAS soon, so I would suggest that others interested in IAS Kermit to wait a couple of weeks until I get more info on the progress. ------------------------------ Date: Fri 17 May 85 19:34:39-PDT From: Wing Lee Subject: Need Help with Kermit-TSO and 7171 I am experiencing a problem with the Series/1 version of TSO-KERMIT. It works fine with the Series/1, but here at USC we are replacing the Series/1 with an IBM 7171. I am having problems trying to upload files through the 7171. I am able to download files just fine, but when I upload, TSO-KERMIT stops at the first bad packet. I used the debug option on TSO-KERMIT and when I looked at the debug file, it shows that TSO-KERMIT stops right after a CHECKSUM error. It appears that TSO-KERMIT is unable to notify the micro KERMIT that it has received a bad packet and have the micro resend it, and since the micro KERMIT hasn't received an acknoledement from TSO-KERMIT telling it to that the last packet was good, a transmission lock up occurs. I've tried everything I can think of to solve this problem, and would appreciate any suggestions you can think of. Thanks Wing Lee University Computing Services University of Southern California [Ed. - This is presumably the Version of TSO Kermit whose genealogy is Columbia VM/CMS Kermit v 1.0 -> U of Chicago MVS/TSO support -> U of Toronto Series/1 support. Anyone else out there using it? Also, see next message.] ------------------------------ Date: Mon 20 May 85 16:26:52-EDT From: Frank da Cruz Subject: Converting New VM/CMS Kermit to MVS/TSO? To: Ron Rusnak Hi Ron -- Do you think anybody at U of Chicago will be working on TSO Kermit any time soon? Ideally, I think it would be good if the new CMS release (2.00, which has server mode, binary file transfer, CRC's, etc) could have TSO support added to it in such a way that either TSO or CMS Kermit could be built from it. I don't know much about IBM assembler, but I would hope that this would be possible using macros or conditional assembly for the system- dependent parts. This would simplify life a lot for both of us, not to mention the hundreds of sites that are running TSO &/or CMS Kermit, allowing each to benefit immediately from improvements in the system-independent areas. What do you think? - Frank [Ed. - I never got a reply to this, but maybe someone else who might be interested in TSO Kermit -- U. of Toronto, maybe? -- would be willing to take on the task.] ------------------------------ Date: Sun 19 May 85 19:49:20-MDT From: Jon Albers Subject: Kermit for the NorthStar horizon and USR S-100 modem. To: northstar-users@SIMTEL20.ARPA, info-cpm@AMSAA.ARPA, info-kermit@CU20B.ARPA I am looking for a version of Kermit that will work on a Northstar horizon with either the second printer port, or better yet, the US Robotics S-100 internal modem. If you have or know of such a beast, or can perhaps give some help with writing the code to make Kermit work with an S-100 modem board, please reply to me at the below addresses: Jon Albers ARPA: JALBERS@SIMTEL20 /..seismo!dolqci!irsdcp!albers UUCP: ---------<...seismo!dolqci!irsdcp!dcp1!albers \..philabs!sbcs!bnl!bnl44!jalbers ------------------------------ Date: Sat 18 May 85 23:01:53-PDT From: Bob Larson Subject: Formatting documentation for Xerox 2700 I had problems formatting the kermit documentation for our xerox 2700 also. The verbatim portions of the manuals have lines to long to print at 10 cpi with the default margins used for the 2700. By making sure that all verbatim areas were printed at 12cpi, and modifying "italics" to do underlining (the only italic font we have is 10cpi) I was able to format the manual so only a few characters where lost. It might work if formatted with a one character left margin. Hope this helps. Bob Larson ------------------------------ Date: Tue, 21 May 85 03:02:17 edt From: Robert Scott Lenoil Subject: Commodore 64 Kermit Diskette Availability Enclosed is the text of my message to USENET, re: my ability to supply Commodore 64 Kermit diskettes this summer. Please update the 00readme.doc file and the information that you give out over the phone to reflect this new status. Note that my work phone number this summer will be (206) 828-8080, effective June 1. Subject: Kermit diskette availability Newsgroups: net.micro.cbm Distribution: net.micro.cbm As you may know, I have been providing copies of Commodore 64 Kermit for $7.00 as a service for those who couldn't otherwise obtain the program. However, I will be leaving shortly for the summer and have decided not to take my Commodore with me. Therefore, I do not anticipate being able to fulfill any orders until my return August 25th. There is always a possibility that I find somebody at work with a 64, so if you do need a diskette, send me netmail, and I'll let you know if I can accommodate you. (Send to this address - my mail will forward). Robert Lenoil lenoil@mit-eddie.uucp lenoil@mit-eddie.arpa lenoil@mit-mc.csnet ------------------------------ Date: Friday, 17 May 1985 14:26-MDT From: ritcv!husky!pma%rochester.uucp@Seismo Subject: Kermit for Wang VS or OIS? Does any one know of a "kermit" for a Wang(tm) VS or OIS system ? Please respond to me by email. Thanks, Philip Abram, Eastman Kodak Co., Rochester, N.Y. PATH: {allegra,seismo}!rochester!ritcv!-------\ >------husky!pma {eagle,astrovax,netword}!sun!sunrise!----/ ------------------------------ From: tektronix!stever@Berkeley Date: Tuesday, 21 May 85 13:01:22 PDT Subject: Two Faces of Kermit Kermit is both a protocol and a communications program. One should not ridicule people for their confusion about this point. All communications programs whether commercial or not should be able to do *raw* (i.e. ASCII) data file transfers using system level commands of the computer they are talking to, as well as supporting one or more file transfer protocals. Kermit should not be an exception. This feature should be a part of the Kermit protocal definition. Kermit implementations should not be included in the distribution system of Kermit software unless they have the *raw* file transfer function. steven d. rogers ...ucbvax!tektronix!stever [Ed. - In principle, I agree. In practice, Kermit programs are donated by individuals who are free to implement whatever features they like, so long as the minimum protocol features are present. We're not going to turn down desparately needed contributions (we know when a Kermit implementation is desparately needed when the number of phone calls asking about it exceeds a hundred per day) because they lack a particular optional feature.] ------------------------------ End of Info-Kermit Digest ************************* ------- 30-May-85 17:29:15-EDT,11900;000000000001 Mail-From: SY.FDC created at 30-May-85 17:28:02 Date: Thu 30 May 85 17:28:02-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #31 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 30 May 1985 Volume 2 : Number 31 Departments: C-KERMIT 4C - C-Kermit Parity More Problems on Kermit 4C? System V C-Kermit 4C Works System V 4C C-Kermit Racal-Vadic Control Fixed! C-kermit on 4.1bsd MISCELLANY - Kermit for Atari ST TRS-80 III Kermit Users Wanted PC/AT Serial Adaptor problems CP4KERMIT on Superbrain ---------------------------------------------------------------------- From: Date: Tue, 28 May 85 22:48:33 PDT Subject: C-Kermit Parity I hope that this is the right place to send this. I am using C-Kermit 4.2, and I noticed that it does not set the parity on the com. line when a set parity even/odd/mark/space command is issued. This is a problem for me because our VAX (System V) defaults differently than the other machines here (iNTEL 310 w/System V, VME/10 w/System V). Thanks, Alan Fargusson. DIGITAL RESEARCH INC. 60 GARDEN COURT BOX DRI MONTEREY, CA. 93942 [Ed. - C-Kermit certainly makes every attempt to transmit the desired parity. The question is whether the System V implementation sets the tty up in an appropriate mode to allow the C-Kermit software to do this. Some changes have been made in this area since release 4.2 -- you may find that release 4C does it right. I hope so.] ------------------------------ Date: Mon May 27 1985 10:57:27 From: Marco Papa Subject: More Problems on Kermit 4C? I am sorry to say, but the problem reported by Yigal Arens on Kermit 4C about timeouts on large files under System V is present also in the Berkeley version. I run the following test: I tried to transfer the new ckuker.mss (34 TOPS-20 Pages) from ECLC (TOPS-20) to uscvax (Berkeley-UNIX 4.2). Everything went well until after about 160-200 dots(.) were on the screen. Then suddenly a sequence of T%T%T%T%T%T%T% started coming. Only way to get out was to abort the batch transfer. The UNIX kermit was saying it had timed out, and the TOPS-20 kermit was back to the KERMIT-20 prompt. I tried this twice with the same result. Both machines were totally unloaded (I was the ONLY user on TOPS-20 and there were 5 other users on the VAX). This seems to be a bug of the new 4C version of Kermit, not present in the preceding 4.2 version (which I used to transfer all 4C files between the above mentioned machines). ------------------------------ Date: Tue 28 May 85 13:19:16-EDT From: Frank da Cruz Subject: Re: More Problems on Kermit 4C? To: papa%usc-cse.csnet@CSNET-RELAY.ARPA Were you running the very latest release, 4C(049), circa 8:00pm EST Monday? I just used it to transfer ckuker.mss from the DEC-20 to a 4.2bsd system and didn't get a single timeout. Then I did it again. Then, just to make sure this wasn't a fluke, I sent my mail.txt file -- 205 DEC-20 pages, or 514453 characters, or 502.4K, or half a megabyte (that's about a week's worth of mail for me). There were 70 jobs on the 2060, the 15 minute load average was about 6.00; there were 8 users on the VAX-11/750, load below 1.0. The two systems are connected by a direct line between the DH11 on the DEC-20 and a DMF32 on the VAX, running at 9600 baud. The transfer took about 38 minutes; there were 6 timeouts -- one burst of three (%T%T%T), one of two, and one single timeout. I don't think a file this big could be transferred if there were some intrinsic flaw in the program. Maybe you're running a slightly older version, and were hit by a bug that has since been fixed. More likely, it's just something in 4.2bsd. We have seen terminals hang quite often on our 4.2bsd systems (the longer the system is up, the more it happens), and recently installed a patch (from Usenix?) to the DMF driver that may have alleviated the situation somewhat. ------------------------------ Date: Mon, 27 May 85 21:46:43 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) Subject: System V C-Kermit 4C Works Good news! The latest version has cleared up the problem with remote commands for System V C-Kermit. I tested them all and they now all work. Unfortunately, the dialer problems are still there for System V and Racal-Vadic modems, but progress is being made! ------------------------------ Date: Tue, 28 May 85 15:49:27 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) To: Info-Kermit@CU20B.ARPA Subject: System V 4C C-Kermit Racal-Vadic Control Fixed! I have found a fix for the System V Racal-Vadic modem problem. The problem was that tthang was dropping DTR for the modem AND LEAVING IT LOW. After I examined the code for ttopen, tthang, and ttpkt, I concluded that if ttopen needed the "close(open( . . ." magic, tthang probably did too. The magic is there, but it is surrounded by "#ifdef PCIX". I removed the "#ifdef PCIX", and the problem went away! [Ed. - Good news! Change installed.] By the way, while playing with C-Kermit 4C, I noticed that the bsd version is compiled without optimization. I tried compiling it with optimization, and it seems to work well, while generating a somewhat smaller executible file. Why no "-O" for bsd? [Ed. - You're free to add -O if you want; I'd rather distribute without it so there's one less thing to blame when things break.] ------------------------------ Date: Tue, 28 May 85 10:06:38 PDT From: Dave Flamm Subject: C-kermit on 4.1bsd The latest version of C-kermit still won't "make" successfully on our 4.1 bsd. It still looks for "time.h" without success. It would seem that whatever means is used for detecting 4.1 versus 4.2 is not foolproof? > I think I see the problem. It's in ckutio.c... all the nested #ifndefs > around "#include " need an additional #ifndef BSD41...#endif. > Try that and let me know if everything else is ok for 4.1bsd. Thanks! (later...) That seems to have done it. Thank you. Dave [Ed. - It looks now as if 4C pretty much works as advertised on all systems except 2.9bsd. The next issue of Info-Kermit will announce it "for real".] ------------------------------ Date: Tue 28 May 85 13:52:27-EDT From: Frank da Cruz Subject: Kermit for Atari ST To: Info-Kermit@CU20B.ARPA I got a call from someone in Canada who said that Atari is distributing what appears to be the old Unix Kermit (command line operation only) in the developer kit for the new ST computer system, source not included. The caller wanted to know why it wouldn't transfer binary files in "image mode" -- it seems it stops sending as soon as it hits a control-Z in the file. Sounds like the file system must be in the CP/M style. It's nice that Atari is promulgating Kermit, but if they also included the source then maybe some of their developers could fix the bugs, or even adapt the new C-Kermit... ------------------------------ Date: Tue 28 May 85 13:55:52-EDT From: Frank da Cruz Subject: TRS-80 III Kermit Users Wanted John A Ball of the Northeast Radio Observatory Corporation, Haystack Observatory, Westford MA 01866, 617-692-4764, would like to make contact with users of TRS-80 Model III TRSDOS Kermit. ------------------------------ Date: Tue, 28 May 85 09:35:36 PDT From: Bruce_A._Cowan%SFUG-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: INFO-IBMPC@USC-ISIB.ARPA, Info-Kermit@CU20B.ARPA Subject: PC/AT Serial Adaptor problems There is a lot of misinformation going around about the serial ports on a PC/AT and their compatibility with the PC. The 16450 chip (and 8250A chip from National Semiconductor) has quite a few bug fixes compared to the 8250 and 8250B. One of those bug fixes breaks many interrupt-driven PC communications programs. The typical result is missing characters at speeds of 1200 bps and above. Now, the bug is that the 8250 pulses (low) its interrupt line when the condition causing the interrupt is satisified even if there is another interrupt condition pending. NatSemi thought that action was incorrect so they fixed it in the 8250A and 16450 - for those chips the interrupt line will stay high until ALL pending enabled interrupts are satisfied. The problem this causes with PC communications programs is that many of them assume the interrupt handler will get entered for every interrupt individually. This happened because the pulsing interrupt line would make the PC's 8259 interrupt controller think there was a new interrupt pending, so it would present it to the CPU chip immediately upon receiving the EOI (end of interrupt) for the previous interrupt. With the interrupt line not pulsing on the new chips, the 8259 doesn't think there is a new interrupt pending even though the 16450's interrupt line remains high. That is because the 8259 is in edge-triggered mode. Now, the solution is to poll either the 8250 status register or the interrupt identification register before exiting from the interrupt handler. For instance, the following logic works for the receiver data ready interrupt: Interrupt handler: save whatever is necessary while status register says data ready process data whend send EOI to 8259 restore whatever was saved exit You might now be saying "But I only enable received data interrupts so there can never be more than one interrupt pending at a time so I don't need to worry about this." Well, I thought so too, but the situation is that if the next received character is ready to be transferred to the receiver buffer register by the time the CPU reads the receiver buffer register, then the receiver data ready interrupt will remain pending. Hence you need logic like the above. (I've tried this and it does solve the problem.) There are other bug fixes in the 8250A/16450 which can cause troubles, but they are much more obscure and much less likely. They have to do with transmitter interrupts but I can't recall the details right now and I don't have my copy of the NatSemi errata sheet handy to refer to. I hope this helps all you people out there. For those who seem to think all these problems are caused by the IBM Professional Graphics Controller, please note that while it may cause some, it is not the ONLY cause, as should be evident from the above description. ------------------------------ Date: 29 May 1985 08:03:15 IST (GMT+2) To: SY.FDC@CU20B.CCNET From: PHR00JG@TECHNION.BITNET Subject: CP4KERMIT on Superbrain Hello Frank ! I was delighted with Version 4 which together with Version 2 under CMS makes the use of KERMIT even more efficient than it was before. Also I was very happy to find a version tuned to my Lobo MAX-80, although I had been happy before with the CPM-Plus version. The availability of server mode is great, and I take this occasion to thank you again. The version running on Superbrain does not generate a break. I did not look into the source code to see why, but I thought that the following listing of a tiny dumb terminal program I have written here may help clear out the problem, IF there is a problem (perhaps I missed something). Regards \ Jacques [Ed. - Jacques' code forwarded to Charles Carvalho for inclusion in the next release of CP/M-80 Kermit. No estimate when it will appear.] ------------------------------ End of Info-Kermit Digest ************************* ------- 30-May-85 19:29:35-EDT,5278;000000000001 Mail-From: SY.FDC created at 30-May-85 19:29:10 Date: Thu 30 May 85 19:29:10-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #32 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 30 May 1985 Volume 2 : Number 32 C-Kermit Version 4C for Unix, VMS, and the Macintosh ---------------------------------------------------------------------- This is to announce version 4C of C-Kermit for Unix, the Apple Macintosh, and VAX/VMS. C-Kermit is a version of Kermit written modularly in C, implementing the entire Kermit file transfer protocol (except for attribute packets), designed for modularity and transportability. This version of Kermit has been in "field test" for about a month, and is being released at this time because most of the major goals for it have been met, namely: . Most known bugs in release 4.2 fixed . Support for new systems added and tested . A few new functions incorporated At this point, C-Kermit should be considered a fairly stable base upon which to add support for new systems -- the interface between the system-dependent and portable modules seems to have settled down -- and to add new features. A few highlights: Systems Supported: . Berkeley Unix 4.1 and 4.2 (but not yet 2.9) . AT&T Unix System III and derivatives (Xenix/286, PC/IX, etc) . AT&T Unix System V and derivatives . Bell Unix Version 7 . DEC Pro-350 with Venix Version 1 . NCR Tower 1632, OS 1.02 . VAX/VMS . Apple Macintosh New features since version 4.2, common to all implementations: . Many features redesigned to promote portability. . Compile-time options to eliminate debugging and logging code to reduce size and boost performance. . Packet parameters separately settable for inbound & outbound packets. . Protocol operation improved here & there, many bugs fixed. New features for Unix implementation (and VMS): . Command line continuation . Support for additional modem-dialers . Improved performance for Pro/Venix . Better (but still not perfect) determination of local vs remote mode in 'set line' . User's preferred shell is used for "!" commands, rather than always sh. (A complete list of Unix/VMS updates is in CKUKER.UPD.) New Features (since 0.7) for Macintosh: . A key redefinition package is now provided. . I/O errors, such as disk full or write protected, now handled better. . Separate boxes for inbound & outbound packet parameters in protocol settings dialog. (A complete list of Macintosh updates is in CKMKER.UPD.) The Macintosh implementation is built using the Stanford University Medical Center's SUMACC cross development system, which runs on VAX computers under Unix (or VMS with Eunice). MacKermit fits on a standard 128K Mac, but just barely. The key configurator is a separate program, because this additional functionality added to Kermit itself would not fit into a 128K Mac. The memory restriction is a problem only because the SUMACC system cannot produce swappable segments. If someone wants to take the trouble to translate the Macintosh-specific modules to one of the native Macintosh C development systems that supports segment loading, then additional functionality can be added without worrying about exceeding memory. (If you want to volunteer to do this, please contact us first!) The VAX/VMS implementation is more an exercise in portability than a real Kermit implementation. It mostly works, but does not possess the intimate knowledge of the VMS environment that the Stevens Institute of Technology Bliss language implementation has. Still, it may be useful to sites that do not have a Bliss compiler but do have the VAX-11 C compiler. Documentation includes a Unix Kermit manual (CKUKER.DOC, Scribe source CKUKER.MSS), a Macintosh Kermit manual (CKMKER.DOC,.MSS), various help files (CK*.HLP), program update histories (CK*.UPD), and "beware" files (CK*.BWR). The Unix and Macintosh manuals are new chapters for the Kermit User Guide, but the Guide itself has not yet been reissued to include these chapters; a new revision of the manual will appear after MS-DOS Kermit 2.28 is announced. The files are in KER:CK*.*, available from host CU20B via anonymous FTP on the Internet. Within a few days, they will also be available from BITnet via KERMSRV at CUVMA. In addition, Macintosh Kermit diskettes will be sent out to selected sites (Apple University Consortium schools and a few others; our capacity to reproduce diskettes is limited, so we can't do mass mailings). And of course, the new files will be included henceforth on our Kermit distribution tapes. The files that had been in for testing purposes have been removed. Thanks to all the folks on the network who participated in the test and helped to work out the bugs, particularly Dave Tweten (AMES-NAS), Marco Papa (USC), Dan Schullman (DEC), Lawrence Afrin (Clemson U), and many others too numerous to mention. Please report any problems to Info-Kermit@CU20B. ------------------------------ End of Info-Kermit Digest ************************* ------- 7-Jun-85 15:42:40-EDT,17134;000000000001 Mail-From: SY.FDC created at 7-Jun-85 15:41:57 Date: Fri 7 Jun 85 15:41:57-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #33 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B 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 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 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 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) 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 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 . Otherwise the filenames prefixed with "" 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: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 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 /* 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 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 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 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 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 .... [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 ************************* ------- 10-Jun-85 17:31:47-EDT,4162;000000000001 Mail-From: SY.FDC created at 10-Jun-85 17:31:21 Date: Mon 10 Jun 85 17:31:21-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #34 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 10 Jun 1985 Volume 2 : Number 34 MS-DOS Kermit Version 2.28 Now Available Need Pointer to Victor 9000 Kermit Disk Kermit-MS under Topview? ---------------------------------------------------------------------- Date: Mon 10 Jun 85 17:22:15-EDT From: Frank da Cruz Subject: MS-DOS Kermit Version 2.28 Now Available To: Info-Kermit@CU20B, Info-IBMPC@USC-ISIB This is to announce Version 2.28 of MS-DOS Kermit. MS-DOS Kermit provides terminal emulation and Kermit protocol file transfer for the following systems: . IBM PC, PC/XT, PC/AT and compatibles . IBM PCjr (RS232 port only) . DEC Rainbow Series . Hewlett-Packard 150 . Hewlett-Packard 110 . NEC APC . Sanyo MBC . Texas Instruments Professional . Wang PC . Heath/Zenith 100 . Generic MS-DOS The program has been tested at Columbia on the IBM PC, XT, and AT, the DEC Rainbow, and the HP-150. Since the system-dependent modules were not noticably altered, it is expected that it will work on the other systems too -- but confirmation (to Info-Kermit@CU20B) would be appreciated. The changes are in several major areas: 1. Bug fixes (many) 2. Size -- new version is much smaller on disk, at the cost of DOS 1.x support. 3. New commands - CWD, TYPE, VERSION 4. Better unique-filename manufacturing algorithm. 5. Additional Heath-19 terminal emulation features and controls. The files are in KER:MS*.* on CU20B, available to Internet via anonymous FTP: KER:MS228.UPD -- List of specific changes from 2.27 to 2.28 KER:MSAAAA.HLP -- List of all the MS*.* files, with brief explanations KER:MS*.BOO -- .BOO-format programs for downloading (see documentation) KER:MSKERM.DOC -- New Kermit User Guide manual chapter for V2.28 KER:MSKERM.BWR -- "Beware File" (list of known bugs & limitations) KB:MS*.EXE -- 8-bit binary format Kermit programs for the various systems The files will also appear at the other Kermit distribution points within a week or two (BITnet KERMSRV, okstate, etc) and will be submitted to PC SIG for the benefit of those who want to order MS-DOS Kermit on floppy disk. ------------------------------ Date: Sun, 9 Jun 85 14:25:52 cdt From: ihnp4!shell!buck%Berkeley@columbia.arpa (Lester Buck) Subject: Need Pointer to Victor 9000 Kermit Disk Could you direct me to a source for a version of kermit that runs on a Victor 9000 that is actually on a Victor 9000 format disk? I would gladly pay some $$$ to anyone and I am not in a terrific hurry (next three or four weeks). I would like to avoid downloading the versions I have on the distribution tapes. I note that the Victor versions have changed around alot from the distribution tape last August to the tape this March - no more vic*.* files for msdos, but a bunch of new ones called sir*.* which I guess are identical (?). Thanks for any pointers, A. Lester Buck @ Shell Development Co. {ihnp4, pur-ee, ut-sally}!shell!buck [Ed. - There were actually several different Victor/Sirius Kermit implementations, based on various releases of Version 1.x IBM PC Kermit. We're only distributing the latest one. Can anyone help him out?] ------------------------------ Date: Mon 10 Jun 85 13:28:03-PDT From: Jim Celoni S.J. Subject: Kermit-MS under Topview? What are the correct program parameters to give Topview so that Kermit-MS 2.27 runs best under it? Is there a .pif file for Kermit? If Kermit can transfer files in the background and not mess up the screen, that would be great... Thanks. +j [Ed. - Has anybody really gone through the bother of doing this? If you have, please feel free to contribute your work to Info-Kermit!] ------------------------------ End of Info-Kermit Digest ************************* ------- 14-Jun-85 20:00:33-EDT,11944;000000000001 Mail-From: SY.FDC created at 14-Jun-85 20:00:11 Date: Fri 14 Jun 85 20:00:11-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #35 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 14 Jun 1985 Volume 2 : Number 35 Known Bugs in MS-Kermit 2.28 Fixes to C-Kermit 4C Available for Unix, VMS, and Macintosh Why is C-Kermit So Slow? Kermit for Fortune 32/16? ---------------------------------------------------------------------- Date: Fri 14 Jun 85 18:30:52-EDT Subject: Known Bugs in MS-Kermit 2.28 To: Info-Kermit@CU20B.ARPA There are two major problems with MS-Kermit version 2.28: 1. When doing a GET command, incoming filenames are randomly truncated. 2. On the IBM PC family only, when escaping back from a terminal connection, the system hangs. We have a fix for problem 1 -- it's just a coding error (thanks to Dave Tweten at NASA for pointing out the error and the fix). Problem 2 is more serious: it comes from the use of incompatible assemblers and linkers. The program depends upon its segments being in a certain order, and it instructs the linker to put them in that order using the MSDMB and MSFINAL dummy modules. However, it seems that certain assemblers defeat this technique. A method is needed for insuring that the segments are in the desired order, no matter what assembler and linker are used. While this problem is being worked on, it should be noted that a version of the program that does not have this bug is available in the .EXE and .BOO files we distribute, which were built with an assembler/linker combination that ordered the segments as desired. A new release fixing problems 1 and 2 should appear within a few days. Meanwhile, here's Dave's prescription: Change 1 -- (original msfile.asm) jne gofil4 ; No - get the filename. ; this bogusity copies the filename from the fcb into the data (modified msfile.asm) jne gofi4a ; No - get the filename. ; this bogusity copies the filename from the fcb into the data Change 2 -- (original msfile.asm) cmp flags.destflg,0 ; writing to printer? jne gofil5 ; no, go on (modified msfile.asm) gofi4a: cmp flags.destflg,0 ; writing to printer? jne gofil5 ; no, go on ------------------------------ Date: Fri 14 Jun 85 19:35:21-EDT Subject: Fixes to C-Kermit 4C available for Unix, VMS, and Macintosh To: Info-Kermit@CU20B.ARPA The many messages reporting bugs in and/or suggesting fixes for Unix Kermit 4C(050) will not be reproduced here. Thanks to all those who sent them in, particularly (in no special order) Bradley Smith at UCLA, Jim Bernard at U of Delware, Kelvin Nilsen at U of Arizona, Larry Afrin at Clemson U, Dan Schullman at DEC, Randy Huntziger at NLM, Frank Prindle at NADC, Martin Minow at DEC, Marco Papa at USC, Jim Knutson at U Texas, Chris Maio at Columbia CS, Robert Mark at USGS, Neal Holtz at UBC(?), David Ragozin at U of Washington, Dave Tweten of NASA, and (of course) Herm Fischer (I think that's all of them; apologies to anyone I missed). If you think this list is long, you should see the messages themselves... It should be apparent that this program has not settled down as much as was hoped, and still further releases may appear over the summer. So if anyone was thinking of posting it to net.sources... please don't! C-KERMIT FOR UNIX, CHANGES FROM 4C(050) TO 4C(052), 14 JUNE 85: . Fixed 8th-bit prefixing negotiation; sometimes C-Kermit would agree to do it and then not really do it (applies also to Macintosh Kermit). . Added minimal 2.9bsd support (further improvements solicited!). . Trap and ignore QUIT signal, trap SIGHUP and handle like SIGINT. This prevents lock files from being left behind after hangup or quit. . Ignore SIGQUIT and SIGINT signals while inferior shell active -- let inferior shell handle them. . Allowed "-a name" to work when sending from stdin. . Change hlptxt[] to contain less than 256 characters (for Xenix) . Fixed bugs in determination of remote vs local mode. . When stdin redirected, and remote/local status cannot be definitely determined, assume local rather than remote so that local-mode commands can still be used. . Fixed bug that was making 16-bit machines erroneously report files not found. . Change makefile symbol 3BX to ATT3BX (has to start with letter) . Remove line continuations in the middle of strings in makefile. . Fixed a couple errors in the Tower OS 1.02 support. . Fixed a minor problem in V7 support. . Got rid of the (void) casts in strxxx() invocations. . For Sys III/V, open terminal in 7-bit, parity-enabled mode rather than 8-bit, no-parity mode (some sites actually use parity). . Change message "status report..." to "status report:" to avoid dot confusion. . Replace Herm Fischer's ckudia.c with Dan Schullman's reworking of it, which features support for more modems (in particular, the DEC DFxxx modems) and more structured organization of the modem info, so support for new modems can be added by making relatively straightforward table entries. . Script command now accepts scripts that were continued on the command line using \ (as advertised). . Fixed minor syntactic problems in ckvtio.c for VAX/VMS. The files are in KER:CK*.* on CU20B, available via anonymous FTP. Also included is a new release of Macintosh Kermit, described briefly below. Thanks to Doug Brutlag at SUMEX and Mike Meyer at U of Wisconsin for pointing out the problems, and in some cases offering fixes, and of course to Bill Schilit, now of Columbia CS, for doing the work: C-KERMIT FOR MACINTOSH, CHANGES FROM 0.8(28) TO 0.8(31), 14 JUNE 85: . Built with new protocol modules from C-Kermit to fix 8th-bit-prefixing negotiation. . Added dragging and selecting of main window, for better coexistence with desk accessories. . Fixed COMMAND-SHIFT-1..COMMAND-SHIFT-9 problem. Since these keys are special (they eject the diskettes, dump screens to files/printer, etc) they were being ignored. This caused things like Control-@ and Control-^ to be ignored also. Add a new item to the SETTINGS menu that allows you to enable or disable this action. The default is disabled. . Fixed some default keymap definitions: Control-Y and Control-T were mapped incorrectly. Control-' was mapped incorrectly. Functions were defined for VT52 instead of VT100 keypad: Changed "?" to "O" in function definition strings. . Errors during and/or after CKMKEY save, decompile now handled better. WARNING: A serious bug exists in Macintosh Kermit (this new release as well as previous ones) which should be fixed in a forthcoming release (soon, I hope): parity operations simply do not work correctly. Example: when parity is set to "mark", Macintosh Kermit will discard any incoming underscore characters; this prevents the Mac from receiving a file that requires more than 63 packets, or from sending one that requires more than 33, assuming said files contain no underscores (if they do, the hangup may occur sooner). The problems fixed above were distracting enough to warrant early fixing, but those who can live with them for another week or two are encouraged to wait until an announcement can be made that the parity problem is fixed. ------------------------------ Date: Tue, 11 Jun 85 21:09:08 edt From: xp!tony@nyu-cmcl2 (Tony Movshon) Subject: Why is C-Kermit So Slow? I've just been timing my backup from the Rainbow to the VAX (lightly loaded). It's on a 9600-baud line, but is only transferring characters at about 140/sec. By my lights, that's 14.5% efficient. Where'd the other 85.5% go? I realize that the Kermit protocol expands the bytecount by about 25%, but where's the rest of the time going? Specifics: to VAX 11/750, 2 MB memory, RA81 disk, 4.2BSD, no fancy floating-point hardware, DMF32 port (DMA). Load average about 1.7, 3-5 users. C-Kermit 4C (049), file type binary, no parity. from Rainbow 100A, 512k memory, RD51 10 MB Winchester. MS-Kermit 2.28. I haven't timed it, but transfers seem to go considerably faster to my 11/24 running TSX-Plus using Kermit-11 V2.29. Yours in puzzlement ... Tony ------------------------------ Date: Wed 12 Jun 85 10:08:00-EDT From: Frank da Cruz Subject: Re: Why is C-Kermit so slow? You have exactly the same setup as I do, except my VAX has more memory. I've seen the speed vary a lot, and can't always explain it. In some cases, it's appropriate to point the finger at 4.2bsd. Sometimes, the longer our system is up, the slower it gets. Also, there are bugs in the DMF drivers that need fixing (fixes are available from Usenix if you don't have them). Also, sometimes the system will get VERY slow if one of the idle tty lines is being blasted by noise -- that seems to happen to us a lot. The reason I mention these items is that my measurements are a lot different from yours -- using 4.2bsd Kermit 4C(050) on a VAX-11/750 with load around 1.00 (with no special line discipline, see below) against the Rainbow 100B running Kermit-MS 2.28, transferring a 11372 character file with few repeated characters (so as not to deceptively boost throughput because of run-encoding compression), I get: Unix to PC: 28 seconds, or 406.0 cps (42% efficiency) PC to Unix: 42 seconds, or 277.4 cps (29% efficiency) These figures are not great, but they're better than your 140 cps by a good bit. Beyond the possible problems mentioned above, there's one inherent design problem in BSD and probably most other Unixes as well -- the line is open in raw mode for file transfer, but raw mode also turns on cbreak mode, which is very expensive (more so when receiving data packets than when sending them). BSD provides an alternate line discipline called "Berknet", which would have been a LOT better for Kermit except that (a) it strips the 8th bit of incoming characters, preventing efficient transfer of binary files, and (b) it's hardwired to use LF as its only break character, whereas all the Kermit programs in the world use CR. At Columbia, we fooled with modifying the Berknet discipine to not strip the 8th bit, to be double-buffered, and to allow specification of the break character; you can see some code in ckutio.c under the KERLD conditional that evokes this line discipline. We found the result was a Kermit that indeed ran a lot faster, but unfortunately we can't really distribute the kernel modifications because we're too busy sending ordinary Kermit shipments to get into the "send me your ATT and Berkeley source licenses and we'll send you the code" business. Short of fooling with the kernel, you should be able to speed C-Kermit up perceptibly by recompiling with DEBUG not defined, to eliminate the many calls to DEBUG that occur during normal operation, even when debugging information is not being logged (and if you want to see sloooow, try transferring files with debug logging turned on!). - Frank ------------------------------ Date: Thu, 13 Jun 85 09:22 MDT From: "Kevin W. Laurent" Subject: Kermit for Fortune 32/16? We have a user with a Fortune 32/16 running FORPRO (similar to UNIX version 7) who wants to use Kermit. Unfortunately, he doesn't have a C compiler. Do you have a contact running Kermit on a Fortune? Thanks. - Kevin Laurent ------------------------------ End of Info-Kermit Digest ************************* ------- 21-Jun-85 20:17:55-EDT,9177;000000000001 Mail-From: SY.FDC created at 21-Jun-85 20:17:23 Date: Fri 21 Jun 85 20:17:23-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #36 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 21 Jun 1985 Volume 2 : Number 36 Departments: ANNOUNCEMENTS - Another New C-Kermit for Unix (4C(53)) and Macintosh (0.8(32)) New FTP server up on CU20B: CWD fixed Okstate Dialup Repaired C-KERMIT - C-Kermit Very Slow on TRS-Xenix C-Kermit Runs on Heurikon Mini-Box Mapping Keys in Mac Kermit MS-DOS KERMIT - Generic MS-DOS Kermit Runs on the DG/1 Kermit-MS under Topview ---------------------------------------------------------------------- Date: Fri 21 Jun 85 20:00:27-EDT From: Frank da Cruz Subject: Another New C-Kermit for Unix (4C(53)) and Macintosh (0.8(32)) To: Info-Kermit@CU20B.ARPA C-Kermit 4C(053) fixes a major problem for both Unix and the Macintosh: it now does parity right. There were two areas in which problems showed up: 1. Macintosh Kermit could not transfer files using mark or space parity. Furthermore, when using any kind of parity other than none, occasional incoming characters would be lost during terminal emulation. This was because Mac Kermit was letting the serial i/o chip handle parity, and the chip is simply not flexible enough to be relied upon. 2. Unix Kermit could not transmit odd parity correctly. If you "set parity odd", it was equivalent to "set parity mark". The Unix Kermit software parity generation function dopar() was fixed to generate all kinds of parity correctly. Then Macintosh Kermit was changed to use dopar() rather than its chip to generate parity. Several other minor changes were made to Unix Kermit, in particular in the determination of whether it is in local or remote mode. The changes are detailed in KER:CKUKER.UPD and KER:CKMKER.UPD; known bugs are listed in KER:CKUKER.BWR and KER:CKMKER.BWR (U for Unix, M for Macintosh). The complete collection of C-Kermit files for Unix, VMS, and the Macintosh are in KER:CK*.*. These files are all accessible via anonymous Internet FTP from host CU20B. A message about CU20B's FTP server follows. Also, the file KER:AANETW.HLP has been updated to provide more complete information on access to CU20B's Kermit distribution area. ------------------------------ Date: Thu 20 Jun 85 23:39:51-EDT From: Ken Rossman Subject: New FTP server up on CU20B: CWD fixed To: Info-Kermit@CU20B.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 CU20B is now running a new version of the CMU TOPS-20 FTP server. The major enhancement which will be important to most users is one which (indirectly) makes multiple file transfers easier in some cases. One problem (particularly with originating Unix systems) was that an mget would return a list of files with fully qualified TOPS-20 pathname prefixes, which in turn would be the way those files were created on disk (i.e. the Unix filenames would contain the entire TOPS-20 path prefix). While this is merely annoying on Berkeley 4.2 systems, this is a real problem with 4.1 systems (and perhaps others), which have shorter file names and can lose some of the name information. Due to the new enhancements to the FTP server, a CWD command may now be issued to connect the user to the desired Kermit directory (with or without a password), so that the file list that FTP retrieves for a multiple file transfer will not contain the entire directory path (just the filenames). If no password is supplied at the time the CWD command is issued, no "owner access" is granted to the target directory, and files are only accessible according to their individual file protections (in the case of the Kermit directories, this translates to read-only access). If a password is supplied, full owner access is granted to the target directory. Many thanks to Vince Fuller of CMU for the new FTP server. /Ken ------------------------------ To: info-kermit@CU20B.ARPA Subject: Okstate Dialup Repaired Date: 11 Jun 85 18:14:52 CDT (Tue) From: Mark Vasoll Some of you have been reporting problems with the dialup access that we provide to the Kermit Distribution. The problem has been traced to a flakey modem and the offending unit has been replaced with a new unit. Please continue to direct problem reports and suggestions to one of the "uucp-support" addresses. UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!uucp-support ARPA: uucp-support%okstate.csnet@csnet-relay.arpa Mark Vasoll Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll ARPA: vasoll%okstate.csnet@csnet-relay.arpa ------------------------------ Date: Mon, 17 Jun 85 09:38 MDT From: RMark@DENVER.ARPA Subject: C-Kermit very slow on TRS-Xenix To: Info-Kermit@CU20B.ARPA I just installed 4C(052) on TRS-XENIX and timed a file transfer to a very lightly loaded VAX/VMS. With a 4800 baud connection, the transfer averaged 13 chars/sec. [Ed. -- Wow, does everybody else with TRS-Xenix have the same performance?] ------------------------------ Date: 18 Jun 85 08:28:10 PDT (Tuesday) From: Cherry.Pasa@Xerox.ARPA Subject: C-Kermit Runs on Heurikon Mini-Box To: Info-Kermit@CU20B.ARPA C-Kermit has been sucessfully installed on two Heurikon Mini-Boxes. (68010, Unisoft System V 5B 4/85; HK68 CPU - 10 MHz) only two minor problem areas: 1. Tabs were converted to spaces at some point along the transfer route. 2. the " \ " characters had to be removed in the initial Make line. Recommendation: Since there are so many entries for a "3" type installation, change the name of sys3 to sys5. I found that some non-unix types had trouble with this as they have System 5 Unix and all through the documentation Unix V is the more common term used. Note: Time to complete the make process 27 minutes. Thanks to all for a fine job on the software. ------------------------------ Date: Thu, 20 Jun 85 11:22:09 EDT From: Greg Lauer Subject: Mapping Keys in Mac Kermit To: info-kermit@cu20b.arpa I used the kermit key map program to put control characters on the Option key and meta characters on the Command key. The problem is that Option-e,i,u,n still act like option keys: they "expect" another character. Thus to send a control-n requires typing option-n option-n. Otherwise, this seems like a great program. Greg [Ed. - The lowercase vowels "aeiou" are treated specially in the translation routine /usr/mac/ws/local/init0. init0 is also the routine which was doing the shift-clover-1..9 stuff. Mac Kermit currently has a command for disabling the shift-clover-1..9 keys, but adding one for the option-vowels would be a lot harder. For now, this goes into the .BWR file.] ------------------------------ Date: Wed 12 Jun 85 14:08:13-CDT From: Aaron Temin Subject: Generic MS-DOS Kermit Runs on the DG/1 To: info-kermit@CU20B.ARPA We have a copy of MSGENE.EXE running on our Data General/One. File transfers work fine at 1200 baud through an external modem. Internal modem doesn't seen to respond, and screen emulation, even with the vt100 ansi.sys installed, doesn't seem to work. But this is entirely satisfactory until someone can modify Kermit appropriately for the beast. Hope this is helpful. Thanks. Aaron Temin ------------------------------ From: Jim Gillogly Date: 12 Jun 85 14:38:00 PDT (Wed) Subject: Re: Kermit-MS under Topview? Yes, MS-Kermit v. 2.27 will run under Topview. I haven't bothered with a .PIF file, but it works fine in the background. For 2.27 on the IBM PC I used 96K for the min memory, 96K for max, and 7K for system. I left the interrupts at 00-FF, although I'm sure they don't all need to be swapped (if any) ... keep it simple. Use "n" for "program writes to screen", since writing to the screen and running in the background are linked. The disadvantage of telling it "n" is that it intercepts everything, giving you a "galumphing" scroll. However, "n" is necessary for background, and if you're transferring long files it's worth it. I used 2.27 in background mode to pull Webster's 2nd over while doing a half-day's worth of real work on my PC in the foreground. I normally don't use Topview because it's not compatible with the Tall Tree RAMdisk ... and since I have 2.5 meg of RAMdisk, that's a big loss. It also works with MS-Kermit v.2.28, which needs only 85K for min/max size. Jim Gillogly (jim@rand-unix) [Ed. - Thanks for the information. Since 2.28 does dynamic memory allocation, it will probably have to be defined differently to TopView.] ------------------------------ End of Info-Kermit Digest ************************* ------- 24-Jun-85 18:19:09-EDT,5902;000000000001 Mail-From: SY.FDC created at 24-Jun-85 18:18:37 Date: Mon 24 Jun 85 18:18:37-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #37 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 24 Jun 1985 Volume 2 : Number 37 Commodore-64 Kermit V1.6 MS-Kermit Support Module for ACT Apricot Kermit for the Acorn BBC Micro New Release of Sperry 1100 Kermit Kermit for ND Series Minicomputers Another Kermit Implementation for the ICL/Perq New HP-3000 SPL Kermit ---------------------------------------------------------------------- Date: 8 Jun 85 17:59:50 EDT From: Eric Subject: Commodore-64 Kermit V1.6 Is ready for distribution. There are a few minor annoyances, like the disk command parsing routine not working entirely correctly and the timeout implementation is far from complete (though it can timeout), and not handling the lack of an init file on the disk elegantly. The documentation describes all the features of this new Kermit, I'm sure people will find it a major improvement over previous versions. All known bugs in the communications routines have been fixed and eight-bit-quoting works. ARPA: LAVITSKY@RUTGERS UUCP: ...{harvard,seismo,ut-sally,sri-iu,ihnp4!packard}!topaz!eric SNAIL: CPO 2765, CN 700 New Brunswick, NJ 08903 [Ed. - The new files are in KER:C64KER.* on CU20B, available via anonymous FTP, as are all the other new files announced below.] ------------------------------ Date: Mon 24 Jun 85 17:05:20-EDT From: Frank da Cruz Subject: MS-Kermit Support Module for ACT Apricot The file KER:MSXAPR.ASM contains the system-dependent functions for the ACT Apricot, suitable for inclusion in MS-DOS Kermit 2.27 or later. It comes from Ralph Mitchell, Computer Centre, Brunel University, Uxbridge UK. There is no documentation to speak of, so nothing can be said at this point about its capabilities (maximum baud rate, screen scroll, printer control, key redefinition, etc). Reviews, contributions of documentation (or a .BOO file) welcome. Note that there was already a version of the old IBM PC Kermit version 1.20 that was modified for the Apricot at the Rijksuniversiteit Groningen, which has been available as KER:APRICOT.* since November 1984. If anyone knows any reason why this new version should not replace the old one, please speak up. Thanks to Alan Phillips of Lancaster University for sending it on tape. ------------------------------ Date: Mon 24 Jun 85 17:15:47-EDT From: Frank da Cruz Subject: Kermit for the Acorn BBC Micro This is to announce the initial release (version 0.53) of Kermit for the Acorn BBC micro under the operating system OS1.20, by Alan Phillips, Department of Computing, Lancaster University, UK. The source, in 6502 assembler, is in KER:BBC*.ADE, and a binary dump of the compiled code is in KER:BBC053.ROM. KER:BBCBUILD.HLP describes how to construct a BBC Kermit, and KER:BBCKERMIT.BWR lists known problems with this release. A printable form of the user guide is in BBCKERMIT.DOC. Inside the UK, this program will be available on diskette and via the UK university network from Lancaster University. ------------------------------ Date: Mon 24 Jun 85 18:05:55-EDT From: Frank da Cruz Subject: New Release of Sperry 1100 Kermit Version 2.2 of Sperry (Univac) 1100 Kermit (the assembler version, not the Pascal or the Ratfor version) has been sent in by the author, Paul Stevens of the University of Wisconsin. Version 2.2 includes 8th-bit and repeat-count prefixing, server operation, and supports wildcards in filenames (server and wildcard code mostly from Grant Gilmour of Guld Canada Resources Inc). The program is in KER:UNIVAC.ASM on CU20B. ------------------------------ Date: Mon 24 Jun 85 17:21:39-EDT From: Frank da Cruz Subject: Kermit for ND Series Minicomputers Announcing the initial release of Kermit-ND (version 3.1b) for the Norwegian ND family of minicomputers (ND-10/100/500), by H. Eidnes and A. Lie, Norwegian Institute of Technology and others, written in ND Pascal version J / MAC. The files are in KER:ND*.* on CU20B. ------------------------------ Date: Mon 24 Jun 85 17:28:55-EDT From: Frank da Cruz Subject: Another Kermit Implementation for the ICL/Perq Here is a second Kermit program for the ICL/Three Rivers Perq workstation. This one is by A. Lie, formerly of the Norwegian Institute of Technology, written in POS Pascal for POS version D6/R2. Like the other Pascal-based Perq Kermit (from Peter Thew in Australia), it has a pop-up menu user interface. This new version of Perq Kermit is in KER:PQ2*.* on CU20B (the old one is in KER:PQK*.*). Unbiased comparisons by Perq users of the two programs would be welcome, so that the less favored one can be retired to make space. Thanks to Frithjov Iversen of the Computing Centre at the University of Trondheim for sending this to us on tape. ------------------------------ Date: Tue, 4 Jun 85 08:29:49 edt From: Steve Archer Subject: New HP-3000 SPL Kermit Here is a new version of HP-3000 Kermit in SPL, version 1.1, to replace version 1.0 originally from Ed Eldridge, Polaris Inc. (POLARIS@USC-ISI). It adds the capability to show parameters, changes the "serve" command to "server". Help messages have been added, and some short-form commands. Also added parity, a FINISH command, and a very primitive connect mode. steve archer ------------------------------ End of Info-Kermit Digest ************************* ------- 26-Jun-85 19:42:39-EDT,14990;000000000000 Mail-From: SY.FDC created at 26-Jun-85 19:42:11 Date: Wed 26 Jun 85 19:42:11-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #38 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Wed, 26 Jun 1985 Volume 2 : Number 38 C-Kermit Issue: C-Kermit 4C for Amdahl UTS 2.4 C-Kermit 4C for Fortune 16:32 Fixes to C-kermit for the Valid Scaldstar System C-Kermit on Whitechapel MG-1 with Genix 1.3 Unix-Like Systems Supported by C-Kermit Transporting C-Kermit to Eurosys-16 with Os9 Dialing from C-Kermit on a 3B2? C-Kermit 4x vs Line Locking, etc ---------------------------------------------------------------------- Date: Thu 20 Jun 85 02:23:04-PDT From: Jean-Pierre Dumas Subject: C-Kermit 4C for Amdahl UTS 2.4 We have compiled Kermit 4.2 on UTS 2.4. It works very well (with "make v7"; we use a dummy function that always return 0 for initrawq in ckutio.c ) [Ed. - Thanks for the news! I've added a comment to this effect to the makefile.] ------------------------------ Date: Wed 26 Jun 85 04:32:52-PDT From: Jean-Pierre Dumas Subject: C-Kermit 4C for Fortune 16:32 Frank, I insert ckuker.mak ckufio.c ckutio.c as modified for the fortune 16:32 by Gerard Gaye. [Ed. - The Fortune support has been fitted into KER:CKUKER.MAK, KER:CKUTIO.C, and KER:CKUTIO.C. It's mostly the same as 4.1bsd.] As we are connected through an x25 network it should be possible to safely by-pass some packet assembly/deassembly/coding... of kermit and rely on the x25 pad to do the work...anybody working on that ??? [Ed. - The Kermit protocol is not layered well enough to do things like this.] Jean-Pierre Dumas ------------------------------ Date: Thu, 20 Jun 85 17:32:51 pdt From: psivax!woof (Hal Schloss) To: ttidca!randvax!sy.fdc@cu20b.ARPA Subject: Fixes to Ckermit for the Valid Scaldstar System We have a VAX 11/750 running BSD 4.2 that we talk to with Intel MDS's and VALID Scaldstars. We use the VAX to develop code that we download to the MDS's and to provide remote services for the Scaldstars. In the course of getting these to work I had to make changes to existing kermits to allow communication to C-kermit on the VAX. For the VALID systems I had to change all references to the variable cc in the file ckucmd.c. These were changed to ccx, the problem is that cc is an internal variable for the VALID's assembler which blows up in an ugly fashion if you declare a second time. I also had to replace a reference to FREAD in ckutio.c as the VALID does not have this in it's include files. I hope this works, it seems to so far. To compile for the VALID include the changes listed in diff -c format below (using patch?) and make bsd. [Ed. - diffs omitted.] By the way, I have implemented a remote line printer server for the VALID on our vax, but I have to run kermit at 300 baud as the VALID has problems above that speed. I don't know why though. Hal Schloss (from the Software Lounge at) Pacesetter Systems Inc. {trwrb|allegra|burdvax|cbosgd|hplabs|ihnp4|sdcsvax|aero|uscvax|ucla-cs| bmcg|sdccsu3|csun|orstcs|akgua|randvax}!sdcrdcf!psivax!woof or {ttdica|quad1|scgvaxd|nrcvax|bellcore|logico}!psivax!woof ARPA: ttidca!psivax!woof@rand-unix.arpa [Ed. - This can be handled by adding an entry like this to the makefile: #Valid Scaldstar valid: make wermit "CFLAGS= -DBSD4 -Dcc=ccx -DFREAD=1" I've added this to KER:CKUKER.MAK. At some later time, perhaps some of the commonly-objected to variables, like "cc" and "data" can be renamed.] ------------------------------ Date: Fri, 21 Jun 85 18:33:06 BST From: Ljwu@ucl-cs.arpa Subject: C-Kermit on Whitechapel MG-1 with Genix 1.3 I have managed to compile and run C-Kermit 4C(050) on a Whitechapel MG-1 workstation (See Byte magazine from first quarter '85). This machine is basically a Unix engine running Genix-1.3 which is essentially a bsd 4.1 system. Only hitches were: 1) single call to getppid in ckufio.c was hardwired to 0 due to lack of this system call in Genix. [Ed. - Sounds a lot like the Fortune support mentioned above.] 2) wart compiles fine but refuses to process ckcpro.w stating that one of the defined dynamic states is undefined. Older version of wart from c-kermit 4.2 also gives a similar error but a couple of states later. Lex also wouldn't process it. I suspect that it is an obscure bug in my operating system. I haven't had the time or energy to chase it down. Instead I worked around the problem by using the distributed ckcpro.c. I haven't the foggiest idea of what is wrong since wart seemed happy on a vax running bsd 4.2 and previous versions (4.2) of wart and ckprot.w worked fine. Thus far, I have done only basic send/receive functions on the Whitechapel using only text files. Everything for the present seems to be in order. THanks for kermit! Les J. Wu [Ed. - I've added Les's hints to the makefile comments section.] ------------------------------ Date: Wed 26 Jun 85 17:45:38-EDT From: Frank da Cruz Subject: Unix-Like Systems Supported by C-Kermit To: Info-Kermit@CU20B.ARPA The following list shows all the systems that C-Kermit has been reported to work on (the Fortune, Valid, and Whitechapel changes announced above are confined to the files KER:CKUKER.MAK (makefile), KER:CKUTIO.C, and KER:CKUFIO.C). I'd appreciate hearing from anyone who has it working on any systems not listed here, so that I can add their machines and operating systems to the list: Machine Operating System Machine Operating System AT&T 3B Series Unix Sys V IBM PC/AT Xenix/286 Cadmus 68000 Unix Sys V IBM 370 Series VM/UTS 2.4 CallanUnistar300 Unix Sys V IBM 370 Series VM/UTS v5 Codata Unix V7 NCR Tower OS 1.02 DEC VAX Ultrix-32 NCR Tower Unix Sys V DEC VAX, ... Unix 4xBSD PerkinElmer 3200 Unix V7 DEC PDP-11 Unix 2xBSD Pyramid 90x Unix 4xBSD DEC PDP-11, ... Unix V7 Masscomp RTU 2.2 DEC Pro-3xx Venix V1 Motorola 4 Phase Unix Sys V DEC Pro-3xx Venix V2 Plexus P60 Unix Sys V Fortune 16:32 For:Pro1.7 SUN Unix 4xBSD HP-9836 S/200 HP-UX 200B TRS-80 Model 16 Xenix HP-9000 S/500 HP-UX 3.25 Valid Scaldstar Unix 4xBSD IBM PC/XT PC/IX Whitechapel MG-1 Genix 1.3 Also, if anyone can claim that the current version does NOT work on any of these systems, I'd also like to find out about that. Thanks! - Frank ------------------------------ Date: Fri, 14 Jun 85 13:20:15 -0300 From: mcvax!hut!kla@seismo.ARPA (Kimmo Laaksonen, Helsinki U of Technology) Subject: Transporting C-Kermit to Eurosys-16 with Os9 Hi, I'm forwarding the following mail (excerpt of) for your info: Date: 14 Jun 1985 1006 From: SAHKOL.TAKALA To: LK.LAAKSONEN We are planning to transfer CKERMIT into a system called EUROSYS-16. The operating system is OS9/68000. The C-compiler we have running is done by Microware. The version of CKERMIT we have got is 4.2(030). Petri Alhola, Lauri Aarnio Robcon OY Hankasuontie 9 P. O. Box 9 SF - 00391 HELSINKI Finland Juha Takala Helsinki University of Technology Power Systems Engineerin Laboratory Otakaari 5 SF - 02150 ESPOO Finland Electronic mail can be routed to the implementors through me. Kimmo Laaksonen, mcvax!hut!kla@seismo.arpa. [Ed. - Bob Larson, BLARSON%ECLD@USC-ECLA, is coordinating an effort to bring up C-Kermit under Os9 on a variety of systems. Maybe these two groups can make contact, especially since Bob has access to the up-to-date C-Kermit sources.] ------------------------------ Date: Wed, 26 Jun 85 11:50:42 EDT From: Dr. Joseph M. Leonard To: info-kermit@cu20b Subject: Dialing from C-Kermit on a 3B2? This, hopefully, will be an easy one. I have C-Kermit going on our 3B2, but cannot get the dialer feature to work. The "set modem racal" seems to work (with the addition of an extra \r), but the "instant" that dialer tries to do its stuff, DTR is dropped by the 3B2. What I need is anybody who has set up the /etc/inittab file to do this. OR, if somebody using SysV.2.2 has used racal modems to dial out, please let me know what I've missed... Joe Leonard [Ed. - Has anyone done this? If not, a new dialer module is expected soon that might help in this area.] ------------------------------ Date: Tue, 28 May 85 11:53:40 pdt From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa (Ken Poulton) Subject: C-Kermit 4x vs Line Locking, etc Questions: 1) How does kermit do uucp line locking on 4.2 systems that (I understand) generally have /usr/spool/uucp owned by uucp and protected as 755 ? Our system manager suggests that we should make kermit setuid uucp; is this commonly done? 2) Some of my uses of Kermit (a spooled print server, for instance) require that one script do the login, the next does a transfer, more transfers occur if they are queued, and then a script logs out. Obviously, there needs to be a way to leave the line locked and open *between* Kermit invocations. I have addressed this with an eXIT command, (like berkeley mail) which exits the program without unlocking the line or dropping DTR. To make this work, I changed look4lk to swallow an existing lock file if the user is the owner. (This, however, provides no protection if kermit is setuid! This may require some id inside the lock file.) [Ed. - This is probably a good idea, provided Kermit not setuid'd. If I were a Unix system manager, I'd think twice about making a program as big and complex as C-Kermit setuid'd anyway.] To alleviate the problem of users leaving the line locked, I print a warning message and create a script in the user's home dir ("UNLOCKtty04") which can delete the lock and drop the line. To avoid confusion, I have disabled the 'exit' command. [Ed. - Well... Not to rehash all the old arguments, but there's simply NO GOOD WAY to handle this situation over the entire family of Unixes. Unix stupidly lets anyone assign an appropriately protected tty, regardless of whether someone else may also have it assigned. Reasonable multiuser operating systems allow access to devices like terminals and tape drives to one job or process at a time, since there's no practical way that serial devices such as these can be shared. Many operating systems even have a tough time letting users share disk files! Anyway, because Unix blithely grants a tty device to as many users who ask for it, the whole business of "line locking" came about. Whoever it was that invented uucp decided for the rest of us how lines should be locked: by writing a file into a particular directory like /usr/spool/uucp or /etc/locks. This requires that the user's process must have write access to that directory. This is accomplished by (a) protecting the directory so that the public can write into it (which opens the door to potential security problems); (b) protecting the directory so that members of certain groups can write into it (which requires the system manager to keep track of who's in what group); (c) setting the process's user id to a privileged id or one that has owner access to the lock directory (more security loopholes). All of these approaches require some action of the system manager in order to install a program that wants to create locks, meaning that such a program is not user installable, at least not unless condition (a) already prevails. If one wants to find out who is currently using a device, option (c) is not viable, since the user's name will not appear as the creator of the lock file. Assuming that all this can be set up, there still remain ___ major problems with line locking: 1. Programs will always appear that do not honor the locking conventions, defeating the entire purpose of the locking mechanism by simply ignoring it. 2. Programs that do honor the locking convention will occasionally leave lock files behind (because the process was killed, the system crashed, or the program itself crashed), preventing other users from using the device even when it is free. The trade-off, then, is whether it is better to err on the side of security or on the side of letting users get their work done. C-Kermit, in its present form, makes various compromises. If read or write access to the lock directory is denied, the program issues a warning but allows the user to proceed. If a lock file exists for the specified device, the user is not allowed to proceed, but is given an "ls -l" listing of the lock file to show the file's creator and creation time. Since C-Kermit does not allow access to a locked line, it is very careful to get rid of lock files whenever it exits, whether because a command-line invocation was completed, an "exit" command was given, or an interrupt or quit signal was raised. If users are given the ability to exit Kermit without releasing the line or closing the lock file, many lock files will be left behind. This is especially likely because the intention of this feature is to facilitate running Kermit from unattended scripts.] The other problem is that on Bell systems, we have no job control (sigh). This means that we can't put a long transfer into the background after it starts. The eXIT command allows you to be using Kermit CONNECT for doing work, eXIT and do a transfer in the background, and re-CONNECT when the transfer is done. Perhaps Kermit should support background transfers directly... [Ed. - I can see that the proposed eXIT command has its uses, but it really supposes a friendly environment where everyone knows everyone else and can chase them down when they leave a lock file behind. But what happens when you have Unix running on some huge timesharing system like a VAX 8600 or an IBM 3081 with 5000 users, and they're all leaving lock files behind, perhaps even on purpose (maybe they're premed students...)?] ------------------------------ End of Info-Kermit Digest ************************* ------- 27-Jun-85 18:39:37-EDT,23374;000000000000 Mail-From: SY.FDC created at 27-Jun-85 18:39:12 Date: Thu 27 Jun 85 18:39:12-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #39 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 27 Jun 1985 Volume 2 : Number 39 Departments: ANNOUNCEMENTS - BITNET KERMSRV Reorganized IBM VM/CMS Kermit in Pascal MISCELLANY - MS-Kermit 2.28 H-19 Emulation for IBM Kermit Talk at National Prime Users Group Kermit-TSO and the IBM 7171 Front End About Commodore 64 Kermit V1.6 Apple II Kermit Status C-Kermit Line Locking Problems, Cont'd C-Kermit Problems: HP-9000, Racal-Vadic Modems, etc ---------------------------------------------------------------------- Date: Thu 27 Jun 85 13:50:57-EDT From: Frank da Cruz Subject: BITNET KERMSRV Reorganized BITNET users who get files from the Kermit file server, KERMSRV at CUVMA, will notice that the BITNET Kermit distribution area has been split in two in the same way as the CU20B area, as described in Info-Kermit V2 #33. Those who may have missed the announcement are encouraged to read the file KER:AAAUPD.HLP on CU20B (AAAUPD HLP on KERMSRV) to see what was done. In particular, it should be noted that all the "bureaucratic" files (like lists of versions, flyers, order forms, etc) have all been renamed to have names starting with AA. ------------------------------ Date: Fri, 7 Jun 85 16:47 EDT From: VIC@QUCDN.BITNET Subject: IBM VM/CMS Kermit in Pascal I have just sent you an updated version of my Pascalvs version of KERMIT-CMS. This version eliminates the use of the LINEMODE call and thus can be run as a self-contained module and should work with any other Kermit without modification. There is a quick comparison of the Assembler and Pascal version below. COMPARING ASSEMBLER AND PASCALVS KERMIT FEATURES. CMS Kermit Capabilities : ASSEMBLER PASCALVS Local operation: No Yes Remote operation: Yes Yes Transfers text files: Yes Yes Transfers binary files: Yes Yes Wildcard send: Yes Yes ^X/^Y interruption: Yes Yes Filename collision avoidance: Yes No Can time out: No No 8th-bit prefixing: Yes Yes Repeat count prefixing: Yes Receiving only Alternate block checks: Yes Yes Terminal emulation: No No Communication settings: No No Transmit BREAK: No No Transaction logging: Yes No Session logging: No No Raw transmit: No Yes Act as server: Yes Yes Talk to server: No Yes Advanced server functions: No Yes **** Advanced commands for servers: No No Local file management: Yes Yes Handle Attribute Packets: No No Command/init files: Yes No Command macros: No No **** Advanced server commands DIR,ERASE,and TYPE have been implemented. All of the advance server functions will respond if only to tell you it has not been implemented. [Ed. - The files are in KER:CM2*.* on CU20B available via anonymous FTP and as CM2* * via BITNET KERMSRV.] ------------------------------ Date: Wed, 19 Jun 85 17:36:58 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) To: Info-Kermit@CU20B Subject: MS-Kermit 2.28 H-19 Emulation for IBM MS-Kermit 2.28 msyibm.asm seems to have a bug, and what I interpret as two "misfeatures". The bug is that a line-wrap which requires a scroll-up does not produce the scroll. As a result, the wrapped portion of the line overwrites the first part for as many wrappings as are required. I observed this by running "vi" on our 4.2 bsd system, using MS-Kermit 2.28 in H-19 emulation mode. I viewed a file with long lines. Line-wrap in the middle of the screen worked properly. So did scroll-down (backward) through multi-line lines. However, when I had "vi" scroll-up (forward) through the file, each multi-line line that entered at the bottom of the screen overwrote itself. When I used ^L to tell vi to repaint the screen, overwritten lines were displayed correctly. When I repeated the test, using MS-Kermit 2.27, everything worked correctly. I haven't yet had time to find the source of the problem. The first of the "misfeatures" is the addition of line-wrapping backspace. My copy of the H-19 Operation Manual says clearly (on page 12) that backspace: Moves the cursor one space to the left. If the cursor is at the start (left end) of a line, it will not move when you type a BACK SPACE. I believe that if Kermit is going to be advertized as emulating an H-19, it ought to do so. I don't think this is a very serious deviation, though, because I can't imagine a program sending a useless backspace, confident that the H-19 will ignore it. Still, why introduce incompatibilities? The other "misfeature", though, is serious. H-19s will work in either native or ANSI mode. Almost all of Kermit's escape sequences are from the native set. Kermit's new "Enhanced Character Support" sequence (ESC [ p1 ; . . . ; pn m) is the sole exception, being an extension of one from the ANSI set. Unfortunately, it conflicts with the native set "ESC [" sequence (Enter Hold Screen Mode), which is not implemented in Kermit. Both sequences are correctly interpreted by a real H-19 because it has two more sequences which are not implemented in Kermit, "Enter ANSI Mode" (ESC <), "Enter ZDS Mode" (ESC [ ? 2 h). To implement "Enhanced Character Support" correctly, without stumbling over "Enter Hold Screen Mode", the sequence should be honored only in ANSI mode. That would require it to become "ESC < ESC [ p1 ; . . . ; pn m ESC [ ? 2 h". I don't think the sequence is worth it without a general implementation of ANSI mode. One very good reason for Kermit to emulate an H-19 is that many systems believe they already know about H-19s. If this advantage is not to be lost, Kermit must stay as close to the H-19 as possible. ------------------------------ Date: Thu 20 Jun 85 13:50:57-EDT From: Frank da Cruz Subject: Re: MS-Kermit 2.28 H-19 Emulation for IBM One of our problems is that we don't have a real H19, and the H19 manual that we once had has disappeared (anybody want to donate one to the cause?). Our PC's get used a lot as terminals to our IBM mainframes, and it is common on those machines to display files that contain lines a full 80 characters long, with a CRLF at the end. If you don't suppress LF after autowrap, then these come out looking double spaced. We made the change mainly to make our IBM mainframe users happy. Since this is inconsistent enough with the H19 definition to break "vi", we'll have to back out of this change; the next release (2.28a, which contains fixes to the most glaring problems with 2.28, namely the "get" filename truncation and the segment reordering) will have this feature put back the way it was -- should be ready within a week or so. Having backspace wrap to the previous line was a suggestion from Greg Small at Berkeley; I don't remember his motivation (Greg?). Aside from the the fact that this deviates from the H19 definition, can you think of any functional reason not to do it? We thought about the ANSI mode business a bit before we put it in. It was added because we needed the different kinds of highlighting for use with 3270 protocol converters (front ends for our IBM mainframes). We noticed that there was a potential conflict between native ESC [ and the ANSI lead-in sequence. But, we reasoned, since we don't support native ESC [ (can you think of any software that would send a hold screen command?), and since we ignore unknown escape sequences (like Enter and Exit ANSI mode), and since we're not trying emulate an ANSI terminal in all its glory, we figured that no harm would be done. If some software wants to use the character highlighting and does that by sending "ESC < ESC [ p1 ; ... ; pn m ESC [ ? 2 h" then it will work just fine. It will also work if they just send ESC [ p1;...;pn m by itself. If they really want to send a hold screen command, it will have no effect (unless, I guess, the following characters can be interpreted as p1;...pn m). But then, will any software that exists ever actually send a hold screen command? You'd think that if the software did not want additional characters to be displayed on the screen, it would simply not send them, but perhaps I'm naive... I realize these are touchy issues, but in my view the H19 emulator in Kermit is just a stopgap. Soon, we expect to have a fully functional ANSI (VT102) emulator available in the form of a loadable console driver, separate from Kermit but distributed with it on the same terms. At that point, I think the H19 code will become superfluous and will eventually wither away. - Frank ------------------------------ Date: Sat 22 Jun 85 04:00:45-PDT From: Bob Larson Subject: Kermit Talk at National Prime Users Group To: info-kermit@CU20B A talk was given at the National Prime Users Group (NPUG) in Saint Louis this week entitled "Kermit on the Prime: One shop's experience" by Harvey J. Friedman of the International Pacific Halibut Commission. The bug in Prime Kermit discussed in the talk was configuration dependant, it only affects systems with printing characters for erase and or kill. (It is also documented at Columbia in a .bwr file, but that file is not in the distribution from Pulse (Prime users library...)) Apparently there is a need to cooridante the Pulse distribution with the Columbia distribution. I have heard that there is a new version on Pulse that supports assigned lines. Bob Larson [Ed. - Prime Kermit has always been one of the most difficult to manage. Another problem has been that Prime computers can't read any of the tape formats in which we distribute Kermit, including ANSI labeled ASCII (the standard format for information interchange agreed upon by all major manufacturers). Finally, in desparation, people in Prime's New York office wrote a short Fortran program to read ANSI tapes, and we have to include a copy of it on paper every time we send a tape to a Prime site. Even if Prime refuses to support industry standard tape formats, you'd think the user group (Pulse?) could solve problems like this.] ------------------------------ Date: Wed 25 Jun 85 11:51:32-EDT From: Wing Lee Subject: Kermit-TSO and the IBM 7171 Front End To: Sy.Daphne@CU20B.ARPA I have the TSOS1.ASM file and it works fine with the Series/1. But when we replaced the S/1 with an IBM 7171, we started having problems. The problem was that when you were uploading to the TSO host, the file transfer would be hung at random places. When I used the debug option, on TSO kermit, I found that the transfer would stop right after the first CHECKSUM error. Downloading works fine, and KERMIT is able to handle CHECKSUM errors just fine, but when uploading, it just stops. I was wondering if anyone else was experiencing problems similar to my, and if so, if anyone was going to add support for the 7171 in the next release of KERMIT-TSO. wing ------------------------------ Date: Wed 26 Jun 85 11:51:32-EDT From: Daphne Tzoar Subject: Re: Kermit-TSO and the IBM 7171 Front End To: WingLee%ECLD@USC-ECL.ARPA It sounds like the problem you are having should be a protocol issue and shouldn't be related to whether you are using a S/1, 7171 or 4994. I'm not sure why a bad checksum should affect the upload to TSO and not the download from it. But, I will forward your message to Info-Kermit and the author of the S/1 TSO Kermit. /daphne [Ed. - To the best of our knowledge, the new VM/CMS Kermit works equally well through straight ASCII async tty connections through 3705 and equivalent front ends, through the Series/1 (4994?) front end doing 3270 protocol conversion, and likewise the 7171 front end. We hope that someone at a TSO site will find a way to convert VM/CMS Kermit to TSO in such a way that it can be built for either VM/CMS or MVS/TSO, either by conditional assembly or by moving system-dependent primitives to a special module, like C-Kermit or MS-DOS Kermit. Then, whenever the program gets fixed or improved, everyone will benefit at once.] ------------------------------ Date: 26 Jun 85 19:08:07 EDT From: Eric Subject: About Commodore 64 Kermit V1.6 I neglected to include a suitable .INI file in the kermit distribution, which is losing since it really needs an init file right now to startup in a sane manner. You can instruct people with older versions of kermit to download this file as an ascii seven-bit file before starting up the new Kermit. [Ed. - This file is now in KER:C64KER.INI on CU20B. It contains a strange looking sequence of control characters -- don't be alarmed when you see them.] By the way I thought I'd take this opportunity to address some of the questions you've been sending my way lately (I've been really busy with a new job and all): Using C64 Kermit with a tape drive: Very simply put, you can't. That is not without adding to the program and not without huge delays in transmission. The C64 operating system uses the same memory locations for the RS232 routines and the tape drive timing (both of which are critical). I do *not* plan on adding any support whatsoever for the tape drive. Using Kermit with the C128 (no one's asked yet, but just in case): It should be easy to use Kermit in C64 mode on the C128. There *should* also be no problem with using it in 128 mode, but it would make more sense to use the native screen mode for 80 columns. Since I don't have a 128 (and don't plan on getting one), I cannot evaluate what is necessary to take advantage of this. Anyone else who is interested in doing this should feel free to give it a crack. The C128 should work nicer in native mode due to the faster disk drive. On the other hand, you may just want to use CP/M Kermit on it. Eric ------------------------------ Date: Thu 27 Jun 85 00:20:45-EDT From: Peter G. Trei Subject: Apple II Kermit Status >Date: Mon, 24 Jun 85 14:09 MDT >From: "Mike Armstrong {mba}" >Subject: Apple 2 kermit >Would you please tell me the current status of the Apple 6505 version of >kermit. The latest version I have is V2.1 (V2.1A??) updated 30-JUL-84 >by Peter Trei (original by A.N.J. Moine) Version 2.1a is still the latest released version. Development has is currently rather slow: both Anton's and my real-world workload have substantially increased in the past year, and I have been able to do rather little for 4-5 months, and Anton none. (I am still distributing several copies a week by mail). If you feel like contributing code, my only request is that you inform me and Anton about it before you start, to advoid duplication of effort. Outstanding desired features and bugfixes include: [Ed. - Anton indicates that he is out of the Apple II Kermit business now and Peter should be regarded as the sole proprieter.] 1: On Apple 2c's, the cursor produces a bogus character when placed over a lowercase alpha character. (Its ok after you move again). 2: Command files, so you can set up and dial your kermit more easily. 3: Support for the Videx and Apple 2c/e 80-column cards. (This is more easily said than done. If you want to know why, ask me.) 4: Support for more varieties of serial interface (my current project). 5: A better bootstrapping procedure. 6: Server capability (a real toughie, since most apples have no clock). 7: VT102 emulation. 8: ProDos kermit. I am currently awaiting the arrival of my order for a 'native code, optimising, ProDos Pascal compiler'. 6502 assembler can be macho, but its also a pain in the b*tt. If you feel like taking any of these on, please tell me about it. I have a number of ideas (and some code) for most of them. Everything being equal, I expect to have a release out late summer/early fall with at least 3 and 4 fixed, more if possible. >I am looking for a version that, in addition to the capability of V2.1, >also handles the 80 col screen card and has the "insert-line", >"delete-line", "delete-chars" and the "insert-chars"/"end-insert-chars" >capability in the terminal emulation (for use with Multics full screen >editing and menu features). Kermit65 acting as a server would also be >very nice. However I don't have access to a Dec Tops/20 system to run >the CROSS assembler so I cannot modify the source. (And I'm not >convinced of my capability of doing it properly anyway.) This is the VT102 emulation I mentioned earlier. I agree, it would be nice, and I would like to include (I use Emacs too). >Mike Armstrong - Honeywell, Canada (from University of Calgary's Multics > system). Peter Trei oc.trei@cu20b h: 212-5692371 w: 212-8153711 ------------------------------ Date: Wed, 26 Jun 85 20:52:43 pdt From: Scott Weikart Subject: C-Kermit Line Locking Problems, Cont'd Instead of setuid, I think it would be much better to operate setgid. Then the ownership of the lock file would be intact. I put uucp, cu, kermit, etc in a group called dialer, for such situations. But then you have to convince your administrator to allow /usr/spool/uucp to be writable by group (in my opinion, this is much safer than making kermit setuid, especially if you keep regular users out of the group). This has one annoying side-effect; kermit will no longer be able to create a file in a directory that's not writable by the user but is writable by the group that the user's shell is in [this is fixable for system 3 and 5 - i'll send the code along - but not in v7 or BSD]. Another thought; if you did something like the above which would allow the user to own the lock file (or if you write the uid into the lock file), then maybe you could do the following to do a multi-stage kermit. start up a kermit, connect, pop back to kermit and fork a sub-shell, then allow the user to start up another kermit as long as she owns the lock file. I think this will work, even though the original kermit still has the tty open. The user would not be able to log out without exitting the original kermit. Of course, once the user pushes a subshell she might forget about the open line until she logs out; it would be nice to change the prompt in the subshell, but i'm not sure how to do it in an exec. [Ed. - Further contributions to this discussion are welcome. If the WHOLE WORLD can come to a concensus about how Unix line locking should work, we can make the program abide by it. But then somebody has to write the installation manual, the user manual, and the environmental impact statement...] ------------------------------ Date: Thu, 27 Jun 85 15:22 EDT From: WIBR@MIT-MULTICS.ARPA Subject: C-Kermit Problems: HP-9000, Racal-Vadic Modems, etc I was able to get the kermit package working on our HP-9000's. They have a problem, however. I can call a foreign host (even myself), login, run kermit on the foreign host and get files from the foreign host OKAY. However, when I try to send stuff to the foreign host, I have problems with packet sizes larger than 70 characters. I viewed the data flow through the modem with a protocol analyzer and it seems that everything looks okay: the sender keeps resending packets that are NAK'ed by the foreign host. Even with packet sizes of 70, the sender has to resend each packet something like ten times. At packet sizes of around 40, the situation is much better. i don't THINK my lines are excessively noisy (running "log packets" on either machine seems to support this), but I'm confused. [Ed. - Sounds to me like HP-UX has small input buffers for its serial ports, and can't accept bursts longer than 40-70. Not much you can do about this short of fooling with the kernel, or complaining to the vendor.] Another thing: we have racal-vadic modems that do not conform to the protocol that ckudia.c employs. Apparently, the old Racal Vadic's used to send "ON LINE", and the new ones (at least the Maxwell series, as well as the -PA and -PAR series) send "ONLINE" (your code searches for "ON LINE"). Secondly, your code "acknowledges printout of dialing string" by sending an extra after "(number)" when dialing the number. The old Racal Vadic's required the extra --- the NEW ones, however, do not. IN FACT, the new ones abort the dialing sequence when they receive the extra . Obviously, I had to change these two things when I wanted to get kermit working -- I felt you might want to pass some of this information on to others. The "ON LINE" vs. "ONLINE" discrepancy is not guaranteed by Racal Vadic to be cleared up: some models MIGHT use one, and others might still use the other. The business with the extra will go away: I was guaranteed that Racal Vadic's won't require it from now on (the newer models, that is). [Ed. - Yuk. I guess this means we another modem type has to be added to ckudia.c -- "NewRacalVadic". Alternatively, the code can be changed to do something like what is done for the Hayes, which also has two ways of answering ("verbal" and "nonverbal") -- feed it some innocuous command whose response will tell you if it's a new or old style modem, and then set a flag to that effect, which is used to control further interactions with it. This method is preferable to simply adding "NewRacalVadic" as another modem type, because how is the poor user to know whether her Racal-Vadic is new or old?] One question: is there any effort by you folks to support Codex short- haul modems in the near/distant future? Is there any perceived need? (actually, I guess that's two questions) [Ed. - The new ckcdia.c module is much easier to add new modems to than the old one was, thanks to reorganization by Dan Schullman. Dan is currently working on yet another release of that module; when that's ready, I'd encourage you to add support for "NewRacalVadic" and "Codex" to it and send it back to us.] Thanks for your help. ---Matt G. ------------------------------ End of Info-Kermit Digest ************************* ------- 28-Jun-85 18:10:53-EDT,10393;000000000000 Mail-From: SY.FDC created at 28-Jun-85 18:10:22 Date: Fri 28 Jun 85 18:10:22-EDT From: Frank da Cruz Subject: Info-Kermit Digest V2 #40 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 28 Jun 1985 Volume 2 : Number 40 Departments: C-KERMIT - Yet Another Unix Kermit Release (minor) MacKermit Observations MS-DOS KERMIT - Bug in MS-Kermit 2.28 and Tandy 2000 support MS-Kermit Reverse Wrap at Column 1 MISCELLANY - FTP Problems on CU20B ---------------------------------------------------------------------- Date: Fri 28 Jun 85 17:12:33-EDT From: Frank da Cruz Subject: Yet Another Unix Kermit Release (minor) To: Info-Kermit@CU20B This is to announce C-Kermit 4C(055). No major changes, mainly just some enhancements to the dial command, support for a some additional systems and modems. Here, for those who understandably have a hard time keeping up with all this, is a list of changes since 4C(052) was announced on June 18: C-KERMIT FOR UNIX, CHANGES FROM 4C(054) TO 4C(055), 28 JUNE 85: ckudia.c (all changes by Dan Schullman, DEC): . Add support for US Robotics modem (untested) from Joe Orost at Berkeley. . Reorganize MDMINF data structure to accommodate US Robotics (some char fields had to become strings). . Allow interrupts (SIGINT, e.g. ^C) to cancel dialing in progress. . Ring bell when connection made successfully. . Close line on failures. . Allow stored numbers with DF100 and 200 modems. ckudia.c now supports the following modems: . Cermetek Info-Mate 212 A . DEC DF03-AC . DEC DF100 Series . DEC DF200 Series . General Data Comm 212A/ED . Hayes Smartmodem 1200 & compatibles . Penril . Racal Vadic . US Robotics 212A . Ventel Plus "unknown" modems and direct (modemless) connections. C-KERMIT FOR UNIX, CHANGES FROM 4C(053) TO 4C(054), 25 JUNE 85: ckuker.mak (makefile): . Add "make ft17" for Fortune 16:32 For:Pro 1.7. . Add "make uts24" for Amdahl UTS 2.4 . Add "make valid" for Valid Scaldstar CAD system . Add "make c70" for BBN C/70 IOS 2.4 ckcmai.c: . Add call to sysinit() ck[uvm]tio.c: . Add sysinit() function. For VMS, open console. For others, null for now. ckutio.c, ckufio.c: . Add support for Fortune 16:32, mostly like 4.1bsd. . Ditto for Amdahl UTS 2.4, mostly like V7. ckuus2.c: . Expand a couple tabs in hlp1 (-h help message) so things line up right. C-KERMIT FOR UNIX, CHANGES FROM 4C(052) TO 4C(053), 21 JUNE 85: ckcfn2.c: . Change dopar() to be of type CHAR. . Fix dopar() to calculate odd parity correctly. ckucon.c, ckuscr.c: . Add "extern CHAR dopar();" declarations. The files, as usual, are in KER:CK*.* on CU20B, available via anonymous FTP. There's no real need to get them unless one or more of the changes listed above is of use to you. ------------------------------ Date: Fri 28 Jun 85 10:32:33-EDT From: Frank da Cruz Subject: MacKermit Observations To: manis%ubc.csnet@CSNET-RELAY In-Reply-To: Message from "Vincent Manis " of Thu 27 Jun 85 22:49:46-EDT >Date: Thu, 27 Jun 85 19:42:15 pdt >From: Vincent Manis >To: info-kermit@CU20B >Subject: MacKermit > >I've been using MacKermit for a week or so (0.8 (28)), and would like >to know whether the following are intended to be fixed: We're up to 0.8(32) now... >1) If I tell my local Unix that I'm a VT100, emacs has difficulty > refreshing the screen properly. Is the VT102 emulation imperfect, > or simply different enough from the VT100 that I should make a new > termcap entry? We use Mac Kermit with EMACS (both CCA and GNU) at 9600 baud on our VAX/Unix system and have not seen this problem. We tell it we're a VT100 since our EMACS's (or termcaps) don't yet have support for VT102. See if 0.8(32) exhibits the same behavior. >2) I'd like the ability to include an initial character string to send > automatically when I fire up a settings document. This would > provide some modem support (even if not terribly well). A reasonable idea; we'll add it to the list of things to do. A lot of other things have higher priority though, like screen save/print, saving lines off the top, cutting/pasting the screen, sizing the screen, allowing international character sets, etc. >3) Any possibility of mouse support (clicking the mouse somewhere away > from the current cursor position would send the requisite cursor > positioning string)? I doubt it. The program is already straining the limits of a 128K Mac. >4) Why doesn't KerKey have the ability to create a new settings > document? Why can't the settings menu from MacKermit be included > in KerKey as well? This would allow one to create a complete > settings file at one time. Simply a question of not having enough time to write the code. >5) I've had some sort of transient behaviour in which the first file > transfer in a session works ok, but subsequent ones just hang. > Firing up MacKermit again seems to cure the problem, but it's a > nuisance. (On the Unix end, this happens with both CKermit and the > old Unix Kermit, but not with enough regularity for me to pin it > down). You're not using parity, are you? If so, get 0.8(32), which fixes problems with parity. Otherise, it's hard to know what to say about this without more details about what machine, what Unix, what version of C-Kermit, what kind of connection, what baud rate, etc etc. This kind of behavior is always a possibility between any two Kermits and usually has more to do with the operating systems or communications equipment that Kermit itself. For instance, if you're running 4.2 bsd on a VAX with DMR's, you might be suffering from problems in Berkeley's DMR driver. Some other systems just get tired of allocating tty buffers after a while... We've used MacKermit to transfer very large batches of files at high baud rates without observing any consistent kind of failure. >6) The key in the upper right hand corner is labelled ``Backspace''. > By default it should generate a backspace. Matter of taste. You can always type a backspace using CTRL-H, but how do you type a DEL if there's no DEL key? Anyhow, that's what KerKey is for -- so people who don't like the defaults can change them. To be perfectly honest about the situation, Mac Kermit is "between maintainers" just now. The last two people who worked on it have both left, so I expect it will stay pretty much as it is for quite some time. - Frank ------------------------------ Date: Thu, 27 Jun 85 19:04:46 cdt From: goldberg@Uiuc.ARPA (Phil Goldberg) Subject: Bug in MS-Kermit 2.28 and Tandy 2000 support When you type 'C?' from the command prompt, instead of getting a 'Confirm with CR' message as in 2.27, you get a list of all commands from C-Z displayed. Since C is a valid command, isn't this a bug. I looked, but I couldn't figure it out. [Ed. - Hmmm... must have something to do with C being a synonym for CONNECT (necessary because of the addition of the CLEAR command). Added to the list of bugs, KER:MSKERM.BWR.] Steve Alexander has done mods to MSX/YIBM to get a Tandy 2000 module for v2.28. He swears up and down that this time he will send them in. Phil Goldberg goldberg@Uiuc [Ed. - Hope so...] ------------------------------ Date: Thu, 27 Jun 85 17:44:22 pdt From: gts%ucbpopuli.CC@Berkeley (Greg Small) To: info-kermit@cu20b Subject: MS-Kermit Reverse Wrap at Column 1 The backspace from column 1 to column 80 of the previous line was added for UNIX. For normal input echoing, UNIX assumes that the terminal handles all margin wraping. This includes both the normal forward wrap at the right margin and the less known reverse wrap at column 1. Many newer terminals do both. ANSI X3.64 enumerates some margin actions but does not specify any. Of course this only impacts those who enter and then wish to erase characters from lines longer than 80 characters. I had thought than no one would care, but our beta test release of MS-Kermit 2.27 turned up a number of users who complained that they could not erase characters accross the line wrap. I confess that I am not overly concerned with exact emulation of the limitations of the H19, our priority is delivering functionality. However we do try to avoid extensions which are likely to cause dificulties. Actually, we have abandoned pretending that a particular program emulates a real terminal. We now treat each emulator and version thereof as a seperate terminal type. Greg Small (415)642-5979 Microcomputer Communications gts@ucbpopuli.Berkeley.ARPA 214 Evans Hall CFO ucbvax!ucbpopuli!gts University of California SPGGTS@UCBCMSA.BITNET Berkeley, Ca 94720 ------------------------------ Date: Thu, 27 Jun 85 17:16:57 pdt From: rag@uw-june.arpa (David Ragozin) Subject: FTP problems on CU20B Today I tried to FTP some of the vms*.mar files on k2:. None of them would come. Each time I tried (with "TYPE ASCII") I received the error message: File not 7-bit - not text file. That sounds to me like a problem at your end, not mine. Could you have someone check it out? [Ed. - Oops! The bytesize was indeed 36, rather than 7. This is fixed now. Surprised nobody reported this before. In fact, all the following files had 36-bit bytesizes, which are now changed to 7: AP2KER.ASM AP2KER.TXT APPLEK.M65 CP4CPT.HEX CPMH8.HEX CPMPRO.HEX K10MIT.CCL K10V3.MEM MTSKERMIT.ASM MTSKERMIT.DOC MTSKERMIT.PAS PROV1.MEM RTED.TXT Sorry for the confusion; most of these files were created by TOPS-10 utilities that run on our DEC-20 system.] Also, is there some reason you know why I haven't been able to get any response from KERMSRV on BITNET for many days? [Ed. - KERMSRV has been undergoing reorganization the last few days. Should be up now.] ------------------------------ End of Info-Kermit Digest ************************* -------