Talk:Systems Network Architecture

From Wikipedia, the free encyclopedia

Demise of SNA

The demise of SNA has always been predicted but will not be till IBM says so. — Preceding unsigned comment added by Askjva (talkcontribs) 04:06, 31 August 2002‎ UTC

Credit card numbers begin with an SNA routing sequence?

From the article:

The first numbers of your credit card is usually a SNA routing sequence.

Really? Can we have a cite for this? — Preceding unsigned comment added by The Anome (talkcontribs) 01:47, 4 September 2002‎

On a SNA based VISANET Take a TranScan a PC-based intelligent protocol monitor and analyzer designed to support Credit Card, Debit Card, Bank Card and Financial Transaction Processors press B to show message routing and usually it is your credit card number
ASKJVA  Preceding unsigned comment added by Askjva (talkcontribs) 04:07, 5 November 2002 (UTC (UTC)
Possibly for some definition of message routing routing that has nothing to do with SNA, but routing in an SNA network is controlled by identifying the sending and receiving logical units, not with a routing sequence. Routing decisions are made by consulting tables in intermediate nodes. Try a protocol analyzer that breaks out the header fields in the SNA Request/Response (RR) units rather than presenting the financial data. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:24, 17 October 2011 (UTC)
A basic feature of SNA is providing a transparent end-to-end communications channel that makes the application independent from the implementation of the networking infrastructure. In the Internet era this seems utterly obvious, but in the communication "systems" of the 1960s it was not. SNA takes care of network routing, applications may implement specific application routing.  Preceding unsigned comment added by Rbakels (talkcontribs) 09:28, 14 March 2014 (UTC)

SNA client access for OS/400 no longer supported

2003-sep-13. Starting from version 5.2 of IBM OS400, SNA for client-access is no longer supported — Preceding unsigned comment added by Juky (talkcontribs) 14:48, 13 September 2003‎

SNA in System/3x and {AS/400, iSeries, System i, whatever it's called these days}

This article should mention the use of SNA/SDLC in the IBM minicomputers. The S/34 only supported the 5250 terminal protocol (LU7). The S/36 first implemented APPC, followed by APPN, which was quite robust. It allowed full peer-to-peer networking without additional equipment and simple management. — Preceding unsigned comment added by 190.27.215.37 (talk) 03:33, 24 November 2011 (UTC)

The article does mention it; in IBM Systems Network Architecture#Logical unit types, it says
SNA defines several kinds of devices, called Logical Unit types:
...
  • LU7 provides for sessions with IBM 5250 terminals.
The primary ones in use are LU1, LU2, and LU6.2 (an advanced protocol for application to application conversations).
Within SNA there are two types of data stream to connect local display terminals and printers; there is the 3270 data stream mainly used by mainframes (zSeries family) and the 5250 data stream mainly used by minicomputers/servers such as the S/36, S/38, and AS/400 (now System i).
Starting from version 5.2 of OS/400, SNA for client-access is no longer supported.
Perhaps it should say more; if so, go ahead and make it do so. Guy Harris (talk) 08:36, 24 November 2011 (UTC)

Advantages and Disadvantages

I have added this section to replace the original second paragraph. The original paragraph didn't make any sense to me. The article could use a paragraph on writing applications to use SNA/VTAM (particularly to communicate with other programs). Said paragraph should follow the enumeration of LU types. Rdmoore6 19:29, 18 January 2006 (UTC)

I'm not a guru, but didn't SNA use one UCB for the attachment of a controller to the host, while Bisync used a UCB per line attached to the 270x? This sounds like an advantage. Peter Flass (talk) 01:43, 6 September 2012 (UTC)
Channel attached SNA controllers used the same addresses for all SNA traffic. Some of them supported multiple channel attachments for, e.g., performance. The term "UCB" is a software concept that has nothing to do with SNA and is not synonymous with address.
One complication is Partitioned Emulator Program (PEP), in which the same controller ran both NCP and the Emulator Program (EP) (as an 270x replacement); the latter has its own block of I/O addresses, normally on a different channel from those used by the NCP proper. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:41, 7 September 2012 (UTC)

It seems to me that one big advantage is that centralized control made it much more difficult to spoof addresses or hack into the network compared to TCP/IP, but I'd rather someone more knowledgeable phrase this better. Peter Flass (talk) 21:39, 1 April 2016 (UTC)

Network Control Program

I decided not to make Network Control Program a wiki link. Problem is that existing article describes the ARPANET NCP and says nothing about IBM's use of the same term in SNA.Rdmoore6 19:41, 18 January 2006 (UTC)

Linked to IBM Network Control Program. Philcha 16:09, 19 October 2007 (UTC)

Objectives of SNA; Principal components and technologies

I've added these 2 sections. "Objectives of SNA" deals mainly with the commercial aspects, including how "Dark Ages" data communications was before SNA and X.25 - something modern non-specialist readers will not understand if they are not told very plainly.

Can anyone provide refs for them? I was an IBM employee at the time (my last project for IBM was SNA-related) and have summarised internal IBM presentations (omitting a lot of details which would confuse general readers), but have no references I can cite.Philcha 16:01, 19 October 2007 (UTC)

I was an IBM employee too (from 1974). I guess the present text overemphasizes IBMs commercial interest. In addition, if confuses IBMs drive for "online computing" with the promotion of SNA. IBM in the 1970s had no serious competitors, in the sense that IBM customers were unlikely to move to a different vendor. IBMs main "competitor" was the inertia of the market, of customers to adopt new technologies such as "online computing" (younger people may have great difficulty in imagining a computer without screens!) Just one of the inhibitors to implement large scale online computing was the proliferation of communications software (BTAM, TCAM, QTAM, VTAM) and protocols (2780, 3270 and may more), which often were not transparent to the application. SNA was innovative that it considered the network a system by itself, a common resource in a company. no, I am not idealizing SNA. It was a complicated way to simplify things, and some of the objectives (liek offloading mainframes by front-end processing) siply did not materialize. Rbakels (talk) 09:46, 14 March 2014 (UTC)

Now, six years later, a different aspect comes to my mind: the layered SNA communications protocol (also) was a reaction to the Open Systems Interconnect endeavour of the International Standards Organization, who felt the need to standardize computer communications. So to some extent, the purpose of SNA was competitive. However, OSI never became a success apart from some niches (probably due to fundamental shortcomings of "committee design"). SNAs true competitor became Internet (TCP/IP protocols). Remarkably, those protocols are as least as old as SNA, but for many years they were not considered a serious alternative for the business environment - nor a competitor for SNA.Rbakels (talk) 11:49, 15 December 2020 (UTC)
According to Systems Network Architecture, "Systems Network Architecture (SNA) is IBM's proprietary networking architecture, created in 1974."
According to OSI model, "Beginning in 1977, the International Organization for Standardization (ISO) conducted a program to develop general standards and methods of networking. A similar process evolved at the International Telegraph and Telephone Consultative Committee (CCITT, from French: Comité Consultatif International Téléphonique et Télégraphique). Both bodies developed documents that defined similar networking models. The OSI model was first defined in raw form in Washington, DC in February 1978 by Hubert Zimmermann of France and the refined but still draft standard was published by the ISO in 1980."
It seems unlikely that the layered SNA communications protocols (plural), created in 1974, were a reaction to a project that began three years after 1974. Guy Harris (talk) 11:57, 15 December 2020 (UTC)

LU type pertains to session, not to terminal

The LU type pertains to an LU-LU session, not the actual LU. As an expample, it was common for the same printer to be in an LU1 session with one application and an LU3 session with a different application. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:40, 16 November 2010 (UTC)

Line sharing prior to SNA

The ability to share a communications line between applications goes all the way back to QTAM. The ability to share a line between TSO and another application is as old as TSO; it started with TCAM. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:53, 20 November 2010 (UTC)

S/360 and S/370 I/O

Error checking in SDLC and HDLC

Modem speeds prior to SNA

History of SNA

Dial-up speeds in the 1970s

Status of 3770

References for protocol details?

"Advanced Communication Function"

Protocol elements

Related Articles

Wikiwand AI