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

Reply via email to