Systems Network Architecture - Versionsgeschichte

Neutronstar2 am 22. Juni 2023 um 10:08 Uhr

2023-06-22T10:08:05Z

← Nächstältere Version		Version vom 22. Juni 2023, 12:08 Uhr
Zeile 38:		Zeile 38:
	Der technische Fortschritt führte im Jahre [[1985]] zur Vorstellung des „neuen SNA“: [[Advanced Peer-to-Peer Networking]] (APPN) löste die Abhängigkeit von einem zentralen Steuerpunkt auf dem Mainframe auf. Entsprechend leistungsfähige Hardware konnte nun direkt SNA-Verbindungen auf- und abbauen. Hierzu wurde die Physical Unit des Typs 2.0 um die erforderliche Routing-Funktionalität, die bislang Mainframe und Vorrechner übernommen hatten, erweitert und erhielt die Bezeichnung PU Type 2.1.		Der technische Fortschritt führte im Jahre [[1985]] zur Vorstellung des „neuen SNA“: [[Advanced Peer-to-Peer Networking]] (APPN) löste die Abhängigkeit von einem zentralen Steuerpunkt auf dem Mainframe auf. Entsprechend leistungsfähige Hardware konnte nun direkt SNA-Verbindungen auf- und abbauen. Hierzu wurde die Physical Unit des Typs 2.0 um die erforderliche Routing-Funktionalität, die bislang Mainframe und Vorrechner übernommen hatten, erweitert und erhielt die Bezeichnung PU Type 2.1.

	Inzwischen ([[2009]]) sind die Vorrechner (PU 4) Geschichte; die Verbindung von ~~[[VTAM]]s~~ (PU 5) untereinander, und mit PUs 2.1, erfolgt heute mittels Internetprotokoll, genauer durch UDP-Tunnel (siehe [[Tunnel (Rechnernetz)]]). Diese Technologie ist seit etwa dem Jahr 2000, seit [[OS/390]] Release 2.6 praxistauglich und unter dem Namen Enterprise Extender bekannt.		Inzwischen ([[2009]]) sind die Vorrechner (PU 4) Geschichte; die Verbindung von VTAMs (PU 5) untereinander,# und mit PUs 2.1 erfolgt heute mittels Internetprotokoll, genauer durch UDP-Tunnel (siehe [[Tunnel (Rechnernetz)]]). Diese Technologie ist seit etwa dem Jahr 2000, seit [[OS/390]] Release 2.6 praxistauglich und unter dem Namen Enterprise Extender bekannt.

	== Literatur ==		== Literatur ==

Kolja21: /* Weblinks */ Abrufdatum nur bei Einzelnachweis

2023-02-12T02:30:35Z

Weblinks: Abrufdatum nur bei Einzelnachweis

← Nächstältere Version		Version vom 12. Februar 2023, 04:30 Uhr
Zeile 48:		Zeile 48:

	== Weblinks ==		== Weblinks ==
	* [http://bitsavers.trailing-edge.com/pdf/ibm/sna/GC30-3073-0_SNA_Technical_Overview_Mar82.pdf Systems Network Architecture] (abgerufen am 4. August 2017)		* [http://bitsavers.trailing-edge.com/pdf/ibm/sna/GC30-3073-0_SNA_Technical_Overview_Mar82.pdf Systems Network Architecture] <!-- (abgerufen am 4. August 2017) -->
	* [http://castle.eiu.edu/a_illia/cis3200/Notes/MIS3200Class4.pdf Network Architecture Models] (abgerufen am 4. August 2017)		* [http://castle.eiu.edu/a_illia/cis3200/Notes/MIS3200Class4.pdf Network Architecture Models] <!-- (abgerufen am 4. August 2017) -->
	* [https://scadahacker.com/library/Documents/White_Papers/Juniper%20-%20Architecture%20for%20Secure%20SCADA%20and%20Distributed%20Control%20System%20Networks.pdf ~~ARCHITECTURE~~ ~~FOR~~ ~~SECURE~~ SCADA ~~AND~~ ~~DISTRIBUTED~~ ~~CONTROL~~ ~~SYSTEM~~ ~~NETWORKS~~] (abgerufen am 4. August 2017)		* [https://scadahacker.com/library/Documents/White_Papers/Juniper%20-%20Architecture%20for%20Secure%20SCADA%20and%20Distributed%20Control%20System%20Networks.pdf Architecture for Secure SCADA and Distributed Control System Networks] <!-- (abgerufen am 4. August 2017) -->

	{{Normdaten\|TYP=s\|GND=4181707-2}}		{{Normdaten\|TYP=s\|GND=4181707-2}}

Bildungsbürger: Linkfix mit AWB

2020-10-16T09:58:49Z

Linkfix mit AWB

← Nächstältere Version		Version vom 16. Oktober 2020, 11:58 Uhr
Zeile 5:		Zeile 5:
	== Aufbau ==		== Aufbau ==
	=== PU ===		=== PU ===
	Die Komponenten im SNA-Netzwerk werden in [[~~Netzknoten\|~~Netzwerkknoten]]-Typen klassifiziert; in der SNA-Terminologie heißen diese ''Physical Units (PUs)''. Diese Netzwerkknoten werden durch eine entsprechende Definition auf dem Mainframe derart miteinander verknüpft, dass zwischen ihnen Verbindungen (Sessions) auf- und abgebaut werden können.		Die Komponenten im SNA-Netzwerk werden in [[Netzwerkknoten]]-Typen klassifiziert; in der SNA-Terminologie heißen diese ''Physical Units (PUs)''. Diese Netzwerkknoten werden durch eine entsprechende Definition auf dem Mainframe derart miteinander verknüpft, dass zwischen ihnen Verbindungen (Sessions) auf- und abgebaut werden können.

	Folgende Physical Unit-Typen sind definiert:		Folgende Physical Unit-Typen sind definiert:
Zeile 17:		Zeile 17:
	Der Verwaltungsbereich einer PU Type 5 wird als „Domäne“ bezeichnet, der Verwaltungsbereich einer PU Type 4 als Untermenge der Domäne heißt „Subarea“.		Der Verwaltungsbereich einer PU Type 5 wird als „Domäne“ bezeichnet, der Verwaltungsbereich einer PU Type 4 als Untermenge der Domäne heißt „Subarea“.

	Die Physical Units dienen einzig der Steuerung von Verbindungen. Eine Kommunikation mit einem Anwender ist hiermit noch nicht gegeben. Hierfür stellen Physical Units des Typs 2(.1) eine weitere Schnittstelle zur Verfügung; im SNA-Sprachgebrauch heißt diese ''Logical Unit (LU)''. Im ursprünglichen Ansatz von SNA („klassisches SNA“, „Subarea-SNA“) konnte eine einzelne Logical Unit zu einem bestimmten Zeitpunkt genau eine Verbindung, eine LU-LU-Session, zu einem Anwendungsprogramm auf dem Mainframe aufbauen.		Die Physical Units dienen einzig der Steuerung von Verbindungen. Eine Kommunikation mit einem Anwender ist hiermit noch nicht gegeben. Hierfür stellen Physical Units des Typs 2(.1) eine weitere Schnittstelle zur Verfügung; im SNA-Sprachgebrauch heißt diese ''Logical Unit (LU)''. Im ursprünglichen Ansatz von SNA („klassisches SNA“, „Subarea-SNA“) konnte eine einzelne Logical Unit zu einem bestimmten Zeitpunkt genau eine Verbindung, eine LU-LU-Session, zu einem Anwendungsprogramm auf dem Mainframe aufbauen.

	=== LU ===		=== LU ===
Zeile 36:		Zeile 36:
	Lange vor dem [[OSI-Modell]] für die Organisation der Kommunikationstechnik stellte SNA bereits eine in sich geschlossene Architektur für ein Computernetzwerk zur Verfügung.		Lange vor dem [[OSI-Modell]] für die Organisation der Kommunikationstechnik stellte SNA bereits eine in sich geschlossene Architektur für ein Computernetzwerk zur Verfügung.

	Der technische Fortschritt führte im Jahre [[1985]] zur Vorstellung des „neuen SNA“: [[Advanced Peer-to-Peer Networking]] (APPN) löste die Abhängigkeit von einem zentralen Steuerpunkt auf dem Mainframe auf. Entsprechend leistungsfähige Hardware konnte nun direkt SNA-Verbindungen auf- und abbauen. Hierzu wurde die Physical Unit des Typs 2.0 um die erforderliche Routing-Funktionalität, die bislang Mainframe und Vorrechner übernommen hatten, erweitert und erhielt die Bezeichnung PU Type 2.1.		Der technische Fortschritt führte im Jahre [[1985]] zur Vorstellung des „neuen SNA“: [[Advanced Peer-to-Peer Networking]] (APPN) löste die Abhängigkeit von einem zentralen Steuerpunkt auf dem Mainframe auf. Entsprechend leistungsfähige Hardware konnte nun direkt SNA-Verbindungen auf- und abbauen. Hierzu wurde die Physical Unit des Typs 2.0 um die erforderliche Routing-Funktionalität, die bislang Mainframe und Vorrechner übernommen hatten, erweitert und erhielt die Bezeichnung PU Type 2.1.

	Inzwischen ([[2009]]) sind die Vorrechner (PU 4) Geschichte; die Verbindung von [[VTAM]]s (PU 5) untereinander, und mit PUs 2.1, erfolgt heute mittels Internetprotokoll, genauer durch UDP-Tunnel (siehe [[Tunnel (Rechnernetz)]]). Diese Technologie ist seit etwa dem Jahr 2000, seit [[OS/390]] Release 2.6 praxistauglich und unter dem Namen Enterprise Extender bekannt.		Inzwischen ([[2009]]) sind die Vorrechner (PU 4) Geschichte; die Verbindung von [[VTAM]]s (PU 5) untereinander, und mit PUs 2.1, erfolgt heute mittels Internetprotokoll, genauer durch UDP-Tunnel (siehe [[Tunnel (Rechnernetz)]]). Diese Technologie ist seit etwa dem Jahr 2000, seit [[OS/390]] Release 2.6 praxistauglich und unter dem Namen Enterprise Extender bekannt.
Zeile 50:		Zeile 50:
	* [http://bitsavers.trailing-edge.com/pdf/ibm/sna/GC30-3073-0_SNA_Technical_Overview_Mar82.pdf Systems Network Architecture] (abgerufen am 4. August 2017)		* [http://bitsavers.trailing-edge.com/pdf/ibm/sna/GC30-3073-0_SNA_Technical_Overview_Mar82.pdf Systems Network Architecture] (abgerufen am 4. August 2017)
	* [http://castle.eiu.edu/a_illia/cis3200/Notes/MIS3200Class4.pdf Network Architecture Models] (abgerufen am 4. August 2017)		* [http://castle.eiu.edu/a_illia/cis3200/Notes/MIS3200Class4.pdf Network Architecture Models] (abgerufen am 4. August 2017)
	* [https://scadahacker.com/library/Documents/White_Papers/Juniper%20-%20Architecture%20for%20Secure%20SCADA%20and%20Distributed%20Control%20System%20Networks.pdf ARCHITECTURE FOR SECURE SCADA AND DISTRIBUTED CONTROL SYSTEM NETWORKS] (abgerufen am 4. August 2017)		* [https://scadahacker.com/library/Documents/White_Papers/Juniper%20-%20Architecture%20for%20Secure%20SCADA%20and%20Distributed%20Control%20System%20Networks.pdf ARCHITECTURE FOR SECURE SCADA AND DISTRIBUTED CONTROL SYSTEM NETWORKS] (abgerufen am 4. August 2017)

	{{Normdaten\|TYP=s\|GND=4181707-2}}		{{Normdaten\|TYP=s\|GND=4181707-2}}

T-daddy: /* LU */Formulierung verbessert

2020-04-02T23:32:40Z

LU: Formulierung verbessert

← Nächstältere Version		Version vom 3. April 2020, 01:32 Uhr
Zeile 27:		Zeile 27:

	Mit dem Aufkommen von intelligenter Hardware und der Abkehr von „dummen Terminals“ wurde die Funktionalität von Logical Units zunehmend von Software-Lösungen abgelöst, die die ursprünglichen Terminals [[Emulation\|emulierten]].		Mit dem Aufkommen von intelligenter Hardware und der Abkehr von „dummen Terminals“ wurde die Funktionalität von Logical Units zunehmend von Software-Lösungen abgelöst, die die ursprünglichen Terminals [[Emulation\|emulierten]].
	Gleichermaßen erwuchs der Bedarf, auch ~~periphere~~ laufende Programme direkt miteinander über das SNA-Netzwerk kommunizieren zu lassen. Hierzu wurde der bisher nur zwischen Mainframe-Programmen verwendete LU Typ 6.2 ~~eingeführt~~, die Schnittstelle für Erweiterte Programm-zu-Programm-Kommunikation ([[APPC]]). Der wesentliche Unterschied zur LU Type 0 ist, dass LU Typ 6.2 im Gegensatz zum frei definierbaren Format der LU Type 0 eine standardisierte Schnittstelle bereitstellte.		Gleichermaßen erwuchs der Bedarf, auch peripher laufende Programme direkt miteinander über das SNA-Netzwerk kommunizieren zu lassen. Hierzu wurde der bisher nur zwischen Mainframe-Programmen verwendete LU Typ 6.2 ausersehen, die Schnittstelle für Erweiterte Programm-zu-Programm-Kommunikation ([[APPC]]). Der wesentliche Unterschied zur LU Type 0 ist, dass LU Typ 6.2 im Gegensatz zum frei definierbaren Format der LU Type 0 eine standardisierte Schnittstelle bereitstellte.

	Der LU Type 6.2 erlaubt auch den Aufbau von parallelen Verbindungen dieser Logical Unit zu einem oder mehreren Anwendungsprogrammen, die sowohl auf einem Mainframe (PU Typ 5) oder einem peripheren Knoten (PU Typ 2.1) beheimatet sein können.		Der LU Type 6.2 erlaubt auch den Aufbau von parallelen Verbindungen dieser Logical Unit zu einem oder mehreren Anwendungsprogrammen, die sowohl auf einem Mainframe (PU Typ 5) oder einem peripheren Knoten (PU Typ 2.1) beheimatet sein können.

T-daddy: /* LU */Funktionalität und Ansiedlung des LU Typ 6.2 klarer dargestellt.

2020-04-02T23:19:37Z

LU: Funktionalität und Ansiedlung des LU Typ 6.2 klarer dargestellt.

← Nächstältere Version		Version vom 3. April 2020, 01:19 Uhr
Zeile 20:		Zeile 20:

	=== LU ===		=== LU ===
	Aus technischer Sicht handelt es sich bei einer Logical Unit um Hardware (Bildschirm oder Drucker) mit dementsprechend implementiertem Vorrat an Befehlen für die Steuerung einer SNA-Sitzung bis hin zur formatierten Ausgabe am Endgerät. Nach den implementierten Protokollen existieren verschiedene LU-Typen. Die gebräuchlichsten sind:		Aus technischer Sicht handelt es sich bei einer Logical Unit um Hardware (Bildschirm oder Drucker) mit dementsprechend implementiertem Vorrat an Befehlen für die Steuerung einer SNA-Sitzung bis hin zur formatierten Ausgabe am Endgerät, oder eben ein Anwendungsprogramm auf einem Mainframe (PU_Type5). Nach den implementierten Protokollen existieren verschiedene LU-Typen. Die gebräuchlichsten sind:

	* LU Type 2: eine Bildschirm-Datenstation aus der Produktfamilie [[IBM 3270]]		* LU Type 2: eine Bildschirm-Datenstation aus der Produktfamilie [[IBM 3270]]
Zeile 27:		Zeile 27:

	Mit dem Aufkommen von intelligenter Hardware und der Abkehr von „dummen Terminals“ wurde die Funktionalität von Logical Units zunehmend von Software-Lösungen abgelöst, die die ursprünglichen Terminals [[Emulation\|emulierten]].		Mit dem Aufkommen von intelligenter Hardware und der Abkehr von „dummen Terminals“ wurde die Funktionalität von Logical Units zunehmend von Software-Lösungen abgelöst, die die ursprünglichen Terminals [[Emulation\|emulierten]].
	Gleichermaßen erwuchs ~~auch~~ der Bedarf, Programme direkt miteinander über das SNA-Netzwerk kommunizieren zu lassen. Hierzu wurde der ~~neue~~ LU Typ 6.2 eingeführt, die Schnittstelle für Erweiterte Programm-zu-Programm-Kommunikation ([[APPC]]). Der wesentliche Unterschied zur LU Type 0 ~~war~~, dass ~~APPC~~ im Gegensatz zum frei definierbaren Format der LU Type 0 eine standardisierte Schnittstelle bereitstellte.		Gleichermaßen erwuchs der Bedarf, auch periphere laufende Programme direkt miteinander über das SNA-Netzwerk kommunizieren zu lassen. Hierzu wurde der bisher nur zwischen Mainframe-Programmen verwendete LU Typ 6.2 eingeführt, die Schnittstelle für Erweiterte Programm-zu-Programm-Kommunikation ([[APPC]]). Der wesentliche Unterschied zur LU Type 0 ist, dass LU Typ 6.2 im Gegensatz zum frei definierbaren Format der LU Type 0 eine standardisierte Schnittstelle bereitstellte.

	Der LU Type 6.2 ~~erlaubte~~ auch ~~erstmals~~ den ~~parallelen~~ Aufbau von Verbindungen ~~einer einzelnen~~ Logical Unit zu mehreren Anwendungsprogrammen.		Der LU Type 6.2 erlaubt auch den Aufbau von parallelen Verbindungen dieser Logical Unit zu einem oder mehreren Anwendungsprogrammen, die sowohl auf einem Mainframe (PU Typ 5) oder einem peripheren Knoten (PU Typ 2.1) beheimatet sein können.

	== Einsatz ==		== Einsatz ==

HReuter: +Smartquotes

2019-01-20T11:15:08Z

+Smartquotes

Invisigoth67: typo, form

2018-07-24T15:42:05Z

typo, form

← Nächstältere Version		Version vom 24. Juli 2018, 17:42 Uhr
Zeile 41:		Zeile 41:

	== Literatur ==		== Literatur ==
	* Werner Schäfer, Helmut an de Meulen:''Systems Network Architecture''. Addison-Wesley Verlag, München 2007, ISBN 978-0-201-56533-1.		* Werner Schäfer, Helmut an de Meulen: ''Systems Network Architecture.'' Addison-Wesley Verlag, München 2007, ISBN 978-0-201-56533-1.
	* Hugo Schröer, Thomas Stalke: ''Die Netzwerkarchitektur SNA''. Friedrich Vieweg & Sohn, Wiesbaden 1993, ISBN 978-3-322-91564-1.		* Hugo Schröer, Thomas Stalke: ''Die Netzwerkarchitektur SNA''. Friedrich Vieweg & Sohn, Wiesbaden 1993, ISBN 978-3-322-91564-1.
	* Carl A. Sunshine (Hrsg.):''Computer Network Architectures and Protocols''. Second Edition, Plenum Press, New York / London 1989, ISBN 978-1-4612-8093-4.		* Carl A. Sunshine (Hrsg.): ''Computer Network Architectures and Protocols.'' Second Edition, Plenum Press, New York / London 1989, ISBN 978-1-4612-8093-4.
	* Klaus Garbe:''Management von Rechnernetzen''. B. G. Teubner Verlag, Stuttgart 1991, ISBN 978-3-519-02418-7.		* Klaus Garbe: ''Management von Rechnernetzen.'' B. G. Teubner Verlag, Stuttgart 1991, ISBN 978-3-519-02418-7.
	* Gurdeep S. Hura, Mukesh Singhal:''Data and Computer Communications''. Networking and Internetworking, CRC Press LLC, Boca Raton 2001, ISBN 0-8493-0928-X.		* Gurdeep S. Hura, Mukesh Singhal: ''Data and Computer Communications.'' Networking and Internetworking, CRC Press LLC, Boca Raton 2001, ISBN 0-8493-0928-X.

	== Weblinks ==		== Weblinks ==

Aka: Abkürzung korrigiert

2018-03-24T18:20:15Z

Abkürzung korrigiert

← Nächstältere Version		Version vom 24. März 2018, 20:20 Uhr
Zeile 1:		Zeile 1:
	'''Systems Network Architecture''' ('''SNA''') ist eine [[Rechnernetz\|Netzwerkarchitektur]], die von [[IBM]] in den [[1970er]]-Jahren entwickelt und im Jahre [[1974]] vorgestellt wurde. SNA sah eine hierarchische Organisation des Computernetzwerks vor, und die Implementierung setzte einen Großrechner nebst dessen für Netzwerke bestimmter Peripherie voraus. Diese hierarchische Netzwerkorganisation steuerte dann u.a. viele 'dumme' [[Terminal (Computer)\|Terminals]]. Im Gegensatz zur hierarchischen Organisation der SNA gibt es zum Beispiel die dezentral organisierte [[Internetprotokollfamilie]].		'''Systems Network Architecture''' ('''SNA''') ist eine [[Rechnernetz\|Netzwerkarchitektur]], die von [[IBM]] in den [[1970er]]-Jahren entwickelt und im Jahre [[1974]] vorgestellt wurde. SNA sah eine hierarchische Organisation des Computernetzwerks vor, und die Implementierung setzte einen Großrechner nebst dessen für Netzwerke bestimmter Peripherie voraus. Diese hierarchische Netzwerkorganisation steuerte dann u. a. viele 'dumme' [[Terminal (Computer)\|Terminals]]. Im Gegensatz zur hierarchischen Organisation der SNA gibt es zum Beispiel die dezentral organisierte [[Internetprotokollfamilie]].

	Die Systemsoftware, die diese Architektur implementiert, sind [[VTAM]] auf dem [[Mainframe]] und Advanced Communication Function/Network Control Program (NCP) auf den Vorrechnern (Front End Prozessoren), sowie festverdrahtete Bildschirm- und Druckerterminals.		Die Systemsoftware, die diese Architektur implementiert, sind [[VTAM]] auf dem [[Mainframe]] und Advanced Communication Function/Network Control Program (NCP) auf den Vorrechnern (Front End Prozessoren), sowie festverdrahtete Bildschirm- und Druckerterminals.

Pittimann: /* Weblinks */ + 1

2017-08-04T08:20:13Z

Weblinks: + 1

← Nächstältere Version		Version vom 4. August 2017, 10:20 Uhr
Zeile 50:		Zeile 50:
	* [http://bitsavers.trailing-edge.com/pdf/ibm/sna/GC30-3073-0_SNA_Technical_Overview_Mar82.pdf Systems Network Architecture] (abgerufen am 4. August 2017)		* [http://bitsavers.trailing-edge.com/pdf/ibm/sna/GC30-3073-0_SNA_Technical_Overview_Mar82.pdf Systems Network Architecture] (abgerufen am 4. August 2017)
	* [http://castle.eiu.edu/a_illia/cis3200/Notes/MIS3200Class4.pdf Network Architecture Models] (abgerufen am 4. August 2017)		* [http://castle.eiu.edu/a_illia/cis3200/Notes/MIS3200Class4.pdf Network Architecture Models] (abgerufen am 4. August 2017)
			* [https://scadahacker.com/library/Documents/White_Papers/Juniper%20-%20Architecture%20for%20Secure%20SCADA%20and%20Distributed%20Control%20System%20Networks.pdf ARCHITECTURE FOR SECURE SCADA AND DISTRIBUTED CONTROL SYSTEM NETWORKS] (abgerufen am 4. August 2017)

Pittimann: /* Literatur */ der auch

2017-08-04T08:16:48Z

Literatur: der auch

← Nächstältere Version		Version vom 4. August 2017, 10:16 Uhr
Zeile 45:		Zeile 45:
	* Carl A. Sunshine (Hrsg.):''Computer Network Architectures and Protocols''. Second Edition, Plenum Press, New York / London 1989, ISBN 978-1-4612-8093-4.		* Carl A. Sunshine (Hrsg.):''Computer Network Architectures and Protocols''. Second Edition, Plenum Press, New York / London 1989, ISBN 978-1-4612-8093-4.
	* Klaus Garbe:''Management von Rechnernetzen''. B. G. Teubner Verlag, Stuttgart 1991, ISBN 978-3-519-02418-7.		* Klaus Garbe:''Management von Rechnernetzen''. B. G. Teubner Verlag, Stuttgart 1991, ISBN 978-3-519-02418-7.
			* Gurdeep S. Hura, Mukesh Singhal:''Data and Computer Communications''. Networking and Internetworking, CRC Press LLC, Boca Raton 2001, ISBN 0-8493-0928-X.

	== Weblinks ==		== Weblinks ==

← Nächstältere Version		Version vom 20. Januar 2019, 13:15 Uhr
Zeile 1:		Zeile 1:
	'''Systems Network Architecture''' ('''SNA''') ist eine [[Rechnernetz\|Netzwerkarchitektur]], die von [[IBM]] in den [[1970er]]-Jahren entwickelt und im Jahre [[1974]] vorgestellt wurde. SNA sah eine hierarchische Organisation des Computernetzwerks vor, und die Implementierung setzte einen Großrechner nebst dessen für Netzwerke bestimmter Peripherie voraus. Diese hierarchische Netzwerkorganisation steuerte dann u. a. viele ~~'dumme'~~ [[Terminal (Computer)\|Terminals]]. Im Gegensatz zur hierarchischen Organisation der SNA gibt es zum Beispiel die dezentral organisierte [[Internetprotokollfamilie]].		'''Systems Network Architecture''' ('''SNA''') ist eine [[Rechnernetz\|Netzwerkarchitektur]], die von [[IBM]] in den [[1970er]]-Jahren entwickelt und im Jahre [[1974]] vorgestellt wurde. SNA sah eine hierarchische Organisation des Computernetzwerks vor, und die Implementierung setzte einen Großrechner nebst dessen für Netzwerke bestimmter Peripherie voraus. Diese hierarchische Netzwerkorganisation steuerte dann u. a. viele „dumme“ [[Terminal (Computer)\|Terminals]]. Im Gegensatz zur hierarchischen Organisation der SNA gibt es zum Beispiel die dezentral organisierte [[Internetprotokollfamilie]].

	Die Systemsoftware, die diese Architektur implementiert, sind [[VTAM]] auf dem [[Mainframe]] und Advanced Communication Function/Network Control Program (NCP) auf den Vorrechnern (Front End Prozessoren), sowie festverdrahtete Bildschirm- und Druckerterminals.		Die Systemsoftware, die diese Architektur implementiert, sind [[VTAM]] auf dem [[Mainframe]] und Advanced Communication Function/Network Control Program (NCP) auf den Vorrechnern (Front End Prozessoren), sowie festverdrahtete Bildschirm- und Druckerterminals.
Zeile 5:		Zeile 5:
	== Aufbau ==		== Aufbau ==
	=== PU ===		=== PU ===
	Die Komponenten im SNA-Netzwerk werden in [[Netzknoten\|Netzwerkknoten]]-Typen klassifiziert, in der SNA-Terminologie heißen diese ''Physical Units (PUs)''. Diese Netzwerkknoten werden durch eine entsprechende Definition auf dem Mainframe derart miteinander verknüpft, dass zwischen ihnen Verbindungen (Sessions) auf- und abgebaut werden können.		Die Komponenten im SNA-Netzwerk werden in [[Netzknoten\|Netzwerkknoten]]-Typen klassifiziert; in der SNA-Terminologie heißen diese ''Physical Units (PUs)''. Diese Netzwerkknoten werden durch eine entsprechende Definition auf dem Mainframe derart miteinander verknüpft, dass zwischen ihnen Verbindungen (Sessions) auf- und abgebaut werden können.

	Folgende Physical Unit-Typen sind definiert:		Folgende Physical Unit-Typen sind definiert:
Zeile 11:		Zeile 11:
	* PU Type 5, der zentrale Steuerpunkt auf dem Mainframe (''System Services Control Point'')		* PU Type 5, der zentrale Steuerpunkt auf dem Mainframe (''System Services Control Point'')
	* PU Type 4, ein Vorrechner für die Leitungssteuerung		* PU Type 4, ein Vorrechner für die Leitungssteuerung
	* PU Type 3, welcher aus der Dokumentation von SNA schon relativ früh wieder verschwand, nie implementiert wurde und für die ~~"Intelligenz"~~ der Leitung vorgesehen war.		* PU Type 3, welcher aus der Dokumentation von SNA schon relativ früh wieder verschwand, nie implementiert wurde und für die „Intelligenz“ der Leitung vorgesehen war.
	* PU Type 2, später erweitert zur PU Type 2.1, eine Steuereinheit für den Betrieb von Bildschirm- und Druckerterminals		* PU Type 2, später erweitert zur PU Type 2.1, eine Steuereinheit für den Betrieb von Bildschirm- und Druckerterminals
	* PU Type 1, ein standalone-Bildschirm- oder Druckerterminal. Dieser Typ ist heute bedeutungslos.		* PU Type 1, ein standalone-Bildschirm- oder Druckerterminal. Dieser Typ ist heute bedeutungslos.

	Der Verwaltungsbereich einer PU Type 5 wird als ~~'Domäne'~~ bezeichnet, der Verwaltungsbereich einer PU Type 4 als Untermenge der Domäne heißt ~~'Subarea'~~.		Der Verwaltungsbereich einer PU Type 5 wird als „Domäne“ bezeichnet, der Verwaltungsbereich einer PU Type 4 als Untermenge der Domäne heißt „Subarea“.

	Die Physical Units dienen einzig der Steuerung von Verbindungen. Eine Kommunikation mit einem Anwender ist hiermit noch nicht gegeben. Hierfür stellen Physical Units des Typs 2(.1) eine weitere Schnittstelle zur Verfügung, im SNA-Sprachgebrauch heißt diese ''Logical Unit (LU)''. Im ursprünglichen Ansatz von SNA (~~'klassisches~~ ~~SNA'~~, ~~'Subarea~~-~~SNA'~~) konnte eine einzelne Logical Unit zu einem bestimmten Zeitpunkt genau eine Verbindung, eine LU-LU-Session, zu einem Anwendungsprogramm auf dem Mainframe aufbauen.		Die Physical Units dienen einzig der Steuerung von Verbindungen. Eine Kommunikation mit einem Anwender ist hiermit noch nicht gegeben. Hierfür stellen Physical Units des Typs 2(.1) eine weitere Schnittstelle zur Verfügung; im SNA-Sprachgebrauch heißt diese ''Logical Unit (LU)''. Im ursprünglichen Ansatz von SNA („klassisches SNA“, „Subarea-SNA“) konnte eine einzelne Logical Unit zu einem bestimmten Zeitpunkt genau eine Verbindung, eine LU-LU-Session, zu einem Anwendungsprogramm auf dem Mainframe aufbauen.

	=== LU ===		=== LU ===
	Aus technischer Sicht handelt es sich bei einer Logical Unit um Hardware (Bildschirm oder Drucker) mit dementsprechend ~~implementierten~~ Vorrat an Befehlen für die Steuerung einer SNA-Sitzung bis hin zur formatierten Ausgabe am Endgerät. Nach den implementierten Protokollen existieren verschiedene LU-Typen. Die gebräuchlichsten sind:		Aus technischer Sicht handelt es sich bei einer Logical Unit um Hardware (Bildschirm oder Drucker) mit dementsprechend implementiertem Vorrat an Befehlen für die Steuerung einer SNA-Sitzung bis hin zur formatierten Ausgabe am Endgerät. Nach den implementierten Protokollen existieren verschiedene LU-Typen. Die gebräuchlichsten sind:

	* LU Type 2: eine Bildschirm-Datenstation aus der Produktfamilie [[IBM 3270]]		* LU Type 2: eine Bildschirm-Datenstation aus der Produktfamilie [[IBM 3270]]
Zeile 26:		Zeile 26:
	* LU Type 0: frei definiertes Format, vorzugsweise für die Kommunikation zwischen Programmen.		* LU Type 0: frei definiertes Format, vorzugsweise für die Kommunikation zwischen Programmen.

	Mit dem Aufkommen von intelligenter Hardware und der Abkehr von ~~'dummen~~ ~~Terminals'~~ wurde die Funktionalität von Logical Units zunehmend von Software-Lösungen abgelöst, die die ursprünglichen Terminals [[Emulation\|emulierten]].		Mit dem Aufkommen von intelligenter Hardware und der Abkehr von „dummen Terminals“ wurde die Funktionalität von Logical Units zunehmend von Software-Lösungen abgelöst, die die ursprünglichen Terminals [[Emulation\|emulierten]].
	Gleichermaßen erwuchs auch der Bedarf, Programme direkt miteinander über das SNA-Netzwerk kommunizieren zu lassen. Hierzu wurde der neue LU Typ 6.2 eingeführt, die Schnittstelle für Erweiterte Programm-zu-Programm-Kommunikation ([[APPC]]). Der wesentliche Unterschied zur LU Type 0 war, dass APPC im Gegensatz zum frei definierbaren Format der LU Type 0 eine standardisierte Schnittstelle bereitstellte.		Gleichermaßen erwuchs auch der Bedarf, Programme direkt miteinander über das SNA-Netzwerk kommunizieren zu lassen. Hierzu wurde der neue LU Typ 6.2 eingeführt, die Schnittstelle für Erweiterte Programm-zu-Programm-Kommunikation ([[APPC]]). Der wesentliche Unterschied zur LU Type 0 war, dass APPC im Gegensatz zum frei definierbaren Format der LU Type 0 eine standardisierte Schnittstelle bereitstellte.

Zeile 36:		Zeile 36:
	Lange vor dem [[OSI-Modell]] für die Organisation der Kommunikationstechnik stellte SNA bereits eine in sich geschlossene Architektur für ein Computernetzwerk zur Verfügung.		Lange vor dem [[OSI-Modell]] für die Organisation der Kommunikationstechnik stellte SNA bereits eine in sich geschlossene Architektur für ein Computernetzwerk zur Verfügung.

	Der technische Fortschritt führte im Jahre [[1985]] zur Vorstellung des ~~'neuen~~ ~~SNA'~~: [[Advanced Peer-to-Peer Networking]] (APPN) löste die Abhängigkeit von einem zentralen Steuerpunkt auf dem Mainframe auf. Entsprechend leistungsfähige Hardware konnte nun direkt SNA-Verbindungen auf- und abbauen. Hierzu wurde die Physical Unit des Typs 2.0 um die erforderliche Routing-Funktionalität, die bislang Mainframe und Vorrechner übernommen ~~hatte~~, erweitert und erhielt die Bezeichnung PU Type 2.1.		Der technische Fortschritt führte im Jahre [[1985]] zur Vorstellung des „neuen SNA“: [[Advanced Peer-to-Peer Networking]] (APPN) löste die Abhängigkeit von einem zentralen Steuerpunkt auf dem Mainframe auf. Entsprechend leistungsfähige Hardware konnte nun direkt SNA-Verbindungen auf- und abbauen. Hierzu wurde die Physical Unit des Typs 2.0 um die erforderliche Routing-Funktionalität, die bislang Mainframe und Vorrechner übernommen hatten, erweitert und erhielt die Bezeichnung PU Type 2.1.

	Inzwischen ([[2009]]) sind die Vorrechner (PU 4) Geschichte, die Verbindung von [[VTAM]]s (PU 5) untereinander, und mit PUs 2.1, erfolgt heute mittels Internetprotokoll, genauer durch UDP-Tunnel (siehe [[Tunnel (Rechnernetz)]]). Diese Technologie ist seit etwa dem Jahr 2000, seit [[OS/390]] Release 2.6 praxistauglich und unter dem Namen Enterprise Extender bekannt.		Inzwischen ([[2009]]) sind die Vorrechner (PU 4) Geschichte; die Verbindung von [[VTAM]]s (PU 5) untereinander, und mit PUs 2.1, erfolgt heute mittels Internetprotokoll, genauer durch UDP-Tunnel (siehe [[Tunnel (Rechnernetz)]]). Diese Technologie ist seit etwa dem Jahr 2000, seit [[OS/390]] Release 2.6 praxistauglich und unter dem Namen Enterprise Extender bekannt.

	== Literatur ==		== Literatur ==
Zeile 51:		Zeile 51:
	* [http://castle.eiu.edu/a_illia/cis3200/Notes/MIS3200Class4.pdf Network Architecture Models] (abgerufen am 4. August 2017)		* [http://castle.eiu.edu/a_illia/cis3200/Notes/MIS3200Class4.pdf Network Architecture Models] (abgerufen am 4. August 2017)
	* [https://scadahacker.com/library/Documents/White_Papers/Juniper%20-%20Architecture%20for%20Secure%20SCADA%20and%20Distributed%20Control%20System%20Networks.pdf ARCHITECTURE FOR SECURE SCADA AND DISTRIBUTED CONTROL SYSTEM NETWORKS] (abgerufen am 4. August 2017)		* [https://scadahacker.com/library/Documents/White_Papers/Juniper%20-%20Architecture%20for%20Secure%20SCADA%20and%20Distributed%20Control%20System%20Networks.pdf ARCHITECTURE FOR SECURE SCADA AND DISTRIBUTED CONTROL SYSTEM NETWORKS] (abgerufen am 4. August 2017)


	{{Normdaten\|TYP=s\|GND=4181707-2}}		{{Normdaten\|TYP=s\|GND=4181707-2}}


	[[Kategorie:Netzwerkarchitektur]]		[[Kategorie:Netzwerkarchitektur]]