2-Jul-85 19:54:13-EDT,10370;000000000000 Mail-From: SY.FDC created at 2-Jul-85 19:53:39 Date: Tue 2 Jul 85 19:53:39-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #1 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 2 Jul 1985 Volume 3 : Number 1 New Release of Kermit-11 Available Unix Program for Converting CU20B FTP Server Filenames Mac Kermit & Caps Lock Key IBM PC Kermit and National Character Sets MS DOS Memory Allocation in Kermit More about ND-Kermit Kermit Versus 9600 Baud ---------------------------------------------------------------------- Date: Tue 2 Jul 85 19:50:57-EDT From: Frank da Cruz Subject: New Release of Kermit-11 Available Keywords: Kermit-11 Brian Nelson of the University of Toledo (BRIAN@UOFT02) has sent in version 2.29 of Kermit-11, replacing version 2.26 of March 1985. The changes include: . Fix losing attribute packets in case timed out or nak'd. . Fix ASSDEV: for stack problem . Added SET BINARY-TYPE .xxx for overriding the built-in binary file type list. . Kludge if RT system does not have a clock. . Ignore TYPE in SET FILE [TYPE] arg. . Final mods by Ned Rhodes for TSX+ . Add support for server REM DIR command for RT and TSX+. . Fix bug for setting 8bit prefixing (quite noticable on PRO/RT version). . Add SET FIL [NO]SUPERCEDE to protect files that already exists. . Update packet types to symbolic names The files are available via anonymous FTP from CU20B as K2:K11*.* (many files). General information is in K2:K11AAA.AAA. The files are listed and explained in K2:K11FIL.DOC. Installation instructions are in K11INS.DOC. ------------------------------ Date: Tue 2 Jul 85 15:50:57-EDT From: Frank da Cruz Subject: Unix Program for Converting CU20B FTP Server Filenames Keywords: FTP Server, UNIX Many have complained that when getting (especially "mget"ing) files to a Unix system from the CU20B FTP server, the resulting filenames are not what would be desired. This problem is partially fixed by the installation of a new FTP server that allows users to CWD (CD) to a given directory for read access, so that the fully qualified file name need not be sent back for each file gotten with an "mget". However, even if you CWD to KER: or K2: before issuing an mget command, the files will still show up with uppercase names and will include "generation" (version) numbers. And of course, if you fail to CWD first, you still get the directory name too, so that you are likely to find files with names like CKUFIO.C.3 in your Unix directory, rather than the ckufio.c you might have wanted. A new program, xxu (20-to-Unix filename converter), is available in KER:XXU.C which will fix the names of all files sent to a Unix system from a DEC-20 FTP server. It should work on VMS and DEC-20 filenames alike -- it strips DECnet node names, device names, directory names, generation numbers, and it lowercases the uppercase letters. When renaming to the name thus formed, it takes care not to write over any existing files. See comments in the source for further details. ------------------------------ Date: Fri 28 Jun 85 15:52:03-EDT From: Mauricio Matiz Subject: Mac Kermit & Caps Lock Key Keywords: MacKermit Now that Kermit for the Macintosh has a keymap program that allows mapping of the control key to the caps lock key, the locking mechanism becomes a nuisance. There have been postings about taking the whole keyboard apart and using a soldering gun, etc. in order to remove the locking mechanism. I have come up with a simpler and easier method that does not void your warranty. Remove the key using a small screwdriver. There is a spring and the end of it goes through the plastic that supports the key. Stick a piece of paper or soft putty (very small) between the tip and the bottom of the keyboard. This will prevent the key from depressing all the way and locking, but still allow contact of the key. It even works for repeating control characters. If you come up with a better substance to stick in there let me know (or the Kermit people at Columbia). I have been using this for some time with no problems. I imagine that after a while I will need to change the paper because of the continued pressing on it. Maurice Matiz Columbia University User Services [Ed. - As usual, neither the author of this message nor Columbia University acknowledges any liability for damage or loss of warranty incurred by anyone who follows these directions.] ------------------------------ Date: Sat, 29 Jun 85 14:43:27 -0200 From: Frithjov Iversen Subject: IBM PC Kermit and National Character Sets Keywords: MS-DOS Kermit A suggestion for IBM PC Kermit: You must be aware of that many european characters have a different internal representation on the IBM PC and other computers. The norwegian alphabet, for example, has 3 extra characters, which in normal ASCII replaces [\] (upper) and {|} (lower case). On the IBM PC, all these characters are represented with values in the range 128-255. This means that every terminal emulation program (to have a chance on the Norwegian market) must include an option to convert between the two standards, both when acting as a terminal and when transferring files. We have a local mod to MSSET and MSYIBM which fixes the terminal problem, and provide a converting program on the Kermit diskette to convert the text files. However, I feel that this must be a problem in other European countries, and I was hoping for a more general solution. The SET KEY feature will make it possible to do terminal emulation with a "national" keyboard, but the right characters will not appear on the screen. Why not include a SET FONT command? For Norway, all that would be needed, was 6 SET KEYs and 6 SET FONTs in a macro defined in MSKERMIT.INI, and we could do without the local mods. As to transferring files, I prefer the "raw" approach, and leave conversion to the user. When transferring MASM or PASCAL programs, I do not like to see my square brackets turn into you-know-what. [Ed. - Good idea, though I'm not sure if you mean "set font" or "set character". A font would be a whole character set, presumably some alternate character set in ROM, invokable by changing some pointer. This would probably be easy to implement, though the details would be very system-dependent. Changing how individual characters display would be harder, not so much to implement, but to design the command -- the user would need to say something like "if I get a character whose ASCII value is x, then display character y from font z in its place..."] ------------------------------ From: lotto%lhasa@harvard.ARPA Date: 30 Jun 85 14:19 EDT Subject: MS DOS Memory Allocation in Kermit Keywords: MS-DOS Kermit Well, I finally found the problem with memory allocation and (Microsoft) I was missing something crucial. KERMIT as part of its memory initialization, gives extra memory back to DOS explicitly. Unfortunately, the calculation of the image end assumes that the stack segment is not last. My apologies to those people that I confused from an incomplete investigation of the problem. I still object to the IBM versions of Micro- softs programs being built with new defaults, but in this case it only confused matters instead of being the root of the problem. To address the issue of memory allocation directly, if segment ordering becomes so important, perhaps the required space should be calculated from the load module image size and not from the offset of a specific object file in KERMIT. Is there some reason why this is undesireable? Jerry Lotto lotto@harvard.ARPA inhp4!harvard!lhasa!lotto ------------------------------ Date: Sat, 29 Jun 85 14:43:27 -0200 From: Frithjov Iversen Subject: More about ND-Kermit Keywords: ND Kermit The operating system of the ND series computers is SINTRAN III. Versions are numbered with the letters A,B,.. The Kermit I sent you runs under version J, and needs the Pascal-J compiler and library. The binary program, KERMIT:PROG, should run under previous versions, at least back to H. Anyone who sends us a self-adressed diskette envelope with one 148-page 8" ND diskette (two if you need source code), will receive the latest version of ND-Kermit for free. There are plans to include SERVER and CONNECT later this summer. Frithjov Iversen RUNIT Brukerkontakt N - 7034 Trondheim-NTH NORWAY ------------------------------ Date: Sat, 29 Jun 85 22:56 EDT From: Frankston@MIT-MULTICS.ARPA Subject: Kermit Versus 9600 Baud Keywords: Modem, Sliding Windows Kermit I've been experimenting with a 9600 bps dialup modem. It is cheap (about $800). It is really a half duplex modem that provides a full duplex interface and a reliable byte stream. This is fine, except when one uses protocols such as Kermit and Xmodem which have only a single packet in the stream at a time. It takes .5 seconds or more to turn around the line. Thus sending a packet, acking and sending the next one reduce one to 1 second/ package or about 900 bps for kermit and about 1200 for Xmodem. This is the same as the problem of satellite links. Given that such modems make a lot of sense since they make more effective use of the bandwidth for file transfering than true full duplex modems, what thought has been given to upgrading Kermit to allow for a protocol that can have multiple packets active at once? I presume that there has already been much discussion of this, but now that it is my ox being gored, I have a special interest in this issue. [Ed. - For a couple years, people have been asking for (a) a sliding window extension to the Kermit protocol, and (b) a way to have longer packets. Some people are working on a sliding window protocol, and a proposal will be posted to Info-Kermit some time soon. At the same time, I'll also post a proposal for a way to allow longer packets.] ------------------------------ End of Info-Kermit Digest ************************* ------- 9-Jul-85 18:04:18-EDT,20303;000000000000 Mail-From: SY.FDC created at 9-Jul-85 18:03:13 Date: Tue 9 Jul 85 18:03:13-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #2 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 9 Jul 1985 Volume 3 : Number 2 KERM and KERK Registered with Apple Okstate Downtime Re: MS-Kermit 2.28 Wraparound Backspace MASM & Kermit C-Kermit on HP-9000 S500 C-Kermit Line Locking UUCP Line Locking Running Pro-3xx P/OS Kermit from Tool Kit Bug in Prime Kermit More about 9600 bps Modem More about PC-Kermit and National Characters Z100 Comunications Program Query Kermit on MicroVAX-1? ---------------------------------------------------------------------- Date: Mon 8 Jul 85 18:04:31-EDT From: Frank da Cruz Subject: KERM and KERK Registered with Apple Keywords: Macintosh The Macintosh application names KERM and KERK have been registered with Apple for Macintosh Kermit and for the Macintosh Kermit Keyboard Configurator, respectively. These names allow "documents" (e.g. settings files) created by these programs to be associated with the programs themselves so that double clicking such a document will invoke the program with the indicated settings. ------------------------------ To: Info-Kermit@CU20B.ARPA Subject: Okstate Downtime Date: 09 Jul 85 06:43:11 CDT (Tue) From: vasoll%okstate.csnet@csnet-relay.arpa Keywords: Okstate The system `Okstate' will be down for hardware and software upgrade from 8:00 a.m. July 17th until 5:00 p.m. July 22 (all times central). During this time the UUCP and Kermit Server line used for the Kermit Distribution will not be available. 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: Tue, 2 Jul 85 18:20:31 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) Subject: Re: MS-Kermit 2.28 Wraparound Backspace Keywords: MS-DOS Kermit, UNIX In Info-Kermit Digest, volume 2, number 40, Greg Small writes: 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. Of course this only impacts those who enter and then wish to erase characters from lines longer than 80 characters. That confuses me. My impression is that bsd UNIX uses curses and termcap entries to perform terminal independent smart terminal operations. This includes simulation of wrap-around backspace for terminals whose termcap entries do not contain the "bw" ("backspace wraps") specifier. My impression is reinforced by observation of "vi" behavior with long lines. I used MS-Kermit 2.27 (which correctly emulates H-19 backspace behavior) in linewrap mode. On multi-row lines, right arrow and space moved me from column 80 on one row to column 1 on the next. Left arrow and backspace moved me from column 1 to column 80 of the previous row. 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. This seems to me to be a sad commentary on the current state of design and implementation of most terminal emulation packages. It is also a little frightening to consider what this means if you multiply the number of available terminal emulators (say, for just the vt-100) times the number of different operating systems which think they know about the terminal being emulated. Particularly in the case of Kermit, where Columbia and the user community have control over the quality of the emulation, it seems to me to make much more sense to emulate the H-19 well enough that it fools (almost) all the systems which think they know about it. Users whose systems require a more faithful emulation than is currently provided should be encouraged to contribute Kermit code modifications. Finally, let me reiterate that though I believe strongly in faithful emulation, and though I can't see how UNIX could require wrap-around backspace, I don't think wrap-around backspace represents a serious deviation from the ideal H-19 emulation. I can't imagine that it is common for programs to send column-1 backspaces to H-19s, realizing that they will be ignored. [Ed. - We have received a couple H-19 (Z-19) manuals in response to our plea a couple issues ago (thanks to those who sent them!), so we should now be able to emulate this terminal more faithfully...] ------------------------------ From: lotto%lhasa@harvard.ARPA Date: 28 Jun 85 11:18 EDT To: harvard!info-ibmpc@usc-isib.ARPA Subject: MASM & Kermit Keywords: MASM If you are building KERMIT with the Microsoft assembler (any version) or the IBM release (pre 2.0) all will work as written. If however, you are using MASM 2.0 or later (IBM release) you must specify the /S switch on the command line for MSXDMB. Be sure the Linker you are using does not predate the version of DOS by too much. Also, make sure you actually DO have enough memory to run KERMIT in. A fairly significant chunk of RAM is used by the new KERMIT, but unlike the previous version, it is allocated by the program. Gerald Lotto - Harvard Chemistry Dept. UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto ARPA: lotto@harvard.ARPA CSNET: lotto%harvard@csnet-relay ------------------------------ Date: Wed, 3 Jul 85 12:16 EDT From: WIBR@MIT-MULTICS.ARPA Subject: C-Kermit on HP-9000 S500 Keywords: C-Kermit, HP9000 I solved that packet-size problem I was having (calling out and trying to send from my HP9000 Series 500). Apparently, I have to tell the remote host that I am a vt100, or I get into problems. At least, when I did call myself a vt100, I was able to send with no problems. The obvious inconvenience hewith this is that since I really am using an HP2392A terminal, fun things like EMACS die big if I'm trying to use Kermit in the same login session. Oh, well. [Ed. - Could it be that by telling the host you are a VT100, you turn on its XON/XOFF flow control? Maybe you could tell it you're an HP terminal, and also tell it to use XON/XOFF, and all will work well.] A note to HP9000 users out there ( if there are any!): Kermit cannot use an ASI card interface to a modem if it is to call outside. It needs to be talking to a MUX board port (properly addressed by read-writeable ttyxx, cuaxx and culxx files in /dev). Since the ASI board took care of neat items such as telling the modem to hang up when it's done with it (using signal lines), and the MUX board cannot, we installed new chips in our Racal-Vadic's (from them) to interpret a ^C^D sequence flanked by 3 seconds of dead air on either side as a "hangup". Thus, I modified the Kermit code to echo a "^C^D" to the communications port when exiting Kermit. Perhaps the best way to do this, would be to modify the ckudia.c MDMINF struct to include a "hangup_str" parameter. Unless of course, this is too obscure a scenario... One further note: ^\^F still doesn't abort a file transfer that is hung up; neither does ^\^B, for that matter. Does the transfer have to be at least a little successful ( a few packets here and there) for this to work? If so, perhaps it is suboptimal? [Ed. - Right, interrupting a transfer with [^\]{^F,^B} only takes effect after the first data packet has passed. So there's no good way to interrupt a Unix Kermit that's stuck trying to start a file transfer, short of ^C'ing it to stop the program all together. This is noted in the .BWR file.] ------------------------------ Date: Sun, 7 Jul 85 10:14:48 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) Subject: C-Kermit Line Locking Keywords: C-Kermit In Info-Kermit Digest, volume 2, number 39, Scott Weikart writes about Kermit line-locking: 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. I agree that the group mechanism is the appropriate tool to use. On our Vax 780, 4.2 BSD system, the system administrator has established a similar group. The dial-out ttys are owned by the group and are given owner and group access, and so is /usr/spool/uucp. That way, using /etc/groups, we can admit users to the group who have a valid need to dial out. We thereby reduce our exposure to the phone bills which would result from someone dialing into his favorite Timbuktu bulletin board all day. To make this system as consistant as possible, we have modified C-Kermit to make the /usr/spool/uucp "no read access" and "no write access" warning messages be preventive messages instead. That way, if an access specification mistake has been made, there is less likelyhood of Kermit users, tip users, uucp, etc. stomping on one another. As I see it, the problem can be resolved for all sizes of systems. In a small system, with a tight group of users, make /usr/spool/uucp and the ttys publicly accessible. With a larger system, make them group accessible, and only admit to the group those with a legitimate need to contribute to the size of the phone bill. The concern over users' ability to get their work done is resolved by realizing that on a system which is small and tight-knit enough for public access to be appropriate, the "system administrator" is likely to be very accessible (if "he" is not, in fact, just a hat worn by any of several users when doing system administration tasks). In a larger system, the administrator has a legitimate need to control access. I do believe, though, that Kermit's /usr/spool/uucp access warnings should be made preventive. I believe this for the very reason you (the Info-Kermit Digest editor) stated in volume 2, number 38: 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. With its current access warnings, C-Kermit is just such a program. ------------------------------ Date: Sun, 7 Jul 85 14:53:48 pdt From: "Scott Weikart; Community Data Processing; 415-322-9069" Subject: UUCP Line Locking Keywords: UUCP, C-Kermit Ken Poulton had talked about wanting to have one kermit process open a circuit, and then have other kermit processes use that same circuit. His scheme was to have a kermit exit command that wouldn't close the line. This scheme has the problem that people will forget to release the tty. I had suggested an alternative scheme of having subsequent kermits run in a subshell of the kermit that opened the circuit, so that when you tried to log off you would pop back into the parent kermit and then exit it and release the line. I had also suggested that on those systems where lock-file directories are not accessible by the world, that kermit be run setgid in a group which has write accesss to the lock-file directory, so that a) kermit wouldn't have to be setuid and b) the lock file would be owned by the user account so that subshell kermits could see if their user owned the tty lock-file. If people wanted kermit to run setuid, I had suggested writing the account name into the lock-file, so that subshell kermits would just read the lock-file to see if their user had reserved the tty. What follows is a discussion in usenet about a similar problem. The last note indicates that Honey Danber UUCP uses a similar scheme: it writes the process ID (PID) into the lock-file. So if kermit used this scheme, a subshell kermit could read the lock-file and see if its contents match kermit's PPID (parent PID), as gotten by getppid(). [Ed. - Kermit actually does write the PID into the lock file, but currently does not use it for anything. Note that not all Unix systems have getppid().] >>The problem with tip is that, after locking the modem port, it >>setuid's back to the original invoker's uid/gid. This is >>supposed to patch the security hole surrounding shell escapes >>and file transfers. Fine but; alas; it doesn't read /etc/phones... Another problem this causes involves /usr/spool/uucp security and LCK files. It is desirable to have /usr/spool/uucp NOT WRITABLE by the world, as this leaves a hole for (admittedly clever) vandalism. However, with the 4.2BSD version of `tip', this causes the LCK files to be left around after `tip' exits, preventing use of the port until manual intervention by a "privileged user". `tip' creates the LCK file while SUID, and no longer has write permission in /usr/spool/uucp once it changes the UID. The LCK file therefore remains. For binary sites the only "solution" seems to be to leave this directory writable. Yuck. /+\ Keith F. Pilotti (UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti (ARPA) Pilotti@UCSD a possible solution is to follow honey danber's lock file treatment. assuming tip's lock files have the same format as uucp's, the lock file contains the pid of the process that created it. write a program that reads the lock file and issues signal 0 to the named pid. if the return is 0 or EPERM, the lock file is valid, otherwise it should be removed. if binary license is a problem, make tip a shell script that calls tip, then this program. i leave the details to your imagination. peter [Ed. - Let's keep this discussion going until some kind of concensus is reached. My concern is that whatever mechanism is settled upon is rational, humane, simple, installable, maintainable, and explainable.] ------------------------------ Date: 7 Jul 85 19:01:41 EDT From: D. M. Rosenblum Subject: Running Pro-3xx P/OS Kermit from Tool Kit Keywords: Pro-3xx P/OS Kermit Users of PRO/Kermit may be interested to know that PRO/Kermit can be run from PRO/Tool Kit, instead of from the main P/OS menu. This is useful if you are in the habit of going directly into PRO/Tool Kit and doing everything from there. Here's how to do this. Suppose you have installed PRO/Kermit in a menu on a hard disk system. KERMIT.TSK will be in a directory of the form [ZZAPnnnnn], where nnnnn is a system-dependent five-digit number (you will have to do some hunting to find which such directory KERMIT.TSK is in). PRO/Tool Kit's START.CMD and EXIT.CMD files will also be in a directory of the form [ZZAPmmmmm] (where mmmmm is not equal to nnnnn). You should APPEND the following lines to [ZZAPmmmmm]START.CMD, replacing [ZZAPnnnnn] throughout by the name of the directory in which KERMIT.TSK resides. ; ; Install PRO/Kermit Version 1.0 ; ; Note that the reference to [ZZAPnnnnn] in the line that installs ; KERMIT must be changed if PRO/Kermit is removed from the menus and re- ; installed there. ; .DISABLE QUIET .IFNINS KERCON INSTALL [ZZKERMIT]KERCMN .IFNINS KERCON INSTALL [ZZKERMIT]KERCON/NOREMOVE .IFNINS KERFIL INSTALL [ZZKERMIT]KERFIL/NOREMOVE .IFNINS KERMIT INSTALL [ZZAPnnnnn]KERMIT .ENABLE QUIET (the PRO DCL indirect command processor has no way of testing to see whether a common region has been installed, so you have to instead check to see whether some task, that you're careful to have installed if and only if that common region is installed, has been installed in order to determine whether the common region has been installed -- this makes the order of the commands in the START.CMD file important). You should also append the following lines to [ZZAPmmmmm]EXIT.CMD. ; ; Remove PRO/Kermit Version 1.0 ; ; Note that we do not remove KERCON, KERFIL, or KERCMN (which is a ; common region), since the first two are normally installed with the ; /NOREMOVE option (when Kermit is run from the menu in P/OS), and the ; third is not normally removed when Kermit is exited. ; .DISABLE QUIET .IFINS KERMIT REMOVE KERMIT .ENABLE QUIET If you are on a diskette system, all references to directories [ZZAPmmmmm] and [ZZAPnnnnn] should be replaced by [ZZAPPL]. Otherwise, as far as I can tell, the procedure is the same (I don't have access to any diskette-based PROs, so I can't tell if this really works -- in other words, it's untested). Once you have made these additions to the .CMD files, all that you have to do in Tool Kit to run PRO/Kermit is issue a RUN KERMIT command. You will then be in Kermit's top-level menu, and you may proceed as usual. When you exit PRO/Kermit, you will be back in Tool Kit. ------------------------------ Date: Wed 3 Jul 85 00:13:21-PDT From: Bob Larson Subject: Bug in Prime Kermit Keywords: Prime Kermit Testing the new os9 kermit, I found another bug in Prime kermit. When in server mode, Prime kermit will Ack an 'R' packet, then send a Send-Init packet. According to the protocol manual, it is not suposed to send the 'Y' (Ack) packet. I had to modify the os9 kermit to ignore the extra Ack. [Ed. - If Prime Kermit really does this, it's a bug. I've forwarded Bob's message to the Prime Kermit authors.] ------------------------------ Date: Wed, 3 Jul 85 21:24 EDT From: Frankston@MIT-MULTICS.ARPA Subject: More about 9600 bps Modem Keywords: Modem Since a few people are asking me about the modem I mentioned, I will pass on the information. This is for informational purposes only and is not a comment pro or con: It is the UPTA96 modem from Electronic Vaults, Inc. Their phone number is 703-883-0332. It presents a full duplex interfaces but transmits half duplex using its own error correcting protocol. It can drop back to 7200 or 4800 under program control. It uses either XON/XOFF or CTS/DTR flow control. It is available as a standalone modem or as a board for the IBM PC. It uses a standard RJ11 jack. ------------------------------ Date: Fri, 5 Jul 85 15:46:22 -0200 From: Frithjov Iversen Subject: More about PC-Kermit and National Characters Keywords: MS-DOS Kermit What I had in mind, is what you refer to as SET CHARACTER. Anyway, the feature need not include the ability to switch between different font sets in ROM. It could be implemented as a simple 256-byte lookup-table. When ASCII comes in,look it up, and it turns into before sending it to the screen. One may assume that the National character ROM already is in effect. -fi ------------------------------ Date: Tuesday, 2 July 1985 11:43-MDT From: Dave Shanks Subject: Z100 Comunications Program Query Keywords: Z100 Kermit Does anyone out there know of a good communications program for the Heath/Zenith H/Z100 under MS-DOS which supports both the serial ports? I am specifically looking for a program which will allow me to switch ports on the fly. It would be nice if the program were in the public domain, but not necessary. Thanks in advance. Dave Shanks ..!tektronix!reed!teneron!shanks Teneron Corp. 6700 SW 105th Suite 200 Beaverton, OR 97005 (503) 646-1599 [Ed. - Does anyone have experience using MS-DOS Kermit on the Z100 with two ports?] ------------------------------ Date: Mon, 8 Jul 85 11:56:14 EDT From: John Shaver STEEP-TM-AC 879-7602 Subject: Kermit on MicroVAX-1 Keywords: MicroVAX-I Is there any experience with Kermit on the MicroVAX-1? [Ed. - Comments appreciated, of course, about either VMS or Unix on the MV-I, or the MV-II for that matter.] ------------------------------ End of Info-Kermit Digest ************************* ------- 12-Jul-85 18:01:20-EDT,10612;000000000000 Mail-From: SY.FDC created at 12-Jul-85 18:00:56 Date: Fri 12 Jul 85 18:00:56-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #3 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 12 Jul 1985 Volume 3 : Number 3 Departments: ANNOUNCEMENTS - Another Release of C-Kermit 4C for Unix, VMS, and Macintosh Commodore-64 Bootstrap Program in Fortran Assembling Apple II Kermit (AP2KER) with Apple Assembler? New Apple II Cross Assemblers OLD QUERIES ANSWERED - Re: Kermit on MicroVAX-I Re: Z100 Communications Program Query NEW QUERIES - IBM 3270/PC and Kermit? ---------------------------------------------------------------------- Date: Fri, 12 Jul 85 16:58:22 EDT From: SY.FDC@CU20B (Frank da Cruz) Subject: Another Release of C-Kermit 4C for Unix, VMS, and Macintosh Keywords: C-Kermit, UNIX Kermit, VMS Kermit, MacKermit Yet another release of C-Kermit 4C, this one is 4C(056), for Unix, VAX/VMS, and the Apple Macintosh. Major differences from 4C(055), affecting all systems: . Various file transfer performance improvements. . Another bug with 8th-bit-prefixing negotiation fixed. . Some bugs fixed concerning interrupted file transfers. . Incoming Z (EOF) packet now ack'd only after file successfully closed. . Allowance made for ACK to F packet containing alternate file name. . "Blank lines" in packet stream no longer NAK'd. . Test for echoed packets fixed. . Input buffer now flushed only after desired packet is read. . Many minor fixes and cleanups. Unix and VMS only: . "statistics" and transaction log now include timing information. . "set incomplete {keep,discard}" is now implemented. . "show parameters" redesigned and has some inaccuracies fixed. . "echo" now accepts \ooo octal escapes, e.g. "echo foo\007bar" will now beep. . "set prompt" now accepts argument in doublequotes to allow blanks. . Command parser now accepts comment lines starting with "%". . It is now possible to exit protocol at any time by typing ^A^C^C. . Manual chapter updated to reflect above changes. Unix only: . 4.xBSD performance improved by doing nonblocking reads, own buffering (Herm Fischer's Sys III/V code adapted to work for BSD). VMS only: . Version numbers should now be stripped from outbound file names. . Improved build procedure (CKV*.COM). Macintosh: . No Mac-specific changes were made, but the changes made to the system- independent protocol modules should fix a couple problems that reportedly prevented all C-Kermits from communicating with systems that send "blank lines" between packets, with systems that echo packets, and with Kermits that know about 8th-bit prefixing but refuse to do it. The new Mac Kermit release is numbered "0.8(33)". The new release has been tested under 4.2bsd, Pro/Venix V1, and on the Macintosh against normal systems like DEC-20's and VAXes as well as against IBM mainframes both in line mode and with full screen 3270 protocol conversion (thru Series/1). The VMS version has not been tested (feedback welcome). Thanks to Larry Afrin, Gary Algier, Todd Booth, Kelvin Nilsen, Ken Poulton, Dan Schullman, Ed Schwalenberg, and others for reporting problems and/or suggesting fixes since the last release of C-Kermit 10 days ago. The new files are in K2:CK*.* on CU20B, available via anonymous FTP. The updates are listed in greater detail in the files K2:CK*.UPD. The files K2:CK*.BWR list known bugs and restrictions. K2:CKUKER.DOC is the new Kermit User Guide chapter for Unix Kermit (not yet integrated into the monolithic Kermit User Guide, KER:KUSER.DOC). Since C-Kermit continues to change, it is not recommended that you get these files unless: (a) You are having problems with your present version that might be fixed by the changes listed above; (b) You are doing development work based on the C-Kermit source (always try to work from the latest sources!). It is expected that these new files, along with others recently announced, will be available via uucp at okstate shortly after okstate comes back up on July 22 or thereabouts, and will also be available on BITnet via KERMSRV at CUVMA probably next week. As usual, send comments, suggestions to Info-Kermit@CU20B. ------------------------------ Date: 10:23:48 07/11/85 (85.192) From: Jeff Balvanz Subject: Commodore-64 Bootstrap Program in Fortran Keywords: Commodore 64 This is a Fortran version of the download program C64BOOT designed to bootstrap the Commodore-64 version of Kermit from our VAX system. It should work with minor modifications with any system running Fortran-77. [Ed. - Thanks, now we have one in each of Fortran, C, Simula, and Clu -- quite a collection -- in KER:C64BOOT.* (.FOR, .C, .SIM, .CLU; pick your favorite.)] ------------------------------ Date: Fri, 12 Jul 85 08:52:18 MST From: slesh@FTH-1 Subject: Assembling Apple II Kermit (AP2KER) with Apple Assembler? Keywords: Apple II DOS Kermit Assembling and using the Apple Assembler/Editor version of Kermit is NOT a straightforward proposition. (The following comments are based upon as little expertise with Apple 3.3 DOS and the assembler as I could acquire in the process of getting an Apple DOS Kermit.) A few of the little quirks I have discovered THE HARD WAY follow: 1- if you obtain the source ( ap2ker.asm ) using a communications program which runs under another operating system and permits text files larger than 32K (e.g. CP/M 80), you will not be able to convert the resulting file to an Apple text file without splitting it. My Applicard file conversion utility ADOSXFER converted the first 32K all right then went right on cheerfully whirring disks and flashing text on the screen. When I attempted to assemble the resulting product there were 81 errors. 2- the Apple Assembler documentation mentions something about 'chaining' - "CHN" - but I couldn't get that to work. What did work was naming two source files on the "asm" command line. I couldn't find anything in the documentation to indicate WHY it worked. (The binary file takes the name of the second source file named - an undocumented feature of the Apple Assembler?) 3- the 'ap2ker' version does NOT have some of the features documented in the DEC 20 version (e.g. talking to servers, setting slots or defining keyboard type). A little help from anybody out there who really knows what's going on would be appreciated. [Ed. - AP2KER is a "hand crafted" translation of the original Stevens Institute of Technology "CROSS" cross-assembler source into Apple assembler, done by Olaf Pors of the University of Virginia. It is, indeed, based upon an older version of Apple Kermit; the CROSS version continued to change after Olaf contributed this version, and Olaf made a few changes during translation that may or may not have shown up in the "master copy". CROSS, for those who don't know, is a general-purpose cross assembler written in PDP-10 assembly language (and hence can be run only on DEC-10 and DEC-20 systems). The input syntax closely resembles PDP-11 Macro assembler, perhaps because CROSS is based upon MACY11, the DEC-10 PDP-11 cross assembler. Unlike MACY11, however, CROSS can generate output for a wide variety of micros from basically the same input syntax. But since CROSS only runs on PDP-10 style processors, these benefits are not widely enjoyed. To complete the cycle, it would be interesting if someone could write a new CROSS that accepts PDP-10 Macro-10 for input and produces output in a variety of formats; then CROSS itself could be CROSS-assembled to form a new CROSS that could then cross-assemble APPLE.M65 on other machines. But wait, maybe there's a better way ... ] ------------------------------ Date: 08 Jul 85 AT 15:37:30 From: Ted Medin Subject: New Apple II Cross Assemblers Keywords: Apple II DOS Kermit I have two Apple II cross assemblers written in C. One can handle the M65 CROSS-format source for Apple II DOS Kermit and the other can handle Apple II assembler (AP2KER). These assemblers are available in source asis if any one wants them; I got them from the net and then hacked them. I will mail them in three parts each as Unix shell archives; cut and execute to produce the files which include test cases. The test cases are the best documentation on what the syntax is. [Ed. - Thanks! The files are available in the Kermit-Tools area on CU20B as KT:APX*.* (Apple II assembler) and KT:M65*.* (CROSS M65 format), via anonymous FTP, along with CROSS which is also still there.] ------------------------------ Date: Wed 10 Jul 85 23:12:09-EDT From: Richard Garland Subject: Re: Kermit on MicroVAX-I Keywords: MicroVAX-I Kermit Kermit was the first means we used to load stuff into our microVAX-I last October under microVMS V1.0. We down-loaded the Stevens Kermit .HEX file (using raw terminal capture with XON/XOFF flow control), did the same with the DEHEXIFY Macro source, assembled DEHEXIFY, dehexified KERMIT, and used it for weeks getting our applictions down from our VMS VAX 780. It was a mainstay until DECnet over Ethernet got installed. It was hardwired port-to-port at 9600 bpi. The current version of Kermit works equally well with microVMS V4.1 Rg ------------------------------ Date: Wed, 10 Jul 85 09:58:22 cdt From: knutson@ut-ngp.ARPA (Jim Knutson) Subject: Re: Z100 Communications Program Query Keywords: Z100 Kermit I had thought long and hard about a way to access both ports when I was getting the Z100 version up. The problem has to do with using the BIOS routines for character output. These only support one AUX device. To be able to use the other serial port, a rewrite of the I/O module would need to be done and some interrupt driven I/O routines would have to be written. Unfortunately, I don't have the time to do this but it shouldn't be too hard if you use the IBM-PC I/O module as an example. Jim Knutson ------------------------------ Date: Fri 12 Jul 85 11:00:54-PDT From: Wing Lee Subject: IBM 3270/PC and Kermit? Keywords: IBM 3270/PC Will the IBM-PC kermit work on an IBM 3270/PC using its RS-232 port? We currently have version 2.26 of IBM-PC Kermit. wing lee [Ed. - Anybody have experience with this? My guess is that it would work just fine, but have never had any reports either way.] ------------------------------ End of Info-Kermit Digest ************************* ------- 15-Jul-85 16:27:31-EDT,11222;000000000001 Mail-From: SY.FDC created at 15-Jul-85 16:26:36 Date: Mon 15 Jul 85 16:26:36-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #4 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 15 Jul 1985 Volume 3 : Number 4 Kermit Protocol Extension Proposals Proposal for Extended Packet Lengths ---------------------------------------------------------------------- Date: Mon 15 Jul 85 16:12:15-EDT From: Frank da Cruz Subject: Kermit Protocol Extension Proposals To: Info-Kermit@CU20B.ARPA Keywords: Kermit Protocol This week, two new extensions to the Kermit file transfer protocol will be proposed. Both address one of Kermit's weakest areas: performance. Both extensions are designed to allow extended Kermits to work transparently with older Kermit programs that are ignorant of the extension; this has always been the rule for extensions added to the protocol. The two extensions are: 1. Longer packets. 2. Continuous transmission of packets in a "sliding window". As originally designed, Kermit is a "stop and wait" protocol; each packet has to be acknowledged before the next one is sent. A Kermit packet includes a single-byte length field expressed as a printable ASCII character, limiting the packet length to 94. The original design has been quite effective for several reasons: a. Kermit programs are simple to write. b. The restriction on packet length guaranteed that Kermit would work on practically every system, including the many whose terminal input buffers cannot tolerate long bursts of input. c. The stop-and-wait strategy gives the operating system time to consolidate its input buffers. As Kermit grows in popularity, it has found use in situations where its basic design results in poor performance. Two examples: a. Connections with built-in delays, like public networks or satellite links. Unlike direct or dialup connections, these connections do not have a dedicated channel; response varies with the current load on the medium, and also with the "diameter" of the network. Delays can slow down the performance or stop it all together if they exceed Kermit's timeout parameters. b. Direct, clean connections, to systems with big input buffers. When the error rate is very low, throughput is unreasonably impeded by stop-and-wait for short packets. At first glance, it would seem that a single solution could address both situations. First, note that any performance extension must require the receiver of a file to have big input buffers (and since many many systems don't, any extensions will have to be negotiable). The question is whether to send one long packet or a bunch of short packets end-to-end (or both). Assuming that each packet must be acknowledged, the advantage would seem to go to long packets, since fewer acks would be required per unit data. But when errors occur the amount of data to be retransmitted is less with short packets, so a sliding window with short packets would be better in a potentially noisy environment. But sliding windows work best on a full duplex communication channel, which certain key systems do not provide. It is still possible to do packet windowing on half-duplex connections, but in this case the windows lurch rather than slide -- a batch of packets can be sent, responded to by a batch of ACKs and NAKs. Some random observations: Longer packets are simpler to specify and program. Windowing is harder to specify and program, and for true full duplex operation also requires either multiprocessing (e.g. separate input and output forks) or else interrupt-driven i/o. Long packets need a rigorous error-detection mechanism like the 16-bit CRC. The normal 6-bit checksum just won't do. Windowing with short packets, on the other hand, should work well even with short block checks. Currently during initial connection, two present-day Kermits tell each other the longest packet they are prepared to accept, up to the maximum of 94. Each computer bases this number on some knowledge about its input buffers. But there are also external factors which may be unknown to the computers; for instance, the connection has been made through a public packet-switched network or a local area network whose interface devices might have smaller buffers than the computers themselves. These factors have rarely interfered with original ("classic"?) Kermit, because even its biggest packets are acceptable to most of these devices. But if Kermit is extended to allow transmission of much longer bursts of continuous data, all bets are off. The burden will shift to the (often naive) user to understand the communications environment enough to elect the best parameters and options. The biq question is: Are the benefits in performance worth the cost in complexity for specification, programming, and "user education"? Especially in view of the likelihood that even if adopted, the extensions will probably not be made to more than a few of the existing Kermit programs. Assuming extension is desirable, which extension should be made: long packets, sliding windows, or both? The first proposal follows. The next one will appear in a forthcoming Info-Kermit (most likely the next one). By the way, it should be noted that long packets and windowing should probably be mutually exclusive, since the proposal for windowing (in its present form) expresses window sizes in numbers of packets, assuming the current maximum length. ------------------------------ Date: Mon 15 Jul 85 16:12:44-EDT From: Frank da Cruz Subject: Proposal for Extended Packet Lengths To: Info-Kermit@CU20B.ARPA Keywords: Long Packets A method is proposed to allow the formation of long Kermit packets. Questions as to the desirability or appropriateness of this extension to the Kermit protocol are not addressed. All numbers are in decimal (base 10) notation, all arithmetic is integer arithmetic. In order for long packets to be exchanged, the sender must set the LONGP bit in the CAPAS field of the Send-Init (S or I) packet, and also furnish the MAXLX1 and MAXLX2 (extended length 1 and 2) fields, as follows (the value for the LONGP bit and the position of the MAXLX1,MAXLX2 fields have not yet been settled): ---+-------+- -+--------+--------+ | CAPAS | ... | MAXLX1 | MAXLX2 | ---+-------+- -+--------+--------+ where MAXLX1 and MAXLX2 are each a printable ASCII character in the range SP (space, ASCII 32) to ~ (tilde, ASCII 126), formed as follows: MAXL1 = char(m / 95) MAXL2 = char(m MOD 95) (where m is the intended maximum length), to indicate the longest extended-length packet it will accept as input. The receiver responds with an ACK packet having the same bit also set in the CAPAS field, and with the MAXLX1 and MAXLX2 fields set to indicate the maximum length packet it will accept. The maximum length expressible by this construct is 95 x 94 + 94, or 9024. Since the sender can not know in advance whether the receiver is capable of extended headers, the Send-Init MAXL field must also be set in the normal manner for compatibility. If the receiver responds favorably to an extended-length packet bid (that is, if its ACK has the LONGP bit set in the CAPAS field), then the combined value of its MAXLX1,MAXLX2 fields is used. If the the LONGP bit is set but MAXL1,MAXL2 is missing, then the value 500 will be used by default. If it responds unfavorably (the LONGP bit is not set in the CAPAS field), then extended headers will not be used and the MAXL field will supply the maximum packet length. After the Send-Init has been sent and acknowledged with agreement to allow extended headers, all packets up to and including the B or E packet which terminates the transaction (and its acknowledgement) are allowed -- but not required -- to have extended headers; extended and normal packets may be freely mixed by both Kermits. The normal Kermit packet length field (LEN) specifies the number of bytes to follow, up to and including the block check. Since at least 3 bytes must follow (SEQ, TYPE, and CHECK), a value of 0, 1, or 2 is never encountered in the LEN field of a valid unextended Kermit packet. When extended packets have been negotiated, the LEN field is treated as follows for the duration of the transaction: If unchar(LEN) > 2 then the packet is a normal, unextended packet. If unchar(LEN) = 0 then the packet has a "Type 0" extended header. If unchar(LEN) = 1 or 2, the packet is invalid and should evoke an Error. "Lengths" of 1 and 2 are reserved for future use in Type 1 and 2 extended headers, yet to be specified. A Type 0 extended packet has the following layout: +------+-----+-----+------+-------+-------+--------+---- ----+-------+ | MARK | | SEQ | TYPE | LENX1 | LENX2 | HCHECK | DATA .... | CHECK | +------+-----+-----+------+-------+-------+--------+---- ----+-------+ | Extended Header | The blank length field (SP = char(0)) indicates that the first 3 bytes of what is normally the data field is now an extended header of Type 0, in which the number of bytes remaining in the packet, up to and including the block check, is extended-length = (95 x unchar(LENX2)) + unchar(LENX2) and HCHECK is a header checksum, formed exactly like a Type-1 Kermit block check, but from the sum of the ASCII values of the SEQ, TYPE, LENX1, and LENX2 fields: s = SEQ + TYPE + LENX1 + LENX2 HCHECK = char((s + ((s AND 192)/64)) and 63) Since the value of the extended length field must be known accurately in order to locate the end of the packet and the packet block check, it is vital that this information not be corrupted before it is used. The header checksum prevents this. The extended header, like the normal header itself, is NOT prefix-encoded. This implies that the entity responsible for building packets must leave 3 spaces at the beginning of the data field, form the rest of the packet (encode the data), and then go back and fill in LENX1, LENX2, and HCHECK based upon the data actually entered into the packet, after encoding. Similarly, the packet receiver must allow the extended header to be treated as prefix-encoded data. The packet block check is formed in the usual manner, based on all packet bytes beginning with LEN and ending with the last character in the data field. The block check may be Type 1, 2, or 3, depending upon what was negotiated, but longer packets are more likely to be corrupted than shorter ones and should therefore have higher-order block checks if possible. This proposal does not change the way block check type is negotiated, and does not require that Type 2 or 3 block check be implemented. ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Jul-85 19:24:33-EDT,13170;000000000001 Mail-From: SY.FDC created at 18-Jul-85 19:23:23 Date: Thu 18 Jul 85 19:23:23-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #5 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 18 Jul 1985 Volume 3 : Number 5 Departments: KERMIT PROTOCOL EXTENSIONS - Kermit Extension Proposal Feedback Re: Proposals Checksum versus CRC Kermit Extensions Kermit Extended Packet Lengths Proposal Kermit Protocol Enhancements New vs Classic Kermit MISCELLANY - Re: IBM 3270/PC and Kermit RSX Kermit Warning Kermit for Mac L Running Unix Terminal Emulator w/Kermit: Beta-test Site Query MS-Kermit 2.26 and Hercules Graphik Card ---------------------------------------------------------------------- Date: Thu 18 Jul 85 19:09:55-EDT From: Frank da Cruz Subject: Kermit Extension Proposal Feedback Keywords: Kermit Protocol Proposal The following messages are in response to the first Kermit extension proposal, presented without comment. The second proposal (sliding windows, an effort which is being coordinated by people at The SOURCE Telecomputing) is not quite ready yet, but should appear shortly. If you sent a response that doesn't appear below, send it again -- we lost our file system on CU20B last night and some messages may have been lost. ------------------------------ Date: Tue, 16 Jul 85 02:12:32 pdt From: Scott Weikart Subject: Re: Proposals Keywords: Kermit Protocol Proposal, Sliding Window Kermit, Long Packets I would definitely like to have either sliding window protocol or long buffers, but I'm not sure which one (or if I need both). We're working with some other non-profits to setup long-distance telecommunications between UN*X and MS-DOS machines, and would like to use kermit as our transport mechanism, but we're worried about kermit efficiency with long round-trip times (eg packet-switched networks) or long-distance high-speed modem connections. The packet-networks should be error- corrected so that long packets would seem to make sense, but I don't know if you'll get hing up by buffer sizes in the network (the nets I'm thinking of are Uninet, and maybe Tymnet or Telenet). We may also be using some of the new high-speed pseudo-full-duplex modems, and I don't know enough about their error rates or buffer size factors either; if it's error rate is high and and it doesn't do partition a block and use its own sliding window protocol, it might be good to use half-duplex lurching window with small packets. I'm not so worried that many/most kermits won't be able to handle either extension. For people like us who are interested in using kermit for the transport mechanism of sophisticated telecommunications services, probably only the more capable machines will be considered as part of the system (although one may argue that an MS-DOS machine is not very capable). As for user education about large packets, people could maybe implement an adaptive mode that would try a 1/3 or 1/2 smaller packet each time a transport media truncated a packet. But that's more hairiness. ------------------------------ Date: 15 Jul 1985 1941-EDT From: B.Eiben LCG Ext 617-467-4431 Subject: Checksum versus CRC Keywords: Kermit Protocol Proposal, Checksums I haven't seen a single clear review of the above - I STILL BELIEVE THAT Checksumming of mostly analog based circuits is SUPERIOUR. CRC [ and all quasi-mathematical "analysises" assume BIT-drops] is SUPERIOUR in catching missing BITS [one typically can be "reconstructed" depending on the "polynom" - two or [sometimes more] can be "detected". CHecksumming is good for "detecting" single-bit changes [no chance to "reconstruct" - since the position of the "change" is not known - and [obviously.. only a 50% chance to "catch" double-bit errors].... HOWEVER - and here lays the "settle" difference -- ANALOG CIRCUITS TEND NOT TO DROP BITS - THEY DROP MINIMALLY WORDS and TYPICALLY "SENTENCES" -- AND CHECKSUMMING HAS A HIGH CHANCE TO "catch" these DROPS or MODIFICATIONS - since typically [on ANALOG CIRCUITS] FULL [either ON- or OFF-Bit sequences are substituted] -- this [by the way] also explains my long-standing objection to CRC-protocol in MODEM [acknowledged by the experience - that ON "BAD" lines switching from CHECKSUMMED PROTOCOL to CRC-PROTOCOL DOESN't make a "bit of a difference". - Yeah, I know; there's an even more serious flaw in MODEM- protocol - in that ACK/NAK msgs are NOT encased into "message-protocol" and thereby on a "bad" line MODEM looses typically in ACK/NAK traffic.] Let me clarify [after re-reading] the above SUPERIOUR - it summs up the "expended CPU-time {and number of program instructions}" - as compared to the achieved results {I.e. probability to detect an ERROR}. Rgds, Bernie. ------------------------------ Date: Tue 16 Jul 85 21:07:07-EDT From: Richard Garland Subject: Kermit Extensions Keywords: Kermit Protocol Proposal, Long Packets I perked my ears up at one statement in your introduction to the extensions you outlined: "Each packet must be ACKed" and you even gave an example of a half duplex "lurching" window where a bunch of packets are sent and then a bunch of ACKs are returned. I would suggest two ideas for ACKs that DECnet uses: o ACKing only the last good packet and o piggyback ACKing. In the first case if, packets 9, 10, 11, and 12 are sent successfully, the receiver ACKs 12 and this *implies* 9, 10, and 11 were also good. If 9, and 10 were good and 11 was bad on the other hand, the receiver NACKs 11, and this implies 11 is bad, but 9 and 10 were good. Then the sender resends starting at 11. This scheme allows a lot less reverse traffic. Usually there is a limit on the number of packets that will be sent before getting some ACK but that is the sliding window protocol which you are working out and I won't bother about that part of it. (DECnet uses about 3 versions of it). piggyback ACKing simply means that an ACK or a NAK can be combined with another packet going in the right direction and is relavent for full duplex data streams. Perhaps Kermit will never have full duplex data (as opposed to packets) so this idea may be irrelavent. But if on the other hand you want to send a bunch of packets, then send an END packet, a type of piggybacking would allow the receiver to ACK the last n packets and the END packet all at once. By the way, I don't think sliding windows and large packet extension ideas are mutually exclusive ways to improve performance. ------------------------------ Date: Tue, 16 Jul 85 20:24:42 PDT From: Bruce_A._Cowan%SFU.Mailnet@MIT-MULTICS.ARPA Subject: Kermit extended packet lengths proposal Keywords: Kermit Protocol Proposal, Long Packets Overall this looks pretty good, but I'd recommend a couple of small changes: 1. Change the extended length specification to be simply 12 bits transmitted the same way as the 2-byte checksum. This limits the maximum packet size to 4096 bytes, but that is plenty when the best checksum is CRC-CCITT. It is also as big as any host's usual input buffer as far as I know. 2. Include the LEN byte in the header checksum so that both checksums start at the same byte. Having the header one start 1 byte later than the packet one doesn't make any sense and will confuse the implementator. I believe that the last sentence of the second-to-last paragraph is missing a "NOT". As it stands, it contradicts the first sentence of the same paragraph. (That is the paragraph about the extended header not being prefix-encoded.) Finally, I think there is a small bug in the advanced state table shown in the 3 April 84 protocol manual (there may be a newer one but that is the newest I have). The Send_Gen_Cmd state should allow for receiving an F packet in the case that it was entered from the Send_Server_Init state and sent a R command. That is because the server will, I expect, conclude that it doesn't need to send a S(0) because of receiving and Acking the I(0). (I haven't tried this with a server to be sure, but the Rec_Server_Idle state description sure implies to me that is how the server will work.) ------------------------------ Date: July 17, 1985, 09:15 CEST FROM: <#D15%DDATHD21.BITNET@WISCVM.ARPA> Subject: Kermit Protocol Enhancements Keywords: Kermit Protocol Proposal Hi, I hope my questions are not too late for this stage of the discussion. 1.) which kind of systems would be able to use the large packets? 2.) which kind of systems can afford (pgm size, complexity) the necessary changes to the software? 3.) how does the proposal fit the rules of the early days of Kermit development (to have a simple, cheap to implement protocol for connecting especially small systems)? 4.) where are the ends, or in other words, wouldn't it be better to develop a new protocol with enhanced performance (e.g larger packet, high speed lines, parallel activities on the lines)? Martin Knoblauch TH-Darmstadt, D-6100 Darmstadt, West Germany EARN/BITNET: #D15 at DDATHD21 (the number sign is really part of my UID) ------------------------------ Date: 17 JUL 85 09:34-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: New vs Classic Kermit Keywords: Kermit Protocol Proposal The proposals for large packets (and likely sliding windows) are not going to work out well on pdp-11's as the buffers in all the execs are fairly small, ranging from a max of 36 for rsx, 255 for rsx11m+, 140 for rt, ??? for p/os, and max of about 500 for rsts/e (depending on available small buffer pool). Thus xon/xoff would come into play rather soon. Of course, xonxoff control is no better (much worse,really) that send/ack for each packet. ------------------------------ Date: Mon, 15 Jul 85 12:42:33 edt From: Paul Placeway Subject: Re: IBM 3270/PC and Kermit Keywords: IBM 3270/PC We have been running kermit for IBM PCs and clones for 6 months on our 3270 PC with no problems whatsoever. We run a 9600 baud line between the 3270 PC and our Vax to do file transfers (9600 is very nice, but the Unix version is too slow (no, we havn't gotten the latest version of Unix kermit)). I have one suggestion, however: get a normal PC keyboard for your 3270 PC. The position of ESC, Control, and some other keys is a PAIN. Paul Placeway OSU CIS Dept. Lab ...!cbosgd!osu-eddie!paul paul@ohio-state (CSNet) ------------------------------ Date: 16 JUL 85 09:28-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: RSX Kermit Warning Keywords: Kermit-11, RSX Kermit A problem with RSX Kermit-11 has been resolved in that the outgoing line (via SET LINE) must NOT have the /RPA setting enabled (read pass all). If set, it must be disabled via the mcr command SET/NORPA=TTn: The characteristic is not one that would be normally set. The effect of having it set is to force the terminal driver to pass all flow control (xon and xoff) characters directly to Kermit, which is highly undesirable. The call to disable /RPA will be added to Kermit-11 source in the future. ------------------------------ Date: Tue, 16-JUL-1985 08:55 EDT From: Ronald A. Jarrell Subject: Kermit for Mac L Running Unix Keywords: MacKermit Our CS department is going to be having all incoming freshman purchasing Macintosh-L's with Unipres System V. Has anyone tested, or suspects that one of the flavors of kermit will work under that combination? We plan on setting up some semi-automated software for file transfer for them, and the most desirable alternative would be for them to connect to a VMS Vax that has Kermit on it. -Ron Jarrell Systems Programming Dept, Va Tech ------------------------------ 17-Jul-85 11:36:50-EDT,869;000000000001 Mail-From: EXT1.FUCHS created at 17-Jul-85 11:36:47 Date: Wed 17 Jul 85 11:36:46-EDT From: Michael Fuchs Subject: Terminal Emulator w/Kermit: Beta-test Site Query To: info-kermit@CU20B.ARPA Keywords: Terminal Emulation Would anyone in net.land be interested in beta-testing the latest release of a commercial terminal emulator (full VT102) for the IBM PC incorporating a complete implementation of Kermit? Features include: * Kermit including CRC, server commands, etc. * XMODEM, Proprietary protocols with host software provided * Software (and hardware) 132 column support * Scrolled-off screens capture buffer (80 screens' worth) * Terminate-stay-resident Hot key feature * Programmable softkeys Anyone interested please contact me through net mail or at 212-777-6707. Michael Fuchs Coefficient Systems Corp. ------------------------------ Date: Thu 18 7 85 23:30 GMT From: Eberhard W. Lisse Subject: MS-Kermit 2.26 and Hercules Graphik Card Keywords: MS-DOS Kermit, Hercules Card Have you heard of any problems caused by the Hercules monochrome graphik card on an XT DOS 2.11 ? Since they installed it on our XT, Kermit does not connect any more. [Ed. - Can anyone help?] ------------------------------ End of Info-Kermit Digest ************************* ------- 22-Jul-85 15:18:45-EDT,8780;000000000001 Mail-From: SY.FDC created at 22-Jul-85 15:08:51 Date: Mon 22 Jul 85 15:08:51-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #6 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 22 Jul 1985 Volume 3 : Number 6 Departments: ANNOUNCEMENTS - Kermit-11 User Manual Kermit Distribution Updated on Okstate MISCELLANY - Long Packets and Sliding Windows Kermit Problem with Z100 MS-DOS2 Solved MacKermit 0.8, UNIX C-Kermit Problems Tools for Ascii/Ebcdic Conversion Tables for TSO Kermit MS-DOS Kermit vs Professional Graphics Adapter? ---------------------------------------------------------------------- Date: Thu, 18-JUL-1985 16:53 EST From: Subject: Kermit-11 User Manual Keywords: Kermit-11 I will send two files, K11USR.DOC and .RNO, to you after this; this is the Kermit-11 User Manual, shaped like a Kermit User Guide chapter but written using Runoff rather than Scribe. You folks can do with them what you may, though they should be placed with the rest of the k11 files on cuvma, cu20b, and your vax that you make the tapes on. [Ed. - The files are installed with the other K11 files in K2:K11USR.* on CU20B, and on CUVMA for KERMSRV. Thanks, Brian! ] ------------------------------ Date: 20 Jul 85 00:23:32 CDT (Sat) From: vasoll%okstate.csnet@csnet-relay.arpa Subject: Kermit Distribution Updated on Okstate Keywords: Okstate I have received and installed the latest Kermit tapes (thanks for sending them) on our system. I have moved the distribution area into a more "normal" location (/usr/spool/uucppublic) on our system and I have split it into two areas, one for each tape. The area that was generated from TAPE A (the micro Kermits) is called /usr/spool/uucppublic/kermit-a and the area that was generated from TAPE B (the mainframe Kermits) is called /usr/spool/uucppublic/kermit-b. The default directory for our "kermsrv" login will be changed to /usr/spool/uucppublic/kermit-a and users will be allowed to CWD to /usr/spool/uucppublic/kermit-b. UUCP users will just have to specify the full path (although ~uucp/kermit-a and ~uucp/kermit-b should also work on most systems...). To summarize: - The files that were on TAPE A are in /usr/spool/uucppublic/kermit-a/* - The files that were on TAPE B are in /usr/spool/uucppublic/kermit-b/* - The Kermit server login "kermsrv" has been modified to use the kermit-a area as its default directory and REMOTE CWD /usr/spool/uucppublic/kermit-b will take you to the other area. For those systems not supporting REMOTE commands, the server will also accept full pathnames in GET requests. Mark [Ed. - Thanks Mark, and thanks again for providing this service.] ------------------------------ Date: Fri, 19 Jul 85 09:19:04 EDT From: Brian_Borchers%RPI-MTS.Mailnet@MIT-MULTICS.ARPA Subject: Long Packets and Sliding Windows Keywords: Sliding Windows Kermit, Long Packets We use Kermit here for host to host transfers over Telenet and Datapac, and the long packet extension seems ideal for this purpose. Unfortunately, our operating system (MTS) doesn't really allow asynchronous reads, which might cause problems with a sliding window scheme. I'm interested in seeing the actual proposal. [Ed. - It will appear in the next digest.] ------------------------------ Date: Fri, 19 Jul 85 10:17:49 PDT From: klee@sri-spam (Ken Lee) Subject: Kermit Problem with Z100 MS-DOS2 Solved Keywords: Z100 Kermit Thanks to all those who responed to my request for help with Kermit on MS-DOS2. My version of Kermit worked fine on ZDOS, but failed when I tried to use it with DOS2. Apparently, DOS2 causes the Z100 to drop the data terminal ready (DTR) signal to the modem when Kermit attempts to receive a file. The modem interpets this as a signal to quit and drops the telephone line. By optioning the modem to ignore the DTR signal from the Z100, I now have kermit working properly. Ken Lee [Ed. - Thanks for the pointer; I've placed it in MSZ100.BWR so others can benefit from it.] ------------------------------ Date: Sun, 21 Jul 85 12:24:17 pdt From: westjw%frog@Nosc (Joel West c/o NOSC San Diego) Organization: CACI, Inc. (home of SIMSCRIPT II.5) Subject: MacKermit 0.8, UNIX C-Kermit Problems Keywords: MacKermit, C-Kermit, UNIX Kermit Before I nit-pick, I'd like to say how much I like the keymap program, even if it was only designed for EMACS hackers. :-) I've chosen the assignment BS=^H; Shift-BS=DEL; Ctl-BS, Enter=; although I may change this for vi later. (in BSD, you use ~ and ` a lot, and the Ctl-Shift-~ of MacTerminal is a real pain). [Ed. - Of course, you can have as many different settings files as you like; just double-click the one you want to start up Kermit with the appropriate settings and key map.] Two problems with MacKermit: #1 files never go into folders, always desktop. This must be a "feature", since it's easier to default the file to the disk (FlFldr=0) than to the desktop (FlFldr=-2) [Ed. - Like it says in the manual, they go into whatever folder the settings file was in that you started Kermit from, otherwise on the desktop.] #2 if you receive a file (interactive), toggle disk drives and insert a new disk, it bombs during initialization. The only time this happened was using RAM Disk "RamStart" off of net.sources.mac. [Ed. - This will be added to the beware file.] Also, I'm using the April C-Kermit (BSD 4.2) off of mod.sources. When I upload files from UNIX to the Mac, I'm not getting a size packet -- or at least, the Mac isn't printing the expected size. This is the only thing I like better about MacTerminal than Kermit -- but the keymap and more reliable transfers means I've thrown MacTerminal away. [Ed. - Unfortunately, this requires the sender to include an "attribute packet", which C-Kermit does not yet do.] Keep up the good work. Joel West CACI, Inc. - Federal ------------------------------ Date: Thu, 18 Jul 85 21:18:22 PDT From: VSS7853@UCLAVM Subject: Tools for Ascii/Ebcdic Conversion Tables for TSO Kermit Keywords: TSO Kermit, ASCII/EBCDIC Translation Tables Enclosed are three Fortran 77 programs I wrote as aids to installing TSO Kermit when non-standard TCAM tables are used by MVS to communicate with Ascii terminals. The first two programs, ATOE.FOR and ETOA.FOR take the actual tables used by TCAM, which are obtained from the communication's people at one's installation, and generate assembler source code to replace the tables in Kermit. The third, TCAM.FOR, takes the output of the first two and checks whether the ETOA table is indeed the inverse of the ATOE on the printable subset as required for Kermit to operate. If the test fails, Kermit will not run with the existing TCAM tables. I suspect, however, that so long as all of the Ascii printables map to distinct Ebcdic representations, and so long as the range of the Ebcdic- to-Ascii contains all the Ascii printables, that Kermit could still be made to work by employing an ETOA which is the inverse of TCAM's Ascii-to-Ebcdic, an ATOE which is the inverse of TCAM's Ebcdic-to-Ascii, and an additional ETOA with range contained in the printable subset (and null). This would require a bit of analysis and a modest amount of reprogramming on someone's part but it might add to the number of mvs systems which support Kermit. The listings include actual output which includes an echo of the input. The programs were developed on VAX but the language should be standard 77 except for the Z format extension. I hope this helps someone. Glenn E. Thobe EE dept. UCLA iva3get.uclamvs (bitnet) [Ed. - Listings omitted; they're collected together in K2:TSOETOA.FOR.] ------------------------------ Date: 22 Jul 1985 1354-EDT From: LCG.KERMIT@MARKET Subject: MS-DOS Kermit vs Professional Graphics Adapter? Keywords: MS-DOS Kermit, Professional Grpahics Adapter We are having trouble with MS-DOS Kermit V2.27 on an IBM AT with the professional graphics adapter/display. At speeds above 1200 baud characters are lost in terminal emulation mode. Has anyone else seen this problem? Carl Houseman GENICOM Corporation 703-949-1323 [Ed. - On the IBM PC/AT, terminal emulation is very slow if EGA card is present because the program waits for the vertical retrace operation to complete, which should not be done with the EGA. Apparently the same is true of the Professional Graphics Adapter. Until this is fixed in the next release, EGA (and PGA?) users can patch the routine SCRWAIT in MSYIBM to just return. If anyone with the PGA tries this, please report the results to Info-Kermit.] ------------------------------ End of Info-Kermit Digest ************************* ------- 23-Jul-85 11:22:17-EDT,23765;000000000001 Mail-From: SY.FDC created at 23-Jul-85 11:21:26 Date: Tue 23 Jul 85 11:21:25-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #7 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 23 Jul 1985 Volume 3 : Number 7 Kermit Sliding Window Proposal ---------------------------------------------------------------------- Date: Tue 23 Jul 85 10:30:00-EDT From: Frank da Cruz Subject: Kermit Sliding Window Proposal Keywords: Sliding Windows Kermit This digest presents a proposal from a group at The SOURCE Telecomputing in McLean, Virginia, for a sliding window extension to the Kermit protocol (if you're not interested in protocol issues, skip the rest of this digest). Like other extensions, this one is designed for "upward compatibility" with Kermits that do not support this extension. It may be viewed as an alternative to the long-packets extension proposed in V3 #4, or as complementary to it. The question raised by the latter proposal also applies here: Is the cost in complexity worth the improvement in performance? -- complexity not only in program size and logic, but also in explaining the options to the user: even when Kermit programs implement windowing, when and to what degree should it be used? When must it not be used? The following proposal is not the only way to do sliding windows or to adapt windows to Kermit. The method outlined is certainly not cast in concrete, although Leslie's group is working on some prototype implementations. The proposal is being put forth now to solicit ideas, suggestions, and opinions from the world at large. Some areas to think about include: . What is the effect on the portability of current Kermit programs? Since windowing implies packets flowing in both directions at once, it will be necessary to run separate input and output forks or else to handle packet i/o at interrupt level. Neither of these techniques will be as portable as the simple input-output sequences now used by most Kermit programs. . What will be the effect in the many and varied environments in which Kermit operates, and will operate in the future? These include public networks, satellite links, local area networks, terminal concentrators, TACs, PBX's, high-speed full-duplex error-correcting modems, ATT 56Kb digital service, etc etc. In some cases windowing (or long packets) could boost performance dramatically, in others it could prevent Kermit from working at all. . Does the particular method suggested strike the best balance among improved performance, upward compatibility, and simplicity? Are there obvious simple improvements to the proposed algorithms and heuristics? . Can sliding (lurching) windows be done on half-duplex channels? Are any modifications to the proposal required? This digest will be followed closely by another, which will contain some questions and answers about this proposal. Please read both digests before responding. ------------------------------ Date: Mon 22 Jul 85 11:29:46-EDT From: Leslie Spira Subject: Kermit Sliding Window Proposal Keywords: Sliding Windows Kermit KERMIT WINDOWING PROTOCOL DRAFT SPECIFICATION Hugh Matlock, The SOURCE Telecomputing June 12, 1985 1 INTRODUCTION The windowing protocol as defined for the Kermit file transfer protocol is based on the main premise of continuously sending data packets up to the number defined by a set window size. These data packets are continuously acknowledged by the receive side and the ideal transfer occurs as long as they are transmitted with good checksums, they are transmitted in sequential order and there are no lost data packets or acknowledgements. The various error conditions define the details of the windowing protocol and are best examined on a case basis. There are five stages that describe the overall sequence of events in the Kermit protocol. Three of these stages deviate from the original protocol in order to add the windowing feature. Stages 1 through 5 are briefly described on the following page. The three stages (1, 3 and 4) which deviate from the original protocol are then described in greater detail in the pages that follow. 2 OVERALL SEQUENCE OF EVENTS STAGE 1 - Propose and Accept Windowing The send side requests windowing in the transmission of the Send-Initiate (S) packet. The receive side accepts windowing by sending an acknowledgement (ACK packet) for the Send-Initiate packet. STAGE 2 - Send and Accept File-Header Packet The send side transmits the File-Header (F) packet and waits for the receive side to acknowledge it prior to transmitting any data. STAGE 3 - Transfer Data The sending routine transmits Data (D) packets one after the other until the protocol window is closed. The receiving side ACKs good data, stores data to disk as necessary and NAKs bad data. When the sender receives an ACK, the window may be rotated and the next packet sent. If the sender receives a NAK, the data packet concerned is retransmitted. STAGE 4 - Send and Accept End_of_File Packet As the sender is reading the file for data to send, it will eventually reach the end of the file. It then waits until all outstanding data packets have been acknowledged, and then sends an End-of_File (Z) packet. When the receive side gets the End-of-File packet it stores the rest of the data to disk, closes the file, and ACKs the End-of_File packet. The protocol then returns to Stage 2, sending and acknowledging any further File-Header (F) packets. STAGE 5 - End of Transmission Once the End-of-File packet has been sent and acknowledged and there are no more files to send, the sender transmits the End-of-Transmission (B) packet in order to end the ongoing transaction. Once the receiver ACKs this packet, the transaction is ended and the logical connection closed. 3 PROPOSE AND ACCEPT WINDOWING (STAGE 1) The initial connection as currently defined for the Kermit protocol will need to change only in terms of the contents of the Send-Initiate packet. The receiving Kermit waits for the sending Kermit to transmit the Send-Initiate (S) packet and the sending packet does not proceed with any additional transmission until the ACK has been returned by the receiver. The contents of the Send-Init packet, however, will be slightly revised. The data field of the Send-Init packet currently contains all of the configuration parameters. The first six fields of the Send-Init packet are fixed as follows: 1 2 3 4 5 6 +--------+--------+--------+--------+--------+--------+ | MAXL | TIME | NPAD | PADC | EOL | QCTL | +--------+--------+--------+--------+--------+--------+ Fields 7 through 10 are optional features of Kermit and fields 7 through 9 will also remain unchanged as defined for the existing protocol: 7 8 9 10 +--------+--------+--------+--------+ | QBIN | CHKT | REPT | CAPAS | +--------+--------+--------+--------+ Field 10 is the capability field and requires N number of bytes depending on the number of capabilities defined for kermit. Each bit position of these 6-bit fields corresponds to a capability with the low order bit used to indicate whether or not another capability byte follows. If the low order bit is "1" then another capability byte follows. If the low order bit is "0" then the current byte is the last capability byte. The second through sixth bit positions represent capabilities in the same way. If a bit position is set to 1 then the capability it represents is present. If the bit position is set to 0 then the capability it represents does not exist. Currently, there are only 3 capabilities defined for Kermit as follows: #1 Reserved #2 Reserved #3 Ability to accept "A" packets (file attributes) The windowing capability will constitute a fourth capability and the fourth bit of the capability field will be set to 1 if the kermit implementation can handle windowing. #4 Ability to handle windowing. The remaining fields of the Send-Init packet are either reserved for future use by the standard Kermit protocol or reserved for local site implementations. The four fields following the capability field are reserved for the standard Kermit protocol. We propose the use of field 11 to be used to specify the "Window Size" for all kermits 11 12 13 14 15 16 - N +--------+--------+--------+--------+--------+------------------+ | WINDW | RESV1 | RESV2 | RESV3 | RESV4 | LOCAL Reserved | +--------+--------+--------+--------+--------+------------------+ 11. WINDW - The window size to be used encoded printably using the char() function. The window size may range from 1 to 31 inclusive. The sender will specify the window size it wishes to use and the receiver will reply (in the ACK packet) with the window size it wishes to use. The window size actually used will be the minimum of the two. If the receiver replies with a window size of 0 then no windowing will be done. 4 TRANSFER DATA (STAGE 3) The sequence of events required for the transmission of data packets and confirmation of receipts constitute the main functions of the windowing protocol. There are four main functions which can be identified within this stage. These are: - the sender's processing of the data packets, - the receiver's handling of incoming packets, - the sender's handling of the confirmations, - the error handling on both sides. The following discussion details the specific actions required for each of these functions. Refer to the state table at the end of this document for the specific action taken on a "received message" basis for the full protocol. 4.1 The Sender's Processing of Data Packets The sender instigates the transmission by sending the first data packet and then operating in a cyclical mode of sending data until the defined window is closed. Data to be sent must be read from the file, encoded into the Kermit Data packet, and saved in a Send-Table. A Send-Table entry consists of the data packet itself (which makes convenient the re-send of a NAKed packet), a bit which keeps track of whether the packet has been ACKed (the ACKed bit), and a retry counter. The table is large enough to hold all the packets for the protocol window. Before each transmission, the input buffer is checked and input is processed, as described below. Transmission is stopped if the protocol window "closes", that is, if the Send-Table is full. 4.2 The Receiver's Handling of Incoming Packets The receiver keeps its own table as it receives incoming data packets. This allows the receiver to receive subsequent packets while it is waiting for a re-send of an erroneous or lost packet. In other words, the incoming packets do not have to be received in sequential order and can still be written to disk in order. A Receive-Table entry consists of the data packet, a bit which keeps track of whether a good version of the packet has been received (the ACKed bit), and a retry counter for the NAKs we send to request retransmissions of the packet. The table is large enough to hold all the packets for the protocol window. The different possibilities for a received packet are: 1. A new packet, the next sequential one (the usual case) 2. A new packet, not the next sequential one (some were lost) 3. An old packet, retransmitted 4. An unexpected data packet 5. Any packet with a bad checksum These are discussed separately below. 1. The next new packet has sequence number one past the . The packet is ACKed, and the Receive-Table is checked for space. If it is full (already contains window_size entries) then the oldest entry is written to disk. (This entry should have the ACKed bit set. If not, the receiver aborts the file transfer.) The received packet is then stored in the Receive-Table, with the ACKed bit set. 2. If the packet received has sequence number in the range to then it is a new packet, but some have been lost. (The upper limit here represents the highest packet the sender could send within its protocol window. Note that the requirement to test for this case is what limits the maximum window_size to half of the range of possible sequence numbers) We ACK the packet, and NAK all packets that were skipped. (The skipped packets are those from to ) The Receive-Table is then checked. The table may have to be rotated to accomodate the packet, as with case 1. (This time, several table entries may have to be written to disk. As before, if any do not have the ACKed bit set, they will trigger an abort.) The packet is then stored in the table, and the ACKed bit set. 3. A retransmitted packet will have sequence number in the range to . The packet is ACKed, then placed in the table, setting the ACKed bit. 4. A packet with sequence number outside of the range from to is ignored. 5. If the packet received has a bad checksum, we must decide whether to generate a NAK, and if so, with what sequence number. The best action may depend on the configuration and channel error rate. For now, we adopt the following heuristic: If there are unACKed entries in our Receive-Table, we send a NAK for the oldest one. Otherwise we ignore the packet. (Notice that this will occur in a common case: when things have been going smoothly and one packet gets garbled. In this case, when we later receive the next packet we will NAK for this one as described under Case 2 above.) 4.3 The Sender's Handling of Confirmations The sender's receipt of confirmations controls the rotation of the Send-Table and normally returns the sender to a sending state. The sender's action depends on the packet checksum, the type of confirmation (ACK or NAK), and whether the confirmation is within the high and low boundaries of the Send-Table. If the checksum is bad the packet is ignored. When the sender receives an ACK, the sequence number is examined. If the sequence number is outside of the current table boundaries, then the ACK is also ignored. If the sequence number is inside of the current table boundaries then the ACKed bit for that packet is marked. If the entry is at the low boundary, this enables a "rotation" of the table. The low boundary is changed to the next sequential entry for which the ACKed bit is not set. This frees space in the table to allow further transmissions. When the sender receives a NAK, the table boundaries are checked. A NAK outside of the table boundary is ignored and a NAK inside the table boundary indicates that the sender must re-send the packet. The sender first tests the packet's retry counter against the retry threshold. If the threshold has been reached, then the transfer is stopped (by going to the Abort state). Otherwise, the retry counter is incremented and the packet re-sent. 4.4 Error Handling for Both Sides Three situations are discussed here: Sender timeout, Receiver timeout, and invalid packets. If certain packets are lost, each side may "hang", waiting for the other. To get things moving when this happens each may have a "timeout limit", the longest they will wait for something from the other side. If the sender's timeout condition is triggered, then it will send the oldest unACKed packet. This will be the first one in the Send-Table. If the receiver's timeout condition is triggered, then it will send a NAK for the "most desired packet". This is defined as either the oldest unACKed packet, or if none are unACKed, then the next packet to be received (sequence number ). The packet retry count is not incremented by this NAK; instead we depend on the timeout retry count, discussed next. For either the sender or receiver, the timeout retry count is incremented each time a timeout occurs. If the timeout retry limit is exceeded then the side aborts the file transfer. Each side resets the retry count to zero whenever they receive a packet. In addition, as with the existing Kermit, any invalid packet types received by either side will cause an Error packet and stop the file transfer. 5 SEND AND ACCEPT END_OF_FILE PACKET (STAGE 4) There are several ways to end the file transfer. The first is the normal way, when the sender encounters an end-of-file condition when reading the file to get a packet for transmission. The second is because of a sender side user interrupt. The third is because of a receiver side user interrupt. Both of these cause the received file to be discarded. In addition either side may stop the transfer with an Error packet if an unrecoverable error is encountered. 5.1 Normal End of File Handling When the sender reaches the end of file, it must wait until all data packets have been acknowledged before sending the End-of-File (Z) packet. To do this it must be able to check the end-of-file status when it processes ACKs. If the ACK causes the Send-Table to be emptied and the end-of-file has been reached, then a transition is made to the Send_Eof state which sends the End_of_File packet. When the receiver gets the End_of_File packet, it writes the contents of the Receive-Table to the file (suitably decoded) and closes the file. (If any entries do not have the ACKed bit set, or if errors occur in writing the file, the receiver aborts the file transfer.) If the operation is successful, the receiver sends an ACK. It then sets its sequence number to the End_of_File packet sequence number and goes to Rcv_File state. 5.2 Sender User Interrupt Whenever the sender checks for input from the data communications line, it should also check for user input. If that indicates that the file transfer should be stopped, the sender goes directly to the Send_Eof state and sends an End_of_File packet with the Discard indication. It will not have to wait for outstanding packets to be ACKed. When the receiver gets the End_of_File packet with the Discard indication it discards the file, sets its sequence number to the End_of_File packet sequence number, and goes to RcvFile state. 5.3 Receiver User Interrupt Whenever the receiver checks for input from the data communications line, it also should check for user input. If that indicates that the file transfer should be stopped, the receiver sets an "interrupt indication" of X (for "stop this file transfer") or of Z (for "stop the batch of file transfers"). When the receiver later sends an ACK, it places an X or Z in the data field. When the sender gets this ACK, it goes to the Send_Eof state and sends the End_of_File packet with the Discard indication, as above. When the receiver gets the End_of_File packet with the Discard indication, it discards the file, sets its sequence number to the End_of_File packet sequence number, and goes to RcvFile state. 5.4 LOW LEVEL PROTOCOL REQUIREMENTS The Kermit windowing protocol, as defined in this document, makes certain assumptions about the underlying transmission and reception mechanism. First, it must provide a full-duplex channel so that messages may be sent and received simultaneously. Second, it will prove advantageous to be able to buffer several received messages at the low level before processing them at the Kermit level. This is for two reasons. The first is that the Kermit windowing level of the protocol may take a while to process one input, and meanwhile several others may arrive. The second reason is to support XON/XOFF flow control. If Kermit receives an XOFF from the data communications line, it must wait for an XON before sending its packet. While it is waiting, the low level receive must be able to accept input. Otherwise a deadlock situation could arise with each side flow controlled, waiting for the other. 5.5 KERMIT WINDOWING PROTOCOL STATE TABLE The following defines the inputs expected, the actions performed, and the succeeding states for proposed new Send_Data_Windowing and Rcv_Data_Windowing states. If both sides agree on windowing in the Send Init exchange, then instead of entering the old Send_Data or Rcv_Data states from Send_File or Rcv_File, we enter the new Send_Data_Windowing or Rcv_Data_Windowing. SEND_DATA_WINDOWING Rec'd Msg Action Next State --------- ------ ---------- No input/Window closed (1) Wait for input SDW No input/Window open (2) Read file, encode packet, SDW Place in table, mark unACKed, Send packet ACK/ X or Z (3) set interrupt indicator (X/Z) Send_Eof ACK/outside table -ignore-SDW ACK/inside table (4) mark pkt ACKed, SDW or Send_Eof if low rotate table, if file eof & table empty then goto Send_Eof NAK/outside table -ignore-SDW NAK/inside table (5) test retry limit, SDW re-send DATA packet Bad checksum -ignore- SDW Timeout (6) re-send oldest unACKed pktSDW User interrupt (7) set interrupt indicator (X/Z) Send_Eof Other (8) send Error Abort RCV_DATA_WINDOWING Rec'd Msg Action Next State --------- ------ ---------- DATA/new (1) send ACK RDW if table full: file & rotate store new pkt in table DATA/old (2) send ACK, store in table RDW DATA/unexpected -ignore- RDW Z/discard (3) discard file Rcv_File Z/ (4) write table to file & close Rcv_File if OK send ACK, else Error or Abort Bad checksum (5) send NAK for oldest unACKed RDW Timeout (6) send NAK for most desired pkt RDW User Interrupt (7) Set interrupt indicator X or Z RDW Other (8) send Error pkt Abort ------------------------------ End of Info-Kermit Digest ************************* ------- 23-Jul-85 17:11:31-EDT,16806;000000000001 Mail-From: SY.FDC created at 23-Jul-85 17:10:57 Date: Tue 23 Jul 85 17:10:57-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #8 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 23 Jul 1985 Volume 3 : Number 8 Departments: PROPOSAL FEEDBACK - Sliding Window Proposal, Cont'd Sliding Window Proposal Q & A MISCELLANY - Conversion Tables, Liberalized Requirements More about IBM Professional Graphics Controller (several msgs) Using Kermit with Ungermann-Bass Net One? ---------------------------------------------------------------------- Date: Tue 23 Jul 85 13:12:23-EDT From: Frank da Cruz Subject: Sliding Window Proposal, Cont'd Keywords: Sliding Windows Kermit The proposal in Info-Kermit V3 #7 should have been dated July 19, not June 12, and the formatting of the state table at the end appears to have been messed up -- apologies. The next message (about 10K long) gives some informal information about the proposal in the form of questions and answers. Comments, reactions, suggestions on both the long-packets and the windowing proposals encouraged. ------------------------------ Date: Mon 22 Jul 85 09:30:00-EDT From: Leslie Spira Subject: Sliding Window Proposal Q & A Keywords: Sliding Windows Kermit KERMIT WINDOWING PROTOCOL DRAFT PROPOSED DEFINITION DATED JULY 19, 1985 QUESTIONS AND ANSWERS John Mulligan, The SOURCE Telecomputing July 19, 1985 Q. What is the purpose of the "windowing" extension? A. The object is to speed up file transfers using KERMIT. The increase will be especially noticeable over the data networks (such as Telenet and Tymnet) and over connections using satellite links. This is because there are long communications delays over these connections. Q. How does it work? A. Basically, it allows you to send several packets out in a row before getting the first acknowledgment back. The number of packets that can be sent out is set by the "window size", hence the name windowing. Q. Could you explain in more detail? A. Right now, a system sending a file transmits one packet of data, then does nothing more until it gets back an acknowledgment that the packet has been received. Once it gets an acknowledgment, it sends the next packet of data. Over standard direct-dial land-based phone lines, the transmission delays are relatively small. However, the public data networks or satellite links can introduce delays of up to several seconds round trip. As a result, the sending system ends up spending much more time waiting than actually sending data. With the new windowing enhancement, the sending system will be able to keep sending data continuously, getting the acknowledgments back later. It only has to stop sending data if it reaches the end of the current "window" without getting an acknowledgment for the first packet in the current "window". Q. What size is the "window"? A. The window size can vary depending on what the two ends of the connection agree on. The suggested standard window size will be 8 packets. The maximum is 31 packets. The KERMIT sequence numbering is modulo 64 (it "wraps" back to the 1st sequence number after the 64th sequence number). It is helpful to limit the maximum window size to 31 to avoid problems (ambiguous sequence numbers) under certain error conditions. Q. Is windowing in effect throughout a KERMIT session? A. No, it is only in effect during the actual data transfer (data packets) portion of a file transfer. Windowing begins with the first data packet (D packet type), and stops when you get an End-of-File packet (Z packet type). Q. Why does it stop when you get to the End-of-File packet? A. This is done primarily to avoid having more than one file open at once. Q. Why will windowing be especially helpful at higher baud rates over communications paths that have delays? A. As you increase the baud rate, the transmission speed of the data increases, but you do not change the delay caused by the communications path. As a result, the delay becomes more and more significant. Assume, for example, that your communications path introduces a delay of 1 second each way for packets, for a total delay of 2 seconds round trip. Assume also that your packets have 900 bits in them so it takes you 3 seconds to send a packet at 300 baud (this is roughly equivalent to a typical KERMIT packet). WITHOUT windowing, here is what happens: If at 300 baud you transmitted data for 3 seconds (sending 900 bits), then waited 2 seconds for each acknowledgment, your throughput would be roughly 180 baud. (Total time for each transmission = 5 seconds. 900/5 = 180). Howver, if you went to 2400 baud, you would transmit data for 3/8 second, then wait 2 seconds for an acknowledgment. (Total time for each transmission = 2 and 3/8 seconds). The throughput would increase only to about 378 baud. (900 / 2.375 = 378). The delay becomes the limiting factor; in this case, with this packet size, the delay sets an outside limit of 450 baud (900 / 2 second delay = 450), no matter how fast the modem speed. WITH windowing, the throughput should be close to the actual transmission speed. It should be possible to send data nearly continuously. The exact speed will depend on the window size, length of transmission delays, and error rate. Q. Are there any new packet types introduced by this extension? A. No, the only change is to the contents of the Send-Init packet, to arrange for windowing if both sides can do it. If either side cannot, KERMIT will work as it does now. Adding an extension such as this was provided for in the original KERMIT definition. See section 3 of the windowing definition for details. Q: On the receive side, in section 4.2, why does the definition say that writing to disk is done when the Receive-Table becomes full rather than as soon as you get a good packet? A: The definition was phrased this way because it makes the logic of the receive side clearer and simpler to implement. Actually, you could also write a packet to disk when it is a good packet and it is the earliest entry in the receive table. This approach has the disadvantage that you don't know at this point that the sender has received your ACK, so you have to be prepared to handle the same packet later on if the sender never gets the ACK, times out, and sends the same packet again. Thus you have to be prepared to deal with packets previous to the current window; you will have to ACK such a packet if it has been received properly before. By writing packets to disk only when the receive table becomes full, (the oldest packet) you know that the sender has received your ACK (otherwise the sender could not have rotated the window to the n+1 position to send the current packet, where n is the window size). This makes it very easy to stay in synch with the sender. The disadvantage of this approach is that when you receive the End-of-File packet, you have to take the time to write all the remaining packets in the Receive-Table to disk. Q. Could you briefly explain what happens if a single packet gets corrupted? A. In essence, the receiver will ignore the bad packet. When it gets the next good packet, it will realize (because packets are numbered) that one or more packets were lost, and NAK those packets. The receiver continues to accept good data. As long as the sender's window does not become "blocked", the only loss of throughput will be the time it takes to transmit the NAKed packets. For a full description, see section 4.2 of the windowing definition. Q. There are currently two proposals for KERMIT extensions: the Windowing extension and a proposal for extended packet lengths. What are the relative advantages and disadvantages of sliding windows and extended packet lengths? A. What is best depends on the exact conditions and systems involved in a particular file transfer. There are some general rules however. Windowing helps more and more as the communications path delays get longer. Windowing is also more and more helpful as the baud rate goes up. Increased packet length is most helpful on circuits with low error rates. If the error rate is high, it is difficult for a long packet to get through uncorrupted. Also, it then takes longer to re-transmit the corrupted packet. On some machines, the CPU time to process a packet is relatively constant no matter what the packet length, so longer packets can reduce CPU time. Q. Are extended packet lengths and sliding windows mutually exlusive? A. No, there is no real reason that they would have to be. As a practical matter, it is slightly easier to implement windowing if you know the maximum packet size ahead of time, since you can then just use an array to store your data. In standard KERMIT, you know automactically that your maximum packet length is 94, so you can just go ahead and dimension an array at 94 by Window-size. If you are going to use both extended packet length and windowing, you need to select the maximum packet length and window-size so that the combination does not exceed the available memory for each side of the transfer. In addition, it is possible to see the desired relationship between packet size and windowing for various baud rates and communications delays. For the common case of an error corrected by one retransmission of the corrupted packet, the minimum window size needed for continuous throughput (the window never gets "blocked") can be calculated by: 4 x delay x baud rate WS > 1 + ------------------------ packet-size x 10 ;(this is the # of bits) Windowing always helps (the minimal continuous throughput window size is always greater than 1). In the above equation, the "4" derives from the fact that a corrupted packet has 4 transit times involved: Original (bad checksum) packet NAK for the packet Retransmission of packet ACK for retransmission. All of this must happen before the window becomes blocked. The "delay" is the effective maximum one-way communications path delay, which includes any CPU delays. Strictly speaking, the "packet-size" should have the length of the ACK packets added to it. As an example, if you assume a 2-second (one-way) delay, at 1200 baud, with a packet size of 94, the minimum window size for continuous throughput would be: 4 x 2 x 1200 WS > ------------ = 10.2 94 x 10 Under these circumstances, a window size of at least 11 should be chosen, if possible. ------------------------------ Date: Sat, 20 Jul 85 10:47:19 PDT From: VSS7853@UCLAVM Subject: Conversion Tables, Liberalized Requirements Keywords: ASCII/EBCDIC Translation Tables Regarding the message I sent the other day with the programs for constructing and analyzing ATOE and ETOA tables, I think I could have expressed my thesis a bit more clearly. Kermit-TSO and Kermit-CMS require that the TCAM (or whatever) tables be, loosely speaking, inverses of one another. I claim that this requirement is too restrictive and prevents Kermit from working on systems where it otherwise might. On Ebcdic machines, Kermit performs the following four translations: 1. (e to a) predict the Ascii form of an outgoing message so that a packet can be constructed in Ascii. 2. (a to e) map the packet back to Ebcdic for outputting and final reconversion by TCAM. 3. (e to a) reconstruct the Ascii form of an incoming packet already converted by TCAM, so that the packet can be analyzed in Ascii. 4. (a to e) map the incoming message back into its final Ebcdic form. Presently these four internal transformations are done with only two tables, each identical to the corresponding TCAM table. Whence the requirement that the two TCAM tables be inverses of one another. I claim that by constructing four tables, one for each of the above numbered functions, two benefits would accrue: 1. The requirements on the TCAM tables would be weakened. Each table would have to be invertable separately, but they would no longer have to be inverses of each other. 2. Kermit could guarantee a standard correspondance between the two character codes for messages transmitted from Ascii machines to Ebcdic and vice versa, instead of accepting the correspondance imposed by the local TCAM tables. In the other message I attempted to give precise weakened mathematical requirements for the TCAM tables so that this method would work. Also tools would have to be developed to construct the necessary translation tables to be used by Kermit. These tools ought to be included in the distribution. What do you think? Glenn Thobe EE dept., UCLA 818-888-8434 p. s. Please address replies to both IVA3GET@UCLAMVS and VSS7853@UCLAVM (BITNET). ------------------------------ Date: Mon 22 Jul 85 16:55:26-EDT From: Charlie C Kim Subject: IBM Professional Graphics Controller Keywords: Professional Graphics Card It's called a Professional Graphics Controller (not Adapter). Waiting for the vertical retrace on the EGA isn't a bad thing to do--it's just unnecessary in the enhanced mode. It isn't so clear that it's the wrong thing to do when it is emulating the CGA. The problem with losing characters above 1200 baud on the PGC is well known. The following message from the IBM-PC bulletin board should clarify the issue: Date: Thu, 4 Jul 85 13:54 EDT From: "Roger C. King" Subject: Professional Graphics Controller Fix We have had IBM replace more than a dozen Professional Graphics controllers with corrected units which work correctly with previous communications packages at 9600 baud. The old unit did not work correctly at all, but sort of worked on an AT at 2400 baud (sort of means some dropped characters) and sort of worked on an XT at 1200 baud. It takes an individual, case by case, interface with IBM to get this resolved, but it is possible for a field office to get someone at Boca to send out corrected boards for a swap. A good controller can be recognized as follows: Looking at a controller with the output on the right, the top left corner of the board has a 'REV' number, probably 6323698, whited out with white paint or something similar. A bad board(s), does not have this number modified. As an aside, we have found the Professional Graphics Controller to be an almost perfect emulator of the old Color Graphics controller. Even low-res software seems to work correctly. Roger King ------------------------------ From: Herm Fischer Subject: Professional Graphics Controller Date: Mon Jul 22 16:02:42 1985 Keywords: Professional Graphics Card Carl Houseman reports problems over 1200 baud with this display. He should be aware that the async ports dont work over 1200 at all unless he gets replacement PGA cards from IBM. The original cards had hardware/firmware problems which interfered with comm activity; IBM has "recalled" those cards. I am using the EGA on Xenix and on MSDOS with kermit. So far no problems, but have not tried EGA with MSDOS above 1200... ------------------------------ Date: 23 July 1985 1350-PDT (Tuesday) From: germar@nprdc.arpa (Marcelo Germar) Subject: Using Kermit with Ungermann-Bass Net One? Keywords: Ungermann-Bass Net One Does anybody have experience using ibm pc kermit with ungermann-bass net one to transfer files between a vax with 4.2bsd unix and an ibm pc? What should be the configuration of the ungermann-bass hardware/software to enable a successful file transfer? All your help will be sincerely much appreciated. thanks, marcelo ------------------------------ End of Info-Kermit Digest ************************* ------- 26-Jul-85 17:53:40-EDT,15845;000000000000 Mail-From: SY.FDC created at 26-Jul-85 17:53:06 Date: Fri 26 Jul 85 17:53:06-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #9 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 26 Jul 1985 Volume 3 : Number 9 Departments: ANNOUNCEMENTS - Kermit for the PDP-8 PROPOSAL FEEDBACK - Lurching Windows? About the New Proposals Kermit Windowing Questions and Answers...Continued MISCELLANY - Tranferring a MacPaint or MacDraw Document MS-Kermit and the Hercules Monochrome Graphics Card ---------------------------------------------------------------------- Date: Fri 26 Jul 85 17:07:42-EDT From: Frank da Cruz Subject: Kermit for the PDP-8 Keywords: PDP-8 Kermit This is to announce Kermit-8 for the DEC PDP-8 with OS8 or RTS8, written in the PAL-8 assember by Jerry Sands and Randy Hippe of the Bureau of Engraving, Inc., Minneapolis, MN. It works in local mode only, includes CONNECT, BYE, EXIT, SEND, GET, and RECEIVE commands, and can do wildcard sends. There is no documentation to speak of. The program is in K2:K08MIT.PAL (and .HLP) on CU20B, available via anonymous FTP. This means that Kermit is now available for every single existing DEC machine operating system, with the exception of IAS-11 (soon to be contributed, I hope). (I hope there aren't any PDP-1's, -4's, -6's, -7's, 9's, -12's, or 15's left out there... If you have one, why haven't you written Kermit for it?) And if you count WPS-8 as an operating system, maybe someone who knows something about it could convert this program for the benefit all the poor DECmate users who need to transfer their WPS "documents" to systems that don't have DX. ------------------------------ Date: Thu, 25 Jul 85 12:49:49 pdt From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa Subject: Lurching Windows? Keywords: Lurching Windows I didn't see any discussion of how to extend this to half-duplex lines ("lurching windows"). Is any forthcoming? Ken Poulton [Ed. - See below.] ------------------------------ Date: 24 Jul 1985 1257-EDT From: B.Eiben LCG Ext 617-467-4431 Subject: About the New Proposals Keywords: Kermit Protocol Proposal Yes, I have seen the stuff only "fly by" on the screen - so my comments will be "fast and [maybe] not fully founded". [By the way, I like both proposals and believe, they both will work together.] I would like to introduce the "bulk" ACK from the Receiver [didn't see that mentioned - or "lost it on the screen"], i.e. the Receiver has the freedom to "ACK" every X packets, where X can be between 1 and the agreed upon maximum window-size. Receipt of the "BULK" ACK forces a "sliding" of the SENDER's window, so that it "starts" after receipt with the next packet. The Receiver will discard packets with packet-nr's LESS than current "BULK" ACK and "BULK" ACK minus MAX Window-size. I will regard receipt of packets with even smaller numbers a "serious errror" - i.e. stop receiving. [To be "discussed more" : It might be also a good rule to FORCE an ACK on the last two PACKETS BEFORE crossing the 64-magic to make sure, that the SENDER's window slides nicely..] I believe, that the above rules "get rid" of the receivers duty to keep a "table" plus a relatively large buffer - it also leaves it open for the receiver to "write to the 'disk' whenever he feels necessary" It doesn't complicate SENDER behaviour - but the hightest overall "gain" is anyhow at the 90% of down-loads from distribution-points, which typically are slightly larger than "micro's" - and can afford the "extra" coding. It also [as a side effect] eases handling of "larger packets" on the micro [I just hate to debug the logic of a "floating table" depending on memory- limits {relatively easy} plus "agreed upon" package size {slightly more muggy} aggravated by [either] unexpected RE-Sends because I was too long occupied didling the floppy or expected - i.e. I saw a bad packet , sent a NAK but was not allowed to "throw away the rest". Which leads to an "addendum" for the SENDER - all in the view of keeping the coding EASY for all the micro-versions... On receipt of a NAK - all PACKETS INCLUDING the NAKed one and [maybe already sent other ones] will be re-sent. If we are clever - remember the "bulk" number for the ACK didn't have to be established - we can "train" the receiver to "trim down" the "bulk" number depending on the amount of NAKs per X packets - thereby allowing a "macro" adjustment to line-quality. I will not go into "calculations" - but as a rule of thumb: On SLOW channels [300 Baud] - there typically will be only ONE MORE packet sent after the receiver sees the NAK - and its NOW the msg "Lets redo it after the last good one" - so thats tolerable. On "faster" channels [4800 Baud and UP] - there "might be" another packet "sneaking in" - but "channel quality" typically tends to be better anyhow, so "better quality" and "higher speed" make the overhead of above simplification tolerable again. ... and last not least - one probably can even under CP/M with ist 64K limitation handle both LARGER PACKETS and "floating ACKs" Rgds, Bernie. -------------------------------------- Date: Fri 26 Jul 85 16:50:48-EDT From: Leslie Spira Subject: KERMIT Windowing Questions and Answers...continued. Keywords: Sliding Windows Kermit FORWARD: The two proposed extensions to KERMIT, Windowing and Extended Packet Length, are both useful. They seem to me to be complementary, and each solves certain problems that the other cannot. The purpose for the development of the windowing protocol was to solve the problem of how to increase throughput over circuits with long delays that also had a potentially noisy section of the circuit. The discussion of the Windowing protocol, and of Extended Packet Lengths, should keep in mind the environments in which each would be useful. In some cases, a combination would provide optimum performance. The extensions will only be implemented for situations that make sense. In all cases, KERMIT Classic will still be available, with all its utility of being able to handle varied enviroments. While reading the following questions and answers, keep in mind that this windowing definiton was developed to handle a common situation of long circuit delays with possible moderate error rates. KERMIT does not need this type of extension for clean lines with insignificant delays - KERMIT could be left alone, or use Extended Packet Lengths, in such environments. Long delays with significant error rates will occur under two obvious and common conditions: A. Local phone line (of uncertain quality) to Public Data Networks (such as Telenet). B. Satellite phone links. These often occur with the lower-priced phone services, which often also have noisier lines. In addition, satellite links will increase as more people need to transfer data overseas. The above conditions will become more common, as well increased baud rates, which make the delays more significant. As an aside, note that the benefit of Extended Packet Lengths over the Public Data Networks is limited by the number of outstanding bytes the PDN allows. (Internally, the PDNs require end-to-end acknowledgement. They use their own windowing system within the network.) I don't currently know the exact impact of this. Now on to the questions... Q. Can sliding windows be done on half-duplex channels? Are any modifications to the proposal required? A. An underlying assumption in the development of windowing was that there was a full-duplex channel. (See section 5.4, "Low Level Protocol Requirements") The intent of windowing is to try to keep the sender continuously sending data. Obviously, this is not possible on a half-duplex channel. A better solution for half-duplex channels would be to use an extended packet length. An attempt to use windowing on half-duplex really is just a way of doing extended packet lengths. The sender would send out a group of packets, then wait and get a group of ACKS. It would be better to simply send out a large packet, which would have less overhead. Q. Is the cost in complexity for sliding windows worth the increase in performance? A. Under the conditions described above (long delays and possibly significant error rates) windowing can increase performance by a factor of 2, 3, or more, especially at higher baud rates. This increase is necessary to make KERMIT viable under some conditions. With classic KERMIT over the Public Data Networks, I have had througput as low as 250 baud over a 1200 baud circuit (with a negligible error rate). Windowing should allow throughput close to the maximum baud rate. Windowing is most helpful when the delay is significant in relation to data sending time. Any delay becomes more significant as users move to higher baud rates (2400 baud and beyond). The complexity of implementing windowing has yet to be fully evaluated. The first implementation (for the IBM PC using C-KERMIT) proved to be fairly manageable. It appears that the windowing logic can be implemented so that KERMIT Classic uses the same code, but with a window size of 1, which should avoid having to keep separate sections of code. The windowing definiton was developed with the idea of keeping changes to KERMIT to a minimum. No new packet types were developed, ACKs and NAKS were kept the same, and windowing is in effect only during actual data transfer (D packets). We tried to define the protocol so that a window size of 1 was the same as the current classic KERMIT. These factors should help reduce the complexity of implementing windowing. We currently have a working implementation of KERMIT for the IBM PC going through testing. It's fun to see the modem "Send" light stay on constantly! Q. Why doesn't the Windowing proposal use a "bulk ACK"? A. There are a couple of possibilities for ways to use some sort of "bulk" or combined ACK. We looked at them when developing the Windowing definition. We did not see any advantages that outweighed the disadvantages. Here are two possible ways of changing how ACKs would work: 1. An ACK for any packet would also ACK all previous packets. 2. A new "Bulk ACK" (BAK?) packet could be developed. 1. The concept that an ACK would also ACK all previous packets seems attractive at first, since it would appear to reduce overhead. However, it has a major drawback in that you then must re-synch when you get errors. This is because, once you have an error, you have to send a NAK, then stop and wait for a re-transmission of the NAKed packet, before you send out any more ACKs. (If you sent out an ACK for a later packet, it would imply that you had received the NAKed packet. Not until you safely get the re-transmission can you go ahead.) This would negate one of the nicest parts of windowing as it is defined now, which is that the sender can transmit continuously, including during error recovery, as long as the window does not become blocked. It does not appear to us that the reduction in the number of ACKs sent is worth this penalty. In addition, this is a departure from the way ACKs in KERMIT work now. It seemed best to make as few changes to KERMIT as possible. If this facility turns out to be useful, it would be better to introduce a new packet type (or other means of distinguishing regular ACKs from "Bulk ACKS"). 2. A new "Bulk ACK" packet type could be developed. This did not seem to us to be a good idea, since it required defining a new packet type. We were trying to fit windowing in with as few changes to KERMIT as possible. A "Bulk ACK", in which one packet could contain a whole string of ACKs and NAKs, also seems like a good idea at first. The penalty here is a little more subtle. First, if you lose a "Bulk ACK" packet, you lose more information and it takes longer to get things flowing smoothly again. Second, and probably more importantly, efficient windowing depends on the window never becoming "blocked" (i.e., the sender can always keep sending). A "Bulk ACK" interferes with this to some extent, because if you have a long delay, the "Bulk ACK" with its multiple individual ACKs may not get back to the sender in time to prevent the window from becoming blocked. With the current definition of windowing, returning an ACK for each packet gets the ACKs (or NAKs) to the sender as soon as possible. This provides the best chance for keeping the window open so that the sender can transmit continually. Once again, remember the conditions under which windowing is most useful: long delays with significant error rates. Under these conditions, individual ACKs have advantages. If these conditions don't apply, it may not be necessary to use windowing, or it may be better to use extended packet lengths. ------------------------------ Date: Thu, 25 Jul 85 16:41:22 PDT From: ucsfcca.ucsf!jd9014@ucsf-cgl.ARPA (Joe DeBattista) Subject: Tranferring a MacPaint or MacDraw Document Keywords: MacKermit I have a question about whether it is possible to upload and/or download a MacPaint or MacDraw document. When I use macput or macget with Versaterm or MacTerminal this works ok, as it seems to grab the data and resource files together. When I try to upload to our VAX 750, I can only specify the data or resource from the settings menu. When I try to download a macpaint document, I tried sending the data file first and then the resource, but that didn't work. I've checked the MacKermit documentation for hints, and have asked people around here if they have a solution. I am currently running version 08(32). Thanks. Joe DeBattista BITNET: jd9014@ucsfcca UUCP: ucbvax!ucsfcgl!ucsfcca.ucsf!jd9014 [Ed. - It says somewhere in the Mac Kermit documentation that you can only send one fork of a file at a time. I think what you need to do is send each fork separately, giving each a different name (like FOO.DATA and FOO.RSRC). When bringing them back to the Mac, get the two files separately, each into the appropriate fork of the same file. I realize this is less than satisfactory, but Kermit was not designed to anticipate that a file could actually have more than one part; the other programs you mentioned are Mac-specific and designed to know about this. In general, I think the safest way to treat arbitrary Mac files is to run them through Binhex before transmitting to a foreign system, and unBinhex them upon return.] ------------------------------ Date: Tue, 23 Jul 85 19:17:35 BST From: Ljwu@ucl-cs.arpa Subject: MS-Kermit and the Hercules Monochrome Graphics Card Keywords: MS-DOS Kermit, Hercules Graphics Card In response to query on MS-KERMIT with the Hercules card (vol 3 #5), I must say that I have encountered no problems, at least with version 2.27. Our configuration is an XT, DOS 2.10, and a fully populated QuadRam expansion card. We dedicate 360K to a RAM disk using AST support though. Good luck! Les Wu ------------------------------ End of Info-Kermit Digest ************************* ------- 31-Jul-85 12:01:33-EDT,11240;000000000000 Mail-From: SY.FDC created at 31-Jul-85 12:00:20 Date: Wed 31 Jul 85 12:00:18-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #10 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Wed, 31 Jul 1985 Volume 3 : Number 10 Departments: ANNOUNCEMENTS - Summer Vacation Release 4C(057) of C-Kermit for Unix Update of Pascal/VS Kermit for IBM VM/CMS PROPOSAL FEEDBACK - Windows Considered Harmful Re: The New Proposals MISCELLANY - DDJ Article on Asynchronus Protocols TTSynch in VMS kermit VMS-Kermit and VMS 4.0 Bug in Prime Kermit Shows Up with Kermit-MS 2.28 Generic CP/M-80 Kermit Question (& Answer) Kermit-11 and IAS ---------------------------------------------------------------------- Date: Wed 31 Jul 85 11:18:21-EDT From: Frank da Cruz Subject: Summer Vacation After this week, I'll be on vacation until the first week in September. While I'm gone, some of the other people at Columbia will moderate the Info-Kermit digest as time permits (we're all quite busy on other projects). Let's keep the discussion of long packets and sliding windows going and see if some concensus will emerge. Meanwhile, address all Kermit-related correspondence to Info-Kermit@CU20B or Info-Kermit-Request@CU20B, not to me personally, so that it can be routed to whoever is handling the digest while I'm gone. - Frank ------------------------------ Date: Mon 29 Jul 85 20:15:03-EDT From: Frank da Cruz Subject: Release 4C(057) of C-Kermit for Unix Keywords: C-Kermit, UNIX Kermit This is to announce Yet Another Release of C-Kermit for Unix, 4C(057). The changes, like last time, are minor: . "set send packet-length" now overrides negotiated value, so that packet lengths in both directions can be controlled from one side. . The Unix Kermit server now responds to all generic commands (but not "remote host" commands) in text mode, even if the file type is currently set to binary. Remote host commands continue to obey the file type setting. . Support for 4.1BSD, 2.9BSD, and BBN C/70 that was apparently broken in recent edits is (or should be) fixed again. . A bug that sometimes prevented 14-character filenames on non-4.2bsd systems from being recognized is fixed. . Several other bugs fixed relating to modem control, dialing, etc. But reportedly some problems still remain -- see the .BWR file. Thanks to Herm Fischer and Dan Schullman for reporting and/or fixing the bugs corrected by this release. The files are in K2:CKU*.* and K2:CKC*.* on CU20B, available via anonymous FTP. CKUKER.UPD lists the changes in greater detail, CKUKER.BWR lists the known bugs and restrictions, CKUKER.DOC (and .MSS) is an updated Kermit User Guide manual chapter. This should be the last release of C-Kermit until some time in September. In the meantime, send suggestions, comments, complaints, bug reports and fixes to Info-Kermit@CU20B, as usual. ------------------------------ Date: Mon, 29 Jul 85 11:23 EDT From: VIC@QUCDN.BITNET Subject: Update of Pascal/VS Kermit for IBM VM/CMS Keywords: VM/CMS Pascal Kermit I have made a few changes to the Pascal/VS version of Kermit-CMS to correct a few bugs. So I am sending you updated source code for it. Victor Lee, Queen's University [Ed. - The updated program is in K2:CM2MIT.*.] ------------------------------ Date: Tue, 23-Jul-85 11:44:51 xDT From: (anonymous) Subject: Windows Considered Harmful Keywords: Sliding Windows Kermit The windowing stuff looks far too complex; I think it will greatly decrease one of the Kermit's main points -- its fundamental simplicity. The interrupt stuff to make such things work can be a tremendous pain on many systems, and it really is probably not worth the effort. Large packets are OK, but I don't think people are going to see as much of an advantage as they think, even on long hauls. With every one of these mods, things get a little less compatible and a little less universal. I personally think that efforts in this area are starting to show signs of "feature-itis" that would best be avoided. ------------------------------ Date: Sat, 27 Jul 85 00:48 EDT From: Bakin@MIT-MULTICS.ARPA Subject: Re: The New Proposals Keywords: Kermit Protocol Proposal, Sliding Windows Kermit, Long Packets Hi. I vote for both proposals, in my environment I can use both, though probably separately. The sliding window proposal would be great for our communications Boston -> Tymnet -> Transpac -> Versailles which is plagued by long long delay ... and won't allow long packets either. Meanwhile, in house our poor VAX is swamped when Kermit is going at 9600 baud due to its lousy TTY input interrupt handling (per character) and at least long packets would reduce the number of task switches and I suspect lead to better interactive performance for the non-Kermit users. Assuming of course it'll eat a long package without losing characters ... that remains to be tested. [Anyway, the easiest way to test it would be for someone else to implement long packets in Kermit and then ...] I wanted to point out that although in kermit-digest V3 #9 it was mentioned that long packets wouldn't be good given fast error-free communication I disagree: I think timesharing hosts would benefit by the fewer task switches from OS read to application Kermit. -- Dave (Bakin -at mit-multics) ------------------------------ Date: Wed 31 Jul 85 01:28:11-PDT From: Bob Larson Subject: DDJ Article on Asynchronus Protocols Keywords: Asyncronous Protocols Kermit is mentioned in the article "Asynchronous Protocols" in the August 1985 issue of Doctor Dobbs Journal. The article is an overview of several asyncronous protocols. It does state "It [Kermit] may become a widely used standard in the near future," but devotes much more space to discussing versions of [x]modem[7]. Bob Larson ------------------------------ Date: Mon, 22 Jul 85 09:11:50 edt From: Steve Archer Subject: TTSynch in VMS kermit Keywords: VMS Kermit We find here locally, that we have to do a 'set term /noTTSynch' before we use the VMS kermit with any half duplex machine that uses Xon/Xoff protocol. Apparently the machines that VMS kermit was written for are that way by default. Having to do the set term confuses many of our casual users of kermit. Kermit could very easily do this automatically for the user. Could this be incorporated in the next VMS kermit release? steve {seismo,allegra}!rochester!kodak!archer ------------------------------ Date: Thu, 25 Jul 85 09:33:31 edt From: Subject: VMS-Kermit and VMS 4.0 Keywords: VMS Kermit VMS-Kermit (Version 3.1.066) was running fine under VMS 3.6, but shows annoying habits under 4.0: in connect mode, long outputs from the remote host are echoed by ^G (BEL) (going to the remote host). This obviously confuses the remote host. I conjecture that the bell is the same as the one now heard on logging in. (We set the line protections of regular terminal lines so that they can be allocated by WORLD.) I would be grateful for any suggestions. Henning Schulz-Rinne Univ. of Cincinnati ------------------------------ Date: Friday, 26 Jul 85 17:11:47 EDT From: rmcqueen (Robert C McQueen) @ sitvxb.CCNET Subject: Re: VMS Kermit Problems Keywords: VMS Kermit Ok, noted. First person to have free time will look into them. ------------------------------ Date: 26 Jul 85 09:15:06 ADT From: CGP@UNBMVS1 Subject: Bug in Prime Kermit Shows Up with Kermit-MS 2.28 Keywords: Prime Kermit, MS-DOS Kermit Prime Kermit can not be used in server mode with Kermit-MS 2.28. The problem is that Prime kermit NAKs the Init-Info packet, instead of responding with an Error packet as specified in the Protocol Manual. Kermit-MS 2.26 does not seem to use the Init-Info packet, and did work with Prime Kermit. I have not tested it with 2.27. I have modified Prime Kermit to honor the Init-info packet. What is the best way to forward the corrected source? Carl Pottle University of New Brunswick Saint John, N.B. Canada CGP@UNBMVS1 [Ed. - Just send the new code by electronic mail to Info-Kermit@CU20B.] ------------------------------ Date: 16 Jun 1985 11:33:08 EDT (Sunday) From: Tom Reid (MS W932) Subject: Generic CP/M-80 Kermit Question Keywords: CP/M-80 Kermit To make a long, sad story short, I have an Ithaca Intersystems Z80/CPM system with an interrupt driven serial board. This makes the usual direct port addressing schemes of communication packages impossible to install. Generic Kermit's only requirement of an installed IOBYTE seemed a perfect solution. However, Kermit goes direct to the devices crt:, tty:, etc. rather than at the virtual CON:, RDR:, and PUN:. I have tried to hook the II to a Kaypro 2x direct connect through the modem port and with the KP being the II's terminal. (As a terminal, it is fine, but cannot establish communication when a file transfer is initiated). Any ideas of how to proceed from here? Thank you in advance for your help. Please reply directly to me as I am not on the info-kermit mailing list. If there is interest, I will summarize and post any replies and solutions to info-kermit. Tom Reid. ------------------------------ Date: 27 Jul 1985 00:12 PST From: Charles Carvalho Subject: Re: Generic CP/M-80 Kermit Question Keywords: CP/M-80 Kermit Generic Kermit has to know what physical devices are in use because the only way it can test the modem port for data available is to make it the console and use the "get console status" bdos call. The console port and the modem port must be different ports; if your system doesn't have a builtin console, you'll need a terminal connected to the console port, and the Kaypro connected to the serial port. Given the physical device names (TTY/CRT/UC1/PTR/etc) of the console port and the serial port, the proper argument for the SET PORT command may be found in the CP/M Kermit chapter of the User's Manual. /Charles ------------------------------ Date: 30 JUL 85 10:52-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: Kermit-11 and IAS Keywords: Kermit-11, IAS Status of Kermit-11 for IAS v3.1: I have just talked with an EPA site and they plan to have Kermit-11 running on IAS 3.1 by Sep 1. This version of Kermit-11 will not be able to do wildcard file operations (at least at first) and some of the mcr/dcl interface will be lost. Addtionally, sources will be separate from Kermit-11's source as IAS 3.1 does not support some of the assembler directives I used thus forcing the EPA to merg some source files and make other minor (but very numerous) changes. They are working from a very recent copy of Kermit-11, so there should otherwise be a good measure of compatibility. brian nelson brian@uoft02.bitnet ------------------------------ End of Info-Kermit Digest ************************* ------- 1-Aug-85 14:51:21-EDT,23882;000000000001 Mail-From: SY.FDC created at 1-Aug-85 14:48:27 Date: Thu 1 Aug 85 14:48:26-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #11 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 1 Aug 1985 Volume 3 : Number 11 SPECIAL SLIDING WINDOWS ISSUE -- Comments on Comments on Lurching Windows Sliding Windows -- When to Write to Disk? Mutual Exclusivity of Sliding Windows and Long Packets? Implied ACKs, Half Duplex Windows Full-Duplex Windowing vs CP/M, et al Proposal for Half Duplex Windows Examination of Proposals Full Duplex Sliding Windows -- Let's Give Them a Try ---------------------------------------------------------------------- Date: Sun, 28 Jul 85 21:32:40 pdt From: "Scott Weikart; Community Data Processing; 415-322-9069" Subject: Comments on Comments on Lurching Windows Keywords: Sliding Windows Kermit > Date: Fri 26 Jul 85 16:50:48-EDT > From: Leslie Spira > Subject: KERMIT Windowing Questions and Answers...continued. > > The intent of windowing is to try to keep the sender continuously > sending data. Obviously, this is not possible on a half-duplex > channel. A better solution for half-duplex channels would be to use > an extended packet length. > > An attempt to use windowing on half-duplex really is just a way of > doing extended packet lengths. The sender would send out a group of > packets, then wait and get a group of ACKS. It would be better to > simply send out a large packet, which would have less overhead. Actually, this is not quite true. If the channel is noisy, then longer packets won't increase the data rate. Tha advantage of a lurching window scheme is that the receiver could NAK all the small packets that didn't make it, and then the sender could resend the NAKed packets plus some new packets in the next bundle. I think that lurching windows would be a good idea. -scott ------------------------------ Date: Thu, 850725 15:11:20-EDT From: Peter Marshall <21-111@uwo-d10.UWO> Subject: Sliding Windows -- When to Write to Disk? Keywords: Sliding Windows Kermit I would like to add a question to the group produced by John Mulligan produced in a recent Kermit-digest. I wonder if someone could explain why it would be so much more difficult to write a received packet to disk, when you have correctly received it? His explaination does not make sense to me. Just because you write a packet to disk does not mean that you have to clear it from the receive table at that time. When you actually clear the oldest message from the receive table for a new message, then you can be assured that the sender has received the ACK. So I don't see his argument about keeping things synchronized. The ACKed flag in the table could also act as a "written to disk" flag. Is it not a little unsafe to assume that you have received a packet correctly (and send off an ACK to that effect) until you have actually got it safely to disk? ------------------------------ Date: Tue, 30 Jul 85 20:41:16 EDT From: RAF@UMDC.BITNET Subject: Mutual Exclusivity of Sliding Windows and Long Packets? Keywords: Sliding Windows Kermit, Long Packets I'm not sure that I understand what was meant by long packets and sliding windows being mutually exclusive. If it means that both would not be used at the same time, that seems fairly reasonable (although packets a bit longer than 96 characters wouldn't seem to be especially harmful). If it means that only one of the two proposals should be adopted, I disagree. They are not technically incompatible and each solves some problems that the other does not. Sliding windows are best if the environment can support them. However, some major systems, such as the IBM 370 (TSO and, I think, CMS), do not support the necessary full duplex channel. TSO, at least, will support long packets. The UCLA File Transfer Package sucessfully uses a 1K packet size on TSO and CMS (using their own protocol). We very much want improved Kermit performance, but will never be able to support sliding windows on our TSO system. On the other hand, we also have a DECsystem-10, which can support sliding windows. Those users would benefit from the extra performance of sliding windows over long packets. Lurching windows for half duplex channels were not addressed in the sliding windows proposal. It seems like sender and receiver would have to agree on how many packets would be sent before the receiver would acknowledge. The sender would have to know not to try to send more packets until the previous group was acknowledged. I suppose that this number could be the window size. Also, in a lurching windows environment, a way to acknowledge multiple packets would be beneficial, as acknowledgements are not overlapped with data. The main difference between lurching windows and long packets seems to be that lurching windows have more overhead bytes and that less data might be retransmitted in case of an error. One further point on lurching windows: I'm pretty sure that TSO would require a delay of a charcater time or more between packets so that they would be recognized as separate "lines" of input. Otherwise, I think that everything after the carriage return at the end of the first packet would be lost. Also, when TSO detects a parity error it sends out a transmission error message, which means that it would not be listening for the following packet, so it would be lost too. All in all, I think long packets are better for half duplex channels and sliding windows are better for full duplex. In the sliding windows proposal, I do not understand why the sending of the end of file packet is delayed until all previous packets have been acknowledged. It seems to introduce an unnecessary delay. Both proposals are optional -- no one would have to implement either, if they don't care about the improved performance or want to defer the additional complexity to a later version of their Kermit. ------------------------------ Date: Sat, 27 Jul 85 18:18:19 pdt From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa Subject: Implied ACKs, Half Duplex Windows Keywords: Sliding Windows Kermit, Long Packets I have two comments on Leslie's Q+A in info-kermit #9. On implied-ACKing: Leslie states that getting a NAK forces the protocol to stop sending. I don't agree. There's no reason for the sender to stop sending just because a NAK came. The retry for the NAK'ed packet can be inserted (ASAP) into the stream of first-try packets. ACK's for packets successfully received after the NAK'ed packet will have to wait until the NAK'ed packet is successfully received. But this does *not* change window requirements: the window has to be long enough to cover the time for NAK and retransmission of packets anyway. Note that although ACK's must wait until all packets up to that point have been received correctly, NAK's for unsuccessful packets can be sent as soon as they are detected as being unsuccessful, i.e. upon successful receipt of the following packet. This will help keep the protocol running smoothly. The only penalty is that since ACKs will be bunched by the receiver, the window must be longer by the number of packets implied by each ACK to keep the window from filling. On windows in a half-duplex environment: This is dismissed as being just long packets, with the implication that one should just use long packets in a half-duplex environment. This is not true! Half-duplex connections have exaclty the same problem: how to get good efficiency over long-delay + moderate error rate connections. I would like to have half-duplex sliding windows seriously considered! Ken Poulton hplabs!poulton I know it's dumb, but half-duplex is the way many systems work... ------------------------------ Date: 27 Jul 1985 1334-EDT From: B.Eiben LCG Ext 617-467-4431 Subject: Full-Duplex Windowing vs CP/M, et al Keywords: Sliding Windows Kermit, CP/M-80 Since KERMIT-protocol has been invented and is successfully used in data transfer between "micro's" and larger machines, let me take a look at the "windowing" proposal as seen from the "micro's". As is probably known, none of our current 'Van Neuman' machines can handle more than one task at any given instant of time. The illusion of 'time-sharing' and 'multi-tasking' or even 'multi-processing' are only possible with the existence of a sophisticated interrupt-structure [typically combined with 'hardware assisted' context-switching] and software delivering the book-keeping services. The currently most 'popular' micro-systems [CP/M and MSDOS or derivatives] are SINGLE-tasking systems. Although the used micro-processors typically support a basic interrupt-structure, the lack of buffered and hardware assisted I/O devices limits the interrupt-structure basically to ERROR intercepts and clock-service. -- Or in laymans terms, "A typical micro CANNOT accept characters on the Input-port, as long as its reading or writing to the floppy". How, might You ask, did MODEM or KERMIT survive this basic flaw at higher communication speeds ?? -- Very easily with a "trick" in ACKing a received packet ONLY AFTER it had been written to storage [ - thereby making sure, that NOTHING {except NOISE} could arrive at the input-port - and therefore nothing could be lost ]. In view of these "basics", I would like to treat a "Window of Packets" as one Very Large Packet, which just happens to be sliced into smaller packets for ease of error-recovery. And the micro only has to make sure, that it can store the combined DATA-content of the Window in a buffer. Following Frank's concerns of portability, I would like to propose "fixed" windows ["fixed" in their "agreed upon" starting packet-Nr and their size - in contrast to "sliding windows" , where an ACK for the first packet in a window of packets can slide the starting-point downwards]. In comparison to the "large packet" proposal this technique is probably of more immediate interest to micro-users since: a. Most Communication media are NOT totally error-free b. Most micros are quite limited in sustaining any baud-rate above 4800 Baud between Communication-Port and File-storage [ infact some have even problems to sustain above rates between Comm-Port and terminal]. Here the "changes" in detail: 1. Extend current KERMIT-Heuristic that "A NAK for the current packet is an implied ACK for the previous one" to "A NAK for the current packet is an implied ACK for all previous packets inside the current window". 2. Introduce a rule, that the next [ fixed ] window of packets can ONLY be sent, AFTER receipt of the LAST packet of the previous window has been ACKed. [This will guarantee the needed "silence on the input-port" during 'buffer-write to file-storage' on the micro.] 3. Change the proposed Error-Recovery rule to "On a receipt of a NAK the SENDER will re-send packets starting with the NAKed one". [This will remove the need to keep a "transfer-table" AND make re-synchonisation possible for the micro without hefty recoding]. I believe, that with above changes, we only encounter a minimal "extra overhead" in case of error-retransmission - probably NO extra overhead time-wise at all , if the MAIN-Kermit can be written to be effectively "interrupted" by receipt of a NAK from the micro - if he only can check for NAK's between sending of packets, we'll incur a slight degradation timewise as compared to the current protocol - since the NAK probably will arrive in the middle of a not fully sent packet, which has to be re-sent again according to the above changed rules. We will however enjoy even "faster" transmission in the more prevailing case of having NO ERRORS, since the single ACKs for each packet collapse into a single ACK per window - and we will enjoy the same savings [or better] on packet-based channels. Rgds, Bernie. ------------------------------ Date: Sat, 27 Jul 85 18:18:41 pdt From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa Subject: Proposal for Half Duplex Windows Keywords: Sliding Windows Kermit, Long Packets A quick proposal for half-duplex sliding windows: Kermit negotiates both packet size and super-packet size (i.e., N packets per super-packet, where N should be less than half the window size). The sender then sends <=N packets, then the end-of-line character to delimit end-of-super-packet (NO end-of-line chars inside the super packet - this is a must for half-duplex receivers). The receiver sends back a super packet of ACKs and NAKs. This could use either the implied-ACK scheme discussed above, or an explicit ACK or NAK for each packet in the super-packet. The implied-ACK scheme has the advantage that, on clean lines, the returning super-packet consists of just one ACK packet. The sender then sends the next super-packet, starting with the outstanding NAK'ed packets, and filled up (to N packets max) with new (first-time) packets. This kind of protocol can't obtain the efficiency of the full-duplex sliding window protocol, since it must incur an overhead of one round-trip delay per super-packet. This can, however, still gain a factor of 2 or 3 over the current situation with 1200 baud lines with 2 second round trip delays. It's *essential* for improvement over poor half-duplex connections where the error rates preclude getting long packets to work at all. I think what I have outlined is close enough to the full-duplex sliding windows to allow them to coexist in the same code. All the full-duplex version needs to do is: 1) negotiate half-duplex status and super-packet size along with window size (maybe we can negotiate handshake at the same time?) 2) bunch packets without end-of-lines to form a super-packet 3) wait for the replying super-packet before sending the next. Another advantage to allowing this half-duplex option is that this opens up greater flexibility for the implementation of sliding window Kermits, since this protocol can be implemented without multiprocessing. This might make it a good choice for non-multi-processing systems or systems which make that difficult. Ken Poulton hplabs!poulton ------------------------------ Date: Thu 1 Aug 85 12:44:55-EDT From: Leslie Spira Subject: Examination of Proposals Keywords: Sliding Windows Kermit, Long Packets Dear Frank, Hugh Matlock and I sat down last night and studied in detail the discussion about the proposed extensions. It seemed to us once again that there is a fundamental difference between full-duplex environments and half-duplex environments. Looking at it, it appears that the problems in half-duplex can best be solved by a large packet size with smaller sub-units that can be NAKed and retransmitted as necessary. The attempts to modify windowing all ended coming around to this concept. We looked at three things that indicated this: 1. Ken Poulton's suggestion of a way to do "super-packet" half-duplex (message dated July 27). This is a effectively a super-packet with segmentation. Hugh agrees with Ken Poulton that the coding on this suggestion would parallel well with the full-duplex coding. 2. Bernie Eiben's "rewritten" reply dated 27 July. As he notes: "... I would like to treat a 'Window of Packets" as one Very Large Packet, which just happens to be sliced into smaller packets for ease of error-recovery." 3. The original extended packet length proposal, which could be modified so that checksums are placed after every 94 characters. If you look at that definition, MAXLX1 simply becomes the number of sub-units in this view. Note what happened as people looked at "windowing" in the half-duplex environment: the choice of terminology was confusing at first, but gradually sorted itself out into the fact that true sliding windows only works in a full-duplex environment, and the equivalent in half-duplex is a long packet with sub-units for ease of error-recovery. This suggests that the extended packet length proposal can be modified to include sub-units. I believe there is something of a philosophical turning point in KERMIT's development appearing. The Sliding Windows proposal provides "high-end" performance for those higher capability environments (operating system and communications channel) that are truly able to be full-duplex. This "high-end" situation generally reflects the capabilities of later systems on the market, which deserve to have their power taken advantage of. On the other hand, I think that a Super-Packet with segmentation proposal could reflect Classic KERMIT's concern with being able to operate in all environments. This proposal would need to take more enviroments into account. In some ways it is harder to define, because it may require more changes to the existing KERMIT definition since it is more dependent on KERMIT and less dependent on the operating system environment for performance gains. This philosophical difference is just a way of analyzing the fact that the two proposals have somewhat different intents, both of which I think are valid. With this in mind, I think it might be helpful to change the name of our proposal to "Full-Duplex Windowing Extension", in order to make it's intent clear. This definition is more dependent on the operating environment, but its changes to the KERMIT definition are limited, in that windowing is only in effect during transfer of data packets, there are no new packet types, and the ACK and NAK stay pretty much the same. The criticisms of our proposal have been with our underlying decision to operate in a full-duplex environment, rather than with the internal consistency of the proposal. I'm putting the following points forward in our favor: 1. We have a complete, usable definition. 2. We have a working implementation for the IBM PC, and it is based on CKERMIT. We are about to finish the PRIME implementation. 3. We will be making the code available to Columbia, and will be actively distributing it to communications software producers. 4. We have put lots of hard work into this. (Does that count??) 5. We have some unfortunate, but real, deadlines. 6. The sliding window definition can starting making some very great improvements in transfer times over the public data networks, where there currently is no other good solution to the throghput problem. 7. We (at The Source) currently have a chance to build additional momentum for KERMIT. In a lot of ways, this opportunity (or window?) is much better now than it will be later. We would like to have the definition approved this week. In addition, we would then like to continue to contribute to the definition of "super-packets with segmentation". I also would like to apologize for not having more time to approve this; it was not our intent. This is not a casual proposal however; it has been pretty carefully thought through (indeed, the refinement of the definition delayed it). Sincerely, John Mulligan ------------------------------ Date: Thu 1 Aug 85 14:17:00-EDT From: Frank da Cruz Subject: Full Duplex Sliding Windows -- Let's Give Them a Try To: OC.SOURCE@CU20B, OC.Jordan@CU20B, Info-Kermit@CU20B Keywords: Long Packets, Sliding Windows Kermit John, Hugh, Leslie, Larry... Your arguments are persuasive. You've clearly done a lot of work (in a project like Kermit, that's usually what counts most!). I'd like to state my misgivings for the record, and then go ahead grant you permission to use Bit #4 in the CAPAS field to indicate Full Duplex Sliding Window Capability, and the field immediately after the CAPAS field (remembering that the CAPAS field can grow) to designate window size, as you have proposed. My biggest misgiving is that we (you, I, and the Info-Kermit community) have not had sufficient time to consider the proposal, and I will always have nagging doubts that there may have been ways to improve it that would have made more people happy. As proposed, this capability requires true full duplex operation. In order for any computer to support this style of i/o, it must be capable of EITHER multiprocessing OR fully interrupt-driven i/o (or both). Multiprocessing is something most micros can't do; it requires certain hardware features like memory protection. On the other hand, almost any operating system allows access to its interrupt structure by the programmer. Unfortunately, the mechanisms for getting at interrupts vary considerably among machines, operating systems, and even operating system versions. So a Kermit program that manages to "steal" the system's interrupt vector in order to work correctly under version x of the operating system might suddenly stop working when the user installs version y... To make matters worse, information about interrupt programming tends to be hard to come by -- it's missing from the manuals, it's proprietary, or whatever -- so when this is true, it makes it tough for even the motivated programmer to do the work. It's unfortunate that you have such pressing deadlines, and that I will be gone for a month. It may well be that your proposal is exactly what is needed to kick Kermit protocol into the big leagues, but it might have been possible to refine it in such a way that continuous full duplex transmission would be possible for those systems capable of it, while provision was made for those systems (CP/M-80 springs to mind) that have to turn their backs on the communication port from time to time in order to write to the disk. As you suggest, systems like CP/M along with the systems that really have half duplex communication channels might be accommodated by the long-packet extension, especially if modified to allow segmented long packets (this reminds me of SMTP vs BSMTP...). But it would be a lot cleaner if a single Kermit extension could take care of everyone. A final misgiving is that allocation of a CAPAS bit and Send-Init field is irrevocable. Once Kermit programs are out in the world that use them, they can never be used for anything else. Therefore, I'd like to emphasize that the full duplex sliding window feature specified in Info-Kermit V3 #7 should still be considered EXPERIMENTAL. The group at The SOURCE will be tuning it as they work on their new implementations, and I'm sure that some of the comments and suggestions from Info-Kermit will be in the back of their minds. I expect that all this activity will settle down in a month or two, and a "final" copy of the sliding window specification will be available then. Until then, no one should attempt to work from the current specification without first contacting the people at The SOURCE (mail to OC.SOURCE@CU20B). Since the CAPAS bit and the window size field will be allocated to their windowing method, it is essential that the protocol invoked by them is clearly, completely, and unambiguously specified before any programs using them are distributed to the public. - Frank ------------------------------ End of Info-Kermit Digest ************************* ------- 2-Aug-85 17:40:38-EDT,9111;000000000000 Mail-From: SY.FDC created at 2-Aug-85 17:40:04 Date: Fri 2 Aug 85 17:40:04-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #12 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 2 Aug 1985 Volume 3 : Number 12 Departments: ANNOUNCEMENTS - C-Kermit 4C(057) Hurriedly Replaced PROPOSALS - Attribute Packets, Windows A Vote FOR Long Packets Sliding Windows vs. Long Packets vs. Segmentation MISCELLANY - VMS Kermit and VMS V4 Problem with Stevens' Kermit for Apple // Bugs in Version 2.28 of MS-DOS Kermit ---------------------------------------------------------------------- Date: Wed 31 Jul 85 18:07:00-EDT From: Frank da Cruz Subject: C-Kermit 4C(057) Hurriedly Replaced To: Info-Kermit@CU20B.ARPA Keywords: C-Kermit One of the edits in 4C(057) apparently broke C-Kermit on 68000's and possibly other non-VAX, non-PDP-11 machines -- the old int/char pitfall. Anyone who ftp'd C-Kermit from CU20B between 8:00pm-EDT July 29 and 6:00pm-EDT July 31 should pick up a new copy of K2:CKCFNS.C. Too bad I didn't have a 68000 to test this on -- apologies, and thanks to Philip Jeuck for pointing out the problem. You'll know if you have the bad version if it announces itself with the date 29 Jul 85; the (hopefully) fixed one is dated 31 Jul 85. Also, there was a minor error in conditional compilation for 4.1BSD which should also be fixed (K2:CKUTIO.C) and there was a minor change to the makefile (K2:CKUKER.MAK), and a minor problem with subshell invocation on systems with ints and pointers of different sizes (K2:CKUUSR.C). This should REALLY be the last release of this program for at least a month, so those who have not been getting new versions because they keep changing so often should pick up this one. ------------------------------ Date: Fri 2 Aug 85 15:14:57-EDT From: Frank da Cruz Subject: Attribute Packets, Windows To: oc.source@CU20B.ARPA, oc.jordan@CU20B.ARPA cc: Info-Kermit Keywords: Sliding Windows Kermit, Attribute Packets I was just looking at the protocol manual and realized that the current edition does not contain something which might be useful to you, namely two new attribute fields: "1" specifies the exact byte count of the file, and "2" specifies the byte size (e.g. "7" or "8"). This will be in the next edition. Many people have asked for a somewhat finer-grained way to report the file size than the number of K (e.g. some systems need to preallocate space, but in some unit other than K). - Frank P.S. Bye till September. P.P.S. I was waiting for a message to this effect from someone who called, but it hasn't arrived, and I'm leaving now, so here it is in a nutshell: If you have tested your sliding window algorithm with a slow (1200b or less) line and a fast (hard or RAM) disk and it works as expected, please verify that it ALSO works with a FAST (9600b or more) line and a SLOW (floppy) disk before finalizing the protocol and releasing any programs that implement it to the public. P.P.P.S. To everyone -- please keep sending comments on the new proposals to Info-Kermit@CU20B, even while I'm gone -- they'll appear in the digest on a weekly basis, approximately. ------------------------------ Date: Thu, 1 Aug 85 14:04:13 pdt From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa Subject: A Vote FOR Long Packets Keywords: Long Packets, Sliding Windows Kermit I'd like to cast a vote FOR the long-packet proposal. It seems to me to be a simple enough extension that it can be implemented and debugged quite quickly, without massive program changes. There are a number of situations where it will definately help; I have one user of ST-Kermit who has already "rolled his own" long packets, and another champing at the bit. I see long packets as complementary to (and even compatible with) sliding windows; there is no reason to have to choose only one. If someone would specify the extra bits and bytes in the send-init packet (very clever to have left those out of the proposal), we could get some implementations going soon. (Anyone want to volunteer for C-Kermit?) Ken Poulton hplabs!poulton [Ed. - Let's leave the proposal open for discussion, but if you want to play with an experimental implementation, let's say that the long packets bit is bit #5 and the length fields are the 2nd and 3rd bytes after the CAPAS field.] ------------------------------ Date: Fri, 2 Aug 85 09:42:58 cdt From: knutson@ut-ngp.ARPA (Jim Knutson) Subject: Sliding Windows vs. Long Packets vs. Segmentation Keywords: Sliding Windows Kermit, Long Packets Something that hasn't been addressed in this, is the protocol negotiation. In the past, both sides have not needed to negotiate because it was not necessary. Each side always transmitted what the other wanted. If there was disagreement over an option, the lowest common denominator was used. Now we have several transmission schemes. There is the normal packets transmission with packet lengths up to 96 characters, extended packet lengths, extended packet lengths with segmentation and sliding windows with all the above options. How will the correct scheme to use be decided between the two Kermits. Will a disagreement always bring you back to 96 character packets? For example, if a user selects sliding windows on a kermit that can have either sliding windows and/or extended packets and the remote kermit can only do extended packets, will they both revert to 96 character packets? Will extended packets be used? What if both could have done extended packets with segmentation but not sliding windows? Are we going to have a build in a priority CAPAS to prioritize the decision between transfer schemes? Jim Knutson ------------------------------ Date: Thu, 1 Aug 85 14:04:13 From: LCG.KERMIT Subject: VMS Kermit and VMS V4 Keywords: VMS Kermit Some of the folks at RCA have been using the new VMS Kermit on VMS V4.x and noticed odd echoing which was traced to differences in the V4 terminal driver's echo from V3. Characters like control-O were getting screwed up and leaving local terminals in graphics mode, as a symptom. It turned out there was a workaround. The procedure to use is as follows: Set line local host set term /PASTHRU connect The result is that things then work OK. VMS V4 users may want to take note. Charles Garman reported this to me. Glenn Everhart ------------------------------ Date: Wed, 31 Jul 85 20:26:19 PDT From: ken@cit-hamlet.arpa Subject: Problem with Steven's Kermit for Apple // Keywords: Apple II DOS Kermit When sending a file (specifically, a text file in 7 bit mode) from either an Apple ][+ or //e, to a Vax/Vms machine running V4 [with the V4 version of Kermit], the Apple kermit gets a "WRITE PROTECTED" error AFTER the transfer of the file (and the Vax deletes the file if the appropriate option is left as the default) if the disk is write-protected. It seems silly that write-protecting a disk should prevent the proper reading of a file. Anyone have a fix for this before I delve into the file manager? -Ken Adelman, Caltech ken@cit-hamlet.arpa ken@caltech.bitnet [Ed. - Anybody out there who can help?] ------------------------------ Date: 2 Aug 1985 0653-PST From: Pawka Subject: Bugs in Version 2.28 of MS-DOS Kermit To: INFO-HZ100@RADC-TOPS20.ARPA Keywords: MS-DOS Kermit I found a couple of minor bugs in the Z-100 version of MS-Kermit, Version 2.28, here are the fixes: 1) The STATUS command causes the program to wander off into never- never land, module MSSET.ASM had 2 instuctions missing, in routine BAUDPRT a push and a pop of di were missing: Was: BAUDPRT PROC NEAR call getbaud ; read baud rate first Should be: BAUDPRT PROC NEAR push di ; preserve this call getbaud ; read baud rate first pop di 2) The delete, backspace or Ctrl/H keys were not erasing characters in the command line. The routine that gets characters from the keyboard now, for some reason, puts out a space when it reads one of these characters. I fixed this by changing a string in MSXZ100.ASM: Was: delstr db BS,' ',BS,'$' Now: delstr db BS,BS,' ',BS,'$' I hope this doesn't foul up something else, it seems o.k. for the stuff I do. Mike Pawka PAWKA@NOSC-TECR.ARPA [Ed. - Provided only for information to H/Z-100 folks; we'll check it out and include in the forthcoming release if ok.] ------------------------------ End of Info-Kermit Digest ************************* ------- 9-Aug-85 13:37:30-EDT,16925;000000000001 Date: Fri 9 Aug 85 13:34:34-EDT From: The Mailer Daemon To: US.JD@CU20B.ARPA Subject: Message of 9-Aug-85 13:21:37 Message failed for the following: *MAIL.TXT.1@CU20B.ARPA: No such mailbox ------------ Date: Fri 9 Aug 85 13:21:37-EDT From: Jeff Damens Subject: Info-Kermit Digest V3 #13 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-to: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 09 Aug 1985 Volume 3 : Number 13 Departments: ANNOUNCEMENTS - Kermit directories/files have moved KERMIT ENHANCEMENTS DISCUSSION - Sliding windows on micros should work ANY-duplex Windows Half-duplex windowing and large packets UNIX KERMIT - CKermit Statistics MS-DOS KERMIT - Warning: Unrecognized Baud Rate MISCELLANY - How do you edit pc-ix sources? RT-11/TSX+ Kermit Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS. ---------------------------------------------------------------------- Date: Sat 3 Aug 85 09:02:08-PDT From: Douglas Edwards Subject: "Warning: Unrecognized Baud Rate" Keywords: MS-DOS Kermit I use MS-DOS Kermit for the IBM PC (actually I have a Compaq, but they seem interchangeable). I have one minor problem. When I start up Kermit I always get the message "?Warning: Unrecognized Baud Rate" even though my init file clearly specifies 1200 bps. (It works fine--the message seems to have no significance, it's just annoying.) What causes this? Douglas Edwards (edwards@su-csli) [Ed. - When it starts up, MS-DOS Kermit looks at the baud rate the serial port is set to and tries to identify it (so that the status command will print the correct value if the baud rate isn't explicitly set). If it can't figure out the baud rate, the message is printed. This has nothing to do with what's in your init file - it is printed even before the init file is read. The message won't affect anything else; it should probably be removed. ] ------------------------------ Date: Sun, 4 Aug 85 15:08:17 pdt From: "Corwin Nichols; Community Data Processing; 415-322-9069" Subject: sliding windows on micros should work Keywords: Sliding Windows Kermit In a July 27 note, B.Eiben writes: >As is probably known, none of our current 'Van Neuman' machines can handle >more than one task at any given instant of time. The illusion of >'time-sharing' and 'multi-tasking' or even 'multi-processing' are only >possible with the existence of a sophisticated interrupt-structure >[typically combined with 'hardware assisted' context-switching] and software >delivering the book-keeping services. >The currently most 'popular' micro-systems [CP/M and MSDOS or derivatives] >are SINGLE-tasking systems. Although the used micro-processors typically >support a basic interrupt-structure, the lack of buffered and hardware >assisted I/O devices limits the interrupt-structure basically to ERROR >intercepts and clock-service. -- Or in laymans terms, "A typical micro >CANNOT accept characters on the Input-port, as long as its reading or >writing to the floppy". It is true that the current crop of popular micros run MSDOS, CP/M, or AppleDos, and that these are singletasking operating systems. However it is NOT necessary to have a "sophisticated interrupt-structure" or fancy hardware in order to process a single stream of incoming characters while performing other tasks such as monitoring the incoming stream, calculating checksums, transmitting ACKs, etc. All that is required is a simple interrupt routine which captures the incoming stream in a buffer, and which is enabled throughout disk i/o operations. All machines which claim to be close to IBM PC compatibility meet this simple criteria. Many CP/M machines also meet these requirements, ei Radio Shack models 2, 4, 12, and 16; all Compupros, Altos's, Cromemcos and any other machine which uses a dma chip for disk i/o and has a serial chip that is on an interrupt line. Since most of the CP/M and MSDOS implementations are already machine dependent, I don't foresee any major problems implementing the sliding window code on most of the popular micros. ------------------------------ Date: Fri, 2 Aug 85 20:18:22 pdt From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa hplabs!cc.fdc@cu20b.ARPA, hplabs!oc.source@cu20b.ARPA Subject: ANY-duplex Windows Keywords: Sliding Windows Kermit, Long Packets I agree with Leslie et al, that they have a viable, apparently well thought-out proposal for full-duplex sliding windows. Where we differ is in whether half-duplex windows belong to Sliding Windows or to Long Packets. They argue that the various half-duplex proposals all filter down to long, segmented packets. At the link level (what passes down the wires, and how to synchronize it) this is true. But NOT AT THE PACKET LEVEL, where most of the programming is involved. The major part of the implementation of full-duplex windows is in the handling of a window of "active" packets (except when the opsys doesn't support multi-processing). At the packet level, the handling of half-duplex windows is nearly the same, as Leslie agrees: 1. Ken Poulton's suggestion of a way to do "super-packet" half-duplex (message dated July 27). This is a effectively a super-packet with segmentation. ******************************************** ************* Hugh agrees with Ken Poulton that the coding on this suggestion would parallel well with the full-duplex coding. *********************************************************** PROPOSAL: Have the full-duplex windows allow for half-duplex operation. All implementations with full-duplex windows should be able to run in half-duplex mode also, so that we don't end up with two (probably incompatible) versions of windows/long-packets running around. I don't think this requires adding much to a full-duplex window scheme. To repeat from my earlier proposal: All the full-duplex version needs to do is: 1) negotiate half-duplex status and super-packet size along with window size 2) bunch outgoing packets together (without end-of-lines) to form a super-packet 3) wait for the replying super-packet before sending the next. My immediate concern is with point (1): unless this negotiation is added to the full-duplex windows NOW, it never will. But once that part is defined, the implementation is easy. In fact, it might be a positive benefit for future full-duplex implementations: one could bring up half-duplex windows first to debug the window algorithm and worry about the low-level interrupt/process handling stuff later. (Half-duplex windows have got to be easier to debug than full-duplex...) Adding a half-duplex option to sliding windows also makes them more portable: half-duplex windows might still work across operating system revs or different hardware (e.g., PC-almost-clones) when a full-duplex implementation (that munged the interrupt vector, or whatever) broke. To argue by the numbers: 1) half-duplex windows are a SIMPLE extension of the proposed full-duplex window proposal 2) half-duplex windows ADD portability and robustness, even for full-duplex machines 3) The only critical need *right now* is to *define* the bits and bytes for negotiating half-duplex windows and add that part of the negotiation to the full-duplex window specification. In the interests of allowing Leslie, et al to move along, implementation can wait. If full-duplex windows go ahead without a half-duplex provision, it seems likely that we will eventually agree to a separate segmented long packet proposal, which may go the way of File Attribute Packets. (Almost no one has implemented these because there is almost no one else to exchange them with.) Momentum is key here! Leslie & co have made a large contribution here, and I thank them for that. I agree that this window proposal is indeed a critical moment for Kermit. We *all* benefit by making it useful to more machines. After all, isn't that what Kermit is all about? Ken Poulton hplabs!poulton ------------------------------ Date: Wed 7 Aug 85 03:20:06-EDT From: Ken Rossman Subject: Kermit directories/files have moved Keywords: Kermit DIR Due to space shortages on our PS structure, all Kermit directories and files have been moved to the PX/PB structure. All system-wide logical names have been correspondingly redirected, so if you use the system-wide logicals for all file references, you should not notice any difference. Mail questions and/or problems to info-kermit@CU20B. ------------------------------ Date: 7 Aug 85 18:11:49 EDT From: BL02@CMU-CC-TC Subject: how do you edit pc-ix sources? Keywords: Editor Help! I have a pc-xt running pc-ix. I can't live with INed (the editor) anymore. Since ckermit is a rather large program, and it has been made to run under pc-ix, I gather someone out there has a nice editor that runs under same. Can someone give me a pointer to where I can get one? I really am looking for an emacs clone (thief, fine, jove, etc.) or even real emacs, etc., etc., etc. I do have some sources to thief and jove, but not for pc-ix, and I just don't have the time right now to fix them up. Can anyone help me?? or am I just stuck with INed? Thanks SO MUCH for any replies or comments. Bryan Lally bl02@cmcctc ------------------------------ Date: Tue, 6 Aug 85 11:59:46 PDT From: Bruce_A._Cowan%SFU.Mailnet@MIT-MULTICS.ARPA Info-Kermit@CU20B.ARPA Subject: Half-duplex windowing and large packets Keywords: Long Packets, Sliding Windows Kermit I'd like to make a proposal which essentially adds some details to Ken Poulton's proposal for half-duplex sliding windows with super-packets (Info-Kermit #11). Extend the protocol to negotiate both the maximum window size and the super-packet size, using the byte following the window size for the super-packet size. Now, if the super-packet size is 0 or 1 (treat 0 as equivalent to 1), then we have full-duplex windowing as in the Source's proposal. If the super-packet size is the same as the window size, then we have half-duplex windowing. If somewhere in between, then we have full-duplex windowing using super-packets. Note that if window size is super-packet size times 2, then although we strictly have full-duplex windowing, we can consider it to be half-duplex with type-ahead. I believe that will work on a few half-duplex systems. It will certainly work on my MTS system. In this proposal the window size in terms of number of super-packets outstanding at once is (window size)/(super-packet size). Keep the rule in the original windowing proposal that explicit ACKs and NAKs are required for each packet. Note that implicit ACKing must be disabled if the environment is full-duplex, because you really don't know if the missing packet is an ACK or a NAK (you could change it to implicit NAKing). The other rule that differs between half- and full-duplex environments is that in a half-duplex environment one should do something with a packet with a bad checksum - sender treats it as a NAK and receiver sends a NAK. That prevents having to wait for a timeout every time a packet gets mangled. As the windowing proposal correctly states, in a full-duplex envorinment one must simply ignore packets with a bad checksum. That is because one cannot guess the correct packet number as one can in the half-duplex environment. I'd also like to propose one more extension to save money on public data networks. Many of those networks charge by the packet and packet sizes are typically up to 128 or 256 bytes. I'd like to extend the packet length field to 2 bytes when the first length byte (decoded) is 1 or 2. That will allow packet sizes from the current minimum up to 284 with no loss of efficiency on short packets. It will allow a super-packet of 26696 (284*94) bytes which seems more than long enough. Two more bytes are needed in the Init packet to negotiate the maximum packet size just as in the original long packet proposal. Note that I haven't used packet size 0 so this doesn't conflict with the large packet proposal. However, I'd like to see this proposal supercede that one because it is superior in several respects. It allows ACKing and NAKing parts of large packets and it fits in with the windowing proposal. Now, this idea complicates the negotiation process a bit, because if one side wants to be half-duplex and the other side doesn't care, the negotiation must be sure to end up in a half-duplex state. I believe the following rules will work: 1. Use the minimum value of window size (or smaller, see 3). 2. Be half-duplex (super-packet size equal to window size) if either side requests that. 3. Make super-packet size divide (no remainder) window size and make super- packet size be such that the resulting quotient is the minimum of the two quotients requested, by adjusting the window size downward if necessary. The biggest drawback to this proposal is that it doesn't allow very large packets when one really wants a window size of 31 (since in that case one cannot use super-packets). Nonetheless, the 284 byte maximum packet size in that case seems sufficient. I'm a bit out of touch for the next week and have been for a few days so this proposal may not take into account everything it should and I won't be able to respond until next week. ------------------------------ Date: Mon, 5 Aug 85 14:19:56 pdt From: seismo!decvax!ucbvax!ucdavis!deneb!ccrms@columbia.arpa (Michael Shulman) Subject: RT-11/TSX+ Kermit Keywords: RT-11 Kermit We understand that there is a version of Kermit available for the TSX+ system. It is far easier for us to obtain a copy of this system on 8" disk than it would be to bootstrap it ourselves. Are there any sites that have such a system running and would be willing to make us a copy on 8" disk? Thank you, Michael Shulman Computer Center UCDavis ... ucbvax!ucdavis!deneb!ccrms ------------------------------ Date: Thu, 8 Aug 85 03:29:24 pdt From: Neal Holtz Subject: CKermit Statistics Keywords: C-Kermit A statistic regarding performance of C-Kermit: source: Vax 11/750 4.2 BSD dest: Apollo DN320, Aegis SR8 line: 9600 baud type: text # files: 53 # chars: 684206 time: 29 min. (+/- 1 min.) effective rate: 393 chars/sec Notes: 1) Apollo versions: C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85 C-Kermit Protocol Module 4.2(015), 5 Mar 85 C-Kermit functions, 4.2(026) 5 Mar 85 Unix cmd package V1.0(015) 27 Feb 85 User Interface V4.2(038), 5 Mar 85 Apollo Aegis tty I/O, 4C(023), 20 May 85 for Apollo Aegis SR8 Aegis file support, 4C(024) 20 May 85 for Apollo Aegis SR8 Connect Command for Unix, V4.2(006) 5 March 85 2) Vax versions: C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85 C-Kermit Protocol Module 4.2(015), 5 Mar 85 C-Kermit functions, 4.2(026) 5 Mar 85 Unix cmd package V1.0(015) 27 Feb 85 User Interface V4.2(038), 5 Mar 85 Unix tty I/O, 4.2(016), 5 Mar 85 for 4.2 BSD Unix file support, 4.1(015) 28 Feb 85 for 4.x BSD Connect Command for Unix, V4.2(006) 5 March 85 3) All compiler optimizing turned off on Apollo 4) Used about 25% of CPU on Vax 5) Used about 70% of CPU on Apollo ------------------------------ Date: Fri, 9 Aug 85 9:46:06 EDT From: David Roth (Ft. Benj. Harrison) Subject: Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS. Keywords: Burroughs B2x, BTOS This Sept.15 we are expecting shipment to arrive of dozens of Burroughs B-20s, B-25s & B-26s. The operating system they run is called BTOS. We are in need of a version of KERMIT for these systems. Anyone have a version or enough experience in using BTOS to suggest what existing version of KERMIT we should start with. The Army refers to these systems as: TACCS. Thanks in advance. David A. Roth droth@brl-bmd US Mail: COMMANDER USA Soldier Support Center ATSG-DTU-S Attn: Mr. David A. Roth Fort Benjamin Harrison, IN 46216-5590 AUTOVON:699-4298 FTS:335-4298 COMMERCIAL:(317) 542-4298 ------------------------------ End of Info-Kermit Digest ************************* ------- ------- 30-Aug-85 18:31:41-EDT,21691;000000000001 Mail-From: US.JD created at 30-Aug-85 18:31:00 Date: Fri 30 Aug 85 18:31:00-EDT From: Jeff Damens Subject: Info-Kermit Digest V3 #14 To: info-kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 30 Aug 1985 Volume 3 : Number 14 Departments: UNIX KERMIT - Bug (?) in C-Kermit 4C MS-DOS KERMIT - Concurrent DOS KERMIT CMS/TSO KERMIT - CMS Kermit Improvements? KERMIT-TSO and 7171 (2 messages) CMS KERMIT and Yale 2.0 (2 messages) MISCELLANY - More on sliding windows Kermit for the PRO Getting K11 on floppies 6809 Kermit BTOS Kermit Kermit for TI 99/4A CompuPro KERMIT version wanted to work with Hayes Micromodem. CROSS and other queries Prime Kermit Plea for help Kermit/milnet Kermit over TELENET: Help Needed Kermit for Fortune 32:16 Kermit on VMS ---------------------------------------------------------------------- Date: 9 Aug 1985 1612-EDT From: B.Eiben LCG Ext 617-467-4431 Subject: More "sliding WINDOWS" Keywords: Sliding Windows Kermit, Long Packets The gist for micro's lays NOT in the fact, that they have [or haven't] an interrupt-structure [infact having none is cleaner then having "something"]. The PROBLEM typically is the "floppy-controler" i.e FD17xx , which delivers data "fast" enough , so that one has to TURN OFF interrupts during READ/WRITE but SLOW enough to lead easily to character-loss during floppy-processing. The typical coding sequence [very innocent] looks like DI Call Write/Read Sector EI ... that alone makes "sliding WINDOWS" impossible - since one eventually HAS to write the stuff to the disk - and there's NO TRICK to stop the SENDER from sending - except for "holding back ACKs" - and that takes away most of the advertised speed-improvements. Obviously the "sector-time" window is dependant on the media-speed [floppies will be LOOSERs compared to winnies] and the amount of 'character lossage' depends on the channel-speed [ at 1200 baud one might loose NOTHING , since the window is about one char-time, and thats hanging around in the USART ... at higher speeds it'll be one or more lost char's - i.e. a full NAK/resend packet cycle ] - so as seen from the "innocent bystander" we now have introduced a feature , which might "work for me" but "not for You" - i.e. the same MICRO connected to the same Mainframe will "win" or "fail" depending on storage medium and/or channel-speed == in my mind NOT A GOOD IDEA . Rgds, Bernie. ------------------------------ Date: Wed 7 Aug 85 17:58:06-PDT From: Wing Lee Subject: KERMIT-TSO and 7171 Keywords: TSO Kermit, 7171 Protocol Converters I hate to keep on bugging you about KERMIT-TSO and the 7171, but my boss keeps on asking me if there is any news. This is our situation. We installed the Series/1 version of KERMIT-TSO on our 3081, in March of 1985. Everything worked fine, and everybody was happy. In May, we replaced our Series/1 with an IBM 7171, so that we could have more lines going into TSO. That's when our problems started. Going through the 7171, we were able to download but not upload. When we tried to upload, the file transfer would hang at random places. When I used DEBUG mode to look at the packets, I saw that the tranfer would always stop right after a file transfer. As soon as I discovered this, I sent a message to Columbia asking for help. In the meantime, we have put together a makeshift way to get KERMIT-TSO to work. On our 3081, we run both MVS/TSO and VM/CMS. Our ascii interface to TSO is an IBM 7171, our ascii interface to CMS is a SERIES/1. We have been able to have users who wish to do file transfer to TSO, to use the CMS Series/1. Then they would DIAL MVSA and connect to our MVS system. That works. But now our Systems people are thinking of replacing the CMS Series/1 with another 7171. When we told them that this would disable are ability to use KERMIT altogether, they said that our TSO KERMIT is not supported by Columbia, and we should not be using TSO Kermit on our TSO system until Columbia has a supported version. Thus we should not even have the package on our system. My question is, does Columbia support the Series/1 version of KERMIT-TSO? [Ed. - No. We don't run TSO.] wing ------------------------------ Date: Wed 7 Aug 85 19:10:07-PDT From: Wing Lee Subject: kermit-tso and 7171 Keywords: TSO Kermit, 7171 Protocol Converters in my last message i said, that when uploading, the transfer stops right after a file transfer. i meant that the transfer stops right after a bad packet. i should have reread my message more carefully before i sent it out. wing ------------------------------ From: Gary Mills Subject: 6809 Kermit Keywords: 6809 Kermit Does anyone have a version of Kermit for the 6809 CPU, with Flex-9 or OS/9 operating systems? C or assembler languages would be suitable. ------------------------------ Date: Sat, 10 Aug 85 13:04 EST From: Larry Afrin Subject: Bug (?) in C-Kermit 4C Keywords: C-Kermit Hi, I just got the latest version of 4C a few days ago (the one the Digest swore would be the "absolute last" release of 4C). I compiled it for a System V system, and the problem I noticed occurred when I was "get"ting some stuff from SIMTEL20. The files on SIMTEL that I was transferring had names like ABCDEF. and GHIJKLMN. (the point here being that they're all upper-case, as you would expect from a TOPS-20 system). I wanted to transfer them to my UNIX system and give them the same, upper-case filenames, just without the dot. I knew that if I told my local Kermit "get ABCDEF." or "get ABCDEF", it was going to do some funky translation of the name (for what reasons, I don't know; I just remember seeing somewhere that Kermit adjusts filenames for the "conventions" of your system, which in UNIX usually means all lower-case), which isn't what I wanted. So I figured I would just type in "get" and let it prompt me for the remote filespec and the local filespec. For the remote filespec I entered "ABCDEF.", and for the local filespec I entered "ABCDEF". The transfer then started up ... "IRSF" and wham! my local Kermit told me "ABCDEF. => abcdef", which wasn't what I wanted. My whole point here is, if Kermit goes to the trouble of asking you exactly what you want your local filespec to be, shouldn't it refrain from translating that name (in this case from uppercase to lowercase)? In fact, why can't the "get" command be set up so that (1) if you don't give a command line filespec and it goes ahead and prompts you, it shouldn't translate either the remote or local filespecs; and (2) if you do give a command line filespec, it should be interpreted as the *exact* filespec for the local system, but it should be "appropriately" translated to make the remote Kermit happy. I'm not 100% sure that (2) is "right", but I do feel that (1) is right. Oh, yeah, one more thing: Also during this transfer operation with SIMTEL20, I tried this command: "get *.c". Assuming my SIMTEL filenames matching this spec were ABC.C, DEF.C, GHI.C, and JKL.C, this is what my local Kermit reported to me during the transfer: ABC.C => *.c DEF.C => def.c GHI.C => ghi.c JKL.C => jkl.c and yes, sure enough, my local Kermit really did create a filename called "*.c". Now, is this a bug, or did I just specify my "get" command incorrectly? Thanks for any info, advice, etc., you can provide. -- Larry Afrin Dept. of Computer Science Clemson University Please send replies, if any, to: lbafrin@clemson if you're on CSNet lbafrin.clemson@csnet-Relay if you're on ARPANet ------------------------------ Date: Mon 12 Aug 85 09:15:36-EDT From: Bill Catchings Subject: BTOS Kermit Keywords: Burroughs B2x Kermit, BTOS The best version of Kermit to work with for the Burroughs BTOS is probably C Kermit. I do not know for a fact that Burroughs supplies C for BTOS, but Convergent Technologies (the maker of the B-20 series) supplies a C for CTOS (The "parent" of BTOS). My knowledge of BTOS is limited, but I believe that CTOS and BTOS are pretty close. The C for CTOS is pretty poor, based on Mark Williams C, and the terminal/file transfer product that CT supplies is terrible. After 40 screens it starts over at the first screen. Very annoying. I plan to be working on a CTOS version of C Kermit in the next few weeks. If I succeed in getting one working it will be announced on Info-Kermit. If not you'll have to try yourself. -Bill Catchings ------------------------------ Date: Tue, 06 Aug 85 19:58:34 EDT From: Peter DiCamillo Subject: CMS Kermit Improvements? The latest version of CMS Kermit includes features which make it very attractive to users at Brown. These include support for Series/1 connections, binary data transfer, and server mode. As a result, the Computer Center plans to recommend Kermit as the standard file transfer program between CMS and IBM PCs, Macintoshes, and other micros. In evaluating CMS Kermit, we noticed that, as documented, server mode only supports GET, SEND, FINISH, and BYE. This is very obvious to the Macintosh user who has a menu of server commands, most of which are not supported by CMS Kermit. Also, it would be useful to us if CMS Kermit could preserve the date and time of files whenever possible. Is any work planned or in progress to add these features? If not, I may attempt to add them myself. [Ed. - Kermit allows you to create the file on the destination computer with the same write date and time as on the source computer. This requires however supporting attribute packet. At this time, CMS Kermit does not support attribute packets although it may do so in the future. If you'd like to add the support, let us know so there won't be a duplication of effort on the part of some other ambitious soul. ] ------------------------------ Date: 14 Aug 1985 23:45-EST From: Sanjay Kapur Subject: kermit for the pro Keywords: DEC PRO300 Kermit Is there a version of kermit available for the DEC PRO350 running the Professional Operating System? Where can I get a copy of it? [Ed. - yes. It's the k11 version, available on the distribution tape or in numerous other ways (see following message).] ------------------------------ Date: 10 AUG 85 12:04-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: GETTING K11 ON FLOPPIES Keywords: Kermit-11 In Response to Kermit Digest re RX0x dist. Getting K11 on various media K11AAA.AAA Updated 14-JUN-1985 09:22 Brian Nelson Kermit-11 Edit history: K11CMD.MAC Kermit-11 Installation: K11INS.DOC Kermit-11 Documentation: K11HLP.HLP (no separate user manual) Kermit-11 Files: K11FIL.DOC Please note that while Kermit-11 uses RMS11 for all versions (RT11 excluded) you do not need RMS on your system unless you opt to use the versions linked to RMSRES (K11.TSK for RSTS/E and K11POS.TSK for M/M+ and P/OS). For further information, please read K11INS.DOC To get Kermit-11 and all the other Kermits: KERMIT Distribution Columbia University Center for Computing Activities 7th Floor, Watson Laboratory 612 West 115th Street New York, N.Y. 10025 There is also a fairly current copy of Kermit-11 available from DECUS, order number 11-731. As of June 1985 the DECUS library has Kermit-11 available on RX01's and RX50's (in RT and P/OS format). Additionally, the SIG tapes almost always have a current version on them. To get Kermit-11 from the author: Mail: 800bpi DOS-11 format 1600 bpi tape DOS-11, ANSI or VMS Backup RX01 RT format, binaries only RX50 RT or P/OS (readable on Micro/RSX), delays are possible since I have only one PRO/350 and one hard disk. For tapes, VMS Backup format is preferred (default if not specified). For RSTS/E, V9 Backup format is preferred. V9 backup is NOT compatible with previous releases of RSTS/E, but IS compatible with VMS backup. You must supply the media (extras are nice to offset the cost). Brian Nelson Computer Services University of Toledo 2801 West Bancroft Toledo, Oh 43606 (419) 537-2841 or BRIAN@UOFT02.BITNET Bitnet: from VM/CMS: CP SMSG RSCS MSG UOFT02 KERMSRV DIR CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.* from VMS Jnet: $ SEN/REM UOFT02 KERMSRV SEND K11*.* Columbia University maintains a BITNET Kermit server also, username KERMSRV node CUVMA. Command format is similiar to the VMS KERMSRV on node UOFT01. Dialup: (419) 537-4411 Service class VX785A User: KERMIT Password: KERMIT Source and hex files are in KER:, binaries are in KERBIN: ------------------------------ Date: Mon 19 Aug 85 05:33:45-PDT From: GARGARO@USC-ECLB.ARPA Subject: Kermit for TI 99/4A Keywords: TI 99/4A Kermit Gentlemen I am trying to locate a version of Kermit for the Texas Instruments 99/4A Home Computer. I have been informed that one exists or is currently under implementation. I would appreciate any information that you may have regarding Kermit for the TI 99/4A. Anthony Gargaro. ------------------------------ Date: Mon, 19 Aug 85 12:23:44 EDT From: David Roth (Ft. Benj. Harrison) Subject: CompuPro KERMIT version wanted to work with Hayes Micromodem. Keywords: CompuPro Kermit, Hayes Modem We need help on getting a version of KERMIT for the CompuPro running CP/M 2.2LD to work with a Hayes Micromodem 100 using the microcoupler. We have the source to KER:CPMPRO.M80 from Columbia University but it is for use with Compupro Interfacer 3/4. Thanks in advance. David A. Roth droth@brl-bmd US Mail: COMMANDER USA Soldier Support Center ATSG-DTU-S Attn: Mr. David A. Roth Fort Benjamin Harrison, IN 46216-5590 AUTOVON:699-4298 FTS:335-4298 COMMERCIAL:(317) 542-4298 ------------------------------ Date: Mon, 19 Aug 85 13:44:28 edt From: jax-lab!jng (John N Guidi) Subject: Concurrent DOS KERMIT Keywords: MS-DOS Kermit, Concurrent Kermit I would like to run KERMIT on a Concurrent DOS, IBM PC/AT system. Is there a separate Concurrent DOS distribution? If not, can one use the PC-DOS KERMIT while running Concurrent DOS? If this is the case, are there any caveates to keep in mind? Thanks. John Guidi The Computing Service The Jackson Laboratory Bar Harbor, ME 04609 phone: (207)288-3371 uucp: ...!decvax!unh!jaxlab!jng bitnet: jaxlab@maine ------------------------------ Date: Friday, 16 August 1985 15:51-MDT From: ABN.ISCAMS@USC-ISID.ARPA Subject: CROSS and other queries Keywords: CROSS Assembler NetLandians, Could someone please point me to the documentation/instructions for CROSS - the cross assembler available on some TOPS-20 hosts, and used extensively for KERMIT applications. [Ed. - Take a look in psb:cross.* on Cu20B.] Second: Is CROSS proprietary or public domain? [Ed. - I think it's public domain.] Third: What happened to CU20B as a host? The KERMIT archives are out there (Columbia University), and I saw the msg they were moving the archives to another disk... but when trying to FTP to CU20B, I get an unknown host error. Can anyone point me right? [Ed. - Cu20b underwent some disk reshuffling, but it should be back online now. ] Thanks in advance, David Kirschbaum Toad Hall ------------------------------ Date: Tue, 20 Aug 85 07:53 PDT From: "Chase Lila"@LLL-MFE.ARPA Subject: Prime Kermit Keywords: Prime Kermit Can the Prime Kermit transfer binary files? chase@lll-mfe.arpa ------------------------------ From: bierma@nprdc.arpa (Larry Bierma) Date: 20 August 1985 0953-PDT (Tuesday) Subject: CMS KERMIT and Yale 2.0 Keywords: VM/CMS Kermit, Yale ASCII Communications Program Is CMS KERMIT supposed to work through a Series/1 running version 2.0 of the Yale software? Whenever we start the server it hangs up the line. Everything works fine in line mode through a 3704, and in page mode through a 7171, it's just the series/1 that hangs up. [Ed. - We use CMS Kermit through a Series/1 running the version 2.0 of the Yale Ascii code and version 3.2 of EDX all the time without any problems. The way this works is Kermit puts the S/1 into transparent mode. It sounds like you don't have the most up-to-date software for the S/1. ] --Larry ARPA: bierma@nprdc.arpa UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdcsla!nprdc!bierma PSTN: (619) 225-2161 ------------------------------ Date: Tue 20 Aug 85 15:34:52-CDT From: CMP.STARCH@UTEXAS-20.ARPA Subject: plea for help Keywords: VAX/VMS Kermit, HP1000 Kermit Hi I am trying to find a way to connect my Vax (VMS 4.1) to our HP 1000 running the RTE-A operating system. Is there a Kermit out there for this OS. I looked and found the one for a previous HP1000 operating system (RT6/vm or some such moniker) Please respond to CMP.STARCH@UTEXAS-20.ARPA, as I am not on the INFO-KERMIT discussion. Steve Kneuper Lockheed Austin Division (512)386-1676 ------------------------------ Date: 14 Aug 1985 1541-PST From: Contr36 Subject: kermit/milnet Keywords: C-Kermit, MILNET from: Paul Attermeier Sandia National Labs Albuquerque, NM (505) 844-1106 I am trying to transfer some files from a VAX at the Naval Ocean Systems Center back to my machine using Kermit. I have had no success so far and the problem seems to lie somewhere in the MILNET connection. I'm running Kermit on a VAX/780 under Ultrix. (The header reads 'C-Kermit 4.2 (030) Prerelease #2, 5 March 85, 4.2 BSD). I've been able to transfer files from another local 780 running VMS and a version of Kermit (VMS Kermit-32 version 3.0.052) that appears to be older than the one on the NOSC machine, (VMS Kermit-32 version 3.1.062) so I don't think there is a Kermit version incompatibility problem. Whenever I try a Kermit file transfer across MILNET, it just tries for a minute or two and then times out. Do you know of any Kermit or MILNET parameters which need to be changed from their defaults? ------------------------------ Date: Fri, 23 Aug 85 09:57 EST From: Larry Afrin Subject: Kermit over TELENET: Help Needed Keywords: TELENET Fellow Frog Lovers, I would like to use Kermit for file transfer between my IBM PC and an NCR Tower running System V UNIX. Both machines are running the latest versions of Kermit available for them. The only problem is that GTE TELENET is in the middle. (From the PC's Kermit I dial TELENET's local number and then give the connect code (host address) by which TELENET knows the Tower.) Something with TELENET is preventing file transfer from working (the initialization packets don't even make it through). Does anyone out there have either (1) a proven method for using Kermit over TELENET or (2) an explanation of why such may be impossible? Any help, advice, pointers, etc. would be greatly appreciated. Thanks in advance... -- Larry Afrin Dept. of Computer Science Clemson University Please send replies, if any, to: lbafrin@clemson if you're on CSNet lbafrin.clemson@csnet-Relay if you're on ARPANet ------------------------------ Date: Wednesday, 21 August 1985 08:59-MDT From: Steve Westfall Subject: Kermit for Fortune 32:16 Keywords: Fortune 32:16 Kermit The Bulletin of the Atomic Scientists at the University of Chicago has a Fortune 32:16 computer. The system administrator has had problems getting kermit to work with his Fortune and would like to get in touch with anyone who has helpful information about this. Please get in touch with the following person, not me: Barry Bowen Bulletin of the Atomic Scientists 5801 S. Kenwood Chicago, Illinois 60637 312-363-5225 UUCP: ...ihnp4!gargoyle!xeno Thanks. Steve Westfall Uucp: ihnp4!gargoyle!sphinx!west Senior Staff Analyst Bitnet: staff.westfall@UChicago.bitnet U. of Chicago Computation Center Mailnet: staff.westfall@UChicago.Mailnet ------------------------------ Date: 22 Aug 1985 12:32-EDT Subject: kermit on vms From: ZAKAR@USC-ISI.ARPA Keywords: VAX/VMS Kermit, C-Kermit I am trying to connect a VAX/VMS system to a VAX/UNIX 4.2 system using KERMIT. The UNIX side is running version 4C (CK*) and the VMS side is running the MACRO version (VMS*.MAR). The link is made up of ports of DMF32s on both machines. If someone else has tried this before, I need to talk to them because I may not have set up the VMS environment correctly. From the UNIX side I can CONNECT to VMS just like a terminal with no problems. On the VMS side though, when I CONNECT to UNIX, I have a problem with data overrunning buffers, as though there were no flow control. Any help would be appreciated. Joe Zakar Zakar at USC-ISI ------------------------------ End of Info-Kermit Digest ************************* ------- 5-Sep-85 18:44:47-EDT,21422;000000000001 Mail-From: SY.FDC created at 5-Sep-85 18:44:24 Date: Thu 5 Sep 85 18:44:24-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #15 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 5 Sep 1985 Volume 3 : Number 15 Departments: SLIDING WINDOWS - Sliding Windows Work on Fast Line with Slow Disk Re: ANY-duplex Windows (2 messages) MS-DOS KERMIT - POPDOS2 and Kermit Problem Problem with MS kermit on DEC Rainbow 100+ Leading Edge & Corona Portable -- Kermit Fit? Kermit for the Hyperion? IBM MAINFRAME KERMIT - Solution to TSO Kermit vs 7171 Problem Kermit with Yale ASCII? ---------------------------------------------------------------------- Date: Thu 22 Aug 85 15:42:46-EDT From: John Mulligan Subject: Sliding Windows Work on Fast Line with Slow Disk Keywords: Sliding Windows Kermit Frank - I tried the windowing direct connect at 9600 baud with a standard IBM PC (Floppies) and had no problems. ------------------------------ Date: Thu 22 Aug 85 15:46:43-EDT From: John Mulligan Subject: Re: ANY-duplex Windows Keywords: Sliding Windows Kermit, Long Packets Dear Ken, I would like to thank you for your messages on the windowing proposal. They were well thought out and written, and helped us a great deal in refining the proposal. I have been meaning to reply before, but I was still learning the mail system on Columbia. Frank was the only one I knew how to send messages to! Anyway, we have been thinking about the half-duplex situation. I'm sending our current thoughts to you before we go public with them. First, the Send-Init packet. Define an additional bit in the capabilities mask indicating half-duplex windowing: Bit 1 2 3 4 5 reserved ATTRIB FULL HALF Do a bitwise "AND" of the sender pair with the receiver pair. Full Half 0 0 Kermit Classic 1 0 Full-duplex as defined now 0 1 Half-duplex extension to be elaborated 1 1 Either full or half * *If both, default to half; shouldn't happen because second send-init should pick one. Second, half-duplex itself: Create a new data packet type that says "this data packet is not the last in this group; don't answer yet". Thus the current standard DATA packet can be answered right away, and our current full-duplex definition is consistent. I'm suggesting the new packet type be called the WATA packet, and it would be just like a DATA packet except that it would mean "WAiT A minute, I'm not done sending this group, don't reply yet". A DATA packet (as in "DAT's All for this group, go ahead and reply") would signal the end of a particular group of packets. The above definition is consistent with both classic KERMIT and with the full-duplex windowing. As the receiver processed WATA packets, it would compose the ACKs and NAKs in the same manner as for full-duplex windowing, but buffer them for sending when the half-duplex line was turned around (indicated by receipt of a DATA packet). This system should use almost identical code for both full and half duplex windowing, and would (as you mentioned) make it very easy to debug in half-duplex and then move to full-duplex. Error handling, window rotation, etc. appear to remain the same, at least at first glance. We think the maximum half-duplex window size could be 63, instead of 32, but we aren't totally sure. Thanks again for your very helpful thoughts. Let me know what you think of the above. -John Mulligan ------------------------------ Date: Mon, 26 Aug 85 23:19:52 pdt From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa Subject: ANY-Duplex Windows Keywords: Sliding Windows Kermit, Long Packets Glad to hear from you, John! Here are my thoughts: Repeated for the benfit of others: > > First, the Send-Init packet. Define an additional bit in the capabilities > mask indicating half-duplex windowing: > > Bit 1 2 3 4 5 > reserved ATTRIB FULL HALF > > > Do a bitwise "AND" of the sender pair with the receiver pair. > > Full Half > 0 0 Kermit Classic > 1 0 Full-duplex as defined now > 0 1 Half-duplex extension to be elaborated > 1 1 Either full or half * > *If both, default to half; shouldn't happen because > second send-init should pick one. Yes, but I think that "1 1" should default to full duplex. Both sides are capable, so why not use full-duplex? (If you want to choose half-duplex with a pair of Kermits capable of either, "SET WINDOW HALF-DUPLEX" or some such command should cause only the half-duplex bit to be sent.) Both sides should also send a super-packet size (S) in the next byte following the window-size (W) byte. If half-duplex windows are selected, then the super-packet size used is the lower of the two super-packet sizes. Super-packet size must be less than or equal to half the window size (S <= W/2) : 1) We must have window size (W) >= 2x super-packet size (S) in case the first packet of a super-packet is lost (then the next super packet contains packet 1 plus packets S+1 through 2S-1). 2) We can only make use of W > 2*S in the case of multple retries for a particular packet. (This could be useful in very noisy environments...) The normal case (the program default) should probably be for S = W/2. Note that S may be more limited by a machine's input buffer size than by W (=~ memory size). It might be less than W/2 even for full duplex machines (i.e., how *long* can a full-duplex machine sustain a full speed input without any pauses?). Note that super-packet size is a maximum only. More repeated stuff: > > > Second, half-duplex itself: > > Create a new data packet type that says "this data packet is not the > last in this group; don't answer yet". Thus the current standard > DATA packet can be answered right away, and our current full-duplex > definition is consistent. > > I'm suggesting the new packet type be called the WATA packet, and it > would be just like a DATA packet except that it would mean > "WAiT A minute, I'm not done sending this group, don't reply yet". > > A DATA packet (as in "DAT's All for this group, go ahead and reply") > would signal the end of a particular group of packets. > > The above definition is consistent with both classic KERMIT and with > the full-duplex windowing. > > As the receiver processed WATA packets, it would compose the ACKs and > NAKs in the same manner as for full-duplex windowing, but buffer > them for sending when the half-duplex line was turned around (indicated by > receipt of a DATA packet). I'm not convinced that we gain by adding a new packet type. Note that we cannot send an EOL character to the half-duplex host between packets, because this causes the host to finish the read and probably miss the start of the next packet. On my system, at least, the system not only can't send while it's receiving, but, after completing a read, it doesn't buffer until a new read is issued for the line. System call overhead ensures that the next read will not be issued until well after several characters of the next packet have gone by, even if no processing is done on the packet in the meantime. (The alternative is XON handshaking between packets, which will defeat the whole pupose of super-packets. Note also, that we have not gotten away from XON handshaking between super-packets.) This means that when the kermit program on a half-duplex host gets the packet, an EOL has been received. EOL is a de-facto super-packet delimiter. As soon as the end of the super-packet (the EOL) is processed, the program knows it can proceed to reply. If one side is full-duplex, it can queue up ACKs and NAKs as it reads packets, but it must wait for the EOL (and probably XON) before sending them. I suppose that for a full-duplex host, WATA/DATA is a way of providing the higher-level protocol with the end of super-packet data which the half-duplex host gets implicity by the nature of its i/o system. It seems to me that making the send-packet routine wait for receiving routine to get an XON is sufficent, although this hides the super-packets from the packet-level protocol. Is there a reason to tell it? If so, perhaps the full-duplex kermit can implement a WATA packet internally: a DATA packet received without an EOL gets reported internally as a WATA, but only DATA packets are actually sent over the wires. I'm not real strong on this one way or the other; I'm just wary of adding packet types. As Bruce Cowan points out, a half-duplex receiver can NAK bad-checksum packets since it *knows* which packets were supposed to be sent (including which ones resent). I'm not sure whether this helps or not, since the absence of an ACK is just as sure an indication to the sender. *Something* (at least one ACK/NAK) does have to be sent, however, to let the sender know to retransmit. The best policy is probably to send only ACK's unless no good packets are received, in which case a NAK for the lowest-numbered outstanding packet may be sent. This has the advantage of agreeing with the full-duplex case, for best commonality of coding. It seems to me that where super-packets are most vulnerable is if the EOL (or the XON) is lost. In that case, my system, at least, will time out and throw away the whole super-packet! Some simple kluges will help here: send some padding followed by a second EOL character *after* each super packet if the padding parameter is non-zero. As long as we don't get into a situation where the end of the super-packet (and the EOL) is lost on every transmission, though, we still gain: the critical EOL characters are a lower percentage of the total characters sent. > This system should use almost identical code for both full and half > duplex windowing, and would (as you mentioned) make it very > easy to debug in half-duplex and then move to full-duplex. > > Error handling, window rotation, etc. appear to remain the same, > at least at first glance. I believe so, too. > We think the maximum half-duplex window size could be 63, instead > of 32, but we aren't totally sure. I'm not sure that the gain would be worth making it different from the full-duplex case. Ease of coding and all... One thing I have not thought about yet is how to integrate long packets with windows. Bruce makes a good case for allowing packets to be close to 128 or 256 characters to take advantage of public data network packet sizes. I lean towards using the published long-packet extension rather than his proposed special case for up to triple-size packets, though. It seems that the easy solution is to state that window and super-packet negotiations are really for windows of 94*W *characters*; when using longer packets, you must scale W and S down accordingly. This is not as flexible as one might wish for, though. Your turn! Ken Poulton Bit by bit, byte by byte, we'll figure it out... ------------------------------ Date: Tue 13 Aug 85 13:45:37-EDT From: Fuat C. Baran Subject: POPDOS2 and Kermit Problem Keywords: MS-DOS Kermit, popdos2 I have been testing some of the popups (Bellsoft) recently and I have found one problem. The problem occurs when I use Kermit (v2.28) and popdos2. Here is what happens: I install the popup and go into kermit. Until I use popdos2 (calling it up with ALT-U) I have no problems. Then I call popdos2 and do the following: I cd to a subdirectory and a dir *.* of the subdirectory. I then exit from popdos2 and continue with Kermit. I try transferring more files but later when I look at the files I see that they are all filled with garbage. The garbage looks like random characters and, here and there, file names of the subdirectory that I had done the dir on. I tried this several times and with different files and got the same results. Kermit works fine until I do the cd and dir sequence in popdos2. Any files transferred after that point come out as garbage. So far that is the only major problem I have encountered with popups. I minor irritation is the alarm clock feature in continuous display mode. Every time the screen scrolls up a line it moves the clock (I keep the display in the top right hand corner of the screen) up with it and then it redisplays it where it should be. (If you put the clock in some other place, on the bottom for example, then it scrolls up with the page and you get multiple displays on your screen.) Note: I have an IBM-PC with 256K and two disk drives. I use a TAXAN monochrome display with a Paradise Color Card (yuk! [The Paradise card has been giving me problems like substituting characters on my screen ("S." -> "S*" with the "*" flickering, etc...)]) --Fuat Baran BARAN@Columbia-20.ARPA ------------------------------ Date: Fri, 23 Aug 85 10:38:21 mdt From: rgt%a@LANL.ARPA (Richard Thomsen) Subject: Problem with MS kermit on DEC Rainbow 100+ Keywords: MS-DOS Kermit, DEC Rainbow I have (am currently) using MSKERMIT on my Rainbow 100+, connecting to a Berkley 4.2 UNIX system on a VAX. When I run the Rand Editor under Kermit, the cursor arrow keys do not work. When I run the Rand Editor using the Rainbow built-in terminal emulator, then the arrow keys work. I suspect that the Kermit program does not change the normal cursor keys to the application cursor keys, but it does so with the keypad keys, which work as expected. I have not had a chance to look extensively at the code, but I guess I could if that is desired. Richard Thomsen rgt@lanl.arpa [Ed. - In a pinch, you can always make a file that does "set key" commands for the cursor keys, and "take" the file whenever you want to run the editor.] ------------------------------ Date: 25 Aug 1985 0040-PDT From: Rob-Kling Subject: Leading Edge & Corona Portable -- Kermit Fit? Keywords: Leading Edge D PC, Corona Portable PC For reasons explained below, the new Leading Edge D machine might be an attractive PC compatable. As might also a Corona portable at about $1250. Has anybody had experience using recent MS-Kermits (2.27 or 2.28) with either of these machines. [I would also appreciate any comments on the compatability or ruggedness of these machines if anybody has relevant experience.] Some dealers in Southern California are pricing the Leading Edge D Machine rather aggresively -- with 640K, parallel & seriel port, Hercules-like board, hefty power supply, monitor & 2 DSDD drives ... about $1300-$1400. About $700 more for a 20MB Seagate or Rodine hard disk w/WD controller. They will also take off about 25% for universities...... making the floppy machine about $1150 and the hard disk machine about $1700. These are attractive prices..... if the machine works well, is about as compatable as anything else on the market, etc. (And if Leading Edge doesn't go under in its endless suits with Mitsubishi.) BTW. The machine has a small footprint and also comes with a 1 year warranty. Processor is an 8088 at 4.77 MHz. No speed demon, but the aim seems to be to aim at the highest cmpatability possible (Phoenix BIOS, ...). I would apprecaite any comments on the compatability, ruggedness of the Leading Eedge D machine from people who can share some recent experience. I am told that this machine is just coming to market and that it is better (?) than the earlier M machine which Mitsubishi manufactured for Leading Edge. I'll summarize key responses for the net. Rob Kling Department of Information and Computer Science University of California, Irvine kling@uci-ics-a PS. Corona has also recently dropped prices. I would also appreciate comments on the IBM compatability & general value of the Corona portables manufactured in the last year (since the ROM BIOS was changed because of the suit by IBM). ------------------------------ Date: Wed, 4 Sep 85 11:48:05 pdt From: Peter Ludemann Subject: Kermit for the Hyperion? Keywords: Hyperion Kermit Does there exist a version of Kermit for the Hyperion (also sometimes known as Bytec Hyperion or Anderson-Jacobson Ajile) running DOS2.11 (DOS1.x is acceptable)? The generic MS-DOS Kermit gets a "write error while reading from COM1" error - I suspect the problem is that the Hyperion uses a Zilog SIO chip instead of whatever the IBM-PC uses. Thanks in advance, Peter Ludemann ludemann@ubc-cs.uucp (ubc-vision!ubc-cs!ludemann) ludemann@cs.ubc.cdn (ludemann@cs.ubc.cdn@ubc.mailnet) ludemann@ubc.csnet (ludemann%ubc.csnet@CSNET-RELAY.ARPA) [Ed. - Generic MS-DOS Kermit should be able to work on any DOS machine. It uses only DOS calls for i/o, and has no knowledge of any chip. Try fooling with the SET PORT command, and maybe you'll stumble upon a device designator that will work.] ------------------------------ Date: Wed 14 Aug 85 08:52:52-PDT From: Wing Lee Subject: Solution to TSO Kermit vs 7171 Problem Keywords: TSO Kermit, 7171 Protocol Converters Good News! The problem we had with the Series/1 version of TSO-KERMIT has been solved. The problem we were having was that TSO-KERMIT would hang at random places whenever you tried to upload to TSO. One of our Systems Programmers, Valaine Saito, discovered what we think the problem is. What follows is Valaine's message to me. > i looked at the kermit through the 7171 problem again since it appears >that it really HAS to work if we're going to lose a s/1. i stumbled through >the assembler program, it looks like the logic is okay. after determining >that, i went to the s/1 and 7171 manuals to see what the difference was. it >turns out that there is NO logical difference, but there clearly is a >functional difference. > > both the s/1 and the 7171 have 64 char type ahead buffers. the s/1 must >handle it differently. when i have both the host and micro kermits sending >packet lengths of 60 (less than the 64 char buffer size), everything works >fine. when either of the kermits sends > 64 packet lengths, the familiar >"failure to receive ackn from host" msg appears on the micro and the transfer >stops. (all this pertains to file transfer from micro to host, i assume the >other way works since no one has said otherwise.) at 9600 baud, i ran a >largish file (60+ kb) through a number of times (10 or so) and it worked >every time with BOTH kermits sending packet sizes of less than 64. > > so the solution is to send packets of size X, where x is less than 64 >(i always tried sizes of < 64, i didn't try 64). the practical options >are: > > tell users about the packet length problem and have them set both > lengths themselves. > > re-code the host kermit to accept a max packet size of 63 or 64. > (this isn't too cool because only the receive section has the > problem. changing the max packet size would affect all > sections.) > > re-code the host kermit to utilize the RPSIZ variable correctly > and change the value to F'64' (or 63). RPSIZ is the max receive > packet size. I have tried sending packet sizes of 64 bytes and that works. When I tried 65 byte packets, the upload failed, so it looks like 64 is the magic number. wing lee [Ed. - For CMS Kermit, we will look into the possibility that the program can determine if it's a 7171 (it's not clear that it reports itself differently from a Series/1) and in that case use the smaller packet size.] ------------------------------ Date: Wed, 28 Aug 85 17:12 EST From: Jim Ennis Subject: Kermit with Yale ASCII? Keywords: Yale ASCII Communications Program What is the oldest version of the YALE ASCII communication package that can be used with Kermit for upload download (i.e. transparency)? We have an old turkey implementation using Yale ASCII V2.0 running under EDX V3.2..... It is my understanding that I need to go to a more recent version of the Yale ASCII support in order to utilize the transparency capabilities of that later version. Furthermore, I need to go to a more recent version of EDX before I can go to the more recent version of the Yale package. Information on this subject will be greatly appreciated...... The only reason this is an issue is be- cause we have only floppies on the box (no hard drive) and I want to get it right the first try. Sincerely. [Ed. - We run version 2.0 of the Yale ASCII package, and version 3.2 at update level P0A of the EDX Supervisor, and have experienced no problems. There was, however, a complaint from Larry Bierma@NPRDC in the last Info-Kermit digest, who claimed that file transfers through the Series/1 would "hang up" even though they worked fine through the 7171 or 3704.] ------------------------------ End of Info-Kermit Digest ************************* ------- 6-Sep-85 18:08:45-EDT,15713;000000000001 Mail-From: SY.FDC created at 6-Sep-85 18:08:13 Date: Fri 6 Sep 85 18:08:13-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #16 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 6 Sep 1985 Volume 3 : Number 16 Today's Topics: Downloading .EXE Files Which Destroy Monitor CR/LF Processing How to Make Kermit Work over European Packet Switching Networks Kermit on NEC 8001 Concurrent DOS Kermit New BITNET KERMSRV Command Syntax Kermit for Japanese Microcomputers and NTT Lisp Machine Kermit for Sharp PC 1500 A? ---------------------------------------------------------------------- Date: Thu, 15 Aug 85 11:58:49 pdt From: reynolds@AMES-NAS.ARPA (Don Reynolds) Subject: Downloading .EXE Files Which Destroy Monitor Keywords: .EXE File Transfer Welcome to a new user of Kermit on an IBM compatible! We like the frog a lot here, but he sometimes croaks! This may not be your problem, but the symptoms happened to me before. By mistake I used the host command: kermit s filename.ext which sends 7-bit ascii text files, but will not send 8-bit (image mode) executable (.COM & .EXE) files, Wordstar format files, or other binary files. The command for image mode is kermit si filename.ext If you try it without the "i" switch it really trashes the files, and gives the results Brzozowski states a couple messages down from your message. However, the file size still looks reasonable using the DOS DIR command. Question for the net: People have noted in this digest problems burning out the IBM monochrome display trying to execute such a file. I wonder if something like Norton's Utilities, U-File, or some other utility that looks at disk sectors or one that looks at memory can easily look at the header to see if the file has been trashed? Will DEBUG work? What do you look for? Note that I person- ally have only academic interest since we have mostly color monitors here, but someday I may have to download executables to a monochrome system. Best, Don [Ed. - The Kermit protocol allows file transmission in both text and binary mode. Text mode means that any necessary conversions are done on the file -- by both the sender and the receiver -- to make the file useful and readable on the target system. Binary mode means no conversions are done. Unfortunately, most Kermit programs have to rely on the user to specify whether a file is text or binary, because (a) the sending Kermit program usually can't tell because most systems (e.g. MS-DOS) don't provide this information in the file descriptor, and (b) the receiving Kermit certainly doesn't know (unless the sender informs it using the almost universally unimplemented Attribute packet). Now, it might be observed that text files tend to contain bytes whose high-order bits are all off, whereas binary files tend to have many bytes with this bit on. However, for the sending Kermit program to determine whether a file is binary by this method would require it to make a preliminary pass through the file (the WHOLE file if it turns out to be text) which would be undesirable for many reasons (e.g. timeouts when files are long). Many operating systems require executable programs to be in a certain format or to be tagged in a certain way, and will therefore not attempt to execute text files. But since not all OS's guard themselves in this way, users should also take precautions. On a case-by-case basis, heuristics can be added to some of the Kermit programs but they will never be foolproof. For instance, PDP-11 Kermit allows the use to specify a list of filetypes to determine the mode of the file -- but how can it know whether a .COM file is a DCL command file (text) or, say, a CP/M-80 program image (binary)?] ------------------------------ Date: Fri, 23 Aug 85 15:06:18 BST From: Chris-on-Fridays Subject: CR/LF Processing. Keywords: CR/LF Info: Is there an accepted policy about when Kermit should and should not do CR/LF (logical-end-of-record) processing? Obviously it is wanted in text-files and not in binaries. By default any 7-bit file is probably text, and any file sent as 8-bit image is probably not; but what assumption do you make if 8th-bit-prefixing is switched on? If the answer to the previous is "binary", shouldn't Kermits in general make it rather difficult to accidentally switch on 8th-bit-prefixing? And if the answer to that one is "yes", then is it wise for a Kermit server, or in fact any mainframe Kermit, to regularly offer 8th-bit-prefixing in its I-exchange? (This is suggested in the protocol manual.) Those of us who live on unix (with its LF as record-terminator) are keenly aware of the problems of files which come in with CR instead. Unsophisticated users tend to get absoultely floored; and it's they who are most likely to get into trouble if the two Kermits they are using do not, between them, pick sensible defaults. As an extension, what about the filing-systems which expect to find carriage-control-characters either at the start of each line (as per Fortran), or even at the end (older IBM formats)? Chris Kennington (cjk@ucl-cs) [Ed. - 8th-bit prefixing is totally unrelated to text vs binary mode. The prefixing mechanism is just a trick to squeeze 8-bit bytes through a 7-bit link. Most Kermit programs do (and should) enable 8th-bit prefixing automatically if parity is not none (i.e. is even, odd, mark, or space); it is a transmission technique akin to TELNET IAC doubling. All Kermit programs I know about run in text mode by default, and 8th bit prefixing is off by default except in systems (like IBM mainframes, or Prime computers) that always use parity. In Unix, text mode means LF/CRLF conversion is done, and it works Unix-to-anything, anything-to-Unix, so long as the "anything" Kermit is also in text mode. But see the discussion after the previous message about the perils of automatic mode selection. Systems that have carriage control or other "structured text" formats bear the responsibility for converting them to canonical (CRLF) format before transmission; VAX/VMS Kermit (the Stevens Bliss version) does this.] ------------------------------ Date: Fri, 30 Aug 85 10:12 MET From: Peter Bendall, DECUS VAX SIG Europe Subject: How to Make Kermit Work over European Packet Switching Networks Keywords: European Networks Since I started distributing 6800 and 6809 FLEX Kermits I have received MANY calls to say that Kermit is not able to work over the European packet switching networks. The following "work around" does however work for the German DATEX-P system and will probably work for other systems also: For Kermit-32 on VAX/VMS systems: Call the VAX using CONNECT and start Kermit-32, and issue the commands: SET RECEIVE START_OF_PACKET 7 SET SEND START_OF_PACKET 7 and then start the server if required. Then escape to your own Kermit and issue the equivalent commands: SET REC SOP=7 SET SEN SOP=7 (or whatever they look like) and then it works. [Ed. - Apparently DATEX-P does not pass through Control-A's, which are used by Kermit as the start-of-packet character.] In the case of the VAX systems, we have checked that the control-As are still in the packet when they reach our machine but we have found no simple way to get them into the packets... If anyone knows the proper workaround please let me know! ------------------------------ Date: Wed 28 Aug 85 11:17:59-PDT From: Ronald Blanford Subject: Kermit on NEC 8001 Keywords: NEC 8001 Some time ago there was a complaint that the Generic version of Kermit only partially worked on the NEC 8001. I had reason to need it recently and found the following fix which works quite well. Generic Kermit uses the iobyte to switch to the BAT console (which takes its input from the RDR device) so that it can check the serial port input status using the Console Status BIOS call. The BIOS therefore must check the iobyte twice in this situation, once to determine that the BAT console is in use, then again to decide which physical device RDR is set to. The NEC 8001 does this for the Console Input routine, but not for Console Status. The default Console Status routine always returns No Input Available, so that Kermit never tries to receive a character even though it can send them just fine. The solution is to patch the dispatch table for the Console Status routine so that it proceeds to the serial status routine instead of the default. It might be hard to determine the address of the status routine if RDR is set to the PTR, UR1, or UR2 device, but for the TTY device the address is just two entries earlier in the table to be patched. Fortunately Kermit uses the TTY device by default. On the NEC 8001, the serial driver is loaded dynamically, and the address of the status routine varies depending on which driver is used. Therefore this patch must be made each time the system is cold-booted, after installing the serial device driver but before running Kermit. It's easiest to make the patch into a simple program using DDT as follows: A>DDT DDT VERS 2.2 -A100 0100 LHLD 1 ; get the address of the BIOS jump table 0103 INX H ; step forward to the Console Status entry 0104 INX H 0105 INX H 0106 INX H 0107 MOV A,M ; get the address of the Console Status dispatcher 0108 INX H 0109 MOV H,M 010A MOV L,A 010B INX H ; step past the dispatcher's initial JMP instruction 010C INX H 010D INX H 010E MOV C,M ; pick up the address for the TTY Status routine 010F INX H 0110 MOV B,M 0111 INX H 0112 INX H ; step forward to the BAT entry 0113 INX H 0114 MOV M,C ; save the TTY address in the BAT entry 0115 INX H 0116 MOV M,B 0117 RET ; return to CP/M 0118 . -^C ; Now get out of DDT A>SAVE 1 KPATCH.COM ; and save the patch as a COM file With this patch program available, perform the following sequence of actions after cold boot to bring up Kermit: A>INSTALL8 IRS232A TTY: [,,,,O] ; install the driver as device TTY ; set up for Object files. The driver ; name may vary. A>KPATCH ; Patch the BAT status routine A>KERMIT ; Start Kermit With the interrupt-driven serial driver in place, this has worked perfectly for me at up to 9600 baud. Good luck. -- Ron [Ed. - Thanks, Ron! I've stored this message in the Kermit distribution as CP4NEC.HLP.] ------------------------------ Date: Wed, 4 Sep 85 03:14 EDT From: "John C. Klensin" Subject: Concurrent DOS Kermit Keywords: Concurrent DOS, MS-DOS Kermit PC-DOS Kermit seems to work fine under Concurrent DOS, with a few qualifications, as you expect. First, most of the 'internal' commands that require PC-DOS interactions don't work, e.g., LOCAL DIR (wildcard SENDs work fine). This is, of course, less of a problem under Concurrent than it would be under PCDOS, since, with Concurrent, you can switch processes and do anything of these things (or even keep the current directory or whatever in a handy window). Second, you must use SUSPEND=OFF if you expect to do transfers in background. Third, experience with the PC indicates that you may want to arrange a bit more waiting time and/or retry count maximum with your mainframe kermit if that is possible -- things sometimes get a little slow if there is a lot of other stuff going on in the machine, especially if kermit is a background, rather than foreground, process. I would suspect that this would be less of a problem on the AT, but haven't tried. I keep fussing with a CDOS-specific version of Kermit, based on the CP/M86 version when I manage to be around for more than a couple of weeks (not frequent in the last year). It is, of necessity, heavily dependent on the operating system, and is quite slow when it works. But this message is coming to you from a Concurrent DOS 4.1 system, using PC-DOS kermit, for whatever that is worth. If someone else would like to take that on, I would be happy to transfer everything I have done, and try to transfer everything I know/have found out, otherwise I will keep fussing as I have time. The combination of MSDOS kermit and Concurrent also worked fine under version 3.2 of the latter; versions before 3.2 are hopeless, since they don't support PCDOS mode. ------------------------------ Date: Fri 16 Aug 85 11:03:59-EDT From: Daphne Tzoar Subject: New BITNET KERMSRV Command Syntax Keywords: BITnet KERMSRV The syntax of Kermsrv commands has changed slightly so the file AANETW.HLP should be modified. Here is the command format: ? HELP SEND { DIR | fn ft | ?} PUNCH { DIR | fn ft | ?} Send returns information in netdata format. Punch uses punch format. If PUNCH is used, files with LRECL 80 or under will be punched Class A. The others will be disk dumped Class N. The DIR (directory command) has been replaced by SEND DIR or PUNCH DIR. File names may contain wildcards. Requests to Kermsrv can be either in the form of messages or reader files, where the file contains a single line with a valid Kermsrv command. /daphne ------------------------------ From: ihnp4!kddlab!nttmecl!nttmecl!NTT-20!MURAKAMI@seismo.CSS.GOV Date: 27 Aug 1985 2023 Subject: Kermit for Japanese Microcomputers and NTT Lisp Machine Keywords: Japanese Micro Kermit, NTT Lisp Kermit for Japanese micro computers is supported. Kermit for the following computers is available: (1) NEC PC8800 on CP/M-80 (2) NEC PC9800 on CP/M-86 (3) FUJITSU FM-8 on CP/M-80 (4) FUJITSU FM-11 on MS-DOS (5) IBM5550 on MS-DOS In addition to these computers, Kermit for NTT Lisp Machine ELIS was written by its language TAO. TAO is a dialect of Lisp which unifies an object-oriented programming paradigm and a logic programming paradigm with a procedural programming paradigm. NTT Lisp Machine (interpreter) runs 1.3 times faster than SYMBOLICS LISP MACHINE (compiler). If you are interested in these Kermits, please send me mail to hplabs!kddlab!nttmecl!murakami@Berkeley Is it useful for you to get Kermit sources for Japanese computers? I hesitate to send these sources because of the following reasons. (1) These Kermits will not be widely used in your country. (2) Kermit on CP/M-80 is based on the old Kermit version. We are translating an important part of the Kermit manuals into Japanese. I would appreciate if you'd allow me to distribute these manuals in Japan. Thank you for your attention [Ed. - Does everyone agree that the programs listed above are not of general interest outside of Japan? If not, I'll try to get them into the Kermit distribution.] ------------------------------ DATE: 26 Aug 85 1735 WEZ FROM: U02F%CBEBDA3T.BITNET@WISCVM.ARPA (Franklin A. Davis) SUBJECT: Kermit for Sharp PC 1500 A? Keywords: Sharp PC 1500 A Kermit Anyone know of a Kermit for the Sharp PC 1500 A? A colleague needs it, and unfortunately isn't even sure if it uses CP/M, but our guess is that it may be a close clone. Please answer directly. Thanks -- Franklin Institute for Informatics and Applied Mathematics University of Bern Laenggassstrasse 51 CH-3012 Bern Switzerland ------------------------------ End of Info-Kermit Digest ************************* ------- 10-Sep-85 17:43:14-EDT,21796;000000000001 Mail-From: SY.FDC created at 10-Sep-85 17:42:02 Date: Tue 10 Sep 85 17:42:01-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #17 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 10 Sep 1985 Volume 3 : Number 17 Special C-Kermit Edition: New C-Kermit Bug List C-Kermit on a 3B2 - Secure Line Locking Kermit/cu Incompatabilities on the 3B2 C-Kermit Speed on TRS-Xenix C-Kermit Performance with Parity C-Kermit Ideas C-Kermit Remote Server Commands Fail After an Abort Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032) Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057) Bug in C-Kermit Line Locking Bug Report For C-Kermit 4C(057) Problem Installing 4C(057) C-Kermit Take File Control and Background Operation C-Kermit on UTS vs the IBM 7171? Exiting "Protocol Mode" Gracefully ---------------------------------------------------------------------- Date: 10 Sep 85 17:00:00 EDT From: Frank da Cruz Subject: New C-Kermit Bug List Keywords: C-Kermit Most of the messages in this issue report bugs and problems with C-Kermit 4C(057), the current (since July 31) release for Unix. The problems are not urgent, so a new release has not yet been prepared. The problems have, however, been noted in the "beware" file, KER:CKUKER.BWR, available via anonymous FTP from Internet host CU20B. Some of the messages below are over a month old -- apologies; I'm still catching up from the backlog of mail after a long vacation. ------------------------------ Date: 16 Aug 85 23:01:39 GMT From: Robert Vidua Subject: C-Kermit on a 3B2 - Secure Line Locking Keywords: C-Kermit, 3B2 Kermit I just recently got C-Kermit 4C(055) and brought it up on a 3B2 running System V Rel 2. I'm trying to use it on a line that uucp also uses and I'm not sure how to do this without making a potential security problem and still giving ordinary users full access to the line. I don't want to modify the code. That leaves me with a two other solutions: 1) make kermit setuid to something (it doesn't handle this correctly (i.e. no 'setuid (getruid ())' or equivalent), so this isn't a valid solution) and 2) make the tty line as well as /usr/spool/locks readable and writable by everyone (nasty if someone decides to get malicious). I'm not too concerned about the 3B2, since I know/trust all the users on it (it's a intra-departmental machine), but I'll soon be bringing up the same kermit on a couple of 3B20s that's open to the whole campus and I'd like to solve the security problem first. About two or three months ago, there was a discussion on this very topic in fa.info-kermit which I, silly me, neglected to pay attention to. Now I need the information. Does anyone have an archive of those messages and is willing to send me a copy? Robert Viduya Georgia Institute of Technology UUCP: {akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert {rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert BITNET: CCOPRRV @ GITVM1 [Ed. - The discussions are in the Info-Kermit Digest V2 #11-12, #38-39, and V3 #2. You should be able to pick up the archives over BITNET via KERMSRV at host CUVMA -- V2 should be called "MAIL 85A" and V3 should be "MAIL TXT".] ------------------------------ Date: 3 Aug 85 16:00:12 EDT From: Eliot Lear Subject: Kermit/cu Incompatabilities on the 3B2 Keywords: 3B2 Kermit I am running kermit on an At&T 3B2 running System V.2. I don't know if I am repeating what someone said but we have discovered that cu requires a line be owned by uucp while Kermit requires that the line be owned by root. Since the everyday average user is not allowed to root, this presents problems. I imagine that this has something to do with checking to see if the line is active but I don't know. I figured I'd mention it to you, though. eliot lear [Ed. - See previous discussions of line locking.] ------------------------------ Date: Mon, 26 Aug 85 14:46 MDT From: RMark@DENVER.ARPA Subject: C-Kermit Speed on TRS-Xenix Keywords: C-kermit, TRS-Xenix Kermit After compiling the latest ckermit on TRS-80 Model 16b (v. 7 Xenix), I timed a transfer from VAX/VMS: 16 chars/sec. I then removed the -DDEBUG and recompiled. Now over 200 chars/sec at 4800 baud. [Ed. - As predicted in V2 #35, building the program without the debugging feature can result in a perceptible speed improvement -- but 1250% is more than just perceptible! I wonder if the difference is as great on other systems. In light of this report, it might make sense for every site to build the program both ways -- use the non-debugging version for production and the debugging version for tracking down & reporting problems.] ------------------------------ Date: 28-AUG-1985 12:17:47 From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa Subject: C-Kermit Performance with Parity Keywords: C-Kermit, Parity Here's a relayed note on C-KERMIT from Tim Green, Computer Unit, Warwick University UK. If you want to reply send it to me and I'll forward it. Alan Phillips Lancaster University Forwarded message: I've just put up C-Kermit 4C(057) and have some comments to make regarding its performance. The performance of C-Kermit on a VAX is fine when you use it with no parity. Typically I can get 480ch/s on a 9600 baud line. However due to the local net we have here we can't use it with no parity for binary files. As soon as you start to use parity the performance is greatly degraded. This is due to the way C-Kermit tries to detect whether parity is correct. If you do a profile of it while it is running you find that it is spending most of its time setting and unsetting a timer. There are two posible solutions to this. One: Do not test the parity, just assume that it is correct (leaving error detection to the checksum). Two: provide an option to set 7bit data when using no parity. We are using a VAX 780 with 4.2 Unix. [Ed. - You're right about the poor performance when parity is "on". It's because the program is doing single-character reads rather than reading an entire "line" (up to a carriage return). It does this because the terminating CR might have its parity bit on and therefore won't be recognized as a CR. A more clever scheme will used in a future release to speed things up. By the way, parity is not used by Kermit for error checking; rather, Kermit (unlike some other protocols) "tolerates" parity that is imposed upon it by the communication medium or one of the hosts involved.] ------------------------------ Date: Sat, 3 Aug 85 00:18:04 pdt From: "Scott Weikart; Community Data Processing; 415-322-9069" Subject: C-Kermit Ideas Keywords: C-Kermit Here's are some comments on items in the recent ckuker.bwr file. > - When connecting back to C-Kermit after a transaction, or after finishing > the server, it may be necessary to type a ^Q to clear up an XOFF deadlock. > There's not much the Kermit program can do about this... If XON/XOFF is enabled, why couldn't Kermit send an extra ^Q before exitting? [Ed. - The problem is in the other direction. The local PC needs to send a ^Q to the remote end. But you don't want the PC to do this automatically, because it might mess things up -- e.g. suppose the remote Kermit was invoked from within EMACS, which uses ^Q as a command, and has popped to EMACS upon exit...] > - ckufio 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. (Find out how Unix FTP does it...) How about forking a shell that's kept around, and communicating with it through pipes. This way you would only incur the fork and exec overhead the first time a file name is specified. Various EMACS's use this technique. In fact, it seems like this could also be used for the "!" command. [Ed. - Right, that's the idea. Any volunteers to submit some code for this that fits in the current framework and works for all versions of Unix? Would this technique work on small systems, e.g. small-memory PDP-11's?] ------------------------------ Date: Tue, 6 Aug 85 10:46:07 PDT From: rag@uw-june.arpa (David Ragozin) Subject: C-Kermit Remote Server Commands Fail After an Abort Keywords: C-Kermit Running C-Kermit, 4C(057) under 4.2BSD connected to MS-DOS 2.27 Kermit. With the C-Kermit side in server mode it responds properly to remote and remote host commands from the MS-DOS side. However, if I interrupt a remote command by typing a Control-C on the MS-DOS side, all further remote or remote host commands fail, except for "remote help". For instance, "remote dir" elicits the message "Can't list directory", "remote space" gives back "can't check space", "remote host...." leads to "can't do system command". Apparantly something on the C-kermit side has been left in a strange state by the abort. [Ed. - If you read the MS-DOS Kermit chapter of the Kermit User Guide, you'll see the explanation. ^C typed to MS-DOS Kermit during a file transfer returns to MS-DOS Kermit command level "immediately without sending any kind of notification to the remote system"; it's for use when, for instance, you give a "send" command but then realize you forgot to start up a Kermit on the other end. This means that the remote Kermit blithely continues with what it was doing, in this case sending data packets. If you waited for a couple minutes (after the other side timed out the maximum number of times) the situation would have cleared up by itself. If you have a real transaction in progress that you want to interrupt, then you should use ^X or ^Z, which most any Kermit server will honor. MS-DOS Kermit also provides a ^E interrupt, which sends an error packet to the remote side, which is guaranteed to stop any transaction (assuming it arrives).] ------------------------------ Date: Mon, 12 Aug 85 23:30:16 BST From: Ljwu@ucl-cs.arpa Subject: Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032) Keywords: C-Kermit I had a friend of mine in the US snork a copy of C-Kermit and post it to me on floppy disks. He must have grabbed 4C(056) just before 4C(057) was released and re-released (see Info-Kermit Digest v3 #10/12). Unfortunately, the ckctio file seems to lack rtime and gtime routines. I managed to patch together a working ckctio by including the appropriate lines of code from ckvtio.c. I hope that this oversight has been remedied in 4C(057). Script Command, V2.0(006) 14 Jun 85 [Ed. - It has.] As a footnote, the problem reported earler with wart on a Whitechapel (Info-Kermit Digest v2 #38) seems to have disappeared. Les J. Wu - ljwu@ucl-cs.arpa ------------------------------ Date: Tue, 13 Aug 85 17:37:10 PDT From: rag@uw-june.arpa (David Ragozin) Subject: Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057) Keywords: C-Kermit Setting: C-Kermit 4C(057) BSD version on VAX-11/7xx's under BSD4.2. Problem: When receiving multiple files a Ctrl-F discards the current file, and all subsequent files in the same batch. (The transfer of each subsequent file is started, and then aborted with a discarded message.) (I seem to remember a report of a problem of this sort a long time ago, but find no mention in the .bwr file. I have also reproduced the same behavior between 4C(056) versions.) [Ed. - Sure enough, it's a bug. Will note this in the .bwr file and fix in the next release.] ------------------------------ Date: 20-AUG-1985 10:29:51 From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa Subject: Bug in C-Kermit Line Locking Keywords: C-Kermit Forwarded message from Dave Osborne, Cripps Computing Centre, Nottingham U, UK There is a bug in the the Version 7 unix version of the program. The ckutio.c module, when opening the line (such as /dev/tty), in its "ttopen" routine, does an 'ioctl' call with parameter TIOCEXCL, to hold the line for exclusive use. Unfortunately, it doesn't bother to unset this condition before closing the line. [Ed. - This is fixed in the current release.] ------------------------------ Date: 28-AUG-1985 09:58:17 From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa Subject: Bug Report For C-Kermit 4C(057) Keywords: C-Kermit I've had a bug report passed to me from Icarus Sparry, Electrical Engineering Department, Bath University UK. Bug in C-Kermit 4C(057) and previous releases: File CKCFN2.C, routine SPACK If padding is in operation then it is inserted at the start of the packet before the ^A, as well as at the end of the packet before the EOL. However the values at the start of the packet are counted for the checksum, (except for the first) and the ^A is also included in the checksum. The workaround is to remember where the ^A is or to start the checksum after npad+1 characters. [Ed. - Oops! You're absolutely right. This will be noted in the .bwr file, and will be fixed in the next release. By the way, padding should only be sent before the packet, not after the end before the terminator -- I have no idea how that line of code got in there...] ------------------------------ Date: Wed, 4 Sep 85 16:42:51 cdt From: Dave Rasmussen Subject: Problem Installing 4C(057) Keywords: C-Kermit I have the version that supposedly corrects the 68000 architectural bugs mentioned by Frank da Cruz on Usenet, the one marked as: C-Kermit, 4C(057) 31 Jul 85, 4.2 BSD When I tell it to "set line /dev/t1570" where t1570 is owned by uucp and mode 666, kermit just hangs there. The problem is on a 68000 based Integrated Solutions box running 4.2bsd. I tried running as the superuser in case there were any file conflicts, but this doesn't change things. I do have this version running on a Vax 750 with 4.1bsd and it talks to remote lines with no problems or other modifications. Any suggestions, or anyone else had these problems? It may well be our environment, but I think I've looked it over thoroughly. Dave Rasmussen, CSD University of WI - Milwaukee [Ed. - Can anyone with a similar system offer any advicde?] ------------------------------ Date: Tue, 3 Sep 85 18:22:15 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) Subject: C-Kermit Take File Control and Background Operation Keywords: C-Kermit When I read the contents of the current ckuker.bwr file, with particular attention to the two items I have previously commented on, I noticed someone had added editorial comment to each item indicating that this message is necessary. Though my original message, which included code, also covered my reasons for the suggestions, I'll repeat the reasons here. Some users report that it would be more desirable to have an error during execution of a take file return directly to command level, rather than pop to the invoking take file (why?). Kermit has no flow-of-control commands to be used in TAKE files. It is therefore impossible to write a TAKE file which does something intelligent if a file IT TAKEs should die. The result of that fact, and of the way the unmodified Kermit works, is that multiply nested command files with an error at the bottom level die a slow and painful death, wasting the user's time until they work their way back up to the top level. In background, this is particularly wasteful, since there is noone to hit ^C to end the nonsense. My proposal, which I have implemented at our site, is simply a matter of euthenasia for terminal TAKE files. Where the Columbia-issue command processor closes the current TAKE file and pops one level, I have put in a while statement which makes it keep closing and popping until interactive command level is reached. [Ed. - Actually, what is needed is a "set" command to control whether this is done, with which users can "declare" some errors fatal and others not. The DEC-20 Kermit script facility has something like this.] Some users report that the program should make no internal distinction between running in foreground or background (why?). Release C-Kermit attempts to determine if it is in background by checking if its parent has set SIGINT to SIG_IGN. That is not a completely reliable indicator of being in background, and furthermore, why would it want to know if it is in background? [Ed. - So it would know whether or not to issue messages to the user's screen. If in background, attempting to print a message to the screen freezes the the process.] The release version changes its behavior in a couple of ways as a function of whether it thinks it is in background. It sets several signals to be ignored (which are ignored by default for background anyway), and it decides to abort immediately on any command failure from standard input (which prevents graceful termination of a remote server). Incidently, this is the only way release C-Kermit generates a return value of BAD_EXIT. Because C-Kermit's changed behavior in background made it difficult to debug scripts intended to run in background, I changed ours so it doesn't try to be different in background. Ours ALWAYS returns a status value on exit. The status value is always GOOD_EXIT if no commands have failed, and BAD_EXIT, otherwise. That makes it easy to debug a shell script which uses a while loop to retry Kermit a number of times. When a command from standard input fails, our C-Kermit sets the eventual returned status value to BAD_EXIT and keeps going, so later commands can gracefully shut down a remote server, if any. Over all, I believe our two changes have made C-Kermit much more civilized, particularly when run from a script. If Columbia would like diffs for our changes, I would be happy to send a more recent set. [Ed. - Dave has sent the diffs; does anyone else have any opinions on these issues? Meanwhile, I'll add a little more in the way of rationale to the comments in the .bwr file.] ------------------------------ From: ihnp4!inmet!ada-uts!mule@seismo.CSS.GOV Date: 9 Aug 85 17:08:39 CDT (Fri) Subject: C-Kermit on UTS vs the IBM 7171? Keywords: C-Kermit, UTS Kermit, 7171 Protocol Converters I am under the impression that the CMS version of Kermit knows how to talk through the IBM 7171 protocol converter. The 7171 allows ascii devices (terminals or pc's running terminal emulation programs) to look to the IBM host like an IBM 3270 type terminal. We (at Intermetrics Inc 733 Concord Ave Cambridge Mass 02138) are running UTS on a 3083 IBM host with a 7171 attached. We would love to run a Kermit that knew about the 7171 and was able to send files back and forth through it. So: * Is it true that the CMS kermit knows how to do this ? [Ed. - Yes.] * If so, how hard would it be to add this capability to UTS Kermit ? [Ed. - I believe Philip Murton at the University of Toronto (MURTON@UTORONTO.BITNET) has done this, or knows someone who did. The UTS code uses a different technique (escape sequences) than CMS Kermit (CCW programming).] * Are there any plans to do so? [Ed. - Philip, do you have this code for the current, or a recent, release of C-Kermit?] * Would you like us to take a shot at it (and where do we go for help when we need it) ? [Ed. - Let's see if/how Philip responds. If we don't hear from him, we'll try to dig up the code he sent us long ago for the old Unix Kermit.] Thanks, Fred Mueller (617) 661-1840 PS Thanks in general for devoting so much energy on such a worthwhile cause. I hope you get lots of kudos for it. ------------------------------ Date: Sat, 7 Sep 85 02:49:35 edt From: ukma!sean@anl-mcs (Sean Casey) Subject: Exiting "Protocol Mode" Gracefully Keywords: C-Kermit I think that C-kermit should have some provision for completely aborting the protocol from the terminal. When one is trying to figure out which parity, flow control, handshaking, etc. settings to use with new computer, a considerable amount of time may be spent waiting for the local kermit to give up on the transfer. CTRL/F and CTRL/B are provided to abort a transfer in progress, but there is no way to abort the protocol without also exiting kermit (and losing dtr on the line). I'd like to see another control sequence, perhaps CTRL/X, that would cause the local kermit to immediately exit the protocol and give the command prompt. Then, when one is debugging a kermit conversation, the protocol could be easily aborted as soon as the debugger sees that the two kermits aren't talking correctly. - Sean Casey UUCP: sean@ukma.UUCP or - Department of Mathematics {cbosgd,anlams,hasmed}!ukma!sean - University of Kentucky ARPA: ukma!sean@ANL-MCS.ARPA [Ed. - I agree, this has been noted in the .bwr file for some time. MS-DOS Kermit has a couple options for this which are missing from C-Kermit. They should be added in future releases.] ------------------------------ End of Info-Kermit Digest ************************* ------- 12-Sep-85 18:40:09-EDT,17249;000000000001 Mail-From: SY.FDC created at 12-Sep-85 18:39:42 Date: Thu 12 Sep 85 18:39:42-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #18 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 12 Sep 1985 Volume 3 : Number 18 Today's Topics: Announcing LM-KERMIT for Lispmachine Lisp Environments Kermit Diskette Distribution HP110 Kermit Binaries & MSIBMP.BOO Name Problem NEC PC8800 (not 8001), APC III, & other Japanese Kermits Kermit and the Far East Kermit and the European Packet Switching Services Kermit on X.25 and Similar Networks Kermit over Networks CMS Kermit with 7171's Behaviour of MS-Kermit 2.28 on a COMPAQ Portable Kermit for Exxon Office Systems 500? Kermit for Cromix and the NCR DMV? MS-DOS Kermit for the Gavilan PC? ---------------------------------------------------------------------- Date: Wed, 11 Sep 85 19:04:27 EDT From: George J. Carrette Subject: Announcing LM-KERMIT for Lispmachine Lisp Environments Keywords: LM-Kermit, Lisp LM-KERMIT KERMIT and terminal emulation capability for ZetaLisp based lispmachines. LM-KERMIT was implemented by Mark David of LMI (Lisp Machines Inc). The use of KERMIT on a lispmachine can fill the gap between sophisticated (and expensive) networking hardware and software available on lispmachines and the other extreme, NO NETWORKING. What we found is that many mainframe/ minicomputer installations take a long time to purchase and install something like ethernet TCP-IP, but that KERMIT shows up almost everwhere, already installed or in some users directory. There are presently available two versions: * bundled with the LMI-LAMBDA. It supports terminal emulation, KERMIT, and serial connections via RS-232, TCP-IP (TELNET), etc. Also provided is a HOST/MAINFRAME emulation capability so that PC's can log into the machine and use SERVER mode. * A port to the Symbolics 36xx machines done by Mark Ahlstrom of Honeywell. It supports terminal emulation, KERMIT, and serial connections via RS-232. The source is conditionalized in the usual manner, #+LMI, #+SYMBOLICS. There are a few #+TI conditionalizations although they have not been tested. A user of the TI (Texas Instruments) Explorer should be able to bring LM-KERMIT up by changing most of the #+LMI conditionalizations to #+(OR LMI TI). A word about the programming style used. Don't expect anything exemplary. Parts of the code are a quick hack off of KERMIT.C, and much of the window system code is a mix of "doing while learning" combined with later added sophistication and hair. Compiling the source gives style warnings of various severities on both the LMI and Symbolics machines. However, the number of phone calls I've been getting on this has forced us to either tell people to go away or provide what we have now. The port that Ahlstrom did to Symbolics Release 6.0 was also of the "conditionalize into the source the equivalent Symbolics function name or feature" rather than the other more slow route of "rewrite things to use mainline Common-Lisp functions." However, now that it is out people will no doubt be improving things. -gjc [Ed. - The files are in KER:LM*.*, available via anonymous FTP from CU20B.] ------------------------------ Date: Thu 12 Sep 85 12:43:33-EDT From: Frank da Cruz Subject: Kermit Diskette Distribution Keywords: Kermit Diskettes As anyone who has received a Kermit tape knows, bootstrapping the microcomputer versions from the tape is a tricky, frustrating business. It's even trickier if you don't have a computer with a tape drive. To ease the pain, we are preparing to make it easier for people to get Kermit programs on diskette; we expect to be able to distribute IBM PC and Apple Macintosh diskettes ourselves, and we'd like to compile a list of other sources for diskettes or other "native media". If you know of a user group or other organization that distributes Kermit on native media for a particular system (e.g. a Heath-89 user group, a TRS-80 user group, etc), please send me the information that would be needed to order Kermit from that organization -- Address, pricing, order number, etc, plus phone number (so I can verify the information and their willingness to act as distributor). Also, if you belong to a user group that could be distributing Kermit but isn't, maybe you could submit it. Individuals are also welcome to volunteer to distribute diskettes -- as some already have been doing for the Apple II and Commodore 64 -- but when addresses and ordering information are published, the demand might exceed the ability of a single individual to meet it. Of course, any person or group that distributes Kermit should not be doing it for profit; the cost should be designed only to recover expenses for media, postage, packaging, etc, plus a little margin to allow for expansion when demand outstrips capacity. P.S. If you can't reply by netmail, send it to me at Columbia University Center for Computing Activities 612 W. 115th Street New York, NY 10025 ------------------------------ Date: Wed 31 Jul 85 19:25:38-PDT From: Jim Lewinson Subject: HP110 Kermit Binaries & MSIBMP.BOO Name Problem Keywords: HP110 Kermit According to the documentation, KER:MSIBMP.BOO is supposed to be MSIBMPC.BOO. I suppose it got truncated to make it 6 characters, but AAFILES.HLP should be updated. [Ed. - Thanks for pointing this out, will change AAFILES.HLP.] Also, you find an (old) .EXE file for the HP-110 MS-DOS kermit on [SU-GSB-WHY] WHY:MSHP110.EXE. It is based on an old version of the source code, and I'm not sure how well tested it is, but maybe it will help someone more than nothing. Maybe when I get back to the west coast I can get someone working on rebuilding it with the latest sources. Jim [Ed. - Thanks. The 8-bit binary .EXE file is now available as KB:MSHP11.EXE, and a hex encoding (straight two-hex-digits per 8-bit byte) is in KER:MSHP11.HEX. There is also source and documentation which may or may not correspond to the binaries in KER:MSXHPX.*.] ------------------------------ Date: Fri 6 Sep 85 22:33:03-PDT From: Ronald Blanford Subject: NEC PC8800 (not 8001), APC III, & other Japanese Kermits Keywords: Japanese Micro Kermits, NEX PC8800 Kermit, APC III Kermit The NEC 8001 Generic Kermit-80 patch had a slight error, not in the patch, but that the machine is in fact the NEC PC8800. I got confused by the multiplicity of models I deal with. (I don't believe there is an 8001.) As for the offer of source for Japanese computer Kermits, the NEC PC8800 has been extensively sold in this country so that source may be useful. The PC9800 is sold here (with differences) as the APC III, which supports only MS-DOS, making a CP/M-86 Kermit of no use. I don't know about the other models mentioned. I received an MS-Kermit system module for the APC III (MSXAPC3.ASM) from someone at Virginia Tech (VPI&SU). I haven't seen it included in your lists, so I wonder if you ever got a copy. It seems to work acceptably with version 2.28. I can make it available if you wish. -- Ron ------------------------------ Date: Sat, 07 Sep 85 16:50:22 cet From: ZDV626%DJUKFA11.BITNET@WISCVM.ARPA Subject: Kermit and the Far East Keywords: Japanese Micro Kermits There are some Fujitsus and NECs over here in Germany. I would appreciate if you could put at least the MS-DOS version on CUVMA. I have requested Mr. Murakami to send it direct, but I don't know, really if it will work. (usenet-BITNET) Eberhard W. Lisse [Ed. - I tried too, but got mailer replies back with messages like "Too many hops"...] ------------------------------ Date: Sat, 07 Sep 85 16:21:39 cet From: ZDV626%DJUKFA11.BITNET@WISCVM.ARPA Subject: Kermit and the European Packet Switching Services Keywords: European Networks I have no problems at all with the European packet switching service. I have had no trouble on the Datex-P after setting both Kermits to SET PARITY EVEN I have used the following hardware: IBM-PC DOS 2.11 KERMIT 2.28 OSBORNE 1 CP/M 80 KERMIT 4.05 RAINBOW DOS 2.?? KERMIT 2.26 VAX 11/780 VMS 3.7 4.1 KERMIT 3.0.055 3.0.066. CYBER 175 NOS KERMIT ??? IBM VM/CMS KERMIT 2.?? ( If I dial my BITnet host [the IBM] through Datex-P I have to set my local parity to even. I don't set anything on the IBM. If I do it from any machine through at the Technical University or from the University Hospital I have to set the local parity to MARK. This indicates that Datex-P forces the parity to EVEN. I can't get our PDP-11/44 RMS-X11M with the new KERMIT to file transfer. CONNECT works, but now way of getting one single packet over to the IBM or back. Doesn't bother me though, as I'm doing the file transfer with the VAX anyway due to a faster line.) [Ed. - I believe newer versions of PDP-11 Kermit handle IBM communications a little better.] Same thing works for Telenet I am told by LBAFRIN@CLEMSON.CSNET who had a mail the other day. Eberhard W. Lisse ------------------------------ Date: Wed, 11 Sep 85 11:15:18 BST From: "Chris.K.Now-and-Then" Subject: Kermit on X.25 and Similar Networks Keywords: European Networks Peter Bendall's suggestion (infodig 16) of substituting BEL (07) for SOH (01) as Kermit start-of-packet is an interesting kludge, but not quite the canonical way of dealing with the problem (of how to work Kermit across text-line-oriented networks). Admittedly almost any (terminal) network will pass BEL, for obvious reasons; but bridges, PADs etc. often feel free to add BELs if they see fit. What about a PAD which stuck a BEL into any "overlength" line? I regularly Kermit large files over UK JANET, which uses XXX (X.3, X.28, X.29) above X.25. In normal terminal (line) mode, SOH will be stripped. The easy answer is to switch to character (transparent) mode, in which case all control characters are passed through "as sent". For XXX this is in fact overkill, since there are parameters to specify which control chars are to be passed; but it is straighforward and always supported on the user interfaces; it also switches off local echo, which is desirable. In principle character-mode could result in Kermit packets being sent as several blocks each; this does not in fact happen when using a standard JANET PAD, due to the forward-on-timeout strategy employed. I believe that every terminal network protocol includes a transparent mode, so the solution is generally applicable. Chris Kennington. ------------------------------ Date: Sat, 7 Sep 85 13:52:05 edt From: Mike Ciaraldi Subject: Kermit over Networks Keywords: MILNEY, TELENET Two messages in Info-Kermit digest volume 3, number 14 asked about file transfers over Milnet and Telenet. I haven't used either of these, but the symptoms sound like a problem I have run into before. Sometimes you are able to log on, start up Kermit on the remote machine, and give it commands like "DIR" with no trouble. But when you try to do a file transfer your local machine just sits there until it times out, as if no packets are being received either way. When this has happened to me, I can usually get it to work by EXPLICITLY setting the parity of both Kermits, local and remote. Naturally, if your communications channel (e.g. Telenet) enforces a particular parity (e.g. even), you have to set the Kermits to match each other and the comm channel. Parity being slightly off doesn't seem to affect commands like DIR, but file transfers and other things that use packets cannot handle it because the checksums, 8th-bit prefixing, and so on are thrown off. Thus no packets get through. Mike Ciaraldi ciaraldi@rochester seismo!rochester!ciaraldi ------------------------------ Date: Tue, 10 Sep 85 09:03:52 EDT From: ostrove@umd5 (Steve Ostrove) Subject: CMS-KERMIT with 7171's Keywords: VM/CMS Kermit, 7171 Protocol Converters We are in the process of testing out our 7171's with CMS. Although I haven't done extensive testing, yesterday I transfered a 65K file using KERMIT-MS on one side and KERMIT-CMS on the other (versions 2.28 and 2.01 respectively). The transfer was using a packet size of 94 (default). I had no problems. It would seem therefore that the problem with packet size and TSO, may be a problem unique to TSO and the 7171's. I will attempt to do more extensive testing of them soon. On a different note. When we put KERMIT-CMS into server mode, it does not seem to respond to any terminating command with the exception of FINISH. Neither LOG or BYE works. Is this normal?? Sincerely, Steve Ostrove User Services Staff The University of Maryland Computer Science Center Ostrove@umd5.ARPA [Ed. - Thanks for the information. No, CMS Kermit is supposed to log itself out upon receipt of a BYE request, and it does so nicely on our CMS system. No one here can think of a reason why it would fail to do so. Can anyone else?] ------------------------------ Date: Mon, 9 Sep 85 13:40:34 BST From: Ljwu@ucl-cs.arpa Subject: Behaviour of MS-Kermit 2.28 on a COMPAQ Portable Keywords: MS-DOS Kermit, COMPAQ Portable I have encountered a slight bios incompatability between a real IBM PC/XT and a "Compatable" Compaq Portable. In short, MS-Kermit v2.28 with bug fixes as advertised in .BWR file work fine on the XT. The problem, however, is that when sending or receiving files, the Compaq displays a blank inverse video mode line with a single spurious character ('s') above the transfer status displays. The mode line displayed during connection appears normally. The information normally contained in this mode line is rather important in that it gives the user information on how to abort an active file transfer. After some digging, I traced the problem to the routine 'putmod' in MSXIBM.ASM. As I don't have documentation on the bios interfaces I did a simple backout to the putmod routine in version 2.27. Below are the affected lines: Original version 2.28 code: call poscur pop si ; get message back putmo1: lodsb ; get a byte cmp al,'$' ; end of string? je putmo2 mov ah,14 ; write to screen mov bx,07000h ; inverse video, page one int bios jmp putmo1 putmo2: ret ; and return putmod endp Version 2.27 backout: call poscur pop dx ; get message back mov ah,prstr int dos ret putmod endp This fix works fine for the COMPAQ. On a real PC, however, the information line is displayed in normal video. At least this backout provides the user with the necessary information in all cases. Has anybody else experienced this anomolous behaviour with a Compaq or have an explanation for the incompatability? -- Les J. Wu ------------------------------ Date: Fri, 6 Sep 85 15:19:48 edt From: Bob Sutterfield Subject: Kermit for Exxon Office Systems 500? Keywords: Exxon Office System 500 Kermit The secretary across the hall has recently been blessed with an Exxon Office Systems 500 Series word processor. It apparently crunches words nicely enough, but its facilities to talk to the outside world are severely limited. It has some sort of asynchronous communications software, but this won't do the job for us. I don't know what kind of processor it has, nor what operating system it runs. We really need to get several hundred pages of publications off this beast, and onto a usable machine. Does anybody know of pointers to a Kermit for this beast? ------------------------------ Date: Mon, 09 Sep 85 03:37:14 cet From: ZDV626%DJUKFA11.BITNET@WISCVM.ARPA Subject: Kermit for Cromix and the NCR DMV? Keywords: Cromix Kermit, NCR DMV Kermit Any information regarding Kermit for Cromemco Cromixor the NCR Decision MATE V ? Eberhard W. Lisse ------------------------------ Date: Tue, 10 Sep 85 14:08:18 PDT From: rich@CIT-Hamlet.ARPA Subject: MS-DOS Kermit for the Gavilan PC? Keywords: MS-DOS Kermit, Gavilan PC A professor here has the Gavilan PC with the 3" drives. Has anyone successfully run MS-DOS Kermit on one of these, and if so, can we possibily get a copy of the disk? Thanks is advance, Rich Fagen Caltech Computing Support rich@cit-hamlet.arpa rich@hamlet.bitnet (818)-356-3896 ------------------------------ End of Info-Kermit Digest ************************* ------- 13-Sep-85 18:16:56-EDT,17716;000000000001 Mail-From: SY.FDC created at 13-Sep-85 18:16:20 Date: Fri 13 Sep 85 18:16:20-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #19 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 13 Sep 1985 Volume 3 : Number 19 Departments: MACINTOSH KERMIT - New Macintosh Kermit Bug List Macintosh Kermit VT100 Emulation Bottom-of-Screen Bug Garbage in Upper Left Corner on MacKermit MacKermit Comments MacKermit/ScreenSaver Incompatibility MacKermit Transfer Command Macintosh Kermit Key Configurator Limitation Mac Kermit Show-Response Window Too Narrow Bug and Nit in Macintosh Kermit Terminal Emulation Bug In Mac Kermit Double Keying Option-Keys in Mac Kermit Mac Kermit vs Yale ASCII IBM MAINFRAME KERMIT - Kermit for UTS with Series/1 CMS Kermit with 7171's (two messages) Kermit-11 vs IBM VM/CMS MISCELLANY - Kermit Distribution in the UK ---------------------------------------------------------------------- Date: Fri 13 Sep 85 17:24:56 EDT From: Frank da Cruz Subject: New Macintosh Kermit Bug List Keywords: MacKermit The following messages report bugs in the current release of Macintosh Kermit, or suggest improvements. These have been noted in the new "beware" file, KER:CKMKER.BWR, which is available via anonymous FTP from CU20B. For now, no changes are being made to the program, mainly because Mac Kermit is still "between maintainers". Although not mentioned specifically in conjunction with Mac Kermit, the C-Kermit bug reported by Icarus Sperry (Bath Univ, UK) in Info-Kermit V3 #17, namely that checksums are computed incorrectly if padding is selected, applies also to Macintosh Kermit. ------------------------------ Date: Thu 15 Aug 85 11:12:12-CDT From: Don Nash Subject: Macintosh Kermit VT100 Emulation Bottom-of-Screen Bug Keywords: MacKermit, Terminal Emulation I just found found this simply wonderful bug in Macintosh Kermit. Here's how to do it: 1) Set MacKermit 0.8(33) for 9600 baud, no parity, remote echo. 2) Connect to a VAX 11/780 running VMS 4.1 and Eunice and log in. 3) Set your terminal type by having the following lines in your LOGIN.COM file: $define TERM "vt100" $set term /dev = vt100 /line 4) Type out a file which is long enough to fill the screen more once using the following command: type /page filename.ext 5) When you are prompted to hit return, type ^C. The word "Cancel" should appear, but it should be partially below the screen. 6) Type several times. If you get the same results I did, then the screen of the Mac should go crazy. It looks like snow on a TV set, except that it is black snow on a white background (which seems logical, since the Mac's screen is white). The Mac is now completely wedged, the cursor does not respond to mouse movements. The only way out is to reset the Mac and restart MacKermit. Also, the number zero and the capital letter oh were identical on MacKermit, and the same applies to the capital letter "I" (the letter after "H"), and the lowercase letter "l" (the letter after "k"). They are also *exactly* the same. Don Nash [Ed. - Thanks, noted in the beware file.] ------------------------------ Date: Thu 15 Aug 85 12:25:26-CDT From: Don Nash Subject: Garbage in Upper Left Corner on MacKermit Keywords: MacKermit I read the file CKMKER.BWR.8. In the section UNDIGESTED, item #3 said that Dan Tappan from BBN reported garbage in the upper left corner of the terminal emulator window which eventually went away. I have the same problem, but it won't go away. It is nothing serious, but it does seem to be permanent on my copy of MacKermit 0.8(33). It does not interfere with the display in any way. Hope this aids in digestion. Don Nash ------------------------------ Date: Mon, 19 Aug 85 11:45:56 PDT From: msev%Phobos@CIT-Hamlet.ARPA Subject: MacKermit Comments Keywords: MacKermit I'm very pleased with the new MacKermit release. I use it now in preference to MacTerminal. I like the speed: both initialization and operation are much better than MacT. I have set up the key map to send the right characters for EDT. File transfer with VMS is very smooth. - Martin Ewing Comments on 0.8(33) Kermit for Macintosh: SERIOUS 1. The VMS TYPE/PAGE command types a page of output from a file and types "Type enter to continue" (or some such) in reverse video on bottom line of screen. If you ^Y at that point to terminate, Kermit writes the next line ("Interrupt" in reverse video) on what appears to be line 25. Kermit often dies shortly thereafter. I don't have the exact character sequence that VMS is putting out. [Ed. - Same as Don Nash's bug. Temporary workaround: don't use VMS (just kidding...)] NUISANCE 2. Screen is not thoroughly wiped by erase screen command. Garbage characters left at right of screen (sometimes). This may have been documented before. 3. A blinking cursor, or, better, a blinking solid cursor would be a great help. It's nearly impossible to find the underscore in a page full of text. A user-selectable cursor format would be preferable. [Ed. - Good idea.] SUGGESTIONS 4. It would be handy to distribute a standard VT100/numeric keypad definitions file. This is important for running the VMS EDT editor. I'll donate such a file if requested. [Ed. - Please do.] 5. Apparently the VT10x graphics characters are not emulated. At least the MONITOR command on VMS does not produce the desired line and block characters. This would be a useful addition for those of us who like to stare at these status displays. 6. Emulate the VT102 printer port commands. ------------------------------ Date: Thu, 8 Aug 85 10:14:02 mdt From: jad%b@LANL.ARPA (John De Vries) Subject: MacKermit/ScreenSaver Incompatibility Keywords: MacKermit I have received a report that while making long uploads from MacKermit while ScreenSaver (a desk accessory) is active will cause the upload to bomb and will indeed screw up the Mac's system, necessitating a reboot. It happens when ScreenSaver goes and blanks the screen... Zoz ------------------------------ Date: Fri 9 Aug 85 16:55:15-EDT From: Don Lanini Subject: MacKermit Transfer Command Keywords: MacKermit Whenever I try to use the transfer command under the transfer menu to launch an application from another disk (a disk other than the one Kermit is on), it blows up the machine with an ID = 26 error and hangs. The version is 0.8(32) ------------------------------ Date: Wed 19 Jun 85 16:30:52-EDT From: Bill Schilit Subject: Macintosh Kermit Key Configurator Limitation Keywords: MacKermit I just read a message on the net... you might want to configure a system disk with the Dutch or German, or French international resources and check out the results of this on MacKey... I think the result will be an incorrect keyboard (check this out in relation to the KEYCAPS display). Since the key names are hard coded in an array in the program... ------------------------------ Date: Tue, 9 Jul 85 18:43:58 edt From: Mike Ciaraldi Subject: Mac Kermit Show-Response Window Too Narrow Keywords: MacKermit When you give a remote command (e.g. Directory) to a server, the results come up in a window. You can scroll the window from side to side, but even if you move it all the way to the left (i.e. the little box in the horizontal scroll bar is all the way to the right), you still can't see the right end of the line of text. You have to stretch the window to see it. [Ed. - I agree this might not be intuitively obvious to the user...] When you do a "Get file from server", after the transfer is complete the box that keeps you informed of the progress of the transfer still stays on the middle of the screen until you click on it. This is not really obvious as the way to continue. What makes it bad is that the mouse pointer still shows as the little clock face indefinitely, implying that you ought to wait before proceeding (maybe while it closes the file or something). [Ed. - Right, this has been noted in the .BWR file all along.] ------------------------------ Date: 23 Jul 1985 02:04 PST From: Charles Carvalho Subject: Bug and Nit in Macintosh Kermit Keywords: MacKermit A friend pointed out a bug and a nit in the Macintosh Kermit: bug: if you call SFGetFile with the numTypes argument equal to zero, it apparently doesn't find all files; numTypes should be -1 instead. [Ed. - From one of the authors: "I haven't noticed any problems, and I believe the code reflects the documentation." Has anyone actually observed files being skipped over?] nit: the Close box at the left of the MacKermit window doesn't do anything; it ought to be left out (define the window with the NoGoAway attribute). /Charles ------------------------------ Date: Wed 31 Jul 85 15:18:44-EDT From: Ben Fried Subject: Terminal Emulation Bug In Mac Kermit Keywords: MacKermit, Terminal Emulation I don't know if i can reproduce this, but i definitely found a bug in mac kermit 0.8(33) I was in emacs, typing a command into the echo area, when a send came in. the first few scan lines of the text showed up at the bottom of the screen, then it froze--i had mouse control, but the event handler must have frozen, because i got no response to any sort of update event -- keydowns, clicking the mouse, whatever. it looks like it didn't handle the scrolling of the text i was sent correctly, and died somewhere in there. but i'm not sure. [Ed. - "Doubt it was the event handler, more likely it is a scroll problem with the characters being drawn off the screen." Noted in .BWR file.] ------------------------------ Date: Sat, 7 Sep 85 19:10 MST From: Barry Margolin Subject: Double Keying Option-Keys in Mac Kermit I think I've figured out why certain characters have to be doubled in order to send them in MacKermit. These characters are normally set to nonspacing diacritical marks. For instance, Option-e is normally a nonspacing accent grave. In the normal Macintosh text input environment, nothing gets sent until you type the next character after a diacritical, so that it can send the appropriate accented character. If you type the diacritical twice, it sends just the diacritial character. If you type a character that cannot be used with that diacritical, it sends the diacritical followed by the character. This is all consistent with the behavior I have seen when I use the Option key as a Control key. I suspect that the same problems would exist if I used the Option key as a Meta key, which I believe is the default. [Ed. - This was also noted in the .BWR file that originally went out with 0.8(33).] ------------------------------ Date: Thu, 22 Aug 85 19:47:45 edt From: Mike Ciaraldi Subject: Mac Kermit vs Yale ASCII We just started using MacKermit to talk to our IBM 4381, which uses a Series 1 front end with the Yale Ascii package. On the other end we installed the version of TSO Kermit from U of Toronto. File transfers work OK, it seems. Big problem with terminal emulation. The packages we use on MVS use lots of boldface. The CKMKER.BWR file says that boldface characters are the wrong size, but for us it's worse than that. The cursor proceeds along, putting stuff on the screen, then skips back and erases several characters, leaving a series of gaps in the line of text. If you open up a window over the affected area, then close it again, the text is OK. It's not in boldface, but it is perfectly readable and in the right place. [Ed. - The problem is still probably due to the characters being a different size from what they program thinks they are. Some IBM/Yale-ASCII sites have found the problem so annoying that they define a new terminal type for the Macs, which is basically a VT100 without boldface.] We tried opening up the SHOW RESPONSE window, stretching it to almost fill the screen, then switching back and forth between it and the main window to force refreshing of the screen image in the main window. This works, but the lower right corner of the SHOW RESPONSE window is "dead", i.e. clicking on it will not bring the window to the front. The dead area is the part where the size-changing icon usually appears. When the main window is in the background, there doesn't seem to be this problem getting it back. Mike Ciaraldi ciaraldi@rochester [Ed. - Mike mentioned in a subsequent message that they would try to come up with a fix for the boldface problem.] ------------------------------ Date: 12 September 1985, 15:31:45 EDT From: Philip Murton Subject: Kermit for UTS with Series/1 We are no longer running UTS under VM here so that only version of Kermit for UTS I have is based on the old UNIX Kermit. [Ed. - This is the KERMIT.C from the Protocol Manual, with modifications to support the Series/1, presumably it will also work with the 7171, 4994, and other systems that run the Yale ASCII package. I've put it in K2:UTSS1.C on CU20B.] ------------------------------ Date: Fri, 13 Sep 85 02:07:01 EDT From: Peter DiCamillo Subject: CMS Kermit with 7171's I can confirm Steve Ostrove's experience that CMS Kermit through the 7171 does not log itself out, and only responds to FINISH. Even with FINISH, CMS Kermit doesn't respond with "R;" until after I enter a carriage return back in the terminal session. From what I have heard, the packet size problem with 7171s is a performance problem which only shows up when a 7171 is loaded. If Steve was testing with only one or two users on the 7171, then a larger packet size would work. I haven't had a chance to confirm this myself yet. Kermit should be able to distinguish a Series/1 from a 7171 because a Series/1 emulates a 3277 terminal, but a 7171 emulates a 3278 terminal. This device type information is available to a program by using DIAG X'24' to obtain information about the virtual console. Peter DiCamillo [Ed. - Can anyone provide a clue as to why CMS Kermit might refuse to log itself out when run from a 7171, but log out OK when run from a 3705???] ------------------------------ Date: 13 September 85 14:35 EDT From: NJG@CORNELLA.BITNET Subject: CMS Kermit and 7171s The problem with Kermit (CMS at least, and I expect the same with TSO) and 7171s should only show up if the 7171 can not field the incoming characters as fast as they are sent. This forces the 7171 to use a 64 character long circular type ahead buffer. Once this buffer fills up the 7171 will not accept further input until the buffer starts to empty. As long as a set of 8 terminal ports is not 'over worked' it should be able to handle input from a terminal at 9600 baud. It is only when more than one of the terminals on a set of 8 ports is sending large data buffers at high data rates that there will be overrun problems. I do not know at what data rates or how many active terminals it takes to actually cause the problems, but 1 terminal at 9600 baud (plus the rest doing normal terminal type output traffic, not file transfer) should not exhibit the problem. This problem has been discussed with the IBM development team for the 7171. Personally I doubt that the problem will be corrected in future versions of the device as it appears that IBM does not intend to have the device support file transfer, but rather to support attachment of dumb-terminals only. ":-)" Nick Gimbrone (607)256-3747 ------------------------------ Date: 13 SEP 85 07:39-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: Kermit-11 vs IBM VM/CMS The most recent Kermit digest had a comment regarding Kermit-11 and CMS. Here is an explanation (?) I should point out that Kermit-11 has never worked well with CMS Kermit (before the S/1 support) as the U of Toledo does not use standard IBM half duplex lines, thus making testing impossible. The controller here is a CCI which fakes a FDX link. Kermit-11 does, however, work fine with the S/1 support in the newest CMS kermit, as long as one remembers to set parity to anything other than the default, none. brian nelson ------------------------------ Date: 10-SEP-1985 10:39:01 From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa Subject: Kermit Distribution in the UK Lancaster University (UK) have just installed Columbia tapes written there on August 3. The files are all online on a VAX 11/780 and can be accessed freely by anyone who wishes using NIFTP or KERMIT. We can also send out files on 9 track tape, and on floppy for some versions. The collection is regularly updated with new tapes and files pulled from cu20b direct. For details mail to Alan Phillips, SYSKERMIT @ LANCS.VAX1 (JANET address 000010404000.FTP.MAIL, or PSS address 23425240101.000010404000.FTP.MAIL), or phone 0524-65201 x 4881. Distribution is free to all educational establishments: a small handling charge is made to commercial users. ------------------------------ End of Info-Kermit Digest ************************* ------- 20-Sep-85 17:58:08-EDT,14460;000000000001 Mail-From: SY.FDC created at 20-Sep-85 17:57:35 Date: Fri 20 Sep 85 17:57:35-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #20 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 20 Sep 1985 Volume 3 : Number 20 Departments: ANNOUNCEMENTS - Kermit Available for Os9 Commodore 64 Kermit V1.7 Available NEC APC III Kermit Available IBM MAINFRAME KERMIT - CMS Kermit Server Logout Problem Solved CMS Kermit 2.01 Init File Problem MISCELLANY - Kermit Diskette Distribution Kermit Diskette Distribution in UK Kermit-11, P/OS, and TMS Problem with C-Kermit on IS 68000 Q-Bus System with 4.2BSD C-Kermit on Xenix on PC/AT? C-Kermit for SUN on 1/4" Tape Cartridge? MacKermit Beware Addition Apple Kermit & CCS Card Kermit as Mail Server? Kermit for Victor 9000? Octopus / Flex Kermit? ---------------------------------------------------------------------- Date: Wed 18 Sep 85 00:57:23-PDT From: BLARSON@USC-ECLB.ARPA Subject: Kermit Available for Os9 Os9 kermit is ready for distribution. It is based on old Unix Kermit, and also has limited server functions. Read the .doc, .hlp, and .bwr files for known limitations. (It should work on all os9 versions, but connect mode has a problem with the CoCo bit banger port.) I am willing to make a "s" format (hexadecimal) file available, but due to numerous compile time options, its usefulness would be limited. Bob Larson UUcp: ihnp4!sdcrdcf!oberon!blarson [Ed. - The files are available for anonymous FTP from CU20B as KER:OS9*.*.] ------------------------------ Date: 8 Aug 85 10:02:53 EDT From: Eric Subject: Commodore 64 Kermit V1.7 Available C64 Kermit V1.7(52) is ready for release. The new edits are bug fixes to the command parser that screwed up the disk commands, a fix to make 1200 baud file transmission work at a full 1200 baud, and a fix to the ASCII/PETSCI conversion tables. All fixes were done by Frank Prindle (Prindle@NADC). ------------------------------ Date: Thu 19 Sep 85 18:40:42-PDT From: Ronald Blanford Subject: NEC APC III Kermit Available Here is the MSXAP3.ASM module for the NEC APC III. I have only used this briefly once, but as far as I can tell it does not implement keyboard redefinition, does not implement any type of terminal emulation, and only works with the standard serial port. Terminal mode does not have backward paging. The author is RAL from Virginia Polytechnic Institute, more than that I don't know. -- Ron [Ed. - Thanks, Ron. The source file is in KER:MSXAP3.ASM on CU20B.] ------------------------------ Date: Tue, 17 Sep 85 00:19:12 EDT From: Peter DiCamillo Subject: CMS Kermit Server Logout Problem Solved I think I've figured out why CMS Kermit doesn't log itself out correctly through a Series/1 or 7171. There are two problems. First, when CMS Kermit sends an ack to the logout or finish command, it uses transparent write/read, as if it expected a response. The micro doesn't send a response, which I believe matches the Kermit protocol, so the user has to complete the read. The following update to CMS Kermit corrects this problem by sending the final ack with just a transparent write: ./ R 00846000 $ 846290 290 09/16/85 22:44:58 DC X'40',AL1(SBA),X'5D7F',AL1(SBA) UPDATE1 00846290 S1ORDAD DC X'0001' addr. -> 0 for write UPDATE1 00846580 ./ I 01601000 $ 1601500 500 09/16/85 22:44:58 XC S1ORDAD(2),S1ORDAD just write when ending UPDATE1 01601500 ./ I 02869000 $ 2869300 300 09/16/85 22:44:58 CLC S1ORDAD(2),=H'0' was write/read done? UPDATE1 02869300 BE SPRET no: return now UPDATE1 02869600 ^ [Ed. - I've removed some spaces so this will fit on the screen.] The second problem affects only the logout command. Before issuing the CP LOG command, CMS Kermit uses the sequence of WRTERM and WAITT to send an XON to the micro and wait for the write to complete. However, if the console is a Series/1 or 7171, CMS Kermit's own console interrupt handler is still in control, so CMS hangs when the WAITT is executed. Also, to send an XON in this case would require another transparent write, since WRTERM cannot send control characters through a full-screen interface. The following update solves this problem by bypassing the calls to WRTERM and WAITT for Series/1 and 7171 connections. It seemed safe to skip them since they weren't working in this case anyway. ./ I 01607000 $ 1607300 300 09/16/85 22:44:58 TM S1FLAGS,ISS1 Is console a S/1? UPDATE2 01607300 BO SERVLOG Yes: skip line mode I/O UPDATE2 01607600 ./ R 01611000 $ 1611490 490 09/16/85 22:44:58 SERVLOG LA 1,=C'LOG' UPDATE2 01611490 These updates are for CMS Kermit Version 2.01, and assume serialization starting at 1000 with an increment of 1000. I've tested them with success on both a Series/1 and a 7171. Peter [Ed. - Thanks, Peter -- I've included your message in CMSMIT.BWR until the next release comes out.] ------------------------------ Date: Wed, 18 Sep 85 9:11:17 BST From: Andrew J Cole Subject: CMS Kermit 2.01 Init File Problem CMS Kermit 2.01 works very well with one small exception (non-feature?). If server mode is entered directly from the CMS command line Kermit seems to fail to read the KERMINI files. Many thanks for such a useful system for a real pig of a system! [Ed. - Thanks for the report; it's been added to the .BWR file.] ------------------------------ Date: Tue, 17 Sep 85 11:47:16 EDT From: Don_Porter%RPI-MTS.Mailnet@MIT-MULTICS.ARPA Subject: Kermit Diskette Distribution I'd be willing to distribute Macintosh Kermit at RPI if you send me a copy on diskette. There aren't many Macs at RPI, but there are a few. We support Kermit on several mainframes on campus, and distribute it for IBM PCs and some compatibles. Don Porter Assoc. Dir., Information Technology Services [Ed. - I got a lot of responses like this to my query about Kermit diskette distribution. I guess I wasn't clear enough... What I'm looking for are organizations or individuals willing to distribute Kermit on diskette in some particular format to the general public, e.g. by mail order, not just within their own organizations. I haven't received reports of any of these. Can anyone tell me about, say, Heath or Atari or Apple or ... user groups that provide this kind of service, like PC SIG does for the IBM PC?] ------------------------------ Date: 19-SEP-1985 11:17:29 From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa Subject: Kermit Diskette Distribution in UK Lancaster University is able to distribute some KERMITs on native media. We can currently handle Aculab Z80B, Sirius 1 (CP/M-86 and MS-DOS), BBC micro, DEC Rainbow (CP/M-86) and IBM PC. We also maintain a freely accessible contact list of other UK native media suppliers for machines we don't have, and can broadcast enquiries to the UK Kermit community at large. Distribution is free in the UK to educational users, but there's a small handling charge for others: we don't supply the discs ourselves. Interested users should contact me BEFORE sending discs, to check availability. The service is one person, so response might be a few weeks, especially if I have to pass discs on to others who actually own the machines. We are willing to co-ordinate supply in the UK : anyone who wishes can be put onto our contact list if they let me have details. Alan Phillips Department of Computing Lancaster University UK E-mail to SYSKERMIT @ LANCS.VAX1 JANET address 000010404000.FTP.MAIL PSS address 234252400101.000010404000.FTP.MAIL Telephone to 0524-65201x4881 (I cannot reply over UUCP and only unreliably over ARPA) ------------------------------ Date: 18 SEP 85 12:11-EST From: BRIAN%UOFT02.BITNET@WISCVM.ARPA Subject: Kermit-11, P/OS, and TMS I may interest you to know that someone is adding to Kermit-11 for P/OS to support TMS. I, as is often the case, will be unable to test such as I do not hav TMS on the PRO but it does sound like the mods to Kermit-11 should be quite minimal. brian ------------------------------ Date: 18 Sep 1985 1046-PDT (Wednesday) From: Paul Graham Subject: Problem with C-Kermit on IS 68000 Q-Bus System with 4.2BSD A nearby site using an Integrated Solutions (IS) q-bus 68000 board under 4.2bsd has been unable to get Kermit to open the phone line. Monitoring the line shows behavior similar to cu and tip when the the line is first opened (some lines are pulsed briefly) but after that kermit hangs. It works in remote mode just fine. Anybody out there using an IS system successfuly? Thanks for your time. Paul Graham 702/784-6007 University of Nevada Reno ucbvax!decvax!seismo!unr70!unrvax!pjg unr70!unrvax!pjg@seismo[.CSS.GOV|.ARPA] [Ed. - There seems to be a lot of this going around, see below...] ------------------------------ Date: Fri, 20 Sep 85 15:15:11 edt From: yhe@ORNL-MSR.ARPA (Young Etheridge) Subject: C-Kermit on Xenix on PC/AT? Am encountering problem with "connect". After connecting /dev/tty00 to a null-modem line, then "set line /dev/tty00" followed with "set baud 4800" then "connect", results in a deadly silence thereafter. The communications channel is okay since "cu" works as advertised. [Ed. - Can anyone who has this working offer some tips?] ------------------------------ Date: Mon 16 Sep 85 13:41:12-EDT From: Frank da Cruz Subject: C-Kermit for SUN on 1/4" Tape Cartridge? Anyone willing to provide a working C-Kermit program for the SUN with 4.2BSD on quarter-inch tape cartridge, please contact Peter Hiscocks 416-979-5000 x6109 Center for Advanced Technology (Ryerson Polytech), Toronto ------------------------------ Date: 19 Sep 85 20:05:07 CDT (Thu) From: ihnp4!islenet!david@Berkeley.EDU Subject: MacKermit Beware Addition Minor addition to your Mackermit BWR file: when a Settings file is saved, it does not store the Command-Shift-1...Command-Shift-9 flag, so we have to set it every session if we want it active. [Ed. - Thanks, I've added it.] ------------------------------ Date: Fri, 20 Sep 85 11:19:17 BST From: Chris_K_Now-and-Then Subject: Apple Kermit & CCS Card This note has circulated in UK. It's obviously of general interest, so I send if on to you. Chris Kennington. Date: Wed 18 Sep 85 19:40:36-GDT From: Alan Greig Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland On the subject of Kermit for various Apple serial cards, the most notable ommision (to my mind anyway) is the lack of support for the California Computer Systems Card (CCS) which seems to be almost universely used in the UK. At DCT we added support for this card to the sources and as we have CROSS can provide hex files with this change. The original changes were made by Colin Bruce (Colin%DCT@UK.AC.DUNDEE) who has now left to work with Data General and involve only a few additions to some tables. The only known bug is that the the card needs to be specifically reset by sticking some value in its command register before running Kermit. (PR#n,IN#n RESET will do this). This initialisation could/should really be inside apple kermit but I've never got round to recompiling it. Anyway it works and if anybody wants it let me know or I can send down the changes to Lancaster. Alan Greig (Alan%DCT@UK.AC.DUNDEE) ------------------------------ Date: Thursday, 19 September 1985 10:05-MDT From: Subject: Kermit as Mail Server? I've seen several messages lately about people allegedly using Kermit as a mail gateway to Unix systems. Do you know how that is being done? Seems like there would have to be a lot more Kermit than I've ever seen to accomplish it. The implications are that of an almost uucp-like server. Enlighten me, please? --Bill [Ed. - It is possible to run a Unix Kermit server as a login shell; OK State is doing this. Presumably, you can then have other systems dial it up, transfer queued mail to it, and then issue the appropriate "remote host" command to it to deliver the mail. I don't know if anyone is actually doing this -- is anyone??? However, I have heard of Kermit servers being used as print spoolers, etc.] ------------------------------ Date: Friday, 13 September 1985 14:40-MDT From: hao!nbires!isis!galon!root@SEISMO.ARPA Subject: Kermit for Victor 9000? A friend has a Victor 9000 and is trying to talk with some IBM PC's. I've been trying to get him a suite of Kermit Programs but todate have been unsuccessful. A tape won't do him any good and I haven't found it on floppies. I did locate it at Okstate, but was unable to pull it using their uucp instructions either in kermit-a or kermit-b directories. Anyone knowing of or having a copy please contact me via email. Thanks. Pat Gallivan @ UUCP: ..!seismo!hao!nbires!isis!galon!fmg Galon Exploration, Inc. 7122 S. Fillmore, (303) 770-6229 Littleton, CO 80122 Data: (303) 771-0258 ------------------------------ Date: Tue, 17 Sep 85 17:26:34 BST From: Chris_K_Now-and-Then To: info-kermit@cu20b.columbia.edu cc: cjk@ucl-cs.arpa Subject: Octopus / Flex Kermit? Kermiteers: Anyone working on Kermits for either Octopus or Flex machines? Both wanted in the UK. Reply to "cjk@ucl-cs", a valid arpanet address. Chris Kennington ------------------------------ End of Info-Kermit Digest ************************* ------- 24-Sep-85 17:48:54-EDT,18487;000000000000 Mail-From: SY.FDC created at 24-Sep-85 17:48:17 Date: Tue 24 Sep 85 17:48:17-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #21 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12145893975.21.SY.FDC@CU20B.ARPA> Info-Kermit Digest Tue, 24 Sep 1985 Volume 3 : Number 21 Departments: ANNOUNCEMENTS - Kermit for QNX Kermit for Intel System 86/380 with iRMX-86 Kermit for HP-1000 A-Series with RTE-A Kermit for Zilog System 8000 Zeus (Sys V) Kermit for the HP Integral PC Update of Fujitsu Micro-16s CP/M-86 Kermit UNIX KERMIT - Kermit for UUCP Mail Changes to C-Kermit 4C(057) Bug Fix for C-Kermit User Interface C-Kermit on Masscomp Systems? MS-DOS KERMIT - Problem with Sanyo 555 Kermit MsKermit Linking Idea ---------------------------------------------------------------------- Date: Mon, 23 Sep 85 13:14:33 edt From: Frank da Cruz Subject: Kermit for QNX A version of Kermit for the Quantum Software QNX operating system has been contributed by Anthony J. Starks, Merrell Dow Research Institute, Indianapolis IN; although he doesn't mention what system it's supposed to run on in his transmittal letter, I believe it's for 8088-based systems like the IBM XT or AT and/or the DEC Rainbow. The program based on the "old" Unix Kermit, but the QNX-specific support is sufficiently different from any other Unix code I've seen that I've installed it as a separate set of files, rather than attempting to merge it with C-Kermit. The files are in KER:QNX*.* on CU20B, available via anonymous FTP. ------------------------------ Date: 23 Sep 85 13:44:04-EDT From: Frank da Cruz Subject: Kermit for Intel System 86/380 with iRMX-86 This is to announce Kermit for the Intel System 86/380 running iRMX-86, written by Albert J. Goodman, Grinnell College, Grinnell, Iowa. The program is written in PL/M-86. The source files (including built-in help) are concatenated together into the file KER:I86KER.PLM, and a short external help file is included as KER:I86KER.HLP, available from CU20B via anonymous FTP. ------------------------------ Date: Mon 23 Sep 85 13:46:33-EDT From: Frank da Cruz Subject: Kermit for HP-1000 A-Series with RTE-A Announcing Kermit for the HP-1000 A-Series with RTE-A, written in Pascal/1000, contributed by Tor Lillqvist, Technical Research Centre of Finland. Here is his cover letter: This is a Kermit implementation for the HP1000 A-series machines running the RTE-A operating system (HPAKermit). It will probably also work on the older E-series machines running RTE-6/VM. The file HPAKERMIT.SRC is a large text file into which is merged all the source files needed to build HPAKermit (just to keep the number of files down). HPAKermit is written in the Pascal/1000 dialect. (A note to Pascal purists: this has many "useful extensions" which makes it more suitable to "Real Programming", but of course removes any chance of an easy port to some other Pascal system.) I would certainly prefer 'C', but the 'C' compiler for HP1000 seems rather oldfashioned, and in any case, we don't have it. HPAKermit must be compiled with the Pascal/1000 compiler of revision 2410 (or later). HPAKermit is based on the (old) Unix Kermit, and has only basic features (Send, Receive and Get). Connect mode is missing, as it is very hard, maybe impossible, to implement successfully on a HP1000. Server mode is also missing, but that is only a "Not-Yet-Implemented" issue. HPAKermit has been tested extensively with MSDOS-Kermit version 2.27 and HP3000 Kermit. Using 9600 bps and an IBM PC/XT a transfer rate of 470 chars/s is achieved. Best regards, Tor Lillqvist Technical Research Centre of Finland Lehtisaarentie 2 A, SF-00340 HELSINKI, FINLAND Phone: +358 0 4566132 Telex: 122972 vttha sf I have no net address, but you can reach me through a friend of mine: mcvax!hut!jtv [Ed. - The files are in K2:HPA*.*, available via anonymous FTP.] ------------------------------ Date: Mon, 23 Sep 85 12:43:29 edt From: Frank da Cruz Subject: Kermit for Zilog System 8000 Zeus (Sys V) I received a tape from Mark E. Sunderlin, Internal Revenue Service, containing C-Kermit 4C(057) revised to include support for the Zilog System 8000 with Zeus 3.20 and later. This will appear in the next release. Meanwhile, if anyone can't wait, the trick seems to be to build it for System III/V ("make sys3") in the normal way, but first change all occurrences of "setjmp" to "setret" and "longjmp" to "longret". This might be accomplished in the makefile without changing the program source by doing something like... zilog: make wermit "CFLAGS = -DUXIII -Dsetjmp=setret -Dlongjmp=longret -i" \ "LNKFLAGS = -i -w" (and also including -DDEBUG, -DTLOG, -O if desired); no one has tested doing it this way, but the same trick works for some of the other systems. ------------------------------ Date: Mon, 23 Sep 85 12:43:29 edt From: Frank da Cruz Subject: Kermit for the HP Integral PC I received a tape from Robert Raymond of TransEra Corp, Provo Utah, with a version of Kermit for HP Integral PC. It's based on the old Unix Kermit, but a cursory inspection of the code suggests that he's simply added System V support to it. Can anyone verify that the present C-Kermit runs on the HP Integral via "make sys3"? If so, I'll simply include that system on the list of those supported by C-Kermit; if not, I'll be glad to make Robert's code available to anyone with an HP Integral who would like to adapt it to the current C-Kermit. ------------------------------ Date: Mon, 23 Sep 85 12:43:29 edt From: Frank da Cruz Subject: Update of Fujitsu Micro-16s CP/M-86 Kermit This fixes an error in baud rate setting/selection. Submitted by the original contributor, Chris Barker, WRIST Inc, Long Island City, NY. The source file is in KER:C86XFJ.A86. Would anyone on the net would care to build and test the result and supply a hex (.H86) file? ------------------------------ Date: Sat 21 Sep 85 14:35:52-EDT From: Bdale Garbee Subject: Kermit for UUCP Mail I haven't finished doing it yet, but I am one of the people using/planning to user Kermit on a UUCP host to move mail to other places. The system in question is an Intel 86/330 running Xenix V2.2N, currently working on getting implementation-specific bugs out of the latest C-Kermit. More details when I'm done. The idea is very simple. Just create a user on the Unix/Xenix system named something like 'kserver'. Then build a .login or .profile for that user in that user's home directory that fires up kermit in server mode, and then terminates the process and hangs up when kermit exits. A remote machine that wants to do file transfer, either of UUCP mail or anything else, just dials in, logs in as user kserver, and issues the appropriate kermit server commands. When done, he issues a server terminate command, which causes Kermit on the Unix box to exit and kill the process... which should also hang up the phone. Using cron and shell scripts makes for easy packing and unpacking of bundles of mail to/from the UUCP mail directory. The remote system just has to have a similar sort of batch facility to use to do the dialup. Bob Hartman of ...!vaxine!spark!bob fame is using this technique to implement a UUCP/Fidonet bridge. I'm working on duplicating and then expanding his work. Will pass along details when it works, and would be most interested in talking to other people who have this sort of thing working, or want help on making it work... Bdale Garbee arpa: ag0b@cmu-cc-te.arpa, soon to be ag0b@te.cc.cmu.edu uucp: ...allegra!pitt!rensys!bdale [Ed. - Thanks for the news. You may be interested in a customized Unix Kermit server that they run at OK State as a login shell if you dial a certain number -- have you been in touch with them... vasoll%okstate.csnet@csnet-relay? Of course, none of this addresses the real questions of mail since (I assume) you're just sending mail in batch mode and not control information in interactive messages, like SMTP would do. How do you handle the various situations that SMTP or UUCP would handle, like bad routing information, can't connect to host, no such user, etc etc?] ------------------------------ Date: Mon, 23 Sep 85 14:06:51 pdt From: Ken Poulton Subject: Changes to C-Kermit 4C(057) [Ed. - Ken Poulton has submitted code for the following changes to C-Kermit. Some of them are obviously desirable, some are in "sensitive" areas (where opinions are divided); I'd like to solicit a concensus in these areas, if possible.] Fixes for HP 9000: added "make s500" which does the things formerly listed in the make file added code to disable HP's enq-ack handshaking (#ifdef IENQAK) in connect Connect: changed use of XON/XOFF slightly (now it works like BSD, and better with HP terminals) Set Handshake: now turns off XON/XOFF (-t already does this) ! merged ! and other uses of fork to call new routine zexecl in ckufio zexecl does an exec, using 1) the shell defined by environment variable SHELL, if any, or else 2) the user's login shell from /etc/passwd, or failing that, 3) /bin/sh. [Ed. - I guess this is better than the current method, which ignores the SHELL variable because some Unix systems do not set it automatically.] control chars added conchr to ckutio and changes in ckucmd to support using the user's predefined control characters as he expects [Ed. - Seems like a good idea, assuming the method used works for the systems the program tries to support. For Sys III/V, it does ioctl(0,TCGETA,&x), and then sets the interrupt, character delete, and line delete characters to x.c_cc[0], x.c_cc[2], and x.c_cc[3] respectively; for all others it does gtty(0,&x) and ioctl(0,TIOCGETC,&y), and sets interrupt, chardel, linedel to y.t_intrc, x.sg_erase, and x.sg_kill. In the first case, x is a struct termio; in the second, x is a struct sgttyb and y is a struct tchars. How many systems will this break?] added code for VENIX11 to turn off driver's recognition of these characters. Most Unices (BSD, SysIII, etc) do this anyway in raw mode. [Ed. - I've heard reports about this before, but never saw this behavior in Pro/Venix, which I thought was the same.] prompt settable with -DPROMPT= startup files 1) ./.kermrc 2) ~/.kermrc 3) /usr/local/lib/kermrc settable with -DKERMRC (as before) and -DSYS_KERMRC Note that order of first two is intentionally changed [Ed. - This looks like a touchy one. First, it might be argued that most people would like the program to behave consistently, no matter what directory you're connected to. Second, if there is to be a "system-wide" startup file, does everyone agree that it should be in /usr/local/lib? Third, the program searches for the startup file as above, and executes the first one it finds. Maybe it should execute all of them? If there is to be a system startup file, should the program ALWAYS execute it? Should there be user-selectable options to specify the order in which startup files are executed, and how many??? How to explain all this to users?] eXIT command added eXIT command - allows leaving Kermit w/o unlocking or dropping line added ttnohu to close the tty w/o hangup creates ~/UNLOCKttyxx to remind user EXIT deleted to avoid confusion (maybe this should be disabled on BSD systems as not needed) [Ed. - This is the most controversial area of all. First of all, case- sensitive commands are not in the spirit of Kermit. Second, giving the user the power to lock a line permanently might be fine on a small friendly system, but not on a big one with many users. The risk of a user leaving a line locked (intentionally or not) is much higher with this method, and the inconvenience to other users must be weighed against the advantages of doing this. Opinions? (Here we go again...) ] scripts commented out most of the messages user can use echo to write messages if he *wants* to [Ed. - Opinions from script command users?] # added comment command for documenting scripts (done with % by 4C(057)) [Ed. - I used "%" for this to avoid confusion with shell scripts.] locking now accepts existing lock files owned by the user (to support eXIT) [Ed. - This is probably not a bad idea, when it works... But some sites keep the locks directory write-protected (or even read-protected), and other sites want to run Kermit, UUCP, CU, TIP, etc, set[ug]id'd, so there's no good way to tell for sure whose lock file it is. I truly believe that "lock files" are the WORST thing about Unix... It continues to amaze me that the system was designed NOT to give exclusive access by default to serial devices automatically upon open().] VOID defined to null for V7, "(void)" for all others to avoid all the V7 ifdefs [Ed. - I thought I had removed all those (void)s; they were just there for lint's benefit, but I guess a couple are still there (in ckutio.c and ckuus3.c); they should go too.] -g rfn -a name changed ckcfns.c to try treating "-a name" as a directory name bug: zopeno gives an err msg if the name is a directory [Ed. - This is a little tricky, not sure it's worth it...] logging added better debug and transaction messages to clsif and clsof in ckcfns.c [Ed. - Good messages are always nice.] get fixed to strip newline off of -a name in take script [Ed. - Obviously desirable.] ------------------------------ Date: Sat, 21 Sep 85 21:28:25 PST From: !!tweten@AMES-NAS.ARPA Subject: Bug Fix for C-Kermit User Interface We just got a new giant Amdahl machine, running the System V flavor of UTS. So far, its only connection to the world is through 9600 baud lines. Needless to say, my first order of business was building C-Kermit on it, followed by Compress, followed by most of my files (it also has mucho disk). It went mostly OK, though the lintish feature of the UTS C compiler fussed a bit. That's not the story for today, though. While sending files to UTS, I got fed up with Kermit's habit of double-spaceing between lines of dots. I decided to fix it while waiting for the transfer. The context diff below, for ckuus3.c, is the result. The problem arose from some confusion over whether "p" was the position of the last character or of the next character to go into the buffer. I tried to make everything consistant. My rules were as follows: 1) "p" is the zero-based position of the next character to be put on the line, 2) It is each message type's responsibility to determine if there is enough space for it, and to leave "p" pointed at the next available space when it is done. I also parameterized the line length, and set it to 79 for our C-Kermit, so terminals with linewrap won't. [Ed. - diffs omitted, but will be included in next release. Kermit was also brought up recently on our own UTSV system, and worked ok, except for some cosmetic problems with command echoing, which I think we can fix.] ------------------------------ Date: 23 Sep 85 16:34:00 EDT From: STEVE KABERLINE Subject: C-Kermit on Masscomp Systems? Can you tell me, please, who is/has been working on the Masscomp specific implementation of Unix Kermit? I have a few comments/suggestions I would like to forward (A network address, if available, would be nice) to them. I recall, at one time, seeing a list on CU20B of who-is-doing-what as far as Kermit work goes, is there still such a file I can ftp over and look at? [Ed. - I've lost the specific reference, but have had reports that Masscomp systems can run the current release of C-Kermit just fine, when built with "make sys3". Anyone know otherwise?] ------------------------------ Date: Fri 20 Sep 85 21:39:02-EDT From: Andy R Raffman Subject: Problem with Sanyo 555 Kermit I thought that I should tell you that I have tried the new Kermit 2.28 for the Sanyo 555, and it has a bug: the backspace key does not move the cursor back or erase the previous character in command mode. Given that many of the other improvements in Kermit haven't helped the Sanyo version much (no H-19 or VT-100 emulation, no set key, no mode line), unless you have fixed some larger bugs in v.2.26 (I know that the log function doesn't work right), you might consider going back to it until the backspace bug is fixed. [Ed. - If any Sanyo users out there have a fix for this, please let us know.] ------------------------------ Date: Mon, 23 Sep 85 23:48:58 PDT From: Samuel_Lam%UBC.MAILNET@MIT-MULTICS.ARPA Subject: MsKermit Linking Idea The following is the relevant part of a response in our local electronic conference (*Forum) which I think may be of interest to part of the Kermit community. 2723. MTS Kermit Now Available Bruce Jolliffe 16:23 Mon Aug 13/84 2723/60. CORRIE KOST 21:16 Mon Sep 23/85 12 lines I would like to suggest that all versions of KERMIT be linked with Microsoft's LINK version 3.XX, so that they can be packed with Microsoft's EXEPACK utility. This procedure can cut the size of the .EXE file by up to 50 %, and the .EXE file is still directly runnable from MS-DOS (...and it loads faster, too) Note that EXEPACK will produce garbage (no warning !) if you try to pack a file linked with LINK version 2.XX, or the default IBM-PC linker supplied with PC-DOS 3.0 and PS-DOS 3.1 - Ya'akov [Ed. - Does anyone know if a thus-packed file can be run transparently under earlier versions of DOS? Also what would the expected savings be on a program like MS-Kermit 2.28, which has got rid of most of its static buffers and does memory allocation at runtime? Any other pitfalls to be wary of?] ------------------------------ End of Info-Kermit Digest ************************* ------- 7-Oct-85 18:50:21-EDT,20104;000000000000 Mail-From: SY.FDC created at 7-Oct-85 18:49:38 Date: Mon 7 Oct 85 18:49:38-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #22 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12149313014.49.SY.FDC@CU20B.ARPA> Info-Kermit Digest Mon, 7 Oct 1985 Volume 3 : Number 22 Departments: MISCELLANY - Half-Duplex Windowing vs Long Buffers Use of Kermit by the Blind (Several Messages) Hint for VMS Binary File Transfer using Kermit UNIX KERMIT - Ken Poulton's C-Kermit Changes (Several Messages) C-Kermit Works on HP Integral Kermit C-Kermit EOF Bug C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix Masscomp Kermit TI NU Machine Kermit Bug in C-Kermit Remote Commands under VAX/VMS ---------------------------------------------------------------------- Date: Thu, 3 Oct 85 19:35 EDT From: RAF@UMDC.BITNET Subject: Half-Duplex Windowing vs Long Buffers Is everyone agreed that in half-duplex windowing, the EOL character should not be sent until the end of a group of packets? If an EOL character is sent after each packet, my 370 TSO and WYLBUR systems will require some delay before the next packet is sent. Otherwise following packets will be lost. Also, if a packet received in error results in a parity error (likely, but not certain), the resulting error message from the system will cause the following packet to be obliterated also. For my systems, I think it is best not to send an EOL until the end of a group of packets. However, if the EOL is not sent until the end of a group, there is another problem which may be common to systems that check incoming parity. Since the whole group of packets is considered to be one "line" by the system, an error in any packet that also results in a parity error (highly likely, although not guaranteed), will cause the entire line (group of packets) to be discarded. Thus the half duplex windowing scheme results in extra overhead for multiple packets per "line" with little corresponding benefit in reduced retransmission when compared to the big packet proposal. Therefore I prefer big buffers to half-duplex windowing. Roger Fajman Computer Center National Institutes of Health [Ed. - Last chance to get your comments in... The tide of opinion seems to be favoring long packets, distinct from sliding windows.] ------------------------------ Date: Tue 1 Oct 85 14:17:51-EDT From: Frank da Cruz Subject: Use of Kermit by the Blind To: Info-Kermit@CU20B.ARPA cc: Info-IBMPC@USC-ISIB.ARPA, Info-Micro@BRL-VGR.ARPA I've had a call from Kenneth Reed at NASA in Greenbelt, MD (phone 301-344-8414) asking how Kermit can be used effectively by blind people. Back in the days when computers had terminals, you could put a device like a Votrax or DECtalk or whatever between the terminal and the computer, and it could try to speak the letters and numbers, or words, as they went by. But microcomputers don't generally have a place to attach such a device. Kenneth says his Apple II has a special card that somehow gets characters just before they're about to be put on the screen and presumably can transmit them to a speaking device, but that's just for the Apple. I'm sure there has been a lot of discussion about this elsewhere, but I must have missed it. How can blind people use microcomputer applications in general? Obviously, graphics-oriented stuff is mostly out (and therefore, presumably, also the Macintosh). In MS-DOS, maybe there are console drivers that can intercept characters, strip out (or interpret) formatting information, and send the text out the serial port to, say, a Votrax, or maybe there are IBM PC boards that "speak the screen" directly. Anyhow, Kenneth's department is selecting microcomputers and he'd like to see them pick one that text oriented applications (like Kermit) can be adapted to give comprehensible audible output. If you have any information, please post it and also give Kenneth a call at the number listed. By the way, the way the Kermit file transfer display is done is important here. On MS-DOS systems, a "form" is put up on the screen at the beginning of the file transfer, and then numbers and messages are filled in and updated randomly throughout. If one were to read this stuff in sequence as it appeared on the screen, it would be a pretty confusing jumble. Also, you'd need a pretty fast talker at high baud rates... The serial output of local-mode Unix Kermit or DEC-20 Kermit would be a lot more comprehensible when interpreted by a voice device. ------------------------------ Date: Wed, 2 Oct 85 06:21:51 MDT From: halff@utah-cs.arpa (Henry M. Halff) Subject: Re: Use of Kermit by the Blind References: <1835@brl-tgr.ARPA> Let me suggest that your friend contact the following firm. Talking Computers, Inc. 6931 North 27th Road Arlington, VA 22213 703-241-8224 The fellow that runs the firm is Doug Wakefield. His business is putting speech synthesizers on computers for blind people. He pretty much specializes in IBM PC's, but he might be able to help with Apples. The software that he uses should have no problem with a screen display like Kermit's since the user can, at any time, get a readout of the entire screen or any line on the screen. Hope this helps. Henry M. Halff Halff Resources, Inc. halff@utah-cs.ARPA ------------------------------ Date: Sat, 5 Oct 85 10:28:24 mst From: Kelvin Nilsen Subject: Kermit for the Blind [Ed. - This is from the author & proprietor of VersaCom, a communication program that includes Kermit.] versacom does not run windows! all i/o to the terminal is serialized through the bios, write tty (except of course when it comes to terminal emulation). this makes it possible to run versacom on a pc from a terminal and connect to another system to transfer files. for example: vt100 dumb tty emulation +-------------+ +---------+ +----------+ |home terminal|- 1200 baud -|office pc|-19200 baud-|office vax| +-------------+ +---------+ +----------+ xon/xoff handshaking is supported on both ports, in both directions and works independently. the amount of information reported by file transfers can be each packet, or each file transfered. anyway, this capability makes possible two solutions to the problem you mentioned. first, attach a votrax-type terminal to one of the com ports of the pc. second, modify versacom to send bios tty output to an internal voice synthesizer instead of or in addition to the bios tty output. kelvin nilsen ------------------------------ DATE: October 07, 1985 11:29:44 EDT FROM: NUNNALLY%VPIVM1.BITNET@WISCVM.ARPA SUBJECT: TERMINAL FOR THE BLIND WE ARE TRYING SEVERAL DIFFERENT PRODUCTS FOR THE BLIND HERE AT VA. TECH ONE IS A PACKAGE ON THE IBM PC CALL ED FREEDOM. VERY NICE PACKAGE. WORKS OUTSIDE OF ALMOST ANY OTHER PACKAGE ON THE PC. WE USE THE TERM EMULATOR YTERM WITH IT NO PROBLEMS. WE ALSO USE THE AUDIOTRONICS TALKING KEYBOARD FOR THE PC. HAVING SOME SPEED INTERFACE PROBLEMS. QUESTIONS CALL 703-961 5961. ------------------------------ Date: 5 Oct 1985 1454-PDT (Saturday) From: randy@uw-bluechip.arpa (William Randy Day) Subject: Re: Use of Kermit by the Blind I am part of a research project here at the University of Washington aimed at developing software for deaf-blind (both deaf and blind) users. The presentation problem is severe. As you say, graphics-oriented software is out. As you describe in you posting, even ``non-graphics'' programs like kermit can prove incomprehensible if a straight screen output to speech translation is made. We have come to the conclusion that a simple hardware/software translation unit sitting on top of normal software is inadequate, particularly for our severely handicapped target group. We have taken the custom software approach. Randy Day. UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy ARPA: randy@washington CSNET: randy%washington@csnet-relay ------------------------------ Date: 3 Oct 85 17:20:20 GMT From: walton%Deimos@CIT-HAMLET.ARPA Subject: Hint for VMS Binary File Transfer using Kermit If one has two VMS Vaxes connected together with RS-232 ports, binary files will transfer OK, using 8-bit data. The catch is that Kermit cannot possibly be taught about all of the wild and wonderful RMS file formats (how many are there? 1.0e10?), so making a BACKUP set (which contains the RMS formats) and transferring it via Kermit will work fine. Do a SET FILE TYPE FIXED in the Kermits at both ends. This allows .EXE files to be transferred directly, and BACKUP save sets to be transferred and read from after fixing up the block size. ------------------------------ Date: Wed, 25 Sep 85 11:38:25 pdt From: hpl-opus!poulton%hplabs.csnet@CSNET-RELAY.ARPA Subject: More Kermit Changes Comments > -g rfn -a name > changed ckcfns.c to try treating "-a name" as a directory name > bug: zopeno gives an err msg if the name is a directory, > even though it works. > [Ed. - This is a little tricky, not sure it's worth it...] It is consistent with other file transfer facilities such as uucp (and I *needed* it for that reason). The code *is* a bit messy because I didn't dare change the machine-dependent primitives like zopeno (I can't write or test new VMS or Mac versions). I think adding an argument to zopeno will allow having it do this operation (if appropriate for that opsys). > eXIT command > > [Ed. - This is the most controversial area of all. First of all, case- > sensitive commands are not in the spirit of Kermit. Second, giving the The typed command is 'x' or 'xit'. This is sometimes an essential feature, but not always desirable. How about making this feature depend on a compile-time ifdef? Then the system manager can control the use of this as appropriate. Ken Poulton ------------------------------ Date: Tue, 24 Sep 85 18:43:32 pdt From: "Scott Weikart; Community Data Processing" Subject: Info-Kermit Digest V3 #21: Ken Poulton reactions Here's my reactions to Ken Poulton's changes. > ! > merged ! and other uses of fork to call new routine zexecl in ckufio > zexecl does an exec, using 1) the shell defined by environment variable > SHELL, if any, or else 2) the user's login shell from /etc/passwd, or > failing that, 3) /bin/sh. I like it. > control chars > added conchr to ckutio and changes in ckucmd to support using the > user's predefined control characters as he expects I like it, for those systems that support it (and leave ^W as backward delete word on SYSIII, etc). > startup files > 1) ./.kermrc 2) ~/.kermrc 3) /usr/local/lib/kermrc > settable with -DKERMRC (as before) and -DSYS_KERMRC > Note that order of first two is intentionally changed I would like to have two system files, kermrc.1st and kermrc.lst. .1st would be done first, then a user's (if any) would be done (i.e. either 1) or 2) above), then .lst. Basically, I want both defaults and mandatory values, and this seems to be the only way to do it. I think /etc might be a better place for the system-wide files, like /etc/profile and /etc/cshprofile. I'm not sure I like 1); it seems like a take file in the appropriate directory would be safer. > eXIT command > added eXIT command - allows leaving Kermit w/o unlocking or dropping line > added ttnohu to close the tty w/o hangup > creates ~/UNLOCKttyxx to remind user > EXIT deleted to avoid confusion > (maybe this should be disabled on BSD systems as not needed) I don't like it. I still think that pushing a subshell is the only reasonable way to do it, with /usr/spool/uucp group accessible and kermit setgid (as I described at length a while back). Of course, I can't bitch too much since I'm not offering to implement it. > # > added comment command > for documenting scripts > (done with % by 4C(057)) > > [Ed. - I used "%" for this to avoid confusion with shell scripts.] But I'd *rather* have it be like shell scripts; my Emacs already assumes that files with no or unknown extionsions use # as comment, and most UNIX types will recognize # as comment. And I doubt that a kermit script will often look like a shell script. > locking > now accepts existing lock files owned by the user (to support eXIT) This seems good as long as it doesn't break when files or directories or unreadable. At least some people could have it right. ------------------------------ Date: Thu Sep 26 1985 17:55:58 From: Marco Papa Subject: Comments on C-Kermit new features These are my comments about the possible additional features or chhanges to current features of C-Kermit. 1. SHELL stuff. OK. 2. Control chars. OK. 3. Startup files. BAD!!! Much better like it is now. 3. Exit command. BAD too!! I do not like case sensitivity, but much more important I do not want users to leave locked lines around. There is really no real advantage, and the risks are enormous. 4. Scripts with no echo. OK. In fact I hate to have my login script to show right on the monitor the password I am using to login on another system. Logging transactions is enough. After one has found the correct login sequence there is absolutely no need to show it everytime. 5. comment command for shell scripts. OK together with 4. 6. locking. It won't work in most systems. System managers are becoming more restrictive in letting users create locks owned by them. Marco Papa USC - Computer Science Dept. UUCP: ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!papa CSNET: papa@usc-cse.csnet ARPA: papa%usc-cse@csnet-relay.arpa ------------------------------ Date: Wed, 25 Sep 85 10:43:58 pdt From: hpl-opus!poulton%hplabs.csnet@CSNET-RELAY.ARPA Subject: Use of '%' and '#' in Scripts On the use of '%' or '#' for comments in scripts: *Many* Unix programs allow '#' to introduce comments, not just shells. In addition, some Unix systems allow "#! program" at the beginning of a file to indicate that that file is a script for 'program' and should be executed as such. This is usually used for csh scripts ("#! /bin/csh") but would allow one to write executable kermit scripts by writing #!/usr/local/bin/kermit at the head of the file. Then (on systems which support this) one need only type the script's filename to execute it with kermit. Ken ------------------------------ Date: 25 Sep 85 09:22:11 EDT From: GH0N@CMU-CC-TC Subject: C-Kermit Works on HP Integral Kermit This is in regard to whether C-Kermit 4C runs on the HP Integral. I have gotten C-Kermit to run on the Integral with very little trouble. Make sys3 does get the job done, but you need to either remove the code that sets up lock files, or have the lock files put in a directory that is guaranteed to be there (such as /tmp). Another thing that crops up is that the C compiler for the Integral has a bug in it (at least the version I have does) that will cause it to report the sizeof() an array as being 0. Sizeof() on lone variables and structures (including structures containing arrays) work fine. The biggest hassle with making C-Kermit for the Integral is the fact that you can't use make if you don't have either LOTS of memory or a hard disk. To compile and link all the code takes about an hour. Hope this helps. Gordon Haverland GH0N % CMU-CC-TC @ Carnegie Mailnet } GH0N @ CMU-CC-TC BITnet } soon to be GH0N.TC.CC.CMU.EDU ? ...!cmu-cs-pt!cmu-cc-tc!gh0n uucp? ------------------------------ Date: Tue, 1 Oct 85 11:31:06 -0100 From: mcvax!philmds!duvel!frans@seismo.css.gov Subject: C-Kermit EOF Bug I've encountered a bug in C-Kermit v57. The bug is that in ckcpro.c (and .w) a test is done on the return value of reof. However reof() does *never* return a value. This makes ckcpro.c barf sometimes that a file cannot be closed, but evidently there is no problem at all. By the way reof() is declared in ckcfns.c. I could not find other calls except for the one in ckcpro.c Frans Meulenbroeks, Philips Microprocessor Development Systems ...!{seismo|philabs|decvax}!mcvax!philmds!frans [Ed. - Right you are -- reof() should return the value that was returned to it by clsof(), indicating whether the file was closed successfully or not. Will be fixed in next release; noted in "beware file" till then.] ------------------------------ Date: Thu, 3 Oct 85 11:07:42 PDT From: brian@sdcsvax.arpa (Brian Kantor) Subject: C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix The routine 'unchar' in ckcker.h has a name conflict with the unsigned character typedef included from sys/types.h. Changing it to 'myunchar' permits Kermit to compile. Brian Kantor UC San Diego decvax\ brian@ucsd.arpa akgua >--- sdcsvax --- brian ucbvax/ Kantor@Nosc [Ed. - Thanks, will change this in the next release, and note it in the beware file until then.] ------------------------------ Date: Sat, 5 Oct 85 02:19:30 CDT From: Stan Barber Subject: Masscomp Kermit I submitted an version of 4.2 C-Kermit to the Masscomp Users Group that had line-locking that would work (I hope) for most environments. I have not had a chance to get the most recent release of 4C to add those features to it that deal with the line-locking problem effectively. make sys3 does just fine, if line-locking is not an issue. If it is, then my mods would probably satisfy most. It is fortunate that the new version of UUCP (BSD 4.3) supports a read/write by the world LCK directory to remove the need for setuid programs. I will be making the 4C version work on masscomp sometime soon, but 4.2 seems to work for most people even with the bugs it has. I will be happy to field any comments on the masscomp users group version. Stan Barber Baylor College of Medicine sob@rice.edu ihnp4!shell!neuro1!sob ------------------------------ Date: 20-Sep-85 14:33:10EDT From: "KENNETH POOLE" Subject: NU-Machine Unix Kermit I have done a simple mod of 4c(57) of the unix kermit for the NU-machine unix from TI. This Unix is the one on the LMI Lambda-Plus machines. Please indicate how you would like me to send you the mods for adding to the main source. I modified ckutio,ckufio and ckuker.mak. Also, please add my name to the list for the info-kermit digest. I was on before, but we lost our arpanet software fo a while and i think i was taken off the list. Thanks, Ken Poole 849-6270 [Ed. - I tried to respond to this message, but couldn't seem to push a message through. Ken, please send me context diffs...] ------------------------------ Date: Thu, 26 Sep 85 15:21:32 GMT From: John Rainbow Messenger Via: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa Subject: Bug in C-Kermit Remote Commands under VAX/VMS We have found a bug in the remote command execution code for the VMS version of C-Kermit. The symptom was a complete failure to execute remote commands, with a message of the form %F - Can't delete file (for instance). The enclosed fix enables remote commands to be executed. The patch is a context diff, and can be installed with the patch command. [Ed. - Patch omitted, but listed in KER:CKVKER.BWR on CU20B.] ------------------------------ End of Info-Kermit Digest ************************* ------- 8-Oct-85 13:03:52-EDT,20102;000000000000 Mail-From: SY.FDC created at 8-Oct-85 13:03:14 Date: Tue 8 Oct 85 13:03:14-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #23 To: Info-Kermit@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12149512097.46.SY.FDC@CU20B.ARPA> Info-Kermit Digest Tue, 8 Oct 1985 Volume 3 : Number 23 Departments: New BOO-file Maker for MS-DOS Further Problem with MS-DOS Kermit 2.28 GET Command About MS Kermit and EXEPACK... Communication Problems with MS-DOC Kermit 2.28 on Leading Edge PC MS-DOS Kermit vs "Desk Accessory" Clocks How to Build Z100 MS-DOS Kermit from Source? Terminals for the Blind The Claimed C-Kermit Bug for VMS Four-Table ASCII/EBCDIC System for EBCDIC Kermits Request for Osborne and Kaypro Kermit Diskettes MacKermit TAC Problem Re: Kermit 1.7 Loses at 1200 Baud Kermit for Wang 2200? Kermit for DG Machines? Kermit for CDS 4000? ---------------------------------------------------------------------- Date: Thu 26 Sep 85 11:39:58-EDT From: Frank da Cruz Subject: New BOO-file Maker for MS-DOS Alan Phillips at Lancaster University (UK) added Lattice C support to MSMKBO.C, so that now MS-DOS Kermit .BOO files can be made directly on the PC. The new version replaces the old one, as KER:MSMKBOO.C on CU20B. If you don't know what a .BOO file is, it's yet-another-printable-encoding for binary files, the format that we distribute MS-DOS Kermit binaries in. It features 4-for-3 encoding and 0-compression so that the resulting .BOO file is often shorter than the original .EXE. ------------------------------ Date: 24 Sep 1985 2221-EDT From: Stephen H. Owades, c/o EIBEN@DEC-MARLBORO Subject: Further Problem with MS-DOS Kermit 2.28 GET Command I have had some problems with MS-DOS Kermit 2.28 on my IBM PC/AT, as I described in a mail message some weeks ago. I downloaded the MSKERM.BWR file, which offered a solution to the faulty file-name truncation (in multi-file GETs) problem. I made the suggested changes, reassembled and relinked, and tested the resulting program. Apparently no truncation whatever is performed on a GET; DOS truncates the file name passed to it by KERMIT. This does eliminate the problem of badly truncated file names (wherein KERMIT was doing something bizarre to the name of the first incoming file), but it has created a new, perhaps worse, fault. Now collisions (incoming file name the same as a file name already presen are only detected when the incoming file name is valid under DOS; if the incoming file name is longer than XXXXXXXX.XXX, KERMIT doesn't know there is a conflict and the system hangs. I had to reboot my AT! Collisions are detected and avoided with the "0-1-2-..." naming method described in MSKERM.DOC if the incoming file name is valid under DOS--evidently KERMIT doesn't realize that there is a collision when the incoming file name was truncated by DOS. Stephen H. Owades ------------------------------ Date: 27 Sep 1985 0912-EDT From: LCG.KERMIT Subject: About MS Kermit and EXEPACK... I have used EXEPACK on MS Kermit 2.26 through 2.28 and it produces workable code (note I relink from source). In the 2.27 and older versions the .EXE file went from 80+ K to around 36K. In V2.28 however the savings was minimal (10% if I recall right). Thus EXEPACK is of marginal use with V2.28. Can't say much about backward compatibility; it looks OK on PCDOS V2.0 on, but could break some compatibles. Since MSDOS Link V3.XX is not commonly available I believe its a mistake to use it in distribution; people should be able to recreate the distributed .EXE via source with more common tools... Glenn Everhart ------------------------------ Date: 2 Oct 1985 1152-PDT From: Rob-Kling Subject: Communication Problems with MS-DOC Kermit 2.28 on Leading Edge PC I normally use Kermit through COMM1 on my IBM-PC. I was trying it on a Leading Edge PC last night which was configured to communicate through COM2. It wouldn't send commands to the modem. The Status command indicated that 1200 baud was illegal [even though we could use PC-TalkIII to dial out on COM2]. I could not get Kermit to accept any baud rate (e.g., 110, 300, 1200) as legal for COM2. That is, the Status command indicated an error at any baud rate when I set the port to COM2, but it would accept 1200 baud on COM1. When I came home, I tried setting Kermit to use COM2 on my IBMPC at home. I have only one serial port on this machine, but tried to set COM2 as the active port. I received the same error messages re inappropriate baud rate ["Baud rate not recognized" or equivalent message]. I couldn't find any information in the Kermit 2.28 manual to help me decide where the problem might lie. 1. What may be the problem? 2. Do you know if anyone has tried to use MSKermit on one of the new leading Edge D machines? Thanks Rob Kling UC-Irvine [Ed. - I'm pretty sure you can set the baud rate on COM2, as many people at Columbia have two serial ports and use both. If the second serial board isn't there, the status command would not be able to figure out the baud rate, since reading the (non-existent) baud rate status port would return something meaningless. I don't know anything about the Leading Edge machines, but it sounds like they're another 'almost' compatible, at least in terms of the second serial port. Does anyone out there know something about Leading Edge?] ------------------------------ Date: Mon, 7 Oct 85 10:21:49 PDT From: walton%Deimos@CIT-Hamlet.ARPA Subject: MS-DOS Kermit vs "Desk Accessory" Clocks Any program which accesses the IBM PC timer interrupt to place a real-time clock on the screen seems to put a real strain on Kermit. Continuous-update programs basically trash Kermit. I have a shareware program called Deskmate on my PC right now, which updates the time on the screen every 10 seconds or so. It still badly interferes with Kermit. I don't want to have to reboot my system in order to use Kermit effectively. Does anyone have a solution to this problem, or is it inherent in the IBM PC architecture? Steve Walton Caltech Solar Astronomy walton@citdeimo.bitnet walton%deimos@cit-hamlet.arpa ...!psuvax1!walton@citdeimo.bitnet [Ed. - Thanks for the report; I've noted it in the "beware" file. There may be a way to get two or more programs that use timers to coexist, we'll have to look into it.] ------------------------------ Date: Mon 7 Oct 85 13:20:34-MDT From: Dick Dysart Subject: How to Build Z100 MS-DOS Kermit from Source? I have downloaded the MS*.ASM files for Kermit for the Z-100, 13 of them.. I have run them thru MASM , each with no errors from MASM..(not sure if or what I should modify for MY machine).. Then when I LINK them, the linker responds -> I/O run error in EXE, and aborts without creating the .EXE file... I thought that I should try from the beginning as my Besterm still won't work properly, and MAYBE a version of Kermit compiled on MY machine would work.. With the LINKER aborting this way, and I cant find that error message in the MS-DOS manual as yet, I don't know what's wrong, nore do I have any idea what to fix.. Any help would be appreciated......................Dick [Ed. - Can anybody who has experience with MS-DOS Kermit on the Z100 offer any help?] ------------------------------ Date: Mon, 7 Oct 85 20:31:19 EDT From: Doug Gwyn (VLD/VMB) Subject: Terminals for the Blind I don't know why nobody seems to be mentioning the VersaBraille (another company makes a similar device). I used to have a blind programmer working for me, and we tried various talking terminals, optical scanners, and so forth. Her conclusion was that the VersaBraille (with communications software cassette) was much easier and faster, although for graphics (yes!) she resorted to an optical scanner (sorry, I forget the trade name). This topic really seems orthogonal to KERMIT, other than to the extent to which it points out the silliness of fancy user interfaces in what was supposed to be a file transfer program. [Ed. - So true. By the way, I can't find any other forum for discussion of these issues in the "list of lists", so I don't mind if the topic continues in Info-Kermit for a while.] ------------------------------ Date: Mon 7 Oct 85 21:47:01-EDT From: Jin Au Kong Subject: The Claimed C-Kermit Bug for VMS The problem with "! XXX" in VMS is related to the BYTLM in user authorization file, as we discovered soon after we installed C-kermit on our system. For VMS to create a subprocess, the BYTLM must exceed 4096 (which is our previous setting), and of course, PRCLM must be at least 1. I don't know the exact minimum for BYTLM, but after we set it to 6144, it worked. But note that the created subprocess will not be stopped after you get out from Kermit. Hope somebody can fix the problem. [Ed. - Thanks, noted in the CKVKER.BWR file. Does this mean that the previous report is wrong and that no change needs to be made to the code, or that both are necessary? Anybody want to contribute "installation instructions" for C-Kermit under VMS, and/or a review of its usefulness?] ------------------------------ Date: Sat, 27 Jul 85 15:55 PDT From: IVA3GET@UCLAMVS.BITNET Subject: Four-Table ASCII/EBCDIC System for EBCDIC Kermits [Ed. - This message was recently excavated and is now belatedly published. It was apparently provoked by the new ASCII/EBCDIC translation feature of VM/CMS Kermit v2.] The two ATOE's and two ETOA's would differ in the following way. First let us denote the system tables ATOE0 and ETOA0. We will construct ETOA1 to be the left inverse of ATOE0, i.e. for every printable ASCII character x, ETOA1(ATOE0(x)) = x. Similarly, we will construct ATOE1 to be the right inverse of ETOA0, i.e. for every printable ASCII character x, ETOA0(ATOE1(x)) = x. The -1 tables are used to postmap incoming packets back to ASCII and to premap outgoing packets out of ASCII. They form an outer layer to Kermit so it can analyze and build packets in ASCII. If the -0 system tables are nonstandard, then the -1 will be too. Note that the right inverse may not be unique and that either inverse may fail to exist. The other function of translation tables is to map text messages back and forth between ASCII and EBCDIC as packets are analyzed and synthesized. Call these ETOA2 and ATOE2. Ideally these should be based on the "standard" in the IBM System 370 Reference Summary or the Appendix of the Kermit User's Manual, and thus would differ from the -1 tables in the nonstandard situation. Currently, -1 tables do double duty as they perform the text message translation function as well. The result is various distortions in text as it is transmitted to and from EBCDIC systems, including undesirable substitutions and swallowing of characters. In a four-table system as I have outlined, these distortions would not occur. What is left is to state mathematically the conditions under which the -1 tables can be constucted, and to present the appropriate algorithms. . ETOA1 exists iff ATOE0 is 1-1 (unambiguous) on the printable set. . ATOE1 exists iff the range of ETOA contains the printable set. With standard tables, these questions do not arise since in this case the system tables are both left and right inverses of each other. This is all I have time for now. Hopefully, I can sketch the algorithms later. I ran into the problem of distorted characters at UCLA where TSO Kermit has recently been installed with modified translation tables. I wanted to download Kermit-MS in the .BOO format as well as the Basic program to decode it. I noticed that the tilde (or degree sign) was getting swallowed and that the backslash was being blanked out. It would have been easy enough to hand patch the Basic, but hardly the .BOO file. I hope I have convinced you that there is a problem. Ciao - Glenn Thobe iva3get@uclamvs and vss7853@uclavm (bitnet) [Ed. - Given the number of calls I get every day from IBM mainframe sites who have "customized" their translate tables, I don't need convincing that there's a problem. But I'm not sure I understand how a 4-table system will necessarily solve it. Your level 1 tables that invert the system's tables will only work if the system's tables are already unique and invertible -- in many cases they are not. If 2 different printable ASCII characters are mapped by the system to the same EBCDIC character, then the even the low level stuff won't work -- some packets will be perceived has having wrong checksums. In such cases, the only solution is to fix the system's tables.] ------------------------------ Date: Wed, 25 Sep 85 13:10:12 PDT From: spacerad@JPL-VLSI.ARPA Subject: Request for Osborne and Kaypro Kermit Diskettes To: info-kermit@cu20b.arpa I have been in touch with Frank da Cruz regarding our local (Los Angeles area) Osborne club acting as a distribution house for Osborne and Kaypro Kermit diskettes and documentation. the details are all worked out, but I do require copies on disk of latest versions and doc or library files for these programs. I would also like to obtain a copy of the Kermit User Guide. Anyone who can assist in this matter may reply directly to this message or contact me also via: 1) dantas@jpl-vlsi.arpa 2) BOB DANTAS % JET PROPULSION LAB 4800 OAK GROVE DRIVE MAIL SLOT T-LL MAIL SLOT T-1180 (CORRECT ONE) PASADENA, CALIF. 91109 3) (818)354-4932 [Ed. - I'll send a User Guide. Could someone who has Kermit on Kaypro or Osborne diskette please send in a copy? Thanks!] ------------------------------ Date: Tue 1 Oct 85 09:07:52-PDT From: Steve Dennett Subject: MacKermit TAC Problem The NIC has gotten several calls lately from users having trouble getting Macintosh Kermit to work through a TAC. I've tried doing file transfers and have been equally unsuccessful. The odd thing is that it's a one-way problem. Going through a TAC, files can be downloaded from host to Mac without difficulty. But when uploading, MacKermit sends three packets then starts re-trying until it finally times out. I've read the general information about using Kermit through a TAC and have successfully moved files in both directions through a TAC using the IBM PC version of Kermit, so the problem is something specific to MacKermit. Also, I've tried all the different TAC twiddles (BIS/BOS, flow control, varying packet sizes, etc.) but no combination seems to make a difference. The version of MacKermit I'm using is .8(33) July 1985. Since you're listed as one of the authors, I hope you can help. With the growing number of net users and the popularity of the Mac, this question is certain to come up with increasing frequency. Thanks for your help. Steve Dennett ( dennett@sri-nic.arpa ) DDN Network Information Center [Ed. - Well... You've got the latest version of Mac Kermit, so that's not the problem. I've never used a TAC personally, so all my information is second hand. @B I S/@B O S makes the TAC transparent, so once you've done that, you should be able to rule out any interference by XON/XOFF (which the Mac doesn't do anyway), atsigns, etc. The fact that you can download files to the Mac seems to confirm this. Therefore, I'd look again at the TAC's buffers. If there's a way to make them bigger, do that. If not, you've got to get the Mac to send shorter packets; to do this, tell BOTH Kermits to reduce their packet sizes. What may be happening is that the effect of commands like "set send packet-length" might be the opposite of what you expect -- some Kermits take this to mean that you want to override whatever the other Kermit asks for, and while others do the opposite. Let me know how it works. If you still have problems, find out as much as you can from the two Kermits involved -- note all the current communications and protocol settings, get debug and/or packet logs if possible.] ------------------------------ Date: Wed 2 Oct 85 21:30:17-EDT From: Robert S. Lenoil To: prindle@NADC.ARPA cc: info-kermit@CU20B.COLUMBIA.EDU, lavitsky@RED.RUTGERS.EDU Subject: Re: Kermit 1.7 Loses at 1200 Baud I tried your suggested fix of setting the RS-232 registers to 8 so that my modem could autobaud correctly, and then resetting them to zero. This worked in that my modem did autobaud correctly and go into high-speed mode. However, when I reset the rs-232 regs to zero, the host could no longer understand me. Of course, if I left the registers at 8, I dropped characters. The symptoms are this: my transmit data light goes on, but the host does not return any character (I am in full duplex). After restarting with Kermit 1.5 (what I'm using now), I saw that the DEC-20 was receiving nothing but back-quotes ("`"). I've rejected the possibility that my download went poorly, since I used Kermit, and because the hex file has its own checksums. Again, my modem is a ProModem 1200, by Prometheus. Has anyone else seen this behavior exhibited? ------------------------------ Date: Wednesday, 18 September 1985 17:43-MDT From: pjohnson@sdcsvax.ARPA (Paul Johnson) Subject: Kermit for Wang 2200? Does anybody have the source for Kermit on a Wang 2200? paul johnson {akgua,allegra,dcdwest,decvax,ihnp4,helios,ucbvax}!sdcsvax!pjohnson [Ed. - To my knowledge, no Kermit program exists for any Wang systems other than the PC, and no one is working on any. Does anybody know something to the contrary?] ------------------------------ Date: 26 Sep 1985 1331-EDT From: LSM.DUNCAN at DEC-MARLBORO.ARPA Subject: Kermit for DG Machines? Is there ayone who could provide a copy of a Data General Kermit for an MV4000 system in binary form? We have a system with no compilers and a cartridge tape. Alternatively, is there a way to get a binary version from a system so it could be downloaded with a 'crude' transfer program? Thanks, Jeff Duncan (lsm.duncan@dec-marlboro) ------------------------------ Date: 2 Oct 85 22:13:21 EDT From: Steven Christensen Subject: Kermit for CDS 4000? Is anyone working on a Kermit for ComputerVision's CDS-4000 computer? It's basically a FORTRAN generic machine, with some strange idiosyncronicities. Steven Christensen Phone: (513) 752-4595 Address: 728 Stuart Lane Cincinnati, Oh 45245 ------------------------------ End of Info-Kermit Digest ************************* ------- 17-Oct-85 17:51:15-EDT,21893;000000000000 Mail-From: SY.FDC created at 17-Oct-85 17:50:28 Date: Thu 17 Oct 85 17:50:28-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #24 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12151923684.34.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Thu, 17 Oct 1985 Volume 3 : Number 24 Today's Topics: MS-DOS Kermit for the DECmate II and III Crosstalk XVI 3.6 Kermit Implementation Kermit Throughput Problems with "Smart" Multiplexer MacKermit and TACs VMS Kermit 3.1.066 Bug Re: VMS C Kermit problem... Commodore-64 Kermit 1.7 1200 Baud Fix CP/M Kermit on a Remote Machine File Transfer Between VAX (Unix 4.2) and IBM 3081 (VM/370) ? File Transfer Between VAX And IBM PC Through LAN ? Victor 9000 CP/M-86 Kermit Binary Wanted (On Floppy) MS DOS Kermit vs DTR Kermit for 1750A, MOS, or Jovial? ---------------------------------------------------------------------- Date: Thu, 17 Oct 85 10:02:47 EDT From: Frank da Cruz Subject: MS-DOS Kermit for the DECmate II and III An implementation of MS-DOS Kermit 2.28 (the current release) is now available for the DECmate-II and III with the XPU (MS-DOS) option, from an anonymous donor at DEC. The files are in KER:MSDM2.BOO (printably encoded .EXE file, use KER:MSPCTRAN.BAS or KER:MSPCBOO.BAS to decode it, if indeed DECmate MS-DOS has a Microsoft-like Basic), KER:MSDMII.BAT (for building from source), KER:MSXDM2.ASM (system-dependent source module), and KB:MSDM2.EXE (8-bit binary). No documentation is available, but it is said to work, and to use the DM-II/III's built-in VT100/200 firmware for terminal emulation. ------------------------------ Date: Wed, 9 Oct 85 08:57:06 cdt From: blake@astro.utexas.edu (R. Blake Farenthold) Kermit: Kermit on The Source The Source (a commercial time sharing service) has just set up their SIGS (Special interest groups) containing discussions & downloads for people with various interests. Aside from straight ASCII up and down loads they offer Kermit transfers. A couple of days ago I sent a 110K file to the Source using Kermit. At 1200 baud this should have taken about 15 minutes. IT TOOK OVER AN HOUR! Is Kermit that inefficent, is it horribly hampered when using a packet switching network (I used Telenet), or has The Source slowed things way down so they can collect more per-minute connect time! In otherwords who do I yell at? Blake Farenthold | CIS: 70070,521 | UUCP: {ut-sally,ut-ngp,noao} P.O. Box 3027 | Source: TCX023 | !utastro!blake Austin, TX 78764-3027 | Delphi: blake | Intr: blake@astro.UTEXAS.EDU BBS: 512-442-1116 | MCI: BFARENTHOLD | ESL: 62806548 [Ed. - The people at The Source are well aware of the problem, which is twofold: (a) TELENET, and the Prime computer itself (which is what you are talking to) provide only 7-bit channels, so you incur the overhead of 8th-bit prefixing for binary files, and (b) any packet-switched wide-area public network like TELENET has its own built-in delays, which, due to the stop-and-wait nature of the Kermit protocol in its present form, will tend to dominate any file transfer over TELENET. To cope with these problems, The Source has proposed (in Info-Kermit v3 #7, with discussion in following issues) a sliding window protocol to allow multiple packets to be sent back to back, which can result in a dramatic performance improvement under these conditions. Prototype programs are running now, and should be announced before the end of the year. By the way, don't complain too much -- most other protocols don't work in this environment at all!] ------------------------------ Date: Wed, 16 Oct 85 20:02:47 EDT From: RAF@UMDC Subject: Crosstalk XVI 3.6 Kermit Implementation I just received a copy of Crosstalk XVI 3.6, which includes KERMIT support. I gave it a quick try and encountered two problems. One is that when I send a text file from the PC to my TSO KERMIT, Crosstalk does not stop at the Control-Z. Thus I get a Control-Z plus some additional garbage at the end of the file. Microstuf customer support confirms that there is no way to get Crosstalk to stop at the Control-Z. Since Control-Z for end of file is a PC convention, it seems to me that Crosstalk should support it. Customer support said they would pass the suggestion on for consideration. The other problem is much more minor: after a Crosstalk KERMIT LIST command is done to list KERMIT protocol options, everything put on the screen after that is in high intensity. Roger Fajman National Institutes of Health ------------------------------ DATE: 16-OCT-1985 FROM: BRIAN@UOFT02.BITNET SUBJECT: Kermit Throughput Problems with "Smart" Multiplexer A note to those of you who support a Kermit implementation on odd modems and muxes: I recently had a call from a Kermit-11 user who found that a download from the host to the RT11 system for a given file took 2 minutes, whereas the upload of the same file to the host took 14 minutes. Solution: the mux they were using severely downgrades the uplink bandwidth in an ill conceived attempt to improve the host to local link bandwidth. From what I have seen recently in the various trade rags, this seems to be an approach that some vendors are trying out. Beware... brian [Ed. - One of the hardest problems Kermit or any similar protocol has to cope with is that so much communication equipment is designed under the assumption that input from a "terminal" will only be human keystrokes. Another example follows...] ------------------------------ Date: Thu, 10 Oct 85 21:35:27 EDT From: Dave Swindell Subject: MacKermit and TACs I've found that you have to explicitly set the send-packet length to something less than 64 when uploading data from ANY PC over a TAC. The TAC input buffer just isn't big enough to handle the 90 (or is it 94?) character default send-packet size used by MacKermit. As was mentioned in the digest, you also have to use the TAC commands @ B O S and @ B I S (in that order) to allow the Kermit protocol to function correctly over a TAC. Dave Swindell BBN Laboratories ------------------------------ Date: Tue 8 Oct 85 16:15:54-EDT From: Michael Fuchs Subject: VMS Kermit 3.1.066 Bug I don't know if 3.1.066 is state-of-the-art, but it can't handle CRCs and 8bit data simultaneously in server mode. One can't set the micro to CRC and send a binary file to the VAX unless one explicitly makes the micro *request* 8-bit-prefixing. CRC works fine with non-8bit-files, and 8bit files can be sent micro to VAX with Checksum error detection. The VAX puts a "3" in the appropriate place in the init packet. Then, if the data packet has bytes with the eighth bit high, it sends NAK packets back to the micro. (Indeed, the NAK packets correctly have CRCs.) The only way to use CRC error detection is to also have the micro request 8-bit-quoting (if one is sending 8bit data to the VAX). ------------------------------ From: Ivan Auger To: info-kermit <@csnet-relay.arpa:info-kermit@cu20b.columbia.edu> Subject: Re: VMS C Kermit problem... There is a default mailbox buffer size on any VMS system (mailboxes are used for process communication). You can have kermit set the size of mailboxes, change the defaulf mailbox size, or you can indeed increase BYTLM quotas. (By theway on our system you can do a SET HOST with a BYTLMC quota of 4096). Ivan Auger, NYS Dept. of Health. ------------------------------ Date: Tue 8 Oct 85 17:20:07-EDT From: Robert Lenoil Subject: Commodore-64 Kermit 1.7 1200 Baud Fix You must download the .INI file as a SEQ file. The proper parameters for the kludge baud rates are contained in that file. 1200 baud will not work without it. That was the problem. There is no way (from within Kermit) to set the optional baud rate parameters in the .INI file, so you better download KERMIT.INI properly, or 1200 baud won't work. As as alternative, you might wish to create KERMIT.INI with this small program: 10 open 8,8,8,"0:kermit.ini,s,w" 20 for i=1 to 45 : read b : print#1,chr$(b); : next 30 close 8 40 data 25,1,0,0,0,0,1,0,5,0,1,0,1,1,0,0,0,60,1,56,0,38,38,0,0,0,0,13,10,8,10 50 data 93,93,4,0,35,0,0,0,0,0,0,0,0,0 ------------------------------ Date: Thu, 10 Oct 85 17:37:27 edt From: Mike Ciaraldi Subject: CP/M Kermit on a Remote Machine I sent this before, but I think it got lost: Is there any way to run CP/M Kermit as the "remote" kermit rather than the "local" kermit? e.g. Suppose you had a computer bulletin board system running under CP/M, and you wanted to use Kermit to upload and download files. You would use the Kermit on your own micro to call the BBS, and could then run Kermit on the remote machine. But when you told the remote Kermit to, say, SEND, it would try to send the data out some communication port, and would send only the status reports about the transfer to the console (which is REALLY the modem ultimately connected to your local machine). Even if you use Generic Kermit and have it communicate with the TTY or CRT device, it will still be sending both file data and the status reports to the same device. I know the IBM PC version has a flag you can set to disable displaying the status, and the mainframe versions of Kermit must be able to tell when to send status reports to the console and when not to (by looking at the SET LINE perhaps?), but I couldn't find anything like this in the CP/M Kermit 4.05 manual. Thanks for your help. Mike Ciaraldi ciaraldi@rochester seismo!rochester!ciaraldi [Ed. - For now, there's no way to do this. I've been forwarding messages regarding CP/M-80 Kermit to the current maintainer, Charles Carvalho (CHARLES@ACC), but haven't had a response in months. Charles, are you there???] ------------------------------ Date: 11 Oct 85 02:14:56 GMT From: wei@princeton.UUCP (P Wei) Subject: File Transfer Between VAX (Unix 4.2) and IBM 3081 (VM/370) ? We have vax running UNIX 4.2BSD , ckermit program, modem (/dev/tty18), vcu (to use modem). The ibm3081 also has cmskermit program. the question is: is it possible to transfer ascii file between this two system via that modem? I tried to use vcu to connect to ibm3081, but when I type 'kermit' in CMS , I got 'an ascii terminal must be used' error message. Even if i didn't get that message, I couldn't get (escape) back to vax to invoke ckermit because vcu doesn't allow me to 'escape'. Then I tried to use 'kermit -l /dev/tty18 -b 1200'. The phone line was connected. However, when ibm ask my terminal type, whatever I answer it warned me to check parity etc... I don't have time to go through further. I would like to ask if any one knows my intention (file transfer) is possible. If anyone has experience, would you please mail me some sample session (as detail as possible)? (e.g. the parameter settings...) thanks a lot ! HP Wei [Ed. - It is entirely possible to use Kermit to transfer ASCII text as well as binary files between a 4.2BSD VAX and an IBM 370-Series mainframe running VM/CMS. Very briefly, here's how: If you have a Series/1 style front end (7171, 4994, etc) running the Yale ASCII package, you must also have version 2.00 or later of CMS Kermit on the IBM mainframe (if you don't, you'll get the "An ASCII terminal must be used" message. If you're going through some other kind of 3270 protocol emulator, then you can't use Kermit. If you're going through a 3705-style front end as an ordinary line mode TTY, you can use any version of CMS Kermit. You should have version 4C(057) of C-Kermit on the Unix system -- certain earlier versions had bugs that might have prevented them from working with IBM mainframes. To C-Kermit you should give the following commands if you're coming in as a line-mode TTY: set duplex half (half duplex = local echo) set flow none (no full duplex xon/xoff flow control) set handshake xon (use half duplex line turnaround handshake) set parity mark (use whatever parity your IBM system expects) or else the following commands if you're coming in through a Series/1 style front end: set parity even (or whatever) And of course you must also include whatever "set" commands are necessary to set up the communication line ("set line", "set modem", "set baud", etc). If all this seems a little strange, you can blame the IBM style of data communications, which is different from everyone else's. ] ----------------------------- Date: 11 Oct 85 04:49:02 GMT From: wei@princeton.UUCP (P Wei) Subject: File Transfer Between VAX And IBM PC Through LAN ? We have several ibmpc's connected to ETHERNET LAN with the communication program 'yterm'. I can connect the ibmpc to the vax (running UNIX 4.2) using yterm. Therefore , the ibmpc serve as a terminal for the vax. Now , I escape the yterm program to DOS and invoke MSKERMIT and then type 'connect'. I get back to the unix shell. CKERMIT is then invoked. Then type 'send filename '; escape (^]C) back to MSKERMIT ; type 'receive '. However, there is no packet coming in. The screen just display 'transfer in progress......' message forever! (1) Am I totally wrong ? The kermit doesn't work on LAN ??? (only on tel line ? ) (2) Or I forgot to set some parameters ??? Can someone mail me sample session if same attempt has been done? Thanks in advance. HP Wei [Ed. - Kermit can indeed be used over LANs, so long as the PC's connection to the LAN looks like a serial communication port to the PC. This would seem to the case in HP Wei's query, since a terminal connection can be made. In general, when the Kermit CONNECT command works but file transfer does not, the culprit is usually (a) parity, (b) flow control, (c) packet size, or (d) interference: (a) Check to see if your LAN terminal interfaces are using some kind of parity and if so, tell BOTH Kermit programs about it, using the SET PARITY command. (b) It is command for LAN terminal interfaces to want to do xon/xoff flow control with the PC. Make sure you PC is set up for this (MS-DOS Kermit does this by default in most cases). If some other kind of flow control is required (like RTS/CTS) you could be in for trouble. (c) Some LAN terminal interfaces have small buffers and can't accept a normal Kermit packet (90-95 characters) at 9600 baud. Try using SET SEND/RECEIVE PACKET-LENGTH for smaller packets, or else reducing the baud rate. (c) Some LAN terminal interfaces intercept a certain character for control purposes. If this is a printable character, a Control-A, or a carriage return, then this will prevent Kermit file transfers from taking place. In this case, try to find out how to change the box's intercept character to a control character other than ^A or CR. If the ^A or the CR are at fault, you can use Kermit's SET START and/or SET END to change these. If it's a printable character, and it can't be changed in the LAN box, you're out of luck.] ------------------------------ Date: Sunday, 13 October 1985 06:56-MDT From: Gijs Mos Subject: Victor 9000 CP/M-86 Kermit Binary Wanted (On Floppy) I want to get some files from our Victor 9000 computers to various other machines. The best program to use seems to be kermit. The problem is how to get Kermit running on the Victor. I have a recent kermit distribution with a V9000-CP/M 86 kermit on it. But I don't have an assembler, nor a way to get the sources on the Victor 9000's disks. So I guess I'm looking for a kermit CP/M 86 executable in Victor 9000 format. Can somebody provide such a beasty at media/handling costs? Gijs Mos Dept. of Biology Free University De Boelelaan 1087 1081 HV Amsterdam The Netherlands {seismo,philabs,decvax}!mcvax!vu44!gijs ------------------------------ Date: 14-OCT-1985 11:41 From: Heather Holmback To: Problems with MS-DOS Victor Kermit We have been unsuccessful in using Kermit for a connection between a VICTOR PC with operating system MS-DOS and the VAX, at the Max-Planck-Institut for Psycholinguistics in Nijmegen, The Netherlands. We are using Sirius version 1.20 by Barry Devlin, University College Dublin, April 1984, translated by SIREXE.BAS (by Daphne Tzoar, CUCCA). Could you please send information on any later versions of Kermit or any recent solutions to problems. Our main problem is that only one file can be successfully uploaded without exiting and reloading Kermit. Also MSKERMIT.INI does not work as indicated in the documentation. Thanks. [Ed. - Unfortunately, this is still the latest version of MS-DOS Victor/Sirius Kermit. No one has ever taken the trouble to write an MSXSIR.ASM module so that Victor support would be included automatically in new MS-DOS Kermit releases. Any volunteers?] ------------------------------ Date: Wed, 16 Oct 85 19:11:05 CDT From: Subject: MS DOS Kermit vs DTR MS DOS Kermit leaves the modem signal DTR high upon exit. This is useful if a person wishes to exit kermit and then resume an online session, however there are times when it is useful to drop DTR when running Kermit or when finished with Kermit. For instance some modems will answer the phone only when DTR is high, so you might want to drop DTR after a Kermit session so that YOU can answer the phone rather than your modem. On our campus a great many of our computers are linked together by a Gandalf PACX communications switch. Our switch polls all ports not in use that have DTR high. Since we have hundreds of micro's hard-wired to the switch, if they keep DTR high when the switch has no active connection on that port to a given system, they bog down the polling and after a short period produce copious timeout error messages on the switch console. For this reason it is important that our users drop DTR when finished with a session. Furthermore, on some lines it is impossible to reconect or change systems without dropping DTR first. Ideally, it would be nice to have another SET parameter called DTR or DTR- EXIT or DTR-QUIT or DROP-DTR that could be set ON or OFF so that when Kermit is terminated it would dictate what state DTR would be left in. It would also be nice to just have a command like RESET COMx or DROP-DTR COMx. In lieu of this facility in Kermit I have written a short COM program which I call OFFCOM1.COM or OFF.COM for short. The commands to create this 8 byte COM file follow. I suggest typing them in without the comments (things beggining with a semicolon). DEBUG OFFCOM1.COM A ; PROGRAM OFFCOM1 ; by Mark Zinzow ; ; Provides an external DOS command to clear ; the serial port. ; This has been tested on a Zenith Z150 running MS Dos 2.11 and an ; IBM PC AT running PC Dos 3.1. ; Note that this program is hardcoded for the address of the RS232 port. ; A better way would be to use an offset on the base address normally ; found in memory at location 40H:0. ; MOV DX,3FC ; Port address for serial modem register. ; (Use 2FC for com2 rather than com1) MOV AL,0 ; Store a zero as the value to output. OUT DX,AL ; SEND the zero to the port. ; INT 20 ;return to DOS RCX 8 W Q After typing the Q you should get the DOS prompt back. A DIR should show the 8 byte com file OFFCOM1.COM. This program can be run after exiting kermit or from kermit using the run command. I use a macro to drop DTR with the command do off. The macro definition looks like this: DEFINE OFF RUN A:OFF.COM The first program of this kind at our site was written by Mitch Blank for the Zenith Z100. Here's the MASM source: [Ed. - Source omitted, stored in KER:MSXZ100.DTR. Adding DTR control for every system that MS-DOS Kermit runs on (not to mention all the different internal modems in use on them) would be a very big job, so little programs like this are probably the best approach.] ------------------------------ Date: Thu, 10 Oct 85 13:47 CDT From: "David S. Cargo" Subject: Kermit for 1750A, MOS, or Jovial? Has anybody seen or heard of a version of Kermit written in Jovial, or the assembly language of the 1750A for MOS (the MATE Operating System)? We have some parts of the company that want such a thing. [From "Burton J. Ewing" : By the way, MOS is a derivative of Unix (by way of IDRIS?). This might be more useful info to the Kermit community than MOS. Our people who have been peering about in MOS's innards tell me that it is largely identical to Unix in most respects. Same structure, same subroutine names, arguments, etc. Therefore, if we could find another Unix hosted Kermit that was written in something we can compile to 1750A code we are in business. The last time I checked, that meant JOVIAL - but, who knows what will happen in the future?] ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Oct-85 18:06:14-EDT,13892;000000000000 Mail-From: SY.FDC created at 18-Oct-85 18:05:42 Date: Fri 18 Oct 85 18:05:42-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #25 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12152188600.62.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Fri, 18 Oct 1985 Volume 3 : Number 25 Departments: KERMIT (ETC) FOR THE BLIND - Equipment for the Blind Use of Kermit by the Blind VM/CMS KERMIT - CMS Kermit V2.01 CMS KERMIT bugs Kermit-CMS Fixes Bug Fixes for CMS-Kermit 2.01 MISCELLANY - Dropping DTR on VMS Victor/Sirus Support on the Way for MS-Kermit 2.28 ---------------------------------------------------------------------- Date: Wednesday, 9 Oct 85 07:59:43 PDT From: Robert Jaquiss Subject: Equipment for the Blind [Ed. - Some people have complained that this discussion is inappropriate to Info-Kermit (and/or Info-IBMPC, Info-Micro, etc), but there's no mailing list specifically for this topic. And a lot of useful information is coming in. So please tolerate this digression for a while. I'll also be archiving all of these messages into a special file, KER:AABLIND.HLP.] I am a blind programmer at Tektronix Inc. I have used Kermit on several occations. For my work I use a Thiel braille printer from Maryland Computer Services. To the computer it looks like a teletype that can send and receive upper and lowercase. Of course graphics are useless cursor movement is impossible. It is possible to deal with numbered or lettered menus where you select the item you want by entering some character. I have a Versabraille as a backup terminal on which I have also used kermit it worked fine. The micro I am using runs CP/M so I don't have to contend with menus. Here are some equipment sources that have reliable hardware. Maryland Computer Services sells a very good braille printer. They have a specially modified HP150 that talks and a accessory for a PC that will allow users to use screen oriened software. Telesensory Systems Inc. sells the Versabraille (a refreshable braille display) and the Optacon (a hand held scanner that will show you the shape of letters). Vtek sells a tactile display device for use on a ibm PC or Apple. Maryland Computer Services Inc. 2010 rock Springs Road Forest Hills, Md. 21050 Phone (301) 879-3366 Telesensory Systems Inc. 455 N. Bernardo Mountainview, Ca. 94039 Phone (415) 960-0920 Vtek 1610 26th Santa Monica, Ca. 90404 Phone (213) 829-6841 If you need moe help call me at (503) 627-6346 (work). Robert S. Jaquiss ucbvax!tektronix!robertj (uucp) robert jaquiss@tektronix (csnet) robert jaquiss.tektronix@rand-relay (arpanet) ------------------------------ Date: Fri, 11 Oct 85 9:34:53 EDT From: Robert I. Isakower (IMD-SEAD) Subject: Use of Kermit by the Blind The following letter was sent to Kennith Reed 10/10/85 at your request. 9 October 1985 Dear Mr. Reed, Recently a request was forwarded to me from Frank da Cruz asking if I had any information on the use of Kermit or the MS-DOS system by the Blind. Perhaps this request was directed to me because I have tunnel vision (Retinitis Pigmentosa). I also have a degenerative hearing problem which places very demanding requirements on any voice synthesizers used with visual aids for my eyesight problems. I have found SMOOTHTALKER on the Mac difficult to understand. DECTALK provides, for my personal use, the best voice output. Please realize that I am not a judge of what constitutes good speech because everything sounds to me as if it were coming from a distorted radio receiver. The following information that I am including in my letter are my notes and results of my own findings of a computer show that I attended in Ewing, New Jersey this past September. I have no corporate nor financial interest in any of the company products and the information and comments that I am offering is my personal opinion. I sincerely hope that my enclosure will be of some assistance to you in your research. If I can be of any further assistance, please feel free to contact me. Robert I. Isakower C, Technical Systems Division Four vendors featuring "talking computers" were at the show for aids for the blind and the visually impaired. I was unable to get prices for all the equipment. VTEK (formerly VISUALTEK) 1625 Olympic Boulevard Santa Monica, CA 90404 1-800-345-2256 VOYAGER Electronic Magnifiers: $2,395 to $2,895 Large Print Display Processor (*) : $2,695 (This device magnifies, up to 16X, whatever is on the screen, with character enhancement. It recognizes the ASCII code and redraws it as a solid line vector, instead of an enlarged matrix of dots and spaces.) MBOSS-1 Braille Printer: $3,225 Braille Display Processor (*): $3,495 This is a neat paperless braille output with a 20 cell tactile refreshable braille readout. It will provide the braille equivalent of 20 contiguous character spaces on the computer display. Audio signals indicate the "position" of the 20 cell braille window on the video display. (*) for APPLE II, II+, IIe and IBM PC, PC-XT, PC-AT COMPUTER CONVERSATIONS 2350 N. Fourth St. Columbus, Ohio 43202 (614) 263-4324 (after 6 PM) ENHANCED PC TALKING PROGRAM: $500 Written by a blind programmer, (Ronald Hutchinson), this is interfacing software only, and requires the user's own computer, voice synthesizer, and application progams. Application programs are the programs that you wish to use in a speaking mode and would be an additional expense with all talking computers. This company's program interfaces with the most used computers, speech synthesizers and application software in the marketplace. The company will offer to recommend the configuration best suited to your needs and budget. MARYLAND COMPUTER SERVICES 2010 Rock Spring Rd Forest Hill, Maryland 21050 (301) 879-3366 TOTAL TALK PC (microcomputer, display, speech synthesizer, keyboard) AUDIODATA/IBM PC KEYBOARD (2 slider keys, speech synthesizer, speaker, and display magnification with optional low cost monitor)-provides audio output from your IBM PC. The vertical slider key locates the desired line and the horizontal key locates the character on the line. In this manner, the user can hear the screen, one line at a time, character by character. THIEL BRAILLE (high speed-120 cps) EMBOSSER CRANMER-PERKINS BRAILLER (4000 character memory typewriter, braille printer, plotter, smart terminal, portable): $2,350. READY READER optical character reader (typewritten material to braille or voice): $11,500. MCS computer systems are based upon Hewlett-Packard computers which are very well constructed. Unfortunately, none of the above equipment was demonstrated to me, for one reason or another. A fourth vendor was demonstrating a speech synthesizer that works with the APPLE II. I wasn't stirred by it and left early, not being offerred any literature. COMMENTS: VTEK and MCS have been around a long time, know the business of electronic visual aids, have the most varied product line and are probably my best bet for the future. They have equipment for both the visually impaired and the totally blind. MCS's AUDIODATA/IBM KEYBOARD promises the simplest, cheapest and quickest fix for IBM PC users. Although it is a very competitive computer marketplace, a small software manufacturer and system iterfacing company such as Computer Conversations, probably with lower production costs and more self-motivating talent, cannot be discounted. Another company that should be investigated is the one that manufactures a portable tactile (pins) readout device called the OPTICON. I've watched this used with great success and speed on printouts and teletypewriters (on line), and I heard of some sort of adaptation to a computer display. Note that the OPTICON is difficult to learn to use. ------------------------------ Date: 9 October 1985, 13:36:52 EDT From: Philip Murton (416) 978-5271 MURTON at UTORONTO Subject: CMS Kermit V2.01 I think I found a small bug that is related to your edit [25], if you have FILE set to BINARY and have compression ON. Here's the fix: [Ed. - Thanks! Code omitted, but included in KER:CMSMIT.BWR.] ------------------------------ Date: Wed, 9 Oct 85 23:04 CDT From: Brick Verser Subject: CMS KERMIT bugs Here is another small CMS KERMIT problem. If running on the 7171 (or Series/1, I think), CMS KERMIT 2.x doesn't work if the virtual machine console is not at address 9. While all of the diagnoses know to use the dynamically determined console address, the HNDINT SET has address 9 hard coded. The fix is simple and obvious, except that HNDINT doesn't allow a register for the console address field, so the HNDINT macro has to be replaced by the hand coded equivalent. [Ed. - See below.] ------------------------------ Date: Tue, 15 Oct 85 09:13 EST From: Dave Elbon Subject: Kermit-CMS Fixes I have some fixes for Kermit-CMS 2.01. 1) Kermit-CMS is confused when TERMINAL LINESIZE is set to OFF. 2) The actual virtual console address is not used in a call to HNDINT, which prevents Kermit-CMS from working if the address is not 009. (Many, many thanks to Brick Verser of KSU for this.) 3) CP SET ACNT should be turned OFF along with MSG, WNG, and IMSG. When Series/1 mode is on it might be possible to set TERMINAL BREAKIN to GUESTCTL rather than changing all of the message settings. Acknowledge-To: Dave Elbon [Ed. - Thanks, the code that was included with this message has been added to KER:CMSMIT.BWR.] ------------------------------ Date: Wed, 16 Oct 85 14:25:24 pdt From: gts@ucbopal.Berkeley.EDU Subject: Bug Fixes for CMS-Kermit 2.01 [Ed. - Each of these paragraphs came with code to correct the reported problem. The code has been omitted here, but has been added to KER:CMSMIT.BWR.] Fix bug at RPACK4. Calculation of crck (block=3) must begin at the first actual packet character not at RECPKT+1. Leading pad or junk characters move it further down. Use pointer RECPKTP. Fix confusion and conflicts in use of MAXOUT and LRECL. MAXOUT controls the amount of data collected for a write and LRECL is used only during padding of recfm F records. During SET FILE BIN, MAXOUT was set to LRECL and during SET FILE TEXT it was set to MAXTXT! This is clearly wrong. Also, MAXOUT was set to LRECL during SET LRECL which causes recfm V writes to be blocked to LRECL. This fix removes the MAXOUT change during SET FILE. SET LRECL is changed to set MAXOUT to MAXTXT for recfm V or to LRECL for recfm F. SET RECFM is changed to do the same. Fix maximum LRECL to 65535 not 65536. CMS allows only 65535 (64k-1). CMS aborts the write if lrecl 65536 for recfm V. And although CMS allows the write if lrecl 65536 for recfm F, most products cannot handle such records. Fix MAXTXT to be 65535 not 64536 (typo)! Remove unused MAXBIN. Change receive to expand tabs each 8 spaces (unix,cp/m,pcdos) for text file receives. Redisplay the send or receive command at completion, followed by the status message, then the completed or failed message. This gives the user everything they need to know at one glance. Initial status is "No send / receive done yet". Fix recfm f to pad lines with spaces not nulls. Change DECODE to interpret CR and LF from the EBCDIC after translation with ATOE instead of from the seven bit ASCII. This allows receive of text files that contain characters with the eight bit set with the normal ATOE table, or by altering the the ATOE table allows receipt of text in any eight-bit code. Also CR LF LF gives two lines based on CR LF then LF. Fix receive to discard the trailing control-Z for text files This catches all cases except where the control-Z has already been written to disk, e.g. the 65535th character of the last recfm V record or the lreclth character of the last recfm F. Greg Small (415)642-5979 Microcomputer Networking & Communications gts@ucbopal.Berkeley.ARPA 214 Evans Hall CFC ucbvax!ucbjade!ucbopal!gts University of California SPGGTS@UCBCMSA.BITNET Berkeley, Ca 94720 ------------------------------ Date: Thu, 17 Oct 85 21:53:16 edt From: faron!sidney@mitre-bedford.ARPA Subject: Dropping DTR on VMS We have the latest VMS Kermit running under VMS 4.whatever, talking to an autodial modem through a DMF-32 mux. The only way the VAX can get the modem to hang up the phone is by dopping DTR. Can anyone help with a way to do that, perhaps with a little program like the one that was in the last info-kermit digest for MSDOS? Are there any VMS SET TERM parameters that are involved? Sidney Markowitz ------------------------------ Date: 18-OCT-1985 13:58:48 From:SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa Subject: Victor/Sirus Support on the Way for MS-Kermit 2.28 Brian Steel of Logic Programming Associates (UK) is doing an MSXSIR.ASM at the moment - no idea when it will be ready though. Will let you know as soon as I hear from him. Alan ------------------------------ End of Info-Kermit Digest ************************* ------- 24-Oct-85 16:16:36-EDT,18062;000000000000 Mail-From: SY.FDC created at 24-Oct-85 16:14:36 Date: Thu 24 Oct 85 16:14:36-EDT From: Frank da Cruz Subject: Info-Kermit Digest V3 #26 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12153741238.45.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Thu, 24 Oct 1985 Volume 3 : Number 26 Departments: ANNOUNCEMENTS - CU20B Internet Address Changed MS-DOS KERMIT - MS-DOS Kermit Files Reorganized Request for Kaypro 2000 Information Revised HP 110, Portable Support for MS-DOS Kermit 2.28 New TI Pro Support for MS-DOS Kermit 2.28 Fix for Z100 MS-DOS Kermit MS-DOS Kermit Key Definitions for EDT MS-DOS Kermit and DTR MISCELLANY - C-Kermit 4C(056/057) and MacKermit 0.8(33) 2400 Baud Modems with MNP "Protocol" Update on Crosstalk Problems CMS Kermit "Enhancements" Kermit for the Blind Kermit for the Texas Instruments 99/4A?? Kermit on Diskette for Terak? ---------------------------------------------------------------------- Date: Thu, 24 Oct 85 15:33:59 edt From: Frank da Cruz Subject: CU20B Internet Address Changed Because Columbia is splitting its overburdened campus network into several discrete but interconnected chunks, the Internet host address for CU20B has changed, effective yesterday (23 Oct 85, 7:00PM EDT), from [192.5.43.128] to [128.59.32.128]. The change has been reported to the NIC in hopes that they will get out a revised host table in a day or so. Until CU20B's new address is in your host table, you can refer to it numerically (but then you don't get the automatic recognition of what type of host it is; e.g. people coming in from other DEC-20s will have to explicitly tell FTP "STRUCTURE PAGE", "TENEX", or something to that effect.) ------------------------------ Date: Wed 23 Oct 85 14:13:21-EDT From: Frank da Cruz Subject: MS-DOS Kermit Files Reorganized Several recent submissions of MS-DOS Kermit material (see below) have prompted me to reorganize the MS-DOS Kermit files a bit, so now they have more consistent names. The names are now in the following form: MScxxx.typ The file name is no longer than six characters, the file type is 3 or less. MS is the common prefix for all the file names. "c" is a single-letter code that categorizes the file: A - General information, "read me" files, etc. (like this file) B - Files related to Bootstrapping I - Initialization or command files to be read by Kermit K - General program documentation (Kermit User Guide chapter, etc) R - Release notes S - System-independent Source code V - Binaries, .BOO files, documentation for a particular Version X - System-dependent source code & related documentation Y - System-dependent terminal emulation code Z - System-and-modem-dependent modem control code "xxx" is a 3 letter code to designate which system an MSV, MSX, MSY, or MSZ file applies to: AP3 - NEC APC-3 APC - NEC APC APR - ACT Apricot DM2 - DECmate II or III with MS-DOS Option GEN - "Generic" MS-DOS (DOS calls only) HP1 - HP-150 HPX - HP-110 and HP Portable Plus IBM - IBM PC, XT, AT, and PCjr (note, only works on RS-232 port of PCjr) MBC - Sanyo MBC-550 RB1 - DEC Rainbow-100 series TIP - Texas Instruments Professional WNG - Wang PC Z10 - Heath/Zenith 100 "typ" is the file type, e.g. ASM - Assembler source (for Microsoft or IBM Assembler) H - An assembler header file (included at assembly time) C - A C language source file (e.g. Lattice C) BAS - A Basic language source (e.g. Microsoft Basic) BOO - An .EXE file encoded into printable characters for bootstrapping BWR - A "beware" file - list of known bugs or limitations HLP - A help file DOC - A longer documentation file MSS - Scribe text formatter source for a HLP or DOC file INI - An initialization or command file to be read by Kermit BAT - An MS-DOS Batch file (e.g. for building from source) UPD - A program update history file KER:MSAAAA.HLP has been updated to reflect the changes, as well as the new releases. No changes were made to the programs themselves (except as reported below), but I expect a new release of MS-DOS Kermit to be ready in about a month. ------------------------------ Date: Tue, 22 Oct 85 16:30:24 pdt From: Harvey A. Iwamoto Subject: Request for Kaypro 2000 Information I have been patching the Generic Kermit for the built-in modem in the HP 110 with minor success. I was able to get the modem port in the Grid Compass working with yet another patched Generic Kermit but the file transfer would not work. There is some problem with either parity, number of stop or data bits. It seems that each one of these built-in modems behave differently and are located in differently addresses. I am currently trying to get a version of Kermit working for the Kaypro 2000 but I lack address information about the modem port. I called Kaypro directly but they would like users to ask their dealers. The only Kaypro rep got fired so there is no direct line to information. I need to know where the modem is located (memory or ioport) and what the busy bits are. Also, if it must be initialized. In short, the type of modem if any does it emulate. If and when I get the patched version working, I will make it available to any or all interested parties. Harvey Iwamoto [Ed. - Internal modems are poison, but if you're stuck with one I guess this is what you have to do. Meanwhile, see below about HP-110 modem port.] ------------------------------ Date: Tue, 22 Oct 85 21:17:23 mdt From: dwf%b@LANL.ARPA (Dave Forslund) Subject: Revised HP 110, Portable Support for MS-DOS Kermit 2.28 Attached is the assembler source for the HP110 Kermit (MSHPX.ASM). It works both on the HP110 and the new HP Portable Plus. Port 1 is the serial port and Port 2 is the internal modem. Defaults are even parity and 9600 baud on the serial port and 1200 baud on the internal modem. We should have a version shortly which will also drive the HP-IL RS-232 interface as Port 3. This new code correctly handles different parity settings and works without modification on both the HP110 and the Portable Plus. All of the work on this code was done by Chuck Aldrich here at Los Alamos. The separate assembler source is assembled with MicroSoft MASM and linked with LINK just has described in the MSKERMIT documentation. This executable has also been compressed with MicroSoft's EXEPACK utility before being processed with MSBMKB.C into a .BOO file. [Ed. - Thanks Dave! The files are in KER:MS*HPX.*, available via anonymous FTP from CU20B (by those who have fixed their host tables as shown above).] ------------------------------ Date: Sun 20 Oct 85 22:13:21-EDT From: Joe Smith (415)794-2512 Subject: New TI Pro Support for MS-DOS Kermit 2.28 About 6 months ago, my colleague Dan Smith tried sending you the updated versions of the sources for MS-DOS Kermit 2.28 running on the Texas Instruments Professional. Apparently they did not get there. The version in question has H19 and Tektronix emulation and works at 9600 baud. I have uploaded them again. Please delete KER[MIT]:MSXTEK.ASM on both MARKET and COLUMBIA - that file has been replaced by MSYTIP.ASM. Please update MSAAAA.HLP and MSBUILD.HLP to reflect the new name. Joe Smith [Ed. - Thanks, Joe! The files are available on CU20B as KER:MS*TIP.*.] ------------------------------ From: John Voigt, Tulane Univ. Systems Group Date: 10/20/85 13:02:43 CDT Subject: Fix for Z100 MS-DOS Kermit August Treubig of Middle South Services discovered a bug in the Z100 version of KERMIT. It caused MS-DOS to crash. The fix is in the GETBAUD routine; the call to bios_auxfunc should be surrounded by "push di" and "pop di". [Ed. - Thanks; the change has been made in the source file, MSXZ10.ASM, and added to the Z100 Kermit beware file. The .BOO file is still based on the original source until the next release of MS-DOS Kermit.] ------------------------------ Date: 11 Oct 1985 0118-EDT From: (Carl Houseman, GENICOM Corp., via) EIBEN@DEC-MARLBORO Subject: MS-DOS Kermit Key Definitions for EDT I've uploaded two files which make life for the IBM-PC/Kermit user who also uses EDT a little easier. Together they provide all the keypad editing functions of EDT to the PC user. They are: MSIVT1.EDT - An EDT initialization file which defines the numeric keypad functions to match a VT-100 layout. Use of this file when editing on a VT-100/VT-220 is harmless, but those using "real" VT-52's should not invoke it. MSIVT1.INI - Defines the numeric keypad and function keys as to match VT-100 function keys as closely as possible, as follows: F1=PF1 F2=FP2 F3=PF3 F4=PF4 F5=backspace F6=linefeed F7=up-arrow F8=down-arrow F9=left-arrow F10=right-arrow The numeric keypad is the same as a VT-100 where the keys are the same, with the PRTSC key acting for the VT-100 keypad comma, and the "+" key acting for ENTER. The 8, 4, 6 and 2 keys become cursor keys when SHIFT is held. If the 5 key fails to work correctly (can't effect BACKUP while in EDT), press the NUM-LOCK key. Also note that an "=" will appear at the top left of the screen after starting EDT; this is a problem with Kermit's VT-52 (Heath-19) emulation, and the "=" is not really in the file. It does not re-appear after scrolling off the screen. Carl Houseman GENICOM Corp. 703-949-1323 [Ed. - These files available in KER:MSIVT1.* on CU20B.] ------------------------------ Date: Sun 20 Oct 85 13:08:20-PDT From: Carl Fussell Address: Santa Clara University Subject: MS-DOS Kermit and DTR If anyone is interested, we have added a SET DTR ON/OFF command to the IBM PC version of Kermit... we also found that it was needed for some of the communication we do. We did not submit it back to Columbia since it was only added to this one version. If you would like a copy, contact me. If anyone is interested, I will upload it to my guest account at Score where it can be ftp'd. As I recall, the changes were only in a couple modules. Carl [Ed. - Again, the problem here is that in inordinate amount of research and effort would be required to add DTR control to all the different versions of MS-DOS Kermit; the MSX*.ASM system-dependent modules would have to be redesigned, possibly resulting in damage to systems that the new design could not be readily tested on, etc. Far better to supply a trivial little program for toggling DTR, and define macros in Kermit for running it with Kermit's RUN command.] ------------------------------ Date: Mon, 21 Oct 85 20:06:40 est From: George Wyncott Subject: C-Kermit 4C(056/057) and MacKermit 0.8(33) Two of our staff members with Macintoshes reported the following problem: C-Kermit 4C(056/057) seems to fail when used with MacKermit 0.8(33). C-Kermit version 4.2(030) PRERELEASE #2 works correctly under normal conditions. Here's what happens with versions (056) and (057): 1. C-Kermit is executed interactively and given the "r " command. 2. MacKermit is directed to send the file. 3. C-Kermit receives the file completely. 4. MacKermit continues to resend the end-of-file packet (B) continuously. It appears that C-Kermit is not acknowledging the B packet correctly, causing MacKermit to cycle endlessly and preventing the end-of-transmission (Z) packet from being exchanged. HERE'S THE STRANGE PART: If you give C-Kermit the "log debug" command before the "r ", the exchange takes place without error - C-Kermit gets the Z packet. NOW HERE'S ANOTHER STRANGENESS: C-Kermit 4.2(030) works the opposite. You get a correct transfer UNLESS "log debug" is commanded. Then it hangs up just like versions (056) and (057). George Wyncott aaj@asc.purdue.edu [Ed. - The problem can probably be traced to how C-Kermit sends out the ACK to the B packet, and then closes the line. Unfortunately, Unix tends to close the line while sending out the packet is still on its list-of-things- to-do-when-it-gets-around-to-them... Solution: flush the output queue before closing the line. Or if that adds too much system-dependent hair, sleep(n) before the close. The program currently does a sleep(1), but it may be that more than a second is needed for busy systems and/or low baud rates, so maybe n should be some function of these.] ------------------------------ Date: Mon Oct 21 21:55:09 1985 From: Herm Fischer Reply-To: HFischer@USC-ECLB Subject: 2400 Baud Modems with MNP "Protocol" I looked (briefly) into the new 2400 baud modems for use with my Xenix system. The dealers all push versions with a built-in protocol called MNP. This protocol handles retries of bad characters, BUT (e.g., beware) it is not really suitable for use on communications where the underlying software already has a protocol. With uucp, the MNP flow control will be incompatible, and thus one will have to disable MNP. With Kermit, MNP is likely to play havoc particularly where the end-to-end flow control needs to be preserved (likely at 2400 baud on systems which might become busy), because MNP only appears to support modem to computer flow control. For interactive computer access, if you need control-s or control-q, e.g., if you use an editor like emacs ever, then again you might have difficulties. The people who produced the MNP protocol, and whose marketing has caused the modem suppliers to energetically advertise its features (without being knowledgable of its operation), ended up recommending that I buy some other modem without the feature. Finally, be aware that MNP is only a retry on error protocol; it is not a forward error correction device with Hamming codes (as I expected from its sales literature). [Ed. - Thanks for the comments, Herm. Any further discussion of MNP and/or X.PC in relation to Kermit would be most welcome here.] ------------------------------ Date: Fri, 18 Oct 85 19:42:31 EDT From: RAF@UMDC Subject: Update on Crosstalk Problems The latest word from Microstuf customer support is that both problems that I encountered with Crosstalk XVI 3.6 Kermit support will be fixed "soon". The two problems are not stopping at the Control-Z in a text file and setting the wrong screen intensity in the KERMIT LIST command. Roger Fajman National Institutes of Health ------------------------------ Date: Sat, 19 Oct 85 23:07 EDT Subject: CMS Kermit "Enhancements" From: ("Bob Shields ") <@UMD2.UMD.EDU:VBOB@UMDB.BITNET> In one of the latest "info-kermit" digests I read that someone had modified CMS Kermit to "automatically" expand tab characters to 8 column boundaries. If this is being considered as a standard operation, I would like to cast my vote against it. I have found that XEDIT will expand tabs just fine (see the "EXPAND" and "COMPRESS" commands), and will do it to whatever columns *I* specify, not just every *8*. I more often use a tab setting of every 4 columns, and sometimes use ones that are not at fixed intervals (like 10, 16, 30,... for CMS ASSEMBLE files). Maybe this can be resolved with "yet another SET command" in CMS Kermit. [Ed. - You're right, it shouldn't be hardwired into the program.] ------------------------------ From: Sheldon Talmy Date: 19 Oct 85 18:36:58 PDT (Sat) Subject: Kermit for the Blind In response to your msg about "Kermit for the blind", there is a great deal being done for the visually handicapped in conjunction with computers. One company I suggest is IRTI: Innovative Rehabilitation Technologies Inc. 26699 Snell Lane, Los Altos Hills,Ca, 94022 415-948-8588 They have a huge catalog of products for the visually impaired, including synths & entire turn-key systems. If nothing else, the man who owns the company is an excellent resource for info on the latest products. I've been writing articles on computers for the handicapped for the last couple of years, & have gathered several sources for products, that are ready to go now. If I can be of any help, send me a msg, & I'll be happy to assist you. I note from other messages on the subject, that some research is going on that could conceivably come under the heading of "re-inventing the wheel". As i'm involved in the field, I might possibly be able to save time & effort, so contact me if you like. Shel Talmy<>Talmy@Rand-Unix ------------------------------ Date: Sat, 19 Oct 85 09:07:59 EST From: pur-ee!mjs@UCB-VAX.Berkeley.EDU (Mike Spitzer) Subject: Kermit for the Texas Instruments 99/4A?? I've heard someone mention this... does Kermit exist for the 99? If not, why not? Mike ------------------------------ Date: Wed 23 Oct 85 16:01:10-EDT From: MG1K%CMCCTC@TC.CC.CMU.EDU Subject: Kermit on Diskette for Terak? I have a Terak which I am trying to use as terminal for the flourscence center vax. I would like to be able to transfer Kermit to the Terak. If you know of anyone who has(had) a Terak and has Kermit on 8 inch single density floppies, please send me mail. Thank you, Miriam Gulotta ( MG1k@cmcctc) [Ed. - Can anyone help?] ------------------------------ End of Info-Kermit Digest ************************* ------- 28-Oct-85 15:45:11-EST,8780;000000000000 Mail-From: SY.FDC created at 28-Oct-85 15:43:16 Date: Mon 28 Oct 85 15:43:16-EST From: Frank da Cruz Subject: Info-Kermit Digest V3 #27 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12154795033.32.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Mon, 29 Oct 1985 Volume 3 : Number 27 Departments: ANNOUNCEMENTS - CU20B Address, Info-Kermit-Request Mail Trouble New Release of BBC Acorn Kermit Kermit for GEC-4000 Minicomputers New ACT Apricot Support for MS-DOS Kermit 2.28 Kermit for RMX86 MISCELLANY - MacKermit vs Cray C-Kermit 4.2(030) Source Wanted VMS Kermit-32 bug fix CMS-Kermit Expanding Tabs on Receive C-Kermit on Diskette for Chromatics 7900? ---------------------------------------------------------------------- Date: Mon 28 Oct 85 12:42:42-EST From: Frank da Cruz Subject: CU20B Address, Info-Kermit-Request Mail Trouble Apologies to all who have had trouble with the host address change for CU20B. It was announced correctly in the last issue of Info-Kermit, but unfortunately it was reported incorrectly to the NIC, which had CU20B listed as [128.59.32.1] rather than [128.59.32.128] for several days. Apologies also to those who had trouble mailing to Info-Kermit or Info-Kermit-Request at CU20B, even when the host address was right -- it all started when a disk filled up... Everything should be back to normal now. ------------------------------ Date: Mon 28 Oct 85 12:42:30-EST From: Frank da Cruz Subject: New Release of BBC Acorn Kermit This is to announce Version 1.02 of BBC Acorn Kermit from Alan Phillips of Lancaster University, UK. It includes significant improvements and bug fixes over the current release, and is in extensive use in the UK. The files are in KER:BBC*.* on CU20B, available via anonymous FTP. ------------------------------ Date: Mon 28 Oct 85 12:45:02-EST From: Frank da Cruz Subject: Kermit for GEC-4000 Minicomputers This is to announce Kermit for the British GEC 4000 Series minicomputers with OS4000/RAL from Martin Loach of Rutherford-Appleton Laboratories. The files are in KER:GEC*.* on CU20B. ------------------------------ Date: Mon 28 Oct 85 12:50:08-EST From: Frank da Cruz Subject: New ACT Apricot Support for MS-DOS Kermit 2.28 This is to announce a new release of the ACT Apricot support for MS-DOS Kermit 2.28 from Ralph Mitchell of Brunel University, Uxbridge, Middlesex, UK. The files are in KER:MS*APR.* on CU20B. ------------------------------ Date: Mon 28 Oct 85 12:52:52-EST From: Frank da Cruz Subject: Kermit for RMX86 This is to announce a second Kermit program for Intel x86/xx systems with the RMX86 operating system. This one is written in PL/M by Robert Schamberger, Wilson Lab, Cornell University, Ithaca NY 14583. It is available on CU20B as KER:RMX*.* (the other one is in KER:I86*.*; they are completely different programs -- reviews or comparisons would be appreciated). ------------------------------ Date: Tue, 22 Oct 85 12:18 pst From: "pugh jon%b.mfenet"@LLL-MFE.ARPA Subject: MacKermit vs Cray I have been trying to use the MacKermit version 0.8(33) with our Cray supercomputers and it has failed to go. I have an earlier version of Kermit from Stanford that does work. The PC Kermit also works, but only version 2.27 which is because it ignores an echoed packet, or so I am told. I have tried using Kermit-PC version 2.26 with our Crays and it exhibits the same symptoms MacKermit does. I was wondering if MacKermit could be modified by the creator there at Columbia to ignore the echoed packet that gets returned. Perhaps an investigation into the changes between the two versions of Kermit-PC would be helpful. I am willing to help in any way that I can, including lots of testing. For information purposes, I am a consultant at the National Magnetic Fusion Energy Computer Center in Livermore, California, and we have users all over the country using our four Crays. It would be beneficial if we could have Kermit working for all the physicists trying to use their Macs with our Crays. I would personally hate to see people forced to use a PC. Yuck! Yours Truly, Jon Pugh [Ed. - MacKermit suffers from a bug endemic to all the current releases of C-Kermit, having to do with padding. The problem is that whenever padding is being used, and the padding character is not null (0), the checksum is calculated incorrectly, and seems to only effect the Crays, since they are the only ones that need non-null padding on Kermit packets. The problem will be fixed in the next release.] ------------------------------ Date: Wed, 23 Oct 85 10:34:39 CDT From: Gregg Wonderly Subject: C-Kermit 4.2(030) Source Wanted We want to update our Kermit server to the current release level, but have misplaced the original source we worked from, preventing us from getting diffs to show the changes we have to install to the current release. Does anyone out there have vanilla source for the C-Kermit which announces itself as "C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85"? ------------------------------ Date: Fri, 25 Oct 85 16:35:33 edt From: jso@edison.Berkeley.EDU (John Owens) Subject: VMS Kermit-32 bug fix Here is code for two changes to VMS Kermit 3.1.066. In the diffs I changed the version number to 3.1.067, but you should do whatever is appropriate with that. The first change is to the VMSMSG module to correct a bug with CRC mode. Previously, if you sent 8 bit data without 8 bit quoting, the CRC would be computed incorrectly, since the code stripped the high bit if parity was none. The fix is just to reverse the condition and strip the high bit if the parity is NOT none. Diffs to the .MAR file are enclosed, but you should rebuild it from the .BLI file instead - my changes are just hacks by hand, since I don't have a BLISS compiler. [Ed. - Code omitted, but added to KER:VMSMIT.BWR.] The second change is optional, and is just my preference. This change, to the VMSMIT module, makes FINISH not cause the program to exit, but just to return to the Kermit-32 prompt, so that, for example, statistics could be printed. This agrees with what C-Kermit does, but I believe Kermit-20 exits the program on a FINISH.... Remember not to even bother with the diffs to the .MAR file if you have access to a Bliss-32 compiler - my changes are definitely not what the compiler would do. [Ed. - Code also omitted, but added to KER:VMSMIT.BWR.] John Owens UUCP: General Electric Company ...!decvax!mcnc!ncsu!uvacs!edison!jso Factory Automated Products Division Compuserve: 76317,2354 Charlotesville, VA Phone: (804) 978-5726 ------------------------------ Date: Sun, 27 Oct 85 21:44:59 pst From: gts%ucbopal@columbia.arpa Subject: CMS-Kermit Expanding Tabs on Receive I struggled over whether to expand tabs during receive or not. Clearly leaving the file alone is more flexible for the experienced CMS user. However, most of our users do not want to bring up XEDIT and EXPAND tabs on every file they upload. Most of the systems that use Kermit to send to CMS use the tab8 convention and use it freely without the users direct knowledge of it (msdos,cpm,unix). I have decided to make tab expansion on receive the default and use a modeless prefix to disable it. Also, that mod I submitted (UCB09) is flawed because it depends on being able to overflow the ARBUF by 8 characters which is only OK because CMS-Kermit 2.01 misallocates the buffer in the first place. Please remove UCB09 until I fix it. Greg Small (415)642-5979 Microcomputer Networking & Communications gts@ucbopal.Berkeley.ARPA 214 Evans Hall CFC ucbvax!ucbjade!ucbopal!gts University of California SPGGTS@UCBCMSA.BITNET Berkeley, Ca 94720 ------------------------------ Date: Fri 25 Oct 85 13:14:50-EDT From: Frank da Cruz Subject: C-Kermit on Diskette for Chromatics 7900? Gina Morinaka of Hercules Aerospace in Utah needs to get C-Kermit on an 8" diskette for the Chromatics 7900 workstation. If you can help her, please call 801-250-3776. ------------------------------ End of Info-Kermit Digest ************************* ------- 1-Nov-85 17:11:24-EST,12809;000000000000 Mail-From: SY.FDC created at 1-Nov-85 17:10:48 Date: Fri 1 Nov 85 17:10:48-EST From: Frank da Cruz Subject: Info-Kermit-Digest V3 #28 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12155859545.18.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Fri, 1 Nov 1985 Volume 3 : Number 28 Departments: ANNOUNCEMENTS - Pascal/VS Kermit/CMS 7171 Support for IBM Mainframe MUSIC Kermit Another Kermit for Intel Micro Development Systems MISCELLANY - We Are Working on a Robust Kermit for IBM MVS/XA TSO 7171/Series 1 and Kermit-MS interaction Problems with New HP-110 MS-DOS Kermit Support Commodore-64 Kermit V1.7 QUERIES - Need Kermit Diskette for IBM PC with Xenix Need Kermit 3.5" Diskette for HP-9816 Need Kermit Diskette for HP-9000/S500 HP-UX System ---------------------------------------------------------------------- Date: Thu, 31 Oct 85 10:06 EST From: VIC@QUCDN.BITNET Subject: Pascal/VS Kermit/CMS I am sending you an updated source for my Pascal KERMIT/CMS along with an updated FULLSERV ASSEMBLE file. The new source will handle some additional server commands and fixes some minor bugs. A major bug shows up when using the old KERMIT source with the newer version of the PASCALVS compiler which does a more careful checking of strings. The updated source will correct this fault. [Ed. - The files are in KER:CM2*.* on CU20B, available as usual via anonymous FTP.] ------------------------------ Date: 24 October 1985, 16:58:52 EST From: SYSBJAV%TCSVM.BITNET@UCB-VAX.Berkeley.EDU Subject: 7171 Support for IBM Mainframe MUSIC Kermit Here is a new version of KERMIT for MUSIC (IMUSIC), based on the Indiana/Purdue original, but with support for the 7171 front end added, approved by the original author Marie Schriefer at INDYVM. J.V. [Ed. - The files are on CU20B as KER:IMUSIC.*.] ------------------------------ Date: Fri 1 Nov 85 4:21pm EST From: Frank da Cruz Subject: Another Kermit for Intel Micro Development Systems This is to announce yet another version of Intel Microcomputer Development System (MDS) Kermit, for the ISIS operating system, written in PL/M. It's an upgrade to the original version, and adds the ability to talk to a Kermit server (GET, FINISH, BYE, (remote) CWD) and a way to send multiple files using a special command LSEND that reads the list of files to send from the specified file. It was submitted by Hanh Tuan Truong Leigh Instruments ltd. 2680 Queensview Dr. Ottawa, Ontario K2B-8J9 CANADA The files are in KER:MD2*.* on CU20B. The MDS*.* files are still there too. It seems that this new version is based on the original release of MDS Kermit, which in the interim was updated & fixed at Intel's DSSO department. If anyone who cares about these systems would care to do a comparitive review for Info-Kermit, it would be most welcome. Better still would be an integration of the two programs into a single one. ------------------------------ Date: 29 Oct 85 1500 WEZ From: U02F%CBEBDA3T.BITNET@WISCVM.ARPA (Franklin A. Davis) Subject: We Are Working on a Robust Kermit for IBM MVS/XA TSO We have a robust version of Kermit for TSO systems that is adapted from the CMS Pascal Kermit. It includes server mode with most of the possible remote commands. In local mode you can execute TSO commands from within Kermit. Coming soon will be wildcards, though that is tough on an IBM... MVS and CMS are so different that it will not be possible to have a single version for both systems. However, Fritz will be maintaining it for at least the next couple of years. Anyone interested in 'Beta test' of TSO kermit, please contact us directly. -- Fritz & Franklin Institut fuer Informatik und angewandte Mathematik Universitaet Bern Laenggassstrasse 51 CH-3012 Bern Switzerland [Ed. - How about Series/1 (4994, 7171, ...) front-end support? We're getting such a proliferation of MVS/TSO IBM mainframe Kermits -- versions in assembler, Pascal, and PL/I, with and/or without Series/1 support, ... 1. U of Chicago's, based on Columbia's original (primitive) CMS Kermit, only for use on line-mode TTYs. 2. U of Toronto's, based on Chicago's but only for use thru Series/1 or 7171. 3. Rice University's, supposedly fancy, in PL/I, but you have to buy their support functions from them. 4. University of Maryland is working on yet another completely different, fancy TSO Kermit (in assembler?). 5. And now this one. Not to mention the two versions for VM/CMS; when it rains...] ------------------------------ Date: Fri, 01 Nov 85 11:05:31 cet From: PCSC%WUVMD.BITNET@WISCVM.ARPA Subject: 7171/Series 1 and Kermit-MS interaction We have found that our new 7171 protocol converters work much less well for us than the Series 1 boxes for Kermit file uploading with the newer generation of IBM-like PCs. The symptoms are a 7171 hang up when uploading files from the PC AT or Zenith 158s over 9600 bps direct connect lines. We have been using Kermit heavily for about a year, and normally these devices upload fine, but if the Kermit-MS 2.28 they are running is YAKing faster than normal due to (1) use of a mono screen (2) use of a faster crystal (3) use of FANSI-CONSOLE to speed screen writing, then the 7171 hangs in a pretty big way. Multiple master resets must be sent to the 7171 to get session control back again. If one SETs DEBUG ON in Kermit-MS, then the time spent writing the packets to a color screen slows things down enough to work unless FANSI-CONSOLE is in there speeding things up again. The evidence is as follows: Connected through 7171 to Kermit-CMS 2.01: IBM PC AT, 8mhz, EGA & ECD, with DEBUG OFF --> failure IBM PC AT, 8mhz, EGA & ECD, with DEBUG ON --> success As above w/ FCONSOLE, DEBUG ON or OFF --> failure Zenith 158, 8mhz, monochrome, DEBUG ON|OFF --> failure Zenith 158, 8mhz, color, DEBUG OFF --> failure Zenith 158, 8mhz, color, DEBUG ON --> success Connected through a Series 1 all of the above succeed. The SEND PACKET in all cases was 64 since the 7171's won't work from my AT under any conditions with a larger size. The only conclusion I have been able to draw is that the slow screen writing routines of the color BIOS slow Kermit-MS down enough such that when DEBUG is ON the YAK packet from Kermit-MS does not go back until the 7171 is ready. I assume this is because the incoming packet is being written to the screen before the YAK is sent (though I have not checked the Kermit code to verify this). I am inferring that the problem is due to the 7171 because (1) it works through the Series 1 (2) many Master Resets are required to wrest control back, but conceivably the issue is one of CMS Kermit's control of the 7171 rather than the box's internals. Any suggestions or relevant experiences would be appreciated. Michael Palmer Washington University Computing Facilites Bitnet address: PCSC@WUVMD ------------------------------ Date: 26 Oct 1985 2242-EDT From: LCG.KERMIT@DEC-MARLBORO Subject: Problems with New HP-110 MS-DOS Kermit Support Took the new version of MSXHPX.ASM last night. Unfortunately, in being compatible with both the 110 and the PLUS, it develops several problems on the plus. In particular: 1. PORT 2 is set to AUX. On the plus, this is not the INTERNAL MODEM necessarily, but is the default modem set in the system configurator. To insure that the internal modem is used, the PORT selection logic should select COM3, not AUX. 2. All character output is being sent to the punch via MSDOS PUNOUT call. This is slow, and, worse, will direct output to AUX even if the serial port is in use. 3. Minor points: the program starts with even parity and 7 bit words. This causes chaos in every situation we tried. Changes are shown below by giving at least one line before and after each change. Would appreciate your forwarding to appropriate authority. Also, leaving DTR on on the PLUS is not just a nuisance, it is deadly, since you also leave on the MODEM or SERIAL interface, which eats the battery at incredible rates. I have attached to the end of this a short program to turn those off. I run KERMIT on the plus from a command file KERMIT.BAT which contains the following: MSXHPX 1% MODEMOFF This guarantees modem/serial port doesn't run down battery. Mike Mellinger 800-325-0888 Modified MSXHPX follows: [Ed. - Code omitted, included in KER:MSXHPX.BWR for now; see next message.] ------------------------------ Date: Mon, 28 Oct 85 23:08:28 mst From: dwf%b@LANL.ARPA (Dave Forslund) Subject: Re: Problems with New HP-110 MS-DOS Kermit Support In response to the problems with MSXHPX on the Portable Plus: 1. We felt the choice of the AUX port was an advantage because one could also choose the HP-IL loop RS-232 interface from the PAM without having to add an additional port in kermit itself. It is true to use the modem with Kermit one must have selected it in the PAM. However, if it is selected then port 1 is the serial port and port 2 is the modem (or HP-IL RS-232). Choosing COM3 for the Portable makes the code incompatible with the HP-110. 2. We used this call as it was in the generic Kermit. We will try this suggested fix. 3. Our choice of even parity and 7 bit words is what works on our network here at Los Alamos and avoided us having to have a .ini file to modify the defaults. If others like other defaults, so be it. 4. Thanks for the modemoff file. It will be a big help. By the way, for this code to work properly on the internal modem in the HP110 still requires some work, as the modem does not respond conversationally but requires special ioctl commands to dial, etc. We have not pursued this any further. Dave (dwf@lanl.arpa) ------------------------------ Date: Sat 26 Oct 85 13:05:13-EDT From: RP0Q@TD.CC.CMU.EDU Subject: Commodore-64 Kermit V1.7 To: remarks@TD.CC.CMU.EDU Kermit 1.7 for the Commodore 64 is completely non-functional. There is a bug in the VT52 emulation routines which crashes the program every time I attempt to use Emacs. This same bug crashes the program whenever I try to send or receive a file, since the current packet, number of packets sent, etc, are displayed on the screen using the same routines. Does a quick fix exist for this problem, or do I have to wait for the next version of Kermit for the problem to be fixed. As it stands, Kermit 1.7 is completely useless for file transfer. HELP!!!! Roger Preisendefer RP0Q @ CMU-CC-TD [From Eric - C64 Kermit-65 V1.7 works fine at 300 baud or 1200 baud. There are no bugs in the VT52 emulation, and no 'serious' (or well known) bugs in the file transfer routines. Chances are this person did not download the files correctly to his C64 - I use Kermit with Emacs extensively and send files all the time with much sucess. I suggest that this person send away to Robert Lenoil for a C64 Kermit diskette -- 229 Commonwealth Ave, Boston MA 02116 -- $7.00 incl postage.] ------------------------------ Date: Tuesday, 29 October 1985 07:30:30 EST From: Duvvuru.Sriram@cive.ri.cmu.edu Subject: Need Kermit Diskette for IBM PC with Xenix I would like to have a kermit on my IBM PC running under Xenix (and talk to the MS-DOS PC). Where can I get a copy of one? Sriram ------------------------------ Date: Tue 29 Oct 85 14:28:43-EST From: Frank da Cruz Subject: Need Kermit 3.5" Diskette for HP-9816 Marilyn Evans, Polaroid Corp, Cambridge MA, 617-577-3662 or -2262, needs Kermit for the HP-9816. She thinks the HP-Pascal version that was written for the 9836 a while back might work. Could anyone send it to her on a 3.5" diskette so she can try it out? Thanks! ------------------------------ Date: Tue 29 Oct 85 11:39:33-PST From: David Liu Subject: Need Kermit Diskette for HP-9000/S500 HP-UX System Is there anyone ever installed and run Kermit on HP-9000/500 computer (which runs HP-UX)? This is what I am trying to do and may save me some of the efforts if I can get some advise. Dave Liu@SIERRA-SU [Ed. - Again, the best thing would be for someone to send him a diskette. Any volunteers? (Contact Dave directly)] ------------------------------ End of Info-Kermit Digest ************************* ------- 13-Nov-85 17:53:13-EST,16634;000000000000 Mail-From: SY.FDC created at 13-Nov-85 17:52:28 Date: Wed 13 Nov 85 17:52:27-EST From: Frank da Cruz Subject: Info-Kermit Digest V3 #29 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12159012856.30.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 13 Nov 1985 Volume 3 : Number 29 Today's Topics: Kermit the Frog Kermit the Book New Kermit-11 Coming Kermit for NEC APC-3 C-Kermit 4C(057), Mackermit 0.8(33), and 2.9BSD Okstate's Kermit Server Active Again Binary File Transfer Between C-Kermit and VMS Kermit-32 Kermit Problems, Notes and Praises Osborne Executive Kermit? Kermit & MUSIC SP ---------------------------------------------------------------------- Date: Tue 12 Nov 85 15:26:44-EST From: Frank da Cruz Subject: Kermit the Frog The new (December 1985) MACWORLD Magazine features a cover story on Kermit -- no, not Kermit the file transfer protocol, but Kermit the Frog, the proprietor of a whole new line of Muppet-based educational software. "Kermit" is a trade mark for some of this software, like "Kermit's Electronic Story Maker." This is one among the many good reasons why "our" Kermit should (and can) not become a commercial product. ------------------------------ Date: Wed 13 Nov 85 17:02:22-EST From: Frank da Cruz Subject: Kermit the Book I'm writing a Kermit book for Digital Press. I hope it will be out in Spring or Summer 1986, and I hope the price will be relatively low (it can't be set yet, because the manuscript isn't done, but there is general agreement that it should not be a high-priced item). I hope the book will be a big improvement over the Kermit User Guide and Protocol Manual; it will contain all the information from these manuals, plus a lot more -- background in data communications, file organization, etc; more cohernet organization, lots of illustrations, tables, code fragments, etc etc. But it will lack the detailed descriptions of the various Kermit programs found in the User Guide; that information will continue to be supplied along with each program. Anyhow, the idea is for the book to "work" for everyone from the utter novice to the Kermit programmer, pehaps in conjunction with a program-specific handout, and to promote Kermit a little more as a serious protocol and maybe encourage future Kermit program contributors to stick to the "standard" command syntax a little better and provide code examples to make it easy for them to include server mode, 8th-bit quoting, etc etc. Preparing the manuscript, plus doing my "real job," is keeping me pretty busy, which partly explains the lag between Info-Kermits (the rest of the explanation is that there hasn't been a lot of activity recently anyway). Occasionally I might bother someone for a bit of specific information to round out some table or other. Here's one tidbit I haven't been able to dig up anywhere -- what multiplexing technique is used by VA-3400 1200bps modems (frequency division?) and at what baud rate does it transmit (some 1200bps modems actually transmit at 600 baud). Here's another one -- does anyone know the etymology of "D-Connector" or "DB-xx" (as in DB-25)? Also, if anyone wants to fill in the following questionnaire and send it back to me, I'd be most grateful. This is just for purposes of filling in some illustrative tables, contrasting the diverse communication and file architectures of various machines and OS's. I've already got info for the common ones, like DEC-20, VAX/VMS, IBM VM/CMS, MS-DOS, etc etc, but am looking more for the "strange" ones -- HP minis, DG minis, P-E minis, Prime computers, mainframes of Burroughs, Honeywell, Sperry, CDC, etc. Machine, Model(s): Operating System: Version of OS following info applies to, if it makes a difference: Machine Word Size: Text Byte Size, and how many bits within byte are used for a character, and what happens to any leftover bits: Directory structure (flat file system, 1 level of directory, hierarchical): Filespec format (indicate punctuation and max length of each field, e.g. DEV:[DIR]NAME.EXT;n with DEV=6, DIR=12, NAME=8, EXT=3, n=numeric generation. Text code: (7-bit ASCII, 8-bit extended ASCII, 8-bit EBCDIC, etc): Normal record separation technique for text files (CRLF, LF, CR, RCW, fixed block, etc): EOF indication (nearest character, word, block); what happens at EOF if EOF not recorded exactly (e.g. CP/M ^Z trick): Asynchronous Communications (But first please indicate if the system normally prefers some other style, like IBM-style synchronous block mode terminals): Duplex (full, half): Flow Control (half duplex line turnaround handshake char, XON/XOFF, ENQ/ACK, ETX/ACK, etc): Required or default parity: Special or unusual characteristics worth noting about file system, text representation, or communications: Thanks to anyone who responds! Also, any suggestions of a general (or specific) nature would be most welcome, especially from people who have had problems with some aspect of Kermit that could have been avoided by better documentation. - Frank ------------------------------ Date: 8 Nov 1985 From: BRIAN@UOFT02.BITNET Subject: New Kermit-11 Coming There currently is a version 2.38 of Kermit-11 available. The version will only be available via Bitnet or dialup to UOFT02 until December 85 as I am waiting for modifications from some other people regarding M+ v3 and also PRO/TMS support. As always, the file K11CMD.MAC has the edit trail. How to get it: Bitnet: from VM/CMS: CP SMSG RSCS MSG UOFT02 KERMSRV DIR CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.* from VMS Jnet: $ SEN/REM UOFT02 KERMSRV SEND K11*.* Dialup: (419) 537-4411 Service class VX785A User: KERMIT Password: KERMIT Source and hex files are in KER:, binaries are in KERBIN: [Ed. - I imagine Brian will be sending the successor to 2.38 to Columbia when it's ready; will announce it when it arrives.] ------------------------------ Date: Fri, 8 Nov 85 13:55:55 est From: Phil Johnson Subject: Kermit for NEC APC-3 Since you had the source but not the binary for NEC APC-3 Kermit, I built the binary for you. Phil Johnson [Ed. - Thanks! It's in KER:MSVAP3.BOO ("boo" file) and KB:MSVAP3.EXE (8-bit binary).] ------------------------------ From: Vic Abell Date: 8 Nov 1985 1438-EST (Friday) Cc: abe@purdue-asc.arpa, ach@purdue-asc.arpa, acu@purdue-asc.arpa Subject: C-Kermit 4C(057), Mackermit 0.8(33), and 2.9BSD C-kermit 4C(057) does not work properly with 2.9BSD, as distributed by Berkeley. It may work with the Harvard, Seismo distribution, but I haven't tested that. One problem is that the Berkeley 2.9BSD distrubution does not support the 4.2BSD timeval and timezone structures and the functions that surround them. Thus, all of the #if tests in ckutio.c that assume 2.9 to 4.2 equivalence in that area must be undone. A second problem is that the protocol rule for Z in ckcpro.w tests for a return value from the function reof() in ckcfns.c Reof() does not return a value. The protocol rule works on 4.2BSD out of happenstance - apparently the return value register happens to be non-negative. Under 2.9BSD it doesn't work - apparently because the return value register happens to be negative. I am enclosing diffs that show the changes necessary to eliminate these two problems. The diffs for ckcpro.w also include a fix to the B protocol rule that I reported earlier to this mailing group. It prevents the EOT ack from being lost in interactive mode when the terminal is switched from cbreak to cooked. Note that the sleep time was raised to five seconds on the slower 11/70s. Vic Abell, abe@asc.purdue.edu [Ed. - Thanks! Diffs omitted, appended to KER:CKUKER.BWR, will be included in the next release.] ------------------------------ Date: Sun, 10 Nov 85 17:42:19 CST From: Gregg Wonderly Subject: Okstate's Kermit Server Active Again Due to an obscure bug in some modifications made to the KERMIT SERVER at OKSTATE, the server has not been able to service GET requests from users. This problem has been located, and fixed. We appologize for any headaches caused (We had a few here in finding this one). Thanks to those who pointed the problems out initially. Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg ARPA: gregg%okstate.csnet@csnet-relay.arpa ------------------------------ Date: Fri, 1 Nov 85 21:55:26 pst From: daver@cit-vax.ARPA (David Robinson) Subject: Binary File Transfer Between C-Kermit and VMS Kermit-32 I am having troubles transfering files to and from a SUN-2/170 running Ckermit 4C(57) and a VAX/VMS3.7 running Kermit-32(66). Transfering both ways one side or the other is mapping ALL ^J's to ^M's which reaks havic on my binary data. I have set file type to binary on both machines with no success. When I set file type fixed on the VAX (A suggestion from a friend) The file makes it thru the data transfer part but dies on the final handshaking with an error "unimplemented server command". We are constrained to use only the VAX as a server, our connection allows logins only on the VAX side. Any and all help on this problem would be appreciated. "How to get raw binary files from Ckermit to kermit-32?" David Robinson daver@cit-vax.arpa [Ed. - I've heard complaints like this before, but don't have a VMS system to track them down with, and the folks at Stevens Inst of Tech are badly bogged down in other work for the time being. Anybody out there can help?] ------------------------------ Date: Wed 6 Nov 85 21:25:42-EST From: Christopher Lent (LENT@CUPHOA.CCNET) Subject: Kermit Problems, Notes and Praises PROBLEMS: ***** MSRVRB1.BOO - MS-DOS Rainbow-100 boot file. The first line of KER:MSVRB1.BOO contains: KER:MSRB10.EXE rather than MSVRB1.EXE A minor oops but it could give a first time user a problem. [Ed. - Thanks, I fixed it.] ***** MSSDEF.H - MS-DOS KERMIT macro assembler (MASM) source header file. Perhaps a stronger warning should be included that KER:MSSDEF.H must be renamed to MSDEFS.H before compiling. [Ed. - Thanks, I put warnings in appropriate places.] ***** MSIBMP.EXE - Compiling your own: I compiled MSIBMP.EXE on an IBM/PC-XT using V2.0 MASM with the suggested /S option and have experienced no problems with the resultant V2.28 IBM-PC KERMIT. ***** notes: +++++ MSIBMP.EXE - IBM/PC KERMIT through a DECServer 100: I have been using KERMIT V2.27 and now V2.28 through DEC's new DECServer 100 terminal server. All I can say is WOW!! The configuration consists of a VAX-11/780 with VMS 4.1 running KERMIT-32 V3.1.066 and IBM/PC's, and XT's running PC-DOS 3.1 and KERMIT V2.27 and V2.28. Kermit works fine with the initial settings on the terminal server. The server doesn't interfere with the KERMIT protocol. KERMIT file transfers exhibit no visible loading of either the terminal server or VMS, even at 19.2K baud. The local CWD command has greatly aided doing incremental PC/XT backups to corresponding VMS directories. +++++ Note - Converting "BINARY" Text files on VAX/VMS created by KERMIT-32. Most users doing backups of PC's to our VAX use the KERMIT-32 SET FILE TYPE BINARY option so the .COM and .EXE files will transfer properly. This results in a minor problem when text file transferred as "BINARY" files are to be edited or revised on the VAX. A workaround procedure for this follows using the age-old editor TECO. Since TECO's calling sequence has changed in VMS 4.x two versions are given. VMS 3.x: $ ! Untested $ TECO :== $SYS$SYSTEM:TECO.EXE $TOP: $if "''p1'" .eqs. "" then inquire p1 "Binary file to be converted to text" $if "''p1'" .eqs. "" then goto TOP $WRITE SYS$OUTPUT "Converting file ''p1' to text format." $! the line after edit/teco 'p1' should contain EX $! where is the escape character (decimal 27, octal 33, hex 1B) $TECO 'p1' EX$$ $write sys$output "File ''p1' converted to text format." $exit VMS 4.x $! Works! $TOP: $if "''p1'" .eqs. "" then inquire p1 "Binary file to be converted to text" $if "''p1'" .eqs. "" then goto TOP $WRITE SYS$OUTPUT "Converting file ''p1' to text format." $! the line after edit/teco 'p1' should contain EX $! where is the escape character (decimal 27, octal 33, hex 1B) $edit/teco 'p1' EX$$ $write sys$output "File ''p1' converted to text format." $exit Usage: If the above file is called CVT.COM in the current directory simply type type following to convert the "BINARY" text file FILE.BIN $ @CVT.COM FILE.BIN and the new version of file.bin will be in VMS's default text file format. Beware: If the "BINARY" text file has lines which exceed 255 characters, VMS's EDIT/EDT editor will truncate these lines during editing. +++++ Praises: ##### Ckermit - general praises Nice Job!!! I was previously using the version now relegated to the to the documentation. The new version work fabulously on our AT&T 3b5 computer. I've even managed to get a version running on a V6 UNIX system. The V6 version was compiled using a modified V7 compiler so I doubt it would be of any use to others. With quite a bit of emulating V7 system calls, I produced a working version of Ckermit. Just a warning, in split I/D spaces on the PDP-11, some V6 system calls do NOT work. ##### Final comments: Kermit is fabulous. I now try to get it to friends as a matter of course. At first they're a little confused as to why they need Kermit, but about a month after they come back and say "Wow, how can I get Kermit for machine XYZ-123/X?" and we figure out how to load the initial copy. I must admit I'm a convert. When I originally read about Kermit in BYTE, I thought "Oh, yet another ASCII file transfer package". Reading on I thought, "Hmm, sounds pretty easy to implement". Then I put these thoughts on the back burner for a few years. In March of 1985, I found Kermit source on a FIDO BBS system and tried it on the PC. It worked wonderfully. They also had 'C' source for a Unix Version of Kermit. I loaded it on our 3b5 and our V6 system and it worked with only minor modifications. The BYTE articles made the debugging much more simple. Keep up the good work! Chris Lent lent@cuphoa.ccnet Care of: oc.pedhem@cu20b ------------------------------ Date: Wed, 6 Nov 85 20:38:02 pst From: George Cross Subject: Osborne Executive Kermit? Can someone inform me of the status of the Osborne Executive version of Kermit? Browsing through the mail archives (83/84 Epoch) one finds a flurry of interest when the OE was alive but it seems to have faded out. My questions are: 1. Does the Osborne 1 version work on the Osborne Executive? 2. Does the Generic CPM version work on the Executive? If so how? I don't receive this list regularly, so a mail reply to me would be preferred. Thanks, George R. Cross cross@wsu.CSNET Computer Science Department cross%wsu@csnet-relay.ARPA Washington State University faccross@wsuvm1.BITNET Pullman, WA 99164-1210 Phone: 509-335-6319 or 509-335-6636 ------------------------------ Date: Fri, 08 Nov 85 08:57:21 cet From: PCSC%WUVMD.BITNET@WISCVM.ARPA Subject: Kermit & MUSIC SP Does anyone know if Kermit-MUSIC 1.0 is compatible with the new release of MUSIC (MUSIC SP)? I realize that it contains its own communications program PCWS, but sites with several operating systems like ours would prefer to use one program (Kermit!) for all micro to mainframe communication if possible. Michael Palmer, Washington University Computing Facilities BITNET address: PCSC@WUVMD ------------------------------ End of Info-Kermit Digest ************************* ------- 20-Nov-85 19:26:06-EST,6349;000000000000 Mail-From: SY.FDC created at 20-Nov-85 19:25:31 Date: Wed 20 Nov 85 19:25:31-EST From: Frank da Cruz Subject: Info-Kermit Digest V3 #30 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12160864806.25.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 20 Nov 1985 Volume 3 : Number 30 BITNET Things Kermit Over Public Networks? Kermit for the HP-87? MVS/TSO Kermit with Protocol Converter? Kermit for Tandy 6000? Cromix Kermit??? ---------------------------------------------------------------------- Date: Wed 20 Nov 85 18:44:10-EST From: Frank da Cruz Subject: BITNET Things Due to a change that was made in CU20B's host tables some time between Oct 24 and Oct 29, Info-Kermit mail destined for BITNET was lost. The affected issues were V3, Numbers 27, 28, and 29. The problem is now fixed. I will remail these three issues to all the BITNET members after this issue goes out. Sorry for the inconvenience. Speaking of BITNET, those who access the Kermit file collection via the BITNET Kermit file server, KERMSRV at CUVMA, may have noticed two things, one good, one bad: (a) the KERMSRV server itself has been behaving a lot better lately, and (b) the Kermit files have not been updated in several weeks to reflect recent announcements. (a) is because our IBM systems folks have been working on KERMSRV, mostly in an effort to reduce network overhead by queuing files according to length, discarding duplicated requests etc. An announcement about exactly what was done should appear shortly. In the meantime, send the HELP command to KERMSRV to learn about any changes or new commands. (b) is because the person who used to keep the BITNET area up to date has changed jobs and has not been replaced yet; I hope the situation will be remedied soon. ------------------------------ Date: Wed 20 Nov 85 18:44:10-EST From: Frank da Cruz Subject: Kermit Over Public Networks? I know this has been hashed over before several times in the past, but I'd like the gather all the relevent information together into one place (the Kermit book)... What experiences have people had using Kermit over the public networks? These include Tymnet, Telenet, Uninet, Datapac, Transpac, Datex-P, and all the ones I don't even know about. Here's a short questionnaire: Name of Network (spelled and capitalized as the vendor prefers): Company or Organization that "owns" it: Country or Area covered: What are the characteristics and peculiarities of the network? Sacred characters, delay, transmission wakeup (does a Kermit packet correspond to a network packet?), etc... Could you make Kermit file transfer work at all? If not, what was the fatal impediment? If so, what tricks were necessary? These include SET commands to Kermit itself (for parity, packet length, retry threshold, timeout, flow control, handshake, etc; what particular parameters and values are necessary?), and commands to the network (the local or remote node or PAD). If anyone would like to answer the same questions as they apply to RS-232 connections through local area networks -- Sytek, DEC LAT, etc -- please do. Thanks in advance! P.S. And thanks to all those who responded to my previous questionnaire about computer file systems and communications -- I learned about Honeywell/MULTICS; Sperry 1100/OS 1100; HP-1000 (partly); PDP-11/RT/RSX/RSTS/POS; UCSD p-System; Prime/Primos; Os9. Any more out there? HP-3000? Data General? CDC? Cray? Gould? Perkin-Elmer? PDP-8? Burroughs? Honeywell GCOS? Lisp Machine? Etc? ------------------------------ Date: Thu, 14 Nov 85 02:18:55 -0100 From: hans@oslo-vax (Hans A. ]lien) Subject: Kermit for the HP-87? Kermit for Hewlett Packard Series 80 is needed by a colleague. A version working on the CP/M-extension card would also be of some help... ------------------------------ Date: Thu 14 Nov 85 11:39:37-EST From: Michael Fuchs Subject: MVS/TSO Kermit with Protocol Converter? Does anyone have any experience using either the U of Chicago or the U of Toronto MVS/TSO Kermit in the following enviroment (or similar): AMDAHL V8470 MVS/SP3 (will have MVS/XA) using TSO through protocol converter (asynch to SNA) to COMTEN Any tips, assurances, bewares, "no problem, pal"'s, or "won't work"'s gratefully appreciated. Michael Fuchs Coefficient Systems Corp. [Ed. - If the protocol converter is a Series/1 or equivalent running the Yale ASCII Communication system or equivalent, then the Toronto version should do the trick. Other sites are reportedly adding support for additional protocol converters to MVS/TSO or VM/CMS Kermit or both. Again, recall that this can only be done for those protocol converters that all the host to put them in transparent (pass-through) mode and take them out again.] ------------------------------ Date: 12 Nov 85 01:52:34 GMT From: Yosef Gold Subject: Kermit for Tandy 6000? I am looking for the tandy 6000 version of Kermit. The Tandy is running Xenix. I have no way to load it off tape. The ideal would be either a floppy or email. Yosef Gold ...{ihnp4,rocky2,philabs,esquire,cucard,pegasus,spike}!aecom!gold ------------------------------ Date: 20 November 1985, 17:08:08 MEZ From: Eberhard W. Lisse Subject: Cromix Kermit??? Has anybody got a net-adress for the Losinger, AG in Berne/Switzerland who are according to a rumor ( AAWAIT HLP on CUVMA.BITNET ) working on an implementation for CROMIX? As I am based in Germany a surface mail adress would do as well. Also does anybody know about an implementation for an ICL 2900 under TME ? Thanks in advance, el Eberhard W. Lisse ------------------------------ End of Info-Kermit Digest ************************* ------- 27-Nov-85 11:55:40-EST,18568;000000000001 Mail-From: SY.FDC created at 27-Nov-85 11:54:55 Date: Wed 27 Nov 85 11:54:55-EST From: Frank da Cruz Subject: Info-Kermit Digest V3 #31 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Message-ID: <12162617785.25.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 27 Nov 1985 Volume 3 : Number 31 Departments: ANNOUNCEMENTS - PDP-11 Kermit Now Available for IAS 3.1 Kermit in C for DG MV Series with MV/UX New Release of Burroughs B7900 Kermit Another Kermit for Intex RMX Systems VMS Hexify/Dehexify Fix IMUSIC - MUSIC Kermit w/7171 support UNIX KERMIT - More notes on C-Kermit 4C(057) More on Masscomp Running C-Kermit 4C(057) Zilog Zeus Kermit, Os9 Kermit Warning Problems with MacKermit for the Macintosh version 0.8(33) MS-DOS KERMIT - MS-DOS Kermit V2.28 Hardware Upgrade for some Professional Graphics Controllers ROMing MS-DOS Kermit MISCELLANY - ETX/ACK Flow Control? Problem Downloading Files with Apple II Kermit ---------------------------------------------------------------------- DATE: 25-NOV-1985 FROM: BRIAN@UOFT02 SUBJECT: PDP-11 Kermit Now Available for IAS 3.1 This is to announce that a version of Kermit-11 for IAS 3.1 is available. Due to source incompatibility, only the task image and hexified task image will be made generally available. The complete sources will be archived at UOFT02 in directory KERIAS: available from dialup access, and a copy of the sources will be sent to Frank when I send the K11 update the first week of December. Doc and HEX files are in KER: as K11I31.* and KERBIN:K11I31.TSK. Many thanks to Gene Costello and Bruce Wright of the EPA for this version of Kermit-11. Brian Nelson [Ed. - This was the last current DEC operating system that did not have a Kermit program -- now they all do. The hex, odl, cmd, and doc files are in KER:K11I31.* on CU20B.] ------------------------------ Date: Wed, 27 Nov 85 09:44:53 est From: John Sambrook Subject: Kermit in C for DG MV Series with MV/UX This is a Kermit for Data General MV Series computers. In order to use this Kermit you need the MV/UX product installed on top of your AOS/VS system. If you don't have the MV/UX product but do have Data General's C compiler you can modify the source to eliminate all calls to the UNIX emulator. While this should not be too difficult, it will require some work. I would have done it for you but my schedule is just too tight. If you don't have a C compiler feel free to translate this to another language. Note that you will need to provide a multitasking environment. This version of Kermit was created from an older version of Kermit. It may or may not be up to date. It was tested at our site with a Kermit on a 4.2BSD system and seemed to work fine. As our site is moving to native UNIX (DG/UX) we will not be using this Kermit for very long. I will answer questions about this version as my schedule permits. John Sambrook Department of Bioengineering WD-12 University of Washington Seattle, Washington 98195 Work: (206) 545-2018 UUCP: uw-beaver!entropy!gandalf [Ed. - Thanks! The files are in KER:DGM*.* on CU20B, available via anonymous FTP. The program is based mostly on the old Unix Kermit.] ------------------------------ Date: 24 Nov 85 09:44:53 est From: J.M.H. Smeets, Technische Hogeschool Eindhoven (THE), Netherlands Subject: New Release of Burroughs B7900 Kermit Enclosed is a tape containing our final implementation of Kermit for the Burroughs B7900. It includes file compression and binary transport. [Ed. - The program, which is written in Burroughs Algol, is available on CU20B as KER:B79*.*.] ------------------------------ DATE: 85/11/25 FROM: 3GTLBTL@CALSTATE.BITNET SUBJECT: Another Kermit for Intex RMX Systems I'm releasing RMXKERMIT this week. I'll get a tape off to you as soon as I can get DP to do it. Our campus bookstore will send out 5 1/4" DSDD RMX format disks for $6/disk. Disk 1 contains the executable program & documentation. Disk 2 contains source code for those who want it. Orders can be sent to: University Bookstore 6049 E. 7th St. Long Beach, CA 90840 Attn: Lyle Bartlett [Ed. - This yet-another-RMX-Kermit will be announced again when it shows up at Columbia. This one differs from the others in being an adaptation of MS-DOS Kermit, rather than a PL/M implementation.] ------------------------------ Date: 29 Oct 85 From: Andrew L. Burke, Tektronix MS 63/196, Wilsonville OR 97070 Subject: VMS Hexify/Dehexify Fix Here are fixed versions of the VMS HEXIFY and DEHEXIFY programs. While these programs worked correctly on small files (files with less than 65535 lines, or thereabouts), failed on large files. The problem was as follows: the programs both used a longword (four bytes) internally to record the current line number while reading/ writing the hexified file. However, both only read/wrote a word (two bytes) to/from the hexified file. So, when it came time for the VMSDEH program to read a line past the 65535th, it found that the line number had wrapped back to line one. This causes prolems because the program uses the line index to decide whether to expand compacted nulls or not, and when it found the next line index not equal to the current plus the current line length, it starts writing out nulls (counting from 65535 to 1, or therabouts...). To make a long story short, it didn't work. The fix is simply to read and write a longword. The other modification is to VMSDEH is that it reports an end of file error when it finished reading the hex file. [Ed. - The fixed versions replace the old ones as KER:VMSHEX.MAR and KER:VMSDEH.MAR on CU20B. This came up because Tektronix is including Kermit with its TekniCAD product on its 4100 series systems with CP/M-86.] ------------------------------ Date: Sat, 23 Nov 1985 18:06 CST From: John Voigt - Systems Group Tulane Subject: IMUSIC - MUSIC Kermit w/7171 support We have discovered a bug in the new version of KERMIT for MUSIC which supports the 7171 and Series/1 protocol converters. This bug does not always seem to cause a problem but it should be fixed in your code. The error is a result of a non-initialized control block field when sending the first packet. If you are trying to use this version of KERMIT with the 7171 and you get a message FSIO ERROR - 0B1000 then this fix should correct the problem. In routine INTRINI find the following lines: (near line number 2565) LA R1,RECPKT ST R1,KERMFSRB add the following lines after the above two: LA R1,L'RECPK2 GET LENGTH OF INITIAL SEND PACKET ST R1,KERMFSRL SET RECORD LENGTH IN CONTROL BLOCK This should correct the above error. We have also found that if the terminal is defined to MUSIC as a "B" model (with APL graphics characters) the 7171 will incorrectly translate data causing KERMIT to fail altogether. This is a permanant restiction and should be noted in a BWR file. [Ed. - Noted, along with above fix.] Also, in answer to several questions from other MUSIC sites, I would like to let everyone know that KERMIT is running on MUSIC/SP without any modifications so if you are considering a software upgrade it should not cause any proplems for your KERMIT users. ------------------------------ Date: Sun, 24 Nov 85 04:16:02 CST From: Stan Barber Subject: More Notes on C-Kermit 4C(057) One more suggestion: I would provide some mechanism to allow SYSIII compatible sites to configure what signal that might like to use to allow the child and parent to notify each other of problems. At my site, SIGUSR1 can not be used by kermit, so I modify ckucon.c by replacing SIGUSR1 with SIGUSR2. That fixes everything just fine. At least a warning should be noted somewhere (in the .bwr file, I guess) so that people will know to change it. Alternatively, I would suggest a unique name (SIGKERMIT) that the installer can define in the makefile (e.g. -DSIGKERMIT=SIGUSR2) to keep people from mucking in the source file. ------------------------------ Date: Sun, 24 Nov 85 23:07:42 CST From: Stan Barber Subject: More on Masscomp Running C-Kermit 4C(057) There is one more difference that masscomp users should check if they make Ckermit. Using the masscomp FIONREAD (when in connect mode) my cause characters to be dropped. Using myread generally works better. This is certainly true if the masscomp has the imux or jmux installed on it. It may not be true with the new HPSMux installed. We don't have one yet, so I don't know. In any case, I suggest a line for masscomp be added to the makefile of this form: rtu: make wermit "CFLAGS= -UFIONREAD -DUXIII -DDEBUG -DTLOG -O" "LNKFLAGS =" [Ed. - Thanks Stan, both your messages have been added to the .BWR file, and are on the list for the next release.] ------------------------------ Date: Tue Nov 26 11:45:41 EST 1985 From: dolqci!irsdcp!scsnet!sunder@seismo.CSS.GOV Subject: Zilog Zeus Kermit, Os9 Kermit Warning I am the contributer of the Zilog Zeus support for C-Kermit. Kermit WILL NOT WORK with the newest version of the Zeus operating system, i.e. 3.21. We have gotten C-Kermit to run under this new release but we had to rewrite ckutio.c. Do you want us to submit this new mod? [Ed. - Sure, especially if the new ckutio.c also works with the old release of Zeus. Or do we have to have two separate compile-time options for Zeus systems?] Also we think(!?) we have found two bugs in ckermit. One is in ckcpro.c. In this module, C-Kermit sends an initial NAK to the other system rather than waiting for the other side to make the first move. We simply commented this line out and now C-Kermit will talk to older Unix kermits. Could this be made public so that C-Kermit can be made a little more universal? Some systems may never be able to port C-Kermit (ala Os-9 Level I) and need to be able to talk to C-Kermit. Can this be done without losing any other comapatibility? [Ed. - Are you talking about when C-Kermit is given the RECEIVE command, or the SERVER command? In the former case, I don't see how we can get around sending NAKs -- if the expected first packet doesn't come, Kermit has to NAK it, in case it was lost on the way and the sender of it doesn't do timeouts. If your local Kermit does timeouts, you can turn C-Kermit's timer off all together with SET RECEIVE TIMEOUT 0. In the latter case, you're right, there should be a SET SERVER TIMEOUT command to turn off the periodic NAKing function of the server, but still let it time out during a protocol transaction. Something like this should appear in a future release.] The 2nd bug is in ckutio.c In this mod, ckermit waits to get the other side's eol char but then ignores it and expects its own: see the following #ifdef ZILOG seol = (len-- > 0) ? unchar(data[4]) : '\r'; /* Terminator */ if ((seol < 2) || (seol > 037)) seol = '\r'; #else eol = (len-- > 0) ? unchar(data[4]) : '\r'; /* Terminator */ if ((eol < 2) || (eol > 037)) eol = '\r'; #endif the ifdef ZILOG is our correction. It was our experience that C-Kermit would not work with any system that did not use as eol or would convert eol to . Hope this helps! [Ed. - Thanks.] ------------------------------ Date: 26 November 1985, 08:43:52 CST From: Tim Klosowski, Argonne National Laboratory Subject: Problems with MacKermit for the Macintosh version 0.8(33) I have been testing version 33 of the Kermit program for the Macintosh computer prior to its release to our users. I have encountered no problems using the program on a 9600-baud X.25 line hookup to our IBM 3033 mainframe. The problems surfaced when using a 1200-baud line. I found three cases during the course of my testing. FIRST, normal execution and normal completion. The file transferred sucessfully, the message stating this appeared and, after a mouse-click, returned to the KERMIT-CMS prompt. SECOND, normal execution and abnormal completion. The file transfers successfully and the message appears. Instead of the KERMIT-CMS prompt after a mouse-click, the program displays odd characters (such as %B..) and necessitates several carriage returns to get action on the screen. The characters continue until a file transfer error message appears followed by the KERMIT-CMS prompt. The error message states that the transfer did not complete, but closer examination indicates that the files did indeed transfer successfully. THIRD, abnormal execution and completion. The program stalls after a few packets are transferred. The emergency exit is the only recourse. The first case is what should ideally happen. The third is a known problem (occurring after an emergency exit is invoked). The one that truly puzzles me is the second. If this is a known problem or if there is something I can do to eliminate the problem, please let me know. [Ed. - Thanks for your report. I think that problem #2 has something to do with closing down the line before the acknowledgement of the B (Break Transmission) packet has been completely sent. This would only occur during uploading, and can be cured by using an even longer delay between sending the ACK and closing the line. It could also occur if this final ACK were lost for some reason; again, a delay could cure this too. The problem should be fixed in the next release.] ------------------------------ Date: Monday, 25 November 1985 13:46-MST From: Dick McGee (MMW) Subject: MS-DOS Kermit V2.28 Has anyone successfully ported kermit v2.28 to a Z100? I fixed the reported bugs in the source code and assembled it. I can upload and download with it okay. If I do a DIRECTORY, PUSH, SPACE or any command that temporarily exits to DOS it goes into the twilight zone and I have to hard reset. I'm running MS-DOS 2.18. I'm quite satisfied with the 2.26 version of Kermit, but since like Mt. Everest, version 2.28 was there I thought I would try it. s/Richard McGee dickmc@BRL.ARPA [Ed. - Sounds like another casualty of version 2.28's new dynamic memory allocation. Did you use the /S switch on the assembler?] ------------------------------ Date: 17 November 85 15:46-PST From: Don Pelton (415) 854-3300 x2901 Subject: Hardware Upgrade for some Professional Graphics Controllers [Ed. - Excerpted from a posting on Info-IBMPC.] If you have bought, or plan to buy, IBM's Professional Graphics Controller and Display, you may be interested in this. Several of us who bought this board early this year discovered, through some painstaking research, that there was a hardware bug on the board that caused it to interfere with ANY terminal emulation program making use of the asynch port. The old PGC cards have the numbers 6323697 and 6323698 on the top left of the memory card. The new cards have these two numbers inked out and the number 6448811 replaces them. The two old numbers are not always inked out and if your board has the 6448811 number, you have a new board. ------------------------------ Subject: ROMing MS-DOS Kermit Date: 25 Nov 85 10:38:57 EST (Mon) From: jcmorris@mitre.ARPA [Ed. - This message picked up from Info-IBMPC in response to a query from ad0r@cmu-cc-te about installing Kermit ROMs in IBM PCs...] It's probably not worth it. If you are willing to forgo the file upload/ download functions of KERMIT and use it to emulate a dumb terminal, it shouldn't be too difficult to replace the screen and keyboard interfaces with BIOS calls (I think that KERMIT uses DOS calls for these functions, but I don't have the code at hand). If you do this, why bother with KERMIT? There are several other packages around which provide X3.64 interfaces; the real advantage to KERMIT is the popularity of its file transfer capabilities. If you want the file transfer capabilities, on the other hand, you will have to write your own file subsystem and burn it on the PROM. For all its faults, DOS does provide a mechanism for device-independent disk access. Unless you are going to dedicate significant staff time (spelled with dollar signs) to the project, you will wind up with a package which will support only a few device types. I see occasional articles in the press which describe central-server systems where the node PC's have no hard disk (or sometimes no DASD at all). The nodes, when booted, go to the central server for their copy of DOS; this might be a better technique for you. Ciao. Joe Morris (jcmorris@mitre) ------------------------------ Date: Thu 21 Nov 85 11:11:21-EST From: Frank da Cruz Subject: ETX/ACK Flow Control? Does anybody know what ETX/ACK flow control is, and what systems use it? Is it like XON/XOFF, or ENQ/ACK, or is it something completely different? ------------------------------ Date: 24 Nov 85 00:07:26 GMT From: Jeff Hollingsworth Subject: Problem Downloading Files with Apple II Kermit I am having trouble using kermit to transfer files between an Apple IIe, and UNIX. When I try to send files from UNIX to my Apple, all occurences of the "&" (ascii 38) character are removed. This happens in both the image and text mode. However, all goes ok when I transfer a file from the Apple TO UNIX. Does anyone have an idea what is happening. The Apple has a Super Serial card if that helps. Thanks in advance. Jeff Hollingsworth UUCP: ucbvax!cory!hollings ARPA: hollings%cory@ucbvax.BERKELEY.EDU AT&T: (415) 653-3723 [Ed. - Sounds like the two sides are not agreeing about 8th-bit prefixing. The Apple thinks it's doing it, Unix doesn't. You didn't say what versions of Kermit you're running, so the problem may be fixed by now. In any case, you might be able to work around it by saying SET PARITY ODD on both sides to force 8th-bit prefixing.] ------------------------------ End of Info-Kermit Digest ************************* ------- 5-Dec-85 16:50:34-EST,20014;000000000000 Mail-From: SY.FDC created at 5-Dec-85 16:49:00 Date: Thu 5 Dec 85 16:48:55-EST From: Frank da Cruz Subject: Info-Kermit Digest V3 #32 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12164768457.21.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Thu, 5 Dec 1985 Volume 3 : Number 32 Departments: ANNOUNCEMENTS - New MS-DOS Kermit Available for Evaluation VT-220 .INI File for MS-DOS Kermit MISCELLANY - Forthcoming NIH TSO Kermit Apple Kermit Problem Fix for Apple Kermit Problem Os9 Kermit on Os9/68000 Xenix Kermit Modem Control MULTICS Kermit? Professional 350 Kermit w/o Hard Disk? HP 9836 Kermit Diskette Needed Osborne 1 SD Kermit Diskette Needed Kermit Praises and Uses ---------------------------------------------------------------------- Date: Thu 5 Dec 85 15:55:21-EST From: Frank da Cruz Subject: New MS-DOS Kermit Available for Evaluation I have the following letter from Joe R. Doupnik, Professor, Center for Atmospheric and Space Sciences, Utah State University: The enclosed tape ... holds an updated version of Kermit for MS-DOS microcomputers. This version is based on your MS-DOS Kermit 2.28 [the current version]... and is identified internally as "version 2.28 jrd". The updates include full DOS 2.0 file support thoughout, a nearly complete set of advanced server functions, much cleaned up displays (Help, Status, Set, etc), a much better file renaming algorithm, and quite a few bug fixes. All of the problems known [in 2.28 as of August 85] have been fixed and some unreported ones were as well. Internally the code has been strengthened and cleaned up generally. Kermit 2.28 jrd was built for IBM PC clones (a Zenith 151 here) and for generic machines (I have one like this using a terminal and it is not at all close to an IBM PC). However, my updates affect the modules common to all versions, [and there are also minor changes to] MSXIBM and MSYIBM. There is a READ.ME file as well. [End of letter.] I have put these files in a special place on CU20B, PS:*.*, available on the Internet via anonymous FTP. I only received the source files, but I built a version on the Rainbow, which (so far) seems to work just fine. The file names are the old ones, not the new consistent ones (see KER:MSAAAA.HLP). Since the people who used to take care of MS-DOS Kermit here have quit, I am inclined to make this the new base version. It seems to be better than July-vintage 2.28 in all respects, but I'd appreciate it if people could check it on different machines to verify this, including the IBM family (with various graphics adapters), the Wang PC, the HP-150 and 110, TI Pro, NEC APC, etc, and report back as to whether it would be a good idea to switch to this version (and point me at an .EXE and/or .BOO file). The PS: directory includes 8-bit binary .OBJ files (assembled with MASM 1.10 on the Rainbow) and MSVRB1.EXE, the 8-bit binary Kermit .EXE file for the Rainbow. The binary files are *.OBJ, *.EXE; the text files are *.ASM, *.H, *.ME. I still have a version of MS-Kermit laying around that has built-in VT100 (102?) emulation, but it's based on 2.27, and the emulation only works on the IBM PC family, but effects all the others. I figure we'd better first get a clean base to work from, and then worry about how to add new stuff to it. ------------------------------ Date: Mon, 2 Dec 85 18:17:58 pst From: Joel West Subject: VT-220 .INI File for MS-DOS Kermit I'm not the original author, but I'm told that if this is made the KERMIT.INI for MS-DOS kermit on the Rainbow, it will make the keyboard act like that of a DEC VT-220. You might wish to include it in the FTP directory at Columbia-20. Joel West CACI, Inc. - Federal westjw@nosc.ARPA {decvax,ucbvax,ihnp4}!sdcsvax!noscvax!westjw [Ed. - It's in KER:MSIVT2.INI, the author is listed as Ken Bass ] ------------------------------ Date: Mon, 2 Dec 85 19:46 EST From: RAF@UMDC Subject: Forthcoming NIH TSO Kermit I would like to correct an error that appeared in a recent Info-Kermit. It is not the University of Maryland that is doing a TSO KERMIT, but rather the National Institutes of Health in Bethesda, Maryland. The confusion most likely arose because my BITNET mailing address is at the University of Maryland until we get our BITNET connection running. A description of our TSO KERMIT follows: I spoke to you about our KERMIT on the phone some time ago. It is based on the University of Chicago TSO KERMIT, but we have really ripped it apart - so it wouldn't be recognizable. I spoke to Ron Rusnak about it before we started development. He said that they had no plans to do any further development and planned to go to the Rice TSO KERMIT. I tried to get a copy of that KERMIT, but they were unwilling to send me one at that time (but did later for $75). Since we were unwilling to wait some unspecified period of time just to look at the Rice KERMIT, we went ahead with our plans. Our TSO KERMIT has server mode, CRC, wildcard send and receive, ability to issue TSO commands, timeout (without polling), compression, 8th bit quoting, optional tab removal on upload, optional tab insertion on download, support for NIH WYLBUR edit format, a SET VOLUME command, binary file support, handling of line errors that generate a break signal, multiple records per packet, handling of lines 500 or more characters long. We also plan support for PDS members and are reworking the help info to make it more helpful. Another item is an interface to the TSO CLIST facility for KERMIT command lists. I'm no expert on CMS, but I'm not sure that TSO and CMS aren't different enough to make separate programs the most reasonable way to go. An awful lot of the program is concerned with the system interface rather than the KERMIT protocol. Anyway, ours is almost done. We will make it available to you when it is finished Roger Fajman National Institutes of Health (301) 496-5181 RAF@UMDC.BITNET ------------------------------ Date: Saturday, 23 November 1985 17:07-MST From: Jeff Hollingsworth Subject: Apple Kermit Problem I am having trouble using kermit to transfer files between an Apple IIe, and UNIX. When I try to send files from UNIX to my Apple, all occurences of the "&" (ascii 38) character are removed. This happens in both the image and text mode. However, all goes ok when I transfer a file from the Apple TO UNIX. Does anyone have an idea what is happening? The Apple has a Super Serial card if that helps. Thanks in advance. Jeff Hollingsworth UUCP: ucbvax!cory!hollings ARPA: hollings%cory@ucbvax.BERKELEY.EDU AT&T: (415) 653-3723 [Ed. - See next message.] ------------------------------ Date: Wed, 27 Nov 85 15:18:06 PST From: Bruce_Jolliffe%UBC.MAILNET@MIT-MULTICS.ARPA Subject: Fix for Apple Kermit Problem In this message I've enclosed an update to your Apple Kermit program. Versions 2.0 and 2.1 of the program do not handle eighth bit quoting correctly. A student, Sam Lam, who was working for me during the summer found the error. Below is the correction. In the procedure Rpar three operands have to be changed from "rparrt" to "rpar8" as indicated by the arrows. -- Bruce Jolliffe [Ed. - Thanks! Code omitted, added to KER:APPLE.BWR.] ------------------------------ Date: Wed 4 Dec 85 15:05:39-PST From: Bob Larson Subject: Os9 Kermit on Os9/68000 The current version of os9 kermit can't be compiled by the current version of os9/68k C (1.3) because "remote" is a reserved word. (What version of os9/68k C introduced this "feature"?) Even after this problem is solved, kermit doesn't work properly. I'll be fixing this asap. (I now have a QT+ 68000 system.) Bob Larson Arpa: Blarson@Usc-Ecl.Arpa Uucp: ihnp4!sdcrdcf!oberon!blarson [Ed. - This message added to KER:OS9KER.BWR.] ------------------------------ Date: Mon 25 Nov 85 17:10:21-EST From: Yoram Eisenstadter Subject: Xenix Kermit Modem Control? I'm trying to bring up Unix Kermit on my PC/AT running XENIX, but I'm having difficulties. I got ahold of the source, and compiled everything successfully using "make xenix". First problem: the machine hung when I tried to do a "set line /dev/tty00". I was able to do a set line only after saying "set modem-dialer hayes", even though I have a direct connection and not a modem. 2nd problem: after set line, I did a "set speed 9600". Then I did a connect. Kermit immediately came back with the message "Communication Disconnect", and returned me to the C-Kermit> prompt. I know that the hardware is O.K. I use the same communication port with MSKERMIT under DOS, and it works just fine (I'm using it now...) I was also able to use the port (/dev/tty00) from Unix with the "cu" command, by saying "cu -s 9600 -l /dev/tty00 dir". What am I doing wrong? [Ed. - See next message...] -------------------- Date: Wed Nov 27 12:10:47 1985 From: Herm Fischer Subject: Re: Xenix kermit difficulties Ahh, the saga of carrier detect, clear to send, and data set ready continues... If you fire up kermit, when you do a set modem-dialer, you place kermit into the "clocal" (ignore carrier detect absence) state. If you fire up kermit on a direct connection without a modem, then be sure carrier detect is present on the pins of the cable before firing kermit up. I suggest purchasing one of those widget connectors with the led's which goes between the rs232 cable and the computer to see which signals are present. Often on direct connections, it is common to hot-wire carrier detect to some other signal to get it to come up. If you're on a LAN, then there might be a LAN option to raise the carrier signal... Your communications disconnection message comes from the UNIX operating system notifying kermit that the carrier signal has dropped! Same problem. cu may override the "clocal" flag; I haven't looked at its code. kermit cannot override that flag because it must know when a remote modem hangs up, lest it tie up a system or hang it... Herm Fischer HFischer@isif.arpa; {ihnp4, decvax, randvax}!hermix!fischer [Ed. - Herm not only wrote the Xenix modem support in C-Kermit, but he also uses it all the time -- an existence proof that it works.] ------------------------------ Date: Fri, 29 Nov 85 12:24 EST From: Wiedemann@RADC-MULTICS.ARPA Subject: MULTICS Kermit I have recently moved to Maui and been out of touch with my usual MULTICS machine for about two months. In that time, a new release of the operating system was installed. This came with KERMIT. The new KERMIT does not respond to my PC KERMIT, even though I have successfully used this repeatedly with the previous version of MULTICS KERMIT. I have made every effort to ensure that the file parameters match at both ends. Could the fact that I'm now using a TAC have something to do with it? Transfer has failed both ways using either an ASCII or binary file. Anyone have a systematic approach to a solution?? I'd appreciate the help as Maui is a veritable computer "wasteland"! Wolf Wiedemann RADC-MULTICS [Ed. - TACs are always a pain. But I also keep hearing about all these different versions of MULTICS Kermit that are in use "out there" that I have never seen personally, so it might just as likely be the culprit. Anybody care to clear up the MULTICS Kermit confusion? Which is the "real" one, and where does it come from?] ------------------------------ Date: Mon, 2 Dec 85 17:20:32 EST From: Chris_Moore%UB-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA Subject: Professional 350 Kermit w/o Hard Disk I presently use Kermit on my Digital Pro-350, however I don't have a hard disk on this system thus it operates as a Pro-325. While Kermit functions just fine with the obvious exception on interfacing with the other utilites which it expects on disk, I can not get kermit to retain its communications settings so it ALWAYs uses the defaults. The problem seems to be that Kermit wants to store its settings in a file somewhere, but I can't figure out what that file is named or where it is supposed to be; if I could, then I could create it and suspect all would be fine! Any help with this would be greatly appreciated. --chris ------------------------------ Date: Thu 5 Dec 85 08:44:31-EST From: Frank da Cruz Subject: HP 9836 Kermit Diskette Needed If anybody has HP9836 Kermit on a diskette and is willing to send a copy to someone who can't get it any other way, please call Steve Masticola at RCA, Somerville NJ, 201-685-6594, collect if desired. And if you're willing to send Steve a disk, how about also sending one to the HP98x6 user group (is there such a thing?) so they can handle these requests? ------------------------------ Date: Thu 5 Dec 85 11:27:12-EST From: Frank da Cruz Subject: Osborne 1 SD Kermit Diskette Needed I got a letter from Norway that was addressed like this: Columbia University Columbia, USA It actually, came to me... Somebody in Norway figured out that CU was in New York, and then somebody at Columbia opened it up and saw the word Kermit in it... Anyhow, this guy lost his only copy of Kermit because of a power hit, and can't find a single-density copy of it anywhere in Norway. If some kind soul would send one to Einar Norway I'm sure he'd appreciate it. Just kidding, his full address is Einar Fredriksen Edvard Griegsvei 34 N-5037 Solheimsvik NORWAY Thanks! ------------------------------ Date: Thu 5 Dec 85 13:46:34-EST From: Chris Lent Subject: Kermit Praises and Uses KERMIT in the trenches: We've been using KERMIT down at Cooper Union quite a bit. (We're at 3rd Ave and East 8th Street). After I bought a copy of the tapes, I put it on our systems down at Cooper. These are: VAX 11/780 VMS 4.2 ATT 3b5 System V UNIX R 2.0.211 PDP-11/45 UNIX V6 (plus) ! This took a good bit of work PDP-11/23 UNIX V6 (plus-more) ! Same as 11/45 IBM-PC's, and PC-Jr's PC-DOS 2.0,2.1,3.0,3.1 ATT 6300 (Very IBM compatible AND FAST!!!) Apple Mac's ! The VT102 emultator comes in very handy. Intel Blue Boxes "MDS-80" (ISIS-II)(8" Floppy only) ! We transfered this via a block-by-block copy ! from our VAX RX01 Console Floppy Intel 310's ! DON'T EVEN THINK ABOUT BUYING THESE TURKEYS!!!! ! The 310's run MS-DOS BADLY (We had to write drivers for the serial port and winchester that Intel put in!!) ! Intel also foists IRMX-86 on you (Everyone needs an archaric multi-user Operating System on a machine that one person uses?) ! Kermit is having a hard time here only because the ! port drivers still are bug-infested. We tend to ! transfer to an IBM-PC and take the MS-DOS floppy ! and read that instead. Intel 380's ! BIGGER Multi-User TURKEYS!! ! Intel hasn't managed to port MS-DOS to these yet!!!! Now we do a multitude of daily and regular transfers like: STUDENT USE: Student archiving of programs. This works wonderfully as we don't have to hunt through age-old backups for their stuff. It also has the added benefit that if the programs are written portably in 'C', Fortran, Pascal or Basic, they can do development work on PC's and other micros around the school or at home. The archiving is done at local PC's. This is necessary as our money for dialin facilities is limited and our computers are brought down each night because the building is closed. Students talking to FIDO bulletin board systems from home. This way they can get the latest shareware utlities. Students talking to each other's systems. One interesting case is a lab group where the guy with the MAC did the diagrams, and printed the final version of the paper while another member typed the paper on his IBM. The third member proof-read the text on his Commodore-64. Let's hear it for two wonderful standards: ASCII and KERMIT!!!! COURSE AND PROJECT USE: Sending GTSTRUDL plotting files from our VAX to the 11/45 where our CALCOMP plotter is. This lets our civil engineers make giant plots of their structures and how they will deform under load. Sending Digitized maps and data from the 11/45 to IBM-PC's and the VAX. There a lot of this. The students in the CAD/CAM course have to design a simple packeage and many of them digitize their intial shape library on the 11/45 before moving them to the final machine. Sending sample bitmapped image data from RT-11 format tapes read in on our VAX to Intel 380's for work in developing medical imaging systems. MORE STUDENT USE: Sending and receiving programs under development from grad and undergrad students machines out at Bell Labs (and AT&T clones) for course work (complier design, programming languages, data structures, and of course the infamous Master's thesis). Bell Labs machines at Whippany, Homdel, and Parsippany get the new versions from us as we get them from you. Once Kermit'ed to a Usenet machine, the programs flow over Usenet to the apporiate machines. Most times they just type % make sys3 or the make for Berkley 4.2 and the Kermit works perfectly right away. Many times the user DOESN'T know what type of machine he's running on (VAX, 3bx or whatever) and it STILL works well even though the "RIGHT" version wasn't used. The first version when over via the UNIX 'cu'(CALL UNIX) utility which talked through the VAX's modem via KERMIT in CONNECT mode. After fixing up the transmission errors, we compiled it and got a reliable version of KERMIT via our 'cu'ed version. FACULTY USE: The faculty computer program. Professor's develop programs at home that the students use in their classes on the main computers. The number of these programs we support now is getting huge. Faculty work on remote machines in places like Texas and Califonia. Usually they have older versions of KERMIT, so we ship a new version to our faculty member's account via the old KERMIT and then tell the remote staff where to find it for system-wide installation. And even more every day. It seems like every third word out of my mouth is KERMIT. My policy is now whenever someone has a machine or an account on a machine which doesn't have KERMIT, we find some way of moving KERMIT to them. I must admit I thought the demand would be large but it just seems to be growing in leaps and bounds. The thing is that I've learned about so many strange operating systems while installing KERMIT, but I rarely (once a month) have to examine individual KERMIT packets when porting a new KERMIT version. We just seems to be trashing more old file transfer programs every day. It doesn't matter if they we purchased or hacked together, KERMIT is in general better and makes MUCH more sense to maintain. We usually keep the old one around until we figure out how to send strange file formats (VMS is famous for these.) Well, I'll keep KERMITing the rest of the Universe. Thanks, Chris Lent Care of: OC.PEDHEM@CU20B.COLUMBIA.EDU (VAXmail) CUPHOA::LENT (I'm working on tailoring utilities and EUNICE for them up here) ------------------------------ End of Info-Kermit Digest ************************* ------- 11-Dec-85 11:00:48-EST,9532;000000000000 Mail-From: SY.FDC created at 11-Dec-85 10:59:58 Date: Wed 11 Dec 85 10:59:58-EST From: Frank da Cruz Subject: Info-Kermit Digest V3 #33 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12166277797.20.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 11 Dec 1985 Volume 3 : Number 33 Departments: MS-DOS KERMIT 2.28 JRD - MS-DOS Kermit 2.28 jrd Not on BITnet MS-DOS Kermit 2.28 jrd Bug with X Packets Bug Report on MS-DOS Kermit 2.28 jrd on 18MHz PC/AT Suggestion for MS-DOS 2.29 Minor Mod to New MS-DOS Kermit MISCELLANY - Apple-II Kermit Bugs Multics Kermit ---------------------------------------------------------------------- Date: Wed 11 Dec 85 10:13:20-EST From: Frank da Cruz Subject: MS-DOS Kermit 2.28 jrd Not on BITnet In response to numerous requests from BITnet for Joe Doupnik's improved version of MS-DOS Kermit 2.28, I'm sorry to say I can't put it on BITnet just yet, for a variety of reasons which are too complicated to explain. It looks as though this version will wind up replacing the current one -- one or two minor bugs need fixing, plus checkout is still required on the Wangs, HP's, NECs, etc -- and at that time it will replace the current version on BITnet. I'm also sorry I mentioned the MS-DOS Kermit 2.27 that had VT100 support added to it. In response to numerous requests for it, let me just say that in order to avert utter chaos, I would prefer to get the fixed 2.28 installed as the standard, base version, and then call for volunteers to take the VT100 support and fit it into the new base version. If we don't do it that way, we'll have multiple proliferating divergent versions of the program which will be impossible to support. Those of you who whose phone doesn't ring 500 times a day with MS-Kermit questions might not appreciate why this is important, so you'll just have to take my word for it. Once again, I apologize for the reduced level of support for MS-DOS Kermit and the BITnet Kermit files. Like I said before, it's because the people who used to take care of these things have left Columbia. They will be replaced, but I can't say when. Soon, I hope. ------------------------------ Date: Tue 10 Dec 85 18:02:07-EST From: Frank da Cruz Subject: MS-DOS Kermit 2.28 jrd Bug with X Packets First real bug -- if you send a generic command to a server which the server does not support, and it sends back an error packet (which is the proper behavior for servers under the circumstances), then the next file sent by MS-DOS Kermit has its name in an X packet rather than an F packet, which of course the server is not prepared to handle. MS-DOS Kermit is apparently setting its "X flag" in anticipation that the generic command will elicit a X packet or a data-bearing ACK from the server, and then not resetting it when the transaction is terminated by an error. In fact, it should not set this flag until such a response actually occurs, and it should reset the flag at the beginning of each transaction. Reportedly, the same behavior crops up randomly (not reproducibly) at other times. Thanks also to others who reported this problem. If anybody develops a fix (it should be real simple, something like setting the X-Flag to 0 at the top of the command loop), please send it in. ------------------------------ Date: 9 Dec 85 08:57:00 PST From: ALEX WOO Subject: Bug Report on MS-DOS Kermit 2.28 jrd on 18MHz PC/AT The new MS-DOS kermit seems to work fine on a 4.77MHz PC but it coughs on a 18MHz PC AT with the error message "? Not enough memory to run kermit" The PC AT has about 2MB of memory. [Ed. - Beats me, anybody have any ideas? Doesn't sound like anything that would involve timing loops... Do all your other programs work on your souped up AT??? Does the old Kermit?] Also, if there a Makefile for the MS-DOS version of Kermit, perhaps using one of the Info-IBMPC makes. [Ed. - There isn't, sorry. Does anyone know if there is a "make" that will support command line arguments, so you can say "make ibm", "make rainbow", "make tipc", etc? If so, which one is it, where is it?] Alex. ------------------------------ Date: Mon 9 Dec 85 04:18:07-EST From: Joe Smith (415)794-2512 Subject: Suggestion for MS-DOS 2.29 If you do plan to use MSKERMIT 2.28 jrd as the basis of the next release of MS-DOS KERMIT, please add "SET TERMINAL mumble" and "SET DTR mumble" to the system independent code. Define dummy entry points in all the system dependent modules so they can parse "mumble" or say "not implemented". Then the developers could add system specific arguments to these commands, such as: SET TERMINAL NO-WRAPAROUND SET TERMINAL WIDTH 132 SET TERMINAL ID VT125 SET DTR ON SET DTR OFF SET DTR HANGUP-ON-EXIT We need a general way to get to system-specific functions thru KERMIT's command scanner. /JMS [Ed. - These sound like useful hints for whoever is going to volunteer to fit the VT100 support into 2.28 jrd.] ------------------------------ Date: Sun, 8 Dec 85 01:23 EST From: Larry Afrin Subject: Minor Mod to New MS-DOS Kermit The new MS-DOS Kermit (jrd's rewrite/mod of 2.28) has a minor problem when it invokes COMMAND.COM to do stuff like TYPEing out files, DELeting files, running CHKDSK, and RUNning any other program: when you type in the command line in response to the "Kermit>" prompt, and then hit Enter, only a carriage return is echoed. No line feed. This means that the first line of output (either from COMMAND.COM or from the program loaded in by COMMAND.COM) overwrites the "Kermit>" prompt and the command you typed. Trivial, I admit, but aesthetically displeasing. I made the following mod in the location of the "run3" label in the MSKERM.ASM module in PS: to output the needed line feed. [Ed. - I've appended your code to the MSKERM.BWR file, but I can't reproduce the problem, either on a PC/AT or a Rainbow.] Other than this minor problem, I haven't found anything wrong yet with jrd's version. I'm running PC-DOS 3.10 on a plain vanilla PC. Still waiting for a VT100 emulator to replace the Heath-19, though... (hey, we can dream, can't we?) [Ed. - Yes, but can we volunteer?] P.S. I'm running MASM version 1.00 (from the Dark Ages of 1981), and in order to get the segments in the right order for the linker, I had to change all references to segment name STACK to segment CTACK. These references are in modules MSKERM.ASM (4 references) and MSXDMB.ASM (2 references). If you don't make this change, the machine winds up taking a long walk off a short pier when you hit Control-] C to come back from on-line mode to command mode. [Ed. - Anyone else have this problem? I assembled the files with Microsoft MASM 1.10 (1981,82) using no switches, and not renaming any segments, and the result worked fine. Also, has anybody ever heard of the /DOS switch that Joe mentioned in his letter?] ------------------------------ Date: Fri 6 Dec 85 01:25:39-EST From: Peter G. Trei Subject: Apple-II Kermit Bugs In reference to Sam Lam and Bruce Jolliffe's fix for the Apple ][ Kermit's 8th bit quoting bug, here is a way to install it in version 2.1a without doing another download. I have not yet had the opportunity to perform thorough checking and testing of this fix, so be cautious! [This patch only works for version 2.1a] Make a copy of your kermit-65 disk. Boot with the new disk. Enter the following DOS commands: ] UNLOCK KERMIT ] BLOAD KERMIT ] POKE 17303,35 ] POKE 17317,21 ] POKE 17329,9 ] POKE 17399,194 ] DELETE KERMIT ] BSAVE KERMIT,A$801,L$4E9B As soon as I have finished checking this fix, I will ask Frank to put the updated source and hex files into the download area on CU20B for distribution. This may be related to the bug that strips out '&' on reception of files. Peter Trei oc.trei@cu20b ------------------------------ Date: Fri, 6 Dec 85 17:20 EST From: "John C. Klensin" Subject: Multics Kermit As of approximately now, the 'real' Multics kermit is the one with which problems were reported in V3#32. It is a version created at Calgary and being distributed with the system and supported by Honeywell (it is, consequently, unlikely to be released to the Columbia archives). It supports many options that the various older versions and kludges do not, incluing server mode, 8th-bit-quoting, etc., and is structured much more like other Multics commands that do similar things, such as the Internet FTP command. Its default option settings, however, tend to be a little more optimized for Multics<->Multics transfers over X.25 and dial circuits than for PC->Multics or Internet TAC use. Users with problems should probably bug Honeywell over conventional channels, as this is a supported product. Does that help? [Ed. - I guess. Columbia, by the way, has never received this version of Multics Kermit. I suppose if all Multics sites get it automatically, no harm is done.] ------------------------------ End of Info-Kermit Digest ************************* ------- 19-Dec-85 12:28:31-EST,20252;000000000000 Mail-From: SY.FDC created at 19-Dec-85 12:27:49 Date: Thu 19 Dec 85 12:27:48-EST From: Frank da Cruz Subject: Info-Kermit Digest V3 #34 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12168390938.12.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Thu, 19 Dec 1985 Volume 3 : Number 34 Departments: ANNOUNCEMENTS - New Honeywell CP-6 Kermit New version of IMUSIC MS-DOS KERMIT - MS-DOS Kermit 2.28 jrd Problems and Fixes IBM-PC Kermit V2.28 jrd Display Problems TopView Support for MS-DOS Kermit More MS-DOS Kermit 2.28 jrd Problems MSBOOT.FOR for Unix f77 MISCELLANY - DEC-20 File Naming Problem Os9 kermit warning! Bugs in the CP/M Turbo-Pascal Kermit V1.00 Re: Apple-II Kermit Bugs ---------------------------------------------------------------------- Date: Thu, 18 Dec 85 10:50 EST From: Frank da Cruz Subject: New Honeywell CP-6 Kermit This is to announce a new Kermit program for Honeywell CP-6 systems from Lee Hallin at Honeywell (Lee-Hallin%LADC@CISL). This one is written in PL/6, a PL/I-like language, and includes text/binary file transfer, wildcards, all the prefixing options, server and client operation, command files, etc, but lacks CRC, file interrupt, attributes. (The other CP-6 Kermit is written in Pascal and comes from Bucknell University.) Lee's new CP-6 Kermit is available from CU20B via anonymous FTP as KER:HC6*.*. Again, apologies to everyone on BITNET for the hiatus in getting new files on KERMSRV; we should be back in business on that end after the holidays. ------------------------------ Date: Mon, 16 Dec 85 20:14 EST From: John Voigt - Systems Group Tulane Subject: New version of IMUSIC I have a new version (1.2) of IMUSIC KERMIT available. This version incorporates several fixes as well as enhancing the set ? function. I have sent you the complete source with all the new changes. JV/ [Ed. - Thanks! This replaces the previous version (1.1) on CU20B. It's in KER:IMUSIC.ASM.] ------------------------------ Date: 12 Dec 85 21:23:04 PST (Thu) Subject: MS-DOS Kermit 2.28 jrd Problems and Fixes From: donovan@aero I've attached a fix to MS-DOS Kermit v2.28 rjd for a problem in the send protocol. The problem occurs when a send command follows a Kermit generic command which causes flags.xflg to be set. This happens whenever a remote server displays output on the local screen. The GENRIC procedure in MSSSER is the culprit, but the simplest fix is to reset xflg in the SEND command processor just before the server entry point at SEND11. Here are diffs for MSSSEN. ..........mssend.old ; Send command ..........msssen.asm ; Send command - protocol handler to send a file ; Normal entry - SEND does file transfer preceded by "F" packet ; resets xflg ; Server entry - SEND11 does file transfer preceded by "X" packet ; set xflg = 1 before call ..........mssend.old send11: mov flags.nmoflg,0 ; Reset flags from fn parsing. [21a] mov ah,setdma ; set dta address [jrd] ..........msssen.asm mov flags.xflg,0 ; Reset flag for normal file send [mtd] SEND11: mov flags.nmoflg,0 ; Reset flags from fn parsing. [21a] mov ah,setdma ; set dta address [jrd] [Ed. - Thanks! This was the most glaring bug in this version.] Also, the Z-100 version has had a bug in backspace processing since v2.27. When entering Kermit commands at the prompt, backspace (^H) won't back up over characters on the screen. The problem is caused by a change made to MSSCMD.ASM near the label "cmge11". Backspace was removed from the set of characters which are echoed. The fix is to change MSXZ10.ASM to send an extra backspace. "diff"s below. ..........msxz10.old delstr db BS,' ',BS,'$' ; Delete string. [21d] home db ESC,'H$' ..........msxz10.asm delstr db BS,BS,' ',BS,'$' ; Delete string. [21d] home db ESC,'H$' The MS-DOS version with Joe Doupnik's modifications works with both HP150 and, with this fix, Z-100 modules. Joe's modifications are a major improvement to MS-DOS Kermit. I suggest that once the documentation catches up with the programming, the revised Kermit should be accepted as MS-DOS Kermit v2.29. [Ed. - Well, a couple more problems remain, and the contributions keep pouring in. But you're right, we have to draw the line somewhere. See below...] ------------------------------ Date: Sat 14 Dec 85 05:33:09-EST From: Kathleen Connors Subject: IBM-PC Kermit V2.28 jrd Display Problems I tried the new 2.28 version of Kermit for the IBM PC tonight. It still has some of the same problems (2 out of 3) that the old 2.28 version had, which I reported to you last June. 1) When you GET a file the file transfer screen puts an "s" in upper left hand corner of the screen. 2) The mode line under the same conditions displays nothing except a single "^" in the first position. The truncation of the file name upon receiving a file has been fixed. I am using a IBM PC I (64k motherboard), 512k of memory, DOS 3.0 and a internal Qubie (Hayes compatible) modem. Since these problems, albeit cosmetic, still exist I will probably continue to version 2.27. [Ed. - Has anyone else ever seen this? I haven't, and I've been running both 2.28 and 2.28 jrd on an IBM PC for a couple weeks.] Suggestions for future Kermits: 1) A means of clearing the terminal screen buffer from the local Kermit. 2) The Kermit initialization file should be allowed to be called KERMIT.INI instead of MSKERMIT.INI. [Ed. - The reason it's called MSKERMIT.INI is that if you accidentally transfer your KERMIT.INI file from a mainframe, you'd be in for some nasty surprises the next time you started Kermit up on your PC.] 3) The ability to send a file "raw" without the Kermit protocol just xon/xoff. [Ed. - Everybody wants this, along with login scripts and a DIAL command. Maybe someday someone will write the code.] ------------------------------ Date: 12/16/85 6:10:45 E.S.T. From: TUCBOB@TUCCVM.BITNET Subject: TopView Support for MS-DOS Kermit Here is a new MSYIBM terminal emulation module; the following changes were made: . ANSI set graphics rendition support extended to handle color attributes in addition to monochrome . Direct moves to and from the video buffer modified to use TOPVIEW interrupt codes, so that KERMIT can run in the background under TOPVIEW and take advantage of TOPVIEW windowing support. The following parameters are used in a TOPVIEW Program Information File to run KERMIT under TOPVIEW with the MSYIBM TOPVIEW support added. Memory: Variable. Suggest min and max be set to 128K to allow 'run' support. Set system memory to about 20K Screen type: D Pages: 4 Window size: 25 by 80 Offsets: 0 0 Writes directly to screen: no Accesses system keyboard buffer: no Runs only in the foreground: no Uses math coprocessor: no [Ed. - Thanks! I haven't had a chance to try this out, but if these are the only changes, then it should be compatible with JRD's new stuff, except for one minor change that JRD made about Heath line wrap. If anybody wants to try this out, the file is with JRD's Kermit, stored as PS:MSYIBM.TOP on CU20B only -- If you take it, please report back about how/if it works, and whether it's safe to distribute as the standard version.] ------------------------------ Date: Thu 19 Dec 85 09:24:23-EST From: Frank da Cruz Subject: More MS-DOS Kermit 2.28 jrd Problems Beyond the bugs reported already (like the X-Flag bug), there are at least two subtle problems with the new MS-DOS Kermit. First, even when assembled correctly with the "right" assembler and switches, it will sometimes (very rarely) start executing garbage after a CONNECT command. This happened to me exactly once in several weeks of constant use -- I had escaped back from a connection to the DEC-20, gave the DO IBM command, switched my port contention unit to the IBM mainframe, gave the CONNECT command, and poof -- system totally dead, had to be rebooted. A few other people have reported similar occurrences. I can't reproduce it; can anybody else? The second problem applies to earlier releases as well, but only shows up on a PC/AT, and (for us at least) only when communicating with a half duplex system at 9600 baud using handshake. The sympton is that, after the end of a file transfer session from the mainframe to the PC, after the mainframe sends the B (Break transmission) packet, the AT responds with its ACK, but the ACK shows up as garbage at the mainframe. If on the AT you SET DEBUG ON, the problem goes away. When the connection is run through a line monitor, everything appears normal; the AT responds to each packet from the mainframe immediately as the XON handshake appears, and ACK is in correct format. The speculation is that the AT is somehow ACKing the B packet "too fast". Even though we haven't caught it sending the ACK prematurely on the line monitor, the behavior is exactly what you'd expect if a transmission occurred before the line was fully "turned around". Why would this happen after a B packet, but not after any other packet? Several possible explanations suggest themselves: (a) unlike most other packets, the B packet requires no processing, and can be ACK'd immediately; (b) MS-DOS Kermit somehow forgets about handshaking after the B packet; (c) MS-DOS Kermit is handling the UART incorrectly. I think (b) is unlikely; we never saw any supporting evidence on the line monitor. While (c) is a possibility, it would take a lot of digging through the low-level code to show up a problem; a cursory inspection reveals nothing obvious (the UART's output holding register is always tested for emptiness before giving it the next character). If (a) is true, it would imply that the host is sending its XON before it is really and truly ready for input. Unlikely as this may seem (it's a lightly-loaded IBM 3083), the fact that the problem only happens with the AT -- which is much faster than the PC or the Rainbow -- lends some credence to this theory. If this is the real explanation, then the thing to do would be to insert a brief sleep in MS-DOS Kermit before ACKing the B packet. But there are also some other packets that don't require any processing, namely those that arrive with bad checksums; thus we might have to sleep before retransmitting or NAKing as well. If anyone can offer any insight or evidence to support any of these theories, it would be much appreciated. But beyond that, we may have here a presage of things to come. As microcomputers get faster and faster, they may begin to strain the assumptions underlying the design of our communications equipment. ------------------------------ Date: 13 Dec 1985 1427-EST (Friday) From: Tom Putnam Subject: MSBOOT.FOR for Unix f77 The subject FORTRAN program is supposed to be run on a host machine in conjunction with MSPCBOOT.BAS on a target MS-DOS machine to download MSKERMIT.BOO and similar binary files. The program requires several modifications to operate under UNIX. (We are running UNIX 4.2 BSD). In particular: * The variable ACK is declared as a 4-element array, but only the first element is ever used. The initial READ statement: READ (5,200) OK, SPACE, COMMA, ACK 200 FORMAT(4A1) implies that the whole array ACK will be read. Since the format does not allow enough elements, a second "line" or "record" of input is requested, so file transfer never gets off the ground. * The write statements include a blank for carriage control. Although some systems strip this character on output to the terminal, UNIX terminal output includes the blank and thus fouls up the character count check. I corrected these problems, converted the program to FORTRAN-77, and cleaned-up the logic a little so that we could use it on our systems. The modified version of the program is available via anonymous ftp from ASC.PURDUE.EDU in the "kermit" subdirectory, file name "msboot.f". [Ed. - It's also on CU20B as KER:MSBOOT.F.] Tom Putnam, Manager of User Services Purdue University Computing Center ARPANET: ac4@asc.Purdue.EDU or ac4@purdue-asc.ARPA BITNET: PUTNAMT@PURCCVM CSNET: ac4@purdue-asc-tn USENET: ac4@pucc-j.UUCP USMAIL: Mathematical Sciences Bldg. West Lafayette, IN 47907 PHONE: 317/494-1787 ------------------------------ Date: Tue, 17 Dec 1985 13:34 EST From: CPH%MIT-OZ@MIT-MC.ARPA Subject: DEC-20 File Naming Problem I am using TOPS-20 Kermit version 4.1 and running into the following problem: The filenames that I am using on my microcomputer are in the same format as TOPS20 filenames, that is, "..". The software system maintains the version numbers in the usual way. As we have quite a few of these computers, which are not tied together with a network, we use Kermit to transfer files to and from MIT-OZ, our DEC 20. This gives us all a shared file system to work from. Now, my problem is that I want to transfer files from my local machine to the 20, retaining the version number (note that this works fine when transferring from the 20 to the local machine). This is so the version numbers on the 20 will match the version numbers on the local machine. Unfortunately, TOPS20 Kermit doesn't have an option to do this. As far as I can tell, the only options I have are "set file naming unconverted" and "set file naming normal-form". In neither case is the version number I specify used to write the output file on the 20. Instead, the file is forced to be a "newest" generation -- either "FOO.BAR.34.0" (where the is "BAR.34") or "FOO.BARX34.0", respectively. Could this be changed? It seems to me that if the version number is explicitly specified, it does no harm to open the output file under that name if one does not already exist. Or, if that is not reasonable, could you add an option, say, "set file naming literal", that does what I want? It is really a pain for me to have to rename all my files after I transmit them. Thanks, Chris Hanson [Ed. - Thanks for the suggestion. I'll try to add another file-naming option to Kermit-20 in the next release.] ------------------------------ Date: Mon Dec 16 10:58:59 EST 1985 From: dolqci!irsdcp!scsnet!sunder@seismo.CSS.GOV Subject: Os9 kermit warning! A warning about using kermit under os9 on a tandy CoCo: If you use kermit with the multi-pak and the delux rs-232 pak, that is you intend to use /t2 as your outgoing device you MUST have the rs-232 pak in slot 1 of the multi-pak. In fact the device driver for /t2 requires that the rs-232 pak be in slot 1. ANY program that uses /t2 will only run if the rs-232 is in slot 1. Also it appears that you must have the carrier forced on BEFORE you run kermit if you are using sometype of smartmodem. (maybe some os9 wizard out there can find a patch to the device driver to let /t2 look for the rs-232 pak in another slot). Kermit on the CoCo is still (as far as I know - maybe bob larson knows more) untested using device /t1, the so called "bit banger" port. ~ Addresses: USmail: IRS, 1111 Constitution Ave. NW Washington, DC 20224 ~ ~ Atten: M. Sunderlin PM:S:D:NO Office Phone: ~ ~ UUCP: ...seismo!dolqci!irsdcp!scsnet!sunder (202) 634-2529 ~ ~ ...decvax!philabs!ubbs!sund (FTS) 634-2529 ~ ~ CIS: 74026,3235 ~ ------------------------------ Date: Wed, 18 Dec 85 13:32:59 cst From: Jeff Woolsey Subject: Bugs in the CP/M Turbo-Pascal Kermit V1.00 I have found and fixed a few bugs in the Turbo Pascal Kermit for CP/M-80, and made some simple but useful enhancements. Bug #1: Binary file transfers "worked" (everybody was happy with checksums) but the file was missing the 8th bit sometimes. &X would not get the 8th bit set, but &#X would. The code that checked for control characters in this case forgot that this was an &-quoted character if it wasn't also #-quoted. The fix in the else clause should be obvious. See procedure expand_packet in file KREC1.PAS here: [Ed. - Code omitted.] Bug #2: This first showed up as filenames listed by the DIR command being separated by linefeeds. The solution eluded me until I realized that I was in user area 10 (= ASCII linefeed) at the time. Fix it by not writing the first "character" of the file name. See procedure writefilename in file KDIR.PAS. Bug #3: The scourge of all machines using 16-bit signed integers. The displays of bytes (remaining to be) transferred wrap to negative integers above 32767. Since this number is calculated by multiplying blocks by 128 (an integer), you really only get 9 bits of information there. This can be remedied by multiplying by 128.0 (a real) and formatting the result. See procedure update in file KDISPLAY.PAS. See procedure open_file in file KOPEN.PAS. Enhancement #1: I got tired of having to tell the host explicitly the name of each file I was downloading when I should have been able to use wildcards. The impediment here is that Turbo Kermit goes to receive_init state when it gets the EOF packet, and expects a send_init packet from the host. Instead, it gets a file_header packet, and aborts. A two-line change allows Kermit to receive multiple files in this case. Find the repeat/case/until block that processes the incoming packets. Only one of the cases ever sets the state variable (to receive_init). Change it to receive_header, and add a clause to the until condition checking for state <> receive. See procedure rfile in file KREC1.PAS here [Ed. - Code omitted.] Enhancement #2: Especially in conjunction wtih Enchancement #1, I wanted to be able to see the name of the file being transferred along with all the other statistics being displayed. I stuck "gotoxy(58,2); write(fileref);" at the front of procedure open_file in file KOPEN.PAS. The above should be of general interest. What follows summarizes the other, more machine-specific changes that I needed to make. I undid the IOBYTE stuff so that I could support all 4 of the serial ports on my system. I have a 1200 bps autodialing modem and a dumb 2400 bps modem and I wanted to be able to autodial 2400 bps systems. I support searching through the various PAMS/PDSE/et.al. BBS lists and extracting the phone numbers. I rewrote pieces of the command processor to make it easier to add new commands while retaining the ability to abbreviate them to uniqueness, and I implemented meaningful semantics for commands like CONNECT 1 or RECEIVE FRED.PAS . I have a text capture mode, and if I desire the terminal handler converts ANSI escape sequences into H19 sequences for my console. ... The aim of Nuclear Freeze is to prevent Nuclear Winter. Jeff Woolsey ...ihnp4{!stolaf}!umn-cs!woolsey woolsey@umn-cs.csnet [Ed. - Thanks. I've put this message in full (with code) in KER:TURBO.BWR on CU20B, and have also passed it along to the Turbo Pascal Kermit authors.] ------------------------------ Date: Wed, 11 Dec 85 16:55:16 PST From: Samuel_Lam%UBC.MAILNET@MIT-MULTICS.ARPA Subject: Re: Apple-II Kermit Bugs >This may be related to the bug that strips out '&' on reception of files. This IS the bug that strips out '&' on reception regardless of the setting of text/binary and 7/8 bit data path. When it sees an '&' in the incoming data stream, it just unconditionally strips it and turns on the 8th bit of the next character. Sam Lam ------------------------------ End of Info-Kermit Digest ************************* ------- 24-Dec-85 14:12:09-EST,12480;000000000000 Mail-From: SY.FDC created at 24-Dec-85 14:11:39 Date: Tue 24 Dec 85 14:11:39-EST From: Frank da Cruz Subject: Info-Kermit Digest V3 #35 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12169720564.28.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Tue, 24 Dec 1985 Volume 3 : Number 35 Departments: MS-DOS KERMIT - Kermit 2.28 jrd Bug Report Fast Kermit for AT? IBM-PC Kermit v2.28 Display Problems Kermit for Victor MISCELLANY - Kermit for Apples with StarCard Request for KERMIT binary for Radio Shack 6000 Xenix Set File 8-Bit in Kermit-20 ---------------------------------------------------------------------- Date: 23 DEC 85 13:15-MST From: JRD@USU.BITNET Subject: Kermit 2.28 jrd Bug Report 1. Thanks for the mail messages and nice words. Using Bitnet here is magic of a rather dark hue, alas. Given that you seem to have a shortage of MS-DOS folks perhaps I can get the mail via Bitnet and help solve the sundry bugs as they arrive and then send responses to you for editing. 2. Bugs of various kinds in "MS Kermit 2.28 jrd" are discussed below. 3. Rare computer hangups when engaging IBM mode and then entering the Connect state. Peering at the interrupt level code in file MSXIBM shows several places of difficulty if the mainframe were to have sent a char before Kermit was ready to accept one. Some changes were made to hopefully avoid problems; all involve completing work before interrupts can interfere. The hangup problem seems to be like a corrupted segment register (ds?), which could happen I suppose if a char arrived during serial port initialization. Actually, I or someone needs to have a hard look at the code in SERINT to see if all UART conditions are properly serviced and if the 8259 interrupt controller chip is attended to in an manner consistent with both IBM PCs and ATs. ISRs are such fun! My quick changes are as follows. Procedure SERINI: - flush UART received character BEFORE turning on interrupts, - change allowable UART interrupting conditions to avoid interrupts on TX Holding Buffer Empty (a nonsense interrupt for us) but allow them on Data Available, RX Line Change, and Modem Change, - move push/pop es to allow quicker procedure exit, - replace call to proc Clrbuf with separate code since Clrbuf turns on interrupts within the body of SERINI (a likely culprit). Procedure SERRST: - move push/pop es to allow quicker procedure exit. Procedure SERINT: - send 8259 chip End-of-Interrupt signal as almost last item in the proc, - remove strange Enable Interrupts (sti) instruction within proc body; after all, we got here via an interrupt. 4. Data overrun when turning around line between IBM mainframe and IBM PC/AT. An obvious thing to do here is insert a small wait interval before sending a packet (sending filler chars could still upset the host during line turn around); this is usually called pacing. In terms of fast micros and sluggish mainframe terminal handlers, pacing seems to be one of the solutions. I added a 3 millisecond wait routine at the very beginning of procedure OUTPKT in file MSCOMM; it may not be enough, but the delay is easily adjusted. If it's too long then we will lose the time slice, if too short then mainframe loses the first part of a packet. 5. Files sent while in server mode do not use repeat prefixing. My goof due to misunderstanding the non-standard protocol of setting the prefix char. Two lines of code were added in procedure SERVER (in file MSSERV) to force the default prefix char into the active prefix after each server command. 6. Items not clearly explained in original read.me file for 2.28 jrd. -- GET allows both file names to be on the same line; ex. GET theirs mine. -- GET allows ? chars in filenames after the first char, but I forgot to invoke the # --> ? translation. I think earlier versions omitted this also. Similarly, I parse both file names on whitespace (can be fixed) which is probably painful for IBM users. 7. All these changes affect three files: MSXIBM, MSCOMM, and MSSERV. Below is the output of MSDOS utility FC on the new and original "2.28 jrd" files. The complete files, with extension of .NEW, are being sent as well. 8. Happy holidays. Joe [Ed. - Now that we have established network connection with Joe, we can send files back and forth rather quickly. There may well be a few more contributions from him in the coming weeks. I've put the new files in PS: on CU20B, in case anybody wants to check them out -- feedback solicited and appreciated!] ------------------------------ Date: Thu 19 Dec 85 16:51:47-PST From: Ed Pattermann Subject: Fast Kermit... Does anyone have a patch for MS-KERMIT that allows it to work with IBM AT's that have faster crystals installed, like a 18MHZ crystal? Kermit fails to work after installing the new crystal. [Ed. - Some of the changes mentioned in the previous message might go a long way towards helping here.] ------------------------------ Date: 19 Dec 85 16:39:48 PST (Thu) From: Mike Iglesias Subject: IBM-PC Kermit v2.28 Display Problems I've seen the display problems that Kathleen Connors has seen with the original v2.28 Kermit on both a IBM PC-I and a Compaq. It appears to only happen on the old motherboard PCs (we have only one of those here) and the Compaq (which must do something the same way that the PC-I does). It does not happen on the newer PCs (PC-II; 256k motherboard) or a Compaq 286, so I suspect it may have something to do with the ROM BIOS. Mike Iglesias University of California, Irvine ------------------------------ Date: 20 Dec 85 02:13:23 +0100 From: XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU (YD14@BR1.THDNET) Subject: Kermit for Victor? I'm using a Vicky with "BIOS Version 2.9 February 4,1984 for V9000" and MSDOS 2.11. I've tried to run the SIRIUS ASM available from KERMSRV at CUVMA but it doesn't work. The CONNECT corrupts a lot of keys (I'm using a German keyboard) and the RECEIVE doesn't work at 2400 baud. The generic MSDOS kermit is running up to 2400 baud. Has anyone a special kermit version for the Vicky (Victor 9000) PC? Thanks Reinhard Goeth (Techn. Univ. of Darmstadt/Fed. Rep. of Germany) P.S. I wish you a merry chrismas and a happy new year. ------------------------------ Date: Fri, 20-DEC-1985 08:53 MST From: Eric Zurcher Subject: KERMIT for Apples with StarCard I thought I'd pass along a few things that I've learned while trying to implement KERMIT on an Apple ][+ with a StarCard CP/M board. All of this may already be familiar to you, but I provide it to you on the chance that it may keep someone else from having to reinvent the wheel. "Official" versions of KERMIT exist for Apples using the SoftCard CP/M board, but I could not locate any for the StarCard. The SoftCard versions do not work, since the two CP/M boards use quite different approaches in gaining access to the Apple's ports. I have found that the "generic" CP/M KERMIT can be made to work quite well with the StarCard, but only after making a minor alteration in the BIOS of the operating system provided with the card. In its standard configuration, the BAT: device is identical to the CRT: device, both refering to the Apple's monitor and keyboard. However, changing a single byte in the BIOS will cause the BAT: device to refer to a serial card in slot 2 of the Apple, which is of course the sort of arrangement that generic KERMIT needs. The byte in question is located at an offset of 63H from the start of the JMP tables of the BIOS (that is, it can be easily located by adding 60H to the address pointed to by the JMP instruction at address 0). This address normally contains the value CC - changing it to C8 will result in the definition of the BAT: device being changed to slot 2 of the Apple. (I have not seen this "feature" documented anywhere, though I have not requested technical documentation from the manufacturers of the StarCard.) Once this change is made, generic KERMIT works quite well. I'm currently working (though not very hard) on the rather simple task of developing a KERMIT that will handle the task of modifying this byte, if necessary. At present, I get around the problem by booting the system with a disk that contains a version of the BIOS in which I have already modified the byte. I've also managed to combine a few features of the SoftCard KERMITs with the generic KERMIT, to allow VT52 emulation to work and to "tidy up" the display during file transfers. It works reasonably well. If you wish, I will send a version to you once I get everything working the way I'd like. There are a few caveats (aren't there always?): (1) an 80-column display enhancer is almost a necessity for reasonable terminal usage; the StarCard can try to produce a 70-column display using software, but this is too slow to keep up at even 1200 baud. (2) I have not thoroughly tested this, but I suspect that a DC Hayes MicroModem II will not work with this arrangement - the problem is that you can't dial a number. It does appear to be possible to first dial and establish the connection under Apple DOS, then reboot the machine to run CP/M. In any case, whatever serial interface is used must be in slot 2 of the Apple. (3) I have not tested this arrangement at speeds above 1200 baud, but I suspect that faster speeds will not work well. (4) Most of the VT52 emulation features work as they should, but the "home and clear screen" operation is a bit slow - at 1200 baud I usually lose the next dozen or so characters received after this operation. (5) It appears that data is restricted to 7-bit, and not 8-bit bytes. For transfer of non-ASCII files, parity should be set to space. I hope somebody, somewhere, finds some of this useful. In the long run, it would be preferable to have a KERMIT for this system which accesses the serial port a bit more directly, rather than through twiddling the IObyte, but I will leave that task to someone else. Regards, and Merry Christmas! Eric Zurcher Dept. of Biology Utah State University Logan, Utah 84322-5305 REHABIV@USU [Ed. - Thanks for the information; I've added your message to the APPLE.BWR file for the time being. USU seems to be a beehive of Kermit activity these days...] ------------------------------ Date: Sun, 22 Dec 85 11:41:56 EST From: Glenn Ricart Subject: Request for KERMIT binary for Radio Shack 6000 Xenix I'd like to run KERMIT under Xenix on a Radio Shack 6000 (previously known as the 16B before some magic happened). Unfortunately, this system does not have a C compiler so I can't start from the sources. Could someone contribute the binary? . . . . Thanks! ------------------------------ Date: Sun, 22 Dec 1985 13:29 MST From: Keith Petersen Subject: Set File 8-Bit in Kermit-20 Request for change in next update of Kermit-20: Because I do a lot of uploading to Simtel20 and frequently use SEND *.* to do it, I have my KERMIT.INI do SET FILE BINARY. No problem so far, as I can use ASCIFY later to fix the ascii files - meantime I can go away from the computer and let things transfer automatically (of course my Kermit-80 is set to default to SET FILE BINARY). Now the problem: When downloading from Simtel20, that INI is still in effect and I get garbage on ascii files sent to me. I need to be able to tell Kermit-20 to use SET FILE 8-BIT for sends from me to Simtel20, and SET FILE AUTO for sends from Simtel20 to me. Suggest it might be added as SET FILE SEND AUTO and SET FILE RECEIVE 8-BIT. --Keith [Ed. - Good idea, will probably be added to the next release.] ------------------------------ End of Info-Kermit Digest ************************* -------