Talk:Systems Network Architecture

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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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

The IBM System/360 and System/370 did not act as controllers for peripherals and were not limited to 16 I/O devices per channel. An I/O channel connected to control units, which in turn connected to peripherals. In the case of DASD, tape and telecommunications, it was normal for one controller to connect to or include multiple peripherals.

Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:05, 20 November 2010 (UTC)

In System/360 and early (large) System/370 models, the channels where separate devices as well. Rbakels (talk) 09:31, 14 March 2014 (UTC)

Error checking in SDLC and HDLC

SDLC and HDLC did not use an ECC; they used a simple Cyclic redundancy check (CRC). Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:16, 20 November 2010 (UTC)

This is better than SLIP, which used nothing. If you have a known, fixed, frame length you can calculate a table of values to reconstruct the original data from the CRC value (of course assuming your CRC transmitted correctly which is pretty silly)... — Preceding unsigned comment added by 203.214.89.130 (talk) 12:05, 28 November 2012 (UTC)

And what if, as I think is the case in most if not all uses of SDLC/HDLC (including SDLC in SNA), you don't have a known, fixed, frame length? Guy Harris (talk) 12:04, 15 December 2020 (UTC)

Modem speeds prior to SNA

Dial-up modems faster than 300 bps were available in 1962, well before SNA. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:31, 20 November 2010 (UTC)

There may have been faster leased-line modems in 1962, but the Bell 103 was the fastest dialup modem in 1962, at up to 300 bps, but perhaps most commonly used with Teletype equipment at up to 110 bps. The next improvement in dialup rates was the Bell 202, which offered dialup rates up to 1200bps half-duplex, with a 75 bps reverse channel. I can't find a reference for the date of introduction of the 202, but I don't think it was before 1964. --Brouhaha (talk) 19:38, 2 October 2011 (UTC)

From Modem:

In the summer of 1960, the name Data-Phone was introduced to replace the earlier term digital subset. The 202 Data-Phone was a half-duplex asynchronous service that was marketed extensively in late 1960. In 1962, the 201A and 201B Data-Phones were introduced. They were synchronous modems using two-bit-per-baud phase-shift keying (PSK). The 201A operated half-duplex at 2,000 bit/s over normal phone lines,

Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:36, 3 October 2011 (UTC)

Thanks for pointing that out. I believe the years claimed in that article are wrong, and will add citation-needed tags to it. --Brouhaha (talk) 23:48, 6 October 2011 (UTC)

History of SNA

While IBM initially only supported SNA in VTAM, they later added SNA support to TCAM 10. Also, as part of the Advanced Communications Function (ACF) announcement they added Multi-System Network Facility (MSNF) to ACF/TCAM and ACF/VTAM. MSNF, APPN and MSI each altered the way routing was done in SNA. In particular, MSNF supported connecting two mainframes with a channel-to-channel adapter (CTCA), but communication line interconnection (remote) was also supported).

Also, should I add any of the relevant manuals to the article? Some are brief summaries and some are highly technical. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:55, 17 October 2011 (UTC)

ACF/VTAM was historical in the sense that it was the first instance of systems software that was not distributed free of charge by IBM. This is sometimes attributed to anti-trust issues, but those predeate the announcement of ACF/VTAM by many years. The actual reason was the advent of "plug compatible" computers. Originally, IBM software would only run on IBM computers so there was no point in charging it separately, but providing free IBM software for non-IBM computers was not an attractive business for IBM. Rbakels (talk) 09:36, 14 March 2014 (UTC)

Dial-up speeds in the 1970s

Dial-up connection speed was limited to 300 bits per second mainly because faster modulation schemes had not yet been implemented. In those days, a transmissions were at one bit per baud. It was better modulation schemes, which allowed multiple bits per symbol, that provided increased speeds on the same dial-up line.

Also, until the 1968 Carterfone decision, any equipment attached to the public switched telephone network had to be approved by the carrier, i.e., AT&T. And AT&T only supplied 300 bps modems. — Preceding unsigned comment added by 71.191.134.57 (talk) 19:05, 3 April 2012 (UTC)

