Hello Jim,
Am 10.09.2024 um 03:25 schrieb Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>:
SNA was a vastly superior network but it was significantly more difficult than TCP because it was way smarter and absolutely secure.
I disagree with both allegations.
First, it was unloading the topology building to the human brain with subarea SNA, which was very cumbersome. Maybe necessary when considering the resource scarcity decades ago. That's anything but smart.
It wasn't until IBM came up with APPN to lessen the burden considerably. But still miles away from what I'd perceive as "smart". From todays view, its clearly influenced by its ancestry and the need to manually define adjacencies on the lowest level which is contrary how LANs work. And those became almost ubiquitous in corporations at the end of the 1980's. Try to explain this to a youngster and he will give you the most puzzled look.
Again later, the concept of connection networks has been introduced to ease the need of defining low level adjacencies manually. I've never bothered with it, because it seems to be overly complicated. Again. :-) Kind of an centralized ARP server, in IP lingo, and stated oversimplified.
Next came EE to account for the increasing ubiquity of IP in corporate internal WANs. Again, no additional smartness perceived.
Overengineered but fascinating. :-)
On the pro side of the comparison, no other protocol I know of has this concept of "security", as in *none, *pktswtnet, *undrgrdcbl, *securecnd, *guardcnd, *encrypted, *max as a possible routing metric which can be influenced by client request.
Finally, there is nothing "absolutely" secure. SNA benefits increasingly from security by obscurity. Implementing encryption on LU-LU level is — not surprisingly — rather cumbersome. I'm pretty sure the encryption algorithms this is based on are pretty outdated by now, considered broken, insecure, possible to be circumvented with modest effort.
Also did not run on non-IBM equipment.
Wrong. :-)
Microsoft provides the Host Integration Services Server (formerly MS SNA Server) for decades which is a Low Entry Network Node (LEN) for APPN. Not a full APPN protocol stack, but enough to support the functionality of HIS.
Once there was a product called Novell Netware for SAA with a similar feature set compared to HIS.
Apple and IBM partnered in early 1990 to come up with SNA•ps, also a LEN node implementation, to provide Macintosh users with terminal and printing support. Interestingly, this was a gateway based solution where the SNA stack itself ran on the processor of an "active" network card in a central Mac, while LU-LU sessions were re-encapsulated into AppleTalk, so any Mac could use the SNA•ps clients, even with "just" LocalTalk attachment.
https://try-as400.pocnet.net/wiki/Apple_SNA.ps
Again in the 1990's, Cisco and IBM partnered to come up with migration scenarios, bringing SNA and IP together, to spare the expense of two separate WAN connections.
Early Cisco IOS versions had a full SNA stack, later implementations a "crippled" one, being only capable of being a branch extender, but supporting EE. I tinkered a lot with that and the latter wasn't very stable.
Also, people tried to come up with an OpenSourced implementation of the SNA protocol stack for Linux. Unfortunately, it was abandoned for unknown reasons two decades ago. I don't know how feature-complete it is.
https://github.com/9track/linux-sna
One of the contributors was Jay Schulist, also being very active in early Samba ("Windows NT emulated" file server for Linux) development.
Matt Burke (
https://9track.net) managed to rewrite parts of the code so the main APPN module can be compiled "out of tree" (no need to patch the kernel source). Unfortunately, there is no EE support. And the patches for LLC probably need extensive rework to be compatible with current kernel releases. Matt asserted that (early) Linux implementations featured just enough of LLC to support IP, but SNA requires more of the standardized functionality. As such, you can compile and load APPN, but have no connection to the outside world.
Also, Roger Bowler (the initial maker of the Hercules Mainframe Emulator) implemented for UNIX a subset of AnyNet called SNIPIX.
http://www.rogerbowler.fr/snipix.htm Sadly he decided to not release this to the public after SNA became more and more irrelevant and sales declined. If there were any.
Roger once asserted to me that linux-sna is a mere empty hull and just wasn't working.
And these are only those implementations I know about. Pretty sure there have been more, especially from the era when IP wasn't lingua franca between disparate systems.
Died a slow death.
No. It just retreated. :-) Part of SNA is still there in e. g. tn5250. Not sure if current IBM i releases support IP as transport for SNADST, or only with the aid of EE.
:wq! PoC
midrange.com
