Columbia Kermit

home *** CD-ROM | disk | FTP | other *** search

/ Columbia Kermit / kermit.zip / e / mail.84a < prev next >

Wrap

Text File | 2020-01-01 | 342KB | 7,850 lines

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 <decwrl!rhea!vax4!arson!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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: MS-DOS Kermit To: info-kermit@CUCS20 In-Reply-To: Message from "DMII 1.0 For: Keith Roberts <decwrl!rhea!vax4!arson!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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <WANUGA@MIT-XX.ARPA> 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 <cc.fdc@COLUMBIA-20.ARPA>" 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <WANUGA@MIT-XX.ARPA>" 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: <CC.DAPHNE@COLUMBIA-20.ARPA> 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 <CC.DAPHNE@CUCS20> 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 <CONTEXT@WASHINGTON.ARPA> 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 <WANUGA@MIT-XX.ARPA>" 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 <CONTEXT@WASHINGTON.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <Nemnich@MIT-MULTICS.ARPA> 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 <HFischer>pck20.new for the modified assembler code, and file <HFischer>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 <HFischer>PCK20.new (assembly code) and <HFischer>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 <BRACKENRIDGE@USC-ISIB> 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 <ALBERS @ MIT-ML> 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 <iglesias@uci-750a> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: Kermit for CP-6 To: iglesias@UCI-750A.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Mike Iglesias <iglesias@uci-750a>" 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: <HFischer>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 <G.FUSSELL@SU-SCORE.ARPA> 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) <wkc@ardc> 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) <wkc@ardc> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: rt kermit To: G.FUSSELL@SU-SCORE.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Carl Fussell <G.FUSSELL@SU-SCORE.ARPA>" 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <Friedman@Ru-Blue> ------- 23-Jan-84 16:40:15-EST,700;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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<CR> or SET IBM<CR>). 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <judd%umcp-cs@CSNet-Relay> Return-Path: <judd%umcp-cs@CSNet-Relay> 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 <LATZKO@RU-BLUE.ARPA> 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 <latzko@ru-blue.arpa> ------- 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 <HOWALD%USC-ECLB@SRI-NIC> 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 <OC.Trei@CU20B> 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 <KERMIT>, 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) <decwrl!rhea!vax4!arson!ziemba@su-shasta> 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 <iglesias%uci-750a> (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: <G.GARLAND@COLUMBIA-20.ARPA> 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 <G.GARLAND@CUCS20> 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 "<CTRL>A3S" <== chain SSC to Videx 80 col. card 4) Type "<CTRL>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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <SY.FDC@CU20B> 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:<KERMIT>, 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 <WYNN@SU-SIERRA.ARPA> 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 <Kenny@HIS-PHOENIX-MULTICS.ARPA> Date: Tue, 31 Jan 84 21:29 MST From: Kevin Kenny <Kenny@HIS-PHOENIX-MULTICS.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <judd%umcp-cs@CSNet-Relay> Return-Path: <judd%umcp-cs@CSNet-Relay> Subject: Re: [TS.WALT: Fortran/Pascal "VMS KERMIT"] To: Frank da Cruz <cc.fdc@COLUMBIA-20>, 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 <MOORE.LOSANGEL.IBM@Rand-Relay> Return-Path: <MOORE.LOSANGEL.IBM-SJ@Rand-Relay> 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 <HFischer>PCK20.LPT (default-style printable on dumb terminal), and in file <HFischer>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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <judd%umcp-cs@CSNet-Relay>" 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 <beattie at mitre-gateway> 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 <G.TJM@SU-SCORE.ARPA> 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 <cc.fdc@COLUMBIA-20.ARPA>" 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]<HFischer>PCK20.LPT and .MSS . Herm Fischer ------- 6-Feb-84 14:00:41-EST,642;000000000000 Return-Path: <CC.DAPHNE@COLUMBIA-20.ARPA> 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 <CC.DAPHNE@CUCS20> Subject: Re: KERMIT/VM/CMS To: MOORE.LOSANGEL.IBM@RAND-RELAY.ARPA cc: info-kermit@CUCS20 In-Reply-To: Message from "Jim moore <MOORE.LOSANGEL.IBM@Rand-Relay>" 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 <rag@uw-june> 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 <fox.vpi@Rand-Relay> Return-Path: <fox%vpi.vpi@Rand-Relay> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <fox.vpi@Rand-Relay>" 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 <OC.WBC3@CU20B> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <OC.WBC3@CU20B> 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 <OC.GARLAND@CU20B> 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: <johnston@LBL-CSAM> 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 <leo@mit-pamela> Subject: Too many Kermits (Kermi ?) To: <Info-Kermit%COLUMBIA-20@mit-mc> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: unix kermit server To: beattie@MITRE-GATEWAY.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "brian beattie <beattie at mitre-gateway>" 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <OC.WBC3@CU20B> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <leo@mit-pamela> Subject: Kermit on the SUN To: <Greg.Glass%cmu-cs-cad%cmua@mc>, <info-kermit%columbia-20@mc> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <WANUGA@MIT-XX.ARPA> 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 <judd%umcp-cs@CSNet-Relay> Return-Path: <judd%umcp-cs@CSNet-Relay> Subject: Re: Reply to brean beattie Re: Unix kermit server To: David Ragozin <rag@uw-june>, 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: <CC.KEN@COLUMBIA-20.ARPA> 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 <cc.Ken@CUCS20> Subject: Re: KRFC #10 (?), database service To: Info-Kermit@CUCS20 In-Reply-To: Message from "Frank da Cruz <cc.fdc@COLUMBIA-20.ARPA>" 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 <LIN @ MIT-MC> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: Kaypro, VENIX To: WANUGA@MIT-XX.ARPA cc: Info-Kermit@CUCS20 In-Reply-To: Message from "Thomas S. Wanuga <WANUGA@MIT-XX.ARPA>" 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 <Spitzer@HIS-PHOENIX-MULTICS.ARPA> Date: Fri, 10 Feb 84 07:45 MST From: Charlie Spitzer <Spitzer%pco@CISL-SERVICE-MULTICS.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <judd%umcp-cs@CSNet-Relay>" 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: KRFC #10 (?), database service To: cc.Ken@CUCS20, Info-Kermit@CUCS20 cc: cc.fdc@CUCS20 In-Reply-To: Message from "Ken Rossman <cc.Ken@COLUMBIA-20.ARPA>" 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <kdp%HP-LABS.HP-LABS@Rand-Relay> Return-Path: <kdp.HP-Labs@Rand-Relay> 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 <HFischer>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 <LIN @ MIT-MC> Herb, Most of our hosts have KERMIT.DOC in their <DOCUMENTATION> directories, or you can FTP it down (kind of big, though). As I remember, COLUMBIA-20 now has (in <KERMIT> 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 <G.TJM@SU-SCORE.ARPA> Subject: Re: KRFC # 11, Kermit commands To: Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Frank da Cruz <cc.fdc@COLUMBIA-20.ARPA>" 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: <CC.DAPHNE@COLUMBIA-20.ARPA> 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 <CC.DAPHNE@CUCS20> Subject: Re: KRFC # 11, Kermit commands To: G.TJM@SU-SCORE.ARPA cc: info-kermit@CUCS20 In-Reply-To: Message from "Ted Markowitz <G.TJM@SU-SCORE.ARPA>" 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: KRFC # 11, Kermit commands To: G.TJM@SU-SCORE.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Ted Markowitz <G.TJM@SU-SCORE.ARPA>" 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 <Kenny@HIS-PHOENIX-MULTICS.ARPA> 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 <ALBERS @ MIT-ML> 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 <info-kermit%columbia-20.arpa%columbia-20.arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa> 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 <CCIMS.WILSON@CUTC20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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" <POURNE@mit-mc.arpa> Subject: Let's spread the good news! To: Per_Lindberg_QZ <Per_Lindberg_QZ%qzcom@ucl-cs.arpa>, KERMIT_implementation_and_experience <KERMIT_implementation_and_experience%qzcom@ucl-cs.arpa> cc: info-kermit <info-kermit%columbia-20.arpa%columbia-20.arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa> In-reply-to: Msg of 13 Feb 84 13:29 +0100 from Per_Lindberg_QZ%qzcom at ucl-cs.arpa Sender: POURNE <POURNE%mit-mc.arpa@usc-isid.arpa> 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 <info-kermit%columbia-20.arpa%columbia-20.arpa%ucl-cs.arpa%ykxa at ucl-cs.arpa> Re: Let's spread the good news! Remailed-From: Billy <BRACKENRIDGE@USC-ISIB> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <judd%umcp-cs@CSNet-Relay> Return-Path: <judd%umcp-cs@CSNet-Relay> Subject: Take me off Kermit mail list. Someone else gets it and one is enough. To: Frank da Cruz <cc.fdc@COLUMBIA-20>, 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 <KEN@JPL-VLSI> 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 <TSAI@RU-BLUE.ARPA> 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 <info-kermit%columbia-20.arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa>, 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 <info-kermit%columbia-20..arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa> 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 <info-kermit%columbia-20.arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa>, 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 <info-kermit%columbia-20.arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa>, 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <maples at mitre-gateway> 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 <Margolin@MIT-MULTICS.ARPA> 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 <info-kermit%columbia-20.arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa>, 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <kermit> 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 <KERMIT> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <BILLW@SRI-KL.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <ables@ut-ngp.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: bug in CPMBASE.M80 v3.6 To: ables@UT-NGP.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "King Ables <ables@ut-ngp.ARPA>" 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <johnston@lbl-csam> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <LECIN@RU-BLUE.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <cc.fdc@COLUMBIA-20.ARPA> 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 <LECIN@RU-BLUE.ARPA>" 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 <G.FUSSELL@SU-SCORE.ARPA> Subject: Re: MACRO-11 Kermit Query To: LECIN@RU-BLUE.ARPA cc: kermit@RUTGERS.ARPA In-Reply-To: Message from "Matthew J Lecin <LECIN@RU-BLUE.ARPA>" 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 <cc.fdc@COLUMBIA-20.ARPA> 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 <G.FUSSELL@SU-SCORE.ARPA>" 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 <Smith@USC-ECLC.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: Kermit for DEC Professional? To: Smith@USC-ECLC.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from "Dennis R. Smith <Smith@USC-ECLC.ARPA>" 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 <SIETZ@RU-GREEN.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: MS-DOS KERMIT for the DEC Rainbow To: SIETZ@RU-GREEN.ARPA, info-kermit@CUCS20 In-Reply-To: Message from "Brian <SIETZ@RU-GREEN.ARPA>" 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 <Friedman@RU-BLUE> 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" <Klensin@MIT-MULTICS.ARPA> 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 <OC.GARLAND@CU20B> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: Rainbow CP/M-80 Kermit warning To: Klensin@MIT-MULTICS.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from ""John C. Klensin" <Klensin@MIT-MULTICS.ARPA>" 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <BILLW@SRI-AI.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <FRAYMAN@SUMEX-AIM.ARPA> 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 <BILLW@SRI-AI.ARPA> 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 <info-kermit%columbia-20.arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa> 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 <OC.BUSH@cu20b> Subject: Re: KERMIT-10 requires parity? To: Per_Lindberg_QZ <Per_Lindberg_QZ%qzcom%ucl-cs.arpa@columbia-20.arpa> cc: info-kermit <info-kermit%columbia-20.arpa%ucl-cs.arpa%ykxa%ucl-cs.arpa@columbia-20.arpa> In-Reply-To: Message from "Per_Lindberg_QZ%qzcom@ucl-cs.arpa" of Thu 15 Mar 84 13:29:00-EST Sender: "OC.BUSH" <OC.BUSH%cu20b@columbia-20.arpa> 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 <OC.GARLAND@CU20B> 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 <info-kermit%columbia-20.arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa>, 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 <iglesias@uci-750a> 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 <iglesias@uci-750a> 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 <Kling%UCI-20B@UCI-750a> 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 <Schauble@MIT-MULTICS.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <Kling%UCI-20B@UCI-750a>" 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 <Linnerooth@SANDIA.ARPA> 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" <Klensin@MIT-MULTICS.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: Osborne kermit To: Klensin@MIT-MULTICS.ARPA, Info-Kermit@CUCS20 In-Reply-To: Message from ""John C. Klensin" <Klensin@MIT-MULTICS.ARPA>" 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 <SLAVENBURG@SU-SIERRA.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <papa%usc-cse.csnet@csnet-relay.arpa> 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 <papa%usc-cse.csnet@csnet-relay.arpa> 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 <iglesias@uci-750a> 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 <papa%usc-cse.csnet@csnet-relay.arpa> 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 <sob@rice.ARPA> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <grich@uci-750a> 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 <papa%usc-cse.csnet@csnet-relay.arpa> 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 <kdp%hp-labs.csnet@csnet-relay.arpa> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> Subject: Re: XON handshaking To: kdp%hp-labs.csnet@CSNET-RELAY.ARPA cc: Info-Kermit@CUCS20 In-Reply-To: Message from "Ken Poulton <kdp%hp-labs.csnet@csnet-relay.arpa>" 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 <OC.Trei@CU20B> 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 <KERMIT>, 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: <G.GARLAND@COLUMBIA-20.ARPA> 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 <G.GARLAND@CUCS20> 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 "<CTRL>A3S" <== chain SSC to Videx 80 col. card 4) Type "<CTRL>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) <LECIN@RU-BLUE> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <kdp%hp-labs.csnet@csnet-relay.arpa> 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 <Friedman@Ru-Blue> ------- 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) <GEOFFM@SRI-CSL> 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 <OC.BUSH@CU20B> 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: <G.BUSH@COLUMBIA-20.ARPA> 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 <G.BUSH@CUCS20> 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 <OC.GARLAND%CU20B%CU20B@COLUMBIA-20> 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 <G.BUSH@CUCS20>" 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 <LATZKO@RU-BLUE.ARPA> 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 <latkzo.ru-blue.arpa> ------- 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 <papa%usc-cse.csnet@csnet-relay.arpa> 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 <INSTIT-STUDIES.WJBALDWIN@CUTC20> Subject: Re: Apple Kermit To: G.BUSH@CUCS20, INFO-KERMIT@CUCS20 cc: INSTIT-STUDIES.WJBALDWIN@CUTC20 In-Reply-To: Message from "Nick Bush <G.BUSH@CUCS20>" 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 <STAFF.SAS@UChicago.Mailnet> 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 <G.FUSSELL@SU-SCORE.ARPA> 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 <chin%hp-labs.csnet@csnet-relay.arpa> 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 <EXT1.SAMANI@CU20B> 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" <LATZKO@RU-BLUE.ARPA> cc: "Alexander B. Latzko" <LATZKO@RU-BLUE.ARPA> 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 <Z00.R-Gerber@NYU20> 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 <STAFF.SAS@UChicago.Mailnet> Subject: [Don Goldhamer <STAFF.DHG@UChicago.Mailnet>: 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 <STAFF.DHG@UChicago.Mailnet> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <LAVITSKY@RUTGERS.ARPA> 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 <kdp%hp-labs.csnet@csnet-relay.arpa> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <cc.fdc@CUCS20> 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 <filename> >dfile', followed by ^\c and R <filename> 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 <filename>. 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 <info-kermit@COLUMBIA-20> 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 <PAWKA at NOSC-TECR> 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 <PAWKA at NOSC-TECR> 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 <info-kermit@COLUMBIA-20> 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 <Linnerooth@SANDIA.ARPA> 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 <SIETZ@RU-GREEN.ARPA> 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 <kdp%hp-labs.csnet@csnet-relay.arpa> 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: <G.BUSH@COLUMBIA-20.ARPA> 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 <G.BUSH@CUCS20> 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 <BRACKENRIDGE@USC-ISIB> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <CC.FDC@CUCS20> 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 <BRACKENRIDGE@USC-ISIB> 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: <CC.FDC@COLUMBIA-20.ARPA> 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 <CC.FDC@CUCS20> 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 ....<cr>) 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 <lf> at start of file; there is an implied ; <cr> 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