POTS (PSTN what?) was frequency limited 300 to 3000 Hertz (notable was women with higher pitched voices had communication issues, often poor response at high end). ISDN used to connect to local distribution was 8-16 8KHz data channels to each phone line (3KHz and Nyquist limitations). When I did Tech Support in 1996+ I would get customers in Eastern Washington, Florida panhandle et al that had no touch tone, only pulse dialing. In 1994 a customer returned a modem I installed because ADP would not accept connections faster than 1200bps. In the 90's USWest (now Verizon) upgraded Arizona to a purposely limited 9600bps. Note that most credit card authentication devices contain 300bps modems: the 256 bytes on the magnetic stripe can be processed faster than the time for a faster modem can negotiate a connection (that and most cell and Sat phones had limited bandwidth at 1G or 2G technologies, limited support for Cellular Packet Data). When I sold phone equipment in 1979 (in Seattle), phone company would disconnect customer equipment claiming it was defective and threatening customers not using GTE/USWest equipment. PSTN refers to the Telco infrastructure (c.f ISDN at the time), POTS refers to the customer end: the 48volt 50mA on the red and green wires that powers the carbon microphone and dynamic earpiece. In the 80's, I had a 1200bps modem that fit over a phone handset (not many motels had customer accessible phone jacks let alone ethernet) and not all phone lines would accept the signal (even though couldn't tell from voice quality.) Shjacks45 (talk) 09:37, 27 June 2013 (UTC)

Women with high pitched voices had no problems in making phone calls: the "high C" used in some opera repertoire relates to 10 1046 Hz. Rbakels (talk) 11:56, 15 December 2020 (UTC)

By the 1980's you could get 2400 bps over an acoustic coupler and the 208B 4800 bps modem was bog common in the mainframe world. I'm aware of faster speeds for dialup in the 1980's, but the were too expensive for the sites that I worked at.

Re the acronyms: POTS is Plain old telephone service and PSTN is Public switched telephone network. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:59, 15 July 2013 (UTC)

I recall that as a rule of thumb, 2400 bps was the maximum for dial-up lines and 9600 bps for fixed lines in the 1970s. For modem developers, it always was a frustration that the Shannon theorem predicted the possibility much higher speeds than they were actually able to achieve. In the early 1980s, IBM developed really faster modems, using advanced algoritims (Trellis). But this has nothing to do with SNA. Rbakels (talk) 09:52, 14 March 2014 (UTC)

That may have been true for asynchronous modems; it certainly wasn't true for synchronous modems. Not only did the Bell 208B run at 4800 bps on a dial line in the 1970's, but ITU approved ITU-T Recommendation V.27 in 1972; my recollection is that the 208B was available in the 1960's.Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:35, 14 March 2014 (UTC)

Status of 3770

To answer the question of whether the 3770 is related to the 2780 and 3780, no, it is not. However, there is no separate article on the 3770 and the 2780 article does discuss it, so the link to that article is appropriate unless and until somebody splits the 3770 off into a separate article. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:47, 27 June 2012 (UTC)

Unfortunately there isn't much 3770 info online (yet). Hopefully there'll be more in a while. Peter Flass (talk) 14:02, 27 June 2012 (UTC)

www.3770-emulation.com/‎ or en.wikipedia.org/wiki/IBM_2780/3780‎ Shjacks45 (talk) 09:46, 27 June 2013 (UTC)

Introduction to IBM 3770 SNA/RJE Communications does give some details, although the reference to emulation is incorrect. However, IBM 2780/3780‎ is the article about which the question was originally asked. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:32, 27 June 2013 (UTC)

References for protocol details?

I added some references to the article, but did not cite the manuals for protocol details/ Would those be TMI, or is it reasonable to add them as well? E.g.,

• IBM (June 1989), Systems Network Architecture Formats (PDF), Eleventh Edition, IBM, GA27-3136-10
• IBM (April 1981), Systems Network Architecture - Sessions Between Logical Units (PDF), Third Edition, IBM, GC20-1868-2
• IBM (December 1979), Systems Network Architecture - Introduction to Sessions between Logical Units (PDF), Third Edition, IBM, GC20-1869-2
• IBM (June 1993), Systems Network Architecture: Transaction Programmer's Reference Manual for LU Type 6.2, Sixth Edition, IBM, GC30-3084-05
• IBM (December 1996), Systems Network Architecture Type 2.1 Node Reference, Fifth Edition, IBM, SC30-3422-04
• IBM (October 1996), Systems Network Architecture LU 6.2 Reference: Peer Protocols, Third Edition, IBM, SC31-6808-02

Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:40, 17 July 2013 (UTC)

I'd say that if the article gives those protocol details, it's appropriate to give citations for those details. Guy Harris (talk) 21:24, 17 July 2013 (UTC)

The article currently does not give those details. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:58, 19 July 2013 (UTC)

Then they wouldn't be references. They might, however, be worth including in "External links" or "Further details" or something such as that. Guy Harris (talk) 21:38, 19 July 2013 (UTC)

"Advanced Communication Function"

The article associates "Advanced Communication Function" with SNA. That is not correct. There was SNA before ACF.

Initially, the mainframe SNA software was called just VTAM, and it was delivered free of charge with the operating system software, like all IBM systems software at the time. The reason was that IBM software ran only on IBM hardware, so the price was effectively included in the hardware price.

With the advent of "plug compatible" computers, computers made by other manufacturers such as Amdahl that ran IBM software, there was a reason to charge systems software separately. The first systems software packages charged separately were VTAM and NCP, now called ACF/VTAM and ACF/NCP. Only later, complete operating systems were charged, like MVS and VSE.

ACF/VTAM was announced in 1976 and shipped in 1978. Rbakels (talk) 11:35, 15 December 2020 (UTC)

Protocol elements

The article covers network addressable units, e.g., SSCP, but it does not discuss, e.g., the structure and types of packets, the types of data flow, the mechanics of initiating and terminating sessions. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:45, 13 December 2021 (UTC)