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 Keywords: ARPANET 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 Keywords: Kermit-80 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 Keywords: UNIX Kermit, MS-DOS Kermit Cross-Ref: PC Kermit, IBM Kermit, MS-Kermit (see also MS-DOS Kermit) 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 Keywords: Kermit-80 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 Keywords: UNIX Kermit, MS-DOS Kermit 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 Keywords: Kermit-80 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 Keywords: Kermit Info 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 Keywords: Kermit Info 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 Keywords: Distribution List 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 Keywords: DEC-Rainbow Kermit Cross-Ref: Rainbow Kermit (see also DEC-Rainbow Kermit) 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 Keywords: C-Kermit, UNIX Kermit 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 Keywords: ARPANET, MODEM 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 Keywords: ARPANET, MODEM 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 Keywords: UNIX Kermit Cross-Ref: C-Kermit (see also UNIX Kermit) 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 Keywords: UNIX Kermit 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 Keywords: Kermit-80 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 Keywords: MAC80 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 Keywords: UNIX Kermit 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 Keywords: Distribution List 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 Keywords: OCC-1, Osborne Kermit 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 Keywords: Osborne Kermit, CP/M Kermit 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 Keywords: MVS Kermit, IBM 370 Series 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 Keywords: MVS Kermit, IBM 370 Series 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 Keywords: MVS Kermit, IBM 370 Series 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 Keywords: Distribution List 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 Keywords: MAC80 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 Keywords: New Implementations 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 Keywords: RSX11-M, RSX, RSTS 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 Keywords: PRO-350 Kermit 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 Keywords: Kermit Info 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 Keywords: Kermit-20 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 Keywords: Commodore 64 Kermit 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> Received: 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 Keywords: VMS Kermit 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 Keywords: VMS Kermit 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 Keywords: VMS Kermit 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 Keywords: VMS Kermit 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 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 Keywords: VMS Kermit 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 Keywords: CP/M Kermit 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 Keywords: MS-DOS Kermit 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 Keywords: Commodore 64 Kermit 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 Keywords: MS-DOS Kermit 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 Keywords: TAC 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 Keywords: TAC 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;000000000001 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 Keywords: Kermit-86, MS-DOS Kermit, Heath/Zenith-100 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 Keywords: DECsystem-10 Kermit, Kermit-10, DEC-10 Kermit 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 Keywords: Kermit-10 Dan Jones at LLL asked whether anyone on the list had seen or heard about a program to allow use of a dialout 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 site (due to the wide distribution 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 Keywords: TAC 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 Keywords: TAC 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 Keywords: ANONYMOUS FTP 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) Keywords: TAC 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 Keywords: UNIX Kermit, MS-DOS Kermit Recently, I installed a copy 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, suggestions etc, please forward to Wmt@MIT-XX. Happy Hacking !!! --- 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 ... Keywords: UNIX Kermit, MS-DOS Kermit Here is a message I sent to a friend of mine who implemented UNIX Kermit running under JHU UNIX at BRL. Since then, we have discussed which things are bugs and which are features. 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 Keywords: BMD-70 Kermit 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 -so filename object 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 Keywords: UNIX Kermit, MS-DOS Kermit 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 Keywords: VM/CMS Kermit, MS-DOS Kermit Cross-Ref: CMS Kermit (see also VM/CMS Kermit) 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 Keywords: MS-DOS Kermit 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 Keywords: HP-3000 Kermit 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 Keywords: CP/M Kermit 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 Keywords: CP/M Kermit 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 Keywords: CPM/86 Kermit 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 Keywords: HP-9836 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 Keywords: CPM/86 Kermit 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 Keywords: HP-9836 Kermit 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 want to talk to the people 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: Kevin 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 Keywords: CPM/86 Kermit 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 Keywords: MS-DOS Kermit 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 Keywords: Dialup 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 Keywords: Dialup 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 Keywords: MS-DOS Kermit 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 Keywords: MS-DOS Kermit 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 Keywords: MS-DOS Kermit 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 Keywords: Kermit Protocol 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 Keywords: Batch, Kermit-20 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 Keywords: Batch, Kermit-20 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 version of Kermit exist for the NEC APC, or is anyone working on one? Since the NEC APC 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 connections, was not able to run under TOPS-20 batch because the program wanted to enable ^C 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 been successfully enabled, 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.), allowing the other 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. That particular omission has been corrected, and some other minor bugs fixed in recent days. The 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: from CUVMA by CU20B with HASP; 26 Sep 83 15:22:25 EDT From: Alan Crosswell Date: 26 Sep 1983 15:21:55-EDT Sender: UNIXA at CUVMB To: sy.fdc@cu20b 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 the following changes: 1) Removed IBM_UTS system type. 2) Added NO_NLWAKEUP #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) Added an fflush 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 done, the eol character 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 NO_FIONREAD 0 /* 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 t, /* 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 not all the comments 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 the first 36-bit word 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 file with the sixbit 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 appreciated. 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;000000000001 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 the use of any new 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) moving the reserved fields 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 capabilities will be numbered 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. If the binary values (i.e. before addition of 32) of the two fields are "concatenated" to form 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 capabilities represented). 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 capability to IBM PC Kermit 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 user programs themselves, the potential for confusion becomes even greater. For instance, a Kermit user program might have a command to delete a local file and another one 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: The REMOTE machine is the one on the far side of the connection, which you must interact with "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: This term should be avoided, 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 addition to its usual use to denote the person using a system or program, "user" can also 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 have been wiser to call 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 Kermit implementations include various local file management services and commands to invoke them. For 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: Make a new copy of 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 information about 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: Give brief information 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 lively debates... ------- 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 to avoid overwriting 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 Available from Columbia 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 VMS MACRO-32/Bliss C A + Stevens DEC PDP-11 RSX/11 MACRO-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 VM/CMS IBM assembler 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 ? Pascal? 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 Concept David Todd, Wesleyan U Sage II & IV 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 Rainbow (Z80 side) Bernie Eiben, DEC DECmate II (CP/M only) Someone at DEC Heath/Zenith-89 Someone at DEC Heath/Zenith-100 (Z80 side) 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" CP/M 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 use version 1.19 of 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 Announcing a major new KERMIT release, written in FORTRAN for the CDC Cyber 170 by Jim Knutson of the Computation Center of the University of Texas at Austin (knutson@utexas-11, or knutson@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 presently unavailable. The source for the Cyber Version of Kermit is on COLUMBIA-20 in the file KER:170KERMIT.FOR, available 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 since there are probably 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 and a Z100 and CPMKermit 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. ------- 25-Oct-83 10:27:32-EDT,539;000000000000 Return-Path: <@CUCS20:JPAnderson.DODCSC@MIT-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 25 Oct 83 10:27:28 EDT Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 25 Oct 83 10:26:15-EDT Date: 25 October 1983 10:22 edt From: JPAnderson.DODCSC at MIT-MULTICS Subject: kermit on RSTS/E To: info-kermit at COLUMBIA-20 Does a version of KERMIT exist to run on 11's (PDP's of course) running RSTS/e? If not, does any one know of any means of xfering files between two machines? thanks in advance Jay 25-Oct-83 16:46:40-EDT,943;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 25 Oct 83 16:46:07 EDT Date: Tue 25 Oct 83 16:44:07-EDT From: Frank da Cruz Subject: Re: kermit on RSTS/E To: JPAnderson.DODCSC@MIT-MULTICS.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "JPAnderson.DODCSC at MIT-MULTICS" of Tue 25 Oct 83 10:22:00-EDT There's not yet a KERMIT for RSTS/E (any volunteers?). Unless there's an implementation of MODEM, your best bet would probably be to write a simple terminal emulator that can log to a file, for unguarded capture of remote files. It's probably just as easy, however, to write KERMIT itself, working from the Protocol Manual and one of the existing implementations (in C or Pascal, for instance). All these are available on host Columbia-20 in the area KER: via anonymous FTP. Look at KER:00README.TXT for a guide to the files in the Kermit distribution area. ------- 29-Oct-83 17:03:35-EDT,424;000000000000 Return-Path: <@CUCS20:CCVAX.trest@Nosc> Received: from CUCS20 by CU20B with DECnet; 29 Oct 83 17:03:26 EDT Received: from nosc-cc by COLUMBIA-20.ARPA with TCP; Fri 28 Oct 83 23:11:09-EDT Date: 28 Oct 1983 20:01:21-PDT From: CCVAX.trest@Nosc To: INFO-KERMIT@COLUMBIA-20 Please Add Me to your List. THANKS!! trest@nosc trest@nosc-tecr Mike Trest 4065 Hancock Street San Diego, Ca 92110 (619)225-1980 2-Nov-83 19:01:21-EST,1363;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Nov 83 19:00:43 EST Date: Wed 2 Nov 83 18:26:52-EST From: Frank da Cruz Subject: Kermit for UCSD p-System To: Info-Kermit@CUCS20 cc: KMM%CORNELLA@CU20B This is to announce the arrival of Kermit for the UCSD p-System, written by Kate MacGregor of Cornell University Computing Services. The program is written modularly, to allow it to be brought up on any machine under the p-System by supplying some machine-dependent assembly language procedures. The implementation we have now is for the Terak, an LSI-11/2 based machine. The relevent source files are in KER:UC*.* at host COLUMBIA-20, accessible via anonymous FTP. First read UCSD.HLP, which explains how the files were renamed to fit in the KERMIT distribution area. UCKERM.HLP contains user documentation and installation instructions. Work is in progress at Cornell on an implementation for the IBM PC p-System. If anyone wants to bring up Kermit on some new machine, not under the p-System, but which has Pascal, this might be a good base from which to start. I don't know how close UCSD Pascal is to ISO Pascal, but if they are not fatally incompatible, it may be possible to adapt this version to any system by merely filling in the system-dependent routines. ------- 3-Nov-83 18:58:28-EST,1069;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 3 Nov 83 18:58:22 EST Date: Thu 3 Nov 83 18:57:23-EST From: Frank da Cruz Subject: New(er) Protocol Manual To: Info-Kermit@CUCS20 A slightly revised version of the KERMIT protocol manual has been placed in the KERMIT distribution area as KER:PROTO.* at host COLUMBIA-20 (accessible via anonymous FTP, as usual). It corrects some typos (a few of them serious, like a missing "not", the checksum formula was in octal when all numbers were supposed to be in decimal), and some minor improvements were made, mostly cosmetic. All truncated lines in the non-typeset document types (.DOC,.LPT, .FOR) were fixed to fit. A bit was added in the "how to write a KERMIT program" section about version/edit numbers, and a plea to keep all source and documentation lines to 80 characters or less, not just so they'll look nice on a screen, but also because we have to ship these things over card-image communication links. Comments welcome. - Frank ------- 3-Nov-83 19:44:17-EST,636;000000000000 Received: from CUCS20 by CU20B with DECnet; 3 Nov 83 19:44:14 EST Received: from LLL-MFE by COLUMBIA-20.ARPA with TCP; Thu 3 Nov 83 19:43:07-EST Date: Thu, 3 Nov 83 16:42 PST From: "Jones Dan%LLL"@LLL-MFE.ARPA Subject: HP9816 Kermit query. To: info-kermit@columbia-20.arpa I am looking for a version of Kermit that will run on HP9816 computers. It seems that I saw something go by about this a while back. Can someone point me to someone on the net that has sources,documentation, or information about this version of kermit. Thanks, Dan Jones 4-Nov-83 10:03:46-EST,868;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 4 Nov 83 10:03:38 EST Date: Fri 4 Nov 83 10:02:15-EST From: Frank da Cruz Subject: Re: HP9816 Kermit query. To: "Jones Dan%LLL"@LLL-MFE.ARPA, info-kermit@CUCS20 In-Reply-To: Message from ""Jones Dan%LLL"@LLL-MFE.ARPA" of Thu 3 Nov 83 19:43:17-EST I'm not sure what an HP9816 is. Is it like a 9826 or 9836? If so, a guy named Ray Adams at Oak Ridge National Lab said he would be doing Kermit for them. I haven't received any progress reports, however, and my notes don't indicate what the operating system was. Mike Gallaher at Rutgers (GALLAHER@RUTGERS) was also looking to get KERMIT going on these machines under UCSD Pascal, based on the Cornell version just announced. If I hear any news, I'll post it to the Info-Kermit list. - Frank ------- 7-Nov-83 02:23:20-EST,2126;000000000000 Return-Path: <@CUCS20:GALLAHER@RUTGERS.ARPA> Received: from CUCS20 by CU20B with DECnet; 7 Nov 83 02:23:17 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 7 Nov 83 01:53:18-EST Date: 7 Nov 83 01:49:44 EST From: GALLAHER@RUTGERS.ARPA Subject: HP9816/9826/9836 kermit available To: info-kermit%CUCS20@COLUMBIA-20.ARPA Well, it took a while, but I now have the HP9836 Kermit working well enough so I'd trust it at other sites. This version is intended to work only on the HP9836, so it is heavily dependent on the HP pascal extensions, mostly the module facility. It probably will not be easy to port to non-HP machines. The actual Kermit protocol routines are from the RT-11 Pascal version from Ontario/CU. The user interface has been completely rewritten - one of our requirements was that it be reasonably idiot-proof. The current version is minimal, and at this point is really a prototype. It will only transfer text files, only one file at a time, and the error handling is not the greatest, but it works for everything it's supposed to do. I plan to be adding a lot to this implementation quite soon, to improve the user command interface, improve error handling, add login packets, and maybe binary transfers. The important features (marked by +) and misfeatures (marked by -) of the current version are - errors not handled gracefully - only transfers one file at a time - does not handle wild cards - only transfers text files + continuous status display during file transfers + can talk to a server - does not handle timeouts - only acts as local Kermit + reasonably friendly command interface, modeled after TOPS-20 COMND facility. I have made the sources and documentation available on RUTGERS.ARPA in KRM*.TEXT. There are six source files, which contain about a dozen modules altogether. They use only the recommended library routines and such that HP distributes. The file KRMDOC.TEXT summarizes the (mis)features and gives details on how to run this Kermit. Mike Gallaher Gallaher@Rutgers.Arpa ------- 7-Nov-83 12:22:26-EST,574;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 7 Nov 83 12:22:21 EST Date: Mon 7 Nov 83 12:21:15-EST From: Frank da Cruz Subject: Re: HP9816/9826/9836 Kermit To: Info-Kermit@CUCS20 The version of UCSD Pascal Kermit which Mike Gallaher announced from Rutgers for the HP98xx series is on line at Columbia-20 as KER:HP9*.*. The file KER:HP9KERMIT.HLP lists the other files, the renaming conventions, and so forth. The file KER:HP9KERMIT.DOC is Mike's documentation for this implementation of KERMIT. ------- 7-Nov-83 13:51:56-EST,1099;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 7 Nov 83 13:51:31 EST Date: Mon 7 Nov 83 13:50:21-EST From: "Nick Bush" Subject: New Kermit-10 and VMS Kermit available To: INFO-KERMIT@CUCS20 There are new versions of Kermit-10 and VMS Kermit available on Columbia-20 KER:. Kermit-10 files are KER:K10*.*, plus KER:VMSMSG.BLI and KER:VMSTT.BLI (common sources with VMS Kermit). VMS Kermit files are KER:VMS*.* plus KER:K10VMS.MEM. These versions include a substantial number of enhancements and bug fixes. Both Kermits are now full servers, can run in both local and remote modes, and can send commands to servers. Both Kermits now support eigth-bit quoting, repeat compression, 2 character checksums and 3 character CRC-CCITTs. Both also support aborting (or skipping) files during transfers by typing control-X (to skip one file) or control-Z (to skip the rest of the group), as well as supporting this functionality in the other Kermit. For more information on changes see KER:K10VMS.MEM on Columbia-20. ------- 7-Nov-83 14:10:55-EST,1429;000000000000 Return-Path: <@CUCS20:OC.WBC3@CU20B> Received: from CUCS20 by CU20B with DECnet; 7 Nov 83 14:10:48 EST Received: from CU20B by CUCS20 with DECnet; 7 Nov 83 14:09:40 EST Date: Mon 7 Nov 83 14:09:58-EST From: Bill Catchings Subject: Kermit for the Rainbow To: info-kermit@CUCS20 I've been meaning to send this announcement for about two weeks. Sorry it took so long in coming. There is now a preliminary version of Kermit for the Rainbow running CP/M. It has the following restrictions: Runs under CP/M-86/80 version 1 only, not tested under version 2. . Does not run under MS DOS. . Terminal emulation is sluggish. Barely keeps up at 4800 baud. . No wildcard SEND yet. . Some server commands are supported, but not GET (yet). . There is code to keep DTR up, but it has not been tested. . There may be rough edges and bugs here and there. You should be able to download the program using the old KERMIT on the Z80 side. The program is stored in the distribution area as RB*.*. RBKERMIT.CMD is the executable program. RBKERMIT.H86 is the hex file (you can use GENCMD on the Rainbow to build the .CMD file from this). RB*.A86 are the source modules, written in Digital Research CP/M-88 assembler and assembled on the Rainbow. Please send any comments or complaints. I will put in a few more hours to correct the major shortcomings and bugs. -Bill Catchings ------- 8-Nov-83 10:27:52-EST,4037;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 8 Nov 83 10:27:45 EST Date: Tue 8 Nov 83 10:25:58-EST From: Frank da Cruz Subject: KERMIT for CP/M-80 To: Info-CPM@BRL-VGR.ARPA, Info-Micro@BRL-VGR.ARPA cc: Info-Kermit@CUCS20 A few months ago, I announced the file transfer protocol KERMIT to the Info-CPM and Info-Micro lists. I never got very much feedback about it, though I have seen it mentioned now and then on both lists. For those of you who missed the announcement, the KERMIT distribution area is on host COLUMBIA-20, in the area KER:, accessible with anonymous FTP. It's a big area (but nothing to rival the size of the CPM archives, of course), so if you're interested, you should look first at the file KER:00README.TXT, which lists what versions are available and describes the naming conventions. KERMIT is available for a wide variety of micros and mainframes. KERMIT for CP/M provides terminal emulation and file transfer. Versions for about 15 different systems are built from a common source file, written in standard DR ASM for the 8080, using conditional compilation, either on the micro itself or on a DEC-10 or -20 using the cross assembler MAC80 (which is itself available in the KERMIT area). A few weeks ago, a new version of CP/M-80 KERMIT, v3.5, was announced to the Info-Kermit list, with a plea that users of the various systems supported by KERMIT-80 (as it's called) report back as to whether the new version worked on their systems. I had hoped to get the bugs ironed out before announcing it to the world at large. Unfortunately, I got very few reports. Since we lack examples of most of these systems at Columbia to try the new KERMIT-80 out on, I'm announcing it now anyway. If you have any of the systems listed below, please try to get KERMIT for your machine, try it out, and: (a) let me know if it works; (b) if it doesn't, describe the symptoms; (c) if you can provide a fix, please do so (you'll be given full credit). Here are the systems: System: Filename: Status: DEC VT-180 KER:CPMROBIN.HEX Tested, works up to 4800 baud DEC Rainbow-100 KER:CPMRAINBO.HEX Tested, works up to 1800 baud DEC DECmate II KER:CPMDMII.HEX Tested, works up to 9600 baud Heath/Zenith 89 KER:CPMHEATH.HEX Not tested Heath/Zenith 100 KER:CPMZ100.HEX Not tested Apple II* KER:CPMAPPLE.HEX Not tested TRS-80 II** KER:CPMTRS80.HEX Not tested Osborne 1*** KER:CPMOSBORN.HEX Tested, doesn't seem to work at all Intertec Superbrain KER:CPMBRAIN.HEX Not tested Kaypro II KER:CPMKAYPRO.HEX Tested, mostly works OK. Telcon Zorba KER:CPMTELCON.HEX Not tested Vector Graphics KER:CPMVECTOR.HEX Not tested Ohio Scientific KER:CPMOSI.HEX Not tested Generic CP/M 2.x KER:CPMGENERI.HEX Tested OK on Rainbow, DECmate, VT180 Generic CP/M 3.0 KER:CPMPLUS.HEX Not tested *With Z80 soft card, Hayes micromodem II **With CP/M 2.25 ***Can you fix it? You can download the .HEX file with MODEM, or your old version of KERMIT, or any other technique that works, and then load it using the CP/M LOAD command, to produce a runnable .COM file. The generic versions are supposed to run on any CP/M-80 system, since they don't use only CP/M calls for device manipulation. The 2.x generic version depends on the system having fully implemented the "option" IOBYTE business, and the user setting the values of the IOBYTE correctly and re-building. The 3.0 generic version should run as-is on any CP/M 3.0 system; it has been reported to work (in an earlier version of KERMIT-80) on the Osborne Executive and the Micro Mate. The source for all these versions is in KER:CPMBASE.M80. There's also a file KER:CPMKERMIT.DOC which explains the situation in greater detail. - Frank da Cruz, Columbia University ------- 9-Nov-83 11:05:26-EST,509;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Nov 83 11:05:19 EST Date: Wed 9 Nov 83 11:03:17-EST 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 It should be in the next release of KERMIT-20. The only thing I have to go on is what's in the DEC-20 MODEM program; I have no way to test it. - Frank ------- 9-Nov-83 16:25:37-EST,800;000000000000 Return-Path: <@CUCS20:INFO-IBMPC@USC-ISIB> Received: from CUCS20 by CU20B with DECnet; 9 Nov 83 16:24:39 EST Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Wed 9 Nov 83 15:38:58-EST Return-Path: Received: FROM CMU-CS-CAD BY USC-ISIB.ARPA WITH TCP ; 9 Nov 83 11:50:21 PST Date: 9 Nov 1983 14:40:16-EST From: Greg.Glass@CMU-CS-CAD To: info-ibmpc@usc-isib Subject: kermit and direct connect modem Remailed-Date: 9 Nov 1983 1237-PST Remailed-From: Dick Gillmann Remailed-To: info-kermit@COLUMBIA-20 Has anyone modified kermit to work with one of the direct connect modems that plug into the pc bus? What modem? Also has anyone used the new modem that Qubie(?) is selling for about $290 for 1200 baud? (the one with a z8) Greg 9-Nov-83 17:09:32-EST,735;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Nov 83 17:09:16 EST Date: Wed 9 Nov 83 17:07:41-EST From: Daphne Tzoar Subject: Re: kermit and direct connect modem To: info-kermit@CUCS20 cc: greg.glass@CMU-CS-CAD.ARPA I know of two people using Kermit with the Hayes Smartmodem. One uses the plug in board modem, and one uses the external modem. As far as I know, neither has problems. The only restriction that I know of is that you can send the number to dial, but you can't pick a number from a stored list of numbers. They issue the 'connect' command and then type in data needed by the modem. For more details, send me mail. /daphne ------- 10-Nov-83 17:06:07-EST,825;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 10 Nov 83 17:05:59 EST Date: Thu 10 Nov 83 17:02:54-EST From: Daphne Tzoar Subject: Filename Bug with DOS To: info-ibmpc@USC-ISIB.ARPA, info-kermit@CUCS20 I just came across a strange problem. I had a file on our DEC-20, LOGIN&.CMD, which is stored as LOGIN^V&.CMD -- that is, with a Control-V before the special character. I tried to send it to the IBM PC using Kermit, which uses the DOS function call (int 21H) to create a file. DOS complained with the error DISK FULL. When I renamed the file to LOGIN.CMD it worked OK. It seems, therefore, that the disk was not full but rather there is a bug in DOS if there is a non-standard character in the filename. Has anyone seen this before? ------- 14-Nov-83 19:25:28-EST,466;000000000000 Received: from CUCS20 by CU20B with DECnet; 14 Nov 83 19:25:20 EST Received: from LLL-MFE by COLUMBIA-20.ARPA with TCP; Mon 14 Nov 83 16:13:27-EST Date: Mon, 14 Nov 83 13:11 PST From: "Jones Dan%LLL"@LLL-MFE.ARPA Subject: Rsx-11/M kermit To: info-kermit@columbia-20.arpa Is there a version of kermit for RSX-11/M available yet? I noticed that Frank mentioned a version forthcoming that was written in macro-11. Dan Jones 14-Nov-83 19:57:08-EST,754;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 14 Nov 83 19:57:01 EST Date: Mon 14 Nov 83 19:55:42-EST From: Nick Bush Subject: Re: Rsx-11/M kermit To: "Jones Dan%LLL"@LLL-MFE.ARPA cc: info-kermit@CUCS20 In-Reply-To: Message from ""Jones Dan%LLL"@LLL-MFE.ARPA" of Mon 14 Nov 83 19:25:36-EST The version of Kermit that Frank mentioned is actually a version that is being written (at Stevens Institute of Technology) to run on the DEC Pro-3xx systems under P/OS. Since P/OS is 99% RSX-11M+, we fell it should not be very difficult to make it run under normal RSX-11M. Note however, that there may be some unforeseen problems since none of us are RSX-11M people. - Nick Bush ------- 17-Nov-83 10:26:12-EST,3618;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 17 Nov 83 10:26:04 EST Date: Thu 17 Nov 83 10:24:01-EST From: Frank da Cruz Subject: New release of KERMIT-20 To: Info-Kermit@CUCS20 It's not all you'd ever want, but it's better than before... KERMIT-20 Version 3B(122), differences from version 3A(66) ---------------------------------------------------------- MAJOR DIFFERENCES: 1. File i/o completely rewritten to prepare for future addition of new server commands. 2. DEFINE command added for definition of SET macros, for instance: DEFINE IBM (to be) PARITY MARK, DUPLEX HALF, HANDSHAKE XON SHOW MACROS shows the current macro definitions. 3. TAKE command to allow commands to be taken from a file, with nesting. 4. Automatic TAKE of KERMIT.INI upon startup. KERMIT.INI can contain DEFINE commands for the various systems you would be communicating with. 5. Interruption of file transfer in both local and remote mode (KRFC #1) In local mode, typing ^X interrupts the current file and skips to the next, typing ^Y skips the rest of the batch. These always work when sending files (except that the receiver may still keep the partial transmitted file, and work for receiving files only if the sender understands the interrupt request. In remote mode, KERMIT-20 responds to interrupt requests. 6. Separate remote and local mode top-level command tables. Since most users of KERMIT-20 use it only in remote mode, they will no longer be confused by commands like "FINISH" and "BYE". 7. ITS binary files are now handled (KRFC #3). 8. Help text for SET command broken up, so you can say "help set escape", etc. MINOR IMPROVEMENTS AND CHANGES: In local mode, ^A may be typed for a report on the file transfer in progress. . Server operations may now be recorded in the debugging log. . Don't parse for initial filespec in SEND if source file not wild. . SET ABORTED-FILE renamed to SET INCOMPLETE. . Minor improvements to statistics display. . Allow ^C to interrupt a stuck BYE or FINISH command. . Server accepts "I" packets (KRFC #1). . SET HANDSHAKE allows specification of line turnaround character. BUG FIXES: Mod 64 packet number compares fixed. . NAK bad packet immediately, don't wait for timeout. . Various bugs fixed relating to ^C trap, exiting and continuing, etc. . Proceed gracefully after file i/o errors. . Correctly assess the file byte size when sending in server mode. . Release TTY and file JFNs in some places where they weren't before. . Don't truncate error message in error packet prematurely. WHAT'S NEXT: Future releases of KERMIT-20, which should be coming along within a month or two, will have the following features: Transaction logging. Support for 8th-bit prefixing, to allow passing 8-bit binary data through a 7-bit communications link. Repeat count processing to allow compression of repeated characters. Support for 2-character checksums and 16-bit CRCs. Additional server functions, particularly for file and job management. Some file attribute support. ARPANET TAC binary mode negotiation. The new release is available via anonymous FTP from host COLUMBIA-20 in the files KER:20KERMIT.EXE and KER:20KERMIT.MAC. It has been tested in a variety of environments with files of various types and sizes, but our quality control department is not infallible. If you discover any bugs, or have any comments, please report them to me. - Frank ------- 18-Nov-83 12:46:34-EST,964;000000000000 Return-Path: <@CUCS20:G.TJM@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 18 Nov 83 12:46:24 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Fri 18 Nov 83 12:43:02-EST Date: Fri 18 Nov 83 09:40:08-PST From: Ted Markowitz Subject: VT100 emulation for the PC/XT To: info-kermit@COLUMBIA-20.ARPA Not having looked at the code in detail... why can't Kermit support VT100 emulation rather than just VT52? I just received a PC, so forgive any obvious lack of knowledge, but I have seen other emulators for VT100 compatibility. Also, I've had a strange situation transferring file to my XT. I was using TOPS-20 Kermit to send a 60-page file to the XT's hard disk. Everything went smoothly, until I checked the output file. It had 0 characters in it! There was no problem with files of the same name, available space on the disk (I tried it on a new diskette also), etc. Any ideas? --ted ------- 18-Nov-83 15:39:15-EST,778;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 18 Nov 83 15:38:45 EST Date: Fri 18 Nov 83 15:36:12-EST From: Frank da Cruz Subject: Re: VT100 emulation for the PC/XT To: G.TJM@SU-SCORE.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Ted Markowitz " of Fri 18 Nov 83 12:44:05-EST Full VT100 emulation is quite a big deal, and no one has written the prodigious amount of code required who is willing to give it away. You'll notice there are several VT100 emulation packages for the PC on the commercial market. As to your problem with the empty file on the hard disk, contact Daphne directly with the details; I'm sure she'll be able to figure out what went wrong. - Frank ------- 23-Nov-83 01:54:32-EST,1460;000000000000 Return-Path: <@CUCS20:DIAMANT@CWRU20> Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 01:54:24 EST Received: from CWRU20 by CUCS20 with DECnet; 23 Nov 83 01:56:57 EST Date: Wed 23 Nov 83 01:54:40-EST From: John Diamant Subject: Transfers between IBM PC and UNIX To: info-kermit@CUCS20 I have been trying to get kermit to run on our VAX 11/780 (running 4.1BSD), for file transfers to my IBM PC. We currently have a version (about 6 months old) which receives properly, but hangs when I try to send files (CR's don't help). This happens before a single packet is sucessfully sent. In an attempt to fix that, I copied kermit.c from the columbia-20 archives in the last few days. I now have a version which sends and receives, but when I am receiving a file, it hangs when it gets to the end of the file. I have tried running this with Ricekermit as well (also newest version on columbia-20). The version I am running on my IBM is 1.3A (again newest version not including the one currently being tested). Is there anything special I have to do when I compile these? Has anybody else run across similar problems? By the way, I tried the file transfers from an apple to the vax as well, and the VAX acted the same in all cases, so I doubt it is the IBM version causing the problem. Thanks, John Diamant DIAMANT%CWRU20@COLUMBIA-20 (ARPA) or diamant.Case@Rand-Relay (Also ARPA) ------- 23-Nov-83 04:33:21-EST,903;000000000000 Return-Path: <@CUCS20:G.FUSSELL@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 04:33:18 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Wed 23 Nov 83 04:35:49-EST Date: Wed 23 Nov 83 01:21:43-PST From: Carl Fussell Subject: kermit-11 To: info-kermit@COLUMBIA-20.ARPA Address: Santa Clara University We have a number of DEC LSI-11/03's and 11/23's running RT11 (V.4) that we would like to run kermit on. I have obtained a couple different versions of kermit for 11's but neither work. Making them work appears to be more than a 10-15 miniute repair job so before I spend a large amount of time working on them, I was hoping to perhaps find someone out there who already has a version running under similar conditions. If you do, I would really appreciate hearing from you.... Thanx.... Carl ------- 23-Nov-83 04:45:29-EST,1446;000000000000 Return-Path: <@CUCS20:ELWELL@CWRU20> Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 04:45:25 EST 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. Received: from CWRU20 by CUCS20 with DECnet; 23 Nov 83 04:35:52 EST Date: Wed 23 Nov 83 04:33:37-EST From: Clayton Elwell Subject: problems with kermit.c To: info-kermit@CUCS20 I uploaded PS:KERMIT.C from COLUMBIA-20 to my CP/M system by capturing the typeout text. I then integrated the code into my terminal program (written in C). The code compiled beautifully. I now can receive files and batches of files from our DEC20 (running Kermit-20, though not the very latest version) with no problem. However, when I try to send a file to the DEC20, the Kermit-20 bombs, saying ("retry count exceeded in RDATA") or something similar. I have not touched the code. Does anyone have any idea what's wrong? It may be related to the problem that DIAMANT@CWRU20 just mentioned on this list... Thanks, Clayton Elwell Elwell%CWRU20@COLUMBIA-20 OR Elwell.Case@Rand-Relay OR {usenet}!decvax!cwruecmp!elwell ------- 23-Nov-83 09:45:49-EST,1263;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 09:45:44 EST Date: Wed 23 Nov 83 09:47:41-EST From: Frank da Cruz Subject: Re: kermit-11 To: G.FUSSELL@SU-SCORE.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Carl Fussell " of Wed 23 Nov 83 04:35:58-EST Currently, we only have the OMSI Pascal version of KERMIT for RT-11, which doesn't do much for the majority of RT-11 installations that don't have OMSI Pascal. There are currently several other possibilities in the works: 1. Someone, somewhere, is attempting to get the UNIX version to run under DECUS C. 2. Brian Nelson at the University of Toledo is writing a version of KERMIT in Macro-11 for RSTS/E. He says he will write it with all the system dependencies isolated into small routines so that it will be readily adaptable to RT-11 and RSX-11 by plugging in new versions of those routines. 3. Stevens Institute of Technology is writing KERMIT for the DEC Pro-350 with P/OS in a combination of Bliss and Macro-11. This one would be somewhat harder to adapt to RT-11. I don't have any of these in hand yet; (2) seems like the best bet for RT-11. - Frank ------- 23-Nov-83 10:45:33-EST,1491;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 10:45:22 EST Date: Wed 23 Nov 83 10:47:07-EST From: Frank da Cruz Subject: KERMIT and TAC To: Info-CPM@BRL.ARPA, Info-Kermit@CUCS20 I've been told by someone who knows about these things (Mark Crispin at Stanford) that there's no good way to make KERMIT-20 put the TAC in binary mode, at least not in a way that doesn't depend on a bug in TOPS-20 that may be present at some sites but fixed at others (the bug being that FF (a byte with all 1's) is supposed to be quoted by doubling in the monitor, but isn't, so some application programs do it instead). Therefore, the way to use KERMIT over a TAC would seem to be: 1. Set the TAC escape character to be any control character other than ^A or CR, LF, etc. ^A is KERMIT's packet synchronization character, and CR or LF might be used as line terminators at the end of packets (KERMIT never puts any control characters inside the packets). Also, choose the character to be something you're unlikely to type during your timesharing session. For instance, as Keith Petersen suggests, use ^E. Do this by typing "@I 5" (for ^E) to the TAC. This allows "@" to be transmitted. 2. To send binary files, type "@B O S" and "@B I S" to the TAC (if you already did step 1, then I suppose you would type "^EB O S" and "^EB I S"). I'm not a TAC user myself, so I can't vouch for any of this. - Frank ------- 23-Nov-83 11:24:10-EST,2241;000000000000 Return-Path: <@CUCS20:OC.GARLAND@CU20B> Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 11:23:59 EST Received: from CU20B by CUCS20 with DECnet; 23 Nov 83 11:26:14 EST Date: Wed 23 Nov 83 11:22:55-EST From: Richard Garland Subject: [Nick Bush : Re: VAX kermit] To: info-kermit@CUCS20 I asked Stevens Institute about a problem with VAX/VMS kermit hanging up the line on outgoing connects after escaping back to do file trans- fers. The reply may be of interest to others: Rg --------------- Mail-From: OC.BUSH created at 22-Nov-83 18:26:48 Date: Tue 22 Nov 83 18:26:48-EST From: Nick Bush Subject: Re: VAX kermit To: OC.GARLAND@CU20B cc: oc.sitgo@CU20B In-Reply-To: Message from "Richard Garland " of Tue 22 Nov 83 11:35:42-EST The problem occurs because VMS Kermit does not allocate the terminal line and deassigns it when returning from the CONNECT command. It turns out that VMS will drop DTR whenever a terminal line which was declared to be a modem becomes free (neither allocated nor assigned). The solution is to allocate the terminal line before entering Kermit. That way the terminal will never become "free" until it is explicitly deallocated by a DCL command. I'll think about putting the code into Kermit to allocate the line when a SET LINE is given and release it when exiting (or changing lines). It would still be a good idea to allocate the terminal line in that case anyway, since otherwise exiting Kermit would cause the line to hangup (which is not always desired). I ran into another version of this problem: I forgot to allocate a terminal line (non-modem line) and started up a Kermit in Server mode on the other end. After returning to VMS Kermit I had a hard time getting the terminal line back, since the NAK's which the Server was sending out were being taken as unsolicited input and causing LOGINOUT to run. It would eventually time out, just about in time for the next NAK to show up. Anyway, at least for the current version of VMS Kermit, the user should allocate the terminal line from DCL before attempting to use it from Kermit. - Nick ------- ------- 23-Nov-83 22:12:38-EST,756;000000000000 Return-Path: <@CUCS20:MRC@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 22:12:34 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Wed 23 Nov 83 22:15:14-EST Date: Wed 23 Nov 83 19:10:47-PST From: Mark Crispin Subject: Re: KERMIT and TAC To: cc.fdc@COLUMBIA-20.ARPA cc: Info-CPM@BRL.ARPA, Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Frank da Cruz " of Wed 23 Nov 83 09:46:12-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I believe that @ B I S will suffice to disable the TAC escape character, so the step of setting it with @I should be unnecessary. ------- 24-Nov-83 09:52:52-EST,1518;000000000000 Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID> Received: from CUCS20 by CU20B with DECnet; 24 Nov 83 09:52:48 EST Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Thu 24 Nov 83 09:55:31-EST Date: 23 Nov 1983 20:52-PST Sender: ABN.ISCAMS@USC-ISID Subject: Re: KERMIT and TAC From: ABN.ISCAMS@USC-ISID To: MRC@SU-SCORE Cc: cc.fdc@COLUMBIA-20, Info-CPM@BRL Cc: Info-Kermit@COLUMBIA-20 Message-ID: <[USC-ISID]23-Nov-83 20:52:55.ABN.ISCAMS> In-Reply-To: The message of Wed 23 Nov 83 19:10:47-PST from Mark Crispin Talking about disabling (or changing) the TAC escape character.. I just had a (polite but sincere) talking to by my TAC owners... Seems they don't really like so very much when users start messing about with their ports! (I never changed the excape character because I suspected it would cause people problems.) I DID leave F O S set a couple of times (makes XON/XOFF happen at the TAC level for immediate halting of a listing while my software writes to file) -- usually when the system choked up and I got thrown off! Turns out any of those convenient settings we users make to ports STAY THAT WAY when we leave/sign off unless we specifically reset them to the way things were -- and that sure can mess up the next guy. I'd suggest anyone playing with their TAC maybe check with the operators first to kind of work out an agreement. If they know what and why you're doing, they tend to be much more understanding! David Kirschbaum Toad Hall 25-Nov-83 09:50:05-EST,830;000000000000 Return-Path: <@CUCS20:G.TJM@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 25 Nov 83 09:50:01 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Fri 25 Nov 83 09:52:44-EST Date: Fri 25 Nov 83 06:51:08-PST From: Ted Markowitz Subject: Modifying PC Kermit To: info-kermit@COLUMBIA-20.ARPA A suggestion for a useful modification. A command could be added to allow a port other than the primary comm port to be used for data transfers. I ran into this while testing a windowing piece of software that coopts the primary comm port for a mouse. I'd like to be able to use the other port I've got on a memory card to still use Kermit under the window program. I looked at the source, but am still not familiar enough with 808x code to hack it out myself. --ted ------- 25-Nov-83 10:26:32-EST,434;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 25 Nov 83 10:26:30 EST Date: Fri 25 Nov 83 10:28:48-EST From: Frank da Cruz Subject: Re: Modifying PC Kermit To: G.TJM@SU-SCORE.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Ted Markowitz " of Fri 25 Nov 83 09:52:53-EST The next release of PC Kermit will be able to switch ports. - Frank ------- 25-Nov-83 17:40:38-EST,1056;000000000000 Return-Path: <@CUCS20:jalbers@BNL> Received: from CUCS20 by CU20B with DECnet; 25 Nov 83 17:40:35 EST Received: from BNL by COLUMBIA-20.ARPA with TCP; Fri 25 Nov 83 17:42:30-EST Date: 25-Nov-83 17:39:38-EST From: jalbers@BNL Subject: I GIVE UP!!!!!!!!!!! To: info-kermit@COLUMBIA-20 After trying to get KERMIT up on an Osborne Exec for about 3 months, I GIVE UP! Thanks for all the help I got from the people on the net, but it was no use. I want to ask whoever it was who put together that file to get in contact with me since the host I was using untill October is now down and I still do want to get it up. I got contacted by 4 other Exec owners who all had the same problems as I did getting it up, and the only explanition I can give is there must be 2 different versions of CP/M 3 out for it. "...as he groped for the escape key..." Jon Albers jalbers@bnl 26-Nov-83 12:41:39-EST,971;000000000000 Return-Path: <@CUCS20:w8sdz@brl> Received: from CUCS20 by CU20B with DECnet; 26 Nov 83 12:41:35 EST Received: from BRL by COLUMBIA-20.ARPA with TCP; Sat 26 Nov 83 12:44:07-EST Date: Sat, 26 Nov 83 12:39:18 EST From: Keith Petersen To: Mark Crispin cc: cc.fdc@columbia-20.arpa, Info-CPM@brl.arpa, Info-Kermit@columbia-20.arpa Subject: Re: KERMIT and TAC If you do @B I S to the TAC you don't have ANY intercept character at all and it's then impossible to @C (close) the connection between the TAC and your host after you're done. I'm not certain but I think this may leave a "hanging job" on your host. The @I 5 command to set the TAC for control-E intercept works fine with KERMIT for text files and when you are done the TAC reverts to the normal "@" intecept for the next caller so no one will be unhappy with you changing the intercept character for the duration of your connection. --Keith 26-Nov-83 15:21:15-EST,1043;000000000000 Return-Path: <@CUCS20:MRC@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 26 Nov 83 15:21:11 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Sat 26 Nov 83 15:23:43-EST Date: Sat 26 Nov 83 12:22:07-PST From: Mark Crispin Subject: Re: KERMIT and TAC To: w8sdz@BRL.ARPA cc: cc.fdc@COLUMBIA-20.ARPA, Info-CPM@BRL.ARPA, Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Keith Petersen " of Sat 26 Nov 83 09:42:56-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In my humble opinion, any host which fails to hang up the connection when the user logs out should be disconnected from the ARPANET until they fix their software! @ B I S is the means of getting into binary mode on the TAC, and no host should make that mode useless. Disabling the TAC intercept character is necessary if you want true binary I/O. Hosts ought to work well enough so this functionality is usable. ------- 26-Nov-83 17:02:51-EST,783;000000000000 Return-Path: <@CUCS20:w8sdz@brl> Received: from CUCS20 by CU20B with DECnet; 26 Nov 83 17:02:44 EST Received: from BRL by COLUMBIA-20.ARPA with TCP; Sat 26 Nov 83 17:05:08-EST Date: Sat, 26 Nov 83 16:54:27 EST From: Keith Petersen To: Info-Cpm@brl-vgr, Info-Kermit@columbia-20 Subject: Re: KERMIT and TAC If the host software is properly written it should be possible for the operating system to send instructions to the TAC, telling it to enter and exit BINARY mode. UMODEM (for UNIX), MODEM (for TOPS-20) and MMODEM (for ITS at MIT) all do this sucessfully, making it unnecessary for the user to "lose control" of his TAC. I frequently connect to several hosts during one TAC session and "losing control" is unacceptable to me. -Keith 27-Nov-83 12:14:21-EST,2753;000000000000 Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID> Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 12:14:17 EST Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 12:14:43-EST Date: 27 Nov 1983 08:52-PST Sender: ABN.ISCAMS@USC-ISID Subject: Re: KERMIT and TAC From: ABN.ISCAMS@USC-ISID To: MRC@SU-SCORE Cc: w8sdz@BRL, cc.fdc@COLUMBIA-20, Info-CPM@BRL Cc: Info-Kermit@COLUMBIA-20 Message-ID: <[USC-ISID]27-Nov-83 08:52:58.ABN.ISCAMS> In-Reply-To: The message of Sat 26 Nov 83 12:22:07-PST from Mark Crispin Mark (also also Keith at W8SDZ): Fully agree with the host properly hanging up/reconfiguring. The KERMIT patch, though is SO very simple. Atchd is my patch I recently sent to a local user who's emulating an IBM PC (kind of) with a Wang PC. Same problem; same fix outta work. David Kirschbaum Toad Hall To: ABN.20E-SP@USC-ISID Subject: Re: TAC X/ON X/OFF In-Reply-To: <[USC-ISID]26-Nov-83 13:42:41.ABN.20E-SP> ------------------------------------------------------------------------ Sir, I don't have the source code of PCKERMIT available now, so I can't move an actual patch over to you. However -- if you can grab the chunk of assembler that actually sends characters out the port when sending packets (in my version its the section with OUTCHR, OUTCH0, OUTCH1, etc...) and move/message it to me, I can put in the patches. What you do is get the character from a register or memory (wherever KERMIT put it)(the character you want to send as part of a packet, that is, and compare it to 40H (the @ sign). If it isn't an @ sign, just go ahead and send it. If it IS -- send it twice!. In my code (8080), it looks like this... outchr: mov a,e ; get the char into A call setpar ; This is the routine that sets parity on ; the char to your desires. I moved it ; up here to keep it out of the TAC loop. mov e,a ; Put the character back into E while we ; use A to check port status. cpi 40h ; compare immediate A with the @ sign. cz outch1 ; Yep - got an @. Call the OUT routine to ; send it the first time, and fall through to ; send it the second time (elegant, no?) outch1: in mnprts ; Get the output ready flat from the Tx ; status port. ani output ; Is the ready bit set? jz outch1 ; Not ready, loop... mov a,e ; Char back into A register outch2: out mnport ; Put it out the modem port (finally). ret ; Return the first time to the OUTCHR ; call, the second time (if there IS a second ; time) to whatever called this. That's all there is to it! Now your code and registers are going to be a bit different, but basically the simple idea works. Have fun... SGM K 27-Nov-83 13:57:10-EST,2947;000000000000 Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID> Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 13:57:05 EST Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 13:57:27-EST Date: 27 Nov 1983 10:51-PST Sender: ABN.ISCAMS@USC-ISID Subject: Re: KERMIT and TAC From: ABN.ISCAMS@USC-ISID To: MRC@SU-SCORE Cc: w8sdz@BRL, cc.fdc@COLUMBIA-20, Info-CPM@BRL Cc: Info-Kermit@COLUMBIA-20 Message-ID: <[USC-ISID]27-Nov-83 10:51:12.ABN.ISCAMS> In-Reply-To: The message of Sat 26 Nov 83 12:22:07-PST from Mark Crispin PCKERMIT users: Here's a patch to PCKERMIT to hopefully solve the TAC intercept character problem with no hassles about resetting TACs. Now, please check this out for me -- I'm an 8080/Z80 hacker and donno nuttin about 8086/8088 code except what I reasoned out of the PCKERMIT source. Regards, David Kirschbaum Toad Hall ;************************System Dependent**************************** ; Put a char in AH to the port. PORT PROC NEAR IF ibmpc outchr: sub cx,cx ; [14 start] mov al,ah ; Parity routine works on AL. [16] call dopar ; Set parity appropriately. [10] mov ah,al ; Don't overwrite character with status. [16] mov dx,03FDH ; Toad Hall note: hokay - now we got the char in ah. Need to test and see ;if it's the infamous TAC intercept character (@ in this case). Sending it ;twice will tell the TAC that it's a true ASCII character for the host: the ;TAC will then send a single @ on to the host, and echo one more back to you. ;If it is, we'll call OUTCH1 to put it out once, and then fall through to :put it out the second time. If it isn't, we'll just send one character. ; PS: Somebody with a manual on this assembler language check this out ; for me - I'm only guessing at the mnemonics since I'm a Z80/8080 hacker. cmp ah,40h ; Is it the @? cz outch1 ; Yep, send it the first time.. ; ...and fall through for the second. ; Else just send it once. [Toad Hall] ;End of Toad Hall TACpatch outch1: in al,dx test al,20H ; Transmitter ready? jnz outch2 ; Yes loop outch1 jmp r ; Timeout outch2: mov al,ah ; Now send it out mov dx,03F8H out dx,al jmp rskp ; [14 end] ENDIF IF Z100 outchr: mov al,ah ; Yes, get the character into al mov cx,0 call dopar ; Set parity appropriately. [10] ; Toad Hall Note: somebody check this for me -- I assume here that ; ah has not been trashed by the DOPAR call above, and the char is ; still in ah. I also assume the BIOS-AUXOUT call don't do nuttin ; to ah or al or wherever the char is being accessed so we can in ; fact call and put it out twice in a row. [Toad Hall] cpi ah,40h ; Is the char an @ (TAC intercept char)? cz bios-auxout ; Yep - send it once... ; ...and fall through to send the 2nd... ; End of Toad Hall TACpatch. outch1: call bios_auxout ; Send the character jmp rskp ENDIF  27-Nov-83 14:10:40-EST,1399;000000000001 Return-Path: <@CUCS20:w8sdz@brl> Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 14:10:37 EST Received: from BRL by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 14:00:54-EST Date: Sun, 27 Nov 83 13:54:36 EST From: Keith Petersen To: Info-Kermit@columbia-20 cc: Info-Cpm@brl-vgr Subject: Bug fix for Kermit-80 ver 3.5 There is a bug in the CONNECT (dumb terminal) function of CPMBASE.ASM. It causes continuous NULLs to be sent out to the modem when there are no characters ready from the console keyboard. This bug occurs in all versions except ROBIN or RAINBO or GENER or DMII. Two lines of code were mis-placed. Below is a listing of the corrected area. CONCHR: IF NOT (ROBIN OR RAINBO OR GENER OR DMII) MVI C,DCONIO ; Direct console I/O BDOS call. MVI E,0FFH ; Input. CALL BDOS ENDIF ; NOT (robin OR rainbo OR gener OR dmII) IF ROBIN OR RAINBO OR GENER OR DMII CALL BCONST ; Get the status CALL BCONIN ; Yes, get the character ENDIF ; robin OR rainbo OR gener OR dmII ORA A ; Anything there? <-----corrected JZ RSKP ; No, forget it <-----corrected ANI 7FH ; Keep only 7 bits ........ End of corrected area 27-Nov-83 15:24:06-EST,584;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 15:23:59 EST Date: Sun 27 Nov 83 15:23:51-EST From: Daphne Tzoar Subject: Re: Modifying PC Kermit To: G.TJM@SU-SCORE.ARPA cc: info-kermit@CUCS20 In-Reply-To: Message from "Ted Markowitz " of Fri 25 Nov 83 09:52:54-EST I recently added a command to let user's choose between communications port one (the primary one) and port two. It is in a version of PC Kermit that I hope to formally announce in a week or two. /daphne ------- 27-Nov-83 15:42:21-EST,516;000000000000 Return-Path: <@CUCS20:LIN@MIT-ML> Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 15:42:17 EST Received: from MIT-ML by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 15:42:34-EST Date: 27 November 1983 15:43 EST From: Herb Lin Subject: KERMIT and multiple send-receives... To: Info-Kermit @ COLUMBIA-20 In-reply-to: Msg of Wed 23 Nov 83 19:10:47-PST from Mark Crispin is this possible? thanks. pls reply to me directly, as I am not on INFO-KERMIT. tnx. 27-Nov-83 21:07:50-EST,4634;000000000000 Return-Path: <@CUCS20:BILLW@SRI-KL.ARPA> Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 21:07:39 EST Received: from SRI-KL.ARPA by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 21:07:49-EST Date: Sun 27 Nov 83 18:03:13-PST From: William "Chops" Westfield Subject: TACs and BINARY mode on TOPS20 To: info-cpm@BRL.ARPA, info-kermit@COLUMBIA-20.ARPA The problem is that the current implementation of TOPS20 is not "properly written". It is broken. It isnt even clear that it will work if you give your TAC an @B I S command sequence.... Here is the a description and solution to the BINARY MODE problem on TOPS20. --------------- Date: Mon 1 Aug 83 14:17:59-PDT From: BILLW@SRI-KL.ARPA Subject: [Frank J. Wancho : [pditmars: Binary]] To: info-modemxx@MIT-MC.ARPA, tops20@SU-SCORE.ARPA As some of you may know, there are a series of programs for downloading microcomputers from Tops-20 systems. Recently, a new version of TAC code was installed, and these programs stopped working when used through a TAC. After much searching, this was finally tracked down to a bug in Tops-20 (or a mis-feature) that was agravated by the new TAC code. A patch has been developed (and is enclosed). This patch has been tested at SRI and at SIMTEL20, and should be installed if you have any users who use the MODEM program to download micros over the ARPANet. Bill Westfield ------------- Date: 24 June 1983 12:29 EDT From: Frank J. Wancho Subject: [pditmars: Binary] To: BillW @ SRI-KL Bill, Peter patched my TAC port so that he could capture the TCP headers in a dump. I ran MMODEM on MC first, to demonstrate a working version. Then I ran your MODEM (still 125) on XX. Here's is his results so far. I thought you'd be interested... --Frank -------------------- Date: 24 Jun 1983 11:14:32 EDT (Friday) From: Pieter Ditmars To: fjw cc: taccers at BBN-UNIX, pditmars at BBN-UNIX Re: Binary Frank, Results of the dump proved inconclusive, though something funny seems to be going on. Can't see the first IAC from xx but it should be a "will binary" cause the TAC responds do binary. Then xx says wont binary and the tac gives don't binary. Finally xx sends do binary to which the TAC does not reply. Looks like we got a bug here new tests in progress will msg you when isolated. Pete Date: 27 Jul 1983 18:26-PDT From: William "Chops" Westfield To: Wancho@SIMTEL20 Cc: billw@SRI-KL Here is a bug fix that might help fix the downloading through TAC problem. First, the suspected reason it doesnt work: The 20 sends "WILL BINARY". The TAC receives this and, if binary is not already set, responds with a positive "DO BINARY" (this explains why it will work if you put the TAC in binary mode BEFORE you connect to the host). The 20 monitor receives the "DO BINARY", and is currently set to refuse this option (I consider this a bug, and plan to complain to DEC - It will help if other Net heavyweights complain also), so it sends "WONT BINARY",and the TAC responds "DONT BINARY", leaving things in NON-binary mode. The reason this probably worked in older versions of the TAC code is that the TAC probably ignored the second "DONT BINARY" and just transmitted all 8 bits from the host anyway. Thus this is really a bug in TOPS-20, and not in the new TAC code. Now, here is the fix: In module TTNTDV, at location NVTDOD, change NVTDOD: IFIW!R to NVTDOD: IFIW!RSKP (This can also be done to the binaries, of course, and its relatively safe to do to a running monitor: @MDDT call SWPMWE$x ;write enable swappable monitor NVTDOD/ SETZ RSKP ;make the change call SWPMWP$x ; write protect monitor again ^Z ;exit MDDT ) This will cause TOPS20 to reply "WILL BINARY" whenever it receives "DO BINARY", which chould not cause any problems. The PROPER thing to do is to reply positively only if the program on the other end is reading from the terminal in binary mode, and refuse otherwise. Putting the terminal in binary mode should take care of everything. Unfortunately, the relevant code (NVTMOD) has been commented out of the current monitor. Please let me know if this works... Bill Westfield ------- ------- 30-Nov-83 10:46:51-EST,4369;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 10:46:39 EST Date: Wed 30 Nov 83 10:45:45-EST From: Frank da Cruz Subject: KRFC #9, Preserving File Attributes To: Info-Kermit@CUCS20 The following is from Nick Bush of Stevens Institute of Technology. Although the Kermit protocol now provides a way to transmit file attributes, nothing is said about how to preserve them on the target system so that they can be restored correctly upon return to the system of origin. This proposal addresses the question. - Frank ---------------- Date: Tue 29 Nov 83 22:42:27-EST From: Nick Bush Subject: File attribute packet handling To: SY.FDC@CU20B After a good bit of consideration of how to handle the file attributes for Files-11 (VMS and RSX) files, I have come up with a suggestion (one which will especially impact Kermit-10 and -20). I think the acceptance of a file attribute should not imply that the attribute is really used in the destination system, only that if the file is transmitted by Kermit from that system it will send all the attributes out the same as it received. It would be best if a Kermit could handle as many of the possible attributes as possible, since then files from any system could be stored on any other system and retrieved without any modification. Right now it is not possible to store task files (.TSK) from an RSX system or .EXE files from a VMS system on a -10 or a -20 and expect to be able to get the original file back. This is because some information about the structure of the file has no corresponding attribute under either TOPS-10 or TOPS-20, and the original file cannot be recreated with the additional information. The file attributes packet does provide this information, but with the current definition there would still be no method of storing the attribute information unless the file system supported the attributes. Therefore, I suggest the following for Kermit-10 and Kermit-20 (in the theory that both should do the same thing as much as possible): 1. Some method be devised to store the file attributes (those that are not reasonable for -10's and -20's, like block size, etc.). This could possibly be an extension of the "DSK8" kludge, but would not need to recognize anything in the incoming data stream. I don't have a proposal for the exact format of the storage, but I think it would probably be easiest to store it in a form close to what it is like in the attributes message. 2. Kermit-10 and Kermit-20 (once they are taught to recognize the packet at all) should be willing and able to store any unrecognized attributes in the file using the method described above. I would assume that like other random things there should be a SET command to allow the user to enable/disable this. 3. There should be one file type defined for the attributes packet that says the file is a text file which must be stored in a format which is readable on the destination system as a text file. I assume that this is what you intended file format "A" to be. I think there needs to be some specific mention that this format must result in a file which is readable, and does not need to result in an identical file when it is transferred back to the original system, only that it should be as close as possible within the constraints of the text storage conventions of the two systems. There should probably also be an additional file type which specifies a text file which must be returnable in identical format. 4. The attributes should be split into attributes which are system independent format (or are an attempt at system independence), and those which are system dependent. I think the only system dependent item you have at the moment is ' (ASCII 44) protection code. Whether any other will be (or should be) added I don't know. One other item I just thought of while typing this in: What time zone are the date/times expressed in? GMT? Might be nice to attempt to standardize that before anyone does anything with it. Of couse, some systems don't really know what time zone they are in (TOPS-10 7.01 doesn't), so it might be tough to make it GMT. - Nick ------- 30-Nov-83 11:32:37-EST,1488;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 11:32:18 EST Date: Wed 30 Nov 83 11:31:48-EST From: Frank da Cruz Subject: Re: KRFC #9, Preserving File Attributes To: Info-Kermit@CUCS20 In-Reply-To: Message from "Frank da Cruz " of Wed 30 Nov 83 10:46:02-EST The business of storing file attributes in the file itself is, of course, very much like the "ITS Binary Format" idea. The major problem is how to distinguish attributes thus stored from file data. The answer is probably very much like the ITS answer: start the file with some kind of header which is very unlikely to be found among actual file data, but allow the user a way to override in case of an unfortunate coincidence. I'd also suggest that a new attribute be added: operating system and version. This will allow the system receiving a file which begins with an attributes header to decide whether to use (interpret) the attributes when storing the file, or simply to keep them. This way, a file can be sent with its attributes through many different systems, and only a system like the one that originated the file will attempt to interpret them. For this to work, there will have to be a standard list of codes for machines and operating systems. An alternative, or perhaps parallel idea, will be to include in the Disposition attribute an option to store or to keep the attributes. - Frank ------- 30-Nov-83 13:51:59-EST,617;000000000000 Return-Path: <@CUCS20:KPETERSEN@SIMTEL20.ARPA> Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 13:51:54 EST Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Wed 30 Nov 83 13:51:45-EST Date: Tuesday, 29 November 1983 22:10-MST Message-ID: Sender: Herb Lin From: Herb Lin To: W8SDZ@SIMTEL20 Subject: KERMIT and multiple send-receives... ReSent-From: KPETERSEN@SIMTEL20 ReSent-To: Info-Kermit@columbia-20 ReSent-Date: Wed 30 Nov 1983 11:48-MST i need kermit for a compupro interfacer 3 board. must i use generic kermit? 30-Nov-83 18:00:45-EST,1075;000000000000 Return-Path: <@CUCS20:reid@Glacier> Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 18:00:37 EST Received: from Glacier by COLUMBIA-20.ARPA with TCP; Wed 30 Nov 83 17:59:34-EST Date: Wednesday, 30 November 1983 11:47:39-PST To: Frank da Cruz Cc: Info-Kermit@COLUMBIA-20.ARPA, Mogul@Navajo Subject: Re: KRFC #9, Preserving File Attributes In-Reply-To: Your message of Wed 30 Nov 83 11:31:48-EST. From: Brian Reid Jeff Mogul of Stanford, as part of his thesis work, has had very good luck with representing file attributes as Lisp-like Properties, and transmitting a series of attribute/value pairs defining file properties along with the transmission of the file itself. The issue of system-independent file properties is a very important one, and I encourage people to think about it a bit before they dive in and implement something. Perhaps I can persuade Jeff to send around a short summary of his scheme, which incidentally was presented as a ``short paper'' at the recent SOSP symposium. Brian Reid 30-Nov-83 22:52:31-EST,819;000000000000 Return-Path: <@CUCS20:abrams@mitre> Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 22:52:25 EST Received: from mitre by COLUMBIA-20.ARPA with TCP; Wed 30 Nov 83 22:14:41-EST Date: 30 Nov 1983 22:02:26 EST (Wednesday) From: Marshall Abrams Subject: Donate computer for tax credit To: microgroups:@mitre Cc: abrams@mitre A charitable organization in the Washington, DC area would like to receive a donation of a computer. The donor would get a tax credit based on his/her valuation of the hardware and software. This would be an excellent opportunity to do a good deed and recover one's investment so that a newer configuration could be purchased. Please contact me to discuss this further. My telephone at work is 703/827-6938 and at home is 301/588-1005. Marshall Abrams 1-Dec-83 18:00:43-EST,1471;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 1 Dec 83 18:00:38 EST Date: Thu 1 Dec 83 18:00:04-EST From: Frank da Cruz Subject: KERMIT in PL/I for MULTICS available To: Info-Kermit@CUCS20 This is to announce a new version of KERMIT written in PL/I for the Honeywell MULTICS system by Paul Amaranth of Oakland University, Rochester Michigan. This is an initial release, and provides basic service, i.e. no server mode of operation. Paul will continue to develop this version; he expects to be adding server mode and other functionality in the coming months. If anyone wants to modify this program, it is suggested that you contact Paul first, to make sure that the work is not already done. Unfortunately, he's not connected to any networks, but you can call him at the number given in the source file. You should also call him if you have bugs to report. This is one of two PL/I KERMITs, developed independently. The other, for PR1ME computers done by people at The SOURCE, will be available shortly, as soon as I receive their tape. The PR1ME version will have server mode and several other advanced features. Either of these PL/I KERMITs may serve as a basis for new implementations for computers that have PL/I, such as the many IBM operating systems (DOS, MVS/TSO, MTS, GUTS, MUSIC, etc) not currently supported. Efforts in this direction are encouraged. - Frank ------- 1-Dec-83 18:46:00-EST,1077;000000000000 Return-Path: <@CUCS20:reid@Glacier> Received: from CUCS20 by CU20B with DECnet; 1 Dec 83 18:45:28 EST Received: from Glacier by COLUMBIA-20.ARPA with TCP; Thu 1 Dec 83 18:45:07-EST Date: Thursday, 1 December 1983 15:43:00-PST To: Info-Kermit@Columbia-20 Subject: next step: Kermit Mail From: Brian Reid The obvious next step in the development of Kermit is the design of a Kermit Mail protocol. Many many people have wanted "uucp" mail on their personal computers, but in fact all they really need is a way of participating in mail networks. Now that all of the hard stuff, namely reliable data transfer and protocol negotiations, is in place, it is time for somebody to start thinking about a uucp-like Kermit Mail protocol on top of it. Other than the startup/wrapup parts of the protocol, it seems to me that the right way to do is to implement the Arpa SMTP mail protocol or else the NBS message transmission standard. The world doesn't need yet another mail protocol, and uucp is more-or-less undocumented. Brian Reid Stanford 1-Dec-83 20:22:50-EST,612;000000000000 Return-Path: <@CUCS20:WANCHO@SIMTEL20.ARPA> Received: from CUCS20 by CU20B with DECnet; 1 Dec 83 20:22:21 EST Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Thu 1 Dec 83 20:21:25-EST Date: 1 Dec 1983 18:16 MST (Thu) Message-ID: From: "Frank J. Wancho" To: Brian Reid Cc: INFO-KERMIT@COLUMBIA-20 Subject: next step: Kermit Mail In-reply-to: Msg of 1 Dec 1983 16:43-MST from Brian Reid Brian, Do you remember someone recently making a suggestion that SMTP have a PROTO command?... --Frank 1-Dec-83 21:57:04-EST,795;000000000000 Return-Path: <@CUCS20:MRC@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 1 Dec 83 21:57:00 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Thu 1 Dec 83 21:56:48-EST Date: Thu 1 Dec 83 18:55:04-PST From: Mark Crispin Subject: Re: next step: Kermit Mail To: reid@SU-GLACIER.ARPA cc: Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Brian Reid " of Thu 1 Dec 83 16:38:12-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have been looking into the feasibility of doing Kermit mail with SMTP for some time. No code exists yet. Some people love Kermit, others want TOPS-20 UUCP. I'm hoping the dust will eventually settle. ------- 2-Dec-83 09:52:40-EST,1283;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Dec 83 09:52:30 EST Date: Fri 2 Dec 83 09:51:35-EST From: Frank da Cruz Subject: Re: next step: Kermit Mail To: reid%SU-Glacier@SU-SCORE.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Brian Reid " of Thu 1 Dec 83 18:45:20-EST The idea of KERMIT-based mail has come up often in recent months. Of course, no version of KERMIT was ever written with this in mind, so to unravel these programs to support SMTP (or whatever) as an alternate application above the transport-level stuff would be a major undertaking. Anyone about to write a new KERMIT from scratch should design for this. I'll be thinking about how to change the protocol manual to allow for multiple applications. For TOPS-20 in particular, which has extensive mail support already in the form of MM, MMAILR, MMAILBOX (or however you spell it), etc, it would be silly to try to incorporate all of that into KERMIT. It has been suggested that a better approach would be to isolate the transport-level functions into a library that could be shared by KERMIT and the mail system. This could come in handy right away for mail systems like PhoneNet and MailNet. - Frank ------- 2-Dec-83 10:04:17-EST,386;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Dec 83 10:04:08 EST Date: Fri 2 Dec 83 09:53:29-EST From: Frank da Cruz Subject: MULTICS KERMIT To: Info-Kermit@CUCS20 I forgot to say that MULTICS KERMIT is available at host COLUMBIA-20 via anonymous FTP in the files KER:MU*.* (3 files, 51 pages = 255K). - Frank ------- 2-Dec-83 19:20:48-EST,618;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Dec 83 19:20:45 EST Date: Fri 2 Dec 83 19:20:31-EST From: Frank da Cruz Subject: New Rainbow Kermit available To: Info-Kermit@CUCS20 Bill Catchings' CP/M-86 Kermit for the DEC Rainbow-100 has a new release. The major feature is that the port i/o is now interrupt driven, so the program should be able to handle both file transfer and terminal emulation at 9600 baud. Also a GET command was added, but still no wildcard SEND. It's available at host COLUMBIA-20 via anonymous FTP as KER:RB*.*. ------- 2-Dec-83 19:36:52-EST,1123;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Dec 83 19:36:46 EST Date: Fri 2 Dec 83 19:31:40-EST From: Frank da Cruz Subject: Another new KERMIT-20 To: Info-Kermit@CUCS20 Several minor bugs that were reported with the recent new release of KERMIT-20 have been fixed (I hope). These include: Fix SHOW ALL command not to say "DEL" at end. . Make sure init file is taken before processing command line argument. . Fix command line arguments to work even if no init file. . Change SET FILE-BYTE-SIZE to SET FILE BYTESIZE. . Add SET FILE NAMING to elect filename conversion. . Make sure line is set up correctly after exit and continue. . Don't send 4 extra characters if file is ITS binary. Please replace your current copy with this one, try it out, report any problems to me. You should still keep version 3A around for backup, since it's quite stable. The new version is available at COLUMBIA-20 via anonymous FTP as KER:20KERMIT.*. In case you need to get the old version back, it's still here as KER:20KEROLD.*. - Frank ------- 4-Dec-83 02:17:01-EST,1065;000000000000 Return-Path: <@CUCS20:LBrenkus.ADL@MIT-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 4 Dec 83 02:16:59 EST Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Sun 4 Dec 83 02:16:52-EST Date: Sunday, 4 December 1983 02:13 est From: LBrenkus.ADL@MIT-MULTICS.ARPA Subject: PC Kermit -- redefining keys? To: info-kermit@COLUMBIA-20.ARPA Message-ID: <831204071323.521175@MIT-MULTICS.ARPA> DOS 2.0 includes a device driver, ANSI.SYS, which implements many useful advanced keyboard and screen handling features. In particular, it permits easy redefinition of any key on the keyboard to an arbitrary string (much like proprietary utilities such as PROKEY). This feature is useful-- I use it with an IBM3101 terminal emulator to change cursor keys so they send MULTICS Emacs the correct control characters: ^f,^b etc. Is there any easy way to utilize this built-in feature of DOS 2.0 with PC-Kermit? (I can't get it to work by redefining keys before running kermit). If not, what is the simplest patch to redefine cursor keys? 4-Dec-83 11:30:23-EST,1116;000000000000 Return-Path: <@CUCS20:muller%UMass-ECE%UMASS-ECE@csnet-cic.arpa> Received: from CUCS20 by CU20B with DECnet; 4 Dec 83 11:30:20 EST Received: from UDel-Relay by COLUMBIA-20.ARPA with TCP; Sun 4 Dec 83 11:30:19-EST Received: From Csnet-Cic.arpa by UDel-Relay via smtp; 3 Dec 83 20:36 EST Date: 3 Dec 83 11:47-EDT (Sat) From: Rich Muller Return-Path: Subject: VT52 emulation for Kermit-80 and -86. To: info-kermit.columbia-20@udel-relay.arpa Via: UMASS-ECE; 3 Dec 83 19:58-EST The VT52 emulation mode doesn't seem to work at all on my version of Kermit-80 for Apple/cpm/videx board. What might I be doing wrong? And on the IBM PC at work, VT52 emulation seems to work fine, but I can't find the equivalent of the keypad commands ... which makes it difficult to use, eg, EDT on my VAX. Rainbow Kermit is superb; glad to hear that there's a version now for CPM-86 and the Rainbow; any suggestions about sources for that for those of us who can't FTP stuff from Columbia-20? Rich Muller Hampshire College 5-Dec-83 10:16:45-EST,1034;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 5 Dec 83 10:16:38 EST Date: Mon 5 Dec 83 10:16:01-EST From: Frank da Cruz Subject: Re: VT52 emulation for Kermit-80 and -86. To: Info-Kermit@CUCS20 In-Reply-To: Message from "Rich Muller " of Sat 3 Dec 83 10:47:00-EST The CP/M-80 Kermit program has grown so complex that it's not surprising that some features of some implementations don't work. The problem is being addressed now by someone on the Info-Kermit list who is completely reorganizing the program into modules that isolate the system-dependent features. This should make it easier to support new machines or devices or fix support that doesn't work. Watch this list for further announcements. Although PC Kermit claims to emulate a VT52, it's really emulating a Heath-19. We'll check to see if the two machines use the keypad the same way, and if so, will look into putting support for that into Kermit-86. ------- 5-Dec-83 13:45:44-EST,990;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 5 Dec 83 13:45:36 EST Date: Mon 5 Dec 83 13:44:34-EST From: Frank da Cruz Subject: Another KERMIT for VAX/VMS To: Info-Kermit@CUCS20 THis one is from Bruce Pinn, University of Toronto. It's written in a combination of Fortran and Pascal. Although the version from Stevens Institute of Technology (written in Bliss and available in the KERMIT distribution area as VMS*.*) is recommended, this version might be useful for those who do not have Bliss on their systems, and feel uncomfortable about running a program they cannot modify. The Toronto version is available in source form at host COLUMBIA-20 via anonymous FTP as KER:VF*.*. The file VFREADME.TXT explains what the other files are. Incidentally, there is still another KERMIT for VAX/VMS -- an old version of UNIX KERMIT to which VMS i/o support was added -- in the KERMIT area as VX*.*. - Frank ------- 5-Dec-83 14:18:42-EST,1120;000000000000 Return-Path: <@CUCS20:CELONI@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 5 Dec 83 14:18:36 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Mon 5 Dec 83 14:18:23-EST Date: Mon 5 Dec 83 11:16:43-PST From: Jim Celoni S.J. Subject: Re: VT52 emulation for Kermit-86 To: Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Frank da Cruz " of Mon 5 Dec 83 07:53:19-PST PC Kermit works perfectly with the RoseSoft's ProKey keyboard enhancer. I'm using both now with Emacs; ALT is META, and the keypad does what it should (e.g., Right sends Ctrl-F & Ctrl-Right sends ESC F). A prokey script of a dozen lines will make the PC keypad like the H/Z-19's; another dozen will set up function keys like the Heath's too. I'm not against Kermit-86 supporting H19's keypad, but since there are other ways to provide that support (other keyboard enhancers, some free) without changing Kermit, the need may not be pressing. Do any Kermits support a log file (capturing local keystrokes and remote responses, not packets)? +j ------- 6-Dec-83 01:39:16-EST,2705;000000000000 Return-Path: <@CUCS20:ESTEFFERUD@USC-ECL> Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 01:39:08 EST Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 01:34:16-EST Date: 5 Dec 1983 22:01-PST Sender: ESTEFFERUD@USC-ECL Subject: Re: next step: Kermit Mail From: ESTEFFERUD@USC-ECL To: cc.fdc@COLUMBIA-20 Cc: reid%SU-Glacier@SU-SCORE, Info-Kermit@COLUMBIA-20 Cc: TDomae@USC-ECL, JSweet%uci@RAND-RELAY Message-ID: <[USC-ECL] 5-Dec-83 22:01:09.ESTEFFERUD> In-Reply-To: The message of Fri 2 Dec 83 09:51:35-EST from Frank da Cruz In-Reply-To: Having looked carefully at the idea of using one of the TTY based FTP protocols like XMODEM or KERMIT for MAIL transfers, a group of us at UCI (working on the MZnet Project to link an MMDF based local mail net to student and faculty PC's at home) have come to the conclusion that those protocols are rather hopelessly bound to the idea of having a human intelligence around to deal with things that the protocols cannot handle, like diskette overflow, et al. Kermit was found to be little better about this than XMODEM when we tried to erradicate the dependence on human intervention. So, we have fallen back to using the Phonenet packet protocol as the basis for a session oriented PC Mail Post/Pickup Server attached to the UCI ZOTnet which is an MMDF based local mail subnet of CSnet and the Internet. The Phonenet packet protocol may not be elegant, but it is able to run roughshod over most of the obstacles that bedevil XMODEM and KERMIT, such as TELENET or OTHERNETS. But we don't mind when 4 wheel drive is what we need. And, it has been relatively easy to adapt the Phonenet code, and its higher level drivers to provide support user controllable transfer sessions. Another problem has to do with authenication. XMAILR and MMDF assume that they are talking to an authenticated peer Mail Transfer Agent (So does SMTP) when they link up to transfer mail between "certified" hosts. PC's are not certifiable, unless you have some way to certify the diskettes that hold their Operating Systems. The bottom line on all this is, that kermit may be a reasonable TTY FTP program, but that has little to do with mail, beyond the need to transfer text packets. The entire session concept needs to be reworked to act as a MAIL SERVER. I will leave you here with the observation that a MAIL SERVER is a much more complicated problem to solve than the as yet unresolved design of the Kermit FTP Server. A word to the wise: "Mail systems are never as simple as they seem." Just ask Eric Allman if you don't want to believe me. Enjoy! Stef 6-Dec-83 01:49:58-EST,841;000000000000 Return-Path: <@CUCS20:ESTEFFERUD@USC-ECL> Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 01:49:55 EST Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 01:36:34-EST Date: 5 Dec 1983 22:13-PST Sender: ESTEFFERUD@USC-ECL Subject: Xenix Kermit Query From: ESTEFFERUD@USC-ECL To: Info-Kermit@COLUMBIA-20 Cc: TDomae@USC-ECL Message-ID: <[USC-ECL] 5-Dec-83 22:13:32.ESTEFFERUD> Has anyone out there ported Kermit onto Xenix, as for an ALTOS 586? I get the latest version from Columbia to compile without complaint, but, in "r" mode, it but cannot see anything from the remote host. Also, in "c" mode, the escape character mechanism does not interupt, etc, et al. So, I gather that something is radically wrong with the way kermit tries to use the Xenix library routines, or something. Thanks - Stef 6-Dec-83 14:31:47-EST,3096;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 14:31:39 EST Date: Tue 6 Dec 83 14:29:54-EST From: Frank da Cruz Subject: [HFISCHER%USC-ECLB@MINET-CPO-EM: PC Kermit, Heath, and LAN Question] To: Info-Kermit@CUCS20 The first suggestion, about saying that PC Kermit really emulates a Heath-19, is noted and will be part of the next release. About the second point -- server operation would be a desirable addition to PC Kermit (as it is to any Kermit), and would make unattended usage very pleasant; this is on our list of things to do (but who knows when we'll get to it?). Redirecting interactive PC Kermit to use the back port would be a possibility -- has anyone out there tried it? Does the suggested method work? Are there other or better ways to do it? - Frank --------------- Return-Path: Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 01:04:36-EST Date: 5 Dec 1983 2202-PST From: HFISCHER%USC-ECLB@MINET-CPO-EM Subject: PC Kermit, Heath, and LAN Question To: cc.fdc at COLUMBIA-20 cc: HFischer at USC-ECLB Frank, First, let me thank you for the msg that PC kermit actually emulates a heath, instead of the VT52. Kermit was a real dog in the VT52, especially with EMACS. With the H19 mode, it nicely does line insert and delete, and is relatively breezy to use. I don't think the average kermit user on an PC realizes that he is working with the H19. I'd recommend that the on line help, and the user.doc, both reflect this. My real question stems from a local area net that my company just installed to interconnect its horde of PC's. We find that two Kermit's can talk if humans attend both and are in phone contact to coordinate loading, setting into receive/send mode, etc. But, what would be desired is like an unattended remote server, like for the department manager about to write his weekly status report to place his PC into unattended server state, and let the network users connect to him and send him files; or maybe they connect to receive the company's staff report, or broadcast news files, etc. For the unattended server to just be a KERMIT program in serving mode (probably easy to patch into the asm code), it would have to stand for the local area network's "informational messages", plain ascii notification of who the caller is, when he disconnects, etc. Or would it be possible to do a CTTY PC DOS command to redirect console input to the async line, and then get remote guys to log on, load kermit themselves, and operate the remote PC remotely (as they would do for a host?)? Will KERMIT cooperate with the CTTY console redirection on the PC? There must be other places with LAN's and PC's using kermit to do this sort of thing, without human attendance and voice contact doing each minor detail. What ideas would you recommend? Or could you put me in touch with other LAN KERMIT users)? Thanks in advance, Herm Fischer (HFischer@ECLB) ------- ------- 6-Dec-83 15:51:25-EST,956;000000000000 Return-Path: <@CUCS20:MRC@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 15:51:11 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 15:49:54-EST Date: Tue 6 Dec 83 12:48:01-PST From: Mark Crispin Subject: Re: next step: Kermit Mail To: ESTEFFERUD@USC-ECL.ARPA cc: cc.fdc@COLUMBIA-20.ARPA, reid%SU-Glacier@SU-SCORE.ARPA, Info-Kermit@COLUMBIA-20.ARPA, TDomae@USC-ECL.ARPA, JSweet%uci@RAND-RELAY.ARPA In-Reply-To: Message from "ESTEFFERUD@USC-ECL" of Mon 5 Dec 83 22:01:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Well, one of the projects that is being started with the MM mailsystem (including MMailr, the successor to XMailr) is a restructuring of the code to implement the two-way model. Perhaps it will also be rewritten in a semi-highlevel "portable" language. ------- 6-Dec-83 17:41:13-EST,1264;000000000000 Return-Path: <@CUCS20:uucp@Shasta> Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 17:41:09 EST Received: from Shasta by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 17:40:09-EST Received: from decwrl by Shasta with UUCP; Tue, 6 Dec 83 14:38 PST Date: Tuesday, 6 Dec 1983 14:18:21-PST Sender: uucp@Shasta From: decwrl!rhea!atfab!wyman@Shasta Subject: Problem with VMS-KERMIT Message-Id: <8312062235.AA16265@DECWRL> Received: from RHEA.ARPA by DECWRL (3.327/4.09) 6 Dec 83 14:35:46 PST (Tue) To: info-kermit@columbia-20.arpa I hate to mention bugs, when I don't have time to dig through the sources and propose fixes right now, but I think people should be warned that the current version of VMS-KERMIT seems to have some problems when sending Print-Format files. It just keeps sending packet after packet with no data... I found this when transferring a .LOG file from VMS to Rainbow-KERMIT. The .LOG file was 4 blocks long but accumulated a traffic of about 800 packets before I cut it off. The problem is probably related to the handling of VFC records. bob wyman Point of procedure? Should bug reports go to INFO-KERMIT or to the actual developer? If to the developer, how do I get his/her mail address relative to the DECNET? 6-Dec-83 17:54:35-EST,1274;000000000000 Return-Path: <@CUCS20:BRACKENRIDGE@USC-ISIB> Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 17:54:19 EST Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 17:45:39-EST Date: 6 Dec 1983 1440-PST Subject: Plea for 8bit mail From: Billy To: info-kermit@COLUMBIA-20 It looks from recent discussion that people are considering building a mail service on top of the Kermit file transfer capability. I would like to plead for real 8 bit mail. I am working with LPC encoded voice which uses about 250 to 300 bytes per second of recorded speech. I would like to send this as mail and don't want to encode this as Hex or 6/8 packing. I don't mind a scheme that requires that I send several Kermit files. For example I could send a standard mail parcel that contains a 7bit ACSII text field similar to "You have voice mail in the file FOO.BAR". I could then transfer FOO.BAR in 8 bit format. I understand that all of the Tops-20 sites store mail files as 7 bit ascii and IBM mainframes do even more unmentionable things. Currently Kermit is used for passing code and things like spreadsheet data. It would be shame not to be able to pass these sorts of files off to your friendly mail server. ------- 6-Dec-83 18:07:21-EST,780;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 18:07:16 EST Date: Tue 6 Dec 83 17:50:33-EST From: Frank da Cruz Subject: Re: Problem with VMS-KERMIT To: decwrl!rhea!atfab!wyman%SU-Shasta@SU-SCORE.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "decwrl!rhea!atfab!wyman@Shasta" of Tue 6 Dec 83 17:40:19-EST Point of procedure -- Since the traffic on Info-Kermit is relatively light, it should be OK to send bug reports to the list in general. That way, we're all alerted to potential problems & pitfalls. Many of the maintainers or contributors participate in this mailing list and can respond. Others, who may not be on any kind of network at all, can be contacted by me, I guess. - Frank ------- 6-Dec-83 21:57:29-EST,3484;000000000000 Return-Path: <@CUCS20:MRC@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 21:57:13 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 21:56:11-EST Date: Tue 6 Dec 83 18:54:08-PST From: Mark Crispin Subject: Re: Plea for 8bit mail To: BRACKENRIDGE@USC-ISIB.ARPA cc: info-kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Billy " of Tue 6 Dec 83 14:40:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) No!! There should be a clear separation between the concepts of: (1) text mail (2) multi-media mail (3) file transfer (4) spooled file transfer Of these, (2), (3), and (4) are typically 8-bit oriented, generally because a common processor ISP involves allocating memory in 8-bit bytes (making, of course, data atoms whose magnitude is not a multiple of 8 awkward to use). (1) on the other hand has typically involved 7-bit ASCII, for a good number of historical reasons. The most important reason today is that ASCII text is 7 bit; the eighth bit is for parity. Certain individuals have hit on the idea of using (1) to implement (2), (3), and (4). I suspect this is because a great many people have well-tested well-debugged implementations of (1). That doesn't mean that it is anything other than a kludge to do this! If you want file spooling or multi-media mail, the correct thing to do is to develop new protocols that do this, not layer them on top of old text-oriented protocols. -- Mark -- PS: For those of you not familiar with the PDP-10 and/or TOPS-20, the PDP-10 is a 36-bit processor with "soft" bytes; that is, memory is addressed by 36-bit word and within each word the program could use bytes of arbitrary size and position from 1 to 36 bits. A set of instructions implement these soft bytes so the programmer can load and deposit them without resorting to shifting and masking. Text files are traditionally stored on the PDP-10 packed 5 7-bit bytes to a word; the extra bit is generally unused. Some PDP-10 operating systems (at least 5 exist) have expanded characters beyond 7 bits, but have generally gone beyond 8 bits to 9, 12, or 18 bits. This has received limited application, because VAXen et al would have a impossible task in coping with 9-bit data but can cope with 7-bit data reasonably well. I strongly suggest to those of you who think that 8 bit bytes (or some other power of 2, e.g. 32) is somehow wonderful take a good look at the real applications out there. It's a myth that a word or byte size that's a power of 2 buys anything; in fact, 32 bits makes for quite inadequate floating point and equally inadequate pointers. Data structures involving bytes that do not correspond to the processor byte size are rather awkward to work with. This isn't to say that "36 bits is better than 8 bits", but rather to point out that not all applications today or tommorrow are going to be oriented around 8 bits. Consequently anything that is going to be binary encoded should use a transport that is bit-stream oriented (whether or not that bit-stream is encoded within some flavor of bytes is irrelevant). A flag day to make text mail be 8 bits would have to be repeated all over again if suddenly the industry decides to go with a 9 bit character set. ------- 7-Dec-83 10:03:02-EST,1998;000000000000 Return-Path: <@CUCS20:OC.GARLAND@CU20B> Received: from CUCS20 by CU20B with DECnet; 7 Dec 83 10:02:56 EST Received: from CU20B by CUCS20 with DECnet; 7 Dec 83 10:02:09 EST Date: Wed 7 Dec 83 10:01:32-EST From: Richard Garland Subject: Lets not get carried away! To: info-kermit@CUCS20 cc: OC.GARLAND@CU20B Please forgive me if this sounds like flame but ... I would like to give a general point of view as regards to 2 recent points of discussion on this list: the idea that Kermit and it's various hosts store in some detailed way file characteristics (a'la ITS headers only more), and the idea of layering some kind of Mail on top of kermit. Kermit was created as a means to transfer data reliably between micros and main-frames (the super-brain and the DEC-20 to be exact). It caught on and soon began to support lots of big and little systems. However, the initial design considerations (such as packet size, acknowledgement scheme, flow control etc.) were oriented around small systems and low speed lines. Its popularity probably attests to its success in meeting its goals (to say nothing of the fact that it is free). Now when people say "well I'm thinking of connecting my 2 Cybers with Kermit and do you think ....", or "Well I don't know if SMTP or UUCP is the right MAIL scheme for Kermit ..." or "I'm thinking of how Kermit can reversably download/upload my IBM VSAM datasets to my Apple ...", I say - hey wait a minute, Kermit is not the end of the world! Lets get it to do what it's designed to do real well and on as many systems as possible and not try to solve all the worlds problems with it! I would rather see effort put for a SIMPLE and RELIABLE version on all the systems I use (and anyone else uses) and forget the blue sky. If I want to connect my DEC-20's I use DECnet or TCP/IP. If I want MAIL I call up my DEC-20 or VAX and read it. If I want a file on my Rainbow, I use kermit. Rg ------- 7-Dec-83 10:42:31-EST,1009;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 7 Dec 83 10:42:18 EST Date: Wed 7 Dec 83 10:41:23-EST From: Bob Cattani Subject: Re: Lets not get carried away! To: info-kermit@CUCS20 In-Reply-To: Message from "Richard Garland " of Wed 7 Dec 83 10:02:27-EST My feelings about some of the proposed expansions to Kermit closely parallel Rich Garland's. As far as I'm concerned, Kermit has a place and it has performed well in that place. Let's not try to build things into it that most systems can do just as well without. If someone needs mail on their computer, let's handle that problem separately. What Frank suggested ("isolate the transport-level functions into a library that could be shared by KERMIT and the mail system") sounds to me like a more proper way of doing it. This way, people who don't need mail, file attributes, etc. won't get what to them would just be excess baggage. -Bob Cattani ------- 7-Dec-83 13:23:59-EST,2054;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 7 Dec 83 13:23:43 EST Date: Wed 7 Dec 83 13:18:21-EST From: Frank da Cruz Subject: Kermit for Victor 9000 To: Info-Kermit@CUCS20 This is to announce the possible arrival of KERMIT-86 for the Sirius 1, aka Victor 9000. There are two versions, one for CP/M-86, another for MS DOS. The programs arrived on a tape in undecipherable format, which I had to dump bit-for-bit and then pick apart by hand, removing periodic chunks of imbedded garbage. I hope I didn't remove anything that wasn't garbage (I was careful), and didn't miss anything that was. These two programs are adaptations of IBM PC Kermit as it existed in May 1983 (edit 13), i.e. before the interrupt-drive i/o was added, terminal emulation improved, various minor bugs fixed, etc. The MS DOS support could conceivably be merged into the current (better still, next -- announcement forthcoming) release of IBM PC Kermit, and the CP/M-86 support integrated with the new Rainbow CP/M-86 Kermit. However, since we don't have any Victor machines to test them on at Columbia (at least not yet), we're making these programs available as they are for the benefit (?) of anyone who does. The programs were supplied in source form only -- no binaries or hex. It would be greatly appreciated if someone who has a Victor could download the appropriate source program (do Victors have a way to do this? MODEM? Some proprietary or vendor-supplied package?), try it out, create a hex (or IBM PC Kermit-style .FIX) file and make it available, along with any reactions about if and how well the program works. The files are available via anonymous FTP from host COLUMBIA-20, as KER:VIC*.*. KER:VICTOR.DOC is a short message explaining the changes he made to support the Victor. KER:VICMSDOS.ASM is the MS DOS version, KER:VICCPM.A86 is the CP/M-86 version. Thanks to Barry Devlin, University College Dublin (Ireland), for the contribution. - Frank ------- 7-Dec-83 19:37:50-EST,575;000000000000 Return-Path: <@CUCS20:CERRITOS@USC-ECL> Received: from CUCS20 by CU20B with DECnet; 7 Dec 83 19:37:41 EST Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Wed 7 Dec 83 19:36:14-EST Date: 7 Dec 1983 1433-PST From: Bruce Tanner Subject: Osborne Executive To: INFO-KERMIT@COLUMBIA-20 Is there anyone out there who has Kermit running on an Osborne Executive under CP/M Plus? I've had people tell me it doesn't work. If you have it working or know of someone who has, would you let me know the details? Thanks, -Bruce ------- 8-Dec-83 06:03:36-EST,714;000000000000 Return-Path: <@CUCS20:AWALKER@RUTGERS.ARPA> Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 06:03:34 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Thu 8 Dec 83 06:02:40-EST Date: 8 Dec 83 06:02:23 EST From: Hobbit Subject: Kermit suggestions To: info-Kermit@COLUMBIA-20.ARPA How about an interrupt character that will *cleanly* abort a transfer? And, if one is going to support the FINISH command on one machine, when does it come to the rest? I speak here of Kermiting between VMS Vaxes and 20's. I can shut down the Vax server from the 20, but not the other way round. Leads to some interesting ways of getting wedged sometimes.... _H* ------- 8-Dec-83 19:13:56-EST,3230;000000000000 Return-Path: <@CUCS20:OC.BUSH@CU20B> Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 19:13:52 EST Received: from CU20B by CUCS20 with DECnet; 8 Dec 83 19:12:46 EST Date: Thu 8 Dec 83 19:13:04-EST From: Nick Bush Subject: Re: Lets not get carried away! To: OC.GARLAND@CU20B cc: info-kermit@CUCS20 In-Reply-To: Message from "Richard Garland " of Wed 7 Dec 83 10:03:11-EST The reason I suggested the storing of attributes for a file in such a way that the file will be reversibly stored is due to the need to be able to store files from micros on a mainframe and get them back when needed. The problem we have which prompted the suggestion is due to the file system used on the DEC Pro-3xx's under P/OS. In order to be able to store executable programs for a P/OS system on a DECsystem-10 or DECSYSTEM-20, there needs to be some way of storing the attributes of the file as it appears on the P/OS system. Also, in order to be able to move a task image (executable program) from a VMS system (where it may have been generated by DEC's cross compiler(s) and linker) to a P/OS system, the same attributes are needed, however in this case it is coming from a file system which does store those attributes. Until the idea of the file attributes packet was suggested, we were considering implementing a "FILE-TYPE" in both VMS Kermit and Pro-Kermit that would cause the Kermit to send (and recognize when receiving a file) a short header which contained the necessary attributes. This header would be sent as part of the data, not as a separate type of packet. Therefore, Kermit's which did not know about the header (or had not been told to look for it) would just store it in the file, and would therefore send it out when asked to transmit the file. This would have made the transfer reversible without any need for support from any other Kermit. However, since the attributes packet was added, it made us reconsider the problem. If we are to support the attributes packet (which would solve the problem of transfer between VMS and P/OS), we need some way to store the information when the destination file system does not store the same attributes as Files-11. It would seem that the only alternative (assuming the need to use the attributes packet) is to teach Kermit's how to store the attributes their file system doesn't know about. I don't know that it is really a very good idea to use the attributes packet in this way. Perhaps we should just go back to our original idea of how to transmit the attributes we need to. In some ways I like that idea better (means less work for me in Kermit-10), but it seems contrary to the idea that is embodied in an attributes packet. Overall, the question seems to be whether Kermit is intended for transferring files between systems such that they are usable on both systems, or so that one system may be used as a file store (backup medium, whatever) for the other. People are using Kermit for both purposes, and will continue to do so. We need a method of handling file systems which require a little more information than the simple ones Kermit started out with. - Nick ------- 8-Dec-83 19:27:36-EST,1416;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 19:27:31 EST Date: Thu 8 Dec 83 19:14:02-EST From: Nick Bush Subject: Re: Kermit suggestions To: AWalker@RUTGERS.ARPA cc: info-Kermit@CUCS20 There currently is an interrupt character which will abort a transfer. In fact, there are two different options - abort only the current file, or abort the entire group (if wildcards are being used). This is implemented in the newest versions of Kermit-20, VMS Kermit, Kermit-10 and CP/M Kermit-80. A control-X typed while a transfer is in progress will cause the current file to be aborted, skipping to the next file if a wildcard transfer is in progress. A control-Z will cause the current file to be aborted and the wildcard transfer to act like it ran out of files. If you are using the latest versions of these Kermit's, this will work regardless of which direction the file transfer is going. If you only using a version which supports this on the local side (the side which owns a physical terminal), you can abort files being sent, but not those being received. The latest version of VMS Kermit also supports giving commands to a server Kermit (FINISH, BYE, LOGOUT, and GET). The latest versions of all of these Kermits are available via ANONYMOUS FTP from Columbia-20 on the directory KER: (PS:). - Nick ------- 8-Dec-83 20:26:37-EST,2090;000000000000 Return-Path: <@CUCS20:uucp@Shasta> Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 20:26:34 EST Received: from Shasta by COLUMBIA-20.ARPA with TCP; Thu 8 Dec 83 20:25:28-EST Received: from decwrl by Shasta with UUCP; Thu, 8 Dec 83 17:23 PST Date: Wednesday, 7 Dec 1983 12:21:22-PST Sender: uucp@Shasta From: decwrl!rhea!atfab!wyman@Shasta Subject: re: Plea for 8-bit mail Message-Id: <8312090108.AA15720@DECWRL> Received: from RHEA.ARPA by DECWRL (3.327/4.09) 8 Dec 83 17:08:28 PST (Thu) To: wyman@Shasta, Shasta!info-kermit@columbia-20.arpa In re: Plea for 8-bit mail. It was suggested that 8-bits would be inappropriate for use in text based mail systems... Some comments were made about the specifics of the TOPS-10/-20 environment.. While it may be difficult for some systems to handle 8-bit mail, it is very important for us all to recognize that there is a clear and certain trend towards both 8 and eventually 16 bit characters. Digital, for instance, has recently created a DEC Multinational Character Set Standard which uses all 8 bits. This character set is destined to be supported over time by all DEC hardware and operating systems. Initial support will come in the VT2xx family of terminals. 8-bit support is also necessary if one wishes to exchange mail with the folks in other countries (ie: Europe, Canada). While KERMIT itself probably won't be used to connect to foreign countries (there are legal issues involved), any KERMIT based mail services should avoid being defined in such a manner that KERMIT will not be useful in the context of a world-wide mail network. Because there are a number of 8-bit character sets outstanding, the important question should not be whether 8-bit is supported but rather which 8-bit encoding should be KERMIT default. There should also be consideration of whether character set translation is appropriate and/or achievable. I'm prejudiced of course, working for DEC... I would suggest that the DEC Multinational set be the KERMIT 8-bit default. bob wyman 8-Dec-83 20:57:48-EST,930;000000000000 Return-Path: <@CUCS20:louie@cvl> Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 20:57:45 EST Received: from cvl by COLUMBIA-20.ARPA with TCP; Thu 8 Dec 83 20:56:43-EST Date: 8 Dec 1983 20:59:28-EST From: Louis A Mamakos Reply-to: louie@cvl To: info-kermit@columbia-20.arpa Subject: Re: Plea for 8 bit mail I think this can get out of hand... Sure there is a trend to move to 8 bit character data, but there are vendors that use more than 8 bits already; Sperry Univac uses 18 bit for 18 bits for its Japanese character sets. Where will it all stop? Louis A. Mamakos Internet: louie@cvl.arpa CSNet: louie.cvl@umcp-cs uucp: ..!{seismo,we13,mcnc}!rlgvax!cvl!louie phone: (301) 454-2946 Snail Mail: Computer Science Center - Systems Staff University of Maryland College Park, MD 20742 9-Dec-83 10:52:11-EST,2643;000000000000 Return-Path: <@CUCS20:knutson@utexas-11> Received: from CUCS20 by CU20B with DECnet; 9 Dec 83 10:52:01 EST Received: from UT-NGP.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Dec 83 10:50:31-EST Date: 9 Dec 83 09:50:50 CST (Fri) From: Jim Knutson Subject: Re: Lets not get carried away! Posted-Date: 9 Dec 83 09:50:50 CST (Fri) Message-Id: <8312091550.AA27997@UT-NGP.ARPA> Received: by UT-NGP.ARPA (3.326/3.7) id AA27997; 9 Dec 83 09:50:50 CST (Fri) To: info-kermit@columbia-20.ARPA Let's look at what we want. First and foremost, Kermit should be a file transfer program. We would like it to not only transfer files but allow us to use its capabilities to store files on other machines. These are two very different things! Now this leads us to the following conclusions: 1. For transfers between like machines (compatible machine/opsys), we probably want exactly what we started out with. Sort of like copying a file on that machine. 2. For transfers between different machines we have: a) Text file transfers. What you see on one machine is what you want to see on the other. b) Binary transfers. This should only be usefully for downloading cross-compiled programs. Usually binary executables are useless on different machines. Perhaps this should be called down-load transfers. c) Store-forward transfers. Perhaps this is what we really want from binary transfers. The file is not meant to be used on the destination, just stored. Here we want to get back exactly what we sent. How do we accomplish this? For item number 1, two different kermits need to know if they are compatible. This could be accomplished through commands, flags, or swithces to the Kermit program or with parameters to the send-init negotiation. To accomplish a copy of a file, we need the originators attributes and the data. For text transfers, all we need is the data. No attributes. Why bother? The file is on a foreign system where none of the attributes are likely to have anything to do with the originators attributes. Downloading is similar to storing-forward except that instead of storing the file for later retrieval it is setup to be used on the destination system. Storing-forward is what needs work. I suggest that we define some format for storage such as originators file name, attribute header, data field. Kermit should also be modified to distiguish between the different types of transfers. -- Jim Knutson ARPA: knutson@ut-ngp UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson 9-Dec-83 13:28:20-EST,499;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Dec 83 13:28:14 EST Date: Fri 9 Dec 83 13:25:59-EST From: Daphne Tzoar Subject: Re: Kermit suggestions To: AWalker@RUTGERS.ARPA cc: info-Kermit@CUCS20 In-Reply-To: Message from "Hobbit " of Thu 8 Dec 83 06:02:23-EST The next release of PC Kermit will also support cleanly aborting the transfer of the current file (^X) or file group (^Z). /daphne ------- 9-Dec-83 15:14:35-EST,2535;000000000000 Return-Path: <@CUCS20:Kincl%HP-HULK.HP-Labs@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 9 Dec 83 15:14:20 EST Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Dec 83 15:12:44-EST Date: Fri 9 Dec 83 10:31:21-PST From: Norm Kincl Return-Path: Subject: Re: Lets not get carried away! Received: by HP-VENUS via CHAOSNET; 9 Dec 1983 10:31:45-PST To: info-kermit@COLUMBIA-20, @, Kincl%HP-VENUS.HP-LABS@Rand-Relay In-Reply-To: Message from "Jim Knutson " of Fri 9 Dec 83 09:50:50-PST Message-Id: <439842706.8390.hplabs@HP-VENUS> Via: HP-Labs; 9 Dec 83 11:57-PST It seems like what you want is something like this: 1. If no file attribute packet is sent, keep things just as they are now. 2. If a file attribute packet is sent, then there are two possibilities a. The receiving system handles that type of file. In this case, just save it as is. For example, a VMS system receiving a file from a Pro with attribute Files-11 can just save it as a Files-11 file. b. The receiving system does not handle it. (eg. TOPS-20 receiving a Pro Files-11 file). The receiving system should then be allowed to either i. reject the file with a "can't accept this type of file" packet ii. store the packet in some operating system dependent way. This may involve pre-pending a sixbit FILES11 to the file, marking some user-defined field in the file descriptor, or whatever. It should be up to the operating system to decide how to best do this. The only requirement should be that if the file is sent via Kermit someplace else, the original format of the file will be preserved. This would include both the same attribute packet and data as was originally sent. Using this, I could transfer a file from a Pro to a Multics system to an IBM to a TOPS-20 to a VMS system and back to a Pro and it would end up unchanged. Implementing something like this in the protocol will take the responsibility of deciding HOW to store a file away from the file transfer protocol where it has no business being. My operating system that I write some day may have a comment field associated with each file where I can easily put a DSK8 comment instead of a kludge involving the data in the first 13 bytes of the file being some special combination of cryptic bits. Put the work where it belongs. -Norm Kincl HP Labs Internet: Kincl.HP-Labs@Rand-Relay.Arpa ------- 9-Dec-83 17:43:06-EST,3836;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Dec 83 17:42:58 EST Date: Fri 9 Dec 83 17:41:56-EST From: Frank da Cruz Subject: Preserving file attributes, cont'd To: Info-Kermit@CUCS20 Without going into any great detail (yet), I think we need to differentiate between sending a file to be used and sending a file to be archived for later retrieval. To do this, the attributes packet "disposition" field would have an "archive" parameter. In its absence, the receving system would try to store the file in usable form. In its presence, the receiver would store the attribute packet itself along with the file's contents. For archiving, a new command be added to KERMIT -- "ARCHIVE". This would be just like SEND, except the attributes packet would specify archiving. When a file is archived, there should be some indicator to distinguish it from an ordinary file. Preferably, this would be something outside the file. Fancy file systems may have some user-definable directory entry fields which would be perfect for this use, like the TOPS-20 "user settable word" (.FBUSW). Other less desirable conventions could also be used, like funny protection codes, modes, special file types, etc. Only as a last resort should the indicator be put in the file itself, because there's always the chance that an ordinary file's data could start with the same sequence. In cases where the archive status of a file could not be accurately determined by its sender, there should be an "UNARCHIVE" command to direct that the file be treated as archived, and to send out the attribute information in attribute packets rather than as data. In addition (and this would require a new packet type) there could be a "RETRIEVE" command, which would send a message to a KERMIT server to "unarchive" the specified file(s). When an archived file is sent out, the receiver should be able to decide whether to "unarchive" it. For this, the archive information should contain a code indicating the machine and operating system of origin. Thus if I send my FILES11 file to a CP/M system and from there to a MULTICS system, the MULTICS system should know not to try to interpret the attributes, but rather, to re-archive them. In this way, an archived file could float around among all kinds of systems until it finally found its way back to one that understood its original file structure and could "unarchive it". All this depends, of course, on the support for the attributes packet and the archiving mechanism on each system involved. Any that don't support these concepts would operate as KERMITs do now. An issue still open is how an archived file should be stored. Since it is not being sent for use, why not store it in the most compact way possible? A simple way to achieve compaction would be to not expand KERMIT repeat-prefixed sequences, and to indicate in the attributes what the repeat prefix was, so that the file could be properly expanded upon retrieval. All this sounds like pie in the sky, and it probably is. But the whole idea is necessary when trying to adapt KERMIT to systems whose files are not strictly sequential streams of bytes. FILES11 is one example. Another, perhaps more demanding one, would be IBM VM/CMS VB-Format binary files (such as executable modules), where record boundaries of varying length records must be preserved. The attributes mechanism takes care of this nicely by allowing for file type "D", where records are each preceded by a length field. An extension of this idea could apply to sparsely populated random-access files. Still, even if we settle any of these issues, it remains to be seen whether they'll ever find their way into a KERMIT program... - Frank ------- 10-Dec-83 17:18:13-EST,834;000000000000 Return-Path: <@CUCS20:iam@cmu-cs-g> Received: from CUCS20 by CU20B with DECnet; 10 Dec 83 17:18:09 EST Received: from CMU-CS-G by COLUMBIA-20.ARPA with TCP; Sat 10 Dec 83 17:16:42-EST Date: 10 Dec 1983 17:05-EST From: Ira.Monarch@CMU-CS-G.ARPA Subject: VT52 emulation on CPM-APPLE-KERMIT To: INFO-KERMIT@CUCS20 Message-Id: <439941956/iam@CMU-CS-G> Will the Kermit program that runs under Apple-CPM using the Hayes micromodem II emulate a VT52 or a VT100 on a VAX or DEC20? I already have a terminal program that does file transfer reasonably well but doesn't allow the necessary cursor control to use the emacs screen editor. If the Kermit program does emulate a VT52, what files need to be transfered and what steps need to be taken in order to get it up and running on my Apple? Thanks --Ira Monarch 11-Dec-83 02:22:36-EST,1247;000000000000 Return-Path: <@CUCS20:G.FUSSELL@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 11 Dec 83 02:22:32 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Sun 11 Dec 83 02:21:35-EST Date: Sat 10 Dec 83 23:20:51-PST From: Carl Fussell Subject: Re: Preserving file attributes, cont'd To: cc.fdc@COLUMBIA-20.ARPA cc: Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Frank da Cruz " of Fri 9 Dec 83 16:03:40-PST Address: Santa Clara University This is just a comment on Frank da Cruz's archive/unarchive suggestions. I think the description outlined is quite good, in particular, the idea that an archived file be allowed "float" among systems freely until finding one understanding it. My main comment (criticism?) is the idea of using directory "user settable words" in the implementation of future kermits. As a site (DECSystem 20) that already takes advantage of this feature for site dependent things (and I doubt we are unique), it would deny us the use of the newer versions that become available. Although I haven't an alternative to suggest at this point, I would hope that another mechanism could be decided upon. . Carl ------- 11-Dec-83 13:01:16-EST,1011;000000000000 Return-Path: <@CUCS20:KLOTZ@MIT-MC> Received: from CUCS20 by CU20B with DECnet; 11 Dec 83 13:01:13 EST Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Sun 11 Dec 83 13:00:06-EST Date: 11 December 1983 12:56 EST From: Leigh L. Klotz Subject: Retaining file attributes on various systems To: info-kermit @ COLUMBIA-20 Pardon my ignorance, but why don't you just implement a means for storing file attributes on top of whatever system you're using, be it CP/M or ITS. Make a Kermit "directory" file containing filenames and info about files Kermit has received or wants to transmit. This approach solves the problem of separating the format info from the file contents, while still allowing files to float freely among systems, provided the Kermit transfer protocol does a lookup of the format information from the directory file before sending it. It seems to me if you really want system independent user-settable words, you might as well implement them. Leigh. 12-Dec-83 00:49:31-EST,1173;000000000000 Return-Path: <@CUCS20:uucp@Shasta> Received: from CUCS20 by CU20B with DECnet; 12 Dec 83 00:49:27 EST Received: from Shasta by COLUMBIA-20.ARPA with TCP; Mon 12 Dec 83 00:48:08-EST Received: from decwrl by Shasta with UUCP; Sun, 11 Dec 83 21:47 PST Date: Sunday, 11 Dec 1983 21:14:59-PST Sender: uucp@Shasta From: decwrl!rhea!atfab!wyman@Shasta Subject: Re: Plea for 8-bit Message-Id: <8312120536.AA19012@DECWRL> Received: from RHEA.ARPA by DECWRL (3.327/4.09) 11 Dec 83 21:36:53 PST (Sun) To: Shasta!info-kermit@columbia-20.arpa The Japanese Character sets are clearly defined in JIS-1 and JIS-2. These are "Japanese Industrial Standard"s which define a 16-bit character set which includes KANJI, KATAKANA, ROMANJI and a number of "technical characters". Also, there is no problem with handling the JIS-1/-2 characters with KERMIT!! Just as a test, I did it tonight. The 16-bit characters move like quoted 8-bit characters, and with the proper "shift-handling" it's still easy to get through the normal "ROMANJI" characters which are essentially ASCII. PLEASE-- let's not let Japanese worry us here. The question is 8-bits -- not 16! bob wyman 13-Dec-83 14:20:15-EST,2948;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 13 Dec 83 14:20:08 EST Date: Tue 13 Dec 83 14:13:42-EST From: Frank da Cruz Subject: New release of CP/M-80 KERMIT To: Info-Kermit@CUCS20 cc: Info-CPM@BRL.ARPA Announcing a new release of KERMIT-80, which provides file transfer and terminal emulation for CP/M-80 systems. This release is version 3.6; it has no new functionality over version 3.5, but several major bugs have been fixed. These include: Cursor addressing errors fixed for various systems. During terminal emulation, some systems (the Kaypro II, for instance) would output nulls continuously. This has been fixed. Thanks to James Grossen at the University of Tennessee at Knoxville for these fixes. Users of CP/M Kermit are encouraged to get the new .HEX files (using their current versions of Kermit), LOAD them, and try them out. If you do this, please let me know which system you tried, whether it worked, and if not, what went wrong. The .HEX files are available in KER:CPM*.HEX via anonymous FTP from host COLUMBIA-20. The systems supported, and the corresponding files, are: CPMAPPLE.HEX Apple II with Z80 SoftCard, DC Hayes MicroModem II CPMBRAIN.HEX Intertec SuperBrain CPMDMII.HEX DECmate II with CP/M option CPMGENERI.HEX "Generic" CP/M-80 version 2.x CPMHEATH.HEX Heath/Zenith 89 CPMKAYPRO.HEX Kaypro II CPMOSBORN.HEX Osborne 1 CPMOSI.HEX Ohio Scientific CPMPLUS.HEX "Generic" CP/M-80 version 3.0 (CP/M Plus) CPMRAINBO.HEX DEC Rainbow-100, CP/M-80 (Z80 side) CPMROBIN.HEX DEC VT180 "Robin" CPMTELCON.HEX Telcon Zorba CPMTRS80.HEX TRS-80 Model II with CP/M CPMVECTOR.HEX Vector Graphics CPMZ100.HEX Heath/Zenith Z100, CP/M-80 (Z80 side) CPMBASE.M80 The single source file for all the above. CPMBASE.DIF Source differences from version 3.5. There are also various associated .DOC and .HLP files. KERMIT implementations are also available for many other systems, both micros and mainframes. To get an idea of what's available, see the file KER:00README.TXT. Those of you who have been using KERMIT-80 version 3.2 or earlier are encouraged to try out this new release -- in incorporates many new features, including built-in DIR and ERA commands, a way for switching and logging in disks, improved wildcard facilities, etc. Since we do not have examples at Columbia of more than a couple of the systems listed above, I would be very grateful to anyone who could report to me about their success or lack thereof in running this new version of KERMIT-80. In the meantime, an entirely new (and radically different) release of KERMIT-80 is in preparation. It is expected that this new version will require considerable testing, so it is very desirable to stabilize the present version. Your reports will be of great help in doing this. - Frank da Cruz (Columbia U) ------- 13-Dec-83 19:15:42-EST,1730;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 13 Dec 83 19:15:33 EST Date: Tue 13 Dec 83 19:12:54-EST From: Frank da Cruz Subject: New KERMIT-20 available To: Info-Kermit@CUCS20 KERMIT-20 version 3C(133) is available for testing. There are two changes since version 3B was announced not too long ago: 1. 8th-bit-prefixing will now be done when requested. It can be requested: a. Explicitly via the SET EIGHTH-BIT-PREFIX command; b. Explicitly by the other side in the Send-Init packet; c. Implicitly if you SET PARITY to anything other than NONE. 8th-bit-prefixing allows 8-bit binary data to be sent through a 7-bit communication link, such as one that uses parity (examples are TELENET, which uses MARK parity, and IBM mainframes, which typically use MARK, ODD, or EVEN parity). The prefixing method is costly in transmission overhead, so KERMIT-20 will not use it unless asked to. Even then, the KERMIT on the other side must also know how do do this. Presently, only VAX/VMS and TOPS-10 KERMITs fall in this category, with others soon to come (including IBM PC and Apple DOS). 2. Whenever a timeout occurs, KERMIT-20 will clear any XOFF condition on the communication line, and transmit an XON. This will overcome any deadlocks that might occur when an XOFF is spontaneously generated on a noisy line, and both sides are doing XON/XOFF flow control (as KERMIT-20 does during file transfer). Report any problems to me. Next comes repeat-count processing. - Frank P.S. The relevant files are in KER:20KERMIT.* at host COLUMBIA-20, accessible as always via anonymous FTP. ------- 14-Dec-83 15:17:09-EST,1027;000000000000 Return-Path: <@CUCS20:jalbers@BNL> Received: from CUCS20 by CU20B with DECnet; 14 Dec 83 15:16:48 EST Received: from BNL by COLUMBIA-20.ARPA with TCP; Wed 14 Dec 83 15:13:45-EST Date: 14-Dec-83 14:28:15-EST From: jalbers@BNL Subject: Latest version of Kermit To: cc-fdc@COLUMBIA-20, info-kermit@COLUMBIA-20 Frank, and all: The latest version of Kermit works with the OCC-EXEC 1. I would like to know the changes between this and the last. The last version would not allow the PIA time to turn on the communications port's incoming buffer, so instead of connecting up to the modem port like it should, the PIA threw up and died, making it necessary to reset the osborne. I don't know how the PIA controlls the buffer, but there should be a way to make it either ignore it, or keep it on all the time. Thanks to those who got this latest version out! Jon Albers jalbers@bnl 14-Dec-83 16:46:43-EST,1270;000000000000 Return-Path: <@CUCS20:MCNULTY%UCI-20a.UCI@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 14 Dec 83 16:46:31 EST Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Dec 83 16:42:48-EST Date: 14 Dec 1983 1216-PST From: Dale M. McNulty Return-Path: Subject: KERMIT for Atari800 To: INFO-KERMIT.UCI-20A@Rand-Relay Cc: mcnulty.UCI-20A@Rand-Relay Received: from UCI-20a by UCI-750a; 14 Dec 83 12:28:16 PST (Wed) Via: UCI; 14 Dec 83 12:51-PST Is there a version of KERMIT for the Atari 800? If so, how can I get a copy? If not, is it possible to modify a version of KERMIT so that it will run on the Atari 800? This last question seems to imply that either: 1.Source KERMIT is available on the DEC 2020, DEC 10, or VAX 750 (since I have immediate access to these). a.Atari cross assembler available on one of the above. or 2.Source KERMIT available on Atari (or a listing available for hand entry). This, in turn, implies that the source be in Atari/6502 assembler, macro assembler, or translatable to one of these. Please, send replies to: Dale McNulty . Thanks for any help you can provide. Dale McNulty 14-Dec-83 18:57:40-EST,1203;000000000000 Return-Path: <@CUCS20:CC.FDC%COLUMBIA-20%UCI-20a.UCI@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 14 Dec 83 18:57:30 EST Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Dec 83 18:54:39-EST Date: Wed 14 Dec 83 16:53:08-EST From: Frank da Cruz Return-Path: Subject: Re: KERMIT for Atari800 Received: from COLUMBIA-20.ARPA by rand-relay.ARPA ; 14 Dec 83 13:58:28 PST (Wed) To: MCNULTY.UCI-20A@RAND-RELAY, INFO-KERMIT.UCI-20A@RAND-RELAY In-Reply-To: Message from "Dale M. McNulty " of Wed 14 Dec 83 15:16:00-EST Received: from Rand-Relay by UCI-750a; 14 Dec 83 14:08:15 PST (Wed) Received: from Uci-750a by UCI-20A; Wednesday, 14 Dec 83 14:36:32 PST Received: from UCI-20a by UCI-750a; 14 Dec 83 15:07:24 PST (Wed) Via: UCI; 14 Dec 83 15:14-PST John Palevich of Atari is working on a KERMIT for Atari machines (on his own time). If you want to contact him about what progress he's made, you can mail to palevich%atari.Atari@Rand-Relay (or something like that; I think CSnet may have changed its routing since I last corresponded with him). - Frank ------- 14-Dec-83 19:09:35-EST,1161;000000000000 Return-Path: <@CUCS20:MRC%SU-SCORE%UCI-20a.UCI@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 14 Dec 83 19:09:25 EST Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Dec 83 18:54:58-EST Date: Wed 14 Dec 83 14:22:10-PST From: Mark Crispin Return-Path: Subject: Re: KERMIT for Atari800 Received: from SU-SCORE.ARPA by rand-relay.ARPA ; 14 Dec 83 14:23:13 PST (Wed) To: MCNULTY.UCI-20A@RAND-RELAY Cc: INFO-KERMIT.UCI-20A@RAND-RELAY In-Reply-To: Message from "Dale M. McNulty " of Wed 14 Dec 83 12:16:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Received: from Rand-Relay by UCI-750a; 14 Dec 83 14:33:19 PST (Wed) Received: from Uci-750a by UCI-20A; Wednesday, 14 Dec 83 15:08:16 PST Received: from UCI-20a by UCI-750a; 14 Dec 83 15:36:13 PST (Wed) Via: UCI; 14 Dec 83 15:38-PST Yes, Jack Palevich has written an Atari KERMIT in the ACTION! programming language. If you have ACTION!, the source files are on PS:K*.* on Score. ------- 15-Dec-83 12:49:51-EST,2357;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 15 Dec 83 12:49:31 EST Date: Thu 15 Dec 83 12:44:16-EST From: Daphne Tzoar Subject: IBM PC Kermit Announcements To: info-kermit@CUCS20, info-ibmpc@USC-ISIB.ARPA A new version of PC KERMIT, version 1.20, is now available for testing. Some additions made to the current version (v1.18) include: - Allow ^X/^Z to interrupt sending/receiving a file or file group, respectively. - If get an error when receiving a file, clean up and send an error packet. Allow user to specify whether to keep what made it over or to discard it. - Add U. of Arizona changes so Kermit once again compiles on the Z100 (Joellen Windsor). Move IBM specific statements inside IBM conditional assembly blocks. - Print packet and retry numbers in decimal instead of hex. - Allow users to choose between COM1 (default) and COM2. Also, remind the user about which communications port they are using and at what baud rate when connecting to another system. - Add SET BACKARROW so can set backarrow to backspace or delete. (William Dair) And, set default to ON for renaming files due to filename conflicts. Change VT52 emulation messages to Heath-19 since that's what Kermit-86 emulates. Please report any bugs to Sy.Daphne@CU20B or CC.Daphne@Columbia-20. Users with Z100's are encouraged to try the test version as we are not sure all the Z100 compilation problems were fixed. The files are located in a publicly accessible directory on Columbia-20 called Kermit, logically defined as KER:. The relevant files are PCKERM20.ASM, PCKERM20.HLP, and PCKERM20.FIX (the printable version of the .EXE file.) To get a working copy of Kermit for the IBM PC or the Z100 (running MS DOS), copy the FIX file to the PC and run the BASIC program PCKEXE.BAS or use the bootstrapping programs PCKSEND.FOR and PCKGET.BAS. For more information, see the Kermit User's Guide (USER.DOC). Finally, there is a new format for the FIX files. Therefore, to reconstruct the .EXE file, make certain that you are using the most recent versions of PCKSEND.FOR, PCKGET.BAS, PCKEXE.BAS, and PCKFIX.ASM. Daphne Tzoar Systems Group ------- 17-Dec-83 10:58:29-EST,494;000000000000 Return-Path: <@CUCS20:howard@brl-bmd> Received: from CUCS20 by CU20B with DECnet; 17 Dec 83 10:58:25 EST Received: from BRL-BMD by COLUMBIA-20.ARPA with TCP; Sat 17 Dec 83 10:55:53-EST Date: Sat, 17 Dec 83 10:55:05 EST From: Howard Walter To: info-kermit@columbia-20 Subject: Kermit for UNIVAC?? I would appreciate information on the availability of kermit for use on a UNIVAC 1100 series machine running Exec 8. Thanks. Howard Walter howard@brl 17-Dec-83 12:52:38-EST,964;000000000000 Return-Path: <@CUCS20:louie@cvl> Received: from CUCS20 by CU20B with DECnet; 17 Dec 83 12:52:34 EST Received: from cvl by COLUMBIA-20.ARPA with TCP; Sat 17 Dec 83 12:50:00-EST Date: 17 Dec 1983 12:52:17-EST From: Louis A Mamakos Reply-to: louie@cvl To: howard@brl-bmd.arpa, info-kermit@columbia-20.arpa Subject: Kermit for UNIVAC?? Cc: butt@umd-univac.arpa The University of Maryland Computer Science Center is developing a KERMIT for the Sperry (what used to be Uniac) 1100 Series computer system. It's not yet completly working, and there are some strange kludges because of our terminal concentrators, but work is coming along. When a stable version exists, it will be announced on the list. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Louis A. Mamakos - Computer Science Center (Systems Staff) - Univ. of Maryland Internet: louie@cvl.ARPA uucp: ...!{seismo,ihnp4,allegra}!rlgvax!cvl!louie 19-Dec-83 11:29:16-EST,1114;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 19 Dec 83 11:29:10 EST Date: Mon 19 Dec 83 11:24:48-EST From: Frank da Cruz Subject: Re: Kermit for UNIVAC?? To: louie@CVL.ARPA, howard@BRL-BMD.ARPA, info-kermit@CUCS20 cc: butt@UMD2.ARPA, cc.fdc@CUCS20 In-Reply-To: Message from "Louis A Mamakos " of Sat 17 Dec 83 12:52:17-EST There's already a UNIVAC-1100 version running at U of Wisconsin, written by Paul Stevens &/or Chuck Hutchins. It has been listed in KER:VERSIONS.DOC for some time. I'm still waiting for a tape from them. I'd hate to suddenly find two different versions on my doorstep (but that seems to be the way...). I'd encourage you to give these guys a call at 608-262-2016 or -0280 and see if your versions can be combined somehow. Unfortunately, I'm the only one who keeps records of who's working on what versions of KERMIT, so before embarking on a new one, it's always a good idea for the prospective implementor to give me a call to see if anyone else is already at work on the same thing. - Frank ------- 19-Dec-83 14:10:53-EST,898;000000000000 Return-Path: <@CUCS20:PGW@MIT-XX.ARPA> Received: from CUCS20 by CU20B with DECnet; 19 Dec 83 14:10:46 EST Received: from MIT-XX.ARPA by COLUMBIA-20.ARPA with TCP; Mon 19 Dec 83 14:07:52-EST Date: Mon 19 Dec 83 14:08:22-EST From: Paul G. Weiss Subject: Sending and gathering text To: info-kermit@COLUMBIA-20.ARPA I have two suggestions regarding "CONNECT" mode of KERMIT. It would be nice to be able to prepare a text file locally on the micro, and then go into CONNECT mode and have the contents of the file sent as if it were being typed on the keyboard. This would be terrific for something like MCIMAIL, which has a really crummy text editor. Then in the other direction, one should be able to record what comes back over the line in a local file. This would be useful for commercial infomation services, which charge on a connect-time basis. ------- 19-Dec-83 15:17:52-EST,1016;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 19 Dec 83 15:17:41 EST Date: Mon 19 Dec 83 15:11:21-EST From: Frank da Cruz Subject: Re: Sending and gathering text To: PGW@MIT-XX.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Paul G. Weiss " of Mon 19 Dec 83 14:08:10-EST Capturing and sending raw text are nice features, having nothing to do with the KERMIT protocol, of course, but certainly things that can be stuck into any particular implementation of KERMIT. In fact, many KERMITs already attempt, with varying degrees of success, to log to files during CONNECT. Sending raw text is another matter, however; it could probably never be done to everyone's satisfaction, because everyone would have a different application they might want to communicate with, and these applications could have very different requirements as to synchronization (answering prompts, clearing buffers, flow control, etc). - Frank ------- 19-Dec-83 18:10:43-EST,708;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 19 Dec 83 18:10:31 EST Date: Mon 19 Dec 83 18:07:44-EST From: Frank da Cruz Subject: New Release of Apple DOS KERMIT To: Info-Kermit@CUCS20 Many new features, many problems fixed (some still remain). The major new feature is the ability to select communication slot and device via SET commands, and support for several different serial cards. The files are available in KER:AP*.*, via anonymous FTP from host COLUMBIA-20. The file KER:APPKER.HLP describes this version of KERMIT for the Apple II with DOS. Thanks to Stevens Institute of Technology for contributing this new release. ------- 20-Dec-83 14:10:10-EST,3271;000000000000 Return-Path: <@CUCS20:AWALKER@RUTGERS.ARPA> Received: from CUCS20 by CU20B with DECnet; 20 Dec 83 14:09:54 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 20 Dec 83 14:06:26-EST Date: 20 Dec 83 14:04:49 EST From: Hobbit Subject: Merry Christmas! Have some bugs. To: info-kermit@COLUMBIA-20.ARPA I stand corrected and informed on VMS FINISH and transfer abort [Thank you Mr. Bush et al]. Having brought up new versions of everything, I still notice the following remaining problems [to be thrown on the Bug Report stack]: What is the standard concerning SEND [close connection] RECEIVE ? It would seem logical that you could SEND one file, regardless of name, and have it received on another system under a different name. I speak specifically of sending a Tops-20 file with a long name over to a VMS system. The VMS side rejects the filename and aborts if you simply type RECEIVE, and [even worse] if you type RECEIVE , it sits for a moment, returns, and no file was ever written. This can be lived with if you're willing to rename or copy a file with a long name before you transfer it, but can't Kermit be taught to ignore the filename packet and just use the data and the name you gave it? I could not find any clearly-labeled documentation on how to build 20 Kermit. Someone here clued me in about the CMD.MAC subtlety... The Tops-20 version doesn't show the GET command when you type ?, even though it's in the table. In the VMS help file [vmskermit.rnh]: there's an extra ^M in the entry concerning STATUS, which caused Runoff to hiccup. Easily fixed. VMS Kermit still dies with a reserved operand fault if you set DEBUG ON and try to do something. Mine was assembled from the BLISS machinecode listing [we don't have BLISS over here]. I was briefly having some trouble with a vax-vax transfer. I put the remote in server mode, and subsequent GETs complained of ''no more files''. Besides being rather cryptic, this message was wrong, since the file did indeed exist on the other side. Later on, it worked. I don't know what I did to fix it. Also, if you GET a bunch of files from a VMS server to a VMS Kermit, say *.FOR or something, you get Receiving ATX.FOR [OK] [OK] [OK] [OK] ... the subsequent filenames aren't stated. It would also be nice if VMS Kermit typed dots as it handled packets, like the 20 version. I'm considering sticking in a small subroutine to QIO a dot to the terminal after RPACK or SPACK or wherever, but if it's easier to wait for a new and better version, I will. There is also a slightly annoying misfeature in the interrupt handler. While Kermit looks for a ^X or ^Z from the terminal, it throws away all other input. Therefore you can't type ahead and give it a bunch of files; you have to babysit it. Suppose the extra typeahead were throw into a buffer and then *used*, or better yet, command file support?? That way you could even use Kermit in batch jobs [to transfer mail and whatnot. Command files might be easier than trying to write mail protocol into Kermit itself.] We're running VMS Kermit 2.0.011, and Tops-20 version 3B(127). _H* ------- 20-Dec-83 18:52:50-EST,1876;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 20 Dec 83 18:52:46 EST Date: Tue 20 Dec 83 18:49:43-EST From: Frank da Cruz Subject: Re: Merry Christmas! Have some bugs. To: AWalker@RUTGERS.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Hobbit " of Tue 20 Dec 83 14:04:49-EST Thanks for the bugs. I'll respond to a couple of them; the Stevens folks can respond to the others. There was some discussion a while back about specifying a different name for the file in SEND and RECEIVE. Here's what we agreed upon (from the current Protocol Manual): Since it can be useful, even necessary, to specify different names for source and destination files, these commands [i.e. SEND, RECEIVE, and GET] should take operands as follows (optional operands in [brackets]): SEND local-source-filespec [remote-destination-filespec] If the destination file specification is included, this will go in the file header packet, instead of the file's local name. RECEIVE [local-destination-filespec] If the destination filespec is given, the incoming file will be stored under that name, rather than the one in the file header pakcet. GET remote-source-filespec [local-destination-filespec] If the destination filespec is given, the incoming file will be stored under that name, rather than the one in the file header packet. If a file group is being sent or received, alternate names should not be used. [end of quote] Unfortunately, most of us haven't gotten around to putting this into our KERMIT programs yet. It's on the list... About installing DEC-20 KERMIT -- The Users Guide contains a section (4.1) on installing DEC-20 KERMIT, and it mentions CMD and all the other files you need. - Frank ------- 20-Dec-83 21:26:29-EST,2597;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 20 Dec 83 21:26:22 EST Date: Tue 20 Dec 83 21:23:06-EST From: Nick Bush Subject: Re: Merry Christmas! Have some bugs. To: AWalker@RUTGERS.ARPA cc: info-kermit@CUCS20 A few of the problems you mentioned with VMS Kermit have been fixed, and at least one should work in the copy you have. If you desire to have constant reassurance that the transfer is inprogress, give VMS Kermit the command "SET MESSAGE PACKET ON". It will then type out a single character and packet count for each packet sent or received. Unfortunately, if your terminal doesn't wrap at end of line, you end up having the characters printing in the last column - VMS doesn't keep track of the column and wrap onto the next line. In the next version, you can also type control-A and get a single line status message about the transfer. The file names that were missing in the "Sending..." (or receiving) messages are typed out in the next version. There still is a problem with VMS Kermit with respect to received file names. Currently, VMS Kermit just attempts to use the file name as specified in the packet, and if RMS-32 doesn't like the name, you will get an error. We haven't fixed this one yet, so for the time being, you need to restrict any files you send to having names of the form name.typ, with name being up to nine characters and typ being up to three. I don't know when this will get fixed, but it is on the list. The RECEIVE command with a file-specification currently behaves exactly the same as the GET command. This also will be changed in a future version, but again I'm not sure when. When VMS Kermit was started, there was no standard at all for the commands, and the RECEIVE command was put in to correspond more with the RECEIVE command in Kermit-80 than that in Kermit-20 (at the time it was the preferred way to do things - that has since changed). We have not seen the reserved operand fault in a long time, and were never able to reliably reproduce it. It may be related to the version of VMS Kermit is running under. Finally, the next version of VMS will be able to be run taking input from a command file (although it still won't accept an indirect file itself). I have successfully used this to run batch jobs to transfer quite a few files. (As part of the same fix, VMS Kermit will also write the debugging information to a file instead of the terminal.) The new version should be available within a few weeks. - Nick ------- 20-Dec-83 21:54:04-EST,2613;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 20 Dec 83 21:53:56 EST Date: Tue 20 Dec 83 21:51:07-EST From: Frank da Cruz Subject: Yet another new KERMIT-20 available To: Info-Kermit@CUCS20 Announcing yet another new version of KERMIT-20. This one is 3.3(140). The changes since 3C(133) are: Repeat count processing will be done automatically if the other side agrees (VAX/VMS and TOPS-10 KERMITs are among the other KERMITs that can do this, with others to follow). Repeated sequences of the same character will be collapsed into a special prefix, a repeat count, and one copy of the character itself. This tends to dramatically speed up the transmission of certain kinds of binary files, particularly small executable programs. You can't issue the RECEIVE command now if you're running KERMIT-20 in local mode, just as you couldn't issue the GET command if you were in remote mode. The SET EIGHTH-BIT-PREFIX command was removed. This is now tied to SET PARITY. KERMIT-20 will attempt to do 8th-bit-prefixing if you SET PARITY to anything other than NONE. In addition, KERMIT-20 will do 8th-bit- prefixing if the other side requests it. Allow a single file to be sent with a specified name, as in: SEND MUMBLE.FROTZ (AS) FOO.BAR KERMIT-20 will prompt you with the guide word (AS) if you give non-wild filespec to send. If you give a wild filespec, it will still prompt you with (INITIAL), since there's no satisfactory simple way to substitute file names when sending more than one file. By the way, the RECEIVE command has always had this feature. The GET command does not, because there's no way to tell if the given remote file specification is wild (now I understand why in FTP, the GET and MULTIPLE GET commands are distinct!). Version number typeout has been changed to conform to the new way DEC does it -- 3.3 rather than 3C. This version has been pretty thoroughly tested and seems to work with both newer and older versions of KERMIT. It's available at host COLUMBIA-20 as KER:20KERMIT.MAC and KER:20KERMIT.EXE via anonymous FTP. In addition, there is a draft of a new DEC-20 KERMIT manual available for comment in KER:20KERMIT.DOC or KER:20KERMIT.MSS (Scribe source). This is a first step in updating the KERMIT Users Guide and breaking it up into more manageable pieces. I'd be interested to what extent people think this draft would be a useful model for documentation of the other KERMIT implementations. - Frank ------- 21-Dec-83 06:09:23-EST,619;000000000000 Return-Path: <@CUCS20:Popiel.EMREL@HIS-BILLERICA-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 21 Dec 83 06:09:17 EST Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 21 Dec 83 06:06:47-EST Received: from HIS-BILLERICA-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 21-Dec-1983 06:01:34-est Date: 20 December 1983 13:22 est From: Popiel.EMREL at HIS-BILLERICA-MULTICS Subject: PASCAL version of KERMIT To: info-kermit at COLUMBIA-20 Acknowledge-To: Popiel.EMREL at HIS-BILLERICA-MULTICS Please let me know what Pascal versions of Kermit are currently available. 21-Dec-83 10:36:16-EST,826;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 21 Dec 83 10:36:10 EST Date: Wed 21 Dec 83 10:29:19-EST From: Frank da Cruz Subject: Re: PASCAL version of KERMIT To: info-kermit@CUCS20, Popiel.EMREL%HIS-BILLERICA-MULTICS@CISL-SERVICE-MULTICS.ARPA In-Reply-To: Message from "Popiel.EMREL at HIS-BILLERICA-MULTICS" of Tue 20 Dec 83 13:22:00-EST 1. RT-11 KERMIT is written in OMSI Pascal with PDP-11 assembler mixed in. 2. HP-98xx KERMIT is written in HP Pascal (similar to UCSD) 3. Terak KERMIT is written in UCSD Pascal with some PDP-11 assember procedures. 4. There's a VAX/VMS version written in a mixture of Pascal & Fortran. 5. The MTS version (I don't have it yet) is written in Pascal/VS. I think that covers the bases, so far... - Frank ------- 22-Dec-83 18:52:51-EST,743;000000000000 Return-Path: <@CUCS20:prophet%umcp-cs@CSNet-Relay> Received: from CUCS20 by CU20B with DECnet; 22 Dec 83 18:52:44 EST Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Thu 22 Dec 83 18:50:10-EST Date: 22 Dec 83 17:40:55 EST (Thu) From: Dennis Gibbs Return-Path: Subject: Kermit To: INFO-KERMIT@COLUMBIA-20 Via: UMCP-CS; 22 Dec 83 18:01-EST Greetings, I have the generic form of Kermit for CP/M. I thought I would send a msg asking if there existed a version of it for my Micro before I started modifying. I have a Altos 5-15D runs CP/M & MP/M. It has two floppies, 192K memory and so on...Thankyou for any comments you might have.. 22-Dec-83 19:48:51-EST,1318;000000000000 Return-Path: <@CUCS20:AWALKER@RUTGERS.ARPA> Received: from CUCS20 by CU20B with DECnet; 22 Dec 83 19:48:46 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Thu 22 Dec 83 19:46:08-EST Date: 22 Dec 83 19:32:55 EST From: Hobbit Subject: Storing attributes To: info-kermit@COLUMBIA-20.ARPA May I suggest that making Kermit handle file attributes between any two different machines is perhaps asking too much from an already good thing. I believe the original idea behind Kermit was to transfer 7-bit ascii files. This may be opinion, but would it perhaps not be easier to write a package for any given system to mash up binary files into printable characters [or the reverse] and then use Kermit to move the text across? This way, a stored binary file would look like any other text file, which is the same on any system. I suggest this because I wrote such a package for VMS, and have successfully transferred VMS images between machines with it. It seems that Kermit is reaching a stage where implementation of the blue-sky ideas may only lead to massive confusion. Similarly, a mail system could simply call Kermit to do its transferring and pass commands to it. Are there any ideas about this [besides making Kermit cook your breakfast]? _H* ------- 22-Dec-83 20:02:46-EST,1433;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 22 Dec 83 20:02:42 EST Date: Thu 22 Dec 83 19:58:10-EST From: Frank da Cruz Subject: Re: Kermit To: prophet%umcp-cs@CSNET-CIC.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Dennis Gibbs " of Thu 22 Dec 83 17:40:55-EST To bring CP/M Kermit up on the Altos 5, presumably under CP/M 2.x (as opposed to 3.x, i.e. CP/M-Plus): FIrst Make sure you have the latest CP/M Kermit, KER:CPMBASE.M80 (Kermit-80 version 3.6). Also get the file KER:CPMGENERI.HEX. You can try LOADing the latter and running it -- who knows, it just might work! If not, then look at the assembler source and check the IOBYTE definitions, and modify them for your system if necessary (presuming your system fully supports the IOBYTE). If none of that works, you'll have to add device- and system-dependent code for your system -- port address, status bits, screen codes, all that, on the model of the various systems that are present supported explicitly. BUT... DOn't put too much effort into it, because some time in the next few weeks (or months?), an entirely new, rewritten, modularized version of CP/M Kermit will appear. At that point, it will be a lot easier to produce support for new systems, and to enhance the protocol portion of the program. Watch this list for announcements. ------- 23-Dec-83 00:47:26-EST,1307;000000000000 Return-Path: <@CUCS20:cbosgd!mddc-b!chris@Berkeley> Received: from CUCS20 by CU20B with DECnet; 23 Dec 83 00:47:19 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Fri 23 Dec 83 00:44:45-EST Received: by UCB-VAX.ARPA (4.22/4.18) id AA18901; Thu, 22 Dec 83 21:42:43 pst Received: by cbosgd.UUCP (4.12/3.7) id AA22776; Fri, 23 Dec 83 00:30:59 est Sent-By: qusavx.UUCP Thu Dec 22 17:51:57 1983 Sent-By: mddc-b.UUCP Thu Dec 22 17:36:47 1983 Received: by mddc.UUCP (4.12/4.7) id AA00126; Thu, 22 Dec 83 17:36:47 est Date: Thu, 22 Dec 83 17:36:47 est From: cbosgd!mddc-b!chris@Berkeley (Chris Maloney) Message-Id: <8312222236.AA00126@mddc.UUCP> To: INFO-KERMIT@COLUMBIA-20.ARPA Subject: DECmate and WS78 to VAX/4.2 file transfers I will be asked to provide 'Kermit' service from a DECmate II to a VAX/4.2 unix machine. I would rather not force my users to buy the CPM option. Do they have a choose? Similiarly we need a kermit like service for the ancient DEC WS78 (the DECmate I). Any ideas? Thanks, Chris Maloney Management Decisions Development Corp. Fairfield, Ohio 45014 (513)874-6464 ..{ucbvax,decvax,inhp4,mhuxi}!cbosgd!qusavx!mddc!chris (uucp) cbosgd!qusavx!mddc!chris@BERKELEY (arpa) cca!decvax!cbosgd!qusavx!mddc!chris@SRI-CSL (arpa) 23-Dec-83 01:01:59-EST,1018;000000000000 Return-Path: <@CUCS20:prophet%umcp-cs@CSNet-Relay> Received: from CUCS20 by CU20B with DECnet; 23 Dec 83 01:01:55 EST Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Fri 23 Dec 83 00:59:24-EST Date: 22 Dec 83 23:17:03 EST (Thu) From: Dennis Gibbs Return-Path: Subject: Re: Kermit To: Frank da Cruz , prophet%umcp-cs@CSNet-Relay, Info-Kermit@COLUMBIA-20 Via: UMCP-CS; 22 Dec 83 23:28-EST Thankyou for the info, I have CPMGENERI.ASM, I have assembled it and loaded it, but it didnt work, since then I have started putting some of the system dependent stuff in it. I don't know Z80 assembly so I can't do much other than put in the port numbers in the defines and some set up some of the other system stuff. I won't work on it too much, just to become familar with the kermit system. I will eagarily await the new CP/M package....And you are right, I do run CP/M 2.2... Happy Holiday's...... 23-Dec-83 12:03:48-EST,1545;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Dec 83 12:03:41 EST Date: Fri 23 Dec 83 12:00:13-EST From: Frank da Cruz Subject: Announcing KERMIT for UNIVAC 1100 To: Info-Kermit@CUCS20 cc: howard@BRL-BMD.ARPA, louie@CVL.ARPA Announcing Sperry Univac KERMIT, contributed by Paul Stevens Madison Academic Computing Center 1210 West Dayton Street University Of Wisconsin Madison, Wisconsin 53706 (608) 262-9618 Here is the text of his letter: "For what it is worth, here is our version of KERMIT that runs on Sperry 1100/82. Documentation is meager. Instructions for users are in the listing itself in the form of `HELP' strings. Instructions for implementing on other 1100 computers amount to a few comments on page 1. Probably the most helpful comment consists of my name, address, and phone number. Good luck!" A subsequent phone conversation revealed that there actually is a manual, which you may obtain by sending a self-addressed stamped envelope to the above. It is not included with the distribution since there is no plain-text version of it (it was for a particular photocomposer using a text formatter than cannot produce plain text). The program is written in Univac 1100 Exec assembly language. The unusual use of alphabetic case in the listing is not a mistake; the author actually typed it in that way. The program is available at host COLUMBIA-20 via anonymous FTP in the file KER:UNIVAC.ASM. - Frank ------- 23-Dec-83 12:15:26-EST,1056;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Dec 83 12:15:20 EST Date: Fri 23 Dec 83 12:06:40-EST From: Frank da Cruz Subject: Re: DECmate and WS78 to VAX/4.2 file transfers To: cbosgd!mddc-b!chris@UCB-VAX.ARPA, INFO-KERMIT@CUCS20 In-Reply-To: Message from "cbosgd!mddc-b!chris@Berkeley (Chris Maloney)" of Fri 23 Dec 83 00:44:56-EST The only way to have KERMIT on a DECmate II is with the CP/M option. I believe there is a new "option" for interchanging files between the CP/M file system and the word processor file system. Thus if you have one DECmate II with the CP/M option, it can service WPS-78s and other DECmate II's that don't have CP/M or KERMIT, since the disks are (or can be) compatible. I sincerely doubt that anyone will ever write KERMIT to run on the PDP-8 which is inside the DECmates; I don't even know if it's possible to program it directly. There's always DEC's DX package... Did you know that DEC markets a version of DX for UNIX? - Frank ------- 28-Dec-83 14:34:08-EST,808;000000000000 Return-Path: <@CUCS20:OC.AMS@CU20B> Received: from CUCS20 by CU20B with DECnet; 28 Dec 83 14:34:03 EST Received: from CU20B by CUCS20 with DECnet; 28 Dec 83 14:32:31 EST Date: Sun 25 Dec 83 21:49:39-EST From: Bill Hall Subject: Re: PASCAL version of KERMIT To: info-kermit@CUCS20 In-Reply-To: Message from "Popiel.EMREL at HIS-BILLERICA-MULTICS" of Tue 20 Dec 83 13:22:00-EST I have written two versions in PASCAL. One runs on the MTS operating system (Michigan Terminal System) and is written in Pascal/VS. The other is written for the DEC-20. This was just an exercise since the Macro version is the one to use in practice, but it may provide a model for other systems. -Bill Hall Mathematical Reviews 611 Church Street Ann Arbor, MI 48107 ------- 29-Dec-83 22:24:09-EST,1067;000000000000 Return-Path: <@CUCS20:uucp@SU-Shasta> Received: from CUCS20 by CU20B with DECnet; 29 Dec 83 22:24:06 EST Received: from SU-Shasta by COLUMBIA-20.ARPA with TCP; Thu 29 Dec 83 22:23:58-EST Received: from decwrl by Shasta with UUCP; Thu, 29 Dec 83 19:20 PST Date: Wednesday, 28 Dec 1983 17:40:06-PST Sender: uucp@SU-Shasta From: decwrl!rhea!atfab!wyman@SU-Shasta Subject: DECmates and KERMIT Message-Id: <8312300304.AA04917@DECWRL> Received: from RHEA.ARPA by DECWRL (3.327/4.09) 29 Dec 83 19:04:46 PST (Thu) To: info-kermit@columbia-20.arpa Frank stated recently that he wasn't sure if KERMIT could be written for a PDP-8... Well, I don't want to sound defensive here, however, the DX protocol that IS written on the DECmates is very similar in many ways to the KERMIT protocol. If DEC could write DX on an 8 then KERMIT should be possible too! Since there are alot of DECmates, WPS-???, and WS78 systems in the world, and there are going to be many more... An interesting project might be the development of a DX-KERMIT server. bob wyman 30-Dec-83 09:08:02-EST,1254;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Dec 83 09:07:59 EST Date: Fri 30 Dec 83 09:07:37-EST From: Frank da Cruz Subject: Re: DECmates and KERMIT To: decwrl!rhea!atfab!wyman%SU-Shasta@SU-SCORE.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "decwrl!rhea!atfab!wyman@SU-Shasta" of Thu 29 Dec 83 22:24:12-EST Actually a "native" Kermit for the DECmate would be a great idea. Given that, you wouldn't need to buy DX for your DEC-10, DEC-20, VAX, etc, and (perhaps even more significant) you could now exchange files between your DECmate or WS-78 and your IBM mainframe, CP/M system, IBM PC, Apple, and all the other systems that speak KERMIT. To my knowledge, however, the only people who know how to program a DECmate are within DEC. Speaking of DX, about 3 years ago I was tracking down one of the persistent rumors about DEC running DECnet internally on a UNIX system in their internal engineering net. When I finally reached the person in Merrimac who ran ran the alleged system, he said no, it wasn't DECnet, just DX-UNIX, which was a commercial product developed for DEC by his group. But after that, I never heard anything about DX-UNIX. - Frank ------- 30-Dec-83 13:56:11-EST,1567;000000000000 Return-Path: <@CUCS20:abrams@mitre> Received: from CUCS20 by CU20B with DECnet; 30 Dec 83 13:56:07 EST Received: from mitre by COLUMBIA-20.ARPA with TCP; Fri 30 Dec 83 13:55:51-EST Date: 30 Dec 1983 13:34:41 EST (Friday) From: Marshall Abrams Subject: Call for Papers To: microgroups:@mitre Cc: abrams@mitre The IEEE Computer Society has issued a call for papers which I think would be of special interest to those of us involved with small computers. The conference title is The Small Computer (R)Evolution. The call for papers sys that the program will encompass a wide scope of applications: as tools for managers, professionals, non-professionals, students, home-users, hobbyists and as embedded elements of other systems. The program will include tutorials, panels, demonstartions, and technical papers." The schedule includes:Jan 3 1984 Proposals for tutorials due (these are all-day tutorials of professional quality with the speaker being paid) April 2 Paper, session, and panel proposals due April 16 Demonstration descriptions due The papers (due April; 2) are to be submitted in three copies and should range from 1000 to 5000 words. All mail is addressed to: Small Computer (R)Evolution c/o IEEE Computer Society P. O. Box 639 Silver Spring, MD 20901 I will be happy to supply further information, including a copy of the physical call for papers, on request. I would especially encourage formation of sessions concentrating on subjects/applications which from a group of co-workers. 30-Dec-83 17:38:55-EST,1503;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Dec 83 17:38:51 EST Date: Fri 30 Dec 83 17:38:31-EST From: Frank da Cruz Subject: New Release of Rainbow Kermit-86 To: Info-Kermit@CUCS20 cc: LCampbell@DEC-MARLBORO.ARPA This is version 0.2 of KERMIT for the DEC Rainbow 100 (and, hopefully, Rainbow 100+), to run under CP/M-86 version 1.0 or 2.0. It's still preliminary, and still missing some important features like wildcard sends. The major change is that it corrects a problem with modem signals versus internal modems. If the change works (I don't have an internal modem to test it on), you won't have to run SETDTR before running Kermit-86 on the Rainbow any more. (But you'll still have to run SETDTR before running Kermit-80 on the Rainbow, because there's no way to control modem signals from the Z80 side.) Thanks to Brian Orr in Idaho for the fix. The new release is available at host COLUMBIA-20 via anonymous FTP as: KER:RBKERMIT.CMD (executable program, 8-bit binary) KER:RBKERMIT.H86 (7-bit ASCII DR-format hex file, loadable with GENCMD) KER:RBKERMIT.HLP (short help file) The source is in KER:RB*.A86. If anyone has an internal modem, please get this new version and try it out, and let me know it the problem with DTR has been solved. Thanks! Meanwhile, there may be a version of KERMIT for the Rainbow under MS DOS some time soon; watch this space for announcements. - Frank ------- 30-Dec-83 18:28:32-EST,719;000000000000 Return-Path: <@CUCS20:lauren@rand-unix> Received: from CUCS20 by CU20B with DECnet; 30 Dec 83 18:28:29 EST Received: from rand-unix by COLUMBIA-20.ARPA with TCP; Fri 30 Dec 83 18:28:24-EST From: vortex!lauren at RAND-UNIX Date: Fri, 30-Dec-83 15:09:58-PST Sender: Lauren Weinstein Subject: DEC Engineering net To: info-kermit@COLUMBIA-20 The interface between the Enet (running DECnet) and the outside world (mostly UUCP) is basically a twisted pair running between a Unix and VMS machine. DEC is not running DECnet on UNIX, though they will soon be running UUCP on VMS (a version of my private UUCP code which I have to go back to Merrimack to finish up...) --Lauren--