Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Anwenderbericht Papierwerke Waldhof-Aschaffenburg AG, Raubling:

JAWS: Dynamische Work file-Verwaltung unter DOS

22.09.1978

Zur Optimierung der Plattenarbeitsdateiverwaltung unter DOS/VS im Rechenzentrum der Papierwerke Waldhof-Aschaffenburg in Raubling/Obb. wird JAWS, ein Softwarepaket aus eigener Entwicklung, eingesetzt. JAWS (JCL exit controlled Allocation of dasd Workfile Space) läuft bei PWA auf einem Duplex-System IBM 148/145 und ist für 5000 Mark inklusive einjähriger Wartung zu kaufen.

Es gibt ein Problem, das fast so alt wie die DOS-Mehrpartition-Welt selbst ist: Wie ist es möglich, Arbeitsdateien auf Magnetplatten so unterzubringen, daß die Arbeitsvorbereitung auf der einen Seite nicht durch ständige Überwachungs- und JCL-Änderungsarbeiten in Atem gehalten wird, auf der anderen Seite jedoch die zur Verfügung stehenden Systemresourcen (sprich: Plattenkapazität) einigermaßen günstig ausgenutzt werden? Die Lösung erscheint zunächst einfach: Der findige Systemprogrammierer teilt jeder Partition feste Magnetplatten oder Teile derselben zu und weist die AV an, den JCL entsprechend anzupassen. Nach einiger Zeit wird jedoch ein spitzer Blei- oder gar Rotstift entdecken, daß einmal festgelegte Platteneinheiten oder

-bereiche nur selten oder schlecht genutzt werden (Schlagwort: Redundanz), andererseits jedoch seitens der AV Wehklagen ertönt, daß dem einen oder anderen Job der der Partition zur Verfügung stehende Arbeitsbereich beim besten Willen nicht ausreicht. Die fleißige IBM Systementwicklung tut ein übriges dadurch, daß sie (gottlob) dem Anwender immer neue Partitions zur Verfügung stellt, was bei oben genanntem Konzept den zuständigen IBM-VB nur zufrieden lächeln laßt.

Was also tun? Die Losung heißt "wieder weg von unflexiblem Partition/Arbeitsbereich-Konzept". Die Schwierigkeit besteht darin, das relativ starre DOS JCL-Konzept zu dynamisieren, um - wie vorausgeschickt - der AV nicht dauernde JCL-Änderungen aufzubürden.

Wir setzten uns folgende Ziele:

þEs sollte die Möglichkeit bestehen, einen "Gesamtarbeitsbereich" (eine oder mehrere Platten) von allen Partitions aus gleichzeitig und dynamisch zu benutzen.

þDie Job-Control-Karten unabhängig von Partitions, Plattennamen und -bereichen zu machen.

þDie Große einer Arbeitsdatei sollte ohne Verwendung von physischen Plattenadressen nicht auf Plattengröße beschränkt sein.

þArbeitsdateien müssen über bestimmte, festzulegende Zeiträume hinweg verfügbar bleiben.

þArbeitsdateien müssen zu einem frei wählbaren Zeitpunkt löschbar sein.

þEs muß eine befriedigende Restartmöglichkeit vorhanden sein.

þDer Job Control darf seine DOS/VS-Verträglichkeit nicht verlieren.

Die Kluft zwischen unseren (anspruchsvollen) Plänen und der Realität wurde durch die Schaffung einiger Voraussetzungen bereits etwas geschlossen:

- Bereitstellung des erwähnten "Gesamtarbeitsbereiches", bei uns im Hause JAWS-Pool genannt, der im Normalfall vier 3340 Einheiten in Anspruch nimmt.

- Organisatorische Festlegung, welche Dateien Arbeitsdateien, also kurz- bis mittelfristig existierende Dateien sind.

- Schaffung beziehungsweise Erweiterung eines bestehenden DOS/VS Job Control Exits (Größe je nach Ausbaustufe zwischen 5 und 10 K).

Die Grundlage des JAWS-Systems ist die Möglichkeit mit Hilfe des DOS/VS Job Control Exits DLBL und EXTENT sowie ASSGN Karten zu modifizieren.

Anhand bestimmter Merkmale im Dataset-Namen einer DBL-Karte ist der JCL-Exit in der Lage, JAWS-Dateien zu identifizieren und durch ein Kennzeichen, das in den DSN übertragen wird, die Partitioneindeutigkeit herzustellen. Mit Hilfe verschiedener, im JCL Exit gespeicherter Tabellen ist es möglich, zu überprüfen, ob eine JAWS-Datei bereits vorhanden oder neu anzulegen ist. Ist sie noch nicht vorhanden, wird im JAWS-Pool über Optimierungskriterien nach einem Bereich gesucht, der die Datei aufnehmen kann. Die von JAWS erzeugte relative Spurnummer und der Name, auf die die Platte gelegt wird, werden intern in die Extentkarte übernommen. Ist die JAWS-Datei bereits angelegt, werden nur die Bereichsinformationen aus der Tabelle entnommen und in die EXTENT-Karte übertragen.

Der Forderung einer variablen Verfügbarkeitsdauer einer JAWS-Datei wurde mit Hilfe eines Kennzeichens im DSN entsprochen. Es gibt die Möglichkeit, eine Datei

þbeliebig lange

þmaximal einen Tag

þbis zum nächsten Job-Ende (/&-Karte)

zu erhalten. Jede JAWS-Datei kann zu einem beliebigen Zeitpunkt durch einen speziellen "Release-Parameter" in der DLBL-Karte freigegeben werden.

Endet ein Job abnormal, so können einem späteren Restart alle JAWS-Dateien durch einen Operator-Befehl erhalten werden. Voraussetzung hierfür ist allerdings, daß der Restart in der gleichen Partition anläuft, in der der Job abnormal endete.

Alle manuellen Änderungen der Job-Control-Karten beschränken sich auf den Dataset-Namen oder sind so angebracht, daß sie vom DOS JCL als Kommentar betrachtet werden. Auf diese Weise ist es gelungen, den JCL voll DOS/VS kompatibel zu erhalten.

Die eigentlichen UmstelIungsarbeiten bestanden für die Arbeitsvorbereitung in der (einmaligen) Änderung des Job Controls der für die JAWS-Verwaltung vorgesehenen Dateien. Die Umstellung wurde ohne Termindruck kontinuierlich für alle eingesetzten Sachgebiete durchgeführt.

Ein vorübergehender Mehrbedarf an Plattenkapazität wurde durch eine Verkleinerung des JAWS-Pools fast ausgeglichen. Die Maschinenbelastung wurde durch JAWS nicht meßbar gesteigert, da sich der JCL-Exit in der SVA befindet und in ihm keine SVC's verwendet werden.

Die Gesamtsicherheit des JAWS-Systems wird durch ein Batch-Programm gewährleistet, das in der Lage ist, jederzeit die Tabellen des JCL-Exits dem aktuellen Stand des JAWS-Pools anzugleichen.

Rückblickend kann festgestellt werden, daß bei konsequentem Einsatz des JAWS-Systems der Plattenbedarf für Workfiles erheblich eingeschränkt werden konnte. Ein weiterer Vorteil ergab sich durch die problemlose Übergangsmöglichkeit von Jobs von einer CPU auf die andere des bei uns im Hause eingesetzten Duplex-Systems.

Übrigens: Wir freuen uns auf jede weitere Partition, die IBM dem Anwender zur Verfügung stellt. Unser JAWS wartet nur darauf ...