11-Nov-91 18:52:42-GMT,19637;000000000001 Return-Path: <@cuvmb.cc.columbia.edu:I-KERMIT@CUVMA.BITNET> Received: from cuvmb.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA10651; Mon, 11 Nov 91 13:52:39 EST Message-Id: <9111111852.AA10651@watsun.cc.columbia.edu> Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7373; Mon, 11 Nov 91 13:51:38 EST Received: from CUVMA.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.07) with BSMTP id 2514; Mon, 11 Nov 91 13:51:33 EST Date: Mon, 11 Nov 1991 13:50:24 EST Reply-To: Info-Kermit%watsun.cc.columbia.edu@cuvmb.cc.columbia.edu Sender: INFO-KERMIT Digest From: Christine M Gianone Subject: Info-Kermit Digest V14 #10 Comments: To: Info-Kermit@watsun.cc.columbia.edu To: Multiple recipients of list I-KERMIT 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 *************************