Bundesamt für Sicherheit in der Informationstechnik

M 3.40 Einführung in das z/OS-Betriebssystem

Verantwortlich für Initiierung: Leiter IT

Verantwortlich für Umsetzung: Administrator, Leiter IT

In seinen Grundstrukturen unterscheidet sich z/OS kaum von anderen Betriebssystemen. Sein Aufbau ist eingeteilt in Hardware-nahe Funktionen, Betriebssystemprozesse und Benutzerprozesse. Zwischen dem eigentlichen Betriebssystem (Base Control Program) und den Benutzerprozessen existieren eine Reihe von Subsystemen, von denen die bekanntesten das Job Entry Subsystem für die Behandlung der Stapelverarbeitung, die Time Sharing Option für die Unterstützung des interaktiven Betriebs und die Unix System Services für den Unix-kompatiblen Betrieb sind.

Die folgende Beschreibung gilt für die Betriebssysteme OS/390 und z/OS. Zur Vereinfachung wird nur noch z/OS aufgeführt, eventuell vorhandene Unterschiede zu OS/390 werden angesprochen, wo sie existieren.

Base Control Program (BCP)

Dieser Teil des z/OS-Betriebssystems ist mit dem Unix-Kernel vergleichbar. Hierin sind die wesentlichen Funktionen des Betriebssystems vereint, die dementsprechend im Kernel-Modus laufen.

Subsysteme

Subsysteme erledigen Aufgaben des Betriebssystems, die nicht im Kernel angesiedelt sind, und laufen in einem separaten Adressraum. Wird ein Subsystem vor dem JES-Start vom MVS-Kernel aktiviert, erfolgt seine Interpretation durch das z/OS selbst (dies erledigt dann der Master Scheduler), was mit gewissen Einschränkungen verbunden ist. Ansonsten startet das Job Entry Subsystem weitere Subsysteme. Eine Definition in der Konfigurations-Datei des z/OS (PARMLIB) legt fest, wie und in welcher Reihenfolge solche Subsysteme gestartet werden.

Subsysteme werden von IBM und von anderen Software-Herstellern geliefert.

Job Entry Subsystem (JES2/3)

Ein Stapelverarbeitungsauftrag wird im z/OS Batch-Job genannt. Dieser besteht aus einer Reihe von prozeduralen Anweisungen, die gemäß der Job ControlLanguage (JCL) aufgebaut sind. Ein Batch-Job kann aus einem oder einer größeren Anzahl von Ablaufschritten (Steps) bestehen. Auch TSO-User oder Started Tasks werden dem System über JCL bekannt gemacht.

Das Job Entry Subsystem (JES) dient zur Verwaltung der Job-Verarbeitung (hauptsächlich Batch-Jobs, aber auch Started Tasks und TSO-User) und deren Ein- bzw. Ausgaben. Aus historischen Gründen gibt es bis heute zwei unterschiedliche Systeme, JES2 und JES3.

Das JES2/3 wird als Primary Subsystem in der Subsystem-Tabelle von z/OS geführt und sollte in einem z/OS-System als erste Task gestartet werden, da erst im Anschluss daran Batch-Jobs gestartet werden können.

Die Verarbeitung der Jobs wird über sogenannte Initiators kontrolliert. Dabei werden unter anderem Klassen, Prioritäten und Anzahl von Jobs definiert, die parallel im System arbeiten.

Ein- und Ausgaben werden in einer zentralen Datei gespeichert, die Spool genannt wird. Mehrere LogicalPartitions (LPARs) lassen sich zu einem JES-Verbund zusammenlegen, bei JES3 Complex, bei JES2 Multiple Access Spool (MAS) genannt.

