Neues Verfahren der Zugriffskontrolle

VSAM-File-Sharing: Abbrüche müssen nicht unbedingt sein

12.10.1990

Mit der fortschreitenden Verbreitung von Online-Systemen steigt die Anforderung für erweiterte Datei-Management-Verfahren. Datenbanksysteme berücksichtigen diesen Aspekt der Datenintegrität, nur VSAM hängt immer noch hinten an. Über Anforderungen an ein vernünftiges File-Sharing" macht sich Wilfried Janßen* Gedanken.

In vielen Betrieben sind Datenbanksysteme im Einsatz, aber die meisten Fachleute verbinden Datenorganisation nach wie vor automatisch mit VSAM. Selbst Datenbankanwender sehen in VSAM eine der effektivsten Datenorganisationen für Anwendungen, wenn es auf Verarbeitungsgeschwindigkeit ankommt. Außerdem ist es nicht immer praktikabel, bestehende VSAM-Anwendungen an ein DBMS anzupassen oder neu zu entwickeln.

Im Vergleich zu Datenbanken besitzt VSAM eine einfache Struktur, wobei für VSAM-Dateien der konkurrierende Zugriff durch den Parameter, Shareoption" kontrolliert wird. Diese Methode der Zugriffskontrolle gibt es seit der ersten Version von VSAM. Obwohl in der heutigen Zeit, in der Online-Systeme vorherrschen, diese Methode nicht den Anforderungen des File-Sharings zwischen den Subsystemen genügen kann, wurde sie nie überarbeitet.

Shareoption 1 ist nicht optimal

Um auf ein Verfahren, das den konkurrierenden Zugriff auf VSAM-Dateien sowohl von der Online- als auch der Batch-Seite ermöglicht, einzugehen, sollten vorher die möglichen VSAM-Shareoptions und ihre Nachteile besprochen werden. Denn nur so wird offensichtlich, daß eine alternative Methode notwendig ist, um allen Anforderungen eines vernünftigen File-Sharings gerecht zu werden.

Die erste VSAM-Shareoption erlaubt einer einzelnen Region, in eine Datei zu schreiben, oder mehreren Regionen, die Daten in dieser Datei zu lesen. Diese Option wird nicht häufig benutzt. Ändert nämlich eine Region Daten, so wird der Zugriff aller anderen Regionen blockiert. In einer typischen Online-Umgebung bedeutet dies, daß für die Batch-Seite alle Lesezugriffe auf diese Ressource blockiert sind. Mit anderen Worten, nur in einer statischen Datenlandschaft ist diese Option angebracht. In allen anderen Fällen ist sie nicht praktikabel.

Die zweite Shareoption erlaubt eine größere Flexibilität als die erste Möglichkeit, weil ein Lesezugriff auf mehrere Regionen zugelassen wird - auch wenn eine weitere Region die Datei zur gleichen Zeit verändert. Der Nachteil von Shareoption 2 ist, daß konkurrierende Veränderungen einer Datei nicht möglich sind. Denn nur eine Region kann die Daten zu einem Zeitpunkt verändern. Shareoption 2 läßt sich dort anwenden, wo zum Beispiel CICS hauptsächlich für Veränderungen der Daten benutzt wird und wo Modifikationen durch andere Subsysteme nur gelegentlich stattfinden.

Trotzdem ist Shareoption 2 nicht optimal. Wird eine Datei grundlegend verändert und gleichzeitig von anderer Seite gelesen, so kann es passieren, daß die veränderten Daten der lesenden Region nicht zur Verfügung gestellt werden. Unter Umständen treten dann Situationen auf, die zu Fehlern führen. Selbst ein Abbruch ist dann nicht mehr auszuschließen. Dieses Risiko läßt sich durch CICS-Befehle reduzieren, indem die betreffende Datei von Zeit zu Zeit geschlossen und wieder geöffnet wird. Dadurch wird VSAM veranlaßt, die Buffer zurückzuschreiben und die Kontrollinformation dieser Datei auf den neuesten Stand zu bringen.

