It also has a few features that the Windows versions do not have: SLIP and PPP dialing, a Rexx interface, and transmission of files with full OS/2 extended attributes.
NOTE: Although Kermit 95 for OS/2 is, indeed, the OS/2 version of Kermit 95, in this file we refer to the Windows version of Kermit 95 as "Kermit 95" and to the OS/2 version as "Kermit/2" for the sake of brevity and clarity.
Kermit/2 replaces OS/2 C-Kermit 5A(191) of April 1995. It is a 32-bit program, requiring OS/2 2.0 or later. It comes with a GUI Presentation Manager Dialer (which requires OS/2 3.0 or later) to set up your connections.
IMPORTANT: Kermit/2 uses different keyboard keycodes than OS/2 C-Kermit. You will need to convert any key settings files to the new keycodes. This change was required in order to allow any and all key combinations to be mapped, and to be mapped on a per-emulation basis. OS/2 C-Kermit only allowed a relatively small number of key combinations to be mapped, and all mappings were global. The new scheme also allows MS-DOS Kermit keymaps to be imported.
Kermit/2 includes a large repertoire of terminal emulations, Kermit and XYZMODEM file transfer, a powerful cross-platform script programming language, built-in automatic translation of Roman, Cyrillic, Hebrew, and other character sets: all in a consistent package that operates uniformly over direct or dialed serial connections, TCP/IP Telnet or Rlogin connections, PATHWORKS, IBM LAN Server, or NETBIOS connections, and in a consistent way with Kermit programs for DOS, Windows, UNIX, VMS, and many other platforms.
Kermit/2 is miles ahead of the old OS/2 C-Kermit:
C-Kermit 5A(191) Kermit/2 2.1Terminal emulations: 6 40 Built-in modem types: 28 82 Graphical dialer and database: No Yes Intelligent dialing: No Yes Portable dialing directory: No Yes Integrated XYZMODEM protocol: No Yes Auto-up/download: No Yes Streaming: No Yes Host mode: No Yes Rlogin client: No Yes URL hot spots: No Yes Block structure for scripts: No Yes Authentication: No Yes Encryption: No Yes Transport Layer Security: No Yes HTTP script commands: No Yes FTP client: No Yes
And lots more, including significant improvements in just about every area.
IMPORTANT -- PLEASE READ THIS:
Eight years of full-time development have gone into Kermit 95. It is not free software; it must be licensed. The same goes for the OS/2 version; the terms for use are the same as for the Windows version.
However, in view of the declining importance of OS/2 in the marketplace, no effort has been devoted to creating OS/2-specific manuals, packaging, or hypertext INFO files. This should not detract from the utility of the software itself.
Kermit/2 is documented in the Kermit 95 and Using
C-Kermit manuals. This file documents OS/2-specific differences from the
Microsoft Windows 95 and NT releases.
The installation of these soft fonts is tricky and not guaranteed to work
on all video adapters and with all video drivers. And remember, it can only
be done in a fullscreen session -- NOT in an OS/2 Window.
Also, there is presently no LK450 support for Kermit/2.
These problems appear to be confined only to certain systems, and do not
occur on others. It is believed that they are related to the particular
video adapter or driver; the problems are most commonly reported on SVGA and
XGA systems. You can usually work around these problems in various ways:
SET TERMINAL CODE-PAGE only seems to work in fullscreen sessions. For that
matter, the same seems to be true of OS/2's own CHCP program, so this is
apparently an OS/2 limitation (noted in OS/2 2.1 GA).
SET TERMINAL CODE-PAGE (and OS/2's own CHCP program) seem to have no effect
at all when the Hebrew NLV is installed. The code page simply does not
change.
Shift-in/Shift-Out works only if you SET TERMINAL LOCKING-SHIFT ON (except
in the case of the DEC Technical Character Set, used for line- and box-
drawing, etc, which is handled specially).
Host-directed US/UK character-set switching (ASCII 35 interpreted as number
sign in US, Pound Sterling sign in UK) works only if you have SET TERM
CHARACTER-SET ASCII.
Under certain conditions on certain systems, Kermit/2 has been observed to put
the entire screen (or subsequent help screens) in blinking mode. For example,
when running in a fullscreen session, CONNECT mode active, background color is
high-intensity, and using Alt-Esc to get to the desktop, then resuming the
Kermit window can produce this effect; reportedly, this is caused by a bug in
some of OS/2's video drivers. Alt-R (reset) makes the blinking stop. To
avoid the problem altogether, don't use high-intensity background colors:
DGRAY, LBLUE, LCYAN, LGREEN, LMAGENTA, LRED, WHITE, YELLOW.
Briefly, the idea is that an OS/2 file can be transferred from one OS/2
system to another with all its extended attributes intact. It can also be
transferred to an intermediate (non-OS/2) system for archival, and later
transferred to another OS/2 system and restored to its original form. An
OS/2-specific SET FILE LABEL command is also provided for controlling how
regular OS/2 file attributes are handled in labeled file transfers:
By default, all but ARCHIVE are ON. All of a file's attributes are always
transmitted; this command tells the file receiver whether to pay attention
to them (ON) or not (OFF). Use SHOW LABELED-FILE-INFO to display the values
of these settings.
SET FILE COLLISION UPDATE has the following peculiarity: On FAT (i.e. DOS)
file systems, a file's date/time is recorded with a granularity of 2
seconds, whereas on most other kinds of file systems (UNIX, VMS, OS/2 HPFS,
etc), it is recorded to at least the exact second. Thus when Kermit/2
records the timestamp of an incoming file, the "one's place" of its time is
truncated. If it was an odd number, therefore, it will be one second
"older" than the date/time of the original file. Downloading the same file
again with SET FILE COLLISION UPDATE would result in a second, unnecessary
transfer of the file, since the remote file would appear to be newer than
the local file. Therefore, Kermit/2, when making this comparison, will treat
two times as equal if (a) the local file's time is an even number, (b) the
remote time is equal to (of course) or exactly one second greater than the
local time, and (c) the local file system is FAT.
or:
or:
which executes a REXX program from the given file. The text, if any, is
passed to the REXX program, where it is available as ARG(1).
A REXX command or program invoked via Kermit/2's REXX command can also
execute Kermit/2 commands from within REXX procedures that are invoked via
Kermit/2's REXX CALL command, by enclosing them in single quotes, for
example:
The RETURN value from the REXX command or program is available in the
Kermit/2 variable \v(rexx). Set this by including a RETURN
Q: Why would you want to use REXX from within Kermit/2?
A: Many reasons:
There are three types of functionality provided in the Kermit/2/REXX
interface:
Let's say you want to execute a one-line REXX program from within
Kermit/2. You would use the new Kermit/2 "REXX" command. The format of the
command is:
where "rexx-command" is everything after the keyword REXX to the end of the
line. A simple example:
executes the REXX command SAY with the parameter "hello", which prints the
word "hello" on your screen.
Another example, returning a value from REXX:
the REXX command "return 4 * 4" calculates the value "16" and returns it to
Kermit/2. Kermit/2 stores the return value from the last REXX command in
\v(rexx):
Let's say you want to execute a series of REXX commands, but you don't want
to create a REXX command file:
This prints the string "hello" and then returns the value "0" to
Kermit/2. Notice that \13 (Carriage Return, Ctrl-M) was placed between the
commands. This is necessary because REXX expects to find each command
separated by a return character just as if it was being read from a file.
To execute a REXX command file, use:
where "oofa.cmd" is the name of your REXX command file.
Now let's say you want to gain access to a Kermit/2 variable value from
within a REXX program, change a Kermit/2 setting, or execute a Kermit/2
command. You could alter your program so it is called in separate parts
from a Kermit/2 TAKE file or macro. But there is a better way. Just
include the Kermit/2 command in your REXX program. For example, you want to
set Kermit's parity from within your REXX program:
Let's say you want to set a REXX variable to the value of a Kermit/2
variable:
Notice the single quotes around and the "return" command before the Kermit/2
variable statement. REXX passes the quoted statement to Kermit/2 for
evaluation. Kermit/2 interprets the command and returns to REXX the value
of the parity variable. This value is then stored in the REXX special
variable RC. RC stores the return value of all non-REXX commands. The next
statement assigns the value of REXX variable RC to the REXX variable parity.
Q: What happens if you create a REXX program file that contains
Kermit/2 commands and you try to execute it outside of the
Kermit/2 environment?
A: A Syntax Error. This is because the Kermit/2 commands are only
available when Kermit/2 is executing the REXX command file.
Q: Can Kermit/2 be used with REXX programming tools such as
Watcom's VX-REXX?
A: Yes and No. Kermit/2 and VX-REXX work together too. To run a
VX-REXX program from within Kermit/2, first generate a .VRM file
and then invoke it with the Kermit/2 REXX CALL command.
However, the VX-REXX program is not allowed to make
Presentation Manager calls, because VIO applications (like Kermit/2)
can't do that.
TCP/IP support is not yet available for Novell LAN Workplace for OS/2. If a
TCP/IP package includes an IBM- or TCP/2-compatible TCPIPDLL.DLL library,
then Kermit/2 should work with it. Support for other OS/2 TCP/IP packages
will be added in future releases. These can be supplied in the form of
small DLLs that can be installed after the fact, which Kermit/2 will load
automatically if you define the environment variable CKTCPIPDLL to indicate
the pathname.
When TELNET'ing into an OS/2 system, you should set your terminal type to
ANSI. This is particularly important if you are going to use Kermit/2 or
TELNET on OS/2 system to establish a second connection out from the PC that
you have TELNET'ed into.
Users of IP-Switch Vantage IP may notice a brief TRANSMISSION BLOCKED
message after typing the first character upon entering terminal mode. The
blocked transmission does not result in any data loss or performance
degradation as it only occurs only on the first typed character.
Q: Why use Kermit on a TCP/IP connection rather than TELNET and FTP?
A: Many reasons: Unlike TELNET, Kermit/2 can also transfer files.
Kermit/2 has a script programming language, a powerful key mapping
facility, screen rollback, color selection, and many other amenities
lacking in most TELNET programs. It also has a unique ability to
translate character sets, both during terminal emulation and file
transfer. Many services are coming on the Internet which do not provide
FTP, but do provide Kermit file transfer.
Q: Why is Kermit file transfer over a TCP/IP connection slower than FTP?
A: Because the Kermit program on the remote end of the connection is
probably not running directly on a TCP socket, but rather running
underneath a TELNET server, usually on a pseudoterminal and under a
login shell, with the vast amounts of per-character overhead all of that
implies. Also Kermit does more than FTP, especially when transferring
in text mode. Still, you can get reasonably fast transfer rates by using
large window sizes, long packets, and control-character unprefix (but
remember not to unprefix character 255!).
Kermit/2 has been tested with the following products:
To have a named pipe connection connection between two Kermit programs, one
Kermit program must be the "server" and the other must be the "client". The
server is the one that is started first, and which waits for a connection to
come in from the client. The server is started this way:
If the pipename is omitted from the SET NETWORK NAMED-PIPE command, a
pipename of "kermit" is used. "SET HOST *" means to wait for a connection
to come in from another Kermit program.
Then the client makes a connection to the server:
where pipename is the pipename used by the server you want to communicate
with (default "kermit"), and servername is the name of the server on the
network. If you specify a servername of "." (period), this means your own
computer; you can set up such local connections even if you don't have Named
Pipes network support installed, e.g. between two copies of Kermit/2
running in different windows.
Both pipename and servername are case-independent, and can contain spaces.
There is no particular restriction on what Kermit commands can be used on a
named-pipe connection. Here are some useful scenarios:
To close a named-pipe connection, give the HANGUP command (or the SET HOST
command, specifying no hostname) to either the client or the server.
The Kermit/2 named-pipe server can also wait for a client to connect. After
the client disconnects, the connection will be reset to await the next
client. This allows for the use of kermit "server" as a pseudo-FTP site for
those without IBM TCP/IP.
Note: When using Named Pipes with LAN Server or LAN Manager, only the
machine which has the Network Server software is capable of successfully
using the SET HOST * command. This is because the client network requesters
do not implement the server side of the named-pipe network redirection.
Novell NetWare Requester for OS/2, on the other hand, implements both the
named-pipes client and server code on the client workstation and does not
require the existence of a Network server to operate.
To have a NETBIOS connection connection between two Kermit programs, one
Kermit program must the "server" and the other must be the "client". The
server is the one that is started first, and which waits for a connection to
come in from the client. The server is started this way:
If the localname is omitted from the SET NETWORK NETBIOS command, then if a
HOSTNAME environment variable is defined, that is used; otherwise if a
SYSTEMNAME environment variable is defined, that is used; otherwise "kermit"
is used (the HOSTNAME variable is created by TCP/IP installation, SYSTEMNAME
by DECnet PATHWORKS installation; if you don't have TCP/IP or PATHWORKS
installed, you can add a "SET HOSTNAME=blah" or "SET SYSTEMNAME=blah"
statement to your CONFIG.SYS file). The localname must be unique on the
NETBIOS network; if not, the SET NETWORK command will fail.
"SET HOST *" means to wait for a connection to come in from another Kermit
program.
Then the client makes a connection to the server:
where localname is the new name used to identify the client Kermit session,
and servername is the localname of the server's Kermit session.
The localname and servername are case-dependent, and can contain spaces.
There is no particular restriction on what Kermit commands can be used on a
NETBIOS connection. Here are some useful scenarios:
Unlike with TCP/IP connections, the Kermit/2 NETBIOS server can wait for a
client to connect. After the client disconnects, the connection will be
reset to await the next client. This allows for the use of kermit "server"
as a pseudo-FTP site for those without IBM TCP/IP.
NETBIOS is the preferred protcol to use when transfering files with MS-DOS
Kermit or Kermit/2 for OS/2 in a peer-to-peer local area network. NETBIOS
is supported over most networking protocols including: Netbeui, IPX, IP, and
LU6.2. In addition, it has lower overhead than all other OS/2 implemented
networking protocols.
Each Kermit/2 session requires the following resources from the NETBIOS
provider: 1 Name, 32 Commands, and 1 session. For example, if you wish to
have three Kermit/2 sessions running simultaneously in Server mode, NETBIOS
must be configured to support at least 3 Names, 96 Commands, and 3 sessions.
If the number of available NETBIOS commands is unavailable, NETBIOS support
for the current Kermit/2 session will not be installed.
The default settings for IBM and Netware NETBIOS implementations are:
The maximum settings for IBM and Netware NETBIOS implementations are:
The method for modifying NETBIOS resources depends on the NETBIOS product;
it is normally done by executing the configuration program (LAPS, INSTALL,
...) or by manually modifying the configuration files and restarting OS/2.
It is possible to have two or more products each providing NETBIOS services
by running multiple NETBIOS protocol stacks. All products which use LAPS
may be mixed together. And LAPS may be mixed with up to one product which
uses the NETAPI.DLL product. However, there are limitations. In
particular, you can not successfully run Novell NETBIOS support with IBM
Extended Services.
The most common dual stack combination is of IBM Netbeui (LAPS) and Novell
IPXNB (NetWare Requester). The installation procedure for each package is
completely ignorant of the other protocol. The dual stack requires that the
configuration files be manually modified with a text editor (e.g. E.EXE).
The NETBIOS configuration is defined by statements in two files: NET.CFG and
PROTOCOL.INI. These files contains statements defining how many NETBIOS
Names, Commands, and Sessions are available to each protocol stack. The
settings for each protocol stack must be consistent between the two files.
For both protocols to coexist the following section to the must be added to
the end of the PROTOCOL.INI file:
where:
Without this additional section in PROTOCOL.INI, only IBM Netbeui will be
available to Kermit/2. This section defines up to 4 virtual adapters (0-3),
each of which is assigned a specific NETBIOS protocol stack implementation.
Kermit/2 allows you to choose which NETBIOS implementation you want to use
by using the '-N' (note uppercase) command-line option. To use the driver
assigned to ADAPTER1 in the [NETBIOS] section of PROTOCOL.INI use:
The syntax of the option is:
where adapter is one of the virtual adapter numbers (default = 0).
It is important to know which NETBIOS protocol stack you are using as both
machines must be using the same stack type for them to successfully
communicate.
The following provide examples of valid [NETBIOS] sections in PROTOCOL.INI.
Example 1: Both IBM and Novell NETBIOS implementations and one physical
adapter. Novell NETBIOS is the default.
Example 2: Both IBM and Novell NETBIOS implementations and one physical
adapter. IBM NETBIOS is the default.
Example 3: Only Novell NETBIOS implementation and one physical adapter.
Example 4: Both IBM and Novell NETBIOS implementations and two physical
adapters. IBM NETBIOS is the default. (Novell NETBIOS cannot be assigned
to two physical adapters.)
and then use all of Kermit's communication features - terminal emulation,
file transfer, etc - in the same way you would on a serial or TCP/IP
connection.
If you experience difficulties transferring files that contain 8-bit data,
use SET PARITY SPACE and/or use shorter packets. Reportedly, some character
loss will occur in the underlying PATHWORKS transport, and sometimes even
random disconnections; hopefully, this will be fixed in PATHWORKS 5.0.
Because backslash (\) is a special command character, use one of the
following forms at the Kermit/2 prompt or in a command file or macro:
or:
or:
Once the SLIP/PPP driver has begun execution, run Kermit/2 and select port
SLIPCOMx or PPPCOMx as your serial port, where x is the serial port in use
for the SLIP/PPP connection. Kermit/2 will obtain access to the port from
the SLIP/PPP driver and you may then use the port as necessary to log into
your SLIP/PPP server and start a SLIP/PPP session. All of Kermit/2's
features and capabilities are available for use over the serial line while
Kermit/2 has control of the serial port. Upon exiting Kermit/2 or issuing
SET PORT 0, the port is returned to the SLIP/PPP driver which will once
again control the port, handling all SLIP/PPP traffic.
Note that Kermit/2 should not be used as part of an attachment script, which
is started by the SLIP/PPP driver itself, but should be run as a separate
command after the SLIP/PPP driver is started. Should scripting be required,
you can use Kermit scripts (including the OS/2 Kermit/2 REXX support as
necessary) to perform the same tasks as an attachment script.
SLIPWAIT or PPPWAIT may be executed from a Kermit script to synchronize the
operation of Kermit/2 and the SLIP/PPP driver.
Kermit/2 shares the same SOCKS environment variables as IBM Gopher. It also
supports the use of local SOCKS configuration files.
To specify the default SOCKS Server, add SET SOCKS_SERVER=
If you must use a SOCKS Distributed Name Server, add SET SOCKS_NS=
If you must use a specific
The SOCKS configuration file must be placed in the directory pointed to by
the ETC environment variable as declared in your CONFIG.SYS file. The name
should be SOCKS.CONF. On a FAT file system, use SOCKS.CNF.
The format of the lines in the SOCKS configuration file are as follows:
op must be one of 'eq', 'neq', 'lt', 'gt', 'le', or 'ge'. dst_addr,
dst_mask, and port may be either numeric or name equivalents.
Kermit/2 ignores the [*=userlist] and [@=serverlist] fields. Matches are
determined on a first match not a best match basis. Addresses for which no
match is found default to "sockd".
For completeness: Fields in square brackets are optional. The optional
@=serverlist field with a 'sockd' line specifies the list of SOCKS servers
the client should try (in the given order) instead of the default SOCKS
server. If the @=serverlist part is omitted, then the default SOCKS server
is used. Commas are used in the userlist and serverlist as separators, no
white spaces are allowed.
will try to make a DECnet (PATHWORKS) LAT connection to DECnet node
OOFA. However, please be aware that a SET NETWORK command will fail if the
given type of network is not installed, or if (in the case of NETBIOS) the
given name is already in use. Thus a safer construction would be:
The default network type (which is used if give a SET HOST command without
first giving a SET NETWORK command) depends on which network products you
have installed on your OS/2 system, chosen in this order of preference:
NETBIOS cannot be a default choice because it requires a user-assigned name.
On a TCP/IP TELNET connection, you should normally have PARITY set to NONE
and FLOW-CONTROL also set to NONE. If file transfer does not work with
these settings (for example, because the remote TELNET server only gives a
7-bit data path), use SET PARITY SPACE. Do not use SET PARITY MARK, EVEN,
or ODD on a TELNET connection - it interferes with TELNET protocol.
TELNET sessions are treated just like serial communications sessions as far
as "terminal bytesize" and "command bytesize" are concerned. If you need to
view and/or enter 8-bit characters during a TELNET session, you must tell
Kermit/2 to SET TERMINAL BYTESIZE 8, SET COMMAND BYTESIZE 8, and SET PARITY
NONE.
If you SET TERMINAL DEBUG ON or SET DEBUG SESSION (same thing), TELNET
protocol negotiations will be displayed on your screen. But most of the
interesting negotiations happen at the time the SET HOST or TELNET command
is given, before CONNECT mode is entered, so you won't see them on your
screen. However, you can still capture them in the debug log ("log debug").
If you are using the RLOGIN command and are unable to make a connection,
check the SERVICES file located in the directory assigned to the ETC
environment variable. Check to make sure that the first instance of "login"
is on port number 513. Many systems are now listing "login" on port 49
which is incorrect. Comment out or remove the extraneous entries if
necessary.
If your OS/2 system is running IBM TCP/IP TELNETD.EXE, it is also possible to
TELNET to your OS/2 system to have a CMD session, in which you can run only
character-mode commands and applications.
IBM's TELNET server provides limited functionality for emulating an OS/2 full
screen session on a VT100 or ANSI Telnet terminal. Due to the limitations of
the ASCII character set not all keyboard keystrokes may be replicated across
the Telnet session. The OS/2 VIO programming interface used in the design of
text applications does not map well to character based terminal devices.
Therefore you will notice slow performance. The optimal terminal emulation to
use from your terminal emulator is ANSI. You can use Kermit/2's SET TERMINAL
TYPE ANSI command, or its SET TELNET TERMINAL-TYPE ANSI command.
If you run a PM application (such as "help") while TELNETed to your OS/2
system, your session will hang because control will have been transferred to
the real keyboard, mouse, and screen. Similarly, if you manage to invoke
the OS/2 critical error handler during a character-mode application (for
example, "dir a:" when there is no diskette in the A: drive). To avoid this
place AUTOFAIL=YES into your CONFIG.SYS file.
You can run Kermit/2 in a remote TCP/IP session and tell Kermit/2 to SET
LINE to a serial device and call up a third computer. Thus Kermit/2 can be
used as a modem server in the TCP/IP environment.
However, at present you cannot transfer files between your local Kermit
program and Kermit/2 when TELNET'd to OS/2 due to restrictions in the OS/2
TELNET server.
It is also possible to get an OS/2 CMD session on a serial connection when
dialing into your OS/2 system if you are running a product such as OS2YOU,
but Kermit/2 file transfer does not yet work in this environment either.
The Telnet server in recent versions of OS/2 (probably starting with Warp 4)
evidently does character-set translation from CP850 to Latin1, which can
interfere with the K95 Telnet client's screen formatting, especially if you
are trying to use the ANSI terminal type. Cure: Start OS/2 telnetd with the
"-cp none" parameter. Then "set term type ansi" in Kermit 95 should work as
expected. But note that function keys are not supported since they are not
part of ANSI emulation, and in any case there is no provision for them in IBM
telnetd. Ditto for Alt keys, the gray keypads, etc.
Kermit/2 and MS-DOS Kermit are well designed for this task. The SET FILE
COLLISION UPDATE command may be used to instruct Kermit/2 to only transfer
files that are new or have changed.
The SEND /RECURSIVE command allows entire directory trees to be sent from one
system to another.
In addition, Kermit/2's SET FILE TYPE LABELED and SET FILE LABEL {ARCHIVE,
EXTENDED, HIDDEN, READ-ONLY, and SYSTEM} commands can be used to specify
which file attributes including extended attributes should be transfered.
This is particularly useful when backing up changes to an OS/2 desktop from
one system to another.
With the use of a Parallel Port NDIS driver, Kermit/2 can use its network
support to take advantage of high speed parallel port connections. (Savant
Software, Inc., sells parallel port drivers for OS/2 and DOS:
floyd@savant.com, or P.O. Box 201015, Austin, TX 78720-1015.) Just add
either the TCP/IP or NETBIOS protocol stacks to the Parallel Port MAC in IBM
LAPS or IBM MPTS. Then tell Kermit/2 to SET NETWORK TCP/IP or NETBIOS
depending on which you want to use. Standard Lap-Link cables are supported.
Kermit/2 ships with a utility program, "k2clip.exe". This PM Application
when active acts as an agent for all active Kermit/2 sessions enabling
Kermit/2 to copy and paste text data to and from the clipboard with full
compatibility with other OS/2 PM applications (eg. TWCP and ManyClip). Now
the \KPaste kverb can paste text data copied to the clipboard from all PM
and Win-OS2 applications and the \KMarkCopyClip kverb will paste text into a
ManyClip Clipboard.
It is recommended that users place a shadow of the Kermit/2 PM Clipboard
Server program object into their Startup folder (located within the OS/2
System folder.) By doing this a single copy of the Server will be started
each time OS/2 is loaded. When not in use, the server uses zero CPU time
and its memory will be paged to the swapfile.
When navigating the World Wide Web using IBM WebExplorer you may often come
across Web links which require the use of a Telnet client. Unfortunately,
IBM WebExplorer does not allow you to configure it to use a Telnet client
other than IBM TelnetPM. This is because IBM WebExplorer must provide
information to the Telnet client via the command line. Therefore, it uses
the command line format provided by IBM Telnet and IBM TelnetPM.
However, if you wish to use Kermit/2 as your Telnet client during your
travels along the World Wide Web all is not lost. Kermit/2 ships with a
utility known as the IBM Telnet Replacement, "telnet.exe" and
"telnetpm.exe". The Telnet Replacement provides a command line interface
that is identical to that provided by IBM Telnet and IBM TelnetPM. It
converts the command line options into a command string that is then passed
to Kermit/2.
In order for this to work properly you must ensure that the Kermit/2
directory comes before the TCPIP\BIN directory in the PATH environment
variable.
To remove this option, simply delete the "telnet.exe" and "telnetpm.exe"
files from your Kermit/2 directory.
If you have updated the Dialing Directory or Services Directory to include
entries for each of the various systems you connect to you can further
automate the process of connecting by creating Program Objects for each
services directory or dialing directory entry. To create the new object:
For a Dialing Directory entry type:
When double clicking on a Services Directory object you would first be
prompted for the appropriate password prior to Kermit/2's connecting to the
designated service.
The Work Place Shell provides special parameters which may be passed to
filenames to Kermit/2. These parameters are replaced with the filename at
startup. They are used for drag and drop operations or file associations.
If the PUSH command, and related commands, do not work for you, check the
definition of your OS/2 COMSPEC environment variable, i.e. make sure it
contains the fully-specified pathname of a valid OS/2 executable shell
program (such as C:\OS2\CMD.EXE), and/or the named program is in your OS/2
PATH .
Kermit/2 works with JP Software's 4OS2.EXE, the Hamilton csh, and any other
replacement Command Shell. The directory containing the shell must be
located in the PATH in order for the replacement shell to be called
correctly.
Out of the box, OS/2 is tuned to favor foreground applications, which is
fine if the background applications will not be performing time-critical
operations or be expected to perform consistent screen updates. But Kermit
does both, and so we need a way to tell OS/2 to let it run at a reasonable
speed even while we do other work in the foreground.
There are two settings in the CONFIG.SYS file which affect how OS/2
determines the priority of applications which are competing for CPU time and
File I/O Services:
Other settings that also affect the performance of OS/2 are:
Disk caching is extremely important and can have a dramatic affect on the
performance of your computer. Disk caches in OS/2 are allocated separately
for each type of file system: FAT , HPFS , and CDFS . When configuring your
cache do not set the cache size to be high if you have a small amount of RAM
(less than 16MB). Be sure to turn on Lazy Writes.
If you never run DOS or Windows programs, set PROTECTONLY=YES. This will
give OS/2 640k more physical memory to use for your OS/2 applications.
For additional information on all of the above topics read the OS/2 Command
Reference in the Information folder on your OS/2 Desktop.
Further information on tuning OS/2 can be found in:
These files and more are available from most OS/2 ftp sites, BBS, and online
services under a variety of names.
Click Back on your Browser's Toolbar to return.
Files
The files are the same as for the Windows version, except all files whose
names start with K95 have names starting with K2 in the OS/2 version. Also,
there are certain platform-specific differences; for example, the Windows
version might have some utility programs that are not needed in OS/2, and the
OS/2 version has some fonts that can't be used in Windows.
Differences Between OS/2 and Windows 95
The following sections describe differences between OS/2 and Windows 95
as they affect Kermit's Terminal window.
Console Only
It was not possible to create both Windows and OS/2 GUI versions from common
code.
No SSH Client
The OpenSSH library was not available for the native IBM OS/2 development
environment.
No Toolbar
OS/2 Console Windows, unlike Windows 95, do not contain an optional toolbar.
All functions such as window sizing, font selection, copy/paste, ... are
performed by using the System Menu accessed by clicking on the Window
mini-icon in the upper left hand corner.
Changing the Window Font
The fonts used in the OS/2 Console Window may be changed by choosing "Font
Size ..." from the System Menu. The "Change" button changes the font size
for the current window only, whereas the "Save" button will change the font
size for all future windows of this application.
OS/2 Mouse Actions
OS/2 Warp 4.0 Console Windows have "Mouse Actions" that supersede all of
the Kermit-95 mouse functions. In order to use Kermit-95's mouse functions
for text selection, copy to clipboard, host, or printer, or cursor
repositioning you must disable "Mouse Actions" by using the System Menu.
Loading Alternative Fonts into Fullscreen Sessions
Kermit-95 for OS/2 supports the ability to install VGA fonts into the
video memory of the video adapter when running in a Full Screen session.
This is accomplished by using the SET TERMINAL FONT command.
Kermit-95 supplies fonts for:
CP437 - Original PC Code page
CP850 - "Multilingual" (Western Europe) code page
CP852 - Eastern Europe Roman code page (Czech, Polish, ...)
CP862 - Hebrew code page
CP866 - Cyrillic code page (Russian, Belorussian, and Ukrainian)
Screen Dimensions
OS/2 2.x (pre-Warp 32-bit OS/2 versions) can not create 132-column console
screens, but it can create console screens of just about any height you want:
30, 35, 40, etc. In OS/2 4.0 and later, you can have any screen dimensions
you wish.
The Mouse Cursor
In OS/2, if the mouse cursor is within the boundaries of the terminal screen
or command screen, it blinks each time the screen is updated. If this
annoys you, just move the mouse off the Kermit/2 screen.
The Keyboard
On "vanilla" OS/2 systems, the keyboard should work just like in Windows 95
and NT: Same keycodes, same behavior. Note, however, that Kermit/2 does not
work well with SWAPDCP (a utility floating around the net that lets you swap
the Ctrl and Caps Lock keys, etc) -- some of the keycodes are lost; e.g.
Esc, Ctrl-[, and Ctrl-H all appear to be the same key, with a keycode of 0.
Use SWAPDCP at your own risk. (Note: OS/2 C-Kermit 5A(191) and earlier worked
with SWAPDCP only because it did not provide complete key mapping capability;
Kermit/2 does, but since SWAPDCP loses some of the keyboard state flags,
Kermit/2 gets incorrect information.)
Other features not implemented in OS/2
The following features in Kermit 95 are not available in OS/2:
Tips and Tricks
When switching away from Kermit/2's terminal screen and then
switching back to it, certain video items might become confused:
Transferring OS/2 Files with Attributes
The SET FILE TYPE LABELED command allows OS/2 files to be transferred with
all their extended attributes intact -- desktop material, icons, long file
names on FAT partitions, etc. Consult the VMS appendix of "Using C-Kermit"
for information on labeled file transfer.
SET FILE LABEL {ARCHIVE, READ-ONLY, HIDDEN, SYSTEM, EXTENDED} {ON, OFF}
File Transfer Hints and Tips
Some communication software claims to implement sliding windows, but does so
incorrectly. If sliding window transfers fail, set Kermit/2's window size
to the smallest one that works, for example:
SET WINDOW 1
Using REXX
Kermit/2 for OS/2 has a REXX
programming interface consisting of the single command, REXX. REXX
REXX SAY "Hello"
REXX RETURN "Goodbye"
REXX CALL filename [ text ]
'set parity none'
'return \v(parity)'
say rc
rexx rexx-command
Kermit/2> rexx say "hello"
Kermit/2> rexx return 4 * 4
Kermit/2> echo \v(rexx)
16
Kermit/2>
Kermit/2> rexx say "hello"\13 return 0
Kermit/2> rexx call oofa.cmd
/* Beginning of REXX program file */
set parity "none"
'return \v(parity)'
parity = rc
Network Connections
Kermit/2 for OS/2 supports the following types of network connections:
Using Named Pipes
Kermit/2 for OS/2 supports NAMED PIPES as an interprocess communication
mechanism. Named Pipes support for local processes is built into OS/2. In
order to use them to communicate across a local area network both computers
must have installed Named Pipe network support software. Each computer may
be a Client, a Server or both. Each server on a particular network has a
unique Named Pipe Server Name assigned as part of the Named Pipe software
installation.
SET NETWORK NAMED-PIPE [ pipename ]
SET HOST *
SET NETWORK NAMED-PIPE [ pipename ]
SET HOST servername
set terminal echo local
set terminal cr-display crlf
connect
Using NETBIOS
Kermit/2 for OS/2 supports the NETBIOS API, both the original NETBIOS 3.0
(NETAPI) interface and the newer NETBIOS 4.0 (ACSBNET) interface.
Kermit/2 has been tested with the following products:
IBM LAN Distance
IBM Communication Manager/2
IBM LAN Server 3.x
IBM LAN Requester 3.x
IBM OS/2 WARP 3.x, 4.0
IBM Extended Services 1.x
IBM LAN Server 2.x Requester
Novell NetWare 2.x Requester
SET NETWORK NETBIOS [ localname ]
SET HOST *
SET NETWORK NETBIOS [ localname ]
SET HOST servername
To close a NETBIOS connection, give the HANGUP command (or the SET HOST
command, specifying no hostname) to either the client or the server.
set terminal echo local
set terminal cr-display crlf
connect
Product Config File Sessions Commands Names
Novell (IPXNB) NET.CFG 16 32 24
IBM NTS/2 (NETBEUI) PROTOCOL.INI 5 95 21
Product Config File Sessions Commands Names
Novell (IPXNB) NET.CFG 64 128 128
IBM NTS/2 (NETBEUI) PROTOCOL.INI 254 255 254
[NETBIOS]
DriverName=NETBIOS$
virtual adapter=driver,physical adapter,sessions,commands,names
virtual adapter=driver,physical adapter,sessions,commands,names
...
ckermit -N 1
-N adapter
[NETBIOS]
DriverName=NETBIOS$
Adapter0=ipxnb$,0,48,128,16
Adapter1=netbeui$,0,48,255,16
[NETBIOS]
DriverName=NETBIOS$
Adapter0=netbeui$,0,48,255,16
Adapter1=ipxnb$,0,48,128,16
[NETBIOS]
DriverName=NETBIOS$
Adapter0=ipxnb$,0,48,128,16
[NETBIOS]
DriverName=NETBIOS$
Adapter0=netbeui$,0,48,255,16
Adapter1=netbeui$,1,48,255,16
Adapter2=ipxnb$,0,48,128,16
Using DECnet PATHWORKS
DECnet LAT (Local Area Transport) support works in conjunction with DEC's
PATHWORKS For OS/2 product version 2.3 or later, which must be installed,
and LATCALLS.DLL must be in your LIBPATH. To make LAT connections from
Kermit/2:
SET NETWORK DECNET
SET HOST hostname
Using Asynchronous Communications Servers
There are two methods for using remote modems accessed via LAN
server (asynchronous communication server):
net use com3 \\server\modem
ckermit -l com3
net use com3 /d
ckermit -l \\server\modem
set line //server/modem
set line \\\\server\\modem
set command quoting off
set line \\server\modem
set command quoting on
Using Kermit/2 to Dial SLIP and PPP Connections
Kermit/2 may be used instead of SLIPTERM/PPPTERM for starting SLIP/PPP
connections, providing more extensive serial device and terminal emulation
support than that included in SLIPTERM/PPPTERM.
SOCKS 4.2 Client Support
Kermit/2 provides support for SOCKS 4.2 servers when using IBM TCP/IP 2.0,
IBM OS/2 WARP, or a compatible protocol stack. SOCKS is one popular means
of implementing a firewall between a private network and the Internet.
Networking Hints and Tips
The SET HOST command uses your current SET NETWORK type. For example:
SET NETWORK DECNET
SET HOST OOFA
SET NETWORK NETBIOS OOFA
IF FAIL STOP 1 Can't access NETBIOS network
SET HOST MUPEEN
IF FAIL STOP 1 Can't make NETBIOS connection
Remote Access
The recommended way to provide remote access to your OS/2 system is with
Kermit/2 host mode (see previous section).
Using Kermit Software Instead of Lap-Link
Lap-Link software is typically used to synchronize the versions of files
found on two separate computers by transfering files across either a direct
serial port or parallel port connection.
OS/2 Kermit Utilities
OS/2 Kermit PM Clipboard Server
Since Kermit/2 is not a PM application its ability to access the PM
Clipboard is extremely limited. In fact, according to IBM documentation, it
shouldn't be possible at all. However, OS/2 C-Kermit has by itself (since
release 5a(190)) given users the ability to copy data into the PM Clipboard
for use by other applications. It also was able to retrieve data from the
PM Clipboard whenever the data was placed there by an application using a
type of shared memory known as GETABLE shared memory.
IBM Telnet Replacements
Rlogin Command-Line Executable
Similar to "telnet.exe", Kermit/2 comes with "rlogin.exe". The command
line RLOGIN utility allows you to access hosts from the command line with
using the LOGIN protocol instead of TELNET.
More OS/2 Hints and Tips
Kermit and the OS/2 Work Place Shell
You can use the Program page in the Settings notebook of the Kermit/2
program object to enter parameters that will affect the way the program
starts. Kermit/2 does not normally need parameters when it is opened. You
can add Kermit/2 to the pop-up menu for a folder object (e.g. the Desktop)
so you can start that program by selecting the choice on the pop-up
menu. However, when you start Kermit/2, OS/2 sends any parameters to the
program. OS/2 considers the name of a folder a parameter, so OS/2 sends the
folder name to the program when you select a program-name choice from the
pop-up menu. Kermit/2 cannot accept a folder name as a parameter. If you
try to start Kermit/2 from the pop-up menu of a folder and the program does
not start or displays an error message, you can stop the name of the folder
from being sent to the program by doing the following:
-C "access
-C "dial
Serial Port Performance
Kermit/2's performance on serial connections - and the performance of any
other OS/2 communication software program - can be improved significantly by
using a 16550AFN communications port controller (UART) rather than an 8250,
16450, 16550 (no A), or other unbuffered UART. Unbuffered UARTs interrupt
the CPU once per character, whereas a buffered UART interrupts every 8-14
(or more) characters. Measurements during Kermit/2 file transfer on an
otherwise unloaded i486/50 EISA system under OS/2 show approximately 10%-25%
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.
OS/2 Devices, Files, and Shells
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 should not occur in file transfer operations. The "hard error box" will
put a halt to unattended, scripted operations, and it stops the operation of
the Kermit/2 server if there is no human in attendance. To work around: add
the line " AUTOFAIL =YES" to CONFIG.SYS and reboot. This eliminates the
hard error box, but it applies system-wide, not just to Kermit/2. (The
equivalent of AUTOFAIL =YES can be set on a per-process basis and Kermit/2
does so for itself but it can't do this for any inferior processes started
by it.)
Running Kermit in the Background
When Kermit is performing a long file transfer or lengthy script-based
operation, you can have Kermit proceed with its work in the background while
you work on something else in the foreground.
Applications that Freeze
There have been isolated reports of Kermit/2 "freezing" on some systems.
This problem is not confined to Kermit/2, and has also been observed with a
variety of other communications software packages: