MS-DOS V9KERMIT 3.13 BEWARE FILE FOR VICTOR 9000 and SIRIUS 1 MS-DOS COMPUTERS [Originally MSKERMIT.BWR for IBM PC Family, Compatibles, and Other MS-DOS computers; minor modifications for Victor 9000 and Sirius 1 computers by R.N. Folsom, October 1993] BUGS, LIMITATIONS, HINTS & TIPS Most recent IBM version update: Thursday 8 July 18:56:14 1993 This file discusses common problems installing or using MS-DOS Kermit and presents solutions or workarounds in many cases. It applies to version 3.13 of MS-DOS Kermit for the IBM PC family and compatibles. See V9KERMIT.HLP (modified from MSKERMIT.HLP) for copyright information, terms and conditions, and a summary of MS-DOS Kermit commands. The user manual for MS-DOS Kermit 3.13 is the book "Using MS-DOS Kermit", Second Edition, by Christine M. Gianone, published by Digital Press, Bedford, MA (1992), order number EY-H893E-DP. Call 1-800-344-4825 (toll free, USA) to order, or order from Columbia University. Changes since the book was published are described in V9KERMIT.UPD (originally KERMIT.UPD or MSKERM.UPD). Please consult "Using MS-DOS Kermit" and this file before contacting Kermit technical support staff. Report problems via e-mail to kermit@columbia.edu on the Internet or to KERMIT@CUVMA.BITNET, or call +1 212 854-5126, or by Fax to +1 212 663-8202, or write to Kermit Distribution, Columbia University Academic Information Systems, 612 West 115th Street, New York, NY 10025, USA. INCOMPATIBILITIES BETWEEN MS-DOS KERMIT 3.13 AND EARLIER VERSIONS: 1. The TERMINALR/S macro capability is replaced by host-initiated change of screen writing direction (details in KERMIT.UPD). As a consequence of this, host-based WordPerfect won't be able to load your key settings (see next section). Any other host software that sent the TERMINALR/S sequences will also need to be converted in similar fashion. See the APC section in V9KERMIT.UPD for further details. 2. STATUS command removed. There is no longer any way to display all of MS-DOS Kermit's settings on a single screen. Now use the SHOW command to display categories of settings: SHOW TERMINAL, SHOW COMMUNICATIONS, SHOW PROTOCOL, etc. 3. STATISTICS, which displays file transfer statistics, has been added as a top-level command, for compatibility with C-Kermit. So if you were used to typing "stat" to get a screenful of settings values, now you will get file transfer statistics instead. 4. Alt-n was previously bound by default to the \Knethold verb. It is now bound to the new \Knextsession verb. \Knethold (used on TES, EBIOS, NASI/NACS, and various other PC networks or asynchronous communication servers) has been moved to Alt-z. WORDPERFECT To make host-based UNIX WordPerfect work with MS-DOS Kermit 3.13, follow these directions (courtesy of Chris Thompson at Vanderbilt University). Presumably similar steps can be followed for the VMS version: . Go into the directory where the terminal definitions are stored (in my case of WP 5.1 for AIX, it was /usr/wp51/shlib), and execute "wpterm" (it usually requires you to be super-user). . A screen containing all the terminal definitions will appear. Highlight the current Kermit terminal definition and hit Create. . It will ask "Model new definition after Kermit?" Answer yes. . It will then ask for a new name for your new terminal definition. Call it something like KERMIT313. . At the bottom of the screen, several options will appear. Choose the option for Terminal Control Characters. It will then bring up a screen with the different initialization strings and their values. The first four items are the ones that need altering (Terminal Initialization, Terminal Reset, Quick Initialization, and Quick Reset). Just delete "[27][?34h" or "[27][?34l" (for initialization and reset, respectively) from the string and replace it with "[27]_take \kermit\wpunix.ini[27]\" or "[27]_set key clear[27]\", leaving the rest of the string intact. . Be sure to change your WPTERM environment variable if you decided to create a definition with a different name. TROUBLESHOOTING MS-DOS KERMIT SERIAL PORT AND MODEM PROBLEMS "Why can't MS-DOS Kermit find my COM3 or COM4 port?" "Why can Kermit send characters to my COM port, but not read them?" "Why doesn't Kermit work with my internal modem?" Rule out the obvious: Is everything connected and turned on? Did you give a SET PORT command for the right device, and did you give it BEFORE any other device-related commands, such as SET SPEED and SET PARITY? Remember, port-related settings apply to the port that was selected in the most recent SET PORT command, so a proper sequence might be: SET PORT COM2 ; First select the port SET SPEED 19200 ; Then set its speed SET PARITY EVEN ; and other parameters for this port... SET FLOW RTS/CTS SET LOCAL-ECHO ON Each of these parameters is remembered for each port, so switching ports (e.g. SET PORT COM1 after you have given the above sequence of commands) changes all these parameters to their previous (or default) values for the port you have switched to. To see communication parameters for the current port: SHOW COMMUNICATIONS Check them carefully to be sure they are what you intended. The following discussion is detailed and technical, but most of it boils down to (a) telling Kermit two numbers, the port address and IRQ value; and (b) fiddling with your modem. Keep that in mind as you read more about PC hardware than you ever wanted to know. HOW A PHYSICAL COMMUNICATION PORT IS ASSOCIATED WITH A DOS COMn DEVICE [Not applicable to Victor; included for information] DOS PCs come with full support for two communication ports, COM1 and COM2, and with provisions for two more, COM3 and COM4. COM3 and COM4 are not well (or consistently) supported in most types of PCs, as are COM1 and COM2 which rarely (by themselves) cause any problems. This discussion considers only COM1-COM4, since higher-numbered COM ports are rare, and in any case not supported by MS-DOS Kermit. The digit in the port name (like the "2" in COM2) is an index into an area in memory that contains the address of the serial port hardware. The PC's Basic Input/Ouput System (BIOS) has four words starting at segment 40 (hexadecimal), word 0, for the addresses of the first four COM ports. Word 0 is for COM1, word 2 (two bytes per word) for COM2, word 4 COM3, and word 6 COM4. To view these addresses: C:\> debug (start the debug program) -d 40:0 (display segment 40) -q (quit the debug program) ("C:\>" is the DOS prompt, "-" is the debug prompt.) Here are the results on a PS/2 with 3 COM ports: 0040:0000 F8 03 F8 02 20 32 00 00-BC 03 00 00 00 00 60 03 .... 2........`. ^^^^^ ^^^^^ ^^^^^ ^^^^^ COM1 COM2 COM3 COM4 The first line (like the one above) contains the COM port information (ignore the other lines, as well as the characters on the right). "F8 03" is the 2-byte COM1 address, expressed in hexadecimal (base 16) with the low byte first. Thus the actual COM1 address is 03F8 hex, expressed in Kermit commands as \x3f8. The COM2 address is 02F8, the COM3 address is 3220, and (since there is no COM4) the COM4 address is 0000. That is how both DOS and the BIOS understand which ports are defined and where to find them. When your PC is powered up, the BIOS startup code checks for serial port hardware (that is, a Universal Asynchronous Receiver/Transmitter, or UART) at the two port addresses 03F8 and 02F8. If it finds a UART at the first address then that address is placed in word 40:0 and declared to be COM1. Then the BIOS tries the second address and if successful this address goes into the first available word at that time, typically 40:2 as the address of COM2. Thus if you remove a COM1 device then a previously COM2 device will appear in the COM1 BIOS storage area as COM1 to DOS and Kermit. What happens to the other two words depends on the PC model and BIOS. The IBM PS/2 BIOS fills in all four words on startup, but most others handle only the first two because that's how IBM did it with the original PCs. So... just setting switches or jumpers on a serial port board or internal modem does NOT necessarily define the board to be a particular COM port. So why do some communication programs work with COM3 and COM4 without any special fiddling? These programs ASSUME certain COM3 and COM4 addresses, even when there are no entries in the BIOS communication-port area. Some of these programs show you their assumptions in a menu (and might allow you to change them), others do not. The assumed values are usually as follows: Port Assumed Address (hexadecimal) COM1 03F8 COM2 02F8 COM3 03E8 COM4 02E8 NOTE: PS/2s use different addresses for COM3 and COM4 -- 3220 and 3228, respectively. Well-behaved communication software (like Kermit) will use these addresses rather than the defaults listed above. Ill-behaved software ignores the segment-40 addresses and erroneously attempt to use its own values, right or wrong. Unchecked use of an assumed port address is DANGEROUS if the device is not really where the software expects, especially if some other kind of device, say a network adapter, is at the given address. It can also produce unwanted conflicts under Windows, OS/2, and DesqView, whose drivers often set the port's segment-40 word to 0 when they want to use the port exclusively and without interference, and then restore the real address when done, and similar unwanted interference with Int 14H redirectors that allow serial-port communication software to be used on network connections. Unlike most other PC communication software, Kermit does NOT attempt to use a communications port unless: (a) It finds its address in the BIOS comm-port area, segment 40, or: (b) You specify the address yourself. AND: The device at the given address passes certain tests, in which registers must contain certain values that are legitimate for a UART. In other words, KERMIT IS MORE CAREFUL than most other communication software, because does not want to risk disrupting normal operation of your PC. SPECIFYING THE PORT ADDRESS [Not applicable to Victor; included for information] If you tell MS-DOS Kermit to SET PORT COMn (where n is 1, 2, 3, or 4), and Kermit responds: Warning, no hardware for this serial port. This port will be operated through the BIOS as BIOSn it means that Kermit did not find an address for the port in the BIOS area or it did find one but the hardware at that address did not look like a UART. If the cause of the message is a missing address, you can tell MS-DOS Kermit the address of the port by issuing the following command: SET COMn \xhhhh where n is 1, 2, 3, or 4, and hhhh are four hexadecimal digits (0-9, A-F) representing the 16-bit address. This command not only informs Kermit of the address, but also inserts the address into the BIOS so other programs can find the port (if they follow the rules), and so you don't have to give this command to Kermit again until after the next time you reboot. After giving the SET COMn command, give a SET PORT COMn command for the same port, e.g.: set com3 \x3f8 ; FIRST specify the address of COM3 set port com3 ; THEN select COM3 How do you know what addresses to give? If have purchased an internal modem or an add-on serial port, the installation instructions should tell you. The device must be configured -- generally by setting little switches or installing or removing jumpers. You have to make sure that the address that you have chosen agrees with the address that Kermit will use. Although it is not recommended that you guess at address values, sometimes it is the only way (as often with inherited equipment), for which occasions here is a list of the addresses commonly used for serial ports and internal modems: Port Likely Addresses (hexadecimal) COM1 03F8 COM2 02F8 COM3 03E8, 3220 (PS/2) COM4 02E8, 3228 (PS/2), 02E0 You probably won't find a serial port at any address not listed above, but you might find a port at another port's expected address. The use of these addresses in SET COMn commands should be relatively harmless (provided you don't also specify an interrupt, explained later); if there is no error message, Kermit found a possibly usable port. If there is an error message, no harm should have been done. Now let's look at the other cause for the "This port will be operated through the BIOS" message, namely that an address was found in segment 40, but the device at that address does not appear to be a genuine serial port. Explanations might include: 1. The device is at a different address. Check your device's configuration again, or else your SET COMn command. 2. Your device is indeed at the given address, but its registers do not contain values expected of a true PC serial port. In that case, BIOS operation is the only alternative. 3. Your device is at the given address, but there is a conflict with another device at that address or the machine's bus speed (not CPU speed) is set so high that the hardware test gave confusing results. When Kermit operates a port through the BIOS, rather than directly, it will be MUCH slower and might not work at all because the BIOS requires the CD, CTS, and DSR modem signals to be asserted by the device connected to the port (and the CD signal is normally NOT asserted by a modem before it has made a connection to another modem). In that case, you will have to configure the device (e.g. modem) to assert DSR, CTS, and CD always, or wire your modem cable to fake these signals (e.g. by connecting CD and DSR together). Assuming you have found the right address for your COM3 or COM4 port (or nonstandard address for COM1 or COM2), and you want these addresses to be set correctly for Kermit at all times, even if it doesn't read its initialization file, you can put a command like the following in your AUTOEXEC.BAT file: set kermit=com3 \x3e8; com4 \x2e8; INTERRUPTS [Not applicable to Victor; included for information] "I can send characters to the modem, but I never see any on my screen." This complaint (often arising from the user's observation of the modem lights and speaker), also known as "can-talk-but-not-listen syndrome", usually means that the communication device was found at the expected address, but Kermit's idea of its interrupt is wrong. What's an interrupt? To achieve high-speed communication without impacting other applications, Kermit reads characters from a serial device using "interrupts". Whenever a character arrives at the serial device, the device sends a signal, called an interrupt, that can be "caught" by application software like Kermit, leaving the application free to do other work in the meantime without having to constantly look at the serial port to see if any characters have arrived (an operation called "polling", which is used by some other communications programs). Communications programs that use polling are not sensitive to interrupts being set improperly and might therefore work with improperly- configured machines where Kermit will not (until you give it the required information), but they also tend to take over the entire computer. In contrast to polling programs, Kermit is normally waiting for input from the keyboard, and is therefore idle if you are not typing and no characters are arriving at the communication port. In multi-tasking environments such as Windows or OS/2, this allows other applications the largest possible share of the CPU while Kermit is running. When a character arrives at the port, an interrupt signals Kermit to wake up from its keyboard-wait state and read the character from the port. But Kermit needs a way of knowing which device the interrupt came from, so it will not erroneously read characters from the wrong one. The device is identified by an Interrupt Request (IRQ) number, a small number like 3 or 4. The BIOS does not record the IRQ number used by a serial port because the BIOS uses polling rather than interrupts. The communications software has to know which IRQ to use. By convention from the original IBM PC, COM1 uses IRQ 4 and COM2 uses IRQ 3. There is no standard for COM3 and above, but certain conventions are normally followed: Port PS/2 Others COM3 IRQ3 IRQ4 COM4 IRQ3 IRQ3 WARNING: Certain serial port cards and internal modems allow themselves to be configured with different IRQ numbers (such as 9), even on COM1 or COM2. Check your device's installation instructions. Some types of PCs (PS/2s, for example) allow sharing of IRQ numbers, provided each application has its own interrupt service routine and each such routine is built to "chain" interrupts properly (i.e. pass them along to other applications if they have arrived at the wrong place). This works, for example, with Kermit on a PS/2; you can run two copies of Kermit under Windows, one using COM2/IRQ3 and the other using COM3/IRQ3 (i.e. two ports, same IRQ), both doing input and output simultaneously with no confusion. But on most types of PCs, IRQs can NOT be shared, so each device must have a unique IRQ number. This caution applies especially when you have a serial mouse on IRQ 3 or 4. Once Kermit knows the COM port's address, it tests to see which IRQ number, 3 or 4, the device uses. This is a safe test and doesn't cause any modem signaling or communication to take place. The PC architecture has a limited range of IRQ numbers available, and so (usually) there can not be a unique IRQ number for each serial port when there are more than two, so in most cases no more than two serial ports can be active at once. MS-DOS Kermit tests first for IRQ4, and then if there is no response, IRQ3. If both tests fail, a default value is used (on PS/2s, the default is IRQ4 for COM1 and IRQ3 for COM2-4; on others is it is IRQ4 for COM1 and COM3, IRQ3 for COM2 and COM4). No error message is given in this case, but "can-talk-but-not-listen syndrome" is a likely result. Some add-on communication boards or internal modems are set up to use IRQ numbers other than 3 or 4 in order to avoid conflicts with COM1 or COM2 and/or to allow more than two COM ports to be active at once. But this can be dangerous -- for example, IRQ 5 (which is often used for this purpose) is also used by the hard disk controller on the PC/XT. IRQ 7 is often used by network boards. For this reason, Kermit does not automatically test any IRQ numbers other than 3 or 4, and does not use any other IRQ number by default. But it is sometimes necessary, particularly on ISA (Industry Standard Architecture) bus machines (PC/ATs and compatibles) and earlier (such as PCs and XTs) to use an IRQ other than 3 or 4, for example when when an internal modem is installed as COM3 on IRQ4, and then use of COM1 prevents COM3 from working, and vice versa. This problem can often be solved by reconfiguring the board to use an otherwise unused unique IRQ number. Ideally this would be a normally free IRQ such as 10 or 11, but unfortunately most communication boards are not configurable for IRQs higher than 7. Here is a brief, and definitely not comprehensive, guide to the low IRQ numbers (with IRQ numbers expressed in decimal): 2 Normally available, but some video boards use it to obey an obsolete standard for indicating vertical refresh. Adjust video board jumpers to not do this. On 286's and above, IRQ 2 is also known as IRQ 9: same IRQ, alternate number. Windows 3.0 had difficulty with devices using IRQ 2, but Windows 3.1 is better. 3 Normally COM2 and COM4. PS/2's use IRQ 3 for all serial ports above COM1. IRQ3 is also a favorite "factory default" of many local area network (LAN) adapters. 4 Normally COM1 and informally COM3 (except on PS/2s). 5 Secondary parallel port. Parallel ports are rarely interrupt-driven (except for Novell RPRINTER users) so this wire becomes free if you unjumper the IRQ on the parallel port board. LAN adapters are frequently placed on IRQ 5. PC/XTs use IRQ 5 for the hard disk. Be careful with this one. 6 Floppy disk drives. Leave it alone! 7 Primary parallel port. Remove as described for IRQ 5. Be careful, LAN adapters are frequently placed here. 9 Alias for IRQ 2. 10 Usually free. 11 Usually free. 12 Used by the IBM bus mouse, otherwise usually free. 13 Math coprocessor errors are trapped here, otherwise frequently free. 14 Used by hard disk on 286 and above. Leave alone! 15 Some SCSI controllers use this. Usually free. If your communication board uses an IRQ other than 3 or 4, you will experience the "can talk but not listen" syndrome when using Kermit. To fix it, simply inform Kermit of the device's IRQ number. This is done in the SET COMn command, after the address: SET COMn
for example: SET COM3 \x03e8 5 When you include a number (like 3, 4, 5, 6, or 7) after the port address (separated by a space), Kermit skips its IRQ test and uses the IRQ number you specified the next time you give a SET PORT command for that port. AVOID address and IRQ conflicts; these items MUST NOT overlap existing equipment. SERIOUS DAMAGE can result if, for example, the IRQ number you give is the same as the one used by your disk controller or network adapter. Incorrect operation can result if the interrupt is in use by a less critical device, such as a mouse. It is necessary to specify the IRQ number in either of these two situations: 1. The communication device uses an IRQ number other than 3 or 4. 2. Kermit's IRQ test interferes with Windows or a similar environment. Check your PC's configuration carefully before specifying an IRQ number. Before starting Kermit, you can use certain public domain or commercial utilities, such as MAPMEM, Northgate QAPLUS, Quarterdeck MFT, or the MSD utility shipped with Windows 3.1 to get an idea of which IRQ numbers are already in use (these utilities are, of course, not foolproof -- for example, they can't tell what IRQs are used by programs that are not presently loaded). If, even after establishing the device's interrupt, Kermit still fails to operate correctly (or reliably), check to see whether: 1. Some other device (such as a mouse or LAN adapter) is generating the same interrupt. 2. Some other software (such as a mouse or video driver) is catching the same interrupt. If you find a conflict, you'll have to resolve it: remove the offending device driver or TSR from your CONFIG.SYS or AUTOEXEC.BAT file or turn it off temporarily (e.g. with the MOUSE OFF command for certain mouse drivers); or, if possible, reconfigure one of the conflicting devices to use a different interrupt. Example: A PC (not PS/2) is delivered with a serial mouse on COM1 and with COM2 as a free serial port. COM2 can be used with an external modem, but you can't put an internal modem on COM3 because its IRQ conflicts with the mouse and the COM4 address clashes with an 8514/A video adapter (such as the ATI Ultra+). Neither the mouse interrupt nor the video board address can be changed. So to install an internal modem, you must remove the serial mouse and driver and, if you need a mouse, replace it with a bus mouse. PROBLEMS WITH MODEMS "I just bought and installed an XYZ V-Dot-Everything internal modem, and it works with communication package, but not with Kermit". This has long been a common complaint about internal modems. The same complaint is also now being heard with alarming frequency about some of the newer external modems. With internal modems, particularly when they are installed on COM3 or COM4, the most common problems are: 1. Kermit doesn't know the modem's address, or the device is using an IRQ number other than 3 or 4. These problems can be fixed by giving the appropriate SET COMn command to Kermit. 2. The internal modem is installed incorrectly, with an address or IRQ that conflicts with one already in use on your PC. 3. The internal modem does not correctly emulate a real IBM PC serial port, and therefore fails Kermit's hardware test, and therefore can only be used through the BIOS. 4. The device is in a laptop, notebook, or palmtop computer, and power to the internal modem or serial port has been disabled in the CMOS setup, or has been turned off automatically when the cover is closed or the machine shut down. In mid-1992, a new generation of low-cost, high-speed modems, both internal and external, began to appear on the market. These modems typically offer a wide range of features: V.32 and V.32bis modulation, V.42 and MNP error correction, V.42bis and MNP data compression, etc. Unfortunately, many of these modems suffer from bugs not found in earlier modems. The problems are generally related to initialization of the modem and interaction with its command processor. Some common complaints: 1. "The modem won't dial or respond to commands". Or the modem ignores commands when Kermit's PARITY is set to a particular value, like EVEN. Or commands are not processed correctly above a certain interface speed. 2. "I can dial successfully, and in general send characters to and through the modem, but I never get any characters back." This looks suspiciously like the "talk-but-not-listen" problem, but in some cases it is a bug in, or a configuration problem with, the modem, having nothing to do with Kermit: the modem is simply not sending any characters to the PC. 3. "After using the modem with communication software, it also works with Kermit, but it won't work with Kermit unless I run first." 4. "I can communicate in command-mode with the modem, up until I give it an ATZ command, at which point it seems to die." 5. The modem does not pass the BREAK signal. 6. The DSR signal goes off after successful dialing. And so on. All of these are modem, not Kermit, problems. Some suggestions for overcoming them: 1. Before giving a DIAL command, which invokes a macro containing OUTPUT commands for the modem's command processor, give the command: SET OUTPUT PACING For example: SET OUTPUT PACING 100 OUTPUT AT Q0 E1 V1 &F\13 2. External modems only: Check that your modem cable has wires for (at least) the TD, RD, SG, CTS, RTS, DSR, CD, and DTR RS-232 signals. If it does not, replace the cable with a real modem cable, or (temporarily) configure your modem to compensate for the missing signals. 3. Read your modem manual and check your modem's configuration. Perhaps its interface speed is locked to a different speed than the one Kermit is using. Perhaps Kermit is set to use RTS/CTS flow control, but the modem is not asserting CTS. Also, check its factory and/or saved settings, and under what conditions they are restored (for example, are they restored when the PC drops DTR?). How are you selecting saved settings -- read your modem manual about (e.g.) the difference between AT&F and AT&F2. Be aware that the AT&Fn commands might not restore all S-registers, so double check them. Be particularly sensitive to the registers that control interface speed, modulation technique, error correction, data compression, negotiation, and fallback, and note that each modem maker probably uses different registers and commands to control each of these features. 4. Try the following sequence to initialize the port (using COM3 in this example): SET COM3
; (if necessary) SET PORT 3 ; Select port 3 HANGUP ; Drop DTR on port 3 SET PORT 3 ; Re-initialize port 3 5. SET PARITY NONE when talking to the modem, and then set parity to whatever the remote host or service requires after making the connection. (NOTE: MS-DOS Kermit might set its parity to some other value automatically as a result of automatic parity detection during file transfer.) 6. Ensure your PC bus speed is 8MHz. Some PCs (not PS/2s) come with a BIOS SETUP facility that lets you change the PC's bus speed, memory wait states, etc. In general, it is dangerous to deviate from the defaults, particularly from the 8MHz bus speed, a standard for add-on devices; it might be required by your communication board or internal modem. 7. Dial at a lower speed. Make your interface speed match the modulation speed -- e.g. use 9600 for V.32, 2400 for V.22bis, etc. Turn off modem error correction and compression. etc etc. NOTE: connection problems between the two modems have nothing to do with Kermit and are beyond the scope of this document. If a modem appears to dial correctly, gets connection tones, and then hangs up, it is a problem between the two modems (involving one or both modems and/or the phone company), and indicates a modem configuration problem, a bug, or a basic incompatibility between the calling and answering modems. 8. The ATZ problem. If the modem doesn't work after an ATZ command, HANGUP and the SET LINE again. If that doesn't do it, power the modem off and on. 9. If the modem can't be configured to pass the BREAK signal, but it does correctly implement a command for sending BREAK, such as AT\B9, define an MS-DOS Kermit macro, SBREAK, to send a BREAK as follows: define sbreak pause 1, output +++, pause 1, output ATB\{92}9\13, - pause 1, output ATO\13, connect and assign it to the key of your choice, for example F1: set key \315 {Ksbreak} 10. Call your modem maker's technical support number. Ask if they have replacement chips to fix bugs in your modem. DISK INTERRUPT CONFLICTS On certain PCs, Kermit file transfers (or terminal sessions that are being logged to disk) through serial communication devices (COM1 thru 4) can suffer from data loss during disk read/write operations. This is apparently because, on these PCs, the entire interrupt mechanism is TURNED OFF during disk reads or writes. Thus, while the disk driver is active, no interrupts are generated by incoming characters, and therefore they are likely to be lost (particularly if the UART does not have its own buffer). If you experience data loss during uploads (watch the "Retries" counter), try sending the same file from a RAM disk; if the retries go away, your PC has this problem. If downloads to disk have lots of retries, try downloading the same file to the NUL device (tell MS-DOS Kermit to RECEIVE NUL); same deal. On some PC's, it has been observed that the disk-interrupt conflict occurs when using a certain COM port, but not a different one. For example, on a PS/2 Model 70 A20, conflicts occur on COM2 but not COM1. MS-DOS 5.0 AND 6.0 [Not applicable to Victor; included for information] You should not use MS-DOS Kermit (or other communications software) under DOSSHELL. Unlike Windows, DesqView, OS/2, etc, DOSSHELL is NOT a multitasking environment. MICROSOFT WINDOWS, DESQVIEW, OS/2, ETC. [Omitted; Not applicable to Victor] VIDEO PROBLEMS [Not applicable to Victor; included for information] Kermit does not mix well with NNANSI.SYS, a public domain (or shareware?) console driver that replaces ANSI.SYS, and which implements "hardware scrolling", a case of two non-cooperating programs directly manipulating the video adapter at the same time! Similar comments apply to other console drivers that access the screen directly, including ANSI.COM (from PC Magazine, circa 1988). To turn off NNANSI.SYS's direct screen access, put the following commands in your MSCUSTOM.INI file: echo \27[=98l ; Reset "fast mode" define on_exit echo \27[=98h ; Set "fast mode" SERIAL COMMUNICATIONS [UART discussion not applicable to Victor; included for information] On PCs with high-quality buffered UARTs, Kermit can be used at speeds up to 57600 bps under DOS (under Windows or DesqView, the maximum speed is probably lower). 115200 bps works only with a very short shielded cable, and the async adapters of the two machines in perfect tune. Some VAX serial port interfaces are out of tolerance at 19,200 bps and faster. Some of the new high-speed PCs (486s like, for example, the IBM PS/VP or the Gateway 2000) come with unbuffered UARTs. Despite the speed of the CPUs, these new machines perform serial communications less reliably than older machines that run at 1/4 the speed or less, but that have buffered UARTs (like the PS/2-70). MS-DOS Kermit will tell you whether you have a buffered UART: SET PORT 2 SHOW COMMUNICATIONS ... COM1 Address: Port \xf38, IRQ 4, 16550A UART FIFO 16550A UART means you have the good kind, FIFO means it has a "First-In First-Out" buffer. If Kermit does not say you have a 1655A UART FIFO, and you are suffering from performance or data loss problems, replace it (if possible!) with a 16550A. If your speed is set too high, the symptom might be lost or garbled characters or graphics images on the screen, or data-overrun beeps. Normally flow control prevents these problems so use it if you can. Printing while in CONNECT mode needs flow control to be active. MS-DOS Kermit does not monitor the communication line for carrier loss during terminal emulation or file transfer. You can SHOW MODEM or SHOW COMMUNICATIONS to inquire about CD, DSR, and CTS. The script command WAIT permits sensing carrier presence in a script program. The SHOW MODEM and WAIT commands work right only if your modem or other communication device is configured to raise and lower the DSR, CTS, and CD signals appropriately, and the cable that connects your PC to the modem passes these signals through. For some modems, the factory setting is to always keep CD on, even if there is no connection. Consult your modem manual. For serial devices, the HANGUP command (and Ctrl-]H in CONNECT mode) works only if the cable that connects your PC to the communication device passes the DTR signal through, and if the communication device itself is configured to hang up or otherwise terminate the connection when the DTR signal is lowered by the PC. For some modems, the factory setting is to ignore DTR transitions. Consult your modem manual (for example, tell a Hayes modem to "AT&D2"). NOTE: in version 3.11, the HANGUP command turned off DTR for about 1/2 second and then turned it back on again. In version 3.12 and later, the HANGUP command turns off DTR until the next time you issue a command that accesses the serial port. If you can't make the HANGUP command work, define a macro to send a hangup command to the modem, for example (for Hayes modems): DEFINE MYHANGUP PAUSE 1, OUTPUT +++, PAUSE 1, OUTPUT ATH0\13 and then use this macro in place of the regular HANGUP command. TERMINAL EMULATION Kermit's VT320/340 emulator lacks the following features: . Smooth scroll . Downloadable soft fonts . ReGis graphics (VT340/330) . Dual sessions in split screens (VT340/330) . Local screen editing and block transmission (for security reasons) . True double height/width characters (these are simulated) . Selective erasure (as a character attribute, a formatted screen item) . Some of the exotic and rarely-used features of the DEC VT340/330 series: formatted screen and graphics operations highly specialized to DEC hardware. MS-DOS Kermit does not include "ANSI" or "PCTERM" emulation. If you need this, as when logging in to a PC-based BBS, make sure you have the ANSI.SYS (part of DOS) console driver loaded, and then tell MS-DOS Kermit to SET TERMINAL TYPE NONE, SET PARITY NONE, and SET TERMINAL BYTESIZE 8, and make sure your PC's code page agrees with what the BBS thinks it is, otherwise box-drawing characters might come out looking like accented letters. Since Kermit's own terminal emulator is not active when your terminal type is NONE, the mode line, screen rollback, similar features are not available. On certain "national keyboards", like the German one, Kermit's normal escape character, Ctrl-] (Control-Rightbracket) does not seem to work. This is because certain control characters are typed differently on these keyboards. On the German keyboard, Ctrl-] is produced by holding down the Ctrl (Strg) key and pressing the + (plus) key. MS-DOS Kermit has no way of knowing this, and continues to display the escape character as "^]" in the mode-line help text. Kermit does not work with certain Swedish keyboard drivers because of a bug in the keyboard driver. Workaround: use a different keyboard driver. Reportedly there are several different Swedish keyboard drivers available. Do not attempt to plug an "enhanced" (101) keyboard into a PC/XT or earlier. The BIOS on early PCs does not support the newer keyboards, even if you install the corresponding keyboard driver. If VAX/VMS thinks you have a VT220 or VT320, it sends 8-bit control sequences. Kermit does not understand them unless you SET TERMINAL BYTESIZE 8. The symptom is the appearance of fragments of escape sequences on the screen and wrong cursor positioning, and possibly fractured tab settings, particularly during EVE sessions. You can prevent VMS from sending 8-bit control sequences (if you really do not have an 8-bit connection) by giving the VMS command SET TERMINAL /NOEIGHT. For VAX/VMS, you should also use Xon/Xoff flow control in both directions (SET TERM /TTSYNC /HOSTSYNC on VMS). In VT100/200/300 emulation on the IBM PC family, receipt of ESC [ 4 m (turn on underscore) results in a color change rather than underscore on IBM CGA, EGA and other color displays. IBM display adapters have one less attribute than DEC monochrome terminals, and in addition the two systems intensify dots differently (IBM does foreground/character dots only, whereas DEC can illuminate any dot). SET TERMINAL COLOR 1 [3xx 4xx] (used to make the foreground color bright), if issued when SET TERMINAL SCREEN REVERSE is in effect, reverts to normal video. If certain incomplete escape sequences (e.g. Operating System Command) are received during terminal emulation, Kermit can hang waiting for the string terminator that never comes, usually because of noise on the communication line. Reset the terminal emulator by pressing Alt-= (Alt-equals), the default key for \Kreset. Kermit assumes 25 screen lines but can adapt to other lengths if it knows how to get this information from the video adapter. There still might be some confusion about screen length when switching between text and graphics modes, or between 80 and 132 column mode, or escaping back from CONNECT mode, due primarily to lack of reliable or consistent information from the many different kinds of video adapters. To get properly formatted screens during terminal emulation, be sure to inform the remote host of your screen width and length. So that key translation and macros can work on both IBM and non-IBM compatible PCs, Kermit uses the system BIOS to obtain key scan codes. But the IBM BIOS does not produce scan codes at all for certain keys, and may produce duplicate scan codes for others. Num Lock, Print Screen, Scroll Lock, and Pause are examples. When you PUSH to DOS (including when you use Kermit's RUN command), and you have XON/XOFF flow control enabled, Kermit sends an XOFF (Ctrl-S) to the host when you leave, and XON (Ctrl-Q) when you return (if you have RTS/CTS flow control enabled, Kermit turns off RTS). This prevents data transmitted by the host from being lost. However, if you are using Xon/Xoff and you do this while using the EMACS text editor on the host, the Ctrl-S will be interpreted as a Search command, and the Ctrl-Q as a Quote command. When you return to EMACS, type several Ctrl-G's to get back to normal. Similar comments about sending Xoff and Xon apply when Kermit is commanded to change its screen size between 80 and 132 columns. Session logging can be turned on using the LOG SESSION command, and it can be toggled on and off during terminal emulation by using whatever keys are associated with the verbs \Klogoff and \Klogon. One user stated the requirement to enable a session log, but to have it initially turned off. This can be done as follows (using the F1 and F2 keys as examples): SET KEY \315 {\Kloginit} ; F1 to turn on log SET KEY \316 \klogoff ; F2 to turn log off DEFINE loginit log session, set key \315 \klogon, define loginit, connect To log your session to a printer, add the word PRN after "log session" in the third line above. The session log is written to disk by DOS. The frequency with which DOS updates this file is governed by the BUFFERS= line in your CONFIG.SYS file (see your DOS manual). If you allocate a large number of buffers in CONFIG.SYS, disk operations occur infrequently and this improves performance. If you need to have the session log updated more frequently to minimize the loss of data when there is a power failure, you can do this (at the expense of efficiency) by allocating a smaller number of buffers in CONFIG.SYS. 132-COLUMN MODE If you have a monitor with fixed horizontal frequency but a video adapter that Kermit knows how to switch into 132 column mode, you will see only garbage on your screen whenever Kermit switches to 132 columns. There is no way to tell Kermit to ignore "switch to 132 columns" commands. If you buy a 132-column-capable video adapter, be sure you have a compatible monitor. GRAPHICS TERMINAL EMULATION In earlier releases, MS-DOS Kermit responded to ESC 1 and ESC 2 for automatically switching into and out of Tektronix graphics mode, for the benefit of some long-forgotten host-based graphics software. This feature has been discontinued because these escape sequences mean something entirely different, namely "switch character size" in VT340 Tek mode. PS/2 Model 25 and 30 MCGA adapter is used in low-resolution CGA mode by default; images may be elongated or truncated. Hi-resolution graphics can be done (as of version 3.11) via SET TERM GRAPHICS VGA, but the PC might not be able to keep up at speeds above 9600 bps. When you type the escape character (normally Ctrl-]) while in Tektronix graphics mode, the screen goes back to text memory. Then when you type the argument character, the graphics screen reappears (unless the argument was C or P). Ctrl-]F will not file the graphics screen, but rather the text screen, because that's the screen that's showing after type the Ctrl-] key. To file the graphics screen (in TIFF format), use \Kdump (normally on Ctrl-Keypad-End). You can't dump the Tektronix screen while the GIN-mode crosshair cursor is active; Kermit's keyboard translator is not active. Key strokes (of regular typewriter keys) or mouse actions are used to transmit the crosshair coordinates. If you press a non-typewriter key, Kermit just beeps. Kermit does not emulate a particular kind of color graphics terminal, such as a DEC ReGIS display or a Tektronix 41xx or 42xx series. However, it can be used for color graphics by mixing ANSI color-setting escape sequences with Tektronix or Sixel commands. This requires graphics software vendors adding support for MS-DOS Kermit graphics to their packages (so far, WordPerfect Corp has done this for their host-resident products). There is at least one ReGis-to-Sixel converter on the market: RETOS, a DEC product for VAX/VMS. Problems may occur when using Kermit with host-resident (VAX/VMS) versions of WordPerfect because the color palette report sent upon request of WordPerfect is very long. If the host is not configured properly, parts of the report will be lost because of overruns on the VMS side. SET TERM /HOSTSYNC and /TTSYNC are required for WP/VMS. Even then intervening communication boxes (e.g. terminal servers) can become overloaded with the 200++ byte response. PRINTER SUPPORT Kermit uses DOS services for printing. There is no knowledge of particular printer types in Kermit. Kermit determines whether the printer is ready, or whether there has been a printing error, via DOS's return code. If DOS tells Kermit the printer is not ready, Kermit changes the printer device name to NUL so subsequent print operations won't block. To reenable printing operations (e.g. after turning on the printer, adding paper, etc), use a SET PRINTER command such as SET PRINTER PRN or SET PRINTER LPT1. The Print Screen and Shift-PrintScreen keys are never seen by Kermit. They are intercepted and acted upon by the BIOS. Thus Kermit has no control over the format of the printed output. For example, a formfeed is not added to the end to force a page eject. If you want to print the current screen with a formfeed at the end, use the following procedure: SET DUMP PRN ; Specify that screen dumps go to the printer and then use the \Kdump keyboard verb to accomplish the screen dump. This verb is assigned by default to the keypad Ctrl-End key, but you can assign it to another key of your choice (but not Print Screen), for example: SET KEY \315 \Kdump ; Assign screen dump to F1 (Shift-)Printscreen can cause the PC to hang if there is no attached printer. This is a BIOS feature, Kermit never receives the command. If this happens during terminal emulation, try pressing Alt-= (hold down Alt and press the "=" key) several times to reset the terminal emulator. Serial printers are not well supported by DOS, and since Kermit does all its printing through DOS, Kermit's printing features might not work well with serial printers. To use a serial printer effectively, you must have a driver for it that takes care of flow control, such as MSPSPD, available on the MS-DOS Kermit Utilities and Technical Documentation diskette. Transparent printing starts when the host sends the sequence ESC [ 4 i and stops when the host sends ESC [ 5 i. All characters, including escape sequences, that arrive at the port are passed directly to the printer without translation (but the parity bit is stripped if Kermit's parity is not NONE). If character translation is desired, or it is desired not pass screen-control escape sequences to the printer, use Autoprint rather than Transparent print (ESC [ 0 i, ESC [ ? 4 i, ESC [ ? 5 i). In that case, characters are translated to the current IBM code page. If your printer doesn't support your IBM code page, you need an external utility to translate from the PC code page to the printer's character set. You can use SET PRINTER xxxx to capture Transparent print or Autoprint data into a file. INTERNATIONAL CHARACTER SETS MS-DOS Kermit does not directly support Cyrillic terminal sets; that is, you can't set your TERMINAL CHARACTER-SET to a Cyrillic set. However, you can still have a Cyrillic terminal session if you have a Cyrillic code page loaded and you have issued the appropriate collection of SET KEY and SET TRANSLATE INPUT commands (see the CYRILLIC directory on the distribution diskette). MS-DOS Kermit does not support Japanese Kanji character-set translation during terminal emulation. However, version 3.13 does support the Kanji video mode used on IBM-compatible DOS/V PCs, which allows Kanji terminal emulation if the remote character set happens to be Shift-JIS (CP982). Character-set translation during terminal emulation is done between the remote TERMINAL CHARACTER-SET and the PC's current code page. During file transfer, it's between the TRANSFER CHARACTER-SET and the PC's code page. At startup, MS-DOS Kermit asks DOS to report the current code page, and it sets your FILE CHARACTER-SET and your TERMINAL CODE-PAGE to this value. But DOS often lies about the code page, so in most cases when your actual code page is anything but 437 (or maybe 850), you, yourself, will have to tell MS-DOS Kermit what your code page *really* is, using the following two commands: SET TERMINAL CODE-PAGE CPnnn ; Your actual current code page. SET FILE CHARACTER-SET CPnnn ; The code page for incoming text files. The two would normally be the same, but MS-DOS Kermit lets you set them differently if you want to, for example if you have a Hebrew code page loaded for display purposes, but you want to download a Russian file that you will display later, after loading a Cyrillic code page. MS-DOS Kermit does not allow all possible combinations of FILE and TRANSFER character sets. The Hebrew code page (CP862) forces the Hebrew transfer character set, and vice-versa. Similarly for Cyrillic and Latin-2, etc. Latin-1, however, can be used with many code pages: 437, 850, 861, 863, 865. Some of the ISO 2022 or DEC-specific character-set designation escape sequences, which *do* work correctly, nevertheless fail to have an effect on the character-set field of the SHOW TERMINAL display. LOG SESSION records characters that arrive at the serial port, before translation by either Kermit's built-in terminal character set translation tables or by user-specified SET TRANSLATION INPUT commands. This allows REPLAY to work correctly but it prevents special characters from being logged after translation to the PC's own character set. Screen dump (Ctrl-End or Ctrl-]F) and autoprint, however, record the translated characters. SET TERMINAL CHARACTER SET is effective only for text screens, not for graphics screens. This is because the fonts for all the special characters have not been designed yet (and may never be, and even if they are, they would require a lot of memory). International characters in macro names are not case independent. Case-independent string matching operations (e.g. SET INPUT CASE IGNORE, IF EQUAL xxx yyy) won't necessarily work with international characters. COMMAND PROCESSING When a command field begins with the @ (at-sign) character, the following characters are interpreted as a filename that contains the rest of the command. If you need to type a command field that actually starts with @, or respond to an ASK or ASKQ query with text that starts with an atsign, you have to encode the atsign as \64 or \{64}. \B in an OUTPUT command tells Kermit to send a BREAK. \L Tells Kermit to send a Long BREAK. If you need to output \B or \L literally, use two OUTPUT statements, e.g.: define xbreak pause 1, output +++, pause 1, output AT\92, output B, - pause 1, output ATO\13, connect set key {\Kxbreak} Notice that the backslash itself is written as "\92" to output it literally. Certain commands, such as RUN, DIRECTORY, TYPE, etc, invoke COMMAND.COM "underneath" Kermit, and COMMAND.COM might, in turn, invoke other programs. If you get the message "Can't run program" in response to such a command, it usually means there is not enough memory. But you should also check your SHELL environment variable. If you include the word STAY anywhere on the Kermit command line, e.g.: kermit echo stay it is interpreted as a STAY command. A command file that contains lines or commands too long for DOS's line buffer (usually 128 characters) can hang your PC: a DOS problem, not a Kermit problem. Commands in command files can be continued by including "-" as the last character on the line, but NOT if the line ends with a trailing comment. In other words, you can't have a trailing comment on a continued line. If you need to end a line with a dash, but the dash is part of the command rather than a continuation symbol, use \45 instead or add a trailing comment. Trailing comments can be used only in command files. All text starting with the first semicolon through the end of line is ignored. If you need to include an actual semicolon in a command, precede it with a backslash (\;). The name and password that you specify in SET SERVER LOGIN must be matched exactly by the ones in REMOTE LOGIN. Case matters. If you need to include spaces within the username, password, or account field of the REMOTE LOGIN or SET SERVER LOGIN commands, surround the field with {braces}. DISABLE ALL is not equivalent to all the other DISABLE commands given separately. For example, DISABLE DELETE restricts REMOTE DELETE commands from the client to working only in the MS-DOS Kermit server's current directory, while DISABLE ALL prevents all types of modifications to the PC's file system, including file deletion and creation. KEY MACROS Key macros are executed while in CONNECT mode. If you assign the \Khangup verb to a key, Kermit remains in CONNECT mode after the hangup takes place. On a serial dialup connection, Kermit turns off the DTR signal, and you should see a confirmation message from the modem, such as NO CARRIER, on your screen. On a TCP/IP network connection, however, Kermit does indeed drop the connection, but since Kermit is still in CONNECT mode, it is immediately reestablished. If you want to terminate a network session by pressing a key, use a method that leaves CONNECT mode. You can do this by defining a macro to hang up, and then assigning execution of the macro to the key, e.g. Alt-d: define xxx hangup set key \2336 {\Kxxx} This causes Kermit to return from CONNECT mode and execute the macro without returning to CONNECT mode. This technique works for both serial and network connections. To assign several verbs to a single key, use braces as in this example: set key \315 {\{Kgold}\{KdecF13}} or this: set key \315 {\{Kfoo}\{Kdump}\{Kbar}} in which "foo" and "bar" are macro names, and \Kdump is Kermit's screen-dump verb. FILE TRANSFER SET EOF CTRL-Z, when used with text files that actually contain Ctrl-Zs, might result in gaps or truncation in the vicinity of the Ctrl-Z. This is a DOS "feature". When using Kermit through a terminal server (particularly those that execute the TCP/IP Telnet protocol), or directly through a SET PORT TCP connection, it is sometimes necessary to SET PARITY SPACE for file transfer. It is sometimes impossible to use very long packets with terminal servers. Try SET RECEIVE PACKET-LENGTH 80, working up or down to the longest length that works. REMOTE TYPE and other REMOTE commands resulting in an error "Unable to open CON": insufficient FILES= in CONFIG.SYS. FILES= should be at least 20. MS-DOS Kermit uses the program named in the DOS Environment command line starting as SHELL= as a replacement for COMMAND.COM. Such a line is seen by typing SET at the DOS prompt, and it is not associated with the SHELL= line appearing in file CONFIG.SYS. The MS-DOS Kermit command REMOTE SET BLOCK-CHECK will generally have no effect upon a remote server unless the SET BLOCK-CHECK is also given locally to MS-DOS Kermit. The host prompt for TRANSMIT is a single character (SET TRANSMIT PROMPT). It is not possible to specify a multi-character or varying transmit-prompt. SCRIPT PROGRAMMING The terminal emulator is not active during execution of script commands such as INPUT and OUTPUT. This means: 1. If the host sends the escape sequence that tells the terminal to identify itself, it is ignored. You have to put the appropriate INPUT and OUTPUT commands in your script program. Here is a macro to set your terminal type in Kermit and to set up the appropriate response string as well as terminal type string: def term if not def \%1 def \%1 vt320,- set term type \%1,- if error end 1,- assign _ttype \%1,- if eq \%1 vt320 assi _tid \27[\{63}63\;1\;2\;4\;8\;9\;15c,- if eq \%1 vt220 assi _tid \27[\{63}\62\;1\;2\;4\;8\;9\;15c,- if eq \%1 vt102 assi _tid \27[\63\;6c,- if eq \%1 vt100 assi _tid \27[\63\;1c,- if eq \%1 vt52 assi _tid \27/Z Whenever you switch terminal emulations, do "term vt102" instead of "set term type vt102" (substitute your preferred terminal type). In any script that responds to ESC Z (or whatever), have it "output \m(_tid)", and any prompt that asks for your terminal type you can "output \m(_ttype)". And be sure to execute a "term" command in your MSKERMIT.INI file, so your initial terminal type is set. 2. A host-generated escape to put the terminal in Tektronix mode has no effect. Put explicit SET TERMINAL TYPE TEK commands in the appropriate places in your script program. 3. Screen formatting escape sequences have no effect. If you have SET INPUT ECHO ON, they are simply displayed as-is. If the remote host is sending ANSI (VTxxx) escape sequences during execution of the script program, then users of IBM PCs can use the ANSI.SYS or similar console driver to interpret the escape sequences. This is particularly useful when running a script that logs in to a full-screen system, such as an IBM mainframe through a protocol converter. But beware: ANSI.SYS is not totally compatible with Kermit's VT emulator, and it may produce unwanted side effects, the most annoying of which is suddenly popping your PC into 40-column mode! If you experience difficulties with your screen display while using Kermit script programs, use SET INPUT ECHO OFF. Or remove ANSI.SYS from your CONFIG.SYS file and reboot. PAUSE, WAIT, and similar commands also cause port input to be echoed to the screen if INPUT ECHO is ON. Use SET INPUT ECHO OFF to defeat this effect. If the REINPUT command fails to find the requested text in the INPUT command buffer, it will wait (up to the timeout interval) for more characters to arrive from the communication channel. INPUT / REINPUT combinations will not work if the INPUT buffer is smaller than the amount of text that separates the INPUT text from the REINPUT text. You can increase the size of the INPUT buffer by including the desired size in your KERMIT=INPUT environment variable. The default size is 256 bytes. Script programming hint: To test whether a readable floppy disk is available in drive A:, do this: SPACE A: IF FAILURE ECHO No diskette in drive A:. The ON_EXIT macro is intended only for automatic execution when MS-DOS Kermit exits. It only works once, to prevent recursion (as would happen, for example, if you put an EXIT command in your ON_EXIT definition). MEMORY MANAGEMENT [Not applicable to Victor; included for information] MS-DOS Kermit, like any DOS or Windows program, is likely to misbehave if your PC memory is insufficient or is incorrectly configured. MS-DOS Kermit runs in conventional memory (the first 640K [on the Victor, as much as 896k]) of your PC. It occupies about 280K initially, and then allocates additional memory as needed for rollback screens, file-transfer packet buffers, etc. Kermit uses additional memory to execute certain commands such as TYPE and DIRECTORY, for which it invokes a second copy of COMMAND.COM (appoximately 30K) in conventional memory, as well as RUN, which can invoke not only COMMAND.COM, but an additional program to be run by COMMAND.COM, for example "run edit". If there is insufficient memory, these operations will not work; thus it is always best to have as much free conventional memory as possible. Memory for file-transfer packets is allocated at the time the transfer begins, based on the current sliding-window size (SET WINDOW) and packet-length (SET RECEIVE PACKET-LENGTH), and is deallocated when the transfer ends. So SHOW MEMORY won't reveal the effect of the packet buffers. If insufficient memory is available for the requested window size and packet length, MS-DOS Kermit automatically reduces its RECEIVE PACKET-LENGTH. Conventional memory is always used for packet buffers. Thus packet buffers and RUN/PUSH/TYPE/ DIRECTORY commands "time-share" the same conventional memory. Memory for graphics screens is taken from your video display adapter. Storage of graphics images in the video adapter's on-board memory allows rapid switching between text and graphics screens provided (a) your video has sufficient memory, (b) the memory is not "mapped away", and (c) you are not running Kermit under Windows. Memory for rollback screens is allocated when the CONNECT command is first given, i.e. when Kermit first displays its terminal emulation window, and remains allocated until you EXIT from Kermit. This can be demonstrated by starting Kermit, giving the command SHOW MEMORY, then giving the CONNECT command, then escaping back (Alt-x), and then giving the SHOW MEMORY command again -- see how available memory has shrunk. Approximately 4K is required per 24x80 rollback screen (more for bigger screens). The default number of rollback screens is 10, but the number can be set to practically any value at all (0 or greater) by giving the following command to DOS before you start Kermit (interactively, or in your AUTOEXEC.BAT file): SET KERMIT=ROLLBACK 40 The smaller the number, the less memory required; the bigger, the more memory. In version 3.13, you can also give the new command: SET ROLLBACK at the MS-Kermit prompt at any time, and the rollback memory will be adjusted when you next CONNECT. A large number of rollback screens can crowd out other possibilities, like the ability to use Kermit's RUN, PUSH, TYPE, DIRECTORY, and other commands that run inferior processes. [Expanded memory features given below not tested on Victor, but they may work on Victors equipped with a Western Automation Laboratories Escort expanded memory board.] Version 3.13 of MS-DOS Kermit lets you store your rollback screens in Expanded Memory (EMS) if you have more than 1MB of physical memory and you have an expanded memory manager for it like Quarterdeck QEMM or EMM386 and HIMEM that come with DOS 5.0 and Windows 3.1. [These memory managers do not work on the Victor.] Using expanded memory for rollback screens frees 40K of conventional memory if you are using the default number (10) of rollback screens, and it also allows you to have a much larger number of rollback screens. The following steps are required to keep your rollback screens in expanded memory: 1. Make sure the desired amount of expanded (EMS) (not "extended", or XMS) memory is available. The DOS MEM command will tell you this. [Not on the Victor.] 2. In your AUTOEXEC.BAT file, set the desired number of Kermit rollback screens. For example, for 250 screens (requiring about 1 megabyte): SET KERMIT=ROLLBACK 250 3. Give the following command to MS-DOS Kermit: SET TERMINAL EXPANDED-MEMORY ON If this command fails, Kermit prints an appropriate error message. Now start a Kermit session, scroll some text off the screen during CONNECT mode, and check the operation of the PageUp/PageDown keys. If they work, you're done. And as an added benefit, graphics screens will also be stored in expanded memory, allowing you to switch between graphics and text screens (Alt-minus), even under Windows, without losing the graphics screen. If it doesn't work, then welcome to the bewildering world of DOS memory management. The most common symptom of a bad memory configuration is that your PC will freeze the first time Kermit tries to scroll a line off the screen or the first time it tries to clear the screen. Now you should begin looking at your CONFIG.SYS file. [Remainder of this section omitted; not applicable to the Victor.] If all else fails, tell Kermit to SET TERMINAL EXPANDED-MEMORY OFF (this is the default anyway). NOTE: whenever you switch Kermit's expanded memory status from OFF to ON or vice versa, your previous rollback screens are lost. HARDWARE-RELATED PROBLEMS Many of the newer low-cost, high-speed clone PCs suffer from noisy buses, interrupt or address conflicts, and other maladies not seen on earlier, more expensive (but slower) models. INTERACTIONS WITH DOS A REMOTE HOST or similar command sent to an MS-DOS Kermit server can invoke the DOS critical error handler, which issues its familiar "Abort, Ignore, Retry?" message on its real screen, and is waiting for a response from its own real keyboard, and so the server will no longer respond. Kermit attempts to catch many of these errors before DOS learns learns about them, but some cannot be avoided (like disk i/o errors). Similarly, a REMOTE DIRECTORY command sent to an MS-DOS Kermit server can cause the server to hang if its default directory command pauses after each screen (DIRCMD=/P). In fact, the server will hang any time a subprocess invoked by any REMOTE command (watch out, in particular, for REMOTE HOST) requests keyboard input. Interaction between MS-DOS Kermit and various terminate-and-stay-resident (TSR) programs is necessarily unpredictable. Console, mouse, clock, or graphics drivers might interfere with file transfer, e.g. the CMOSCLK.SYS driver on the PS/2 model 55SX. If TSR programs are interfering with Kermit (by taking over the timer or serial port interrupts), you should remove them all from your AUTOEXEC.BAT or CONFIG.SYS files, and then put them back one by one until you have identified the culprit. Use caution when invoking certain TSR programs while PUSHed from Kermit (e.g. using the PRINT command for the first time), as not all of these programs observe proper etiquette for allocating and freeing memory, and the TSRs will be loaded above Kermit into the middle of memory where they may prevent large programs from loading later. NETWORKS When communicating across certain network pathways, the longest burst of information tolerated from the PC can be rather short. For example, the LAT path with SET PORT DECNET (PATHWORKS) has a limit of 256 bytes and the SET PORT TES path has a limit of 512 bytes in a burst (or less, depending on the TES release). Longer bursts can cause the network software on one end or the other to drop the connection. This is most likely in the following situations: 1. During file transfer, when sending files from the PC using long packets and/or sliding windows. The total size of the packets in the window (packet length times the number of window slots) must be less than the burst limit for the network. 2. During VT320 terminal emulation, if the host application (such as VMS or UNIX WordPerfect) sends a Terminal State or Color Palette Request escape sequence, DECRQTSR, "ESC [ 2 ; 2 $ u". The response to this request is more than 200 characters long and has been known to break LAT and TES connections. This is not a Kermit problem, but rather a limitation (or bug) in the underlying networking method. Workarounds include: 1. If you have a DECnet LAT connection, make a DECnet CTERM connection instead (i.e. unload your LAT TSR and load the CTERM TSR instead). 2. Enable RTS/CTS flow control between MS-DOS Kermit and the device it is most immediately connected to, if possible. Otherwise, enable Xon/Xoff flow control in MS-DOS Kermit and at the host on the far end (e.g. tell VMS to SET TERM/HOSTSYNC/TTSYNC). 3. Use a different networking method, e.g. TCP/IP instead of DECnet. Sending BREAK over network connections via SET PORT BIOS1 + Int 14h interceptor may or may not work, depending upon the actual network and drivers in use. Kermit uses the BREAK facility if the driver and network support it. Symptom: PC no longer works after installing a network board. Diagnosis: a 16-bit VGA display adapter is running in 16-bit mode. Cure: Jumper it back to 8 bits and all should start working again. PC-NFS prevents applications programs such as Kermit from creating a file in the root directory of a PC-NFS disk drive. When the applications program asks if a particular file exists in the root, PC-NFS always responds with "volume label present", whether or not the actual file is present. SET PORT TELAPI performance is good with version 4 of Novell's LAN WorkPlace for DOS but it is poor with version 3.5 because that older version sends each Kermit byte in an individual packet. Because the TELAPI interface lacks the ability to resolve Internet, names you can use the small Kermit macro below to invoke Novell's program TSU to resolve names and set up a session: define telapi run tsu -o \%1 k1,run tsu -a k1 1,set port bios1 Use as Kermit command "telapi my.favorite.host" followed by CONNECT. This tells TSU to "o"pen a connection to the host named in Kermit variable \%1 and give the session a TSU tag of "k1". Then run TSU again and "a"ttach this session to COM"1" meaning Kermit's BIOS1 port. Four sessions can be started by choosing different tags and port numbers, though this macro does not make the changes. An alternative to SET PORT BIOS1 is SET PORT 3COM for much faster throughput; an end-of-session signal is not available with this method so the user must exit manually. You can't run LAN Workplace for DOS (LWP) and make SET PORT TCP/IP connections with Kermit at the same time, because only one protocol stack of a given kind can run over a single network board. If you want to make a TCP/IP connection with Kermit when LWP is loaded you can either (a) use SET PORT TELAPI rather than SET PORT TCP/IP (slower and less flexible), or (b) unload LWP from the DOS prompt by typing TCPIP UNLOAD, and then start Kermit. The Interconnections TES product, which Kermit fully supports, has a fancy menu that pops up if you type the TES "hot key", Alt-LeftShift-T. Reportedly, this pop-up menu interferes with the LK250 driver that is distributed with Kermit (it works fine with regular IBM keyboards). The LK250 driver uses a special interrupt, and the TES menu program might not properly chain this interrupt. The workaround is to use TES's text-mode menu, which Kermit brings up if you type Alt-Home during terminal emulation. Version 3.13 of MS-DOS Kermit transparently supports both older and the latest TES products. For DECnet/DOS (PATHWORKS) LAT connections, it is often necessary to tell the LAT control program on the PC to reserve enough memory for all of the local LAT host names. By default, space for 16 names is allocated. Increase your LAT control program's memory allocation if you have more than 16 hosts on your DECnet network. Also, remove ALL permanent LAT names from your database and let the network provide them (this can mean waiting a minute or two for all broadcasts to be heard). Reportedly, when making NETBIOS or 3COM(BAPI) connections under Windows, characters from a DOS window can show up in the Kermit window. Reportedly, this can be fixed by setting Kermit's foreground and background priority to 150 and setting the priority of the other DOS applications to 5000. NETBIOS STATION-TO-STATION CONNECTIONS The procedure for establishing a NETBIOS PC-to-PC connection is as follows: 1. On the first PC: SET NETBIOS NAME SET PORT NETBIOS SERVER 2. On the second PC: SET PORT NETBIOS .K ( is any name you choose, up to 14 characters long.) Now you can initiate file transfer and other Kermit protocol operations from the second PC. If you want the two PCs to "chat" in terminal mode, send a FINISH command from the second PC (or type Ctrl-C on the first, server, PC), and then give the following commands to both PCs: SET TERMINAL NEWLINE ON SET LOCAL-ECHO ON CONNECT TCP/IP SUPPORT As of version 3.11, MS-DOS Kermit contains built-in TCP/IP and TELNET protocol support. This allows a PC equipped with an Ethernet or other network board that is connected to a TCP/IP network to communicate with any other node on the network, without requiring any additional TCP/IP software on your PC. You need an external Ethernet-style (Class 1) packet driver for your network interface board, or (as of version 3.12) a SLIP Packet Driver or a Novell ODI driver, or (as of version 3.13) the Novell SLIP_PPP ODI driver. You can also use any of various "shims" to sit between Kermit and other kinds of board drivers (e.g. NDIS) to make them look to Kermit like Ethernet packet drivers. With ODI, Kermit's Telnet operates across Ethernet (many frame kinds), Token Ring, Arcnet, and PCnet. Kermit does not contain built-in network device drivers. Packet drivers are available from network interface manufacturers, and via anonymous FTP from Columbia University, host watsun.cc.columbia.edu [128.59.39.2], cd packet-drivers, get the READ.ME file, read it, and take it from there. These files, now called the Crynwr packet driver collection, are also available from Columbia University via mail order. ODI drivers are available from makers of the LAN adapter and in some cases from Novell. See Novell archive "novlib" on CompuServe and on machines ftp.is.sandy.novell.com [137.65.12.2] and mirrors such as netlab2.usu.edu [129.123.1.44] for Novell supplied ODI drivers. The TCP/IP code in this version of Kermit has been tested successfully with at least the following boards and packet drivers (according to reports from users): Ungermann-Bass PC/NIC board with Clarkson UBNICPC packet driver 9.1 3COM 3C501 with Clarkson 3C501 packet driver 5.0. 3COM 3C503 with Clarkson 3C503 packet driver 9.4.0. Western Digital WD8003E with Crynwr (not WD) WD8003E packet driver 9.7.0 Cabletron 2000 and 3000 series DNI boards with CSIPD_E 1.0x and later packet drivers on unshielded twisted pair, thin Ethernet, and thick Ethernet, on both PC/AT and Microchannel buses. Micom-Racal NI5210 with NI5210 packet driver. AT&T EN100 with Clarkson AT&T packet driver. IBMTOKEN.COM 3C501 emulation packet driver 1.9 over various Token Ring boards and drivers. DIS_PKT over NDIS for LAN Manager networks and NDIS-compliant boards including SD8003, 3C503, AT&T 10MB/sec thinwire Harvard ODIPKT over LSL, LANSUP, and IPXODI over Ethernet (but not Token Ring) Novell NE2000 with Crynwr NE2000 packet driver (not the Novell MLID!) Token Ring, Arcnet, and LocalTalk packet drivers are not supported, as they are not Ethernet- or SLIP-class Packet drivers. The performance of the 3C50x packet drivers is poor, but the operation seems correct. Suggestion from a 3COM 3C503 Ethernet board user: "When installing the packet driver for 3Com 503 cards, one has to pay attention that the memory option on the card is not disabled. It was in my case, and the packet-driver did not complain. Since other drivers (e.g. the DEC PATHWORKS driver) do not require the memory enabled, the default is disabled." Reportedly, the packet driver supplied by Western Digital with their WD8003E and/or Elite network boards cannot be found by Kermit. The Crynwr WD8003E packet driver, however, works correctly with both the WD8003E and Elite boards. Same comments apply to WD8003E.SYS shipped with PC-NFS. To reconfigure a Novell network (NetWare 3.xx or earlier) for packet drivers so Kermit and Novell software can be used concurrently, use software from Brigham Young University, available via anonymous ftp from dcsprod.byu.edu. For further information, read the Kermit Distribution file MSABYU.HLP. An Ethernet-simulation packet driver "shim" is available for systems using the NDIS (Network Driver Interface Specification) program. NDIS is frequently used with LAN Manager networks, including AT&T's StarGROUP network and DEC's Pathworks for DOS. The interface program is named DIS_PKT and originated with FTP Software Inc. Their program DIS_PKT.GUP is available by anonymous ftp to vax.ftp.com, and a research version DIS_PKT9.ZIP is available from Utah State University by anonymous ftp to netlab2.usu.edu. Instructions for configuring Lan Manager to include DIS_PKT are included with the program. (Also available from watsun.cc.columbia.edu, in the packet-drivers.new directory and on the MS-DOS Kermit diskette.) Here is a setup with which one user reports success in using MS-DOS Kermit's built-in TCP/IP support with LAN Manager and a Novell NE2000 Ethernet board: CONFIG.SYS --------------------------- SHELL=C:\COMMAND.COM /P /E:1024 DEVICE=C:\WINDOWS\HIMEM.SYS DEVICE=C:\WINDOWS\EMM386.EXE noems I=B000-B7FF i=e000-efff DOS=HIGH,UMB COUNTRY=61,,C:\DOS\COUNTRY.SYS BUFFERS=13 FILES=50 STACKS=0,0 LASTDRIVE=Z DEVICEHIGH=C:\DOS\ANSI.SYS DEVICEHIGH=C:\WINDOWS\MOUSE.SYS DEVICEHIGH=C:\LANMAN\DRIVERS\PROTMAN\PROTMAN.DOS /i:C:\LANMAN DEVICEHIGH=C:\LANMAN\DRIVERS\ETHERNET\NE2000\NE2000.DOS DEVICEHIGH=C:\KERMIT\DIS_PKT9.DOS PROTOCOL.INI ---------------------------- [PROTMAN] DRIVERNAME = PROTMAN$ DYNAMIC = YES PRIORITY = NETBEUI [PKTDRV] ; This section added for kermit DRIVERNAME = PKTDRV$ BINDINGS = NE2000_NIF INTVEC = 0x65 [NETBEUI_XIF] DRIVERNAME = NETBEUI$ SESSIONS = 8 NCBS = 12 BINDINGS = "NE2000_NIF" LANABASE = 0 [NE2000_NIF] ; protocol.ini section for the Novell NE2000 Card IOBASE = 0x300 INTERRUPT = 5 DRIVERNAME = MS2000$ Kermit's TCP/IP support does not work over the Harvard ODIPKT driver on a Token Ring network because it requires Kermit to use Token Ring rather than Ethernet frames (but it does work with ODIPKT over Ethernet). Version 3.12 and later support ODI directly; ODIPKT is not necessary except when using Windows. Direct use of ODI drivers permits Kermit's TCP/IP to run with several kinds of Ethernet frames: DIX/Blue-Book/Ethernet_II, 802.2, 802.2 with SNAP, and 802.3, as well as with Token Ring, Arcnet, and PCLan broadband. No extra protocol "shim" is needed, but you must have the ODI drivers which come from Novell or from your network board vendor. The ODI interface will be tried if a Packet Driver is not found, and it can be selected in preference to a packet driver by the command: SET TCP/IP PACKET-DRIVER-INTERRUPT ODI where "ODI" replaces the interrupt number of a Packet Driver. For ODI, the file NET.CFG should have the lines "Protocol IP etc" similar to the example below: # File NET.CFG, example PB buffers=10 show dots=on Link Support buffers 6 1514 MemPool 2048 Link Driver SMCPLUS Port 280 20 Mem 000CA000 2000/10 Int 7 frame Ethernet_II Protocol IPX 8137 Ethernet_II Protocol IP 0800 Ethernet_II Protocol ARP 0806 Ethernet_II Protocol RARP 8035 Ethernet_II To make TCP/IP connections, Kermit requires three "protocols", IP, ARP, and optionally RARP as shown above. The frame kinds can be anything the board will support: Ethernet, Token Ring, Arcnet, all IEEE 802.2-based frames etc. ODI will complain if the frame type cannot support these protocols. Arcnet uses different TYPE values, D4 for IP, D5 for ARP, and D6 for RARP, rather than 0800 etc, as per RFC-1201. Which board Kermit (or IPX or other application) will use if two or more boards are available? Although one would think the board could be selected by placing the Protocol IP, etc, lines under the desired Link Driver section, such is not really the case; those lines tell LSL the frame kind to associate with the protocol (say IP) but not the board. The frame lines are associated with particular boards, however. The default method for finding a board is that the application chooses "the first board" offering a suitable frame, regardless of whether or not the Protocol IP, etc, lines are present for that board. "First" refers not to the contents of NET.CFG but to the order in which board drivers are loaded at DOS level. So the indented protocol lines tell ODI which frame a protocol needs, and a TYPE to use for recognizing packets, but the lines do not identify a particular board. To target a particular board a separate main section is used in NET.CFG. The section starts with the word Protocol against the left margin and has Bind indented beneath it, like this - Protocol Kermit Identifies Kermit section of NET.CFG bind SMCPLUS Bind to SMCPLUS board driver When a board name is used more than once then the alternative form is to use a board number in place of the name: Protocol Kermit bind #2 bind to the board loaded second Kermit considers the text in these sections to be case-insensitive. The # construction must not have a separation between the number sign (#) and the digit. The # case is normally used when two or more boards share the same driver and thus are not distinguishable by name alone. A sample STARTNET.BAT file might look like this: @echo off run quietly c:\lsl >nul LSL is always loaded before boards c:\smcplus.com >nul SMC/WD8003E board, the first c:\exos.com >nul EXOS-205T board, the second rem c:\odinsup Odinsup can coexist with Kermit rem c:\odipkt 0 96 Odipkt can coexist with Kermit c:\ipxodi >nul IPX is always loaded after boards rem echo Starting network... may be needed to help some drivers c:\bnetx ps=my-preferred-server > nul rem (Packet Burst mode) NETX loads after IPX @echo on If both EXOS and SMCPLUS boards offer frame Ethernet_II Kermit will choose the first loaded board, SMCPLUS, in the absence of a "bind" command. Putting the section "Protocol Kermit, bind " anywhere in NET.CFG selects a particular board for Kermit. A complete NET.CFG file using two boards is shown below and applies to both regular NetWare shells and the newer VLM shells (but with minor changes to the no-board parts of things). # File NET.CFG, an example with two boards PB buffers=10 show dots=on # all main sections must start in column 1, indent local material. # Protocol "IPX" is for Novell's IPXODI Protocol IPX Bind #1 # Protocol "Kermit" is for MS-DOS Kermit Protocol KERMIT Bind EXOS Link Support buffers 6 1514 MemPool 2048 Link Driver exos Port 310 20 Mem 000D0000 400 Int 5 frame Ethernet_II Protocol IPX 8137 Ethernet_II Protocol IP 0800 Ethernet_II Protocol ARP 0806 Ethernet_II Protocol RARP 8035 Ethernet_II Link Driver SMCPLUS Port 280 20 Mem 000CA000 2000/10 Int 7 frame Ethernet_II frame Ethernet_Snap Protocol IPX 8137 Ethernet_II Protocol IP 0800 Ethernet_II Protocol ARP 0806 Ethernet_II Protocol RARP 8035 Ethernet_II # Protocol "TCPIP" is for Novell's Lan WorkPlace for DOS, not Kermit Protocol TCPIP ip_address 129.123.1.99 ip_router 129.123.1.254 ip_netmask 255.255.255.0 tcp_sockets 8 udp_sockets 8 raw_sockets 1 nb_sessions 4 nb_commands 8 nb_adapter 0 nb_domain usu.edu Link Driver SLIP_PPP DIRECT YES BAUD 9600 OPEN ACTIVE PCOMP YES ACCOMP YES PORT 3F8 INT 4 FRAME SLIP Protocol IP 0800 SLIP MAKING NOVELL SLIP_PPP ODI CONNECTIONS Novell's SLIP_PPP ODI driver is a combined serial port SLIP and PPP module which is part of the Lan WorkPlace for DOS (LWP) product. Kermit requires the line: Protocol IP 0800 SLIP to be included with the driver. Note that Kermit can temporarily steal the serial port hardware from this driver to dial the telephone and log into a host; SLIP/PPP communications should resume normally after Kermit is set to the TCP/IP pathway. Here is a STARTODI.BAT and NET.CFG example with SLIP_PPP carrying the TCP/IP traffic. File STARTODI.BAT: @echo off REM - Load LSL first c:\lsl.com REM - Then load your network board driver c:\ne2000.com REM - Then load the Novell SLIP_PPP driver c:\slip_ppp.com REM - Then the regular Novell IPX driver and network shell, for example: set name=olga c:\ipxodi /d c:\bnetx.exe ps=name-of-novell-server @echo on File NET.CFG: # File NET.CFG PB buffers=6 show dots=on signature level=0 protocol KERMIT bind SLIP_PPP # bind ne2000 Link Support Buffers 7 1500 MemPool 2048 Link Driver NE2000 Port 360 Int 5 Frame Ethernet_II Protocol IPX 8137 Ethernet_II Protocol IP 0800 Ethernet_II Protocol ARP 0806 Ethernet_II Protocol RARP 8035 Ethernet_II Link Driver SLIP_PPP DIRECT YES BAUD 9600 OPEN ACTIVE # TCPIPCOMP VJ PCOMP YES ACCOMP YES PORT 3F8 INT 4 FRAME SLIP # FRAME PPP Protocol IP 0800 SLIP # Below is for Novell's Lan WorkPlace for DOS Protocol TCPIP PATH SCRIPT d:\lwp41\net\SCRIPT PATH PROFILE d:\lwp41\net\PROFILE PATH LWP_CFG d:\lwp41\net\HSTACC PATH TCP_CFG d:\lwp41\net\TCP ip_router 129.123.100.254 ip_netmask 255.255.255.0 ip_address 129.123.100.5 tcp_sockets 16 udp_sockets 8 raw_sockets 1 # nb_sessions 4 # nb_commands 8 # nb_adapter 0 # nb_domain usu.edu Bind slip_ppp Kermit is told to bind to SLIP_PPP rather than to the active NE2000 board because the indented minor clause Bind SLIP_PPP under the Protocol Kermit major heading tells Kermit which MLID (board driver) to use. Link Driver SLIP_PPP has indented Kermit line "Protocol IP 0800 SLIP" so Kermit can use the driver; ARP and RARP lines could have been added with no effect (no ARP on a point-to-point link). LWP/DOS does not need this protocol line because it tends to generate them itself. Either SLIP or PPP can be used by setting the Frame Type and using the same frame type in the indented protocol line below it. No NetBios support was wanted from LWP/DOS so that section was commented out. STARTODI.BAT loads SLIP_PPP but nothing is sent out immediately as there is not yet any connection. To make the connection, start Kermit, SET PORT COM1 (or whatever), set the desired speed and flow control (but not Xon/Xoff!), dial the phone and log into the host or server, then start SLIP or PPP there (Novell provides a DIALER program with SLIP_PPP which can set the port speed and dial a phone number via rudimentary means; Kermit is much more flexible about this). In all this, Kermit is grabbing the serial port from SLIP_PPP, using it, and then returning it when done. Kermit's TELNET will find an ODI driver, SLIP_PPP, adjust itself accordingly, and SLIP-style packets flow back and forth. (If Kermit doesn't find the ODI driver, tell it to SET TCP PACKET-DRIVER ODI.) ODI-TO-PACKET-DRIVER SHIMS Prior to version 3.12, the only way to make TCP/IP connections over ODI with MS-DOS Kermit was through the ODIPKT shim, which converts between the ODI interface and the packet-driver interface. ODIPKT is no longer necessary, except under Windows (because there is, as yet, no equivalent of WINPKT for ODI drivers). There is an ODI to Packet Driver shim available for Token Ring cards which can work with Kermit (and WINPKT). The current version is still in Beta as of this writing (May 93). ODITRPKT is available via FTP from Oklahoma State University host datacomm.ucc.okstate.edu as pub/oditrpkt/beta9.zip. A copy is also available in packet-drivers/new on watsun.cc.columbia.edu, but it might not be as up-to-date as the one at the source. Here is a NET.CFG example using ODITRPKT: LINK DRIVER TOKEN INT 3 FRAME TOKEN-RING FRAME TOKEN-RING_SNAP PROTOCOL IPX E0 TOKEN-RING Protocol IP 0800 TOKEN-RING_SNAP Protocol ARP 0806 TOKEN-RING_SNAP Protocol RARP 8035 TOKEN-RING_SNAP And here is one using Arcnet: LINK DRIVER SMCARCWS INT 3 PORT 300 MEM D0000 Frame NOVELL_RX-NET Protocol IPX FA NOVELL_RX-NET Protocol IP D4 NOVELL_RX-NET Protocol ARP D5 NOVELL_RX-NET Protocol RARP D6 NOVELL_RX-NET At the moment there is no Windows support for Kermit over ODI. Instead we recommend using shim ODIPKT or ODITRPKT over ODI, followed by WINPKT over that to employ a Packet Driver interface into Windows. TCP/IP BUGS AND LIMITATIONS Domain name resolution might not work when you give a nickname instead of a complete host name in the SET PORT TCP/IP command and Kermit transforms the nickname into the desired complete host name by combining it with your TCP/IP DOMAIN. Kermit does not use a special Hosts file to relate nicknames to complete host names. Workarounds: use a complete hostname, an IP host number, or set your TCP/IP DOMAIN correctly. It should be obvious that Domain Name Servers are specified by their IP number rather than name. Version 3.13 supports multiple gateways on the local network. Choosing the incorrect gateway normally results in that gateway sending an ICMP Redirect message to Kermit indicating the preferred gateway, and Kermit displays such messages. Version 3.12 and earlier did not implement ICMP Redirect actions. For IBM mainframe linemode TELNET connections, automatic appearance of the login banner might not work. Type a carriage return (Enter) to get the login banner. Local-echo and linemode operation are negotiated automatically. BOOTP requests are handled correctly within the local network, and have been tested successfully through Novell's BOOTP forwarder NLM and through Cisco routers with software version 8.2.7. In the SET TCP/IP ADDRESS command, the words BOOTP and RARP must be spelled out in full. Version 3.11 and 3.12 support original RFC951 and 1048 BOOTP protocol, and version 3.13 adds support for downloading of the PC's full host (domain) name as specified in RFC1395. See V9KERMIT.HLP for details. EXIT from Kermit closes your TCP/IP session (just like HANGUP). PUSHing or running DOS commands from Kermit keeps it open. In version 3.12 and later, EXITing while a session is active causes a warning / confirmation message to appear so you can change your mind. Version 3.11 of MS-DOS Kermit uses only the TELNET port (23) for SET PORT TCP connections. Version 3.12 and later allow you to specify any desired port (except 25) in the SET PORT TCP command, after the host name or address. MS-DOS Kermit honors TELNET protocol negotiations, including terminal type and ECHO/SGA. Version 3.11 always sends "VT100" as its terminal type; later versions send MS-DOS Kermit's active terminal type or allows the user to create an override string with command SET TCP/IP TELNET-TERM-TYPE. Not supported: FTP, TFTP, automatic setting of PC date/time from network, 3270 emulation (tn3270), etc. There is no PING command, but MS-DOS Kermit responds when PINGed and when probed by Traceoute. The keyboard verb \Knethold does nothing. Multiple simultaneous TCP/IP sessions are supported in version 3.13; see V9KERMIT.HLP for details. For TCP/IP connections to IBM mainframes in full screen 3270 mode, you need an intermediate host or device to do the 3270/ASCII terminal conversion. Typical setup is a TCP/IP terminal server with its serial lines connected to a protocol converter (e.g. IBM 7171), a UNIX host that has tn3270 available, or a terminal server (like Cisco) that does 3270 terminal emulation. To transfer files with an IBM mainframe, you might have to tell MS-DOS Kermit to SET PARITY SPACE. Version 3.12 and later support inbound connections to MS-DOS Kermit. Inbound TELNET connections do not copy DOS screens, etc, like Carbon Copy and PC Anywhere and the free telnetd program of Erick Engelke; a Kermit-to-Kermit connection is made instead. To configure MS-DOS Kermit to be a TCP/IP server, give the following command: SET PORT TCP * [ ] SET SERVER LOGIN [ ] ; (recommended but not required) SERVER Use asterisk instead of an IP name or address, followed optionally by a TCP port number (the default is 23 = TELNET), and then enter server mode. Anybody who TELNETs to your PC will see a brief screen message telling them to escape back to their local Kermit prompt and issue commands from there, for example: REMOTE LOGIN REMOTE DIRECTORY GET OOFA.TXT Kermit's TCP/IP support cannot be used simultaneously with PC NFS because both applications want to register use of ARP and IP with the packet driver, but each protocol can only be assigned to one application. This is only one particular case of the more general rule: Only one TCP/IP based application can use a LAN adapter at once. which also applies to DesqView/X and other TCP/IP products for the PC. (There is a program called PKTMUX that, under some conditions, might allow coexistence of multiple TCP/IP applications, but it is risky and not recommended.) To make MS-DOS Kermit work simultaneously with PC-NFS, Kermit would have to be linked with the proprietary socket-library routines, which we cannot do. If you need to have NFS active simultaneously with an MS-DOS Kermit TCP/IP connection, it is best to use a different NFS package that also works with Kermit such as FTP Software, Novell LWP, or Beame and Whiteside. The SET TCP/IP and SET PORT TCP/IP commands only return failure codes if there is a parse error. The connection is not opened until the first attempt to communicate with the remote host: CONNECT, PAUSE, OUTPUT, etc. While connection establishment is in progress, you can't interrupt the program with Ctrl-C. Use IF SUCCESS / FAILURE after PAUSE 0 to check if the connection is open, for example: DEFINE TELNET SET PORT TCP \%1 \%2, PAUSE 0, IF SUCCESS CONNECT The second variable above is for the optional TCP port number in version 3.12 and later. TCP/IP performance hints: Set your Kermit packet size to 500 or larger to achieve most data sent per network packet. A convenient setting is SET RECEIVE PACKET 1000, SET WINDOW 4, resulting in four 1000-byte packets in a window. SET FLOW NONE lets TCP/IP do the flow control and eliminates Kermit's need to check for Xon/Xoff. In most situations beyond the local network performance will be limited by the long distance lines rather than by the PC. End of V9KERMIT.BWR (modified from MSKERMIT.BWR, also known as MSKERM.BWR or KERMIT.BWR)