XTF - Pooling von Band- und Kassettenbeständen
Detailinformationen
Arbeitsweise
XTF wird nach dem VSE IPL in einer Partition gestartet in der es dann
permanent läuft. Diverse Optionen wie z. B. Blockgröße
der von XTF zu schreibenden Bandbestände (Container Dateien), Anzahl zu
simulierender Kassetteneinheiten etc. können beim Startup
spezifiziert werden.
Erkennt XTF einen I/O auf eine unter seiner Kontrolle stehenden
Kassetteneinheiten, simuliert XTF diesen I/O.
(XTF physiche Sicht bei z.B. 4 Programmen)
Bei Ausgabe auf eine virtuelle Kassette (auf einer virtuellen Einheit)
werden die Blöcke - evtl. zusammen mit den Blöcken anderer
virtueller Kassetten - zusammengefaßt und auf eine reale Kassette
geschrieben.
Soll eine virtuelle Kassette gelesen werden, wird von XTF die reale
Datei (Container Datei), in der sich die virtuelle Kassette befindet,
eröffnet.
Zusätzlich besteht die Möglichkeit, eine virtuelle Kassette -
entweder bereits während der Ausgabe oder erst nach der Erstellung
- in einem Dataspace abzustellen (ein Dataspace ist virtueller Speicher,
der vom Betriebssystem verwaltet wird). Zu dem Zeitpunkt, da die
virtuelle Kassette gelesen werden soll, kann XTF die Daten direkt aus
dem Dataspace zur Verfügung stellen. Dadurch ist es möglich
dieselbe Kassette gleichzeitig von mehreren Programmen zu lesen
Die Anzahl der gleichzeitig zu haltenden virtuellen Kassetten in
Dataspaces ist nur durch die vom Anwender definierte
Gesamtgröße der Dataspaces begrenzt.
Synergie mit BVS
XTF kennt Mount- und Demount-Befehle für virtuelle Kassetten und
stellt sich somit als "virtuelles" Roboter System dar.
Die BVS Unterstützung realer Roboter Systeme wurde auf das
"virtuelle" Roboter System XTF ausgedehnt.
Selbstverständlich erlaubt BVS die Koexistenz realer und virtueller
Roboter Systeme.
Bei Ausgabebeständen ist lediglich im Volser Feld des TLBL
Statements die Angabe VAULTx oder AUTOx erforderlich um XTF
anzusteuern.
Bei Eingabebeständen sucht BVS in seinem Katalog nach der
entsprechenden Generation/Version des zu lesenden Bestandes. Handelt es
sich um eine von einem Roboter bediente Kassette, sendet BVS über
sein Roboter Interface einen Mount Befehl an das Roboter System (in
diesem Falle XTF). Dieser Mount bewirkt das Eröffnen der realen
Container Datei.
Das Eröffnen einer Container Datei im XTF wird aus Sicht des BVS
wie ein herkömmliches Band-Open - evtl. unter Ansteuerung eines
realen Roboter Systems - behandelt.
Synergie mit anderen Bandverwaltungssytemen
für andere Bandverwaltungssysteme stellt XTF einen entsprechenden
Exit zur Verfügung, so dass bei Bandopen und -close evtl.
erforderliche Befehle an XTF gegeben werden um die von XTF simulierten
Kassetten auf virtuellen Einheiten zu montieren bzw. zu demontieren.
Für das Bandverwaltungssystem ist XTF somit vollkommen transparent.
Es behandelt reale und virtuelle Kassetten gleichermaßen.
.
Vorteile
Einsparung eines Roboter Systems oder Virtual Tape Servers, da die Kassettenkapazität voll ausgenutzt wird
Einsparung von realen Kassetteneinheiten durch Zusammenfassung von Ausgabebeständen
Einsparung an Kassetten
a) geringere Anschaffungskosten
b) kleineres Archiv
verstärktes Multi-Programming durch die Beseitigung der Engpäße bei Kassetteneinheiten
Performancegewinn durch verkürztes Mountverfahren
drastische Reduzierung der realen Band I/Os durch
a) Pufferung der Daten bis zu 64K
b) Schreiben mehrerer Blöcke pro I/O
Nutzung von Data in Memory (ohne Programmänderungen) durch Spooling von Bandbeständen in Dataspaces
in Dataspaces abgestellte Bestände können gleichzeitig von mehreren Programmen gelesen werden
Problemloser Einsatz unter einem Bandverwaltungssystem da sich XTF als virtueller Roboter darstellt
Bedienerfreundlich, da XTF nur 4 Systembefehle benötigt
Hier geht es zurück zu den allgemeinen Informationen:
Um die Kurzbroschüre im PDF Format herunterzuladen
auf das Icon zeigen, rechte Maustaste klicken und
'Ziel speichern unter' auswählen; zum Anzeigen
linke Maustaste klicken.