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, Microsoft Windows, Windows In response to numerous queries, here is the situation -- as best we know it -- with MS-DOS 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 Mainframe 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 *************************