IBM 3174 C 6.4 Microcode Disks?

[Grant Taylor]

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