Bundesamt für Sicherheit in der Informationstechnik

M 3.39 Einführung in die zSeries-Plattform

Verantwortlich für Initiierung: Leiter IT

Verantwortlich für Umsetzung: Administrator, Leiter IT

Die zSeries-Architektur ist der Nachfolger der 1964 eingeführten S/360-Architektur und wird bei heutigen Mainframe-Installationen häufig eingesetzt. Die zSeries-Systeme (als Teil von IBMs eServer-Familie) können sowohl für Stapelverarbeitungen und Transaktionen als auch für E-Business-Anwendungen eingesetzt werden.

Zum Betrieb der zSeries-Plattform stehen die Betriebssysteme OS/390 (31 Bit-Architektur) und z/OS (64 Bit-Architektur) zur Verfügung. Da das z/OS-Betriebssystem als Nachfolger von OS/390 gilt, sollte es bei neuen Installationen eingesetzt werden.

Nachfolgende Abschnitte enthalten eine Übersicht über die Komponenten der zSeries-Plattform, sie erheben jedoch keinen Anspruch auf Vollständigkeit. Umfangreiche und detaillierte Informationen sind in der einschlägigen Literatur des Herstellers IBM zu finden (siehe Literaturhinweise am Ende der Maßnahmenbeschreibung).

Das z/OS-Betriebssystem ist in der Maßnahme M 3.40 Einführung in das z/OS-Betriebssystem beschrieben, das Betriebssystem Linux für z/OS in der Maßnahme M 3.41 Einführung in Linux und z/VM für zSeries-Systeme .

Historie

Die Basis für die zSeries-Architektur entstand im Jahr 1964, als IBM die S/360-Architektur entwickelte und einführte. Von Anfang an war es Ziel der Architektur, dass Maschinencode auf allen damaligen und zukünftigen Modellen ohne wesentliche Modifikationen lauffähig sein sollte.

Im Laufe der Zeit erweiterte IBM sukzessiv die S/360-Architektur, wobei sich die Bezeichnung mehrfach änderte, erst zu S/370, danach zu S/390 und jetzt zur aktuellen zSeries. Die wesentlichen Grundlagen der Architektur (z. B. Maschinencode, Register und Adressierung oder auch die Festlegung der Relation zwischen Bit und Byte) wurden jedoch immer beibehalten und gelten heute noch.

Mainframe-Architektur

IBMs Dokumentation z/Architecture Principles of Operations teilt das zSeries-System in die Bestandteile

  • Main Storage,
  • einem oder mehreren Central Processing Units (CPUs),
  • Operator Facilities,
  • einem Channel Subsystem und
  • I/O Devices

auf. Die I/O Devices hängen an sogenannten Control Units (CU), die wiederum am Channel Subsystem hängen.

Die S/390-Architektur entspricht - mit Ausnahme der neuen zSeries-Funktionen - im wesentlichen der zSeries-Architektur. Im Folgenden werden einige Aspekte der z/Architektur dargestellt:

EBCDIC Code

zSeries-Systeme verwenden beim Abspeichern den sogenannten EBCDIC-Code (Extended binary coded decimal interchange code) mit einer Länge von acht Bit, im Gegensatz zu dem bei anderen Rechner-Architekturen verwendeten ASCII-Code (sieben Bit). Kommunizieren Rechner miteinander, die unterschiedliche Formate einsetzen, sind Konvertierungen der Codes erforderlich.

Register

Ein zSeries-Rechner arbeitet mit verschiedenen Registern von 64 Bit Länge (z. B. Kontrollregister oder Mehrzweckregister). Der Instruction Operation Code (IOC) bestimmt, welches Register verwendet wird.

Beim S/390-Rechner sind die Register 32 Bit lang.

Programmverzweigung (Linkage Convention)

Die zSeries-Architektur verwendet beim Aufruf eines Unterprogramms mehrere Mehrzweckregister. Die Verwendung bestimmter Register ist in der Literatur auch als Linkage Convention bekannt.

Alternativ ist die Benutzung eines Linkage Stacks möglich, wofür andere Assembler-Instruktionen zur Verfügung stehen.

Speicherschutz

Ein zusätzlicher Speicherschutz stellt bei der zSeries-Architektur sicher, dass Fehler beim Speicherzugriff weitgehend vermieden werden. Die Hardware teilt den Hauptspeicher in 4 kB große Blöcke auf und vergibt pro Block einen Speicherschutzschlüssel, der bei der späteren Verarbeitung überprüft wird.

