First, consider really whether the SNA step is necessary any longer. tn3270 
directly to the host is not the resource pig it used to be. 

Second, there's two stages here: desktop to Linux (which needs only IP) and 
Linux to VTAM, which needs to be layer 2 clean (eg TYPE ETHERNET guest LAN). 
VLANs are a refinement to the plan. 

Crude picture: 

Client  --IP-> Linux - SNA --> VTAM

The first hop (client to Linux) can be a direct OSA connection or delivered via 
a virtual NIC connected to a VSWITCH connected to a VLAN-aware physical switch. 
The second hop is a different network segment (could be a different VSWITCH or 
layer 2 GLAN, or a different VLAN number on the same VSWITCH - -I'd suggest the 
first option). 

You don't care about the MAC address on the first hop. You care deeply about 
the MAC address of the second hop. 

I'd suggest: 

Set up the Linux guest and set the IP address on eth0. 
Define a second VSWITCH or layer 2 GLAN without giving it access to an OSA. 
Define and couple a second virtual nic on Linux to the second GLAN/VSWITCH. 
Make sure it has a fixed MAC address on the NICDEF in the directory entry for 
the Linux guest.
Define and couple a second virtual NIC on VTAM to the second GLAN/VSWITCH. Make 
sure it has a fixed MAC addres in the NICDEF directory entry for VTAM (must be 
different than the other adapter above)
Configure second adapter on Linux in the SNA software.
Configure VTAM XCA and other members for the second adapter. 
Activate VTAM node
Activate adapter in Linux

At that point, the two SNA implementation should show connected and available. 

Once that's done and working, THEN configure the tn3270 server on Linux and 
allow it to start passing sessions to the SNA stack. 

> The solution I am thinking of now is to use real hardware to route my SNA 
> traffic back and 
> forth between VTAM and the z/LINUX SNA server on real OSA ports.
> Is that right? Or have I missed something?

Unnecessary. See above. 

Second repeat: seriously consider eliminating the front end and just run IP all 
the way into the other system, or switching to using the connection exit in the 
VM Telnet server to DIAL VTAM and go directly to SNA-land from there. This SNA 
server stuff is just way more complicated and costly than you need to support 
simple telnet functions. 
 

Reply via email to