Lynn (I guess[1]) I see this is no longer discussing "VTAM security" but is hinged to one of my lead-in comment regarding "an universal network".
There are some policemen in this list who require subject drift properly to be documented - or they will complain - even if the complaint is unjustified and there has not been any subject drift - but in this case, there has been. - Once I had got deep into this post I realised why SNA was being slagged off so much. It's all down to lost political fights within IBM over which it is now pointless to keep mulling. Just about all these negative comments regarding SNA should be ignored as futile raving. Do they contain any useful messages for now and the future? It would be helpful - and this may even be "on topic" regarding the origin of the thread - if posters would declare their interests at the beginning so that biased comments can be seen as such - as is required of politicians in some legislatures. - > SNA isn't a networking infrastructure, it is large closed dumb terminal > control infrastructure. Correct only if referring to SNA as originally announced up until VTAM was offered as ACF/VTAM in 1980/81. Otherwise profoundly wrong! > It is even more restrictive than OSI ... Arguable. OSI in my experience with the IBM products which implemented it - for teaching purposes only - never really got developed very far. > ... which also wasn't an open infrastructure. Again arguable. Theoretically it was "open". In practical terms, it may not have delivered the possibilities that the label "open" suggested. My experience was only with one vendor's products so obviously I can't comment much about that. I heard the Japanese were still giving it a go after everyone else abandoned the architecture. > SNA lacked both a network layer ... True of pre-ACF VTAM and NCP, not afterwards. Skipping releases 1 and 2, release 3 (SNA 4.2) offered the virtual route network layer between VTAM (type 5) and NCP (type 4) nodes - not to bother with TCAM to keep matters simpler. This may be cumbersome in comparison with the IP networks of the mid-80's - when I first paid attention to them - which could involve much smaller machines than those running VTAM and NCP, but it's still routing from node to node. I tried to see on what narrow definition of the capabilities a "network" layer should have could allow IP to pass and SNA to fail. I failed I'm unhappy to say! I had an idea that maybe the header used for routing - surely the key characteristic of a "network" layer - which is built in the source node should not be changed in reaching the destination node. But subarea SNA actually qualifies here - over the virtual route - whereas APPN Intermediate Session Routing (ISR) and High Performance Routing (HPR) do not. Actually all this requires no segmenting over the virtual route - and no fragmentation in IP. > ... as well as a internetworking layer ... Perhaps SNI introduced with ACF/VTAM and NCP V2R2 IIRC has been overlooked for some reason I could not possibly guess. Perhaps again there is more than one understanding of what "internetworking" could be intended to mean. It defies belief that anyone anywhere near IBM in the '80s and '90s could overlook the pervasive nature of enterprises with their own SNA networks interlinking them with other enterprises, with or without the aid of the IBM networks. I'm supposed to have overlooked a joke post or two in a thread recently. Perhaps I'm being blind to a joke here. > ... while OSI had a network layer ... OSI even called it a "network layer" - sandwiched between the "data link control layer" and the "transport layer" just as the ISO model says it should be. When VIPAs appeared I was intrigued to note that the entities of the OSI "network layer" comprised one which corresponds to one of the uses of the static VIPA in the Communications Server IP component. > ... but also lacked an internetworking layer. Probably the "architects" had one in mind to be rolled out eventually. After all, OSI was supposed to take over the world - starting with the governments.[2] Incidentally, you are guilty of violating the ISO model here. A "layer" is placed between a lower "layer" and an "upper" layer, accepts services from the lower layer and provides services to the "upper" layer. It can be said to have a *vertical* function. Although we probably have some difficulty agreeing mutually what "internetworking" might mean, it cannot logically be a layer since I would expect the broadest interpretation of "internetworking" to imply an *horizontal* function. I'd better ignore "layer" following "internetworking" in what follows. > The internetworking layer (found in IP) was necessary for creating an open infrastructure (as a layer that would internetwork networks). I don't believe it is necessary to have invented IP in order to have "internetworking". If you are relying on the normal IP terminology where a LAN is a network - even a point-to-point link - and so an IP router provides "internetworking", this is just plain silly. If a LAN is to be equated with a "network", the "network" will not contain any router nodes and the operation of routing is considered by everybody except one, it would seem, as a key aspect of the "network" as a "layer" rather than the peculiar terminology adopted by IP with which most of use can take in our stride without becoming confused. > The "universal" SNA was on par with government GOSIP mandates that the internet was to eliminated and replaced with OSI (which never happened, I've frequently asserted because OSI lacked internetworking layer ... I expect that's supposed to be "the internet was to *be* eliminated and replaced with OSI". > ... even tho it was slightly better than SNA by actually having a network layer). "Once more ..., dear friends, once more ..." > The closest (with a networking layer) that might be claimed for SNA might be APPN ... So is APPN supposed to be considered SNA or not? And if it is, this utterly contradicts your statements so far regarding SNA!!! This is at least somewhat amusing as a post even if not intended to be a joke. > ... but the original APPN announcement was vetoed by the SNA organization ... after 6-8 weeks it was finally announced, but the announcement letter was carefully rewritten to avoid implying any relationship between APPN and SNA. We would periodically hassle the person responsible for APPN to stop playing around with internal stuff and come work on real networking (APPN specification was AWP164). I believe I've read some of this text before in the distinctive "garlic.com"[3] contributions. There's a bit of "so what" about this. Subarea SNA, specifically the peripheral node to boundary node part, to Low Entry Networking (LEN) SNA to APPN is a sort of progression that can be followed easily enough while retiring the type 4 node and virtual routes, that much maligned subarea SNA "network" layer! > Back in the early days of SNA ... my wife was co-author of "peer-to-peer" networking (only when SNA had co-opted the term "networking" ... was it necessary to qualify specification "peer-to-peer"). This was (internal specification) AWP39 ... and possibly SNA organization viewed it as competition (even tho SNA had nothing to do with networking). If you start from a position of bias, prejudice even, you are going to have distorted ideas! > Later when she had been con'ed into going to POK to be in charge of loosely-coupled architecture ... she had lots of battles with the SNA organization. And it's no surprise that "turf wars" will follow! > Eventually there was a (temporary) truce where she was allowed to do anything she wanted within the perimeter of the datacenter walls ... but SNA had to be used anytime the datacenter walls were crossed. So I guess it's ironic that today the conventional wisdom is that, outside the data centre walls, IP must reign supreme, while SNA is allowed within the data centre walls. > While in POK, she created "peer-coupled" shared data architecture ... some past posts http://www.garlic.com/~lynn/submain.html#shareddata If you have something useful to say I'd be obliged if you would write a suitable synopsis on the spot rather than obliging endless - and, on the record of this reference, very likely fruitless - browsing elsewhere. > Somewhat related recent post mentioning working on PU4/PU5 emulation product .... that carried RUs in real networking environment ... Can't resist a dig, eh? Incidentally using "PU" to refer to SNA nodes is likely to take you down the slippery slope to describing a type 2.1 node as a "PU". Equating the "PU" to the "node" is very early, and necessarily "subarea", SNA. > ... (but converted at boundaries when talking to real pu5/vtam host) http://www.garlic.com/~lynn/2009k.html#70 An inComplete History Of Mainframe Computing > above references this decade old post ... which includes part of project presentation that I gave at fall86 SNA architecture review board meeting in Raleigh http://www.garlic.com/~lynn/99.html#67 This looked intriguing so despite decrying having to look elsewhere, I took a peek. It's either very poorly expressed or rubbish! There's talk of implementing the subarea SNA function in a Series/1 and supposedly in a manner superior to VTAM and NCP. It is said that the Series/1 incorporates both VTAM (type 5 node) and NCP (type 4 node) function. The nonsense here is that, if your node implements type 5 node function, there's no need whatsoever at all to implement type 4 node function since type 4 node function is a subset of type 5 node function. Incidentally, implementing the function of a type 5 node - which necessarily includes boundary support in case that's the aspect of the type 4 node function that is supposed to be the preserve of the type 4 node - in a Series/1 would be/have been an interesting project. Had it been offered in conjunction with the "Communications Management Configuration" concept of around 1983 - IIRC - I could see it getting off the ground - and, as far as I can tell from the references - the dates match! It was about this point that I discovered that this post and probably many others to which we are perpetually redirected are "sour grapes" over not having had alternative ideas to the SNA implementations of the past taken up. And these "sour grapes" are polluting the discussions that matter today. It's because we have this pervasive anti-SNA bigotry that vendors of unnecessary products supposedly correcting SNA deficiencies get so much oxygen. > as an aside ... the internal network ... which wasn't SNA ... was larger than the arpanet/internet from just about the beginning until possibly late-85 or early-86 http://www.garlic.com/~lynn/subnetwork.html#internalnet This reference is useless. It's just a list of other references - and to add insult to injury - this very post has been added at the end!!! > post mentioning the 1000th node (on the internal network) in 1983 (83 was when the arpanet/internet was passing 255 hosts) http://www.garlic.com/~lynn/2006k.html#8 As I suspected - and the reason for checking that useless previous reference - the internal network is the IBM VM nodes linked, typically, with point-to-point BSC links. It was established before SNA expanded beyond the "dumb terminal control infrastructure". The fact that it was not based on SNA is purely down to dates, "If it ain't broke ..." and the fact that the operating system preferred for IBM's internal business was VM. VM VTAM didn't appear until 1985. I see another post from "garlic.com" has appeared in this thread. Oh dear! Chris Mason [1] Since Anne is a lady's name and there are references to "my wife". [2] I recall teaching a Belgian government person whose department was set on installing the IBM OSI products and, additionally, because the class finished early, showing how to install all of them together on the same system - a feat which was taxing some IBM departments with the mission to support the OSI products. [3] I saw a TV program earlier today where a garlic grower recommended Moldovan garlic as the most pungent! I sure some readers will appreciate the recommendation! On Sun, 9 Aug 2009 11:57:15 -0400, Anne & Lynn Wheeler <l...@garlic.com> wrote: >chrisma...@belgacom.net (Chris Mason) writes: >> There is no universal SNA network - as some in IBM imagined could be >> created in the early '80s - and so the access to these supposedly >> vulnerable VTAM systems is going to be via the universal IP >> network.[1] Thus one of the protocols whereby the IP network is >> suborned to serve as a logical link in the SNA network will be used. > >SNA isn't a networking infrastructure, it is large closed dumb terminal >control infrastructure. It is even more restrictive than OSI ... which >also wasn't an open infrastructure. SNA lacked both a network layer as >well as a internetworking layer ... while OSI had a network layer >... but also lacked an internetworking layer. The internetworking layer >(found in IP) was necessary for creating an open infrastructure (as a >layer that would internetwork networks). The "universal" SNA was on par >with government GOSIP mandates that the internet was to eliminated and >replaced with OSI (which never happened, I've frequently asserted >because OSI lacked internetworking layer ... even tho it was slightly >better than SNA by actually having a network layer). > >The closest (with a networking layer) that might be claimed for SNA >might be APPN ... but the original APPN announcement was vetoed by the >SNA organizaton ... after 6-8 weeks it was finally announced, but the >announcement letter was carefully rewritten to avoid implying any >relationship between APPN and SNA. We would periodically hassle the >person responsible for APPN to stop playing around with internal stuff >and come work on real networking (APPN specification was AWP164). > >Back in the early days of SNA ... my wife was co-author of >"peer-to-peer" networking (only when SNA had co-opted the term >"networking" ... was it necessary to qualify specification >"peer-to-peer"). This was (internal specification) AWP39 ... and >possibly SNA organization viewed it as competition (even tho SNA had >nothing to do with networking). > >Later when she had been con'ed into going to POK to be in charge of >loosely-coupled architecture ... she had lots of battles with the SNA >organization. Eventually there was a (temporary) truce where she was >allowed to do anything she wanted within the perimeter of the datacenter >walls ... but SNA had to be used anytime the datacenter walls were crossed. >While in POK, she created "peer-coupled" shared data architecture >... some past posts >http://www.garlic.com/~lynn/submain.html#shareddata > >which, except for IMS hot-standby, saw very little uptake until sysplex. > >Somewhat related recent post mentioning working on PU4/PU5 emulation >product .... that carried RUs in real networking environment (but >converted at boundaries when talking to real pu5/vtam host) >http://www.garlic.com/~lynn/2009k.html#70 An inComplete History Of Mainframe Computing > >above references this decade old post ... which includes part of >project presentation that I gave at fall86 SNA architecture review >board meeting in Raleigh >http://www.garlic.com/~lynn/99.html#67 > >as an aside ... the internal network ... which wasn't SNA ... was larger >than the arpanet/internet from just about the beginning until possibly >late-85 or early-86 >http://www.garlic.com/~lynn/subnetwork.html#internalnet > >post mentioning the 1000th node (on the internal network) in 1983 (83 >was when the arpanet/internet was passing 255 hosts) >http://www.garlic.com/~lynn/2006k.html#8 > >above also lists internal datacenters/locations having one or more >new/added networking nodes during 1983. > >-- >40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