Diese Art des Speicherschutzes stellt eine der Stärken des Betriebssystems dar, da Überschreiben fremden Speichers im normalen Problem-Modus weitgehend ausgeschlossen ist.

Ein-/Ausgabe

Der zSeries-Ein-/Ausgabe-Verkehr wird durch ein Channel Subsystem gesteuert. Bis zu 65536 Ein-/Ausgabe-Einheiten können über Steuereinheiten (Control Units) an das Channel Subsystem angeschlossen und mittels Channel Paths mit diesem verbunden werden.

Die einzelnen Anschlüsse werden vom Channel Subsystem als logische Verbindungen (Subchannels) geführt. Sie sind über Channel Paths mit dem Channel Subsystem verbunden.

Operator Facilities

Mit dieser Funktion kann der Systemadministrator, ähnlich der BIOS -Kommunikation beim PC, mit dem zSeries-System in Verbindung treten und Systemanpassungen vornehmen.

Zur Kommunikation dient ein herkömmlicher PC, der an das Service Element angeschlossen ist und als Management Console bezeichnet wird (siehe auch Abschnitt Ein-/Ausgabe - zSeries-Mainframe-Konsolen). Diese Konsole dient ausschließlich der Nutzung durch den Systemadministrator bzw. das Wartungspersonal des Herstellers.

Betriebssystem-Unterstützung

Die z/Architektur unterstützt alle drei existierenden Hardware-Adressierungsbereiche, 24 Bit-, 31 Bit- und 64 Bit-Adressierung. Betriebssysteme und Middleware-Produkte wurden für die Möglichkeit der erweiterten Adressierung angepasst. Viele Beschränkungen, z. B. die 2 GB-Grenze bei S/390-Systemen oder jetzt weitgehend unnötige Funktionen, wie z. B. die Verlagerung von Seiten des Hauptspeichers in den erweiterten Speicher (Expanded Storage), fallen damit weg. Dadurch kann der Durchsatz des Systems in vielen Fällen erhöht werden. Expanded Storage wird jedoch weiterhin bei S/390-(31-Bit)-Anwendungen und z/VM unterstützt.

Anmerkung: Das S/390-System ist zwar in Bezug auf die Hardware ein 32 Bit-System, die Software darauf läuft jedoch mit 31 Bit, da das erste Bit zur Umschaltung zwischen 24 und 31 Bit-Modus benötigt wird.

Unterschiede der S/390-Architektur zur zSeries-Architektur

Der Hauptunterschied zwischen S/390- und zSeries-Systemen ist die erweiterte Adressierbarkeit. Während die S/390-Architektur nur die 31 Bit- Adressierung unterstützt, wurden in den Rechnern der zSeriesfast alle Register auf 64 Bit erweitert. Ein Umschalten zwischen den beiden Modi ist jederzeit möglich.

Die neuesten zSeries-Systeme sind noch immer kompatibel zu früher entwickelten 31 Bit-Programmen, es laufen sogar noch 24 Bit-Programme.

Hardware

Mainframe-Hardware ist in den verschiedensten Varianten verfügbar. Modelle und Ausstattung lassen sich flexibel zusammenstellen, periphere Einheiten können weitgehend beliebig daran angeschlossen werden. Eine vollständige Darstellung kann an dieser Stelle nicht gegeben werden.

Nachfolgend eine kurze Übersicht über die wichtigsten Merkmale:

Modelle

Zur Zeit sind die Typen S/390 (G5, G6 und Multiprise) aus der S/390-Architektur verfügbar, aus der zSeries-Architektur die Typen z800-Server, z900- Server und z990-Server (Stand Ende 2003).

Prozessoren

Die Systeme sind auf bis zu 32 Prozessoren aufrüstbar, wobei diese bei der zSeries-Architektur dynamisch (d. h. während des Betriebs) hinzugefügt werden können.

Hauptspeicher

Je nach Typ können zwischen 1 GB bis max. 256 GB Hauptspeicher verwendet werden.

Kanäle

Verfügbar sind 256 bis max. 512 Kanäle, wobei unterschiedliche Kanaltypen zusammen betrieben werden können (Escon, Ficon). Je nach Konstellation gibt es Einschränkungen.

Logical Partitioning

Ein zSeries-System lässt sich in bis zu 15, bei z990-Servern in bis zu 30, sogenannte logische Partitionen (Logical Partition, LPAR) aufteilen. Dies wird durch das interne PR/SM-Feature (teils Hardware, teils Microcode im Licensed Internal Code) unterstützt. Jede einzelne Partition verhält sich dabei wie ein separates System. Auf den LPARs lassen sich unterschiedliche Betriebssysteme installieren, so dass der Einsatz von Linux (für zSeries) parallel mit dem z/OS-Betriebssystem auf dem gleichen Rechner möglich ist.

Komponenten

  • Multichip Module (MCM)
    Die wesentlichen Komponenten des Rechners sind in sogenannten Multichip Modules zusammengepackt und auf einem Glaskeramikträger aufgebracht. Ein MCM beinhaltet Processor Unit Chips (PUs), Chips für den L2-Cache und dessen Ansteuerung sowie die Ein-/Ausgabe-Steuerung. Die Verbindung aller Komponenten auf dem Träger erfolgt über waagerechte und senkrechte Leitungsverbindungen, die über Kontakte mit der Platine verbunden sind.
  • Thermo Conduction Module (TCM)
    Die in einem MCM entstehende Wärme leitet ein auf dem MCM sitzender Kühler (TCM) ab.
  • SMP
    Das MCM stellt einen in sich symmetrischen Multiprozessor (SMP) dar.
  • Logical Channel Subsystem (LCSS)
    Das LCSS ist eine Erweiterung des früher schon verfügbaren Channel Subsystems (CSS), das es erlaubt, von allen Processor Units aus bis zu 512 Kanäle anzusprechen.
  • HiperSockets
    Die schnelle TCP/IP-basierende Verbindung zwischen LPARs und Virtual Servers (Linux) stellt eine Art TCP/IP-Netz innerhalb des Servers dar.
  • Intelligent Resource Director (IRD)
    Der Intelligent Resource Director unterstützt den Workload Manager (WLM) und besteht aus den wesentlichen Teilen
    • LPAR CPU Management,
    • Dynamic Channel Path Management ( DCM ) und
    • Channel Subsystem Priority Queueing (CSSPQ).
    Bei Problemen im System kann der Workload Manager dynamisch über den IRD veranlassen, dass LPAR-Gewichtungen verändert, Kanal-Pfade umgehängt oder im Channel Subsystem I/O-Prioritäten verändert werden.

Prozessoren und Einsatz

Die Prozessoren sitzen auf MCMs und bestehen im wesentlichen aus den folgenden Typen:

  • Processor Units (Mikroprozessor-Chips),
    • CPU (CP),
    • Ein-/Ausgabe-Prozessoren,
    • Reserve-PUs,
  • Level 2 Cache Chips,
  • System-Assist-Prozessoren (SAPs, Ausführung des Channel Subsystems),
  • Storage Control Chips,
  • Memory Bus Adapter Chips und
  • Clock Chips.

Die Anzahl der standardmäßig gelieferten CPs und SAPs ist abhängig von dem jeweils bestellten Modell. Die Anzahl der Reserve-PUs ist abhängig davon, wie viele PUs insgesamt vorhanden und noch nicht mit Funktionen belegt sind.

Reserve-PUs lassen sich leicht über den Licensed Internal Code Configuration Control (LICCC) via Host Management Console (HMC) den folgenden Funktionen zuordnen:

  • Central Processor (CP)
  • Integrated Facility for Linux (IFL)
  • Internal Coupling Facility (ICF)
  • System Assist Processor (SAP)

Kryptographische Komponenten

Die zSeries bietet verschiedene kryptographische Hardware-Komponenten an, die die Daten-Ver- und -Entschlüsselung unterstützen.

  • Cryptographic Coprocessor Facility ( CCF )
    Dieser Coprozessor ist auf dem Prozessormodul der 9672- und zSeries-Hardware angeordnet (außer z990). Es sind ein oder zwei CCFs je Modul erhältlich. Im CCF können die Schlüssel DES Master Key, Key Management Master Key (PKA KMMK) und Signature Master Key (PKA SMK) gespeichert werden.
  • Peripheral Component Interconnect Crypto Coprocessor ( PCI-CC )
    zSeries-Systeme unterstützen die PCI-CC-Karte, die zusätzlich eingesetzt werden kann, um die Funktionalitäten und Performance des CCF zu unterstützen.
  • Peripheral Component Interconnect Crypto Accelerator (PCI-CA)
    Diese neue Krypto-Karte wurde speziell entwickelt, um die SSL-Ver- und -Entschlüsselung auf zSeries-Systemen zu beschleunigen.
  • z990 PCIX-CC Enhanced Cryptographic Functionality
    Der PCIX Cryptographic Coprocesser ersetzt die CCF- und PCI-CC- Krypto-Hardware im z990-Server.

Ein-/Ausgabe

Die Ein- oder Ausgabe von Daten läuft bei der zSeries-Plattform über ein Netz von Verbindungen, die im folgenden kurz beschrieben werden:

Channel Subsystem (CSS)

Das Channel Subsystem ist eine Einheit (aus Hard- und Software), die für die Verarbeitung der Daten von und zu den Ein-/Ausgabe-Einheiten zuständig ist und die CPU entlastet. Es besteht aus Kanälen (Channel Paths), die wiederum in Unterkanäle (Subchannels) unterteilt sind. Die Unterkanäle führen die Kanalprogramme (Channel programs) aus. Bei dem zSeries-System z990 wurde das CSS zum Logical Channel Subsystem (LCSS) erweitert und unterstützt jetzt mehr als 15 CPUs.

Escon / MIF

Escon-Kanäle sind serielle Kanäle, die als Folgeentwicklung der alten Parallel-Channel-Entwicklung gelten können. Das Multiple Image Facility (EMIF bis z/900 oder MIF ab z/990) unterstützt den parallelen Zugriff von Ressourcen über LPAR-Grenzen hinweg (resource sharing). Escon-Kanäle werden über sogenannte Directors den Einheiten zugeordnet.

Ficon

Ficon-Express-Kanäle (Fibre channels) können parallel zu Escon-Kanälen betrieben werden. Bei der z990 können bis zu 120 solcher Ficon-Kanäle angeschlossen werden. Die Übertragungsrate reicht bis zu 100 MB pro Sekunde. Auch Ficon-Kanäle werden über Directors den Einheiten zugeordnet.

Integrated Cluster Bus (ICB)

ICBs werden unter anderem im Rahmen der Sysplex-Kommunikation als Coupling Link für Highspeed-Verbindungen zwischen Systemen benutzt.

OSA/Express

OSA/Express bietet einen zSeries-Kanalanschluss für Ethernet-Geräte wie z. B. Switches oder Router.

Channel To Channel (CTC)

Channel-To-Channel-Verbindungen gestatten schnelle Verbindungen zwischen zwei zSeries-Rechnern und werden von diversen Software-Produkten, wie z. B. JES3 und VTAM, unterstützt.

zSeries-Mainframe-Konsolen

Die Host Management Konsole(HMC) erlaubt die folgenden Aktionen:

  • Setzen von Datum und Zeit,
  • Konfigurieren von LPARs und Systemen,
  • Reset von Subsystemen,
  • Boot Manager (Initial Program Load - IPL - einer LPAR),
  • Laden des Microprogramms (Initial Microcode Load - IML - eines zSeries Systems),
  • Eingriff bei Fehlerbedingungen,
  • Ersatz-MVS-Konsole und
  • Fehlerkorrekturen seitens des Herstellers (Microcode-Patches).

Es können zwei Konsolen (Primary und Alternate) angeschlossen werden. Sie sind für das komplette System zuständig (alle LPARs) und nicht nur für ein spezielles Betriebssystem. Der Zugriff auf diese Konsolen muss aus Sicherheitsgründen gut geschützt sein.

Die z/OS-System-Konsolen (MVS) sind für die Steuerung und Kontrolle eines z/OS-Betriebssystems zuständig und lassen sich für verschiedene Zwecke konfigurieren, z. B. als Konsole für alle Nachrichten aus dem Bandbereich (Tape-Pool). Es sind mehrere MVS-Konsolen pro z/OS möglich, wovon nur eine die Master-Konsole sein kann. Im Fehlerfall schaltet diese Konsole auf die nächste verfügbare um. Der Zugriff auf die MVS-Konsolen (speziell auf die Master-Konsole) muss aus Sicherheitsgründen gut geschützt sein.

Remote Support Facility (RSF)

zSeries-Systeme sind meist durch eine Remote-Konsole mit dem Hersteller verbunden. Diese Funktion meldet erkannte Hard- und Software-Probleme automatisch weiter, so dass Fehler oft behoben werden können, bevor der Anwender einen Fehler selbst erkennt. Prinzipiell unterstützt diese Verbindung auch die Installation von Patches durch den Hersteller, dies muss jedoch vorher vereinbart und die Remote-Access-Verbindung entsprechend geschützt werden.

Parallel-Sysplex-Konzept

Sind die Anforderungen von einem System (einer LPAR) nicht mehr zu bewältigen, können mehrere LPARs zu einem logischen Verbund, dem Parallel Sysplex zusammengefasst werden. Dieser stellt sich nach außen als eine Einheit dar.

Der Parallel Sysplex ist eine Zusammenarbeit von bis zu 32 z/OS-Systemen, dies entspricht maximal 512 Prozessoren in einem Rechnerverbund. Innerhalb dieses Verbundes können Lasten auf den Rechnern verteilt werden. Treten an einer Maschine Probleme auf, lässt sich diese aus dem Verbund lösen. Die Last wird von den im Sysplex verbleibenden Maschinen übernommen.

  • Coupling Facility (CF)
    Die Coupling Facility (CF) hat die Aufgabe, die Arbeitslast der Systeme zu steuern und Informationen für alle Systeme zur Verfügung zu stellen. Sie ist für die flexible Lastverteilung und die Skalierung zuständig. Die CF übernimmt Aufgaben des Locking, Caching und Queuing. Sie wird über den CCFC (Coupling Facility Control Code) gesteuert.
  • Sysplex Timer
    Damit die einzelnen Systeme innerhalb des Sysplex zusammenarbeiten können, ist der Sysplex Timer nötig. Er übernimmt die Aufgabe, allen im Sysplex befindlichen Systemen eine synchrone Tageszeit zu liefern.
  • Work Load Manager (WLM)
    Der Work Load Manager ist Teil einer jeden Betriebssystem-Instanz und übernimmt in Verbindung mit der Coupling Facility einen wichtigen Teil der Steuerung des Sysplex Clusters. Ein Teil des WLM ist der System Resource Manager (SRM). Dieser übernimmt die Überwachung der angeschlossenen Systeme. Überwacht werden durch den SRM z. B. Prozessorlast, Plattenauslastung, Hauptspeichernutzung und andere Parameter. Die Informationen werden dazu genutzt, die Last auf die im Sysplex angeschlossenen Systeme zu verteilen (siehe Abschnitt zum Thema Intelligent Resource Director).
  • Cloning
    Alle Systeme eines Sysplex Clusters werden auf Basis eines Plattensatzes erstellt. Die lokale Anpassung erfolgt im Normalfall über Variablen der Systemkonfiguration.

Peripherie

Platten

Im Gegensatz zu anderen Betriebssystemen ist der Plattenbereich eines z/OS-Betriebssystems in sogenannte Volumes aufgeteilt. Ein Volume umfasst bei der Emulation einer Platte vom Typ 3390 Mod. 3 einen Speicherbereich von ca. 2,7 GB und ist in Zylinder und Spuren aufgeteilt.

Die Volumes sind an Steuereinheiten angeschlossen. Zur Steigerung der Performance und Betriebssicherheit ist ein paralleler Anschluss an verschiedene Steuereinheiten möglich. Diese werden bestimmten Aufgaben zugeordnet (z. B. JES-Spool-Datei oder System-Residenz) und lassen sich über Subchannel-Adressen ansprechen.

Band

Das z/OS-Betriebssystem unterstützt verschiedene Bandeinheiten, von einzelnen Stationen bis zu Robotersystemen, in denen die Bänder automatisch verwaltet und zur Verfügung gestellt werden. Darüber hinaus gibt es auch virtuelle Band-Systeme (z. B. VTS von IBM oder VSM von StorageTek), die Dateien zuerst auf integrierten Festplatten zwischenspeichern. Danach werden diese Dateien sehr effektiv auf Bänder in diesen Einheiten geschrieben (Komprimierung und Ausnutzung der gesamten Bandlänge).

VTS oder VSM werden vom z/OS-Betriebssystem als Bandeinheit 3490 verarbeitet, d. h. aus der Sicht des Betriebssystems handelt es sich um ein normales Band.

Drucker

Drucker werden von z/OS-Betriebssystemen sowohl direkt am Kanal als auch als Netzwerkdrucker im SNA- oder TCP/IP-Netz unterstützt. Bei entsprechend großen Druckvolumina, z. B. in Druckzentren, erledigen z/OS-Systeme auch reine Druckaufgaben.

Terminalfamilie 327x

Klassische 3270-Terminals an den entsprechenden Steuereinheiten sind heute praktisch nicht mehr in Betrieb. 3270-basierte Terminals haben als PC-Terminalemulation jedoch einen hohen Stellenwert und befinden sich noch recht häufig im Einsatz (bekannt als "grüner Schirm"). Sie basieren auf dem TN3270-Protokoll und lassen sich so betreiben, wie die 327x-Terminals aus früheren Jahren (von Modell 2 bis Modell 5 in verschiedenen Bildschirm-Formaten).

SNA-Komponenten (Systems Network Architecture)

SNA ist eine hierarchisch aufgebaute Netztechnologie mit vordefinierten Verbindungen. Die Knoten im Netz sind in der Regel als Hardware-Komponenten ausgeführt und werden als Physical Units (PUs) bezeichnet. Die Endpunkte im Netz sind entweder Software-Schnittstellen zu einer Applikation (Application Control Block, ACB) oder ein Terminal bzw. Terminal-Emulator oder Drucker. Daneben gibt es seit längerer Zeit die APPN -Technologie (Advanced Peer to Peer Network), die sich von der hierarchischen Form deutlich unterscheidet.

SNA kommt heute als alleiniges Netzprotokoll nur noch selten zum Einsatz. SNA-Netzinstallationen sind vielfach abgelöst oder durch ein TCP/IP-Netz ergänzt, so dass die Anzahl der im Betrieb befindlichen SNA-Hardware-Komponenten stark rückläufig ist.

SNA-Topologie

Das hierarchische SNA-Netz war in der Vergangenheit so aufgebaut, dass unter einem VTAM ein Front-End-Prozessor 3745/46 angeschlossen war. Angeschlossen an diesen waren die Control Units, an denen letztlich die Endgeräte (Terminals, Drucker oder Applikationen) betrieben wurden. Diese Konstellation ist heute zwar immer noch im Einsatz, Front-End Prozessoren und auch Control Units werden von IBM jedoch nicht mehr vertrieben (aber noch unterstützt). Die Anbindung an TCP/IP Netze erfolgt heute meistens über die Software-Funktion Enterprise Extender. SNA in der heutigen Ausprägung wird hauptsächlich noch im Rechenzentrum benutzt, um SNA-basierende Applikationen wie z. B. TSO (Time Sharing Option) anzubinden, während das Netzwerk von TCP/IP abgedeckt wird.

  • Physical Units (PUs)
    Physical Units stellen physische Knoten im SNA-Netz dar. An diesen können weitere Einheiten hängen. Zu den PUs gehören z. B. die oben erwähnten Front-End-Prozessoren 3745/46.
    Darüber hinaus existieren Komponenten, die die früher vorhandenen Control Units (3174) emulieren und deren Funktion wahrnehmen. VTAM im z/OS-Betriebssystem stellt ebenfalls eine Physical Unit dar. Aus historischen Gründen werden selbst neuere Funktionen (wie z. B. APPN) bei VTAM Displays immer noch als Physical Units dargestellt, obwohl diese Bezeichnung hierbei eigentlich ohne Bedeutung ist.
  • Logical Units (LUs)
    Eine Logical Unit stellt sich entweder als Schnittstelle zu einer Applikation, als ein Terminal (oder Terminal-Emulator auf einem PC) oder als ein Drucker dar.

Weitere Informationen zu SNA finden sich in der Maßnahme M 3.40 Einführung in das z/OS-Betriebssystem im Abschnitt Communications Server.

Support Elements (SEs)

Jede zSeries-Hardware besitzt zwei Support Elements (S/390-G5 Modelle haben nur ein SE), die eine Konfiguration und Kontrolle des Systems erlauben. SEs sind über ein schnelles internes Ethernet-Netz untereinander und mit den Prozessoren verbunden (ein Support Element ist ein IBM Laptop PC). Sie erlauben die Systemkommunikation im Rahmen der Operator Facilities.

Firmware

Licensed Internal Code (LIC)

Zwischen der Hard- und der Software existiert auf einer weiteren Ebene der Microcode (Licensed Internal Code). Für den LIC gibt es bei PCs keine direkte Entsprechung, am ehesten ist er mit dem BIOS bei einem PC vergleichbar (siehe Abschnitt zum Thema IML).

Processor Resource/System Manager (PR/SM)

