IBM System Storage-Kompendium

IBM Storage Software
Der System-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer
Automatisches Storage und Daten­Management wurde mit
DFSMS/MVS realisiert und wird in den folgenden Abschnitten
beschrieben.
Data Facility Storage Management Subsystem, DFSMS/MVS
IBM hat 1989 mit MVS/DPF 3.0 die 2. Stufe einer Strategie
realisiert, die unter dem internen Begriff „Jupiter Strategy“ in
den frühen 80er­Jahren entstanden ist. Diese 2. Stufe ist
das, was wir heute im Host­Umfeld als SMS verstehen.
Die Jupiter­Strategie war damals in drei Stufen geplant:
1. Jupiter Stage I ist das, was im DFSMS/MVS bzw. z/OS als
Interactive Storage Management Facility (ISMF) verstanden
wird. ISMF ist ein Panel-basierendes ”Frontend“ zu dem
externen Speicher und dem dazugehörigen Repository, in
dem der externe Speicher in einer speziellen, sehr effektiven
und effizienten Datenbank verzeichnet ist. ISMF war der
erste Schritt und wurde 1987 angekündigt und im Markt
eingeführt.
2. Jupiter Stage II wurde 1989 als MVS/DFP 3.0 angekündigt
und allgemein verfügbar. Neben dem Data Facility
Product (DFP) waren auch die Komponenten Data Set Services
(DSS), der Hierarchical Storage Manager (HSM) und
der Removable Media Manager (RMM)
integraler Bestandteil dieser Jupiter Stufe II. Das ist der
Stand von SMS, wie er heute im Mainframe-Umfeld
bekannt ist. Er trägt der Realisierung des Gedankens
Rechnung, den Speicher durch das Betriebssystem nach
einem vordefinierten Regelwerk automatisch zu verwalten.
Über die Jahre hinweg wurde diese Stufe verfeinert und
ergänzt und ist heute unter z/OS integraler Bestandteil
der Betriebssystemsoftware.
3. Jupiter Stage III war als letzte Stufe geplant. In dieser Stufe
sollte die völlige Trennung von logischen Daten und physikalischer
Speicherung umgesetzt werden. Dabei sollte der
externe Speicher auf eine Block-Level Architektur standardisiert
und die logischen Daten automatisch so plaziert
werden, wie es über Regeln und Service-Levels vorge geben
ist. Sollte eine Regel – oder der geforderter Service-
Level – nicht mehr eingehalten werden können, sorgt das
System selbst dafür, dass die betroffenen Blöcke automatisch
und für die Anwendung unbemerkt in der Speicher-
Hierachie so umverlagert werden, dass der geforderte
Service-Level wieder eingehalten werden kann.
Anfang der 90er­Jahre entschied IBM, diese 3. Stufe im
Rahmen der Jupiter­Strategie nicht mehr zu verwirklichen.
Man ging davon aus, dass eine entsprechende Investition
eher für Unix­basierende Server gemacht werden sollte.
168 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang