OS/2 Shareware BBS: 3 Comm/03-Comm.zip/CK5A188.ZIP/ckoker.bwr

Text File | 1993-01-25 | 16KB | 374 lines

CKOKER.BWR          "Beware File" for C-Kermit Version 5A        -*- text -*-

                 OS/2 VERSION

Applies to version 5A(188)

Last update: Tue Jan 19 15:45:46 1993

Authors: Frank da Cruz, Christine M. Gianone, Columbia University.

  Copyright (C) 1985, 1992, Trustees of Columbia University in the City of New
  York.  Permission is granted to any individual or institution to use this
  software as long as it is not sold for profit.  This copyright notice must be
  retained.  This software may not be included in commercial products without
  written permission of Columbia University.

Report problems, suggestions, fixes, etc, to Frank da Cruz:

  Internet: [e-mail]  (or)  [e-mail]
  BITNET/EARN: FDCCU@CUVMA

Columbia University Center for Computing Activities
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.  Digital
Press ISBN: 1-55558-108-0; Prentice-Hall ISBN: 0-13-037490-3.  Price: US
$34.95.  In USA, call DECdirect at 1-800-344-4825, refer to order number
EY-J896E-DP.  Available: January 1993.


THE 16-BIT AND 32-BIT VERSIONS

OS/2 C-Kermit can be built in a 16-bit version, which works under both OS/2
1.x and 2.0, and in a 32-bit version, which works only under OS/2 2.0 and
later.  The SHOW FEATURES command tells you which version you have.

The 16-bit version might run out of stack space and crash under certain
conditions (the OS/2 message will be "Stack Overflow").  This is a limitation
of the Microsoft C 6.00 development system it was built with, and of the
underlying 16-bit architecture.

The 32-bit version does not (should not) crash, but it can't be used under
OS/2 1.x.  So use the 32-bit version under OS/2 2.00 and later.


GENERAL LIMITATIONS AND PROBLEMS

C-Kermit's performance -- and the performance of any other OS/2 communication
software program -- can be improved significantly by using a 16550 or 16550A
communications port controller (UART) rather than a 8650, 16450, 164C50, or
other unbuffered UART.  Unbuffered UARTs interrupt the CPU once per character,
whereas a buffered UART interrupts only once per 8-14 characters.
Measurements performed during C-Kermit file transfer on an otherwise unloaded
i486/33 processor under OS/2 2.0 show approximately 60% CPU usage with a
buffered UART and 75%-100% using an unbuffered one.  And of course, as with
all other OS/2 applications (and OS/2 itself), a faster CPU and more memory
also help.

The public-domain serial communications driver, SIO.SYS, a replacement for
COM.SYS, is supposed to speed up operation of DOS communication programs under
OS/2 (it is not supposed to speed up native OS/2 communication programs like
C-Kermit).  Prior to 14 Jan 93, C-Kermit would not work with SIO.SYS.  On 14
Jan 93, a patch was installed to CKOTIO.C to work around this problem.  You
can tell if you have this patch installed by issuing the SHOW VERSIONS
command: the line "OS/2 Communications I/O" should indicate version 5A(102)
or later, with a date of 14 Jan 93 or later.

If you refer to a disk drive that is not ready, or to a file on such a disk
drive, the OS/2 critical error handler might pop up and require action from
the keyboard.  This occurs during execution of commands by inferior processes,
such as DIRECTORY, REMOTE DIRECTORY, DELETE, REMOTE DELETE, etc.  It does not
occur in file transfer operations (e.g. "get a:oofa.txt", when sent to an OS/2
C-Kermit server that does not have a diskette in drive A, will not cause this
problem).  The "hard error box" will put a halt to unattended, scripted
operations, and it also stops the operation of the OS/2 C-Kermit server if
there is no human in attendance.  To work around: add the line "AUTOFAIL=YES"
to CONFIG.SYS.  This eliminates the hard error box, but it applies
system-wide, not just to C-Kermit.

