14-Jul-86 11:58:35-EDT,11600;000000000000 Mail-From: SY.CHRISTINE created at 14-Jul-86 11:57:35 Date: Mon 14 Jul 86 11:57:35-EDT From: Christine M Gianone Subject: Info-Kermit Digest V5 #1 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12222638324.32.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Mon, 14 Jul 1986 Volume 5 : Number 1 Today's Topics: Kermit Now Available for Atari ST Info-Kermit-Request ID confusion PDP-11 Kermit Binaries Using VMS Backup with Kermit Swedish characters in Kermit RE: Swedish characters in Kermit ---------------------------------------------------------------------- Date: Thu 3 Jul 86 15:37:22-EDT From: Frank da Cruz Subject: Kermit Now Available for Atari ST Keywords: Atari ST Kermit This is to announce Kermit for the Atari ST series of personal computers, contributed by Bernhard Nebel, Technische Universitaet Berlin (NEBEL@DB0TUI11.BITNET). The program is written in DRI C, and is based upon the OS9 version of Kermit, which was in turn based on the original (simple) UNIX Kermit. The program transfers text and binary files, can do wildcard sends, and includes the necessary settings for communicating with IBM mainframes (parity, handshake, 8th-bit prefixing). IBM communications is one major advantage of this program over the Kermit program that DRI has been distributing with their GEM developers kit (and which they never submitted to Columbia Kermit Distribution), and another is that this one (unlike DRI's) actually employs the GEM user interface. GEM Kermit does not provide a terminal emulator, nor does it manipulate RS-232 parameters itself. Instead, it relies on existing accessories from the desk menu to supply these functions. Bernhard has also supplied a special IBM line-mode terminal accessory. The source consists of C and header files, and there are also some "uuencoded" binary files for the Kermit program itself and various accessories and resource files. As originally submitted (via BITNET mail), the file names had the prefix ST, but since that prefix was already in use for Software Tools Kermit, I changed the names of the files from STK*.* to AST*.*. In most cases this was a simple string replacement, but STKERM.* became ASTKER.*. Also UUENCODE.C and UUDECODE.C became ASTUUE.C and ASTUUD.C, respectively. I also changed (I hope) all internal references to these filenames accordingly. The files are available in KER:AST*.* on CU20B via anonymous FTP on the Internet, or on BITNET from KERMSRV at CUVMA, and should appear within a reasonable amount of time at Oklahoma State for UUCP access. ASTKER.DOC is the documentation (in English), which includes installation instructions. ------------------------------ Date: Fri 11 Jul 86 13:50:11-EDT From: Ken Rossman Subject: Info-Kermit-Request ID confusion Keywords: Info-Kermit-Request My apologies to those of you who sent mail to Info-Kermit-Request and got it bounced back to them with a "No such directory" error. We have been moving files and directories around on the system lately, and the redistribution list to which "Info-Kermit-Request@CU20B" points was moved along with everything else, but the list was not updated. It is fixed now. Sorry for any inconvenience. /Ken ------------------------------ Date: Mon 7 Jul 86 14:08:20-EDT From: Frank da Cruz Subject: PDP-11 Kermit Binaries Keywords: PDP-11 Kermit For those who are able to transfer files from CU20B using FTP or NFT, and who need the latest release of PDP-11 Kermit (for RSX, RT, or RSTS), the 8-bit binary .TSK or .SAV images are now available in KB:K11*.*. These are considerably smaller than the .HEX files in the main distribution, and require no postprocessing. Thanks to Brian Nelson for sending them in on diskette. ------------------------------ Date: Thu 10 Jul 86 09:19:47-EDT From: Frank da Cruz Subject: Using VMS Backup with Kermit Keywords: VMS Kermit Apparently, VMS Backup cannot create a saveset on disk with a blocksize of 512, which is the blocksize used by VMS Kermit when you give the "set file type fixed" command. To remedy this situation, Gary Stebbins of DEC wrote a little procedure for converting VMS Backup savesets to and from blocksize 512, to allow these files to be transferred with Kermit. Use of Backup in this way permits convenient transfer of a group of unlike or complex files in a single Kermit operation, such that all their FILES-11 and RMS attributes are preserved after transfer. Thanks to Bernie Eiben for sending it in. The files are in KER:VMSBAK.DOC and KER:VMSBAK.BAS. ------------------------------ Date: Mon 7 Jul 86 19:32:24-EDT From: Frank da Cruz Subject: Re: Swedish characters in Kermit Keywords: Swedish characters [Ed.- This is in response to those of you interested in getting Swedish characters on your screen during terminal emulation using Kermit.] Unfortunately, there's no "standard" version of Kermit that will display Swedish characters on the screen, because there's no commonly accepted way to represent Swedish (or Norwegian, or Finnish, or German, or Spanish, or Hebrew, or...) characters in 7-bit ASCII. Old versions of IBM PC Kermit (the current version is 2.29) have been modified to display Swedish characters from a special font when certain 7-bit ASCII characters are received, but so far there is no good, general solution to this problem, because of the lack of standards (or more precisely, the lack of conformity to existing ISO standards). The best person to ask about this would be Per Lindberg at the University of Stockholm (Per_Lindberg_QZ@QZCOM). He advocates the use of a special console driver to map between US ASCII and Swedish (or any other) characters. Unfortunately, doing it this way would interfere with Kermit's built-in VT102 terminal emulation; the only way to get IBM PC Kermit to show Swedish characters on the screen is modify the program. But then how do you make the Norwegians, Finns, Germans, Spaniards, and Israelis happy? And then what about the Turks, Russians, Armenians, Japanese, Cherokee, etc etc? Since it is undesirable to modify the Kermit program for each new "national" character set to be supported, a better solution might be to adopt a new mechanism usable at runtime, something like the key redefinition mechanism (SET KEY). But such a mechanism would probably be somewhat complicated, because different systems use different methods to transmit "national" characters: (a) Selected 7-bit USASCII characters are redefined, for instance left square bracket "[" might come out as an umlaut-A on a Swedish terminal. (b) 8-bit codes are used to represent the national characters. This might follow some proposed standard, or it might be completely system dependent (the IBM PC or DEC Rainbow have built-in 8-bit characters, totally different from each other). (c) A shift-in/shift-out sequence might be used to switch between character sets. This could correspond with the VT100's ability to switch in and out of the alternate character set ROM, triggered by ESC ( 1, ESC ( 2, etc. If anybody knows about a good, general solution to this problem that does not require the program be modified for every new character set, please speak up. - Frank ------------------------------ Date: 08 Jul 86 19:39 +0200 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: Swedish characters in Kermit Keywords: Swedish Characters **KERMIT, IBM PC and national characters.** Yes, there *is* a standard way to represent national characters with a 7-bit code! Instead of adding more bits, the trick is to shift between several character sets. The ANSI standard X3.41 escape sequence "SCS" (Select Character Set) which is implemented in the VT100 and VT102 does this. ANSI X3.41 is related to ANSI X3.64, on which the VT100 is based. This scheme is also an ISO and SIS (Swedish Institute for Standards) standard. I suggest that you look up SIS 63 61 27 (ISO ESC 2/8 4/0 and ISO ESC 2/8 4/7 and ISO ESC 2/8 4/8). My VT100-workalike can shift between vanilla ASCII and SIS using the ESC ( A, ESC ( B etc. scheme. The characters [ \ ] { | } are umlaut A:s and O:s (upper & lower case) on the keyboard, and the ANSI ESC sequence shifts what the screen shows. There is a *big* difference in difficulty learning which is what: I know without thinking which key to hit for a left square bracket, but reading a C program with that on the screen is awful. So I just switch what the screen shows, and no problem. BEGIN wThe *problem* is IBM, who choose to use a non-standard 8-bit code for representing national characters. Foo! ALSO they have the WORST keyboard in history, with *both* USA and Swedish layouts. Double foo! (They are different, [ is an upper-case letter, so we want it shifted). END To live with this problem, all communications software on their PC has to talk 7-bit codes with the port and 8-bit codes with the screen and possibly also with the keyboard. Your (a)-(b)-(c) scheme is sound. To do this, I suggest you give KERMIT a character translation table for I/O to COM:, and another table for keyboard layout. This, I beleive, would solve the problem for all languages on the PC, be they Swedish, Hebrew or whatever. The tables should be written in assembler (using MACROs?), and linked with KERMIT giving an .EXE file which works on swedish-modified PC:s. (Swedish keyboard layout, the right 8-bit codes to the screen, the corresponding 7-bit codes to/from the port). Thus nationally flavoured KERMITs can be distributed. (A luser can't hack and link it, we have to do it and distribute diskettes, which we do anyway). The console driver I have been talking about is not a good solution. However, IBM puts out a program called KEYBSV (KEYBNO for norway etc) with *all* swedish PC:s which (I think) remaps the BIOS keyboard driver. But since KERMIT reads the keyboard the hard way (?), this won't help. (And you don't want to send 8-bit codes to the port!) I have heard rumours that IBM has a paper with recommendations for nationalizing software, have you seen it? (I have not). Do try to get a copy of it, if it exists. By the way, if you are implementing VT100 in KERMIT (which I think is a very good idea), you might want to test it with my VTTEST program which tests all features (and a few bugs...) in a VT100 (VT102). The program is written in C, and runs under TOPS-10 and Twenex (Sargasso C) and UNIX. If you don't already have it, I'll send it! -- Per Lindberg (Per_lindberg_QZ@QZCOM.MAILNET) QZ - Stockholm U. Computing Center Box 27322 S-10254 Stockholm Sweden + 46 8 654500 ...enea!suadb!lindberg (Im am not with the University of Stockholm, but the Stockholm University Computing Center, which is another organisation). ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Jul-86 12:09:47-EDT,31929;000000000000 Mail-From: SY.CHRISTINE created at 18-Jul-86 12:07:51 Date: Fri 18 Jul 86 12:07:51-EDT From: Christine M Gianone Subject: Info-Kermit Digest V5 #2 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12223688767.188.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Fri, 18 Jul 1986 Volume 5 : Number 2 Today's Topics: Additional BITNET Kermit File Access Amiga Kermit Bootstrapping Extra-Long Packets Specification KERMIT Transfer Rates with File Compression MS-Kermit 2.29 Memory Contention Problem Rosetta Stone for MS-Kermit and VT100 A Wish List (long) ---------------------------------------------------------------------- Date: Tue, 15 Jul 86 06:19 EST From: (brian nelson) Subject: Additional BITNET Kermit File Access Keywords: KERMSRV at Uoft02 Usage of kermsrv@uoft02.bitnet There is a bitnet server for Kermit files at the node Uoft02. The 'user' is called KERMSRV and is accessed in the following manner: from VM/CMS: CP SMSG RSCS MSG UOFT02 KERMSRV DIR CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.* from VMS Jnet: $ SEND KERMSRV@UOFT02 SEND K11*.* Please note that any filespec containing wildcard characters will be queued for a deferred transmission; please do not override this by submitting multiple requests. Also, there is no point in sending requests that involve CUVMA or CUNYVM in the routing. If the traffic is too high, there is a possibility that requests could be deferred to the next day. We are connected to Ohio State via 9600 line, then to PSUVM which goes to CUNYVM when I send you mail. Most of the european traffic seems to go from PSUVM to GWUVM and then out to EARNET. Anyway, I think we want to avoid routing that involves CUNYVM. Sorry, if we were farther west then this thing would be more useful. The commands are (in Jnet format) $ send kermsrv@uoft02 dir FILESPEC $ send kermsrv@uoft02 send FILESPEC $ send kermsrv@uoft02 vmsdump FILESPEC $ send kermsrv@uoft02 help The 'VMSDUMP' command can be used to avoid EBCDIC translation, thus if you are running jnet on your vax you can request Kermit-11 binary files. brian@uoft02.bitnet [Ed. - Thanks for the information Brian!] ------------------------------ Date: Wed, 16 Jul 86 16:22 N From: Subject: Amiga Kermit Bootstrapping Keywords: Amiga Kermit, Bootstrapping As I tried to install the Amiga Kermit I found out there was no real solution for the bootstrap procedure: How could I get the CKIBOO.BAS and CKIKER.BOO files on our Amiga? One of the problems was, that if I used a simple BASIC program, buffer overflows occurred and there was no reliable stop criterium. That's why I wrote two programs, one for our Vax and one BASIC program for the Amiga which can do the job. W. Maessen Agricultural University, Wageningen, The Netherlands P.S. I didn't have the time to create a composite program which combines CKIBOO.BAS and this Amiga Basic program, but it sure would save some time. [Ed. - Thanks! The programs are listed in the file KER:CKIBOO.MSG.] ------------------------------ Date: Thu 17 Jul 86 13:19:44-EDT From: Frank da Cruz Subject: Extra-Long Packets Specification Keywords: Extra-Long Packets, ELP Recent technological advances have brought high-speed, error-correcting asynchronous dialup modems into the marketplace, and it won't be long until they are affordable by ordinary mortals. The first question some people ask when they learn of these of these devices is whether their error-correcting capability has made Kermit obsolete. The answer is an emphatic no, for at least two reasons. First, although error-free transmission may be guaranteed from modem to modem, it cannot be assurred between modem and computer. Second, even when the connection between computer and modem is clean, problems of file delimitation, file representation, and computer-to-computer synchronization are not solved by these modems. When new communication technologies provide high-speed, potentially error-free paths, then file transfer performance is unreasonably hampered by Kermit's short packets and its stop-and-wait operation. But (you ask) won't the long packet extension solve this problem? Perhaps, for some modems. But others, already on the market, will not perform at their peak unless they handle data in bursts even longer than the 9024-byte maximum provided by this extension. One such modem, operating in half duplex, wants data in chunks of at least 16K-20K, and others may need even more. Successful transmission of very long packets, especially at high speeds, requires effective end-to-end full duplex flow control. When modems or other intermediate devices are involved, each device along the chain must be able to control the flow of data from the devices "upstream." For instance, if the receiving computer cannot keep up with arriving data, it must be able to stop the modem, and when the modem's buffers approach fullness, it must stop the other modem, which in turn must be able to stop the sending computer, all without loss of a single byte of data. But given a virtually error-free path with reliable end-to-end flow control, Kermit's maximum packet length can be further increased by employing a second kind of extended header, which is just like the long-packet (LP) header, except with a 3-byte, rather than 2-byte, extended length field. The presence of a 3-byte length field is signalled when the LEN field of the packet indicates (after decoding) a length of one. The DATA field of such a packet begins with an extended header in which the first three bytes are the 3-digit base-95 length, and the 4th byte is the header checksum. This allows for lengths up to 857,374 (95 cubed minus 1). To ensure that this extension is compatible with Kermit programs that are unaware of it, we must include it in the negotiations. Rather than extend the capability mask into a second byte, we take over one of the reserved bits, and assign capability #2 (bit 4 of the first capability byte, corresponding to a value of 16) for extra-long packets (ELP). The rest of the initialization string stays the same, but the interpretation of the MAXLX1 and MAXLX2 fields, which appear at CAPAS+2 and CAPAS+3 respectively, is different. If the ELP capability bit is set (regardless of the setting of the LP bit), then the 2-digit base-95 quantity given by MAXLX1 and MAXLX2 should be multiplied by 95 to obtain the intended length. In other words, MAXLX1 is the "9025's place" (rather than the 95's place), and MAXLX2 is the 95's place (rather than the 1's place). For instance, if the maximum length is to be 30,000, the encoding could be "#>" (3x9025 + 30x95 = 29,925) or "#?" (30,020). As with regular long packets, the file receiver tells the sender the maximum length packet to send. But now there are more possibilities, since either Kermit program may support one or the other or both (or neither) long packet extension. If the receiver does not support LP or ELP, the sender will send only normal packets (NP). If a Kermit program supports ELP, then it should also support LP, so that it can fall back to LP rather than to NP when the receiver supports LP but not ELP. The interesting case arises when the sender supports only LP, but the receiver supports both LP and ELP. If the receiver puts the ELP maximum length in MAXLX1 and MAXLX2, then the sender (which is unaware of the ELP extension) will interpret these numbers as the LP maximum length, 95 times smaller than what the receiver intended. But since the sender goes first in the negotiation, the receiver sees that the sender does not have ELP capability, and in this case it can specify a suitably large LP maximum length (like 9024) in its own initialization string, rather than an ELP maximum length that the sender would misinterpret. Without this trick, fallback would occur to a much smaller size. A few final words of caution are necessary. First, the longer the packet, the more rigorous the required error-checking technique; it would be unwise to transmit packets of thousands of characters guarded by anything less than a 16-bit CRC. Second, extra-long packets are untried as of this writing; even if the technique works, performance might be disappointing if the implementation follows the straightforward path suggested in all the foregoing code. When packets are very long, the transmission line can sit idle for extended periods while packets are being assembled and disassembled. Although idleness is unavoidable while the receiver is checking and processing the packet before ACKing it, the sender can make use of this time to begin assembling its next packet, so that additional idle time after the ACK is received is avoided. This trick requires an additional packet transmission buffer, which, for very long packets, might be hard to find. Finally, users must know the required conditions for successful use of long packets, and must request extended packet sizes explicitly; too many things can go wrong if long packets are used by default. ------------------------------ Date: Tue, 15 Jul 86 13:19 EDT From: CCPHIL@TUCC.BITNET (Phil Julian, SAS Institute) Subject: KERMIT Transfer Rates with File Compression Keywords: Compression We have found that piping Kermit input through a 'compress' program will greatly increase the transmission rate when going between a Sperry 5000 Unix system and an HP 9000 Unix system, using C-Kermit on both ends. Much of the improvement may be due to spaces in the original source, and nulls in the tar format, but the effects of the compression program are much greater than Kermit's internal space compression. The first attempt to send the files was tar cf - . | kermit -i -s - on the HP 9000 kermit -i -k | tar xf - on the Sperry 5000 22 megabytes took 8.5 hours to send, with a 31.4% efficiency rate, at 19.2k baud. The next attempt to send the files was tar cf - . | compress | kermit -i -s - on the HP 9000 kermit -i -k | uncompress | tar xf - on the Sperry 5000 4 megabytes took 1 hour to send, with a 54.6% efficiency rate, at 19.2k baud. The improvement was a 74% over using Kermit alone. The compress program is in the public domain, and uses the Lempel-Ziv algorithm. These figures may add to the argument to add space compression algorithms to the Kermit protocol. Few systems have Unix-like pipes, so the addition to the protocol would be useful. [Ed. - Yep, in fact this technique is suggested in the documentation. There are other problems with Unix Kermit performance too, including excessive copying of data from buffer to buffer, single-character i/o where bulk i/o would suffice, lack of flow control, etc. These will be addressed in future releases.] ------------------------------ From: I. WRENCH Date: Wed, 16 Jul 86 09:11:36 BST Subject: MS-Kermit 2.29 Memory Contention Problem Keywords: MS-Kermit 2.29 memory contention In a previous UK newsletter I asked for help with problems using v2.29 of Ms-Kermit to a DEC 10 system. The symptoms were that files sent from the PC contained spurious characters on arrival, always in the same places. Several people replied with sugestions, all of which i tried and seem to have no success. I managed to get access to kermits on non-DEC machines and tried my Ms-Kermit out with them - and got exactly the same problem. This lead me to think that my actual copy of Ms-Kermit (brought down in .BOO form from Lancaster) might have been corrupted somehow. I brought the .BOO file down again using a different terminal capture prog than I originally used, and converted the .BOO file using both the .PAS and .BAS de-hexers - but nothing changed. This seems to suggest that there was something wrong with the set-up on the IBM-XT I was using, and with a lot of playing around I traced down the problem to be a program called INT10 that was being loaded in the AUTOEXEC.BAT file. This program I believe has something to do with the Hercules graphics board and I presume was causing workspace contention problems with Ms-Kermit. I think this was caused as Ms-Kermit was growing in size to the point when the problem was triggered at the release of v2.29. Incidentally the scroll back pages function also just stopped working, it just pulled back rubbish onto the screen. Anyway all is back to perfect working order now, if anyone else was having similar problems to me i.e a perectly good program just stopped working properly, and you can't trace it, then look to see what else is resident in memory. Hope this is of use. Iain Wrench. [Ed. - See next message.] ------------------------------ Date: 17 JUL 86 13:31-MDT From: JRD@USU Subject: RE: MS-Kermit 2.29 Memory Contention Problem Keywords: MS-Kermit 2.29 memory contention Iain's difficulties were appearence of strange characters in transferred files and a trashed roll back screen. In his most recent note he traced both to a Hercules supplied Helpful Utility, INT10.COM. Indeed, Iain. The Hercules display board has characteristics much different than standard IBM boards. Their INT10 program intercepts Bios Int 10h calls (video display) and maps them into Hercules compatible form and might also use memory not belonging to itself. The strange looking characters on the roll back display were graphics images whereas Kermit expects text and attributes. I have a legal copy of INT10 here and get similar troubles. However, Kermit runs well with the EGA boards, in text mode. Thanks for the specific symptoms. I had seen your original note in the UK Kermit newsletter, but have not had time to reply. Regards, Joe D. ------------------------------ Date: Mon, 14 Jul 86 21:51:40 EDT From: Edward_Vielmetti%UMich-MTS.Mailnet@MIT-MULTICS.ARPA Subject: Rosetta Stone for MS-Kermit and VT100 Keywords: VT100 Emulation, Keyboard settings After (too much) hacking around with various other terminal programs and with Kermit, I've come up with a reasonably useful general reference for mapping the vt100 keypad with MS-Kermit. No single keyboard mapping is "best"; it all depends on your particular application. In particular, some keyboards are best mapped logically (f1 corresponds to numeric pad 1) and others are best done physically (the one in the upper corner is the same in both). Instead of trying to please everyone, here's a way to roll your own with a minimum of effort. The first set of diagrams are pictures of the keyboard mappings for all the vt100 implementations I could find. There aren't too many, but these few show the various approaches nicely. The second set of diagrams should save some time when you build an initialization file. In it are the results of SHOW KEY for all the function keys and all the numeric keypad keys. (The numeric keypads shown have an enter key on them, since they were done on a Zenith 158. With that exception they should be generally applicable. I don't have an enhanced AT keyboard to play with.) Edward Vielmetti Computing Center MicroGroup University of Michigan emv%UMich-MTS.Mailnet@MIT-Multics.ARPA +----+----+----+----+ | PF1| PF2| PF3| PF4| This is the layout of a real, live +----+----+----+----+ VT100 keypad. | 7 | 8 | 9 | - | +----+----+----+----+ | 4 | 5 | 6 | , | +----+----+----+----+ | 1 | 2 | 3 | | +----+----+----+entr| | 0 | . | | +---------+----+----+ +----+----+----+----+ | SF1| SF2| SF3| SF4| This is the layout of the VT100 emulation +----+----+----+----+ for Procomm v2.3. | F7 | F8 | F9 | SF5| +----+----+----+----+ | F4 | F5 | F6 | SF6| +----+----+----+----+ | F1 | F2 | F3 | | +----+----+----+ SF8| | F10 | SF7| | +---------+----+----+ +----+----+----+----+ | F1 | F2 | F3 | F4 | This is the layout of the default VT100 +----+----+----+----+ emulation for MS-Kermit v2.29. | F5 | F6 | F7 | F8 | +----+----+----+----+ | F9 | F10| SF1| SF2| +----+----+----+----+ | SF3| SF4| SF5| | +----+----+----+ SF6| | SF7 | SF8| | +---------+----+----+ +----+----+----+----+ | F1 | F2 | SF1| SF2| This is the layout for PC-VT v8.4. Note +----+----+----+----+ the two keys mapped to the same | F3 | F4 | SF3| SF4| VT100 key in the case of 0 and enter. +----+----+----+----+ | F5 | F6 | SF5| SF6| +----+----+----+----+ | F7 | F8 | SF7| SF8| +----+----+----+ | | F9 F10| SF9|SF10| +---------+----+----+ +----+----+----+----+ | OP | OQ | OR | OS | These are the escape sequences sent out +----+----+----+----+ by these emulations. Read "OP" as | Ow | Ox | Oy | Om | OP. +----+----+----+----+ | Ot | Ou | Ov | Ol | +----+----+----+----+ | Oq | Or | Os | | +----+----+----+ OM | | Op | On | | +---------+----+----+ +----+----+----+----+ | F10| SF1| SF2| SF3| This is the VT100 emulation +----+----+----+----+ defined by PC1:MSKERMIT.INI | F7 | F8 | F9 | SF4| for the University of Michigan's +----+----+----+----+ MTS system. | F4 | F5 | F6 | SF5| +----+----+----+----+ | F1 | F2 | F3 | | +----+----+----+ SF6| | Grey - | SF7| | +---------+----+----+ 1 Show Key for the function keys: +----+----+ +----+----+ +----+----+ +----+----+ | f1 | f2 | | 596| 597| |1118|1119| |2152|2153| +----+----+ +----+----+ +----+----+ +----+----+ | f3 | f4 | | 598| 599| |1120|1121| |2154|2155| +----+----+ +----+----+ +----+----+ +----+----+ | f5 | f6 | | 600| 601| |1122|1123| |2156|2157| +----+----+ +----+----+ +----+----+ +----+----+ | f7 | f8 | | 602| 603| |1124|1125| |2158|2159| +----+----+ +----+----+ +----+----+ +----+----+ | f9 | f10| | 604| 605| |1126|1127| |2160|2161| +----+----+ +----+----+ +----+----+ +----+----+ unshifted shifted with ctrl with alt +----+----+----+----+ +----+----+----+----+ |Home| Up |PgUp|Gry-| | 7 | 8 | 9 |Gry-| +----+----+----+----| +----+----+----+----| |Left| |Rght|Gry+| | 4 | 5 | 6 |Gry+| +----+----+----+----+ +----+----+----+----| | End|Down|PgDn| | | 1 | 2 | 3 | | +----+----+----+----+entr| +----+----+----+----+entr| | Ins | Del | | | 0 | . | | +---------+---------+----+ +---------+---------+----+ cursor pad numeric pad +----+----+----+----+ +----+----+----+----+ | 71 | 72 | 73 | 74 | | 583| 584| 585| 586| +----+----+----+----+ +----+----+----+----+ | 75 | | 77 | 78 | | 587| 588| 589| 590| +----+----+----+----+ +----+----+----+----+ | 79 | 80 | 81 | | | 591| 592| 593| | +----+----+----+----+ 28 | +----+----+----+----+ 540| | 82 | 83 | | | 594 | 595 | | +---------+---------+----+ +---------+---------+----+ unshifted shifted +----+----+----+----+ |1143| |1156| | +----+----+----+----+ |1139| |1140| | +----+----+----+----+ |1141| |1142| | +----+----+----+----+1052| | | | | +---------+---------+----+ with ctrl ------------------------------ Date: Wed, 16 Jul 86 16:17 PDT From: FRIEDMAN%OAVAX.MNET.MFENET@LLL-MFE.ARPA Subject: A Wish List (long) Keywords: MS-DOS Kermit, MS-DOS 2.29 For the last year or so I have been using MS-KERMIT on a PC-XT to connect to a variety of computers. These include the CRAYs here at NMFECC and the local VAX running VMS. I have been collecting a wish-list, and thought it was time to post it and see if some of the items might be added to the "official" list in the BWR file. Here goes: 1) Any new text coming from the host or typed by the user should appear at the end of the last screenful, not at the cursor location. Operator messages from the host, as well as messages from programs I am running, often obscure critical text on the screen while I am examing something I did five minutes earlier. 2) Seven pages (or so) of screen memory is nowhere near enough. I'd like to be able to use as much memory as I want, (say) 30 pages of screen memory. Better still would be an "infinitely" long memory, with simultaneous storage into a disk file that would serve as both a log and the top half of the screen memory. This might also allow you to view the screen memory of your last session simply by paging back during the current session. The present log is awkward since a) it isn't available online, and b) it contains a lot of control characters from backspacing over typing errors, and from screen editing sessions on the VAX when I forget to turn off the logging. 3) Printing and dumping. It would be nice if one could somehow "mark" a section of the screen memory and either print it or save it to a file. 4) The CRAYs do not respond to input characters until the carriage return is pressed (this is also true of many computers accessed through networks). Thus, screen editing is impossible without use of a "co-editing" program which runs on the PC and the CRAY simultaneously. It might be a good project to develop standards for such a system. NMFECC and LCC both support a system called SED which seems to work well. 5) Again because of the above characteristic, editing of input lines is limited to backspacing. A true line-editing capability (as on the VAX, or in the DOS supplement/shareware program CED) could be incorporated into the terminal emulator. This is the natural place for such a capability, since the line could be echoed locally, edited, then sent when the return key was pressed. 6) A related wish is command-line recall, either VMS/CED-style (press a key repeatedly and old command lines reappear in reverse order) or by highlighting text in the screen memory somehow, then bringing the line into the current command buffer for editing by pressing a key, then sending it with a return. On our system, linefeed characters echo as exclamation points, and so a facility for translating exclamation points into linefeeds (and echoing linefeeds as !'s during local pre- transmission editing) would be useful - of course, the mapping should be general enough to support a variety of host computer idiosyncrasies. 7) When I assign a character string to a key, then press the key, often the characters appear too rapidly for our CRAY terminal concentrator to accept them. It would be useful if the speed with which character strings were sent to the host could be selected by the user. Since when I talk to the VAX I press the arrow keys a lot, and these send three-character sequences, I'd like these to be sent at full speed - so some means of specifying the "speed of paste" when each key is defined would be best. (Also, it would be nice if the interactive key definition procedure were streamlined so that the user need only press the key they wished to define - why do we need to know the scan code?). 8) It would be nice to have a "bare bones" mode that used DOS for the keyboard handling. My text editor has a facility whereby one can start a command processor, and use the editor commands to paste old lines, etc. Thus, one gets command line recall and a log when running compilers on the pc. It would be nice if I could run codes on the CRAY this way. Also, I have some questions about what happens when one is not in connect mode and a message comes in over the serial port from the mainframe. When I am at Kermit command level after a ctrl-]c, then I reconnect, data is missing from the screen (if I had been listing my files, the list would be garbled). I have had better luck with ctrl-]p. What I'd really like is a full explanation of what happens - for example, does the disk actually run in a background mode to update the log when an interrupt comes in over the port? Finally, I expect that some of the above wishes might be answered by use of either a) a windowing program, b) a mouse with appropriate driver for cut-and-paste, or c) a keyboard enhancer program, and wonder if anyone has learned any useful tricks. I use SIDEKICK all the time with MS-KERMIT, and find it useful to paste frequently used lines from the notepad; SIDEKICK allows the user to control the speed of pasting, and so I avoid the problem alluded to in (7) above. In general, I'm very pleased with MS-KERMIT; I would appreciate any comments on these ideas from either the KERMIT developers or the user community. Comments can be posted if of general interest; other- wise I can be reached at: friedman%llv@lll-mfe.arpa or some such thing depending on the syntax of your local mail utility; Im on the LLV VAX on the MFENET at Lawrence Livermore National Laboratory. ------------------------------ Date: 16 JUL 86 21:47-MDT From: JRD@USU Subject: RE: Wish List Keywords: MS-DOS Kermit, MS-DOS 2.29 Mr. Friedman (friedman%llv@lll-mfe.arpa), Your long "wish list" arrived in the mail from Columbia and, since I have been doing much of the MS Kermit development recently, perhaps I can comment on some of the points. As I understand things, the bulk of the wishes are closely related to offsetting deficiencies of the mainframe host, full editing facilities in particular. Point 1: While in connect mode incoming text should be placed at the end of previously received text rather than at the cursor position (if the screen has been rolled back manually). True, but. This would require a healthy amount of screen and memory management code and employment of multiple pages of video memory (on what kind of display adapter?) to avoid massive flickering between old and new screens. And, think about what must be done if the regular screen scrolls up. Just telling the host Xoff can work wonders most of the time; exiting connect mode, selecting port 2, and returning to connect mode will also preserve the old screen (but will lose new incoming text from port 1). Point 2: Five screens of roll back are too few, 30..inf would be much nicer. Again, these things can be done, at a stiff price in both runtime code space and programmer effort. An easy work around is to make a hard copy listing as you go (Control PrtSc does the trick). Micros are spoiling us. Point 3: Selectively edit a screen for dumping to a printer. See below. Modern full screen editors on micros have many of the characteristics you wish. They cost $200+ when Sold in large quantities and they just edit. Some serious duty editors of this kind are Brief, Emacs, Epsilon, and Kedit. For capturing program output to a window have a look at Epsilon by Lugaru; I'm using Brief. Some day, "real soon now", mainframe editors will catch up, but at a very hefty price in i/o channel facilities (38 Kbaud+) and scads of real memory for buffers, etc. My students have remarked to me that because I have pronounced ideas on what editors should do then why not write my own. Yes, certainly, but what about all the other interesting things to do? Point 4: Cray editors are line oriented rather than full screen types. Yep! Only Real Programmers use Crays and RPs are happy with card images and patching binaries; I was & did. Try a copy of Emacs. By the way, why are you burning up Cray time doing editing? Don't you fellows at LLL work into a mere-computer front end to handle i/o, scheduling, and other routine chores? (Must be the SDI money.) Point 5: Line editing Helpful Utilities. These still work under Kermit! Mouse menus can be very useful for classes of minor tasks, and Kermit loves the little fellows. Microsoft supplies a very good menu program with their mouse; I have both. Point 6: Command line recall buffer and translation of strange input chars. Kermit already has too many buffers and the command parser is Byzantine trying to do the present command line editing (in system independent fashion). Limited translation is being considered, particularly for European characters. Point 7. Pace sent characters. Either lower the baud rate or have the troops get a concentrator with typeahead buffering. If we were to pace characters then most of the other users would hit the overhead. Also, key redefinition could be much smoother. Sure could, and we are thinking about doing so when time is available; it will not replace Prokey et al. Also, how do you get file transfer packets through a slow concentrator? Point 8: Bare bones keyboard handling (let DOS do it). MS Kermit obtains keyboard info by both DOS calls and Bios calls; it does not go to the keyboard hardware and the like. It is about as bare bones as possible. If you were to use a fancy console handler which passes along scan codes properly then it probably would be compatible with Kermit. Most such utilities do not do so yet. Question: What's with the serial port? Kermit returns the serial port to its original owner when Kermit does not have direct need of it, such as between file transfers. That is a very good safety feature for a program which uses interrupts for reception. As you may notice, between file transfers or Connect sessions there is no implied source/sink for serial port information; thus, Kermit is unaware of the port at such times. If the port were left active then Kermit would have to be prevented from accessing conflicting programs or letting the user Push to DOS, etc just to keep the interrupts from calling a perhaps non- existant interrupt routine (a disaster) or having a buffer overflow. When DOS grows up to be a multi-tasking o/s then we can consider letting Kermit run in the background; WINDOWS/DOS 5.0 does not seem to be there yet. I also run DECnet-DOS on my micro, and it tries to permanently install itself as an extension of DOS plus "own" the serial port most of the time. It runs the port in the background and messes with DOS in a very serious way. Comment added by me. Kermit as a whole is written and improved by volunteers, using an enormous number of man hours, and we earn exactly zero for doing so. Thus, features get added when someone decides to do them (best to let Columbia know first since others may be doing the same thing). Many of the items on your wish list fall into the very sophisticated technique department. Fortunately for all of us, many of the Kermit contributors are adept at such matters, when they have the time. Suggestions such as yours provide a rich menu of interesting things to consider. Like to have a go at one or two? And not least, thanks for the nice words about the existing Kermit; they help. Regards, Joe D. ------------------------------ End of Info-Kermit Digest ************************* ------- 22-Jul-86 16:21:49-EDT,17314;000000000001 Mail-From: SY.FDC created at 22-Jul-86 16:20:13 Date: Tue 22 Jul 86 16:20:13-EDT From: Frank da Cruz Subject: Info-Kermit Digest V5 #3 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12224783286.155.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Tue, 22 Jul 1986 Volume 5 : Number 3 Today's Topics: New Kermit for the Commodore Amiga HP1000 Kermit Bug in MS-DOS Kermit 2.29 Sanyo Kermit BOO File Problems Extra-Long Packets Specification Some Thoughts about Long Packets in Kermit CMS Kermit Problem ---------------------------------------------------------------------- Date: Mon 21 Jul 86 17:31:29-EDT From: Frank da Cruz Subject: New Kermit for the Commodore Amiga Keywords: Amiga, Commodore Amiga, C-Kermit This new version of Kermit for the Commodore Amiga is based on the current C-Kermit release, 4D(060), and has been sent in by Jack Rouse of SAS Institute (Cary, NC). It replaces (by mutual agreement) the Amiga Kermit previously submitted by Davide Cervone of the University of Rochester. The CKI*.* files have been replaced, except for the bootstrapping files, which remain where they were. Also, several of the system-independent C-Kermit modules have been restored to their original condition (the previous Amiga Kermit release altered them to include "printf2" and "printf3" functions; these are no longer needed). The new release includes help, documentation, beware, and "boo" files, along with source. The files are in KER:CKI*.* on CU20B, plus (if you want to build from source) the other C-Kermit source files (CKU*.C, CKU*.H, CKC*.C, CKC*.H, CKWART.*, CKCPRO.W). The files are also available on BITNET from KERMSRV at CUVMA. For those who cannot get at these files over the networks, or who have trouble with the bootstrapping procedure, Jack will send an Amiga diskette including source and executable program if you send him a check for $6.00: Jack Rouse 106 Rubin Ct., Apt. A-4 Cary, NC 27511 The CKI*.* files from the previous Amiga Kermit are still available on CU20B as KO:CKI*.*. Jack is also working on an adaptation of C-Kermit to Apollo Aegis. This will be announced when it is received. ------------------------------ Date: 17 Jul 86 17:20 +0200 From: W._Michael_Terenyi%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: HP1000 Kermit Keywords: HP1000 Kermit For a long time I have tried to install Kermit on every machine in our company's multivendor computer hardware environment. The biggest problems arose with the HP1000 (RTE-6/VM) we still have, but finally I could solve them mostly. The Fortran-Kermit (HPM* files) you distribute contains some bugs, but we could get it running with an HP150-Kermit, but not with VAX- or DEC20-Kermit. For a long time we had to use the HP150-Kermit (with debug mode enabled) as an intermediate for transfers to other hosts. Not good, but better than nothing. When the Pascal-Kermit (HPA* files) arrived, we hoped to get it working, because the Pascal-Compiler is identical on RTE-6/VM and RTE-A. But we ran into big troubles, and as a regular reader of Kermit Info Digest I wonder that nobody has complained about this Kermit version. These were the main problems: 1. Two source files are missing (PASCAL.PAS, VMAST.PEX). 2. A compiler directive (STANDARD_LEVEL HP1000) is missing in some modules, causing lots of compilation errors. 3. The revision number of the Pascal compiler has to be 2440 (or later) and not 2401 as stated in the instructions. We did a lot of investigations to find this, but after adding the correct compiler directive and installing a new version of the Pascal compiler, we gave up, because of the missing source files. They contain only procedure headers, and backtracing from the compilation errors it is possible to write them again. But we did not want to put so much work in it. I also tried to phone the author of this Kermit, but he went off in his holidays for 4 weeks just half an hour before I called him, and nobody else was there to help me. But finally everything turned into happiness, when I received a new Fortran version of Kermit distributed at an HP1000 conference in Washington (DC). I could compile and link it without any problems and it worked instantly. Later I discovered a bug concerning the time-out setting of the terminal port, but this was obvious and easy to correct. This Kermit version supports remote and local (very difficult on a half-duplex machine!) operation as well as server mode. And, best of all, this Kermit runs on RTE-6/VM and RTE-A as well, the type and revision(!) of the operating system is selectable by parameters. I suggest, that this Kermit version should replace both the HPM* and HPA* files in the official Kermit distribution. I am sure that the author will give you the most recent version of this Kermit (which I do not have, yet) if you contact him: Paul Schuman E-Systems, Inc., Greenville Division P.O. Box 1056 CBN 101 Greenville, Texas 75401 Phone (214) 457-5358 Telex 701511 mfogvl ud In the meantime we got MS-Kermit 2.29 on our ATs, and we discovered that the HP1000-Kermit does not like it (file transfer with version 2.27 works perfectly). We have found out, that the 2.29-Kermit precedes every packet with XON or binary zero depending on the setting of the flow control, and the HP1000-Kermit seems to have a bug in its packet parsing routine. Maybe this is already corrected in the next release, which I will receive in October presumably, but is now available from Paul Schuman as said above. Best regards, Michael. Real Name: Wolfgang Michael Terenyi MAILNET: W._Michael_Terenyi_(SANDOZ)@QZCOM.MAILNET ARPA/CSNET: W._Michael_Terenyi_(SANDOZ)%QZCOM.MAILNET@MIT-MULTICS.ARPA JANET: W._Michael_Terenyi_(SANDOZ)%QZCOM@UK.AC.YORK.KL G3 Fax: +43 222 867018 Telex: 132287 sfi a Real Address: SANDOZ Research Institute Brunner Str. 59 A-1235 Vienna Austria, Europe [Ed. - Many thanks for the information. We have written to Paul Schuman and asked him to send it in. It will be announced when (if?) it arrives. Also thanks for describing the MS-DOS Kermit problem so succinctly (see below).] ------------------------------ Date: Fri 18 Jul 86 11:22:05-EDT From: Frank da Cruz Subject: Bug in MS-DOS Kermit 2.29 Keywords: MS-DOS Kermit, IBM Mainframe, HP1000, Harris The new MS-DOS Kermit has a serious problem when used with certain kinds of host computers, including IBM mainframes, HP-1000's, and Harris minis. The symptom is that file transfer doesn't work -- either at all, or else rarely. The cause is that when flow-control is set to NONE, then Kermit erroneously precedes each packet with a NUL (ASCII 0) byte. Most hosts are immune to NULs on the communication line, but an IBM mainframe with VM/CMS will discard all following characters up to the break character (CR), in Kermit's case the entire packet. On the Harris, a NUL reportedly kills the entire Kermit process. See the previous message for what happens on the HP-1000. A patch is available for those who are affected by this problem. Since it is rather long, it has been added to the end of the "beware file". This file is available as KER:MSKERM.BWR on CU20B (via anonymous FTP on the Internet) or MSKERM BWR on CUVMA (via KERMSRV on BITNET). An updated release of MS-DOS Kermit containing fixes for this and all the other reported problems, plus a few surprises, should be available in late summer or early autumn. In the meantime, source-level patches will continue to be listed in the beware file. ------------------------------ Date: 1986 Jul 21 19:43 EST From: Bob Babcock Subject: Sanyo Kermit Keywords: Sanyo MBC Kermit The Sanyo release of kermit version 2.29 has a bug which locks it at 300 baud. I got a copy of the sources over KERMSRV and fixed the problem. I will send you the revised MSXMBC.ASM shortly. I also got copies of the IBM specific routines and created a Sanyo version with essentially all of the IBM features. This version requires an optional video board which only some machines have. (The board was produced by Sanyo to make the MBC series sufficiently IBM compatible to run Lotus 123.) I have a couple little things which I may work on before sending the sources off. I have named the Sanyo specific routines MSX55X.ASM, MSY55X.ASM and MSZ55X.ASM, but you can change that if you prefer. Because of the video board requirement, these do not replace MSXMBC. [Ed. - Thanks. The names are fine, though it would be preferable if the two Sanyo versions could be combined into one, which could tell at runtime whether the option board was present. The new stuff will be announced when it arrives.] ------------------------------ Date: Mon, 21 Jul 86 21:07:57 EDT From: "Roger Fajman" Subject: BOO File Problems Keywords: BOO File, Bootstrapping, MS-DOS Kermit, KERMSRV, EBCDIC I figured out some problems that I encountered with BOO files and the IBM PC. There were two: (1) If you use the PUNCH command of KERMSRV@CUVMA on BITNET, the file comes with trailing blanks, which will cause the EXE file generated to be incorrect. The BOO format doesn't use blanks, so trailing blanks can be safely stripped before the file is processed. However, MSBPCT.BAS does not do this, so you had better. [Ed. - The MSBPCB and MSBPCT programs should indeed strip trailing blanks.] (2) When getting BOO files through BITNET, take care with your EBCDIC-ASCII translations. Ours is the same as Columbia's, except for curly braces. Most BOO files don't have curly braces, but MSBPCT.BOO (the C version of the IBM PC BOO file decoder) does have a curly brace in it that represents a count of NULs. BOO files don't contain any kind of internal consistency check, such as a byte count and/or checksum, so problems such as these just give you EXE files that don't work. [Ed. - It would have been nice to include consistency checks in .BOO files, but since checksums or CRCs are based on the numeric, internal representation of the characters, you get into trouble when going between ASCII and EBCDIC systems. Actually, when you use the MSBOOT.FOR/MSBPCB.BAS pair, there is a minimal kind of consistency check -- the length of each line is transmitted along with the line by MSBOOT and checked by MSBPCB. But you're right, you don't even get this with the MSBPCT programs. That's why the recommended technique is to use these bootstrapping programs to get a Kermit program that SEEMS to work onto your PC, and then use that Kermit program to get another copy of itself, with error checking, etc.] ------------------------------ Date: Sat, 19 Jul 86 23:44:48 edt From: roy@phri.UUCP (Roy Smith) Subject: Re: Extra-Long Packets Specification Keywords: Long Packets > The first question some people ask when they learn of these of these [sic] [Ed. - oops] > devices [error correcting modems] is whether their error-correcting > capability has made Kermit obsolete. The answer is an emphatic no [...] I know this list is for discussing Kermit, but I couldn't help noticing that exactly the same question is asked about uucp. Time and time again I've seen people suggest that all the overhead of computing checksums that uucp does could be eliminated if only you had error correcting modems. Come to think of it, I've seen it asserted more than once that you don't really need TCP/IP on an ethernet, since you don't have to worry about mangled packets. Will people never learn? As it happens, while I was typing in the first paragraph of this message, a bunch of "/usr: file system full" messages popped up on my screen. Kermit, uucp, and ftp (and presumably Decnet, Appletalk, Xmodem, and so forth) all deal with full file systems in some rational way. Error correcting modems do not. It doesn't do you much good to move the bits from here to there if they just get dropped on the floor at the other end without any warning. Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ------------------------------ Date: Sat, 19 Jul 86 01:18:10 edt From: zeeff%b-tech.uucp%umich.csnet@CSNET-RELAY.ARPA Subject: Some Thoughts about Long Packets in Kermit Keywords: Long Packets, Sliding Windows I see a potential problem with long packets - just because two kermits have the capability, it might not make sense to use it. They may be connected together by a regular modem. You can have some user selectable option, but the less the user has to know about the lower levels, the better (getting all the options set correctly can be difficult now). One solution might to use adaptive packet sizing. They could start small, and rapidly grow larger as it is determined that the link is error free. Another nice feature (which I'm sure has been mentioned before) would be packet stacking and built in compression. It might soon become difficult to determine where to do some of these things - in kermit or in the modem. - Jon Zeeff ihnp4!umich!umix!b-tech!zeeff Jon_Zeeff@UMich-MTS.MAILNET [Ed. - Well... There is also a packet-stacking extension to Kermit (called "sliding windows"), which is independent of, and not mutually exclusive with, long packets. However, sliding windows (a) require full duplex communication, and (b) are complex to program. Any particular implementation will depend on peculariarities of the system -- interrupts, multiprocessing, etc -- in order to achieve full duplex transmission. Long packets are the best way to boost performance in a half duplex connection (and many of these new modems are half duplex), but you're right: long packets should not be sprung on the user by default. The user should know the necessary preconditions -- a very clean connection, large input buffers at the receiving end, and effective, reliable end-to-end flow control.] ------------------------------ Date: 1986 Jul 21 19:43 EST From: Bob Babcock Subject: CMS Kermit Problem Keywords: CMS Kermit I have always found it difficult to run Kermit talking to an IBM mainframe running CMS over a straight ascii line. The problem is that line noise during a file transfer tends to interrupt the Kermit process and pop you into CP. To resume execution of Kermit, you need to send a BEGIN command (b is enough). But you can't do this without aborting the transfer at the local Kermit, assuming that it hasn't already timed out before you noticed the problem. This problem does not arise if Kermit is run over a series/1 interface or equivalent, but the IBM mainframe which is our link to BITNET does not have series/1 software which would allow Kermit to run. I have thought about modifying Kermit at different levels, either allowing the user to hit a key and transmit a B, or making Kermit smart enough to recognize the problem and automatically send the begin command. Do you know if anyone else has attacked this problem? I don't want to reinvent the wheel. I should emphasize that this is not a problem with the CMS Kermit, but rather is a characteristic of the environment it runs in. [Ed. - This is only a specific instance of a common problem: what should the local Kermit do when the remote Kermit "goes away" during file transfer? When the remote Kermit goes away, you're confronted by some aspect of the underlying system, or in some cases nothing at all. The possibilities are simply too numerous to be accounted for in the Kermit protocol, or any protocol that attempts to span a large number of systems. You shouldn't have to embody specific knowledge about a particular remote system in another system's Kermit program -- if you did, where would it end? The best that can be done is what is currently done: if a packet does not elicit the expected reply, try again, up to the retry limit, and then give up, but also allow for manual intervention. In the case of MS-DOS Kermit, you can type Ctrl-C at any time during the file transfer to get back to Kermit-MS> command level instantly, so that you can CONNECT and do whatever you can to clean up. Unfortunately, there's no way to tell the local Kermit to resume the file transfer where it left off. CMS is a special case. Luckily, there's a special solution. Version 3 of CMS Kermit (due for release Any Day Now, will put the line into a special mode so that any characters at all that appear to CP will continue the program, that is, will do what "begin" would have done.] ------------------------------ End of Info-Kermit Digest ************************* ------- 25-Jul-86 13:24:02-EDT,20572;000000000000 Mail-From: SY.FDC created at 25-Jul-86 13:22:50 Date: Fri 25 Jul 86 13:22:50-EDT From: Frank da Cruz Subject: Info-Kermit Digest V5 #4 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12225537425.141.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Fri, 25 Jul 1986 Volume 5 : Number 4 Today's topics: IBM PC Kermit 2.29 on Diskette in the UK Another BASICA Program to DeBOO Kermit Files Kermit-11, Kermit-32 and Wildcard Send HP1000 Kermit Saga, cont'd, and MS-Kermit Filespec Parsing Kermit with Other Terminal Emulators Emulation Wish Protocol Manual Potential Changes Multics Kermit Dialout? MS Kermit for Epson QX-16? Kermit with Internal Hayes Modem on the Leading Edge D? Kermit for General Automation-type Equipment? More on BOO Files Problem with Atari UU-encoded Files ---------------------------------------------------------------------- Date: 22-JUL-1986 11:31:21 From: Alan Phillips Subject: IBM PC Kermit 2.29 on Diskette in the UK Lancaster University Kermit distribution can now supply the complete set of files for MS-Kermit 2.29 on the IBM PC on diskette. Those interested can contact me at: Kermit Distribution, Department of Computing, Computer Building, Lancaster University, Lancaster LA1 4YW UK or phone (UK) 0524-65201 x 4881 Diskette supply is offered in the UK and Eire only, and we can't return calls to other countries. We have a complete set of Kermit files for all current implementations on a VAX system, and these can be accessed by anyone who can connect to us, from anywhere. Those wanting details, or who wish to receive the UK Kermit newsletter, should mail me as SYSKERMIT @ UK.AC.LANCS.VAX1 (JANET) SYSKERMIT @ UK.AC.LANCS.VAX1 (BITNET) SYSKERMIT%LANCS.VAX1 @ UK.AC.UCL.CS (ARPA) SYSKERMIT%LANCS.VAX1 @ UKC (UUCP - UK *only*) [Ed. - Many thanks for providing this service, Alan, and for all the work you've done in promoting and distributing Kermit in the UK!] ------------------------------ Date: Thu, 15 May 86 23:24 EDT From: Alan H. Holland Subject: Another BASICA Program to DeBOO Kermit Files Enclosed is a BASICA program developed from MSBPCT.BAS that takes 45% to 60% of the time that MSBPCT.BAS would take. For lack of a better name, I have been calling it MSBPCT2.BAS. The following comparative times (in min:sec) were done on an IBM PC XT using PC-DOS 2.1 and IBM BASICA 2.0. In CONFIG.SYS, BUFFERS=8. Input File Input Length Type of Disk Used MSBPCT MSBPCT2 ------------ ------------ ----------------- ------ ------- MSKERMIT.BOO 47,701 10 MB hard disk 22:45 10:27 (ver. 2.27) MSJRD5G.BOO 59,394 10 MB hard disk 22:38 12:28 MSJRD5G.BOO 59,394 360 KB floppy 24:09 13:50 [Ed. - Thanks! The program has been added to the Kermit distribution as MSBPCT.BAA (the old one is still MSBPCT.BAS; our filenames have to be unique within the 6.3 paradigm...)] ------------------------------ Date: 22-JUL-1986 11:44 From: PENNICK@UK.AC.AFRC.AGRI Via: SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk Subject: Kermit-11, Kermit-32 and Wildcard Send Users of Kermit-11(V3.51) under RSX-11M and Kermit-32(V3.1.066 ) under VMS 4.2 may be interested to note the different ways in which these two kermits treat file version numbers. If you wildcard send multiple generations from the PDP-11 they arrive with the same version numbers as they left with. However if you wildcard send them back the VAX sends the latest version first, thus reversing the generation numbers... Purge then becomes a very dangerous command.. Cheers Jonathan Pennick Animal and Grassland Research Inst. ------------------------------ Date: Wed, 23 Jul 86 10:10 EST From: (brian nelson) Subject: Re: Kermit-11, Kermit-32 and Wildcard Send Kermit-11 always strips the filename down to NAME.TYPE before sending the name over in the F packet. Perhaps a possible alternative would be to allow different levels of filename processing, such as a set command to (1) Remove all but NAME.TYPE (2) To allow the version number, (3) To allow transmission of the UIC or directory, and (4) To allow retention of the device name. I am not suggested the actual syntax as I would like to see Kermit maintain some sort of common command syntax. It would be quite undesirable to default to anything other than FILE.TYPE as many other Kermits would reject a name that included a version field. Lastly, if the version number is sent, then what about collision on the version number? [Ed. - The whole business of filename transmission is quite a stumper. If we could characterize file specifications on every possible system in some canonic syntax to include every possible field (device, directory or path, name, type, version, attributes, etc etc), then maybe we could have some kind of format specification to say just which fields to transmit, how to fill in defaults for missing fields, etc., plus a selector to tell whether these fields, once selected, should be translated to canonic form for transmission, or transmitted literally (e.g. between like systems)...] ------------------------------ Date: 21 Jul 86 17:39 +0200 From: W._Michael_Terenyi%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: HP1000 Kermit Saga, cont'd, and MS-Kermit Filespec Parsing We found the bug in the packet parsing routine of HP1000-Kermit in the meantime; it works now with MS-Kermit V2.29 perfectly. The old HP1000 file system allows file names starting with ? (question mark). If you put the HP1000-Kermit in server mode, you cannot transfer such files, because if you type GET ? on your PC AT, the help feature is immediately invoked. Is there an easy way to disable the recognition of question mark for help ? [Ed. - MS-DOS Kermit always wants to give help if you type a question mark. Since question marks can be legitimate parts of file specifications (either as a wildcard character, or as an actual part of the name), the following compromise was made in the Kermit-MS command parser: If you type a question mark as the first character in a filespec field, you get help, but if you type it in a subsequent field, it is taken literally as part of the filespec. To enter a question mark as the first character of a filespec, type a pound (sharp) sign (#) instead. Meanwhile, I'm sure everyone with HP-1000's is waiting anxiously for this new Kermit program...] ------------------------------ Date: Tue, 22 Jul 86 23:57 -0200 From: Jonathan Scott Subject: KERMIT with Other Terminal Emulators I thought KERMIT was a file transfer protocol until I met KERMIT-MS V2.29 which is obviously a sophisticated terminal emulator but also happens to have KERMIT file transfer capability. It's great, but it doesn't quite do everything I want. I already have a terminal emulator which does... except that it doesn't support KERMIT file transfer. The terminal emulator which I normally use has features which I don't want to give up, including graphics and automatic mode switching between full screen mode and line by line mode when running with an IBM 7171. It's a big problem switching over to KERMIT in the middle of a session because my normal emulator is like a DM1520 Elite (for high performance because all the control codes are 1 byte) but KERMIT emulates VT10x-type terminals and I can't even enter the command to start the host KERMIT through the KERMIT terminal emulator. What I would like to see is a separate KERMIT file transfer facility which can be used together with any other terminal emulator for a PC. I think it would be best to have a "hot key" type switch between the terminal emulator and KERMIT. It might not be easy, but I think it would be more helpful than any number of special new features in the KERMIT terminal emulator, and file transfer is after all the primary purpose of KERMIT. The terminal emulator in KERMIT V2.29 is a very nice product and should obviously continue to be developed, but terminal emulation is a tricky area and it is very difficult to satisfy everyone (I know because I wrote one a couple of years ago "sufficient for all our current needs" which has resulted in a continuous barrage of enhancement requests ever since). What I want from KERMIT is a reliable file transfer system without side-effects, integrated as neatly as possible into my existing work environment - then it would really be worth the money we don't have to pay for it... Has anyone done any work in this area before? Does this seem feasible? Jonathan Scott (Gothenburg Universities Computing Centre, Sweden) [Ed. - A standalone Kermit file transfer program is not a bad idea, but when you separate your terminal program from your file transfer program, you have to waste a lot of time feeding them BOTH the same set of communication parameters. Particularly tedious if you switch between different hosts a lot.] ------------------------------ Date: Tue, 22 Jul 86 13:47:46 cdt From: dsandrsn@uxe.CSO.UIUC.EDU (David Sanderson) Subject: Emulation Wish A good way to provide emulation of nearly any terminal would be to build an emulator into KERMIT that would configure itself from an entry in a termcap-style file. What tools exist that might make this addition easier for micro versions, like MS-KERMIT? Would performance necessarily suffer? David Sanderson Illinois State Geological Survey true UUCP: ...uiucdcs!uiucuxa!uiucuxe!dsandrsn (before 15 Aug.) ...wucs!wucec1!dws3014 (after 15 Aug.) [Ed. - Ron Fowler once attempted a CP/M Kermit implementation that would do this, but he either gave up or lost interest. Since then, nobody has picked up the cudgel. In principle it's a great idea. At compile time, the program only needs to know a bunch of symbols ("cleol" for "clear to end of line", etc) and program functions associated with each symbol. These functions could be filled in in a system-dependent way for each system (IBM PC, Macintosh, etc). Then at runtime, the program reads a termcap file entry for the desired terminal type (ADM3A, Concept-100, VT-102, DM2500, etc) to learn the escape sequences associated with each symbol, plus some global parameters like whether cursor addressing is 1- or 0-based, etc. In practice, however, writing the code could be quite a chore...] ------------------------------ Date: Wed 23 Jul 86 18:13:17-PDT From: Bob Larson Subject: Protocol Manual Potential Changes When using long packets and sliding windows together, the suggestion of reducing the packet size (long packets section) cannot be done if a later packet has been sent. (Unless some further protocol extention is done.) There are also a couple of problems in the attributes system/os field: Prime/Primos is listed both as G and M4. Tandy (J) should probably be subdivided, TRSDOS and Disk Extended Color Basic versions of Tandy specific Kermit exist. (Tandy seems to be migrating away from proprietary os's, they supply Xenix, MS-DOS and Os9.) The assignment of these seems to be quite random, UNIX and Os9 have one listing each, while cpm has 4. The delimiter may be listed in both the type and format attribute packet if the type is A. It should probablby only be in the format. Encoding should have a compress 4.0 type (bits in the range 12-16 may also need to be listed.) Shouldn't the "1-@ (ascii 49)" be "1 (ascii 49)"? [Ed. - Thanks...] ------------------------------ Date: Wed, 23 Jul 86 13:35 MST From: CMRoe@HIS-PHOENIX-MULTICS.ARPA Subject: Multics Kermit Dialout? I'm having a real problem using Multics as a local system when dialing out to just about anything, but most importantly to VMS systems. Kermit works fine when dialing out of VMS, but refused to work the other way round. The procedure is fairly simple, dial_out of multics to the VMS system over a direct line, set up kermit on VMS in server mode. Escape back to Multics with dial_out escape character and execute the Multics Kermit.After issuing the command "GET" or "SEND", the Multics kermit will timeout everytime. You can't get back to the VMS system until you quit the Multics kermit. An alternate method was to dial_out to VMS, get kermit up, and set the timeout period to be 60 seconds. You would then issue the Send or receive commands and escape back to Multics, get kermit running and set it to receive or send before the VMS side timed out. This gave a 'fatal error on remote'. All of the parameters are set correctly. ie) sop, eop, packet_length, parity, etc. If anyone has had this problem or heard of it a clue would be greatly appreciated. Cameron Roe University of Calgary Roe@UNCAMULT.MAILNET [Ed. - I understand there are several different versions of Multics Kermit out there, of which Columbia has only one (the original from Oakland Univ). Maybe some versions work better than others in this, and other, respects. Can anyone shed any light?] ------------------------------ Date: 24 Jul 1986 0906-EDT From: Don Bach, Sysop, FIDO 18/13 Via: LCG.KERMIT@MARLBORO.DEC.COM> Subject: MS Kermit for Epson QX-16? I've installed the MSVCLO on my Epson. It works ok, but is a tad slow and whenever I return to the Kermit-MS prompt, the baud gets reset to 1800. Is anyone working on a version for the Epson QX-16? Don Bach P.O. Box 631 Vicksburg, MS 39180 (601)634-3163 [Ed. - Not that I know about. Anyone else? The 1800 baud bug occurs on other systems, too, so it's probably a problem with the code itself.] ------------------------------ Date: 24 Jul 1986 21:23-EDT Subject: Kermit with Internal Hayes Modem on the Leading Edge D? From: Charles Davis A colleague is having difficulty getting MSKERMIT V2.29 to talk to an internal Hayes modem on his Leading Edge D machine. Are there special configuration steps he needs to follow to make this work? [Ed. - There are some problems with the Hayes 1200b even on real IBM systems; there will be some fixes in the next release. The only way to know if these fixes will also work for the Leading Edge is to try them out.] ------------------------------ Date: Thu, 24 Jul 1986 18:26 PDT From: "Jeffrey Sicherman" Subject: Kermit for General Automation-type Equipment? Though I am still planning (real soon now) to do a Kermit version for the General Automation architecture machines that I work on (Control and MIBS operating systems), I have come across mention of an existing implementation which apparently does not appear in the Kermit listings, possibly because it is part of a commercial package as opposed to a separate program. The manufacturer (or distributor?) is a company called GEI Rechnersysteme GmbH, Aachen, West Germany. Anybody on the other side of the Atlantic know anything about this software and its availability (or anyone on this side for that matter) ? ------------------------------ Date: Wed, 23 Jul 86 12:58:48 EDT From: "Roger Fajman" Subject: More on BOO Files > [Ed. - It would have been nice to include consistency checks in .BOO files, > but since checksums or CRCs are based on the numeric, internal > representation of the characters, you get into trouble when going between > ASCII and EBCDIC systems. Actually, when you use the MSBOOT.FOR/MSBPCB.BAS > pair, there is a minimal kind of consistency check -- the length of each > line is transmitted along with the line by MSBOOT and checked by MSBPCB. > But you're right, you don't even get this with the MSBPCT programs. That's > why the recommended technique is to use these bootstrapping programs to > get a Kermit program that SEEMS to work onto your PC, and then use that > Kermit program to get another copy of itself, with error checking, etc.] I don't understand what you are saying here. If I use KERMSRV@CUVMA to get a copy of a BOO file, say for a new version of MSKERMIT, I must run a program someplace to decode that file into an executable file. Wherever I do that, I am open to possibly not having the BOO file exactly right. It would be helpful if the actual binary executable files were available via KERMSRV. Then BOO files would really not be needed after the first time, at least for those of us who have EBCDIC machines on BITNET. As far as checksums in BOO files are concerned, if they were implemented, they should be based on the original file. This avoids EBCDIC-ASCII translation difficulties in computing the checksum and would usually detect errors that were introduced into the BOO file due to translation problems. Anyway, now that I am aware of the problems, I can watch for them. It did, however, take me a while to figure out what was happening. [Ed. - We've gone through several different encodings for .EXE files, and .BOO files are simply the most recent. All such encodings have their faults. Intel HEX format has too much storage (and transmission) overhead, the BOO files are more compact but not error-checked, and see below about UUENCODE. Is there another encoding in common use that is (a) error checked, (b) compact, and (c) easily decoded? By (c) I mean can you type in a short (1 or 2 page) BASIC program to do the job (this rules out LZW or Huffman compression, I think). Otherwise, maybe we'll add length and checksum fields to .BOO files, along with an internal identifier so the decoding program knows the data is really what it's supposed to be, plus start and end markers, maybe even an ASCII "test pattern" of the entire character set near the beginning to allow the decoder to determine in advance whether any mistranslations have occurred. Some day, we'll get this right...] ------------------------------ Date: 25-JUL-1986 12:21:04 From: SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk Subject: Problem with Atari UU-encoded Files There may be a problem with the AST*.UUE encoded files : I've had a report that the copies I picked up from cu20b over arpa have lost trailing spaces from the ends of some records, resulting in an unusable object file. I don't know whether the spaces got lost on the way to me, or from me to the user here, or whether they aren't on the cu20b files at all, but it sounds like the sort of problem that may affect a lot of people. Perhaps the author could modify the encoding technique slightly to end records only with non-space characters? [Ed. - These files came to us over BITNET, which trimmed the trailing blanks. It's always a bad idea when encoding binary files printably to allow spaces in the encoding. Fortunately, UU-encoded files have lines beginning with a length field, so the right number of spaces can be restored. Below is a little program in my favorite screwball language, SNOBOL, to do this. It must be run on an ASCII system because length fields are ASCII values.] &TRIM = 1 * Look for beginning BEGIN LINE = INPUT :F(NOBEGIN) LINE POS(0) 'begin ' :S(GO):F(BEGIN) NOBEGIN TTY = 'No begin line' :(ERR) GO OUTPUT = LINE * Read encoded lines, get length, pad to that length. LOOP LINE = INPUT :F(DONE) OUTPUT = IDENT(LINE,NULL) :S(LAST) LINE POS(0) LEN(1) . X :F(ERR) &ALPHABET @P X :F(ERR) OUTPUT = RPAD(LINE,(((P - 32) / 3) * 4) + 1) :S(LOOP) * Blank line and 'end' line at end. LAST LINE = INPUT :F(LAST2) OUTPUT = IDENT(LINE,'end') LINE :S(DONE) LAST2 TTY = 'No end line' * Error and regular exit. ERR TTY = 'Fatal error' :(END) DONE TTY = 'Done' END ------------------------------ End of Info-Kermit Digest ************************* ------- 1-Aug-86 12:47:07-EDT,12869;000000000000 Mail-From: SY.CHRISTINE created at 1-Aug-86 12:46:06 Date: Fri 1 Aug 86 12:46:06-EDT From: Christine M Gianone Subject: Info-Kermit Digest V5 #5 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12227365746.194.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Fri, 1 Aug 1986 Volume 5 : Number 5 Today's Topics: The First Kermit Newsletter Available Okstate Downtime Kermit-80 files on PC-format diskettes in the UK Japanese Kermit Manuals KERMIT for Sirius/Victor 9000 under CP/M-86 Two Kermit-MS 2.29 Implementations for the Sanyo 550 Series Re: KERMIT with Other Terminal Emulators CMS Kermit Problem (making it work) .BOO files Using C-Kermit to dialout on a DF112 modem? ---------------------------------------------------------------------- Date: Tue 29 Jul 86 14:41:54-EDT From: Christine M Gianone Subject: The First Kermit Newsletter Available Keywords: Kermit Newsletter The first issue of the (paper) Kermit Newsletter (July 1986, Vol.1 No.1) is currently available. The Newsletter target audience was originally intended to be those who do not have access to our networks and have asked to be informed about new Kermit releases and other Kermit news. Articles in this issue include: MS-DOS Kermit Version 2.29; Kermit Book Published by Digital Press; C-Kermit; The Top Five Kermit Questions; Mac Kermit 0.8(34); Protocol Extensions; VAX/VMS Kermit-32 Version 3.2; Kermit's Early History. Anyone who is interested in obtaining a copy of this and future Kermit Newsletters may do so by sending their postal (not electronic) mailing address to Info-Kermit-Request@CU20B, Kermit@CU20B, or KERMIT@CUVMA. Number 1 will be sent to those who request it this way till our leftover copies run out. ------------------------------ Date: Tue, 29 Jul 86 20:12:34 -0500 From: Mark Vasoll Subject: Okstate Downtime Keywords: Okstate Downtime The system Okstate, (home of the UUCP and Kermit Server Kermit distributions) will be down from August 8th until August 31st while our machine room is being remodeled. The uucpker and kermsrv dialin number will not answer the phone during this period. Watch for the return of uucpker and kermsrv shortly after August 31st. Thanks, Mark Vasoll Department of Computing and Information Sciences Oklahoma State University Internet: vasoll@a.cs.okstate.edu Obsolete: vasoll%okstate.csnet@csnet-relay.arpa UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll [Ed. - Thanks for the information. The return date of UUCP will be announced in the digest.] ------------------------------ Date: 30-JUL-1986 17:18:19 From: SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk Subject: Kermit-80 files on PC-format diskettes in the UK Having had a number of requests lately for it, we've now set things up so we can supply a complete set of the CP/M-80 Kermit files (CP4) on IBM PC MS-DOS format diskettes. Not having any CP/M engines, we can't write diskettes directly in CP/M format: but this at least will let people get the files onto their own territory (and it's easier to move files from your own PC to your CP/M machine than download over a phone line). The service is offered in the UK and Irish Republic only: the address, as before, is Kermit Distribution, Department of Computing, Computer Building, Lancaster University, Lancaster LA1 4YW UK Phone (UK) 0524-65201 x 4881 We hope before long to be able to provide all the IBM PC Kermits (Xenix, QNX and so on) on MS-DOS format discs; and in the longer term we intend to offer all Kermit sources for everything in this way. Alan Phillips [Ed. - Thanks!] ------------------------------ Date: Mon 21 Jul 86 09:20:55 From: ken-ichiro murakami Subject: Japanese Kermit Manuals Keywords: Japanese Kermit Manuals I will give the Japanese Kermit manuals to everyone. The only problem is that I cannot distribute machine readable code. My favorite workstation is STAR Japanese version, and all my document files are in this machine. JSTAR has no way to export files except for FDD, and the number of JSTAR in Japan is also small. That is, every time the manual is ordered, I must print it out and send by mail (not E-mail). However, I'll distribute free manuals as many as possible. Please forward me, when you receive requests for Japanese manuals. I can distribute JSTAR FDD or printed documents. Ken-ichiro Murakami NTT Basic Research Laboratories 3-9-11 Midori-cho, Musashino-shi Tokyo, 180 Japan Telephone : 0422-59-3589 E-mail address : "nttlab!murakami"@Shasta (from ARPA) or murakami@nttlab.ntt.junet (from JUNET) (JUNET is Japanese domestic network.) [Ed. - Thanks to Ken-ichiro Murakami for all the work he put into translating the Kermit User's Guide and the Kermit Protocol Manual and for volunteering to distribute these manuals to others.] ------------------------------ Date: Tue, 29 Jul 86 10:44 MDT From: (Eric Zurcher) Subject: KERMIT for Sirius/Victor 9000 under CP/M-86 Keywords: Sirius/Victor 9000 Kermit, CP/M-86 This note will be followed by slightly modified versions of A86 and H86 files for KERMIT for the Victor 9000/Sirius under CP/M-86. This version is nearly identical to the one I sent to you about 3 weeks ago, and differs only in that the SET PORT command is now implemented, allowing the user to select either serial port "A" or "B" - "A" is the default. I hadn't originally intended bothering to add this feature, but a freak lightning strike knocked out the "A" port on one of the Victors in our department, and it was easier (and cheaper) to implement the SET PORT option than to fix the hardware. Sincerely, Eric Zurcher Dept. of Biology Utah State University Logan, Utah 84322-5305 REHABIV@USU.BITNET [Ed. - Thanks, Eric. The new files are in the Kermit distribution as KER:C86XV9.*.] ------------------------------ Date: Wed, 23-JUL-1986 22:26 EST From: Bob Babcock Subject: Two Kermit-MS 2.29 Implementations for the Sanyo 550 Series Keywords: MS-DOS 2.29, Sanyo 550 Series This is to announce two versions of Kermit 2.29 for the Sanyo 555. One has a fairly simple machine dependent routine MSXMBC.ASM, in particular, it does not have any terminal emulation other than responding properly to some VT-100 escape sequences which the BIOS recognizes. This version will run under DOS 2.11 on any Sanyo MBC-550 or 555 which has a serial port. I haven't tried it under DOS 1.25, but Kermit does check the DOS version, so it ought to work. The other version is derived from the IBM Kermit and includes almost all of its features including emulation of VT-52, VT-102, Heath-19 terminals. This version requires the optional IBM compatible video board. Since DOS 1.25 doesn't support the video board, the question of DOS version doesn't arise for this version. Most of the work in producing these routines was copied from code written by Joe Smiley for version 2.27. Both versions use the standard files: mssdef.h msscmd.asm msscom.asm mssfil.asm mssker.asm mssrcv.asm msssen.asm mssser.asm mssset.asm msster.asm mssfin.asm The simple version has one Sanyo dependent-file: msxmbc.asm The video board version has three Sanyo-dependent files: msx55x.asm msy55x.asm msz55x.asm Bob Babcock Mail stop 63 Smithsonian Astrophysical Observatory 60 Garden Street Cambridge, MA 02138 617-495-7107 FTS 830-7107 Net addresses: PEPMNT@HARVARDA.BITNET PEPAP@CFA1.BITNET [Ed. - The new files are in KER:MS%MBC.* (simple version) and KER:MS%55X.* (video-board/vt100 version), including .BOO files for each (% is the DEC-20 single-character wildcard).] ------------------------------ Date: Sat, 26 Jul 86 11:40 AST From: (Eberhard W. Lisse) Subject: Re: KERMIT with Other Terminal Emulators Keywords: Terminal Emulation Apropos of Jonathan Scott's message on this subject in the Info-Kermit Digest V5 #4... If one needs both Kermit (MS 2.29) and another Terminal program I would try to run the other one from within Kermit. (RUN XYTERM) I do this with a public domaine Tektronix 4010 emulator with no problems at all. That combination works, in fact, better than a commercial product (VTERM from Coefficient Systems) we use here as well, as that one does not leave the keyboard as it is but switches to the US layout which is very different from the one which comes with the IBM PC when bought in Germany. ------------------------------ Date: Wed, 30 Jul 86 14:34 EDT From: CCPHIL@TUCC Subject: CMS Kermit Problem (making it work) Keywords: VM/CMS Kermit, CMS Kermit Bob Babcock mentioned a problem with CMS Kermit putting him into CP mode, where he has to interact with the system by entering a "begin" command to get back into CMS mode. The solution is to enter the command "set run on". This changes your CMS environment in a few . One thing that happens is that a carriage return will return you to CMS mode if you enter CP mode. S most Kermits will time out, and send a NAK packet (which is terminate in a carriage return), then you automatically return to CMS mode where ermi Kermit runs without dropping a stroke. Your default environment must be "set run off". We have used e "set run on" command hen going to CMS from the HP 900 and other hosts at SAS Institute. [Ed. - Version 3.0 of CMS Kermit should return you to CMS mode automatically if you happen to enter CP mode.] ------------------------------ Date: 30-JUL-1986 15:04:20 From: SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk Subject: .BOO files How about using a hybrid Intel-Hex/BOO file format to provide the error checking? If you were to structure a record as : where length and checksum are ASCII hex, and checksum is based on the sum of the byte values after conversion, you'ld add only 5 bytes per record. An EOF record would have a length value of 0, adding 3 bytes to the grand total. I would guess an 8-bit checksum would be enough for anyone's needs, and you'ld have only a 6% or so increase in file size. That would give you the checking needed: for another 2 bytes per record you could add a ASCII hex field after the field, which then gives you an expansion path if you ever do a major change in the structure. The obvious ones here are Type 0 Filename record (including such attributes as you might want, such as "total length of data you should get when you've done") Type 1 Data record Type 2 ASCII test pattern Type $FF EOF Having a specific record type for EOF and FileName would let you concatenate .BOO encodings for multiple files and convert them all in one run of the converter program. And, I suppose, if you used record type values not used in Intel hex, you could produce a universal converter that could do both..... Alan ------------------------------ Date: Thu, 31 Jul 86 14:57:07 edt From: Jeffrey Burgan Subject: Using C-Kermit to dialout on a DF112 modem? Keywords: DF112 Modem I am having problems getting a DF112 modem to work with C-Kermit. When I issue a 'set line /dev/ttyIb' command after the 'set modem df100' command, kermit does not respond with a prompt. It seems it is waiting for carrier detect. Has anyone gotten a DF112 to work dialing out and if so, are there any special switch settings for the modem. Any help would be appreciated. Thanks in advance, Jeffrey Burgan University of Maryland jeff@umbc3.umd.edu [Ed. - It also depends on which version of C-Kermit -- Sys V, 4.2BSD, etc. Sys V has special treatment for modems ("CLOCAL"), which may or may not be consistently implemented on different System-V systems.] ------------------------------ End of Info-Kermit Digest ************************* ------- 8-Sep-86 17:40:31-EDT,15879;000000000000 Mail-From: SY.CHRISTINE created at 8-Sep-86 13:05:07 Date: Mon 8 Sep 86 13:05:07-EDT From: Christine M Gianone Subject: Info-Kermit Digest V5 #6 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12237330682.326.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Mon, 08 Sep 1986 Volume 5 : Number 6 Today's Topics: New Kermit for HP-1000 New Release of Sperry-1100 Kermit New Kermit for Use with Microsoft Windows More Kermit Diskettes Available MSBPCT.ASM Amiga Kermit Initialization Kermit Documentation in French Review of MS Kermit 2.29 vs ProComm 2.3 Kermit on IBM MVS/XA? Suggestions for Fortran Port ---------------------------------------------------------------------- Date: Wed 3 Sep 86 17:23:51-EDT From: Christine M Gianone Subject: New Kermit for HP-1000 Keywords: HP-1000 Kermit This is to announce a new Kermit program for the HP-1000 running either RTE-6 or RTE-A, replacing both of the two earlier HP-1000 programs, as discussed in Info-Kermit V4 #xxx and #yyy. This program was submitted by Paul Schuman of E-Systems, Inc, Greenville, Texas, who has also contributed it to the appropriate HP user groups. The files are in KER:HPM*.*. Binaries (for RTE-A) are in KB:HPM*.*. The old versions have been moved to KO:HP*.*. ------------------------------ Date: Wed 3 Sep 86 17:37:23-EDT From: Christine M Gianone Subject: New Release of Sperry-1100 Kermit Keywords: Sperry This is to announce version 2.5 of Sperry 1100 Kermit from pAaul sTevens at the University of Wisconsin. The changes include conditional assembly to make it easier to port to "standard" Sperry systems, increased maximum record size from 800 to 2000, and error corrections. The source file, in Sperry assembler, is in KER:UNIVAC.ASM. ------------------------------ Date: Sun 10 Aug 86 10:21:58-EDT From: Bill Hall Subject: New Kermit for Use with Microsoft Windows Keywords: Microsoft Windows, MS-DOS Kermit I have developed a simple version of Kermit to run under Microsoft Windows. I will be sending you the files via the mails on a floppy disk for you to try. It is strictly bare bones, but the multitasking aspect is really nice. If you will put it on the system, I will maintain it and develop it further. [Ed. - Thanks Bill! The diskette was received, and the files have been placed in KER:WIN*.* on CU20B. Although this program is bare-bones (no help, only dumb terminal emulation), it runs a lot faster under MS Windows than regular Kermit does, and it has the advantage that it can be run in several windows at once, for instance transferring two files simultaneously, one on COM1 and the other on COM2, all in the background while doing other work in the foreground. The program is written in Microsoft C v4.0 (Windows aware), using the supplemental Windows libraries, the Microsoft Resource Compiler, and LINK4 v5.02. It takes advantage of MS-Windows' built-in comm and screen drivers, and is thus usable on any system that runs Windows. It requires a lot of memory and only runs at speeds up to 2400 baud. It has several typical Windows menus so a mouse is a near necessity. This Kermit program should not be confused with the other "Windows Kermit" for the PC (WKERMIT), which implements windows in the other sense of the word, namely the sliding window transport-level protocol. The executable program is KER:WINKRM.BOO, in Boo-file format, which can be translated to and .EXE file using any of the KER:MSBPCT.* programs. The 8-bit binary .EXE file is available in KB:WINKRM.EXE, for those sites that can transfer such files directly from CU20B.] ------------------------------ Date: Sun, 17 Aug 86 17:06:41 pdt From: Randy Spencer Subject: More Kermit Diskettes Available Keywords: Kermit Diskettes This is a copy of the letter I sent out to net.micro.amiga. I am sending it to you because I just noticed the file AADISK.HLP on CU20B and would like to be included... I am willing to send you a copy of Kermit for the IBM, C64, or the Amiga. These are the most recent versions available from Columbia. Send me $6.00 and your mailing address to: Randy Spencer {Keeper of the Kermits}, Box 4542, Berkeley CA 94704 ^^^^^^^^^^^^^^^^^^^^^optional I prefer checks, they make good receipts. I *will* include the sources for Amiga Kermit on the disk I send. I will include the sources for the IBM Kermit if requested (but it is so hard to keep up with the changes, and I cannot be sure that it will compile as I have not got all the compilers for the IBM (I am just using the transformer)). The sources for c64 Kermit will not compile on the c64 (they were compiled on a mainframe) so there is little use in downloading them. There are some other utilities on the disk and the .boo file is included if you want to modem someone else a copy of the file. Randy Spencer [Ed. - Thank you for offering to distribute Kermit on diskettes, Randy. Your name and terms have been put in the file KER:AADISK.HLP. Are there any other volunteers for micros we do not already have listed?] ------------------------------ Date: 27 Aug 86 14:14 EDT From: junod@dtrc.ARPA (John Junod) Subject: MSBPCT.ASM Keywords: .EXE files I have just completed a reconstruction of Kermit on a DEC Rainbow using the MSVRB1.BOO file. The target machine had a Vanilla MS-DOS disk without BASIC or a Terminal Emulator with file transfer. It did have MASM and LINK. I was able to capture the BOO file by using "copy aux mskermit.boo" (and you could capture the msbpct.asm file by using "copy aux msbpct.asm") and sending a control-z at the end from another MS-DOS machine connected to the Rainbow's communication port. Since I was unable to find an assembly version of MSBPCT I wrote the following to reconstruct MSKERMIT.EXE. (Note: you must have the source BOO file on the default drive as MSKERMIT.BOO and the output will always be MSKERMIT.EXE on the default drive. If necessary do a "copy" or "rename" of your capture file before running the assembled MSBPCT.ASM) Regards, John Junod Code 1821 David Taylor Naval Ship R and D Center (DTNSRDC) Bethesda, Md 20084-5000 [Ed. - Thanks John! The file is in KER:MSBPCT.ASM.] ------------------------------ Date: Fri, 05 Sep 86 01:50 EDT From: CCPHIL@TUCC Subject: Amiga Kermit Initialization Keywords: Amiga Kermit Cross-Ref: Commodore Amiga (see also Amiga Kermit) I have found the following kermit initialization file useful for the Amiga, when you want to emulate a standard ANSI terminal (like a VT100). I have used this with a PCI protocol converter and also a VAX VMS system. The PCI works well, but the VAX has problems in EDT when lines need to be scrolled up from the bottom of the screen. Note that the Amiga Kermit will configure itself based on the settings in the Preferances screen for the serial line. Insert the following lines into a file s:.kermrc : % % Set up to 80 columns by 24 rows, position to (0,0), & clear screen % echo \\033[25t\\033[80u\\033[0x\\033[0y\\014 % echo Kermit is initialized and 80x24 ANSI screen! ------------------------------ Date: Thu 4 Sep 86 16:12:48-EDT From: Frank da Cruz Subject: Kermit Documentation in French Keywords: French Kermit Documentation A translation into French of the first part of the Kermit User Guide appears in CiSi telematique's "Bulletin Technique", numbers 86/05-06 and 86/07-08, available (I'm not sure how) from CiSi telematique, 35 Boulevard Brune, 75680 Paris CEDEX 14, phone (1)45.45.80.00. Thanks to Gerard Gaye. ------------------------------ Date: 22 Aug 86 05:23:44 GMT From: pete@octopus.UUCP (Pete Holzmann, Octopus Enterprises, Cupertino, CA) Subject: Review of MS Kermit 2.29 vs ProComm 2.3 Keywords: MS-DOS Kermit, ProComm THANK YOU to the many who responded to my recent request for info on communications programs that properly handle flow control. This is a summary of the responses and my subsequent experience: The responses were almost unanimous in recommending either ProComm (2.3 is the latest version) or MS-Kermit (2.29 is the latest). A kind soul sent me MS-Kermit, and I picked up ProComm locally. A review of the two: Kermit: lots of options, but not really as flexible as the number of options might lead one to believe. Comes with one terminal emulator (VT102) and only one file transfer protocol (Kermit, no sliding windows). Can use 38.4 KBaud, a win. Drives my LCD display at about 6 Kbaud. User interface isn't too bad once you know how to use it, but it is not at all intuitive (you must 'Cancel Connection' to get to command mode, and that doesn't *really* break the connection, fortunately!). No dialing directory or other niceties, although you *can* push into DOS. File transfers are slooooowwww. Running between two 8 MHz AT's at 38.4 KBaud, I could only push through about 300 bytes a second!!! Rather poor. However, I didn't find any bugs. It may not do a whole lot, but it works. [Ed. - Actually, PC Kermit comes with 3 terminal emulators built in -- VT52, H19, and VT102 -- plus the ability to run with external terminal device drivers like ANSI.SYS or whatever. 2.29 is slightly slower than some previous releases, but not THAT slow! See below...] ProComm: Great user interface, lots of terminal emulations, lots of transfer protocols, lots of niceities including dialing directory that can also link to destination-specific command files (for auto-login, etc). Color, windows, (even sound if you can stand it). Very fast file transfers (even good in Kermit, with sliding windows, but slower than the other protocols). It is a 'shareware' program (kermit is from a University, presumably more altruistic). BUT A BIG BOO for all the bugs. ProComm has a strong tendency to lock up. More so on AT's, but also on PC's. It can happen when you aren't doing anything, it can happen during file transfer, it can happen due to problems in terminal emulation, it can happen... you get the idea. I've posted another article asking for help with these problems. I just can't trust ProComm. Otherwise, it would be the greatest thing since sliced bread. [Ed. - Kermit has color too...] Actually, there's two wish-list features I wish could be added to ProComm or some other program: 1) Conditional branching and user-input in command files, similar to some of the capabilities of CrossTalk. 2) Putting something like CWEEP into the comm program, so that one could easily select the files to be block-transferred. It would make unattended operation MUCH more useful! It would even be better if you could grab filenames off the screen (so you could get a remote directory, then just point at the files you want to download). Again, thanks for the help! (My current status: using ProComm in general, but using MS-Kermit when it is important that the job get done right without system-reboot hassles). [Ed. - The following comments about MS-DOS Kermit 2.29 performance on the IBMs and clones come from Joe Doupnik, who put together version 2.29 and is working on a new release, 2.29A] At 38400 baud the effective speed ought to be well above 9600 baud (like 14-16Kb or so). That's for the new version (2.29a) whereas the release version (2.29) is the normal slow poke (say 3000 but not quite 300 baud). MSKermit 2.29 is slower than 2.28 (please speed up if possible). Well, the test version of 2.29 on the previous disk is much faster than 2.28. As an example, transferring a plain text file, mssscp.asm in fact, between two regular IBM PC clones at 9600 baud this morning took: 132 seconds with MSK 2.28 67 seconds with MSK 2.29a/test same packet length as 2.28 That's a 2:1 speedup! Lower baud rates achieve less dramatic factors since the transmission time is a greater proportion of the whole. 2.29a at 38400 baud works, but the higher efficiency did not come cheaply. Some additional comments since I have focused on that topic recently. The measured overhead of new 2.29a to move a character from one ramdisk to another is close to 350 microseconds per character plus the time sending the data on the comms link. The per character time includes the major factor of time doing (s-l-o-w) DOS file calls. I overlap as much packet construction and decomposition as possible with i/o without going to extreme measures (read that as expanded buffering + management code). Screen writes are time consuming but are less so now. The release 2.29 (and earlier releases) had high overhead associated with clock timing (for timeouts); this version does not. Earlier versions had real trouble with the serial port at high speeds; this version has code written for high speeds. A problem with all comms programs is that items hanging on the clock tic block interrupts from the serial port and cause data loss. Examples are print spoolers, keyboard enhancers, screen savers, pop up helpers, and so forth; it is amazing how much time they eat. With a scope attached to the comms line I observe a series of 1000 byte packets to use 1.34 +/- seconds from ACK to ACK at 9600 baud; hence the timing figure above. This is on a regular 4.77 MHz PC and translates into an efficiency of 75% on the comms line. In the test case of transferring MSSSCP.ASM from hard disk to a ramdisk the new version gave a throughput of about 507 bytes/sec (5000 baud, 33950 bytes div 67 seconds) end to end (or about 7200+ on the comms line) including all overhead of prefix encoding chars, screen updating, packet header bytes, etc. I think the new Kermit will beat many or most X-modem implementations (certainly the ones I have). So, Kermit's efficiency is up this time around, and it can run at much higher speeds than before. ------------------------------ Date: Thu 4 Sep 86 10:04:46-EDT From: Walter V Dixon Jr Subject: Kermit on IBM MVS/XA Keywords: MVS/TSO Kermit? Another GE site is trying to use an MVS version of Kermit under XA. They are getting an ijkmsg SYSDA not allowed. Is there anyone they can call to get help solving this problem? Thanks Walt Dixon ------------------------------ Date: Mon, 18 Aug 1986 01:49 PDT From: "Jeffrey Sicherman" Subject: Suggestions for Fortran Port Keywords: Fortran Port I would appreciate some advice from anybody who has done a kermit port/implementation in FORTRAN or who is familiar with one or more of the FORTRAN implementations. The machine is a minicomputer and has an old FORTRAN compiler ... Fortran IV (which corresponds to FORTRAN 66, I think) and I would like recommendations on which of the existing versions would be easiest to convert. I could edit some new IF constructs, etc., but I wouldn't like to use one if it was rife with such constructs. Maximum facilities would be nice, but right now ease of conversion is primary. Please reply to me if possible: JAJZ801@CALSTATE.BITNET Thanks for any help. ------------------------------ End of Info-Kermit Digest ************************* ------- 10-Sep-86 16:54:28-EDT,20102;000000000000 Mail-From: SY.CHRISTINE created at 10-Sep-86 16:52:54 Date: Wed 10 Sep 86 16:52:54-EDT From: Christine M Gianone Subject: Info-Kermit Digest V5 #7 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12237896436.205.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 10 Sep 1986 Volume 5 : Number 7 Converting Kermit Distribution to 3 Tapes New (Minor) Release of C-Kermit for UNIX Kermit 2.29 for the NEC APCIII Uuencoded Files and Trailing Blanks Kermit for NCUBE AXIS Timing Problem with TOPS-20 Kermit VAX to PC binary file xfers Being thrown into CP while using CMS Kermit CMS KERMIT under VM/XA/SF? Kermit through 3708 Front End or WETRONIC Protocol Converter? PRIMOS Kermit v. IBM-PC 2.29? Kermit and Paradise Graphics Card? ---------------------------------------------------------------------- Date: Tue 9 Sep 86 17:26:35-EDT From: Frank da Cruz Subject: Converting Kermit Distribution to 3 Tapes Keywords: Kermit Distribution The collection of Kermit programs and documentation has once again grown beyond the capacity of our most common distribution, 1600bpi 2400-foot reels of magnetic tape. We are now in the process of reorganizing the files from 2 groups (micros and mainframes) into 3 groups (micros, mainframes, and esoterica). Our major goal is to keep the most popular stuff on tapes A and B, so that people who ordered these tapes before the changeover will still stand a good chance of getting everything they want. However, we must create sufficient empty space on tapes A and B to allow the new Kermit programs recently announced (and others waiting in the wings) to fit. We'll try to do this as fairly as possible. In the meantime, we'll be installing new programs and files on CU20B without necessarily also putting them in our other distribution areas or on our tapes. When this rash of installations (and announcements) is complete, we'll see how to most equitably distribute the files. Network access to Kermit files will be unchanged, but during the transition some of the new files won't necessarily be available at all of the distribution points. ------------------------------ Date: Tue 9 Sep 86 17:27:50-EDT From: Frank da Cruz Subject: New (Minor) Release of C-Kermit for UNIX Keywords: C-Kermit Cross-Ref: UNIX Kermit (see also C-Kermit) This is to announce a new, minor release of C-Kermit for UNIX. Because of some mixups this past July, the new Amiga Kermit was installed in the Kermit distribution with an inconsistent set of sources; the major reason for this release is to remove this inconsistency. Also, a few minor bugs are fixed. Significant performance improvements and additional features will come in future releases. Here's a brief summary of what's in this new release: Changes from Jack Rouse and Phil Julian of SAS Institute: . Commodore Amiga support, replaces that from Davide Cervone of Rochester U. All-new CKI*.* files (this was announced in Info-Kermit v5 #3). This is the version written up in Jul/Aug 86 Amiga World. . Revert CKUCMD.[CH] and CKUUS?.[CH] to their old selves (no more printf2, printf3, since these are no longer necessary for the Amiga), but add a few new Amiga specifics under #ifdef AMIGA conditionals. . Fix multiline GET parsing to allow get back to top-level prompt if illegal local filename given (in CKUUSR.C). . Supply a missing printf() parameter in CKWART.C. Other changes: Fix top-level parse loop in CKUUSR.C to reset any start state that might erroneously have been set when a parse error has occurred. Eliminates (for instance) the spurious "?Sorry, you must set speed first" message if you specify "foo bar" as the local filespec in multiline GET. Make sysinit() return -1 if it fails, 0 if it succeeds, and have CKCMAI.C check the return code. Corresponding changes to invocation of sysinit in CK[UVMI]IO.C. Change references in CKUFIO.C to _file member of FILE structure to more portable fileno() [suggested by Doug Orr, U of Mich]. In CKUFIO.C, change zclosf() to kill the fork before waiting for it to terminate. Fix Sys-V speed setting code (change "," to ";" between tttvt.c_cflag statements) in CKUTIO.C. Fix errpkt() function in CKCFN2.C to close open files, so that further host commands can be done by the server after such a command is interrupted abnormally [problem pointed out by Gregg Wonderly, Oklahoma State U]. Add Stan Barber's 4.3BSD acu control code to CKUTIO.C, under NEWUUCP conditional. I'm not sure if NEWUUCP needs to be defined in the makefile, or what... Version 4D(061) has been compiled and tested under Ultrix 1.1 (= 4.2BSD), Ultrix 1.2 (whatever that may be a hybrid of), 2.9BSD on a DEC Pro/380, and true 4.3BSD on a VAX 11/750 (4.3BSD includes an earlier version of C-Kermit -- 4C(057) -- on its distribution tape). The files that are new to this version are in KER: on CU20B. They are: CKUCMD.C, CKUCMD.H, CKITIO.C CKUUSR.C, CKUUSR.H, CKMTIO.C CKUUS2.C, CKUUS3.C, CKVTIO.C CKUFIO.C, CKUTIO.C CKCMAI.C, CKUKER.UPD ------------------------------ Date: Fri, 29 Aug 86 21:16 EDT From: Goeke@MIT-MULTICS.ARPA Subject: Kermit 2.29 for the NEC APCIII Keywords: MS-DOS Kermit, NEC APC3 Cross-Ref: NEC APCIII (see also NEC APC3 and MS-DOS Kermit) As we discussed almost two months ago, I have this version of a terminal driver for the NEC APCIII which implements almost everything found in the IBM PC driver plus some little goodies of its own. Roger Link (linkr%vtvm1) and I have worked together on debugging the present version; he is now releasing it to his general (local) universe, which will no doubt turn up additional bugs, but one cannot wait forever. I have put a note in the Boston Computer Society APCIII newsletter offering to supply disks for users finding it inconvenient to get the source from Columbia. The same offer applies to the general world, which you may publish in whatever manner is common. The instructions are to send me 1 floppy to get the executable code, 4 floppies to get all the sources. The address is: Robert Goeke MIT Center for Space Research Room 37-567 77 Massachusetts Avenue Cambridge, MA 02139 [Ed. - Thanks! We will distribute this stuff as part of the 2.29a release, since corresponding changes have to be made to all the other incarnations of MS-DOS Kermit. Till then, those who are anxious to get it can get floppies by mail as advertised above.] ------------------------------ Date: Sun, 03 Aug 86 22:35:31 EST From: MOEWS%UCONNVM.BITNET@WISCVM.ARPA Subject: Uuencoded Files and Trailing Blanks Keywords: Uuencoded Files If you use KERMIT under VM/CMS, it is hard to use uuencoded files such as the uuencoded version of ST Kermit, since VM/CMS Kermit removes all trailing blanks when downloading files. Here is a solution to this problem; it is a version of UUDECODE that supplies trailing blanks as necessary, written to run on the Atari ST. It is written in 68000 assembly language, and can be assembled using the public domain assembler, AS68. David Moews MOEWS@UCONNVM.BITNET [Ed. - Thanks David! The files are in KER:ASTUUD.*. The trailing blanks will be lost, however, if punched across BITnet. See KER:ASTKER.BWR for a more complete explanation and a SNOBOL program to restore the blanks.] ------------------------------ Date: Fri, 8 Aug 86 11:02:58 edt From: couch <@CSNET-RELAY.ARPA,@TUFTS.CSNET (alva l couch):couch@TUFTS.CSNET> Subject: Kermit for NCUBE AXIS Keywords: NCUBE AXIS I now have a partially functional adaptation of C - Kermit 4.2 for the NCUBE parallel processor running the AXIS operating system. Sincerely, Alva L. Couch, Dept. of Computer Science, Tufts University, Medford, MA, 02155 [Ed. - As soon as Columbia receives the files, we'll attempt to add Alva's code to the current C-Kermit release, and announce when it's ready.] ------------------------------ Date: Tue, 09 Sep 86 13:10:00 PDT From: Bob Larson Subject: Timing Problem with TOPS-20 Kermit Keywords: TOPS-20 Kermit Cross-Ref: KERMIT-20 (see also TOPS-20 Kermit) After making a few improvements in my specialized kermit used to transfer mail between USC's primes and other computers, (better timeout handling) files started being duplicated. (Cases of up to 26 have been reported.) I finaly traced the problem down: Tops-20 kermit (4.2(253)) frequently ignors a GE (Generic Erase, i.e. Delete File) packet sent immediatly after an ack to a B packet. (Is the tops-20 clearing its input buffer before going back to server wait?) By adding a delay (20 seconds is probably a bit much, but works) before sending the GE packet, this problem has dissapeared. My kermit implimentation cannot resend the GE packed after a timeout, since it requests to delete the oldest generation of a file (-2) after it has been transferred. (If the Ack of the GE packed was lost, repeating the GE packet would erase a file that has not been transfered.) A completly different solution to the problem would be to convince the tops-20 end to tell me what generation of the file it is sending. I'm not sure I want to put the work into supporting atribute packets even if the tops-20 end did. [Ed. - What the DEC-20 Kermit server actually does in response to a GE packet is to send back a whole transaction, in which the Data packets list the actual files (including generation numbers) that were listed. Thus you don't get an ACK, you get a "long form response". If you want to try to pick out the filenames from the data packets you can do so, but this would mean the Prime code would have to have special knowledge of the form in which the DEC-20 sends this information.] Another problem I have noticed with tops-20 kermit 4.2(253) is it wants a control-v counted as two characters in a GE packet it receives, which does not agree with my interpretation of section 8.2.1 of the kermit protocol manual (sixth edition). (The case of control characters is not dirrectly discussed, so it is somewhat left to interpretation.) [Ed. - If you want to quote a special character in a filespec sent to a DEC-20 Kermit server, precede it by a Ctrl-V, just as you would do when typing odd filenames directly to TOPS-20. The data field of the generic packet is formed before datalink-level encoding, therefore the little length fields within the data packet of a generic command reflect the length before encoding. For instance, if you want to send a generic command to delete a file called x.? (where ? is not normally a legal character in a filename), the data field of the g packet would look like "E$x.#V?" -- $ indicates a length of 4, AFTER DECODING (and before encoding). Clear? (ha)] Bob Larson ------------------------------ Date: Fri 8 Aug 86 21:37:30-PDT From: Dan Davison Subject: VAX to PC binary file xfers Keywords: VAX/VMS Kermit, MS-DOS Kermit Someone asked about doing binary file transfers via kermit from an IBM PC to a VAX. A response indicated that it can be done. I'm sorry to report that response is wrong in some cases. We routinely transfer files from VAXEN to uVAXen and other PCs (Pro 350, Dec Rainbow, IBMPC Portable, a few others). Vax has a binary file format tha CANNOT be transfered using KERMIT. They cannot (1) be transfered via KERMIT VAX to VAX; (2) uVAX to VAX (or vice versa) and (3) PC to VAX (or vice versa). It doesn't matter what parity, baud, stop,start etc. you use. We speak to a set of 785s, everybody running the same version of kermit. The thing to do is a DIR/FULL/ALL filename.EXE If the record size is 512 (the usual for VAX executables and some special format files made via FORTRAN and PASCAL) you are guaranteed to get garbage after the transfer. We have tried all sorts of ways around this, but the only way that works is to copy the files over DECNET to a machine that has a tape drive. We also cannot transfer binary (.OBJ) files with Kermit. The problem lies n in KERMIT but the way the VAX keeps information in the file header. You can transfer the files, true, but they are useless and cannot be RUN or LINKed. Non-DEC binary files, on the other hand, can be transferred successfully, re- loaded and used. I use our Microvax to backup my hard disk (until its reacent headache (crash) courtesy of Federal Express. If anyone wants further info, or knows of a way around this, please get in touch with me at one of the addresses below. Dr. Dan Davison, Dept. of Biochemical and Biophysical Sciences, SR-1, University of Houston--University Park, 4800 Calhoun, Houston, Tx 77004 [Ed. - The normal trick is to SET FILE TYPE FIXED or SET FILE TYPE BINARY. Did you try either or both of these? (They are alleged to work, provided the record length is 512.) Of course, what VMS Kermit really needs is attribute packets. PDP-11 Kermit uses this to transfer the entire FILES-11 FAB (or whatever it's called) along with the file, so it can be properly reconstructed on the receiving system, provided it's also FILES-11. Future releases of VMS Kermit may work somewhat better in this respect.] ------------------------------ Date: Fri, 01 Aug 86 23:19:27 EDT From: Mark S. Feldman Subject: Being thrown into CP while using CMS Kermit Keywords: CMS Kermit Recently, there has been discussion here about the problem of CMS Kermit falling through to CP. I've used CMS Kermit a lot, both here at the University of Maryland and at several comercial sites. Only one of the comercial systems that I have used has ever thrown me into CP, and it was doing it fairly consistently one day. The problem was not with Kermit, but with the over-loaded state of the computer. I don't even think that having control returned to kermit would have helped that day - the machine was being thrown into CP because it could not keep up with the input. What if you want to go into CP? While preventing CMS Kermit from being thrown into CP might help some people, I wonder if it might hurt some others. What if you need to break out of (server) CMS Kermit and for some reason the pc Kermit is unable to transmit a finish packet, or any packet for that matter. Wouldn't the proposed change to CMS Kermit make it very difficult, and perhaps impossible, to get out of CMS Kermit server mode if their were a problem with the pc Kermit? Mark [Ed. - When using the CMS in linemode through a 3705 or equivalent, then almost any kind of framing or parity error can throw you into CP. The proposed change will continue Kermit where it left off, immediately, whenever this happens -- a fairly frequent occurrence over dialups, etc. It's still possible to break out if you're coming in as a 3270 through a Series/1-style front end, and it may also be possible with a 3705 if you type a lot of BREAKs in a row.] ------------------------------ Date: Tue, 19 Aug 1986 16:04 EDT From: Nick Gimbrone Subject: CMS KERMIT under VM/XA/SF? Keywords: CMS Kermit Has anyone succeeded (tried) in using CMS Kermit under VM/XA/SF? [Ed. - CMS Kermit (any version) should work, provided VM/XA/SF has TTY support (does anyone know if it does?). In any case, Kermit should still work on these systems through Series/1-style front ends.] ------------------------------ Date: Mon, 11 Aug 86 13:04:12 MEZ From: UZR112%DBNRHRZ1.BITNET@WISCVM.ARPA Subject: Kermit through 3708 Front End or WETRONIC Protocol Converter? Keywords: Protocol Converters We (id est: the Computer Center of the University of Bonn, West Germany, where I work beside my studies), we want to run KERMIT on an IBM3708 Protocol Converter. Did anyone of yours already test this configuration? Did anyone of yours heard about someone *out in netland* who has this configuration and/or has tested it and/or is using it. Any notes concerning this problem will be very welcome !!!!!!!! [Ed. - The 3708 makes an ASCII terminal look like an SNA terminal, rather than a local bisync 327x terminal. There is no code in CMS or TSO Kermit to handle these, and it's not clear that there ever can be -- for a protocol converter to be usable for Kermit file transfer requires that it can be put into transparent mode (and that the mainframe Kermit program know how to do this); does the 3708 have a transparant mode, like the Series/1 or 7171?] Did anyone *out there in netland* already succeded in a filetransfer using KERMIT for conecting PCs to an IBM/370-series-mainframe via a Protocol Converter WETRONIC PCI/1076? We are able to run an emulation on this configuration, but we still have problems when trying the file transfer facility. Any notes concerning this problem will be very welcomed. Thanks a lot for all your efforts in advance. Have a nice day. Please answer me directly to: Thorsten Glattki Computer Center,Univ.Bonn,W.-Germany My netaddress is : [Ed. - Similar considerations apply here. Does the WETRONIC thingie have a transparent mode? If so, code can be added to mainframe Kermit to turn this on and off, as it does for 7171's, etc. Otherwise, forget it.] ------------------------------ Date: Fri, 29 Aug 86 11:14:58 BST From: Chris_K_now-and-then Subject: PRIMOS Kermit v. IBM-PC 2.29? Keywords: Prime Kermit, MS-DOS Kermit Has anyone actually worked IBM-PC Kermit 2.29 against (any) PRIMOS Kermit successfully? If so a note as to the settings employed would be much appreciated. A friend at Salford is failing utterly. Chris Kennington. [Ed. - This combination is in common use between The Source (which has Primes) and their customers (many of whom have PCs). However, most accesses to The Source are through Telenet, which adds an additional level of complexity. The magic in that case, however, is simply "set parity mark". Do you have the most recent (May 86) version (7.57)?] ------------------------------ Date: Mon, 8 Sep 86 15:40:47 EDT From: Kenneth Van Camp -FSAC- Subject: Kermit and Paradise Graphics Card? Keywords: Graphics Card I recently replaced my old IBM monochrome (non-graphics) display adapter with a Paradise Modular graphics card (still driving my IBM monochrome display) on my PC-XT. For some reason, the text display with this board is noticeably slower than with the old mono card. I can live with this, but when I go into Kermit I am now dropping characters when in the normal connect mode. I tried slowing down the baud rate to 4800, and I even told Unix to put in some fairly long pauses after every line (stty cr3), to no avail. I also tried both types of flow-control in Kermit, with no effect. It's important that I point out that nothing has changed except the display adapter -- same modem, same Kermit, etc. Yet Crosstalk XVI doesn't seem to have the same problem; no characters are dropped at any speed. Does anybody know what's going on? --Ken Van Camp ------------------------------ End of Info-Kermit Digest ************************* ------- 15-Sep-86 09:40:29-EDT,25093;000000000000 Mail-From: SY.FDC created at 15-Sep-86 09:35:20 Date: Mon 15 Sep 86 09:35:20-EDT From: Frank da Cruz Subject: Info-Kermit Digest, V5 #8 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12239127498.282.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Mon, 15 Sep 1986 Volume 5 : Number 8 Today's Topics: Prerelease Version of MS-DOS Kermit 2.29A Available for Testing New Release of Kermit for Concurrent (nee Perkin-Elmer) 3200 New Kermit for Burroughs 7800 and A Series Glut of Kermit Files (A Plea) MS Kermit use of COM3 CMS Kermit under VM/XA/SF Clarifications Distributing TAKE scripts. Kermit 2.29 for Tandy 2000? ---------------------------------------------------------------------- Date: Fri 12 Sep 86 13:45:15-EDT From: Frank da Cruz Subject: Prerelease Version of MS-DOS Kermit 2.29A Available for Testing Keywords: MS-DOS Kermit 2.29A, IBM PC, Rainbow Cross-Ref: DEC Rainbow, see Rainbow A prerelease test version of MS-DOS Kermit 2.29A is available for testing on the IBM PC,XT,AT and compatibles, and the DEC Rainbow. This test version is being released at this time mainly to help those who must use the program for file transfer in half-duplex environments (e.g. with IBM mainframes or certain HP or Harris minis) where line turnaround handshaking must be used; version 2.29 has a bug that prevents this from working, and 2.29A fixes the bug. 2.29A also includes some new features. These are not necessarily completely developed or polished in this test release, but they appear to be mostly functional and usable: . Performance improvements, particular on the IBM PC family. . Support for extended-length packets, up to 1000 bytes long. . A script facility, almost identical to the one in DEC-20 Kermit. . A TRANSMIT command, for raw uploading. . An ECHO command. . VT102 ANSI printer control support (IBM PC family only). Extended-length packets may be enabled using the SET SEND/RECEIVE PACKET-LENGTH command, and will be used if the other Kermit program supports them. So far, only Kermit-11 (for PDP-11's with RSX, RT, RSTS, etc) does, but version 3.1 of IBM VM/CMS mainframe Kermit, which will be announced shortly (next week?) will also support long packets. The script facility allows you to write "programs" of Kermit commands to interact with the remote system. Scripts are typically used for dialing modems, logging in on remote systems, or performing other routine and/or complicated interactive jobs. The Kermit script is not a full-fledged programming language (with variables, conditional branching, etc), but differs from other popular script facilities by not differentiating script commands from other program commands, so that all Kermit commands may be freely intermixed in a script. The commands that were added specially to support script execution include INPUT, OUTPUT, PAUSE, ECHO, plus various SET options. The Kermit User Guide chapter for the DEC-20 (KER:K20MIT.DOC) may be consulted for a complete description of the script facility. Raw uploading is accomplished using the TRANSMIT command, which sends a file "raw", a line at a time. It works like DEC-20 Kermit's TRANSMIT command, and may (like any other Kermit command) be used in conjunction with scripts. The ECHO command includes \ooo escape sequence recognition for including arbitrary characters in octal notation. This allows all sorts of fancy special effects on the Rainbow by including VT100 commands in strings to be echoed, and also on IBM PCs that have ANSI.SYS or similar console drivers loaded. ANSI printer support allows the PC to respond to host escape sequences for printing selected regions of the screen, turning the printer on and off, etc. Version 2.29A is being put together by Joe Doupnik at Utah State University (JRD@USU.BITNET), who also was responsible for version 2.29. The performance improvements, bug fixes, and long packet support were done by Joe, and the script facility came from James Sturdevant at AC Nielsen in Minneapolis, and Joe integrated it into the new release. The files are in KER:MSTIBM.BOO for the IBM family and KER:MSTRB1.BOO for the Rainbow. Use any of the BOO-file decoders, KER:MSBPCT.*, to decode into runnable .EXE files. A brief guide to the new features of 2.29A is in the file KER:MST29A.HLP. No additional major functionality is intended for 2.29A, so please restrict your comments and suggestions to features that are already in the program. Note that the MST*.BOO files may be replaced from time to time as bugs are reported and fixed, up until the final release of this version. ------------------------------ Date: Thu 11 Sep 86 10:29:15-EDT From: Frank da Cruz Subject: New Release of Kermit for Concurrent (nee Perkin-Elmer) 3200 Keywords: Concurrent Kermit Cross-Ref: Perkin-Elmer Kermit (see Concurrent Kermit) This is to announce version 2.1 of Kermit for the Concurrent Computer Company (formerly called Perkin-Elmer) 3200 series under OS/32 7.2.1 and up, by Paul Mamelka, Southwest Foundation for Biomedical Research, San Antonio, Texas. The major changes from version 2.0 of June 1985 are: . Name change from Kermit-PE to Kermit-CO . Horrible bug fixed caused by typo (RECKPT instead of RECPKT) . Minor bugs also fixed . First 3 letters of command or set option now sufficient for abbreviation . SYSIO style now controlled by parity setting . Selection of text, binary, contiguous file types . End of record selection for text file transmission . "File Warning" added (filename collision avoidance) . Initialization file . Automatic error logging The new files replace the old ones as PERKIN.* in the Kermit distribution (even though Paul sent them to us with the new prefix CON to denote the company name change). ------------------------------ Date: Thu 11 Sep 86 11:44:59-EDT From: Frank da Cruz Subject: New Kermit for Burroughs 7800 and A Series Keywords: Burroughs Kermit This is to announce Kermit for the Burroughs 7800 and other Burroughs large systems (5000/6000/7000 and A series), written in Algol by Larry Johnson, Dave Squire, and Katie Stevens at the Computer Center, University of California at Davis. The program and user manual are in the Kermit Distribution as B78*.*, alongside the other Burroughs mainframe Kermits, B68*.* (for the 6800, from Quest Research, Inc), and B79*.* (for the 7900, from THE--Technische Hogeschool Eindhoven). If any Burroughs aficionados out there know if this new program makes either or both of the other two redundant, please let us know so we can move them to a less critical area. UC Davis has indicated willingness to supply this version of Kermit directly to other Burroughs sites that request it directly from them. The address is: David Squire Senior Programmer, ID-1023 Systems Group, Computer Center University of California, Davis Davis, CA 95616 USA ------------------------------ Date: Fri 12 Sep 86 14:45:15-EDT From: Frank da Cruz Subject: Glut of Kermit Files (A Plea) Keywords: Kermit Distribution As Kermit's popularity escalates, more and more contributions of Kermit programs show up on our doorstep. We know what to do with many of them: new ones simply get installed (though often a good deal of file renaming is necessary to avoid conflicts), etc. But what do we do when there are multiple versions for the same system, or similar systems? In some cases, we can't really tell when a version is redundant, because we don't know enough about the systems involved (like the Burroughs mainframes mentioned in the previous message). In other cases, two different people submit totally different Kermit programs for the same system; should we keep both (sometimes there are more than two!)? It would be most helpful if we could get some feedback from the people who actually use these programs. Here are a few items we could use some help with, as we try to clean up our Kermit collection: Apple II DOS - Does anybody use the native 6502 assembler version that was based on an old release of the CROSS version? (By the way, a new, native assembler version is under development at the U of Maryland, and work is also being done on a new release of the CROSS version.) Burroughs - Are all 3 versions (prefixes B68, B78, B79) necessary, or can one or two of them be eliminated? CDC - We have two CDC Cyber Kermits, one in Fortran, one in Compass. Do we need both? Is one more portable, or clearly better in other ways, than the other? Commodore 64 - The "major" version is in CROSS, based on the Apple DOS version. CROSS only runs on DEC-10s and DEC-20s, most of which are not long for this world. Does anybody care enough about the C-64 to translate this into a native assembler (if there is such a thing)? And what about the other C-64 Kermit written in FORTH? Data General MV Series with AOS, AOS/VS - We have several Kermits for these systems. Most of these are quite old, primitive, buggy, and undocumented. There are at least 3 or 4 separate efforts underway to replace them. I have urged the various people or groups to get together and settle on a single replacement. Watch Info-Kermit for news, or read the file KER:AAWAIT.HLP in case you're interested in contacting any of these people directly (this file contains a list of all the Kermit programs that we know to be under development). DEC PDP-11 - We have a main version (Brian Nelson's Macro-11 version) that runs on all the DEC operating systems, but there's also an old OMSI Pascal version just for RT-11. Does anyone use the Pascal version any more? DEC Rainbow - Does anyone out there run QNX on the Rainbow? Have they tried QNX Kermit? How about on the IBM PC? DEC VAX/VMS - The main version is the Stevens Inst. of Tech. version written in Bliss, but also distributed in Macro-32 source form. But there's also an old Pascal version. Does anyone use the latter? Also, is anyone using the VMS implementation of C-Kermit? Gould/SEL 32 MPX-32 - We have two separate versions, both in Fortran, for this system, prefixes GM1 and GM2. Do we need both? Can GM1 be retired? Honeywell - All this Honeywell stuff is a mystery to me. In addition to Multics Kermit (we have one version of this, but have heard that there are several others floating around), there are two separate versions for GCOS (one in B, one in C, prefixes HDP and HG, respectively), and two for CP-6 (one in Pascal and one one in PL/6, prefixes HCP and HC6). Do we really need all of these? How about "Level 6" or DPS-6? Can anyone who really knows the Honeywell world recommend a consistent, minimal set of good Kermit programs for the Honeywell line? IBM 370 MVS/TSO - We have a couple different versions of Kermit for this system, but they will all soon be replaced by a new comprehensive release from the National Institutes of Health. ICL/Perq - Does anybody still have Perq workstations? If so, can they tell us if we really need two different Kermit programs for the Perq, both in Pascal? (Prefixes PQK and PQ2.) If not, which one is better? Intel - There are literally dozens of Kermit programs for Intel micros, many of which we haven't either bothered to install. Some are for RMX (or iRMX), some for ISIS. Can anybody who knows about Intel development systems take a look at these and tell us which ones are redundant? In addition to the MS-Kermit 2.29 Intel support modules, we have specific Intel Kermit programs with prefixes RMX, I86, MDS, and MD2. Software Tools - We have a version of Kermit written in Ratfor for use with the Software Tools library. It reportedly runs on at least the HP-3000 and the Sperry 1100. Is anyone actually using it? Does anyone know if it runs on any other systems? Univac (oops, I mean Sperry (oops, I mean Burroughs)) 1100 - We have 3 Kermits for this one: prefixes ST (Software Tools), UN (Assembler), and another UN (Pascal). Can any of these be sacrificed? At least, can one of them (say, the assembler version) be considered the "main" one? Victor 9000/Sirius 1 with MS-DOS - In addition to the support in MS-Kermit 2.29 for this system, there's also a C language version. Is anyone using it? Comments, comparisons, reviews, suggestions will be appreciated. The more redundant material we can retire, the more room we have for new Kermit programs, and the less often we have to add new tapes to the Kermit distribution. Meanwhile, anybody who's considering writing a new Kermit program or upgrading or fixing an old one, please contact Kermit Distribution at Columbia before proceeding to make sure that your work will not be duplicating someone else's. Thanks! ------------------------------ Date: 10 SEP 86 12:12-MDT From: JRD@USU Subject: MS Kermit use of COM3 Keywords: MS-DOS Kermit, COM3 In response to queries about use of more than two communication ports with MS-DOS Kermit, I have compiled a few pointers. MS Kermit, internally, does allow many serial ports: four directly and as many as wished through rebuilding. As we all realize MS Kermit tries to connect directly to the serial port hardware (the UART chip, if possible so that characters can be read by an interrupt procedure. Hardware details differ greatly among MSDOS machines so code for serial port specifics is located in the system dependent module MSX---.ASM. The number of ports visible on the Status screen is adjusted to match the kind of machine (model) being used. The system independent part of Kermit has a standard table of four named ports, expandable to whatever size is needed, which hold nine bytes of information for each port. That information is the baud rate index, flag for local echo on/off, parity type flag, flow control bytes and on/off flag, and handshake (line turn around) character and on/off flag. Expansion thus uses little space. The system dependent module(s) examine this table to decide how to setup the particular port. The table is found in file MSSCOM.ASM. For IBM PCs and clones MS Kermit knows the hardware addresses of COM1 and COM2, which have been specified by IBM. Higher comms port addresses have not been standardized and thus are not mentioned in MS Kermit. However, it is a simple matter to add new addresses to the list in MSXIBM and to readjust the couple of tables which support the Set Port command (performed in MSXIBM). The most recent (September) issue of PC Tech Journal has an article on boards offering many serial ports, together with the range of addresses provided by each board. It is unfortunate that the addresses near standard comms ports are frequently used by other add-in hardware so that no consensus exists for COM3 et seq. and hardware conflicts are common. ------------------------------ Date: Thu, 11 Sep 1986 13:47:00 EDT From: Nick Gimbrone Subject: CMS Kermit under VM/XA/SF Clarifications Keywords: CMS Kermit To clarify my question concerning CMS Kermit under VM/XA/SF. We currently have and are running this operating system. The CMS we are running under it is esentially identical to CMS R4 under an HPO system (we don't yet have FILELIST and that ilk of commands up and we have a small mod to XEDIT to address an LDEV problem). VM/XA does NOT support any TTY access. VM/XA/SF only supports 3270s (real, or fake as with the 7171). When attempting to run Kermit over a 7171 or Passthru (which works under VM/HPO and VM/SP systems) under VM/XA/SF I get an addressing exception. I will eventually be looking at this, but if anyone has already solved the problem I'd appreciate hearing from them via the net. Thank-you. ------------------------------ Date: Thu, 11 Sep 1986 02:17 PDT From: "Jeffrey Sicherman" Subject: Subject: Distributing TAKE scripts. Keywords: TAKE command, Script Since one of the problems of using micro KERMITS with unfamiliar mainframes is not knowing the necessary protocol parameters that may be required to interface through front-ends and operating system peculiarities, a standard way of distributing appropriate TAKE scripts on a system or site specific basis would be desireable. Why not bootstrap them? In particular, I would propose a CONNECT TAKE [filename] command for the local system. This would have the effect of CONNECTing to the the host which should be running KERMIT in non-server mode (by definition of the problems, we are not ready to send packets yet). The user would then enter a new command: GIVE [systemname] on the host. Ignoring the optional name arguments for moment, the effect of this would be that the local micro would interpret the lines coming from the host not only as displayable data but as local commands, just as though a local TAKE had been performed. Most likely these would be SET commands: (almost) anything that would be valid in a local TAKE file (it would not be wise to switch ports or line parameters at this point or invoke any transfers or change of mode). [Ed. - Well... It's a good idea, but complicated. The first pitfall is that neither the host Kermit program nor the local one necessarily know what parameters are really necessary -- for instance, if the connection goes through an X.25 network, or bounces off a satellite, or is very noisy. The user is the only one who really knows.] Of course, a minimal subset of all possible commands would probably be most appropriate for consistency across a broad range of micro implementations; such a list would be sent when the GIVE is issued with no systemname argument. It would establish the minimum conditions for a usable and reasonably efficient exchange. Where differences are significant with respect to different local systems, especially with regard to reliability or efficiency, a systemname specification would send SETtings appropriate to that combination. I have stated this as systemname rather than filename since there is no reason that the responses could not be built into the program rather than increasing the number of distribution files. This makes it somewhat inflexible though, so there are good arguments on each side (maybe I'm only arguing with myself) and I don't think the choice is critical; either way will serve the purpose. [Ed. - The problem here is that there are hundreds of programs to deal with, and, because Kermit is a volunteer, cooperative, loosely organized effort (at best), each program's syntax has its peculiariarities, despite the efforts that have been made to settle on consistent terminology (e.g. in the User Guide and Protocol Manual). Does this mean we have to change 50 or 100 programs to make them conform? Or does it mean that every mainframe Kermit should have explicit knowledge of the variations in syntax used by all the other Kermit programs? Unfortunately, both alternatives are impractical.] The optional filename on the CONNECT TAKE command would cause the received commands to be stored into a local file that could be TAKEn locally for subsequent uses. Admittedly, this is not an error-free exchange but the errors are likely to be noticeable to the operator when rejected by the command processor and the process can be repeated. By saving an error-free transmission, it need only be performed once or infrequently. For this reason, a remote KERMIT implementation should probably announce the existence of new values at initialization time when changes of significance are made. If random (non-syndromatic) single character changes in transmission are of concern (such as for decimal specifications of block-check options, maximum lengths, framing character specifications) I propose the following mechanism: Define a new command called VERIFY which takes all the same operands as SET but merely compares its target value to the current setting. If a discrepancy exists, display an error message. By inserting SETs and VERIFYs in the same GIVE transmission at appropriate intervals, most such errors should be operator detectable. The implementation seems rather straightforward to me since the same parsing could be used with a global mode switch telling low level logic whether a store/call or compare/error is to be invoked. A final possibility to minimize the possibility of an erroneous transmission being used would to, either by default or command variation, cause the commands in the take to be checked (and verified), but only put into effect if no errors occur. This could be accomplished by having an edit-only pass on initial receive and rereading the take destination file if error-free. If the no-file-name variation were used, the take stream could be stored in a temporary file and/or an internal buffer. [Ed. - Kermit already has an automatic way for each Kermit program to "configure" the other one with respect to settings for buffer size, packet terminator, padding, timeout, etc., namely the Send-Init negotiation. These packets provide a common intermediate representation for these parameters and their values, something you don't get with textual SET commands, which can vary from program to program (in fact, some programs don't have command parsers at all, but use menus instead). Unfortunately, not everything can be negotiated in these error-checked packets. Most notable are physical or datalink settings like baud rate, parity, and flow control, because these must already be set correctly before the Send-Init negotiation can take place. And, still more unfortunately, these parameters are often unknown (and sometimes unknowable) to the programs themselves. However, it is possible to adopt some heuristics to get around some of the other problems, and these can be fairly simple. One example would be automatic parity detection -- when the program gets the first packet (S, I, Y, G, etc, which will never contain 8-bit data), it can figure out what the parity is, if any, and then adjust itself accordingly. This kind of trick seems more practical and reliable than the proposed method of exchanging SET commands.] ------------------------------ Date: 11-Sep-1986 0946 From: g_hafner%wookie.DEC@decwrl.DEC.COM (Gary Hafner, DEC Littleton) Subject: Kermit 2.29 for Tandy 2000? Keywords: Tandy 2000 Kermit 1) Does anyone out there know of a version of MSKERMIT V2.29 that's been modified for the Tandy 2000? If not, could someone take a minute and explain what it would take to do such a thing? Being a mainframe-type of user rather than a PC user, I don't really know a heck of a lot about MS-DOS, but I have a relative that could use this program if there were some way to come up with it (who knows, between the 2 of us we might even be able to come up with it ourselves...). [Ed. - The version of Kermit we have for the Tandy 2000 was based on an ancient version of IBM PC Kermit, namely 1.20, when it was still a single-module program just for the PC, adapted by Steve Padgett at the U of Texas in Feb, 1984. The Tandy-specific code is under T2000 assembly conditionals. It would be great if somebody could look at this code and churn out MSX, MSY, and MSZ modules from it, to fit in with the current multi-module MS-DOS Kermit.] 2) I understand there's already 2 files for the Tandy 2000, and one of them, a file with a ".FIX" extension, appears to be in a form similar to the "MSxxx.BOO" formats for other machines. Could someone jot down the names of the programs that both create AND 'unscramble' this format? I'm not familiar with it at all. [Ed. - The .FIX file was a precursor to the .BOO file. It was a simple 4-for-3 (or was it 3-for-2?) encoding, but with no compression. The program to decode the .FIX file (this was the only survivor of the species) was in TA2EXE.BAS. However, as of now, both the .FIX file and the TA2EXE.BAS program have been removed and replaced by a TA2000.BOO file, which you can "un-boo" in the normal way, as described in MSBAAA.HLP. The .BOO file is only about 18K long, compared with the 30K .FIX file (and 15K .EXE file). The 8-bit binary .EXE file is now available in KB:TA2000.EXE, for those who can FTP it directly from CU20B.] ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Sep-86 16:06:52-EDT,20563;000000000000 Mail-From: SY.CHRISTINE created at 17-Sep-86 12:16:56 Date: Wed 17 Sep 86 12:16:56-EDT From: Christine M Gianone Subject: Info-Kermit Digest V5 #9 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12239681204.330.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 17 Sep 1986 Volume 5 : Number 9 Today's Topics: Announcing IBM Mainframe VM/CMS Kermit Version 3.1 MS-DOS Kermit 2.29A Prerelease Announcing Kermit for DTSS CP/M-80 Kermit-80 Version 4.08 on Trial Release in UK Comment on MS-DOS Kermit vs Graphics Screen Display Problems with Atari ST Kermit Problems with MacKermit 0.8(34) ---------------------------------------------------------------------- Date: 1986 Sep 9 20:05 EST From: (John F. Chandler) Subject: Announcing IBM Mainframe VM/CMS Kermit Version 3.1 Keywords: CMS Kermit, IBM Mainframe This is to announce CMS Kermit Release 3.1 for IBM 370-series mainframes running VM/CMS. The new version has been consolidated into a single source file, but there is a new, optional, separate program which can be used for loading Kermit into high memory (thereby allowing Kermit to invoke any CMS program). An effort has been made to keep the CMS-dependent parts of Kermit together (many operations are performed using MACRO's which could be redefined to fit, for example, TSO), but there are still many spots in the code which implicitly assume the CMS environment. Below is a list of the more important additions in Version 3.1: 1. Massive reorganization and cleanup of source code. 2. Advanced server functions. 3. Basic and advanced commands to a local server from remote mode, driven by TAKE command file. 4. Long packet protocol (type 0 extended headers). Allow arbitrary foreign filespec in SEND and GET commands. Provide optional prefix and suffix for outgoing file headers. 5. CWD and SPACE commands along with SET DESTINATION. The default filemode for SEND is taken from CWD. 6. TYPE, ECHO, XTYPE, and XECHO commands (the latter two being Series/1 transparent-mode analogs of the first two, useful for raw downloading). 7. REMOTE KERMIT commands honored by CMS Kermit server, including SET, SHOW, TDUMP, TAKE, CMS, CP, STATUS, and SPACE. 8. TEST mode for debugging. 9. Optionally append to, rather than, replace, old files with duplicate names. 10. Optionally keep files even when the transfer is cancelled. 11. Send Attribute packets with file size, host system, and possibly file type and record format. Receive and ACK attribute packets. 12. Option whether to search only the "home" disk and its read-only extensions or all accessed disks when the filemode is omitted from filespec. 13. Automatic recovery from line-noise interruptions on TTY lines. 14. Multi-column, two-level selective SHOW display. 15. New help text for HELP command. [Ed. - Many thanks! Version 3.1 began as 3.0 (which was never released), consisting mostly of source-level reorganization, cleanup, bug fixes, plus new keyword parsing and a new help command, by Vace Kundakci of Columbia. John made further contributions, including the new server functions, Attribute packets, new SET and SHOW commands, the new CMS chapter for the Kermit User Guide, the new installation procedure, and more. Bob Bolch of Triangle Universities added the extended-length packet support, Clark Frazier of the Harvard B-School added features for raw downloading through the Series/1 (XECHO and XTYPE). The new version should also fix most or all of the bugs that were reported by many sites (particularly by Greg Small at UC Berkeley) since the release of version 2. The new files are in KER:CMS*.* on CU20B. The old ones will be kept on CU20B for a while as KO:CMS*.*.] ------------------------------ Date: Tue 16 Sep 86 12:41:47-EDT From: Frank da Cruz Subject: MS-DOS Kermit 2.29A Prerelease Keywords: MS-DOS Kermit The MS-DOS Kermit 2.29A Prerelease that was announced in the previous digest turned not to work with IBM mainframe Kermits. It has been fixed in this respect and replaced. The new version is dated September 15 rather than September 10th, and has been tested against VM/CMS Kermit with no problems, using both 3705 (linemode) front ends and Series/1-style ASCII protocol converters, and both regular and extended-length packets up to 1000 bytes in length. The test versions of MS-Kermit are in KER:MST*.* on CU20B and also on KERMSRV as MST* * for BITNET access. Also, as noted in the .HLP and .BWR files, when parity is set to NONE, all 8 bits of incoming characters are displayed on the screen during CONNECT. This will cause consternation to users of systems (particularly the IBM PC family) with 8-bit character sets. This feature was added to accommodate European and non-Roman-alphabet environments that really do have 8-bit ASCII character sets, but it was erroneously tied to the PARITY setting. In fact, there are systems (like the DEC-20) which have 7-bit ASCII character sets, but which send parity (e.g. even) to the terminal, but don't require parity coming from the terminal, and whose Kermit programs put the line into transparent 8-bit mode for file transfer. Until a new SET command is added to select 8-bit or 7-bit terminal display, the workaround is to SET PARITY SPACE during terminal emulation and to SET PARITY NONE for file transfer. ------------------------------ Date: Tue 16 Sep 86 13:11:57-EDT From: Frank da Cruz Subject: Announcing Kermit for DTSS Keywords: DTSS Kermit A new version of Kermit has been written for Honeywell 6000 mainframes running the Dartmouth Timesharing System (DTSS) in "Virtual PL/1" (VPL1) by Philip Koch of the Dartmouth Kiewit Computer Center. This is a relatively esoteric Kermit since there are not very many DTSS installations, and of them, few have VPL1 compilers. However, brief instructions are included for converting to non-virtual PL/1. There's no manual or help file, but there are some comments at the beginning of the source file, which is in KER:DTSS.PL1 on CU20B. Thanks to Philip Crowell of Dartmouth for sending the program to us on tape. ------------------------------ Date: 11-SEP-1986 17:01:26 From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK (Alan Phillips) Subject: CP/M-80 Kermit-80 Version 4.08 on Trial Release in UK Keywords: CP/M Kermit Cross-Ref: Kermit-80 (see also CP/M Kermit) Bertil Schou at Loughborough University in the UK (OBSchou@UK.AC.LUT.MULTICS on the UK JANET network) has now got his mammoth rewrite of Kermit-80 available for test release. At the moment the files are available only by FTP in the UK from his machine, but once the very worst bugs have been cleared we'll be getting the files to Columbia for wider circulation. Bertil has sent in some notes on what changes he's made: here they are: Superficially, there is little real change in operation of Kermit-80, but there have been some major jobs tackled like trapping BDOS calls and multiple FCB buffering... New bits for this version include: SET {SEND/RECEIVE} START-OF-PACKET character SET DIRECTORY-FILE-SIZE (Shows or hides file sizes on DIRectory displays) USER to set other user spaces RECEIVE to collect a file from a remote SENDer GET to collect a file from a remote SERVER SEND {local filename} {remote filename} TAKE to take command files from disk automatic TAKE KERMIT.INI on default disk on loading KERMIT-80 (useful for SET BAUD etc.) much improved speed on DIRECTORY automatic CLOSE-ing of a terminal connection if the line is DROP-ped (currently only for an Apple, and Torch has a dummy test for cntrl-] D in connect state) improved printer handling. (Kermit-80 sends an XOFF to the host if the characters are comming in faster than they are printed. This does not work in this version, as another option, SET FLOW-CONTROL has not been fully implemented - also, I did not have a printer to test this out on a Torch...) On the negative side, only LASM can be used to assemble the source files. I personally see no pont in being able to support several assemblers if LASM can do the job, but then again, I have not used the MAC80 cross assembler... All source files have been renamed, and there are a few additions. All source files are named in the form: CPaxxx.ASM where: a=S for system independent source files a=X for system dependent source files a=other letters for .HEX files etc. These files have NOT been created as yet. The system dependent code has changed a litle too, hopefully bringing the CPXSYS.ASM (formerly CP4SYS.ASM) file a bit more toward a manageable size. There is now the possibility for FAMILIES of systems, like APPLE and NorthStar (also Comart), which contains code for computers of a single type. I have immediately gone against all this by creating a family with the code for Torches, Cifers, Ithacas and Superbrains. (This because we have these systems here at Loughborough) CPXSYS.ASM is largely unmodfied from CP4SYS.ASM. Systems now in families have their code duplicated in the relavent family file. CPXSYS.ASM LINKs to the family file if appropriate. In due course, I hope to split off more systems into "families" either on their own, or grouped with other similar systems. I know this is a half way step to true independent code for each system, but some systems are so close to others that I think it best to group them this way. All VDU and terminal information is now held in CPXVDU.ASM. This is really the last section in the older CP4SYS.ASM file. A quick "schematic" of what happens at assembly time... LASM CPXTYP... this then assembles the following: CPXTYP | v CPSDEF | v CPXLNK | v (CPXSYS acts as a sorter for FAMILY switching) CPXSYS-------+----------+-----------+-----------+---- | | | | | v v v v v (rest of CPXTOR CPXAPP CPXNOR CPX??? one of CPXSYS) | | | | several | | | | | Families +<---------+----------+-----------+-----------+---- | v CPXVDU | Users should be aware of the change both to the linking information and start of the overlay address. There are two new entries in the table, family (offset 6) and lptstat (offset 20h). The former is a two byte pointer to a text string for a FAMILY (or null if not used) and the latter a JMP to a routine giving the status of the printer. This can be done through BIOS, but not through BDOS. Users with odd sorts of printers may need to add their own code here. There have also been some bugs fixed in some of the system dependent code, so you would be wise pulling all the source files across. The overlay address is now 5000h, and will probably change before this revision is complete. The speeding up of multiple file handling takes its toll on memory, as there are now 64-ish FCBs buffered. This speeds up the DIRECTORY command no end. With the overlay address at 5000h there is still a lot of space free for more things to be added (about 800h bytes). Things yet to be done - lots! There have been moves trying to add other independent modules for other terminal emulators other than the VT52. Demands for SERVER, REMOTE HOST..., file compression, better TRANSMIT, % of file sent and/or Kbyets sent/received as part of the display diring transfers, a lot of cosmetic tidying up as well as even more systems to be added. CP/M-80 is a slowly dying DOS, and I feel inclined to leave some bits out, like SERVER (how many use really large winchesters in CP/M-80 systems, and want true servers?). Does anyone have a burning desire for these facilities? And if so, will YOU be willing to take on the job of implementing them? Bertil Schou. [Ed. - Above you see the future of CP/M-80 Kermit -- comments and suggestions will be relayed to Bertil -- get them in soon, before it's too late.] ------------------------------ Date: 14 SEP 86 18:44-MDT From: JRD@USU Subject: Comment on MS-DOS Kermit vs Graphics Screen Display Keywords: MS-DOS Kermit In the Kermit Digest V5 #7 Kenneth Van Camp, kvancamp@ardec, said that his new display board was causing MS Kermit 2.29 (but not Crosstalk) to drop characters arriving from the serial port. The critical things here are: does the display board turn off interrupts during screen scrolling, does it use the standard color card display memory address (B800H, vs B000H for the monochrome card), does it use interrupt request lines reserved for the serial port, and might its Bios (if any) intercept the normal Int 10h video interrupt to implement things its own way? An answer of Yes indicates slower processing of screen data. The slowest screen operation on my EGA equipped system is scrolling (runs about 16 millisec per text line), and scrolling can be caused by receipt of a line feed (rather than a carriage return). Loss of characters indicates the serial port interrupt could not be serviced before another character arrived at the port. Common delaying items include print spoolers, screen savers, and many other items, all of which tie on to the system clock tic interrupt and block interrupts for extended periods. If the display adapter also keeps interrupts off for milliseconds then things will get lost. When the screen is scrolled Kermit has a lot of work to do. Before scrolling it copies the top (or bottom, as appropriate to the scroll direction) line to an internal buffer, asks the Bios to do its slow screen scroll, and then if need be writes a new bottom (top) line from a buffer to the screen. MS Kermit 2.29a has a speedier algorithm for all of this; but still, the limiting factor is the Bios. If the display adapter were to turn off interrupts during its Bios scroll operation then that's that. The MS Kermit command Set Term Color 10 forces a fast screen update which may aid Kenneth; it causes snow on IBM CGAs. Regards, Joe D. ------------------------------ Date: TUE, 26 AUG 86 17:10:04 GMT From: C20228 @ UK.AC.PLYM.B Subject: Problems with Atari ST Kermit Keywords: Atari ST Kermit I have an ATARI 1040 ST with an ATARI C development kit. The kit has a version of Kermit based on the old VMS/UNIX Kermit. This works but is not really suitable for the uninitiated ATARI user (ie 1st Year Students). I therefore set out to implement Bernhard Nebels GEM KERMIT 1.02 which you have on file store at Lancaster. 1) Use VMS kermit to download the UUENCODED HEX files from LANC, get DECODE program in C to decode above file. Compile DECODE program and feed it the UUENCODED HEX files, results in KERMIT.PRG and KERMIT.RSC files now on disk. Execute KERMIT.PRG it doesn't work !!! ATARI turns up its toes and displays usual two bombs, then returns to desktop. 2) OK back to LANC file store, new message in 00BULL.TXT there is a new version of the DECODE program in assembler, to correct missing spaces problem. Right download it, and another copy of UUENCODED HEX file for good mesure. Assemble DECODE program OK, now run it and feed it UUENCODED HEX files, results in KERMIT.PRG etc etc.... execute Kermit ATARI experiences fatal error, usual two bombs displayed, program returns to desktop. 3) OK now I'm really mad, back to LANC filestore. Transfer whole of ATARI C source code (didn't really want to do it this way, but!). Write BATCH file to compile all C source modules, link modules, KERMIT.PRG now appears on the disk. Execute KERMIT.PRG ATARI treats us to a wonderful display of random graphics and dither patterns, stand admiring random graphics for a while before remembering that we are supposed to be running KERMIT. Try to regain control of ATARI, to no avail, even reset leaves the machine with a duff hard disk driver, finally resort to powering down and re-booting. Repeat above three procedures on and off for about a week. finally give up in disgust!!!!! CAN ANYBODY HELP!! Chris Rose Micro-Support Plymouth Polytechnic. [Ed. - This is a good example of the paradox of Kermit -- you can't get it unless you already have it... Has anybody succeeded in making this work? Maybe a .boo file would be better than a UUENCODE file -- at least .boo files don't have trailing blanks, and there's a .BOO-file decoder written in C (KER:MSBPCT.C on CU20B). It would also be most helpful if someone could volunteer to ask as a provider of Atari ST Kermit diskettes, or to induce an Atari user group to do it. If this happens, please tell us, so we can refer people who ask us.] ------------------------------ Date: Sat, 23 Aug 86 09:31:28 pdt From: gould9!joel@nosc.ARPA (Joel West) Subject: Problems with MacKermit 0.8(34) Keywords: Mac Kermit I've been using MacKermit for 1.5 years now and am very pleased overall. I use it every day even though I own two commercial (MacTerminal and Microphone) programs which sit unused. But... (You knew this was coming) I'm having trouble with my MacPlus: 1) The Receive dialog box is not compatible with HFS and looks quite bizarre. 2) I was unable to map keys on the Plus to other values. (Has anyone else tried this?) My previous mappings from my 512 days work fine, though. [Ed. - All of our Macintosh programmers disappeared after 0.8(33). The current version, 0.8(34), consists mostly of VT102 emulation improvements by Davide Cervone of the U of Rochester. No work has been done to accommodate the Mac Plus. It has been suggested that the resource file can be edited to make the Receive-file box look right for the Mac+, by making it the same size as the Send-file box. The keypad stuff mostly works fine with the Mac+ (at least on ours), provided you start with the VT100 Keypad startup file that's supplied on our distribution diskette, and on CU20B as KER:CKMVT1.HQX (and .DOC).] Also, a lingering nit-pick from day one: When starting a new file, the transaction dialog box should pull down the "Transferred OK" message from the previous file, as it is confusing to tell whether the msg is left from the previous file or is a status on the current file. If there are any lingering key problems on the European macs or the Plus, I would recommend the article "Be a Keyboard Sleuth" (by Joel West) in the August 1986 MacTutor. I can supply a paper copy to anyone who's interested in doing further work on MacKermit or K-Config. Joel West MCI Mail: 282-8879 [Ed. - Mac Kermit does indeed need work. The major thing that needs to be done to it is translation to a native Macintosh C compiler, so that a VAX or other Unix system with the SUMACC tools is not required to modify the program. Several people have expressed an interest in doing this, but I don't think anyone has really started. Also, there doesn't seem to be any concensus as to the best C compiler for the job. Suggestions welcome, volunteers even more welcome!] ------------------------------ End of Info-Kermit Digest ************************* ------- 19-Sep-86 17:39:59-EDT,21262;000000000000 Mail-From: SY.CHRISTINE created at 19-Sep-86 17:39:03 Date: Fri 19 Sep 86 17:39:03-EDT From: Christine M Gianone Subject: Info-Kermit Digest V5 #10 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12240264133.23.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Fri, 19 Sep 1986 Volume 5 : Number 10 Today's Topics: Alternate BITNET Kermit Distribution at University of Toledo Os9 Kermit from os9 Users Group Using C-Kermit on VAX/VMS for Mail Spooling MS-DOS Kermit with Different Character Sets More on Wanted: Kermit for the Apple][ Help with Installing VMS Kermit VAX to PC Binary File XFERS MVS/TSO and Apple II Kermit Gluts Problems with Atari ST Kermit Uuencoded Files and Trailing Blanks ---------------------------------------------------------------------- Date: Fri 19 Sep 86 14:31:37-EDT From: Frank da Cruz Subject: Alternate BITNET Kermit Distribution at University of Toledo Keywords: BITnet The collection of Kermit files at the University of Toledo VAX-11/785 is now being updated on a weekly basis. BITNET sites that have trouble getting a response from CUVMA (due to congestion) are welcome to try KERMSRV at UOFT02. To get started with KERMSRV (at either CUVMA or UOFT02) give the command: SMSG RSCS MSG xxxxx KERMSRV HELP (from CMS) or SEND KERMSRV@xxxxx KERMSRV HELP (from VAX/VMS with Jnet) where "xxxxx" is either CUVMA or UOF02. Thanks to Brian and to the U of Toledo Computing services for helping to ease BITnet congestion. ------------------------------ Date: Fri 19 Sep 86 05:52:04-PDT From: Bob Larson Subject: Os9 Kermit from Os9 Users Group Keywords: Os9 Kermit Os9 kermit is available from the Os9 users group as disk 48. (The latest disk listing I have from them has this mislabeled as 68k only and lists disk 37 as the 6809 version. The version on disk 37 has quite a few bugs that are fixed in the version on disk 48.) Since several things are determined at compile time, it's a good idea to have the C compiler available even if they claim to supply a compiled version. Membership in the Os9 users group is $25/year and includes disk 0 and MOTD their monthly newsletter. Send Name, address, computer type, os9 type and level, and disk format to: The Os9 Users Group Attn: Membership 9743 University Ave. Suite 330 Des Moines, IA 50322 Disk orders from members should be sent to the same address, Attn: Disk order. Disks are $5 for 5", $8 for 8", $80 for the works on 5" 80 track DSDD standard os9. Disk orders are accepted from members only. [Ed. - Thanks for the information. This Users Group has been added to our KER:AADISK.HLP file, with the terms outlined.] ------------------------------ Date: Tue, 16 Sep 86 09:44:36 pdt From: varian!david@lll-crg.ARPA Subject: Using C-Kermit on VAX/VMS for Mail Spooling Keywords: C-Kermit, VAX/VMS Kermit, Scripts We use C Kermit (058) under VMS here. I wrote some scripts that run kermit unattended in order to send mail from UNIX to VMS. [Ed. - Thanks for the scripts! Since they are rather long, we've put them in the Kermit distribution as CKVKER.SCR.] ------------------------------ Date: Wed, 13 Aug 86 16:40 N From: Kimmo Laaksonen Subject: MS-DOS Kermit with Different Character Sets Keywords: MS-DOS Kermit, Character Sets The internal translation feature allows MS DOS Kermit user to change external character codes to MS DOS internal codes within Kermit, and vice versa. This feature is mainly intended for text display and file transfer in non-English speaking countries, where "national" characters in a remote host are assigned to codes that have another graphics representation in a "standard", ie. Anglo-American, character set (some "standard" graphics are replaced with national grahics - in terminals, line printers, etc.). In a PC there is an extended character set, where both "standard" and "national" characters can be intermixed in text files. The internal translation supports full 8 bits, so it can be used to map different 8 bit character sets to each other, too, like the DEC set (eg. in VT200 series) to the IBM PC set and vice versa. Without translation a text file prepared on the remote host will look strange because the PC will display the "standard" graphics instead of the national graphics, when the file is typed on PC screen via Kermit terminal emulator, or when it is transferred to PC as a file with Kermit and then looked upon with a text editor in PC. Respectively a text file prepared in a PC and transferred with Kermit to a remote host looks strange because different codes are used to represent national characters in remote host output devices. MS DOS Kermit internal translation is an elegant solution to this situation. There certainly exist separate programs to do the necessary code conversions. One problem with them is that at least twice the file space is required, which may turn out to be impossible in a PC if the file is large. Another problem is the extra time required for running a separate conversion program. Translation overhead within MS DOS Kermit is negligible. Translation does NOT affect the Kermit protocol, ie. translation is done outside Kermit packet assembly/disassembly. The new commands for translation are: SET XLATION object [parameter(s)] The following objects are available: ALL Affects all translations. Valid parameter values are ON or OFF. ON is the default ! DISPLAY Controls translation of characters received DURING Kermit terminal emulation, ie. what is displayed on the screen. Does not (should not?) affect terminal controls, eg. ESC sequences. PRINT Controls translation of characters received and output to printer DURING Kermit terminal emulation. SEND Controls translation when transferring files FROM the PC. RECEIVE Controls translations when transferring files TO the PC. Parameters: OFF Turns translation OFF for the selected object. Respective translations must be OFF to properly SEND and RECEIVE binary files, eg. .EXE, .COM, etc. ON Turns CURRENT translations on for the selected object. The Finnish convention is the default for all translations (guess why). INITIAL Resets a translation table to an identity table ie. all possible 8 bit codes are translated to them selves. It is good practice to initialize a translation table before starting to build a new translation. EXPAND Copies the lower half, ie. first 128 translations, to the upper half of the selected translation table. This is a useful feature when only the 7 lower bits (as in ASCII) are meaningful and the 8th bit (ASCII parity) is a "don't care". CODE base nnn base nnn This parameter is used to actually set up a SINGLE translation in the selected object's translation table. The first pair (base nnn) is the original code. The second pair is the code to which it is to be translated. Base can be any of DEC (decimal), HEX (hexadecimal), or OCT (octal). The actual code (nnn) is a number in the selected base. In addition there is a new command for terminal emulation: SET EIGHBIT value It controls whether MS Kermit strips the 8th (normally parity) bit (value = OFF, the default) during terminal emulation, or if all 8 bits are used (ON). Passing all 8 bits is useful when 2 PCs are connected together, or when connected to a DEC VAX VMS set to pass all 8 bits. Note that the DISPLAY and PRINT translations are applied (if ON) AFTER the 8th bit is stripped off or passed on as it is. Some notes: The MS DOS Kermit translation is not intended for a lay operator. It would be best if somebody at a site prepared command file(s) to set up (and enable) the required translations. It is usually too tedious to give a note listing the necessary Kermit commands that a user has to type in, although it's possible. TAKE, or even using MSKERMIT.INI, is much easier. Anyway, since we didn't touch the SET KEY facility, it is customary to include tailored keyboard "translation" command files in local Kermit distribution floppies, so adding a few new files (or including them in SET KEY command files) for the translations suits that custom well. Some may think that the ability to define only a single translation for a single object at a time is too slow, but usually there are not so many of them, well under 10 for the Finnish character set, for example. Even mapping a full 8 bit set to another, eg. DEC character set to IBM PC, and vice versa, doesn't require modification of all 256 codes. And when the translations are set up, they are normally loaded from a file, which doesn't take long. We have translation files for the Finnish language and IBM PC (of course!), including SET KEYs, which we can send to Columbia for redistribution. However, we think it's better to postpone sending anything yet, because our additions to MS Kermit were done on the 2.27 version! We think it's better to wait until we have added them to 2.29. After that we hope that translation becomes a standard feature in MS Kermit to keep all us non-AngloAmericans happy. If you REALLY want something fast, send queries to: LK-KLE@FINHUT.BITNET, or KLAAKSON@FINFUN.BITNET (We are connected to EARN/BITNET, only.) [Ed. - Sounds like you've really attacked the problem head-on. Still, it's going to be tough to make everybody happy. On the one hand you've got all the different character sets -- Finnish, Swedish, German, Spanish, etc. -- and on the other you've got all the different hardware -- the IBM character ROM, the DEC version (with its multifarious "country kits"), presence or absence of all different, incompatible graphics boards, etc. I can visualize having dozens, maybe hundreds, of character-set files to adapt each alphabet to each kind of hardware. And then we have to deal with people's personal preferences about which key should transmit which code... But still, this sort of thing is badly needed in the non-Anglo-American world. What do people think? Kimmo, maybe when you get your hands on 2.29a (when it's finally released) you can try installing your translation code, keeping these questions in mind. Like, maybe there's a way to combine many mappings into one compact file...] ------------------------------ Date: 4 Sep 86 02:37:48 GMT From: umcp-cs!cvl!umd5!zben@SEISMO.CSS.GOV (Ben Cranston) Subject: More on Wanted: Kermit for the Apple][ Keywords: Apple II Kermit, Uppercase Terminals Some people suggested that although they have other means of transfering stuff from their Unix machines to their Apples I should post Kermit anyway. So I sat down and started to upload the source. I didn't get very far. The Apple ][ that I use doesn't have lower case. Unix is not very friendly to upper-case-only terminals that try to use Kermit. (To try it yourself, next time you sign on, type your userid in upper case.) [Ed. - What Kermit are you using on Unix? C-Kermit handles the uppercase environment just fine, at least on 4.2BSD -- uppercase filenames map to lowercase, etc, and since during file transfer the line is open in rawmode, the Unix terminal driver's uppercasing does not interfere with the packets.] I got it uploaded to the Sperrysaur which is a case insensitive machine. Unfortunately it doesn't like lines longer than 132 characters so I'm gonna hafta do moby "join" commands when I get it FTPed up here. But this exposes a pathological problem. It probably works if you have the lower case stuff, but what should the response of Kermit be to an unmodified Apple? Should there be a force-to-lower-case option? Suggestions? Oh, the other feature this Kermit has is a 70 column display-to-hires option. It doesn't make it on a color TV, but it's barely tolerable on my B/W set. On a video monitor it should be better... umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92 umd2.BITNET "via HASP with RSCS" ------------------------------ Date: 9-SEP-1986 10:17:43 From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK Subject: Help with Installing VMS Kermit Keywords: VAX/VMS Kermit We've had some discussions in the UK newsletter lately with people having trouble installing VMS Kermit and its help files on VMS. A couple of people have contributed some ideas and command procedures to help the non-VMS expert: I have them online here as VMSINS.HLP Alan [Ed. - Thanks! This file is in KER:VMSINS.HLP on CU20B.] ------------------------------ Date: 16-Sep-1986 0539 From: fulton%comet.DEC@decwrl.DEC.COM (Cathy Fulton -- CXO Technical Training) Subject: VAX to PC Binary File XFERS Keywords: VAX/VMS Kermit In response to the recent messages about transferring VMS binary files with Kermit... I xfer VMS binary files to and from a PC all the time using Kermit. Well, they're not really binaries, but hexified forms of binaries. There are two programs, VMSHEX.MAR and VMSDEH.MAR, which are used to hexify and dehexify any VMS binary. You first hexify the file with VMSHEX and then Kermit it to the destination. The hexified file is a normal ASCII file, so SET FILE TYPE TEXT. Upon Kermiting the file back to a VMS system, run VMSDEH on it to restore the file to its original state. - Cathy [Ed. - Preprocessing is always a way around this kind of thing. VMSHEX & VMSDEH not only hexify & dehexify the file, but preserve & restore the FILES-11 stuff. If you're going from VAX to VAX, you can also use Kermit to send BACKUP save sets back & forth. Still, it should be possible to transfer fixed 512-byte-block binaries with Kermit-32, at least that's what it says in the documentation. Maybe this could be a hot topic at the DECUS Kermit session.] ------------------------------ Date: Tue, 16 Sep 86 21:19 EST From: CDTAXW%IRISHMVS.BITNET@WISCVM.WISC.EDU Subject: MVS/TSO and Apple II Kermit Gluts Keywords: MVS/TSO Kermit, Apple II Kermit We have been using a very nice MVS/TSO version of Kermit written in assembler by Steve Blankenship of TUCC. He has modeled this after CMS Kermit, and it the nicest, most powerful version we have run across for an MVS/TSO site. It supports communications both through 3705/3725 front ends and Series 1/7171 front ends and includes a server mode, initialization and take files, optional log files, tab expansion, etc., etc. Steve and Roger [Fajman] (of NIH) have been put in contact with the hope that the two versions and the two authors could hash things out to come up with a definitive MVS/TSO standard version. Let's hope for the best. [Ed. - Indeed they are in contact, and there will be at least one or two releases soon, and there's a good chance that one or more of these will be consolidated with CMS Kermit at some time thereafer.] As for Apple II Kermits, both Ted Medin and Dick Atlee have been working on very nice 80-column versions. Ted's runs under DOS 3.3 and ProDOS and is just about complete (although some distribution has already started on some Apple II mailing lists). From what I have seen of the source, it is being done with the CROSS assembler. Dick's version, as far as I know, is only DOS 3.3, although it is done in Big Mac assembler - an advantage. He has been very busy lately, and I don't know how he is coming with it. Both myself and two other people I know of have been trying to work with Dick for ProDOS versions of his work. Again, in this case it would be very nice to consolidate all of this work to one, nice version - although the release of the Apple //GS will probably make that two versions now. [Ed. - Ted's version has been received at Columbia, where Peter Trei, the other Apple II Kermit person, has been trying to merge it with his own latest version. How this will stack up against -- or eventually be consolidated with Dick's version remains to be seen.] A major problem with versions for machines such as the Apple is the non-communication with Columbia on distribution and availability. If Apple II users could follow the example (I hate to say this) of MS-DOS users, the whole group would benefit. Take version 2.29A of MS-Kermit as a solid example of what can happen when people cooperate to produce one, good piece of software. Sorry for the verbosity, but this is a subject about which I feel very strongly, and thus far my efforts to persuade people to work with and through Columbia for their own sakes and for the sake of the best Kermit versions possible have been met with much adversity (in the micro world). Any suggestions on this topic would be appreciated. Thanks for letting me blow off some steam. Mark [Ed. - Yes, people should consult with Columbia before starting work on a Kermit program to avoid this kind of duplication of effort, not to mention filename conflicts and other lesser headaches. However, even when they do, sometimes things fall through the cracks. Anyway, we try to keep a record of everybody who's working on everything in the file KER:AAWAIT.HLP, and everyone who's interested in forthcoming versions is welcome to take a look at it.] ------------------------------ Date: 19 Sep 86 09:26:06 EDT (Fri) From: Michael Fischer Subject: Re: Problems Installing Atari ST Kermit Keywords: Atari ST Kermit I had problems installing GEM Kermit, too, but I finally got it to work. Here in a nutshell are what the problems were: 1. The UUDECODE program distributed with Kermit (astuud.c) is written for the Lattice C compiler. To use it with the Alcyon C compiler distributed with the Atari Developer's Kit, it is necessary to open the binary output file with "fopenb" instead of "fopen"; otherwise, the file is opened in text mode (ignoring the "b" mode flag") and every ^J in the output has a gratis ^M inserted after it. 2. Recompiling the sources as Chris Rose did is not sufficient, for the resource files are *only* distributed in binary form. A correct program given a bad resource will crash, just as an incorrect program will. Thus, one has no choice but to get UUDECODE to work. 3. Once I fixed UUDECODE, I successfully decoded both the Kermit program and resource files and they worked without problem. I also rebuilt the program from the sources and it also worked with the decoded resource file. 4. There has been a great deal of activity lately on the INFO-ATARI16 bboard discussing the various problems people have been having with UU-encoded files. There seem to have been two or three independent sets of problems: (a) Bugs in the UUDECODE program to run on the ST as described above. (b) Problems with the encoded file being modified during transmission such as tab expansion, truncation of trailing blanks, or padding of all lines to a given length. (c) For people who tried decoding on a mainframe and then transmitting the binary files to the ST (often using the old Developer's kit Kermit), forgetting to set binary mode on both the transmitting and receiving Kermit. After numerous reports of failures and then people bringing these problems out in the open, success stories such as mine above began pouring in. So UU-encoded files *are* usable, but it can be rather tricky to do it right. I will contact the "New Haven ST's" user group to see if they would be willing to copy GEM Kermit onto disks for people. Mike Fischer [Ed. - See next message for another hint.] ------------------------------ Date: Sat, 13 Sep 1986 12:40 MDT From: WANCHO@SIMTEL20.ARPA Subject: Uuencoded Files and Trailing Blanks Keywords: Uuencoded Files I made a small experimental change to our version of uuencode to solve the truncated trailing blank problem and it turns out to be transparent to uudecode. That change is simply to insert a "M" to each uuencoded line just prior to the insertion of the CRLF. BITNET users accessing our system through our mail file server have voiced no complaints since I made that minor change. --Frank ------------------------------ End of Info-Kermit Digest ************************* ------- 25-Sep-86 18:11:13-EDT,17282;000000000000 Mail-From: SY.CHRISTINE created at 25-Sep-86 18:09:44 Date: Thu 25 Sep 86 18:09:44-EDT From: Christine M Gianone Subject: Info-Kermit Digest V5 #11 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12241842583.197.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Thu, 25 Sep 1986 Volume 5 : Number 11 Today's Topics: New Release of QK-KERMIT (MsDos and CP/M Kermit in Turbo Pascal) New Release 1.6 of KERMIT/TSO Motorola Kermit New IBM and Rainbow .BOO Files for MS-DOS 2.29a MS-DOS Kermit 2.29 Question VMS File Attributes and KERMIT Timing out on CMS Re: Kermit BOO for HP Integral? UNIX SYS/V Version of Kermit? UUCP and Kermit Server at Okstate returns to life Kermit for C128? ---------------------------------------------------------------------- Date: Mon, 22 Sep 86 16:27 EDT From: VIC@QUCDN Subject: New Release of QK-KERMIT (MsDos and CP/M Kermit in Turbo Pascal) Keywords: QK Kermit, Turbo Pascal I am sending you version 2.6 of QK-KERMIT (an MsDos and CP/M Kermit program written in Turbo Pascsal.) In addition to the new Pascal source, I have sent the following files: 1. hex file for MsDos (IBMPC) kermit with VT100 emulation. 2. hex file with overlay file for a kermit with VT100/TEK4010 emulation. 3. hex file for a KayproII kermit. 4. updated installation documentation 5. updated user documentation. Both the MsDos versions will also contain code to handle the APL character set. You should replace the old files with the new files. The old files which I didn't send are the same for the new version. There is also a new QKKER.SCR (Script source for the documentation) will also be sent. [Ed. - Thanks, Vic. The new files have been installed in KER:QK*.* on CU20B, and in BITNET KERMSRV on CUVMA as QK* *.] ------------------------------ Date: 23 Sep 86 14:15 CET From: Fritz Buetikofer Subject: New Release 1.6 of KERMIT/TSO Since May 86 some bugs in the version 1.4 have appeared. And furthermore some new commands have been implemented: * Bugs fixed and error handling improved in the routine which checks for the presence of a file (Check_Dsn). * New command TAKE to execute KERMIT-commands from within a file. * When displaying STATUS screen, you will find a notice, whether the INIT-file (KERMIT.SETUP) has been found or not. * New command SET ATOE/ETOA to modify the ASCII <-> EBCDIC translation tables, while running KERMIT. * New command SET INCOMPLETE, to specify what has to be done with a file when user aborts the transfer. * Update of SEND command, so that the user may specify a filename, which is sent to the micro (instead of generating one automatically). Only the Pascal source file and the documentation were changed. For the very near future, I'm going to implement a STATISTICS command, handling of attribute packets and (maybe) long packets. Regards to all TSO freaks, F.Buetikofer, University of Bern (Switzerland) [Ed. - Thanks, Fritz! The new files are installed as KER:TS2KER.PAS and KER:TS2KER.DOC, replacing the old version, on CU20B for anonymous Internet FTP, and TS2KER PAS and TS2KER DOC on CUVMA for BITNET KERMSRV access. This version of MVS/TSO Kermit works only on linemode (3705-style) connections, but it has many more features than the original TSO version. Meanwhile, watch Info-Kermit for announcements of at least two other new TSO Kermits on the way, both with many advanced features, and both able to operate over both linemode and Series/1-style connections.] ------------------------------ Date: 22 sep 86 17:07 GMT +0100 From: Subject: Motorola Kermit Keywords: Motorola Kermit, 68000 After experimenting the high reliability of the Kermit file transfer protocol, I promoted its utilization in my department. Since we make a heavy use of Motorola microprocessors I am writing a Kermit implementation for 680xx processors based systems. The language used is assembly, and I think it may be processed by most assemblers following the syntax defined by Motorola (I proved the 2500 A.D. 68000 cross assembler, the Motorola MC68000 cross assembler and the CERN M68MIL cross macro assembler). The key principle of this Kermit implementation is machine independence (obviously stated that the processor belongs to the 680xx family). The system dependent part is composed by a few routines, containing all the knowledge about the system's file structure and I/O ports. The program is thoroughly documented, thus allowing the implementors to modify it easily, according to their need. This Kermit implementation has been written in order to be installed also on those 680xx family based machines, which have no or not-standard operating system, being often custom built for the solution of specific processing problems. At least in the high energy physics field, that frequently happens. I think that the first version of the program will be ready in 1 or 2 months. If you are interested in it, I would be glad to send it to you, so that you can distribute it. Roberto Bagnara Physics Department Bologna University via Irnerio, 46 40126 BOLOGNA ITALY DECnet address: 39948::MICRO Bitnet address: RBG.XX@GEN.BITNET [Ed. - This will be announced when it is received.] ------------------------------ Date: 21 SEP 86 18:24-MDT From: JRD@USU Subject: New IBM and Rainbow .BOO Files for MS-DOS 2.29a Keywords: MS-DOS Kermit MSTIBM.BOO and MSTRB3.BOO are identified as MS Kermit 2.29 test 21 Sept 1986. The items of note are: - new command to control width (7 or 8 bits) of characters displayed in non-file-transfer mode: Set Display Regular | Serial | Quiet | 7-bit | 8-bit 7-bit is the default width. Any two keywords above can be used together on the same command line. The Status display also shows the Regular etc type plus the 7-bit or 8-bit tag. 8-bit is ineffective if parity is other than None. - Set Send Packet ### has been modified slightly to use this command to set the ultimate upper limit the size of outgoing packets. The default value is 1000. The Status screen still shows the active, negotiated, size. In practice this means MS Kermit will send packets of size "other end's requested size" or the Set Send Packet value, whichever is smaller; thus the user need not do anything to send long packets to an appropriate host. However, MS Kermit requests only standard 94 byte packets be sent to it unless the user specifically requests another length by giving the command Set Receive Packet ###. The limit of 1000 bytes is arbitrary and can be enlarged by changing the single parameter "maxpack" located in the header file and rebuilding; two lines of Help in mssset.asm should also be edited to match the readjusted maxpack value. - Bug fixed: incompletely received files were not deleted when a transfer was prematurely terminated. - Bug fixed: VT102 emulator did not always correctly position the cursor within a restricted scrolling region when the escape sequence ESC top; bottom r was received. Regards, Joe D. [Ed. - Thanks, Joe! The new files replace the old ones as KER:MST*.BOO (and KB:MST*.EXE) on CU20B and MST* * on CUVMA. This should pretty much complete the list of new functions for 2.29a; leaving only the tedium of bringing all the other versions up to this level and testing them, and then bringing the manual up to date...] ------------------------------ Date: Mon, 22 Sep 86 19:47 EDT From: Michael G. Chan Subject: MS-DOS Kermit 2.29 Question Keywords: MS-DOS Kermit Is there any way to patch MSKermit to recognize the 43 lines mode of an EGA? I can put the display in 43 lines mode but MSKermit always put the status line on the 25th line when connected. Thanks Michael Chan chan@duke [Ed. - From JRD: There are no quick patches even though most of the code is written for arbitrary sized screen. Some parts are specific about line numbers (location of the status line, for example). Also, my experience has been that 43 line mode is such a hybrid (ega vs the rest of the Bios and DOS) that it may not function well on machines having two display adapters; I have such a situation. For a while I considered including more specific ega mode support but quit when the quirks became too much. EGAs were designed with most registers being write-only. Thus, the ega needs to be managed; in turn, that is tough to do properly within an applications program containing an inner program (terminal emulator).] ------------------------------ Date: 19 Sep 1986 2127-EDT From: "Bernie AT&T:617-467-5664 LDP Workstations" Subject: VMS File Attributes and KERMIT Keywords: VMS Kermit With a 'little bit' of trickery it's possible to send any file from VMS to any other system and back to VMS. Single files : Use LZCOMP/LZDECOMP {base language C - an implementation of Lempel-Ziv- Welch compression} in {non-portable} VMS-specific mode. In this mode RMS-attributes are carried and reestablished at decompression. Use KERMIT to move the file. Collection of files : Use VMS BACKUP to generate a single 'Backup' save-set and then a. LZCOMP/LZDECOMP {see above} or b. VMSBAK.BAS {source language BASIC} to 'restructure' the blocking of the save-set to KERMIT's 512 bytes fixed records. Then use KERMIT to move and VMSBAK again to de-block back to original blocking {restriction - original blocking has to be multiple of 512!!. .. last {but not least} single and multiple files Use Stevens Institute's VMSHEX and VMSDEH {source language MACRO} - and transmit the resultant 'hexified' files via KERMIT. This method (although the oldest) will generate the largest files for trans- mission via KERMIT and could therefore be the slowest one. BTW 'standard' VMS executables can also be 'moved' by telling the 'receiving' KERMIT 'SET FILE TYPE FIXED'. However the above three 'choices' will work in all cases - since LZCOMPRESS, BACKUP and VMSHEX all include RMS file descriptors in the encoded file and reconstitute same. [Ed. - Thanks, Bernie! The VMSBAK.BAS program was already in the Kermit distribution, and now the LZW-compression programs have also been added, as KER:VMSLZ*.*; the file KER:VMSLZ.HLP explains the organization and contents of the files. The programs are written in C, and may be compiled under VAX/VMS with VAX-11 C, on PDP-11s with DECUS C, or under Unix. Thanks to Martin Minow of DEC for adapting 'compress' to the DEC operating systems.] ------------------------------ Date: Mon 22 Sep 1986 16:26:54 CDT From: Dan Theriault Subject: Timing out on CMS Keywords: CMS Kermit Some of our users here type Kermit Receive on CMS and then realize too late that they forgot their PC Kermit at home or whatever. The result is that they can't get out of Kermit so what they often end up doing is hanging up their telephone and run disconnected on CMS for days. They often wind up using 80 percent of our CPU as Kermit searches and searches and searches for an incoming file. I've looked at the source to our Kermit and I found a variable that claims to be the time-out counter for Receiving, but nothing I've done causes it to work. Any help? Dan Theriault University of Illinois at Urbana-Champaign [Ed.- From John F. Chandler The normal method of escaping from a Kermit protocol wait is to type a bunch of CR's at Kermit. The number required will depend on the context: for the initial packet exchange, the retry threshhold is 16, but after that the threshhold is determined by the SET RETRY command (default 5). There is no need to set aside some special sequence of characters to abort a transfer "by hand"; all it takes is the patience to type 16 carriage returns.] ------------------------------ Date: Fri, 19 Sep 86 11:33:29 cdt From: seismo!uiucdcs!uxc.CSO.UIUC.EDU!zinzow@columbia.edu (Mark Zinzow) Subject: Re: Kermit BOO for HP Integral? Keywords: HP Integral Kermit It seems the only boo files for Ckermit are for machines like the Amiga. The HP does not come with a c compiler so having a boo file available from kermsrv would be desirable. [Ed. - Can anybody send in a Kermit .BOO file for this system?] I was very happy when MSTIBM.BOO made it over the net. Does anyone have an application to run on an IBM mainframe using a 7171 or Series/1 type front end, that utilizes the new print support for local printing of a mainframe file (under VM/CMS) with kermit on the PC? Mark S. Zinzow ARPA: zinzow@uiucuxc.CSO.UIUC.EDU Research Programmer BITNET: MARKZ@UIUCVMD.BITNET Computing Services Office UUCP: ihnp4!pyrchi!uiucuxc!zinzow University of Illinois at Urbana-Champaign ------------------------------ Date: 15 Sep 86 20:25:20 GMT From: jc@cdx39.UUCP Subject: UNIX SYS/V Version of Kermit? Keywords: UNIX Kermit Does kermit now cooperate with uucp? That is, does it know how to create the uucp lockfiles for a device, so that uucp won't wake up and stomp on kermit's toes? Of course, if it doesn't, it would be easy enough to modify kermit, if only we had the source. [Ed. - Yes, C-Kermit includes code to "cooperate" with uucp. BUT... Every version of Unix wants this to be done a different way, and every site tends to change it again. And then come the perennial questions: what is the name of the lock directory? what are the lock files called? should the lock directory be publicly writeable, or should Kermit be sutuid'd or setgid'd to it? Should the lock file be empty, or contain the pid of the process that has line locked. A quick look at ckutio.c (yes, the sources are widely available, e.g. see next message) will show just some of the variations on these themes, as will a perusal of many past issues of this digest...] ------------------------------ Date: Sun, 21 Sep 86 15:18:51 -0500 From: Mark Vasoll Subject: UUCP and Kermit Server at Okstate returns to life Keywords: Okstate, UUCP The UUCP and Kermit Server services at the Oklahoma State University Department of Computing and Information Sciences are back on the air again. The information in the okstate.txt blurp still contains the correct access information. One side note though, since we reactivated the dial-in line on Sept 16th, someone's system has been dialing us every 15 minutes, 24 hours a day and using the uucpker login and password. Since this type of thing is easily automated and forgotten, and since the system in question doesn't get far enough into the UUCP protocol to identify itself (so I could send the system manager a mail message), I am making this public plea for everyone who even *might* have something like this set up to go take a look before your phone bill hits the mega buck level. Thanks, Mark Vasoll Department of Computing and Information Sciences Oklahoma State University Internet: vasoll@a.cs.okstate.edu Obsolete: vasoll%okstate.csnet@csnet-relay.arpa UUCP: {cbosgd, ea, ihnp4, isucs1, pesnta, uokmax}!okstate!vasoll ------------------------------ Date: Fri, 19 Sep 86 20:47:40 EDT From: mek%UMass.BITNET@WISCVM.WISC.EDU Subject: Kermit for C128? Keywords: Commodore Kermit Are there any plans for a version of KERMIT-65 for the COMMODORE 128 in 128 mode? I have all kinds of problems with the COMMODORE 64 version, and it would be very convenient, I think, for all COMMODORE 128 users to have a 128-mode version. An ideal program would be one similar to the other kermits, but one that redefined the 128 character set for special unix-type characters (backslash, curly braces, tilde, etc.), worked in 80-COLUMN mode, emulated a VT-52, and could take advantage of the 8502 microprocessor's 2-MHZ speed, at least during actual file transfers, and prefereably always when in 80-column mode. If anyone has plans for this, I would be happy to help out. I don't know 6502 assembly language, but I do know BASIC, Pascal and C quite well. If anyone knows of any plans for a 128 version, please let me know! Thanks! Matt Kimmel, MEK@UMASS.BITNET MEK%UMASS.BITNET@WISCVM.ARPA ------------------------------ End of Info-Kermit Digest ************************* ------- 6-Oct-86 17:34:20-EDT,18576;000000000000 Mail-From: SY.CHRISTINE created at 6-Oct-86 17:32:22 Date: Mon 6 Oct 86 17:32:22-EDT From: Christine M Gianone Subject: Info-Kermit Digest V5 #12 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12244719365.290.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Mon, 6 Oct 1986 Volume 5 : Number 12 Today's Topics: New Release of Kermit-11 Available Another 2.29a Prerelease Atari ST Kermit on Diskette in the UK BOO files vs UUENCODE Suggestions for MS-Kermit Screen Saver Feature as part of Kermit. MS-Kermit on 80386 Found on net.bizarre ---------------------------------------------------------------------- Date: Fri 26 Sep 86 15:31:53-EDT From: Frank da Cruz Subject: New Release of Kermit-11 Available Keywords: Kermit-11, K-11, PDP-11 Kermit This is to announce Version 3.54 of Kermit-11 for PDP-11s or Pro-3xx's running the various DEC operating systems (RSX, RSTS, RT, P/OS, etc) or TSX+, from Brian Nelson at the University of Toledo (BRIAN@UOFT02.BITNET). New features since the last release, 3.50 (April 1986), include: . Command line editing and recall controlled by arrow keys. ";" and "!" may be used to delimit comments. . Handling of DEC multinational 8-bit ASCII text files. . New SET FILE NAMING options. . New SET SEND [NO]XON command, to prefix every packet with an XON to fight pathological problems with flow control. . Minor bug fixes and cleanups. . Some RT11/TSX+ specific modifications: Reduction in the size of the root for XM to facilitate running Kermit as a foreground task. Complete rewrite of terminal emulation, specifically to enhance the support of the XL/XC/CL handlers. It is now completely event driven thus performance should be improved as well as presenting a much lower load on the CPU. It should also function better under SJ. Restructuring buffer allocation to (1) Reduce the root size for XM, and (2) To enable the USR to swap over buffers for SJ and FB. This will eliminate Kermit crashing on USR requests in 95% of the cases for SJ and FB systems with minimal background memory available (ie, many devices in the system and/or large RMON). Control C delivery has been improved by adding a watchdog timer to check for control C's as RT11 does not generate an AST on control C. The new files are available via anonymous as KER:K11*.* on CU20B and over BITNET via KERMSRV at both CUVMA and UOFT02. The file K11INS.DOC contains installation instructions, K11AAA.AAA is a read-me file, and K11FIL.DOC is a (slightly dated) annotated list of the Kermit-11 files (of which there are about 111, totalling about 3.8 megabytes in size). The file K11CMD.MAC contains the detailed update history. ------------------------------ Date: Thu 2 Oct 86 10:10:32-EDT From: Frank da Cruz Subject: Another 2.29a Prerelease Keywords: MS-DOS Kermit A new copy of MSTIBM.BOO is available for testing. This one fixes a bug with VT100/102 emulation when rubout (DEL) characters are received -- some screen editors send these as padding, and they were erroneously causing characters to disappear from the screen during editing. Also, display of login script text in 8-bit ASCII even when parity is in use or display is set to 7 bits no longer occurs. The new files are in KER:MSTIBM.BOO and KB:MSTIBM.EXE on CU20B for anonymous FTP, or in MSTIBM BOO on CUVMA for BITNET KERMSRV access. Thanks to Walter Bourne of Columbia for pointing out the problems, and to Joe Doupnik for fixing them. The final release of 2.29a should be ready in a week or two. ------------------------------ Date: 29-SEP-1986 15:06:20 From: SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk Subject: Atari ST Kermit on Diskette in the UK Keywords: Atari ST Kermit A colleague in our Environmental Sciences Department with an Atari 1040ST has kindly volunteered to do some disc copying, so we're now able to supply the ST files on Atari format discs. Anyone interested should contact us on (0524) 65201 x 4881, or to SYSKERMIT@UK.AC.LANCS.VAX1 on JANET. I'm afraid this offer is to users in the UK and Eire only: we can't return calls or answer letters from other countries. ------------------------------ Date: Mon 29 Sep 86 11:57:26-EDT From: Frank da Cruz Subject: BOO files vs UUENCODE Keywords: .BOO files, UUENCODE [Ed. - The following message is in response to a question from Keith Petersen about whether BOO file format should be added to the the formats supported by the SIMTEL20 archive file server.] The main advantage of BOO files over UUENCODE files (except when Frank W's trick of putting a printable character on the end of each UUENCODEd line is applied) is that BOO files don't have blanks in them, so they don't get truncated by mailers, BITNET file transfer, etc. Also, BOO files don't have dots, which can cause problems when going through SMTP processes when the dot occurs in "column 1". Also, BOO files tend to be a little more compact; both BOO and UUENCODE use 4-for-3 packing, but BOO files also run-length encode strings of nulls. As Keith points out, neither encoding includes error checking; BOO files avoided that because of ASCII/EBCDIC considerations. Both BOO and UUENCODE encodings have a distinct advantage over LZW, Huffman, and other more efficient, but complicated, techniques: the decoding program is short enough to be typed in and used by the average PC owner. The BOO-file maker is written in C; BOO-file decoders are written in PC Basic, BASICA, MASM, Pascal, and C. These programs are available from CU20B as KER:MSB*.*. I'm not sure it's time to design yet another "standard" printable encoding for binary files, but here are some considerations, in case anyone is interested: The major reason for encoding binary files printably is to allow transmission on or through character-oriented media not designed for arbitrary 8-bit data. In particular, encoded files should pass freely through electronic mail, should be downloadable via dialup (possibly through public data network), and should be easily stored on and retrieved from magnetic tape. The encoding should be compact (to minimize time and expense of transmission) and simple (to allow the decoding program to be small enough for an individual to type in), and it should allow errors to be detected during "de-encoding". Since mail is often used to transmit these files, the decoding process should be able to skip past mail headers and find the real beginning of the encoded file. The encoded file should begin with a distinctive header containing at least the file's name, and possibly other attributes, and it should end with a distinctive trailer, allowing multiple files to be concatenated (archived?) together, and picked apart and decoded by a single run of the decoding program. Did I say "possibly other attributes"? I think we want to avoid anything system-dependent here. We should be shooting for a way to encode stream binary data, not structured files. If the file is to have structure (e.g. it is a DEC FILES-11 file, or a Macintosh application, or a VM/CMS VB-format file), then that should be imbedded in the data itself, and the encode/decode progam must know how to handle it. Did I say "archived"? I don't want to raise the spectre of yet another SQ/LIBR/SWEEP/ARC/etc/etc system. Especially not one in which (like ARC), the "archiving" program decides on the most appropriate encoding for each file (e.g. it would be overkill to turn assembler source into a BOO file). But the possibility of having more than one file concatenated together at least suggests that each file's header should contain not only the file's name, but also the encoding technique (including none). There should be an error detection mechanism that is independent of the character set of the host computer. It should be possible to encode the file on an ASCII system and decode it on an EBCDIC one, and vice versa. It's hard to imagine how to do this in a transportable way (given the idiosyncratic nature of most ASCII/EBCDIC translation tables), or in a way that results in short encoding and decoding programs. Obviously, control and 8-bit characters should be excluded from the encoding, as well as those printable characters that are known to cause problems with networks and mailers (space, atsign, and period spring to mind). And it should break the file up into "lines" that are short enough (say, 64 characters?) to pass through the most restrictive line-, record-, or block-oriented mechanisms, but that have no relation at all to the data itself. Here is a brief survery of some of the encoding techniques I know about: HEX: Simple 1/2 packing into hex digits, with CRLFs inserted to break the file up into lines. No error checking, compression, etc. Very simple to encode and decode. BOO: 4/3 packing, null compression, printable, no blanks or dots, no error checking, no skipping past mail headers, single file only. Tends to survive mail, raw download, etc., but sensitive to transmission errors. UUENCODE: 4/3 packing, no compression, printable. Includes blanks, dots, and atsigns. No error checking. Skips past mail headers, but tends not to survive mail, card-oriented communication links (like BITNET), or any software that strips trailing blanks. BINHEX version 4 (HQX): Macintosh only; 4/3 packing, printable, no blanks. Includes data and resource fork, allows Mac application to be fully reconstituted (MacBinary is similar, but is not a printable encoding). Intel Hex format (HEX, H86): Simple 2/1 hex encoding, error-checked, used by Intel and compatible loaders. VMSHEX/VMSDEH: VAX/VMS only. Like Intel Hex format, but includes FILES-11 FAB, allowing FILES-11 files to be fully reconsitituted. LZW and Huffman: These are compression, rather than encoding, techniques, but they are often built into encoding programs. However, the decoding programs are too long and complicated to be typed in. All of these have their advantages and disadvantages. The tradeoffs are in program complexity vs encoding efficiency and tranparency. Further discussion of the subject would be most welcome, as would a "standard" in this area. ------------------------------ Date: 30 September 1986 17:03:58 CDT From: George Wiggans Subject: Suggestions for MS-Kermit Keywords: MS-DOS Kermit I use Kermit extensively, but do not write code to add to it, therefore, I wanted to suggest what enhancements I would like. (1) I would like Kermit to assume all commands are prefixed with RUN unless they are Kermit commands. Many times I must retype the command because I forgot the RUN. [Ed. - Not a bad idea; it's been suggested before. Maybe this will appear in a future release.] (2) A recall previous commands feature. I use Norton's DOS Editor (NDE) in DOS which lets me recall and edit earlier commands. It uses the up and down arrows to scroll through the previous commands. [Ed. - You'll probably never see this, because the command parser is supposed to be machine independent.] (3) A Tek 4010 emulation for the IBM PC with an EGA card. [Ed. - This may appear in a future release; several people have expressed some interest in doing it.] (4) A raw download from the mainframe using a 7171 terminal emulator so yokeing the screen to the printer would work for printing files. [Ed. - You already have this: LOG PRN. The new CMS Kermit release has the matching feature, XTYPE, which transmits a file raw, in transparent mode, through the 7171. You could even use this to drive a plotter.] I am sure that you get many suggestions, but I thought that I would add mine. [Ed. - You're right. And one of the suggestions I get is to come up with a version of MS-Kermit that has been stripped of all its fancy features and is once again a compact, simple file transfer program. This is becoming an issue not only because it's getting increasingly difficult for users to deal with such a feature-laden program, but also because it takes up so much space on disk and in memory. The latter is a real problem for diskless laptop portables.] Thanks, George ------------------------------ Date: Mon, 6 Oct 86 09:13 EDT From: David M Chizmadia Subject: Screen Saver Feature as part of Kermit. Keywords: MS-DOS Kermit Our site uses Kermit as the primary communications program on our IBM PCs. We would like to have a feature which would allow us to set Kermit to blank the screen after so many minutes of keyboard inactivity. A command along the lines of SET SCRNSAVE n (where n is an integer >= 0 and represents the number of minutes of keyboard inactivity to wait before blanking the screen) would be optimal. If anyone has implemented or is planning to implement this feature, I would be interested in hearing about it. If not, I will try to implement it and pass it back to this digest. Dave Chizmadia (ARPA) Chizmadia -at DOCKMASTER.ARPA [Ed. - It might be a better idea to use another utility to do this.] ------------------------------ From: drilex!dricej%axiom.UUCP@harvard.HARVARD.EDU Date: Mon, 29 Sep 86 22:06:36 edt Subject: MS-Kermit on 80386 Keywords: MS-DOS Kermit I know it's awfully early, but has anyone tried a recent version of MS-Kermit (2.28 or 2.29) on a Compaq 386 yet? I have somebody who's hot to buy one, but they need kermit... I'd try it myself, except I'm not sure when I will get around to getting a 386. Craig Jackson UUCP: {harvard,linus}!axiom!drilex!dricej BIX: cjackson ------------------------------ Date: Sat, 27 Sep 86 16:24:46 pdt From: Bob Larson Subject: Found on net.bizarre Keywords: Kermit Humor In article <1482@bucsd.bu-cs.BU.EDU> awc@bucsd.UUCP writes: > >You know how I like to spend a day? > >When I'm not installing database managers, compilers, graphics >packages, etc. (and then FOLDING, SPINDLING and MUTILATING them >so they'll run on our non-standard system), I like to sit by the >phone and wait for questions about how to use Kermit. I make copies >for our users who have PC's, and at least half of them call for >help. The typical conversation goes something like: > >"Hello, may I help you?" (In my user-friendliest voice.) > >In an aggrieved tone: >"Yeah, I'm trying to use Kermit and I'm having problems." > >(I wait half a second to see if they'll add to that - like; > *what* problems? No WAY!) > >"Yes, what exactly is the matter?" > >"It doesn't work." > >(I break a pencil between two fingers.) >"Ah. Did you read the entry in on-line HELP about how to use it?" > >"Yes, but I can't get it to do aaanything!" > >"Did you execute the file KERMIT.EXE on your PC?" > >"What?" > >(I'm not a violent person, but I star this user in a Sam Peckinpah movie.) >"Are you sitting in front of your PC?" > >"Yes." > >"Type KERMIT." > >"... Ok, I did that." > >"Type TAKE M-S-K-E-R-M-I-T" > >"... ... ... Ok." > >(The INI file sets baud rate, etc. and CONNECTS them to the modem.) >"You see where it says 'Connecting to Host Computer'?" > >Triumphantly: >"Yes! I got this far, and it didn't DO anything!" > >"Well, at this point, you're communicating with your modem, NOT with >VPS (our system). You have to type the dial command, and your modem will >call the campus network. Then you can sign on as usual." > >"OOHHHH! Let me try that!" > >The user types the dial command, eventually gets it right, and >(I'M NOT KIDDING ABOUT THIS) the goddam modem starts dialing on the >line we're talking on! > >I stuff my eyes back into their sockets. > >There are a few seconds of silence at this point, during which I draw >blood from my palms with my fingernails, as the user's brain grinds >and grinds and comes up with THE QUESTION: > >"What do I do then?" > >(We're almost home now, I tell myself.) >"Well, then you just run Kermit on VPS, and you can start transmitting >files back and forth. It works just like the documentation says it >does." > >Why do I let them go at this point? I KNOW they're going to call back, >because people who don't know that you still have to dial in even if >you're using Kermit can't possibly transfer a file with it, but if >I talk to them much longer, things get red and hazy, and somebody just >might get killed. > >Eventually they give up, and call me again. I establish that they have >no idea what commands to type after they sign on and run Kermit ("Yes, >of *course* I read the documentation!"), and have them come in to see >me. Since I don't have a private phone line, I have to borrow the line >from the cubicle across the hall, stringing it over the corridor. >Our Assistant Provost inevitably brushes it with the top of his head (he's >pretty tall), and visibly wonders why *THIS* goof is still working here. > >I hook up the modem and show them, STEP. BY. STEP. how to transfer files. >The mists part, and BEHOLD! I've initiated yet another user to the mysteries >of Kermit. They clutch my hand, weep little tears of gratitude, admire my >plaster of paris Boston Terrier (you don't want to know), and they're off. > >Do I sound like a hateful little misogynist weasal, looking for a little >sympathy? Well, I am, but the point is, you'd be one too if you had to >do this OVER and OVER and OVER! Is it any wonder I come to work at 11 am, >smelling of soy sauce? Do you have to ask why I torture small animals in >the evening? Why I don't wear ties in the office, but DO when I'm lying >around at home? Shall I tell you about the time >two people came in the same day at different times for the above described >help, and I later discovered they SHARE THE SAME PC???!!! > >ARRRRGGGGHHHHHH!!! > >I'm going to lunch. ------------------------------ End of Info-Kermit Digest ************************* ------- 8-Oct-86 17:25:46-EDT,6730;000000000000 Mail-From: SY.FDC created at 8-Oct-86 17:24:12 Date: Wed 8 Oct 86 17:24:12-EDT From: Frank da Cruz Subject: Info-Kermit Digest V5 #13 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12245242164.21.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 8 Oct 1986 Volume 5 : Number 13 Today's Topics: Kermit Book Available New C-Kermits on the Way Other New Kermits On The Way Re: Screen Saver Feature as Part of Kermit ---------------------------------------------------------------------- Date: Wed 8 Oct 86 11:35:52-EDT From: Frank da Cruz Subject: Kermit Book Available The Kermit book is finally in print. Thanks to all the members of the Info-Kermit community who provided information, responded to queries, read drafts, and helped in other ways, and especially to Don Knuth for contributing the Foreword. And thanks are due, perhaps even more, to all of you who have kept Kermit alive and growing over the years by generously contributing your time and effort to its design, development, and distribution, and to the keepers of the computer networks that have made the rapid spread of Kermit information and programs so easy. Kermit is truly a community project. I tried to fit as many of you as I could into the acknowledgements, and apologize in advance to anyone I might have missed. The book is called "Kermit, A File Transfer Protocol," (author me), published by Digital Press. It does not replace the Kermit User Guide, because specific Kermit programs are not described in detail, but it supplements it by discussing motivation, commands, operation, and tricks in greater detail, and filling in more background -- there are tutorials on file systems and on data communications (RS-232, modems, cable-building, etc), plus many new tables, diagrams, pictures, summaries, a glossary, etc etc. There's a troubleshooting guide, a new bootstrapping technique including a "baby Kermit" program in BASIC short enough to type in to a PC, hints to programmers for writing and submitting Kermit programs, etc etc. The book does, however, replace the Kermit Protocol Manual; it presents the protocol in more detail, and (I hope) more coherently, than the PM, and includes program fragments from a bare-bones version of C-Kermit to illustrate each facet of the protocol, in a much more layered and structured fashion than was done before (but the PM will still be kept around). It will take some time before the book reaches the bookstores, since it only left the bindery this week. In the meantime, it can be ordered direct from Digital Press by calling 1-800-343-8321, order number EY-6705E-DP. It is also being distributed this week at DECUS in San Francisco, but reportedly it's in short supply. Anyone who has checked the book box on Columbia's Kermit order form should be getting their copies within 2-3 weeks, maybe sooner (we'll send them out as soon as we get them). Disclaimer: I am obviously biased about this book. Reviews, favorable or not, will be most welcome and will be published in the Info-Kermit digest. Reports of mistakes, typos, etc, are also welcome (so they can be fixed in the next printing, if any) as well as suggestions for changes to make in future editions. ------------------------------ Date: Wed 8 Oct 86 11:45:52-EDT From: Frank da Cruz Subject: New C-Kermits on the Way There is a lot of work underway to bring C-Kermit to new systems. Below is a brief list of the work in progress; the major intention is to prevent duplication of effort, and to promote cooperation. If you are working on a Kermit program for any of the systems listed below, or know anyone who is, please have them contact us, so we can put them in touch with the people who are working on these projects: Apollo Aegis Apple II GS, CPW (windows) Apple Macintosh (convert Mac Kermit to Lightspeed C) Data General MV series, AOS/VS MS-DOS NCUBE parallel processor with AXIS OS VAX/VMS (add more knowledge about VMS file system) If you know of anyone adapting C-Kermit to any systems not listed above, also have them contact us, so we can add them to the list. Thanks! ------------------------------ Date: Wed 8 Oct 86 10:14:45-EDT From: Frank da Cruz Subject: Other New Kermits On The Way Here are some other Kermit development efforts. Again, if you are (or know of anyone who is) doing any work along the same lines, please (have him/her) contact us: Apple II: (1) New CROSS release for DOS; (2) new release in native assembler. ProDOS support may appear in one or both of the above. Apple III (yes Apple III) CDC Cyber 170 Series: Various new versions, improvements to current ones. CP/M-80: New release, will support many more systems more modularly. CP/M-86, Concurrent CP/M-86: IBM PC Data General MV Systems, AOS and AOS/VS: versions in Fortran, C, DGL HP-9000 and 98x6 BASIC systems Honeywell DPS6/GCOS6 IBM System/370 Series: Major effort underway to integrate CMS and TSO versions Intel development systems (many separate efforts underway) Japanese micros - many versions available through NEC or NTT Motorola 68000 assembler version, OS-independent Motorola development systems (Xormacs, VME, Versados, etc etc) MS-DOS: Version 2.29a will be ready soon! MUMPS-11 (improved version reportedly done, on the way) Philips development systems Pick Operating System (IBM PC, etc) There are also many, many others of a less certain nature. All of these efforts are listed in the file KER:AAWAIT.HLP on CU20B (AAWAIT HLP on CUVMA). ------------------------------ Date: Mon, 6 Oct 86 15:30:20 pdt From: tweten@ames-prandtl.ARPA (Dave Tweten) Subject: Re: Screen Saver Feature as Part of Kermit Keywords: MS-DOS Kermit, Screen Saver Feature You don't need to put a screen saver feature into Kermit. There are several public domain terminate-and-stay-resident screen saver programs available, any one of which can be started before running Kermit (perhaps in an AUTOEXEC.BAT file), and which will be effective while Kermit runs. The Info-IBMPC source code library at USC-ISIB.ARPA has at least two. I wrote another (which has the user-settable time feature you requested). I'm sure many others exist in the public domain. A little asking around should net you one you like. ------------------------------ End of Info-Kermit Digest ************************* ------- 28-Oct-86 11:16:10-EST,20840;000000000000 Mail-From: SY.CHRISTINE created at 28-Oct-86 11:14:44 Date: Tue 28 Oct 86 11:14:43-EST From: Christine M Gianone Subject: Info-Kermit Digest V5 #14 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12250428707.177.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Tue, 28 Oct 1986 Volume 5 : Number 14 New York Mets: The Official Baseball Team of the Kermit File Transfer Protocol Today's Topics: Call for IBM Mainframe Kermit Developers Re: File encoding Where to Get HP-1000 Kermit Kermit Server at Bitnet node UOFT02 Prime Kermit 7.57 RT11 XM Kermit Problem Mac connections MS-Kermit options Two Small Requests for MSKERMIT MSKermit LOG suggestion Kermit on Compuserve? Problem with Kermit and DATAKIT ---------------------------------------------------------------------- Date: Thu 9 Oct 86 13:23:41-EDT From: Frank da Cruz Subject: Call for IBM Mainframe Kermit Developers Keywords: VM/CMS Kermit, MVS/TSO Kermit A lively discussion (and some work) is underway to merge the major IBM System/370 series assembly-language Kermit programs, so that VM/CMS and MVS/TSO Kermits can share common OS-independent modules (particularly the code that implements the Kermit protocol itself). Any IBM mainframe Kermit developer or maintainer who wants to be involved in this discussion should send me a note (as SY.FDC@CU20B, or FDCCU@CUVMA.BITNET). This includes those who have any connection with the Kermit programs for MVS/GUTS, MUSIC, and MTS, and who might be interested in integrating Kermit into the various dialects of Wylbur, and possibly also with CICS. ------------------------------ Date: Sat 11 Oct 86 02:08:17-PDT From: Bob Larson Subject: Re: File encoding Keywords: File Encoding Here are a couple of file encoding schemes that Frank da Cruz missed in his list: btoa/atob 4.0: 5/4 encoding to printable characters, space not included. Designed for use with (and comes with) compress 4.0. Has header and trailer lines so mail headers may be skipped and multiple files may be sent together. (Available for ftp from the mod.sources archives at seismo.css.gov, I have an os9/68k version if there is interest.) Motorola S record: 2/1 encoding to printable characters. Designed for use with eprom programmers, etc. so includes address specification. (Number of address bits vary between various S record formats.) The only advantage of this format that I know of is encoding/decoding programs come with os9. Included for completeness. Bob Larson [Ed. - Thanks for completing the encoding form list Bob.] ------------------------------ Date: Wed 15 Oct 86 11:24:44-EDT From: Frank da Cruz Subject: Where to Get HP-1000 Kermit Keywords: HP-1000 Kermit In V5 #3 of the Info-Kermit Digest, a message was posted by Michael Terenyi describing a new HP-1000 Kermit that solved all the problems of the previous versions, that was available from Paul Schuman of E-Systems, Inc, Greenville, Texas. Some weeks later, we actually received, installed, and announced this version in the regular Kermit distribution. However, Paul has been getting numerous calls, blank tapes, etc, ever since. Although Paul was kind enough to contribute his program to Kermit Distribution, he does not have the time or resources to honor the high volume of requests he's been getting for this program. If you need it, please get it either from Columbia (by mail order, or over the networks as HPM*.*), or else from the international Hewlett-Packard User Group: Interex 680 Almanor Avenue Sunnyvale, CA 94086-3513 Phone 1-408-738-4848 You probably have to be a member of Interex before you can order programs from them. Paul thinks they have Kermit programs for a large variety of HP minis, workstations, and PCs, all on native media, which is a service Columbia has not been able to provide. ------------------------------ Date: Wed, 15 Oct 86 12:43 EDT From: (brian nelson) Subject: Kermit Server at Bitnet node UOFT02 Keywords: Kermit BITnet Server For those of you experiencing trouble accessing KERMSRV@UOFT02.BITNET there was a problem in the way it sent interactive messages back. It was acting as if it were a NODE and not a USER when sending messages. This has been fixed. Also, please note that it responds to interactive messages only, files sent to it with imbedded commands will not cause it to send files back. Brian Nelson ------------------------------ Date: Tue, 21 Oct 86 18:35:15 GMT From: BROOKS@UK.AC.EXETER.PC Subject: Prime Kermit 7.57 Keywords: Prime Kermit There is a bug in PR1ME Kermit version 7.57. If, when in SERVER mode, the user logs off with a BYE command on the micro-Kermit, the NEXT user to get that PRIMOS usernumber can have problems related to the PRIMOS KILL and ERASE characters. It showed up in the Sheffield Editor for us. The problem arises if other software expects that the PRIMOS routine ERKL$$ returns leading zeros in the words that give the user's KILL and ERASE characters as documented in DOC3621-190 Subroutines Reference Guide page 10-23. What is not documented is that when writing the KILL and ERASE the leading byte of the words should be ZERO. This is the only reason that reading returns leading zeros! Unfortunately, PRIMOS Kermit uses leading spaces when writing these values. This in itself causes no problem as when Kermit exits SERVER mode in all ways EXCEPT when it receives a BYE command, it restores the user's KILL and ERASE characters with words it had read previously. Again this seems no problem as LOGO$$ restores the System default KILL and ERASE characters so everything appears OK to the next user. But logo$$ does not seem to alter the leading byte of the words holding KILL and ERASE, hence the problem. The simplest fix in PRIMOS Kermit is as follows:- In GENERIC_CMD.PLP, before call logo$$(0,0,' ',0,0,code); insert the line call xfer_mode(0,code); /* restore terminal characteristics */ Ideally, the first call to erkl$$ in XFER_MODE.PLP should be fixed so that it has leading zeros in the character strings it passes, but this needs more changes to be made in the source. The fix given is short and it works! There may be a problem with forced logouts which this fix obviously won't cope with. The QUIT handler calls xfer_mode so there is no trouble there. This caused us no end of trouble to track down to Kermit! It seemed an epidemic had struck as more and more users hit this problem. (The PRIMOS command TERM -kill and TERM -erase fixes a user in trouble). It didn't help that we changed from Rev 19.3 to Rev 19.4 at the same time as we released Kermit 7.57. Neil Brooks University of Exeter Computer Unit [Thanks. We will forward this message to the authors of Kermit.] ------------------------------ Date: Thu, 23 Oct 86 11:51 EDT From: (brian nelson) Subject: RT11 XM Kermit Problem Keywords: RT-11 Kermit A problem with the RT11 XM version of Kermit-11 (K11XM.SAV) has been reported. The symptom is that any command that requires additional prompting for input, such as SHOW and SET, the prompt will be garbage. Ie, the command: Kermit-11>SHOW should reply with: What: The cause is the command table being swapped over by the command line editor, thus making the pointer to the prompt text invalid. The correction is made in K11CMD.MAC as follows. The lines commented with /55/ are the corrections. Brian Nelson Brian@Uoft02.Bitnet [Ed. - Thanks. The fix is in KER:K11.BWR.] ------------------------------ Date: Fri 24 Oct 86 13:13:29-EDT From: Frank da Cruz Subject: Mac connections Keywords: MacKermit There have been increasing numbers of questions coming in about how to connect Macintoshes and Mac-Pluses to modems and directly to other computers. I hope the following details will help. I won't go into any detail explaining terms -- you can look them up in a data communications book (or the Kermit book!). The Macintosh serial port is not RS-232, it's RS-422 and uses different signalling. The Mac RS-422 port lacks the modem signals CD, DTR, DSR, RI, and RTS, and any modems that expect to handshake with the Mac using these signals will not work unless the handshaking can be overriden (e.g. by setting configuration switches in the modem) or by fakeout wiring in the modem end of the cable. The Macintosh serial port connector has 9 pins rather than the customary 25 pins that RS-232 requires. The Mac-Plus has an 8-pin "Din-8" connector, which needs a special converter from Din-8 to 9-pin to make it "plug compatible" with the original Mac. Here are the Macintosh 9-pin connector assignments, and the corresponding Din-8 assignments: 9-pin Din-8 Signal 1 4 FG (frame ground) 2 +5V (not connected in DB9/Din-8 converter) 3 4 SG (signal ground) 4 8 TD+ (transmit positive) 5 5 TD- (transmit negative) 6 2 +12V 7 1 CTS (clear to send, or "handshake") 8 6 RD+ (receive positive) 9 3 RD- (receive negative) The cable that you need to connect the Mac to a modem or to another Mac may not be readily available in a store, so you might have to alter or build one yourself. The parts (DB-9 and DB-25 connectors, pins, cables, tools, etc) should be available from computer stores or in computer supply catalogs like Inmac, Black Box, Misco, etc. To connect a Macintosh to a modem, you need a male 9-pin (called DB-9, DE-9, or D-9) on the Mac end. Only pins 3, 5, 8, and 9 need to be connected. On the modem end, a 25-pin male DB-25 connector. Four wires in the cable should connect the pins in the two ends as follows: Mac DB-25 3 7 Signal ground 5 2 Transmitted data 8 1 Frame ground 9 3 Received data Before testing this cable with your modem, be sure it's plugged into to desired port (the present version of Kermit on the Macintosh, 0.8(34), works only on the communication port, not on the printer, SCSI, or any other port; this restriction may be lifted in future releases), and the baud rate is set appropriately, usually 1200. You should be able to dial the modem (if it's Hayes compatible) by typing ATD and the phone number. If this doesn't work, check the configuration switches of your modem. In particular, it must be in originate mode (ATD puts Hayes-like modems in originate mode automatically), and it may need to be instructed to ignore DTR (many modems require DTR signals from the PC, but the Mac doesn't provide one). For further details, read your modem manual. To connect your Mac to another PC, use a "null modem" cable. Here is how to set up a null modem cable with a Mac 9-pin (male) connector on one end and a male DB-25 on the other: Mac 9-pin DB-25 The DB-25 end of this cable can be plugged into any computer that has a female RS-232 DB-25 serial 3 SG ---+ port connector. To connect a Mac with a PC/AT | (which has a DB-9 connector, but with RS-232 +---- 7 SG rather than RS-422, signalling), use a regular Mac | modem cable, described above, on the Mac, a regular 8 RD+ --+ PC/AT modem cable on the AT (available in stores +-- 6 DSR and catalogs), and a female-female null modem | (also available in stores and catalogs) to connect 7 CTS <---+-- 20 DTR the DB-25 ends of each cable. | +-- 8 CD To connect two Macs back-to-back, use a similar trick: two Mac modem cables, plus a null modem. 5 TD- ------> 3 RD Building, adapting, and testing connectors is 9 RD- <------ 2 TD not everyone's dish of tea. If it's not yours, then take a copy of this message to a computer +--- 4 RTS store and point to what you need. If possible, | try to test it there on a configuration similar +--> 5 CTS to yours before paying for it. Back to modem cables. If your modem requires certain modem signals, and this requirement cannot be disabled, you should be able to cajole the modem into operation by using a null modem cable like the one above, but with 5 TD- ------> 2 TD 9 RD- <------ 3 RD That is, the modem signals RTS, CTS, DTR, DSR, and CD are all faked in the connectors, but receive and transmit are not cross-connected as in a real null-modem cable. ------------------------------ Date: Thu 9 Oct 86 12:02:50-EDT From: EXT1.FARHAD@CU20B.COLUMBIA.EDU Subject: MS-Kermit options Keywords: MS-DOS Kermit (1) - In a recent message to Info-Kermit, someone proposed that the MS-DOS Kermit subcommand parser incorporate assumption of a "run" prefix for inputs that are not specifically Kermit subcommands. I suggest that, unless such suggested feature is effected as a togglable option via Kermit's "set" subcommand or as an equivalent togglable function, such proposed feature's simplistic allure be resisted because the "feature" could potentially have unintended side effects that would interfere undesirably with Kermit's otherwise expected proper behavior. As you are aware, the proposed run prefix assumption feature would send DOS flying on PATH-related searches for each and every Kermit-level nonsubcommand input, including typos. For example, people who park their harddisks when they run Kermit for long remote sessions would see this behavior of the proposed feature put their disk in "drive." The feature might also necessitate that Kermit macros be named differently from programs on the PATH which the "feature" would want to run -- clearly a cumbersome and "nontransportable" requirement. (2) - I much prefer to see Kermit continue to steer clear away from special-interest "gimmeckery" such as commandline recall/edit, screensaver, alarm and calculator functions, etc. I have seen many users (beginner and advanced but not intermediate) who often choose to use earlier (even buggy) versions of MS-Kermit just because they want a bare-bones program without the fancy-schmancy code even though they have ready access to V-2.29a! (4) - A universally useful feature would be runnability of MS-Kermit with DOS-level subcommands, switches, etc. -- e. g.: DOS>KERMIT -do MACRO1 or, DOS>KERMIT -take INIT1. (5) - Without implying that Kermit should become a whole O/S with development tools, compilers and the rest, I ask whether Kermit could indeed not be modularized so that a core program could be run and then desired features could be loaded optionally through subcommands that work on external file contents -- that'll take care of memory size, extra features and the rest of the complaints and suggestions, wouldn't it? And, how about an O/S-(in)dependent Kermit Function Module Protocol? /Farhad ------------------------------ Date: Sat, 11 Oct 86 08:11:16 EDT From: John C Klensin Subject: Two Small Requests for MSKERMIT Keywords: MS-DOS Kermit With apologies for joining the litany... 1) It would be nice if the key scanning table were expanded so that the two new function keys (F11 and F12) on the extended keyboards could be used. Neither their scan codes, nor the function key names are recognized by 'set key', and 'show key' does not even recognize that they are keys. [Ed. - There's nothing in Kermit that prevents the new scan codes from being recognized. These keys simply are not generating them in the same way the other keys generate scan codes. Even on the previous keyboards, some keys -- like Ctrl-1, Ctrl-3, Ctrl-4, etc, keypad 5, Sys Req, etc -- generate no scan codes.] 2) There is apparently no convenient way to display the [path]name of the current local directory. I can set it (with LOCAL CWD ...), or get a directory of its contents (with LOCAL DIR), but can't just inquire about its name. The CP/M-86 versions do an approximation to the job by displaying the kermit prompt in the form KERMIT86 DN> where D and N are the drive and user number; MSKERMIT should have SOME way to obtain this info without listing out the contents of the directory. [Ed. - Right, this should show up in a future release.] Similarly, it would be nice to be able to ask the thing to tell me to whence I am logging. I can, more or less, find out if logging is turned on, but can't (at least as far as I know) find the name of the file to which logging is occurring. Both of these things take on added importance as the presence of scripts and TRANSMIT make it more possible to tailor the kermit environment to the needs of a particular [naive] user, introducing more confusion as to what has happended when something goes wrong. [Ed. - All good points. Anything that can be SET should be capable of being SHOWn.] ------------------------------ Date: Wed, 15 Oct 86 07:29 EST From: CDTAXW%IRISHMVS.BITNET@WISCVM.WISC.EDU Subject: MSKermit LOG suggestion Keywords: MS-DOS Kermit, LOG command Being an avid user of IBM's 7171 controller via an IBM PC and MSKermit, I might suggest the following modification to MSKermit's LOG feature: allow one to strip escape sequences if desired. Session logs of sessions through a 7171 or Series 1 controller with IBM mainframes can be accomplished with the escape sequence - F commands, but dumping screen at a time for more than a few screens is anything but easy. If an option was available for the LOG function which would allow the user to choose between keeping the escape sequences and stripping them, I believe its functionality would be greatly increased. Mark [Ed. - Doing what you ask would introduce a whole new level of complexity into terminal emulation, slowing it down significantly. It would also add dependence on the particular terminal being emulated, and on the system doing the emulating. In your particular case, a way around the problem is to use CMS Kermit's XTYPE and XECHO commands, to send stuff "raw" to the ASCII terminal, where it can be logged.] ------------------------------ Date: Mon 13 Oct 86 13:12:46-EDT From: Dan Caldano Subject: Kermit on Compuserve? Keywords: Compuserve Does anyone have any info about downloading files from Compuserve using Kermit on a 512K Mac? Am new to this sort of thing, and while I've mastered downloading from our local DEC20 I must admit to being daunted by what I'm reading on Compuserve (besides it's expensive just "grazing" through Compu- serve) and in various magazines. Anyone out there able to point out what I'm missing? Any help would be appreciated, thanks. [Ed. - Good question. Can some knowledgable Compuserve subscriber post a message to Info-Kermit telling whether Kermit is available on Compuserve, and if so, how to get at it?] ------------------------------ Date: Mon, 13 Oct 86 17:19:47 EDT From: vxb@harvisr.harvard.edu (Vernon Bradner) Subject: Problem with Kermit and DATAKIT Keywords: DATAKIT I am trying to use Kermit over AT&T's DATAKIT packet switched data network. Kermit file transfers work, but sometimes have many frame retransmits resulting in much longer file transmit times. The xmodem file transfer protocol has no such problems over DATAKIT. Of course, I would much prefer to use Kermit (especially since with Kermit I can transmit several files at once, unlike xmodem). Has anyone else had similar problems with Kermit and DATAKIT? Possibly I just have the wrong settings in Kermit? Any ideas you might have would be a big help. Thanks - Vern Bradner (vxb@wjh12.harvard.edu) [Ed. - Has anyone had experience using DATAKIT packet switched data network?] ------------------------------ End of Info-Kermit Digest ************************* ------- 3-Nov-86 16:36:28-EST,14520;000000000000 Mail-From: SY.FDC created at 3-Nov-86 16:34:24 Date: Mon 3 Nov 86 16:34:22-EST From: Frank da Cruz Subject: Info-Kermit Digest V5 #15 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12252059761.162.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Mon, 3 Nov 1986 Volume 5 : Number 15 Today's Topics: Kermit Files Split into Three Groups New Release of Kermit for TRS-80 Model 4 Atari ST Kermit Diskette Volunteer Re: CompuServe vs Kermit How to Display Connected Directory in MS-Kermit Kermit vs Datakit Networks PROCOMM Kermit File Transfer Problems? KermitLANd: Suggestions to Improve Kermit Ideas for Kermit Distribution Overflow ---------------------------------------------------------------------- Date: Thu 30 Oct 86 17:08:01-EST From: Frank da Cruz Subject: Kermit Files Split into Three Groups Keywords: Kermit Distribution, Distribution, Tapes, OK State, UUCP The Kermits just keep rolling in. In June 1985, the material became too big to fit on a single 1600-bpi 2400-foot reel of labeled tape, so we had to split the files into two groups: A (micros) and B (minis and mainframes). In August 86, the collection grew too large for two tapes, and intallation of some new versions was put on hold. So now a third tape (C) has been added. Tape C is for "esoterica" (less popular versions of Kermit, implementations infrequently requested from us, European and Japanese versions, etc, and redundant versions) and for large documents -- the Scribe source for the User Guide and Protocol Manual, the mail archives, etc. The AAVERS.HLP file tells exactly which group each implementation is assigned to. AAFILES.HLP explains in a bit more detail. Apologies to anyone who feels slighted by having their favorite Kermit version assigned to the "esoteric" tape. The assignments were not totally arbitrary and capricious, but were made mostly according to the frequency with which people ask for (or about) these versions, with the goal of having the three collections occupy about the same amount of disk/tape space (about 15MB each). The most popular micro and mainframe Kermits remain on tapes A and B, so that people who order these tapes in the "old way" will still most likely get what they were expecting. For network access, the procedures are pretty much unchanged. FTP, NFT, and KERMSRV will continue to work as before. The file KER:AANETW.HLP has been updated (along with all the other relevant files) to reflect the new layout. Apologies for the disruption in KERMSRV service from Friday afternoon (Oct 31) to Monday afternoon (Nov 3) while the files were being reorganized. As we announced a couple months ago, our major tape-making facility (a small UNIX Vax) could not have its Kermit files updated until this reorganization took place. This has now been done. Oklahoma State University, which keeps a parallel Kermit collection for UUCP access, updates its files from this VAX; hence OK State has not been getting new Kermit files since August. We will send them a new set of tapes this week, and the automatic updating should kick in again after they have installed it. ------------------------------ Date: Fri, 31 Oct 86 13:01:26 -0600 Subject: New Release of Kermit for TRS-80 Model 4 From: Gregg Wonderly Keywords: TRS-80 Model 4 This is to announce the newest version of the TRS80 Model 4 KERMIT. This version, 5.2, has many small bug fixes, as well as some major additions to the program. The changes are listed in detail in the file M4CHGS/ASM, but the most important ones since the previous release (5.0) are bug fixes, command restructuring (particularly SET FILE), transaction and debug logging, and wildcards allowed in SEND and KILL. Version 5.1 was never released. There were also some changes in the H19-filter that is now included in the distribution. These changes include the addition of a STRIP8 parameter to SETH19 that will allow the parity bit to be stripped from characters before they are put on the display. In this version of KERMIT, I have made some attempts to start reducing the number of hardware manipulations that do not use the system SVC's. However, there are still many Model 4 specific operations. I would like to begin replacing the Model 1/3 version of KERMIT with this version, in the interest of making more of the functionality of Model 4 KERMIT available to Model 1 and 3 owners. If anybody is interested in taking on the task of doing this for either machine, the help would be greatly appreciated. Most of the work will involve finding replacement code for routines that manipulate the Model 4 hardware (Display, Comm Line, etc...). Any interested parties should send mail to me at the address below so that there can be some sort of cordination of efforts. Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg ARPA: gregg@A.CS.OKSTATE.EDU or gregg%okstate.CSNET@CSNET-RELAY [Ed. - Thanks, Gregg! The new version replaces the old one as KER:M4*.*. In the spirit of consolidating the hundreds of Kermit versions, I'd heartily encourage anyone who cares about the TRS-80 Model 1 and 3 Kermits to get together with Gregg and try to hammer together a common version for the models 1, 3, and 4.] ------------------------------ Date: Mon 3 Nov 86 12:05:59-EST From: Il H Oh Subject: Atari ST Kermit Diskette Volunteer I finally got Kermit running on my Atari ST. I'd be glad to mail ST Kermit diskettes to other ST users, if they'll send me a preformatted diskette and a self-addressed, stamped return mailer. My address is: Il Oh 362 Riverside Dr. Apt. 10B7 New York, NY 10025. il [Ed. - Many thanks! Diskette volunteers are always welcome, as are user groups and diskette services that are willing to provide Kermit diskettes by mail order at low cost (say, in the neighborhood of $10). If anyone out there has a Kermit program on a diskette that's not readily available from Columbia or other sources, you are heartily encouraged to volunteer as Il has done, or to submit it to an appropriate user group or diskette service.] ------------------------------ Date: Tue, 28 Oct 86 21:40:12 est From: jpm@bnl.ARPA (John McNamee) Subject: Re: CompuServe vs Kermit Keywords: CompuServe To answer the query from Dan Caldano in Info-Kermit V5 #14: no, CompuServe does not support Kermit. They support XMODEM and two of their own protocols (CIS "A" and CIS "B"), and are working on something like X.PC for concurrent file transfer and terminal sessions. I doubt they are going to support Kermit since it was a major fight to get them to support XMODEM, and a lot more of their users have XMODEM than have KERMIT. John McNamee CompuServe: 70235,1345 [Ed. - Do the current protocols suffice? Can everybody get at Compuserve with an 8-bit transparent path, with buffers that never need to be shorter than 132, etc? Or do they all have CompuServe A & B on their micros? If not, then maybe those who need Kermit could start infiltrating and agitating...] ------------------------------ Date: Wed 29 Oct 86 15:05:29-EST From: Peter Kanaitis Subject: How to Display Connected Directory in MS-Kermit In Info-Kermit Digest V5 #14, John C Klensin writes: >2) There is apparently no convenient way to display the [path]name of the >current local directory.... > >[Ed. - Right, this should show up in a future release.] Why not do a: Kermit-MS>run cd or Kermit-MS>run chdir P. Kanaitis Allegheny-Singer Research Institute PK0P@TD.CC.CMU.EDU [Ed. - Where there's a RUN, there's a way...] ------------------------------ Date: Wed, 29 Oct 86 08:02:46 est From: ulysses!psk@ucbvax.berkeley.edu (Philip S. Kravitz) Subject: Kermit vs Datakit Networks Keywords: Datakit Unlike Vern Bradner (Info-Kermit Digest V5 #14), I use Kermit all the time over Datakit networks and have not experienced any problems. (I primarily use the Unix version of Kermit although I have had no problems with the MS-DOS version either). ------------------------------ Date: Wed, 29 Oct 86 16:10:04 PST From: Lawrence_Clarke%UBC.MAILNET@MIT-MULTICS.ARPA Subject: PROCOMM Kermit File Transfer Problems? Keywords: PROCOMM I am having problems transfering files from an IBM-PC/XT using PROCOMM V2.42, to a VAX/VMS V4.4 system running KERMIT-32> V3.1.066. File transfers seem to work fine with normal PCKERMIT/MSKERMIT V2.29, but will not work with PROCOMM. Has anyone out there had any experiences with PROCOMM'S kermit file transfers to a VAX ??? ------------------------------ Date: Thu, 18 Sep 1986 15:28 PDT From: "Jeffrey Sicherman" Subject: KermitLANd: Suggestions to Improve Kermit Keywords: Kermit Protocol, Suggestions My intention was to link several PCs with on onsite minicomputer. Since Kermit is already in the public domain and is implemented on numerous machines, it seems to me that it could be suitable for this purpose if some program changes were made to existing implementations and a very few (perhaps even non-essential) packet/protocol changes were made for a LAN-only environment. Some of the considerations that have occurred to me are indicated below, but I'm sure there are some features and complexities that I have overlooked. [Ed. - Jeffrey goes on to point out that a Kermit server is a lot like a network file server, and then discusses problems of routing, station identification, topology, media access & contention, file attributes, mail, etc., at some length. KERMIT IS NOT A NETWORK. It's strictly for point-to-point, user-initiated, temporary connections over serial communication devices. Furthermore, Kermit provides terminal emulation, NOT virtual terminal service -- there's a big difference. Kermit's design is simply not amenable to layering of arbitrary kinds of network services -- especially interactive ones like virtual terminal service, SMTP dialogs, etc. All these problems have been solved already, and a lot of the software -- particularly TCP/IP implementations -- is either in the public domain or else relatively cheap. Let's remember that the vast majority of Kermit users are individuals with modems who couldn't care less about these issues, let alone take the time to work on design and implementation problems that take huge, PAID, programming teams years to solve.] ------------------------------ Date: Thu, 18 Sep 1986 00:19 PDT From: "Jeffrey Sicherman" Subject: Ideas for Kermit Distribution Overflow Keywords: Files I noted the request for assistance in cleaning up the Kermit distribution files in the recent digest (vol 5 no. 8) and the associated difficulties in maintaining order in the system. In response to this, I suggest the following: It would be useful to have a file that was a matrix of kermit implementations. The rows of this matrix would be the various implementation; the columns would be features implemented. This could be restricted only to features defined within the Kermit protocol and standard or could also include other esoterica but should at least include all the defined features and such things as mode of operation. The matrix entries could be as simple as Y/N or X/- to indicate the compliance, or a level of support (e.g. checksum types) or could indicate parametric values (e.g. maximum packet sizes) or the characters used for implementation (e.g. prefixes). A couple of columns could also include annotations such as latest version. Multiple entries might be desirable where there are multiple implementations or there is a new version in beta test; if so they should be marked as such. It would also be nice to have some figure of merit or rating that indicates the reliability, quality of documentation, and ease of use; this would probably be not scientific in nature but hell, one of the advantages of development by controlled chaos is not having to adhere to a lot of bureaucratic rules. Admittedly, a matrix of reasonable comprehensiveness would be rather large and be difficult to present in printed form. Therefore there should be a native, master form of the matrix which is comprehensive. This, I expect, would take the form of a spreadsheet file (in native form and/or some common convertible, importable standard one)... [Ed. - Jeffrey goes on to describe how the matrix might be implemented, and discusses some of the attendant problems. It's a great idea, but one that will probably never see the light of day. If it's a spreadsheet, it's necessarily dependent on some piece of software that not everybody has. If it's plain text, we've got a problem in organization and formatting; many people want to see this information in printed form, which limits it to 80 or 132 columns in width -- our AAV*.* files are the best we've been able to come up with to date; they fit on the screen, and can be printed 2-up on landscape paper and/or double-sided for convenient mailing (when you mail 30 or 40 Kermit info packets per day, you have to think of these things). They show the most important information (file prefix, system, os, language, version number, date, contributor) as compactly as possible in the space that we have. To reorganize these files all you need is a sorting program, which every computer should have, and to search them a text editor suffices. Still, the need for a master list of Kermit versions (available, on-the-way, and possible) that includes more information than the AAV and AAW files is real. I expect we'll have to do something like this one day, and the form it will take will be some kind of simply structured plain text. It's just a matter of finding the time to do it.] ------------------------------ End of Info-Kermit Digest ************************* ------- 12-Nov-86 17:37:49-EST,23422;000000000000 Mail-From: SY.CHRISTINE created at 12-Nov-86 17:36:47 Date: Wed 12 Nov 86 17:36:47-EST From: Christine M Gianone Subject: INfo-KErmit Digest V5 #16 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12254430419.45.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 12 Nov 1986 Volume 5 : Number 16 Today's Topics: Announcing HP9845 Kermit in BASIC Updates to Cyber Kermit Oksatate Kermit Distribution Getting Kermit Files F11 and F12 on new IBM PC Keyboard TSO Kermit Fix Fix to os9 Kermit Server Portable 68000 Kermit More on CompuServe vs. Kermit CompuServe and Kermit VAX/VMS Kermit to PROCOMM PROCOMM's Kermit and the VAX/VMS PROCOMM Kermit File Transfer Problems Kermit-32 and PROCOMM How to Transfer Binary from UNIX to VMS? VAX/VMS & Kermit C-Kermit and Xenix 3.0 Re: FIDO - UNIX Kermit problem Rainbow MSKERMIT initialization ---------------------------------------------------------------------- Date: 7-NOV-1986 12:53:27 From: DGM1@UK.AC.YORK.VAXA Subject: Announcing HP9845 Kermit in BASIC Keywords: HP9845 Kermit Please find attached a listing of a minimalist kermit data transfer program in interpreted Basic (!) for the HP9845. As it's in interpreted Basic a listing of the source code seemed the best form to distribute it in. This implementation was developed by Chris Walker in the Physics Dept here, and is principally designed for the transfer of experimental data from a micro functioning as a data logger to a mainframe. As such it lacks some features of a standard Kermit implementation, but it works well and does what its supposed to do. Cheers, Doug Doug Moncur, Computing Service, University of York, Heslington, York YO1 5DD tel: 0904-430000x487 :: janet: DGM1@YORK.VAXA [Ed. - Thanks for the new Kermit version. Many people have asked for this in the past. The files are in KER:HP9845.*.] ------------------------------ Date: 12-NOV-1986 10:14:07 From: SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk Subject: Updates to Cyber Kermit Keywords: Cyber Kermit A new version of Manchester University's Cyber Kermit (CYB) has just arrived here: I've attached their release notes below. Alan CYBKER.UPD In addition to several minor alterations and improvements, there are two major changes to Cyber Kermit which have been requested by many users of the program: A Directory command has been added to list the names and lengths of local files. When an optional filename parameter is specified, only those files with matching names are listed. This command is avail- able both as a local command on the Cyber and as a remote command in server mode. The wildcard character '*' is allowed in file names after DIR, SEND, remote DIR, and remote GET commands. [Ed. - These files will placed in KER:CYB*.* as soon as they arrive over the network.] ------------------------------ Date: Tue 11 Nov 86 09:50:49-EST From: Frank da Cruz Subject: Oksatate Kermit Distribution Keywords: Okstate, UUCP For those who may have missed previous announcements about this, here is a brief description of the dialup Kermit file services available from Oklahoma State University, Department of Computing and Information Sciences, Stillwater, Oklahoma. The OK state collection has just been brought up to date to reflect the new 3-area organization, and to include the Kermit versions that have been announced since last August. OK State provides both UUCP and Kermit dialup access. The files from TAPE A are in /usr/spool/uucppublic/kermit-a/* The files from TAPE B are in /usr/spool/uucppublic/kermit-b/* The files from TAPE C are in /usr/spool/uucppublic/kermit-c/* -- UUCP -- You need to set up "okstate" as a site in your "L.sys" UUCP dialing file using the information listed below. You can then issue the following commands on your system: uucp okstate!~uucp/kermit-a/aaaread.me /usr/spool/uucppublic (this example will retrieve a general information file about the entire Kermit Distribution. DO THIS FIRST!) uucp okstate!~uucp/kermit-b/ck\* /usr/spool/uucppublic (this example will retrieve the current version of C-Kermit) There are several files available that contain information about the entire distribution. We recommend that you retrieve these files first. They are "aaaread.me" which explains the file name conventions used, "aafiles.hlp" which explains how to find the different kermit versions, and "aafiles.dir" which is a complete listing (by name) of all files in the in each kermit directory. These files will enable you to choose the right files the first time. UUCP Login information: Site Name : okstate Phone number : (405) 624-6953 (300/1200 baud) Login name : uucpker Password : thefrog Hours : 24 hours per day, 7 days a week Problem : okstate!uucp-support (UUCP) reports : uucp-support@a.cs.okstate.edu (ARPA) The following is a sample L.sys line (\r is a carriage return): okstate Any ACU 1200 405-624-6953 "" \r ogin: uucpker word: thefrog -- KERMIT SERVER ACCESS -- Okstate also provides access to the Kermit distribution via a Kermit Server. The number is the same as above for the uucpker login, so the line may be busy quite a bit. This server is a specialized server with controlled access. At present, the server is only allowed access to the Kermit directories on our machine. You need the following information in order to access the server: KERMIT login : kermsrv Password : piggy Parity : even Data path : 7 bit Available : 24 hours/day, 7 days a week When the login is completed, the server will start, and you should escape back to your local KERMIT to issue further commands. If the server remains idle for a period of time around 10 minutes, it will be stopped. The best place to start after logging on is "REMOTE HELP", followed closely by the desired "REMOTE DIR" commands. If you don't include an argument to REMOTE DIR, you should be prepared for more than 600 lines of output. It is usually better to read the 'aaaread.me' file (using REMOTE TYPE perhaps) and then do the DIR with some kind of wildcard (like "REMOTE DIR ck*"). Mark Vasoll Computing and Information Sciences Internet: vasoll@a.cs.okstate.edu Oklahoma State University UUCP: {cbosgd, ihnp4, isucs1, Stillwater, Oklahoma pesnta, uokmax}!okstate!vasoll [Ed. - Once again, many thanks for providing this service. A much longer and more detailed description of how to access the OK State Kermit files may be found in the file AANOKS.HLP in the Kermit distribution. There may be a slight delay before this service is fully available because of a last-minute foulup (Columbia's fault) with the tapes.] ------------------------------ Date: Wed 5 Nov 86 14:16:29-EST From: Ken Rossman Subject: Getting Kermit Files Keywords: FTP, Arpanet It seems to be a general problem with the ARPAnet backbone these days. There's been lots of speculation on what the actual problem is and how to solve it on lists like TCP-IP. In any case, the only thing I can recommend at this point in time is to try the file transfer during off hours and on weekends. I think I've had my best successes with FTP on Saturday nights/ Sunday mornings. Submit a batch job to get the files, so you don't actually have to be there at that time. /Ken ------------------------------ Date: Wed, 29 Oct 86 08:59:32 PST From: forags%violet.Berkeley.EDU@berkeley.edu Subject: F11 and F12 on new IBM PC Keyboard Keywords: IBM PC Keyboard Following is a note from our kermit guru, Greg Small (gts@populi.berkeley.edu) regarding patches he made to our version of Kermit to allow use of F11 & F12. The patches DO NOT specifically apply to any other versions of Kermit, but may provide a starting point for patching other versions. Al Stangenberger Forestry & Resource Mgt. U. C. Berkeley [Ed. - Thanks for the patch. Many people have asked about this. Greg's changes have been forwarded to Joe Doupnik for inclusion in the next release, coming Real Soon Now...] ------------------------------ Date: Mon, 3 Nov 86 18:10:24 pst From: thobe@ee.UCLA.EDU (Glenn Thobe) Subject: TSO Kermit Fix Keywords: TSO Kermit TSO Kermit v.1.1 appeared to be broken as file transfers would regularly fail at the same point in the transmission. I was advised to enter the following TSO command: profile char(bs) which totally fixed the problem. Apparently anything other than "bs" for this profile parameter causes some character translation which interferes with the incoming data. I hope this information will be of use to others. -Glenn Thobe [Ed. - This message has been added to the TSO Kermit beware file - KER:TSOKER.BWR ] ------------------------------ Date: Mon 3 Nov 86 23:42:40-PST From: Bob Larson Subject: Fix to os9 Kermit Server Keywords: os9 Kermit After seeing a rather vague bug report in the mod.os.os9 usenet newsgroup about os9 kermit, I did find the bug in the os9srv.c module of os9 kermit: It did not allocate space for the receive file name to go into. I have not tested this fix for the same reason I never tested the host mode originally: my system is not set up to answer the phone. The fix is rather straitforward (two lines of code) and obviously needed, so I am including the fixed os9srv.c at the end of this message. The answer to the question of who should get the os9 kermit bug reports is probably me, being the person who submited the last two versions to the columbia kermit archives and the latest to the os9 users group. Reports sent to info-kermit@cu20b.columbia.edu would probably get to me also. Bob Larson Arpa: Blarson@Usc-Eclb.arpa or Blarson@Usc-Oberon.Arpa Uucp: sdcrdcf!usc-oberon!blarson [Ed. - Thanks Bob! The new file KER:OS9SRV.C has replaced the old one. The old file has been moved to KO:OS9SRV.C.] ------------------------------ From: RBG.XX@GEN.BITNET Date: 11 nov 86 14:38 GMT +0100 Subject: Portable 68000 Kermit Keywords: 68000 Kermit [Ed. - This is from Roberto Bagnara, Physics Department, Bologna University (Italy), concerning a Kermit program he's developing for the Motorola 68000 family of processors, designed for portability among 68000 operating systems and assemblers, particularly those of the sort that are sold as turnkey systems for lab work, with little or nothing in the way of utility software or operating system support for many of the functions we take for granted. Anyone who has an interest in such systems, please respond to Roberto's questions directly, or through Info-Kermit. Thanks!] I'm writing to you, in order to clarify some points about the Kermit program that I'm developing. Here they are: a) I'm working hard, because I'd like to carry out my job by the end of this month. The first version of Kermit68K will be necessarily a preliminary one, due to the fact that, being employed at a department of physics, I haven't the advantage of a useful exchange of ideas, suggestions, etc. I need strong user/implementor feedback, in order to make the program effectively portable to different machines and operating systems, and to refine it, so that it works at its best. Having said all that, do you think that it's better to include it in the official distribution as a preliminary or you know any potential user/implementor, whom I can address to, in order to get this feedback? [Ed. - Any "alpha test" volunteers out there? If not, then let's just install the preliminary version for distribution.] b) Ensuring portability while maintaining, as much as possible, a unique source code would be a nice result. Unfortunately the assemblers differ, in general, in the syntax of the directives, besides some of them produce machine code directly, thus not allowing linking with other modules, that is separate assembly is impossible. Is there a public domain or highly diffused pre-processor for files inclusion and conditional text insertion ? That's all for now. Thank you very much. Roberto ------------------------------ Date: Mon, 3 Nov 86 23:24:09 est From: jpm@bnl.ARPA (John McNamee) Subject: More on CompuServe vs. Kermit Keywords: CompuServe Most CompuServe users access the service via CompuServe's own network, which has dialups all over the place. Very few come in via Telenet, Tymnet, etc. The CompuServe network nodes are quite smart and have large input buffers, and CompuServe may even move some or all of file transfer protocol handling off the mainframes and into the nodes. ------------------------------ Date: Mon 3 Nov 86 22:40:40-EST From: Russ Forster Subject: CompuServe and Kermit Keywords: CompuServe I have used compu-serv rather extensivly in the last little while and have experenced a number of problems in downloading files. This is partly due to going through DATAPAC here in the 'Great White North'. CIS does not support KERMIT at all and this can (and does) cause problems for us AMIGA owners. XMODEM pads out to 256 characters per line, so if the line is less, it gets filled with nulls. Because the AMIGA is multi- tasking, It must know the length of the file to find a place for it in memory. We AMIGAns have developed a number of Chomping programs to eat up the null's that XMODEM insists on putting in. The bottom line is yes Yes YES!!!! I would love to see KERMIT infiltrate these networks like CIS and PEOPLE LINK. Us AMIGIANS need it. /Russ ps. This was in response to the latest KERMIT digest. Disclaimer .. The above commnets are my own not my employeers. ------------------------------ Date: Thu, 6 Nov 86 18:08:14 pst From: thobe@ee.UCLA.EDU (Glenn Thobe) Subject: VAX/VMS Kermit to PROCOMM Keywords: VAX/VMS Kermit, PROCOMM In reference to Lawrence Clark's communication (IKD v.5, no.15), I have had difficulty transferring files from VAX/VMS Kermit-32 v.3.2.077 to Procomm v.2.4 on an IBM-PC (that's the other direction from what L.C. was trying to do). The transfer of a text file was successful but very slow. The VAX would send out a data packet immediately upon receipt of an ack and wait, time out, send a repeat of the data packet, wait some more, finally receive the ack, etc. This is just one experience, not a controlled experiment, so I wouldn't hasten to make any hard and fast judgements from it. -Glenn Thobe thobe@ee.ucla.edu (arpa) [Ed. - See the following messages...] ------------------------------ Date: Fri, 7 Nov 86 16:42:15 est From: Robert Montante Subject: PROCOMM's Kermit and the VAX/VMS Keywords: PROCOMM, VAX/VMS In response to Lawrence Clarke's question about ProComm's Kermit and VAX/VMS Kermit: I am using ProComm v2.42 for Kermit transfers quite successfully, to and from a VAX/VMS V4.2 with Kermit-32 (and also with ckermit running under UNIX on another VAX). I have noticed that both ProComm and the host Kermits make some default-setting assumptions that are incompatible (and occasionally inexplicable). Something like the "block check type" may need to be adjusted locally or on the host (or both); this was necessary to get me going on UNIX. ...Bob Montante... Datclaimer: "[Usual disclaimer: I have no opinion, therefore I don't exist .]" Disclaimer: I opine, therefore I am. My employer, however, is a figment. RAMontante Computer Science "Have you hugged ME today?" Indiana University [Ed. - Block check type is something that two Kermit programs are supposed to negotiate between themselves. It's possible that ProComm isn't doing this right.] ------------------------------ Date: Wed, 5 Nov 86 14:13:09 est From: phri!dvm!frank@columbia.edu (Frank Wortner) Subject: PROCOMM Kermit File Transfer Problems Keywords: PROCOMM I noticed the last Kermit Digest had a note from Lawrence Clarke about the difficulty getting PROCOMM and Kermit to speak to eachother. I've had this problem also. File transfers were OK when MSKERMIT 2.29 talked to C-Kermit 4C(58) on the VAX ( an 11/780 running DEC Ultrix ), but when PROCOMM 2.42 took over, the Kermit transfers simply stopped working. All was not lost, however, since I discovered that if I changed some of PROCOMM's line settings, everything worked again. I used the Line-Settings menu (Alt-P) to set the parity to space, and Kermit then happily resumed shipping files. I don't know how or why this worked, but if anyone out there wants to use PROCOMM to talk to Kermit, experimenting with parity bit settings is worth a shot. Frank Wortner UUCP: frank@orville.UUCP (... allegra!phri!orville!frank ) ------------------------------ Date: Tue, 4 Nov 86 08:58:17 EST From: rmcqueen (Robert C McQueen) @ sitvxb Subject: Kermit-32 and PROCOMM Keywords: Kermit-32, PROCOMM In response to Lawrence Clarke in the Info-Kermit Digest V5 #15: Try using at least version 3.2 of Kermit-32 to see if the problem still exists that and PROCOMM. We have fixed lots of random problems along the way and could have resolved this problem. Bob ------------------------------ Date: Tue, 4 Nov 86 12:16:52 pst From: black@ee.UCLA.EDU (Rex Black) Subject: How to Transfer Binary from UNIX to VMS? Keywords: C-Kermit, VAX/VMS Kermit, Binary Files My advice is to archive the file (since that changes format) and try that. If that fails, you know that it is NOT the data format which is tripping up the machine, but rather some form of hardware/communications problem between DEC and Pyramid. It's always a good idea to isolate your bug. Rex ------------------------------ Date: Tue, 11 Nov 86 23:03:16 est From: Bob Sutterfield Subject: VAX/VMS & Kermit Keywords: VAX/VMS Kermit In article <1679@ncoast.UUCP> btb@ncoast.UUCP (Brad Banko) writes: >Kermit dogs our VMS system down... whenever one of us uses kermit >to communicate over the modem, it really dogs our 11/750 down... it is >particularly bad when typing long messages or kermitting files... has anybody >else had this type of problem, and is there an easy fix? > I don't know if the problem is with VMS, or Kermit... Thanks. Yes, I've noted that problem on a 750 running VMS. Even at 1200 bps on a DMF-32 modem port, filling a screen (like by cat(1)ing a text file on the remote system) can grab over 90% of an otherwise-busy CPU (thus saith MONITOR). Curiously enough, unlike your report, I only saw the problem while CONNECTed to a remote system, never while SENDing or GETting a file to/from a remote server. The clue to the cause is to look (still via MONITOR) at all the buffered I/O that's going on in your process. Think about all those characters passing through the port drivers, the class drivers, etc. to get to your screen, generating high-priority interrupts as they go. It's pretty gruesome. I tried various permutations of the SYSGEN parameters concerning silo and DMA and typeahead buffer sizes, particularly the one that controls when the minimum-size thing that triggers a switch to "DMA mode" from character-by-character interrupt mode - I think it's TTY_DMASIZE (I no longer have any connection with VMS systems, so my memory is foggy of its name). Nothing seemed to help me. It seems to me that the only way to improve this problem would be to make Kermit much more intelligent about VMS guts, in order to bypass some of the layers that characters have to go through. This, of course, would make it much less portable, even to new versions of VMS, as the terminal driver is wont to change occasionally. Like, apparently, with new major releases of the operating system. ------------------------------ Date: Wed 5 Nov 86 16:58:31-EST From: Christine M Gianone Subject: C-Kermit and Xenix 3.0 Keywords: C-Kermit, Xenix Has anyone has any experience running C-Kermit under the Xenix operating system, version 3.0A, on the AT? If you got it to work, what "make" options did you use, or what modifications did you make to the source? We're getting a lot of questions about this. ------------------------------ Date: Wed, 5 Nov 86 13:59:29 est From: munnari!latcs1.oz!philip@seismo.CSS.GOV (Philip Lee) Subject: Re: FIDO - UNIX Kermit problem Keywords: FIDO, C-Kermit, UNIX Kermit Found the problem, FIDO kermit allways sends out file with 8th bit quoting (with '&' prefix), even when you come in with 8 bits and no parity! I should've guessed it when the received binary file is bigger than the original. I've been told that it would be fixed in the next version of FIDO, the one I've been connected to runs on ver 11W. Philip P.H. Lee, La Trobe University, Dept. of Computer Science, PHONE: +61 03 478 3122 ext 2902 Bundoora, A/CSnet:philip@latcs1.oz Victoria 3083, ARPA: philip%latcs1.oz@seismo.css.gov AUSTRALIA. UUCP:{seismo,hplabs,mcvax,ukc,nttlab}!munnari!latcs1.oz!philip [Ed. - There have been many complaints from people downloading ARC files from FIDO BBS's with Kermit that the files cannot be successfully unARC'd. This could be the problem! A cursory examination of a packet log shows that 8-bit quoting was not negotiated, but was used by FIDO anyway, so that the resulting downloaded file was filled with extraneous & characters. We'll try to check this in more detail.] ------------------------------ Date: Fri, 7 Nov 86 08:07 ??? From: RLH Subject: Rainbow MSKERMIT initialization Keywords: MS-DOS Kermit, DEC Rainbow Does anyone have a good .INI initialization file for the MS-DOS version of Kermit on a DEC Rainbow? What I want to do is to get the terminal emulation to look as much like a VT200 series terminal as I can - particularly as far as having the function keys transmit the right sequences so that I use the key definition facilities of VAX/VMS and the TPU editor. If you have a .INI that does a good job of this, would you send me a copy? thanks, Bob Haar [Ed. - Try KER:MSIRB2.INI on CU20B (MSIRB2 INI from KERMSRV). You're welcome.] ------------------------------ End of Info-Kermit Digest ************************* ------- 21-Nov-86 16:34:02-EST,15396;000000000000 Mail-From: SY.CHRISTINE created at 21-Nov-86 16:32:41 Date: Fri 21 Nov 86 16:32:40-EST From: Christine M Gianone Subject: Info-Kermit Digest V5 #17 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12256778044.71.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Fri, 21 Nov 1986 Volume 5 : Number 17 Today's Topics: WISCVM Arpa/BITNET Mail Relay Congestion HP9845 Kermit Okstate Kermit Service Available Once Again Re: C-Kermit and Xenix 3.0 FIDO and Kermit Error in CP4KER.DOC Amiga kermit C-Kermit 4D(060) Help needed on Kermit-32 and X25/X29 Kermit and CompuServe ---------------------------------------------------------------------- Date: 14 November 86 18:34 EST From: Larry Landweber Subject: WISCVM Arpa/BITNET Mail Relay Congestion Keywords: BITNET, Arpanet Because of Arpanet congestion problems, our WISCVM mail relay is unable to keep up with the quantity of mail sent to it for forwarding. While the problem is particularly acute in the Bitnet to Arpanet direction, the level of traffic in both directions is a problem. A large part of this traffic results from mailing lists. Furthermore, while we are usually only sent a single copy of a list mailing, the recipient list is often very long. A single message may require the sending of over a hundred copies. This is a problem for two reasons... Arpanet congesion makes it difficult at times to establish and keep TCP connections and such connections are slow; second, the implementation of the gateway at present makes multiple copies for forwarding (a poor design choice that is being worked on). At present, the first problem is far [more] significant. To alleviate the problems cited above and enable us to provide a reasonable level of service, we are asking Arpanet list maintainers to provide list exploders on Bitnet and vice versa. Your cooperation will be very much appreciated. Note that in a about a month we will begin limiting the number of copies we will relay by putting a limit on the number of recipients in RCPT TO lines in SMTP and BSMTP. This limit is likely to be 10. Gligor Tashkovich has agreed to help coordinate the process of putting maintainers on one net in touch with relevant people on the other list. Thanks in advance for your cooperation in this matter. Larry Landweber cc: NIC @ SRI-NIC.ARPA CIC @ SH.CS.NET INFO @ BITNIC PEB @ CERNVM [Ed. - This is a serious problem. There is not a lot of duplication in the Info-Kermit list; only a few hosts appear more than twice (they are VTVM1 (6 times), CALSTATE (5), BROWNVM (3), DACTH51 (3), DBNRHRZ1 (3), UMKCVAX1 (3), and UREGINA1 (3)). If the subscribers at those hosts could arrange to combine themselves into a local redistribution list, that would be appreciated. Meanwhile, we'll try to work out some arrangement so that mail to BITNET subsribers won't be arbitrarily discarded. But success can't be promised.] ------------------------------ Date: Fri 21 Nov 86 12:00:35-EST From: Christine M Gianone Subject: HP9845 Kermit Keywords: HP9845 Kermit In Info-Kermit Digest V5 #16 HP9845 Kermit was announced to be in the file KER:HP9845.*. Accidentally, the files were placed in KER:HP9KER.* This has been corrected. Sorry for any inconvenience. ------------------------------ Date: Tue, 18 Nov 86 16:05:28 -0600 From: Mark Vasoll Subject: Okstate Kermit Service Available Once Again Keywords: Okstate I have reenabled the dial-in modem and about 45 seconds after doing that someone had logged into uucpker and started grabbing stuff. Looks like there is still plenty of demand! Cheers, Mark ------------------------------ Date: 13 November 1986 0810-PST (Thursday) From: bierma@nprdc.arpa (Larry Bierma) Subject: Re: C-Kermit and Xenix 3.0 Keywords: C-Kermit, Xenix I got kermit running on an AT running IBM's XENIX 1.0 (which is supposedly the same as Microsoft XENIX 3.0) with no problems. Unfortunatly I don't remember what "make" option I used and I no longer have the machine. If no one else gives you better information let me know and I'll get access to the machine and check what I did. Larry ARPA: bierma@nprdc.arpa UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdics!nprdc!bierma PSTN: (619) 225-2161 [Ed. - Well, there is some feedback. Does anyone have more information?] ------------------------------ Date: Fri, 14 Nov 86 13:52:40 CST From: plocher@puff.wisc.edu (John Plocher) Subject: FIDO and Kermit Keywords: FIDO, Kermit The Fido kermit problem is deeper than just 8 bit quoting... I downloaded an ARC file and ran a simple filter on it to expand 8 bit quoting... BOMB! The file became much shorter than the original and would not unarc. Is this because the 8bit decoding can't be done outside of the kermit state machine? I'm confused as to how to fix this problem: setting my kermit to use a 7 bit line with 8 bit quoting does NOT seem to get rid of the problem! "Never trust an idea you get sitting down" - Nietzche {harvard,seismo}!uwvax!uwmacc!uwhsms!plocher (work) John Plocher {harvard,seismo}!uwvax!puff!plocher (school) decvax!encore!vaxine!spark!121!0!John_Plocher (FidoNet) ------------------------------ Date: Mon, 17 Nov 86 11:35 N From: Subject: Error in CP4KER.DOC Keywords: CP/M Kermit Dear Kermit-eers, There are two tiny little errors in the file CP4KER.DOC. A small 8080-assembler program is listed which should downline-load the Kermit-hex-files from a DEC20-system to a CP/M-microcomputer. line 015A shows: jm 170 This should be: jc 170 line 0167 shows: jm 170 This should be: jc 170 Change the above lines and it really works! A happy Kermit-eer, .KeesdeGroot (DEGROOT@HWALHW50) [Ed. - Thanks for the bug report and the fix. This message has been added to KER:CP4KER.BWR. This whole program was replaced in the second revision of the sixth edition of the Kermit User Guide but this file has not yet been updated.] ------------------------------ Date: Mon, 17 Nov 86 21:55 EST From: Subject: Amiga kermit Keywords: Amiga Kermit Cross-Ref: Commodore Amiga (see also Amiga Kermit) This may or may not be of interest to anyone there. I obtained what I believe is the latest version of Amiga Kermit from the Columbia Kermit server a couple of months back. (I used the earlier one before that.) This newer version is rather nice, except that it doesn't seem to be able to generate even parity. The old version worked fine, this newer one does not seem to generate even parity (at least, not the even parity that the local IBM 3081 likes) under release 1.1 of AmigaDos. I've tried it with the 1.2 beta serial.device, but no luck. I haven't made any attempt at fixing it; I am NOT a C programmer (yet?). Rick Pim ------------------------------ Date: Tue, 18 Nov 86 02:01 EST From: Kuryan Thomas Subject: C-Kermit 4D(060) Keywords: C-Kermit [Ed. - The latest version of C-Kermit is 4D(061)] This is Kuryan Thomas at Virginia Tech Physics department. Some months ago I reported a problem with C-Kermit running on my AT&T PC6300PLUS under UNIX System V. I couldn't get the dial command to work -- I would always get an error like "Can't hang up the phone" or "Communications Disconnect." After some time as a UNIX administrator and programmer, I've managed to debug the problem. In function tthang() in ckutio.c, the phone is hung up by using ioctl() to set the baud rate on the port to 0. This, I believe, is standard UNIX procedure. On my particular system, though, this operation always fails with ioctl() signalling an error (-1) and setting errno to ENXIO (No such device or address). This is definitely a bug, because the phone IS correctly hung up (DTR line is dropped). The fix is to simply ignore error returns from the hang-up ioctl() in tthang() (that's the first ioctl() call in tthang()). [Ed. - Since this error might be significant on other systems, maybe the best thing would be to report any error returned by this ioctl(), but then proceed anyway.] I uncovered a few other problems, all of which I found (rather kludgy) fixes for. First, the dial command cannot work unless carrier detect is asserted on the terminal line. My modem, a Prometheus 1200, refuses to accept the commands. (Or my tty port refuses to behave correctly, I'm not sure which.) The fix is to strap CD high with the DIP switches on the bottom panel. [Ed. - This sounds like another problem with your system. Obviously, CD will not be asserted until the phone call is completed and carrier is detected. The system should not require CD to be on while dialing. Strapping CD high, of course, prevents Kermit or any other program from telling when carrier really drops.] Next, my computer, like the 3BX series, expects its lock files in the directory /usr/spool/locks, rather than /usr/spool/uucp. The problem is that the former, unlike the latter, is writable only by the uid uucp. It might appear that the solution is to make ckermit owned by uucp and set the set-uid bit, but ckermit uses the access() system call to check write access to the lock directory. access() uses REAL uid's to check access, not effective uid's. Therefore, set-uid is ineffective. The only fix I could think of was to remove the lines in look4lk() that report an error if access() says there's no write permission in the lock directory. If the set-uid trick is used, all is well and the lock file is created. If you forget to set the set-uid bit or something else goes wrong, the attempt to creat() the lock file fails with an error like "Couldn't gain exclusive access of lock file" or words to that effect. [Ed. - It seems like every variant of Unix on every different kind of system puts the "lock files" in different places. And what's more, each installation sets the permissions differently. Perhaps the next release of UNIX Kermit will make the lock file location a makefile option, to emphasize that it has given up all hope of knowing where to find it.] Finally, the problem of having Kermit hang up the phone when you return to the shell (thus terminating the conversation) can be solved by strapping DTR high with the modem's DIP switches. Ckermit can no longer hang up the phone correctly, but if you often return to your local shell in the middle of a remote session, the convenience is worth it. And, of course, the remote end is usually able to hang up the phone correctly when you are done with it. [Ed. - Or you can push from Kermit to an inferior shell, leaving the connection active and all Kermit settings intact -- use the "!" command at prompt level. A "push" escape will probably also be added to the 'connect' command in the next release. Setting the modem's "ignore DTR" switch prevents the modem from noticing when your system crashes, and terminating the connection, resulting in potentially big phone bills if this happens during unattended Kermit or UUCP operation.] Hope this will be of help to someone. ------------------------------ Date: Wed, 19 Nov 86 15:32 GMT From: Jan Peter Stuart 19-NOV-1986 15:37 Subject: Help needed on Kermit-32 and X25/X29 Keywords: Kermit-32 I was dissappointed to find after my note in newsletter 92, that possibly no one else uses Kermit-32 on a vax at the end of an X25 line. So far I have been singularly unsuccessful in getting anything to function on the outside world! The problem is now a bit clearer at least. Kermit-32 was designed to use a vax terminal line. I have no terminal lines to the outside world, only an x25 connexion that terminates at a DEUNNA board in the vax. Thus no hardware PAD! I can certainly establish connections thru the vax X25 without kermit but does anyone know how to tell kermit-32 to set up an x25/x29 type of call ???? If I find no other uk users in this position, is there any way I can request help from the source ? (USA) ? Yours hopefully, Jan Stuart. also direct at uk.ac.rl.gm ------------------------------ Date: Thu, 20 Nov 86 09:18:39 PST From: Steve Walton Subject: Kermit and CompuServe Keywords: CompuServe Adding fuel to the fire... I have had the experience of using Kermit over Telenet. It was not pleasant. The remote system was the WELL, a 4.2BSD Vax 750 in Berkeley, and the local system was my Amiga. Version 4D(061) of C-Kermit was used at the WELL end, and a PD terminal emulator at the Amiga end. Efficiency was 25%. (Has anyone ever seen C Kermit do better than 65% efficiency?) I finally gave up on Kermit, and am now using the 1024-byte-packet version of XMODEM for WELL communication. Compuserve "B" protocol uses 511-byte packets, which seem to work fine over Tymnet, Telenet, and the CompuServe net. PeopleLink offers XMODEM and a new one called "Windowed XMODEM" (!) to get around the delay problems. When I first arrived on PeopleLink, I suggested windowed Kermit to them as a new protocol. I haven't asked why they didn't adopt it, but suspect it was because windowed Kermit is basically nonexistent (except possibly for some alpha test versions and the IBM PC-only one from the Source). So is windowed XMODEM, but XMODEM is much closer to universal than Kermit, and is easily modified to add the window support. After all, we're talking a strict 8-bit asynch-to-asynch one file at a time protocol. I love the little green guy, and use it whenever I have a direct connect line between two machines. But it's a big lose on the packet-switched nets, and when you're paying by the minute, that's important. Stephen Walton ARPA: ametek!walton@csvax.caltech.edu Ametek Computer Research Div. BITNET: walton@caltech 610 N. Santa Anita Ave. UUCP: ...!ucbvax!sun!megatest!ametek!walton Arcadia, CA 91006 USA 818-445-6811 [Ed. - Windowed Xmodem is not exactly what you might think -- Since Xmodem does not have replies (ACKs and NAKs) that are in packet form so that they can indicate WHICH packet they are ACKing or NAKing, true sliding windows cannot be supported by any of the MODEM family. What Windowed Xmodem does is cancel the entire file transfer if any error is detected. So it's fast when it works, but "infinitely slow" when it doesn't. C-Kermit will eventually have support for both long packets and sliding windows.] ------------------------------ End of Info-Kermit Digest ************************* ------- 8-Dec-86 16:40:34-EST,19107;000000000000 Mail-From: SY.CHRISTINE created at 8-Dec-86 16:30:14 Date: Mon 8 Dec 86 16:30:14-EST From: Christine M Gianone Subject: Info-Kermit Digest V5 #18 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12261234047.28.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Mon, 8 Dec 1986 Volume 5 : Number 18 Today's Topics: PERKIN-ELMER 7000 Series Kermit NIH TSO Kermit Version 1.0 BITNET Distribution More on FIDO and Kermit SCO Sys V/286 Xenix Kermit 4C Use of Unix Kermit on Packet Switched Network VAX/VMS Kermit-32 and X25/X29 Micro_Vax II problem with modem interface HP9845 BASIC Kermit Kermit for RSX-11/M v3.2 and/or Hyperion PC? Problem with P-E Kermit? PR1ME Kermit with connect capability? ---------------------------------------------------------------------- Date: Mon 8 Dec 86 11:32:34-EST From: Chris Lent Subject: PERKIN-ELMER 7000 Series Kermit Keywords: Perkin-Elmer, Concurrent I've gotten a Kermit for the Perkin-Elmer 7000 Series computers which are IDRIS based. It's loosely based on the old C-Kermit from the old Protocol manual. It has Binary file (8-bit and &-quoting), Repeat quoting and server mode (GET,SEND,and FINISH). It has no connect mode, as the 7000 series comes with the cu(1) command which does the same thing. I didn't create this version (Dan Eisner of Perkin-Elmer did), but I did create a bootstrap document. I translated the bootstrap programs so that I'm using an existing format for encoding the binary files. For its size it's one of the most solid Kermit's I've seen so far. Chris Lent "phri!cooper!chris"@NYU.ARPA OC.PEDHEM@CU20B.COLUMBIA.EDU ------------------------------ Date: Fri, 05 Dec 86 23:33:18 EST From: "Roger Fajman" Subject: New NIH TSO Kermit Version 1.0 Keywords: TSO Kermit, IBM Mainframe I would like to announce the availability of the NIH TSO Kermit Version 1.0. The following summarizes its capabilities: NIH TSO Kermit Capabilities At a Glance: Local operation: No Remote operation: Yes Transfers text files: Yes Transfers binary files: Yes Wildcard send: Yes XX/XY interruption: Yes Filename collision avoidance: No Timeouts: Yes 8th-bit prefixing: Yes Repeat character compression: Yes Alternate block check types: Yes Communication settings: No Transmit BREAK: No IBM mainframe communication: Yes Transaction logging: No Session logging: No Debug logging: Yes Raw transmit: No Login scripts: No Act as server: Yes Talk to server: No Advanced commands for servers: No Local file management: Yes Command/init files: Yes Handle file attributes: No I am sending a tape to Frank da Cruz at Columbia so that NIH TSO Kermit can be included on the regular Columbia distribution tapes. When the files are available on KERMSRV, ask for TSNKER.TXT to see the installation instructions. There are 8 required files, plus 13 more if you want the source. NIH TSO Kermit may also be obtained directly from NIH by sending a letter of request and a tape to the following address: Joseph D. Naughton Chief, Computer Center National Institutes of Health Building 12, Room 2244 Bethesda, MD 20892 There is no charge. The NIH version of TSO Kermit is an extensive modification and rewrite of the University of Chicago TSO Kermit, which in turn was based on an early CMS Kermit developed at Columbia University. The external design was done by Roger Fajman and Dale Wright. The internal design and programming was done by Dale Wright. ------------------------------ Date: Wed, 03 Dec 86 13:02:24 EST From: Harold C Pritchett Subject: BITNET Distribution Keywords: BITNET Please add: I-KERMIT@UGA.BITNET to your distribution list. This is a BITNET List server which will allow BITNET users to subscribe and receive copys of your list without having to transverse the WISCVM gateway. After this is done, you might want to announce the availablility of this list as an alternative method for your BITNET subscribers to receive this list. For a BITNET user to subscribe to this list, they can issue the command TELL LISTSERV AT UGA SUB I-KERMIT Users Name (from VM/370) SEND LISTSERV@UGA SUB I-KERMIT Users Name (from VAX/VMS) All other users can send RFC-822 mail to LISTSERV at UGA where the first of the message text (the line after the blank delimiter line) is SUB I-KERMIT Users Name [Ed. - Thanks. BITNET subscribers might want to try this new service and if it works okay, they may want to switch from Info-Kermit at CU20B to I-KERMIT, in order to relieve congestion at the WISCVM gateway.] ------------------------------ Date: 1986 Nov 21 22:14 EST From: (John F. Chandler) Subject: More on FIDO and Kermit Keywords: FIDO It should be obvious that if the two Kermits mis-negotiate the state of 8-bit quoting there can be irretrievable garblings. In particular, assuming the sender thinks "&" is the 8-bit quote, all occurences of "&" get sent as "#&", which is garbage if the receiver thinks there is no 8-bit quoting. The "#&" is probably converted to "f", but it could depend on the implementation! If it, in fact, comes out as "&", then a post-reception filter would try to merge it with the following character anyway. If there is garbling even when the two Kermits claim to agree on the quoting state, it might be a good idea to send a short file with a few mixed 7- and 8-bit byte values. Then you'll have a clue as to what's happening. [Ed. - Actually, translation of "#&" to "f" is improper, because "&" is not in the range of encoded control characters. The "#" operator should "controllify" the following character only if it is in the range 63-95 (decimal), otherwise it means "take the following character literally". But you're right, there are some Kermit implementations that do not follow this rule.] ------------------------------ Date: Sat 29 Nov 86 21:08:53-MST From: Mike Niswonger Subject: SCO Sys V/286 Xenix Kermit 4C Keywords: Xenix Help!!, There seems to have been a lot of hassles stirred up about what is necessary to run which version of C-Kermit on which version of Xenix. I would like to compile a full list of users who have Kermit up and running on a Xenix system. Please include the following information: User name and net address Hardware: manufacturer, model, CPU (8086, 80286, etc), configuration SPECIFIC Xenix version including: . Source (IBM, Microsoft, SCO, Tandy) . Sys III, Sys V, V7, "Sys V with Berkeley features", etc. . Xenix release version (very important) . Development system (compiler) version Edit level of C-Kermit used (should be 4D(061)) Specific fixes, patches, workarounds, actual flags used during compilation (please don't just say "see makefile") I realize that this may require some digging, but please help out. I have been working (on and off) trying to bring up Kermit on a friend's SCO Xenix 286 / Sys V AT clone for almost a year, with little success. From some of the notes that I have seen, I am not alone. A compilation of the results will be submitted to CU20B when complete. -- Mike Niswonger, CNiswonger@Simtel20.arpa [Ed. - As we've noted in previous postings, "Xenix" is almost a meaningless label, except that it means a operating systems that resembles one or more versions of Unix. Thus, it has proven next to impossible for us to tell people how to bring up C-Kermit under "Xenix". If we had a list of all the different incarnations of Xenix along with the parameters that Mike has listed, it would help a lot.] ------------------------------ Date: Mon, 24 Nov 86 12:49:10 WET From: Bruce Wilford { 01 387 7050 x 3691 } Subject: Use of Unix Kermit on Packet Switched Network Keywords: Unix Kermit, C-Kermit, X.25 People connect to our machine from all over the UK via an X25 network. Some have to pay for this and therefore need to use message (line) mode. If they are in line mode the characters will not be forwarded until the is typed at the end. This would ruin the effect of command completion, with ESC and things like ? being picked up immediately. [Ed. - First, note that you do not HAVE to use command completion, ESC, or ? when talking to C-Kermit. You can use it as a traditional Unix command, with command-line options, as documented in the manual (or type "kermit -h" for a brief summary). During interactive use, if you configure your PAD to use only CR as the data forwarding character (X.3 parameter 3, value 3), then you will simply not have the special features available to you at your terminal; you can still type the commands. You can use X.3 PAD commands to change your data forwarding characters; for instance "SET? 3:14" will allow forwarding on CR, ESC, DEL and a few other control characters, but not ^U or "?", which are also used by the interactive command parser. "SET? 3:72" will cause forwarding on any control character. There's no X.3 selector for "?". You can also configure the PAD to let you do local editing when in line mode (X.3 parameters 15-18). During file transfer, Unix Kermit puts the communication line into "rawmode" which, in some Unix implementations, causes the Unix system to tell the network to do character-at-a-time i/o, which means one character per packet, which is unnecessarily expensive when you're paying by the packet. Future releases of Unix Kermit may provide some kind of workaround for this.] ------------------------------ Date: Sun, 23 Nov 86 16:47:10 EST From: Richard_S._Conto@um.cc.umich.edu Subject: VAX/VMS Kermit-32 and X25/X29 Keywords: VMS Kermit, X.25 In Info-Kermit dgest V5 #14, Jan Peter Stuart asked about using Kermit-32 to connect out through an X.25 PSI interface to the outside world. Unfortunately, I am in the same situation. However, since our users can usually loop around in our network (Merit), and come back in to use it as a remote kermit, our need is not overly pressing. There are other VAX/VMS systems attached through X.25 interfaces to Merit, though, and any real, software solution would bre greatly appreciated. Richard S. Conto University of Michigan Computing Center 1075 Beal Ave. Ann Arbor, Mi. 48109, USA ARPA/Internet: Richard_S._Conto@UM.CC.UMICH.EDU [Ed. - Bob McQueen, the author of VMS Kermit, says that he'd be willing to look into adding X.25/29 PSI support, but (1) he doesn't have an X.25 PSI system at his site, and (2) he doesn't have any documentation on the interface. If someone can provide the details of the VAX/VMS X.25 interface (does it look like a normal terminal? Do you send special X.28 control sequences to the PAD? etc) and would be willing to test the results, please contact Bob as "rmcqueen%sitvxb.CCNET"@CU20B, or through Info-Kermit. Results cannot be promised.] ------------------------------ Date: 25 Nov 1986 12:07-EST From: DEC PC BBoard Subject: Micro_Vax II problem with modem interface Keywords: VMS Kermit We have recently got a Microvax II and are facing some problems in connecting the MUX ports to modem. I am here a faculty member in Electrical Engineering at North Dakota State University Fargo, North Dakota, USA. The problem is as follows: 1. When the prot, e.g. TXA0 is defined as MODEM port, using SET TERM command, after a user logs in through that port, he is logged out in about 30 seconds with a message, SYS - E - HANGUP. If the port is not defined as a modem, by the command SET TERM/NOMODEM then this hangup does not occur, but if the modem is switched off without the user having logged off, the user is not logged out and anybody who comes in through that port is in effect working as the 'old' user. This is a big security risk Did you come across any such problem. We are here using a PACKSnetwork which uses Gandolf modems. The operating system is VMS 4.4 and the port controllers are DHV-11. I shall be very thankful for your suggestions. K.Sankara Rao [Ed. - Reply from Bob McQueen: "This person is talking about setting VMS parameters on his terminal lines and is doing it incorrectly from what I read. I'd guess from the message that the problem he is having is that the device requires DTR to be raised and the modem he is using doesn't (or the terminal cable doesn't have the line)." We get questions like this all the time. What we need is a quick guide to VMS DCL parameters for using Kermit in various situations -- direct connect, dialin, dialout, etc. We'll try to come up with something like this.] ------------------------------ From: uw-apl!apl-em!dunlap@beaver.cs.washington.edu Date: Thu, 20 Nov 86 09:46:29 pst Subject: HP9845 BASIC Kermit Keywords: HP9845 Kermit, BASIC Kermit Our HP9845's do not recognize the following: Mass Storage Unit Specifier ":Q" CCOM, CMODEL, CCONNECT, CDISCONNECT, CCONTROL, CSTAT, CWRITE, CREAD Block if: IF THEN, ELSE, END IF on separate lines Case selection: SELECT, CASE, END SELECT on separate lines These keywords are in fact in ROMs we don't own. According to our HP service engineer: > Mass Storage Unit Specifier ":Q" This is the msus for the "HP7908" disc. > CCOM, CMODEL, CCONNECT, CDISCONNECT, CCONTROL, CSTAT, CWRITE, CREAD These commands are found in the Datacomm ROM, which can only be used with the HP98046 Datacomm interface. > Block if: IF THEN, ELSE, END IF on separate lines > Case selection: SELECT, CASE, END SELECT on separate lines These are found in the Structured Programming ROM, along with many other useful commands like XREF and INDENT. Since we don't have the above and have no plans to purchase I am considering redoing the code a little to use the more common I/O ROM and HP98036 serial interface. I already have written a terminal emulator which performs quite well (keeps up at 1200 bps) so I don't forsee any great difficulty. On the down side I cannot say when I can get to it. In any case there should be some words in the HP9845 kermit distribution about the above ROMs and I/O cards being required. I don't think the mass storage unit specifier (MSUS) problem is serious -- people can change that to their usual MSUS. [Ed. - HP has such a variety of products, and so many of them come with BASIC as the only standard (or only, period) programming language, that it would be very desirable to have a relatively portable HP-BASIC Kermit, if indeed there is some subset of the language that is consistent across the HP line, and which does not require special ROMs and options (Is there???). Meanwhile, your message has been added to the "beware file" for this version of Kermit.] ------------------------------ Date: Mon, 24 Nov 86 07:26:18 EST From: Noah Diesbourg Subject: Kermit for RSX-11/M v3.2 and/or Hyperion PC? Keywords: Kermit-11, Hyperion PC Is anyone running Kermit on a PDP 11/34 with RSX 11M ver 3.2 or a Hyperion PC? [Ed. - According to K11INS.DOC, the minimum version of RSX that Kermit-11 can run under is 4.1. The author's advice to people in this situation is to upgrade. It is recognized, however, that there are many old PDP-11 systems out there that can't be easily upgraded. There are rumors of bare-bones remote-only Kermit programs written in Fortran for earlier releases of RSX, but none of these programs has yet surfaced. If anyone wants to send one in, it would be appreciated. The Hyperion is an IBM-incompatible MS-DOS system, and should be able to run "generic" MS-DOS Kermit.] ------------------------------ Date: Tue, 2 Dec 86 11:39 EST From: (brian nelson) Subject: Problem with P-E Kermit? Keywords: Perkin-Elmer Kermit This was sent to me by someone using kermit dialup access here. Anyone know about Perkin-Elmer Kermit? Brian@Uoft02.Bitnet > From: DRWHO::KERMIT 2-DEC-1986 11:33 > Submission by: > Richard J. Zirbes > (303) 236 5812 > U.S. Geological Survey > BOX 25046 MS 516 > Denver, CO. 80225 > Environment: > OS/32 Version 8.1.2 (not 8.2) > all perkin.* files in my work area. > Problem 1: > Source compiles fine using d and o compilers, links okay > however; when trying to start up using KERMIT.INI file I get: > SVC ADDRESS ERROR > INST @17A92 > SVC PARAMETER BLOCK > AT C770 > MEMORY FAULT ADDRESS Z39C1 > TASK PAUSED. > also; when I use another file such as KINIT.DAT in the command > line: KERMIT KINIT.DAT > the results are the same. > The files KINIT.DAT and KERMIT.INI look like: > SET PARITY EVEN > SET PACKET 90 > SET FCHEK OFF > SET 8BIT OFF > SET SEOR LF > SET FILE TEXT > EXIT > Problem 2: > I run kermit without an initializer file and enter the parameters > defined above interactively and send a file to my ckermit I get > transmission errors and kermit-co times out. Ckermit has settings: > mode: local > parity: even > duplex: full > flow: xon/xoff > handshake: none > packet start: 1 > packet end: 13 > packet length: 90 > block check type: 1, delay: 5 > 8th bit prefix '&' > File Names: converted > File Type: text > Please contact me with any solutions. Thank you. ------------------------------ Date: Tue, 02 Dec 86 09:07:00 PST From: jfisher@USGS3-VMS Subject: PR1ME Kermit with connect capability? Keywords: Prime Kermit I am in need of a Kermit implementation for PR1ME machines that can be run in local mode, 'dialing-out' through a comm. port to another mini Kermit, so as to transfer files between them. I spoke to Leslie Spira of The Source, who said she didn't have one, but she had a vague recollection that somebody else might have modified her PR1ME Kermit to allow it to connect out. Does anybody out there have such a beast ? ------------------------------ End of Info-Kermit Digest ************************* ------- 19-Dec-86 12:09:28-EST,18669;000000000000 Mail-From: SY.CHRISTINE created at 19-Dec-86 12:07:37 Date: Fri 19 Dec 86 12:07:37-EST From: Christine M Gianone Subject: Info-Kermit Digest V5 #19 To: Info-kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12264069824.321.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Info-Kermit Digest Fri, 19 Dec 1986 Volume 5 : Number 19 Today's Topics: New Kermit Program for IBM 370 Mainframes with MVS/TSO Kermit-MPX version 2.3 Misuse of Okstate services C-Kermit and Xenix C-Kermit on Microport Unix Uploading Macintosh Binhexes with Kermit Bug in Apollo Pascal Kermit Prime kermit connect Kermit and X.25 Problem with HP9845 Kermit HCP and HC6 Versions of Kermit Need Fast De-BOOing Program for the Amiga Data General MV2000 Kermit 3.1 - An interesting speed problem Symbolics V7.0 Kermit ---------------------------------------------------------------------- Date: Thu 18 Dec 86 15:31:12-EST From: Frank da Cruz Subject: New Kermit Program for IBM 370 Mainframes with MVS/TSO Keywords: MVS/TSO Kermit The new IBM 370-series mainframe MVS/TSO Kermit from the US National Institutes of Health (NIH), announced in the previous Info-Kermit digest, is now available in the Kermit distribution areas under the prefix TSN. There are 21 files, comprising a total of about 3 megabytes, including three documentation files and a TSO help file. The program is written in "ALP", which is a preprocessor for 370 assembly language developed at NIH. The ALP preprocessor, also supplied, is written in PL/I. For those who do not have PL/I or do not wish to bother with the source programs, a hexidecimal-encoded object file is provided, along with an assembler program to decode it into a binary object file; this can be linked with a tailorable module (written in straight assembler) in which site dependencies, such as the ASCII/EBCDIC translations, are specified. Before deciding to transfer all 3 MB from Columbia over a network, first get the file TSNKER.TXT, which explains which files are which, and then only get the ones you really need. Thanks to Roger Fajman at NIH (RAF@NIHCU.BITNET) for submitting this program to us. Roger participated in the design with Dale Wright, who then did the programming. The new program has many advanced features over previous TSO Kermit versions, including server mode, binary file transfer, file interruption, 8th-bit prefixing, run-length encoding, alternate block check types, and support for both 3705-style line mode and Series/1-style full screen emulation. It is hoped that this new version will render the old University of Chicago (linemode only, circa July 1984) and University of Toronto versions (Series/1 only, March 85) obsolete. Reactions from TSO sites will be appreciated, in the interest of keeping redundant Kermit versions at a minimum. Reactions from users of the Pascal/VS version from the University of Bern (linemode only, Sept 86) will also be appreciated. For the present, the Chicago, Toronto, and Bern versions remain available in the Kermit distribution under the prefixes TSO, TSO, and TS2, respectively. For the future, there may still be another TSO Kermit program on the horizon, a result of a cooperative effort among IBM mainframe Kermit sites to develop a Kermit program that is portable among all IBM 370 mainframe operating systems (no estimate as to when this will be ready, but IBM mainframe system programmers who are interested in developments in this area may send mail to IBM-KERMIT@CU20B or IBM-KERMIT@CUVMA). ------------------------------ Date: Sun 7 Dec 86 22:40:44-MST From: Mike Niswonger Subject: Kermit-MPX version 2.3 Keywords: Gould, SEL, MPX The latest version of Kermit-MPX (GM2) for Gould machines is now available for you to FTP from my directory at Simtel20. All files are found in directory PD:GM2KERM.*. This release 2.3 of Kermit-MPX, which is also being submitted to the Gould User's group library. -- Mike Niswonger [Ed. - Thanks Mike! The files are also available through KERMSRV at CUVMA and on CU20B using FTP (user ANONYMOUS), any password. These files have replaced the old KER:GM2*.* and the old files are now in KO:GM2*.*] ------------------------------ Date: Mon, 08 Dec 86 18:50:27 -0600 From: Mark Vasoll Subject: Misuse of Okstate services Keywords: Okstate, Oklahoma State Fellow Kermiters, It saddens me to inform you all that various people have started to abuse the UUCP login "uucpker" on Okstate by attempting to use us as a jumping off point for mail. While we enjoy providing the home for Kermit access via UUCP, we have no desire to become a major mail relay point for various random systems. To this end, I have had to place a restriction on our UUCP to not accept the "rmail" command from any system using the uucpker account. This will, unfortunately, make it more difficult for people to report problems to okstate!uucp-support, but there is very little I can do about it. Please use the following mail paths when reporting problems with the Kermit distribution (no phone calls please). Internet: uucp-support@a.cs.okstate.edu or: uucp-support%a.cs.okstate.edu@csnet-relay.arpa UUCP : {cbatt, cbosgd, ihnp4, pesnta, rutgers, seismo}!okstate!uucp-support Mark Vasoll Computing and Information Sciences Internet: vasoll@a.cs.okstate.edu Oklahoma State University UUCP: {cbatt, cbosgd, ihnp4, pesnta, Stillwater, Oklahoma rutgers, seismo}!okstate!vasoll ------------------------------ Date: Tue, 9 Dec 86 08:05:48 EST From: Marshall_DeBerry@um.cc.umich.edu Subject: C-Kermit and Xenix Keywords: Xenix, C-Kermit RE: Info-Kermit Digest V5 #18 I recently put the latest C Kermit (4D(061)) up on a Tandy 16/6000 running Xenix 3.1 with no problems. I used the make sys5 command to compile; only changes needed were to include /sys/typedefs.h for the void identifier found in one file. Everything seems to be working ok so far. ------------------------------ Date: Mon, 15 Dec 86 10:17:15 EST From: es!Dan_Senie%anvil.UUCP@harvard.HARVARD.EDU Subject: C-Kermit on Microport Unix Keywords: C-Kermit I just compiled 4D(061) using 'make sys3'. It work right from the start. Many people have sent in messages about trouble getting Kermit to run on XENIX. I had used XENIX for a time, but found the include files and compiler contained many errors and incompatibilities with real system V Unix. Microport Unix is a full System V for the IBM-AT. Unlike XENIX, it is based on the current Sys V sources and therefore Kermit was easy to get running. Those of you using XENIX may want to investigate this new package. Dan Senie PS. I am not connected in any way with Microport Systems, ATT, etc. UUCP: ...!harvard!anvil!es!Dan_Senie (case is important!) ARPA: anvil!es!Dan_Senie@harvard.harvard.edu ------------------------------ Date: Sun, 7 Dec 86 11:29:35 pst From: gould9!joel@nosc.ARPA (Joel West @ Western Software Technology) Subject: Uploading Macintosh Binhexes with Kermit Keywords: UNIX, MacKermit, hqx I've been meaning to send this along for a while, but I wasn't sure anyone was interested. A query on INFO-MAC prompted this posting. It is a UNIX csh script (MACKERM) that I use to upload binhexes using kermit. If for a file foo.hqx, it first sends the header (before the binhex) as 'About foo', then sends foo.hqx. I use the header to later note the origin on the final unhexed file. To make this work, you need to take the first file (usually a short About... file) manually, selecting the target directory. Then place your MAC in server mode, since each 'kermit' command at the UNIX side is a separate session, and the Mac would otherwise quit file transfer mode. Oh yeah, it also works on ordinary files, preserves actual names ('FooBar' instead of 'FOOBAR') and NEVER transfers a directory. So it's real useful to type mackerm * place the Mac in server mode, and walk away. Joel West joel%gould9.UUCP@NOSC.MIL ihnp4!gould9!joel ==File ===== #!/bin/csh # by Joel West, ihnp4!gould9!joel, 11/14/86 # Script to send binhexes and other files # Also preserves exact upper/lower case name set noglob foreach f ($*) if (-d $f) continue set typ=$f:e switch ($typ) case hqx: case hex: set r=$f:r set T1=/tmp/kermdat_$$ set T2=/tmp/kermhqx_$$ rm -f $T1 $T2 cat $f | cutat '(This' $T1 $T2 kermit -s $T1 -a "About $r" kermit -s $T2 -a $f rm -f $T1 $T2 breaksw default: kermit -s $f -a $f endsw end == EOF == [Ed. - Thanks. This hint has been added to the Macintosh Kermit .BWR file, CKMKER.BWR.] ------------------------------ Date: Fri 14 Nov 86 10:34:23-PST From: Ted Shapin Subject: Bug in Apollo Pascal Kermit Keywords: Apollo Kermit We found that the Pascal kermit for the Apollo inserts extra line feeds every 256 characters if there is no line feed carriage return in the file. We traced it to the I/O in the Pascal program which can only read 256 byte lines. [Ed. - Thanks for the information. This message is now in the file KER:APOLLO.BWR.] ------------------------------ Date: Wed 10 Dec 86 10:45:54-PST From: Bob Larson Subject: Prime kermit connect Keywords: Prime Kermit I have a partially working one, based on the old version of prime kermit. I'm not even sure if I have a complete set of sources for it on tape any more. Known bugs include dropping characters in connect mode, problems with some of the message strings (incorect use of ioa$), and not supporting 2400 baud. (Writen before prime standardized the "optional" speeds at 2400 and 4800 baud for autobaud.) I have been considering making improvements to the current prime kermit, with support for amlc lines among them. ------------------------------ Date: WED, 10 DEC 86 17:17:13 BST From: CJK @ UK.AC.SALFORD.R-D Subject: Kermit and X.25 Keywords: C-Kermit, X.25 Points from infodigest 5/17. First Steve Walton & Telenet: We over this side of the pond are quite used to using Kermit over X.25 networks (posing as an X.29 terminal). It works fine, at least in the micro-mainframe mode, with call originated by the micro. Efficiency should not be affected much until the ratio: time-through-network / front-end-delay reaches about 5. The crucial thing is to set up the X.3 parameters in the PAD so that the whole Kermit packet gets into a single X.25 packet; it is bound to be shorter than the 128-byte maximum on X.25. In general you have to use a transparent-type mode to let the SOH get through, but there is no need at all to forward on every character (which simply fills up the X.25 window with single-character X.25 packets). Provided the EoL is a forwarding character, which it will be if it is CR, all works fine. What you actually do depends on the user interface provided by your PAD. This is in fact all covered in your book. Of course, network congestion can slow things down. Our X.25s, the public PSS and private JANET, have maximum time-through-networks of about 0.1 sec in all normal circumstances, so no problem. But I heard last week in a different context that the congestion on ACCUNET was so severe that holding transatlantic calls open was very difficult. If Telenet is in the same state, then you've got problems. But blame the sizing of the network, not X.25 or Kermit. Does CKermit really limit you to 65% of line-speed? I tested homegrown Kermits here (at up to about 30Kbaud) and found that, with data-compression on, I always got better than 100% of linespeed. If CKermit is really that slow, is it losing time somewhere that it needn't? Incidentally, switching over to Kuryan Thomas' problems with his autodialler: Many UARTs will not receive if DCD is not high (it's a protection against line-noise). If you have one of these, and an autodialler which does not hold up DCD while it is trying to talk to you, then you have no option but to strap DCD to one of the other pins, e.g. DSR. Chris Kennington. ------------------------------ Date: 11-DEC-1986 09:47:23 From: DGM1@UK.AC.YORK.VAXA Subject: Problem with HP9845 Kermit Keywords: HP Kermit Cross-Ref: Hewlett-Packard Kermit It's not a bug: it's a problem regarding some assumptions regarding the machine configuration, which I should have spelt out when I sent it in. We have explained/apologised to one or two people who contacted us directly, and if in a fit of absent mindedness I had not deleted a note I had from Chris regarding the configuration assumptions, I would forward it to you for a BWR file. As I mentioned when I sent it in, it does not pretend to be a full kermit, more a minmalist bulk data transfer utility conforming to the kermit protocol. It is probably possible to bypass the need for specific ROMs and so on by the use of inline assembler, however, if the ROMs are available, it is better to use the facilities provided by the HP virtual communication device. I'll get the precise details from Chris as soon as possible for you for inclusion in a BWR Sorry about the hassle, Doug ------------------------------ Date: 11 Dec 86 13:42:00 EST From: John Stewart Subject: HCP and HC6 Versions of Kermit Keywords: Honeywell Kermit I was looking at the versions file and noticed that two versions of Kermit are listed for our machine, HCP and HC6. HCP is a Pascal implementation of Kermit that was ported to the Honeywell Cp-6 operating system by Bucknell University. It is a very minimal implementation (it doesn't even do repeat counts, let alone advanced features like server mode). HC6 is much more complete then HCP, and both the original developer and myself are continuing to enhance it. I suggest that distribution of the HCP version of kermit be discontinued. Regards.. jas [Ed. - Thanks, this seems to be the concensus of opinion; the HCP version was indeed retired to Tape C.] ------------------------------ Date: Wed, 10 Dec 86 10:33 EST From: "John G. Ata" Subject: Need Fast De-BOOing Program for the Amiga Keywords: Amiga Kermit Can somebody out there who has a C compiler on the Amiga please compile CKIBOO.C and then make a BOO file out of it and send it in to Kermit Distribution as, say, CKIBOO.BOO, so that those of us without a C compiler only have to run the Basic de-booer once, on CKIBOO.BOO, and then can subsequently use the compiled de-booer which should be much faster. It takes about an hour to de-boo Amiga Kermit with the Basic de-booer. John G. Ata ------------------------------ Date: Tue, 16 Dec 86 16:25:14 est From: munnari!latcs1.oz!philip@seismo.CSS.GOV (Philip Lee) Subject: Data General MV2000 Keywords: Data General Has anyone sucessfully ported the unix kermit to Data General MV2000 running DG/UX ver. 3.00? We've tried recompiling ver 4D on it. It compiled without complaining, but gave link error. However it sort of work. We could do ascii file transfer, but any compressed file or any of those using all 8 bits would fail. The DG kermit would accept set file type binary quite happily and indicate the same, but on file transfer it would just time out and fail. In generating the DG/UX kermit we used the following: make wermit \ "CFLAGS = -D_file=_fd -DUXIII -DDEBUG -DVER2 -DTLOG -O4" "LNKFLAGS =" Could this be also related to the problem of 8 bit transfers between FIDOnet Kermit and the Pyramid? [Ed. - The FIDO question has still not been totally solved, mostly because of lack of time, but it might help you to know there's a version of Kermit specifically tailored for DG MV/UX (is that the same thing?), based on an old release of Unix Kermit, available in the Kermit distribution under the prefix DGM. There's also a C-Kermit implementation for AOS/VS on the way.] ------------------------------ Date: Sun, 14 Dec 86 14:56:29 +0200 From: Sam Gamoran Subject: Kermit 3.1 - An interesting speed problem Keywords: CMS Kermit, PROCOMM We just installed CMS Kermit 3.1 - appears to solve our problems with 2.1 particularly the program hanging and binary transfers. We use CMS Kermit through a 7171 against PCs running either MS-DOS Kermit 2.28 or Procomm 2.3 with the Kermit file transfer option. Works great with MS-DOS Kermit 2.28 but file transfer crawls with Procomm 2.3. Every packet sent by CMS-KERMIT 3.1 ends with an X-ON character. The old CMS-KERMIT 2.1 did not do this. It appears that this X-ON character causes Procomm to delay a second or so before sending the next packet. We saw on a line monitor packets going out from PC to mainframe and an instantaneous response followed by a delay. With the old CMS-KERMIT, where the main difference between packets is the absence of the final X-ON character no delay occured and transfer throughput was 400% faster! Do you know of anyone having experience with PC->Mainframe file transfer using PROCOMM who has encountered similar problems? I am also sending this query to the procomm folks. Thanks, Sam Gamoran ------------------------------ Date: Tue, 16 Dec 86 15:39 CST From: "David S. Cargo" Subject: Symbolics V7.0 Kermit Keywords: Symbolics Kermit Symbolics is upgrading their system software to version 7.0. The old Symbolics Kermit no longer works with the new system revision. Has anybody upgraded the existing version to run on the new system? I'm trying to avoid some wheel reinvention. ------------------------------ End of Info-Kermit Digest ************************* ------- 31-Dec-86 15:55:38-EST,14580;000000000000 Mail-From: SY.FDC created at 31-Dec-86 15:54:33 Date: Wed 31 Dec 86 15:54:33-EST From: Frank da Cruz Subject: Info-Kermit Digest V5 #20 To: Info-Kermit@CU20B.COLUMBIA.EDU Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Message-ID: <12267256864.290.SY.FDC@CU20B.COLUMBIA.EDU> Info-Kermit Digest Wed, 31 Dec 1986 Volume 5 : Number 20 Today's Topics: Series 1/7171 Support in NIH TSO Kermit Speed Problem Between ProComm and Kermit-CMS C-Kermit With Intel Xenix Fix for Unix Kermit on SCO System V C-Kermit and Valid Workstations Where to Send HP-1000 Kermit Requests ---------------------------------------------------------------------- Date: Sat, 20 Dec 86 21:00:25 EST From: "Roger Fajman" Subject: Series 1/7171 Support in NIH TSO Kermit Keywords: TSO, MVS/TSO Kermit One important correction to Info-Kermit V5 #19: NIH TSO Kermit does not presently have Series 1/7171 protocol converter support. We don't have those machines. If someone wants to send us the modification, we will be glad to include it. [Ed. - Oops! Sorry. It appears that reports of the death TSOS1 were somewhat exaggerated. Volunteers? Also, note that the "other" new TSO Kermit, expected in the not-too-distant future, should indeed support both Series/1 (full screen) and 37x5 (linemode) style hookups.] Also, I checked the files as they appear on KERMSRV at CUVMA, and found some erroneous translations between vertical bars and exclamation marks. The following files contain real exclamation points: TSNKER.ALP (just a comment), TSNKER.DOC, TSNEDR.DOC, TSNMAC.DOC, and TSNTBL.ASM (in the translate tables). The last one is the most serious. [Ed. - Oops again! That's what comes from reading EBCDIC tapes on a Unix system with 'dd'... We'll try to get clean copies of these files over BITNET to replace the current copies. It has also been reported that some files have U and e where square brackets ([) and (]) ought to be.] ------------------------------ Date: 1986 Dec 22 13:52 EST From: (John F. Chandler) Subject: Speed Problem Between ProComm and Kermit-CMS Keywords: ProComm, CMS Kermit, Series/1 I have seen reports of the problem from a number of places now, some not specifically mentioning the use of a 7171, but none mentioning anything else. The implication of the latest report (in Kermit Digest #19) is clear: ProComm needs to be fixed. However, I should add that the XON added to the end of each packet by CMS Kermit is not essential and could be removed if necessary. It was added as a convenience for the micro Kermit -- the rule of thumb is: when talking to an IBM mainframe, always wait for an XON before sending the next packet. The rule is not true for the various protocol converters (Series/1, 4994, and 7171), but the added XON makes it harmless. How does ProComm perform when told to wait for the XON? ------------------------------ Date: Mon, 22 Dec 86 21:26 CST From: Wilkinson@HI-MULTICS.ARPA Subject: C-Kermit With Intel Xenix Keywords: Xenix, C-Kermit I have been running 4D(061) under Intel Xenix(3.3) on an Intel 286/310 system for some time now with no problems. I used "make xenix". I also got a clean compile/link for an older UniPlus (UniSoft System III) for 4D(061). It is running, but I have not used it extensively. I used "make sys3". Richard {Wilkinson@HI-MULTICS.ARPA} ------------------------------ Date: 21 Dec 86 04:30:32 GMT From: ihnp4!killer!alleng@seismo.CSS.GOV Subject: Fix for Unix Kermit on SCO System V Keywords: C-Kermit, SCO Xenix, Xenix I have some info that may be useful in trying to determine why kermit (wermit) specifically ckuker does not want to run on Xenix sys V (SCO). I noticed a discrepancy in the server mode prompt from any other system to an SCO system. On most systems, the prompt is "# N3". HOwever, on Xenix, the thing comes up "# N/". A Xenix system will talk to another Xenix system (SCO), but cannot communicate with any other systems for protocol transfer. The problem comes from performing functions on unsigned and signed ints. For some reason (compiler bug), when certain operations are performed on standard ints, the sign bit gets set (lsb in MS byte). This makes checksums come out screwy. To resolve this, edit the module 'ckcfn2.c' (by the way, we are talking about ckuker here) look for the function 'C K U 1'. You will notice an 'int chk' below the function heading. Simply change it to 'unsigned int chk' and the version should work perfectly. My thanks to all who helped isolate this... Allen [Ed. - Hmmm... What version of C-Kermit has everyone been using? This change was made months ago, either in 4D(061) or 4D(060). Maybe if everyone with SCO Xenix systems tries the current version - 4D(061) - the problem will disappear. Could some SCO Xenix users verify this??? By the way, I think Allen meant to say 'C H K 1' rather than 'C K U 1'.] ------------------------------ Date: Tue, 9 Dec 86 16:12:13 pst From: hplabs!valid!carolf@gumby.arpa (Carol Fernihough) Subject: C-Kermit and Valid Workstations Keywords: C-Kermit, Valid Workstations I'm unclear as to where to mail bug reports regarding kermit. I'd like my mail find its way to 1) kermit programmers at Columbia University, and 2) a network, so that I could receive responses from other users who can suggest fixes. Would you please forward this mail if necessary, and let me know where I should send UUCP mail. Although I have access to kermit information via the mod.protocols.kermit newsgroup on Usenet, I do not have permission to post to the moderated newsgroup. [Ed. - UUCP mail can be sent to ...!seismo!columbia!cu20b!info-kermit] I have tested version 4D(060) of c-kermit quite extensively on Valid's workstation, which is an S320 running 4.2 BSD UNIX. I compiled c-kermit using "make valid". I've found the following problems when transferring files between two S320's: * Use of the -k option corrupts the file during kermit's transfer: This problem also arises when transferring files between the S320 and c-kermit (compiled using "make sys3") on the IBM PC/AT. machineA# kermit -iwl /dev/ttys0 -b 9600 c-kermit(machineA)> connect (log onto machineB) machineB# kermit -ik > file.from_machineA (escape back to machineA) c-kermit(machineA)> send file file -> FILE, Size 50 The text file that arrives on machineB is 52 bytes long since it has a CR LF at the beginning of the file. Binary files are corrupted in the same manner. Text files are corrupted when sent using the -k option with no -i option. [Ed. - We can't reproduce this problem on our 4.2BSD (Ultrix 1.1, really) VAX 750, but it's probably related to the well-known bug which inserts an extraneous CRLF into standard output every 4096 characters (this only happens with the -k option). There's nothing in the C-Kermit code that inserts this CRLF, so it must have something to do with Unix's blocking. Does anybody have an idea what must be done to convince Unix to leave out the CRLFs -- some kind of mysterious ioctl or fnctl applied to stdout, maybe?] * Can't use -c option When I escape (^\c) after starting kermit on machineB, I escape out of the kermit on machineA. This also happens when kermit is started in server mode. c-kermit(machineA)> kermit -cl /dev/ttys0 -b 9600 -iw (log onto machineB) machineB# kermit -iw [Ed. - This is the documented behavior. When you invoke Kermit with action commands (either protocol or connect, or both) on the command line, it acts like a normal Unix command, i.e. it exits when done. Leave out the -c option, and you'll get an interactive Kermit session that you can escape back to.] * This problem occurs randomly. When host to host, and connected to machineB: c-kermit(machineB)> exit (logout from csh) Can't get character: I/O error [Back at Local System] c-kermit(machineA)> (exits directly back to kermit on machineA - should need ^\c first) The problem also occurs randomly when machineB is running in server mode: c-kermit(machineA)> finish c-kermit(machineA)> connect machineB# logout Can't get character: I/O error [Back at Local System] c-kermit(machineA)> [Ed. - This probably is caused by your ports and cables. Most likely, you've got the systems connected by a true null-modem cable, in which one computer's DTR is connected to the other computer's CD and/or DSR. The remote computer may be configured to drop DTR upon logout, which would cause the local one to sense that CD or DSR disappeared, and to return an I/O error the next time you tried to read or write characters to the port. The Kermit connect command exits when it gets an i/o error. Solution: trade in your true null modem cable for a "fakeout" cable in which DTR is connected to CD and DSR within the local connector, or reconfigure your ports to be less persnickety about modem signals.] * When kermit is invoked from a script command, the command line options are ignored. machineA# kermit -iwl /dev/ttys0 -b 9600 machineA's /.kermrc file contains: script gin:--gin:--gin: name ssword: passwd \ machineB#--machineB# kermit~s-iwx send binary_file binary_file.from_machineA The attempted transfer simply times out because kermit on machineA is NOT in server mode, nor have the other command line options taken effect. Workaround: Rather than including command line options in a call to kermit from a script, put the necessary commands in the script or in the remote machine's .kermrc. [Ed. - This is just a guess, but maybe the '-' in '-iwx' is the culprit, since dashes are meta-characters in uucp-style scripts. Try changing 'kermit~s-iwx' to 'kermit~s~055iwx' and see if that works.] * Finish doesn't always work When using a server, type finish, then connect. Kermit will sometimes connect back to kermit on the remote machine rather than the shell on the remote machine. [Ed. - This depends upon whether you invoked Kermit with -x on the command line (in which case it exits to the shell) or with the interactive 'server' command (in which case it returns to C-Kermit> command level).] I've also begun to test c-kermit between the S320 and the Microvax, running VAX version 2.1. I compiled c-kermit on the Microvax using the CKVKER.COM DCL procedure. I've found the following problems: S320 -> Microvax * Can't transfer binary files Both host to host and server transfers corrupt binary files. [Ed. - Presumably you gave the -i option or 'set file type binary' on both ends. Have other users of C-Kermit on VMS found this to be true? I think the problem is that VMS binary files are not simple streams but are structured with particular blocksizes, etc. There's no code in C-Kermit to do this. I hope somebody who's familiar with VMS and VAX-11 C will add this code, or provide some hints or workarounds to this problem.] * Bye doesn't work When running kermit on the microvax in server mode, type bye, then connect. Bye acts like finish because kermit will connect to the microvax command interpreter prompt. At this point, type logout (which doesn't echo on the screen). [Ed. - Again, sounds like something to do with VMS. Maybe VMS doesn't allow a program to log out its own job unless the program is started or configured with some specific capability. Can any VMS experts answer this?] * Finish doesn't work When using the microvax as a server, type finish, then connect. Kermit will connect back to kermit on the microvax rather than the command interpreter. [Ed. - As in the Unix case, it depends on how the program was invoked.] * Exit doesn't always work Sometimes no action will be taken in response to exit. Quit always works however. [Ed. - That's strange, because quit is simply a synonym for exit -- both are associated with exactly the same code.] Microvax -> S320 * Directory doesn't work Directory listed only one file in a directory containing several files. * Cwd doesn't work Cwd caused an access violation and exited from kermit. c-kermit(microvax)> cwd %SYSTEM-F ACCVIO, access violation, reason mask=00, virtual address=00000000, P4 %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel pc abs pc CKVFIO system 3233 17 15122 CKUUSR docmd 1796 1a2 12F53 CKUUSR parser 1635 182 12B69 CKCMAI main 930 BC D918 $ (could not echo - logged out) [Ed. - Again, I appeal to VMS experts for help sprucing up the VMS-specific functions in the CKV*.C modules.] I also have a question. What is the reason for not reading the .kermrc file when the command line contains an action? [Ed. - No special reason except that the structure of the code made it hard to do. This feature should be added in a future release.] UUCP address: ucbvax!hplabs!pesnta!valid!carolf Thanks! Carol Fernihough [Ed. - And thanks to you for your detailed reports. This is how Kermit programs keep getting better. I hope I've answered each point satisfactorily. If not, let me know. - Frank] ------------------------------ Date: Wed 24 Dec 86 10:56:43-EST From: Christine M Gianone Subject: Where to Send HP-1000 Kermit Requests Keywords: HP-1000 Kermit, Interex Paul Schumann has been getting many requests for his version of Kermit for the HP-1000 but is unable to provide such a service. He has asked that in the future people please make such requests of Columbia University or the HP User Groups since these groups are set up to do this kind of distribution. If anyone is interested in becoming a member of the HP User Group, the address is as follows: Interex 680 Almanor Avenue Sunnyville, CA 94086-3513 ------------------------------ End of Info-Kermit Digest ************************* -------