| Author |
Message
|
| nosnhoj |
 Posted: Fri Mar 23, 2007 5:18 am Post subject: SNA vs TCP |
 |
|
Apprentice
Joined: 07 Sep 2005
Posts: 40
Location: Markham On.
|
I was asked if there is any benefit to changing from SNA to TCP/IP (unix connecting to mainframe) - and I figured "if it ain't broke, don't fix it"
Other than that rock solid answer, is there any substantial benefit for someone wanting to 'look into' that change? |
|
| Back to top |
|
 |
| zpat |
| Posted: Fri Mar 23, 2007 5:26 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
SNA software for UNIX is usually a chargeable extra.
SNA over a LAN tends to use non-routeable low level protocols - most network guys would prefer not to have these.
SNA support is becoming a rare skill. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Mar 23, 2007 5:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, while to a large degree "if it ain't broke, don't fix it..." is a reasonable approach, one also has to acknowledge that change is a fundamental force in the universe and a fundamental force in business and IT.
The best approach for dealing with this fact is to manage change, rather than avoid it.
This means things like applying regular maintenance to software, planning hardware upgrades, and planning and managing technology upgrades, and acknowledging changes in the market.
This is all to back up what zpat says.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| nosnhoj |
| Posted: Fri Mar 23, 2007 5:34 am Post subject: |
|
|
Apprentice
Joined: 07 Sep 2005
Posts: 40
Location: Markham On.
|
| SNA is already installed and running... but as you said, the 'support' skill isn't there. This is the big reason they want to look at going TCP |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Mar 24, 2007 11:09 am Post subject: |
|
|
Guest
|
Unfortunately, the battle of TCP/IP vs SNA is long over. The politics of TCP/IP have all but killed off LU6.2. The same thing happened in the Token Ring vs Ethernet battle. Bill Gates long ago proved that effective marketing beats technology.
VTAM and LU6.2 are still used within mainframes; but seldom to/from mainframes.
My advice: duck this, and move to IP. It's probably already running on your mainframe; and it works just fine. The argument/discussion is not worth the loss of your credibility. You will be seen as a dynosaur.
SNA (LU6.2) does have its advantages.
IP frames are small and fixed; LU6.2 frame size can be specified, and are usually much bigger. LU6.2 is session-bound vs. IPs connection-less nature.
Sessions can have userids/passwords imbedded in the MQ channel definitions. This transport-level validation alone may be enough of a benefit not to change for the sake of changing.
There are IP vs SNA documents to be found on the net. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Tue Mar 27, 2007 12:25 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 314
|
| Most mainframe shops use what they call the Enterprise Extender these days. Changes SNA to TCP and sends it over the wire to the recipient. Before it is given back to the recipient it gets converted back from TCP to SNA. While I’m not sure about how far reaching an “Enterprise Extender” is say to and AIX box in the network, one has to believe there is some overhead involved is tearing down and rebuilding SNA and TCP traffic. You may want to ask your network team if this is involved |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 27, 2007 2:25 pm Post subject: |
|
|
Guest
|
An Enterprise Extender (EE) enables is a logical connection that delivers SNA connectivity over TCP/IP from an EE- enabled workstation / server to the target EE- enabled host. EE uses UDP. Overhead is minimal.
IBMs PCOMM, Host Integration Services and SNA Switching Services, implement EE at non-mainframe remote sites. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Tue Mar 27, 2007 3:11 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 314
|
I happened to inherit support of 30 z/OS MQM’s where all the channels between the z/OS MQMs where APPC using EE. Any channel from z/OS MQM to any other platform was TCP. So I tried to figure out from here:
http://www-1.ibm.com/support/docview.wss?rs=852&uid=swg27005523
How much overhead it was costing us. Pretty difficult to extrapolate a number with MQ as the client. Well, it was for me anyway. Near as I could figure it was 21-22 microseconds CPU per KB.
One thing I do know, configuring these APPC channels on the mainframe is much more difficult and involves several groups to accomplish. Requires a VSAM side info dataset and batch job, VTAM entries, automation to activate, and the MQ OBJECTS – yuk. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 28, 2007 6:28 am Post subject: |
|
|
Guest
|
Yep. SNA/VTAM/LU6.2 is ugly. It works. Again, I'd duck the (political) discussion of the relative merits of TCP vs. SNA. At this point in network hardware/software evolution, they are pretty much equal.
I'd go forward with the migration to TCPIP using the rationale that it conforms to company policy, or it's ITs stated direction, or consolidates to a consistent network protocl, or blah blah. |
|
| Back to top |
|
|
|
|
