Auszug aus dem IBM Storage System Kompendium

Der System-verwaltete Speicher im Mainframe-Umfeld, Teil 1

Seite: 3/5

Firma zum Thema

Data Facility Storage Management Subsystem

IBM hat 1989 mit MVS/DPF 3.0 die zweite Stufe einer Strategie realisiert, die unter dem internen Begriff „Jupiter Strategy“ in den frühen 80er-Jahren entstanden ist. Diese zweite 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 platziert werden, wie es über Regeln und Service-Levels vorgegeben 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 dritte 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.

Weiter mit: Dateien im z/OS

(ID:2044714)