Beide JES-Subsysteme beinhalten ähnliche Funktionen. JES3 bietet über den Standard hinaus Funktionen wie Networking (zur Automation von Batch- Jobs), Clustering (LPAR-ähnlicher Verbund mit Global/Local-Funktion, jedoch nur auf JES-Basis) und Locate (Job wird nur gestartet, wenn alle Ressourcen verfügbar sind). Viele Funktionen stehen dem Bediener parallel zu den JES-Subsystemen über andere z/OS-Funktionen zur Verfügung (z. B. über GRS, Sysplex, Job Scheduler Programme).

NJE (Network Job Entry) erlaubt das Versenden und Empfangen von Dateien, Batch-Jobs und auch deren Ausgaben zwischen den einzelnen Netzknoten eines Verbundes. So ist es damit z. B. möglich, einen Batch-Job vom System A zum System B zu schicken, dort zu verarbeiten und die Ausgabe dann am System C auszugeben.

Time Sharing Option (TSO)

Im Online-Betrieb ermöglicht TSO einen Multi-Tasking- und Multi-User-Betrieb.

Der TSO Terminal Control Address Space (TCAS), ein eigener Adressraum, verwaltet dabei den Ablauf. Er initiiert und terminiert die einzelnen Benutzeradressräume (einen pro Benutzer) und verwaltet den Nachrichtenfluss zwischen Terminal und Adressraum.

TSO unterstützt über eine einfache Scriptsprache sogenannte Command Lists (Clists), häufiger ist jedoch die modernere Interpreter-Sprache REXX im Einsatz. Zu Vereinfachung der Kommunikation steht dem Bediener ein weiteres Software-Paket zur Verfügung, das Interactive System Productivity Facility (ISPF). Es erlaubt einen Dialog im Full Screen Modus. Neben den Standardfunktionen von ISPF kann der Bediener eigene Dialoge für neue Applikationen entwickeln.

Communications Server (CS)

Der Communications Server für z/OS beinhaltet die Software-Komponenten, die für die Kommunikation von und zu einem Mainframe nötig sind. TCP/IP-Komponenten, wie z. B. FTP -Server und TN-Server, sind in diesem Paket ebenso enthalten wie SNA-Komponenten.

Der Communications Server liefert die folgenden Funktionalitäten:

  • Bereitstellung der TCP/IP- und SNA-Dienste
  • Lastverteilung auf die Netzkomponenten in einem Sysplex-Verbund
  • Kontrolle und Steuerung der VPN-Kommunikation
  • Implementierung der Sicherheitskomponenten für Applikationen
  • Telnet-3270- und Secure-Telnet-3270-Unterstützung, Telnet/SSH zu den Unix System Services des z/OS
  • Unterstützung von IPv6 für das z/OS-Betriebssystem

Systems Network Architecture (SNA)

Ein Knoten im SNA-Netz ist durch eine Network Addressable Unit (NAU) definiert. Die Wege zwischen den einzelnen Knoten werden in Form von Routen konfiguriert. Die Weiterentwicklung des statischen SNA-Netzes, Advanced Peer to Peer Networking ( APPN ) genannt, erlaubt den Einsatz dynamischer Netzkonfigurationen ähnlich dem TCP/IP-Netz.

Der Communications Server bildet eine Gateway-Funktion zwischen der heute üblichen IP-Netzinfrastruktur und den noch vielfach vorhandenen SNA/APPN-basierenden Komponenten, wie z. B. TSO-, IMS- oder CICS - Anwendungen.

SNA-Kommunikationsbeziehungen werden häufig über das IP-Netz mittels Enterprise Extender betrieben. Voraussetzung dafür ist APPN/HPR (High Performance Routing).

Klassische SNA-Netze gelten als relativ sicher, da die Netzzugänge komplett definiert sein müssen und das Gesamtnetz somit geschlossen ist. Als weiterführende Sicherheitsmaßnahme kann der Session Management Exit (SME) von VTAM eingesetzt werden.

TCP/IP

TCP/IP ist unter den Unix System Services (USS) im z/OS implementiert. Der TCP/IP-Service unter z/OS bietet ähnliche Funktionen wie die IP-Dienste anderer Unix-Versionen. Über den Telnet TN3270 IP-Service ist der Zugriff auf SNA-basierende Anwendungen (TSO, CICS, IMS usw.) möglich. Unter TCP/IP stehen für z/OS eine ganze Reihe von Applikationen zur Verfügung, wie z. B. ein HTTP-Webserver, Unterstützung für File-Transfer via FTP, E-Mail via SMTP, Network File System (NFS), Domain Name Service ( DNS ) und weitere Services. TCP/IP unterstützt Verschlüsselung über IPSec, SSH und TLS (SSL).

Durch den Einsatz von Dynamic VIPA (Virtual IP Address) wird es ermöglicht, dass beim Ausfall eines Systems innerhalb eines Parallel SysplexClusters eine IP-Adresse automatisch von einem Backup-System übernommen werden kann. Unterstützt die Anwendung diese Funktionalität auch, trägt dies wesentlich zur Erhöhung der Verfügbarkeit bei.

Durch Einsatz des Workload Managers ist es darüber hinaus möglich, eine Lastverteilung der Netzdienste auf mehrere CPUs innerhalb eines Sysplex-Verbundes zu erreichen.

TCP/IP gewinnt immer mehr an Bedeutung, wohingegen die Bedeutung des SNA-Netzes abnimmt (speziell bei der Neuentwicklung von Applikationen).

Kerberos

z/OS unterstützt das Authentisierungssystem Kerberos.

AnyNet

Die Bezeichnung AnyNet steht für zwei Funktionalitäten, die mit dem Communications Server ausgeliefert werden:

  • SNA over TCP/IP und
  • AnyNet Sockets over SNA.

SNA over TCP/IP erlaubt es Applikationen, die nur das SNA-Protokoll unterstützen, mit einem TCP/IP-Netz verbunden zu werden, ohne dass die Applikationen angepasst werden müssen.

AnyNet Sockets over SNA erlaubt es Applikationen unter z/OS Unix System Services (USS), Verbindungen über ein vorhandenes SNA-Netz aufzubauen.

System Authorization Facility (SAF)

Die SAF ist ein Teil des z/OS-Betriebssystems und dient als Sicherheitsschnittstelle zwischen dem System und dem Sicherheitssubsystem (z. B. RACF, TopSecret, ACF2).

Resource Manager, z. B. IMS, DFHSM, JES oder CICS, fragen über die SAF-Schnittstelle bei RACF bzw. dem jeweiligen Sicherheitssubsystem an (RACROUTE Macro), ob ein Anwender berechtigt ist, auf eine Ressource zu zugreifen. SAF gibt die Antwort des Sicherheitssubsystems an den Resource Manager zurück, woraufhin dieser den Zugriff gewährt (Return Code ist gleich Null) oder ablehnt (Return Code ist größer Null).

SecureWay Security Server für z/OS

Der Secure Way Security Server für z/OS bildet eine Sicherheitsplattform für das Mainframe-System. Der Secure Way Security Server umfasst folgende Komponenten:

RACF (Resource Access Control Facility)

RACF ist eine Zusatz-Software zur Absicherung des z/OS-Betriebssystems. RACF arbeitet mit Kennungen, Gruppen und Ressourcen (Dateien, Klassen), die in der RACF-Datenbank eingetragen sein müssen. Anhand dieser Definitionen regelt RACF nicht nur den Zugang zum System, sondern auch die Zugriffe auf die Ressourcen. Jede Ressource, z. B. Datei, muss über ein entsprechendes RACF-Profil geschützt sein. Durch den Einsatz von Platzhaltern ist es möglich, mit einem generischen Profil eine Gruppe von Ressourcen zu schützen, womit die Verwaltung vereinfacht wird. Zugriffe auf diese so geschützten Ressourcen müssen dann entweder einzelnen Usern oder Usergruppen durch die RACF-Administration vergeben werden.

Im RACF gibt es Attribute, die einem Besitzer höhere Rechte einräumen können:

  • SPECIAL - berechtigt zur Administration des RACF (Verwalten von Gruppen, Kennungen und Ressourcen).
  • OPERATIONS - für Space Manager, mit diesem Recht können Dateien verwaltet werden.
  • AUDITOR - für die Überwachung der Tätigkeiten im Sicherheitsbereich in der Funktion eines Audits.

Diese Rechte können zusätzlich auf Gruppenebene vergeben werden (Group Special, Group Operations, Group Auditor).

Für die Berechtigung zur Nutzung interaktiver Programme, z. B. TSO oder Unix System Services, bietet RACF zusätzliche Segmente an. In diesen Segmenten werden die Rechte zur Nutzung der interaktiven Programme festgelegt. Darüber hinaus können Abrechnungsinformationen (Accounting) oder Ressourcenbeschränkungen (dem Anwender zur Verfügung stehender Hauptspeicher, Anzahl zu startender Tasks) in diesen Segmenten festgeschrieben werden.

Jeder Anwender (darunter fallen die Kennungen von Batch-Jobs, TSO-Usern und Started Tasks) wird im laufenden System von RACF über sogenannte ACEEs (Accessor Environment Element) verwaltet. Das sind Kontrollblöcke, die bei der Initialisierung des Adressraumes angelegt werden.

Public Key Infrastructure (PKI)

RACF bietet den gesicherten Systemzugang mittels digitaler Zertifikate an. Dies ist besonders für den Einsatz im Internet/Intranet sinnvoll. RACF kann Zertifikate erzeugen, signieren, prüfen und verwalten. Die Zertifikate können in der RACF-Datenbank oder in einer speziellen Hardware gespeichert werden. Der Aufbau einer Public Key Infrastructure mit eigenen RACF-Zertifikaten ist hiermit möglich. Auch der Zugang zu geschützten Webserver-Bereichen kann über Zertifikate erfolgen.

Firewall Technologies

Die Firewall Technologies des Secure Way Security Server für z/OS ermöglichen die Trennung interner und externer Netzbereiche. Sie unterstützen folgende Funktionalitäten:

  • Packet Filter
  • sichere Tunnel mit IPSec-Technik zum Aufbau von VPNs (Virtual Private Networks)
  • Socks Server
  • FTP Proxy Server
  • Network Address Translation (NAT) von einer internen zu einer externen Adresse und zurück

Für den Einsatz von IPSec wird zusätzlich der Communications Server für z/OS benötigt.

LDAP

Zusammen mit dem Secure Way Security Server liefert IBM einen LDAP-Server aus. Dieser unterstützt die gängigen LDAP-Clients und kann somit als Auskunftssystem dienen. Zur Verwaltung großer Datenmengen kann sowohl die RACF-Datenbank als auch eine unabhängige DB2-Datenbank eingesetzt werden.

Distributed Computing Environment (DCE)

DCE ist eine Sammlung von Tools und Diensten, welche die Erstellung, Nutzung und Pflege von verteilten Anwendungen unterstützen.

DCE unter z/OS unterstützt das Distributed File System (DFS), welches innerhalb der DCE-Umgebung die gemeinsame Nutzung von Daten (Sharing) erlaubt, und Network File System (NFS), welches unter anderem Unix-Workstations gestattet, auf Daten der z/OS-Rechner zuzugreifen.

Integrated Cryptographic Service Facility (ICSF)

Das ICSF ist ein Software-Element, das mit der Krypto-Hardware und dem Secure Way Security Server zusammenarbeitet, um die Ver- und Entschlüsselung zu beschleunigen.

Sysplex Failure Managements (SFM)

Die SFM Policy erkennt, ob Fehler an einem im Sysplex-Verbund arbeitenden System aufgetreten sind und leitet gegebenenfalls entsprechende Maßnahmen ein. Ohne SFM wird, falls eine Maschine im Verbund Probleme hat, eine Nachricht an den Operator gesendet. Der Operator kann daraufhin das fehlerhafte System aus dem Verbund nehmen und Recovery-Maßnahmen einleiten. SFM erlaubt die Installation einer Policy, die bei bestimmten Fehlern automatisch festgelegte Recovery-Aktionen initiiert und so den Betrieb der Maschine aufrechterhalten kann.

Automatic Restart Manager ( ARM )

Der ARM erlaubt ein schnelles Wiederherstellen von Subsystemen, die aufgrund kritischer Ressourcen (z. B. Deadlocks) angehalten wurden. Hierdurch werden die aktiven Systemeingriffe durch das Operating reduziert.

Global Resource Serialization (GRS)

GRS stellt in einer Multitasking/Multiprocessing-Umgebung sicher, dass der Zugriff auf Ressourcen, die von mehr als einem Rechner benutzt werden, koordiniert abläuft. Im Rahmen einer Sysplex-Konfiguration sollte GRS in jedem Fall eingesetzt werden.

GRS kann einerseits im RING-Modus konfiguriert werden. Dabei wird ein RSA Message Control Block (Ring System Authority) sequentiell von z/OS-System zu z/OS-System transportiert, in dem jedes System seine Anforderungen einträgt. Jedes System kopiert sich die RSA Message in den eigenen Speicher, d. h. die Information ist nicht aktueller, als bei der zuletzt vorbeigekommenen RSA-Information.

Als weitere, modernere Konfiguration steht der STAR-Modus zur Verfügung. Dabei sind alle z/OS-Systeme im Sysplex mit einer Lock Structure in der Coupling Facility verbunden, wobei jedes z/OS-System nur die eigene Sicht im lokalen Speicher halten muss. Die Abfrage nach Ressourcen durch GRS ist im STAR-Modus effektiver als im RING-Modus.

Unix System Services (USS)

USS ist keine Unix-Portierung, sondern ein POSIX-kompatibles Subsystem von MVS. Früher wurde es als Open Edition MVS vertrieben. Die Aufgabe des USS Subsystems liegt im Betrieb POSIX-kompatibler Anwendungen. Hierfür wurde das Hierarchical File System (HFS) und eine Unix Shell eingeführt.

Parallel zu HFS steht seit geraumer Zeit auch das Filesystem zFS zur Verfügung, das für alle neuen Entwicklungen benutzt wird (siehe auch nachfolgenden Abschnitt Dateisysteme und Zugriffsarten).

Unter USS laufen viele Programme, die auch unter POSIX-konformen Unix-Betriebssystemen laufen können. So sind die Funktionen von TCP/IP für z/OS größtenteils unter USS realisiert. Ebenso steht ein HTTP-Webserver zur Verfügung, der als Daemon unter USS oder als Started Task unter MVS laufen kann.

System Managed Storage (SMS)

SMS vereinfacht das Verwalten von Daten auf Festplatten, indem diese Funktion viele Aufgaben, z. B. das Anlegen von Dateien auf bestimmten Festplatten, die Festlegung von Charakteristiken der Datasets usw., übernimmt. Hierzu werden sogenannte ACS-Routinen (Automated Control Storage) definiert, die nach vorgegebenen Regeln den Plattenspeicher verwalten. Datasets werden dabei anhand ihrer Namensgebung in vorher festgelegte Plattenpools gespeichert. Da Mainframe-Systeme nicht selten über eine große Anzahl von Platten verfügen, vereinfacht SMS die Verwaltung der Dateien außerordentlich. Die Verwaltung von SMS kann über das interaktive Dialog-System ISMF erfolgen (Interactive Storage Management Facility).

Im Rahmen des SMS-Konzepts gibt es eine Reihe von Software-Produkten, die die effiziente Verwaltung von Daten in einer Umgebung mit dem z/OS-Betriebssystem ermöglichen (z. B. DFHSM- oder DFxxx-Produkte). Darüber hinaus stehen als Storage Management Funktionen eine Reihe von Dienstprogrammen zur Verfügung, die die Verwaltung der Datenbestände unterstützen.

Hierarchical Storage Manager (HSM)

HSM ist ein wesentlicher Bestandteil des SMS-Konzeptes von z/OS. Das Programm-Produkt unterstützt die Verwaltung der z/OS-Dateien, die Datensicherung sowie die effektive Nutzung von Speichermedien. Gesteuert über sogenannte Policies (Regel-Definitionen) werden von HSM zu vorgegebenen Zeiten Dateien auf andere Medien verschoben (migriert) und dabei komprimiert. Es gibt zwei Migrations-Level:

  • Migration-Level 1 auf HSM-eigene Platten
  • Migration-Level 2 auf Bänder (in Roboterstationen) oder nach VTS (Virtual Tape System)

Migrierte Dateien können erst wieder gelesen werden, wenn sie über den HSM wieder erstellt worden sind. Diese Funktion kann entweder manuell initiiert werden oder erfolgt automatisch, wenn die Datei angesprochen wird (Recall-Funktion).

Weiterhin können logische Dumps (bestimmte Dateien) oder Full Volume Dumps (der Inhalt einer ganzen Festplatte) zu bestimmten Zeiten gestartet werden und somit automatisch Datensicherungen durchgeführt werden.

System Management Facility (SMF)

SMF ist die zentrale Protokollierungsfunktion im z/OS-Betriebssystem. Nahezu alle Komponenten und auch viele ISV-Produkte (Independent Software Vendor) schreiben SMF-Sätze, in denen die Aktivitäten protokolliert werden. Auch RACF schreibt solche Sätze. Hier ist besonders der Satztyp 80 wichtig für spätere Auswertungen.

Resource Measurement Facility (RMF)

RMF protokolliert das Systemverhalten in Bezug auf Kapazität und Performance. Die Protokolldaten werden als SMF-Sätze gesichert und stehen für spätere Auswertungen zur Verfügung. RMF ist optional, alternative Programme (Monitore) sind am Markt verfügbar.

Generalized Trace Facility (GTF)

Der Begriff Trace stellt die Möglichkeit dar, den Datenfluss zwischen zwei Komponenten im System (z. B. einer Anwendung und einem Endbenutzer) mitzuschreiben und in einer Datei zur späteren Auswertung zur Verfügung zu stellen. GTF ist die zentrale Trace-Funktion von z/OS, die Traces von vielen z/OS-Komponenten ermöglicht. Darüber hinaus werden auch Traces der Netzfunktionen unterstützt. Zum Auswerten der Traces stehen verschiedene Programme zur Verfügung, z. B. ACFTAP für Netzanalysen. Für Online-Traces bietet sich auch NLDM an (Network Logical Data Manager), eine Komponente der NetView Software.

Transaktionsmonitore und Datenbanksysteme

IMS TM (Information Management System Transaction Monitor)

IMS TM wird die Transaktionskomponente des IMS-Systems genannt, mit der die IMS-Transaktionen in einem IMS-System verwaltet und gesteuert werden. (In älteren IMS-Versionen ist diese Funktion auch unter dem Kürzel DC bekannt.)

IMS DB (Information Management System Database)

IMS DB wird die Datenbankkomponente des IMS-Systems genannt, mit der die IMS-Datenbanken in einem IMS-System verwaltet werden. Bei IMS-Datenbanken handelt es sich um hierarchische Datenbankmodelle.

CICS TS (Customer Information Control System Transaction Server)

CICS TS ist ein weiterer Transaktionsmonitor. Mit CICS TS werden die CICS-Transaktionen in einem System verwaltet und gesteuert. Als Datenbank werden häufig VSAM-Files oder DB2-Datenbanken eingesetzt.

DB2 (Database 2)

DB2 ist ein Programmpaket, mit dessen Hilfe relationale Datenbanken erstellt und verwaltet werden können. Über IMS TM, CICS TS oder über die Sprache SQL (Structured Query Language) können Daten in der Datenbank in Tabellen abgelegt oder aus dieser Datenbank extrahiert werden.

IMS, CICS und DB2 sind nicht im Fokus des Bausteins S/390- und zSeries-Mainframe und werden nur am Rande betrachtet.

File Transfer Protocol (FTP)

FTP-Programme erlauben den Transport von Daten sowohl zwischen z/OS-Systemen, als auch zu und von anderen Plattformen.

FTP ist nicht im Fokus des Bausteins S/390- und zSeries-Mainframe und wird nur am Rande betrachtet.

Middleware

MQSeries (Message Queueing System)

MQSeries stellt eine Verbindung zwischen unterschiedlichen Applikationen auf der Basis von Nachrichten (Messages) her, beispielsweise zwischen CICS, IMS oder Batch-Applikationen. Über entsprechende API s (Application Programming Interfaces) werden die Nachrichten an MQSeries weitergegeben und danach an die vorgegebenen Ziele ausgeliefert. Ist die Lieferung nicht möglich, werden die Nachrichten zwischengespeichert (Queued) und erst dann weitergeleitet, wenn der Verbindungsaufbau wieder möglich ist.

MQSeries ist nicht Gegenstand des Bausteins S/390- und zSeries-Mainframe.

Dateisysteme und Zugriffsarten

Dateien werden unter z/OS mit bestimmten Charakteristiken angelegt, z. B. Größe, Art der Speicherung (innere Struktur), auf welcher Platte sich die Datei befindet und unter welchem Dateinamen die Datei gespeichert und normalerweise zu finden ist. Insbesondere in Bezug auf die innere Struktur der Dateien bestehen teilweise erhebliche Unterschiede zu anderen, häufig eingesetzten Betriebssystemen. Nachfolgend die wichtigsten Dateitypen:

HFS (Hierarchical File System)

Das HFS-Filesystem ist mit typischen Unix-Dateisystemen vergleichbar. Es wird in einem MVS Dataset abgelegt, das MVS-seitig mit den üblichen Werkzeugen verarbeitet werden kann (z. B. Datensicherung über HSM). Gegenüber USS stellt sich das Filesystem hierarchisch dar. Daten in diesem Filesystem werden im EBCDIC -Zeichensatz gespeichert.

z/OS File System (zFS)

Das zFS entspricht konzeptionell dem HFS, jedoch können hier mehrere Filesysteme in einem z/OS Dataset gespeichert werden und die Daten lassen sich auch im ASCII -Zeichensatz abspeichern. Laut IBM ist zFS das strategische Filesystem, in dem nur noch neue Funktionen entwickelt werden. zFS kann bis jetzt nicht als Root-Filesystem verwendet werden.

MVS Physical Sequential (PS) Datasets

In dieser Art von Dataset können Daten nur sequentiell gelesen oder geschrieben werden. Physical Sequential Datasets dienen im Systemumfeld oft der Verarbeitung großer Datenmengen.

MVS Partitioned Organized (PO) Datasets

Partitioned Organized Datasets können mit einer Bibliothek verglichen werden. In einem PO Dataset gibt es einen Index (Directory) und die einzelnen Bücher (Member). Die Member enthalten die Informationen.

Bei häufigem Abspeichern von Membern muss die Datei zeitweise reorganisiert werden. Dies kann durch die Benutzung einer PDSE-Datei (Partitioned Dataset Enhanced) umgangen werden.

Virtual Storage Access Method (VSAM)

