Columbia Kermit/kermit.zip/archives/ckl196.zip/cklbwr.txt

Text File | 2000-01-02 | 6KB | 141 lines

File CKLKER.BWR:  "Beware File" for C-Kermit Version 7.0 on Stratus VOS

Applies to:  C-Kermit 7.0 Beta.11
Last update: Sun Dec  5 14:34:06 1999

Authors:  David Lane <[e-mail]>
          Frank da Cruz <[e-mail]>

  Copyright (C) 1985, 1999,
    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: [e-mail]
  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.

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 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. 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.

Text files are transferred 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.  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. 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)