Re: Telnet Query

"Robert G. Moskowitz" <> Mon, 17 May 1993 14:05 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa25708; 17 May 93 10:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25704; 17 May 93 10:05 EDT
Received: from by CNRI.Reston.VA.US id aa02105; 17 May 93 10:05 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 3396; Mon, 17 May 93 10:07:09 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 3389; Mon, 17 May 93 10:07:00 EDT
Date: Mon, 17 May 1993 13:49:00 GMT
Reply-To: IETF TN3270E Working Group List <>
X-Orig-Sender: IETF TN3270E Working Group List <>
Comments: <Parser> W: CC field duplicated. Last occurrence was retained.
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <>
Subject: Re: Telnet Query
X-To: IETF TN3270E Working Group List <>
X-cc: Dave Crocker <>
To: Multiple recipients of list TN3270E <>
Message-ID: <9305171005.aa02105@CNRI.Reston.VA.US>

Michael StJohns said:

Christian - without commenting on whether or not the idea of "packets"
makes sense within a telnet stream (I've read Dave's note a couple of times
and I'm not sure which way to jump) it makes sense to make this part of the
telnet protocol rather than a separate protocol.  Why?  -> The notion of
fall back.  If you can't negotiate TN3270 mode, you still get dumb  (or
perhaps dumber) terminal service.  Whereas if you have a TN3270 only
protocol you're out of luck if one end or the other doesn't do the
protocol.  Telnet has a fairly powerful optioning mechanism -- I wish more
of our protocols had ways of negotiating options this cleanly.

To which Dave Crocker replied:


The IDEA of fall-back is appealing.  But is it realistic in this case?

I don't know anything about the 3270 world.  If I refuse 3270 mode,
will host systems really let me continue in dumb tty mode?


Dave Borman:

HELP!!!  We are now getting cross-postings, which is good, but it makes replies
hard.  It might be my MCIMail -> INTERNET -> BITNET that ends up with my BITNET
postings including all original TO:s.  So I have CCed Michael and Dave Crocker,
but you might need to post this to the IESG or IAB or whereever...


Now in answer to Dave Crocker, from a real-life environment.

We have two different TN3270 deamons at Chrysler, lots of instances of each.

With MVS/TCP (from IBM) running as a started task on our MVS mainframes, we have
configured a none 3270 terminal type to act as a 3767 tty device.  Of course,
since not too many MVS apps can handle this 'LOGMODE', we auto connect such a
user to our VM system.  I know of other companies that use SIMWARE on their MVS
hosts to do the VT100 -> 3270 mapping.  For them, a VT100 or such terminal type
results in a session with SIMWARE that then functions as a host session manager
and does the necessary conversions.

With OCSII (from Open Connect Systems) running on an RS-6000, a non-3270
terminal type (well not all but the ones we need) are mapped to a 3270 device
by OCSII.  This works fairly well.  We have also done some custom coding on the
RS-6000 so when a dumb assembly line robot TELNETs to an OCSII box, a script
does the rest of the work in connecting that robot to the proper CICS region
(this was trivial back in the 3708 protocol conversion days...).

Oh, to access the RS-6000 to do maintance on it, we have set up TELNET on
another port, as OCSII 'ownes' port 23 on those systems.

So, the answer is YES!  Fall back to a non-3270 device is currently in use in
the real world.

Robert Moskowitz
Chrysler Corporation
TN3270E WG Chair