The free disk space reported by the SPACE command, and by the OS/2 C-Kermit
server in response to a REMOTE SPACE command, is somewhat smaller than the
free space reported by the OS/2 directory command, because Kermit's report
is based on K bytes.

Certain commands that rely on underlying CMD.EXE services, including DELETE
and TYPE, do not accept full pathnames (or, at least they do not pass them
correctly to CMD.EXE).

If the PUSH command, and related commands, do not work for you, check the
definition of your OS/2 COMSPEC environment variable.

There is no way to change the OS/2 code page after you have started Kermit.
RUN CHCP doesn't do it because it only affects the CMD.EXE process below,
which, of course, exits immediately after running CHCP.

Reportedly (by some, but denied by others), if you make your window longer
than 25 lines, scrolling can interfere with the screen colors during terminal
emulation.

Printer support.  The good news:

 . The PRINT command works.
 . Files can be transferred to PRN in the 32-bit version only.
 . LOG SESSION PRN works in the 32-bit version.
 . The Print-Screen key prints the current terminal emulation screen in the
   32-bit version (not tested in the 16-bit version).
 . Host-initiated transparent print operations work correctly in the 32-bit
   version.

The bad news:

 . There is no Print item in the C-Kermit window menu because C-Kermit
   is a character-mode (VIO), rather than Presentation Manager (PM),
   application.
 . Ctrl-Print-Screen has no effect.
 . Host-initiated print operations are presently ignored by the 16-bit
   version (because if they are not ignored, they cause a stack overflow).
 . The following host-initiated print operations are not supported:
   - ESC [ 0 i    (print current screen)
   - ESC [ 1 i    (print current line)
   - ESC [ ? 5 i  (autoprint is treated like transparent print)
 . Print operations, when attempted on an OS/2 system that has no printer
   installed, can hang the Kermit program.

Wish list:

 . Make screen rollback instantaneous, as in MS-DOS Kermit.
 . Add TCP/IP, LAN Manager, and other network support.
 . 132-column mode for VT102 emulator, using horizontal scrolling if
   graphics adapter does not support 132 columns.
 . VT-320 emulation
 . Tektronix emulation


COMMUNICATIONS AND DIALING

Unless you have a very fast machine (say, 25 MHz or higher), OS/2 and its
serial port drivers are not fast enough to keep up with serial input at 19200
bps unless you have configured your connection for the optimum type of flow
control, preferably RTS/CTS.  Symptoms of lost data include fractured terminal
screens during CONNECT and packet retransmissions during file transfer.

SET LINE and SET PORT are synonyms, they do exactly the same thing: select the
communication device.  The syntax is the same for both:

  SET LINE [ <device-name> ]
  SET PORT [ <device-name> ]

If you omit the device name, C-Kermit reverts to its default communications
device, which is normally COM1.

If you include a device name, these commands work as follows:

 1. If the device name is a single digit, 1 through 8, C-Kermit converts
    this digit to the corresponding COM port name, COM1 through COM8.
    For example, "set port 2" is converted to "set port com2".

 2. If the device name begins with an underscore character (_), and all of
    the following characters are numeric (for example, _12), the number is
    assumed to be a file descriptor for an already-open communication device
    (more about this below).  If the device name begins with an underscore,
    but any non-numeric characters follow, a syntax error results.

 3. Any other sequence of characters (including "COM1", etc) is accepted
    literally as a device name.

In cases (1) and (3), C-Kermit attempts to open the device, and then, if
successful, checks to see whether it is a real communications device.  If not,
the SET LINE / SET PORT command fails.  In case (3) (see below), no checking
is done.  NOTE: You can also pass an open file descriptor to C-Kermit on
the command line, e.g. "ckermit -l 4".  See the sample program at the end of
this file.

Unless you use the MODE command to change it, the OS/2 communication port
device driver requires DSR and CTS from the modem.  If your modem or
communication device does not provide these signals, you can enable
communication by telling the communication port driver not to require them,
before starting C-Kermit (or in your CKERMIT.CMD file).  For example:

  MODE COM2 IDSR=OFF,ODSR=OFF,OCTS=OFF

On some machines, C-Kermit may appear to work even though DSR and CTS are
not connected to anything, nor disabled using MODE.  This is because
unconnected input lines tend to "float high".  Although this situation may not
cause any problems, for safety's sake you should still disable these signals,
if they are not legitimate, with the MODE command

If you have problems using COM3, COM4, or higher, it is likely that the OS/2
communications manager, through which C-Kermit accesses all serial devices,
does not know the address or interrupt number of your communication port.  You
can specify this information in your OS/2 CONFIG.SYS file, in the line that
starts the serial communication driver, COM.SYS:

  DEVICE=C:\OS2\COM.SYS (number,base-address,irq) ...

Here is an example that specifies the addresses and IRQs for COM3 and COM4,
and leaves the default values for COM1 and COM2 alone:

  DEVICE=C:\OS2\COM.SYS (3,3E8,10) (4,2E8,15)

and here is an example that specifies these values for COM1 through COM4:

  DEVICE=C:\OS2\COM.SYS (1,3F8,4) (2,2F8,3) (3,3E8,10) (4,2E8,15)

Warning: the addresses and IRQs for COM3 and COM4 are not standardized, and
can vary depending on the design and configuration of your communication
board.  Consult the documentation that came with your communication board.


TERMINAL EMULATION

SET DEBUG SESSION is currently not supported.

Various VT102 terminal features are not supported, including:

 . Blink
 . Smooth scroll
 . Switching between 80- and 132-column mode

and others are simulated:

 . Double-width and double-height lines
 . Underlining

Scrolling is slow in an OS/2 Window.  This is because OS/2 is operating in
graphics mode and must draw each dot (pixel) individually.  (Reportedly, IBM
will be improving the speed in a forthcoming update of the screen manager --
the new "graphics engine" that will be part of OS/2 2.00.1.)  Scrolling is
fast if you run C-Kermit fullscreen, which uses character mode rather than
graphics mode.  But when running C-Kermit fullscreen you lose the ability to
cut and paste.

The cursor disappears briefly while the screen is being updated and appears
again within a few milliseconds after screen activity stops.  This can be
somewhat disconcerting, but increases the speed of screen updates.

SET FLOW XON/XOFF prevents you from transmitting Ctrl-S and Ctrl-Q characters
to the host.  These characters are commands (Search and Quote) in EMACS.

If the host sends the escape sequence to put the terminal into 132-column
mode, and subsequently sends data that would appear in the rightmost 52
columns, this may interfere with existing data on the screen.  If C-Kermit is
started in an OS/2 132-column fullscreen session under OS/2 2.0 (only possible
on certain video adapters), it will display such data correctly but will
always be in 132-column mode, even if only 80-column mode is used.

Key scan codes are not all the same as in MS-DOS Kermit.  Most ordinary keys
have the same codes, but not as many keys are differentiated.  For example,
all combinations of Ctrl, Shift, and Alt with a particular key do not
necessarily produce different scan codes.  Also, there are no \Kverbs as in
MS-DOS Kermit.

Shift-in/Shift-Out works only if you SET TERMINAL LOCKING-SHIFT ON.

There is presently no way to disable the answerback sequence ("OS/2 C-Kermit").

See the file CKOVTK.INI as a sample key mapping file for mapping the PC 101
and 102 numeric keypad to VT102 functions.

SET KEY works with the Num Lock key, but several cautions are necessary:

1. Num Lock has two different scan codes: \510 and \766.
2. Every time you push Num Lock, the scan code toggles.
3. Every time you push Num Lock, the keypad state toggles.

Assigning characters to Num Lock with SET KEY does not change this behavior.


FILE TRANSFER

There is no way send the complete contents of a file in text mode if the file
contains a Ctrl-Z character that is not the last character in the file.  In
other words, Ctrl-Z is always treated as end-of-file when the FILE TYPE is set
to TEXT.  There should be a SET EOF {CTRLZ, NOCTRLZ} command as in MS-DOS
Kermit to control the treatment of Ctrl-Z characters in text files.

Be sure to activate the appropriate type of flow control before transferring
files, especially if you are using long packets:

  SET FLOW RTS/CTS
    Preferred, if the device your PC is immediately connected to supports it.

  SET FLOW XON/XOFF
    Used end-to-end, but subject to noise corruption, propogation delays, etc.

By default OS/2 C-Kermit uses whatever flow control is already configured
for the communications port driver at the time you started C-Kermit.


HINTS and TIPS:  INVOKING C-KERMIT FROM ANOTHER PROGRAM

If you are writing a communications program and wish to incorporate the Kermit
protocol within it, one way is to use the OS/2 function call DosExecPgm to
call up C-Kermit.  You would supply the instructions for Kermit using
command-line options, and Kermit would do the transfer, returning back to your
program when it had finished.

The only problem with this scenario is that you might already have opened up
the COM port within your program, so that when Kermit tries to do the same it
gets an error code back from DosOpen.  The -l command line option gets round
this problem.  It uses the fact that a child process inherits the open file
handles of its parent.  -l takes one numeric parameter which is the handle of
the COM port in question, and it must occur in front of any other command-line
parameter which accesses the COM port.  The following is a complete C program
written using the Microsoft C compiler version 5.1 and the Microsoft OS/2
Software Development Toolkit, which illustrates how to use the -l command-line
option.

#define    INCL_BASE
#include <os2.h>
/*
 *    Example of how to use the C-Kermit -l option to invoke
 *    Kermit from another program under OS/2.
 */
main(int argc, char *argv[]) {
HFILE    ttyfd;
USHORT    action;
int    err,i;
char    failname[80];
char    args[80];
RESULTCODES    res;
struct dcb {            /* Device control block */
    USHORT write_timeout;
    USHORT read_timeout;
    BYTE flags1, flags2, flags3;
    BYTE error_replacement;
    BYTE break_replacement;
    BYTE xon_char;
    BYTE xoff_char;
} ttydcb;

    /*** Open a file ***/
    if (err=DosOpen(argv[1],&ttyfd,&action,0L,0,1,0x0012,0L)) {
        printf("Error %d opening %s\n",err,argv[1]);
        exit(1);
    }
    if (err=DosDevIOCtl(&ttydcb,NULL,0x0073,1,ttyfd)) {
        printf("Error %d from IOCTL on %s\n",err,argv[1]);
            exit(1);
    }
    ttydcb.flags3 &= 0xF9;
    ttydcb.flags3 |= 0x04;    /* Read "some" data from line */
    DosDevIOCtl(NULL,&ttydcb,0x0053,1,ttyfd);

    /*** Call kermit ***/
    strcpy(args,"ckermit");
    i = strlen(args);
    args[i++]=0;
    sprintf(&args[i],"-l %d -q -s test.c",ttyfd);
    i += strlen(&args[i]);
    args[i++]=0;
    args[i++]=0;
    if (err=DosExecPgm(failname,80,EXEC_SYNC,args,NULL,&res,
                            "CKERMIT.EXE")) {
        printf("Error %d executing Kermit\n",err);
        exit(1);
    }

    /*** Print out return code ***/
    printf("Termination code %d\n",res.codeTerminate);
    printf("Result code %d\n",res.codeResult);

    /*** Close the file ***/
    if (err=DosClose(ttyfd)) {
        printf("Error %d closing %s\n",err,argv[1]);
    }
}

(End of CKOKER.BWR)