Frequently Asked Questions (and answers) about Kermit software. From comp.protocols.kermit.misc and elsewhere... Most recent update: Thu Mar 23 15:06:58 1995 ------------------------------------------------------------------------- CONTENTS: DIRECTORY: How to contact us. 1. Q: WHERE DO I GET DOCUMENTATION? A: Here's a list of manuals and how (and why) to get them. 2. Q: WHY IS KERMIT SO SLOW COMPARED TO ZMODEM? A: It isn't if you tune it for speed; here's how. 3. Q: MY BACKSPACE KEY DOESN'T WORK! A: Here's why, and how to fix it. 4. Q: HOW DO I USE KERMIT OVER TRUMPET WINSOCK? A: Sorry, you don't, here's why. 5. Q: HOW TO TRANSFER FILES THROUGH A 3270 PROTOCOL CONVERTER? A: Here's a brief tutorial. 6. Q: WHERE IS THE KEY MAP FOR 3270 EMULATION? A: This is completely site-dependent, here's why. 7. Q: CAN I MAKE MS-DOS KERMIT USE COM3, COM4? A: Yes. 8. Q: MS-DOS KERMIT PATCHES DON'T SEEM TO TAKE EFFECT. A: Several possible reasons for this, and how to fix. 9. Q: I CAN TRANSFER TEXT FILES BUT NOT BINARY FILES. A: Several possible reasons for this, and how to fix. 10. Q: BINARY FILES ARE CORRUPTED AFTER TRANSFER. A: Then they probably were not transferred in binary mode. 11. Q: WHY DOESN'T THE HANGUP COMMAND WORK FOR ME? A: Various reasons, and how to make it work. 12. Q: HOW CAN I MAKE THE {DIAL, REDIAL} COMMAND KEEP TRYING? A: It's easy, here's how. 13. Q: I ENABLED SLIDING WINDOWS BUT IT LOOKS LIKE ONLY ONE IS USED. A: It's an optical illusion, here's the explanation. 14. Q: HOW DO I WRITE A SCRIPT TO DIAL A NUMERIC PAGER? A: By not expecting the modem to get carrier; here's how. 15. Q: WHEN C-KERMIT DIALS MY V.32bis (OR V.34) MODEM, I GET THE ERROR "CAN'T CHANGE SPEED TO 14400 (OR 28800)" A: Tell C-Kermit to SET DIAL SPEED-MATCHING OFF; explained below. 16. Q: HOW DO I USE KERMIT WITH PINE? A: Here's a brief explanation of how to print a message and how to import and export files. ------------------------------------------------------------------------- DIRECTORY: World-Wide Web: http://www.columbia.edu/kermit/ ftp: kermit.columbia.edu This is the definitive source for Kermit software on the Internet. Other Kermit archives or "mirror sites" are not necessarily complete, accurate, or up to date. Newsgroups: comp.protocols.kermit.announce - Moderated comp.protocols.kermit.misc - Unmoderated LISTSERV: I$KERMIT@CUVMA.BITNET or CUVMA.CC.COLUMBIA.EDU - Submissions LISTSERV@CUVMA.BITNET or CUVMA.CC.COLUMBIA.EDU - Subscriptions KERMRSV: KERMSRV@CUVMA.BITNET or CUVMA.CC.COLUMBIA.EDU - Files (Send e-mail with text HELP to get started.) E-mail: kermit@columbia.edu (not an FTP mail server!) Post: Kermit Distribution Columbia University Academic Information Systems 612 West 115th Street New York, NY 10025-7221 USA Fax: +1 212 663-8202 or +1 212 662-6442 ------------------------------------------------------------------------- FREQUENTLY ASKED QUESTIONS: Most questions are already answered in the published documentation. Reading the appropriate manuals (in conjunction with online release notes) will get you started, answer most of your questions, and will let you get the most out of your Kermit software: maximize the performance, write scripts to automate your communications tasks, and so on. The Kermit effort is entirely self-supporting, and proceeds from sales of these manuals is our primary source of funding. So please do purchase the manuals. ------------------------------------------------------------------------- (1) WHERE TO GET KERMIT MANUALS MS-DOS Kermit, full-featured communications software for IBM and compatible PCs with DOS or Windows, is documented in: Christine M. Gianone, Using MS-DOS Kermit, Second Edition, Digital Press / Butterworth-Heinemann, Woburn, MA, 1992, 345 pages, ISBN 1-55558-082-3. Packaged with version 3.13 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on a 3.5-inch diskette. In computer and book stores, or order direct from Columbia University or from Digital Press. A German-language edition is also available: Christine M. Gianone, MS-DOS Kermit, das universelle Kommunikationsprogramm, Verlag Heinz Heise, Hannover, Germany (1991), 414 pages. Packaged with version 3.12 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on a 5.25-inch diskette, including German- language help files. Deutsch von Gisbert W. Selke. ISBN 3-88229-006-4. And a French-language edition: Christine M. Gianone, Kermit MS-DOS mode d'emploi, Deuxieme edition, Heinz Schiefer & Cie., Versailles (1993), 406 pages. Packaged with version 3.11 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on a 5.25-inch diskette. Adaption francaise: Jean Dutertre. ISBN 2-901143-20-2. There is also a Japanese book about MS-DOS Kermit, concentrating on the NEC PC9801: Hirofumi Fujii and Fukuko Yuasa, MS-Kermit Nyumon, Computer Today Library 6, Saiensu-Sha Co., Ltd., publishers (1993), 160 pages. ISBN 4-7819-0669-9 C3355 P1854E. C-Kermit 5A, full-function communication software for UNIX, VMS, OS/2, AOS/VS, OS-9, Apollo Aegis, the Commodore Amiga, and the Atari ST is documented in: Frank da Cruz and Christine M. Gianone, "Using C-Kermit", Digital Press / Butterworth-Heinemann, Woburn, MA, 1993, 514 pages, ISBN 1-55558-108-0. In computer and book stores, or order direct from Columbia University or from Digital Press. A German-language edition is also available: Frank da Cruz und Christine M. Gianone, C-Kermit--Einfuhrung und Referenz, Verlag Heinz Heise, Hannover, Germany (1994). ISBN 3-88229-023-4. Deutsch von Gisbert W. Selke. The Kermit File transfer protocol is specified in the following book, which also includes tutorials on computers, file systems, data communications, and using Kermit: Frank da Cruz, Kermit, A File Transfer Protocol, Digital Press / Butterworth-Heinemann, Worburn, MA, 1987, 379 pages, ISBN 0-932376-88-6. In computer and book stores, or order direct from Columbia University or from Digital Press. Kermit software for more than 400 different computers and operating systems is available from Columbia University. Contact Columbia for a free Kermit software catalog. ENGLISH-LANGUAGE KERMIT BOOKS: 1. In computer and book stores, or order direct from the publisher, Digital Press / Butterworth-Heinemann with MasterCard, Visa, or American Express: +1 800 366-2665 (Woburn, MA office for USA & Canada) +44 993 58521 (Rushden, England office for Europe) +61 2 372-5511 (Chatswood, NSW office for Australia & NZ) +65 220-3684 (Singapore office for Asia) 2. From Columbia University: Kermit Development and Distribution Columbia University Academic Information Systems 612 West 115th Street New York, NY 10025 USA Tel. +1 212 854-3703 Fax. +1 212 663-8202 E-Mail: kermit@columbia.edu Domestic and overseas orders accepted. Add $10 US PER BOOK for shipping outside of North America. Orders may be paid by MasterCard or Visa, or prepaid by check in US dollars. Add $35 bank fee for checks not drawn on a US bank. Price includes shipping. Do not include sales tax. Quantity discounts are available. Single-copy US prices (in US dollars): Using MS-DOS Kermit . . . . . . . . . . . . . . . . .$ 36.95 Using C-Kermit . . . . . . . . . . . . . . . . . . . .$ 36.95 Kermit, A File Transfer Protocol . . . . . . . . . . .$ 32.95 All three . . . . . . . . . . . . . . . . . . . . . .$ 85.00 GERMAN-LANGUAGE KERMIT BOOKS: MS-DOS Kermit, das universelle Kommunikationsprogramm: DM 79,00 C-Kermit--Einfuhrung und Referenz: . . . . . . . . . . DM 88,00 Verlag Heinz Heise GmbH & Co. KG Helstorfer Strasse 7 D-30625 Hannover, GERMANY Tel. +49 (05 11) 53 52-0 Fax. +49 (05 11) 53 53-1 29 FRENCH: Kermit MS-DOS Mode d'Emploi: . . . . . . . . . . . FF 495,00 Heinz Schiefer & Cie. 45 rue Henri de Regnier F-78000 Versailles, FRANCE Tel. +33 39 53 95 26 Fax. +33 39 02 39 71 JAPANESE: MS-Kermit Nyumon: . . . . . . . . . . . . . . . . . 1,800 Y Saiensu-Sha Co., Ltd. Abe-toku Building 2-4 Kanda-suda cho, Chiyoda-ku Tokyo 101, JAPAN Tel. +81-3-3256-1091 ------------------------------------------------------------------------- (2) WHY IS KERMIT SO SLOW COMPARED TO ZMODEM? Path: news.columbia.edu!usenet From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: [HELP] Slow Kermit Transfer ?! Date: 19 Sep 1994 14:15:42 GMT Organization: Columbia University Lines: 153 In article <35jrgsINNdq2@newsman.csu.murdoch.edu.au> anson@csuvax1.csu.murdoch.edu.au (Binh Anson) writes: > I used Kermit 3.13 for my PC, my modem has a speed of 14.4 K, but I found > that the downloading rate from the mainframe to my PC was still very slow! > I tried Telix with SZ (Z-Modem Protocol), and it was very fast compared to > Kermit. Is there a way to accelerate Kermit transfer ? > Yes. But first, welcome to comp.protocols.kermit.misc. This is the first day of operation of this unmoderated newsgroup. I hope it will prove beneficial to all Kermit users. To answer your question, somewhat longwindedly, since this Question is Asked so Frequently :-) ... Zmodem is optimized for speed on the assumption that it has a clear 8-bit transparent channel with no blockages (small buffers, etc), and so, out of the box, when it works it goes fast. The tradeoff is that it often does not work at all, in which case you have to configure it in various ways -- escaping of control characters, changing window size, etc. In some cases it can't be made to work at all, either because of the nature of the connection, or because of one or both of the computers on the two ends. Kermit, on the other hand, is configured to work -- i.e. transfer files -- out of the box, even under hostile conditions. By default, it does not assume that control characters pass through transparently, nor that large buffers are available. It does not even assume a full-duplex connection. The tradeoff is speed. In a perfect world, there would be no tradeoffs, but the world is far from perfect. 7-bit transmission is still extremely common, small buffers are very common, even in modern terminal servers and other communications processors, flow control is rarely implemented correctly and effectively, telephone lines are still noisy, and we still have a bewildering array of communication methods needed for accessing different kinds of hosts and services. Most PCs are still shipped with non-buffered UARTs; many PCs have interrupt conflicts, noisy buses, etc; many modern modems are buggy. The list goes on. This is by way of demonstrating that Kermit's default tuning is not crazy, and goes a long way towards explaining its justified reputation for dependability. Unfortunately, because of the tradeoffs necessary to achieve its reliability, Kermit has a reputation for slowness: Yes, Kermit transfers are slow if you use the default tuning. However, you can make Kermit go as fast as the communication path will permit by changing a few parameters. But first, here are some general principles that apply to all communications software: 1. Ensure that you have an effective means of flow control enabled at every juncture along the communication path (this applies to any file transfer protocol). For example, when using high-speed, error-correcting modems, you should use some form of hardware flow control, most commonly RTS/CTS. You have to tell the software to use it, AND you have to tell the modem to use it too -- if the flow control methods of the PC and the modem do not agree, then data will be lost. 2. If your modem is capable of data compression, use it. Fix the interface speed of the software to four times the connection speed if possible -- e.g. for a V.32bis 14400 bps connection, use an interface speed of 57600, or else the modem's compression capacity is likely to be wasted. 3. On network connections (e.g. TCP/IP), it is usually best to turn off flow control entirely, because the underlying networking method supplies fully effective flow control. Now, to make Kermit go fast, follow these steps: 1. Use real Kermit software, not the many shareware and commercial packages, most of whose Kermit protocol implementations lack the performance features listed below and/or the means for the user to control them. 2. Use long packets. Kermit's default packet length is 94. You can increase it to a theoretical maximum of 9024. Give the following command to the file receiver: SET RECEIVE PACKET-LENGTH 2000 ; (or other length) The longer you make the packets, the more efficient the file transfer will be... IF IT WORKS. If you make packets longer than some buffer somewhere along the line, and effective flow control is lacking, the transfer might not work. Also, the longer the packet, the greater the chance it will be hit by noise, and the longer it takes to retransmit. A good starting value to try is 1000. 3. On full duplex connections, use sliding windows. Sliding windows allow packets to be transmitted in a continuous stream, rather than "stop and wait" style. The command is: SET WINDOW 4 ; (or other number) The maximum is 32 (or less, depending on the implementation). Give this command to *both* Kermit programs. For text files and uncompressed binary files, this should give you very good performance -- efficiencies in the 85%-100% range. For compressed files, and certain other types of binary files, you can squeeze out another 20-25% efficiency by telling Kermit not to prefix a given list of control characters. A typical sequence might be: SET CONTROL UNPREFIX ALL ; Unprefix all control characters. SET CONTROL PREFIX 0 1 13 129 141 ... ; Add back prefixes for these. This might require some trial and error because there is no way that a communication software program can know what characters are safe and which ones are not on a particular connection. For example, you might be going through an X.25 PAD where Ctrl-P will pop you back to the PAD prompt. Or you might be going through a TELNET terminal server where Ctrl-] or Ctrl-^ will pop you back to the terminal server prompt. Or the connection might be using Xon/Xoff flow control, and sending Ctrl-S as a data character might freeze the connection. If you take all of these steps, using optimal packet lengths, window sizes, and unprefixing, you should achieve transfer rates comparable to, and often better than, the Zmodem implementations that you find in Telix, Procomm, and similar shareware and commercial packages; for example, on a V.32bis/V.42/V.42bis connection, RTS/CTS flow control, no parity, 57600 bps interface speed: Typical text files: 3500 cps (characters per second) Uncompressed binary files: 2400 cps (e.g. PC KERMIT.EXE) Compressed files: 1600 cps (e.g. ZIP files) These figures come from Kermit News #5, June 1993, which is available via anonymous ftp from kermit.columbia.edu, directory kermit/e, file newsn5.txt (ASCII) or newsn5.ps (PostScript). Also see newsn4.txt (.ps) for a detailed discussion of long packets and sliding windows. Kermit software is available via anonymous ftp to kermit.columbia.edu [128.59.39.2], directory kermit and its subdirectories. There are literally hundreds of different Kermit programs for *almost* every machine and operating system imaginable. The most widely used Kermit programs are: . MS-DOS Kermit 3.14 for DOS and Windows. No, this is not a native Windows application, but yes, this is the software we recommend for Windows. File: kermit/bin/msvib.zip. . C-Kermit 5A(190) for UNIX, VMS, OS/2, AOS/VS, the Commodore Amiga, etc. UNIX: kermit/bin/cku190.tar.Z. VMS: Get kermit/b/ckvaaa.hlp, read it, take it from there. Others: Get kermit/b/ckaaaa.hlp, read it, take it from there. . IBM Mainframe Kermit-370 4.3 for VM/CMS, MVS/TSO, CICS, and MUSIC. kermit/b/ik*.*. - Frank ------------------------------------------------------------------------- (3) MY BACKSPACE KEY DOESN'T WORK! From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: [?] Backspace key says, "^?" Date: 7 Jan 1995 21:26:44 GMT Organization: Columbia University Lines: 122 In article , Jim Monty wrote: >DISCLAIMER: I've looked for the answer to the following question in > _Using MS-DOS Kermit_ and in the documentation included > with MS-DOS Kermit 3.13. I either couldn't find the > answer or didn't understand it if I did. > Thank you for consulting the documentation. >I'm using MS-DOS Kermit 3.13 on an i80386SX machine running MS-DOS 6.0, >using a 14,400 bps Zoom VFP V.32bis modem. Kermit is set for VT220 >terminal emulation and is using the Latin1 character set and code page >CP437. I've not mucked with much in the initialization files, so you may >assume that any other parameters are still set to the "factory" defaults. > >Alas, the question: In some online environments, my backspace key behaves >as one would expect it to. In others, hitting the backspace key results >in either (1) nothing happening, or (2) the characters "^?" appearing on >the screen. I can, however, use Ctrl-H in these situations. In these >exact same online environments (e.g., vi insert mode when connected to my >dial-up UNIX shell account) under analagous circumstances, the other >terminal emulator that I use, Telemate Version 3.12, does not behave this >way. The backspace key functions as a destructive backspace. > >I presume that the change I need to make to my MS-DOS Kermit >configuration is a simple one, but I can't figure it out. And I've never >really wanted to bother to spend a lot of time trying to figure it out >myself. (I want the magic straight from the wizards' minds.) Thanks, in >advance, for taking the time to help me. > >Jim Monty, Kermit Cheerleader at Arthur Andersen LLP > Well, Jim, I think it's finally time to classify this as a Frequently Asked Question and add it to the FAQ (kermit.columbia.edu:kermit/FAQ.TXT). As you have discovered, different hosts and applications use different characters (or sequences) for destructive backspace. The terminal emulator, Kermit or otherwise (including Telemate -- if its backspace key works for you in all circumstances, I think that's just a stroke of luck), has no way of knowing what host or application you are using, and therefore no way of knowing what to send when you press the Backspace key. Of course, Kermit's Backspace key must send *something* "out of the box", so it uses one of the several most likely destructive backspace values, and in fact the one that is defined in ASCII to be destructive backspace, namely Rubout, also known as Delete or DEL, character number 127, which sometimes is displayed as "^?". Lest anyone believe this is a frivolous choice, I quote from American National Standard X3.4-1977, Section 5.1, Control Characters: 0/8 BS (Backspace). A one-active-position format effector that moves the position backward on the same line. 7/15 (DEL). A character used primarily to erase or obliterate an erroneous or unwanted character... In cases where the default does not work, Kermit lets you redefine the Backspace key (or any other key) to send whatever you want it to send (or to take any other actions) with the SET KEY command. The SET KEY command has two operands: a unique identifier for a key or key combination, called a scan code, and the value or action to be assigned to the key. Scan codes are written with a preceding backslash (\). The scan code for the Backspace key is \270. The default definition for this key is \127, meaning the character whose numeric value is 127, i.e. DEL. You can find out a key's scan code by consulting Table I-9 in the manual (pages 285-288), or by giving the SHOW KEY command to Kermit and then pressing the desired key or key combination. Now, as you have discovered, some applications use Ctrl-H -- ASCII BS (Backspace) -- for destructive backspace. Consulting the ASCII table on page 275, you see that the ASCII code for BS is 8. So to make PC's Backspace key send BS instead of DEL, give this command: SET KEY \270 \8 If you use Kermit only to connect to hosts and services that use BS for destructive backspace, then you can put this command in your MSCUSTOM.INI file, and it will take effect automatically every time you start Kermit. But some people (like yourself) switch between different hosts and/or services that expect different characters or sequences for destructive backspace. You can, of course, give Kermit the appropriate command every time you switch from one to another: SET KEY \270 \8 ; Backspace sends BS or: SET KEY \270 \127 ; Backspace sends DEL or you can use the macros that are already defined in MSKERMIT.INI for this. In version 3.14, for example, we have macros with names like VAX and IBM. The VAX macro sets things up (including the Backspace key) for communicating with VAXes and VAX-like systems, and that means, among other things, setting the Backspace key to send DEL. The IBM macro, on the other hand, is used for communicating with IBM mainframes in linemode, where BS is used. You can use these macros as they are, or you can write your own macros based upon them and add them to your MSCUSTOM.INI file. To use a macro, just type its name at the MS-Kermit> prompt. Suppose, for example, you normally access two different systems: a BBS (which uses 8-bit characters, ANSI terminal emulation, and BS) and a UNIX system (which uses 7-bit characters, VT220 emulation, and DEL), and these items need to be changed when you switch between the two. You could write two macros such as these: define bbs set term byte 8, set term type ANSI, set key \270 \8 define unix set term byte 7, set term type vt220, set key \270 \127 And then each time you want to use the BBS, you just type "bbs" at the MS-Kermit> prompt, and each time you want to access the UNIX system, you type "unix". Of course, you could take this process even further, and turn the BBS and UNIX macros into complete connection-establishment and login scripts, following the directions in Chapter 14 of the manual, on script programming. - Frank ------------------------------------------------------------------------- (4) HOW DO I USE KERMIT OVER TRUMPET WINSOCK? Date: Sun, 8 Jan 95 13:27 EST To: .... From: kermit@columbia.edu Subject: Re: Using Kermit with Trumpt Winsock > I have an internet connection (SLIP) using Trumpet Winsock to establish > the connection to the server under windows. I'd like to use kermit at > that point to telnet to my company's computer. I've filled in the IP > addresses in my custom file, but when I run kermit, and try to telnet, > I get the message: > > Cannot attach to an Ethernet Packet Driver.... > > Can you give me an idea of what I'm doing wrong? > The rule for DOS, Windows, and similar PC operating systems is: ONE APPLICATION PER PROTOCOL PER NETWORK BOARD This applies also to serial ports being used as if they were network boards, e.g. via SLIP. Now, Trumpet Winsock is using (i.e. registered for) the TCP protocol on your "network board". Thus, when you try to activate Kermit's own built-in TCP/IP networking, it finds that it can't register TCP because TCP is already registered. Thus it "Cannot attach to ... Packet Driver". One might think it would be possible, then, to tell Kermit to "use" Winsock. But Winsock TCP/IP stacks are strictly for pure Windows (and NT) programs, not for DOS programs. MS-DOS Kermit is a "Windows-aware" DOS program, but a DOS program nevertheless; it runs from the DOS prompt and within DOS emulator boxes in various operating systems, and cannot access Winsock. If you want to make a TCP/IP connection with Kermit when Winsock is running, you have to unload Winsock and use Kermit's own built-in TCP/IP capability directly over an Ethernet- or SLIP-class packet driver or an ODI driver. Or else install a second network adapter. Or... It is PERHAPS POSSIBLE, but not necessarily recommended, to run Kermit's TCP/IP stack alongside of Winsock using Dan Lanciani's NDIS3PKT shim. Use this method at your own risk. In Dan's words: "Ndis3pkt is a Windows virtual device (VxD) that provides multiple emulated packet driver interfaces in Windows VMs and converts to NDIS3. It knows how to route packets to the correct VM at upcall time (similar to the function of WINPKT) and it includes an optional tcp multiplexor to allow multiple tcp/ip stacks to coexist with the same IP address (similar to the function of PKTMUX). It can also support multiple boards, but that isn't a much-used feature. It can also emulate a class 1 (Ethernet) packet driver on top of Token Ring. In other words, ndis3pkt is intended to be a one-stop solution to packet driver applications over NDIS3. "Now, when people talk about ``Winsock'' they often mean one of the Winsock providing packages that runs in the Windows system VM, e.g., Trumpet. Because Trumpet Winsock is really just another packet driver application, ndi3pkt is perfectly happy to multiplex it along with any number of DOS applications. Thus, from a high-level viewpoint, users see this as sharing DOS applications with Winsock. In reality, ndis3pkt knows nothing about Winsock, but the net effect is the same." ndis3pkt in pub/ndis3pkt on newdev.harvard.edu, available by by anonymous ftp. Be sure to read the license in the accompanying README file, and be sure you have a version dated 17 Mar 95 or later. For additional details, see discussions in comp.protocols.tcp-ip.ibmpc and in the ndis3pkt documentation. ------------------------------------------------------------------------- (5) HOW TO TRANSFER FILES THROUGH A 3270 PROTOCOL CONVERTER? From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Kermit File Transfer and tn3270 Date: 16 Jan 1995 16:46:18 GMT Organization: Columbia University Lines: 169 In article <173276AEB.BDESIMON@uga.cc.uga.edu>, Bert DeSimone wrote: >Gotta figure this has come up before. We are evaluating a terminal server >that supports tn3270. No problem using MS-Kermit to connect to the terminal >server and connect via tn3270 to an IBM mainframe. However, file >transfers (either invoking server on the mainframe or not) always fail. >Connecting through this same terminal server to the same mainframe >through a 7171 presents *no* problem with file transfer. (BTW: I don't >have to be using tn3270 on a terminal server; file transfers with Kermit >using tn3270 on a Unix host fail the same way). > >I am speculating that the mainframe Kermit must send a transparent mode >sequence, ordinarily processed by the protocol converter, that is causing >the problem. > One of the major strengths of the Kermit protocol is its ability to transfer files with IBM mainframes over a wide variety of connection types, and there is an excellent Kermit software program for the IBM mainframe, which is available for VM/CMS, MVS/TSO (and ROSCOE), CICS, and MUSIC. The current version is 4.3.0, with version 4.3.1 in beta test. All of the Kermit books and manuals ("Kermit, A File Transfer Protocol", "Using MS-DOS Kermit", "Using C-Kermit", and the IBM mainframe Kermit online manuals) describe the process(es) in some detail. Here is a brief summary. Half-duplex (local-echo), line-at-a-time connections are generally handled by the "ibm" macro that is built in to MS-DOS Kermit and C-Kermit, which performs the following protocol-related settings: set local-echo on set parity mark set flow none set handshake xon Full-screen sessions go through a 3270 terminal emulator. This can reside anywhere between the client software (such as MS-DOS Kermit) and the mainframe. For the past 10 or 20 years, the most common place to find the 3270 emulator was on a special purpose "protocol converter": a box that has serial lines on one side and a connection to the mainframe on the other. This box generally works by tricking the mainframe into thinking it is a "control unit" with multiple 3270 terminals attached, and at the same time tricking the terminals into thinking they are communicating with a "normal" ASCII character-at-a-time host. The box converts between 3270 data streams and ASCII terminal (e.g. VT100) conventions. This includes ASCII/EBCDIC character-set conversion, cursor positioning and screen painting, and keystroke interpretation. As you can imagine, all of these conversions would normally have a disastrous effect on Kermit protocol packets, and also upon any other type of data that has to be transmitted "as is", without conversion, such as graphics terminal directives. Thus, many protocol converters support a "transparent mode", that allows the mainframe host to command them to turn off their conversion functions, and at a later time, turn them back on. When everything works as planned, the only Kermit commands required for going through the protocol converter are: set flow xon/xoff ; (usually) set parity even ; (or other) Everything else corresponds to the normal Kermit defaults (remote echo, no "handshake", etc). Unfortunately, the method for entering and leaving transparent mode differs from one 3270 emulation product to another. Ideally, there are two components: (1) the identification phase, in which the mainframe software issues a special instruction that causes the protcol converter to respond in a unique (but harmless) way; and (2) the actual enter- and exit-transparent-mode directives. IBM Mainframe Kermit needs to know which kind of transparency, if any, is used by the protocol converter so it can be put into transparent mode at the beginning of packet protocol and taken out of it upon return to interactive command mode. There are several ways that mainframe Kermit can go about this. First, you can use the SET CONTROLLER command to tell it which style of transparency is used by the protocol converter. Second, mainframe Kermit can be set up by the system administrator to always use a particular style. Third, it can attempt to "autodiscover" the controller type by issuing various types of identification queries and checking the results. The third method is not very reliable, however, since many types of protocol converters fail to respond to these queries even when they do implement a particular style of transparency. Nowadays, special-purpose protocol converters are giving way to general purpose terminal and compute servers that include a "tn3270" function. tn3270 is a special kind of TELNET program that also performs 3270 emulation, and requires that the mainframe be on a TCP/IP network and have a TN3270 server. Here are two examples: 1. UNIX tn3270. Most UNIX systems come with a tn3270 program that lets you make a full-screen connection to an IBM mainframe. Once you have made the connection, you should be able to start Kermit on the mainframe, give it a SEND, RECEIVE, or SERVER command, escape back to your terminal emulator (e.g. MS-DOS Kermit), and transfer files without any special settings. If you have trouble with this, then: . Ask mainframe Kermit to "show controller". If it doesn't say Series/1, then tell it to "set controller series1". . Try using shorter packets. The maximum length that can pass through the protocol converter might be less than what you are trying to use. A typical maximum value might be 1700. . Tell one or both Kermit programs to "set parity space". 2. Cisco terminal server tn3270. Current releases of Cisco terminal server software include a tn3270 feature that is supposed to permit Kermit transfers, but it has bugs. Sometimes these bugs can be worked around by using the methods listed in (1) above and specifying VERY short packets, like 30 or 40 bytes. Sometimes they can't be worked around at all. A future release of Cisco software (probably 10.3) will include new tn3270 software that implements Series/1-style transparency correctly, and allows Kermit transfers of both text and binary files in both directions using packet lengths up to about 1900 (or whatever the total screen size is). If you try all of these workarounds with your terminal server and still get failed transfers, make packet logs and/or debug logs in both Kermit programs to find out what the terminal server is delivering to each Kermit program, and report the misbehavior to your terminal server vendor. For further information about specific protocol converters and how to configure IBM Mainframe Kermit for them, please read the ik0aaa.hlp file that comes with IBM Mainframe Kermit. Finally, it is possible to transfer files through a 3270 fullscreen connection even when 3270 emulator can't be put into transparent mode at all. You can read about this in the C-Kermit update notes file (ckcker.upd) and the MS-DOS Kermit update notes files (KERMIT.UPD). Quoting from the latter: "Doomsday Kermit" (DDK) techniques allow file transfer with IBM mainframes through 3270 protocol converters that do NOT support transparent mode, to be used in conjunction with IBM Mainframe Kermit's SET CONTROLLER FULLSCREEN command on VM/CMS, MVS/TSO, or CICS. MS-DOS Kermit 3.13 or later and IBM Mainframe Kermit 4.2.3 or later required. Commands: SET PARITY EVEN ; Or whatever SET FLOW XON/XOFF ; Or whatever SET SEND START 62 ; Greater-than sign SET RECEIVE START 62 ; Ditto SET BLOCK BLANK-FREE-2 ; New block-check type SET HANDSHAKE NONE BLANK-FREE-2 is a new block-check type, exactly like type 2, except encoded to never contains blanks. Give IBM Mainframe Kermit the following commands: SET CONTROLLER FULL SET SEND START 62 SET RECEIVE START 62 SET BLOCK BLANK-FREE-2 SET HANDSHAKE 0 Doomsday Kermit file transfers are not as reliable as regular Kermit protocol transfers, and they are much slower. Use this method only as a last resort; that is, only when you can't get a transparent-mode fullscreen connection or a linemode connection to the mainframe. (end quote) And beyond finally: in the future, we expect to add 3270 emulation to the Kermit software itself, so you will be able to make tn3270 connections directly from Kermit to the mainframe without having to go through a "black box" for the conversion. Of course, Kermit software will handle transparency correctly (and automatically). (And no, I can't estimate when built-in 3270 emulation will be available.) - Frank ------------------------------------------------------------------------- (6) WHERE IS THE KEY MAP FOR 3270 EMULATION? Real 3270 terminals have all sorts of keys that regular ASCII terminals (and PCs and Macintoshes and UNIX workstations, etc) do not have. A big part of the job of a 3270 protocol converter is to convert between ASCII keystrokes (including escape sequences) and 3270 keys such as PA1 through PA3 and PF1 through PF24. The administrator of the 3270 protocol converter creates the mapping. So in order to make a 3270 key map for Kermit, you first have to find out what the mapping in the protocol converter is, and then assign the ASCII values (characters or sequences) that correspond to each 3270 key to the desired PC (or Mac, etc) key. It is the responsibility of each site administrator to document the key mappings used by its protocol converters. Once you know the ASCII values that correspond to each 3270 key, then it's easy to create Kermit key bindings. For example, suppose the 3270 "cursor left" function (left arrow) is mapped to ASCII Ctrl-B (ASCII character 2). Then in MS-DOS Kermit you would: SET KEY \4427 \2 where \4427 is the scan code of the PC's (gray) left arrow key, and \2 is the code for the ASCII value of the Ctrl-B character. ------------------------------------------------------------------------- (7) CAN I MAKE MS-DOS KERMIT USE COM3, COM4? From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: COM3 available in 3.14? Date: 20 Jan 1995 15:48:20 GMT Organization: Columbia University In article <1995Jan19.232004.8689@midway.uchicago.edu>, Cal Lott wrote: >I was simply wondering if version 3.14 (or any earlier) could >address COM3 and above. > A frequently asked question. The short answer: Yes. The medium answer: COM3 and above have no standard address or IRQ, hence communications software (Kermit or anything else) can't always find them, in which case you have to specify the address and IRQ, using a sequence like: SET COM3 \x3e8 5 SET PORT COM3 (You need both commands, in the order shown.) The long answer: Read section 6 of the KERMIT.BWR file on your MS-DOS Kermit 3.14 diskette. - Frank ------------------------------------------------------------------------- (8) MS-DOS KERMIT PATCHES DON'T SEEM TO TAKE EFFECT. Since the release of MS-DOS Kermit 3.14, there have been persistent reports that patches don't seem to "stick". That is, after giving a PATCH command, the patch level is still reported as 0. This can happen if the patch file is transferred to the PC from a UNIX system in binary mode, so the lines end with LF rather than CRLF -- DOS does not recognize the line boundaries and therefore Kermit does not see valid patches. Cure: make sure each line ends with CRLF. Fix it in an editor, or re-transfer the file in text mode. Also, remember there is no longer a need to rename the patch file to MSKERMIT.PCH. Since there are now three different Kermit executables, there must be three corresponding patch files. For version 3.14, these are: MSR314.PCH -- For full-featured KERMIT.EXE MSRM314.PCH -- For "medium-size" KERMITE.EXE MSRL314.PCH -- For "Kermit Lite" KERLITE.EXE Notice that each patch file includes the version number as part of its name. This allows you to run different versions of Kermit without confusion about patching. ------------------------------------------------------------------------- (9) I CAN TRANSFER TEXT FILES BUT NOT BINARY FILES Here are the causes (and cures) listed in decreasing order of likelihood: 1. You are going through a terminal server or other type of connection (telnet, rlogin, etc) that chops off the 8th bit. Kermit can't tell that this is happening (as it can with devices that add even, odd, or mark parity), so you have to tell it. The command is: SET PARITY SPACE 2. You have used the SET CONTROL CONTROL UNPREFIX command to unprefix one or more control characters that are not safe. Tell Kermit to: SET CONTROL PREFIX ALL and see if it works. If so, you'll have to home in on the offender(s). ------------------------------------------------------------------------- (10) BINARY FILES ARE CORRUPTED AFTER TRANSFER Some non-Columbia Kermit implementations simply do not work, including some found in BBS software. For example, if you download a file from a BBS using their Kermit protocol option and find a lot of Ctrl-Ys in your file where only actual letter Y's should be, then the BBS has a broken Kermit implementation. The same is also true if a file downloaded from a BBS in binary mode is bigger than the original. Ask your BBS sysop to install MS-DOS Kermit ("Kermit Lite") as an external protocol. See the KERMIT.UPD file in the MS-DOS Kermit 3.14 distribution for additional information. The more common cause, however, for "corrupted" binary files is that they were transfered in text mode. Both Kermit and ftp transfer files in text mode by default. This means that record formats and character sets are likely to be converted. You can tell Kermit to skip all conversions and transfer the file literally, as-is, with the command: SET FILE TYPE BINARY Normally, it is sufficient to give this command to the FILE SENDER before giving it the SEND command. But there are some exceptions to this rule: 1. One or both Kermits do not support "Attribute packets" (or they are disabled). This is true of many of the commercial and shareware Kermit implementations. Cure: tell BOTH Kermits to use binary mode. 2. You are using some combination of C-Kermit 5A(190) or later, MS-DOS Kermit 3.14 or later, or IBM Mainframe Kermit 4.3.1 or later in client server mode. In this case, it is the CLIENT's file type setting, rather than the file sender's, that prevails. Cure: tell the CLIENT to SET FILE TYPE BINARY, or to be extra sure, tell them both. 3. You are sending the file from VMS C-Kermit, which is unique among Kermit programs in its ability to automatically switch between text and binary mode based on the file's characteristics. VMS C-Kermit ignores SET FILE TYPE BINARY and SET FILE TYPE TEXT when sending files, and instead uses binary mode if the file's record format is Fixed, and text mode otherwise. However, some binary files, notably VMS ZIP files, are stored using a "text-style" record format (Stream_LF), so Kermit sends them in text mode. You can override this by telling it to SET FILE TYPE IMAGE. If you follow all these directions and binary transfers still come out wrong, then perhaps the file you were downloading was corrupt to begin with -- e.g. it was ftp'd in text mode instead of binary mode. ------------------------------------------------------------------------- (11) WHY DOESN'T THE HANGUP COMMAND WORK FOR ME? On network connections, Kermit's HANGUP command executes the appropriate network protocol for closing the connection, and this should always work. On serial connections, the HANGUP commands turns off the computer's DTR (Data Terminal Ready) signal for a period of time. According to the standard that governs modem signals, this action is supposed to make a modem hang up the phone call. If it doesn't: 1. Your modem has been configured to "Ignore DTR". This setting is available on most Hayes-compatible modems, either on a physical switch (such as Configuration Switch 1 on the Hayes 1200) or as a command (&Dx on Hayes 2400 and later, and compatibles). In many cases, "Ignore DTR" is the factory setting. If you want your modem to obey the DTR signal, then you should set the switch appropriately, or give the command AT&D2. The actual syntax of the command might vary among different brands and models of modems, so consult your modem manual for details. 2. Your cable or connector has DTR "hotwired high", meaning that the DTR wire is jumpered to some other signal that is always high (on). If this is not what you desire, you should replace your cable with a standard modem cable. 3. You are using a Macintosh with a "hardware handshaking cable". This is actually the same situation as (2), except there is no way to "fix" the cable - please read the ckmker.bwr file for an explanation. To work around these problems in Kermit, without actually fixing the underlying cause, you can use a macro that escapes back to the modem's command processor and gives it the command to hang up. Such a macro is predefined for you in the MS-DOS Kermit 3.14 initialization file, MSKERMIT.INI: ; ATHANGUP macro. Use this if regular HANGUP command doesn't do the trick. def ATHANGUP sleep 1,out +++,sleep 1,out ath0\13 You can use exactly the same technique in C-Kermit. It assumes your modem is Hayes compatible, and that your modem's "escape character" is plus-sign; if it isn't, change the plus-signs appropriately. In MS-DOS Kermit and OS/2 C-Kermit, you can even assign execution of this macro to the "hot key" of your choice, for example: set key \315 {\Kathangup} ; Assign ATHANGUP macro to the F1 key In Mac Kermit, you can just go to the terminal screen and do it by hand: . Pause at least one second . Type +++ . Pause at least one second . Type ATH0 (letters A, T, H, digit zero) . Press the return key. Modem should say NO CARRIER. ------------------------------------------------------------------------- (12) HOW CAN I MAKE THE {DIAL, REDIAL} COMMAND KEEP TRYING? In MS-DOS Kermit, the DIAL command is defined in the MSKERMIT.INI file, and it does indeed retry the call several times. REDIAL is also a macro, which simply invokes the DIAL macro with the number most recently dialed; hence it, too, tries the number several times. If you want to change the number of times that the DIAL macro tries, or the conditions under which it retries, or the interval between tries, simply edit the DIAL macro definition in MSKERMIT.INI. In C-Kermit, DIAL and REDIAL are built-in commands, each of which dials once. If you want them to dial more than once, you can define macros as follows. Put the definitions in your .mykermrc or CKERMOD.INI file. Here are some samples: define mydial dial \%1, while fail { redial, sleep 30 } and/or: define myredial redial, while fail { redial, sleep 30 } Embellish as desired. ------------------------------------------------------------------------- (13) I ENABLED SLIDING WINDOWS BUT IT LOOKS LIKE ONLY ONE IS USED. Newsgroups: comp.protocols.kermit.misc Subject: Re: Sliding windows - only one is used? Date: Wed Feb 15 09:21:08 1995 From: fdc@fdc.cc.columbia.edu (Frank da Cruz) In article <3hn07m$4dl@israel-info.datasrv.co.il>, 4th Dimension wrote: >I'm using MS-Kermit 3.14, PL3 on my PC, talking to C-Kermit 5A(190) on >the remote Sun. When I start MSK, I load the FAST macro to get maximum >thruput. Transfer of data is pretty fast, except that I never see more >than one window used out of the three. Is this a bug, a feature, or am I >doing something wrong? > It's not a bug and you are probably not doing anything wrong. When two Kermit programs have agreed to use a maximum window size greater than one, let's say 4, here is what happens: The FILE SENDER can send up to 4 packets without waiting for an acknowledgement from the file receiver. Each unacknowledged packet sits in the file sender's window until it is acknowledged. Thus its window size grows from 1 to 2 to 3 to 4. If acknowledgments arrive quickly, the window might not grow to its maximum size because it does not need to. The job of the FILE RECEIVER is to accept and verify packets, decode them, and write the decoded contents out to the file. If packets arrive in sequence, then each one is processed and disposed of as soon as it arrives. If, however, a packet arrives that has a sequence number that is more than one greater than the previous packet that was successfully processed, this means that a packet is missing. Thus the packet that just arrived can't be written out to disk because if it were, the file would have a piece missing. So the out-of-sequence packet is stored in the receiver's window until the missing piece is filled in. Thus you won't see the file receiver's window size exceed one unless there have been transmission errors, no matter what window size the file sender might be using. For greater detail see pages 102-103 of "Using MS-DOS Kermit" or pages 158-161 of "Using C-Kermit". - Frank ------------------------------------------------------------------------- (14) HOW DO I WRITE A SCRIPT TO DIAL A NUMERIC PAGER? A numeric pager is one that can display a number -- usually the number to be called back. The number is entered by pressing Touch-Tone keys on your telephone, usually terminated by pressing the "#" or "*" key. Numeric pagers are not modems. Therefore when you dial one, it does not return a carrier signal. Therefore, the dialing modem will not say "CONNECT" or turn on its carrier signal. Therefore, DIAL commands will not succeed. You can type commands to your modem manually for testing. For example: ATDT7654321,,,,,8765432#; In this example we Tone-dial the phone number "7654321", then we pause for ten seconds (",,,,,") to give the pager time to answer the call, then we send "8765432" to be displayed on the pager, then we send the "#" tone, and then we return to command mode (";"). The modem should respond "OK". The details will vary with your modem, your telephone service, and the pager you are dialing. Let's assume we have a Hayes 2400 or higher compatible modem. Here's a sample command file to call a numeric pager: define \%a 7654321 ; Number to call define \%b 8765432 ; Number to display on pager set port xxxxxxx ; Select the communication device set speed 2400 ; Any speed supported by the modem output AT\13 ; Make sure it's in command mode input 3 OK ; ... if fail stop 1 Can't get your modem's attention output ATDT\%a,,,,,\%b#;\13 ; Make the call input 3 OK ; ... if fail stop 1 Can't place call You can turn this into a macro that accepts the numbers as arguments. See "Using MS-DOS Kermit" or "Using C-Kermit" for additional script programming instructions, and your modem manual and the pager manual for details of calling and paging. Hint - the commas might cause trouble in a macro, so you'll either have to quote them or break the modem dialing command into two, separated by an appropriate PAUSE. Hint #2 - Some modems might also support a "wait for quiet answer" feature, e.g. by using the at-sign "@" in the dialing string: ATDT7654321@8765432#; ------------------------------------------------------------------------- (15) WHEN C-KERMIT DIALS MY V.32BIS (OR V.34) MODEM, I GET THE ERROR "CAN'T CHANGE SPEED TO 14400 (OR 28800)" Dialing is covered in Chapter 3 and Appendix II of "Using C-Kermit". To recapitulate very briefly: older modems, like the Hayes 1200 and 2400, that did not do error correction or compression, but that could negotiate their modulation speed, would report the modulation speed upon successful connection, and change their interface speed to match. Thus, the communication software would also have to change its own interface speed, or else the user would see only garbage. Modern modems have two different speeds: the interface speed and the modulation speed. The interface speed can be kept constant even though the modulation speed changes. Or not, depending on how the modem is configured. Kermit has no way of knowing whether your modem is set up to lock its interface speed, or to change it to match the modulation speed, and therefore it has no way of knowing whether to believe the "CONNECT 28800" (or whatever) message. By default, for compatibility with the huge installed base of older modems, it does believe, and therefore changes its interface speed according to the CONNECT message. So if your modem's interface speed is locked (which it SHOULD be if it is an error-correcting, data-compressing modem), you must tell Kermit NOT to change its interface speed by giving it the command: SET DIAL SPEED-MATCHING OFF Now to complicate matters, some of the newer modulations report speeds that are not commonly supported by the host operating system, such as 14400 and 28800. Hence the message "Can't change speed to 14400" (or 28800). But even if these speeds were supported, you would not want Kermit changing to them if the modem's interface speed was locked. You would still see only garbage, but you would not get the "Can't change speed" message. See pages 60-61 of "Using C-Kermit" for additional detail. ------------------------------------------------------------------------- (16) HOW DO I USE KERMIT WITH PINE? Here's a tip sheet we use at Columbia University - thanks to Joe Brennan. SCREEN FORMATTING Make sure that your UNIX terminal type agrees with Kermit's terminal emulation. For example, if Kermit is emulating a VT320, tell UNIX: export TERM=vt320 or: setenv TERM vt320 If there is a complaint about "terminal type unknown" when starting Pine, then try a lesser VT terminal model, such as VT220, VT102, VT100. PRINTING Pine's print command, letter Y, is known to work with MS-DOS Kermit and Mac Kermit. With MS-DOS Kermit, if the printer is directly attached, it should make the printer print the selected email message. With Mac Kermit, it should send the selected email message into the printer buffer, which can be seen in the Printer window, and which can be printed using the print command in the pulldown File menu. The command ''pcprint'' on UNIX (*), which prints any text file, does the same thing as Pine's Print command. It may be easier to debug problems by running a command like ''pcprint .profile'' at the UNIX shell ($ prompt). (*) pcprint is a UNIX shell script: ---(cut here)--- echo -n '[5i' if [ $# -eq 0 ]; then cat else cat $* fi echo -n '[4i' ---(cut here)--- (Replace by a real Escape (ASCII 27) character. DOWNLOAD FROM PINE TO THE PC Use Pine's command letter E, Export, to copy a message into a file. This file will be created in your home directory on UNIX. It can then be downloaded to your PC or Mac using Kermit. After you finish, remember to remove the now-unneeded file on UNIX, using the ''rm'' command at the $ prompt. If you View a MIME-encoded message, Pine will ask whether to save it to a file with a name of your choice. Pine will decode the message and create the file in your home directory on UNIX. It can then be downloaded to your PC using kermit. MIME-encoded files are often binaries rather than plain text, so you should set kermit to transfer a binary file. UPLOAD FROM THE PC TO PINE Send email in plain text if possible. Save the document as plain ASCII text with the PC application that created it. Use Kermit to upload it to UNIX. Run Pine, choose letter C, Compose, and address your message as usual. Move the cursor to the Message Text area and choose control-R, Read File, and type the name the file (the copy on UNIX) to insert. You will see the file on screen, as if you had typed it. If it looks strange, it's not plain text, so start over. After you finish, remember to remove the now-unneeded file on UNIX, using the ''rm'' command at the $ prompt. If you want to send a PC document, use Kermit to upload it, setting Kermit to transfer a binary file. Run Pine, choose letter C, Compose, and at the Attchmnt: header, type the name of the file (the copy on UNIX). Pine will encode it using MIME, and attach it to the end of any text you choose to type in the message. *Note*: with MIME or any form of encoding, you should determine whether the recipient of your message will be able to decode it. Plain text email (previous paragraph) can be read on any email system. ------------------------------------------------------------------------- (End)