All of the Kermit books and manuals ("Kermit, A File Transfer Protocol",
"Using MS-DOS Kermit", "Using C-Kermit", and the IBM mainframe Kermit online
manuals) describe the process(es) in some detail. Here is a brief summary.
Half-duplex (local-echo), line-at-a-time connections are generally handled
by the "ibm" macro that is built in to MS-DOS Kermit and C-Kermit, which
performs the following protocol-related settings: As you can imagine, all of these conversions would normally have a
disastrous effect on Kermit protocol packets, and also upon any other type of
data that has to be transmitted "as is", without conversion, such as graphics
terminal directives. Thus, many protocol converters support a "transparent
mode", that allows the mainframe host to command them to turn off their
conversion functions, and at a later time, turn them back on.
When everything works as planned, the only Kermit commands required for
going through the protocol converter are: Unfortunately, the method for entering and leaving transparent mode differs
from one 3270 emulation product to another. Ideally, there are two components:
(1) the identification phase, in which the mainframe software issues a special
instruction that causes the protcol converter to respond in a unique (but
harmless) way; and (2) the actual enter- and exit-transparent-mode directives.
IBM Mainframe Kermit needs to know which kind of transparency, if any, is
used by the protocol converter so it can be put into transparent mode at the
beginning of packet protocol and taken out of it upon return to interactive
command mode. There are several ways that mainframe Kermit can go about this.
First, you can use the SET CONTROLLER command to tell it which style of
transparency is used by the protocol converter. Second, mainframe Kermit can
be set up by the system administrator to always use a particular style. Third,
it can attempt to "autodiscover" the controller type by issuing various types
of identification queries and checking the results. The third method is not
very reliable, however, since many types of protocol converters fail to respond
to these queries even when they do implement a particular style of
transparency.
Nowadays, special-purpose protocol converters are giving way to general
purpose terminal and compute servers that include a "tn3270" function. tn3270
is a special kind of TELNET program that also performs 3270 emulation, and
requires that the mainframe be on a TCP/IP network and have a TN3270 server.
Here are some examples:
If you try all of these workarounds with your terminal server and still get
failed transfers, make packet logs and/or debug logs in both Kermit programs to
find out what the terminal server is delivering to each Kermit program, and
report the misbehavior to your terminal server vendor.
For further information about specific protocol converters and how to
configure IBM Mainframe Kermit for them, please read the ik0aaa.hlp file that
comes with IBM Mainframe Kermit.
Finally, it is possible to transfer files through a 3270 fullscreen
connection even when 3270 emulator can't be put into transparent mode at all.
You can read about this in the second edition of Using C-Kermit and the
MS-DOS Kermit update notes file (KERMIT.UPD). Quoting from the latter:
"Doomsday Kermit" (DDK) techniques allow file transfer with IBM mainframes
through 3270 protocol converters that do NOT support transparent mode, to be
used in conjunction with IBM Mainframe Kermit's SET CONTROLLER FULLSCREEN
command on VM/CMS, MVS/TSO, or CICS. MS-DOS Kermit 3.13 or later and IBM
Mainframe Kermit 4.2.3 or later required. Commands: (end quote)
And beyond finally: in the future, we expect to add 3270 emulation to the
Kermit software itself, so you will be able to make tn3270 connections directly
from Kermit to the mainframe without having to go through a "black box" for the
conversion. Of course, Kermit software will handle transparency correctly (and
automatically). (And no, I can't estimate when built-in 3270 emulation will be
available.)
- Frank
7 How to Transfer Files through a 3270 Protocol Converter?
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit File Transfer and tn3270
Date: 16 Jan 1995 16:46:18 GMT
Organization: Columbia University
Lines: 169
In article <173276AEB.BDESIMON@uga.cc.uga.edu>,
Bert DeSimone <BDESIMON@UGA.CC.UGA.EDU> wrote:
> Gotta figure this has come up before. We are evaluating a terminal
> server that supports tn3270. No problem using MS-Kermit to connect
> to the terminal server and connect via tn3270 to an IBM mainframe.
> However, file transfers (either invoking server on the mainframe or
> not) always fail. Connecting through this same terminal server to
> the same mainframe through a 7171 presents *no* problem with file
> transfer. (BTW: I don't have to be using tn3270 on a terminal
> server; file transfers with Kermit using tn3270 on a Unix host fail
> the same way).
>
> I am speculating that the mainframe Kermit must send a transparent
> mode sequence, ordinarily processed by the protocol converter, that
> is causing the problem.
>
One of the major strengths of the Kermit protocol is its ability to
transfer files with IBM mainframes over a wide variety of connection types, and
there is an excellent Kermit software program for the IBM mainframe, which is
available for VM/CMS, MVS/TSO (and ROSCOE), CICS, and MUSIC. The current
version is 4.3.2.
set local-echo on
set parity mark
set flow none
set handshake xon
Full-screen sessions go through a 3270 terminal emulator. This can
reside anywhere between the client software (such as MS-DOS Kermit) and the
mainframe. For the past 10 or 20 years, the most common place to find the 3270
emulator was on a special purpose "protocol converter": a box that has serial
lines on one side and a connection to the mainframe on the other. This box
generally works by tricking the mainframe into thinking it is a "control unit"
with multiple 3270 terminals attached, and at the same time tricking the
terminals into thinking they are communicating with a "normal" ASCII
character-at-a-time host. The box converts between 3270 data streams and ASCII
terminal (e.g. VT100) conventions. This includes ASCII/EBCDIC character-set
conversion, cursor positioning and screen painting, and keystroke
interpretation.
set flow xon/xoff ; (usually)
set parity even ; (or other)
Everything else corresponds to the normal Kermit defaults (remote echo,
no "handshake", etc).
SET PARITY EVEN ; Or whatever
SET FLOW XON/XOFF ; Or whatever
SET SEND START 62 ; Greater-than sign
SET RECEIVE START 62 ; Ditto
SET BLOCK BLANK-FREE-2 ; New block-check type
SET HANDSHAKE NONE
BLANK-FREE-2 is a new block-check type, exactly like type 2, except
encoded to never contains blanks. Give IBM Mainframe Kermit the following
commands:
SET CONTROLLER FULL
SET SEND START 62
SET RECEIVE START 62
SET BLOCK BLANK-FREE-2
SET HANDSHAKE 0
Doomsday Kermit file transfers are not as reliable as regular Kermit
protocol transfers, and they are much slower. Use this method only as a last
resort; that is, only when you can't get a transparent-mode fullscreen
connection or a linemode connection to the mainframe.
Kermit FAQ / Columbia University / kermit@columbia.edu