Kermit FAQ - How to Transfer Files through a 3270 Protocol Converter?

(Home) (Prev) (Next)

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.

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:

  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.

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:

  set flow xon/xoff ; (usually)
  set parity even   ; (or other)
Everything else corresponds to the normal Kermit defaults (remote echo, no "handshake", etc).

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:

  1. UNIX tn3270. Most UNIX systems come with a tn3270 program that lets you make a full-screen connection to an IBM mainframe. Once you have made the connection, you should be able to start Kermit on the mainframe, give it a SEND, RECEIVE, or SERVER command, escape back to your terminal emulator (e.g. MS-DOS Kermit), and transfer files without any special settings. If you have trouble with this, then:
  2. VMS tn3270. Depends on the TCP/IP version. TGV Multinet, for example, does not claim to support transparent mode.
  3. Cisco terminal server tn3270. Current releases of Cisco terminal server software include a tn3270 feature that is supposed to permit Kermit transfers, but it has bugs. Sometimes these bugs can be worked around by using the methods listed in (1) above and specifying VERY short packets, like 30 or 40 bytes. Sometimes they can't be worked around at all. A future release of Cisco software (probably 10.3) will include new tn3270 software that implements Series/1-style transparency correctly, and allows Kermit transfers of both text and binary files in both directions using packet lengths up to about 1900 (or whatever the total screen size is).

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:

  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.

(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


Kermit FAQ / Columbia University / kermit@columbia.edu