1. If you're trying to look like a 3270 on a 3174 and you need to be usable as
    a console before VTAM is up then you need to connect over B&T, ESCON
    or FICON. A TN3270 session with an OSA-ICC will do the trick.

 2. The 3174 had both synchronous and asynchronous RS-232-C adapters.
      a. A 3174 used as a protocol converter had asynchronous adapters.
      b. A remote (BSC or SDLC) model had a synchronous adapter. Depending
          on the configuation, it might be dial, leased analog or digital.
 3. TN3270 does not carry SNA packets, although tere are some housekeeping
      data that may be transmitted.
 4.  Only an SNA 3174 looks like a tree of devices.
 5.  MSNF already allowed SNA traffic between hosts; what APPN did was to
      allow semi-autonomous nodes with less complexity.
 6. It's easy to capture the traffic between a local 3174 and the host. For 
    non-SNA it's also easy to read the traces.

Shmuel (Seymour J.) Metz

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Grant Taylor <0000023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, January 14, 2020 8:07 PM
Subject: Re: Talking to 3270 terminals?

On 1/14/20 2:52 AM, Alexander Huemer wrote:
> Hi


> I am new to this list and would like to discuss an idea and ask several
> questions.


> * Did anybody ever attempt to 'talk' to 3270 terminals with something
> different than an IBM mainframe?


* because it's highly dependent on what you mean by "IBM mainframe".
More specifically if you mean the hardware and / or the software.

I know that there are people actively working in the Hercules community
to drive (talk to) 3270 terminals.

I think I've recently read some articles where someone is trying to use
a 3270 as a terminal for a Unix (Linux?) workstation.

So, "It depends...."

> This might sound like a strange idea, though I find it intriguing to
> be able to display content on such a terminal and be able to receive
> keyboard input from it.

It doesn't sound completely crazy to me.  It does some completely
atypical.  But atypical can be entertaining and / or educational.

> I guess the most straight-forward way to attempt something like that is
> to use a 3270 terminal attached to a 3174 or similar and try to talk to
> that instead of the terminal itself. I wouldn't know how to interface
> with the terminal directly over the coax.

I believe the article I recently read was talking about driving the
signal on the coax.

I typically see some variation of the following discussed:

1)  3270 terminal talks to the (remote) 3174 Control Unit (?).
2)  The remote 3174 CU talks across Ethernet or Token Ring or RS-232
something else acting like a local 3174 CU.
3)  This thing acting like a local 3174 usually talks TN3270 to a
mainframe OS, be it running on a physical mainframe or emulated.

I believe that some later / feature rich 3174s have the ability to act
like primitive telnet clients.  Thus you could use the 3270 to talk to a
Unix box.

> * What's the best available documentation regarding 3174 models and
> their features?

I don't know.

I've seen quite informative discussions about this type of thing on the
hercules-390 and cctalk mailing lists, plus a few newsgroups.

> I poked around on ibm.com and google but wasn't able to find much. It
> seems like there were several different physical-layer north-bound
> interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not
> mistaken, for dial-up connections), maybe others?

I think it's highly dependent on if it's the "local" or "remote" 3174.

I think that the "local" 3174 was exclusively Bus & Tag for northbound.
—  I've not heard of any ESCON interfaces for 3174.  —  The Token Ring /
Ethernet / SDLC / RS-232 was southbound to talk to "remote" 3174s.

Similarly, the "remote" 3174 was Token Ring / Ethernet / SDLC / RS-232
for northbound and coax for southbound.

The Token Ring / Ethernet / SDLC / RS-232 was used to connect "local"
and "remote" 3174s.

> Bus&Tag doesn't seem to be a good candidate, it's difficult to interface
> with as far as I understand.

Two things come to mind to interface with B&T.  The B&T cards that exist
for PCs running things like the PC/370 / P/390(-E) or something like a
big iron Cisco router with a Channel Interface Processor card.  But I
think even the CIP is a "grey" downstream device and can't pretend to be
a "black" host (mainframe) device.

> Ethernet is way more common these days than Token Ring, though TR NICs
> are easy to procure second hand


> protocol support under Linux (the OS I am most savvy with) is in place.

Be careful there.  Contemporary Linux (4.x) no longer includes Token
Ring support.  I believe it was removed from 3.5.

Even then, there are other protocols that I've not been able to find
support for in Linux.  SNA being the biggest contender.  There are
pieces that I think could be used to help support SNA.  But I'm not sure
that all of the requisite pieces are there.  LLC is questionable.  There
were a couple of implementations for some different things.  I don't
know if any of them were ever complete enough to support SNA.

