ckuker.bwr

linux终端仿真程序

CKUKER.BWR         "Beware File" for C-Kermit Version 6.0         -*- text -*-

				 UNIX VERSION

As of C-Kermit version:  6.0.192
This file last updated:  Fri Sep  6 23:23:23 1996

Authors: Frank da Cruz and 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.

WHAT IS IN THIS FILE

This is the "beware file" for the UNIX version of C-Kermit.  It contains
hints and tips, frequently asked questions (and answers), troubleshooting
advice, limitations and restrictions, known bugs, etc, that apply to all UNIX
variations, as well as to specific ones like HP-UX, AIX, SunOS, Solaris,
Unixware, NeXTSTEP, etc etc.  It should be read in conjunction with the
system-independent C-Kermit "beware file", ckcker.bwr, which contains similar
information that applies to all versions of C-Kermit (VMS, OS/2, AOS/VS, VOS,
etc, as well as to UNIX).

CONTENTS:

  (0) DOCUMENTATION
  (1) IMPORTANT FILES
  (2) BINARIES
  (3) NOTES ON SPECIFIC UNIX VERSIONS
  (3.1) C-KERMIT AND AIX
  (3.2) C-KERMIT AND HP-UX
  (3.3) C-KERMIT AND LINUX
  (3.4) C-KERMIT AND NEXTSTEP
  (3.5) C-KERMIT AND QNX
  (3.6) C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER
  (3.7) C-KERMIT AND SOLARIS
  (3.8) C-KERMIT AND SUNOS
  (3.9) C-KERMIT AND ULTRIX
  (3.10) C-KERMIT AND UNIXWARE
  (3.11) C-KERMIT AND APOLLO SR10
  (3.12) C-KERMIT AND TANDY XENIX 3.0
  (3.13) C-KERMIT AND OSF/1 (DIGITAL UNIX)
  (3.14) C-KERMIT AND SGI IRIX
  (3.15) C-KERMIT AND THE BEBOX
  (4) GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
  (5) INITIALIZATION AND COMMAND FILES
  (6) COMMUNICATION SPEED SELECTION
  (7) COMMUNICATIONS AND DIALING
  (8) HARDWARE FLOW CONTROL
  (9) TERMINAL CONNECTION AND KEY MAPPING
  (10) FILE TRANSFER
  (11) EXTERNAL FILE TRANSFER PROTOCOLS
  (11.1) C-KERMIT AS AN EXTERNAL PROTOCOL
  (11.2) INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
  (11.3) USING C-KERMIT WITH TERM
  (12) MISCELLANEOUS

(0) DOCUMENTATION

C-Kermit is documented in the book "Using C-Kermit" by Frank da Cruz and
Christine M. Gianone, Digital Press, Burlington, MA, USA, ISBN 1-55558-164-1.
Price: US $39.95.  To order, call Columbia University, New York City,
at [phone], or Digital Press / Butterworth-Heinemann at:

  [phone]  (Massachusetts office for USA & Canada)
  [phone] (Rushden, England office for Europe)
  [phone]   (Chatswood, NSW, office for Australia & New Zealand)
  [phone]     (Singapore office for Asia)

A German edition is available from Verlag Heinz Heise in Hannover, Germany,
Tel. [phone], Fax. [phone].

New features added since these books were published are documented in the
ckcker.upd file.

TECHNICAL SUPPORT

Please consult the documentation listed above, plus the ckcker.bwr file and
this file itself, before submitting questions, reporting problems, etc, to:

  E-Mail: [e-mail]

    News: comp.protocols.kermit.misc

    Post: The Kermit Project
          Columbia University
          612 West 115th Street
          New York NY  10025-7799
          USA

    Fax: [phone]
     or: [phone]

Telephone support also available:

  USA Only:  [phone], cost: $2.50 per minute
  Anywhere:  [phone], cost: $25.00 per call, payable via Visa or MC.


(1) IMPORTANT FILES

In addition to the published documentation, the following files are useful
in troubleshooting:

    ckaaaa.hlp:  Overview, file naming conventions, list of files, etc.
    ckuins.doc:  Installation instructions for UNIX C-Kermit.
    ckccfg.doc:  C-Kermit program configuration information.
    ckcker.bwr:  C-Kermit "beware file" for all C-Kermit implementations.
    ckuker.bwr:  C-Kermit "beware file" specific to UNIX (this file).
    ckcplm.doc:  C-Kermit program logic manual.
    ckcker.upd:  User documentation for features added since 5A(188).
    ckcXXX.upd:  Program edit history for edit XXX, e.g. ckc190.upd.

(2) BINARIES

It is often dangerous to run a binary C-Kermit (or any other) program built
on a different computer.  Particularly if that computer had a different C
compiler, libraries, operating system version, processor features, etc, and
especially if the program was built with shared libraries.

It is often OK to run a binary built on an earlier OS version, but it is
rarely possible (or safe) to run a binary built on a later one, for example
to run a binary built under SunOS 4.1.2 on a SunOS 4.1.1 system.

When in doubt, build C-Kermit from the source code on the system where it is
to be run (if possible!).  If not, ask us for a binary specific to your
configuration.  We might have one, and if we don't, we might be able to get
one.

(3) NOTES ON SPECIFIC UNIX VERSIONS

The following sections apply to specific UNIX versions.

(3.1) C-KERMIT AND AIX

Many problems reported with bidirectional terminal lines on AIX 3.2.x on the
RS/6000.  Workaround: don't use bidirectional terminal lines, or write some
kind of shell script that turns getty off on the line before starting Kermit,
or before Kermit attempts to do the SET LINE.  (But note: These problems
MIGHT be fixed in C-Kermit 6.0.192.)

