BARCELONA (uk) - "Benutzer einer IBM 370/125 sollten sich den Einsatz der Zugriffsmethode beziehungsweise Datenorganisation VSAM (Virtual Storage Access Method) gut überlegen. Denn: Mit weniger als 384 K Hauptspeicher ist die Anwendung auf solchen Systemen kritisch", schreckte Armand Martin, Systemspezialist bei der schweizerischen Utesia AG, auf der letzten Common-Tagung in Barcelona Anwender kleinerer IBM 370-Systeme. Martin stellte VSAM zwar als eine "sorgfältig konzipierte, stabile Softwarekomponente" hin, doch erst IBM-Anwender ab der 370/135 aufwärts müßten nicht mehr befürchten, später für eine Fehlentscheidung geradestehen zu müssen". Andererseits, so der VSAM-Insider weiter auf dem DOS-Anwender-Meeting in Spanien, "erleiden Benutzer der Systeme 370/138 und größer sogar einen echten Verlust, wenn sie VSAM nicht einsetzen". Armand Martin, der sich bereits seit Anfang 1974 mit insgesamt etwa 20 VSAM-Umstellungen beschäftigt hat und dabei "einige Dutzend problemerfüllte Nachtwachen am Rechner" absolvieren mußte, kritisierte bei seinem VSAM-Erfahrungsbericht außerdem noch die "gewollte oder sieh aus der Philosophie der VS-Systeme ergebende" Abhängigkeit vom EDV-Hersteller: "Mir ist kein Anwender bekannt, der nach einer echten, das heißt nicht nur probehalber durchgeführten VSAM-Einführung den Weg zurück beschritten hätte." "Gewisse VSAM-Sachzwänge", so machte Martin deutlich, ließen den Hersteller sogar "im Laufe der Zeit immer mehr Einfluß gewinnen".
Im folgenden einige Auszüge aus dem Martin-Referat:
VSAM unterstützt die Platteneinheiten 3330, 3340, 3344 und 3350. Es spielt dabei keine Rolle, ob 3350-Platten im 3330-Modus (also als 3330-Platten) oder im Originalmodus (im native mode) betrieben werden.
Unterste Grenze: 384 K
Die kleinste mir bekannte VSAM-Installation war eine 370/125 mit 256 Kilobytes. Der Systemdurchsatz auf dieser Anlage war im Zwei-Partitionbetrieb noch einigermaßen erträglich, bis CICS installiert wurde. Um wieder vernünftig produzieren zu können, war ein Ausbau auf 512 Kilobytes nötig. Eine Systemkonfiguration 370/125 mit 384 K scheint mit die unterste Grenze für einen vernünftigen VSAM-Betrieb zu sein.
Bei einer Einführung von VSAM ist es uns gelungen, die Daten des Betriebes die rund 360 MB auf 2314 belegten in 300 MB auf 3330-Platten unterzubringen Also eine Einsparung von zirka 18 Prozent.
Die Erfahrung zeigt, daß es in vielen Fällen durchaus möglich ist mit 300 MB, das heißt 3 Spindeln 3330, einen vernünftigen VSAM-Betrieb aufzuziehen.
VSAM kann nur in einem VS-Betriebssystem benutzt werden. Der älteste mögliche DOS/VS-Release ist 29. Die Generierung besteht aus einem Parametereintrag in der Systemgenerierung, der Definition einer SVA, eines VSAM-Masterkatalogs und einem oder mehreren VSAM-Bereichen auf Platte. Der Arbeitsaufwand ist höchstens mit zwei bis drei Arbeitstagen zu beziffern.
"Default Values" nicht optimal
Ein ganz anderes Kapitel ist ein vernünftiger oder sogar optimaler VSAM- Betrieb. Es besteht nämlich die große Gefahr - und ich habe das an mehreren Orten bestätigt gefunden - daß man nach Einführung die Software "sich selber überläßt", das heißt, daß die vordefinierten Werte, die "default values", unverändert belassen werden. Diese Werte sind aber alles andere als optimal! Sie können es auch gar nicht sein, wenn man in Betracht zieht, daß VSAM immerhin auf etwa 8 bis 10 verschiedenen Computermodellen unter dem gleichen Betriebssystem laufen kann. Ein "selbst erlebtes" Beispiel: Ein Programm, das sehr viele direkte Zugriffe mit anschließendem Zurückschreiben ausführte, lief nach der
Umstellung von ISAM auf VSAM nicht mehr durchschnittlich 54 Minuten sondern 79 Minuten. Durch Veränderung der Puffergröße in der Job-Control sank die durchschnittliche Laufzeit auf 39 Minuten! Damit ist eines der Hauptprobleme des VSAM-Betriebes deutlich gemacht: Im Gegensatz zu den herkömmlichen Datenorganisationen und Zugriffsmethoden benötigen wir den dauernden Einsatz eines kompetenten Systemprogrammierers, der den VSAM-Betrieb optimiert. Das ist aber auch eine EDV-betriebliche Voraussetzung, die nicht überall gegeben ist. In der Praxis sind zwei Probleme aufgetreten:
1. Die Ausbildung eines VSAM-Spezialisten ist mit erheblichen Kosten verbunden. Der Hersteller bietet zur Zelt drei Kurse und einen Lehrtext an, die zusammengenommen 15 Arbeitstage beanspruchen und direkte Kosten von rund 1500 Mark verursachen. Dazu kommt, daß diese Kurse einen hohen Ausbildungsstand voraussetzen.
2. Einige Betriebe, besonders kleinere die bis, dahin ihre Software durch den Hersteller oder den temporären Einsatz externer Mitarbeiter generieren ließen und das System dann während längerer Zeit (im Extremfall während Jahren) unverändert benutzten, sahen sich mit gravierenden Problemen konfrontiert. Es waren neue Stellen zu schaffen, Pflichtenhefte zu schreiben, Aufgabenverteilung und Kompetenzen neu zu regeln.
Die Pflege der VSAM-Dateien nimmt an den meisten Orten 10 - 20 Prozent der Arbeitszeit eines Mitarbeiters in Anspruch. Das Problem ist dort gelöst wo weitere Softwarekomponenten im Einsatz sind, die dauernde Wartung benötigen, wie zum Beispiel CICS. Größere betriebe haben die Aufgabe dem Datenbank-Administrator übertragen.
Dynamische Plattenplatzverwaltung für DOS
Es liegt auf der Hand, daß nicht jeder Benutzer die gleichen Vor- oder Nachteile aus der Anwendung von VSAM zieht Umfragen haben folgende Schwerpunkte ergeben:
- "Key sequenced data sets" müssen weit weniger oft reorganisiert werden als ISAM-Dateien. Das hängt damit zusammen, daß VSAM keinen Überlaufbereich kennt und daß Sätze physisch gelöscht werden können. Das kann zur Folge haben, daß im Batch-Betrieb Programmdurchlaufzeiten und im Online-Betrieb Antwortzeiten weniger großen Schwankungen unterworfen sind.
- Eine weitere VSAM-Eigenschaft, die vielen Anwendern Vorteile gebracht hat ist die dynamische Platzverwaltung auf Platten. Ich glaube, daß dies sogar der größte Gewinn für einen DOS/VS-Benutzer ist. Wer kennt nicht das mühevolle Anpassen der Job-Control-Anweisungen, wenn ISAM-Dateien überlaufen oder umgekehrt, wenn man bei einer Überprüfung der Plattenbelege feststellt, daß einzelne Datenbestände das Zwei- bis Dreifache des effektiv benötigten Platzes belegen. Das dynamische Plattenspeicher Konzept macht daher auch VSAM für den DOS-Benutzer attraktiver als für den OS-Anwender, der diese Möglichkeit schon immer kannte.
- Ein wichtiges Moment ist die VSAM Kompatibilität zwischen DOS/VS uz OS/VS. Als Beispiel sei hier eine größere Bank genannt, die ihr System 370/158 von DOS/VS auf OS/VS umstellte. Dabei war sie gezwungen, während eines Jahres unter VM 370 einen Parallelbetrieb aufrechtzuerhalten. Da man in dieser Installation ein generelles Input/Output-Modul für den VSAM-Zugriff verwendet, beschrankten sieh die Umstellungsarbeiten für reine FSAM-Programme auf Umwandeln und Katalogisieren der DOS-Programme auf dem OS-System.
- Ebenfalls sehr gute Erfahrungen haben jene Anwender gemacht, die in Jüngster Zeit von 3330 Platten auf 3344 Oder 3350 umgestellt haben. Auch wenn alle Plattensysteme parallel nebeneinander verwendet wurden, waren keinerlei Eingriffe notwendig. Die absolute Kompatibilität zwischen DOS/VS und OS/VS sowie zwischen den verschiedenen Platteneinheiten ist hier für IBM-Benutzer wohl erstmalig vorbehaltlos realisiert worden.
- Ebenfalls als Positivum ist das sehr komfortable Dienstprogramm, die Access Method Services (AMS), zu werten. Dieses parametrierbare Programm kann unter anderem: VSAM-Dateien im Katalog definieren, verändern und entfernen; den Inhalt der Kataloge sichtbar machen Alternate Indices für VSAM-Dateien generieren.
Obschon die Parametersprache nicht ganz einfach ist, arbeiten Programmierer Analytiker und Systembediener nach kurzer Eingewöhnungszeit sehr gerne mit diesem Instrument. Es ist dabei von großem Vorteil, daß alle Funktionen mit einem Programm und mit einheitlicher Kodierung ausgeführt werden können. Die bisherigen Dienstprogramme, die eine nicht sehr rühmliche Geschichte haben, sind weitgehend abgelöst worden.
VSAM-Pflege durch teure Systemprogrammierer
Daneben gibt es aber gewisse Momente, die wir als nachteilig bewerten können.
- Der wichtigste Nachteil wurde bereits genannt: VSAM-Dateien benötigen dauernde Pflege durch kompetente und damit auch teure Systemprogrammierer. So läßt sich VSAM von normalen Anwendungsprogrammierern besonders in höheren Programmiersprachen leicht anwenden, bietet aber erhebliche Schwierigkeiten, wenn optimal gearbeitet werden soll oder wenn im Assembler programmiert wird .
- Etwas näher wollen wir auch einen alten Zankapfel beleuchten: Die Verarbeitungsgeschwindigkeit. Hier müssen wir unbedingt differenzieren. Es genügt nämlich nicht zu sagen: VSAM ist langsam! Es ist sehr leicht zu beweisen, daß VSAM Verarbeitungen dreimal schneller laufen können als konventionelle Lösungen. Auf einen Nenner gebracht müßte die Aussage lauten: Bei direktem Zugriff ist VSAM unter normalen Bedingungen immer schneller als ISAM. Beim Hinzufügen von Sätzen kann das Verhältnis bis 3:1 zugunsten VSAM lauten.
- Wenn wir vorhin gesagt haben, daß die Verarbeitungsgeschwindigkeit unter VSAM mit mehr und größeren Puffern verbessert werden kann, so sind wir damit bei einem weiteren Problem angelangt: Die Größe des Hauptspeichers. Größere Speicher machen VSAM nicht schneller, vermindern aber die Paginrate.
So hat man zum Beispiel bei der eingangs erwähnten 370/125 beim Ausbau von 256 Kilobytes auf 512 Kilobytes eine durchschnittliche Leistungsverbesserung von 37 Prozent erreicht. Der weitaus größte Teil der täglichen Programme benötigen 30 bis 50 Prozent weniger Verweilzeit bei gleicher Umgebung.
ISAM/VSAM-Interface
Das heißt aber auch: Anwender, die die maximale Ausbaustufe ihres Systems erreicht haben, werden bei Umstellung auf VSAM gewisse Leistungseinbußen erfahren. In diesem Fall bleibt kaum etwas anderes übrig, als entweder unnötigen Balast aus den Anwendungen entfernen oder dann auf ein größeres System umzusteigen.
Mit der Standard Software stellt der Hersteller kostenlos ein Programmprodukt zur Verfügung, das ISAM Programme nur durch Umstellen der Job Control-Anweisungen unter VSAM verarbeitet.
Es handelt sich dabei nicht etwa um eine Simulation oder Emulation, sondern beim Eröffnen der Dateien wird festgestellt, daß sich die ISAM Angaben im Programm auf eine VSAM Datei beziehen.
Das ISAM Interface Programm arbeitet sehr zuverlässig. Ich habe selbst einmal eine Umstellung von 32 ISAM Dateien auf VSAM auf diese Art und Weise durchgeführt, wobei nur zwei leichte Probleme auftraten:
- Die Fehlermeldungen, die im Zusammenhang mit Dateien auftreten können sind etwas dürftig. Man sieht nicht immer ohne weiteres, welche Datei den Fehler verursacht hat.
- wenn ungeblockte VSAM Dateien über das Interface Programm geladen werden wird automatisch der Satz um die Länge des Schlüssels verlängert, weil dieser vor den eigentlichen Daten zusätzlich angefügt wird.
Solange solche Dateien nur über das Interface Programm bearbeitet werden passiert nichts. Wenn man aber im Original VSAM Modus zugreift, muß man der Verlängerung des Satzes Rechnung tragen.
Auf dem Softwaremarkt werden zwei Produkte angeboten, die den VSAM Zugriff erleichtern. Beide Produkte wurden in der Schweiz entwickelt, und zwar aus folgenden Überlegungen:
- Input/Output Operationen sind am anfälligsten für Inkompatibilitäten Um möglichst unabhängig zu sein, verlegt man sie daher mit Vorteil in ein zentrales Module außerhalb des Programms. Fällige Änderungen können dann leicht an einem Ort ausgeführt werden.
- Gewisse VSAM Funktionen lassen sieh f nur im Assembler ausführen oder laufen in höheren Programmiersprache langsam. Mit Input/Output Moduln kann man solche Funktionen auch dem Programmierer, der nur in einer höheren Sprache arbeitet, verfügbar machen.
- Der Zugriff auf VSAM Dateien wird ähnlich wie auf Datenbanken. Der Programmierer läßt sich auf Grund eines Funktionscodes Daten zur Verfügung stellen, ohne den Zugriffsmechanismus im einzelnen zu kennen.