File CKLKER.BWR: "Beware File" for C-Kermit Version 7.0 on Stratus VOS Applies to: C-Kermit 7.0.197 Last update: 8 February 2000 Authors: David Lane Frank da Cruz Copyright (C) 1985, 2000, Trustees of Columbia University in the City of New York. All rights reserved. See the C-Kermit COPYING.TXT file or the copyright text in the ckcmai.c module for disclaimer and permissions. Report problems, suggestions, fixes, etc, to: The Kermit Project Columbia University 612 West 115th Street New York NY 10025-7799 USA Email: kermit-support@columbia.edu Web: http://www.columbia.edu/kermit/ News: comp.protocols.kermit.misc DOCUMENTATION Frank da Cruz and Christine M. Gianone, "Using C-Kermit", Second Edition, 1997, Digital Press / Butterworth-Heinemann, Woburn, MA, ISBN 1-55558-164-1 US single-copy price: $44.95; quantity discounts available. Available in computer bookstores or directly from Columbia University: http://www.columbia.edu/kermit/manuals.html Features added after version 6.0 was released are documented in the text file, ckermit2.txt. WHAT IS IN THIS FILE This is the "beware file" for Stratus VOS C-Kermit. It contains hints and tips, frequently asked questions (and answers), troubleshooting advice, limitations and restrictions, known bugs, etc, that apply to the Stratus VOS implementation of C-Kermit. This file is the VOS-specific supplement to the platform-independent "beware file" for C-Kermit, ckcbwr.txt. KNOWN PROBLEMS AND LIMITATIONS The maximum length for a pathname segment (such as a filename) is 31 characters. You should use full device names in the SET LINE command. If you don't, VOS C-Kermit might not realize that the device name has not changed or you are using the same device again (such as when CONNECTing). Also, abbreviations are not expanded in file names or device names, but they are in RUN commands or REMOTE HOST commands received in remote mode if you load your abbreviations in your start_up.cm file. Users attaching via TCP/IP in remote mode have reported hangs during file transfers. It looks like some channel gets choked up and then the transfer slows enough for the receiving Kermit to time out repeatedly, with a rare packet getting through. Often the transfer will abort at this point. One reported solution is to use smaller packets and windows. Network performance seems to be one factor. Transfers of real VOS binary files, such as object or program modules is very shaky. These can be transfered in binary mode, but they will be created on the receiving VOS system as stream files. To convert them into a usable format, use the cvt_stream_to_fixed command. Better yet, use the bundle.cm macro that is available free from ftp.stratus.com/pub/vos/utility. This utility is only for Stratus-to-Stratus use; it converts VOS files so they can pass through and be stored on non-VOS systems. Such bundles must eventually be transferred to a Stratus destination where "unbundle.cm" extracts the original VOS files intact. Text files are transferred in BINARY mode correctly only if they have Stream organization. It might be surprising, therefore, that a VOS text file created with EMACS loses all its line terminators after transfer with VOS C-Kermit. That's because VOS EMACS creates files with Sequential rather than Stream organization. The easiest way to avoid this is to transfer files that are text in TEXT mode. However, EMACS will edit a stream file and keep its format intact: create_file oofa.txt -organization stream emacs oofa.txt C-Kermit uses sub-processes to do a lot of things. Normally, this is done using the system() routine in the ANSI C Library. However, in the VOS C runtime library, the system() routine does things that are not consistent with C-Kermit. For this reason, VOS C-Kermit has its own builtin version of system() which uses s$start_process. This causes a lot of process messages to be displayed to the terminal. Library paths and abbreviations in these started processes, which include RUN commands and REMOTE HOST commands received in remote mode, will be the paths set in your start_up.cm for a batch process, regardless of the type of process running Kermit. C-Kermit implements the MAIL file destination by using the send_mail command. Send_mail does not support SMTP addresses, even though OFFICE mail and emacs do, so you cannot send Internet mail to an address via Kermit, but if you have the addressee registered as an "External Mail User" that will work. C-Kermit performs raw i/o to the terminal, and does its own echoing of command line input. When your terminal is a vterm using an X.25 PAD, this can make C-Kermit look like it is slow. It is not. The Virtual Terminal Facility configures the PAD to delay sending each packet for a quarter of a second to see if you will hit another key. As long as your typing is fast enough that you don't have a quarter of a second between keystrokes, the PAD will not send any of the characters you have typed to VOS, and C-Kermit will not echo any of them. There is a word that can be set in VTF to reduce the delay. COMMUNICATIONS AND DIALING The DIAL command will work occasionally. The major problem appears to be in the timeout mechanism. If your modem type is supported, and there are no obvious errors in the dialing sequence, such as no dialtone or no answer, then the dialing support works. If dialing appears to "just stop," then it might be necessary for you to type dialing commands to the modem using CONNECT mode. Flow control is not currently supported. VOS does not always support an eight-bit connection, or report that it cannot support one. This is also not always a problem with VOS, since many times the connection itself is stripping the high-bit without VOS being aware of it. CHARACTER SET SUPPORT The VOS internal character set is ISO-8859-1. VOS C-Kermit does not automatically detect shift characters or character sets associated with files. If the file character set is LATIN1, then VOS will usually send it correctly and receive it correctly in text mode. (End of CKLBWR.TXT)