Während auf diese Weise zwar die Möglichkeit der Entstehung von Fehlersituationen minimiert wird, garantiert dieses Vorgehen nicht, daß die lesenden Regionen jedesmal erfolgreich sind - ein Restrisiko für mögliche Abbrüche bleibt bestehen. Dieses Risiko ist nicht akzeptabel, weil bei einem Abbruch möglicherweise aufwendige Wiederholläufe notwendig sind.

Shareoption 3 erlaubt den konkurrierenden Zugriff mehrerer Regionen von sowohl Lese- als auch Schreiboperationen für dieselbe Datei. Diese Option löst nicht die Einschränkungen von Shareoption 2. Sie birgt im Gegenteil die Gefahr durch die Möglichkeit der konkurrierenden Zugriffe auf eine Datei Integritätsprobleme hervorzurufen, was den Verlust von Produktionsdateien bedeutet. Aus diesen Gründen ist Shareoption 3 nur in sehr durchdachten Prozessen anwendbar.

Bleibt die vierte und letzte Shareoption. Um den Zugriff aus mehreren Regionen für Lese- und Schreiboptionen innerhalb einer Datei zu ermöglichen und die physische Datenintegrität zu gewährleisten, erfordert Shareoption 4 umfangreiche Programmtechniken

(ENQ, DEQ, RESERVE).

Shareoption 4: Extrem hohe I/O-Rate

Dazu kommen die Kosten für diesen physischen Datenschutz nämlich eine extrem hohe I/O-Rate. Selbst wenn diese Kosten für zusätzlichen Programmieraufwand und I/Os akzeptabel währen, gewährleistet diese Option nicht die vollkommene Datenintegrität innerhalb der Anwendungssysteme. Dies ist ein Nachteil, den Shareoption 4 mit den anderen Optionen gemeinsam hat. Es ist nicht möglich, daß eine einzelne Region exklusives Zugriffsrecht bekommt oder einen Lock auf die einzelne Ressource setzen kann.

Angenommen, CICS- und Batch-Anwendungen laufen zur gleichen Zeit und beide verändern denselben Satz in einer Datei. Bei einem Abbruch einer CICS Transaktion werden durch das Dynamic Transaction-Backout alle Sätze auf den ursprünglichen Zustand zurückgesetzt, die von der fehlerhaften Transaktion verändert wurden. Dies bedeutet für die Batchanwendung, daß auch die hier parallel durchgeführten Veränderungen in diesen Sätzen verloren gehen. Von Datenintegrität also keine Spur.

Dieser Nachteil der Shareoptions läßt den VSAM-Benutzer mit ungenügenden Möglichkeiten für die konkurrierende Bearbeitung von VSAM-Dateien allein. Mit großem Aufwand haben viele DV-Betriebe deshalb ein Datenbanksystem implementiert, um mit den Shareoption-Nachteilen nicht auskommen zu müssen. Dennoch sind Datenbanksysteme nicht immer die beste Wahl, denn zusätzlicher Overhead muß in Kauf genommen werden, weil Datenbankanwendungen einfach mehr CPU-Zeit brauchen.

Zusätzlich ist eine Ausbildung erforderlich, die Zeit und Geld kostet. Projekte können dadurch verzögert werden. Natürlich kann man versuchen, erfahrene Datenbankspezialisten zu finden, die sehr teuer und sehr rar sind. Diese Leute sollten für Neuentwicklungen und nicht für Wartungsaufgaben eingesetzt werden.

Eine Alternative dazu ist das DB2/VSAM-Transparency-Produkt der IBM. VSAM-Anwendungen laufen dann unter dem DB2-Subsystem, ohne daß sie modifiziert werden müssen. Diese Möglichkeit bedingt das Vorhandensein von DB2. VSAM-Anwendungen haben dann nicht mehr den signifikanten Vorteil der schnelleren Verarbeitung, denn die relationale Architektur von DB2 fordert natürlich gerade für Nicht-DB2-Datenstrukturen zusätzliche Rechnerressourcen.

Außerdem ist VSAM durch seine Struktur kein geeignetes Objekt für relationale Datenbanksysteme, obwohl DB2 auf VSAM basiert.

Die wohl bislang beste Lösung ist, VSAM-Dateien dann vom CICS-System abzuhängen, wenn die Batch-Seite aktiv wird. Durch diese Methode sind die bekannten Schwachstellen der Datenintegrität logisch und physisch eleminiert. Nur kann während dieser Zeit niemand über CICS auf diese Dateien zugreifen, was unter Umständen nachteilige Auswirkungen haben kann.

Geringer Speicherbedarf mit Shareoption/5

Die noch bleibende Alternative, eine VSAM-Erweiterung nicht von IBM, löst alle vorher erläuterten Probleme bezüglich der Anwendung der VSAM-Shareoptions und der DB2-AIternative.

Mit Shareoption/5 besteht keine Notwendigkeit mehr, VSAM-Dateien vom CICS-System abzuhängen, damit Batch-Anwendungen mit diesen Dateien arbeiten können. Dies bedeutet, daß Batch- und Online-Anwendungen auf alle VSAM-Dateien zur gleichen Zeit zugreifen können und die Datenintegrität zu jedem Zeitpunkt gewährleistet ist.

Das Produkt operiert in einer eigenen Region (Adreß-Space) und ermöglicht dem Anwender, jede VSAM-Datei als shareable zu definieren. Alle I/Os auf VSAM-Dateien, die über die Shareoption/5-Contro-Facility

als shareable gekennzeichnet wurden, lassen sich über das Produkt abhandeln.

Dadurch, daß Shareoption/5 alle I/Os ausführt, entfallen sämtliche notwendigen Buffer in den Adreß-Spaces, von denen auf VSAM Dateien zugegriffen werden soll. Dies bedeutet eine erhebliche Reduzierung der Speicheranforderungen.

Konkurrierende Zugriffe werden unterstützt

Unter MVS/XA und MVS/ESA werden die benötigten File-Buffer oberhalb der 16-MB-Grenze angelegt. Zusätzlich lassen sich bei MVS/ESA die Hiperspaces benutzen, um den Durchsatz für Batch- und Online-Anwendungen zu erhöhen. Mit den internen Buffer- und Multitasking-Möglichkeiten kann Shareoption/5 gleichzeitig alle Prozessoren in einem CPU-Complex ausnutzen.

Durch das Verwalten aller I/Os ist das Produkt in der Lage, konkurrierende Zugriffe wie READ oder UPDATE aus verschiedenen Regionen zu unterstützen und die Datenintegrität für jeden Fall sicherzustellen. Die Datenintegrität wird durch eine erweiterte Record-Locking-Möglichkeit sichergestellt, die unter anderem verhindert, daß ein Satz in einer VSAM-Datei verändert wird, während dieser Satz in Bearbeitung ist. In diesem Fall ist sichergestellt, daß alle betroffenen Updates zurückgesetzt, die konkurrierenden Updates aber durchgeführt werden.

Die Integrität wird durch eine Forward- und Backward-Recovery-Einrichtung verstärkt, die alle Before- und After-Images von veränderten Sätzen in ein Journal protokolliert. Wenn eine Batch-Anwendung abbricht, wird durch die Shareoption/5-Backout-Facility das Recovery vereinfacht.

Das Forward-Recovery vollzieht alle Veränderungen in einer VSAM-Datei nach, die seit dem letzten Backup durchgeführt wurden, und ermöglicht somit auch das Wiederherstellen einer Datei nach einem DASD-Ausfall oder Fehler. Diese Datenschutzeinrichtung kann auch dann genutzt werden, wenn kein File-Sharing angewandt wird, um die Notwendigkeit von Datei-Backups vor einer Batch-Anwendung zu eliminieren.

Mit Shareoption/5 werden alle Bedenken bezüglich VSAM-Abbrüchen, verlorener oder unzugänglicher Informationen oder nicht korrigierbarer Dateifehler durch das VSAM-File-Sharing aus dem Weg geräumt. Somit ist eine der letzten Barrieren im Bereich VSAM gefallen.

*Wilfried Janßen ist Senior Systems Engineer bei der Standard Electric Lorenz AG in Neuss.