Der Processor Resource/System Manager ist eine LIC-Funktion und erlaubt die logische Aufteilung der physischen zSeries-Hardware in verschiedene Teile, Logical Partitions (LPARs) genannt. Jeder logische Rechner beinhaltet sein eigenes Betriebssystem, wobei verschiedene Betriebssysteme parallel eingesetzt werden können (also zum Beispiel z/OS, OS/390, TPF, Linux oder VSE/ESA auf einer Hardware). Die gemeinsame Nutzung aller Ressourcen wird von PR/SM kontrolliert.

Initial Microcode Load (IML)

DerIMList ein Vorgang, der den LIC in einen nicht zugreifbaren Speicherbereich lädt. Der IML bezieht sich immer auf die gesamte Maschine, d. h. mit IML werden alle LPARs auf der Maschine neu initialisiert (und damit auch die Betriebssysteme gestoppt). IML ist ein Teil der Operator Facilities und kann über die HMC-Konsole aktiviert werden. Der Aufruf des IML muss entsprechend geschützt werden.

Hardware Configuration Definition (HCD)

Zur Anpassung der Software-Konfiguration an die Hardware wird eine Datei (I/O Definition File, IODF) erstellt, in der die logischen Subchannels auf den physischen Channel Pathid abgebildet werden.

Dem Bediener stehen dazu verschiedene Tools zur Verfügung. Auf diese Tools sollte nur autorisiertes Personal Zugriff haben.

Betriebssystem

Für die S/390- und der zSeries-Architektur sind verschiedene Betriebssysteme verfügbar (Stand Januar 2004):

S/390-Architektur (24 und 31 Bit):

  • OS/390 Version 2, Release 10
  • Linux on S/390
  • z/VM Version 3, Release 1
  • z/VM Version 4, Release 2 bis 4
  • VSE/ESA Version 2, Release 5, 6, 7
  • TPF Version 4, Release 1 (nur ESA-Mode)

z/Series-Architektur (64 Bit):

  • OS/390 Version 2, Release 10
  • z/OS Version 1, Release 2 bis 5
  • Linux on zSeries
  • z/VM Version 3, Release 1
  • z/VM Version 4, Release 2 bis 4

Weitergehende Informationen über die Betriebssysteme OS/390 und z/OS sind in der Maßnahme M 3.40 Einführung in das z/OS-Betriebssystem zu finden.

Betrieb

IML

Der Start eines zSeries-Systems beginnt mit dem Initial Microcode Load (IML). Er wird entweder über die HMC-Konsole manuell initiiert oder mittels entsprechender Definitionen automatisch angestoßen. Der IML-Vorgang lädt den Microcode und stellt die Systeminfrastruktur bereit (alle LPARs verfügbar, kein Betriebssystem geladen). Während des IML-Vorgangs wählt der Bediener die gewünschte I/O-Konfiguration aus.

IPL

Das z/OS-Betriebssystem wird durch den Initial Program Load (IPL) von der Host Management Console (HMC) aus aktiviert. Dabei muss mindestens die IPL-Ladeadresse und der IPL-Parameterstring (Ladeadresse der IOCDS-Datei) angegeben werden. Nach der NIP-Phase (Nucleus InitializationProcess) kommuniziert das z/OS-System mit dem Bediener über die MVS-Master-Konsole. Die weiteren Schritte hängen von den Definitionen des Betriebssystems ab. Entweder wird das System manuell aktiviert (Ausnahmefall) oder automatisch.

Operation

Zu den Betriebsaufgaben gehört das Starten und Stoppen der Tasks und Jobs, Aktivieren von Ressourcen, Beantworten von Systemanfragen (Replies) und Bereitstellen von Bandstationen (wenn nötig).

Monitoring

Das System kommuniziert mit dem Operator über Nachrichten und Replies, die an der MVS-Konsole ausgegeben bzw. eingegeben werden. Eine laufende Kontrolle der Nachrichten ist daher notwendig. Dies kann entweder manuell (relativ aufwendig) oder besser über Automatismen erfolgen (separate Programme). Gleiches gilt für die Kontrolle der Stapelverarbeitung.

Literaturhinweise

Für das zSeries-System existiert eine Vielzahl an Literatur und Dokumentationen. Die folgende Aufstellung beschränkt sich auf die wichtigsten und für die Sicherheit des zSeries-Systems besonders relevanten Quellen der Firma IBM. Die Aufstellung ist jedoch keineswegs vollständig.

