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-- 2-Jan-84 19:27:49-EST,1303;000000000000 Return-Path: <@CUCS20:iam@cmu-cs-g> Received: from CUCS20 by CU20B with DECnet; 2 Jan 84 19:27:46 EST Received: from CMU-CS-G by COLUMBIA-20.ARPA with TCP; Mon 2 Jan 84 19:27:56-EST Date: 2 Jan 1984 15:06-EST From: Ira.Monarch@CMU-CS-G.ARPA Subject: Apple CP/M Kermit and Emacs To: INFO-KERMIT@CUCS20 Message-Id: <441921979/iam@CMU-CS-G> This is a direct reply to Francis Wilson who I haven't been able to reach @CUTC20, though I think it will have some general interest. My current understanding of how to get Apple CP/M Kermit to work with UNIX Emacs on a VAX is the following: If your system supports a Soroc IQ 120/ IQ 140 video terminal, then configure the Hardware Screen Function Table for use with a Datamedia-style terminal and the Software Table for the Soroc. This is explained in part V of the manual supplied by Microsoft. Once this is done you can "tell" UNIX that your video terminal is a Soroc by typing "setenv TERM Soroc" after you login. You might also want to change some Emacs key-bindings if they are incompatible with your particular hardware configuration. In other words the problem is not with Kermit, but with configuring Apple CP/M for a particular external terminal and getting the system your communicating with to recognize this. --Ira 3-Jan-84 08:51:51-EST,901;000000000000 Return-Path: <@CUCS20:decwrl!rhea!vax4!arson!roberts@SU-Shasta> Received: from CUCS20 by CU20B with DECnet; 3 Jan 84 08:51:48 EST Received: from SU-Shasta by COLUMBIA-20.ARPA with TCP; Tue 3 Jan 84 08:51:54-EST Received: from decwrl by Shasta with UUCP; Tue, 3 Jan 84 05:49 PST Date: Tuesday, 3 Jan 1984 05:35:42-PST Sender: decwrl!rhea!vax4!arson!roberts@SU-Shasta From: DMII 1.0 For: Keith Roberts ; Subject: MS-DOS Kermit Message-Id: <8401031344.AA14857@DECWRL> Received: from RHEA.ARPA by DECWRL (3.327/4.09) 3 Jan 84 05:44:55 PST (Tue) To: info-kermit@columbia-20.arpa Is it planned that the Rainbow MS-DOS Version of Kermit will Run on other machines...Such as the Z100 (ZDOS) ? I'm working DECmate II software development...I don't know if DEC has any plans of including Kermit Protocol in their DX Option.. But I'll ask. Keith Roberts 3-Jan-84 10:57:09-EST,515;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 3 Jan 84 10:56:52 EST Date: Tue 3 Jan 84 10:56:36-EST From: Frank da Cruz Subject: Re: MS-DOS Kermit To: info-kermit@CUCS20 In-Reply-To: Message from "DMII 1.0 For: Keith Roberts ;" of Tue 3 Jan 84 08:52:08-EST The MS DOS version of Kermit already does run on the Z100 under ZDOS, as well as the IBM PC. The machine it doesn't run on yet is the Rainbow. - Frank ------- 4-Jan-84 17:01:27-EST,1542;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 4 Jan 84 17:01:14 EST Date: Wed 4 Jan 84 17:00:42-EST From: Frank da Cruz Subject: New KERMITs for DEC Rainbow, NEC APC To: Info-Kermit@CUCS20 Announcing yet another release of KERMIT for the Rainbow-100, version 2.1, contributed by Ron Blanford of the University of Washington. This release adds many of the features that were missing before, notably: Wildcard sends . SET FILE ASCII / BINARY . Validation (and conversion if necessary) of incoming filenames . Proper handling of modem signals like DTR along with many minor improvements (for instance, packet numbers are displayed in decimal rather than hex). In addition, support was added for the NEC Advanced Personal Computer (APC). Like the previous release, this version keeps up at speeds up to and including 9600 baud. It has not been tested at 19,200 baud. The relevant files are available at host COLUMBIA-20 via anonymous FTP. For the Rainbow: KER:RBKERMIT.CMD Executable CP/M-86 program KER:RBKERMIT.H86 Hex file loadable by GENCMD KER:RBKERMIT.HLP A brief description of the features & limitations For the NEC APC: KER:APCKERMIT.CMD Executable CP/M-86 program KER:APCKERMIT.H86 Hex file loadable by GENCMD The source is in: KER:86*.A86 ASM86 source modules. The file KER:86KERMIT.HLP describes the program in more detail, lists features, restrictions, and known problems. - Frank ------- 5-Jan-84 00:19:11-EST,908;000000000000 Return-Path: <@CUCS20:WANUGA@MIT-XX.ARPA> Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 00:19:06 EST Received: from MIT-XX.ARPA by COLUMBIA-20.ARPA with TCP; Thu 5 Jan 84 00:18:35-EST Date: Thu 5 Jan 84 00:18:49-EST From: Thomas S. Wanuga Subject: Re: New KERMITs for DEC Rainbow, NEC APC To: info-kermit@COLUMBIA-20.ARPA cc: jprestivo@MIT-XX.ARPA In-Reply-To: Message from "Frank da Cruz " of Wed 4 Jan 84 19:33:26-EST My friend tried out the newly announced KERMIT on his NEC APC. He was able to transfer files with a TOPS-20 machine, but was unable to get the terminal emulator to work properly. Specifically, clearing the screen did not work. We tried telling TOPS-20 that the terminal was a H19, and then a VT52. What kind of terminal does this version of KERMIT emulate? Has anyone had similar problems? Tom Wanuga ------- 5-Jan-84 11:06:42-EST,451;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 11:06:26 EST Date: Thu 5 Jan 84 11:03:14-EST From: Frank da Cruz Subject: Re: New KERMITs for DEC Rainbow, NEC APC To: WANUGA@MIT-XX.ARPA, info-kermit@CUCS20 cc: jprestivo@MIT-XX.ARPA In-Reply-To: Message from "Thomas S. Wanuga " of Thu 5 Jan 84 00:19:12-EST I'll try to get an answer for you. - Frank ------- 5-Jan-84 11:19:39-EST,502;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 11:19:19 EST Date: Thu 5 Jan 84 11:14:09-EST From: Daphne Tzoar Subject: PC Kermit version 1.20 To: info-kermit@CUCS20, info-ibmpc@USC-ISIB.ARPA Version 1.20 of PC Kermit is now the default and has been renamed to PCKERMIT. Version 1.18 is available as PCKOLD. Both files can be anonymously FTP'ed from node Columbia-20. Please report any problems to me. /daphne ------- 5-Jan-84 14:31:56-EST,938;000000000001 Return-Path: <@CUCS20:CONTEXT@WASHINGTON.ARPA> Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 14:31:49 EST Received: from WASHINGTON.ARPA by COLUMBIA-20.ARPA with TCP; Thu 5 Jan 84 14:27:28-EST Date: Thu 5 Jan 84 11:26:30-PST From: Ronald Blanford Subject: Re: New KERMITs for DEC Rainbow, NEC APC To: WANUGA@MIT-XX.ARPA cc: info-kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Thomas S. Wanuga " of Wed 4 Jan 84 21:54:31-PST The NEC APC emulates most of the functions of a VT100. The only function which doesn't work right because of a bug in the BIOS is the HOME cursor function. The ANSI command for this function is ESC [ H, with the omitted parameters defaulting to 1;1. This default does not work correctly on the APC, so the only solution is to always include the 1;1 specifically. I don't know how to get TOPS-20 to do this. Ron Blanford ------- 5-Jan-84 17:32:58-EST,3131;000000000001 Return-Path: <@CUCS20:CONTEXT@WASHINGTON.ARPA> Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 17:32:44 EST Received: from WASHINGTON.ARPA by COLUMBIA-20.ARPA with TCP; Thu 5 Jan 84 17:29:46-EST Date: Thu 5 Jan 84 14:28:44-PST From: Ronald Blanford Subject: NEC APC home cursor bug To: WANUGA@MIT-XX.ARPA cc: info-kermit@COLUMBIA-20.ARPA This message is in response to the complaint that the NEC APC does not clear screen when in terminal mode. The following patch to the NEC APC CPM.SYS will fix the bug that keeps it from correctly executing the ANSI HOME CURSOR function ESC [ H. The addresses for this patch are taken from CP/M-86 version 1.106.013 and although the patch is most likely correct for other versions, the addresses may differ. This patch is to the ESCCUP0 routine in the NEC CBIOS and the correct addresses can be obtained for any version by displaying the CBIOS.LST file that came with the CP/M-86 release and adding 80H (hex) to the first address it shows for that routine. As an elementary precaution, do not patch the release disk, and use a scratch disk for the initial modification and testing of the patch. The following sequence is exactly what I used to modify my own CPM. The computer output is in upper case, and my typing is in lower case. Don't enter the comments. A>ddt86 ;load DDT86 DDT86 1.1 -rcpm.sys ;read the CPM.SYS file START END 0800:0000 0800:6EFF -l3505 ;list the beginning of ESCCUP0 0800:3505 PUSH SI 0800:3506 MOV SI,5C68 0800:3509 CMP BYTE [5C67],00 0800:350E JZ 3517 0800:3510 CMP BYTE [5C67],02 0800:3515 JNZ 3540 0800:3517 MOV AX,[SI] 0800:3519 CMP AL,00 0800:351B JZ 3525 0800:351D SUB AL,01 0800:351F CMP AL,18 0800:3521 JB 3525 -a350e 0800:350E nop ;get rid of the JZ 3517 0800:350F nop 0800:3510 ;(just enter a RETURN here) -a3515 0800:3515 ja 3540 ;change the JNZ to JA 0800:3517 ;(just enter a RETURN here) -l3505 ;list it again to verify changes 0800:3505 PUSH SI 0800:3506 MOV SI,5C68 0800:3509 CMP BYTE [5C67],00 0800:350E NOP ;should be different here 0800:350F NOP 0800:3510 CMP BYTE [5C67],02 0800:3515 JA 3540 ; and here 0800:3517 MOV AX,[SI] 0800:3519 CMP AL,00 0800:351B JZ 3525 0800:351D SUB AL,01 0800:351F CMP AL,18 -wcpm.sys ;save the modified version -^C ;type CONTROL-C to exit from DDT86 A> Then reboot your system to load the new version of CPM. After you've tried out the new version, copy it to your working disks. The ANSI-VT100 features that the NEC APC supports are: direct cursor addressing (row, column) relative cursor addressing (up, down, left, right) line erasing (cursor to end, beginning to cursor, entire line) screen erasing (cursor to end, beginning to cursor, entire line) character attributes (underline, reverse, blink, but not bold) If your editor requires other features (such as perhaps cursor position read, reverse scroll, tab setting, or window erase) you'll have to add those to Kermit or to your CP/M BIOS. Good luck. Ron Blanford ------- 6-Jan-84 20:11:32-EST,905;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Jan 84 20:11:28 EST Date: Fri 6 Jan 84 20:12:05-EST From: Frank da Cruz Subject: Announcing KERMIT for MTS To: Info-Kermit@CUCS20 Just arrived from the University of Michigan, Ann Arbor: KERMIT for the Michigan Terminal System (MTS), which is a non-IBM operating system for IBM 370-series mainframes. There are two (count them) versions, one in IBM assembler written by Chris Thomson, and another in Pascal/VS written by Bill Hall of Math Reviews. The assembler version has no documentation beyond some comments at the top of the listing; the Pascal version has a .DOC file. MTS KERMIT is available in KER:MTSKERMIT.* (3 files) on host COLUMBIA-20 via anonymous FTP. Thanks to Gavin Eadie of U. Mich. for rounding up these implementations and sending them in. - Frank ------- 8-Jan-84 20:21:39-EST,1700;000000000000 Return-Path: <@CUCS20:decwrl!rhea!atfab!wyman@Shasta> Received: from CUCS20 by CU20B with DECnet; 8 Jan 84 20:21:34 EST Received: from Shasta by COLUMBIA-20.ARPA with TCP; Sun 8 Jan 84 20:20:41-EST Received: from decwrl by Shasta with UUCP; Sun, 8 Jan 84 17:20 PST Date: Sunday, 8 Jan 1984 16:49:09-PST From: decwrl!rhea!atfab!wyman@Shasta Subject: KERPAC -- An answer to the MAIL need??? Message-Id: <8401090058.AA21291@DECWRL> Received: from RHEA.ARPA by DECWRL (3.327/4.09) 8 Jan 84 16:58:18 PST (Sun) To: info-kermit@columbia-20.arpa Although the discussion of KERMIT-MAIL has died down a bit... With the consensus seeming to be that such a thing should not be done, there is still an outstanding requirement for "standard" mail protocols for the micros which rely not only on predictable syntax/semantics but also on the availability of some sort of widely available reliable transport layer. The existence of the KERMIT packet definition is one of the nice things about the protocol. The expandablity provided by the definition as it stands is a great plus... What I would like to propose is that the packet definition be made to stand independent of KERMIT itself and that KERMIT the file transfer program be defined as simply one of potentially many applications that will one day use the KERMIT Packet (KERPAC) as a base. What do you think? Is the KERMIT Packet structure appropriate for general use? Is there a better packet structure that already exists? bob wyman (DEC-Enet) ATFAB::WYMAN (UUCP) {decvax,ucbvax,allegra}!decwrl!rhea!atfab!wyman (ARPA) decwrl!rhea!atfab!wyman@Berkeley.ARPA decwrl!rhea!atfab!wyman@SU-Shasta 8-Jan-84 22:23:35-EST,3529;000000000000 Return-Path: <@CUCS20:Nemnich.PDO@MIT-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 8 Jan 84 22:23:28 EST Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Sun 8 Jan 84 22:22:53-EST Date: Sunday, 8 January 1984 22:17 est From: Bruce Nemnich Subject: Re: KERPAC -- An answer to the MAIL need??? To: decwrl!rhea!atfab!wyman@SU-SHASTA.ARPA cc: info-kermit@COLUMBIA-20.ARPA, protocols@RUTGERS.ARPA In-Reply-To: Message of 8 January 1984 19:49 est from "decwrl!rhea!atfab!wyman at SU-SHASTA" Message-ID: <840109031755.538962@MIT-MULTICS.ARPA> Date: Sunday, 8 January 1984 19:49 est From: decwrl!rhea!atfab!wyman at SU-SHASTA Subject: KERPAC -- An answer to the MAIL need??? To: info-kermit at COLUMBIA-20 Although the discussion of KERMIT-MAIL has died down a bit... With the consensus seeming to be that such a thing should not be done, there is still an outstanding requirement for "standard" mail protocols for the micros which rely not only on predictable syntax/semantics but also on the availability of some sort of widely available reliable transport layer. The existence of the KERMIT packet definition is one of the nice things about the protocol. The expandablity provided by the definition as it stands is a great plus... What I would like to propose is that the packet definition be made to stand independent of KERMIT itself and that KERMIT the file transfer program be defined as simply one of potentially many applications that will one day use the KERMIT Packet (KERPAC) as a base. What do you think? Is the KERMIT Packet structure appropriate for general use? Is there a better packet structure that already exists? bob wyman (DEC-Enet) ATFAB::WYMAN (UUCP) {decvax,ucbvax,allegra}!decwrl!rhea!atfab!wyman (ARPA) decwrl!rhea!atfab!wyman@Berkeley.ARPA decwrl!rhea!atfab!wyman@SU-Shasta Yes, there is a better protocol already designed called PCNET. The name has nothing to do with a product of the same name sold by Orchid Technologies; the people working on the PCNET I am writing of were using the name long before Orchid. The problem is that little work has been done recently on PCNET. The protocol was originally designed about 5 years ago (there have been changes since), but there is only one full implementation I know of (by Robert Elton Mass on MIT-MC). There are many implementations partially completed. PCNET was designed from the beginning as a link-level protocol; any desirable application (mail, ftp, telnet/supdup, et cetera) can be written on top of it. PCNET provides one or more extremely reliable 8-bit data channels to its applications, even on hosts which can send only capital letters, numbers, and common punctuation characters. It is better than Kermit for many reasons; if you want more technical information, I can supply you with it. Now, if only we PCNET volunteers can get going (actually, I have been working on it again for the last couple of weeks on Multics and my IBM PC). --bruce P.S. -- Bob, I have CC'd this to the Protocols discussion group in hope of getting more comments therefrom. Hope you don't mind. 9-Jan-84 21:51:34-EST,4660;000000000000 Return-Path: <@CUCS20:HFISCHER@USC-ECLB> Received: from CUCS20 by CU20B with DECnet; 9 Jan 84 21:51:22 EST Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Mon 9 Jan 84 21:46:56-EST Date: 9 Jan 1984 1846-PST From: HFISCHER%USC-ECLB@SRI-NIC Subject: Test version of PC kermit has server function added To: Info-Kermit at COLUMBIA-20 cc: HFischer at ECLB A number of folks have expressed an interest in a version of the IBM PC Kermit program which also functions as a server. Intense pressure at my company (Litton Data Systems) to be able to do something with all of our PC's so that managers could collect their status reports automatically prompted me to make an initial test release of the PC (and Heath) Kermit (with server added). I have succeeded in modifying PCK20.asm to become both the regular local Kermit and additionally a server. As a server, the program (the same identical program) can function as an unattended remote, either controlled by its own console, or with the DOS-2 CTTY command, over the communications line. The modified kermit is in my directory for those who would like to test it. At Arpanet site "USC-ECLB" FTP file pck20.new for the modified assembler code, and file pck20.exe for the 8-bit mode .exe file. If you'd rather have the file some other way, there are two choices; mail me a floppy (Herman Fischer, Litton Data Systems, 8000 Woodley, ms 44-30, Van Nuys, CA 91409) or contact me by net or phone (we could put my PC into server mode and transmit the .exe file directly). Please let me know of any problems, or questions in getting it up. My telephone number is 213/902-5139 (but I will be out of town next week and the week after, net accessible next week but not at all the week after). I have tested it using the resources available in my company (my test setup is a Sytek local area network with 9600 baud communications between multiple PC's). Obviously there are many combinations of equipment which are still to be tried. If you must run under DOS 1, then you can only load the kermit server on the serving machine's console (because DOS 1 cannot redirect commands over comm links). When you load kermit, after setting the baud rates, parity, or whatever, issue the command "server". This places your machine in a receive state, whereby callers can send to you, receive from you (default directory only). Don't let remote callers issue "finish" or "logout" because that'll return your machine to DOS, and then subsequent callers cannot access kermit without your presence to reload it. It is much more sexy to use DOS 2 CTTY to redirect your keyboard to the comm line. Then the caller can use dir, edlin, type, and just about all programs which use DOS (not BIOS) calls. (BASIC uses BIOS calls, so it won't cooperate with CTTY.) If your machine has CTTY COM1 issued, then the caller can do whatever he wants, including loading and running PC Kermit. For PC Kermit, your caller must type in a command to load Kermit and override the DOS 2 CTTY redirection (because your comm line probably needs set baud and other preparatory commands, and the server command, and because PC kermit uses BIOS console I/O (lest it not run on DOS 1 any more)). Once the remote caller is ready, to load kermit, he MUST do it (or invoke batch files) as thus: "kermit < yourfile.xx > con:" where yourfile.xx contains something like: "set baud 9600 server". He then does his "^]C" and tells his kermit what to send/receive/finish. When finished, he again can connect and operate the remote PC's DOS (those programs not using BIOS, of course). Wildcards work as usual. Drive id's work, but are tricky, for example, because getting a file from a sepecified drive of the server will stuff the file onto the default drive of the recipient. If the owner stumbles back into the office with the "serving machine", since we have ">con:" on the kermit statement he will see the ongoing transactions. I have modified the program so that a ^C issued at the main console of the serving machine will abort the program and return to DOS. Also, that means now that a ^C at any point while sending or receiving, even if you are not a server, will abort the program (you might have to follow the ^C by a bunch of enter depressions, depending on where you caught the program hanging). I will next try to think of some way to make this Kermit version do some type of elementary mailing task with unix go-betweens. Herm Fischer (HFischer@eclb) ------- 12-Jan-84 00:31:22-EST,1769;000000000000 Return-Path: <@CUCS20:HOROWITZ@USC-ISIF> Received: from CUCS20 by CU20B with DECnet; 12 Jan 84 00:31:10 EST Received: from USC-ISIF.ARPA by COLUMBIA-20.ARPA with TCP; Thu 12 Jan 84 00:28:38-EST Date: 10 Jan 1984 20:37:13 PST From: HOROWITZ@USC-ISIF Subject: kermit - and the spreadsheet To: info-kermit@COLUMBIA-20 Hi, I hope you can help me on this one. I had been using an H-19 connected via a Racal Vadic 3451 modem to a VAX750 running Unix 4.1. I replaced the h-19 by my ibm pc which has 442K and a color graphics monitor and ran kermit to connect to the VAX. All appeared to be well until i executed my spreadsheet program. Instead of getting an empty spreadsheet that looked like: a1 a b c d e f g 1 2 3 4 5 6 7 8 9 10 Note that on my h19 the column and row labels appear in reverse video. I instead get a1 a b c d e f g 2 3 4 5 6 7 8 9 10 For some reason it loses the indicator for row 1. I believe it is lost on the far right of the monitor, but i cannot see it. If i try to place a number in location a1, it does so in what appears on the screen to be location a2. Also the arrow keys don't work but other keys behave properly. Is there some advice or help you can give me? I did change my terminal type to vt52, but that produced other problems. (the field cursor was not visible and the arrow keys didn't work) Besides the spreadsheet doesn't look as nice on a vt52 as that terminal requires an extra space for reverse video and so the spreadsheet doesn't display the row and column indicators in reverse video as it does on my h19. setting the terminal type to vt100 was also fruitless. Ellis Horowitz ------- 12-Jan-84 00:52:12-EST,1321;000000000000 Return-Path: <@CUCS20:HOROWITZ@USC-ISIF> Received: from CUCS20 by CU20B with DECnet; 12 Jan 84 00:52:08 EST Received: from USC-ISIF.ARPA by COLUMBIA-20.ARPA with TCP; Thu 12 Jan 84 00:50:14-EST Date: 11 Jan 1984 21:49:00 PST From: HOROWITZ@USC-ISIF Subject: kermit and the spreadsheet To: info-kermit@COLUMBIA-20 This is my second note on a problem with kermit that i hope you can help me with. Since i now understand the problem a bit better i thought i would follow my first note with this one even before you answered the first. I am using kermit on my ibm-pc and connecting it to our vax 750 which runs unix 4.1. kermit is emulating an h-19 according to its status command. My problem is that when i run the spreadsheet program on the vax the number 1 (indicating the first row) does not appear. apparently it has disappeared somewhere on the line above. this problem also occurred on my h-19 when i first got it. by going off-line and typing esc v it redefined the wrap so that the spreadsheet was properly displayed. not knowing how to do this in kermit i tried to redefine the kermit end-of-line character and i set it to every value between 0 and 31 without effect. I hope this clarifies the problem for you. thanks in advance for your assistance. ellis horowitz ------- 13-Jan-84 00:37:23-EST,2543;000000000000 Return-Path: <@CUCS20:HFISCHER@USC-ECLB> Received: from CUCS20 by CU20B with DECnet; 13 Jan 84 00:37:18 EST Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Thu 12 Jan 84 19:36:28-EST Date: 12 Jan 1984 1633-PST From: HFISCHER%USC-ECLB@SRI-NIC Subject: Test Version of PC Kermit has TAKE added To: info-kermit at COLUMBIA-20 A suggestion by cc.fdc for a TAKE command in PC kermit has gnawed at me, especially now that I am trying to use Kermit here to do our mail integration to Unixes. (TAKE redirects Kermit inputs temporarily to come from a named file.) We need to be able to set up a number of parameters easily, and it is a pain to type in the baud, port, parity, and all that rot every time you load, because if you are like me, you use three different computers, on different networks, different ports, and at different baud rates. Then again, some others complain about simple things like Hayes (&Qubie) modem dialing commands, which a computer should be capable of assisting, and it seemed related to the take issue. I have added TAKE filename to the PC kermit test version on the net, accessible at node usc-eclb as PCK20.new (assembly code) and PCK20.exe (8 bit mode executable code file). TAKE uses a full pathname, so you can place your take files (such as EMACS and function key definitions) in a "\bin" like directory. This function checks for the presence of DOS 2 to operate. It allows nesting up to ten levels (unless your CONFIG.SYS restricts open files count to less). A take file on the command line will be executed before the console is accessed. A special feature allows a take file to "take" from the user's keyboard within its nesting levels, by asking for the device "<". If a user enters EXIT he pops back to the nesting level from whence he was called. Eof on a take file pops nesting levels back to where it was called from. If a take file has the EXIT command in it, it exits directly to DOS. Additionally there now is a SET CONSOLE [xx;xx;p command, for those with DOS 2's ANSI.SYS handler. This allows the PC user to define keystrokes (such as the arrows and function keys) to be meaningful to his host computer (EMACS vs INed), and for his autodialer and login. The [xx;xx;p follows the DOS manual page 13-11. I will distribute TAKE files with SET CONSOLE commands for EMACS and INed as they get done. Herm Fischer ------- 13-Jan-84 10:33:17-EST,1132;000000000000 Return-Path: <@CUCS20:jim@rand-unix> Received: from CUCS20 by CU20B with DECnet; 13 Jan 84 10:33:09 EST Received: from rand-unix by COLUMBIA-20.ARPA with TCP; Fri 13 Jan 84 10:29:59-EST Date: Friday, 13 Jan 1984 07:20-PST To: HOROWITZ@USC-ISIF Subject: Re: kermit and the spreadsheet Cc: info-kermit@COLUMBIA-20 In-reply-to: Your message of 11 Jan 1984 21:49:00 PST. From: jim@rand-unix Ellis - Remember me? I haven't seen you around for quite a while. I switched from an H89 to a PC with Kermit to a Vax runnin 4.1BSD, and have had no trouble using it with Jim Guyton's termcap entry for all screen-oriented stuff. If this doesn't work with your spreadsheet, at least it may give a starting point. Jim Gillogly # first pass at a termcap entry for the ibm pc kermit # this is a vt52 emulator with some h19 features added # to do: check delay on screen clear # jdg 7/6/83 dv|vt52|dec vt52:\ :bs:cd=\EJ:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :co#80:li#24:nd=\EC:\ :pt:sr=\EI:up=\EA:ku=\EA:kd=\EB:kr=\EC:kl=\ED: ii|ibm|kermit vt52 extension:\ :al=\EL:cd=\EJ:ce=\EK:dc=\EN:dl=\EM:\ :se=\Eq:so=\Ep:tc=vt52: 14-Jan-84 21:17:56-EST,2026;000000000000 Return-Path: <@CUCS20:BRACKENRIDGE@USC-ISIB> Received: from CUCS20 by CU20B with DECnet; 14 Jan 84 21:17:52 EST Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Sat 14 Jan 84 21:16:46-EST Date: 14 Jan 1984 1814-PST Subject: Kermit IP/TCP FTP From: Billy To: info-kermit@COLUMBIA-20 cc: postel@USC-ISIB I would like to propose KRFC??? that someone make a program on either Unix or Tops-20 that combine Kermit and an IP/TCP based FTP. This program would have the same user interface as the standard Kermit with the addition of two new commands: CONNECT (to host) and LOGIN. CONNECT would establish an IP/TCP FTP session, and LOGIN would allow a user to login to that remote host and connect to a particular directory. Kermit would behave identically to the current implementation with the exception that the files transferred could be from any directory on any machine on the internet. Wild carding would be supported in the same fashion it is currently by Kermit. This would be particularly useful to those of us who run large mailing lists. There are many recipients of computer mail who are not directly connected to the ARPA or MIL-NETS, but who need to transfer files to or from these mailing list central sites. This scheme would ensure an orderly controlled access to the network at minimal cost to the host site. It is important that the connection between FTP and Kermit be on a packet per packet basis as the Kermit host site should not be required to store intermediate temporary files. To make this scheme useful we would have to publish the phone number of these Kermit FTP servers. If necessary access could be restricted to specific hosts or specific directories. Jon Postel has assured me that if such a program existed he would favor installing such a public phone number at ISI to aid him in the distribution of his network RFC mailing list. As of yet I haven't found anyone willing to do the necessary programming. ------- 16-Jan-84 18:07:09-EST,2762;000000000000 Return-Path: <@CUCS20:ALBERS@MIT-ML> Received: from CUCS20 by CU20B with DECnet; 16 Jan 84 18:07:00 EST Received: from MIT-ML by COLUMBIA-20.ARPA with TCP; Mon 16 Jan 84 18:06:07-EST Date: 16 January 1984 18:06 EST From: Jon P. Albers Subject: Setting up KERMIT for the OCC-exec (or CPM+(3.0)) To: kpno!brown @ LBL-CSAM cc: info-kermit @ COLUMBIA-20 I'm sorry I couldn't get back to you sooner, my host had a lot of problems handeling and routing the mail.. I'll tell you how I did it (get KERMIT up on the Exec): 1. I ftp'ed the GENERIC kermit (ker:CPMGENERI.ASM) from columbia-20, 2. transfered it to my micro by modem7. If you don't have it, you can try capturing KERMIT to your disk. 3. I put it, MAC.COM, and HEXCOM.COM (MAC and HEXCOM are on CP/M disk #3 as supplied to you from OCC) on a blank, formatted disk. 4. assembled it using MAC. To do it, put a blank, formatted disk in drive B:, and the disk you made in step 3 in drive a:. Then, I typed the following: MAC CPMGENERI.ASM $AA HB SZ PZ After you type that, and press return, the drive will begin running, and alternating. After a short time, they will stop, and a message will be printed on the screen. You now have CPMGENERI.HEX on drive B:. 5. Now, type: B: And return to log on to drive B:, then type: a:HEXCOM B:CPMGENERI.HEX And a return. Again, the drives will spin, and in a moment, you will have CPMGENERI.COM, and executable at that! OOPS! I forgot to tell you, use WordStar, and edit CPMGENERI.ASM as a non- document (the 'N' option from the 'not editing' menu). Look down the first few pages and find something that looks like this: ROBIN EQU TRUE Change the TRUE to FALSE (If it is FALSE already, leaeve it that way), and then look for: CPM3 EQU FALSE And change the FALSE to TRUE (If it is TRUE already.........) and save it, deleteing the file CPMGENERI.BAK. This should go between steps 3 and 4. 6. Use SYSCOPY, and put a copy of the system on the disk you put CPMGENERI.COM on (the one in drive B:). 7. Use the program SETUP, get the system from drive B:, and go to the option COMMUNICATIONS PORT. Change the device assignment to AUXIN:/AUXOUT:, and the baud rate to what you will be using the Executive in KERMIT at, most likely 300 or 1200. (Note:, when you change baudrates, you must change it here (via SETUP) before you can use KERMIT at that baud rate.) 8. Exit the program and save the system setup to drive b:, and press the reset button. Now boot up on the new drive (withCPMGENERI.COM on it) and execute CPMGENERI.COM. You can now use KERMIT. If you need more info, contact me at: ALBERS@ML Jon Albers 18-Jan-84 22:01:56-EST,531;000000000000 Return-Path: <@CUCS20:Iglesias@uci-750a> Received: from CUCS20 by CU20B with DECnet; 18 Jan 84 22:01:48 EST Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; Wed 18 Jan 84 22:00:14-EST Date: 18 Jan 84 19:01:25 PST (Wed) To: info-kermit@Columbia-20 Subject: Kermit for CP-6 From: Mike Iglesias Is there a KERMIT for a Honeywell CP-6 system? Is anyone in the process of writing one? Is anyone thinking about writing one? Thanks for any info. Mike Iglesias University of California, Irvine 19-Jan-84 09:43:55-EST,734;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 19 Jan 84 09:43:50 EST Date: Thu 19 Jan 84 09:42:47-EST From: Frank da Cruz Subject: Re: Kermit for CP-6 To: iglesias@UCI-750A.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Mike Iglesias " of Wed 18 Jan 84 19:01:25-EST To my knowledge, no one has done anything for any Honeywell system except those that run Multics. There are implementations of KERMIT in various high-level languages that would be good starting points -- PL/I, Fortran, Pascal, etc. Anyone who decides to embark on such a venture should let me know first, so I can prevent others from duplicating the effort. - Frank ------- 20-Jan-84 19:41:36-EST,653;000000000000 Return-Path: <@CUCS20:Mailer@USC-ECLB.ARPA> Received: from CUCS20 by CU20B with DECnet; 20 Jan 84 19:41:33 EST Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; Fri 20 Jan 84 19:41:11-EST Date: 20 Jan 1984 1636-PST From: HFISCHER at USC-ECLB.ARPA Subject: Keyboard Cursor and Function Key Setups for Kermit To: info-kermit at COLUMBIA-20 Two sets of files in my directory on ECLB contain console setups for my test version of kermit (the current one, PCK20.NEW.3). These are: PCINed.* for unix'es INed editor (from Interactive Sys.) < " >PCemcs.* for emacs keyboard cursor controls Herm Fischer ------- 21-Jan-84 16:11:38-EST,3145;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 16:11:32 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:10:57-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29266; Sat, 21 Jan 84 13:10:01 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA12703; Sat, 21 Jan 84 12:58:47 pst Date: Sat, 21 Jan 84 12:58:47 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212058.AA12703@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: Kermit CP/M v3.6 Bugs and Modifications (1 of 11) This is the cover letter for a series of ten (10) modifications and corrections to CP/M Kermit Version 3.6 (cpmbase.m80 ftped on 83-12-12). Since we must modify kermit for our use here, it would be nice if kermit distributions could be set up in such a way that our local mods can be fitted to new distributions without intensive re-implementation. Distribution of the complete new source after heavy modification makes such tools as UNIX diff virtually unusable. A simple way to do this would be to sequence the entire source and use a modification name plus sequence for individual modification sets. This serves both to identify the mods associated with a particular fix or change, and to permanently identify lines that are unchanged. Below is our current bug list for v3.6: These are the known bugs in CP/M 80 Kermit Columbia Version 3.6 as modified and distributed by us. Version history is: COL36 Columbia's release version 3.6 of 83-12-12. UCB3614 Gts reinstall of COL36 as of 84-01-21. 83-11 FIXED UCB3604 partially fixed COL36 GTS: VT52 emulation does not work properly in most versions. Caused by absence of cursor addressing and errors in the vt52 to terminal table (ttab:); entries not all exactly four bytes. 83-11 FIXED UCB3606 GTS: If a duplicate file name is received kermit crashes with "file r/o" if the existing file is $r/o. This is because the attribute bits are not cleared in the file control block (fcb) after the initial open and, hence, the modified filename is created $r/o and kermit cannot write it! 83-11 FIXED UCB3607 GTS: Kermit accepts lowercase filenames on receive; CP/M cannot use. 84-01 unsolved GTS: Filenames geinve to kermit cannot contain "-", "&", and probably other characters perfectly valid in CP/M. 84-01 unsolved GTS: When ^Z or ^X is used to terminate a send or receive, kermit says "Unable to receive ack from host" rather than something informative. Other circumstances give equally obtuse messages. 84-01 unsolved GTS: When ^Z or ^X is used to terminate a send or receive with CMS Kermit, it doesnt stop immediately but seems to mimick continuing to the end of the file. Probably our CMS Kermit does not respond to EOF under these circumstances???? 83-12 NEEDED GTS: When talking to UCB cal, a BREAK must be used to interrupt output since cal is half-duplex. Kermit cannot generate a BREAK. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg 21-Jan-84 16:25:35-EST,892;000000000000 Return-Path: <@CUCS20:G.FUSSELL@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 16:25:32 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:25:03-EST Date: Sat 21 Jan 84 13:16:48-PST From: Carl Fussell Subject: rt kermit To: info-kermit@COLUMBIA-20.ARPA Address: Santa Clara University Has anyone done a kermit for RT-11 in macro? Would like to find out before I attempt it. Have been "playing" with the omsi version but have strange things occuring... (arbitrarily, it will work fine, then next time, it destroys the contents of SY:) problem is I do not have omsi pascal and perhaps there is some library problems altho' ODT seems to show me every thing set up properly.... anyway, if anyone has a macro version, I would very much appreciate hearing... thanx... Carl ------- 21-Jan-84 16:37:48-EST,1306;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 16:37:40 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:30:15-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29421; Sat, 21 Jan 84 13:29:22 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13177; Sat, 21 Jan 84 13:20:58 pst Date: Sat, 21 Jan 84 13:20:58 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212120.AA13177@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CPMBASE.M80 Mod UCB3607 (6 of 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.07asm 83-10-31 gts, CFO ;UCB3607 > ; Force received file names to upper case (gofil2:, gofil6:). ;UCB3607 > 2100a > cpi 'a' ; Force upper case ;UCB3607 > jm gofl2a ; ;UCB3607 > ani 5Fh ; ;UCB3607 > gofl2a: ; ;UCB3607 2133a > cpi 'a' ; Force upper case ;UCB3607 > jm gofl6a ; ;UCB3607 > ani 5Fh ; ;UCB3607 > gofl6a: ; ;UCB3607 21-Jan-84 16:50:07-EST,1349;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 16:50:01 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:31:12-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29435; Sat, 21 Jan 84 13:30:13 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13155; Sat, 21 Jan 84 13:19:43 pst Date: Sat, 21 Jan 84 13:19:43 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212119.AA13155@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CPMBASE.M80 Fixes UCB3605 (4 of 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.05asm 83-10-23 gts, CFO ;UCB3605 > ; Changes for assembly under RMAC. ;UCB3605 > ; Local is a reserved name and is changed to locall. ;UCB3605 > ; Title and aseg pseudo ops inserted. Title gives warning in ASM. ;UCB3605 > 172a > > ASEG ;UCB3605 3737c < jmp local ; 06H SET LOCAL --- > jmp locall ; 06H SET LOCAL ;UCB3605 3925c < local: lxi d,ontab --- > locall: lxi d,ontab ;UCB3605 21-Jan-84 17:02:17-EST,1489;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:02:13 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:32:13-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29453; Sat, 21 Jan 84 13:31:19 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13212; Sat, 21 Jan 84 13:22:15 pst Date: Sat, 21 Jan 84 13:22:15 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212122.AA13212@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CPMBASE.M80 Fix UCB3609 (8 fo 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.09asm 84-01-05 gts, CFO ;UCB3609 > ; Fix misplaced "if debug" at line 2399. ;UCB3609 > ; Fix split line for "baudtb: ...baud ra","te.." for brain. ;UCB3609 > ; Change "If debug" for rppos:/sppos: to "IF debug AND brain". ;UCB3610 > 2399d < IF debug 2403a > IF debug ;UCB3609 5444,5445c < baudtb: db ('A'-100O),esc,'~kType the letter corresponding with the baud ra < te desired.' --- > baudtb: db ('A'-100O),esc,'~kType the letter corresponding with the baud rate desired.' ;UCB3609 5504c < IF debug --- > IF debug AND brain ;UCB3609 21-Jan-84 17:14:38-EST,1583;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:14:31 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:33:08-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29464; Sat, 21 Jan 84 13:32:16 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13171; Sat, 21 Jan 84 13:20:21 pst Date: Sat, 21 Jan 84 13:20:21 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212120.AA13171@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CPMBASE.M80 Fix UCB3606 (5 of 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.06asm 83-10-23 gts, CFO ;UCB3606 > ; Fix more problems with cp/m 2.2 attribute bits (see also [UTK013]). ;UCB3606 > ; Trim attribute bits from fcb after each open when file to be received ;UCB3606 > ; already exists (gofil8:) so that subsequent file creation with ;UCB3606 > ; modified name does not have attribute bits set (e.g. $r/o)! ;UCB3606 > 2180a > lxi h,fcb ; Trim off any cp/m 2.2 attribute bits ;UCB3606 > mvi c,1+8+3 ; so they do not effect the new file. ;UCB3606 > gofl82: mov a,m ; ;UCB3606 > ani 7Fh ; ;UCB3606 > mov m,a ; ;UCB3606 > inx h ; ;UCB3606 > dcr c ; ;UCB3606 > jnz gofl82 ; ;UCB3606 21-Jan-84 17:26:50-EST,1824;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:26:46 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:34:09-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29483; Sat, 21 Jan 84 13:33:16 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13224; Sat, 21 Jan 84 13:23:50 pst Date: Sat, 21 Jan 84 13:23:50 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212123.AA13224@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CPMBASE.M80 Fix UCB3612 (10 of 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg This bug may have caused some wierdness if received junk overflowed the buffer and clobbered later stuff used in some versions. Normally rare.... -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.12asm 84-01-15 gts, CFO ;UCB3612 > ; Inpkt: prevent recpkt: buffer overflow from clobbering other storage. ;UCB3612 > ; If overflow, restart packet collection (see UCB3603). ;UCB3612 > ; Inpkt: store a cariage-return beyond the received packet to stop ;UCB3612 > ; rpack: if some error confuses it. ;UCB3612 > 2901a > lxi d,-recpkx ; Start over if packet buffer overflow ;UCB3612 > dad d ; ;UCB3612 > jc inpkt ; ;UCB3612 2904a > lhld pktptr ; Reload packet pointer ;UCB3612 > mvi m,cr ; Set a carriage-return to stop rpack: ;UCB3612 2906a > inx h ; Point to next char. ;UCB3612 2908d < inx h ; Point to next char. 5956a > recpkx: db cr,'$' ; = = = buffer limit ;UCB3612 21-Jan-84 17:38:55-EST,1831;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:38:51 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:35:08-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29497; Sat, 21 Jan 84 13:34:15 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13112; Sat, 21 Jan 84 13:18:13 pst Date: Sat, 21 Jan 84 13:18:13 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212118.AA13112@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CPMBASE.M80 Mod UCB3603 (2 of 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.03asm 83-08-?? vaf, CS ;UCB3603 > ; Improve packet receive reliability under error conditions. ;UCB3603 > ; Inpkt: skip leading junk until soh and restart if another soh. ;UCB3603 > ; Rpack: did check for imbedded soh's, but this only worked if the ;UCB3603 > ; buffer was allowed to overflow. Rpack: not changed to remove soh ;UCB3603 > ; checks, they do not cost much. ;UCB3603 > 2894a > inpkt1: call inchr ; Get first character. ;UCB3603 > jmp r ; Return failure. ;UCB3603 > cpi soh ; is it the beginning of a packet? ;UCB3603 > jnz inpkt1 ; if not, ignore leading junk ;UCB3603 > jmp inpkt3 ; else go put it in the packet ;UCB3603 2896a > cpi soh ; is it a new begining of packet? ;UCB3603 > jnz inpkt3 ; If not continue ;UCB3603 > lxi h,recpkt ; else throw away what you've got so far;UCB3603 > shld pktptr ; ;UCB3603 > inpkt3: ; ;UCB3603 > 21-Jan-84 17:51:05-EST,2045;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:50:59 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:35:41-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29507; Sat, 21 Jan 84 13:34:51 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13229; Sat, 21 Jan 84 13:24:19 pst Date: Sat, 21 Jan 84 13:24:19 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212124.AA13229@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CMPBASE.M80 Mod UCB3614 (11 of 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.14asm 83-08-?? vaf, CS and gts, CFO ;UCB3614 > ; Implement fuzzy timer for inchr: auto-retry, some machines only. ;UCB3614 > ; Timeout uses a two byte counter giving 65536 repetitions of the ;UCB3614 > ; inchr: loop. This gave 13.5 seconds on a TRS-80 Model 16. ;UCB3614 > 2598c > inchr: lxi h,0000h ; Reset fuzzy timer ;UCB3614 > shld inchr6+1 ; ;UCB3614 > inchr0: in mnprts ; Get the port status into A ;UCB3614 2604c < jz inchr ; If not go look for another char. --- > jz inchr6 ; If not go look for another char. ;UCB3614 2608,2609c < jnz inchr4 ; If not go look for another char. < ret --- > rz ; If so, return. 2616c < jnz inchr ; No, try for another character --- > jnz inchr6 ; No, try for another character ;UCB3614 2621a > inchr6: lxi h,0000h ; Increment fuzzy time-out ;UCB3614 > inx h ; ;UCB3614 > shld inchr6+1 ; (65,536 * loop time) ;UCB3614 > mov a,h ; (Retry if not timeout) ;UCB3614 > ora l ; ;UCB3614 > jnz inchr0: ; ;UCB3614 > call updrtr ; Count as retry ;UCB3614 > ret ; and return to do the retry ;UCB3614 > 21-Jan-84 18:03:17-EST,3315;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 18:03:12 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:36:37-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29515; Sat, 21 Jan 84 13:35:46 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13129; Sat, 21 Jan 84 13:18:53 pst Date: Sat, 21 Jan 84 13:18:53 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212118.AA13129@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CPMBASE.M80 Mod UCB3604 (3 of 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.04asm 83-08-?? vaf, CS and gts, CFO ;UCB3604 > ; Fix Kaypro II ttab: and clrlin: clear to eos + eol. ;UCB3604 > ; Remove default off for vtflg: now that ttab: fixed. ;UCB3604 > ; Add clear to end of line to most positioning strings. ;UCB3604 > ; Fix scrend: to past send/receive display. ;UCB3604 > ; When ibmflag, do not display null, xon, xoff or del (kpii graphics). ;UCB3604 > 3283a > IF kpII ;UCB3604 > lda ibmflg ; on the Kaypro II the following chars ;UCB3604 > ora a ; are displayed as greek symbols ... ;UCB3604 > jz prtch0 ; ;UCB3604 > mov a,e ; Get the char for testing. ;UCB3604 > cpi 0 ; if the char is a null ;UCB3604 > jz prtchr ; ignore it ;UCB3604 > cpi xon ; likewise for xons ;UCB3604 > jz prtchr ; ;UCB3604 > cpi xoff ; and xoffs ;UCB3604 > jz prtchr ; ;UCB3604 > cpi del ; and deletes ;UCB3604 > jz prtchr ; ;UCB3604 > prtch0: ; ;UCB3604 > ENDIF ;kpII ;UCB3604 > 5695c < clrlin: db cr,esc,'T$' ; Clear line. --- > clrlin: db cr,18H,'$' ; Clear line. ;UCB3604 5699c < scrfln: db esc,'=%+',esc,'T$' ; Place for file name. --- > scrfln: db esc,'=%+',esc,18h,'$' ; Place for file name. ;UCB3604 5701,5703c < scrend: db cr,lf,'$' < screrr: db esc,'=& $' ; Place for error messages. < curldn: db esc,'=$' ; Cursor lead-in [UTK016] --- > scrend: db cr,esc,'=( ',17h,'$' ; Place for prompt after done ;UCB3604 > screrr: db esc,'=& ',18h,'$' ; Place for error messages. ;UCB3604 > curldn: db cr,esc,'=$' ; Cursor lead-in [UTK016] ;UCB3604 5714,5715c < tj: db esc,'Y$',0 ; Clear to end of screen. < tk: db esc,'T$',0 ; Clear to end of line. --- > tj: db 17H,'$',0,0 ; Clear to end of screen. ;UCB3604 > tk: db 18H,'$',0,0 ; Clear to end of line. ;UCB3604 5894c < IF NOT (robin OR gener OR rainbo OR dmII OR cpm3 OR kpii) --- > IF NOT (robin OR gener OR rainbo OR dmII OR cpm3) ;UCB3604 5896,5900c < ENDIF ;NOT (robin OR gener OR rainbo OR dmII OR cpm3 < ; OR kpii) < IF kpii < vtflg: db 0 ; VT52 emulation flag (default off). < ENDIF ;kpii --- > ENDIF ;NOT (robin OR gener OR rainbo OR dmII OR cpm3) ;UCB3604 21-Jan-84 18:16:27-EST,3983;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 18:16:21 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:37:50-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29527; Sat, 21 Jan 84 13:36:56 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13203; Sat, 21 Jan 84 13:21:42 pst Date: Sat, 21 Jan 84 13:21:42 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212121.AA13203@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CPMBASE.M80 Mod UCB3608 (7 of 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.08asm 83-08-?? vaf, CS and gts, CFO ;UCB3608 > ; Split screen dependant trs-80 code into original for lifeboat cp/m ;UCB3608 > ; (trs80lb) and newer for Pickles and Trout cp/m (trs80pt). ;UCB3608 > ; Do not display xon, it is a graphics character for P+T cp/m. ;UCB3608 > ; Note: trs80 variable must also be set. ;UCB3608 > 192c < trs80 EQU FALSE ; For TRS-80 model II (Lifeboat CP/M 2.25C) --- > trs80 EQU FALSE ; For TRS-80 model II ;UCB3608 > trs80lb EQU FALSE ; Lifeboat 2.25C CP/M Display ;UCB3608 > trs80pt EQU FALSE ; Pickles + Trout CP/M Display ;UCB3608 442a > ;NEEDS display definition (e.g., trs80lb, trs80pt) ;UCB3608 3282a > > IF trs80pt ;UCB3608 > cpi xon ; For P+T cp/m, xon is a graphic ;UCB3608 > jz prtchr ; so ignore it. ;UCB3608 > ENDIF ;trs80pt ;UCB3608 3632c < IF (osbrn1 or apple OR trs80 OR kpii); [UTK016] --- > IF (osbrn1 or apple OR trs80lb OR kpii); [UTK016];UCB3608 3639c3546 < ENDIF ;(osbrn1 or apple OR trs80 OR kpii)[UTK016] --- > ENDIF ;(osbrn1 or apple OR trs80lb OR kpii)[UTK016] ;UCB3608 3640a > IF trs80pt ;UCB3608 > ;P+T CP/M uses the same cursor positioning as the H19 or VT52. ;UCB3608 > ENDIF ;trs80pt ;UCB3608 > 5632c < IF trs80 --- > IF trs80lb ;UCB3608 5634c < versio: db 'Kermit-80 V3.6 [TRS-80 II CP/M]',cr,lf,'$' --- > versio: db 'Kermit-80 V3.6 [TRS-80 II Lifeboat CP/M]',cr,lf,'$' 5658c < ENDIF ; trs80 --- > ENDIF ; trs80lb ;UCB3608 > > IF trs80pt ;UCB3608 > outlin: db 0Ch,cr,lf,tab,tab ;UCB3608 > versio: db 'Kermit-80 V3.6 (UCB%I%) [TRS-80 II P+T CP/M]',cr,lf,'$';UCB3608 > delstr: db 10O,' ',10O,'$' ; Delete string ;UCB3608 > clrspc: db ' ',10O,'$' ; Clear space. ;UCB3608 > clrlin: db cr,01h,'$' ; Clear line. ;UCB3608 > clrtop: db 0Ch,'$' ; Clear screen and go home. ;UCB3608 > scrnp: db esc,'Y#5$' ; Place for number of packets. ;UCB3608 > scrnrt: db esc,'Y#5',lf,'$' ; Place for number of retries. ;UCB3608 > scrfln: db esc,'Y%+',01h,'$' ; Place for file name. ;UCB3608 > scrst: db esc,'Y#T$' ; Place for status. ;UCB3608 > scrend: db cr,esc,'Y( ',02h,'$' ; Place for prompt after done ;UCB3608 > screrr: db esc,'Y& $' ; Place for error messages. ;UCB3608 > curldn: db esc,'Y$' ; Cursor lead-in [UTK016] ;UCB3608 > ttab: ; Table start location. ; (MUST be 4 bytes each) ;UCB3608 > ta: db 1Eh,'$',0,0 ; Cursor up. [UTK016];UCB3608 > tb: db 1Fh,'$',0,0 ; Cursor down. [UTK016];UCB3608 > tc: db 1Dh,'$',0,0 ; Cursor right. [UTK016];UCB3608 > td: db 1Ch,'$',0,0 ; Cursor left [UTK016];UCB3608 > te: db 0Ch,'$',0,0 ; Clear display ;UCB3608 > tf: db 11h,'$',0,0 ; Enter Graphics Mode ;UCB3608 > tg: db 14h,'$',0,0 ; Exit Graphics mode ;UCB3608 > th: db 06h,'$',0,0 ; Cursor home. [UTK016];UCB3608 > ti: db 1Eh,'$',0,0 ; Reverse linefeed. [UTK016];UCB3608 > tj: db 02h,'$',0,0 ; Clear to end of screen. ;UCB3608 > tk: db 01h,'$',0,0 ; Clear to end of line. ;UCB3608 > ENDIF ; trs80pt ;UCB3608 21-Jan-84 18:29:26-EST,10640;000000000000 Return-Path: <@CUCS20:gts%G.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 18:29:12 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:40:38-EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA29545; Sat, 21 Jan 84 13:39:42 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA13218; Sat, 21 Jan 84 13:23:17 pst Date: Sat, 21 Jan 84 13:23:17 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401212123.AA13218@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20 Subject: CPMBASE.M80 Implement MDI UCB3610 (9 of 11) The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83. The form similar to that of UNIX diff. Greg Small gts@ucbpopuli.Berkeley.ARPA or gts%ucbpopuli.Berkeley gts@ucbpopuli.Berkeley.BITNET or gts@ucbunixg -------------------------------------------------------------------------------- 0a1 > > ;UCB 36.10asm 83-10-06 gts, CFO ;UCB3610 > ; Implement seperate terminal definitions for machines that do not ;UCB3610 > ; have a built in and therefore standard terminal. ;UCB3610 > ; Implement tvi925 and adm3a cursor positionable crts. The tvi925 ;UCB3610 > ; implementation is designed to work acceptably on the adm3a and the ;UCB3610 > ; adm3a implementation is just a tiny revision to the vt52 emulation. ;UCB3610 > ; Most other similar crts can either use the tvi925 implementation or ;UCB3610 > ; be implemented as small changes similar to the adm3a implementation. ;UCB3610 > ; Implement crt, basic non-positionable crt similar to generic. ;UCB3610 > ; Implement the Morrow Micro Decision I (mdI). ;UCB3610 > 199a > mdI EQU FALSE ; Morrow Micro Decision I ;UCB3610 > > crt EQU FALSE ; Basic crt, no cursor positioning ;UCB3610 > adm3a EQU FALSE ; Adm3a Display ;UCB3610 > tvi925 EQU FALSE ; TVI925 Display ;UCB3610 496a > > IF mdI ;UCB3610 > mnport EQU 0FEH ; Morrow Printer UART data port ;UCB3610 > mnprts EQU 0FFH ; Morrow Printer UART command/status ;UCB3610 > output EQU 01H ; Output ready bit. ;UCB3610 > input EQU 02H ; Input ready bit. ;UCB3610 > ;Note: ; NEEDS terminal definition (e.g. tvi925 or adm3a above) ;UCB3610 > ENDIF ;mdI ;UCB3610 > 508a > > IF crt OR tvi925 OR adm3a ;UCB3610 > defesc EQU '\'-100O ; The default is Control \ ;UCB3610 > ENDIF ; crt OR tvi925 OR adm3a ;UCB3610 590a > > IF crt OR tvi925 OR adm3a ;UCB3610 > lxi h,versi0 ; Move machine mame ;UCB3610 > lxi d,versi1 ; to display header ;UCB3610 > mvi c,versi2-versi1 ; (limit to space) ;UCB3610 > start2: mov a,m ; (get character) ;UCB3610 > ani 7Fh ; (clean ascii) ;UCB3610 > jz start3 ; (stop if end of string) ;UCB3610 > stax d ; (store it) ;UCB3610 > inx h ; (increment source pointer) ;UCB3610 > inx d ; (increment destination pointer) ;UCB3610 > dcr c ; (continue if not too long) ;UCB3610 > jnz start2 ; ;UCB3610 > start3: ;UCB3610 > ENDIF ;crt OR tvi925 OR adm3a ;UCB3610 787c < IF NOT (gener OR osi OR cpm3) --- > IF NOT (gener OR osi OR cpm3 OR crt) ;UCB3610 790c < ENDIF ; NOT (gener OR osi OR cpm3) --- > ENDIF ; NOT (gener OR osi OR cpm3 OR crt) ;UCB3610 2498c < IF brain OR vector OR heath OR z100 OR trs80 OR telcon or kpII --- > IF brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI ;UCB3610 2506c < ENDIF ; brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII --- > ENDIF ;brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI ;UCB3610 2597c < IF brain OR vector OR heath OR z100 OR trs80 OR telcon or kpII --- > IF brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI ;UCB3610 2630c < ENDIF ; brain OR vector OR heath OR z100 or trs80 OR telcon OR kpII --- > ENDIF ;brain OR vector OR heath OR z100 or trs80 OR telcon OR kpII OR mdI ;UCB3610 3274c < IF brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII --- > IF brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI ;UCB3610 3279c < ENDIF ; brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII --- > ENDIF ;brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI ;UCB3610 3284c < IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3288c < ENDIF ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > ENDIF ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3296c < IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3308c < ENDIF ; NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > ENDIF ; NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3607c < IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3611c < ENDIF ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > ENDIF ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3632c < IF (osbrn1 or apple OR trs80 OR kpii); [UTK016] --- > IF osbrn1 or apple OR trs80 OR kpii OR tvi925 OR adm3a ;[UTK016];UCB3610 3639c < ENDIF ;(osbrn1 or apple OR trs80 OR kpii)[UTK016] --- > ENDIF ;osbrn1 or apple OR trs80 OR kpii OR tvi925 OR adm3a ;[UTK016];UCB3610 3641c < IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3656c < ENDIF ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > ENDIF ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3683c < IF NOT (robin OR rainbo OR gener OR dmII) --- > IF NOT (robin OR rainbo OR gener OR dmII OR crt) ;UCB3610 3695c < ENDIF ;NOT (robin OR rainbo OR gener OR dmII) --- > ENDIF ;NOT (robin OR rainbo OR gener OR dmII OR crt) ;UCB3610 3938c < IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3953c < ENDIF ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3) --- > ENDIF ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt) ;UCB3610 3955c < IF robin OR rainbo OR gener OR dmII OR osi OR cpm3 --- > IF robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt ;UCB3610 3961c < ENDIF ; robin OR rainbo OR gener OR dmII OR osi OR cpm3 --- > ENDIF ; robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt ;UCB3610 4109c < IF NOT (robin OR rainbo OR gener OR dmII OR cpm3) --- > IF NOT (robin OR rainbo OR gener OR dmII OR cpm3 OR crt) ;UCB3610 4119c < ENDIF ; NOT (robin OR rainbo OR gener OR dmII OR cpm3) --- > ENDIF ; NOT (robin OR rainbo OR gener OR dmII OR cpm3 OR crt) ;UCB3610 4528c < IF brain OR heath OR z100 OR trs80 OR telcon OR kpII --- > IF brain OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI ;UCB3610 4535c < ENDIF ; brain OR heath OR z100 OR trs80 OR telcon OR kpII --- > ENDIF ; brain OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI ;UCB3610 5422c5386 < IF NOT (robin OR gener OR rainbo OR dmII OR cpm3) --- > IF NOT (robin OR gener OR rainbo OR dmII OR cpm3 OR crt) ;UCB3610 5424c < ENDIF ;NOT (robin OR gener OR rainbo OR dmII OR cpm3) --- > ENDIF ;NOT (robin OR gener OR rainbo OR dmII OR cpm3 OR crt) ;UCB3610 5728c < IF gener OR osi OR cpm3 --- > IF gener OR osi OR cpm3 OR crt ;UCB3610 5739c < ENDIF ; gener OR osi OR cpm3 --- > ENDIF ; gener OR osi OR cpm3 OR crt ;UCB3610 5739a > > IF crt ;UCB3610 > versio: db 'Kermit-80 V3.6 (UCB%I%) [CRT] ' ;(35) ;UCB3610 > versi1: db ' ' ;(40) ;UCB3610 > versi2: db cr,lf,'$' ;UCB3610 > outlin: equ versi2 ;UCB3610 > ENDIF ;crt ;UCB3610 > ;UCB3610 > IF tvi925 ;UCB3610 > outlin: db 'Z'-64,cr,lf ;UCB3610 > versio: db 'Kermit-80 V3.6 (UCB%I%) [TVI925] ' ;(35) ;UCB3610 > ENDIF ;tvi925 ;UCB3610 > ;UCB3610 > IF adm3a ;UCB3610 > outlin: db 'Z'-64,0,0,cr,lf ;UCB3610 > versio: db 'Kermit-80 V3.6 (UCB%I%) [ADM3A] ' ;(35) ;UCB3610 > ENDIF ;adm3a ;UCB3610 > ;UCB3610 > IF tvi925 OR adm3a ;UCB3610 > versi1: db ' ' ;(40) ;UCB3610 > versi2: db cr,lf,'$' ;UCB3610 > ;UCB3610 > :Note: These are designed to work on both the tvi925 and the adm3a. ;UCB3610 > delstr: db 10O,' ',10O,'$' ; Delete string ;UCB3610 > clrspc: db ' ',10O,'$' ; Clear space. ;UCB3610 > clrlin: equ tj ; Clear line. ;UCB3610 > clrtop: db 'Z'-64,0,0,'$' ; Clear screen and go home. ;UCB3610 > scrnp: db esc,'=#3','$' ; Place for number of packets. ;UCB3610 > scrnrt: db esc,'=#3',lf,'$' ; Place for number of retries. ;UCB3610 > scrfln: db esc,'=%+',esc,'T',8,' $'; Place for file name. ;UCB3610 > scrst: db esc,'=#T$' ; Place for status. ;UCB3610 > scrend: db esc,'=( ',esc,'Y',cr,'$'; Place for prompt when done ;UCB3610 > screrr: db esc,'=& ',esc,'T',cr,'$'; Place for error messages. ;UCB3610 > curldn: db cr,esc,'=$' ; Cursor lead-in (cr 0s lncnt) ;UCB3610 > ENDIF ;tvi925 OR adm3a ;UCB3610 > ;UCB3610 > IF tvi925 OR adm3a ;UCB3610 > ttab: ; Table start location. ; (MUST be 4 bytes each) ;UCB3610 > ta: db 'K'-64,'$',0,0 ; Cursor up, stop at top ;UCB3610 > tb: db 'V'-64,'$',0,0 ; Cursor down, stop at bottom ;UCB3610 > tc: db 'L'-64,'$',0,0 ; Cursor right, stop at right ;UCB3610 > td: db 'H'-64,'$',0,0 ; Cursor left, stop at left ;UCB3610 > te: db 'Z'-64,0,0,'$' ; Clear display (2 pad nulls) ;UCB3610 > tf: db esc,'F$',0 ; Enter Graphics Mode NONE ;UCB3610 > tg: db esc,'G$',0 ; Exit Graphics Mode NONE ;UCB3610 > th: db 1Eh,'$',0,0 ; Cursor home. ;UCB3610 > ti: db esc,'j$',0 ; Reverse linefeed, scroll ;UCB3610 > tj: db esc,'Y$',0 ; Clear to end of screen. ;UCB3610 > tk: db esc,'T$',0 ; Clear to end of line. ;UCB3610 > ENDIF ;tvi925 OR adm3a ;UCB3610 > ;UCB3610 > IF adm3a ;UCB3610 > org tb ;UCB3610 > tb: db 'J'-64,'$',0,0 ; Cursor down CTL J ;UCB3610 > org ti ;UCB3610 > ti: db 'K'-64,'$',0,0 ; Reverse linefeed. ;UCB3610 > tj: db '$',0,0,0 ; Clear to end of screen NONE ;UCB3610 > ti: db '$',0,0,0 ; Clear to end of line NONE ;UCB3610 > ENDIF ;adm3a ;UCB3610 > > IF mdI ;UCB3610 > versi0: db '[Micro Decision I]',0 ;UCB3610 > ENDIF ;UCB3610 > 21-Jan-84 18:41:51-EST,518;000000000000 Return-Path: <@CUCS20:wkc@ardc> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 18:41:48 EST Received: from ARDC by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 17:02:11-EST Date: Sat, 21 Jan 84 16:58:01 EST From: William K. Cadwallender (LCWSL) To: info-kermit@columbia-20.arpa Subject: Kermit for RSX11 and HP9845b/9845c Has a kermit been done for a PDP11 running RSX11? We have an 11/24 with 1meg and 2 RL02 disks. How about an HP9845b or c? Bill Cadwallender wkc@ARDC 21-Jan-84 20:58:21-EST,439;000000000000 Return-Path: <@CUCS20:Malasky.PA@PARC-MAXC.ARPA> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 20:58:19 EST Received: from PARC-MAXC.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 20:58:02-EST Date: 21 Jan 84 17:58:54 PST (Saturday) From: Malasky.PA@PARC-MAXC.ARPA Subject: Please remove me from this list In-reply-to: <8401212124.AA13229@ucbpopuli.CC.Berkeley.ARPA> To: Info-Kermit@COLUMBIA-20.ARPA Thanks, Bruce 21-Jan-84 21:43:26-EST,522;000000000000 Return-Path: <@CUCS20:wkc@ardc> Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 21:43:20 EST Received: from ARDC by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 21:43:00-EST Date: Sat, 21 Jan 84 21:31:43 EST From: William K. Cadwallender (LCWSL) To: Info-kermit@columbia-20 Subject: Kermit for RSX11 and HP9845 Had a Kermit been done for a PDP11 running RSX11? We are using an 11/24 with 1 meg and 2 RL02 disks. How about Kermit for an HP9845b or c? Bill Cadwallender wkc@ARDC 23-Jan-84 11:05:18-EST,1243;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 11:03:32 EST Date: Mon 23 Jan 84 10:59:07-EST From: Frank da Cruz Subject: Re: Kermit CP/M v3.6 Bugs and Modifications (1 of 11) To: gts%ucbpopuli.CC@UCB-VAX.ARPA, INFO-Kermit@CUCS20 cc: cc.fdc@CUCS20, Eiben@DEC-MARLBORO.ARPA, G.Bush@CUCS20, G.WBC3@CUCS20, Wancho@SIMTEL20.ARPA, RFOWLER@SIMTEL20.ARPA, Cerritos@USC-ECL.ARPA, bray%tennesse.tennesse@RAND-RELAY.ARPA In-Reply-To: Message from "gts%ucbpopuli.CC@Berkeley" of Sat 21 Jan 84 16:11:19-EST Greg, thanks for the fixes and suggestions. As you know, it's tough to manage such a widespread distributed voluntary effort as KERMIT, particularly CP/M KERMIT, which tries to support so many different systems. We recently decided to stablize CP/M Kermit, except for bug fixes, and concentrate all new development in a totally rewritted, modularized version being done by Ron Fowler, one of the big MODEM people. Your fixes come at an opportune moment, since Bernie Eiben, one of the major CP/M Kermit contributors, is in the process of making one last pass over Kermit-80, and I'll send your work directly to him; I hope it gets in. - Frank ------- 23-Jan-84 11:15:05-EST,609;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 11:14:46 EST Date: Mon 23 Jan 84 11:03:53-EST From: Frank da Cruz Subject: Re: rt kermit To: G.FUSSELL@SU-SCORE.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Carl Fussell " of Sat 21 Jan 84 16:25:13-EST A MACRO-11 implementation of KERMIT for RSX-11M and RSTS/E has been done by Brian Nelson of the University of Toledo (Ohio); it's on a tape, in the mail to me at this moment. He'll be adapting it for RT-11 over the next several weeks. - Frank ------- 23-Jan-84 11:36:57-EST,2287;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 11:36:49 EST Date: Mon 23 Jan 84 11:34:09-EST From: Frank da Cruz Subject: New release of KERMIT for HP98xx To: Info-Kermit@CUCS20 The files are in KER:HP9*.*, accessible via anonymous FTP from host COLUMBIA-20. The problem he alludes to is due to an omission in the KERMIT Protocol Manual, which will be fixed in a new revision: data fields of all packets EXCEPT the Send-Init (S) or the Info (I) packet, or the ACK to those packets, or the File Attributes (A) packet, should go through the encoding and decoding mechanisms for control prefixing, etc. - Frank ---------- Date: 20 Jan 84 05:29:39 EST From: GALLAHER@RUTGERS.ARPA Subject: New HP Kermit To: cc.fdc@COLUMBIA-20.ARPA Frank, I have a new version of HP-Kermit. All the source files have been modified, and there is one new file, KRMVERS.TEXT. I was going to add a few more things to this version of HP-Kermit before sending it over, but I discovered a severe bug in the last version that had to be fixed. It seems that the old protocol code did its control unquoting in the receive packet routine. Not only did file data packets get unquoted, but ALL packets did! This did not cause a problem until 20 Kermit started setting the QCTL and QBIN fields in its send-init packets to #Y. Since # happened to be the same character HP kermit was using for local quoting, HP kermit took the #Y to mean "use ^Y as the control quote"! I fixed it so the unquoting is only done for data packets. Since I lifted the protocol code from RTKERMIT, this bug is almost certainly in that version also. If you want I can try fixing it in there too, but I have no way to test it. By the way, I couldn't find any mention of this potential problem in the protocol document, though I didn't look very hard. I admit that quoting is obviously meaningless when the quote characters have not yet been defined, but some implementations (like this one) might not account for that... Besides the bug fix, the new version has nicer error reporting, the code in the protocol module is a little cleaner, and responds to interrupt keys ^X and ^Z. Mike (Gallaher@Rutgers) ------- 23-Jan-84 12:31:58-EST,494;000000000000 Return-Path: <@CUCS20:FRIEDMAN%RU-BLUE.ARPA@RUTGERS.ARPA> Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 12:31:53 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 23 Jan 84 12:30:42-EST Date: 23 Jan 84 12:29:28 EST From: FRIEDMAN@RU-BLUE.ARPA Subject: Apple kermit. To: info-kermit@COLUMBIA-20.ARPA Who is working on the Apple DOS version of kermit? I have some questions and suggestions. -Gadi ------- 23-Jan-84 16:40:15-EST,700;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 16:40:00 EST Date: Mon 23 Jan 84 16:33:37-EST From: Frank da Cruz Subject: KERMIT in MicroSoft BASIC To: Info-Kermit@CUCS20 Well, almost. This is a version sent to us from Sweden, written by Torbjorn Alm of the Stockholm ABC-Klubben for the Luxor ABC-800 in a language called Basic II, which he claims is very close to MicroSoft Basic. I don't know anything about this machine, but the Basic code might be adaptable to many micros. It's in KER:800*.*, available via anonymous FTP from host COLUMBIA-20. If anyone does anything with it, please let me know. - Frank ------- 23-Jan-84 16:54:16-EST,8710;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 16:54:00 EST Date: Mon 23 Jan 84 16:47:26-EST From: Frank da Cruz Subject: IBM PC Kermit To: Info-Kermit@CUCS20, Info-IBMPC@USC-ISIB.ARPA We (at Columbia) have decided to make a full blown effort at getting IBM PC Kermit in shape, and will be working on it full time over the coming weeks or months. While the present release, 1.20, is quite adequate, there remain gaps and problems. What's worse, 5 or 10 different sites have made significant modifications to this program -- most of them useful and worthwhile -- and we are badly behind in fitting all this work into the base version. What follows is our list of things to do (it's rather long). If you have comments on this list, please send them to me. And if you have additional suggestions, send those to me too, rather than changing the program yourself. Meanwhile, announcements will be made of test versions of PC Kermit from time to time, as the various features find their way into the program. Here's the list: * Support for multiple systems: First, the program should no longer be thought of as IBM PC Kermit, but rather MS DOS KERMIT. Support has been added to it (at other sites) for at least the following MS DOS systems: . DEC Rainbow 100, 100+ . Heath/Zenith 100 . Victor 9000 . Seequa Chameleon . Eagle 1600 . Ericson Step/One (Panasonic JB3000) And we'll soon be getting in some IBM Peanuts and HP-150s, which will have to be supported by this program too. Currently, only the IBM PC/XT and Z100 support are integrated into the same program. We need to integrate support for the other systems too. By the way, the IBM PC version is known to run without modification on certain PC-compatibles, including the Compaq portable and the Columbia MPC. * Program organization: The program is now a gigantic monolith, with conditional assembly to select the PC or Z100. It will only become larger and more tangled (like CP/M-80 KERMIT) if we support the additional systems in the same way. So it has to be broken up into separately compiled modules. There should be a system-independent module for the protocol, and system/device/etc-dependent modules for: . port i/o . modem control, if necessary (for "smart" &/or internal modems) . file i/o . printer i/o . screen display (cursor positioning, screen clearing, etc) . terminal emulation (some people have wanted to plug in their own terminal emulators) . command parsing (some people would prefer a Unix-style command parser, or a menu, or function keys, or a mouse, or a pointing finger, or ...) and so forth. This cuts down on assembly time, KERMITing time, etc, and -- if the modules have well-defined specifications and interfaces to the outside world -- should make it easy to support new systems by plugging in new modules. Doing it this way requires clear user-level documentation about how to put together a working KERMIT for an existing or new system. * I/O structure: Packet encoding/decoding must be separated from file/port i/o, to allow non-file data to be encoded/decoded, e.g. to send directory listings. For instance, it is now possible for you to type "GET FOO#BAR" (assuming you're talking to a system that allows "#" in filenames); since the argument for the server command doesn't go through the normal encoding mechanism, the remote KERMIT will see "FOO#BAR" and translate the "#B" to control-B. The data field of any packet should go through the encoding mechanism to get control & 8th-bit prefixes, etc. Obvious exceptions are the init and attributes packets. * Binary file transfer: . Get the 8th bit prefixing working reliably with DEC-10/20, VAX, etc. . Get binary file transfer working with CMS KERMIT. This requires implementation not only of 8th-bit prefixing, but also the dreaded FILE ATTRIBUTES packet, to allow arbitrary record boundaries to be preserved for CMS files sent to the PC and back. * Herm Fischer's changes: Test this stuff, integrate it, check it out on non-PC machines: . Server mode . TAKE command . Init file . Key redefinitions . etc * Kimmo Laaksonen's change: . Filename completion, a la TOPS-20 & TENEX. * Terminal emulation: . Modularize . Insert character is too slow when inserting a block of characters. . Use 25th line to display current settings -- baud, parity, etc. Maybe toggle (and/or scroll) this display with a function key. . SET HANDSHAKE to allow user to specify this. . SET FLOW-CONTROL option for XON/XOFF (during both terminal emulation & file transfer) . Session logging (with big memory buffer, XON/XOFF &/or handshake) . Multiple page screen memory (like HP or new Concept) . Distinguish between ^H and backarrow (they really are different); make SET BACKARROW only affect backarrow, not ^H too. . Support VT52/H19 reverse index command -- many editors, like VI, use it. . User-defined function keys. . SET BELL {VOLUME | PITCH | DURATION} . Support for IBM's ANSI.SYS to allow (relatively slow) ANSI terminal emulation. This has already been done by Glenn Everhart in the Seequa version (I think the same thing is also in Herm's SET CONSOLE business). . Support CTRL/PrtSc during terminal emulation (Shift/PrtSc already works). . Fix the getting-stuck-on-25th-line problem. . Do bounds checking on all cursor positioning commands. . (pie in the sky) Full-speed ANSI terminal emulation, windows, line/char insert/delete, etc. * Add local functions (like in CP/M Kermit 3.6 & above): These are especially handy for 1-drive systems (like the Peanut). . Directory listings . Deleting files . Find out how much space is left on disk . Change default disk * Fix existing problems: . Always update retry count on screen when there's a NAK or retransmit. . MS DOS file byte count includes the ^Z at the end of the file. If it's a text file, you don't want to send it; if it's a binary file you do. Find some way to do this right. Probably need to add SET FILE BINARY/TEXT like CP/M KERMIT. . COMND simulation -- currently, if any fields are left off, the command has no effect (like SET or SET IBM). It should either complain, or supply a default. Also, implement ^R, ^W. * Missing features from the protocol manual: . Timeouts . Fancy block check types -- 2 char checksum, 3 char CRC. . Repeat counts. . Sending file-management commands to server & displaying results. . Server-provided file management: delete, rename, directory, type, change directory, login, ... . DEFINE command for SET macros. * Etc: . Verify everything in SPAR. . Prevent receive-packet buffer overruns. . Ability to run in background from a batch file. . Ability to send a raw file (like in Kimmo's CP/M Kermit), with prevailing handshake/flow control (XON/XOFF, half duplex XON, etc). . Special features for PC-to-PC connection. For instance, sending an entire directory tree, to be replicated on the target system. . ^C during file transfer sends you straight back to command level. . Don't set the baud rate to 4800 when starting up, but leave it at whatever it was set at. If you want it at 4800 (or whatever), put a SET BAUD command in your KERMIT.INI file. . Appearance -- put some whitespace around "?" help messages. . Add a real "help" command that gives a bit more information. . Allow redirection of incoming files to devices other than disk: - Printer, to let PCs share printers. - Memory, to let programs be downloaded and started from remote disk. * Finally, a manual: A new manual needs to be written, for use in conjunction with the KERMIT User Guide, much like the new (draft version of the) KERMIT-20 Manual. The manual should contain not only detailed descriptions of the commands, but also hints about using KERMIT within the PC/MS DOS environment, for instance: Using KERMIT in conjunction with key redefinitions (like ProKey). For instance to get a META key for EMACS, to make the arrow keys work with your favorite editor. Using KERMIT as a terminal (can't transfer files!) over a protocol emulator as a 3270 -- inverse video, etc. . Using KERMIT with a RAM disk. . Using KERMIT with a "smart" modem. . Using KERMIT over TELENET, through a TAC, over TYMNET, etc etc . Nuts & bolts of connected two PCs. Any other suggestions? ------- 23-Jan-84 17:06:22-EST,1816;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 17:06:16 EST Date: Mon 23 Jan 84 16:50:44-EST From: Frank da Cruz Subject: Release 2.2 of Rainbow KERMIT-86 To: Info-Kermit@CUCS20 This new release of KERMIT-86 for the DEC Rainbow 100 running CP/M-86 version 1.0 or 2.0, submitted by the original author Bill Catchings, corrects several problems in the previous release, which was 2.1: The buffer is cleared at the correct times, so it is now possible to communicate normally with a KERMIT server (e.g. on the DEC-20). Some changes were made to the port handling which MAY clear up some problems people were having with modem signals when using internal modems, especially when carrier is dropped while KERMIT is running (e.g. when logging out from a dialup connection to the DEC-20). It is not possible to type carriage return to "wake up" a stuck file transfer in the same way this is possible in other microcomputer implementations of KERMIT. There is still an unresolved problem which prevents KERMIT-86 on the Rainbow from transferring files with the IBM mainframes. Terminal connection, however, works correctly. This problem will be fixed in a forthcoming release. The new release is available via anonymous FTP from host COLUMBIA-20 as KER:RBKERMIT.CMD (executable), KER:RBKERMIT.H86 (hex), KER:RBKERMIT.HLP (short documentation), and KER:86*.* (source). Please use your current version of KERMIT to download this new version. Report any problems to me; it is important to get the kinks ironed out of KERMIT-86 since it will soon replace KERMIT-80 as the standard KERMIT for the Rainbow, because KERMIT-80 no longer works on the Rainbow under release 2.0 of CP/M-86/80. - Frank ------- 23-Jan-84 17:19:29-EST,835;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 17:19:21 EST Date: Mon 23 Jan 84 17:03:10-EST From: Frank da Cruz Subject: Bug uncovered To: Info-Kermit@CUCS20 Greg Small at Berkeley found a bad bug in CP/M-80 Kermit, which is bound to exist in many other implementations as well. The bug is in the code that fills the received-packet buffer. The problem is that there is no bounds checking. If a sudden burst of noise (or a system message, or a "[You have mail from...]" message, etc) appears in the midst of a packet, the characters are deposited into the buffer past the end, overwriting other important data (or even code, depending upon how the program is organized). All KERMITs should deend themselves against this sort of thing. - Frank ------- 23-Jan-84 19:48:37-EST,697;000000000000 Return-Path: <@CUCS20:judd%umcp-cs@CSNet-Relay> Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 19:48:33 EST Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Mon 23 Jan 84 19:48:12-EST Date: 23 Jan 84 14:14:39 EST (Mon) From: Judd Rogers Return-Path: Subject: Re: CPMBASE.M80 Implement MDI UCB3610 (9 of 11) To: gts%ucbpopuli.CC@Berkeley, INFO-Kermit@COLUMBIA-20 Via: UMCP-CS; 23 Jan 84 17:40-EST From: Judd Rogers(judd@umcp-cs) PLEASE DON'T SEND LONG FILES ON THE NET. IT WASTS THE TIME OF PEOPLE WHO DO NOT WANT TO READ THEM.. INSTEAD SEND A SHORT ANOUNCEMENT AND MAKE THE FILE AVAILABLE. 24-Jan-84 12:40:18-EST,1115;000000000000 Return-Path: <@CUCS20:gts%ucbpopuli.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 24 Jan 84 12:40:08 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Tue 24 Jan 84 12:39:26-EST Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.22/4.19) id AA13246; Tue, 24 Jan 84 09:36:09 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.11) id AA19289; Tue, 24 Jan 84 09:30:44 pst Date: Tue, 24 Jan 84 09:30:44 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8401241730.AA19289@ucbpopuli.CC.Berkeley.ARPA> To: INFO-Kermit@COLUMBIA-20, judd%umcp-cs@CSNet-Relay Subject: Re: CPMBASE.M80 Implement MDI UCB3610 (9 of 11) Sorry, I did not realize that stuff to INFO-Kermit was automatically rebroadcast. I myself have been inundated with net return messages reporting machines that could not be reached, obsolte or out of service accounts, etc. I am not complaining, however, I need rapid feedback on Kermit issues in order to fulfill my kermit support fuction here, even though I may have to skim through many messages about versions I do not support. 25-Jan-84 11:51:20-EST,526;000000000000 Return-Path: <@CUCS20:LATZKO%RU-BLUE.ARPA@RUTGERS.ARPA> Received: from CUCS20 by CU20B with DECnet; 25 Jan 84 11:51:11 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 25 Jan 84 11:48:21-EST Date: 25 Jan 84 11:47:05 EST From: Alexander B. Latzko Subject: Apple Kermit To: info-kermit@COLUMBIA-20.ARPA cc: mione@RUTGERS.ARPA As far as I know Apple Kermit (DOS verison) was written by Tony Mione at Stevens Institue of Technology. alex ------- 25-Jan-84 13:30:55-EST,1076;000000000000 Return-Path: <@CUCS20:FONGHEISER@CWR20B> Received: from CUCS20 by CU20B with DECnet; 25 Jan 84 13:30:47 EST Received: from CWR20B by CUCS20 with DECnet; 25 Jan 84 13:04:41 EST Date: Wed 25 Jan 84 13:05:09-EST From: FONGHEISER@CWR20B Subject: Transferring directory trees To: info-kermit@CUCS20 Frank da Cruz mentioned the possibility of transferring entire directory trees with kermit. There are a few problems with this. Basically what would happen is you would have a directory file sitting on the remote system. However, there is no trace of the files in the directory. All of the real information about where the file is stored isn't even in the directory. A better approach is to use a program such as tar and then transfer the resulting file via kermit. The tar format is well documented and can probably be read by most systems. This means you wouldn't even have to worry about transferring say, from a MS-DOS system to a UNIX system. Carl Fongheiser FONGHEISER@CWR20B (CCnet) FONGHEISER%CWR20B@Columbia-20 (ARPA) ------- 25-Jan-84 18:50:07-EST,340;000000000000 Received: from CUCS20 by CU20B with DECnet; 25 Jan 84 18:50:02 EST Received: from LLL-MFE by COLUMBIA-20.ARPA with TCP; Wed 25 Jan 84 18:46:47-EST Date: Wed, 25 Jan 84 15:47 PST From: "Webb Mike"@LLL-MFE.ARPA Subject: KERMIT FOR TELEVIDEO 802 To: INFO-KERMIT@COLUMBIA-20.ARPA DOES SUCH A BEAST EXIST??? BEFORE I START. MIKE 25-Jan-84 20:11:41-EST,772;000000000000 Return-Path: <@CUCS20:HOWALD@USC-ECLB> Received: from CUCS20 by CU20B with DECnet; 25 Jan 84 20:11:37 EST Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Wed 25 Jan 84 20:10:06-EST Date: 25 Jan 1984 1708-PST From: HOWALD Subject: Kermit for Apple IIe w/Super Serial Card To: info-kermit@COLUMBIA-20 I am trying to install the 6502 version of Kermit on an Apple IIe with a super serial card. I'm having problems re-writing APPLBT.BAS so that it will work with the superserial card--I can't seem to get the right combination of IN#2, PR#2, and CTRL-A TERM MODE. If someone out there has gotten KERMIT working on the above setup, I would be grateful for their help. I am a novice where Apples are concerned. *james ------- 26-Jan-84 16:54:59-EST,2851;000000000000 Return-Path: <@CUCS20:OC.TREI@CU20B> Received: from CUCS20 by CU20B with DECnet; 26 Jan 84 16:54:51 EST Received: from CU20B by CUCS20 with DECnet; 26 Jan 84 16:54:04 EST Date: Thu 26 Jan 84 16:53:30-EST From: Peter G. Trei Subject: Apple DOS Kermit. To: info-kermit@CUCS20 [CU Area Apple/Kermit Hacker] People trying to use Kermit-65 (Apple DOS Kermit) Version 1.1 with a Super Serial Card have been running into problems. Here is how to make it work. 1. Before you start up Kermit, send the SSC the following string: ^AZ (thats Control-A, followed by Z). This will disable the SSC's command recognition. The SSC usually looks for ^A in the terminal input, and strips it out. It then looks at the next character, and if it is a valid SSC command, strips it out as well and performs the command. Trouble arises from the fact that Kermit uses ^A to announce the start of each packet. Typing ^AZ disables the SSC from seeing further ^A commands. If you really need to have access to the SSC commands again before you turn off the Apple, type ^A^W instead, which will change the command prefix to ^W, which should not appear during Kermit file transfer. There is a bug in the code to support the Super Serial Card, which must be fixed before it will work at all. If you look in the source code for Kermit-65 (APPLEK.M65 in , and search for the label TL2CP:, two lines further down you will see a line which reads: AND #$04 At this point, Kermit is ANDing a status register with a bitmask. If the result is non-zero, a character has been received from the modem. the problem is that 04 is the wrong mask; it should be 08, according to page 54 of the SSC manual. To fix this, you can either alter the source, recompile, and upload the new version, or much more quickly you can patch the binary version you already have. Here's how to do the patch from Applesoft: ]BLOAD APPLEK.BIN (or whatever you are calling your copy). ]POKE 8665,8 (thats a decimal address) ]BSAVE NEWKER,A$800,L$4900 Thats all. The new version contains the patch. With this, file transfer using the Super Serial Card has been done at 1200 baud. 3. Those of you who use 1200 baud modems will have noticed that you loose characters at the beginning of each line when the screen is scrolling. This is not Kermits fault, but rather the slowness of the software used to scroll the screen image in the Apples memory. According to the SSC manual, you can eliminate this by slightly narrowing the scroll window. The following poke does it: ]POKE 35,22 This will make line 22 the bottom of your scroll window, which is enough. I would be interested in hearing from anyone on the list who is using Kermit-65. Peter Trei, OC.TREI%CU20B@Columbia-20.Arpa ------- 27-Jan-84 13:29:13-EST,861;000000000000 Return-Path: <@CUCS20:decwrl!rhea!vax4!arson!ziemba@su-shasta> Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 13:28:57 EST Received: from su-shasta by COLUMBIA-20.ARPA with TCP; Fri 27 Jan 84 13:28:17-EST Received: from decwrl by Shasta with UUCP; Fri, 27 Jan 84 10:27 PST Date: Friday, 27 Jan 1984 10:05:29-PST From: decwrl!rhea!vax4!arson!ziemba (DMII 1.0 For: Irene Ziemba) Subject: Enclosed file "ZBOX.TXT" Message-Id: <8401271806.AA10078@DECWRL> Received: from RHEA.ARPA by DECWRL (3.327/4.09) 27 Jan 84 10:06:57 PST (Fri) To: info-kermit@columbia-20.arpa, "INFO-KERMIT@COLUMBIA-20.ARPA"@su-shasta Cc: ~z~@su-shasta Sirs/Madams, Please add me to your KERMIT subscription list. Can you also send me your earlier issues which deal with APPLEs? Much obliged, Irene 27-Jan-84 13:39:13-EST,801;000000000000 Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 13:39:08 EST Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 27 Jan 84 08:21:31-EST Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 27-Jan-1984 08:08:14-est Received: from HIS-LA-CP6.ARPA by HIS-PHOENIX-MULTICS.ARPA dial; 26-Jan-1984 22:41:47-mst Date: Thu, 26 Jan 84 21:18 PST From: DENNIS GRIESSER at HIS-LA-CP6.ARPA To: INFO-KERMIT at COLUMBIA-20 In reply to Mike Iglesias (01/18/84), some folks around here would like to bring up KERMIT on Honeywell CP-6, but have little time to devote to the effort. We would like to start from a generic FORTRAN version. Has anybody else shown interest? Dennis Griesser Honeywell Los Angeles Development Center 27-Jan-84 21:07:14-EST,1621;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:07:10 EST Date: Fri 27 Jan 84 21:06:45-EST From: Richard Garland Subject: Apple with SSC & Videx 80 col. card To: info-kermit@CUCS20 Using Peter Trei's suggestions (in yesterday's Info-Kermit) we now have Apple Kermit working nicely with the SSC (Super Serial Card). We have no problem connecting to and doing file transfers with a VAX running VMS and Steven's VMS Kermit at 1200 baud. Mark Paczkowski here has worked out how to get the Videx 80 column card working under Kermit with the SSC. The Videx must go in slot 3. Assume the SSC is in slot 1. The following sequence gets the whole thing going: 1) Boot the Apple 2) Type "IN#1" <== this wakes up the SSC 3) Type "A3S" <== chain SSC to Videx 80 col. card 4) Type "AZ" <== turn off SSC's interception of ^A's 5) Type "PR#3" <== turn on Videx 80 col card 6) Type "BLOAD KERMIT" <== load kermit (patched as per Peter Trei) 7) Type "CALL 7855" <== Start up Kermit Then you are off and running. The 80 col card has faster screen handling and so Peter Trei's suggestion about reducing the scrolling region to 22 lines is unnecessary. The BLOAD is needed rather than the usual BRUN so that the chaining stuff you set up in the previous steps won't get reset. During the above sequence you will get various prompts from the system and from the cards. The screen will do various wierd things but in the end it will all be ok. [Now back to my Rainbow ...] Rg ------- 27-Jan-84 21:19:43-EST,631;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:19:40 EST Date: Fri 27 Jan 84 21:17:09-EST From: Frank da Cruz Subject: KERMIT for Atari Home Computers To: Info-Kermit@CUCS20 cc: Ingerman@CWRU20 Jack Palevich has released a version of KERMIT for Atari Home Computers which requires the "Action!" cartridge to run. It is available in KER:ATA*.* on host COLUMBIA-20 via anonymous FTP. Another implementation will follow that can run standalone, i.e. without any special cartridges. The files ATAKERMIT.HLP and .DOC comprise the documentation. ------- 27-Jan-84 21:31:44-EST,576;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:31:42 EST Date: Fri 27 Jan 84 21:19:40-EST From: Frank da Cruz Subject: KERMIT for Intel Development System To: Info-Kermit@CUCS20 A version of KERMIT written in PL/M for the Intel MDS system is available in KER:MDS*.* on host COLUMBIA-20 via anonymous FTP. This implementation was donated by a benefactor at Columbia who wishes to remain anonymous. It is based on the very early C-language "outline" of KERMIT; it's primitive but it works. ------- 27-Jan-84 21:44:31-EST,1668;000000000000 Return-Path: <@CUCS20:SY.FDC@CU20B> Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:44:28 EST Received: from CU20B by CUCS20 with DECnet; 27 Jan 84 21:36:20 EST Date: Fri 27 Jan 84 21:36:02-EST From: Frank da Cruz Subject: Finding versions of KERMIT To: Info-Kermit@CUCS20 For those of you who are new to the Info-Kermit mailing list, a brief reminder about how to find out about an implementation of Kermit for whatever system you're interested in... All the files are in the directory PS:, which you can also refer to as "KER:" (this is logical device name). You can get at the KER: area from the ARPAnet using anonymous FTP to host COLUMBIA-20, from CCnet (the DECnet network of Columbia, Carnegie-Mellon, Case Western, and (soon) NYU and Stevens) using anonymous NFT (from certain hosts) from DECnet host CU20B, and from BITnet (an IBM RSCS-protocol based network comprising some 50 universities and research institutions) via a Kermit server at BITnet host CUVMA. The first place to look is the file KER:00README.TXT. The filename starts with zeros so it will appear at the top of an alphabetical directory listing. This file lists the presently available implementations of KERMIT, and the prefixes for the filenames under which it is stored. If you don't find what you're looking for in the 00README file, look in KER:VERSIONS.DOC. This is a tabular listing of all the known KERMIT efforts, complete, in progress, or still in the planning stage. You might also want to peruse the Info-Kermit mailing list archives which, for the present, are stored in the large KER:MAIL.TXT file. ------- 27-Jan-84 23:53:38-EST,656;000000000000 Return-Path: <@CUCS20:WYNN@SU-SIERRA.ARPA> Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 23:53:36 EST Received: from SU-SIERRA.ARPA by COLUMBIA-20.ARPA with TCP; Fri 27 Jan 84 23:53:17-EST Date: Fri 27 Jan 84 20:52:47-PST From: Pardner Wynn Subject: PCjr kermit To: info-kermit@COLUMBIA-20.ARPA Kermit for the IBM PC, version 1.20, does not work with the PCjr. I just tried it with the disk model, DOS 2.1, built-in serial port and Hayes Smartmodem 300. My PC-Talk.exe program (freeware) runs fine. Let me know if I can be of help trying out new versions... Pardner Wynn wynn@su-sierra.arpa ------- 30-Jan-84 09:58:14-EST,1396;000000000000 Return-Path: <@CUCS20:Brzozowski.RPMtnd@HIS-PHOENIX-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 30 Jan 84 09:58:01 EST Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 30 Jan 84 09:57:09-EST Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 30-Jan-1984 09:54:13-est Date: Mon, 30 Jan 84 07:52 MST From: Brzozowski@HIS-PHOENIX-MULTICS.ARPA Subject: Kermit user manual To: info-kermit@COLUMBIA-20.ARPA Message-ID: <840130145252.745608@HIS-PHOENIX-MULTICS.ARPA> I have been trying to get version 1.1 of the IBM-PC Kermit running on my Compaq. The VT52 emulation works well (Emacs never looked so good!). but when I tried to downline load a file using my Kermit, and a Multics Kermit, I don't even seem to recieve a filename packet. My biggest problem, (Being a beginning user to Kermit) is that I don't know wether I am using Kermit correctly, or Kermit is to blame, or I have been bitten by the non-compatibility mode of my Compaq. I have a copy of the Kermit Protocol document, and I have heard of a Kermit 'Users Manual', but have never found this beastie. My question is: does this 'Users Manual' really exist, and if it does, where can I get a copy of it? (Preferrably on system "M" in Phoenix, since I can't FTP stuff.) Thanks in advance, Gary Brz... 1-Feb-84 11:19:01-EST,882;000000000000 Return-Path: <@CUCS20:Kenny.OSNI@HIS-PHOENIX-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 1 Feb 84 11:18:55 EST Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 1 Feb 84 11:02:44-EST Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 01-Feb-1984 09:27:36-est Acknowledge-To: Kevin Kenny Date: Tue, 31 Jan 84 21:29 MST From: Kevin Kenny Subject: 8th-bit quoting and KERMIT-80 Reply-To: Kenny%PCO@CISL-SERVICE-MULTICS.ARPA To: INFO-KERMIT@COLUMBIA-20.ARPA Message-ID: <840201042936.021068@HIS-PHOENIX-MULTICS.ARPA> Has anyone else tried to get 8th-bit-quoting into CP/M Kermit? I don't want to start hacking on it if someone else already has it or is working on it; that way lies reinvention of the wheel. /k**2 (Kenny%PCO@CISL) 2-Feb-84 12:14:25-EST,1992;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 12:14:04 EST Date: Thu 2 Feb 84 12:11:10-EST From: Frank da Cruz Subject: KERMIT for RSX-11 and RSTS/E To: Info-Kermit@CUCS20 cc: ATSBDN%UOFT01@CU20B, AP2.L-Lidofsky@CU20A, KMM%CORNELLA@CU20B This is to announce a major new implementation of KERMIT for the PDP-11, from Brian Nelson at the University of Toledo in Ohio (ATSBDN@UOFT01.BITNET). The program is written in MACRO-11, and can be configured for RSX-11/M, M-Plus, or RSTS/E. Minimum system requirements: RSTS v8.0 or later, with multiple private delimiters and RMS V2 RSX11M v4.1 or later, with full duplex terminal driver and RMS V2 RSX11M+ v2.1 or later, with full duplex terminal driver and RMS V2 This version of Kermit supports server mode and full wildcarding for SEND and GET. It also supports the CONNECT command, which can be used to dial out of the RSTS or RSX system and talk to another Kermit somewhere else. In addition to supporting the basic server functions -- SEND, GET, BYE -- KERMIT-11 also provides such advanced functions as remote directory listing, file deletion, directory switching, disk space inquiry, and more. In fact, it's so advanced that many of these functions can be invoked only by another copy of itself! (But new releases of MS DOS, DEC-20, and other KERMITs are on the way.) An adaptation of the same program for RT-11 is expected within a month or so. The files are available from host COLUMBIA-20 via anonymous FTP (ARPANET) or host CU20B (CCNET) via anonymous NFT (from certain CCNET hosts) as KER:K11*.*. There are about 42 files, most of them small, including user documentation, installation instructions, command and control files for building the program, and the MACRO source itself. Congratulations and thanks to Brian for an excellent job on this long-awaited version of KERMIT. - Frank ------- 2-Feb-84 13:41:35-EST,934;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 13:41:26 EST Date: Thu 2 Feb 84 12:12:00-EST From: Frank da Cruz Subject: New release of VAX/VMS Pascal-based KERMIT To: Info-Kermit@CUCS20 A new release of the Pascal/Fortran VAX/VMS KERMIT implementation has been received from Bruce Pinn at the University of Toronto in Ontario. It can operate in either local or remote mode, but there is no server operation. This version of KERMIT is an alternative to the Bliss/Macro-32 implementation from Stevens Institute of Technology (which is more advanced) and the VAX-11 C version from somewhere inside DEC (an adaptation of an early release of UNIX Kermit). Comparisons of these three VMS KERMITs would be welcome on the Info-Kermit mailing list. This program is available in KER:VF*.* on COLUMBIA-20 (ARPANET FTP) or CU20B (CCNET NFT). - Frank ------- 2-Feb-84 14:15:25-EST,901;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 14:15:08 EST Date: Thu 2 Feb 84 12:16:28-EST From: Frank da Cruz Subject: New Release of RT-11 Pascal-Based KERMIT To: Info-Kermit@CUCS20 cc: Michael@CUCS20 A new release of the RT-11 KERMIT written in OMSI Pascal has been received from Philip Murton at the University of Toronto (...!utcstat!utcss!philip). This release is more modular, more configurable, and has many improvements over the earlier version, including a keyword-style (rather than single-character) command parser. Perhaps most important, the is now distributed with configurable "hexified" binaries so that you don't need to have OMSI Pascal on your RT-11 system to run it. The files are available from COLUMBIA-20 (ARPANET FTP) or CU20B (CCNET NFT) as KER:RT*.*. Comments welcome. - Frank ------- 2-Feb-84 14:47:29-EST,934;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 14:47:21 EST Date: Thu 2 Feb 84 12:27:11-EST From: Frank da Cruz Subject: New Release of VAX/VMS Pascal-Based KERMIT To: Info-Kermit@CUCS20 A new release of the Pascal/Fortran VAX/VMS KERMIT implementation has been received from Bruce Pinn at the University of Toronto in Ontario. It can operate in either local or remote mode, but there is no server operation. This version of KERMIT is an alternative to the Bliss/Macro-32 implementation from Stevens Institute of Technology (which is more advanced) and the VAX-11 C version from somewhere inside DEC (an adaptation of an early release of UNIX Kermit). Comparisons of these three VMS KERMITs would be welcome on the Info-Kermit mailing list. This program is available in KER:VF*.* on COLUMBIA-20 (ARPANET FTP) or CU20B (CCNET NFT). - Frank ------- 2-Feb-84 15:40:41-EST,769;000000000000 Return-Path: <@CUCS20:POLARIS@USC-ISI> Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 15:40:34 EST Received: from USC-ISI.ARPA by COLUMBIA-20.ARPA with TCP; Thu 2 Feb 84 15:38:29-EST Date: 2 Feb 1984 12:34-PST Sender: POLARIS@USC-ISI Subject: KERMIT FOR HP3000 From: POLARIS@USC-ISI To: INFO-KERMIT@COLUMBIA-20 Message-ID: <[USC-ISI] 2-Feb-84 12:34:39.POLARIS> i REMEMBER READING A MESSAGE a while back about someone at work on a KERMIT for the HP-3000. Has there been any progress on this? If a HP-300 KERMIT is somewhere available, we would appreciate info on obtaining it, otherwise, we are interested in trying to produce at least a basic KERMIT (no file SERVER). Any advice, or help would be greatly appreciated. -Mike Seyfrit, Polaris 2-Feb-84 19:58:52-EST,635;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 19:58:48 EST Date: Thu 2 Feb 84 19:55:53-EST From: Frank da Cruz Subject: Re: KERMIT FOR HP3000 To: POLARIS@USC-ISI.ARPA, INFO-KERMIT@CUCS20 In-Reply-To: Message from "POLARIS@USC-ISI" of Thu 2 Feb 84 15:34:00-EST No news since I last checked. But before you start on anything, check with Ken Poulton at HP labs, who was going to do a version for the HP-1000 and -3000 using the Software Tools. Ken is at kdp.hp-labs@Rand-Relay. After doing this, please let me know who's doing what. Thanks. - Frank ------- 2-Feb-84 20:14:17-EST,1065;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 20:14:14 EST Date: Thu 2 Feb 84 20:00:55-EST From: Frank da Cruz Subject: KERMIT for HP-150 To: Info-Kermit@CUCS20 cc: Faunt.HP-LABS@RAND-RELAY.ARPA, twc.HP-LABS@RAND-RELAY.ARPA, kdp.HP-LABS@RAND-RELAY.ARPA KERMIT for the HP-150 MS DOS micro is now available. It is based on IBM PC Kermit Version 1.3A, circa last June. It works quite well for both terminal emulation (HP2621) or file transfer. Terminal connection loses occasionally at 4800 baud, but this seems to be a feature of the firmware. The support for the HP-150 come from Frank Heartney at HP. We'll be integrating it into the new MS DOS KERMIT in the next few weeks. In the meantime, it's available as KER:HP150.* from COLUMBIA-20 (ARPANET FTP) or CU20B (CCNET NFT). The .FIX file is a nibble-encoded .EXE file, which you can download using the same procedure as for IBM PC Kermit (assuming you have Basic) -- the PCKSEND and PCKGET programs. - Frank ------- 2-Feb-84 20:26:49-EST,1004;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 20:26:43 EST Date: Thu 2 Feb 84 20:02:53-EST From: Frank da Cruz Subject: KERMIT for Data General AOS To: Info-Kermit@CUCS20 An implementation of KERMIT for Data General machines running AOS has been contributed by John Lee of RCA Labs, Princeton, New Jersey. It is written in Ratfor, and is essentially a translation of the Unix implementation -- a basic "no frills" KERMIT that runs in both remote and local mode, and can communicate with IBM mainframes as well as ordinary full-duplex ASCII systems. In glancing through the code, I also noticed hooks for running under RDOS. The files are in KER:AOS*.* available via anonymous FTP from host COLUMBIA-20 (ARPANET) or NFT from CU20B (CCNET). Thanks to Glenn Everhart of RCA GSD, who is also the DECUS RSX SIG Tape coordinator, for unearthing this version, doing the tape conversion, and sending it in. - Frank ------- 3-Feb-84 19:32:02-EST,2274;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 3 Feb 84 19:31:58 EST Date: Fri 3 Feb 84 19:30:42-EST From: Frank da Cruz Subject: [TS.WALT: Fortran/Pascal "VMS KERMIT"] To: Info-Kermit@CUCS20 Too many KERMITs for the VAX? --------------- From-the-terminal-of: "Walt Lamia (LAMIA at TOPCAT)" Subject: Fortran/Pascal "VMS KERMIT" I am, sorry to say, disappointed in the release of yet another Kermit for VMS. We have had our problems in getting the Bliss version working well, and this introduces a whole new product to worry about. Let me voice my concern and objection to the propagation of this version anywhere beyond the originating system. I have no objections to individual sites writing whatever God-awful versions in whatever languages they think are "neat" (i.e. let's all wait for some U.K. site to write a CORAL-66 version). But for general public release and support, let's all of us in the Kermit community agree on what (one!) version of the product will be the official, legal, supported, definitive version for each major system (maybe we should define those, too...I nominate TOPS-20, TOPS-10, VMS, UNIX, CP/M, MS-DOS, VM(whatever) [IBM], RSX, RT11, RSTS, and possible a "generic" Fortran (for host systems) and a "generic" Basic version(for micros) for bootstraping onto new systems. We should even consider declaring one host version and one micro version as the "definitive" version for test, verification, and certification purposes. I hope I don't sound too much like the autocratic software engineering manager, but I foresee moby problems if lots of "slightly" different versions with slightly different supported protocols are running around ("Your new release of Version X doesn't work - you didn't test it with Version Y" ... "But I did test it with Version Z, and it worked") (cf. X=Robin 3.7 Y=VMS Bliss Z=TOPS-20). Feel free to forward this message around for comment. If anyone on the networks wants to send me mail, please use the following (also CC. to EIBEN): DECnet TOPCAT::LAMIA Usenet ...decvax!decwrl!rhea!topcat!lamia ARPAnet decwrl!rhea!topcat!lamia@Shasta ------- 4-Feb-84 00:26:52-EST,958;000000000000 Return-Path: <@CUCS20:judd%umcp-cs@CSNet-Relay> Received: from CUCS20 by CU20B with DECnet; 4 Feb 84 00:26:49 EST Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Sat 4 Feb 84 00:25:35-EST Date: 3 Feb 84 22:56:41 EST (Fri) From: Judd Rogers Return-Path: Subject: Re: [TS.WALT: Fortran/Pascal "VMS KERMIT"] To: Frank da Cruz , Info-Kermit@COLUMBIA-20 Via: UMCP-CS; 3 Feb 84 23:05-EST Since the fortran/Pascal versions of Kermit work NOW lets make them the standards (or bring them up to the same functionality of the non-working Bliss version and then make them standard). After all, standard programs should work! {swat! for people who insist on writing stuff in 'neat' languages like Bliss). Better yet, formalize a functional deffinition of exactaly what any correct Kermit program will do. That will be the standard. Judd Rogers 4-Feb-84 00:58:04-EST,685;000000000000 Return-Path: <@CUCS20:MOORE.LOSANGEL.IBM-SJ@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 4 Feb 84 00:58:00 EST Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Sat 4 Feb 84 00:56:51-EST Date: 3 Feb 1984 16:07:03-PST (Friday) From: Jim moore Return-Path: Subject: KERMIT/VM/CMS To: info-kermit@columbia-20 Via: IBM-SJ; 3 Feb 84 20:49-PST Is there anyone out there on VNET who has a running KERMIT for VM/CMS? I tried to assemble it here, but the required MACLIBs seem to be hopelessly unavailable. Thanks Csnet: MOORE.LOSANGEL.IBM@RAND-RELAY VNET: MOORE at LOSANGEL 6-Feb-84 02:45:53-EST,846;000000000000 Return-Path: <@CUCS20:HFISCHER@USC-ECLB.ARPA> Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 02:45:48 EST Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 02:44:35-EST Date: 5 Feb 1984 2340-PST From: HFISCHER at USC-ECLB.ARPA Subject: Draft User's Guide to PC-DOS & MS-DOS Kermit To: cc.fdc at COLUMBIA-20, cc.DAPHNE at COLUMBIA-20 cc: info-kermit at COLUMBIA-20, HFischer at USC-ECLB Frank and Daphne, I have made up a first draft of a User's Manual for the KERMIT-86 version which includes the TAKE, SERVER, and SET CONSOLE. This is available for FTP-ing from Arpanet host USC-ECLB, file PCK20.LPT (default-style printable on dumb terminal), and in file PCK20.MSS (Scribe file for use when generating fancy printout for fancy printers). Herm Fischer ------- 6-Feb-84 11:09:30-EST,1583;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 11:09:22 EST Date: Mon 6 Feb 84 11:06:23-EST From: Frank da Cruz Subject: Re: [TS.WALT: Fortran/Pascal "VMS KERMIT"] To: judd%umcp-cs@CSNET-CIC.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Judd Rogers " of Fri 3 Feb 84 22:56:41-EST I agree with the need to write a fully-configured KERMIT in some high-level language, like C, to serve as a basis for any other implementation. We'll probably do this. In the meantime, however, freedom of choice will have to prevail. There's no one place in the world that has an example of every machine/operating system/language for which an implementation of KERMIT has been done, and can therefore validate or compare all these versions. In particular, I've never heard before that the Bliss implementation of KERMIT for the VAX was "non-working", and in fact have never had verification (except from the original contributors) that the Pascal/Fortran version DID work. Some sites say they would rather run the Pascal/Fortran version because they don't have Bliss, while others would rather run the Bliss version because they don't have Pascal -- the latter include sites that also don't have Bliss. While Bliss might not be our favorite language, I don't think it was chosen because it was "neat", but rather because it was portable among several different systems which the authors had to support -- the only such language they had at their disposal. - Frank ------- 6-Feb-84 12:02:46-EST,451;000000000000 Return-Path: <@CUCS20:beattie@bbn-unix> Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 12:02:39 EST Received: from mitre-gateway by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 12:01:03-EST Date: 6 Feb 1984 11:55:39 EST (Monday) From: brian beattie Subject: unix kermit server To: info-kermit at columbia-20 Hi, does anyone have/know of a kermit server that will run under UNIX? beattie at mitre-gateway 6-Feb-84 13:16:45-EST,809;000000000000 Return-Path: <@CUCS20:G.TJM@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 13:16:40 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 13:15:15-EST Date: Mon 6 Feb 84 10:15:23-PST From: Ted Markowitz Subject: Re: IBM PC Kermit To: cc.fdc@COLUMBIA-20.ARPA, Info-Kermit@COLUMBIA-20.ARPA, Info-IBMPC@USC-ISIB.ARPA In-Reply-To: Message from "Frank da Cruz " of Mon 23 Jan 84 16:48:23-PST I'd just like to cast a vote in favor of taking the ANSI (VT100) terminal emulation out of the 'sky' and putting it in the priority list. Much software I'm aware of uses this standard and it would make life a GREAT deal simpler for many folks. Good luck and thanks for the effort in advance! --ted ------- 6-Feb-84 13:41:12-EST,813;000000000000 Return-Path: <@CUCS20:HFISCHER@USC-ECLB.ARPA> Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 13:41:08 EST Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 13:39:42-EST Date: 6 Feb 1984 1038-PST From: HFISCHER at USC-ECLB.ARPA Subject: Minor revision made to PC KERMIT-86 User's Manual To: cc.fdc at COLUMBIA-20, cc.daphne at COLUMBIA-20 cc: info-kermit at COLUMBIA-20 Frank and Daphne, An error in the User's manual was corrected. The changes indicate that remote operation of KERMIT-86 over comm lines, using the DOS 2 CTTY command need to redirect standard output to the remote console so the informational and error messages don't fight with packets on the comm line. The files corrected are [ECLB]PCK20.LPT and .MSS . Herm Fischer ------- 6-Feb-84 14:00:41-EST,642;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 14:00:37 EST Date: Mon 6 Feb 84 13:43:51-EST From: Daphne Tzoar Subject: Re: KERMIT/VM/CMS To: MOORE.LOSANGEL.IBM@RAND-RELAY.ARPA cc: info-kermit@CUCS20 In-Reply-To: Message from "Jim moore " of Fri 3 Feb 84 19:07:03-EST Three files are required, all of them available in the Kermit directory. They are: CMSKERMIT, CMSNXTFST and CMSWILD. Copy these files to your CMS system, rename them to Kermit, Nextfst, and Wild. They should compile without any problems. /daphne ------- 6-Feb-84 22:01:56-EST,687;000000000000 Return-Path: <@CUCS20:rag@uw-june> Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 22:01:52 EST Received: from uw-june by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 22:00:35-EST Date: 6 Feb 1984 18:46:25-PST From: David Ragozin To: beattie@mitre-gateway, info-kermit@columbia-20 Subject: Reply to brean beattie Re: Unix kermit server I do not know of a unix kermit server, and would like to have such also. I have, however, adapted the unix kermit.c so that it allows multiple commands just as most other kermits do. It is a short change to the code, which seems to work on Berkeley 4.1 and 4.2. I can send it in its current state if anyone is interested. 7-Feb-84 01:44:06-EST,1314;000000000000 Return-Path: <@CUCS20:fox%vpi.vpi@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 01:44:01 EST Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Tue 7 Feb 84 01:42:48-EST Date: Mon, 6 Feb 84 14:57 EST From: Ed Fox Return-Path: Subject: Can Kermit be used to build a communications subroutine for IBM PC? Received: from rand-relay.ARPA by csnet-cic.ARPA ; 7 Feb 84 00:58:51 EST (Tue) To: info-kermit@columbia-20 Cc: fox.vpi@Rand-Relay Via: vpi; 6 Feb 84 19:31-PST Can some part or parts of Kermit be incorporated in another package? I need a relatively small subroutine available (or something using interrupts) that a DOS 2.10 C program can call to: 1)choose and logon to a machine, using direct LAN connection or autodialing 2)send ascii messages 3)receive and store ascii messages The C program must also communicate with a user via keyboard and monitor. My interest is in a reliable routine that is easy to use and won't take too much memory, and is callable by C. YTERM has been mentioned - is part of that suitable instead of part of KERMIT? Sorry for not knowing more about where to start in this project. Thanks for the help! - Ed Fox (fox.vpi@rand-relay on ARPANET or foxea@vpivm1 on bitnet) 7-Feb-84 10:10:40-EST,757;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 10:10:33 EST Date: Tue 7 Feb 84 10:08:31-EST From: Frank da Cruz Subject: Re: Can Kermit be used to build a communications subroutine for IBM PC? To: fox.vpi@RAND-RELAY.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Ed Fox " of Tue 7 Feb 84 01:42:59-EST Kermit is probably not what you want for choosing and logging in to a machine, sending and receiving ASCII messages, manipulating autodialers. These things are done well by cheap commercial communication packages, but CP/M Kermit (at least in its present state) concentrates more on terminal emulation and protocol-driven file transfer. - Frank ------- 7-Feb-84 11:14:43-EST,506;000000000000 Return-Path: <@CUCS20:OC.WBC3@CU20B> Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 11:14:31 EST Received: from CU20B by CUCS20 with DECnet; 7 Feb 84 11:06:59 EST Date: Tue 7 Feb 84 11:07:19-EST From: Bill Catchings Subject: Wang PC To: Info-Kermit@CUCS20 Has anyone adapted the IBM PC version of Kermit to support the Wang PC? It runs MS-DOS, so it is at least possible. Let me know if you have even tried, otherwise I'll have to do it myself. -Bill ------- 7-Feb-84 11:46:33-EST,567;000000000000 Return-Path: <@CUCS20:gjg@cmu-cs-cad> Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 11:46:12 EST Received: from CMU-CS-CAD by COLUMBIA-20.ARPA with TCP; Tue 7 Feb 84 11:43:50-EST Date: 7 Feb 1984 11:33:46-EST From: Greg.Glass@CMU-CS-CAD To: info-kermit@cucs20 Subject: Kermit on the SUN I recall sometime back seeing mention of someone getting kermit running on a SUN. As I am going to be moving a copy of ckermit.c(the vers. that I use on our VAX) over to one of these I would like to get in touch with anyone that has done this. Greg 7-Feb-84 16:31:55-EST,816;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 16:31:50 EST Date: Tue 7 Feb 84 16:30:25-EST From: Frank da Cruz Subject: CP/M-86 Kermit version 2.3 available To: Info-Kermit@CUCS20 This is the version that runs on the DEC Rainbow and the NEC APC. The major differences from the earlier release are: Parity is handled correctly. . IBM mode (parity, handshake, half duplex) works correctly. . System dependencies are better isolated. . Buffer clearing is done between packets to prevent "packet echoing". Source is in KER:86*.*. Hex and binary for the Rainbow are in KER:RB*.*, and for the APC in KER:APC*.*. All these files accessible at host COLUMBIA-20 via anonymous FTP (ARPANET) or NFT from CUCS20 (CCNET). - Frank ------- 7-Feb-84 21:38:22-EST,1327;000000000000 Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID> Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 21:38:18 EST Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Tue 7 Feb 84 21:40:01-EST Date: 7 Feb 1984 17:39-PST Sender: ABN.ISCAMS@USC-ISID Subject: Re: Wang PC From: ABN.ISCAMS@USC-ISID To: oc.wbc3@COLUMBIA-20 Cc: Info-Kermit@CUCS20 Message-ID: <[USC-ISID] 7-Feb-84 17:39:44.ABN.ISCAMS> In-Reply-To: The message of Tue 7 Feb 84 11:07:19-EST from Bill Catchings Bill, Hope this reaches you - your original return message choked up my mailer (HERMES). I looked at the Wang PC's references and considered porting the IBM PC KERMIT over to it - but couldn't figure out the right port addresses, and being fairly new to interrupts...... got scared/felt dumb, and gave it up. Not very much information in the standard Wang manuals, at least not for a relatively inexperienced 16-bit hacker like me. Rots of ruck - would be most interested if someone does do this thing -- we have several Wang PCs here, and would like KERMIT to get some sort of compatible protocol for talking with other systems/machines. The Wang proprietary communications software is very flexible, but won't error-trap with other systems. Regards, David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 8-Feb-84 13:16:10-EST,785;000000000000 Return-Path: <@CUCS20:OC.GARLAND@CU20B> Received: from CUCS20 by CU20B with DECnet; 8 Feb 84 13:16:04 EST Received: from CU20B by CUCS20 with DECnet; 8 Feb 84 13:16:05 EST Date: Wed 8 Feb 84 13:12:26-EST From: Richard Garland Subject: Rainbow Kermit To: Info-kermit@CUCS20 cc: OC.GARLAND@CU20B To all Rainbow Kermit developers: I expect to put a few enhancements into Rainbow Kermit this week. First will be some optional flow control (a'la VT100 Auto XON/XOFF), and next possibly will be integarting the special function keys (HELP, DO, EXIT, etc.). I am working on version 2.3 as a base. If you are or intend to do anything to Rainbow Kermit in the near furure, please hold off or let me know so we can stay consistant. Rg ------- 8-Feb-84 14:43:45-EST,648;000000000000 Return-Path: <@CUCS20:johnston@LBL-CSAM> Received: from CUCS20 by CU20B with DECnet; 8 Feb 84 14:43:41 EST Received: from lbl-csam.ARPA by COLUMBIA-20.ARPA with TCP; Wed 8 Feb 84 14:43:45-EST Return-Path: Received: by lbl-csam.ARPA ; Wed, 8 Feb 84 11:44:09 pst Date: Wed, 8 Feb 84 11:44:09 pst From: (Bill Johnston [csam]) johnston@LBL-CSAM Message-Id: <8402081944.AA12541@lbl-csam.ARPA> To: info-kermit@columbia-20 Subject: IBM/MVS Kermit? Does anyone know of an MVS/TSO version of Kermit, or how close the VM/CMS version might be (i.e. how hard would it be to convert)? Thanks, Bill Johnston johnston@lbl-csam 8-Feb-84 18:17:35-EST,1255;000000000000 Return-Path: <@CUCS20:leo@MIT-PAMELA> Received: from CUCS20 by CU20B with DECnet; 8 Feb 84 18:17:30 EST Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Wed 8 Feb 84 17:37:11-EST Date: Sunday 5 February 1984 09:46:24 EDT From: Leo Hourvitz Subject: Too many Kermits (Kermi ?) To: I'm afraid I disagree with Walt Lamia's feelings about too many kermits. Of course, it ain't up to me, it's gonna be up to Frank as to what Info-Kermit 'supports', but it seems that there can indeed be valid reasons for multiple kermits propagating around. For instance, the X version uses a feature not available here, or, we don't have the compiler for the Y version. I know that in installing software on systems I have been glad to find alternate versions of a program, since for some reason the alternate versions came up much more easily than the first version I got. I understand Walt L.'s concern with infinite numbers of implmentations floating around; certainly, we can ask why these people wrote their own implementation instead of using an existing one. But often, they had some reason for doing so... Leo Hourvitz Architecture Machine Group, MIT Arpa: leo%mit-pamela@mit-mc 8-Feb-84 19:27:34-EST,1686;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 8 Feb 84 19:27:24 EST Date: Wed 8 Feb 84 19:28:18-EST From: Frank da Cruz Subject: Re: IBM/MVS Kermit? To: "(Bill Johnston [csam]) johnston"@LBL-CSAM.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "(Bill Johnston [csam]) johnston@LBL-CSAM" of Wed 8 Feb 84 14:44:06-EST There have been many rumors of people doing KERMIT for MVS (or OS) / TSO, but to date none have panned out (somebody please correct me if I'm wrong). In any case, I'd venture to suggest that it might be more fruitful to work from one of the PL/I or Fortran implementations as a base, rather than the VM/CMS version, which is pretty much "bare bones" at this point. There's a PL/I version for Honeywell Multics available in KER:MU*.*, and another one for PRIME computers is on a tape that's on its way to me in the mail. A Fortran version for the Cyber 170 is in KER:170*.*. The PL/I version is probably the better choice -- it's an easier language to work with than Fortran, and turns out to be the (or a) system-programming language on quite a few systems, not just IBM, where a more modern or "acceptable" high-level language like C or Pascal is not available. If anybody wants to take a shot at this, please let me know first; I have a few ideas about how the program should be broken up into modules to isolate system dependencies, so that the resulting PL/I program could have system- dependent plug-in modules to let it run under MVS/TSO, VM/CMS, MULTICS, PRIME, etc etc, so that all these systems could share the most advanced possible protocol module. - Frank ------- 9-Feb-84 11:13:56-EST,1220;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 11:13:49 EST Date: Thu 9 Feb 84 11:15:11-EST From: Frank da Cruz Subject: Re: unix kermit server To: beattie@MITRE-GATEWAY.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "brian beattie " of Mon 6 Feb 84 11:55:39-EST We've received a UNIX Kermit server from someone in France, but we haven't had an opportunity to evaluate it yet. We've also received many other changes to Unix Kermit from many other sources, and have quite a lot of checking and merging to do. After we get a new MS DOS Kermit release out the door (which is where we're devoting all our effort just now, except for installing and announcing new Kermit contributions ever day, it seems, and shipping out about five tapes per day), we're going to concentrate on Unix Kermit, bringing it up to the level of what's described in the protocol manual, modularizing it, etc. In particular, isolating the protocol module will go a long way towards satisfying the need of having a system-independent file Kermit file service kernel that can be incorporated into any system that has C. - Frank ------- 9-Feb-84 12:49:28-EST,1650;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 12:49:22 EST Date: Thu 9 Feb 84 12:22:14-EST From: Frank da Cruz Subject: KRFC #10 (?), database service To: Info-Kermit@CUCS20 Somebody called me from the Canadian Film Board with an idea that never occurred to me before, even though it's very simple. He's got some huge database on his DEC-20, and wants to use KERMIT from a PC to get selected records from it. The protocol does provide for sending things other than files, like directory listings, etc, so why not records from databases? How about a new generic command, say "B", whose argument is a string which you pass to a database program -- the string being the search or lookup key, relational expression or whatever. The Kermit server runs the database program (the user would have to tell it which database program, and which database, in advance), for instance as an inferior process -- this is easy under systems like Unix or TOPS-20 -- and each lookup command would have the server feed the argument string to the database program, get the result (easy under Unix) and send it back in packets (the program on the user side would have the option of displaying this information on the screen or putting it in a file). This simple procedure would go a long way towards providing the "integrated micro- mainframe link" that we read about so much in the business-oriented trade publications. Anybody see any problems or pitfalls here? I have absolutely no experience with database applications, so I don't want be too glib here. - Frank ------- 9-Feb-84 13:02:37-EST,1464;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 13:02:26 EST Date: Thu 9 Feb 84 13:02:49-EST From: Frank da Cruz Subject: KRFC # 11, Kermit commands To: Info-Kermit@CUCS20 Another simple idea. When communicating with a KERMIT server, particularly a server running on the DEC-20, you often wish you could send it a command such as you would type to it if it were running interactively. For instance, you were sending text files to it, but now you want to send an 8-bit binary file. Rather than shut down the server, connect to the remote side, start Kermit up interactively, and give commands like SET FILE BYTESIZE 8 or whatever, wouldn't it be a lot easier to type the command from your local system? This requires a new packet type, say "K", with the command string in the data field. This would be similar to the G (generic command) and C (host command) packets. K will be an implementation-specific Kermit command, which the server will execute as if it had been typed at it interactively. An example of using this (from, say, an IBM PC) -- Kermit-86>send *.asm Kermit-86>remote kermit set file bytesize 8 Kermit-86>send *.exe Kermit-86>remote kermit set file bytesize 7 Kermit-86>send *.txt You could also use it to turn debugging logs on and off, or to do anything else the remote KERMIT might be capable of in interactive mode. Comments? - Frank ------- 9-Feb-84 15:34:40-EST,592;000000000000 Return-Path: <@CUCS20:Wiedemann@RADC-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 15:34:19 EST Received: from RADC-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 15:32:54-EST Date: 9 February 1984 15:31 est From: Wiedemann.4506i1808 at RADC-MULTICS Subject: KERMIT for MULTICS??? To: info-kermit at COLUMBIA-20 Is there an implementation of KERMIT for the MULTICS system available?? We can "ftp" from virtually anywhere, but transferring things down to a dial-up user cannot be presently done. Thanx for your help! Wolf Wiedemann 9-Feb-84 16:07:05-EST,2422;000000000000 Return-Path: <@CUCS20:knutson@ut-ngp.ARPA> Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 16:06:53 EST Received: from ut-ngp.ARPA by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 16:04:32-EST Date: Thu, 9 Feb 84 15:05:30 cst From: knutson@ut-ngp.ARPA Posted-Date: Thu, 9 Feb 84 15:05:30 cst Message-Id: <8402092105.AA14632@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/3.14) id AA14632; Thu, 9 Feb 84 15:05:30 cst To: Info-Kermit@Columbia-20.ARPA Subject: Re: KRFC #10 (?), database service Please, let's not forget what we are working with here! Kermit is designed for reliable data transfer. If we start adding more to the protocol so that it can be all things to all people, we may effectively deter others from using it just because the protocol is so massive. If anything, I would like to see the protocol simplified so that there are two levels of the protocol. One level is the packet transfer protocol which provides a reliable mechanism for data transfer. The next level would implement the file transfer protocol. If we want to add something for database record retrieval, let it replace the file transfer protocol. Let's keep the two seperate. This brings me to another point. When we say Kermit, what exactly are we talking about. The Kermit file transfer programs and the Kermit protocol are seperate issues. I see real problems with adding to the protocol and expecting microcomputers with limited address space to be able to implement it. I am not sure that even the current protocol with all the file attribute mess can be implemented on a fair amount of micros. Now let's talk about reliability and support. As an implementor of a new kermit (Cyber), I am finding it extremely difficult to even keep up with the current protocol (involving attributes and whatnot). How many other Kermit programs are there that need to be brought up to the current protocol level? I would imagine almost all of them. We need to start working more with support and reliability than changing things. We have more than enough work now to keep us all busy for a long time. If someone else wants to design and implement protocol layers above Kermit, fine, let them. It should be done that way anyhow. Make it be a seperate protocol and program from Kermit. Kermit is a good protocol. Let's not blow it. From the smoldering fingers of Jim Knutson knutson@ut-ngp 9-Feb-84 16:50:31-EST,3189;000000000000 Return-Path: <@CUCS20:OC.WBC3@CU20B> Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 16:50:25 EST Received: from CU20B by CUCS20 with DECnet; 9 Feb 84 16:47:55 EST Date: Thu 9 Feb 84 16:46:48-EST From: Bill Catchings Subject: Re: KRFC #10 (?), database service To: knutson%ut-ngp@COLUMBIA-20.ARPA, Info-Kermit%Columbia-20@COLUMBIA-20.ARPA In-Reply-To: Message from "knutson@ut-ngp.ARPA" of Thu 9 Feb 84 16:07:06-EST I am afraid I must agree with Jim Knutson, this is getting out of hand. The most important work that remains to be done with the protocol is that of defining its different levels. Every six months or so some one comes up with another great idea for what should be in the Kermit protocol. It has grown well beyond its original intention, to provide a simple, easy to implement, means of reliable file transfer. Rather than jamming more into the present protocol it is now time to step back and evaluate. KRFC #12 For the sake of argument, I'm going to call what I'm going to talk about Kermit II. If it is possible to do this within the existing structure, then so much the better. If not, maybe we should look ahead. Kermit II would just provide reliable task to task communication. This is now usually refered to as packetizing. At this level some initial negotiation is done that concerns packetizing, such as padding, quoting etc. This is presently done in the Send Init packet. If a Kermit is restarted or does not hear from its counter part for a given amount of time then this is renegotiated. It may also be necessary to renegotiate on the fly. The higher level is that of the individual application. The first one to be specified would be file transfer. Another might be remote commands (presently server remote commands). Frank's database could be yet another. An individual program could implement whatever it felt necessary. The "normal" one would be file transfer and remote commands (basically today's Kermit). A minimal one might just implement file transfer. On systems like Tops-20 or Unix the remote server Kermit might just be a packetizer that would fork up the appropriate application and feed it an unpacketized stream of data. The application would then have its own "packetizing" and higher level protocol as well. This is just a rough outline, I have thought through "Kermit II" quite a bit more thoroughly over the last year since I started to muddy the waters with the "Kermit Server". The real question is, do people really want to do this kind of thing, or is file transfer all they care about. Before you jump too fast look at PCnet. It started out sort of as Kermit II, it was more than people wanted. If so, lets do it right and then see if when can get the existing Kermit to fit within that frame work without too much trouble. If people really want a more generalize micro to mainframe communications solution, lets aggressively go at it. If not, then lets keep the present Kermit practical and not try to make it all things to all people. This is definately a "Kermit Request for Comments". -Bill Catchings ------- 9-Feb-84 18:21:47-EST,459;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 18:21:41 EST Date: Thu 9 Feb 84 18:19:57-EST From: Frank da Cruz Subject: Re: KERMIT for MULTICS??? To: Wiedemann.4506i1808@RADC-MULTICS.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Wiedemann.4506i1808 at RADC-MULTICS" of Thu 9 Feb 84 15:31:00-EST A Multics Kermit is available in KER:MU*.* on COLUMBIA-20 via anonymous FTP. ------- 9-Feb-84 18:34:19-EST,864;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 18:34:15 EST Date: Thu 9 Feb 84 18:25:55-EST From: Frank da Cruz Subject: Re: KRFC #10 (?), database service To: Info-Kermit@CUCS20 In-Reply-To: Message from "knutson@ut-ngp.ARPA" of Thu 9 Feb 84 16:04:52-EST I agree, mostly. But don't forget -- whenever anything new is added to "the protocol", nobody is forced to add it to any particular implementation. The most advanced implementation in the world can still be used by the most primitive and/or oldest. The directory listing & similar stuff has been in the protocol manual for over a year; this database stuff is a very simple adaptation of the same idea. As far as Kermit is concerned, there's nothing about it that's any different from any other kind of file transfer. ------- 9-Feb-84 19:30:41-EST,1275;000000000000 Return-Path: <@CUCS20:decwrl!rhea!atfab!wyman@Shasta> Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 19:30:36 EST Received: from Shasta by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 19:30:25-EST Received: from decwrl by Shasta with UUCP; Thu, 9 Feb 84 16:27 PST Date: Thursday, 9 Feb 1984 16:15:06-PST From: decwrl!rhea!atfab!wyman@Shasta Subject: KRFC #10 (?), database service Message-Id: <8402100020.AA16068@DECWRL> Received: from RHEA.ARPA by DECWRL (3.327/4.09) 9 Feb 84 16:20:03 PST (Thu) To: info-kermit@columbia-20.arpa I would like to second the concerns expressed by knutson@ut-ngp and reopen my past suggestion that a KERPAC (KERMIT Packet) specification be established which is independent of the KERMIT file transfer protocol. There are all sorts of things which need to be implemented in a total workstation protocol set. We can't clowd the KERMIT spec with everything, nor can we accept the requirement that every addition be cleared through Columbia-20... By locking the "new toys" into the KRFC approval process, we will be essentially limiting the opportunites for creativity. Better that we divide the spec into KERPAC and KERMIT file transfer, then focus on making sure the "capabilities negotiation" works well. bob wyman 9-Feb-84 19:44:48-EST,623;000000000000 Return-Path: <@CUCS20:leo@MIT-PAMELA> Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 19:44:44 EST Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 19:32:51-EST Date: Thursday 9 February 1984 14:50:44 EDT From: Leo Hourvitz Subject: Kermit on the SUN To: , Greg- I got uxkermit (Unix Kermit) running on the Suns we have here in as much time as it took to compile. (Finding another kermit machine immediately handy took a few minutes more)... Leo Hourvitz Architecture Machine Group leo%pamela@mit-mc 9-Feb-84 19:55:19-EST,2236;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 19:55:14 EST Date: Thu 9 Feb 84 19:34:34-EST From: Frank da Cruz Subject: Fancy stuff To: Info-Kermit@CUCS20 Ahh, it's been a while since this discussion group has had a real discussion. I too have the feeling that the Kermit protocol may be getting out of control, but the two recent suggestions, I think, are quite minor optional features that don't bend the protocol very much out of shape at all. Two features that do, however, are file attributes and alternate block check types. The alternate block check types were added after I attempted an analysis of the probability of transmission errors going undetected using the default 6-bit checksum. No matter how you figure it (e.g. it's simply 1/2^6, or by counting the number of errors that could cancel each other out against the total number of possible errors, of 1 bit, 2 bits, 3 bits...), it always seemed to come out the same. 1/64 is pretty poor odds; I panicked and wrote the alternate block checks into the protocol. These turn out to add an awful lot of hair and complication, especially when used in conjunction with server operation. What really throws me, though, is that I have NEVER heard of an error slipping through when using the single character checksum. How can that be? Any mathematicians or epistimologists out there? The file attributes business, which so many people object to, arise -- sad to say -- out of necessity when dealing with file systems like FILES-11 (RMS) or IBM mainframe systems like CMS, OS, MVS, etc, where a file is meaningless without its attributes. In such systems, it is often the case that the absolute basic, simplest goal of KERMIT, i.e. file transfer, turns out to be impossible without passing attributes back and forth. Those of you on wonderful systems like Unix where a file is a linear sequence of 8-bit bytes just can't begin to "appreciate" the hair that has to be raveled and unraveled to get, say, a CMS binary file to a PC and back. But why, you say, would anyone ever want to do such a thing? Well, suffice it to say that they do. Sigh... - Frank ------- 9-Feb-84 20:08:51-EST,522;000000000000 Return-Path: <@CUCS20:WANUGA@MIT-XX.ARPA> Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 20:08:48 EST Received: from MIT-XX.ARPA by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 19:56:11-EST Date: Thu 9 Feb 84 19:39:44-EST From: Thomas S. Wanuga Subject: Kaypro, VENIX To: info-kermit@COLUMBIA-20.ARPA cc: randy@MIT-XX.ARPA I am looking for versions of KERMIT that run on the IBMPC running the VENIX operating system, and the Kaypro. Do such things exist? Thanks. Tom Wanuga ------- 9-Feb-84 21:00:30-EST,656;000000000000 Return-Path: <@CUCS20:judd%umcp-cs@CSNet-Relay> Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 21:00:27 EST Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 21:00:21-EST Date: 8 Feb 84 14:24:55 EST (Wed) From: Judd Rogers Return-Path: Subject: Re: Reply to brean beattie Re: Unix kermit server To: David Ragozin , info-kermit@columbia-20, beattie@mitre-gateway Message-Id: <445116237.503.1@umcp-cs> Via: UMCP-CS; 9 Feb 84 20:12-EST Yes, I would like to see the Kermit server. You might send it to net.sources. Judd Rogers 10-Feb-84 00:28:44-EST,1434;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 00:28:40 EST Date: Fri 10 Feb 84 00:28:52-EST From: Ken Rossman Subject: Re: KRFC #10 (?), database service To: Info-Kermit@CUCS20 In-Reply-To: Message from "Frank da Cruz " of Thu 9 Feb 84 18:26:26-EST Address: 716 Watson Labs, 612 W.115th St, NY, NY 10025 Phone: (212) 280-3703 I agree with Frank that Kermit currently is, and can always continue to be a protocol that can be added to. The basic functions will always still be there, and won't change, so even the most simple-minded Kermit will be able to do it's basic job with the most advanced multi-processing, database- reading, super-automatic, sock-washing, house-cleaning Kermits. I'd like to throw in my two cents on the database program idea, though. I think that same idea could be extended into a more general case (for TOPS-20 in any case) where the local Kermit could instruct the remote (TOPS-20) Kermit to run just about any program and hand it some command string as a rescan argument. Why limit yourself only to databases? Why not be able to run Finger too, for example? OK, so that's getting pretty far off base, and is perhaps a poor example, but I just figure as long as something like database manager fork code might be added, it's not so hard to generalize it a little more. /Ken ------- 10-Feb-84 02:51:53-EST,645;000000000000 Return-Path: <@CUCS20:LIN@MIT-MC> Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 02:51:50 EST Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Fri 10 Feb 84 02:52:05-EST Date: 10 February 1984 02:51 EST From: Herb Lin To: LIN @ MIT-MC, info-kermit @ COLUMBIA-20 dear people I have the DOC files on generic Kermit for CP/M and Kermit for TOPS-20. I have been unable to learn just how I can use the kermit-cpm/kermit-20 combination to transfer files from a 20 to my cp/m machine. I feel really stupid, but can you supply a pointer to where in the documentaiton this information lives? many thanks. 10-Feb-84 09:59:16-EST,533;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 09:58:54 EST Date: Fri 10 Feb 84 09:58:14-EST From: Frank da Cruz Subject: Re: Kaypro, VENIX To: WANUGA@MIT-XX.ARPA cc: Info-Kermit@CUCS20 In-Reply-To: Message from "Thomas S. Wanuga " of Thu 9 Feb 84 19:56:22-EST Kermit for the Kaypro is in KER:CPMKAYPRO.* on COLUBMIA-20 (anonymous FTP). KER:KERMIT.C is the Unix version, hopefully easily adaptable to the PC with Venix. - Frank ------- 10-Feb-84 10:15:45-EST,973;000000000000 Return-Path: <@CUCS20:Spitzer.Multics@HIS-PHOENIX-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 10:15:38 EST Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 10 Feb 84 10:00:49-EST Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 10-Feb-1984 09:57:09-est Sender: Charlie Spitzer Date: Fri, 10 Feb 84 07:45 MST From: Charlie Spitzer Subject: Re: KERMIT for MULTICS??? (INFO-KERMIT [0262]) To: Wiedemann.4506i1808@RADC-MULTICS.ARPA cc: INFO-KERMIT@COLUMBIA-20.ARPA Message-ID: <840210144539.762426@HIS-PHOENIX-MULTICS.ARPA> Yes, there is a Multics implementation, however it is not very good and certainly not complete. You can get a version that at least works from Klensin @ MIT-Multics for the source and a brief description of how to use the features that do work. charlie (Spitzer%pco @ CISL) 10-Feb-84 10:28:41-EST,982;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 10:28:35 EST Date: Fri 10 Feb 84 10:01:20-EST From: Frank da Cruz Subject: Re: Reply to brean beattie Re: Unix kermit server To: judd%umcp-cs@CSNET-CIC.ARPA, rag@UW-JUNE.ARPA, info-kermit@CUCS20, beattie@MITRE-GATEWAY.ARPA In-Reply-To: Message from "Judd Rogers " of Wed 8 Feb 84 14:24:55-EST The Unix Kermit server is in KER:X*.* on COLUMBIA-20. We haven't really looked at it yet, and the person who did this made a lot of assumptions about how things should work that are not necessarily valid, but you're welcome to try it out & report your findings. Like I said in an earlier message, our next project at Columbia, after getting a new release of MS DOS Kermit out, will be to rework Unix Kermit according to the same modularized scheme, and bring it up to the level described in the protocol manual. - Frank ------- 10-Feb-84 10:47:29-EST,3775;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 10:47:20 EST Date: Fri 10 Feb 84 10:47:08-EST From: Frank da Cruz Subject: Re: KRFC #10 (?), database service To: cc.Ken@CUCS20, Info-Kermit@CUCS20 cc: cc.fdc@CUCS20 In-Reply-To: Message from "Ken Rossman " of Fri 10 Feb 84 00:29:02-EST I agree with Ken. Rather than scare people off with the word "database", let's just say there can be a command to tell the Kermit server to start up a program, and another to give the program a command. Something like this: GP~programName~optionalCommandLineArgument This would let you run Finger, or any Unix-like program and get the results back in packets, which you could display on the screen, store on the disk, print on the printer, etc. If the program is interactive, then the result that you get back would probably be the program's herald, if any, and its first prompt. To run an interactive program, the kind that keeps prompting for commands, another Kermit packet would let you send a command to the current loaded program (and get the results back, including the next program prompt): GJ~command (the "~" is a length field.) Not only would implementation of such a facility be optional, it would be IMPOSSIBLE on many - if not most - systems. Just to clarify, when a new feature is added to KERMIT: (a) It doesn't change the basic packet protocol, the format of the packets, the rules for connecting and disconnecting, the sequence of events and so forth. KERMIT is basically a file transfer protocol, and all the other stuff that it can do -- directory listings, file deletion, directory changing, running programs, etc -- use the file transfer mechanism to send their commands and results back and forth. Suggestions like the one above only add a new command withing the existing framework, The new feature is OPTIONAL, and if implemented, uses the very same code for communication that is already there. (b) If you add the ability to send a new command, and you send this command to a server that doesn't know about it, the server will say "Sorry, I don't know that command". (b) If you add the ability to execute a new command to server, and the user program doesn't know about it, no harm is done. Anybody who likes a new idea can implement it if their system gives them the tools to do so conveniently. You'd have a tough time implementing this program-running idea on TOPS-10 or CP/M, and it would be (dare I say) "trivial" under Unix, and it would be possible but difficult on TOPS-20 or VM/CMS. But nobody has to do it if they don't want to. And if they like the idea, but see some better way to do it, now's the time to say so. The reason that these new ideas keep cropping up is that an unstated goal of the KERMIT project is to provide a model (though not necessarily an actual facility) that will allow users sitting at workstations the greatest possible access to the facilities of a central system without actually logging in, with the ultimate goal of getting more users simultaneously "hooked" to the central system -- with its shared files, etc -- than could possibly be accommodated by direct login. Of course, networks will eventually solve this problem, but (a) they're not here yet, at least not with the capacity and affordability required for very large sites with limited budgets, and (b) there will always need to be connections that are made from outside the network. Well, enough pie in the sky. The important thing is to kick these issues around and work out the problems in prose rather than in code. - Frank ------- 10-Feb-84 14:05:48-EST,497;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 14:05:44 EST Date: Fri 10 Feb 84 14:05:40-EST From: Frank da Cruz Subject: Kermit for PR1ME in PL/I available To: Info-Kermit@CUCS20 Contributed by Leslie Spira, The SOURCE Telecomputing (McLean, VA), written in a variant of PL/I which is PR1ME's implementation language. The files are in KER:PRIMEK.* at COLUMBIA-20, via anonymous FTP (or CU20B via NFT). - Frank ------- 10-Feb-84 17:52:40-EST,1058;000000000000 Return-Path: <@CUCS20:kdp.HP-Labs@Rand-Relay> Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 17:52:35 EST Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Fri 10 Feb 84 17:51:36-EST Date: Fri, 10 Feb 84 13:20:34 pst From: Ken Poulton Return-Path: Subject: Re: Fancy stuff Received: by HP-VENUS id AA00955; Fri, 10 Feb 84 13:20:34 pst Message-Id: <8402102120.AA00955@HP-VENUS> To: Info-Kermit@COLUMBIA-20, cc.fdc@COLUMBIA-20 Source-Info: From (or Sender) name not authenticated. Via: HP-Labs; 10 Feb 84 14:32-PST On the adequacy of a 6 bit checksum: With a 6 bit checksum, if we have two errors in the packet, the probablity of not detecting that is indeed 1/64. However, if there is a uncorrected errors per packet rate of x, the probability of getting two errors in one packet is only x^2. x is usually a small number (like 1/1000 to 1/1000000). Thus the net probablility of an undetected double error is x*x*1/64. This is small! Don't worry about it. 11-Feb-84 13:11:18-EST,1677;000000000000 Return-Path: <@CUCS20:HFISCHER@USC-ECLB.ARPA> Received: from CUCS20 by CU20B with DECnet; 11 Feb 84 13:11:11 EST Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; Sat 11 Feb 84 13:11:42-EST Date: 11 Feb 1984 1007-PST From: HFISCHER at USC-ECLB.ARPA Subject: Kermit 86 Take Files for use with Unix EMACS To: info-kermit at COLUMBIA-20 Marco Papa has contributed a set of files which allow Kermit-86 to fully use the functionality of Unix EMACS from the PC Keyboard. I have recommended to Columbia that they incorporate these files as an additional appendix for the Kermit-86 User's Manual (or whatever those folks eventually incorporate it into). Meanwhile, so you Unix EMACS users can benefit from this contribution, I have placed these files in my directory for netland FTPing. On net node ECLB, file PCUXEMCS.ALL can be split into three files, one for use on the Unix system, and two for use on the PC. On the Unix system, pc-h19-key.ml provides for Unix EMACS macro-key assignment for use with the built-in Kermit-86 Heath-19 emulator (or a real Heath-19). On the PC, a batch file, pcuxemcs.bat, is used to load kermit and "take" console keyboard setup commands from the PC-resident TAKE file, pcuxemcs.ker. The procedure "undoes" the keyboard setup after the user exits from kermit. Comments in the file explains the operation. (If you have an old version of Kermit-86 with the take and server additions, which gives an error message on the comment lines in take files, contact me if you want a three line fix; or alternatively the current version is in my directory under PCK20.NEW.) Herm Fischer ------- 12-Feb-84 11:17:42-EST,1340;000000000000 Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID> Received: from CUCS20 by CU20B with DECnet; 12 Feb 84 11:17:38 EST Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Sun 12 Feb 84 11:18:15-EST Date: 12 Feb 1984 08:06-PST Sender: ABN.ISCAMS@USC-ISID From: ABN.ISCAMS@USC-ISID To: LIN@MIT-MC Cc: info-kermit@COLUMBIA-20 Message-ID: <[USC-ISID]12-Feb-84 08:06:35.ABN.ISCAMS> In-Reply-To: The message of 10 February 1984 02:51 EST from Herb Lin Herb, Most of our hosts have KERMIT.DOC in their directories, or you can FTP it down (kind of big, though). As I remember, COLUMBIA-20 now has (in CP/M and other users manuals, to include the TOPS-20/DEC manual. The manual was all right, I guess, but KERMIT grows and changes faster than the manual documents! If you're just trying to get the rascal running, I think I can help you. If you're trying to get the code implemented for your own system...well, I can maybe help you there if your CP/M system is one of those documented in CPMGENERI KERMIT. Did a lot of hacking getting it up on my Decision I, and studied the other system IF-END's thoroughly in the process. What stage are you in, and can you please describe your problems (code OR running it!). Regards, David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 13-Feb-84 13:01:33-EST,648;000000000000 Return-Path: <@CUCS20:G.TJM@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 13:01:25 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Mon 13 Feb 84 13:01:45-EST Date: Mon 13 Feb 84 10:00:13-PST From: Ted Markowitz Subject: Re: KRFC # 11, Kermit commands To: Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Frank da Cruz " of Thu 9 Feb 84 12:18:41-PST Any thoughts been given to augmenting the VM/CMS version of Kermit to act as a server also? I don't think there's been an update of this version to include that functionality. --ted ------- 13-Feb-84 15:15:40-EST,530;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 15:15:31 EST Date: Mon 13 Feb 84 15:15:13-EST From: Daphne Tzoar Subject: Re: KRFC # 11, Kermit commands To: G.TJM@SU-SCORE.ARPA cc: info-kermit@CUCS20 In-Reply-To: Message from "Ted Markowitz " of Mon 13 Feb 84 13:02:00-EST There are plans for Kermit CMS to act as a server and to allow the transfer of binary files. It's merely a question of finding the time. /daphne ------- 13-Feb-84 17:01:33-EST,465;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 17:01:13 EST Date: Mon 13 Feb 84 17:00:29-EST From: Frank da Cruz Subject: Re: KRFC # 11, Kermit commands To: G.TJM@SU-SCORE.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Ted Markowitz " of Mon 13 Feb 84 13:02:00-EST An upgrade of VM/CMS Kermit is pretty high on our list, right after the MS DOS Kermit work. ------- 13-Feb-84 20:45:42-EST,1629;000000000000 Return-Path: <@CUCS20:Kenny.OSNI@HIS-PHOENIX-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 20:45:37 EST Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 13 Feb 84 20:46:16-EST Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 13-Feb-1984 20:45:38-est Date: Mon, 13 Feb 84 18:43 MST From: Kevin Kenny Subject: Re: Fancy stuff Reply-To: Kenny%PCO@CISL-SERVICE-MULTICS.ARPA To: INFO-KERMIT@COLUMBIA-20.ARPA Message-ID: <840214014315.812198@HIS-PHOENIX-MULTICS.ARPA> Ken Poulton's analysis is not really complete. For one thing, on a 1200 baud link running with the 212A protocol, there's really no such thing as a single-bit error, since the data go through a scrambler. If the comm line drops one bit, the unscrambled data will contain three erroneous bits. As it turns out, though, the 6-bit checksum will detect all of these. More severe is the possibility of "burst" errors, where the line will give a whole burst of 0's or 1's instead of whatever it's supposed to be sending. Asynchronous lines in this state will only foul up at most two characters in this case, though, before they encounter either a framing error or what looks like an idle line. The unscrambler may make it as wide as three or four bytes. In these cases, though, the result is generally severe enough to cause a framing error (do many Kermits check?) and kill the packet that way. In other words, the checksum is probably PERFECTLY adequate on an async line. Synchronous communication needs more. /k**2 13-Feb-84 22:20:01-EST,666;000000000000 Return-Path: <@CUCS20:ALBERS@MIT-ML> Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 22:19:58 EST Received: from MIT-ML by COLUMBIA-20.ARPA with TCP; Mon 13 Feb 84 22:20:31-EST Date: 13 February 1984 22:18 EST From: Jon P. Albers To: info-kermit @ COLUMBIA-20 I am thinking about adapting the version of KERMIT for the OSBORNE 1 to be used for the OCC-Executive 1. The CPM3 version of KEMIT works on the Exec, but a lot of the major features, especially the vt52 emulation, are cut off. I need some help from (Bruce Tanner), and anyone else familiar with KERMIT, in general, or the OCC-1 or CPM 3. Jon Albers 14-Feb-84 04:44:50-EST,1108;000000000000 Return-Path: <@CUCS20:Per_Lindberg_QZ%qzcom@Ucl-Cs.ARPA> Received: from CUCS20 by CU20B with DECnet; 14 Feb 84 04:44:46 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Tue 14 Feb 84 04:45:16-EST Via: ykxa.ac.uk; to 44d.Ucl-Cs.AC.UK over Sercnet with NIFTP; 14 Feb 84 9:38 GMT Via: QZCOM; Date: Monday, 13-Feb-84 20:42:34-GMT Date: 13 Feb 84 13:29 +0100 From: Per_Lindberg_QZ%qzcom@ucl-cs.arpa Reply-to: Per_Lindberg_QZ%qzcom@ucl-cs.arpa, KERMIT_implementation_and_experience%qzcom@ucl-cs.arpa To: KERMIT_implementation_and_experience%qzcom@ucl-cs.arpa, info-kermit Subject: Let's spread the good news! Message-ID: <41569@QZCOM> It seems to me that there is a lot of people with personal computers Out There who has never heard of KERMIT, and probably would be very happy to. And I think KERMIT deserves more publicity. So, who writes an article in BYTE? - Per Lindberg, QZ - (Text 41569)------------------------------ 15-Feb-84 13:47:55-EST,645;000000000000 Return-Path: <@CUCS20:CCIMS.WILSON@CUTC20> Received: from CUCS20 by CU20B with DECnet; 15 Feb 84 13:47:46 EST Received: from CUTC20 by CUCS20 with DECnet; 15 Feb 84 13:45:34 EST Date: Wed 15 Feb 84 05:49:08-EST From: Francis Wilson Subject: Re: KRFC #10 (?), database service To: knutson%ut-ngp@CUCS20 cc: Info-Kermit%Columbia-20@CUCS20 In-Reply-To: Message from "knutson@ut-ngp.ARPA" of Thu 9 Feb 84 16:08:39-EST I'm still trying to get Kermit (CP/M version 3.6) to work on an Apple II+, with an ALS CPM Plus card, and a Videx PSIO, so I'm all for support, robustness, reliability, etc. Francis ------- 15-Feb-84 17:24:06-EST,957;000000000000 Return-Path: <@CUCS20:POLARIS@USC-ISI> Received: from CUCS20 by CU20B with DECnet; 15 Feb 84 17:24:00 EST Received: from USC-ISI.ARPA by COLUMBIA-20.ARPA with TCP; Wed 15 Feb 84 15:30:50-EST Date: 15 Feb 1984 12:28-PST Sender: POLARIS@USC-ISI Subject: IBM-PC KERMIT[86] From: POLARIS@USC-ISI To: info-kermit@COLUMBIA-20 Cc: frank da cruz@COLUMBIA-20 Message-ID: <[USC-ISI]15-Feb-84 12:28:31.POLARIS> Do I have the most recent version of KERMIT for the IBM-PC? I have downloaded your 1.20, but have trouble using it under DOS 2.0. I have probably missed a fix or a NET NOTE about it, but the version I have for CP/M works, and this one cannot seem to pass the INIT packet properly. An additional question, If one uses a console redirection scheme (ie, BYE.com) should there be any dificulty in using Kermit remotely, micro to micro?, or does the local Kermit have to be in the receive mode before the issuing f the send? Thanks-- 16-Feb-84 11:20:44-EST,894;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 16 Feb 84 11:20:27 EST Date: Thu 16 Feb 84 11:19:06-EST From: Frank da Cruz Subject: KERMIT for Tandy 2000 To: Info-Kermit@CUCS20 This is an adaptation of IBM PC Kermit V1.20 (the current version) submitted by Stephen Padgett at the University of Texas. This support will eventually be merged into the new MS DOS KERMIT, but for now it's available in KER:TA2000.* on COLUMBIA-20 via anonymous FTP (ARPANET) or CU20B via NFT (DECNET). The .ASM file is the assembler source, the .FIX file is the hexified .EXE file, which you can download following the same procedure as for the IBM PC, described in KER:PCBOOT.HLP (note that all the files referred to in that document have the prefix "PC" in the KERMIT distribution area, e.g. KGET.BAS is found as PCKGET). - Frank ------- 16-Feb-84 13:24:52-EST,2388;000000000000 Return-Path: <@CUCS20:pourne@Mit-Mc.ARPA> Received: from CUCS20 by CU20B with DECnet; 16 Feb 84 13:24:42 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Thu 16 Feb 84 13:20:25-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 16 Feb 84 18:16 GMT Via: UCL-CS; Date: Wednesday, 15-Feb-84 16:28:40-GMT Received: from Usc-Isid by 44d.Ucl-Cs.AC.UK via Satnet with SMTP; 15 Feb 84 13:17 GMT Received: FROM MIT-MC BY USC-ISID.ARPA WITH TCP ; 15 Feb 84 01:04:49 PST Date: 15 February 1984 04:06 EST From: "Jerry E. Pournelle" Subject: Let's spread the good news! To: Per_Lindberg_QZ , KERMIT_implementation_and_experience cc: info-kermit In-reply-to: Msg of 13 Feb 84 13:29 +0100 from Per_Lindberg_QZ%qzcom at ucl-cs.arpa Sender: POURNE what's that supposed to mean? I do not know anything about KERMIT either. How should I? There have been drearily long expositions on the net at 300 baud; I have yet to see anything in print or in my mail. If Kermit is available for any machine I know of, I'd like to see it run. can it work on a Compupro? Z-80 or Dual Processor? Ot what does it take to make it run? Is there a way I can get a copy mailed to J E Pournelle BYTe POB 372 Hancock NH 03449 Or at least some description of what it is? Date: 13 Feb 84 13:29 +0100 From: Per_Lindberg_QZ%qzcom at ucl-cs.arpa Reply-To: Per_Lindberg_QZ%qzcom at ucl-cs.arpa, KERMIT_implementation_and_experience%qzcom at ucl-cs.arpa To: KERMIT_implementation_and_experience%qzcom at ucl-cs.arpa, info-kermit Re: Let's spread the good news! Remailed-From: Billy Remailed-To: pourne@MIT-MC It seems to me that there is a lot of people with personal computers Out There who has never heard of KERMIT, and probably would be very happy to. And I think KERMIT deserves more publicity. So, who writes an article in BYTE? - Per Lindberg, QZ - (Text 41569)------------------------------ 16-Feb-84 13:50:11-EST,534;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 16 Feb 84 13:50:04 EST Date: Thu 16 Feb 84 13:47:56-EST From: Frank da Cruz Subject: Info-Kermit mail archives To: Info-Kermit@CUCS20 I've broken the mail archive file into two pieces, MAIL.83A (the mail from 1983), and MAIL.TXT (the current, active mail file). From now on, old mail will periodically be retired to MAIL.yyx, like MAIL.84A, MAIL.84B, etc., and MAIL.TXT will remain the active mail file. - Frank ------- 16-Feb-84 21:17:24-EST,586;000000000000 Return-Path: <@CUCS20:judd%umcp-cs@CSNet-Relay> Received: from CUCS20 by CU20B with DECnet; 16 Feb 84 21:17:18 EST Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Thu 16 Feb 84 21:16:26-EST Date: 16 Feb 84 13:50:18 EST (Thu) From: Judd Rogers Return-Path: Subject: Take me off Kermit mail list. Someone else gets it and one is enough. To: Frank da Cruz , Info-Kermit@COLUMBIA-20, G.TJM@SU-SCORE Message-Id: <445804954.19853.3@umcp-cs> Via: UMCP-CS; 16 Feb 84 19:54-EST 17-Feb-84 08:22:19-EST,546;000000000000 Return-Path: <@CUCS20:KEN@JPL-VLSI> Received: from CUCS20 by CU20B with DECnet; 17 Feb 84 08:22:16 EST Received: from JPL-VLSI.ARPA ([10.3.0.54]) by COLUMBIA-20.ARPA with TCP; Fri 17 Feb 84 08:21:51-EST Date: 17 Feb 1984 0507 PST From: Ken Adelman Subject: Please add To: info-kermit@columbia-20 Reply-To: KEN@JPL-VLSI Me (KEN@JPL-VLSI) to the info-kermit list. I am currently trying to use kermit on an apple2 and under VAX/VMS. Thanx, Kenneth Adelman Califonia Institute of Technology ------ 17-Feb-84 10:31:11-EST,729;000000000000 Return-Path: <@CUCS20:TSAI@RU-BLUE.ARPA> Received: from CUCS20 by CU20B with DECnet; 17 Feb 84 10:31:03 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 17 Feb 84 10:30:12-EST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 17 Feb 84 10:30:42 EST Date: 17 Feb 84 10:28:54 EST From: Chris Subject: TAKE & Server for PC DOS Kermit To: kermit@RUTGERS.ARPA Hello, I remember reading a message about a proposal to add a TAKE command and server capability to the PC DOS Kermit. Have such modifications been made? If so, how can I obtain a copy of it.. I do not have arpanet privileges, so I will not be able to ftp it myself.. Chris Tsai ------- 20-Feb-84 16:40:53-EST,1055;000000000000 Return-Path: <@CUCS20:Per_Lindberg_QZ@Qzcom.SWEDEN> Received: from CUCS20 by CU20B with DECnet; 20 Feb 84 16:40:35 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Mon 20 Feb 84 16:37:45-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 20 Feb 84 21:31 GMT Via: QZCOM; Date: Monday, 20-Feb-84 20:36:39-GMT Date: 20 Feb 84 17:00 +0100 From: Per_Lindberg_QZ%qzcom@ucl-cs.arpa Reply-to: Per_Lindberg_QZ%qzcom@ucl-cs.arpa, Per_Lindberg_QZ%qzcom@ucl-cs.arpa To: Info-Kermit , Per_Lindberg_QZ%qzcom@ucl-cs.arpa Subject: KERMIT-800 Message-ID: <42674@QZCOM> The printout of 00README.TXT included with the distribution tape (dated 2 February 1984) says that the Luxor ABC-800 has a CP/M-80 like OS. Correction: it has its own OS called ABCDOS, which has no similarities with CP/M. The PROMmed BASIC that KERMIT-800 is written in, is similar to DEC BASIC-PLUS-2. - Per Lindberg QZ - 20-Feb-84 16:55:41-EST,939;000000000000 Return-Path: <@CUCS20:Michael_Walsh__Univ._College_Dublin@Qzcom.SWEDEN> Received: from CUCS20 by CU20B with DECnet; 20 Feb 84 16:55:31 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Mon 20 Feb 84 16:38:08-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 20 Feb 84 21:33 GMT Via: QZCOM; Date: Monday, 20-Feb-84 20:37:30-GMT Date: 20 Feb 84 18:32 +0100 From: Michael_Walsh__Univ._College_Dublin%qzcom@ucl-cs.arpa Reply-to: Michael_Walsh__Univ._College_Dublin%qzcom@ucl-cs.arpa, KERMIT_implementation_and_experience%qzcom@ucl-cs.arpa To: KERMIT_implementation_and_experience%qzcom@ucl-cs.arpa, Info-Kermit Subject: Kermit for VM/CMS via YALE/IUP (Series/1) Message-ID: <42703@QZCOM> Does anyone know of KERMIT development for the above configuration? 21-Feb-84 10:43:33-EST,1055;000000000000 Return-Path: <@CUCS20:Per_Lindberg_QZ@Qzcom.SWEDEN> Received: from CUCS20 by CU20B with DECnet; 21 Feb 84 10:43:16 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Tue 21 Feb 84 10:40:06-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 21 Feb 84 13:45 GMT Via: QZCOM; Date: Monday, 20-Feb-84 20:36:39-GMT Date: 20 Feb 84 17:00 +0100 From: Per_Lindberg_QZ%qzcom@ucl-cs.arpa Reply-to: Per_Lindberg_QZ%qzcom@ucl-cs.arpa, Per_Lindberg_QZ%qzcom@ucl-cs.arpa To: Info-Kermit , Per_Lindberg_QZ%qzcom@ucl-cs.arpa Subject: KERMIT-800 Message-ID: <42674@QZCOM> The printout of 00README.TXT included with the distribution tape (dated 2 February 1984) says that the Luxor ABC-800 has a CP/M-80 like OS. Correction: it has its own OS called ABCDOS, which has no similarities with CP/M. The PROMmed BASIC that KERMIT-800 is written in, is similar to DEC BASIC-PLUS-2. - Per Lindberg QZ - 21-Feb-84 10:53:30-EST,1055;000000000000 Return-Path: <@CUCS20:Per_Lindberg_QZ@Qzcom.SWEDEN> Received: from CUCS20 by CU20B with DECnet; 21 Feb 84 10:53:21 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Tue 21 Feb 84 10:40:06-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 21 Feb 84 13:45 GMT Via: QZCOM; Date: Monday, 20-Feb-84 20:36:39-GMT Date: 20 Feb 84 17:00 +0100 From: Per_Lindberg_QZ%qzcom@ucl-cs.arpa Reply-to: Per_Lindberg_QZ%qzcom@ucl-cs.arpa, Per_Lindberg_QZ%qzcom@ucl-cs.arpa To: Info-Kermit , Per_Lindberg_QZ%qzcom@ucl-cs.arpa Subject: KERMIT-800 Message-ID: <42674@QZCOM> The printout of 00README.TXT included with the distribution tape (dated 2 February 1984) says that the Luxor ABC-800 has a CP/M-80 like OS. Correction: it has its own OS called ABCDOS, which has no similarities with CP/M. The PROMmed BASIC that KERMIT-800 is written in, is similar to DEC BASIC-PLUS-2. - Per Lindberg QZ - 21-Feb-84 15:40:25-EST,1209;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 21 Feb 84 15:39:34 EST Date: Mon 20 Feb 84 19:21:23-EST From: Frank da Cruz Subject: Re: Kermit for VM/CMS via YALE/IUP (Series/1) To: Michael_Walsh__Univ._College_Dublin%qzcom@UCL-CS.ARPA, KERMIT_implementation_and_experience%qzcom@UCL-CS.ARPA, info-kermit%columbia-20..arpa%ucl-cs.arpa%ykxa@UCL-CS.ARPA cc: Info-Kermit@CUCS20 In-Reply-To: Message from "Michael_Walsh__Univ._College_Dublin%qzcom@ucl-cs.arpa" of Mon 20 Feb 84 18:32:00-EST The problem with using KERMIT over the Yale/IUP (Series/1) is that the IBM VM/CMS host believes it's talking to a "green tube", i.e. IBM 3270-series synchronous terminal. If CMS Kermit were to send out a packet, first VM (or is it CMS) would modify it by putting 3270 commands on it, and then the IUP would modify it still further by "interpreting" the 3270 commands (by translating them to escape codes for the particular ASCII terminal) and also by translating EBCDIC to ASCII (which, of course, has already been done). We need the ability to use KERMIT over the IUP too, but the solution to this problem is not easy. - Frank ------- 21-Feb-84 18:23:51-EST,681;000000000000 Return-Path: <@CUCS20:maples@bbn-unix> Received: from CUCS20 by CU20B with DECnet; 21 Feb 84 18:23:48 EST Received: from mitre-gateway by COLUMBIA-20.ARPA with TCP; Tue 21 Feb 84 18:22:11-EST Date: 21 Feb 1984 18:18:38 EST (Tuesday) From: Subject: Standard (?) Kermit To: info-kermit at columbia-20 Iam in search of a semi-standard kermit of reasonable size and capability. If such a system exists at your site as advertized by Dick Gillman at Columbia-20, please send me the particulars for FTP retrieval of source and documentation, if you have user manuals or pointers, please inform also. Thanks, Greg Maples (maples@mitre) 25-Feb-84 19:22:41-EST,864;000000000000 Return-Path: <@CUCS20:Margolin.Multics@MIT-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 25 Feb 84 19:22:35 EST Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 24 Feb 84 01:52:30-EST Date: Thu, 23 Feb 84 13:46 EST From: Barry Margolin Subject: kermit with real terminal emulator To: info-kermit@COLUMBIA-20.ARPA Message-ID: <840223184615.872244@MIT-MULTICS.ARPA> Anyone have a kermit implementation for MS-DOS (specifically, I have an IBM-PC and a Honeywell MicroSystem 6/10) that includes a real terminal emulator. I am looking for something which emulates a common video terminal, such as an H19; simple "ship the output straight to the screen" is not really useful. Please reply directly to me, as I don't read this list. Thanks. barmar 27-Feb-84 06:35:43-EST,1106;000000000000 Return-Path: <@CUCS20:Per_Lindberg_QZ@Qzcom.SWEDEN> Received: from CUCS20 by CU20B with DECnet; 27 Feb 84 06:35:40 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Mon 27 Feb 84 06:35:51-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 27 Feb 84 10:29 GMT Via: QZCOM; Date: Monday, 27-Feb-84 09:48:35-GMT Date: 24 Feb 84 17:45 +0100 From: Per_Lindberg_QZ%qzcom@ucl-cs.arpa Reply-to: Per_Lindberg_QZ%qzcom@ucl-cs.arpa, Per_Lindberg_QZ%qzcom@ucl-cs.arpa To: Info-Kermit , Per_Lindberg_QZ%qzcom@ucl-cs.arpa Subject: KERMIT for IBM/GUTS Message-ID: <43384@QZCOM> Is there any news from the people who are implementing KERMIT under GUTS? We here at QZ (Stockholm Univ. Comp. Center) need one badly. I want to check with the rest of the KERMIT world before we go any further. If we get desperate enough, we might try to make one together with GD (Gothenburg Data center). (But mind you, that's no *PROMISE*!) - Per Lindberg QZ - 27-Feb-84 15:20:03-EST,783;000000000000 Return-Path: <@CUCS20:Wiedemann@RADC-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 27 Feb 84 15:19:53 EST Received: from RADC-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 27 Feb 84 15:16:39-EST Date: 27 February 1984 15:15 est From: Wiedemann.4506i1808 at RADC-MULTICS Subject: MULTICS implementation To: info-kermit at COLUMBIA-20 I recently copied the MUKERMIT file from COLUMBIA for installation on our MULTICS. I am having problems compiling the PL1 code as it was copied. Is there anyone that has any hints for implementing this version of KERMIT for MULTICS? I realize that there are other sources available for MULTICS, but I find the features on this version to be rather com- plete. Thanx for your help! Wolf Wiedemann 27-Feb-84 17:31:55-EST,960;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Feb 84 17:31:50 EST Date: Mon 27 Feb 84 17:29:18-EST From: Frank da Cruz Subject: Re: MULTICS implementation To: Wiedemann.4506i1808@RADC-MULTICS.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Wiedemann.4506i1808 at RADC-MULTICS" of Mon 27 Feb 84 15:15:00-EST I can't help but suspect that there is something wrong with FTP between here and MULTICS sites; I've had this complaint before. Yet, when I look at KER:MUKERMIT.PLI on COLUMBIA-20, it is correct and complete; the pieces which people say are missing are really there. On problem is that there are some variables that are initialized in the PL/I source code with real control characters. I suspect that this may be causing some problems for MULTICS FTP? Let me know the sections you're having trouble with; maybe I can extract them and mail them to you. - Frank ------- 27-Feb-84 20:39:34-EST,760;000000000000 Return-Path: <@CUCS20:jsq@ut-sally.ARPA> Received: from CUCS20 by CU20B with DECnet; 27 Feb 84 20:39:27 EST Received: from ut-sally.ARPA by COLUMBIA-20.ARPA with TCP; Mon 27 Feb 84 20:39:20-EST Date: Mon, 27 Feb 84 19:39:16 cst From: jsq@ut-sally.ARPA (John Quarterman) Posted-Date: Mon, 27 Feb 84 19:39:16 cst Message-Id: <8402280139.AA15149@ut-sally.ARPA> Received: by ut-sally.ARPA (4.22/4.22) id AA15149; Mon, 27 Feb 84 19:39:16 cst To: info-kermit@columbia-20.ARPA Subject: jsq@ut-sally -> info-kermit@ut-sally Cc: jsq@ut-sally.ARPA Please replace jsq@ut-sally with info-kermit@ut-sally for INFO-KERMIT. If there are any other users receiving INFO-KERMIT on ut-sally, I'd like to redirect their feed through the local info-kermit alias. 28-Feb-84 11:55:11-EST,1095;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 28 Feb 84 11:55:05 EST Date: Tue 28 Feb 84 11:53:58-EST From: Frank da Cruz Subject: Software Tools Ratfor Kermit for HP3000 & Univac 1100 To: Info-Kermit@CUCS20 cc: kdp.HP-LABS@CSNET-RELAY.ARPA Announcing a remote-only version of Kermit (capable of server operation) written in Ratfor to run under the Software Tools environment. This version of Kermit was originally written by Kendall Tidwell & Allen Cole, University of Utah Computer Center, for the Univac 1100/60, with support added for the HP3000 by Ken Poulton of HP Labs. It should be readily adaptable to any other system that has the Software Tools package. The program is in KER:STKERMIT.RF, and a help file is in KER:STKERMIT.HLP, available via anonymous FTP from COLUMBIA-20 (ARPAnet) or NFT from CU20B (CCNET/DECnet). The program will also be available over BITnet via the KERMIT server, KERMSRV, at host CUVMA. Thanks to Ken Poulton at Hewlett-Packard for contributing this version. - Frank ------- 28-Feb-84 14:27:48-EST,1388;000000000000 Return-Path: <@CUCS20:fenchel@wisc-rsch> Received: from CUCS20 by CU20B with DECnet; 28 Feb 84 14:27:40 EST Received: from wisc-rsch.ARPA by COLUMBIA-20.ARPA with TCP; Tue 28 Feb 84 14:27:24-EST Date: Tue, 28 Feb 84 13:23:28 cst From: fenchel@wisc-rsch (Bob Fenchel) Message-Id: <8402281923.AA07104@wisc-rsch.ARPA> Received: by wisc-rsch.ARPA (4.22/3.7) id AA07104; Tue, 28 Feb 84 13:23:28 cst To: info-kermit@columbia-20 Subject: Kermit on Victor Cc: fenchel@wisc-rsch I am having difficulty trying to run Kermit on the Victor 9000. Here are the details: Retrieved vicmsdos.asm from columbia-20 directory, assembled it on ibm-pc, transferred exe file to victor. This is apparently a somewhat older version of kermit that has been modified in Scotland. The program runs on victor in "connect" mode without difficulty (in fact I'm using it now), however I don't seem to be able to transfer files either to or from the victor using the receive/send modes. Either the program appears to do nothing, or it rapidly sends/waits but can not receive the initiate signal from the other system. I have tried communicating with an IBM PC running the newer version of KERMIT and with a vax/unix system. In both cases, "terminal" mode works fine but file transfer does not. I'd appreciate any assistance you might have to offer. Bob (fenchel@UWisc) 29-Feb-84 11:19:33-EST,1079;000000000000 Return-Path: <@CUCS20:Brzozowski.RPMtnd@HIS-PHOENIX-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 29 Feb 84 11:19:17 EST Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 29 Feb 84 11:18:35-EST Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 29-Feb-1984 11:14:33-est Date: Wed, 29 Feb 84 09:11 MST From: Brzozowski@HIS-PHOENIX-MULTICS.ARPA Subject: Re: Kermit on Victor To: fenchel@WISC-RSCH.ARPA cc: info-kermit@COLUMBIA-20.ARPA Message-ID: <840229161145.156161@HIS-PHOENIX-MULTICS.ARPA> I had basically the same problems trying to up/download things from a Multics system. My problem was the fact that the parity settings on my system (a Compaq) was set to even parity (Default), and the Multics Kermit was set to no parity (It's default). The extra bit caused Multics-Kermit to refuse anything I sent it (ONLY intransfer mode NOT in terminal mode). After I changed my kermit to no parity it worked like a charm. Good luck! Gary Brz... 29-Feb-84 19:57:27-EST,926;000000000000 Return-Path: <@CUCS20:fenchel@wisc-rsch> Received: from CUCS20 by CU20B with DECnet; 29 Feb 84 19:57:20 EST Received: from wisc-rsch.ARPA by COLUMBIA-20.ARPA with TCP; Wed 29 Feb 84 19:57:13-EST Date: Wed, 29 Feb 84 18:53:19 cst From: fenchel@wisc-rsch (Bob Fenchel) Message-Id: <8403010053.AA08262@wisc-rsch.ARPA> Received: by wisc-rsch.ARPA (4.22/3.7) id AA08262; Wed, 29 Feb 84 18:53:19 cst To: info-kermit@columbia-20 Subject: Kermit on Victor Thanks to those who answered my call for help. I was only able to get the old version of Kermit running at 300 baud for file transfer; as noted by several respondents to my message, it is necessary to have NO parity set. Frank da Cruz placed a new version of VICMSDOS.ASM in the directory on Columbia-20; I am now running this version without any difficulty at 4800 and 9600 baud for file transfer (sure beats the heck out of 300 baud!). Bob 1-Mar-84 18:58:45-EST,2569;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 1 Mar 84 18:58:39 EST Date: Thu 1 Mar 84 18:58:47-EST From: Frank da Cruz Subject: New Release of CP/M-86 KERMIT To: Info-Kermit@CUCS20 Announcing a new release of KERMIT-86 for the DEC Rainbow 100 or the NEC APC running CP/M-86. This is version 2.4 of the program, and it was contributed by Richard Garland of the Columbia University Chemistry Department. Here are the new features: SET FLOW-CONTROL to allow XON/XOFF flow control to be turned on and off. When used, XON/XOFF allows use of smooth scrolling and the HOLD SCREEN button on the Rainbow during terminal connection without loss of data, even at high speeds, providing the system you're connected to also does XON/XOFF flow control (DEC-20s and VAXes do). The Rainbow can now transmit a BREAK signal (you must type the CONNECT escape character followed by a B to do this). File transfers with the DEC-20, VAX, and other systems that have relatively advanced KERMITs can now be interrupted by typing CTRL-X (stop this file and go on to the next) or CTRL-Z (stop the entire transfer). KERMIT-86 will now time out according to the interval requested by the KERMIT on the other side of the connection. This makes file transfer with systems that cannot time out (such as IBM mainframes) a lot more robust. The new KERMIT-86 is available on COLUMBIA-20 via anonymous FTP (ARPAnet), or CU20B via NFT (DECnet). The relevant files are: KER:RBKERMIT.CMD The executable KERMIT program for the Rainbow. KER:RBKERMIT.H86 The hex file for the Rainbow (load with GENCMD). KER:RBKERMIT.HLP Information about Rainbow KERMIT. KER:APCKERMIT.CMD The executable KERMIT program for the NEC APC. KER:RBKERMIT.H86 The hex file for the NEC APC (load with GENCMD). KER:APCKERMIT.HLP Information about NEC APC KERMIT. KER:86*.A86 The ASM86 source files for the program. KER:86KERMIT.HLP General information about CP/M-86 KERMIT. KER:86KER24.BWR Some implementation notes for version 2.4. To obtain the new version on your Rainbow or APC, use your present version of KERMIT to transfer the appropriate .CMD file. If you have trouble doing that, then transfer the .H86 file and build a .CMD file from it using GENCMD. If you don't have KERMIT on your Rainbow, read KER:RBKERMIT.HLP for a helpful hint, or follow the installation directions in the KERMIT User Guide. Report any problems directly to me. - Frank da Cruz ------- 2-Mar-84 19:55:33-EST,3382;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Mar 84 19:55:25 EST Date: Fri 2 Mar 84 19:55:35-EST From: Frank da Cruz Subject: New KERMIT User Guide To: Info-Kermit@CUCS20 The 5th edition of the KERMIT User Guide is now available. It reflects the new features added since July 1983, when the 4th edition was released. The new edition has been "modularized" (as we are trying to do with many of the KERMIT programs). The main section is system-independent, and attempts to describe an "ideal" KERMIT. The remaining sections come from separate files, one for each implementation. Each site can include sections on only those implementations they care about. The manual is written in SCRIBE text formatter language, suitable for producing documentation for a variety of media, ranging from online files to be read on a screen, to line printer output (with overstriking and underscoring), to daisy-wheel printer output (with fractional vertical spacing and other special effects), to multifont laser printer or photocomposer output. SCRIBE is a commercial product from UNILOGIC, Inc, in Pittsburgh PA, and is available for a variety of systems, including TOPS-10, TOPS-20, UNIX, IBM mainframe operating systems, Apollo, etc., and the source language is also compatible in large degree with the formatting language of Perfect Writer and Final Word on microcomputers. Some of the documentation is actually ahead of the software. In particular, the sections describing DEC-20 and MS DOS KERMITs apply to soon-to-be-released versions (watch this space for news). All files are available in KER: on COLUMBIA-20 via anonymous FTP (ARPANET) or CU20B (DECNET). The Scribe source files are: USER.MSS The system-independent part, and the "root file" for the rest. 20KERMIT.MSS Description of DEC-20 KERMIT. VMSKERMIT.MSS .. DEC VAX/VMS KERMIT. CMSKERMIT.MSS .. IBM VM/CMS KERMIT. UXKERMIT.MSS .. UNIX KERMIT. PCKERMIT.MSS .. IBM PC (and other MS DOS systems) KERMIT. CPMKERMIT.MSS .. CP/M-80 KERMIT. 86KERMIT.MSS .. CP/M-86 KERMIT. The *KERMIT.MSS files are selected with "@INCLUDE" statements in USER.MSS. These @INCLUDE statements can be edited or shuffled in any way to easily customize the manual (if you have Scribe). Some implementations do not have much documentation to speak of. Others have good documentation, but it's not in Scribe format. Anyone who would like to produce "Scribified" documentation for any system not listed above should feel free to volunteer (let me know first, so I can prevent duplication of effort). Even if you don't have Scribe, you can use the *KERMIT.MSS files as a guide. In addition to the .MSS files, there are also finished documents in several formats: USER.DOC The entire manual, with all the @INCLUDE files, as plain text (no special effects), suitable for reading on line. USER.LPT Ditto, suitable for printing on a line printer, with boldface (overstriking) and underscoring. USER.FOR Like USER.LPT, but with Fortran-style carriage control in "column 1". There are also .DOC files (but not .LPT or .FOR) for each of the @INCLUDE files listed above. Comments welcome. There will also be a new Protocol Manual shortly, containing no major changes, mainly just clarification of fine points. ------- 5-Mar-84 17:03:08-EST,1353;000000000000 Return-Path: <@CUCS20:BILLW@SRI-KL.ARPA> Received: from CUCS20 by CU20B with DECnet; 5 Mar 84 17:03:01 EST Received: from SRI-KL.ARPA by COLUMBIA-20.ARPA with TCP; Mon 5 Mar 84 16:58:00-EST Date: Mon 5 Mar 84 14:01:03-PST From: William "Chops" Westfield Subject: Getting kermit to run on our system... To: info-kermit@COLUMBIA-20.ARPA Hi. As a staunch supporter of MODEM2 over KERMIT, I have not yet brought KERMIT up on our 20s. Alas, however, there are people who dont have MODEM2 who want to talk to us, so I FTPed over the latest version of KERMIT, and tried to set it to working. IT DOESN'T WORK! I am unable to get it to transfer files even to itself! (This same KERMIT works fine on other systems.) What happens (usually), is that about 5 packets are transferred, and then 5 errors occur (quite quickly, leading me to beleive that perhaps timeouts arent working properly), and KERMIT aborts. Can someone give me a hand tracking the problem down ? As far as I know, the only relevant difference in our system is that we implement a hold key that toggles output, but this is turned off in binary mode, and is mutually exclusive with DECs XON/XOFF.... Has anyone experience similar problems? HELP! (please be sure and CC responses to me. Im not on INFO-KERMIT) Thanks Bill Westfield ------- 5-Mar-84 22:27:14-EST,2255;000000000000 Return-Path: <@CUCS20:gts%ucbpopuli.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 5 Mar 84 22:27:08 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Mon 5 Mar 84 22:27:04-EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA21012; Sun, 4 Mar 84 14:27:56 pst Received: from ucbpopuli.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.14.2) id AA06503; Sun, 4 Mar 84 14:22:42 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.14/4.14) id AA03045; Sun, 4 Mar 84 14:28:39 pst Date: Sun, 4 Mar 84 14:28:39 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8403042228.AA03045@ucbpopuli.CC.Berkeley.ARPA> To: INFO-KERMIT@Columbia-20.ARPA Subject: Kermit 8-bit Data Problems It seems that there is a slight inconsistency in computing block-checks. Please check the following and let me know if I am wrong. Apparently, UNIX `kermit r' computes the block-check AFTER trimming the eighth bit but micro kermits compute it BEFORE. Hence, if any of the original data bytes had the eighth bit set, the checksum will fail if in a single packet, an odd number of data bytes had the eighth bit set! UNIX uses block-check-type 1 (6 bits), hence, a checksum error will be detected only if an odd number of eighth bits occur in a single packet (since bits above 8 are discarded and bits 7 and 8 are shifted to the bottom of the byte and added, the checksum will differ by 2). UNIX should be changed to compute the block-check BEFORE trimming the eighth bit in `r' mode. The micro kermits set the parity on outgoing bytes AFTER computing the block-check based on the full eight bits of each data byte, hence, if some data bytes have the eighth bit set and the result does not match the micro kermit parity mode, the receiver will detect a checksum error, identically as UNIX above. This prevents using `set parity space' to trim the eighth bit. The micro kermits should be changed to set parity before computing the block-check during send. Greg Small (415)642-5979 Microcomputer Communications gts@ucbpopuli.Berkeley.ARPA 214 Evans Hall CFO gts%ucbpopuli.CC@Berkeley University of California gts@ucbpopuli.Berkeley.BITNET Berkeley, Ca 94720 6-Mar-84 11:52:57-EST,2150;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Mar 84 11:52:48 EST Date: Tue 6 Mar 84 11:52:08-EST From: Frank da Cruz Subject: Re: Kermit 8-bit Data Problems To: gts%ucbpopuli.CC@UCB-VAX.ARPA, INFO-KERMIT@CUCS20 In-Reply-To: Message from "gts%ucbpopuli.CC@Berkeley" of Mon 5 Mar 84 22:27:34-EST The high-order, or "8th", bit is used for two different purposes in KERMIT. It's preferred use is for data. But it can't be used for data if a device anywhere along the communications path demands its use for parity. When parity must be used, the user types a command like "set parity odd" (or even, mark, or space). Normally, parity is "none". When the 8th bit is used for data, it figures into the block check. When parity is being used, the parity bit does NOT figure into the block check. Unix Kermit does not do any parity processing at all. Under normal operation, it strips the 8th bit of incoming & outbound bytes and maps LF to CRLF & vice versa. In "image mode" ("-i" on command line) it leaves the data alone, and the 8th bit figures in the block check. Image mode is intended for Unix-to- Unix transfers, but may also be used for sending microcomputer binary files to Unix & getting them back. Normal mode is for transfer of text files, either Unix-to-Unix, or between unlike systems. Microcomputer Kermits (CP/M-80, CP/M-86, MS DOS), on the other hand, are capable of doing parity processing. In the normal case, no parity is used, the 8th bit may be used for data, and it figures into the block check. When parity is being used, an outbound byte should have its 8th bit stripped, the result added to the block check, and then the appropriate parity bit tacked on; an inbound byte should have its parity stripped before it is added to the block check. Without 8th-bit prefixing (which most micro Kermits don't have yet), binary files cannot be sent while parity is being done. We are currently checking CP/M-80 Kermit to make sure it actually works as described above; we already had reason to believe it wasn't. - Frank ------- 6-Mar-84 17:44:30-EST,1734;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Mar 84 17:44:17 EST Date: Tue 6 Mar 84 17:43:36-EST From: Frank da Cruz Subject: IBM Portable PC & Kermit To: Info-IBMPC@USC-ISIB.ARPA, Info-Kermit@CUCS20 I'm writing this note on an IBM Portable PC which we have on loan for a few days, using KERMIT in H19 emulation mode with EMACS. KERMIT seems to work just fine on this new machine; I didn't test it extensively, but I transferred a few files back & forth with no difficulty at all, and the terminal emulator works fine with EMACS. A couple impressions about the portable PC -- the 8.5" amber screen is awful. I have nothing against amber, but the monitor is driven by the IBM color adapter, so you get the low resolution characters and the disconcerting flicker during scrolling. There's no monochrome option. The keyboard is exactly like the PC/XT keyboard, except with a different base that folds onto the front of the unit. The cord plugs into the front of the unit (hooray!) with a phone jack and stores inside the keyboard. I installed an IBM async adapter and it worked fine right away (at 4800 baud). I notice there are 6 expansion slots. 4 of them are very short, 1 is a little bit longer, and one appears to be ALMOST long enough for the AST or Quadram multifunction boards. There's an annoying high pitched noise coming out of the vent in back. The noise plus the flicker would make this machine no fun to sit in front of all day. But the compatibility and the keyboard beat the PCjr. Speaking of the PCjr, we have one of those on loan for a few days too and will try to get KERMIT running on it if we can. - Frank ------- 6-Mar-84 18:58:51-EST,761;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 6 Mar 84 18:58:49 EST Date: Tue 6 Mar 84 18:57:12-EST From: Frank da Cruz Subject: Current KERMITs List To: Info-Kermit@CUCS20 In response to the many requests from people who wanted a single file to look in to see what the current versions of the various KERMIT implementations are, I've started a current-Kermits list in the file KER:CURRENT.DOC (it's short). It shows the prefix the file is stored under, the machine/OS, programming language, version number if any, date installed, and major contact (not necessarily the author) as a net address when possible. Available as usual via anonymous FTP (ARPANET) or NFT (DECNET). - Frank ------- 7-Mar-84 19:32:48-EST,1205;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 7 Mar 84 19:32:33 EST Date: Wed 7 Mar 84 19:32:29-EST From: Frank da Cruz Subject: CP/M-86 Kermit v 2.5 (yes, another release) To: Info-Kermit@CUCS20 This is a slight modification to version 2.4, announced last week. The main differences are that the features added in 2.4 were made to work on the NEC APC as well, and the new timeout facility can be turned on and off with a SET TIMER command. Also, the SET FILE-WARNING command was renamed to SET WARNING, to avoid conflict with SET FILE-TYPE. Timeouts are not used unless you ask for them by typing SET TIMER ON. You should normally only have to request timeout when transferring files with the IBM mainframe, since it cannot do its own timeouts. The new files replace the old ones in the KERMIT areas on COLUMBIA-20 (or CU20B), for instance KER:RBKERMIT.CMD and .H86 for the Rainbow, and KER:APCKERMIT.CMD and .H86 for the NEC APC, on the DEC-20s. The sources and documentation are in KER:86*.*, as before. Thanks to Ron Blanford at the University of Washington and Bernie Eiben at DEC for the updates. - Frank ------- 8-Mar-84 10:21:26-EST,1096;000000000000 Return-Path: <@CUCS20:ables@ut-ngp.ARPA> Received: from CUCS20 by CU20B with DECnet; 8 Mar 84 10:21:21 EST Received: from ut-ngp.ARPA by COLUMBIA-20.ARPA with TCP; Thu 8 Mar 84 10:19:15-EST Date: Thu, 8 Mar 84 09:20:17 cst Posted-Date: Thu, 8 Mar 84 09:20:17 cst Message-Id: <8403081520.AA17966@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/3.14) id AA17966; Thu, 8 Mar 84 09:20:17 cst From: King Ables To: info-kermit@columbia-20.ARPA Subject: bug in CPMBASE.M80 v3.6 I've been seeing a bug where the ^Zs at the end of a CP/M file are getting sent as data to the host kermit and I end up with them in my file after the transfer. I've looked at the code but being new to CP/M and fairly new to 8080 code, I'm not too sure what the fix is. I think it's happening in getchr. Has anybody seen/fixed this? I have also seen it on our Z-100 (built from PCKERMIT.ASM?) which seems interesting. I'm using an H89 on the CPMBASE.M80 version from home. If someone has a fix, please let me know, else consider this a bug report. Thanks, King (ables@ut-ngp) 8-Mar-84 12:57:53-EST,1471;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 8 Mar 84 12:57:46 EST Date: Thu 8 Mar 84 12:50:17-EST From: Frank da Cruz Subject: Re: bug in CPMBASE.M80 v3.6 To: ables@UT-NGP.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "King Ables " of Thu 8 Mar 84 10:19:40-EST The problem with seeing ^Z's at the end of a file sent from a micro stems from the difficulty in determining the end of a microcomputer file. In CP/M, for instance, the eof is defined as the first ^Z anywhere in the file, except for binary files, whose eof is at the end of the last block. CP/M-80 Kermit treats files as binary by default (since it's better to send junk after the end of a text file than to truncate a binary file that may have contained a ^Z in the middle). You can avoid the junk at the end of text files by typing SET FILE-TYPE (or FILE-MODE) ASCII (or TEXT) (syntax varies from program to program) before sending text files. You can also reassemble the program with the default file type set for text files. The situation is a little more complicated for MS DOS (IBM PC & Z100 Kermit), because it keeps a byte count, which should point to the end of the file. Unfortunately, some applications also put a ^Z at the end of the file, and this too is included in the byte count. So one has no way of knowing whether the ^Z should be considered part of the file. - Frank ------- 8-Mar-84 14:37:44-EST,889;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 8 Mar 84 14:37:36 EST Date: Thu 8 Mar 84 14:06:00-EST From: Frank da Cruz Subject: New RSX-11/M/M+ and RSTS/E Kermit To: Info-Kermit@CUCS20 cc: BBoard@CU20A, BBoard@CU20B, BBoard@CU20C, BBoard@CU20D, AP2.L-Lidofsky@CU20A This is a new release of Brian Nelson's Macro-11 Kermit. The major change is that procedures are now provided for installing and running the programs on non-RMS systems, and under releases of RSTS or RSX earlier than the ones required to actually build the programs -- hexified renditions of the binaries are provided, along with conversions and installation instructions. The files are in KER:K11*.* on COLUMBIA-20, CU20B, and CU20D. See KER:K11INS.DOC for the new installation instructions and system requirements. Thanks Brian! - Frank ------- 8-Mar-84 19:10:32-EST,2262;000000000000 Return-Path: <@CUCS20:johnston@lbl-csam> Received: from CUCS20 by CU20B with DECnet; 8 Mar 84 19:10:26 EST Received: from lbl-csam.ARPA by COLUMBIA-20.ARPA with TCP; Thu 8 Mar 84 19:06:30-EST Return-Path: Received: by lbl-csam.ARPA ; Thu, 8 Mar 84 16:07:02 pst Date: Thu, 8 Mar 84 16:07:02 pst From: (Bill Johnston [csam]) johnston@lbl-csam Message-Id: <8403090007.AA10355@lbl-csam.ARPA> To: info-kermit@columbia-20 Subject: Kermit/Telnet problem Cc: fink@lbl-csam, pierre@lbl-csam Frank, We currently have a sabbatical type from Norway in our Dept., and for the past week or so, we have been trying to establish a Kermit connection from our 4.2bsd UNIX system to a DEC-10 in Norway, via Telenet. We have run into a number of things that I would like to pass on, and/or seek advise on: 1) Telenet, being a packet network, transmits data on (at least) two conditions, one, when there is enough data to fill a packet, and two, when a "data forwarding" character is encountered in the data. The data forwarding character is normally a CR, and if it is possible to change this, it is not obvious from the little documentation one gets form Telenet. The UNIX Kermit sets the packet terminator to LF, in the UNIX style, and the connection through Telenet doesn't work (since the Kermit packets are usually shorter than Telenet packets). After studying the UNIX code, I concluded that there is no reason (other than UNIX convention) to use a LF packet terminator. I suggest that this be changed (to CR) in the UNIX distribution (for all flavors of UNIX, not just UTS, as it is now). 2) Even with the helpful advice in the new manual, we couldn't ever get the two Kermits to pass checksummed packets back and forth. The checksums were never computed correctly on the UNIX end (that is to match the DEC-10 checksums). We tried all of the different parity settings on the DEC-10 end, still to no avail. We can, however, get packets from UNIX to the DEC-10. I have fixed this, temporarily, by disabling the checksum checking on the UNIX end, but this is clearly nonsence in the long run. I would be grateful for any advise. Bill Johnston, Computer Science Research UC Lawrence Berkeley Laboratory 9-Mar-84 08:54:57-EST,1723;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 08:54:50 EST Date: Fri 9 Mar 84 08:54:11-EST From: Frank da Cruz Subject: Re: Kermit/Telnet problem To: "(Bill Johnston [csam]) johnston"@LBL-CSAM.ARPA, info-kermit@CUCS20 cc: fink@LBL-CSAM.ARPA, pierre@LBL-CSAM.ARPA In-Reply-To: Message from "(Bill Johnston [csam]) johnston@lbl-csam" of Thu 8 Mar 84 19:07:08-EST Your suggestion about using CR as the default packet terminator in all versions of Unix Kermit makes sense -- does anyone out there see any reason for not doing this? My understanding about TELENET is that you have to use mark parity to make things work. The DEC-10, and most other implementations of Kermit, are capable of sending any desired parity, including mark, if you give the SET PARITY command. Unfortunately, Unix Kermit is not one of these, yet. But the normal operation of Unix Kermit is to strip the parity bit from any incoming character before adding it to the accumulated checksum. If you have SET PARITY MARK (or anything other than NONE) on the DEC-10, then it should never include the parity bit value when accumulating the outgoing checksum, so that the result SHOULD agree with what Unix computes when the packet arrives. Future releases of Unix Kermit will be a lot stronger in this area. Meantime, if you can record what's going on at both ends (I believe KERMIT-10 has a packet logging facility like KERMIT-20's, and it should be fairly simple to add a logging feature to Unix Kermit, or interposing a logging process in front of it) and mail me the results and the commands you used, maybe I can figure something out. - Frank ------- 9-Mar-84 15:12:38-EST,3174;000000000000 Return-Path: <@CUCS20:gts%ucbpopuli.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 15:12:20 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Mar 84 15:11:18-EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA23120; Fri, 9 Mar 84 11:50:13 pst Received: from ucbpopuli.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.14.3) id AA08830; Fri, 9 Mar 84 11:45:00 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.14/4.14) id AA24926; Fri, 9 Mar 84 11:42:26 pst Date: Fri, 9 Mar 84 11:42:26 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8403091942.AA24926@ucbpopuli.CC.Berkeley.ARPA> To: info-kermit@columbia-20 Subject: Kermit 8th bit Frank, It is an excellent point that the checksum checks the data not the transmission because the user may have been unaware that the eighth bit existed or that it was not being passed. For this protection, the eighth bit should NOT BE STRIPPED before computing the sum when parity is set. So existing kermits are correct in this sense. The problem of the eighth bit is important because many users are unaware of it and because many word processors and some basics use the eighth bit in what appears to be a simple text file. Every kermit should have the option to strip the eighth data bit for SENDING. In this case ONLY should the eighth data bit be stripped before addinng it to the sum, because the user has now explicitly asked for seven bits. Whenever a parity other than "none" is set a warning message should be given that files with the eighth bit set cannot be sent or received. AND a send should be aborted if an eighth data bit is seen while parity is set to other than "none". If both ends have implemented the eighth bit escape character, the warning is unnecessary. Lets examine the eighth data bit and whether it is adequately checked by the 6-bit checksum. The lower seven bits are always checked. The 6-bit check is summed as 16 bits but the upper 8 bits of the sum are discarded before bits 8 and 7 are stripped and added to bits 6-1. Because the upper 8 bits of the sum are discarded, any packet with an even number of eighth data bits has the same 6-bit sum as if those eighth data bits did not exist. While this gives some protection against single eighth-bit failures, it gives no protection against stripping of the eighth bit. A serious side effect is that files with eighth data bits send ok sometimes and fail sometimes. Consider strengthening the 6-bit checksum by stripping bits 12-7 and 16-13 and adding them to bits 6-1. The eighth data bit becomes as protected as the other seven. Older kermits will still work for 7-bit files because the upper bits will all be zero. Obviously this weakness of the 6-bit checksum is avoided if all kermits had the 16-bit sums! I will implement these suggestions and see how they work out. Greg Small (415)642-5979 Microcomputer Communications gts@ucbpopuli.Berkeley.ARPA 214 Evans Hall CFO gts%ucbpopuli.CC@Berkeley University of California gts@ucbpopuli.Berkeley.BITNET Berkeley, Ca 94720 9-Mar-84 15:38:30-EST,546;000000000000 Return-Path: <@CUCS20:LECIN@RU-BLUE.ARPA> Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 15:38:21 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Mar 84 15:36:23-EST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 9 Mar 84 15:33:07 EST Date: 9 Mar 84 15:33:24 EST From: Matthew J Lecin Subject: MACRO-11 Kermit Query To: Kermit@RUTGERS.ARPA cc: mione@RU-GREEN.ARPA Is there a version of KERMIT for RT-11? (I am running RT11 V4.0, soon to get V5.0). Thanks, {Mijjil} ------- 9-Mar-84 15:55:03-EST,1549;000000000000 Return-Path: <@CUCS20:gts%ucbpopuli.CC@Berkeley> Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 15:54:43 EST Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Mar 84 15:38:28-EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA23242; Fri, 9 Mar 84 11:57:10 pst Received: from ucbpopuli.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.14.3) id AA08901; Fri, 9 Mar 84 11:52:03 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.14/4.14) id AA25218; Fri, 9 Mar 84 11:51:13 pst Date: Fri, 9 Mar 84 11:51:13 pst From: gts%ucbpopuli.CC@Berkeley Message-Id: <8403091951.AA25218@ucbpopuli.CC.Berkeley.ARPA> To: ables@ut-ngp.ARPA, info-kermit@columbia-20.ARPA Subject: Re: bug in CPMBASE.M80 v3.6 Yes there is a problem with deafult file-mode. It should strip trailing ^Z but it does not. You can use file-mode ascii if you are sending text. But that too has a problem if your file has imbedded ^Z's. In file-mode ascii, a ^Z causes the remainder of the block (128 bytes) to be ignored BUT the send continues because cp/m did not report EOF for the file. Of course it is not clear what an imbedded ^Z means in a cp/m file, it is not very standard!!! I have also noticed that the PC kermit sends a trailing ^Z and NULL when I send to UNIX. Greg Small (415)642-5979 Microcomputer Communications gts@ucbpopuli.Berkeley.ARPA 214 Evans Hall CFO gts%ucbpopuli.CC@Berkeley University of California gts@ucbpopuli.Berkeley.BITNET Berkeley, Ca 94720 9-Mar-84 18:26:52-EST,2611;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 18:26:40 EST Date: Fri 9 Mar 84 16:34:49-EST From: Frank da Cruz Subject: Re: Kermit 8th bit To: gts%ucbpopuli.CC@UCB-VAX.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "gts%ucbpopuli.CC@Berkeley" of Fri 9 Mar 84 15:12:08-EST Greg, You've obviously put a lot of thought into this. The real question, I guess, is what to do when sending files when: a. Some file bytes have the 8th bit set, b. Parity is being used on the communication line to prevent the 8th bit from being set in the byte being sent, AND c. The two KERMITs in question can't agree to do 8th bit prefixing. Obviously, the file can't be sent correctly. But that doesn't mean that the file shouldn't be sent at all. Many word processors (and this is exactly what prompted all this) set the 8th bit of characters in text files to denote some kind of highlighting, as you point out. Many users want to be able to send these files to a foreign system, and are willing to have the special effects stripped. We might as well let KERMIT do the stripping -- it's easier than running the file through a conversion program first, especially when disk space is tight. In other words, the user should be able to decide -- if she wants to send a file this way, we'll assume she knows what she's doing, provided the sending program prints a warning message to say what's going on. Then the user has the option of typing ^X to "abort" the file if she really doesn't want to send it (most micro Kermits now support this, or will very soon). I agree that the checksum may not be adequate. Unfortunately, it's simply too late to change how it works -- there are thousands of KERMIT programs out there. Even if we changed every single one of them at the distribution point, there would still be thousands of users running the old ones who will never hear about the change. Potential problems with the six-bit checksum (and, as I've said before, I've yet to hear of an ACTUAL problem with it) are what prompted the type 2 and 3 alternate block check methods, which are in place in CP/M-80 Kermit. If we had it to do over again, though, I think we'd do the single-character checksum the way you suggest. If we don't strip the 8th bit before computing the checksum when parity is set, then the receiver will get a different value and reject the packet. If you're not sending the 8th bit as data, you CAN'T include it in the checksum because the receiver will never see it. - Frank ------- 9-Mar-84 19:31:21-EST,984;000000000000 Return-Path: <@CUCS20:CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 19:31:18 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Mar 84 16:53:54-EST Received: from COLUMBIA-20.ARPA by RUTGERS.ARPA with TCP; 9 Mar 84 16:50:14 EST Date: Fri 9 Mar 84 16:37:20-EST From: Frank da Cruz Subject: Re: MACRO-11 Kermit Query To: LECIN@RU-BLUE.ARPA, Kermit@RUTGERS.ARPA cc: mione@RU-GREEN.ARPA In-Reply-To: Message from "Matthew J Lecin " of Fri 9 Mar 84 15:33:24-EST Yes, there is a KERMIT for RT-11. See KER:RT*.* on COLUMBIA-20. This version comes from the University of Toronto; it's written in OMSI Pascal, but a hexified version of the runnable binary file is available so that you can run it even if you don't have OMSI Pascal. Brian Nelson, who wrote the Macro-11 Kermit for RSX and RSTS, will have a version of that program for RT-11 soon as well. - Frank ------- 11-Mar-84 03:44:03-EST,1528;000000000000 Return-Path: <@CUCS20:G.FUSSELL@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 11 Mar 84 03:43:58 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Sun 11 Mar 84 03:44:33-EST Received: from SU-SCORE.ARPA by RUTGERS.ARPA with TCP; 11 Mar 84 03:40:50 EST Date: Sun 11 Mar 84 00:40:06-PST From: Carl Fussell Subject: Re: MACRO-11 Kermit Query To: LECIN@RU-BLUE.ARPA cc: kermit@RUTGERS.ARPA In-Reply-To: Message from "Matthew J Lecin " of Fri 9 Mar 84 15:33:24-PST Address: Santa Clara University I am running RT V4.0 (will be getting 5.0 next week). I am running the RTKERM distribution set (with modifications) and seems to work ok. The distribution set was written in OMSI which I don't have so minor mods had to be done to eliminate those dependencies. Secondly, the distribution set used monitor call .TTYIN for virtual terminal mode. I replaced this with an assembly driver so that chars like ^S, ^Q, ^O, etc could be used without being intercepted by RT11. This is working. Adding code for baud rate selection by program control (for DLV11-E's), line selection (CSR/VEC) , VT100 style display of SEND/REC data when transfering files, and so on. This requires modification of overlay structure and I have been a little short of time last couple of weeks. I intend to submit it back to the distribution list when completed, but if you are interested in any of this before then, let me know. -Carl ------- 12-Mar-84 12:33:49-EST,889;000000000000 Return-Path: <@CUCS20:CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 12 Mar 84 12:33:39 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 12 Mar 84 12:30:17-EST Received: from COLUMBIA-20.ARPA by RUTGERS.ARPA with TCP; 12 Mar 84 12:30:51 EST Date: Mon 12 Mar 84 12:28:47-EST From: Frank da Cruz Subject: Re: MACRO-11 Kermit Query To: G.FUSSELL@SU-SCORE.ARPA, LECIN@RU-BLUE.ARPA cc: kermit@RUTGERS.ARPA In-Reply-To: Message from "Carl Fussell " of Sun 11 Mar 84 03:44:50-EST Sounds great, but I'd just as soon wait till you're finished. You might also want to contact Brian Nelson at the University of Toledo (ATSBDN@UOFT01.BITNET) about his Macro-11 based RT11 Kermit, which will most likely have all imaginable bells & whistles, and not require any Pascal at all. - Frank ------- 12-Mar-84 13:09:11-EST,462;000000000000 Return-Path: <@CUCS20:mike@logicon> Received: from CUCS20 by CU20B with DECnet; 12 Mar 84 13:09:03 EST Received: from LOGICON by COLUMBIA-20.ARPA with TCP; Mon 12 Mar 84 13:06:54-EST Date: 12 Mar 1984 0934-PST From: mike@LOGICON Subject: Name Change To: INFO-KERMIT@COLUMBIA-20 cc: mike I am on your kermit mailing list, and need a little help. Please transmit kermit mail to kermit@logicon and NOT mike@logicon. Thanks.... Mike Parker ------- 12-Mar-84 14:08:35-EST,483;000000000000 Return-Path: <@CUCS20:SMITH@USC-ECLC.ARPA> Received: from CUCS20 by CU20B with DECnet; 12 Mar 84 14:08:17 EST Received: from USC-ECLC.ARPA by COLUMBIA-20.ARPA with TCP; Mon 12 Mar 84 14:05:18-EST Date: 12 Mar 1984 11:03-PST Sender: SMITH@USC-ECLC Subject: Kermit for DEC Professional? From: Dennis R. Smith To: Info-Kermit@COLUMBIA-20 Message-ID: <[USC-ECLC]12-Mar-84 11:03:43.SMITH> What is the status of a Kermit for the DEC Professional (P/OS)? 12-Mar-84 14:54:44-EST,650;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 12 Mar 84 14:54:36 EST Date: Mon 12 Mar 84 14:52:02-EST From: Frank da Cruz Subject: Re: Kermit for DEC Professional? To: Smith@USC-ECLC.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Dennis R. Smith " of Mon 12 Mar 84 14:03:00-EST There are two (2) versions of Kermit for the DEC Professional with P/OS, but we have yet to devise a way of distributing them, because of problems with the binary help menus and so forth. A solution is being cooked up, and an announcement should be made soon. - Frank ------- 13-Mar-84 13:35:17-EST,707;000000000000 Return-Path: <@CUCS20:SIETZ@RU-GREEN.ARPA> Received: from CUCS20 by CU20B with DECnet; 13 Mar 84 13:35:12 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 13 Mar 84 11:07:23-EST Received: from RU-GREEN.ARPA by RUTGERS.ARPA with PUP; 13 Mar 84 10:58:35 EST Date: 13 Mar 84 10:58:46 EST From: Brian Subject: MS-DOS KERMIT for the DEC Rainbow To: info-kermit@COLUMBIA-20.ARPA cc: Sietz@RU-GREEN.ARPA Home: 506 Birch Dr. Cherry Hill, NJ. (609) 428-1201 Work: RCA Corp. Moorestown, NJ. (609) 778-6163 I am wondering if there is a Kermit available for the DEC Rainbow running under MS-DOS. If not - is there anyone working on it? Brian Sietz ------- 13-Mar-84 13:38:54-EST,619;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 13 Mar 84 13:38:49 EST Date: Tue 13 Mar 84 11:17:19-EST From: Frank da Cruz Subject: Re: MS-DOS KERMIT for the DEC Rainbow To: SIETZ@RU-GREEN.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Brian " of Tue 13 Mar 84 10:58:46-EST As yet, no Kermit for the Rainbow under MS DOS. There is one written in C floating around (I don't have it yet) whose status is uncertain. The IBM PC implementation will be adapted to run on the Rainbow by us at Columbia in any case. - Frank ------- 13-Mar-84 19:17:54-EST,695;000000000000 Return-Path: <@CUCS20:FRIEDMAN@RU-GREEN.ARPA> Received: from CUCS20 by CU20B with DECnet; 13 Mar 84 19:17:50 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 13 Mar 84 19:15:57-EST Received: from RU-GREEN.ARPA by RUTGERS.ARPA with PUP; 13 Mar 84 19:15:40 EST Date: 13 Mar 84 19:16:03 EST From: FRIEDMAN@RU-GREEN.ARPA Subject: kermit manuals. To: info-kermit@COLUMBIA-20.ARPA Scribe drops characters from the kermit manuals User.mss. Even User.lpt is missing characters at the end of some lines. -Gadi harpo!whuxlb!ru-blue!friedman ------- 14-Mar-84 02:47:05-EST,1522;000000000000 Return-Path: <@CUCS20:Klensin.ARCS@MIT-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 02:47:01 EST Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Mar 84 01:32:41-EST Date: Wed, 14 Mar 84 01:32 EST From: "John C. Klensin" Subject: Rainbow CP/M-80 Kermit warning To: Info-Kermit@COLUMBIA-20.ARPA Message-ID: <840314063214.465312@MIT-MULTICS.ARPA> I suspect that this is not worth fixing, but, for the information of anyone else who might be surprised, the CP/M-80 Kermit for the DEC Rainbow has the interesting property that, if it is sent a filename that contains lower case characters, it creates a CP/M file and directory entry containing lower case characters. Unfortunately, resident CP/M commands and most transient ones cannot find things with lower-case names. It might be helpful if the "file names" section of the protocol manual contained an explicit warning that file-receiving implementations on machines where the file system is single-case but programs can manage to create dual-case or "other" case names had better be prepared to map to the appropriate case. This mapping is not a "normal form" problem, nor should it be done in the sender. The sender will, in general, not know what case(s) the recipient wants; the latter should figure this out for itself. Most of the micro Kermit codes seem to have gotten this right; the Rainbow-80 version is the first with which we have noticed the problem. 14-Mar-84 09:32:06-EST,648;000000000000 Return-Path: <@CUCS20:OC.GARLAND@CU20B> Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 09:31:57 EST Received: from CU20B by CUCS20 with DECnet; 14 Mar 84 09:30:49 EST Date: Wed 14 Mar 84 09:31:04-EST From: Richard Garland Subject: Setting the baud rate for Rainbow Kermit To: BBoard@CU20B cc: info-kermit@CUCS20 The reason Rainbow kermit doesn't have a SET BAUAD command (or some such) is because it's so easy to set it from the keyboard using the set-up function. I use rainbow kermit all the time and never considered using a program to set the baud rate. I just use the set-up function. Rg ------- 14-Mar-84 10:20:30-EST,1163;000000000000 Return-Path: <@CUCS20:POLARIS@USC-ISI> Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 10:20:22 EST Received: from USC-ISI.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Mar 84 10:19:13-EST Date: 14 Mar 1984 07:17-PST Sender: POLARIS@USC-ISI Subject: kermit on ARPANET From: POLARIS@USC-ISI To: info-kermit@COLUMBIA-20 Message-ID: <[USC-ISI]14-Mar-84 07:17:53.POLARIS> I have been using KERMIT over the ARPANET (actually using it to transfer files from our "local" host (in California) to or site, here in Virginia) for about a month. Up until recently thre has been no difficulty if I set the TAC interupt character to CTRL-D before logging on. (I am transfering text files only). The local kermits have been several: 86Kermit, PCKermit, and CPMKermit for the Heath. Then suddenly I am unable to use the process--Kermit chokes on the 1st of second packet (usually the first). Has the distribution version of Kermit20 changed, has the net protocol changed? (or am I just doing something dumb?) I can still use PCKermit (with Herm Fischer's server code) in conjunction with my Heath at home. --HELP Mike Seyfrit --and thanks 14-Mar-84 11:01:30-EST,953;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 11:01:16 EST Date: Wed 14 Mar 84 10:59:38-EST From: Frank da Cruz Subject: Re: Rainbow CP/M-80 Kermit warning To: Klensin@MIT-MULTICS.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from ""John C. Klensin" " of Wed 14 Mar 84 01:32:57-EST We'll check the code. I thought the problem with CP/M-80 Kermit creating lower case filenames was fixed a while back, but maybe not. If not, we'll fix it. By the way, we've pretty much "de-committed" supporet for CP/M-80 Kermit on the Rainbow because (a) CP/M-86 Kermit is available for it, and (b) CP/M-80 Kermit does not work at all on the Rainbow under the new (2.0) release of DEC's CP/M-86/80. The CP/M-86 Kermit runs much faster anyway, although a couple fancy features remain to be added (local DIR, ERA, etc; fancy block checks; ...) - Frank ------- 14-Mar-84 13:07:40-EST,474;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 13:07:20 EST Date: Wed 14 Mar 84 11:02:52-EST From: Frank da Cruz Subject: Re: kermit on ARPANET To: POLARIS@USC-ISI.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "POLARIS@USC-ISI" of Wed 14 Mar 84 10:17:00-EST A forthcoming release of Kermit-20 attempts to solve all the TAC-related problems. Watch this space for announcements. - Frank ------- 15-Mar-84 15:06:59-EST,471;000000000000 Return-Path: <@CUCS20:JFisher.Help@RESTON.ARPA> Received: from CUCS20 by CU20B with DECnet; 15 Mar 84 15:06:35 EST Received: from RESTON.ARPA by COLUMBIA-20.ARPA with TCP; Thu 15 Mar 84 15:04:02-EST Date: 15 March 1984 15:00 est From: JFisher.Help at RESTON Subject: Kermit for Sanyo MBC1150 To: info-kermit at COLUMBIA-20 Has anybody had any experience putting kermit up on a Sanyo MBC1150 (cp/m) ? Should I assume that generic kermit is the one to try ? 15-Mar-84 16:23:22-EST,703;000000000000 Return-Path: <@CUCS20:LEVYAL@USC-ISI> Received: from CUCS20 by CU20B with DECnet; 15 Mar 84 16:23:08 EST Received: from USC-ISI.ARPA by COLUMBIA-20.ARPA with TCP; Thu 15 Mar 84 16:20:12-EST Date: 15 Mar 1984 13:19-PST Sender: LEVYAL@USC-ISI Subject: Help on cpm apple kermit From: LEVYAL@USC-ISI To: info-kermit@COLUMBIA-20 Message-ID: <[USC-ISI]15-Mar-84 13:19:44.LEVYAL> I would like to bring up cpm kermit on my apple . Unfortunetely the system has a SSC card in slot 2. The cpmapple file is to big for me to bring down to my apple disk to edit for the SSC and slot changes. Any help would be appreciated. Also is there a kermit on the Tops-20 at ISI and MIT-Multics? Thanks, Allan 15-Mar-84 19:49:10-EST,6401;000000000000 Return-Path: <@CUCS20:BILLW@SRI-AI.ARPA> Received: from CUCS20 by CU20B with DECnet; 15 Mar 84 19:49:01 EST Received: from SRI-AI.ARPA by COLUMBIA-20.ARPA with TCP; Thu 15 Mar 84 19:47:11-EST Date: Thu 15 Mar 84 16:48:02-PST From: William "Chops" Westfield Subject: How lucky we all are..... To: info-kermit@COLUMBIA-20.ARPA, info-modemxx@MIT-MC.ARPA cc: protocols@RUTGERS.ARPA [Henceforth, copys of my MODEM2 program will be sold for $10000. each. Since Kermit also talks to IBM mainframes, I suggest you charge 20K.. (-: Are you glad you use DEC? Dont you wish everybody did? :-) ] a006 15-Mar-84 06:31 BC-TECHNOLOGY (Financial Commentary) By ANDREW POLLACK c.1984 N.Y. Times News Service NEW YORK - One of the newest computer industry buzzwords is ''micro-mainframe link.'' Dozens of companies are falling over themselves to announce products designed to allow desktop microcomputers to exchange information with mainframes, large central corporate computers. No one denies that such connections are a major trend. But as with other industry buzzwords - such as user-friendly, integrated and compatible - no one knows exactly what a micro-mainframe link means, and buyers are becoming confused trying to separate the claims of vendors from reality. ''There's a lot more sound and fury than actual buying going on,'' said Robert N. Healy, senior vice president of Software International, an Andover, Mass., software company that recently introduced such a link. The need for such links is clear. Personal computers are spreading through corporations, allowing workers to do their own computer analyses. But much of the data needed by these workers are still in the corporate mainframe. A budget analyst who needs last year's expense figures to do a forecast for next year would find those figures in the mainframe computer. Similarly, a secretary who wants to use a word processing program to send out dunning letters would have to draw on the central computer to find the delinquent accounts. The solution until now has been to get a printout of the required information from the central computer and then retype the information into the personal computer, which is extremely tedious. It seems much easier to have the data transferred directly from the mainframe to the microcomputer. But such communication is neither easy nor inexpensive. Microcomputers communicate at slower speeds than mainframes and use a different language. Hence, a personal computer must be beefed up with a special circuit board that can cost more than $1,000. In addition to this hardware, there must be software in the mainframe that allows it to recognize the requests from the personal computer. Such programs can cost $25,000 or more. There must also be software for the personal computer that allows the user to request information and to transfer it into the spreadsheet or dunning letter. Thus the link can cost more than the personal computer itself. The simplest link is to have the personal computer emulate a computer terminal, which is the way most computer users interact with commercial data bases such as Compuserve. But such a connection only allows the personal computer user to look at the data, not to store them and manipulate them. One step up is the ability to ''download'' data. This allows the personal computer user to call information from the mainframe and store it on a disk. The data, however, are in raw form and the user must figure out himself how to get the data from the disk into the spreadsheet or dunning letter. An improvement on that is to add software to allow the data to be formatted correctly, so they can go directly from the mainframe into the proper rows and columns of the spreadsheet or into the proper spots in the dunning letter. Yet another approach is to have the microcomputer and the mainframe run the same programs, so that the personal computer becomes a miniature version of the mainframe, and translation of data is not as necessary. One of the early examples of this is the International Business Machines Corp.'s new XT370 computer, a desktop machine that can run software written for IBM's mainframes. Total sales of the hardware and software needed for the links totaled $222 million in 1983 and will double to $545 million in 1984, according to International Resource Development, a Norwalk, Conn., market research firm. Most major mainframe software companies have entered the market. Some are teaming up with microcomputer software companies. Many of the micro-mainframe links developed by software companies work only with IBM or IBM-compatible personal computers, and only with software made by the manufacturer of the link. Some smaller companies are making the communications circuit boards, the best known being the IRMA board from Digital Communications Associates of Norcross, Ga. But the biggest provider of links is likely to be IBM, since the company already is the leading producer of computers at both ends of the link. Late last year, IBM introduced two desktop machines designed for this link - the XT370 and the 3270 PC, which doubles as a computer and as a 3270 family terminal. ''That's a strategic direction for IBM,'' said Betty Feezor, manager of personal computer products for Management Science America, a mainframe software company that was one of the first to provide such a link. Other hardware vendors need such connections to compete. One reason Apple Computer Inc. did not succeed with its Lisa computer last year was that the machine could not be linked to IBM mainframes, a situation now remedied. But such links pose challenges for users as well as vendors. Security must be preserved, so that people see only the data they are entitled to see. An even greater hazard: ''uploading,'' in which data are sent from the personal computer back to the mainframe. Such a feature would be useful, for instance, to allow department heads to prepare their individual budgets on spreadsheets, and then send them to the mainframe to be consolidated into a single budget. But there must be strict controls to make sure that errors are not introduced into the central records, fouling up the company's books. nyt-03-15-84 0927est ------- 16-Mar-84 17:16:31-EST,2579;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 16 Mar 84 17:16:19 EST Date: Fri 16 Mar 84 17:14:13-EST From: Frank da Cruz Subject: New DEC-20 Kermit To: Info-Kermit@CUCS20 This is to announce a new release of the KERMIT file transfer program for the DEC-20, Kermit-20 version 4(207). There are many new features; here are a few highlights: Server performs some new file management functions beyond file transfer, including directory listings, file deletions, changing directory, etc. These will not be useful to most users yet, because most of the micro- computer Kermits do not yet know how to ask for these services. Forthcoming releases of IBM PC and other Kermits will have this ability. Ability to request file management functions of a remote server when dialed out over an autodialer. Local file deletion and directory listing commands. . ARPAnet support for use over TACs and TVTs. . ITS Binary format file support. . Transaction logging to record the progress of unattended file transfers. . A variety of error detection methods, including 16-bit CRC. . Compression of repeated characters for increased throughput. . Ability to pass 8-bit binary stream data through a 7-bit communication link. . A macro definition facility for SET commands. . Initialization and TAKE command files. . Graceful interruption of file transfers in progress. . Improved reporting of settings, performance. . Improved documentation and internal help messages. . Many bug fixes, and improvements in performance and robustness. The new Kermit has been thoroughly tested against most other Kermit implementations, and is available over ARPANET via anonymous FTP from host COLUMBIA-20 (or over DECNET via NFT from CU20B) as KER:20kermit.*. It will also be available soon over BITNET via KERMSRV at host CUVMA. For a detailed list of changes since the previous release, see the file KER:20KERMIT.UPD. See KER:20KERMIT.DOC for detailed documentation of the DEC-20 Kermit program. The file KER:20KERMIT.INI is a sample initialization file. The file KER:USER.DOC is the new 5th edition of the Kermit User Guide. The Kermit protocol is explained in the Kermit Protocol Manual, available on line as KER:PROTO.DOC (edition of 4 Nov 83). For those who use KERMIT-20 for dialing out, there is also a new release of the companion program TTLINK, which corrects some bugs. The files are in KER:TTLINK.*. Report any problems with TTLINK or KERMIT-20 directly to me. ------- 16-Mar-84 20:23:37-EST,515;000000000000 Return-Path: <@CUCS20:FRAYMAN@SUMEX-AIM.ARPA> Received: from CUCS20 by CU20B with DECnet; 16 Mar 84 20:23:33 EST Received: from SUMEX-AIM.ARPA by COLUMBIA-20.ARPA with TCP; Fri 16 Mar 84 20:22:01-EST Date: Fri 16 Mar 84 17:21:26-PST From: Felix Frayman Subject: KERMIT OR MODEM-7 ON RSX O.S.? To: info-kermit@COLUMBIA-20.ARPA I am looking for KERMIT or MODEM-7 implementations for RSX operating system on LSI-11/23. Any information is appreciated. -- Felix Frayman. ------- 17-Mar-84 11:12:53-EST,1062;000000000000 Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID.ARPA> Received: from CUCS20 by CU20B with DECnet; 17 Mar 84 11:12:49 EST Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Sat 17 Mar 84 11:11:24-EST Date: 17 Mar 1984 08:10-PST Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: Re: How lucky we all are..... From: ABN.ISCAMS@USC-ISID.ARPA To: BILLW@SRI-AI Cc: info-kermit@COLUMBIA-20, info-modemxx@MIT-MC Cc: protocols@RUTGERS Message-ID: <[USC-ISID.ARPA]17-Mar-84 08:10:48.ABN.ISCAMS> In-Reply-To: The message of Thu 15 Mar 84 16:48:02-PST from William "Chops" Westfield Anybody got MDM7xx or KERMIT running on a DisplayWriter? Better yet, how about ...what is it ... IBM 3270..3720...whatever? The new Army automated support for installations is called VIABLE, and it insists on the IBM 3270..or whatever.. protocol. I have some utilities lying around somewhere that are supposed to do that, but it sure would be nice if they were built in to a modem program! Regards, David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 19-Mar-84 02:09:40-EST,1105;000000000000 Return-Path: <@CUCS20:Per_Lindberg_QZ%Qzcom.SWEDEN%Ykxa.AC.UK@Ucl-Cs.ARPA> Received: from CUCS20 by CU20B with DECnet; 19 Mar 84 02:09:36 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Mon 19 Mar 84 02:08:03-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 19 Mar 84 7:02 GMT Via: QZCOM; Date: Thursday, 15-Mar-84 20:31:34-GMT Date: 15 Mar 84 13:29 +0100 From: Per_Lindberg_QZ%qzcom@ucl-cs.arpa Reply-to: Per_Lindberg_QZ%qzcom@ucl-cs.arpa To: Info-Kermit Subject: KERMIT-10 requires parity? Message-ID: <46918@QZCOM> Some of our KERMIT users has had problems with the new version of KERMIT-10. It seems that it now requires that you first set the parity (e.g. to "space") before it works. Parity "none" (the default) doesn't work. Excuse me if these are trivial questions, but is this a bug or a feature? Maybe it would be better to have another default parity? Or isn't the parity "none" mode unforgiving enough? - Per Lindberg QZ - 20-Mar-84 17:50:53-EST,1771;000000000000 Return-Path: <@CUCS20:oc.bush%cu20b%Columbia-20.ARPA%Ucl-Cs.ARPA%Ykxa.AC.UK@Ucl-Cs.ARPA> Received: from CUCS20 by CU20B with DECnet; 20 Mar 84 17:50:36 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Tue 20 Mar 84 17:48:00-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 20 Mar 84 22:00 GMT Via: UCL-CS; Date: Tuesday, 20-Mar-84 10:33:39-GMT Received: from columbia-20.arpa by 44d.Ucl-Cs.AC.UK via Satnet with SMTP; 19 Mar 84 15:19 GMT Received: from CU20B by CUCS20 with DECnet; 19 Mar 84 10:20:12 EST Date: Mon 19 Mar 84 10:20:44-EST From: Nick Bush Subject: Re: KERMIT-10 requires parity? To: Per_Lindberg_QZ cc: info-kermit In-Reply-To: Message from "Per_Lindberg_QZ%qzcom@ucl-cs.arpa" of Thu 15 Mar 84 13:29:00-EST Sender: "OC.BUSH" KERMIT-10 does not normally require a SET PARITY SPACE to work. The only time the SET PARITY command should be necessary is if there really is some parity in use on the communications line. SET PARITY NONE assumes that the communications line is a full eight bit path, and that any characters which are not part of the data portion of a packet will have the parity bit clear. If this is not the case, then a SET PARITY command is needed to tell KERMIT-10 that it should strip the parity bit from every character it receives, and to generate parity on every character it sends. I suspect that either your communications medium is using parity, or else the "other" KERMIT is generating parity bits on the characters it is transmitting. - Nick Bush ------- 21-Mar-84 11:19:59-EST,2092;000000000000 Return-Path: <@CUCS20:OC.GARLAND@CU20B> Received: from CUCS20 by CU20B with DECnet; 21 Mar 84 11:19:53 EST Received: from CU20B by CUCS20 with DECnet; 21 Mar 84 11:18:13 EST Date: Wed 21 Mar 84 11:19:00-EST From: Richard Garland Subject: Plea to developers To: Info-kermit%Columbia-20@COLUMBIA-20.ARPA cc: OC.GARLAND@CU20B I have a plea to all developers of Kermit to include machine identification in kermit prompts and messages. Yesterday I was debugging a dialout program on VAX/VMS while logged onto the VAX from a Rainbow via Kermit. I used the dialer program to dialout to Telenet and thence to a DEC-20 to see if Kermit would work over this route (from the VAX to the 20). The dialer program could do session logging as could the Rainbow-kermit. I hit "control-(something) L" and got the message "[Logging started]". By what? I forgot what escape character I hit. Was I confused. Suggestion: > All Micro-kermits should preface their kermit version name infront of all messages that can interrupt terminal emulation. Thus - [Logging started] ==> [Kermit-86: Logging started] [Connected to remote host] ==> [Kermit-86: connected ...] [Back at micro] ==> [Kermit-86: Back at micro] > All mainframe Kermits should put their node name (DECnet, Arpanet, Usenet, whatever-you-got-net etc.] infront of all prompts and messages. Thus - Kermit-32> ==> CUCHEM::Kermit-32> Kermit-20> ==> Columbia-20::Kermit-20> [Logging started] ==> [CUCHEM::Kermit-32: Logging started] etc., etc. Most mainframes can give this information dynamically to a program running via a logical name, environment variable etc. For example on VAX/VMS there is a logical name "SYS$NODE" accesible to a program. This would be an easy thing to do in most Kermits and would certainly be a welcome feature in this day and age when we can easily be logged in on 3 or 4 machines on top of one another. Please don't consider this idea a joke - I really was confused and things will only get more complicated. Rg ------- 22-Mar-84 04:40:56-EST,1218;000000000000 Return-Path: <@CUCS20:KPJ_Jaakkola_QZ_%Qzcom.SWEDEN%Ykxa.AC.UK@Ucl-Cs.ARPA> Received: from CUCS20 by CU20B with DECnet; 22 Mar 84 04:40:53 EST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Thu 22 Mar 84 04:38:14-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 22 Mar 84 9:30 GMT Via: QZCOM; Date: Thursday, 22-Mar-84 04:54:17-GMT Date: 22 Mar 84 02:25 +0100 From: KPJ_Jaakkola_QZ_%qzcom@ucl-cs.arpa Reply-to: KPJ_Jaakkola_QZ_%qzcom@ucl-cs.arpa, Per_Lindberg_QZ%qzcom@ucl-cs.arpa, KERMIT_implementation_and_experience%qzcom@ucl-cs.arpa To: Info-Kermit , Per_Lindberg_QZ%qzcom@ucl-cs.arpa, KERMIT_implementation_and_experience%qzcom@ucl-cs.arpa Subject: KERMIT-10 requires parity? Message-ID: <47871@QZCOM> In-Reply-To: <46918@QZCOM> I wonder if not some of these problems can be traced back to losing terminal network eqt, which destroy the parity bit. This makess it necessary to set the parity to something in order to make KERMIT use a 7-bit byte size. I have at least had that problem in the past. 22-Mar-84 11:37:30-EST,956;000000000000 Return-Path: <@CUCS20:Iglesias@uci-750a> Received: from CUCS20 by CU20B with DECnet; 22 Mar 84 11:37:18 EST Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; Thu 22 Mar 84 11:34:20-EST Date: 22 Mar 84 08:36:25 PST (Thu) To: info-kermit@Columbia-20 cc: iglesias@Uci-750a Subject: PRIME Kermit From: Mike Iglesias A group on campus has tried to bring up the PRIME Kermit and is having a problem. They built it according to the directions in PRIMEK.HLP. When they run it, they get ERROR: CONDITION "POINTER FAULT" RAISED AT 4001(3)/567. The person who did the building has never used PL/I (or whatever PRIME calls it), so he has no idea how to go about debugging this. I know nothing about Primes. Has anybody else made Kermit work on a Prime? Any Prime experts out there who can tell us how to go about figuring out what is wrong? Thanks for any info. Mike Iglesias University of California, Irvine 22-Mar-84 14:42:47-EST,1268;000000000000 Return-Path: <@CUCS20:JFisher.Help@RESTON.ARPA> Received: from CUCS20 by CU20B with DECnet; 22 Mar 84 14:42:37 EST Received: from RESTON.ARPA by COLUMBIA-20.ARPA with TCP; Thu 22 Mar 84 14:38:24-EST Date: 22 March 1984 14:38 est From: JFisher.Help at RESTON Subject: Re: Prime Kermit error To: info-kermit at COLUMBIA-20 the Error: condition "condition" raised at "address" msg cited says that the pointer_fault$ condition was raised in segment number 4001 , word 567 in ring 3 (the user ring, I think). So you first have to find out what seg 4001 is, and what happens near word 567. Presumably a compliation listing will tell the latter. The general explanation of the pointer_fault$ condition is: "The process has referenced through an indirect pointer (IP) whose fault bit is on, but that pointer did not appear to be a valid unsnapped dynamic link. That is, reference has been made to an argument or instruction not in memory. This error condition is frequently caused by an incomplete load (unsatisfied references), or by making a subroutine or function call with too few arguments. The condition is raised when the called subroutine attempts to access one of its arguments through a faulted pointer." 23-Mar-84 17:14:25-EST,886;000000000000 Return-Path: <@CUCS20:Iglesias@uci-750a> Received: from CUCS20 by CU20B with DECnet; 23 Mar 84 17:14:21 EST Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; Fri 23 Mar 84 17:11:37-EST Date: 23 Mar 84 14:10:25 PST (Fri) To: info-kermit@Columbia-20 cc: iglesias@Uci-750a, grich@Uci-750a Subject: Kermit suggestion From: Mike Iglesias One feature I would like to see in Kermit (especially the IBM PC Kermit) is the ability to drop DTR on the serial line. We have a Develcon Dataswitch that all of our systems are connected to and to use Kermit on a PC and move from system to system requires pulling the connector out of the PC or the wall to tell the Dataswitch that you want to request another machine. This would also be handy if one is using Kermit on a PC at home and you want your modem to drop the line so you can dial another system. 24-Mar-84 16:03:54-EST,2344;000000000000 Return-Path: <@CUCS20:KLING%UCI-20b@UCI-750a> Received: from CUCS20 by CU20B with DECnet; 24 Mar 84 16:03:41 EST Received: from UCI-750a (not validated) by COLUMBIA-20.ARPA; Sat 24 Mar 84 16:01:50-EST Date: 24 Mar 1984 1249-PST From: Rob-Kling Subject: PC-Talk III and Kermit To: schutz%UCI-20B@UCI-750a cc: info-kermit@COLUMBIA-20, fdc@COLUMBIA-20, EASTERLIN%UCI-20B@UCI-750a, king%UCI-20B@UCI-750a, rittenHOUSE%UCI-20B@UCI-750a, iacono%UCI-20B@UCI-750a, info-ibmpc@USC-ISIB Received: from UCI-20b by UCI-750a; 24 Mar 84 12:53:37 PST (Sat) Munged: from uci-750a; 24 Mar 84 13:04:06 PST (Sat) I've spent some time w/PC-Talk III and find that it has some real advantages over Kermit in managing the transaction and some real disadvantages in acting as a terminal emulator. PC-Talk will store phone numbers and redial automatically. You can change alot of parameters (including the login drive) during a session with an Alt-key. You can read files on the PC and manage PC directories. All the time while logged onto a DEC20, actively. (in Kermit, one has to move "back" to Kermit 86, exit, fiddle with DOS, rerun Kermit, retype "set baud 1200" (why no memory?), issue a connect command, and then be back in 20 land. On the other hand, PC-Talk emulates a dumb terminal (Terminal mode TI will do), rather than a VT52. Also, it displays a help-line in high intensity at the bottom of the screen (which I find to be a nuisance). A version of Kermit with PC-talk's session management or a version of PC-Talk which emulates a VT100 or VT52 and toggles the help-bar on line 25 would be really useful. At the moment, Kermit works as a better terminal emulator, and I prefer it over PC-talk despite PC-Talk's real advantages. If I were composing alot of text on my PC and shipping them to a larger machine for processing, I might prefer PC-Talk. (PC-talk seems to communicate more slowly than Kermit, but I have not tried to benchmark the two carefully.) Since the terminal emulation is important to me, Kermit is the more useful. I wish that a next release of PC-Kermit included the phone-directory and session managing capabilities of PC-Talk. PC-Talk comes with the source code. (from FREEWARE - P.O. Box 862, Tiburon, CA 94920 ) Rob Kling UC-Irvine 25-Mar-84 04:38:43-EST,1073;000000000000 Return-Path: <@CUCS20:Schauble.HIS_Guest@MIT-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 25 Mar 84 04:38:38 EST Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Sun 25 Mar 84 04:36:57-EST Date: Sun, 25 Mar 84 04:33 EST From: Paul Schauble Subject: 8 bit graphic characters in kermit To: info-kermit@COLUMBIA-20.ARPA Message-ID: <840325093307.221410@MIT-MULTICS.ARPA> I am using the IBM PC version of kermit as a terminal emulator to talk to other PC based systems. Some of these run with the comm port set to 8 data bit, no parity, and send 8 bit data, expecting it to be displayed as the upper 128 characters, the graphic characters. The present version of kermit running with "set parity none" strips off the 8th bit. Is it possible to set up the present version to run this way? Do you know of a patch or source change to make it run that way? Save me the problems of digging it out. Also, I suggest that the next version support this mode through setup parameters. Paul 26-Mar-84 11:11:37-EST,1017;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 26 Mar 84 11:11:21 EST Date: Mon 26 Mar 84 11:08:07-EST From: Frank da Cruz Subject: Re: PC-Talk III and Kermit To: Kling%UCI-20B@UCI-750A.ARPA, brackenridge@USC-ISIB.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Rob-Kling " of Sat 24 Mar 84 20:13:00-EST I agree that most microcomputer implementations of Kermit are weak in the area of session control. As you point out, the idea is to have a package that works over a wide variety of machines (many of which may not have PF or ALT keys) in a relatively consistent way, but on the other hand the desired control should be provided when feasible. I expect the next release of PC Kermit will make you happier -- it'll leave the baud rate the way you left it last time, and it will have external command files, a toggle-able status line, scrollback of the terminal session, and many other improvements. - Frank ------- 27-Mar-84 12:58:47-EST,779;000000000000 Return-Path: <@CUCS20:LINNEROOTH@SANDIA.ARPA> Received: from CUCS20 by CU20B with DECnet; 27 Mar 84 12:58:39 EST Received: from SANDIA.ARPA by COLUMBIA-20.ARPA with TCP; 27 Mar 84 12:55:55 EST Date: Tue 27 Mar 84 10:53:34-MST From: Tom Linnerooth Subject: Apollo support To: info-kermit@COLUMBIA-20.ARPA We at Sandia Labs are just starting to look at KERMIT as a method of linking engineering work stations to the DEC-20. One of the workstations we have is based on the Apollo computer running the AEGIS operating system. Can anyone tell me if any work has been done to provide KERMIT support for that system? Thanks. Please reply directly to me since I am presently not on this list. Tom Linnerooth (LINNEROOTH@SANDIA) ------- 28-Mar-84 15:34:14-EST,953;000000000000 Return-Path: <@CUCS20:Klensin.ARCS@MIT-MULTICS.ARPA> Received: from CUCS20 by CU20B with DECnet; 28 Mar 84 15:34:01 EST Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 28 Mar 84 14:58:44 EST Date: Wed, 28 Mar 84 14:46 EST From: "John C. Klensin" Subject: Osborne kermit To: Info-Kermit@COLUMBIA-20.ARPA Message-ID: <840328194637.202279@MIT-MULTICS.ARPA> It appears that this routine does not (a) Understand about the modem port and the internal (slide-in) modem and how to use it. (b) Understand enough to be able to work the dialer arrangements of that modem. (c) Understand how to generate a BREAK with either the RS232 port or the modem port. Is anyone thinking about doing anything about these problems, or should we try making a plan about them? Note that (b) is likely to be quite annoying, since the modem has little intelligence and has to be pulsed by the computer. 28-Mar-84 17:13:42-EST,1483;000000000000 Return-Path: <@CUCS20:jalbers@BNL> Received: from CUCS20 by CU20B with DECnet; 28 Mar 84 17:13:28 EST Received: from BNL by COLUMBIA-20.ARPA with TCP; 28 Mar 84 17:09:37 EST Date: 28-Mar-84 17:07:40-EST From: jalbers@BNL Subject: OSKERM To: info-kermit@COLUMBIA-20 Cc: Klensin@MIT-MULTICS John, Chuck Bacon, who devloped OSKERM, never intended to have it work for the Ozzie's modem port, nor for the COMM-PAC modem. I think that it would be, though, an easy fix. (No, I'm not going to do it) All that must be done it change the port address. I will, if someone REALLY wants to do the mods, supply the address change. On a break and the Osborne 1. The Ozzie's RS232 is not fully implimented, thus it can't genetate a break at all (Due to the supreme and holy knowledge of OCC)!!! The modem port can, though. Don't count on dialing the COMM-PAC, though, because it is done through a combination of an escape sequencs and making one pin go high. If you really want a good communications program, and don't need the KERMIT protocols, use OTERM405, which is public domain and at SIMTEL20. It does allow the use of the modem port, although it does not dial the COMM-PAC (you have to do it by hand).. Jon Albers jalbers@bnl (P.S. Any Ozzie owners who would like to get on a digest for Osborne 1 and Osborne Exec owners, send me a note) 28-Mar-84 21:44:30-EST,794;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 28 Mar 84 18:59:58 EST Date: Wed 28 Mar 84 18:56:34-EST From: Frank da Cruz Subject: Re: Osborne kermit To: Klensin@MIT-MULTICS.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from ""John C. Klensin" " of Wed 28 Mar 84 14:59:10-EST To my knowledge, no one has announced any intention to fix the Osborne problems that you mention. Osborne Kermit users all over the world would thank you if you could fix them. However, first please wait a week or two for the announcement of CP/M-80 Kermit version 3.9, which contains many fixes and enhancements, so that your Osborne fixes won't have to be painfully retrofitted. Thanks for the offer! - Frank ------- 29-Mar-84 12:32:47-EST,567;000000000000 Return-Path: <@CUCS20:SLAVENBURG@SU-SIERRA.ARPA> Received: from CUCS20 by CU20B with DECnet; 29 Mar 84 12:32:36 EST Received: from SU-SIERRA.ARPA by COLUMBIA-20.ARPA with TCP; 29 Mar 84 12:30:30 EST Date: Thu 29 Mar 84 09:30:06-PST From: Gert Slavenburg Subject: add me To: info-kermit@COLUMBIA-20.ARPA Hi, Can You add me to the mailing list of kermit. Since I'm rather new here (just arrived from Europe), is there someone who can tell me if there exists a kermit running under Apple/UCSD ?? Gert Slavenburg ------- 30-Mar-84 15:11:57-EST,1518;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Mar 84 15:11:05 EST Date: Fri 30 Mar 84 15:06:19-EST From: Frank da Cruz Subject: New version of CP/M-86 KERMIT To: Info-Kermit@CUCS20 There's another new release of CP/M-86 Kermit for the DEC Rainbow 100/100+ and NEC APC. This is version 2.6 (yes, we skipped 2.5); the work was done by Ron Blanford at the University of Washington and Rich Garland at Columbia. The changes are: LOG command added for session logging, unguarded file capture. . Improved interrupt handling . Improved filename processing; valid special characters are now allowed. . Improved error messages. . Files are no longer skipped because of attribute bits. . Terminal emulation moved to a separate module. . Other code shuffled around for better modularization. . SET FILE-WARNING changed to SET WARNING. . Bug that left junk at end of file is fixed. And if you failed get version 2.4, note that that one fixed parity processing and IBM communication, added a local packet timeout facility, and added XON/XOFF flow control, allowing smooth scroll and hold-screen to work. The new version is available via anonymous FTP from COLUMBIA-20 (ARPANET) or NFT from CU20B (DECnet) and will soon be accessible via KERMSRV at CUVMA (BITNET). The files are KER:86*.* (sources & documentation), KER:RB*.* (Rainbow binaries and documentation), and KER:APC*.* (NEC APC binaries and documentation). - Frank ------- 30-Mar-84 21:15:23-EST,1035;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 Mar 84 21:15:18 EST Date: Fri 30 Mar 84 21:13:59-EST From: Frank da Cruz Subject: New Edition of Protocol Manual To: Info-Kermit@CUCS20 The fifth edition of the KERMIT Protocol Manual is available via anonymous FTP from COLUMBIA-20 (ARPANET), NFT from CU20B (DECNET), and (soon) via KERMSRV from CUVMA (BITNET). It incorporates a few new (minor) ideas, changes a few details in the Attribute packet description (these have never been implemented anywhere, so that shouldn't cause too much grief), includes a much more complete state table, and clarifies many of the points that so many of you requested clarification on. It's in KER:PROTO.*. PROTO.MSS is the Scribe source file, PROTO.DOC is suitable for printing or reading on the terminal, PROTO.LPT is suitable for printing on a printer, and PROTO.FOR is for printing on systems that need FORTRAN-style carriage control. Comments welcome. - Frank ------- 30-Mar-84 21:58:34-EST,1176;000000000000 Return-Path: <@CUCS20:papa%usc-cse.csnet@csnet-relay.arpa> Received: from CUCS20 by CU20B with DECnet; 30 Mar 84 21:58:31 EST Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 30 Mar 84 21:54:08 EST Received: by csnet-relay via xusc-cse; 30 Mar 84 21:40 EST Date: Thu Mar 29 1984 20:32:19 From: Marco Papa To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: UNIX Kermit with line locking Cc: cc.fdc%columbia-20.arpa@csnet-relay.arpa Reply-to: papa.usc-cse@csnet-relay.arpa Peter Vanderbilt of USC has modified Unix Kermit to support locking on the use of the outgoing line for Berkeley 4.x UNIX. The change consists of only 8 lines of code. 1.) add one line for conditional compilation (see LOCK_LINE): #if UCB4X #define V6_LIBS 0 /* Dont't use retrofit libraries */ #define NO_FIONREAD 0 /* We have ioctl(FIONREAD,...) for flushinput() */ #define NO_TANDEM 0 /* We have TANDEM line discipline (xon/xoff) */ #define LOCK_LINE 1 /* Lock the line when in local mode */ #endif 2) Add the code between #if LOCK_LINE ... #endif LOCK_LINE inside the "main" program: 30-Mar-84 22:36:41-EST,1176;000000000000 Return-Path: <@CUCS20:papa%usc-cse.csnet@csnet-relay.arpa> Received: from CUCS20 by CU20B with DECnet; 30 Mar 84 22:36:36 EST Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 30 Mar 84 21:54:08 EST Received: by csnet-relay via xusc-cse; 30 Mar 84 21:40 EST Date: Thu Mar 29 1984 20:32:19 From: Marco Papa To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: UNIX Kermit with line locking Cc: cc.fdc%columbia-20.arpa@csnet-relay.arpa Reply-to: papa.usc-cse@csnet-relay.arpa Peter Vanderbilt of USC has modified Unix Kermit to support locking on the use of the outgoing line for Berkeley 4.x UNIX. The change consists of only 8 lines of code. 1.) add one line for conditional compilation (see LOCK_LINE): #if UCB4X #define V6_LIBS 0 /* Dont't use retrofit libraries */ #define NO_FIONREAD 0 /* We have ioctl(FIONREAD,...) for flushinput() */ #define NO_TANDEM 0 /* We have TANDEM line discipline (xon/xoff) */ #define LOCK_LINE 1 /* Lock the line when in local mode */ #endif 2) Add the code between #if LOCK_LINE ... #endif LOCK_LINE inside the "main" program: 31-Mar-84 00:42:34-EST,398;000000000000 Return-Path: <@CUCS20:iglesias@uci-750a> Received: from CUCS20 by CU20B with DECnet; 31 Mar 84 00:42:31 EST Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; 31 Mar 84 00:41:36 EST Date: 30 Mar 84 21:43:01 PST (Fri) To: info-kermit@Columbia-20 cc: iglesias@UCI-750a Subject: USER.LPT From: Mike Iglesias What happened to KER:USER.LPT? Is it no longer available? 31-Mar-84 20:38:47-EST,1565;000000000000 Return-Path: <@CUCS20:papa%usc-cse.csnet@csnet-relay.arpa> Received: from CUCS20 by CU20B with DECnet; 31 Mar 84 20:38:37 EST Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 31 Mar 84 20:37:01 EST Received: by csnet-relay via xusc-cse; 31 Mar 84 20:25 EST Date: Sat Mar 31 1984 11:29:01 From: Marco Papa To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: UNIX Kermit with line locking (2nd message) Cc: cc.fdc%columbia-20.arpa@csnet-relay.arpa Reply-to: papa.usc-cse@csnet-relay.arpa I guess one of the mailers lost the second part of the message. I you haven't got it, this is the rest of Peter Vanderbilt's patch for line locking with UNIX Kermit. 2) Add the code between #if LOCK_LINE ... #endif LOCK_LINE inside "main". if (ttyname) /* If LINE was specified, we */ { /* operate in local mode */ ttyfd = open(ttyname,2); /* Open the tty line */ if (ttyfd < 0) { printmsg("Cannot open %s",ttyname); exit(1); } #if LOCK_LINE /* Set exclusive-use mode on line */ if (ioctl(ttyfd,TIOCEXCL,0) != 0) { printmsg("Cannot lock %s", ttyname); exit(1); } #endif LOCK_LINE remote = FALSE; /* Indicate we're in local mode */ } else /* No LINE specified so we operate */ { /* in remote mode (ie. controlling */ ttyfd = 0; /* tty is the communications line) */ remote = TRUE; } That's all! Marco Papa USC CS Dept. ARPA, CSNET: papa.usc-cse@csnet-relay UUCP: !randvax!uscvax!papa 1-Apr-84 04:58:27-EST,1057;000000000000 Return-Path: <@CUCS20:sob@rice.ARPA> Received: from CUCS20 by CU20B with DECnet; 1 Apr 84 04:58:22 EST Received: from rice.ARPA by COLUMBIA-20.ARPA with TCP; 1 Apr 84 04:57:14 EST Received: from tethys by rice.ARPA (AA03682); Sun, 1 Apr 84 03:53:54 CST Received: by tethys (AA07105); Sun, 1 Apr 84 03:51:26 cst Date: Sun, 1 Apr 84 03:51:26 cst From: Stan Barber Message-Id: <8404010951.AA07105@tethys> To: Info-Kermit@COLUMBIA-20.ARPA, cc.fdc@COLUMBIA-20.ARPA Subject: Re: New version of CP/M-86 KERMIT This is really in reference to KERMIT-TRS80. Someone from Columbia called (713) 6609252 to download the binaray for KERMIT-TRS80 directly. Unfortunately, the BBS was not ready for this. It is now. Please pass the word to those there that are interested. The source is on-line at Rice, but needs the line numbers stripped out. Busy doing research project at the moment. I will try to get them ready soon. Regards, Stan Barber sob@rice lbl-csam!rice!sob Department of Psychology Rice University Houston,Tx 77251 2-Apr-84 17:04:50-EST,780;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Apr 84 17:04:45 EST Date: Mon 2 Apr 84 17:03:59-EST From: Frank da Cruz Subject: Use of anonymous FTP To: Info-Kermit@CUCS20 cc: Cower@CUCS20 Due to the great demand for KERMIT and the large size of the "Kermit collection" at COLUMBIA-20, anonymous FTP accesses to the KERMIT distribution area have been having a noticable impact on the responsiveness of this system. The administrators of COLUMBIA-20 have asked me to request that anonymous access to the KERMIT area be restricted to hours outside of 6:00 AM to 6:00PM, weekdays, Eastern time. Your cooperation will be much appreciated, particularly by the users of this system. Thank you. - Frank ------- 2-Apr-84 19:58:02-EST,806;000000000000 Return-Path: <@CUCS20:grich@uci-750a> Received: from CUCS20 by CU20B with DECnet; 2 Apr 84 19:57:55 EST Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; 2 Apr 84 19:56:27 EST Date: 02 Apr 84 16:57:33 PST (Mon) To: info-kermit@Columbia-20 Subject: Anyone running RSTS/E Kermit under V7.1? From: John Mangrich I got the K11NRS.HEX (etc) file and converted it to a task as per instructions on our V 7.1 RSTS/E system. When I try to run it, connect works ok but file commands get something like "ER$WCD WILDCARD ENCOUNTERED DURING FNA/DNA STRING PARSE" message. I am not a proficient MACRO/RMS programmer, so I'm slow in deciphering the source to find out what I might do, so is anyone out there in a position to suggest what is going on? John Mangrich UC Irvine 4-Apr-84 12:39:52-EST,1175;000000000000 Return-Path: <@CUCS20:papa%usc-cse.csnet@csnet-relay.arpa> Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 12:39:46 EST Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 30 Mar 84 21:54:08 EST Received: by csnet-relay via xusc-cse; 30 Mar 84 21:40 EST Date: Thu Mar 29 1984 20:32:19 From: Marco Papa To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: UNIX Kermit with line locking Cc: cc.fdc%columbia-20.arpa@csnet-relay.arpa Reply-to: papa.usc-cse@csnet-relay.arpa Peter Vanderbilt of USC has modified Unix Kermit to support locking on the use of the outgoing line for Berkeley 4.x UNIX. The change consists of only 8 lines of code. 1.) add one line for conditional compilation (see LOCK_LINE): #if UCB4X #define V6_LIBS 0 /* Dont't use retrofit libraries */ #define NO_FIONREAD 0 /* We have ioctl(FIONREAD,...) for flushinput() */ #define NO_TANDEM 0 /* We have TANDEM line discipline (xon/xoff) */ #define LOCK_LINE 1 /* Lock the line when in local mode */ #endif 2) Add the code between #if LOCK_LINE ... #endif LOCK_LINE inside the "main" program: 4-Apr-84 17:11:57-EST,1036;000000000000 Return-Path: <@CUCS20:JFisher.Help@RESTON.ARPA> Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 17:11:47 EST Received: from RESTON.ARPA by COLUMBIA-20.ARPA with TCP; 4 Apr 84 17:10:12 EST Date: 4 April 1984 17:07 est From: JFisher.Help at RESTON Subject: SuperBrain kermit To: info-kermit at COLUMBIA-20 cc: KLaurent.Help at RESTON We have recently been experimenting with kermit on the Intertec SuperBrain, transferring files to/from our local Multics. We find that with V3.2 of SB kermit, all is as it should be, files go in both directions and appear at the destination as they were at the origin. However, with the new V3.6 , things are not quite right. Files sent from the SB to Multics are fine, as above, but files arriving from Multics on the SB have the literal string 'MJ' embedded in them in place of the CRLF sequence sent by Multics. In all cases, the SB is configur-ed with 8-bit character length, 2 stop bits and no parity. So, what might we be doing wrong, or not doing that we should be ? 4-Apr-84 19:23:07-EST,1217;000000000000 Return-Path: <@CUCS20:kdp@csnet-relay.arpa> Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 19:23:00 EST Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 4 Apr 84 17:46:05 EST Received: by csnet-relay via xhp-labs; 4 Apr 84 17:38 EST Date: Wed, 4 Apr 84 10:25:25 pst From: Ken Poulton Received: by HP-VENUS id AA26476; Wed, 4 Apr 84 10:25:25 pst Message-Id: <8404041825.AA26476@HP-VENUS> To: cc.fdc%columbia-20.arpa@csnet-relay.arpa, info-kermit@csnet-relay.arpa Subject: XON handshaking Source-Info: From (or Sender) name not authenticated. We all know that IBM 370's have some i/o peculiarities that must be specially handled (usually by 'set ibm'). What is not well known is that the HP 3000 shares one of those peculiarities: it needs to use the XON handshake to communicate reliably (sigh). Most kermits seem to allow XON handshaking, but only bundled together with duplex and parity settings for IBM machines. The 3000 doesn't want these other settings. Therefore, I would like to request all kermit implementors to include XON hanshaking as a separate 'set' option - when you get around to it, of course. Thanks! Ken Poulton 4-Apr-84 19:38:33-EST,1015;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 19:38:29 EST Date: Wed 4 Apr 84 17:52:15-EST From: Frank da Cruz Subject: Re: SuperBrain kermit To: JFisher.Help@USGS1-MULTICS.ARPA cc: Info-Kermit@CUCS20 In-Reply-To: Message from "JFisher.Help at RESTON" of Wed 4 Apr 84 17:07:00-EST That is truly bizarre! We have a Superbrain here, as well as other CP/M-80 systems, which we use in conjunction with various mainframes (but no Multics systems) and have never seen such a thing! The problem is either (a) SB Kermit recognizes the prefix sequence #M#J (the normal representation of CRLF), strips out the prefix characters (#), but forgets to controllify the M and J, or (b) Multics Kermit is sending M and J without the prefix. (b) could possibly be explained by something different happening in the Send-Init exchange. I'd have to see actual logs of the packets in order to fix the blame better than that. Strange! - Frank ------- 4-Apr-84 19:52:03-EST,747;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 19:51:58 EST Date: Wed 4 Apr 84 17:58:37-EST From: Frank da Cruz Subject: Re: XON handshaking To: kdp%hp-labs.csnet@CSNET-RELAY.ARPA cc: Info-Kermit@CUCS20 In-Reply-To: Message from "Ken Poulton " of Wed 4 Apr 84 17:46:01-EST I think you're right; the protocol manual says it this way too. The new DEC-20 Kermit unbundles handshake and all the other stuff, and now defines "IBM" as a macro composed of the appropriate SET commands, rather than as a hardwired combination of parity, duplicity, and line access. Also, the handshake character itself should be SETtable. - Frank ------- 4-Apr-84 23:20:51-EST,691;000000000000 Return-Path: <@CUCS20:NEELAND@USC-ECL.ARPA> Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 23:20:41 EST Received: from USC-ECL.ARPA by COLUMBIA-20.ARPA with TCP; 4 Apr 84 18:02:02 EST Date: Wed 4 Apr 84 15:02:21-PST From: NEELAND@USC-ECL.ARPA Subject: Fix for Apple-DOS KERMIT To: info-kermit@COLUMBIA-20.ARPA Does anyone know what modifications have to be made to the Apple DOS KERMIT to support the Apple 'Super Serial' card instead of the Apple 'Commun- ications' card? The current version displays a continuous stream of characters after the CONNect command. Or are we simply missing something in the way we are setting up the Apple KERMIT? Jim Neeland ------- 5-Apr-84 01:01:10-EST,4887;000000000000 Return-Path: <@CUCS20:OC.TREI@CU20B> Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 01:00:55 EST Received: from CU20B by CUCS20 with DECnet; 5 Apr 84 00:59:51 EST Date: Thu 5 Apr 84 00:59:16-EST From: Peter G. Trei Subject: Re: Fix for Apple-DOS Kermit... To: info-kermit@CUCS20 I here repost two letters relating to using Kermit under Apple-DOS with the Super-Serial Card. The address specific stuff applies only to the unmodified 'official' version currently distributed. Peter Trei oc.trei%cu20b@columbia-20 ---------------------- People trying to use Kermit-65 (Apple DOS Kermit) Version 1.1 with a Super Serial Card have been running into problems. Here is how to make it work. 1. Before you start up Kermit, send the SSC the following string: ^AZ (thats Control-A, followed by Z). This will disable the SSC's command recognition. The SSC usually looks for ^A in the terminal input, and strips it out. It then looks at the next character, and if it is a valid SSC command, strips it out as well and performs the command. Trouble arises from the fact that Kermit uses ^A to announce the start of each packet. Typing ^AZ disables the SSC from seeing further ^A commands. If you really need to have access to the SSC commands again before you turn off the Apple, type ^A^W instead, which will change the command prefix to ^W, which should not appear during Kermit file transfer. There is a bug in the code to support the Super Serial Card, which must be fixed before it will work at all. If you look in the source code for Kermit-65 (APPLEK.M65 in , and search for the label TL2CP:, two lines further down you will see a line which reads: AND #$04 At this point, Kermit is ANDing a status register with a bitmask. If the result is non-zero, a character has been received from the modem. the problem is that 04 is the wrong mask; it should be 08, according to page 54 of the SSC manual. To fix this, you can either alter the source, recompile, and upload the new version, or much more quickly you can patch the binary version you already have. Here's how to do the patch from Applesoft: ]BLOAD APPLEK.BIN (or whatever you are calling your copy). ]POKE 8665,8 (thats a decimal address) ]BSAVE NEWKER,A$800,L$4900 Thats all. The new version contains the patch. With this, file transfer using the Super Serial Card has been done at 1200 baud. [This bug has been fixed in all the copies I hand out now. ] 3. Those of you who use 1200 baud modems will have noticed that you loose characters at the beginning of each line when the screen is scrolling. This is not Kermits fault, but rather the slowness of the software used to scroll the screen image in the Apples memory. According to the SSC manual, you can eliminate this by slightly narrowing the scroll window. The following poke does it: ]POKE 35,22 This will make line 22 the bottom of your scroll window, which is enough. I would be interested in hearing from anyone on the list who is using Kermit-65. Peter Trei, OC.TREI%CU20B@Columbia-20.Arpa Here is Richard garland's method for using the Videx and the super-serial card. Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:07:10 EST Date: Fri 27 Jan 84 21:06:45-EST From: Richard Garland Subject: Apple with SSC & Videx 80 col. card To: info-kermit@CUCS20 Using Peter Trei's suggestions (in yesterday's Info-Kermit) we now have Apple Kermit working nicely with the SSC (Super Serial Card). We have no problem connecting to and doing file transfers with a VAX running VMS and Steven's VMS Kermit at 1200 baud. Mark Paczkowski here has worked out how to get the Videx 80 column card working under Kermit with the SSC. The Videx must go in slot 3. Assume the SSC is in slot 1. The following sequence gets the whole thing going: 1) Boot the Apple 2) Type "IN#1" <== this wakes up the SSC 3) Type "A3S" <== chain SSC to Videx 80 col. card 4) Type "AZ" <== turn off SSC's interception of ^A's 5) Type "PR#3" <== turn on Videx 80 col card 6) Type "BLOAD KERMIT" <== load kermit (patched as per Peter Trei) 7) Type "CALL 7855" <== Start up Kermit Then you are off and running. The 80 col card has faster screen handling and so Peter Trei's suggestion about reducing the scrolling region to 22 lines is unnecessary. The BLOAD is needed rather than the usual BRUN so that the chaining stuff you set up in the previous steps won't get reset. During the above sequence you will get various prompts from the system and from the cards. The screen will do various wierd things but in the end it will all be ok. [Now back to my Rainbow ...] Rg ------- 5-Apr-84 09:37:54-EST,611;000000000000 Return-Path: <@CUCS20:LECIN@RU-BLUE.ARPA> Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 09:37:46 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 5 Apr 84 09:37:00 EST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 5 Apr 84 09:36:55 EST Date: 5 Apr 84 06:15 EST (Thu) From: Mijjil (Matthew J Lecin) To: Kermit@Rutgers Phase-Of-The-Moon: NM+4D.17H.40M.24S. Reply-to: Lecin@Ru-Blue Subject: Apple-Dos Kermit currently DOES support the Apple Com Card, The DC Hayes Micromodem and the Super Serial Card. Check out the SET DEVICE command... {Mijjil} 5-Apr-84 11:40:37-EST,1632;000000000000 Return-Path: <@CUCS20:JFisher.Help@RESTON.ARPA> Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 11:40:12 EST Received: from RESTON.ARPA by COLUMBIA-20.ARPA with TCP; 5 Apr 84 11:38:15 EST Date: 5 April 1984 11:34 est From: JFisher.Help at RESTON Subject: SuperBrain kermit To: info-kermit at COLUMBIA-20 cc: KLaurent.Help at RESTON Frank: Following your comments to my previous inquiry re SuperBrain kermit V3.2 vs. V3.6 , I created a small test file on Multics. It contained two lines: This is the first line. This is the second (last) line. and was called TEST. Neither V3.2 nor V3.6 supports logging (?) but Multics does. So I enabled logging on Multics, and sent TEST to the SB. The V3.2 log looked like this: 09:59 T ) S~4 @-#! 09:59 R ) Y~% @-#X 09:59 T '!FTEST1 10:04 R #!Y? 10:04 T a"DThis is the first line.#M#JThis is the second (last) line.#M#JA 10:05 R #"Y@ 10:05 T ##ZB 10:08 R ##YA 10:08 T #$B+ 10:08 R #$YB Then I sent TEST to the SB using V3.6 , and the log looked like this: 12:36 T ) S~4 @-#! 12:36 R + Y~% @-#N1W 12:36 T '!FTEST1 12:43 R #!Y? 12:43 T a"DThis is the first line.MJThis is the second (last) line.MJ, 12:44 R #"Y@ 12:44 T ##ZB 12:47 R ##YA 12:47 T #$B+ 12:47 R #$YB I have not as yet gone to the protocol manual to see what's going on, but obviously the first packet from the SB is different in the two versions, and it apparently caused Multics to eliminate the prefix character. So, is SB V3.6 doing the 'right thing' and Multics kermit screwing up, or is V3.6 defective ? 5-Apr-84 18:23:02-EST,2025;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 18:22:44 EST Date: Thu 5 Apr 84 17:16:24-EST From: Frank da Cruz Subject: Re: SuperBrain kermit To: JFisher.Help@USGS1-MULTICS.ARPA, info-kermit@CUCS20 cc: KLaurent.Help@USGS1-MULTICS.ARPA In-Reply-To: Message from "JFisher.Help at RESTON" of Thu 5 Apr 84 11:34:00-EST The problem with Multics KERMIT seeming to send files containing MJ rather CRLF appears to be due to an incorrect assumption on the part of the MULTICS Kermit author, namely that the Send-Init packet should go through the prefix encoding/decoding mechanism. The rules about this were not stated explicitly in the protocol manual at the time he wrote the program (they are now). MULTICS Kermit sees "#N" in the Send-Init packet and "decodes" that to be Control-N, which it then proceeds to use as the control quote in outgoing packets, when the SuperBrain, of course, is looking for "#" as the control quote. The reason this started happening with 3.6 of Kermit-80 is that the earlier version had no Send-Init fields after the control quote; since MULTICS Kermit ate the control quote, it found nothing in that field and therefore defaulted to the correct value. The fix is to obey the protocol manual and NOT send the Send-Init (S or I packet) or the ACK to an S or I packet through the prefix encoding/decoding mechanism. Also, note that there was another mistake: the contents of the control-prefix field of the Send-Init denote the character that "I" will be sending to "you", NOT the character "I" want "you" to send to "me". I'll call the author and tell him about this. Meanwhile, anyone with a MULTICS system is more than welcome to attempt a fix along these lines. If you volunteer for this, you should also install the fixes from Wolf Wiedemann at RADC-MULTICS, which you can find in the file KER:MUKERMIT.BWR. Thanks to Bill Catchings for figuring out the problem with MJ... - Frank ------- 5-Apr-84 19:07:24-EST,1727;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 19:07:16 EST Date: Tue 3 Apr 84 17:41:55-EST From: Frank da Cruz Subject: KERMIT on the PCjr To: Info-Kermit@CUCS20, Info-IBMPC@USC-ISIB.ARPA Well, it took three weeks, but IBM finally came through with a serial communication port cable for the PCjr (it's a short 16-pin to 25-pin adpater). We plugged it in to the serial port and gave KERMIT a whirl. It worked, sort of. Details: IBM PC KERMIT v 1.20 (the current release) was used. The serial port corresponds to COM2 on the PC or XT, so you have to SET PORT 2. We ran at 4800 baud and signed on to a DEC-20, emulating a Heath-19. When typing files or running EMACS, a few characters are lost here and there, but the terminal emulation is usable. File transfer worked just fine, though we only tested it with a few relatively short text files. One problem is that the KERMIT program assumes the screen is 80 columns wide, and the Peanut is 40 by default, so the display during file transfer is out of whack (but the files are still transferred OK). If you happen to have a monitor that supports it, you can do MODE 80 to get 80-character lines, and then the display during file transfer works just like on the PC, XT, or Portable PC. We'll fix KERMIT to run more naturally on the Peanut, by taking note of the current width, and doing whatever buffering or flow control may be necessary to prevent loss of characters during file transfer, etc. But even in its current state, it seems to be perfectly usable. Meanwhile, work on the next release continues; there should be an announcement within a few weeks. - Frank ------- 5-Apr-84 20:08:28-EST,1727;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 20:08:21 EST Date: Tue 3 Apr 84 17:41:55-EST From: Frank da Cruz Subject: KERMIT on the PCjr To: Info-Kermit@CUCS20, Info-IBMPC@USC-ISIB.ARPA Well, it took three weeks, but IBM finally came through with a serial communication port cable for the PCjr (it's a short 16-pin to 25-pin adpater). We plugged it in to the serial port and gave KERMIT a whirl. It worked, sort of. Details: IBM PC KERMIT v 1.20 (the current release) was used. The serial port corresponds to COM2 on the PC or XT, so you have to SET PORT 2. We ran at 4800 baud and signed on to a DEC-20, emulating a Heath-19. When typing files or running EMACS, a few characters are lost here and there, but the terminal emulation is usable. File transfer worked just fine, though we only tested it with a few relatively short text files. One problem is that the KERMIT program assumes the screen is 80 columns wide, and the Peanut is 40 by default, so the display during file transfer is out of whack (but the files are still transferred OK). If you happen to have a monitor that supports it, you can do MODE 80 to get 80-character lines, and then the display during file transfer works just like on the PC, XT, or Portable PC. We'll fix KERMIT to run more naturally on the Peanut, by taking note of the current width, and doing whatever buffering or flow control may be necessary to prevent loss of characters during file transfer, etc. But even in its current state, it seems to be perfectly usable. Meanwhile, work on the next release continues; there should be an announcement within a few weeks. - Frank ------- 5-Apr-84 21:13:57-EST,884;000000000000 Return-Path: <@CUCS20:kdp@csnet-relay.arpa> Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 21:13:52 EST Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 3 Apr 84 17:47:46 EST Received: by csnet-relay via xhp-labs; 3 Apr 84 17:30 EST Date: Tue, 3 Apr 84 10:58:28 pst From: Ken Poulton Received: by HP-VENUS id AA08839; Tue, 3 Apr 84 10:58:28 pst Message-Id: <8404031858.AA08839@HP-VENUS> To: info-kermit@csnet-relay.arpa Subject: Unix line locking Source-Info: From (or Sender) name not authenticated. Has anyone added uucp-compatable lock files to the Unix Kermit? Line locking works for Berkeley Unix, but other systems rely on the existence of lock files in /usr/spool/uucp to mediate access to outgoing lines. Stealing code from uucp or cu is apparently not kosher - it's covered by Bell's license agreement. 6-Apr-84 15:37:33-EST,835;000000000000 Return-Path: <@CUCS20:FRIEDMAN@RU-BLUE.ARPA> Received: from CUCS20 by CU20B with DECnet; 6 Apr 84 15:37:28 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 6 Apr 84 13:20:17 EST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 6 Apr 84 13:20:52 EST Date: 6 Apr 84 13:20:34 EST From: FRIEDMAN@RU-BLUE.ARPA Subject: Apple kermit. To: info-kermit@COLUMBIA-20.ARPA I was using Apple kermit-65 at 9600 baud (with a direct line). It seemed to be working fine, no errors, but the file turned out to be missing characters. Shouldn't kermit have given an error message or something ?. I know 9600 baud is too fast, but with no error messages I thought it might have worked. -Gadi ------- 9-Apr-84 09:56:58-EST,521;000000000000 Return-Path: <@CUCS20:GEOFFM@SRI-CSL> Received: from CUCS20 by CU20B with DECnet; 9 Apr 84 09:56:20 EST Received: from SRI-CSL by COLUMBIA-20.ARPA with TCP; 9 Apr 84 09:54:22 EST Date: 9 Apr 1984 06:49-PST Sender: GEOFFM@SRI-CSL Subject: Kermit running under Tenex From: Geoffrey C. Mulligan (AFDSC, The Pentagon) Reply-To: geoffm@SRI-CSL To: info-kermit@COLUMBIA-20 Message-ID: <[SRI-CSL] 9-Apr-84 06:49:34.GEOFFM> Does anyone have a version of Kermit running under Tenex? geoff 9-Apr-84 10:57:29-EST,664;000000000000 Return-Path: <@CUCS20:OC.BUSH@CU20B> Received: from CUCS20 by CU20B with DECnet; 9 Apr 84 10:57:23 EST Received: from CU20B by CUCS20 with DECnet; 9 Apr 84 10:55:59 EST Date: Mon 9 Apr 84 10:40:10-EST From: Nick Bush Subject: VAX/VMS Kermit problem To: MCGILL%CIT-20@COLUMBIA-20.ARPA cc: INFO-KERMIT@CUCS20 There was a problem with one of the MACRO-32 sources produced by BLISS-32 that caused errors when running Kermit with debug turned on. This can be easily fixed in the MACRO source by looking for the line "U.28:" and moving it down past the .PSECT statement, so it is just before the .ENTRY DBG_MESSAGE,... - Nick ------- 13-Apr-84 13:39:24-EST,624;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 13 Apr 84 13:39:14 EST Date: Thu 12 Apr 84 22:44:48-EST From: Nick Bush Subject: Apple Kermit To: INFO-KERMIT@CUCS20 Has anyone succeeded in getting Apple Kermit (Kermit-65) to run on an Apple IIe? We have heard conflicting stories (nothing very specific) concerning whether Kermit-65 works on IIe's. Anyone who has tried (either successfully, or unsuccessfully) to get Kermit-65 running on a IIe, please let me know. If you did get it to work, was there anything special you needed to do? - Nick ------- 13-Apr-84 14:10:57-EST,605;000000000000 Return-Path: <@CUCS20:OC.GARLAND@CU20B> Received: from CUCS20 by CU20B with DECnet; 13 Apr 84 14:10:49 EST Received: from CU20B by CUCS20 with DECnet; 13 Apr 84 14:03:55 EST Date: Fri 13 Apr 84 14:02:16-EST From: Richard Garland Subject: Re: Apple Kermit To: G.BUSH@CUCS20 cc: INFO-KERMIT@CUCS20, OC.GARLAND%CU20B%CU20B@COLUMBIA-20 In-Reply-To: Message from "Nick Bush " of Fri 13 Apr 84 13:39:29-EST We have it going on a IIe with SSC. I'll check further if there were any problems. It was a group in our Physics dept. Rg ------- 16-Apr-84 10:00:51-EST,536;000000000000 Return-Path: <@CUCS20:LATZKO@RU-BLUE.ARPA> Received: from CUCS20 by CU20B with DECnet; 16 Apr 84 10:00:40 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 16 Apr 84 09:58:20 EST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 16 Apr 84 09:58:13 EST Date: 16 Apr 84 09:58:48 EST From: Alexander B. Latzko Subject: apple 65 To: info-kermit@COLUMBIA-20.ARPA cc: latzko@RU-BLUE.ARPA does indeed work on the apple //e. details if requested. alex ------- 16-Apr-84 10:41:17-EST,992;000000000000 Return-Path: <@CUCS20:RWeaver.PA@Xerox.ARPA> Received: from CUCS20 by CU20B with DECnet; 16 Apr 84 10:40:55 EST Received: from Xerox.ARPA by COLUMBIA-20.ARPA with TCP; 16 Apr 84 10:36:55 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 16 APR 84 07:36:49 PST Date: 16 Apr 84 07:25:47 PST From: RWeaver.PA@Xerox.ARPA Subject: Re-distribution list for INFO-KERMIT@COLUMBIA-20 To: INFO-KERMIT@COLUMBIA-20.ARPA Cc: REGISTRAR.PA@Xerox.ARPA I have created the re-distribution list Kermit-Info^.pa with JonL.PA@Xerox.Arpa as the Owner, and having the following initial members: Ciccarelli.PA, Clark.Wbst, Conrad.Pasa, Ford.PA, JonL.PA, Malasky.PA, Porcar.PA, Preas.PA, Veizades.PA. Would you please add the name Kermit-Info^.pa@Xerox.Arpa as a member of INFO-KERMIT@COLUMBIA-20 and remove the following names from your memebership list: Ciccarelli.PA, Clark.Wbst, Conrad.Pasa, Ford.PA, JonL.PA, Malasky.PA, Porcar.PA, Preas.PA, Veizades.PA. Thanks! Ron... 16-Apr-84 21:28:27-EST,1046;000000000000 Return-Path: <@CUCS20:LARSON@USC-ECLB.ARPA> Received: from CUCS20 by CU20B with DECnet; 16 Apr 84 21:28:12 EST Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; 16 Apr 84 21:26:43 EST Date: Mon 16 Apr 84 18:26:41-PST From: LARSON@USC-ECLB.ARPA Subject: Prime Kermit Installation To: info-kermit@COLUMBIA-20.ARPA When getting Prime kermit from Columbia-20 using ftp make sure that the file does not contain any tabs. (Pip on a 10 or 20 can do this.) Here is a prime emacs macro to split primek.plp into the individual files: ; by Jack Heath ; modified by Robert A. Larson 4/16/84 (defcom splitk (do_n_times (numeric_argument 1) (next_line_command) (forward_char 2) (setq start (copy_cursor current_cursor)) (end_line) (back_char 2) (setq file (point_cursor_to_string start)) (begin_line) (mark) (forward_search_command "::::") (begin_line) (prepend_to_file 2 file) )) Perhaps these suggestions could be added to primek.hlp Bob Larson ------- 17-Apr-84 08:02:42-EST,1419;000000000000 Return-Path: <@CUCS20:papa%usc-cse.csnet@csnet-relay.arpa> Received: from CUCS20 by CU20B with DECnet; 17 Apr 84 08:02:37 EST Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 17 Apr 84 08:01:31 EST Received: From usc-cse.csnet by csnet-relay; 17 Apr 84 7:51 EST Date: Mon Apr 16 1984 15:39:33 From: Marco Papa To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: Great Kermit Hoax Cc: info-pc@usc-isib.arpa This is an excerpt from an article by Michael N. Huttner in the latest issue of PC WEEK, entitled "Barnum Would Enjoy Hucksterism in Ads; Buyers Beware": "... More than likely, it was one of Barnum's cunning descendants who engineered the legendary "Great Kermit Hoax," by successfully contriving to fleece Uncle Sam himself for a hefty sum before fading safely away into the sunset. According to our version of the story, our bright friend recently contracted with an agency of the federal government to develop a personal computer-to-mainframe communications software package. It seems the fellow simply borrowed a working copy of a program called KERMIT from a library collection of free, public-domain personal computer software. After making some very cosmetic modifications, he then neatly proceeded to duplicate and deliver the package as promised--and collected $ 495 per copy. A very smooth job indeed...." 17-Apr-84 12:48:33-EST,826;000000000000 Return-Path: <@CUCS20:INSTIT-STUDIES.WJBALDWIN@CUTC20> Received: from CUCS20 by CU20B with DECnet; 17 Apr 84 12:47:57 EST Received: from CUTC20 by CUCS20 with DECnet; 17 Apr 84 08:33:20 EST Date: Tue 17 Apr 84 08:32:21-EST From: Bill Balldwin Subject: Re: Apple Kermit To: G.BUSH@CUCS20, INFO-KERMIT@CUCS20 cc: INSTIT-STUDIES.WJBALDWIN@CUTC20 In-Reply-To: Message from "Nick Bush " of Fri 13 Apr 84 13:39:36-EST Have tried; haven't succeeded. Problem appears to involve the Apple IIe configuration -- what communications board, which slot, what modem.... I can't get Kermit-65 to "wake-up" the modem. The kermit-65 contact person, so I'm told, is OC.TREI@B at Columbia. Let me know if you solve the riddle. I'll do the same. -Bill Baldwin ------- 18-Apr-84 01:11:47-EST,603;000000000000 Return-Path: <@CUCS20:STAFF.SAS@UChicago.Mailnet> Received: from CUCS20 by CU20B with DECnet; 18 Apr 84 01:11:43 EST Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 18 Apr 84 01:10:20 EST Received: from UChicago.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2628568334760671@MIT-MULTICS.ARPA>; 18 Apr 1984 00:52:14 est Date: Tue 17 Apr 84 18:22:29-CST From: Stuart Schmukler Subject: CROSS BIN files To: info-kermit%Columbia-20@mit-multics.Arpa cc: staff.sas@UChicago.Mailnet Does anyone know how to generate CROSS 8-bit .BIN files? SaS ------- 18-Apr-84 03:14:18-EST,620;000000000000 Return-Path: <@CUCS20:G.FUSSELL@SU-SCORE.ARPA> Received: from CUCS20 by CU20B with DECnet; 18 Apr 84 03:14:13 EST Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; 18 Apr 84 03:12:57 EST Date: Wed 18 Apr 84 00:09:44-PST From: Carl Fussell Subject: hp kermit To: info-kermit@COLUMBIA-20.ARPA Address: Santa Clara University Is anybody working on a version of kermit for the HP 3000 (I didn't see anything in the current list of kermits)? If so, would it be possible to find out the present state of its development. Thanx for any information... carl ------- 21-Apr-84 13:40:11-EST,969;000000000000 Return-Path: <@CUCS20:chin%hp-mercury.csnet@csnet-relay.arpa> Received: from CUCS20 by CU20B with DECnet; 21 Apr 84 13:40:05 EST Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 21 Apr 84 13:12:50 EST Received: From hp-labs.csnet by csnet-relay; 21 Apr 84 2:54 EST Received: by HP-VENUS id AA25606; Wed, 18 Apr 84 09:54:02 pst Date: Wed, 18 Apr 84 09:40:26 pst From: Wayne F. Chin Received: by HP-MERCURY id AA06133; Wed, 18 Apr 84 09:40:26 pst Message-Id: <8404181740.AA06133@HP-MERCURY> To: G.FUSSELL%su-score.arpa@csnet-relay.arpa, info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: Re: hp kermit Cc: chin@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. Yes, there's a version of Kermit for the HP 3000. Try contacting Ken Poulton @ HP Labs (415)857-8461. Any other questions, call me at HP Labs (415)857-4416. Good luck, Wayne Chin (chin.hp-labs@rand-relay) 23-Apr-84 07:09:07-EST,604;000000000000 Return-Path: <@CUCS20:EXT1.SAMANI@CU20B> Received: from CUCS20 by CU20B with DECnet; 23 Apr 84 07:09:01 EST Received: from CU20B by CUCS20 with DECnet; 23 Apr 84 07:07:36 EST Date: Mon 23 Apr 84 07:07:52-EST From: SamaniFluidsnAsscts 2028ParsonsNYC113573436 2129398595 Subject: Ward-Christiansen Protocol To: info-kermit@CUCS20 Can use MODEM on CU20B:: for xmit to my micro, but not back to CU20B::. So I try line dump, but CU20B:: dies with long files.... Any suggestions? Do you know of other MODEM locations with better support (accessible by MM)? tnx/vjp2 ------- 24-Apr-84 22:22:47-EST,1117;000000000000 Return-Path: <@CUCS20:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from CUCS20 by CU20B with DECnet; 24 Apr 84 22:22:28 EST Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 24 Apr 84 22:20:20 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2629163377797336@MIT-MULTICS.ARPA>; 24 Apr 1984 22:09:37 est Date: 20 Apr 84 19:31 +0200 From: Ingemar_Joelsson_Ume}_Univ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Ingemar_Joelsson_Ume}_Univ%QZCOM.MAILNET@MIT-MULTICS.ARPA, KERMIT_implementation_and_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KERMIT_implementation_and_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA, info-kermit@COLUMBIA-20, "Alexander B. Latzko" cc: "Alexander B. Latzko" Subject: apple 65 Message-ID: <52495@QZCOM> In-Reply-To: <52400@QZCOM> Thanks! Yes I would like to receive all possible info regarding using KERMIT on my Apple 2 E. Please write to me here in QZ-Com or use my address: POBox 414, S-90108 Ume}, Sweden. Regards, Ingemar Joelsson 25-Apr-84 08:53:05-EST,838;000000000000 Return-Path: <@CUCS20:knutson@ut-ngp.UTEXAS.ARPA> Received: from CUCS20 by CU20B with DECnet; 25 Apr 84 08:52:57 EST Received: from ut-ngp.ARPA by COLUMBIA-20.ARPA with TCP; 25 Apr 84 08:51:35 EST Date: Wed, 25 Apr 84 07:52:39 cst From: knutson@ut-ngp.UTEXAS.ARPA Posted-Date: Wed, 25 Apr 84 07:52:39 cst Message-Id: <8404251352.AA27990@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/4.22) id AA27990; Wed, 25 Apr 84 07:52:39 cst To: info-kermit@columbia-20 Subject: Break on an Apple running kermit??? Is there a way to generate a break on an Apple running kermit or anyway to generate one at all? Our MICOM port contention system won't let you disconnect without sending a break. Any and all help would be much appreciated. Jim Knutson ARPA: knutson@ut-ngp UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson 25-Apr-84 13:24:58-EST,437;000000000000 Return-Path: <@CUCS20:KSPROUL@RUTGERS.ARPA> Received: from CUCS20 by CU20B with DECnet; 25 Apr 84 13:24:40 EST Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 25 Apr 84 13:22:16 EST Date: 25 Apr 84 13:21:05 EST From: KSPROUL@RUTGERS.ARPA Subject: Apple Kermit under ProDOS To: info-kermit@COLUMBIA-20.ARPA Has anyone started working on KERMIT-65 for use under ProDOS. Keith Sproul Ksproul@Rutgers.arpa ------- 25-Apr-84 14:47:14-EST,1365;000000000000 Return-Path: <@CUCS20:wunder@FORD-WDL1.ARPA> Received: from CUCS20 by CU20B with DECnet; 25 Apr 84 14:46:38 EST Received: from FORD-WDL1.ARPA by COLUMBIA-20.ARPA with TCP; 25 Apr 84 14:42:27 EST Return-Path:<> Date: 25-Apr-84 11:42:09-PST From: wunder@FORD-WDL1.ARPA Subject: Breaks To: info-kermit@COLUMBIA-20.ARPA Breaks should be pretty easy to make, if you don't mind kludges. A break is 0Volts for around 250msec. That is longer than the longest valid character, which is about 10 bits at 50 Baud (200msec). Longer breaks should be just fine. Anyway, you can make breaks by grounding your Transmit Data line for 1/4 second. If you use a cheap switch, the contact bounce could send garbage characters. If you want to be really cool, you could use a 555 one-shot chip. Transmit Data should be Pin 2 on your terminal or computer, or pin 3 on your modem. I haven't tried this, but it really ought to work. If someone tries it, I'd like to know how it goes. Good luck, w underwood PS: I've never seen a standard for the Break signal. If there is such a thing, I'd like to know about it. WUNDERWOOD(tm) BREAK-O-THING ------- TxD | | / This is supposed to be a switch. / | | 5K RS-232 lines should have a load between 3K and 7K. | | Ground Signal ground, actually. Pin 7. 26-Apr-84 10:55:05-EST,801;000000000000 Return-Path: <@CUCS20:Z00.R-GERBER@NYU20> Received: from CUCS20 by CU20B with DECnet; 26 Apr 84 10:54:54 EST Received: from NYU20 by CUCS20 with DECnet; 26 Apr 84 10:52:59 EST Date: Thu 26 Apr 84 10:51:58-EST From: Robert M Gerber Subject: Re: Breaks To: info-kermit@CUCS20 Reply-To: Z00.R-Gerber%NYU20@Columbia-20 In-Reply-To: Message from "wunder@FORD-WDL1.ARPA" of Wed 25 Apr 84 14:42:09-EST The 'standard' break for use to interrupt something that is running is four characters in length at 300 baud and above. This works with IBM mainframes very well. A break that is two long can cause the modems to hang up (this is called a 'long' break). A long break is about 400 msec long. As Wunder suggested 250 msec should work just fine. -----Robert ------- 27-Apr-84 08:25:31-EST,1206;000000000000 Return-Path: <@CUCS20:STAFF.SAS@UChicago.Mailnet> Received: from CUCS20 by CU20B with DECnet; 27 Apr 84 08:25:25 EST Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 27 Apr 84 08:23:45 EST Received: from UChicago.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2629372571931976@MIT-MULTICS.ARPA>; 27 Apr 1984 08:16:11 est Date: Thu 26 Apr 84 14:59:51-CST From: Stuart Schmukler Subject: [Don Goldhamer : KERMIT Ascii-Ebcdic translation] To: info-kermit%Columbia-20@MIT-Multics.ARPA cc: staff.sas@UChicago.Mailnet Date: Thu 26 Apr 84 14:24:19-CST From: Don Goldhamer Subject: KERMIT Ascii-Ebcdic translation To: staff.sas@UChicago.Mailnet cc: staff.dorothy@UChicago.Mailnet There is one code which is mis-translated in the KERMIT Ascii to Ebcdic translation on the IBM3081. At present the tilde (Ascii code HEX 7E) is translated into an equal-sign (Ebcdic code HEX 7E). The correct translation should be in to a tilde (sometimes displayed as a degree-sign) (Ebcdic code HEX A1). Could you correct the KERMIT translate table and documentation. Thanks Don Goldhamer ------- 27-Apr-84 10:30:58-EST,4062;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Apr 84 10:30:40 EST Date: Fri 27 Apr 84 10:24:45-EST From: Frank da Cruz Subject: New release of KERMIT for CP/M-80 To: Info-Kermit@CUCS20 cc: Info-CPM@BRL-AOS.ARPA, Info-Micro@BRL.ARPA This is to announce a new release of CP/M-80 KERMIT, version 3.9. This is not the long-awaited "modularized" version, but a maintenance release of the current monolithic version that fixes many bugs and addresses various shortcomings in the previous release, which was version 3.6. Here is a brief list of the changes since version 3.6: * Fixes & improvements contributed by Greg Small, UC Berkeley, including: . A "fuzzy" timer -- imprecise timeouts . Some VT52 emulation bugs fixed . Bugs with file attribute bits fixed . TRS-80 support for both Lifeboat & Pickles & Trout CP/M . Morrow Decision I support . Separate terminal support for TVI925, ADM3A, "generic CRT" on some systems . Buffer boundary checking for recovering from long bursts of noise * From Kimmo Laaksonen, Helsinki University of Technology Computing Centre: . Support for Nokia MikroMikko (a Finnish CP/M system) . Filename completion on ESC, a`la TENEX/TOPS-20 . TRANSMIT command, for uploading a file "bare" (no protocol), with XON/XOFF . Miscellaneous fixes & cosmetic improvements * Contributions from Bernie Eiben, DEC Marlboro, including: . Integration of Greg's and Kimmo's changes with working source . SET PRINTER ON/OFF during CONNECT (no fancy buffering or waiting) . ^C during file transfer returns immediately to command level . Source file compaction, removal of update history to separate file . Rainbow-100 support removed; use CP/M-86 Kermit from now on. * From Columbia: . 8th-bit prefixing for transferring binary files when parity is in effect . Fixed and/or improved communication with IBM mainframes . Kaypro II and other display fixes . Added code for DECmate-II to transmit BREAK signal . SET TIMER ON/OFF, off by default, goes on/off automatically with SET IBM . Default file mode as distributed is now ASCII . Misc bug fixes HEX files have been built for all the systems supported by this program. Here is a list of them: CPMAPPLE Apple II, Z80 softcard CPMBRAIN Intertec SuperBrain CPMDMII DECmate II, Z80 card CPMGENERI Generic CP/M-80 2.2 CPMHEATH Heath/Zenith-89 CPMKAYPRO Kaypro II CPMMDI Morrow Decision I CPMMIKKO Nokia MikroMikko CPMOSBORN Osborne 1 (serial port only) CPMOSI Ohio Scientific CPMPLUS Generiac CP/M-80 3.0 CPMROBIN DEC VT180 "Robin" CPMTRLB TRS-80 Model II, Lifeboat CP/M-80 CPMTRPT TRS-80 Model II, Pickles & Trout CP/M-80 CPMTELCON Telcon Zorba CPMVECTOR Vector Graphics CPMZ100 Heath/Zenith Z100, CP/M-80 (8085 side) These files are all stored with the suffix ".HEX" in the area "KER:", for instance KER:CPMDMII.HEX, in normal ASCII format. The hex files for the previous release are still available with suffix ".OHX". There is also a new Kermit User Guide chapter for this program, KER:CPMKERMIT.MSS and .DOC. The entire group of CP/M-80 Kermit files can be referred to as KER:CPM*.*. Network users may obtain KERMIT files from host CU20B via NFT (CCNET), or host COLUMBIA-20 via anonymous FTP (only after 6:00pm on weekdays, ARPANET). The hex files may be downloaded to your micro using your old version of KERMIT (or MODEM7, or any other downloading procedure) and then converted to runnable .COM format with the LOAD command. Your old KERMIT.COM should be renamed to something like OLDKERM.COM for backup and the new one can then be renamed to KERMIT.COM. Since this new release is the result of the work of many people at many sites on many different machines, there can be no guarantee that it works on all the systems listed above. It has been tested thoroughly on the DEC VT-180, the Kaypro II, and the Intertec Superbrain. I'd appreciate reports about the other systems. ------- 29-Apr-84 14:02:04-EDT,454;000000000000 Return-Path: <@CUCS20:LAVITSKY@RUTGERS.ARPA> Received: from CUCS20 by CU20B with DECnet; 29 Apr 84 14:02:00 EDT Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 29 Apr 84 14:01:27 EDT Date: 29 Apr 84 14:00:10 EDT From: Eric Subject: C64 Kermit ?? To: info-kermit@COLUMBIA-20.ARPA cc: laviTSKY@RUTGERS.ARPA Where is it? Is anyone really working on it? ... Still waiting, Eric (LAVITSKY@RUTGERS) ------- 30-Apr-84 19:58:01-EDT,730;000000000000 Return-Path: <@CUCS20:kdp@csnet-relay.csnet> Received: from CUCS20 by CU20B with DECnet; 30 Apr 84 19:57:54 EDT Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 30 Apr 84 19:57:03 EDT Received: From hp-labs.csnet by csnet-relay; 30 Apr 84 19:48 EDT Date: Mon, 30 Apr 84 13:10:39 pdt From: Ken Poulton Received: by HP-VENUS id AA09249; Mon, 30 Apr 84 13:10:39 pdt Message-Id: <8404302010.AA09249@HP-VENUS> To: info-kermit@csnet-relay.arpa Subject: Who has RSX Kermit? Source-Info: From (or Sender) name not authenticated. I remember reading here that someone took the RT-11 Kermit to RSX. Can anyone give me a current pointer? I'd like to get a copy. 1-May-84 19:23:47-EDT,504;000000000000 Return-Path: <@CUCS20:NOURSE@DEC-MARLBORO.ARPA> Received: from CUCS20 by CU20B with DECnet; 1 May 84 19:23:36 EDT Received: from DEC-MARLBORO.ARPA by COLUMBIA-20.ARPA with TCP; 1 May 84 19:22:57 EDT Date: 1 May 1984 1922-EDT From: NOURSE at DEC-MARLBORO To: INFO-KERMIT at COLUMBIA-20 Subject: KERMIT for IBMPC (jr) Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12011955528.38.122.8268 at DEC-MARLBORO> I am seeking a copy of KERMIT for the IBM PC jr. I am told that this is the place -------- 4-May-84 19:54:50-EDT,2188;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 4 May 84 19:54:40 EDT Date: Fri 4 May 84 19:53:51-EDT From: Frank da Cruz Subject: New release of CP/M-86 KERMIT To: Info-Kermit@CUCS20 Announcing a new release of KERMIT-86 for the DEC Rainbow 100 or the NEC APC running CP/M-86. This is version 2.7 of the program. New features since the last release (which was 2.4) include: 8th-bit prefixing, for transferring binary files over communication links or to systems that require character parity. Command files, TAKE command, automatic TAKE of KERMIT.INI. Reliable session logging for raw capture of remote files or typescripts. Improved command parsing and error messages, and miscellaneous display improvements and bug fixes. The new KERMIT-86 is available on COLUMBIA-20 via anonymous FTP (ARPANET, outside of 6am-6pm weekdays), and on CU20B via NFT (DECNET/CCNET). The relevant files are: KER:RBKERMIT.CMD The executable KERMIT program for the Rainbow. KER:RBKERMIT.H86 The hex file for the Rainbow (load with GENCMD). KER:RBKERMIT.HLP Information about Rainbow KERMIT. KER:APCKERMIT.CMD The executable KERMIT program for the NEC APC. KER:RBKERMIT.H86 The hex file for the NEC APC (load with GENCMD). KER:APCKERMIT.HLP Information about NEC APC KERMIT. KER:86*.A86 The ASM86 source files for the program. KER:86*.RB,86*.APC System-dependent support. KER:86KERMIT.HLP Brief information about CP/M-86 KERMIT. KER:86KERMIT.DOC The Kermit User Guide chapter on CP/M-86 KERMIT (new). To obtain the new version on your Rainbow or APC, use your present version of KERMIT to transfer the appropriate .CMD file. If you have trouble doing that, then transfer the .H86 file and build a .CMD file from it using GENCMD. If you don't have KERMIT on your Rainbow, read KER:RBKERMIT.HLP for a helpful hint, or follow the installation directions in the KERMIT User Guide. Report any problems directly to me. Thanks to Ron Blanford of the University of Washington and Bernie Eiben at DEC for their contributions to this new release. - Frank da Cruz ------- 8-May-84 17:22:53-EDT,2126;000000000000 Return-Path: <@CUCS20:wouk@BRL-VGR.ARPA> Received: from CUCS20 by CU20B with DECnet; 8 May 84 17:22:47 EDT Received: from BRL-VGR by COLUMBIA-20.ARPA with TCP; 8 May 84 14:14:37 EDT Date: Tue, 8 May 84 14:05:00 EDT From: wouk@BRL-VGR.ARPA Sender: wouk@BRL-VGR.ARPA To: info-kermit@columbia-20.ARPA Dear info-kermit@columbia-20 I have a problem with kermitrb. I have tried to use it at two locations, with the same result. These are unc and brl-vgr. Both locations run UNIX. In both cases I can upload from my Rainbow 100 with no difficulty. However, at both locations, when I try to download, after issuing the command 'kermit sdd >dfile', followed by ^\c and R at my local machine, dfile contains: >>> Debugging level = 2 >>> >>> Send command >>> >>> sendsw state: S >>> spack type: S >>> num: 0 >>> len: 6 >>> data: "~* @*#" >>> sendsw state: S >>> spack type: S >>> num: 0 >>> len: 6 >>> data: "~* @*#" >>> rpack type: R >>> num: 0 >>> len: 7 >>> data: "ABC.TXT" >>> sendsw state: A A local guru at brl-vgr states that my kermit sent the wrong type and data having sent R type and . A correct sequence on my guru's Apple is: >>> Debugging level = 2 >>> >>> Send command >>> >>> sendsw state: S >>> spack type: S >>> num: 0 >>> len: 6 >>> data: "~* @*#" >>> sendsw state: S >>> spack type: S >>> num: 0 >>> len: 6 >>> data: "~* @*#" >>> rpack type: Y >>> num: 0 >>> len: 6 >>> data: "~* @*#" >>> >>> sendsw state: F >>> Opening dfile for sending. >>> spack type: F >>> num: 1 >>> len: 5 >>> data: "DFILE" >>> rpack type: Y >>> num: 1 >>> len: 0 >>> data: "" etc. Can you give me any guidance on this. I can find no option to SET on the implementation of kermitrb which I got from you early in April. I know there is a new kermitrb coming along, but my problem may not be cured there if it has not occurred before. Arthur Wouk wouk@brl-vgr !unc!wouk 8-May-84 17:30:09-EDT,1374;000000000000 Return-Path: <@CUCS20:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from CUCS20 by CU20B with DECnet; 8 May 84 17:30:02 EDT Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 8 May 84 16:04:46 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2630347131184218@MIT-MULTICS.ARPA>; 08 May 1984 15:58:51 edt Date: 07 May 84 15:51 +0200 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Info-Kermit Subject: Bug in KERMIT-800 Message-ID: <54422@QZCOM> There is a bug in KERMIT-800. On line 730: 730 Spsiz=ASCII(S$)-32 : Timint=ASCII(MID$(S$,2,1)) 32 should be subtracted from the last expression: 730 Spsiz=ASCII(S$)-32 : Timint=ASCII(MID$(S$,2,1))-32 Please correct this in your distribution copy of KERMIT-800 (the file is 800KER.BAS). Also, there might be a problem with our version of KERMIT-10, 2(106). When KERMIT-10 is waiting for a init package and times out, it does something wrong. It seems to give a "Kermit-10>" prompter instead of a NAK package. (The problem goes away if you either hurry and fire up your local KERMIT before the default 15 s timeout, or set the timeout in KERMIT-10 to something more reasonable, like 40 seconds). - Per Lindberg QZ - 8-May-84 18:24:27-EDT,613;000000000000 Return-Path: <@CUCS20:PAWKA@NOSC-TECR> Received: from CUCS20 by CU20B with DECnet; 8 May 84 18:24:22 EDT Received: from NOSC-TECR.ARPA by COLUMBIA-20.ARPA with TCP; 8 May 84 18:21:29 EDT Date: 8 May 1984 1510-PST From: Pawka Subject: Getting started To: INFO-KERMIT at COLUMBIA-20 Reply-To: PAWKA at NOSC-TECR A couple of easy questions, I'm trying to implement the VAX/VMS version interfacing with the generic CP/M version: 1) How come VXSERVER.C is empty? 2) Where is CPMGENERI.ASM PLease mail directly as I may not yet be on the list, Mike PAWKA@NOSC-TECR ------ 9-May-84 10:48:34-EDT,615;000000000000 Return-Path: <@CUCS20:PAWKA@NOSC-TECR> Received: from CUCS20 by CU20B with DECnet; 9 May 84 10:48:26 EDT Received: from NOSC-TECR.ARPA by COLUMBIA-20.ARPA with TCP; 9 May 84 10:41:29 EDT Date: 9 May 1984 0730-PST From: Pawka Subject: Getting started To: INFO-KERMIT at COLUMBIA-20 Reply-To: PAWKA at NOSC-TECR A couple of easy questions, I'm trying to implement the VAX/VMS version interfacing with the generic CP/M version: 1) How come VXSERVER.C is empty? 2) Where is CPMGENERI.ASM PLease mail directly as I may not yet be on the list, Mike PAWKA@NOSC-TECR ------ 11-May-84 19:43:58-EDT,1627;000000000000 Return-Path: <@CUCS20:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from CUCS20 by CU20B with DECnet; 11 May 84 19:43:53 EDT Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 11 May 84 19:43:37 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2630618651996240@MIT-MULTICS.ARPA>; 11 May 1984 19:24:11 edt Date: 11 May 84 16:35 +0200 From: Lars_Enderin_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Lars_Enderin_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, KERMIT_implementation_and_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KERMIT_implementation_and_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: Info-Kermit Subject: KERMIT-20 - letting go of the communication line Message-ID: <55091@QZCOM> When using KERMIT-20 to communicate with another host, KERMIT assigns the terminal line being used for the communication. If you leave KERMIT in an orderly fashion (EXIT, BYE), the terminal line will be released, but if you just leave the program with a ^C, the line will be left assigned to you. If you forget about it and leave the job running (possibly detached for a LONG time), nobody without magical powers can use that line, which may be the only one. I suggest that ^C be trapped, and that you should get an opportunity to decide if you want to keep the line assigned, or if the line should be released before you return to the process level above KERMIT. KERMIT-10 does not seem to have the same problem, since it does not ASSIGN the terminal line, just OPENs it. Thus the next RESET will release the line. 13-May-84 19:49:48-EDT,839;000000000000 Return-Path: <@CUCS20:monta@cmu-cs-g.arpa> Received: from CUCS20 by CU20B with DECnet; 13 May 84 19:49:43 EDT Received: from CMU-CS-G.ARPA (not validated) by COLUMBIA-20.ARPA; Sun 13 May 84 19:48:00-EDT Date: Sunday, 13 May 1984 19:41:00 EDT From: Peter.Monta@cmu-cs-g.arpa To: info-kermit@columbia-20.arpa Subject: IBM PC Kermit character ins/del Message-ID: <1984.5.13.23.35.39.Peter.Monta@cmu-cs-g.arpa> Can the character insert/delete parts of the Zenith-19 terminal emulator in IBM-PC Kermit be made faster? Inserting a character at the beginning of a crowded line is considerably slower than 1200 baud---painful when in Unix Emacs, which uses these functions when redisplaying. I'd be willing to do the modifications myself. Help and/or pointers to the relevant code appreciated. Peter Monta (monta@cmu-cs-g) 14-May-84 19:44:14-EDT,837;000000000000 Return-Path: <@CUCS20:LINNEROOTH@SANDIA.ARPA> Received: from CUCS20 by CU20B with DECnet; 14 May 84 19:44:04 EDT Received: from SANDIA.ARPA by COLUMBIA-20.ARPA with TCP; 14 May 84 18:30:59 EDT Date: Mon 14 May 84 16:30:09-MDT From: Tom Linnerooth Subject: IBM PC - VMS link To: info-kermit@COLUMBIA-20.ARPA There is a person here at Sandia who is trying to use KERMIT between an IBM PC and a VAX/VMS system. He asked me to ask the following questions to the KERMIT mailing list: 1. Has anybody implemented VT100 emulation from an IBM PC to VMS? 2. Has anybody successfully uploaded WORDMARC (MUSE) files from an IBM PC to a VMS system with the attributes correctly set? Any information send to me (Linnerooth@SANDIA) will be passed along. Thanks. Tom Linnerooth ------- 15-May-84 07:48:45-EDT,2069;000000000000 Return-Path: <@CUCS20:decvax!mulga!nemeth.uacomsci@Berkeley> Received: from CUCS20 by CU20B with DECnet; 15 May 84 07:48:39 EDT Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; 15 May 84 07:48:20 EDT Received: by UCB-VAX.ARPA (4.24/4.27) id AA19640; Tue, 15 May 84 04:48:15 pdt From: decvax!mulga!nemeth.uacomsci@Berkeley Received: by decvax.UUCP (4.12/1.0) id AA16828; Tue, 15 May 84 07:45:38 edt Message-Id: <8405151145.AA16828@decvax.UUCP> Received: by mulga.OZ (4.3) id AA26204; Mon, 14 May 84 19:02:50 EST Date: Mon, 14 May 84 15:52:00 EST To: info-kermit%columbia-20.arpa.mulga.UUCP@Berkeley Subject: Hello (and other problems...) Hi, This is mainly in the nature of a test transmission, to let you know that Kermit is alive and well at the University of Adelaide. Presently, we are using it on Apple IIs, Vax(VMS), PDP-11 Unix, IBM PC, MedFly(CPM3), Rainbow, Robin, Northstar (CP/M) and DEC-10. We have just received a new tape (via Melbourne Uni.) dated Feb 29, 1984, and are about to upgrade to it. Underway are versions being booted for the Cyber 170 (NOS/BE), DECMate, NEC APC, PDP 11 RSTS, Intel DevSys, PDP 11 Unix, Kaypro, Vax/VMS, Rainbow (CP/M 86), and Sanyo MBC 550(MS/DOS). {some of them are updates} Now to the problems: 1. We DESPERATELY could use a BBC (6502) version; can anybody help? 2. I have personally fixed a number of CRITICAL problems in the Apple 6502 version (I notice it has not changed in the latest release); I am very surprised that nobody has noticed that it does not work...I would be happy to forward the corrected version if you want it. Among other things, conditional code has been added to support other comms cards (Digitek, Super-serial card, Medfly, Mountain CPS multi-function card, and California Comp. Systems serial card), as well as the fixes. 3. Has anybody got a working NOS/BE version? (with some luck, it might even be possible to get a reply in due course -- amazing when you consider the contortions involved!) Cheers, Tom Nemeth 15-May-84 10:38:34-EDT,1160;000000000000 Return-Path: <@CUCS20:knutson@ut-ngp.ARPA> Received: from CUCS20 by CU20B with DECnet; 15 May 84 10:38:24 EDT Received: from ut-ngp.ARPA by COLUMBIA-20.ARPA with TCP; 15 May 84 10:37:18 EDT Date: Tue, 15 May 84 09:38:30 cdt From: knutson@ut-ngp.ARPA Posted-Date: Tue, 15 May 84 09:38:30 cdt Message-Id: <8405151438.AA13427@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/4.22) id AA13427; Tue, 15 May 84 09:38:30 cdt To: allegra!decvax!mulga!nemeth.comsci Subject: Re: Hello (and other problems...) Cc: Info-Kermit@Columbia-20.ARPA There is a NOS/BE version of Kermit ready to go. Ric Anderson of the University of Arizona at Tuscon did the mods to 170KERMIT.FOR and sent them to me to merge. I will be sending a new version to Columbia as soon as I can get everything together. If you are trying to get Kermit-170 Version 1.0 up then I would suggest waiting for this version. It should be much easier to bring up. There is also some development going on at CDC to make some mods to the new version for NOS sites. Jim Knutson ARPA: knutson@ut-ngp UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson Phone: (512) 471-3241 15-May-84 12:29:02-EDT,1073;000000000000 Return-Path: <@CUCS20:SIETZ@RU-GREEN.ARPA> Received: from CUCS20 by CU20B with DECnet; 15 May 84 12:28:46 EDT Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 15 May 84 12:09:38 EDT Received: from RU-GREEN.ARPA by RUTGERS.ARPA with PUP; 15 May 84 12:08:58 EDT Date: 15 May 84 12:10:36 EDT From: Brian Subject: Suggestion for Kermit To: info-kermit@COLUMBIA-20.ARPA Home: 506 Birch Dr. Cherry Hill, NJ. (609) 428-1201 Work: RCA Corp. Moorestown, NJ. (609) 778-6163 I use KERMIT to transfer files between computers whenever possible. However, when I call RCPM bboards, I usually end up using MODEM to do the transfers because most do not support KERMIT. I prefer KERMIT to MODEM however MODEM has one very nice feature which displays the number of packets before completion. This feature is extremely usefull at speeds lower than 1200 baud!!! I am only a user of these programs, so I do not know what it would take to add this feature to KERMIT, but I think it is something to be considered. Brian Sietz ------- 15-May-84 18:15:53-EDT,1614;000000000000 Return-Path: <@CUCS20:kdp@csnet-relay.csnet> Received: from CUCS20 by CU20B with DECnet; 15 May 84 18:15:45 EDT Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 15 May 84 18:14:28 EDT Received: From hp-labs.csnet by csnet-relay; 15 May 84 17:39 EDT Date: Tue, 15 May 84 12:23:58 pdt From: Ken Poulton Received: by HP-VENUS id AA11328; Tue, 15 May 84 12:23:58 pdt Message-Id: <8405151923.AA11328@HP-VENUS> To: info-kermit@csnet-relay.arpa Subject: Software Tools Kermit Cc: ~/kmbox@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. To anyone thinking about doing a kermit for a new machine: I have a Kermit written in Software Tools Ratfor which should run on any machine supporting the Software Tools package. This kermit is essentially a translation of the C kermit, although I have made enhancements since then, notably server mode and binary and repeat encoding. It currently runs on the HP3000 and the Univac 1100. (Columbia-20 has a copy, but you should contact me for the most up to date version.) The Software Tools package is a set of public domain *portable* programmer's utilities written in Ratfor. Software Tools packages exist on most mainframes and minicomputers. (There are also CP/M and MS-DOS packages, but these systems are already well covered by existing Kermits.) To find out about the Tools on your system contact: Software Tools Users Group Nancy Deerinck Lawrence Berekely Lab RTSG-46A Univ of CA Berkeley, CA 94720 (415) 486-6411 0700 to 1800 PDT 16-May-84 03:01:55-EDT,782;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 16 May 84 03:01:03 EDT Date: Tue 15 May 84 20:50:25-EDT From: Nick Bush Subject: Re: Hello (and other problems...) To: decvax!mulga!nemeth.uacomsci@UCB-VAX.ARPA cc: INFO-KERMIT@CUCS20 In-Reply-To: Message from "decvax!mulga!nemeth.uacomsci@Berkeley" of Tue 15 May 84 07:48:38-EDT Some (but probably not all) of the problems in the Apple-DOS version have been fixed in version 2.0, but we would certainly like to know about any problems you have found. One of the major changes in version 2.0 was making the comm card selection at run time. There have been other changes made since version 2.0, but these still need to be integrated into one copy. - Nick ------- 17-May-84 07:41:24-EDT,920;000000000000 Return-Path: <@CUCS20:BRACKENRIDGE@USC-ISIB> Received: from CUCS20 by CU20B with DECnet; 17 May 84 07:41:19 EDT Received: from USC-ISIB by COLUMBIA-20.ARPA with TCP; 16 May 84 15:00:53 EDT Date: 16 May 1984 11:59:40 PDT Subject: Kermit for more than Universities From: Billy To: info-kermit@COLUMBIA-20, info-ibmpc@USC-ISIB Congratulations on some recognition for Kermit at last. I was dismayed to hear that Lotus' new product Symphony, which is supposed to combine data base, with spreadsheet, word processing, and communication capabilities is basing the communications on the Christiansen modem protocol. Those of us with PDP-10s who rely on Kermit's variable packet size appear to be out of luck in this regard. Has anyone seen this product and are interface specifications described such that Kermit could be replaced as the communications portion of Symphony? ------- 17-May-84 08:19:06-EDT,1452;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 17 May 84 08:18:59 EDT Date: Wed 16 May 84 13:27:11-EDT From: Frank da Cruz Subject: Publicity To: Info-Kermit@CUCS20 A two-part article about KERMIT, written by me and Bill Catchings, will appear in the June and July issues of BYTE magazine. The title was to be "KERMIT: A Simple File-Transfer Protocol". However, I just found out that the editors changed the title at the last minute to "KERMIT: A File-Transfer Protocol for Universities" to make it fit better with their June theme, education. The new title is obviously misleading -- KERMIT is for everyone; I've asked them to make some kind of correction to this in the July issue. The article discusses the motivation for KERMIT, problems of asynchronous communication, and presents an overview of the protocol. It was written about a year ago, and may appear out of date in some respects. Shorter articles will appear in forthcoming issues of EDUNET NEWS and DEC's Large Systems News; these talk more about how KERMIT is shared, distributed, etc, and how contributions have been made. Also, an award called the CARROLL showed up unexpectedly on our doorstep from French DECUS; it turned out to be a bottle of champagne and an engraved silver plate, for the best software contribution of 1983-84. So even free software has its compensions... - Frank ------- 17-May-84 08:26:57-EDT,1312;000000000000 Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID> Received: from CUCS20 by CU20B with DECnet; 17 May 84 08:26:51 EDT Received: from USC-ISID by COLUMBIA-20.ARPA with TCP; 16 May 84 21:49:58 EDT Date: 16 May 1984 18:07-EDT Sender: ABN.ISCAMS@USC-ISID Subject: Re: Kermit for more than Universities From: ABN.ISCAMS@USC-ISID To: BRACKENRIDGE@USC-ISIB Cc: info-kermit@COLUMBIA-20, info-ibmpc@USC-ISIB Message-ID: <[USC-ISID]16-May-84 18:07:06.ABN.ISCAMS> In-Reply-To: The message of 16 May 1984 11:59:40 PDT from Billy Billy (et al) You PDP-10 owners aren't the only ones dependent on Kermit's variable packet size. My TAC doesn't seem to want to upload with MDM7nn, despite flow control (probably disabled by NMODEM on my host) -- I think it's also the Christensen packet size overflowing the TAC keyboard buffer. I haven't fought it out yet because of Kermit's packet size flexibility. I just cut uploads down to 64 characters or so, and it works just fine! I don't have Symphony (still in the 8-bit world), but you have a good point. Would be nice to have the alternative, especially with the newly gained Kermit capability to send 8-bit through 7-bit channels! I get awfully tired of HEXIFYing things in some situations. Regards, David Kirschbaum Toad Hall 17-May-84 08:27:21-EDT,584;000000000000 Return-Path: <@CUCS20:POLARIS@USC-ISI> Received: from CUCS20 by CU20B with DECnet; 17 May 84 08:27:15 EDT Received: from USC-ISI by COLUMBIA-20.ARPA with TCP; 17 May 84 08:25:41 EDT Date: 17 May 1984 08:26-EDT Sender: POLARIS@USC-ISI Subject: congrats From: POLARIS@USC-ISI To: info-kermit@COLUMBIA-20 Message-ID: <[USC-ISI]17-May-84 08:26:00.POLARIS> Dear All: Congratulations on your CARROLL award, it is well deserved...KERMIT FOREVER! (Or at least until everyone runs only one kind of machine and operating system). Best Wishes for more KERMITS in the brood. 17-May-84 15:15:48-EDT,1220;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 17 May 84 15:15:36 EDT Date: Thu 17 May 84 13:07:27-EDT From: Frank da Cruz Subject: Info-Kermit To: Info-Kermit@CUCS20 Info-Kermit is not a terribly active mailing list, at least not when you compare it to Info-Micro, Info-CPM, etc. We've averaged something like one message per day since the list was started last August. However, the list is rather large, with more than 200 members (many of which are mailing lists themselves). It takes our poor mailer something like an hour of elapsed time to process an Info-Kermit message. COLUMBIA-20, the Columbia Computer Science Department DECSYSTEM-20 which is host to the Internet KERMIT distribution area and to Info-Kermit, will be undergoing extensive hardware work over the summer, and may be unavailable for periods of time. When it is available, demand for its services will be high, to make up for lost time. Therefore, Info-Kermit mail will no longer be sent automatically to the list membership, but will be redistributed periodically by me, perhaps in digest form. This change will start tomorrow (Friday, May 18). - Frank ------- 18-May-84 04:21:20-EDT,5016;000000000000 Return-Path: <@CUCS20:decvax!mulga!nemeth.uacomsci@Berkeley> Received: from CUCS20 by CU20B with DECnet; 18 May 84 04:21:11 EDT Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; 18 May 84 04:20:11 EDT Received: by UCB-VAX.ARPA (4.24/4.27) id AA29982; Fri, 18 May 84 01:19:31 pdt From: decvax!mulga!nemeth.uacomsci@Berkeley Received: by decvax.UUCP (4.12/1.0) id AA16072; Fri, 18 May 84 04:08:17 edt Message-Id: <8405180808.AA16072@decvax.UUCP> Received: by mulga.OZ (4.3) id AA03543; Fri, 18 May 84 10:15:43 EST Date: Thu, 17 May 84 15:37:00 EST To: info-kermit%columbia-20.arpa.mulga.UUCP@Berkeley Subject: Apple Kermit patches To (would-be) Apple (6502) Kermit users: The following is a detailed list of problems I have corrected in the Apple Kermit (as on the Feb 29, 1984 release tape); due to lack of a suitable means of accurately transmitting the source code, I have removed the pieces which are relevant. In practice, I did not reassemble the code, but patched the binary ON THE APPLE; included in the following are the patches applicable to (either the Hayes DC Modem or the old Apple serial card) Apple Kermit. {Note: To do this, boot the Apple, then BLOAD KERMIT (or whatever), and enter the monitor by CALL-151 then put in the patches as below (*aaaa:cc cc cc ....) and finally BSAVE KERMIT(NEW),A$800,L$3640 now you can BRUN KERMIT(NEW) } ; ; 1A By: Thomas A. Nemeth, Adelaide University. ; Add options to support other common serial interface ; cards: CPS, SSC, CCS(&Digitek) & Medfly with all of their ; perversities. ;{I have omitted all except the SSC; others available on request} ;*16c2:e0 3d {jump to init routine} ;*3de0:20 00 c2 20 c8 16 60 {init SSC} ;*17d0:ad 89 c0 {status} ;*17d4:08 {rx rdy mask} ;*17df:ad 88 c0 {data in} ;*180c:ad 89 c0 {status} ;*1810:10 {tx rdy mask} ;*1814:8d 88 c0 {data out} ; ; 7A By: Thomas A. Nemeth, Adelaide University On: 11-JAN-1984 ; Fix typing error in above, causing garbage at ; end of transmitted file names (server). ;*1ed1:c9 {should have been \#hspace !!} ; 10 By: Thomas A. Nemeth On: 18-JAN-1894 ; Create a cursor in connect mode (cheap & nasty, but works) ;*17c7:20 17 3e ;*1803:20 17 3e ;*3e17:aa 20 9c fc 8a 09 80 20 ed fd a9 df 20 ed fd 20 10 fc 60 ;(3e2a) ; ; 11 By: Thomas A. Nemeth On: 18-JAN-1984 ; Delete at start of file; there is an implied ; at the start. ;*198d:20 10 3e ;*3e10:8d 02 15 8d 12 15 60 ; ; 12 By: Thomas A. Nemeth On: 18-JAN-1984 ; On flushing the disk buffer (RECEIVE), indicate it ; has been emptied. Also, get correct error status (missing code) ;*2c25:20 04 3e ;*3e04:20 06 ab a9 00 8d 4f 15 ad c5 b5 60 ;(3e10) ; ; 13 By: Thomas A. Nemeth On: 18-JAN-1984 ; Must only check quoting of 8-bit-quote character ; if 8-bit quoting is ON (BUFILL & BUFEMP) {symptom: loses N-s) ;*2cd0:20 f6 3d ;*3df6:ad 0a 15 c9 01 d0 06 ad 17 15 cd 41 15 60 ;(3e04) ; ; 14 By: Thomas A. Nemeth On: 18-JAN-1984 ; Fix typing error which caused error on file close. ; {compunded with [12]} ;*1d53:1f ; ; 15 By: Thomas A. Nemeth On: 27-JAN-1984 ; Checksum error (failure return from RPAK) is NEVER ; checked if packet sequence number is correct!!!!!! (8 places) ;*3e2a:20 65 28 8d fc 14 c9 00 d0 01 60 4c 82 12 ;(3e38) ;*1a31:20 2a 3e 4c 55 1a ;*1ad4:20 2a 3e 4c 0d 1b ;*1c29:20 2a 3e 4c 5b 1c ;*1e2c:20 2a 3e 4c 60 1e ;*1eee:20 2a 3e 4c 23 1f ;*1f81:20 2a 3e 4c b5 1f ;*2029:20 2a 3e 4c 4f 20 ;*20ac:20 2a 3e 4c e0 20 ; ; 16 By: Thomas A. Nemeth On: 01-FEB-1984 ; Fix error in FGETC, causing it to lose the last ; character of every disk buffer (but I still don't ; understand why EVERY disk read returns EOD status). ;*2e6e:ad b5 c1 8d 50 15 a9 00 8d 4f 15 That's all folks! I hope this is not garbled too much in transit; the whole thing should take no more than about 15-20 mins to patch on an Apple (even though it looks, and IS extremely grotty); and as I said before, it is amazing that it ran at all! I will be happy to send you the source code, although any self-respecting 6502 freak should be able to recreate it from the above. Please don't send any suggestions to me, but to the author of the original code (the above was done under sufferance!); all I can say is that it seems to work now. Tom Nemeth 23-May-84 18:58:43-EDT,9663;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 May 84 18:58:24 EDT Date: Wed 23 May 84 18:59:04-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #1 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 23 May 1984 Volume 1 : Number 1 Today's topics: Info about Info-Kermit New Release of LCTERM for Rainbow MS DOS New Implementation of KERMIT for MUMPS on PDP-11 New Implementation of KERMIT for IBM PC under UCSD p-System Hayes internal modem question UCSD Pascal Kermit for Apple? KERMIT Enhancement -- Changing Filenames ------------------------------------------------------------------------------- Date: Wed 23 May 84 12:04:05-EDT From: Frank da Cruz To: Info-Kermit Subject: Info About Info-Kermit Because of the need to reduce the load on the Columbia University Computer Science Department DEC-20 (COLUMBIA-20) during a period of heavy use and hardware & software development, Info-Kermit will be run as a digest for the next couple months. This is the first issue. Another policy that ARPAnet users should be aware of is the recent restriction on anonymous FTP at COLUMBIA-20, imposed for the same reasons. Anonymous FTP logins are not allowed between the hours of 6:00am and 6:00pm eastern time, weekdays, but are permitted outside these hours. A reminder about how to get KERMIT. For ARPAnet/Internet sites, connect to host COLUMBIA-20, login as user ANONYMOUS with any non-null password. For CCnet (DECnet) sites, use NFT to host CU20B; depending upon the arrangements between Columbia and your site, you may be able to access the files specifying user ANONYMOUS; otherwise contact your system manager. In both cases, all the KERMIT files are in PS:, which you can also refer to using the logical device name KER:. The file KER:00README.TXT contains information on what files are in the KERMIT distribution area and how to find them. One file worth checking from time to time is KER:CURRENT.DOC, a brief tabular listing of each existing version of KERMIT, showing the version number and date of the latest release of each version. KERMIT network distribution is also available to users of BITNET through a server called KERMSRV set up at host CUVMA, an IBM system at Columbia. To get started with KERMSRV, type the following command on your own BITnet host: SMSG RSCS MSG CUVMA KERMSRV HELP For those who cannot obtain KERMIT files over these networks, there remain the DECUS, SHARE, STUG and other user group tapes, various PC or micro floppy distribution services, and Columbia itself will send out tapes for a distribution fee (our tape service is described in KER:FLYER.DOC). Archives of Info-Kermit are in KER:MAIL.*. The messages up to March 8, 1984 are in KER:MAIL.83A. Those from March 8 to May 18 (the last "direct mail" activity) are in KER:MAIL.83B. The current mail (starting with this issue of the digest) are in KER:MAIL.TXT. - Frank ----------------------- Date: Wed 23 May 84 12:04:05-EDT From: Frank da Cruz To: Info-Kermit Subject: New LCTERM for Rainbow MS DOS Version 2.14 of Larry Campbell's LCTERM multi-protocol (including KERMIT and XMODEM) communication program for the DEC Rainbow under MS DOS 2.05 or later is now available. There are many fixes since the last release, and enhancements including a session script facility. The program is available via anonymous FTP from COLUMBIA-20 (ARPANET, only outside of peak hours), or NFT from CU20B (DECNET/CCNET), as KER:RBLCTERM.*. RBLCTERM.EXE is the executable program, in MS-DOS binary format. RBLCTERM.C is the source (actually this file contains the concatenation of various C and ASM86 source files). Installation instructions are in KER:RBLCTERM.HLP. Documentation is in KER:RBLCTERM.DOC. Various other files are also included, including a .BWR file that lists some bugs & restrictions. Since there is no "printable" object module, such as the .HEX or .H86 files of CP/M, or the .FIX file provided with MS DOS (IBM PC) Kermit, you should read the .HLP file before attempting to download LCTERM for the first time. By the way, there will also be a version of Columbia's MS DOS Kermit for the Rainbow, which will appear as part of the next MS DOS Kermit release within the next few weeks. ----------------------- Date: Wed 23 May 84 12:04:05-EDT From: Frank da Cruz To: Info-Kermit Subject: New Implementation of KERMIT for MUMPS-11 Kermit-M is a version of Kermit that is written in 1982 ANSI Standard MUMPS, by David Rossiter of the New York State College of Veterinary Medicine, Veterinary Computing Facility. This version is designed for PDP-11 computers running InterSystem's M/11 operating system (version 5), but instructions are provided for converting to other machines or MUMPS implementations. The files may be found in the KERMIT distribution area as KER:MPKERMIT.*. Some of these files have very long "lines" (over 200 characters), which are apparently unavoidable in the MUMPS language. Thanks to Kate MacGregor of Cornell University for contributing this Kermit implementation through BITNET. ----------------------- Date: Wed 23 May 84 12:04:05-EDT From: Frank da Cruz To: Info-Kermit Subject: New Implementation of KERMIT for IBM PC under UCSD p-System This implementation of KERMIT for the IBM PC p-System was submitted by Kate MacGregor and Steve Pacenka of Cornell University Computing Services. It requires version IV.x of the UCSD p-System, and is also intended to be transferrable to other computers that run the same level of the p-System. It was developed on the IBM PC using NCI release C1F. The files are in KER:UCIBMPC.*. The Pascal source files are concatenated together into the file KER:UCIBMPC.PAS; there are also .DOC and .HLP files. The other UCSD Pascal Kermit from Cornell (the one for the Terak) has been reorganized along similar lines, as KER:UCTERAK.*. ----------------------- Date: Tue 22 May 84 12:04:05-EDT From: Alan Crosswell Subject: Hayes internal modem question. To: info-ibmpc@USC-ISIB.ARPA, info-kermit@CUCS20 I would appreciate it if somebody who has the Hayes internal modem or who looked at one and decided against it would let me know what your experience has been with it. I have heard a rumor that it is unreliable. Is this true? Is it worth the price difference to get the internal modem instead of an async card and external one? The professor who is looking is absolutely convinced that he will never want to attach to an RS232 line but will always use a telephone from his home. Alan Crosswell User Services Columbia University Center for Computing Activities [Editor's note: I don't know if the Hayes modem is good or bad, but there are several good reasons for avoiding internal modems in general: . They take up a slot that might be otherwise put to better use . They can't be easily used on other PCs . They can't be used at all on different kinds of micros . They tend to confuse and/or complicate communication software, like KERMIT People interested in using KERMIT- or MODEM-like programs for transferring files should avoid internal modems.] ----------------------- Date: Tue 22 May 84 18:06:05-PDT From: Bruce Tanner Subject: Apple Pascal Kermit? To: INFO-KERMIT@COLUMBIA-20.ARPA I see from VERSIONS.DOC that there are several UCSD p-system Kermits around, but none for the Apple. Is there one available? Thanks, -Bruce [Not to my knowledge. But see the above announcement for a UCSD Pascal Kermit for the IBM PC. There are now at least three versions -- IBM PC, Terak, HP-98x6 -- to use as a basis. Any volunteers? - Frank] ----------------------- Date: Wed 23 May 84 15:20:05-EDT From: Dave Weaver Subject: KERMIT Enhancment To: cc.fdc@COLUMBIA-20.ARPA I would like to see all flavors of KERMIT offer an option to the RECEIVE or GET commands to output to a file spec other than the same one as you are receiving. Not only would this help with file name length problems, but it would be a valuable asset on VAX systems with DECnet, because one could "RECEIVE" a file to a different node. Something like: Kermit-32> get FILE.EXT NODE"user password"::FILE.EXT and: Kermit-80> get TOPS20_LONG_FILE_NAME.EXTENSION FILE.EXT The latter is because TOPS20 supports long file names and it would be nice to be able to copy them without first copying them to some shorter named file. In the former example I could be talking to a 20 from a VAX which is a DECnet node, but I would like to copy the file to another node other than the one I am running KERMIT from. -Dave [Heartily endorsed. In fact, the Kermit Protocol Manual recommends this; see section 9.1 of the 5th edition. Not many implementations support all these options; KERMIT-20, for instance lets you send FOO (AS) BAR, but not GET FOO (AS) BAR. This should be fixed. But note that there's always the problem of delimitation -- some systems (ITS, VM/CMS) have filenames with imbedded spaces. FTP takes care of this by having you type the source and destination filespecs on separate lines. - Frank] ------- 26-May-84 15:45:29-EDT,6067;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 26 May 84 15:45:14 EDT Date: Fri 25 May 84 20:28:43-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #2 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Friday, 25 May 1984 Volume 1 : Number 2 Today's Topics: Info-Kermit Digest Format Kermit at DECUS Kermit on Cyber Machines (2 messages) Kermit on Epson QX10? Kermit Enhancement - renaming files in get and send ---------------------------------------------------------------------- To: Info-Kermit Date: Friday, 25 May 1984 8:04pm-EST From: Frank da Cruz To: Info-Kermit Subject: Info-Kermit Digest Format There were a few complaints about the format of the first issue of the new Info-Kermit digest. Various digest digesters complained of indigestion. This issue should be better -- the dashed separators are the "right length", there are some asterisks at the end, tabs removed, etc. Let me know of any further problems. ------------------------------ Date: Friday, 25 May 1984 8:04pm-EST From: Frank da Cruz To: Info-Kermit Subject: Kermit at DECUS The new KERMIT releases that were announced in the last issue (UCSD, MUMPS), this issue (Cyber 170), and the next issue (most likely VAX/VMS, TOPS-10, and Professional-350) will be available at Spring DECUS. Brian Nelson will probably be bringing new releases of his PDP-11 Kermit for RSX, RSTS, and maybe RT-11. Attempts will be made to bring all these last-minute releases together into a coherent collection for the various SIG tapes (particularly VMS and RSX), and to make them available on whatever machines are provided by DEC for people to make their own copies. If you need any of these new releases and you're going to DECUS, you might want to bring along a tape (a 2400' reel -- the entire KERMIT distrubution won't fit on anything smaller), as well as some floppies for the Rainbow and Pro-350 versions. This will save you the trouble of FTP'ing a large amount of data over the net, or sending for a tape if you don't have FTP access, as well as avoiding cumbersome bootstrapping procedures for first-time users of Rainbow and Pro Kermit. I'm not going to DECUS myself, but I understand a KERMIT session has been set up for Friday (when most people have left). ------------------------------ Date: Fri, 25 May 84 13:24:38 cdt From: knutson@ut-ngp.ARPA To: cc.fdc@columbia-20.ARPA Subject: New Cyber Kermit You can get the source for the new Cyber Kermit via anonymous ftp to ut-ngp. The files you need are 170kermit.for and 170azlib.asm. These two files should replace the current 170kermit.for. The following are a list of changes made: Version 2.0 - File name packets send uppercase file names, Error packets now handled correctly, modified character tables for CDC 63 and 64 character sets, merged Ric Anderson's NOS/BE code, added push and ! commands, added read delay for performance tuning, changed binary data-mode to ignore NEL characters, OVCAP or SEGLOAD version can be produced, reduced field length. Note that this version now truly supports NOS/BE (aside from differences in front-ends). Ric Anderson of the University of Arizona at Tuscon deserves credit for this. I'll hopefully have a true NOS version in a couple of months. Keep up the good work, Jim Knutson ARPA: knutson@ut-ngp UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson Phone: (512) 471-3241 [Ed Note -- The new files are in KER:170*.* on COLUMBIA-20, available via anonymous FTP in the usual manner. Note that a good deal of the Fortran code of the previous release has been replaced by assembler. Also, there doesn't seem to be any new documentation beyond what's been said above, but then maybe none is necessary.] ------------------------------ Date: Fri, 25 May 84 10:11:04 EST From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers) To: cc.fdc@columbia-20.ARPA Subject: Kermit on Cyber Machines You might be interested to know that one of my colleagues has modified Kermit-170 (Cyber) to run on the 815 - we'll send you a copy when it's been more thoroughly tested. Our 815 runs NOS 2.2, by the way, and Darryl Chivers (the one doing the job) also plans a NOS/BE version for the 730, but that's further off. - Steve Withers, University of Melbourne [Let's hope the different Cyber versions will get back together one day... - Ed.] ------------------------------ Date: Wed, 23 May 84 To: info-kermit@columbia-20 Subject: Kermit on QX10 From: fenchel@wisc-rsch.arpa Has anyone brought kermit up on the Epson QX10? Bob Fenchel [Not to my knowledge. Anyone else heard anything? - Ed.] ------------------------------ Date: Thu, 24 May 84 10:31:20 pdt From: Ken Poulton To: info-kermit@csnet-relay.arpa Subject: Kermit Enhancement - renaming files in get and send I agree with the need. I found kermit-20's "send .. (as) .." so handy that I implemented it for Tools and Unix Kermits. Doing the same for Get would be nice, too. [Ed note -- Ken is the author of the Software Tools Kermit, written in Ratfor.] A note on syntax: I chose to allow Send to take any number of files (possibly wildcarded); any filename followed with "-as" is sent with the word following the "-as" as the name. Obviously, you don't want to mix wildcards with "-as", but the "-as" needn't restrict you to one file at a time. In my opinion, files with spaces in their names are a pathological case: try to provide a mechanism to deal with them, but don't restrict your syntax (one file per line) because of them. ------------------------------ End of Info-Kermit Digest ************************* ------- 30-May-84 19:11:31-EDT,8442;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 30 May 84 19:11:07 EDT Date: Wed 30 May 84 19:06:46-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #3 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 30 May 1984 Volume 1 : Number 3 Today's Topics: KERMIT for TRS-80 I and III with TRSDOS New Release of DEC-20 KERMIT DEC Pro-350 & IBM PC Kermit Queries KERMIT for Commodore-64 Underway Fix for Kermit-80 V3.9 ---------------------------------------------------------------------- Date: Mon, 28 May 84 16:55:55 CDT From: Stan Hanks Subject: TRS-80 Kermit To: Frank da Cruz Cc: Stan Barber Frank, Stan Barber has finally completed the TRS80 version of Kermit. Included is all of the source, plus a BASIC program that, when executed, will generate a correct binary. The manual entry for the user's guide is also present. This implementation of the Kermit is written in Z80 Assembler, compatible with M80 and EDAS from Mysosys. It runs under all DOS's available for the TRS80 Model I or Model III (and the Model 4 running in Model III mode). It has been checked out under the following DOS's: TRSDOS 2.3 (Model I), TRSDOS 1.3 (Model III), NEWDOS/80 V 2.0, LDOS 5.1.3, DOS+ 3.5 and VTOS 3.0 (Model I). Stan Hanks [Ed. Note: The files have been renamed for grouping together in the KERMIT distribution as KER:TRS*.*. The file KER:TRSMIT.HLP contains the correspondence between the real names and distribution names. The file KER:TRSMAKE.BAS is a Basic program that generates the executable binary, and KER:TRSMIT.DOC is the KERMIT User Guide manual chapter for this version. All available from COLUMBIA-20 or CU20B in the normal manner.] ------------------------------ Date: Wed 30 May 84 16:47:28-EDT From: Frank da Cruz To: Info-Kermit Subject: New Release of DEC-20 KERMIT There is a new release of KERMIT-20 for the DECSYSTEM-20, 4(222), which fixes a couple bugs in the previous release, 4(215), and should replace that version (or any earlier version). The changes since edit 215 include: Fix FILE NAMING NORMAL-FORM (it was broken in the previous release). . Fix problem with two consecutive ~ chars in data when doing compression. . Don't create empty debugging log files. . Change SET DEBUGGING LOG to LOG DEBUGGING, like other KERMITs. . Add SET FLOW-CONTROL to allow explicit enable/disable of XON/XOFF. . Add SET EXPUNGE to allow enable/disable of automatic expunge on DELETE. . Make LOCAL prefix optional on LOCAL commands like LOCAL DELETE, etc. . Add LOCAL TYPE, LOCAL RUN. . Change LOCAL/REMOTE DISK to LOCAL/REMOTE SPACE, like other KERMITs. . Add code to believe remote TTY line speed under TOPS-20 6.0. . Miscellaneous minor bugs fixed. The new release is in KER:20KERMIT.* on COLUMBIA-20 or CU20B. The file suffixes include: .EXE - The executable program .MAC - The MACRO-20 program source file .UPD - The program update history .DOC - A new KERMIT User Guide chapter for KERMIT-20 .MSS - The Scribe source file for the manual chapter .INI - A sample KERMIT.INI file ------------------------------ Date: 28 May 84 19:02:01 EDT From: Chris Koenigsberg To: To: info-kermit-request@CUCS20 Subject: DEC PRO 350 and IBM PC KERMIT Hello, I am a staff technologist here at CMU's School of Urban and Public Affairs, where they have given us 50 DEC PRO 350 personal computers to play with. I wonder if anyone has successfully assembled a Kermit to run on these beasts. Thanks for all the good work you have done. Chris Koenigsberg Urban Systems Institute CMU SUPA MMC204 (412)578-2175 [Ed. Note -- At least two versions of KERMIT for the Pro-350 have been done; one by Bob Denny of DECUS C fame, and the other by Stevens Institute of Technology. The Stevens version will be released this week or next week, and will be presented at DECUS.] p.s. Is there a new version of the Kermit-86 for the IBM running PC-DOS?? Around here everyone uses version 1.19 or 1.19A....1.19 gets hung up a lot when running things like Emacs on the host, and 1.19A is the "brain-damaged" version which they once thought would eliminate the overloading of the TOPS20 front end by drastically cutting the speed with which packets are sent during uploads. (They were wrong, the front end still gets overloaded, and lots of people are using this brain-damaged very slow upload for absolutely no reason!!) [Ed. Note - Columbia is working on a new release of MS DOS KERMIT, far advanced over the current release, which is 1.20. It should be ready within a couple weeks (I've been saying this for months, but this time I really mean it...). The new version has much improved terminal emulation, particularly in the character insert/delete area. The special CMU customization for slowing things down, pausing between packets, etc, has never proven to be necessary at any other site that I know about, and is probably an artifact of some system modifications.] ------------------------------ Date: 30 May 84 16:43:26 EDT From: Eric Subject: C64 Kermit To: cc.fdc@COLUMBIA-20.ARPA Hi Frank, Many of us C64 owners are distraught at the lack of a good public domain communication/file transfer program like Kermit. We are also distraught at the lack of attention Columbia has decided to give to the project of writing Kermit for this machine. Therefore, I have decided to start the project myself. At present the VT52 emulation is complete, and was written by Frank Prindle (Prindle@NADC) and myself. The remainder of Kermit will be written by me, and later some will be done with the help of Brian Beattie (Beattie@mitre-gateway). If anyone up there has already started to write anything, or formulate some ideas as how to approach the project on the C64, we would like to hear from them. I will keep you posted as to our progress. By the way, we will be writing it in Commodores' Macro Assembler and maintaining a working copy in Cross format. Due to various time restrictions, I don't expect the project to be near completion till the end of the summer. Eric Lavitsky (Lavitsky@Rutgers) [Ed. Note - Good for you! I wish we had been able to do it. We announced our intention to do C64 Kermit because one of our departments had decided to require its students to buy C64s. We even went so far as to buy one ourselves to do the work on. But the project never bubbled up high enough on our priority list to actually get started, what with the MS DOS, CP/M, DEC-20, IBM VM/CMS, Unix, Macintosh, and other implementations that were more important to larger numbers of Columbia users. Good luck!] ------------------------------ Date: 29 May 1984 0242-PDT From: Charles Carvalho Subject: Fix for Kermit-80 V3.9 To: CC.FDC at COLUMBIA-20 Kermit-80 v3.9 will always prefix all &'s in the data with #'s. This should only be done if 8th-bit prefixing has been requested. This problem will only be seen when the other Kermit does not request (or permit) 8th-bit quoting, since Kermit-80 always agrees to use 8th-bit quoting. To fix it, replace the following three lines between gtch4a: and gtch4b:. lxi h,qbchr ;[jd] point to 8-bit quote char cmp m ;[jd] is it our quote character? jz gtch4b ;[jd] yes, have to quote it... with: lda quot8 ; Are we doing 8th-bit quoting? ora a jz gtch4c ; if not, skip test and restore char. lda qbchr ; get 8th-bit quote character cmp d ; same as current character? jz gtch4b ; yes, have to quote it... gtch4c: mov a,d ; no. get character back again. [Ed. Note - This fix will appear in the next release of CP/M-80 Kermit, which Charles is preparing. It will include other fixes, various improvements, but most important it will have the long heralded modular reorganization. Anyone with items to add or fix in KERMIT-80 3.9 should hold off until this new release appears.] ------------------------------ End of Info-Kermit Digest ************************* ------- 1-Jun-84 17:32:10-EDT,9297;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 1 Jun 84 17:31:47 EDT Date: Fri 1 Jun 84 17:30:12-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #4 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Friday, 1 June 1984 Volume 1 : Number 4 Today's Topics: Several Major New KERMIT Releases DEC VAX/VMS KERMIT 3.0.051 DEC TOPS-10 KERMIT 3(124) DEC Professional-350 KERMIT 1.0 Commercial KERMIT Guidelines ---------------------------------------------------------------------- Date: Fri 1 Jun 84 13:15:33-EDT From: Frank da Cruz Subject: Several Major New KERMIT Releases To: Info-Kermit Nick Bush and Bob McQueen of Stevens Institute of Technology have released several new KERMITs. New versions of VAX/VMS and TOPS-10 KERMIT include major improvements in server operation and other areas. And there is an entirely new implementation of KERMIT for the DEC Pro-350. These are described in the next three messages. The three new Stevens KERMITs share their system-independent portions, which are generated from common modules written in BLISS, DEC's "implementation Language". Therefore, the descriptions and capabilities of these three programs will be very similar. It should be noted that you don't need to have BLISS in order to run these programs. MACRO source files are generated from the BLISS for the PDP-10, VAX, and Pro-350, and hexified binaries are also supplied in some cases. The KERMIT User Guide chapters for these systems are not quite ready, but should be available soon. Since the files for the Pro-350 all begin with the prefix "PRO", the KERMIT Protocol Manual files have been renamed from KER:PROTO.* to KER:KPROTO.*, and the User Guide from KER:USER.* to KER:KUSER.*, so that the two appear together (at the end of the K's) in the distribution area directory listing. These three KERMIT implementations, along with the TOPS-20 and other recent releases, will be available at the DECUS symposium in Cincinnati next week on VAX/VMS and DEC-10/20 systems, so if you're attending, you might want to bring a tape along. In addition, new releases for RSX-11/M, RSTS/E, and RT-11 will be arriving at DECUS in time to be included. All of these will also find their way onto the TOPS-10/20, VMS, and RSX DECUS SIG tapes. Meanwhile, the new files are all available in the usual manner using FTP (ARPANET) or NFT (DECNET) or, after the files are moved, KERMSRV (BITNET). ------------------------------ Date: Fri 1 Jun 84 13:33:45-EDT From: Nick Bush Subject: DEC VAX/VMS KERMIT 3.0.051 To: Info-Kermit New features and changes in VAX/VMS Kermit-32 3.0.051 are listed in detail in the file KER:VMSV3.MEM. Here is a brief summary: . "SET PROMPT xxx". . When running as a user Kermit (i.e., talking to a server), it is possible to access all of the generic command functions (REMOTE commands) that were specified in edition 4 of the protocol manual. . Improved local-mode operation (e.g. when dialed out over an autodialer); better performance, ^A status reports, ^D debugging toggle. . Logical name KER$COMM queried for default line at startup. . Kermit-32 will now type out its version number when it starts up. . Problems with IBM host communication have been fixed. . The file processing should now handle sending any type of file. Previously, VFC format files did not work, and certain records from PRN or FTN format files would cause infinite loops. . The format in which ASCII files are sent has been changed to correspond with both the protocol manual and everyone's expectations (instead of the way VMS defines things). Each record from a file with implied CRLF's will be followed by a CRLF, not preceded by a LF and followed by a CR as VMS claims the records are supposed to be. . Kermit-32 will only abort a transfer on the controlling terminal line if two control-Y's are seen in sucession (without any other character or timeout in between). This will keep a single glitch of a control-Y from killing a transfer. . There is a new file type - FIX. This will cause Kermit-32 to create a 512 byte fixed record length file. This is useful for transferring .EXE or .TSK files. . The SET FILE_TYPE command has been changed to SET FILE TYPE. This change was to allow for the addition of the SET FILE NAMING command (FULL, NORMAL_FORM, UNTRANSLATED). . Parity problems fixed. . The GET and RECEIVE commands are now different. RECEIVE now allows the user to give the name into which the file is to be received. This is the same as the RECEIVE command in Kermit-10 and Kermit-20, and conforms to the "standard" format for Kermit commands. . All messages output from the CONNECT command are identified by the node name of the system Kermit-32 is running on (the translation of SYS$NODE, if any). . Some new server functions have been added, some by spawning suprocesses with DCL commands. The new functions includ COPY, CWD, DELETE, HELP, HOST, RENAME, SEND (a terminal message), SPACE (query), TYPE, WHO (show system). . The LOG command has been added to support log files for SESSION, TRANSACTION, and DEBUG. . There is now a PUSH command to spawn a new sub-process. . Sites which wish to enforce restrictions on the files which may be transferred with Kermit can now supply a routine which will validate a file specification. The file KER:VMSV3.MEM gives greater detail about the new release, and lists the component files and their functions. ------------------------------ Date: Fri 1 Jun 84 13:33:45-EDT From: Nick Bush Subject: DEC TOPS-10 KERMIT 3(124) To: Info-Kermit New features and changes in Kermit-10 version 3(124) are detailed in the file KER:K10V3.MEM. Many of them parallel the new VMS KERMIT. A few major changes are: . KERMIT-10 can now run on KI10 processors, KL-only instructions removed. . Correct operation on non-network (ANF-10) systems. . Server can do CWD, DELETE, DIRECTORY, HELP, SPACE, STATUS, and TYPE. . During local operation, send full range of commands to remote server. . Improved local operation. . TAKE command added. . DEFINE for SET macros as in KERMIT-20. . SET FILE BYTESIZE, NAMING, WARNING. . LOG SESSION, TRANSACTION, DEBUG . SET PROMPT . Bugs in wildcard processing fixed. The new files are in KER:K10*.*. KER:K10V3.MEM explains which files are which. ------------------------------ Date: Fri 1 Jun 84 13:33:45-EDT From: Nick Bush Subject: DEC Professional-350 KERMIT 1.0 To: Info-Kermit Announcing the first release of KERMIT for the DEC Professional-350 PDP-11 based microcomputer running P/OS. This version is based on the Common BLISS modules that are used in Kermit-10 and VAX Kermit, so contains most of the functionality of Kermit-10 and VAX Kermit. The user interface is menu driven in the P/OS style. Pro/Kermit is not dependent on any Digital product to do the communications, so Pro/Communications is not required to run Pro/Kermit. The following functionality is currently implemented in Pro/Kermit: CONNECT (to host) . GET (files from server) . SEND (files) . Commands for servers: LOGOUT, FINISH, BYE, TYPE, DIRECTORY, DISK (space), CHANGE (cwd), STATUS, HELP, HOST, COPY, RENAME, WHO . Server operation: sends & receives files, honors remote commands like TYPE, FINISH/LOGOUT, etc. . P/OS Services - Enter various P/OS services from Kermit. These are the various services found in the main menu of P/OS. . SET commands. A full range of parameter setting is provided. The files are in KER:PRO*.*. KER:PROV1.MEM lists the files in detail, including the files that are necessary in the bootstrapping procedure for getting Pro-350 KERMIT initially from a mainframe to the Pro. [Ed. Note - There is also a version of KERMIT for the P/OS, written in DECUS C by Bob Denny. We do not yet have this program in distributable form. Presumably the Stevens hexification & downloading procedures can be applied to that program too.] [Another note - Venturcom's Venix operating system will soon be announced for the Pro-350. Unix KERMIT runs adequately on that system, but performance is very poor. A new Unix KERMIT specially tailored for the Pro-350 with Venix will be announced shortly.] ------------------------------ Date: Thu 31 May 84 19:42:28-EDT From: Frank da Cruz Subject: Commercial KERMIT Guidelines To: Info-Kermit@CUCS20 I've been getting a lot of requests lately from hardware and software vendors for permission to include KERMIT in their products. I've written a new flyer which I'm sending in response to these queries. It's in KER:COMMER.DOC in case anyone is interested in looking at it. ------------------------------ End of Info-Kermit Digest ************************* ------- 11-Jun-84 18:44:03-EDT,7483;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 11 Jun 84 18:43:15 EDT Date: Mon 11 Jun 84 18:39:36-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #5 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 11 June 1984 Volume 1 : Number 5 Today's Topics: Cray-1 Kermit Progress Report Bug fixed in CP/M-80 Kermit 3.9 IBM-PC DOS Kermit Terminal Emulation Cyber Kermit Document File TRS-80 Kermit File Problems Macintosh Kermit No-Progess Report ---------------------------------------------------------------------- Date: 1 Jun 1984 21:09:40-MDT From: Leah F. Miller C-10 To: cc.fdc@columbia-20 Subject: Cray Kermit Thanks for putting me in touch with Lila Chase at Livermore. We have agreed that they will give our Cray Kermit (LANL's) a friendly user tryout, probably next month. They were attempting to port NOS Kermit to the Cray and finding it difficult because of the very different character handling capabilities of the 2 machines. In return for this, we get the benefit of their experience with Unix Kermit on the SUN PC. If all goes well, I expect to put Cray Kermit on general release in late summer, at which time it will have been tested in communication with at least 2 other Kermits. ------------------------------ Date: Wed 6 Jun 84 16:41:54-EDT From: Frank da Cruz Subject: Bug fixed in CP/M-80 Kermit 3.9 To: Info-Kermit@CUCS20 CP/M Kermit 3.9 has a serious bug. When connected to another Kermit (such as VAX/VMS or DEC-20 Kermit) that agrees to do 8th-bit quoting, but does not explicitly request it (which is the normal case on communication lines where the parity bit is not used), any ampersand in an outbound file will have a spurious pound sign inserted before it. A fix for this problem was posted in a recent Info-Kermit digest by Charles Carvalho of ACC. That fix has been installed in Kermit-80, and new .HEX files have been built for most of the systems supported by Kermit-80. The fixed version is called 3.9A and the new files are in: KER:CPMBASE.M80 Source file KER:CPMBASE.UPD Update history KER:CPMKERMIT.BWR "Beware" file KER:CPM*.HEX New hex files, e.g. CPMKAYPRO.HEX, CPMAPPLE.HEX These files are available in the usual manner from COLUMBIA-20 (ARPAnet) or CU20B (DECnet). Kermit-80 3.9A is a stopgap release until the new modularized version 4 is released by Charles Carvalho. ------------------------------ Date: 10 Jun 84 13:46:42 EDT From: D. M. Rosenblum Subject: IBM-PC DOS KERMIT TERMINAL EMULATION To: INFO-KERMIT@CUCS20 When I run IBM-PC Kermit version 1.19 (or C-MU's 1.19A) under DOS 2.0, I tell the DEC-20 that I am talking to that my terminal type is VT52. This works fine. Some of my friends here tell me that I can tell the 20 that my terminal type is Zenith-19 (what you call H19 at Columbia), and I have even observed such people running EMACS through their Kermits and getting things like inverse video mode lines, use of line insert and line delete functions, and other such things that Zenith-19s support but VT52s don't. I know, however, that it can't emulate every function of a Zenith-19, because it can't use the 25th line. So apparently it's emulating something in between a full Zenith-19 and a VT52. What exactly is that something, i.e. what are the specs for what it is emulating? Also, if I am talking to VAX/VMS 3.5 (instead of a DEC-20) I find that there are many VT52 functions that it cannot emulate. For instance, SET TERMINAL /INQUIRE doesn't work, and most of the screen handling of VAX/VMS EDT fails badly (e.g. downward scrolling, among other things -- of course, the keypad doesn't work for EDT either, but I have EDT customized to use control characters for most of the stuff that's usually invoked by the keypad, a la EMACS). Could these things be made to work, or are there restrictions in DOS that cannot be gotten around that explain why they aren't implemented? Where, in general, is the precise set of terminal capabilities that Kermit emulates documented? Thanks in advance. -- Daniel M. Rosenblum, Ph.D. candidate, School of Urban and Public Affairs, Carnegie-Mellon Univ. [Ed. Note -- The forthcoming release of MS DOS Kermit will address most of these complaints. It will do reverse line feeds and work with EDT on the VAX. The documentation will include a list of all the H/Z-19 control codes showing which ones are supported by MS DOS Kermit. There will be a key redefinition facility so you can make the keypad or the functions keys send anything you like. I hope to be able to announce it this week.] ------------------------------ Date: Mon, 11 Jun 84 13:58:37 cdt From: knutson@ut-ngp.ARPA Subject: Cyber Kermit document file I have put together a .MSS file similar to the others referenced by KUSER.MSS. It is available via anonymous FTP from UT-NGP as file 170KERMIT.MSS. I think for the most part it is formatted correctly. You might want to take a look at it and check for yourself. Jim Knutson ARPA: knutson@ut-ngp UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson Phone: (512) 471-3241 [Ed. Note -- It's available in KER:170KERMIT.DOC and .MSS on COLUMBIA-20 and CU20B, accessible via FTP and NFT, respectively.] ------------------------------ Date: Mon, 11 Jun 84 02:29:30 cdt From: Stan Barber To: cc.fdc@columbia-20.ARPA, stan@rice.ARPA, towson@Amsaa.ARPA Subject: TRS-80 Kermit File Problems I have checked some of the code on Columbia-20 and some of the .SRC files have missing tails. TRSMAKE.BAS is correct except for an error on my part. Line 150 starts 150 ' some code the ' needs to be removed before running the program. Stan sob@rice [Ed. Note -- Actually, it appears that the *.SRC files are not missing anything at the end; rather they have a ^Z and then some junk after the end (sound familiar, CP/M fans?). The TRSMAKE.BAS file has been corrected, and the junk has been lopped off the end of TRS*.SRC. The TRS-80 I & III Kermit files are available in KER:TRS*.* on COLUMBIA-20 and CU20B.] ------------------------------ Date: Mon 11 Jun 84 18:26:34-EDT From: Frank da Cruz Subject: Macintosh Kermit No-Progess Report To: Info-Kermit In response to the many inquiries I've been getting about this... We (Columbia) are totally committed to writing Kermit for the Macintosh, and probably also for the Lisa. We're a member of the Apple University Consortium, and we've submitted a proposal to Apple about adding Kermit as one of Macterminal's protocols. So far, no word back from Apple. The major hangup, however, is that Apple has been unable to deliver the Lisa II development systems we have had on order for many, many months (we never bought any Lisa I systems). There may be some possibility of using the SUMEX "sumacc" VAX-based cross development system instead of a Lisa, but we don't yet have a system to run it on -- Eunice under VMS would be about the best we could do, but we don't have Eunice yet... More news as (if) it develops... ------------------------------ End of Info-Kermit Digest ************************* ------- 15-Jun-84 13:16:07-EDT,14229;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 15 Jun 84 13:15:23 EDT Date: Fri 15 Jun 84 13:12:45-EDT From: Frank da Cruz Subject: Info-Kermit-Digest V1 #6 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Friday, 15 June 1984 Volume 1 : Number 6 Today's Topics: New Kermits, How To Get Them New Release of PDP-11 Kermit New Software Tools Ratfor Kermit New Version of Sirius MS DOS Kermit CMS Kermit and Yale IUP Kermit-80 Status Report DEC-20 KERMIT Review Telenet and Kermit ---------------------------------------------------------------------- Date: Fri 15 Jun 84 12:00:00-EDT From: Frank da Cruz Subject: New Kermits, How To Get Them To: Info-Kermit This issue of the Info-Kermit digest contains announcements of several new KERMITs. For the benefit of those who are new to the Info-Kermit list, and to refresh the memories of those who aren't, here's how to get the KERMIT files: ARPANET/Internet Use FTP, connect to host COLUMBIA-20, login as user ANONYMOUS with any non-null password, and GET (or MULTIPLE GET) the files you're interested in. Anonymous FTP access to COLUMBIA-20 is allowed only after 6:00pm and before 6:00am. CCNET (DECNET hosts at Columbia, CMU, CWRU, NYU, Stevens, and (soon) Vassar): Use NFT to COPY the desired files from CU20B::KER:. If you're on a VAX, just use the COPY command. Specify /USER:ANONYMOUS. If CU20B does not grant you anonymous access, ask your system manager to get the files. BITNET: On an IBM VM/CMS system, type the command SMSG RSCS MSG CUVMA KERMSRV HELP to get instructions for how to use the Kermit server at host CUVMA. There is usually a delay between the announcement of a new version of Kermit and its availability on BITNET, because each file has to be painfully screened and possibly processed to fit the requirements of our RJE link. Other networks like USENET, MAILNET, etc, or if you're not on a network: Send mail to Info-Kermit-Request@COLUMBIA-20, or to: KERMIT Distribution Columbia University Center for Computing Activities 612 West 115th Street New York, N.Y. 10025 and we'll send you flyers explaining how to order a distribution tape. ------------------------------ Date: Fri 15 Jun 84 11:57:22-EDT From: Frank da Cruz Subject: New Release of PDP-11 Kermit To: Info-Kermit Announcing version 2.16 of PDP-11 Kermit for RSX-11/M and M+, RSTS/E, and now also RT-11, from Brian Nelson at the University of Toledo, Ohio. The major changes since the previous release (2.11, March 1984) include: Support for the RT-11 operating system (v4.0 or later) . Performance improvements in both asynchronous and disk i/o . Software controlled parity . Support for half duplex communication . Ability to transmit a BREAK signal . Support for attribute packets, mainly for use between FILES-11 systems. . Support for DECnet (RMS DAP) file access (added by Bob Denny). Kermit-11 is probably the most advanced version of Kermit presently available. It implements practically every feature described in the 5th edition of the protocol manual, including the full range of server file management functions. Although the RSTS and RSX versions use RMS for i/o, you do not have to have RMS on your system in order to use it, and Kermit-11 does not have to create RMS files as output. The installation instructions explain how to run Kermit-11 on non-RMS systems. The files for all 3 operating systems are in KER:K11*.*. There about 59 files, occupying a total of about 1760K (703 DEC-20 pages), so before taking them all you should first look at KER:K11INS.DOC, the installation notes, which describe in detail the exact prerequisites for installing or running this program, and it may give you an idea of which files you might not need. A detailed list of changes to the program is in the file KER:K11CMD.MAC. The new help files for the program were inadvertently omitted from the tape I received, but they should be available soon. Meanwhile, Kermit-11 is very close to the "ideal" Kermit described in the main part of the 5th edition Kermit User Guide. This release will also be available on the Sring 84 RSX and other DECUS SIG tapes. ------------------------------ Date: Mon, 11 Jun 84 14:41:37 pdt From: Ken Poulton To: cc.fdc@columbia-20.arpa Subject: New ST Ratfor Kermit Here is the latest Software Tools Ratfor Kermit. I am sending you three files: the formatted doc, the doc source, and the program source. The latter two are in ST 'archive' format; standard format for ST distributions. Any Software Tools implementor can install this rather simply on his/her machine: the machine dependent parts are well flagged and few. Further versions will be forthcoming, but this should serve for anyone's initial implementation. Implementors should also pick up the standard user's and protocol manuals. Ken [Ed. Note - The files are in KER:ST*.*. It is configured for the Univac 1100 and the HP3000, and designed to be easily adapted to any other system that has the Software Tools package, which must be present before you can run it. The file KER:STKERMIT.HLP tells more about the program, and also how to get the Software Tools package.] ------------------------------ Date: 18-May-84 From: Barry Devlin, Computer Center, University College, Dublin Subject: New Version of Sirius MS DOS Kermit Here is a new version of Sirius MS-DOS Kermit. I have merged it into version 1.20 of the IBM PC Kermit, and have added a reasonable degree of VT100 emulation. Also, the bootstrapping method has been made to work for the Sirius. Considering the demise of the Victor in the U.S. and the much greater popularity of the Sirius in Europe, I suggest we settle on the SIR prefix for distribution. VIC also has some Commodore implications. I have not made any attempt to update the CP/M-86 version for the Sirius although I am aware of some problems in the area of end-of-file handling and also in wildcarding. When the Rainbow CP/M-86 version touches these areas I hope to return to the problem. [Ed. Note -- The new Sirius MS-DOS version is available as KER:SIR*.*. The present CP/M-86 Kermit that runs on the Rainbow and NEC APC do handle wildcards and eof correctly; Barry will receive a copy.] ------------------------------ Date: 18-May-84 From: Barry Devlin, Computer Center, University College, Dublin Subject: CMS Kermit and Yale IUP Here in U.C.D. we will be moving away from the beloved 2060 towards a more IBM oriented computer centre. However, the communications and terminal base on campus will remain ASCII in character. It is envisaged that the Series-1 / Yale IUP with support for VT100s will continue to be the way of supporting these terminals. This means that Kermit for CMS is becoming very important. Is there a better version now available? And what do you think of the chances of running it through the Series-1? We had a look at the old CMS Kermit and felt it should be possible to use the transparent Series-1 mode to do the packet transfer and perhaps full-screen mode terminal emulation. We would be interested to hear if anyone has done anything about it. [Ed. Note -- We will be working on CMS Kermit this summer, and making it work with the Yale IUP is one of the areas we'll be investigating.] ------------------------------ Date: 13 Jun 1984 0106-PDT From: Charles Carvalho Subject: Kermit-80 Status Report To: CC.FDC at COLUMBIA-20 Cc: CHARLES@ACC Hi. I'll be away on vacation June 14-24, and my system is not portable (besides, I would worry about getting sand in the floppy drive). I sent version 4.00 to David Kirschbaum (abn.iscams@usc-isid); he's put in support for his Decision I and the TAC trap code; meanwhile, I've fixed some minor problems and added some documentation and produced v4.01. We'll have to figure some way to get these two back together. He also made everything assemble under LASM, which we ought to be able to supply with Kermit, it being public domain. (He also uses MLOAD rather than DDT to merge the two hex files). The current delay is documentation. I've got some very rough notes on generating Kermits for supported systems, but nothing yet on how to add support for a new system (which shouldn't be too hard, since there are about 18 examples). There's also about 25 Kbytes of notes on what I've changed. /Charles [Ed. Note - For those who missed earlier announcements to this effect, Charles is working on a new, modularized, version of Kermit for CP/M-80.] ------------------------------ Date: Thu 7 Jun 84 16:02:02-PDT From: Ken Harrenstien Subject: DEC-20 KERMIT Review To: cc.fdc@COLUMBIA-20.ARPA [Ed. Note - My comments are indented like this.] OK, I've looked at the 5th edition stuff a bit and have the following comments. Most has to do with the TOPS-20 KERMIT.MAC program, version 4(215). (1) It is extremely annoying to have a document file with 80 chars per line. Please make the default LPT versions something more reasonable such as 72. Not all printers can handle 80 chars, and for those which can, it is nice to have SOME right margin for readability and notes. NIC documents are limited to 72 chars per line for this reason. Of course this will make the documents a few pages longer, but the whole point of documentation is to convey information in a way which is clear and easily readable! [OK, next time thru the wringer, they'll come out narrower.] (2) The protocol badly needs a "bare" control-char convention. You should define it NOW before various people (eg me) go off and implement their own. Of course it should be an option, but still it should be provided. A simple start would be an option bit that says the program has complete control over all input and output -- in other words, all characters can be sent and received, and you don't have to pull your hair trying to figure out which ones are ok and which aren't. [In fact, there's nothing in the protocol that says you HAVE to transmogrify all control characters. You can stick bare ones into packets right now, and they'll come out correctly on the receiving end, provided you don't do this with SOH (Control-A, the normal start-of-packet marker), with the XON or XOFF characters if XON/XOFF is being done, etc. However, watch out for the case when both hosts THINK they know which control characters they can handle but some piece of communication equipment that's somewhere between them knows otherwise. Anyway, you're right, this needs more thought.] (3) KERMIT-20 GET doesn't provide any way to specify different local filenames (such as RECEIVE and SEND do). It should. (4) KERMIT-20 is screwed up after a ^Z or ^X -- SEND complains "no files to send" even when an argument is specified! They don't appear to actually abort a file transfer, either... even when SENDing the file! (5) KERMIT-20 GET can't get a filespec starting with "!" because that is the TOPS-20 comment character. It doesn't help very much to quote it because the resulting filename is almost certainly going to be highly unusual, if not illegal -- this because of the problem above where you can't specify the local filename. (6) KERMIT-20 has this incredibly brain damaged misfeature where it quietly turns off the receive-link bit for the user's terminal, and leaves it off! I can understand this while it is in SERVER mode, but not local mode!!! There is absolutely no justification for refusing links in local mode -- that should be up to the user, who determines this with EXEC commands. (7) TTLINK doesn't appear to ever actually set the terminal speed to what was specified. This is a pain because often outgoing lines are set to speed 0 to prevent noise problems, and hooking up to one with TTLINK isn't going to do anything (whether or not a speed is specified) until you realize what is going on (50 points for intuitive flash) and manually clobber it with ^ESET TER n SPE. There doesn't seem to be a good way to pass parameters like SPEED from KERMIT-20 to TTLINK by the way. That seems to be all that was on my list at the moment. [I'll look at all the Kermit-20 and TTLINK complaints as soon as I get a chance.] Oh! One other thing I remembered. TTLINK or KERMIT (I suspect the former) sends a CR every time you start or resume a connection. This is very bad, because sometimes the first char you send should be a special auto-baud speed set char, and CR is not always the right thing. Also, during a connection, this makes it extremely annoying if the other end is talking to a text editor -- you get CR's inserted -- or if the other end is awaiting some test input such as a filename (CR sets it going with defaults that you DON'T want!). Grumble, grumble. This is a pretty serious misfeature, I'd say. I don't see any good reason for it at all. [TELNET does this too. Can anybody think of any undesired consequences of removing this behavior?] --Ken ------------------------------ Date: 14 Jun 84 09:46:30 EDT From: RC0T@CMU-CC-TE To: info-kermit@CUCS20 Subject: Telenet and Kermit We are part of the Telenet network. But if users use Kermit on their PCs and then connect through Telenet the sending and receiving of files fails immediately. Would you have any suggestions as to why this is happening? Thanks. Rick Costa User Services [Ed. Note - I've used KERMIT over TELENET successfully by giving the command SET PARITY MARK to the Kermits on both ends.] ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Jun-84 18:41:28-EDT,5756;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 18 Jun 84 18:41:13 EDT Date: Mon 18 Jun 84 18:32:08-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #7 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 18 June 1984 Volume 1 : Number 7 Today's Topics: Dialup Access to Kermit Files Looking for Kermit for Pick OS Coco Os9 kermit Kermit On Telenet Cray Kermit Progress ---------------------------------------------------------------------- Date: 15 Jun 1984 1753-EDT From: B.Eiben LCG To: Info-Kermit at COLUMBIA-20 Subject: Dialup Access to Kermit Files You might want to stick us in too: DEC-Marlboro 617-467-7437 (300 / 1200 Baud) two Control-C's LOG LCG.KERMIT KERMIT distribution area is KERMIT: It's a public account - and has been "pushed" in DECUS and otherwise - to my knowledge the "only" way to get KERMIT via "Ma Bell" without any other "special connections". [Ed. Note -- That's Digital Equipment Corporation, Marlboro, Massachusetts, USA. The machine is a DECSYSTEM-20. Thanks, Bernie!] ------------------------------ Date: Fri, 15 Jun 84 11:21:18 pdt From: Ken Poulton To: info-kermit@csnet-relay.arpa Subject: Looking for Kermit for Pick OS Does anyone know of a Kermit for the Pick operating system? Failing that, how about a Kermit written in Basic? [Ed. Note -- I haven't heard of anyone working on Kermit for Pick, but there is a Basic implementation for a Swedish micro, the Luxor ABC-800, in KER:800*.*. I've been told that it's a rather unusual dialect of Basic.] ------------------------------ Date: Sat 16 Jun 84 00:32:53-PDT From: Bob Larson Subject: Coco Os9 kermit To: info-kermit-request@COLUMBIA-20.ARPA I am listed with Good intentions of implementing Trs-80 Color computer Kermit in an unknown language for an unknown operating system. I have good intintions of implementing os9 kermit in (microware) C on my color computer. Due to os9 doing a very good job of insulating the user from piculuarities of hardware, it is my belief (and hope) that this implementation could be run on any 6809 os9 system. (There is also a version of os9 for the 68k, I can't tell how easy it would be it convert to it.) There is also someone listed with good intentions of doing a kermit for a swtp system. Do you you know what operating system he is using? Also note that they have changed my user name from Larson@Usc-Eclb to Blarson@Usc-Eclb. (They decided to make user names unique on all Usc-Ecl systems.) Bob Larson [Ed. Note - The SWTPc system is running FLEX. I added this and your info to KER:VERSIONS.DOC.] ------------------------------ Date: Sun 17 Jun 84 20:53:50-PDT From: Doug Brutlag Subject: KERMIT ON TELENET To: cc.fdc@COLUMBIA-20.ARPA, rc0t%CMCCTE@COLUMBIA-20.ARPA Frank, Another way to get KERMIT to transfer files on TELENET is to configure TELENET to transmit the eighth bit. Most TELENET nodes are set up for 7 bit communications only. You can set up eight bit mode, by connecting to your host, then escape back to TELENET (with cr @ cr) and giving the command: SET? 0:33,63:0 The 0:33 parameter allows you to set certain ITI parameters normally not used by TELENET users. The ITI parameter 63 enables the eighth bit when set to 0 (contrary to what is written in the TELENET documentation by the way). I have found this setting useful for both KERMIT file transfers and for using a terminal with a META key for setting the eighth bit for EMACS editing commands. If this fails you should call the TELENET 800 number to find out how to allow eight bit communications for your node. SOme nodes use old TELENET protocols which require setting parameter 57:1 as well. If you have many people using KERMIT via TELENET you can have your TELENET representative change your local node to make the default setting of parameter 63 be 0. By the way I do not encourage people to use KERMIT via TELENET because of the delay in receiving the ACK/NAK. Even with an unloaded network and 1200 baud nodes at either end, the delay in receiving the ACK/NAK effectively lowers the transmission speed from 1200 baud to less than 300 baud. Doug Brutlag [Ed. Note - We will try to work out a "sliding window" option for the Kermit protocol over the summer. This should speed things up a bit, assuming it can be widely implemented.] ------------------------------ Date: 18 Jun 1984 14:24:02-MDT From: Leah F. Miller C-10 To: cc.fdc@COLUMBIA-20 Subject: Cray Kermit Progress We have a portable pre-release Kermit up and running on both the Cray-1 and the Cray X-MP. It runs under the CTSS (Cray Time Sharing System) operating system which was developed at Livermore and is fairly widely used at gov't laboratories. I think, however, that anyone wishing to port it to a COS (the batch OS provided by CRI) system would find this a matter of replacing a few low-level subroutines. As of today Cray Kermit has been tested only in communication with one partner, Kermit-86 on the IBM-PC, and in one environ- ment, the LANL network. Therefore, estimated general release date remains "late summer". Enjoyed your article in Byte and look forward to Part 2 ! Leah Miller ------------------------------ End of Info-Kermit Digest ************************* ------- 20-Jun-84 11:20:19-EDT,12638;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 20 Jun 84 11:19:31 EDT Date: Wed 20 Jun 84 11:15:26-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #8 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 20 June 1984 Volume 1 : Number 8 Today's Topics: Control-Character Prefixing Performance of Kermit over Packet Networks (several messages) Server Mode for Micros (several messages) BLAST - KERMIT Lookalike? ---------------------------------------------------------------------- Date: Mon, 18 Jun 84 14:17:20 pdt From: Ken Poulton To: info-kermit@csnet-relay.arpa Subject: Control-Character Prefixing I'm not convinced as to the need for sending "bare" control characters. This is one of the beuties of Kermit! You don't *have* to worry about who cares about what control characters. Defining a bit for "I can take anything without control quoting" is an easy first step, but anything beyond that would probably add several pages to the protocol manual which are almost never implemented. Most of all, though, I don't see any motivation. Text files contain only a small percentage of control characters, so there's little need for efficiency's sake. Binary files do incur a 25% overhead due to control quoting, but they incur an additional 50% overhead due to eighth-bit quoting. So... why bother? [Ed. - Actually, a 25% improvement is nothing to sneeze at. Also, the 50% overhead for 8th-bit quoting only occurs over 7-bit channels; most Kermit connections are 8-bit, so they don't get this overhead. Therefore, the control-character prefixing dominates. The trouble is, you're just not safe eliminating it unless you have a hardwired connection whose characterstics are fully known. Also, not only will it add pages to the manual, but it'll add startup overhead, translate tables to the program, etc. But it's still worth looking into.] Is anyone thinking about a better binary encoding? It would be nice to use something like the Unix uuencode's 4-bytes-for-3 translation to cut down on the overhead for binaries. Seems like a way to specify record breaks would be nice, so as to accomodate those arcane systems (IBM + HP3000, f'rinstance) that have such things as variable record size binary files. [Ed. - We're encoding the new MS-DOS Kermit binaries with 4-for-3, and also collapsing adjacent 0 bytes. We find the result to be smaller than the .EXE file itself. All this will be announced soon. With Kermit attribute packets (unimplemented anywhere except in the PDP-11 versions) it is possible to specify the encoding, so certainly 4-for-3 could be one of the alternatives. There's also an attribute that specifies that the file is composed of arbitrary records preceded by length fields.] ------------------------------ Date: Mon, 18 Jun 84 17:04:55 pdt From: Ken Poulton To: info-kermit@csnet-relay.arpa Subject: increasing kermit throughput on long-distance lines We have an interest in using kermit for file transfer over long lines and packet networks, where the roundtrip delay may reach several seconds. Clearly, several seconds of delay causes some severe throughput problems with kermit's packet-acknowledge protocol. In the current protocol manual, under "Unresolved Issues", mention is made of a "floating window" scheme: send a bunch of packets and then wait for acknowledgement; ack for packet N implies ack for all packets < N. It occurs to me that this could be implemented with nothing more than some buffering on the sender's side. No negotiation is required; the sender must simply be sure that the number of packets he sends at one time does not exceed the number of nak's the receiver will send before quitting (the receive retry limit). Has anyone tried this? Does anyone see a hole in my reasoning? [Ed. - I think there's got to be some agreement between the two sides. Retries are used to recover from errors, and the same counter shouldn't be used to count two different things. Anyway, there has been a lot of talk about adding this to Kermit (see next message for another example), and it should be carefully considered.] ------------------------------ From: ihnp4!sask!derek@Berkeley Date: 18 Jun 84 13:58:45 CDT (Mon) To: cc.fdc@columbia-20.ARPA Subject: a plea First, let me say that the work you are doing with Kermit is fantastic. It is really a wonderful package unselfishly contributed to the world. Now, let me ask for a favour. Presently, the maximum packet size is 80 characters. I implore you to consider allowing it to be 256 characters. In Canada, we have a network called Datapac. It is similar to Telenet. It is a packet switched network allowing packets to be a maximum of 256 characters. It costs the same to send a 1 byte packet as it does to send one of 80 or 256 characters. Allowing Kermit to send 256 byte lines would keep the cost of Datapac connections down. Is it too late to try to incorporate this into the standard? I would hate to make a change to Kermit to allow this only to be incompatable with the myriad of Kermits out there. Thank you for your time. Derek Andrew U of Saskatchewan (Canada) Arpanet: "sask!derek"@utah-cs ------------------------------ Date: Wed 20 Jun 84 09:56:07-EDT From: Frank da Cruz Subject: Re: a plea Actually, the maximum Kermit packet length is 96. This is not an arbitrary number, but rather a consequence of the fact that the length field is encoded as a single printable character, of which ASCII has 94 (the length field does not include the SOH or the length itself). We designed it this way on purpose, because we found that other protocols that used longer packets (especially fixed length longer packets) would not work with certain popular systems that had trouble receiving 256 or 128 characters at once. By making it impossible for anyone to write a Kermit that would "overload" any other Kermit, we have kept the protocol more generally useful. I agree, however, that the performance is not what it could be. For applications in which you know the characteristics of the communication medium and the two systems involved, you would like to get more throughput. This can be done by either lengthening the packets, or allowing multiple packets to be sent in a stream. Longer packets incur a higher cost in retransmission overhead, and would require use of CRC for error detection, as the current 6-bit checksum would be pretty inadequate for a 200 (or 1000) character packet. A stream of packets (the "floating window" technique) would achieve the same effect, but would work less than optimally on half duplex connections. Incidentally, it would be relatively easy to extend the packet length. Since the length field always includes the type and block check fields, it can never be less than 3. Therefore, values of 0, 1, or 2 could be set aside for special uses. For instance, 0 could mean that the first 2 (or 3 or 4) characters of the data field were an extended length field. The ability of a Kermit program to handle this would be flagged in the Send-Init capabilities mask, and corresponding special values would also have to be used in the MAXL field of the Send-Init. We are looking at the possibility of adding both these options to the Kermit protocol, but bear in mind that adding things to the protocol specification and getting them into 50 or 60 implementations are two different things. - Frank ------------------------------ Date: 18 Jun 1984 23:00-EDT Subject: pc server code From: POLARIS@USC-ISI.ARPA To: info-kermit@COLUMBIA-20.ARPA Have there been any personal computer KERMITS which include server functions besides Herm Fischer's (excellent!) additions to the IBM-PC version? I am curious to see if the "other end" of the line code has been done for KERMIT in the same manner as XMODEM vs. MODEM7, particularly for CP/M systems acting as bulletin boards or public domain software distribution points. mike seyfrit [Ed. - The forthcoming MS-DOS Kermit release will incorporate Herm's server code. See below for more on this subject.] ------------------------------ Date: Tue 19 Jun 84 19:56:16-PDT From: William Pearson Subject: CPM kermit To: info-kermit-request@COLUMBIA-20.ARPA I have just set up Kermit on our VAX, IBM-PC and Heath 89 and am very impressed, particularly with its batch capability. I would like to have a version for a CP/M computer that would have a server mode, so that after I dial up my Heath using BYE (for remote login with password) and then upload or download from a remote kermit. I could also use a version for a NorthStar Advantage. I would have no problem making these modifications myself, but a 175K source file is a little beyond my capacity. I wonder if 1) you know of some way to recompile on a VAX/VMS system (using public domain assembler perhaps) or 2) if you have an uncommented version which is smaller, along with comments where actual i/o is done or 3) a modular version with overlays. (But I suspect that won't help the server mode). Bill Pearson Pearson@sumex-aim ------------------------------ Date: Wed 20 Jun 84 10:09:31-EDT From: Frank da Cruz Subject: Re: CPM kermit To: PEARSON@SUMEX-AIM.ARPA The lack of remote, unattended access for CP/M Kermit has long been one of its shortcomings, and accounts for Kermit's relative disuse on the RBBS systems. Charles Carvalho at ACC (CHARLES@ACC) is working on a modularized version of CP/M-80 Kermit. This should solve the size problem nicely, allowing you to work on more manageable chunks at a time. It should also let you easily add support for the North Star, and there's always room for a server module. - Frank ------------------------------ Date: 19 Jun 1984 08:48-EDT Subject: BLAST - KERMIT Lookalike? From: ABN.ISCAMS@USC-ISID.ARPA To: CC.FDC@COLUMBIA-20.ARPA Frank, Just got some literature on a file transfer program called BLAST that's VERY reminiscent of KERMIT (adjustable packet sizes, CRC, sliding window pipelining (isn't that coming this summer?), system-unique file conversion, 8-bit prefixing, settable parity and baud, no master-slave restrictions, log/status, remote site error condition reporting, etc. Has some things I haven't seen in KERMIT (yet), and some I've seen in MDM730 (programmable function keys, delay between characters, send logon, and a bunch of remote system command executions). They have versions for about a hundred different micros, minis, and mainframes, to include the big Data General machines, PDP-11s, HP3000s, Honeywell DPS-8s, IBM 360s (no Cray). Might almost be worth while getting, just to see some of the things they did. NOT to pirate the code, just to see how! (A little backward engineering, my friends??) Source is Communications Research Group 8939 Jefferson Hwy Baton Rouge Louisiana 70809 (504)923-0888 Costs run from $250 for micros to several thousand for the mainframes. Cheapest is $100 for Compaq and IBM PCs, running PC-D200EM OS (what's that?). Just for your info. Regards, David Kirschbaum Toad Hall ABN.ISCAMS@USC-ISID [Ed. - Actually, BLAST has been around for some time. I don't know much about it, but it's probably a lot like Kermit in its capabilities, probably superior in many areas. It's only one of many, many Kermit-like commercial products. They all have their strong and weak points. The commercial products are generally stronger in the area of modem control, login scripts (built-in options for talking to Dow-Jones, The Source, etc), etc, and they usually have jazzy function-key menu-driven user interfaces. Kermit, on the other hand, tends to run on more different kinds of systems more consistently than most commercial products, comes with sources and internal as well as user documentation, invites users to write versions for new sytems, and the price is right... But I don't doubt that Kermit and the commercial products influence each other.] ------------------------------ End of Info-Kermit Digest ************************* ------- 22-Jun-84 18:24:13-EDT,15616;000000000001 Return-Path: Received: from CUCS20 by CU20B with DECnet; 22 Jun 84 18:23:37 EDT Date: Fri 22 Jun 84 18:18:50-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #9 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Friday, 22 June 1984 Volume 1 : Number 9 Today's Topics: Macintosh Kermit Progress Report Unix Kermit Problems (several messages) Kermit Comments Current Kermit for IBM PC? Control Characters in Packets Micro-Host Transfer Software Recommendation? Comparing Kermit with Other Packages ---------------------------------------------------------------------- Date: Thu 21 Jun 84 18:19:34-EDT From: Frank da Cruz Subject: Macintosh Kermit Progress Report To: Info-Kermit@CUCS20, Info-Mac@SUMEX-AIM.ARPA Columbia has finally received its Lisa-2/10 development system, though we haven't actually tried to use it yet for Mac development yet (we just unpacked it). We had a rudimentary, receive-only adaptation of Unix Kermit running on the Mac briefly, bootstrapped with the Sumacc cross development package. This was painful to do, and only worked once for some reason. We may pursue this avenue, or give it up if the Lisa proves to be easier to deal with. We submitted a proposal to Apple 2 months ago to add Kermit as one of the file transfer protocols supported by MacTerminal. We haven't had a response yet. Meanwhile, a review of MacTerminal in the current (July/August 1984) issue of Macworld compares Kermit favorably to the XMODEM protocol that is already in MacTerminal (p.69). I hope someone at Apple reads the review. What does all this add up to? We'll produce a Kermit for the Mac one way or another. We'd prefer to see it as an option in MacTerminal, since that's the natural place to put it, but failing that we'll do a standalone version. Anyway, at least now we can start. ------------------------------ Date: Wed, 20 Jun 84 10:11:26 edt From: cu-arpa.tesla!pottle@Cornell.ARPA (Christopher Pottle) To: cornell!info-kermit@columbia-20.ARPA Subject: IBMPC-Unix Kermit Problem This problem may be well known, but I am a newcomer. With what I believe to be the latest versions of Kermit for the IBMPC (1.20) and for Vax-Unix (ca. 2/84), the IBMPC hangs with the Waiting... message after sending a file to Unix. One can interrupt out and reconnect, and will find the file safe and sound on the Unix machine. Is this bug known to you? [Ed. - Many Unix Kermit users have reported this problem, and I haven't seen a good solution yet. I'm not a Unix expert, but as I understand it, Unix does most things by putting them on lists of things to do. When you tell Unix to send a packet, it goes out when Unix gets around to it. However, having sent its last packet, an ACK for the PC's "I'm all done" packet, Unix Kermit then restores the TTY to "cooked mode" and exits. This apparently happens immediately, and interferes with the transmission of that last packet, which is still waiting on a list somewhere. A workaround would be for Unix Kermit, after returning from the protocol, to sleep for a second or two before restoring the line.] ------------------------------ Date: Thu, 21 Jun 84 08:17 PDT From: "Chase Lila"@LLL-MFE.ARPA Subject: UNIX Kermit To: Info-Kermit@COLUMBIA-20.arpa Frank, There is a definite problem with UNIX Kermit on our Sun's with Berkeley UNIX 4.2. The phone is hung up or disconnected upon the second call to open the tty line. It had worked with the previous version of UNIX only by luck. I have been told it is hazardous to open the line, exit kermit and open it again upon another invocation of Kermit. Better to have just one invocation. To do this quickly, simply replace if (cflg) by if (!remote) before the connect call. execution then becomes: kermit slb /dev/ttya 1200 filename (locally) kermit r (remote) Evidently this problem does not happen over hardwire connections (Bob Cattani says). Lila Chase (415) 422-4086 chase@LLL-MFE ------------------------------ Date: Thursday, 21 Jun 1984 14:21-PDT To: cc.fdc@COLUMBIA-20.ARPA Cc: unix-wizards@BRL-VGR.ARPA Subject: unix kermit From: gray@SU-DSN.ARPA Having discovered that cu loses characters at 9600 baud, I tried to bring up Unix kermit on a Callan Unistar 200 running Unisoft System V Unix. It did not compile since TANDEM and FIONREAD are not defined in in Unisoft system V and simple fixes do not work. The baud rate is set incorrectly and even if set correctly & ixoff set via stty, Kermit still gets no response from a known functional VAX Kermit (& it seems to keep sending garbage to the Vax). Does anyone have an idea of a way to fix this without drastic rewrites? reply to gray@su-dsn [Ed. - System V support has been added to Kermit, along with support for some of the more arcane versions of Unix. We have perhaps 15 or 20 Unix Kermit contributions waiting to be reconciled with one another. Unix Kermit will be one of our next projects, as soon as we finish the new release of MS-DOS Kermit next week(?). We aim to have a very portable, modular, C-based version of Kermit, providing the full-blown protocol, with support for the various versions of Unix plus some other systems that have C compilers and Unix-like runtime support. Any systems not explicitly supported by all this should be easily adapted by filling in the appropriate i/o primitives.] ------------------------------ Date: Wed 20 Jun 84 19:56:33-PDT From: scott Subject: kermit comments To: cc.fdc@columbia-20.arpa i thought your recent byte article did a good job of illustrating the problems of designing a universal ftp. it looks like your second article won't talk about the sociology of kermit development (the distributed development with columbia coordination via national networks), or the vast number of available implementations. was that because you were worried about being inundated with requests? i would hope that your tentative plans for developing a sliding window protocol would include the option to operate full duplex when available, but now that i read the byte article i realize that i hadn't thought about the echoing problem...can't most OS's turn off echoing? [Ed. - It's too late to worry about being inundated with requests... we're getting 5-10 tape requests per day! The second part of the BYTE article, which appears July 1, tells readers how to get Kermit. We're beginning fortification of the mail room now...] ------------------------------ Date: Thu, 21 Jun 84 01:05:07 pdt From: System Mom - root Subject: Current Kermit for IBM PC? I would like to inquire about the current version of Kermit for the IBM PC. Sorry, it's late. What I meant to say is, when is the next version coming out, how can I get it, and what is the current version number? I have 1.3A and have previously asked this question, but have received no reply. I can (hopefully) be reached at ..!hplabs!hplabsb!fujinaka. I don't know how else. So much for 2 years at MIT. Thank you. Todd Fujinaka [Ed. - So much for xxx years at Columbia -- I don't know how to reply... Anyway, I hope we'll have a field test release of the new MS-DOS Kermit at least for the IBM PC & XT next week. 1.3A is ancient; the current release, since last October, has been 1.20. The new release will be called 2.26.] ------------------------------ Date: Wed 20 Jun 84 19:44:13-PDT From: Bob Larson Subject: Re: Control Characters in packets To: info-kermit-request@COLUMBIA-20.ARPA Unquoted control characters should not be allowed in kermit without specific negotiation. The current prime kermit will NOT allow unquoted CR or LF. (It is not feasible on the prime to not quote linefeed... they are eaten by primos before any user program can get them (including EMACS)) I recommend that any control character in a packet be considered an error, and a NAK packet sent immediately. This would catch some errors that are only handled by timeouts now. Bob Larson [Ed. - The whole area of performance, including bare control characters, long packets, sliding windows, full duplex, deserves - and will get - a lot of thought. Contribution welcome!] ------------------------------ Date: 19 Jun 84 12:23 +0200 From: Edgar_Hildering_SARA%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KERMIT_implementation_and_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Micro-host transfer software recommendation The universities of the Netherlands, technological as well as other, formed a committee for the recommendation of a file tranfer protocol between micro and mainframes of all dutch universities. Although all of the members had heard of KERMIT, some of them even had some experience with it, the committee started to set up a list of requirements for such a protocol. Together with KERMIT there are two other candidates, both commercial packages. Although KERMIT is the most likely candidate, I, as a member of the committee, would like to know if someone has experience with non-private packages other than KERMIT. In concrete: What can KERMIT do that these packages cannot and what can these packages do that KERMIT cannot? May the best win, Edgar. [Ed. - That's a tall order; I'll give it a try below. Other replies are welcome, too.] ------------------------------ Date: Fri 22 Jun 84 18:19:34-EDT From: Frank da Cruz Subject: Comparing Kermit with Other Packages To: Info-Kermit@COLUMBIA-20 First let me say that there seem to be two major kinds of commercial packages: the kind that use some variation of MODEM protocol, and the kind that use their own proprietary protocols. First, MODEM (please, any MODEM aficionados feel free to correct any of this)... MODEM and Kermit are similar in that they both use back-and-forth ACK/NAK protocols over asynchronous telecommunication lines. However, MODEM sends fixed-length packets with 128 8-bit data bytes, KERMIT sends variable length packets (up to 96 characters in length) with either 7- or 8-bit data bytes. The MODEM packet control fields use all 8 bits; Kermit control fields only use 7. There are several consequences of all this: MODEM can't work at all over a 7-bit channel, even for text files, because the checksum and other control fields will be wrong. This means that MODEM can't be used over public packet-switched networks like TELENET, or with hosts that require use of character parity, like IBM mainframes. Kermit can send both text and binary files over either 7-bit channels or 8-bit channels, but the data gets longer if you have to squeeze it through a narrower hole. Certain computing or communication equipment cannot accept 128 characters at a time. Their buffers aren't that big. Kermit can accommodate these systems, but MODEM cannot. Many systems cannot accept all ASCII characters, particularly control characters, transparently (see the message about PRIME above for one of many possible examples). MODEM provides no mechanism for encoding otherwise taboo characters. Non-CPM systems, which do not necessarily allocate files in units of 128 bytes or follow the CTRL-Z end-of-file convention, will often have junk at the end of a file received by MODEM. MODEM, to the best of my knowledge, does not have a good mechanism for transmitting a group of files; Kermit has it built into the protocol. Kermit protocol also includes optional features for management of remote files -- directory listings, file deletion, quota checking, etc. Many of the Kermit programs support these optional features. MODEM sends the file bytes exactly as is, whereas Kermit gives you some options for reformatting and compressing. A "text" file is transformed to "canonical form" by Kermit, i.e. a stream of ASCII characters with the "records" (lines) separated by (encoded) CR/LF sequences, so that it may be stored in useful form on the target system. Thus, Kermit may be used on record-oriented systems (like IBM VM/CMS) or on stream-oriented systems like Unix where there record boundaries may be different (LF instead of CRLF); Kermits on those systems that don't store text files in the canonical manner do the appropriate conversions. In addition, Kermit may also be told to send files as-is. On the other hand, MODEM works nicely between like systems (especially CP/M systems) -- it's more efficient than Kermit because it doesn't have to encode and decode the data, and the packets are somewhat longer. Also, much greater attention has been given in MODEM programs to modems themselves, and MODEM programs are typically able to control dialout modems from various manufacturers, and to run in "remote mode" when dialed up from the "back port" of a micro (but the forthcoming MS-DOS Kermit will have this ability also). MODEM provides the ability to dynamically switch between 8-bit and 16-bit block checks depending on the error rate; KERMIT provides 6, 12, and 16 bit block checks, but one of these must be selected ahead of time and will be used throughout the transfer. There's more, but in short I think that, on balance, Kermit is more flexible and more easily adaptable to new systems; hence its rapid spread to a wide variety of micros, minis, and mainframes. Now, as to commercial packages with proprietary protocols -- well, who knows? In some cases, these protocols may be superior to Kermit in every way. But you have certain problems with any commercial package: Are implementations available for all the systems you want them for? If not, will the vendor write the missing implementations? When? For how much money? Does the protocol make assumptions (like full duplex communication, 8-bit data path) that would lock out certain classes of systems? Do you have enough money to buy the software licenses for your mainframes and each and every one of your micros? Some sites have thousands of micros. A typical commercial file transfer package costs $500-$5000 dollars for the mainframe end and $50-$500 for each micro. Can your vendor fix bugs in a timely fashion? If you had sources, you could fix them yourself, but most vendors don't provide sources. Many commercial packages are very fancy, both in the protocol and the user interface. But they often tend to be specially tailored to a certain combination of systems and/or applications. Kermit is not as fancy as a commercial product that knows how to dial up Dow-Jones and look up your stocks, reformat the data as it comes in, and display it in a color pie chart, all upon a single keystroke. But then that package probably can't exchange text and binary files with 50 or 60 different kinds of systems in a relatively uniform and consistent way. Comments, rebuttals, are invited. - Frank ------------------------------ End of Info-Kermit Digest ************************* ------- 26-Jun-84 11:15:54-EDT,10161;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 26 Jun 84 11:15:19 EDT Date: Tue 26 Jun 84 11:15:10-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #10 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Tuesday, 26 June 1984 Volume 1 : Number 10 Today's Topics: Begging for Mercy IBM-PC Kermit & Ctrl-PrtSc Kermit for the DEC-Pro 350 Unix Kermit Hangs Call for Unix Kermits! Many Things Kermit for the Macintosh ---------------------------------------------------------------------- Date: 22-JUN-1984 09:07 CST From: STEVENS@MACCWISC.MAILNET To: CC.FDC@COLUMBIA-20.ARPA Subject: Begging for Mercy I am quite sure that your heart is in the right place so I say all this only to reinforce what you already know. !!!!!!!KEEP THE MINIMUM KERMIT SIMPLE!!!!! After playing with KERMIT for years it is easy to see how 12th bit binary escape compression ECC re-encoding would fit nicely and be a big help for people using the Mars/Jupiter data link. But to the poor soul reading the protocol manulal for the first time, such notions can only result in despair. He will give up. Let KERMIT be a simple (possibly expensive, possibly slow, possibly "un-friendly") way to get information from any machine to any other machine. Something I can count on. [Ed. - I agree. The minimum Kermit IS simple. You can still write a Kermit program in a few pages of C or other high-level language. Look at the current (5th) edition of the protocol manual. It's divided into two sections, one describing the mandatory features, the other discussing the optional ones. The mandatory features haven't changed at all from the very beginning. The most rudimentary Kermit will always be able to communicate with the most exalted, automatically. Things were a bit more confused in earlier editions of the manual, which was the main reason for the 5th edition.] ------------------------------ Date: 24 Jun 84 14:13:00 EDT From: D. M. Rosenblum Subject: IBM-PC KERMIT & CTRL-PRTSC To: INFO-KERMIT@CUCS20 About three and a half weeks ago, someone here (C-MU Comp. Center) posted a message (only locally, which is why you didn't see it) complaining that when using an IBM-PC as a terminal through Kermit 1.19, one couldn't get a hard copy (on the PC's printer) of what one was doing by using the Ctrl-PrtSc combination. (Ctrl-PrtSc toggles hard-copy printing of everything that appears on the screen on an IBM-PC as it appears. It is different from shift-PrtSc, which merely prints the current screenful.) Apparently Kermit didn't know about slowing down its output to make this work. He asked if anyone had any other terminal emulation programs that did have this feature, and he found that a guy in the Comp. Sci. department here (C-MU) had in fact written such a thing. Unfortunately, it is not available as cheaply as Kermit. This leads to two questions: (I) Do newer versions of Kermit (somehow) support the Ctrl-PrtSc mechanism, and (II) if not is it planned or could it be planned to implement this feature? [Ed. - The forthcoming release of MS-DOS Kermit will do Ctrl-PrtSc.] ------------------------------ Date: 24 Jun 84 14:17:24 EDT From: D. M. Rosenblum Subject: KERMIT FOR THE DEC-PRO 350 To: INFO-KERMIT@CUCS20 The School of Urban and Public Affairs at C-MU is getting some DEC-PRO 350s running RSX-11 (for the time being, anyway -- they may switch to some Unix look-alike or other). Does the PDP-11 Kermit run on these? In particular, does the documentation of PDP-11 Kermit include information on how to install it on a DEC-PRO 350? If the PDP-11 Kermit doesn't run on these, is there a version that does? [Ed. - I assume that when you say RSX-11M, you really mean P/OS with the DCL front end? Kermit for P/OS was written by Stevens Institute of Technology, and is available in KER:PRO*.* in the Kermit distribution area.] ------------------------------ Date: Sun, 24 Jun 84 17:47:23 pdt From: sdcsvax!sdccsu3!brian@Nosc (Brian Kantor) To: cc.fdc@columbia-20 Subject: unix kermit hangs Here at UCSD we're not running a recent version of the unix kermit, but one of the changes we found out needed to be done was to ensure that flushing gets done. In Berkeley (4.2) we have not only to fflush the i/o buffer, but also call the ioctl() function to flush the output buffer. And then, when transfers are completed, we wait about 3 seconds before resetting the tty modes back to normal. We discovered that this was necessary in getting the Christensen protocol programs to work properly; it seemed prudent to put all the same stuff into kermit too just in case it might avoid a load-dependent hang. Since our machines run with load averages anywhere from 0.2 during quarter and summer break and up to 35 or so (with a record of over 100 processes contending for the processor once!!!!), load-dependent "funny noises" kind of hangs are something we look for. ihnp4 \ Brian Kantor, UC San Diego decvax \ akgua >---- sdcsvax ----- brian dcdwest/ ucbvax/ Kantor@Nosc [Ed. - Thanks for the hints; we'll make sure to heed them while working on the new release of Unix Kermit; see below.] ------------------------------ Date: Mon 25 Jun 84 18:31:27-EDT From: Frank da Cruz Subject: Call for Unix Kermits! To: Info-Kermit@COLUMBIA-20.ARPA While the Kermit folk at Columbia are busy putting the last(?) touches on the new release of MS-DOS Kermit, I'm trying to gather together all the Unix Kermit suggestions and contributions that have come in since the last (unnumbered) release, in October 1983. I have a pretty good stack of them, but if there's anyone out there who has some additional suggestions or contributions to make, now's the time! I expect that we'll have a minor new release very soon, whose major new feature will be the ability to communicate with IBM, HP, and other half duplex mainframes, and which (I hope) will have the system- dependent conditional compilation code moved into separate modules. After that, I hope we'll have a full-blown server that does most of what's described in the protocol manual, along with some options for local operation, including an interactive command mode as well as the tar-style command line one-shot mode. ------------------------------ Date: Mon, 25 Jun 84 10:06:13 EST From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers) Subject: Many Things To: cc.fdc@columbia-20.ARPA Glad to hear your Lisa arrived - our Lisas and Macintoshes turned up about 10 days ago. We haven't decided whether or not to go in for the Mac in a big way, but a Kermit would be very useful for the ones we have. Many users here have expressed their appreciation of Kermit, so would you pass on their thanks to all involved in the project (we're using VAX/VMS, Unix, CP/M-80, CP/M-86, MS-DOS, RSTS, Apple-DOS, and Cyber Kermits, so there's a lot of people to thank!) Re CP/M Kermit servers and CBBSs - you don't need a server for this purpose. All that is necessary (I think) is to suppress Kermit's send/receive displays, and make all its i/o go through the port that is connected to the modem. Server mode would be useful, but it's definitely in the 'bells and whistles' category. There's no reason why a CP/M Kermit couldn't be used in the same way as a mainframe Kermit that doesn't have Server functions. I have been thinking about producing a version of Kermit for a CBBS that I'm (very) loosely involved with - I'll let you know if anything happens, but I'll wait for the modularised version before I do any work on it. Getting back to Macintosh, Kermit has two big advantages: 1) it works (at least as well as anything else I've seen) 2) it is (effectively) free If you build Kermit into MacTerminal, point 2 no longer applies. Apple's University Consortium is on a smaller scale here (after all, with a total population of 15 million, Universities are smaller too), so say we buy 120 Macs per year. Virtually everyone will need comms software, so if MacTerminal costs $A150 (Lisa Terminal is priced at $A245), that's $A18,000, compared with about $A125 for the Kermit distribution tape. Even if MacTerminal turns out to be cheaper, we are still talking about thousands rather than hundreds of dollars. [Ed. - About Macintosh Kermit -- We would ensure that there would be a free version available, one way or another. What we hoped to do was to fix Macterminal so it could dynamically "load" the protocol module of your choice (XMODEM, KERMIT, MICROCOM, whatever). Macterminal would still be a product, but Kermit would still be free, but hopefully distributed by Apple with Macterminal. But it seems this problem has been solved before we really had to deal with it; see the next message.] ------------------------------ Date: Mon, 25 Jun 84 21:19:05 CDT From: Don Johnson To: cc.fdc@columbia-20.ARPA Subject: Kermit for Mac Frank, If you trust our implementation, we are writing and are fairly close to being finished with a Kermit for Mac. It is being developed under the Lisa Workshop environment. It will include prefixing and handling of attributes (i.e., some, if not most of extended Kermit will be implemented). We knew that Columbia was going to work on it, but we have to have running code by August. We intend to submit it to the Kermit catalog of implementations when done. Hope that this is useful to you. Don Johnson dhj@rice (713)527-4020 EE Department Rice University Houston, TX 77251 [Ed. - What luck. More news about this will appear as it arrives.] ------------------------------ End of Info-Kermit Digest ************************* ------- 27-Jun-84 12:48:11-EDT,11663;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Jun 84 12:47:24 EDT Date: Wed 27 Jun 84 12:46:29-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #11 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 27 June 1984 Volume 1 : Number 11 Today's Topics: New Release of DEC-20 Kermit New Release of PDP-11 Kermit Unix Kermit Fix Floating Windows & Graphical Views Kermit Supported by Crosstalk XVI Kermit for PCjr? IBM 3270 Protocol Emulators and Unix Kermit ---------------------------------------------------------------------- Date: Tue 26 Jun 84 18:32:29-EDT From: Frank da Cruz Subject: New Release of DEC-20 Kermit To: Info-Kermit@CUCS20 A minor new release of DEC-20 Kermit is available, 4(224), incorporating several fixes and features suggested by Ken Harrenstien (KLH@SRI-NIC): The GET command allows source & destination filespecs to be given separately. Type GET ? to see how this works. Characters like ?!;@ can be included in the remote filespec in GET by prefixing them with CTRL-V (which is stripped before sending the name to the remote host). This is the normal TOPS-20 way of quoting funny characters in commands. Refuse links on file-transfer tty, not controlling tty! Restore advice and links to former state after file transfer. ------------------------------ Date: Tue 26 Jun 84 19:24:26-EDT From: Frank da Cruz Subject: New Release of PDP-11 Kermit To: Info-Kermit@CUCS20 Announcing a new release of PDP-11 Kermit, 2.17, from Brian Nelson at the University of Toledo (ATSBDN@UOFT01.BITNET). This release cleans up some minor problems with the one distributed at DECUS in early June. Included are some performance improvements, some fixes for adapting to new releases of RSX-11/M and M+ (4.1 and 2.1, respectively), and improvements in the support for RT-11, particularly in terminal i/o. Also, the new release will run on the PDT-11 RT-11 system, whereas the previous release would not. The files (61 of them) are in KER:K11*.*. KER:K11INS.DOC describes the files, operating system requirements, etc. KER:K11CMD.MAC contains the edit history, which describes the changes in detail. ------------------------------ Date: 25 Jun 84 21:40 PDT From: mike@LOGICON.ARPA To: cc.fdc@COLUMBIA-20 Subject: UNIX KERMIT fix Howdy... Just wanted to confirm something you stated earlier in one of the KERMIT digests. This concerns a UNIX problem, which this site is having as well. It seems that when you are transmitting a file from an outside micro to the UNIX kermit, the micro never seems to get the word to stop. Although the file is transfered ok. You stated in a recent digest, that the fix was to put a sleep(1) call in before the terminal parameter change (UNIX call is stty()). This really works! I have installed your suggested correction with no apparent side effects, except the elimination of the micro sending problem. Thanks again... Mike Parker {alias mike@LOGICON.ARPA} [Ed. - Thank you. I've also been receiving lots of comments and code in response to "Call for Unix Kermits"; keep them coming!] ------------------------------ Date: 26 Jun 1984 14:13:30-MDT From: Leah F. Miller C-10 To: cc.fdc@COLUMBIA-20 Subject: Floating Windows & Graphical Views Frank, Would you summarize the recent Info-Kermit debate on optimizing Kermit performance, for those of us who came in late? I've received several calls in the last few days from people who work on different projects but have the same question : could they use Kermit to send graphics output to other states and/or Canada? Do you know of anyone who is shipping graphics data, if only on a workstation-host basis? Leah Miller ------------------------------ Date: Wed 27 Jun 84 10:01:50-EDT From: Frank da Cruz Subject: Re: Floating Windows & Graphical Views To: lfm@LANL.ARPA Well... I think there is general agreement that Kermit should provide some performance options, like sliding windows (multiple unacknowledged packets) and longer packets, and perhaps ways for the two sides to agree to send certain control characters "bare". However, the exact mechanisms for doing these things have yet to be specified. In the meantime, Kermit can be used for sending any kind of data over any kind of link, though you may find yourself paying more in packet charges over public networks, and you may have to adjust packet length or timeout intervals when long delays are involved, like you have with satellite links. If your graphics files are vector encoded, then you won't see any particular savings from the repeat count compression, but bit maps might get compressed a lot. - Frank ------------------------------ Date: Tue Jun 26 1984 14:44:09 From: Marco Papa To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: Kermit supported by Crosstalk XVI >From the latest issue of PC-WEEK: "Crosstalk XVI version 4.0, which will be shipped in August, will support the Kermit protocol. Crosstalk will contain hooks for Kermit, which users will be required to individually license from Columbia." Crosstalk XVI is a product of Microstuf. Congratulations you guys at Columbia. Marco [Ed. - We agreed to let Microstuf do this with our normal stipulations, namely that they don't raise the price just because they put Kermit in it, and they give credit to Columbia for the protocol. These stipulations are spelled out in greater detail in KER:COMMER.DOC.] ------------------------------ Date: 26 Jun 84 2322 PDT From: David Fuchs Subject: Kermit for PCjr? To: info-kermit@COLUMBIA-20.ARPA Are folks running Kermit on the PCjr with the IBM built-in modem? I haven't been able to get SEND or RECEIVE to work at all, and regular terminal emulation only works after some irreproducible set of "F " commands are given. It can't be that the modem is flakey, because the communications program on the JR Sampler disk works fine talking to the same target TOPS-20 system. I must be missing something. Does anyone have a definitive set of magic incantations that make things work? Is there some Kermit command that must be given (other than SET BAUD 300) before CONNECTing? Is there some "latest version" of Kermit that must be used? Are all users this clueless? My only excuse is that COLUMBIA-20 has been closing all FTP connections before it manages to send a complete copy of any documentation file... [Ed. - IBM PC Kermit 1.20 works just fine on the PCjr serial port, except that the screen display during file transfer looks strange on a 40-column screen. However, Kermit doesn't work at all on the modem port. Internal modems are poison. We'll try to get it workin on the modem port as time permits (many things are higher on our list), meanwhile, contributions will be gratefully accepted. I don't know why FTP should be having trouble, except that COLUMBIA-20 is field testing a new version of TOPS-20.] ------------------------------ Date: Tue, 26 Jun 84 12:34 PDT From: "Chase Lila"@LLL-MFE.ARPA Subject: ibm3270 Protocol Emulators and Unix Kermit To: Info-Kermit@COLUMBIA-20.arpa Has anyone had any experience getting the CMS Kermit to work through this protocol emulator? ------------------------------ Date: Wed 27 Jun 84 11:02:17-EDT From: Frank da Cruz Subject: Re: ibm3270 Protocol Emulators and Unix Kermit To: Info-Kermit@COLUMBIA-20.ARPA A protocol emulator is a device that allows ordinary ASCII terminals or PCs that emulate them to be connected to IBM systems that only know how to drive 3270 series EBCDIC terminals, which are normally connected via coaxial cable to a 3274 cluster controller, which is either locally or remotely connected to an IBM channel. The 3270 is the only kind of terminal that VM/CMS really understands; it is a full-screen block-mode terminal with lots of function keys. Protocol converters are popular at sites that have a mixture of IBM and non-IBM timesharing systems. They allow the same terminal to be used with both kinds of systems. They interpret the host's 3270 screen formatting commands into appropriate escape codes for various ASCII terminals, do EBCDIC/ASCII data conversion, and translate the terminal's function key output or other keystroke sequences into 3270 function key signals. A wide variety of protocol emulators is available on the market. They may be cards you plug into your PC (like the Irma board), little boxes on your desk, bigger boxes (like the Datastream) near your mainframe or terminal switch, minicomputers like the IBM Series-1 based Yale IUP, or IBM host resident software like SIM3270. Their operation can vary from straightforward translation and interpretation to highly optimized screen management, in which only those characters on the screen that need to be changed actually are changed. Kermit works on the assumption that data -- at least printable 7-bit ASCII characters -- will be received exactly as they are sent. Protocol converters violate this assumption by doing EBCDIC/ASCII conversion on the data, inserting escape sequences, and possibly reformatting it. Therefore, Kermit (in its present form) cannot operate through a protocol converter. For now, there are several other options. If you have an Irma board, you don't need Kermit, because you get software with the Irma board to do file transfer. Same for the Yale IUP. The same may be true of some other protocol emulators. One of our projects this summer will be CMS Kermit. In addition to bringing it up to a more advanced level, providing server functions, etc, we will be looking at this problem. It won't be easy, because the changes have to be made not only in CMS Kermit (and ultimately also MVS/TSO Kermit, whenever that appears), but also in any PC Kermit that wants to talk to it. The PC, rather than dealing with sequential streams of ASCII characters clearly delimited into packets, will be receiving perhaps randomly ordered screen formatting commands. A possible approach would be to have CMS Kermit send a clear-screen command to signal the beginning of a packet, send the contents of the packet as line 1 (with awareness that the protocol emulator might "optimize" it by converting spaces to tabs or cursor positioning commands), and signal that the packet is finished by putting something on line 2. Meanwhile, the PC builds its screen interally, interpreting any escape codes (which it presumably already knows how to do because of the VT52 or H19 emulation code in most PC versions of Kermit), and then goes back to read the result as a packet when it gets the completion signal. Well... we'll try doing something like this with the CMS and MS-DOS Kermits. Who knows, maybe it'll work. If it does, then there's the task of getting the same functionality into all the other Kermit implementations. Comments or suggestions about this would be most appreciated. ------------------------------ End of Info-Kermit Digest ************************* ------- 3-Jul-84 09:56:45-EDT,4107;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 3 Jul 84 09:56:21 EDT Date: Tue 3 Jul 84 09:55:30-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #12 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Tuesday, 3 July 1984 Volume 1 : Number 12 Today's Topics: MVS/TSO Kermit Coming BYTE Article Available On Line Kermit for the Morrow MD-11? Bug in Kermit-20? Wang PC Kermit? ---------------------------------------------------------------------- Date: Thu 28 Jun 84 22:09:47-CDT From: RON RUSNAK Subject: TSO-KERMIT To: Info-kermit@COLUMBIA-20.ARPA I am currently putting the finishing touches on a TSO-KERMIT which is based on the CMS version. Where would you like me to send it? We have a BITNET connection here, if that helps. I should be ready to ship it out next week. Ron Rusnak SYSRONR@UCHIVM1.BITNET SYSTEMS.RON@UCHICAGO.MAILNET [Ed. - It will be announced as soon as it shows up.] ------------------------------ Date: Fri 29 Jun 84 20:24:10-EDT From: Frank da Cruz Subject: BYTE Article Available On Line To: Info-Kermit@CUCS20 The July issue of BYTE Magazine is published, so now I'm allowed to make the text of the article (at least as it was when we submitted it) available on line. It's in KER:BYTE.*. BYTE.DOC is readable at the terminal, BYTE.MSS is Scribe source, which can be run through Scribe to produce output for a variety of devices, including multifont laser printers. - Frank ------------------------------ Date: Wed, 27 Jun 84 18:28 GMT From: JONES%LLL@LLL-MFE.ARPA Subject: Kermit for the Morrow MD-11 To: info-kermit@COLUMBIA-20.ARPA Has anyone brought up a version of Kermit on the Morrow MD-11? The generic CP/M 3 version did not seem to work when I tried it out. The MD-11 runs CP/M 3.0 and is very different as far as communications from the MD-1,MD-2, and MD-3. Thanks, Dan Jones ------------------------------ Date: Sat 30 Jun 84 17:51:33-PDT From: Jim Lewinson Subject: Bug in Kermit-20? To: cc.FDC@COLUMBIA-20.ARPA I have noticed the following behaviour wich I don't think is quite correct. 1) Start up your favorite version of Kermit-20. 2) Tell it to go into server mode. 3) Type "^A# N3" at it. This looks to me like a NAK for packet 0, with a length of 3. This is the same packet that many Kermits throw at me when they start up, so I think the checksum is correct. Kermit-20 produces a big ugly error about "un-implmented server command". Surely this is not correct. It should simply NAK back at me if it doesn't make sense. I don't know if this is related, but I have gotten a similar error when I have disconnected (briefly) the rs232 link to the modem when Kermit-11 and Kermit-20 were talking back and forth. needless to say, the transfer failed. (I was playing to see if it could handle lost packets.) Jim ARPA: Jiml@Score [Ed. - Good point. You're right, it should ignore NAKs when in server command wait. I'll fix it in Kermit-20 next time around.] ------------------------------ Subject: WANG Kermit From: ABN.20E-548@USC-ISID.ARPA To: info-kermit@COLUMBIA-20.ARPA Message-ID: <[USC-ISID.ARPA] 3-Jul-84 09:30:50.ABN.20E-548> Has anyone seen or heard of Kermit to run on the Wang PC under MS-dos? I have tried to modify the IBM-PC version but cant get it to work. Too many diferencies in things like port addresses and screen escape sequences. Walt [Ed. - Kermit for the Wang PC with MS-DOS is on the way. You're right, the port and screen stuff is very mysterious.] ------------------------------ End of Info-Kermit Digest ************************* ------- 9-Jul-84 12:39:25-EDT,19350;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 9 Jul 84 12:38:42 EDT Date: Mon 9 Jul 84 12:00:28-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #13 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 9 July 1984 Volume 1 : Number 12 Today's Topics: RSX-11 Kermit Terminal Emulator Problem Bad Kermit-11 Files K11ASM.M41, K11*.XRF Fixed Kermit-11 & RT11 Kermit File Servers Kermit for HP-1000? What is the Kermit Protocol Named After? [Little] CP/M-86 Kermit Progress Report Kermit-Based Network at Rice Conversion of CROSS Apple Output from Hex to Binary Problem Installing DECsystem-10 Kermit Apollo Kermit ---------------------------------------------------------------------- Date: Tue, 3 Jul 84 16:31 GMT From: HAMMON%LLL@LLL-MFE.ARPA Subject: k11rsx term emulator problem. To: info-kermit@COLUMBIA-20.ARPA I just installed the new kermit-11 on my 11/23 (128kw rsx11m v4.1B) and have experienced some peculiar problems with the terminal emulator. Terminals are driven with an MBD 8-line DZ11. This behavior occurs when trying to talk to our dec-20 or just looping back(plugging in the output into another line on the distribution panel). When typing in characters, what's on the screen is always one character behind what I'm typing. To end a line it frequently takes either an extra cr or something like an xon. When receiving characters, It stops after 4 or 5 characters and I must keep hitting xon to get more groups of 4 or 5 characters. Occasionally I lose characters when receiving. I've had no problem with transferring files either way. Maybe the problem is related to the way a dz buffers characters. Any suggestions would appreciated. thanks, -randy- - hammon%lll@lll-mfe.arpa- ------------------------------ DATE: TUES, 05 JUL 84 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: RSX TERMINAL EMULATION Don't know about being one character behind for RSX on his 11/23. I have never seen that happen, and can't really think of why it would do that. I will try some tests and see if I can come up with anything. ------------------------------ DATE: FRI, 07 JUL 1984 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: KERMIT-11 AND RT11 hate to do this to you, but I found the reasons for my flakey problems in the rt11 file create and open code. I had the agr list for a macro called .DSTAT (it looks to see if a driver is resident) swapped. This would sometimes succeed (based on garbage on the stack) and proceed to overwrite the rt11 parsed filename and device block for the open. I can send something next week to fix your stuff. Sorry about that, but perhaps you can see why I took so long to do the RT11 conversion. I/O under RT is a royal pain. brian nelson [Ed. - Will announce new stuff when it arrives.] ------------------------------ Date: Thu, 5 Jul 84 09:07 PDT From: "Hammon Randy"@LLL-MFE.ARPA Subject: munged kermit file To: info-kermit@cucs20.arpa I just discovered that the copy of k11asm.m41 is munged. -randy- hammon%lll@lll-mfe.arpa ------------------------------ Date: Thu 5 Jul 84 18:30:46-EDT From: Frank da Cruz Subject: Re: munged kermit file To: "Hammon Randy"@LLL-MFE.ARPA Thanks for pointing it out, there's a fixed one now. Also the two K11*.XRF files were bad and have been replaced. - Frank ------------------------------ Date: Mon 2 Jul 84 14:46:19-PDT From: Bruce Tanner Subject: Kermit File Servers To: cc.fdc@COLUMBIA-20.ARPA Frank I read the second part of the BYTE article this weekend - good work. I was pleased to see the college acknowledged at the end. The article also touched on a subject I have been thinking about the last few weeks, Kermit file servers. The goal of micro-mainframe communications is transparency; the user (or even the user's program) doesn't know that the information is not at the micro, but at the mainframe. It seems that a Kermit server on the mainframe is 90% of what is needed to service requests for data, although the protocol would need to know about logical sectors or even records of a file. The micro side of the problem is tricky, you could either have a general purpose subroutine to put into all your programs (practical for very few applications) or modify the operating system. Luckily, MS-DOS has device drivers that can be installed. If I can have a driver that makes MS-DOS thing a chunk of memory is a virtual disk, I would think that a Kermit driver could make requests to another virtual disk ship requests for logical sectors to the server. I seem to recall that the Macintosh has hooks in it for a 'smart' file server. Perhaps the same type of thing could be done there. I'm not sure this is a Kermit topic or not, since applications based on the Kermit protocol (e.g. SMTP servers) were frowned upon as topics for discussion. This is just a bit of 'blue sky' to see what you think. [Ed. - You're right, it's sort of beyond what most people like think Kermit is for. But it sounds a lot like a project we're working on as an outgrowth of Kermit. It also sounds a bit like a project at Rice University -- see below.] Different topic: KERMIT - KL Error free Reciprocal Micro computer Interface over Terminal lines (or something like that) Initial Kermit release Kermit - Celtic for 'free' Various Kermit sources Kermit is not an acronym, it was named after Kermit the frog. BYTE What gives? -Bruce [Ed. - See below.] ------------------------------ Date: 3 Jul 1984 1442-GMT From: CAROFF at Ames-VMSB Subject: Kermit To: cc.fdc at columbia-20 Is there a software tools available for the hp1000 that you have heard of? I have not unfortunately. But I will look into that version. [Ed. - The Software Tools version of Kermit contributed by Ken Poulton runs on the HP3000. Ken says it should also run on the HP1000. In both cases, you need the stuff from the Software Tools tape for your system. Call the Software Tools User Group at 213-647-0272 for further information about getting the "tools" for the HP1000, or write to Software Tools User Group 1259 El Eamino Real #242 Menlo Park, California 94025 ] By the way, I just finished reading your kermit article and noticed that kermit is NOT an acronym. What the hell did you name it after a frog, I just do not quite get it?? There must have been a reason! Thanks much, Mike [Ed. - What do you have against frogs? In fact, we called the protocol Kermit in honor of Kermit the Frog. However, once we started exporting Kermit programs, we became a little bit worried about getting in trouble with the name, so we thought we'd better make it an acronym. The "KL10 Error-free..." etc was the best we could come up with, but it was pretty lame. Later, Bill Catchings, while looking through name books for his new baby (who is not named Kermit) noticed that the name Kermit comes from the Celtic word for "free". We liked that a lot better than the acronym. Then when we went to publish the article in BYTE, the editors suggested we contact the Muppet people to settle the matter. It turns out that "Kermit" is a registered trade mark of Henson Associates Inc, and no product may be called "Kermit" without their blessing. Well, fortunately, "our" Kermit is not a commercial product since we don't sell it for profit, and Henson Associates Inc kindly granted us permission to use the name, provided we acknowledge them in our publications, as we have begun to do. It's not easy being green...] ------------------------------ Date: Fri, 6 Jul 84 09:37:51 CDT From: Don Johnson To: CC.FDC@COLUMBIA-20.ARPA, ... Subject: kermit-based network at Rice To the Kermit world: We at Rice are writing a Kermit protocol package as part of a network we are developing. Thought I would describe what we are doing. We are bringing up a campus-accessible mail system and file storage facility. The presumption is that most user nodes on the network are personal computers which are not multiprocess machines. Consequently, they cannot be assumed to be at a physical location at any one time, cannot accept mail which arrives at a random instant of time, and the user could be anybody. A good model for our system is that of a post office. To send/receive mail and packages, the PC user must explicitly go (connect) to the post office to access mail services. Our post office is an IBM 4341 and the communications medium is a CBX (made by ROLM). Thus, we communicate with RS-232, with a defined datarate of (hopefully) 9600 baud. We assume (and have to because of the IBM) that the datapath is only seven bits wide. As we want to send Mac files (both resource and data), we needed a protocol that would support 8-bit transfers in this environment. In an attempt not to reinvent the wheel, we settled on Kermit as our 'data-link layer' protocol and are writing same for the Mac, the IBM PC, and the 4341 as well as one for MVS. We do NOT support time sharing services on this net, so we do not do anything in regards to what could be termed 'terminal emulation' other than for a dumb tty. 'Mail' for us is straight ASCII that can be read on any PC regardless of what it may be. 'Packages' can be most anything, including operating system specific (like applications). The system will prepend a header to each packages explaining its contents. We know what goes in this 'content' field, but no specific format has been laid out. Thus, we are not writing what most of the world refers to as a 'Kermit'. Rather, we are writing the protocol portion of it as a module which looks like a device driver (open, read, write, etc.). The 4341 side is a server Kermit. We are supposed to have the net up (walking, maybe crawling) by August 17. We will probably make that deadline. If any of you want this stuff, you are welcome to it when completed. By the way, the MacKermit is being written in Pascal under the Workshop environment on the Lisa. Don Johnson dhj@rice [Ed. - Sounds a lot like the project we're working on, except with a VAX at the center and DEC PCs (Rainbows with MS-DOS and Pro-350s with Venix), with Macs to be added later. We too have a deadline...] ------------------------------ Date: Fri, 6 Jul 84 10:27 EDT From: "John C. Klensin" Subject: [little] CP/M-86 Kermit Progress Report To: Frank da Cruz Sorry for the long delay in getting back to you on my CP/M-86 Kermit struggles. I have been working on it on and off, with repeated interruptions to get a new multinational research project in place (the joys of soft money). In any event, the state of things at the moment is as follows: Overall changes required and made: - A few lines of conditional assembly code have been placed into module 'kermit.a86' to identify the version for Concurrent differently and to (for Concurrent) narrow down the displays so that they fit in in a reasonable window. Also added support for a new SET command to set the width of a tab. I hope this is acceptable, I needed it because Multics (along with some UNIX implementations, so this is not completely site-specific) is a "tab every 10" machine, rather than the DEC and imitators "tab every 8". The SHOW piece is in KERMIT (since the width is always determinable), SET is in kerio so that people don't need to support it where it does not make sense (e.g., rainbow). - modifications to "kertrm" for tab widths, mostly a few variables that seemed logically to belong there. - everything else is in KERIO, including SET TAB-WIDTH for the PC. Versions of KERIO I seem to have spread out here: - IBMPC, CP/M-86, semi-generic: seems to work, using character-at-a-time retrievals, rather than an interrupt-driven ring buffer. Seems to mostly work, as long as the speeds are moderate (<=1200 Baud), and then not well at 1200. This is all as one might expect. I did it in frustration at the next one in order to have something to work with/from. -- IBMPC, CP/M-86, interrupt driven: code has been assembled, tested, and extensively desk-checked. I am now on a hunt for something that will explain in a way that my weak mind (which has not tried to write assembly language in anger for maybe 16 years but which was writing channel programs and real time interrupt handlers for years before that) can understand what the relationship is between programming for the 8250 and for the 8259 and what it is that I am saying to, and expecting from, the latter. I have managed to figure out what seems like it ought to be enough from studying the code in PCDOS pckermit, and from the Tech Ref, and bits from the several "IBMPC esoterica" books I have around here, but the books stop before that and that part of pckermit is probably clear only when people know what it is doing. Anyway, the thing loads successfully, initializes the ports, and dies in a mode in which (jodging from the lights on the modem) successfully sends characters in terminal mode, but cannot manage to discover them when they come back and get them to the terminal emulator. It also leaves the PC in that state, even across warm boots (PCDOS kermit resets it correctly). -- Concurrent CP/M-86: now that I have a full set of documents (Digital Research has a new trick, they send you a manual with the OS that is strictly user-oriented and tell you in it that there is a programmers guide, which you need to order, pay extra for, and (more important) wait for. That one tells you about yet another manual which contains the esoterica that you then have to try to order. Of course, they have gone out of the retail business, and their retaillers have not heard of manual set 2, much less the esoterica book), it looks quite easy, given that all of the work is managed by the operating system, including buffering, parity (if wanted), and XON/XOFF processing. I have a version desk-coded, but have not tried to assemble it yet, for two reasons: (a) I have been too busy getting frustrated by the CP/M-86 version. (b) the size of their serial buffers, as delivered, is 16 characters. I don't fancy trying to run kermit with 16-char packets, and Concurrent runs only on fairly large machines (256K absolute minimum) anyway. So I have been trying to find out how to make the queue sizes larger. I was assured when I finally got a technical person at DRI that it was possible to do so, I am still trying to figure out how. If I can get the queue sizes up over 96, things should go very nicely. -- Since Barry Devlin seems to understand the Serius/Victor, and since the availability of technical documentation on it here is photocopies of engineering documents with handwritten notes in the margins, and since he seems (from kermit-info) to be about to take on the CP/M-86 version, I hereby will it back to him. The IBM is clearly more than I can handle right now without taking on another machine, especially as an uncompensated activity (MIT considers my fussing with this stuff an 'outside professional activity' which translates as hobby for which I can't bill salary). - I also have (trivial) SET TAB-WIDTH code for the rainbow and apc versions of KERIO to maintain compatability. john [Ed. - If any of the CP/M-86 Kermit contributors would care to comment on what John has done so far, feel free.] ------------------------------ Date: Mon 9 Jul 84 01:13:55-EDT From: Peter G. Trei Subject: CROSS hex -> binary conversion. To: info-kermit@CUCS20 I realise that there are only a limited number of people out there working on Apple DOS Kermit, but I would like to spread the use of a handy programming tool, which may be adaptable to use with other micros. When you compile a micro source code file using the CROSS compiler, the output is either one of a number of binary representations, or one of a number of hexadecimal representations. Frequently, the binary representation is nothing like that which your micro's kermit expects to upload. This is a problem with Apple kermit, and I have created a program, APPLEB.SAI, which converts one of the hexadecimal outputs of the CROSS compiler into an 8-bit file which can be directly uploaded to an Apple using kermit, and run. This is a considerable aid not only to developers, but also to people wishing to upload updates. Directly uploading the binary form is at least twice as fast as uploading, then converting, a hexadecimal representation. APPLEB.SAI is written in the SAIL language, which may not be available at all sites. However, the source is heavily commented, and it should be easily adaptable to PASCAL. It should also be fairly trivial to cause it to output a number of different binary formats appropriate for different micros. Peter Trei oc.trei%cu20b@columbia-20 [Ed. - The program is in KER:APPLEB.SAI.] ------------------------------ [Ed. - I lost the original message, but it was from someone who complained of having trouble building DECsystem-10 Kermit because of a missing file, B361LB.REL...] Date: Fri 6 Jul 84 22:24:03-EDT From: Nick Bush Subject: Re: [LCG.KERMIT: TOPS-10 KERMIT] To: EIBEN@DEC-MARLBORO.ARPA B361LB.REL is distributed along with RMS-10 on the Digital supported CUSP tape. - Nick ------------------------------ Date: Thu, 28 Jun 84 17:05 CDT From: Tom Linnerooth Subject: Re: Apollo KERMIT To: Cargo@HI-MULTICS.ARPA Frank slightly misinterpreted my intent. I am not actively working on KERMIT for the Apollo. We simply don't have the manpower at the present time to work on that problem. If it were available, however, I would probably install it. The Apollo's we have were purchased from Mentor with CAD software. Mentor provided a simple protocol written in Pascal that handles file transfers to and from the Apollo over a TTY line. It checks the transfer by a simple checksum. We were able to adapt their program to our needs in just a couple of days, and we are reliably transferring quite large files now. That satisfied our immediate need. I have not heard of anybody else who is interested in an Apollo implementation of KERMIT, but I think it's a matter of time since Apollo rings are becoming quite popular. There is an Apollo mailing list on the net, and a message broadcast there might bring some help. I didn't try that. Good luck, and I would be interested in what you find out. Tom ------------------------------ End of Info-Kermit Digest ************************* ------- 12-Jul-84 10:31:24-EDT,14576;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 12 Jul 84 10:30:40 EDT Date: Thu 12 Jul 84 10:29:02-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #14 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Thursday, 12 July 1984 Volume 1 : Number 14 Today's Topics: Incorrect Issue Number on Last Digest Kermit on a DG MV/x0000 running AOS/VS? Bug in Kermit-10, VMS Kermit, and Pro/Kermit Re: RSX-11 Kermit Terminal Emulator Problem RSX TT EMULATOR AT&T PC Kermit Problems Kermit, DCA and the DDN Kermit Boot Program Kermit for MVS/TSO Kermit-11 Problem Between RSTS/E Systems Software Tools for HP-1000 ---------------------------------------------------------------------- Date: Thu 12 Jul 84 09:32:56-EDT From: Frank da Cruz Subject: Incorrect Issue Number on Last Digest To: Info-Kermit Sorry, the last issue was number 13, not number 12. Thanks to all of you who pointed out the mistake. - Frank ------------------------------ Date: Mon 9 Jul 84 09:32:56-PDT From: Michael A. Haberler Subject: Kermit on a DG MV/x0000 running AOS/VS To: info-kermit-request@COLUMBIA-20.ARPA I am interested in bringing up Kermit on a DG MV series machine running AOS/VS. Has anybody out there done that before? - mike [Ed. - Kermit is available for DG machines running AOS, but first you must have the Software Tools Package. For futher information about the Software Tools package, contact: Software Tools User Group 1259 El Camino Real #242 Menlo Park, CA 94025 213-647-0272 The AOS implementation of Kermit is available in KER:AOS*.*. There's also a newer, more advanced Software Tools Kermit implementation which has been done for the HP3000 and Univac 1100 -- it would be desirable to adapt any system- dependent parts from the AOS-specific version to the newer version and use that. Anyone who does this is encouraged to contribute it to the Kermit collection so we can discard the older program. The newer one is in KER:ST*.*.] ------------------------------ Date: Mon 9 Jul 84 13:35:40-EDT From: Nick Bush Subject: Bug in Kermit-10, VMS Kermit, and Pro/Kermit To: INFO-KERMIT@CUCS20 There is a minor bug in these three Kermits (the joys of a common source). The problem will only show up when sending files to a Kermit which has requested 94 character messages with an even valued ASCII character as the end of line character (like line feed = 12octal). One Kermit implementation which requests this set of parameters is LCTERM. The problem is easily avoided by using the SET SEND PACKET-LENGTH command (PACKET_LENGTH in VMS Kermit) to set the maximum packet size to something less than 94 characters. This will be fixed in the next versions of these Kermits. - Nick ------------------------------ Date: 9 Jul 84 17:54:09 EDT From: Glenn J. Joyce To: Info-Kermit@CUCS20 Subject: Re: RSX-11 Kermit Terminal Emulator Problem I've seen the same behavior that he is talking about and the solution to the problem (at least in my case) was pretty simple. If you have a full duplex terminal driver and have your lines set to half duplex, you will get the results that he reports. If you set the line that you will connect over to full duplex (via the MCR command SET /FDX=TTnn:) and set the line to which your terminal is connected to full duplex, the terminal emulator will work just fine. If either of those lines are in half duplex mode, the terminal emulator appears to work, but is always a few characters behind. You can clear the pending typein/typeout with a few CR's or XON's. (You can see the line characteristics if you do a DEV TTnn: to the > prompt) - Glenn Joyce ------------------------------ DATE: TUES, 10 JUL 1984 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: RSX TT EMULATOR Sounds reasonable (?). This may have been caused by an edit accidently removing the sf.smc for fdx on the connected line in k11con.mac, which will be there when the next tape goes out tomorrow. [Ed. - New Kermit-11 will be announced as soon as it arrives. See below for another problem with this program when it's running under RSTS/E.] ------------------------------ Date: Tue 10 Jul 84 07:22:01-PDT From: Ted Markowitz Subject: AT&T PC problems To: Info-Kermit@COLUMBIA-20.ARPA I'v just received a model of the new AT&T PC and tried it with the standard IBM PC version of KERMIT since it claims to be 'compatible'. Well, no such luck. After a few lines of output in terminal emulation mode it garbles the text something fierce. It is 8086 based and does have a faster clocking (8Megahertz). Any ideas to get this to work? Another version of KERMIT perhaps? --ted [Ed. - The forthcoming release of MD-DOS Kermit will have a small module in which the system-dependent primitives are defined. We will have such modules for the IBM PC & XT, DEC Rainbow, HP-150, Wang PC, and "generic" MS-DOS. You can start with the generic MS-DOS Kermit; it may work as is, or you may have to twiddle an address or two. However, since it goes through DOS for all services, it will be slow. If it's too slow for you, then you can write system-dependent primitives for your new AT&T system. The new release will be available Real Soon Now.] ------------------------------ Date: 10 Jul 1984 09:29-PDT Subject: KERMIT, DCA and the DDN From: Geoffrey C. Mulligan (AFDSC, The Pentagon) To: Info-Kermit@COLUMBIA-20 While I was out at DCA I heard talk that they working to upgrade the C/30 TACs. This upgrade would be both hardware (ie a new C/50) and software (ie user friendly). Along with the software upgrade they are considering implementing some protocols in the TAC for PC <-> DDN file transfers (recognizing that character-at-a-time is very wasteful of DDN resources). On the top of the list of protocols is KERMIT! I am not sure (nor are they) exactly how it will all work, but the initial idea is that the TAC would receive the whole file and then use FTP to pass it on to the host. Does anyone have any comments or ideas? DCA also has quite a number of IBM-PCs with integral Hayes 1200B modems. Is there a version of KERMIT that will drive the modem. Even if it does not dial (another program could do that), it has to be modified to use the Hayes modem as opposed to the serial port... help?!?!? geoff [Ed. - Most Kermit programs, including MS-DOS Kermit, do not contain explicit code for modem control. We have always advised Kermit users to steer clear of internal modems.] ------------------------------ Date: Tue 10 Jul 84 23:51:27-PDT From: Jim Lewinson Subject: Kermit Boot Program To: cc.FDC@COLUMBIA-20.ARPA KerBoo is a small Fortran program that implements the Kermit Protocol to allow you to receive files. The idea is that you already have both a Kermit on one machine and a somewhat featureful Kermit in "HEX" format for the other. The purpose behind the program is to allow you to send the HEX file to the machine with nothing with some sort of error detection and recovery (By using the Kermit on the machine you have one running on.) This program is VERY dumb. It has no timeouts, no 2 or 3 character checksums, no eighth bit quoting, and no protection. It doesn't even try to turn off echoing. In fact, I could spend all day telling you the things it does not do. It does do one thing, it lets you send using Kermit to a machine that doesn't have anything. I have tried it under VMS, and Versions 3.2 and 4.0 of RSX-11M, and it seems to work. If it doesn't, it will most likely be obvious why it is failing. ("Hmmm - This Fortran Doesn't allow file names in opens.") I have tried to write very generic Fortran. Happy Kermiting, Jim Lewinson Breuer & Company Bedford, Massachusetts [Ed. - The files (3 short ones) are in KER:KERBOO*.*.] ------------------------------ Date: 9 July 1984, 13:18:27 CST From: SYSRONR at UCHIVM1 To: DFTCU at CUVMA Subject: Kermit for MVS/TSO I have completed a version of Kermit for MVS/TSO. I have been able to test it out in our environment, but I have not tested it on a raw TCAM. In our environment we are using a mod to the 3705 to make everything look like a 2741. This means that everything is translated from ASCII to 2741 code to EBCDIC before it reaches KERMIT. It also supplies XON codes when the host has put up a read. It is my belief that normal TCAM will handle ASCII to EBCDIC translation just fine, and I believe that TCAM will also supply XON codes when it has a read up. However, I have been unable to gen a TCAM here with raw Teletype 33-35 support to test it out. If you wish I will sendfile you the the following pieces. IBMKERM ASSEMBLE IBMDYNA ASSEMBLE IBMKERM DOC I would like to put in a word for adding support to all of the micro KERMITs for the SET START-OF-HEADER command. In our MVS/TSO environment the host cannot receive a CNTRL-A. We have therefore added the SET START-OF-HEADER command to the IBM-PC version and to the APPLE II version. Ron Rusnak [Ed. - Chicago's MVS/TSO Kermit will be announced as soon as it arrives. The forthcoming release of MS-DOS Kermit will have commands to changes the packet-start character.] ------------------------------ DATE: WED, 11 JUL 84 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: KERMIT-11 PROBLEM BETWEEN RSTS/E SYSTEMS May as well send the following note out on info-kermit. A problem has been found with sending binary files on RSTS/E with attributes when the file sent never had any on the sender's system. It's unusual and should not normally cause a problem. ; update to the last procedure in K11ATR.MAC .sbttl finish up the update of rms file attributes to output ; A T R F I N ; ; If the file was send in image mode, and we have been sent ; valid attributes (basically, the sender's IFAB), then call ; PUTATR to place these attributes into our output file's ; IFAB so they will get updated. ; ; ; Note: 11-Jul-84 17:12:49 BDN, edit /19/ ; ; Note that for RSTS/E, we have an unusual problem in that if ; the sender sent a stream ascii file (most likely a file with ; NO attributes) over and the sender said it's binary, then ; RMS-11 sends GARBAGE for the VFC header size. When this data ; is wriiten into the output file's IFAB, RMS11 finds invalid ; data in the IFAB and writes attributes to disk with the last ; block field (F$HEOF and F$LEOF) equal to ZERO. Such a file ; would thus be unreadable to PIP, RMS and other programs that ; look at the file attributes. The fix is one of two things. ; One, we can clear the invalid VFC size and fudge the record ; size and maximum record size to something usable (like 512), ; or we can simply ignore the senders attributes and let the ; file stand as a FIXED, NO CC, recordsize 512 file. Rather ; than to try to fix the attributes, we will simple ignore the ; attributes if the sender said that the file is stream ascii ; with a garbage VFC. Since the attributes are only used if ; the transfer was in image moed, this will not affect normal ; files, only files like DMS-500 files that have no attributes ; but must be sent in image mode. ; Of course, the sending Kermit-11 can always be given the SET ; ATT OFF and SET FIL BIN and the receiving Kermit-11 be given ; the SET FIL BIN and the issue will never arise. ; ; The mods are noted with /19/ after the statement. atrfin::save ; just in case please tst @r5 ; lun zero ? beq 100$ ; yep tst at$val ; valid attributes to write ? beq 100$ ; no cmpb at$typ ,#binary ; did we get this as a binary file? bne 100$ ; no mov #at$fab ,r1 ; yes tst (r1)+ ; valid data present ? beq 100$ ; no cmp @r1 ,#2000 ; /19/ stream ascii ? bne 30$ ; /19/ no cmp 16(r1) ,#177400 ; /19/ garbage for the vfc header size? beq 90$ ; /19/ yes, forget about the attributes 30$: calls putatr ,<@r5,r1> ; /19/ update the ifab for the file 90$: clr at$typ ; /19/ no longer valid please clr at$fab ; no longer valid please clr at$val ; no longer valid please 100$: unsave ; output file and exit return 200$: .byte 40,0 .end [Ed. - This fix will not be in the next release (the situation where it occurs rarely comes up), but in the one after that. Until then, anyone who is effected by the problem can install the fix themselves.] ------------------------------ Date: 11 Jul 84 10:16 +0200 From: W._Michael_Terenyi_%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Frank da Cruz" Subject: Software Tools for HP-1000 I have found out in the meantime that there are two implementations of the Software Tools Package on a HP1000, but I had not the time to contact the implementors yet. Larry Dwyer (408) 257-7000 x 2095 John Campbell (213) 831-3938 I try to receive the Software Tools Package for the HP1000 as fast as possible. Then I will take a closer look at the HP3000 Kermit. Regards, Michael [Ed. - This is in regards to running the Software Tools implementation of Kermit on the HP-1000.] ------------------------------ End of Info-Kermit Digest ************************* ------- 16-Jul-84 12:12:02-EDT,21753;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 16 Jul 84 12:10:19 EDT Date: Mon 16 Jul 84 11:53:26-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #15 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 16 July 1984 Volume 1 : Number 15 Today's Topics: New Kermit Available for HP-1000 New Kermit Available for Apollo Aegis Sirius Kermit(s) BREAK Indication Kermit for DEC Pro-350? Other Kermits - Sanyo, Toshiba, BBC 6502, ... Kermit-32 Problem Kermit and Modem Binary File Transfers Kermit with Knowledgeman Kermit's limit Problems with Kermit-10 RECEIVE Command ---------------------------------------------------------------------- Date: Fri 13 Jul 84 13:33:49-EDT From: Frank da Cruz Subject: New Kermit Available for HP-1000 To: Info-Kermit@CUCS20 Announcing version 1.0 of Kermit for the HP-1000/RTE-6/VM system from John Lee of RCA Laboratories, written in Fortran, capable of remote (dialin) but not local (dialout) operation. The source file is in KER:HPMKERMIT.SRC (the HP name space in the distribution area is getting tight; "M" is Roman for 1000), the documentation is in KER:HPMKERMIT.DOC. ------------------------------ Date: Fri 13 Jul 84 13:34:26-EDT From: Frank da Cruz Subject: New Kermit Available for Apollo Aegis To: Info-Kermit@CUCS20 Announcing version 1.0 of Kermit for the Apollo Aegis system from John Lee of RCA Laboratories, written in Fortran, capable of both remote (dialin) and local (dialout) operation. The source file is in KER:APOKERMIT.SRC, the documentation in KER:APOKERMIT.DOC. ------------------------------ Date: Sun Jul 8 1984 10:58:02 From: Marco Papa To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: UNIX Kermit problem Now that we are using XTs connected to our Vaxes running Berkeley UNIX, we are experiencing the following problem. When transfering a file from the XT running Kermit-86 V. 1.20 to the VAX running UNIX Kermit at 9600 bauds the transfer is aborted after the first packet is sent. PC Kermit says that it is unable to receive an acknowledgement from the host. The PC screen looks like this: Number of Packets: 2 Failed Number of retries: 5 ?Unable to receive acknowledgement from the host Instead, if we make the transfer at low speed, say 300 bauds, everything is OK. Also we have no problems when transfering files in the other direction (from the VAX to the XT), no matter which speed we use. Has anyone experienced this before? It seems that this might be a problem similar to the one that requires to insert a sleep(1) at the end of the transfer code, so that the last acknowledgement is not lost. Marco Papa ARPA, CSNET: papa.usc-cse@csnet-relay UUCP: ..!randvax!uscvax!papa [Ed. - Anyone out there who can help? As far as I know, this combination has been working for many months.] ------------------------------ Date: Thu 12 Jul 84 14:26:43-EDT From: JUNGER@CWRU20 Subject: Internal Modems To: info-kermit@CUCS20 In the last Info-Kermit I noticed the following statement: [Ed. - Most Kermit programs, including MS-DOS Kermit, do not contain explicit code for modem control. We have always advised Kermit users to steer clear of internal modems.] Perhaps it would be well to point out to those who are running non-generic Kermit for CP/M-80 that they can use an internal modem if they modify Kermit to look for the ports used by the modem instead of the external serial port. At least this works for my North Star Horizon, for which I have two versions of Kermit, one for the external printer port and one for a Hayes Micro Modem 100 connected to the S-100 bus. Peter D. Junger CWRU Law School ------------------------------ Date: Thu, 12 Jul 84 14:28 EDT From: Wiedemann@RADC-MULTICS.ARPA Subject: Packet retransmissions. To: info-kermit@COLUMBIA-20.ARPA I have recently installed the MULTICS Kermit from MIT-MULTICS on our system (the MUKERMIT from COLUMBIA-20 had many bugs). I am talking to this with the PCKERMIT from COLUMBIA. Using either 1200 or 300 baud, my retransmission rate runs about 95%! What am I doing wrong? Are there any parameters on either end that affect retransmission? I assumed that this was primarily due to communications equipment or line quality. Any suggestions are welcomed. Wolf Wiedemann RADC-MULTICS [Ed. - I haven't heard that complaint before, but I don't have any experience with MULTICS machines. I assume other MULTICS Kermit users have had better experience, or else I would have heard! Anyway, the author of MULTICS Kermit, Paul Amaranth of the Oakland University in Michigan, just sent me a tape with a new release of the program. I'll announce it as soon as it's on line.] ------------------------------ From: decvax!mulga!nemeth.uacomsci@Berkeley Date: Thu, 12 Jul 84 13:14:00 EST To: info-kermit%columbia-20.arpa.mulga.UUCP@Berkeley Subject: Sirius Kermit(s) Hi, hope you got the hex file of the CP/M-86 Sirius version I sent a few days ago... it was quite a struggle getting it ON the damn thing, because its disc format is totally incompatible with everything! And to complicate things further, MS-DOS can't write CM/M-86 files (but it can read them). Anyway, having used the two (ie MS-DOS and CP/M-86) versions on the Sirius, we have decided to all but forget about the MS-DOS version; it is VERY slow (barely runs @1200, even loses chars in connect mode; highest speed it seems to run reliably is about 600 bps); and it has some bugs, apparently (gets very confused talking to a server). The CP/M-86 version does not seem to have any such problems -- it runs faster (tested at 4800 bps), does not need padding characters in connect mode, and seems to work fine with a server (although it produces a strange diagnostic, which is ignored, using wildcards). [Ed. - I've heard wildly conflicting reviews of Victor/Sirius Kermit, both the CP/M-86 and MS-DOS versions. Some say it performs flawlessly at 9600 baud; others say it doesn't work at all. I've also heard that the systems themselves vary a lot -- different i/o chips, different BIOSes, etc. Can anyone out there shed any light?] Subject: Break indication (new subject, not a comms problem): I believe this should be an ESSENTIAL facility for all Kermits to provide in connect mode; it has all sorts of uses. In our environment (via a port selector) it is the only means for the user to disconnect his line and select another host; the ability to send a break indication is really missed on the CP/M-80 versions! [Ed. - Obviously, I agree. Most of the KERMITs that come from Columbia have this. It's up to each person who installs support on a new microcomputer to include this functionality. The method varies from system to system -- system calls to send BREAK, direct serial i/o chip device manipulation, BREAK simulation by sending several nulls at 50 baud, etc.] Subject: Kermit for DEC Pro 350? What's happening about it? Has it been released yet? We have some users who would like to use it (we also have the DEC PFT, but that only talks to VAXes..) [Ed. - It's released. It was done by Stevens Institute of Technology, sharing common code with their VAX/VMS and DECsystem-10 versions. P/OS Kermit is available as KER:POS*.* in the Kermit distribution area, and it will be on the Spring DECUS VAX and RSX SIG tapes.] Subject: Other Kermits - Sanyo, Toshiba, BBC 6502, ... Work is progressing on a few other implementations: the Sanyo is almost there, should be done in about a week; a Toshiba version is being looked at; likewise for RSX-11 and RT-11 (appears to be non-trivial to install), and Cyber(NOS/BE); BBC 6502 still working on it; and 3 or 4 other local CP/M based micros. Keep up the good work! Will advise further when some of these are completed. Tom Nemeth ------------------------------ Date: Thu 12 Jul 84 17:46:22-PDT From: Lawrence L. Wu Subject: Kermit-32 problem To: cc.fdc@COLUMBIA-20.ARPA I am writing on behalf of the system people at the Hoover Institution's VAX/VMS. A few weeks ago, I helped them acquire a copy of Kermit-32 (Version 3.0.051) for their VAX. Today, Kermit caused a system problem that caused them to disable Kermit until the problem can be fixed. It appears that some user was using Kermit in local mode and exited abnormally from the VAX, probably by hitting break or turning off their terminal. The problem that occurred was that Kermit didn't drop the dial-out modem and the remote computer effectively tried to login through the remote port, which had been dedicated to Kermit. This wrote login failure messages to the system disk every few seconds and, according to the system people, would have crashed the system if not caught in time. I have just pulled the protocol manual over from Columbia via Arpanet and will look through it with the system people at Hoover; this may help us solve our problems. However, I qualify only as a dumb user (and also have less than complete confidence in the abilities of the system people at Hoover.) Have other people have encountered similar problems, or can you (or others) offer suggestions? Any help would be greatly appreciated. Larry ------------------------------ Date: Fri 13 Jul 84 08:26:00-EDT From: Nick Bush Subject: Re: Kermit-32 problem To: WU%SU-SCORE@COLUMBIA-20.ARPA If Kermit is really aborted abnormally, there is little it can do to hang up a modem. However, the problem can be avoided by setting the terminal line with the dial-out modem to enable automatic hangup. This is done by "SET TERM TTxn:/PERM/HANGUP". With the line set this way, it will hangup the phone whenever the terminal line is either released by a program or deallocated by user command (if it was allocated to a process). - Nick PS: It is actually possible to recover from the situation you described without reloading the system. I keep a command file around the simply attempts to allocate the terminal specified by its parameter and loops until it is sucessful. Since it takes some amount of time to create a process to run LOGINOUT to attempt the login, you can ususally grab the terminal fairly quickly (within one or two login attempts). ------------------------------ Date: Fri 13 Jul 84 09:32:04-PDT From: Ted Shapin Subject: kermit and modem binary file xfers To: info-kermit@COLUMBIA-20.ARPA, info-ibmpc@USC-ISIB.ARPA One of our main requirements for micro to mainframe communication is to be able to archive programs on the large systems disks. This includes binary files that may be .COM, .EXE, .CMD and "squeezed" files. KERMIT for TOPS-20 only saves files as 7-bit ASCII, which loses the eigth bit. Under MS-DOS files can have a length that is not an even multiple of 128 bytes. MODEM loses because a file that is transferred up to the HOST and then back to the PC will be rounded up to the next even number of sectors. I know there are programs that will expand binary files to 7-bit files but I do not think that extra translation is a good solution. Comments? Ted. [Ed. - Au contraire... You can tell Kermit-20 to "SET FILE BYTESIZE 8" when receiving files and it will store them as you desire. If a file is stored with bytesize 8 on a DEC-20, Kermit-20 will automatically send it correctly. It even recognizes "ITS Binary" format. Read the manual. The most current documentation is in KER:20KERMIT.DOC.] ------------------------------ Date: 13 Jul 84 08:12:28 EDT From: J. Ray Scott To: sy.fdc@CU20B Subject: Kermit with Knowledgeman Just a caution. If you are creating files with the Knowledgeman CONVERT verb KMan pads the output file out to even multiples of 128 bytes. It puts a ^Z in at the end of its data and then just junk after that. If you send this file with PC Kermit, Kermit will go ahead and send the junk since Kermit relies on the MS-DOS file size and not any data in the file. I think Kermit is right. This is just another in a very long list of problems with KMan. I would NOT recommend Kman to anyone. J. Ray Scott ------------------------------ Date: 13 Jul 84 21:23:19 EDT From: G.W. van Mook To: js5a@CMCCTA Subject: KERMIT'S limit I attempted to download the AP vendor file from TOPS-A to the XT, and like it did last time I did this, it died at KERMIT packet 32767. It seems that KERMIT's limit is around 2.8 megabytes per file transfer, unless something else is causing this. Good night...gvm [Ed. - Sounds like some 16-bit counter overflowed unexpectedly in PC/XT Kermit. We'll look into the problem.] ------------------------------ Date: Wed, 11 Jul 84 11:24:38 EDT From: Dave Swindell Subject: Problems with KERMIT-10 Receive command?? To: info-kermit@columbia-20 Recently, I have had problems sending files from KERMIT-86 (version 1.20) on an IBM-PC to KERMIT-10 (latest version) on our TOPS-10 computer. I want to be able to rename the files as they are sent by using the RECEIVE on KERMIT-10 command and the SEND command from KERMIT-86. When I do this, I get an error message from KERMIT-10 about illegal wildcard characters in file specification. The file specs I am using in KERMIT-10 contain no wildcard characters (*,%, or ?). What am I (or what is it!) doing wrong? Dave Swindell, @bbn-unix ------------------------------ Date: Fri 13 Jul 84 22:38:06-EDT From: Nick Bush Subject: Problems with Kermit-10 receive command To: DSwindell@BBN-LABS-B.ARPA cc: info-kermit@COLUMBIA-20.ARPA The following patch corrects a problem with Kermit-10 v3(123) in the RECEIVE command. This makes RECEIVE file.ext work correctly. Previously if an extension was given, an error message was generated when the file was received. File 1) DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984 File 2) DSKB:KERMIT.MAC[10,52,KERMIT,10] created: 1753 11-Jul-1984 1)1 MITVER==2 ; Major version number 1) MITMIN==0 ; Minor version number 1) MITEDT==123 ; Edit level 1) MITWHO==0 ; Customer edit **** 2)1 MITVER==3 ; Major version number 2) MITMIN==0 ; Minor version number 2) MITEDT==126 ; Edit level 2) MITWHO==0 ; Customer edit ************** 1)3 | **** 2)3 Start of Version 3(124) 2) 126 By: Nick Bush On: 11-July-1984 2) RECEIVE FOO.BAR would not work correctly. 2) It thought the extension was 2) wild-carded. 2) 2) Modules: KERMIT 2) | ************** 1)28 > ; End of TOPS10 **** 2)28 ; Determine if we are logged in. 2) PJOB S1, ;[125] Get our job number 2) MOVNS S1 ;[125] Set up for JOBSTS 2) JOBSTS S1, ;[125] Get status for us 2) MOVX S1,JB.ULI ;[125] Old TOPS-10 maybe? 2) TXNN S1,JB.ULI ;[125] Logged in? 2) SETZ S1, ;[125] No, remember that 2) MOVEM S1,LOGDIN ;[125] flag file creation time 2) > ; End of TOPS10 ************** 1)29 $CALL I%EXIT ; And exit 1) TOPS10< **** 2)29 $CALL C$EXI0 ;[125] And exit 2) TOPS10< ************** 1)33 GETPPN S1, ; Get our logged in PPN **** 2)33 MOVX S1,<> ;[125] Try INI:KERMIT.INI first 2) MOVEM S1,INIFD+.FDSTR ;[125] for global defs 2) MOVEI S1,INIFD ;[125] Get the FD address 2) SETZ S2, ;[125] No log file FD 2) $CALL P$TAKE ;[125] Set up the take 2) JUMPF REDIN0 ;[125] If not there don't worry 2) MOVEM S1,INIIFN ;[125] Found file, save IFN 2) $CALL PARL.1 ;[125] Parse the file File 1) DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984 File 2) DSKB:KERMIT.MAC[10,52,KERMIT,10] created: 1753 11-Jul-1984 2) REDIN0: MOVX S1,<> ;[125] Now we will use 2) MOVEM S1,INIFD+.FDSTR ;[125] DSK:KERMIT.INI[,] 2) GETPPN S1, ; Get our logged in PPN ************** 1)39 XMOVEI S1,MYTERM ; Point to the block 1) $CALL T$SBRK ; Set the PIM mode break set **** 2)39 XMOVEI S2,MYTERM ;[125] Point to the block 2) $CALL T$SBRK ; Set the PIM mode break set ************** 1)39 CAIN P1,"E" ; In escape sequence? **** 2)39 MOVE S2,S1 ;[125] Copy of the character 2) ANDI S2,177 ;[125] Keep only 7 bits 2) CAIN P1,"E" ; In escape sequence? ************** 1)39 CAME S1,ESCAPE ; Is this escape? 1) JRST CN.SND ; no, just send it **** 2)39 CAME S2,ESCAPE ; Is this escape? 2) JRST CN.SND ; no, just send it ************** 1)39 CN.ESC: CAIE S1,"C" ; Is is C 1) CAIN S1,"c" ; or lower case c? 1) JRST CN.END ; Yes done 1) MOVEI P1,"S" ; Assume not send control chr 1) CAMN S1,ESCAPE ; Another escape? 1) JRST CN.SND ; Yes, send a real one 1) CAIN S1,"?" ; want help? 1) JRST CN.HLP ; Yes, do it 1) CAIE S1,"S" ; Want status? 1) CAIN S1,"s" ; or lower case "s" 1) JRST CN.STS ; Yes 1) CAIE S1,"O" ; Clear buffers? 1) CAIN S1,"o" ; . . . 1) JRST CN.CLR ; Yes, go clear terminal buffers 1) CAIE S1,"Q" ; Quit logging? 1) CAIN S1,"q" ; . . . 1) JRST CN.QUT ; Quit logging 1) CAIE S1,"R" ; Resume logging 1) CAIN S1,"r" ; . . . 1) JRST CN.RSM ; Yes, do it 1) CAIE S1,"^" ; Want control chr? 1) JRST CN.ESE ; No, bad **** 2)39 CN.ESC: CAIE S2,"C" ; Is is C 2) CAIN S2,"c" ; or lower case c? 2) JRST CN.END ; Yes done 2) MOVEI P1,"S" ; Assume not send control chr 2) CAMN S2,ESCAPE ; Another escape? 2) JRST CN.SND ; Yes, send a real one 2) CAIN S2,"?" ; want help? 2) JRST CN.HLP ; Yes, do it 2) CAIE S2,"S" ; Want status? 2) CAIN S2,"s" ; or lower case "s" 2) JRST CN.STS ; Yes File 1) DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984 File 2) DSKB:KERMIT.MAC[10,52,KERMIT,10] created: 1753 11-Jul-1984 2) CAIE S2,"O" ; Clear buffers? 2) CAIN S2,"o" ; . . . 2) JRST CN.CLR ; Yes, go clear terminal buffers 2) CAIE S2,"Q" ; Quit logging? 2) CAIN S2,"q" ; . . . 2) JRST CN.QUT ; Quit logging 2) CAIE S2,"R" ; Resume logging 2) CAIN S2,"r" ; . . . 2) JRST CN.RSM ; Yes, do it 2) CAIE S2,"^" ; Want control chr? 2) JRST CN.ESE ; No, bad ************** 1)39 ANDI S1,37 ; make a control chr 1) JRST CN.SND ; and send it **** 2)39 CAIL S1,"`" ;[125] Lower case range? 2) XORI S1,240 ;[125] Toggle Parity & case 2) XORI S1,300 ;[125] Convert to control 2) JRST CN.SND ; and send it ************** 1)39 CN.SND: XMOVEI S2,XFRTRM ; Get terminal control block 1) $CALL T$CCOT ; Send char down line **** 2)39 CN.SND: BLSCAL GEN%PARITY##, ; Generate correct parity 2) XMOVEI S2,XFRTRM ; Get terminal control block 2) $CALL T$CCOT ; Send char down line ************** 1)39 XMOVEI S2,MYTERM ; Yes, output to our tty also **** 2)39 $CALL CN.PAR ; Even parity unless PR%NONE 2) XMOVEI S2,MYTERM ; Yes, output to our tty also ************** 1)39 CN.TYP: XMOVEI S2,MYTERM ; Point to the terminal block 1) $CALL T$CCOT ; Output the character 1) $RETT ; and return 1)40 SUBTTL Command execution -- DEFINE command **** 2)39 CN.TYP: $CALL CN.PAR ;[125] Even parity if needed 2) XMOVEI S2,MYTERM ; Point to the terminal block 2) $CALL T$CCOT ; Output the character 2) $RETT ; and return 2) ;[125] Here to put even parity on a character. 2) CN.PAR: MOVE S2,PARITY%TYPE## ;[125] Get the parity type 2) CAIN S2,PR%NONE## ;[125] No parity? 2) $RET ;[125] Yes, leave it alone 2) ANDI S1,177 ;[125] Keep only 7 bits 2) MOVEI S2,(S1) ;[125] Get a copy 2) LSH S2,-4 ;[125] Shift back 4 bits 2) XORI S2,(S1) ;[125] Combine halves 2) TRCE S2,14 ;[125] Left bits both 0 2) TRNN S2,14 ;[125] Or both 1? 2) XORI S1,200 ;[125] Yes, change high bit 2) TRCE S2,3 ;[125] Right bits both zero 2) TRNN S2,3 ;[125] Or both one? 2) XORI S1,200 ;[125] Yes, change high bit 2) $RET ;[125] All done File 1) DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984 File 2) DSKB:KERMIT.MAC[10,52,KERMIT,10] created: 1753 11-Jul-1984 2)40 SUBTTL Command execution -- DEFINE command ************** 1)41 C$EXI0: $HALT ; Exit to the monitor 1) $RETT ; Allow continues **** 2)41 C$EXI0: SKIPN LOGDIN ;[125] Are we logged in? 2) JRST [$TEXT (,<.KJOB^M^J.^A>) ;[125] No, make a nice msg 2) LOGOUT 1, ;[125] And quit 2) JRST .+1] ;[125] Shouldn't get here... 2) $HALT ; Exit to the monitor 2) $RETT ; Allow continues ************** 1)52 HLLOS USRFX+.FDEXM ; . . . 1) SETOM USRFX+.FDDIM ; . . . **** 2)52 ;[126];@C$RECEIVE + 9 2) HRROS USRFX+.FDEXM ;[126] . . . 2) SETOM USRFX+.FDDIM ; . . . ************** [Ed. - Some of the comments in the above FILCOM listing were edited to make them fit on the screen. The patch will be in the next release of DECsystem-10 Kermit.] ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Jul-84 22:05:36-EDT,15014;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 18 Jul 84 22:04:59 EDT Date: Wed 18 Jul 84 22:03:37-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #16 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 18 Jul 84 Volume 1 : Number 16 Today's Topics: Reminder - How to Get Kermit New Kermit for IBM MVS/TSO New Apple II Kermit-65 Release New Release of DEC-20 Kermit Kermit on Otrona Attache Victor Kermit and Problems Transferring to VAX Kermit over Arpanet Kermit and TACs Kermit Between IBM PC and Host -- 8 Bit Transfer ---------------------------------------------------------------------- Date: Wed 18 Jul 84 21:33:15-EDT From: Frank da Cruz Subject: Reminder - How to Get Kermit To: Info-Kermit@CUCS20 This issue of the Info-Kermit digest contains announcements of several new KERMITs. For the benefit of those who are new to the Info-Kermit list, and to refresh the memories of those who aren't, here's how to get the KERMIT files: ARPANET/Internet: Use FTP, connect to host COLUMBIA-20, login as user ANONYMOUS with any non-null password, and GET (or MULTIPLE GET) the files you're interested in. Anonymous FTP access to COLUMBIA-20 is allowed only after 6:00pm and before 6:00am, eastern time. CCNET (DECNET hosts at Columbia, CMU, CWRU, NYU, Stevens, and (soon) Vassar): Use NFT to COPY the desired files from CU20B::KER:. If you're on a VAX, just use the COPY command. Specify /USER:ANONYMOUS. If CU20B does not grant you anonymous access, ask your system manager to get the files. CCNET and ARPANET: All KERMIT files are in the area KER:. Several short files are of particular interest: KER:00README.TXT Guide to what's available, showing file name conventions. KER:VERSIONS.DOC List of all known KERMIT versions, both available and in progress. KER:CURRENT.DOC Reverse chronological list of available versions, showing release date and version number. BITNET: On an IBM VM/CMS system, type the command SMSG RSCS MSG CUVMA KERMSRV HELP to get instructions for how to use the Kermit server at host CUVMA. There is usually a delay between the announcement of a new version of Kermit and its availability on BITNET, because each file has to be painfully screened and possibly processed to fit the requirements of our RJE link. Other networks like USENET, MAILNET, etc, or if you're not on a network: Send mail to Info-Kermit-Request@COLUMBIA-20, or to: KERMIT Distribution Columbia University Center for Computing Activities 612 West 115th Street New York, N.Y. 10025 and we'll send you flyers explaining how to order a distribution tape. ------------------------------ Date: Wed 18 Jul 84 18:21:15-EDT From: Frank da Cruz Subject: New Kermit for IBM MVS/TSO To: Info-Kermit@CUCS20 Announcing Kermit for MVS/TSO on IBM 370-series and compatible mainframes from Ron Rusnak of the University of Chicago Computation Center (SYSRONR@UCHIVM1.BITNET or SYSTEMS.RON@UCHICAGO.MAILNET). This is an adaptation of Columbia's VM/CMS implementation, and it has about the same characteristics -- a no-frills Kermit, no server operation, no binary file transfers, and so forth. The source and documentation files are in KER:TSO*.* (4 files). The CMS and TSO versions of Kermit will be upgraded to a more advanced level in the future. ------------------------------ Date: Wed 18 Jul 84 15:49:46-EDT From: Anton Mione Subject: New Apple II Kermit-65 Release To: sy.fdc@CU20B Version 2.1 of Apple II DOS KERMIT-65 is finished. APPREAD.ME is the usual 'quick summary' of changes. APPHXL has been changed to be more 'Terse' in providing information. It now prints the count and load address for each line of the .HEX file followed by an '[OK]' if things went well or a '[CHECKSUM ERROR]' if they did not. APPDXL has not changed but a .BIN file is now included. APPLEK.M65, APPLEK.HEX, and APPLEK.BIN are the new source/object to release 2.1. APPLE.MSS is the new format documentation. This is a first draft and I may have to make some minor changes before it is really ready to be included in the user manual. Some new functionality has been added to KERMIT-65, especially in relation to CONNECT mode support. A cursor is now displayed when connected to a remote host. Upper case characters appear in inverse so the user can now distinguish between upper and lower case characters. Also, characters which can not be directly generated from the Apple ][ keyboard can now be generated by using a right-arrow as a prefix character. The connect-escape processing now has more options. Break signals can be sent, etc. Some bugs have been fixed in the GET and SEND commands. KERMIT-65 no longer runs out of buffers in long sessions. The GET command uses file names out of the File-header packets sent from the remote Kermit. There is now an easy way to change the drive which KERMIT-65 uses for file transfers. Anton: [Ed. - The program now supports the Apple II, the II+, and the IIe (with certain limitations on the IIe), and the Apple Comm Card, the Apple Super Serial Card, and the DC Hayes Micromodem II. The files are available in KER:APP*.*.] ------------------------------ Date: Wed 18 Jul 84 18:51:09-EDT From: Frank da Cruz Subject: New Release of DEC-20 Kermit To: Info-Kermit@CUCS20 Announcing a new release of DECSYSTEM-20 Kermit, 4.1(236). The major change in this version is to move the code for connecting to a remote system into the Kermit-20 program itself, rather than running another program (TTLINK) in a lower fork. The connect code now runs in two forks (a`la TELNET), and is not interrupt driven, unlike TTLINK which ran in one fork and was interrupt driven. This was done for several reasons -- . It allows Kermit-20 to run in local mode under TOPS-20 version 6.0, which does not allow multiple simultaneous opens of a TTY device. . It gives the user greater control over communication options, like line speed, BREAK simulation, flow control, etc. . It allows Kermit-20 to run in local mode under batch, for instance to dial a remote system at midnight and send or get files. This was not possible with TTLINK, which did not send the appropriate "pty-hungry" signals to BATCON. As a consequence of this change, several new commands have been added -- CLOSE (to explicitly close the various kinds of log files), SET SPEED, SET BREAK, PUSH. The files are in KER:20KERMIT.*, including a new 20KERMIT.DOC. - Frank ------------------------------ Date: 16 Jul 1984 0759 PDT From: Richard B. August Subject: Kermit on Otrona Attache To: info-kermit-request@columbia-20 I have been successful in getting Kermit up on my Otrona Attache, however, I am experiencing some "difficulties" in transfering .COM (IMAGE) files from my VAX. Additionally I have had "NO LUCK" transfering files (IMAGE) from SIMTEL20. Does anyone have a KERMIT working on an Otrona Attache? If not I will FTP the source I have (along witmy changes) to see what mistakes I have made. Thanks in advance. Regards, Richard ------------------------------ Date: Mon 16 Jul 84 14:37:14-EDT From: JUNGER@CWRU20 Subject: Victor Kermit and problems transferring to VAX. To: info-kermit@CUCS20 I noted to queries in the current INFO-KERMIT which may relate to the same experience which I had. One was about Sirius/Victor. We have just gotten the MSDOS version of Kermit up on a Victor 9000, and, though we have not done much experimenting, it seems to work fine. We transferered the Kermit .COM file itself to a DEC 20 and returned it to the Victor and it ran just as it should upon its return. But!!! we had trouble getting the DEC to receive if from the the Victor using the receive command on the DEC. The symptoms were that the Victor showed exactly the same symptoms as were reported by Marco Papa when trying to send a file to a VAX at 9600 baud. We were only running at 1200 baud. The solution was to put the DEC in the server mode. I don't know if the VAX version allows it to be run as a server, but it might be worth trying. P. Junger [Ed. - That's a strange one. DEC-20 Kermit does nothing different in server mode, except that it parses its commands from packets rather than the keyboard. The communications line conditioning and protocol should be exactly the same. I'd tend to chalk it up to coincidence. But just to make sure, get the latest version of DEC-20 Kermit - 4.1(236) - announced above, and see if the problem persists.] ------------------------------ Date: Tue 17 Jul 84 17:44:41-EDT From: J. Eliot B. Moss Subject: Kermit over Arpanet To: cc.fdc@COLUMBIA-20.ARPA I regularly log in through a TAC from a Z80 based machine to MIT-XX, a TOPS-20 site. I have used the MODEM7xx program for file transfer in the past, and typically have had success only in downloading. I run at 1200 baud. I understand a lot about the Arpanet protocols, etc., having done some work to get a version of MODEM running on the 20. I have had no success getting Kermit on XX to talk to my local Kermit. The TOPS-10 compatibility stuff is a crock to begin with; but mainly it would appear that characters just do not flow, even though I can type (as in the CONNECT command) through my local Kermit. Any hints on what to do? [Ed. - See next message.] For your info, I have downloaded the CP/M version of Kermit, and created versions for the following: Molecular SuperMicro (terminal type selectable by EQU) Altos 8000-10 running MP/M (terminal type by EQU) Altos 8000-10 running CP/M (terminal type by EQU) my home micro (Morrow Design Mult I/O board) In the process, I made it easy for people using the Z80CTC to set the baud rate, and for those using the NS8250 asynch chip to init and set the baud rate. Of course, some systems vary baud rate clocks, so adjustments may have to be made, but code works out well. [Ed. - Charles@ACC, are you listening? You might want to incorporate this code into version 4.] I want to suggest that future versions be done in Turbo Pascal -- you can do up insert files to adjust system specific things, achieve modularity, etc. It would be much easier to maintain, though likely lead to bigger com files. [Ed. - Any volunteers?] Anyway, thanks in advance for any assistance you can give me. Eliot ------------------------------ Date: 17 Jul 1984 10:41-EDT Subject: Kermit and TACs From: ABN.ISCAMS@USC-ISID.ARPA To: INFO-KERMIT@COLUMBIA-20.ARPA NetLandians, Hard keeping up with what KERMITs can do, with all the wizards improving all the time. However, I learned a new trick with my host's KERMIT-20 and my own KERMIT-80 (CP/M) for working through a TAC. The TAC, as you may know, is a purely 7-bit medium and does a real job on any binary files going through it. Some KERMITs have the ability to "prefix" binary characters to enable you to pass data through such 7-bit media. However, the trick is how to make your KERMIT do that! By setting my host's KERMIT-20 with parity (I used a nice innocuous "Even"), that forces KERMIT-20 to prefix binary characters. It KNOWS it has to fiddle that 8th bit, so it changes everything to its 7-bit prefixed equivalent. The TAC is gonna strip off that parity bit anyway, but no harm done! Down at the micro, you don't have to do anything! Just do your normal receive, and KERMIT-80 DOES know how to change prefixed data back to real 8-bit. You will truly get an effective 8-bit data download through a 7-bit medium. For uploads, a little more trickiness. Tell your KERMIT-20 on the host to SET FILE to BYTESIZE 8, so it knows it'll be getting true binary. Tell your local KERMIT-80 you're sending in FILE-MODE BINARY, and SET PARITY EVEN, so YOUR KERMIT will know to prefix binary. Again, the TAC will strip that 8th bit during upload, but who cares? The host KERMIT-20 changes things back to a nice 8-bit character and files it correctly as 8-bit files, and all is well. For a test, I downloaded an ITS-binary formatted file from my host through the TAC, and then uploaded it again as a pure 8-bit file. Then downloaded it again as a pure 8-bit file (no ITS-binary this time). The two versions on my micro (the converted ITS-binary one and the new 8-bit one) matched exactly. Damn, these KERMITs are clever! Regards, David Kirschbaum Toad Hall ABN.ISCAMS@USC-ISID [Ed. - As a matter of fact, DEC-20 Kermit has a command "SET TVT-BINARY", which should take care of all this for you, provided your TOPS-20 monitor is set up for it. This command will tell the TAC to put itself in binary mode, and then will take the TAC out of binary mode when the transfer is over. But if your TOPS-20 monitor is not set up to do this -- several patches popular among ARPAnet TOPS-20 sites are necessary -- then your method is a good alternative, except that you shouldn't SET FILE BYTESIZE 8, etc, for ASCII (text) files if you want them to be usable on the DEC-20. All this is described in the DEC-20 Kermit manual, KER:20KERMIT.DOC.] ------------------------------ Date: Tue, 17 Jul 84 23:57 EDT From: LBrenkus@MIT-MULTICS.ARPA Subject: Kermit between IBM PC and host -- 8 bit transfer To: info-ibmpc@USC-ISIB.ARPA ReSent-To: info-kermit@COLUMBIA-20.ARPA Previous messages have (correctly) noted that the host is capable of receiving 8 bit files from Kermit if it is instructed to expect them. I believe that it is impossible to download them back to the IBM PC, however. The transfer mysteriously "hangs", with the host Kermit still trying to send the file, but the PC end reports a message and aborts the transfer. I actually have to disconnect (turn my modem off, redial up again) and abort my old process, or the Multics Kermit will continue to spew out garbage. Apparently, the problem is that 8 bit quoting doesn't work properly on IBM-PC Kermit. Hopefully, that shortcoming will be corrected in the new, fully modularized MSDOS Kermit which will be released real soon now. [Ed. - MS-DOS Kermit 1.20 cannot do "8th-bit quoting" and so cannot transfer binary files over a 7-bit connection. The forthcoming release will be able to do this.] ------------------------------ End of Info-Kermit Digest ************************* ------- 23-Jul-84 12:43:27-EDT,12455;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 23 Jul 84 12:42:55 EDT Date: Mon 23 Jul 84 12:42:04-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #17 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 23 July 1984 Volume 1 : Number 17 Today's Topics: Kermit Directory Listing Apple II Kermit-65 V2.1 KERMIT-80 vs TAC More About UNIX Kermit Problem Wierd Things with Kermit-11 RT11 and CONNECT Command FLEX Kermit? Kermit for Cromemco OS's? ---------------------------------------------------------------------- Date: Mon 23 Jul 84 11:47:51-EDT From: Frank da Cruz Subject: Kermit Directory Listing To: Info-Kermit@COLUMBIA-20.ARPA Users at some network sites have complained that their FTP implementations do not support the MULTIPLE GET function. Therefore, they need to know the exact name of each file before in order to GET the desired files one by one. Starting now, there will be a new file in the Kermit network distribution area on COLUMBIA-20, KER:FILES.DIR. It contains an alphabetical listing of all the Kermit files, including their sizes and dates. The directory listing will be updated automatically each morning at 3am, eastern time. Here are the first few lines to illustrate the format: PS: PGS Bytes(SZ) Write 00README.TXT.50 5 12347(7) 18-Jul-84 170AZLIB.ASM.1 27 66670(7) 25-May-84 170KERMIT.DOC.3 9 22498(7) 11-Jun-84 .FOR.2 67 170230(7) 25-May-84 .MSG.1 1 1453(7) 25-May-84 .MSS.1 8 18347(7) 11-Jun-84 .NR.1 4 8914(7) 18-Oct-83 20CMD.DOC.1 4 9229(7) 14-Aug-78 .MAC.1 4 7794(7) 10-Jun-81 PS: is the name of the directory, for which we normally use the "logical device name" KER:. 00README.TXT.50 is the name of the first file in the directory, which is a text file containing an explanation of what is available and the naming conventions used. "00README" is the file name, "TXT" is the file type (text), and "50" is a generation number, which should normally not be used explictly. Note that for files of the same name, but differing types and generations, the listing omits the name on subsequent lines, although you must supply it in order to refer to the file. For instance, 20CMD.DOC.1 4 9229(7) 14-Aug-78 .MAC.1 4 7794(7) 10-Jun-81 denotes two files, 20CMD.DOC and 20CMD.MAC. The number in the PGS column shows the size in DEC-20 "pages" (units of 512 36-bit words, or 2560 7-bit ASCII characters, or 2048 8-bit bytes). The next two numbers show the length in bytes, and the size of the bytes. Normally, the bytesize has the following significance: 7 ASCII text (program source, documentation, hex files) 8 "Foreign" 8-bit binary files (from micros and other 8-bit-byte systems) 36 PDP-10 or DEC-20 36-bit binary files The final column shows the write date for the file. A chronological listing of the currently available Kermit versions can be found in KER:CURRENT.DOC. ------------------------------ Date: 18 Jul 1984 2208 PDT From: Ken Adelman Subject: Apple Kermit V2.1 To: Info-Kermit@COLUMBIA-20 After I received digest #16, announcing the new apple kermit, I ftp'd KER:APPLEK.HEX from columbia-20 (between 9 and 10pm pdst jul 18) and kermit'd it to my apple useing V2.0 of kermit. The file APPLEK.HEX contains the old version V2.0 rather that the new version V2.1. Did someone forget to update something? Frustration is maximized since the load address moved by a byte from $800 to $801 in the version change, which gives the appearence of trash when one saves from $801 (for V2.1), and because I have a Super Serial Card, which requires a bug-fix for V2.0 and not V2.1. Please update the file. thanx, Ken Adelman Caltech [Ed. - Sorry! Thanks for pointing it out. The error was corrected soon after the announcement was made.] ------------------------------ Date: Fri, 20 Jul 84 09:25 CDT From: "David S. Cargo" Subject: Apple II Kermit-65 To: Info-Kermit@COLUMBIA-20.ARPA I don't know how often people plan for future versions of Kermit, but I thought it would be worthwhile pointing out some problems that have just been created. There are two major sources of incompatibility between the Apple IIc and the other earlier Apples. One is the disk drive; this is a major concern only of you are producing or using copy protected software. The other is the character set displayed on the screen. The inverse video characters have been replaced by graphics characters at least in some cases. This means that when Kermit for the IIc is done by somebody, there will be problems (or perhaps might be). I don't own any kind of Apple, so I can't verify the problem. My information comes from an article recently published in InfoWorld. If you are interested in minimizing differences between versions of Kermits for Apples, somebody might want to experiment and develop a common solution. ------------------------------ Date: 19 Jul 1984 02:00-EDT Subject: KERMIT-80 From: ABN.ISCAMS@USC-ISID.ARPA To: INFO-KERMIT@COLUMBIA-20.ARPA A recent input to our Info-Kermit Digest commented on several new I/O drivers for CP/M systems. The 8250, as used on the Morrow Multi I/O board, is already implemented (Charles has it too), and works fine at 300 to (I guess!) 52000 - just kidding, but for sure 9600. No parity fiddling on the board - just baud rate. I too work through a TAC with my Decision I, and have no problems up or down. I understand there are many bells and whistles on the KERMIT-20 to permit binary transfer, disabling TAC intercept char, etc., but my local wizards frown on too much fiddling with their TAC, so I've done most of it within KERMIT. The World Famous Toad Hall TACTrap handles intercept characters (just screens for them during packet or straight upload transfers, and sends the designated intercept character twice! That takes care of the TAC!). TACs usually have kind of small input buffers, so you have to set the host (or local) KERMIT to maybe 50 or 60 character packets during upload. Any kind of flow control engaged messes things up: I leave it up to the KERMIT-20 to take care of all that. I too have problems with MDM7nn uploading, specifically because the TAC can't handle those 128-byte packets, so I use KERMIT exclusively for uploads when I'm doing binary. For normal text, I usually just engage Xon/Xoff flow control and use MDM7nn (or my new patched KERMIT 4.0 with a MDM7nn- like Xon/Xoff straight upload) to move ascii into an editor. If that gentleman can't work out KERMIT for uploads, please contact me directly and I'll send you parts of source, whatever, to make your system work through the TAC. Last point -- can someone give me pointers to the wizards playing with floating windows and KERMIT. I'm curious as to their approach, having several ideas myself but no practical knowledge. Regards, David Kirschbaum, Toad Hall ABN.ISCAMS@USC-ISID [Ed. - We'll be looking into a windowing option for Kermit this summer at Columbia, but no guarantees that we'll accomplish anything!] ------------------------------ Date: Thu Jul 19 1984 16:36:18 From: Marco Papa To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: More about UNIX Kermit problem For background on this problem, please read Vol. 1, number 15. I used debug mode on both sides of UNIX and PC-DOS kermits and these are the results: The 3 packets that are sent by PC-DOS Kermit for a text file of name TEST.FOR are as follows (each packet is preceded by the SOH char that on the PC appears as the small face): 1. ) S~% @-#R (Send Initiate) 2. +!FTEST.FORJ (File header) 3. |"DTEST.FORJ (Data packet) After trying 5 times on the third packet PC Kermit aborts saying that cannot receive acknowledgement from the host. If I connect back to UNIX now I get the following data (I run it with dd mode): spack type: N, num: 2, len: 0, recstate: D, data: SOH followed by #"N5 This seems to me as the standard NAK packet. This packet is sent a number of times, until UNIX kermit finally aborts and exits. What is not clear to me is why PC Kermit sends the filename into a Data packet after having sent it in the File Header packet, since the filename was not in the text file at all. Also, you there Kermit hackers, are the various fields in the packets correct? Marco Papa USC Computer Science Dept. ARPA, CSNET: papa.usc-cse@csnet-relay UUCP: ..!randvax!uscvax!papa [Ed. - Very strange... We've been running PC Kermit 1.20 heavily for a long time and have never seen such behavior. Rather than try too hard to track it down, better to just get the new release, which should come out any day now. Really!] ------------------------------ Date: Thu 19 Jul 84 00:53:50-PDT From: Carl Fussell Subject: rt kermit from Stevens... To: info-kermit@COLUMBIA-20.ARPA Address: Santa Clara University I recently got the new Stevens release of kermit-11 and from k11rt4.com (the linker command file if I remember correctly) figured out most of the necessary files to compile it. I am doing this on an 11/23 running RT-11 V5.0 with multi term support. All compiled correctly after locating the .Included files but when I linked it, got a multiple definition on labe DIRER$. It appears that routine is coded into 2 modules... K11CMD.MAC and K11RT4.MAC. (???) I commented out one of them (K11RT4 arbitrarily) and all compiles and links ok. Just wanted to let someone know this duplication was there. The resulting kermit still does not work properly unfortunately. I can start it and (after setting line and speed) connect to host and work. This moment I "escape" back to local kermit, I get the prompt but then appears to cease all output to terminal. As soon as I type a couple of ^C's, then any and all output that was generated while kermit was "frozen" appears and kermit terminates (from ^C's). Has anyone else run into any problems that you are aware of? If so, can you let me know who so I can contact them... perhaps they have fixed them. thanx... Carl Fussell G.FUSSELL@SU-SCORE ------------------------------ DATE: MON, 23 JULY 1984 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: KERMIT AND RT11 The RT11 problem about Kermit-11 not accepting input after returning from the connect command has been solved. Kermit-11 will not run under the SJ (single job) monitor. There must be some call that gets lost on the SJ exec, or else there is a bug in doing the .MTDTCH call to release the terminal from MT service. If anyone has any ideas, I will be glad to look into it but for now, simply run FB or XM. Since this problem is trivial to work around, getting Kermit-11 to run under SJ will be placed on the back burner. Brian Nelson ------------------------------ Date: 18 Jul 84 16:27 +0200 From: Edgar_Hildering_SARA%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KERMIT_implementation_and_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: FLEX Kermit? Is there anyone outthere who can reach John Guidi Jackson lab? He is working on a FLEX-implementation of Kermit. I would like to give him some mental support and if necessary any other help. ------------------------------ Date: Sat 21 Jul 84 17:50:16-PDT From: Phillip W. Barth Subject: KERMIT for Cromemco OS's? To: cc.fdc@COLUMBIA-20.ARPA Has anyone put together versions of KERMIT to run under Cromemco's operating systems (CDOS, C-10 CDOS, or Cromix)? As I understand it, the I/O byte is different for the CDOS systems so that generic CP/M KERMIT won't work directly. Any info will be appreciated. ------------------------------ End of Info-Kermit Digest ************************* ------- 27-Jul-84 17:54:20-EDT,13732;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 27 Jul 84 17:53:48 EDT Date: Fri 27 Jul 84 17:51:32-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #18, Special MS-DOS Edition To: Info-Kermit: ; cc: Info-IBMPC@USC-ISIB.ARPA, Info-Micro@BRL-VGR.ARPA Info-Kermit Digest Friday, 27 July 1984 Volume 1 : Number 18 Today's Topic: New Release of Kermit for MS-DOS ---------------------------------------------------------------------- Date: Fri 27 Jul 84 17:45:00-EDT To: Info-Kermit From: Frank da Cruz Subject: New Release of Kermit for MS-DOS This issue of the Info-Kermit Digest is devoted to the long-heralded (and overdue) announcement of version 2 of Kermit for MS-DOS systems (Kermit is Columbia University's file transfer protocol for use over telecommunication lines, and it runs on a wide variety of systems). We announced our intention to provide this new release back in January, and have been working on it ever since. The previous release was 1.20, 28 November 1983. The new version is called "Kermit-MS" rather than "Kermit-86" and the version number is 2.26. It is available for several systems: System DOS Versions ------ ------------ IBM PC, PPC, and XT 1.1, 2.0 & above DEC Rainbow 100 and 100+ 2.05 & above HP-150 2.0 Wang PC 2.01 Others (Generic DOS) 1.1, 2.0 & above Versions for the IBM PCjr and Heath/Zenith 100 are soon to be added (version 1.20 already run on these machines). If your MS-DOS system is not on this list, you are invited to add support for it by supplying the appropriate system- and device-dependent modules (described below). The IBM version has been tested on IBM PCs with the old and new motherboards and ROMs, as well as on the XT and Portable PC, on hard disks, floppy disks, and RAM disks, and on color and monochrome monitors. It has NOT been tested on the Compaq, Columbia, or other "PC compatible" product; there is some chance that it might not work on the compatibles even when the previous release (1.20) did, because of greater dependence on the display hardware. Version 2 of MS-DOS Kermit has been tested successfully up to 9600 baud on the IBM, DEC, HP, and Wang micros, in communication with full duplex systems like the DEC-20 and VAX, and half duplex systems like IBM mainframes. Kermit-MS requires about 80K RAM, and certain functions like PUSH and RUN will need additional memory. Thus, for DOS plus Kermit, you will need a machine with at least 128K. Version 1.20 can run on a 64K machine. Version 1.20 will remain available indefinitely because it has proven quite stable, runs on a variety of PC-compatible systems, and is considerably smaller than version 2. Here is a summary of the changes: * Program organization: The program has been broken up into separate source files, assembled separately, and linked together. The modules are: System/Device Independent: MSKERM.ASM - Main program MSSEND.ASM - File sender MSRECV.ASM - File receiver MSSERV.ASM - Server operation MSFILE.ASM - File i/o MSCMD.ASM - Command parser MSTERM.ASM - CONNECT command MSCOMM.ASM - Communications port buffering & flow control MSSET.ASM - SET, SHOW, and STATUS commands MSDEFS.H - Data structure definitions and equates System/Device Dependent: MSXxxx.ASM - System-dependent code for system xxx MSYxxx.ASM - System-dependent screen and keyboard code MSZxxx.ASM - Modem control (modem-dependent) MSXSYS.DOC - Description of system-dependent modules The modular organization allows easier modification of the program, quicker transfer of modified portions from system to system. The modules are designed to be well-defined and self-contained, such that they can be easily replaced. For instance, someone who prefers windows and mice to typing commands could replace the command parsing module without having to worry about the effect on the other modules. * Kermit Protocol Improvements: Kermit-MS now supports: . 8th-bit prefixing for passing binary data through 7-bit communication links . 12-bit checksums and 16-bit CRCs as alternate block check types . Compression of repeated bytes . Server operation . Advanced commands for servers, including: REMOTE DELETE REMOTE DIRECTORY REMOTE HELP REMOTE HOST REMOTE SPACE REMOTE TYPE These advanced protocol features can be used in conjunction with other advanced Kermit implementations, including itself, as well as the current Kermits for the DECsystem-10, DECSYSTEM-20, VAX/VMS, PDP-11 (RSX, RSTS, RT), DEC Pro-350, and others, and soon to include IBM VM/CMS and UNIX. * Local command execution: The following new commands provide access to DOS functions from within the Kermit-MS program: DELETE DIRECTORY SET DEFAULT DISK PUSH (to DOS) SET DESTINATION (device - disk or printer) SPACE (runs CHKDSK) RUN (a program) * Command parsing: The command parser has been improved in many areas. For instance, "?" now works much better than before (though still not perfectly). ESC now provides completion not only in keywords, but also in filenames. CTRL-W deletes the previous "word" on the command line. CTRL-C always returns to the Kermit-MS> prompt. There is a command macro facility; DEFINE lets you build macros by combining Kermit-MS commands, DO executes them, SHOW displays them. DOS command line arguments are accepted, and may be strung together separated by commas, e.g. "kermit set baud 9600, set timer on, connect" Kermit-MS now reads an initialization file, MSKERMIT.INI, and can process (nested) command files with a TAKE command. * Terminal emulation: On IBM micros, the speed of Heath-19 terminal emulation has been improved by using direct screen memory access. Functions like insert and delete character now execute very rapidly. Heath-19 emulation functions, such as reverse index, missing from earlier releases are now supplied. H19 emulation may be disabled to allow the use of other console drivers, like ANSI.SYS, in conjunction with Kermit-MS. On systems with 25 lines, the 25th line is an inverse video mode line, displaying current settings, which may be kept or turned off. On the IBM and DEC systems, there are pop-up help and status screens, and the screen is saved and restored between remote/local context switches. The terminal session can be logged to disk to provide unguarded capture of remote files or session typescripts. On the IBM, DEC, and HP systems, the screen can be rolled back several pages, on a per-line or per-screen basis. On most of the systems, print-screen (screen dump) and CTRL-print-screen (toggle printing on/off) work as they do in DOS. On the IBM and DEC systems, a key redefinition facility is available to allow the layout of the keyboard to be altered to suit individual tastes, to set up keypads or function keys for specific applications, or to construct "keystroke macros". On IBM micros, the ALT key can be set up for use as a META key for use with EMACS-like editors. All versions of Kermit-MS except the generic DOS version are capable of transmitting the BREAK signal. The functions that are missing from the Wang and/or HP micros -- key redefinition, pop-up menus, screen rollback, screen print -- were omitted due to lack of information about how to get at the scan codes, screen memory, printer interrupts, etc, and may be added at a later time. Meanwhile, anyone out there who has the information and feels inclined to add missing features is invited to do so. * Communication options: The port characteristics are left alone when Kermit-MS starts (in the previous release, Kermit-MS always set the baud rate). The program allows settings for speed, duplex, flow control, handshake, and parity on a per-port basis, to allow convenient switching between ports. * File Transfer: You can now supply new names for files in SEND and GET commands. A timeout facility has been added to allow automatic recovery from deadlocks when communicating with systems (like IBM mainframes) that can't time out. The file transfer display has been reformatted, and includes more useful information, including a percentage for outbound files. The various counts are updated more reliably. Several options are available for interrupting file transfer, including ^X (cancel current file), ^Z (cancel entire batch), ^E (user-generated "error"), ^C (return immediately to command level), CR (simulate a timeout). The options are displayed during file transfer. There is a new end-of-file option to allow selection of DOS-style (believe the DOS byte count) or CP/M-style (file ends at first CTRL-Z) EOF detection. * Remote operation: Kermit-MS may be run from the back port in either interactive or server mode. This allows micro-to-micro file transfer without requiring an operator on both ends. * New Bootstrapping Procedure: The Kermit .EXE files for the various systems are now encoded using a printable 4-for-3 encoding, with compression of repeated 0 bytes. The result tends to be smaller than the original .EXE file. A new set of bootstrapping programs has been provided: MSMKBOO.C Encode. Can be used on any binary file. Written in C. MSBOOT.FOR Send the encoded file from the mainframe. Fortran. MSPCTRAN.BAS Decode the encoded file on the micro. MS Basic. MSPCBOOT.BAS Receive on the micro, decode on the fly. MS Basic. * Documentation: There's an entirely new manual, available now as a separate document, soon to be incorporated into the Kermit User Guide. It describes operation of the program in detail, along with the new bootstrapping procedure. * How To Get It: Kermit is available for a wide variety of systems -- micros, minis, and mainframes. It is distributed by Columbia University via network or on magnetic tape. For further information about Kermit, send network mail to INFO-KERMIT-REQUEST@COLUMBIA-20, or write to the Kermit Distribution address below. To be added to the Info-Kermit network mailing list, mail to INFO-KERMIT-REQUEST@COLUMBIA-20. The new MS-DOS Kermit files are available from COLUMBIA-20 via anonymous FTP after 6pm daily (ARPANET), though KERMSRV at CUVMA on BITNET (BITNET users should type "SMSG RSCS MSG CUVMA KERMSRV HELP" for information about the Columbia Kermit file server), and on all the Columbia DEC-20 systems in the KERMIT area. The file names all begin with "MS" (on BITNET, omit the "KER:" prefix). The executable programs have the suffix .EXE and are in 8-bit binary format. The corresponding 7-bit ASCII encoded files have the suffix .BOO. The system-specific programs are available in both .EXE and .BOO formats. KER:MSIBMPC -- IBM PC, XT KER:MSIBMJR -- IBM PCjr (not yet availble) KER:MSRB100 -- DEC Rainbow 100, 100+ KER:MSHP150 -- Hewlett-Packard 150 KER:MSHZ100 -- Heath/Zenith 100 (not yet available) KER:MSWANG -- Wang PC KER:MSGENER -- Generic DOS KER:MS*.ASM, KER:MS*.H are the assembler source files. KER:MSBUILD.HLP tells how to build the program. KER:MSKERMIT.DOC is the new MS-DOS section for the Kermit User Guide. KER:MSKERMIT.MSS is the Scribe source for the .DOC file. Those without network access may write to the following address for details of how to order a complete Kermit distribution on 9-track magnetic tape: KERMIT Distribution Columbia University Center for Computing Activities 612 West 115th Street New York, NY 10025 Version 2 of MS-DOS Kermit will be submitted to PC-SIG so that it can be ordered on IBM PC floppy disks. Inquiries should be directed to PC Software Interest Group 1556 Halford Avenue, Suite #130 Santa Clara, CA 95051 Phone 408-730-9291 Be sure to wait until they have version 2, because they are presently distributing version 1 on their disks numbers 41 and 42. It may take some time for them to update their distribution. * Credit: The bulk of the work was done by Daphne Tzoar and Jeff Damens of the Columbia University Center for Computing Activities. Many ideas (and "existence proofs") were contributed by Herm Fischer of Litton Data Systems -- key redefinitions, remote and server operation, etc, but those who have been using Herm's modified 1.20 will find that some of the features he added have been done differently in this release. 8th-bit quoting was originally added by Leslie Spira and her staff at The Source Telecomputing to allow Kermit to transfer binary files over Telenet. The new bootstrapping procedure and the new file transfer display were done by Bill Catchings of Columbia. Filename completion came from Kimmo Laaksonen at the Helsinki University of Technology. Some corporate support and encouragement was provided by Digital Equipment Corporation, Wang Laboratories, and IBM. * Disclaimer: Although we have been using the new version on several different kinds of systems for a good while and have done extensive testing, some bugs may have slipped through. Please hang on to your old release (1.20), and don't hesitate to report any problems to Info-Kermit@COLUMBIA-20. Suggestions and contributions are also welcome. ------------------------------ End of Info-Kermit Digest ************************* ------- 31-Jul-84 10:25:11-EDT,16952;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 31 Jul 84 10:23:23 EDT Date: Tue 31 Jul 84 10:23:34-EDT From: Bill Catchings Subject: Info-Kermit Digest V1 #19 Sender: CC.FDC@CUCS20 To: Info-Kermit: ; Info-Kermit Digest Mon, 30 July 1984 Volume 1 : Number 19 This week's editor: Bill Catchings Today's Topics: New Release of PR1ME Kermit Available Several New Documents Available Kermit in Modula-2 or Ada? Kermit in Turbo Pascal Franklin CPM Kermit, Apple Kermit 2.1 Kermit Distribution Unfairness (2) Problems loading Kermit-10 UNIX Kermit Kermit for rsx11m+ (2) Kermit-MS for NEC APC SDS Kermit? Bug fix for new MSPCTRAN.BAS bootstrap program ---------------------------------------------------------------------- Date: Fri 27 Jul 84 18:01:15-EDT From: Frank da Cruz Subject: Info-Kermit To: Info-Kermit@CUCS20 As many of you may have noticed, COLUMBIA-20 was down for several days. During that period of relative calm, we were able to get the new MS-DOS Kermit put together sufficiently for release. I'm sure we'll be getting many reports about it, and we'll collect them all for the next release which will be dedicated to incorporating fixes for reported problems. Meanwhile, I'll be going on vacation for the month of August, so some of the other Kermit folks will be running the Info-Kermit digest. This issue is a trial run. Keep addressing your comments, contributions, requests, complaints to Info-Kermit or Info-Kermit-Request at COLUMBIA-20, but not to me personally, because I won't be here to read them until September. - Frank ------------------------------ Date: Mon 23 Jul 84 15:05:24-EDT From: Frank da Cruz Subject: New Release of PR1ME Kermit Available To: Info-Kermit@CUCS20 This is to announce a new release of Kermit for PR1ME computers running PRIMOS R18 and R19. It was submitted by Nancy K. Morrison of SPSS, Inc, in Chicago and includes bug fixes and enhancements to the original version contributed by The Source, as well as a special conversion facility for SPSS "portable files". The new files are in KER:PRIMEK.*. Some of the changes are: 1. Break handler fixed so quits are done cleanly. 2. Received files are now renamed when they already exist on disk. 3. The compiling and linking files were modified to ran at PRIMOS rev 18, and a new CPL program was added to copy the tree structure with rev 18 commands. Kermit does run at rev 18, but not with the server command "attach" (CWD). 4. New PORTFILE command for SPSS files. ------------------------------ Date: Wed 25 Jul 84 11:13:16-EDT From: Frank da Cruz Subject: Several New Documents Available To: Info-Kermit@CUCS20 Several new documents are available in the Kermit distribution area. KER:K11FIL.DOC contains a description of what all the PDP-11 Kermit files are (Brian Nelson, U of Toledo). KER:KINTRO.DOC is an introduction to Kermit for the inexperienced computer user, with emphasis on micro-to-micro file transfer (Norman Weatherby of the Columbia University Center for Population and Familty Health). KER:APPLE.DOC (Antonino Mione, Stevens Inst of Tech, and Peter Trei, Columbia U) is an update of the new Apple DOS Kermit manual in which several minor errors are corrected. KER:APPLE.MSS is the Scribe text formatter source for this file. ------------------------------ Date: Monday, 23 Jul 1984 14:19-EDT From: munck@Mitre-Bedford To: Info-Kermit@Columbia-20 Subject: Kermit in Modula-2 or Ada? I haven't seen any mention of a kermit in either of these "languages of the future." Is anyone out there working on either? Failing that, which of the various Pascal kermits would be "best" to translate/re-code into one or both? By "best" I mean (priority order): o a clean implementation; modular, readable, untricky, uniform. o complete with as many of the standard features and optional goodies as possible. o makes good use of Pascal extensions that are in the direction of Modula-2 and Ada; strings, units, etc. Eventually, of course, we'll need only the Ada implementation, as Ada will be supported everywhere on everything. Those of you still in your teens may live to see that, if you take very good care of yourselves. -- Bob Munck ARPA: munck@mitre-bedford uucp: {allegra,genrad,ihnp4,utzoo,philabs,decvax}!linus!bccvax!munck USPS: The MITRE Corporation, MS A134, Bedford, MA 01730 (617)271-3671 ------------------------------ Date: Wed, 25 Jul 84 08:40:04 EST From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers) To: cc.fdc@columbia-20.ARPA Subject: Kermit in Turbo Pascal I think the idea of rewriting Kermit in Turbo Pascal is a very good one for the following reasons: * It will allow more Kermit users to contribute to the development and maintenance of the program (everyone can afford Turbo Pascal, especially with their new educational licencing) * It will allow greatly increased commonality between the CP/M-80, CP/M-86, and MS-DOS versions * Borland might let us use their "general installation program" which would make Generic Kermit look nicer (as screen formatting would be possible without editing and recompilation). As always, the problem is finding someone prepared to do the work... Steve ------------------------------ Date: Tue, 24 Jul 84 10:59:39 EDT From: Dave Swindell Subject: Franklin CPM Kermit, Apple Kermit 2.1 To: info-kermit@columbia-20 I have a Franklin 1200 computer with a PCPI CP/M card and and ASIO II serial/parallel card. Are there any versions of Kermit that have been used with the PCPI CP/M card? Are the source .ASM files available on line for either the Apple CPM or generic CPM Kermits? Any help in obtaining a workable CPM kermit for the Franklin would be appreciated. Thanks, Dave Swindell P.S. The new Apple 2.1 Kermit works fine. I had problems downloading the HEX via APPHXL at 1200 baud, but none at all at 300 baud. ------------------------------ Date: Fri, 20 Jul 84 16:00 EST From: Mark Scherfling To: info-kermit-request%columbia-20.arpa@csnet-relay.csnet Subject: new kermit distribution We are interested in the Kermit versions for IBM/TSO and the new version for the Apple II. From the notices explaining how to receive new versions of the protocol, we seem to be left with sending you a tape and $100 while those more fortunate on other networks can just transfer the source to themselves without any cost incurred. I feel that this selective policy of who pays for updates is unfair. We have already paid for the first distribution and I feel, as with the others, we should not have to pay for subsequent updates. I feel strongly about this and wish to have a clearification on this matter from yourselves. regards, -- mark ------------------------------ Date: Wed 25 Jul 84 13:06:18-EDT From: Frank da Cruz Subject: Kermit Distribution Unfairness To: Info-Kermit@CUCS20 In response to Mark Scherfling's comments, I agree that it seems unfair that network sites get new Kermits for free whereas unconnected sites have to pay. But if you look at the situation a little more closely, I think you'll understand the policy. We're a university, not a business. Since the BYTE and EDUNET news articles were published, we've been sending out about 10 tapes PER DAY to sites all over the world, answering about 30 letters of inquiry daily, and the phone never stops ringing. Several systems programmers are putting in nearly full time hours as shipping clerks, and have to work extra hours in order to do their REAL jobs. What little money we take in from the distribution fee goes to pay for some part time clerks to help with the shipping, and for supplies like magnetic tape (no, you don't send us a tape, we supply the tape), mailers, printing, and postage. Now, why should network users get it free while unconnected sites pay? Well, first of all, network sites have made large investments in order to get connected -- after all, this is just the sort of thing that networks are for! Second, how would you want us to charge them? Networks just aren't set up for that. Third, it costs us little effort for a network site to drag new Kermit versions away by FTP, whereas it costs us A LOT of effort to make and mail a tape. The only special network-related work comes in updating the Kermit network distribution areas and running the Info-Kermit mailing list. But tape users benefit from this effort too, because they receive Info-Kermit mail on their tapes, along with everything else. In any case, without the network connection, many valuable additions to the Kermit collection would never have been made. A couple years ago, our policy was "send us a tape and return mailer and we'll send you Kermit". We had to give that up when the demand got so high that our offices were filled up with tapes and mailers, our mail room was in utter chaos, having to call Federal for this one, UPS for that one, explain to the post office that the postage meter sticker for this one with a San Francisco postmark really wasn't used already, etc etc, and there was no money to hire anyone to help do all this extra work. Now we have a uniform and relatively automated way of handling orders, with fairly rapid turnaround, and a mechanism for handling increased demand. Why not send automatic free updates? In less than two years, we've sent out nearly 800 Kermit tapes. If you keep up with Info-Kermit, you know that new releases or implementations appear a few times EACH WEEK. To send free updates, we'd have to send out tapes to some 800 sites several times a week, or else do massive database searches for who cares about what version, and make hundreds of custom tapes a week. The sad fact is that we're so swamped sending tapes and responding to inquiries that we haven't even been able to find the time to send a mailing to our "tape customers" letting them know about the new releases that are available. And if we had, we'd have even more orders to fill! Finally, you don't have to get Kermit from Columbia. Go to one of your neighbors, or to DECUS, SHARE, STUG, PC-SIG, etc etc, and get a tape or disk from them -- we submit Kermit to these user groups regularly for redistribution to their membership. But they'll charge you a nominal distribution fee just like we do, because time and materials don't cost them any less than they cost us, and you'll also find that they update their distribution files much less frequently than we do. ------------------------------ Date: Fri 27 Jul 84 11:41:25-EDT From: Robert C. McQueen Subject: Problems loading Kermit-10 To: SY.FDC@CU20B It has been reported by several sites that they are having problems loading Kermit-10. The problem is multiply defined symbols loading the Galaxy library. To fix the problem people should use the CCL file in KER:. - Bob ------------------------------ Date: 25 Jul 1984 02:18:21-PDT From: cmf%case.csnet@csnet-relay.arpa To: cc.fdc@columbia-20.arpa Subject: UNIX Kermit Hello, What is the current status of UNIX Kermit? (I don't currently get INFO-KERMIT). Also, if it is possible, could I be added to the INFO-KERMIT mailing list? I don't have access to the DEC-20's over the summer. Thanks, Carl Fongheiser cmf%Case@CSnet-relay [Ed. We are presently cleaning up UNIX Kermit and adding a few minor features such as the ability to talk to IBM hosts. This version should be available fairly soon (we're in the debugging stage). A more advanced UNIX/C Kermit (written in LEX) with full server capablities has been started and will be available at a later date.] ------------------------------ Date: 26 Jul 1984 1537-PDT From: HAL.DOVE at Ames-VMSB Subject: Kermit for rsx11m+ To: cc.fdc at columbia-20 I took the kermit for rsx11m+ and have been having nothing but probs. I took the executable version over the source, for its ease. I got it into executable form with no problem. I tkb'ed it, and I did have a problem locating f4pots, even though it was there. The exact error was: --DIAG-- Error locating file F4POTS Something like that, so I ignored it, and got no undefined externals. I installed it, and right now it does not have the /ckp=no for the installation. I position myself on my pc running kermit, i get onto the rsx via remoting to it from a vax, so therefore I am on an ht#: line. I fire up kermit, the first thing I notice, it can not seem to find the time, SHOW TIME gives : "The time is ". I set the port to ti: which kermit then replies he is in remote mode now. I then tell him to "SEND FILE", get back to the pc kermit, type recieve, and it never responds. Could it be it can not do a delay since it can`t find the clock. If I set a recieve on the rsx kermit, and do a send down below, it always fails. Now one also notcies that you bang on any key while kermit it in receive mode, you get the nice mcr or dcl prompt depending what you are using. Is kermit listening on the wrong line, or is it just getting interrupted? Is that why the pc kermit fails, because it sends stuff up, and gets > or # as a reply. I hope I have given you enough information. Please reply to me directly here... Thanks Mike ------------------------------ Date: Fri 27 Jul 84 19:03:51-EDT From: Brian Nelson Subject: the decnet thing To: sy.fdc@CU20B error locating f4pots? kermit-11 is macro, not fortran perhaps he tried to link k11hex.ftn and got a task build error. remote user's should use the node name for the file they want rather than to get layers deep into terminal emulation in decnet. since I can't possibly test decnet m+, this one will have to wait a response from someone who does have it. I never got around to the sho tim for rsx or rt. The problem is simple. Kermit-11, for rsx, never pays any attention to the device name, it ALWAYS uses either TT or TI. Thus, a set line HT2: would actually end up assigning TT2:. This will be fixed in the next release. For the time being, user's who have to use a HTnn: line can call me and get information on how to downline load a new RSX task image from one of my systems. The number is (419) 537-2841 brian [Ed. This response was culled from a number of letters from Brian. Thanks, Brian, for all the trouble you went to.] ------------------------------ Date: Fri 27 Jul 84 20:24:54-PDT From: Ronald Blanford Subject: Kermit-MS To: cc.fdc@COLUMBIA-20.ARPA I'll be adding support for the NEC APC to Kermit-MS this weekend. We've all been waiting a long time for this release, as I know you have too. I haven't figured out a general way to boot Kermit on the APC either under CP/M-86 or MS-DOS. As a stopgap, if people will send a diskette and a stamped return envelope I will provide them with the source and object for either version. My address for this purpose is: Ron Blanford 4200 Aurora Ave. N. Seattle, WA 98103 (206) 632-0301 -- Ron ------------------------------ Date: Wed 25 Jul 84 14:28:26-PDT From: ALFIERI@USC-ECLB.ARPA Subject: SDS Kermit? To: cc.fdc@COLUMBIA-20.ARPA Frank: This is a stab in the dark, but do you know of anyone who may have developed even a kludged version of Kermit for the Scientific Data Systems (SDS) dedicated word processing system? (Ah, "SDS" reminds me of 1968 at Columbia!!!) We have a huge data base that needs to be transferred from the SDS to the IBM PC. As life would have it, SDS is now out of business, so we can't even call them up. Help! --vince alfieri alfieri@usc-eclb ------------------------------ Date: Mon 30 Jul 84 14:28:26-EDT From: CC.WBC3@COLUMBIA-20.ARPA Subject: Bug fix for new MSPCTRAN.BAS bootstrap program To: Info-Kermit@COLUMBIA-20.ARPA There is a bug in the new MS-Kermit .BOO file decoder. Line 400 should read 400 if len(x$) < 4 goto 300 rather than 400 if len(x$) = 0 goto 300 -Bill ------------------------------ End of Info-Kermit Digest ************************* ------- 2-Aug-84 12:38:46-EDT,7508;000000000000 Return-Path: Received: from CUCS20 by CU20B with DECnet; 2 Aug 84 12:38:13 EDT Date: Thu 2 Aug 84 12:37:55-EDT From: Daphne Tzoar Subject: Info-Kermit Digest V1 #20 To: Info-Kermit: ; Reply-To: info-kermit@columbia-20 Info-Kermit Digest Thursday, 2 August 1984 Volume 1 : Number 20 This week's editor: Daphne Tzoar Today's Topics: Problems with MSFILE (4 messages) Kermit-MS Status Line with ANSI.SYS Kermit for PC/IX Apollo errors Problem with UNIX Kermit and MS Kermit MSKERMIT (2 messages) ---------------------------------------------------------------------- Date: Tue, 31 Jul 84 13:27:38 EDT From: G B Reilly To: Info-Kermit@columbia-20.ARPA Subject: Re: Info-Kermit Digest V1 #19 I tried to compile the 'msfile.asm' from the latest distribution, and the following was the result: The Microsoft MACRO Assembler , Version 1.25 Copyright (C) Microsoft Corp 1981,82,83 00E2 8D 06 01B1 R lea ax,outbuf ; Where to put data when buffer gets full. E r r o r --- 57:Illegal size for item 0271 8D 1E 03AB R gtchr0: lea bx,inbuf E r r o r --- 57:Illegal size for item Warning Severe Errors Errors 0 2 Brendan Reilly ------------------------------ Date: Tue 31 Jul 84 20:14:00-MDT From: Carl Diegert Subject: Problem in MS-Kermit MSFILE under MASM 1.25 To: info-kermit@COLUMBIA-20.ARPA cc: DIEGERT@SANDIA.ARPA, LINNEROOTH@SANDIA.ARPA Microsoft's MASM version 1.25 gobbled up all modules for IBM PC version MS Kermit EXCEPT for choking on two lines in MSFILE: lea ax,outbuf gtchr0: lea bx,inbuf with a "57:Illeagal size for item" (severe error). How about replacing these lines with mov ax,offset outbuf gtchr0: mov bx,offset inbuf ?? ------------------------------ Date: Tue 31 Jul 84 17:45:20-EDT From: Jeff Damens Subject: Re: [G B Reilly ] To: CC.DAPHNE@CUCS20 inbuf and outbuf are declared as byte labels (not words)... I guess it's looking for a word address. We can just stick a "word ptr" in front of the operand. Maybe we should get a later version of the assembler. Jeff ------------------------------ From: lhasa!lotto@harvard.ARPA Date: 2 Aug 84 08:57 EDT To: harvard!info-kermit@columbia-20 Subject: MSFILE.ASM There is a minor bug in MSFILE.ASM. Please insert the line: mov cl,6 ; Adjust high order word for OR directly before the first (and only) shl instruction. Without this change, routines will wrap reports of Kb transferred from 63 to 1024. Jerry Lotto (lotto@harvard) [It's already been fixed but thanks for pointing out the error and supplying the solution. -ed] ------------------------------ Date: 31 Jul 84 14:57:03 EDT From: Peter Kanaitis To: Info-Kermit@CUCS20 Subject: Kermit-MS Status Line with ANSI.SYS Another thing I noticed about Kermit-MS V2.26 (IBM-PC version) is the send/receive status line. With the ANSI.SYS driver loaded, the line appears in normal video up to the end of the text, where the remaining part of the status line is in reverse video. With ANSI.SYS loaded, the entire send/receive status line is in reverse video. I'm guessing this is the way it should appear with the ANSI.SYS driver loaded. Peter Kanaitis PK0P@CMU-CC-TD ------------------------------ Date: 31 Jul 84 19:34:26 EDT From: DA2A@CMU-CC-TE To: info-kermit-request@CUCS20 Subject: Kermit for PC/IX I've quickly looked over some of the C sources for Kermit. Is there one that takes advantage of the features (crufts) of PX/IX? At the very least, it should have all the features of the latest version of the IBM-PC Kermit. If it could have server capability as well, my life would be complete. Thanks in advance, David Artman (DA2A@CMU-CC-TE) ------------------------------ Date: Tue 31 Jul 84 17:23:04-PDT From: Ted Shapin Subject: Apollo errors To: info-kermit@COLUMBIA-20.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 I tried FTPing APOKERMIT.SRC twice. The FORTRAN code has errors. There are continuation statements following a commented line and other syntax errors in many of the subroutines. I think it needs to be reloaded. ------------------------------ Date: Tue, 31 Jul 84 20:27:11 cdt From: seung@ut-ngp.ARPA To: CC.DAPHNE@COLUMBIA-20.ARPA Subject: Re: mskermit [I don't have original message for the reply below but essentially it said that PC Kermit 1.20 worked with his UNIX version and MS Kermit 2.26 didn't. -ed] I figured out my problem. With version 1.2, I used the command % kermit sdlb ... This doesn't work with 2.26. I have to use the command % kermit slb ... Not that this is any great loss. The d is for debugging mode, which is of limited usefulness since the new mskermit has a debugging mode. Still, it's curious that this happens with UNIX Kermit. I do run mskermit with the timer off--at least the status information says the timer is off. What happens is that two packets are received, enough for the name of the file to be recorded on disk. Then, after six retries, mskermit quits, "unable to receive data." Sebastian ------------------------------ Date: 1 Aug 1984 15:57:37 PDT Subject: MSKERMIT From: Billy To: info-kermit@COLUMBIA-20.ARPA The new MSKERMIT is really great! There are several problems however. If I abort a single file while receiving a series of files the disk gets messed up. This is because Kermit probably does not close and delete the aborted file before starting the next file. If this is indeed the problem the fix should be pretty simple. I know nobody does this, but it is supposed to be a MS-DOS or even IBM-PC standard to be able to BREAK from a program by use of the control break key. I find it best to hook the CTL-BREAK processing code to BIOS as opposed to DOS. Both provide for CTL-BREAK processing, While the BIOS level processing may not be as portable it can handle situations the DOS level can't. It is possible to hang any program and we have done it with a Kermit that we ran on a wierdly configured PC. I hate to have a CTL-ALT DEL reboot when CTL-Break would be more convenient. ------------------------------ Date: Thu 2 Aug 84 11:13:59-EDT From: Daphne Tzoar Subject: Re: MSKERMIT To: BRACKENRIDGE@USC-ISIB.ARPA cc: info-kermit@COLUMBIA-20.ARPA How did you abort the incoming file? If you type ^X or ^Z Kermit closes and deletes the file (unless you did a SET INCOMPLETE KEEP in which case whatever portion of the file that made it over is kept). Checking for ^C was also added to the new version. If someone typed ^C to stop the transfer, we didn't want them abruptly returned to DOS. Typing ^C will return you to the Kermit prompt and if you really want to get to DOS, you can EXIT Kermit. /daphne ------------------------------ End of Info-Kermit Digest ************************* ------- 7-Aug-84 19:24:35-EDT,13788;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by CU20B.ARPA with TCP; Tue 7 Aug 84 19:24:15-EDT Date: Tue 7 Aug 84 19:23:04-EDT From: Daphne Tzoar Subject: Info-Kermit Digest V1 #21 To: Info-Kermit: ; Reply-To: info-kermit@columbia-20 Info-Kermit Digest Tuesday, 7 August 1984 Volume 1 : Number 21 This week's editor: Daphne Tzoar Today's Topics: Mackermit Bugs with Apollo Kermit Problems with TRS-80 Kermit... SWITCHAR in MS-DOS Kermit (4 messages) Kermit and Debug: They won't work together.. CPMBASE needs revising for more micros Perkin-Elmer kermit ? Internal modems Apple-kermit 10 Kermit ---------------------------------------------------------------------- Date: Fri, 3 Aug 84 13:18:04 edt From: engel@harvard.ARPA (Stephen Engel) To: CC.FDC@COLUMBIA-20 Subject: Mackermit I have a working version of kermit for the macintosh. It is an adapted version of the UNIX kermit, and can be compiled and run using the SUMACC package. I have tested it against UNIX kermit and a VMS one, and the file transfer appears to work fine. A few bugs remain in the terminal part though, most notably its bombing upon typeing large amounts (more than 3 or 4 screenfulls) of text. I would be happy to mail it to info-kermit, if you could advise me on what format to provide the material. Steve (engel@harvard) [We received the version for the Macintosh and will be testing it. If all goes well, we'll release it some time next week. Thanks to Steve!! -ed] ------------------------------ Date: Tue 7 Aug 84 17:58:56-EDT From: Daphne Tzoar Subject: Bugs with Apollo Kermit To: info-kermit@CUCS20 We received a new tape from the author and will start distributing the corrected version as soon as I can get it to the DEC-20. /daphne ------------------------------ Date: 29 Jul 84 21:41:39 EDT From: Brian Subject: Problems with TRS-80 Kermit... To: info-kermit@COLUMBIA-20.ARPA cc: sietz@RU-GREEN.ARPA Home: 212 Massachusetts Ave. Cherry Hill, NJ. (609) 428-1201 Work: RCA Corp. Borton Landing Rd. Moorestown, NJ. (609) 778-6163 These are not necessarily things wrong with the code, just things wrong with the distribution of it. Let me start at the beginning... First, I downloaded the basic program (TRSMAKE.BAS) using kermit to my Rainbow, then using a non protocall transfer program to get it to my TRS-80. The program is rather clever in that it computes a checksum, however running the program on the TRS-80 and my Rainbow show the same (wrong) checksum! Also, there is a commented out line (250). Thinking that I had a bad version on my Rainbow, I uploaded the file back to the DEC-20 only to find them to be the same! The next obvious thing to try is to compile it from the sources. There are seven files on the distribution for the TRS kermit program (the main program and six modules). It turns out that there are supposed to be eight source files because the main program includes seven of them - COMND/SRC is missing! Now come on guys - I can't believe the amount of carelessness! I have downloaded five different version of Kermit with no problems before - why start now? Very dissapointed, Brian Sietz [ Stan - Could you send us the missing file and another copy of TRSMAKE.BAS? -ed] ------------------------------ Date: 2 Aug 1984 2321-EDT From: Larry Campbell To: Info-Kermit at COLUMBIA-20 Subject: New MS-DOS KERMIT MS-DOS KERMIT does not behave well if you set SWITCHAR=- in your CONFIG.SYS. Now, I understand why it can't fork commands (so none of the LOCAL xxx commands work, and PUSH doesn't work), but it also doesn't accept pathnames with either forward or backward slashes. 1) Is it supposed to support pathnames? 2) Please support SWITCHAR... Since I develop software that runs under both Unix and MS-DOS, it makes my life a lot easier if I can run with SWITCHAR=- ... - Larry Campbell ------------------------------ Date: Fri 3 Aug 84 14:57:10-EDT From: Jeff Damens Subject: SWITCHAR in MS-DOS Kermit To: lcampbell@DEC-MARLBORO.ARPA I did try to handle SWITCHAR... The problem I ran into is that there isn't any way (that I know of) to get the path separator character from DOS. You can obtain the switchar, but I wasn't sure about the relationship between switchar and the path separator. Empirically, it seems that if you set switchar to - (or anything else but /) then both forward and backward slash are taken as path separators. Do you think that Kermit should accept either slash when switchar is something other than dash? Is there some way to read the path separator? Am I missing something here? Jeff ------------------------------ Date: 3 Aug 1984 2027-PDT From: mike@LOGICON.ARPA Subject: V2.26 MSKERMIT problem To: .note: cc: mike@logicon I have a PC/XT system running DOS v2.10 and I have noticed a VERY interesting problem. Since installation of the new version, I could never get the file MSKERMIT.INI to be successfully read. Oh yes, it did always seem to try but it never executed any of the commands. Another interesting item is that I could not get the 'DIRECTORY' command to work. After a couple of hours of experimenting with different operating systems (v2.00 and v2.10), I discovered the problem. It seems that there is some problem related with the setting of the PATH environment variable. For MSKERMIT to successfully read and execute all commands in the MSKERMIT.INI file, the PATH variable MUST include the current directory for initialization to work. This is nothing harder than putting a ';.' at the end of your declarations. However, it also seems that MSKERMIT only searches the ROOT directory of a given disk for the DIRECTORY command and completely ignores the PATH specification. I have all my system binaries stuck in a subdirectory and I guess this version of Kermit cannot handle that situation at present. A final note, I tried this utilizing '\' directory seperators (standard SWCHAR setting) and '/' directory seperators (SWCHAR = -) and they work identically. However, I have not looked through the code, but Kermit I hope that Kermit would be smart enough to allow UNIX style filenames. Mike Parker {alias mike@LOGICON} ------------------------------ Date: Mon 6 Aug 84 22:40:11-EDT From: Jeff Damens Subject: Re: [mike@LOGICON.ARPA: V2.26 MSKERMIT problem] To: CC.DAPHNE@COLUMBIA-20.ARPA, mike@LOGICON.ARPA Kermit searches the directories in the current PATH environment variable when looking for the MSKERMIT.INI file, or when looking for a file in the TAKE and RUN commands (this is documented in the MSKermit Manual, under the TAKE and RUN commands). If the PATH is empty, or the file isn't found in one of the PATH directories, the default (connected) directory is tried. To use the PUSH and DIRECTORY commands (under DOS 2.0 and higher), Kermit tries to EXEC COMMAND.COM. To find COMMAND.COM, it looks at the COMSPEC environment variable. If you put COMMAND in some other directory, you must change COMSPEC to reflect this; give the command "set COMSPEC=\foo\command.com" The present version of MSKermit only accepts backward slash as the directory delimiter at present; this is definitely a deficiency, and will be fixed, hopefully this week. Jeff ------------------------------ Date: Mon 6 Aug 84 18:22:56-PDT From: Ted Shapin Subject: New MSDOS Kermits To: info-kermit@COLUMBIA-20.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 The version 2 Kermit for the IBMPC is very good. I like the save and restore of the screen during file transfers. It meets the objection I had to unsolicited screen clears. There seem to be a problem with the WANG-PC version. It doesn't run at all under DOS 2. Is it supposed to? [ Kermit for the Wang was developed under MS-DOS version 2.01. Does anyone know what features were added? -ed] ------------------------------ Date: Fri, 3 Aug 84 10:54:43 mdt From: brownc@utah-cs (Eric C. Brown) To: info-kermit@columbia-20 Subject: Kermit and Debug: They won't work together.. I was attempting to bring up Kermit V. 2.26 on a Zenith Z-100 when I found a truly wonderful bug. DEBUG (at least the 2.0 version) breaks the Kermit command processor. When Kermit is run without the debugger, the command processor works fine. When Kermit is run under DEBUG, the command processor will no longer accept commands. All it will do is print ?Illegal command and nothing else. I believe that what is happening is that the code around cmky2x is being trashed (discovered by tracing through the command processor). So. Does anyone have a working version of DEBUG, and if not, does anybody know of a debugger that will debug Kermit?? Thanks, Eric C. Brown brownc@utah-cs ..!harpo!utah-cs!brownc Hacking.. It's not just a job, it's an obsession. [ Does that mean MS Kermit v2.26 works with the Z100 -- we couldn't test the new version since we have no such animal. -ed] ------------------------------ Date: Fri 3 Aug 84 11:14:46-PDT From: Ted Shapin Subject: CPMBASE needs revising for more micros To: info-kermit@COLUMBIA-20.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 KERMIT versions currently exist for about 21 different micros. There are versions of MODEM for about 79 different micro systems. The MODEM people learned a long time ago that it is a good idea to put system dependent code in a separate overlay and keep the main program separate. The first instruction is a jump over the overlay code and the main program calls fixed locations in the overlay for all versions to perform functions such as send a character to the modem, etc. It is easy to support a new system by writing the small overlay and linking it into the main program. This scheme is also used by the recent MEX program which even will work with the same overlays used with MODEM7xx. I looked at CPMBASE.ASM to see what what be involved in supporting some of our in-house micro systems. It is a MESS. There is hardware dependent code scattered thruout and parochial comments such as "only ROBIN can send a break" which is untrue. I just did a rough edit to remove hardware specific code from CPMBASE and found I removed 30% of the source lines. I know the people who are presently running on a micro are happy, but there are three times as many micro systems that COULD run KERMIT and the present arrangement will become absolutely unmanageable. I would like to suggest that the next major revision of the micro code follow the lead set by the MODEM people and remove all of the hardware dependencies to a separate front overlay. Ted Shapin. [Some ambitious soul had volunteered to break up CP/M Kermit but hasn't done so yet. -ed] ------------------------------ Date: Fri, 3 Aug 84 10:07 MDT From: JFisher@DENVER.ARPA Subject: Perkin-Elmer kermit ? To: info-kermit@COLUMBIA-20.ARPA I am in need of a kermit for the Perkin-Elmer Model 3200-MPS, operating under OS 7.2 . Languages available on it are CAL (assembler), Fortran (and Cobol). Is there such a thing available or in progress, to your knowledge ? ------------------------------ From: ihnp4!sask!derek@Berkeley Date: 2 Aug 84 23:08:22 CDT (Thu) To: info-kermit@columbia-20.ARPA Subject: Internal modems What is the story on internal modems. I know that Kermit has some trouble in using them in the IBM-PC and am curious why. Derek Andrew, U of Saskatchewan, sask!derek ------------------------------ Date: Mon, 6 Aug 84 21:43:14 CDT From: Stan Barber To: info-kermit@columbia-20.ARPA Subject: apple-kermit Cc: oc.mione@cu20b.ARPA, oc.trei@cu20b.ARPA, sob@rice.ARPA, stan@rice.ARPA Some more comments on proceedure to get KERMIT-65 to work. I had to change APPLEBT.BAS line 203 to the following to get it to work. 202 GET A$:L$=L$+A$:Y2%=Y2%+1:IF A$<>CHR$(13) THEN 202 Otherwise, it all worked just fine. I even used my TRS-80 to boot it on my apple. If anyone is interested in how I did it, let me know here or in a message to me on the sobbs test board at (713) 660-9252 Stan Barber Rice University ------------------------------ Date: 6 Aug 84 22:20:08 EDT From: *Hobbit* Subject: 10 Kermit To: info-kermit@COLUMBIA-20.ARPA cc: AWalker@RUTGERS.ARPA Yow, have you guys hacked up Kermit to do things while logged out??? If so, what does/can it do in that state? _H* ----------------------- From: Nick Bush Subject: Problems with Kermit-10 receive command ... 2)41 C$EXI0: SKIPN LOGDIN ;[125] Are we logged in? 2) JRST [$TEXT (,<.KJOB^M^J.^A>) ;[125] No, make a nice msg 2) LOGOUT 1, ;[125] And quit 2) JRST .+1] ;[125] Shouldn't get here... 2) $HALT ; Exit to the monitor 2) $RETT ; Allow continues ------------------------------ End of Info-Kermit Digest ************************* ------- 17-Aug-84 15:12:59-EDT,14566;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by CU20B.ARPA with TCP; Fri 17 Aug 84 15:11:44-EDT Date: Fri 17 Aug 84 15:11:26-EDT From: Daphne Tzoar Subject: Info-Kermit Digest V1 #22 To: Info-Kermit: ; Reply-To: to Info-Kermit@columbia-20 Info-Kermit Digest Friday, 17 August 1984 Volume 1 : Number 22 This week's editor: Daphne Tzoar Today's Topics: Kermit for PC/IX New version of CP/M Kermit MSKermit for APC New version of Kermit Bug in version 2.26 receive SWITCHAR and directories Problem with MSKERMIT MS-DOS Kermit Wanted: Kermit for the Kaypro 4 with built in modem Osborne-1 kermit and the Comm-Pac (internal) modem ---------------------------------------------------------------------- Date: Tue 14 Aug 84 17:40:37-PDT From: Herm Fischer Subject: Kermit for PC/IX; works with connect To: info-ibmpc@USC-ISIB.ARPA, info-kermit@COLUMBIA-20.ARPA cc: hfischer@USC-ECLB.ARPA I have modified the latest "kermit.c" as distributed by Columbia University: - It now has conditional compilations for Unix System III, (which includes PC/IX), and TALKER options for interactive features in the connected state and for cooperation with PC/IX's connect facilities. - Its "connect" state allows interactively "escaping" and (without exiting kermit): Entering receive state, sending specified files, asking for reassurance, executing shell commands, quitting/disconnecting, getting a help menu, and sending the escape character itself. - It can be loaded and run from a shell as usual with the unix kermits - It can work as a "talker" for the connect command, which then properly sets up and clears lock files, uses connect's autodialers, etc, and prevents uucp from crashing onto kermit's port. As a talker, you just say "connect talker=kermit somehost" or put the talker=kermit line into connect.con. - When using kermit as connect's talker, you get vt100 screen cursor controls (see PC/IX display(4) man page) minus line insert/delete. (Connect's default talker, "atalk", gives you NO cursor emulation.) - Kermit also works as a "network" program under connect. When connecting using the default talker, if you decide to send/receive a file, enter ^Vu^M rkermit s myfile to send, or ^Vu^M rkermit r to enter kermit's receive state. The r command automatically tells kermit which line to use. This new kermit is in my directory on eclb, kermit.c. When I get to it, I will also provide a man page and some instructions, in files which will also begin with the name kermit. Herm Fischer [Herm, let me know when it's ready for us to copy over. -ed] ------------------------------ Date: 7 Aug 1984 19:11 PDT From: Charles Carvalho Subject: I'm not dead yet! To: CC.DAPHNE@COLUMBIA-20 Cc: CHARLES@ACC Reply-To: CHARLES@ACC Hello... I'm the latest (no, make that "most recent") ambitious soul working on CP/M Kermit, and it looks like a progress report is in order. The long-awaited modular Kermit-80 does exist, and is currently in beta test. (I sent a note to Frank, but it seems I just missed him). Unfortunately, we don't provide FTP server access, but I can mail you a copy if you have some victims (er, test subjects). Do you have an extra-large mailbox available? Sources and documentation total ~270Kbytes. /Charles some changes (not all mine; see [credits]): . Modularized (but you knew that already...) . May be assembled with LASM (aka LINKASM), as well as M80 and MAC80. I've tested M80 and LASM, but don't have a DEC-10 or -20 to test MAC80 on. . Disk space calculated correctly for CP/M 3 systems. [Bruce Tanner] . "break" capability added for Kaypro and BigBoard II. . TACtrap added for running through ARPA/MILnet TACs [David Kirschbaum at Toad Hall] . SET DEBUG command added to display packets sent/received . VT52 emulation improved . SET PORT supported under generic CP/M 2.2 (6, count'em, 6 ports!) [Ronald Blanford] . "Fuzzy" timer support generalized for all systems . New systems: Cal-Tex/Ferguson BigBoard II, Apple II with 6551 ACIA (Apple Super Serial Card, Videx PSIO) [Jon Beeson, Francis Wilson] Morrow Decision I [Toad Hall] . New terminals: VT52, VT100 . TRANSMIT command fixed (I think) . Fixed a couple of bugs in protocol module. [ We've got it. We'll get back to y'all after we test it. -ed] ------------------------------ Date: Tue 7 Aug 84 20:51:35-PDT From: Ronald Blanford Subject: MSKermit for APC To: cc.daphne@COLUMBIA-20.ARPA cc: context@WASHINGTON.ARPA I've finished the system-dependent part of MSKermit for the NEC APC. If you are handling distribution now, the source file is available for anonymous ftp from my account, and is called MSXAPC.ASM. The executable code is in MSAPC.EXE, and a brief help file specific to the APC is in MSAPC.HLP. I also found one bug in (I guess) the documentation to the effect that the POSCUR routine must not trash register SI. It messes up file reception if it does. -- Ron [We'll get a hold of this version too. -ed] ------------------------------ Date: 8 Aug 1984 13:56-EDT Subject: New version of Kermit From: HARDY@USC-ISI.ARPA To: info-kermit@COLUMBIA-20.ARPA Cc: hardy@USC-ISI.ARPA Mike Seyfrit from Polaris ported a version of kermit for DARPA to use on its' IBM-PCs. What is the differance between the new and last version of Kermit. Also, please add my name to info-kermit since Mike now works for someone else. Rich. ^ ^ 0 0 > \-/ ------------------------------ Date: Wed 8 Aug 84 00:41:37-PDT From: Michael A. Haberler Subject: Bug in version 2.26 receive To: info-kermit@COLUMBIA-20.ARPA When I try to download a file from a host with the receive command, sometimes Kermit seems to hang. It will show the filename on the screen, as usual during transfer; it seems to do nothing, but can be aborted by Control-C. When I exit to DOS and try version 1, things work fine (same connection/server). Does anybody have a fix for that? The host is SU-Sierra, a Tops-20 machine. However, the problem seems to be in Kermit; as I said, it works with the old version after 2.26 failed. I'll try to get a more exact picture of the problem and let you know. Send always works. I use a vanilla IBM PC with the Hayes Smartmodem card. Sincerely, Michael ------------------------------ Date: Thu, 9 Aug 84 08:11:07 mdt From: brownc@utah-cs (Eric C. Brown) To: info-kermit@columbia-20 Subject: SWITCHAR and directories According to my pre-release copy of the ms-dos progammer's manual, the path separator can be either forward slash or back slash; the OS doesn't care. However, if the switchar is /, then most programs must parse / as a switch and \ as the only directory separator. If the switchar is not /, then either / or \ should be accepted as directory separators. Eric C. Brown brownc@utah-cs ..!harpo!utah-cs!brownc ------------------------------ Date: 9 Aug 84 11:06:38 EDT From: PK0P@CMU-CC-TD To: CC.DAPHNE@CUCS20 Subject: Problem with MSKERMIT This may have gotten lost over the net, so I'm sending it again... While testing out the new Kermit-MS, I found the following bug: C>kermit ;Get into Kermit IBM-PC Kermit-MS V2.26 Type ? for help Kermit-MS>Set Bau? ;Type "SET BAU" followed by an escape ;The "D " will print. Type another escape, ;The bell will ring, signifying that the ;command has no more defaults. Type a ;question mark at this point ? One of the following: ;lists the options ?Program error Invalid COMND call ;plus some unreadable characters are echoed. I've noticed similar occurrences with the DO command, and SET HEATH19-EMULATION. On a second note, has the control-R facility been removed from version 2.26? Peter Kanaitis (PK0P@CMU-CC-TD) Allegheny General Hospital Pittsburgh, Pennsylvania [ It's been fixed but thanks for pointing it out -- we accidentally trashed a register. -ed] ------------------------------ Date: Wed 15 Aug 84 18:35:29-PDT From: Bruce Tanner Subject: MS-DOS Kermit To: info-kermit@COLUMBIA-20.ARPA We've just gotten MS-DOS Kermit version 2.26 for the Rainbow. We can communicate over the comm port just fine, but file transmission fails on the first packet to both Kermit-10 and Kermit-20. Is there a problem with this version of Kermit, or is it just us? -Bruce ------------------------------ Date: Fri, 10 Aug 84 09:12:03 CDT From: Stephen M. Padgett To: info-kermit@columbia-20 Subject: Wanted: Kermit for the Kaypro 4 with built in modem A friend would like a copy of Kermit for the Kaypro 4 with the built in modem. Has anyone modified the Kaypro version to talk to the built in modem? Please send mail to me, as I get the mailing list indirectly. Thanks! --Steve Padgett smp@ut-ngp ------------------------------ Date: Fri, 17 Aug 84 13:03 EDT From: "John C. Klensin" Subject: Osborne-1 kermit and the Comm-Pac (internal) modem To: info-kermit@COLUMBIA-20.ARPA Since we do not have the facilities to reassemble CP/M-80 kermit (source too big to fit on the machine), but have succeeded in getting it to work with the internal modem, I thought it might be useful to pass the kludge along for others with these unfortunate modems. For anyone contemplating doing this right, or for anyone speculating about the operation of the Ozzie, the bits that go to the "modem port" are the same as those that go out the RS232C port. Note "the same": port selection is meaningless, as these are, in essence, wired in parallel (the voltages differ, but who cares). The modem is dialed by connecting and disconnecting it in a timing loop -- the equivalent to dialing a standard telephone by pushing on the hangup button with the right timing pattern. The internal (Comm-Pac) modem is "connected" by turning the DTR line on and disconnected by turning it off (more on that later). In the interim, use the following strategy: a) Use AMCALL (the software that comes with the modem) or something equivalent to initialize the UART and dial the telephone. b) Escape from AMCALL (or whatever) to CP/M without disconnecting. For AMCALL, this is done by the sequence ESC-Z. c) Run Osborne kermit, modified as indicated below. Now, Osborne kermit will work fine, except that it tries to initialize the UART, and the initializing process drops DTR and, consequently, hangs up the modem--a bad idea. But the port is already initialized, so bypassing that code works fine. If one can assemble generic CP/M-80 kermit, find the STA instruction about two statements after OSSTST (about line 6691) and get rid of it. If not, use DDT to convert the three locations starting at 2C31h to NOPs. And, presto, a version of Osborne kermit that works with the Comm-Pac. Note that, when you exit Osborne kermit, it de-initializes the port, resulting in hanging up the phone. You don't need to go back to AMCALL or manually disconnect. It is possible to construct a SUBMIT file that will walk through this process from invocation of AMCALL to having kermit connected; if it is not obvious to anyone who cares, let me know and I will forward a copy to the net. Things that will get done when either CP/M-80 kermit is restructured and becomes small enough to fit or we discover an appropriate machine and copy of MAC80: - Making this generate breaks. This will definitely work for the Comm-Pac; it looks from the drawings and the technical manual as if it will work for the RS232C also, but we will have to see experimentally. - Making it dial directly, avoiding the kludge. This exercise has pointed out two things about Kermit implementations in general, and CP/M-80 kermit in particular, that probably deserve some priority. 1) As implementations of the various descendants of Multics (and Multics itself), with their case-sensitive file system names proliferate, it is very important that versions of kermit running on systems that cannot cope with lower-case names translate those names into upper case before storing them. With CP/M-80 kermit at present, lower case names are stored in the file system but, since the CCP maps everything that is typed to it to upper case, it is very difficult to use, rename, or get rid of such files. As I read the protocol manual, this problem is a bug and should be fixed; versions of kermit that support operating systems that do case mapping in their command systems, but are internally case sensitive, should be checked for this problem also. 2) The kludge above points out something that has, I think, been discussed before, which is that it would be very advantageous to provide the various micro-kermits with - an exit/quit command that does not de-initialize the port. In the general case, this is required to access commands in the micro's operating system without dropping the line (although some modems are smart enough (or dumb enough) not to hang themselves up when DTR goes off). - some sort of command-line argument ("command tail") that would disable attempts to initialize the port. In the general case, this is probably needed to permit getting back to kermit after suspending it without disconnecting as above. It is also needed for cases like this one, where two communications programs are being used in the same connection and the second one should not undo what the first one has done. ------------------------------ End of Info-Kermit Digest ************************* ------- 5-Sep-84 18:25:22-EDT,26409;000000000000 Mail-From: SY.FDC created at 5-Sep-84 18:24:58 Date: Wed 5 Sep 84 18:24:58-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #23 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Wednesday, 5 September 1984 Volume 1 : Number 23 Today's Topics: Info-Kermit Moving to a New Host Unix Kermit (Several Messages) New Unix Kermit MS-DOS Kermit 2.26 Works on Compaq Problem with MS-DOS Kermit Text Upload and Auto LF in MS-DOS Kermit New Kermit Implementation in LISP Cray Kermit Progress Report Attribute Packets Kermit Over Telenet? Use of Kermit in Commercial Products DEC-20 Kermit Control Character Interference TRS-80 Kermit Author Moves Apple CP/M and DOS Kermit? Kermit to TOPS-20 over TAC? ---------------------------------------------------------------------- Date: Wed, 5 Sep 84 17:00:00-EDT From: Frank da Cruz To: Info-Kermit Subject: Info-Kermit Moving to a New Host Hi everyone, I'm back from vacation. Thanks to Daphne and Bill for running Info-Kermit while I was away. Kermit is maintained and distributed by the Columbia University Center for Computing Activities (i.e. Computer Center), an entity distinct from the Columbia Computer Science Department. The CS department has graciously acted as host for Internet Kermit distribution this past year, including maintaining a very large file archive and handling all the Info-Kermit and other Kermit-related mail. One of the DEC-20s at the Computer Center, CU20B, is now connected to the Internet, and so it is no longer necessary to burden the CS DEC-20 with our mail and file transfer traffic. As a first step in the transition, I'm moving the mailing list from COLUMBIA-20 to CU20B. Mail to Info-Kermit or Info-Kermit-Request should now be directed to CU20B (or, if your host does not yet know about CU20B, which was entered in the NIC host tables last month, then to %CU20B@COLUMBIA). Such mail sent to COLUMBIA-20 will be routed automatically to CU20B during the transition period. Over the next few weeks, we'll be moving the Kermit file archive to CU20B, so please check with your system manager to make sure CU20B is known to your host for both mail and FTP purposes. CU20B's Internet host number is [192.5.43.128] (this may change at some time in the future). Don't worry about file transfer yet, but please try to use the new host when sending mail -- one of the following formats should work: Info-Kermit@CU20B Info-Kermit%CU20B@COLUMBIA Info-Kermit@[192.5.43.128] Sorry for any confusion this might cause, and many thanks to the Columbia CS Department for putting us up (and up with us) this past year. - Frank ------------------------------ Date: Mon, 3 Sep 84 13:42:14 pdt From: jak%ucbopal.CC@Berkeley ( Nhoj Eznuk ) To: info-kermit@columbia-20 Subject: Unix Kermit at UC Berkeley On our Computer Science Department and Computer Center machines we are running your version of Unix Kermit with modifications we would like to see incorporated into Columbia's next release. The "diff" file below has comments indicating the scope of the changes; the file itself specifies all the changes. The actual C source follows under separate cover. John Kunze [Ed. - "diff" file omitted. See below.] ------------------------------ Date: Wed, 5 Sep 84 00:28:31 cdt From: Perry Emrath To: cc.fdc@columbia-20.arpa Subject: unix kermit Hello, my name is Perry Emrath. I am a research professor at the University of Illinois. Earlier this summer, I obtained a copy of Kermit for unix from Lee Hollaar at the University of Utah. I wrote my own version for a pdp-11 which is running a home grown operating system that I wrote. I have made some changes to the unix kermit and plan to make a few more. Reasons are given in the following list describing the changes. I would like to know if you are interested in these changes or if somebody else has already done (or is doing) something similar. 1) Read into a buffer of 100 bytes instead of 1 byte at a time. For a file of 18k bytes, it now uses cpu times of .8 seconds user and 3.5 system, whereas it used to use something like 2.0-2.8 user and 20.0-28.0 system. This works out to about 250 CPU microseconds per byte, instead of 1+ milliseconds, and is now acceptable for a 9600 baud line, which is what we're using. Even when the system is somewhat busy, it achieves 450-500 data chars per second using 10-15% of the CPU. I have yet to add such a buffer in the connect mode routine. 2) When kermit executes as a remote, get the terminal's interrupt char, and if this is received, exit. This way, you don't have to wait for it to time out or go to another terminal to kill it. 3) The receive routine returns an error message if the file exists. I prefer "no clobber". 4) IBM-CMS support. Sending stuff between our pdp-11, vaxen (4.2bsd), a Cyber 175, and ibm equipment was the main reason for obtaining kermit. It appears that the only distinctions for the IBM version are to wait for a ^Q and handle even parity. I have the cms version, but we haven't gotten it assembled yet. 5) Ability to use the send and receive routines from inside the connect routine, somewhat like the other kermits. This is important for us, because we want to use a local resource allocation program that can allocate lines to remote machines, can handle groups of lines to the same machine in a "rotary" fashion. Once you connect to somewhere, you don't want to exit kermit to do a send or receive, thereby freeing the line. We already have a local connect program, and I would make kermit look just like it with two new commands for sending and receiving files. 6) Other minor bug fixes and changes. Numbers 1, 2, and 3 are already done and I am about to start working on 5 and 4. Kermit has generated a lot of interest here and a number of different groups are looking to start using it. I was out to Utah during my vacation in August and Lee helped me grab a bunch of versions from Columbia via the Arpanet and write them on a tape. I have two other questions: 1) Since flushing the input buffer before starting is very useful (based on my experience with my pdp-11 version), I thought it would make sense to have the "receiver" flush the buffer and immediately send a NAK, rather than remaining passive. Then, no matter which direction you're going, things would start up right away instead of waiting until a time out. Is there any problem with this idea? 2) Why was ^A selected instead of a printing character as the start-of-packet character? (I don't really expect an answer, it clearly can't be changed now.) The entire kermit protocol seems oriented toward systems that can only work in a "cooked" mode, like the cyber. I in fact keep my pdp-11 in line mode and it works fine, but I had to change the OS because ^A used to mean something and didn't come through. Oh well, I guess you need raw mode for talking to the ibm anyway, in order to pick up the ^Q. Except for that, though, using a "cooked" line mode seems possible and more efficient. Thanks much, Perry Emrath ...{ihnp4|pur-ee}!uiucdcs!emrath DCS, U of IL emrath.uiuc@csnet ------------------------------ Date: Wed 5 Sep 84 12:44:01-EDT From: Frank da Cruz Subject: Re: Unix Kermit To: emrath%uiucdcsb%uiuc.csnet@CSNET-RELAY.ARPA Hi, thanks for the note. You're about the 50th person to make these and similar changes to Unix Kermit. A couple months ago, we tried to notify the network community that we would be working on an upgrade of the program ourselves and everyone else should hold off for a while, but the contributions continue to pour in... The buffered reads are a good idea, and we'll probably do something along those lines because performance is becoming increasingly important to us. There should also be an option to specify how to handle filename conflicts. We have IBM VM/CMS support already working in Unix Kermit (XON line turnaround, use of selected parity). See below... Eventually Unix Kermit will have a command parser, so that once started it can do repeated commands (send, connect, get, etc) without having to be restarted. The only problem with having the receiver send a NAK immediately is that if it's remote, the user will not have had enough time to escape back to the local Kermit and start it sending, and the NAK will appear on the user's screen. This is disconcerting to users who don't know what it is. If the receiver is local, then it can send a NAK for packet 0 immediately, and that may or may not wake up the sender, depending on the mechanism it uses for delaying transmission of the first packet. Kermit data can include any printing character, and Kermit packets include ONLY printing characters. A distinguished character is needed to mark the beginning of the packet. Control-A was chosen for various reasons (it's the ASCII "start of header" character, and most systems accept it as input, even in "cooked mode"). The protocol manual and BYTE article explain this more detail. If your system won't pass the Control-A through to the program, than you can use some other non-printing character. Many Kermits have commands to redefine the start-of-packet character. - Frank ------------------------------ Date: Wed, 5 Sep 84 11:03:28 EDT From: Edward Haines Subject: Automating Kermit transfers To: cc.fdc @ columbia-20.arpa Cc: haines@BBNCCI.ARPA Frank: We are interested in running Kermit transactions from a batch file (or a program) on an IBM PC talking to a Unix host. We need to be able to issue Unix commands such as 'kermit r' and then local Kermit-MS commands such as 'send \etmail\'. Do you know of any way to do this with any available version of Kermit for the IBM PC? It is easy enough to put the local commands in the batch file but I haven't been able to issue terminal mode commands or exit back to local mode with the new Kermit-MS. [Ed. - You can write a program in your favorite language to issue the desired commands to Unix from the PC, and use the Kermit-MS "RUN" command to execute it. Then, using the new long "command tails" or TAKE files (or any combination thereof), you can write batch files to make Kermit do whatever you like.] Is there a useable version of a Kermit Server for Unix? [Ed. - There will be soon; see below.] Is there any version of Kermit for the IBM PC in a higher level language such as C or Pascal? [Ed. - No, but the C or one of the Pascal versions could probably be adapted. But why bother?] What we really want to do is to transfer a set of files in each direction between the PC and the Unix host and to do a few related Unix commands without any interaction from the user ... something that could be made into a deamon process once we get multitasking in PC-DOS. [Ed. - I think this will all work pretty soon.] Thanks for all you have done so far; Kermit is alive and well. Ted Haines ------------------------------ Date: Wed 5 Sep 84 14:164:01-EDT From: Frank da Cruz Subject: New Unix Kermit To: Info-Kermit A new version of Unix Kermit is available. This is not the totally souped-up version everyone would like to have, but an interim release to bring some more systems into the fold while we continue work on the more ambitious version. Here is what's new: . Parity options (None, Odd, Even, Mark, Space) (-p) . Line turnaround handshake option (XON) (-t) . Half duplex terminal operation (-h) These three items allow the program to communicate with IBM and similar mainframes. Also, various small bugs or problems have been fixed. In addition, work has begun on decomposing the program into modules (there's still a long way to go). In this release, the system-dependent i/o and terminal emulation code has been separated out into special modules for: . Unix (most systems) . VAX/VMS (remote only, no terminal emulation) . Venix on the DEC Pro-350 All the other features which people have asked for (or sent us) have yet to be incorporated into the new LEX-based version we're working on. The new release, and the continuing development, are being done at Columbia by Bill Catchings and Jeff Damens. The new files are in KER:UX*.* on COLUMBIA-20 or CU20B, available via anonymous FTP after 6pm eastern time. The comments at the head of UXKERMIT.C explain what the modules are. The .NR and .MAN files have been updated to describe the new switches. ------------------------------ Date: Fri, 31 Aug 84 20:30 MST From: Brzozowski@HIS-PHOENIX-MULTICS.ARPA Subject: Kermit-MS 2.26 Works on Compaq To: cc.daphne@COLUMBIA-20.ARPA I have just gotten a copy of Kermit 2.26 for MS-DOS for my Compaq. I assembled it like an IBM-PC and I have had no problems with it. I have tested the terminal emulation on Multics Emacs configured as an h19, and it works great!!! I just wanted to let you and Jeff Damens know that that you have done an excellent job! (I also wanted to let you know that it appears to work well on a Compaq too.) Keep up the fantastic work! Gary Brz... ------------------------------ Date: Tue 21 Aug 84 14:10:40-PDT From: ALFIERI@ECLD.#ECLnet Subject: Problem with MS-DOS Kermit To: info-kermit@columbia-20.arpa I love the new version of Kermit for the IBM PC, but I have been having a small problem. Whenever I transfer a file either to or from the TOPS-20, Kermit inserts a long string of Control-Z's at the end of the file. These can be easily deleted, but the earlier version of Kermit did not do this. I assume others have had this problem? --vincent alfieri computing information services university of southern california alfieri@usc-eclb [Ed. - There is an end-of-file option for Kermit-MS 2.26 that determines whether Control-Z's are used at the end of a file. Normally, they are not. You must have asked (either explicitly, or in your MSKERMIT.INI file) to use them. See the manual.] ------- Date: Tue 21 Aug 84 17:18:51-PDT From: L. Brett Glass Subject: Text Upload and Auto LF in MSKERMIT To: info-kermit@COLUMBIA-20.ARPA I have been using the IBM PC version of MSKERMIT for a few weeks now, and like it a lot. However, there are two semi-essential features that it does not have -- and I would like to find out if anyone out in Net-land has implemented them already. These are: 1) Text Upload (that is, dumping straight text from a file to the serial port); [Ed. - There are so many variations on how to do this that we didn't even try; instead, we included a RUN command in Kermit-MS that you can use to run your own Basic or Pascal or C (or ...) program that does it whatever way it wants (XON/XOFF, look for prompt, look for handshake, etc etc).] and 2) Auto linefeed (i.e. going to the next line when the host tries to type past column 80). [Ed. - Linewrap works in the H19 emulator in IBM PC Kermit-MS. The host has to first send the escape sequence to enable it; it's off by default. The escape sequence is ESC v to turn on line wrap, ESC w to turn it off. See the Kermit User Guide.] I have been able to do text upload on the HP 150 version by doing a "push" and then a "copy" to the seral port; unfortunately, the IBM version produces a "write error" when I try this technique. [Ed. - We'll look into the write-error problem.] As for the auto-linefeed, I need it to emulate the terminals I use at work, whose software expects this option to be enabled. Any help with these queries would be MUCH appreciated. Please respond to , and I will post results if there is sufficient interest. --Brett Glass ------------------------------ Date: 1 September 1984 11:54-EDT From: George J. Carrette Subject: New Kermit Implementation in LISP To: cc.fdc @ COLUMBIA-20 A full-function kermit with H19 terminal emulator has been part of the standard LMI lispmachine software release since June. We have used it in house extensively as the way to get files from tops-20 and multics sites and to and from our vax before we had TCP. It is also used by customers to deposit bug notes and snarf fix files from our vax. Also implemented is a SERVER/LOGIN feature, where one can log into the lispmachine through a serial line and get a kermit command loop. This has been used by people uploading and downloading lisp programs from IBM pc's. At some sites kermit fills a real "network gap" where management has not decided on the "right network" yet but programmers need to transfer files. The implementation is kind of hairy. As soon as we have it up in another lisp dialect ourselves (NIL on VAX) we can release it as a COMMON-LISP standard kermit, which would be a good thing indeed. ------------------------------ Date: 30 Aug 1984 13:46:53-MDT From: Leah F. Miller C-10 To: cc.fdc@COLUMBIA-20 Subject: Cray Kermit Progress Report An initial version of Cray Kermit went onto in-house friendly user release on the last day of June. This was a rudimentary "advanced" Kermit with a Server and timeout capability, but nothing fancy. It immediatedly gained user acceptance and began to be used on a daily basis, talking exclusively to Kermit-86 on the IBM PC. A week or so later, Lila Chase began porting it to a rather similar Cray environment at Livermore. She had some success in getting it to talk to Kermit-86 and to a Version 1 Unix Kermit on the SUN computer. Extensive use soon revealed an inadequacy in end-of-file detection. This was a very minor problem at LANL, but much more serious at Livermore where a variant compiler put a trailer after the end-of-file character. At the same time, our users began to request a binary file transfer capability. This required 8th bit quoting, as our network hardware usurped the 8th bit to impose even parity. Since I was doing revisions anyway, I decided to add repeat prefixing. The resulting version of Cray Kermit, called Kermit-CR, now appears to work successfully with both Kermit-86 & MSKERMIT on the IBM PC. A new period of "friendly user" testing is about to begin. If all goes well, I expect to release Kermit-CR in September. ------------------------------ DATE: MON, 13 AUG 1984 FROM: ATSBDN AT UOFT01 TO: SY.WBC3 AT CU20B SUBJECT: ATTRIBUTES PACKETS the ascii 33 attr packet (file length) would be more convenient of the units were in 512 bytes rather that 1024. All DEC pdp11 exec's store allocations in chunks of 512 in the directory entry, thus going to 1024 in the attribute packet can cause trouble. The reason this came up was the need for kermit-11 to be able to tell a RT11 kermit-11 how big the file should be, since RT files are always contig and need to be allocated at create time. No problem for small files, but if the file is to be larger that 1/2 of the largest free contig space then pre-allocation for RT11 is required. For binary files, a length error of +/- one block (due to the rounding in mapping 512 to 1024) could cause problems to an rt11 application needing to read the resultant file. brian nelson [Ed. - Right, it would be better for PDP-11's if the length were expressed in "blocks" instead of K. But there are lots of systems out there that have "blocks", "pages", etc, of different sizes, but K-bytes is the best understood unit. The intention of this field is not to give the exact size of the file, but to let the receiver of a file have some idea in advance of how big it is before it starts to arrive. The EXACT size (byte count) may be specified in another field, which will be listed in the next edition of the Protocol Manual -- "1" (ASCII 49) Byte Count, and "2" (ASCII 50) Byte Size.] ------------------------------ Date: 29 Aug 1984 1126-PDT From: HAL.DOVE at Ames-VMSB Subject: Kermit Over Telenet? To: cc.fdc at columbia-20 Sorry to bother you with this, but I rmemeber that you mentioned about kermit over telenet. Have you ever had the problem while you are on telenet where your spaces are sometimes echoed and sent as @. It is a real annoying problem. If you do not know, do you possibly know someone who does know? Thanks Mike [Ed. - Do you have your parity set right? To the best of my knowledge, Telenet expects you to use Mark parity. Any Telenet users out there?] ------------------------------ From: Paul McNabb Date: 22 Aug 1984 0831-EST (Wednesday) To: info-kermit@columbia-20.ARPA Subject: Use of Kermit in Commercial Products I also have a question. I have heard of people using kermit in a product to be sold. I have been working on a project that may require some sort of file transfer package. Do people frown on kermit being included in a commercial product? Thanks. Paul McNabb Director of Research Facilities Department of Computer Science Purdue University (pam@purdue) [Ed. - Our policy ("feelings", really) on the subject have been written down in a special document which we send to people -- and there are many -- with such requests. It's in KER:COMMER.DOC.] -------- Date: Wed 22 Aug 84 15:36:46-PDT From: Ed Pattermann Subject: DEC-20 Kermit Control Character Interference To: cc.fdc@COLUMBIA-20.ARPA Frank, You can disregard my previous message about troubles with MSKERMIT and TOPS20 Kermit. Please accept my apologies for cluttering your mailbox with 'one more message'. The problem I uncovered was the following, and feel free to post to INFO-KERMIT (after editing a bit) if you feel it is appropriate. The SUMEX exec, as well as many other Tops20 execs, has built in a command editor, usually gotten into by typing '^' as the first character. You can also arm a control character to get into the command editor. I choose ^A. Well, if you use a Tops20 system as a server, and have ^A armed for the line editor, KERMIT will hang no matter what you try to do. I assume this has something to do with Kermit using ^A as a status interrupt. Anyway, that's it. I'm glad I solved it, and I hope someone else doesn't have to waste the time I did. -- Ed [Ed. - Thanks, Ed. Yes, some sites have command editors or daemon forks that are armed to do things when you type certain control characters. Kermit uses ^A as the packet delimiter, so it couldn't transfer files very well if the ^A's were being trapped by some other process. The next release of Kermit-20 will do something about this -- at the very least, it will warn you that another process has a terminal interrupt enabled for ^A. Meanwhile, you can kill your daemon while running Kermit, OR you can redefine the start of packet character to be something other than ^A (SET RECEIVE START-OF-PACKET).] ------------------------------ Date: Wed, 22 Aug 84 20:34:26 CDT From: Stan Barber To: info-kermit-request@columbia-20.ARPA Subject: TRS-80 Kermit author moves Hi there. I am now at Baylor College of Medicine. For TRS-80 Kermit users who want to write, the address is Stan Barber Deparment of Neurology Baylor College of Medicine Houston, Tx 77032 sob@rice still works for mail. We also use kermit here on MASSCOMP under Unix and on PDP-11/23 using RT11. Cheers. Stan [Ed. - Good luck, Stan. By the way, we're still missing the complete set of source files for TRS80 Kermit. Could you, or someone, please send them to us on tape? We have not been able to get them with ftp.] ------------------------------ Date: Wed, 22 Aug 84 23:43:08 cdt To: info-kermit@columbia, info-kermit@columbia-20 Subject: Apple CP/M and DOS Kermit? From: fenchel@wisc-rsch.arpa I'm looking for a version of kermit for an apple 2e with microsoft premium softcard and ssc serial interface card. I would prefer a CP/M version, but will settle for a working Dos version if necessary. Is anyone willing to send me a diskette? or to give me clear instructions on how to download the object file (or source) via ftp from columbia-20 to a unix / vax system. I have a temporary path to download from the unix to the apple under DOS, but am looking for a more permanent and reliable one using KERMIT. ------------------------------ Date: 26 Aug 1984 0205-PDT From: KOTLER@USC-ECLB.ARPA Subject: Kermit to TOPS-20 over TAC? To: Info-Kermit@COLUMBIA-20 I have no end of of troubles in using kermit to communicate with tops20 via the arpanet/milnet. There must be some trick that I am missing. Currenntly I am going through a Tac via remote dialup and no matter what combination of parity/no parity/even parity etc. I used I get a tremendous number of retries when attempting to send files from the tops20 ECLB machine to my IBM PC at home. One trick that I discovered was that the @ character in the packets was being intercepted by the net, so I had to chage the interrupt character via a @i 2, which makes ctl B the new interrupt character. Normally the number of retries is at least half the number of packets recieved. Any help would be greatly appreciated. Thanks in advance, Reed [Ed. - TOPS-20 Kermit needs to be told that you are talking to it through a TAC. It will then put the TAC in "binary mode" and all will be well. When the file transfer is done, it will take it back out of binary mode. The command is SET TVT-BINARY ON.] ------------------------------ End of Info-Kermit Digest ************************* ------- 10-Sep-84 13:49:46-EDT,20500;000000000000 Mail-From: SY.FDC created at 10-Sep-84 13:49:23 Date: Mon 10 Sep 84 13:49:23-EDT From: Frank da Cruz Subject: Info-Kermit Digest V1 #24 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Mon, 10 Sep 84 Volume 1 : Number 24 Today's Topics: New Cyber-170 NOS, NOS/BE Kermit MS-DOS Kermit Available for NEC APC New Release of Multics Kermit Another Kermit for Victor/Sirius MS-DOS TRS-80 Kermit Source Problems Fixed Getting UNIX Kermit Session Transcripts V2.26 MS-DOS Kermit Heath-19 Emulation Bug MS-DOS Kermit on Eagle PC-Plus Bugs in MS-DOS Kermit 2.26 Rainbow CP/M-86 Kermit Printer Interrupts Kermit for Epson QX-10? Apple Kermit on Quadlink Board? Question about RSX Kermit ---------------------------------------------------------------------- Date: Thu, 6 Sep 84 14:33:25 cdt From: knutson@ut-ngp.ARPA (Jim Knutson) To: SY.FDC@CU20B Subject: New Cyber-170 NOS, NOS/BE Kermit Version 2.2 of Kermit for the Cyber-170 is ready. The files are: 170kermit.for 170azlib.asm 170tape.ltr The tape letter is what I have been sending out with tapes I have written for others. You may or may not want to include it with the others. The only change to the document file is the version number. Version 2.2 contains the following modifications from 2.0: Changes from Bill Russell (Russell@NYU.ARPA): Added NOS 2.2 support (up through level 602). Add timeout during reads (NOS 2.2 level 602 or above only). Changes from Ric Anderson (U of Arizona, Tucson): Add UPDATE IFDEFs for character set, operating system and site selection. Fix EXECMD to work under NOS/BE. Fix CFE for use under NOS/BE. I'll include the 8th bit prefixing from Olaf Pors at the U of Virginia along with with the other mods I've done on the next release I send to you. Jim [Ed. - The new files are in KER:170*.* on COLUMBIA-20 and CU20B.] ------------------------------ Date: Tue 7 Aug 84 20:51:35-PDT From: Ronald Blanford Subject: MS-DOS Kermit Available for NEC APC To: cc.daphne@COLUMBIA-20.ARPA I've finished the system-dependent part of MS-DOS Kermit 2.26 for the NEC APC. The source file is called MSXAPC.ASM. The executable code is in MSAPC.EXE, and a brief help file specific to the APC is in MSAPC.HLP. I also found one bug in (I guess) the documentation to the effect that the POSCUR routine must not trash register SI. It messes up file reception if it does. -- Ron [Ed. - Thanks Ron! The files are available in KER:MS*APC.* on CU20B and COLUMBIA-20. Anybody else want to contribute similar modules for some of the other MS-DOS systems (Victor/Sirius, Tandy 2000, Seequa, Z100, etc) so we can get rid of the redundant files?] ------------------------------ Date: Fri 7 Sep 84 16:28:38-EDT From: Frank da Cruz Subject: New Release of Multics Kermit To: Info-Kermit@CU20B.ARPA A new release of Multics Kermit has been received from Paul Amaranth of Oakland University. This is version 2.0g, and replaces the earlier version from May 1983. Various problems with the earlier version have been corrected (for instance, the source code no longer contains any "hard" control characters), and many improvements have been made (server mode, logging and metering facilities, etc). Comments and critism may be directed to Paul at the following address; he may also be reached at (313) 377-4329. With any luck Oakland U will be on MailNet in the not too distant future and communications will improve. Paul Amaranth Oakland University Academic Computer Services Rochester, MI 48063 USA The files are in KER:MU*.* on COLUMBIA-20 and CU20B, including PL/I source files, user help files, installation instructions, and program call tree listings. ------------------------------ Date: Fri 7 Sep 84 16:58:51-EDT From: Frank da Cruz Subject: Another Kermit for Victor/Sirius MS-DOS To: Info-Kermit@CU20B.ARPA This version of Victor Kermit is written in Computer Innovations 'C' by W. Hertha of Victor Technologies (Canada) and Dr. Joe Angel of the Department of Biochemistry of the University of Saskatchewan. There is no hex file format of the binary currently available, so you must have Computer Innovations 'C' to be able to compile it on a Victor. It should work with other complete 'C' compilers as well. It has been tested at 9600 baud with no problems. The help file describes any variations from the standard kermit implementations. Thanks to David Emigh of the University of Saskatchewan for this contribution. The files are in KER:VICKERMIT.* on CU20B and COLUMBIA-20. ------------------------------ Date: Fri 7 Sep 84 17:37:11-EDT From: Frank da Cruz Subject: TRS-80 Kermit Source Problems Fixed To: Info-Kermit@CU20B.ARPA Thanks to the many, including Brian Sietz of Rutgers, who pointed out the problems with the TRS-80 Kermit source files. We now have what we hope is a complete and correct set of files in KER:TRS*.* on CU20B and COLUMBIA-20. - Frank ------------------------------ Date: Thu 6 Sep 84 16:51:21-PDT From: Daniel H. Miller Organization: Litton Data Systems; Van Nuys, CA; (818)902-4493 Subject: Getting UNIX Kermit Session Transcripts To: info-kermit@COLUMBIA-20.ARPA I found an interesting method of obtaining UNIX Kermit transcripts: kermit clb /dev/tty0 1200 | tee transcript Kermit sets up its session in CONNECT mode over line tty0 at 1200 baud and then every time a character is received from the line it is sent via a pipe to tee which sends it to the terminal and to the transcript file. The transcript file contains what the user types and what is sent via the machine, since Kermit is operating in full duplex and all characters come back over the line. This works as long as Kermit only outputs via standard output. --- Dan Miller ------------------------------ From: Bruce Nemnich Date: 29 Aug 1984 0445-EDT (Wednesday) To: Info-Kermit@COLUMBIA-20.ARPA Subject: v2.26 heath emulation bug There is a heath emulation bug in v2.26 in that tabs are destructive, i.e., they wipe out characters under the range of their motion. I assume this is a bug; I don't have a real heath at hand, but all drivers I have seen assume heath tabs aren't destructive. For those of you using Unix, that means you will want to add the "xt" flag to the termcap and/or terminfo entries for your kermit terminals until the bug is fixed. --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA [Ed. - Anybody out there have a real Heath-19 to check this?] ------------------------------ Date: Fri, 07 Sep 84 20:59:14 EDT From: Jeff Kimmelman Subject: MS-DOS Kermit on Eagle PC-Plus To: info-kermit-request@columbia-20.arpa I am having problems with MS-Kermit on my Eagle PC-plus. It seems that I lose about one out every 10 characters when I am in terminal emulation connected to a host. I suspect that there are stop bit problems but am not sure. I haven't been able to get the manual yet and can find no command which alleviates the problem. If you can help I would greatly appreciate it. I am using generic Kermit by the way. Thanks in advance-- Jeffrey Kimmelman [Ed. - Generic Kermit can't be expected to work flawlessly on a new machine, only just barely. The solution, of course, is to add explicit system-dependent support for the Eagle, as we have for the IBM PC, Rainbow, Wang, HP150, etc. Any volunteers?] ------------------------------ Date: Sat 8 Sep 84 11:57:02-PDT From: Roland Hutchinson (r.rdh@su-lotsa) To: Info-Kermit@COLUMBIA-20 Subject: Bugs in MS-DOS Kermit 2.26 Congratulations to the implementors of the new MS-DOS Kermit!!! The following bugs and curious features have come to my attention in version 2.26 on the IBM-PC. CAVEAT: I HAVE NOT HAD TIME TO REASSEMBLE AND TEST THE FIXES SUGGESTED FOR THE FIRST TWO ITEMS BELOW. PLEASE REGARD THEM AS SUGGESTIONS ONLY!! I have thought it more important to report these to you quickly than to try to fix them myself with my limited experience in 8086 assembler! 1. Status line displays incorrect information. The status line (line 25) shows local echoing when echoing is in fact remote, and vice-versa. This is, to say the least, confusing. (The STATUS command, however, continues to give the correct information.) This one appears to be easy to fix: In the file MSTERM.ASM, make the following change: test flags,lclecho ; echoing? jnz modl4 ; no, keep going ;[ ^^^ THIS WAS JZ INSTEAD OF JNZ, IN ERROR] mov si,offset remmsg modl4: mov cx,3 ; size of on/off mov di,offset modbuf.m_echo rep movsb 2. Problems with command prompting. Typing "?" after certain commands yields an incorrect reprompt--the question mark is not removed from the line, thus: Kermit-MS>defi? Specify macro name followed by body of macro Kermit-MS>defi? Typing ESC at this point produces Kermit-MS>defiINE (note the two i's). This problem seems to affect the commands: DEFINE LOG SHOW MACRO SET PROMPT SET KEY SCAN This might be fixed by making the message strings FILHLP through SK2MSG in MSSET.CMD have the same format as the strings which proceed them, i.e., remove the leading space and insert cr and lf in the last six lines listed below. erms23 db cr,lf,'?0 or null scan code not allowed$' ;[jd] erms24 db cr,lf,'?Capture file already open (use close command)$' ;[jd] filhlp db ' Input file specification for session logging$' macmsg db ' Specify macro name followed by body of macro $' shmmsg db ' Confirm with carriage return $' prmmsg db ' Enter new prompt string $' sk1msg db ' Decimal scan code for key $' sk2msg db ' Redefinition string for key $' The proposed change would also have the benefit of making the "?" behave uniformly in different commands. (ALWAYS starting the help message on a new line.) [I have noticed a few other problems with command prompting & completion--if memory serves, typing the name of a command complete, but without a space, and following it immediately with a "?" was one situation. Sorry I don't have time to test and report at length just now, but my impression is that the whole command-parsing code needs a good systematic test!!!] 3. 8th-bit characters typed from the keyboard can cause a system crash!! This is rather a bad problem and I am afraid I have no idea how to fix it. Do the following: Kermit-MS>set key f1 Enter key definition: ^^Here, hold down the alt key and press 147 on the keypad (this is the normal way of entering characters 128 to 255 decimal from the IBM keyboard). Type a few more of 8-bit characters in this way, if you like. Then press RETURN. The screen will fill with stray bits of text, and seem to go into a loop. The floppy disk may start to spin after a while (fortunately, no damage seems to be done to the disk.) The only way out is to power down. I suspect that this problem occurs because CMGTCH (in the file MSCMD.ASM) sets the 8th bit to mark an "action character", and something in SETKEY or DEFKEY is unprepared to deal with other hi-bit characters. This is going to be a bit tricky to fix absolutely properly. Since ESC+80H, "?"+80H, " "+80H are all valid characters in IBM's extended character set, it should be possible to enter them from the keyboard. I don't see how this would be possible without rewriting COMND and much of the code that uses it. In the meanwhile, a fix that simply keeps the system from crashing and ignores these characters (or lets only some of them through, or whatever) would be a very good thing to have!!!!!! 4. SET KEY SCAN doesn't parse it's input correctly. SET KEY SCAN doesn't realize it should generate the same error as SET KEY SCAN or SET KEY SCAN You have to use ctrl-C to get out. I don't know what scan number it thinks it's getting or what it does if you give it a redefinition. (It accepts it, but where does it put it?) 5. Suggested improvement in SHOW MACRO command. It would be nice if this could reconvert the tabs (displayed as "\015") back into a printable character--preferably the comma, so that SHOW MACRO would show a definition string that looked like the one DEFINE originally read. 6. File transfer status line isn't sufficiently informative. The RETURN key is active during file transfers, and nothing on the screen warns the user about this. Pressing return carelessly during a transfer can get the transmission out of synch, and abort the current file being transfered. (It happened to me!!!!) The role of the RETURN key should be displayed somewhere on the screen (maybe on line 24, in reverse video to match line 25?). Would it be possible to fix it so that stray RETURN's can't break the file transfer? (Perhaps by making the return key active only if the comm port hasn't been busy for a while--the purpose of the RETURN is to do a "wakeup" as if the line had been timed out, isn't it? (If I have misunderstood the niceties of the protocol, kindly ignore this suggestion!!!)). 7. Undocumented command. The grey plus key (on the keypad) toggles the status line on and off. This isn't documented anywhere, or have I missed it? 8. Missing scan codes. Scan codes for ctrl with certain keys on the keypad don't seem to be passed along to the program. (Shift+keypad cod