Columbia Kermit

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

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

Wrap

Text File | 2020-01-01 | 628KB | 15,586 lines

23-May-84 18:58:43-EDT,9663;000000000001 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 23 May 84 18:58:24 EDT Date: Wed 23 May 84 18:59:04-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #1 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 23 May 1984 Volume 1 : Number 1 Today's topics: Info about Info-Kermit New Release of LCTERM for Rainbow MS DOS New Implementation of KERMIT for MUMPS on PDP-11 New Implementation of KERMIT for IBM PC under UCSD p-System Hayes internal modem question UCSD Pascal Kermit for Apple? KERMIT Enhancement -- Changing Filenames ------------------------------------------------------------------------------- Date: Wed 23 May 84 12:04:05-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20> To: Info-Kermit Subject: Info About Info-Kermit Because of the need to reduce the load on the Columbia University Computer Science Department DEC-20 (COLUMBIA-20) during a period of heavy use and hardware & software development, Info-Kermit will be run as a digest for the next couple months. This is the first issue. Another policy that ARPAnet users should be aware of is the recent restriction on anonymous FTP at COLUMBIA-20, imposed for the same reasons. Anonymous FTP logins are not allowed between the hours of 6:00am and 6:00pm eastern time, weekdays, but are permitted outside these hours. A reminder about how to get KERMIT. For ARPAnet/Internet sites, connect to host COLUMBIA-20, login as user ANONYMOUS with any non-null password. For CCnet (DECnet) sites, use NFT to host CU20B; depending upon the arrangements between Columbia and your site, you may be able to access the files specifying user ANONYMOUS; otherwise contact your system manager. In both cases, all the KERMIT files are in PS:<KERMIT>, which you can also refer to using the logical device name KER:. The file KER:00README.TXT contains information on what files are in the KERMIT distribution area and how to find them. One file worth checking from time to time is KER:CURRENT.DOC, a brief tabular listing of each existing version of KERMIT, showing the version number and date of the latest release of each version. KERMIT network distribution is also available to users of BITNET through a server called KERMSRV set up at host CUVMA, an IBM system at Columbia. To get started with KERMSRV, type the following command on your own BITnet host: SMSG RSCS MSG CUVMA KERMSRV HELP For those who cannot obtain KERMIT files over these networks, there remain the DECUS, SHARE, STUG and other user group tapes, various PC or micro floppy distribution services, and Columbia itself will send out tapes for a distribution fee (our tape service is described in KER:FLYER.DOC). Archives of Info-Kermit are in KER:MAIL.*. The messages up to March 8, 1984 are in KER:MAIL.83A. Those from March 8 to May 18 (the last "direct mail" activity) are in KER:MAIL.83B. The current mail (starting with this issue of the digest) are in KER:MAIL.TXT. - Frank ----------------------- Date: Wed 23 May 84 12:04:05-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20> To: Info-Kermit Subject: New LCTERM for Rainbow MS DOS Version 2.14 of Larry Campbell's LCTERM multi-protocol (including KERMIT and XMODEM) communication program for the DEC Rainbow under MS DOS 2.05 or later is now available. There are many fixes since the last release, and enhancements including a session script facility. The program is available via anonymous FTP from COLUMBIA-20 (ARPANET, only outside of peak hours), or NFT from CU20B (DECNET/CCNET), as KER:RBLCTERM.*. RBLCTERM.EXE is the executable program, in MS-DOS binary format. RBLCTERM.C is the source (actually this file contains the concatenation of various C and ASM86 source files). Installation instructions are in KER:RBLCTERM.HLP. Documentation is in KER:RBLCTERM.DOC. Various other files are also included, including a .BWR file that lists some bugs & restrictions. Since there is no "printable" object module, such as the .HEX or .H86 files of CP/M, or the .FIX file provided with MS DOS (IBM PC) Kermit, you should read the .HLP file before attempting to download LCTERM for the first time. By the way, there will also be a version of Columbia's MS DOS Kermit for the Rainbow, which will appear as part of the next MS DOS Kermit release within the next few weeks. ----------------------- Date: Wed 23 May 84 12:04:05-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20> To: Info-Kermit Subject: New Implementation of KERMIT for MUMPS-11 Kermit-M is a version of Kermit that is written in 1982 ANSI Standard MUMPS, by David Rossiter of the New York State College of Veterinary Medicine, Veterinary Computing Facility. This version is designed for PDP-11 computers running InterSystem's M/11 operating system (version 5), but instructions are provided for converting to other machines or MUMPS implementations. The files may be found in the KERMIT distribution area as KER:MPKERMIT.*. Some of these files have very long "lines" (over 200 characters), which are apparently unavoidable in the MUMPS language. Thanks to Kate MacGregor of Cornell University for contributing this Kermit implementation through BITNET. ----------------------- Date: Wed 23 May 84 12:04:05-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20> To: Info-Kermit Subject: New Implementation of KERMIT for IBM PC under UCSD p-System This implementation of KERMIT for the IBM PC p-System was submitted by Kate MacGregor and Steve Pacenka of Cornell University Computing Services. It requires version IV.x of the UCSD p-System, and is also intended to be transferrable to other computers that run the same level of the p-System. It was developed on the IBM PC using NCI release C1F. The files are in KER:UCIBMPC.*. The Pascal source files are concatenated together into the file KER:UCIBMPC.PAS; there are also .DOC and .HLP files. The other UCSD Pascal Kermit from Cornell (the one for the Terak) has been reorganized along similar lines, as KER:UCTERAK.*. ----------------------- Date: Tue 22 May 84 12:04:05-EDT From: Alan Crosswell <US.ALAN@CU20B> Subject: Hayes internal modem question. To: info-ibmpc@USC-ISIB.ARPA, info-kermit@CUCS20 I would appreciate it if somebody who has the Hayes internal modem or who looked at one and decided against it would let me know what your experience has been with it. I have heard a rumor that it is unreliable. Is this true? Is it worth the price difference to get the internal modem instead of an async card and external one? The professor who is looking is absolutely convinced that he will never want to attach to an RS232 line but will always use a telephone from his home. Alan Crosswell User Services Columbia University Center for Computing Activities [Editor's note: I don't know if the Hayes modem is good or bad, but there are several good reasons for avoiding internal modems in general: . They take up a slot that might be otherwise put to better use . They can't be easily used on other PCs . They can't be used at all on different kinds of micros . They tend to confuse and/or complicate communication software, like KERMIT People interested in using KERMIT- or MODEM-like programs for transferring files should avoid internal modems.] ----------------------- Date: Tue 22 May 84 18:06:05-PDT From: Bruce Tanner <CERRITOS@USC-ECL.ARPA> Subject: Apple Pascal Kermit? To: INFO-KERMIT@COLUMBIA-20.ARPA I see from VERSIONS.DOC that there are several UCSD p-system Kermits around, but none for the Apple. Is there one available? Thanks, -Bruce [Not to my knowledge. But see the above announcement for a UCSD Pascal Kermit for the IBM PC. There are now at least three versions -- IBM PC, Terak, HP-98x6 -- to use as a basis. Any volunteers? - Frank] ----------------------- Date: Wed 23 May 84 15:20:05-EDT From: Dave Weaver <DWEAVER@DEC-MARLBORO.ARPA> Subject: KERMIT Enhancment To: cc.fdc@COLUMBIA-20.ARPA I would like to see all flavors of KERMIT offer an option to the RECEIVE or GET commands to output to a file spec other than the same one as you are receiving. Not only would this help with file name length problems, but it would be a valuable asset on VAX systems with DECnet, because one could "RECEIVE" a file to a different node. Something like: Kermit-32> get FILE.EXT NODE"user password"::FILE.EXT and: Kermit-80> get TOPS20_LONG_FILE_NAME.EXTENSION FILE.EXT The latter is because TOPS20 supports long file names and it would be nice to be able to copy them without first copying them to some shorter named file. In the former example I could be talking to a 20 from a VAX which is a DECnet node, but I would like to copy the file to another node other than the one I am running KERMIT from. -Dave [Heartily endorsed. In fact, the Kermit Protocol Manual recommends this; see section 9.1 of the 5th edition. Not many implementations support all these options; KERMIT-20, for instance lets you send FOO (AS) BAR, but not GET FOO (AS) BAR. This should be fixed. But note that there's always the problem of delimitation -- some systems (ITS, VM/CMS) have filenames with imbedded spaces. FTP takes care of this by having you type the source and destination filespecs on separate lines. - Frank] ------- 26-May-84 15:45:29-EDT,6067;000000000001 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 26 May 84 15:45:14 EDT Date: Fri 25 May 84 20:28:43-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #2 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Friday, 25 May 1984 Volume 1 : Number 2 Today's Topics: Info-Kermit Digest Format Kermit at DECUS Kermit on Cyber Machines (2 messages) Kermit on Epson QX10? Kermit Enhancement - renaming files in get and send ---------------------------------------------------------------------- To: Info-Kermit Date: Friday, 25 May 1984 8:04pm-EST From: Frank da Cruz <cc.fdc@columbia-20> To: Info-Kermit Subject: Info-Kermit Digest Format There were a few complaints about the format of the first issue of the new Info-Kermit digest. Various digest digesters complained of indigestion. This issue should be better -- the dashed separators are the "right length", there are some asterisks at the end, tabs removed, etc. Let me know of any further problems. ------------------------------ Date: Friday, 25 May 1984 8:04pm-EST From: Frank da Cruz <cc.fdc@columbia-20> To: Info-Kermit Subject: Kermit at DECUS The new KERMIT releases that were announced in the last issue (UCSD, MUMPS), this issue (Cyber 170), and the next issue (most likely VAX/VMS, TOPS-10, and Professional-350) will be available at Spring DECUS. Brian Nelson will probably be bringing new releases of his PDP-11 Kermit for RSX, RSTS, and maybe RT-11. Attempts will be made to bring all these last-minute releases together into a coherent collection for the various SIG tapes (particularly VMS and RSX), and to make them available on whatever machines are provided by DEC for people to make their own copies. If you need any of these new releases and you're going to DECUS, you might want to bring along a tape (a 2400' reel -- the entire KERMIT distrubution won't fit on anything smaller), as well as some floppies for the Rainbow and Pro-350 versions. This will save you the trouble of FTP'ing a large amount of data over the net, or sending for a tape if you don't have FTP access, as well as avoiding cumbersome bootstrapping procedures for first-time users of Rainbow and Pro Kermit. I'm not going to DECUS myself, but I understand a KERMIT session has been set up for Friday (when most people have left). ------------------------------ Date: Fri, 25 May 84 13:24:38 cdt From: knutson@ut-ngp.ARPA To: cc.fdc@columbia-20.ARPA Subject: New Cyber Kermit You can get the source for the new Cyber Kermit via anonymous ftp to ut-ngp. The files you need are 170kermit.for and 170azlib.asm. These two files should replace the current 170kermit.for. The following are a list of changes made: Version 2.0 - File name packets send uppercase file names, Error packets now handled correctly, modified character tables for CDC 63 and 64 character sets, merged Ric Anderson's NOS/BE code, added push and ! commands, added read delay for performance tuning, changed binary data-mode to ignore NEL characters, OVCAP or SEGLOAD version can be produced, reduced field length. Note that this version now truly supports NOS/BE (aside from differences in front-ends). Ric Anderson of the University of Arizona at Tuscon deserves credit for this. I'll hopefully have a true NOS version in a couple of months. Keep up the good work, Jim Knutson ARPA: knutson@ut-ngp UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson Phone: (512) 471-3241 [Ed Note -- The new files are in KER:170*.* on COLUMBIA-20, available via anonymous FTP in the usual manner. Note that a good deal of the Fortran code of the previous release has been replaced by assembler. Also, there doesn't seem to be any new documentation beyond what's been said above, but then maybe none is necessary.] ------------------------------ Date: Fri, 25 May 84 10:11:04 EST From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers) To: cc.fdc@columbia-20.ARPA Subject: Kermit on Cyber Machines You might be interested to know that one of my colleagues has modified Kermit-170 (Cyber) to run on the 815 - we'll send you a copy when it's been more thoroughly tested. Our 815 runs NOS 2.2, by the way, and Darryl Chivers (the one doing the job) also plans a NOS/BE version for the 730, but that's further off. - Steve Withers, University of Melbourne [Let's hope the different Cyber versions will get back together one day... - Ed.] ------------------------------ Date: Wed, 23 May 84 To: info-kermit@columbia-20 Subject: Kermit on QX10 From: fenchel@wisc-rsch.arpa Has anyone brought kermit up on the Epson QX10? Bob Fenchel [Not to my knowledge. Anyone else heard anything? - Ed.] ------------------------------ Date: Thu, 24 May 84 10:31:20 pdt From: Ken Poulton <kdp%hp-labs.csnet@csnet-relay.arpa> To: info-kermit@csnet-relay.arpa Subject: Kermit Enhancement - renaming files in get and send I agree with the need. I found kermit-20's "send .. (as) .." so handy that I implemented it for Tools and Unix Kermits. Doing the same for Get would be nice, too. [Ed note -- Ken is the author of the Software Tools Kermit, written in Ratfor.] A note on syntax: I chose to allow Send to take any number of files (possibly wildcarded); any filename followed with "-as" is sent with the word following the "-as" as the name. Obviously, you don't want to mix wildcards with "-as", but the "-as" needn't restrict you to one file at a time. In my opinion, files with spaces in their names are a pathological case: try to provide a mechanism to deal with them, but don't restrict your syntax (one file per line) because of them. ------------------------------ End of Info-Kermit Digest ************************* ------- 30-May-84 19:11:31-EDT,8442;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 30 May 84 19:11:07 EDT Date: Wed 30 May 84 19:06:46-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #3 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 30 May 1984 Volume 1 : Number 3 Today's Topics: KERMIT for TRS-80 I and III with TRSDOS New Release of DEC-20 KERMIT DEC Pro-350 & IBM PC Kermit Queries KERMIT for Commodore-64 Underway Fix for Kermit-80 V3.9 ---------------------------------------------------------------------- Date: Mon, 28 May 84 16:55:55 CDT From: Stan Hanks <stan@rice.ARPA> Subject: TRS-80 Kermit To: Frank da Cruz <cc.fdc@COLUMBIA-20.ARPA> Cc: Stan Barber <sob@rice.ARPA> Frank, Stan Barber has finally completed the TRS80 version of Kermit. Included is all of the source, plus a BASIC program that, when executed, will generate a correct binary. The manual entry for the user's guide is also present. This implementation of the Kermit is written in Z80 Assembler, compatible with M80 and EDAS from Mysosys. It runs under all DOS's available for the TRS80 Model I or Model III (and the Model 4 running in Model III mode). It has been checked out under the following DOS's: TRSDOS 2.3 (Model I), TRSDOS 1.3 (Model III), NEWDOS/80 V 2.0, LDOS 5.1.3, DOS+ 3.5 and VTOS 3.0 (Model I). Stan Hanks [Ed. Note: The files have been renamed for grouping together in the KERMIT distribution as KER:TRS*.*. The file KER:TRSMIT.HLP contains the correspondence between the real names and distribution names. The file KER:TRSMAKE.BAS is a Basic program that generates the executable binary, and KER:TRSMIT.DOC is the KERMIT User Guide manual chapter for this version. All available from COLUMBIA-20 or CU20B in the normal manner.] ------------------------------ Date: Wed 30 May 84 16:47:28-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> To: Info-Kermit Subject: New Release of DEC-20 KERMIT There is a new release of KERMIT-20 for the DECSYSTEM-20, 4(222), which fixes a couple bugs in the previous release, 4(215), and should replace that version (or any earlier version). The changes since edit 215 include: Fix FILE NAMING NORMAL-FORM (it was broken in the previous release). . Fix problem with two consecutive ~ chars in data when doing compression. . Don't create empty debugging log files. . Change SET DEBUGGING LOG to LOG DEBUGGING, like other KERMITs. . Add SET FLOW-CONTROL to allow explicit enable/disable of XON/XOFF. . Add SET EXPUNGE to allow enable/disable of automatic expunge on DELETE. . Make LOCAL prefix optional on LOCAL commands like LOCAL DELETE, etc. . Add LOCAL TYPE, LOCAL RUN. . Change LOCAL/REMOTE DISK to LOCAL/REMOTE SPACE, like other KERMITs. . Add code to believe remote TTY line speed under TOPS-20 6.0. . Miscellaneous minor bugs fixed. The new release is in KER:20KERMIT.* on COLUMBIA-20 or CU20B. The file suffixes include: .EXE - The executable program .MAC - The MACRO-20 program source file .UPD - The program update history .DOC - A new KERMIT User Guide chapter for KERMIT-20 .MSS - The Scribe source file for the manual chapter .INI - A sample KERMIT.INI file ------------------------------ Date: 28 May 84 19:02:01 EDT From: Chris Koenigsberg <CK0C@CMCCTE> To: To: info-kermit-request@CUCS20 Subject: DEC PRO 350 and IBM PC KERMIT Hello, I am a staff technologist here at CMU's School of Urban and Public Affairs, where they have given us 50 DEC PRO 350 personal computers to play with. I wonder if anyone has successfully assembled a Kermit to run on these beasts. Thanks for all the good work you have done. Chris Koenigsberg Urban Systems Institute CMU SUPA MMC204 (412)578-2175 [Ed. Note -- At least two versions of KERMIT for the Pro-350 have been done; one by Bob Denny of DECUS C fame, and the other by Stevens Institute of Technology. The Stevens version will be released this week or next week, and will be presented at DECUS.] p.s. Is there a new version of the Kermit-86 for the IBM running PC-DOS?? Around here everyone uses version 1.19 or 1.19A....1.19 gets hung up a lot when running things like Emacs on the host, and 1.19A is the "brain-damaged" version which they once thought would eliminate the overloading of the TOPS20 front end by drastically cutting the speed with which packets are sent during uploads. (They were wrong, the front end still gets overloaded, and lots of people are using this brain-damaged very slow upload for absolutely no reason!!) [Ed. Note - Columbia is working on a new release of MS DOS KERMIT, far advanced over the current release, which is 1.20. It should be ready within a couple weeks (I've been saying this for months, but this time I really mean it...). The new version has much improved terminal emulation, particularly in the character insert/delete area. The special CMU customization for slowing things down, pausing between packets, etc, has never proven to be necessary at any other site that I know about, and is probably an artifact of some system modifications.] ------------------------------ Date: 30 May 84 16:43:26 EDT From: Eric <LAVITSKY@RU-BLUE.ARPA> Subject: C64 Kermit To: cc.fdc@COLUMBIA-20.ARPA Hi Frank, Many of us C64 owners are distraught at the lack of a good public domain communication/file transfer program like Kermit. We are also distraught at the lack of attention Columbia has decided to give to the project of writing Kermit for this machine. Therefore, I have decided to start the project myself. At present the VT52 emulation is complete, and was written by Frank Prindle (Prindle@NADC) and myself. The remainder of Kermit will be written by me, and later some will be done with the help of Brian Beattie (Beattie@mitre-gateway). If anyone up there has already started to write anything, or formulate some ideas as how to approach the project on the C64, we would like to hear from them. I will keep you posted as to our progress. By the way, we will be writing it in Commodores' Macro Assembler and maintaining a working copy in Cross format. Due to various time restrictions, I don't expect the project to be near completion till the end of the summer. Eric Lavitsky (Lavitsky@Rutgers) [Ed. Note - Good for you! I wish we had been able to do it. We announced our intention to do C64 Kermit because one of our departments had decided to require its students to buy C64s. We even went so far as to buy one ourselves to do the work on. But the project never bubbled up high enough on our priority list to actually get started, what with the MS DOS, CP/M, DEC-20, IBM VM/CMS, Unix, Macintosh, and other implementations that were more important to larger numbers of Columbia users. Good luck!] ------------------------------ Date: 29 May 1984 0242-PDT From: Charles Carvalho <CHARLES at ACC> Subject: Fix for Kermit-80 V3.9 To: CC.FDC at COLUMBIA-20 Kermit-80 v3.9 will always prefix all &'s in the data with #'s. This should only be done if 8th-bit prefixing has been requested. This problem will only be seen when the other Kermit does not request (or permit) 8th-bit quoting, since Kermit-80 always agrees to use 8th-bit quoting. To fix it, replace the following three lines between gtch4a: and gtch4b:. lxi h,qbchr ;[jd] point to 8-bit quote char cmp m ;[jd] is it our quote character? jz gtch4b ;[jd] yes, have to quote it... with: lda quot8 ; Are we doing 8th-bit quoting? ora a jz gtch4c ; if not, skip test and restore char. lda qbchr ; get 8th-bit quote character cmp d ; same as current character? jz gtch4b ; yes, have to quote it... gtch4c: mov a,d ; no. get character back again. [Ed. Note - This fix will appear in the next release of CP/M-80 Kermit, which Charles is preparing. It will include other fixes, various improvements, but most important it will have the long heralded modular reorganization. Anyone with items to add or fix in KERMIT-80 3.9 should hold off until this new release appears.] ------------------------------ End of Info-Kermit Digest ************************* ------- 1-Jun-84 17:32:10-EDT,9297;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 1 Jun 84 17:31:47 EDT Date: Fri 1 Jun 84 17:30:12-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #4 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Friday, 1 June 1984 Volume 1 : Number 4 Today's Topics: Several Major New KERMIT Releases DEC VAX/VMS KERMIT 3.0.051 DEC TOPS-10 KERMIT 3(124) DEC Professional-350 KERMIT 1.0 Commercial KERMIT Guidelines ---------------------------------------------------------------------- Date: Fri 1 Jun 84 13:15:33-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20> Subject: Several Major New KERMIT Releases To: Info-Kermit Nick Bush and Bob McQueen of Stevens Institute of Technology have released several new KERMITs. New versions of VAX/VMS and TOPS-10 KERMIT include major improvements in server operation and other areas. And there is an entirely new implementation of KERMIT for the DEC Pro-350. These are described in the next three messages. The three new Stevens KERMITs share their system-independent portions, which are generated from common modules written in BLISS, DEC's "implementation Language". Therefore, the descriptions and capabilities of these three programs will be very similar. It should be noted that you don't need to have BLISS in order to run these programs. MACRO source files are generated from the BLISS for the PDP-10, VAX, and Pro-350, and hexified binaries are also supplied in some cases. The KERMIT User Guide chapters for these systems are not quite ready, but should be available soon. Since the files for the Pro-350 all begin with the prefix "PRO", the KERMIT Protocol Manual files have been renamed from KER:PROTO.* to KER:KPROTO.*, and the User Guide from KER:USER.* to KER:KUSER.*, so that the two appear together (at the end of the K's) in the distribution area directory listing. These three KERMIT implementations, along with the TOPS-20 and other recent releases, will be available at the DECUS symposium in Cincinnati next week on VAX/VMS and DEC-10/20 systems, so if you're attending, you might want to bring a tape along. In addition, new releases for RSX-11/M, RSTS/E, and RT-11 will be arriving at DECUS in time to be included. All of these will also find their way onto the TOPS-10/20, VMS, and RSX DECUS SIG tapes. Meanwhile, the new files are all available in the usual manner using FTP (ARPANET) or NFT (DECNET) or, after the files are moved, KERMSRV (BITNET). ------------------------------ Date: Fri 1 Jun 84 13:33:45-EDT From: Nick Bush <G.BUSH@COLUMBIA-20> Subject: DEC VAX/VMS KERMIT 3.0.051 To: Info-Kermit New features and changes in VAX/VMS Kermit-32 3.0.051 are listed in detail in the file KER:VMSV3.MEM. Here is a brief summary: . "SET PROMPT xxx". . When running as a user Kermit (i.e., talking to a server), it is possible to access all of the generic command functions (REMOTE commands) that were specified in edition 4 of the protocol manual. . Improved local-mode operation (e.g. when dialed out over an autodialer); better performance, ^A status reports, ^D debugging toggle. . Logical name KER$COMM queried for default line at startup. . Kermit-32 will now type out its version number when it starts up. . Problems with IBM host communication have been fixed. . The file processing should now handle sending any type of file. Previously, VFC format files did not work, and certain records from PRN or FTN format files would cause infinite loops. . The format in which ASCII files are sent has been changed to correspond with both the protocol manual and everyone's expectations (instead of the way VMS defines things). Each record from a file with implied CRLF's will be followed by a CRLF, not preceded by a LF and followed by a CR as VMS claims the records are supposed to be. . Kermit-32 will only abort a transfer on the controlling terminal line if two control-Y's are seen in sucession (without any other character or timeout in between). This will keep a single glitch of a control-Y from killing a transfer. . There is a new file type - FIX. This will cause Kermit-32 to create a 512 byte fixed record length file. This is useful for transferring .EXE or .TSK files. . The SET FILE_TYPE command has been changed to SET FILE TYPE. This change was to allow for the addition of the SET FILE NAMING command (FULL, NORMAL_FORM, UNTRANSLATED). . Parity problems fixed. . The GET and RECEIVE commands are now different. RECEIVE now allows the user to give the name into which the file is to be received. This is the same as the RECEIVE command in Kermit-10 and Kermit-20, and conforms to the "standard" format for Kermit commands. . All messages output from the CONNECT command are identified by the node name of the system Kermit-32 is running on (the translation of SYS$NODE, if any). . Some new server functions have been added, some by spawning suprocesses with DCL commands. The new functions includ COPY, CWD, DELETE, HELP, HOST, RENAME, SEND (a terminal message), SPACE (query), TYPE, WHO (show system). . The LOG command has been added to support log files for SESSION, TRANSACTION, and DEBUG. . There is now a PUSH command to spawn a new sub-process. . Sites which wish to enforce restrictions on the files which may be transferred with Kermit can now supply a routine which will validate a file specification. The file KER:VMSV3.MEM gives greater detail about the new release, and lists the component files and their functions. ------------------------------ Date: Fri 1 Jun 84 13:33:45-EDT From: Nick Bush <G.BUSH@COLUMBIA-20> Subject: DEC TOPS-10 KERMIT 3(124) To: Info-Kermit New features and changes in Kermit-10 version 3(124) are detailed in the file KER:K10V3.MEM. Many of them parallel the new VMS KERMIT. A few major changes are: . KERMIT-10 can now run on KI10 processors, KL-only instructions removed. . Correct operation on non-network (ANF-10) systems. . Server can do CWD, DELETE, DIRECTORY, HELP, SPACE, STATUS, and TYPE. . During local operation, send full range of commands to remote server. . Improved local operation. . TAKE command added. . DEFINE for SET macros as in KERMIT-20. . SET FILE BYTESIZE, NAMING, WARNING. . LOG SESSION, TRANSACTION, DEBUG . SET PROMPT . Bugs in wildcard processing fixed. The new files are in KER:K10*.*. KER:K10V3.MEM explains which files are which. ------------------------------ Date: Fri 1 Jun 84 13:33:45-EDT From: Nick Bush <G.BUSH@COLUMBIA-20> Subject: DEC Professional-350 KERMIT 1.0 To: Info-Kermit Announcing the first release of KERMIT for the DEC Professional-350 PDP-11 based microcomputer running P/OS. This version is based on the Common BLISS modules that are used in Kermit-10 and VAX Kermit, so contains most of the functionality of Kermit-10 and VAX Kermit. The user interface is menu driven in the P/OS style. Pro/Kermit is not dependent on any Digital product to do the communications, so Pro/Communications is not required to run Pro/Kermit. The following functionality is currently implemented in Pro/Kermit: CONNECT (to host) . GET (files from server) . SEND (files) . Commands for servers: LOGOUT, FINISH, BYE, TYPE, DIRECTORY, DISK (space), CHANGE (cwd), STATUS, HELP, HOST, COPY, RENAME, WHO . Server operation: sends & receives files, honors remote commands like TYPE, FINISH/LOGOUT, etc. . P/OS Services - Enter various P/OS services from Kermit. These are the various services found in the main menu of P/OS. . SET commands. A full range of parameter setting is provided. The files are in KER:PRO*.*. KER:PROV1.MEM lists the files in detail, including the files that are necessary in the bootstrapping procedure for getting Pro-350 KERMIT initially from a mainframe to the Pro. [Ed. Note - There is also a version of KERMIT for the P/OS, written in DECUS C by Bob Denny. We do not yet have this program in distributable form. Presumably the Stevens hexification & downloading procedures can be applied to that program too.] [Another note - Venturcom's Venix operating system will soon be announced for the Pro-350. Unix KERMIT runs adequately on that system, but performance is very poor. A new Unix KERMIT specially tailored for the Pro-350 with Venix will be announced shortly.] ------------------------------ Date: Thu 31 May 84 19:42:28-EDT From: Frank da Cruz <SY.FDC@CU20B> Subject: Commercial KERMIT Guidelines To: Info-Kermit@CUCS20 I've been getting a lot of requests lately from hardware and software vendors for permission to include KERMIT in their products. I've written a new flyer which I'm sending in response to these queries. It's in KER:COMMER.DOC in case anyone is interested in looking at it. ------------------------------ End of Info-Kermit Digest ************************* ------- 11-Jun-84 18:44:03-EDT,7483;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 11 Jun 84 18:43:15 EDT Date: Mon 11 Jun 84 18:39:36-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #5 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 11 June 1984 Volume 1 : Number 5 Today's Topics: Cray-1 Kermit Progress Report Bug fixed in CP/M-80 Kermit 3.9 IBM-PC DOS Kermit Terminal Emulation Cyber Kermit Document File TRS-80 Kermit File Problems Macintosh Kermit No-Progess Report ---------------------------------------------------------------------- Date: 1 Jun 1984 21:09:40-MDT From: Leah F. Miller C-10 <lfm@lanl> To: cc.fdc@columbia-20 Subject: Cray Kermit Thanks for putting me in touch with Lila Chase at Livermore. We have agreed that they will give our Cray Kermit (LANL's) a friendly user tryout, probably next month. They were attempting to port NOS Kermit to the Cray and finding it difficult because of the very different character handling capabilities of the 2 machines. In return for this, we get the benefit of their experience with Unix Kermit on the SUN PC. If all goes well, I expect to put Cray Kermit on general release in late summer, at which time it will have been tested in communication with at least 2 other Kermits. ------------------------------ Date: Wed 6 Jun 84 16:41:54-EDT From: Frank da Cruz <SY.FDC@CU20B> Subject: Bug fixed in CP/M-80 Kermit 3.9 To: Info-Kermit@CUCS20 CP/M Kermit 3.9 has a serious bug. When connected to another Kermit (such as VAX/VMS or DEC-20 Kermit) that agrees to do 8th-bit quoting, but does not explicitly request it (which is the normal case on communication lines where the parity bit is not used), any ampersand in an outbound file will have a spurious pound sign inserted before it. A fix for this problem was posted in a recent Info-Kermit digest by Charles Carvalho of ACC. That fix has been installed in Kermit-80, and new .HEX files have been built for most of the systems supported by Kermit-80. The fixed version is called 3.9A and the new files are in: KER:CPMBASE.M80 Source file KER:CPMBASE.UPD Update history KER:CPMKERMIT.BWR "Beware" file KER:CPM*.HEX New hex files, e.g. CPMKAYPRO.HEX, CPMAPPLE.HEX These files are available in the usual manner from COLUMBIA-20 (ARPAnet) or CU20B (DECnet). Kermit-80 3.9A is a stopgap release until the new modularized version 4 is released by Charles Carvalho. ------------------------------ Date: 10 Jun 84 13:46:42 EDT From: D. M. Rosenblum <DR01@CMCCTE> Subject: IBM-PC DOS KERMIT TERMINAL EMULATION To: INFO-KERMIT@CUCS20 When I run IBM-PC Kermit version 1.19 (or C-MU's 1.19A) under DOS 2.0, I tell the DEC-20 that I am talking to that my terminal type is VT52. This works fine. Some of my friends here tell me that I can tell the 20 that my terminal type is Zenith-19 (what you call H19 at Columbia), and I have even observed such people running EMACS through their Kermits and getting things like inverse video mode lines, use of line insert and line delete functions, and other such things that Zenith-19s support but VT52s don't. I know, however, that it can't emulate every function of a Zenith-19, because it can't use the 25th line. So apparently it's emulating something in between a full Zenith-19 and a VT52. What exactly is that something, i.e. what are the specs for what it is emulating? Also, if I am talking to VAX/VMS 3.5 (instead of a DEC-20) I find that there are many VT52 functions that it cannot emulate. For instance, SET TERMINAL /INQUIRE doesn't work, and most of the screen handling of VAX/VMS EDT fails badly (e.g. downward scrolling, among other things -- of course, the keypad doesn't work for EDT either, but I have EDT customized to use control characters for most of the stuff that's usually invoked by the keypad, a la EMACS). Could these things be made to work, or are there restrictions in DOS that cannot be gotten around that explain why they aren't implemented? Where, in general, is the precise set of terminal capabilities that Kermit emulates documented? Thanks in advance. -- Daniel M. Rosenblum, Ph.D. candidate, School of Urban and Public Affairs, Carnegie-Mellon Univ. [Ed. Note -- The forthcoming release of MS DOS Kermit will address most of these complaints. It will do reverse line feeds and work with EDT on the VAX. The documentation will include a list of all the H/Z-19 control codes showing which ones are supported by MS DOS Kermit. There will be a key redefinition facility so you can make the keypad or the functions keys send anything you like. I hope to be able to announce it this week.] ------------------------------ Date: Mon, 11 Jun 84 13:58:37 cdt From: knutson@ut-ngp.ARPA Subject: Cyber Kermit document file I have put together a .MSS file similar to the others referenced by KUSER.MSS. It is available via anonymous FTP from UT-NGP as file 170KERMIT.MSS. I think for the most part it is formatted correctly. You might want to take a look at it and check for yourself. Jim Knutson ARPA: knutson@ut-ngp UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson Phone: (512) 471-3241 [Ed. Note -- It's available in KER:170KERMIT.DOC and .MSS on COLUMBIA-20 and CU20B, accessible via FTP and NFT, respectively.] ------------------------------ Date: Mon, 11 Jun 84 02:29:30 cdt From: Stan Barber <sob@rice.ARPA> To: cc.fdc@columbia-20.ARPA, stan@rice.ARPA, towson@Amsaa.ARPA Subject: TRS-80 Kermit File Problems I have checked some of the code on Columbia-20 and some of the .SRC files have missing tails. <KERMIT>TRSMAKE.BAS is correct except for an error on my part. Line 150 starts 150 ' some code the ' needs to be removed before running the program. Stan sob@rice [Ed. Note -- Actually, it appears that the *.SRC files are not missing anything at the end; rather they have a ^Z and then some junk after the end (sound familiar, CP/M fans?). The TRSMAKE.BAS file has been corrected, and the junk has been lopped off the end of TRS*.SRC. The TRS-80 I & III Kermit files are available in KER:TRS*.* on COLUMBIA-20 and CU20B.] ------------------------------ Date: Mon 11 Jun 84 18:26:34-EDT From: Frank da Cruz <SY.FDC@CU20B> Subject: Macintosh Kermit No-Progess Report To: Info-Kermit In response to the many inquiries I've been getting about this... We (Columbia) are totally committed to writing Kermit for the Macintosh, and probably also for the Lisa. We're a member of the Apple University Consortium, and we've submitted a proposal to Apple about adding Kermit as one of Macterminal's protocols. So far, no word back from Apple. The major hangup, however, is that Apple has been unable to deliver the Lisa II development systems we have had on order for many, many months (we never bought any Lisa I systems). There may be some possibility of using the SUMEX "sumacc" VAX-based cross development system instead of a Lisa, but we don't yet have a system to run it on -- Eunice under VMS would be about the best we could do, but we don't have Eunice yet... More news as (if) it develops... ------------------------------ End of Info-Kermit Digest ************************* ------- 15-Jun-84 13:16:07-EDT,14229;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 15 Jun 84 13:15:23 EDT Date: Fri 15 Jun 84 13:12:45-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit-Digest V1 #6 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Friday, 15 June 1984 Volume 1 : Number 6 Today's Topics: New Kermits, How To Get Them New Release of PDP-11 Kermit New Software Tools Ratfor Kermit New Version of Sirius MS DOS Kermit CMS Kermit and Yale IUP Kermit-80 Status Report DEC-20 KERMIT Review Telenet and Kermit ---------------------------------------------------------------------- Date: Fri 15 Jun 84 12:00:00-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20> Subject: New Kermits, How To Get Them To: Info-Kermit This issue of the Info-Kermit digest contains announcements of several new KERMITs. For the benefit of those who are new to the Info-Kermit list, and to refresh the memories of those who aren't, here's how to get the KERMIT files: ARPANET/Internet Use FTP, connect to host COLUMBIA-20, login as user ANONYMOUS with any non-null password, and GET (or MULTIPLE GET) the files you're interested in. Anonymous FTP access to COLUMBIA-20 is allowed only after 6:00pm and before 6:00am. CCNET (DECNET hosts at Columbia, CMU, CWRU, NYU, Stevens, and (soon) Vassar): Use NFT to COPY the desired files from CU20B::KER:. If you're on a VAX, just use the COPY command. Specify /USER:ANONYMOUS. If CU20B does not grant you anonymous access, ask your system manager to get the files. BITNET: On an IBM VM/CMS system, type the command SMSG RSCS MSG CUVMA KERMSRV HELP to get instructions for how to use the Kermit server at host CUVMA. There is usually a delay between the announcement of a new version of Kermit and its availability on BITNET, because each file has to be painfully screened and possibly processed to fit the requirements of our RJE link. Other networks like USENET, MAILNET, etc, or if you're not on a network: Send mail to Info-Kermit-Request@COLUMBIA-20, or to: KERMIT Distribution Columbia University Center for Computing Activities 612 West 115th Street New York, N.Y. 10025 and we'll send you flyers explaining how to order a distribution tape. ------------------------------ Date: Fri 15 Jun 84 11:57:22-EDT From: Frank da Cruz Subject: New Release of PDP-11 Kermit To: Info-Kermit Announcing version 2.16 of PDP-11 Kermit for RSX-11/M and M+, RSTS/E, and now also RT-11, from Brian Nelson at the University of Toledo, Ohio. The major changes since the previous release (2.11, March 1984) include: Support for the RT-11 operating system (v4.0 or later) . Performance improvements in both asynchronous and disk i/o . Software controlled parity . Support for half duplex communication . Ability to transmit a BREAK signal . Support for attribute packets, mainly for use between FILES-11 systems. . Support for DECnet (RMS DAP) file access (added by Bob Denny). Kermit-11 is probably the most advanced version of Kermit presently available. It implements practically every feature described in the 5th edition of the protocol manual, including the full range of server file management functions. Although the RSTS and RSX versions use RMS for i/o, you do not have to have RMS on your system in order to use it, and Kermit-11 does not have to create RMS files as output. The installation instructions explain how to run Kermit-11 on non-RMS systems. The files for all 3 operating systems are in KER:K11*.*. There about 59 files, occupying a total of about 1760K (703 DEC-20 pages), so before taking them all you should first look at KER:K11INS.DOC, the installation notes, which describe in detail the exact prerequisites for installing or running this program, and it may give you an idea of which files you might not need. A detailed list of changes to the program is in the file KER:K11CMD.MAC. The new help files for the program were inadvertently omitted from the tape I received, but they should be available soon. Meanwhile, Kermit-11 is very close to the "ideal" Kermit described in the main part of the 5th edition Kermit User Guide. This release will also be available on the Sring 84 RSX and other DECUS SIG tapes. ------------------------------ Date: Mon, 11 Jun 84 14:41:37 pdt From: Ken Poulton <kdp%hp-labs.csnet@csnet-relay.arpa> To: cc.fdc@columbia-20.arpa Subject: New ST Ratfor Kermit Here is the latest Software Tools Ratfor Kermit. I am sending you three files: the formatted doc, the doc source, and the program source. The latter two are in ST 'archive' format; standard format for ST distributions. Any Software Tools implementor can install this rather simply on his/her machine: the machine dependent parts are well flagged and few. Further versions will be forthcoming, but this should serve for anyone's initial implementation. Implementors should also pick up the standard user's and protocol manuals. Ken [Ed. Note - The files are in KER:ST*.*. It is configured for the Univac 1100 and the HP3000, and designed to be easily adapted to any other system that has the Software Tools package, which must be present before you can run it. The file KER:STKERMIT.HLP tells more about the program, and also how to get the Software Tools package.] ------------------------------ Date: 18-May-84 From: Barry Devlin, Computer Center, University College, Dublin Subject: New Version of Sirius MS DOS Kermit Here is a new version of Sirius MS-DOS Kermit. I have merged it into version 1.20 of the IBM PC Kermit, and have added a reasonable degree of VT100 emulation. Also, the bootstrapping method has been made to work for the Sirius. Considering the demise of the Victor in the U.S. and the much greater popularity of the Sirius in Europe, I suggest we settle on the SIR prefix for distribution. VIC also has some Commodore implications. I have not made any attempt to update the CP/M-86 version for the Sirius although I am aware of some problems in the area of end-of-file handling and also in wildcarding. When the Rainbow CP/M-86 version touches these areas I hope to return to the problem. [Ed. Note -- The new Sirius MS-DOS version is available as KER:SIR*.*. The present CP/M-86 Kermit that runs on the Rainbow and NEC APC do handle wildcards and eof correctly; Barry will receive a copy.] ------------------------------ Date: 18-May-84 From: Barry Devlin, Computer Center, University College, Dublin Subject: CMS Kermit and Yale IUP Here in U.C.D. we will be moving away from the beloved 2060 towards a more IBM oriented computer centre. However, the communications and terminal base on campus will remain ASCII in character. It is envisaged that the Series-1 / Yale IUP with support for VT100s will continue to be the way of supporting these terminals. This means that Kermit for CMS is becoming very important. Is there a better version now available? And what do you think of the chances of running it through the Series-1? We had a look at the old CMS Kermit and felt it should be possible to use the transparent Series-1 mode to do the packet transfer and perhaps full-screen mode terminal emulation. We would be interested to hear if anyone has done anything about it. [Ed. Note -- We will be working on CMS Kermit this summer, and making it work with the Yale IUP is one of the areas we'll be investigating.] ------------------------------ Date: 13 Jun 1984 0106-PDT From: Charles Carvalho <CHARLES at ACC> Subject: Kermit-80 Status Report To: CC.FDC at COLUMBIA-20 Cc: CHARLES@ACC Hi. I'll be away on vacation June 14-24, and my system is not portable (besides, I would worry about getting sand in the floppy drive). I sent version 4.00 to David Kirschbaum (abn.iscams@usc-isid); he's put in support for his Decision I and the TAC trap code; meanwhile, I've fixed some minor problems and added some documentation and produced v4.01. We'll have to figure some way to get these two back together. He also made everything assemble under LASM, which we ought to be able to supply with Kermit, it being public domain. (He also uses MLOAD rather than DDT to merge the two hex files). The current delay is documentation. I've got some very rough notes on generating Kermits for supported systems, but nothing yet on how to add support for a new system (which shouldn't be too hard, since there are about 18 examples). There's also about 25 Kbytes of notes on what I've changed. /Charles [Ed. Note - For those who missed earlier announcements to this effect, Charles is working on a new, modularized, version of Kermit for CP/M-80.] ------------------------------ Date: Thu 7 Jun 84 16:02:02-PDT From: Ken Harrenstien <KLH@SRI-NIC.ARPA> Subject: DEC-20 KERMIT Review To: cc.fdc@COLUMBIA-20.ARPA [Ed. Note - My comments are indented like this.] OK, I've looked at the 5th edition stuff a bit and have the following comments. Most has to do with the TOPS-20 KERMIT.MAC program, version 4(215). (1) It is extremely annoying to have a document file with 80 chars per line. Please make the default LPT versions something more reasonable such as 72. Not all printers can handle 80 chars, and for those which can, it is nice to have SOME right margin for readability and notes. NIC documents are limited to 72 chars per line for this reason. Of course this will make the documents a few pages longer, but the whole point of documentation is to convey information in a way which is clear and easily readable! [OK, next time thru the wringer, they'll come out narrower.] (2) The protocol badly needs a "bare" control-char convention. You should define it NOW before various people (eg me) go off and implement their own. Of course it should be an option, but still it should be provided. A simple start would be an option bit that says the program has complete control over all input and output -- in other words, all characters can be sent and received, and you don't have to pull your hair trying to figure out which ones are ok and which aren't. [In fact, there's nothing in the protocol that says you HAVE to transmogrify all control characters. You can stick bare ones into packets right now, and they'll come out correctly on the receiving end, provided you don't do this with SOH (Control-A, the normal start-of-packet marker), with the XON or XOFF characters if XON/XOFF is being done, etc. However, watch out for the case when both hosts THINK they know which control characters they can handle but some piece of communication equipment that's somewhere between them knows otherwise. Anyway, you're right, this needs more thought.] (3) KERMIT-20 GET doesn't provide any way to specify different local filenames (such as RECEIVE and SEND do). It should. (4) KERMIT-20 is screwed up after a ^Z or ^X -- SEND complains "no files to send" even when an argument is specified! They don't appear to actually abort a file transfer, either... even when SENDing the file! (5) KERMIT-20 GET can't get a filespec starting with "!" because that is the TOPS-20 comment character. It doesn't help very much to quote it because the resulting filename is almost certainly going to be highly unusual, if not illegal -- this because of the problem above where you can't specify the local filename. (6) KERMIT-20 has this incredibly brain damaged misfeature where it quietly turns off the receive-link bit for the user's terminal, and leaves it off! I can understand this while it is in SERVER mode, but not local mode!!! There is absolutely no justification for refusing links in local mode -- that should be up to the user, who determines this with EXEC commands. (7) TTLINK doesn't appear to ever actually set the terminal speed to what was specified. This is a pain because often outgoing lines are set to speed 0 to prevent noise problems, and hooking up to one with TTLINK isn't going to do anything (whether or not a speed is specified) until you realize what is going on (50 points for intuitive flash) and manually clobber it with ^ESET TER n SPE. There doesn't seem to be a good way to pass parameters like SPEED from KERMIT-20 to TTLINK by the way. That seems to be all that was on my list at the moment. [I'll look at all the Kermit-20 and TTLINK complaints as soon as I get a chance.] Oh! One other thing I remembered. TTLINK or KERMIT (I suspect the former) sends a CR every time you start or resume a connection. This is very bad, because sometimes the first char you send should be a special auto-baud speed set char, and CR is not always the right thing. Also, during a connection, this makes it extremely annoying if the other end is talking to a text editor -- you get CR's inserted -- or if the other end is awaiting some test input such as a filename (CR sets it going with defaults that you DON'T want!). Grumble, grumble. This is a pretty serious misfeature, I'd say. I don't see any good reason for it at all. [TELNET does this too. Can anybody think of any undesired consequences of removing this behavior?] --Ken ------------------------------ Date: 14 Jun 84 09:46:30 EDT From: RC0T@CMU-CC-TE <RC0T@CMCCTE> To: info-kermit@CUCS20 Subject: Telenet and Kermit We are part of the Telenet network. But if users use Kermit on their PCs and then connect through Telenet the sending and receiving of files fails immediately. Would you have any suggestions as to why this is happening? Thanks. Rick Costa User Services [Ed. Note - I've used KERMIT over TELENET successfully by giving the command SET PARITY MARK to the Kermits on both ends.] ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Jun-84 18:41:28-EDT,5756;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 18 Jun 84 18:41:13 EDT Date: Mon 18 Jun 84 18:32:08-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #7 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 18 June 1984 Volume 1 : Number 7 Today's Topics: Dialup Access to Kermit Files Looking for Kermit for Pick OS Coco Os9 kermit Kermit On Telenet Cray Kermit Progress ---------------------------------------------------------------------- Date: 15 Jun 1984 1753-EDT From: B.Eiben LCG <EIBEN at DEC-MARLBORO> To: Info-Kermit at COLUMBIA-20 Subject: Dialup Access to Kermit Files You might want to stick us in too: DEC-Marlboro 617-467-7437 (300 / 1200 Baud) two Control-C's LOG LCG.KERMIT KERMIT distribution area is KERMIT: It's a public account - and has been "pushed" in DECUS and otherwise - to my knowledge the "only" way to get KERMIT via "Ma Bell" without any other "special connections". [Ed. Note -- That's Digital Equipment Corporation, Marlboro, Massachusetts, USA. The machine is a DECSYSTEM-20. Thanks, Bernie!] ------------------------------ Date: Fri, 15 Jun 84 11:21:18 pdt From: Ken Poulton <kdp%hp-labs.csnet@csnet-relay.arpa> To: info-kermit@csnet-relay.arpa Subject: Looking for Kermit for Pick OS Does anyone know of a Kermit for the Pick operating system? Failing that, how about a Kermit written in Basic? [Ed. Note -- I haven't heard of anyone working on Kermit for Pick, but there is a Basic implementation for a Swedish micro, the Luxor ABC-800, in KER:800*.*. I've been told that it's a rather unusual dialect of Basic.] ------------------------------ Date: Sat 16 Jun 84 00:32:53-PDT From: Bob Larson <BLARSON@USC-ECLB.ARPA> Subject: Coco Os9 kermit To: info-kermit-request@COLUMBIA-20.ARPA I am listed with Good intentions of implementing Trs-80 Color computer Kermit in an unknown language for an unknown operating system. I have good intintions of implementing os9 kermit in (microware) C on my color computer. Due to os9 doing a very good job of insulating the user from piculuarities of hardware, it is my belief (and hope) that this implementation could be run on any 6809 os9 system. (There is also a version of os9 for the 68k, I can't tell how easy it would be it convert to it.) There is also someone listed with good intentions of doing a kermit for a swtp system. Do you you know what operating system he is using? Also note that they have changed my user name from Larson@Usc-Eclb to Blarson@Usc-Eclb. (They decided to make user names unique on all Usc-Ecl systems.) Bob Larson <Blarson@Usc-eclb> [Ed. Note - The SWTPc system is running FLEX. I added this and your info to KER:VERSIONS.DOC.] ------------------------------ Date: Sun 17 Jun 84 20:53:50-PDT From: Doug Brutlag <brutlag@USC-ECL.ARPA> Subject: KERMIT ON TELENET To: cc.fdc@COLUMBIA-20.ARPA, rc0t%CMCCTE@COLUMBIA-20.ARPA Frank, Another way to get KERMIT to transfer files on TELENET is to configure TELENET to transmit the eighth bit. Most TELENET nodes are set up for 7 bit communications only. You can set up eight bit mode, by connecting to your host, then escape back to TELENET (with cr @ cr) and giving the command: SET? 0:33,63:0 The 0:33 parameter allows you to set certain ITI parameters normally not used by TELENET users. The ITI parameter 63 enables the eighth bit when set to 0 (contrary to what is written in the TELENET documentation by the way). I have found this setting useful for both KERMIT file transfers and for using a terminal with a META key for setting the eighth bit for EMACS editing commands. If this fails you should call the TELENET 800 number to find out how to allow eight bit communications for your node. SOme nodes use old TELENET protocols which require setting parameter 57:1 as well. If you have many people using KERMIT via TELENET you can have your TELENET representative change your local node to make the default setting of parameter 63 be 0. By the way I do not encourage people to use KERMIT via TELENET because of the delay in receiving the ACK/NAK. Even with an unloaded network and 1200 baud nodes at either end, the delay in receiving the ACK/NAK effectively lowers the transmission speed from 1200 baud to less than 300 baud. Doug Brutlag [Ed. Note - We will try to work out a "sliding window" option for the Kermit protocol over the summer. This should speed things up a bit, assuming it can be widely implemented.] ------------------------------ Date: 18 Jun 1984 14:24:02-MDT From: Leah F. Miller C-10 <lfm@lanl> To: cc.fdc@COLUMBIA-20 Subject: Cray Kermit Progress We have a portable pre-release Kermit up and running on both the Cray-1 and the Cray X-MP. It runs under the CTSS (Cray Time Sharing System) operating system which was developed at Livermore and is fairly widely used at gov't laboratories. I think, however, that anyone wishing to port it to a COS (the batch OS provided by CRI) system would find this a matter of replacing a few low-level subroutines. As of today Cray Kermit has been tested only in communication with one partner, Kermit-86 on the IBM-PC, and in one environ- ment, the LANL network. Therefore, estimated general release date remains "late summer". Enjoyed your article in Byte and look forward to Part 2 ! Leah Miller ------------------------------ End of Info-Kermit Digest ************************* ------- 20-Jun-84 11:20:19-EDT,12638;000000000001 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 20 Jun 84 11:19:31 EDT Date: Wed 20 Jun 84 11:15:26-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #8 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 20 June 1984 Volume 1 : Number 8 Today's Topics: Control-Character Prefixing Performance of Kermit over Packet Networks (several messages) Server Mode for Micros (several messages) BLAST - KERMIT Lookalike? ---------------------------------------------------------------------- Date: Mon, 18 Jun 84 14:17:20 pdt From: Ken Poulton <kdp%hp-labs.csnet@csnet-relay.arpa> To: info-kermit@csnet-relay.arpa Subject: Control-Character Prefixing I'm not convinced as to the need for sending "bare" control characters. This is one of the beuties of Kermit! You don't *have* to worry about who cares about what control characters. Defining a bit for "I can take anything without control quoting" is an easy first step, but anything beyond that would probably add several pages to the protocol manual which are almost never implemented. Most of all, though, I don't see any motivation. Text files contain only a small percentage of control characters, so there's little need for efficiency's sake. Binary files do incur a 25% overhead due to control quoting, but they incur an additional 50% overhead due to eighth-bit quoting. So... why bother? [Ed. - Actually, a 25% improvement is nothing to sneeze at. Also, the 50% overhead for 8th-bit quoting only occurs over 7-bit channels; most Kermit connections are 8-bit, so they don't get this overhead. Therefore, the control-character prefixing dominates. The trouble is, you're just not safe eliminating it unless you have a hardwired connection whose characterstics are fully known. Also, not only will it add pages to the manual, but it'll add startup overhead, translate tables to the program, etc. But it's still worth looking into.] Is anyone thinking about a better binary encoding? It would be nice to use something like the Unix uuencode's 4-bytes-for-3 translation to cut down on the overhead for binaries. Seems like a way to specify record breaks would be nice, so as to accomodate those arcane systems (IBM + HP3000, f'rinstance) that have such things as variable record size binary files. [Ed. - We're encoding the new MS-DOS Kermit binaries with 4-for-3, and also collapsing adjacent 0 bytes. We find the result to be smaller than the .EXE file itself. All this will be announced soon. With Kermit attribute packets (unimplemented anywhere except in the PDP-11 versions) it is possible to specify the encoding, so certainly 4-for-3 could be one of the alternatives. There's also an attribute that specifies that the file is composed of arbitrary records preceded by length fields.] ------------------------------ Date: Mon, 18 Jun 84 17:04:55 pdt From: Ken Poulton <kdp%hp-labs.csnet@csnet-relay.arpa> To: info-kermit@csnet-relay.arpa Subject: increasing kermit throughput on long-distance lines We have an interest in using kermit for file transfer over long lines and packet networks, where the roundtrip delay may reach several seconds. Clearly, several seconds of delay causes some severe throughput problems with kermit's packet-acknowledge protocol. In the current protocol manual, under "Unresolved Issues", mention is made of a "floating window" scheme: send a bunch of packets and then wait for acknowledgement; ack for packet N implies ack for all packets < N. It occurs to me that this could be implemented with nothing more than some buffering on the sender's side. No negotiation is required; the sender must simply be sure that the number of packets he sends at one time does not exceed the number of nak's the receiver will send before quitting (the receive retry limit). Has anyone tried this? Does anyone see a hole in my reasoning? [Ed. - I think there's got to be some agreement between the two sides. Retries are used to recover from errors, and the same counter shouldn't be used to count two different things. Anyway, there has been a lot of talk about adding this to Kermit (see next message for another example), and it should be carefully considered.] ------------------------------ From: ihnp4!sask!derek@Berkeley Date: 18 Jun 84 13:58:45 CDT (Mon) To: cc.fdc@columbia-20.ARPA Subject: a plea First, let me say that the work you are doing with Kermit is fantastic. It is really a wonderful package unselfishly contributed to the world. Now, let me ask for a favour. Presently, the maximum packet size is 80 characters. I implore you to consider allowing it to be 256 characters. In Canada, we have a network called Datapac. It is similar to Telenet. It is a packet switched network allowing packets to be a maximum of 256 characters. It costs the same to send a 1 byte packet as it does to send one of 80 or 256 characters. Allowing Kermit to send 256 byte lines would keep the cost of Datapac connections down. Is it too late to try to incorporate this into the standard? I would hate to make a change to Kermit to allow this only to be incompatable with the myriad of Kermits out there. Thank you for your time. Derek Andrew U of Saskatchewan (Canada) Arpanet: "sask!derek"@utah-cs ------------------------------ Date: Wed 20 Jun 84 09:56:07-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Re: a plea Actually, the maximum Kermit packet length is 96. This is not an arbitrary number, but rather a consequence of the fact that the length field is encoded as a single printable character, of which ASCII has 94 (the length field does not include the SOH or the length itself). We designed it this way on purpose, because we found that other protocols that used longer packets (especially fixed length longer packets) would not work with certain popular systems that had trouble receiving 256 or 128 characters at once. By making it impossible for anyone to write a Kermit that would "overload" any other Kermit, we have kept the protocol more generally useful. I agree, however, that the performance is not what it could be. For applications in which you know the characteristics of the communication medium and the two systems involved, you would like to get more throughput. This can be done by either lengthening the packets, or allowing multiple packets to be sent in a stream. Longer packets incur a higher cost in retransmission overhead, and would require use of CRC for error detection, as the current 6-bit checksum would be pretty inadequate for a 200 (or 1000) character packet. A stream of packets (the "floating window" technique) would achieve the same effect, but would work less than optimally on half duplex connections. Incidentally, it would be relatively easy to extend the packet length. Since the length field always includes the type and block check fields, it can never be less than 3. Therefore, values of 0, 1, or 2 could be set aside for special uses. For instance, 0 could mean that the first 2 (or 3 or 4) characters of the data field were an extended length field. The ability of a Kermit program to handle this would be flagged in the Send-Init capabilities mask, and corresponding special values would also have to be used in the MAXL field of the Send-Init. We are looking at the possibility of adding both these options to the Kermit protocol, but bear in mind that adding things to the protocol specification and getting them into 50 or 60 implementations are two different things. - Frank ------------------------------ Date: 18 Jun 1984 23:00-EDT Subject: pc server code From: POLARIS@USC-ISI.ARPA To: info-kermit@COLUMBIA-20.ARPA Have there been any personal computer KERMITS which include server functions besides Herm Fischer's (excellent!) additions to the IBM-PC version? I am curious to see if the "other end" of the line code has been done for KERMIT in the same manner as XMODEM vs. MODEM7, particularly for CP/M systems acting as bulletin boards or public domain software distribution points. mike seyfrit <polaris@usc-isi> [Ed. - The forthcoming MS-DOS Kermit release will incorporate Herm's server code. See below for more on this subject.] ------------------------------ Date: Tue 19 Jun 84 19:56:16-PDT From: William Pearson <PEARSON@SUMEX-AIM.ARPA> Subject: CPM kermit To: info-kermit-request@COLUMBIA-20.ARPA I have just set up Kermit on our VAX, IBM-PC and Heath 89 and am very impressed, particularly with its batch capability. I would like to have a version for a CP/M computer that would have a server mode, so that after I dial up my Heath using BYE (for remote login with password) and then upload or download from a remote kermit. I could also use a version for a NorthStar Advantage. I would have no problem making these modifications myself, but a 175K source file is a little beyond my capacity. I wonder if 1) you know of some way to recompile on a VAX/VMS system (using public domain assembler perhaps) or 2) if you have an uncommented version which is smaller, along with comments where actual i/o is done or 3) a modular version with overlays. (But I suspect that won't help the server mode). Bill Pearson Pearson@sumex-aim ------------------------------ Date: Wed 20 Jun 84 10:09:31-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Re: CPM kermit To: PEARSON@SUMEX-AIM.ARPA The lack of remote, unattended access for CP/M Kermit has long been one of its shortcomings, and accounts for Kermit's relative disuse on the RBBS systems. Charles Carvalho at ACC (CHARLES@ACC) is working on a modularized version of CP/M-80 Kermit. This should solve the size problem nicely, allowing you to work on more manageable chunks at a time. It should also let you easily add support for the North Star, and there's always room for a server module. - Frank ------------------------------ Date: 19 Jun 1984 08:48-EDT Subject: BLAST - KERMIT Lookalike? From: ABN.ISCAMS@USC-ISID.ARPA To: CC.FDC@COLUMBIA-20.ARPA Frank, Just got some literature on a file transfer program called BLAST that's VERY reminiscent of KERMIT (adjustable packet sizes, CRC, sliding window pipelining (isn't that coming this summer?), system-unique file conversion, 8-bit prefixing, settable parity and baud, no master-slave restrictions, log/status, remote site error condition reporting, etc. Has some things I haven't seen in KERMIT (yet), and some I've seen in MDM730 (programmable function keys, delay between characters, send logon, and a bunch of remote system command executions). They have versions for about a hundred different micros, minis, and mainframes, to include the big Data General machines, PDP-11s, HP3000s, Honeywell DPS-8s, IBM 360s (no Cray). Might almost be worth while getting, just to see some of the things they did. NOT to pirate the code, just to see how! (A little backward engineering, my friends??) Source is Communications Research Group 8939 Jefferson Hwy Baton Rouge Louisiana 70809 (504)923-0888 Costs run from $250 for micros to several thousand for the mainframes. Cheapest is $100 for Compaq and IBM PCs, running PC-D200EM OS (what's that?). Just for your info. Regards, David Kirschbaum Toad Hall ABN.ISCAMS@USC-ISID [Ed. - Actually, BLAST has been around for some time. I don't know much about it, but it's probably a lot like Kermit in its capabilities, probably superior in many areas. It's only one of many, many Kermit-like commercial products. They all have their strong and weak points. The commercial products are generally stronger in the area of modem control, login scripts (built-in options for talking to Dow-Jones, The Source, etc), etc, and they usually have jazzy function-key menu-driven user interfaces. Kermit, on the other hand, tends to run on more different kinds of systems more consistently than most commercial products, comes with sources and internal as well as user documentation, invites users to write versions for new sytems, and the price is right... But I don't doubt that Kermit and the commercial products influence each other.] ------------------------------ End of Info-Kermit Digest ************************* ------- 22-Jun-84 18:24:13-EDT,15616;000000000001 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 22 Jun 84 18:23:37 EDT Date: Fri 22 Jun 84 18:18:50-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #9 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Friday, 22 June 1984 Volume 1 : Number 9 Today's Topics: Macintosh Kermit Progress Report Unix Kermit Problems (several messages) Kermit Comments Current Kermit for IBM PC? Control Characters in Packets Micro-Host Transfer Software Recommendation? Comparing Kermit with Other Packages ---------------------------------------------------------------------- Date: Thu 21 Jun 84 18:19:34-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: Macintosh Kermit Progress Report To: Info-Kermit@CUCS20, Info-Mac@SUMEX-AIM.ARPA Columbia has finally received its Lisa-2/10 development system, though we haven't actually tried to use it yet for Mac development yet (we just unpacked it). We had a rudimentary, receive-only adaptation of Unix Kermit running on the Mac briefly, bootstrapped with the Sumacc cross development package. This was painful to do, and only worked once for some reason. We may pursue this avenue, or give it up if the Lisa proves to be easier to deal with. We submitted a proposal to Apple 2 months ago to add Kermit as one of the file transfer protocols supported by MacTerminal. We haven't had a response yet. Meanwhile, a review of MacTerminal in the current (July/August 1984) issue of Macworld compares Kermit favorably to the XMODEM protocol that is already in MacTerminal (p.69). I hope someone at Apple reads the review. What does all this add up to? We'll produce a Kermit for the Mac one way or another. We'd prefer to see it as an option in MacTerminal, since that's the natural place to put it, but failing that we'll do a standalone version. Anyway, at least now we can start. ------------------------------ Date: Wed, 20 Jun 84 10:11:26 edt From: cu-arpa.tesla!pottle@Cornell.ARPA (Christopher Pottle) To: cornell!info-kermit@columbia-20.ARPA Subject: IBMPC-Unix Kermit Problem This problem may be well known, but I am a newcomer. With what I believe to be the latest versions of Kermit for the IBMPC (1.20) and for Vax-Unix (ca. 2/84), the IBMPC hangs with the Waiting... message after sending a file to Unix. One can interrupt out and reconnect, and will find the file safe and sound on the Unix machine. Is this bug known to you? [Ed. - Many Unix Kermit users have reported this problem, and I haven't seen a good solution yet. I'm not a Unix expert, but as I understand it, Unix does most things by putting them on lists of things to do. When you tell Unix to send a packet, it goes out when Unix gets around to it. However, having sent its last packet, an ACK for the PC's "I'm all done" packet, Unix Kermit then restores the TTY to "cooked mode" and exits. This apparently happens immediately, and interferes with the transmission of that last packet, which is still waiting on a list somewhere. A workaround would be for Unix Kermit, after returning from the protocol, to sleep for a second or two before restoring the line.] ------------------------------ Date: Thu, 21 Jun 84 08:17 PDT From: "Chase Lila"@LLL-MFE.ARPA Subject: UNIX Kermit To: Info-Kermit@COLUMBIA-20.arpa Frank, There is a definite problem with UNIX Kermit on our Sun's with Berkeley UNIX 4.2. The phone is hung up or disconnected upon the second call to open the tty line. It had worked with the previous version of UNIX only by luck. I have been told it is hazardous to open the line, exit kermit and open it again upon another invocation of Kermit. Better to have just one invocation. To do this quickly, simply replace if (cflg) by if (!remote) before the connect call. execution then becomes: kermit slb /dev/ttya 1200 filename (locally) kermit r (remote) Evidently this problem does not happen over hardwire connections (Bob Cattani says). Lila Chase (415) 422-4086 chase@LLL-MFE ------------------------------ Date: Thursday, 21 Jun 1984 14:21-PDT To: cc.fdc@COLUMBIA-20.ARPA Cc: unix-wizards@BRL-VGR.ARPA Subject: unix kermit From: gray@SU-DSN.ARPA Having discovered that cu loses characters at 9600 baud, I tried to bring up Unix kermit on a Callan Unistar 200 running Unisoft System V Unix. It did not compile since TANDEM and FIONREAD are not defined in <sgtty.h> in Unisoft system V and simple fixes do not work. The baud rate is set incorrectly and even if set correctly & ixoff set via stty, Kermit still gets no response from a known functional VAX Kermit (& it seems to keep sending garbage to the Vax). Does anyone have an idea of a way to fix this without drastic rewrites? reply to gray@su-dsn [Ed. - System V support has been added to Kermit, along with support for some of the more arcane versions of Unix. We have perhaps 15 or 20 Unix Kermit contributions waiting to be reconciled with one another. Unix Kermit will be one of our next projects, as soon as we finish the new release of MS-DOS Kermit next week(?). We aim to have a very portable, modular, C-based version of Kermit, providing the full-blown protocol, with support for the various versions of Unix plus some other systems that have C compilers and Unix-like runtime support. Any systems not explicitly supported by all this should be easily adapted by filling in the appropriate i/o primitives.] ------------------------------ Date: Wed 20 Jun 84 19:56:33-PDT From: scott <weikart%hp-labs.csnet@csnet-relay.arpa> Subject: kermit comments To: cc.fdc@columbia-20.arpa i thought your recent byte article did a good job of illustrating the problems of designing a universal ftp. it looks like your second article won't talk about the sociology of kermit development (the distributed development with columbia coordination via national networks), or the vast number of available implementations. was that because you were worried about being inundated with requests? i would hope that your tentative plans for developing a sliding window protocol would include the option to operate full duplex when available, but now that i read the byte article i realize that i hadn't thought about the echoing problem...can't most OS's turn off echoing? [Ed. - It's too late to worry about being inundated with requests... we're getting 5-10 tape requests per day! The second part of the BYTE article, which appears July 1, tells readers how to get Kermit. We're beginning fortification of the mail room now...] ------------------------------ Date: Thu, 21 Jun 84 01:05:07 pdt From: System Mom - root <root%hp-labs.csnet@csnet-relay.arpa> Subject: Current Kermit for IBM PC? I would like to inquire about the current version of Kermit for the IBM PC. Sorry, it's late. What I meant to say is, when is the next version coming out, how can I get it, and what is the current version number? I have 1.3A and have previously asked this question, but have received no reply. I can (hopefully) be reached at ..!hplabs!hplabsb!fujinaka. I don't know how else. So much for 2 years at MIT. Thank you. Todd Fujinaka [Ed. - So much for xxx years at Columbia -- I don't know how to reply... Anyway, I hope we'll have a field test release of the new MS-DOS Kermit at least for the IBM PC & XT next week. 1.3A is ancient; the current release, since last October, has been 1.20. The new release will be called 2.26.] ------------------------------ Date: Wed 20 Jun 84 19:44:13-PDT From: Bob Larson <BLARSON@USC-ECLB.ARPA> Subject: Re: Control Characters in packets To: info-kermit-request@COLUMBIA-20.ARPA Unquoted control characters should not be allowed in kermit without specific negotiation. The current prime kermit will NOT allow unquoted CR or LF. (It is not feasible on the prime to not quote linefeed... they are eaten by primos before any user program can get them (including EMACS)) I recommend that any control character in a packet be considered an error, and a NAK packet sent immediately. This would catch some errors that are only handled by timeouts now. Bob Larson <Blarson@Usc-eclb> [Ed. - The whole area of performance, including bare control characters, long packets, sliding windows, full duplex, deserves - and will get - a lot of thought. Contribution welcome!] ------------------------------ Date: 19 Jun 84 12:23 +0200 From: Edgar_Hildering_SARA%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KERMIT_implementation_and_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Micro-host transfer software recommendation The universities of the Netherlands, technological as well as other, formed a committee for the recommendation of a file tranfer protocol between micro and mainframes of all dutch universities. Although all of the members had heard of KERMIT, some of them even had some experience with it, the committee started to set up a list of requirements for such a protocol. Together with KERMIT there are two other candidates, both commercial packages. Although KERMIT is the most likely candidate, I, as a member of the committee, would like to know if someone has experience with non-private packages other than KERMIT. In concrete: What can KERMIT do that these packages cannot and what can these packages do that KERMIT cannot? May the best win, Edgar. [Ed. - That's a tall order; I'll give it a try below. Other replies are welcome, too.] ------------------------------ Date: Fri 22 Jun 84 18:19:34-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Comparing Kermit with Other Packages To: Info-Kermit@COLUMBIA-20 First let me say that there seem to be two major kinds of commercial packages: the kind that use some variation of MODEM protocol, and the kind that use their own proprietary protocols. First, MODEM (please, any MODEM aficionados feel free to correct any of this)... MODEM and Kermit are similar in that they both use back-and-forth ACK/NAK protocols over asynchronous telecommunication lines. However, MODEM sends fixed-length packets with 128 8-bit data bytes, KERMIT sends variable length packets (up to 96 characters in length) with either 7- or 8-bit data bytes. The MODEM packet control fields use all 8 bits; Kermit control fields only use 7. There are several consequences of all this: MODEM can't work at all over a 7-bit channel, even for text files, because the checksum and other control fields will be wrong. This means that MODEM can't be used over public packet-switched networks like TELENET, or with hosts that require use of character parity, like IBM mainframes. Kermit can send both text and binary files over either 7-bit channels or 8-bit channels, but the data gets longer if you have to squeeze it through a narrower hole. Certain computing or communication equipment cannot accept 128 characters at a time. Their buffers aren't that big. Kermit can accommodate these systems, but MODEM cannot. Many systems cannot accept all ASCII characters, particularly control characters, transparently (see the message about PRIME above for one of many possible examples). MODEM provides no mechanism for encoding otherwise taboo characters. Non-CPM systems, which do not necessarily allocate files in units of 128 bytes or follow the CTRL-Z end-of-file convention, will often have junk at the end of a file received by MODEM. MODEM, to the best of my knowledge, does not have a good mechanism for transmitting a group of files; Kermit has it built into the protocol. Kermit protocol also includes optional features for management of remote files -- directory listings, file deletion, quota checking, etc. Many of the Kermit programs support these optional features. MODEM sends the file bytes exactly as is, whereas Kermit gives you some options for reformatting and compressing. A "text" file is transformed to "canonical form" by Kermit, i.e. a stream of ASCII characters with the "records" (lines) separated by (encoded) CR/LF sequences, so that it may be stored in useful form on the target system. Thus, Kermit may be used on record-oriented systems (like IBM VM/CMS) or on stream-oriented systems like Unix where there record boundaries may be different (LF instead of CRLF); Kermits on those systems that don't store text files in the canonical manner do the appropriate conversions. In addition, Kermit may also be told to send files as-is. On the other hand, MODEM works nicely between like systems (especially CP/M systems) -- it's more efficient than Kermit because it doesn't have to encode and decode the data, and the packets are somewhat longer. Also, much greater attention has been given in MODEM programs to modems themselves, and MODEM programs are typically able to control dialout modems from various manufacturers, and to run in "remote mode" when dialed up from the "back port" of a micro (but the forthcoming MS-DOS Kermit will have this ability also). MODEM provides the ability to dynamically switch between 8-bit and 16-bit block checks depending on the error rate; KERMIT provides 6, 12, and 16 bit block checks, but one of these must be selected ahead of time and will be used throughout the transfer. There's more, but in short I think that, on balance, Kermit is more flexible and more easily adaptable to new systems; hence its rapid spread to a wide variety of micros, minis, and mainframes. Now, as to commercial packages with proprietary protocols -- well, who knows? In some cases, these protocols may be superior to Kermit in every way. But you have certain problems with any commercial package: Are implementations available for all the systems you want them for? If not, will the vendor write the missing implementations? When? For how much money? Does the protocol make assumptions (like full duplex communication, 8-bit data path) that would lock out certain classes of systems? Do you have enough money to buy the software licenses for your mainframes and each and every one of your micros? Some sites have thousands of micros. A typical commercial file transfer package costs $500-$5000 dollars for the mainframe end and $50-$500 for each micro. Can your vendor fix bugs in a timely fashion? If you had sources, you could fix them yourself, but most vendors don't provide sources. Many commercial packages are very fancy, both in the protocol and the user interface. But they often tend to be specially tailored to a certain combination of systems and/or applications. Kermit is not as fancy as a commercial product that knows how to dial up Dow-Jones and look up your stocks, reformat the data as it comes in, and display it in a color pie chart, all upon a single keystroke. But then that package probably can't exchange text and binary files with 50 or 60 different kinds of systems in a relatively uniform and consistent way. Comments, rebuttals, are invited. - Frank ------------------------------ End of Info-Kermit Digest ************************* ------- 26-Jun-84 11:15:54-EDT,10161;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 26 Jun 84 11:15:19 EDT Date: Tue 26 Jun 84 11:15:10-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #10 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Tuesday, 26 June 1984 Volume 1 : Number 10 Today's Topics: Begging for Mercy IBM-PC Kermit & Ctrl-PrtSc Kermit for the DEC-Pro 350 Unix Kermit Hangs Call for Unix Kermits! Many Things Kermit for the Macintosh ---------------------------------------------------------------------- Date: 22-JUN-1984 09:07 CST From: STEVENS@MACCWISC.MAILNET To: CC.FDC@COLUMBIA-20.ARPA Subject: Begging for Mercy I am quite sure that your heart is in the right place so I say all this only to reinforce what you already know. !!!!!!!KEEP THE MINIMUM KERMIT SIMPLE!!!!! After playing with KERMIT for years it is easy to see how 12th bit binary escape compression ECC re-encoding would fit nicely and be a big help for people using the Mars/Jupiter data link. But to the poor soul reading the protocol manulal for the first time, such notions can only result in despair. He will give up. Let KERMIT be a simple (possibly expensive, possibly slow, possibly "un-friendly") way to get information from any machine to any other machine. Something I can count on. [Ed. - I agree. The minimum Kermit IS simple. You can still write a Kermit program in a few pages of C or other high-level language. Look at the current (5th) edition of the protocol manual. It's divided into two sections, one describing the mandatory features, the other discussing the optional ones. The mandatory features haven't changed at all from the very beginning. The most rudimentary Kermit will always be able to communicate with the most exalted, automatically. Things were a bit more confused in earlier editions of the manual, which was the main reason for the 5th edition.] ------------------------------ Date: 24 Jun 84 14:13:00 EDT From: D. M. Rosenblum <DR01@CMCCTE> Subject: IBM-PC KERMIT & CTRL-PRTSC To: INFO-KERMIT@CUCS20 About three and a half weeks ago, someone here (C-MU Comp. Center) posted a message (only locally, which is why you didn't see it) complaining that when using an IBM-PC as a terminal through Kermit 1.19, one couldn't get a hard copy (on the PC's printer) of what one was doing by using the Ctrl-PrtSc combination. (Ctrl-PrtSc toggles hard-copy printing of everything that appears on the screen on an IBM-PC as it appears. It is different from shift-PrtSc, which merely prints the current screenful.) Apparently Kermit didn't know about slowing down its output to make this work. He asked if anyone had any other terminal emulation programs that did have this feature, and he found that a guy in the Comp. Sci. department here (C-MU) had in fact written such a thing. Unfortunately, it is not available as cheaply as Kermit. This leads to two questions: (I) Do newer versions of Kermit (somehow) support the Ctrl-PrtSc mechanism, and (II) if not is it planned or could it be planned to implement this feature? [Ed. - The forthcoming release of MS-DOS Kermit will do Ctrl-PrtSc.] ------------------------------ Date: 24 Jun 84 14:17:24 EDT From: D. M. Rosenblum <DR01@CMCCTE> Subject: KERMIT FOR THE DEC-PRO 350 To: INFO-KERMIT@CUCS20 The School of Urban and Public Affairs at C-MU is getting some DEC-PRO 350s running RSX-11 (for the time being, anyway -- they may switch to some Unix look-alike or other). Does the PDP-11 Kermit run on these? In particular, does the documentation of PDP-11 Kermit include information on how to install it on a DEC-PRO 350? If the PDP-11 Kermit doesn't run on these, is there a version that does? [Ed. - I assume that when you say RSX-11M, you really mean P/OS with the DCL front end? Kermit for P/OS was written by Stevens Institute of Technology, and is available in KER:PRO*.* in the Kermit distribution area.] ------------------------------ Date: Sun, 24 Jun 84 17:47:23 pdt From: sdcsvax!sdccsu3!brian@Nosc (Brian Kantor) To: cc.fdc@columbia-20 Subject: unix kermit hangs Here at UCSD we're not running a recent version of the unix kermit, but one of the changes we found out needed to be done was to ensure that flushing gets done. In Berkeley (4.2) we have not only to fflush the i/o buffer, but also call the ioctl() function to flush the output buffer. And then, when transfers are completed, we wait about 3 seconds before resetting the tty modes back to normal. We discovered that this was necessary in getting the Christensen protocol programs to work properly; it seemed prudent to put all the same stuff into kermit too just in case it might avoid a load-dependent hang. Since our machines run with load averages anywhere from 0.2 during quarter and summer break and up to 35 or so (with a record of over 100 processes contending for the processor once!!!!), load-dependent "funny noises" kind of hangs are something we look for. ihnp4 \ Brian Kantor, UC San Diego decvax \ akgua >---- sdcsvax ----- brian dcdwest/ ucbvax/ Kantor@Nosc [Ed. - Thanks for the hints; we'll make sure to heed them while working on the new release of Unix Kermit; see below.] ------------------------------ Date: Mon 25 Jun 84 18:31:27-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Call for Unix Kermits! To: Info-Kermit@COLUMBIA-20.ARPA While the Kermit folk at Columbia are busy putting the last(?) touches on the new release of MS-DOS Kermit, I'm trying to gather together all the Unix Kermit suggestions and contributions that have come in since the last (unnumbered) release, in October 1983. I have a pretty good stack of them, but if there's anyone out there who has some additional suggestions or contributions to make, now's the time! I expect that we'll have a minor new release very soon, whose major new feature will be the ability to communicate with IBM, HP, and other half duplex mainframes, and which (I hope) will have the system- dependent conditional compilation code moved into separate modules. After that, I hope we'll have a full-blown server that does most of what's described in the protocol manual, along with some options for local operation, including an interactive command mode as well as the tar-style command line one-shot mode. ------------------------------ Date: Mon, 25 Jun 84 10:06:13 EST From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers) Subject: Many Things To: cc.fdc@columbia-20.ARPA Glad to hear your Lisa arrived - our Lisas and Macintoshes turned up about 10 days ago. We haven't decided whether or not to go in for the Mac in a big way, but a Kermit would be very useful for the ones we have. Many users here have expressed their appreciation of Kermit, so would you pass on their thanks to all involved in the project (we're using VAX/VMS, Unix, CP/M-80, CP/M-86, MS-DOS, RSTS, Apple-DOS, and Cyber Kermits, so there's a lot of people to thank!) Re CP/M Kermit servers and CBBSs - you don't need a server for this purpose. All that is necessary (I think) is to suppress Kermit's send/receive displays, and make all its i/o go through the port that is connected to the modem. Server mode would be useful, but it's definitely in the 'bells and whistles' category. There's no reason why a CP/M Kermit couldn't be used in the same way as a mainframe Kermit that doesn't have Server functions. I have been thinking about producing a version of Kermit for a CBBS that I'm (very) loosely involved with - I'll let you know if anything happens, but I'll wait for the modularised version before I do any work on it. Getting back to Macintosh, Kermit has two big advantages: 1) it works (at least as well as anything else I've seen) 2) it is (effectively) free If you build Kermit into MacTerminal, point 2 no longer applies. Apple's University Consortium is on a smaller scale here (after all, with a total population of 15 million, Universities are smaller too), so say we buy 120 Macs per year. Virtually everyone will need comms software, so if MacTerminal costs $A150 (Lisa Terminal is priced at $A245), that's $A18,000, compared with about $A125 for the Kermit distribution tape. Even if MacTerminal turns out to be cheaper, we are still talking about thousands rather than hundreds of dollars. [Ed. - About Macintosh Kermit -- We would ensure that there would be a free version available, one way or another. What we hoped to do was to fix Macterminal so it could dynamically "load" the protocol module of your choice (XMODEM, KERMIT, MICROCOM, whatever). Macterminal would still be a product, but Kermit would still be free, but hopefully distributed by Apple with Macterminal. But it seems this problem has been solved before we really had to deal with it; see the next message.] ------------------------------ Date: Mon, 25 Jun 84 21:19:05 CDT From: Don Johnson <dhj@rice.ARPA> To: cc.fdc@columbia-20.ARPA Subject: Kermit for Mac Frank, If you trust our implementation, we are writing and are fairly close to being finished with a Kermit for Mac. It is being developed under the Lisa Workshop environment. It will include prefixing and handling of attributes (i.e., some, if not most of extended Kermit will be implemented). We knew that Columbia was going to work on it, but we have to have running code by August. We intend to submit it to the Kermit catalog of implementations when done. Hope that this is useful to you. Don Johnson dhj@rice (713)527-4020 EE Department Rice University Houston, TX 77251 [Ed. - What luck. More news about this will appear as it arrives.] ------------------------------ End of Info-Kermit Digest ************************* ------- 27-Jun-84 12:48:11-EDT,11663;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 27 Jun 84 12:47:24 EDT Date: Wed 27 Jun 84 12:46:29-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #11 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 27 June 1984 Volume 1 : Number 11 Today's Topics: New Release of DEC-20 Kermit New Release of PDP-11 Kermit Unix Kermit Fix Floating Windows & Graphical Views Kermit Supported by Crosstalk XVI Kermit for PCjr? IBM 3270 Protocol Emulators and Unix Kermit ---------------------------------------------------------------------- Date: Tue 26 Jun 84 18:32:29-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: New Release of DEC-20 Kermit To: Info-Kermit@CUCS20 A minor new release of DEC-20 Kermit is available, 4(224), incorporating several fixes and features suggested by Ken Harrenstien (KLH@SRI-NIC): The GET command allows source & destination filespecs to be given separately. Type GET ? to see how this works. Characters like ?!;@ can be included in the remote filespec in GET by prefixing them with CTRL-V (which is stripped before sending the name to the remote host). This is the normal TOPS-20 way of quoting funny characters in commands. Refuse links on file-transfer tty, not controlling tty! Restore advice and links to former state after file transfer. ------------------------------ Date: Tue 26 Jun 84 19:24:26-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: New Release of PDP-11 Kermit To: Info-Kermit@CUCS20 Announcing a new release of PDP-11 Kermit, 2.17, from Brian Nelson at the University of Toledo (ATSBDN@UOFT01.BITNET). This release cleans up some minor problems with the one distributed at DECUS in early June. Included are some performance improvements, some fixes for adapting to new releases of RSX-11/M and M+ (4.1 and 2.1, respectively), and improvements in the support for RT-11, particularly in terminal i/o. Also, the new release will run on the PDT-11 RT-11 system, whereas the previous release would not. The files (61 of them) are in KER:K11*.*. KER:K11INS.DOC describes the files, operating system requirements, etc. KER:K11CMD.MAC contains the edit history, which describes the changes in detail. ------------------------------ Date: 25 Jun 84 21:40 PDT From: mike@LOGICON.ARPA To: cc.fdc@COLUMBIA-20 Subject: UNIX KERMIT fix Howdy... Just wanted to confirm something you stated earlier in one of the KERMIT digests. This concerns a UNIX problem, which this site is having as well. It seems that when you are transmitting a file from an outside micro to the UNIX kermit, the micro never seems to get the word to stop. Although the file is transfered ok. You stated in a recent digest, that the fix was to put a sleep(1) call in before the terminal parameter change (UNIX call is stty()). This really works! I have installed your suggested correction with no apparent side effects, except the elimination of the micro sending problem. Thanks again... Mike Parker {alias mike@LOGICON.ARPA} [Ed. - Thank you. I've also been receiving lots of comments and code in response to "Call for Unix Kermits"; keep them coming!] ------------------------------ Date: 26 Jun 1984 14:13:30-MDT From: Leah F. Miller C-10 <lfm@lanl> To: cc.fdc@COLUMBIA-20 Subject: Floating Windows & Graphical Views Frank, Would you summarize the recent Info-Kermit debate on optimizing Kermit performance, for those of us who came in late? I've received several calls in the last few days from people who work on different projects but have the same question : could they use Kermit to send graphics output to other states and/or Canada? Do you know of anyone who is shipping graphics data, if only on a workstation-host basis? Leah Miller ------------------------------ Date: Wed 27 Jun 84 10:01:50-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Re: Floating Windows & Graphical Views To: lfm@LANL.ARPA Well... I think there is general agreement that Kermit should provide some performance options, like sliding windows (multiple unacknowledged packets) and longer packets, and perhaps ways for the two sides to agree to send certain control characters "bare". However, the exact mechanisms for doing these things have yet to be specified. In the meantime, Kermit can be used for sending any kind of data over any kind of link, though you may find yourself paying more in packet charges over public networks, and you may have to adjust packet length or timeout intervals when long delays are involved, like you have with satellite links. If your graphics files are vector encoded, then you won't see any particular savings from the repeat count compression, but bit maps might get compressed a lot. - Frank ------------------------------ Date: Tue Jun 26 1984 14:44:09 From: Marco Papa <papa%usc-cse.csnet@csnet-relay.arpa> To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: Kermit supported by Crosstalk XVI >From the latest issue of PC-WEEK: "Crosstalk XVI version 4.0, which will be shipped in August, will support the Kermit protocol. Crosstalk will contain hooks for Kermit, which users will be required to individually license from Columbia." Crosstalk XVI is a product of Microstuf. Congratulations you guys at Columbia. Marco [Ed. - We agreed to let Microstuf do this with our normal stipulations, namely that they don't raise the price just because they put Kermit in it, and they give credit to Columbia for the protocol. These stipulations are spelled out in greater detail in KER:COMMER.DOC.] ------------------------------ Date: 26 Jun 84 2322 PDT From: David Fuchs <DRF@SU-AI.ARPA> Subject: Kermit for PCjr? To: info-kermit@COLUMBIA-20.ARPA Are folks running Kermit on the PCjr with the IBM built-in modem? I haven't been able to get SEND or RECEIVE to work at all, and regular terminal emulation only works after some irreproducible set of "<control-N>F <digit>" commands are given. It can't be that the modem is flakey, because the communications program on the JR Sampler disk works fine talking to the same target TOPS-20 system. I must be missing something. Does anyone have a definitive set of magic incantations that make things work? Is there some Kermit command that must be given (other than SET BAUD 300) before CONNECTing? Is there some "latest version" of Kermit that must be used? Are all users this clueless? My only excuse is that COLUMBIA-20 has been closing all FTP connections before it manages to send a complete copy of any documentation file... [Ed. - IBM PC Kermit 1.20 works just fine on the PCjr serial port, except that the screen display during file transfer looks strange on a 40-column screen. However, Kermit doesn't work at all on the modem port. Internal modems are poison. We'll try to get it workin on the modem port as time permits (many things are higher on our list), meanwhile, contributions will be gratefully accepted. I don't know why FTP should be having trouble, except that COLUMBIA-20 is field testing a new version of TOPS-20.] ------------------------------ Date: Tue, 26 Jun 84 12:34 PDT From: "Chase Lila"@LLL-MFE.ARPA Subject: ibm3270 Protocol Emulators and Unix Kermit To: Info-Kermit@COLUMBIA-20.arpa Has anyone had any experience getting the CMS Kermit to work through this protocol emulator? ------------------------------ Date: Wed 27 Jun 84 11:02:17-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Re: ibm3270 Protocol Emulators and Unix Kermit To: Info-Kermit@COLUMBIA-20.ARPA A protocol emulator is a device that allows ordinary ASCII terminals or PCs that emulate them to be connected to IBM systems that only know how to drive 3270 series EBCDIC terminals, which are normally connected via coaxial cable to a 3274 cluster controller, which is either locally or remotely connected to an IBM channel. The 3270 is the only kind of terminal that VM/CMS really understands; it is a full-screen block-mode terminal with lots of function keys. Protocol converters are popular at sites that have a mixture of IBM and non-IBM timesharing systems. They allow the same terminal to be used with both kinds of systems. They interpret the host's 3270 screen formatting commands into appropriate escape codes for various ASCII terminals, do EBCDIC/ASCII data conversion, and translate the terminal's function key output or other keystroke sequences into 3270 function key signals. A wide variety of protocol emulators is available on the market. They may be cards you plug into your PC (like the Irma board), little boxes on your desk, bigger boxes (like the Datastream) near your mainframe or terminal switch, minicomputers like the IBM Series-1 based Yale IUP, or IBM host resident software like SIM3270. Their operation can vary from straightforward translation and interpretation to highly optimized screen management, in which only those characters on the screen that need to be changed actually are changed. Kermit works on the assumption that data -- at least printable 7-bit ASCII characters -- will be received exactly as they are sent. Protocol converters violate this assumption by doing EBCDIC/ASCII conversion on the data, inserting escape sequences, and possibly reformatting it. Therefore, Kermit (in its present form) cannot operate through a protocol converter. For now, there are several other options. If you have an Irma board, you don't need Kermit, because you get software with the Irma board to do file transfer. Same for the Yale IUP. The same may be true of some other protocol emulators. One of our projects this summer will be CMS Kermit. In addition to bringing it up to a more advanced level, providing server functions, etc, we will be looking at this problem. It won't be easy, because the changes have to be made not only in CMS Kermit (and ultimately also MVS/TSO Kermit, whenever that appears), but also in any PC Kermit that wants to talk to it. The PC, rather than dealing with sequential streams of ASCII characters clearly delimited into packets, will be receiving perhaps randomly ordered screen formatting commands. A possible approach would be to have CMS Kermit send a clear-screen command to signal the beginning of a packet, send the contents of the packet as line 1 (with awareness that the protocol emulator might "optimize" it by converting spaces to tabs or cursor positioning commands), and signal that the packet is finished by putting something on line 2. Meanwhile, the PC builds its screen interally, interpreting any escape codes (which it presumably already knows how to do because of the VT52 or H19 emulation code in most PC versions of Kermit), and then goes back to read the result as a packet when it gets the completion signal. Well... we'll try doing something like this with the CMS and MS-DOS Kermits. Who knows, maybe it'll work. If it does, then there's the task of getting the same functionality into all the other Kermit implementations. Comments or suggestions about this would be most appreciated. ------------------------------ End of Info-Kermit Digest ************************* ------- 3-Jul-84 09:56:45-EDT,4107;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 3 Jul 84 09:56:21 EDT Date: Tue 3 Jul 84 09:55:30-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #12 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Tuesday, 3 July 1984 Volume 1 : Number 12 Today's Topics: MVS/TSO Kermit Coming BYTE Article Available On Line Kermit for the Morrow MD-11? Bug in Kermit-20? Wang PC Kermit? ---------------------------------------------------------------------- Date: Thu 28 Jun 84 22:09:47-CDT From: RON RUSNAK <Systems.Ron@UChicago.Mailnet> Subject: TSO-KERMIT To: Info-kermit@COLUMBIA-20.ARPA I am currently putting the finishing touches on a TSO-KERMIT which is based on the CMS version. Where would you like me to send it? We have a BITNET connection here, if that helps. I should be ready to ship it out next week. Ron Rusnak SYSRONR@UCHIVM1.BITNET SYSTEMS.RON@UCHICAGO.MAILNET [Ed. - It will be announced as soon as it shows up.] ------------------------------ Date: Fri 29 Jun 84 20:24:10-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: BYTE Article Available On Line To: Info-Kermit@CUCS20 The July issue of BYTE Magazine is published, so now I'm allowed to make the text of the article (at least as it was when we submitted it) available on line. It's in KER:BYTE.*. BYTE.DOC is readable at the terminal, BYTE.MSS is Scribe source, which can be run through Scribe to produce output for a variety of devices, including multifont laser printers. - Frank ------------------------------ Date: Wed, 27 Jun 84 18:28 GMT From: JONES%LLL@LLL-MFE.ARPA Subject: Kermit for the Morrow MD-11 To: info-kermit@COLUMBIA-20.ARPA Has anyone brought up a version of Kermit on the Morrow MD-11? The generic CP/M 3 version did not seem to work when I tried it out. The MD-11 runs CP/M 3.0 and is very different as far as communications from the MD-1,MD-2, and MD-3. Thanks, Dan Jones ------------------------------ Date: Sat 30 Jun 84 17:51:33-PDT From: Jim Lewinson <Jiml@Score> Subject: Bug in Kermit-20? To: cc.FDC@COLUMBIA-20.ARPA I have noticed the following behaviour wich I don't think is quite correct. 1) Start up your favorite version of Kermit-20. 2) Tell it to go into server mode. 3) Type "^A# N3" at it. This looks to me like a NAK for packet 0, with a length of 3. This is the same packet that many Kermits throw at me when they start up, so I think the checksum is correct. Kermit-20 produces a big ugly error about "un-implmented server command". Surely this is not correct. It should simply NAK back at me if it doesn't make sense. I don't know if this is related, but I have gotten a similar error when I have disconnected (briefly) the rs232 link to the modem when Kermit-11 and Kermit-20 were talking back and forth. needless to say, the transfer failed. (I was playing to see if it could handle lost packets.) Jim ARPA: Jiml@Score [Ed. - Good point. You're right, it should ignore NAKs when in server command wait. I'll fix it in Kermit-20 next time around.] ------------------------------ Subject: WANG Kermit From: ABN.20E-548@USC-ISID.ARPA To: info-kermit@COLUMBIA-20.ARPA Message-ID: <[USC-ISID.ARPA] 3-Jul-84 09:30:50.ABN.20E-548> Has anyone seen or heard of Kermit to run on the Wang PC under MS-dos? I have tried to modify the IBM-PC version but cant get it to work. Too many diferencies in things like port addresses and screen escape sequences. Walt [Ed. - Kermit for the Wang PC with MS-DOS is on the way. You're right, the port and screen stuff is very mysterious.] ------------------------------ End of Info-Kermit Digest ************************* ------- 9-Jul-84 12:39:25-EDT,19350;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 9 Jul 84 12:38:42 EDT Date: Mon 9 Jul 84 12:00:28-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #13 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 9 July 1984 Volume 1 : Number 12 Today's Topics: RSX-11 Kermit Terminal Emulator Problem Bad Kermit-11 Files K11ASM.M41, K11*.XRF Fixed Kermit-11 & RT11 Kermit File Servers Kermit for HP-1000? What is the Kermit Protocol Named After? [Little] CP/M-86 Kermit Progress Report Kermit-Based Network at Rice Conversion of CROSS Apple Output from Hex to Binary Problem Installing DECsystem-10 Kermit Apollo Kermit ---------------------------------------------------------------------- Date: Tue, 3 Jul 84 16:31 GMT From: HAMMON%LLL@LLL-MFE.ARPA Subject: k11rsx term emulator problem. To: info-kermit@COLUMBIA-20.ARPA I just installed the new kermit-11 on my 11/23 (128kw rsx11m v4.1B) and have experienced some peculiar problems with the terminal emulator. Terminals are driven with an MBD 8-line DZ11. This behavior occurs when trying to talk to our dec-20 or just looping back(plugging in the output into another line on the distribution panel). When typing in characters, what's on the screen is always one character behind what I'm typing. To end a line it frequently takes either an extra cr or something like an xon. When receiving characters, It stops after 4 or 5 characters and I must keep hitting xon to get more groups of 4 or 5 characters. Occasionally I lose characters when receiving. I've had no problem with transferring files either way. Maybe the problem is related to the way a dz buffers characters. Any suggestions would appreciated. thanks, -randy- - hammon%lll@lll-mfe.arpa- ------------------------------ DATE: TUES, 05 JUL 84 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: RSX TERMINAL EMULATION Don't know about being one character behind for RSX on his 11/23. I have never seen that happen, and can't really think of why it would do that. I will try some tests and see if I can come up with anything. ------------------------------ DATE: FRI, 07 JUL 1984 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: KERMIT-11 AND RT11 hate to do this to you, but I found the reasons for my flakey problems in the rt11 file create and open code. I had the agr list for a macro called .DSTAT (it looks to see if a driver is resident) swapped. This would sometimes succeed (based on garbage on the stack) and proceed to overwrite the rt11 parsed filename and device block for the open. I can send something next week to fix your stuff. Sorry about that, but perhaps you can see why I took so long to do the RT11 conversion. I/O under RT is a royal pain. brian nelson [Ed. - Will announce new stuff when it arrives.] ------------------------------ Date: Thu, 5 Jul 84 09:07 PDT From: "Hammon Randy"@LLL-MFE.ARPA Subject: munged kermit file To: info-kermit@cucs20.arpa I just discovered that the copy of k11asm.m41 is munged. -randy- hammon%lll@lll-mfe.arpa ------------------------------ Date: Thu 5 Jul 84 18:30:46-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Re: munged kermit file To: "Hammon Randy"@LLL-MFE.ARPA Thanks for pointing it out, there's a fixed one now. Also the two K11*.XRF files were bad and have been replaced. - Frank ------------------------------ Date: Mon 2 Jul 84 14:46:19-PDT From: Bruce Tanner <CERRITOS@USC-ECL.ARPA> Subject: Kermit File Servers To: cc.fdc@COLUMBIA-20.ARPA Frank I read the second part of the BYTE article this weekend - good work. I was pleased to see the college acknowledged at the end. The article also touched on a subject I have been thinking about the last few weeks, Kermit file servers. The goal of micro-mainframe communications is transparency; the user (or even the user's program) doesn't know that the information is not at the micro, but at the mainframe. It seems that a Kermit server on the mainframe is 90% of what is needed to service requests for data, although the protocol would need to know about logical sectors or even records of a file. The micro side of the problem is tricky, you could either have a general purpose subroutine to put into all your programs (practical for very few applications) or modify the operating system. Luckily, MS-DOS has device drivers that can be installed. If I can have a driver that makes MS-DOS thing a chunk of memory is a virtual disk, I would think that a Kermit driver could make requests to another virtual disk ship requests for logical sectors to the server. I seem to recall that the Macintosh has hooks in it for a 'smart' file server. Perhaps the same type of thing could be done there. I'm not sure this is a Kermit topic or not, since applications based on the Kermit protocol (e.g. SMTP servers) were frowned upon as topics for discussion. This is just a bit of 'blue sky' to see what you think. [Ed. - You're right, it's sort of beyond what most people like think Kermit is for. But it sounds a lot like a project we're working on as an outgrowth of Kermit. It also sounds a bit like a project at Rice University -- see below.] Different topic: KERMIT - KL Error free Reciprocal Micro computer Interface over Terminal lines (or something like that) Initial Kermit release Kermit - Celtic for 'free' Various Kermit sources Kermit is not an acronym, it was named after Kermit the frog. BYTE What gives? -Bruce [Ed. - See below.] ------------------------------ Date: 3 Jul 1984 1442-GMT From: CAROFF at Ames-VMSB Subject: Kermit To: cc.fdc at columbia-20 Is there a software tools available for the hp1000 that you have heard of? I have not unfortunately. But I will look into that version. [Ed. - The Software Tools version of Kermit contributed by Ken Poulton runs on the HP3000. Ken says it should also run on the HP1000. In both cases, you need the stuff from the Software Tools tape for your system. Call the Software Tools User Group at 213-647-0272 for further information about getting the "tools" for the HP1000, or write to Software Tools User Group 1259 El Eamino Real #242 Menlo Park, California 94025 ] By the way, I just finished reading your kermit article and noticed that kermit is NOT an acronym. What the hell did you name it after a frog, I just do not quite get it?? There must have been a reason! Thanks much, Mike [Ed. - What do you have against frogs? In fact, we called the protocol Kermit in honor of Kermit the Frog. However, once we started exporting Kermit programs, we became a little bit worried about getting in trouble with the name, so we thought we'd better make it an acronym. The "KL10 Error-free..." etc was the best we could come up with, but it was pretty lame. Later, Bill Catchings, while looking through name books for his new baby (who is not named Kermit) noticed that the name Kermit comes from the Celtic word for "free". We liked that a lot better than the acronym. Then when we went to publish the article in BYTE, the editors suggested we contact the Muppet people to settle the matter. It turns out that "Kermit" is a registered trade mark of Henson Associates Inc, and no product may be called "Kermit" without their blessing. Well, fortunately, "our" Kermit is not a commercial product since we don't sell it for profit, and Henson Associates Inc kindly granted us permission to use the name, provided we acknowledge them in our publications, as we have begun to do. It's not easy being green...] ------------------------------ Date: Fri, 6 Jul 84 09:37:51 CDT From: Don Johnson <dhj@rice.ARPA> To: CC.FDC@COLUMBIA-20.ARPA, ... Subject: kermit-based network at Rice To the Kermit world: We at Rice are writing a Kermit protocol package as part of a network we are developing. Thought I would describe what we are doing. We are bringing up a campus-accessible mail system and file storage facility. The presumption is that most user nodes on the network are personal computers which are not multiprocess machines. Consequently, they cannot be assumed to be at a physical location at any one time, cannot accept mail which arrives at a random instant of time, and the user could be anybody. A good model for our system is that of a post office. To send/receive mail and packages, the PC user must explicitly go (connect) to the post office to access mail services. Our post office is an IBM 4341 and the communications medium is a CBX (made by ROLM). Thus, we communicate with RS-232, with a defined datarate of (hopefully) 9600 baud. We assume (and have to because of the IBM) that the datapath is only seven bits wide. As we want to send Mac files (both resource and data), we needed a protocol that would support 8-bit transfers in this environment. In an attempt not to reinvent the wheel, we settled on Kermit as our 'data-link layer' protocol and are writing same for the Mac, the IBM PC, and the 4341 as well as one for MVS. We do NOT support time sharing services on this net, so we do not do anything in regards to what could be termed 'terminal emulation' other than for a dumb tty. 'Mail' for us is straight ASCII that can be read on any PC regardless of what it may be. 'Packages' can be most anything, including operating system specific (like applications). The system will prepend a header to each packages explaining its contents. We know what goes in this 'content' field, but no specific format has been laid out. Thus, we are not writing what most of the world refers to as a 'Kermit'. Rather, we are writing the protocol portion of it as a module which looks like a device driver (open, read, write, etc.). The 4341 side is a server Kermit. We are supposed to have the net up (walking, maybe crawling) by August 17. We will probably make that deadline. If any of you want this stuff, you are welcome to it when completed. By the way, the MacKermit is being written in Pascal under the Workshop environment on the Lisa. Don Johnson dhj@rice [Ed. - Sounds a lot like the project we're working on, except with a VAX at the center and DEC PCs (Rainbows with MS-DOS and Pro-350s with Venix), with Macs to be added later. We too have a deadline...] ------------------------------ Date: Fri, 6 Jul 84 10:27 EDT From: "John C. Klensin" <Klensin@MIT-MULTICS.ARPA> Subject: [little] CP/M-86 Kermit Progress Report To: Frank da Cruz <cc.fdc@COLUMBIA-20.ARPA> Sorry for the long delay in getting back to you on my CP/M-86 Kermit struggles. I have been working on it on and off, with repeated interruptions to get a new multinational research project in place (the joys of soft money). In any event, the state of things at the moment is as follows: Overall changes required and made: - A few lines of conditional assembly code have been placed into module 'kermit.a86' to identify the version for Concurrent differently and to (for Concurrent) narrow down the displays so that they fit in in a reasonable window. Also added support for a new SET command to set the width of a tab. I hope this is acceptable, I needed it because Multics (along with some UNIX implementations, so this is not completely site-specific) is a "tab every 10" machine, rather than the DEC and imitators "tab every 8". The SHOW piece is in KERMIT (since the width is always determinable), SET is in kerio so that people don't need to support it where it does not make sense (e.g., rainbow). - modifications to "kertrm" for tab widths, mostly a few variables that seemed logically to belong there. - everything else is in KERIO, including SET TAB-WIDTH for the PC. Versions of KERIO I seem to have spread out here: - IBMPC, CP/M-86, semi-generic: seems to work, using character-at-a-time retrievals, rather than an interrupt-driven ring buffer. Seems to mostly work, as long as the speeds are moderate (<=1200 Baud), and then not well at 1200. This is all as one might expect. I did it in frustration at the next one in order to have something to work with/from. -- IBMPC, CP/M-86, interrupt driven: code has been assembled, tested, and extensively desk-checked. I am now on a hunt for something that will explain in a way that my weak mind (which has not tried to write assembly language in anger for maybe 16 years but which was writing channel programs and real time interrupt handlers for years before that) can understand what the relationship is between programming for the 8250 and for the 8259 and what it is that I am saying to, and expecting from, the latter. I have managed to figure out what seems like it ought to be enough from studying the code in PCDOS pckermit, and from the Tech Ref, and bits from the several "IBMPC esoterica" books I have around here, but the books stop before that and that part of pckermit is probably clear only when people know what it is doing. Anyway, the thing loads successfully, initializes the ports, and dies in a mode in which (jodging from the lights on the modem) successfully sends characters in terminal mode, but cannot manage to discover them when they come back and get them to the terminal emulator. It also leaves the PC in that state, even across warm boots (PCDOS kermit resets it correctly). -- Concurrent CP/M-86: now that I have a full set of documents (Digital Research has a new trick, they send you a manual with the OS that is strictly user-oriented and tell you in it that there is a programmers guide, which you need to order, pay extra for, and (more important) wait for. That one tells you about yet another manual which contains the esoterica that you then have to try to order. Of course, they have gone out of the retail business, and their retaillers have not heard of manual set 2, much less the esoterica book), it looks quite easy, given that all of the work is managed by the operating system, including buffering, parity (if wanted), and XON/XOFF processing. I have a version desk-coded, but have not tried to assemble it yet, for two reasons: (a) I have been too busy getting frustrated by the CP/M-86 version. (b) the size of their serial buffers, as delivered, is 16 characters. I don't fancy trying to run kermit with 16-char packets, and Concurrent runs only on fairly large machines (256K absolute minimum) anyway. So I have been trying to find out how to make the queue sizes larger. I was assured when I finally got a technical person at DRI that it was possible to do so, I am still trying to figure out how. If I can get the queue sizes up over 96, things should go very nicely. -- Since Barry Devlin seems to understand the Serius/Victor, and since the availability of technical documentation on it here is photocopies of engineering documents with handwritten notes in the margins, and since he seems (from kermit-info) to be about to take on the CP/M-86 version, I hereby will it back to him. The IBM is clearly more than I can handle right now without taking on another machine, especially as an uncompensated activity (MIT considers my fussing with this stuff an 'outside professional activity' which translates as hobby for which I can't bill salary). - I also have (trivial) SET TAB-WIDTH code for the rainbow and apc versions of KERIO to maintain compatability. john [Ed. - If any of the CP/M-86 Kermit contributors would care to comment on what John has done so far, feel free.] ------------------------------ Date: Mon 9 Jul 84 01:13:55-EDT From: Peter G. Trei <OC.TREI%CU20B@COLUMBIA-20.ARPA> Subject: CROSS hex -> binary conversion. To: info-kermit@CUCS20 I realise that there are only a limited number of people out there working on Apple DOS Kermit, but I would like to spread the use of a handy programming tool, which may be adaptable to use with other micros. When you compile a micro source code file using the CROSS compiler, the output is either one of a number of binary representations, or one of a number of hexadecimal representations. Frequently, the binary representation is nothing like that which your micro's kermit expects to upload. This is a problem with Apple kermit, and I have created a program, APPLEB.SAI, which converts one of the hexadecimal outputs of the CROSS compiler into an 8-bit file which can be directly uploaded to an Apple using kermit, and run. This is a considerable aid not only to developers, but also to people wishing to upload updates. Directly uploading the binary form is at least twice as fast as uploading, then converting, a hexadecimal representation. APPLEB.SAI is written in the SAIL language, which may not be available at all sites. However, the source is heavily commented, and it should be easily adaptable to PASCAL. It should also be fairly trivial to cause it to output a number of different binary formats appropriate for different micros. Peter Trei oc.trei%cu20b@columbia-20 [Ed. - The program is in KER:APPLEB.SAI.] ------------------------------ [Ed. - I lost the original message, but it was from someone who complained of having trouble building DECsystem-10 Kermit because of a missing file, B361LB.REL...] Date: Fri 6 Jul 84 22:24:03-EDT From: Nick Bush <OC.BUSH@CU20B> Subject: Re: [LCG.KERMIT: TOPS-10 KERMIT] To: EIBEN@DEC-MARLBORO.ARPA B361LB.REL is distributed along with RMS-10 on the Digital supported CUSP tape. - Nick ------------------------------ Date: Thu, 28 Jun 84 17:05 CDT From: Tom Linnerooth <Linnerooth@SANDIA.ARPA> Subject: Re: Apollo KERMIT To: Cargo@HI-MULTICS.ARPA Frank slightly misinterpreted my intent. I am not actively working on KERMIT for the Apollo. We simply don't have the manpower at the present time to work on that problem. If it were available, however, I would probably install it. The Apollo's we have were purchased from Mentor with CAD software. Mentor provided a simple protocol written in Pascal that handles file transfers to and from the Apollo over a TTY line. It checks the transfer by a simple checksum. We were able to adapt their program to our needs in just a couple of days, and we are reliably transferring quite large files now. That satisfied our immediate need. I have not heard of anybody else who is interested in an Apollo implementation of KERMIT, but I think it's a matter of time since Apollo rings are becoming quite popular. There is an Apollo mailing list on the net, and a message broadcast there might bring some help. I didn't try that. Good luck, and I would be interested in what you find out. Tom ------------------------------ End of Info-Kermit Digest ************************* ------- 12-Jul-84 10:31:24-EDT,14576;000000000000 Return-Path: <CC.FDC@COLUMBIA-20.ARPA> Received: from CUCS20 by CU20B with DECnet; 12 Jul 84 10:30:40 EDT Date: Thu 12 Jul 84 10:29:02-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #14 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Thursday, 12 July 1984 Volume 1 : Number 14 Today's Topics: Incorrect Issue Number on Last Digest Kermit on a DG MV/x0000 running AOS/VS? Bug in Kermit-10, VMS Kermit, and Pro/Kermit Re: RSX-11 Kermit Terminal Emulator Problem RSX TT EMULATOR AT&T PC Kermit Problems Kermit, DCA and the DDN Kermit Boot Program Kermit for MVS/TSO Kermit-11 Problem Between RSTS/E Systems Software Tools for HP-1000 ---------------------------------------------------------------------- Date: Thu 12 Jul 84 09:32:56-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20> Subject: Incorrect Issue Number on Last Digest To: Info-Kermit Sorry, the last issue was number 13, not number 12. Thanks to all of you who pointed out the mistake. - Frank ------------------------------ Date: Mon 9 Jul 84 09:32:56-PDT From: Michael A. Haberler <HABERLER@SU-SIERRA.ARPA> Subject: Kermit on a DG MV/x0000 running AOS/VS To: info-kermit-request@COLUMBIA-20.ARPA I am interested in bringing up Kermit on a DG MV series machine running AOS/VS. Has anybody out there done that before? - mike [Ed. - Kermit is available for DG machines running AOS, but first you must have the Software Tools Package. For futher information about the Software Tools package, contact: Software Tools User Group 1259 El Camino Real #242 Menlo Park, CA 94025 213-647-0272 The AOS implementation of Kermit is available in KER:AOS*.*. There's also a newer, more advanced Software Tools Kermit implementation which has been done for the HP3000 and Univac 1100 -- it would be desirable to adapt any system- dependent parts from the AOS-specific version to the newer version and use that. Anyone who does this is encouraged to contribute it to the Kermit collection so we can discard the older program. The newer one is in KER:ST*.*.] ------------------------------ Date: Mon 9 Jul 84 13:35:40-EDT From: Nick Bush <OC.BUSH%CU20B@COLUMBIA-20.ARPA> Subject: Bug in Kermit-10, VMS Kermit, and Pro/Kermit To: INFO-KERMIT@CUCS20 There is a minor bug in these three Kermits (the joys of a common source). The problem will only show up when sending files to a Kermit which has requested 94 character messages with an even valued ASCII character as the end of line character (like line feed = 12octal). One Kermit implementation which requests this set of parameters is LCTERM. The problem is easily avoided by using the SET SEND PACKET-LENGTH command (PACKET_LENGTH in VMS Kermit) to set the maximum packet size to something less than 94 characters. This will be fixed in the next versions of these Kermits. - Nick ------------------------------ Date: 9 Jul 84 17:54:09 EDT From: Glenn J. Joyce <GJ0F@CMCCTE> To: Info-Kermit@CUCS20 Subject: Re: RSX-11 Kermit Terminal Emulator Problem I've seen the same behavior that he is talking about and the solution to the problem (at least in my case) was pretty simple. If you have a full duplex terminal driver and have your lines set to half duplex, you will get the results that he reports. If you set the line that you will connect over to full duplex (via the MCR command SET /FDX=TTnn:) and set the line to which your terminal is connected to full duplex, the terminal emulator will work just fine. If either of those lines are in half duplex mode, the terminal emulator appears to work, but is always a few characters behind. You can clear the pending typein/typeout with a few CR's or XON's. (You can see the line characteristics if you do a DEV TTnn: to the > prompt) - Glenn Joyce ------------------------------ DATE: TUES, 10 JUL 1984 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: RSX TT EMULATOR Sounds reasonable (?). This may have been caused by an edit accidently removing the sf.smc for fdx on the connected line in k11con.mac, which will be there when the next tape goes out tomorrow. [Ed. - New Kermit-11 will be announced as soon as it arrives. See below for another problem with this program when it's running under RSTS/E.] ------------------------------ Date: Tue 10 Jul 84 07:22:01-PDT From: Ted Markowitz <G.TJM@SU-SCORE.ARPA> Subject: AT&T PC problems To: Info-Kermit@COLUMBIA-20.ARPA I'v just received a model of the new AT&T PC and tried it with the standard IBM PC version of KERMIT since it claims to be 'compatible'. Well, no such luck. After a few lines of output in terminal emulation mode it garbles the text something fierce. It is 8086 based and does have a faster clocking (8Megahertz). Any ideas to get this to work? Another version of KERMIT perhaps? --ted [Ed. - The forthcoming release of MD-DOS Kermit will have a small module in which the system-dependent primitives are defined. We will have such modules for the IBM PC & XT, DEC Rainbow, HP-150, Wang PC, and "generic" MS-DOS. You can start with the generic MS-DOS Kermit; it may work as is, or you may have to twiddle an address or two. However, since it goes through DOS for all services, it will be slow. If it's too slow for you, then you can write system-dependent primitives for your new AT&T system. The new release will be available Real Soon Now.] ------------------------------ Date: 10 Jul 1984 09:29-PDT Subject: KERMIT, DCA and the DDN From: Geoffrey C. Mulligan (AFDSC, The Pentagon) <GEOFFM@SRI-CSL> To: Info-Kermit@COLUMBIA-20 While I was out at DCA I heard talk that they working to upgrade the C/30 TACs. This upgrade would be both hardware (ie a new C/50) and software (ie user friendly). Along with the software upgrade they are considering implementing some protocols in the TAC for PC <-> DDN file transfers (recognizing that character-at-a-time is very wasteful of DDN resources). On the top of the list of protocols is KERMIT! I am not sure (nor are they) exactly how it will all work, but the initial idea is that the TAC would receive the whole file and then use FTP to pass it on to the host. Does anyone have any comments or ideas? DCA also has quite a number of IBM-PCs with integral Hayes 1200B modems. Is there a version of KERMIT that will drive the modem. Even if it does not dial (another program could do that), it has to be modified to use the Hayes modem as opposed to the serial port... help?!?!? geoff [Ed. - Most Kermit programs, including MS-DOS Kermit, do not contain explicit code for modem control. We have always advised Kermit users to steer clear of internal modems.] ------------------------------ Date: Tue 10 Jul 84 23:51:27-PDT From: Jim Lewinson <x.Jiml@[36.40.0.209]> Subject: Kermit Boot Program To: cc.FDC@COLUMBIA-20.ARPA KerBoo is a small Fortran program that implements the Kermit Protocol to allow you to receive files. The idea is that you already have both a Kermit on one machine and a somewhat featureful Kermit in "HEX" format for the other. The purpose behind the program is to allow you to send the HEX file to the machine with nothing with some sort of error detection and recovery (By using the Kermit on the machine you have one running on.) This program is VERY dumb. It has no timeouts, no 2 or 3 character checksums, no eighth bit quoting, and no protection. It doesn't even try to turn off echoing. In fact, I could spend all day telling you the things it does not do. It does do one thing, it lets you send using Kermit to a machine that doesn't have anything. I have tried it under VMS, and Versions 3.2 and 4.0 of RSX-11M, and it seems to work. If it doesn't, it will most likely be obvious why it is failing. ("Hmmm - This Fortran Doesn't allow file names in opens.") I have tried to write very generic Fortran. Happy Kermiting, Jim Lewinson Breuer & Company Bedford, Massachusetts [Ed. - The files (3 short ones) are in KER:KERBOO*.*.] ------------------------------ Date: 9 July 1984, 13:18:27 CST From: SYSRONR at UCHIVM1 To: DFTCU at CUVMA Subject: Kermit for MVS/TSO I have completed a version of Kermit for MVS/TSO. I have been able to test it out in our environment, but I have not tested it on a raw TCAM. In our environment we are using a mod to the 3705 to make everything look like a 2741. This means that everything is translated from ASCII to 2741 code to EBCDIC before it reaches KERMIT. It also supplies XON codes when the host has put up a read. It is my belief that normal TCAM will handle ASCII to EBCDIC translation just fine, and I believe that TCAM will also supply XON codes when it has a read up. However, I have been unable to gen a TCAM here with raw Teletype 33-35 support to test it out. If you wish I will sendfile you the the following pieces. IBMKERM ASSEMBLE IBMDYNA ASSEMBLE IBMKERM DOC I would like to put in a word for adding support to all of the micro KERMITs for the SET START-OF-HEADER command. In our MVS/TSO environment the host cannot receive a CNTRL-A. We have therefore added the SET START-OF-HEADER command to the IBM-PC version and to the APPLE II version. Ron Rusnak [Ed. - Chicago's MVS/TSO Kermit will be announced as soon as it arrives. The forthcoming release of MS-DOS Kermit will have commands to changes the packet-start character.] ------------------------------ DATE: WED, 11 JUL 84 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: KERMIT-11 PROBLEM BETWEEN RSTS/E SYSTEMS May as well send the following note out on info-kermit. A problem has been found with sending binary files on RSTS/E with attributes when the file sent never had any on the sender's system. It's unusual and should not normally cause a problem. ; update to the last procedure in K11ATR.MAC .sbttl finish up the update of rms file attributes to output ; A T R F I N ; ; If the file was send in image mode, and we have been sent ; valid attributes (basically, the sender's IFAB), then call ; PUTATR to place these attributes into our output file's ; IFAB so they will get updated. ; ; ; Note: 11-Jul-84 17:12:49 BDN, edit /19/ ; ; Note that for RSTS/E, we have an unusual problem in that if ; the sender sent a stream ascii file (most likely a file with ; NO attributes) over and the sender said it's binary, then ; RMS-11 sends GARBAGE for the VFC header size. When this data ; is wriiten into the output file's IFAB, RMS11 finds invalid ; data in the IFAB and writes attributes to disk with the last ; block field (F$HEOF and F$LEOF) equal to ZERO. Such a file ; would thus be unreadable to PIP, RMS and other programs that ; look at the file attributes. The fix is one of two things. ; One, we can clear the invalid VFC size and fudge the record ; size and maximum record size to something usable (like 512), ; or we can simply ignore the senders attributes and let the ; file stand as a FIXED, NO CC, recordsize 512 file. Rather ; than to try to fix the attributes, we will simple ignore the ; attributes if the sender said that the file is stream ascii ; with a garbage VFC. Since the attributes are only used if ; the transfer was in image moed, this will not affect normal ; files, only files like DMS-500 files that have no attributes ; but must be sent in image mode. ; Of course, the sending Kermit-11 can always be given the SET ; ATT OFF and SET FIL BIN and the receiving Kermit-11 be given ; the SET FIL BIN and the issue will never arise. ; ; The mods are noted with /19/ after the statement. atrfin::save <r1,r2,r3> ; just in case please tst @r5 ; lun zero ? beq 100$ ; yep tst at$val ; valid attributes to write ? beq 100$ ; no cmpb at$typ ,#binary ; did we get this as a binary file? bne 100$ ; no mov #at$fab ,r1 ; yes tst (r1)+ ; valid data present ? beq 100$ ; no cmp @r1 ,#2000 ; /19/ stream ascii ? bne 30$ ; /19/ no cmp 16(r1) ,#177400 ; /19/ garbage for the vfc header size? beq 90$ ; /19/ yes, forget about the attributes 30$: calls putatr ,<@r5,r1> ; /19/ update the ifab for the file 90$: clr at$typ ; /19/ no longer valid please clr at$fab ; no longer valid please clr at$val ; no longer valid please 100$: unsave <r3,r2,r1> ; output file and exit return 200$: .byte 40,0 .end [Ed. - This fix will not be in the next release (the situation where it occurs rarely comes up), but in the one after that. Until then, anyone who is effected by the problem can install the fix themselves.] ------------------------------ Date: 11 Jul 84 10:16 +0200 From: W._Michael_Terenyi_%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Frank da Cruz" <CC.FDC@COLUMBIA-20.ARPA> Subject: Software Tools for HP-1000 I have found out in the meantime that there are two implementations of the Software Tools Package on a HP1000, but I had not the time to contact the implementors yet. Larry Dwyer (408) 257-7000 x 2095 John Campbell (213) 831-3938 I try to receive the Software Tools Package for the HP1000 as fast as possible. Then I will take a closer look at the HP3000 Kermit. Regards, Michael [Ed. - This is in regards to running the Software Tools implementation of Kermit on the HP-1000.] ------------------------------ End of Info-Kermit Digest ************************* ------- 16-Jul-84 12:12:02-EDT,21753;000000000000 Return-Path: <CC.FDC@CUCS20> Received: from CUCS20 by CU20B with DECnet; 16 Jul 84 12:10:19 EDT Date: Mon 16 Jul 84 11:53:26-EDT From: Frank da Cruz <CC.FDC%CUCS20@COLUMBIA-20.ARPA> Subject: Info-Kermit Digest V1 #15 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 16 July 1984 Volume 1 : Number 15 Today's Topics: New Kermit Available for HP-1000 New Kermit Available for Apollo Aegis Sirius Kermit(s) BREAK Indication Kermit for DEC Pro-350? Other Kermits - Sanyo, Toshiba, BBC 6502, ... Kermit-32 Problem Kermit and Modem Binary File Transfers Kermit with Knowledgeman Kermit's limit Problems with Kermit-10 RECEIVE Command ---------------------------------------------------------------------- Date: Fri 13 Jul 84 13:33:49-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: New Kermit Available for HP-1000 To: Info-Kermit@CUCS20 Announcing version 1.0 of Kermit for the HP-1000/RTE-6/VM system from John Lee of RCA Laboratories, written in Fortran, capable of remote (dialin) but not local (dialout) operation. The source file is in KER:HPMKERMIT.SRC (the HP name space in the distribution area is getting tight; "M" is Roman for 1000), the documentation is in KER:HPMKERMIT.DOC. ------------------------------ Date: Fri 13 Jul 84 13:34:26-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: New Kermit Available for Apollo Aegis To: Info-Kermit@CUCS20 Announcing version 1.0 of Kermit for the Apollo Aegis system from John Lee of RCA Laboratories, written in Fortran, capable of both remote (dialin) and local (dialout) operation. The source file is in KER:APOKERMIT.SRC, the documentation in KER:APOKERMIT.DOC. ------------------------------ Date: Sun Jul 8 1984 10:58:02 From: Marco Papa <papa%usc-cse.csnet@csnet-relay.arpa> To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: UNIX Kermit problem Now that we are using XTs connected to our Vaxes running Berkeley UNIX, we are experiencing the following problem. When transfering a file from the XT running Kermit-86 V. 1.20 to the VAX running UNIX Kermit at 9600 bauds the transfer is aborted after the first packet is sent. PC Kermit says that it is unable to receive an acknowledgement from the host. The PC screen looks like this: Number of Packets: 2 Failed Number of retries: 5 ?Unable to receive acknowledgement from the host Instead, if we make the transfer at low speed, say 300 bauds, everything is OK. Also we have no problems when transfering files in the other direction (from the VAX to the XT), no matter which speed we use. Has anyone experienced this before? It seems that this might be a problem similar to the one that requires to insert a sleep(1) at the end of the transfer code, so that the last acknowledgement is not lost. Marco Papa ARPA, CSNET: papa.usc-cse@csnet-relay UUCP: ..!randvax!uscvax!papa [Ed. - Anyone out there who can help? As far as I know, this combination has been working for many months.] ------------------------------ Date: Thu 12 Jul 84 14:26:43-EDT From: JUNGER@CWRU20 Subject: Internal Modems To: info-kermit@CUCS20 In the last Info-Kermit I noticed the following statement: [Ed. - Most Kermit programs, including MS-DOS Kermit, do not contain explicit code for modem control. We have always advised Kermit users to steer clear of internal modems.] Perhaps it would be well to point out to those who are running non-generic Kermit for CP/M-80 that they can use an internal modem if they modify Kermit to look for the ports used by the modem instead of the external serial port. At least this works for my North Star Horizon, for which I have two versions of Kermit, one for the external printer port and one for a Hayes Micro Modem 100 connected to the S-100 bus. Peter D. Junger CWRU Law School ------------------------------ Date: Thu, 12 Jul 84 14:28 EDT From: Wiedemann@RADC-MULTICS.ARPA Subject: Packet retransmissions. To: info-kermit@COLUMBIA-20.ARPA I have recently installed the MULTICS Kermit from MIT-MULTICS on our system (the MUKERMIT from COLUMBIA-20 had many bugs). I am talking to this with the PCKERMIT from COLUMBIA. Using either 1200 or 300 baud, my retransmission rate runs about 95%! What am I doing wrong? Are there any parameters on either end that affect retransmission? I assumed that this was primarily due to communications equipment or line quality. Any suggestions are welcomed. Wolf Wiedemann RADC-MULTICS [Ed. - I haven't heard that complaint before, but I don't have any experience with MULTICS machines. I assume other MULTICS Kermit users have had better experience, or else I would have heard! Anyway, the author of MULTICS Kermit, Paul Amaranth of the Oakland University in Michigan, just sent me a tape with a new release of the program. I'll announce it as soon as it's on line.] ------------------------------ From: decvax!mulga!nemeth.uacomsci@Berkeley Date: Thu, 12 Jul 84 13:14:00 EST To: info-kermit%columbia-20.arpa.mulga.UUCP@Berkeley Subject: Sirius Kermit(s) Hi, hope you got the hex file of the CP/M-86 Sirius version I sent a few days ago... it was quite a struggle getting it ON the damn thing, because its disc format is totally incompatible with everything! And to complicate things further, MS-DOS can't write CM/M-86 files (but it can read them). Anyway, having used the two (ie MS-DOS and CP/M-86) versions on the Sirius, we have decided to all but forget about the MS-DOS version; it is VERY slow (barely runs @1200, even loses chars in connect mode; highest speed it seems to run reliably is about 600 bps); and it has some bugs, apparently (gets very confused talking to a server). The CP/M-86 version does not seem to have any such problems -- it runs faster (tested at 4800 bps), does not need padding characters in connect mode, and seems to work fine with a server (although it produces a strange diagnostic, which is ignored, using wildcards). [Ed. - I've heard wildly conflicting reviews of Victor/Sirius Kermit, both the CP/M-86 and MS-DOS versions. Some say it performs flawlessly at 9600 baud; others say it doesn't work at all. I've also heard that the systems themselves vary a lot -- different i/o chips, different BIOSes, etc. Can anyone out there shed any light?] Subject: Break indication (new subject, not a comms problem): I believe this should be an ESSENTIAL facility for all Kermits to provide in connect mode; it has all sorts of uses. In our environment (via a port selector) it is the only means for the user to disconnect his line and select another host; the ability to send a break indication is really missed on the CP/M-80 versions! [Ed. - Obviously, I agree. Most of the KERMITs that come from Columbia have this. It's up to each person who installs support on a new microcomputer to include this functionality. The method varies from system to system -- system calls to send BREAK, direct serial i/o chip device manipulation, BREAK simulation by sending several nulls at 50 baud, etc.] Subject: Kermit for DEC Pro 350? What's happening about it? Has it been released yet? We have some users who would like to use it (we also have the DEC PFT, but that only talks to VAXes..) [Ed. - It's released. It was done by Stevens Institute of Technology, sharing common code with their VAX/VMS and DECsystem-10 versions. P/OS Kermit is available as KER:POS*.* in the Kermit distribution area, and it will be on the Spring DECUS VAX and RSX SIG tapes.] Subject: Other Kermits - Sanyo, Toshiba, BBC 6502, ... Work is progressing on a few other implementations: the Sanyo is almost there, should be done in about a week; a Toshiba version is being looked at; likewise for RSX-11 and RT-11 (appears to be non-trivial to install), and Cyber(NOS/BE); BBC 6502 still working on it; and 3 or 4 other local CP/M based micros. Keep up the good work! Will advise further when some of these are completed. Tom Nemeth ------------------------------ Date: Thu 12 Jul 84 17:46:22-PDT From: Lawrence L. Wu <WU@SU-SCORE.ARPA> Subject: Kermit-32 problem To: cc.fdc@COLUMBIA-20.ARPA I am writing on behalf of the system people at the Hoover Institution's VAX/VMS. A few weeks ago, I helped them acquire a copy of Kermit-32 (Version 3.0.051) for their VAX. Today, Kermit caused a system problem that caused them to disable Kermit until the problem can be fixed. It appears that some user was using Kermit in local mode and exited abnormally from the VAX, probably by hitting break or turning off their terminal. The problem that occurred was that Kermit didn't drop the dial-out modem and the remote computer effectively tried to login through the remote port, which had been dedicated to Kermit. This wrote login failure messages to the system disk every few seconds and, according to the system people, would have crashed the system if not caught in time. I have just pulled the protocol manual over from Columbia via Arpanet and will look through it with the system people at Hoover; this may help us solve our problems. However, I qualify only as a dumb user (and also have less than complete confidence in the abilities of the system people at Hoover.) Have other people have encountered similar problems, or can you (or others) offer suggestions? Any help would be greatly appreciated. Larry ------------------------------ Date: Fri 13 Jul 84 08:26:00-EDT From: Nick Bush <OC.BUSH%CU20B@COLUMBIA-20.ARPA> Subject: Re: Kermit-32 problem To: WU%SU-SCORE@COLUMBIA-20.ARPA If Kermit is really aborted abnormally, there is little it can do to hang up a modem. However, the problem can be avoided by setting the terminal line with the dial-out modem to enable automatic hangup. This is done by "SET TERM TTxn:/PERM/HANGUP". With the line set this way, it will hangup the phone whenever the terminal line is either released by a program or deallocated by user command (if it was allocated to a process). - Nick PS: It is actually possible to recover from the situation you described without reloading the system. I keep a command file around the simply attempts to allocate the terminal specified by its parameter and loops until it is sucessful. Since it takes some amount of time to create a process to run LOGINOUT to attempt the login, you can ususally grab the terminal fairly quickly (within one or two login attempts). ------------------------------ Date: Fri 13 Jul 84 09:32:04-PDT From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA> Subject: kermit and modem binary file xfers To: info-kermit@COLUMBIA-20.ARPA, info-ibmpc@USC-ISIB.ARPA One of our main requirements for micro to mainframe communication is to be able to archive programs on the large systems disks. This includes binary files that may be .COM, .EXE, .CMD and "squeezed" files. KERMIT for TOPS-20 only saves files as 7-bit ASCII, which loses the eigth bit. Under MS-DOS files can have a length that is not an even multiple of 128 bytes. MODEM loses because a file that is transferred up to the HOST and then back to the PC will be rounded up to the next even number of sectors. I know there are programs that will expand binary files to 7-bit files but I do not think that extra translation is a good solution. Comments? Ted. [Ed. - Au contraire... You can tell Kermit-20 to "SET FILE BYTESIZE 8" when receiving files and it will store them as you desire. If a file is stored with bytesize 8 on a DEC-20, Kermit-20 will automatically send it correctly. It even recognizes "ITS Binary" format. Read the manual. The most current documentation is in KER:20KERMIT.DOC.] ------------------------------ Date: 13 Jul 84 08:12:28 EDT From: J. Ray Scott <JS5A@CMCCTA> To: sy.fdc@CU20B Subject: Kermit with Knowledgeman Just a caution. If you are creating files with the Knowledgeman CONVERT verb KMan pads the output file out to even multiples of 128 bytes. It puts a ^Z in at the end of its data and then just junk after that. If you send this file with PC Kermit, Kermit will go ahead and send the junk since Kermit relies on the MS-DOS file size and not any data in the file. I think Kermit is right. This is just another in a very long list of problems with KMan. I would NOT recommend Kman to anyone. J. Ray Scott ------------------------------ Date: 13 Jul 84 21:23:19 EDT From: G.W. van Mook <GM04@CMCCTA> To: js5a@CMCCTA Subject: KERMIT'S limit I attempted to download the AP vendor file from TOPS-A to the XT, and like it did last time I did this, it died at KERMIT packet 32767. It seems that KERMIT's limit is around 2.8 megabytes per file transfer, unless something else is causing this. Good night...gvm [Ed. - Sounds like some 16-bit counter overflowed unexpectedly in PC/XT Kermit. We'll look into the problem.] ------------------------------ Date: Wed, 11 Jul 84 11:24:38 EDT From: Dave Swindell <dswindel@bbn-labs-b> Subject: Problems with KERMIT-10 Receive command?? To: info-kermit@columbia-20 Recently, I have had problems sending files from KERMIT-86 (version 1.20) on an IBM-PC to KERMIT-10 (latest version) on our TOPS-10 computer. I want to be able to rename the files as they are sent by using the RECEIVE <TOPS-10 file spec> on KERMIT-10 command and the SEND <file spec> command from KERMIT-86. When I do this, I get an error message from KERMIT-10 about illegal wildcard characters in file specification. The file specs I am using in KERMIT-10 contain no wildcard characters (*,%, or ?). What am I (or what is it!) doing wrong? Dave Swindell, @bbn-unix ------------------------------ Date: Fri 13 Jul 84 22:38:06-EDT From: Nick Bush <OC.BUSH%CU20B@COLUMBIA-20.ARPA> Subject: Problems with Kermit-10 receive command To: DSwindell@BBN-LABS-B.ARPA cc: info-kermit@COLUMBIA-20.ARPA The following patch corrects a problem with Kermit-10 v3(123) in the RECEIVE command. This makes RECEIVE file.ext work correctly. Previously if an extension was given, an error message was generated when the file was received. File 1) DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984 File 2) DSKB:KERMIT.MAC[10,52,KERMIT,10] created: 1753 11-Jul-1984 1)1 MITVER==2 ; Major version number 1) MITMIN==0 ; Minor version number 1) MITEDT==123 ; Edit level 1) MITWHO==0 ; Customer edit **** 2)1 MITVER==3 ; Major version number 2) MITMIN==0 ; Minor version number 2) MITEDT==126 ; Edit level 2) MITWHO==0 ; Customer edit ************** 1)3 | **** 2)3 Start of Version 3(124) 2) 126 By: Nick Bush On: 11-July-1984 2) RECEIVE FOO.BAR would not work correctly. 2) It thought the extension was 2) wild-carded. 2) 2) Modules: KERMIT 2) | ************** 1)28 > ; End of TOPS10 **** 2)28 ; Determine if we are logged in. 2) PJOB S1, ;[125] Get our job number 2) MOVNS S1 ;[125] Set up for JOBSTS 2) JOBSTS S1, ;[125] Get status for us 2) MOVX S1,JB.ULI ;[125] Old TOPS-10 maybe? 2) TXNN S1,JB.ULI ;[125] Logged in? 2) SETZ S1, ;[125] No, remember that 2) MOVEM S1,LOGDIN ;[125] flag file creation time 2) > ; End of TOPS10 ************** 1)29 $CALL I%EXIT ; And exit 1) TOPS10< **** 2)29 $CALL C$EXI0 ;[125] And exit 2) TOPS10< ************** 1)33 GETPPN S1, ; Get our logged in PPN **** 2)33 MOVX S1,<<SIXBIT |INI|>> ;[125] Try INI:KERMIT.INI first 2) MOVEM S1,INIFD+.FDSTR ;[125] for global defs 2) MOVEI S1,INIFD ;[125] Get the FD address 2) SETZ S2, ;[125] No log file FD 2) $CALL P$TAKE ;[125] Set up the take 2) JUMPF REDIN0 ;[125] If not there don't worry 2) MOVEM S1,INIIFN ;[125] Found file, save IFN 2) $CALL PARL.1 ;[125] Parse the file File 1) DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984 File 2) DSKB:KERMIT.MAC[10,52,KERMIT,10] created: 1753 11-Jul-1984 2) REDIN0: MOVX S1,<<SIXBIT |DSK|>> ;[125] Now we will use 2) MOVEM S1,INIFD+.FDSTR ;[125] DSK:KERMIT.INI[,] 2) GETPPN S1, ; Get our logged in PPN ************** 1)39 XMOVEI S1,MYTERM ; Point to the block 1) $CALL T$SBRK ; Set the PIM mode break set **** 2)39 XMOVEI S2,MYTERM ;[125] Point to the block 2) $CALL T$SBRK ; Set the PIM mode break set ************** 1)39 CAIN P1,"E" ; In escape sequence? **** 2)39 MOVE S2,S1 ;[125] Copy of the character 2) ANDI S2,177 ;[125] Keep only 7 bits 2) CAIN P1,"E" ; In escape sequence? ************** 1)39 CAME S1,ESCAPE ; Is this escape? 1) JRST CN.SND ; no, just send it **** 2)39 CAME S2,ESCAPE ; Is this escape? 2) JRST CN.SND ; no, just send it ************** 1)39 CN.ESC: CAIE S1,"C" ; Is is C 1) CAIN S1,"c" ; or lower case c? 1) JRST CN.END ; Yes done 1) MOVEI P1,"S" ; Assume not send control chr 1) CAMN S1,ESCAPE ; Another escape? 1) JRST CN.SND ; Yes, send a real one 1) CAIN S1,"?" ; want help? 1) JRST CN.HLP ; Yes, do it 1) CAIE S1,"S" ; Want status? 1) CAIN S1,"s" ; or lower case "s" 1) JRST CN.STS ; Yes 1) CAIE S1,"O" ; Clear buffers? 1) CAIN S1,"o" ; . . . 1) JRST CN.CLR ; Yes, go clear terminal buffers 1) CAIE S1,"Q" ; Quit logging? 1) CAIN S1,"q" ; . . . 1) JRST CN.QUT ; Quit logging 1) CAIE S1,"R" ; Resume logging 1) CAIN S1,"r" ; . . . 1) JRST CN.RSM ; Yes, do it 1) CAIE S1,"^" ; Want control chr? 1) JRST CN.ESE ; No, bad **** 2)39 CN.ESC: CAIE S2,"C" ; Is is C 2) CAIN S2,"c" ; or lower case c? 2) JRST CN.END ; Yes done 2) MOVEI P1,"S" ; Assume not send control chr 2) CAMN S2,ESCAPE ; Another escape? 2) JRST CN.SND ; Yes, send a real one 2) CAIN S2,"?" ; want help? 2) JRST CN.HLP ; Yes, do it 2) CAIE S2,"S" ; Want status? 2) CAIN S2,"s" ; or lower case "s" 2) JRST CN.STS ; Yes File 1) DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984 File 2) DSKB:KERMIT.MAC[10,52,KERMIT,10] created: 1753 11-Jul-1984 2) CAIE S2,"O" ; Clear buffers? 2) CAIN S2,"o" ; . . . 2) JRST CN.CLR ; Yes, go clear terminal buffers 2) CAIE S2,"Q" ; Quit logging? 2) CAIN S2,"q" ; . . . 2) JRST CN.QUT ; Quit logging 2) CAIE S2,"R" ; Resume logging 2) CAIN S2,"r" ; . . . 2) JRST CN.RSM ; Yes, do it 2) CAIE S2,"^" ; Want control chr? 2) JRST CN.ESE ; No, bad ************** 1)39 ANDI S1,37 ; make a control chr 1) JRST CN.SND ; and send it **** 2)39 CAIL S1,"`" ;[125] Lower case range? 2) XORI S1,240 ;[125] Toggle Parity & case 2) XORI S1,300 ;[125] Convert to control 2) JRST CN.SND ; and send it ************** 1)39 CN.SND: XMOVEI S2,XFRTRM ; Get terminal control block 1) $CALL T$CCOT ; Send char down line **** 2)39 CN.SND: BLSCAL GEN%PARITY##,<S1> ; Generate correct parity 2) XMOVEI S2,XFRTRM ; Get terminal control block 2) $CALL T$CCOT ; Send char down line ************** 1)39 XMOVEI S2,MYTERM ; Yes, output to our tty also **** 2)39 $CALL CN.PAR ; Even parity unless PR%NONE 2) XMOVEI S2,MYTERM ; Yes, output to our tty also ************** 1)39 CN.TYP: XMOVEI S2,MYTERM ; Point to the terminal block 1) $CALL T$CCOT ; Output the character 1) $RETT ; and return 1)40 SUBTTL Command execution -- DEFINE command **** 2)39 CN.TYP: $CALL CN.PAR ;[125] Even parity if needed 2) XMOVEI S2,MYTERM ; Point to the terminal block 2) $CALL T$CCOT ; Output the character 2) $RETT ; and return 2) ;[125] Here to put even parity on a character. 2) CN.PAR: MOVE S2,PARITY%TYPE## ;[125] Get the parity type 2) CAIN S2,PR%NONE## ;[125] No parity? 2) $RET ;[125] Yes, leave it alone 2) ANDI S1,177 ;[125] Keep only 7 bits 2) MOVEI S2,(S1) ;[125] Get a copy 2) LSH S2,-4 ;[125] Shift back 4 bits 2) XORI S2,(S1) ;[125] Combine halves 2) TRCE S2,14 ;[125] Left bits both 0 2) TRNN S2,14 ;[125] Or both 1? 2) XORI S1,200 ;[125] Yes, change high bit 2) TRCE S2,3 ;[125] Right bits both zero 2) TRNN S2,3 ;[125] Or both one? 2) XORI S1,200 ;[125] Yes, change high bit 2) $RET ;[125] All done File 1) DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984 File 2) DSKB:KERMIT.MAC[10,52,KERMIT,10] created: 1753 11-Jul-1984 2)40 SUBTTL Command execution -- DEFINE command ************** 1)41 C$EXI0: $HALT ; Exit to the monitor 1) $RETT ; Allow continues **** 2)41 C$EXI0: SKIPN LOGDIN ;[125] Are we logged in? 2) JRST [$TEXT (,<.KJOB^M^J.^A>) ;[125] No, make a nice msg 2) LOGOUT 1, ;[125] And quit 2) JRST .+1] ;[125] Shouldn't get here... 2) $HALT ; Exit to the monitor 2) $RETT ; Allow continues ************** 1)52 HLLOS USRFX+.FDEXM ; . . . 1) SETOM USRFX+.FDDIM ; . . . **** 2)52 ;[126];@C$RECEIVE + 9 2) HRROS USRFX+.FDEXM ;[126] . . . 2) SETOM USRFX+.FDDIM ; . . . ************** [Ed. - Some of the comments in the above FILCOM listing were edited to make them fit on the screen. The patch will be in the next release of DECsystem-10 Kermit.] ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Jul-84 22:05:36-EDT,15014;000000000000 Return-Path: <CC.FDC@CUCS20> Received: from CUCS20 by CU20B with DECnet; 18 Jul 84 22:04:59 EDT Date: Wed 18 Jul 84 22:03:37-EDT From: Frank da Cruz <CC.FDC%CUCS20@COLUMBIA-20.ARPA> Subject: Info-Kermit Digest V1 #16 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Wednesday, 18 Jul 84 Volume 1 : Number 16 Today's Topics: Reminder - How to Get Kermit New Kermit for IBM MVS/TSO New Apple II Kermit-65 Release New Release of DEC-20 Kermit Kermit on Otrona Attache Victor Kermit and Problems Transferring to VAX Kermit over Arpanet Kermit and TACs Kermit Between IBM PC and Host -- 8 Bit Transfer ---------------------------------------------------------------------- Date: Wed 18 Jul 84 21:33:15-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Reminder - How to Get Kermit To: Info-Kermit@CUCS20 This issue of the Info-Kermit digest contains announcements of several new KERMITs. For the benefit of those who are new to the Info-Kermit list, and to refresh the memories of those who aren't, here's how to get the KERMIT files: ARPANET/Internet: Use FTP, connect to host COLUMBIA-20, login as user ANONYMOUS with any non-null password, and GET (or MULTIPLE GET) the files you're interested in. Anonymous FTP access to COLUMBIA-20 is allowed only after 6:00pm and before 6:00am, eastern time. CCNET (DECNET hosts at Columbia, CMU, CWRU, NYU, Stevens, and (soon) Vassar): Use NFT to COPY the desired files from CU20B::KER:. If you're on a VAX, just use the COPY command. Specify /USER:ANONYMOUS. If CU20B does not grant you anonymous access, ask your system manager to get the files. CCNET and ARPANET: All KERMIT files are in the area KER:. Several short files are of particular interest: KER:00README.TXT Guide to what's available, showing file name conventions. KER:VERSIONS.DOC List of all known KERMIT versions, both available and in progress. KER:CURRENT.DOC Reverse chronological list of available versions, showing release date and version number. BITNET: On an IBM VM/CMS system, type the command SMSG RSCS MSG CUVMA KERMSRV HELP to get instructions for how to use the Kermit server at host CUVMA. There is usually a delay between the announcement of a new version of Kermit and its availability on BITNET, because each file has to be painfully screened and possibly processed to fit the requirements of our RJE link. Other networks like USENET, MAILNET, etc, or if you're not on a network: Send mail to Info-Kermit-Request@COLUMBIA-20, or to: KERMIT Distribution Columbia University Center for Computing Activities 612 West 115th Street New York, N.Y. 10025 and we'll send you flyers explaining how to order a distribution tape. ------------------------------ Date: Wed 18 Jul 84 18:21:15-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: New Kermit for IBM MVS/TSO To: Info-Kermit@CUCS20 Announcing Kermit for MVS/TSO on IBM 370-series and compatible mainframes from Ron Rusnak of the University of Chicago Computation Center (SYSRONR@UCHIVM1.BITNET or SYSTEMS.RON@UCHICAGO.MAILNET). This is an adaptation of Columbia's VM/CMS implementation, and it has about the same characteristics -- a no-frills Kermit, no server operation, no binary file transfers, and so forth. The source and documentation files are in KER:TSO*.* (4 files). The CMS and TSO versions of Kermit will be upgraded to a more advanced level in the future. ------------------------------ Date: Wed 18 Jul 84 15:49:46-EDT From: Anton Mione <OC.MIONE@CU20B> Subject: New Apple II Kermit-65 Release To: sy.fdc@CU20B Version 2.1 of Apple II DOS KERMIT-65 is finished. APPREAD.ME is the usual 'quick summary' of changes. APPHXL has been changed to be more 'Terse' in providing information. It now prints the count and load address for each line of the .HEX file followed by an '[OK]' if things went well or a '[CHECKSUM ERROR]' if they did not. APPDXL has not changed but a .BIN file is now included. APPLEK.M65, APPLEK.HEX, and APPLEK.BIN are the new source/object to release 2.1. APPLE.MSS is the new format documentation. This is a first draft and I may have to make some minor changes before it is really ready to be included in the user manual. Some new functionality has been added to KERMIT-65, especially in relation to CONNECT mode support. A cursor is now displayed when connected to a remote host. Upper case characters appear in inverse so the user can now distinguish between upper and lower case characters. Also, characters which can not be directly generated from the Apple ][ keyboard can now be generated by using a right-arrow as a prefix character. The connect-escape processing now has more options. Break signals can be sent, etc. Some bugs have been fixed in the GET and SEND commands. KERMIT-65 no longer runs out of buffers in long sessions. The GET command uses file names out of the File-header packets sent from the remote Kermit. There is now an easy way to change the drive which KERMIT-65 uses for file transfers. Anton:<miONE> [Ed. - The program now supports the Apple II, the II+, and the IIe (with certain limitations on the IIe), and the Apple Comm Card, the Apple Super Serial Card, and the DC Hayes Micromodem II. The files are available in KER:APP*.*.] ------------------------------ Date: Wed 18 Jul 84 18:51:09-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: New Release of DEC-20 Kermit To: Info-Kermit@CUCS20 Announcing a new release of DECSYSTEM-20 Kermit, 4.1(236). The major change in this version is to move the code for connecting to a remote system into the Kermit-20 program itself, rather than running another program (TTLINK) in a lower fork. The connect code now runs in two forks (a`la TELNET), and is not interrupt driven, unlike TTLINK which ran in one fork and was interrupt driven. This was done for several reasons -- . It allows Kermit-20 to run in local mode under TOPS-20 version 6.0, which does not allow multiple simultaneous opens of a TTY device. . It gives the user greater control over communication options, like line speed, BREAK simulation, flow control, etc. . It allows Kermit-20 to run in local mode under batch, for instance to dial a remote system at midnight and send or get files. This was not possible with TTLINK, which did not send the appropriate "pty-hungry" signals to BATCON. As a consequence of this change, several new commands have been added -- CLOSE (to explicitly close the various kinds of log files), SET SPEED, SET BREAK, PUSH. The files are in KER:20KERMIT.*, including a new 20KERMIT.DOC. - Frank ------------------------------ Date: 16 Jul 1984 0759 PDT From: Richard B. August <AUGUST@JPL-VLSI.ARPA> Subject: Kermit on Otrona Attache To: info-kermit-request@columbia-20 I have been successful in getting Kermit up on my Otrona Attache, however, I am experiencing some "difficulties" in transfering .COM (IMAGE) files from my VAX. Additionally I have had "NO LUCK" transfering files (IMAGE) from SIMTEL20. Does anyone have a KERMIT working on an Otrona Attache? If not I will FTP the source I have (along witmy changes) to see what mistakes I have made. Thanks in advance. Regards, Richard ------------------------------ Date: Mon 16 Jul 84 14:37:14-EDT From: JUNGER@CWRU20 Subject: Victor Kermit and problems transferring to VAX. To: info-kermit@CUCS20 I noted to queries in the current INFO-KERMIT which may relate to the same experience which I had. One was about Sirius/Victor. We have just gotten the MSDOS version of Kermit up on a Victor 9000, and, though we have not done much experimenting, it seems to work fine. We transferered the Kermit .COM file itself to a DEC 20 and returned it to the Victor and it ran just as it should upon its return. But!!! we had trouble getting the DEC to receive if from the the Victor using the receive command on the DEC. The symptoms were that the Victor showed exactly the same symptoms as were reported by Marco Papa when trying to send a file to a VAX at 9600 baud. We were only running at 1200 baud. The solution was to put the DEC in the server mode. I don't know if the VAX version allows it to be run as a server, but it might be worth trying. P. Junger [Ed. - That's a strange one. DEC-20 Kermit does nothing different in server mode, except that it parses its commands from packets rather than the keyboard. The communications line conditioning and protocol should be exactly the same. I'd tend to chalk it up to coincidence. But just to make sure, get the latest version of DEC-20 Kermit - 4.1(236) - announced above, and see if the problem persists.] ------------------------------ Date: Tue 17 Jul 84 17:44:41-EDT From: J. Eliot B. Moss <EBM@MIT-XX.ARPA> Subject: Kermit over Arpanet To: cc.fdc@COLUMBIA-20.ARPA I regularly log in through a TAC from a Z80 based machine to MIT-XX, a TOPS-20 site. I have used the MODEM7xx program for file transfer in the past, and typically have had success only in downloading. I run at 1200 baud. I understand a lot about the Arpanet protocols, etc., having done some work to get a version of MODEM running on the 20. I have had no success getting Kermit on XX to talk to my local Kermit. The TOPS-10 compatibility stuff is a crock to begin with; but mainly it would appear that characters just do not flow, even though I can type (as in the CONNECT command) through my local Kermit. Any hints on what to do? [Ed. - See next message.] For your info, I have downloaded the CP/M version of Kermit, and created versions for the following: Molecular SuperMicro (terminal type selectable by EQU) Altos 8000-10 running MP/M (terminal type by EQU) Altos 8000-10 running CP/M (terminal type by EQU) my home micro (Morrow Design Mult I/O board) In the process, I made it easy for people using the Z80CTC to set the baud rate, and for those using the NS8250 asynch chip to init and set the baud rate. Of course, some systems vary baud rate clocks, so adjustments may have to be made, but code works out well. [Ed. - Charles@ACC, are you listening? You might want to incorporate this code into version 4.] I want to suggest that future versions be done in Turbo Pascal -- you can do up insert files to adjust system specific things, achieve modularity, etc. It would be much easier to maintain, though likely lead to bigger com files. [Ed. - Any volunteers?] Anyway, thanks in advance for any assistance you can give me. Eliot ------------------------------ Date: 17 Jul 1984 10:41-EDT Subject: Kermit and TACs From: ABN.ISCAMS@USC-ISID.ARPA To: INFO-KERMIT@COLUMBIA-20.ARPA NetLandians, Hard keeping up with what KERMITs can do, with all the wizards improving all the time. However, I learned a new trick with my host's KERMIT-20 and my own KERMIT-80 (CP/M) for working through a TAC. The TAC, as you may know, is a purely 7-bit medium and does a real job on any binary files going through it. Some KERMITs have the ability to "prefix" binary characters to enable you to pass data through such 7-bit media. However, the trick is how to make your KERMIT do that! By setting my host's KERMIT-20 with parity (I used a nice innocuous "Even"), that forces KERMIT-20 to prefix binary characters. It KNOWS it has to fiddle that 8th bit, so it changes everything to its 7-bit prefixed equivalent. The TAC is gonna strip off that parity bit anyway, but no harm done! Down at the micro, you don't have to do anything! Just do your normal receive, and KERMIT-80 DOES know how to change prefixed data back to real 8-bit. You will truly get an effective 8-bit data download through a 7-bit medium. For uploads, a little more trickiness. Tell your KERMIT-20 on the host to SET FILE to BYTESIZE 8, so it knows it'll be getting true binary. Tell your local KERMIT-80 you're sending in FILE-MODE BINARY, and SET PARITY EVEN, so YOUR KERMIT will know to prefix binary. Again, the TAC will strip that 8th bit during upload, but who cares? The host KERMIT-20 changes things back to a nice 8-bit character and files it correctly as 8-bit files, and all is well. For a test, I downloaded an ITS-binary formatted file from my host through the TAC, and then uploaded it again as a pure 8-bit file. Then downloaded it again as a pure 8-bit file (no ITS-binary this time). The two versions on my micro (the converted ITS-binary one and the new 8-bit one) matched exactly. Damn, these KERMITs are clever! Regards, David Kirschbaum Toad Hall ABN.ISCAMS@USC-ISID [Ed. - As a matter of fact, DEC-20 Kermit has a command "SET TVT-BINARY", which should take care of all this for you, provided your TOPS-20 monitor is set up for it. This command will tell the TAC to put itself in binary mode, and then will take the TAC out of binary mode when the transfer is over. But if your TOPS-20 monitor is not set up to do this -- several patches popular among ARPAnet TOPS-20 sites are necessary -- then your method is a good alternative, except that you shouldn't SET FILE BYTESIZE 8, etc, for ASCII (text) files if you want them to be usable on the DEC-20. All this is described in the DEC-20 Kermit manual, KER:20KERMIT.DOC.] ------------------------------ Date: Tue, 17 Jul 84 23:57 EDT From: LBrenkus@MIT-MULTICS.ARPA Subject: Kermit between IBM PC and host -- 8 bit transfer To: info-ibmpc@USC-ISIB.ARPA ReSent-To: info-kermit@COLUMBIA-20.ARPA Previous messages have (correctly) noted that the host is capable of receiving 8 bit files from Kermit if it is instructed to expect them. I believe that it is impossible to download them back to the IBM PC, however. The transfer mysteriously "hangs", with the host Kermit still trying to send the file, but the PC end reports a message and aborts the transfer. I actually have to disconnect (turn my modem off, redial up again) and abort my old process, or the Multics Kermit will continue to spew out garbage. Apparently, the problem is that 8 bit quoting doesn't work properly on IBM-PC Kermit. Hopefully, that shortcoming will be corrected in the new, fully modularized MSDOS Kermit which will be released real soon now. [Ed. - MS-DOS Kermit 1.20 cannot do "8th-bit quoting" and so cannot transfer binary files over a 7-bit connection. The forthcoming release will be able to do this.] ------------------------------ End of Info-Kermit Digest ************************* ------- 23-Jul-84 12:43:27-EDT,12455;000000000000 Return-Path: <CC.FDC@CUCS20> Received: from CUCS20 by CU20B with DECnet; 23 Jul 84 12:42:55 EDT Date: Mon 23 Jul 84 12:42:04-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #17 To: Info-Kermit: ; Reply-To: Info-Kermit@COLUMBIA-20 Info-Kermit Digest Monday, 23 July 1984 Volume 1 : Number 17 Today's Topics: Kermit Directory Listing Apple II Kermit-65 V2.1 KERMIT-80 vs TAC More About UNIX Kermit Problem Wierd Things with Kermit-11 RT11 and CONNECT Command FLEX Kermit? Kermit for Cromemco OS's? ---------------------------------------------------------------------- Date: Mon 23 Jul 84 11:47:51-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Kermit Directory Listing To: Info-Kermit@COLUMBIA-20.ARPA Users at some network sites have complained that their FTP implementations do not support the MULTIPLE GET function. Therefore, they need to know the exact name of each file before in order to GET the desired files one by one. Starting now, there will be a new file in the Kermit network distribution area on COLUMBIA-20, KER:FILES.DIR. It contains an alphabetical listing of all the Kermit files, including their sizes and dates. The directory listing will be updated automatically each morning at 3am, eastern time. Here are the first few lines to illustrate the format: PS:<KERMIT> PGS Bytes(SZ) Write 00README.TXT.50 5 12347(7) 18-Jul-84 170AZLIB.ASM.1 27 66670(7) 25-May-84 170KERMIT.DOC.3 9 22498(7) 11-Jun-84 .FOR.2 67 170230(7) 25-May-84 .MSG.1 1 1453(7) 25-May-84 .MSS.1 8 18347(7) 11-Jun-84 .NR.1 4 8914(7) 18-Oct-83 20CMD.DOC.1 4 9229(7) 14-Aug-78 .MAC.1 4 7794(7) 10-Jun-81 PS:<KERMIT> is the name of the directory, for which we normally use the "logical device name" KER:. 00README.TXT.50 is the name of the first file in the directory, which is a text file containing an explanation of what is available and the naming conventions used. "00README" is the file name, "TXT" is the file type (text), and "50" is a generation number, which should normally not be used explictly. Note that for files of the same name, but differing types and generations, the listing omits the name on subsequent lines, although you must supply it in order to refer to the file. For instance, 20CMD.DOC.1 4 9229(7) 14-Aug-78 .MAC.1 4 7794(7) 10-Jun-81 denotes two files, 20CMD.DOC and 20CMD.MAC. The number in the PGS column shows the size in DEC-20 "pages" (units of 512 36-bit words, or 2560 7-bit ASCII characters, or 2048 8-bit bytes). The next two numbers show the length in bytes, and the size of the bytes. Normally, the bytesize has the following significance: 7 ASCII text (program source, documentation, hex files) 8 "Foreign" 8-bit binary files (from micros and other 8-bit-byte systems) 36 PDP-10 or DEC-20 36-bit binary files The final column shows the write date for the file. A chronological listing of the currently available Kermit versions can be found in KER:CURRENT.DOC. ------------------------------ Date: 18 Jul 1984 2208 PDT From: Ken Adelman <KEN@JPL-VLSI.ARPA> Subject: Apple Kermit V2.1 To: Info-Kermit@COLUMBIA-20 After I received digest #16, announcing the new apple kermit, I ftp'd KER:APPLEK.HEX from columbia-20 (between 9 and 10pm pdst jul 18) and kermit'd it to my apple useing V2.0 of kermit. The file APPLEK.HEX contains the old version V2.0 rather that the new version V2.1. Did someone forget to update something? Frustration is maximized since the load address moved by a byte from $800 to $801 in the version change, which gives the appearence of trash when one saves from $801 (for V2.1), and because I have a Super Serial Card, which requires a bug-fix for V2.0 and not V2.1. Please update the file. thanx, Ken Adelman Caltech [Ed. - Sorry! Thanks for pointing it out. The error was corrected soon after the announcement was made.] ------------------------------ Date: Fri, 20 Jul 84 09:25 CDT From: "David S. Cargo" <Cargo@HI-MULTICS.ARPA> Subject: Apple II Kermit-65 To: Info-Kermit@COLUMBIA-20.ARPA I don't know how often people plan for future versions of Kermit, but I thought it would be worthwhile pointing out some problems that have just been created. There are two major sources of incompatibility between the Apple IIc and the other earlier Apples. One is the disk drive; this is a major concern only of you are producing or using copy protected software. The other is the character set displayed on the screen. The inverse video characters have been replaced by graphics characters at least in some cases. This means that when Kermit for the IIc is done by somebody, there will be problems (or perhaps might be). I don't own any kind of Apple, so I can't verify the problem. My information comes from an article recently published in InfoWorld. If you are interested in minimizing differences between versions of Kermits for Apples, somebody might want to experiment and develop a common solution. ------------------------------ Date: 19 Jul 1984 02:00-EDT Subject: KERMIT-80 From: ABN.ISCAMS@USC-ISID.ARPA To: INFO-KERMIT@COLUMBIA-20.ARPA A recent input to our Info-Kermit Digest commented on several new I/O drivers for CP/M systems. The 8250, as used on the Morrow Multi I/O board, is already implemented (Charles has it too), and works fine at 300 to (I guess!) 52000 - just kidding, but for sure 9600. No parity fiddling on the board - just baud rate. I too work through a TAC with my Decision I, and have no problems up or down. I understand there are many bells and whistles on the KERMIT-20 to permit binary transfer, disabling TAC intercept char, etc., but my local wizards frown on too much fiddling with their TAC, so I've done most of it within KERMIT. The World Famous Toad Hall TACTrap handles intercept characters (just screens for them during packet or straight upload transfers, and sends the designated intercept character twice! That takes care of the TAC!). TACs usually have kind of small input buffers, so you have to set the host (or local) KERMIT to maybe 50 or 60 character packets during upload. Any kind of flow control engaged messes things up: I leave it up to the KERMIT-20 to take care of all that. I too have problems with MDM7nn uploading, specifically because the TAC can't handle those 128-byte packets, so I use KERMIT exclusively for uploads when I'm doing binary. For normal text, I usually just engage Xon/Xoff flow control and use MDM7nn (or my new patched KERMIT 4.0 with a MDM7nn- like Xon/Xoff straight upload) to move ascii into an editor. If that gentleman can't work out KERMIT for uploads, please contact me directly and I'll send you parts of source, whatever, to make your system work through the TAC. Last point -- can someone give me pointers to the wizards playing with floating windows and KERMIT. I'm curious as to their approach, having several ideas myself but no practical knowledge. Regards, David Kirschbaum, Toad Hall ABN.ISCAMS@USC-ISID [Ed. - We'll be looking into a windowing option for Kermit this summer at Columbia, but no guarantees that we'll accomplish anything!] ------------------------------ Date: Thu Jul 19 1984 16:36:18 From: Marco Papa <papa%usc-cse.csnet@csnet-relay.arpa> To: info-kermit%columbia-20.arpa@csnet-relay.arpa Subject: More about UNIX Kermit problem For background on this problem, please read Vol. 1, number 15. I used debug mode on both sides of UNIX and PC-DOS kermits and these are the results: The 3 packets that are sent by PC-DOS Kermit for a text file of name TEST.FOR are as follows (each packet is preceded by the SOH char that on the PC appears as the small face): 1. ) S~% @-#R (Send Initiate) 2. +!FTEST.FORJ (File header) 3. |"DTEST.FORJ (Data packet) After trying 5 times on the third packet PC Kermit aborts saying that cannot receive acknowledgement from the host. If I connect back to UNIX now I get the following data (I run it with dd mode): spack type: N, num: 2, len: 0, recstate: D, data: SOH followed by #"N5 This seems to me as the standard NAK packet. This packet is sent a number of times, until UNIX kermit finally aborts and exits. What is not clear to me is why PC Kermit sends the filename into a Data packet after having sent it in the File Header packet, since the filename was not in the text file at all. Also, you there Kermit hackers, are the various fields in the packets correct? Marco Papa USC Computer Science Dept. ARPA, CSNET: papa.usc-cse@csnet-relay UUCP: ..!randvax!uscvax!papa [Ed. - Very strange... We've been running PC Kermit 1.20 heavily for a long time and have never seen such behavior. Rather than try too hard to track it down, better to just get the new release, which should come out any day now. Really!] ------------------------------ Date: Thu 19 Jul 84 00:53:50-PDT From: Carl Fussell <G.FUSSELL@SU-SCORE.ARPA> Subject: rt kermit from Stevens... To: info-kermit@COLUMBIA-20.ARPA Address: Santa Clara University I recently got the new Stevens release of kermit-11 and from k11rt4.com (the linker command file if I remember correctly) figured out most of the necessary files to compile it. I am doing this on an 11/23 running RT-11 V5.0 with multi term support. All compiled correctly after locating the .Included files but when I linked it, got a multiple definition on labe DIRER$. It appears that routine is coded into 2 modules... K11CMD.MAC and K11RT4.MAC. (???) I commented out one of them (K11RT4 arbitrarily) and all compiles and links ok. Just wanted to let someone know this duplication was there. The resulting kermit still does not work properly unfortunately. I can start it and (after setting line and speed) connect to host and work. This moment I "escape" back to local kermit, I get the prompt but then appears to cease all output to terminal. As soon as I type a couple of ^C's, then any and all output that was generated while kermit was "frozen" appears and kermit terminates (from ^C's). Has anyone else run into any problems that you are aware of? If so, can you let me know who so I can contact them... perhaps they have fixed them. thanx... Carl Fussell G.FUSSELL@SU-SCORE ------------------------------ DATE: MON, 23 JULY 1984 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: KERMIT AND RT11 The RT11 problem about Kermit-11 not accepting input after returning from the connect command has been solved. Kermit-11 will not run under the SJ (single job) monitor. There must be some call that gets lost on the SJ exec, or else there is a bug in doing the .MTDTCH call to release the terminal from MT service. If anyone has any ideas, I will be glad to look into it but for now, simply run FB or XM. Since this problem is trivial to work around, getting Kermit-11 to run under SJ will be placed on the back burner. Brian Nelson ------------------------------ Date: 18 Jul 84 16:27 +0200 From: Edgar_Hildering_SARA%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KERMIT_implementation_and_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: FLEX Kermit? Is there anyone outthere who can reach John Guidi Jackson lab? He is working on a FLEX-implementation of Kermit. I would like to give him some mental support and if necessary any other help. ------------------------------ Date: Sat 21 Jul 84 17:50:16-PDT From: Phillip W. Barth <BARTH@SU-SIERRA.ARPA> Subject: KERMIT for Cromemco OS's? To: cc.fdc@COLUMBIA-20.ARPA Has anyone put together versions of KERMIT to run under Cromemco's operating systems (CDOS, C-10 CDOS, or Cromix)? As I understand it, the I/O byte is different for the CDOS systems so that generic CP/M KERMIT won't work directly. Any info will be appreciated. ------------------------------ End of Info-Kermit Digest ************************* ------- 27-Jul-84 17:54:20-EDT,13732;000000000000 Return-Path: <CC.FDC@CUCS20> Received: from CUCS20 by CU20B with DECnet; 27 Jul 84 17:53:48 EDT Date: Fri 27 Jul 84 17:51:32-EDT From: Frank da Cruz <CC.FDC@CUCS20> Subject: Info-Kermit Digest V1 #18, Special MS-DOS Edition To: Info-Kermit: ; cc: Info-IBMPC@USC-ISIB.ARPA, Info-Micro@BRL-VGR.ARPA Info-Kermit Digest Friday, 27 July 1984 Volume 1 : Number 18 Today's Topic: New Release of Kermit for MS-DOS ---------------------------------------------------------------------- Date: Fri 27 Jul 84 17:45:00-EDT To: Info-Kermit From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: New Release of Kermit for MS-DOS This issue of the Info-Kermit Digest is devoted to the long-heralded (and overdue) announcement of version 2 of Kermit for MS-DOS systems (Kermit is Columbia University's file transfer protocol for use over telecommunication lines, and it runs on a wide variety of systems). We announced our intention to provide this new release back in January, and have been working on it ever since. The previous release was 1.20, 28 November 1983. The new version is called "Kermit-MS" rather than "Kermit-86" and the version number is 2.26. It is available for several systems: System DOS Versions ------ ------------ IBM PC, PPC, and XT 1.1, 2.0 & above DEC Rainbow 100 and 100+ 2.05 & above HP-150 2.0 Wang PC 2.01 Others (Generic DOS) 1.1, 2.0 & above Versions for the IBM PCjr and Heath/Zenith 100 are soon to be added (version 1.20 already run on these machines). If your MS-DOS system is not on this list, you are invited to add support for it by supplying the appropriate system- and device-dependent modules (described below). The IBM version has been tested on IBM PCs with the old and new motherboards and ROMs, as well as on the XT and Portable PC, on hard disks, floppy disks, and RAM disks, and on color and monochrome monitors. It has NOT been tested on the Compaq, Columbia, or other "PC compatible" product; there is some chance that it might not work on the compatibles even when the previous release (1.20) did, because of greater dependence on the display hardware. Version 2 of MS-DOS Kermit has been tested successfully up to 9600 baud on the IBM, DEC, HP, and Wang micros, in communication with full duplex systems like the DEC-20 and VAX, and half duplex systems like IBM mainframes. Kermit-MS requires about 80K RAM, and certain functions like PUSH and RUN will need additional memory. Thus, for DOS plus Kermit, you will need a machine with at least 128K. Version 1.20 can run on a 64K machine. Version 1.20 will remain available indefinitely because it has proven quite stable, runs on a variety of PC-compatible systems, and is considerably smaller than version 2. Here is a summary of the changes: * Program organization: The program has been broken up into separate source files, assembled separately, and linked together. The modules are: System/Device Independent: MSKERM.ASM - Main program MSSEND.ASM - File sender MSRECV.ASM - File receiver MSSERV.ASM - Server operation MSFILE.ASM - File i/o MSCMD.ASM - Command parser MSTERM.ASM - CONNECT command MSCOMM.ASM - Communications port buffering & flow control MSSET.ASM - SET, SHOW, and STATUS commands MSDEFS.H - Data structure definitions and equates System/Device Dependent: MSXxxx.ASM - System-dependent code for system xxx MSYxxx.ASM - System-dependent screen and keyboard code MSZxxx.ASM - Modem control (modem-dependent) MSXSYS.DOC - Description of system-dependent modules The modular organization allows easier modification of the program, quicker transfer of modified portions from system to system. The modules are designed to be well-defined and self-contained, such that they can be easily replaced. For instance, someone who prefers windows and mice to typing commands could replace the command parsing module without having to worry about the effect on the other modules. * Kermit Protocol Improvements: Kermit-MS now supports: . 8th-bit prefixing for passing binary data through 7-bit communication links . 12-bit checksums and 16-bit CRCs as alternate block check types . Compression of repeated bytes . Server operation . Advanced commands for servers, including: REMOTE DELETE REMOTE DIRECTORY REMOTE HELP REMOTE HOST REMOTE SPACE REMOTE TYPE These advanced protocol features can be used in conjunction with other advanced Kermit implementations, including itself, as well as the current Kermits for the DECsystem-10, DECSYSTEM-20, VAX/VMS, PDP-11 (RSX, RSTS, RT), DEC Pro-350, and others, and soon to include IBM VM/CMS and UNIX. * Local command execution: The following new commands provide access to DOS functions from within the Kermit-MS program: DELETE DIRECTORY SET DEFAULT DISK PUSH (to DOS) SET DESTINATION (device - disk or printer) SPACE (runs CHKDSK) RUN (a program) * Command parsing: The command parser has been improved in many areas. For instance, "?" now works much better than before (though still not perfectly). ESC now provides completion not only in keywords, but also in filenames. CTRL-W deletes the previous "word" on the command line. CTRL-C always returns to the Kermit-MS> prompt. There is a command macro facility; DEFINE lets you build macros by combining Kermit-MS commands, DO executes them, SHOW displays them. DOS command line arguments are accepted, and may be strung together separated by commas, e.g. "kermit set baud 9600, set timer on, connect" Kermit-MS now reads an initialization file, MSKERMIT.INI, and can process (nested) command files with a TAKE command. * Terminal emulation: On IBM micros, the speed of Heath-19 terminal emulation has been improved by using direct screen memory access. Functions like insert and delete character now execute very rapidly. Heath-19 emulation functions, such as reverse index, missing from earlier releases are now supplied. H19 emulation may be disabled to allow the use of other console drivers, like ANSI.SYS, in conjunction with Kermit-MS. On systems with 25 lines, the 25th line is an inverse video mode line, displaying current settings, which may be kept or turned off. On the IBM and DEC systems, there are pop-up help and status screens, and the screen is saved and restored between remote/local context switches. The terminal session can be logged to disk to provide unguarded capture of remote files or session typescripts. On the IBM, DEC, and HP systems, the screen can be rolled back several pages, on a per-line or per-screen basis. On most of the systems, print-screen (screen dump) and CTRL-print-screen (toggle printing on/off) work as they do in DOS. On the IBM and DEC systems, a key redefinition facility is available to allow the layout of the keyboard to be altered to suit individual tastes, to set up keypads or function keys for specific applications, or to construct "keystroke macros". On IBM micros, the ALT key can be set up for use as a META key for use with EMACS-like editors. All versions of Kermit-MS except the generic DOS version are capable of transmitting the BREAK signal. The functions that are missing from the Wang and/or HP micros -- key redefinition, pop-up menus, screen rollback, screen print -- were omitted due to lack of information about how to get at the scan codes, screen memory, printer interrupts, etc, and may be added at a later time. Meanwhile, anyone out there who has the information and feels inclined to add missing features is invited to do so. * Communication options: The port characteristics are left alone when Kermit-MS starts (in the previous release, Kermit-MS always set the baud rate). The program allows settings for speed, duplex, flow control, handshake, and parity on a per-port basis, to allow convenient switching between ports. * File Transfer: You can now supply new names for files in SEND and GET commands. A timeout facility has been added to allow automatic recovery from deadlocks when communicating with systems (like IBM mainframes) that can't time out. The file transfer display has been reformatted, and includes more useful information, including a percentage for outbound files. The various counts are updated more reliably. Several options are available for interrupting file transfer, including ^X (cancel current file), ^Z (cancel entire batch), ^E (user-generated "error"), ^C (return immediately to command level), CR (simulate a timeout). The options are displayed during file transfer. There is a new end-of-file option to allow selection of DOS-style (believe the DOS byte count) or CP/M-style (file ends at first CTRL-Z) EOF detection. * Remote operation: Kermit-MS may be run from the back port in either interactive or server mode. This allows micro-to-micro file transfer without requiring an operator on both ends. * New Bootstrapping Procedure: The Kermit .EXE files for the various systems are now encoded using a printable 4-for-3 encoding, with compression of repeated 0 bytes. The result tends to be smaller than the original .EXE file. A new set of bootstrapping programs has been provided: MSMKBOO.C Encode. Can be used on any binary file. Written in C. MSBOOT.FOR Send the encoded file from the mainframe. Fortran. MSPCTRAN.BAS Decode the encoded file on the micro. MS Basic. MSPCBOOT.BAS Receive on the micro, decode on the fly. MS Basic. * Documentation: There's an entirely new manual, available now as a separate document, soon to be incorporated into the Kermit User Guide. It describes operation of the program in detail, along with the new bootstrapping procedure. * How To Get It: Kermit is available for a wide variety of systems -- micros, minis, and mainframes. It is distributed by Columbia University via network or on magnetic tape. For further information about Kermit, send network mail to INFO-KERMIT-REQUEST@COLUMBIA-20, or write to the Kermit Distribution address below. To be added to the Info-Kermit network mailing list, mail to INFO-KERMIT-REQUEST@COLUMBIA-20. The new MS-DOS Kermit files are available from COLUMBIA-20 via anonymous FTP after 6pm daily (ARPANET), though KERMSRV at CUVMA on BITNET (BITNET users should type "SMSG RSCS MSG CUVMA KERMSRV HELP" for information about the Columbia Kermit file server), and on all the Columbia DEC-20 systems in the KERMIT area. The file names all begin with "MS" (on BITNET, omit the "KER:" prefix). The executable programs have the suffix .EXE and are in 8-bit binary format. The corresponding 7-bit ASCII encoded files have the suffix .BOO. The system-specific programs are available in both .EXE and .BOO formats. KER:MSIBMPC -- IBM PC, XT KER:MSIBMJR -- IBM PCjr (not yet availble) KER:MSRB100 -- DEC Rainbow 100, 100+ KER:MSHP150 -- Hewlett-Packard 150 KER:MSHZ100 -- Heath/Zenith 100 (not yet available) KER:MSWANG -- Wang PC KER:MSGENER -- Generic DOS KER:MS*.ASM, KER:MS*.H are the assembler source files. KER:MSBUILD.HLP tells how to build the program. KER:MSKERMIT.DOC is the new MS-DOS section for the Kermit User Guide. KER:MSKERMIT.MSS is the Scribe source for the .DOC file. Those without network access may write to the following address for details of how to order a complete Kermit distribution on 9-track magnetic tape: KERMIT Distribution Columbia University Center for Computing Activities 612 West 115th Street New York, NY 10025 Version 2 of MS-DOS Kermit will be submitted to PC-SIG so that it can be ordered on IBM PC floppy disks. Inquiries should be directed to PC Software Interest Group 1556 Halford Avenue, Suite #130 Santa Clara, CA 95051 Phone 408-730-9291 Be sure to wait until they have version 2, because they are presently distributing version 1 on their disks numbers 41 and 42. It may take some time for them to update their distribution. * Credit: The bulk of the work was done by Daphne Tzoar and Jeff Damens of the Columbia University Center for Computing Activities. Many ideas (and "existence proofs") were contributed by Herm Fischer of Litton Data Systems -- key redefinitions, remote and server operation, etc, but those who have been using Herm's modified 1.20 will find that some of the features he added have been done differently in this release. 8th-bit quoting was originally added by Leslie Spira and her staff at The Source Telecomputing to allow Kermit to transfer binary files over Telenet. The new bootstrapping procedure and the new file transfer display were done by Bill Catchings of Columbia. Filename completion came from Kimmo Laaksonen at the Helsinki University of Technology. Some corporate support and encouragement was provided by Digital Equipment Corporation, Wang Laboratories, and IBM. * Disclaimer: Although we have been using the new version on several different kinds of systems for a good while and have done extensive testing, some bugs may have slipped through. Please hang on to your old release (1.20), and don't hesitate to report any problems to Info-Kermit@COLUMBIA-20. Suggestions and contributions are also welcome. ------------------------------ End of Info-Kermit Digest ************************* ------- 31-Jul-84 10:25:11-EDT,16952;000000000000 Return-Path: <CC.FDC@CUCS20> Received: from CUCS20 by CU20B with DECnet; 31 Jul 84 10:23:23 EDT Date: Tue 31 Jul 84 10:23:34-EDT From: Bill Catchings <CC.WBC3@CUCS20> Subject: Info-Kermit Digest V1 #19 Sender: CC.FDC@CUCS20 To: Info-Kermit: ; Info-Kermit Digest Mon, 30 July 1984 Volume 1 : Number 19 This week's editor: Bill Catchings Today's Topics: New Release of PR1ME Kermit Available Several New Documents Available Kermit in Modula-2 or Ada? Kermit in Turbo Pascal Franklin CPM Kermit, Apple Kermit 2.1 Kermit Distribution Unfairness (2) Problems loading Kermit-10 UNIX Kermit Kermit for rsx11m+ (2) Kermit-MS for NEC APC SDS Kermit? Bug fix for new MSPCTRAN.BAS bootstrap program ---------------------------------------------------------------------- Date: Fri 27 Jul 84 18:01:15-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: Info-Kermit To: Info-Kermit@CUCS20 As many of you may have noticed, COLUMBIA-20 was down for several days. During that period of relative calm, we were able to get the new MS-DOS Kermit put together sufficiently for release. I'm sure we'll be getting many reports about it, and we'll collect them all for the next release which will be dedicated to incorporating fixes for reported problems. Meanwhile, I'll be going on vacation for the month of August, so some of the other Kermit folks will be running the Info-Kermit digest. This issue is a trial run. Keep addressing your comments, contributions, requests, complaints to Info-Kermit or Info-Kermit-Request at COLUMBIA-20, but not to me personally, because I won't be here to read them until September. - Frank ------------------------------ Date: Mon 23 Jul 84 15:05:24-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: New Release of PR1ME Kermit Available To: Info-Kermit@CUCS20 This is to announce a new release of Kermit for PR1ME computers running PRIMOS R18 and R19. It was submitted by Nancy K. Morrison of SPSS, Inc, in Chicago and includes bug fixes and enhancements to the original version contributed by The Source, as well as a special conversion facility for SPSS "portable files". The new files are in KER:PRIMEK.*. Some of the changes are: 1. Break handler fixed so quits are done cleanly. 2. Received files are now renamed when they already exist on disk. 3. The compiling and linking files were modified to ran at PRIMOS rev 18, and a new CPL program was added to copy the tree structure with rev 18 commands. Kermit does run at rev 18, but not with the server command "attach" (CWD). 4. New PORTFILE command for SPSS files. ------------------------------ Date: Wed 25 Jul 84 11:13:16-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: Several New Documents Available To: Info-Kermit@CUCS20 Several new documents are available in the Kermit distribution area. KER:K11FIL.DOC contains a description of what all the PDP-11 Kermit files are (Brian Nelson, U of Toledo). KER:KINTRO.DOC is an introduction to Kermit for the inexperienced computer user, with emphasis on micro-to-micro file transfer (Norman Weatherby of the Columbia University Center for Population and Familty Health). KER:APPLE.DOC (Antonino Mione, Stevens Inst of Tech, and Peter Trei, Columbia U) is an update of the new Apple DOS Kermit manual in which several minor errors are corrected. KER:APPLE.MSS is the Scribe text formatter source for this file. ------------------------------ Date: Monday, 23 Jul 1984 14:19-EDT From: munck@Mitre-Bedford To: Info-Kermit@Columbia-20 Subject: Kermit in Modula-2 or Ada? I haven't seen any mention of a kermit in either of these "languages of the future." Is anyone out there working on either? Failing that, which of the various Pascal kermits would be "best" to translate/re-code into one or both? By "best" I mean (priority order): o a clean implementation; modular, readable, untricky, uniform. o complete with as many of the standard features and optional goodies as possible. o makes good use of Pascal extensions that are in the direction of Modula-2 and Ada; strings, units, etc. Eventually, of course, we'll need only the Ada implementation, as Ada will be supported everywhere on everything. Those of you still in your teens may live to see that, if you take very good care of yourselves. -- Bob Munck ARPA: munck@mitre-bedford uucp: {allegra,genrad,ihnp4,utzoo,philabs,decvax}!linus!bccvax!munck USPS: The MITRE Corporation, MS A134, Bedford, MA 01730 (617)271-3671 ------------------------------ Date: Wed, 25 Jul 84 08:40:04 EST From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers) To: cc.fdc@columbia-20.ARPA Subject: Kermit in Turbo Pascal I think the idea of rewriting Kermit in Turbo Pascal is a very good one for the following reasons: * It will allow more Kermit users to contribute to the development and maintenance of the program (everyone can afford Turbo Pascal, especially with their new educational licencing) * It will allow greatly increased commonality between the CP/M-80, CP/M-86, and MS-DOS versions * Borland might let us use their "general installation program" which would make Generic Kermit look nicer (as screen formatting would be possible without editing and recompilation). As always, the problem is finding someone prepared to do the work... Steve ------------------------------ Date: Tue, 24 Jul 84 10:59:39 EDT From: Dave Swindell <dswindel@bbn-labs-b> Subject: Franklin CPM Kermit, Apple Kermit 2.1 To: info-kermit@columbia-20 I have a Franklin 1200 computer with a PCPI CP/M card and and ASIO II serial/parallel card. Are there any versions of Kermit that have been used with the PCPI CP/M card? Are the source .ASM files available on line for either the Apple CPM or generic CPM Kermits? Any help in obtaining a workable CPM kermit for the Franklin would be appreciated. Thanks, Dave Swindell P.S. The new Apple 2.1 Kermit works fine. I had problems downloading the HEX via APPHXL at 1200 baud, but none at all at 300 baud. ------------------------------ Date: Fri, 20 Jul 84 16:00 EST From: Mark Scherfling <mrs2%gte-labs.csnet@csnet-relay.arpa> To: info-kermit-request%columbia-20.arpa@csnet-relay.csnet Subject: new kermit distribution We are interested in the Kermit versions for IBM/TSO and the new version for the Apple II. From the notices explaining how to receive new versions of the protocol, we seem to be left with sending you a tape and $100 while those more fortunate on other networks can just transfer the source to themselves without any cost incurred. I feel that this selective policy of who pays for updates is unfair. We have already paid for the first distribution and I feel, as with the others, we should not have to pay for subsequent updates. I feel strongly about this and wish to have a clearification on this matter from yourselves. regards, -- mark ------------------------------ Date: Wed 25 Jul 84 13:06:18-EDT From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA> Subject: Kermit Distribution Unfairness To: Info-Kermit@CUCS20 In response to Mark Scherfling's comments, I agree that it seems unfair that network sites get new Kermits for free whereas unconnected sites have to pay. But if you look at the situation a little more closely, I think you'll understand the policy. We're a university, not a business. Since the BYTE and EDUNET news articles were published, we've been sending out about 10 tapes PER DAY to sites all over the world, answering about 30 letters of inquiry daily, and the phone never stops ringing. Several systems programmers are putting in nearly full time hours as shipping clerks, and have to work extra hours in order to do their REAL jobs. What little money we take in from the distribution fee goes to pay for some part time clerks to help with the shipping, and for supplies like magnetic tape (no, you don't send us a tape, we supply the tape), mailers, printing, and postage. Now, why should network users get it free while unconnected sites pay? Well, first of all, network sites have made large investments in order to get connected -- after all, this is just the sort of thing that networks are for! Second, how would you want us to charge them? Networks just aren't set up for that. Third, it costs us little effort for a network site to drag new Kermit versions away by FTP, whereas it costs us A LOT of effort to make and mail a tape. The only special network-related work comes in updating the Kermit network distribution areas and running the Info-Kermit mailing list. But tape users benefit from this effort too, because they receive Info-Kermit mail on their tapes, along with everything else. In any case, without the network connection, many valuable additions to the Kermit collection would never have been made. A couple years ago, our policy was "send us a tape and return mailer and we'll send you Kermit". We had to give that up when the demand got so high that our offices were filled up with tapes and mailers, our mail room was in utter chaos, having to call Federal for this one, UPS for that one, explain to the post office that the postage meter sticker for this one with a San Francisco postmark really wasn't used already, etc etc, and there was no money to hire anyone to help do all this extra work. Now we have a uniform and relatively automated way of handling orders, with fairly rapid turnaround, and a mechanism for handling increased demand. Why not send automatic free updates? In less than two years, we've sent out nearly 800 Kermit tapes. If you keep up with Info-Kermit, you know that new releases or implementations appear a few times EACH WEEK. To send free updates, we'd have to send out tapes to some 800 sites several times a week, or else do massive database searches for who cares about what version, and make hundreds of custom tapes a week. The sad fact is that we're so swamped sending tapes and responding to inquiries that we haven't even been able to find the time to send a mailing to our "tape customers" letting them know about the new releases that are available. And if we had, we'd have even more orders to fill! Finally, you don't have to get Kermit from Columbia. Go to one of your neighbors, or to DECUS, SHARE, STUG, PC-SIG, etc etc, and get a tape or disk from them -- we submit Kermit to these user groups regularly for redistribution to their membership. But they'll charge you a nominal distribution fee just like we do, because time and materials don't cost them any less than they cost us, and you'll also find that they update their distribution files much less frequently than we do. ------------------------------ Date: Fri 27 Jul 84 11:41:25-EDT From: Robert C. McQueen <OC.MCQUEEN@CU20B> Subject: Problems loading Kermit-10 To: SY.FDC@CU20B It has been reported by several sites that they are having problems loading Kermit-10. The problem is multiply defined symbols loading the Galaxy library. To fix the problem people should use the CCL file in KER:. - Bob ------------------------------ Date: 25 Jul 1984 02:18:21-PDT From: cmf%case.csnet@csnet-relay.arpa To: cc.fdc@columbia-20.arpa Subject: UNIX Kermit Hello, What is the current status of UNIX Kermit? (I don't currently get INFO-KERMIT). Also, if it is possible, could I be added to the INFO-KERMIT mailing list? I don't have access to the DEC-20's over the summer. Thanks, Carl Fongheiser cmf%Case@CSnet-relay [Ed. We are presently cleaning up UNIX Kermit and adding a few minor features such as the ability to talk to IBM hosts. This version should be available fairly soon (we're in the debugging stage). A more advanced UNIX/C Kermit (written in LEX) with full server capablities has been started and will be available at a later date.] ------------------------------ Date: 26 Jul 1984 1537-PDT From: HAL.DOVE at Ames-VMSB Subject: Kermit for rsx11m+ To: cc.fdc at columbia-20 I took the kermit for rsx11m+ and have been having nothing but probs. I took the executable version over the source, for its ease. I got it into executable form with no problem. I tkb'ed it, and I did have a problem locating f4pots, even though it was there. The exact error was: --DIAG-- Error locating file F4POTS Something like that, so I ignored it, and got no undefined externals. I installed it, and right now it does not have the /ckp=no for the installation. I position myself on my pc running kermit, i get onto the rsx via remoting to it from a vax, so therefore I am on an ht#: line. I fire up kermit, the first thing I notice, it can not seem to find the time, SHOW TIME gives : "The time is ". I set the port to ti: which kermit then replies he is in remote mode now. I then tell him to "SEND FILE", get back to the pc kermit, type recieve, and it never responds. Could it be it can not do a delay since it can`t find the clock. If I set a recieve on the rsx kermit, and do a send down below, it always fails. Now one also notcies that you bang on any key while kermit it in receive mode, you get the nice mcr or dcl prompt depending what you are using. Is kermit listening on the wrong line, or is it just getting interrupted? Is that why the pc kermit fails, because it sends stuff up, and gets > or # as a reply. I hope I have given you enough information. Please reply to me directly here... Thanks Mike ------------------------------ Date: Fri 27 Jul 84 19:03:51-EDT From: Brian Nelson <OC.BRIAN@CU20B> Subject: the decnet thing To: sy.fdc@CU20B error locating f4pots? kermit-11 is macro, not fortran perhaps he tried to link k11hex.ftn and got a task build error. remote user's should use the node name for the file they want rather than to get layers deep into terminal emulation in decnet. since I can't possibly test decnet m+, this one will have to wait a response from someone who does have it. I never got around to the sho tim for rsx or rt. The problem is simple. Kermit-11, for rsx, never pays any attention to the device name, it ALWAYS uses either TT or TI. Thus, a set line HT2: would actually end up assigning TT2:. This will be fixed in the next release. For the time being, user's who have to use a HTnn: line can call me and get information on how to downline load a new RSX task image from one of my systems. The number is (419) 537-2841 brian [Ed. This response was culled from a number of letters from Brian. Thanks, Brian, for all the trouble you went to.] ------------------------------ Date: Fri 27 Jul 84 20:24:54-PDT From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: Kermit-MS To: cc.fdc@COLUMBIA-20.ARPA I'll be adding support for the NEC APC to Kermit-MS this weekend. We've all been waiting a long time for this release, as I know you have too. I haven't figured out a general way to boot Kermit on the APC either under CP/M-86 or MS-DOS. As a stopgap, if people will send a diskette and a stamped return envelope I will provide them with the source and object for either version. My address for this purpose is: Ron Blanford 4200 Aurora Ave. N. Seattle, WA 98103 (206) 632-0301 -- Ron ------------------------------ Date: Wed 25 Jul 84 14:28:26-PDT From: ALFIERI@USC-ECLB.ARPA Subject: SDS Kermit? To: cc.fdc@COLUMBIA-20.ARPA Frank: This is a stab in the dark, but do you know of anyone who may have developed even a kludged version of Kermit for the Scientific Data Systems (SDS) dedicated word processing system? (Ah, "SDS" reminds me of 1968 at Columbia!!!) We have a huge data base that needs to be transferred from the SDS to the IBM PC. As life would have it, SDS is now out of business, so we can't even call them up. Help! --vince alfieri alfieri@usc-eclb ------------------------------ Date: Mon 30 Jul 84 14:28:26-EDT From: CC.WBC3@COLUMBIA-20.ARPA Subject: Bug fix for new MSPCTRAN.BAS bootstrap program To: Info-Kermit@COLUMBIA-20.ARPA There is a bug in the new MS-Kermit .BOO file decoder. Line 400 should read 400 if len(x$) < 4 goto 300 rather than 400 if len(x$) = 0 goto 300 -Bill ------------------------------ End of Info-Kermit Digest ************************* ------- 2-Aug-84 12:38:46-EDT,7508;000000000000 Return-Path: <CC.DAPHNE@CUCS20> Received: from CUCS20 by CU20B with DECnet; 2 Aug 84 12:38:13 EDT Date: Thu 2 Aug 84 12:37:55-EDT From: Daphne Tzoar <CC.DAPHNE@CUCS20> Subject: Info-Kermit Digest V1 #20 To: Info-Kermit: ; Reply-To: info-kermit@columbia-20 Info-Kermit Digest Thursday, 2 August 1984 Volume 1 : Number 20 This week's editor: Daphne Tzoar Today's Topics: Problems with MSFILE (4 messages) Kermit-MS Status Line with ANSI.SYS Kermit for PC/IX Apollo errors Problem with UNIX Kermit and MS Kermit MSKERMIT (2 messages) ---------------------------------------------------------------------- Date: Tue, 31 Jul 84 13:27:38 EDT From: G B Reilly <reilly%udel-eecis3.delaware@udel-relay.ARPA> To: Info-Kermit@columbia-20.ARPA Subject: Re: Info-Kermit Digest V1 #19 I tried to compile the 'msfile.asm' from the latest distribution, and the following was the result: The Microsoft MACRO Assembler , Version 1.25 Copyright (C) Microsoft Corp 1981,82,83 00E2 8D 06 01B1 R lea ax,outbuf ; Where to put data when buffer gets full. E r r o r --- 57:Illegal size for item 0271 8D 1E 03AB R gtchr0: lea bx,inbuf E r r o r --- 57:Illegal size for item Warning Severe Errors Errors 0 2 Brendan Reilly ------------------------------ Date: Tue 31 Jul 84 20:14:00-MDT From: Carl Diegert <DIEGERT@SANDIA.ARPA> Subject: Problem in MS-Kermit MSFILE under MASM 1.25 To: info-kermit@COLUMBIA-20.ARPA cc: DIEGERT@SANDIA.ARPA, LINNEROOTH@SANDIA.ARPA Microsoft's MASM version 1.25 gobbled up all modules for IBM PC version MS Kermit EXCEPT for choking on two lines in MSFILE: lea ax,outbuf gtchr0: lea bx,inbuf with a "57:Illeagal size for item" (severe error). How about replacing these lines with mov ax,offset outbuf gtchr0: mov bx,offset inbuf ?? ------------------------------ Date: Tue 31 Jul 84 17:45:20-EDT From: Jeff Damens <US.JD%CU20B@COLUMBIA-20.ARPA> Subject: Re: [G B Reilly <reilly%udel-eecis3.delaware@udel-relay.ARPA>] To: CC.DAPHNE@CUCS20 inbuf and outbuf are declared as byte labels (not words)... I guess it's looking for a word address. We can just stick a "word ptr" in front of the operand. Maybe we should get a later version of the assembler. Jeff ------------------------------ From: lhasa!lotto@harvard.ARPA Date: 2 Aug 84 08:57 EDT To: harvard!info-kermit@columbia-20 Subject: MSFILE.ASM There is a minor bug in MSFILE.ASM. Please insert the line: mov cl,6 ; Adjust high order word for OR directly before the first (and only) shl instruction. Without this change, routines will wrap reports of Kb transferred from 63 to 1024. Jerry Lotto (lotto@harvard) [It's already been fixed but thanks for pointing out the error and supplying the solution. -ed] ------------------------------ Date: 31 Jul 84 14:57:03 EDT From: Peter Kanaitis <PK0P@CMU-CC-TD> To: Info-Kermit@CUCS20 Subject: Kermit-MS Status Line with ANSI.SYS Another thing I noticed about Kermit-MS V2.26 (IBM-PC version) is the send/receive status line. With the ANSI.SYS driver loaded, the line appears in normal video up to the end of the text, where the remaining part of the status line is in reverse video. With ANSI.SYS loaded, the entire send/receive status line is in reverse video. I'm guessing this is the way it should appear with the ANSI.SYS driver loaded. Peter Kanaitis PK0P@CMU-CC-TD ------------------------------ Date: 31 Jul 84 19:34:26 EDT From: DA2A@CMU-CC-TE To: info-kermit-request@CUCS20 Subject: Kermit for PC/IX I've quickly looked over some of the C sources for Kermit. Is there one that takes advantage of the features (crufts) of PX/IX? At the very least, it should have all the features of the latest version of the IBM-PC Kermit. If it could have server capability as well, my life would be complete. Thanks in advance, David Artman (DA2A@CMU-CC-TE) ------------------------------ Date: Tue 31 Jul 84 17:23:04-PDT From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA> Subject: Apollo errors To: info-kermit@COLUMBIA-20.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 I tried FTPing APOKERMIT.SRC twice. The FORTRAN code has errors. There are continuation statements following a commented line and other syntax errors in many of the subroutines. I think it needs to be reloaded. ------------------------------ Date: Tue, 31 Jul 84 20:27:11 cdt From: seung@ut-ngp.ARPA To: CC.DAPHNE@COLUMBIA-20.ARPA Subject: Re: mskermit [I don't have original message for the reply below but essentially it said that PC Kermit 1.20 worked with his UNIX version and MS Kermit 2.26 didn't. -ed] I figured out my problem. With version 1.2, I used the command % kermit sdlb ... This doesn't work with 2.26. I have to use the command % kermit slb ... Not that this is any great loss. The d is for debugging mode, which is of limited usefulness since the new mskermit has a debugging mode. Still, it's curious that this happens with UNIX Kermit. I do run mskermit with the timer off--at least the status information says the timer is off. What happens is that two packets are received, enough for the name of the file to be recorded on disk. Then, after six retries, mskermit quits, "unable to receive data." Sebastian ------------------------------ Date: 1 Aug 1984 15:57:37 PDT Subject: MSKERMIT From: Billy <BRACKENRIDGE@USC-ISIB.ARPA> To: info-kermit@COLUMBIA-20.ARPA The new MSKERMIT is really great! There are several problems however. If I abort a single file while receiving a series of files the disk gets messed up. This is because Kermit probably does not close and delete the aborted file before starting the next file. If this is indeed the problem the fix should be pretty simple. I know nobody does this, but it is supposed to be a MS-DOS or even IBM-PC standard to be able to BREAK from a program by use of the control break key. I find it best to hook the CTL-BREAK processing code to BIOS as opposed to DOS. Both provide for CTL-BREAK processing, While the BIOS level processing may not be as portable it can handle situations the DOS level can't. It is possible to hang any program and we have done it with a Kermit that we ran on a wierdly configured PC. I hate to have a CTL-ALT DEL reboot when CTL-Break would be more convenient. ------------------------------ Date: Thu 2 Aug 84 11:13:59-EDT From: Daphne Tzoar <CC.DAPHNE@COLUMBIA-20.ARPA> Subject: Re: MSKERMIT To: BRACKENRIDGE@USC-ISIB.ARPA cc: info-kermit@COLUMBIA-20.ARPA How did you abort the incoming file? If you type ^X or ^Z Kermit closes and deletes the file (unless you did a SET INCOMPLETE KEEP in which case whatever portion of the file that made it over is kept). Checking for ^C was also added to the new version. If someone typed ^C to stop the transfer, we didn't want them abruptly returned to DOS. Typing ^C will return you to the Kermit prompt and if you really want to get to DOS, you can EXIT Kermit. /daphne ------------------------------ End of Info-Kermit Digest ************************* ------- 7-Aug-84 19:24:35-EDT,13788;000000000000 Return-Path: <CC.DAPHNE@COLUMBIA-20.ARPA> Received: from COLUMBIA-20.ARPA by CU20B.ARPA with TCP; Tue 7 Aug 84 19:24:15-EDT Date: Tue 7 Aug 84 19:23:04-EDT From: Daphne Tzoar <CC.DAPHNE@COLUMBIA-20.ARPA> Subject: Info-Kermit Digest V1 #21 To: Info-Kermit: ; Reply-To: info-kermit@columbia-20 Info-Kermit Digest Tuesday, 7 August 1984 Volume 1 : Number 21 This week's editor: Daphne Tzoar Today's Topics: Mackermit Bugs with Apollo Kermit Problems with TRS-80 Kermit... SWITCHAR in MS-DOS Kermit (4 messages) Kermit and Debug: They won't work together.. CPMBASE needs revising for more micros Perkin-Elmer kermit ? Internal modems Apple-kermit 10 Kermit ---------------------------------------------------------------------- Date: Fri, 3 Aug 84 13:18:04 edt From: engel@harvard.ARPA (Stephen Engel) To: CC.FDC@COLUMBIA-20 Subject: Mackermit I have a working version of kermit for the macintosh. It is an adapted version of the UNIX kermit, and can be compiled and run using the SUMACC package. I have tested it against UNIX kermit and a VMS one, and the file transfer appears to work fine. A few bugs remain in the terminal part though, most notably its bombing upon typeing large amounts (more than 3 or 4 screenfulls) of text. I would be happy to mail it to info-kermit, if you could advise me on what format to provide the material. Steve (engel@harvard) [We received the version for the Macintosh and will be testing it. If all goes well, we'll release it some time next week. Thanks to Steve!! -ed] ------------------------------ Date: Tue 7 Aug 84 17:58:56-EDT From: Daphne Tzoar <Sy.Daphne@CU20B> Subject: Bugs with Apollo Kermit To: info-kermit@CUCS20 We received a new tape from the author and will start distributing the corrected version as soon as I can get it to the DEC-20. /daphne ------------------------------ Date: 29 Jul 84 21:41:39 EDT From: Brian <SIETZ@RU-GREEN.ARPA> Subject: Problems with TRS-80 Kermit... To: info-kermit@COLUMBIA-20.ARPA cc: sietz@RU-GREEN.ARPA Home: 212 Massachusetts Ave. Cherry Hill, NJ. (609) 428-1201 Work: RCA Corp. Borton Landing Rd. Moorestown, NJ. (609) 778-6163 These are not necessarily things wrong with the code, just things wrong with the distribution of it. Let me start at the beginning... First, I downloaded the basic program (TRSMAKE.BAS) using kermit to my Rainbow, then using a non protocall transfer program to get it to my TRS-80. The program is rather clever in that it computes a checksum, however running the program on the TRS-80 and my Rainbow show the same (wrong) checksum! Also, there is a commented out line (250). Thinking that I had a bad version on my Rainbow, I uploaded the file back to the DEC-20 only to find them to be the same! The next obvious thing to try is to compile it from the sources. There are seven files on the distribution for the TRS kermit program (the main program and six modules). It turns out that there are supposed to be eight source files because the main program includes seven of them - COMND/SRC is missing! Now come on guys - I can't believe the amount of carelessness! I have downloaded five different version of Kermit with no problems before - why start now? Very dissapointed, Brian Sietz [ Stan - Could you send us the missing file and another copy of TRSMAKE.BAS? -ed] ------------------------------ Date: 2 Aug 1984 2321-EDT From: Larry Campbell <LCAMPBELL at DEC-MARLBORO> To: Info-Kermit at COLUMBIA-20 Subject: New MS-DOS KERMIT MS-DOS KERMIT does not behave well if you set SWITCHAR=- in your CONFIG.SYS. Now, I understand why it can't fork commands (so none of the LOCAL xxx commands work, and PUSH doesn't work), but it also doesn't accept pathnames with either forward or backward slashes. 1) Is it supposed to support pathnames? 2) Please support SWITCHAR... Since I develop software that runs under both Unix and MS-DOS, it makes my life a lot easier if I can run with SWITCHAR=- ... - Larry Campbell ------------------------------ Date: Fri 3 Aug 84 14:57:10-EDT From: Jeff Damens <US.JD@CU20B.ARPA> Subject: SWITCHAR in MS-DOS Kermit To: lcampbell@DEC-MARLBORO.ARPA I did try to handle SWITCHAR... The problem I ran into is that there isn't any way (that I know of) to get the path separator character from DOS. You can obtain the switchar, but I wasn't sure about the relationship between switchar and the path separator. Empirically, it seems that if you set switchar to - (or anything else but /) then both forward and backward slash are taken as path separators. Do you think that Kermit should accept either slash when switchar is something other than dash? Is there some way to read the path separator? Am I missing something here? Jeff ------------------------------ Date: 3 Aug 1984 2027-PDT From: mike@LOGICON.ARPA Subject: V2.26 MSKERMIT problem To: .note: cc: mike@logicon I have a PC/XT system running DOS v2.10 and I have noticed a VERY interesting problem. Since installation of the new version, I could never get the file MSKERMIT.INI to be successfully read. Oh yes, it did always seem to try but it never executed any of the commands. Another interesting item is that I could not get the 'DIRECTORY' command to work. After a couple of hours of experimenting with different operating systems (v2.00 and v2.10), I discovered the problem. It seems that there is some problem related with the setting of the PATH environment variable. For MSKERMIT to successfully read and execute all commands in the MSKERMIT.INI file, the PATH variable MUST include the current directory for initialization to work. This is nothing harder than putting a ';.' at the end of your declarations. However, it also seems that MSKERMIT only searches the ROOT directory of a given disk for the DIRECTORY command and completely ignores the PATH specification. I have all my system binaries stuck in a subdirectory and I guess this version of Kermit cannot handle that situation at present. A final note, I tried this utilizing '\' directory seperators (standard SWCHAR setting) and '/' directory seperators (SWCHAR = -) and they work identically. However, I have not looked through the code, but Kermit I hope that Kermit would be smart enough to allow UNIX style filenames. Mike Parker {alias mike@LOGICON} ------------------------------ Date: Mon 6 Aug 84 22:40:11-EDT From: Jeff Damens <US.JD%CU20B@COLUMBIA> Subject: Re: [mike@LOGICON.ARPA: V2.26 MSKERMIT problem] To: CC.DAPHNE@COLUMBIA-20.ARPA, mike@LOGICON.ARPA Kermit searches the directories in the current PATH environment variable when looking for the MSKERMIT.INI file, or when looking for a file in the TAKE and RUN commands (this is documented in the MSKermit Manual, under the TAKE and RUN commands). If the PATH is empty, or the file isn't found in one of the PATH directories, the default (connected) directory is tried. To use the PUSH and DIRECTORY commands (under DOS 2.0 and higher), Kermit tries to EXEC COMMAND.COM. To find COMMAND.COM, it looks at the COMSPEC environment variable. If you put COMMAND in some other directory, you must change COMSPEC to reflect this; give the command "set COMSPEC=\foo\command.com" The present version of MSKermit only accepts backward slash as the directory delimiter at present; this is definitely a deficiency, and will be fixed, hopefully this week. Jeff ------------------------------ Date: Mon 6 Aug 84 18:22:56-PDT From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA> Subject: New MSDOS Kermits To: info-kermit@COLUMBIA-20.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 The version 2 Kermit for the IBMPC is very good. I like the save and restore of the screen during file transfers. It meets the objection I had to unsolicited screen clears. There seem to be a problem with the WANG-PC version. It doesn't run at all under DOS 2. Is it supposed to? [ Kermit for the Wang was developed under MS-DOS version 2.01. Does anyone know what features were added? -ed] ------------------------------ Date: Fri, 3 Aug 84 10:54:43 mdt From: brownc@utah-cs (Eric C. Brown) To: info-kermit@columbia-20 Subject: Kermit and Debug: They won't work together.. I was attempting to bring up Kermit V. 2.26 on a Zenith Z-100 when I found a truly wonderful bug. DEBUG (at least the 2.0 version) breaks the Kermit command processor. When Kermit is run without the debugger, the command processor works fine. When Kermit is run under DEBUG, the command processor will no longer accept commands. All it will do is print ?Illegal command and nothing else. I believe that what is happening is that the code around cmky2x is being trashed (discovered by tracing through the command processor). So. Does anyone have a working version of DEBUG, and if not, does anybody know of a debugger that will debug Kermit?? Thanks, Eric C. Brown brownc@utah-cs ..!harpo!utah-cs!brownc Hacking.. It's not just a job, it's an obsession. [ Does that mean MS Kermit v2.26 works with the Z100 -- we couldn't test the new version since we have no such animal. -ed] ------------------------------ Date: Fri 3 Aug 84 11:14:46-PDT From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA> Subject: CPMBASE needs revising for more micros To: info-kermit@COLUMBIA-20.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 KERMIT versions currently exist for about 21 different micros. There are versions of MODEM for about 79 different micro systems. The MODEM people learned a long time ago that it is a good idea to put system dependent code in a separate overlay and keep the main program separate. The first instruction is a jump over the overlay code and the main program calls fixed locations in the overlay for all versions to perform functions such as send a character to the modem, etc. It is easy to support a new system by writing the small overlay and linking it into the main program. This scheme is also used by the recent MEX program which even will work with the same overlays used with MODEM7xx. I looked at CPMBASE.ASM to see what what be involved in supporting some of our in-house micro systems. It is a MESS. There is hardware dependent code scattered thruout and parochial comments such as "only ROBIN can send a break" which is untrue. I just did a rough edit to remove hardware specific code from CPMBASE and found I removed 30% of the source lines. I know the people who are presently running on a micro are happy, but there are three times as many micro systems that COULD run KERMIT and the present arrangement will become absolutely unmanageable. I would like to suggest that the next major revision of the micro code follow the lead set by the MODEM people and remove all of the hardware dependencies to a separate front overlay. Ted Shapin. [Some ambitious soul had volunteered to break up CP/M Kermit but hasn't done so yet. -ed] ------------------------------ Date: Fri, 3 Aug 84 10:07 MDT From: JFisher@DENVER.ARPA Subject: Perkin-Elmer kermit ? To: info-kermit@COLUMBIA-20.ARPA I am in need of a kermit for the Perkin-Elmer Model 3200-MPS, operating under OS 7.2 . Languages available on it are CAL (assembler), Fortran (and Cobol). Is there such a thing available or in progress, to your knowledge ? ------------------------------ From: ihnp4!sask!derek@Berkeley Date: 2 Aug 84 23:08:22 CDT (Thu) To: info-kermit@columbia-20.ARPA Subject: Internal modems What is the story on internal modems. I know that Kermit has some trouble in using them in the IBM-PC and am curious why. Derek Andrew, U of Saskatchewan, sask!derek ------------------------------ Date: Mon, 6 Aug 84 21:43:14 CDT From: Stan Barber <sob@rice.ARPA> To: info-kermit@columbia-20.ARPA Subject: apple-kermit Cc: oc.mione@cu20b.ARPA, oc.trei@cu20b.ARPA, sob@rice.ARPA, stan@rice.ARPA Some more comments on proceedure to get KERMIT-65 to work. I had to change APPLEBT.BAS line 203 to the following to get it to work. 202 GET A$:L$=L$+A$:Y2%=Y2%+1:IF A$<>CHR$(13) THEN 202 Otherwise, it all worked just fine. I even used my TRS-80 to boot it on my apple. If anyone is interested in how I did it, let me know here or in a message to me on the sobbs test board at (713) 660-9252 Stan Barber Rice University ------------------------------ Date: 6 Aug 84 22:20:08 EDT From: *Hobbit* <AWalker@RUTGERS.ARPA> Subject: 10 Kermit To: info-kermit@COLUMBIA-20.ARPA cc: AWalker@RUTGERS.ARPA Yow, have you guys hacked up Kermit to do things while logged out??? If so, what does/can it do in that state? _H* ----------------------- From: Nick Bush <OC.BUSH%CU20B@COLUMBIA-20.ARPA> Subject: Problems with Kermit-10 receive command ... 2)41 C$EXI0: SKIPN LOGDIN ;[125] Are we logged in? 2) JRST [$TEXT (,<.KJOB^M^J.^A>) ;[125] No, make a nice msg 2) LOGOUT 1, ;[125] And quit 2) JRST .+1] ;[125] Shouldn't get here... 2) $HALT ; Exit to the monitor 2) $RETT ; Allow continues ------------------------------ End of Info-Kermit Digest ************************* ------- 17-Aug-84 15:12:59-EDT,14566;000000000000 Return-Path: <CC.DAPHNE@COLUMBIA-20.ARPA> Received: from COLUMBIA-20.ARPA by CU20B.ARPA with TCP; Fri 17 Aug 84 15:11:44-EDT Date: Fri 17 Aug 84 15:11:26-EDT From: Daphne Tzoar <CC.DAPHNE@COLUMBIA-20.ARPA> Subject: Info-Kermit Digest V1 #22 To: Info-Kermit: ; Reply-To: to Info-Kermit@columbia-20 Info-Kermit Digest Friday, 17 August 1984 Volume 1 : Number 22 This week's editor: Daphne Tzoar Today's Topics: Kermit for PC/IX New version of CP/M Kermit MSKermit for APC New version of Kermit Bug in version 2.26 receive SWITCHAR and directories Problem with MSKERMIT MS-DOS Kermit Wanted: Kermit for the Kaypro 4 with built in modem Osborne-1 kermit and the Comm-Pac (internal) modem ---------------------------------------------------------------------- Date: Tue 14 Aug 84 17:40:37-PDT From: Herm Fischer <HFISCHER@USC-ECLB.ARPA> Subject: Kermit for PC/IX; works with connect To: info-ibmpc@USC-ISIB.ARPA, info-kermit@COLUMBIA-20.ARPA cc: hfischer@USC-ECLB.ARPA I have modified the latest "kermit.c" as distributed by Columbia University: - It now has conditional compilations for Unix System III, (which includes PC/IX), and TALKER options for interactive features in the connected state and for cooperation with PC/IX's connect facilities. - Its "connect" state allows interactively "escaping" and (without exiting kermit): Entering receive state, sending specified files, asking for reassurance, executing shell commands, quitting/disconnecting, getting a help menu, and sending the escape character itself. - It can be loaded and run from a shell as usual with the unix kermits - It can work as a "talker" for the connect command, which then properly sets up and clears lock files, uses connect's autodialers, etc, and prevents uucp from crashing onto kermit's port. As a talker, you just say "connect talker=kermit somehost" or put the talker=kermit line into connect.con. - When using kermit as connect's talker, you get vt100 screen cursor controls (see PC/IX display(4) man page) minus line insert/delete. (Connect's default talker, "atalk", gives you NO cursor emulation.) - Kermit also works as a "network" program under connect. When connecting using the default talker, if you decide to send/receive a file, enter ^Vu^M rkermit s myfile to send, or ^Vu^M rkermit r to enter kermit's receive state. The r command automatically tells kermit which line to use. This new kermit is in my directory on eclb, <HFischer>kermit.c. When I get to it, I will also provide a man page and some instructions, in files which will also begin with the name kermit. Herm Fischer [Herm, let me know when it's ready for us to copy over. -ed] ------------------------------ Date: 7 Aug 1984 19:11 PDT From: Charles Carvalho <CHARLES@ACC> Subject: I'm not dead yet! To: CC.DAPHNE@COLUMBIA-20 Cc: CHARLES@ACC Reply-To: CHARLES@ACC Hello... I'm the latest (no, make that "most recent") ambitious soul working on CP/M Kermit, and it looks like a progress report is in order. The long-awaited modular Kermit-80 does exist, and is currently in beta test. (I sent a note to Frank, but it seems I just missed him). Unfortunately, we don't provide FTP server access, but I can mail you a copy if you have some victims (er, test subjects). Do you have an extra-large mailbox available? Sources and documentation total ~270Kbytes. /Charles some changes (not all mine; see [credits]): . Modularized (but you knew that already...) . May be assembled with LASM (aka LINKASM), as well as M80 and MAC80. I've tested M80 and LASM, but don't have a DEC-10 or -20 to test MAC80 on. . Disk space calculated correctly for CP/M 3 systems. [Bruce Tanner] . "break" capability added for Kaypro and BigBoard II. . TACtrap added for running through ARPA/MILnet TACs [David Kirschbaum at Toad Hall] . SET DEBUG command added to display packets sent/received . VT52 emulation improved . SET PORT supported under generic CP/M 2.2 (6, count'em, 6 ports!) [Ronald Blanford] . "Fuzzy" timer support generalized for all systems . New systems: Cal-Tex/Ferguson BigBoard II, Apple II with 6551 ACIA (Apple Super Serial Card, Videx PSIO) [Jon Beeson, Francis Wilson] Morrow Decision I [Toad Hall] . New terminals: VT52, VT100 . TRANSMIT command fixed (I think) . Fixed a couple of bugs in protocol module. [ We've got it. We'll get back to y'all after we test it. -ed] ------------------------------ Date: Tue 7 Aug 84 20:51:35-PDT From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: MSKermit for APC To: cc.daphne@COLUMBIA-20.ARPA cc: context@WASHINGTON.ARPA I've finished the system-dependent part of MSKermit for the NEC APC. If you are handling distribution now, the source file is available for anonymous ftp from my account, and is called MSXAPC.ASM. The executable code is in MSAPC.EXE, and a brief help file specific to the APC is in MSAPC.HLP. I also found one bug in (I guess) the documentation to the effect that the POSCUR routine must not trash register SI. It messes up file reception if it does. -- Ron [We'll get a hold of this version too. -ed] ------------------------------ Date: 8 Aug 1984 13:56-EDT Subject: New version of Kermit From: HARDY@USC-ISI.ARPA To: info-kermit@COLUMBIA-20.ARPA Cc: hardy@USC-ISI.ARPA Mike Seyfrit from Polaris ported a version of kermit for DARPA to use on its' IBM-PCs. What is the differance between the new and last version of Kermit. Also, please add my name to info-kermit since Mike now works for someone else. Rich. ^ ^ 0 0 > \-/ ------------------------------ Date: Wed 8 Aug 84 00:41:37-PDT From: Michael A. Haberler <HABERLER@SU-SIERRA.ARPA> Subject: Bug in version 2.26 receive To: info-kermit@COLUMBIA-20.ARPA When I try to download a file from a host with the receive command, sometimes Kermit seems to hang. It will <not> show the filename on the screen, as usual during transfer; it seems to do nothing, but can be aborted by Control-C. When I exit to DOS and try version 1, things work fine (same connection/server). Does anybody have a fix for that? The host is SU-Sierra, a Tops-20 machine. However, the problem seems to be in Kermit; as I said, it <always> works with the old version after 2.26 failed. I'll try to get a more exact picture of the problem and let you know. Send always works. I use a vanilla IBM PC with the Hayes Smartmodem card. Sincerely, Michael ------------------------------ Date: Thu, 9 Aug 84 08:11:07 mdt From: brownc@utah-cs (Eric C. Brown) To: info-kermit@columbia-20 Subject: SWITCHAR and directories According to my pre-release copy of the ms-dos progammer's manual, the path separator can be either forward slash or back slash; the OS doesn't care. However, if the switchar is /, then most programs must parse / as a switch and \ as the only directory separator. If the switchar is not /, then either / or \ should be accepted as directory separators. Eric C. Brown brownc@utah-cs ..!harpo!utah-cs!brownc ------------------------------ Date: 9 Aug 84 11:06:38 EDT From: PK0P@CMU-CC-TD To: CC.DAPHNE@CUCS20 Subject: Problem with MSKERMIT This may have gotten lost over the net, so I'm sending it again... While testing out the new Kermit-MS, I found the following bug: C>kermit ;Get into Kermit IBM-PC Kermit-MS V2.26 Type ? for help Kermit-MS>Set Bau<ESC><ESC>? ;Type "SET BAU" followed by an escape ;The "D " will print. Type another escape, ;The bell will ring, signifying that the ;command has no more defaults. Type a ;question mark at this point ? One of the following: ;lists the options ?Program error Invalid COMND call ;plus some unreadable characters are echoed. I've noticed similar occurrences with the DO command, and SET HEATH19-EMULATION. On a second note, has the control-R facility been removed from version 2.26? Peter Kanaitis (PK0P@CMU-CC-TD) Allegheny General Hospital Pittsburgh, Pennsylvania [ It's been fixed but thanks for pointing it out -- we accidentally trashed a register. -ed] ------------------------------ Date: Wed 15 Aug 84 18:35:29-PDT From: Bruce Tanner <CERRITOS@USC-ECL.ARPA> Subject: MS-DOS Kermit To: info-kermit@COLUMBIA-20.ARPA We've just gotten MS-DOS Kermit version 2.26 for the Rainbow. We can communicate over the comm port just fine, but file transmission fails on the first packet to both Kermit-10 and Kermit-20. Is there a problem with this version of Kermit, or is it just us? -Bruce ------------------------------ Date: Fri, 10 Aug 84 09:12:03 CDT From: Stephen M. Padgett <smp@ut-ngp.ARPA> To: info-kermit@columbia-20 Subject: Wanted: Kermit for the Kaypro 4 with built in modem A friend would like a copy of Kermit for the Kaypro 4 with the built in modem. Has anyone modified the Kaypro version to talk to the built in modem? Please send mail to me, as I get the mailing list indirectly. Thanks! --Steve Padgett smp@ut-ngp ------------------------------ Date: Fri, 17 Aug 84 13:03 EDT From: "John C. Klensin" <Klensin@MIT-MULTICS.ARPA> Subject: Osborne-1 kermit and the Comm-Pac (internal) modem To: info-kermit@COLUMBIA-20.ARPA Since we do not have the facilities to reassemble CP/M-80 kermit (source too big to fit on the machine), but have succeeded in getting it to work with the internal modem, I thought it might be useful to pass the kludge along for others with these unfortunate modems. For anyone contemplating doing this right, or for anyone speculating about the operation of the Ozzie, the bits that go to the "modem port" are the same as those that go out the RS232C port. Note "the same": port selection is meaningless, as these are, in essence, wired in parallel (the voltages differ, but who cares). The modem is dialed by connecting and disconnecting it in a timing loop -- the equivalent to dialing a standard telephone by pushing on the hangup button with the right timing pattern. The internal (Comm-Pac) modem is "connected" by turning the DTR line on and disconnected by turning it off (more on that later). In the interim, use the following strategy: a) Use AMCALL (the software that comes with the modem) or something equivalent to initialize the UART and dial the telephone. b) Escape from AMCALL (or whatever) to CP/M without disconnecting. For AMCALL, this is done by the sequence ESC-Z. c) Run Osborne kermit, modified as indicated below. Now, Osborne kermit will work fine, except that it tries to initialize the UART, and the initializing process drops DTR and, consequently, hangs up the modem--a bad idea. But the port is already initialized, so bypassing that code works fine. If one can assemble generic CP/M-80 kermit, find the STA instruction about two statements after OSSTST (about line 6691) and get rid of it. If not, use DDT to convert the three locations starting at 2C31h to NOPs. And, presto, a version of Osborne kermit that works with the Comm-Pac. Note that, when you exit Osborne kermit, it de-initializes the port, resulting in hanging up the phone. You don't need to go back to AMCALL or manually disconnect. It is possible to construct a SUBMIT file that will walk through this process from invocation of AMCALL to having kermit connected; if it is not obvious to anyone who cares, let me know and I will forward a copy to the net. Things that will get done when either CP/M-80 kermit is restructured and becomes small enough to fit or we discover an appropriate machine and copy of MAC80: - Making this generate breaks. This will definitely work for the Comm-Pac; it looks from the drawings and the technical manual as if it will work for the RS232C also, but we will have to see experimentally. - Making it dial directly, avoiding the kludge. This exercise has pointed out two things about Kermit implementations in general, and CP/M-80 kermit in particular, that probably deserve some priority. 1) As implementations of the various descendants of Multics (and Multics itself), with their case-sensitive file system names proliferate, it is very important that versions of kermit running on systems that cannot cope with lower-case names translate those names into upper case before storing them. With CP/M-80 kermit at present, lower case names are stored in the file system but, since the CCP maps everything that is typed to it to upper case, it is very difficult to use, rename, or get rid of such files. As I read the protocol manual, this problem is a bug and should be fixed; versions of kermit that support operating systems that do case mapping in their command systems, but are internally case sensitive, should be checked for this problem also. 2) The kludge above points out something that has, I think, been discussed before, which is that it would be very advantageous to provide the various micro-kermits with - an exit/quit command that does not de-initialize the port. In the general case, this is required to access commands in the micro's operating system without dropping the line (although some modems are smart enough (or dumb enough) not to hang themselves up when DTR goes off). - some sort of command-line argument ("command tail") that would disable attempts to initialize the port. In the general case, this is probably needed to permit getting back to kermit after suspending it without disconnecting as above. It is also needed for cases like this one, where two communications programs are being used in the same connection and the second one should not undo what the first one has done. ------------------------------ End of Info-Kermit Digest ************************* ------- 5-Sep-84 18:25:22-EDT,26409;000000000000 Mail-From: SY.FDC created at 5-Sep-84 18:24:58 Date: Wed 5 Sep 84 18:24:58-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #23 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Wednesday, 5 September 1984 Volume 1 : Number 23 Today's Topics: Info-Kermit Moving to a New Host Unix Kermit (Several Messages) New Unix Kermit MS-DOS Kermit 2.26 Works on Compaq Problem with MS-DOS Kermit Text Upload and Auto LF in MS-DOS Kermit New Kermit Implementation in LISP Cray Kermit Progress Report Attribute Packets Kermit Over Telenet? Use of Kermit in Commercial Products DEC-20 Kermit Control Character Interference TRS-80 Kermit Author Moves Apple CP/M and DOS Kermit? Kermit to TOPS-20 over TAC? ---------------------------------------------------------------------- Date: Wed, 5 Sep 84 17:00:00-EDT From: Frank da Cruz <SY.FDC@CU20B> To: Info-Kermit Subject: Info-Kermit Moving to a New Host Hi everyone, I'm back from vacation. Thanks to Daphne and Bill for running Info-Kermit while I was away. Kermit is maintained and distributed by the Columbia University Center for Computing Activities (i.e. Computer Center), an entity distinct from the Columbia Computer Science Department. The CS department has graciously acted as host for Internet Kermit distribution this past year, including maintaining a very large file archive and handling all the Info-Kermit and other Kermit-related mail. One of the DEC-20s at the Computer Center, CU20B, is now connected to the Internet, and so it is no longer necessary to burden the CS DEC-20 with our mail and file transfer traffic. As a first step in the transition, I'm moving the mailing list from COLUMBIA-20 to CU20B. Mail to Info-Kermit or Info-Kermit-Request should now be directed to CU20B (or, if your host does not yet know about CU20B, which was entered in the NIC host tables last month, then to %CU20B@COLUMBIA). Such mail sent to COLUMBIA-20 will be routed automatically to CU20B during the transition period. Over the next few weeks, we'll be moving the Kermit file archive to CU20B, so please check with your system manager to make sure CU20B is known to your host for both mail and FTP purposes. CU20B's Internet host number is [192.5.43.128] (this may change at some time in the future). Don't worry about file transfer yet, but please try to use the new host when sending mail -- one of the following formats should work: Info-Kermit@CU20B Info-Kermit%CU20B@COLUMBIA Info-Kermit@[192.5.43.128] Sorry for any confusion this might cause, and many thanks to the Columbia CS Department for putting us up (and up with us) this past year. - Frank ------------------------------ Date: Mon, 3 Sep 84 13:42:14 pdt From: jak%ucbopal.CC@Berkeley ( Nhoj Eznuk ) To: info-kermit@columbia-20 Subject: Unix Kermit at UC Berkeley On our Computer Science Department and Computer Center machines we are running your version of Unix Kermit with modifications we would like to see incorporated into Columbia's next release. The "diff" file below has comments indicating the scope of the changes; the file itself specifies all the changes. The actual C source follows under separate cover. John Kunze [Ed. - "diff" file omitted. See below.] ------------------------------ Date: Wed, 5 Sep 84 00:28:31 cdt From: Perry Emrath <emrath%uiucdcsb%uiuc.csnet@csnet-relay.arpa> To: cc.fdc@columbia-20.arpa Subject: unix kermit Hello, my name is Perry Emrath. I am a research professor at the University of Illinois. Earlier this summer, I obtained a copy of Kermit for unix from Lee Hollaar at the University of Utah. I wrote my own version for a pdp-11 which is running a home grown operating system that I wrote. I have made some changes to the unix kermit and plan to make a few more. Reasons are given in the following list describing the changes. I would like to know if you are interested in these changes or if somebody else has already done (or is doing) something similar. 1) Read into a buffer of 100 bytes instead of 1 byte at a time. For a file of 18k bytes, it now uses cpu times of .8 seconds user and 3.5 system, whereas it used to use something like 2.0-2.8 user and 20.0-28.0 system. This works out to about 250 CPU microseconds per byte, instead of 1+ milliseconds, and is now acceptable for a 9600 baud line, which is what we're using. Even when the system is somewhat busy, it achieves 450-500 data chars per second using 10-15% of the CPU. I have yet to add such a buffer in the connect mode routine. 2) When kermit executes as a remote, get the terminal's interrupt char, and if this is received, exit. This way, you don't have to wait for it to time out or go to another terminal to kill it. 3) The receive routine returns an error message if the file exists. I prefer "no clobber". 4) IBM-CMS support. Sending stuff between our pdp-11, vaxen (4.2bsd), a Cyber 175, and ibm equipment was the main reason for obtaining kermit. It appears that the only distinctions for the IBM version are to wait for a ^Q and handle even parity. I have the cms version, but we haven't gotten it assembled yet. 5) Ability to use the send and receive routines from inside the connect routine, somewhat like the other kermits. This is important for us, because we want to use a local resource allocation program that can allocate lines to remote machines, can handle groups of lines to the same machine in a "rotary" fashion. Once you connect to somewhere, you don't want to exit kermit to do a send or receive, thereby freeing the line. We already have a local connect program, and I would make kermit look just like it with two new commands for sending and receiving files. 6) Other minor bug fixes and changes. Numbers 1, 2, and 3 are already done and I am about to start working on 5 and 4. Kermit has generated a lot of interest here and a number of different groups are looking to start using it. I was out to Utah during my vacation in August and Lee helped me grab a bunch of versions from Columbia via the Arpanet and write them on a tape. I have two other questions: 1) Since flushing the input buffer before starting is very useful (based on my experience with my pdp-11 version), I thought it would make sense to have the "receiver" flush the buffer and immediately send a NAK, rather than remaining passive. Then, no matter which direction you're going, things would start up right away instead of waiting until a time out. Is there any problem with this idea? 2) Why was ^A selected instead of a printing character as the start-of-packet character? (I don't really expect an answer, it clearly can't be changed now.) The entire kermit protocol seems oriented toward systems that can only work in a "cooked" mode, like the cyber. I in fact keep my pdp-11 in line mode and it works fine, but I had to change the OS because ^A used to mean something and didn't come through. Oh well, I guess you need raw mode for talking to the ibm anyway, in order to pick up the ^Q. Except for that, though, using a "cooked" line mode seems possible and more efficient. Thanks much, Perry Emrath ...{ihnp4|pur-ee}!uiucdcs!emrath DCS, U of IL emrath.uiuc@csnet ------------------------------ Date: Wed 5 Sep 84 12:44:01-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: Re: Unix Kermit To: emrath%uiucdcsb%uiuc.csnet@CSNET-RELAY.ARPA Hi, thanks for the note. You're about the 50th person to make these and similar changes to Unix Kermit. A couple months ago, we tried to notify the network community that we would be working on an upgrade of the program ourselves and everyone else should hold off for a while, but the contributions continue to pour in... The buffered reads are a good idea, and we'll probably do something along those lines because performance is becoming increasingly important to us. There should also be an option to specify how to handle filename conflicts. We have IBM VM/CMS support already working in Unix Kermit (XON line turnaround, use of selected parity). See below... Eventually Unix Kermit will have a command parser, so that once started it can do repeated commands (send, connect, get, etc) without having to be restarted. The only problem with having the receiver send a NAK immediately is that if it's remote, the user will not have had enough time to escape back to the local Kermit and start it sending, and the NAK will appear on the user's screen. This is disconcerting to users who don't know what it is. If the receiver is local, then it can send a NAK for packet 0 immediately, and that may or may not wake up the sender, depending on the mechanism it uses for delaying transmission of the first packet. Kermit data can include any printing character, and Kermit packets include ONLY printing characters. A distinguished character is needed to mark the beginning of the packet. Control-A was chosen for various reasons (it's the ASCII "start of header" character, and most systems accept it as input, even in "cooked mode"). The protocol manual and BYTE article explain this more detail. If your system won't pass the Control-A through to the program, than you can use some other non-printing character. Many Kermits have commands to redefine the start-of-packet character. - Frank ------------------------------ Date: Wed, 5 Sep 84 11:03:28 EDT From: Edward Haines <haines@BBNCCI.ARPA> Subject: Automating Kermit transfers To: cc.fdc @ columbia-20.arpa Cc: haines@BBNCCI.ARPA Frank: We are interested in running Kermit transactions from a batch file (or a program) on an IBM PC talking to a Unix host. We need to be able to issue Unix commands such as 'kermit r' and then local Kermit-MS commands such as 'send \etmail\'. Do you know of any way to do this with any available version of Kermit for the IBM PC? It is easy enough to put the local commands in the batch file but I haven't been able to issue terminal mode commands or exit back to local mode with the new Kermit-MS. [Ed. - You can write a program in your favorite language to issue the desired commands to Unix from the PC, and use the Kermit-MS "RUN" command to execute it. Then, using the new long "command tails" or TAKE files (or any combination thereof), you can write batch files to make Kermit do whatever you like.] Is there a useable version of a Kermit Server for Unix? [Ed. - There will be soon; see below.] Is there any version of Kermit for the IBM PC in a higher level language such as C or Pascal? [Ed. - No, but the C or one of the Pascal versions could probably be adapted. But why bother?] What we really want to do is to transfer a set of files in each direction between the PC and the Unix host and to do a few related Unix commands without any interaction from the user ... something that could be made into a deamon process once we get multitasking in PC-DOS. [Ed. - I think this will all work pretty soon.] Thanks for all you have done so far; Kermit is alive and well. Ted Haines ------------------------------ Date: Wed 5 Sep 84 14:164:01-EDT From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA> Subject: New Unix Kermit To: Info-Kermit A new version of Unix Kermit is available. This is not the totally souped-up version everyone would like to have, but an interim release to bring some more systems into the fold while we continue work on the more ambitious version. Here is what's new: . Parity options (None, Odd, Even, Mark, Space) (-p) . Line turnaround handshake option (XON) (-t) . Half duplex terminal operation (-h) These three items allow the program to communicate with IBM and similar mainframes. Also, various small bugs or problems have been fixed. In addition, work has begun on decomposing the program into modules (there's still a long way to go). In this release, the system-dependent i/o and terminal emulation code has been separated out into special modules for: . Unix (most systems) . VAX/VMS (remote only, no terminal emulation) . Venix on the DEC Pro-350 All the other features which people have asked for (or sent us) have yet to be incorporated into the new LEX-based version we're working on. The new release, and the continuing development, are being done at Columbia by Bill Catchings and Jeff Damens. The new files are in KER:UX*.* on COLUMBIA-20 or CU20B, available via anonymous FTP after 6pm eastern time. The comments at the head of UXKERMIT.C explain what the modules are. The .NR and .MAN files have been updated to describe the new switches. ------------------------------ Date: Fri, 31 Aug 84 20:30 MST From: Brzozowski@HIS-PHOENIX-MULTICS.ARPA Subject: Kermit-MS 2.26 Works on Compaq To: cc.daphne@COLUMBIA-20.ARPA I have just gotten a copy of Kermit 2.26 for MS-DOS for my Compaq. I assembled it like an IBM-PC and I have had no problems with it. I have tested the terminal emulation on Multics Emacs configured as an h19, and it works great!!! I just wanted to let you and Jeff Damens know that that you have done an excellent job! (I also wanted to let you know that it appears to work well on a Compaq too.) Keep up the fantastic work! Gary Brz... ------------------------------ Date: Tue 21 Aug 84 14:10:40-PDT From: ALFIERI@ECLD.#ECLnet Subject: Problem with MS-DOS Kermit To: info-kermit@columbia-20.arpa I love the new version of Kermit for the IBM PC, but I have been having a small problem. Whenever I transfer a file either to or from the TOPS-20, Kermit inserts a long string of Control-Z's at the end of the file. These can be easily deleted, but the earlier version of Kermit did not do this. I assume others have had this problem? --vincent alfieri computing information services university of southern california alfieri@usc-eclb [Ed. - There is an end-of-file option for Kermit-MS 2.26 that determines whether Control-Z's are used at the end of a file. Normally, they are not. You must have asked (either explicitly, or in your MSKERMIT.INI file) to use them. See the manual.] ------- Date: Tue 21 Aug 84 17:18:51-PDT From: L. Brett Glass <GLASS@SU-SIERRA.ARPA> Subject: Text Upload and Auto LF in MSKERMIT To: info-kermit@COLUMBIA-20.ARPA I have been using the IBM PC version of MSKERMIT for a few weeks now, and like it a lot. However, there are two semi-essential features that it does not have -- and I would like to find out if anyone out in Net-land has implemented them already. These are: 1) Text Upload (that is, dumping straight text from a file to the serial port); [Ed. - There are so many variations on how to do this that we didn't even try; instead, we included a RUN command in Kermit-MS that you can use to run your own Basic or Pascal or C (or ...) program that does it whatever way it wants (XON/XOFF, look for prompt, look for handshake, etc etc).] and 2) Auto linefeed (i.e. going to the next line when the host tries to type past column 80). [Ed. - Linewrap works in the H19 emulator in IBM PC Kermit-MS. The host has to first send the escape sequence to enable it; it's off by default. The escape sequence is ESC v to turn on line wrap, ESC w to turn it off. See the Kermit User Guide.] I have been able to do text upload on the HP 150 version by doing a "push" and then a "copy" to the seral port; unfortunately, the IBM version produces a "write error" when I try this technique. [Ed. - We'll look into the write-error problem.] As for the auto-linefeed, I need it to emulate the terminals I use at work, whose software expects this option to be enabled. Any help with these queries would be MUCH appreciated. Please respond to <GLASS@SU-SIERRA.ARPA>, and I will post results if there is sufficient interest. --Brett Glass <GLASS@SU-SIERRA.ARPA> ------------------------------ Date: 1 September 1984 11:54-EDT From: George J. Carrette <GJC @ MIT-MC> Subject: New Kermit Implementation in LISP To: cc.fdc @ COLUMBIA-20 A full-function kermit with H19 terminal emulator has been part of the standard LMI lispmachine software release since June. We have used it in house extensively as the way to get files from tops-20 and multics sites and to and from our vax before we had TCP. It is also used by customers to deposit bug notes and snarf fix files from our vax. Also implemented is a SERVER/LOGIN feature, where one can log into the lispmachine through a serial line and get a kermit command loop. This has been used by people uploading and downloading lisp programs from IBM pc's. At some sites kermit fills a real "network gap" where management has not decided on the "right network" yet but programmers need to transfer files. The implementation is kind of hairy. As soon as we have it up in another lisp dialect ourselves (NIL on VAX) we can release it as a COMMON-LISP standard kermit, which would be a good thing indeed. ------------------------------ Date: 30 Aug 1984 13:46:53-MDT From: Leah F. Miller C-10 <lfm@lanl> To: cc.fdc@COLUMBIA-20 Subject: Cray Kermit Progress Report An initial version of Cray Kermit went onto in-house friendly user release on the last day of June. This was a rudimentary "advanced" Kermit with a Server and timeout capability, but nothing fancy. It immediatedly gained user acceptance and began to be used on a daily basis, talking exclusively to Kermit-86 on the IBM PC. A week or so later, Lila Chase began porting it to a rather similar Cray environment at Livermore. She had some success in getting it to talk to Kermit-86 and to a Version 1 Unix Kermit on the SUN computer. Extensive use soon revealed an inadequacy in end-of-file detection. This was a very minor problem at LANL, but much more serious at Livermore where a variant compiler put a trailer after the end-of-file character. At the same time, our users began to request a binary file transfer capability. This required 8th bit quoting, as our network hardware usurped the 8th bit to impose even parity. Since I was doing revisions anyway, I decided to add repeat prefixing. The resulting version of Cray Kermit, called Kermit-CR, now appears to work successfully with both Kermit-86 & MSKERMIT on the IBM PC. A new period of "friendly user" testing is about to begin. If all goes well, I expect to release Kermit-CR in September. ------------------------------ DATE: MON, 13 AUG 1984 FROM: ATSBDN AT UOFT01 TO: SY.WBC3 AT CU20B SUBJECT: ATTRIBUTES PACKETS the ascii 33 attr packet (file length) would be more convenient of the units were in 512 bytes rather that 1024. All DEC pdp11 exec's store allocations in chunks of 512 in the directory entry, thus going to 1024 in the attribute packet can cause trouble. The reason this came up was the need for kermit-11 to be able to tell a RT11 kermit-11 how big the file should be, since RT files are always contig and need to be allocated at create time. No problem for small files, but if the file is to be larger that 1/2 of the largest free contig space then pre-allocation for RT11 is required. For binary files, a length error of +/- one block (due to the rounding in mapping 512 to 1024) could cause problems to an rt11 application needing to read the resultant file. brian nelson [Ed. - Right, it would be better for PDP-11's if the length were expressed in "blocks" instead of K. But there are lots of systems out there that have "blocks", "pages", etc, of different sizes, but K-bytes is the best understood unit. The intention of this field is not to give the exact size of the file, but to let the receiver of a file have some idea in advance of how big it is before it starts to arrive. The EXACT size (byte count) may be specified in another field, which will be listed in the next edition of the Protocol Manual -- "1" (ASCII 49) Byte Count, and "2" (ASCII 50) Byte Size.] ------------------------------ Date: 29 Aug 1984 1126-PDT From: HAL.DOVE at Ames-VMSB Subject: Kermit Over Telenet? To: cc.fdc at columbia-20 Sorry to bother you with this, but I rmemeber that you mentioned about kermit over telenet. Have you ever had the problem while you are on telenet where your spaces are sometimes echoed and sent as @. It is a real annoying problem. If you do not know, do you possibly know someone who does know? Thanks Mike [Ed. - Do you have your parity set right? To the best of my knowledge, Telenet expects you to use Mark parity. Any Telenet users out there?] ------------------------------ From: Paul McNabb <pam@Purdue.ARPA> Date: 22 Aug 1984 0831-EST (Wednesday) To: info-kermit@columbia-20.ARPA Subject: Use of Kermit in Commercial Products I also have a question. I have heard of people using kermit in a product to be sold. I have been working on a project that may require some sort of file transfer package. Do people frown on kermit being included in a commercial product? Thanks. Paul McNabb Director of Research Facilities Department of Computer Science Purdue University (pam@purdue) [Ed. - Our policy ("feelings", really) on the subject have been written down in a special document which we send to people -- and there are many -- with such requests. It's in KER:COMMER.DOC.] -------- Date: Wed 22 Aug 84 15:36:46-PDT From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> Subject: DEC-20 Kermit Control Character Interference To: cc.fdc@COLUMBIA-20.ARPA Frank, You can disregard my previous message about troubles with MSKERMIT and TOPS20 Kermit. Please accept my apologies for cluttering your mailbox with 'one more message'. The problem I uncovered was the following, and feel free to post to INFO-KERMIT (after editing a bit) if you feel it is appropriate. The SUMEX exec, as well as many other Tops20 execs, has built in a command editor, usually gotten into by typing '^' as the first character. You can also arm a control character to get into the command editor. I choose ^A. Well, if you use a Tops20 system as a server, and have ^A armed for the line editor, KERMIT will hang no matter what you try to do. I assume this has something to do with Kermit using ^A as a status interrupt. Anyway, that's it. I'm glad I solved it, and I hope someone else doesn't have to waste the time I did. -- Ed [Ed. - Thanks, Ed. Yes, some sites have command editors or daemon forks that are armed to do things when you type certain control characters. Kermit uses ^A as the packet delimiter, so it couldn't transfer files very well if the ^A's were being trapped by some other process. The next release of Kermit-20 will do something about this -- at the very least, it will warn you that another process has a terminal interrupt enabled for ^A. Meanwhile, you can kill your daemon while running Kermit, OR you can redefine the start of packet character to be something other than ^A (SET RECEIVE START-OF-PACKET).] ------------------------------ Date: Wed, 22 Aug 84 20:34:26 CDT From: Stan Barber <sob@rice.ARPA> To: info-kermit-request@columbia-20.ARPA Subject: TRS-80 Kermit author moves Hi there. I am now at Baylor College of Medicine. For TRS-80 Kermit users who want to write, the address is Stan Barber Deparment of Neurology Baylor College of Medicine Houston, Tx 77032 sob@rice still works for mail. We also use kermit here on MASSCOMP under Unix and on PDP-11/23 using RT11. Cheers. Stan [Ed. - Good luck, Stan. By the way, we're still missing the complete set of source files for TRS80 Kermit. Could you, or someone, please send them to us on tape? We have not been able to get them with ftp.] ------------------------------ Date: Wed, 22 Aug 84 23:43:08 cdt To: info-kermit@columbia, info-kermit@columbia-20 Subject: Apple CP/M and DOS Kermit? From: fenchel@wisc-rsch.arpa I'm looking for a version of kermit for an apple 2e with microsoft premium softcard and ssc serial interface card. I would prefer a CP/M version, but will settle for a working Dos version if necessary. Is anyone willing to send me a diskette? or to give me clear instructions on how to download the object file (or source) via ftp from columbia-20 to a unix / vax system. I have a temporary path to download from the unix to the apple under DOS, but am looking for a more permanent and reliable one using KERMIT. ------------------------------ Date: 26 Aug 1984 0205-PDT From: KOTLER@USC-ECLB.ARPA Subject: Kermit to TOPS-20 over TAC? To: Info-Kermit@COLUMBIA-20 I have no end of of troubles in using kermit to communicate with tops20 via the arpanet/milnet. There must be some trick that I am missing. Currenntly I am going through a Tac via remote dialup and no matter what combination of parity/no parity/even parity etc. I used I get a tremendous number of retries when attempting to send files from the tops20 ECLB machine to my IBM PC at home. One trick that I discovered was that the @ character in the packets was being intercepted by the net, so I had to chage the interrupt character via a @i 2, which makes ctl B the new interrupt character. Normally the number of retries is at least half the number of packets recieved. Any help would be greatly appreciated. Thanks in advance, Reed [Ed. - TOPS-20 Kermit needs to be told that you are talking to it through a TAC. It will then put the TAC in "binary mode" and all will be well. When the file transfer is done, it will take it back out of binary mode. The command is SET TVT-BINARY ON.] ------------------------------ End of Info-Kermit Digest ************************* ------- 10-Sep-84 13:49:46-EDT,20500;000000000000 Mail-From: SY.FDC created at 10-Sep-84 13:49:23 Date: Mon 10 Sep 84 13:49:23-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #24 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Mon, 10 Sep 84 Volume 1 : Number 24 Today's Topics: New Cyber-170 NOS, NOS/BE Kermit MS-DOS Kermit Available for NEC APC New Release of Multics Kermit Another Kermit for Victor/Sirius MS-DOS TRS-80 Kermit Source Problems Fixed Getting UNIX Kermit Session Transcripts V2.26 MS-DOS Kermit Heath-19 Emulation Bug MS-DOS Kermit on Eagle PC-Plus Bugs in MS-DOS Kermit 2.26 Rainbow CP/M-86 Kermit Printer Interrupts Kermit for Epson QX-10? Apple Kermit on Quadlink Board? Question about RSX Kermit ---------------------------------------------------------------------- Date: Thu, 6 Sep 84 14:33:25 cdt From: knutson@ut-ngp.ARPA (Jim Knutson) To: SY.FDC@CU20B Subject: New Cyber-170 NOS, NOS/BE Kermit Version 2.2 of Kermit for the Cyber-170 is ready. The files are: 170kermit.for 170azlib.asm 170tape.ltr The tape letter is what I have been sending out with tapes I have written for others. You may or may not want to include it with the others. The only change to the document file is the version number. Version 2.2 contains the following modifications from 2.0: Changes from Bill Russell (Russell@NYU.ARPA): Added NOS 2.2 support (up through level 602). Add timeout during reads (NOS 2.2 level 602 or above only). Changes from Ric Anderson (U of Arizona, Tucson): Add UPDATE IFDEFs for character set, operating system and site selection. Fix EXECMD to work under NOS/BE. Fix CFE for use under NOS/BE. I'll include the 8th bit prefixing from Olaf Pors at the U of Virginia along with with the other mods I've done on the next release I send to you. Jim [Ed. - The new files are in KER:170*.* on COLUMBIA-20 and CU20B.] ------------------------------ Date: Tue 7 Aug 84 20:51:35-PDT From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: MS-DOS Kermit Available for NEC APC To: cc.daphne@COLUMBIA-20.ARPA I've finished the system-dependent part of MS-DOS Kermit 2.26 for the NEC APC. The source file is called MSXAPC.ASM. The executable code is in MSAPC.EXE, and a brief help file specific to the APC is in MSAPC.HLP. I also found one bug in (I guess) the documentation to the effect that the POSCUR routine must not trash register SI. It messes up file reception if it does. -- Ron [Ed. - Thanks Ron! The files are available in KER:MS*APC.* on CU20B and COLUMBIA-20. Anybody else want to contribute similar modules for some of the other MS-DOS systems (Victor/Sirius, Tandy 2000, Seequa, Z100, etc) so we can get rid of the redundant files?] ------------------------------ Date: Fri 7 Sep 84 16:28:38-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New Release of Multics Kermit To: Info-Kermit@CU20B.ARPA A new release of Multics Kermit has been received from Paul Amaranth of Oakland University. This is version 2.0g, and replaces the earlier version from May 1983. Various problems with the earlier version have been corrected (for instance, the source code no longer contains any "hard" control characters), and many improvements have been made (server mode, logging and metering facilities, etc). Comments and critism may be directed to Paul at the following address; he may also be reached at (313) 377-4329. With any luck Oakland U will be on MailNet in the not too distant future and communications will improve. Paul Amaranth Oakland University Academic Computer Services Rochester, MI 48063 USA The files are in KER:MU*.* on COLUMBIA-20 and CU20B, including PL/I source files, user help files, installation instructions, and program call tree listings. ------------------------------ Date: Fri 7 Sep 84 16:58:51-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Another Kermit for Victor/Sirius MS-DOS To: Info-Kermit@CU20B.ARPA This version of Victor Kermit is written in Computer Innovations 'C' by W. Hertha of Victor Technologies (Canada) and Dr. Joe Angel of the Department of Biochemistry of the University of Saskatchewan. There is no hex file format of the binary currently available, so you must have Computer Innovations 'C' to be able to compile it on a Victor. It should work with other complete 'C' compilers as well. It has been tested at 9600 baud with no problems. The help file describes any variations from the standard kermit implementations. Thanks to David Emigh of the University of Saskatchewan for this contribution. The files are in KER:VICKERMIT.* on CU20B and COLUMBIA-20. ------------------------------ Date: Fri 7 Sep 84 17:37:11-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: TRS-80 Kermit Source Problems Fixed To: Info-Kermit@CU20B.ARPA Thanks to the many, including Brian Sietz of Rutgers, who pointed out the problems with the TRS-80 Kermit source files. We now have what we hope is a complete and correct set of files in KER:TRS*.* on CU20B and COLUMBIA-20. - Frank ------------------------------ Date: Thu 6 Sep 84 16:51:21-PDT From: Daniel H. Miller <DHMILLER@USC-ECL.ARPA> Organization: Litton Data Systems; Van Nuys, CA; (818)902-4493 Subject: Getting UNIX Kermit Session Transcripts To: info-kermit@COLUMBIA-20.ARPA I found an interesting method of obtaining UNIX Kermit transcripts: kermit clb /dev/tty0 1200 | tee transcript Kermit sets up its session in CONNECT mode over line tty0 at 1200 baud and then every time a character is received from the line it is sent via a pipe to tee which sends it to the terminal and to the transcript file. The transcript file contains what the user types and what is sent via the machine, since Kermit is operating in full duplex and all characters come back over the line. This works as long as Kermit only outputs via standard output. --- Dan Miller ------------------------------ From: Bruce Nemnich <godot!bruce@cca-unix> Date: 29 Aug 1984 0445-EDT (Wednesday) To: Info-Kermit@COLUMBIA-20.ARPA Subject: v2.26 heath emulation bug There is a heath emulation bug in v2.26 in that tabs are destructive, i.e., they wipe out characters under the range of their motion. I assume this is a bug; I don't have a real heath at hand, but all drivers I have seen assume heath tabs aren't destructive. For those of you using Unix, that means you will want to add the "xt" flag to the termcap and/or terminfo entries for your kermit terminals until the bug is fixed. --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA [Ed. - Anybody out there have a real Heath-19 to check this?] ------------------------------ Date: Fri, 07 Sep 84 20:59:14 EDT From: Jeff Kimmelman <jkimmelm@bbn-vax.arpa> Subject: MS-DOS Kermit on Eagle PC-Plus To: info-kermit-request@columbia-20.arpa I am having problems with MS-Kermit on my Eagle PC-plus. It seems that I lose about one out every 10 characters when I am in terminal emulation connected to a host. I suspect that there are stop bit problems but am not sure. I haven't been able to get the manual yet and can find no command which alleviates the problem. If you can help I would greatly appreciate it. I am using generic Kermit by the way. Thanks in advance-- Jeffrey Kimmelman [Ed. - Generic Kermit can't be expected to work flawlessly on a new machine, only just barely. The solution, of course, is to add explicit system-dependent support for the Eagle, as we have for the IBM PC, Rainbow, Wang, HP150, etc. Any volunteers?] ------------------------------ Date: Sat 8 Sep 84 11:57:02-PDT From: Roland Hutchinson (r.rdh@su-lotsa) To: Info-Kermit@COLUMBIA-20 Subject: Bugs in MS-DOS Kermit 2.26 Congratulations to the implementors of the new MS-DOS Kermit!!! The following bugs and curious features have come to my attention in version 2.26 on the IBM-PC. CAVEAT: I HAVE NOT HAD TIME TO REASSEMBLE AND TEST THE FIXES SUGGESTED FOR THE FIRST TWO ITEMS BELOW. PLEASE REGARD THEM AS SUGGESTIONS ONLY!! I have thought it more important to report these to you quickly than to try to fix them myself with my limited experience in 8086 assembler! 1. Status line displays incorrect information. The status line (line 25) shows local echoing when echoing is in fact remote, and vice-versa. This is, to say the least, confusing. (The STATUS command, however, continues to give the correct information.) This one appears to be easy to fix: In the file MSTERM.ASM, make the following change: test flags,lclecho ; echoing? jnz modl4 ; no, keep going ;[ ^^^ THIS WAS JZ INSTEAD OF JNZ, IN ERROR] mov si,offset remmsg modl4: mov cx,3 ; size of on/off mov di,offset modbuf.m_echo rep movsb 2. Problems with command prompting. Typing "?" after certain commands yields an incorrect reprompt--the question mark is not removed from the line, thus: Kermit-MS>defi? Specify macro name followed by body of macro Kermit-MS>defi? Typing ESC at this point produces Kermit-MS>defiINE (note the two i's). This problem seems to affect the commands: DEFINE LOG SHOW MACRO SET PROMPT SET KEY SCAN This might be fixed by making the message strings FILHLP through SK2MSG in MSSET.CMD have the same format as the strings which proceed them, i.e., remove the leading space and insert cr and lf in the last six lines listed below. erms23 db cr,lf,'?0 or null scan code not allowed$' ;[jd] erms24 db cr,lf,'?Capture file already open (use close command)$' ;[jd] filhlp db ' Input file specification for session logging$' macmsg db ' Specify macro name followed by body of macro $' shmmsg db ' Confirm with carriage return $' prmmsg db ' Enter new prompt string $' sk1msg db ' Decimal scan code for key $' sk2msg db ' Redefinition string for key $' The proposed change would also have the benefit of making the "?" behave uniformly in different commands. (ALWAYS starting the help message on a new line.) [I have noticed a few other problems with command prompting & completion--if memory serves, typing the name of a command complete, but without a space, and following it immediately with a "?" was one situation. Sorry I don't have time to test and report at length just now, but my impression is that the whole command-parsing code needs a good systematic test!!!] 3. 8th-bit characters typed from the keyboard can cause a system crash!! This is rather a bad problem and I am afraid I have no idea how to fix it. Do the following: Kermit-MS>set key f1 Enter key definition: ^^Here, hold down the alt key and press 147 on the keypad (this is the normal way of entering characters 128 to 255 decimal from the IBM keyboard). Type a few more of 8-bit characters in this way, if you like. Then press RETURN. The screen will fill with stray bits of text, and seem to go into a loop. The floppy disk may start to spin after a while (fortunately, no damage seems to be done to the disk.) The only way out is to power down. I suspect that this problem occurs because CMGTCH (in the file MSCMD.ASM) sets the 8th bit to mark an "action character", and something in SETKEY or DEFKEY is unprepared to deal with other hi-bit characters. This is going to be a bit tricky to fix absolutely properly. Since ESC+80H, "?"+80H, " "+80H are all valid characters in IBM's extended character set, it should be possible to enter them from the keyboard. I don't see how this would be possible without rewriting COMND and much of the code that uses it. In the meanwhile, a fix that simply keeps the system from crashing and ignores these characters (or lets only some of them through, or whatever) would be a very good thing to have!!!!!! 4. SET KEY SCAN doesn't parse it's input correctly. SET KEY SCAN<space><space><return> doesn't realize it should generate the same error as SET KEY SCAN<return> or SET KEY SCAN<space><return> You have to use ctrl-C to get out. I don't know what scan number it thinks it's getting or what it does if you give it a redefinition. (It accepts it, but where does it put it?) 5. Suggested improvement in SHOW MACRO command. It would be nice if this could reconvert the tabs (displayed as "\015") back into a printable character--preferably the comma, so that SHOW MACRO would show a definition string that looked like the one DEFINE originally read. 6. File transfer status line isn't sufficiently informative. The RETURN key is active during file transfers, and nothing on the screen warns the user about this. Pressing return carelessly during a transfer can get the transmission out of synch, and abort the current file being transfered. (It happened to me!!!!) The role of the RETURN key should be displayed somewhere on the screen (maybe on line 24, in reverse video to match line 25?). Would it be possible to fix it so that stray RETURN's can't break the file transfer? (Perhaps by making the return key active only if the comm port hasn't been busy for a while--the purpose of the RETURN is to do a "wakeup" as if the line had been timed out, isn't it? (If I have misunderstood the niceties of the protocol, kindly ignore this suggestion!!!)). 7. Undocumented command. The grey plus key (on the keypad) toggles the status line on and off. This isn't documented anywhere, or have I missed it? 8. Missing scan codes. Scan codes for ctrl with certain keys on the keypad don't seem to be passed along to the program. (Shift+keypad codes work fine.) Everything but ctrl-uparrow, ctrl-downarrow, and ctrl-5-on-the- keypad does work properly. These don't work because of IBM's somewhat perverse BIOS. It would be easy enough to slightly rewrite the BIOS routines in question and replace them either at boot time or while running Kermit only. I could even volunteer to do the job myself--but IBM's copyright police probably wouldn't care to let us distribute the resulting source code or object code!!!!! In short, it probably isn't worth the effort just to fix this. But if we could get ctrl-alt-stuff to return a different scan code from alt-stuff (there seem to be just about enough scan codes left, if we agree to ignore the state of the Shift key--sorry, LEDIT users!), now there would be something worthwhile. (Unfortunately, the same copyright problems apply.) Thanks to all involved in creating and maintaining this program! I hope the above is helpful to you. Roland Hutchinson [Ed. - Thanks for the informative report; it'll be reflected in the next release.] ------------------------------ Date: Thu, 6 Sep 84 08:48:01 EST From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers) To: Info-Kermit@columbia-20.ARPA Subject: Rainbow CP/M-86 Kermit Printer Interrupts I was interested by the note in RBKERMIT.HLP concerning the problem caused by "certain printer interrupts". I have had Kermit-86 freeze on me quite often, and I'm fairly sure it's happened when my printer has not been switched on. Assuming the problem is to do with the printer interrupts, how about this as a kludge: a command that disables all other printer-related commands and options, and points all the printer interrupt vectors to an IRET. You would also want the ability to reverse this process. Can anyone familiar with the internals of Kermit-86 suggest whether this is likely to succeed, and if so how big a job it would be? Another problem I've experienced is that at 2400 baud (our default line speed), the time taken between disk writes is approximately equal to the Rainbow's disk motor time-out period. This sometimes leads to drive-not-ready errors. There are several ways round this, (e.g using SET DELAY at the transmitting end, or changing the line speed), but they are not always convenient. How difficult would it be to vary the number of packets/characters received before the buffer is written to disk? I'm not asking for someone else to do the work, but I'd appreciate some advice about where to start. Steve Withers, University of Melbourne Computer Centre. ------------------------------ Date: Sun, 9 Sep 84 23:27:47 EDT From: John Wiggins <jwiggins@BBNCCY.ARPA> Subject: Kermit for Epson QX-10? To: info-kermit-request@columbia-20.arpa Is there a version of KERMIT to allow me to transfer files between UNIX system and my micro, Epson QX-10 using CPM? If so, I would appreciate help or direction. Thanks, John Wiggins Room 3/162 BBN Communications, Inc 50 Moulton Street Cambridge, MA 02138 617-497-3390 [Ed. - Neither the current version (3.9A) nor the soon-to-be-announced modular version (4.?) of CP/M-80 Kermit contains explicit support for the Epson. Support for new systems will be easier to add to the forthcoming modular version than to the current monolithic one. In the meantime, does anyone have a custom-made Epson Kermit?] ------------------------------ Date: 10 Sep 84 09:14:10 EDT From: Bdale Garbee <AG0B@CMU-CC-TE> To: Info-Kermit Subject: Apple Kermit on Quadlink Board? Does anyone have any experience getting Kermit v2.1 for the Apple ][ family of computers working on the Quadlink "Apple-emulation" board for the IBM PC? If so, how did you do it? Quadram's documentation is mighty sparse... Bdale Garbee CMU Software Staff ------------------------------ Date: 5 Sep 1984 1555-PDT From: HAL.DOVE at Ames-VMSB Subject: Question about RSX Kermit To: info-kermit at cu20b I have been having a peculiar problem with the RSX Kermit Connect when remoted: Situation: I am on a VAX running VMS, I connect to our PDP running RSX-11m+. I start up kermit, set line to tt7: (a line going to another computer) Do a connect, get the "this is not a remote line message" and then it kicks me back to the vax real quick. Other Info: When I am logged into the PDP directly, no remoting involved. The connect seems to work fine. Is this a problem with the older version not supporting ht#: lines? Thanks in advance, Mike a.k.a. hal.dove@ames-vmsb P.S. It was announced a few kermits back that the new RSX Kermit would be ready shortly with the HT#: fix, among others. When is the tenative date for that?? ------------------------------ DATE: THURS, 06 SEP 1984 FROM: ATSBDN AT UOFT01.BITNET TO: SY.FDC AT CU20B SUBJECT: KERMIT AND RSX rsx q 1. do a set/tt7:=remote 2. can not test HTx:, but kermit-11 works fine in the pro/350 using XK0: so one would assume that doing a set line htn: would now work. I will send a tape today or tomorrow, I just sent one to Bernie for taking to Decus Europe. brian [Ed. - Will announce new PDP-11 Kermit when it's installed.] ------------------------------ End of Info-Kermit Digest ************************* ------- 13-Sep-84 17:35:29-EDT,14142;000000000001 Mail-From: SY.FDC created at 13-Sep-84 17:35:10 Date: Thu 13 Sep 84 17:35:10-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #25 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Thu, 13 Sep 84 Volume 1 : Number 25 Today's Topics: Macintosh Kermit #1 Available New Release of PDP-11 Kermit Kermit on RSX-11M Version 3.2? Obtaining Apple DOS Kermit Apple II Kermit-65 V2.1A Franklin CPM Kermit? Rainbow MS-DOS Kermit Bootstrapping Rainbow Printer Interrupts and CP/M 86 Kermit Screen Scroll Bug in MS-DOS Kermit V2.26 for the DEC Rainbow MS-DOS Kermit V2.26 Heath Emulation Bug Destructive Tab Fix for MS-DOS Kermit V2.26 ---------------------------------------------------------------------- Date: Thu 13 Sep 84 14:21:44-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Macintosh Kermit #1 Available To: Info-Kermit@CU20B.ARPA, Info-Mac@SUMEX-AIM.ARPA This is to announce Macintosh Kermit #1. It's one of several different Macintosh Kermits under development, but this was the first one to reach us. It's from Stephen Engel at Harvard University (engel@harvard), written in C for the Sumacc Unix-based Macintosh cross development system. The files are collected together into a Unix shell archive, as MC1KERMIT.SH. They include source files, a makefile, and some sketchy documentation. In Steve's words, "This is an `alpha' release of the program. Much of the code is sloppy and buggy, but I believe that all the program's funadmentals work adequately. This program is chiefly an adaptation of Columbia's Unix kermit." It has been tested in conjunction with Unix Kermit and DEC-20 Kermit. The program is far from complete and has many rough edges, but it's the first out the door and so should prove useful to the many sites that need some kind of Kermit capability for the Mac. You must have the Sumacc cross development system and a VAX-resident 68000 C cross compiler to make use of these files (anybody out there want to make a hex file suitable for use with the FROMHEX utility?). To get MacKermit onto a Mac, you must: 1. Get MC1KERMIT.SH to your VAX Unix system, preferably in its own directory. 2. Connect your Mac to the VAX using Macterminal 0.5 or later. 3. Be sure your search path includes the Sumacc tools. 4. CD to the directory where you've put the mc1kermit.sh file. 5. Type "sh < mc1kermit.sh" to let the shell pick the file apart. 6. Type "make" to build the program from the source. 7. Type "macput -r kermit" to send the Kermit program to the Mac. 8. On the Mac, use SetFile to set the "bundle bit" (optional). The VAX directory will contain the various source and header files, as well as the Mac-format resource file, and a brief document "kermitdoc", explaining the operation of this version of Macintosh Kermit. The shell archive file is available as KER:MC1KERMIT.SH on COLUMBIA-20 and CU20B via anonymous FTP (it seems to contain multiple versions of some of the files, but I didn't want to tamper with it). Comments, suggestions, bug reports should be directed to engel@harvard with cc to Info-Kermit@CU20B (or @COLUMBIA-20 if your host doesn't know how to mail to CU20B yet). Thanks, Steve, and congratulations on being the first to do it. - Frank P.S. This is probably just the first in a long series of Macintosh Kermit announcements. Independent implementations are expected from Rice, Brown*, Dartmouth, and elsewhere (maybe even Columbia, which was supposed to have done it in the first place), and new releases of the Harvard implementation will probably also appear from time to time. *I'd like to see these two get together and produce a Brown-Rice version... ------------------------------ Date: Wed 12 Sep 84 12:47:38-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New Release of PDP-11 Kermit To: Info-Kermit@CU20B.ARPA Brian Nelson of the University of Toledo in Ohio (ATSBDN@UOFT01.BITNET) has contributed a new release of his PDP-11 Kermit, version 2.22, which supports RSX-11/M/M+, RSTS/E, RT-11, and (now) P/OS systems. New features since the previous release (2.18) include: . 8th-bit quoting for passing binary files through 7-bit communication links; . Various improvements in RT-11 support; . "IBM Mode" -- handshake, parity, for communicating with IBM mainframes; . Support for Pro-350 P/OS systems. The new P/OS support is DCL only (no menus), but it differs from the current Stevens version of P/OS Kermit by supporting Files-11 attributes. The files (72 of them!) are in KER:K11*.* on COLUMBIA-20 and CU20B. The file KER:K11FIL.DOC (slightly out of date) explains what all the files are. The file KER:K11INS.DOC (also slightly dated) contains installation and configuration information. Binaries built for various configurations are in KER:K11*.HEX in "hexified" format, decodable by the programs KER:K11HEX.*. There's also a new document, KER:K11ART.MEM, an article describing the PDP-11 implementation of Kermit in some detail. ------------------------------ Date: Wed, 12 Sep 84 10:34:43 EDT From: mattis@NBS-SDC Subject: KERMIT ON RSX-11M VERSION 3.2 To: INFO-KERMIT@COLUMBIA-20 I have FTP'd the K11FIL.DOC file which lists all the files relating to installation of Kermit on a PDP-11. Before I start, can anyone tell me right off whether I can use these files to install Kermit on an LSI-11/23 running RSX-11M version 3.2? We do not have RSX 4.1 and because the system uses proprietary software supplied by a third party there is little chance of getting it. [Ed. - Sorry, no, as it says in the installation instructions, K11INS.DOC, you must have version 4.0 of RSX-11M, or version 2.0 of RSX-11M+.] ------------------------------ Date: Wed 12 Sep 84 00:36:37-EDT From: Peter G. Trei <OC.TREI@CU20B.ARPA> Subject: Obtaining Apple DOS Kermit. To: info-kermit@CU20B.ARPA Hi! I'm Peter Trei, one of the maintainers of Apple DOS Kermit. Recently, some people have been asking questions about obtaining this version. For some time, I have been supplying copies to the Columbia community at a nominal fee, since booting it up from a mainframe is a non-trivial task. If you can meet me in the CU area, I will trade the disk in return for a new, blank one. If not, for $5 I will mail out a copy. I can also give a certain amount of help over the phone if you are really stuck. My address is: My daytime phone is: 212-8153711 Peter Trei, 15 Sickles Street, New York, NY 10040 Peter Trei oc.trei%cu20b@columbia.arpa [Ed. - Thanks for volunteering to perform this service, Peter! The Apple II Kermit bootstrapping technique is one of the most difficult, and you'll be saving many people lots of time and trouble. Readers of Info-Kermit should bother Peter only on a per-site basis, and then distribute copies themselves within their own site.] ------------------------------ Date: Tue 11 Sep 84 16:41:22-EDT From: Anton Mione <OC.MIONE@CU20B.ARPA> Subject: Apple II Kermit-65 v2.1a To: sy.fdc@CU20B.ARPA Frank, Peter Trei has made some changes to allow Kermit-65 to print real lowercase for //e's and //c's. We are calling it version 2.1A. The three APPLEK files in my directory represent the new stuff. Anton:<miONE> [Ed. - The new files are in KER:APPLEK.*.] ------------------------------ Date: Tue, 11 Sep 84 9:36:26 EDT From: Dave Swindell <dswindel@bbn-labs-b> Subject: Franklin CPM Kermit To: info-kermit@cu20b.arpa I have a Franklin 1200 computer with a PCPI CP/M card and and ASIO II serial/parallel card. Are there any versions of Kermit that have been used with the PCPI CP/M card? Are the source .ASM files available on line for either the Apple CPM or generic CPM Kermits? Any help in obtaining a workable CPM kermit for the Franklin would be appreciated. Thanks, Dave Swindell BBN Labs [Ed. - Anybody out there have Kermit running on a Franklin?] ------------------------------ Date: Thu 13 Sep 84 16:32:44-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Rainbow MS-DOS Kermit Bootstrapping To: Info-Kermit@CU20B Users of DEC Rainbow 100s have complained that there's no bootstrapping procedure they can use for getting the new MS-DOS Kermit onto the Rainbow over the communication line. The problem was that Basic was not available for MS-DOS on the Rainbow (or else it was so new that no one had it yet), so the Microsoft Basic program we provided for decoding the .BOO (4-for-3 encoded) binary file could not be used on the Rainbow. Now, thanks to Bernie Eiben at DEC, we have a version of the Basic program that will run on the CP/M-86 side of the Rainbow, under Microsoft MBasic-86. It's a reworking of MSPCTRAN.BAS, which assumes that you already have the .BOO file on your CP/M disk. It builds an .EXE file, which you can then move to the MS-DOS side of your Rainbow by booting MS-DOS and then using RDCPM to get the file from the CP/M-format disk. How you get the .BOO file onto the CP/M disk in the first place is another question. Either you use some file capture utility -- commercial or otherwise -- or else you go through the DDT bootstrap procedure given for CP/M-80 Kermit (since the Rainbow is also a CP/M-80 system). Bernie's program is in KER:MSRBBOO.BAS. ------------------------------ Date: Mon 10 Sep 84 16:42:41-EDT From: Jeff Damens <US.JD@CU20B.ARPA> Subject: Rainbow printer interrupts and CP/M 86 Kermit To: decvax!mulga!stephenw.murdu@UCB-VAX.ARPA cc: info-kermit@CU20B.ARPA [Ed. - This is in response to a suggestion in the previous issue of the Info-Kermit digest that the problem with printer interrupts hanging CP/M-86 Kermit could be solved by zapping the interrupt vector.] Unfortunately, it's not that easy. There are two separate problems: the first is that the printer and the comm port share the same interrupt vector, so the printer interrupt can't be handled separately. The second problem is that the communications chip needs to be told that processing for certain kinds of interrupts (notably status change) is over; just doing an IRET will hang the machine (presumably because the interrupt keeps on occurring until the chip is told the interrupt has been taken care of). MS Kermit gets around this by handling status change interrupts for the COMM port and reflecting all interrupts from the printer port back to DOS. Paul Ford of U. Chicago graciously fixed CP/M Kermit to do the same thing; his changes should appear in the next release. Jeff Damens ------------------------------ From: Ira Winston <Ira%UPenn-Graphics%upenn.csnet@csnet-relay.arpa> Subject: Bug in MS-DOS Kermit V2.26 for the DEC Rainbow To: sy.fdc%cu20b@columbia-20.arpa Date: Wed, 12 Sep 84 08:01 EDT This is a great program! Everyone here really likes it. However, there is one small problem. When using the PREV SCREEN and NEXT SCREEN keys to page through the text, line are occasionally deleted from the screen. For example, when I type prev screen twice and then next screen twice, the cursor appears one line below its original location and one line on the previous two screens is missing. If you fix this problem, please let me know and I will transfer the new version. Thanks. [Ed. - Thanks for the report; we hope to have this problem fixed in the next release.] ------------------------------ Date: 10 Sep 84 18:10:28 EDT From: D. M. Rosenblum <DR01@CMU-CC-TE> Subject: Re: v2.26 heath emulation bug To: SY.FDC@CU20B This concerns the message of Wednesday 29 Aug 1984 0445-EDT from Bruce Nemnich <godot!bruce@cca-unix> of Thinking Machines Corporation, Cambridge, MA. I checked on a real Heath-19 (actually a Zenith-19, which I am typing on right now, in fact) to see if tabs are destructive, and I found that indeed they are not destructive. So if Kermit's Zenith-19 emulation is indeed doing destructive tabbing, as he suggests, then it is indeed incorrectly emulating the Zenith-19. ------------------------------ From: Bruce Nemnich <godot!bruce@cca-unix> Date: 10 Sep 1984 1644-EDT (Monday) To: Info-Kermit@cu20b.ARPA Subject: destructive tab fix for IBM v2.26 Here is the diff of a fix for the descructive tab bug I reported earlier. It also makes the default to have wrap set on by default, which some h19 drivers also assume. (How about a command SET HEATH WRAP [OFF | ON]?) The modified file is MSYIBM.ASM. First, set line wrap on by default: 334c334 < jz term1 ; no, forget this part --- > jz term0 ; no, forget this part 335a336,337 > jmp term1 ; don't reset wrap mode > term0: or flags1,lnwrap ; start out in wrap mode Fix the destructive tab bug: 786c788 < xor dl,dl --- > wrap: xor dl,dl 837,848c839,846 < outtab: mov dl,byte ptr cursor ; get initial column < outta1: mov dh,dl ; save column ptr < push dx < mov al,' ' ; output a space < call outtty ; convenient, huh? < pop dx < mov dl,byte ptr cursor < cmp dh,dl ; is it moving? < je outta2 ; no, forget this < test dl,7 ; is it a multiple of 8? < jnz outta1 ; no, keep going < outta2: ret ; else return --- > outtab: add dl,8 ; tab width > and dl,0f8h ; round up to next tabstop > cmp dl,79 ; have we gone too far? > jle setcur ; ...nope, go ahead > test flags1,lnwrap ; ...yes, are we in wrap mode? > jnz wrap ; ......yes, do the wrap > mov dl,79 ; ......no, sit at end of line > jmp setcur ; and that's that --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA {astrovax,cca,harvard,ihnp4,ima,mit-eddie,...}!godot!bruce, BJN@MIT-MC.ARPA ------------------------------ End of Info-Kermit Digest ************************* ------- 14-Sep-84 18:57:37-EDT,5065;000000000000 Mail-From: SY.FDC created at 14-Sep-84 18:57:20 Date: Fri 14 Sep 84 18:57:20-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #26 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Fri, 14 Sep 84 Volume 1 : Number 26 Today's Topics: Macintosh Kermit New Kermit for Data General RDOS Systems New Release of Kermit for Data General AOS Systems New Release of Kermit for HP-1000 RTE Systems New Release of Apollo Aegis Kermit MS-DOS Kermit on a Zenith Z-150? ---------------------------------------------------------------------- Date: Fri, 14 Sep 84 11:51:55 pdt From: Bill Croft <croft%safe@columbia.arpa> Subject: Macintosh Kermit To: sy.fdc@cu20b After transfering over the ker:mc1kermit.sh archive, I discovered it contains 2 complete copies of the programs. You should edit this archive to remove the first half; this will reduce confusion and storage space. (I'm probably not the first to mention this...) The 2nd half of the archive also contains a kermit.dl, ready to download or convert with fromhex. I have posted kermit.dl and kermit.rsrc (and kermit.doc) on <info-mac> at SUMEX. [Ed. - Thanks Bill, and to the many others who sent similar messages. I've fixed the file, and also moved the hex to a separate file, MC1KERMIT.HEX. Sorry for confusing everyone the first time around. The files are on KER:MC1*.* on CU20B and COLUMBIA-20.] ------------------------------ Date: Fri 14 Sep 84 18:05:03-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New Kermit for Data General RDOS Systems To: Info-Kermit@CU20B.ARPA This is to announce Kermit for Data General systems running RDOS, written by John Lee at RCA Labs in Princeton (no network address). The program was written on a Data General Nova/4 running RDOS Rev. 7.0 and Fortran 5 Rev. 6.14. The source code is written in Ratfor, which compiles into Fortran 5. The Ratfor source code was not provided to Columbia University for redistribution; the author felt that most Nova sites would not have Ratfor or the necessary support libraries. The program is provided in Fortran form, complete with the necessary library routines. The files, including the Fortran program and some documentation, are in KER:RDOS*.* on CU20B and COLUMBIA-20. ------------------------------ Date: Fri 14 Sep 84 18:05:30-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New Release of Kermit for Data General AOS Systems To: Info-Kermit@CU20B.ARPA This is to announce a new release of Kermit for Data General systems running AOS, written by John Lee at RCA Labs in Princeton (no network address). The program was written on a Data General S/250 running AOS Rev. 5.0 and Fortran 5 Rev. 6.14. The source code is written in Ratfor, which compiles into Fortran 5. The Ratfor source code was not provided to Columbia University for redistribution; the author felt that most Nova sites would not have Ratfor or the necessary support libraries. The program is provided in Fortran form, complete with the necessary library routines. The files, including the Fortran program and some documentation, are in KER:AOS*.* on CU20B and COLUMBIA-20. ------------------------------ Date: Fri 14 Sep 84 18:06:08-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New Release of Kermit for HP-1000 RTE Systems To: Info-Kermit@CU20B.ARPA This is to announce a corrected version of HP-1000 Kermit from John Lee at RCA Laboratories in Princeton NJ. The program is written in Fortran (FNT7X) and runs under the RTE-6/VM operating system. The files are available in KER:HPM*.* on CU20B or COLUMBIA-20. ------------------------------ Date: Fri 14 Sep 84 18:06:32-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New Release of Apollo Aegis Kermit To: Info-Kermit@CU20B.ARPA This is to announce a new release of John Lee's Apollo Aegis Kermit, incorporating a minor change from Ted Shapin at Beckman Instruments to allow the program to operate from any node in the Domain network. The files are in KER:APO*.* on CU20B and COLUMBIA-20. ------------------------------ Date: 13 Sep 84 16:45:31 PDT (Thu) To: info-kermit@cu20b Subject: MS-DOS Kermit on a Zenith Z-150 From: Mike Iglesias <iglesias@uci-750a> A user on campus tried the IBM-PC version of the old MS-DOS Kermit on a Zenith Z-150. He was using the terminal emulation mode with a screen editor, and when the screen editor send the H-19 code for 'insert character', his cursor disappeared. Does this happen on the new MS-DOS Kermit? He tried the same thing on an IBM-PC and everything worked correctly, so I figure it's some incompatability in the Z-150. [Ed. - Anybody out there want to contribute MS-DOS Kermit system-dependent modules for the Z-150?] ------------------------------ End of Info-Kermit Digest ************************* ------- 21-Sep-84 16:08:08-EDT,9592;000000000000 Mail-From: SY.FDC created at 21-Sep-84 16:07:30 Date: Fri 21 Sep 84 16:07:30-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #27 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Fri, 21 Sep 1984 Volume 1 : Number 27 Today's Topics: New Kermit for Heath/Zenith-100 Bug fixed in Multics Kermit MS Kermit V2.26 Key Translation Problem MS-Kermit V2.26 Heath Emulation Bug (Inverse Video) Another Patch for Kermit-MS V2.26 Heath Tab Emulation Commodore-64 Kermit Progress Report Apples and 80-Column Cards ---------------------------------------------------------------------- Date: Fri 21 Sep 84 14:44:15-EDT From: Frank da Cruz <SY.FDC@CU20B> Subject: New Kermit for Heath/Zenith-100 To: Info-Kermit@CU20B Cc: Info-HZ100@RADC-TOPS20, Heath-People@MIT-MC, Info-Micro@BRL This is to announce a release of Columbia University's KERMIT file transfer and terminal emulation program for MS-DOS systems (Kermit-MS v2.26), adapted for the Heath/Zenith-100 with ZDOS 1.x (not tested on 2.x systems) by Jim Knutson of the University of Texas at Austin (knutson@ut-ngp). File transfer and other protocol features work identically as in other machines supported by v2.26 (such as the IBM PC & XT, DEC Rainbow, HP-150, Wang PC, and NEC APC); terminal emulation includes most of the fancy Kermit-MS features: Heath-19 emulation, session capture, mode line, key redefinition, and printer control, but not screen rollback. The files for MS-DOS Kermit 2.26 are available via anonymous FTP at hosts COLUMBIA-20 and CU20B as KER:MS*.*. Those who already have the MS-DOS Kermit files may specify the new H/Z100 files alone as KER:MS*Z100.*. The file KER:MSZ100.HLP describes the system-dependent aspects of the H/Z100 implementation of Kermit-MS. Please note that anonymous FTP access to COLUMBIA-20 is only available after 6:00pm eastern time. ------------------------------ Date: Fri 21 Sep 84 13:54:03-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Bug fixed in Multics Kermit To: Info-Kermit@CU20B.ARPA A new version of Multics Kermit, 2.0h, has been installed to replace 2.0g, which had a problem transferring files at 300 baud. The new PL/1 source files are in KER:MU*.PL1 on COLUMBIA-20 and CU20B. Thanks to Paul Amaranth of Oakland University, Rochester, Michigan. ------------------------------ Date: Tue, 18 Sep 84 22:28:01 cdt From: knutson@ut-ngp.ARPA (Jim Knutson) To: cc.daphne@columbia-20 Subject: MS Kermit V2.26 Key Translation Problem I ran into a problem while trying to set up the Z100 device dependent .ASM files. The problem is in the translation table handling. Apparently, the TELNET routine in MSTERM.ASM sets the HAVTT flag true whether or not the table is being used. This results in bizarre behaviour in my version if the SET KEY command is not run to define something. The IBM-PC version probably never runs into this problem since the lclini routine in MSXIBM.ASM redefines the backspace key to a rubout. I would appreciate it if you could look into the problem. I would rather not dive into the entire source code to figure out a fix. I would imagine that just having the DEFKEY routine set a flag would be good enough. Thanks, Jim Knutson ARPA: knutson@ut-ngp UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson Phone: (512) 471-3241 [That is a problem... I'd say we can get around it for now by testing the length of the translation table (it's initialized to 0) and skipping the search if it's 0. Hope that's easy... I'll make msterm set havtt correctly in the next release. - Jeff Damens] ------------------------------ Date: Tue Sep 18 1984 20:39:36 From: Marco Papa <papa%usc-cse.csnet@csnet-relay.arpa> To: Info-Kermit@CU20B Subject: MS-Kermit V2.26 Heath Emulation Bug (Inverse Video) It seems that the new version of MS-Kermit does not properly handle inverse video in some situations. We used it with a spreadsheet program (QCALC), running under Berkeley UNIX. This program makes heavy use of changes between normal video and inverse video when displaying cells and moving around the spreadsheet. The top row, that displays the cell names (A,B,C, etc..) in inverse vedeo gets clobbered very often when jumping from one position to another in the spreadsheet. If we run Kermit V. 1.20 instead, everything is just fine. Where any changes made to the way Kermit emulates the inverse video feature of the H19? Marco Papa USC - Computer Science Dept. [I haven't seen that happen, but I'll look into it. If it's at all possible, could you send me a (preferably short) session log that demonstrates it (you can just use the "log" command in kermit)? Thanks. - Jeff Damens] ------------------------------ Date: Fri, 21 Sep 84 16:14 GMT From: BRENGLE%LLL@LLL-MFE.ARPA Subject: Another Patch for Kermit-MS V2.26 Heath Tab Emulation To: info-kermit@cu20b.arpa I did a little research on a real H-19 to see how tabs behave. First, the tabs stops are at 8 column intervals, however once past column 72, each additional tab only moves the cursor one space forward. Also, tabs do not wrap at end of line, independent of the setting of the "wrap at end of line" switch. As has already been suggested, tabs are non-destructive. The following is an REDIT file which shows a patch I made to MSYIBM.ASM to exactly emulate these behaviors: ---------------------------------------------------------------------- REDIT 1(103) COMPARE by user BRENGLE, 20-Sep-84 15:40:14 File 1: PS:<KERMIT.IBMPC>MSYIBM.ASM.1 File 2: PS:<KERMIT.IBMPC>MSYIBM.ASM.2 ***** CHANGE #1; PAGE 1, LINE 838; PAGE 1, LINE 838 jle setcur ; col 0, can't back up dec dl ; back up col jmp setcur ; and use if reasonable outtab: mov dl,byte ptr cursor ; get initial column outta1: mov dh,dl ; save column ptr push dx mov al,' ' ; output a space call outtty ; convenient, huh? pop dx mov dl,byte ptr cursor cmp dh,dl ; is it moving? je outta2 ; no, forget this test dl,7 ; is it a multiple of 8? jnz outta1 ; no, keep going outta2: ret ; else return --------------------------------- jle setcur ; col 0, can't back up dec dl ; back up col jmp setcur ; and use if reasonable outtab: mov dl,byte ptr cursor ; get initial column outta1: inc dl ; move cursor right cmp dl,crt_cols ; are we still in range? jnb outign ; no, then don't update cursor cmp dl,72 ; yes, then at or past column 72? jge setcur ; yes, don't check tab stop test dl,7 ; no, then is it a multiple of 8? jnz outta1 ; no, keep going jmp setcur ; yes, then go set cursor ------------------------------ Date: 20 Sep 84 18:10:05 EDT From: Eric <LAVITSKY@RU-BLUE.ARPA> Subject: Commodore-64 Kermit Progress Report To: SY.FDC@CU20B Hi Frank, Well, I ran out of time at the end of the summer. Brian Beattie (beattie@bbn-unix or beattie@mitre-gateway) has since been working on it. As it stands right now, he has a working command parser which at present, can only call a working 80 column VT52 terminal emulator (which has been extensively field proven). Work is just now beggining on the actual communication protocol & disk I/O routines. I really wish we had more time to work on it. If you know of people who want to put time in on the project, have them send mail to Brian or me... Eric ------------------------------ Date: Fri 21 Sep 84 00:40:25-EDT From: Peter G. Trei <OC.TREI@CU20B.ARPA> Subject: Apples and 80-column cards... cc: info-kermit@CU20B.ARPA Here is a quick and dirty (emphasis on the latter) way to get kermit-65 to work with most 80 column cards. It should work with all cards, but does have some problems. The following code must be placed in kstart:, just after the line 'sta basws+1' near the end of the section: ; 1st attempt to use 80 column cards. use 80 column card entry vector stored ; within dos to print to screen, by moving it to csw; [48] pha lda $AA53 sta cswl lda $AA54 sta cswh pla ; end of 80 column code Compile kermit with Cross, and move the result up to your Apple. Now, if you start up Kermit while you have your 80-column card active, Kermit should use it. You should set display-type to 2e so that lowercase shows properly. There are some problems; As it stands, there seem to be extra line feeds between lines. Terminal emulation no longer works well (at all). I am working on making better accomodation for use of the Apple 80 column card and the Videx card. This is probably as good as it will get for other cards. Peter Trei oc.trei@cu20b ------------------------------ End of Info-Kermit Digest ************************* ------- 27-Sep-84 17:08:01-EDT,16617;000000000000 Mail-From: SY.FDC created at 27-Sep-84 17:06:46 Date: Thu 27 Sep 84 17:06:46-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest v1 #28 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Thu, 27 Sep 1984 Volume 1 : Number 28 Today's Topics: VAX Kermit Bugs Comments From a New MS-Kermit User Kermit on Uniplus+ System III? Posting Unix Kermit to Usenet? IOBYTE support in Generic Kermit-80 Rainbow CP/M 86 Kermit Wildcard Send Problem Bug in IBMPC/XT Kermit-MS 'set destination print' MacKermit Problems with Kermit-10 MS-DOS Kermit 2.26 CRC Bug MS Kermit vs BF160 Kermit-MS DOS 1.1 Support? ---------------------------------------------------------------------- Date: Fri, 21-SEP-1984 17:40 EDT From: Ronald A. Jarrell <JARRELLRA@VPIVAX3> To: Info-Kermit@cu20b Subject: Vax Kermit bugs We've run into a couple of problems with Vax Kermit. Were using it from MS-Kermit, over both rainbows, and ibm pc's. With the Vax in server mode, doing a remote help from the micro causes it to die consistently on the description of the last command. We also found a neat bug that seems to cause on IBM-PC's a core dump, and on Rainbows a re-boot. Do a REMOTE HOST DELETE FOO.BAR.1 (where the file name is a legal, existing file, and specifying an existing version number). Or create a com file of the following form: inquire "Foo" foo and then to a REMOTE HOST @comfilename Neat stuff. I have no idea of where to look in the code, and don't have Bliss to recompile it with anyway.. -Ron Bitnet: JarrellR@VPIVAX3 Arpa: JarrellR%VPIVAX3.BITNET@BERKELEY.ARPA ------------------------------ Date: Wednesday, 26 Sep 84 10:19:09 EDT From: rmcqueen (Robert C McQueen) @ sitvxa Subject: Problems reported by JarralR@VPIVAX3 To: sy.fdc @ cu20b Pro/Kermit talking to Kermit-VMS works find for the cases given in the mail message. I would assume that it has something to do with the MS/DOS Kermit. ------------------------------ Date: Mon 24 Sep 84 10:41:04-EDT From: Jeff Damens <US.JD@CU20B.ARPA> Subject: Re: [Ronald A. Jarrell <JARRELLRA@VPIVAX3>: Vax Kermit bugs] To: SY.FDC@CU20B.ARPA There was a bug in the remote host MS-DOS Kermit code the very first week we released Kermit (before we'd made any tapes, I think). I thought it was a vax problem until I put remote host commands into unix kermit and had the same thing happen to me! Anyway, it turned out to be an MS kermit bug... if he replaces the MSFILE module with the one on CU20B, the problem should go away. Jeff [Ed. - The current MS-DOS collection is available on CU20B and COLUMBIA-20 (Arpanet/Internet and CCnet) and via KERMSRV (BITnet).] ------------------------------ Date: Tue, 25 Sep 84 00:36:30 pdt From: Dave Tweten <tweten@AMES-NAS-GW.ARPA> To: +outgoing@AMES-NAS-GW.ARPA, INFO-KERMIT@COLUMBIA-20.ARPA Subject: Comments From a New MS-Kermit User I have a variety of questions and comments concerning recent Kermit events. I'm running the PC version of MS-Kermit on a Zenith Z-151, and as a new convert to Kermit, let me congratulate you on a frog well done. In Digest no. 27, Marco Papa discussed an H-19 inverse video problem you aparently found new. I too have experienced strange inverse video behavior using Kermit, with 4.2 bsd UNIX. Our H-19 termcap generates inverse video for underlines in "man" displays. When the last thing on a line is inverse, the spaces after the next line turn inverse too. This behavior is independent of whether or not my system is configured with ANSI.SYS (which someone had earlier stated caused an inverse video problem on the Kermit file transfer "escape character" line). [Ed. - We've had a lot of comments and suggestions about the inverse video business; it should be fixed in the next release.] In Digest no. 26, Mike Iglesias discussed Zenith Z-150 problems running the PC version of MS-Kermit. In addition, the editor requested volunteers to do Z-150 specific modules for Kermit. I don't believe that should be necessary. My friendly local Heathkit store manager assures me that Heath/Zenith regards any such behavior as a bug. Perhaps Mike should check the revision level of his BIOS ROMs. The same store manager informs me that the most recent revision is level 4 (the ones that came with my Z-151, delivered in May, were level 2). [Ed. - Can anybody confirm this from a real Z-150 with the new ROM?] In Digest no. 20, Carl Diegert discussed assembly errors in MSFILE, using MASM revision 1.25. I have revision 1.27, and the same errors. I wholeheartedly endorse his solution. It is even suggested by Intel's ASM86 Language Reference Manual. About LEA, it says, "You should use this instruction only if EA requires run time calculation ... Otherwise, you should use MOV reg,OFFSET variable." [Ed. - The LEA's will be replaced by MOV's in the next release.] After I made Carl Diegert's mod to MSFILE, and assembled and loaded everything, I ran into a bug which is unique to the build-it-yourself version. Whenever I do anything which requires Kermit to crank up another COMMAND.COM (PUSH, LOCAL DIRECTORY, etc.), the system goes into a tailspin that only a warm boot will cure. It endlessly repeats "Specified COMMAND search directory bad". I repeat, this does NOT happen with the Columbia-provided .EXE file. Could someone have debugged Kermit by patching the .EXE without modifying the source? No! [Ed. - Our .EXE is consistent with our source files. A few corrections were made in the first couple days of the current release - late July - and some people may have an earlier source file.] In your announcement of MS-Kermit, and in the User Guide, you mention (the name of) a modem-specific module, yet I can't find any mention of it in the System-Dependent Code Specification. What's the rest of the story? In my opinion, "smart" modem management is the only department in which Kermit does not already surpass its $100 competition. [Ed. - It's the "null module". People with internal modems are invited to contribute modem-specific modules for their particular modems.] Again, many thanks for a job well done. ------------------------------ Date: Sat, 22 Sep 84 18:56:27 edt From: colossus!barmar@mit-eddie Subject: Kermit on Uniplus+ System III Apparently-To: info-kermit@columbia-20 I tried compiling the recently announced revision of Unix Kermit on my Honeywell microSystem NX, which is a 68000 workstation running Unisoft's Uniplus+ System III. The file UXKERUNX.C failed to compile, complaining about the symbol TANDEM being undefined. I thought this version was supposed to work on System III; I believe that TANDEM is a Berkleyism. Has anyone else had this problem? barmar [Ed. - Actually, the new Unix Kermit doesn't claim to run under System III or System IV. That'll be the NEXT release.] ------------------------------ Date: Sun, 23 Sep 84 14:29:11 EDT From: hart%cp1 at BRL-BMD To: Info-Kermit@COLUMBIA-20 Subject: Posting Unix Kermit to Usenet Hi Frank! Are you guys going to post a Unix kermit on Usenet someday? I DON'T need the whole distribution, just the Unix source. Evidentally every micro user already has a copy. Rod Hart [Ed. - I've looked into posting Unix Kermit on Usenet. Turns out that I just don't have a way to do it. Any volunteers? The current release is in KER:UX*.* on CU20B and COLUMBIA-20. There will be a newer release in a few weeks, I hope, so it might make sense to wait a bit.] ------------------------------ Date: Tue 25 Sep 84 09:41:34-CDT From: John Otken <CC.Otken@UTEXAS-20.ARPA> Subject: IOBYTE support in Generic Kermit-80 To: SY.FDC@CU20B Your message provided a good opportunity for me to flame for a while concerning a particular aspect of Kermit which could use some improvement. The problem (at least with the version of Kermit I used) was the way that the generic version is implemented. This version manipulates the IO byte to switch the console to and from the serial port. Kermit insists that it knows the correct values to set the IO byte to and although they may be correct according to the CP/M documents it is NOT the way I have seen many systems impelment it. The way I implemented IO byte control on a file transfer program we use here at UT is to provide a command to set the value of the IO byte used for the serial port. The value used for the console is obviously just remembered from when the program was started. This makes it very easy for people to use because they can try each of the four possibilites in terminal mode. Once the correct value is found it is entered into an initialization file. Now I am not suggesting that you provide a command for this but I am suggesting that you have a single byte at the beginning of the program which includes clear instructions on patching (changing, whatever). As it stands, it took me a serveral hours to go through the source and find all the places which had the IO byte code hard coded in. And I am very confident with 8080 assembler -- I hate to think what a novice programmer might do. BTW, just in case some hot shot sez, "Oh, that guy doesn't know what he is talking about... You can just change the equates.." Well, that doesn't work. I tried that first. Just a suggestion. I think you have done pretty good job wrt kermit. John Otken. ------------------------------ Date: 25 Sep 1984 17:15 PDT From: Charles Carvalho <CHARLES@ACC> Subject: Re: IOBYTE support in Generic Kermit-80 To: CC.OTKEN@UTEXAS-20, SY.FDC@CU20B The "generic" Kermit-80 for CP/M 2.2 (assembly switch GENER) supports six port selections, to improve the chances of finding one that works. Kermit reads from PTR: and writes to PTP: by default; if this does not work, try "SET PORT TTY". The following table lists the CP/M devices used for each option: SET PORT xxx input from output to CRT CRT: CRT: PTR PTR: PTP: TTY TTY: TTY: UC1 UC1: UC1: UR1 UR1: UP1: UR2 UR2: UP2: In all cases, the console (CON:) and list (LST:) devices used are those selected when Kermit is started. /Charles [Ed. - The new version of CP/M-80 Kermit will be announced shortly.] ------------------------------ Date: Tue, 25 Sep 84 16:29:44 edt From: fryback@nlm-vax (Dennis Fryback) To: info-kermit-request@columbia-20 Subject: Rainbow CP/M 86 Kermit Wildcard Send Problem In trying to send a group of files to the remote using a wildcard (for example, "send g:q*.pas") it seems that the rainbow kermit sends the first file to match just fine. But then it signals "completed" and returns to the kermit 86 prompt. I thought this might be a problem with the receiving kermit on our VAX, but when I used mskermit to send a group of files from my PC to the VAX it worked just fine. Is this a bug in rainbow kermit (CP/M-86, version 2.7)? Is there a later version than this one available? Thanks for the help. Dennis Fryback National Library of Medicine (fryback@NLM-VAX) ------------------------------ Date: Tue 25 Sep 84 15:31:03-PDT From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: Re: Rainbow CP/M 86 Kermit Wildcard Send Problem To: SY.FDC@CU20B I haven't experienced this problem at all, but it may be related to the DMA segment initialization which also affected the new directory command. If so release 2.8 would fix it. I use wildcard uploads all the time. Don't Rainbow users do this? Why hasn't the problem surfaced before? -- Ron [Ed. - Actually, the problem occurs in both 2.7 and 2.8, whenever you do a wildcard send from any drive other than your currently logged-in one. Wild sends from the current drive work fine. This problem may be fixed before 2.8 is released, which should be soon.] ------------------------------ Date: Tue 25 Sep 84 13:55:49-PDT From: Ted Markowitz <G.TJM@SU-SCORE.ARPA> Subject: Bug in IBMPC/XT Kermit-MS 'set destination print' To: info-kermit@CU20B.ARPA When using Kermit to dump directly from the host (TOPS-20) to a printer rather than routing it through an intermediate PC file, the next to last packet seems be printed twice. Once in it's normal progression and then again after the last packet has been printed. This happened when downloading a number of files using a wildcard GET command from a server. --ted [Ed. - We'll look into this one, and will try to have it fixed in the next release.] ------------------------------ Date: Wed, 26 Sep 84 9:13:19 EDT From: Dave Swindell <dswindel@bbn-labs-b> Subject: MacKermit Problems with Kermit-10 To: engel@harvard.arpa Cc: info-kermit@cu20b.arpa, hperry@bbn-labs-b.arpa, jhayter@bbn-labs-b.arpa I recently FTP'd the hex file for MacKermit over to one of our UNIX machines dehexified it, and used macput to transfer the output .rsrc file to a Macintosh. When I tried to use the resulting program to connect to a DEC 10 running TOPS 10, I had the following problems: 1) In terminal emulation mode, MacKermit would occationally 'forget' where received characters should be displayed. Fre- quently, MacKermit would overwrite the last line and/or character it displayed. 2) While in terminal emulation mode, MacKermit would bomb out leaving me with the message: System error id=2 (and the little bomb). 3) When I tried to send or receive files to Kermit-10 on our DEC 10, MacKermit would simply hang. I would have to press the reset switch and reboot. I was running at 4800 baud, 8 data bits, 1 stop bit, no parity, and with Xon/Xoff support. I specified 'Macwrite' format for all attempted file transfers. Any help which you could provide in helping us get MacKermit to perform correctly would be appreciated. If you have any questions concerning this message, please let me know. Dave Swindell BBN Labs dswindell@bbn-unix [Ed. - Steve, are you out there? We have been able to transfer files with a DEC-20, which is very similar to a DEC-20, although when selecting MacWrite format, we get an awful lot of junk mixed in.] ------------------------------ Date: Wed 26 Sep 84 16:43:25-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: MS-DOS Kermit 2.26 CRC bug To: Info-Kermit@CU20B.ARPA When you download a file to the PC and the packets are 94 characters long, with CRC's being done, the PC will erroneously detect a bad CRC. If the packet length is 93 or anything less, the CRC is fine. Thanks to Paul Amaranth of Oakland University for the report; he detected it while testing a new release of his Multics Kermit against the IBM PC. - Frank ------------------------------ Date: 26 Sep 84 23:44:04 EDT From: J. Ray Scott <JS5A@CMU-CC-TA> To: sy.fdc@CU20B Subject: MS Kermit vs BF160 We've found that the new MSKermit does not work with the BUF160 program from the INFO-PC program library. Using the two together hangs the PC. In general, the new MSKERMIT is great. Thanks for a great product!! J. Ray Scott [Ed. - I assume BUF160 is one of those programs that expands your DOS typeahead buffer. Another bug to be fixed in the next release...] ------------------------------ Date: Thu 27 Sep 84 16:46:35-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit-MS DOS 1.1 Support To: Info-Kermit@CU20B.ARPA Are there any users of Kermit on MS-DOS or PC-DOS systems who have any good reasons why pre-DOS-2.0 support should be maintained in Kermit-MS? Making the next release of Kermit-MS require DOS 2.0 or above would simplify the program a lot, and it would dramatically decrease the size of the .EXE file (since many of the present static buffers could be allocated dynamically at runtime). Isn't it true that many of the most popular software packages, like Lotus, require 2.0 and above? - Frank ------------------------------ End of Info-Kermit Digest ************************* ------- 4-Oct-84 21:57:17-EDT,30719;000000000000 Mail-From: SY.FDC created at 4-Oct-84 21:57:00 Date: Thu 4 Oct 84 21:57:00-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #29 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Thu, 4 Oct 1984 Volume 1 : Number 29 Today's Topics: New Release of DEC-20 Kermit Kermit-80 for Compupro Interfacer 3/4 Bugs in MS-DOS Kermit Bootstrapping Programs Kermit-MS 2.26 on PC/AT Kermit-MS 2.26 on PCjr Kermit-MS DOS 1.1 Support (several messages) Kermit-MS V2.26 Bug Reports (several) CP/M-86 Kermit Wildcard Send Problem CP/M-86 Kermit Enhancements Posting Unix Kermit to Usenet GCOS KERMIT On the Way 170Kermit on NOS 2.3, Bug Fixes DEC Pro-350 Kermit Suggestions ---------------------------------------------------------------------- Date: Thu 4 Oct 84 09:34:48-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New Release of DEC-20 Kermit To: Info-Kermit@CU20B A new release of DEC-20 Kermit is now available which includes a simple "login script" facility. This new feature allows those who use Kermit-20 in local mode -- out an autodialer, or hardwired TTY port connection to another system -- to automate the procedure for connecting to and logging in on the remote system, either from an interactive terminal or under TOPS-20 Batch. It consists of three new commands: INPUT, OUTPUT, and PAUSE, plus a SET INPUT command to control the characterics of the INPUT command. These may be combined with other Kermit-20 commands in TAKE command files. Nesting of command files provides a way to conditionally execute commands depending on input. Here's a sample script file for logging into a Unix system, sending a file, and logging out. output \15 input login: output myuserid\15 input 10 password: output mypassword\15 input 20 % out kermit r\15 send foo.bar in % out \4 "\15" is a carriage return, "\4" is a Control-D (that's how you log out from Unix), "%" is the Unix system's prompt. The number following the INPUT command is the number of seconds to wait for the requested input before timing out and proceeding to the next command. SET commands are provided for the default INPUT timeout interval, timeout action (quit/pop or continue current command file), and alphabetic case sensitivity in INPUT string matching. Also, CLEAR (buffers) and ECHO commands have been added, for use with this facility, and there are some fancier features for "if-then-else" simulation, allowing you to input data from the terminal during script execution, etc. In addition, this release now includes a TRANSMIT command to perform "raw upload" of a file without packet protocol to a remote system that doesn't have Kermit. The file is sent line at a time, using the desired parity and handshaking, and synchronized with any specified "prompt" (e.g. from a line editor) on the target system, or manually by the user. The script and transmit features will serve as as models for other Kermits. In particular, they will probably find their way into the next release of MS-DOS Kermit. The new Kermit-20 is available via anonymous FTP on CU20B and COLUMBIA-20 as KER:20KERMIT.MAC and KER:20KERMIT.EXE. The new manual chapter, which explains the script and transmit features in detail, is in KER:20KERMIT.DOC (with Scribe text formatter source in KER:20KERMIT.MSS). This chapter has not yet been merged with the Kermit User Guide. - Frank ------------------------------ Date: Thu 4 Oct 84 16:05:50-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit-80 for Compupro Interfacer 3/4 To: Info-Kermit@CU20B.ARPA cc: Info-CPM@AMSAA.ARPA This is to announce KERMIT-80 for Compupro Interfacer 3/4 with CP/M-80 2.2, based on version 3.9A of CP/M Kermit. It includes support for: . Interfacer 3/4 board I/O. . Terminal control sequences for Wyse Technology WY-100. . Racal-Vadic Auto Dial VA212 modem . US Robotics Password modem . Sending break with <ESC> B while CONNECTed. Contributed by: Guy Valiquette, M.D. (PS1.YAAGC@CU20B) Black Bldg. Rm 322 Dept. of Neurology College of Physicians & Surgeons Columbia University 630 W. 168th Street New York, NY 10032 The source is in KER:CPMPRO.M80. The hex file is in KER:CPMPRO.HEX, and a help/installation file is in KER:CPMPRO.HLP. These files are available via anonymous FTP from CU20B and COLUMBIA-20 (after 6pm Eastern time). No attempt was made to build all the other CP/M Kermits from this source, so for now it will have its own. It is expected that Compupro IF 3/4 support will be added to version 4 of CP/M-80 Kermit, the "modular version", soon after version 4 is released. ------------------------------ Date: Fri 28 Sep 84 12:48:34-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Bugs in MS-DOS Kermit Bootstrapping Programs To: Info-Kermit@CU20B.ARPA, Info-IBMPC@USC-ISIB.ARPA The Fortran-Basic program pair that is used for bootstrapping MS-DOS Kermit initially from a mainframe to a PC does not work in certain cases. There were two small problems -- one caused the Fortran program to hang waiting for input (in Fortrans that do not supply default values for missing variables on a READ statement), the other an erroneous GOTO that had the unfortunate quirk of not breaking the program on systems whose Fortran happened to initialize arrays with blanks... Anyway, the fixed versions are available in KER:MSBOOT.FOR and KER:MSPCBOOT.BAS on CU20B and COLUMBIA-20. If you can't (or would rather not) get the new files, the changes are small: In MSBOOT.FOR, after the statement 200 FORMAT(4A1), change GO TO 30 to GO TO 20 In MSPCBOOT.BAS, change line 100 to: 100 print#1,"O ,2" ' Char constants Oh,Space,Comma,Two. Thanks to Jeff Ramsey of DGM&S, Delran NJ, for pointing out these problems. An additional problem has been noted, but not yet fixed. Those who use a file capture facility to download a .BOO file and then run MSPCTRAN directly on the .BOO file should beware of extraneous characters inserted by the host. In particular, some hosts may insert NUL or DEL characters as padding after a carriage return or linefeed. ------------------------------ Date: Wed Oct 3 1984 12:33:51 From: Marco Papa <papa%usc-cse.csnet@csnet-relay.arpa> To: info-kermit%CU20B%columbia.arpa@csnet-relay.arpa Subject: MS-Kermit 2.26 on PC/AT Has anybody tried to run MS-Kermit 2.26 on a PC/AT ? What are the results? Marco USC - Computer Science Dept. [Ed. - It sort of works. We had an AT on loan here for a short while. At first Kermit seemed to work on it -- we could run our video editors while CONNECTed as an H19, we could transfer files, etc. Later, it was discovered that if you issued any REMOTE commands from the AT, the program would bomb with messages like "Drive A not ready" when drive A was not being used at all. Subsequently, we got a floppy disk in the mail from Dale Smith at the University of Oregon Computing Center containing "the single modification necessary to make KERMIT run on the new IBM AT." Here is the change: University of Oregon modifications to the MSRECV module of MS Kermit (01) Modify to work on IBM AT (Version 2.26/UO.01 -- Dale Smith -- 10 Sep 84) A. On the IBM AT, there are a few things that are different. One of them is that on all REMOTE commands, the AT gets an error reading drive A: at the end of the text from the remote host. The problem is apparently that DOS is changed enough that one cannot issue a DOS call to close a file that is not open (?). Anyway, we need to be a little more selective about what we do when we are receiving text from a REMOTE command on a remote host. This edit does just that so Kermit will run unchanged from an IBM-PC/XT to an IBM-AT (two lines added, marked by [UO.0]). rdat35: mov cx,chrcnt mov temp,cx call outbuf ; Output the last buffer. jmp abort ; Give up if the disk is full. mov ax,temp ; Prepare for the function call. cmp flags.xflg,1 ;[UO.0] Writing to screen? je rdat37 ;[UO.0] Yes, skip a bunch of stuff. call fixfcb This fix is as yet untested by us, so we can't guarantee that it works, or that it's the only fix necessary for the AT. Any volunteers?] ------------------------------ Date: 29 Sep 84 10:50:59-PDT (Sat) To: info-ibmpc @ Usc-Isib.arpa From: hplabs!hao!seismo!harvard!wjh12!bbncca!sdyer @ Ucb-Vax.arpa Subject: PCjr and Kermit [Ed. - This is an except of a message that appeared on Info-IBMPC from someone who's had some experience running Kermit on the PCjr.] Enter the PCJr. I was immediately able to purchase a good VT100 emulator/XMODEM program (Mark of the Unicorn's PC/Intercomm). The IBM PC Kermit distribution works fine, too. Either makes a fine remote terminal, and I have had NO problems with XMODEM or KERMIT file transfers at 1200 baud; techies at first worried about the non-DMA disk drive--it locks out interrupts during transfers, meaning that many comm programs might have trouble. Though I grant this, it hasn't been an operational problem. I have noticed one problem with using PC/Intercomm (though not Kermit) at 1200 baud. A nonmaskable interrupt is generated upon receipt of the start bit of a character generated by the keyboard; the BIOS then acts as a software UART, polling for bit transitions to generate the full scan code. This seems to cause occasional problems when I type ahead of the display: PC/Intercomm seems to get out of sync, and generates several characters worth of fully filled white space (VT100 DEL chars.) This may be due to its handling of UART overruns; I can't say yet. I am using version 2.26, and yes, I need to set the RS232 port to COM2. Every now and then I seem to get some anomalies in H19 emulation, but I haven't chased them down methodically, and I never ascribed them to problems with the PCJr, per se. Other than that, file transfers work just fine at 1200 baud without any data loss. I am quite impressed! /Steve ------------------------------ Date: Sat 29 Sep 84 23:42:21-EDT From: Peter D. Junger <JUNGER@CWRU20.CCNET> Subject: Support for MSDOS 1.1 To: info-kermit@CU20B [Ed. - This and the next several messages are in response to my query about continued support for MS-DOS 1.1 in Kermit-MS.] Here at CWRU Law School we have a large number of Victor 9000's and a few IBM PC's which use only DOS 1.1. These machines are used for word processing and there is simply no reason to upgrade them. At the moment we do not make much use of Kermit with those machines, but that situation is likely to change fairly soon since our faculty will probably have more occasion to make use of some facilities on the CWRU DEC20's. I would not suggest, however, that you continue support for 1.1 only for us. I suspect, however, that we are not alone in this conservatism. ------------------------------ Date: Sun, 30 Sep 84 11:43 EDT From: "Eric J. Swenson" <Swenson@MIT-MULTICS.ARPA> Subject: Kermit-MS DOS 1.1 Support To: SY.FDC@CU20B.ARPA I, for one, would be disappointed if MSDOS 1.1 support were removed. I haven't yet been able to get a version of MSDOS 2.0 for my Zenith-100. But if it presents a real programming obstacle to maintain support for both, as long as you still provide a (the current) version of Kermit 2.26 (which supports both) then we 1.1 users can survive. But please, don't make us have to use Kermit 1.20. -- Eric ------------------------------ Date: Sun 30 Sep 84 16:21:24-PDT From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: MSDOS 2.0 To: SY.FDC@CU20B.ARPA In response to your last question in the info-kermit digest, on the APC the only versions of MSDOS that are available are 2.0 or above, so in this particular case there is no reason to retain pre-2.0 support. I agree that loading 80-some K to bring up Kermit is excessive. Even the 18K for 86kermit seems too long at times. -- Ron ------------------------------ Date: 1 Oct 1984 8:46:24 EDT (Monday) From: Earnie Boyd DRSTE-CM-F 4377 <eboyd%apg-1@columbia.arpa> Subject: 1.1 Support To: Frank da Cruz <SY.FDC@CU20B> Frank, For the H/Z100, LOTUS 123 runs under either version of Z(MS)-DOS. Under the GEA contract, Zenith is still delivering version 1.2. I don't know what is being delivered to the AF and Navy. Earnie ------------------------------ Date: Thu, 4 Oct 84 15:24 EDT From: Schauble@MIT-MULTICS.ARPA Subject: MS DOS version 1.1 support for kermit To: sy.fdc@CU20B.ARPA I would suggest that you forget about version 1 for any new work. Keep a copy of the last version that handles version 1 and freeze it. There are very few people still using version 1, it's not even available for some of the newer machines. [Ed. - Our current plan is to fix all known bugs in 2.26 and release the result as, say, 2.27 with continued DOS 1.1 support. After that, we'll strip out the 1.1 support before adding any new features. The program is simply much too big the way it is now.] ------------------------------ Date: Thu 4 Oct 84 02:14:25-PDT From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: MSKermit bug To: info-kermit@COLUMBIA-20.ARPA I haven't seen this one reported so I will. The counter for number of Kbytes transferred has a couple of problems, the first of which is that the display is not cleared between files in a wildcard transfer, so that the early (single) digits of the new file are followed by the last digits registered for the previous file. The second problem is that when the count passes 63 Kbytes, instead of 64 the count jumps to 1024 Kbytes and continues from there. These are only minor annoyances and don't adversely affect the program's operation. -- Ron [Ed. - These are the most widely reported bugs in 2.26; I probably forgot to post any of the reports to Info-Kermit. The Kbytes display will be fixed in the next release of Kermit-MS.] ------------------------------ Date: 1-Oct-84 11:50:11-PDT From: wunder@FORD-WDL1.ARPA Subject: Inverse video problems with MS-Kermit To: info-kermit@CU20B.ARPA About inverse video in the MS-Kermit H19 emulation: You might check this against some program other than Unix "more" (the pager used to display man pages, among other things). Our copy of "more" does a bad and buggy job of handling inverse video. I have seen it highlight an entire line following a highlighted word. It also ignores some termcap fields (like "leaves extra space when entering/leaving standout"). This may be due to misuse of termcap, or general braindamage. In short, test the H19 emulation with something more reliable than "more" before you try to fix a problem. walter underwood ------------------------------ Date: Fri 28 Sep 84 10:14:08-EDT From: Susan Zayac <US.SUE@CU20B.ARPA> Subject: ^Z EOF in MSKERMIT To: sy.fdc@CU20B.ARPA I just tried KERMITing a FinalWord file from the XT/370 to the DEC20B with EOF set to CTRL-Z and the ^Z at the end of the file still came over. All the otehr settings were teh defaults. Any advice? Sue/ [Ed. - It's a bug, see below.] ------------------------------ Date: Tue, 2 Oct 84 08:02:39 pdt From: dual!islenet!david%Berkeley@columbia.arpa To: Info-Kermit@CU20B Subject: Kermit-MS V2.26 Aloha - After a couple of weeks with V2.26 of Kermit-MS, here's a collection of comments. First, from one of my most serious Kermit users (he adapted V1.18 for his NEC APC under both MS-DOS and CPM-86): ///////// * David - The MSFILE module has two rather substantial bugs: * * 1. When sending, it puts an unquoted 00H byte in the first position * of the data field of all F and D (data) packets. This extraneous * byte screws up the chr count for file closing because it is * usually (but not always) compensated for by a second bug that * miscounts the chars - depending on the exact file length. At * the receiving end the unquoted `null`s get filtered out and do * not usually get in the way. They do not show up when debug is * set on, since they are also filtered out by the display routine, * although you can detect them if you look at the charcount char * in the packet. * * 2. Possibly as a consequence of the above, the EOF CTRLZ file * closing routine gives unreproducible results during both recceiving * and sending , and it does not perform at all as described in the * new MSKERMIT section of the users-guide. * * I have identified the source of the first bug as in the * ENCODE routine in MSFILE, but I don't have a fix yet. The second * I don't consider worth looking at until the first has been fixed. * * Naturally I would prefer taking ready-made fixes if they are available, but * if not they are not I am prepared to put in a modest ammount of time myself. * * Ian \\\\\\\\ I advised him to hold off until I hear back as to whether these are problems you might already be working on (Bill mentioned that there were some bugs that had already been fixed). [Ed. - The CTRLZ business definitely doesn't work right, but we're not sure the diagnosis above is correct, though we'll certainly check it. Another possible problem is that ENCODE is checking for a Control-Z AFTER it has been encoded to #Z, so naturally it won't find it. See next message.] Second, I've done the following simple mods which I can send if you're interested: 1) Moved the "plus key thing" which toggles the status line in MSYIBM to AFTER the key translate table consultation, so that the plus key can be redefined if desired. Then I can use SET KEY to redefine the keypad plus to be H19 ENTER, since it's in the perfect location. [Ed. - Good idea, we'll move it.] 2) Added a module to MSXIBM and code in MSTERM for an ESCAPE-D command to drop the communication line for 3 seconds. This hangs up on our Gandalf PACX (and many modems) so that I can select another computer without turning off my PC or pulling the connector out of the comm port. Code to drop DTR was added in the style of the existing BREAK (ESCAPE-B) code. [Ed. - Good idea, we'll add it.] 3) Added code to MSYIBM to make the IBM PC F10 key, if not redefined, behave like the SCROLL/NO SCROLL key on DEC terminals; it sends ^S and ^Q on alternate keypresses. Note that this is NOT how the H19 scroll key behaves (but I wish it were). [Ed. - Tough to make that one machine independent; better just to use two keys, defined with SET KEY commands.] 4) I also have an mskermit.ini file which makes the shifted keypad behave like the H19 keypad. [Ed. - I'm sure lots of people would find this useful.] Finally, another question: is there any way to put a SET KEY SCAN command into a macro? The macro seems to terminate at the end of line, and SET KEY SCAN seems to require 2 lines. Would be nice for when I switch between systems that use DEL and BS for rubout. Current I TAKE a file to redefine the backarrow, but I'd like to eliminate the disk access. [Ed. - Yes, just separate the two parts of the command by a comma.] With this release I now use Kermit as my standard terminal package, replacing my $100 VT-100 emulator. I drag that out only for file transmits to our as yet un-Kermitted systems: an HP-3000 (no Software Tools) and MVS/TSO (see next note). Thanks! David Lassner, University of Hawaii Computing Center ------------------------------ Date: 26 Sep 84 17:47 +0200 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Info-Kermit <info-kermit@COLUMBIA-20> Subject: Bug (?) in MSSEND.ASM Someone here found a bug in MSSEND.ASM -- End-Of-File is not correctly treated. Here's a FILCOM listing of his hacks: File 1) DSKA:MSSEND.ASM[5,61] created: 0056 24-Jul-84 File 2) DSKG:MSSEND.ASM[60,203] created: 1213 19-Sep-84 1)1 cmp al,'Z'-40H ; is it a ctl-z? 1) je sdata5 ; yes, break loop 1) stosb ; else copy it 1) loop sdata4 ; and keep going **** 2)1 ; cmp al,'Z'-40H ; is it a ctl-z? 2) ; je sdata5 ; yes, break loop 2) ; stosb ; else copy it 2) cmp al,trans.squote ;* Bug fixed 84-09-18 CB/Paralog 2) jne sdat41 ;* if not quote carry on 2) stosb ;* else store quote character 2) dec cx ;* decrement size 2) lodsb ;* get next byte 2) cmp al,'Z' ;* have we detected a ctl-z? 2) jne sdat41 ;* no, continue loop 2) inc cx ;* 2) inc cx ;* dont send quote character 2) jmp sdata5 ;* break loop 2) sdat41: stosb ;* no, copy it 2) loop sdata4 ; and keep going ************** [Ed. - Actually, the check could be made earlier, before/during the encoding. The CTRLZ bug will be fixed in the next release.] ------------------------------ Date: Tue Oct 2 1984 14:25:17 From: Marco Papa <papa%usc-cse.csnet@csnet-relay.arpa> To: US.JD%CU20B%columbia.arpa@csnet-relay.arpa Subject: Re: received floppy Jeff, Glad you got the floppy. Since I'm here, I'll report another bug of MS-Kermit 2.26 (I don't recall of having seen it yet in the digest). My XT has MSKERMIT.INI that does a SET BAUD 1200. I usually use COM1:, but use COM2: sometimes. When I execute the command SET PORT 2 (or COM2), the new port is chosen but the baud rate is screwed up, and a STAT command will say: Baud rate is unknown If then I SET PORT 1, the baud resets back to the original 1200 bauds. Marco [Ed. - We'll check this one, too, and fix it in the next release if it needs fixing.] ------------------------------ Date: Wed 26 Sep 84 15:53:07-PDT From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: Re: Kermit-86 wildcard send problem To: Info-Kermit@CU20B The problem does indeed occur on the APC as well. Good work in pinpointing it, Frank. I found the bug; a minor omission in the code of finding the next file. The new version of 86KERFIL.A86 containing the correction is now on my account for uploading. There are also new versions of APCKERMIT.H86 and APCKERMIT.CMD which work correctly. -- Ron ------------------------------ Date: Sun 30 Sep 84 16:05:27-PDT From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: 86kermit To: SY.FDC@CU20B.ARPA Frank, Sorry if this causes you extra trouble. I've taken advantage of the delay in releasing version 2.8 to improve it somewhat. In particular, the directory list has been changed to appear in sorted columns with the size of each file displayed next to the name. There is also a total of number of files and Kbytes listed. A second change is the addition of the local DELETE (or synonymously ERASE) command for removing files. Each file that matches the wild filespec entered is displayed for verification before deletion. At that time, a 'Y' entry deletes the file, 'N' skips to the next file, and ESC aborts the delete routine. Entry of a '?' displays a help message listing the available options. Also, in view of the comments in the last info-kermit digest about the 8086 LEA command, I've changed all the occurrences of LEA xx,yy to MOV xx, OFFSET yy in all of the modules of 86kermit. There were no occasions whatsoever where the address needed to be computed at run time rather than compile time. The source files and APC assembly files are available as usual on my account. You should upload all of the files, since there has been some reorganization of the code to equalize file sizes. -- Ron [Ed. - Version 2.8 of CP/M-86 Kermit will be announced shortly.] ------------------------------ Date: Fri, 28 Sep 84 11:15:20 cdt From: knutson@ut-ngp.ARPA (Jim Knutson) To: sy.fdc@cu20b Subject: Re: Posting UNIX Kermit for usenet I posted a copy of it to usenet for you. ------------------------------ Date: Fri 28 Sep 84 18:19:52-PDT From: Bob Larson <Blarson@Usc-Ecl> Subject: Posting Unix Kermit To: info-kermit@CU20B.ARPA I belive if you mail the source to unix-sources@brl it will be forwarded to net.sources on uucp. Notices of posting to info-unix and unix-wizards would probably be nice. Someone just posted it so don't repost until you have a new version. Bob Larson <Blarson@Usc-Ecl> [Ed. - Thanks, Jim, Bob, and everyone else who responded. Now I know how to do it next time.] ------------------------------ Date: Thu, 27 Sep 84 07:41 MST From: Terry Carlin <Carlin@HIS-PHOENIX-MULTICS.ARPA> Subject: GCOS KERMIT To: SY.FDC%CU20B@COLUMBIA-20.ARPA Frank, I just put the GCOS versions of KERMIT in the mail. It includes a 'PRINTABLE' version and an assembly language program to recreate the system loadable file. If you have any problems reading the tape etc, please yell. Terry [Ed. - Will announce it as soon as it arrives. Also included is the C language source. It runs on DPS/8 and DPS/6 systems with either GCOS8 or GCOS3. There's also an adaptation of IBM PC Kermit 1.20 for the Honeywell MicroSystem 6/10.] ------------------------------ Date: Tue, 2 Oct 84 21:17:19 pdt From: Dave Tweten <tweten@AMES-NAS-GW.ARPA> To: INFO-KERMIT@CU20B.ARPA Subject: 170Kermit on NOS 2.3, Bug Fixes In a selfish attempt to get Kermit implemented on a machine I occasionally use, some time back I gave a copy of the latest 170Kermit to a friend at CDC's Sunnyvale installation, Ted Brown. I succeeded beyond my greatest expectation. Not only does it work well on the Sunnyvale CDC machines, but Ted offered to let me relay what he learned about 170Kermit back to Info-Kermit. If you wish to communicate to Ted through the net (CDC Sunnyvale isn't connected), feel free to relay the message through me. What follows is Ted's message: Date: 2 October 1984 To: Info-Kermit@CU20B.ARPA Knutson@UT-NGP.ARPA Russel@NYU.ARPA From: Ted Brown, Control Data Corporation Subject: Corrections to Kermit-170 Version 2.2 for NOS I recently received a copy of Kermit-170 Version 2.2 and encountered some problems when installing and executing it in the standard release of NOS Version 2.3 (PSR Level 617). Following is a description of each problem, and attached to this letter is a NOS CCL procedure that properly installs Kermit-170 with corrections for all the problems. The procedure assumes the existence of a direct access permanent file named KERMITS that contains the UPDATE source for the Kermit PL in the first logical record and the source for the AZLIB PL in the second. 1. The installation instructions in the documentation file are missing some parameters and control statements. 2. Assembly errors occur due to incorrect usage of quotation marks and apostrophes in micro definitions. 3. The default data mode (DISPLAY) is inconvenient. ASCII would be more appropriate for the majority of file transfers. 4. The terminal parameters for PW, PG, and EB are not restored after terminating binary mode. Although it is not possible to determine their original values, they could be set to something with less negative impact for the majority of users. 5. Subroutine CONBUFF aborts if Kermit is not compiled with OPT=0 due to an instruction that is overwritten by subroutine CFE when it clears the FET that is adjacent to CONBUFF's entry point. 6. Single-character inputs are incorrectly processed. Specifically, a question mark for help is not recognized due to a parsing error in subroutine CONBUFF. Please feel free to contact me if you have any questions about my code. Thank you very much for the excellent job that you are doing to support and distribute Kermit! Ted Brown Central Software Support Control Data Corporation 215 Moffett Park Drive Sunnyvale, California 94089 Let me add that if you accept Ted's proposed change of the default character code, a change will be required in the documentation for SET DATA-MODE. [Ed. - The updates are rather long, and were omitted from this message for brevity's sake. They can be found in KER:170KERMIT.BWR on CU20B or COLUMBIA-20. Also, note that this message, including the updates, were sent directly to Jim Knutson, the original author of the program.] ------------------------------ Date: 4 Oct 84 16:54:04 EDT From: Chris Koenigsberg <CK0C@CMU-CC-TE> To: info-kermit-request@CU20B Subject: DEC Pro-350 Kermit suggestion I work in an office with an IBM PC and a DEC/PRO 350. The Kermit-MS for the PC is fantastic. The Kermit for the PRO is better than the DEC Communications package, but it would be really nice to have the key redefinition feature added to PRO 350 Kermit, so we could put the Escape key back where it belongs (I see from the Kermit-MS manual that this feature is used on the DEC Rainbow, which shares the awful new keyboard with the PRO). Another feature from Kermit-MS, which is also available in Dec/Pro Communications but not Pro Kermit, is the log file. If there were capability to open a log file for host output, we would delete the PRO/Communications package entirely from our PRO disk and just use Kermit instead. As it is, we need both packages, simply because of the need to log a terminal session once in a while using the DEC-supplied program. Chris Koenigsberg Urban Systems Institute MM204 SUPA (412)578-2175 Carnegie Mellon University [Ed. - The Stevens folks have been pretty swamped lately supporting their Pro-350's -- something like 1400 of them! -- so don't expect any enhancements any time soon. Still, I'm sure they'll appreciate the suggestion.] ------------------------------ End of Info-Kermit Digest ************************* ------- 8-Oct-84 18:10:18-EDT,17385;000000000000 Mail-From: SY.FDC created at 8-Oct-84 18:08:35 Date: Mon 8 Oct 84 18:08:35-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #30 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Mon, 8 Oct 1984 Volume 1 : Number 30 Today's Topics: Kermit Arpanet Distribution Kermit for Honeywell GCOS Kermit for Honeywell MicroSystem L6/10 Oh no, Another Kermit! (Sperry) CP/M-80 Kermit Tools MS-DOS Kermit Bootstrapping Problem MS-DOS Kermit Set Baud/Set Port Unix Kermit Suggestions ---------------------------------------------------------------------- Date: Mon 8 Oct 84 15:15:39-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit Arpanet Distribution To: Info-Kermit@CU20B.ARPA I'd like to phase out network Kermit distribution from COLUMBIA-20 as soon as possible. I've been advertising new versions available from CU20B for the past month or so, and have seen anonymous users from many sites connected to our FTP server. Unless I hear of serious problems with our FTP service, I will be deleting the Kermit files from COLUMBIA-20 on Monday, October 22. If there are problems with FTP, of course we will attempt to fix them. But bear in mind that the files have to be removed from COLUMBIA-20 anyway; the owners of that machine need the space back. For those who missed previous announcements to this effect, and have not yet placed CU20B in their host tables, CU20B is Internet host 192.5.43.128. FTP to CU20B works in the normal way. Connect to host CU20B (or use the host number if the name is not known), login as user ANONYMOUS, supply any non-null password, and then use the DIRECTORY, GET, and MULTIPLE GET commands in the normal fashion. CU20B is a DECSYSTEM-2060 at the Columbia University Center for Computing Activities. Currently there are no restrictions on the number or time of anonymous FTP logins, but since CU20B is a busy system such restrictions may become necessary if FTP access interferes with normal operations. Please be selective about what files you take, since the current collection takes up about 20 megabytes and is still growing. The CU20B Kermit directory is organized a little bit differently from the one on COLUMBIA-20. COLUMBIA-20 has all the Kermit-related files in a single monolithic directory, <KERMIT>. CU20B maintains several directories, as follows: Directory Name Logical Name Contents <KERMIT> KER: Kermit programs: source and hex, manuals, help files, and other printable ASCII files. <KERMIT-BINARIES> KB: Executable program images for various Kermit programs (not hex, real binary). <KERMIT-TOOLS> KT: Cross assemblers and similar utilities used in building or maintaining Kermit programs on DEC-20s or DEC-10s, sources and binaries. <KERMIT-EXTRA> KE: Extra, redundant, old, or variant versions of Kermit. A "logical name" serves as an abbreviation for the longer directory name. For instance, KB:FOO.EXE is a short way to type <KERMIT-BINARIES>FOO.EXE. The logical name KER: is defined to search all of these directories in order, so that KER:20KERMIT.EXE will still find the DEC-20 Kermit executable program file. However, KER:20*.* will find the sources and documentation (which are in a directory higher in the search order) but skip the binary. If you want to get all the files for a Kermit version that comes with both text and binary files, you'll have to look in both places. To get all the DEC-20 Kermit files with FTP, for instance, you should "MULTIPLE GET KER:20*.*" and then "MULTIPLE GET KB:20*.*". Why are the files organized in this inconvenient way? And since we're discussing how the files are organized, why not break them up even further into directories or subdirectories for each Kermit implementation, as many have suggested? It's because this same system (CU20B) is where Kermit distribution tapes are made, most of them in ANSI format. An ANSI tape is structureless -- there are no directories or subdirectories; every file on the tape must have a unique name. Furthermore, many of these tapes are destined for systems that have flat file systems and/or short or otherwise restrictive filenames. For instance, many DEC operating systems allow filenames with only 9 characters (6-dot-3) and forbid punctuation characters like dash. Therefore, all the files in the distribution have: . Names that are unique within 6-dot-3 format. . A period between file name and file type. . Only letters or digits in the name and type. Each implementation has its own prefix, e.g. "20" for the DEC-20, "MS" for MS-DOS, etc. Since files are stored in alphabetical on the DEC-20, all files for a particular implementation will be grouped together in directory listings, or on a distribution tape, or when sent by FTP in response to a MULTIPLE GET command. The binaries have been separated from the printables because binary files and ANSI tapes do not mix well. The tools and extras have been moved to separate areas simply because they no longer fit on a 1200' reel of tape at 1600 bpi. As the size of the collection continues to grow, further measures along these lines may be necessary. Here's a reminder about some special files designed to cut down on network traffic by answering the most common questions about Kermit: KER:CURRENT.DOC - Lists in reverse chronological order all the versions of Kermit that we have "in stock" -- new additions at the top. Answers questions like "Has there been a new release for VMS since last November?" KER:VERSIONS.DOC - Lists all knows implementations of Kermit, whether we have them or not. Answers questions like "Is anybody working on a Kermit for the Widget-8000?" KER:00README.TXT - Tells what files are available in the Kermit distribution and lists the prefixes for each implementation; answers "How do I find Kermit for the Luxor ABC-800?" Note the two leading zeros in the file name; this ensures that this file comes first in a directory listing or on a tape. KER:FLYER.DOC - Explains our tape distribution policy; answers "How do I order a Kermit tape?" KER:COMMER.DOC - Explains our policy toward commercial use and distribution of Kermit; answers "Can I include Kermit in my terminal emulation package that I want to put on the market?" All these files are kept up to date. Please try FTP to CU20B before Oct 22. If you can't reach CU20B from FTP, complain to your site manager. If there turns out to be some "structural" reason why your site can't FTP from CU20B (e.g. too many internet hops), there's not much I can do. If you have any other problems, please convey them directly to me. - Frank ------------------------------ Date: Fri 5 Oct 84 18:37:09-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit for Honeywell GCOS To: Info-Kermit@CU20B.ARPA This is to announce KERMIT-GCOS for the Honeywell DPS 66 and DPS 8, running either GCOS8 or GCOS3. The program is written in the C language, adapted from Columbia University Unix Kermit, and is distributed in both source and printably-encoded binary form, so that GCOS sites without the appropriate C compiler can still run the program. Contributed by: Terry Carlin, Carlin%pco@MIT-MULTICS Honeywell Information Systems Inc 7900 Westpark Dr. McLean, Virginia 22102 (703) 827-3481 The files are in KER:HG*.* accessible via anonymous FTP from CU20B or COLUMBIA-20 (after 6pm eastern time). KER:HGKER.HLP lists the files and tells what each is for. All files in KER:, no binaries. ------------------------------ Date: Fri 5 Oct 84 18:37:51-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit for Honeywell MicroSystem L6/10 To: Info-Kermit@CU20B.ARPA This is to announce Kermit for the Honeywell MicroSystem L6/10 with version 2.11 of MS-DOS, contributed by Terry Carlin of Honeywell, McLean Va., Carlin%pco@MIT-MULTICS. It's an adaptation of version 1.20 of MS-DOS Kermit, but it comes with a ".BOO" file in the style of version 2.26 of Kermit-MS, and with a special adaptation of MSPCTRAN.BAS to decode the .BOO file. Terry is still working on an adaptation of 2.26 for the 6/10; he says he's having problems with the file system interface and server mode, possible due to the 6/10 using an 8086 instead of an 8088 (hints, anyone?). The files are in KER:HL6*.*, available as usual via anonymous FTP from CU20B or COLUMBIA-20. All files in KER:, no binaries. ------------------------------ Date: Thu, 04 Oct 84 14:51:26 EDT From: Edgar B. Butt <BUTT@UMD2.ARPA> To: sy.fdc@cu20b Subject: Oh no, another Kermit! Here is a Kermit implementation for the Sperry 1100 systems written in Pascal. It has been run successfully here at the University of Maryland, College Park, and at SUNY, Albany. Please add it to your selection of Kermits. I would appreciate feedback from anyone who tries it. The first page of code consists of comments explaining how to use and generate Kermit1100. Hope someone finds it useful, Edgar Butt (Butt@umd2.arpa) Computer Science Center University of Maryland College Park, Maryland 20742 (301) 454-2946 KERMIT1100 is yet another Kermit written to run on the Sperry (Univac) 1100 series of computers. It is written in Pascal to be compiled on the NOSC Pascal Compiler, version 2.2 or later. This compiler is available from the Computer Science Center of the University of Maryland, College Park, for a nominal service charge. Kermit aficianodos may notice that the structure of this version differs from other versions in that packets are read and sequence checked in the main program loop and are then dispatched to the proper input or output state with a single case statement. This structure has allowed the various state processes to be relatively uncluttered. While doing this implementation I discovered that NAK's are like tadpole tails. They seem like a neat idea at first, but as the frog emerges, they serve no useful purpose. Likewise, I have been unable to find a case in which NAK's are necessary. Sending an ACK for the last good packet received is just as good. If I'm wrong, I am sure that some swamp dweller out there will let me know. (Not to worry, I handle incoming NAK's even though they are not necessary.) By way of a quick synopsys of features, this version of Kermit has: Simple server mode - processes S and R packets 8-bit quoting (Turned on by Q-option) Repeat count prefixes Error packet generation and processing [Ed. - It's in KER:UNIVAC.PAS on CU20B.] ------------------------------ Date: Mon 20 Aug 84 13:28:00-PDT From: Bruce Tanner <CERRITOS@USC-ECL.ARPA> Subject: CP/M-80 Kermit Tools To: cc.fdc@COLUMBIA-20.ARPA I have new versions of HEXIFY and HEXCOM for both TOPS-10 and -20. The -20 versions do long file names and wild-cards and all that good stuff (I think - check them out and let me know). HEXIFY also now does zero compression. See 10HEXIFY.MAC 20HEXIFY.MAC 10HEXCOM.MAC and 20HEXCOM.MAC. LINK80 will now merge absolute .HEX files. I'd like to try out the new Kermit-80 and modify MAC80/LINK80 to do the right thing. Also, I got tired of trying to figure out which INCLUDE file the MAC80 listing was showing, so I modified MAC80 to display the included file name in the page heading. MAC80 version 10F is in <CERRITOS>. -Bruce [Ed. - A complete new set of Bruce's 8080/Z80 cross development tools for the DEC-10/20 is in KT: on CU20B, named as shown above. KT:M*80*.* will get all the MAC80 files. KT:*HEX*.* will get the hexifier and dehexifier. KT:*ORTUR.* will get the "torture" tests for MAC80. CP/M users who have access to a DEC-10 or DEC-20 should try these out -- they are fast!] ------------------------------ Date: Thu, 4 Oct 84 18:36 EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: MS-DOS Kermit Bootstrapping Problem To: Info-Kermit@CU20B.ARPA I have received a number of calls from MS-DOS Kermit users who have been attempting to bring up the new version by using a file capture utility (for instance, the 3101 emulator you get with the IBM async communication package) to get the new .BOO file and then convert to .EXE format with MSPCTRAN.BAS. There is a potential problem with downloading a .BOO file using a non-protocol (e.g. not Kermit, Modem7, etc) method. The host may be sending padding or screen formatting characters, the screen capture program may be doing things behind your back, etc. Unfortunately, the MSPCTRAN program is not very robust in terms of screening out invalid characters; we'll have to fix it. This mightinvolve a slight change in the .BOO file format. - Frank ------------------------------ Date: Fri 5 Oct 84 12:43:20-EDT From: Jeff Damens <US.JD@CU20B.ARPA> Subject: MS-DOS Kermit Set Baud/Set Port To: sy.fdc@CU20B.ARPA The problem mentioned in the latest Kermit digest (setting baud, setting port, having baud be undefined) is sort of a feature... the ports have different baud rates, so that setting the baud rate only affects the current port. If you set the port first, it works fine. Jeff [Ed. - Sorry, I should have caught this. Yes, we designed it this way on purpose. The SET BAUD and other comm-line related SET commands refer to the currently selected port. If you have two ports on your PC, for instance, your MSKERMIT.INI file can set different parameters for each, e.g. set port 2 set baud 1200 set parity mark set port 1 set baud 9600 set parity none This file sets up the two ports as shown, leaving your current port to be COM1 at startup. You can then switch back & forth simply by issuing SET PORT commands, and the parameters for each port will be remembered. This is all documented in the manual.] ------------------------------ From: ukma!david@ANL-MCS.ARPA (David Herron) Date: Thu, 4 Oct 84 16:24:07 edt Subject: Unix Kermit Suggestions To: anlams!info-kermit@columbia-20.ARPA Frank, I have some comments to make about a UNIX kermit. I have had kermit for a couple of years now and am happy with it as is (for the most part). I would like to see a server of course, and support of the newer (fancier) parts of the protocol. Other people here would like to have it be like the other kermits (i.e. a command level and modes and such like). On the other hand, I have a shell file that looks like this: #! /bin/csh kermit clb /dev/tty$1 300 <<! send $2 ~. ! kermit rlb /dev/tty$1 300 and is driven by another script like this: #! /bin/csh get ha file.1 get ha file.2 kermit clb /dev/ttyha 300 <<! ^C^C quit k/n ! I have been using this to transfer batches of files from a DEC-10 at the University of Louisville to here. I would like to be able to do this kind of thing. Another thing that would be nice is to use the server as a file server. (I envision something like the PCinterface program that AT&T has for the 3B series...They have drive C be a serial (or ethernet) link to a process logged in on a 3B, file accesses to drive C access files on the 3B.) To do this using kermit I would have to have the server as a seperate module. (have the server be their login shell... much like uucp has uucico as its' login shell). What I propose is to have 3 seperate processes making up the UNIX kermit. One is a command interpretor which would be used in most "normal" situations where one just wants to interact. The other two are the server and file transferer. The command interpretor would call the other two as necessary. One question in my mind is "Is the protocol to transfer one file self-contained enough to allow it to be off in another process?" I understand most of the protocol, but have never used a server and have never had reason to understand what this has done to the protocol. The little bit I have looked at it says this can be done...... Another way to implement this would be with conditional compilation from one (group of) source... (On little machines I see problems with starting up a new process for each file transfered.) Thank you, David Herron Arpa: ukma!david@ANL-MCS uucp: ...{ucbvax,boulder,research,unmvax}!anlams!ukma!david ...decvax!ucbvax!anlams!ukma!david Snail: University Station PO Box 780 Lexington, KY 40506 Phone: (606) 257-4244 (work, phone will usually be answered as "Vax Lab"). [Ed. - More good ideas for the "real" Unix Kermit...] ------------------------------ End of Info-Kermit Digest ************************* ------- 10-Oct-84 17:33:53-EDT,12124;000000000000 Mail-From: SY.FDC created at 10-Oct-84 17:29:40 Date: Wed 10 Oct 84 17:29:40-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #31 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Wed, 10 Oct 1984 Volume 1 : Number 31 Today's Topics: Version 2.8 of CP/M-86 Kermit Available New Apple II DOS Kermit Apple-Cat Support in Kermit-65? Macintosh Kermit Help Wanted Making MS-Kermit Work on the TI Professional Venix Kermit? Pro/Kermit and TMS? Getting Connected vs EOL ---------------------------------------------------------------------- Date: Wed 10 Oct 84 13:25:02-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Version 2.8 of CP/M-86 Kermit Available To: Info-Kermit@CU20B.ARPA This is to announce version 2.8 of CP/M-86 Kermit for the DEC Rainbow and the NEC APC. Most of the work was done by Ron Blanford at the University of Washington (CONTEXT@WASHINGTON). The substantive changes are as follows: The current defaults of drive and user number are now displayed in the command line prompt, for example: Kermit-86 B3> The SET DEFAULT-DISK option has been implemented to allow specification of the default drive and user number for subsequent file reception and transmission. The specification following the command must be in one of the following forms: d: = go to drive d (A through P) without changing user u: = go to user u (0 through 15) without changing drive du: = go to drive d and user u : = go to the defaults when Kermit was loaded Whenever a drive is specified, even if it is the same as the current default drive, the drive is logged in so that disks can be swapped without exiting Kermit to type control-C. Kermit restores the original drive and user upon termination. LOCAL commands added: DELETE, DIRECTORY, SPACE. The DIRECTORY command shows both the name and the size of each file. The "LOCAL" prefix is optional. "RECEIVE filename" was changed to behave the way it's supposed to -- it passively waits for a file to arrive, then stores it under the given name, rather acting like "GET filename" as it did in previous versions. If a wildcard is given in the filename, it is used as a mask for incoming filenames. A couple fixes were made that apply only to the DEC Rainbow: A BREAK now lasts exactly 250 milliseconds, as it's supposed to (from Bernie Eiben at DEC). The system no longer hangs when the printer is turned off or on or has its hood lifted. However, Print Screen and CTRL-Print Screen still don't cause any printing to occur during CONNECT. (Fix contributed by Paul Ford, U. of Chicago Graduate School of Business.) The files are available via anonymous FTP from CU20B as: KER:86*.* Source, documentation. KER:APC*.* Hex (.H86), and help files for the NEC APC. KB:APCKERMIT.CMD Binary, executable program for NEC APC. KER:RB*.* Hex, help for DEC Rainbow 100 KB:RBKERMIT.CMD Binary executable program for Rainbow. The documentation includes a revised help file and a new Kermit User Guide chapter (not yet incorporated into the manual itself). ------------------------------ Date: Tue 9 Oct 84 21:39:46-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New Apple II DOS Kermit To: Info-Kermit@CU20B.ARPA A new version of Apple II DOS Kermit has been received from Olaf Pors, University of Virginia. This version is a hand translation of the Stevens version, which is written in the DEC-10/20 CROSS language, to the Apple 6502 Editor/Assembler, allowing the program to be assembled directly on the Apple II. This should prove enormously handy for those Apple II Kermit users who don't happen to have a DEC-10 or DEC-20 handy. In addition to the translation, Olaf made the following changes (this is verbatim from his documentation): Several bugs were fixed: 1. Allow for noise characters which could cause the packet to be larger than the maximum expected size. Previously, important cells would be overwritten. 2. Incorrect file headers were being sent due to bad code at SFILE1E. 3. 8-bit quoting was not working due to a problem at SPAKDC. The parity bit on characters received from the communications line was not being cleared before being added into the checksum. Also, apparently an N received in the 8-bit-quote character field of an ack-init was being misinterpreted as the actual 8-bit-quote character to be used. Some work was done to attempt to get 8-bit quoting to work, but the work was not completed. 4. The CONNECT command was not in the HELP display. Several changes were made for convenience : 1. The SHOW command now only shows all parameters at once. 2. The FILE-TYPE keyword was changed to FILE-MODE. 3. ASCII was made a synonym for TEXT. 4. The screen was not cleared for every packet transmission. 5. The communication line access primitive routines were changed to work with a CCS 7710A or SSM AIO board, and were moved to the start of the object file with some extra space, in order to allow the machine code to be changed by hand for other serial cards, rather than having to reassemble all the source. The program comes in two files, one for reading, the other for assembling. The reading file contains comments, punctuation, etc; the assembling file has all these stripped out, resulting in a much smaller file. The reading file is in KER:AP2KER.TXT, the assembling file is in KER:AP2KER.ASM. Since this program closely parallels the Stevens version, it is hoped that something can be done about reconciling their differences. On the one hand, it's nice to be able to assemble it quickly on the -10 or the -20, but on the other it may be nicer to have it portable (especially since it looks like the Apple II line will outlive the DEC-10/20 line). ------------------------------ Date: Wed 10 Oct 84 07:16:26-EDT From: Anton Mione <OC.MIONE@CU20B.ARPA> Subject: Re: New Apple II DOS Kermit To: SY.FDC@CU20B.ARPA First chance I get, I will check into the bug fixes and changes, however, it seems that #2, #3, and possibly #4 have already been fixed. Also, several of the 'convenience' items have already been corrected or changed. I will also see if there is a way to maintain both versions conveniently. Anton:: ------------------------------ Date: 10 Oct 84 13:10:28 EDT From: Bdale Garbee <AG0B@CMU-CC-TE> To: oc.trei@CU20B, oc.mione@CU20B, sy.fdc@CU20B Subject: Apple-Cat support in Kermit-65? Hi -- has anyone added support to Kermit-65 (Apple) for the Novation Apple-Cat internal modem? I've had several requests, and might add the code myself if noone else has already. Another request... this one more urgent. How about a new option for 'set' to specify whether to force upper case display of incoming text? The problem stems from many owners of Apple-2+ machines wanting to use the 2+ option so they get the keyboard translation, but who own lower-case chips and want real lower case. I've solved the problem so far by separately assembling a version with the upper-casification stuff commented out. But that's a drag.... Bdale CMU Software ------------------------------ Date: Tue, 9 Oct 84 15:57:19 edt From: engel@harvard.ARPA (Stephen Engel) To: Info-Kermit@CU20B.ARPA Subject: Macintosh Kermit Hello, Yes I'm still around, although suffering from the blitz of classes starting. I should be able to mail you a new version early next week, which if it doesn't fix the old one's problems will at least have the debugging capabilities to track them down further. Thank you for your patience. Steve ------------------------------ Date: 9 Oct 1984 2158-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> To: Info-Kermit@CU20B Subject: Help Wanted Making MS-Kermit Work on the TI Professional [Passed along from the Colorado School of Mines; if anyone can help with this, please call Joe directly -- he's not on any net.] The generic MSKERMIT does not work on a Texas Instruments Professional PC because MS-DOS version 2.11 will not allow you to receive characters via COM1:. We tried configuring the Sync/Async Comm Card using: A>CONFIG COM1=P1,DATA=8,PARITY=NONE,SPEED=1200,BUSY=NONE and that allowed us to transmit characters out COM1: or AUX:, but a bug in TI's BIOS does not allow characters to be received. I am working on the machine-dependent code for MSXTIPRO.ASM, but I'm having problems getting information. The Technical Reference Manual says that TI uses a Zilog 8530 chip, gives the port addresses, and some of the bit definitions, but does not describe all the bits in all the registers. I have been unable to locate a Z-8530 spec sheet, if anyone could tell me how to program the durn thing I would be grateful. Joe Smith, CSM Computing Center, Golden, CO 80401 (303)273-3448. [Ed. - This plea also sent to Info-IBMPC.] ------------------------------ Date: Tue 9 Oct 84 21:19:20-PDT From: mark thompson <THOMPSON@USC-ECLC.ARPA> Subject: Venix Kermit? To: sy.fdc@CU20B.ARPA Supposedly, there is a variant of the unix kermit for PRO/Venix. The source mentions a 'uxkercnv.c' file. We don't have it, but would very much like to. Do you know where this file is, or what has to be changed to get the thing to run on the besotted pro? -mark [Ed. - Sorry for the oversight. The file is now in the Kermit distribution area on CU20B as KER:UXKERCNV.C. It speeds things up by adding a separate fork for displaying incoming characters on the screen. But it's still pretty slow because of the way serial i/o is implemented in Pro/Venix.] ------------------------------ Date: Wed 10 Oct 84 12:17:31-EDT From: SCHUBOT@CWRU20 Subject: Pro/Kermit and TMS? To: SY.FDC@CU20B Has anyone figured out how to use PRO/KERMIT with the TMS modem on PRO 350s? ------------------------------ Date: Wed 10 Oct 84 14:24:30-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Getting Connected vs EOL To: Info-Kermit@CU20B.ARPA We've been fooling with Unix Kermit under 4.2 BSD and have found that we can speed it up dramatically by doing packet i/o in "cooked mode" rather than "raw mode" because the latter wakes up on every character, whereas the former reads everything up to a linefeed -- Kermit packets contain only printable characters plus ^A, all of which get through a "cooked" line unmolested. (By the way, this is not a recommendation that everyone change their Unix Kermits -- this trick probably only works for ASCII files, but not 8-bit binary files.) However, since most Kermits use carriage return and not linefeed as their default packet termination character, one must be careful to SET END-OF-LINE 10 (or whatever the syntax of your particular Kermit is), or else Unix Kermit will not receive a linefeed and will therefore never come back from the read. Since we're always forgetting to issue the appropriate SET command, we're always getting stuck. So... Here's something that should be added to every Kermit: When sending an S or an I packet, i.e. packet 0, the initial packet in a "transaction", terminate that packet with a carriage return AND a linefeed (and maybe also an XON for good measure). The other side is much more likely to read it that way. Once the other side has read it, it will be able to tell you in its reply the termination character it really wants, and since it has already read your S or I packet, it knows the one you want; everything should work automatically from that point on. Note that one can insert any characters at all -- except ^A -- between packets with impunity, so this trick should never do any harm. - Frank (and Bill C) ------------------------------ End of Info-Kermit Digest ************************* ------- 15-Oct-84 17:44:29-EDT,24941;000000000000 Mail-From: SY.FDC created at 15-Oct-84 17:43:55 Date: Mon 15 Oct 84 17:43:55-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit-Digest V1 #32 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Mon, 15 Oct 1984 Volume 1 : Number 32 Today's Topics: Kermit for Harris 800 Systems from U of Wisconsin New RT-11 and VAX/VMS Kermits from U of Toronto CP/M-86 Kermit v2.8 Review Unix Kermit, Cooked vs Raw Mode Building MS-DOS Kermit MS-DOS Kermit in Multi-Tasking Environment Changing CP/M-80 Kermit Defaults Improvements for CP/M-80 Heath-89 Kermit Use of IOBYTE in CP/M-80 Kermit Displaywriter Kermit Sought RFC 916, Reliable Asynchronous Transfer Protocol (RATP) ---------------------------------------------------------------------- Date: Thu 11 Oct 84 18:26:11-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit for Harris 800 Systems from U of Wisconsin To: Info-Kermit@CU20B.ARPA Harris 800 Kermit is an adaptation of the University of Toronto's RT-11 Pascal Kermit, with machine dependent subroutines written in assembler. It was converted by David Wilson at the Academic Computing Center of the University of Wisconsin - Madison (MACC). There are 3 files: H800KER.PAS - Pascal Source H800KER.ASM - Assembler Support Routines H800KER.JCL - Installation JCL Submitted by Paul Stevens, MACC (STEVENS%MACCWISC.MAILNET@MIT-MULTICS). The files are available via anonymous FTP from CU20B. ------------------------------ Date: Thu 11 Oct 84 12:46:53-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New RT-11 and VAX/VMS Kermits from U of Toronto To: Info-Kermit@CU20B.ARPA This is to announce new releases of the Pascal-based Kermits from the Bruce Pinn and Philip Murton at the University of Toronto for RT-11 and VAX/VMS. RT-11 Kermit is up to version 2.2C, and includes only minor changes in messages and displays. The previous version was 2.2. The program is written on OMSI Pascal 2.1 with Macro-11 subroutines. The new VMS Kermit is version 1.1E; it fixes a serious bug in packet data prefixing, and also adds some features. While the bulk of the program is in VMS Pascal, some modules are also in VMS Fortran. Since these versions are "redundant", they have been placed in <KERMIT-EXTRA> rather than the main Kermit area. The more popular RT-11 version is Brian Nelson's Macro-11 implementation (which also can be built for RSX, RSTS, P/OS), and the more popular VAX/VMS Kermit is the Bliss/Macro version from Stevens institute of technology. The new Toronto files are in KE:RT*.* (RT-11) and KE:VX*.* (VMS), available via anonymous FTP from host CU20B. Hex files are included, so that you don't need to have Fortran or Pascal in order to run these programs. ------------------------------ Date: Wed 10 Oct 84 14:10:31-PDT From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: CP/M-86 Kermit v2.8 Review To: cc.fdc@CU20B.ARPA I've found a couple of minor bugs in the directory function. Files which contain no data are listed with length 0K, but even these files have a data block allocated so the correct figure should be the size of one block. Files which are larger than 512K are listed with length 512K. I've got a fix for the first one, and I'm still working on the second. I think these fixes can wait for version 2.9. Kermit-86 works acceptably under Concurrent CP/M-86 on the APC with three exceptions: 1. A KERMIT.INI file must be present, even if empty. Concurrent CP/M-86 aborts the program if it tries to close a nonexistent file. 2. The set default-disk command causes subsequent directory and file access to be brain-damaged. I'm not sure why this is. 3. The serial port is accessed directly, bypassing the operating system locks against concurrent use. If another partition is using it as console 4 or as a serial printer there will most likely be garbage as a result. And one other problem: 4. Other partitions slow to a crawl when Kermit is in use, since Kermit loops checking the serial port status for input and uses up its full time slice each time it gets the processor. -- Ron ------------------------------ Date: 11 Oct 1984 00:16:29-PDT From: cmf%case.csnet@csnet-relay.arpa To: info-kermit%cu20b.arpa@csnet-relay.arpa Subject: Unix Kermit, cooked vs raw mode Using cooked mode for packet input for ASCII files seems like a fairly good idea, but there is an error in your statement. You CAN use carriage-return as your end-of-line character. All you have to do is turn on the terminal's CRMOD bit, and a carriage-return looks just like a line-feed. From stty, this would look like 'stty -nl'. Most people have this bit set anyway, because typing <return> is more "natural" than typing <linefeed>. Carl Fongheiser cmf%case.csnet@CSnet-relay.ARPA ------------------------------ Date: Thu, 11 Oct 84 11:44:54 pdt From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:kdp@hplabs.CSNET> To: #cc.fdc%cu20b.arpa@csnet-relay.arpa, Subject: 4.2 kermit and cooked mode There is a way to make the Unix kermit smarter about end-of-line: Set the CRMOD bit in sgttyb.sg_flags on 4.2BSD (and V7, I think). (Set ICRNL in termio.c_iflag for Syetem III and V.) This has the effect of making Unix respond to CR in the same way as NL. Clearly, this is easier than modifiying every other kermit. (Another way: Set the "alternate end-of-line" char to CR. (See tchars.t_brkc for 4.2 (and 4.1, and V7, I think) and termio.c_cc[EOL] for System III and V.)) Also, as long as the control-character quoting is happening, it seems like cooked mode should work just fine, even for binaries. The large gain in speed might argue for at least using cooked mode for ascii transfers (i.e., non-"image" mode). I hope that you are putting the terminal mode munging code in separate routines and adding ifdef's for System III-derived verions. The terminal i/o handling is completely different under System III, and some of the compatibility libraries went away under System V. You might just take my version's setraw and unsetraw routines. [Ed. - The real question in this cooked-vs-rawmode discussion is whether the "parity" bit makes it through intact in cooked mode, in each of the various Unix implementations. If not, then the overhead introduced by "8th-bit- prefixing" for 8-bit binary files would tend to offset the advantage of eliminating single-character wakeups (assuming Unix Kermit could do 8th-bit- prefixing, which it can't yet). Any comments?] ------------------------------ Date: Thu 11 Oct 84 18:19:10-EDT From: Jeff Damens <US.JD@CU20B.ARPA> Subject: Building MS-DOS Kermit To: sy.fdc@CU20B.ARPA It looks like some combination of the new MASM and the new LINK make segments load in a different order than the older versions. The effect is that any command that has to fork something up (e.g. directory, push, run) doesn't work, and usually hangs the machine. This is because kermit tries to release some memory before forking anything up... if the stack isn't the last segment in memory, as kermit thinks it is, it ends up deallocating something crucial, like the code segment. This only happens to people who build their own versions, since the binaries I made are ok. However, it seems like a number of people are having problems with the .BOO files and are building their own binaries, so... The solution is to load MSXDMB as the first object file. This is just a dummy module that specifies the order of the segments. Jeff ------------------------------ Date: 12 Oct 84 14:38:16 EDT From: Michael D. Gillinov <MG1F@CMU-CC-TC> To: info-kermit@CU20B Reply-to: MG1F@CMU-CC-TC Subject: Kermit in multi-tasking environment I appreciate the significant benefits of by-passing DOS for video output, but as a result Kermit v2.26 has become a program which can only run in the foreground in Topview. This result imposes unfriendly restrictions on use of the program in Topview and probably in most other multi-tasking environments for the PC. Will you be supporting a more "well-behaved" version which uses standard DOS calls for this i/o? Keep up the good work! Michael. [Ed. - This is a tough one. We have to access the screen memory to get acceptable performance out of functions like insert/delete character. I believe the previous version, 1.20, is "well behaved" in this respect, and we'll keep it around indefinitely for reasons such as this. Also, you should be able to run 2.26 with some other terminal driver -- for instance ANSI.SYS, assuming it does everything through DOS -- without interfering with your windows.] ------------------------------ Date: 17 September 1984, 10:43:57 CDT From: U09279 at UICVM (Neil W. Rickert /312/996-3055) To: DFTCU at CUVMB, DAPHNE at CU20B Subject: Changing CP/M-80 Kermit Defaults The following is a suggested addition to the KERMIT-80 documentation. I am using the Heath H89 version. The following suggestion works with this version, and presumably works just as well with other versions. Changing defaults for Kermit: Any of the options of KERMIT which may be changed with the SET command can also have the default setting changed. For example, the default parity is NONE. You can change it so that the default parity, when KERMIT is first loaded, is, say, EVEN. Here is a simple way of making this change: First use the STAT command, to find out how large KERMIT is. For example, in my version KERMIT is 101 blocks, and 13K in length. We take the number of records (101), halve it, and round it up to the next integer. In my case that gives 51. Remember this value. You will need it for the SAVE command. Now go into KERMIT. Use the SET command to set the options you desire. Use the EXIT command to return to CP/M. Use the SAVE command ("SAVE nn KERMIT.COM") to save the modified KERMIT. For example, to set the default parity to EVEN, I would do the following: A>kermit Kermit-80 A:>set parity even Kermit-80 A:>exit A>save 51 kermit.com Of course it is a good idea to keep a backup copy of the unmodified KERMIT on another disk, just in case of problems. I believe you can preset all options except the default disk, using this method. ------------------------------ Date: Mon 15 Oct 84 18:26:11-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Improvements for CP/M-80 Heath-89 Kermit To: Info-Kermit@CU20B.ARPA Neil Rickert, who sent the above message, also sent code to be added to CP/M-80 Kermit 3.9A to allow the Heath 89 to send a BREAK signal and to control modem signals like DTR and RTS, for instance for hanging up a Hayes modem. The messages containing this code are in KER:CPMHEATH.BWR. ------------------------------ From: Joe Smith, Colorado School of Mines Computing Center Address: Golden CO 80401, (303)273-3448 To: CHARLES@ACC Subject: Use of IOBYTE in CP/M-80 Kermit PROBLEM: KERMIT-80 does not work on a North-Star Horizon if the modem is plugged into socket #2 or #4. DIAGNOSIS: KERMIT-80 assumes that the BIOS implements the IOBYTE the way that Digital Research suggests: 1) CON=BAT console input comes from the RDR and console output goes to LST, and 2) doing a punch output to TTY is the same as doing a console output to the TTY or doing a list output to the TTY. CURE: Make all 4 fields of IOBYTE independent, with useful synonyms. Generic KERMIT-80 currently allows for 6 of the 8 possible modem ports, TTY, CRT, UC1, PTR, UR1, and UR2. However, there are 2 cases it does not handle: 1) System has 4 consoles. CON=BAT goes to CON2, therefore BDOS cannot check if a character is available at any of the RDR ports but can check if a character is available at CON2. 2) System has 3 console ports and 16 modem ports. CON=BAT does test for input available on the currently selected modem port, but the RDR and PUN fields of the IOBYTE are not independent. Together they select one of 16 different bi-directional serial ports. Setting RDR=TTY and PUN=TTY does not do I/O to the same port as setting CON=TTY. To be completely flexible, KERMIT-80 should accept all 20 of the "SET PORT" arguments listed below, and all 5 "SET PRINTER" arguments. In this way, the command "SET PORT UR1" does NOT imply "SET PORT UP1" (but "SET PORT AUX2" does). SET PORT Read Write IOBYTE ----------- ---- ---- -------- TTY or CON0 CON: CON: xxxxxx00 CRT or CON1 CON: CON: xxxxxx01 BAT or CON2 CON: CON: xxxxxx10 (serial card in slot #2) UC1 or CON3 CON: CON: xxxxxx11 CON CON: CON: xxxxxxXX (value remembered at startup) TTR or PTR0 RDR: PUN: xxxx00xx (different from CON0 mode) RDR or PTR1 RDR: PUN: xxxx01xx UR1 or PTR2 RDR: PUN: xxxx10xx UR2 or PTR3 RDR: PUN: xxxx11xx PTR RDR: PUN: xxxxXXxx (value remembered at startup) TTP or PTP0 RDR: PUN: xx00xxxx (different from CON0 mode) PUN or PTP1 RDR: PUN: xx01xxxx UP1 or PTP2 RDR: PUN: xx10xxxx UP2 or PTP3 RDR: PUN: xx11xxxx PTP RDR: PUN: xxXXxxxx (value remembered at startup) AUX0 RDR: PUN: xx0000xx (TTR+TTP, different from TTY) AUX1 RDR: PUN: xx0101xx (RDR+PUN) AUX2 RDR: PUN: xx1010xx (UR1+UP1) AUX3 RDR: PUN: xx1111xx (UR2+UP2) AUX RDR: PUN: xxXXXXxx (value remembered at startup) SET PRINTER Read Write IOBYTE ----------- ----- ----- -------- TTY or LST0 can't LST: 00xxxxxx (LST=TTY not same as CON=TTY) CRT or LST1 can't LST: 01xxxxxx (LST=CRT not same as CON=CRT) LPT or LST2 can't LST: 10xxxxxx UL1 or LST3 can't LST: 11xxxxxx LST can't LST: XXxxxxxx (value remembered at startup) [Ed. - Poor Charles Carvalho, who is working on the "modularized" release 4 of Kermit-80, has been getting a lot of suggestions like this, plus the new code for the Heath i/o mentioned above, plus the new support for the Compupro, etc. I'm not sure how much of this he can assimilate before he gives up. Therefore, all such information is provided to Info-Kermit with no assurrance that it will appear in the new release of Kermit-80. Let's wait and see. If not, then perhaps someone else will do it.] ------------------------------ Date: 14 Oct 1984 22:31-EDT Subject: Displaywriter Kermit Sought From: POLARIS@USC-ISI.ARPA To: info-kermit@COLUMBIA-20.ARPA We are looking for an implimentation of KERMIT for the IBM Displaywriter or for anyone who is doing work in the area of porting KERMIT to the Displaywriter. Any information will be appreciated. If someone is now working on a version and needs help we would be glad to assist in any way that we can. Thanks in advance Gene Cartier ARPA: POLARIS@USC-ISI.ARPA BELL: (703)527-7333 USPS: POLARIS INC.,1400 Wilson Blvd, Suite 1100,Arlington VA, 22209 ------------------------------ Date: Mon 15 Oct 84 14:01:11-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: RFC 916, Reliable Asynchronous Transfer Protocol (RATP) To: Finn@USC-ISIF.ARPA cc: Info-Kermit@CU20B.ARPA, Info-Micro@BRL.ARPA [Ed. - The remaining messages in this issue are about some fine points of Kermit and other asynchronous protocols, and may be skipped with no ill effects...] RFC 916 includes an appendix which compares the proposed protocol (RATP) to several existing protocols, including DDCMP, MODEM, and KERMIT. As the RFC points out, DDCMP is "too complex for consideration" as an asynchronous protocol. On the other hand, MODEM and KERMIT are "toy protocols", not designed to provide an error-free transport layer for a network based on asynchronous telecommunications, but rather as simple standalone programs intended to provide file transfer and management over that medium. Several valid criticisms are raised about Kermit, but there are also some misconceptions: KERMIT combines both the reliable transfer and file transfer into a single package. Extension to other applications and higher level protocols would be possible but the boundary between the reliable transfer and application layers is very indistinct. It violates the layering design strategy the Internet employs. This is true. Packet control fields and state tables are pretty much hardwired to reflect file transfer and management functions, although it is possible to fit other functions into this paradigm. For instance, a user Kermit process can ask a Kermit server to send a list of who's logged in ("finger"), and will receive the listing back as though it were a file, but for display on the screen rather than storage on the disk. There is a limitation of transmission to the restricted printable ASCII set for certain computers but not for others. This leads to confusion. KERMIT allows both restricted ASCII and 8-bit transmission. Not exactly right. The entire 7-bit ASCII set is supported by all Kermit implementations, and unprintable characters (ASCII 0-31 and 127) are translated to prefixed printables to ensure that they get through (for instance Control-B becomes "#B"). This is because KERMIT is designed to work under the most unfavorable conditions, for instance those in which one end of the connection is a timesharing job's controlling terminal, sensitive to a certain set of control characters. 8-bit transmission is possible in two cases: 1. The data path is 8 bits wide, i.e. there is no entity upon it which is doing parity or otherwise interfering with the "8th" bit. 2. The data path is 7 bits wide and both Kermits have implemented the optional "8th-bit-prefixing" method. In the initial connection dialogue, the two Kermits will automatically decide whether they have to resort to this method, which adds overhead, and will do so only by mutual consent. The 8th-bit-prefixing method is "enabled" when either Kermit "knows" that parity is being done on the communication line. This knowledge is either hardwired (as in IBM mainframe or PR1ME Kermits), or else it is set manually by the user (for instance when both systems are capable of 8-bit i/o, but they are communicating through a 7-bit channel like TELENET). The ability to automatically make this determination, as RATP does, is currently lacking. Incidentally, the 8th-bit prefixing method tends to be somewhat more efficient than RATP's 8-for-4 encoding; if the 8th bit is on randomly, Kermit will only double 50% of all characters, whereas RATP will double 100%. The KERMIT protocol does not appear to make provision for both sides of a connection attempting an active open simultaneously. One side must be an initial "sending Kermit" and the other a "receiving Kermit". The code published as a KERMIT implementation guide cannot recover from simultaneous active opens, it immediately ABORTs. This reflects a bias towards unidirectional data flow. True. Kermit is designed for use over user-initiated connections. It is assumed that a human is sitting at one end, who starts the Kermit processes on each end. Kermit is only intended for use over a single physical channel, and provides a single logical channel. It is also true that transactions are unidirectional. The KERMIT packet type (similar to RATP control flags) specifies whether an ACK/NAK is contained in the packet, or data, etc. These are mutually exclusive and piggybacking an ACK on a data packet is not possible. This can be a source of overhead. In addition KERMIT restricts the sender to a single outstanding unacknowledged packet as does RATP. It allocates an entire byte to the sequence number which is unnecessary. True. The full-byte packet number is there to allow the protocol to be expanded to accommodate multiple outstanding packets. This extension has not been made yet. On the subject of error recovery, the size of a packet is contained in the second byte of the packet and is not protected by a header checksum. If the length field was in error due to noise on the link, it could be longer than the correct packet size. The code published as the KERMIT implementation guide relies upon the detection of the <SOH> character anywhere in a packet to indicate the beginning of a packet header. It re-SYNCHs using this technique. This is only possible if binary data in a packet is quoted. If full eight bit data is transmitted it does not appear that the KERMIT protocol rescans for a new MARK (SYNCH) character within the bad packet data just consumed. It will under these circumstances throw away the retransmitted packet or portions thereof. Re-SYNCHing under such conditions is problematical. Mostly true. The header checksum is good idea, and if we had it to do over again this might be one of the things we'd change (another would be a field to specify what kind of block check is used for the data, so that checking techniques could vary dynamically over a transaction with the condition of the line). However, it should be pointed out that the SYNCH character is a "real" ASCII Control-A ("8th" bit ignored). Any Control-A's that appear in the data are represented as "#A" and will never cause re-SYNCHing. If a length field is corrupted upwards, then presumably one side or the other will time out and resynchronization should occur within the next packet time. Also, one comment about the MODEM protocol: since it does not bother to encode data printably, it tends to be simpler and more efficient than Kermit. But as a consequence, it can't operate at all over 7-bit channels -- even if only 7-bit ASCII data is being transmitted, the checksum (or CRC) and the block number involve all 8 bits of an octet. Thus operation over TELENET or with IBM mainframes is not possible. Finally, you can add the following references to Kermit to your bibliography, if you like: da Cruz, F., "KERMIT Protocol Manual", Columbia University Center for Computing Activities, April 1984. da Cruz, F., and Catchings, B., "Kermit: A File Transfer Protocol for Universities", BYTE Magazine, June and July, 1984. P.S. Don't blame us for the title of the BYTE article; the editors changed our title at the last minute without consulting us, to make it fit with the educational theme of the June issue. The original title was "KERMIT: A Simple File Transfer Protocol for Microcomputers and Mainframes". ------------------------------ From: "Frank J. Wancho" <WANCHO@SIMTEL20> To: Frank da Cruz <SY.FDC%CU20B@COLUMBIA> Cc: Finn@USC-ISIF, INFO-KERMIT@CU20B, INFO-MICRO@BRL Subject: Comments on MODEM Also, one comment about the MODEM protocol: since it does not bother to encode data printably, it tends to be simpler and more efficient than Kermit. But as a consequence, it can't operate at all over 7-bit channels -- even if only 7-bit ASCII data is being transmitted, the checksum (or CRC) and the block number involve all 8 bits of an octet. Thus operation over TELENET or with IBM mainframes is not possible. Not universally known or published, but several clever independent implementations of MODEM have a "7-bit" mode to transfer ASCII data. Thus, that is not a real limitation. The problem with MODEM is that it is not currently possible to anticipate when the single-character EOT is to be received amongst the 132/133-character packets. This make it difficult, if not impossible, to implement on machines which have no capability to timeout a READ. MODEM, of course, has many other "problems", but it is pragmatic, even though it may not be elegant. What is unfortunate about the analysis of the "other" protocols at the end of RFC916 is that it dismisses the file transfer aspects. The analysis of MODEM is based on an ancient document, and that document does not even begin to cover the many enhancements made over the last two years in what has known to be the MODEM7/MDM7xx extensions for batch mode and considerably improved reliability with the timeout and error recovery mechanisms. Now, let's move this discussion over to PROTOCOLS@RUTGERS. --Frank [Ed. - Good idea, and thanks for the clarification about MODEM.] ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Oct-84 18:55:38-EDT,10534;000000000000 Mail-From: SY.FDC created at 18-Oct-84 18:54:45 Date: Thu 18 Oct 84 18:54:45-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #33 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Thu, 18 Oct 1984 Volume 1 : Number 33 Today's Topics: Kermit for the Cray-1 and Cray-XMP New release of Macintosh Kermit Cooked vs Raw Mode in Unix Kermit MS-DOS Kermit in Multi-Tasking Environment Additional Heuristics for Kermit Protocol Kermit on Tenex? Use of IOBYTE in CP/M-80 Kermit Making TSO Kermit Work ---------------------------------------------------------------------- Date: 18 Oct 1984 10:40:18-MDT From: Leah F. Miller C-10 <lfm@lanl> To: sy.fdc@CU20B Subject: Kermit for the Cray-1 and Cray-XMP Kermit-CR - LANL Cray Kermit Kermit-CR is an implementation of the Kermit protocol on the Cray-1 and Cray X-MP computers. It is written in CFT, the Cray version of Fortran-77, and runs under the Cray Time-Sharing System (CTSS) operating system. Kermit-CR is an advanced Kermit, including all required features plus server mode, timeout capability, data compression, and 8th bit quoting. Author : Leah Miller, Computer User Services Group (C-10) Los Alamos National Laboratory Los Alamos, New Mexico 87545 Arpanet address : lfm@lanl [Ed. - Cray Kermit is available on host CU20B via anonymous FTP in the files KER:CRAY.*. CRAY.CFT is the Fortran source, CRAY.DOC is the documentation. The Fortran source consists of 7 files concatenated together in alphabectical order; each file begins with a line of the form !-name-! where "name" is the name to be used for that file in the Cray file system. These names are: cr.filing cr.kermain cr.kfutil cr.kutcmds cr.pktio cr.receive cr.send cr.stdutils All operating-system dependent code is encapsulated in the modules cr.kfutil and cr.pktio.] ------------------------------ Date: Mon, 15 Oct 84 21:39:08 edt From: engel@harvard.ARPA (Stephen Engel) To: Info-Kermit@CU20B.ARPA Subject: New release of Macintosh Kermit Here is the new version of mackermit. It differs from the old version in the following ways: 1) It has debug option which displays the contents of each packet until a key is pressed. 2) It remembers terminal settings. 3) Pressing a key during transfer causes Mackermit to resend the last packet (useful if the packet length is distorted during transmission). Again, I apologize for taking so long on this, and please let me know how Mackermit is or is not working. Steve [Ed. - The new version is in KER:MC1KERMIT.SH, in Unix shell archive format, accessible via anonymous FTP from CU20B (Internet host [192.5.43.128] for those who still don't have CU20B in their host tables). There's no hex file this time.] ------------------------------ Date: Mon, 15 Oct 84 18:58:11 pdt From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:kdp@hplabs.CSNET> To: #cc.fdc%cu20b.arpa@csnet-relay.arpa, Subject: cooked vs raw mode in Unix kermit The answer (from tty(4)) seems to be that 4.x BSD (and V7, I guess) systems cannot get all 8 bits without raw mode. System III (and V) can get all 8 bits in cooked mode. Given the large performance gains possible for text files, it would seem to make sense to have System III always use cooked mode, and V7 and 4.x BSD use raw mode only when in 'image' transfer mode. This shouldn't be too hard to implement, since these two major branches of Unix need separate tty-mode-setting code anyway. To really gain from this, though, the read and write calls should be replaced by buffered i/o, probably stdio. ------------------------------ Date: Tue, 16 Oct 84 18:39 EDT From: Frankston.SoftArts@MIT-MULTICS.ARPA Subject: Re: MS-DOS Kermit in Multi-Tasking Environment To: info-kermit@CU20B.ARPA It is realitively easy to modify an MS-DOS program to work in a multitasking environment. All one needs do is a sequence like the following: mov es,display_segment mov di,0 mov ah,0feh ; get video buffer int 10h mov display_segment,es mov video_base,di ; instead of assuming 0 If the result is not 0b800h, then you do not need to do retrace synching. Note that when not running under Topview the registers are unchanged and thus returns 0b800:0 (of 0b000:0). One other change is necessary, one must post changes to the screen. This can be done when one cares about the result (such as when reading the keyboard). In worst case, one posts the whole screen. The post call is INT 10H, AH = 0FFH ES:DI points to the start of modified area in video buffer CX is the count One can just repost the whole screen on any change. Or simply note the lowest and highest byte numbers modified and post the region. Anything other (like multiple regions) is probably not worth it. ------------------------------ Date: Wed 17 Oct 84 03:05:39-PDT From: Bob Larson <BLarson@Usc-Ecl.Arpa> Subject: Additional Heuristics for Kermit Protocol To: info-kermit@CU20B.ARPA Here are some suggestions that would improve kermit under noisy conditions: 1. Any control character received in a packet terminates that packet. If the terminating character is the start-of-packet character, the original packet should be discarded without a nak and the new packet should be received. Otherwise, the expected packet should be naked. This helps detect corrupted packets, and avoids timeouts when characters in the middle of a packet are dropped and the packet is terminated by a control character. (i.e. return) [Ed. - Good idea, but not necessarily recommended, because the Kermit protocol actually allows bare control characters (other than SOH and EOL, whatever they are defined to be) in the data packets. While no version of Kermit I know of will actually send bare control characters in data packets on purpose, most Kermits upon receiving them will store them as is. It may be worth reserving the ability to send a negotiated set of control characters bare in order to improve performance.] 2. On noisy lines, the terminator character should be sent twice in case one gets dropped or corrupted. Determining what is a noisy line is another problem.... [Ed. - Another good idea. A line could be deemed noisy if the number of retries (timeouts or bad checksums) exceeded a certain threshhold for a certain number of consecutive packets. Under those conditions, you might also want to decrease the packet length to reduce the probability of a noise hit and the retransmission overhead when one occurs. On the other hand, the overhead of keeping all that history around and making such decisions on a per-packet basis might offset any advantage gained.] 3. A nak should be sent as early as possible. If the packet being received is not the expected one, or the length exceeds the requested maximum, the nak may be sent as soon as the header is received. Does this require negotiation to see if the other side is so dumb it can't talk and listen at the same time? [Ed. - This could work for full duplex systems. Again, added hair for deciding whether or not to do it based on whether communication is full or half duplex.] What should the sending side do when it receives a nak while still sending? My choice is flush the output buffer and any outstanding output, and resend the naked packet. Hopefully the other side has implemented (1) above, and the nak was not due to a timeout. [Ed. - All the Kermits I know of are deaf to input while they are sending, and rely on the system, or their own interrupt handlers, to buffer arriving data. Kermit was originally designed to work uniformly on half and full duplex systems, which means it's really a half duplex protocol.] Bob Larson <Blarson@Usc-ecl> ------------------------------ Date: Sunday, 14 October 1984 15:59-MDT From: Rem%IMSSS@SU-SCORE To: PROTOCOLS%RUTGERS@SCORE Subject: Kermit on Tenex? We have source for Kermit on IBM-PC and Tops-20, but we need Kermit on Tenex and the Tops-20 version doesn't assemble on Tenex because it needs a macro package that doesn't exist on our Tenex. Does anybody have a Tenex version of Kermit or know how to fit the Tops-20 version onto Tenex? (We have a direct RS-232 link between Tenex and the room where the IBM-PC is located, and the IBM-PC has an RS-232 interface, so we think the hardware problem has been solved, leaving only the software problem.) ------------------------------ Date: 15 Oct 1984 18:10 MDT (Mon) From: "Frank J. Wancho" <WANCHO@SIMTEL20> To: INFO-KERMIT@CU20B Subject: Use of IOBYTE in CP/M-80 Kermit The real problem is that not all of the versions of CP/M for the N* even have IOBYTE implemented. In particular, N*'s own implementation does not! Considering the extra overhead in making BIOS calls in the first place, much less going through the even higher overhead of an IOBYTE interpreter, it is far better to simply modify the remote I/O to directly address the ports in question, if you can find *all* instances of remote I/O... --Frank ------------------------------ Date: Wed, 17 Oct 84 08:03:53 pdt From: dual!islenet!david%Berkeley@columbia.arpa To: Info-Kermit@CU20B, systems.ron%UCHICAGO@MIT-MULTICS.ARPA Subject: Making TSO Kermit Work Finally got KERMIT-TSO working here. Here's a summary of the changes we had to make. Perhaps this will save someone else some energy. 1) We had to severely edit the ASCII-EBCDIC translation tables. We use our own TCAM tables here (slightly modified versions of the TEKTRONIX tables), and edited KERMIT-TSO to agree with them. This is not a job for the faint-hearted or poor-of-vision, since it involves reversing all the ASCII hex codes to decipher the TCAM tables. 2) The default device (DASD group) for creating new files is hard-coded as SYSDA. If your installation does not allow users to catalog datasets on SYSDA they will not be able to RECEIVE to a new dataset. Easy change. David Lassner, University of Hawaii ------------------------------ End of Info-Kermit Digest ************************* ------- 22-Oct-84 18:04:56-EDT,18062;000000000000 Mail-From: SY.FDC created at 22-Oct-84 18:04:28 Date: Mon 22 Oct 84 18:04:28-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #34 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Mon, 22 Oct 1984 Volume 1 : Number 34 Today's Topics: Kermit Network Distribution Moved New Documentation for VAX/VMS and Pro-350 Kermits New Kermit-11 Coming Changes and fixes for Kermit-MS 2.26 (Several Messages) Kermit-80 for Compupro Interfacer 3/4, Bug Correction Kermit-80 for IMCS CPX-48000 Kermit for TRS80-M100 or NEC PC8201A? Kermit for HP2000? ---------------------------------------------------------------------- Date: Mon 22 Oct 84 12:04:32-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit Network Distribution Moved To: Info-Kermit@CU20B.ARPA The Internet and CCnet Kermit distribution area has been moved from COLUMBIA-20 to CU20B effective today, as previously announced. Many thanks to the Columbia University Computer Science Department for playing host to the Kermit collection over the past year. During that time it grew in size from about 5 megabytes to more than 20, and shows no sign of slowing down. CU20B is a DECSYSTEM-2060 in the Columbia University Center for Computing Activities in New York City, reachable via anonymous FTP as CU20B if your site has this name in its host table, or as Internet host [192.5.43.128]. There are currently no restrictions on the hours during which anonymous FTP access is available, but since the system is very busy during prime time (about 10am - 6pm weekdays, eastern time), please do large transfers outside those hours. For those who may have missed recent announcements of new Kermit releases, here are the top few lines of KER:CURRENT.DOC, for the month of October: Code Machine/OS Language Ver # dd/mm/yy Author or Contact CPM Compupro IF 3/4 ASM 3.9A 20/10/84 PS1.YAAGP@CU20B 20 DEC-20/TOPS-20 MACRO-20 4.2(251) 18/10/84 SY.FDC@CU20B CR Cray-1,Cray-XMP Fortran77 - 18/10/84 lfm@lanl MC1 Apple Macintosh C (SUMACC) - 16/10/84 engel@harvard H8 Harris 800 Pascal/Asm - 11/10/84 STEVENS@MACCWISC.MAILNET VX VAX/VMS Pascal/Fortran 1.1E 11/10/84 P.Murton, U Toronto RT PDP11/RT11 OMSI Pascal 2.2C 11/10/84 P.Murton, U Toronto 86/APC NEC APC/CPM-86 ASM86 2.8 10/10/84 CONTEXT@WASHINGTON 86/RB Rainbow/CPM-86 ASM86 2.8 10/10/84 CONTEXT@WASHINGTON AP2 Apple II/DOS AppleAssembler 2.? 9/10/84 Olaf Pors, U of Va. UN Sperry/Univac1100 NOSC Pascal 2.0 8/10/84 Butt@UMD2 MAC80 8080 Cross Asmblr MACRO-10 10F(121) 8/10/84 CERRITOS@USC-ECL HL6 Honeywell L6/10 MASM 1.20A 5/10/84 Carlin%pco@MIT-MULTICS HG HoneywellDPS8,66 C 3.0 5/10/84 Carlin%pco@MIT-MULTICS ------------------------------ Date: Mon 22 Oct 84 12:06:52-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New documentation for VAX/VMS and Pro-350 Kermits To: Info-Kermit@CU20B.ARPA New manual chapters are available for two of the Stevens Institute of Technology Kermits, VAX/VMS and DEC Pro-350 P/OS. The programs themselves have not changed, but the Kermit User Guide manual chapters describing them have been updated to reflect the current versions. The files are in KER:VMSMIT.DOC and KER:PROMIT.DOC; Scribe text formatter source for the two are in corresponding .MSS files. Thanks to Bob McQueen and Nick Bush of Stevens for the contribution. ------------------------------ DATE: MON, 22 OCT 1984 FROM: ATSBDN AT UOFT01.BITNET TO: SY.FDC AT CU20B SUBJECT: NEW KERMIT-11 COMING New release of Kermit-11: . Support for P/OS and PRO/RT11. . Smaller task image due to splitting some modules up with new overlay. The PRO/RT11 version uses the distributed XC handler for i/o. This handler does NOT support 8-bit data, so binary transfers will have to use 8th-bit prefixing. At some point in the near future, I will write a handler for Kermit-11 on PRO/RT. This new Kermit-11 is currently in FT1 and will be made available in one to two weeks. brian nelson [Ed. - It will be announced on Info-Kermit when it arrives.] ------------------------------ Date: 18 Oct 1984 2324-EDT From: LCG.KERMIT@DEC-MARLBORO To: EIBEN@DEC-MARLBORO Subject: Problems with Kermit-MS on Rainbow I've been using Kermit-MS with a Rainbow 100A and observed the following behavior tonight for the first time while using STI's SMARTQUERY on a VAX: 1. Kermit-MS did not obey the sequence that sets application cursor keys, i.e. the cursor keys should have been sending out ESC O A, but were still sending ESC [ A. I checked with the pure terminal mode and with CPM-86 Kermit 2.8, and both of these get the application cursor keys set when the sequence (not sure what it is) is sent. [Ed. - We'll look into the possibility of responding to host commands to change keypad mode, with particular attention to how that might interact with user-defined key redefinitions.] 2. After putting the status or help message overlay on the screen, video attributes that were there (reverse video, bold) are not restored when the screen is restored. Also, if the graphics character set was selected, the bottom of screen prompts are written in graphics characters. [Ed. - This should be fixed in the next release.] Now, for a question: is there any work currently proceeding on a Tektronix 4010 emulation as part of either Rainbow Kermit for those of us with graphics options? I could certainly use the graphics capability of our VAX while Rainbowing at home. If no one is looking into this, I am willing to start on it as a part of CPM-86 Kermit. Please let me know if there is interest or work already proceeding on this. [Ed. - Answer, no -- be my guest!] Carl Houseman GENICOM Corp. 1 General Electric Drive Waynesboro, VA 22980 703-949-1323 ------------------------------ Date: Fri, 19 Oct 84 16:45:32 EDT From: Edgar B. Butt <BUTT@UMD2.ARPA> To: sy.fdc@cu20b.arpa Subject: Changes and fixes for MSKERMIT 2.26 Here is a copy of a message that must have been lost several weeks ago. Ed (that's -gar, not -itor) Congratulations on the new modular MS-KERMIT. It is much easier to work with and has many features we like here at the University of Maryland, College Park. We have used it successfully (with some changes) on IBM, Zenith, and Sperry PC's connected to our IBM (VM/CMS) and Sperry 1100 systems. I am sending changes to MS-KERMIT 2.26 we have made. Version 2.26, as distributed did not work very well with our Sperry 1100 systems for several reasons. First, MS-KERMIT is not very good at ignoring the extraneous EOL characters that some operating systems transmit between the end of one packet and the beginning of another. Second, when running in full duplex during file transfer, MS-KERMIT is confused by the echo of the packets it sends. The change information that follows is divided into three parts: 1. A narrative of the changes. 2. Changes with line numbers relative to the 2.26 release. 3. Changes in context, that is, changes with hunks of the original code around them. Lines beginning with '.' provide a guide to the sections. Yours for better frogs, Edgar Butt (BUTT@UMD2.ARPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Begin narrative of changes. . [UMD1] mscomm In subroutine INPKT, do not begin putting characters in the packet buffer until the SOH is encountered. This will prevent extraneous EOL characters transmitted by the remote kermit between the EOL for the previous packet and the SOH for the expected packet from terminating packet input before it really gets started. For example, the Univac 1100 sends CR-LF in response to the packet it receives. It also terminates the packet it sends with CR-LF. This means that between the checksum in one packet and the character SOH in the next packet, the other kermit finds CR-LF-CR-LF. The first CR terminates the packet and the second CR makes PCKERMIT think it has received a bad packet. [UMD2] mscomm In subroutine INPKT, whenever a SOH is encountered, discard all characters already input and start filling the buffer again. [UMD3] mscomm Discard echoed packets when the remote Kermit is echoing characters. When LOCAL-ECHO is off, the type of each packet received is compared with the type of the last packet sent. If the types are the same, the input packet is discarded. A previous attempt to discard echoed packets by flushing the input buffer immediately after transmitting a packet failed because concentrators, 1200 baud modems, and UART buffers introduced so much delay that the echoed SOH from short packets did not always arrive in time to be discarded. [UMD4] mscomm Enlarge the input packet buffer (recpkt) and provide space after the input packet buffer for the dollar sign which is appended for debug purposes. The buffer was enlarged because the protocol allows miscellaneous characters to occur between the checksum and the EOL character. If subroutine INPKT did not have space for those characters it would discard a possibly good packet. The 'slop' area after the buffer was provided because the debug routine stored a dollar sign after a received packet before sending it to MS-DOS for display. Without the slop area the dollar sign goes over the CRC table. [UMD5] msyibm Correct 'Echo' portion of mode line when in terminal mode. [UMD6] msyibm Correct processing of TAB character when in H-19 mode. The H-19 manual specifies that a TAB character is to move the cursor (without erasing) to the next tab stop or to the next column if the cursor is on or beyond the last tab stop. Tab stops are fixed in columns 9, 17, 25, 33, 41, 49, 57, 65, and 73. [UMD7] msyibm Implement H-19 cursor save and restore functions. "ESC j" causes the current cursor position to be saved. "ESC k" causes the cursor to be moved to the positon it was in the last time it was saved. [UMD8] msdefs mscomm msset msterm Make the appearance of the mode line settable in command mode and hence settable by MSKERMIT.INI. Also, display the status of the mode line. The following commands control the mode line: SET MODE-LINE ON SET MODE-LINE OFF [UMD9] msset Decouple HANDSHAKE and FLOW CONTROL. The usefulness of being able to set HANDSHAKE and FLOW CONTROL independently is considerably reduced by having one set when the other is cleared. These changes prevent the clearing of one from setting the other. The restriction that they can't be set simultaneously remains. [UMD10] msfile Detect CTRL-Z in disk file when EOF MODE is CTRL-Z. Code to detect CTRL-Z in disk file was in MSSEND, routine SDATA. Unfortunately, by the time disk data gets to MSSEND, the character CTRL-Z has been quoted to the two characters "#Z". This change looks for the CTRL-Z in its undisguised form. The result of not detecting the CTRL-Z is to have an extra "line" transmitted containing only the CTRL-Z. Files sent to the PC and back picked up an extra line [UMD11] msdefs Set Kermit version to 2.26e to identify the above changes. [Ed. - Code omitted, fixes will appear in next release.] ------------------------------ Date: Sat, 20 Oct 84 03:38:29 pdt From: dual!islenet!david@Berkeley To: Info-Kermit@CU20B Subject: Kermit-MS V2.26 Hawaii Patches Here's a summary of the changes we made to Kermit-MS V2.26 that haven't shown up in Info-Kermit. Hope you find them useful. David ; g1 Fix file renaming code not to overwrite original name unless ; unavoidable, but to do 'Pacman' ampersands if necessary. ; Ian Gibbons, Univ of Hawaii 10/2/84 ; g2 Change 'cmp chrcnt,00H' to 'cmp chrcnt,0FFFFH' in ENCOD2 so that ; files of length (integer X 80H)+1 will be sent correctly. Adjust ; other file send code using 'chrcnt' to be consistent. ; Ian 10/4/84 ; g3 Move EOF CTRL-Z code from MSSEND to 'encode' in MSFILE, so that it ; can look for unquoted unprefixed ctrl-z's. Also terminate file send ; only when we find a ctrl-z in the final sector that is followed ; solely by ctrl-z's or 00H's. (Kermit does not seem an appropriate ; place to do major file editing based upon a stray ctrl-z). MSRECV ; has been fixed to add a CTRL-Z to incoming file (with EOF CTRL-Z) ; only if the final char of the received file is not already a CTRL-Z. ; The EOF CTRL-Z file closing now does what user-guide says it does. ; (with the added choice of sending or not sending an EOF CTRL-Z to ; the remote host). ; SET EOF RCTRL-Z puts a ^Z at end of both incoming and outgoing files ; SET EOF CTRL-Z puts a ^Z onto incoming files, but does not send one ; on files going out to remote host. ; SET EOF NOCTRL-Z works solely from file size in directory and pays ; no special attention to ^Z's. ; Ian 10/4/84 ; [Ed. - Code omitted, fixes will appear in next release.] ------------------------------ Date: Fri 19 Oct 84 23:36:58-EDT From: Guy Valiquette <PS1.YAAGC@CU20B.ARPA> Subject: KERMIT-80 for Compupro Interfacer 3/4, bug correction To: sy.fdc@CU20B.ARPA Dear Frank, I just found out why KERMIT-80 for the Godbout Interfacer 3/4 did not work with the U S Robotics Password modem. It's got nothing to do with the modem, but rather with the testing environment!!! Turns out that when disabling the modem UART to hand up the communication (in subroutine "hangup"), I forgot to select the proper UART. This was inocuous when the console was on the System Support 1 board, but disastrous if the console also is on an Interfacer 3/4 UART: since the last selected user most likely (with MP/M) or certainly (with CP/M) the console, disabling the UART effectively kills the console serial channel. Sorry for all of you out there who got this bugged KERMIT, but I'm just a working physician and research scientist who plays with computers.... Please pass the fix along with my appologies: ; ; Problem: ; Kermit hangs if console is on an Interfacer 3/4 port ; and the EXIT or BYE commands are executed. ; ; Cause: ; EXIT and BYE call the "hangup" subroutine. ; "hangup" disables the UART by sending a 00H byte to the ; UART command port. I unfortunately had forgotten to... ; select the user. Since the last UART accessed on the Interfacer 3/4 ; was most likely the console, "hangup" hangs the console rather ; than the phone!!! ; ; Patch: ; replace the original "hangup" routine by this corrected one. ; IF cproif4 cpi 'D' ;Disconnect modem? jnz intc00 ;no hangup: di ;quietly... mvi a,user out usersel ;select our UART xra a ;get a null byte out command ;disable UART sta ckdialf ;pull down flag to reinitialize UART ei ;safe now ret ;most smart modems will hang up on loosing DTR intc00: ENDIF;cproif4 [Ed. - The patch has been installed and a new hex file built on CU20B, in KER:CPMPRO.*] ------------------------------ Date: 22 Oct 1984 0901-PST From: Pawka <PAWKA at NOSC-TECR> Subject: Kermit-80 for IMCS CPX-48000 To: CC.FDC at COLUMBIA-20.ARPA Frank: Got KERMIT working between VAX/VMS and a Z-80 based machine, an Intercontinental Micro Systems Corp. CPZ-48000, using the generic CP/M version. Seems to work fine. I had to make a few additions to the assembly file, I thought someone might want to add them in, just in case someone else might buy one of these obscure machines. The system supports direct IN / OUT handling of ports, so after mdI EQU FALSE I added imsc EQU TRUE and added OR imsc to the next IF statement to set 'inout' TRUE. Next, in the port assignments I added: IF imsc mnport EQU 80H ; modem data port mnprts EQU 81H ; modem status port output EQU 4H ; transmitter buffer empty input EQU 1H ; receive data available ENDIF;imsc Lastly, down near the end for the program herald I added: IF imsc versi0: db '[IMSC CPZ-48000]',0 ENDIF;imsc Thanks for your help in pointing me to the correct files for FTP'ing in the first place, Mike Pawka Naval Ocean Systems Center PAWKA@NOSC-TECR.ARPA ------------------------------ Date: Sun 21 Oct 84 17:29:34-PDT From: Doug <Faunt%hplabs.csnet@csnet-relay.arpa> Subject: KERMIT for TRS80-M100 or NEC PC8201A? To: info-kermit%CU20B Are there any such out there, or in the works? faunt%hplabs@csnet-relay ....!hplabs!faunt ------------------------------ Date: 19 Oct 1984 19:55 MDT (Fri) From: Keith Petersen <W8SDZ@SIMTEL20> To: Info-Kermit@COLUMBIA-20 Subject: Kermit for HP2000? Is anyone working on a Kermit for the HP2000? I have a request from a friend who needs it. It's a time-sharing mainframe that runs Hewlett-Packard Extended BASIC. --Keith [Ed. - There is a BASIC implementation in KER:800KER.*. It's reportedly in an unusual dialect of BASIC, and it's pretty rudimentary, but it might be a starting point.] ------------------------------ End of Info-Kermit Digest ************************* ------- 29-Oct-84 17:31:17-EST,26372;000000000001 Mail-From: SY.FDC created at 29-Oct-84 17:28:50 Date: Mon 29 Oct 84 17:28:49-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #35 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Mon, 29 Oct 1984 Volume 1 : Number 35 Today's Topics: New Kermit for HP 3000 MS-DOS Kermit 2.26 for the TI-Professional MS-DOS/IBM-PC Kermit Runs on Sperry PC & Zenith 150 MS-DOS Kermit Misuse of PATH MS-DOS Kermit Screen Glitch Kermit vs Concurrent PC DOS 3.2 Hex and Binaries Available for 2nd Macintosh Kermit Release Problem with 2nd Macintosh Kermit Release Kermit Underway for Elxsi 6400 Potential Bug In Unix Kermit Comments from UK on C Kermit Problem with TSO Kermit IBM Mainframe Kermit vs Series 1 Question Kermit Series 1 Filter for Use with CMS Kermit Thinwire SLIP Protocol Withdrawn TurboDos Kermit? ---------------------------------------------------------------------- Date: 25 Oct 1984 16:17-EDT Subject: New Kermit for HP 3000 From: POLARIS@USC-ISI.ARPA To: INFO-KERMIT@CU20B.ARPA This is to announce a new KERMIT version for the HP 3000. It is written in SPL specifically for an HP 3000 running MPE. Features include: o Binary and text transmission/reception o Server mode o 8th-bit prefixing o Repeat count prefixing o Numerous commands for control of MPE file system parameters Some Questions and answers: What is SPL ? SPL stands for Systems Programming Language. It's the moral equivalent of assembly language on the HP 3000 (there is no assembler). Since SPL is not included when you purchase a 3000, ALL sites don't have it (extra cost option from HP). On the other hand, SPL is practically a requirement for serious development on the 3000. It may be the most commonly available language (other than COBOL) in the HP 3000 community. Why not modify the Software Toolworks version ? When I started work on this version (6 - 8 months ago), the Software Toolworks version was not available. When we got a copy of the ST version, I stopped work on this one. Why re-invent the wheel? I didn't have a PC to test it with anyway. The ST version is a fine product and the only real limitation was the inability to handle binary files. This was due to the bizarre way that MPE (the HP 3000 operating system) stores files, its (MPE's) inability to transfer 8 bit characters, and the fact that MS DOS KERMIT did not support 8 bit quoting. Since then, things have changed: MS DOS KERMIT does 8 bit quoting, I have a PC to test with and we still need binary file transfer. I found myself with a RATFOR KERMIT that worked and an SPL KERMIT that almost worked. I am not too familiar with RATFOR but I am very familiar with SPL. RATFOR (Software Toolworks flavor) is somewhat rare on the 3000. SPL is quite common. The choice was obvious. I would like to make KERMIT and the associated manuals/documentation available to the INTEREX (HP international users group) Contributed Software Library. Please let me know if this is OK with you. [Ed. - It is, please do!] Finally, thanks to Columbia University for providing KERMIT to us in the first place. It's a useful tool and I've had a lot of fun working with it. - Ed Eldridge Polaris, Inc. 1400 Wilson Blvd. suite 1100 Arlington, Virginia 22209 (703) 527-7333 [Ed. - The files are in KER:HP3000.* on CU20B, available via anonymous FTP.] ------------------------------ Date: 29-Oct-84 08:36:42 EST From: Joe Smith, CSM To: EIBEN Subject: MS-DOS Kermit 2.26 for the TI-Professional Bernie and Frank: I uploaded MSXTIPRO.ASM and MSTIPRO.EXE. I still have some work left to do on it, but at least it runs! Joe Smith, Colorado School of Mines Computing Center, Golden CO 80401; (303)273-3448 [Ed. - The files are available on CU20B. KER:MSXTIPRO.* are the source and "boo" files, along with some brief notes about the implementation. KB:MSTIPRO.EXE is the 8-bit binary .EXE file.] ------------------------------ Date: Tue, 23 Oct 84 09:17:01 EDT From: Edgar B. Butt <BUTT@UMD2.ARPA> To: Frank da Cruz <SY.FDC@CU20B> Subject: MS-DOS/IBM-PC Kermit Runs on Sperry PC & Zenith 150 IBM PC version of MSKERMIT 2.26 with U. of Md. changes runs without modification on Sperry and Zenith (150 series) PC's. Sperry's PC is made by Mitsubishi -- except for the label it looks like the Leading Edge PC, also by Mitsubishi. [Ed. - The U of Md changes were for system-independent bugs, so I presume that the program also runs on these systems without the U. of Md. changes.] ------------------------------ Date: Sat 20 Oct 84 16:46:13-CDT From: Steven Shevell <S1.SHEVELL@UChicago.Mailnet> Subject: MS-DOS Kermit Misuse of PATH To: Staff.Sas@UChicago.Mailnet I found in the Kermit BB a message about the PATH problem on the XT. The response was that this is the way that Kermit should work: follow the PATH designation without looking at the current directory. This is wrong, and should be fixed. I quote from the IBM DOS documentation regarding the PATH command: [PATH] causes specified directories to be searched for commands or batch files THAT WERE NOT FOUND BY A SEARCH OF THE CURRENT DIRECTORY (manual for DOS V2.00, page 6-117; caps added). Therefore, Kermit should search the current directory for .INI files before looking to other directories specified in the path command. I got Kermit to work on the hard disk by adding the current directory to the PATH (I believe the following is an undocumented feature of PC-DOS V2.00: the path name "." (a single period) specifies the current directory, so if the current disk is C:, the current directory is C:.). Still, this should not be necessary; the way Kermit handles PATH is inconsistent with DOS. Unless you disagree, please forward to the appropriate person at Columbia. [Ed. - You're right that Kermit should search things the way DOS does, at least in most cases. This will probably be fixed in the next release. However, it's not true that Kermit never looks in the current directory; it just looks there last instead of first. It's also supposed to look there if PATH is not defined.] ------------------------------ Date: 25 Oct 1984 1437-EDT Forwarded-By: B.Eiben LCG Ext 617-467-4431 <EIBEN@DEC-MARLBORO.ARPA> Subject: Re: MS-DOS Kermit Screen Glitch The "glitch" reported in Kermit Digest 34 about a trashed Rainbow screen reminds me of a similar problem we found when using TOPS-20 Kermit. HOWEVER, the problem was tracked down not to Kermit but to Final Word --- when Final Word exited, it did not properly reset the screen. (The same problem would occur if you were using EMACS on TOPS-20 and would interrupt your work there to do something on the Rainbow.) The MSDOS solution most of us chose to implement was to change our MSDOS prompt to include the reset automatically ... a la' A>prompt $e7$e[?6l$e8$n: This seems to work. (Of course popping back and forth between EMACS-20, FW configed with EMACS.BIN and TURBO emacsified is enough to cause anyone's screen to start scrolling sideways...) Steve Cavrak Academic Computing Center University of Vermont Burlington Vermont, 05405 [Ed. - By the way, did you know that if the Rainbow firmware attempts to "display" certain sequences on the screen, the system will hang or crash? Two of these are ESC 9 and ESC c (lowercase c). This has nothing to do with Kermit; it will happen if a host sends you those sequences in terminal mode, or if you type them in half-duplex terminal mode, etc. Kermit will have to fix this problem by checking for them explicitly and never feeding them to the firmware.] ------------------------------ Date: Sat 20 Oct 84 14:51:14-PDT From: Jim Celoni S.J. <Celoni@SU-SCORE.ARPA> Subject: Kermit vs Concurrent PC DOS 3.2 To: Info-IBMPC@USC-ISIB.ARPA [Ed. - This is an excerpt from a much longer message that was posted to Info-IBMPC.] At long last I can transfer files (w/ Kermit) to the Vax while editing others! My copy of Digital Research (DRI) Concurrent PC DOS version 3.2 (free upgrade to Concurrent CP/M with Windows version 2.0) arrived this week, and now each of four windows can run a DOS or CP/M-86 application. I've edited with The Final Word 1.17, sent and received files with Kermit 2.26, and run the system file manager concurrently. FW wants the whole screen while editing. Cdos stops FW from running in another window when FW tries to open the swap file but properly allows another FW in a different directory. Kermit made 55 (instead of the usual zero) retries while sending over 1000 packets at 1200 baud. Kermit slows FW down but not much. Kermit uses the full screen in terminal mode when I'm in Emacs, but it's well-behaved when in command and file transfer modes. There are a few irregularities, like bogus help after "set heath ?" and mixed normal and reverse video in the ^]S status display, but then the file manager has reverse video glitches on the lower right of its object panel too. +j P.S.: I'm not related to any of the companies whose products and trademarks appear in this note except as customer. [Ed. - It's nice to hear that Kermit 2.26 works under Concurrent DOS. You should be able to get around Kermit taking over the screen while you're in Emacs by shutting H-19 emulation off and loading something "well-behaved" like ANSI.SYS as your console driver. Same for Topview or other window managers. Of course then you get less performance, but those are the tradeoffs. Rumor has it that IBM will eventually come out with a way to access the screen efficiently from DOS, and when that happens Kermit will use it.] ------------------------------ Date: Thu, 25 Oct 84 20:49:47 pdt From: Bill Croft <croft@safe> Subject: Hex and Binaries Available for 2nd Macintosh Kermit Release To: Info-Mac@SUMEX-AIM.ARPA Steve Engel's (engel@harvard) new kermit is filed on kermit.rsrc and kermit.dl. [Ed. - They are also available on CU20B as KER:MC1KERMIT.DL (this is the printable 7-bit ASCII "hex"-format file, downloadable to the Macintosh with the "fromhex" utility) and (KB:MC1KERMIT.RSR the downline-loadable 8-bit binary resource file, which you can download to the Mac with the previous version of Kermit, provided you change its name to back KERMIT.RSRC). The source continues to be available in KER:MC1KERMIT.SH. For those who want Macintosh Kermit but don't know about this version yet, please note that it is written under the Berkeley-Unix-based SUMACC Macintosh cross- development system. Thanks to whoever at SUMEX built the .RSRC and .DL files from the new shell script.] ------------------------------ Date: Sun 28 Oct 84 16:47:39-PST From: Doug Brutlag <brutlag@SUMEX-AIM.ARPA> Subject: Problem with 2nd Macintosh Kermit Release To: engel@HARVARD.ARPA cc: info-kermit@CU20B.ARPA, info-mac@SUMEX-AIM.ARPA Steve, Using the new version of MacKermit from [SUMEX]<INFO-MAC>KERMIT .RSRC or .DL I have had trouble getting MacKermit to communicate properly. Although this new version saves the BAUD setting in the controls from one run to the next, I have found it necessary to reset the BAUD setting from 1200 to 9600 and then back to 1200 again before MacKermit uses the appropriate setting. Although the program saves the settings, it appears to not use the saved settings until they are changed from within controls. I have also noted previously mentioned problems in CONNECT mode that delete still deletes one to many characters on the screen and MacKermit often hangs while receiving a large number of short lines (like after a DIR command). The new Executable option is very nice, allowing one to download 8-bit .RSRC files from TOPS-20 directly to an application file. Doug Brutlag ------------------------------ Date: 29 Oct 84 13:48 EDT From: "David H M Spector" <SPECTOR@NYU-CMCL1.ARPA> To: sy.fdc@CU20B.ARPA Subject: Kermit Underway for Elxsi 6400 Here at NYU, we have a brand new Elxsi 6400, which is a kinda nifty 64 bit multiprocessor. Since we have no networking code/hardware for it, I thought I'd try and bring Kermit to it. It has both fortran and C, so I will probably try to use one of those languages. For a first shot I'll try to bring over the generic C kermit, and then proceed from there. The name of the operating system is EMBOS, Elxsi Message Based Operating System. It's not much like unix, but does sport a C compiler. The OS is more like a cross between VMS and Unix, with a *Really* Verbose command language. Its main virtue is that it is really fast. Our configuration has 2 CPUs ( Expandable to 5 CPUs; 1 CPU = 4 Vax 11/780s ), 16Mb of Memory and, currently, 32 ports. The machine does have a Unix emulation that runs under Embos and is currenly an implemenation of Bell System 5.2, the only thing it lacks is (*Sigh*) UUCP. (Even under EMBOS there is no networking facility, although they say they are working on IP/TCP.) Elxsi says they will eventually have it up to Berkeley 4.2... I will be doing this as a midnite project, so it'll be on a time available basis for now. David HM Spector NYU/acf Systems Group 251 Mercer St. Rm. 329WWH NY, NY 10012 (212) 460-7287 [Ed. - Good luck. Recommend you work from the current C version, adding only the minimum system-dependent code for your system. That code can later be fitted into the new full-functioned modular C Kermit when that's ready.] ------------------------------ Date: 17 Oct 84 13:10:53 EDT From: tpsc-irt @ DDN2.ARPA Subject: Potential Bug In Unix Kermit. To: info-kermit @ cu20b.arpa There is a bug in the latest (and earlier) versions of Unix Kermit which will affect machines in which the pointer and integer size is different. The bug occurs in two locations in the program. First, in the "connect" function, at about line 895, wait is called with an argument of "0". The proper form is wait((int *)0). This forces the argument to be sized as a pointer. The second occurs in the spack function at about line 965. The write system call is given the difference in two pointers as its third argument write(ttyfd,buffer,bufp-buffer+1) however, write expects an integer. A fix for this is to put the difference "bufp-buffer+1" into an integer (such as the i already used as a counter) and call write with the integer instead. Again, these problems occur only in machines (such as the CCI 5/20) which have different sizes for pointers and integers. Symptoms of this bug are bus errors (caused by a bad pointer passed to wait) and kermits which can't send packets (caused by the pointer passed to write). [Ed. - Thanks for the pointers; they'll be reflected in forthcoming releases.] ------------------------------ Date: Fri, 26 Oct 84 9:37:59 BST From: Chris-on-Fridays <cjk@ucl-cs.arpa> To: info-kermit@cu20b.arpa Subject: Comments from UK on C Kermit Having no background other than the Manuals, no contact with other Kermit users, and a non-standard unix, I decided to work from the "demonstration" version "kermit.c". Has this ever been run in anger? I think I've spotted at least 1 flaw:- In rpack(), when reading data, an SOH won't break you to the end of the while; suggest the statement if (t == SOH) continue; in the for loop for data characters be replaced by if (t == SOH) break; with a "if (t == SOH) continue;" placed immediately after the for statement. [Ed. - Good idea; the mistake is probably due to overuse of the unkill feature of our editor...] Also, the code is sufficiently neat and clever that you have to be quite careful when removing "unneccessary" bits; they tend to have side-effects which are used later on! Anyway, having cut this about to become a remote-only and stripped out all the UCB4X system calls, it is on the verge of working. Got a unix system problem for the wizards to sort out (dumps core on input). The RML Z80 micro (480Z) has an unusual i/o architecture in that it uses a single (asynchronous) port for both disks and wideworld communications; therefore no iobyte. Also we use the DRI assembler code, not M80, so I didn't feel like tackling the very large generic CPM80 version. Cutting up "kermit.c" to replace the user interface, make it reentrant, and slot in existing high-performance communications-code has produced a version which runs quite sweetly at up to 4800baud. If you are interested, and subject to commercial considerations (I am a consultant, not an employee of the firm), this could probably be supplied and documented as a generic version for any micro which runs a C-compiler, and can supply a limited set of machine-dependent routines for handling screen and comms line faster than CP/M called from C. It does not try to be any particular VDU terminal; RML already has a high-performance VT100 emulator, which will probably have Kermit protocol slotted into it in due course. (We are using the Aztec compiler - which doesn't implement "#if".) For any other UK users who may see this, we have the tape (date: August 1984) at UCL Computer Science, and about a third of it is online and accessible by Blue-Book NIFTP. It'll be accessible by Kermit itself as soon as I stop the program coredumping. We've also got most of the documentation, and the info-kermit digests as they appear. On request, we could extract other files from the tape. I'll be glad to give details personally; if you're on JANET mail, I am cjk@ucl-cs; else phone me Monday-Wednesday @ RML, Oxford (0865) 249866. Or NIFTP out the file "/44d/kermit/read.me" using userid GUEST and no passwords. [Note that this availability of Kermit is a limited-life thing. UCL does not have funding/resources to get and distribute updated sources. But I would hope to keep it online through this academic year.] I would in any case be glad to hear from any other UK Kermits in order to prove interworkability. Keep up the good work! Chris Kennington (cjk @ UK.AC.UCL-CS). [Ed. - Thanks; your generic microcomputer C version would be most welcome.] ------------------------------ Date: 25 Oct 1984 1319 PDT From: Joe Wieclawek <JAW@JPL-VLSI.ARPA> Subject: Problem with TSO Kermit To: Info-Kermit@CU20B.ARPA Can any TSO Kermit users offer some help? The program seems to run as it should, but no characters ever get sent to the micro. The micros run MS and CP/M versions of Kermit and have no problem talking to each other or VMS and UNIX Kermit. The DEBUG in TSO Kermit tells me: (When TSO is the receiver and the micro is the sender) > TGET gets the send init packer > The ACK packet is formed > TPUT is called > TPUT returns no-error status *> NO characters are sent out (no ACK) (The micro's port was monitored and nothing gets there) > TGET gets a send init packet again etc, until max retries (When TSO is the sender) > The send init packet is formed > TPUT is called > TPUT returns no-error status *> no characters are sent out ?????????????????? Joe Wieclawek Jet Propulsion Laboratory Pasadena California (818)354-2419 JAW@JPL-VLSI.ARPA ------------------------------ Date: 29 October 1984, 11:58:30 CST From: ("Ron Rusnak (312) 962-7607") SYSRONR at UCHIVM1 To: SY.FDC at CU20B.BITNET Subject: Re: Problem with TSO Kermit I'm the guy unfortunately. The problem that this guy is having is probably related to either his terminal handler (TCAM or VTAM or whatever), or the translate tables. As far as, I know the only complaints I have heard come from folks who have ASCII translate tables. It is neccessary that TPUT control send all ASCII characters. Given what this person said, I would suspect something wierd with whatever acess method they're using. ------------------------------ Date: Fri 26 Oct 84 15:39:12-PDT From: ALFIERI@ECLD.#ECLnet Subject: IBM Mainframe Kermit vs Series 1 Question To: info-kermit@CU20B.ARPA We are planning to mount Kermit on the IBM mainframes (soon, I hope), but we would appreciate any information about whether there are any problems using Kermit through the Series 1 mini. Has anyone else done this yet? asbed bedrossian computing information services university of southern california [Ed. - See below.] ------------------------------ From: bjerke@ut-ngp.ARPA (bjerke) Date: Fri, 26 Oct 84 15:51:45 CDT To: cc.fdc@columbia-20.ARPA Subject: Kermit Series 1 Filter for Use with CMSKERMIT I have written a "filter" to enable CMSKERMIT to talk to PCKERMIT 1.20 when the mainframe/micro link is a SERIES/1 running the Yale Ascii Terminal Communications System 2.1 (5796-RKJ) or the Host Loaded Yale Ascii Communications System II (5798-RRJ). It should also work with the new 7171; it requires only that the transparent ascii read/write feature be supported. My main design point was to avoid any modifications to the micro-resident KERMIT and to restrict CMSKERMIT modifications to a minimum number of trivial changes. I think I have achieved this goal. The main changes to CMSKERMIT are: 1. Since Yale-supported devices look like 327x terminals, checking for ascii terminals is removed 2. In SPACK and RPACK, the return codes from WRTERM and RDTERM are checked, and if non-zero an appropriate error condition is flagged to abort file transfer The filter works by installing a nucleus extension that traps WAITRD and TYPLIN svc's. During the normal command-level interaction with KERMIT these calls are passed on to CMS for handling. When file transfer begins, the filter processes the calls as transparent read/write sequences (first translating the buffer back to ascii when sending, and to ebcdic before passing a received buffer back to KERMIT). Transition to file-transfer mode is detected when WAITRD is first entered with EDIT=PHYS, or TYPLIN is first entered with a buffer that begins with X'01'. Transition back to command mode is detected when TYPLIN is in file-transfer mode and is entered with a buffer that does not begin with X'01'. Both entry points pass back non-zero return codes to RDTERM/WRTERM when errors occur. These return code are distinct from the standard codes. The above considerations mean that the following restrictions must be obeyed by CMSKERMIT: 1. Reads and writes in file-transfer mode must always alternate; if they do not the transparent read/write facility may not function correctly. In practice this implies that CMSKERMIT can never be modified to include a timeout, since that could result in two or more successive writes. Micro-based KERMIT can timeout, since if a packet is lost CMSKERMIT is still waiting to receive (if CMSKERMIT lets micro-based KERMIT timeout even though a packet has been received, then something is probably seriously wrong anyway). 2. No additional RDTERMS with EDIT=PHYS may be introduced into CMSKERMIT 3. The default start-of-packet character (SOH) and end-of-packet character (CR) must not be changed if the filter is being used I have not tested the filter extensively yet, and what testing has been done has involved only PCKERMIT 1.20. I hope that the filter will also work with any ot other micro-based version of KERMIT, including MSKERMIT. I am trying to arrange to test MSKERMIT here (I don't have enough memory in my PC) and also to test the 7171 connection. I don't think the program is ready to distribute, but I would like to make it available to a limited number of other sites for testing. I wo would like to know if the restrictions I posed above are reasonable ones for CMSKERMIT to live with, if there is any interest at all in distributing a n addon utility like this one, and if you can give me some help in arranging testing with other sites. Thanks in advance! [Ed. - We will definitely take a look at this for the next release of CMS Kermit, which we're working on now. Packet transmission through a 3270 protocol emulator is a hard problem to attack, but for the Series 1 there seems to be this simple workaround of putting it in "transparent mode". Since the Series 1 is so common, it's worth handling as a special case, possibly with SET commands in KERMIT-CMS itself so that the restrictions you mentioned could be lifted.] ------------------------------ To: info-kermit@cu20b.arpa Subject: Thinwire SLIP Protocol Withdrawn Date: 23 Oct 84 13:36:58 EDT (Tue) From: Gary_Delp <delp@udel-ee> Please Post: The authors of RFC914 (the Thinwires) thank all and sundry for the comments they have received, directly and otherwize. For those who scan only the tops of messages, and for those who read the whole things, we would like to retract from consideration SLIP, the Serial Line Interface Protocol. [Ed. - Rest of message omitted, see ProtocolS or Info-Micros for details. The authors retired SLIP in favor of RATP, which was discussed briefly in Info-Kermit #32 because it compared itself to Kermit protocol. There's also another message on ProtocolS, further discussing Kermit vs PCnet vs RATP etc] Signed, Gary Delp Dave Farber Tom Conte ------------------------------ Date: Fri 26 Oct 84 10:40:43-PDT From: ALFIERI@ECLD.#ECLnet Subject: TurboDos To: info-kermit@CU20B.ARPA Is there a version of Kermit for TurboDos? Thanks in advance. vince alfieri computing information services university of southern california alfieri@usc-eclb [Ed. - Not that I know about. Anybody out there working on one?] ------------------------------ End of Info-Kermit Digest ************************* ------- 3-Nov-84 11:11:58-EST,9969;000000000001 Mail-From: SY.FDC created at 3-Nov-84 11:11:38 Date: Sat 3 Nov 84 11:11:38-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #36 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Sat, 3 Nov 1984 Volume 1 : Number 36 Today's Topics: Problems with MSPCTRAN Kermit-11 for PRO/RT11 Kermit Micro-to-Micro Documentation Sirius/Victor Kermit Question Kermit for Apple // ProDOS? MacKermit Problem Bugs in kermit.c KERMIT for the BBC micro? WYLBUR Kermit? ---------------------------------------------------------------------- Date: Tue, 30 Oct 84 07:28 EST From: Wiedemann@RADC-MULTICS.ARPA Subject: Problems with MSPCTRAN To: info-kermit@CU20B.ARPA Is there someone out there with whom I can establish direct contact on this net that has successfully installed CU20B's Kermit V 2.26 on a Z-100??? I have tried, on-and-off, time permitting, to use MSZ100.BOO and MSPCTRAN to make an MSKERMIT.EXE file for my Z-100. Both files were received using the earlier version of Kermit for the Z-100. The conversion of the ".BOO" file was uneventful. When I tried to execute it, the sign-on message was displayed, followed by continually scrolling garbage. I've gone through this complete procedure (starting with new ftp'd files) three times in an effort to eliminate random errors. The results were consistent. If you can lend a hand here, I'd appreciate it. We now have Kermit on our MULTICS system and more Zeniths are arriving every day. Wolf Wiedemann RADC-MULTICS [Ed. - Our fault, sorry! There was a bug in MSPCTRAN. It went undetected for a long time because the bug didn't surface on the .BOO files we tested it on. See next message.] ------------------------------ Date: Wed, 1 Nov 84 07:28PM EST From: Sy.WBC3@CU20B Subject: Re: Problems with MSPCTRAN To: info-kermit@CU20B.ARPA Fix for MSPCTRAN: change line 400 from: 400 if len(x$) < 4 goto 300 ' Is the input buffer empty? to: 400 if len(x$) < 2 goto 300 ' Is the input buffer empty? and insert at line 425: 425 if len(x$) < 3 goto 300 ' Is the input buffer empty? This was tested and works fine, though it takes over 25 minutes. -Bill Catchings [Ed. - The new MSPCTRAN.BAS is in KER: on CU20B.] ------------------------------ Date: Thu 1 Nov 84 10:59:42-EST From: Brian Nelson <OC.BRIAN@CU20B.ARPA> Subject: Kermit-11 for PRO/RT11 To: sy.fdc@CU20B.ARPA The following files are the minimum to get kermit-11 onto the PRO/RT11: KER:K11PRT.MAC, KER:K11PRT.HEX, KER:K11HEX.MAC and KER:K11HLP.HLP. The file K11HEX.MAC is assembled and linked into K11HEX.SAV and then run to get the save image created. The file K11PRT.MAC has notes in the beginning re 2 mods that should (almost MUST) be made to the DEC-supplied XC handler. Failure to do so will result in internal handler buffer overruns. A complete Kermit-11 will be forthcoming soon, meanwhile some Pro/RT users can try this out. The new Kermit-11 also does repeat count stuff. Note: Requires XM, use VTCOM to download the files from the host. brian nelson ------------------------------ Date: Thu, 1 Nov 84 14:39 EST From: FAMCP@CUVMA.BITNET To: SY.FDC@CU20B Subject: Kermit Micro-to-Micro Documentation Frank-- GLAD YOU LIKED THE DOCUMENTATION. WOULD IT BE POSSIBLE TO ADD THE ARTICLE TO THE KERMIT DOCUMENTATION AREA ON YOUR TAPES AND IN YOUR FILES? NORMAN [Ed. - Yes, Norman's article on micro-to-micro use of Kermit is in KER:KMICRO.DOC on CU20B. It's primarily a tutorial on using "primitive" Kermits between two micros; server operation -- which is now available in MS-DOS Kermit -- is not discussed.] ------------------------------ Date: 29 Oct 1984 1623-PDT From: HAL.DOVE at Ames-VMSB Subject: Sirius/Victor Kermit To: info-kermit at cu20b I have the MASM version of the Sirius kermit. Are there any others out there that use this version on UN*X. The problem I am having is that the vt100 emulation does not work too well. It does not open and close lines too well. If I use vi, open line or delete line in the middle of the page does not work. Is there anyone out there who has a corect termcap to make this work correctly. If not, I plan to modify the code to have the kermit emulate vt52 when vt100 is off. This would be trivial except I would still like the function keys defined as break and exit as they are when in vt100 mode. Has anyone made this fix? If so I would like to get a hold of it. Any help would be more than appreciated! Mike hal.dove@ames-vmsb ucscc!emacs@berkeley ------------------------------ Date: 25 October 1984, 16:32:26 CST From: Ben E. Colley 882-7686 C1453Y at UMVMA 103D Lefevre Hall To: Frank da Cruz FDCCU at CUVMB Subject: Kermit for Apple // family Hello from central Missouri.. I work here at UM-Columbia in Computing Services, Micro Support, and am trying to track down some information about Kermit and the Apple // family. Particularly, are you aware of a version that runs under ProDOS, and runs with VM?? Perhaps you know of someone else who might shed some light on this topic. HELP.... and Thanks. Ben.... [Ed. - Anybody working on a ProDOS Kermit?] ------------------------------ Date: 31 Oct 1984 15:06-EST Subject: MacKermit Problem From: POLARIS@USC-ISI.ARPA To: ENGEL@HARVARD.ARPA, INFO-KERMIT@CU20B.ARPA Steve, I just got a copy of the second MacKermit release. Thanks for providing the "Rest Of Us" with an alternative to MS-Basic and MacTerminal. I am having a problem with getting MacKermit to send pad characters. Looking at the source, I think the problem is in the "spack" routine. When sending the pad characters, "count" is not initialized. This causes MacKermit to "go away" for a long time (it appears to be sending LOTS of characters). Thanks again for all the effort it took to get this thing together in the first place. Ed Eldridge [Ed. - By the way, there is now a copy of the file in BINHEX format on CU20B, as KER:MC1KERMIT.HEX.] ------------------------------ Date: Thu, 1 Nov 84 10:07:53 GMT From: Chris-on-Fridays <cjk@ucl-cs.arpa> To: "sy.fdc" <sy.fdc@cu20b>, info-kermit@cu20b Subject: Bugs in kermit.c Frank & Info: In process of implementation I have found 2 more bugs in both kermit.c & uxkermit.c:- 1. In the receive routines, rinit() rfile() & rdata(), case 'E' of the switches, an error-message is printed from "recpkt" whereas it has actually been received into "packet". 2. The debug packet-printing routines in spack() & rpack() both test for no-data by testing that the pointer "data" is NULL. In many cases the pointer itself is valid, but points to a null string. A better test is if "len" in spack() or *len in rpack() is zero. Incidentally, the UCL 11/44 unix, which I termed "non-standard", is in fact a standard Berkeley 2.8. I have got working code including timeout and flushinput, if you're interested. Currently embedded in the simple remote-only version which I hacked up because asked not to spend much time on it, but could obviously be transferred to the a.s.a.d. version on which you are working. In connection with the Aztec-C / CP/M version which I have implemented for the RML 480Z micro, I had some trouble with stacked NAKs (the well-known problem, which I was intentionally triggering). To stop Kermit entering and staying in a stable state of sending each block several times, I tried several stategies and eventually found that flushing input automatically at the end of every packet read is a complete cure. In the C-version this means replacing the "get and toss EoL character" call in rpack() by a call to flushinput(); which in any case seems more sensible, since once you've got the checksum you are home-and-dry (give or take any problems about speed of line turnaround, which can be solved by padding). Comments? Chris Kennington. ------------------------------ Date: Thursday, 1-Nov-84 15:32:08-GMT From: RICK (on SXKL10 DEC-10) <rick%essex@ucl-cs.arpa> To: "cc.fdc" <cc.fdc%columbia-20.arpa@ucl-cs.arpa> Subject: KERMIT for the BBC micro Frank - do you know if anyone has produced (or is working on) a KERMIT for the BBC micro? A contact name would be useful. I have already posted this notice on the COM systems at QZ, UCD and York, so there's probably no need to put it in the Info-Kermit Digest unless you particularly want to. I felt that you might, being at the centre of things, have access to information about implementations about which I don't know. [Ed. - Anybody?] ------------------------------ Date: 2 Nov 84 15:22 EDT From: "David H M Spector" <SPECTOR@NYU-CMCL1.ARPA> To: info-kermit@CU20B.ARPA Subject: WYLBUR Kermit?? Hello, Does anyone have any knowledge of a version of kermit designed to run under WYLBUR (a sub-system under MVS) on IBM systems? The only other version that might work would be the TSO version, but our local IBM systems folks tell me it would need some large mods. any pointers gratefully accepted! (Please mail to me, I'll summarize if I get any replies.) David HM Spector NYU/acf Systems Group Arpa: Spector@nyu-cmcl1.ARPA uucp: ...!allegra!cmcl2!cmcl1!spector [Ed. - I don't think so, but it's an interesting idea...] ------------------------------ End of Info-Kermit Digest ************************* ------- 9-Nov-84 18:12:05-EST,21594;000000000001 Mail-From: SY.FDC created at 9-Nov-84 18:11:47 Date: Fri 9 Nov 84 18:11:47-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #37 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Fri, 9 Nov 1984 Volume 1 : Number 37 Departments: (hope this new format doesn't cause any problems...) ANNOUNCEMENTS - UUCP Kermit Access Now Available BITNET KERMSRV Disk Updated UNIX KERMIT - Unix Kermit Bugs and Problems (several messages) MS-DOS KERMIT - MS-DOS Kermit Disks Available from PC SIG Problems Assembling MS-DOS Kermit with Different Assemblers MS-DOS Kermit V2.26 Key Definition MSDOS (PCDOS) Kermit vs 8251 Chip MS-DOS Kermit CRC Problems MS-DOS Kermit 2.26 Bug List More on Concurrent PC DOS 3.2 Kermit for Convergent Technologies C3 CP/M KERMIT - Kermit on the NEC 8800 TurboDos Kermit MISCELLANY - Kermit for Compugraphic Photocomposer? ---------------------------------------------------------------------- Date: 7 Nov 84 9:49:20-CST (Wed) From: Mark Vasoll <vasoll%okstate.csnet@csnet-relay.arpa> To: Frank da Cruz <SY.FDC@CU20B> Subject: UUCP Kermit Access Now Available I have won approval from our administration to allow UUCP access to the Kermit sources on our system from 10:00pm until 10:00am CST, 7 days per week. A command like: "uucp okstate!/u/kermit/ux* dir" should transfer the UNIX Kermit distribution to the requesting system. The file names are the same as those distributed on the Columbia Kermit tape. We would appreciate a short "plug" anywhere that you distribute the login information. Something like this would be nice: UUCP distribution of Kermit is provided as a public service of: Oklahoma State University Department of Computing and Information Sciences Stillwater, Oklahoma I hope that this helps promote your Kermit project, we are certainly excited about it. UUCP login information for site: okstate Phone number : (405) 624-6953 (one line only) Login name : uucpker Password : thefrog Hours : 10:00pm - 10:00am central time (7 day per week) Problem : okstate!uucp-support (UUCP) reports : uucp-support%okstate@csnet-relay (ARPA) The phone number is for 300/1200 baud (bell compatible). The tape that we received was dated (by Columbia) as Sep. 28, 1984. The newest version of MS-DOS Kermit has replaced the version that was on the tape, other than that things are as they were when you made the tape. - Mark Vasoll [Ed. - Thanks! We'll add this information to our flyers and blurbs.] ------------------------------ Date: Thu 8 Nov 84 11:51:35-EST From: Frank da Cruz <SY.FDC@CU2OB> Subject: BITNET KERMSRV Disk Updated To: Info-Kermit After a long hiatus, the BITNET Kermit distribution area is being updated again. The entire distribution area from CU20B was transferred to CUVMA, and will be incrementally updated on a regular basis from now on, I hope. Kermit files are available to BITNET sites via a server at host CUVMA. For information about this service, type the following command on your own BITNET host: SMSG RSCS MSG CUVMA KERMSRV HELP ------------------------------ Date: Mon 5 Nov 84 11:55:23-EST From: Bill Catchings <Sy.WBC3@CU20B.ARPA> Subject: UNIX Kermit bug To: Sy.FdC@CU20B.ARPA There is a problem with UNIX kermit that if you use the line command and the baud command with a speed different from that of your controlling terminal Kermit seems to hang. This is actually caused by setting both the assigned line and the terminal line to the speed requested. The following will fix this problem. In module uxkercnu.c make the following changes: From: extern int remote, ttyfd, lecho; To: extern int remote, ttyfd, lecho, speed; After: if (remote) /* Nothing to connect to in remote */ { /* mode, so just return */ printmsg("No line specified for connection."); return; } Add: speed = 0; /* Don't set the console's speed */ Hopefully this change will make using UNIX Kermit a little bit more useful! -Bill Catchings [Ed. - This change is installed in the Columbia Kermit distribution files, KER:UX*.* on CU20B. Also, the connect command modules have been renamed to make their names unique within 6.3 filename format: old new UXKERCNU.C -> UXCONU.C (Connect command for Unix) UXKERCNV.C -> UXCONV.C (Connect command for Pro-350 Venix) ] ------------------------------ Date: Fri, 9 Nov 84 10:24:10 GMT From: Chris-on-Fridays <cjk@ucl-cs.arpa> To: info-kermit@cu20b.arpa Subject: Unix Kermit Bug and Problem There's another bug in kermit.c & uxkermit.c. If you are using a transmission medium which slaps in even parity bits to your characters, SOH becomes 0x81. This won't match with the test at the beginning of rpack(), so you never read a block .... The same applies to all the tests "if (t == SOH) ..." inside the main "while". All these ought to be relocated AFTER the stripping by "if (!image) t &= 0177"; it stands to reason that if you are using this sort of awkward medium, you aren't in "image". Being purist, all except the data bytes ought always to be stripped. You could get some uncomfortably long blocks if you had a garble in "image" ... [Ed. - Good idea.] And now for a problem. This awkward medium also eats "%" as an escape character. It does permit you to change the escape, but only to a printable. I've been using reverse-quote, which doesn't occur in the sequence-characters or in my init parameters, and is an oddity in data; but there is nothing to stop it occurring in the length unless I set down the far end's max blocksize. Any suggestions? Should an optional feature be to double a specified character (at the char-to-line level, not affecting length or checksum)? Of course this only affects the implementation, not the protocol, so it could in fact be implemented in any specific Kermit as a private extra feature. Chris Kennington. [Ed. - We already have encountered media where the escape character has to be doubled, and some Kermits already have this code. There's no reason not to include a facility for this in an implementation, though it's hard to devise a natural syntax that doesn't conflict with existing commands. Maybe "SET DOUBLED x" where x is the character that must be doubled during transmission. A more general solution would involve changes in the protocol.] ------------------------------ Date: Fri, 9 Nov 1984 2:36pm EST From: Frank da Cruz <SY.FDC@CU20B> To: Info-Kermit Subject: MS-DOS Kermit Disks Available from PC SIG MS-DOS Kermit 2.26 may be ordered on IBM PC format floppy disk from: PC SIG 1556 Halford Avenue, Suite #130 Santa Clara, CA 95051 (408) 730-9291 on disks number 41 and 42, for $6.00 per disk. I believe (but am not certain) that one disk contains the source and the other contains the .EXE for the IBM PC only, plus documentation (User Guide manual chapter for MS-DOS Kermit), and system-dependent source for some of the other MS-DOS systems, like Wang PC, HP-150, and DEC Rainbow. ------------------------------ From: mark@digi-g.UUCP (Mark Mendel) Subject: Problems Assembling MS-DOS Kermit with Different Assemblers Date: Thu, 1-Nov-84 14:21:13 CST Apparently kermit is supposed to be compiled with IBM's MASM, not MicroSoft's. I have fixed the incompatablitiy that generates compile errors and it runs. However, perhaps it is responsible for the problems I still have: None of the `sub-process' commands work: DIR, RUN, etc. I end up in a sub-COMMAND processor that complains `Ilegal COMMAND path' or some such. The environment is not being passed. I have traced through the bloody thing to the EXEC command. And it looks IDENTICAL to calls that work in some of my programs. Does anyone have it working? Does anyone have a version that compiles with Microsoft MASM and works? ---Mark Mendel ---ihnp4!umn-cs!digi-g!mark [Ed. - First, make sure that your PATH environment variable is set to include the areas where the sub-process are to be found. If the problem persists, it may be that your assembler/linker combination orders the segments differently from the IBM assembler/linker; try including the dummy module MSXDMB in your linking sequence, to ensure that the segments are ordered correctly.] ------------------------------ Date: 6 Nov 1984 14:14-EST From: Israel.Pinkas@CMU-RI-ISL1.ARPA Subject: MS-DOS Kermit V2.26 Key Definition To: Info-Kermit@CU20B I am currently using Kermit V2.26 and would like to know if there is any way to define a key using the SET KEY command within a TAKE file. Thus I would like SET KEY SCAN 83 \177 The problem is that take uses the backslash itself. Quoting the backslash with another one does not work. Also, \134177 does not work for the obvious reason. \134 177 does not do what I want. (The 134 is octal for the backslash, 177 for delete. I am trying to have the delete key send a delete.) Any help would be appreciated. Israel Pinkas (igp@CMU-RI-ISL1.ARPA) ------------------------------ Date: 6 Nov 1984 14:14-EST From: Frank da Cruz <SY.FDC@CU20B> Subject: Re: IBM-PC Kermit V2.26 Key Definition First of all, there's nothing wrong with your first SET KEY definition. It works just fine for us on a variety of machines, and should work for you. TAKE doesn't do anything special with backslashes. Here are a few fine points about the current operation of MS-DOS Kermit 2.26 key redefinition: . Unlike Unix, MS-DOS Kermit does not accept "\\" as a quoted backslash. To include a backslash, specify \134. . Backslash-quoted quantities cannot be concatenated directly with digits, because the boundary is ambiguous. For instance, to specify a backslash followed by the characters "177x", you could not use \134177x. Nor could you use \134 177x, because the space would be included. Instead, you must use: \134\61\67\67x (the digit "1" is ASCII 61 octal, the digit "7" is ASCII 67). . You may include a SET KEY SCAN command in a macro definition this way: SET KEY SCAN 270,foo The macro expander interprets literal commas as carriage returns. To include a comma as part of your macro definition, use \54 as in SET KEY SCAN 271,foo\54bar which defines the key to send "foo,bar" Although the next release of MS-DOS Kermit might fix the key redefinition code to "break" after the 3rd digit following a backslash, the procedure shown above would still be preferable, since it is unambiguous to the reader as well as to the program. ------------------------------ Date: Thu, 8 Nov 84 20:00 EST From: Frankston.SoftArts@MIT-MULTICS.ARPA Subject: MSDOS (PCDOS) Kermit vs 8251 Chip To: info-kermit@CU20B.ARPA Are there any PCDOS implementations that use the 8251 instead of the 8250 chip? The DG/One is a portable (i.e., lapsize) IBM clone except that the communications processor is an 8251 rather than an 8250 as in the IBM PC. [Ed. - This doesn't make the DG/One very compatible with IBM PC software like Kermit that has to handle interrupts from the serial i/o chip...] ------------------------------ Date: 3-NOV-1984 21:47 CST From: DJS05364@NORTHWESTERN.MAILNET To: cc.fdc@COLUMBIA-20.ARPA Subject: MS-DOS Kermit CRC Problems I have found what appears to be a bug in MS-KERMIT ver 2.26. Talking to VMS Kermit ver 2.0.027 with server mode, I downloaded files to MS-KERMIT using the CRC block check (I set the packet size down to 93 chars as you suggested). It worked ok until I turned debug mode on in MS-KERMIT; then all downloads failed by exceeding max retry count in packet 2. Downloads continued to fail even after turning debug mode back off. However, when I told the Vax not to use the CRC, downloads worked. Downloads with CRC also resumed working when I brought up a fresh copy of MS-KERMIT on the PC. There seem to be other circumstances that cause MS-KERMIT to fail similarly, but I haven't determined what exact parameter settings or sequence of events produce them. Is there a file of known bugs in MS-KERMIT that I can get access to? It would help my implementation task considerably. Also, are you planning a new release in the near future? Dave Slate [Ed. - See below.] ------------------------------ Date: Wed 7 Nov 84 10:32:44-EST From: Daphne Tzoar <Sy.Daphne@CU20B.ARPA> Subject: Re: [DJS05364@NORTHWESTERN.MAILNET: MS-KERMIT problems] To: SY.FDC@CU20B.ARPA It sounds like debug mode overwrote the end of the buffer for the incoming packet in packet number 2, the first data packet (init and filename packets weren't long enough to do that). And the buffer just happens to be followed by the CRC table. So, even though he turned off debug mode, the damage was already done and the CRC table was overwritten with the dollar sign used to print the packet (or so is my guess). Then when he stopped using the CRC or started the new MS Kermit, it was all OK. That problem will hopefully go away when we enlarge the buffer size for incoming packets. I will verify that this really was the problem though. /daphne ------------------------------ Date: Fri 9 Nov 84 10:32:44-EST From: Frank da Cruz <SY.FDC@CU20B> Subject: MS-DOS Kermit 2.26 Bug List To: Info-Kermit Here's a very brief summary of the known or reported bugs in MS-DOS Kermit, version 2.26. Most of them will be fixed in 2.27, coming soon. This list is also available in the file KER:MSKERMIT.BWR. LEA's should be changed to MOV ..,OFFSET or to LEA ..,WORD PTR in msfile. Build instructions should include linking with MSXDMB module to ensure segments are arranged in the right order. Must build all versions with MSXDMB module to ensure segments correctly ordered. Set dest printer should be fixed to use PRN, not LPT1. In Rainbow, should save character attributes in prev/next screen. In Rainbow, prev/next screen sometimes overshoot. In IBM H19 emulation, tabs shouldn't be destructive. on IBM, Insert/Delete line can mess up the screen because scrolling one line with the ROM calls does funny things. on IBM, carriage returns in inverse video mode shouldn't scroll inverse lines onto screen (? this is why MORE acts funny) On Rainbow, break should really be 275 msec. On IBM, echo in status line display is backwards. On IBM, when reading from keyboard, should strip eighth bit, since these can make command parser crash. Set key scan <space><space><return> doesn't work properly. Make \ooo interpreter break after 3 digits (it already breaks at the first non-digit). Return key to retransmit packet undocumented in display. At RDAT33, should check to see if dest is printer and put a ^Z if so, regardless of EOF mode, so buffer isn't printed twice (someone sent this one in; we should make sure it's really the problem). No way to set Heath wrap on/off. Rainbow set baud command missing. SET EOF CTRLZ doesn't work. Someone claims that an unquoted 0 byte gets put into the data field of all F and D packets, because of a bug in encode. On IBM, the checking for the keypad plus key should be moved so it can be redefined. Also, use of the + key to toggle the mode line is undocumented. Kermit should keep the rainbow out of VT52 mode. Also, it should resist attempts to send $8 and $c to the firmware, since they crash it. On rainbow, Cursor keys should be fixed - they get changed as well as the keypad with esc =. In inpkt, don't start filling the buffer until the SOH is detected, to protect against buffer overruns. When an SOH is detected, make sure packet is started again. Discard packets if they're the same type as what we just sent in case hardware echoed it back. Enlarge the input buffer size to prevent "off-by-one" errors that can overwrite critical data, like the CRC table. Renaming code sometimes overwrites original name? Abort code should close open files if set incomplete keep is on. SHOW MACRO should be SHOW MACROS. Check table overflow code in set key. Generic DOS Kermit doesn't always ask for port numbers on new machines; need to add SET PORT [device|file-handle] ... [We have also kept all the bug reports we've received by mail, so if your pet bug doesn't appear in this list, we still have it.] ------------------------------ Date: Wed 24 Oct 84 07:57:12-PDT From: Jim Celoni S.J. <Celoni@SU-SCORE.ARPA> Subject: More on Concurrent PC DOS 3.2 To: Info-IBMPC@USC-ISIB.ARPA To correct what I said Saturday: Concurrent PC DOS 3.2's REDOES command *is* documented, at the end of the file hdmaint.doc on one of the distribution disks. While reading my mail yesterday, I discovered that when run under CDOS, Kermit 2.26 drops many incoming characters (5-10%?)--my guess is that the screen writes via "DOS" don't all work but the direct ones (more common in Emacs) do. File transfers work fine, though two have ended early with a message about "F" not being a valid server command. I regret the error. +j ------------------------------ Date: 8 Nov 1984 1720-EST From: LCG.KERMIT To: EIBEN Subject: Kermit for Convergent Technologies C3 I HAVE BEEN USING A VERSION 1.0 KERMIT HERE BETWEEN IBM PC/XT AND OUR DEC-10 FOR A WHILE. I BUILT A C3 (CONVERGENT TECHNOL.) KERMIT FROM THE PC VERSION AND IT WORKS WELL WITH DEC-10 VERSION HERE. MY PC/XT VERSION SUPPORTS HAYES WITH AUTO-DIALING AND HAS A AUTO-LOGIN FEATURE (FOR OUR DEC-10). THE C3 VERSION WORKS WELL AND HAS BEEN LOADED ONTO A BURROUGHS B-20 AND WORKS (B-20, C3 ARE ALL CONVERG. TECH. MACHINES).IF I GET MY KERMIT TO WORK WITH YOURS I WILL SUBMIT THEM. JEAN R. ROY, DOT/TSC, KENDALL SQ., CAMB. MA. 494-2064 OR 494-2344 TSC COMPUTER CENTER [Ed. - Will announce this if it ever shows up.] ------------------------------ Date: Tue 6 Nov 84 15:21:29-EST From: Lee.Sailer@CMU-CS-C.ARPA Subject: Kermit on the NEC 8800 To: info-cpm@AMSAA.ARPA I've been trying to get kermit-80 v3 up. I've changed the defio to 81H and batio to 42H in the generic version. It seems that I can send stuff to the COMM port OK, but that I do not get anything back. Any help, ideas, working versions of kermit for NEC etc would be appreciated. thanks in advance. [Ed. - See next message] ------------------------------ Date: Tue 6 Nov 84 21:50:59-PST From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: Re: Kermit on the NEC 8800 To: Lee.Sailer@CMU-CS-C.ARPA I used Kermit with an older version of the 8800 and had no problems, but later when I was doing it with a more recent model I found that the BAT: device as implemented by the new version of CP/M did not support the console status call. In other words, the status always returns not ready for the serial port so no input occurs. It was necessary to patch CP/M to get it to work. Your numbers for batio and defio are fine, although the defio is not critical since that is replaced by the current iobyte value when Kermit is loaded. -- Ron ------------------------------ Date: Tue, 6 Nov 84 10:22:55 EST From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers) To: info-kermit@cu20b.ARPA Subject: TurboDos Kermit A couple of issues ago there was a request for a TurboDos Kermit - well, one of our users (Rod Van Cooten) has modified Kermit-80 to run on TurboDos versions 1.22 and 1.3. The modification assumes that the implementation of TurboDos includes the communications driver calls. If this is of interest, let me know and I should be able to arrange for a copy to be sent to you. Steve Withers Computer Centre, University of Melbourne. [Ed. - Will announce this when it arrives.] ------------------------------ From: decvax!mulga!robin.deakcm@Berkeley Date: Thu, 8 Nov 84 14:14:38 EST To: Info-Kermit-Request%CU20B%COLUMBIA.ARPA.mulga@Berkeley Subject: Kermit for Compugraphic Photocomposer? Does anyone out there in the swamp have a version of Kermit that will run on an MCS COMPUGRAPHIC photo-typesetting system? Everybody and his dog here is writing their theses, books, lecture notes etc. etc using bloody Wordstar on CP/M systems, and they seem to expect the Compugraphic to be able to somehow magically read their wierdo disk formats (and Wordstar format files to boot - but that's another story) so they can get the stuff photoset. An MCS Kermit would at least solve the filetransfer problem! [Ed. - Is it possible to program this thing? The only Compugraphic I've heaard about (the 8600?) was designed to communicate only with its own built-in "data entry stations", with only a paper tape reader for the outside world, and was not programmable.] Thanks for all the good work! I hope we can make some contribution next year - possibilities are Hitachi Peach and S-1 versions (8-bit systems that I understand aren't on the US market, but are reasonably common here.) Regards, Robin Simpson Computer Centre Deakin University GEELONG, Victoria Australia ------------------------------ End of Info-Kermit Digest ************************* ------- 16-Nov-84 19:21:37-EST,10073;000000000001 Mail-From: SY.FDC created at 16-Nov-84 19:21:14 Date: Fri 16 Nov 84 19:21:14-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #38 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Fri, 16 Nov 1984 Volume 1 : Number 38 Departments: MS-DOS KERMIT - Kermit 1.20 for ACT Apricot Second Version of TI-Pro Support for MS-DOS Kermit 2.26 Enhanced NEC-APC Module for MS-DOS Kermit 2.26 Kermit for Sanyo PC MISCELLANY - New DEC-20 Kermit Kermit for BBC Micro UUCP Login to okstate ---------------------------------------------------------------------- Date: Wed 14 Nov 84 16:41:44-EST From: Johan Ph. Kelders Rekencentrum der Rijksuniversiteit Postbus 800 9700 AV Groningen The Netherlands Subject: Kermit for ACT Apricot To: Info-Kermit@CU20B.ARPA Recently I have adapted Kermit for the ACT (Applied Computer Techniques) Apricot computer, using the IBM-PC/Z100 version (1.20). The program has been used by several people for some time now and has been functioning very well, with speeds up to 9600 baud. There are many small changes and only a few larger ones, so it seems the best if I describe in general what the changes are along with sending you a floppy disk with the complete source text. There are four kinds of changes: - The Apricot has a software interface to access its devices (or the drivers) which is called the Control Device. It can be used to set baud rate, bits/character, etc, at the serial port. It can also be used to input characters from the serial port or to return a code indicating no character is present. The calls to the Control Device you will find in a separate setup routine APRSET at the end of the source, in the baud rate setting routine and in two places where input from the serial port is done. For output to the serial port, the DOS function 4 (auxiliary port output) is used. - The escape sequences for screen cursor control are the same for the Apricot as for the Z100, so these conditionals have been combined (IF Z100 OR APRICOT...). - Sending a BREAK is not possible when using the Control Device, so this has been suppressed (the command has no effect). To send a BREAK could be doine by controlling SIO directly, but then the whole serial port driver would probably have to be rewritten. - The "standard" keyboard cannot generate CTRL-] or CTRL-\ and some other codes like that. However, you can completely redefine every key, so at startup of Kermit the appropriate escape sequence is sent which defines CTRL-] to send just that. An adaptation which has been done but left out of this version is the setting of the modem control lines, such as DTR, CTS. This can be done outside Kermit by changing the BIOS parameters on disk with a setup program or by using a program called SERIAL. I hope the descriptions together with the source code will enable you to include the changes in the next version of Kermit. [Ed. - The source is in KER:APRICOT.ASM. There is also an APRICOT.BOO file, for downloading with MSBOOT.FOR/MSPCBOOT.BAS or MSPCTRAN.BAS. The 8-bit binary file is in KB:APRICOT.EXE. Any volunteers to adapt all this into the version 2 MS-DOS Kermit modular style?] ------------------------------ Date: 12 Nov 1984 2127-EST From: LCG.KERMIT To: EIBEN Subject: REV 2 of TI-PRO KERMIT I uploaded MSXTIPRO.ASM, .BWR; MSTIPRO.HLP, .EXE, .BOO. This one has the previous bugs fixed, I am still working on revision 3. Joe Smith, CSM Computing Center, Golden CO 80401 (303)273-3448 [Ed. - It's available on CU20B. The .ASM, .HLP, .BOO, and .BWR files are in KER:, the .EXE file is in KB:. According to the implementation notes, revision 3 of the TI support will include faster port i/o (interrupt-driven rather than polled) and graphics terminal emulation (Tek 4010 and/or Regis).] ------------------------------ Date: Wed, 14 Nov 84 06:24:12 pst From: dual!islenet!gibbons%Berkeley@columbia.arpa To: Info-Kermit@CU20B Subject: Enhanced NEC-APC module for MSKERMIT Here is an enhanced MSKERMIT 2.26 system module MSXAPC.ASM for the NEC-APC. I took Ron Blanford's fine working module for a start, and then added full key scan-code redefinition, auto-determination of color/monochrome for CRT formatting, direct video access for faster help menus, and a scroll/noscroll key that sends ^S and ^Q alternately. To make things compatible with the APC operating system, I had to make two minor changes to the MSTERM module - these are detailed below. Also I picked up what appeared to be a bug in MSCMD that causes a system crash if the user attempts to enter a key definition string longer than 127 characters - a fix that catches the problem and gives an error message is given below. The full code for the MSXAPC module and a brief updated APC help file are appended. Ian Gibbons, U of Hawaii [Ed. - Since changes to the other modules are involved, I can't install it just yet. It should be part of the next release, 2.27, soon to appear. This announcement is included as a public service to anyone else who may have been contemplating doing these things.] ------------------------------ Date: 09 Nov 84 21:30 +0100 From: Conor_Cahill_of_Trinity_College_Dublin%QZCOM.MAILNET@MIT-MULTICS.ARPA To: KERMIT_implementation_and_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Kermit for Sanyo PC Has anybody heard of a Kermit for the Sanyo? I would endeaver to modify the IBM PC version but I can get no documentation on the Sanyo except for a very superficial user's guide. This is not enough to do a Kermit. I would be glad (and so would a lot of users here) if this had already been done. [Ed. - See below for an answer. By the way, it's not usually a good idea to mail directly to "Info-Kermit-Members", since this makes the message go to each of the several hundred individuals, bboards, and mailing lists on the Info-Kermit distribution list, and ties up many mailers for a good while. The "To:" address of this message apparently includes Info-Kermit-Members@CU20B; better to mail to Info-Kermit.] ------------------------------ Date: Tue, 13 Nov 84 18:13:12 EST From: Peter DiCamillo <CMSMAINT@BROWNVM> To: Info-Kermit@CU20B Subject: Kermit for Sanyo PC The same day I read the mail requesting Kermit for the Sanyo, I received in the mail a letter from Solution Software 3421 N. 1st Ave. #120 Tucson, AZ 85719 (602) 323-0841 It begins: "We would like to bring your attention to a new micro-mainframe communications program for the IBM PC, Sanyo MBC 550 series, and compatibles. This program, called VersaCom, includes the following: VT100 Emulation [description] Large Capture Buffer [description] Programmable Keys [description] Kermit This is a file transfer protocol for transfers between different types of systems. It includes eighth-bit quoting for transferring binary files, and repeat-count quoting which allows compression of data as it is transmitted. Xmodem [description] System Requirements Versacom is available for the IBM PC and the Sanyo MBC 550 series. It requires 128 Kbytes of RAM and a standard serial port. VersaCom, along with 45 pages of documentation, is available from Solution Software at the above address. The cost is $35 plus $5 postage and handling. Demo copies are available for $10." I've never heard of Solutiion Software or VersaCom before. I hope you will find this information helpful. Peter [Ed. - We've granted permission to a number of companies to include Kermit in their terminal emulation or multi-protocol file transfer packages under the conditions listed in KER:COMMER.DOC. However, this is one company I don't recall. Thanks to everyone who responded with messages about this product.] ------------------------------ Date: Thu 15 Nov 84 19:14:37-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: New DEC-20 Kermit To: Info-Kermit@CU20B.ARPA Two minor changes: (1) A bug with ITS binary files is fixed (thanks to Keith Peterson for tracking it down). (2) The (local) CWD command now behaves exactly like the Exec CONNECT command -- it doesn't prompt you for a password unless it really needs one. Source in KER:20KERMIT.MAC, binary in KB:20KERMIT.EXE on CU20B. The new version is 4.2(253) and replaces 4.2(251). - Frank ------------------------------ Date: Mon, 12 Nov 84 10:52:31 GMT From: Cjk@ucl-cs.arpa To: rick%essex@ucl-cs.arpa Subject: Kermit for BBC Micro UCL is intending to use Kermit to a substantial extent for file transfers between unix (11/44 & VAX) and various micros, including BBC. We have every intention of putting up a Beeb version. The job has been assigned to a chap starting work tomorrow (13th). I am not in charge of this - it comes under C/S's communications group, headed by Rob Cole. If you want to know more about the status of this, I suggest you mail him as "robert@ucl-cs". Chris Kennington. University College London ------------------------------ Date: 14 Nov 84 22:26:37-CST (Wed) From: Mark Vasoll <vasoll%okstate.csnet@csnet-relay.arpa> To: Frank da Cruz <SY.FDC@CU20B> Subject: UUCP Login to okstate It seems that there may be some confusion about the UUCP login account on our system. The account is for UUCP connections, not regular human users (i.e. you will not receive a command prompt, you will be placed into the UUCP protocol). I have had several login attempts where no work was exchanged, I suspect that people are trying to "look and see" what's here. You might want to pass this along to the Info-Kermit members. Mark ------------------------------ End of Info-Kermit Digest ************************* ------- 28-Nov-84 22:09:44-EST,26722;000000000000 Mail-From: SY.FDC created at 28-Nov-84 22:09:26 Date: Wed 28 Nov 84 22:09:26-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #39 To: Info-Kermit-Members@CU20B.ARPA Info-Kermit Digest Wed, 28 Nov 1984 Volume 1 : Number 38 Departments: UNIX KERMIT - Unix Kermit Update Kermit UUCP Downloading Update USENET Distribution of Info-Kermit MS-DOS KERMIT - PCDOS/MSDOS Kermit suggestion Kermits For Weird Semi-IBM Compatible Machines Kermit bugs/inconsistencies (several messages) VAX/VMS KERMIT - DIAL command for VMS KERMIT Bug Reports, Questions, Answers (several messages) MISCELLANY - TELENET PAD Parameters for Kermit CMS Kermit and Non IBM Controllers? VersaCom ITS Binary Files vs Kermit Kermit for Burroughs XE-520 / B25 (BTOS op sys) wanted MacKermit connect mode Mac Kermit initialization & other bugs Apple 2c design flaw. Commodore 64 Kermit V1.1 on the way ---------------------------------------------------------------------- Date: 28 Nov 84 21:15:00-EST From: SY.FDC@CU20B To: Info-Kermit Subject: Unix Kermit Update Although far from ready for release, some progress has been made on the new (version 4) Unix Kermit. Repeated-character compression and 8th-bit prefixing have been added, along with server mode and execution of host commands. The program has been partially decomposed into modules. The development has been done so far only under 4.2BSD and Pro/Venix, but the support code that was contibuted for Sys III, Sys V, v6, etc, is on hand and will be parcelled out into system-dependent support modules. This program differs radically from other Kermit programs in structure; the protocol module is an actual state table written in the input language of the Unix lex program, with statements of the form <current-state>input {action} allowing the operation of the program and the protocol itself to be clearly laid out in several pages of text. The actual release will use a similar technique, but will not use lex because it's proprietary. As soon as we have a version that's ready to test, it'll be announced. ------------------------------ Date: 16 Nov 84 17:50:12-CST (Fri) From: Mark Vasoll <vasoll%okstate.csnet@csnet-relay.arpa> To: Frank da Cruz <sy.fdc@cu20> Subject: Kermit UUCP Downloading Update I have created a file on our system that contains a directory of /u/kermit (the Kermit distribution area) since many uucp users do not have a list of the available files. The file is /u/kermit/00directory and can be uucped from our system (it seems like a very boring thing to post...). We were having some trouble with the wildcard transfers (they aren't working...), so things like "uucp okstate!/u/kermit/ux* dir" were failing. The problems with wildcard transfers to systems that are not in our L.sys file have now been solved. The UUCP Kermit distribution should be able to proceed without problems now. Mark Vasoll Oklahoma State University ------------------------------ Date: Sat, 24 Nov 84 19:31:21 pst From: fair%ucbarpa@Berkeley (Erik E. Fair) To: info-kermit-request@COLUMBIA-20.ARPA Subject: USENET Distribution of Info-Kermit Add post-info-kermit@UCB-VAX.ARPA and let your readers know that as of now, INFO-KERMIT is being gatewayed to the USENET, so they don't have to (in fact, shouldn't) directly subscribe to the digest if their host is on the USENET. If there are any problems, please let me know. Mr. USENET for UCBVAX, Erik E. Fair ucbvax!fair fair@ucb-vax.ARPA ------------------------------ Date: Mon, 19 Nov 84 22:40 EST From: Frankston.SoftArts@MIT-MULTICS.ARPA Subject: PCDOS/MSDOS Kermit suggestion To: info-kermit@CU20B.ARPA In looking at how to implement support for the 8251 chip in the DG/One, it would be simpler if the MSXIBM module attempted to use the IBM BIOS calls whenever possible. This would allow variations to be more easily supported. I realize that the BIOS does not allow full initialization when one is using interrupts, but it does allow standardization of the baud rate setting (except for 19200 and 38400 which the program doens't support anyway (why not?)) as well as other basic initialization. This would be a useful change for 2.27 if it is not too late. [Ed. - See next two messages. There were some other problems with the BIOS too, like not letting you choose all the common baud rates, e.g. 1800.] ------------------------------ Date: Tue 20 Nov 84 11:09:37-EST From: Daphne Tzoar <Sy.Daphne@CU20B.ARPA> Subject: Re: PCDOS/MSDOS Kermit suggestion To: SY.FDC@CU20B.ARPA I disagree -- the whole point of the system independent modules is to take advantage of the best way to do certain functions in each micro. That's why we don't just use DOS for i/o -- it's too slow to run at anything faster than 1200 and why we need system dependent interrupt driven routine for reading in characters. /daphne ------------------------------ Date: 20 Nov 1984 1222-EST From: LCG.KERMIT To: EIBEN Subject: Kermits For Weird Semi-IBM Compatible Machines I saw on the kermit news some queries about Kermit for DG/1. While this isn't really very good, it'll have to do. The version of Kermit I did for Seequa Chameleon is from an old (v1.18) pckermit, but is super generic. It calls the ROM BIOS (int 14) to do all serial communications. This was needed because the Seequa machine uses an 8274 multi protocol controller instead of an 8250, so is totally different from IBM. (At the time I did the Kermit, I had no specs on the 8274.) Therefore I did everything via int 14h so as long as the BIOS used emulates the IBM BIOS (which it pretty much must to allow print), the Kermit will work. You have to use MODE first to set the port baud rate, and then establish the connection (or fake it with Smartmodem switches), and then run the Kermit to use same, and the Kermit assumes ANSI.SYS is loaded. But it will work at up to 1200 baud. It will even run on an IBM PC. But anybody with one of these near-compatibles can use it (KER:SEEQUA.ASM) until I get around to modifying the 2.26 version for similar operation. I've tried the generic Kermit on the Chameleon withoug too much luck (under PC-DOS 2.0). I may try again with 2.1, but I get easily frustrated by having to power down and back up to continue, so I will more likely just fix the new Kermit. I have a need VT52 initializer now for 2.26 that sets up the whole VT52 keypad, allowing me to TECO etc. Thanks. Glenn Everhart ------------------------------ Date: 24 Nov 1984 1408-EST From: LCG.KERMIT To: EIBEN Subject: Kermit-MS bugs Persons: We have several IBM ATs and XTs running Kermit-MS V2.26 connected to a Vax 750 running Kermit-32 V3.0.052. We are running the newest version of Kermit-MS V2.26, the one that doesn't go from 63K to 1024K on file transfers. This was downloaded from DEC. We have found several bugs and inconsistencies in the Kermit-MS V2.26: 1. Take requires a full pathname even though all other references to files (in send and get) only take filenames. Example: Kermit-MS>take foo ; FAILS Kermit-MS>take \usr\mth\foo ; SUCCEEDS 2. Running Kermit-MS piping from stdin works partially. Stdin gets disconnected whenever you go into the terminal emulator or when you get prompted for a password (REMOTE CWD). Example: Kermit-MS>remote cwd [foo.bar] Password: Additionally, Kermit-MS does not quit on end of file. You must put in a QUIT command at the end of the file, or reboot the system. 3. REMOTE commands touch the floppy disk drive for no apparent reason. Example: Kermit-MS>remote dir ; spins up A: This means that you have to have a floppy in the drive or MSDOS gives you an "Abort, Retry, Ignore?" message. 4. If a REMOTE HOST command executes without doing any output, Kermit-MS does a core dump to the screen and the system must be rebooted. Example: Kermit-MS>remote host set def [foo.bar] Thank you, Michael T. Howard ------------------------------ Date: Tue 27 Nov 84 16:37:00-EST From: Daphne Tzoar <Sy.Daphne@CU20B.ARPA> Subject: Re: MS ? KERMIT bugs/inconsistencies To: SY.FDC@CU20B.ARPA I think the problem with the path is that we don't check the current directory at all if it's not in the path. That has to be fixed. And the last problem is fixed for release 2.27. We did a "close file" call at the end of every receive (and remote commands that write to the screen.) Well, the PC and the XT never complained about a close call for a file not physically on the disk and the AT does. I'm not sure about the second problem though. /daphne ------------------------------ Date: 27 Nov 84 18:55 +0100 From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Info-Kermit <info-kermit@COLUMBIA-20> Subject: Bug in MS-KERMIT? There seems to be a bug in IBM PC Kermit ver 2.26 that makes it bomb with "?Program error Invalid COMND call" after dumping some garbage on the screen. To conjure the bug, have a line like define foo take foo.cmd in MSKERMIT.INI (where FOO.CMD contains a couple of SET KEY F1 DoThisCommand SET KEY F2 DoThatCommand etc.) To conjure the bug, DO FOO a couple of times, and say SHOW KEY <f1> after each try. [Ed. - This is probably the SET KEY buffer overflow problem, which should be fixed in 2.27.] ------------------------------ Date: Thu, 22 Nov 84 05:53 PST From: NEWMAN%SAV@LLL-MFE.ARPA Subject: DIAL command for VMS KERMIT To: Info-Kermit@CU20B.Arpa Frank: Some time ago I implemented a DIAL (and REDIAL and HANGUP) command for VMS KERMIT and the DEC DF03 modem. These commands are probably only of marginal use to other sites, but I thought I'd share them with you. Since I'm not directly on the ArpaNet (and thus people cannot FTP the files) I have included the output from the VMS DIFFERENCES utility here. I have also mailed (in a seperate message) the appropriate SLP command files to make the changes. If you'd like, I will mail you the updated sources. Enjoy... gkn [Ed. - The files, which are too long to be included in mail, are in KER:VMSDIAL.DIF and KER:VMSDIAL.SLP.] ------------------------------ From: lhasa!mghccc!simon@harvard.ARPA Date: 21 Nov 84 09:57 EST To: lhasa!harvard!info-kermit@cu20b.ARPA Subject: BUG IN VMS KERMIT I have found what appears to be a bug in the VMS version of KERMIT (version 3.0.051) which occurs when it is attempting to SEND a file, in my case, to the UNIX C KERMIT (uxkermit on the distribution tape, running on a Masscomp MC500 system). The transfer proceeds to completion, the end-file packet is processed on the receiver (and the file is OK there). The sender then runs into an RMS problem and displays the message KERMIT-E-RMS32, %RMS-F-IFI INVALID INTERNAL FILE IDENTIFIER. (IFI) This is the result of a RMS $SEARCH operation just after entry point NEXT_FILE. This occurs irrespective of whether the sending KERMIT is local or remote. I reassembled and linked KERMIT with DEBUG (from the MACRO sources, since we don't have BLISS) and found that the call to NEXT_FILE is not preceded by a call to CLOSE_FILE ; since the $SEARCH operation has to be done on a FAB with an inactive (closed) file I assume this is the cause. Oddly enough, VMS-Kermit to VMS-Kermit works just fine (!), and there I do see a call to CLOSE_FILE at the end of the file transfer on the sending KERMIT, just prior to the NEXT_FILE call. I performed file transfers with the UNIX Kermit and an earlier version of VMS KERMIT (6/83 or so) and there are no problems there . I guess this is a request to anyone out there using VMS KERMIT for help. It's not easy to unravel the MACRO code that BLISS generates so I'd appreciate any leads. Thanks in advance, Simon Rosenthal Cardiac Computer Center Massachusetts General Hospital, Boston MA Phone: (617)-726-8226 ARPA: lhasa!mghccc!simon@harvard.arpa USENET: harvard!lhasa!mghccc!simon ------------------------------ Date: Monday, 26 Nov 84 10:23:05 EST From: nbush (Nicholas Bush) @ sitvxb Subject: Re: [lhasa!mghccc!simon@harvard.ARPA: BUG IN VMS KERMIT] To: <SY.FDC@CU20B>, lhasa!mghccc!simon%harvard @ cu20b There is a problem in version 3.0.051 of VMS Kermit which shows up as RMS IFI errors when talking to some other Kermits. The problem is due to the buffer for packets being sent is too short if the maximum size packet is in use. A simple work around is to do a SET SEND PACKET_LENGTH command before doing a transfer. To fix the problem in the souce, the length of the buffer SND_MSG must be increased. This can be done in the BLISS source by increasing the value of MAX_MSG by 5. In the MACRO-32 source, the length in the .BLKB psuedo-op for SND_MSG can be increased by 5. This problem is fixed in the next version of VMS Kermit. - Nick ------------------------------ Date: 26 Nov 1984 0117-EST From: LCG.KERMIT To: EIBEN Subject: VMS Kermit (BLISS version) I have run into couple of bugs in the VMS kermit. Here they are: 1. Often I set host from one machine to another over decnet and run kermit on the latter machine because the latter has an internal modem. When I tell kermit to CONNECT to the line that has the modem, it puts out the message stating that it is connecting. But then instead of establishing and maintain- ing the connection, it immediately comes back with the message "returning back to vms kermit". If I attempt connecting again, kermit aborts with an opcode fault and the vms runtime message "NOMSG, message number 000000". Here's the sequence of DCL commands that illustrate the problem: $! Assume that I am logged on machine A, I do a set host to $! machine B. B has an internal modem. $ SET HOST B:: $ KERMIT kermit-32>connect txa7: [ connecting to b::txa7: type cntl-] C to return to kermit ] [ returning to b::tta0: ] kermit-32>connect txa7: KERMIT32-E-NOMSG message number 000000 <trace back shows up next> $! back to DCL. If I log on B directly, i.e, not through decnet, after I issue the connect command, everything works as it is supposed to: I am able to talk to the modem and tell it dial a specific number, and the rest. It is only when I am going through decnet, the problem arises. 2. During file transfers, if I tell vms kermit to send a file and the file description has some kind of an error in it, e.g,directory name that is too long, or the file has world read permission while the directory the file resides in does not have world read permissions, kermit aborts with a forced exit by vms. Try the send command like: $ kermit-32>send dra0:[guest.tomdickandharry]foo.bar "tomdickandharry" is too long for a subdirectory name. Kermit will catch the error in the directory name. Instead, it'll abort. 3. I sometimes log on one of our pdp's running ultrix-11 and use the unix kermit to tranfer things between vaxes running vms. When I log on ultrix and then log on a vax using ultrix kermit (i.e, kermit clb /dev/cua0 1200, where /dev/cua0 is an auto-dial modem), and then tell vms kermit to send a file, the file comes over fine, but something causes an RMS IFI (Invalid internal file identifier error) in the vms kermit. I can ignore the error when I tranfer one file at a time. The error however prevents me from using the wildcard option when sending files, e.g, "send *.pas", or sending a bunch of files as in "send prog.pas prog.dat prog.lis". The error occurs after vms kermit has sent over "prog.pas" which then inhibits kermit from sending over the remaining fils. The most recent version of unix kermit, and the one before it, both cause the error. However when I send a bunch of files from ultirx to vms, everything works fine. Thanks, Nancy Prohaska KS1 [Ed. - Bob McQueen of Stevens says: "Problems 1 and 2 should be fixed in the current field image of Kermit-32. Problem 3 is fixed and it is my understanding that you have a work around for it. We will work toward getting a Kermit-32 3.1 out which contains the fix to the RMS IFI problem and also has a TAKE command."] ------------------------------ Date: Tue, 20 Nov 84 11:20:10 CST From: Paul Milazzo <milazzo@rice.ARPA> Subject: PAD Parameters for Kermit? To: info-kermit@cu20b.ARPA Can anyone tell me the exact PAD (and ITI?) parameters necessary to make Kermit work over Telenet? I've had no luck at all with it. If it matters, I'm connecting to a UNIX host from a CP/M system, and have the latest Kermit for each. Thanks, Paul G. Milazzo <milazzo@rice.ARPA> Dept. of Computer Science Rice University, Houston, TX ------------------------------ Date: Tue, 20 Nov 84 13:20 EST From: "John C. Klensin" <Klensin@MIT-MULTICS.ARPA> Subject: Re: PAD Parameters for Kermit? To: Paul Milazzo <milazzo@RICE.ARPA> There are several combinations that appear to work under various circumstances, and some Telenet PADs have historically been more fussy than others, resulting in some confusion. Usually, if your host can tolerate it (UNIX can, I would think), you want to set Xon/Xoff to the PAD and in kermit. For the PAD, that is SET 5:1,12:1 in order to get both input and output flow control. The other little trick, which has nothing to do with PAD settings, is that Telenet does not get on well with the transmission of binary data, and seems to like parity=mark in many cases. For some reason, it often also accepts even, odd, and space parity, as long as you don't try using the high bit to pass information. This is the sort of situation that leads to LOTS of superstitious behavior. Good luck. ------------------------------ DATE: THURS, 15 NOV 1984 FROM: ATSBDN AT UOFT01 TO: SY.FDC AT CU20B SUBJECT: CMS KERMIT AND NON IBM CONTROLLERS Does anyone have any info on using CMS Kermit with a CCI controller that emulates a 2705, except that it runs the ASCII lines in full duplex? Also, how's the Yale IUP modifications coming along? For our system we really need the Yale interface. Thanks, Brian [Ed. - As reported here, a couple sites already have Kermit working through the Series 1, apparently using different techniques. We are looking into their approaches, and hope to have a version of CMS Kermit that does this at some point in the future. I don't see why the CCI controller would present any special problem, since full duplex operation (i.e. host doesn't echo) is just right for Kermit file transfer.] ------------------------------ Date: Wed 21 Nov 84 13:38:09-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: VersaCom To: Info-Kermit@CU20B.ARPA I've received a letter from Solution Software, which is selling a product called VersaCom that does VT100 terminal emulation on the IBM and Sanyo PC's, screen capture, and Kermit and Xmodem file transfer. They say they adapted the current Unix Kermit code, added 8th bit quoting, repeat counts, and keyword style command parsing, and they will submit the result back to us, but without the terminal emulation. Their current brochure gives credit to Columbia, mentions that other versions of Kermit are available, etc etc. Thanks to the many people who brought this product to my attention and who evidently brought me to Solution Software's attention. - Frank ------------------------------ Date: Wed 21 Nov 84 12:48:24-PST From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA> Subject: ITS Binary Files vs Kermit To: W8SDZ@SIMTEL20.ARPA I have a problem with uploading files. I use KERMIT and I know TOPS-20 KERMIT can read ITS binary files and when I use it with KERMIT on the IBM-PC the ITS header is stripped and the file converted to a uasable .LBR file, but I don't think KERMIT has a way of writing an ITS binary file. Why not use 8-bit format to store binary files on SIMTEL, which both KERMIT and TOPS-20 modem can write? Ted. [Ed. - There's a program in <KERMIT-TOOLS> on CU20B called ITS. It will create an ITS header. You can then append any 8-bit binary file to the resulting header to produce an ITS binary file, for instance @its ; (make the header if necessary) @append its.hdr,foo.com (to) foo.com.-1 The result will have the same bytesize as the original, but regardless what the bytesize is, programs that understand ITS binary format will do 8-bit-byte input from it. Alternatively, you can use the program 8COM at SIMTEL20, which apparently does about the same thing.] ------------------------------ Date: Thu 22 Nov 84 01:30:36-EST From: Mark Becker <Cent.Mbeck%MIT-OZ@MIT-MC.ARPA> Subject: Kermit for Burroughs XE-520 / B25 (BTOS op sys) wanted To: Info-Kermit@CU20B.ARPA Hello - Has anyone ported Kermit to a Burroughs XE-520 Megaframe or B25 workstation? Thanks in Advance - Mark Becker Cent.Mbeck%Mit-Oz@Mit-MC ------------------------------ Date: Wed 21 Nov 84 00:03:13-PST From: Jyh-Jye Yeh <YEH@SU-SIERRA.ARPA> Subject: MacKermit connect mode To: engel@HARVARD.ARPA, info-mac@SUMEX-AIM.ARPA I found what is wrong with MacKermit connect mode in dialing out at 1200 baud. I have to choose 9600 baud at first and then choose 1200 baud in the control options in order to link to Apple modem. If I don't point to 9600 baud and click it, but fix at 1200 baud, then MacKermit won't send out commands to the modem. This is not a major problem since I know how to get around with it already. The other problem is that "backspace" dose not seem to work neither when I try to dial out nor when I am talking to the host computer. Also, Emacs can not work via MacKermit because the mode line is at the top instead of the bottom J.J. Yeh yeh@su-sierra.arpa ------------------------------ Date: Fri 23 Nov 84 00:49:44-EST From: Michael Rubin <RUBIN@CUCS20> Subject: Mac Kermit initialization & other bugs To: engel@HARVARD.ARPA cc: sy.fdc@CU20B The reason MacKermit release 2 doesn't use the remembered setup parameters until after you call up the Control window is that the line config=0x4c0a; in main(), which sets default parameters, is AFTER the initial SetupControls() call which reads the remembered values. I've also noticed a pile of other apparent bugs, such as typos in the window size #define's which may explain some off-by-one errors in the terminal emulator. Are you working on a release 3 or should I make a go at it? --Mike Rubin <rubin@columbia-20> ------------------------------ Date: Mon, 26 Nov 84 16:51:13 EST From: engel@harvard.ARPA (Stephen Engel) To: RUBIN@COLUMBIA-20.ARPA, engel@HARVARD.ARPA Subject: Re: Mac Kermit initialization & other bugs Cc: sy.fdc@CU20B You can not imagine the relief with which I read your letter. I have been aware of the problem with configuration, and also another with sending out padding for a while, but have not had the time to correct them. Meanwhile unanswered mail and requests have been piling up, any university funding I might get for working on Mackermit has dissapeared, and my lif has been generally frantic. Please feel free to make any corrections you wish. I would appreciate being sent a list of the bugs and fixes. I am still willing to try to do it myself, but if you were to take it on, I would be very grateful. Steve ------------------------------ Date: Fri 23 Nov 84 20:44:34-EST From: Peter G. Trei <OC.TREI@CU20B.ARPA> Subject: Apple 2c design flaw. To: info-kermit@CU20B.ARPA A recent article in Creative Computing indicates that many of Apple 2c's have a serial port problem; do to a design fault, they transmit about 3% too slow. This is not a major problem at 300 baud, but at 1200 many modems will not work properly. (The Apple modem DOES work though). Apparently, if you have this problem, you can get the dealer to swap the motherboard for you, and future 2c's will have this problem fixed. Maybe this is why so many people are having trouble with Kermit on the 2c. Peter Trei oc.trei@cu20b.arpa ------------------------------ Date: 28 Nov 84 14:48:55 EST From: Eric <LAVITSKY@RU-BLUE.ARPA> Subject: Commodore 64 Kermit V1.1 on the way To: sy.fdc@CU20B.ARPA Well, it's finally here. I have in my posession a working version of Kermit and sources for the Commodore 64. I am working on putting together an initial release now (hopefully in a week). There are some small bugs and improvements I want to make first. Later releases will include major fixes/ improvements. This version is very limited in what it will do as it is a pretty direct translation of Apple V1.0 (or 1.1). The text transfer seems to be working flawlessly though! C-64 Kermit-65 Capabilities At A Glance: Local operation: Yes Remote operation: No Transfers text files: Yes Transfers binary files: No Wildcard send: No ^X/^Y interruption: No Filename collision avoidance: No Can time out: No 8th-bit prefixing: No Repeat count prefixing: No Alternate block checks: No Terminal emulation: Yes (VT52) Communication settings: Yes; local echo, parity, baud Transmit BREAK: Yes IBM communication: No Transaction logging: No Session logging (raw download): No Raw upload: No Act as server: No Talk to server: No Advanced commands for servers: No Local file management: Yes Handle file attributes: No Command/init files: No Printer control: No Please don't flood me with requests: the *only* way to get this will be after its' 'official' release... [Ed. - Note, there's also a Forth implementation of Kermit for the C64 on the way from the University of Vermont. It's either feast or famine...] ------------------------------ End of Info-Kermit Digest ************************* ------- 30-Nov-84 19:45:24-EST,7396;000000000000 Mail-From: SY.FDC created at 30-Nov-84 19:45:10 Date: Fri 30 Nov 84 19:45:09-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #40 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To:: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 30 Nov 1984 Volume 1 : Number 40 Today's Topics: New PDP-11 Kermit New Kermit for Tandem Computers New Kermit for the Apollo Workstation CP/M-80 Kermit for the Heath H8 Revision 3 of TI-PRO Support for MS-DOS Kermit PCDOS/MSDOS Kermit Suggestion, cont'd Victor 9000 Kermit? ---------------------------------------------------------------------- Date: Thurs, 29 Nov 84 From: ATSBDN at UOFT01.BITNET To: SY.FDC at CU20B.BITNET Subject: New PDP-11 Kermit This should be the last mail from uoft01, my 11/785 has jnet on it now and it works very nicely. Once you get the new routing tables, the node is uoft02 and user is BRIAN. Anyway, who's bringing what to decus? I sent you a tape yesterday that is current, so will you merge that in for decus or should I bring a tape? brian [Ed. - The tape was received and installed at Columbia, and the new PDP-11 files, as well as anything else that arrives before Dec 7 (including the other new Kermits announced below) will be on the Kermit tapes at DECUS in Anaheim, Dec 9-14, and all the latest Kermits will be submitted to the various DECUS SIGs, one way or another. Version 2.24 of PDP-11 Kermit for is now available for RSX-11/M/M+, RT-11, RSTS/E, P/OS, TSX+. This release supersedes version 2.22 from September 1984. New features include Pro-3xx P/OS support, Pro/RT11 support, error logging, repeat compression prefix, virtual overlays. The files are in KER:K11*.* on CU20B. There are many files; if you want to pick & choose, first look at KER:K11FIL.DOC (somewhat out of date, but mostly correct). You should also look at KER:K11INS.DOC, which describes the different implementations, system requirements, etc.] ------------------------------ Date: 30 Nov 84 20:10:25 EST From: Frank da Cruz <SY.FDC@CU20B> Subject: New Kermit for Tandem Computers To: Info-Kermit A Kermit server for the Tandem computer has been submitted by Charles J. Cantor Cantor Consulting 116 Dickerman Rd. Newton, MA 02161 It sends and receive ASCII files only, one at a time (no wildcards). It includes repeat counts and 8th-bit quoting. It's written in TAL, the Tandem implementation language. It's in KER:TANDEM.TAL. The documentation is at the top of the program. ------------------------------ Date: 30 Nov 1984 1850-EST From: Frank da Cruz <SY.FDC@CU20B> To: Info-Kermit Subject: New Kermit for the Apollo Workstation A new Kermit implementation for the Apollo workstation has been developed at Control Data Corporation and submitted by: Duane Jergens Magnetic Peripherals, Inc, 7801 Computer Ave. S. Minneapolis MN 55435 This implementation is written in Pascal; it supports local, remote, and server operation, it implements most of the commands from the protocol manual, and includes Cyber-722 terminal emulation. The files are in KER:APOLLO.PAS (source), KER:APOLLO.HLP (help file), and KER:APOTERM.PAS (terminal emulation). This version of Kermit is independent of the Apollo Fortran implementation by John Lee of RCA Laboratories, which remains available as KER:APOKERMIT.*. ------------------------------ Date: 30 Nov 1984 1900-EST From: John Mealing, Intecom Inc, Allen TX To: Info-Kermit Subject: CP/M-80 Kermit for the Heath H8 Here is a modification of CP/M Kermit to allow setting and display of baud rates, a bug fix in telnet, and an extension of the HELP to show GET (which works in this release, on the H8). Look for the new symbol "h8quad" (for the heath quad i/o board that it uses) in the conditionals. Note that the Heath H8 is NOT the same machine as the H89! The H89 code does not run 'as is' on the H8, and does NOT initialize the UART. Also there was a bug in the telnet section that is fixed here, though I expect that it has already been found and fixed by now - this is from the DECUS FALL 83 tape. The comments were stripped out of this file to make it small enough for my H8 to assemble, however, I have put the first section back in to make it easier for you to identify. Thanks for a nice product to use and work on. Major insertions are heavily commented, edit as needed. This modification done by John Mealing, InteCom Inc, 601 Intecom Dr., Allen, TX 75002 (214)797-9141, x-2493, 5 Nov 84. [Ed. - Based on CP/M-80 Kermit v3.5. The files are in KER:CPMH8.M80 and KER:CPMH8.HEX.] ------------------------------ Date: 30 Nov 1984 0034-EST From: Joe Smith, Colorado School of Mines Forwarded-By: B.Eiben LCG <EIBEN%DEC-MARLBORO@columbia.arpa> To: Info-Kermit@cu20b Subject: Revision 3 of TI-PRO Support for MS-DOS Kermit This version works with the TI internal modem and has built-in Tektronix 4010 terminal emulation. If anyone wants to add interrupt handling to MSXTIPRO.ASM, be my guest. I intend to add more to MSXTEK.ASM to turn it into an ESCape sequence processor general enough to handle HEATH/VT52, ANSI/VT100, and both TEK and ReGIS graphics. NOTE: You must edit MSCOMM.ASM to add PORT3 and PORT4 - See MSXTIPRO.BWR for details. Joe Smith CSM Computing Center 1500 Illinois Street Golden CO 80401 [Ed. - The files are KER:MSXTIPRO.ASM, .BOO, .BAT, .BWR, and KER:MSXTEK.ASM. use MSXTIPRO.BAT to assemble and link the program for the TI Pro. MSTIPRO.EXE is in KB:.] ------------------------------ Date: Thu, 29 Nov 84 23:57 EST From: Frankston.SoftArts@MIT-MULTICS.ARPA Subject: Re: PCDOS/MSDOS Kermit suggestion To: Daphne Tzoar <Sy.Daphne@CU20B.ARPA>, INFO-Kermit@CU20B.ARPA [This was a suggestion in V1 #39 for using the BIOS whenever it was feasible]. Since I generally run at much over 1200, the ability to use the BIOS is quite limited. I only meant to suggest that for the 8 supported baud rates, setting speeds using the BIOS was more robust than going to the chip. Admittedly, this doesn't go very far in solving the problem with the 8251. A related problem with the 8251 and the BIOS is the inability to read out the current baud rate. ------------------------------ Date: 29 Nov 84 10:10:25 EST From: Gadi <FRIEDMAN@RU-BLUE.ARPA> Subject: Victor 9000 kermit? To: info-kermit@CU20B.ARPA We recently got a Victor 9000 donated to us in the MICROLAB, The only software it came with was MS-DOS 1.1 and CPM/86. Since the diskdrives are not compatible with the IBM-PC (they hold over 600k each), is there any way I can get a version of vickkermit to a victor format disk? -Gadi Friedman@Ru-Blue harvard!topaz \ friedman allegra!ru-blue / ------------------------------ End of Info-Kermit Digest ************************* ------- 4-Dec-84 18:29:18-EST,9352;000000000000 Mail-From: SY.FDC created at 4-Dec-84 18:27:06 Date: Tue 4 Dec 84 18:27:06-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #41 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 4 Dec 1984 Volume 1 : Number 41 Departments: ANNOUNCEMENTS - Kermit for the ICL/Three Rivers PERQ Kermit for the Pascal Microengine CP/M-86 Kermit Version 2.9 CP/M-86 Kermit for Tektronix 4170 MISCELLANY - How to Bootstrap Kermit for the Victor 9000 MS-DOS Kermit RUN Command ---------------------------------------------------------------------- Date: Tue 4 Dec 84 12:44:00-EST From: Peter Thew, Computer Centre, RMC Duntroon, Australia Subject: Kermit for the ICL/Three Rivers PERQ To: Info-Kermit The Pascal version of Kermit for RT-11 systems, written at the University of Toronto, has been heavily modified for the ICL/Three Rivers PERQ. The command parsing has been improved by using the PERQ's parsing routines which allow pop-up menus and command files. Binary file transfer has been included (but it is rather simple and needs to be improved). Some features that are to be added in the future are: . Server commands . VT100 emulation during CONNECTS. . Pop-up menus for all commands (eg. SET --> SPEED --> baud-rates) . General code clean up, including faster disk I/O using FileSystem routines. Peter Thew Computer Centre Australian Defence Force Academy ACT 2600 Australia [Ed. - The files are in KER:PQ*.* on CU20B, available via anonymous FTP.] ------------------------------ Date: 27 Nov 84 21:22:31 PST (Tue) To: SY.FDC@CU20B Subject: Pascal Microengine kermit implementation From: "Tim Shimeall" <tim%uci-icsd@columbia.arpa> I have adapted the UCTERAK version of kermit to run on a Western Digital Pascal microengine. It was not a difficult translation (your protocol designers are to be complemented on its clarity) and the Microengine is not a common system. To get everything working properly I had to make rather widespread (but not extensive) changes to the Cornell Terak version, such that it would be difficult to tie it down to just a few files (every file in the program has been changed at least slightly). In the process of converting over, I spotted a few bugs in Terak Kermit. The most serious is that it does *no* timed waiting for packets; it just checks 10000 times to see if SOH has arrived. From a colleague here, I understand that UCIBM-PC kermit has problems as well. I have corrected this bug in the transported version (can I suggest calling it UCMICRO?) The following is the list of changes I've made in UCTERAK kermit to make UCMICRO kermit: - Added device declarations copied from Microengine hardware documentation - Replaced external assembly language routines with Pascal versions - Modified debug messages to be label values printed - Changed format of packetwrite display to show header fields - Implemented machine-dependent packet timeout - Added debug packetwrites in recsw - Added wrap-around debug info region - Added legality check in showparms - Removed lf elimination check in echo procedure - Unitwrite calls replaced by calls to device driving routines - Most uses of char_int_rec replaced by ord and chr - Removed queue (no interrupts) - Used sets for integer ops to getaround Microengine bug - Changed parser from a unit to a segment procedure to allow swapping - Eliminated "sendbrk" procedure (couldn't determine its use) Tim [Ed. - The program is in KER:UCMICRO.PAS and KER:UCMICRO.DOC on CU20B.] ------------------------------ Date: Sun 2 Dec 84 15:49:29-PST From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: CP/M-86 Kermit Version 2.9 To: cc.fdc@CU20B.ARPA I've been making changes off and on to 86kermit, but the next month or two looks slack so I'll give you the current version for testing and possible release. The files are in my account as usual with the source in 86KER*.* and the hex and binary in APCKERMIT.*. The specific features that have been implemented in version 2.9 are: o LOCAL DIRECTORY command now computes file sizes correctly for all files. The size given is the actual allocation on disk, and not the logical size (which might differ for non-sequential files). o LOCAL TYPE command has been implemented to display (text) files on the screen. A wildcard filespec is accepted and files displayed alphabetically. The display is paged in Unix fashion with --more-- displayed on the last line. Typein options at that point can be obtained by hitting a '?'. o Wildcard SENDs now send files in alphabetical order by name, and accept an optional initial filename in the command line to allow transmission of partial groups in the manner of TOPS-20 Kermit. o Problems with use under Concurrent CP/M on the APC have been fixed. In particular, a KERMIT.INI file is no longer required, the SET DEFAULT-DISK command works correctly, and a process dispatch is performed each time a call to the serial port status routine returns negative, vastly improving the response of other jobs. There is still no provision for mutual exclusion on the serial port. [Ed. - The files are in: KER:86*.* source, documentation. KER:APCKERMIT.H86 hex for NEC APC KB:APCKERMIT.CMD 8-bit binary for APC KER:RBKERMIT.H86 hex for DEC Rainbow KB:RBKERMIT.CMD 8-bit binary for Rainbow The old files will be set aside for a while in case problems appear. Also see next message...] ------------------------------ Date: Tue 4 Dec 84 18:00:00 From: Frank da Cruz <SY.FDC@CU20B> Subject: CP/M-86 Kermit for Tektronix 4170 To: Info-Kermit CP/M-86 Kermit 2.9 also includes support for the Tektronix 4170. The support comes from a system-dependent module, like the ones for the Rainbow and the APC, contributed by Robert Raymond, TransEra Corporation, Provo, Utah. He says it works just like the APC and Rainbow versions. His module compiled and linked with the other modules with no apparent problems. The Tektronix 4170 i/o module is in KER:86KERIO.TX4. The hex is in KER:TX4KERMIT.H86 and the binary in KB:TX4KERMIT.CMD. ------------------------------ Date: Sat 1 Dec 84 12:51:06-EST From: Peter D. Junger <JUNGER@CWRU20> Subject: How to Bootstrap Kermit for the Victor 9000 To: info-kermit@CU20B In response to the recent request for a way to get the Victor 9000 Kermit onto the Victor without having a Kermit already on that machine, I can explain what we did. We used Kermit on another machine (I forget whether it was a North Star Horizon or an IBM PC) which did run Kermit to download the Victor Kermit source code. We then used Crosstalk to transfer the code to the Victor and then assembled it on the Victor. As I recall it took more than 128 K of memory to get the program to assemble. For the assembler we used the one--I assume that its Microsoft--that comes with the Victor Programmer's Toolkit (which Victor didn't supply without cost). Crosstalk isn't magic, as long as there is some file transfer program which exists on the two micros. If there is no communications program on the Victor in question--as I suspect may be the case--I can send a floppy disk with the version which works for us to the person who needs it. (I can't look at his message while I am typing this.) I am very disorganized, so the best way to reach me is over CCNet: JUNGER@CWRU20. I do not believe that I can be reached directly or indirectly from ARPAnet, so the sender may have to request you to relay it. I hope that this is of some help. I will not quarantee that our copy works very well, we hardly ever use it, since I am the only one here that makes much use of Kermit and I do not use the Victor as my main machine. Peter Junger ------------------------------ Date: Mon, 3 Dec 84 15:04:08 cst From: allegra!noao!utastro!nather@Berkeley (Ed Nather) To: carina!allegra!ucbvax!info-kermit@Berkeley Subject: MS-DOS Kermit RUN Command The "run" command in mskermit is very useful in feeling around for a file under MS-DOS 2.0, and for doing a few other things. It has a couple of peculiarities, though: it requires the full name, with extension, for the executable file; usual ms-dos procedure executes a .com, .exe or .bat file if the extension is left off, and most users are used to it. It took me a long time to guess what Kermit wanted. By the way, it may not be obvious to some users that Kermit can't handle a .bat file at all; the usual symptom is a hang that requires a power-off reset to get the computer's attention again. A warning to this effect in the next version of the manual might save someone a headache. ------------------------------ End of Info-Kermit Digest ************************* ------- 6-Dec-84 13:33:59-EST,8733;000000000001 Mail-From: SY.FDC created at 6-Dec-84 13:33:33 Date: Thu 6 Dec 84 13:33:32-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #42, Special CP/M-80 Edition To: Info-Kermit-Members@CU20B.ARPA, Info-CPM@AMSAA.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Thu, 6 Dec 1984 Volume 1 : Number 42 Special Issue: Announcement of CP/M-80 Kermit Version 4 ---------------------------------------------------------------------- Date: Wed 5 Dec 84 15:28:40-EST From: Charles Carvalho <CHARLES@ACC.ARPA> Subject: New Release of Kermit for CP/M-80 To: info-kermit@CU20B.ARPA This is to announce version 4.03 of CP/M-80 Kermit. This is a "beta test" of a major new release, and will not replace the current version (3.9A), until it has proven to be stable. The major change is the decomposition of the program into a collection of modules, a`la MDMxxx, with a new procedure that allows combining custom "configuration overlays" with the system-independent portions of the program. This allows fixes or new features to be added to the protocol without requiring reassembly of the program for each system supported, and conversely, allows support for new systems to be added (or old ones fixed) without reassembly for the other systems. An added benefit of the breakup of the old monolithic source file into smaller files is managability on systems with limited disk storage -- at 176K, the version 3.9A source file exceeded the capacity of many common floppies. The modular decomposition is not quite complete, however, since the system-dependent code for all systems is still combined in one module, with assembly time conditionals for each system. A future release will break this module, CP4SYS.ASM, into separate, unconditionalized modules for each system. Here are some of the new features of version 4: * Support for New systems: Support has been added for several new systems or configurations: Apple II, Z80 Softcard, 6551 ACIA BigBoard II CPT-85xx word processer Digicomp Delphi 100 Morrow Micro Decision I Support that was recently added to version 3 of CP/M Kermit for systems like the Heath H8 and Compupro Interfacer 3/4 is not included; volunteers are needed to do the conversions. * Terminal support: For micros without integral consoles, one of several terminals may be chosen (among them VT100, VT52, and ADM-3A), as well as the generic "CRT". * Debugging aids: SET DEBUG ON will add two fields to the SEND/RECEIVE display, labelled "Spack" and "Rpack". These display the last packet sent or received. Of course, this slows down the transfer, especially if the console is an external terminal. SET DEBUG OFF removes these fields. The VERSION command displays the name, edit number, and edit date of several of the modules that make up Kermit. * TAC support: ARPAnet TACs (and probably some other communication devices like modems, multiplexers, port contention units) use a printing character (normally "@") as an intercept character, to allow commands to be issued to the TAC. In order to send this character to the host, it must be typed twice. The command "SET TAC CHARACTER" to Kermit enables the TACtrap and asks the user to specify the TAC intercept character. This character will be automatically doubled when it appears in Kermit protocol messages (sent by the SEND or RECEIVE commands) or when it appears in a file being sent with the TRANSMIT command. It is not automatically doubled when typed by the user in CONNECT mode. "SET TAC ON" enables the TACtrap but does not change the TAC intercept character, which is initially "@". "SET TAC OFF" disables the TACtrap. * File buffering: Previous versions of Kermit-80 buffered only one sector (128 bytes) at a time during file transfer operations. This version buffers 16Kbytes at a time, reducing the number of times the floppy drive must be spun up and down, and increasing the effective throughput of the link. If the disk transfer rate is too slow, howver, the remote Kermit may time out and retransmit packets. This will show up on the screen in the "Retries:" field; if this occurs after disk activity, you may want to increase the timeout value on the remote Kermit, or reassemble Kermit with a smaller value for MAXSEC (in CP4SYS.ASM). This buffer is also used by the TRANSMIT command; the log file enabled by the LOG command is still written a sector at a time. * Baud Rate Setting: The format of the SET BAUD-RATE command has been changed for several systems. Rather than requesting the user to enter a letter for the speed, the desired baud rate is supplied on the command line (e.g. "SET BAUD 1200"). A list of supported baud rates may be obtained by typing "SET BAUD ?". If Kermit cannot change the baud rate for your system, it will reply "(not implemented)". * Generic CP/M 2.2 Support: The "generic" Kermit-80 for CP/M 2.2 (assembly switch GENER) supports six port selections, to improve the chances of finding one that works. Kermit reads from PTR: and writes to PTP: by default; if this does not work, try "SET PORT TTY". The following table lists the CP/M devices used for each option: SET PORT xxx input from output to CRT CRT: CRT: PTR PTR: PTP: TTY TTY: TTY: UC1 UC1: UC1: UR1 UR1: UP1: UR2 UR2: UP2: In all cases, the console (CON:) and list (LST:) devices used are those selected when Kermit is started. * How to Get It: The files are in KER:CP4*.* on CU20B, available via anonymous FTP. CU20B is Internet host [192.5.43.128]. The source files have the extension (file type) .ASM, the hex files .HEX. There is also a new Kermit User Guide chapter in KER:CP4KER.DOC and .MSS (Scribe text formatter source). A list of known bugs and deficiencies is in KER:CP4KER.BWR (this file will be updated as reports come in). The edit history and internals are documented in KER:CP4KER.UPD. Note that a new, somewhat more complicated, installation procedure is required. Two hex files -- the system-dependent part, and the "configuration overlay" -- must be combined and then loaded. Detailed instructions are given in KER:CP4KER.DOC. The program may be built with the public-domain assembler and linker, LASM and MLOAD, or on the DEC-10 or DEC-20 with Bruce Tanner's MAC80 and LINK80. Unfortunately, it can no longer be built with ASM and LOAD because multiple files are used (this is the price we pay for modularity). LASM, MLOAD, MAC80, and LINK80 are all in the <KERMIT-TOOLS> area on CU20B, for those who need them. <KERMIT-TOOLS> can be referred to as KT:, as in KT:MLOAD.HEX. The following systems are supported: Symbol Filename System ------ -------- ------ AP6551 CP4APL Apple II, Z80 Softcard, 6551 ACIA in serial interface APMMDM CP4APM Apple II, Z80 Softcard, Micromodem II in slot 2 BBII CP4BB2 BigBoard II (terminal required) BRAIN CP4BRN Intertec SuperBrain. CPM3 CP4CP3 "generic": CP/M 3.0 (CP/M Plus) systems (terminal req'd) CPT85XX CP4CPT CPT-85xx word processors with CompuPak CP/M DELPHI CP4DEL Digicomp Delphi 100 (terminal required) DMII CP4DM2 DECmate II with CP/M option GENER CP4GEN "generic": CPM 2.2 systems with IOBYTE (terminal req'd) HEATH CP4H89 Heath/Zenith H89. KPII CP4KPR Kaypro-II (and 4; probably supports all Kaypro systems) MDI CP4MDI Morrow Decision I (terminal required) MIKKO CP4MIK MikroMikko MMDI CP4UDI Morrow Micro Decision I (terminal required) OSBRN1 CP4OSB Osborne 1 OSI CP4OSI Ohio Scientific ROBIN CP4ROB DEC VT180 TELCON CP4TEL TELCON Zorba portable TRS80LB CP4TLB TRS-80 model II with Lifeboat 2.25C CP/M Display TRS80PT CP4TPT TRS-80 model II with Pickles + Trout CP/M Display VECTOR CP4VEC Vector Graphics. Z100 CP4Z00 Z-100 under CP/M-85 The "symbol" is used in CP4SYS.ASM for assembly purposes. The filename shows where to find the .HEX file in KER: on CU20B, e.g. KER:CP4Z00.HEX. Please try out the new version and report any bugs to Info-Kermit@CU20B. Also, please feel free to add support to CP4SYS.ASM for systems that are not supported, and to make enhancements to those that are; for instance, most systems are still not able to send a 250ms BREAK signal. Version 3.9A of CP/M-80 Kermit continues to be available as KER:CPM*.* on CU20B, but will eventually be phased out. ------------------------------ End of Info-Kermit Digest ************************* ------- 7-Dec-84 17:13:33-EST,7918;000000000001 Mail-From: SY.FDC created at 7-Dec-84 17:11:46 Date: Fri 7 Dec 84 17:11:45-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #43, Special MS/PC-DOS Edition To: Info-Kermit-Members@CU20B.ARPA, Info-IBMPC@USC-ISIB.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 7 Dec 1984 Volume 1 : Number 43 Special Issue: Announcement of MS/PC-DOS Kermit Version 2.27 ---------------------------------------------------------------------- This is to announce version 2.27 of MS-DOS Kermit. This release is primarily intended to fix some of the problems that surfaced in version 2.26. Some minor new functionality has also been added. The work was done by Daphne Tzoar and Jeff Damens of the Columbia University Center for Computing Activities -- some original, and some based on code contributed from other sites, such as the University of Maryland. MS-DOS Kermit has been implemented for the following MS/PC-DOS systems: . IBM PC and PC/XT and compatibles (Compaq, Z150, ITT Xtra, etc) . IBM PC/AT (new) . IBM PCjr (serial port only) . DEC Rainbow 100 and 100+ . Heath/Zenith 100 . HP-150 . Wang PC . NEC APC (from Ron Blanford, U of Wash & Ian Gibbons, U of Hawaii) . TI Professional (from Joe Smith CSM, includes Tek 4010 emultation) and there is a "generic MS-DOS" version for systems not explicitly supported (the generic version runs slower and doesn't take advantage of any machine-specific features). New Features of Version 2.27 ---------------------------- . SET PORT DEVICE and SET PORT FILE-HANDLE commands to allow generic DOS Kermit more flexibility in finding the communication port on new systems. . DEC Rainbow now has SET BAUD command. . SET DESTINATION SCREEN command - directs incoming files to the screen rather than to the disk (for displaying files from those systems whose Kermits don't support the REMOTE TYPE command). . Escape character command <esc-char>P to push to DOS during CONNECT. . Includes the enhanced NEC APC support from Ian Gibbons, U of Hawaii -- full key scan-code redefinition, auto-determination of color/monochrome for CRT formatting, direct video access for faster help menus, and a scroll/noscroll key that sends ^S and ^Q alternately. Problems Fixed in Version 2.27 ------------------------------ Version 2.27 attempts to fix the following problems from version 2.26 (thanks to those who reported them, and especially to those who also sent fixes): * Program Design: Some code that proved to be system-dependent (like structure definitions that assumed only two communication ports) has been moved into the system-dependent sections. LEA's have been changed to MOV ..,OFFSET or to LEA ..,WORD PTR in msfile, so that program can be built by non-IBM assemblers. * File Transfer: Incoming packets are now discarded if they're the same type as the packet just sent, in case some hardware in the communication path is echoing them back. SET DEST PRINTER now uses PRN device, not LPT1. An extraneous partial final buffer should no longer be printed printed during direct transfers to printer ('SET DEST PRINTER'). Use of Return key to retransmit current packet is now documented in the file transfer display. SET EOF CTRLZ has been fixed to work as described in the manual. New precautions have been taken to guard against packet buffer overrun. Buffer overruns caused various symptoms in v2.26 -- CRC's would stop working, memory dumps would appear on screen, etc. Open files are now closed if a fatal error occurs during file transfer and 'set incomplete keep' is in effect. Empty responses to REMOTE HOST commands no longer crash the program. Some early copies of 2.26 displayed the number of Kbytes transferred incorrectly during file transfer; this was fixed in later copies, and is also fixed in 2.27. * Terminal Emulation: In IBM H19 emulation, tabs are no longer destructive. IBM H19 emulation problems with Insert/Delete bottom line of screen are fixed. On IBM, H19 cursor save/restore function is now supported. On IBM, carriage returns in inverse video mode no longer scroll inverse lines onto screen (Unix MORE users will appreciate this). On IBM, Remote/Local Echo status line is now correctly displayed. On IBM, the keypad "+" key may now be redefined using SET KEY (this key normally has the undocumented function of toggling the mode line during CONNECT). On the Rainbow, various problems have been fixed with screen scrolling: . Character attributes are now displayed correctly in previous screens (except for double height/width attributes) . Prev/Next Screen no longer overshoots. . Lines are no longer lost from prev screen when autowrap is in effect. . 132 column display works with Prev/Next screen. . VT52 emulation mode entry/exit no longer hangs the program. On the Rainbow and the IBM PC, BREAK now should last exactly 275 msec. The Rainbow now resists attempts to send ESC-8 and ESC-c to the firmware, since these codes will crash the machine (firmware bugs). * Command Parser: The current directory is now searched for files before the PATH, in the same way DOS searches for files. 'Set key scan <space><space><return>' now works properly. SHOW MACRO should have been SHOW MACROS; now it is. Table overflow for 'set key' definitions is now detected. Undetected overflow had unpredictable (but always bad) consequences. Trailing comments are now illegal in commands typed at the keyboard; they still may be used in command files. This allows the ";" character to be used in commands like "get foo.bar;2" or "remote host cd ; pwd". The eighth bit is stripped from incoming characters; previously, entering characters from the keyboard with the high-order bit on would crash Kermit. * PC/AT support: Some minor problems introduced by DOS 3.0 when the PC/AT appeared have been fixed, and Kermit 2.27 should operate correctly on the AT. Documentation: ------------- The manual has not yet been updated. Many of the changes were made in order to make the program conform to the manual. An updated manual will follow shortly. Future Versions: --------------- Future plans for MS-DOS Kermit include: . Removal of DOS 1.x support. Dynamic memory allocation features of DOS 2.0 and above would allow the program to be much smaller on disk. . Addition of a login script facility, similar to the one recently added to DEC-20 Kermit. How To Get Version 2.27: ----------------------- Version 2.27 of MS-DOS Kermit is available via anonymous FTP from host CU20B, Internet host number [192.5.43.128]. It is in the files KER:MS*.*. The executable programs are encoded in ASCII ".BOO" format -- those who don't know what that means should get the MS-DOS Kermit chapter of the Kermit User Guide (available as KER:MSKERMIT.DOC) and read about bootstrapping MS-DOS Kermit. Those who may have gone through this before are exhorted to obtain the current copy of KER:MSPCTRAN.BAS, the .BOO file decoder, in which a serious bug was recently fixed. The sources are in KER:MS*.ASM and KER:MS*.H. KER:MSBUILD.HLP tells how to build the program. Binaries, for those who can transfer them directly, are in KB:MS*.EXE. This new release will be available at DECUS in Anaheim, Dec 10-14, and should appear on the resulting DECUS SIG tapes. It will also be submitted to PC-SIG for distribution on floppy disk. And it will appear for BITNET distribution in the near future. ------------------------------ End of Info-Kermit Digest ************************* ------- 18-Dec-84 10:41:18-EST,15358;000000000000 Mail-From: SY.FDC created at 18-Dec-84 10:40:49 Date: Tue 18 Dec 84 10:40:49-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #44 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Tue, 18 Dec 1984 Volume 1 : Number 44 Departments: ANNOUNCEMENTS - Kermit for the Commodore 64 Written in Assembler Kermit for the Commodore 64 in FORTH Corrected Copies of MS-DOS Kermit 2.27 for Z100 and NEC APC CP/M-80 KERMIT - CP/M Kermit v4: CP/M 3 Support and H89 CP/M Apple Kermit v4.03 Kaypro Version of Kermit 4.03 Kermit-80 Status MISCELLANY - Columbia Kermit with Port 3? Multics Kermit and X.25 Connections Additional Heuristics for Kermit Kermit vs 4705? ---------------------------------------------------------------------- Date: 14 Dec 84 00:41:50 EST From: Eric <LAVITSKY@RUTGERS.ARPA> Subject: Kermit for the Commodore 64 Written in Assembler To: sy.fdc@CU20B.ARPA Here is Kermit for the Commodore 64, written in CROSS (almost exactly like the Apple version). I have bootstrap programs, but the BASIC version for the C64 end doesn't yet do what it's supposed to. The bootstrap is supposed to work just like the Apple version; since it isn't quite working yet, one must have Kermit or Modem to get Kermit over to his/her machine. I hope to have this problem corrected soon. The files are on CU20B, available via anonymous FTP: KER:C64DXL.BAS ; A BASIC version of C64DXL KER:C64DXL.HEX ; The hex file for C64DXL (nulls removed!) KER:C64DXL.M65 ; The source for the disk hex loader KER:C64KER.DOC ; Incomplete Documentation KER:C64KER.HEX ; The Hex file for C64KER (with nulls removed!) KER:C64KER.INS ; One page installation instructions KER:C64KER.M65 ; The source, however mixed up it may be KER:C64KER.MSG ; Proposals for improvements (like an RFC) KER:C64KER.MSS ; The Scribe source for C64KER.DOC I am calling this release of Kermit a Beta-Test for several reasons. This version was slapped together from the sources I received from Dave Dermott and my improvements, updates from the latest Apple version. I wanted to get this out ASAP. As a result, there are several untested features, unimplemented features or some features which may be better if implemented in a different way. See C64KER.MSG for a list of these. ARPA: Lavitsky@RUTGERS UUCP: ...harpo!whuxlb!ru-blue!lavitsky or ...allegra!ru-green!ru-topaz!eric SNAIL: CPO 2765, CN 700 New Brunswick, NJ 08903 or 14 Rock Ave. Swampscott, MA 01902 Phone: (201) 932 - 2443 (RUTGERS: Operators' Cubbyhole: leave a message) (617) 593 - 4841 (Real Home: leave a message) (201) 745 - 8143 (Campus Home during school semesters only) [Ed. - CROSS is a cross assembler that runs only on the DEC-10 and DEC-20. For bootstrapping, I'd suggest that the MS-DOS method be adapted -- run MSMKBOO on the binary to produce a 4-for-3 encoded .BOO file (with zero-compression), use MSBOOT.FOR to send the .BOO file, and adapt MSPCBOOT.BAS to run on the C64 to receive the file. These days, every Kermit seems to come with its own unique bootstrapping procedure; since most of them do the same thing, let's start standardizing. Meanwhile, send comments and suggestions about this new Kermit implementation to Eric and to Info-Kermit.] ------------------------------ Date: Wed 12 Dec 84 15:46:38-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit for the Commodore-64 in FORTH To: Info-Kermit@CU20B.ARPA Announcing Kermit for the Commodore 64 with Commodore 1541 disk drive, from Robert W. Detenbeck, University of Vermont. The program was written to be used with version A of C64-FORTH, sold by Performance Micro Products, 770 Dedham Street-S2, Canton, MA 02021. Slight modifications would be required to use the screens with the newer version B, a pure FORTH-79 standard. The files (slightly modified for distribution, as indicated) are available on CU20B via anonymous FTP: KB:C644TH.PRG -- core-image 8-bit binary "PRG" file. KER:C644TH.HEX -- hex (nibble) encoding of C644TH.PRG, with CRLF inserted after every 78 characters. KER:C644TH.DOC -- brief explanation of the program KER:C64495.SCR -- help screen SCR95, with CRLF inserted after every 40 chars. KER:C64496.SCR -- help screen SCR96, ditto KER:C64497.SCR -- help screen SCR97, ditto KER:C64498.SCR -- help screen SCR98, ditto Source not included. The author says "I would be glad to provide the FORTH source screens to anyone who could use them, but it is awkward to transmit 90 Kbytes on a 300-baud Kermit, so a mailed disk might be a better answer to the probably small number of requests." Send a self-addressed mailer to the author, Prof. Robert W. Detenbeck, Department of Physics, University of Vermont, Burlington, VT 05405. We'll also try to scare up the source ourselves. ------------------------------ Date: Tue 18 Dec 84 10:13:56-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Corrected Copies of MS-DOS Kermit 2.27 for Z100 and NEC APC To: Info-Kermit@CU20B.ARPA A forthcoming issue will be devoted to the reaction to MS-DOS Kermit v2.27. In the meantime, it should be noted that serious problems were discovered with the Heath/Zenith-100 version, and it has been replaced. Minor problems were also discovered with the NEC APC version and it too has been replaced. The new files are in KB:MSZ100.EXE, KER:MSZ100.BOO, KER:MSXZ100.ASM -- Z100 KB:MSAPC.EXE, KER:MSAPC.BOO, KER:MSXAPC.ASM -- NEC APC on CU20B, available via anonymous FTP. ------------------------------ Date: Tue, 11 Dec 84 23:51:18 CST From: Paul Milazzo <milazzo@rice.ARPA> Subject: CP/M Kermit v4: CP/M 3 support and H89 To: Charles Carvalho <CHARLES@ACC.ARPA>, INFO-KERMIT@CU20B.ARPA One of the many nice things about the beta-test version of CP/M Kermit is that it contains code that correctly calculates disk free space under CP/M 3. Unfortunately, this code is only assembled in when you select the "cpm3" flag, which results in a generic (pronounced "slow") CP/M 3 Kermit, as if CP/M 3 were mutually exclusive with the supported system types. Since I have an H89 running CP/M 3, I wanted to take advantage of the H89-specific support and still be able to tell how much free space there is on my disks. Rather than double the number of supported system configuration flags just for this one function, I chose to save the BDOS file system version (from BDOS function 12) at startup, check it whenever sysspc is called, and branch to the correct algorithm. That way, a configuration for hardware which supports both CP/M 2 and 3 will work in either case. If this approach is seen as a Good Thing, I'll be happy to contribute it to the distribution. If not, what should I have done instead? I've also added some additional H89 support (speed selection, sending breaks, etc.), and fixed a minor bug in the delay subroutine used by "kpii", "bbII", and "cpt85xx". It ignores its argument. Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX ARPA: milazzo@rice.ARPA UUCP: {cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo [Ed. - When any of this finds its way into the distributed version, a notice will be posted.] ------------------------------ Date: 13-Dec-84 03:13:51-EST From: decvax!ncoast!stuart@Berkeley (Stuart Freedman,C.W.R.U.,368-8860) To: .include.fdc@Berkeley Subject: CP/M Apple Kermit v4.03 I just put together this version (snarfed it over and ddt-ed it) and find it great (esp. the greater time between disk accesses). The only problem I have discovered so far is that when I do a ctrl-] D to disconnect (I am using the Micromodem II version), the system just hangs. Also, is there any chance of making the logging feature better (i.e. enlarging the buffer size and allowing more time for ^S-^Q so that no characters would be lost)? Thank you very much for putting Kermit together and coordinating the ongoing efforts to improve it. Stuart Freedman decvax!cwruecmp!ncoast!stuart Case Western Reserve University or ccc%Case.CSNET@CSNet-Relay.ARPA ------------------------------ Date: 14 Dec 84 13:38:49 EST From: Dave Zubrow <DZ05@CMU-CC-TD> To: info-kermit@CU20B Subject: Kaypro Version of Kermit 4.03 Dear Kermit: I have been trying to use version 4.03 and can't get it to work with files larger than the 16K buffer. After it writes the buffer to disk I get the message "?unable to receive data". I've tried various settings for the send and receive timeout parms on the Dec-20 but they were not successful in eliminating the problem. Could it be that the 16K buffer is not being flushed after the disk write? Do you have any remedies or suggestions? Thanks, Dave Zubrow ------------------------------ Date: 17 Dec 1984 12:59 PST From: Charles Carvalho <CHARLES@ACC> Subject: Kermit-80 status To: SY.FDC@CU20B Frank and Bernie - I've got the new H89 stuff here, and will merge it with the FILCOM for the Northstar CP/M version. I'm curious about the bug Hal found in the receive packet routine (but not surprized). I thunk about the disk buffering problems this weekend, and am puzzled why increasing the send/receive timeouts at the other end didn't fix the problem. (It worked here, between a Kaypro and VMS Kermit; the Kaypro takes about 15 seconds to transfer 16Kbytes to disk, so 20 seconds ought to be adequate. I used 30 seconds). Anyway, a possible solution is to check the line for more data after receiving the packet terminator, and if a control-A is seen, forget the received packet and accumulate the next one. (Doesn't the MSDOS Kermit do something like this?) This should work for any number of complete buffered messages, as well as the final partial message, if any, for a micro such as the Robin that flow-controls if nobody is taking the received data. What I'm not sure about is what happens if the middle of a message is dropped (for instance, a SIO chip will keep the first two and the last byte of a message that comes in while nobody is looking). I guess we'd usually recover after a timeout. The problem with the Apple Micromodem configuration is that control-] D no longer terminates connect mode, it just hangs up the phone (oops...) For now, following control-] D with control-] C should do the right thing. /Charles ------------------------------ Date: 14 Dec 1984 12:34:56-EST From: augeri%rpi.csnet@csnet-relay.arpa To: info-kermit@cu20b.ARPA, csnet-relay%rpi.csnet@csnet-relay.arpa Subject: Columbia Kermit with Port 3? Does anybody has a version of kermit that runs on the Columbia using COM3 instead of COM1 or COM2? It seems to me that all that needs changing are the port addresses in MSXIBM.ASM. -- Ivan Auger -- (augeri@rpi for csnet) (augeri%rpi@csnet-relay for arpanet) [Ed. -- Look at MSXTIPRO.ASM for an example of how to increase the number of ports.] ------------------------------ Date: Tue, 11 Dec 84 02:20 CST From: Jerry Bakin <Bakin@HI-MULTICS.ARPA> Subject: Multics Kermit and X.25 connections To: info-kermit@COLUMBIA-20.ARPA I have noticed some peculiar behavior in Multics Kermit; I was hoping to pass this on to the maintainers of Multics Kermit (I know of at least four versions!) and through Info-Kermit. I have been connecting to Multics through a VAX using the DEC PSI program which creates an X.29 virtual terminal over an X.25 circuit. I notice that if the first thing I try to do in Kermit is "receive" a file, I get an error complaining about setting "improper modes" for this device. If I first try a "send" then things work ok. Indeed, if I first send, and then try to receive, the receive works as well. Could it be that you are setting modes differently for send then receive, and trying to set modes for receive that do not really need setting? Jerry Bakin. <Bakin at HI-Multics> (818) 915-9874 [Ed. - This message was passed along to the author of MULTICS Kermit.] ------------------------------ Date: Sun 9 Dec 84 07:59:30-PST From: Bob Larson <BLARSON%ECLD@ECLA> Subject: Re: Additional Heuristics for kermit To: info-kermit@CU20B.ARPA This is in response to Frank da Cruz's response to my message of Oct 17, both of which are published in info-kermit V1 #33. Since we agreed on idea #2, I have omitted it. 1. Any control character received in a packet terminates that packet. What I meant by this was any control character not agreed on as going through unharmed. If the sending kermit won't send a control character, the receiving kermit should NAK a packet containing one. 3. A nak should be sent as early as possible. I should have been more explicit here too. This thought was mainly important for kermits that send multiple packets at a time. (Not yet part of the kermit protocol.) Many systems have output buffers, so the amount of time they spend not waiting for input is trivial. (I'm more used to large systems where this is true, and I like micro's to imitate this. I hate systems without typeahead.) Bob Larson <Blarson@Usc-Ecl.Arpa> [Ed. - No problem with any of these. But note in (3) that because of the layered nature of the protocol, the program does not (or should not) know the packet type or number until the packet reader has read the entire packet and returned it to the entity awaiting the packet; thus it would not fail and send a NAK as soon as a bad header was read.] ------------------------------ Date: Tue, 4 Dec 84 19:55:19 pst Subject: Kermit vs 4705? From: Steve Reynolds <reynolds%uofm-uts.cdn%ubc.csnet@csnet-relay.arpa> To: info-kermit@COLUMBIA.ARPA After implementing a Kermit on my NCR Tower (version III with Berkley enhancements) and successfully communicating with a VAX Kermit I decided to widen my horizons and try to communicate with an Amdahl 470. This is the general configuration of the machines: TOWER PAD AMDAHL 4705 VM UTS x.28 pp04 After some attempts I decided to ask the 'cloud' about this. Does the 4705 eat any control characters??? Does anyone else have this type of config??? If so, how did they get it working. If anyone has any ideas and/or ways of attacking the problem I would surely like to here from them. steve reynolds [Ed. - Note that Unix Kermit, as distributed, operates correctly on 370- series mainframes running UTS, with 3705-style front ends.] ------------------------------ End of Info-Kermit Digest ************************* ------- 28-Dec-84 12:28:51-EST,17258;000000000000 Mail-From: SY.FDC created at 28-Dec-84 12:28:33 Date: Fri 28 Dec 84 12:28:33-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest, V1 #45 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Fri, 28 Dec 1984 Volume 1 : Number 45 Special MS-DOS Kermit 2.27 Feedback Issue: 2.27 Broken (then fixed) for Z100 Display Problems on Z100 Bug in File Transfer Filename Display H19 Emulation Problem File Transfer Display Problem Fixes for NEC APC Support Module Re: Fixes for NEC APC Support Module Various Bugs Problems on Wang PC Kermit Can't Always Find COMMAND.COM TI Professional Support Mode Line Control (More) Various Bugs MS-DOS Kermit and DTR ---------------------------------------------------------------------- From: Frank da Cruz <SY.FDC@CU20B> Date: 28 Dec 84 12:00:00 EST To: Info-Kermit Subject: Special MS-DOS Kermit 2.27 Feedback Issue This issue of the Info-Kermit digest is devoted to feedback received on the recent release of version 2.27 of MS-DOS Kermit, announced in V1 #43 of the digest on December 7, 1984. A few major problems were reported, which prevented certain systems from working at all (notably the Z100) under 2.27; these were promptly fixed. Remaining problems are left for the next release, 2.28. All known problems with version 2.27 are listed in the file KER:MSKERMIT.BWR which, like all Kermit files, is available via anonymous FTP from host CU20B. ------------------------------ Date: Sat 8 Dec 84 01:23:28-PST From: NEELAND@USC-ECL.ARPA Subject: 2.27 Broken for Z100 To: sy.fdc@CU20B.ARPA Just FTP'ed the new 2.27 version of MSZ100 (the .EXE file), and Kermited it (via version 2.26). It works for the most part, so I don't think anything went wrong with the file transfer. However, I've encoun- tered the following serious flaws this evening - 1.) The STATUS command immediately crashes the system - must be rebooted. 2.) The SET PORT command responds with: not implemented (which I expected) and then crashes the system; certainly one way to emphasize the 'not implemented' status. Other commands which do work include: REMOTE, PUSH, SPACE, LOCAL, HELP, DIRECTORY, GET, EXIT, RUN, FINISH, and CONNECT. /Jim [Ed. - Thanks for pointing out the problem; some fast action by Jim Knutson (UT) and Jeff Damens (CU) seems to have fixed the problem -- the fixed files are in KER:MSXZ100.ASM and KER:MSZ100.BOO, and KB:MSZ100.EXE (binary) on CU20B, as of December 11.] ------------------------------ Date: Tue, 11 Dec 84 14:19:44 cst From: knutson@ut-ngp.ARPA (Jim Knutson) To: Info-Kermit@CU20B Subject: Display Problems on Z100 MS-DOS Kermit 2.27 now seems to work on the Z100. But here remain a couple minor problems: The SPACE command doesn't echo CRLF before CHKDSK runs. This causes the prompt and command to be overwritten. The return from push assumes a screen redraw/switch. It looks funny without it since the space you type to continue does nothing. Perhaps checking to see if screen switching is taking place and then blow out a message like [Back in connect mode.] if the switch won't occur. Jim [Ed. - next release.] ------------------------------ From: ihnp4!islenet!david%Berkeley@columbia.arpa Date: 7 Dec 84 20:12:54 CST (Fri) To: Info-Kermit@CU20B Subject: Bug in File Transfer Filename Display Using MS-DOS Kermit 2.26, if I do a SEND MSWANG.BOO at the remote Kermit, then escape back to my local Kermit-MS and RECEIVE B:MSKERMIT.BOO, the status display puts the B: in front of the wrong filename: Filename: B:MSWANG.BOO AS MSKERMIT.BOO [Ed. - This same behavior persists in v2.27, and may be fixed in the next release.] ------------------------------ Date: Mon, 10 Dec 84 12:55:28 pst From: Dave Tweten <tweten@AMES-NAS.ARPA> To: +outgoing@AMES-NAS.ARPA, INFO-KERMIT@CU20B.ARPA Subject: MS-Kermit 2.27 H19 Emulation Problem I picked up a copy of MS-Kermit 2.27 the afternoon of Friday, December 7, as soon as I received the announcement. Over the weekend, I tried it out, and concluded that one of its advertized fixes didn't. I used 2.27 to log onto our UNIX 4.2 BSD system and "man kermit" (what else?). Kermit still has the old problem of inverse blanks beyond the end of the line following one which ends in an inverse character. Incidently, I am sure the problem resides neither in our termdef files, nor in the "more" utility. I have borrowed a real H-19 long enough to confirm that our "more" and our termcap do not produce this effect on a real H-19. I inserted fixes for the inverse video problem into MSYIBM.ASM for MS-Kermit 2.27. They seem to do the trick. They are based on my belief that a real H-19 will provide black blanks for a scroll or a clear command, regardless of whether inverse video is on. The changes are presented below as "fc" output. [Ed. - Code omitted. Next release.] ------------------------------ Date: Mon, 10 Dec 84 12:55:28 pst From: Dave Tweten <tweten@AMES-NAS.ARPA> To: +outgoing@AMES-NAS.ARPA, INFO-KERMIT@CU20B.ARPA Subject: MS-Kermit 2.27 File Transfer Display Problem The "non-blanking of K bytes transferred" problem (fixed in 2.27) also affected the retry count, when in server mode. When you aren't in server mode, each new command produces a whole new status display, but when you are in server mode, only the retry count is restarted - without first blanking the line. I fixed that the same way 2.27 fixed the K-bytes display - by inserting a blank-to-end-of-line call in the positioning routine. 2.27 doesn't seem to have it. Thanks again for providing an excellent product. [Ed. - Code omitted, next release.] ------------------------------ Date: Wed, 12 Dec 84 07:16:22 pst From: dual!islenet!gibbons%Berkeley@columbia.arpa To: SY.FDC@CU20B Subject: Fixes for NEC APC Support Module The problems reported with the display on the NEC APC seem to be due to an instability in the video memory that varies from one NEC APC to another. One of the two APC's that I have access to behaved just as he described, while the other showed it hardly at all. I have fixed the instability in these two APC's by adding a couple of delay loops in the module. Hopefully this will take care of the problem in all cases, although I feel a little unsettled by the difference between the two here. I have also added the two delay loops to the UART mode setting code as Ron Blanford requested. Not having the optional second serial port myself, I am unable to verify this aspect of his code. Ian ------------------------------ Date: Thu 13 Dec 84 13:43:16-PST From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA> Subject: Re: Fixes for NEC APC Support Module To: cc.fdc@CU20B.ARPA I've checked out Ian's fixes and added one of my own, and now all the problems have been fixed. The new versions of MSXAPC.ASM and MSAPC.EXE are on my account and available for anonymous ftp. -- Ron [Ed. - Thanks! The new files are in KER:MSXAPC.ASM, KER:MSAPC.BOO, and KB:MSAPC.EXE on CU20B, as of December 13th.] ------------------------------ Date: 14 Dec 1984 1615-EST From: (Joe Smith, Colorado School of Mines, via) LCG.KERMIT@DEC-MARLBORO To: EIBEN@DEC-MARLBORO Subject: Various Bugs 1. BUG: MS-KERMIT cannot send packets while SET LOCAL-ECHO ON. CURE: Ignore the setting of LOCAL-ECHO when transmitting packets. 2. BUG: Problems in RECEIVE FILENAME.EXT when FILENAME.EXT exists. I told KERMIT-10 to SEND MSKERM.HLP and KERMIT-MS to REC MSKERMIT.HLP when MSKERMIT.HLP already existed on the floppy. It tried to rename the incoming file, but got confused as to which name to add the "&" to. MSKERMIT said "File name: MSKERM.HLP AS MSKERMIT.HLP", then "Renaming file to MSKERMITHLP" (note no period), then aborted with "?Unable to create file". Even stranger things happen when both MSKERM.HLP and MSKERMIT.HLP exits. Then MSKERMIT says "Renaming file to MSKER&IT.HLP". The ampersand is in the wrong position, and it should have never checked for the existance of MSKERM.HLP when I tell it to store the incoming file as MSKERMIT.HLP. 3. PROBLEM: Using SET LOCAL-ECHO ON does not work too well with 2 micros. There is no automatic linefeed when the RETURN key is pressed. CURE: When a CR is typed at the keyboard while LOCAL-ECHO is on, echo it as CR and LF, and set a flag signifying that an automatic LF was sent to the screen. If the host then sends a LF while this flag is set, ignore the 2nd LF (to avoid unwanted double spacing). ALTERNATIVE: Define a new command, SET REMOTE-ECHO ON. When this flag is set during a CONNECT operation, input from the keyboard and from the modem are logically "OR"ed together and echoed to both the screen and the modem, with LF after CR. This feature will be designed to allow two micros to be used as conversational terminals, when one is in SET ECHO REMOTE and the other in SET ECHO OFF. 5. SUGGESTION: Replace HEATH19 keyword with TERMINAL-EMULATION. With proper synonyms, SET TERMINAL-EMULATION ON would be same as the command SET TERMINAL HEATH-19. I feel the phrase "TERMINAL-EMULATION" is more descriptive, and would allow additional keywords, such as VT102, VT125, and TEKTRONIX. This has been partially implemented in MSXTIPRO.ASM Better yet, SET TERMINAL TYPE HEATH-19 and SET TERMINAL ID-SEQ VT100 and SET TERMINAL WRAPAROUND OFF, etc. 6. The portion(s) of the manual showing how to bootstrap using the FORTRAN program on a DECsystem-10 are wrong. Under TOPS-10, only one logical name can be assigned to a TTY at a time; the Fortran side of the bootstrap has to be changed. Joe Smith, CSM Computing Center, Golden CO 80401 (303)273-3448 ------------------------------ Date: Mon 17 Dec 84 13:33:47-PST From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA> Subject: Problems on Wang PC To: info-kermit@CU20B.ARPA I found what was causing the "Write fault error writing device AUX" error message. I had copied the WANG config.sys file which loaded the SER1DRVR. This driver is for a printer and interferes with using the serial port for communications. Once I removed it, MSWANG worked. The following does not work: STATUS cuases a loop sending blanks to the screen. RUN filename gives a message "unable to execute program". (This is for version 2.27.) Ted. ------------------------------ Date: Mon 17 Dec 84 13:35:12-PST From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA> Subject: Kermit Can't Always Find COMMAND.COM To: info-kermit@CU20B.ARPA I think MSKERMIT has a problem finding COMMAND.COM when it is not in the root directory. (This applies to versions 2.27 and 2.26.) I have command.com in a separate sub-directory with the following in CONFIG.SYS: shell=c:\bin\ibm\command.com c:\bin\ibm /p If I type DIR, I get the error message "Unable to execute program". DIR will work if I use a vanilla DOS system with command in the root dir. Ted. ------------------------------ Date: Sunday, 9 December 1984 14:59:56 EST From: Joshua.Brodsky@cmu-cs-speech.arpa To: SY.FDC@cu20b.arpa Subject: TI Professional KERMIT Recently, you posted on CMU's Info-Kermit bboard that a version of KERMIT for the Texas Instruments Professional Computer is available. MSTIPRO.EXE (converted from .BOO) behaves strangely on the Portable TI-PPC. On either the desk-top or portable model it sets the initial baud rate strangely; on the desk-top it accesses the disk briefly, but on the portable is has a divide overflow and bombs. If you know any owners or users groups for the TI who use KERMIT, I would like to meet them. Lastly, I am in need of a KERMIT for the NCR Decision-Mate V. The generic MS-DOS Kermit did not work. I've heard rumors that a version already exists. If you are not aware of one, can you post this request on your next Info-Kermit digest? Thank you. -Josh (brodsky@cmu-cs-speech.arpa) ------------------------------ Date: Thursday, 27 December 1984 21:25:55 EST From: Joshua.Brodsky@cmu-cs-speech.arpa To: Frank da Cruz <SY.FDC@CU20B> Subject: Re: TI Professional KERMIT Thanks for your help with TI Pro KERMIT. The Tektronix emulation is fantastic! I have forwarded a copy of MSTIPRO.EXE to the Washington DC TI Professional user group for distribution. I am still having trouble with my NCR Decision Mate V, however. Even the new generic KERMIT refused to work. In the MS-DOS documentation for the system, it refers to the COM port as \dev\aux and the error KERMIT gives is that it cannot get a handle on the communications port. I think this may be the cause. Can you think of an easy way to fix it? If not, I have heard that a version for the NCR already exists. Can you post a request for information on your next info-KERMIT bboard? Thanks a lot. -Josh [Ed. - Generic DOS Kermit 2.27 has several ways to let you try to get at the communications port - SET PORT n (n is 1 or 2 or 3 ... for COM1, COM2, COM3, ...) SET PORT DEVICE s (s is the device name, e.g. AUX, \dev\aux, etc.) SET PORT HANDLE n (n is a small integer corresponding to the DOS device handle) If you try enough of these, you should be able to hit one that works.] ------------------------------ From: Doug Brutlag <brutlag@SUMEX-AIM.ARPA> Subject: Mode Line Control To: Info-Kermit@CU20B.ARPA I FTP'd the IBMPC version of KERMIT 2.27 when it was released and have found no bugs in a couple of weeks of work. I am particularly happy with how well it interacts with PROKEY allowing me to use that function for general key redefinition (as I did with 1.20) as well as defining keys in MSKERMIT.INI files. I only have one suggestion for improvement. One can remove the MODE line only with the control-] M command in terminal mode. I would suggest that there be both a SET MODE-LINE ON/OFF toggle command and that the setting of the toggle be included in the STATUS report. The main reason for the suggestion is that then one could include SET MODE-LINE OFF in a KERMIT.INI file so that the user not have to ever see the mode line if he wanted. Of course I would leave the default value of this parameter to ON so that one would specifically have to turn it off with the command or in the INI file. Is there a way to do this now without control-] M? [Ed. - On the list for the next version. For a quick fix, see below.] Congratulations on the best piece of public domain software that I have ever seen. Doug Brutlag ------------------------------ Date: Wed, 19 Dec 84 12:21:34 cst From: allegra!noao!utastro!nather@Berkeley (Ed Nather) To: noao!allegra!ucbvax!info-kermit@Berkeley Subject: Various Bugs MS-DOS Kermit v2.27 always adds the "." character to an uploaded filename if it originally had no extension. Kermit v2.27 for the IBM-PC fails to show the mode line in inverse video on the file transfer display. Apparently the DOS function 6 (write a string) does not preserve the attribute byte, set to inverse video before the call to `dos' -- so the text was displayed normally (bright on dark) but the rest of the mode line, at the far end, was inverse video. Kermit v2.27 attempts to accomodate Unix buffs who have changed the default path separator from `\' using the (undocumented) configuration command "switchar=\", thus reversing the use of `/' and `\' in MS-DOS, and almost succeeds. The directory command gets confused, however, by the switch character reversal. [BEWARE! The "switchar=" command has disappeared from MS-DOS 3.0 and may never appear again. (*sigh*)] [Ed. - Code omitted, next release.] Kermit, by default, connects to the host with the mode line displayed. This can be changed to suppress the mode line, by default, by making the following change in msterm.asm: targ termarg <4,1,80,24,cptchr,2dch,0,scntab,deftab,0,,parnon> | `---(was 0) Ed Nather Astronomy Dept., U. of Texas {allegra,ihnp4}!{noao,ut-sally}!utastro!nather ------------------------------ Date: 18 Dec 84 09:21:40 PST (Tue) To: info-kermit@cu20b Subject: MS-DOS Kermit and DTR From: Mike Iglesias <iglesias@uci-750a> Can MS-DOS Kermit toggle DTR? We have a Develcon Dataswitch that uses DTR to tell when to get a new connection to a different computer. If it doesn't have it, can it be added in a future release? [Ed. - On the list for the next release.] ------------------------------ End of Info-Kermit Digest ************************* ------- 31-Dec-84 10:18:42-EST,10238;000000000000 Mail-From: SY.FDC created at 31-Dec-84 10:18:25 Date: Mon 31 Dec 84 10:18:25-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Info-Kermit Digest V1 #46 To: Info-Kermit-Members@CU20B.ARPA Reply-To: Info-Kermit@CU20B Queries-To: Info-Kermit-Request@CU20B Info-Kermit Digest Mon, 31 Dec 1984 Volume 1 : Number 46 Departments: ANNOUNCEMENTS - Kermit for MUSIC More Kermit Articles UUCP Kermit Distribution Instructions MISCELLANY - Kermit over Arpanet/Milnet TAC's P/OS Kermit V1.0 Terminal Emulation Suggestions for CP/M-80 Kermit ---------------------------------------------------------------------- Date: Wed 26 Dec 84 15:08:18-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit for MUSIC To: Info-Kermit@CU20B.ARPA A version of Kermit for the McGill University System for Interactive Computing (MUSIC), a timesharing system for IBM 370-series mainframes, has been contributed by Marie Schriefer of Indiana/Purdue University. It is based on the VM/CMS version of Kermit and has about the same capabilities (lacking only the ability to do wildcard SENDs). The files are available via anonymous FTP from host CU20B, under KER:IMUSIC.ASM (source) and KER:IMUSIC.DOC (documentation). ------------------------------ Date: Fri 28 Dec 84 11:08:18-EST From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: More Kermit Articles To: Info-Kermit@CU20B.ARPA PC TECH JOURNAL has a feature article on Kermit by Augie Hansen, starting on page 110 of the January 1985 issue. This article came as a surprise to us, but considering that we weren't asked about the material it's unexpectedly accurate (if somewhat dated). It's mostly a rehash of material from our BYTE article (June and July 1984), the manuals, and some tidbits gleaned from source code. There are just a few nits worth picking: . Kermit is not in the public domain. Most Kermit programs are copyrighted, but come with permission to copy and redistribute them freely, so long as it's not for profit. . Most major Kermit implementations are now capable of user/server operation. . Figure 4 is a "transaction diagram", but it omits one of the most important features of a Kermit transaction -- the epilogue, in which the EOT packet tells the recipient that the transaction has ended (e.g. that all files in the group have been sent). An accompanying article on p.130 describes a product called "Telios", one of the many commercial programs appearing on the market that include Kermit, Xmodem, terminal emulation, and modem control (dialing, scripts, etc). A similar product, "MLink", was announced on page 221 of December 1984 Data Communications. PC Magazine for January 1985 has a feature article on Micro-Mainframe communications by Bill Catchings (SY.WBC3), and an accompanying article "The Async Link" by Frank Derfler surveys several asynchronous protocols, including Kermit, and even provides a reader service number to circle on the bubble card (gasp!). ------------------------------ Date: 19 Dec 84 11:41:42-CST (Wed) From: Mark Vasoll <vasoll%okstate.csnet@csnet-relay.arpa> To: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: UUCP Kermit Distribution Instructions 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 command on your system: uucp okstate\!/u/kermit/cpm\* /usr/spool/uucppublic (this example will retrieve the CP/M version of Kermit) I chose "/usr/spool/uucppublic" as the destination on your system since the destination must be WIDE OPEN (drwxrwxrwx) to everyone. You should not remove files from your uucppublic until the entire transfer is complete including any redials that are necessary. If you do remove some files our system may retransmit them, resulting in a higher phone bill for you. There are 2 files available that contain information about the entire distribution. We recommend that you retrieve these files first. They are "00readme.txt" which explains the file name conventions used, and "00directory" which is a complete listing (by name) of all files in the distribution. These files will enable you to choose the right files the first time to save those high dollar phone bills. - UUCP Login information - UUCP distribution of Kermit is provided as a public service of: Oklahoma State University Department of Computing and Information Sciences Stillwater, Oklahoma UUCP login information for site: okstate Phone number : (405) 624-6953 (one line only) Login name : uucpker Password : thefrog Hours : 10:00pm - 10:00am central time (7 day per week) Problem : okstate!uucp-support (UUCP) reports : uucp-support%okstate@csnet-relay (ARPA) The phone number is for 300/1200 baud (bell compatible). Mark Vasoll Department of Computing and Information Sciences Oklahoma State University ...!ihnp4!umn-cs!isucs1!\ UUCP: ...!ucbvax!mtxinu!ea! > okstate!vasoll ...!convex!ctvax!uokvax!/ ARPA: vasoll%okstate.csnet@csnet-relay.arpa P.S. -- The system Okstate will be down from 8 a.m. on January 8th until 5 p.m. on January 9th to make some changes in our configuration. When services resume on January 9th no changes should be evident to our UUCP connections. Please note that UUCP Kermit distribution will not be available during this time, but will resume on January 9th at 5 p.m. ------------------------------ From: Jim Guyton <guyton@rand-unix> Date: 23 Dec 84 22:17:32 PST (Sun) To: Info-Kermit-request@columbia-20 Subject: Kermit over Arpanet/Milnet TAC's Excuse me if this is already documented, but it might be worth a note in the Kermit user's manual on how to run kermit over TAC's. What I've read / figured-out is ... 1) Use the "@B O S" and "@B I S" commands to the tac to get into binary mode, and 2) Reduce the size of the send buffer (by "set send packet-size 25" to the ibm pc version of kermit). This combination just worked over a two-network hop (milnet-arpanet-randnet) but that a packetsize of 96 was too big for the tac took me by surprise. Anyway, just fyi ... -- Jim ------------------------------ Date: 21 Dec 84 19:46:25 EST From: D. M. Rosenblum <DR01@CMU-CC-TE> Subject: P/OS Kermit V1.0 terminal emulation To: Info-Kermit@CU20B Several months ago I included a question about a problem with P/OS Kermit V1.0 terminal emulation in a long message asking various Kermit questions. I never heard anything more about it. I'm wondering if you could either include this message in the next Info-Kermit digest, or pass it on to the folks at Stevens who take care of P/OS Kermit. (Note to anyone at Stevens who is reading this as a result of either method of transmission: the system I work on here at C-MU is on the same DECNET as the Stevens machines, so anyone who is qualified and willing to discuss this should be able to send me mail, to DR01@CMCCTE.) The problem is that if I am doing terminal emulation in P/OS Kermit V1.0 and I connect to a VAX-11/780 running VMS V3.7, and I do a SET TERMINAL/INQUIRE, I get a "%SYSTEM-W-DEVREQERR Device request error" message, and the terminal type is not set (it remains at the system default, viz. Unknown). I have to do a SET TERMINAL/DEVICE=VT100 to set the device, which is annoying because my LOGIN.COM is set up to do an automatic SET TERMINAL/INQUIRE. Is it possible that I have some parameters set incorrectly? The settings that I use (for the ones that seem to be at all possibly relevant) are: Line: Receive speed 4800 Terminal: Local echo Off Transmit speed 4800 Transparent function keys Off Parity None IBM-Flag Off XON/XOFF ENABLED 7-Bit character codes On Any advice that anyone reading this can give would be much appreciated. Thanks. ------------------------------ Date: Wednesday, 26 Dec 84 10:48:12 EST From: rmcqueen(Robert C McQueen)%sitvxa.BITNET@WISCVM.ARPA Subject: P/OS Kermit v1.0 terminal emulation To: dr01@CMU-CC-TE, SY.FDC@CU20B Problem: SET TERMINAL/INQUIRE gives an error message under VMS version 3.7 for PRO/Kermit terminal emulation. Diagnosis: PRO/Kermit always responds that it is a Pro350 to the terminal id request. PRO/Communications has the option of responding as if it were a VT102, VT125 or Professional. Cure: [Sorry, but...] It is my understanding that VMS 4.0 will support the new terminal types (VT2xx and Professional). - Bob McQueen ------------------------------ Date: 27 Dec 1984 0520-EST From: LCG.KERMIT To: EIBEN Subject: Suggestions for CP/M-80 Kermit Suggestions for KERMIT-80: Send XON before any NAK packet. Read 64 file names at a time. Change INTCHR in CP4TT.ASM to not ignore modem when waiting for ^\S. If "P" or ^P is typed after the ESCape char, toggle SET PRINTER ON/OFF ala CPM. Add "DELete" as synonym for "ERA". Call the DIR routine in ERAse to tell user what files were deleted. Add "REMOTE DIR" and related commands. Add "REMOTE SET FILE BYTE-SIZE 8" command (for talking to KERMIT-10/20). Put 8080/Z80 test in init code, MOVER in independent part. Suggestion for VT180: When DEBUG is on, set the limited scrolling region to lines 13-24 and set jump scroll. Show the text of the file being transmitted or received in this area, with all characters execpt TAB, CR, and LF in # form. Because the serial line to the VT100 screen is always faster than the line to the modem, it is possible to send 1 character to the VT100 each time through the loop that checks on the modem and not lose any characters from the modem (provided that the user does not type Control-S). Joe Smith, CSM COmputing Center (303)273-3448 (303)986-8366 [Ed. - Good suggestions; most of these have been on the list for some time.] ------------------------------ End of Info-Kermit Digest ************************* -------