> RS232 is easy to interface with also, though then again, I am not sure
> if that interface really exists.

I think that the 3174s did have RS-232 support.  But I'm not sure what
it's purpose was.  I don't know if it was for dial up SNA or if it was
for synchronous modems / X.25 networks.

> * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3

I think so.

My understanding is that SNA on Ethernet / Token Ring used 802.2 LLC
frames (you can find the SSAP / DSAP numbers).  I don't think that SNAP
was used.

SNA is as different from TCP/IP, IPX/SPX, AppleTalk, etc, as they were
from each other.

You quickly get into the fact that traditional SNA thought it was the
center of the universe and the only form of intelligent life.  Then — as
I understand it — you start getting into APPN when systems are no longer
the center of the universe where there is something out there
intelligent like another host.

> was there by any chance something going on with TCP/IP? I doubt it though.

SNA is decidedly NOT TCP/IP.

That being said, I know that TCP/IP can carry SNA traffic in a myriad of
ways.  TCP/IP can encapsulate SNA;  SNASw and Enterprise Extender come
to mind.  TCP/IP can gateway some of the higher SNA application layer
traffic and carry it more natively; TN3270 comes to mind.

I've heard / read that SNA could carry TCP/IP traffic via things like
AnyNet from IBM.

This quickly devolves into a quagmire where you need to really
understand what you do (not) have and what you want to (not) do.

I believe you can substitute IPX/SPX in place of TCP/IP and have a
different quagmire too.  I know that Apple played in this space, but I'm
not sure how much they did on the network layers.

> Talking SNA with custom software doesn't seem to be a low-hanging fruit.

No, not at all.


You really are talking about all of the layers of the OSI model.

> From where I stand right now I cannot say how straight-forward the network
> traffic between the mainframe and a 3174 is

I think that considering it to be a network protocol is probably a

The host sees things connected to it like a tree of devices.  Much like
USB on contemporary systems.

Is it a protocol?  Probably.

Is it a /network/ protocol?  I think not.

> how difficult it would be to emulate that protocol with custom software
> over several layers.

Probably quite.

There is a *LOT* to SNA.

> * Is anybody on the list here able to provide protocol traces from
> the link between mainframe and 3174 over any interface? pcap format is
> preferred, though anything would be valuable.

I think anything like that over B&T is nigh impossible.

Yes, it would be possible to get packet captures of SNA over Ethernet or
Token Ring.  But I've not seen such discussed anywhere.

I suspect it would be problematic to find someone with the proper
equipment to configure an RS-232 based connection, much less capture it.

I think that the further you get away from the host the less of the
protocol that you might actually see.

I want to say that the host and it's 3174s had a symbiotic relationship.
   But that's not the case.  It's more that the host was the brain and
that everything else was a lowly appendage.  Some things like the 3174
control units were quite important, like the heart and lungs.  But they
were still functionally subservient to the host.

> I would appreciate any thoughts regarding this topic, especially to the
> questions marked with asterisks.

This is all my understanding that I've manged to pick up over the last
year or so.  It is quite likely that I'm misunderstanding things
completely or may have some subtle nuance wrong.  Please politely
correct me if I'm wrong.

> Also, if anything is known regarding a similar thing with 5250 instead
> of 3170 terminals, that would be interesting as well.

I  don't know if I've seen anyone trying to talk to 5250 terminals like
3270s.  But my ignorance doesn't preclude such from existing.

I was recently involved in discussions about how to leverage different
Cisco routers with proper IOS support to get AS/400s talking to each
other across disparate networks.  Enterprise Extender running on a
contemporary machine & OS using an OSA to connect to one Cisco.  That
first Cisco gatewaying to something else across virtual Token Ring (?)
to another older Cisco.  That second Cisco was doing additional
gatewaying to talk to an older machine & OS on Token Ring.  It took the
combination of the two Ciscos, each doing a piece of the job, to allow
the two machines talk.

Search for the "SNA and I Systems" thread in the comp.sys.ibm.as400.misc
newsgroup if you are interested to know more.

Finally, I'll say that I'm somewhat surprised to see this type of
discussion in IBM-MAIN.  Not because I think it belongs elsewhere.
Because I think that IBM-MAIN is more day to day production support
related issues and virtually nobody is running anything like this in
production.  I would sort of expect to see this type of discussion in
hercules-390 / cctalk / newsgroups that are further off the beaten path.

Grant. . . .
unix || die

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to