Redbooks

Formnummer Titel
SG24-5975-nn IBM @server zSeries 900 Technical Guide
SG24-6863-nn IBM @server zSeries 990 Technical Introduction
SG24-6851-nn z/OS Version 1 Release 3 and 4 Implementation
SG24-6540-nn Putting the latest z/OS Security Features to work
SG24-7023-nn Linux on IBM eServer zSeries and S/390: Best Practices
SG24-6981-nn ABCs of z/OS System Programming Volume 1 (Introduction to z/OS and storage concepts, TSO/E, ISPF, JCL, SDSF, MVS delivery and installation)
SG24-6982-nn ABCs of z/OS System Programming Volume 2 (z/OS implementation and daily maintenance, defining subsystems, JES2 and JES3, LPA, LNKLST, authorized libraries, catalogs)
SG24-5653-nn ABCs of System Programming Volume 3 (Introduction to DFSMS, storage management)
SG24-5654-nn ABCs of System Programming Volume 4 (Communication Server, TCP/IP, and VTAM )
SG24-5655-nn ABCs of System Programming Volume 5 (Base and Parallel Sysplex, system logger, global resource serialization, z/OS system operations, automatic restart management, hardware management console, performance)
SG24-6989-nn ABCs of z/OS System Programming Volume 9 (z/OS UNIX System Services)
SG24-6990-nn ABCs of z/OS System Programming Volume 10 (Introduction to z/Architecture, zSeries processor design, zSeries connectivity, LPAR concepts, and HCD )
TIPS0382 z/OS V1R3 and V1R5 Technical Guide
SG24-7035-nn Unix System Services z/OS V1R4 Implementation
SG24-6968-nn Implementing PKI Services on z/OS
SG24-5637-nn OS/390 Parallel Sysplex Configuration Volume 1
SG24-5638-nn OS/390 Parallel Sysplex Configuration Volume 2
SG24-5639-nn OS/390 Parallel Sysplex Configuration Volume 3

IBM Dokumentation

Formnummer Titel
SA22-7832-nn z/Architecture Principles of Operation
SA22-7591-nn z/OS Initialization and Tuning Guide
SA22-7592-nn z/OS Initialization and Tuning Reference
SA22-7683-nn Security Server RACF Security Administrator's Guide
SA22-7681-nn Security Server RACF System Programmer's Guide
SA22-7682-nn Security Server RACF Macros and Interfaces
SA22-7684-nn Security Server RACF Auditor's Guide
SA22-7801-nn z/OS Unix System Services Users Guide
GA22-7800-nn z/OS Unix System Services Planning
SA22-7670-nn z/OS SDSF Operation and Customization
SA22-7532-nn z/OS JES2 Initialization and Tuning Guide
SA22-7533-nn z/OS JES2 Initialization and Tuning Reference
SA22-7549-nn z/OS JES3 Initialization and Tuning Guide
SA22-7550-nn z/OS JES3 Initialization and Tuning Reference
SA22-7783-nn z/OS TSO/E Customization
SA22-7692-nn z/OS MVS Planning: Workload Management
SA22-7597-nn z/OS MVS JCL Reference
SA22-7593-nn z/OS MVS Installation Exits
SC34-4826-nn HTTP Server Planning, Installing and Using
SC31-8775-nn z/OS CS : IP Configuration Guide
SC31-8776-nn z/OS CS : IP Configuration Reference
SA22-7600-nn z/OS MVS Planning : Global Resource Serialization
SA22-7623-nn z/OS MVS Recovery and Reconfiguration Guide
SA22-7625-nn z/OS MVS Setting up a Sysplex
SA22-7630-nn z/OS MVS System Management Facilities (SMF)
SA22-7642-nn z/OS MVS Using the Subsystem Interface
SC26-7402-nn z/OS DFSMSdfp Storage Administration Reference
SC35-0422-nn z/OS DFSMShsm Storage Administration Reference
SC26-7405-nn z/OS DFSMSrmm Implementation and Cust. Guide
SC26-7414-nn z/OS DFSMSdfp Utilities
SC33-7989-nn z/OS HCM User's Guide
GC35-0033-nn Device Support Facilities User's Guide and Reference
SH19-8163-nn MVS/DITTO V2 User's Guide and Reference
SC33-1701-nn CICS RACF Security Guide
SG24-5363-nn IMS V6 Security Guide

Stand: 13. EL Stand 2013