22 Feb
2019
22 Feb
'19
3:02 p.m.
On 02/21/2019 04:02 AM, Dave Wade wrote:
I think we have a layer disconnect here. There is a
PHYSICAL connection,
but logically the SNA traffic just passes through the box. You define
the MAC addresses of the end points in the 3174 but it knows nothing of
the traffic passing through. As far as the end points are concerned its
just a router like the one in my wardrobe that links to the VDSL that?s
passing my traffic TCPIP traffic through Except that my router has to do
NAT. These are all in the same SNA Domain and have unique SNA addresses.
When doing SNA the terminal on the remote 3174 connects the VTAM...
Okay.
I'll have to ponder this.
That?s just like IP routing. If we are doing SNA then
each terminal has
an SNA address that?s defined on the host. Its kind of like IP routing.
My workstation knows that to route IP traffic to a specified non-local
IP address it has to send it to my router. Same with SNA. The SNA
connection is between the terminal and the mainframe. The 3174 simply
routes traffic....
Okay.
I'm starting to see a pattern as I re-read your email, pontificate, and
reply.
Yes, precisely. SNA is a layered protocol just like
TCPIP. SNA connections
Sit on top of other protocols.
ACK
Admittedly I had not thought about SNA being a layered protocol, much
less what that means. But it does make perfect sense.
My limited understanding has come from very few discussions about SNA
over the years (prior to this and related threads) with people who
treated it like a black box.
Theoretically VTAM has application layers. In practice
it?s a mess...
~chuckle~
Yes, the VTAM documentation is a good place to start
(well perhaps not).
;-)
But basically VTAM (used to, I haven't looked for
a while) have huge
tables that list every device on the network.
I'm starting to get the impression that the tables are even larger than
I might have originally suspected.
So if you want to use 10 SNA 3270 terminals
concurrently on an RS6000
There must be a VTAM/SNA node defined for the RS6000, and 10 VTAM/SNA
nodes for the terminals.
Why do there need to be 10 VTAM/SNA nodes defined for the RS/6000?
Wouldn't it be one node unto itself, much like a 3174, with the 10
VTAM/SNA nodes for the terminals behind it?
This lead to PC type gate products like Microsoft SNA
server where you
had TN3270 sessions to SNA server then connected via SDLC/Token Ring/X.25
to SNA on the host.
So would Microsoft's SNA server (or the likes) have it's own VTAM node
definition (terminology?) and a VTAM node definition for each (virtual)
terminal that that was behind it?
Where each virtual terminal was quite literally a logical representation
of a state machine for the terminal and the TN3270 traffic would be the
communications between the virtual terminal and the TN3270 terminal
emulator running on the down stream IP client(s).
Would VTAM still see the (virtual) terminals instantiated by SNA server,
even when downstream clients were disconnected? Thus ultimately would
timeout and logout / disconnect clients from ""idle terminals.
Am I in the correct ball park?
If you wanted 20 concurrent session, you defined 20
nodes in VTAM
and SNA server. SNA Server would assign in bound TN3270 sessions SNA
addresses from its pool and associate them with the terminal...
Sort of like old school modem pools, you got the first one that's
available (assuming one was available), and it would have it's hardwired
/ defined node configuration in VTAM. Thus you could get different
terminal IDs depending on which virtual terminal you got out of the pool.
Now I have remembered something nasty. There are SNA
management sessions,
so if he is feeling nasty, the VTAM operator can disable any terminal
on any 3174, or any 3174 ..... ... so yes there may be SNA sessions
between 3174s for management purposes.
Would s/he be disabling something on the 3174 itself? Or the logical
VTAM entity (LU?) in the mainframe, thus disabling anything on the
downstream end. Sort of like putting a phone call on hold at the
receiving end functionally renders the phone at the calling end unusable.
I also haven't considered LU6.2 but LU6.2 is SNA
app to SNA app so I
can't see and SNA LU6.2 session terminating within a 3174.
I know of LU type 6.2, but not much else about them.
Token/Ring and Ethernet yes. I don't know of a way
to have SDLC <->
to SDLC. But again its not an SNA end point to end point. The 3174 is
merely routing SNA Frames.
It sounds like the 3174 is conceptually routing or perhaps actually
switching SNA frames between connections based on endpoints the 3174's
portion of the big table of who's connected where.
Everything has a path in the tree back to the host.
I believe here it means "route SNA traffic".
I guess that there may
also be SNA management sessions. I see that 3174's also support SNMP
so there might be SNMP sessions...
TCP/IP support improved over the years, yes...
Sorry the 3174 ORIGINATES connections. It does not accept connections.
I think we're having semantical differences. The 3174 is one of the
endpoints of the established TCP connection. Bidirectional traffic for
an established TN3270 session going from the 3174 terminates on the
RS/6000 and traffic going from the RS/6000 terminates on the 3174.
If its application aware LU6.2 would show up. That?s
like saying a
network sniffer can't see TCP/IP...
I would say 99% of 3174's had 3270 screens and connected them to the
Mainframe. That?s just bread and butter operation so any mainframe
programmer can set on up in his sleep... ... so there isn't much info
on it, so it looks like its not the way things are done....
I guess that a good proportion also had Token Ring or LAN interfaces
that allowed the mainframe to talk LAN protocols. That was cheaper than
37xx box....
ACK
Not really. One good thing about the 3174 was that it
was in IBM terms
cheap...
IMHO "cheap" and "IBM" don't belong in the same phrase.
Thank you for your input Dave.
--
Grant. . . .
unix || die