11-Jul-83 17:52:27-EDT,5881;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; Mon 11 Jul 83 17:52:18-EDT Date: Mon 11 Jul 83 17:49:18-EDT From: Frank da Cruz Subject: KERMIT Available on the ARPANET To: INFO-IBMPC@USC-ISIB.ARPA, INFO-CPM@MIT-MC.ARPA, TOPS-20@SU-SCORE.ARPA cc: SY.FDC@CU20B, SY.DAPHNE@CU20B, OC.WBC3@CU20B, Chris@CUCS20, Hu@CUCS20, Eiben@DEC-MARLBORO.ARPA, CERRITOS@USC-ECL.ARPA, JS5A@CMCCTA, JO2F@CMCCTE KERMIT is a protocol for transferring files between computers of all sizes over ordinary asynchronous telecommunication lines using packets, checksums, and retransmission to promote data integrity. Microcomputer implementations of KERMIT (and some of the mainframe implementations) also provide terminal emulation. KERMIT is non-proprietary, thoroughly documented, well tested, and in wide use. The protocol and the original program implementations were developed at Columbia University and have been shared with many other institutions, some of which -- particularly Stevens Institue of Technology -- have made contributions of their own. * KERMIT Implementations KERMIT is presently available for the following systems: Machine Operating System Language ------- ---------------- -------- DECSYSTEM-20 TOPS-20 MACRO-20 DECsystem-10 TOPS-10 MACRO-10 VAX-11 VMS Bliss-32, Macro-32 IBM 370 Series VM/CMS IBM Assembler VAX,PDP-11,SUN,etc UNIX C PDP-11 RT-11 OMSI Pascal 8080, 8085, or Z80 CP/M ASM 8086, 8088 PC DOS, MS DOS IBM PC Macro Assembler Apple II 6502 Apple DOS DEC-10/20 CROSS All but the UNIX version and RT-11 versions use or imitate the TOPS-20 style of user interface - command keyword recognition and completion, ?-help, etc. The 8080 version runs on the DEC VT180, DEC Rainbow-100 (speeds up to 1800 baud only), DECmate II (CP/M), Heath/Zenith-89 and 100, Intertec Superbrain, Apple II with Z80 Softcard, TRS-80 II (CP/M), Osborne 1, Osborne Executive, Kaypro II, Vector Graphics, Ohio Scientific, Telcon Zorba, and others. The 8086 version runs on the IBM PC and lookalikes (such as the Compaq portable) and on the Heath/Zenith-100. * Distribution Policy The KERMIT software is free and available to all, sources and documentation included. Columbia University has been charging a reproduction fee of $100 for mailing tapes to recover its costs. Other sites are free to redistribute KERMIT on their own terms, and are encouraged to do so, with the following stipulations: KERMIT should not be sold for profit; credit should be given where it is due; and new material should be sent back to Columbia University so that we can maintain a definitive and comprehensive set of KERMIT implementations for further distribution. * Distribution Mechanisms: In addition to direct distribution from Columbia, KERMIT (all the versions listed above, as they existed in June 1983) has been placed on the DECUS VAX/VMS and RSX-11 SIG tapes, and may, at some point, be added to the DECUS library for DEC-10's and -20s, and also distributed through IBM SHARE. In addition, the KERMIT distribution is available at Columbia to users of BITNET on host CUVMA. * ARPAnet Distribution: Now KERMIT is available in its entirety to the ARPAnet community. An up-to- date KERMIT distribution area will be maintained on the Columbia University Computer Science Department DECSYSTEM-20, a new machine which as just been added to the ARPAnet. The KERMIT distribution can be found at ARPAnet host COLUMBIA-20 in the directory PS:, accessible via anonymous FTP. This is a large area, containing sources (and in some cases binaries or hex) of all implementations, plus documentation and various utility programs -- presently over 2000 DEC-20 pages in about 170 files -- so you probably don't want to take the whole area blindly. First, look at the short file 00README.TXT (starts with two zeros, always appears at the top of a directory listing), which explains what is where, and then take the parts that are of interest to you. The KERMIT area on COLUMBIA-20 should now be considered the definitive source for KERMIT on the ARPAnet; other areas where parts of the KERMIT distribution have been available will not necessarily remain current or complete. The major documentation for KERMIT is the KERMIT USERS GUIDE and the KERMIT PROTOCOL MANUAL, on line as USER.DOC and PROTO.DOC, respectively. The User's Guide gives an overview, general instructions for use, and details about the use and installation of each version, including procedures for initially downloading microcomputer versions from a mainframe host. The Protocol manual is supposed to describe the protocol in sufficient detail to allow new implementations of KERMIT to be written. KERMIT is an active project. Features are being added to existing implementations, bugs are fixed, new implementations are being developed. Towards the end of August (when I return from vacation), I'll set up a KERMIT mailing list for reporting bugs, trading information, announcing new versions, etc. In the meantime, send comments and inquiries to me at this ID, though I won't be able to answer for a while. * Disclaimer No warranty of the software nor of the accuracy of the documentation surrounding it is expressed or implied, and neither the authors nor Columbia University, nor any other contributor, acknowledge any liability resulting from program or documentation errors. - Frank da Cruz Manager of DEC Systems Columbia University Center for Computing Activities CC.FDC@COLUMBIA-20 ------- 11-Jul-83 18:27:14-EDT,4508;000000000001 Mail-From: CC.FDC created at 11-Jul-83 18:27:10 Date: Mon 11 Jul 83 18:27:10-EDT From: Frank da Cruz Subject: Kermit-80 vs binary files To: Cerritos@USC-ECL.ARPA, Eiben@DEC-MARLBORO.ARPA, PS1.SCOR@CU20B cc: CC.Daphne@COLUMBIA-20.ARPA, cc.fdc@COLUMBIA-20.ARPA, OC.WBC3@CU20B Several people have been asking (or complaining) about binary file transfer in KERMIT-80. The following comments attempt to explain it, and propose a possible improvement. Bill Catchings, the original author of Kermit-80, has explained to me how the EOF handling business works. There are really three cases, of which only two are actually accounted for in the code. CP/M determines the EOF in one of two ways -- for a text file, the EOF is at the first ^Z in the last block of the file; for a binary file the EOF is at the end of the last block, regardless of the contents of the last block. There is no way to tell a text file from a binary file, except perhaps by the filetype conventions. Applications that deal with text files -- the TYPE command, text editors, etc, use the ^Z convention, whereas applications that deal with binary files (like the CP/M mechanism to run a program) do not. KERMIT, however, must deal with both binary and text files. Since KERMIT cannot distinguish between the two, it relies on on the user to tell it. By default, it uses the ^Z convention, but if the user gives the SET CPM-CREATED-FILE command, it will not. So far, so good. But now the problem arises of what to do with incoming files. An original goal of KERMIT was to allow users of the DEC-20 to send all their DEC-20 files -- binary and text -- to the micro with a single wildcard SEND command, and to be able to send them back to the DEC-20 the same way. Since a binary file is likely to have a ^Z somewhere in the last block, we can't send it back as a CPM-CREATED-FILE. But it would also be wrong to send back the whole final block, because a CPM block boundary might not correspond the actual end of file on the foreign sytem. So a new convention was adopted by which KERMIT-80 fills out the last block of an incoming file with ^Z's, and then during normal sending, all ^Z's at the end of the last block are not sent on the assumption that they are the result of this padding. This allows a mixture of binary and text files to be received and sent back in wildcard transfers with no special action by the user. This scheme, however, prevents complete transmission of ANY file from the CP/M system that happens to have any number (1 to 127) ^Z's at the end of its final block. Normal transmission will discard them because they're at the END of the block, and CPM-CREATED-FILE transmission will discard them because they are IN the block. Thus, the file options should actually be: 1. TEXT (i.e. CP/M-created text) First ^Z in last block is EOF. This will apply whether the file is created by CP/M or from outside. 2. BLOCK (i.e. CP/M binary) Send all blocks in their entirety (can't do this now). 3. EXTERNAL Strip all trailing ^Z's in last block when sending (this is the current default). These all apply when SENDing files from the CP/M system. When receiving, the action is always the same -- pad the last block with ^Z's, unless the file happens to end on a block boundary, in which case the end is unambiguous and no ^Z's are needed. Explaining this to ordinary users would be pretty tough, but I think the present default works in most cases. It might be worth establishing some mechanism to allow the user to change the default, either by SET command or an assembly option, in case the user is dealing more commonly with CP/M files than with host files. It might even be worth considering having KERMIT-80 attempt the proper mode based on the file type (.COM would use BLOCK mode, .EXE would use EXTERNAL mode, anything else would use TEXT mode? -- sort of a Kermit-80 equivalent to Kermit-20's "auto-byte" mode of operation). This might be nicely meshed with an INQUIRE option for SEND, in which KERMIT-80 would prompt the user with the name of each file to send, let the user say whether to send or skip it, and then allow an opportunity to override the default file mode. Actually, this is such a good idea I might go ahead and put an INQUIRE feature into KERMIT-20... (remember the old /I option on PDP-11 PIP?) - Frank ------- 11-Jul-83 19:09:19-EDT,1519;000000000011 Mail-From: NOT-LOGGED-IN created at 11-Jul-83 19:09:11 Return-Path: Received: from rand-unix by COLUMBIA-20.ARPA with TCP; Mon 11 Jul 83 19:09:13-EDT Date: Monday, 11 Jul 1983 16:07-PDT To: Frank da Cruz Cc: guyton@rand-unix Subject: pc kermit & Unix kermit -- bugs! From: guyton@rand-unix Hi, I just spend many hours tracking down a few problems in using IBM-PC Kermit to talk w/Unix (4.1BSD). 1) The "twenex" version of Kermit.c does NOT work if compiled with "UNIX" defined. 2) The old "UX" version of unix kermit does not work with the IBM PC implementation. After some searching, I found the problem was that the unix code added a null at the end of the filename packet, and the PC rejected it. Once I commented out the line that added the null, everything worked again. I have a suspicion that the unix code assumes the presense of an ending null in the filename packet. I'll track it down further if nobody else has already. 3) The version of kermit.asm on isib:kermit.asm has heath/ansi style ins/del line added to the PC version. Just noticed that the columbia: seems to be older. If nobody else is already working on this, I am willing to ... a) Find out why the kermit.c program no longer works under Unix. b) Change the unix program (and/or kermit.c) to work without the trailing null at the end of filenames. -- Jim 11-Jul-83 19:33:38-EDT,1654;000000000001 Mail-From: CC.FDC created at 11-Jul-83 19:33:35 Date: Mon 11 Jul 83 19:33:35-EDT From: Frank da Cruz Subject: Yet one more problem with Kermit-80 To: Eiben@DEC-MARLBORO.ARPA cc: OC.WBC3@CU20B, CC.Daphne@COLUMBIA-20.ARPA, Cerritos@USC-ECL.ARPA, cc.fdc@COLUMBIA-20.ARPA, CU.HDE@CU20B We noticed this one today on the VT180... Bernie, since you converted VT180 to run "generically", it no longer handles ^S typed at the keyboard correctly. Diagnosis: in TELNET, the tight little CHRLUP (character loop) looks like this: chrlup: call prtchr ; Check port call conchr ; check console jmp kermit ; (if escape character was typed) jmp chrlup ; more... The problem is that when lots of characters are coming in the port, the PRTCHR routine hardly ever returns -- it has its own internal loop and doesn't return until a character-available test fails. First I thought switching the order of the calls in CHRLUP would raise the priority of console input enough to let ^S's, ^O's, etc, to get through (this trick worked on IBM PC Kermit), but no... So then I tried making PRTCHR just return (RET) instead of looping back on itself -- I figured this might slow things down a bit, but it should have worked. It didn't -- I couldn't even make the program transmit the first character. I'll fool with it some more, maybe I made a dumb mistake... But in case I don't get back to you about this, add it to the list of things to be fixed in KERMIT-80. (By the way, the reason this was never a problem before, of course, was that VT180 Kermit was totally interrupt driven...) - Frank ------- 11-Jul-83 19:44:38-EDT,1631;000000000001 Mail-From: CC.FDC created at 11-Jul-83 19:44:37 Date: Mon 11 Jul 83 19:44:37-EDT From: Frank da Cruz Subject: Re: pc kermit & Unix kermit -- bugs! To: guyton@RAND-UNIX.ARPA cc: cc.fdc@COLUMBIA-20.ARPA In-Reply-To: Message from "guyton@rand-unix" of Mon 11 Jul 83 19:09:19-EDT Thanks for the report! The file KERMIT.C is the result of my taking the version that's being run by our CS department (which is in the Kermit distribution as UX*.*, a collection of files), combined all into one file, fixed several bugs (possibly including the null at the end of the filename?), added lots of comments (in violation of the spirit of UNIX), and rewrote the rpack routine, which was so deeply nested in the original that it broke the PCC compiler on our DEC-20. I also conditionalized it, and tested it on our -20 with the TOPS-20 conditional on, and it worked OK. Our CS folks then tested it on their VAX UNIX systems and it didn't work, but they never had a chance to figure out why, and continue to use their old versions. They, and I, would be grateful if you could make KERMIT.C work under UNIX, so we could flush the UX*.* source once and for all, and then begin adding in other parts of the protocol (like error packets, server mode, etc) to the new common source. - Frank P.S. I just took a look, and sure enough I left a "len++;" in sfile under the UNIX conditional in case UNIX needed that for something -- someone must have added it for some reason! UNIX-to-UNIX transfers? Anyway, that's the source of the extraneous character at the end of the filename... ------- 12-Jul-83 18:08:14-EDT,5648;000000000001 Mail-From: CC.FDC created at 12-Jul-83 18:08:12 Date: Tue 12 Jul 83 18:08:12-EDT From: Frank da Cruz Subject: Kermit-80 problems To: Eiben@DEC-MARLBORO.ARPA, OC.WBC3@CU20B cc: Cerritos@USC-ECL.ARPA, CC.Daphne@COLUMBIA-20.ARPA, OC.SITGO@CU20B, cc.fdc@COLUMBIA-20.ARPA As I prepare to leave for a month on vacation, I leave behind this list of problems with Kermit-80, in hopes that someone might fix them before I get back... I probably didn't think of all the problems that people have mentioned to me in past months, but if all these were fixed, we'd have a pretty good program. I anyone knows of problems I forgot, please add them to the list... - Frank --------- Problems with KERMIT-80. 1. Two separate sources: CPMKERMIT.ASM (old, pre-generic) CPMGENERI.ASM (incorporates Bernie's generic support, CP/M 3.0 support) The old one is kept around because a. At least one implementation -- Osborne 1 -- doesn't work when built from the new one. b. Many others have never been tested. c. VT180 interrupt-driven support has better terminal emulation than the "generic" VT180 support in the new version. These problems need fixing. The ARPAnet connection might get some of the previously untested versions tested. The author of the Osborne support (Chuck Bacon at NIH) is looking to see why the Osborne support is busted & will try to fix it. 2. Mentioned above: VT180 terminal emulation doesn't sample the keyboard often enough, so when a lot of text is coming in from the host, ^S, ^O, etc, don't get through, and in fact, they mess things up a lot. Oddly enough, the exact same code works ok on the Rainbow, probably because the tight loop inside PRTCHR fails to find a character more often because of the slow speed of the Rainbow due to Z80/8088 handshaking. 3. The incredibly ugly IF...ENDIF structure of the program makes it almost impossible to read. Bernie has long planned to reorganize it a la MODEM to make a kind of system-independent core, to which a custom template can be filled out and appended for each system/terminal/etc. Doing this is one thing, documenting it so any CP/M user can construct a working Kermit-80 for a new machine is yet another, and testing the result on all the previously supported machines still another! (so much for the major problems, now some "minor" issues) 4. Local echo doesn't work in 3.2, at least not in certain implementations. 5. Cursor positioning is screwed up in some implementations -- various users have complained that the "Kermit-80>" prompt after a file transfer overwrites the filename line. 6. Lower case letters in an incoming file header should be raised to upper case -- ever tried getting a file from UNIX and then referring to it? Also, any nulls in the filename should be discarded (UNIX kermit sometimes sticks a null at the end for some reason). 7. A nak for the next packet is NOT an ack for the current one if the current one was a Send-Init. 8. Check for packet number wrap-around when checking for things like "is this a nak for the previous packet?" when comparing packet numbers. 9. May want to verify other side's Send-Init parameters more rigorously and force them to legal values if illegal. I recently added this to Kermit-20; before I did, it wouldn't talk to the Apple, which was sending garbage in certain fields. 10. Junk in command buffer after a file transfer (or is it just an unsuccessful file transfer?) always prevents the first command after the transfer from being parsed. 11. It's presently impossible for Kermit-80 to send ANY file that ends with a string of one or more ^Z's (right-adjusted on the end of the last block). Need to be able to specify TEXT files (EOF is at first ^Z in last block), BLOCK files (send all blocks, ignore any ^Zs), EXTERNAL files (the kind that KERMIT-80 creates, with the last block padded out with ^Zs). Perhaps add the equivalent of "auto-byte", with .COM files being sent in BLOCK mode, .EXE files in EXTERNAL mode, all others in TEXT mode? Combined with an INQUIRE feature, to ask about each file in a wildcard send? 12. File stepping is limited to something like 16 files, because the only way Bill could figure out how to do it was to chain all the FCB's together in memory beforehand, and he left space for 16 FCB's. Better to figure out how to step through files dynamically, or else make the FCB area bigger. See what any of the various public domain directory-listing programs (or MODEM) do. 13. Probably all versions should allow ^C as a synonyn for C when closing a telnet connection. 14. KERMIT-80 (and all the other micro versions) badly need to be able to send a BREAK signal. You need it to talk to IBM systems, and to get the attention of various kinds of port switchers, multiplexers, etc. 15. Fix logging function. Most implementations don't have it; those that do lose characters. Log to a big area in memory; when buffer gets nearly full, send ^S, dump it to disk, send ^Q. Again, look at MODEM, see what it does. 16. Retry count still isn't updated in every case. ------------ Once all these problems are fixed, or most of them, we can begin adding enhancements (printer support, init files, etc) and new protocol features (8th-bit-quoting, fancier checksums, more interactions with server, asynchronous events during file transfer, etc). Naturally, if any one of you feels like tackling any of this, please coordinate with the others. Have fun while I'm gone! - Frank ------- 12-Jul-83 18:55:00-EDT,3333;000000000011 Mail-From: NOT-LOGGED-IN created at 12-Jul-83 18:54:47 Return-Path: Received: from SRI-KL.ARPA by COLUMBIA-20.ARPA with TCP; Tue 12 Jul 83 18:54:49-EDT Date: Tue 12 Jul 83 15:48:00-PDT From: HEINZE@SRI-KL.ARPA Subject: KERMIT INFO To: CC.FDC@COLUMBIA-20.ARPA cc: HEINZE@SRI-KL.ARPA Frank, I read your KERMIT message with great interest, though of course I have a few hundred questions to ask you about it. My fingers will never last, so I'll hit the high points. First, I'm HEINZE@SRI-KL on the ARPANET for return mail. We are currently writing the code right now (as I speak or type, so to say) to design and implement a microcomputer network of about 200 Commodore 64 microcomputers. It's a very ambitious project but we have some of the most capable people in the Silicon Valley area working on it. I have talked to Robert Maas at MIT and he was of no help in our effort. He had some incipient code that "never did work for us", so rather than pursue that route we went else where. To the best of my knowledge the only good working network available for Commodore microcomputers was writeen by Steve Punter in Ontario Canada and presently being marketed by TPUG. I have written a letter to Punter asking all the obvious questions. I should have written the letter on the net so you could read it that would have saved me a lot of time. I won't reproduce the letter hear but try to hit some highlights. I asked Steve all the basic implementation questions. What hardware configuration is needed? Does your "Appple Kermit" run on a 16K Apple? I would doubt that it would, how much memory does it take? We will have to re-code the Apple code to run on a Commodore 64 micro, any info you have on modify KERMIT code would be helpful. How much memory does KERMIT require? Is there a Microsoft Basic version of KERMIT which will run on the original PET computers? If so, what DOS and ROM version (as every good Commodore owner knows, there's only a hundread or so implementations of CBM computers!!) As you can see, I need a lot more info on KERMIT before I can even decide what, how or whether it really does anything that we are interested in. I'm supposed to be getting a complete listing of the KERMIT info from BILLW @ SRI-KL today. I will need to look at the KERMIT USERS GUIDE, etc to get additional info. I don't completely understand your $100 tape fee, seems outrageously excessive to me. After we get our network up and operating I will try to remember to pass the phone number and info on to you so that you can access the network. We have an extremely hard working group on this project (totally unrelated to SRI) and I feel sure that we will be successful in the long run. Our society is SPHINX SOCIETY Inc. (415) 527-9286. POC is Bill MacCracken, or my self, Rich Heinze (415) 325-0127 in Menlo Park. MacCracken is the current monitor for SPHINX and is very knowledgeable about CBM computers. We have several people up and running on-line with 300 baud modems but our network is just being designed and the code is being written now. Our immediate goal is to get SPHINX up and on-line ASAP and I sincerely hope that this will happen prior to Sept 1983. More later, Rich ------- 12-Jul-83 19:35:18-EDT,1331;000000000001 Mail-From: CC.FDC created at 12-Jul-83 19:35:17 Date: Tue 12 Jul 83 19:35:17-EDT From: Frank da Cruz Subject: Re: KERMIT INFO To: HEINZE@SRI-KL.ARPA In-Reply-To: Message from "HEINZE@SRI-KL.ARPA" of Tue 12 Jul 83 18:55:00-EDT Kermit is not a network -- it's comparable to MODEM, except it works on a wider variety of computers, mainframes included. No special hardware is required, beyond RS232 serial interface. The Apple code comes from Stevens Institute of Technology. It's written in CROSS language on the -10 or -20 and downloaded. I have no idea how much memory is required to run it; they didn't mention anything about that in their documentation. You can call Nick Bush at Stevens and discuss it with him; I'm sure he wouldn't mind. The number is 201-420-5457 (New Jersey). You wouldn't think the $100 fee was outrageous if you had just produced over 300 tapes, packed them up, licked the stamps & labels, paid the postage (including first class postage to places like Sweden, Australia, Chile). We couldn't afford the beating any more, not to mention the way our systems programmers were being turned into highly paid shipping clerks. Now we can afford to hire operators & clerks to do the tape sending and let us get on with the development. - Frank ------- 13-Jul-83 13:47:24-EDT,1110;000000000001 Mail-From: CC.FDC created at 13-Jul-83 13:47:21 Date: Wed 13 Jul 83 13:47:21-EDT From: Frank da Cruz Subject: Kermit distribution mailing list To: Info-Kermit@COLUMBIA-20.ARPA There is now an INFO-KERMIT mailing list at CUCS20. If you have received this message, you're on it, and it works. This list should be for people who maintain or install KERMIT at their site, or who are interested in discussing it. For now, I'm limiting to CCNET members, but when I get back from vacation and can manage it better, I'll expand it to include the ARPANET as well. Here's the contents of the list, which is in the file CUCS20::INFO-KERMIT.DISTRIBUTION: CC.FDC@CUCS20, CC.Daphne@CUCS20, US00@CMCCTF, JS5A@CMCCTA, JO2F@CMCCTF, - CCIMS.Beecher@CUTC20, OC.WBC3@CU20B, Gumpf@CWR20B, DK32@CMCCTF, GM0W@CMCCTF, - OC.SITGO@CU20B, OC.Garland@CU20B If you want to be taken off, or if you know anyone else who wants to be added, let me know. Anyone on CCNET can send mail to everyone on this list simply by sending a message to INFO-KERMIT@CUCS20. - Frank ------- 13-Jul-83 13:58:35-EDT,677;000000000001 Mail-From: CC.FDC created at 13-Jul-83 13:58:32 Date: Wed 13 Jul 83 13:58:32-EDT From: Frank da Cruz Subject: Rainbow Kermit To: Eiben@DEC-MARLBORO.ARPA cc: cc.fdc@COLUMBIA-20.ARPA, OC.WBC3@CU20B I have a user with a Rainbow who has some kind of direct-connect modem, which Kermit won't work with. It appears to insist on having pin 20 (DTR) high. The terminal firmware keeps DTR high, and so does Poly-XFR. But Kermit does not. I advised the user to wire pin 20 to pin 5 or some other pin that is normally high. Meanwhile, there's nothing we can do, because there's no way to talk to the UART, right? Oh well... - Frank ------- 14-Jul-83 01:48:12-EDT,865;000000000011 Return-Path: Received: from rand-unix by COLUMBIA-20.ARPA with TCP; Thu 14 Jul 83 01:48:08-EDT Date: Wednesday, 13 Jul 1983 21:38-PDT To: Frank da Cruz Cc: guyton@rand-unix Subject: Re: kermit.c From: guyton@rand-unix Ok, I have kermit.c working again under Unix. Got it working under 4.1bsd and just tested it on our V7 system. The major problem was the ioctl's were just wrong. Along with a couple other minor bugs that I fixed while I was at it (defaults to non-image mode now for Unix, since there is a command line option to go to image mode, yet none for the opposite effect). The next msg to you will be the source. Let me know if you don't get all of it (it is getting pretty long). -- Jim p.s. I'll send an annotated diff listing when I get back to work and a 9600 baud connection! 14-Jul-83 10:06:08-EDT,845;000000000011 Return-Path: Received: from PARC-MAXC.ARPA by COLUMBIA-20.ARPA with TCP; Thu 14 Jul 83 10:06:04-EDT Date: Thu, 14 Jul 83 07:05 PDT From: fisher.pasa@PARC-MAXC.ARPA Subject: Re: KERMIT Available on the ARPANET In-reply-to: "cc.fdc@COLUMBIA-20.ARPA's message of Mon, 11 Jul 83 17:49:18 EDT" To: Frank da Cruz Frank, I was interested in any compatibility between KERMIT's protocol and Ward Christensen's MODEM protocol for file transfer. Do they have the same protocol? Can KERMIT on the VM/CMS system talk to a MODEM program? I have a Dolphin workstation that I would like to have talk to the IBM system running VM/CMS. One approach would be to have the workstation use the KERMIT protocol and get the IBM KERMIT system. Any thoughts would be appreciated. Pete 14-Jul-83 13:10:22-EDT,1226;000000000001 Mail-From: CC.FDC created at 14-Jul-83 13:10:21 Date: Thu 14 Jul 83 13:10:21-EDT From: Frank da Cruz Subject: Re: KERMIT Available on the ARPANET To: fisher.pasa@PARC-MAXC.ARPA cc: cc.fdc@COLUMBIA-20.ARPA In-Reply-To: Message from "fisher.pasa@PARC-MAXC.ARPA" of Thu 14 Jul 83 10:06:08-EDT No, MODEM and KERMIT are not compatible -- KERMIT was developed in ignorance of MODEM, but we've learned about it since. One of the shortcomings of MODEM is that it could never communication with an IBM mainframe because it sends binary data bare; any binary data that happens to be a CR, LF, DEL, NUL, ^S, ^Q, etc, would be swallowed by the communcation hardware and the application on the IBM system would never see those characters -- the data would be lost and the checksum would be wrong (or in the wrong place, which amounts to the same thing). KERMIT, on the other hand, sends control characters by prefixing them & then translating to printable equivalents, and works fine on every system we've brought it up on. If you need any more information, you can dig through the manuals, or else wait a month until I get back from vacation; I'll be glad to help then. - Frank ------- 14-Jul-83 13:32:10-EDT,335;000000000001 Return-Path: Received: from CU20B by CUCS20 with DECnet; Thu 14 Jul 83 13:32:07-EDT Date: Thu 14 Jul 83 13:32:51-EDT From: Frank da Cruz Subject: Archive To: Info-Kermit@CUCS20 This is just to test if mail to Info-Kermit gets archived correctly in CUCS20::PS:MAIL.TXT. - Frank ------- 14-Jul-83 14:11:27-EDT,870;000000000001 Mail-From: CC.FDC created at 14-Jul-83 14:11:19 Date: Thu 14 Jul 83 14:11:19-EDT From: Frank da Cruz Subject: UNIX Kermit To: Gillmann@USC-ISIB.ARPA In [COLUMBIA-20]PS:KERMIT.C, you'll find a version of UNIX Kermit that has fixes from Jim Guyton at Rand-UNIX. He says it works fine under 4.1bsd and V7, but we haven't tested it here yet; I send this off now because I'm going on vacation for a month, will be back Aug 15. While I'm gone, you might find that new versions of PC Kermit appear in the same directory from time to time. The contact for PC Kermit is CC.DAPHNE@COLUMBIA-20 (Daphne Tzoar); I'll ask her to keep you informed about new developments. After I get back, I'll probably set up an INFO-KERMIT mailing list; the announcement of a couple days ago has already brought in a lot mail. - Frank ------- 19-Jul-83 11:08:47-EDT,868;000000000005 Mail-From: CATTANI created at 19-Jul-83 11:08:41 Date: Tue 19 Jul 83 11:08:41-EDT From: Bob Cattani Subject: Re: Kermit for Vax To: guyton@RAND-UNIX.ARPA cc: cc.fdc@COLUMBIA-20.ARPA, CATTANI@COLUMBIA-20.ARPA In-Reply-To: Message from "guyton@rand-unix" of Mon 18 Jul 83 17:48:59-EDT Wonderful! I just tried it and everything worked fine. Let's consider this our current "standard" UNIX-C version of Kermit. You included a good point in one of your suggestions for improvements. It may be very useful to be able to specify a destination filename or directory name (compatible with the remote system) where the remote kermit is to put the files it receives. Of course, there are a whole set of related issues concerning what should be done about illegal characters in filenames - aren't networks terrible? -Bob ------- 19-Jul-83 22:07:06-EDT,2656;000000000015 Return-Path: Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Tue 19 Jul 83 22:06:59-EDT Date: 19 Jul 1983 1720-PDT From: Bruce Tanner Subject: Re: Kermit-80 problems To: cc.fdc@COLUMBIA-20, EIBEN@DEC-MARLBORO In-Reply-To: Your message of 12-Jul-83 1512-PDT Two fixes: Local echo was broken due to the BDOS trashing reg E in most generic Kermits. Put a push d/pop d around the "call prtout" at conchr + 12 lines. Kermit-80 gets confused when sending files that are a multiple of 128 records. The getfil routine will set filerc to zero in this case, but inbuf expects filerc to be always positive. Here's a filcom of the fix: 2)25 sta filerc ; Save as the file record count. 2) lda fcb+22H ; Get R1. 2) rlc ; Shift over one bit. 2) ora b ; Or in the high order from R0. 2) sta fileex ; Save it as the file extent. **** @gtnfl3 + .5 1)25 mvi c,0 ; [BT] assume no correction 1) jnz gtnfl4 ; [BT] positive record count 1) mvi a,80H ; [BT] make record count 128 1) mvi c,1 ; [BT] account for new record count 1) gtnfl4: sta filerc ; Save as the file record count. 1) lda fcb+22H ; Get R1. 1) rlc ; Shift over one bit. 1) ora b ; Or in the high order from R0. 1) sub c ; [BT] correction if file is multiple of 128 records 1) sta fileex ; Save it as the file extent. ***************************************************************************** This is an alternate fix. I haven't tested it. ***************************************************************************** 1)24 sui 1 ; Decrement it. 1) sta filerc 1) jnz rskp ; If not the last packet then retskp. 1) lda fileex ; Any more left? 1) cpi 0 1) jz inbuf3 1) sui 1 1) sta fileex 1) mvi a,80H ; Get a 128. 1) sta filerc ; Start the record count over. 1) jmp rskp 1) inbuf3: mvi a,0FFH 1) sta eoflag ; Set the EOF flag. 1) jmp rskp **** @inbuf2 + 8.5 2)24 ora a ; [BT] test for zero 2) jz inbuf4 ; [BT] yes, skip 2) sui 1 ; Decrement it. 2) sta filerc 2) jnz rskp ; If not the last packet then retskp. 2) jmp inbuf5 2) inbuf4: push b ; [BT] save BC 2) mvi b,7FH ; [BT] account for buffer already read 2) jmp inbuf6 2) inbuf5: push b ; [BT] save BC 2) mvi b,80H ; [BT] reset record count to 128 2) inbuf6: lda fileex ; Any more left? 2) cpi 0 2) jz inbuf3 2) sui 1 2) sta fileex 2) mov a,b ; [BT] get record count 2) sta filerc ; Start the record count over. 2) jmp rskp 2) inbuf3: mvi a,0FFH 2) sta eoflag ; Set the EOF flag. 2) pop b ; [BT] restore BC 2) jmp rskp -Bruce ------- 21-Jul-83 18:36:20-EDT,7676;000000000005 Return-Path: Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Thu 21 Jul 83 18:36:05-EDT Date: 21 Jul 1983 1531-PDT From: Bruce Tanner Subject: MAC80 6A To: EIBEN@DEC-MARLBORO, CC.FDC@COLUMBIA-20 In-Reply-To: Your message of 21-Jul-83 0609-PDT Is that all you want? Relational operators in expressions and ? @ in symbols are in the folling .cor files. Other changes: $ is now non-significant in symbols (this is what MAC does) local symbols are now ??nn instead of L$$nn (like MAC) macro handling is fixed up a bit. These (and probably future) .cor files are based of MAC80 version 6, so keep it around as a base until the next major release. Is the VT180 BIOS on the tape? I just got it today. It's terrific! MACLIB reading is a good possibility, I think making a .SYM file is a good idea. Should it be a seperate switch, made when a listing is made or made always? Z80 mnemonics are something I've kinda kept away from; I learned 8080 code when there was no Z80. Oh well, it's not out of the question, merely a matter of time and effort and a few compatability problems with the way it works now. Keep thinking of things. What about removong the restriction of : after labels? How about a REPT statement? IRP and friends? -Bruce ;********** M80UNV.COR ************* REP 29/1 M80MAJ==6 M80MIN==0 M80EDT==67 ;MACRO TO DO TITLE AND VERSION NUMBER DEFINE .TITLE (NAME,V,E)< TITLE NAME 8085 Cross Assembler - V(E) IFIDN ,< LOC .JBVER BYTE (3)M80WHO (9)M80MAJ (6)M80MIN (18)M80EDT RELOC> > WIT M80VER==6 M80MIN==1 M80EDT==70 SUM 217297 ;*********** MAC80.COR ************** REP 9/1 SEARCH M80UNV,JOBDAT .TITLE (MAC80,\M80MAJ,\M80EDT) WIT SEARCH M80UNV,JOBDAT,MACTEN TITLE. (M80,MAC80,8085 Cross Assembler) M80TTL M80137 SUM 120325 ;*********** MAC80A.COR ************* REP 8/1 SEARCH M80UNV .TITLE (MAC80A,\M80MAJ,\M80EDT) WIT SEARCH M80UNV,MACTEN TITLE. (M80,MAC80A,8085 Cross Assembler) M80TTL M80PTX REP 6/4 PUSH T4,["$"] ;FLAG TOP OF STACK WIT PUSH T4,[DOLLAR] ;FLAG TOP OF STACK INS 17/4 CAIE I,"<" ;SPECIAL CASE TEST FOR <=,>=,<> CAIN I,">" PUSHJ P,OP2CH ;CHECK FOR 2 CHAR OPCODE REP 42/4 DODT20: CAMN TOK,[SIXBIT/NOT/] ;THE OTHER UNARY OPERATOR? JRST DODT23 ;YES CAME TOK,[SIXBIT/HIGH/] CAMN TOK,[SIXBIT/LOW/] WIT DODT20: CAME TOK,[SIXBIT/NOT/] ;THE OTHER UNARY OPERATOR? CAMN TOK,[SIXBIT/HIGH/] JRST DODT23 ;YES CAME TOK,[SIXBIT/LOW/] CAMN TOK,[SIXBIT/LO/] REP 5/5 CAIN I,"$" ;NO LAST OP? WIT CAIN I,DOLLAR ;NO LAST OP? REP 10/5 CAIN I,"$" ;NOT THERE? WIT CAIN I,DOLLAR ;NOT THERE? REP 11/6 CAIN I,"$" ;ALL DONE? WIT CAIN I,DOLLAR ;ALL DONE? DEL 19/6 INS 51/6 OP2CH: PUSH P,T1 PUSH P,T2 MOVE T1,I ;SAVE I MOVE T2,I SUBI T2,40 ;SIXBIT LSH T2,^D30 ;SHIFT TO 1ST BYTE PUSHJ P,SNEAK ;LOOK AT THE NEXT CHARACTER SKIPE TOK ;NON-BREAK? JRST OLDI ;YES, NOT A 2 CHAR OPCODE MOVE I,SNEAKI ;GET THE BREAK CHAR SUBI I,40 ;SIXBIT DPB I,[POINT 6,T2,11] CAIE I,'>' CAIN I,'=' ;GOOD 2ND CHAR? PUSHJ P,INCH ;YES, USE IT NEWI: SKIPA I,T2 OLDI: MOVE I,T1 ;RESTORE I POP P,T2 POP P,T1 POPJ P, REP 8/7 E "&",,4 E "!",,5 E "_",,2 E "#",,1 E 'AND ',,4 E 'OR ',,5 E 'MOD ',,2 E 'XOR ',,5 WIT E "&",,5 E "!",,6 E "_",,2 E "#",,1 E 'AND ',,5 E 'OR ',,6 E 'MOD ',,2 E 'XOR ',,6 REP 19/7 E 'HIGH ', E 'LOW ', WIT E 'HIGH ',,7 E 'LOW ',,7 E 'LO ',,7 E 'EQ ',,4 E "=",,4 E 'NE ',,4 E '<> ',,4 E 'LT ',,4 E "<",,4 E 'GT ',,4 E ">",,4 E 'GE ',,4 E ,,4 E 'LE ',,4 E ,,4 INS 16/9 RELEQ: CAME OP,T1 FALSE: TDZA OP,OP ;0 = FALSE TRUE: SETO OP, ;-1 = TRUE POPJ P, RELNE: CAMN OP,T1 JRST FALSE JRST TRUE RELLT: CAML OP,T1 JRST FALSE JRST TRUE RELLE: CAMLE OP,T1 JRST FALSE JRST TRUE RELGT: CAMG OP,T1 JRST FALSE JRST TRUE RELGE: CAMGE OP,T1 JRST FALSE JRST TRUE REP 20/9 PUSH T4,["$"] ;DON'T PLOW THROUGH UPPER LEVEL STUFF WIT PUSH T4,[DOLLAR] ;DON'T PLOW THROUGH UPPER LEVEL STUFF INS 15/10 ;REMOVE THE NEXT 2 LINES FOR $ TO BE A SIGNIFICANT LABEL CHARACTER CAIN I,DOLLAR ;IS IT A DOLLAR? JRST TOKENL ;YES, THEY ARE NOISE CHARACTERS REP 40/10 CAIN I,"$" ;$ IS NOW A LEGAL SYMBOL CHARACTER WIT CAIE I,"@" ;@ CAIN I,"?" ;AND ? ARE LEGAL JRST SCPOPJ CAIN I,DOLLAR ;$ IS NOW A LEGAL SYMBOL CHARACTER REP 13/18 MOVE T4,T2 ;SAVE POINTER FOR END OF MACRO PUSHJ P,SNEAK ;TAKE A SNEAKY LOOK AT THE NEXT TOKEN CAMN TOK,[SIXBIT/ENDM/];END OF MACRO? JRST DOMAC5 ;YES JRST DOMAC7 ;NO, SEE IF A DUMMY ARG WIT JRST DOMC2A ;CHECK FOR ENDM, ETC. REP 26/18 MOVEI I,177 IDPB I,T4 MOVEI I,1 ;177,1 IS END OF MACRO IDPB I,T4 SETZ I, IDPB I,T4 ;END WITH NULL AOJ T4, ;POINT TO 1ST FREE WORD HRRM T4,.JBFF## ;UPDATE JOBFF WIT LDB I,T2 ;GET LAST CHAR OF MACRO CAIN I,12 ;END WITH LF? JRST DOMC5A ;YES, SKIP MOVEI I,15 IDPB I,T2 MOVEI I,12 ;END MACRO TEXT WITH CRLF IDPB I,T2 DOMC5A: MOVEI I,177 IDPB I,T2 MOVEI I,1 ;177,1 IS END OF MACRO IDPB I,T2 SETZ I, IDPB I,T2 ;END WITH NULL AOJ T2, ;POINT TO 1ST FREE WORD HRRM T2,.JBFF## ;UPDATE JOBFF REP 44/18 PUSHJ P,SNEAK ;LOOK AT NEXT TOKEN DOMAC7: JUMPE TOK,DOMAC1 ;NOTHING THERE WIT DOMC2A: PUSHJ P,SNEAK ;LOOK AT NEXT TOKEN DOMAC7: JUMPE TOK,DOMAC1 ;NOTHING THERE CAMN TOK,[SIXBIT/ENDM/];END OF MACRO? JRST DOMAC5 ;YES INS 32/25 MOVEM I,SNEAKI ;SAVE THE BREAK CHARACTER REP 38/25 CAIL T2,ENDHGH ;POINTS TO BAKBUF?? (IF SO, DON'T SAVE) WIT CAIG T2,BAKPTR CAIGE T2,BAKBUF ;POINTS TO BAKBUF?? (IF SO, DON'T SAVE) REP 41/28 MOVEI I,"L" ;START THE SYMBOL WITH "L$$" DPB I,INVECT MOVEI I,"$" IDPB I,INVECT WIT MOVEI I,"?" ;START THE SYMBOL WITH "??" DPB I,INVECT REP 4/32 MOVEI T1,"$" ;FLAG NON-INTEL RECORD WIT MOVEI T1,DOLLAR ;FLAG NON-INTEL RECORD REP 27/33 TYPE02: MOVEI T1,"$" ;TYPE 2 OR 3 LEADER WIT TYPE02: MOVEI T1,DOLLAR ;TYPE 2 OR 3 LEADER REP 9/39 PRTS: SETZB T1,T2 WIT PRTS: HRLOI T1,377777 ;+INFINITY REP 20/39 JUMPE T1,PRTX ;DONE WIT CAMN T1,[377777,,-1] ;NO SYMBOLS SMALLER THAN +INFINITY? JRST PRTX ;DONE REP 27/41 CAMG T1,(S) ;GET SYMBOL JRST PRT11 WIT CAMG T1,(S) ;GET SYMBOL THAT IS SMALLER JRST PRT11 ;(YES, WE ARE ONLY SORTING ON THE FIRST 6 CHARACTERS) REP 19/45 MOVEI T2,M80MAJ WIT MOVEI T2,M80VER REP 32/48 CAIG T1,ENDHGH ;CAME FROM BAKBUF? JRST DOLIN1 ;YES, THAT'S NOT A MACRO MOVEI T1,"M" ;FLAG AS A MACRO EXPANSION LINE PUSHJ P,LOUCH WIT CAIG T1,BAKPTR CAIGE T1,BAKBUF ;CAME FROM BAKBUF? JRST [MOVEI T1,"M" ;NO, FLAG AS A MACRO EXPANSION LINE PUSHJ P,LOUCH JRST DOLIN1] INS 23/52 SNEAKI: 0 ;CONTENTS OF REG I WHEN DONE SNEAKING TOKEN SUM 131614 ------- 16-Aug-83 14:01:15-EDT,1051;000000000011 Return-Path: Received: from FORD-WDL1.ARPA by COLUMBIA-20.ARPA with TCP; Tue 16 Aug 83 14:01:03-EDT Return-Path:<> Date: 15-Aug-83 20:54:51-PDT From: wunder@FORD-WDL1.ARPA Subject: INFO-KERMIT and Kermit-Unix To: cc.fdc@COLUMBIA-20.ARPA I noticed some files in PS: that referred to INFO-KERMIT. If there is such a beast, I'd like to join up. I've been working with Kermit-Unix (Columbia), trying to de-Berklify the code. It now runs on v6/PWB, Onyx v7, and Onyx System III, in addition to bsd 4.1 (all through ifdef's). I'll move it to System V, but that will require a little rework in the ioctl's. I sped it up a bit, and added several fixes from Jim Guyton (guyton@rand-unix). As soon as a friend does a little beta test work with Kermit-PC, I'll be glad to send it over. I've also got a fairly complete Unix man page. We sort of require that for public software on our system. walter underwood UUCP: fortune!wdl1!wunder ARPA: wunder@FORD-WDL1 Phone: (415) 852-4206, 852-4769 16-Aug-83 20:02:24-EDT,3792;000000000001 Mail-From: CC.FDC created at 16-Aug-83 20:02:08 Date: Tue 16 Aug 83 20:02:08-EDT From: Frank da Cruz Subject: INFO-KERMIT mailing list available To: Info-Kermit@COLUMBIA-20.ARPA Hi. I'm just back from a month's vacation and am gearing up to start maintaining the INFO-KERMIT mailing list, as promised. If you have received this message, then the mechanism works, and you have either asked to be put on the list or have expressed some interest in maintaining KERMIT. The list is intended for people who maintain or install KERMIT at their sites, or who are (thinking about) working on a new implementation, or who have bugs and/or fixes to report, or are interested in discussing the protocol. If this message goes out OK, I'll announce the mailing list on INFO-IBMPC, INFO-CPM, and INFO-MICRO; KERMIT itself has already been announced on these lists. Here's how to use the list. From ARPANET: Mail requests to be added/deleted to/from the list to INFO-KERMIT-REQUEST@COLUMBIA-20 Mail messages to be seen by all the participants to INFO-KERMIT@COLUMBIA-20 From CCNET (A DECnet network comprising Columbia, CMU, and CWRU), use the same procedure, but mail to host CUCS20. The same facility will also be available from BITnet (a network based on IBM RSCS communication comprising many universities with IBM systems or VAXes) as soon as we have completed the mail gateway mechanism at Columbia (within a few weeks, I hope). An archive of all the messages will be available in the file PS:MAIL.TXT, available via anonymous FTP from COLUMBIA-20 (ARPANET) or anonymous NFT from CUCS20 (CCNET). Any message sent to INFO-KERMIT from any host will reach all participants, no matter which network they're on. We'll try running the list without condensing it into a digest, and see how the traffic goes. If traffic gets too heavy (or silly), we'll convert to digest form. Since the announcement of availability of KERMIT over the network a month ago, there have been several new developments: . UNIX: Everyone has settled on a common source, KERMIT.C, for 4.1bsd, after some bugs were shaken out by Jim Guyton at Rand-Unix. This is available from the Columbia KERMIT area and is the "production" version at the Columbia CS department, where it runs on a variety of VAXes and SUNs. Walter Underwood at Ford is adding support for other varieties of UNIX (v6, v7, Bell System III, Onyx, etc) which can be selected by conditional compilation. I expect this will be available shortly. . CP/M: Bruce Tanner at Cerritos College fixed half-duplex terminal emulation, which was broken in the last update, as well as a problem with files that are a multiple of 128 records. Bernie Eiben at DEC fixed a problem with files that are exactly 0K, 16K, 32K in length, and restored terminal session logging to its previous (imperfect) state; the latter was also broken in the update. Bruce Tanner also beefed up his 8080 cross assembler for the DEC-10 & -20, by adding relational operators in expressions and other new features. None of this stuff is on line yet; I (or someone) will have to sift it all together. CP/M Kermit still has a number of other bugs and shortcomings, which are listed in a previous message, which may be found in the archive. . TOPS-10 KERMIT has had server mode operation added by Denson Burnum at Vanderbilt University; this is not on line yet either. . KERMIT has been adopted by THE SOURCE as their file transfer mechanism; they're implementing it in PL/I on their PR1ME computer. Some other dialup databases are also looking at it. It will, of course, remain nonproprietary. Watch this space for further announcements. - Frank ------- 16-Aug-83 21:31:36-EDT,893;000000000001 Return-Path: Received: from NLM-MCS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 16 Aug 83 21:31:31-EDT Date: Tue 16 Aug 83 21:30:36-EDT From: Jon Albers Subject: Kermit for the OCC-systems To: Info-Kermit@COLUMBIA-20.ARPA Readers, First of all, my thanks to those who put this list together. I feel it was well needed. Second, thanks to Chuck Bacon at the National Institutes of Health, we now have KERMIT for the OCC-1 (Osborne 1). What I would now like to know is if anyone has comwe up with KERMIT for the OCC-Executive 1. I don't want to sound as if I want to sit back and make someone else do the work, but I am not an avid programmer in anything but BASIC. I will contribute anything I can to the list, and I thank again Columbia-U for setting up the list. Jon Albers ALBERS@NLM-MCS ------- 17-Aug-83 09:28:37-EDT,1691;000000000001 Mail-From: CC.FDC created at 17-Aug-83 09:28:28 Date: Wed 17 Aug 83 09:28:27-EDT From: Frank da Cruz Subject: Osborne Kermits To: Info-Kermit@COLUMBIA-20.ARPA Any of you who might have plowed through the material on CP/M Kermit, particularly CPMKERMIT.DOC, may have noticed that the Osborne support is a special problem. Chuck Bacon at NIH added the original Osborne-1 support, which was hairy due to the Osborne's memory-mapped i/o and poor documentation, but it worked fine. Meanwhile, support for various other machines and for "generic" (CP/M calls only) operation was added to the same code, and that broke the Osborne support. The older source file can still produce a working Osborne Kermit and has to be kept around for that reason. Chuck said he would look into getting the Osborne support working from the current source, which he has. Meanwhile, Bruce Tanner added CP/M-Plus (3.0) support to Kermit-80 for some machine that he has, and it turns out that it runs just fine on the Osborne Executive, as it should on any system that fully implements CP/M 3.0. As you can see, Kermit development and maintenance is a truly distributed enterprise. No one has all the supported machines available for testing. CP/M Kermit poses the biggest problem because 15 (and growing!) different machines are supported from a single source file, and one never knows when adding a new feature, fixing a bug, or putting in support for a new machine, whether the change will break the support for some other machine. This is where Info-Kermit can help -- new versions can be tested all over the net in a short time. - Frank ------- 18-Aug-83 11:52:01-EDT,1520;000000000001 Return-Path: Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Thu 18 Aug 83 11:51:48-EDT Return-Path: Received: from MIT-MC by SU-SCORE.ARPA with TCP; Mon 1 Aug 83 18:21:45-PDT Date: 1 August 1983 21:20 EDT From: Allan D. Plehn Subject: KERMIT for IBM 370 running MVS To: G.DACRUZ @ SU-SCORE cc: PLEHN @ MIT-MC ReSent-date: Thu 18 Aug 83 08:51:13-PDT ReSent-from: Frank da Cruz ReSent-to: Info-Kermit@COLUMBIA-20.ARPA I have been looking for a means of xmitting files (ASCII) between the office micros and our IBM 370/158. I thought KERMIT might finally be the solution. Unfortunately, our IBM is not using VM/CMS but instead uses MVS. Is anyone working on a KERMIT implementation to run under MVS? The IBM world is all foreign to me. My computer experience is all on micros, with a little familiarity with MIT's MC (PDP10) and OZ (DEC20). I must rely on what the people in our IBM shop (a little empire that dispenses info grudgingly) for info about the IBM so I can't tell you anything about MVS. Maybe your IBM types recognize this acronym. Is there anything about MVS that would make it tough or impossible to implement KERMIT? Basically, should I forget about KERMIT for this application due to some inherent problem or is it quite possible that KERMIT can and will be available to run under MVS? Any info you can provide will be keenly appreciated. Regards, Al Plehn 18-Aug-83 12:37:54-EDT,2404;000000000001 Return-Path: Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Thu 18 Aug 83 12:37:20-EDT Mail-From: G.DACRUZ created at 18-Aug-83 08:50:47 Date: Thu 18 Aug 83 08:50:47-PDT From: Frank da Cruz Subject: Re: KERMIT for IBM 370 running MVS To: PLEHN@MIT-MC.ARPA In-Reply-To: Message from "Allan D. Plehn " of Mon 1 Aug 83 21:20:00-PDT ReSent-date: Thu 18 Aug 83 09:36:57-PDT ReSent-from: Frank da Cruz ReSent-to: Info-Kermit@COLUMBIA-20.ARPA Just got back from a month's vacation and saw your message. The problem with MVS is that it's a batch operating system -- yes, that's right, cards and JCL (in the IBM sense, not the ITS sense)... To achieve a semblance of timesharing with access from interactive terminals, a batch job is run under MVS which takes over all the terminals and interprets commands as if they were JCL. That batch job is generally something called TSO (Time Sharing Option), which is just about the most hideous parody of timesharing or a "user interface" you've ever seen. Since TSO does support ASCII terminals (the reason I mention this is that many IBM systems do not), it would be quite possible to have KERMIT running under TSO under MVS, and many sites have expressed a craving for this, some have said they would do it. But so far we've seen no results. The latest bunch that said they'd give it a shot was the government of Saskatchewan; you might try calling Arnie Berg in Saskatoon at 306-565-3951 to see how serious they are about it. Our VM/CMS implementation is in assembly language, but I think PL/I would have been a better approach. There are at least two PL/I implementations underway -- one for MULTICS (not at MIT) and another for PR1ME. I suspect either of these would serve as a better basis for a TSO/MVS implementation than would the assembler version. By the way, there are a few other strange non-IBM operating systems that run on the same equipment for which there has been some interest in KERMIT. These include MTS (Michigan Timesharing System) and MUSIC (I'm not sure what that is). Alos, to round out the picture, you can also run UNIX(*) under VM/CMS -- it's marketed by Amdahl and called UTS. We run it at Columbia and are working on getting standard UNIX Kermit to work under it. - Frank ------- 18-Aug-83 12:45:40-EDT,713;000000000001 Return-Path: Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Thu 18 Aug 83 12:45:31-EDT Date: 18 Aug 1983 0944-PDT From: HFISCHER@USC-ECLB Subject: KERMIT for IBM's MVS To: PLEHN at MC cc: Info-Kermit at COLUMBIA-20 RE: request for information on Kermit for IBM's MVS operating system, We too use MVS. I have installed the present Kermit routines on our 3038's, but they are loaded with errors when attempting to assemble. We do not have inhouse expertise as to MVS vs VM differences, and are basically putting the MVS Kermit version on hold. If anybody has any suggestions on how to convert, I am willing to try it out. Herm Fischer (HFischer@eclb) ------- 19-Aug-83 20:12:04-EDT,1905;000000000001 Mail-From: CC.FDC created at 19-Aug-83 20:11:58 Date: Fri 19 Aug 83 20:11:58-EDT From: Frank da Cruz Subject: KERMIT mailing list available To: Info-IBMPC@USC-ISIB.ARPA, Info-Micros@BRL.ARPA, Info-CPM@BRL.ARPA, TOPS-20@SU-SCORE.ARPA cc: Info-Kermit@COLUMBIA-20.ARPA About 6 weeks ago I announced the availability of the KERMIT package on the ARPAnet at COLUMBIA-20. In case you missed it, KERMIT is a file transfer protocol for use primarily between micros and mainframes over TTY lines, and is implemented on a wide variety of both. At that time, I said that if there were sufficient interest in it, I'd start a mailing list. Well, there is, and I have. The list is intended for people who maintain or install KERMIT at their sites, or who are (thinking about) working on a new implementation, or who have bugs and/or fixes to report, or are interested in discussing the protocol. Here's how to use the list. From ARPANET: Mail requests to be added/deleted to/from the list to INFO-KERMIT-REQUEST@COLUMBIA-20 Mail messages to be seen by all the participants to INFO-KERMIT@COLUMBIA-20 From CCNET (A DECnet network comprising Columbia, CMU, and CWRU), use the same procedure, but mail to host CUCS20. The same facility is also available from BITnet (a network based on IBM RSCS communication comprising many universities with IBM systems or VAXes), again using host CUCS20. An archive of all the messages will be available in the file PS:MAIL.TXT, available via anonymous FTP from COLUMBIA-20 (ARPANET) or anonymous NFT from CUCS20 (CCNET). Any message sent to INFO-KERMIT from any host will reach all participants, no matter which network they're on. We'll try running the list without condensing it into a digest, and see how the traffic goes. - Frank da Cruz, Columbia University ------- 22-Aug-83 19:11:11-EDT,2765;000000000001 Mail-From: CC.FDC created at 22-Aug-83 19:11:01 Date: Mon 22 Aug 83 19:11:01-EDT From: Frank da Cruz Subject: New release of MAC80 cross assembler To: Info-Kermit@COLUMBIA-20.ARPA, Info-CPM@BRL.ARPA Bruce Tanner of Cerritos College has contributed a new release of MAC80, his 8080 cross assember for the DECsystem-10 and DECSYSTEM-20, to the KERMIT distribution. This is a CP/M-compatible assembler, written in PDP-10 assembly language, that produces a .HEX file suitable for LOADing on a CP/M system. For those of you who may have an earlier copy, here are the differences: Changes between MAC80 6A and 7: .SYM is created whenever a list file is requested. This can be used by SID and ZSID. MACLIB will read in .LIB (in your default path) as a library of macros and symbol definitions. PAGE will force a page eject. PAGE n will set the default page size to n. NUL FOO will return TRUE if FOO is a null argument to a macro. NUL actually checks for an undefined symbol generated for the macro, so passing an undefined symbol as an argument to a macro will be tested as a null argument. REPT ... ENDM repeats the code inside the macro times. Local symbols may be used in REPT. EXITM may be used to abort a macro or REPT. One layer of fuzzy thinking removed from upper/lower case handling. One known bug: OPT SMAC and nested macros generate junk in the listing. The generated code is OK. Changes between MAC80 6 and 6A: Relational operators in expressions (=,<>,<,<=,>,>=,eq,ne,lt,le,gt,ge), returns FF if true 0 if false. @ and ? are allowed in symbols. $ are considered non-significant in symbols. local symbols are now ??n instead of L$$n. Changes between MAC80 5B and 6: Symbols may now be up to 12 characters long Symbols (including numbers) may include dollar signs The listing file output reflects the actual case of the input file The value generated by dollar signs (assembler PC) in EQU statements are now correct Binary numbers are now legal Macros may now be nested Local symbols in macros You can get the new MAC80 via anonymous FTP from COLUMBIA-20 (ARPAnet) or anonymous NFT from CUCS20 (CCnet), specifying files KER:M*8*.* and KER:TORTUR.* (the latter being a "torture test" that illustrates all the features of the assembler. Bruce's utility HEXIFY, which converts a CP/M .COM file to a .HEX file on the DEC-10 or -20, remains available as before. In addition, he has contributed a complementary program, HEXCOM, to convert a .HEX file to a .COM file. These programs can be obtained by specifying KER:HEX*.* to FTP or NFT. - Frank ------- 22-Aug-83 20:42:55-EDT,5869;000000000001 Mail-From: CC.FDC created at 22-Aug-83 20:42:50 Date: Mon 22 Aug 83 20:42:50-EDT From: Frank da Cruz Subject: KERMIT work in progress To: Info-Kermit@COLUMBIA-20.ARPA Here's a list of some new implementations of KERMIT that are in the works. None of these is online at Columbia yet, but I hope this information might forstall some duplicated efforts. If anyone wants to be put in touch with the people doing these implementations (mostly off the ARPAnet), let me know. - Frank * STEVENS INSTITUTE OF TECHNOLOGY Big doings. They have taken their Bliss implementation for VAX/VMS and started transporting it piecewise to other machines. The part that handles the actual packet construction and transport, the "message" module (VMSMSG.BLI for the VAX) has had the 8th-bit quoting facility added to allow transfer of binary files between systems that can't do 8-bit i/o. They are using this module in these 3 implementations: . DECSYSTEM-10: Upgraded to do 8-bit quoting using the Bliss message module, with the major part of the program still in MACRO-10. Also upgraded to perform some server functions. (Server functions were added independently at Vanderbilt University, but the Stevens work will probably be distributed). . VAX/VMS: Will soon be released with 8th-bit quoting. . Professional-350: A new KERMIT has been written for this machine in MACRO-11, but using the Bliss message module. It's in the final stages of debugging. There will be a menu/function-key P/OS-style user interface as well as a normal keyword-oriented KERMIT command parser. Since Bliss-16 is not commonly available to compile the message module for the PDP-11, it was hand-translated into Bliss-11 and compiled on the DEC-10. Pro-350 KERMIT will be readily transportable to RSX-11/M, which looks almost exactly like P/OS to the programmer. File i/o is done using RMS calls. * THE SOURCE SOURCE Telecomputing has adopted KERMIT as its file transfer protocol and has done an implementation in PL/I for their PR1ME computer. It implements server functions (including some that no one else has implemented yet, like remote directory listings), 8th-bit quoting, and other advanced features. Some additional work remains to be done, and then it will be made available to all. In addition, the SOURCE people have modified IBM PC Kermit to do 8th bit quoting and to invoke some of the new server functions. 8th-bit quoting is especially important to The SOURCE because most of their business comes in over TELENET, which usurps the parity bit, preventing KERMIT (or MODEM or ...) from sending binary files in the normal way. The new PC KERMIT will be made available as soon as possible, after we check it out and merge their work with our own (and CMU's) recent work. Incidentally, I was able to KERMIT their new PC Kermit (170K) to the DEC-20 from their PR1ME system without a hitch. * CORNELL Cornell University is doing a UCSD P-System implementation -- like Stevens, they need it for the Fall semester. They're doing the initial work on Teraks, and expect to run it on IBM PCs and others. A MUMPS implementation is also underway at Cornell. * OTHERS University of Oakland in Rochester, Michigan, has done a MULTICS implementation in PL/I. By the way -- There is a crying demand for more and better IBM mainframe implementations, both for IBM operating systems like TSO under OS/VS1 or MVS, or homegrown systems like MUSIC (McGill University System for Interactive Computing), MTS (Michigan Timesharing System), or GUTS (Gothenburg University Timesharing System). The PR1ME and MULTICS PL/I implementations might easily be adapted to fit these systems. When we (Columbia) get our hands on them, we'll try bringing them up under VM/CMS; if this proves successful, we may abandon the IBM assembler version. The UNIX C version is having conditional compilation support added for non-Berkeley UNIXes by Walter Underwood at Ford. Conditional support for VMS was also added to the C version at DEC; this has yet to be merged in and tested. Once all this is done, Columbia will be adding error packet processing and server functions, and getting it work on IBM mainframes under UTS (Amdahl's versions of UNIX). Columbia will also be adding 8th-bit quoting and advanced server functions to the DEC-20 implementation. We also plan to come up with a native (8088-based) KERMIT for the DEC Rainbow-100. Wesleyan University is doing KERMIT for the Corvus Concept workstation in ISO Pascal; it's in the debugging stages. CP/M KERMIT: Bruce Tanner at Cerritos College fixed half-duplex terminal emulation, which was broken in the last update, as well as a problem with files that are a multiple of 128 records. Bernie Eiben at DEC fixed a problem with files that are exactly 0K, 16K, 32K, ..., in length, and restored terminal session logging to its previous (imperfect) state; the latter was also broken in the update. Bruce Tanner also beefed up his 8080 cross assembler for the DEC-10 & DEC-20. CP/M Kermit still has a number of other bugs and shortcomings, which are listed in a previous message, which may be found in the archive. University of Texas is working on a Cyber 170 implementation in Cyber C, later to be converted to FTN5. Ford Motor Company in Dearborn, Mich, said it would do a Victor 9000 KERMIT; so have various places in Europe and Scandanavia. North Carolina State University announced its intention to produce KERMITs for the Data General MV/8000/AOS/VS and for the Sage II & IV P-Systems. Many sites, mostly commercial, have said they would contribute a RSTS/E version in Basic+ or Basic+2, but I've never heard back from any of them. ------- 23-Aug-83 08:55:11-EDT,780;000000000001 Return-Path: Received: from CU20B by CUCS20 with DECnet; 23 Aug 83 08:55:04 EDT Date: Tue 23 Aug 83 08:52:59-EDT From: Richard Garland Subject: Re: KERMIT work in progress To: cc.fdc@CUCS20 cc: Info-Kermit@CUCS20, OC.GARLAND@CU20B In-Reply-To: Message from "Frank da Cruz " of Mon 22 Aug 83 21:21:22-EDT Does anyone out there still use RSX11-M? I would love to see Kermit on RSX and on RSTS. (RSTS is very big in the small business world). Any ideas on easily convertible versions? Maybe the Bliss-11 can produce a macro like file. Will the Pro-350 version really work on RSX. What about RT-11 for those of us without the P-system? (in other words does anyone use DEC operating systems?) Rg ------- 23-Aug-83 10:04:25-EDT,3256;000000000001 Mail-From: CC.FDC created at 23-Aug-83 10:04:18 Date: Tue 23 Aug 83 10:04:17-EDT From: Frank da Cruz Subject: Re: KERMIT work in progress To: OC.GARLAND@CU20B cc: Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Richard Garland " of Tue 23 Aug 83 08:55:15-EDT Pro-350 KERMIT will work under RSX-11M with maybe a couple minor changes, and using an ordinary command parser (as opposed to the NEXT SCREEN; HELP; DO; INSERT HERE buttons). Correct, Bliss-11 can generate Macro code, which will be distributed for the benefit of those sites that don't have Bliss-11 (or a -10 or -20 to run it on!), much as Macro code is distrubted for VAX/VMS KERMIT, which is written entirely in Bliss-32. Anyway, the Pro implementation might also be rather easily adaptable to RT-11; we'll have to see about that once it's available. Several sites have already expressed an interest in doing the conversion. At that point we'll have all the DEC operating systems well covered except RSTS/E, DOS-11 (anybody remember that?), and OS-8. Of course, there are still the non-DEC OS's for DEC machines to contend with (TENEX, WAITS, ITS for the -10, etc). It would be quite simple to knock off a version of KERMIT for RSTS in Basic-Plus, but no one has done it, or if they have I haven't heard about it. The RT-11 version requires OMSI Pascal, which is proprietary (I don't know the price). It might also be possible to bend the UNIX version of KERMIT (written in C) to run under RT-11 and other DEC OS's in DECUS or Whitesmith C. There may also be a DECUS Pascal for the PDP-11. We have no control over what language people outside Columbia to write KERMIT in. Often, we have no idea that an effort is in progress until a tape shows in in our mailbox. My preference would be for non-proprietary or at least widespread languages, and in fact most implementations are in assembler, which is usually distributed as part of any system package (IBM PC is an exception). There is still no Fortran or Basic implementation, although several sites have said they might produce these. This is not to push any particular language or programming style; the idea of KERMIT is to provide file transfer to the widest variety of machines at the lowest cost, using existing hardware and software whenever possible. A relative of KERMIT, called TTYFTP, was written at Stanford University Medical Center (SUMEX) a few years ago in MAINSAIL (MAchine INdependent SAIL), which should have been readily transportable to the wide variety of machines that MAINSAIL runs on, but MAINSAIL departed from the public domain and TTYFTP never really caught on because MAINSAIL never became nearly as widespread as assembler, Fortran, Basic, Pascal, or C (plus there was never a MAINSAIL for the 8-bit machines). Maybe it will someday -- it's one of the nicest of the Algol-like languages -- and then a MAINSAIL KERMIT could be a great boon, since it would automatically run on TOPS-10, TENEX, TOPS-20, VAX/VMS, VAX/UNIX, MC68000/UNIX, Apollo Aegis, IBM VM/CMS, RT-11, RSX-11M, and who knows what else. (Somebody at SUMEX or XIDAK correct me if I've said anything wrong here.) - Frank ------- 24-Aug-83 16:36:19-EDT,1195;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 24 Aug 83 16:36:11 EDT Date: Wed 24 Aug 83 16:37:24-EDT From: Frank da Cruz Subject: New members, old messages To: Info-Kermit@CUCS20 cc: BJN%MITVMA@CU20B, FDCCU%CUVMB@CU20B I've added 30 or 40 new members to the Info-Kermit mailing list in the last couple days. Those of you who are new to the group might want to take a look at the message archive. It's not too long (yet) -- about 30 DEC-20 pages, or 75K bytes. Some of the more informative messages list known problems or shortcomings of the CP/M KERMIT implementation, new implementations of KERMIT in progress, etc. You can get it via anonymous FTP of KER:MAIL.TXT from ARPANET host COLUMBIA-20, or anonymous NFT of KER:MAIL.TXT from CCNET host CU20B. So far, we don't have an archive accessible from BITNET, and we've also found that BITNET members can't be included in the Info-Kermit mailing list because the BITNET mailer does not yet implement the necessary protocols for mailing list expansion. Those of you who are receiving this message on BITNET are getting it via manual intervention. - Frank ------- 26-Aug-83 10:20:22-EDT,1222;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 26 Aug 83 10:20:14 EDT Date: Fri 26 Aug 83 10:18:48-EDT From: Frank da Cruz Subject: TOPS-20 time bomb breaks KERMIT-20 To: Info-Kermit@CUCS20 On Wednesday, August 24, at 11:53:51-EDT, KERMIT-20 stopped working on many TOPS-20 systems. The symptom was that after a certain number of seconds (KERMIT-20's timeout interval), the retry count would start climbing rapidly, and then the transfer would hang. The problem turns out to be a "time bomb" in TOPS-20. Under certain conditions (i.e. on certain dates, provided the system has been up more than a certain number of hours), the timer interrupt facility stops working properly. If KERMIT-20 has stopped working on your system, just reload the system and the problem will go away. Meanwhile, the systems people at Columbia have developed a fix for the offending code in the monitor and have distributed it to the TOPS-20 managers on the ARPAnet. The problem is also apparent in any other TOPS-20 facility that uses timers, such as the Exec autologout code. The time bomb next goes off on October 27, 1985, at 19:34:06-EST. - Frank ------- 26-Aug-83 23:47:13-EDT,670;000000000001 Return-Path: <@CUCS20:LAVITSKY@RUTGERS.ARPA> Received: from CUCS20 by CU20B with DECnet; 26 Aug 83 23:47:11 EDT Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 26 Aug 83 23:45:51-EDT Date: 26 Aug 83 23:34:26 EDT From: LAVITSKY@RUTGERS.ARPA Subject: Kermit and Commodore?? To: info-micro@BRL-VGR.ARPA, info-kermit@COLUMBIA-20.ARPA Hi, I would like to use Kermit for transferring files with my Commodore 64 to a DEC-20 and possibly a VAX or other mainframes that implement kermit. Is anyone out there writing, or thinking of writing such software. Does anyone know if Kermit for CP/M will run on CP/M for the 64 ?? Thanx, Eric ------- 30-Aug-83 10:09:43-EDT,2512;000000000011 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 10:09:37 EDT Return-Path: <@LBL-CSAM.ARPA:kpno!brown@LBL-CSAM> Received: from LBL-CSAM.ARPA by COLUMBIA-20.ARPA with TCP; Tue 30 Aug 83 02:41:49-EDT From: kpno!brown@LBL-CSAM Return-Path: Message-Id: <8308300645.AA12348@LBL-CSAM.ARPA> Rd: by LBL-CSAM.ARPA (3.347/3.35) id AA12348; Mon, 29 Aug 83 23:45:15 PDT Date: 29 Aug 1983 22:41-MST To: lbl-csam!cc.fdc@columbia-20.ARPA Subject: problems with vms kermit Cc: brown@LBL-CSAM ReSent-date: Tue 30 Aug 83 10:04:58-EDT ReSent-from: Frank da Cruz ReSent-to: Info-Kermit@CUCS20 Frank, We've just brought up the VMS version of KERMIT in Macro. The archive at COLUMBIA-20 is missing a file KERERR.MSG and a Bliss include file seems to be missing (KERCOM? I'm not sure we don't have Bliss here). I have the Kermit distribution from a local Compuserve fellow, thats where I found the files that weren't on COLUMBIA-20. First, my gripes. The echo during the connect mode is abominable, having to wait several seconds to see characters echoed is ridiculous. There seem to be some strange side effects while trying to receive a file via a remote tty (using either server or receive mode) after having done a "SET LINE TTA6". I see messages about device is already allocated to another user and when I retry the command it seems to be accepted but I have to kill KERMIT, control is never returned to me. I haven't tried directly sending or receiving via the login tty yet, we're not set up to do that easily(at least on VMS). Now some constructive comments. The biggest problem we had is that the default device protection under VMS 3.2 is too restrictive, you must do a: "SET PROTECTION=(W:RWLP)/DEVICE TTA6" to allow KERMIT to function properly. How soon will you have the VMS changes from DEC for the kermit.c source? I've got kermit.c on our unix vax and intend to try compiling my present version on a VMS machine to see how they talk to each other (ie. are my problems really due to kermit.c or the macro VMS KERMIT....) If possible can I have the name of the person(s) at DEC doing the work so I can see whats up? I have a couple of minor mods of my own to kermit.c.... regards, Mike Brown Kitt Peak National Observatory Tucson, Arizona (602) 325-9249 {...,arizona,decvax,hao,ihnp4,lbl-csam,sdcarl,sdcsvax,seismo,unc}!kpno!brown 30-Aug-83 10:21:52-EDT,3132;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 10:21:44 EDT Mail-From: CC.FDC created at 30-Aug-83 09:59:05 Date: Tue 30 Aug 83 09:59:04-EDT From: Frank da Cruz Subject: Re: problems with vms kermit To: kpno!brown@LBL-CSAM.ARPA cc: brown@LBL-CSAM.ARPA, cc.fdc@COLUMBIA-20.ARPA In-Reply-To: Message from "kpno!brown@LBL-CSAM" of Tue 30 Aug 83 01:41:00-EDT ReSent-date: Tue 30 Aug 83 10:06:03-EDT ReSent-from: Frank da Cruz ReSent-to: Info-Kermit@CUCS20 I'll pass your comments along to the people at Stevens. The following message talks a little about the echoing. About the VMS support in KERMIT.C... I have it on line. It's pretty ugly, but maybe that's just VMS. The real problem is that they put it into an old version of KERMIT.C (the one that was broken up into about 6 modules) -- the program has been pretty much rewritten since then, and right now it's off somewhere (see some previous messages) having support added for the various non-bsd UNIX clones. When it comes back I thought I would try to add the VMS conditionals, as well as some features that have been sorely missing all along, like error packet processing, server mode, etc. The trick is to have one source to work from, rather than 3 or 4 which have to be reconciled and merged later on. But if you're anxious for it, I'll gladly let you have it if you would be willing to take the VMS support DEC put into the old version and stick it into the current version. - Frank --------------- 25-Aug-83 19:10:04-EDT,1493;000000000001 Mail-From: OC.SITGO created at 25-Aug-83 19:10:02 Date: Thu 25 Aug 83 19:10:02-EDT From: "Nick Bush" Subject: VMS Kermit To: MCCLUSKEY@JPL-VAX.ARPA cc: SY.FDC@CU20B Frank passed on your comments about VMS KERMIT. The next version will have the commands for using a remote server (BYE, etc.). It will probably be a couple weeks before it is ready to be sent out for trials. It will also have a SET FILE-MODE BLOCK, which will allow transfers of any kind of RMS-32 file to another VAX (or to a DEC Professional-350). The response of the CONNECT processing is due to a tradeoff between trying to keep CPU usage to a minimum while allowing usage on a fairly high-speed line. We could not find any way of being able to pick up input from the connected line without using data, except to use large buffers and a timeout. Unfortunately VMS does not implement the desireable type of timeout, which would only occur if at least one character was in the buffer, nor does it allow a small enough time parameter to allow for decent response (minimum timeout is 1 second). Therefore, it may take up to a second for a character to be moved from one terminal line to the other. If you have (or know of anyone who has) a better way of doing it, please let me know. We don't have much usage for the CONNECT command in VMS KERMIT, but any suggestions as to how to improve it would be appreciated. Nick Bush Stevens Institute of Technology ------- ------- 30-Aug-83 10:39:47-EDT,1464;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 10:39:42 EDT Delivery-Notice: While sending this message to CU20B, the CUCS20 mailer was obliged to send this message in 50-byte individually Pushed segments because normal TCP stream transmission timed out. This probably indicates a problem with the receiving TCP or SMTP server. See your site's software support if you have any questions. Mail-From: CC.FDC created at 30-Aug-83 10:04:21 Date: Tue 30 Aug 83 10:04:21-EDT From: Frank da Cruz Subject: Re: problems with vms kermit To: kpno!brown@LBL-CSAM.ARPA cc: brown@LBL-CSAM.ARPA, cc.fdc@COLUMBIA-20.ARPA In-Reply-To: Message from "kpno!brown@LBL-CSAM" of Tue 30 Aug 83 01:41:00-EDT ReSent-date: Tue 30 Aug 83 10:06:41-EDT ReSent-from: Frank da Cruz ReSent-to: Info-Kermit@CUCS20 Oh, I forgot to mention that the missing files are actually present. If you look at the file 00README.TXT, you'll see an explanation of the naming conventions in the KERMIT distribution area. Since there are so many implementationsand since filenames have to be restricted to VMS and TOPS-10 conventions for tape distribution purposes, files pertaining to a particular implementation have a unique prefix. The VAX/VMS modules all start with VMS KER as they did originally); thus the files are VMSCOM, VMSERR, etc... - Frank ------- 30-Aug-83 15:09:34-EDT,1125;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 15:09:28 EDT Mail-From: CC.FDC created at 30-Aug-83 10:04:21 Date: Tue 30 Aug 83 10:04:21-EDT From: Frank da Cruz Subject: Re: problems with vms kermit To: kpno!brown@LBL-CSAM.ARPA cc: brown@LBL-CSAM.ARPA, cc.fdc@COLUMBIA-20.ARPA In-Reply-To: Message from "kpno!brown@LBL-CSAM" of Tue 30 Aug 83 01:41:00-EDT ReSent-date: Tue 30 Aug 83 10:06:41-EDT ReSent-from: Frank da Cruz ReSent-to: Info-Kermit@CUCS20 Oh, I forgot to mention that the missing files are actually present. If you look at the file 00README.TXT, you'll see an explanation of the naming conventions in the KERMIT distribution area. Since there are so many implementations of KERMIT, and since filenames have to be restricted to VMS and TOPS-10 conventions for tape distribution purposes, files pertaining to a particular implementation have a unique prefix. The VAX/VMS modules all start with VMS (rather than KER as they did originally); thus the files are VMSCOM, VMSERR, etc... - Frank ------- 30-Aug-83 21:02:20-EDT,862;000000000001 Return-Path: <@CUCS20:ALBERS@NLM-MCS.ARPA> Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 21:02:18 EDT Received: from NLM-MCS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 30 Aug 83 21:03:10-EDT Date: Tue 30 Aug 83 21:01:53-EDT From: Jon Albers Subject: Problems with CP/M+ Kermit To: Info-Kermit@COLUMBIA-20.ARPA I got a copy of CPMGENERI.ASM from Columbia, assembled it with MAC, setting the VT180 equate to false (it seems that it is default), and the CPM3 equate to true. MAC took it w/o error, but using HEXCOM (the CP/M3.0 loader) on the hex file resulted in this: LOAD ERROR: START LESS THAN 100 or something like that. What did I do wrong? Did anyone else have the same problem? I think that I must have missed the START equate, or something. Can someone help me? Jon Albers ------- 31-Aug-83 11:34:46-EDT,811;000000000001 Return-Path: <@CUCS20:Nemnich@MIT-MULTICS> Received: from CUCS20 by CU20B with DECnet; 31 Aug 83 11:34:43 EDT Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 31 Aug 83 11:35:34-EDT Date: 31 August 1983 1126-edt From: Bruce Nemnich Subject: pckermit.fix To: Info-Kermit @ COLUMBIA-20 It is unfortunate that the pckermit.fix file includes the space among the 16 characters it uses for printable nibbles. Some primitive downloading routines (e.g., IBM ASYNCH under CMS) trim trailing blanks. I have a version of pckexe.bas which does the right thing under those conditions, but it would be better to chenge the character set. A more logical "base" would be 'A', since all systems should be able to send the letters 'A' to 'O'. --bjn 1-Sep-83 11:23:05-EDT,633;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 1 Sep 83 11:22:59 EDT Date: Thu 1 Sep 83 11:23:38-EDT From: Daphne Tzoar Subject: Re: Kermit and Commodore?? To: info-kermit@CUCS20 In-Reply-To: Message from "LAVITSKY@RUTGERS.ARPA" of Fri 26 Aug 83 23:34:26-EDT A few people in the systems group at Columbia have Commodore's and were talking about writing a version of Kermit for it. But, it would be in their spare time so you might want to go ahead and start on a version yourself. You could look at the Apple code as a starting place. /daphne ------- 1-Sep-83 11:36:39-EDT,1126;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 1 Sep 83 11:36:16 EDT Delivery-Notice: While sending this message to CU20B, the CUCS20 mailer was obliged to send this message in 50-byte individually Pushed segments because normal TCP stream transmission timed out. This probably indicates a problem with the receiving TCP or SMTP server. See your site's software support if you have any questions. Date: Thu 1 Sep 83 11:29:20-EDT From: Daphne Tzoar Subject: Re: pckermit.fix To: info-kermit@CUCS20 In-Reply-To: Message from "Bruce Nemnich " of Wed 31 Aug 83 11:26:00-EDT The choice of 20-2F hex (" " through "/") were rather arbitrary. We simply needed a way to get the EXE file from our CMS system to the PC. We never had problems with the space character but if people are having trouble downloading because trailing blanks are being trimmed, we could change the FIX file. Any opinions? /daphne P.S. On your CMS system, do you have the problem if the file is saved as RECFM = F, LRECL = 64? ------- 1-Sep-83 19:10:57-EDT,396;000000000001 Return-Path: <@CUCS20:BRACKENRIDGE@USC-ISIB> Received: from CUCS20 by CU20B with DECnet; 1 Sep 83 19:10:55 EDT Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Thu 1 Sep 83 19:11:47-EDT Date: 1 Sep 1983 1603-PDT Subject: TAC support From: Billy To: INFO-KERMIT@COLUMBIA-20.ARPA Has there been any effort to get Kermit to work through a TAC? ------- 1-Sep-83 19:46:05-EDT,923;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 1 Sep 83 19:46:02 EDT Date: Thu 1 Sep 83 19:46:38-EDT From: Frank da Cruz Subject: Re: TAC support To: BRACKENRIDGE@USC-ISIB.ARPA, INFO-KERMIT@CUCS20 In-Reply-To: Message from "Billy " of Thu 1 Sep 83 19:03:00-EDT There's been a lot of talk about it, but I have yet to hear exactly what it is that a TAC does that prevents Kermit from working. Does it take over the parity bit? If that's all, then use SET PARITY. Does it do some funny kind of flow control? Does Kermit send characters that get interpreted as TAC escape sequences? By the way, if TOPS-20 is involved, there's a bug in virtual terminal support in the TCP monitor that prevents terminals from going into binary mode or something to that effect; I saw a fix for it on the TOPS-20 mailing list. - Frank ------- 3-Sep-83 11:11:26-EDT,829;000000000000 Return-Path: <@CUCS20:b-davis@utah-cs> Received: from CUCS20 by CU20B with DECnet; 3 Sep 83 11:11:24 EDT Received: from UTAH-CS.ARPA by COLUMBIA-20.ARPA with TCP; Sat 3 Sep 83 11:12:07-EDT Received: by UTAH-CS.ARPA (3.343.2/3.33.2) id AA27824; 3 Sep 83 09:10:08 MDT (Sat) Date: 3 Sep 83 09:10:08 MDT (Sat) From: b-davis@utah-cs (Brad Davis) Message-Id: <8309031510.AA27824@UTAH-CS.ARPA> To: info-kermit@columbia-20 Subject: KERMIT-86 We tried to assemble the MS-DOS version of Kermit for both an IBM PC (XT) and for a Z100. The IBM version came up with no problems, but we have had problems with the Z100 version. There are 28 errors (most seem to be IBM bios interrupts). Any help? Also is any one changing Kermit to use 2.0 file path names and the Z100 2.0 bios calls. Brad Davis 3-Sep-83 17:37:00-EDT,1927;000000000000 Return-Path: <@CUCS20:Iglesias%UCI.UCI@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 3 Sep 83 17:36:57 EDT Received: from udel-relay.ARPA by COLUMBIA-20.ARPA with TCP; Sat 3 Sep 83 17:37:38-EDT Date: 02 Sep 83 19:42:24 PDT (Fri) From: Mike Iglesias Return-Path: Subject: Problem with KERMIT-10 Received: from rand-relay.ARPA by udel-relay.ARPA ; 3 Sep 83 16:59:46 EDT (Sat) To: info-kermit.UCI@Rand-Relay Via: UCI; 2 Sep 83 19:54-PDT When using KERMIT-10 to transfer a file from a DECsystem-10 to a 4.1bsd unix system, if the file on the -10 has an extension that is less than three characters (i.e. FILE.X), the file on the unix system ends up being "FILE.X ". The enclosed change to KERMIT-10 will make KERMIT-10 not pad the extension with blanks and not put the "." in if there is no extension. File 1) DSKC:10KERM.OLD[15,4] created: 2118 01-Sep-1983 File 2) DSKC:10KERM.MAC[15,4] created: 2055 01-Sep-1983 1)21 MOVEI T1,"." ; Insert the 'dot' 1) MOVEM T1,DAT(S1) ; And move it in 1) MOVE T1,SFDARG ; Now get the address of the PDB again 1) MOVE T2,3(T1) ; And fetch the word with the extension 1) SFIL.3: SETZ T1, ; Clear T1 **** 2)21 MOVE T1,SFDARG ; Now get the address of the PDB again 2) MOVE T2,3(T1) ; And fetch the word with the extension 2) JUMPE T2,SFIL.A ; Skip putting in 'dot' if no extension 2) MOVEI T1,"." ; Insert the 'dot' 2) MOVEM T1,DAT(S1) ; And move it in 2) SFIL.3: SETZ T1, ; Clear T1 ************** 1)21 ADDI T1,40 ; Change it to ASCII **** 2)21 CAIN T1,0 ; Reached end of extension? 2) JRST SFIL.A ; Yes, done with file name 2) ADDI T1,40 ; Change it to ASCII ************** 1)21 MOVE T1,NUMTRY ; If (Numtry <= 1) SUB T1,MAXTRY ; Maxtry) Then **** 2)21 SFIL.A: MOVE T1,NUMTRY ; If (Numtry <= 2) SUB T1,MAXTRY ; Maxtry) Then ************** 6-Sep-83 10:10:25-EDT,1480;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 10:10:18 EDT Date: Tue 6 Sep 83 10:10:40-EDT From: Frank da Cruz Subject: TOPS-10 dialout programs To: Info-Kermit@CUCS20 Dan Jones at LLL asked whether anyone on the list had seen or heard about a program toalout modem on a TOPS-10 system, and thought this would be a nice feature to have implemented in KERMIT. KERMIT works very nicely with dialout facilities, but it's not a great idea to put support for that into KERMIT itself, because the operation of an autodialer tends to be highly dependent on the system, the particular modem in use, site policy, accounting & billing, etc. The way autodialers are installed at some sites (including ours) require special privileges to control. Since KERMIT should be an ordinary user program, and should be runnable at every sitedistribution it gets), it's best to avoid putting in this kind of special code. At Columbia, our autodialer is controlled by a system daemon. A user program requests the daemon to make make the call and then assign line; the daemon also writes billing records, etc. The user program can then run KERMIT in a lower fork, starting it up with an appropriate SET LINE command. A similar arrangement would be possible in TOPS-10, except for the forking. Is anyone out there running KERMIT-10 with an autodialer? - Frank ------- 6-Sep-83 13:00:00-EDT,2329;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 12:59:44 EDT Date: Tue 6 Sep 83 12:59:51-EDT From: Frank da Cruz Subject: [WANCHO@SIMTEL20.ARPA: TAC support] To: Info-Kermit@CUCS20 There have been a number of inquiries about the use of KERMIT and similar programs (i.e. MODEM) over ARPANET TACs. This is the best explanation I've seen. I'll look at the MODEM program mentioned below and see how the TAC support can be fit into KERMIT-20. - Frank --------------- Mail-From: NOT-LOGGED-IN created at 6-Sep-83 10:59:08 Return-Path: Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Sep 83 10:59:09-EDT Date: 6 Sep 1983 08:57 MDT (Tue) From: WANCHO@SIMTEL20.ARPA To: Frank da Cruz Cc: WANCHO@SIMTEL20.ARPA Subject: TAC support In-reply-to: Msg of Thu 1 Sep 83 19:46:38-EDT from Frank da Cruz Frank, TACs normally run in 7-bit mode, and either the user or the host can change it to run 8-bit binary. If the user changes his input mode to binary, then he can no longer issue further TAC commads and must depend on the host being able to change it. Also, in binary mode, the host must double any FFH characters as FFH is the TELNET intercept character. We have been using host user program negotiated binary mode on ITS with both LMODEM (in MacLisp) and MMODEM (in MIDAS), and on TOPS-20 with MODEM (in MACRO). (On TENEX, it is sufficient to set binary mode with SFMOD and the OS takes care of the negotiations.) For a properly working example of the code required on TOPS-20, FTP a copy of [SRI-KL]MODEM.MAC. The n option forces the ARPANET binary mode negotiations to occur. (Note that the TACs support any of input, output, or both binary modes. With KERMIT, you may only need to negotiate binary mode in the direction needed.) MODEM also has the code to distinguish among the various types of files stored on TOPS-20: normal ASCII, binary, and ITS binary. (ITS binary has a one-word header byte containing DSK8 in SIXBIT. This is to permit auto-recognition of binary files on ITS, which has no other way to let the user know what type the file is, unlike TOPS-20.) --Frank ------- 6-Sep-83 15:33:43-EDT,897;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 15:33:41 EDT Date: Tue 6 Sep 83 15:02:34-EDT From: Frank da Cruz Subject: Anonymous FTP To: Info-Kermit@CUCS20 Anonymous FTP access to COLUMBIA-20 was inadvertantly turned off over the weekend during some TOPS-20 system development. The service is now restored. Apologies for any inconvenience that may have been caused, and thanks to those who pointed out the problem for their patience and understanding. The intention of the Columbia CS facility management (among whose number I do not count myself) is to provide anonymous FTP access to publicly readable files on this machine; should anonymous access ever stop working again without warning, please report it promptly, but also bear in mind that any such disruptions in service are unintentional. - Frank ------- 6-Sep-83 17:08:25-EDT,982;000000000000 Return-Path: <@CUCS20:MRC@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 17:08:19 EDT Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Sep 83 17:08:48-EDT Date: Tue 6 Sep 83 14:08:06-PDT From: Mark Crispin Subject: Re: [WANCHO@SIMTEL20.ARPA: TAC support] To: cc.fdc@COLUMBIA-20.ARPA cc: Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Frank da Cruz " of Tue 6 Sep 83 10:42:57-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Frank - There is a monitor bug in the TCP-based versions of TOPS-20 that should prevent 8-bit binary mode from working in the host=>user direction. The fix is to patch location NVTDOD from SETZ R to SETZ RSKP. That should cause the TAC command @B O S to work. @B I S to the TAC should work now to cause 8-bit binary mode to work. -- Mark -- ------- 6-Sep-83 20:33:54-EDT,1220;000000000000 Return-Path: <@CUCS20:GILLMANN@USC-ISIB> Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 20:33:49 EDT Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Sep 83 20:34:25-EDT Return-Path: Received: FROM MIT-XX BY USC-ISIB.ARPA WITH TCP ; 6 Sep 83 15:38:29 PDT Date: 6 Sep 1983 1836-EDT From: Willie Subject: about Kermit ... To: info-ibmpc@USC-ISIB cc: info-vax-request@SRI-CSL Remailed-Date: 6 Sep 1983 1734-PDT Remailed-From: Dick Gillmann Remailed-To: info-kermit@COLUMBIA-20.ARPA, wmt@MIT-XX Recently, of Kermit on a VAX running Berkeley Unix version 4, the program works fine when transporting files from the PC to the VAX, but does not work in the other direction -- it timed out on waiting for an initial acknowledgment from the PC. Has anyone out there encountered such a problem or similar ones? If so, any idea on fixing it? Would appreciate any infomation on this. If not, I'll have to read through the Kermit documentation and protocols manual, which is a little too time consuming for me. Comments, lease forward to Wmt@MIT-XX. Happy Hack! --- Wmt@XX ------- 7-Sep-83 08:55:03-EDT,2946;000000000001 Return-Path: <@CUCS20:steven@brl-bmd> Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 08:54:59 EDT Received: from BRL-BMD by COLUMBIA-20.ARPA with TCP; Wed 7 Sep 83 08:55:34-EDT Date: Wed, 7 Sep 83 8:45:07 EDT From: Steve Segletes (TBD) To: Willie cc: info-ibmpc@usc-isib, info-kermit@columbia-20 Subject: Re: about Kermit ... Here is a a friend of mine who implemented UNIX Kermit running under JHU UNIX at BRL. Since then, we have discussed which things are bugs ares. Regardless, this is how Kermit performed on our system. I might point out that the UNIX to PC batch mode download did not work on our Berkely VAX either, so that the bug, as you seem to have found, exists in the original coding and not our JHU implementation. Steven Segletes US Army Ballistic Research Laboratory --------------------  Date: Mon, 29 Aug 83 9:27:57 EDT From: Steve Segletes (TBD) To: howard@BRL-BMD cc: steven@BRL-BMD Subject: kermit on BMD-70 I will summarize my experiences with Kermit, so as to provide you with info you might see as valuable. The usages which I have had success with are as follows: kermit -s filename kermit -r kermit -sobject file transfer kermit -ro Uploading*** For a single file transfer, UNIX kermit (Ukermit) should allow a file name to be specified (which is allowed to be different than the filename being sent). Example (CAPS specify PC commands): kermit -r file1 SEND TEST.LST should result in PC file TEST.LST being uploaded as file1 on UNIX. The transfer proceeds, but the final Unix file has the name TEST.LST Downloading*** When multiple files are downloaded, e.g. kermit -s * RECEIVE the first file in the transfer is successfully transferred, but all subsequent files in the batch mode transfer are identical, and comprised of junk from the first successful transfer. We spoke of this in the carpool, and you thought it had something to do the buffer flushing algorithm. When sending is initiated as follows: kermit -s ../filename RECEIVE the PC kermit gasps on the ../ part of the filename. It seems that Ukermit should strip off all the filename info up to the final "/", but doesn't. ************* Finally, the usage statement included with Ukermit is quite confusing, (though maybe not technically incorrect). I believe that the "-" is not required when specifying options: kermit s filename should work, I believe. However, all options must be specified together: kermit -so filename (works) kermit -s -o filename (tries to send ASCII files -o and filename) All in all, it is quite usable now in its present state, even without batch mode download, since object mode download is INCREDIBALLY useful (even one at a time). Steve  7-Sep-83 11:54:43-EDT,2792;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 11:54:35 EDT Date: Wed 7 Sep 83 11:52:58-EDT From: Frank da Cruz Subject: UNIX Kermit vs IBM PC Kermit To: Info-Kermit@CUCS20 In response to several messages about Kermit between the IBM PC and UNIX... First, there are several bugs in UNIX Kermit that have been identified and fixed, notably the wildcard send business. The new UNIX Kermit (which also has support added for various non-Berkeley UNIX systems and some performance improvements) is being tested and will be announced shortly. It will not be, however, the last version we'll see. Several improvements still have to be made in the short term -- standardization of file specifications in the file header packet (case conversion, removal of directory path, etc), addition of error packet processing, etc. In the longer term, UNIX Kermit will also have server mode added. Somebody suggested that UNIX Kermit should let you say "kermit r foo.bar" to let the incoming file be stored under a different name than it was sent with. This is, in fact, a major source of confusion since many Kermits have this feature. The confusion arises because different Kermits interpret this command differently: Kermits that talk to servers (e.g. the IBM PC and CP/M Kermits) pass the given filespec to the server in a request for the server to send it, whereas some other Kermits (like IBM VM/CMS and DEC-20 Kermits) use the given filespec to override the one that comes in a file header packet. Could it be that people who are having trouble transferring files from UNIX to the PC are giving the command "receive filespec" to the PC, rather than just "receive"? That would certainly explain the problem, since the former causes the PC to send a server-mode command to UNIX Kermit, which UNIX Kermit doesn't understand. The whole "receive filespec" business was probably a mistake to begin with. When it's being used to override filenames from incoming file header packets, it's only effective for a single file (not an entire wildcard batch transfer), so its usefulness for that purpose is limited. Since it can also be used to ask a server to send the specified file, the meaning may not be clear. For consistency it would be better to have all versions of Kermit use the following conventions: send filespec send the specified local file receive receive remote files, storing them under the name from the file header. receive filespec receive a single remote file, storing it under the specified local name. get filespec Ask the server to send the specified remote file. Comments? - Frank ------- 7-Sep-83 13:52:53-EDT,900;000000000000 Return-Path: <@CUCS20:G.TJM@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 13:52:49 EDT Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Wed 7 Sep 83 13:53:23-EDT Date: Wed 7 Sep 83 10:52:35-PDT From: Ted Markowitz Subject: VM Kermit - IBM PC Kermit To: info-kermit%CUCS20@COLUMBIA-20.ARPA I've had trouble with getting a PC version of Kermit to talk to a VM version. These both work with the latest DEC-20 product, however. Basically the PC Kermit never seems to get the initiate message from VM. The IBM hardware is this: a 3705 communications controller running NCP and NTO (this allows ASCII terminal access). I've tried all the parity settings allowable and gave the PC Kermit a nudge by typing several Returns to try to wake the connection up. But, to no avail. Any help or ideas would be appreciated. --ted ------- 7-Sep-83 14:36:45-EDT,1303;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 14:36:37 EDT Date: Wed 7 Sep 83 14:36:24-EDT From: Daphne Tzoar Subject: New IBM PC Kermit available To: info-kermit@CUCS20, info-ibmpc@USC-ISIB.ARPA A new version of Kermit for the IBM PC is now available for testing. The pertinent files are PCKERMIT.TST (source) and PCKERMFIX.TST (the "FIX" file) on Columbia-20 in the KERMIT directory. Please try it out and let me know about any problems you encountered. Here's a list of changes for version 1.19: [19] (a) Change NOUT to print numbers in decimal instead of hex. Routine is based on the one used in Generic Kermit. Make a cosmetic change where print filenames & remove extraneous screen output. (b) Change INCHR to allow timeouts when receiving data. In SERINT, change the TEST to a CMP - flag not set as needed. Add Set timeout and fix SPAR to get timeout value from init packet. Add "nop" in NAK because the jump to ABORT is only 2 bytes. [18] A NAK for the next packet is not the same as an ACK for the current packet if we're in Send-Init. Also, account for wraparound when comparing packet numbers that are off by one. /daphne ------- 7-Sep-83 19:11:36-EDT,482;000000000000 Return-Path: <@CUCS20:CERRITOS@USC-ECL> Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 19:11:32 EDT Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Wed 7 Sep 83 19:12:41-EDT Date: 7 Sep 1983 1449-PDT From: Bruce Tanner Subject: HP 3000 Kermit To: INFO-KERMIT@COLUMBIA-20 A friend of mine would like to transfer files from a HP3000 to a Rainbow. Does anyone know about a version of Kermit that runs on a HP3000? Thanks, -Bruce ------- 8-Sep-83 09:56:49-EDT,1022;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 8 Sep 83 09:56:45 EDT Date: Thu 8 Sep 83 09:58:05-EDT From: Frank da Cruz Subject: [Bruce Tanner : CPM3 Kermit] To: Info-Kermit@CUCS20 A hint for anyone who has been trying to run CP/M Kermit under CP/M-Plus... --------------- Return-Path: Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Wed 7 Sep 83 19:12:25-EDT Date: 7 Sep 1983 1447-PDT From: Bruce Tanner Subject: CPM3 Kermit To: CC.FDC@COLUMBIA-20 One thing that wasn't made clear anywhere was that CP/M+ Kermit uses the AUXIN: and AUXOUT: (sometimes refered to as AXI: and AXO:) logical devices. The CP/M+ user must use the DEVICE program (supplied by with CP/M+) to establish the connection between the AUX devices and some physical device and to set up baud rates, etc. This info should be tucked away somewhere in the documentation. -Bruce ------- ------- 9-Sep-83 10:42:45-EDT,619;000000000000 Return-Path: <@CUCS20:G.NORM@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 9 Sep 83 10:42:42 EDT Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Sep 83 10:43:39-EDT Date: Fri 9 Sep 83 07:42:38-PDT From: Norm Kincl Subject: CPM/86, TELENET To: Info-Kermit@COLUMBIA-20.ARPA Reply-To: Kincl@HP-Labs.CSnet-West Hi- A friend who is not on ARPAnet or CSnet asked me to bring up these two questions: 1) Is there a CPM/86 version of KERMIT? 2) Has anyone been able to get KERMIT to work over TELENET (or other packed switching networks)? -Norm ------- 9-Sep-83 11:57:09-EDT,832;000000000000 Return-Path: <@CUCS20:b-davis@utah-cs> Received: from CUCS20 by CU20B with DECnet; 9 Sep 83 11:57:01 EDT Received: from UTAH-CS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Sep 83 11:57:58-EDT Received: by UTAH-CS.ARPA (3.343.2/3.33.3) id AA01270; 9 Sep 83 09:52:27 MDT (Fri) Date: 9 Sep 83 09:52:27 MDT (Fri) From: b-davis@utah-cs (Brad Davis) Message-Id: <8309091552.AA01270@UTAH-CS.ARPA> To: info-kermit@columbia-20 Subject: HP 9836 (model 200?) and Z100 Kermit We have taken the RTKERMIT and have rewritten it for the HP 9836 (in their derivitive of UCSD Pascal). It works but still has some bugs. We are adding binary support and a more consistant interface to the serial port. We will also leave it in a some what more portable form. As for the Z100 we will work it over (sometime). Brad Davis 9-Sep-83 14:09:43-EDT,1045;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Sep 83 14:09:38 EDT Date: Fri 9 Sep 83 14:09:50-EDT From: Frank da Cruz Subject: Re: CPM/86, TELENET To: Kincl.hewlett-packard@RAND-RELAY.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Norm Kincl " of Fri 9 Sep 83 10:43:48-EDT Bill Catchings and I are about to embark on a "native" CP/M-86 Kermit for the Rainbow, either in ASM86, or based on the present UNIX 'C' version. More news as it develops. I have used KERMIT successfully over TELENET; to get it to work, I had to SET PARITY ODD, which precludes transmission of binary files (at least until the 8th-bit-quoting mechanism is implemented in your version of Kermit -- The SOURCE, which is accessed over TELENET, has written an 8th-bit-quoting, server mode Kermit in PL/I for their PR1ME computer, and added 8th-bit quoting to the IBM PC version, to get around this problem; again, more news about this as it develops). - Frank ------- 9-Sep-83 14:22:08-EDT,863;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Sep 83 14:22:02 EDT Date: Fri 9 Sep 83 14:14:26-EDT From: Frank da Cruz Subject: Re: HP 9836 (model 200?) and Z100 Kermit To: b-davis@UTAH-CS.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "b-davis@utah-cs (Brad Davis)" of Fri 9 Sep 83 09:52:27-EDT Glad to hear the news about your Kermit in Pascal for the P-System on the HP 9836; some other places have been asking for that. It turns out that Cornell has also done Kermit in Pascal for the P-System, this time on the Terak; I haven't received it yet. I hope the two versions can be combined, perhaps by putting all the system dependent portions in a separate module. If you waneople at Cornell and compare notes, let me know and I'll put you in touch. - Frank ------- 13-Sep-83 11:24:24-EDT,1121;000000000000 Return-Path: <@CUCS20:Kenny.OSNI@SYSTEM-M.PHOENIX.HONEYWELL> Received: from CUCS20 by CU20B with DECnet; 13 Sep 83 11:24:10 EDT Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 13 Sep 83 11:24:29-EDT Received: from SYSTEM-M.PHOENIX.HONEYWELL by CISL-SERVICE-MULTICS.ARPA dial; 13-Sep-1983 11:11:09-edt Date: 12 September 1983 1730-mst From: B. Kenny Subject: Re: CPM/86, TELENET (INFO-KERMIT [0030]) To: CC.FDC @ COLUMBIA-20 CC: INFO-KERMIT @ COLUMBIA-20 Reply-To: Kenny.OSNI%PCO-Multics @ CISL-SERVICE-MULTICS In your message regarding Kermit use over Telenet, you refer to an 8th-bit-quoting mode. Is there a spec for this? I'm looking at the possibility of porting Kermit to some Honeywell systems that have the same problem of a non-transparent transmission channel. Also, has any thought been given to quoting other characters? Some of our front ends have character-delete and line-delete sequences that can't be disabled. thx 1.0e6 /k**2 (Kenny.OSNI%PCO-Multics@CISL-Service-Multics) 13-Sep-83 21:19:25-EDT,1617;000000000000 Return-Path: <@CUCS20:Iglesias%UCI.UCI@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 13 Sep 83 21:19:21 EDT Received: from udel-relay.ARPA by COLUMBIA-20.ARPA with TCP; Tue 13 Sep 83 21:21:01-EDT Date: 13 Sep 83 08:32:47 PDT (Tue) From: Mike Iglesias Return-Path: Subject: KERMIT on XT w/DOS 2.0 Received: from rand-relay.ARPA by udel-relay.ARPA ; 13 Sep 83 21:19:05 EDT (Tue) To: info-kermit.UCI@Rand-Relay, info-ibmpc@Usc-Isib Cc: grich.UCI@Rand-Relay, sir2!mike%uucp.UCI@Rand-Relay Via: UCI; 13 Sep 83 17:41-PDT I had problems running KERMIT on an XT with DOS 2.0. It appears that KERMIT is sending the first character (^A) repeatedly. I traced the problem to the following code (the dashed lines are mine): outchr: mov al,ah ; Char must be in al. mov cx,0 call dopar ; Set parity appropriately. [10] outch1: mov ah,1 ; Output it. mov dx,0 int comm ;------------------------------------------------- cmp ah,00H je outch3 loop outch1 jmp r ;------------------------------------------------- outch3: jmp rskp I ran KERMIT with the debugger and found that after the 'int comm', ah was non-zero. Looking at the BIOS listing for the XT, ah has the status of the line unless the character couldn't be sent, in which case bit 7 is set in ah. If I remove the code between the dashed lines, it seems to work. To all you XT wizards out there: what code should be between the dashed lines to make it run properly on an XT? Thanks for any help you can provide. 14-Sep-83 11:52:11-EDT,1265;000000000000 Return-Path: <@CUCS20:WLIM@MIT-XX> Received: from CUCS20 by CU20B with DECnet; 14 Sep 83 11:52:04 EDT Received: from MIT-XX by COLUMBIA-20.ARPA with TCP; Wed 14 Sep 83 11:52:58-EDT Date: 14 Sep 1983 1151-EDT From: Willie Lim Subject: KERMIT Dialup Problems To: info-kermit@COLUMBIA-20 I have problems uploading files from my PC or XT to my host machine (MIT-XX). Except for one rare instance many months ago, where I managed to get something over to MIT-XX, I have not been able to transfer any files over since. I also have problems downloading big files (over 50K bytes or so). A colleague of mine using exactly the same software have had no problems at all with the uploading and downloading of files some as big as PCKERMIT.TST. The only difference between the two situations is that I live some distance away from MIT-XX (about 15 miles) while my colleague lives on campus. Note: The VT52 terminal emulator works fine for me. The message that I keep getting for uploading files is: "?Kermit-20: Retry count exhausted in RDATA" For downloading files, the communication hangs frequently and the percentage of number of retries to the number of packets transmitted is sometimes as high as 30%. Willie ------- 14-Sep-83 12:35:01-EDT,1814;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 14 Sep 83 12:34:58 EDT Date: Wed 14 Sep 83 12:36:18-EDT From: Frank da Cruz Subject: Re: KERMIT Dialup Problems To: WLIM@MIT-XX.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Willie Lim " of Wed 14 Sep 83 11:51:00-EDT It's hard to tell what the problem might be without more evidence to look at. Kermit-20 includes packet logging features that would provide the necessary information. However, the symptoms could certainly be explained by a noisy connection, or some other phenomenon peculiar to remote lines or the way your DEC-20 handles them. In any case, Kermit-20 lets you manipulate the timeout interval, the retry threshhold, and other quantities, so if the line is truly noisy (or your DEC-20 front end overburdened) you can change these to fit the conditions, for instance SET SEND TIMEOUT 20 ; Allow more time for incoming packets SET RETRY PACKETS 20 ; Allow up to 20 retries SET RECEIVE PACKET-LENGTH 40 ; Tell the PC to send shorter packets Shortening the packets reduces the probability that a packet will be hit by noise (or will arrive at the DEC-20 front end at a bad time), and reduces the overhead when a packet does have to be retransmitted. I've found that certain sites have a lot of trouble with Kermit on the DEC-20, sometimes only on certain kinds of lines (like remote but not local), and that these are often the sites that have hacked their monitors or front ends. One site was unable to use Kermit (or anything like it) at all because of a change they made to their scheduler... Anyway, if none of this helps, do this: SET DEBUGGING PACKETS SET DEBUGGING LOG-FILE and then send me the log. - Frank ------- 14-Sep-83 17:43:24-EDT,2116;000000000001 Return-Path: <@CUCS20:GILLMANN@USC-ISIB> Received: from CUCS20 by CU20B with DECnet; 14 Sep 83 17:43:18 EDT Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Sep 83 16:11:47-EDT Return-Path: Received: FROM MIT-XX BY USC-ISIB.ARPA WITH TCP ; 14 Sep 83 05:58:44 PDT Date: 14 Sep 1983 0124-EDT From: Thomas S. Wanuga Subject: KERMIT bugs To: info-ibmpc@USC-ISIB cc: wanuga@MIT-XX Remailed-Date: 14 Sep 1983 1309-PDT Remailed-From: Dick Gillmann Remailed-To: info-kermit@COLUMBIA-20.ARPA I cannot send mail to COLUMBIA-20. Could you please forward the following to a relevant person there, and include it in INFO-IBMPC if you think that would be appropriate. Thank you very much. I have tried PCKERMIT.TST (Version 1.19) with my IBMPC and MIT-XX (TOPS-2). I seem to be having a slight problem with this version. Every once and a while (usually when I type ahead fast) things seem to hang (that is, I stop receiving characters from MIT-XX). I can get things back to normal by escaping back to the PC (with ]c), then CONNECTING back to the host. I never noticed this problem with PCKERMIT.NEW (Version 1.3). The version of KERMIT for TOPS-20 that I am using says "TOPS-20 KERMIT version 3A(62)" when I start it up. I tried the following experiment with both versions (1.19 and 1.3). I connected to TOPS-20 and typed the following as fast as I could: "f wanugaf op". Note that "f" is short for "finger". It would take me about three tries to get the hung problem with Version 1.19, but I could not get Version 1.3 to hang at all. Another problem that I have been having is with uploading/downloading .EXE files (the IBMPC type). When I upload an .EXE file from my IBMPC to TOPS-20, the file size remains unchanged. But when I download an .EXE file from TOPS-20 to my IBMPC, two bytes are always added to the end of the file. Have you noticed these problems at all, and if so, do you know how I might get around them? Thanks for your help. Tom Wanuga WANUGA@MIT-XX ------- 14-Sep-83 21:38:30-EDT,1326;000000000000 Return-Path: <@CUCS20:CC.DAPHNE%COLUMBIA-20.UCI@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 14 Sep 83 21:38:25 EDT Received: from udel-relay.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Sep 83 21:39:59-EDT Date: Wed 14 Sep 83 12:06:19-EDT From: Daphne Tzoar Return-Path: Subject: Re: KERMIT on XT w/DOS 2.0 Received: from COLUMBIA-20.ARPA by rand-relay.ARPA ; 14 Sep 83 09:05:51 PDT (Wed) Received: from Rand-Relay by UCI for info-kermit; 14 Sep 83 17:07-PDT Received: from rand-relay.ARPA by udel-relay.ARPA ; 14 Sep 83 21:25:25 EDT (Wed) To: iglesias.uci@RAND-RELAY Cc: info-kermit.UCI@RAND-RELAY, info-ibmpc@USC-ISIB, grich.UCI@RAND-RELAY, sir2!mike%uucp.UCI@RAND-RELAY In-Reply-To: Message from "Mike Iglesias " of Tue 13 Sep 83 08:32:47-EDT Via: UCI; 14 Sep 83 18:02-PDT The problem you mentioned is due to a ROM BIOS error. The way we got around it was to not use the INT routine and just write the character out to the port directly. The code was modified by the folks at CMU since the older versions of Kermit were not able to transfer files with the IBM PC/XT. All newer versions of the Kermit code have the correction so maybe you should just get the newer files. /daphne ------- 15-Sep-83 11:06:11-EDT,1658;000000000000 Return-Path: <@CUCS20:WANUGA@MIT-XX> Received: from CUCS20 by CU20B with DECnet; 15 Sep 83 11:05:56 EDT Received: from MIT-XX by COLUMBIA-20.ARPA with TCP; Thu 15 Sep 83 11:07:22-EDT Date: 14 Sep 1983 1353-EDT From: Thomas S. Wanuga Subject: IBMPC v1.19 bugs To: info-kermit@COLUMBIA-20 I have tried PCKERMIT.TST (Version 1.19) with my IBMPC and MIT-XX (TOPS-20). I seem to be having a slight problem with this version. Every once and a while (usually when I type ahead fast) things seem to hang (that is, I stop receiving characters from MIT-XX). I can get things back to normal by escaping back to the PC (with ]c), then CONNECTING back to the host. I never noticed this problem with PCKERMIT.NEW (Version 1.3). The version of KERMIT for TOPS-20 that I am using says "TOPS-20 KERMIT version 3A(62)" when I start it up. I tried the following experiment with both versions (1.19 and 1.3). I connected to TOPS-20 and typed the following as fast as I could: "f wanugaf op". Note that "f" is short for "finger". It would take me about three tries to get the hung problem with Version 1.19, but I could not get Version 1.3 to hang at all. Another problem that I have been having is with uploading/downloading .EXE files (the IBMPC type). When I upload an .EXE file from my IBMPC to TOPS-20, the file size remains unchanged. But when I download an .EXE file from TOPS-20 to my IBMPC, two bytes are always added to the end of the file. Have you noticed these problems at all, and if so, do you know how I might get around them? Thanks for your help. Tom Wanuga WANUGA@MIT-XX ------- 15-Sep-83 13:04:04-EDT,4250;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 15 Sep 83 13:03:30 EDT Date: Thu 15 Sep 83 13:05:01-EDT From: Frank da Cruz Subject: Kermit "RFC No. 1" To: Info-Kermit@CUCS20 In the ARPAnet tradition of testing any new idea out on its intended victims before casting it into concrete (or silicon), here are a couple new ideas for the KERMIT protocol, presented as a "Request For Comments" (RFC). If no one can think of any serious objections to them, I'll add them to the protocol manual and code them into KERMIT-20 for testing. Comments will be appreciated, especially from anyone who has had some experience writing or fixing some implementation of Kermit (or some other protocol). 1. Interruption of file transfer. How many times have you transferred a file you didn't mean to and wished you could stop the transfer gracefully? Here's the proposed mechanism: a. To interrupt sending a file, simply send an EOF ("Z") packet in place of the next data packet, including a "D" (for Discard) in the data field. The recipient ACKs the Z packet normally, but does not retain the file. This will not interfere with older Kermits on the receiving end; they will not inspect the data field and will close the file normally. The mechanism can be triggered by the sender typing an interrupt character. If a (wildcard) file group is being sent, it is possible to skip to the next file or to terminate the entire batch; the protocol is the same in either case, but the desired action could be selected by different interrupt characters, e.g. CTRL-X to skip the current file, CTRL-Z to skip the rest of the batch. b. To interrupt receiving a file, put an "X" in the data field of an ACK for a data packet. To interrupt receiving an entire file group, use a "Z". The mechanism could be triggered in the same way as above. A sender that was aware of the new feature, upon finding one of these codes, would act as described above, i.e. send a "Z" packet with a "D" code; an older sender would simply ignore the codes and continue sending. 2. Putting information in the data field of an ACK packet can be useful elsewhere too. One application springs to mind: the ACK for a file header packet can contain the name under which the recipient will store the file. This is useful when the recipient must change the file name to suit local naming conventions or to avoid filename conflicts. Old senders will not notice the information in the ACK and will behave as before, but new ones will be able to display the information on the screen so you'll know where to find the file on the receiving system. 3. Various server functions have been mentioned in the protocol manual, but only the most basic ones have been implemented so far: send/receive files, finish, and bye. In order to implement other functions successfully, particularly ones that require information to be transferred -- directory listings and so forth -- the two Kermits should be able to configure themselves to one another beforehand, as they do before a file transfer, with respect to packet size, timeout, padding, the various prefix characters & quoting options, etc. There is presently no provision for this. The proposed addition is an "I" packet, whose contents are exactly like an "S" (Send-Init) packet, and which is ACK'd in the same way. The only difference is that an "S" packet tells the receiving Kermit (server or not) that one or more files are on the way, whereas the "I" packet will be strictly informational and will not trigger transition into another state. The user requesting a function of a server may optionally precede any request with an "I" packet; if an "I" is not sent, one or both sides will use default or previous values for the Send-Init paramaters. Servers that do not know about the new "I" packet will respond with an error message but will remain in operation. Although use of the "I" packet will (must) be optional, it is recommended before each transaction since one side has no way of knowing whether the other side has been restarted or had its parameters reset or changed in some other way. - Frank ------- 15-Sep-83 16:25:07-EDT,654;000000000000 Return-Path: <@CUCS20:G.TJM@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 15 Sep 83 16:25:02 EDT Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Thu 15 Sep 83 16:26:30-EDT Date: Thu 15 Sep 83 13:20:44-PDT From: Ted Markowitz Subject: Batch running of Kermit To: info-kermit%CUCS20@COLUMBIA-20.ARPA Has anyone tried to use Kermit underneath an auto-dialer program in a batch environment? What I'm trying to do is set up an off-hours file transfer capability so as to avoid higher phone and CPU charges. I'm referring here to a TOPS-20 Kermit. Any help would be appreciated. --ted ------- 15-Sep-83 19:51:03-EDT,1074;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 15 Sep 83 19:50:59 EDT Date: Thu 15 Sep 83 19:52:07-EDT From: Frank da Cruz Subject: Re: Batch running of Kermit To: G.TJM@SU-SCORE.ARPA, info-kermit%CUCS20@CUCS20 In-Reply-To: Message from "Ted Markowitz " of Thu 15 Sep 83 16:26:39-EDT Kermit-20 is designed to be runnable under batch, though I've never tried it. For instance, although it normally traps control-C, it does not try to do so under batch, which would deny it that capability. The major problem you'd encounter (I think) would be the processing of error messages. Almost any message will come out with a "?" in first position, which would normally terminate the batch job; there's presently no distinction between "warning" messages and "fatal" error messages, nor is it easy to see how there can be since a message is just as likely to originate from the remote side as from the local. Anyway, give it a try and let me know the results. Good luck! - Frank ------- 16-Sep-83 11:44:14-EDT,1335;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 16 Sep 83 11:44:08 EDT Date: Fri 16 Sep 83 11:44:29-EDT From: Richard Garland Subject: Apple Kermit configuration To: Info-Kermit@CUCS20 I have just been through the process of configuring and downloading Kermit to an Apple for one of my users. He points out that he often has to move things around in his machine to different slots. (his is a lab system with D/A and other interfaces.) This shuffling around is due (he says) since it seems like everyone has fixed ideas about which gizmo should go where and they all conflict. (For example he has 3 interfaces/programs which all want slot 2.) He says a program could figure out in most cases where the desired interface is plugged it. In particular he has another communications program which he says can find his Super Serial card no matter where he plugs it. Could Kermit-65 do this? It would save us and a lot of others considerable grief. Maybe a SET command if not dynamic configuration. Also how about a SET command for D.C.Hayes vs. Serial Card? That may be too much to ask but it would certainly be wonderful to have 1 version of Kermit for my 4 Apples, which at the moment have different slots/cards combinations. Rg ------- 16-Sep-83 14:42:33-EDT,721;000000000000 Return-Path: <@CUCS20:Nemnich@MIT-MULTICS> Received: from CUCS20 by CU20B with DECnet; 16 Sep 83 14:42:30 EDT Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 16 Sep 83 14:43:06-EDT Date: Fri, 16 Sep 83 14:33 EDT From: Bruce Nemnich Subject: Re: Apple Kermit configuration To: Richard Garland CC: Info-Kermit @ COLUMBIA-20 Yes, in one can determine what slot a given card is in by looking for specific bytes in the card's ROM. Depending on what slot the card is in, the ROM will be mapped to a different address range. Some care must be taken to ensure the bytes are unique to the card in question, of course. 16-Sep-83 17:02:40-EDT,842;000000000000 Return-Path: <@CUCS20:OC.SITGO@CU20B> Received: from CUCS20 by CU20B with DECnet; 16 Sep 83 17:02:33 EDT Received: from CU20B by CUCS20 with DECnet; 16 Sep 83 17:02:23 EDT Date: Fri 16 Sep 83 17:01:53-EDT From: "Nick Bush" Subject: Re: Apple Kermit configuration To: G.GARLAND@CUCS20 cc: Info-Kermit@CUCS20 In-Reply-To: Message from "Richard Garland " of Fri 16 Sep 83 11:44:17-EDT Certainly it would be possible for Kermit-65 to determine where the card was located. In fact, it was considered while it was being written and only left out because of a lack of time. I don't know how reasonable it would be for a single copy of Kermit-65 to have the support for different cards - there might be routine name conflicts. I'll pass the comments on to the author. Nick Bush ------- 17-Sep-83 14:10:05-EDT,625;000000000000 Return-Path: <@CUCS20:WANUGA@MIT-XX> Received: from CUCS20 by CU20B with DECnet; 17 Sep 83 14:10:02 EDT Received: from MIT-XX by COLUMBIA-20.ARPA with TCP; Sat 17 Sep 83 14:10:00-EDT Date: 17 Sep 1983 1408-EDT From: Thomas S. Wanuga Subject: NEC APC To: info-kermit@COLUMBIA-20 cc: wanuga@MIT-XX, JPRESTIVO@MIT-XX Does a verf Kexist for the NEC APC, or is anyone working on one? She N has an 8086, how hard would it be to modify the IBMPC version to run on the APC? Would it run without any changes under MS-DOS 1.1 or MS-DOS 2.0? Tom Wanuga WANUGA@MIT-XX ------- 17-Sep-83 19:01:10-EDT,979;000000000000 Return-Path: <@CUCS20:wunder@FORD-WDL1.ARPA> Received: from CUCS20 by CU20B with DECnet; 17 Sep 83 19:01:06 EDT Received: from FORD-WDL1.ARPA by COLUMBIA-20.ARPA with TCP; Sat 17 Sep 83 19:01:03-EDT Return-Path:<> Date: 17-Sep-83 16:00:26-PDT From: wunder@FORD-WDL1.ARPA Subject: KERMIT in WC To: info-kermit@COLUMBIA-20.ARPA I have a KERMIT in Whitesmith's C, running on Idris (Whitesmiths' imitation v6 Unix). I hope that there is not much need for this, since Idris is no fun to use, but if anyone needs it, this will spare them the work. This version is based on the Portable Unix KERMIT, but it doesn't have all the fixes (yet). The necessary changes were massive enough that it didn't seem fair to the rest of the world to conditionalize the Portable KERMIT. Besides, we just made it run today. We are running IDRIS-68K on a Chromatics CGC7900. walter underwood UUCP: fortune!wdl1!wunder ARPA: wunder@FORD-WDL1 Phone: (415) 852-4206 19-Sep-83 10:38:34-EDT,3877;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 10:38:26 EDT Date: Mon 19 Sep 83 10:38:12-EDT From: Frank da Cruz Subject: [WANCHO@SIMTEL20.ARPA: KRFC #2 and #3] To: Info-Kermit@CUCS20 KRFC #2 ("Point of Procedure") seems perfectly reasonable, so let's call them KRFC's and let's send them to Info-Kermit@COLUMBIA-20. KRFC #3 (mainframe format for binary files) deserves, and probably will provoke, more comment. --------------- Date: 16 Sep 1983 18:52 MDT (Fri) From: WANCHO@SIMTEL20.ARPA To: INFO-KERMIT-REQUEST@COLUMBIA-20.ARPA Subject: KRFC #2 and #3 KRFC #2 Proposed Kermit RFCs should be submitted to INFO-KERMIT-REQUEST at COLUMBIA-20 for number assignment and redistribution - no other editing, except to kill extraneous lines from the header, such as "Received:" will be done. To avoid *any* possible confusion with Arpanet RFCs, the short name should be KRFC, with apologies to any radio or TV station with those call letters. -------------------- KRFC #3 STANDARD FILE TYPES Background In very recent memory, when the public domain files related to CP/M were stored on MIT-MC, an arbitrary scheme had been developed for a program to easily distinguish binary files from ASCII text files, as there is no bit in the FCB to designate file types. (Note that we are considering WordStar-generated, LU, and SQ files, as binary files, as well as .COM, .CMD (for you CP/M-86 types), and .REL files, and miscellaneous others - any that contain bytes with the 8th (parity) bit set). On PDP-10s, with 36-bit words, we decided to store binary files in the following format: a header word, containing "DSK8" in SIXBIT, followed by the file contents, stored as four 8-bit bytes, left-justified in each 36-bit word. The remaining four bits were ignored, and usually set to zero by the uploading program. Each 128-byte record was stored as-is, without any trailing padding, except for padding out the last 36-bit word with ^Cs. ASCII files were stored as normal ASCII files, except the last record, containing one or more ^Zs (the CP/M EOF) was stored without the ^Z(s) and beyond. The normal convention of padding out with one or more ^Cs to fill a 36-bit word was used. Any trailing ^Cs were not used to set the file size in 7-bit bytes in the FCB. Downloading programs automatically pad the last 128-byte record with ^Zs as needed. The Proposal To adopt the "ITS Binary" format for storing micro binary files on mainframes, and to observe the end-of-file conventions for ASCII text files. Advantages Downloading programs to not need to depend on any FCB information, which may be possibly ambiguous, to determine the file type. If a "DSK8" in SIXBIT, or its equivalent transformation of four bytes in 32-bit words is detected, the file is, by definition, a binary file. There is a very large collection of CP/M public domain files, including those files formerly kept on MIT-MC, all of the SIG/M volumes, currently up to Volume 85, and all of the CPMUG volumes, except those duplicates of SIG/M volumes, up to Volume 90, now stored on the SIMTEL20. All of the SIG/M and CPMUG volumes were uploaded into ITS Binary format files, and all of the binary files in the MC collection are in ITS Binary format. The TOPS-20 MODEM and CRC programs automatically recognize and distinguish between ITS Binary and regular ASCII text files. CRC computes the same CRC value that the CP/M CRCK program derives from the same files. Binary files uploaded by either KERMIT or MODEM can be downloaded by either. Lastly, CP/M (micro) binary files stored as binary files reduces mainframe storage costs; binary files transmitted, where possible, in binary mode, save transmission costs, etc. ------- 19-Sep-83 11:40:43-EDT,5655;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 11:40:19 EDT Date: Mon 19 Sep 83 11:39:49-EDT From: Frank da Cruz Subject: Re: KRFC #3 To: Info-Kermit@CUCS20 cc: cc.fdc@CUCS20 In-Reply-To: Message from "WANCHO@SIMTEL20.ARPA" of Fri 16 Sep 83 20:54:33-EDT A few comments about mainframe storage of uploaded binary files: KERMIT-10 and KERMIT-20 already have the capability to store uploaded files in either 8-bit (binary) or 7-bit (ASCII) mode. But someone has to tell KERMIT which format to use. Using ITS binary would certainly simplify the job, since KERMIT could automatically select the right size by inspecting the first 4 characters of an incoming file. However, someone has to tell the sender to prepend that special first word. How is that done? Is it done automatically by the program based on the file type (.COM, .CMD, etc)? That could be subject to error, as in the case where I send my LOGIN.CMD (an ASCII text file) from the DEC-20 to the micro and then send it back to the mainframe. Also, what if an ASCII text file on the micro happens to start with the ASCII characters "DSK8"? This is not to say it's a bad idea. Compatibility and standardization are worth a price, especially when the price is not much greater than what we're paying now, which is that KERMIT on the DEC-10/20 stores all the files in an incoming batch with the same bytesize, 7-bit by default, or 8-bit if the SET FILE-BYTESIZE 8 command has been issued. The proposed method would allow binary and text files to be mixed in a batch during uploading. For those outside the PDP-10 world who may be puzzled by this, the problem occurs only because PDP-10s (DEC-10's running TOPS-10, ITS, WAITS, or TENEX; DEC-20s running TOPS-20) do not store text in 8-bit bytes, as the micros do, and as most other mainframes do. For instance, UNIX systems on VAXes or PDP-11s store both text and binary files in 8-bit bytes. I assume that the proposed standard would only affect PDP-10s and other systems that would store characters in 7-bit bytes (thus losing the 8th bit) unless explicitly directed otherwise; systems like IBM VM/CMS, UNIX, VAX/VMS, etc, would not have to bother with ITS binary format. Right? As to ASCII files, why bother padding out the last "word" with ^C's (is that an ITS convention?)? I think the primary goal of ASCII file transfer should be to end up with a useful file on the receiving end, and most PDP-10 users are not accustomed to finding several ^C's at the end of a text file. Especially since one is just as likely to be sending PDP-10 text files (which don't have ^C's at the end) to the micro as CP/M text files to the PDP-10. As to binary files, I see two possible problems with the proposal. First, since the FCB contains no information about whether the file is binary or ASCII, the micro side of the file transfer protocol must make that determination, either by asking the user, or by observing certain filetype conventions; either method is prone to error, and these will tend to affect the less sophisticated user. Second, although SIG/M and CPMUG volumes are stored in the proposed format, there may be other sites that have similar databases stored in other formats; would they have any objection to the proposed change? How about this as a counter-proposal: Let the micro send the characters DSK8 as the first four characters of any binary file, as originally proposed, but the host will not store those characters in the file. Instead, the DEC-10 or DEC-20 will simply store the actual contents of the file in 8-bit bytes, rather than 7-bit bytes (as it would normally have done). When sending files back to the micro, the DEC-10 or -20 is capable of picking up the bytesize from the file's directory entry and sending it appropriately; storing the characters "DSK8" in the mainframe copy of the file is unnecessary. Hosts other than PDP-10s, which store characters in 8-bit bytes anyway, upon seeing "DSK8" as the first 4 characters of an incoming file, can take appropriate action, which will most likely be to simply discard those 4 characters. To deal with PDP-10 resident files that DO have "DSK8" in the file, however, KERMIT could have an option added to ignore (i.e. not send) those characters. Thus, KERMIT could work on both kinds of systems. This flexibility becomes valuable when you consider that CP/M is not the only system that is going to be uploading binary files to the PDP-10 -- there's UNIX, MS/PC DOS, CP/M-86, VMS, VM/CMS, etc etc. Would this cause a problem with MODEM or CRCK, etc? I suspect not, since they would ignore the DSK8 characters (i.e. not send them, or not include them in the CRC) if they were there, and should know how to open the file with the correct bytesize anyway. Finally, I think most of the ideas of the MODEM world spring from an environment where the microcomputer user views the mainframe as an archiving device, and is primarily concerned with files that originate on the micro. There is also another world, in which mainframe users view the micro as an archiving device (providing removable media) for mainframe-created files. In that world, a whole new set of questions is raised. How do you store 36-bit DEC-10 or -20 .EXE or .REL files on the micro? How do you deal with a mainframe file that happens to contain ^Z's in its last "block"? An earlier message to the KERMIT list discussed some of these questions. And every answer only opens the door to some deeper question... - Frank ------- 19-Sep-83 11:54:07-EDT,2737;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 11:53:57 EDT Date: 17 Sep 1983 1229-PDT Subject: Re: Kermit "RFC No. 1" From: Billy ReSent-date: Mon 19 Sep 83 11:49:58-EDT ReSent-from: Frank da Cruz ReSent-to: Info-Kermit@CUCS20 I like the idea of RFCs for Kermit. I think the idea of aborting a connection would be particularly useful. Feel free to edit or distribute this as you wish. I have several things on my wish list: It would be nice if Tops-20 Kermit had an automatic mode where things like Receive packet length and pause times could be set dynamically based on baud rate and load average or perhaps scheduler options. We had some problems with accountants sending large spread sheet files to Tops-20 durring peak load hours breaking the front end. Readjusting receive packet length to a level acceptable to the front end allowed us to run even at 9600 baud durring periods of high load averages. As these people were not programmer types the solution to the problem was apparently not obvious, an automatic Tops-20 Kermit would have saved much running around by the systems staff to find someone who knew anything about Kermit and could teach the accountants the correct Kermit command to fix the problem. I would like to see Kermit-86 re-organised on a more modular basis. I would be more encouraged to add new features if I didn't have to deal with a monolithic 186K byte file. I would like to see Kermit-86 divided up into seperate files and defined interfaces for File I/O, Terminal Emulation, Command Interpreter, Screen display management, and Kermit protocol modules. This way we could support a large number of variations for different machines and different styles of user interaction while maintaining commonality of the core routines. Particularly I might want to use a propriatary terminal emulator, or Columbia may choose to distribute several public domain terminal emulators as they are donated. At ISI we have ordered a few mice for experimental purposes. I might want to replace the Tops-20 style command interpreter with a mouse menu style interpreter. Someone else might want a Unix style command interface, but still run under MS DOS. Similarly screen management and File I/O as seperate modules would allow the same Kermit to be used under several operating systems, and on multiple machines with varying display technologies. Of course this is something that must be done at a central site. The module interfaces should be defined and published. While I suggested this for the 8086 Kermit it is also applicable to the C Kermits and Z80 Kermits. ------- 19-Sep-83 12:08:03-EDT,1421;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 12:07:19 EDT Date: Mon 19 Sep 83 11:57:01-EDT From: Frank da Cruz Subject: Re: Kermit "RFC No. 1" To: Info-Kermit@CUCS20 In-Reply-To: Message from "Billy " of Sat 17 Sep 83 15:30:22-EDT About Billy's wish list: TOPS-20 Kermit does automatically adjust the timeout interval based on load average. Adjusting the packet length is another possibility. However, due to a shortcoming in TOPS-20, it is not feasible to adjust ANYTHING based on terminal baud rate. The reason is that for remote lines, TOPS-20 does not know what the actual baud rate it. Yes, you can ask the monitor, and yes, it will return a reasonable number, but that is the "nominal" baud rate for that line, not the actual speed, i.e. it is the speed to which the line is reset after it is hung up. It does not store the actual speed anywhere, except in a write-only (yes, write-only) register in the DH-11 multiplexer on the DEC-20's PDP-11/40 front end. About organization 8080, 8086, and UNIX Kermits along a more modular basis -- I couldn't agree more, and I hope we'll be able to do it. If we had known that KERMIT was going to grow to the proportions it has, I'm sure we would have paid a little more attention to these issues when writing the programs originally. - Frank ------- 19-Sep-83 15:26:36-EDT,1199;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 15:26:24 EDT Date: Mon 19 Sep 83 15:02:03-EDT From: Frank da Cruz Subject: New TTLINK for DEC-20 To: Info-Kermit@CUCS20 TTLINK, which DEC-20 KERMIT runs in a lower fork to accomplish outgoing terminal cionsnot able to run under TOPS-20 batch because the program wao enC capability, and batch won't allow that. The STIW JSYS (which must be used to let the characters ^C, ^T, and ^O pass through to the remote host) requires ^C capability, even if you're not using it to manipulate ^C itself. The only solution is to skip the STIW if ^C capability hasn't beeessfnabled, which means that you can't send ^O or ^T to the host, and that ^C (typed twice) will terminate the program (continuably). If you run TTLINK under these conditions, an appropriate warning message will be typed, but you can continue to run the program with the limitations just described. This is edit 15 to TTLINK. The source and binary can be found at COLUMBIA-20 as KER:TTLINK.*, retrievable via anonymous FTP. Report any problems to me. - Frank ------- 19-Sep-83 18:54:18-EDT,1204;000000000001 Return-Path: <@CUCS20:OC.SITGO@CU20B> Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 18:54:08 EDT Received: from CU20B by CUCS20 with DECnet; 19 Sep 83 18:38:02 EDT Date: Mon 19 Sep 83 18:37:32-EDT From: "Nick Bush" Subject: Re: Kermit "RFC No. 1" To: cc.fdc@CUCS20 cc: Info-Kermit@CUCS20 In-Reply-To: Message from "Frank da Cruz " of Thu 15 Sep 83 13:04:07-EDT The items in KRFC #1 all seem reasonable. In fact, they provide some functionality which we have alread seen a need for when doing version 1 of Kermit-10. I have one suggestion about the "I" packet. Rather than using the same contents as an "S" packet, this would be a chance to redesign the parameter exchange to get around a few of the problems there have been with the "S" method of passing parameters. For example, the "I" packet could include a bit map of the features that the Kermit supports (which generic commands, etc.), allthe Kermit to determine what it can and cannot do. This would not affect existing Kermits at all, but would allow a method of adding features which might otherwise be incompatible with previous versions of the protocol. ------- 20-Sep-83 11:54:34-EDT,4385;000000000001 Return-Path: <@CUCS20:SY.FDC@CU20B> Received: from CUCS20 by CU20B with DECnet; 20 Sep 83 11:54:22 EDT Received: from CU20B by CUCS20 with DECnet; 20 Sep 83 11:53:53 EDT Date: Tue 20 Sep 83 11:53:11-EDT From: Frank da Cruz Subject: Kermit RFC #4 To: Info-Kermit@CUCS20 Kermit RFC #4, regarding calculation of the CRC, from Nick Bush at Stevens Institute of Technology in Hoboken, New Jersey. Nick and the people at Stevens are putting CRC support into several versions of KERMIT (including VAX/VMS, TOPS-10, PDP-11, CP/M) and will do it as proposed unless serious objections surface. In particular, note that the method differs from that used by MODEM7. Is there any any reason why KERMIT should produce the same CRC as MODEM7? - Frank --------------- Date: Tue 20 Sep 83 11:36:19-EDT From: "Nick Bush" Subject: Kermit protocol version 3 - CRC usage To: SY.FDC@CU20B Proposal for the implementation of the three character CRC specified in the Kermit protocol version 3. The version 3 protocol manual defines the existance of a 3 character CRC option for the "check" field of a message. It specifies that the generating polynomial is to be the CRC-CCITT polynomial, but does not specify the exact method of calculating the CRC. While the general method of calculating a CRC based on the CRC-CCITT is well specified elsewhere, there are a few options in the method of calculation which need to be specified to ensure that all implementations produce the same CRC value. The following defines those options suggested for use in the Kermit protocol: 1. Treat the checked portion of the message (i.e., the portion between the and the block check, exclusive of the two) as a string of bits with the low order bit of the first character first and the high order bit of the last character last. 2. Divide the message bit string by the value representing the CRC-CCITT polynomial (X**16+X**12+X**5+1). This is actually done a byte at a time by a very straight forward algorithm. 3. The remainder is the block check value that is split up into the 3 pieces for packing into the 3 character field. There are three things to note about this that affect the implementation of the algorithm for calculating the CRC: 1. The initial value for the CRC is taken as 0. Some protocols, notably SDLC use all ones as the initial value. This is just an arbitrary choice, but is compatible with a number of protocols. 2. The bit string is treated as it will appear on the transmission line (at least most async transmissions). That is, the low order bit of each byte is first, with the high order bit of a byte immediately preceding the low order bit of the next byte. This method is typical of that used by most protocols, and is the method that is usually implemented in hardware. For example, the VAX has a CRC instruction that treats the string in this way. Any line interface I have seen that allows for CRC generation for transmitted characters does so by working on the serial stream of bits, which are normally transmitted as low order of each byte first. Note that this is the opposite of how MODEM calculates the CRC that it uses. It treats the string as a stream of bits with the high order bit of the first byte coming first and the low order bit of the last byte coming last (meaning that the low order bit of a byte immediately precedes the high order bit of the next byte). I suggest defining the Kermit protocol so that implementations can make use of hardware CRC generators that (like the CRC instruction on the VAX) use the low-order bit first convention. 3. The remainder of the division is used as the CRC as is. Some protocols, like SDLC, complement it first. There seems to be no reason not to use the remainder as is, without complementing it. It should be specified that the Send-Init packet and the Ack to the Send-Init must always be sent using the single character checksum, since the other Kermit does not know what to expect. This should probably be spec'ed this way even if both Kermit's allow a SET of the block check type. The protocol manual currently seems to imply this, but does not specifically state it. ------- ------- 20-Sep-83 16:28:22-EDT,685;000000000000 Return-Path: <@CUCS20:knutson@utexas-11> Received: from CUCS20 by CU20B with DECnet; 20 Sep 83 16:28:14 EDT Received: from UTEXAS-11.ARPA by COLUMBIA-20.ARPA with TCP; Tue 20 Sep 83 16:27:56-EDT Date: Tue, 20 Sep 83 15:25:03 CDT From: Jim Knutson Subject: DEC-20 Kermit chksum processing Posted-Date: Tue, 20 Sep 83 15:25:03 CDT Message-Id: <8309202027.AA12153@UTEXAS-11.ARPA> Received: by UTEXAS-11.ARPA (3.326/3.7) id AA12153; 20 Sep 83 15:27:01 CDT (Tue) To: info-kermit@columbia-20 Our version of DEC-20 kermit (version 3(40)) does not send a NAK upon receipt of a packet with a bad checksum. Is this the latest version or has this been fixed? 20-Sep-83 19:57:33-EDT,1105;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 20 Sep 83 19:57:30 EDT Date: Tue 20 Sep 83 19:57:09-EDT From: Frank da Cruz Subject: Re: DEC-20 Kermit chksum processing To: knutson@UTEXAS-11.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Jim Knutson " of Tue 20 Sep 83 16:28:11-EDT 3(40) is a relatively old version of Kermit-20. A while back, I too discovered that it did not NAK a bad packet, but rather, just waited for the other side to time out and send it again. This can slow things down a lot if the line is noisy. Thticuission has been corrected, and some other minor bugs fixed in rdays version of KERMIT-20 available online at COLUMBIA-20 (as KER:20KERMIT.*) does not yet contain these fixes, but it is considerably ahead of 3(40) -- it's 3A(62), which has a lot of new debugging features, etc. A new version that NAKs bad packets immediately and also includes the features mentioned in "KRFC #1" plus some new server functions will be announced shortly. - Frank ------- 21-Sep-83 21:29:01-EDT,2586;000000000001 Return-Path: <@CUCS20:OC.WBC3@CU20B> Received: from CUCS20 by CU20B with DECnet; 21 Sep 83 21:28:56 EDT Received: from CU20B by CUCS20 with DECnet; 21 Sep 83 21:30:52 EDT Date: Wed 21 Sep 83 21:28:26-EDT From: Bill Catchings Subject: Re: KRFC #3 To: cc.fdc@CUCS20, Info-Kermit@CUCS20 cc: cc.fdc@CUCS20 In-Reply-To: Message from "Frank da Cruz " of Mon 19 Sep 83 11:40:44-EDT As far as I can see there are two problems being addressed here. Correct me if I am wrong. The first is the ability to use "ITS binary" files that are usable by MODEM, etc. This is only really of value on the system or systems that presently use that format (I assume only some Tops-10 sites.) If this is important enough, I guess that ability could be built in. The second question is the general one of how to destinquish between "binary" (8-bit) files and ASCII (7-bit) files on the DEC-20 or DEC-10. The method presently used on the -20 for downloading (as explained by Frank da Cruz) takes care of things quite well. The problem is that uploading requires some sort of manual intervention. On the -20 the solution is straight-forward, but possibly expensive of computer resourses in the worst case. In most cases however, it should be fine. I shied away from doing this in the past, but maybe I was wrong. The thing to do is that unless the user specifies other- wise (forcing either a 7-bit or 8-bit file) Kermit-20 should assume that the file is 7-bit and proceed. If at any time (which is what could be costly) during the transfer a byte with the 8th bit on is detected the file is remapped in and changed to 8-bit. The transfer then continues in 8-bit. The flaw of course is that a 100 page file might have just the last byte in 8-bit. The previous hundred pages must now be gone through and changed to 8-bit. In general, this will not happen, I would think that in almost all cases the 8th bit should be turned on before the first page is even mapped out. There is one other case that is also possible that must be watched for. This does not change what was said before, but just makes the check for "8-bitness" a little bit tougher. You must treat an 8th bit in line numbers different. If this is the bit found, the file stays in 7-bit mode. This already works fine, so if some CP/M file just happened to have only those bits on, it should not cause a problem. I don't know how this would work under Tops-10, but a similar scheme should be possible. What do you think? -Bill Catchings ------- 22-Sep-83 20:22:03-EDT,1874;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 22 Sep 83 20:21:59 EDT Date: Thu 22 Sep 83 20:23:58-EDT From: Frank da Cruz Subject: New UNIX Kermit To: Info-Kermit@CUCS20 Bob Cattani of the Columbia CS Department has merged the various changes, suggestions, and bug fixes to Unix Kermit into a single source program, and has tested it thoroughly under 4.1bsd (talking to itself and to TOPS-20). It is now available to the ARPAnet community for testing via anonymous FTP of the files KER:CKERMIT.* from host COLUMBIA-20. CKERMIT.C is the source program, with conditionals added for various non-Berkeley Unix variants; CKERMIT.CHANGES lists all the changes from the present KERMIT.C (I'm not sure if it lists the infamous wildcard send bug, in which all but the first file came out null, but that's fixed too), and CKERMIT.MAN is the Unix man page. Thanks to W Underwood at Ford Aerospace for the man page and the non-Berkeley support, to Jim Guyton at Rand for some bug fixes and suggestions, and to others on this list who reported problems in the past. This new release does not incorporate any major new functionality, like server operation, CRC's, etc. All that will come later, once we get reports back from some other sites that tell us that we have a solid base to work from. Users of UNIX Kermit are urged to try out the new versions and report any problems or suggestions (or indeed, any success) to us. Here's a very quick summary of the changes: Ifdef'ed to work on v6/PWB, v7, and Onyx System III, as well as 4.1bsd. . Major efficiency improvements. . 2-character user-settable escape sequence for terminal connection. . Filename case conversion and deletion of Unix pathname. . Debugging capability enhanced. . Many cosmetic changes to the code. - Frank ------- 26-Sep-83 16:04:30-EDT,3607;000000000001 Return-Path: <@CUCS20:WANCHO@SIMTEL20.ARPA> Received: from CUCS20 by CU20B with DECnet; 26 Sep 83 16:04:14 EDT Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Mon 26 Sep 83 15:25:57-EDT Date: 26 Sep 1983 13:24 MDT (Mon) From: WANCHO@SIMTEL20.ARPA To: Frank da Cruz Cc: INFO-KERMIT@COLUMBIA-20.ARPA Subject: KRFC #3 Frank, I *think* you *may* have missed some critical points: 1. Yes, it is true, I do consider the mainframes as store-and-forward devices, rather than the other way around, but see below. And, to smooth the mainframe end out, w.r.t. non-ASCII files, my proposal was designed to provide an unambiguous, machine-independent means to determine if the stored file is non-ASCII. Of course, it is up to the user to declare to the storage process that the file is non-ASCII. The reason for this came up when we were FTPing ITS Binary files from MC, and the files were stored "incorrectly" - i.e., the FCB was a misleading (36), instead of (8) or (7), and MODEM attempted to then download the file as its default - an ASCII file. What does KERMIT do in this case? 2. The "DSK8" in SIXBIT must be an unfamiliar term. The entire first 36-bit PDP-10 WORD is occupied by the characters DSK8, six bits per character. That is why I referred to its transformation in an 8-bit/32-bit machine, which will NOT end up being "DSK8". This "word" is only seen by the program on the mainframe and, and is NEVER transferred - only used to determine that, if it is there, the file MUST be in "ITS Binary" format. 3. The reason for bothering with ITS Binary format at all, is not "just" for the PDP-10 world; it is for those others who need to communicate with the PDP-10 world. For example, when such a file is FTP'd to a UNIX site from here, people have devised procedures to pre-strip that "DSK8" - now transformed to four 8-bit bytes, and then download. Wouldn't it be nice if the downloading program took care of that automatically? How are file types determined on Unix machines? Are *all* files assumed to be binary or ASCII? Must the download user explicitly declare the assumed transfer mode? For each file? If so, then THAT is even more prone to error than depending upon just the uploader to to get it right! 4. The ^C padding is done by the system - not the user program - and that is an ITS convention that I'm not sure migrated to TOPS-20. Funny you should ask about storing PDP-10 .EXE or .REL files, and using the micro as the store-and-forward device. After we brought up this machine earlier this year, there was a considerable and unexpected delay in getting connected to the net. Gail Zacharias (GZ@MC) devised a pair of programs for me, named BYTIFY and UNBYTIFY, that respectively convert *any* PDP-10 file to ITS Binary Format, and back. I used these programs to get many files off the net and into my DEC, including two full sets of the MM system while we were waiting! I will put the sources of those files along with the others of interest already in [SIMTEL20]MICRO:, such as MODEM, CRC, TYPESQ, USQ, and UNARI. MODEM is in MACRO, all the others are in MIDAS. (At one point, there was also going to be an LU20 to handle .LBR files - in ITS Binary, of course...) BOTTOM LINE: I would be content if KERMIT20 would automatically recognize ITS Binary format, and begin the file transfer with the SECOND PDP-10 word on download. It would be even nicer for the other KERMITs to do something similarly appropriate for their machines. --Frank 26-Sep-83 16:07:30-EDT,3383;000000000001 Return-Path: <@CUCS20:SY.FDC@CU20B> Received: from CUCS20 by CU20B with DECnet; 26 Sep 83 16:06:50 EDT Received: from CU20B by CUCS20 with DECnet; 26 Sep 83 16:07:29 EDT Date: Mon 26 Sep 83 16:01:08-EDT From: Frank da Cruz Subject: Unix Kermit for Amdahl UTS To: Info-Kermit@CUCS20 Did anyone try out the new Unix Kermit yet? We tried it out at Columbia on our IBM 4341 mainframe running Amdahl UTS (= Unix) and found a few changes were necessary. Will any of the changes described below adversely effect other Unixes? I'd welcome any Unix site trying this version and reporting success or failure with it. It's available on COLUMBIA-20 as KER:UKERMIT.C (same as CKERMIT.C except with fixes for UTS added), via anonymous FTP. - Frank --------- Received: UVMA20B with HASP; 26 Sep 83 15:22:25 EDT From: Alanwell at CUUTSA> Date: 26 Sep 1983 15:21:55-EDT Sender: UNIXA at CUVMB To: sy.fdc Subject: Kermit UTS changes Cc: sy.daphne@cu20b Frank, Following is the differences file for UTS. In a following letter will be the source. I've made llowanges: 1) Removed IBM_UTS system type. 2) NO_UP #define along the lines of the other UNIX tailoring #defines. 3) Changed a char to an int to make (t = getc(ttyfd)) return -1 on EOF instead of 255 (-1 trunc'd to 8 bits). 4) an call in printmsg to make messages come out when they are printed. 5) Added a read() in rpack() to eat the eol character, if this isn't thcharacter is the next character read by the shell when kermit ends. This has no effect for other Unix kermits since they use \n for the eol character and simply see an extra newline as if the user typed a cr. However, UTS kermit sees a \r which it doesn't understand as newline because the tty was in raw mode when the character came in. points 3-5 should work equally well on other systems, so I didn't bracket them within a #if. 32d31 < #define IBM_UTS 0 /* Amdahl UTS on IBM systems */ 34a34 > /* For Amdahl UTS, need to set NO_FIONREAD, NO_TANDEM, and NO_NLWAKEUP */ 37,38c37,39 < #define NREA /* No ioctl(FIONREAD,...) for flushinput() */ < #define NO_TANDEM 0 /* No TANDEM line discipline (xon/xoff) */ --- > #define NO_FIONREAD 1 /* No ioctl(FIONREAD,...) for flushinput() */ > #define NO_TANDEM 1 /* No TANDEM line discipline (xon/xoff) */ > #define NO_NLWAKEUP 1 /* Read does not wake up on NL -- need CR (U TS) */ 68a70,72 > #if UNIX&NO_NLWAKEUP > #define MYEOL '\r' /* End-Of-Line character I need is */ > #else 69a74 > #endif /* UNIX&NO_NLWAKEUP */ 901c906 < char chksum, t, type; /* Checksum, current char, pkt type */ --- > char chksum, t, type, temp; /* Checksum, current char, pkt type */ 947a953 > read(ttyfd,&temp,1); /* get EOL character and toss it */ 988c994 < char /* Char read from file */ --- > int t, /* Char read from file */ 1187a1194 > fflush(stdout); /* make it print now */ ------- 26-Sep-83 18:11:00-EDT,5517;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 26 Sep 83 18:10:48 EDT Date: Mon 26 Sep 83 18:12:09-EDT From: Frank da Cruz Subject: Re: KRFC #3 To: Info-Kermit@CUCS20 In-Reply-To: Message from "WANCHO@SIMTEL20.ARPA" of Mon 26 Sep 83 13:24:00-EDT About ITS binary format -- I think we understand each other OK. Since Kermit doesn't want to make any assumptions about whether the mainframe disk is an archive for the micro or vice versa, I think we can cover all the bases if we allow -- as you suggest -- handling of ITS binary files by Kermit-20 (and I guess Kermit-10 also), but we don't require it. I'd suggest a parameter in Kermit-10/20 that enables/disables the feature, which can be selected on a site-wide basis (say, as an assembly parameter), and then overriden on an individual basis (with a SET command). How does this sound: If ITS-binary-format handling is disabled, then behave as before, i.e. don't pay any special attention to the contents of the file. If enabled, then: - For outgoing files, if the first word is SIXBIT/DSK8/, don't transmit the first word. - For incoming files, if the first 4 characters are DSK8, then store the file in 8-bit mode, even if the prevailing mode is 7-bit (would any system ever actually send a binary file this way?) Recall that if Kermit-10/20 knows that the incoming file is 8-bit-binary (that is, if you have said "SET FILE-BYTESIZE 8") then the file will be stored that way, i.e. four 8-bit bytes left justified in each 36-bit PDP-10 word. If you didn't say "SET FILE-BYTESIZE 8", then the incoming file will be assumed to be text (or PDP-10 binary, which is treated the same way, see below) and the 8th bit will be lost from each byte, and the remaining 7-bit bytes will be stored left justified, 5 to a word. Not to beat a dead horse, but since all files - text and binary - are stored in a uniform way on a CP/M (or MS DOS, or ...) disk, but are stored differently on the PDP-10's disk, then if you want to send a file FROM a micro TO a DEC-20, you must tell one side or the other whether the file is binary or text. If you tell the micro, then it can send out DSK8 as the first 4 characters of the file; if you tell the DEC-20, then it knows to store the file in 8-bit mode. Since the file will be stored in 8-bit mode in either case, there is no point storing the DSK8 header word with the file -- the DEC-20 will know to read 8-bit bytes rather than 7-bit bytes when sending the file out. On the other hand, if there happens to be an ITS binary format file sitting around for some reason, then KERMIT will not bother to transmit the first word. Actually, the story may be somewhat different with respect to TOPS-10 (anybody want to address the question? For instance, can Kermit-10 rely on the bytesize the same way Kermit-20 can?). So much for binary files. I trust we all agree that TEXT files should be stored in whatever form is useful on the target system, in particular that microcomputer text files are stored in 7-bit format on the DEC-20, so that TYPE, PRINT, EDIT and similar commands work on them normally. On the DEC-20, no padding is necessary at the end; a byte count is kept in the FDB that tells exactly how long the file is. For symmetry, let me explain how KERMIT-10 and -20 deal with their own 36-bit- byte binary files. This is done using the same algorithm that the PDP-10 uses to write "ANSI ASCII" format tapes: the 36-bit words are sent as five 7-bit bytes, with the parity set to 0 on the first 4 bytes of each word, and the parity of the 5th byte set to the value of bit 35 of the word. Thus, DEC-20 users can "send *.*" to a micro, and then get all the files back again without ever bothering about whether a particular DEC-20 file is binary or text. This is admittedly a hack, but it does the job (and it's hard to imagine how to do it better). The upshot is that KERMIT-20 treats a file as 7-bit (with special handling for "bit 35") unless its bytesize is 8. And when the bytesize IS 8 (which is never used on DEC-20s except for foreign binary files), the file is read and sent correctly. About FTP -- I never used it between a DEC-20 and UNIX, but between two DEC-20s, FTP preserves the bytesize. That means that when I send a file out from the DEC-20, it tells the receiver in some way that the file is text (bytesize 7), "foreign binary" (bytesize 8), or "image" or "page" (bytesize 36, a special mode only for TENEX and TOPS-20). A receiving UNIX (or any other) FTP should be able to use this information to store the file correctly, without having to rely on the "DSK8" header. For Unix, it doesn't matter anyway, since it stores every incoming byte on the disk as an 8-bit byte -- all files are streams of 8-bit bytes to Unix; thus sending "DSK8" invokes no function on the Unix side other than discarding the "DSK8" (or am I missing something?). Anyway... (sorry to drone on at such length): BOTTOM LINE: I agree that KERMIT-20 should have the ability to recognize ITS binary format, and begin the file transfer with the second PDP-10 word on download, and whatever can be done along similar lines for KERMIT-10 should also be done. However, I don't think KERMIT-20 (or -10) should ever actually have to CREATE ITS format binary files, since the same information is recorded in the file bytesize. Agreed? - Frank ------- 27-Sep-83 10:41:09-EDT,745;000000000000 Return-Path: <@CUCS20:knutson@utexas-11> Received: from CUCS20 by CU20B with DECnet; 27 Sep 83 10:41:01 EDT Received: from UTEXAS-11.ARPA by COLUMBIA-20.ARPA with TCP; Tue 27 Sep 83 10:41:43-EDT Date: Tue, 27 Sep 83 09:35:43 CDT From: Jim Knutson Subject: Naming conventions in the area Posted-Date: Tue, 27 Sep 83 09:35:43 CDT Message-Id: <8309271440.AA00544@UTEXAS-11.ARPA> Received: by UTEXAS-11.ARPA (3.326/3.7) id AA00544; 27 Sep 83 09:40:17 CDT (Tue) To: info-kermit@columbia-20 Would it be possible to include the version number of the program in the filename? It is hard to know which version (.MAC, .NEW, .TST) is the latest version when FTPing files from the area on Columbia. 27-Sep-83 14:22:57-EDT,1430;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Sep 83 14:22:47 EDT Date: Tue 27 Sep 83 14:22:38-EDT From: Frank da Cruz Subject: Re: Naming conventions in the area To: knutson@UTEXAS-11.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Jim Knutson " of Tue 27 Sep 83 10:41:59-EDT Things could be better with regard to naming conventions. The present scheme (what there is of it) is to group files pertaining to the same machine or operating system together by prefix (files are arranged alphabetically within a directory on a DEC-20), with names being no longer than 9.3 to avoid confounding any VMS system, and unique within 6.3 to avoid conflicts on TOPS-10 systems. As to the .NEW, .TST, NEWFOO.BAR, ... business, you're right -- there should be some more standard way of having new or test versions of programs coexist with older ones. The best way around all the problems would be to organize the KERMIT distribution area into subdirectories, which I will do once I have determined that all common file access methods will not be tripped up by this. Presently, KERMIT itself does ok; NFT/FAL (the DECnet file transfer system) fails; I haven't yet tested FTP to see how it might be affected. The old vs new problem would be alleviated somewhat if FTP directory listings included the date, but... - Frank ------- 27-Sep-83 21:43:59-EDT,905;000000000000 Return-Path: <@CUCS20:DBrown@HI-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 27 Sep 83 21:43:57 EDT Received: from HI-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 27 Sep 83 21:44:54-EDT Date: 27 September 1983 20:40 est From: DBrown.TSDC at HI-MULTICS Subject: Naming conventions To: info-kermit at COLUMBIA-20 For a good discussion on this whole basket of worms, get a copy of "A View of Source Text for Diversely Configurable Systems", from the Mathematics Facility, University of Waterloo, Waterloo, Ontario, Canada. This is a tech report by Tom Cargill (now of Bell Labs) on how to keep things straight when you're trying to keep 5 versions of a portable operating system (Thoth) and all its utilities on a rather small mini. It's one of those "its obvious, why didn't I think of it" papers that crop up every so often... --dave (I thorta like Thoth) brown 28-Sep-83 17:35:30-EDT,8146;000000000001 Return-Path: <@CUCS20:GZ@MIT-OZ> Received: from CUCS20 by CU20B with DECnet; 28 Sep 83 17:35:20 EDT Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Wed 28 Sep 83 17:36:44-EDT Date: Wed, 28 Sep 1983 04:30 EDT Message-ID: <[MIT-OZ].GZ.28-Sep-83 04:30:13> From: Gail Zacharias To: Info-Kermit%COLUMBIA-20@MIT-MC.ARPA cc: WANCHO%SIMTEL20@MIT-MC.ARPA Subject: [WANCHO@SIMTEL20.ARPA: KRFC #2 and #3] In-reply-to: Msg of 28 Sep 1983 00:36-EDT from Gail Zacharias I'm not on this list, but since I was one of the people involved in setting up the "ITS binary file format" on ITS, and maintain a number of programs which take advantage of it, Frank Wancho forwarded these messages to me. I'm not familiar with Kermit, but I have some general comments and clarifications to make. Date: 16 Sep 1983 18:52 MDT (Fri) From: WANCHO@SIMTEL20.ARPA Each 128-byte record was stored as-is, without any trailing padding, except for padding out the last 36-bit word with ^Cs. This is not true for binary files. There is no padding at end of file, since each record takes exactly 32 complete words. ASCII files were stored as normal ASCII files, except the last record, containing one or more ^Zs (the CP/M EOF) was stored without the ^Z(s) and beyond. The normal convention of padding out with one or more ^Cs to fill a 36-bit word was used. The ^C's in ascii file are an artifact of the ITS file system. They are ITS's EOF markers, and all ITS programs know how to deal with them. TOPS-20 has a different format for setting EOF (a byte count in the FDB) which all TOPS-20 programs know how to use. I suggest that the protocol only state that for ascii files, the CPM eof mark be replaced by the receiving operating system's standard EOF convention. Date: Mon 19 Sep 83 11:39:49-EDT From: Frank da Cruz what if an ASCII text file on the micro happens to start with the ASCII characters "DSK8"? The identifier word is DSK8 in sixbit, not ascii. Interpreted as PDP-10 ascii, it is the five characters I N [ ^@ ^@, where ^@ means NULL, ascii code 0. Very few PDP-10 ascii files have nulls in them. On an 8-bit system (Unix, VMS, etc.) it is the four bytes 93H 3AH D8H 00H, two of which have the high bit on. Either way there is very little chance of an ascii file starting this way. There might be binary files which genuinely start this way. Which might be a good reason to decide to either put the prefix on all stored binary files, or none of them. The proposed method would allow binary and text files to be mixed in a batch during uploading. I guess it depends on your point of view, but to be precise: the method allows PDP-10's to automatically determine the format of a local disk file. As such, it is helpful when downloading from a 10. That's all. All the other stuff is just to allow files to be FTP'ed between systems and still win - see below. After all, the whole point of a standard is to allow for easy communication between systems. If everybody is only concerned about their own machine, there is no need for a standard. I assume that the proposed standard would only affect PDP-10s and other systems that would store characters in 7-bit bytes (thus losing the 8th bit) unless explicitly directed otherwise; systems like IBM VM/CMS, UNIX, VAX/VMS, etc, would not have to bother with ITS binary format. Right? No. Since binary files FTP'ed from PDP-10's to IBM/UNIX/VMS sites would start with those leading bytes (93H 3AH D8H 00H), it would be important for everybody to understand them. Especially since a major source of CP/M software on the net will be SIMTEL20, a PDP-10. In situations where a Unix etc. doesn't care whether the file is binary or not, all it need do is strip those four bytes if it finds them. In those cases where it might like to know, it might use them to determine binariness, in place of requiring the user to specify a -b switch, if it wishes. But that's a user-interface issue not really relevant here. All the proposal would require is that the bytes be recognized and stripped before downloading (unless the user specifies not to, presumably - again a separate user interface issue). As to binary files, I see two possible problems with the proposal. First, since the FCB contains no information about whether the file is binary or ASCII, the micro side of the file transfer protocol must make that determination, either by asking the user, or by observing certain filetype conventions; either method is prone to error, and these will tend to affect the less sophisticated user. This is irrelevant. I'm not familiar with Kermit, but I'm sure there have to be ways to specify/guess that a file is to be stored as binary on a PDP-10, since storing it as ascii would destroy it. It's not an easy problem, but has nothing to do with the proposal. All the proposal says is that once it is determined, in whatever way, that the file should be stored as binary, Kermit should store the identifier before the data so that future attempts to download the file can do the right thing automatically. This should remain true even after the file is FTP'ed to another system, and for this reason even 8-bit systems like Unix or VMS should store the identifier on upload. And conversely, this should remain true even if the file is FTP'ed from another system, and for this reason Unix and VMS should recognize the identifier before download. Second, although SIG/M and CPMUG volumes are stored in the proposed format, there may be other sites that have similar databases stored in other formats; would they have any objection to the proposed change? Well, if they don't convert, attempting to download them will require the user to explicitly specify which files are binary and which are ascii, as the system will not be able to determine this automatically. It could then either assume they are ascii, or use whatever method it used in the pre-KRFC3 days. Presumably a user can state his preference through a command or switch. Of course the user will need to know he's dealing with such files, and he'll need to know the format of each. Enough users might complain to prompt the database maintainers to comply with the standard. When sending files back to the micro, the DEC-10 or -20 is capable of picking up the bytesize from the file's directory entry and sending it appropriately; No, the bytesize in the FDB is unreliable. In particular transfering a file over the arpanet or chaosnet in the most efficient way will clobber the byte size to 36. Date: Mon 26 Sep 83 18:12:09-EDT From: Frank da Cruz To: Info-Kermit at COLUMBIA-20.ARPA Re: KRFC #3 - For outgoing files, if the first word is SIXBIT/DSK8/, don't transmit the first word. Even more to the point, if the first word is SIXBIT/DSK8/, interpret the rest of the words as 8 bit bytes. On 8-bit systems, if the first four bytes are 93H 3AH D8H 00H, ignore them. (There should be a user command to say not to do that on a particular transfer). - For incoming files, if the first 4 characters are DSK8, then store the file in 8-bit mode, even if the prevailing mode is 7-bit (would any system ever actually send a binary file this way?) I don't think this was the intention of the proposal. Since it's hard for a micro to determine how the file should be stored on the mainframe, it doesn't make much sense for it to be making the decision (a PDP-10 can check a file for 8th-bit-set faster than you can blink an eye). But in any case, all that's being proposed is that however binariness is determined, "storing the file in binary mode" on a mainframe would be DEFINED to mean prefixing the data with SIXBIT/DSK8/ on a 10 or 93H 3AH D8H 00H on an 8-bit system. 29-Sep-83 12:15:30-EDT,2655;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 29 Sep 83 12:15:21 EDT Date: Thu 29 Sep 83 12:16:14-EDT From: Frank da Cruz Subject: Re: KRFC #3 (ITS Binary Format) To: GZ%MIT-OZ@MIT-MC.ARPA, Info-Kermit@CUCS20 cc: WANCHO%SIMTEL20@MIT-MC.ARPA In-Reply-To: Message from "Gail Zacharias " of Wed 28 Sep 83 17:37:06-EDT Although ns about ITS binary format made it to the mailing list, sentiments seem to be running strongly both in favor of it and against it. To make both camps happy, let's make KERMIT-20 (I won't mention KERMIT-10; its makers should comment if they have any objection) support of ITS binary format work as follows: 1. Outgoing files: Handling of ITS binary format will be OPTIONAL, with the default specifiable by the site manager, and overridable by the user. a. If trd of the file is SIXBIT/DSK8/, then: i. If ITS format is selected, the first word will not be transmitted, and the file will be read from the disk in 8-bit mode, regardless of the byte size indicated in the FDB. ii. If ITS format is not selected, the entire contents of the file will be transmitted, with bytes fetched from the file according to the byte size given in the FDB: 8 bit bytes if the FDB says 8; 7 bit bytes otherwise, with b8 of every 5th byte set to the value of b35 from the PDP-10 word it came from. b. If the first word is not SIXBIT/DSK8/, then the file will be sent according to the bytesize in the FDB, as above. 2. Incoming files: ITS binary format handling is an option, as above. a. If ITS binary format handling is enabled, then: i. If the first 4 characters of the file are 93H 3AH D8H 00H, then store the it DSK8 header in 8-bit bytes, and set the file byte size in the FDB to 8. Do this regardless of the prevailing output file bytesize setting. ii. If the first 4 characters of the file are anything else, then store the entire contents of the file according to the prevailing output bytesize. b. If ITS binary format handling is not enabled, store the incoming file according to the prevailing output file bytesize setting. I believe this will allow any conceivable style of transmission and storage to work; for instance, you can use KERMIT-20 to operate automatically on any mixture of ITS binary, text, and 8-bit binary (without header) files. You can send files with or without the header, etc. Any objections? - Frank ------- 29-Sep-83 15:19:50-EDT,3098;000000000001 Return-Path: <@CUCS20:OC.GARLAND@CU20B> Received: from CUCS20 by CU20B with DECnet; 29 Sep 83 15:19:42 EDT Received: from CU20B by CUCS20 with DECnet; 29 Sep 83 15:21:02 EDT Date: Thu 29 Sep 83 15:14:57-EDT From: Richard Garland Subject: Re: KRFC #3 (ITS Binary Format) To: cc.fdc@CUCS20 cc: GZ%MIT-OZ%MIT-MC@COLUMBIA-20.ARPA, Info-Kermit@CUCS20, WANCHO%SIMTEL20%MIT-MC@COLUMBIA-20.ARPA, OC.GARLAND@CU20B In-Reply-To: Message from "Frank da Cruz " of Thu 29 Sep 83 12:15:32-EDT Several comments on the BINARY/ASCII ITS issue: There are two real concerns I believe: How to interpret the proper mode (i.e. bytesize, BINARY vs. ASCII) of a file already resident on a host, presumably so it can be transmitted correctly. "How to know what you got." and How the reciever of a file can be told the type of file and how to store it. "How to tell the other guy." ITS-binary format is aparently an attempt to solve the first issue on DEC-10's running various operating systems. Other systems attempt to solve it in other ways: viz. the bytsize in the file header on Tops-20. Other systems don't care (ie. VMS, Unix, IBM) since there is no mismatch between bytes and words - just save everything as 8 bit bytes and Binary and ASCII are equivalent. CPM systems tend to be in the later category. On the second issue, generally Kermit and other protocols tend to guess or ask the user the best way to transmit. Aparently FTP defaults to 36 bit mode between 36 bit machines no matter what the undelying convention is (i.e. whether ITS-binary is in affect or if the bytesize is set on Tops-20). This can be overridden by the user. My suggestions for Kermit conventions are as follows: Let each operating system and Kermit decide how best to store a file and "remember" its mode. Define a Kermit protocol code so a sending kermit can tell a recieving Kermit the mode. It can derive this information from the file system, the header, the user, the file type convention or anywhere it pleases. The receiver can similarly save this information according to its local convention. The protocol could specify the mode as ASCII/ BINARY/DONT KNOW/DONT CARE etc. or perhaps 7BIT/8BIT/DONT KNOW/DONT CARE etc. Make it open ended to accomodate things we havn't thought of. Bottom line ----------------------------------------------------------------- 1. Define a kermit protocol packet to tell a recieving host the mode of the file. 2. Let each host remember this mode however it likes. 3. Accomodate ITS-binary on option on 36-bit machines. This can simply be a special case of point 2. and can be done as Frank da Cruz suggests. 4. DO NOT adopt ITS-binary conventions as Kermit transmission conventions. Point 1. is a cleaner and less error prone method. Thus although you may want to STORE the mode information in the file itself (as ITS does) you don't want to depend on the file contents as a means for Kermit to transmit special information. Rg ------- 30-Sep-83 10:39:23-EDT,2330;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Sep 83 10:39:10 EDT Date: Fri 30 Sep 83 10:39:53-EDT From: Frank da Cruz Subject: Re: KRFC #3 (ITS Binary Format) To: OC.GARLAND@CU20B cc: GZ%MIT-OZ%MIT-MC@CUCS20, Info-Kermit@CUCS20, WANCHO%SIMTEL20%MIT-MC@CUCS20, OC.GARLAND@CU20B, cc.fdc@CUCS20 In-Reply-To: Message from "Richard Garland " of Thu 29 Sep 83 15:21:19-EDT Unfortunately, it's a little late in the game for changing the protocol in such a fundamental way by adding file attribute information for each file. More to the point, however, there's probably no good way of doing this. Consider, for instance, just a PDP-10 and a CP/M-80 system. We want the sender to tell the receiver whether a file is binary or text. The PDP-10 sends a text file. The micro stores it according to its own convention (^Z in the last block to mark the EOF). Then the PDP-10 sends a 36-bit binary file. The micro stores it exactly the same way. Telling the micro that this file is binary does no good at all, because it has no other way to store files. To send these files back to the PDP-10 correctly, the user must tell the micro which is which; otherwise the micro might stop sending the PDP-10 binary file before the end (e.g. if there happened to be a ^Z among the data in the last block). And even then we have to distinguish between PDP-10 binary files (which could end anywhere in the last block) and CP/M binary files, which include the entire last block. Even if we knew how to correctly distinguish the end of file on these two kinds of binary files, we'd have to tell the PDP-10 that the PDP-10 binary file was a TEXT file, so it would be stored in 5 7-bit bytes per word (plus the bit 35 trick) rather than 4 8-bit bytes, whereas the CP/M file would have to be stored in 8-bit bytes. These are just SOME of the complications that arise between a SINGLE PAIR of systems. When you try to forsee the complications that can arise between ANY pair of systems, you are hard pressed to account for them in a simple protocol. Consider that DECnet Data Access Protocol, for all its unbelievable hairiness, can still only manage to transfer sequential ASCII files between a PDP-10 and a VAX... - Frank ------- 1-Oct-83 04:04:02-EDT,543;000000000000 Return-Path: <@CUCS20:Elmo@MIT-OZ> Received: from CUCS20 by CU20B with DECnet; 1 Oct 83 04:03:59 EDT Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Sat 1 Oct 83 04:05:03-EDT Date: Sat, 1 Oct 1983 04:03 EDT Message-ID: <[MIT-OZ].GREN.ELMO. 1-Oct-83 04:03:41> To: info-kermit%COLUMBIA-20@MIT-MC.ARPA Cc: Elmo@MIT-OZ From: Eliot R. Moore Reply-to: Elmo%Mit-Oz@Mit-ML Subject: Commodore Kermit Sender: Elmo@MIT-OZ Has anyone implemented Kermit on the Commodore 64? Pointers a Regards, Elmo 1-Oct-83 16:52:56-EDT,860;000000000000 Return-Path: <@CUCS20:jalbers@BNL> Received: from CUCS20 by CU20B with DECnet; 1 Oct 83 16:52:52 EDT Received: from BNL by COLUMBIA-20.ARPA with TCP; Sat 1 Oct 83 16:53:54-EDT Date: 1-Oct-83 16:51:56-EDT From: jalbers@BNL Subject: Kermit for the Osborne Executive To: info-kermit@COLUMBIA-20 I'm sorry to open old wounds, but after following all instructions, including setting the modem port to AUXIN/AUXOUT, and it still won't work!!! It starts up, and even goes into terminal mode correctly, but it will not talk to the modem port. Has anyone got Kermit working??? Pls help me!!! I cannot get it up at all, and soon I will not have a host that will let me download via MODEM7. Jon Albers jalbers@bnl 1-Oct-83 19:55:51-EDT,686;000000000001 Return-Path: <@CUCS20:DBrown@HI-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 1 Oct 83 19:55:47 EDT Received: from HI-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Sat 1 Oct 83 19:56:48-EDT Redistributed-Date: 1 October 1983 18:49 est Redistributed-By: DBrown.TSDC at HI-MULTICS Redistributed-To: Info-Kermit at COLUMBIA-20 Redistributed-Date: 30 September 1983 19:29 cdt Redistributed-By: RLee.SysAdmin at HI-MULTICS Redistributed-To: DBrown.TSDC at HI-MULTICS Date: 29 September 1983 15:03 est From: DBrown.TSDC at HI-MULTICS Subject: Re: KRFC3 (Binary Format) To: Info-Kermet at COLUMBIA-20 Re: Richard Garlands suggestion. Hear hear! -- dave 3-Oct-83 11:33:28-EDT,1105;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 3 Oct 83 11:32:56 EDT Date: Mon 3 Oct 83 11:33:33-EDT From: Frank da Cruz Subject: New 8085/Z80 cross assembler To: Info-Kermit@CUCS20 cc: BBoard@CUCS20 A new release of the MAC80 cross assembler from Bruce Tanner at Cerritos College is available for testing. The previous version assembled only 8080 or 8085 code; the new version also will assemble Z80 code. It has been tested here on the CP/M Kermit source, and it works for that. Does anyone have any Z80 programs they'd like to cross-assemble? The new version is in KER:ZAC80.EXE at host COLUMBIA-20. A new manual is available as KER:ZAC80.DOC. A "torture test" for the Z80 support is in KER:ZORTUR.MAC. If no problems are reported within a week or two, the new version will replace the old MAC80; meanwhile, both versions coexist in the KER: area -- the old in files starting with M, the new one in files starting with Z. Please send any comments directly to me, and I'll forward them to the author. - Frank ------- 3-Oct-83 11:45:08-EDT,751;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 3 Oct 83 11:45:03 EDT Date: Mon 3 Oct 83 11:36:41-EDT From: Frank da Cruz Subject: Re: Commodore Kermit To: Elmo%Mit-Oz@MIT-ML.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Eliot R. Moore " of Sat 1 Oct 83 04:05:10-EDT No one has implemented Kermit on the Commodore 64, to my knowledge. A number of people on the systems staff at Columbia have got these machines, and one of them might break down and do it as a spare time project, but if someone else wants to try it first, please do. If you have a DEC-10 or -20, you can work from the Stevens Apple Kermit, written in CROSS language for the 6502. - Frank ------- 3-Oct-83 12:11:06-EDT,643;000000000000 Return-Path: <@CUCS20:CC.DAPHNE@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 3 Oct 83 12:10:44 EDT Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Mon 3 Oct 83 12:11:36-EDT Date: Mon 3 Oct 83 12:10:07-EDT From: Daphne Tzoar Subject: Re: Commodore Kermit To: Elmo%Mit-Oz@MIT-ML.ARPA cc: info-kermit%COLUMBIA-20@MIT-MC.ARPA, Elmo%MIT-OZ@MIT-MC.ARPA In-Reply-To: Message from "Eliot R. Moore " of Sat 1 Oct 83 04:05:11-EDT A few people have said they would write a Commodore 64 version of Kermit. So far, though, I haven't heard any more about it. /daphne ------- 3-Oct-83 20:18:29-EDT,559;000000000000 Return-Path: <@CUCS20:HOWALD@USC-ECLB> Received: from CUCS20 by CU20B with DECnet; 3 Oct 83 20:18:26 EDT Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Mon 3 Oct 83 20:19:26-EDT Date: 3 Oct 1983 1713-PDT From: HOWALD Subject: Telenet connections To: info-kermit@COLUMBIA-20 Has anyone on the net tried to use KERMIT over Telenet with success? I can't get it to run over Telenet--the initial packet transfer is never successful, so after 15 or 16 tries it gives up. Thanks in advance for any help or advice. ------- 4-Oct-83 00:47:40-EDT,1068;000000000000 Return-Path: <@CUCS20:OC.TREI@CU20B> Received: from CUCS20 by CU20B with DECnet; 4 Oct 83 00:47:35 EDT Received: from CU20B by CUCS20 with DECnet; 4 Oct 83 00:48:36 EDT Date: Tue 4 Oct 83 00:47:06-EDT From: Peter G. Trei Subject: Another Commodore enthusiast... To: Info-kermit@CUCS20, elmo%mit-oz%MIT-MC@COLUMBIA-20.ARPA cc: mm24@CMCCTF, oc.trei@CU20B [Permanent Committee to Overthrow the Goverment Next Tuesday after Lunch] I pass on the following message from MM24@CMCCTD (one of CMU's deccnet nodes: mail routed thru CU ought to make it.) 1-Oct-83 02:32:20-EDT,389;000000000001 Return-Path: Received: from CMCCTD by CU20B with DECnet; 1 Oct 83 02:32:13 EDT Received: ID ; 1 Oct 83 02:30:13 EDT Date: 30 Sep 83 21:01:10 EDT From: MM24@CMCCTD To: oc.trei@CU20B Subject: Kermit I own a Commodore-64: it has a 6502 equivilent. I'd be interested in the source for the Apple Kermit -Michael McInerny, CMU mm24@cmcctd -------- Peter Trei %cu20b@columbia-20 ------- 4-Oct-83 01:06:10-EDT,943;000000000000 Return-Path: <@CUCS20:OC.TREI@CU20B> Received: from CUCS20 by CU20B with DECnet; 4 Oct 83 01:06:06 EDT Received: from CU20B by CUCS20 with DECnet; 4 Oct 83 01:07:07 EDT Date: Tue 4 Oct 83 01:05:38-EDT From: Peter G. Trei Subject: Telenet & Kermit... To: info-kermit@CUCS20, howald%USC-ECLB@COLUMBIA-20.ARPA [Permanent Committee to Overthrow the Goverment Next Tuesday after Lunch] Telenet can be pretty flakey; unless you are sending datagrams the route taken by each packet is variable, and it is not unknown for packets to arrive out of sequence. Also, the response time is not too good: they claim an average of 1 second line turnaround time, but 10-15 seconds is not unknown. This might give you timeouts if you are using the defaults. Between 1 and 3 AM is especially bad since Burroughs (I think) uses it then for transfering BIG files. Peter trei oc.trei%cu20b@columbia-20 ------- 4-Oct-83 09:47:01-EDT,585;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 4 Oct 83 09:46:56 EDT Date: Tue 4 Oct 83 09:47:45-EDT From: Frank da Cruz Subject: Re: Telenet connections To: HOWALD@USC-ECLB.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "HOWALD " of Mon 3 Oct 83 20:13:00-EDT To use KERMIT over TELENET, you have to give the KERMIT command "SET PARITY MARK", in order to have KERMIT generate bytes with the parity that TELENET seems to insist upon, and to ensure that the checksums come out right. - Frank ------- 12-Oct-83 14:28:27-EDT,2446;000000000000 Return-Path: <@CUCS20:SY.FDC@CU20B> Received: from CUCS20 by CU20B with DECnet; 12 Oct 83 14:28:20 EDT Received: from CU20B by CUCS20 with DECnet; 12 Oct 83 14:28:22 EDT Date: Tue 11 Oct 83 19:30:45-EDT From: Frank da Cruz Subject: KRFC #5 To: Info-Kermit@CUCS20 Reply-To: CC.FDC@COLUMBIA-20 KERMIT RFC #5 -- "KERMIT Capabilities Word" In the Kermit Protocol Manual, it says that fields 10 and 11 of the Send-Init packet are reserved for future use, and that sites that wish to add new fields should start at field 12. To my knowledge, no site has added features requiring e ofew Send-Init fields (Cornell University long ago added checksum options, but these now have an "official" field in the Send- Init packet). Thus I propose (1) using these two fields as a "KERMIT Capabilities Word" (KCW), and (2) movingeserelds to positions 12-15. The capabilities word will be two six-bit quantities, whose bits tell whether the Kermit program sending the packet has or does not have the corresponding capability. The values for each field will be in the range 0-63, converted to printable characters by adding 32 (all numbers in decimal). 12 different capabilities may be thus signified. The capabi wilumbered 1 through 12, as follows: Field 10 (KCWA) Field 11 (KCWB) +----+----+----+----+----+----+ +----+----+----+-----+-----+-----+ | #1 | #2 | #3 | #4 | #5 | #6 | | #7 | #8 | #9 | #10 | #11 | #12 | +----+----+----+----+----+----+ +----+----+----+-----+-----+-----+ where the boxes represent bits in the 6-bit quantities, high order being the leftmost. e bialues (i.e. before addition of 32) of the two fields are "concad" t a 12-bit quantity A, then capability #n is on if A AND 2^(12-n) = 2^(12-n) The values of the quantity A may range from 0 to 4095. New capabilities will be added from left to right, so that Field 11 need not be included until Field 10 is used up (i.e. all the bits defined). If more than 12 capabilities need be defined, they can be included in subsequently allocated fields (in which case "12" in the formula above should be replaced by "m", where m is the number of capabilreprd). The operation of any pair of KERMITs with respect to any particular capability will be defined for each such capability. Comments, suggestions? ------- 12-Oct-83 19:13:45-EDT,7341;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 12 Oct 83 19:13:37 EDT Date: Wed 12 Oct 83 19:14:23-EDT From: Frank da Cruz Subject: KRFC #6, File Attributes To: Info-Kermit@CUCS20 The recent discussion of automatic recognition of binary versus text files has prompted the following proposal for sending file attributes along with a file. The previous proposal (KRFC #5) gave a mechanism that would allow this major change to be made to the KERMIT protocol without disturbing older KERMIT implementations that did not know about it. KERMIT RFC #6: File Attributes A major shortcoming of KERMIT is the inability of the sender of a file to provide the receiver with any information about the file other than its name. Here is an idea that will allow a certain number of attributes to be provided to KERMITs that are prepared to deal with this information. First, define Kermit Capability #1 to be the ability to send and receive a new packet type, "A" for Attributes. If both sides set this bit in the Kermit Capability Word, then the sender, after sending the filename in the "F" packet and receiving an acknowledgement, may (but does not have to) send an "A" packet to provide file attribute information. The attributes will be given in the data field of the "A" packet. The data field will consist of 0 or more subfields, which may occur in any order. Each subfield is of the following form: where is a single printable character other than space, is the length of the data characters (0 to 94), with 32 added to produce a single printable character, and is characters worth of data, all printable characters. No quoting or prefixing is done on any of this data. There may be 93 different attributes, one for each of the 93 printable ASCII characters other than space. These will be assigned in ASCII order. Here are some suggestions for the first few: ! (ASCII 33) Length. The data field gives the length in K (1024) bytes, as a printable decimal number, e.g. "!#109". This will allow the receiver to determine in advance whether there is sufficient room for the file, and/or how long the transfer will take. " (ASCII 34) Type. The data field can contain some indicator of the nature of the file. Note that only sequential files can be supported by the KERMIT protocol. Here are some suggested types: Axx ASCII text, containing no 8-bit quantities, logical records delimited by the (quoted) control character sequence "xx", represented here by its printable counterpart (MJ = CRLF, J = LF, etc). For instance AMJ means that the appearance of #M#J (the normal prefixed CR-LF sequence) in a file data packet indicates the end of a record. Bxx Binary. "xx" indicates in what manner the file is binary: 8 The file is a sequence of 8-bit bytes, which must be saved as is. The 8th bit may be sent "bare", or prefixed according to the Send-Init negotiation about 8th-bit prefixing. 36 The file is a PDP-10 format binary file, in which five 7-bit bytes are fit into one 36-bit word, with the final bit of each word being represented as the "parity bit" of every 5th character (perhaps prefixed). Dx Variable length undelimited records. Each logical record begins with an x-character ASCII length field (similar to ANSI tape format "D"). Fxxxx Fixed-length undelimited records. Each logical record is xxxx bytes long. I Image. The file is being sent exactly as it is represented on the system of origin. For use between like systems. # (ASCII 35) Creation Date, expressed as "ddmmyy hhmmss", e.g. 070983 135700. The time is optional; if given, it should be in 24-hour format, and the seconds may be omitted. $ (ASCII 36) Creator's ID, expressed as a character string of the given length. % (ASCII 37) Account to charge the file to, character string. & (ASCII 38) Area in which to store the file, character string. ' (ASCII 39) Password for above, character string. ( (ASCII 40) Block Size. The file is to be stored with the given block size. This may be useful when sending files to or from IBM mainframes, VAX/VMS, or other systems where files may have this attribute. ) (ASCII 41) Access: N New, the normal case -- create a new file of the given name. S Supersede (overwrite) any file of the same name. A Append to file of the given name. * (ASCII 42) Encoding: A ASCII, normal ASCII encoding with any necessary prefixing, etc. H Hexidecimal "nibble" encoding. X Encrypted. Well, many of these can be imagined, and can be added later if needed. However, two important points should be noted: The receiver may have absolutely no way of honoring, or even recording, a given attribute. For instance, CP/M-80 has no slot for creation date or creator's ID in its FCB; the DEC-20 has no concept of block size, etc. The sender may have no way of determining the correct values of any of the attributes. This is particularly true when sending files of foreign origin. The "A" packet mechanism only provides a way to send certain information about a file to the receiver, with no provision or guarantee about what the receiver may do with it. That information may be obtained directly from the file's directory entry (FCB, FDB, or whatever), or specified via user command. The ACK to the "A" packet may in turn have information in its data field. However, no complicated negotiations about file attributes may take place, so the net result is that the receiver may either refuse the file or accept it. The receiver may reply to the "A" packet with any of the following codes in the data field of the ACK packet: (empty data field) I accept the file, go ahead and send it. Nxxx I refuse the file as specified, don't send it; "xxx" is zero or more of the attribute characters listed above, to specify what attributes I object to (e.g. "!" means it's too long, "&" means I don't have write access to the specified area, etc). Yxxx I agree to receive the file, but I cannot honor attributes "xxx", so I will store the file according to my own defaults. Y (degenerate case of Yxxx..., equivalent to , above) How the receiver actually replies is an implementation decision. A NAK in response to the "A" packet means, of course, that the receiver did not receive the "A" correctly, not that it refuses to receive the file. (End of KERMIT RFC #6) Any comments, suggestions, additions, deletions? ------- 13-Oct-83 09:40:10-EDT,4763;000000000001 Return-Path: <@CUCS20:SY.FDC@CU20B> Received: from CUCS20 by CU20B with DECnet; 13 Oct 83 09:40:02 EDT Received: from CU20B by CUCS20 with DECnet; 13 Oct 83 09:40:32 EDT Date: Thu 13 Oct 83 09:39:16-EDT From: Frank da Cruz Subject: [J. Ray Scott : Two PC Kermit issues for development] To: Info-Kermit@CUCS20 This might be of some interest to the list... - Frank --------------- 1) 12-Oct J. Ray Scott Two PC Kermit issues for development 2) 13-Oct To: JS5A@CMCCT Re: Two PC Kermit issues for development Message 1 -- ************************ Return-Path: Received: from CMCCTA by CU20B with DECnet; 12 Oct 83 20:22:25 EDT Received: ID ; 12 Oct 83 20:20:49 EDT Date: 12 Oct 83 20:20:03 EDT From: J. Ray Scott To: sy.fdc@CU20B Campus-Phone: 578-2836 Subject: Two PC Kermit issues for development Frank: I have two KERMIT issues for consideration. We are willing to work on them but slowly. First, the last version we got for the IBM PC had the backspace key (the one above the "return" key) send a control-H. Previous CMU versions had this send a delete since TOPS-20 and VAX don't really use control-H very much. While I was tempted to change it back I did some checking and found that both IBM and UNIX systems liked ^H much better than DEL and since the combination of UNIX and IBM uses outnumber the TOPS/VMS users I figured we should consider have some sort of user settable option? ...or perhaps an assembly parameter? It is easy enough to change but I am afraid that the terminal emulation part of this may get out of hand if we all go our own ways. Second, as we were updating the terminal emulation mode it became clear that having separate modules is very important. We eventually ripped out the terminal emulation code and made a stand alone program. Even that takes over 3 minutes to compile. For general interest, we have put in support for some of the VT52 type function keys. We are anxious to be able to run the WORD-11 word processing package via Kermit. While this may sound odd, we have a great number of WORD-11 users who also happen to need or want PC's for other reasons. We have not found a word processing package for the PC which is nearly as good as WORD-11. This seems like a good way to get people started on PC's while not losing all the function they have had on mainframes. When we get our code debugged and merged back into KERMIT we will make it available. If time permits, we will look at breaking PC KERMIT up into modules. J. Ray Scott -------- Message 2 -- ************************ Mail-From: SY.FDC created at 13-Oct-83 09:35:38 Date: Thu 13 Oct 83 09:35:38-EDT From: Frank da Cruz Subject: Re: Two PC Kermit issues for development To: JS5A@CMCCTA cc: SY.FDC@CU20B In-Reply-To: Message from "J. Ray Scott " of Wed 12 Oct 83 20:20:03-EDT I agree that it might be desirable to break Kermit-86 up into modules; it would certainly be a good idea for any Kermit that wants to support multiple systems (Kermit-80 is the top candidate, UNIX Kermit the next). The relevant modules would seem to be: (a) protocol (system independent), (b) command parsing (so people can substitute function keys for the COMND-style interface if they like, or substitute a UNIX-style interface, etc), (c) terminal emulation (plug in your favorite terminal), (d) port i/o, (e) disk i/o, (f) screen i/o. If these can be relatively modular and well defined, it would become much easier to add support for new machines, operating system versions, modems, disk drives, etc etc. This has been our plan for some time, though we've yet to get started on it. This would be a good time for doing it to PC Kermit, because it contains explicit support for only two systems, the IBM PC and the Z100. I also agree that the code the backspace key sends should be made user settable. This is actually part of a larger problem. What we need to have is a way a user can set KERMIT up for communicating with a particular system. This would involve at least the addition of a command or initialization file capability. Each user's KERMIT.INI could contain definitions of the settings for each kind of system, e.g. DEFINE IBM = DUPLEX HALF, HANDSHAKE ^Q, PARITY MARK, BACKSPACE BS DEFINE UNIX = DUPLEX FULL, HANDSHAKE OFF, PARITY NONE, BACKSPACE DEL DEFINE DEC-20 = UNIX DEFINE TELENET = PARITY MARK and so forth. The user would then just type SET IBM or SET UNIX to establish all the right settings (or perhaps simply, CONNECT IBM). Again, it's planned, but no action yet. - Frank ------- ------- 13-Oct-83 10:52:33-EDT,1096;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 13 Oct 83 10:52:25 EDT Date: Thu 13 Oct 83 10:52:28-EDT From: Frank da Cruz Subject: Re: KRFC #5 (capabilities) To: Info-Kermit@CUCS20 Here's a suggested modification to KRFC #5 (capabilities field) that makes a lot of sense. I'd like to incorporate it into the RFC. (It's from Case Western Reserve University.) - Frank --------------- Date: Thu 13 Oct 83 08:24:53-EDT From: Rob Gingell Subject: Re: KRFC #5 To: CC.FDC@COLUMBIA-20 I may be demonstrating a woeful ignorance of the KERMIT protocol, but could you encode the capabilities bytes as a bit-field extensible set a la NSP? That is, use something like the LSB of each byte as a flag that another byte with more bits is coming. The capabilities field would then end upon receiving a capability byte with a LSB of 0. That way the protocol would not have to be updated each time a field ran out of space, it would extend naturally to any length. Rob ------- 14-Oct-83 19:12:23-EDT,765;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 19:12:20 EDT Date: Fri 14 Oct 83 19:13:10-EDT From: Frank da Cruz Subject: Two more KRFC's coming... To: Info-Kermit@CUCS20 I'm in the process of revamping the KERMIT Protocol Manual to incorporate some of the newly proposed features, and to generally reorganize it into a more complete and clear working document. If anyone has any further comments on the recent "Kermit RFC's", please send them soon, since their prose may soon turn to code... Meanwhile, a couple new ones will follow this message -- one suggests a "normal form" for file names, and the other suggests some standard terminology and names for commands. - Frank ------- 14-Oct-83 19:25:43-EDT,2822;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 19:25:39 EDT Date: Fri 14 Oct 83 19:17:52-EDT From: Frank da Cruz Subject: KRFC #7, Normal Form for File Names To: Info-Kermit@CUCS20 KRFC #7, Normal Form for File Names As the various KERMITs have come into being, an unspoken convention has emerged with respect to how file names are represented in file header packets. Although the explicit rule is that it is the responsibility of the recipient to convert the file name to a form that complies with local conventions, it turns out that many of the smaller implementations of KERMIT (particularly for CP/M and other microcomputer systems) took no such measures. This was not a problem when all the systems that had KERMITs had the same idea of what a filename looked like, namely "foo.bar", where "foo" and "bar" were sequences of digits, uppercase letters, and maybe a few special characters, with no imbedded spaces or control characters. When IBM VM/CMS and UNIX started speaking KERMIT, however, great confusion resulted in micro land -- files appeared on CP/M disks that could not be referred to in any normal fashion, e.g. files with pathnames and lowercase letters in their names from UNIX, or with spaces from the CMS file system. Consequently, the mainframe versions were changed to send filenames in the "normal form". UNIX strips the pathname and converts to upper case on output, CMS converts "FILENAME FILETYPE FILEMODE" to "FILENAME.FILETYPE", and so forth. Shall we codify this practice? Are the following rules reasonable? 1. Delete all pathnames from the file specification. The file header packet should not contain directory or device names (if it does, it may cause the recipient to try to store the file in an inaccessible or nonexistent area, or result in a very funny filename). 2. If communicating in "image mode" (see KRFC #6), send filenames as-is. 3. If not in image mode, convert filenames to "normal form", if necessary. Normal form is "name.type", with no restriction on length (except that it fit in the data field of the F packet), and: (a) No more than one dot. (b) Digits, uppercase letters only in "name" and "type". Special characters like $, _, -, &, and so forth should probably be disallowed, since they're sure to cause problems on one system or another. The recipient, of course, cannot depend upon the sender to follow this convention, and should still take precautions. However, since most file systems embody the notion of a file name and a file type, this convention will allow these items to be expressed in a way that an unlike system can understand. The particular notation is chosen simply because it is the most common. ------- 14-Oct-83 19:40:23-EDT,7589;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 19:40:14 EDT Delivery-Notice: While sending this message to CU20B, the CUCS20 mailer was obliged to send this message in 50-byte individually Pushed segments because normal TCP stream transmission timed out. This probably indicates a problem with the receiving TCP or SMTP server. See your site's software support if you have any questions. Date: Fri 14 Oct 83 19:20:33-EDT From: Frank da Cruz Subject: KRFC #8, Commands and Terminology To: Info-Kermit@CUCS20 KRFC #8, Commands and Terminology As KERMIT spreads and the number of implementations and features grows, the time has come to suggest some standard terminology for KERMIT, its environment, and its functions. An example of how confusion can creep in came up recently when a site added the capabilityM PCt to tell a server to change its working directory (generic "C" command). The name they chose for the IBM PC command was ATTACH, because that happens to be the name of the same command on their mainframe. On other systems, ATTACH has a different meaning -- for instance, to "connect" one's terminal to a "detached" (disconnected, disassociated) "job", and another term, like CONNECT, is used to change one's working directory. But then, CONNECT is already used in KERMIT to invoke a virtual terminal connection... Furthermore, as more functionality is added to Kermit servers, and commands added to user programs to invoke them, while the same functions are being added to the useramselves, the potential for confusion becomes even greater. stanKermit user program might have a command to delete a local filenoth to ask a server to delete a remote file. At first, it seemed desirable to let each implementation preserve the flavor of its host operating system, but now we are beginning to get different commands that do the same thing, the same command doing different things, and other odd situations, and we're getting a user manual that is very thick. So the following list of commands and terms is suggested. It is not intended to recommend a particular style of command parsing, only to promote a consistent vocabulary, both in documentation and in choosing the names for commands. * Who's Who: LOCAL: When two machines are connected, the LOCAL machine is the one which you interact with directly. The "local Kermit" is the one that runs on the local machine. A local Kermit always communicates over an external device (the micro's communication port, an assigned TTY line, etc). REMOTE: ThTE m is the one on the far side of the connection, which you mustact through" the local machine. The "remote kermit" runs on the remote machine. A remote Kermit usually communicates over its own "console" or "controlling terminal". HOST: Thisshouavoided, unless preceded immediately by LOCAL or REMOTE. SERVER: An implementation of remote Kermit that can accept commands in packets from a local Kermit. USER: In an tosual use to denote the person using a system or program," ca refer to the local Kermit, when the remote Kermit is a server. * Basic Commands: SEND: This verb tells a Kermit program to send one or more files from its own file structure. RECEIVE: This verb should tell a Kermit program to expect one or more files to arrive. GET: This verb should tell a user Kermit to send one or more files. Some Kermit implementations have separate RECEIVE and GET commands; others use RECEIVE for both purposes, which creates confusion. * Terminal Emulation: CONNECT: This verb, valid only for a local Kermit, means to go into terminal emulation mode; present the user with the illusion that s/he is directly connected to the remote system. (Almost every microcomputer implementation of KERMIT has this command. It might havewiseall it TERMINAL, but it's too late now...) * Special User-Mode Commands: (These commands are used only by Users of Servers.) BYE: This command sends a message to the remote server to log itself out, and upon successful completion, the local Kermit program to terminate. FINISH: This command causes the remote server to shut itself down gracefully without logging out its job. * Commands Whose Object Should Be Specified: Many Kermiemens include various local file management services and commands tke tFor instance, CP/M Kermit recently (announcement forthcoming) has commands to let you get directory listings, delete files, switch disks, and inquire about free disk space without having to exit and restart the program. Soon, remote servers will also provide such services. A user Kermit must be able to distinguish between commands aimed at its own file system and those aimed at the remote one. When any confusion is possible, such a command may be prefixed by: REMOTE - Ask the remote Kermit server to provide this service. LOCAL - Perform the service locally. If the "object prefix" is omitted, the command will be executed locally. The services include: LOGIN: This should be used in its timesharing sense, to create an identity ("job", "session", "access", "account") on the system. CWD: Change Working Directory. This is ugly, but more natural verbs like CONNECT and ATTACH are too imprecise. CWD is the ARPAnet file transfer standard command to invoke this function. DIRECTORY: Provide a list of the names, and possibly other attributes, of the files in the current working directory (or the specified directory). SPACE: Tell how much space is available for storing files in the current working directory (or the specified directory). DELETE: Delete the specified files. ERASE: This could be a synomym for DELETE, since its meaning is clear. (note, it doesn't seem wise to include UNDELETE or UNERASE in the standard list; most systems don't support such a function, and users' expectations should not be toyed with...) COPY: Maew c the specified file with the specified name. RENAME: Change the name of the specified file. TYPE: Display the contents of the specified file(s) at the terminal. SUBMIT: Submit the specified file(s) for background (batch) processing. PRINT: Print the specified file(s) on a printer. MOUNT: Mount the specified tape, disk, or other removable storage medium. WHO: Show who is logged in (e.g. to a timesharing system), or give inion a specified user or network host. MAIL: Send electronic mail to the specified user(s). MESSAGE: Send a terminal message (on a network or timesharing system). HELP: Gief ition about how to use KERMIT. SET: Set various parameters relating to debugging, transmission, file mode, and so forth. SHOW: Display settings of SET parameters. STATISTICS: Give information about the performance of the most recent file transfer -- elapsed time, effective baud rate, various counts, etc. HOST: Pass the given command string to the specified (i.e. remote or local) host for execution in its own command language. Additions? Deletions? Corrections? Suggestions? Complaints? Naming things is always the hardest part of any computing project, and usually provokes the most liveltes... ------- 14-Oct-83 20:54:45-EDT,737;000000000000 Return-Path: <@CUCS20:OC.SITGO@CU20B> Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 20:54:42 EDT Received: from CU20B by CUCS20 with DECnet; 14 Oct 83 20:55:31 EDT Date: Fri 14 Oct 83 20:54:19-EDT From: "Nick Bush" Subject: Re: KRFC #7, Normal Form for File Names To: cc.fdc@CUCS20 cc: Info-Kermit@CUCS20 In-Reply-To: Message from "Frank da Cruz " of Fri 14 Oct 83 19:25:46-EDT This seems like a very good idea. One problem with item #2, however, is that according to KRFC #6, the attributes packet would not get sent until after the file packet. Therefore, two Kermits could not know they could use image mode until after the file name was already sent. - Nick Bush ------- 14-Oct-83 21:14:25-EDT,1335;000000000000 Return-Path: <@CUCS20:WANCHO@SIMTEL20.ARPA> Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 21:14:19 EDT Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Fri 14 Oct 83 21:15:00-EDT Date: 14 Oct 1983 19:11 MDT (Fri) Message-ID: <[SIMTEL20].WANCHO.14-Oct-83 19:11:44> From: Frank J. Wancho To: INFO-KERMIT@COLUMBIA-20 Subject: KRFC #7, Normal Form for File Names In-reply-to: Msg of 14 Oct 1983 17:17-MDT from Frank da Cruz What happens when the receiving end reparses the filename to fit it's naming conventions? For example, one would expect the CP/M end to convert a name of the form n.m to its 8.3 limits, using the first 8 of the n characters, and the first three of the m characters. But then, what should it do if it receives a "different" filename n.m where the first 8 of n and first 3 of m happen to match? Do you overwrite, or use some additional convention to bump the .3 part? Do you change the .3 part to a fixed name, like .BAK? What if a third file comes in? As for the rest of the KRFC, it looks reasonable, except for the "special characters" part. It should be up to the receiving end to determine if any of them should be ignored or considered significant, and use whatever quoting mechanism is available. --Frank 14-Oct-83 22:02:38-EDT,993;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 22:02:35 EDT Date: Fri 14 Oct 83 22:02:48-EDT From: Frank da Cruz Subject: Re: KRFC #7, Normal Form for File Names To: WANCHO@SIMTEL20.ARPA, INFO-KERMIT@CUCS20 In-Reply-To: Message from "Frank J. Wancho " of Fri 14 Oct 83 19:11:00-EDT Good point about filename conflicts on the receiving end. But this has to be an implementation detail, beyond the scope of the protocol. Certainly it's desirable id oting files one doesn't want to overwrite. Systems where that's a particular danger (ones like CP/M and TOPS-10, where filenames are short and there is no automatic backup of versions or generations) tend to have a filename conflict avoidance mechanism built in -- e.g. in both of those implementations, it's the SET FILE-WARNING business (so that the user also has the option to overwrite files if s/he wants to). - Frank ------- 14-Oct-83 22:17:40-EDT,5654;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 22:17:31 EDT Date: Fri 14 Oct 83 19:29:26-EDT From: Frank da Cruz Subject: Kermit versions status table To: Info-Kermit@CUCS20 The following table is now available in KER:VERSIONS.DOC on COLUMBIA-20. It lists, briefly, what KERMIT implementations are available or are being worked on, and by whom, etc. I'll try to keep it up to date. Meanwhile, I talked with some of these people on the phone today. I hope to be getting tapes from several of them within a week or two, including Stevens (VAX/VMS, TOPS-10, Apple II DOS, and maybe Pro-350), Cornell (UCSD Pascal), and The SOURCE (PL/I for the PR1ME). Some of these should provide a good starting point for other implementations that have been long sought after -- the PL/I version should be easily adaptable to various IBM mainframes; the UCSD Pascal version should be widely portable (Cornell's particular implementation is for the Terak, but was written with portability in mind), the Pro-350 version should be adaptable to RSX-11M, etc. Anyway, here it is. If you have any corrections, additions, etc, please let me know... Known Kermit Versions, as of 14 Oct 83 -------------------------------------- Legend: Status: D Done, no further development going on C Continuing; already released, but a new release is in preparation P Work in Progress on initial release G Good intentions (they said they were going to, but no further word) Availability: A Ave frumbia W Columbia is waiting for it Level (a very rough indication): . Basic (send & receive files, terminal emulation if micro) - Sub-Basic (works, but missing some features, like error packets) + Advanced (includes server functions &/or data compression, CRCs, ...) ? Unknown Machine OS Language Status Who DEC-10 TOPS-10 MACRO-10/Bliss C A + Stevens DEC-20 TOPS-20 MACRO-20 C A + Columbia DEC VAX -32/Bliss C A + Stevens DEC PDP-1111 -11 P W + Stevens (based on P/OS) DEC PDP-11 RT-11 OMSI Pascal D A - Ontario/CU DEC PDP-11 RT-11 MACRO-11 P W ? Peter Moulton, Lincoln Labs/MIT DEC PDP-11 RSTS/E Basic+(2?) G W ? (many said they would...) DEC Pro-3xx P/OS MACRO-11/Bliss P W + Stevens DEC Rainbow CP/M-86 Asm86 P W + Bill Catchings, Columbia IBM 370 MS ssembler C A + Columbia IBM 370 MVS/TSO ? G W ? Arnie Berg, SASKCOMP IBM 370 MUSIC ? G W ? Ecole Polytechnique, Montreal IBM 370 MTS ? G W ? U of BC &/or U of Vancouver IBM 370 GUTS ? G W ? Info Resources Inc, Chicago ("370" means the whole 370 series, including 303x, 308x, 43xx, plus PCMs) CDC Cyber NOS Fortran D W ? Jim Knutson, U Texas, Austin Honeywell MULTICS PL/I D W ? Paul Amaranth, Oakland U, Mich. UNIVAC 1100 EXEC Assembler D W . Chuck Hutchins, U. of Wisc. DG MV/8000 AOS ? G W ? Gary Fostel, NCSU PR1ME PRIMOS PL/I D W + Leslie Spira, The SOURCE HP-1000 l? G W ? U of Tennessee, Knoxville Xerox 1100 (InterLisp-D) P W ? Jon L White, Xerox-PARC Various MUMPS MUMPS David Rossiter, Cornell U Various UNIX C C A - Columbia, with contributions VAX 4.1bsd from Jim Guyton, Rand Corp, SUN 4.1Cbsd Bill Underwood, Ford Aerospace IBM 370 Amdahl UTS Others V6, V7, Onyx, etc. Various UCSD P Pascal D W ? Kate McGregor, Cornell U Terak Kate McGregor, Cornell U HP-9826/9836 Mike Gallaher, Rutgers U Corvus C David Todd, Wesleyan U Sage II Gary Fostel, NCSU IBM PC PC DOS MASM C A . Columbia Zenith Z100 MS DOS MASM C A . Added to IBMPC version by Stevens Victor 9000 MS DOS ? G W ? Ford Motor Company, Dearborn Z80/8080 CP/M-80 8080 assembler C A + Columbia, w/other contributors: DEC VT180 Bernie Eiben, DEC DEC Rain80 s Bernie Eiben, DEC DECmate II (CP/M only) Someone at DEC Heath/Zenith-89 Someone at DEC Heath/Ze00 (de) Nick Bush, Stevens Apple II (Z80 soft card) Scott Robinson, DEC TRS-80 II (CP/M only) Bruce Tanner, Cerritos College Osborne I Chuck Bacon, NIH Intertec SuperBrain Columbia Vector Graphics Columbia Telcon Zorba Nick Bush, Stevens Ohio Scientific Columbia "Generic 2.2 Bernie Eiben, DEC "Generic" CP/M 3.0 Bruce Tanner, Cerritos College (All these versions are built from a common source with conditional assembly) Apple II DOS Cross C A . Stevens Commodore 64 Cross? G W ? Columbia ------- 15-Oct-83 02:41:15-EDT,1405;000000000000 Return-Path: <@CUCS20:Grich%UCI.UCI@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 15 Oct 83 02:41:10 EDT Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Sat 15 Oct 83 02:41:55-EDT Date: 14 Oct 83 22:21:50 PDT (Fri) From: John Mangrich Return-Path: Subject: PC Kermit backspace/delete key To: info-kermit.UCI@Rand-Relay, js5a%cmccta@Rand-Relay Via: UCI; 14 Oct 83 23:12-PDT First, the last version we got for the IBM PC had the backspace key (the one above the "return" key) send a control-H. Previous CMU versions had this send a delete since TOPS-20 and VAX don't really use control-H very much. While I was tempted to change it back I did some checking and found that both IBM and UNIX systems liked ^H much better than DEL and since the combination of UNIX and IBM uses outnumber the TOPS/VMS users I figured we should consider have some sort of user settable option? ...or perhaps an assembly parameter? It is easy enough to change but I am afraid that the terminal emulation part of this may get out of hand if we all go our own ways. Hmm...I usion f PC Kermit, and I get a control-H when I press the backspace key, but I get a real delete (ascii 127) if I do control-backspace on the IBM keyboard. John Mangrich grich.uci@rand-relay 15-Oct-83 13:16:13-EDT,623;000000000000 Return-Path: <@CUCS20:DRF@SU-AI> Received: from CUCS20 by CU20B with DECnet; 15 Oct 83 13:16:09 EDT Received: from SU-AI.ARPA by COLUMBIA-20.ARPA with TCP; Sat 15 Oct 83 13:16:55-EDT Date: 15 Oct 83 1015 PDT From: David Fuchs Subject: Re: KRFC #7, Normal Form for File Names To: Info-Kermit@COLUMBIA-20 How about having an option for NOT stripping path names, so KERMIT could potentially send entire sub-directory trees from Unix to Unix systems? I'd also be more comfortable if the `image-mode file name' option were unbundled from the `image-mode data transfer' option. -David Fuchs 17-Oct-83 18:44:18-EDT,620;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 17 Oct 83 18:44:12 EDT Date: Mon 17 Oct 83 18:46:23-EDT From: Frank da Cruz Subject: Re: KRFC #7, Normal Form for File Names To: DRF@SU-AI.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "David Fuchs " of Sat 15 Oct 83 10:15:00-EDT Makes sense. Let's say that BY DEFAULT, it strips pathnames. Also agreed about the unbundling, especially as someone else pointed out, you don't necessarily know know the file is in image mode until after the file name has already been sent. - Frank ------- 18-Oct-83 11:51:06-EDT,1400;000000000000 Return-Path: <@CUCS20:SY.FDC@CU20B> Received: from CUCS20 by CU20B with DECnet; 18 Oct 83 11:50:53 EDT Received: from CU20B by CUCS20 with DECnet; 18 Oct 83 11:50:27 EDT Date: Tue 18 Oct 83 11:50:08-EDT From: Frank da Cruz Subject: [Bob Cattani : Next Kermit is ready] To: Info-Kermit@CUCS20 Announcing yet another release of UNIX Kermit. The major addition here is error packet processing; this brings UNIX Kermit up to the basic level of all other Kermits. All UNIX sites should convert to this latest version. Please report any problems directly to Bob (CATTANI@COLUMBIA-20) and me (CC.FDC@COLUMBIA-20). - Frank --------------- Date: Mon 17 Oct 83 15:52:17-EDT From: Bob Cattani Subject: Next Kermit is ready Included fixes from Alan Crosswell (CUCCA) for IBM_UTS: - Changed MYEOL character from \n to \r. - Change char to int in bufill so getc would return -1 on EOF instead of 255 (-1 truncated to 8 bits) - Added read() in rpack to eat the EOL character - Added fflush() call in printmsg to force the output NOTE: The last three changes are not conditionally compiled since they should work equally well on any system. Changed Berkeley 4.x conditional compilation flag from UNIX4X to UCB4X. Added support for error packets and cleaned up the printing routines. -Bob ------- ------- 18-Oct-83 12:58:40-EDT,1319;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 18 Oct 83 12:58:33 EDT Date: Tue 18 Oct 83 12:58:02-EDT From: Frank da Cruz Subject: FORTRAN-based KERMIT available To: Info-Kermit@CUCS20 Announcingor nMIT release, written in FORTRAN for the CDC Cyber 170 by Jim Knutson of the Computation Center of the University of Texas at Austin (knutson@u11, tson@UT-NGP). Although it won't be able to run as-is on many machines, it should be adaptable to a wide range of systems for which KERMIT is tly lable. The source for the Cyber Version of Kermit is on COLUMBIA-20 in the file KER:170KERR, ale via anonymous FTP. The installation information is in the Fortran source code. It will need mods for any Cyber site that tries to run it therprobably no two Cyber sites anywhere that do ASCII I/O the same way. There is also an nroff source for additions to the Kermit User's Guide in KER:170KERMIT.NR. The Cyber-170 version of KERMIT has been tested with KERMIT-20 and UNIX Kermit and runs with either. It is rather slow (500-900 effective baud on a 2400 baud line). It has also been tested with Kermit-86 on a Corona (IBM-PC clone), IBM-PC and0 anermit on a Z100. ------- 20-Oct-83 23:48:45-EDT,3641;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 20 Oct 83 23:48:38 EDT Date: Thu 20 Oct 83 23:48:16-EDT From: Frank da Cruz Subject: New Release of CP/M Kermit for Testing To: Info-Kermit@CUCS20 Version 3.5 of KERMIT-80 for CP/M is available for testing. Many new features have been added, bugs fixed, etc. A list follows. Users of CP/M systems on this list are urged to get copies of the new version for their systems, try it out, and let me know if it works. When 15 different systems are being supported from one source file by hairy conditional assembly parameters (IF this AND that BUT NOT those...ENDIF), it's never easy to change things, especially when you don't have an example of each system to test the new stuff on. The VT180 and DECmate II support have been tested so far... If I can get word, one way or the other, on most of the systems we're supposed to support, I'll announce the new version to Info-CPM, Info-Micros, etc... KER:CPMBASE.M80 is now the current, working source file for KERMIT-80. All the KER:CPM*.HEX files are generated from it. See KER:CPMKERMIT.DOC for a discussion of the status of this and the other source files. The old .HEX files have been renamed to *.OHX. All these files are available via anonymous FTP from host COLUMBIA-20, in the area KER: (or, PS:). This file briefly lists the changes and new features of KERMIT-80 version 3.5, which is generated for each system from CPMBASE.M80. * Kaypro II support. * SET FILE-MODE BINARY or ASCII or DEFAULT (DEFAULT is currently BINARY). This replaces SET CPM-CREATED FILE, and it works somewhat differently (better -- no longer get "ever-growing files"). SET FILE-WARNING changed to SET WARNING to reduce typing. * Session logging bugs fixed, but it's still not perfect. * Bugs with files of length n*32K fixed. * Performance improvements. * SET PORT (VT180 only) allows switching between communication ports. Also, VT180 can now transmit a BREAK (presently none of the other CP/M implementations can do this; anyone want to add this support for their micro?). * 2 & 3 character block checks (longer checksum, and CRC, respectively). Only useful with other KERMITs that support this option. * ^X/^Z interrupting of file transmission: ^X interrupts the current file (of a wildcard group), skipping to next ^Z interrupts the whole group Works for sending. For receiving, works only if the other KERMIT knows about this new feature. * Fixes for Osborne 1 support installed but not tested. * Improved terminal emulation. Now interrupt characters typed during long typeouts from the host should get through. Also, it's now possible to transmit a NUL. Also, the broken local echoing should now be fixed. * Wildcard file stepping improved to handle any number of files. Previously, 16 was the maximum. However, the new method is slower (there is still room for improvements, which will be installed as time permits). * Local DIRECTORY and ERASE commands. * Disk switching via SET DEFAULT DISK. "Kermit-80>" prompt now includes the default disk, as in "Kermit-80 B:>". * "GET" is a synonym for "RECEIVE filespec", for sending a request to a server. More in line with "standard" nomenclature. * Various cosmetic improvements and minor bugs fixed. Thanks mostly to Bernie Eiben of DEC (Marlboro, Mass), Nick Bush of Stevens Institute of Technology (Hoboken NJ), and Bruce Tanner of Cerritos College (Norwalk, CA) for these improvements. ------- 21-Oct-83 00:02:26-EDT,1148;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 21 Oct 83 00:02:22 EDT Date: Thu 20 Oct 83 23:56:08-EDT From: Frank da Cruz Subject: New KERMIT Protocol Manual To: Info-Kermit@CUCS20 A new, much expanded fourth edition of the KERMIT Protocol Manual is now available via anonymous FTP from host COLUMBIA-20 as KER:PROTO.*. There are 4 files: PROTO.MSS - The SCRIBE (TM UNILOGIC, all rights reserved, etc) source file. PROTO.DOC - Suitable for reading on a computer terminal. PROTO.LPT - Suitable for printing on a DEC line printer (underline, overstrike) PROTO.FOR - Like .LPT, but for printers that want carriage control in column 1. The new protocol manual supersedes the old one -- there are several minor incompatibilities (hopefully not affecting any features that anyone has implemented so far). And it supersedes KRFC's 1-8, which have been incorporated into it with modifications to reflect suggestions I got from members of the mailing list. I hope it's a better document to work from. Comments, complaints, suggestions, flames -- all are welcome. ------- 21-Oct-83 00:16:15-EDT,1821;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 21 Oct 83 00:16:10 EDT Date: Fri 21 Oct 83 00:11:47-EDT From: Frank da Cruz Subject: New TTLINK sends BREAK(?) To: Info-Kermit@CUCS20, TOPS-20@SU-SCORE.ARPA Bill Schilit has added code to TTLINK, the "poor person's TELNET" for making virtual terminal connections from a DEC-20 to another system over an assigned TTY line, for sending a BREAK signal. (TTLINK is run by KERMIT-20 to accomplish the CONNECT command). We've tried it with our own IBM systems, which have many uses for BREAK and expect users to type it all the time, and it seems to work. It's a horrible hack, however; since TOPS-20 provides no way to send a *real* BREAK, so there's no telling if it will work with all systems. Typical symptoms of it not working would be no BREAK detected by the intended recipient, too many BREAKs detected, or (worst of all) line hangs up or gets set to the wrong speed... Yes, you guessed how it works: it drops the speed down low, sends a bunch of nulls which result in a framing error since the speed is wrong (hence BREAK, which is defined roughly as NULs received with a framing error), and brings the speed back up again. The problem, as TOPS-20 afficionados know, is that TOPS-20 didn't know what your speed was in the first place, so restoring it after sending the BREAK can be tricky. Also, the number of NULs to send to simulate a BREAK may vary according to the communications equipment that's being used, and the actual baud rate. These things (the speed and the number of nulls) are controlled by new, cryptic, but user-friendly switches to TTLINK. If you want to try it, it's in KER:NTTLINK.* at host COLUMBIA-20, accessible by anonymous FTP. Comments welcome. -------