Columbia Kermit

home *** CD-ROM | disk | FTP | other *** search

/ Columbia Kermit / kermit.zip / archives / ckc190.zip / ckoker.bwr < prev next >

Wrap

Text File | 1994-09-03 | 50KB | 1,023 lines

CKOKER.BWR "Beware File" for C-Kermit Version 5A -*- text -*- OS/2 VERSION Applies to version 5A(190) BETA.16 Last update: Fri Sep 2 14:18:18 1994 Authors: Frank da Cruz and Christine M. Gianone, Columbia University, New York. Kai Uwe Rommel, ARS Computing & Consulting GmbH, Muenchen, Germany. Jeffrey Altman, Altmania Productions, Great Neck, New York. Copyright (C) 1985, 1994, Trustees of Columbia University in the City of New York. The C-Kermit software may not be, in whole or in part, licensed or sold for profit as a software product itself, nor may it be included in or distributed with commercial products or otherwise distributed by commercial concerns to their clients or customers without written permission of the Office of Kermit Development and Distribution, Columbia University. This copyright notice must not be removed, altered, or obscured. Report problems, suggestions, fixes, etc, to Frank da Cruz: Internet: fdc@columbia.edu BITNET/EARN/CREN: FDCCU@CUVMA Columbia University Academic Information Systems 612 West 115th Street, New York, NY 10025 USA DOCUMENTATION C-Kermit 5A is documented in the book "Using C-Kermit" by Frank da Cruz and Christine M. Gianone, 1993, Digital Press / Butterworth-Heinemann, Woburn, MA, USA, ISBN 1-55558-108-0. Price: US $34.95. Available in book and computer stores, or order by phone, call Columbia University at +1 212 854-3703, or Butterworth-Heinemann at +1 800 366-2665. A German edition is available from Verlag Heinz Heise in Hannover, Germany. UPDATE: C-KERMIT EDITS AFTER 188 As of version 5A(189), OS/2 C-Kermit supports TCP/IP connections if you have IBM TCP/IP 1.2.1 or 2.0 (or compatible products such as the one from Essex Systems) installed on your OS/2 system. This requires a change in the installation instructions. A new automatic installation procedure is now included, a Rexx program called INSTALL.CMD. Just put the installation diskette into drive A:, click on the Drive A: icon, then click on INSTALL.CMD. Or from the OS/2 CMD prompt, type "a:install" (of course, you can also use Drive B). To bypass the INSTALL procedure and install OS/2 C-Kermit manually, please read the installation instructions in the OS/2 Appendix of "Using C-Kermit" together with any updates in the READ.ME (CKOAAA.DSK) file. Edit 190 adds ANSI and VT220 terminal emulation, Named Pipe and NETBIOS communications, a REXX programming interface, an "autodownload" (APC) feature, file transfer failure recovery, mouse support, and a completely new method of key mapping using "\Kverbs" (like MS-DOS Kermit). For details about the new features of OS/2 C-Kermit since edit 188, please read the file CKCKER.UPD, especially the OS/2 section. THE 16-BIT AND 32-BIT VERSIONS OS/2 C-Kermit comes in both a 16-bit version, which works under both OS/2 1.x and 2.0 (and later), and in a 32-bit version, which works only under OS/2 2.0 and later. The program herald and the SHOW FEATURES command tell you which version you have. The 16-bit version might run out of stack space and crash under certain conditions (the OS/2 message will be "Stack Overflow"). This is a limitation of the underlying 16-bit architecture. Also the 16-bit version lacks various features of the 32-bit version due to architectural or compiler limitations: various printer operations, the Rexx interface, SET FILE TYPE LABELED (OS/2 Extended Attribute) support, mouse support, Named Pipe support, NETBIOS, etc. The 32-bit version does not (should not) crash, but it can't be used under OS/2 1.x. It is recommended that all users choose to install the 32-bit version unless they are running a 1.x version of OS/2 (or are running on Windows NT.) NETWORK SUPPORT OS/2 C-Kermit includes support for TCP/IP, DECNET LAT, NETBIOS, and Named Pipes. Named-Pipe support should work for everybody, since this is a standard feature of OS/2. The others require the corresponding networking product to be installed; Kermit will search for these products automatically upon startup. NETBIOS and Named Pipe support are available only in the 32-bit version of C-Kermit. The SET HOST command uses your current SET NETWORK type. For example: SET NETWORK DECNET SET HOST OOFA will try to make a DECnet (PATHWORKS) LAT connection to DECnet node OOFA. However, please be aware that a SET NETWORK command will fail if the given type of network is not installed, or if (in the case of NETBIOS) the given name is already in use. Thus a safer construction would be: SET NETWORK NETBIOS OOFA IF FAIL STOP 1 Can't access NETBIOS network SET HOST MUPEEN IF FAIL STOP 1 Can't make NETBIOS connection The default network type (which is used if give a SET HOST command without first giving a SET NETWORK command) depends on which network products you have installed on your OS/2 system, chosen in this order of preference: TCP/IP, DECnet, Named Pipes NetBIOS cannot be a default choice because it requires a user-assigned name. TCP/IP: C-Kermit's TCP/IP support works with: . IBM TCP/IP (both the 1.2.1 16-bit DLL and the 2.0 32-bit DLL) . Essex Systems TCP/2 (both the 16-bit and 32-bit DLLs) . FTP Software's PC/TCP for OS/2 It is not known whether it works with Novell LAN Workplace for OS/2, Wollongong, or others. If a TCP/IP package includes an IBM-compatible TCPIPDLL.DLL library, then C-Kermit should work with it. Support for other OS/2 TCP/IP packages is planned and will be implemented as time permits and development toolkits are available to us. (End TCP/IP Section) DECNET: DECnet LAT support works in conjunction with DEC's PATHWORKS for OS/2 product, which must be installed. To use it: SET NETWORK DECNET SET HOST <hostname> C-Kermit then tries to load LATCALLS.DLL, which must be in your LIBPATH. (End DECNet Section) NETBIOS: NetBios is the preferred protcol to use when transfering files with MS-DOS Kermit or C-Kermit for OS/2 in a peer-to-peer local area network. NetBios is supported over most networking protocols including: Netbeui, IPX, IP, and LU6.2. In addition, it has lower overhead than all other OS/2 implemented networking protocols. Both Kermit Server and Chat modes are supported. "Chat mode" means that both Kermit programs are in CONNECT mode, so two users can "chat" with each other by typing. For chat mode, use: set terminal echo local set terminal cr-display crlf connect C-Kermit supports both the original NETBIOS 3.0 (NETAPI) interface and the newer NETBIOS 4.0 (ACSBNET) interface. C-Kermit has been tested with the following products: New NETBIOS 4.0 interface (ACSNETB.DLL): IBM LAN Adapter and Protocol Support (LAPS) as found in: IBM Network Transport Services/2 IBM LAN Distance IBM Communication Manager/2 IBM LAN Server 3.x IBM LAN Requester 3.x Old NETBIOS 3.0 interface (NETAPI.DLL): Microsoft LAN Manager Requester IBM Extended Services 1.x IBM LAN Server 2.x Requester Novell Netware 2.x Requester Commands: SET NETWORK NETBIOS <local netbios name> SET HOST { *, <remote netbios name> } Each C-Kermit session requires the following resources from the NetBios provider: 1 Name, 32 Commands, and 1 session. For example, if you wish to have three C-Kermit sessions running simultaneously in Server mode, NetBios must be configured to support at least 3 Names, 96 Commands, and 3 sessions. If the number of available NetBios commands is inadequate for C-Kermit's needs, a C-Kermit in Send or Server modes will quickly timeout. In this situation, reduce the number of window slots used with C-Kermit's SET WINDOW command. In general, there is little benefit on a local area network of using more than 2 window slots. The default settings for some NetBios providers are: Config File Names Commands Sessions Novell NET.CFG 24 32 16 LAPS PROTOCOL.INI 21 95 5 The method for modifying NetBios resources depends on the NetBios product; it is normally done by executing the configuration program (LAPS, INSTALL, ...) or by manually modifying the configuration files and restarting the network (or the OS/2 system). It is possible to have two or more products each providing NetBios services. However, there are limitations. All products which use LAPS may be mixed together. And LAPS may be mixed with up to one product which uses the NETAPI.DLL product. In particular, you can not successfully run Novell NetBios support with IBM Extended Services. The most common combination is LAPS and Novell NetBios. In this situation, you need to specify the NetBios configuration settings in both Net.Cfg and Protocol.Ini. And the settings for Names, Commands, and Sessions *must* match. You must also add the following section to the PROTOCOL.INI file: [NETBIOS] DriverName=NetBios$ ADAPTER0=ipxnb$,<physical adapter>,<sessions>,<commands>,<names> ADAPTER1=netbeui$,<physical adapter>,<sessions>,<commands>,<names> where: <physical adapter> is almost always 0 since there is usually only one adapter in the machine. <sessions>, <commands>, and <names> must match the settings in NET.CFG and PROTOCOL.INI. Without this additional section in PROTOCOL.INI, you can use only IBM's NETBIOS implementation. With this section, Novell's NetBIOS implementation is used by default since it must be ADAPTER0; to use IBM's NETBIOS on a system that has both Novell and IBM, start C-Kermit with the command-line option: -N <adapter number> for example "ckermit -N 1" (note, uppercase N). (End NetBios Section) NAMED PIPES: C-Kermit supports OS/2 Named Pipes across networks when a LAN requester has been installed. C-Kermit has been tested with the following products: IBM LAN Server Requester to LAN Server Network Server Microsoft LAN Manager Requester to LAN Manager Network Server Novell Netware Requester to Novell Netware Requester Commands: SET NETWORK NAMED-PIPE <pipe name> SET HOST { *, <named pipe server name> } Both Kermit Server and Chat modes are supported. Note: when using Named Pipes with LAN Server or LAN Manager, only the machine which has the Network Server software is capable of successfully using the SET HOST * command. This is because the client network requesters do not implement the server side of the named-pipe network redirection. Novell Netware Requester for OS/2, on the other hand, implements both the named-pipes client and server code on the client workstation and does not require the existence of a Network server to operate. (End Named Pipes Section) GENERAL LIMITATIONS AND PROBLEMS When switching away from C-Kermit's terminal screen and then switching back to it, certain video items might become confused: . The cursor might be lost or misplaced . The entire screen might be blinking (more about this below) . The screen border might have disappeared . Colors might have changed These problems appear to be confined only to certain systems, and do not occur on others. It is believed that they are related to the particular video adapter or driver; the problems are most commonly reported on SVGA and XGA systems. You can usually work around these problems in various ways: . Use Alt-R to reset the terminal emulator . Escape back to the prompt and CONNECT again . Escape back to the prompt, PUSH, EXIT, and CONNECT again . Escape back to the prompt, run MODE CO80 (or whatever), and CONNECT again C-Kermit has been reported to "freeze" on some systems. This problem is not confined to C-Kermit, and has also been observed with a variety of other communications software packages: . The most likely cause for freezing would be an interrupt conflict. Make sure your serial ports, CD ROM drive / controller and/or SCSI adapter, Soundblaster, ISA card, network adapter, etc, are all using different and unique IRQs. . One user reported that the problem disappeared when he moved his serial communication board farther away from his SCSI adapter board. This might have reduced electromagnetic interference, or altered the priority of the adapters. Sometimes, simply reseating the card can help. . Another user (different system) made the problem go away by rebooting the PC, which had been up for many weeks. . The problem might be caused by a poorly built or configured system: noisy bus, spurious interrupts, buggy internal modems, or buggy serial port driver software. For example, one user who noted that Kermit froze whenever he told it to SET PORT COM2 also discovered that the same thing would happen if he issued a MODE COM2 command at the CMD prompt, even when this is done immediately after starting the system. . Finally, mysterious problems like this are often cleared up by installing patches (CSDs) or new releases of the software involved (e.g. TCP/IP or other DLLs, serial drivers, OS/2 itself, etc). SET TERMINAL CODE PAGE only seems to work in fullscreen sessions. For that matter, the same seems to be true of OS/2's own CHCP program, so this is apparently an OS/2 limitation (noted in OS/2 2.1 GA). SET TERMINAL CODE PAGE (and OS/2's own CHCP program) seem to have no effect at all when the Hebrew NLV is installed. The code page simply does not change. Q: Is it possible to quit Kermit and NOT have the phone line hung up? That is, quit out of Kermit leaving the modem connection open, so I can then start SLIP? A: No. When an OS/2 process exits, all of its file handles are closed. One of the penalties we pay for using a real operating system, as opposed to (say) DOS. It might be possible to run the SLIP process "under" Kermit. It is also possible for Kermit to inherit the file descriptor of a serial device from a superior process, in which case it is not closed when Kermit exits. Q: Does C-Kermit support multiple sessions? A: No. If you SET PORT 1 and make a connection, and escape back and SET PORT 2, the connection on port 1 is closed, dropped, and hung up. The same happens for network sessions. To achieve multiple C-Kermit sessions, run separate copies in different OS/2 windows. As of edit 190, C-Kermit will put a unique identifier in the window list for each session, such as "C-Kermit COM1", "C-Kermit COM2", "C-Kermit KERMIT.COLUMBIA.EDU", etc. If you have TCP/IP installed on your OS/2 system, you can set up a SLIP connection, and then you can run multiple copies of C-Kermit over it, using C-Kermit's TELNET command to make the connections. This lets you achieve multiple sessions over a single serial port, a single modem, and a single phone call. C-Kermit's performance on serial connections -- and the performance of any other OS/2 communication software program -- can be improved significantly by using a 16550A(FN) communications port controller (UART) rather than an 8250, 16450, 16550 (no A), or other unbuffered UART. Unbuffered UARTs interrupt the CPU once per character, whereas a buffered UART interrupts every 8-14 (or more) characters. Measurements during C-Kermit file transfer on an otherwise unloaded i486/50 EISA system under OS/2 2.0 show approximately 10%-25% CPU usage with a buffered UART and 75%-100% using an unbuffered one. And of course, as with all other OS/2 applications (and OS/2 itself), a faster CPU and more memory also help. In any case, native OS/2 serial communications software is NOT as fast as DOS communications software (particularly MS-DOS Kermit) under DOS on the same machine because OS/2 communications must go the serial device driver, which adds the overhead of context switching; preservation of registers, stack adjustment, call gate, etc, whereas DOS applications can access the bare hardware directly. On the other hand, differences in speed of file transfers between native DOS and OS/2 programs should be marginal or even non-existent for current widely-used high-speed modems and CPU speeds. In addition, the fact that all communication must be done through a device driver ensures device independence (as long as the driver's programming interface is compatible to the standard COM.SYS) and efficient use of the system resources, because all known OS/2 communications device drivers are interrupt-driven, while many DOS communications software packages (other than MS-DOS Kermit) might not be. The OS/2 device driver also allows multiple file transfers on one machine at the same time (if multiple modems are connected to it, for example), and allows other (even very CPU-intensive) tasks to run concurrently without affecting the file transfer speed(s), as long as enough CPU power is available. If you refer to a disk drive that is not ready, or to a file on such a disk drive, the OS/2 critical error handler might pop up and require action from the keyboard. This occurs during execution of commands by inferior processes, such as DIRECTORY, REMOTE DIRECTORY, DELETE, REMOTE DELETE, etc. It should not occur in file transfer operations. The "hard error box" will put a halt to unattended, scripted operations, and it stops the operation of the OS/2 C-Kermit server if there is no human in attendance. To work around: add the line "AUTOFAIL=YES" to CONFIG.SYS and reboot. This eliminates the hard error box, but it applies system-wide, not just to C-Kermit. (The equivalent of AUTOFAIL=YES can be set on a per-process basis and C-Kermit does so for itself but it can't do this for any inferior processes started by it.) If the PUSH command, and related commands, do not work for you, check the definition of your OS/2 COMSPEC environment variable, i.e. make sure it contains the fully-specified pathname of a valid OS/2 executable shell program (such as C:\OS2\CMD.EXE), and/or the named program is in your OS/2 PATH. C-Kermit works with JP Software's 4OS2.EXE and any other replacement Command Shell. The directory containing the shell must be located in the PATH in order for the replacement shell to be called correctly. TYPING AND CUTTING AND PASTING When you are typing normal characters in CONNECT mode, C-Kermit should normally have no trouble transmitting them. An exception occurs on dialed serial connections with RTS/CTS flow control when the modem might drop its CTS (Clear To Send) signal because of noise on the connection that causes the two modems to enter a "retraining" sequence. If you type a character under these conditions, C-Kermit will write "TRANSMISSION BLOCKED 15" in the status line, and then will attempt to retransmit the character every 100 milliseconds for up to 15 seconds (the "15" is a countdown timer). If the countdown timer expires, C-Kermit returns to the prompt with a message like: Serial port blocked Tx waiting for CTS to be turned ON (the second line will tell you the reason for the blockage). Fifteen seconds is usually long enough for modems to retrain, but you can increase (or diminish) the retransmission timeout interval using the command: SET TERMINAL TRANSMIT-TIMEOUT <seconds> You can put the transmit timer on hold by typing or holding down certain keys, such as the Alt key. You can also escape back to the prompt while the BLOCKED message is visible, but other "hot key" functions are disabled. Note that the BLOCKED message might not appear right away -- depending on the buffering capabilities of the UART and the configuration of the OS/2 communication port driver, a transmission error might not be reported back to C-Kermit by OS/2 until the second or later blocked character. When you type a function or arrow key (which sends a multi-character escape sequence), or a key that has been defined (via SET KEY) to send a string of characters, or when you paste into the terminal window, C-Kermit perceives "keyboard" characters arriving at a much faster rate than if they were coming from normal keystrokes, and attempts to transmit them as fast as they arrive. This might cause buffer overruns in the serial device, particularly if it is a nonbuffered UART. Here again, you might see the TRANSMISSION BLOCKED message. Kermit has no way of telling the difference between keystrokes and pasted-in material, so transmission blockages can sometimes be a problem when pasting. If this happens to you, you can force a pause between ALL characters sent by C-Kermit during CONNECT mode by giving the command: SET TERMINAL OUTPUT-PACING <milliseconds> Try values like 20, 50, 100, etc; use the lowest one that makes the problem go away. Copying from a VIEW screen (e.g. OS/2 help text) and pasting into a Kermit (or any other Windowed program) does not work, due to a bug in OS/2. Workaround: paste into any PM editor (ie.,E or EPM) and then cut from there and paste into the C-Kermit session. PRINTER SUPPORT The good news: . The PRINT command works (if you have a printer). . SET PRINTER filename allows transparent-print material to be redirected to the specified file or device (32-bit version only). . Files can be transferred to PRN in the 32-bit version only. . LOG SESSION PRN works in the 32-bit version. . The Print-Screen key prints the current terminal emulation screen in the 32-bit version. If C-Kermit runs in a fullscreen session, Print-Screen prints a text copy of the display while if C-Kermit runs in a PM window, a graphical copy of the whole PM screen is printed (if your printer is capable of that). This is an OS/2 feature, having nothing to do with C-Kermit. . There is also a Print-Screen/Dump-Screen feature built into C-Kermit 5A(190) and later, that follows the SET PRINTER setting, for both the 16- and 32-bit versions, and works with both the current screen and with rolled-back screens. This feature is activated by the CONNECT-mode escape character, normally Ctrl-], followed by the letter F. It is also accomplished by the keyboard verbs, \Kdump or \KprtScn, which can be assigned to any key. . The keyboard verb, \KprintFF, sends a formeed to the printer. Most printers eject the current page upon receipt of a formfeed. Like all keyboard verbs, it can be assigned to any key or key combination. . Host initiated "print current cursor line" and "print current screen" are supported in the 32-bit version as of version 5A(190). . Host-initiated transparent print operations work correctly in the 32-bit version. . As of version 5A(190), VT52 printer functions are also supported. The bad news: . All host-initiated print operations are presently ignored by the 16-bit version (because if they are not ignored, they cause a stack overflow). . All host-initiated autoprint requests are treated like transparent print requests. . Print operations, when attempted on an OS/2 system that has no printer installed, might hang the Kermit program. To avoid this, use SET PRINTER to direct print data to a file or to the NUL device if you don't have a printer. OS/2 C-KERMIT WISH LIST . Regular OS/2-style graphical user interface (*). . True 80/132-column mode switching (*). . True, rather than simulated, double-width, double-height lines (*). . True, rather than simulated, underline and blink attributes (*). . Tektronix and other graphics terminal emulations (*). . Ability to execute VX-REXX programs (*). . 132-column mode via horizontal scrolling. . LK250/LK450 keyboard support. . Improved VT-220 emulation, including character set designation and invocation via ISO 4873 and 2022 rules. . User-controllable beep pitch and duration. . Support for non-IBM-compatible TCP/IP packages (e.g. Novell LWOS/2). . Ability to run in remote mode on both serial (OS2YOU) and network (TELNET) connections. Items marked with (*) require conversion of C-Kermit from a VIO to a PM application, which will make it a much bigger and slower program. COMMUNICATIONS AND DIALING Q: I tried to CONNECT to my modem and C-Kermit popped back to the prompt right away, saying "No carrier detected". A: C-Kermit's default handling of carrier is to not require it during DIALing, but to require it at other times. If you CONNECT to a modem before you have a dialed connection, there is no carrier signal, so i/o operations fail. If you need to CONNECT to a serial device that does not present the carrier signal (for example, to dial a modem "manually"), first tell C-Kermit to SET CARRIER OFF. Unless you have a very fast machine (say, 25 MHz or higher), OS/2 and its serial port drivers are not fast enough to keep up with serial input at 19200 bps or higher unless you have configured your connection for the optimum type of flow control, preferably RTS/CTS. Symptoms of lost data include fractured terminal screens during CONNECT and packet retransmissions during file transfer. High-speed communication works well if RTS/CTS is effective, but the overall throughput is limited by your PC's CPU speed (and how busy OS/2 is with other concurrent processes). OS/2 C-Kermit always uses 1 start bit and 1 stop bit. If Kermit's parity setting is NONE, it uses 8 data bits, otherwise it uses 7 data bits and one parity bit. Kermit controls parity itself, so you don't have to use the MODE command for this. SET LINE and SET PORT are synonyms, they do exactly the same thing: select the communication device. The syntax is the same for both: SET LINE [ <device-name> ] SET PORT [ <device-name> ] If you omit the device name, C-Kermit reverts to its default communications device, COM1. If you include a device name: 1. If the device name is a single digit, 1 through 8, C-Kermit converts this digit to the corresponding COM port name, COM1 through COM8. For example, "set port 2" is converted to "set port com2". 2. If the device name begins with an underscore character (_), and all of the following characters are numeric (for example, _12), the number is assumed to be a file descriptor for an already-open communication device (more about this below). If the device name begins with an underscore, but any non-numeric characters follow, a syntax error results. 3. Any other sequence of characters (including "COM1", etc) is accepted literally as a device name. This includes Universal Naming Convention (UNC) designations such as "\\server\modem" (which, due to Kermit's use of the backslash character as command-escape, must be entered as "\\\\server\\modem" or "//server/modem"). In cases (1) and (3), C-Kermit attempts to open the device, and then, if successful, checks to see whether it is a real communications device. If not, the SET LINE / SET PORT command fails. In case (2) (see below), no checking is done. NOTE: You can also pass an open file descriptor to C-Kermit on the command line, e.g. "ckermit -l 4". See the sample program in CKOEXP.DOC. Unless you use the MODE command to change it, the OS/2 serial port device driver requires the DSR and CTS signals to be asserted by the device (e.g. modem) it is connected to. If the device not provide these signals, C-Kermit will not be able to communicate. This is a feature of the OS/2 serial communications driver. In such cases, you can enable communication by telling the driver not to require them before starting C-Kermit (or in your CKERMIT.CMD file). For example: MODE COM2 IDSR=OFF,ODSR=OFF,OCTS=OFF If you have problems using COM3, COM4, or higher, specify the address and interrupt number (IRQ) in your OS/2 CONFIG.SYS file, in the line that starts the serial communication driver, COM.SYS (or SIO.SYS): DEVICE=C:\OS2\COM.SYS (number,base-address,irq) ... This example gives the addresses and IRQs for COM3 and COM4 but leaves the values for COM1 and COM2 alone: DEVICE=C:\OS2\COM.SYS (3,3E8,10) (4,2E8,15) and this example gives values for COM1 through COM4: DEVICE=C:\OS2\COM.SYS (1,3F8,4) (2,2F8,3) (3,3E8,10) (4,2E8,15) WARNING: the addresses and IRQs for COM3 and COM4 are not standardized, and can vary depending on the design and configuration of your communication board or internal modem. Consult the documentation that came with your device. Make sure you don't have multiple devices using the same IRQ. ANOTHER WARNING: SIO.SYS is a shareware replacement for COM.SYS with more flexible options for setting up access to ports and how they are simulated to DOS sessions. Performance of SIO.SYS and the standard COM.SYS on buffered 16550A ports can be considered roughly equal for OS/2 applications. SIO.SYS is not needed for C-Kermit, since C-Kermit is a native OS/2 application. However, SIO.SYS does provide support for extended buffered serial I/O boards such as the Hayes ESP which provide a 1024 character hardware buffer and extremely fast DMA transfer rates. If you have problems with serial communications -- screen freezing, lost characters, delayed echoing of characters, etc -- and you are using an early revision of SIO.SYS, try putting back the regular OS/2 communications port driver, COM.SYS. One user reports that these symptoms occur with any OS/2 communications program (such as PM Terminal), and are fixed for all such applications by replacing SIO.SYS with COM.SYS. This depends on the version of SIO.SYS in use, because some early revisions of it had problems with flow control. As of this writing, the current revision is 1.30. If you are unable to communicate at all on a serial connection, one possible reason might be that you have SET FLOW RTS/CTS (which is the default), but the serial device is not receiving the CTS signal. This can happen even if you have give a prior MODE COMx OCTS=OFF command. Try SET FLOW NONE. If that doesn't work, try rebooting your PC to reset the communications device driver. KEY ASSIGNMENTS The default key assignments are for a VT100 / VT102 terminal, as listed in "Using C-Kermit", Table V-3, page 430. DEC PF1-4 to PC F1-4. DEC keypad 0-9 to Alt-0 thru Alt-9, top rank, and so on. If you want to assign these functions to the PC's numeric keypad instead, simply TAKE CKOVTK2.INI. CKOVTK2.INI creates bindings for all DEC VT220/320 (LK201) keys to PC keys during terminal emulation. For further information, read the CKOVTK2.INI file itself. Note that the numeric keypad is in Numeric Mode by default, even after you TAKE CKOVTK2.INI -- this is normal, and follows the default for real DEC terminals. The host application software is (or should be) responsible for putting the keypad in the appropriate mode -- Numeric or Appplication. Should the software fail to do this, and assume the wrong mode for your keypad, then use the C-Kermit command SET TERMINAL KEYPAD { APPLICATION, NUMERIC } to correct the situation. SET KEY works with the Num Lock key, but several cautions are necessary: 1. Num Lock has two different scan codes: \510 and \766. 2. Every time you push Num Lock, the scan code toggles. 3. Every time you push Num Lock, the keypad state toggles. Assigning characters to Num Lock with SET KEY does not change this behavior. Thus, if you want the keypad keys to always send the same codes, no matter what the Num Lock state is, you must include two SET KEY commands for each key. This is done by CKOVTK2.INI. Key scan codes are not all the same as in MS-DOS Kermit. Most ordinary keys have the same codes, but not as many key combinations are differentiated. All combinations of Ctrl, Shift, and Alt with a particular key do not necessarily produce unique scan codes. TERMINAL EMULATION Frequently asked questions: Q: When I run C-Kermit with VT220 emulation to access either the DEC EVE (EDIT/TPU) editor or DEC VAX Notes, the screen is filled with gibberish like: m0lJ3l24rl6l7l8h;2'z;3'{4;H'z;H;H. A: Either tell C-Kermit to SET TERMINAL BYTESIZE 8 or tell VMS to SET TERMINAL /NOEIGHT. Q: How do I get Kermit to simulate all the functions of a DEC VT220 keyboard, including arrow keys, numeric keypad, Gold key, PF keys, F keys, etc? A: TAKE the CKOVTK2.INI file that is distributed with C-Kermit. Read this file to find out which PC key is mapped to which DEC key. If you don't like the mapping, edit this file to suit your taste. If you always want these mappings in effect, put the command "take c:\ckermit\ckovtk2.ini" in your CKERMOD.INI file (assuming you have installed C-Kermit in the C:\CKERMIT directory). Q: Key mapping does not work as described in Appendix V of "Using C-Kermit". A: That's right. In version 5A(190) and later it works just like in MS-DOS Kermit, using \Kverbs that can be assigned to any key. See the OS/2 section of CKCKER.UPD for a complete description of the new key mapping method, and all the other improvements in OS/2 C-Kermit since 5A(188). Or read the material about key mapping in "Using MS-DOS Kermit". Q: Screen rollback doesn't work the way it used to in versions 189 and earlier. I liked it better the old way! A: As of edit 190, there are two options for screen scrolling: SET TERMINAL ROLL OFF (the default, and the new way) and SET TERMINAL ROLL ON (the old way). The new way allows you to carry on a dialog with the host while in a rolled-back screen, which is handy when you need to refer to text that has scrolled away while conversing with the host. To get the old behavior back, SET TERMINAL ROLL ON. See the description of this command in the OS/2 section of CKCKER.UPD. Q: The SET TERM COLOR REVERSE command is gone! Version 190 now says "Sorry, this command has been retired. Reverse video is now accomplished simply by exchanging the fore- and background colors." I prefer the ability to set reverse video to whichever color scheme I wish. A: The old way was simply not workable -- it appeared to work only by accident. When all the VT100 features were fixed and VT220 and ANSI features were added, plus the cell-coloring extensions, there was no way to keep this Feature. Color is used not only for regular characters, but also to denote underlining, blinking, and (naturally) also for explicitly- colored characters. So it makes no sense to have one fore- and background color for reverse video. How, for example, does one flip the screen between normal video and reverse video when it has 128 different colors showing? This is a required feature of VT100 and higher DEC terminals (DECSCNM = ESC [ ? 5 h/l). Q: Reverse video doesn't always seem to actually reverse fore/background colors. For example, if I have the terminal set to black on white, reverse video comes out a rather muddy light gray on dark gray. If the terminal is set to light gray on dark gray, reverse is black on white. If the terminal is black on light gray, reverse video really is reverse. A: The explanation for this is a bit technical: The video adapter stores each screen character in a two-byte cell. The first byte of each cell contains the 8-bit character value. The second byte contains the video attributes for the character, and looks like this: Background | Foreground Color | Color +---+---+---+---+---+---+---+---+ | b | R | G | B | i | R | G | B | +---+---+---+---+---+---+---+---+ b = blink i = intensity 0 = nonblinking 0 = normal 1 = blinking 1 = high The i bit applies to the foreground color. The meaning of the b bit depends on the VIO state; it can mean (a) the foreground character blinks, or (b) the background color is high-intensity. C-Kermit uses (b) because blinking only works in a fullscreen session. The RGB bits select the desired mixture of Red, Green, and Blue. When video is reversed, only the colors -- the RGB bits and not the i or b bits are swapped. Otherwise, we would obtain effects that are even more surprising and undesirable: highlighted characters would no longer be highlighted, etc. If blinking were implemented by real blinking rather than color simulation, then a bright foreground could become a blinking foreground, etc. The confusion arises because many of the colors in the SET TERMINAL COLOR command are not "true" (3-bit) colors, but rather effects obtained with the high-intensity bit, as shown in Table 1. If you stick to non-intense colors in your terminal screen, then reverse video will work as expected. Table I: OS/2 C-Kermit Colors ---------------------------------- Name Intensity Remarks BLACK Normal BLUE Normal BROWN Normal CYAN Normal DGRAY High Dark gray GREEN Normal LBLUE High Light gray LCYAN High Light cyan LGRAY Normal LGREEN High Light green LMAGENTA High Light magenta LRED High Light red MAGENTA Normal RED Normal WHITE High YELLOW High ---------------------------------- LIMITATIONS Certain VT terminal features are not implemented, including: . Smooth scroll . Switching between 80- and 132-column mode and others are simulated: . Double-width and double-height lines (by doubling characters) . Underlining (by a distinct color) . Blinking (by the brightness of the background color) Blinking is simulated by a shift in background intensity because blinking cannot be done in an OS/2 window. Even in fullscreen sessions, the underlying video drivers tend to be buggy and inconsistent in their support for the blinking attribute. Underlining is simulated because color PC video adapters do not support underlining in text mode. Note that you should use a distinct background color for underlining if you want blinking text differentiated from underlined text. Double-height and -width lines are simulated because they cannot be accomplished in text mode; text terminal emulation in graphics mode would be painfully slow. C-Kermit's VT220 emulation lacks the following VT220 features: . Host-directed ISO 2022 character-set designation and invocation (use the SET TERMINAL CHARACTER-SET command for this). . Protected fields (because we don't have enough attribute bits): CSI Ps " q (Ps = 0, 1, 2) - select characters to be erasable or not CSI ? Ps K (Ps = 0, 1, 2) - erase erasable characters in line CSI ? Ps J (Ps = 0, 1, 2) - erase erasable characters in display . Various host-initiated printing controls (highly dependent on DEC printers): CSI ? 43 h/l - Large/normal characters CSI ? 44 h/l - Color/monochrome CSI ? 45 h/l - RGB vs HLS color system CSI ? 46 h/l - Background+foreground/only-foreground to printer CSI ? 47 h/l - Rotated/normal printing . Downline-Loadable Character sets (DRCS) (graphics mode would be required) . VT240 Tektronix, Sixel, or ReGIS graphics (graphics mode would be required) . UDK's (can be done if there is a demand, but it might be tough finding fifteen keys with unique and unused scan codes to map them to!). ANSI TERMINAL EMULATION So-called ANSI terminal emulation is a subset of VT100 emulation, but with host- controlled colors and using 8-bit IBM code-page 437 characters for line and box drawing, plus some unique escape sequences for cursor save/restore. ANSI terminal emulation is generally used to communicate with BBSs, and has nothing to do with ANSI (the American National Standards Institute); the misappropriated term "ANSI" seems to derive from the MS-DOS (and OS/2) ANSI.SYS console driver, itself misnamed. C-Kermit supports ANSI terminal emulation as of edit 190, via SET TERMINAL TYPE ANSI. C-Kermit's ANSI emulation does nothing special with the keys; in particular, there is no attempt at "PCTERM" keyboard handling, in which unique key-down and key-up sequences are transmitted separately for every single IBM key (including Shift, Alt, etc), apparently needed for the SCO UNIX console terminal, but evidently not needed for BBS's. There is also no support for so-called ANSI music, which violates every conceivable rule (laid down by ANSI itself!) about the structure and form of escape sequences. 132 COLUMNS You can use 132 columns in a fullscreen session if your video adapter supports it. Issue the command: MODE CO132,xx (where xx is the desired screen length) at the CMD prompt, or: RUN MODE CO132,xx at the C-Kermit prompt. You can switch back to 80-column mode via: [ RUN ] MODE CO80,xx 132-column mode is not supported in an OS/2 window. Host-directed switching between 80- and 132-column mode is presently not supported. OTHER TERMINAL EMULATION ITEMS... Scrolling is slower in an OS/2 Window. This is because OS/2 is operating in graphics mode (to simulate text mode) and must draw each dot (pixel) individually. Fullscreen scrolling, which uses character mode, is much faster. But when running C-Kermit in fullscreen mode you lose the ability to cut and paste between applications. Unless you say otherwise, C-Kermit employs a trick to make screen updates faster: The cursor disappears briefly while the screen is being updated and appears again within a few milliseconds after screen activity stops. Since this can be disconcerting to fast typists, edit 190 adds a new command, SET TERMINAL HIDE-CURSOR { ON, OFF } to let you turn this feature off (or back on). Experimentation on a relatively fast PC shows that TERMINAL HIDE-CURSOR OFF makes screen updates about 1/3 slower on network connections, but makes little difference on serial connections, where the communication speed is the bottleneck. SET FLOW XON/XOFF prevents you from transmitting Ctrl-S and Ctrl-Q characters to the host. These characters are commands (Search and Quote) in EMACS. To use Ctrl-S and Ctrl-Q as commands to host applications, you must SET FLOW NONE or SET FLOW RTS/CTS. Shift-in/Shift-Out works only if you SET TERMINAL LOCKING-SHIFT ON (except in the case of the DEC Technical Character Set, used for line- and box- drawing, etc, which is handled specially). Host-directed US/UK character-set switching (ASCII 35 interpreted as number sign in US, Pound Sterling sign in UK) works only if you have SET TERM CHARACTER-SET ASCII. Under certain conditions on certain systems, OS/2 C-Kermit has been observed to put the entire screen (or subsequent help screens) in blinking mode. For example, when running in a fullscreen session, CONNECT mode active, background color is high-intensity, and using Alt-Esc to get to the desktop, then resuming the Kermit window can produce this effect; reportedly, this is caused by a bug in some of OS/2's video drivers. Alt-R (reset) makes the blinking stop. To avoid the problem altogether, don't use high-intensity background colors. See Table I above. COMMAND PROCESSING Command recall, added in edit 190, allows you to recall earlier commands by typing Ctrl-B or UpArrow. In other C-Kermit versions (UNIX, etc) Ctrl-P is used for this purpose, but you can't use Ctrl-P in OS/2 because it turns on your printer. If you type Ctrl-P at the C-Kermit> prompt and nothing happens (no beep, no recalled command, but you hear some disk activity)), then type Ctrl-P once more (to turn off the printer) and use Ctrl-B for command recall instead. As of edit 190, C-Kermit should be able to handle bare backslashes in file specifications in most commands, e.g. send c:\letters\angry.txt cd e:\temp However, you still can't end a command with a single backslash, e.g.: cd c:\ because C-Kermit treats a single backslash at the end of a command as a line-continuation indicator. To get around this, double the backslash: cd c:\\ FILE TRANSFER Be sure to activate the appropriate type of flow control before transferring files, especially if you are using long packets: SET FLOW RTS/CTS Preferred, if the device your PC is immediately connected to supports it. SET FLOW XON/XOFF Used end-to-end, but subject to noise corruption, propogation delays, etc. By default OS/2 C-Kermit uses whatever flow control is already configured for the communications port driver at the time you started C-Kermit. WARNING: If your FLOW-CONTROL setting is RTS/CTS and serial connections don't work (screen and keyboard seem to be frozen), it is likely that the device and/or cable is not providing the CTS signal to your PC. In that case, try using SET FLOW NONE or SET FLOW XON/XOFF. For transferring files with HP-48 Series calculators, use all the default settings (short packets, window size 1, etc), but SET FLOW NONE. There is no way send the complete contents of a file in text mode if the file contains a Ctrl-Z character that is not the last character in the file. In other words, Ctrl-Z is always treated as end-of-file when the FILE TYPE is set to TEXT. There should be a SET EOF {CTRLZ, NOCTRLZ} command as in MS-DOS Kermit to control the treatment of Ctrl-Z characters in text files. Reportedly (not confirmed), wildcard expansion (e.g. "send oofa.*" or "echo \ffiles(oofa.*)") does not work on NFS-mounted volumes under IBM TCP/IP 1.2.1 (but these operations do work OK under IBM TCP/IP 2.0). SET FILE COLLISION UPDATE has the following peculiarity: On FAT (i.e. DOS) file systems, a file's date/time is recorded with a granularity of 2 seconds, whereas on most other kinds of file systems (UNIX, VMS, OS/2 HPFS, etc), it is recorded to at least the exact second. Thus when OS/2 C-Kermit records the timestamp of an incoming file, the "one's place" of its time is truncated. If it was an odd number, therefore, it will be one second "older" than the date/time of the original file. Downloading the same file again with SET FILE COLLISION UPDATE would result in a second, unnecessary transfer of the file, since the remote file would appear to be newer than the local file. Therefore, OS/2 C-Kermit, when making this comparison, will treat two times as equal if (a) the local file's time is an even number, (b) the remote time is equal to (of course) or exactly one second greater than the local time, and (c) the local file system is FAT. Refreshing the fullscreen file transfer display (by typing Ctrl-L or Ctrl-W) does not refresh all of the fields. REMOTE ACCESS If your OS/2 2.x system is running IBM TCP/IP, it is possible to TELNET to your OS/2 system to have a CMD session, in which you can run only character-mode commands and applications. Depending on the kind of machine you are TELNETing from, you might be able to run only programs which use standard (or real keyboard) input and standard output. If the program does VIO screen output it will run in a TELNET session only if you TELNETed into the OS/2 PC from another OS/2 PC, not from (for example) a UNIX or VMS machine. The reason is that intercepting and relaying VIO screen output to a remote machine is only possible with support from the remote machine, which is only implemented in the OS/2 TELNET client. Since C-Kermit does VIO output, it will not work if you TELNET into the OS/2 machine from a non-OS/2 machine. It will also only work if you TELNET into the OS/2 machine from another OS/2 machine using the real IBM OS/2 TELNET program, not with any other TELNET client application (including C-Kermit) because the mentioned client support is implemented only in the IBM TELNET application. If you run a PM application (such as "help") while TELNETed to your OS/2 system, your session will hang because control will have been transferred to the real keyboard, mouse, and screen. Similarly, if you manage to invoke the OS/2 critical error handler during a character-mode application (for example, "dir a:" when there is no diskette in the A: drive). You can run C-Kermit in a remote TCP/IP session and tell OS/2 C-Kermit to SET LINE to a serial device and call up a third computer. Thus OS/2 C-Kermit can be used as a modem server in the TCP/IP environment. However, at present you cannot transfer files between your local Kermit program and OS/2 C-Kermit when TELNET'd *to* OS/2 because sockets are different from file handles in OS/2 and are not passed to child processes via the "tty" file handle, as they are in UNIX in the same situation. It is also possible to get an OS/2 CMD session on a serial connection when dialing into your OS/2 system if you are running a product such as OS2YOU, but C-Kermit file transfer does not yet work in this environment either. (End of CKOKER.BWR)