Im z/OS-Betriebssystem stellt VSAM eine der wichtigsten Zugriffsmethoden auf Dateien dar. Die Datensätze werden über einen Index oder eine relative Byte-Adresse gefunden. Vier VSAM-Dateiarten lassen sich unterscheiden:

  • ESDS (Entry Sequenced Data Set)
  • KSDS (Key Sequenced Data Set),
  • RRDS (Relative Record Data Set) und
  • LDS (Linear Data Set).

Weitere Zugriffsmethoden

Neben der allgemein bekannten VSAM-Methode gibt es weitere Methoden wie Sequential Access Method (SAM) und Queued Sequential Access Method (QSAM) sowie diverse andere Methoden, die hier wegen ihrer geringeren Verbreitung nur am Rande erwähnt werden.

Server- und Client-Konzepte

Durch die Erweiterung des z/OS-Betriebssystems um den Unix System Server (USS) können Rechner mit diesem Betriebssystem zusätzliche Server- und Client-Funktionen wahrnehmen. Beispiele für solche Server-Funktionen sind unter anderem der HTTP-Server, der FTP-Server oder der Domain Name Server. Die FTP-Funktion lässt sich z. B. auch als Client einsetzen. Darüber hinaus wird das z/OS-System in heutigen 2-Schicht- oder 3-Schicht-Architekturen vielfach als Datenbank-Server eingesetzt, wo es mit anderen Plattformen kommuniziert.

Konfiguration des z/OS (OS/390)

I/O-Config

Die Eingabe-/Ausgabe-Konstellation eines z/OS-Betriebssystems wird im Rahmen des HCD -Dialogs über eine I/O-Konfiguration erstellt und über das Operator Facility (via HMC-Konsole) für die jeweilige LPAR abgelegt. Zum IML-Zeitpunkt ist bereits festgelegt, welche I/O-Profile für die spätere Auswahl zur Verfügung stehen. Ein dynamisches Nachkonfigurieren während des Betriebs ist jederzeit möglich (siehe Maßnahme M 3.39 Einführung in die zSeries-Plattform ).

IPL Volume

Zum Starten eines z/OS-Betriebssystems benötigt das System ein spezielles IPL-Volume, eine Platte mit einer speziellen Bootstrap-Routine, die die notwendigen Betriebssystemprogramme lädt und zum Starten bringt. Dieser Vorgang entspricht einem Boot-Vorgang bei Unix und nennt sich bei z/OS Initial Program Load (IPL).

Parmlib / Proclibs

Eine (oder mehrere) Parameter-Datei(en) stehen über den Parmlib-Mechanismus zur Verfügung, um alle wesentlichen z/OS-Systemparameter zu definieren. Dazu gehört z. B., welche Subsysteme gestartet werden sollen, welche Sicherheitsmechanismen aktiviert werden und welche Bibliotheken autorisiert sein sollen. Alle wichtigen System-Jobs - auch Started Tasks genannt - stehen auf Prozedur-Bibliotheken (Proclibs) bereit, um zum Startzeitpunkt aktiviertwerden zu können (siehe Maßnahme M 3.39 Einführung in die zSeries-Plattform ). Dieser Bereich muss sehr sorgfältig definiert und geschützt werden, da hier wesentliche Sicherheitsmechanismen verankert sind.

Kataloge

Dateien werden über Kataloge geführt und dem System bekannt gegeben. Als oberste Instanz existiert der Master-Katalog, an den über Alias-Definitionen verschiedene Benutzerkataloge angebunden sind.

Arbeitsdateien

Zur Minimalkonfiguration eines z/OS-Betriebssystems gehören mehrere Arbeitsdateien, die bei Produktionsbeginn angelegt sein müssen:

  • Syslog
  • JES2/3 Spool und Checkpoint
  • SMF-Dateien
  • Log-Writer-Dateien
  • Couple Datasets (bei Sysplex)
  • Page Datasets zum Auslagern von Hauptspeicher

Stand: 13. EL Stand 2013