CKLKER.BWR "Beware File" for C-Kermit Version 5A Applies to 5A(190) Last update: Mon Apr 22 17:09:19 1996 Authors: David Lane Frank da Cruz, Christine M. Gianone, Columbia University. Copyright (C) 1985, 1996, 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 kermit@columbia.edu, or: 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, Digital Press, Burlington, MA, USA. Price: US $39.95. Available at book and computer stores, or to order from Columbia University, call +1 212 854-3703. FILES File naming conventions are listed in ckaaaa.hlp. VOS installation instructions are in the build macro (cklmak.cm) with further details in cklins.doc and ckccfg.doc. Updates to the software are listed in ckc*.upd. KNOWN PROBLEMS AND LIMITATIONS There is no FULLSCREEN file transfer display. You should use full device names in the SET LINE command. If you don't, VOS C-Kermit may 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. Writing a program to s$read_raw 4096 bytes from the stream file and s$seq_write 4096 bytes out to the fixed file (4096 for program modules, use 1024 for object modules) is one solution. The ckb*.c programs have been "VOS-ified" to the extent that they can be used to transfer program modules, and can easily be altered to transfer other fixed files. 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 may 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. 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. ------------------------------ From: David Lane Subject: Faux pas in VOS C-Kermit in background To: kermit@watsun.cc.columbia.edu Date: Tue, 26 Sep 1995 22:03:49 -0400 (EDT) Well, this is what appears to be the problem--C-Kermit still thinks it's in the foreground, so it's checking the console port for things. There is a bit flipped (Don't you *HATE* single bit fixes!?) around line 1500 in ckltio.c, in the routine conbgt. The backgrd flag is being set (incorrectly) to 0 when the process is not interactive. It should be set to 1. On the line in the middle, change the "backgrd = 0;" to be "backgrd = 1;" Here is a bit of context of the incorrect version: ------------------------------------------------------------------------- pinfo.version = PROCESS_INFO_VERSION; s$get_process_info (&pid, &pinfo, &status); if ((pinfo.info.flags & INTERACTIVE) == 0) backgrd = 0; else { if (vostty(TERMINAL_PORT_ID)) /* do we have a tty terminal port ? */ backgrd = 0; else -------------------------------------------------------------------------- Sorry about that... As a disclaimer, I have to say I haven't actually tested this change. It's possible that it still gets stuck when it's in the background, but at least IF BACKGROUND should work properly... David ------------------------------ Date: Fri, 19 Apr 1996 10:01:35 -0400 (EDT) From: David Lane Subject: beware additions There are several problems that have been brought up and fixed in the last month or so... The first is that the VOS C-Kermit did not work on window_term devices over the TELNET access layer. I made changes to the terminal io support and it appears to be okay now. Thanks go to Richard Shuford for pointing this out and testing the changes as I don't have any applicable devices. The second is a relatively minor compilation problem when using the newer compiler under VOS 13. I had taken the address of an array, and the new compiler doesn't like this. Changed to take the address of the first element of the array. The credit for finding this one goes to Tim Gamble . The third is a significant problem compiling on VOS 13, which may affect other code than C-Kermit. It appears that there is an incompatible change in the get_port_info.incl.c header, due to a new tool being used at Stratus to generate the includes. The old tool created a "struct $shortmap get_port_info" and the new tool creates a typedef called get_port_info. It also seems that there is a migration to the new tool, so other headers may change in future releases. This should have been in the VOS 13 SRB, but wasn't. There is a doc bug against this. Thanks go to Tim Gamble again for finding it, and to Paul Green for some advice on how to work around it, as well as for generally being helpful. The changes involving "backgrd" in ckltio.c are described in the CKLKER.BWR file earlier. VOS compare_files output for changes follows: ====================================================================== A (columbia>cklfio.c) does not match B (new>cklfio.c). A2 char *ckzv = "Stratus VOS File support, 5A(003) 28 Aug 1994"; changed to B2 char *ckzv = "Stratus VOS File support, 5A(004) 22 Mar 1996"; A1965 s$set_object_times (&path, &file_times, &status); changed to B1965 s$set_object_times (&path, &file_times[0], &status); 2 data difference(s). ====================================================================== A (columbia>ckltio.c) does not match B (new>ckltio.c). A3 char *ckxv = "Stratus VOS Communications support, 5A(006), 15 Oct 94"; changed to B3 char *ckxv = "Stratus VOS Communications support, 5A(006), 22 Mar 96"; B42 /* In releases prior to 13, get_port_info is a struct tag. In 13, it B43 becomes a typedef. No, it's not in the SRB, it's just an incompatible B44 change in a system include file. (YECH!) The cklmak.cm macro tries B45 to set this define on releases before 13. YMMV, unfortunately. B46 */ B47 #ifdef GET_PORT_INFO_IS_STRUCT B48 typedef struct get_port_info get_port_info; B49 #endif inserted before A42 typedef struct A303 struct get_port_info *pinfo, short *status) ); changed to B312 get_port_info *pinfo, short *status) ); A822 if (status) A823 return -1; /* failure */ changed to B831 if (status) { B832 debug(F111,"tthang s$control ASYNC_HANGUP status",ttnmful,status); B833 return -1; B834 } A893 if (status) A894 return -1; changed to B904 if (status) { B905 debug(F111,"ttres s$control SET_MODES status",ttnmful,status); B906 return -1; B907 } A970 if (status) return (-1); changed to B983 if (status) { B984 debug(F111,"ttpkt s$control SET_MODES status",ttnmful,status); B985 return -1; B986 } A978 if (status) return (-1); changed to B994 if (status) { B995 debug(F111,"ttpkt s$control TERM_GET_CONFIG status",ttnmful,status); B996 return -1; B997 } A1010 if (status) return (-1); changed to B1029 if (status) { B1030 debug(F111,"ttpkt s$control TERM_CONFIGURE status",ttnmful,status); B1031 /* DON'T RETURN FAILURE! window_term's can't do this! */ B1032 } A1066 if (status) return (-1); changed to B1088 if (status) { B1089 debug(F111,"ttvt s$control SET_MODES status",ttnmful,status); B1090 return -1; B1091 } A1074 if (status) return (-1); changed to B1099 if (status) { B1100 debug(F111,"ttvt s$control TERM_GET_CONFIG status",ttnmful,status); B1101 return -1; B1102 } A1106 if (status) return (-1); changed to B1134 if (status) { B1135 debug(F111,"ttvt s$control TERM_CONFIGURE status",ttnmful,status); B1136 /* DON'T RETURN FAILURE! window_term's can't do this! */ B1137 } A1221 if (status) return (-1); changed to B1252 if (status) { B1253 debug(F111,"ttgspd s$control TERM_GET_CONFIG status", B1254 ttnmful,status); B1255 return -1; B1256 } A1252 if (status) return (-1); changed to B1288 if (status) { B1289 debug(F111,"congspd s$control TERM_GET_CONFIG status",ttnmful,status); B1290 return -1; B1291 } A1500 backgrd = 0; changed to B1540 backgrd = 1; A2123 if (status) A2124 return -1; changed to B2163 if (status) { B2164 debug(F111,"congm s$control GET_INFO status",ttnmful,status); B2165 return -1; B2166 } A2203 debug(F101,"conbin status","",status); changed to B2245 debug(F101,"conbin s$control SET_MODES status","",status); A2908 struct get_port_info info; changed to B2950 get_port_info info; A2927 struct get_port_info info; changed to B2969 get_port_info info; 18 data difference(s). ====================================================================== A (columbia>cklmak.cm) does not match B (new>cklmak.cm). B28 & Work around an incompatible include file change... B29 &set_string rel (reverse (before (reverse (module_info system_release)) ' ')) B30 &set_string rel (before &$rel& '.') B31 &if &rel& < 13 B32 &then &set_string KOPTS (concat (quote &KOPTS&) ' GET_PORT_INFO_IS_STRUCT') inserted before A28 &set_string mydir (current_dir) 1 data difference(s). ====================================================================== ------------------------------