ckubwr.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

    Downloads -> Software Fixes -> Download FixDist gets an application
    for looking up known problems.

Other people have reported that after upgrading AIX from 4.1 to 4.2, the "ttys
hang" when they try to use Kermit.  Again, so far no further details are
available.  However, others report that C-Kermit 6.0 works fine on both AIX
4.2 and 4.3 if it is rebuilt from source code.  Still others report that the
original C-Kermit 6.0 binaries, built under AIX 4.1, work perfectly in AIX
4.2 and 4.3.

More recently, people have reported various kinds of problems running a
C-Kermit binary built under AIX 4.1 or 4.2 on AIX 4.3.  There has been some
speculation on the newsgroups about a new round binary incompatibility between
AIX 4.3 and earlier versions -- some even suggest renumbered syscalls, but
that seems unlikely.  Example: a user in Germany reported that the C-Kermit
6.0 AIX 4.1 binary would crash during file transfer when run on AIX 4.2, but
the problems disappeared when running a binary that was built on AIX 4.2.

C-Kermit 6.0.192 and earlier were built by default without "BIGBUFOK" defined
for AIX, and this limits the maximum size of macros, etc.  In particular, it
affects the alphanumeric page macro (TAPMSG) distributed with C-Kermit 6.0.
BIGBUFOK should be defined, and it is in C-Kermit 6.1 and later.  In the
meantime use:

  make clean ; make aix???  KFLAGS=-DBIGBUFOK

Reportedly, telnet from AIX 4.1-point-something to non-Telnet ports does not
work unless the port number is in the /etc/services file; it's not clear from
the report whether this is a problem with AIX Telnet (in which case it would
not affect Kermit), or with the sockets library (in which case it would).  The
purported fix is IBM APAR IX61523.

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 a
shell-script wrapper for Kermit 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 and later.)  The commands for
turning getty off and on (respectively) are /usr/sbin/pdisable and
/usr/sbin/penable.

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).  This should not be an issue in
C-Kermit 7.0 or later, which now calls the AIX ttlock() family of library
functions to create, check, and remove lockfiles.  (But it is not known
which versions of AIX prior to 4.1 have working ttlock() functions; for
example, the functions are present in AIX 3.2 but do not seem to work).

C-Kermit SET HOST or TELNET from one AIX 3.1 (or earlier) system to another
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 seems to be
removed in AIX 3.2 and later.

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 anything 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)

About AIX versions and hardware platforms (from the AIX FAQ):

  If you are using IBM's xlc (cc) compiler, the default is to use the common
  instruction set, so the same binary will run on both RS/6000 and PowerPC.

  The option -mcpu=common makes GCC use the common instruction set.  Please
  note that (unlike xlc) this is *not* the default with GCC on AIX.

A couple of other gotcha's:

  Use shared libraries.  The C runtime can and does change as IBM introduces
  patches.  Also this avoids "Netscape syndrome."  They bound AIX 3 libraries
  into their browser.  Although AIX 3 binaries will run on AIX 4, the AIX 3
  libraries aren't totally compatible.

  AIX 4.2 changed the C runtime radically.  AIX 4.2 binaries won't run on AIX
  4.1 or 3.anything.  AIX 3 binaries run on AIX 4.1 and AIX 4.2.

Of course, the moment you take any of this as gospel,  you'll get into big
trouble, but my own experience has pretty much jibed with the above.

(end quote)

"Is AIX Year 2000 Compliant?"  According to a comp.unix.aix newsgroup posting
from IBM Austin, version 4.2 is; earlier versions such as 4.1.x and 3.2.5
require PTFs (which, as of Jan 1997, have not yet been issued).

Here is a sample configuration for setting up an xterm keyboard for VT220 or
higher terminal emulation on AIX, courtesy of Bruce Momjian, Drexel Hill, PA.
Xterm can be started like this:

xterm $XTERMFLAGS +rw +sb +ls $@ -tm 'erase ^? intr ^c' -name vt220 \
        -title vt220 -tn xterm-220 "$@" &

---------------------------------------------------------------------------
XTerm*VT100.Translations: #override \n\
	<Key>Home: string(0x1b) string("[3~") \n \
	<Key>End: string(0x1b) string("[4~") \n
vt220*VT100.Translations: #override \n\
Shift	<Key>F1: string("[23~") \n \
Shift	<Key>F2: string("[24~") \n \
Shift	<Key>F3: string("[25~") \n \
Shift 	<Key>F4: string("[26~") \n \
Shift	<Key>F5: string("~") \n \
Shift	<Key>F6: string("[31~") \n \
Shift	<Key>F7: string("[31~") \n \
Shift	<Key>F8: string("[32~") \n \
Shift	<Key>F9: string("[33~") \n \
Shift	<Key>F10: string("[34~") \n \
Shift	<Key>F11: string("[28~") \n \
Shift	<Key>F12: string("[29~") \n \
	<Key>Print: string(0x1b) string("[32~") \n\
	<Key>Cancel: string(0x1b) string("[33~") \n\
	<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

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

3.2.0. Common Problems

The following sequence:

  set line /dev/cua0p0 ; or other device
  set speed 19200      ; or other normal speed

produces the message "?Unsupported line speed".  This means the port is not
configured for dialout.  Go into SAM and configure the port for dialout.

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

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 6.1 and 7.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 makefile), but doing so tends to make the compilations take a much