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 xonFull-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:
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 NONEBLANK-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 0Doomsday 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