From cmg Tue Jul 9 16:33:19 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA24985; Tue, 9 Jul 91 16:33:19 EDT Date: Tue, 9 Jul 91 16:33:17 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #1 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Tue, 9 Jul 1991 Volume 14 : Number 1 Today's Topics: New VT200/300 Key Mapping File for MS-DOS Kermit MS-DOS Kermit and Microsoft Windows 3.0 Kermit and Desqview Kermit, LAT & Windows 3.0 problem 8-bit Linemode Devices on IBM Mainframes New VMSHEX/VMSDEH Programs Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU, requests for addition to or deletion from the Info-Kermit subscriber list to Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET. Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Thu, 20 Jun 1991 10:58 CST >From: Kevin Lowey Subject: New VT200/300 Key Mapping File for MS-DOS Kermit Keywords: MS-DOS Kermit Here is a new version of MSIVT3.INI (also known as VT300.INI) which fixes a bug in the extended keyboard definition, in which the DEC Remove key was mapped to a nonexistent scan code, rather than to Gray Delete. Also, the PC F11 and F12 keys on extended keyboards are now used for Help and Do, respectively, and the DEC F11-F20 keys are now mapped to Alt-F1 through Alt-F10 on both 88 and 101 keyboards, for consistency, and the DEC Enter key was moved to PC F10 on the 88 keyboard to make it easier to use programs that require the keypad Enter key. [Ed. - Thanks, Kevin. The new file replaces the old version as msivt3.ini. The documentation file, msivt3.doc, has also been updated.] ------------------------------ Date: Tue, 25 Jun 1991 14:25:32 EDT >From: Christine M Gianone Subject: MS-DOS Kermit and Microsoft Windows 3.0 Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0 Xref: Microsoft Windows, See Windows 3.0 In response to numerous queries, here is the situation -- as best we know it -- with MS-DOS Kermit and Microsoft Windows. MS-DOS Kermit is not a "Windows Application". It was not written specifically for Windows, and it does not have a Windows-like menu-and-mouse command interface. However, MS-DOS Kermit has knowledge of the Windows environment and can run "in a window" under certain conditions. This means that Kermit can run simultaneously with other Windows applications (even other copies of Kermit), it can use Windows fonts, and you can cut and paste to and from the Kermit window into other windows, etc, if you have constructed the KERMIT.PIF file properly and you have enough memory for Kermit. When Kermit cannot be run in a Window, you can still use it under Windows as a full-screen application. Under Windows 2.0, you can use Kermit in a window on any kind of PC or PS/2 that has enough memory. Everything works normally (but slower) except Tektronix emulation, which behaves as if you had a monochrome video adapter (plus signs are used instead of dots). The important .PIF file parameters are "Directly Modifies" (uncheck all the boxes), "Memory Requirements" (190 KB required, 400 KB desired), "Program Switch" (check Text box), "Screen Exchange" (check Text/Graphics box). If you don't have enough memory, you can reduce Kermit's memory requirement by eliminating rollback screens: give the DOS command "SET KERMIT=ROLLBACK 0" before starting Kermit, or put this command into your MSKERMIT.INI file. Under Windows 3.0, the situation is the same as for 2.0 if you are running Windows on a 386 or 486 class PC in Enhanced Mode, with the added benefit that Tektronix graphics works if you set up your KERMIT.PIF file for the High Grahics Video Memory display option (however, Windows will complain when you try to switch back to Kermit's text screen from the graphics screen, and does not save the graphics screen). However, Windows 3.0 apparently does not allow non-Windows DOS applications (even Kermit, which is written with "Windows awareness") to operate in a window in Real or Standard mode, which you must use on a 286 or lower class PC, such as a PC, PC/XT, PC/AT, PS/2 Model 50, etc. On these machines, Windows 3.0 only allows Kermit to run in full-screen mode. This seems to be a limitation of Windows 3.0. If anybody knows how to overcome this limitation, please send mail about it to Info-Kermit. If you can get Kermit into a window, but it does not communicate over the COM1 or COM2 port, check your WIN.INI file to make sure that the MODE command for COM1 or COM2 does not include a ",P" -- if it does, remove the ",P". ------------------------------ Date: Mon, 3 Jun 91 11:47:02 EDT >From: Isidore G Bendrihem Subject: Kermit and Desqview Keywords: MS-DOS Kermit, DesqView I've been running kermit under Desqview 386 (QEMM 5.11 and DV 2.31) with no problems. I recently installed an upgrade from Quaterdeck (QEMM 5.13 and DV 2.33), and whenever I start kermit, after giving the "Press ? for help" message, it freezes my computer up. I can't even get back to Desqview. It seems like kermit has taken control over the keyboard. Any suggestions? Configuration: 386sx, 4 MB Chips & Technologies chip set AMI BIOS MS-DOS 4.01 Kermit 3.10 (I've tried both with patches and without them) [From jrd: What's one to say? At the startup stage Kermit is using 100% pure DOS calls to do everything. Kermit never grabs keyboard interrupts. That leaves two possibilities: DV 2.33 has changed what needs to go into your DV setup file for Kermit and/or DV 2.33 has problems. MS-DOS Kermit worked fine with the previous release of Quarterdeck software.] ------------------------------ Date: Tue, 4 Jun 1991 15:34:16 EDT >From: MARIA@SERVAX.FIU.EDU (Maria Rosa Drake) Subject: Kermit, LAT & Windows 3.0 problem Keywords: MS-DOS Kermit, DEC Pathworks We are running DECs PathWORKS network operating system, which provides LAT support, and Kermit 3.01 and Kermit 3.10. We have no difficulty using Kermit to access host systems via LAT when running under DOS; however we have discovered that when invoking Kermit from within Windows 3.0 enhanced mode, the system hangs (it works under Windows 3.0 standard mode). Our MSKERMIT.INI file does a SET PORT DECNET VAXname and a CONNECT; right after connect is where the problems occur. The systems are Zenith 386's with 4MB of RAM running either MS DOS 3.3+ or MS DOS 4.0. Any suggestions? Maria Rosa Drake Florida International University [From jrd: One supposes that Pathworks is not designed to run by loading DECnet outside Windows and then coupling a task to it within Windows. At least that's my guess. The networking programs have to take some steps to ensure the top level client is in the "right virtual machine" and so on, and maybe your version of Pathworks does not do that job. I make no pretense of being a Windows 3.0 expert of any kind, but a suggestion is to start the whole thing from a .BAT file within Windows, to see if that helps. You might also contact DEC to see if this is a known problem and get any workarounds. In addition, I would check the Pathworks documentation on suggestions configuring Windows (things to be said in SYSTEM.INI etc regarding networks). It could turn out that Windows 3 itself is the culprit when programs use high numbered interrupts for communications (DEC LAT and CTERM both require these things to talk to external terminal emulators).] ------------------------------ Date: Wed, 1991 Jun 12 19:28 EDT >From: "John F. Chandler" Subject: 8-bit Linemode Devices on IBM Mainframes Keywords: IBM 370 Kermit I am looking for people who would be interested in trying out 8-bit-wide file transfer through a new generation of front ends on IBM mainframes. The following is a list of configurations that I believe may support the new 8-bit-wide ASCII communications, but it is not by any means complete and not necessarily accurate. I'd be interested to hear from anyone who has knowledge of these or other 8-bit devices for "LU1" communications. Also, as I said before, I'm looking for testers willing to try out a version of Kermit that has been modified to take advantage of the 8-bit capabilities. I can be reached at either or Thanks. By the way, even if all you can tell me is that I have misspelled something in the list, I would still like to hear from you. By the way, I posted this message on the BITNET discussion group for IBM protocol convertors (which was the closest thing I could find to the subject), but got no substantive answers. I also posted it on the IBM mainframe Kermit developers discussion group with no better results. Maker Model Software Fibronics K2000 KNET/MVS Fibronics K200 KNET/MVS Fibronics K310 KNET/MVS Intel Fastpath ACCES/MVS ? ACC9315 ACCES/MVS ? Eicon/MSDOS PACKET/74 Intel Jupiter 1000 PACKET/74 IBM 37x5 COMMPRO/NAS Amdahl 47x5 COMMPRO/NAS Renex RPAD Netlink SNA/Gate Netlink 3703 Perle 350/SNA Telematics PCI 167 Telematics PCI 1067 ------------------------------ Date: Wed, 5 Jun 1991 19:30:29 EDT >From: XRJRG@lepvax.gsfc.nasa.gov (Jeff Guerber) Subject: New VMSHEX/VMSDEH Programs Keywords: VMS hex/dehex programs It was recently pointed out on the Info-VAX mailing list that VMSHEX/VMSDEH do not work for VAX indexed files -- they come out sequential instead. I took a look at the MACRO source, and it wasn't hard to find the bug -- the file organization byte was not being saved in the hexified file, as were the record format, record attributes, and so forth. I have fixed the programs (by adding a new packet type) so that they do save this byte, and they seem to work as expected. (I wasn't sure that they would, because the RMS manual seems to indicate that extended attribute blocks are needed, but I successfully hexed/dehexed an indexed file with 3 keys, and the new file matched the original exactly.) VMSDEH seems to work fine with older .HEX files that don't have this packet, with the organization defaulting to sequential as before. A better method might be to save the entire file access block and any extended attribute blocks, but this is beyond my knowledge of MACRO and RMS. If the Old VMSDEH is used on new-VMSHEXed files, the old VMSDEH gives an "Unknown block type" error message, skips the new record and goes on to do the rest of the input file, creating a sequential output file, and so it appears that replacing the old VMSHEX/VMSDEH programs with the new ones will do no harm. Sorry, but I cannot take over support for these programs (if such is needed); I really know very little about MACRO. Jeff Guerber ST Systems Corp. (STX) NASA / Goddard, code 693.2 xrjrg@lepvax.gsfc.nasa.gov Any opinions are my own and not those of NASA or STX. [Ed. - Thanks, Jeff! The new VMSHEX and VMSDEH programs have been placed in the Kermit Test area for now. If anybody encounters problems with them, please send reports to Info-Kermit. For that matter, if anyone can verify that they do work as advertised, and are upwards compatible with the old VMSHEX and VMSDEH programs, let us know.] ------------------------------ End of Info-Kermit Digest ************************* From cmg Tue Aug 20 12:17:24 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA19465; Tue, 20 Aug 91 12:17:24 EDT Date: Tue, 20 Aug 91 12:17:23 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #2 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Tue, 20 Aug 1991 Volume 14 : Number 2 Today's Topics: New Lotus 1-2-3/V Key Mapping File for MS-DOS Kermit Kermit With DOS 5.0 Task Swapper Windows 3.0 and High-Speed Kermit Connections Window Slot Sizes Unique Log File Names for MS-DOS Kermit? Keyboard Bug in MS-DOS Kermit Kermit Archives Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU, requests for addition to or deletion from the Info-Kermit subscriber list to Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET. Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Mon, 8 Jul 1991 15:20 CST >From: RAVI%SLU.BITNET@RICEVM1.RICE.EDU Subject: New Lotus 1-2-3/V Key Mapping File for MS-DOS Kermit Keywords: MS-DOS Kermit, Lotus Here at Southeastern Louisiana University, we have Lotus/123 on our VAX/VMS system. Many of our users use PCs with Kermit to access the VAX system and we would like to have some method of maintaining transparency for the user, i.e. we want the user to be able to use Lotus/123 on the Vax from his PC and have it look and feel as though he were using PC Lotus. I have created a Lotus 1-2-3 key mapping file for enhanced keyboards. I am sending that to you separately. Feel free to make any suggestions/comments, etc. and use it in the digest. Ravi BITNET: RAVI@SLU Southeastern Louisiana University [Ed. - Thanks very much, Ravi! The new file is in kermit/a/msi123.ini on watsun, and MSI123.INI on KERMSRV.] ------------------------------ Date: Mon, 15 Jul 91 23:47:17 EDT >From: Dick Elnicki Subject: Kermit With DOS 5.0 Task Swapper Keywords: MS-DOS Kermit and DOS 5.0, MS-DOS 5.0 DOS 5.0 and Kermit appear quite compatible. I am currently using Kermit with my EasyK scripts for this e-mail. A program applicaton for Kermit access to our IBM VTAM services is in my DOS Shell. Before starting it, I enabled the Active Task list. Then I clicked on the program name to auto dial into our VTAM services. Once signed on, I can press ALT with ESC to toggle back to the DOS Shell. At the shell, I can start a second application, e.g., PCWrite or Lotus 123. This, of course, depends on the free memory available. The ALT with TAB's also works as described. One can toggle through the active tasks. The name appears at the top of the screen. A choice is make by pressing Enter for a named task. The ALT with ESC choice gives the DOS Shell as noted above. Here you can also double click on the desired active task to return to it. Or, you can click on another program to start it (if you have enough free memory). And, you can click on an active task, then on FILE, and then on DELETE to shut down an application. My mouse works as desired. It is an inexpensive 3-button mouse that is not from IBM, Microsoft, or any other "name" brand. The roller ball runs the cursor, the left button is set to ENTER, the middle button is PF7 (scroll up in the VTAM world), and the right button is PF8 (scroll down). DOS 5.0 is certainly worth the price of admission. It does run a number of my applications that DOS 4.0 could not handle. The DOS Shell run with the mouse is easier to use than my old dozen-or-so AAA.BAT-type application start-up screen. The HELP is great, too. This is not a commercial. I don't have any stock in Microsoft. I do hope you can use the above to pass on to other Kermit users how they might use DOS 5.0. Best regards, Dicke [Ed. - Thanks for the encouraging report, Dicke! It seems that we are going through a period of Microsoft pulling the rug out from under Kermit with new releases of Windows, DOS, etc. Unfortunately, the reports are not all completely positive. One user reports that Kermit cannot keep up with serial port input at high speeds -- 19,200 bps or above, depending on the processor model, under DOS 5.0. Apparently, DOS 5.0 can lose serial port interrupts where previous versions of DOS did not, most likely because of its new memory management features.] ------------------------------ Date: Thu, 25 Jul 91 16:06:52 EDT >From: hwp@sisd.sisd.Kodak.COM Subject: Windows 3.0 and High-Speed Kermit Connections Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0 If you desire to run MS-Kermit at speeds higher than 9600 bps under Windows 3.0 (MS-DOS) you need a third party driver (i.e. TurboComm) because the native Windows 3.0 communication driver maxes out at 9600. You also need to have 16550a UART chips in your serial ports too. H.W.Payne ------------------------------ Date: Fri, 26 Jul 91 15:57:35 -0700 >From: cclloyd@leland.stanford.edu (Charles Lloyd) Subject: Window Slot Sizes Keywords: Sliding Windows, Packet Length, Performance How does one determine the best size for a window slot? I have a line which has between 1 to 2 seconds roundtrip delay (variable wrt time of day) and have not improved effective throughput much with choices or 1, 4, or 8. Slot count = 1 : Significant idle time on LEDs of modem. Slot count = 4 : Sporadic idle time, rapid acknowledgements on SD LED. Slot Count = 8 : Alomost continuous flow on the RD light, almost continuous blips on SD light. Yet, the throughput only went from 5Kbps to 7 Kbps in going from 1 to 8. (I didn't check for slots = 4). Is it unadvisable to play with packet size? Is it possible to set the slot count too big so that data overruns cause more errors than with a smaller window? What's the rule of thumb? Many thanks, Charles. [Ed. - There is an article in Kermit News #4 explaining in great detail how to optimize Kermit's performance by varying the window slots and packet length. Kermit News #4 is on watsun as kermit/e/news.n4, NEWS.N4 on CUVMA via KERMSRV. Briefly, you should use the smallest window size that keeps the modem receive or transmit light on continuously (depending on whether you are sending or receiving files), and then increase the packet size to the maximum allowed by the receiving Kermit. Let's say you get continuous transmission with 5 slots. MS-DOS Kermit's total packet buffer size is 2000, so the maximum size for each packet is 2000 / 5 = 400. Tell both Kermits to SET WINDOW 5, and tell the receiving Kermit to SET RECEIVE PACKET-LENGTH 400.] ------------------------------ Date: Sat Jul 20 19:13:04 1991 >From: Ben Olasov Subject: Unique Log File Names for MS-DOS Kermit? Keywords: MS-DOS Kermit and Unique File Names I'm trying to turn on a session log file prior to invoking a Kermit script file. While the command line: kermit take cbd.scr works, the line: kermit log session d:\local\20\250.txt take cbd.scr doesn't. [Ed. - Multiple commands on the command line must be separated by commas: kermit log session d:\local\20\250.txt, take cbd.scr Adding the comma after "250.txt" should fix the problem.] The reason I'm turning on the session log first is so that I can expand a system variable (from Waffle BBS software) into a filename at the time that the kermit command line is executed, thereby logging each session to a unique filename. If anyone knows how to do this, or has an effective alternative approach, I'd really like to hear from them. Thanks, Ben Olasov [Ed. - If you're using MS-DOS Kermit version 3.10 or later (you should be), try this: SET COUNT 999 DEFINE \%F \V(NDATE).\V(COUNT) This makes the \%f variable be something like "19910727.999" (filename = today's date, filetype = 999). Now let's see if the file already exists: IF NOT EXIST \%F GOTO OK If it does, decrement the COUNT variable and try again until you have a name that's unique: SET COUNT 999 :LOOP DEFINE \%F \V(NDATE).\V(COUNT) IF NOT EXIST \%F GOTO OK IF COUNT GOTO LOOP ECHO Sorry, you've already created 1000 log files today! STOP :OK LOG SESSION \%F That should give you a unique filename.] ------------------------------ Date: Tue, 09 Jul 91 11:45:24 BST >From: Brian Wood Subject: Keyboard Bug in MS-DOS Kermit Keywords: MS-DOS Kermit and Keyboard Drivers I am surprised that this has not been picked up sooner as it is a bug which appears to have been present in MS-DOS Kermit since version 2.31. On an OPUS PC3, a turbo xt, which I suspect is also sold under different badges, running MS-DOS 3.3 there is a clash between Kermit and the keyboard driver installed using the KEYB.COM program. I have only used the driver for the UK keyboard but logically it should apply to them all. After varying amounts of time the PC will appear to hang and will not respond to the keyboard except that you will get the beep to tell you that the keyboard buffer is full. This may well happen with other machines which use MS-DOS 3.3 and KEYB.COM. The remedy is to use "set key off" to force kermit to use the DOS keyboard routines rather than BIOS. Cheers, Brian Wood, UMIST, Manchester, England. [Ed. - This is not a Kermit bug. Kermit is simply asking the BIOS for keyboard input. Kermit is not hanging the system, the BIOS and/or the keyboard driver are doing it.] ------------------------------ Date: Fri 2 Aug 1991 11:33:26 EDT >From: Christine M Gianone Subject: Kermit Archives Keywords: Kermit Archives We receive a lot of complaints that it's difficult to find things in the Kermit archives, and suggestions about how to reorganize them. Many people would like to see us put the MS-DOS related files into ZIP archives, the UNIX-related files into compressed tar archives, or put each version in its own subdirectory, etc etc. The Kermit archives are designed to be written to industry standard ANSI "D" or IBM OS "VB" labeled tapes that can be read on a wide variety of computers. These tapes can only have text files on them; they consist of "records" that are lines of text, and they can't have any kind of directory structure. Tapes are sent out by mail order, and the income from these orders pays for the Kermit Development and Distribution operation and subsidizes network access. We don't have the disk space or the time to keep multiple copies of the hundreds of different Kermit implementations in the many different formats that network users ask for. If we were better funded and staffed, of course, it would be a different story. Here is a brief road-map to the Kermit files. There are five major Kermit areas, A through E. On watsun.cc.columbia.edu, which offers anonymous FTP access to the Internet, there is a kermit directory. It contains a file called read.me, which explains the organization of the directories and files underneath it: kermit/a through kermit/e, plus several special directories for binary files, test versions, etc. On BITNET/EARN, Kermit file access is handled by a file server called KERMSRV at CUVMA. You can ask KERMSRV for any file by name, as long as it is in one of the A through E areas. Binary files are not available on KERMSRV, but test versions can be requested by prefacing filenames with "T:", for example T:MSTIBM.BOO. Each directory, a through e, contains a group of files whose names start with "aa", for example aavers.hlp. These are text files that list all the Kermit versions, sorted in various ways: by computer, operating system, language, area, release date, etc. Within each directory, files for each version are grouped together by filename. Related files start with the same 2- or 3-letter prefix, for example all the MS-DOS Kermit files start with "ms". When there are many files for a particular Kermit version, there is usually an "aaa" file for that version, for example msaaaa.hlp or ckaaaa.hlp, that explains the file naming conventions. ------------------------------ End of Info-Kermit Digest ************************* From cmg Thu Aug 22 14:49:11 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA22965; Thu, 22 Aug 91 14:49:11 EDT Date: Thu, 22 Aug 91 14:49:10 EDT To: Info-Kermit From: Christine M Gianone Subject: Info-Kermit Digest Now Delivered by LISTSERV Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: The Info-Kermit Digest is now delivered by BITNET LISTSERV, which has proven more reliable and flexible than UNIX sendmail. All subscribers who were previously on the Info-Kermit distribution list at watsun have been moved to the I-KERMIT LISTSERV distribution list: I-KERMIT@CUVMA.BITNET, I-KERMIT@CUVMA.CC.COLUMBIA.EDU. Digest submissions should still be sent to info-kermit@watsun.cc.columbia.edu, and administrative queries to info-kermit-request@watsun.cc.columbia.edu. Alternatively, BITNET/EARN subscribers can send mail to KERMIT@CUVMA (not I-KERMIT). But from now on, you can subscribe to Info-Kermit yourself, you can cancel your subscription yourself, and you can correct your personal name yourself. Just send e-mail to: LISTSERV@CUVMA.BITNET (or to whatever BITNET node you actually received this Digest issue from), and Internet subscribers can mail to LISTSERV@CUVMA.CC.COLUMBIA.EDU. In the text of the message, use the following commands: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Remember: Don't send SUBSCRIBE, UNSUBSCRIBE, or REGISTER messages to I-KERMIT, send them to LISTSERV. Mail sent to I-KERMIT is forwarded to the whole list; only the list owner is allowed to mail to I-KERMIT. Send Digest submissions or queries to KERMIT@CUVMA or to Info-Kermit@watsun.cc.columbia.edu. If you received this message, no action is required on your part. Kermit files are still accessible in the normal way: from KERMSRV at CUVMA on BITNET/EARN, and via anonymous FTP from watsun.cc.columbia.edu on the Internet. Internet users may also refer to watsun as: kermit.cc.columbia.edu This name will remain effective in case the Kermit distribution host ever changes from watsun to some other machine (this won't happen in the foreseeable future). For further information about LISTSERV, send mail to LISTSERV@CUVMA.BITNET containing the text "INFO". Various reference cards, tutorials, and reference manuals are available. I trust that this change will result in fewer missed or duplicated issues, and generally more reliable delivery. From cmg Fri Aug 23 15:13:06 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA08669; Fri, 23 Aug 91 15:13:06 EDT Date: Fri, 23 Aug 91 15:13:05 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #3 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Fri, 23 Aug 1991 Volume 14 : Number 3 Today's Topics: MS-DOS Kermit 3.11 Prerelease Ready for Testing Termcap/Terminfo for MS-DOS Kermit on the Wang PC MS-DOS Kermit Speed under Windows Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Fri, 23 Aug 1991 15:28 EDT >From: Christine M Gianone Subject: MS-DOS Kermit 3.11 Prerelease Ready for Testing Keywords: MS-DOS Kermit 3.11, TCP/IP >From Professor Joe R. Doupnik (JRD) of Utah State University, a new release of MS-DOS Kermit. The final release will occur in about one week, so rapid testing and reporting of bugs is needed. Please report problems directly via e-mail to Joe: jrd@cc.usu.edu (Internet), JRD@USU (BITNET/EARN), with cc to Info-Kermit@watsun.cc.columbia.edu. Please limit your reports to bugs (and/or fixes) -- the design and features of this release are frozen. The sooner you get your bug reports in, the greater the chances of getting the bugs fixed! The differences from version 3.10 are: NETWORKS: . Built-in TCP/IP network support for PCs with Ethernet-style packet drivers. . New SET PORT TCP/IP , SET TCP/IP commands. . Alt-n has \Knethold assigned by default. . SET NETBIOS-NAME allows you to set the PC's Netbios node name. TERMINAL EMULATION: . VT220 terminal type now supported. . Alt-minus now toggles between current text terminal and graphics screens, rather than all possible terminal types. . SET TERMINAL CHARACTER-SET DEC-SPECIAL. . SET TERMINAL UPSS {DEC-MCS, LATIN1}. SCRIPT PROGRAMMING: . New OPEN, CLOSE, READ, and WRITE commands for local file access. . "Long variable names": \m(this-is-a-variable-name). . Maximum length for macro definitions raised from 255 to 1000. . GOTO is now global, rather than confined to current macro or command file. OTHER: . New simplified and expanded dialing directory using a plain text file. . All known 3.10 bugs are fixed. . Improved help and status screens. . New help and beware files. The long variables work like this. Define them as if they were macros: define telephone-number 7654321 Refer to them using the new \m() construct: output atdt \m(telephone-number)\13 Those who want to try out the TCP/IP networking support, but don't have packet drivers, use anonymous FTP to get them from Clarkson College in Potsdam, NY, host sun.soe.clarkson.edu [128.153.12.3], cd pub/ka9q, use "type binary", get the appropriate zip, arc, zoo, etc, files, and use PKUNZIP or ZOO on your PC to unpack them. Only Ethernet-style packet drivers are supported. The new version of Kermit has been sucessfully tested with the following boards and accompanying packet drivers: Ungermann-Bass PC/NIC board with Clarkson UBNICPC packet driver 9.1 3COM 3C503 with Clarkson 3C503 packet driver 9.4.0 Western Digital WD8003E with Clarkson WD8003E packet driver Cabletron boards with Cabletron CSIPD_E (1.05) and CSIPD_X packet drivers IBMTOKEN.COM 3C501 emulation packet driver 1.9 over Token Ring board+drivers DIS_PKT over NDIS for LAN Manager networks (incl DECnet/DOS, AT&T StarGROUP) The new Kermit commands are: SET TCP/IP ADDRESS Tell Kermit the IP address of your PC SET TCP/IP BROADCAST IP broadcast address SET TCP/IP SUBNETMASK Your local IP network subnet mask SET TCP/IP GATEWAY IP address of nearest gateway SET TCP/IP DOMAIN Domain name for your local IP network SET TCP/IP PRIMARY-NAMESERVER Address of primary nameserver SET TCP/IP SECONDARY-NAMESERVER Address of fallback nameserver SET TCP/IP HOST Default host for SET PORT TCP SET PORT TCP/IP Specify host to connect to Automatic downloading of some of these parameters via BOOTP or RARP is also supported. Before using Kermit's TCP/IP features, be sure to read the TCP/IP sections at the end of MSKERM.HLP and MSKERM.BWR! Many thanks to Erick Engelke of Waterloo University in Ontario for contributing his Waterloo TCP package (WATTCP), and for his cooperation in adapting it to Kermit. The new files are in kermit/test/ms* on watsun.cc.columbia.edu, and in T:MS*.* on KERMSRV at CUVMA on BITNET/EARN. Convert the MSTIBM.BOO file into MSTIBM.EXE with any of the MSBPCT.* programs available in kermit/a or kermit/bin, or from KERMSRV. On the Internet only, the binary MSTIBM.EXE program is available via binary-mode FTP from kermit/bin/mstibm.exe. FTP users: remember -- transfer files from the kermit/bin directory in binary mode, transfer all files from all the other directories in text (ASCII) mode. Source code will appear with the final release. See MSKERM.HLP for information about the new commands and about how to use the dialing directory. Make sure to get the new MSKERMIT.INI and MSIHAY.SCR files too, since the dialing directory is implemented by these files (note, you must rename MSIHAY.SCR to HAYES.SCR so the DIAL command can find it). There is also a sample dialing directory file MSIDIA.TXT (rename to DIALUPS.TXT). The "beware file" for the new version is MSKERM.BWR -- be sure to read it before reporting problems. As always, our deepest thanks to Joe for his skill, generosity, patience, and long hours of hard work in making this new version of MS-DOS Kermit available. ------------------------------ Date: Thu, 8 Aug 91 16:35:49 EDT >From: pfm@BOURBAKI.MIT.EDU Subject: Termcap/Terminfo for MS-DOS Kermit on the Wang PC Keywords: Wang PC Kermit In case it's of interest to anyone else, I am sending my cheap way out of not having a terminal emulator with the Wang PC version of MS-DOS Kermit: UNIX termcap and terminfo files that will make the PC work as a VT100 minus function keys. (it has the correct screen and cursor escapes and the cursor arrow keys which makes it completely adequate for full screen use but not function keys). Let me also mention that I've put the IBM-PC version of Kermit on several PC's here we use as terminals, which had vt100 emulators only. The vt320/tek emulators are great and will probably save us from buying new graphics terminals. Keep up the good work! Best regards, Paul Mende pfm@math.mit.edu Center for Theoretical Physics pfm@mitlns.bitnet Massachusetts Inst. of Technology [Ed. - Thanks, Paul. The Wang PC termcap/terminfo material has been added to the Kermit distribution as MSVWNG.TC.] ------------------------------ Date: Tue, 20 Aug 91 15:15:19 EST >From: Pat Zerkle Subject: MS-DOS Kermit Speed under Windows Keywords: MS-DOS Kermit and Windows 3.0 Regarding newsletter comments re MS-DOS 5.0, Windows 3.0, and serial speeds above 9600. I use a 386/25MHz 64k cache, 4mb RAM 'AT Clone' (Club American) with AMI BIOS, connecting via a DEC LAT to an IBM 7171. I have had no problem using MS-Kermit 3.1 at 19200 bps under MS-DOS 4.01, MS-DOS 5.0, and via Windows 3.0 Enhanced under either DOS version. In Windows, I use the switch to enable background execution. The maximum speed is probably limited by a combination of software/BIOS/architecture/serial hardware/system load, so we can probably only use empirical methods to get it to work. As for Windows, the files \WINDOWS\SYSIN*.TXT installed by Windows (at least, my 5/1/90 files) explain several SYSTEM.INI settings related to COM ports. The COMxBuffer and COMBoostTime settings may help (hurt?) some users. Cordially, Pat Zerkle [Ed. - Thanks for the encouraging report. Another user, E.W. Carlson says, "I don't understand the July 25 comment that MS-Kermit can not run faster than 9600 baud under Windows. I routinely run MS-Kermit at 19,200 baud under Windows on a PS/2 55SX. The machine is standard IBM equipment with no special chips added."] ------------------------------ End of Info-Kermit Digest ************************* From cmg Fri Aug 30 13:02:31 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA13446; Fri, 30 Aug 91 13:02:31 EDT Date: Fri, 30 Aug 91 13:02:30 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #4 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Fri, 30 Aug 1991 Volume 14 : Number 4 Today's Topics: MS-DOS Kermit 3.11 Beta Testing Continues Kermit News #5 The Old Curiosity Shop MS-DOS Kermit vs Twincom 9600/V42.bis Modem Initialization in MS-DOS Kermit The Wonders of Kermit 0.98(63) and One Little Grouse Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Fri, 30 Aug 1991 12:00 EDT >From: Christine M Gianone Subject: MS-DOS Kermit 3.11 Beta Testing Continues Keywords: MS-DOS Kermit 3.11, TCP/IP Reports on the beta release of MS-DOS Kermit 3.11 continue to pour in to Professor Joe R. Doupnik (JRD) of Utah State University. In order to take full advantage of these reports and produce a solid official version, the testing period will continue for a few more days. The final release is expected by the end of next week. The new files will remain in kermit/test/ms* on watsun.cc.columbia.edu, and in T:MS*.* on KERMSRV at CUVMA on BITNET/EARN until then. Convert the MSTIBM.BOO file into MSTIBM.EXE with any of the MSBPCT.* programs available in kermit/a or kermit/bin, or from KERMSRV. On the Internet only, the binary MSTIBM.EXE program is available via binary-mode FTP from kermit/bin/mstibm.exe. FTP users: remember -- transfer files from the kermit/bin directory in binary mode, transfer all files from all the other directories in text (ASCII) mode. Source code will appear with the final release. Once again we offer our deepest thanks to Joe for his skill and stamina to make this new version of MS-DOS Kermit available. ------------------------------ Date: Fri, 30 Aug 1991 12:00 EDT >From: Christine M Gianone Subject: Kermit News #5 Keywords: Newsletter Kermit News #5, our paper newsletter (ISSN 0899-0309), will be published in a couple months. If you received Kermit News #4, or if you ordered Kermit material from us since June 1990, you're already on the mailing list. If you want to be added to the mailing list, send in your postal address. Library serials collections are encouraged to subscribe too. No cost! If you haven't seen Kermit News before, copies of the last three issues are available online as kermit/e/news*.* (NEWS*.* from KERMSRV). If you would like to publish an article in Kermit News #5, please send it in! We're looking for stories about interesting ways you or your organization are using or benefitting from Kermit, technical articles, reviews, and anecdotes. Articles should be about 500 words (rough guideline, we're not strict). The deadline is October 1, 1991. ------------------------------ Date: Sat, 24 Aug 91 01:19:23 MEZ >From: "Gisbert W.Selke" Subject: The Old Curiosity Shop Keywords: MS-DOS Kermit and Arithmetic, PRODUCT Macro, Arithmetic ; File ARITHMET.INI ; Arithmetic for MS-DOS-Kermit! ; Gisbert W.Selke, Aug 1991. ; Share and enjoy. ; ; This collection of macro definitions for MS-DOS Kermit 3.10 (or later) ; was prompted by Chris Gianone's remark: ; "Meanwhile, creative Kermit users will no doubt find their own uses for ; [the PRODUCT macro]". (Using MS-DOS Kermit, 2nd ed., p 182) ; ; Having done some math, I think I *know* what a product is... ; Given that Joe D. has made Kermit with its script language a universal ; Turing machine... There you are. ; ; TAKE this file from the MS-Kermit> prompt; then, you can do calculations: ; tadd <...> : show sum of numbers ; ex: tadd 15 17 yields 32 ; ex: tadd 15 17 19 yields 51 ; tmult <...> : show product of numbers ; ex: tmult 11 13 yields 143 ; ex: tmult 2 3 4 5 yields 120 ; tfact : show factorial of number ; ex: tfact 5 yields 120 ; Macros used internally are explained below. ; ; More importantly, when you're in CONNECT mode and your host sends a ; sequence like "ESC [ 15;7 ~", the product of the two numbers will ; appear on your screen. ; ; Remark: Multiplication can be implemented more efficiently. This is ; left as an exercise for the reader. So are FFT and primality ; testing for large integers. ; ; Uses variables \%a..\%e as arithmetic registers and for passing results. ; ; Elementary operations: ; Increment one-digit number (\%1) by 1; result in \%r, overflow in \%o: def inc1 def \%o 0,if = \%1 0 def \%r 1,if = \%1 1 def \%r 2,- if = \%1 2 def \%r 3,if = \%1 3 def \%r 4,if = \%1 4 def \%r 5,- if > \%1 4 inc1b \%1 ; internal macro for inc1: def inc1b if = \%1 5 def \%r 6,if = \%1 6 def \%r 7,if = \%1 7 def \%r 8,- if = \%1 8 def \%r 9,if = \%1 9 def \%r 0,if = \%1 9 def \%o 1 ; Increment the number in registers \%a..\%e by 1: def inc5 inc1 \%e, ass \%e \%r,if = \%o 0 go e,inc1 \%d, ass \%d \%r,- if = \%o 0 go e,inc1 \%c, ass \%c \%r, if = \%o 0 go e,inc1 \%b,- ass \%b \%r, if = \%o 0 go e,inc1 \%a, ass \%a \%r,:e ; Split multi-digit number into digits, result in \%a..\%e: def split def \%a 0,def \%b 0,def \%c 0,def \%d 0,def \%e 0,- if = \%1 0 go e,set cou \%1,:l,inc5 \%a \%b \%c \%d \%e,if cou go l,:e ; Add \%1 to number in \%a..\%e: def add1 if = \%1 0 go e,set cou \%1,:l,inc5 \%a \%b \%c \%d \%e,- if cou go l,:e ; Add two numbers; result in \%a..\%e: def add split 0,if > \v(argc) 1 split \%1,if > \v(argc) 2 add1 \%2,- if > \v(argc) 3 add1 \%3,if > \v(argc) 4 add1 \%4,- if > \v(argc) 5 add1 \%5,if > \v(argc) 6 add1 \%6,- if > \v(argc) 7 add1 \%7,if > \v(argc) 8 add1 \%8,- if > \v(argc) 9 add1 \%9 ; Multiply number in \%a..\%e by \%1; result in \%a..\%e: def mult1 set cou \%1,ass \%9 \%a\%b\%c\%d\%e,if > \%1 0 go s,split 0,- go e,:l,add1 \%9,:s,if cou go l,:e ; Multiply two numbers; result in \%a..\%e: def mult split 1,if > \v(argc) 1 split \%1,if > \v(argc) 2 mult1 \%2,- if > \v(argc) 3 mult1 \%3,if > \v(argc) 4 mult1 \%4,- if > \v(argc) 5 mult1 \%5,if > \v(argc) 6 mult1 \%6,- if > \v(argc) 7 mult1 \%7,if > \v(argc) 7 mult1 \%8,- if > \v(argc) 9 mult1 \%9 ; Time-honoured practice: a factorial routine: def fact split 1,if = \%1 0 go e,set count \%1,:l,mult1 \v(count),- if cou go l,:e ; user interface macros: calls for macros above, plus display of result: def fatal echo Error: \%1\13, def \%1, stop ; error handler def tinc1 inc1 \%1,echo \%o\%r ; ex: tinc1 5 def tinc5b inc5b \%1 \%2 \%3 \%4 \%5,echo \%a\%b\%c\%d\%e ; ex: tinc5b 1 2 3 9 9 def tinc5 split \%1,inc5 \%a \%b \%c \%d \%e,echo \%a\%b\%c\%d\%e ; ex: tinc5 99 def tsplit split \%1,echo \%a\%b\%c\%d\%e ; ex: tsplit 12399 def tadd add \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9,echo \%a\%b\%c\%d\%e def tadd1 add1 \%1,echo \%a\%b\%c\%d\%e ; ex: split 17, tadd1 15 def tmult1 mult1 \%1,echo \%a\%b\%c\%d\%e ; ex: split 13, tmult1 7 def tmult mult \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9,echo \%a\%b\%c\%d\%e def tfact if not = \v(argc) 2 fatal {TFact takes exactly 1 numeric - argument},fact \%1,echo \%a\%b\%c\%d\%e ; Multiplication per PRODUCT macro: def product mult \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9,- askq \%9 Result is \%a\%b\%c\%d\%e\59 hit RETURN:,connect ; Factorial: def factorial if not = \v(argc) 2 fatal {Factorial takes exactly 1 - numeric argument},fact \%1,askq \%9 Result is \%a\%b\%c\%d\%e\59 - hit RETURN:,connect ; End of MS-DOS-Kermit arithmetic routines. \Gisbert [Ed. - Gisbert, you have done a fine job of demonstrating the power, elegance, user-friendliness, and ease of use of MS-DOS Kermit's script programming language! This breakthrough makes cryptic programming languages like C, Fortran, and BASIC -- not to mention hand calculators -- totally obsolete.] ------------------------------ Date: 16 Aug 91 20:03:50 GMT >From: gumley@ltp.gsfc.nasa.gov (LIAM GUMLEY) Subject: MS-DOS Kermit vs Twincom 9600/V42.bis Keywords: MS-DOS Kermit, Modems G'day people. This is kind of a software question as well but I figured this was the best place to post. I have just installed a Twincom 9600/V42.bis modem in my 386. I have been using Kermit for a while with my previous 2400 baud modem, and was hoping to continue using it with this modem. However I cannot get kermit to 'wake-up' the modem with the AT command. I tried COMMO 4.52 for the same purpose and it worked just fine with no special setup. Scenario: 386 booted with 'clean' MSDOS 4.01 - no config.sys or autoexec.bat. Modem has had dip-switches changed from 246 to 135 - to set COM1 and IRQ4. No changes have been made to the modem NVRAM setup (factory defaults). MS-Kermit 3.10 started with no initialization file. Kermit commands are set port 1 set speed 38400 connect Now when I type AT there is no response. If I start up COMMO, I get a response with AT immediately. If I dial with COMMO and get the modem on-line, I can do a warm re-boot, and Kermit will then talk to the modem normally (as far as I can tell). So I figure there must be something that Kermit is not doing correctly in sensing COM port speed or something. I have tried all the SET PORT and SET COM1 options that the Kermit beware file suggests, but have had no luck. Okay, I could trash Kermit and use COMMO. But I want to use kermit if possible. Cheers, Liam. Liam E. Gumley Research and Data Systems Corporation Disclaimer: Greenbelt MD, USA Opinions I express here are gumley@ltp.gsfc.nasa.gov my own, not the company's. [Ed. - Liam sent this later: "I have some good news. I was playing with the modem again this morning, and I thought "Why not try the DIAL script (hayes.scr) you supplied with MS-Kermit 3.10?" So I shut the computer down, re-booted, started up kermit, then did a DIAL whatever and it came back with: Error: Turn on or connect your modem BUT within a second, it had woken up the modem, and was dialing the number. I changed hayes.scr to have the speed=38400 and to do ATDT tone dialling. Kermit now works fine! I can exit, and re-enter Kermit as usual. I guess that the initialization string output in HAYES.SCR is what does the good deed. So it looks like things are working as they should. Thanks again for your very prompt reply. I've been using Kermit for a few years now because it's the only program I know that maps the DEC-VT keypad satisfactorily - once you get used to it you don't want to change. Heck, I have the little white and gold DEC keypad stickers on my PC keyboard!] ------------------------------ Date: Wed, 21 Aug 1991 10:02:38 -0500 (CDT) >From: Kathy Kothmann Subject: Modem Initialization in MS-DOS Kermit Keywords: MS-DOS Kermit, Modems We have an MS-DOS Kermit question which, although I have consulted Christine Gianone's book on MS-Kermit, I cannot locate the answer. I hope the following excerpts will explain. On Tue, 20 Aug 1991, Peter Ferrara wrote: > > Where does the initialization command go for setting up ms-kermit. I am > > trying a VIVA 2400bps modem and can't get kermie baby to accept it. > > Its initialization command is ATE1V1X4QO&C1&D2 S7=255 SO=O^M > > pferrara@tenet To which I responded: > > Two suggestions: First - edit the mskermit.ini file and put it in > > there. > > But a better alternative is to go ahead and type connect and get into > > terminal mode and then type at . Then type that long > > initilization string and press . Then type ATDT phonenumber. > > > > I think there's a way to customize the kermit files so that it will do > > that for you... will check the manual I bought on MS-Kermit and see. > > Kathy And Peter answered this morning with: > Thanks... I appreciate any help. it seems that our ms-kermit version is > generic and has a real difficult time accepting the "cheap" modems. > Hope to hear from you soon. NOW - I checked the .INI file and couldn't find anyplace to enter that lengthy initialization string nor could I see how to get kermit to enter it after typing CONNECT (which is where I thnk it belongs). What is the easiest way for Peter to get that string sent to his modem? We surely would appreciate some assistance. If there is someone else we should write, please let us know. THANKS, Kathy Kothmann kathyk@tenet.edu [Ed. - Look at MSIHAY.SCR (which is normally renamed to HAYES.SCR). The following sends the modem initialization command. Change it to whatever is needed: output ATQ0V1X1\13 ; Send AT, use word result codes. See your modem manual for details.] ------------------------------ Date: Wed, 21 Aug 91 17:42 BST >From: Alan Grafen Subject: The Wonders of Kermit 0.98(63) and One Little Grouse Keywords: Mac Kermit Dear Kermit People, I've just started using Kermit 0.98(63) for the Mac, and its wonderful. Its cutting and pasting is extremely useful - no mainframe user can afford to be without facilities of this kind. BUT for some reason the clipboard is private to Kermit. I would like to cut from the Kermit window, and paste into a word processor; and then cut from the word processor and paste into the Kermit window. I'm sure this was not intended - and that other people have pointed this out. Please add my voice to those asking for a Mac-wide clipboard in the next release. Kermit is a tremendous public service - please do not construe my letter as a complaint. Keep up the good work. Best Wishes, Alan Grafen [Ed. - This problem should be fixed in the next release. Unfortunately, we are not quite sure exactly when that will be. Watch Info-Kermit for announcements.] ------------------------------ End of Info-Kermit Digest ************************* From cmg Mon Sep 16 16:32:45 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA20318; Mon, 16 Sep 91 16:32:45 EDT Date: Mon, 16 Sep 91 16:32:44 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #5 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Mon, 16 Sep 1991 Volume 14 : Number 5 Today's Topics: MS-DOS Kermit 3.11 is Released! New Second Edition of "Using MS-DOS Kermit" Kermit, TCP/IP, Packet Drivers, and the Future Adding TCP/IP Features to MS-DOS Kermit Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Mon, 16 Sep 1991 14:00:00 EDT >From: Christine M Gianone Subject: MS-DOS Kermit 3.11 is Released! Keywords: MS-DOS Kermit 3.11, TCP/IP, MCGA, Dialing Directory, Windows 3.0 This is to announce the final release of MS-DOS Kermit 3.11 from Professor Joe R. Doupnik of Utah State University, and a new Second Edition of the documentation, "Using MS-DOS Kermit" (see message below). The major new feature of version 3.11 is its built-in support for TCP/IP networking, adapted from parts of the Waterloo TCP package from Erick Engelke of Waterloo University in Ontario. Also included are script language improvements that allow for a much improved DIAL command that can use a plain text file as a dialing directory, and VT220 emulation to fill the gap between VT102 and VT320. And finally, a last-minute, down-to-the-wire improvement: support for high-resolution Tektronix graphics on the PS/2 Model 25 and 30 MCGA video adapter. Give the command SET TERMINAL GRAPHICS VGA to use it (otherwise Kermit thinks the MCGA is a CGA, and uses low-resolution graphics). TCP/IP NETWORKING Why add TCP/IP to Kermit? Many people use both network and serial connections, and until now had to switch between a Telnet program (which doesn't support serial connections) and Kermit (which didn't support Telnet connections). For file transfer, the TCP/IP FTP protocol, while fast, does not support many of Kermit's advanced features. Kermit offers you features not found in Telnet and FTP: a script programming language, flexible key mapping, macros, international character set translation, and VT320 and Tektronix 401x terminal emulation. Perhaps most important of all, now you have a single application program and a common user interface for both serial and network communication. Kermit's TCP/IP and TELNET implementation takes up only about 30K of additional program space. It runs only over Ethernet-style packet drivers (see Joe's article below) available from your network board vendor, or via anonymous FTP from Clarkson University, host sun.soe.clarkson.edu [128.153.12.3], cd pub/ka9q, use "type binary", get the appropriate zip, arc, zoo, etc, files, use PKUNZIP, PKXARC, or ZOO on your PC to unpack them, read the files READ.ME, MANIFEST.DOC, and INSTALL.DOC, and take it from there. Copies are also available on watsun.cc.columbia.edu in kermit/packet-drivers (source and documentation) and kermit/packet-drivers-bin (PC binaries). Kermit supports downloading of its network parameters from BOOTP and RARP servers, making it possible for all users of a corporate or campus network to have the same initialization file -- a big plus for network managers. Keep your network information in a central database, rather than spread around on scattered PC hard disks and diskettes! Kermit's TELNET implementation automatically negotiates TELNET protocol parameters such as local echoing, so connecting to a linemode TELNET server (such as found on an IBM mainframe) works automatically. However, Kermit does not include built-in 3270 terminal emulation, so it is not (yet) a replacement for tn3270. But, it can be used with reverse telnet terminal servers connected to IBM 7171 or other 3270 protocol converters. Contrary to expectations, Kermit *can* make TCP/IP connections from within a Microsoft Windows 3.0 Enhanced Mode window. Kermit does not support multiple simultaneous TCP/IP sessions, and the fact that you can run it under Windows is not, unfortunately, an escape clause to this rule. The packet driver only allows one one application per protocol; this also means, for example, you can't use Kermit and (say) NCSA telnet at the same time for TCP/IP connections. However, you can still have multiple copies of Kermit running, as long as each one is using a different communication method, or a different serial port. Read the new help and beware files for more information about TCP/IP. DIALING DIRECTORY AND MODEM SUPPORT Kermit's new dialing directory is an ordinary plain-text file that Kermit's DIAL macro searches using Kermit's new OPEN, READ, and CLOSE commands. To take advantage of this new feature, make sure you get a copy of the new sample initialization file, MSKERMIT.INI, as well as the Hayes modem dialing script program, MSIHAY.SCR (which you must rename to HAYES.SCR). A sample dialing directory is available as MSIDIA.TXT (which you must rename to DIALUPS.TXT). Kermit can also manage other types of modems besides Hayes. Two steps are necessary: (1) change the definition of the "_modem" variable in MSKERMIT.INI, and (2) write a dialing script program for your modem, to substitute for HAYES.SCR. An example is provided for the IBM/Siemens/Rolm CBX data phone (ROLMphone) in the file MSIROLM.SCR (which you should rename to ROLM.SCR). Readers are encouraged to develop scripts for other kinds of modems and dialing methods, following the conventions used in HAYES.SCR and ROLM.SCR, and send them in to us for distribution. NEW FILES: Internet anonymous ftp EARN/BITNET watsun.cc.columbia.edu KERMSRV@CUVMA Description GENERAL FILES kermit/a/mskerm.hlp MSKERM HLP Help file (plain text) kermit/a/mskerm.bwr MSKERM BWR "Beware File" (bugs & limitations) kermit/a/mskermit.ini MSKERMIT INI Sample initialization file kermit/a/mskermit.pch MSKERMIT PCH Sample patch file kermit/a/msidia.txt MSIDIA TXT Sample dialing directory file kermit/a/msihay.scr MSIHAY SCR Hayes modem dialing script kermit/a/msirolm.scr MSIROLM SCR ROLMphone dialing script EXECUTABLES kermit/bin/msvibm.exe (none) Executable Kermit program for IBM PC kermit/bin/msvibm.pif (none) Microsoft Windows 3.0 PIF file kermit/a/msvibm.boo MSVIBM BOO BOO-encoded .EXE file for IBM PC kermit/bin/msvgen.exe (none) Generic MS-DOS exectable kermit/a/msvgen.boo MSVGEN BOO BOO-encoded .EXE for generic DOS SOURCE FILES kermit/a/ms*.asm, ms*.h MS* ASM, MS* H Microsoft assembler source files kermit/a/msn*.* MSN* * C-language network source files kermit/a/msv*.lnk MSV* LNK Linker command files kermit/a/msv*.mak MSV* MAK Makefiles for "make" All MS-DOS 3.11 IBM PC Kermit files have been removed from the test directories, kermit/test/ms*.* on watsun and T:MS* * on KERMSRV. The ".boo" files for each version are .EXE files encoded in a printable ASCII format, suitable for BITNET, e-mail, and other nontransparent modes of transmission. You can decode the boo-files back into .EXE files using any of the MSBPCT.* programs available in kermit/a/msbpct.* or MSBPCT * from KERMSRV. See msbaaa.hlp for details. For a detailed description of the MS-DOS Kermit file naming conventions, see the file msaaaa.hlp (MSAAAA HLP). The MS-DOS Kermit implementations for non-IBM compatibles (except the generic DOS version) have not yet been upgraded to 3.11 level -- volunteers? Once again, thanks to Joe for his skill, generosity, patience, dedication, perserverence, and endurance (we're running out of adjectives for Joe!) in putting this new MS-DOS Kermit version together and sharing it with us. And thanks to the beta testers who sent in such prompt and detailed reports of problems so Joe could fix most of them so quickly! ------------------------------ Date: Mon, 16 Sep 1991 13:00:00 EDT >From: Frank da Cruz Subject: New Second Edition of "Using MS-DOS Kermit" Keywords: MS-DOS Kermit 3.11, Using MS-DOS Kermit MS-DOS Kermit 3.11 is accompanied by a brand-new revised and expanded Second edition of Christine Gianone's book, "Using MS-DOS Kermit", Digital Press, Bedford, MA, USA (1991), order number EY-H893E-DP, Digital Press ISBN 1-55558-082-3, Prentice Hall ISBN 0-13-952276-X. The book includes a 5.25-inch 360KB MS-DOS Kermit 3.11 diskette. The US single-copy price is $34.95, up $5.00 from the first edition (not bad for 100 extra pages and 6 months work). To order, call (USA, toll free) 1-800-343-8321. It is also available from Kermit Distribution at Columbia University and in software stores and computer bookstores (where you'll recognize it easily by its new purple cover). A German language edition, "MS-DOS Kermit -- das universelle Kommunikationsprogramm, Einfuehrung und Referenz", is published by Verlag Heinz Heise GmbH & Co KG, Hannover, Germany, ISBN 3-88229-006-4, translated by Gisbert W. Selke (proprietor of the Old Curiosity Shop from Info-Kermit V14 #4), 5.25-inch 360KB diskette included, with many of the text files translated into German, price 69 DM. The new edition describes all the new features of version 3.11, including everything that was added in versions 3.01, 3.02, and 3.10. It has a new chapter on local area networks (including TCP/IP); a new appendix with a complete technical description of Kermit's terminal emulator with tables of all the escape sequences recognized and sent by Kermit in both text and graphics mode; expanded descriptions of many of Kermit's features, including printer control and the script programming language, including the new dialing directory features; an improved index. There are also new instructions for running Kermit under Windows and DesqView, for using LK250 keyboards, and there are many new tables, including one for Cyrillic character sets. The new book remains an excellent introduction (Einfuehrung) for the novice, and it is now an even more complete reference (Referenz) for the expert. The first edition of "Using MS-DOS Kermit" was received with unanimous approval by the critics. Some samples from the book reviews: "...one of the finest user guides, commercial, shareware, or otherwise, that this reviewer has had the pleasure of reading." - Tom Nichol, Link-Up, July/August 1990 (p.8) "An excellent introduction to computer communications, [Using MS-DOS Kermit] explains in simple but intelligent language how to set up and get going." "Must-read for PC buffs..." - Anne M. Russell, Working Woman, September 1990 (p.94) "While the book is aimed at nontechnical readers, I highly recommend it to all technical personnel in the computing field, particularly those who abhore software manuals." - William Oblitey, ACM Computing Reviews, V32 #6, June 1991, pp.283-284 Both the English and German versions of the Second Edition should be available in late September or early October. Every copy sold helps support the Kermit development and distribution effort, so don't be shy! ------------------------------ Date: Mon, 9 Sep 1991 20:38 MDT >From: Joe Doupnik Subject: Kermit, TCP/IP, Packet Drivers, and the Future Release 3.11 of MS-DOS Kermit for IBM-PCs and compatibles opens a new communications channel for Kermit: many hundreds of thousands of machines around the world attached to the cooperative Internet network. The lingua franca of that channel is the TCP/IP protocol suite, including the Telnet interactive protocol. This is networking with a capital "N". We have received many requests for Kermit to "talk over the Ethernet" to other machines. The impression held by those unfamiliar with the mysterious art of communications is that one simply puts individual bytes on the Ethernet much as we do with ordinary RS232-C wires. Alas, the opposite is true so it might be worthwhile reading the few paragraphs on this technical matter. Even if you know the Packet Driver story from my Novell activities skim it for a repeat performance now underway with PD + NDIS + ODI. After that I'll mention some items about how Kermit handles Telnet. Ethernet, Token Ring, and similar network transport systems are party lines carrying traffic for many machines and using many different protocols. To keep the traffic flowing to the right places without ambiguity, the data -- our information -- is wrapped in administrative red tape with From: and To: addresses and much more. These ensembles are called packets or frames, and their rules of construction and manipulation are aptly named protocols, not unlike the Kermit protocol itself. IP is one protocol, TCP is a higher-level protocol that uses IP as a shipping agent. Novell has the SPX and (shipping agent) IPX protocols, and so on. Fortunately each of these can share the communications wire, time-sharing the party line, with the others because they obey the same rules for primitive addressing in the outermost wrapping of the packet or frame. That's about all they have in common: they drive on the same side of the road and they recognize traffic lights. The Internet is a massive voluntary interconnection of machines around the world. So not only do we have local addressing to do, but we have to be able to send and receive packets through gateways to distant lands. Interestingly, with TCP/IP we, as people, typically use the names of the machines, but on the wire only a numerical identification is employed. So behind the scenes name server machines have to quietly tell our program the number of the host whenever we use the name. We say NETLAB.USU.EDU but on the wire this machine is known as 129.123.1.11, a 32-bit quantity. As you might imagine, each protocol has its own distinct rules about names and numbers, as if the other protocols did not exist. More alchemy. What we see so far is that sending data bytes over Ethernet involves a lot of busy work preparing packets in just the right format, with the address of both sender and receiver and other vital administrative detail. The wire can carry a large variety of these packets. This means each machine hears all the packets, the network adapter board filters out all but those addressed to the itself (and the broadcasts), and the machine must have code to pick out the packets it wants and to wrap/unwrap (encode/decode) the interior shipping instructions particular to the protocol it understands. Serial RS232-C links avoid all of this because there is only one machine at each end. This brings us to a very local problem to be solved. Our PC might wish to use several protocols simultaneously. For example, a NetWare (or StarGROUP or PATHWORKS) file server is used to provide file service and we also want to use TCP/IP Telnet to log onto a remote machine in Logan, Utah (Logan is always "remote", no matter how close to it one may be). That means both IPX and IP need to share the Ethernet (or Token Ring, etc) communications board, or we will need a board per protocol. Thus the problem is: what hardware or software will we need to use two or more protocols simultaneously? Until a couple of years ago the solution to the problem was to purchase a network adapter board for each protocol in each client machine. Software of one protocol attached to a board and knew how to converse with it (that's a ticklish job known as being a device driver). Pretty soon there were lots of different boards, and one needed to buy software tailored for each one. In many cases, with only one board we had to reconfigure and reboot one's PC in order to switch among different networking applications. FTP Software Inc. of Wakefield, MA, USA, a vendor of PC-based TCP/IP programs, soon went bananas trying to write drivers for each new Ethernet board on the market. They wisely decided that what was needed was a small piece of code, called a Packet Driver, which did all the board-specific functions yet provided a standardized interface (a virtual board) to the application software. They wrote the Packet Driver (PD) Specification, made it public, and suggested that board makers write their own Packet Drivers so that FTP Inc and other software houses could get on with their primary task of creating useful communications programs (see John Romkey's recent article in BYTE magazine). More came of this than they may have realized. Two aspects make Packet Drivers very popular. One is that the programs are tiny, only about 2.5KB, and "relatively easy" to write. Thus software vendors can provide a PD interface as yet one more choice of board and save many tens of thousands of dollars of development effort per product per year, per vendor. That was FTP's intention too: save internal resouces. We benefit by lower software production costs. The second benefit is greater from the perspective of users (vs vendors). That is, the PD specification permits several protocols to call upon it, the owner of a single board, and each receives only the packets it wants. The requesting program thinks it owns a whole board. So a user can run several non-competing protocol stacks (networking software systems) at the same time, each asking for different kinds of packets, yet using only one physical network adapter. For example, Kermit can send a file from a Novell file server to a TCP/IP host, using a single Ethernet board. Now we are getting somewhere! The demand for Packet Drivers became large quickly. Individuals around the world started writing them because board vendors were too slow. Russel Nelson, then at Clarkson University, established a clearing house for user-written Packet Drivers and made them available at no charge. Oh boy, free and available now, available even across the network via anonymous FTP. A personal observation is that the general public, or at least a broadly based non-commercial group, is needed to make a standard take root and prosper; individual companies have their own territory and traditions to contend with. In the interests of completeness I need to mention two roughly similar systems that arose after Packet Drivers. The first is NDIS, Network Driver Interface Specification, by 3Com and Microsoft. NDIS performs the same functions as a Packet Driver, and a few more. NDIS programs are entirely commercial endeavors at present and all are much much larger than Packet Drivers. The most recent addition to the business is Novell's Open Datalink Interface, ODI, also commercial presently and sized between PDs and NDIS. ODI includes more features that the other two. NDIS is used by Lan Manager systems (DEC PATHWORKS, AT&T StarGROUP, 3Com 3+Open, and others); ODI is used only by Novell NetWare at this time. It appears that all three will live side by side for some time to come. But what about this side by side stuff; didn't we just solve that for the network adapter case? Now a new question arises: Can I run TCP/IP with a Packet Driver interface for the program (say Kermit) together with AT&T StarGROUP together with NetWare? Golly, will demands ever end? The answer is: it can be done, easily! FTP Software, again, wrote a small program called DIS_PKT, and I expanded on their effort with a program of the same name. DIS_PKT sits on top of NDIS and provides a Packet Driver interface for programs that want to communicate this way, and it allows NDIS-style programs to use NDIS simultaneously. Dan Lanciani of Harvard has a preliminary program called ODIPKT that lets Novell's ODI material sit on top of a Packet Driver, and Don Provan of Novell has another named PDEther. These little programs are given the trade name of "shims", and for many of us they are worth their weight in gold (saved from buying more LAN adapters, which if you recall, is where we came in). Well, that was an educational diversion. Back to TCP/IP in MS-DOS Kermit. TCP/IP is a mature protocol with many many features. Telnet is a protocol sitting on top of TCP/IP which provides an error-checked terminal-like communications pathway to a host. The software to implement Telnet, and TCP, and IP is complicated and normally fairly large. Erick Engelke at the University of Waterloo, Ontario, Canada, wrote a TCP/IP kernel which was small enough to be considered for inclusion within Kermit itself, rather than relying on programs such as NET14 and TNGLASS coupling to exterior TCP/IP programs. Much work later we accomplished the goal of embedding Telnet plus TCP plus IP plus a good Packet Driver interface within Kermit, for an overall cost of roughly 30KB increase of program size. That's a bargain, folks. Kermit includes procedures to talk with name servers to do that translation of host names to numbers. It has procedures for Kermit to learn its own Internet address from servers of such things, via the BOOTP and RARP protocols. BOOTP can also supply name server addresses, a gateway address, and so on. Name resolution, etc, is all automatic from the user's perspective, and based on the nuts and bolts discussion above it had better be automatic! The performance of built-in Telnet is much greater than the alternative of coupling to an exterior TCP/IP program via BIOS Interrupt 14H, and of course it is far faster than a serial RS232-C connection. All connections require a communications program pay attention to the wire very frequently. LAN connections on Ethernet or Token Ring require even closer than normal attention because packets arrive at incredible rates and will jam up in the LAN adapter unless the communications program lends a hand. So Kermit has a small invisible background procedure to run the Telnet code while Kermit itself sits at the command prompt or is sleeping while you are shelled to DOS. This reduces the clutter of fresh packets when Kermit is not actively seeking them directly and it keeps the host happy. By the way, for the benefit of network managers, Kermit does not send only one data byte in an individual IP network packet. It gathers as many bytes as will fit before a timer expires and exports few network packets. A network monitor shows Kermit file transfer activity to look much like FTP file transfers. I tried to make Kermit be nice to networks, and to their managers. Another issue concerns running Kermit's Telnet path while in Windows 3. The technical problem is the Packet Driver calls on Kermit when each new packet arrives, but Windows may move Kermit about in memory and thus the call goes to the wrong spot (Uh-Oh time). There is a simple solution. Using the PIF editor for a KERMIT.PIF file find the box labeled "Lock Application Memory" in the Advanced Options section. Check it. That says don't move Kermit in memory. The nice consequence is Kermit is able to run in a window of Enhanced Mode, and it will continue to run even when reduced to an icon. Having Kermit use Telnet for local or long distance communication across existing networks raises some interesting points. The usual file transfer program for TCP/IP work is FTP, File Transfer Protocol. Those who use it will tell you it is quick but not exactly smart nor user-friendly. The Kermit file transfer protocol is slower because it is designed for the worst case situation of going from point A to B by many methods. So FTP is faster than Kermit-to-Kermit file transfers on a fast link. But: Kermit can use many kinds of links whereas FTP can't, Kermit can transfer the file time-and-date stamp, it can skip individual files or stop the entire group of files when you wish during a big transfer, it can do character-set to character-set transfers for international language documents, it can rename files to avoid destroying originals, and so on. The process of moving information, not just raw bytes, is more advanced in Kermit than in FTP. In addition, Kermit is driven by user feedback and we respond quickly. FTP is not about to change much in the near future; what you have now is what you will have several years from now. Kermit's advanced features are negotiated between any two Kermits so they always work even if one program is five years older than the other, and runs on a vastly different machine than the local PC. It has been stated many times that there is a Kermit implementation for almost every kind of computer in this world; the size of the Columbia University Kermit archive supports it. These programs are written by individuals, volunteers, on a not-for-profit basis (costs usually are born by them too). New features appear at the rate which we, the volunteers, can create them; the Kermit Project at Columbia exercises overall control so matters remain coherent across Kermit software programs. The popularity of Kermits, their responsiveness to the "marketplace" (i.e., the users), and their ability to work together between almost any pair of machines makes Kermit an good vehicle for advancing the state of the art of information exchange across communications channels. Kermit is not wedded to one communications method or protocol; it uses serial ports and MS-DOS Kermit uses most of the commercially available networking channels. However, adding new features costs: in time, money, and energy of talented and experienced writers. Each major addition, say adding 3270 emulation or advanced Tektronix graphics support to MS-DOS Kermit, becomes a significant project lasting months to years. We are accomplishing with few people (who by the way have regular full time jobs and careers other than Kermit) what commercial software houses do with larger full-time paid staffs. Thus major advances need the support of the entire community, particularly from commercial and government enterprises that benefit so heavily by not having to pay hundreds of dollars per program per copy per year for connectivity. Some companies have been very helpful by providing boards, software, or complete operating environments. Those contributions are much appreciated and needed. A firmer long-term basis is required so we can plan and implement the strategically meaningful advances. Kermit software has saved the corporate, government, and academic sectors countless millions of dollars in its first ten years of existence. As the sophistication and demands of computer users grow, so too does the complexity of the programming task. If Kermit is to continue fill your needs and save you money over the next ten years, let's hope some of the well-endowed corporations and agencies that have done so well by our efforts will think about supporting them in the future. Additional features that many of you are requesting -- more ASCII terminal emulations, multiple host sessions, 3270 emulation, ReGIS graphics, Tektronix 41xx and 42xx graphics, full integration with Windows 3.0, a fancy menu-driven user interface with internationalized locales, etc -- each of these is a massive project requiring additional dedicated programming staff if these features are to be available in a timely fashion. I ask for your understanding when I say that these can't be provided in one or two releases. The existance of strong requests is our reward that we are doing a good job as you see it. ------------------------------ Date: Mon, 09 Sep 1991 18:18:46 EDT >From: Erick Engelke Subject: Adding TCP/IP Features to MS-DOS Kermit Connectivity has come to mean much more than the RS-232 wires and modems that webbed our offices in recent years. Today's networks are connected using a plethora of incompatible networking hardware, systems software and hardware platforms. But under the TCP/IP family of Internet protocols, all these barriers melt away. The newest version of MS-DOS Kermit is capable of dealing with these intelligent, high-performance networks just as easily as it has worked over other communication media for years. The Waterloo TCP (WATTCP) code was developed at the University of Waterloo to simplify creation or adaptation of TCP/IP-based utilities. It uses a simple and well defined application programmer's interface (API) based on a loose adaptation of BSD networking functions. The TCP portions actually execute off the application program's stack. This unusual practice simplifies development and testing by allowing the application and the network functions to all coexist in the same task. One of the first applications written to demonstrate the capabilities of WATTCP was a little program called TCPPORT which let Kermit or most other communications programs be used as a TELNET client. Although it seemed to be merely an academic achievement and totalled less than 100 lines of 'C' code, I started getting a growing quantity of mail from the masses who needed the capabilities of MS-DOS Kermit in a TELNET package. The most common reasons cited were Kermit's international character support, its unmatched emulation capabilities, and Kermit file transfers to machines not supporting FTP. Within days I received a brief message from Frank da Cruz (C-Kermit author) who had found the program and tried it with relative success. To anyone foolish enough to actually implement a TELNET client, there are hundreds of documents (RFCs) which are required reading and nearly one hundred of them are pertinent specifically to TELNET. After much reading you must start the eternal process of testing your version with everyone else's implementation. One of the known problems TCPPORT had was the ability to crash some VMS systems running poor but common TCP/IP implementations. Frank's experience from C-Kermit quickly resolved these and other problems. By this time, Joe (author of MS-DOS Kermit) and Christine Gianone (Important Kermit Person) had entered into our mail conversations and we started discussing how we might incorporate the functionality of TCPPORT right into MS-DOS Kermit. MS-DOS Kermit had always packed an enormous number of features into a pretty small package, but we felt we could add TELNET capabilities without increasing the executable by more than thirty kilobytes. This was a small cost for the enormous benefits. It also a hard promise to keep - we had overlooked some hidden data areas. As soon as he had time, Joe dove right into the project and scrutized every line of my code. Since I had only started the WATTCP project about seven months earlier, there were a number of areas which had not been fully tested or which were incomplete. During the Kermit-ization process, I mostly gave advice and concentrated on the TCP core section while Joe did an amazing amount of work in adapting and occasionally rewriting my efforts to fit his needs. He also acted coordinator, so we did not have to remember what everyone else was doing. Some of the features of my original code were of little use to MS-DOS Kermit, so it became sort of a WATTCP-Lite, actually consuming less than twenty-five kilobytes of the final Kermit executable. Despite the occasional simplification, we kept the API identical to the documented WATTCP API, allowing us to keep our efforts coordinated for future revisions. The process of perfecting the TELNET features was greatly simplified by the Internet itself. Whenver we were told of problems TELNETting to a particular computer, we could KERMIT/TELNET there ourselves and solve the problems without additional help. In fact, we used Kermit to transfer updates to each other. This also allowed us to tune the long-distance capabilities which are essential to a TELNET program. The final product has the benefit of Frank, Christine, obviously Joe, and the many volunteers whose efforts were too numerous to list. This distributed group of people has once again brought MS-DOS Kermit to the leading edge by adding to its description: an excellent TELNET program. Erick Engelke WATTCP Architect Faculty of Engineering University of Waterloo Waterloo, Canada ------------------------------ End of Info-Kermit Digest ************************* From cmg Thu Sep 19 16:00:24 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA02886; Thu, 19 Sep 91 16:00:24 EDT Date: Thu, 19 Sep 91 16:00:23 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #6 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Thu, 19 Sep 1991 Volume 14 : Number 6 Today's Topics: Announcing MS-DOS Kermit 2.32/A for Chinese DOS MS-DOS Kermit 3.11 Questions and Answers Mac Kermit Questions and Answers Kermit Files Slightly Reorganized Character Set Files and Utilities Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Fri, 6 Sep 1991 15:28:00 EDT >From: Quanfang Zhang Subject: Announcing MS-DOS Kermit 2.32/A for Chinese DOS Keywords: MS-DOS Kermit 2.32/A, Chinese DOS I have translated MS-DOS Kermit Version 2.32/A into a Chinese version which is called CC-DOS Kermit (CCKermit, the prompt is Kermit-CC) and can run under either MS-DOS or CC-DOS (Chinese Code DOS). When CC-Kermit runs under MS-DOS, it is exactly the same as MS-DOS Kermit 2.32/A, but when it runs under CC-DOS, all messages on the display are Chinese and the screen display mode is also modified. So if you know Chinese but little English, you can also operate this Kermit successfully. There are a lot of versions of CC-DOS, such as LIANXIAN, STCDOS, CCDOS213, GWCDOS and so on, and among these versions many differences exist in the screen display modes. CC-Kermit can properly run on most CC-DOS versions. In case you find it can't run on your machine, please let me know. I would like to help you and make the program more satisfactory. If you find bugs, please contact me. I am going to do my best on this project as time permits. Quanfang Zhang Computer Network Research Lab Department of Computer Science & Engineering Zhejiang University Hangzhou 310027 PEOPLES REPUBLIC OF CHINA Tel: (571)572244 ext 2400 or (571)761211 Email: BMAZUNET@ICA.BEIJING.CANET.CN [Ed. - Hsei hsei, Quanfang Zhang! Your Chinese DOS Kermit has been added to the "C" area of the Kermit Distribution collection, as files CC*.*. Also, in ~kermit/bin/ on watsun only, the binary executables: ccvibm.exe, and ccvcga.exe (EGA and CGA versions, respectively). The file ccaaaa.hlp gives more information about this version. The other files are organized exactly like the MS-DOS Kermit files. Many thanks for this contribution!] ------------------------------ Date: Thu, 20 Sep 1991 12:00:00 EDT >From: Christine M Gianone Subject: MS-DOS Kermit 3.11 Questions and Answers Keywords: MS-DOS Kermit 3.11 Keywords: Token Ring, OUTPUT Command and MS-DOS Kermit 3.11 Keywords: PC-NFS and MS-DOS Kermit 3.11, SLIP, DIS_PKT Keywords: DEPCA Ethernet Interface, TCP/IP, Packet Drivers There has been an avalanche of mail about MS-DOS Kermit 3.11 over the past few days. Here are the most common questions, and some answers. Much of this is now noted in a slightly updated MSKERM.BWR file. Q: Why can't I pick up the entire IBM PC 3.11 distribution in one file? A: See the message on this topic in Info-Kermit V4 #2 about this. However, by popular demand, the IBM PC version of MS-DOS Kermit 3.11 is now available for binary-mode FTP from watsun as a ZIP archive: kermit/bin/msvibm.zip. This file contains all the files that are on the distribution disk, plus a copy of the Digest announcement. Thanks to Joe Doupnik for putting the ZIP archive together! Q: I got MSVIBM.BOO from Kermit Distribution, and it was the Sept 6 version, rather than the Sept 7 version. A: As of 8:15PM EDT, Sept 17, MSVIBM.BOO is the correct (Sept 7) version. Those who picked up this file before that time should replace it. The Sept 6 version cannot be patched. The Sept 7 version fixes this problem. The kermit/bin/msvibm.exe file on watsun was correct, however, and need not be replaced. Q: My old script program doesn't work any more. All my OUTPUT commands, which I abbreviated to "O", stopped working. A: Version 3.11 includes a new OPEN command, so O is no longer a sufficient abbreviation for OUTPUT. Make sure all your OUTPUT commands are abbreviated to at least "OU", and your OPEN commands to "OP". Q: Why can't I make a TCP/IP connection with Kermit when I am also running PC-NFS? A: Because the packet driver allows each protocol (such as ARP, RARP, IP, UDP, IPX, etc) to be used by only one application at a time. This is a limitation of packet drivers. Q: Why can't Kermit make TCP/IP connections over SLIP, Appletalk, or Token Ring packet drivers? A: Because the code for this has not been written. Kermit only knows how to talk to Ethernet-class (Class 1) packet drivers. Support for the others, as well as built-in support for ODI and NDIS, are major development efforts. Q: I can't make Kermit work with the Clarkson DEPCA.COM packet driver and a DEC DEPCA Ethernet board. A: We have had several reports like this. So far nobody has reported success with this one. Make sure you read the installation instructions for the DEPCA packet driver -- it needs several special command-line parameters, and care must be taken that the default hardware interrupt number, 5, is not already used by some other device on your PC, like a disk drive or a printer port. If anybody has had success with the DEPCA, please send a report. Q: I can't get Kermit to make TCP/IP connections with the Harvard ODIPKT driver on a Token Ring network. A: This would require additional coding in Kermit to understand Token Ring framing. Kermit does work with ODIPKT over Ethernet. Q: I can't assemble the file MSNTNI.ASM. I get three errors "Cannot address with segment register". A: This error occurs with newer releases of Microsoft MASM. A new copy of the file MSNTNI.ASM has been installed that corrects this error, but which does not change the Kermit program in any way, and still works with MASM 5.0. Q: Where do I get DIS_PKT? A: (Msg from Joe Doupnik): There are two DIS_PKT'S, mine and FTP Software Inc's. Mine is in an archive named DIS_PKT.TXT (uuencoded) or DIS_PKT.ZIP (same, PKZIP'd) on my VMS VAX, NETLAB.USU.EDU 129.123.1.11 in directories [.NOVELL] and [.NETWATCH]. FTP Inc's archive is named DIS_PTK.GUP (a nonsense phrase so we can tell apart our two renditions) on their VAX, VAX.FTP.COM. I know mine works fine with almost everything, particularly AT&T StarGROUP. My archive has a long how-to section with three example setups. Recall that configuring Lan Manager material is a fine art. Fortunately adding DIS_PKT is really simple (one line in CONFIG.SYS, a half dozen in PROTOCOL.INI). My samples show choices for WD8003E, 3C503, and AT&T EN100 boards. Feel free to raid my cookie jars. Q: Why does the new MSKERMIT.INI give lots of error message when used with the generic DOS Kermit version, MSVGEN.EXE? A: It doesn't any more. An updated version of MSKERMIT.INI is now available, which tests to make sure it is executing on an IBM PC or compatible before it tries to execute IBM-specific commands like SET TERMINAL. ------------------------------ Date: Thu, 20 Sep 1991 13:00:00 EDT >From: Christine M Gianone Subject: Mac Kermit Questions and Answers Keywords: Mac Kermit I have had literally thousands of inquiries about Mac Kermit in recent months, many more than I can answer personally. Let me try to summarize the situation very briefly for everybody. Q: Why doesn't (cut and paste, printing, etc etc etc etc etc) work in 0.97(57), 0.98(63), 0.99(91), etc etc etc? Why doesn't Mac Kermit work right under System 7? Why are the fonts messed up? Why isn't parity restored when I launch from a settings file? Why do settings files created by different releases of Mac Kermit not call up the appropriate release when I open them? Why are the key mappings for certain keys like Ctrl-@ messed up? How do I type international characters? Why doesn't flow control work? Why does Mac Kermit always hang up when I quit? etc etc. A: The last official release of Mac Kermit was 0.9(40). Any version with a higher number is a test release, to be used at your own risk. The new Mac OS, System 7, came out after 0.9(40) and seems to have broken several of Mac Kermit's features. Q: When will we see a new release of Mac Kermit? A: Soon, I hope. Our previous Macintosh volunteer programmer, Paul Placeway, has retired from Mac Kermit development after several years of hard work and invaluable contributions. Several new developers have recently come forward, but it will take some time to come up with a new release that has the features you want, works with a wide range of Macintosh models, keyboards, and systems, and is well documented. In the meantime, we have a very comprehensive list of bugs to correct and features to add, and this work is in progress. Watch Info-Kermit for announcements of test releases. ------------------------------ Date: Thu, 20 Sep 1991 13:00:00 EDT >From: Christine M Gianone Subject: Kermit Files Slightly Reorganized Keywords: Kermit Distribution Due to the increased space required by MS-DOS Kermit 3.11, several Kermit versions were moved from the "A" area to the "C" area (primarily the Atari and CP/M-86 versions). Also, several other Kermit versions were moved from the "B" area to the "D" area -- long-discontinued systems like the DEC-20 (where Kermit was first developed) and the DEC-10. Several obsolete and redundant Kermit versions were totally retired. If anybody notices that they are missing and suffers for it, they can be resurrected. A complete list of the moves and changes can be found in the file AAVERS.UPD, the AAV*.HLP files have been updated to show the new locations, as has AAFILES.HLP. ------------------------------ Date: Wed, 18 Sep 1991 20:14:12 EDT >From: Christine M Gianone Subject: Character Set Files and Utilities Keywords: Character Set Files and Utilities, PostScript, Cyrillic A new directory has been set up on watsun only: kermit/charsets. The files in this directory are not part of the normal Kermit distribution, and they do not follow the normal naming conventions. But they should prove useful to Kermit users who want to use or learn about text files containing national and international characters. Included in the kermit/charsets directory are character set tables for many character sets, which include the character names, values in decimal, octal, hex, and row/column notation, and the 8-bit character values themselves. Most of these tables (e.g. cp437.txt, cp850.txt, latin1.txt, next.txt, etc) were produced by C programs (cp437.c, cp850.c, etc), so if you can't transfer the 8-bit text successfully, get the corresponding C program, compile it, and run it to recreate the character set table. Also included is a program, textps, for converting plain text containing 8-bit characters to PostScript. The original file can be in any of several character sets including Latin-1, various IBM code pages, Apple QuickDraw, NeXT, DEC MCS, etc. You can use this program on any UNIX system, MS-DOS, VAX/VMS, and any other computer that has a C compiler and supports the idea of standard input and output redirection. Thanks to Frank da Cruz for the character set programs, tables, and the textps program. Finally, the files cp866.doc and cp866.uue contain a Cyrillic code page (real Cyrillic characters) you can use on your PC if it has an EGA or higher and DOS 3.30 or higher. This was contributed by Dimitri Vulis of the City University of New York. cp866.doc tells how to install the code page. Once your Cyrillic code page is installed, you can display cp866.txt (the Cyrillic code page table) on your screen locally from DOS, you can use DOS applications to create and view Cyrillic files, etc. MS-DOS Kermit 3.10 and later supports CP866 as a file transfer character set, and you can also use your Cyrillic code page during during terminal emulation with any of three commonly used Cyrillic host character sets: ISO 8859-5, KOI-8, or Short KOI. Kermit initialization files, from Konstantin Vinogradov of the International Centre for Scientific and Technical Information in Moscow, are provided for this purpose in the files kermit/charsets/*.ini. The organization and naming of the files in this area is subject to change. Meanwhile, additional contributions to this collection of character set tables and utilities are most welcome. ------------------------------ End of Info-Kermit Digest ************************* From cmg Wed Sep 25 11:58:15 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA11541; Wed, 25 Sep 91 11:58:15 EDT Date: Wed, 25 Sep 91 11:58:13 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #7 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Wed, 25 Sep 1991 Volume 14 : Number 7 Today's Topics: New IBM Mainframe Kermit Release Announcing IBM Mainframe Kermit-370 Version 4.2.2 List of Supported Front Ends for Kermit-370 Announcing IBM Mainframe Kermit-370 for CICS Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.2 Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.2.2 ROSCOE Kermit Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Tue, 24 Sep 1991 14:25:32 EDT >From: Christine M Gianone Subject: New IBM Mainframe Kermit Release Here comes a battery of announcements from John Chandler of the Harvard/Smithsonian Center for Astrophysics in Cambridge, Massachusetts, for IBM Mainframe Kermit-370 version 4.2.2 for the major IBM mainframe operating systems. Most notable among these is a brand new version for CICS, which can be used under either MVS or DOS/VSE. People have been asking for this for nearly ten years! Now they can shave off their long white beards... The new files are in ~kermit/b/ik*.* on watsun for anonymous FTP over the Internet, and on BITNET/EARN as IK* * from KERMSRV at CUVMA. Included are brand new versions of the user manuals in plain-text (.DOC), "line printer" with carriage control (.LPT), and PostScript (.PS), one for each major version: IKCKER (VM/CMS), IKTKER (VMS/TSO), and IKXKER (CICS). Also included are detailed installation instructions (the IK*KER.INS files) and other documentation (.HLP, .BWR, etc). Each version comes in two parts: the system-independent part (IK0), and the system-dependent part (IKC, IKT, IKX). You have to get both parts: ftp watsun BITNET/EARN cd kermit/b KERMSRV@CUVMA VM/CMS ik0*.* and ikc*.* IK0* * and IKC* * MVS/TSO ik0*.* and ikt*.* IK0* * and IKT* * CICS ik0*.* and ikx*.* IK0* * and IKX* * Many thanks to John and to all the contributors and beta testers for these significant new Kermit releases. Now, if only somebody will produce a Kermit program for the AS/400, and Systems /34, /36, and /38, we will have Kermit programs for all the major IBM machines and operating systems. ------------------------------ Date: Monday, 1991 August 19 14:08 EDT >From: "John F. Chandler" Subject: Announcing IBM Mainframe Kermit-370 Version 4.2.2 Keywords: IBM 370 Kermit Xref: IBM Mainframe, See IBM 370 Kermit-370 version 4.2.2 is now available for CMS, TSO, and CICS. The changes are primarily generic, but there are also some system-specific updates in each variant. See the accompanying system-specific announcements for the details: IKCKER.ANN (CMS), IKXKER.ANN (CICS), and IKTKER.ANN (TSO). The most important of the generic updates are: 1) New "CC" option along with the line range for sending files. This option specifies that the file has carriage control in column 1 and that it should be converted to ASCII control characters. 2) More careful avoidance of built-in packet-size limits. 3) V-binary (or D-binary) file transfers work all the way up to records of 64K-1 bytes. 4) Leaving server mode if packet I/O errors recur. 5) More liberal recognition of STOP commands in protocol mode. 6) Extra explanatory error message, if available, now displayed upon completing a subcommand, along with basic status. Also, any reason for cancellation is included in the E-packet text and noted in the transaction log. 7) Time tags in transaction and packet logs. 8) New TRANSPARENT transfer character set, which applies a null translation to all incoming and outgoing files. 9) New SET TTABLE KP option which enables a full 8-bit translation table based on Hollerith codes. 10) Proper control-quoting on 8-bit analogs of ordinary control characters. 11) Suppression of echoing on LU1 3770-type front ends. 12) New VERSION subcommand, which displays the version number and date. 13) New "End-of-attributes" attribute. 14) 8th-bit quoting for the XECHO subcommand. The new release is in the form of updates to be applied to the 4.2 source. The updates are cumulative, so they include those that were already released to make version 4.2.1. In addition, the generic 370 part of the User's Guide has been updated to reflect version 4.2.1. Many thanks to the beta testers who have helped work out the bugs. ------------------------------ Date: Tuesday, 1991 August 20 19:40 EDT >From: "John F. Chandler" Subject: List of Supported Front Ends for Kermit-370 Keywords: IBM 370 Kermit and Supported Front Ends There is a new version of IK0AAA.HLP to go with release 4.2.2 of several variants of Kermit-370, and this seems like a good time to summarize the changes in the list of supported "front ends". Here is the list of new entries added since the version of April 1990, complete with references to footnotes in the new list. The types shown are the abbreviation of the relevant controller types in Kermit-370. Those marked (3) are still questionable, i.e., the reports were not conclusive. Of the additions, only one (the IBM 3174 AEA) represents an enhancement of Kermit itself; the others are simply new reports or changes in the status of the "front end" software. In this time span, there have not been any new reports of UNsupported front ends, just a reconfirmation of the limitation of the IBM 3708 to linemode Kermit transfers. Name, model Type Manufacturer Notes -------------- ---- ------------------------- ----- Amdahl 4705 T Amdahl (2) Datalynx 3174 G Andrew Data Systems (3) Datalynx 3274 G " (3) IBM 3174 AEA A IBM (6) IBM 3745 T " (2) Jupiter 1000 T Intel (14) K200 T Fibronics (14) K310 T " (14) K2000 T " (14) Renex PCM G Renex Corp (8) Renex RPAD G " (8) SIM3278 TCP/IP S Simware (1,4) SIM3278/VM S Simware (1,4) STNxx T STRTC (13) tn3270 S Greg Minshall (1,2,11) For the complete list of supported configurations, and for the footnotes, see IK0AAA.HLP in the Kermit distribution. ------------------------------ Date: Monday, 1991 August 19 14:08 EDT >From: "John F. Chandler" Subject: Announcing IBM Mainframe Kermit-370 for CICS Keywords: IBM 370 Kermit, CICS Kermit Xref: CICS Kermit, Also see IBM 370 There is now a variant of Kermit-370 for CICS. The new Kermit has been tested under releases 1.7 and 2.1 of CICS and with CICS running under both VSE and MVS. This is a full-function Kermit, like other variants of Kermit-370, but is still a test program, since it has not been subjected to any large-scale testing, and several planned refinements have not yet been implemented. Kermit-CICS is both a traditional interactive Kermit and a CICS program that can be invoked to carry out a specific file transfer or group of transfers and then quit. Thus, it is suitable both for "open" CICS systems where the users are permitted to log in as "operators" and controlled systems where all activity is performed through menus. Kermit-CICS surmounts the lack of a real CICS file system by managing its own storage directories assigned to specific users, where each directory has members described by eight-character names; the assignment of directories is done according to an algorithm chosen by the local installer. In addition, Kermit supports transfers of TD and TS queues. The initial version is release 4.2.2 and includes a number of enhancements that are also appearing in the new releases for CMS, TSO, MUSIC, and ROSCOE. However, these enhancements are not listed here, since this is the first version of Kermit-370 for CICS. See the relevant announcements for more details. Work on Kermit-CICS is continuing, but some of the tasks necessary for making it a full-fledged production program have not even been started. Features that need to be improved or added include: - IKXDYNAL for both CICS/VSE and CICS/MVS. The former would probably support only spool files, but the latter should support both spool files and MVS data sets. - Sample exit routines for supporting userid algorithms besides the OPID and TERM options. - Sample package of security exit routines. - Enqueuing on extra-partition TD names before opening. - Support for data objects on a remote CICS. - Cleaner performance of server-mode BYE function, dependent on local conventions. - Support for indirect TD queues. - Testing linemode operation. - Mechanism for flushing terminal output from Kermit (such as from the TYPE subcommand). - Mechanism for collecting "terminal" output from invoked programs. - Testing under CICS/VM. Anyone interested in working on these or other improvements should first get in touch with the Center for Computing Activities at Columbia University to find out if someone else has already begun a similar project (and, if so, who). ------------------------------ Date: Monday, 1991 August 19 14:08 EDT >From: "John F. Chandler" Subject: Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.2 Keywords: IBM 370 Kermit, VM/CMS Kermit Xref: CMS Kermit, See VM/CMS Kermit, IBM 370 Kermit Kermit-370 version 4.2.2 is now available for CMS. As usual, the new version comes in VM/SP and VM/XA/SP flavors, but the changes are the same for both. Version 4.2.2 has numerous improvements over 4.2.1, but many of them are generic (shared among all the variants). See the accompanying generic Kermit-370 announcement for more details. The most important of the CMS-specific updates are: 1) New, more flexible on-line help facility with a separate file available for each subcommand. This can be used in connection with the CMS help menu system or with Kermit's internal help processor (or both). The old-style, single help file is also still available. 2) Improved recovery from a "stolen" screen, fullscreen I/O errors, the classical VTAM lockup at the start of a SEND (caused by having too long a SEND delay), or a 4994 buffer overrun. 3) Kermit-CMS now invokes CMS commands in a way that closely matches the behavior of commands entered directly to CMS. A more complete description of the changes can be found in IKCKER.BWR. The new release is in the form of updates to be applied to the 4.2.0 source. The updates are cumulative, so they include those that were already released to make version 4.2.1. In addition, the help file has been revamped, and the User's Guide has been partly updated (but not actually brought up to date with 4.2.2). The new files are IKCKER.UPD, IKCKER.BWR, IKCKER.MSS, IKCKER.DOC, IKCKER.LPT, IKCKER.PS, IKCKER.HLP, IK0KER.MSS, IK0AAA.HLP, and IK0KER.UPD (the latter is only a catalog of all the updates, not the updates themselves). The new code has been tested pretty thoroughly (many thanks to the beta testers!), but problems may still turn up. Bug reports are welcome, as usual. In particular, reports of any kind are needed for the new facility for supporting 8-bit transfers in line mode -- this has barely been tested. A similar release 4.2.2 is also available for TSO and CICS -- see the corresponding announcements. ------------------------------ Date: Monday, 1991 August 19 14:08 EDT >From: "John F. Chandler" Subject: Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.2.2 Keywords: IBM 370 Kermit, MVS/TSO Kermit Xref: TSO Kermit, See MVS/TSO Kermit, IBM 370 Kermit Kermit-370 version 4.2.2 is now available for TSO. The new version has numerous improvements over 4.2.1, but many of them are generic (shared among all the variants). See the accompanying generic Kermit-370 announcement for more details. The TSO-specific updates are: 1) Correct UNIT selection for new datasets uploaded to TSO. This fixes a bug introduced with version 4.1. 2) Multiple subcommands allowed on the initial invocation command line, provided the Kermit delimiter is defined in one of the initialization files. 3) Current status code available to CLIST's as &LASTCC. A more complete description of the changes can be found in IKTKER.BWR. The new release is in the form of updates to be applied to the 4.2.0 source. The updates are cumulative, so they include those that were already released to make version 4.2.1. In addition, the help file has been revamped, and the User's Guide has been partly updated (but not actually brought up to date with 4.2.2). The new files are IKTKER.UPD, IKTKER.BWR, IKTKER.MSS, IKTKER.DOC, IKTKER.LPT, IKTKER.PS, IKTKER.HLP, IK0KER.MSS, IK0AAA.HLP, and IK0KER.UPD (the latter is only a catalog of all the updates, not the updates themselves). The new code has been tested pretty thoroughly (many thanks to the beta testers!), but problems may still turn up. Bug reports are welcome, as usual. In particular, reports of any kind are needed for the new facility for supporting 8-bit transfers in line mode -- this has barely been tested. A similar release 4.2.2 is also available for CMS and CICS -- see the corresponding announcements. ------------------------------ Date: Fri, 1991 Mar 29 22:04 EST >From: "John F. Chandler" Subject: ROSCOE Kermit Keywords: IBM 370 Kermit, ROSCOE Kermit Xref: ROSCOE Kermit, Also see IBM 370 Xref: MVS/TSO Kermit, Also see IBM 370 I have stored two new files on WATSUN: IKRKER.BWR and IKRKER.UPD. These constitute the collection of all known tips, fixes, and workarounds for running TSO Kermit under ROSCOE. This is not what I would call a full- fledged new variant of Kermit-370, since ROSCOE Kermit is only slightly changed from "vanilla" TSO Kermit. Hence, installers of ROSCOE Kermit will still need to fetch all IKT*.* files and follow the instructions in IKTKER.INS with only a few alterations based on IKRKER.BWR. If further reports come in, I'll add them to the collection. Also, I would be glad to include code updates, especially if some user should feel motivated to add support for native ROSCOE files or other ROSCOE-specific features. John ------------------------------ End of Info-Kermit Digest ************************* From cmg Tue Oct 1 17:01:44 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA02956; Tue, 1 Oct 91 17:01:44 EDT Date: Tue, 1 Oct 91 17:01:43 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #8 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Tue, 1 Oct 1991 Volume 14 : Number 8 Today's Topics: New Patch File for MS-DOS Kermit 3.11 New Serial Printer Driver for MS-DOS Kermit Printing from MS-DOS Kermit on a Novell Printer Problems with DOS 5, DesqView, and MS-DOS Kermit Running MS-DOS Kermit 3.11 under DesqView MS-DOS Kermit 3.11 and Packet Drivers DEPCA Success with MS-DOS Kermit 3.11 MS-DOS Kermit 3.11 Packet Size Problem with TCP/IP Kermit 3.11 TCP/IP Connections Dropping PC Kermit 3.11 Q&A: A Small Correction Something Good in DOS 5.0 for MS-DOS Kermit MS-DOS Kermit Keyboard Problems MS-DOS Kermit and Hebrew? MS-DOS Kermit and Horizontal Scrolling? Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Sun, 29 Sep 91 21:35:02 EDT >From: "Joe R. Doupnik" Subject: New Patch File for MS-DOS Kermit 3.11 Keywords: MS-DOS Kermit 3.11 Patches Here is a new patch file containing patches 1 to 4 for MS-DOS Kermit 3.11, IBM PC version. Patch 1 (optional): Supply an alterate video mode for the Orchid Designer Professional VGA board when switching from 80 to 132 columns. Patch 2: Correct unwanted double echo from TCP/IP Telnet negotiations. Patch 3: Correct cursor indexing problem with scrolling region setup. Patch 4: Correct nested curly brace matching in Kermit commands. Joe D. [Ed. - Thanks, Joe. The new patch file is in kermit/a/mskermit.pch on watsun (Internet) and MSKERMIT PCH on KERMSRV@CUVMA (BITNET/EARN). To apply these patches, store this file in the same directory as your MSKERMIT.INI file and uncomment the PATCH command in your MSKERMIT.INI file.] ------------------------------ Date: Tue, 1 Oct 91 12:00:00 EDT >From: Christine M Gianone Subject: New Serial Printer Driver for MS-DOS Kermit Keywords: Printers, Serial Printers, MS-DOS Kermit and Serial Printers One of the most common questions about MS-DOS Kermit is how to use it with a serial printer. In the words of Joe Doupnik: "MS-DOS Kermit prints by sending material straight to DOS. It does so by gathering up to 128 bytes in a buffer, sends an XOFF to the host (if flow control is being used), does a buffer write to DOS, and then sends an XON to the host. In the buffer writing process there are also checks on whether DOS thinks the printer is ready and that all the characters were accepted, etc. "By using DOS rather than the IBM PC BIOS interrupts or even particular hardware we gain the ability to write the code once for many kinds of machines, remove a mountain of code necessary to manipulate either serial or parallel ports (if they exist), and most importantly we can write to networked printers and print-to-disk TSRs and whatnot. We can also change the name of the print channel used by Kermit from PRN to any legal DOS name (SET PRINT command)." But DOS does not include any provision for flow control with a serial printer (parallel printers do this in hardware, automatically). Therefore it is common to have printing problems when your communication speed with the host is faster than your printer's speed. The solution is to install a printer driver that provides the needed flow control between the PC and the printer. Joe Doupnik recently found such a (public domain) utility and sent it in. Originally called XONXOFF.COM, it was written by Frank Whaley in 1989. It works only for COM1, so it would be nice if somebody fixed it to allow any COM port (address and IRQ) to be specified on the command line. It can be picked up from Kermit Distribution as kermit/a/mspspd.* on watsun (Internet) or MSPSPD * from KERMSRV on CUVMA (BITNET/EARN). The files are mspspd.asm (the assembler source file), mspspd.hlp (a help file), and mspspd.boo (a "boo" encoding of the binary .COM file). Also, on watsun only, the binary .COM file is available in kermit/bin/mspspd.com. ------------------------------ Date: Mon, 16 Sep 91 14:29 EST >From: Clement Lepoutre Subject: Printing from MS-DOS Kermit on a Novell Printer Keywords: Printers, MS-DOS Kermit and Printers, Novell Networks We have a PC which is hooked up to an old Novell network system. It connects to our mainframe where the person does some lists. We have been able to print those lists on the networked printer but get some errors at higher speeds (e.g. 9600). In other words, at 9600 the whole list does not get printed whereas at 1200 the list comes out fine. We feel the higher speed is too fast for the network or Kermit to handle. Is there something settable in Kermit for it to take a larger or smaller hunk of information before it gets sent to the printer? We would like to work at a speed faster than 1200, obviously. Thanks for any suggestions. [from jrd - Plan A: It's neither the network nor Kermit having the problem, but rather the PC. Whatever is doing the printing on the PC is keeping interrupts off for long periods and that prevents the serial port from notifying Kermit that a new character has arrived. The slower the machine the more likely this will be. I try very hard to avoid this specific problem by first buffering characters within Kermit, up to 128 of them, then when the buffer fills I first tell the host XOFF, then ask DOS to print them, finally tell the host XON. If you have turned off flow control in Kermit then these hold-ups are not sent. If you use a print spooler in the PC to pass information to the printer then (a) that spooler will eat lots of CPU cycles, alas, and (b) it may do so well after Kermit has done the stop/print/start work. If this is the case then please don't use the spooler (the DOS PRINT command is such a beast too). Another case is using a printer on a serial port and the serial port driver is consuming the machine so that Kermit's port can't get through. In that case try a different serial port driver, or use a parallel port. Beware of having TSRs present which consume lots of CPU cycles. Plan B: If the "mainframe" in your message is an IBM one, and your connection to it is a half-duplex linemode connection, flow control can't be done. The only workaround in this case is to send printed material to your disk instead of to the printer (SET PRINTER filename) and later print the file by ordinary means. Without flow control, the mainframe will easily overrun the printer.] ------------------------------ Date: Thu, 12 Sep 91 19:25:34 MEZ >From: Erich Neuwirth Subject: Problems with DOS 5, DesqView, and MS-DOS Kermit Keywords: MS-DOS 5.0, MS-DOS Kermit and DOS 5.0 Keywords: DesqView, MS-DOS Kermit and DesqView I have problems with MS-DOS Kermit since I installed DOS 5. Not under plain DOS, but when I am running DesqView under DOS 5. I tried DesqView 2.31 and DesqView 2.34, and in both cases it does not work. (Additionally I am running QEMM 5.11, I do not yet have a later version.) When I open a DesqView window containing Kermit the machine simply hangs and does not accept any keyboard input any more. Even Ctrl-Alt-Del does NOT work, so I really have to switch off. The problem occurs both with Kermit 3.10 and Kermit 3.11. The problem also occurs when I use TAME (i.e. TAME-RES.COM) before running Kermit. My machine is a Mycomp 25 MHz 386 with 4 MB of memory and an AMI BIOS. Usually I have not experienced any compatibility problems. Am I alone with this kind of problem or are more people experiencing something similar? [Ed. - Later, Erich writes:...] The DesqView people solved my problem, and you might be interested in the solution. You have to set Optimize communications in the Advanced Setup menu to NO. Then it works. The manual, though, states, that then you might have problems with higher baud rates (4800 and higher). Since currently I am running at 2400 bps, this is no problem. ERICH NEUWIRTH BITNET (EARN): A4422DAB@AWIUNI11 INTERNET: A4422DAB@VM.UNIVIE.AC.AT Institute for Statistics and Computer Science UNIVERSITY OF VIENNA, UNIVERSITAETSSTR. 5/9, A-1010 VIENNA, AUSTRIA ------------------------------ Date: 23 Sep 91 16:48:18 GMT >From: w8sdz@rigel.acs.oakland.edu (Keith Petersen) Newsgroups: comp.binaries.ibm.pc.archives,comp.os.msdos.desqview Subject: Running MS-DOS Kermit 3.11 under DesqView Keywords: DesqView, MS-DOS Kermit and DesqView I am running MS-DOS Kermit v3.11 in a DESQview window. It takes more memory than the previous version but works fine for me. Change a Program Program Name............: Kermit COM2 Keys to Use on Open Menu: KR Memory Size (in K): 265 Program...: \bin\kermit.exe Parameters: take kermit2.ini Directory.: \incoming Options: Writes text directly to screen.......: [N] Displays graphics information........: [N] Virtualize text/graphics (Y,N,T).....: [N] Uses serial ports (Y,N,1,2)..........: [2] Requires floppy diskette.............: [N] Change a Program Advanced Options System Memory (in K).......: 0 Maximum Program Memory Size (in K)..: Script Buffer Size.......: 0 Maximum Expanded Memory Size (in K): 0 Text Pages: 1 Graphics Pages: 0 Initial Mode: 3 Interrupts: 00 to FF Window Position: Maximum Height: 25 Starting Height: 20 Starting Row...: 5 Maximum Width.: 80 Starting Width.: 40 Starting Column: 5 Shared Program Pathname..: \dv\noff.shp Data......: Close on exit (Y,N,blank)......: [Y] Uses its own colors..............: [Y] Allow Close Window command.....: [N] Runs in background (Y,N,blank)...: [Y] Uses math coprocessor..........: [N] Keyboard conflict (0-F)..........: [0] Share CPU when foreground......: [Y] Share EGA when foreground/zoomed.: [Y] Can be swapped out (Y,N,blank).: [N] Protection level (0-3)...........: [0] In AUTOEXEC.BAT I have this, to minimize Kermit's use of memory: set KERMIT=ROLLBACK 0 Keith Petersen Internet: w8sdz@rigel.acs.oakland.edu or w8sdz@vela.acs.oakland.edu Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND ------------------------------ Date: Sat, 21 Sep 91 06:36:36 EDT >From: Russ Nelson To: Info-Kermit@watsun.cc.columbia.edu Subject: MS-DOS Kermit 3.11 and Packet Drivers Keywords: Packet Drivers, MS-DOS Kermit 3.11 and Packet Drivers Keywords: DEPCA Ethernet Interface, TCP/IP Q: Why can't I make a TCP/IP connection with Kermit when I am also running PC-NFS? A: Because the packet driver allows each protocol (such as ARP, RARP, IP, UDP, IPX, etc) to be used by only one application at a time. This is a limitation of packet drivers. A2: Strictly speaking, it's a limitation of protocol stacks. You can only run one protocol stack per node. Otherwise, you'll have problems, e.g. which TCP/IP stack would answer ICMP messages? Q: I can't make Kermit work with the Clarkson DEPCA.COM packet driver and a DEC DEPCA Ethernet board. A: We have had several reports like this. So far nobody has reported success with this one. A2: The DEPCA.COM packet driver version 9.0 is known to fail on Turbo DEPCAs (DE-200), and old DEPCAs. There is an interim release of it that fixes the Turbo DEPCA problem on sun.soe.clarkson.edu, in pub/ka9q called depca.com. I am working on reverse-engineering the differences between the new and old DEPCAs, so eventually it will be made to work on the old DEPCAs also. [Ed. - Thanks, Russ! More about the DEPCA below...] ------------------------------ Date: Mon, 23 Sep 1991 13:19 +1200 >From: "John Davis" Subject: DEPCA Success with MS-DOS Kermit 3.11 Keywords: Packet Drivers, MS-DOS Kermit 3.11 and Packet Drivers Keywords: DEPCA Ethernet Interface, DEC Pathworks, TCP/IP, DIS_PKT >Q: I can't make Kermit work with the Clarkson DEPCA.COM packet driver and > a DEC DEPCA Ethernet board. > Well, you now have at least _one_ success story :-) I just ftp'd MS-DOS Kermit 3.11 and installed it on my machine, which runs one of the older DPECA's (full length, 8 bit model - predates the current LC/TURBO models). I'm using the v9.1 clarkson DEPCA driver (which does work even though it doesn't really support the older card - only probs are the ethernet address is set to a ridiculous number, and promiscuous mode doesn't work), installed on interrupt 0x7e (as SOSS requires that interrupt vector for the packet driver), card is set for IRQ=5, IO=300h, and full 64K of memory at D000:0000. This setup works just fine with NCSA telnet, and after filling in the appropriate section in MSKERMIT.INI it also works fine with MS-DOS Kermit 3.11... John Davis - CHEM194@csc.canterbury.ac.nz (Depart)mental Programmer,Chemistry Department University of Canterbury, Christchurch, New Zealand [Ed. - From a similar message from Robert L. Divany, : "Old and new DEC cards seem to be referred to collectively as DEPCA cards, even though they are quite different. DEC refers to the new cards as Etherworks controllers. The DEPCA packet driver was released at about the end of 1990, and was based on specifications supplied to Clarkson by DEC. A note from DEC is included with the Clarkson PD distribution in a file named DEPCA.NOT. Quoting from that file, "The Driver supports our most current technology, and not, unfortunately, older DEPCA's". In spite of this, I have used the Clarkson DEPCA driver from release 8 and 9 with success on some, but not all, new DE cards and on an older DEPCA (series E02) card. I have used release 9.1 of the driver with success on ALL DE and DEPCA cards tested. This includes the DE100 LC card, the DE200 Turbo, the DE210 Microchannel card and older DEPCA cards, both series D and E. I suggest that version 9.1 of the driver be tried if earlier versions fail. Note that version 9.1 is not the same as the driver supplied with the last release of the packet driver collection (version 9). Version 9.1 is available for anonymous FTP from SUN.SOE.CLARKSON.EDU in /pub/packet-drivers/depca.com. Be sure to use binary (Image) mode."] [Ed. - And from Andy Evans, Plymouth State College, Plymouth, NH : "I have more than 100 of the 'old' DEPCA cards on our campus. We have site license for PathWorks V4.0 and I picked up DEC's Client TCP/IP package for evaluation. It contains just what you are looking for, an NDIS driver for that card. Packet-Drivers run quite nicely with it, and I haven't found a Packet Spec. application that didn't! If you chose to run just packets, you can retain 605K+ of low DOS memory on a 386 with Quarterdeck. This is the only way I've successfully run TCP/IP on that card (DEC's driver). The full implementation of DEC's Client TCP/IP is a bit of a memory hog. Allows redirection of disks (file services) and printers - a big plus. DEC's TCP/IP NDIS suite was written by someone else (3COM / Hewlett Packard) When I had some initial bugs the folks in Atlata (DEC Tech Suppt) expressed dissatisfaction with it and the fact a replacement might be considered (by DEC). In time I have grown to like it, Packet Drivers over NDIS with DIS_PKT.DOS works quite well. We are heavy Kermit users and have been enjoying the new version regardless of communication protocol - it does 'em all doesn't it!??!!"] ------------------------------ Date: 24 Sep 91 17:20:26 GMT >From: ccastd2@prism.gatech.edu (Dale Phurrough) Subject: MS-DOS Kermit 3.11 Packet Size Problem with TCP/IP Keywords: Packet Drivers, MS-DOS Kermit 3.11 and Packet Drivers Keywords: TCP/IP, MS-DOS Kermit 3.11 and TCP/IP, Packet Length I remember the problem in 3.10 with packet sizes using the Ungermann Bass ports and such. Does this problem persist in 3.11 using the packet drivers with the TCP/IP port? It seems to. I had to reduce my sending packet size to 128. My receive packet seems to be OK at any size. Any ideas out there? [From jrd - Kermit will try to fill a TCP packet, about 512 bytes of data, until a short timer expires. A straight UB connection gets offered up to 512 bytes of data (or to the end of a Kermit packet). The indications are some part of your UB network cannot stand such long packets. That is also true of some other terminal-like network pathways, such as LAT and TES, at roughly 256 and 512 bytes respectively. And they too are able to send longer material to us than vice versa. The reasons are in the way those pieces of software are designed; they expect more terminal activity than long file transfers.] ------------------------------ Date: 25 Sep 91 00:33:24 PST >From: "Terry McKiernan" Subject: Kermit 3.11 TCP/IP Connections Dropping Keywords: TCP/IP, MS-DOS Kermit 3.11 and TCP/IP I'm having a problem maintaining MS-DOS Kermit 3.11 TCP/IP connections. Can you lend a hand? Here is my setup: MS-DOS Kermit (MSVIBM) 3.11, from watsun.cc on September 19. various PCs, XTs, ATs HP EtherTwist 10-baseT adapters, HP hubs NetWare 3.11, TCPIP.NLM loaded, rip=yes, forward=yes BYU packet-driver IPX v. 2.01 Clarkson packet driver v. 9.0.0 Internet connection via PS/2 ethernet-to-token bridge (AIX) The problem is, we can make connections to Internet sites, but as soon as we connect, the connection is dropped. The "connected" screen appears for a split second (clear screen, status bar at bottom, beep), then the connection drops and we are back at the MS-Kermit> prompt. [From jrd - I don't want to create wrong ideas by speculating, but it is possible the NetWare 3.11 server is not transmitting all the packets in both directions. That is typically a subnet mask error. I have not yet had a chance to route TCP through my NW 3.11 server so I offer this only as speculation.] ------------------------------ Date: Tue, 24 Sep 91 00:54 PDT >From: Denis DeLaRoca Subject: PC Kermit 3.11 Q&A: A Small Correction Keywords: Packet Drivers, MS-DOS Kermit 3.11 and Packet Drivers Keywords: Token Ring, SLIP, TCP/IP The latest Kermit digest contains a very useful Q&A summary for the newly released TCP-based PC-Kermit... it points out that it doesn't run on SLIP or Token Ring Packet drivers as framing for those protocols has not yet been implemented in the TCP/IP code. True for the SLIP case and only half true for the TR case. The current TR PD is a "fake" Ethernet driver (type=1) and thus quite compatible with the TCP/IP code in Kermit! -- Denis DeLaRoca UCLA Office of Academic Computing [Ed. - Thanks, Denis. Many people said this. Yes, Kermit does indeed work over the IBMTOKEN.COM packet driver because IBMTOKEN.COM is an Ethernet class driver. But it does not work over Token-Ring class packet drivers, nor over ODIPKT over Token Ring.] ------------------------------ Date: Mon, 23 Sep 1991 10:56 GMT-0200 >From: Petri Kaukasoina Subject: Something Good in DOS 5.0 for MS-DOS Kermit Keywords: MS-DOS Kermit and DOS 5.0 Keywords: National Keyboards, MS-DOS Kermit and National Keyboards Keywords: MS-DOS 5.0, "Keyboards, National" Xref: DOS 5.0, See MS-DOS 5.0 In previous versions of DOS the foreign keyboard program KEYB caused trouble. Kermit could not receive all characters if the keyboard was used at the same time. But in MS DOS 5.00 the bug does not exist! (By the way, I don't have extended memomy, so I do not use the new memory managament capabilities of DOS 5.) ------------------------------ Date: Sat, 24 Aug 1991 19:11:20 GMT >From: s33672e@puukko.hut.fi (Mikko Leino) Subject: MS-DOS Kermit Keyboard Problems Keywords: National Keyboards, MS-DOS Kermit and National Keyboards Keywords: "Keyboards, National" I have 2 problems here: 1) How can I put a '|' -character into a "set key"-definition? ex. set key \2323 get file.txt "| less" ^^^ the above example results in a "v"-character instead of "|". [Ed. - Such a SET KEY command works on US keyboards, so this is probably an artifact of your Finnish keyboard or driver. Instead of using a literal vertical-bar character, insert its character code \124. If that doesn't work, you might also have to give the command SET TRANSLATION KEY OFF.] 2) Is it possible to make Kermit go to command line from interactive mode? ie. if you enter the command "connect" you enter into the interactive mode, but it seems that you cannot return. [Ed. - The normal advice is: "Type Ctrl-] followed by the letter C to return to the prompt". But with certain national keyboards or drivers, it is physically impossible to type the Ctrl-] combination, however there is usually some other key combination that generates the same code. Ctrl-], Kermit's normal escape character, is ASCII code 29. On the German keyboard, for example, this may be entered by typing Ctrl-+ (hold down the Ctrl key, marked "Strg" on the German keyboard) and press the plus (+) key. On IBM PCs and compatibles, you can also escape back by holding down the Alt key and pressing the lowercase letter 'x'.] Mikko Leino s33672e@puukko.hut.fi ------------------------------ Date: Sun, 1 Sep 91 19:33:12 +0200 >From: oren alex Subject: MS-DOS Kermit and Hebrew? Keywords: Hebrew, MS-DOS Kermit and Hebrew Is there a way to use Hebrew characters (8-bit) in Kermit's VT emulation? I tried the translation table feature - no go. [Ed. - Yes, it can be done. First, your PC must have a Hebrew code page loaded (CP862?). Second, you must construct a file on your PC of the form: SET TERMINAL CHARACTER-SET TRANSPARENT SET TERMINAL BYTESIZE 8 SET TRANSLATE INPUT \xxx \yyy SET TRANSLATE INPUT \xxx \yyy ... SET TRANSLATE INPUT ON SET TERMINAL DIRECTION RIGHT-TO-LEFT In the SET TRANSLATE INPUT commands, \xxx is a host character code (for example, in the ISO 8859-8 Latin/Hebrew Alphabet) and \yyy is a PC character code to translate it into. You need one of these commands for each Hebrew character and other 8-bit character. If you have a Hebrew keyboard, you can make a SET KEY command for each Hebrew key to make it translate the PC key code into the corresponding host character code before transmission. This technique works for any code-page / terminal-character-set combination that is not directly supported by MS-DOS Kermit, such as Cyrillic, Greek, etc. The only thing that is particular to Hebrew (and Arabic) about this example is the command SET TERMINAL DIRECTION RIGHT-TO-LEFT. Complete examples of how to do this for Cyrillic character sets can be found in the *.ini files in the kermit/charsets directory on watsun (Internet only). MS-DOS Kermit does not yet support Hebrew text file translation during file transfer.] ------------------------------ Date: Mon, 9 Sep 91 15:10:12 PDT >From: "Trevor Warwick" Subject: MS-DOS Kermit and Horizontal Scrolling? Keywords: 132 Columns, MS-DOS Kermit and 132 Columns, Horizontal Scrolling My PC (a DEC VAXmate) doesn't support 132 column mode, and I guess that quite a few older PCs, as well as newer laptop/portable PCs also only support the simple video modes. It would be very useful if MS-DOS Kermit had a way of scrolling the screen from side to side. So, when presented with a line that is longer than 80 characters, it would be nice if you could press a key and see the text that has disappeared off the right hand edge of the screen, and be able to modify it. The model is of the terminal screen as a window which you move over the text that is actually on the larger underlying surface. [Ed. - This is actually a common request, and falls into the category of "better support for 132 column mode" mentioned in the wish-list section of the MS-DOS Kermit 3.11 announcement. This would be a major undertaking, as would the various other possible solutions for the EGA and VGA. The wish-list for MS-DOS Kermit is long, and many of the items on it are major development projects. At this point, the best way to get these features into Kermit is to encourage your company to fund the Kermit development effort.] ------------------------------ End of Info-Kermit Digest ************************* From cmg Thu Oct 24 12:13:53 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA17894; Thu, 24 Oct 91 12:13:53 EDT Date: Thu, 24 Oct 91 12:13:52 EDT From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #9 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Thu, 24 Oct 1991 Volume 14 : Number 9 Today's Topics: Announcing Kermit for Microsoft Windows 3.0 Announcing a New Release of HP-3000/MPE Kermit Recent Kermit Protocol Extensions Kermit News Articles MS-DOS Kermit and DR DOS Release of Additional Kermit-12 Utilities Re: New Serial Printer Driver for MS-DOS Kermit Flow Control for IBM Mainframe Half Duplex Connections MS-DOS Kermit Speed Under MS-Windows Kermit Packet Length Fluctuations Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Tue, 22 Oct 91 12:00:00 EDT >From: Christine M. Gianone Subject: Announcing Kermit for Microsoft Windows 3.0 Keywords: Windows 3.0, Kermit for Windows Written by Bill Hall, Santa Clara, CA, specifically for Microsoft Windows 3.0, announced for testing in Info-Kermit V13 #5, June 1991. Since no complaints have been received, this version has been moved into the "A" area, replacing the previous version of Bill's Windows Kermit program, which works only under Windows 2.0. This is not MS-DOS Kermit, but a completely different program. It uses the point-and-click Windows user interface, and it runs in a window in Real, Standard, and Enhanced modes of Windows 3.0 on any model PC or PS/2 that supports Windows 3.0, and emulates the VT52, H19, and VT100 terminals. The program is the subject of an article written by Bill in the January 1991 issue of Microsoft Journal: "Adapting Extended Processes to the Cooperative Multitasking of Microsoft Windows". The new version of Windows Kermit lacks many of the advanced features of MS-DOS Kermit: VT220/320 emulation, key mapping and macros, international character sets, Tektronix graphics, long packets, sliding windows, script programming, network support, etc, but some of these items are on Bill's list for future releases. The files are in kermit/a/wk*.* on watsun.cc.columbia.edu (Internet) and are available as WK* * from KERMSRV at CUVMA on BITNET / EARN. First get the file wkaaaa.doc (WKAAAA HLP), read it, and then decide which other files you need to get. The old version of this program, which is still required for Windows 2.0, has been moved to kermit/c/win*.* on watsun (WIN* * on CUVMA). Thanks once again to Bill for this excellent contribution! ------------------------------ Date: Tue, 22 Oct 91 12:01:30 EDT >From: Christine M. Gianone Subject: Announcing a New Release of HP-3000/MPE Kermit FROM: Tony Appelget General Mills, Inc PO Box 1113 Minneapolis, MN 55440-1113 Apparently my contribution of HP3000 Kermit has hit the streets. I am getting complaints, mostly because sites do not have current SPL compilers. Since I first sent you my updated version of HP3000 Kermit, we have obtained HP Spectrum machines. Although Kermit did not fall flat on its face, problems arose and I fixed them. It is time for me to send you an update. Enclosed on this disk are the following: This letter. My HP3000 Kermit source. My HP3000 Kermit object. The object file is straight classic HP3000 code, ready to run. It has not been BOOed or otherwise been made eye-readable. I assume that you have the facilities to readily do that conversion if you choose. I have run the classic HP3000 code through HP's OCTCOMP processor and the resulting code file seems to be well-behaved on a Spectrum machine. (Signed) Tony Appelget [Ed. - Many thanks, Tony! The new files are on watsun.cc.columbia.edu in kermit/d/hp3*.* for Internet access, and available as HP3*.* from KERMSRV at CUVMA on BITNET/EARN/CREN. The .OBJ file has been converted to hex format, which should be easily decodable: each 2 bytes are the hexadecimal encoding of an 8-bit byte. Ignore line ends. A binary copy of the object file is in kermit/bin/hp3000.obj (watsun, Internet only).] ------------------------------ Date: Tue, 22 Oct 91 12:02:00 EDT >From: Frank da Cruz Subject: Recent Kermit Protocol Extensions Keywords: Kermit Protocol, Character Sets, International Character Sets Keywords: Compression For the past several years, Kermit programs have been appearing that translate character sets during transfer of text files. This is necessary because of the many different incompatible encodings used for national and international (non-ASCII) characters on different kinds of computers. The protocol extension that specifies exactly how this is done has been undergoing continuous revision and refinement. The current description can be found in the file kermit/e/isok6.txt (ISOK6 TXT on BITNET KERMSRV). Some background can be found in an excellent paper by Andre' Pirard of the Universite de Liege in Belgium, kermit/e/pirard.txt (PIRARD TXT on KERMSRV). To increase the efficiency of 8-bit text file transfers through 7-bit connections, a locking-shift option has been added to the Kermit protocol. This is documented in the file kermit/e/lshift.txt (LSHIFT TXT on BITNET KERMSRV). The next major effort in Kermit protocol expansion (no commitment expressed or implied!) is the addition of an effective and portable compression method. We're in the information-gathering phase now. The method that is finally chosen must be single-pass, in the clear legally (unlike LZW, which is tied up in patent infringement litigation, or MNP-level-whatever, which is licensed commercially), well-behaved and effective for all types of data (7-bit text or 8-bit text in any language, binary executables, numeric data, raster images, etc), relatively easy to program, and not horrendously consumptive of CPU cycles or memory. For maximum transportability, the result of compression should be a sequence of 7-bit ASCII printable characters (32-126 or a subset of these). Suggestions, pointers to specifications for various methods and analyses of them, etc, would be most appreciated. ------------------------------ Date: Tue, 22 Oct 91 12:01:00 EDT >From: Christine M. Gianone Subject: Kermit News Articles Come on, send in those articles! We're not going to publish the next issue of Kermit News until we have some good ones. I'm looking for interesting stories about Kermit -- how it is being used in different countries, industries, and different sectors of the economy; what role has it played in recent historic events; why was it chosen over other alternatives, what features are especially attractive or useful, etc, as well as amusing anecdotes, technical contributions, reviews of recent Kermit releases, etc. Kermit News is a real journal, ISSN number and all. Get published! ------------------------------ Date: Sat, 12 Oct 91 3:59:16 EDT >From: Charles Lasner Subject: MS-DOS Kermit and DR DOS Keywords: DR DOS, MS-DOS Kermit and DR DOS There is a cosmetic problem with DR DOS 5 (early and late) and DR DOS 6 whereby the OS doesn't do an automatic CR/LF when the application terminates so therefore the KERMIT prompt gets overlayed with the DOS prompt. Otherwise all works very well. DR DOS 6 can deliver even more memory than DR DOS 5 and certainly much more than MS-DOS 5 or any version depending on your hardware. Without resorting to an admitted "trick" of memory management, DR-DOS can deliver 627K out of 640K to the user program (on 386 systems using EMM386.SYS) and 628K on C&T NEAT-chipset 286 systems. This seemingly high number is because pieces of DOS reside in either upper memory or high memory or both. MS-DOS KERMIT runs fine in all of these configurations. The real trick is when you enable the so-called memmax +v option, whereby the video buffer is mapped into the physical space where some of the upper memory lives, thus allowing the remapping of live memory space at A000 and up. The net result is that the machine grows to a whopping 724K (yes, that's 1024=1K units!), but all of the video's graphics modes are disabled. "well-behaved" software believes that your video hardware is now a CGA only, complete with the minimal CGA graphics modes, but all of the extended modes go away. My machine is a 20 MHz "King of Neat" system with an Ahead Systems 1 Meg VGA. All of the extended modes (1024x768x16 or 256, 800x600x16 or 267, 640x480x256) and all of the normal VGA and EGA modes just disappear. Yet, the VGA ROM is still present (and also RAM shadowed for speed). Applications seeking these modes find only the CGA stuff. Needless to say, many applications are incompatible with this much memory, but fortunately MS-DOS KERMIT isn't one of them. It's real cute to run KERMIT, then do a PUSH to DOS to find out that you still have over 600K beneath you! [From jrd - Interesting. Both MS and DR DOS are making some progress. The current version of QEMM/386 takes this further by reusing the area occuppied by some ROMS (video, system, some others) with no, zero, loss of functionality. It's called Stealth mapping. I advise all memory mappers (people) to never put anything in video display areas because that belongs to the video system and may/will be used by programs. Simpleminded ideas about video modes determining a video display adapter are for the birds so my advice is still sound.] ------------------------------ Date: Thu Oct 10 1991 12:00:00 EDT >From: Charles Lasner Subject: Release of Additional Kermit-12 Utilities Keywords: .BOO, PDP-8, PDP-12, VT-78, DECmate, OS/8 Xref: DEC PDP, See PDP This is a release of companion utilities to KERMIT-12 for the purpose of enhancing file distribution. Two areas are addressed: 1) Initial program acquisition, 2) Binary file encoding. 1) Utilities are provided to create and load copies of KERMIT-12 "on the fly" from a server such as a remote time-sharing system or a local PC on the other end of a "clean" connection to the PDP-8. Unfortunately, most PDP-8 family systems lack a communications predecessor to KERMIT-12. Most communications applications were limited to terminal emulation only, so it is rare that any PDP-8 system has an existing utility sufficient to acquire KERMIT-12. (Of course some sites have prior versions of KERMIT-12 already.) Assuming an error-free serial connection to the other system, it is possible to down-load KERMIT-12 directly into the PDP-8 memory without a protocol. This is similar to the process used for years by DEC field service to load paper-tape copies of diagnostics. Loading is limited to a single PDP-8 field at a time. Performing several load operations yields intermediary image files which can be combined into K12MIT.SV identical to the release version (except for irrelevant loading artifacts which is a consequence of the operating system itself). The format chosen for Initial Program Load (.IPL) is an encoding that yields ASCII files that should pass through any system with ease. The scenario of loading is assumed to be either direct system-to-system, or between a remote system and one of its terminals. All control characters (such as CR and LF) are ignored, thus the encoded files contain frequent line breaks to make the encoded file pallatable to the serving system. Strictly lower-case letter messages are added at the beginning and end of the file to serve as leader trailer fields as well as file documentation. Please note that while spaces are insignificent, the rest of the ASCII character set is used for loading information, so editing of .IPL files must scrupulously avoid changes to the "body" of the file. A simple program (K12IPL.PAL) is provided for .IPL loading of a single field. The user must customize it for local requirements, and then enter two variant forms of the loader. (Future releases could require additional variants to be created. The current release occupies two fields.) This process is similar to customizing the communications requirements of KERMIT-12 itself. The program is sufficiently small to allow manual entry into the system debugger (ODT) directly. Examples of such an entry session are provided as K12IP0.ODT and K12IP1.ODT. The source program may also be retyped by any available means (TECO, EDIT, etc.) if desired. Only standard PDP-8 peripherals are supported such as KL8E, KL8-JA, etc., as opposed to KERMIT-12 itself which supports various DECmate communications hardware as well. It was felt that the greatly increased complexity of supporting the DECmate communications ports would make this process too unwieldy. However, it is possible to load the data through the DECmate's printer port. The VT-78 and all prior PDP-8 models are fully supported. Distribution files include K12FL0.IPL and K12FL1.IPL which are the encoded copies of field zero and field one respectively. K12IPL.DOC is a discussion of the .IPL encoding format itself. K12IPG.PAL is the utility used to create K12FL0.IPL and K12FL1.IPL from the standard release file K12MIT.SV. (K12MIT.SV is itself distributed in encoded form as K12MIT.ENC and now also K12MIT.BOO (see below). K12IPG can be used with other programs for similar purposes if required.) 2) Utilities are provided for encoding and decoding arbitrary OS/8 files using the popular .BOO format encoding scheme. .BOO format should be compatible across dis-similar systems thus avoiding intermediary "hazards." While quite popular in the MS-DOS world for file distribution purposes, .BOO format as originally designed has an inherent weakness that makes reliable use on OS/8 family systems impossible. I have designed an extension to the format to make .BOO format sufficiently reliable to allow implementation of an encoder and decoder for OS/8 systems. Note that ENCODE format is still the format of choice for file distribution because of its more robust nature, but the shorter files created by a .BOO encoder may be desirable in certain circumstances. .BOO format files cannot pass through WPFLOP "paths" to distribute files on DECmates or VT-78, so ENCODE format is mandatory on systems used this way. The relevant problem with .BOO format has to do with file length anomalies that are a consequence of the format itself. .BOO files either end on a repeat compression field or a complete three-byte data field expressed as four characters, each only six bits significant. Should a file end with only one or two eight-bit data bytes, two or one additional null bytes will be appended to pad out the last data field. This leads to files that are one or two bytes longer than intended. At least this is the behavior on systems like MS-DOS which maintain a file byte count. Since OS/8 files are multiples of whole records, each of which can be viewed as a collection of 384 bytes, any change in a file's length of even a single extra null byte will cause the creation of an extraneous whole record. Besides wasting space, it is conceivable that an OS/8 file corrupted in this manner could actually be dangerous to use! Note also that this problem can be cumulative in that repeated transmission between systems where the file is stored locally in some decoded form, and then encoded locally before transmission to another site, can cause the problem to worsen indefinitely. Clearly, .BOO format must be firmed up to prevent this form of file corruption before it can be used safely on PDP-8 systems. (It has also been noted that widely distributed .BOO encoding programs exist on certain systems which exhibit defects such as erroneous appendage of additional null bytes onto the end of the file not indicated by the file's contents. This is clearly a program bug and not an inherent problem with .BOO format design.) The method chosen to correct the existing .BOO anomaly is to append a correction field to the end of every file requiring it. The basic correction unit is ~0 which means literally a repeat compression field with a count of zero. This construct is ignored by most .BOO decoders because it contributes nothing to the file. (At the bare minimum, .BOO decoders should implement the robustness of ignoring this type of data. It is conceivable that due to design error, a decoding program could "blow up" when encountering this data. Imagine a file lengthened by 2^32 null bytes! The exact amount of extraneously generated null bytes would likely be 2^{how many bits wide are integers on the machine} or one less than that.) .BOO-encoded files may now contain either ~0 or ~0~0 at the end to indicate whether one or two bytes are to be "taken back" respectively. Tests on MSBPCT.BAS and MSBPCT.C as currently distributed by CUCCA indicate that these corrections are perfectly ignored, thus decoded files are erroneously inflated by one or two bytes. This is the expected behavior of these older decoders. When used with PDP-8 DEBOO.SV (distributed in source form as K12DEB.PAL), the correct file length is maintained. PDP-8 ENBOO.SV (distributed in source form as K12ENB.PAL) is the first encoding program that creates the correction field as necessary. It is hoped that this "pioneering" effort will cause other systems' encoders and decoders to be similarly updated. Overall program operation for the encoder and decoder is identical to the equivalent programs for ENCODE format. Documentation is contained in the source files. As in the ENCODE format decoding program, the target file name can be taken from the original file name imbedded within the file, or optionally the user can specify a target file name as well as a target device. When encoding, the imbedded file name will always be the original name of the file supplied as input to the encoder. The user can specify any valid combination of output file name and device for the resultant encoded file. OS/8 files passed through ENBOO/DEBOO are packed/unpacked according to the standard OS/8 "3 for 2" scheme to ensure byte accuracy where relevant. This allows files which are ASCII, but too "delicate" for ordinary transfer to be sent between unlike systems with total accuracy. This includes any file where the precise placement of CR and LF may be critical, or contains unusual characters in the file such as BEL or ESC. A perfect example of this is the interchange of TECO macros between PDP-8s (used with OS/8 TECO.SV) and IBM-PCs (used with MS-DOS TECO.EXE) with a unix system as an intermediary storage site. Both end systems use like line termination schemes incompatible with the intermediary system. Since both systems support .BOO format, the files can still be sent without loss. Most of the existing K12MIT-related files are unchanged. K12MIT.DSK is updated to reflect all new files pertaining to .IPL or .BOO utilities. K12MIT.ANN and K12MIT.UPD are updated per this announcement. All files distributed in ENCODE format are replicated in .BOO format. The new files have been installed in the regular places: BITNET/EARN Internet KERMSRV@CUVMA watsun.cc.columbia.edu Description K12MIT ANN kermit/d/k12mit.ann Announcement of KERMIT-12 K12MIT UPD kermit/d/k12mit.upd Release update (this) file K12MIT DSK kermit/d/k12mit.dsk Description of RX02 diskettes K12IPL PAL kermit/d/k12ipl.pal .IPL loading program K12IP0 ODT kermit/d/k12ip0.odt ODT session creating IPL0.SV K12IP1 ODT kermit/d/k12ip1.odt ODT session creating IPL1.SV K12FL0 IPL kermit/d/k12fl0.ipl .IPL encoding of K12mit (FL0) K12FL1 IPL kermit/d/k12fl1.ipl .IPL encoding of K12mit (FL1) K12IPG PAL kermit/d/k12ipg.pal .IPL-format encoding program K12IPL DOC kermit/d/k12ipl.doc Description of .IPL format K12ENB PAL kermit/d/k12enb.pal .BOO-format encoding program K12DEB PAL kermit/d/k12deb.pal .BOO-format decoding program K12MIT BOO kermit/d/k12mit.boo .BOO encoding of KERMIT-12 K12PL8 BOO kermit/d/k12pl8.boo .BOO encoding of PAL8 Ver B0 K12CRF BOO kermit/d/k12crf.boo .BOO encoding of CREF Ver B0 K12GLB BOO kermit/d/k12glb.boo .BOO encoded TECO file macro [Ed. - Thanks, Charles! Additional information can be found in the new file, k12mit.not (K12MIT NOT), a message from Charles to the "PDP-8 lovers" mailing list.] ------------------------------ Date: Tue, 01 Oct 91 19:40:40 EDT >From: "Roger Fajman" Subject: Re: New Serial Printer Driver for MS-DOS Kermit Keywords: Printers, Serial Printers, MS-DOS Kermit and Serial Printers > But DOS does not include any provision for flow control with a serial printer > (parallel printers do this in hardware, automatically). Therefore it is > common to have printing problems when your communication speed with the host > is faster than your printer's speed. The solution is to install a printer > driver that provides the needed flow control between the PC and the printer. This is only partly true. XON/XOFF flow control is not supported, but the IBM PC and compatibles support hardware flow control on serial printers. In order to use it, you must have a printer that will drop some control signal on the RS-232 interface when it wishes to stop incoming data and an appropriately wired null modem cable. Many serial printers can be configured to drop DTR (Data Terminal Ready) on a buffer nearly full condition. A suitable null modem cable for such a configuration is wired as follows: 20 (DTR) to 5 (CTS), 6 (DSR), 8 (CD) 5 (CTS), 6 (DSR), 8 (CD) to 20 (DTR) 2 (TD) to 3 (RD) 3 (RD) to 2 (TD) 7 (SG) to 7 (SG) 1 (PG) to 1 (PG) (optional) Not all of these connections are strictly necessary, but I like to make them this way because it makes the cable symetrical and works in a lot of situations. Roger Fajman Telephone: +1 301 402 1246 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV ------------------------------ Date: Wed, 02 Oct 91 09:11:18 -0400 >From: Joe Morris Subject: Flow Control for IBM Mainframe Half Duplex Connections Keywords: Printers, Serial Printers, MS-DOS Kermit and Serial Printers Keywords: IBM Mainframes and Flow Control, Flow Control and IBM Mainframes In INFO-KERMIT 8.14, Clement Lepoutre (CJLEPOUTRE@FAIR1.BITNET) reports having problems while printing through Kermit to a local printer. The problem is that while the printer is cheerfully doing its thing, the data arriving from the host overflows the buffers and drops into the bit bucket. > Is there something settable in Kermit for it to take a larger or smaller > hunk of information before it gets sent to the printer? We would like to > work at a [comm line] speed faster than 1200, obviously. Thanks for any > suggestions. To which Joe Doupnik replied, including the tag note: > Plan B: If the "mainframe" in your message is an IBM one, and your > connection to it is a half-duplex linemode connection, flow control can't > be done. The only workaround in this case is to send printed material to > your disk instead of to the printer (SET PRINTER filename) and later print > the file by ordinary means. Without flow control, the mainframe will > easily overrun the printer. I haven't used it for years (mainly because we've got only one async line for line-mode users...and I think it was last called in 1988) but there's a zap for the 37x5 EP and PEP code which can provide flow control for IBM half-duplex systems *if* you can deliver EIA flow control (RTS/CTS) to the mainframe port. It's marketed by COMM-PRO Associates in Manhattan Beach, CA. In our case we're running a Sytek async LAN, and it can be set up to take XON/XOFF at one end of a path and deliver CTS/RTS on the other. It's not a perfect solution, but given half-[duplex] ASCII architectural limitations it resolved our problems. (We needed it because the Sytek net does speed translation, and we had to support local users at 9600 BPS and dial users at 300 BPS on the same port. It worked.) ------------------------------ Date: Tue, 15 Oct 91 10:21:51 EDT >From: H W Payne Subject: MS-DOS Kermit Speed Under MS-Windows Keywords: Windows 3.0, MS-DOS Kermit and Windows 3.0 In the July 25th, Kermit Digest issue I made a comment that using MS-DOS Kermit, MS-DOS 4.01 and MS-Windows 3.0 causes the native win3 comm driver to max out at 9600 bps. This note was referring to the following configuration: telephone link PC Comm Port <---> MNP modem <-------------------> MNP modem <-----> SUN OS 386 PC V.42 link with workstation MNP 3, 4 or 5 Both modems are identical and are rated for 9600 bps. Kermit was used to set the PC's Com Port speed to 19,200 bps. The PC is a 386 (25 MHz) with an asynchronous communications element (VL16C452) which is programmable to 1.8 MHz. After talking with many people I still can NOT get the modems to talk to each other at 19,200 bps. How can I get 19,200 bps between the two modems with a third party driver? E.W.Carlson, how did you do it? [Ed. - We have attempted to make contact with E.W. Carlson too, but so far no response. We observe the same effect on a 386SX (PS/2-55SX) -- it has to flow-control the host at 19200, but seems to keep up at 9600. On a regular 386 (PS/2-70) it does keep up at 19200.] ------------------------------ Date: Fri, 11 Oct 91 15:47:51 -0400 >From: "Blaise M. Barney" Subject: Kermit Packet Length Fluctuations Keywords: Packet Length, Kermit Protocol Why would kermit quit sending packet lengths of 1000 (specified with both the set send packet-length 1000 and set receive packet-length 1000 commands) and drop down to about 90? This occurs after approximately ten minutes of file transfer at a packet length of 1000. [Ed. - Certain Kermit programs, notably Kermit-370 4.2 and C-Kermit 5A, when sending files, reduce the packet length automatically when transmission errors occur, and then gradually increase it again as transmission errors subside. This is done to reduce the chances that a future packet will be corrupted by noise, as well as the retransmission time. The method used by Kermit-370 is described in Kermit News Volume 3 Number 1, June 1988, available online as kermit/e/newsv1.n3 (Internet) and NEWSV1 N3 (BITNET KERMSRV).] ------------------------------ End of Info-Kermit Digest ************************* From cmg Mon Nov 11 13:50:25 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA10613; Mon, 11 Nov 91 13:50:25 EST Date: Mon, 11 Nov 91 13:50:24 EST From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #10 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Mon, 11 Nov 1991 Volume 14 : Number 10 Today's Topics: New Patch File for MS-DOS Kermit 3.11 Compression Discussion QEMM Too Stealthy for Kermit MS-DOS Kermit 3.11 Printing Problem Double Echoing Problem with MS-DOS Kermit 3.11 Novell Networks and Packet Drivers Using BOOTP with MS-DOS Kermit 3.11 Kermit 3.11 TCP/IP versus 3Com 3C503 Cards MS-DOS Kermit on COM1 and COM2 in Windows MS-DOS Kermit vs Windows vs 9600 bps and Above Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Wed, 6 Nov 91 22:00:53 EDT >From: "Joe R. Doupnik" Subject: New Patch File for MS-DOS Kermit 3.11 Keywords: MS-DOS Kermit 3.11 Patches Keywords: Printers, TCP/IP, MS-DOS Kermit 3.11 and TCP/IP Xref: Patch, See MS-DOS Kermit Here is a new patch file for MS-DOS Kermit 3.11, dated 5 Nov 91. The new patches are: Patch #6 solves the problem of using 8-bit CSI vs 7-bit ESC [ in the host command to end transparent printing, reported by Leslie Foster, and it cures a bug in reporting the status of devices such as the printer and cursor position. Patch #7 solves a problem that prevented file transfer from working on SET PORT TCP/IP connections when parity was set to even or mark. [Ed. - Thanks, Joe! Readers, see below for Leslie Foster's message. The new patch file is in kermit/a/mskermit.pch on watsun and is available as MSKERMIT.PCH from KERMSRV at CUVMA on BITNET/EARN.] ------------------------------ Date: Thu, 7 Nov 1991 10:27:55 EST >From: Frank da Cruz Subject: Compression Discussion Keywords: Compression Those interested in following the discussion on adding compression to the Kermit file transfer protocol can refer to the e-mail archive in kermit/e/compress.txt on watsun, COMPRESS.TXT on KERMSRV@CUVMA (presently about 75K). If you know something about the subject, feel free to chime in (send e-mail directly to me). If traffic warrants, a special-purpose unmoderated discussion group can be set up. I'm still looking to pointers on detailed analyses. ------------------------------ Date: Mon, 28 Oct 1991 14:48 MDT >From: Joe Doupnik Subject: QEMM Too Stealthy for Kermit Keywords: QEMM, 132 Columns Keywords: MS-DOS Kermit and QEMM, MS-DOS Kermit and 132 Columns This weekend I discovered that letting the QEMM v6 Stealth (ST:M) optimization map away my VGA board's BIOS I also removed access to the same by MS-DOS Kermit. Kermit looks for a signature of a video board's Bios when asked to change from 80 to 132 column mode, and the common signatures are text strings in the Bios. Alas, Stealth swiped the BIOS so no text strings were visible. Int 10h calls work fine, as expected, but that's not what Kermit needs in this case. So, before sending in a "broken" message on Kermit let the video BIOS be visible and see if 132 column mode reappears. ------------------------------ Date: Fri, 18 Oct 91 16:46 -0300 >From: Leslie Foster Subject: MS-DOS Kermit 3.11 Printing Problem Keywords: Printers, MS-DOS Kermit and Printers We recently installed a copy of Kermit 3.11 to emulate a VT220 terminal in a GEAC library system. We have been using version 3.01, but looked forward to version 3.11 so we could display diacritics better. However, we are now having a problem printing from the host to the printer attached to the PC, that we did not have in version 3.01. In both cases, the options used are: Display: Regular, 8-bit Parity none We have also installed a print spooler on the PC (20k). When files are sent for printing in version 3.01, the "PRN" flashes on the status line until the file is collected in the spooler, and when finished, the terminal returns to normal, and the printing is done correctly. In version 3.11, this does not happen -- the PRN in the status line stays on, and the terminal must be reset with ALT=. In the debug mode, we can see the characters required for printing being sent (ESC [ 5 i at the beginning and ESC [ 4 i at the end). These appear in the SET DEBUG SESSION display as follows: ~^[5iTEST^M^J^L^@~^[4i (with TEST being the line printed.) It seems as if 3.11 is not interpreting the 8 bit control characters for printing, while 3.01 could handle it. Also, after receiving the 8-bit "stop printing" control sequence, the terminal emulator begins to behave strangely, displaying control characters as graphics. Leslie Foster, System Manager [Ed. - Cured by Patch #6, see above.] ------------------------------ Date: Fri, 1 Nov 91 14:12 MST >From: Ted McGrath Subject: Double Echoing Problem with MS-DOS Kermit 3.11 Keywords: MS-DOS Kermit 3.11 I have just installed MS-KERMIT 3.11, and I have noticed the following problem. 1. I start kermit, use the 'vms' macro that was provided in the kermit distribution, set my port to tcp/ip, set the other tcp/ip parameters, and connect to our VAX 9000. I get the username prompt, log in, and everything seems to work just fine. 2. After a while, I get tired of the reverse video stripe on the bottom of my screen, so I push Crl-], then M to toggle the mode line off. The mode line goes away, but now everything I type is doubled on the screen. Ie- typing 'dir' produces 'ddiirr'. 3. I push Alt-X, then show communications, and see that I am still set at Duplex: full. My display setting is VT320, Regular, 8-bit, with terminal controls set to 7-bit. 4. I reconnect to my VAX session with the 'CONNECT' command, and now everything is back to normal. I can toggle the mode line off, and on, and off, but still my display is as it should be. The problem does not seem to re-appear until I log off, exit kermit, and then start it up again. 5. I am running a PC with DOS 3.3, using the packet driver for the 3c503 card. I also load IPX, and this copy of Kermit is coming off of a 3.10 Novell file server. I have tried to duplicate this problem while communicating to the VAX with TES, but it does not seem to appear then. I would be happy to receive any solutions to this small, but vexing, problem. I have tried to give the critical information about my set-up, if more information is helpful please let me know. Ted McGrath tmcgrath@cc.weber.edu [Ed. - This problem is cured by Patch #2 in the patch file mentioned above.] ------------------------------ Date: 2 Nov 1991 15:27:00 EST >From: Christine M. Gianone Subject: Novell Networks and Packet Drivers Keywords: Novell Networks, Packet Drivers, TCP/IP Keywords: MS-DOS Kermit 3.11 and TCP/IP QUESTION: "How can I use MS-DOS Kermit's TCP/IP support and a Novell Network at the same time?" ANSWER: MS-DOS Kermit's TCP/IP support works only in conjunction with a packet driver (see Joe Doupnik's article "Kermit, TCP/IP, Packet Drivers, and the Future" in Info-Kermit V14 #5). To use Kermit, or any other TCP/IP application, and your Novell services at the same -- for example, to be able to transfer a file between your Novell file server disk and an IP host computer -- your Novell network must be configured to use a packet driver. Novell does not provide instructions for how to do this, so it won't do any good to look in your Novell manuals. One commonly used method is provided by a package of Novell shell drivers from Brigham Young University (BYU) in Utah, USA. These drivers can be obtained via anonymous FTP (password guest) from dcsprod.byu.edu (128.187.7.3). Use binary mode. The drivers are found in the novell subdirectory in a self-extracting archive file called novell.exe; they support NetWare versions 2.1 and higher. Transfer this file (again in binary mode) to your PC and run it. This will extract the component files, including a READ.ME file that gives instructions for configuring your Novell IPX driver to use a packet driver. For convenience, the novell.exe file is also available via anonymous ftp from watsun.cc.columbia.edu as packet-drivers/novell.exe (binary mode). ------------------------------ Date: Wed, 30 Oct 91 13:50:11 EST >From: Ken Brown - Computer Services Subject: Using BOOTP with MS-DOS Kermit 3.11 Keywords: BOOTP, MS-DOS Kermit 3.11 and BOOTP, Novell Networks We are looking at making BOOTP service available for our academic users. I see that managing IP numbers could be a problem but that Kermit can use BOOTP to set IP numbers. We'd like to "idiot-proof" this as much as is possible. Questions... Where can I obtain BOOTP, its documentation, etc? [Ed. - The BOOTP protocol is detailed in RFCs 951 and 1048. A UNIX version of BOOTP is available via anonymous ftp (binary mode), from Carnegie-Mellon University, LANCASTER.ANDREW.CMU.EDU [128.2.13.21], pub/bootp.2.0.tar. A VAX/VMS version comes with TGV MultiNet 3.0. Reportedly, a BOOTP server is available for DOS, but we have not located it yet. Anyone? In a pinch, it should be possible to adapt the CMU BOOTP server for DOS via minor (?) edits and then link it with the Waterloo TCP (WATTCP) kernel. And for Novell networks whose only link to the IP world is through the Novell server, Novell is preparing to release (at least in beta-test form) a BOOTP-forwarder NLM for NetWare 3.11 servers, BOOTPFWD.NLM). Watch CompuServe NetWire or your favorite Novell newsgroup or mailing list for further information.] Can BOOTP restrict access in some fashion? [Ed. - Yes, by hardware address. The BOOTP server sees the requestor's hardware address in the BOOTP request packet and uses this to find the associated IP address and send it back to the requestor.] What happens if two systems have the same IP address? [Ed. - The same thing that happens to your mail if your house has the same street address as another house down the block. You have to control IP numbers centrally. The BOOTP database is a good way to do this.] How do others handle IP numbers when users can set their own in MSKERMIT.INI? [Ed. - Administratively. The network manager hands out IP numbers, and has to trust users to use them properly. Of course, this never works. User A gives User B her Kermit diskette, complete with MSKERMIT.INI file containing a SET TCP/IP ADDRESS command, and then as soon as both of them try to use Kermit TCP/IP connections at the same time, only one of them works. The same thing can happen with NCSA Telnet or any other DOS-based TCP/IP software. That's why BOOTP service is a better approach for PCs: One network configuration fits all.] [Ed. - P.S. We still don't know for sure whether BOOTP service can be made to work through a gateway. Has anyone out there got this to work?] ------------------------------ Date: 22-OCT-1991 12:26:04.20 >From: "Patrick Eitner" Subject: Kermit 3.11 TCP/IP versus 3Com 3C503 Cards Keywords: Packet Drivers, 3Com 3C503, MS-DOS Kermit 3.11 and Packet Drivers Hint for 3Com 3C503 users: When installing the packet driver for 3Com 3C503 cards, one has to pay attention that the memory on the card is *not* disabled. It was in my case, and the 3C503 packet-driver would not complain. Since DEC PATHWORKS (and probably other networks) do not require the memory enabled on the card, the default is disabled. Maybe this fact should be included in your BUGS&BEWARE file. [Ed. - Thanks for the report. As you suggest, a note about this has been added to the "beware" file, kermit/a/mskerm.bwr on watsun, MSKERM.BWR on KERMSRV.] ------------------------------ Date: Wed, 23 Oct 91 13:55:06 EST >From: Dennis Perry Subject: MS-DOS Kermit on COM1 and COM2 in Windows Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0 I am trying to get two copies of MS-DOS Kermit 3.11 running under Windows. I have an early version of Windows 3.0 so perhaps it has problems. However, I've created two copies of the KERMIT.PIF file, one called NCR.PIF and the other MOTOROLA.PIF. I have two COM ports on my 386DX and a serial cable to each system. When the NCR.PIF file runs it goes to C:\KERMIT2 and runs MS-DOS Kermit 3.11 with 'set port 2'. When I do a "show comm" it tells me that I'm using COM2 with address \x2F8, IRQ3. MOTOROLA.PIF has 'set port 1' and reports COM1 in use with address \x3F8, IRQ4. When I start NCR.PIF and then start MOTOROLA.PIF, Windows says both applications want to access COM1 - sometimes MOTOROLA.PIF does find COM1 and tries to use the BIOS. Have you heard of this problem before? I'm using DOS 4.01 so perhaps there is a problem here too? [From jrd - To make sure that COM1's IRQ 4 is not touched when starting COM2 (part of the "find the IRQ" test) specify the COM2 port parameters explicitly as SET COM2 \x2f8 3 (port then IRQ). This will make Kermit bypass the test and leave COM1 material alone. The problem here is how people refer to COM2 as such: the second of two ports (that's what the BIOS does) or the \x2f8 address (what most people do) or even what used to be COM2 before they removed the COM1 device (happens often enough).] Dennis Perry Department of the Premier and Cabinet Internet: drp@premier1.mau.vicgov.oz.au 1 Treasury Place Voice: Int'l 613 651 5028 MELBOURNE VIC 3002 Facsimile: Int'l 613 651 5201 P.S. I do have the WP30.INI file which is how I first discovered MS-DOS Kermit. Did you know that WordPerfect Corp ships this file with WordPerfect 5.0 for UNIX - that's how good they think it is. ------------------------------ Date: 25-Oct-1991 11:28am EDT >From: Jeffrey E Altman Subject: MS-DOS Kermit vs Windows vs 9600 bps and Above Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0 The real problem with running above 9600 is that Windows 3.0 provides DOS Applications with virtual services only. In other words, Windows is capturing the Serial I/O data and then sending it to MS-DOS Kermit when MS-DOS Kermit is next run. However, on slower machines (386sx on down) with a 8250 or 16450 UART, Windows is unable to keep up with all of the Serial Interrupts at 9600 or above. (The actual speed that may be used is affected by the PIF settings, SYSTEM.INI settings, and number of applications running.) In order to resolve this problem you need two things. First, a 16550A UART which supports a 16 byte FIFO buffer on the chip. The FIFO cuts the number of Serial Interrupts down to one every 16 bytes (during continuous high speed transmissions) instead of one every byte received. The second thing is a replacement communications driver for Windows that supports the 16550A FIFO. (It is rumored that Windows 3.1 will contain 16550A FIFO support.) A company based in California called Bio Engineering Research Labs makes a product called TurboComm which is a replacement Windows communication driver. This allows much higher speed communication. It also provides true access to Com3 and Com4 while under windows. Unfortunately, I do not remember the phone number or address of Bio Engineering Research Labs. I will try to forward it. The author does read the WINADV/Communications forum on Compuserve. The other method is to purchase a Hayes ESP board which provides instead of a 16byte FIFO buffer, a 1K byte FIFO buffer. It comes with drivers for Windows 3.0 and OS/2 1.x. Jeffrey E Altman Facilities Management Consultant East Campus Physical Plant State University of New York at Stony Brook Stony Brook, NY 11794-8039 [From jrd - Jeffrey seems to be on target regarding the way Windows 3.0 handles the serial port. A 16550A UART chip can help if the software requests it. MS-DOS Kermit exploits the chip (FIFO buffer highwater set to 8 characters to allow more arrivals while servicing) but it needs contact with the real hardware to do so. A disappointing factor in today's market of cheaper and cheaper boards is finding a serial board with a socketed UART. Most of the serial port boards have UARTs implemented on some kind of VLSI chip of unknown parentage. So I think we are stuck with what we can get and hope that Microsoft can improve their serial port interrupt routine code. Personally I've given up hope of "speed" when using Windows (even on my 386 machine). It's nice to know that there are alternatives, so thanks Jeffrey.] [Ed. - In response to the many people who were wondering how Gene (E.W.) Carson managed to run Kermit in a Window at 19200 bps on a PS/2-55SX, as reported in Info-Kermit V14 #3... It turns out that Kermit wasn't actually running at 19200 after all. Although Gene's MSKERMIT.INI file set Kermit's port speed to 19200 bps, and Kermit displayed it as 19200, the underlying Windows setting for the port was 9600 bps and, as Jeffrey points out, the Windows setting takes precedence; Kermit was only seeing the "virtual port". After making this discovery, E.W. reports that he changed the port speed in Windows to 19200 and saw the same communication problems as everyone else.] ------------------------------ End of Info-Kermit Digest ************************* From cmg Fri Dec 13 12:12:34 1991 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA12742; Fri, 13 Dec 91 12:12:34 EST Date: Fri, 13 Dec 91 12:12:33 EST From: Christine M Gianone To: Info-Kermit Subject: Info-Kermit Digest V14 #11 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: Info-Kermit Digest Fri, 13 Fri 1991 Volume 14 : Number 11 Today's Topics: New Mac Kermit Prerelease Available for Testing Test Release 4.2.2 of Kermit-370 for MUSIC Latest MS-DOS Kermit Patch File Indexed Info-Kermit Digests TN3270 Support for MS-DOS Kermit 3.11? Cancelling Name Lookup in MS-DOS Kermit 3.11 Saving MS-DOS Kermit Screen Output to a File BOOTP for DOS and/or LAN Manager Kermit Dialing Script for Telebits Two Kermit Macros Proving Popular Here Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: 11 Dec 1991 12:48:00 EST >From: Christine M. Gianone Subject: New Mac Kermit Prerelease Available for Testing Keywords: Macintosh Kermit There have been thousands of complaints and queries about Macintosh Kermit in recent months. It is simply not possible to answer them. Instead, I am making this announcement. Development of a new release of Mac Kermit is underway. It is FAR FROM COMPLETE. It is proceeding in stages, because different volunteers at different sites in different countries are working on it in their spare time, so the schedule is not firm. Stage 1 of the development effort has produced a version that might be of use to some of you until we release a more complete version. The result is version 0.99(91)+UTexas(9)+C-Kermit 5A(172). There is NO DOCUMENTATION beyond what you'll find in this message. All the standard disclaimers apply: USE IT AT YOUR OWN RISK, etc. It seems to work under System 7 and on newer Mac models, except in a couple known cases, the most notable being when "Suitcase" is loaded. Its behavior on older Mac models (68000 based and/or small memory and/or Systems prior to 6.0) is unknown. Here is a brief list of the major new features of this "non-release". All are subject to change. . Integration with a recent edit of C-Kermit 5A. The main feature is sliding window packet protocol for increased file transfer efficiency, plus the ability to use very long packets (up to about 9000 bytes). There's also a new "file transfer thermometer". . An interactive command parser (the same as in C-Kermit 5A), in addition to the customary menus, plus the ability to execute commands from a command file. Thus Mac Kermit now has a script programming language, a DIAL command, etc. The script programming language is very similar to MS-DOS Kermit's. . A "Window" menu to let you switch among the terminal emulation, command parser, general text editing, and server response windows, with cutting and pasting between windows, etc. Command files can be created in text editing windows and executed, saved, etc. . Redesigned menus (the design is nowhere near complete, and definitely will change). . Translation between the Mac Quickdraw character set and ISO 8859-1 Latin Alphabet 1 during file transfer (presently available only via SET commands in the Command Window). Many of the new features might be buggy or incompletely implemented. The basic functionality -- text, binary, and macbinary file transfers, VT320 emulation, etc -- seem to be fairly solid. This NON-RELEASE version is available on the Internet as: kermit/test/ckmut9.hqx on watsun.cc.columbia.edu via anonymous ftp (text) and on BITNET/EARN as: T:CKMUT9.HQX from KERMSRV@CUVMA.BITNET It's about 400K long. Use BinHex version 4.0 to decode the HQX file into the Macintosh Kermit application. Please send reports, suggestions, and (most important) offers to help out with the development to: Frank da Cruz fdc@watsun.cc.columbia.edu A few points about this program, to forestall hundreds of e-mail messages: 1. The VT100 font is usable only in 9-point size. Select Courier from Mac Kermit's new Font menu if you want to use a larger size. 2. The VT100 font's code points for accented characters are incompatible with other Mac fonts, like Courier. VT100 line- and box-drawing characters don't work in any but the VT100 font. 3. Volunteers are needed to work on the VT100 font, including design, rearrangement of the code points, externalization in a variety of point sizes, etc, so it is visible to keycaps, etc etc. Please contact Frank if you're interested in taking on this task. 4. Key mapping has not been tackled in this version. Improvements will come, hopefully, in a forthcoming test release. 5. Some improvements have been made in the area of printing, but much more remains to be done. Remember, this announcement is being made only to tide over those who simply cannot find a version of Mac Kermit that runs satisfactorily on their system. Feel free to send in bug reports, but don't expect them to be answered. They will be collected, collated, and acted upon during the development process. ------------------------------ Date: Mon, 1991 Dec 9 16:06 EST >From: "John F. Chandler" Subject: Test Release 4.2.2 of Kermit-370 for MUSIC Keywords: IBM 370 Kermit, MUSIC Kermit Kermit-370 version 4.2.2 is coming soon to MUSIC. A trial release has been undergoing tests for two months, but only at one site. I have sent the new updates to Columbia so that they can be made generally available (as T:IKMKER.UPD on KERMSRV and as ~kermit/test/ikmker.upd on watsun). As soon as enough reports come in to verify that there are no problems with the test version, it will be released officially. The new BWR file has already been released (as IKMKER.BWR and as ~kermit/b/ikmker.bwr). In most respects, the new MUSIC variant is just an adaptation of the updates in the other three variants (CICS, CMS, and TSO), but there is one notable change: Kermit-MUSIC 4.2.2 supports automatic detection of the terminal controller type among the various full-screen flavors (SERIES1, GRAPHICS, AEA). This results in Kermit becoming incompatible with MUSIC/SP 1.2 and requiring at least MUSIC/SP 2.2, but there is a simple optional update to restore 1.2 compatibility. See the notes in ikmker.bwr dated 89/2/27 and 91/8/19 for more details. Please send any test reports (whether good or bad) to PEPMNT@CFAAMP (on BITNET) or to pepmnt@cfaamp.harvard.edu (on the Internet). ------------------------------ Date: Mon, 18 Nov 91 22:15:03 EST >From: "Joe R. Doupnik" Subject: Latest MS-DOS Kermit Patch File Keywords: MS-DOS Kermit Patches Here is today's edition of the MS-DOS Kermit 3.11 Patch news. It has two patches: number 8 corrects a coding error which mistakenly adds 9 to the code for a DEC User Definable Key definition. Number 9 is a workaround for a bug in Interconnections Inc's TES program v2.2/R8, the latest available. The bug would cause Kermit to crash at the start of a connection, necessitating reboot of the PC. [Ed. - Thanks, Joe! The new patch file is in kermit/a/mskermit.pch on watsun for anonymous ftp on the Internet, and also available from KERMSRV at CUVMA on BITNET / EARN as MSKERMIT.PCH.] ------------------------------ Date: 18 Nov 1991 15:27:00 EST >From: Christine M. Gianone Subject: Indexed Info-Kermit Digests Just a reminder that paginated, indexed versions of the Info-Kermit Digest are available as imail.yyx, where yy is the year, and x is "a" or "b". For example, the current Digest volume (14) is in kermit/e/imail.91b on watsun (Internet) or IMAIL.91B (KERMSRV@CUVMA on BITNET/EARN). ------------------------------ Date: 12 Nov 1991 09:19:29 EST >From: Subject: TN3270 Support for MS-DOS Kermit 3.11? Keywords: 3270 Emulation, TN3270 We're running a couple of versions of tcp/ip for pc's, and we'd like to replace the telnet/ftp stuff with Kermit. There are a lot of reasons for doing this: our users are familiar with Kermit, they can use it from home, support for printing, etc. With our IBM mainframe, we do need tn3270 support. Are there any plans to include this support in Kermit? If anyone is working on it, we'd be happy to be guinea pigs. [From jrd - Tom, I'm glad you like the current Telnet support in Kermit. We knew that once this area was opened that folks would want the whole range of TCP/IP based programs. Alas, we don't have the resources to do all that, and mentioned the list and reasons in Info-Kermit V14 #5. TN3270 is a fairly large amount of effort to accomplish. We would certainly consider it if a generous sponsor were willing to contribute enough funds to hire some persons to assist us. In the meanwhile users can employ Telnet with the IBM mainframe in line mode, or go through 3270 protocol converters (perhaps connected "milking-machine" fashion to TCP/IP terminal servers).] ------------------------------ Date: Tue, 12 Nov 91 14:55:07 PST >From: (Richard Stanton) Subject: Cancelling Name Lookup in MS-DOS Kermit 3.11 Keywords: TCP/IP, MS-DOS Kermit 3.11 and TCP/IP Is there any way of quickly aborting a failed or failing name lookup in MSK 3.11? I often sit there for ages while it tries to access a name server and find the address for a computer name, and it's usually faster to reboot than to wait for it to come back. (This is using TCP/IP) Thanks. [From jrd - During the Domain Name Service query matters are entirely in the hands of the TCP/IP code and there is no sampling of the keyboard or similar interactive items. This was done to greatly simplify the design of the new Telnet material. Some probes can take some time. So, for the current release one should wait out the process and/or remove the difficult name server from the list.] ------------------------------ Date: Tue, 12 Nov 91 08:27:04 IST >From: Ran Cheremsh Subject: Saving MS-DOS Kermit Screen Output to a File Keywords: MS-DOS Kermit and Saving Screens I'm trying to transfer information from a database to my PC. Whenever I log information, I endup with a file full with escape characters. The file is almost impossible to read. I can, on the other hand, save the screen by using the Alt-H, F sequence. The problem is, that this method requires a page by page instruction. Is there a way to save a session using a quasi-Alt-H, F technique? [Ed. - Using MS-DOS Kermit 3.11, try this: MS-Kermit>SET PRINTER XXX.LOG MS-Kermit>CONNECT Press Ctrl-PrintScreen When you want to stop recording your session, press Ctrl-PrintScreen again. The file XXX.LOG (call it whatever you like) will contain a session log that does not contain escape sequences. This technique is documented on pages 82-84 of "Using MS-DOS Kermit", second edition.] ------------------------------ Date: Wed, 13 Nov 91 11:03:04 +0100 >From: (Lars W. Holm) fnslh Subject: BOOTP for DOS and/or LAN Manager Keywords: MS-DOS Kermit 3.11 and BOOTP, BOOTP Ref. Info-Kermit Digest vol.14, no.10: I hope you will forward any information on BOOTP available for MS-DOS machines to the Info-Kermit list. Also if any information on BOOTP service on LAN Manager servers is available, it would be very much appreciated. . Lars W. Holm Lars.Holm@nsd.uib.no . . Norwegian Social Science Data Services FNSLH@NOBERGEN.BITNET . . Hans Holmboesgate 22 Phone +47-5-212116 . . N-5007 Bergen, Norway Fax +47-5-960660 . [Ed. - Moore reports that "According to the CUTCP distribution group, the program lpd located in /pub/lpd at tacky.cs.olemiss.edu [130.74.96.13] can perform BOOTP functions." This is primarily a print spooler for PCs equivalent to UNIX lpd, but reportedly the BOOTP service that is included is quite flexible.] ------------------------------ Date: 21 Aug 91 15:19:51 GMT >From: aporter@pilot.njin.net (Al Porter) Subject: Kermit Dialing Script for Telebits Keywords: MS-DOS Kermit, Modems, Telebit I'm using MS-DOS Kermit on a PC. When I try to do a script to call up a site: def remote dial 123-4567,input 60 CONNECT,output \13\13\13,connect as soon as the connection begins, Kermit stops and says: Error: No dialtone or no answer (I have defined dial via the default definition, and using hayes.tak) How can I modify hayes.tak? Does someone have a telebit.tak? Thanks for any help!!! [Ed. - The problem is that Telebit modems output the message RRING each time the called phone rings. Real Hayes modems don't do this. The new version of MSIHAY.SCR that comes with MS-DOS Kermit 3.11 allows for this message, and has been tested successfully on Telebits. Also, it's not a good idea to give a macro the same name as a built-in command, like REMOTE.] ------------------------------ Date: Sun, 3 Nov 91 11:52 PST >From: Professor TJ Olney Subject: Two Kermit Macros Proving Popular Here Keywords: MS-DOS Kermit Macros, File Transfer, TERMINALR/S Macros These simple macros are proving quite popular to communications novices here. TJ Olney ;These two macros rely on prior definition of FATAL ;a macro to send a file to the remote machine automatically ; no manual invocation of the remote kermit ;non machine-specific by having separate lines for kermit and server ;it can deal with either ckermit or vmskermit or mskermit def UPLOAD if < argc 2 fatal {Upload what local file?},- output kermit\13, - input 5 kermit,pause,output server\13,in 5 local machine,pause,send \%1,- fin, in 5 >,output exit\13,output ! \%1 uploaded\13,def \%1,c ;a macro to grab a file from the remote machine automatically def DOWNLOAD if < argc 2 fatal {Download what remote file?},- output kermit\13,- in 5 kermit,pause,output server\13,in 5 local machine,pause,get \%1,fi,- in 5 >, output exit\13,def \%1 [Ed. - Thanks! These are indeed handy macros -- they let the user control file transfers exclusively from the MS-DOS Kermit end, without having to start Kermit on the remote end, or to give the remote Kermit any commands. However, they require the user to escape back first, and they rely on the form of the remote Kermit's name, prompt, and messages. There is a better technique that can be driven entirely from the remote Kermit (or from host command procedures that invoke the remote Kermit). The trick is to define MS-DOS Kermit's TERMINALS and TERMINALR macros appropriately, and have the host send the escape sequences that invoke them. This technique is described on pages 180-181 of the second edition of "Using MS-DOS Kermit".] ------------------------------ End of Info-Kermit Digest *************************