Reportedly, all versions of IBM AIX use the same (undocumented) lockfile
conventions as RTAIX.  If this is true, the "makes" for PS/2 AIX and AIX/370
will have to be changed to use the RTAIX convention (it may be sufficient to
simply add -DRTAIX to the make entry).

C-Kermit SET HOST or TELNET from AIX on an RS/6000 to another RS/6000 won't
work right unless you set your local terminal type to something other than
AIXTERM.  When your terminal type is AIXTERM, AIX TELNET sends two escapes
whenever you type one, and the AIX telnet server swallows one of them.
This has something to do with the "hft" device.  This behavior is reportedly
removed in AIX 3.2.

Transfer of binary -- and maybe even text -- files can fail on AIX 3.x.  The
problem was traced to a facility in AIX whereby a particular port can have
character-set translation done for it by the tty driver.  The following
advice from a knowledgeable AIX user:

  (begin quote...)  [This feature] has to be checked (and set/cleared) with
  a separate command, unfortunately stty doesn't handle this.  To check:

    $ setmaps
    input map: none installed
    output map: none installed

  If it says anthing other than "none installed" for either one, it is likely
  to cause a problem with kermit.  To get rid of installed maps:

    $ setmaps -t NOMAP

  However, I seem to recall that with some versions of AIX before 3.2.5, only
  root could change the setting.  I'm not sure what versions - it might have
  only been under AIX 3.1 that this was true.  At least with AIX 3.2.5 an
  ordinary user can set or clear the maps.  (...end quote) And this would
  imply that Kermit itself cannot be coded to take care of this, because it
  would have to run as root.  On the same problem, another knowledgeable AIX
  user says:

  The way to get information on the NLS mapping under AIX (3.2.5 anyway) is
  as follows.  From the command line type:

    lsattr -l tty# -a imap -a omap -E -H

  Replace the tty number for the number sign above. This will give a human
  readable output of the settings that looks like this;

    # lsattr -l tty2 -a imap -a omap -E -H
    attribute value description     user_settable

    imap      none  INPUT map file  True
    omap      none  OUTPUT map file True

  If you change the -H to a -O, you get output that can easily be processed
  by another program or a shell script, for example:

    # lsattr -l tty2 -a imap -a omap -E -O
    #imap:omap
    none:none

  To change the settings from the command line, the chdev command is used
  with the following syntax.

    chdev -l tty# -a imap='none' -a omap='none'

  Again substituting the appropriate tty port number for the number sign,
  "none" being the value we want for C-Kermit.  Of course, the above can also
  be changed by using the SMIT utility and selecting devices - tty.
  (...end quote)

(3.2) C-KERMIT AND HP-UX

During the C-Kermit 6.0 Beta cycle, something happened to ckcpro.w (or, more
precisely, the ckcpro.c file that is generated from it) which causes HP
optimizing compilers under HP-UX versions 7.0 and 8.0 (apparently on all
platforms) as well as under HP-UX 9.0 on Motorola platforms only, to blow up.
The symptoms vary from the system grinding to a halt, to the compiler
crashing, to the compilation of the ckcpro.c module taking very long periods
of time, like 9 hours.

On HP-UX 9.0, a kernel parameter, maxdsiz (maximum process data segment size),
seems to be important.  On Motorola systems, it is 16MB by default, whereas on
RISC systems the default is much bigger.  Increasing maxdsiz to about 80MB
seems to make the problem go away, but only if the system also has a lot of
physical memory -- otherwise it swaps itself to death.

Therefore, the C-Kermit 6.0 makefile entries for HP-UX 7.x and 8.x that do
optimization, compile ckcpro.c first without optimization.  For HP-UX 9.0, a
special entry, hpux90mot, was added for Motorola makes; the regular entries
optimize all modules.

Even so, the optimizing compiler will often complain about "some optimizations
skipped" on certain modules, due to lack of space available to the optimizer.
You can always increase the space (the incantation depends on the particular
compiler version -- see the makefile), but doing so tends to make the
compilations take a much longer time.  For example, the "hpux100o+" makefile
entry adds the "+Onolimit" compiler flag, and about an hour to the compile
time on an HP-9000/730.  But it *does* produce an executable that is about
10K smaller :-)

(3.2.0) Performance

An unexpected slowness has been noted when transferring files over local
Ethernet connections when an HP-UX system (9.0 or later, perhaps also earlier
versions) is on the remote end.   The following experiment was conducted to
determine the cause.

The systems were HP-UX 10.00 (on 715/33) and SunOS 4.1.3 (on Sparc-20), both
on the same local 10Mbps Ethernet.  Window size 20, packet length 4096, parity
none, control prefixing "cautious", using only local disks on each machine --
no NFS.  The file was a 1.08MB binary file (wermit), transferred in binary
mode.  Conditions were relatively poor: the Sun and the local net heavily
loaded; the HP system is slow and memory-constrained.

 Client   Server   Send    Receive
  Sun      HP       36       18    <-- K cps
  HP       HP       25       15      
  HP       Sun      77       83
  Sun      Sun      60       60

So whenever HP is the server we have bad performance.  Why?

 . Changing file display to CRT has no effect (so it's not the curses
   library on the client side).

 . Changing TCP RECV-BUFFER or SEND-BUFFER has very little effect.

 . Telling the client to make a binary-mode connection (SET TELNET BINARY
   REQUESTED, which successfully negotiates a binary connection) has no effect.

BUT...  If I start C-Kermit as a TCP server:

  set host * 3000
  server

and then from the client "set host blah 3000", I get: