ckubwr.txt

KERMIT工具 这在办公室下载不了,很多人都没有载不到.

          <Key>Pause: string(0x1b) string("[34~") \n\
          <Key>Insert: string(0x1b) string("[2~") \n\
          <Key>Delete: string(0x1b) string("[3~") \n\
          <Key>Home: string(0x1b) string("[1~") \n\
          <Key>End: string(0x1b) string("[4~") \n\
          <Key>Prior: string(0x1b) string("[5~") \n\
          <Key>Next: string(0x1b) string("[6~") \n\
          <Key>BackSpace: string(0x7f) \n\
          <Key>Num_Lock: string(0x1b) string("OP") \n\
          <Key>KP_Divide: string(0x1b) string("Ol") \n\
          <Key>KP_Multiply: string(0x1b) string("Om") \n\
          <Key>KP_Subtract: string(0x1b) string("OS") \n\
          <Key>KP_Add: string(0x1b) string("OM") \n\
          <Key>KP_Enter: string(0x1b) string("OM") \n\
          <Key>KP_Decimal: string(0x1b) string("On") \n\
          <Key>KP_0: string(0x1b) string("Op") \n\
          <Key>KP_1: string(0x1b) string("Oq") \n\
          <Key>KP_2: string(0x1b) string("Or") \n\
          <Key>KP_3: string(0x1b) string("Os") \n\
          <Key>KP_4: string(0x1b) string("Ot") \n\
          <Key>KP_5: string(0x1b) string("Ou") \n\
          <Key>KP_6: string(0x1b) string("Ov") \n\
          <Key>KP_7: string(0x1b) string("Ow") \n\
          <Key>KP_8: string(0x1b) string("Ox") \n\
          <Key>KP_9: string(0x1b) string("Oy") \n

  !       <Key>Up: string(0x1b) string("[A") \n\
  !       <Key>Down: string(0x1b) string("[B") \n\
  !       <Key>Right: string(0x1b) string("[C") \n\
  !       <Key>Left: string(0x1b) string("[D") \n\

  *visualBell:    true
  *saveLines:     1000
  *cursesemul:    true
  *scrollKey:     true
  *scrollBar:     true
    ________________________________________________________________________

  3.2. C-KERMIT AND HP-UX

   [ [184]Top ] [ [185]Contents ] [ [186]Section Contents ] [ [187]Next ]
   [ [188]Previous ]

   SECTION CONTENTS

  3.2.0. [189]Common Problems
  3.2.1. [190]Building C-Kermit on HP-UX
  3.2.2. [191]File Transfer
  3.2.3. [192]Dialing Out and UUCP Lockfiles in HP-UX
  3.2.4. [193]Notes on Specific HP-UX Releases
  3.2.5. [194]HP-UX and X.25

   REFERENCES

   For further information, read the [195]comp.sys.hp.hpux newsgroup.

   C-Kermit is included as part of the HP-UX operating system by contract
   between Hewlett Packard and Columbia University for HP-UX 10.00 and
   later. Each level of HP-UX includes a freshly built C-Kermit binary in
   /bin/kermit, which should work correctly. Binaries built for regular
   HP-UX may be used on Trusted HP-UX and vice-versa, except for use as
   IKSD because of the different authentication methods.

   Note that HP does not update C-Kermit versions for any but its most
   current HP-UX release. So, for example, HP-UX 10.20 has C-Kermit 6.0;
   11.00 has C-Kermit 7.0, and 11.22 has 8.0. Of course, as with all
   software, older Kermit versions have bugs (such as buffer overflow
   vulnerabilities) that are fixed in later versions. From time to time,
   HP discovers one of these (long-ago fixed) bugs and issues a security
   alert for the older OS's, recommending some draconian measure to avoid
   the problem. The true fix in each situation is to install the current
   release of C-Kermit.

  3.2.0. Common Problems

   [ [196]Top ] [ [197]Contents ] [ [198]Section Contents ] [ [199]Next ]

   Some HP workstations have a BREAK/RESET key. If you hit this key while
   C-Kermit is running, it might kill or suspend the C-Kermit process.
   C-Kermit arms itself against these signals, but evidently the
   BREAK/RESET key is -- at least in some circumstances, on certain HP-UX
   versions -- too powerful to be caught. (Some report that the first
   BREAK/RESET shows up as SIGINT and is caught by C-Kermit's former
   SIGINT handler even when SIGINT is currently set to SIG_IGN; the
   second kills Kermit; other reports suggest the first BREAK/RESET sends
   a SIGTSTP (suspend signal) to Kermit, which it catches and suspends
   itself. You can tell C-Kermit to ignore suspend signals with SET
   SUSPEND OFF. You can tell C-Kermit to ignore SIGINT with SET COMMAND
   INTERRUPTION OFF. It is not known whether these commands also grant
   immunity to the BREAK/RESET key (one report states that with SET
   SUSPEND OFF, the BREAK/RESET key is ignored the first four times, but
   kills Kermit the 5th time). In any case:

    1. If this key is mapped to SIGINT or SIGTSTP, C-Kermit catches or
       ignores it, depending on which mode (CONNECT, command, etc) Kermit
       is in.
    2. If it causes HP-UX to kill C-Kermit, there is nothing C-Kermit can
       do to prevent it.

   When HP-UX is on the remote end of the connection, it is essential
   that HP-UX C-Kermit be configured for Xon/Xoff flow control (this is
   the default, but in case you change it and then experience
   file-transfer failures, this is a likely reason).
    ________________________________________________________________________

  3.2.1. Building C-Kermit on HP-UX

   [ [200]Top ] [ [201]Contents ] [ [202]Section Contents ] [ [203]Next ]
   [ [204]Previous ]

     This section applies mainly to old (pre-10.20) HP-UX version on
     old, slow, and/or memory-constrained hardware.

   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. In versions 7.0 and 8.0 the problem has
   spread to other modules.

   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. This problem is handled by compiling
   the modules that tickle it without optimization; the new C-Kermit
   makefile takes care of this, and shows how to do it in case the same
   thing begins happening with other modules.

   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.

   The optimizing compiler might complain about "some optimizations
   skipped" on certain modules, due to lack of space available to the
   optimizer. You can increase the space (the incantation depends on the
   particular compiler version -- see the [205]makefile), but doing so
   tends to make the compilations take a much longer time. For example,
   the "hpux0100o+" makefile target 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 :-)

   In the makefile, all HP-UX entries automatically skip optimization of
   problematic modules.
    ________________________________________________________________________

  3.2.2. File Transfer

   [ [206]Top ] [ [207]Contents ] [ [208]Section Contents ] [ [209]Next ]
   [ [210]Previous ]

   Telnet connections into HP-UX versions up to and including 11.11 (and
   possibly 11.20) tend not to lend themselves to file transfer due to
   limitations, restrictions, and/or bugs in the HP-UX Telnet server
   and/or pseudoterminal (pty) driver.

   In C-Kermit 6.0 (1996) an unexpected slowness was noted when
   transferring files over local Ethernet connections when an HP-UX
   system (9.05 or 10.00) was on the remote end. The following experiment
   was conducted to determine the cause. C-Kermit 6.0 was used; the
   situation is slightly better using C-Kermit 7.0's streaming feature
   and HP-UX 10.20 on the far end.

   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, packet length 4096,
   parity none, control prefixing "cautious", using only local disks on
   each machine -- no NFS. In the C-Kermit 6.0 (ACK/NAK) case, the window
   size was 20; in the streaming case there is no window size (i.e. it is
   infinite). The test file was C-Kermit executable, transferred in
   binary mode. Conditions were relatively poor: the Sun and the local
   net heavily loaded; the HP system is old, slow, and
   memory-constrained.

                   C-Kermit 6.0...    C-Kermit 7.0...
 Local    Remote   ACK/NAK........    Streaming......
 Client   Server   Send    Receive    Send    Receive
  Sun      HP       36       18        64       18
  HP       HP       25       15        37       16
  HP       Sun      77       83       118       92
  Sun      Sun      60       60       153      158

   So whenever HP is the remote we have poor 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 little effect.
     * Telling the client to make a binary-mode connection (SET TELNET
       BINARY REQUESTED, which successfully negotiates a binary
       connection) has no effect on throughput.

   BUT... If I start HP-UX C-Kermit as a TCP service:

  set host * 3000
  server

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

                   C-Kermit 6.0...    C-Kermit 7.0...
 Local    Remote   ACK/NAK........    Streaming......
 Client   Server   Send    Receive    Send    Receive
  Sun      HP       77       67       106      139
  HP       HP       50       50        64       62
  HP       Sun      57       85       155      105
  Sun      Sun      57       50       321      314

   Therefore the HP-UX telnet server or pty driver seems to be adding
   more overhead than the SunOS one, and most others. When going through
   this type of connection (a remote telnet server) there is little
   Kermit can do improve matters, since the telnet server and pty driver
   are between the two Kermits, and neither Kermit program can have any
   influence over them (except putting the Telnet connection in binary
   mode, but that doesn't help).

   (The numbers for the HP-HP transfers are lower than the others since
   both Kermit processes are running on the same slow 33MHz CPU.)

   Matters seem to have deteriorated in HP-UX 11. Now file transfers over
   Telnet connections fail completely, rather than just being slow. In
   the following trial, a Telnet connection was made from Kermit 95 to
   HP-UX 11.11 on an HP-9000/785/B2000 over local 10Mbps Ethernet running
   C-Kermit 8.00 in server mode (under the HP-UX Telnet server):

                   Text........    Binary......
  Stream  Pktlen   GET     SEND    GET     SEND
    On     4000    Fail    Fail    Fail    Fail
    Off    4000    Fail    Fail    Fail    Fail
    Off    2000    OK      Fail    OK      Fail
    On     2000    OK      Fail    OK      Fail
    On     3000    Fail    Fail    Fail    Fail
    On     2500    Fail    Fail    Fail    Fail
    On     2047    OK      Fail    OK      Fail
    On     2045    OK      Fail    OK      Fail
    Off     500    OK      OK      OK      OK
    On      500    OK      Fail    OK      Fail
    On      240    OK      Fail    OK      Fail

   As you can see, downloads are problematic unless the receiver's Kermit
   packet length is 2045 or less, but uploads work only with streaming
   disabled and the packet length restricted to 500. To force file
   transfers to work on this connection, the desktop Kermit must be told
   to:

  set streaming off
  set receive packet-length 2000
  set send packet-length 500

   However, if a connection is made between the same two programs on the
   same two computers over the same network, but this time a direct
   socket-to-socket connection bypassing the HP-UX Telnet server and pty
   driver (tell HP-UX C-Kermit to "set host /server * 3000 /raw"; tell
   desktop client program to "set host blah 3000 /raw"), everything works
   perfectly with the default Kermit settings (streaming, 4K packets,
   liberal control-character unprefixing, 8-bit transparency, etc):

                   Text........    Binary......
  Stream  Pktlen   GET     SEND    GET     SEND
    On     4000    OK      OK      OK      OK

   And in this case, transfer rates were approximately 900,000 cps. To
   verify that the behavior reported here is not caused by the new Kermit
   release, the same experiment was performed on a Telnet connection from
   the same PC over the same network to the old 715/33 running HP-UX
   10.20 and C-Kermit 8.00. Text and binary uploads and downloads worked
   perfectly (albeit slowly) with all the default settings -- streaming,
   4K packets, etc.
    ________________________________________________________________________

  3.2.3. Dialing Out and UUCP Lockfiles in HP-UX

   [ [211]Top ] [ [212]Contents ] [ [213]Section Contents ] [ [214]Next ]
   [ [215]Previous ]

   HP workstations do not come with dialout devices configured; you have
   to do it yourself (as root). First look in /dev to see what's there;
   for example in HP-UX 10.00 or later:

  ls -l /dev/cua*
  ls -l /dev/tty*