White Paper: BS2000/OSD V7.0 (de) - Fujitsu

BS2000/OSD V7.0
Ausgabe April 2009
Seiten 20
Wirtschaftlichkeit, Innovationskraft, Offenheit und Kontinuität stehen bei der Weiterentwicklung von BS2000/OSD im
Vordergrund. In der BS2000/OSD V7.0 liegen die Schwerpunkte in folgenden Aspekten:
• Datenwachstum, Daten- und Backup-Management im Sinne des ILM (Information Lifecycle Management)
• Datenreplikate und deren Einbindung in die BS2000-Storage-Management-Software
• SAN Integration und autonome, dynamische Steuerung von I/O-Ressourcen
• Selbstregulierende Funktionen für den einfacheren und effektiveren Betrieb des BS2000
• Unicode: Zusätzliche Zeichensätze für den europäischen Sprachraum
Wesentliche funktionale Erweiterungen von BS2000/OSD-BC V7.0 betreffen:
Neue Hardware
• Server-Unterstützung: Neue Business Server S165 und S200 der S-Serie, neue Business Server SX100-D und SX160
der SX-Serie
• Peripherie-Unterstützung: LTO-3 MBK-Geräte, Library-System Scalar i500 mit LTO-3 MBK-Geräten in Verbindung mit
ROBAR V6.0
Verbesserte Storage-Integration / Storage-Virtualisierung / Storage on Demand
• Neue Symmetrix DMX-Funktionen Snap und Clone: Unterstützung in SHC-OSD, PVSREN, Save/Restore to/from
Snapsets
• Online Provisioning für Pubsets
Verbesserte SAN-Integration und I/O-Ressourcensteuerung
• SAN Check-Funktion
• I/O-Prioritäten-Steuerung für Tasks
• Dynamische I/O-Lastverteilung für Platten am FC-Kanal
• Optimierte Lastverteilung im CentricStor-Betrieb
• Begrenzung der I/O-Aufnahme einzelner VM2000-Gastsysteme
Offenheit
• Erweiterte Unterstützung von Zeichensätzen und Zeichencodes: CCS-Defaultierung, Unicode
• Neue Versionen POSIX A39, Apache V2.2, Java V5.0, WebTransactions for OSD V7.1
Allgemeine Lieferfreigabe von BS2000/OSD-BC V7.0: 3.2007
Im Zeitrahmen der BS2000/OSD-BC V7.0 erfolgt auch die Freigabe neuer Versionen von SW-Produkten. Für einige
ausgewählte Produkte (AVAS, FDDRL, HSMS, MAREN, ROBAR, SHC-OSD und VM2000) sind hier ebenfalls die
wesentlichen Funktionserweiterungen dargestellt.
Stand der Beschreibung: Juli 2007

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 2 / 20
Inhalt
Hardwareunterstützung 3
Unterstützung der BS2000/OSD Business Server der S-Serie und der SX-Serie 3
Server-Unterstützung: S-Server S165 und S200 3
Server-Unterstützung: SX-Server SX100-D und SX160 3
Peripherie-Unterstützung: LTO-3 MBK-Geräte 3
Library-System Scalar i500 mit LTO-3 MBK-Geräten in Verbindung mit ROBAR V6.0 3
Verbesserte Storage-Integration / Storage-Virtualisierung / Storage on Demand 4
Unterstützung neuer Symmetrix DMX-Funktionen TimeFinder Snap und Clone 4
HW-Funktionalität und Einsatzszenarien 4
Unterstützung von Snap und Clone in SHC-OSD ab V6.0 5
Save/Restore to / from Snapsets 5
Unterstützung von Clone (und Snap) in PVSREN 5
Unterstützung von Snap und Clone in HSMS/ARCHIVE V8.0B 5
Online Provisioning für Pubsets: SPACEPRO 6
Konsistente Spiegelung von SF- und SM-Pubsets 7
Erweiterungen der System Managed Storage-Funktionen 7
Verlagerung von Dateien auf der online Verarbeitungsebene 7
Erweiterungen im Dienstprogramm PVSREN 7
Verbesserte SAN-Unterstützung und I/O-Ressourcensteuerung 8
SAN Check-Funktion 8
Autonome, dynamische Steuerung von I/O-Ressourcen (IORM) 8
I/O-Prioritäten-Steuerung für Tasks (IORM-Funktion I/O Priority Handling for Tasks) 9
Dynamische I/O-Lastverteilung für Platten am FC-Kanal (IORM-Funktion Dynamic Parallel Access Volume) 9
Optimierte Lastverteilung im CentricStor-Betrieb (IORM-Funktion Dynamic Device Allocation) 9
Begrenzung der IO-Aufnahme einzelner VM2000-Gastsysteme (IORM-Funktion I/O Limit for Virtual Machines) 9
Schalten der Komprimierung bei LTO-Geräten (IORM-Funktion TCOM Tape Compression) 10
Verfügbarkeit 10
MONJV für laufenden Job 10
Parallelisierung der Tape-Monitor-Task 10
Vergrößerung des rekonfigurierbaren Arbeitsspeichers unter VM2000 bei SX160 10
Neues Subsystem ASE (Auxiliary SERSLOG Extension) zur Systemdiagnose 10
Offenheit 11
Erweiterte Unterstützung von Zeichensätzen und Zeichencodes 11
CCS-Defaultierung 11
Unicode-Unterstützung im BS2000/OSD 12
POSIX A39 13
Apache V2.2 14
Java V5.0 14
WebTransactions for OSD V7.1 14
Erweiterungen in SW-Produkten 15
AVAS V8.0 15
FDDRL V16.0 15
HSMS/ARCHIVE V8.0B 15
MAREN V11.0 16
Parameter-Änderungen sofort wirksam 16
Wechseln der Exits im laufenden Betrieb 16
MAREN ablauffähig ohne TSOS 16
Volume-Gruppen 16
ROBAR V6.0 17
Reduzierung des Net Traffic zwischen ROBAR-CL und ROBAR-SV 17
Unterstützung zusätzlicher Menü-Fenster in ROBAR-SV 17
Verbesserung der Benutzeroberfläche bezüglich Fehlermeldungen und Warnungen 17
Unterstützung der Library Scalar i500 17
Einführung einer neuen HW/SW-Plattform (Primergy/Linux) für ROBAR-SV 17
SHC-OSD V6.0 17
SHC-OSD V6.1 18
VM2000 V9.0 18
VM-Zuordnung von Pubsets 18
Feinere Privilegierung für die implizite Zuordnung von Geräten 18
Unterstützung von Snapsets 18
Verbesserte Unterstützung sehr großer Konfigurationen 18
Shutdown für einzelne VMs und koordiniert für das gesamte VM2000 19
Verbessertes Performance Monitoring mit SHOW-VM-STATUS 19
SW-Produktübersicht 19

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 3 / 20
Hardwareunterstützung
Unterstützung der BS2000/OSD Business Server der S-Serie und der SX-Serie
BS2000/OSD-BC V7.0 unterstützt alle freigegebenen Server der S-Serie und der SX-Serie. Für die SX-Server wird die auf die
SPARC64-Architektur portierte Ausprägung des BS2000/OSD-BC V7.0 als Bestandteil des OSD Extended Configuration
Pakets OSD/XC V3.0 als Folgeversion der bestehenden OSD/XC V2.x Pakete freigegeben. Als Trägersystem fungiert weiterhin
die bereits freigegebene X2000 Version 3.0, die auf Solaris 8 basiert.
Server-Unterstützung: S-Server S165 und S200
BS2000/OSD-BC V7.0 unterstützt die neuen Server S165 und S200 der S-Serie. Im oberen Leistungsbereich bedient
BS2000/OSD-BC V7.0 damit /390-Architektur-basierte BS2000/OSD-Server mit einer Leistung von bis zu 4.300 RPF. Die
Pilotfreigabe dieser Server ist im Mai 2007 erfolgt.
Die Server S165 und S200 werden auch für den Einsatz unter BS2000/OSD-BC V5.0 und V6.0 freigegeben.
Server-Unterstützung: SX-Server SX100-D und SX160
BS2000/OSD-BC V7.0 unterstützt die neuen Server SX100-D und SX160 der SX-Serie. Das Trägersystem X2000 wurde zur
Unterstützung der SX100-D und SX160 auf Solaris 10 rebasiert (X2000 V4.0). Die SX160 bietet damit im Vergleich zur SX150
eine erhebliche Steigerung in der Multiprozessorleistung und somit eine wesentlich erweiterte Systemskalierbarkeit.
Die Pilotfreigabe dieser Server ist im Juli 2007 erfolgt.
Peripherie-Unterstützung: LTO-3 MBK-Geräte
In der BS2000/OSD-BC V7.0 wird zusätzlich zu den bisherigen LTO-Gerätetypen LTO-1 und LTO-2 der Gerätetyp LTO-3
unterstützt. Mit dem LTO-3-Gerät kommen auch neue Magnetbandkassetten mit 512 Spuren und einer Kapazität von 400 GB
unkomprimiert (neuer Volumetyp TAPE-U3).
LTO-3-Geräte sind für den Betrieb an SX- und S-Servern am FC-Kanal in Verbindung mit einem Quantum/ADIC Librarysystem
Scalar 10K, i2000 oder i500 (s.unten) vorgesehen. Außerdem können LTO-3-Geräte an SX-Servern in einer über FC
angeschlossenen Library FibreCAT TX24 betrieben werden.
Beim Direktanschluss (d.h. ohne CentricStor) der hochperformanten LTO-3-Geräte an einen BS2000-Host ist eine
ausgewogene Konfiguration Vorbedingung, d.h. auch eine schnelle Plattenperipherie ist erforderlich, die Platten müssen über
FC-Kanal angeschlossen sein.
Um die hohen Datenraten von LTO-3-Geräten (die maximale Datenrate beträgt 80 MB/sec (unkomprimiert)) adäquat zu
bedienen, wurden neue Versionen der BS2000-Sicherungsprodukte freigegeben, die durch Parallelisierung von Plattenzugriffen
eine entsprechende Performance auf der Plattenseite bereitstellen. HSMS und ARCHIVE parallelisieren in der V8.0B
Plattenzugriffe, indem sie auf S-Servern das Feature PAV (Parallel Access Volume) und auf SX-Servern die I/O-Parallelisierung
im Feature RSC nutzen. BS2000/OSD-BC V7.0 erweitert die I/O-Parallelisierung beim Aufruf von RSC auf bis zu 6 parallele
Geräte. FDDRL unterstützt in der V16.0 neben der I/O-Parallelisierung das gleichzeitige Sichern von zwei Platten auf ein Band
(Multiplexing.
Die Freigabe ist für OSD V6.0 und OSD V7.0 erfolgt (Details siehe in den jeweiligen Produkt-Kapiteln).
Liegt keine optimale Plattenkonfiguration vor, so kann mit dem neuen I/O-Ressource-Manager IORM die standardmäßige
Komprimierungsfunktion der LTO-3-Geräte ausgeschaltet werden, um die für das Streaming der LTO-3-Bänder erforderliche
Mindestdatenrate herabzusetzen (Details siehe IORM-Funktion TCOM Tape Compression auf Seite 10).
Weitere Details siehe White Paper „Effizienter Peripheriebetrieb mit BS2000/OSD“
http://docs.ts.fujitsu.com/dl.aspx?id=3f063b99-ad7c-4b86-9783-558636baa846
Im CentricStor ist der Anschluss von LTO-3-Geräten ab der Version V3.1 seit November 2005 möglich.
Library-System Scalar i500 mit LTO-3 MBK-Geräten in Verbindung mit ROBAR V6.0
Die intelligente Scalar® i500 ist eine Midrange Library mit branchenführender Skalierbarkeit, Performance und Zuverlässigkeit.
Basierend auf der iPlatform-Architektur wurden fortschrittliche Backup-Funktionen direkt in die Library integriert, um die
allgemeine Datensicherheit zu erhöhen, das Management zu vereinfachen, den Bedarf an externen Servern und Software zu
verringern sowie den Zeit- und Kostenaufwand über die gesamte Lebensdauer des Backup-Systems hinweg zu minimieren.
Capacity-on-Demand-Skalierbarkeit ermöglicht dem Anwender, die Kapazität der Scalar i500 schrittweise um jeweils 46 Slots
von 36 auf 404 Datenträgerstellplätze zu erweitern. In die Scalar i500 Systeme sind LTO-3-Laufwerke integriert.
Die Archivsoftware ROBAR dient der Kommunikation zwischen BS2000-System(en) und dem Archivsystem. ROBAR setzt die
Geräte- und Trägeranforderungen von System- und Benutzerprozessen in Befehle zur Archivsteuerung um. Die Steuerung des
neuen Archivsystems Scalar i500 wurde in der neuen ROBAR-Version V6.0 implementiert.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 4 / 20
Verbesserte Storage-Integration / Storage-Virtualisierung /
Storage on Demand
Unterstützung neuer Symmetrix DMX-Funktionen TimeFinder Snap und Clone
HW-Funktionalität und Einsatzszenarien
Für die Symmetrix DMX-Speichersysteme bietet EMC zusätzlich zu den Replikationsverfahren SRDF und Timefinder/Mirror
(bisher und im Folgenden als BCV bezeichnet) die neuen Symmetrix-internen Replikationsmechanismen Timefinder/Snap und
Timefinder/Clone an.
TimeFinder/Snap realisiert eine virtuelle Kopie eines logischen Volumes zu einem beliebigen Snap(shot)-Zeitpunkt wie folgt:
TimeFinder/Snap sichert den Inhalt des Volumes, indem er bei der ersten Modifikation eines Blockes den ursprünglichen Inhalt
in einen speziellen Symmetrix-Bereich, den Save-Pool schreibt („copy on first write“-Technik).
Beim Restore wird der ursprüngliche Zustand wieder hergestellt, indem die Differenzblöcke aus dem Save-Pool auf das Volume
zurückgeschrieben werden.
Der Save-Pool ist standardmäßig als ein einziger Default-Pool vorhanden. In der Symmetrix DMX ab Enginuity 5671 können
außer dem Default-Pool noch weitere Save-Pools eingerichtet werden. Damit kann eine Partitionierung des Snap-Bereichs
realisiert und verschiedene Snaps können voneinander abgeschottet werden.
Für Snaps ist deutlich weniger Plattenplatz erforderlich als für BCV. Bei mehreren aufeinander folgenden Snaps für ein Volume
werden jeweils nur die Originale der gegenüber dem nächst älteren Stand modifizierten Blöcke abgespeichert. Zu einem
Volume können maximal 15 auf einander folgende Snaps erzeugt werden. Ab Enginuity 5772-Update voraussichtlich im 3.Q.07
wird der Maximalwert auf 127 Snaps erweitert.
Im Unterschied zu BCV ist bei Snap kein Vorlauf zum Erstellen einer Kopie notwendig.
Primäres Einsatz-Szenario für Timefinder/Snap ist das schnelle und effiziente Backup und Restore von Platte, daneben ist die
Nutzung als Input für die Bandsicherung und als freie Platten-Kopie (nur für Lesezugriffe) möglich.
TimeFinder/Snaps und TimeFinder/Clones
Original-
Volume
Volume
A
Track A
Sicht auf das
Produktions-Volume
BCV /
Clone
Track B
Track C
Point-in-time
Spiegel
Save Area
Point-in-time
Snap
EMC TimeFinder/Mirror (BCV) oder TimeFinder/Clone
• Vollständige Kopien
• Benötigt 100% Zusatz-Kapazität
• Unabhängiger Zugriff der Anwendungen zu den
Volumes
TimeFinder/Snap
• Pointer-basierende Kopien
• Benötigt ~30% Zusatz-Kapazität
• Shared Zugriff der Anwendungen zu den
Volumes
Quelle: EMC 2
TimeFinder/Clone ist eine flexible, leistungsfähige Methode zur Erstellung von Kopien ganzer Symmetrix-DMX Volumes.
Eine „Clone-Unit“ ist aus Anwendersicht eine sofort verfügbare Kopie eines Volumes. Im Unterschied zu BCV ist bei Clone kein
Vorlauf zum Erstellen einer Kopie notwendig, da bei Clones mit der „copy on access“-Technik gearbeitet wird:
TimeFinder/Clone kopiert jeweils die Spuren auf die Clone-Unit, auf welche schreibend an einer Unit des Clone-Paars oder
lesend an der Clone-Unit zugegriffen wird.
Zwei Betriebsarten sind möglich:
• Clone kann generell (nur) im „copy on access“-Modus arbeiten (Kopie als Snapshot) oder
• Das Speichersubsystem kopiert das gesamte Volume im Hintergrund auf die Clone-Unit.
In beiden Fällen benötigt TimeFinder/Clone 100% zusätzlichen Plattenplatz.
Im Gegensatz zu BCV-Paaren (Original Unit + BCV-Unit) bestehen Clone-Paare nicht aus vordefinierten Unit-Typen, die wie die
BCV-Units eigens konfiguriert und vorgehalten werden müssen. Nach Aufhebung der Paarbeziehung „Clone-Paar“ können die
beiden Units des (ehemaligen) Paars frei verwendet werden. Insbesondere können auch neue Clone-Paare gebildet werden.
Positionierung Clone vs. BCV
TimeFinder/Clone bietet alles, was ein Kunde zur Erstellung von Daten-Replikaten für die parallele Verarbeitung benötigt.
Clones werden (wie heute BCVs) als Input für die Bandsicherung und als freie Platten-Kopie genutzt. In einigen Fällen bietet
Clone sogar mehr als BCV. Wesentlicher Vorteil der Clones ist ihre Flexibilität: es sind keine speziell vorkonfigurierten BCVs
notwendig. Ein Clone kann Original für eine weitere Clone-Session werden, ein BCV bleibt immer ein Spiegel.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 5 / 20
TimeFinder/Mirror (BCV) ist weiterhin eine gute Lösung für Umgebungen, in denen sehr hohe Performance und Verfügbarkeit
nur mit echten Spiegel-Volumes gewährleistet werden können.
Unterstützung von Snap und Clone in SHC-OSD ab V6.0
Die Integration von Snap und Clones in SHC-OSD erfolgt mit der Version SHC-OSD V6.0. Im Einzelnen sind folgende
Funktionen verfügbar:
• Implementierung der Session-Aktionen (Start, Stop, Activate, Restore, Restart-Clone)
• Informations-Funktion zu den Snap/Clone-Sessions
• Integrationsfunktionen für HSMS wie Sonder-Umbenennung, Auswahl der Snap-Liste, Bearbeitung von VSN-Listen, etc.
• Integration mit der SRDF-Familie (z.B. Snap von SRDF-Target)
• Support für CKD- und FBA-Platten
• Monitoring: Überwachung der Nutzung des Save-Pools der Symmetrix, Ausgabe von Warnmeldungen an die Konsole beim
Erreichen oder Ändern von gewissen Füllgraden.
Save/Restore to / from Snapsets
BS2000/OSD-BC V7.0 unterstützt Snapshot-orientierte Backup-Restore-Szenarien in DMX-Konfigurationen. Die für Restore
nutzbare virtuelle Kopie eines Pubsets besteht aus den gleichzeitig erzeugten Snap-Units für alle Volumes des Pubsets. Die
Snap-Unit ist ein virtuelles Gerät, das die Pointer auf die ursprünglichen Daten enthält. Für unveränderte Daten zeigen die
Pointer auf das (Original-)Volume, für veränderte Daten zeigen die Pointer auf den Save Pool. Snap-Units sind sowohl im
Plattensubsystem als auch im IORSF der S-Server bzw. der X2000-Gerätekonfiguration der SX-Server zu konfigurieren.
Eine solche Pubset-Kopie aus Snap-Units wird im Folgenden „Snapset“ genannt. Snapsets sind keine vollwertigen Pubsets,
sondern Pubsetspiegel, auf die lesend zugegriffen werden kann, und zwar nur um einzelne Dateien und ganze Pubsets zu
restaurieren. Snapsets werden als Spezial-Pubsets realisiert, die Adressierung erfolgt über eine an die Originalnotation
angelehnte “Pseudonotation“, ein DMS-Zugriff durch normale Benutzer-Anwendungen ist nicht möglich (also kein normaler
IMPORT).
Für einen Pubset können mit den aktuell freigegebenen Enginuity-Versionen maximal 15 Snapsets verwaltet werden. Als
Vorleistung für die Erweiterung ab dem Enginuity 5772-Update sind in BS2000/OSD-BC V7.0 bereits 26 Snapsets
implementiert.
Snapsets werden durch den Administrator erzeugt und gelöscht mittels der neuen Kommandos CREATE-SNAPSET, DELETE-
SNAPSET; der Administrator kann mit dem Kommando RESTORE-PUBSET-FROM- SNAPSET ein gesamtes Pubset aus dem
letzten Snapset restaurieren. Diese Funktionen basieren intern auf den Funktionen zur TimeFinder/Snap-Steuerung in
SHC-OSD V6.0 (bzw. SHC-OSD V6.1 für Enginuity 5772).
Der Endanwender kann mit neuen DMS-Funktionen Einzeldateien und Jobvariablen aus den vorhandenen Snapsets
restaurieren. Dazu werden SHOW-Kommandos (SHOW-SNAPSET, LIST-FILES-FROM-SNAPSET, LIST-JVS-FROM-
SNAPSET) und Aktionskommandos (RESTORE-FILES-FROM-SNAPSET, RESTORE-JVS-FROM-SNAPSET) angeboten.
Auch LMS unterstützt mit der Nachtragsversion V3.3B das Restaurieren von Bibliothekselementen aus Snapsets.
Im Shared-Pubset-Betrieb können die Snapsets von allen Systemen aus genutzt werden.
In einem Katastrophenschutz-Szenario mit SRDF-Spiegelung können auch im Target-Speichersubsystem Snapsets geführt
werden.
Abgleich der Volumes bei Restore Pubset
Die volumebasierte Rekonstruktion von Pubsets erfolgt, indem der jüngste Snapset auf die Volumes des Pubset zurückkopiert
und anschließend die Spezial-VSNs in die Standard-VSNs zurückbenannt werden, mit Hilfe des neuen Kommandos
RESTORE-PUBSET-FROM-SNAPSET. Dabei wird berücksichtigt, dass die Anzahl der Volumes des Originalpubset größer als
die Anzahl der Volumes des Snapset sein kann, da ja Volumes dynamisch zu einem Pubset hinzugefügt werden können.
Restore Pubset ist nicht möglich, wenn das Pubset seit der Erstellung des Snapset verkleinert wurde.
Unterstützung von Snapsets in VM2000 V9.0
VM2000 V9.0 unterstützt Snap Units von Snapsets folgendermaßen:
• VM2000 zeigt Snap Units in seinen SHOW-Kommandos an.
• Das neue VM-Privileg AUTO-SNAP-ASSIGN erlaubt einer VM die implizite VM-Zuordnung (ASSIGN-BY-GUEST) einer Snap
Unit für ein Snapset, ohne dass der VM2000-Administrator einem solchen Gerät vorher das entsprechende ASSIGN-BY-
GUEST-Attribut per Kommando vergeben hat. D.h. eine VM kann sich bei entsprechender Privilegierung Snap Units für die
Snapsets automatisch zuordnen, ohne dass für diese Geräte in VM2000 eine Vorbereitung notwendig ist.
Unterstützung von Clone (und Snap) in PVSREN
Mit der Symmetrix Timefinder-Funktion Clone ist es möglich, Kopien eines Pubsets abzutrennen (Split). Sollen die getrennten
Pubsets parallel zu den Originalen verarbeitet werden, muss das Pubset vorher umbenannt werden. Dies ist in der
BS2000/OSD-BC V7.0 mit dem Programm PVSREN für SF-Pubsets und SM-Pubsets als Ausgangs-Pubsets möglich.
Außerdem wird in PVSREN auch die Erzeugung freier Pubsets auf Basis von Snaps unterstützt. Freie Pubsets auf Snap-Basis
sind (nur) für kurzfristige Nutzung mit vorwiegend lesendem Zugriff sinnvoll. Zur Erzeugung von Pubsets, die eine eigenständige
Existenz führen sollen, sind nur Clone-Kopien geeignet.
Unterstützung von Snap und Clone in HSMS/ARCHIVE V8.0B
Mit HSMS V8.0B wird die konventionelle Bandsicherung von Snapsets unterstützt. Dateien und JVs können von einem Snapset
in ein Backup-Archiv gesichert werden. Snapsets und konventionelle Archive sind getrennte Sicherungsbestände
(Unterscheidung durch den Anwender).
Clones werden (wie heute BCVs) als Input für die Bandsicherung genutzt.
An der Benutzerschnittstelle von HSMS wird nicht zwischen BCV und Clones unterschieden. Um die gleichwertige Verwendung
von BCV oder Clone als Plattenkopien auszudrücken, wird mit HSMS V8.0B in der HSMS-Anweisung //BACKUP-FILES beim
Operanden CONCURRENT-COPY=*YES die Angabe BY-ADD-MIRROR-UNIT ersetzt durch BY-ADDITIONAL-UNIT und die

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 6 / 20
Angabe RESUME-MIRRORING durch DISCARD-COPY. Die bisherigen Angaben werden aus Kompatibilitätsgründen weiterhin
unterstützt.
D.h. der Systemverwalter richtet die Clone-Session mit /START-CLONE-SESSION ein (analog zum Einrichten des BCV-
Spiegels mit /START-MULTI-MIRRORING). HSMS wird aufgerufen mit derselben Benutzerschnittstelle wie im Fall BCV, die
Unterscheidung nach BCV oder Clone erfolgt im CCOPY der BS2000/OSD-BC V7.0. Liegt Clone vor, dann erfolgt durch HSMS
intern über eine privilegierte Programmschnittstelle von SHC-OSD die Aktivierung der Clone-Paare (analog zum Auftrennen
der BCV-Paare mit Hilfe dieser Schnittstelle). Diese Nutzung setzt eine Enginuity-Version ab 5671 voraus.
Weitere Details siehe White Paper „Einsatz von Symmetrix TimeFinder Replikations-Funktionen mit BS2000/OSD“
http://docs.ts.fujitsu.com/dl.aspx?id=e7c9c355-7c0b-46c0-ab60-c546c0d1ab98
Online Provisioning für Pubsets: SPACEPRO
SPACEPRO (SPACE PROvisioning) ist eine PROP-XT-Anwendung in BS2000/OSD-BC V7.0, das Pubsets bzgl. Saturation
überwacht und bei Bedarf kontrolliert um Volumes aus einem Free-Pool erweitert.
Für einen ordnungsgemäßen Betrieb des BS2000 ist ein hinreichend großer nicht belegter Public-Space unabdingbar, der
heute vorausschauend von der Systemverwaltung zur Verfügung gestellt werden muss.
Mit SPACEPRO kann in BS2000/OSD-BC V7.0 eine automatisierte Anpassung der Anzahl der Platten eines BS2000-Pubsets
erfolgen. Durch die Automatisierung können mögliche Bedienungsfehler vermieden und ein (vorübergehend) unbedienter
Betrieb unterstützt werden.
Wird ein definierter Schwellwert erreicht oder überschritten (drohender Pubspace-Engpass), so werden automatisch Platten
hinzugenommen. Die freien Platten werden dabei in einem Pubset aus freien, aber bereits BS2000-formatierten Platten
vorgehalten, dem „Free-Pool“. Zur besseren Nutzung der Ressourcen steht der Free-Pool mehreren BS2000- und / oder
VM2000-Systemen zur Verfügung.
SX/S-Server (native)
SX/S-Server (VM2000)
VMx
VMy
BS2000-Pubsets
SPACEPRO
SYMMX / DMX / FibreCat
Die Pool-Pubsets des Free-Pools werden vom BS2000-Administrator eingerichtet und bestehen aus Platten, deren
physikalische Eigenschaften zu den Eigenschaften der Platten des Pubsets passen. Relevante physikalische Eigenschaften
sind z.B. die Plattenformatierung (CKD, FBA) oder die Platten-Box. Im Erweiterungsfall werden die physikalischen
Eigenschaften dynamisch ermittelt, die logischen Eigenschaften können entsprechend angepasst werden (z.B. durch VOLIN).
Zur Kontrolle der physikalischen Eigenschaften von Platten in einer Symmetrix-Box wird das Produkt SHC-OSD genutzt. Bei
einer Erweiterung von Pubsets mit SRDF- oder BCV-Spiegelung kann in BS2000/OSD-BC V7.0 eine Homogenitätsprüfung
vorgenommen werden (siehe unten Maßnahmen zur konsistenten Spiegelung von SF- und SM-Pubsets).
An SX –Servern unterstützt SPACEPRO die Storage-Systeme EMC Symmetrix und FibreCAT. Die FibreCAT-
Spiegelungsfunktionen Snapview und Mirrorview können jedoch nicht vom BS2000 kontrolliert werden.
Technische Realisierung:
Die Space-Saturation-Konsolmeldungen des BS2000 werden durch eine PROP-XT-Anwendung erfasst, die bei Überschreitung
eines festzulegenden Schwellwertes die automatische Pubset-Erweiterung über SDF-P-Prozeduren durchführt.
Alternativ kann auch der INSPECTOR von openSM2 die Sättigung eines Pubsets überwachen und SDF-P-Prozeduren starten.
Für die Regel-gesteuerte Ausführung von Prozeduren werden in openSM2 V7.0 folgende Verbesserungen realisiert:
• Übergabe editierbarer Parameter an die gerufene Prozedur (wie z.B. Name(n) des(der) Pool-Pubsets (CAT-ID) oder des
Volumes (VSN) oder des Gerätes (MN)),
• Aufruf einer Reihe von Prozeduren an unterschiedlichen Systemen (wie z.B. Monitor und Gast) synchronisiert und gesteuert
über deren Ergebnisse.
Für das online Provisioning unter VM2000 wird die implizite Gerätezuordnung durch das Gastsystem-Operating („ASSIGN-BY-
GUEST“) in der VM2000 V9.0 erweitert: Die Geräte eines Platten-Pools können dann auch von einem Gastsystem aus für sich
selbst automatisch, kontrolliert und passend zu einem zu erweiternden Pubset zugewiesen werden, und diese Zuweisung bleibt
auch nach einem VM2000-Restart erhalten.
Die BS2000-übergreifende Synchronisierung erfolgt durch den IMPORT/EXPORT des jeweiligen Pool-Pubsets:
Nach Zuschalten (per /ATTACH *PUBSET(cat-id)) und exklusivem Importieren des Pool-Pubsets ermittelt SPACEPRO die zur
Verfügung stehenden Volumes und wählt eines aus, das aus dem Pool-Pubset entfernt wird (/MODIFY-PUBSET-
PROCESSING). Danach wird das Pool-Pubset wieder exportiert und Detached (mit /DETACH *PUBSET(cat-id)). Dabei wird die

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 7 / 20
Reduzierte Liste der Volumes im SVL der PUBRES vermerkt. Das entfernte Volume bleibt ATTACHED, es wird umformatiert
und umbenannt (VOLIN) und in das zu erweiternde Pubset integriert per /MODIFY-PUBSET-PROCESSING.
Ein 2. System, das sich danach aus dem gleichen Pubset bedienen will, findet nach /ATTACH und /IMPORT das reduzierte
Pubset vor und wählt eines der verbliebenen Volumes aus. Das exklusive Importieren verhindert, dass sich zwei Systeme
gleichzeitig aus einem Pool-Pubset bedienen.
Für die Reduktion von Pubsets (Rückgabe freier Platten) wird eine manuell aufrufbare Funktion zur Verfügung gestellt. Zum
Leeren eines Volumes wird dabei SPACEOPT mit der Funktion CLEAR-VOLUME genutzt. Da dieser Vorgang erhebliche I/O-
Ressourcen erfordert, sollte er gezielt in Niedriglast-Zeiten durchgeführt werden.
SPACEPRO protokolliert alle Pubset-Erweiterungen in einer History-Datei.
Für den Test einer SPACEPRO-Konfiguration können Schwellwert-Überschreitungen simuliert werden.
Für den Einsatz von SPACEPRO wird neben dem Produkt PROP-XT auch das Produkt JV vorausgesetzt.
Konsistente Spiegelung von SF- und SM-Pubsets
Mit den für Symmetrix-Speichersubsysteme verfügbaren Spiegelmechanismen – BCVs, SRDF, Snaps und Clones – werden
verschiedene Einsatzszenarien wie Pubset-Sicherung und Erzeugung freier Pubset-Kopien abgedeckt. Dabei muss die
jeweilige Spiegelung für alle Volumes eines Pubsets bereitgestellt werden, d.h. für alle Volumes des Pubsets müssen die
gleichen Typen von Spiegel geführt werden, und alle Spiegel müssen sich im gleichen Betriebszustand befinden. Dies muss der
Betreiber bei BCV- und SRDF-Spiegelung bisher durch administrative Maßnahmen sicherstellen.
Bei Snapsets erfolgt die Zuordnung der Snap-Units zu den Volumes des Ausgangspubset automatisch durch SHC-OSD bzw.
NDM zu dem Zeitpunkt, zu dem die Spiegel als Sicherungsarchiv (Snapsets) benötigt werden. Die Frage der Homogenität stellt
sich für diesen Spiegeltyp also nicht.
In der BS2000/OSD-BC V7.0 kann durch Überprüfung der Zielkonfiguration bei Inbetriebnahme oder Rekonfiguration eines SFoder
SM-Pubsets sichergestellt werden, dass die jeweilige BCV und SRDF-Spiegelung konsistent für das gesamte Pubset
erfolgt. Diese Prüfung erfolgt (jeweils optional)
• bei der Inbetriebnahme eines Pubsets im Rahmen der Importverarbeitung,
• bei der Erweiterung eines Pubsets um einzelne Volumes oder um ein oder mehrere Volumesets mit dem Kommando
/MODIFY-PUBSET-PROCESSING und
• mit dem Kommando /CHECK-PUBSET-MIRRORS zu einem beliebigem Zeitpunkt (damit ist eine kontinuierliche
Überwachung des Betriebszustands der Pubsetspiegel möglich)
Durch Meldungen der DMS-Kommandos können die betroffenen Volumes identifiziert werden, so dass Fehlerzustände
behoben und ggf. fehlende Spiegel eingerichtet werden können.
Erweiterungen der System Managed Storage-Funktionen
System Managed Storage (SMS) im BS2000/OSD ermöglicht es dem Storage-Administrator, mithilfe eines Public Volume Set
(Pubset) ein hierarchisches Speichersystem bestehend aus der online Verarbeitungsebene und Migrationsebenen auf Platte
und Band zu definieren.
Verlagerung von Dateien auf der online Verarbeitungsebene
In den FibreCAT-Speichersystemen an SX-Servern werden neben den schnellen FC-Platten auch ATA-Platten (große, billige,
langsamere Container) unterstützt. Der Nutzen besteht in der Reduktion des teuren online Speicher, ohne SLA für Datenzugriff
einzubüßen. Auch in der DMX-3 bietet EMC Tiered Storage innerhalb einer Box in Form von Platten mit unterschiedlicher
Umdrehungsgeschwindigkeit, insbesondere auch „Low-cost-FC-Platten“ (LC-FC) an.
Das BS2000 unterstützt ATA- sowie LC-FC-Platten als normale Platten. Die Integration von ATA-Platten in SMS / HSMS ist
heute z.B. über spezielle Storageklassen auf der online Verarbeitungsebene oder in Form einer Nutzung auf der
Migrationsebene durch HSMS bereits möglich.
Mit BS2000/OSD-BC V7.0 wird eine MOVE-FILE-Funktion angeboten, die die Verlagerung von Dateien in „low-performance“
Volume-Sets auf der online Verarbeitungsebene (SM-Pubset) unterstützt.
Erweiterungen im Dienstprogramm PVSREN
Mit PVSREN können aus Pubset-Spiegeln „freie“ Pubsets erzeugt werden. Dabei können sowohl SF- als auch SM-Pubsets
repliziert werden.
Neben den Anpassungen im TSOSCAT bzw. den dateibezogenen Katalogen eines SM-Pubset führt PVSREN heute optional
weitere Abpassungen durch:
• Umbenennung der Standardkatalogkennung im Benutzerkatalog des HOME-PVS. Dies kommt in Frage, wenn das neu
erzeugte Pubset das Ausgangspubset ersetzen soll oder wenn das replizierte Pubset auf einem anderen System eingesetzt
werden soll.
• Umbenennung der Standardkatalogkennung im Benutzerkatalog des replizierten Pubset.
• Anpassung des IMON-Software-Configuration-Inventory. Dies kommt wie oben in Frage, wenn das replizierte Pubset das
Ausgangspubset ersetzen soll oder wenn das replizierte Pubset auf einem anderen System eingesetzt werden soll.
In der BS2000/OSD-BC V7.0 wird PVSREN wie folgt erweitert:
• PVSREN automatisiert die Anpassung der SMS-Storageklassen. Wahlweise können die Storageklassen für das neu
erzeugte Pubset zurückgesetzt oder übernommen werden. Bei Übernahme werden die Volumelisten in SYSCAT.VSETLST
an die neuen Katalogkennungen des SM-Pubsets angepasst.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 8 / 20
Verbesserte SAN-Unterstützung und I/O-Ressourcensteuerung
SAN Check-Funktion
Durch die Einführung von Fibre Channel/SAN im BS2000-Umfeld ist die Komplexität der Verkabelung und Generierung der
Komponenten gestiegen. Bei der Anschlusstechnik SAN ist über die bisherigen Kontrollfunktionen nur eine eingeschränkte
Sicht auf die tatsächliche Peripherie möglich. Fehlerursachen im laufenden Betrieb oder bei Zuschaltung von Geräten sind
daher nur schwer auffindbar.
Host1
Host2
Host3
CHPI D
A8
AC
CHPI D
88
8C
CHPI D
68
6c
Fabric
FC-Switch1
P0 P4
P1 P5
P2 P6
P3 P7
P8
P8
P0 P4
P1 P5
P2 FC-Switch2 P6
P3 P7
Disk-Subsystem
1
D101/

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 9 / 20
Ist im VM2000-Betrieb IORM auf dem Monitorsystem und allen Gastsystemen im Einsatz, so tauschen die IORM-Subsysteme
über eine VM-interne Schnittstelle I/O-Daten und Kontrollinformationen aus. Voraussetzung hierfür ist mindestens VM2000
V8.0.
Das Subsystem IORM unterstützt sowohl S- als auch SX-Server und sowohl Typ S- als auch Typ FC-Kanäle. IORM wurde
Ende 2006 mit Korrekturpaket auch für BS2000/OSD-BC V5.0C und V6.0B freigegeben. Unter den bisherigen Versionen V5.0C
und V6.0B stehen jeweils geeignete Teile der neuen Funktionen zur Verfügung.
I/O-Prioritäten-Steuerung für Tasks (IORM-Funktion I/O Priority Handling for Tasks)
Eine nieder priore, jedoch auf einem Gerät I/O intensive Anwendung kann heute andere, höher priore Anwendungen auf
demselben Gerät beeinträchtigen. Deshalb werden in BS2000/OSD V7.0 die drei I/O-Prioritäten low, medium und high
eingeführt. Diese können per /MODIFY-TASK-CATEGORIES den Task-Kategorien zugeordnet werden (neuer Operand IO-
PRIORITY). Für alle Tasks in einer solchen Kategorie wird die Task-I/O-Priorität durch die vorgegebene I/O-Priorität der
Kategorie bestimmt. Unter PCS ist damit über den Mechanismus „Folgekategorien“ (automatischer Kategoriewechsel) eine
weitere Dynamik in den I/O-Prioritäten einstellbar.
Falls Tasks mit der I/O-Priorität low oder medium höher priore Tasks mit der I/O-Priorität medium oder high behindern, wird für
jede I/O-Priorität nur noch ein begrenzter Auslastungsgrad zugelassen. In Abhängigkeit von der Auslastung der Geräte,
Steuerungen und Kanäle werden I/O-niederpriore Jobs durch Zeitstrafen ausgebremst.
Die Informationsausgabe beim Kommando /SHOW-SYSTEM-STATUS INFORMATION=*CATEGORY wird um die Angabe der
I/O-Priorität erweitert.
Dynamische I/O-Lastverteilung für Platten am FC-Kanal (IORM-Funktion Dynamic Parallel Access Volume)
Alternativ zum einfachen Plattenzugriff (Standard) wird seit der BS2000/OSD-BC V5.0 ein paralleler Plattenzugriff an BS2000
S-Servern unterstützt ('PAV, Parallel Access Volume'). Mit Parallel Access Volume (PAV) werden mehrere Geräteadressen
(Alias-Geräte) einem logischen Volume (Basis-Gerät) zugeordnet. Damit können mehrere I/O-Aufträge parallel auf ein Volume
abgesetzt werden. Im Plattenspeichersystem (EMC) werden Cache-Hits gleichzeitig bedient, während parallel dazu ein Cache-
Miss mit physikalischem Zugriff durchgeführt wird.
Mit PAV (Parallel Access Volume) lassen sich die Antwortzeiten bei stark ausgelasteten Platten reduzieren sowie die
maximalen I/O-Raten auf ein Volume erhöhen.
PAV am FC-Kanal ist eine reine SW-Lösung, die ohne Eingriffe an der Symmetrix-Steuerung in Betrieb genommen werden
kann. Für die Realisierung der PAV-Funktionalität nutzt das BS2000 die Tatsache aus, dass am FC-Kanal ein Gerät einen I/O-
Auftrag bereits annehmen kann, während noch eine I/O aktiv ist.
Alias-Geräte müssen im BS2000 generiert werden, ihre Zuordnung zu einem Basis-Gerät erfolgt bei statischem PAV in der
Generierung. Statisches PAV verlangt eine vorausschauende Planung auf die zukünftige Geräteauslastung, den stark
ausgelasteten Geräten muss im Voraus die richtige Anzahl von Alias-Geräten zugewiesen werden.
Dynamisches PAV in der BS2000/OSD-BC V7.0 weist autonom denjenigen Volumes Alias-Geräte zu, die am meisten davon
profitieren. Alias-Geräte, die als „DPAV“-Devices deklariert sind, weist IORM dynamisch den stark ausgelasteten Geräten zu
(Einsparung von zu generierenden Geräten). I/O-Engpässe durch Zugriffe mehrerer Jobs auf dieselbe Platte werden so durch
automatisches Hinzuschalten von Alias-Pfaden entschärft. Wie beim statischen PAV müssen die Geräte bei der Generierung
berücksichtigt werden.
Dynamisches PAV wird für S-Server und Platten an Typ FC-Kanälen angeboten.
An SX-Servern ist bereits seit BS2000/OSD-BC V6.0B als analoge Funktion zu dynamischem PAV eine Parallelisierung der
I/Os auf emulierte Platten via RSC realisiert.
Optimierte Lastverteilung im CentricStor-Betrieb
(IORM-Funktion Dynamic Device Allocation)
Die Nutzung der virtuellen Bandgeräte im CentricStor ist in BS2000/OSD-BC V7.0
einstellbar: Alternativ zur Nutzung der Geräte gemäß Generierung (wie bisher) kann
das System eine gleichmäßige Auslastung aller verfügbaren ICPs (Integrated
Channel Processor) sicherstellen.
Die Geräteverwaltung merkt sich für jeden ICP die Anzahl der belegten Geräte und
berücksichtigt diesen Zähler bei der Geräteauswahl. Die Geräteverwaltung kennt
jedoch nur die Gerätebelegungen innerhalb eines BS2000 Systems. Falls mehrere
Gastsysteme an einer Anlage gleichzeitig Geräte benötigen, kann trotz Optimierung
in der Geräteverwaltung immer noch eine ungleichmäßige Lastverteilung entstehen.
Die IORM-Funktion Dynamic Device Allocation stellt eine Erweiterung der
optimierten (lokalen) Geräteauswahl auf alle Systeme eines Servers im VM2000-
Betrieb dar. Dazu muss IORM im Monitor- und in allen Gastsystemen im Einsatz
sein. Durch eine VM2000-weite interne Kommunikation kennt IORM die
Gesamtbelegung der ICPs durch alle Systeme des Servers. Bei einer
Gerätebelegung stellt IORM der Geräteverwaltung die globalen Belegungszähler zur
Verfügung.
VM1
VMn
BS2000-Server
ICP ICP ICP
CS
log. LW
Gerätevergabe alt:
Gerätevergabe neu:
Begrenzung der IO-Aufnahme einzelner VM2000-Gastsysteme
(IORM-Funktion I/O Limit for Virtual Machines)
Weniger wichtige, jedoch I/O intensive Gastsysteme können andere, wesentlich wichtigere Gastsysteme massiv
beeinträchtigen. Konflikte können entstehen, wenn diese Gastsysteme I/Os ausführen auf das gleiche (logische) Gerät oder auf
verschiedene (logische) Geräte, die jedoch auf demselben physikalischen Gerät liegen, über dieselben Pfade angeschlossen
sind, über dieselben Ports erreichbar sind oder an denselben Kanälen angeschlossen sind.
IORM kann solche Konfliktsituationen erkennen und proaktiv in den I/O-Betrieb eingreifen.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 10 / 20
Schalten der Komprimierung bei LTO-Geräten (IORM-Funktion TCOM Tape Compression)
Für eine optimale Sicherung von Daten auf LTO-Bänder muss eine Mindestdatenrate erreicht werden, damit die Bänder
kontinuierlich "streamen". Für LTO-3-Bänder auf LTO-3-Geräten liegt diese bei ca. 40 MB/sec unkomprimiert bzw. bei 80
MB/sec komprimiert. Im Bereich zwischen ca. 40 MB/sec bis ca. 80 MB/sec wird die Mindestdatenrate erreicht, wenn die
Komprimierung im Gerät ausgeschaltet wird. Bei ausgeschalteter Komprimierung ist die Bandkapazität entsprechend geringer
(bei LTO-3 etwa 400 GB statt 800 GB).
Defaultmäßig ist im BS2000/OSD-BC V7.0 die Komprimierung immer eingeschaltet (auch ohne Einsatz von IORM). Mit TCOM
kann die Komprimierung vollständig ausgeschaltet werden. Als weitere Alternative bietet TCOM die Möglichkeit der
dynamischen Schaltung der Komprimierung in Abhängigkeit von der Datenrate an. Die Komprimierung wird ausgeschaltet, falls
die Datenrate ohne Komprimierung für ein Streamen des Bandes ausreicht, mit Komprimierung jedoch nicht.
Verfügbarkeit
Ziel ist die Vermeidung/ Verkürzung geplanter Abschaltungen (Verbesserung der Self-configuring- Eigenschaften des
BS2000/OSD), und die Vermeidung / Verkürzung ungeplanter Systemunterbrechungen (Verbesserung der Self-healing-
Eigenschaften des BS2000/OSD). In BS2000/OSD-BC V7.0 sind weitere Entwicklungen zur Erhöhung der Verfügbarkeit
enthalten:
MONJV für laufenden Job
Um Anwendungen mit Hilfe von MONJVs zu überwachen, muss der Task bisher beim Anwendungsstart eine MONJV
zugeordnet werden. In der BS2000/OSD-BC V7.0 kann der Systemverwalter (TSOS) mit dem Kommando MODIFY-JOB-
OPTIONS einem laufenden Job nachträglich eine MONJV zur Überwachung zuordnen. Damit kann die Überwachung von
Anwendungen nach einem Konfigurationsupdate oder nach Bedienungsfehlern eingeschaltet werden, ohne die Anwendung
beenden zu müssen.
Parallelisierung der Tape-Monitor-Task
Der Tape-Monitor ist eine performancekritische Instanz zum Scheduling von Montagevorgängen und zur Überwachung der
Online-Sicherheit von Magnetbandkassetten (MBKs). Bei einer Blockade dieser Task erfolgen keine Mount-/Demount-Vorgänge
mehr. In der Vergangenheit wurden sporadisch immer wieder Blockaden festgestellt, die durch verzögerte I/O-Aufträge
verursacht wurden. In der BS2000/OSD-BC V7.0 wurden die I/O-Aktivitäten in andere Ablaufträger verlagert und dadurch die
Blockaden umgangen: Für die wichtigsten und häufigsten I/O-Vorgänge (CHECK-TAPE-MOUNT, Übergang
not_ready_to_ready) wird anstelle der I/O eine entsprechende Recover-Funktion aufgerufen, die unter einer anderen Task
abläuft. Außerdem werden die I/Os zur Versorgung der Informationsanzeige am Gerät (LOAD DISPLAY) in eine Subtask
ausgelagert.
Vergrößerung des rekonfigurierbaren Arbeitsspeichers unter VM2000 bei SX160
Unter VM2000 besteht die Möglichkeit, dem BS2000-System Arbeitsspeicher im laufenden System hinzu- oder wegzunehmen,
bis zu einem Arbeitsspeicher-Minimum, das vom Anfang bis zum Ende des Systemlaufes dem BS2000 erhalten bleiben muss.
Der rekonfigurierbare Teil des verwendeten Arbeitsspeichers wurde in BS2000/OSD-BC V7.0 bei SX160-Servern deutlich
vergrößert, indem Großverbraucher des realen Arbeitsspeichers wie Big Pages für JIT-Compilate und DAT-Tabellen (Page-
Tables für Big Pages usw.) in den Arbeitsspeicher über dem ASP-Minimum verlagert werden.
Der Bedarf an Big Pages für JIT-Compilate bei Hochlast bildete bisher eine Untergrenze für das ASP-Minimum, die bei ca. 40%
der (Hochlast-)Arbeitsspeicher-Größe lag und mit BS2000/OSD-BC V7.0 aufgehoben wird:
• Neue Big Pages sind bei Arbeitsspeicher-Vergrößerung erzeugbar (bisher nur bei ASP-Minimum-Erhöhung).
• Von lokalen JIT-Compilaten belegte Big Pages können z.B. bei Hauptspeicher-Sättigung und ASP-Reduktion aufgelöst
werden.
Somit adaptiert sich das System bei der Bereitstellung von Big Pages automatisch an die Arbeitsspeicher-Größe.
Dies gilt für SX-Server ab SX160, da die erforderlichen Erweiterungen der CISCFW in X2000 V4.0 eingebracht werden.
Neues Subsystem ASE (Auxiliary SERSLOG Extension) zur Systemdiagnose
Das neue Subsystem ASE der BS2000/OSD-BC V7.0 ermöglicht automatisierte Reaktionen auf kritische Systemzustände, die
sich in SERSLOG-Einträgen widerspiegeln:
• Protokollierung in Puffer, Meldung an der Konsole, Teleservice-Alarm
• Für die zu überwachenden Ereignisse können Schwellwerte festgelegt werden
• Die Protokollierung kann auf ausgewählte SERSLOG-Ereignisse eingeschränkt werden.
Der Nutzen ist eine einfache, unterbrechungsfreie Erzeugung von Diagnoseunterlagen.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 11 / 20
Offenheit
Die seit Jahren verfolgte Strategie der Offenheit wird mit BS2000/OSD-BC V7.0 konsequent fortgesetzt.
Erweiterte Unterstützung von Zeichensätzen und Zeichencodes
Zielsetzung der Unicode-Unterstützung im BS2000/OSD
Unicode ist ein internationaler Standard, in dem langfristig für jedes Zeichen bzw. Textelement aller bekannten Schriften ein
digitaler Code festgelegt wird. Ziel von Unicode ist, für alle weltweit vorkommenden Zeichen eine weltweit eindeutige Codierung
festzulegen.
Einzelheiten zu Unicode siehe Unicode Homepage http://www.unicode.org/
Herkömmliche Computer-Zeichensysteme umfassen einen Zeichenvorrat von entweder 128 (7 Bit) Zeichen oder 256 (8 Bit)
Zeichen. Auch das BS2000/OSD unterstützt bisher nur 7 Bit- und 8 Bit-Zeichensätze. Diese Zeichenkodierungen erlauben die
gleichzeitige Darstellung von nur wenigen Sprachen im selben Text. Dies ist aufgrund neuer EU-Richtlinien und deren
Umsetzung in nationales Recht mittelfristig nicht mehr ausreichend (internationale Postrichtlinie zur Schreibweise von
Adressen, BundOnline 2005, Richtlinie des Bundesministerium des Inneren für den Datenaustausch zwischen Behörden).
Mit der Unicode-Unterstützung im BS2000/OSD werden die in BS2000/OSD -Systemen verfügbaren EBCDIC-Zeichensätze um
zusätzliche Zeichen erweitert, die im europäischen Sprachraum künftig benötigt werden. Dies erfolgt durch den Einsatz
ausgewählter Unicode-Codepoints additiv zu den bisherigen EBCDIC-Varianten.
Ausgangssituation im BS2000/OSD
Das BS2000/OSD verwendet bei der Bearbeitung von Daten standardmäßig einen 7-Bit EBCDIC-Zeichensatz. Die für das
BS2000 definierte internationale 7-Bit EBCDIC-Tabelle, die als System-Standard-Zeichensatz verwendet wird, heißt EDF03IRV.
Mit ihr stehen 95 verschiedene Zeichen zur Verfügung (160 Zeichen abzüglich 65 Steuerzeichen). Die Bezeichnung „7-Bit“ rührt
daher, dass der Vorrat der abdruckbaren Zeichen dem von ASCII 7-Bit entspricht.
Mittels XHCS unterstützt das BS2000/OSD eine Reihe von 8-bit-ISO-Codes und die zugehörigen EBCDIC-Codes..
Extended Host Code Support (XHCS)
Zur Unterstützung verschiedener Zeichensätze und Zeichencodes dient das Konzept der so genannten "Coded Character Sets"
(CCS). Ein CCS definiert einen Zeichensatz und die Codierung dieser Zeichen in der Datei. Das Subsystem XHCS ist die
zentrale Informationsquelle über die codierten Zeichensätze (CCS), die im BS2000/OSD zur Verfügung stehen. Damit müssen
die verschiedenen Programme Informationen über Zeichensätze nicht fest speichern, sie erhalten diese Informationen von
XHCS.
XHCS identifiziert die Datencodes, egal woher sie kommen, ob von einer Terminaleingabe, von einer Programmausgabe oder
von einem anderen System. Zur Identifikation der übertragenen Datencodes dient der Zeichensatzname (CCS-Name). Die
codierten Zeichensätze stellt XHCS in Form von Tabellen zur Verfügung. XHCS unterstützt bis zur Version 1.5 die 8-bit-ISO-
Codes ISO8859-1/2/3/4/5/7/9/15 und die verschiedenen zugehörigen EBCDIC-Codes.
Die Nutzung eines bestimmten 8-bit-EBCDI-Codes kann für das gesamte BS2000/OSD-System über die Class-2-Option
HOSTCODE = CCS-Name eingestellt werden oder für einzelne Kennungen und Pubsets durch Eintragen eines CCS-Namens
in die Benutzerkennung. Über die VTSU-B-Parameterdatei kann global bzw. über /MODIFY-TERMINAL-OPTIONS kann
kennungs-spezifisch gesteuert werden, dass der einer Benutzerkennung zugewiesene 8-bit Code für die Terminal-Ein-
/Ausgaben der TIAM-, UTM- und DCAM-Anwendungen genutzt wird, die unter dieser Kennung ablaufen. Um die binäre
Verschlüsselung innerhalb einer Datei zu beschreiben, kann das Dateiattribut CCS-Name vergeben werden.
Alle Programme im BS2000 gehen davon aus, dass sie Daten in einem EBCDIC-Zeichensatz bearbeiten, bei dem der so
genannte EBCDIC-Kern invariant ist. Deshalb sollten die ISO 8859-x-Varianten nicht als System- oder User-Zeichensatz
eingesetzt werden.
CCS-Defaultierung
Während der Umstellung von einem 7-Bit auf einen 8-Bit-Zeichensatz und auch später ist es notwendig, umgestellte Daten von
nicht umgestellten Daten zu unterscheiden.
Deshalb wurde in der BS2000/OSD-BC V7.0 ein neues Systemverhalten eingeführt, mit dem sich der Defaultwert des CCS-
Namens einer Datei wie folgt beeinflussen lässt:
Wird eine Datei neu angelegt, so wird der CCS-Name des Benutzereintrages des aufnehmenden PVS – anders als bisher - als
CCS-Name der Datei übernommen, falls dieser nicht EDF03IRV ist. Ist er EDF03IRV, so erhält die Datei – wie bisher - den
CCS-Namen *NONE. Analog ändert sich das Verhalten von LMS bezüglich neuer Elemente; diese erhalten den CCS-Namen
der Bibliothek, falls kein Wert für den CCS-Namen angegeben ist.
D.h. für Kunden, die mit dem System-Standard-Zeichensatz arbeiten, erfolgt keine Änderung.
Für Kunden, die mit einem 8-Bit-Zeichensatz arbeiten, führt diese Regelung dazu, dass die Nutzung eines Codes auf
Dateiebene und Bibliotheks-Elementebene klar spezifiziert ist.
(Bisher wurde immer der CCS-Name *NONE vom BS2000 Datenmanagement-System vergeben. D.h. bei einer Umstellung
mussten alle Programme so geändert werden, dass sie das Dateiattribut explizit versorgen.)
Grundsätzlich gilt jedoch, eine explizite Angabe eines CCS-Namen hat immer Vorrang.
Wird eine Datei kopiert, gesichert oder rückgesichert, so wird das Dateiattribut CCS-Name immer mit transportiert.
Das geänderte CCS-Default-Verhalten wurde auch per Korrektur im KP 2/2006 für BS2000/OSD-BC V6.0 freigegeben.
Zur Umstellung von 7-Bit- auf 8-Bit-Zeichensatz siehe auch White Paper
http://docs.ts.fujitsu.com/dl.aspx?id=eebb2f5a-97ea-4411-ae4d-ab5cc9b584f2

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 12 / 20
Unicode-Unterstützung im BS2000/OSD
Unicode-Einsatz-Szenario
Mit der Unicode-Unterstützung im BS2000/OSD werden die in BS2000/OSD -Systemen verfügbaren Codesets um zusätzliche
Zeichen erweitert. Dem Anwender wird die Programmier- und Ablauf-Umgebung zur Verfügung gestellt, die er benötigt, damit er
seine bestehenden Anwendungen um Unicodedatenfelder erweitern kann. Hierbei wird davon ausgegangen, dass die Anzahl
der Felder, die auf Unicode umgestellt oder die zusätzlich eingefügt werden müssen, gering ist. Es wird sich im Wesentlichen
um Namens- und Adressfelder handeln.
Der Kunde muss nur solche Anwendungen / Anwendungsteile modifizieren, die auch die erweiterte Funktionalität nutzen.
Die Unicode-Unterstützung im BS2000/OSD erfolgt auf Basis der vorhandenen Produkte. Unicode-basierte Zeichen werden nur
für die zu verarbeitenden / zu verwaltenden Texte zugelassen, d.h. für die Feld- bzw. Containerinhalte, nicht jedoch für Feldbzw.
Containernamen. Die produktspezifischen Regeln für Kommandos und Objektnamen bleiben bestehen.
Einführung der Unicode-Nutzung im Kundensystem
Zusätzlich zur Hochrüstung der BS2000/OSD-Systembasis und der systemnahen Anwendungen, sowie der
Programmierumgebung auf die erforderlichen Versionen sind vom Kunden weitere Vorbereitungen zu treffen. Dabei sind
folgende Punkte besonders zu beachten:
• Die Daten und Dateien sind in einen definierten Zustand zu bringen.
• Die im BS2000-System verwendeten CCS-Namen (Coded Character Sets) sind zentraler Bestandteil bei der Behandlung
von Daten. Es ist sicher zu stellen, dass der Inhalt und die Bezeichnung der Daten mittels CCS-Namen konsistent ist.
• Die betroffenen Anwendungen sind für die zusätzlich zu verarbeitenden Unicode-Datenfelder zu erweitern.
Speicherung von Unicode
In Unicode finden Zeichen der wichtigsten Industriestandard-Zeichensätze wie die ISO-Normen eine 1:1-Entsprechung (das
bedeutet, dass bei einer Konversion vom Industriestandard zu Unicode und zurück das gleiche Ergebnis herauskommt).
Die Speicherung und Übertragung von Unicode erfolgt in unterschiedlichen Formaten. UTF (Unicode Transformation Format)
beschreibt Methoden, ein Unicode-Zeichen auf eine Folge von Bytes abzubilden. Jeder Character des Unicode-String wird
dabei durch eine oder mehrere "code units" dargestellt.
• UTF-8 ist die verbreitetste Kodierung für Unicode-Zeichen und für alle auf dem Lateinischen Alphabet basierenden Schriften
die platzsparendste Methode zur Abbildung von Unicode-Zeichen. Code unit sind 8 bit; jeder Unicode-Character braucht 1, 2,
3, oder 4 Bytes.
• Neben UTF-8 hat UTF-16 eine große Bedeutung, so z. B. als Zeichencodierung in Java. Code unit sind 16 bit; jeder Unicode
Character braucht entweder 2 oder 4 Byte. UTF-16 ist weitestgehend identisch mit der 2-Byte-Unicode-Darstellung UCS-2.
• UTF-EBCDIC ist eine Unicode-Erweiterung, die auf dem proprietären EBCDIC-Format von IBM-Großrechnern aufbaut. Code
unit sind 8 bit; jeder Unicode Character braucht 1, 2, 3, 4, oder 5 Byte.
• Im BS2000/OSD wird UTF-E neu eingeführt; UTF-E im BS2000 ist an UTF-EBCDIC von der IBM angelehnt.
XHCS V2.0
Basis für die Unicode-Unterstützung im BS2000/OSD sind Erweiterungen im Subsystem XHCS (XHCS V2.0 als Bestandteil der
openNet Server V3.2)
XHCS V2.0 unterstützt die Codierungsvarianten UTF-8, UTF-16 (2-Byte, BS2000) und UTF-E (variable, BS2000).
XHCS V2.0 umfasst Umsetztabellen der unterstützten 8-bit-ISO-Codes (ISO8859-1/2/3/4/5/7/9/15) nach Unicode und deren
Umkehrabbildung.
Über die Zeichen, die in diesen ISO-Codes enthalten sind, hinaus unterstützt XHCS etwa 70 Zeichen des Unicode-
Zeichensatzes (die in den Meldezeichen der öffentlichen Verwaltungen verwendeten Sonderzeichen).
Unicode im BS2000/OSD-Applikationsumfeld
Die Unicode-Unterstützung der Programmier- und Ablauf-Umgebung erstreckt sich auf folgende Funktionsbereiche:
• Programmierung: COBOL2000, ESQL-COBOL, IFG/FHS (Unicode-Datenfelder), AID
• Datenspeicherung: SESAM/SQL, UDS/SQL, ORACLE (Unicode-Datenfelder)
• Verarbeitung von Daten: EDT, SORT, PERCON
• Input/Output: Terminal-Support (VTSU, MT9750, FHS) , Printer-Support (RSO, Spool), File Transfer (openFT)
Zur Unterstützung der Unicode-Funktionalität im BS2000/OSD wird eine entsprechende Softwarekonfiguration unter den
BS2000/OSD-BC-Versionen V6.0 und V7.0 bereitgestellt:
Überblick der Unicode-spezifischen Erweiterungen in den einzelnen Produkten
Programmierung:
• COBOL2000 V1.4 unterstützt den Datentyp NATIONAL in seinen verschiedenen Ausprägungen und die prozedurale
Verwendung dieser Daten in Compiler und Laufzeitsystem (CRTE V2.7 für BS2000/OSD-BC V7.0).
• ESQL-COBOL V3.0 erlaubt den Datentyp NATIONAL von COBOL in seinen Declare Sections und lässt seine Verwendung
als Hostvariable in SQL Anweisungen zu.
• IFG V8.3 und FHS V8.3 ermöglichen eine Kennzeichnung für Unicode für einzelne Felder eines Formats.
• AID V3.2 bietet eine LL-Unterstützung des Datentyps UTF-16 an, der auch als neuer Datentyp von COBOL unterstützt wird.
Zusätzlich bietet AID bei entsprechender Unterstützung durch COBOL den Datentyp UTF-16 auch im LSD an. Damit kann
dieser Datentyp auch symbolisch getestet werden.
Datenspeicherung:
• In den DB-Systemen SESAM/SQL V5.0 und Oracle 10g wird durch Einführung der Datentypen NCHAR und NVARCHAR die
Möglichkeit geschaffen, auch Unicode-Zeichen abzuspeichern und mit SQL-Mitteln zu bearbeiten.
• In UDS/SQL V2.5 werden auch National-Daten (UNICODE) unterstützt. In der DDL werden Datenfelder und Datengruppen
mit PIC N zugelassen.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 13 / 20
UTF-16
EBCDIC
openFT
UTF-8
Unicode im BS2000/OSD-Systemumfeld
BCAM
XHCS
UTF-16
EDT
UTF-E
UTM
UTF-E
VTSU
UTF-E
UTF-16
EBCDIC
UTF-E
UTF-8 UTF-E UTF-E
UTF-E
FHS
UTF-16
EBCDIC
Arbeitsspeicher
UTM-
Anwendung
UTF-16
EBCDIC
DB-System
SESAM / Oracle
UTF-8
UTF-E
UTF-16
EBCDIC
openFT
Fremdsystem
UTF-16
EBCDIC
z.B. UNIX-System
NEABX
810-Protokoll
UTF-8
Bildschirmpuffer
MT9750
UTF-16
EBCDIC
UTF-8
Windows
Verarbeitung von Daten:
• Für die Sortierung stellt XHCS dem SORT (V7.9) die erforderlichen Sortiertabellen zur Verfügung. Zur Normalisierung der
diakritischen Zeichen und zur Konvertierung von Dateien wurde PERCON V2.9 entsprechend erweitert.
• EDT V17.0 kann Dateien in den Unicode Codesets des BS2000 bearbeiten.
Input/Output:
• Mit der Einführung einer EBCDIC-Variante von UTF-8 (UTF-E) wird die Terminal-Ein- und Ausgabe über die
Terminalemulation MT9750 V7.0 und VTSU-B V13.2 für die zu unterstützenden erweiterten Zeichen ermöglicht.
(VTSU-B V13.2 ist in openNet Server V3.2 enthalten.)
• FHS V8.3 kann Formate als Unicode-codierte Nachricht ausgeben (UTF-E) und Eingabe-Strings mit Unicode-Feldern vor
dem Transfer in die entsprechenden Puffer der Applikation feldspezifisch in EBCDIC bzw. UTF16 umwandeln.
• RSO V3.5 unterstützt UTM-8-fähige Netzwerkdrucker (aktuell Printronix P7000 mit IBM ProPrinter- bzw. EPSON-FX-
Emulation). Dabei werden (neben EBCDIC/ASCII) Druckdateien mit Codierung in UTF-8, UTF-16 und UTF-E (abhängig vom
Datensatztyp) akzeptiert.
• Im lokalen Spool (V4.8) können Unicode-Daten im Format UTF-16 auf Océ-Hochleistungsdrucker im I(PDS)-Mode
ausgedruckt werden (mittels entsprechender Fonts und Océ-Treibersoftware SPS).
• openFT V10.0 für BS2000 unterstützt die Übertragung von DMS- und Posix-Dateien mit den Unicode-Varianten UTF-16 (Big
Endian) und UTF-8.
Alle Daten-Container bleiben in ihrer Größe erhalten. D.h. da ein UTF-16 Zeichen zwei Byte Speicherplatz belegt, können z.B.
in einem SAM-Satz maximal 16000 Zeichen und nicht 32000 Zeichen gespeichert werden. Analoges gilt für Datenbankfelder
vom Type NCHAR und NVCHAR.
Weitere Details zur Unicode-Unterstützung im BS2000 siehe White Paper „Unicode im BS2000/OSD“
http://docs.ts.fujitsu.com/dl.aspx?id=f5c84f1c-a69f-4b9b-88fd-1b7901d10cc8
POSIX A39
POSIX als die technische Basis der BS2000/OSD-Öffnungsstrategie wird entsprechend den Anforderungen der Nutzer
weiterentwickelt. In Verbindung mit BS2000/OSD-BC V7.0 ist die Freigabe der neuen Version POSIX A39 erfolgt.
Funktionserweiterungen sind:
Dynamisches Setzen von Systemparametern
Die POSIX-Systemparameter sind im Kernelheader sys/config.h definiert. Sie werden beim Hochfahren von POSIX in die
Strukturen des Kernels übernommen und stehen damit POSIX beim Ablauf zur Verfügung. Danach wird die POSIX-Parameter-
Datei (SYSSSI-Datei) ausgewertet, die neue aktuelle Werte der Systemparameter enthalten kann. In der POSIX A39 können
zusätzlich die aktuellen Werte von ausgewählten Systemparametern über ein privilegiertes Kommando usp verändert werden.
Dies sind:
• HDSTNI (maximal number of server tasks for I/Os)
• HDPTNI (maximal number of mounted (local) filesystems)
• NPROC (maximal number of user processes in POSIX)
• MAXUP (maximal number of user processes)
• HEAPSZ (maximal value for break() systemcall)
• NOTTY (maximal number of ttys)
• NOSTTY (maximal number of sttys)

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 14 / 20
• MAXTIMERC (maximal wait time for rc termination (in seconds))
• FORCEDTERM (invocation of forced termination)
Der veränderte Wert kann optional auch in die SYSSSI-Datei eingetragen und damit automatisch beim nächsten Hochfahren
benutzt werden.
Dynamische Änderung des posdbl-Caches
Mit dem POSIX-Kommando posdbl kann der Superuser einen globalen Programm-Cache in skalierbarer Größe zur
Speicherung ablauffähiger Core-Images von POSIX-Programmen einrichten und verwalten. Diese Core-Images werden
entweder implizit bei Aufruf eines POSIX-Tools aus der Shell-Library oder explizit mit dem posdbl-Kommando gespeichert.
Dadurch werden die Zeiten beim Laden dieser Programme verkürzt. Zum Laden eines gespeicherten Programms steht der
globale Programm-Cache allen Benutzern zur Verfügung.
Die Größe des posdbl-Caches kann in der POSIX A39 ohne den bisher erforderlichen POSIX-Shutdown geändert werden.
Erweiterungen des POSIX-Installationsprogramms (START-POSIX-INSTALL) im Batch-Modus.
• Installationsfehler werden in der Loggingdatei /var/sadm/pkg/insterr protokolliert.
• Über den neuen SDF-Operanden ERROR-HANDLING wird die Rücklieferung eines Kommando-Returncodes (MAINCODE,
SUBCODE1, SUBCODE2) und die Auslösung des Spin-Off-Mechanismus innerhalb von Prozeduren unterstützt.
Erhöhung der maximalen Anzahl lokaler Dateisysteme
• Die maximale Anzahl lokaler POSIX-Dateisysteme wird von bisher 200 auf 300 erhöht. Der zugehörige Defaultwert in der
SYSSSI-Datei bleibt 200.
Maßnahmen zur besseren Portierbarkeit der Java-VM
• Unterstützung von mmap nach /dev/zero. Dies dient i.w. zur Performancesteigerung und zur Reduzierung des
Portierungaufwandes bei JAVA-Versionen.
• Unterstützung shared libraries für JAVA: Nachladen und Initialisierung des Laufzeitsystems für JAVA (analog wie für C++
oder COBOL) und Beachtung von Besonderheiten beim Laden von JAVA shared objects.
• Verbesserungen/Korrekturen bei den POSIX-Kommandos lp und lpstat, die in der neuesten JAVA-Version zur Druckausgabe
benutzt werden.
Einsatz der Secure Shell
Es werden Einschränkungen beim Einsatz der Secure Shell aufgehoben.
Die Secure Shell steht mit dem Produkt interNet Services ab V3.0B zur Verfügung (openssh). Das ssh-Client-Programm ließ
sich bisher nur innerhalb einer Remote-Login-Sitzung (d.h. eingeloggt in POSIX per rlogin, ssh, oder slogin-Kommando)
verwenden. In $DIALOG oder TELNET-Sitzungen konnte es nur benutzt werden, wenn stdin, stdout und stderr auf eine Datei
oder POSIX-Pipe umgelenkt wurden. Diese Umlenkung ist mit POSIX A39 nicht mehr erforderlich.
Apache V2.2
Der weltweit meistgenutzte Web-Server Apache ist in der aktuellen Freigabeversion neben Windows, Linux, Solaris auch für
BS2000/OSD verfügbar und im Betriebssystem-Grundausbau BS2000/OSD-BC enthalten. BS2000/OSD-BC V7.0 wird die
neue Version APACHE (BS2000/OSD) V2.2 enthalten*. Sie basiert auf der offiziellen Freigabeversion 2.2 des Webservers der
Apache Group. Mit Apache V2.0 erfolgt der Umstieg auf den Apache http-Server 2.2 der Apache Software Foundation mit
Unterstützung von PHP V4 ; PERL V5.8 ; TOMCAT statt JSERV/JSP. Die APACHE (BS2000/OSD) V2.2 enthält die
Unterstützung des SSL-Protokolls (Secure Socket Layer) zur sicheren Übertragung von Dokumenten und Daten über das
Internet; das bisherige Zusatzprodukt interNet Security ("Apache+SSL") entfällt.
* Die Freigabe ist als Funktionsnachtrag im Mai 2008 geplant, zuvor wird APACHE V1.3 geliefert.
Java V5.0
Mit BS2000/OSD Environment for Java (Kurzform JENV) wird Java als Bestandteil von BS2000/OSD-BC bereitgestellt. Mit
dem BS2000/OSD Environment for Java (JENV) können alle Java-Programme, die auf beliebigen Plattformen erstellt wurden,
auf BS2000-Systemen zum Ablauf gebracht werden.
BS2000/OSD-BC V7.0 enthält die neue Version JENV (BS2000/OSD) V5.0. Diese Version erfüllt die relevanten Spezifikationen:
• The Java Language Specification, Third Edition“
• „The Java Virtual Machine Specification, Second Edition“
• die versionsspezifische API Spezifikation „Java 2 Platform Standard Edition API Specification 5.0“
Die Einhaltung dieser Spezifikationen wurde von Sun Microsystems, Inc. durch die Erteilung des „Java Compatible“-Logo für die
Version BS2000/OSD Environment for Java V5.0 (am 10.8.2005) bestätigt.
Das Java Development Kit V5.0 wird zusammen mit dem BS2000/OSD Grundausbau, in einer für die jeweilige Hardware
optimierten Variante, ausgeliefert. Mit dem JDK verfügt der Programmierer über ein Grundsystem zur Entwicklung von Java-
Anwendungen. Bestandteile des JDK sind der HotSpot Compiler, der Java-Interpreter, der Debugger, Java-Klassenbibliotheken
und diverse weitere Tools.
Zusätzlich enthält JENV (BS2000/OSD) V5.0 das Paket JRIO. Dieses Paket ist eine Sammlung von Java Klassen zum direkten
Umgang mit Dateien, die eine Satz- und/oder Blockstruktur haben und zur satz- bzw. seitenorientierten Ein-/Ausgabe auf solche
Dateien. In JENV V5.0 werden die Dateien des BS2000 Data Management Systems unterstützt.
WebTransactions for OSD V7.1
Das Produkt WebTransactions for OSD realisiert die Einbindung von beliebigen BS2000/OSD-Anwendungen in das Internet
oder ein Intranet/Extranet. WebTransactions for OSD arbeitet auf der Systemplattform BS2000/OSD mit dem Web-Server
APACHE zusammen. Mit BS2000/OSD-BC V7.0 wird die Variante WebTransactions V7.1 für OSD-Anwendungen ablauffähig
auf BS2000/OSD unter POSIX, mit einer unbegrenzten Anzahl von Userlizenzen ausgeliefert. Damit liegen bereits im
Betriebssystem-Grundausbau die Voraussetzungen vor, die Web-Technologie für E-Business-Aktivitäten zu nutzen.
Die Version WebTransactions for OSD V7.1 enthält gegenüber der Vorversion V7.0 folgende neuen Funktionen:
• Web-Integration Unicode-fähiger Anwendungen
• Unterstützung des Unicode-fähigen 9750-Terminalprotokolls

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 15 / 20
Erweiterungen in SW-Produkten
Im Folgenden sind die Funktionserweiterungen in neuen Versionen für einige wichtige SW-Produkte dargestellt, die im
Zeitrahmen von BS2000/OSD V7.0 freigegeben wurden, die aber auch für BS2000/OSD V6.0 (und z.T. für V5.0) verfügbar sind.
AVAS V8.0
Die Version AVAS V8.0 enthält folgende wesentlichen Funktionserweiterungen:
• Während der aktiven Phase eines AVAS-Auftrages in einem BS2000-System kann dessen SYSOUT-Datei angezeigt
werden.
• File-Transfer-Aufträge, die heute innerhalb von Jobs erledigt werden, können in AVAS V8.0 über AVAS-Strukturelemente
abgewickelt werden. Dadurch wird die Transparenz der Ablauflogik weiter erhöht.
• Die Integration von Subnetzen in Hypernetze wird verbessert: Die Startzeit von Subnetzen kann an den Ablauf des
Hypernetzes gekoppelt werden, so dass auch beide gemeinsam vorverlegt werden können. Das USER-PAR-FILE des
Hypernetzes kann auf die Subnetze vererbt werden.
Wesentliche Funktionserweiterungen für Server im Rahmen der neuen Version AVAS-SV V8.0 sind:
• In Serverjobs können zusätzliche Protokolldateien übertragen und Schwellwerte für den Umfang der Übertragung
vorgegeben werden.
• Seit AVAS-SV V7.0 kann der Administrator eines Servers mit einer Oberfläche für Server-Überwachung überprüfen, welche
Jobs (von einem fremden System aus) in seinem System gestartet wurden. In der AVAS-SV V8.0 wird die Oberfläche für
Serverüberwachung weitergehende Informationen (JCL, Joblog) bieten sowie die Möglichkeit, die Jobverteilung anzuhalten.
Ziel ist mehr Transparenz am dezentralen System.
• AVAS V8.0 wurde ab BS2000/OSD V5.0 freigegeben.
FDDRL V16.0
Die physikalische Plattensicherung unterstützt mit FDDRL V16.0 die technische Fortentwicklung der MBK-Technologie, sowohl
die große Kapazität als auch die Durchsatzsteigerung von LTO-Geräten.
Mit Several-Disk Tapeset wird das Sichern von mehreren Platten eines Pubsets auf ein Band/Tapeset angeboten. Dies
garantiert eine optimale Ausnutzung der Kapazität großer MB-Kassetten.
Das gleichzeitige Sichern von mehreren (zwei) Platten auf ein Band (Multiplexing) gleicht die heutigen
Performanceunterschiede zwischen langsamer Platte und schnellem Band aus.
Die Funktion Reload-Pubset sichert eine konsistente Restaurierung eines Pubsets. Die Anweisung RELOAD-PUBSET bietet
den gleichen benutzerfreundlichen Komfort wie das Gegenstück DUMP-PUBSET beim Sichern. Durch den Zugriff auf
gesicherte Metainformationen werden die Pubset-Konfiguration und Platteneigenschaften ermittelt und angezeigt. Damit wird
die Bereitstellung der Zielplatten wesentlich vereinfacht und der Restaurationslauf kann weitgehend automatisiert abgewickelt
werden. Die Ermittlung der Sicherungsdatenträger bei der Restaurierung erfolgt automatisch über den Zugriff auf den Volume-
Katalog von MAREN oder alternativ anhand der FDDRL-Metadaten.
FDDRL V16.0 wurde für BS2000/OSD V6.0 und V7.0 freigegeben.
HSMS/ARCHIVE V8.0B
HSMS V8.0B unterstützt in Verbindung mit BS2000/OSD-BC V7.0 die Symmetrix DMX TimeFinder-Funktionen Snap und
Clone:
• Die in Snapsets gesicherten Dateien/JV’s können mit HSMS in Backup-Archive übernommen werden.
• Clones können (wie heute BCVs) als Input für die Bandsicherung genutzt werden.
Details siehe im Kapitel ‚Verbesserte Storage-Integration / Storage-Virtualisierung / Storage on Demand’, Abschnitt
‚Unterstützung neuer Symmetrix DMX-Funktionen Snap und Clone’.
HSMS und ARCHIVE parallelisieren in der V8.0B Plattenzugriffe, indem sie auf S-Servern das Feature PAV (Parallel Access
Volume) und auf SX-Servern die I/O-Parellelisierung im Feature RSC nutzen.
Für die PAV- bzw. RSC-Nutzung in ARCHIVE wird (nur) an zentralen Stellen in die Pufferverwaltung und in das Lesen aus bzw.
das Schreiben in Dateien (bei Save bw. Restore) eingegriffen: Hier werden mehrere asynchrone IOs abgegeben, die bei PAV
dann zu paralleler Ausführung kommen und ohne PAV nacheinander ausgeführt werden (die I/O-Parallelisierung im RSC ist auf
SX-Servern standardmäßig vorhanden). Darüber hinaus wird auch beim Kopieren von Disk-Save-File auf Band-Save-File auf
asynchrone Verarbeitung umgestellt.
Die Parallelverarbeitung wirkt sich auf die Plattenschreibseite (Restore) und dadurch auf die Datenrate beim Lesen von Band
aus, außerdem wirkt sie sich bei Save und Restore auch positiv als kürzere Laufzeit aus.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 16 / 20
MAREN V11.0
Parameter-Änderungen sofort wirksam
Die MAREN-Parameter können für alle BS2000-Systeme im MAREN-Verbund von einem Administrator (insbesondere All-
Domain-Administrator) geändert werden. Die Änderungen wurden bis zur MAREN V10.0 nicht in allen Komponenten und auf
allen Systemen sofort wirksam: Im durchführenden MARENADM, in MARENCP und im MAREN-Subsystem auf demselben
BS2000-System wirkten sie sofort, ansonsten erst, wenn die Komponenten MARENCP, MARENUCP, MAREN und
MARENADM an allen betroffenen Systemen neu geladen wurden. In der MAREN V11.0 wird die sofortige Wirksamkeit von
Parameter-Änderungen durch folgende Maßnahmen erreicht:
• In MAREN und MARENADM wird der Parameter-Satz (HOSTREC) konsequent bei jeder Anweisung gelesen. An
MARENUCP wird der HOSTREC bei jedem Aufruf vom Subsystem mit übergeben. Sollen weitere Informationen übertragen
werden, so werden in den Anhang zum HOSTREC zusätzliche Kennzeichen eingefügt, die nach dem Lesen des HOSTREC
ausgewertet werden.
• Im system-übergreifenden MAREN-Betrieb wird für die MAREN-Administration ein Austausch von Nachrichten eingeführt.
Der MAREN-Administrator gibt bei den einschlägigen Anweisungen an, dass diese auch für andere als das eigene System
wirksam werden sollen. Bei der Abarbeitung der Anweisung wird von MARENADM bzw. innerhalb der MARENADM-Task im
Subsystem eine Nachricht an die vom Administrator angegebenen Systeme geschickt und ggf. auf Antwort gewartet. Auf den
angegebenen Rechnern wird die Nachricht ausgewertet und entsprechende Aktivitäten werden eingeleitet. Als
Kommunikationsmechanismus wird MSCF verwendet.
Außerdem wird in der MAREN V11.0 der Wechsel der Logging-Datei sofort wirksam.
Wechseln der Exits im laufenden Betrieb
In der MAREN V11.0 ist es möglich, die MAREN-Exits im laufenden Betrieb zu wechseln. Die analoge Funktion für die
MARENLM-Datei war in MAREN V10.0 bereits vorhanden.
Bei jedem Auftrag wird in MARENCP, MARENUCP, OFFLINE geprüft, ob eine zugewiesene Exit-Bibliothek seit der letzten
Prüfung geändert wurde. Dazu werden mit FSTAT CHANGE-DATE und CHANGE-TIME ermittelt und mit den früher gemerkten
Werten auf Gleichheit verglichen.
Bei einer Änderung werden alle geladenen Exits mit UNBIND entladen und mit BIND neu geladen. Damit muss der
Produktionsbetrieb nicht mehr unterbrochen werden, und das Ändern bzw. Korrigieren von Exits wird erheblich vereinfacht.
MAREN ablauffähig ohne TSOS
MARENUCP und //INITIALIZE-VOLUMES mussten bis zur MAREN V10.0 immer unter TSOS laufen. Da MAREN- bzw. TAPE-
Administratoren nicht auch immer zugleich Systemadministratoren sind, war dies unerwünscht.
In der MAREN V11.0 können MARENCP, MARENUCP und //INIT-VOL unter jeder Kennung mit dem Privileg TAPE-
ADMINISTRATION laufen. Um das Privileg TAPE-ADMINISTRATION für eine beliebige Kennung vergeben zu können, ist das
Produkt SECOS erforderlich. In Installationen ohne SECOS ist es in der MAREN V11.0 möglich, die Kennung SYSMAREN als
Alternative für den Ablauf von MARENUCP und //INIT-VOL zu nutzen. Als Vorleistung wurde bereits in OSD V6.0B die Kennung
SYSMAREN als neue Systemkennung mit dem Privileg TAPE-ADMINISTRATION eingerichtet.
Hinweis: Auch weiterhin laufen die MARENADM-Anweisung //CHECK-TSOSCAT und der //ADD-RESERVED-VOLUME –
Parameter VOLUME=*BY-TSOSCAT ausschließlich unter TSOS ab, da ein Zugriff auf alle TSOSCAT-Einträge möglich sein
muss.
Aus Gründen der Kompatibilität ist auch das bisherige Verfahren weiterhin möglich: Wenn die Operator-Rolle SYSMAREN nicht
existiert und das Programm unter TSOS läuft, wird wie bisher verfahren.
Volume-Gruppen
Seit MAREN V9.0B sind Bänder, die von HSMS / ARCHIVE logisch zusammenhängend erstellt wurden, in MAREN als
zusammengehörend gekennzeichnet. Sie können in MARENADM / MAREN - Anweisungen gemeinsam behandelt werden.
Im BS2000 werden jedoch auch andere Band-Sets erstellt. Diese entstehen zum Beispiel durch Anwendungen in Verbindung
mit dem DMS (Multifile- / Multivolume-Bänder) oder auch durch Backup-Läufe mit FDDRL. Die Bänder dieser Band-Sets kennt
MAREN bisher nur als Einzelbänder.
MAREN wurde in der V11.0 erweitert, um logisch zusammengehörende Bänder gemeinsam bearbeiten zu können. Dazu wurde
der Begriff Volume–Group eingeführt. Bändern kann als zusätzliches Attribut der Name einer Volume-Group zugewiesen
werden. Der Name der Gruppe ist frei wählbar. Welche Bänder zu einer Volume-Group gehören, kann nach beliebigen Kriterien
festgelegt werden. Dazu wurde die Anweisung //MODIFY-VOLUME-ATTRIBUTES entsprechend erweitert. Scratch-Bänder
können bereits während ihres Beschreibens einer Volume-Group zugeordnet werden, mittels des erweiterten Kommandos
/ADD-MAREN-FILE-ENTRY. Die Bänder einer Volume-Group können über MAREN mit den vorhandenen Selektions-
Mechanismen bearbeitet werden. Die MARENADM- und MAREN-Anweisungen wurden entsprechend erweitert.
MAREN V11.0 wurde ab BS2000/OSD-BC V5.0 freigegeben.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 17 / 20
ROBAR V6.0
Reduzierung des Net Traffic zwischen ROBAR-CL und ROBAR-SV
Um die Netzbelastung weiter zu reduzieren, wurde in der Kommunikation zwischen ROBAR-SV und ROBAR-CL eine
Optimierung vorgenommen. Die zu übermittelnden Meldungen werden jetzt bereits in ROBAR-CL vorgefiltert, so dass die
Netzbelastung und Auslastung der ROBAR-SV-Auftragsdatei besonders in Hochlast- oder Fehlersituationen deutlich reduziert
wird. Dadurch kann eine schnellere und sicherere Auftragsbearbeitung in ROBAR-SV erreicht werden.
Unterstützung zusätzlicher Menü-Fenster in ROBAR-SV
Zur Erleichterung der Bedienung und speziell der Überwachung von ROBAR-SV wurden vier weitere Menü-Fenster eingeführt.
Damit gibt es neben dem Administrator-Menü-Fenster, von dem alle Bedienfunktionen wie START/STOP und die manuelle
Eingabe von Kommandos an die Library möglich sind, bis zu fünf so genannte Operator-Menü-Fenster, mit denen die
Überwachung des ROBAR-Betriebs stattfinden kann.
Damit ist es für den Kunden möglich, die Überwachung des ROBAR-Betriebs gleichzeitig örtlich an verschiedenen Stellen
sicherzustellen.
Verbesserung der Benutzeroberfläche bezüglich Fehlermeldungen und Warnungen
Die Ausgabe von Meldungen wurde in allen Programmteilen überarbeitet und verbessert. So werden speziell bei der
Umsetzung der ROBAR-SV-Konfigurationsdatei umfangreiche semantische Prüfungen durchgeführt und damit die einzelnen
Sektionen übergreifend plausibilisiert. Außerdem wird als neues Feature in den Menu-Fenstern gemeldet, wenn die Verbindung
von ROBAR-SV zu den ROBAR-CLs auf den BS2000-Hostrechnern gestört oder nicht möglich ist.
Unterstützung der Library Scalar i500
In der ROBAR-Version V6.0 wurde die Steuerung des neuen Archivsystems Scalar i500 integriert. Das Archivsystem wird über
ein Storage Area Network (SAN) mit ROBAR-SV und dem BS2000 verbunden. Der unabhängige Betrieb von einzelnen
Partitionen wird ebenfalls unterstützt, wobei dann mehrere unabhängige ROBAR-SV-Instanzen auf die Partitionen (Lagerorte)
einer Scalar i500 zugreifen.
Einführung einer neuen HW/SW-Plattform (Primergy/Linux) für ROBAR-SV
Mit ROBAR-V6.0B erfolgt Ende 2007 die Portierung von ROBAR-SV auf die Intel/AMD basierte Primergy HW-Linie von FSC.
Als Basis-Betriebssystem kommt Linux (SuSE SLES 9) zum Einsatz. Damit steht dem Anwender eine weitere moderne,
leistungsfähige und zukunftsorientierte Plattform für den Einsatz von ROBAR-SV zur Verfügung. Es werden wie gewohnt alle
Archivsysteme wie auf der bisherigen Primepower/Solaris-Plattform unterstützt.
ROBAR V6.0 wurde ab BS2000/OSD-BC V5.0 freigegeben.
SHC-OSD V6.0
Schwerpunktthema der SHC-OSD V6.0 ist die Integration von TimeFinder/Snap und TimeFinder/Clone. Details siehe im Kapitel
‚Verbesserte Storage-Integration / Storage-Virtualisierung / Storage on Demand’, Abschnitt ‚Unterstützung neuer Symmetrix
DMX-Funktionen Snap und Clone’.
Neben Kommandoschnittstellen werden hier Programm-Schnittstellen zur Integration in Backup-Verfahren mit HSMS/CCOPY
für BS2000/OSD V7.0 und zur Snap-Nutzung aus DMS-Funktionen angeboten.
Ferner erfolgt mit SHC-OSD V6.0 die Unterstützung von SRDF/A-Erweiterungen, die mit Enginuity 5671 und SYMAPI V6.0
angeboten werden. SRDF/A ist eine asynchrone Spiegelungsfunktion für die Symmetrix-Plattensubsysteme der DMX-Familie,
die als wesentliche Neuerung im Vergleich zu bisherigen asynchronen Spiegelungsmodi Platten-übergreifende Datenkonsistenz
bietet.
Im Einzelnen:
• Konsistenter Übergang von SRDF/A nach synchronem SRDF
Ab Enginuity 5671 ist ein konsistenter Übergang für die Daten auf der Target-Seite von asynchron nach synchron möglich.
• Konsistenter TimeFinder Split (für BCV, Clone, Snap) am SRDF-Target. (SRDF/A Consistency Protection)
Die Consistency Protection kann für Geräte, die im SRDF/A-Modus arbeiten, enabled oder disabled werden. Sie bestimmt,
wie die Symmetrix reagieren soll, wenn Daten im SRDF/A-Modus nicht mehr von einer Source zur Target kopiert werden
können. Ist die Consistency Protection in diesem Fall enabled, dann werde alle Geräte „not ready on the link“ gesetzt, damit
alle Target-Daten konsistent bleiben.
SHC-OSD V6.0 wurde ab BS2000/OSD-BC V5.0 freigegeben.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 18 / 20
SHC-OSD V6.1
SHC-OSD V6.1 (Freigabe September 2007) enthält folgende Erweiterungen gegenüber V6.0:
HW-Anpassungen
• SYMAPI V6.4 mit PTHREAD-Mode
• Unterstützung von RAID6 (in Enginuity-Version 5772)
• Unterstützung von Enginuity-Version 5772
Funktionserweiterungen
• Unterstützung des EMC-Produktes SYMACL (Symmetrix Access Control)
• Unterstützung der TimeFinder/Snap-Erweiterung auf 127 Snapshots)
• Erweiterung der TimeFinder/Clone-Funktionen
• Performance-Verbesserungen durch Flexibilisierung des Event-Monitoring
SHC-OSD V6.1 wird ab BS2000/OSD V5.0 freigegeben.
VM2000 V9.0
VM2000 V9.0 ist die VM2000-Version für BS2000/OSD V7.0 mit der Unterstützung von BS2000/OSD V7.0 als Monitorsystem.
VM2000 V9.0 unterstützt
• Auf S-Servern OSD V6 sowie OSD V7 als Monitorsystem, OSD V5 – OSD V7 als Gastsysteme,
• Auf SX-Servern OSD V6- bzw. OSD V7- basierte OSD/XC Pakete als Monitorsystem, OSD V5- bis OSD V7- basierte
OSD/XC Pakete als Gastsystem.
VM2000 V9.0 setzt auf SX-Servern X2000 ab V3.0 voraus.
Hinweis: VM2000 V8.0 kann bereits BS2000/OSD V7.0 als Monitorsystem und als Gastsystem unterstützen.
Die wesentlichen neuen Funktionen von VM2000 V9.0 sind:
VM-Zuordnung von Pubsets
Die Zuordnung der Geräte eines Pubsets an eine VM wird wesentlich vereinfacht. Pubset-Rekonfigurationen (z.B. Erweiterung)
werden automatisch berücksichtigt. Kommandoprozeduren zum Einrichten von VMs werden kürzer und übersichtlicher und
brauchen insbesondere bei Nutzung des in BS2000/OSD-BC V7.0 neuen Provisioning-Tools SPACEPRO nicht mehr angepasst
zu werden.
Die explizite Zuordnung bzw. die Festlegung der Möglichkeit der impliziten Zuordnung eines Pubsets erfolgt über die Angabe
des Pubres Gerätes oder der Catid.
Bei Pubset Rekonfiguration werden die VM-Zuordnung und die Attribute der impliziten Zuordenbarkeit für die betroffenen
Geräte automatisch angepasst.
Feinere Privilegierung für die implizite Zuordnung von Geräten
Die implizite Zuordnung von Geräten an eine VM (im Rahmen von ATTACH für das Gerät im Gastsystem) setzt die
Privilegierung der VM und die Freigabe des Gerätes für die Funktion voraus.
VM2000 V9.0 ermöglicht
• die Unterteilung der Geräte in so genannte ASSIGNMENT-Sets für die implizite Zuordnung
• die Vergabe von korrespondierenden VM-Privilegien.
Diese Funktion eröffnet vielfältige Nutzungsszenarien:
• Für eine VM bzw. eine VM-Gruppe kann jetzt eine exklusive Menge von Geräten/Pubsets für die implizite Zuordnung
festgelegt werden.
• Die VM-Zuordnung für Pubsets, aus denen sich das Tool SPACEPRO bedient, erfolgt implizit. Ein solches Pool-Pubset kann
damit nur für eine ausgewählte Menge von VMs freigegeben werden.
Unterstützung von Snapsets
BS2000/OSD-BC V7.0 unterstützt erstmals Snap-Techniken für Platten im Rahmen von so genannten Snapsets und von Snap-
Sessions. VM2000 V9.0 zeigt Snap-Units in seinen SHOW-Kommandos an und bietet eine automatische Zuordnung für diese:
Eine VM kann sich bei entsprechender Privilegierung Snap-Units für die Snapsets zuordnen, ohne dass für diese Geräte in
VM2000 eine Vorbereitung notwendig ist.
Verbesserte Unterstützung sehr großer Konfigurationen
Größere Hauptspeicher für VMs
Einer VM kann mit VM2000 V9.0 ein Hauptspeicher größer 32 GB zugeordnet werden. Dies gilt auch für die bisher auf 2 GB
beschränkte VM1. Der Hauptspeicher der VM1 kann künftig dynamisch erweitert und reduziert werden.
HIPLEX-MSCF-koordinierter Move einer VM
Während des Verschiebens einer VM im Hauptspeicher wird diese angehalten. Der Vorgang bedeutet für VMs von der Größe
mehrerer Gigabytes, die an einem HIPLEX-MSCF-Verbund teilnehmen, eine kritisch lange Ausfallzeit. VM2000 V9.0 verständigt
die HIPLEX-MSCF-Partner davon vorab, so dass eine automatische Rekonfiguration wegen Partnerausfall unterbleibt.

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 19 / 20
Verbesserte Unterstützung sehr kleiner VMs
VM2000 V9.0 unterstützt den Betrieb von VMs mit einer Leistungszuteilung (CPU-QUOTA und MAX-CPU-UTILIZATION), die
im Promillebereich der Serverleistung liegt. Damit sind auch bei sehr großen S-Servern VMs mit einstelliger RPF-Leistung
möglich. Zusätzlich wird das VM-Scheduling für kleine VMs verbessert: kürzere Zeitscheiben garantieren für diese eine zwar
stärker begrenzte, aber ausreichend häufige CPU-Aufnahme.
Kombinierbarkeit von VM-Gruppen und CPU-Pools
VM-Gruppen ermöglichen ein Service Level Management für Kunden mit mehreren VMs. Die Unterteilung eines Servers in
CPU-POOLs verbessert die VM2000 Performance für Server mit höherem MP-Grad. VM2000 V9.0 erlaubt VM-Gruppen nicht
nur in genau einem ausgezeichneten CPU Pool einzurichten, sondern eine uneingeschränkte Kombinierbarkeit.
Shutdown für einzelne VMs und koordiniert für das gesamte VM2000
Der VM2000 Administrator erhält die Möglichkeit, Shutdown für einzelne VMs einzuleiten. Neben der Ausführung des
SHUTDOWN-Kommandos wird der Anstoß einer „Shutdown“-RUN-Datei ermöglicht. Als weitere Funktion wird ein zwischen
Gastsystemen und Monitorsystem koordinierter VM2000 Shutdown ermöglicht. Als erstes wird in allen OSD V7 Gastsystemen
automatisch Shutdown eingeleitet. Nach Beendigung aller wird ein solcher in der VM1 eingeleitet. Dieser beendet dann auch
VM2000.
Verbessertes Performance Monitoring mit SHOW-VM-STATUS
Das VM2000 Kommando SHOW-VM-STATUS liefert CPU-Auslastungsdaten und interne Performance-Kenngrößen in einer
periodischen Ausgabe. Das Kommando bietet künftig auch die einmalige, synchrone Ausgabe der Messdaten der unmittelbar
letzten Vergangenheit. Diese Funktion ist im Gegensatz zur periodischen Ausgabe nicht auf einen Arbeitsplatz beschränkt.
SW-Produktübersicht
Die folgende Übersicht enthält alle SW-Produkte, für die zur Unterstützung der BS2000/OSD V7.0 eine neue Version
freigegeben wird, mit einer Zusammenfassung der jeweiligen neuen Funktionen.
Produkt Version Neue Funktion mit OSD V7.0
ARCHIVE V8.0B • Parallele Plattenzugriffe durch asynchrone I/Os und PAV-Nutzung (Performance)
COSMOS V16.0 • Anpassung an BS2000/OSD-BC V7.0 (technisch gekoppeltes Produkt)
CRTE V2.7 • Laufzeitsystemunterstützung von COBOL2000 V1.4 (Unicode-Unterstützung)
DAB V9.1 • Anpassung an BS2000/OSD-BC V7.0 (technisch gekoppeltes Produkt)
FDDRL V16.0 • Sicherung mehrerer Platten auf ein Tapeset
• Multiplexing: Gleichzeitiges Sichern von 2 Platten auf 1 Tapeset
• RELOAD PUBSET: Automatisierte Pubset-Rekonstruktion
FDDRL-OS V16.0 • technisch gekoppelt an FDDRL V16.0
HIPLEX-MSCF V5.0 • Anpassung an BS2000/OSD-BC V7.0 (technisch gekoppeltes Produkt)
HSMS V8.0B • Integration von Snapsets in die Sicherungsverfahren
• Datensicherung von TimeFinderClones
• Parallele Plattenzugriffe durch asynchrone I/Os und PAV-Nutzung (Performance)
LMS V3.3B • Restore von Bibliothekselementen aus Snapsets
MAREN V11.0 • Parameter-Änderungen sofort wirksam
• Wechsel der Exits im laufenden Betrieb
• MAREN ablauffähig ohne TSOS
• Volume-Gruppen
openNet Server V3.2 • VLAN-Unterstützung in BCAM
• Unicode-Unterstützung (XHCS V2.0, VTSU-B V13.2)

White Paper ⏐ Ausgabe: April 2009 ⏐ BS2000/OSD V7.0 Seite 20 / 20
Produkt Version Neue Funktion mit OSD V7.0
openSM2 V7.0 • Support für SPACEPRO (Online Provisioning),
• Anpassung an BS2000/OSD-BC V7.0 (technisch gekoppeltes Produkt)
PCS V2.8 • Unterstützung von IO-Prioritäten in Verbindung mit IORM
PERCON V2.9 • Unterstützung Unicode: Normalisierung und Code-Umwandlung von Dateien
RFA V16.0 • Anpassung an BS2000/OSD-BC V7.0 (technisch gekoppeltes Produkt)
RSO V3.5 • Sicheres Drucken mit IPP V1.1
• Einfache Header-/Trailer-Page-Anpassung
• Unicode-Unterstützung (HW-abhängig)
SCA V16.0 • Anpassung an BS2000/OSD-BC V7.0 (technisch gekoppeltes Produkt)
SHC-OSD V6.0 • Unterstützung TimeFinder/Snap und TimeFinder/Clone
• Abrundung SRDF-A
SORT V7.9 • Unicode-Unterstützung.
SPACEOPT V4.0 • Anpassung an BS2000/OSD-BC V7.0 (technisch gekoppeltes Produkt)
TASKDATE V16.0 • Anpassung an BS2000/OSD-BC V7.0 (technisch gekoppeltes Produkt)
VM2000 V9.0 • OSD V7 Zulieferungen zu IORM, Snapset-Support
• Device-Assignment für Pubsets
• Vollständige Unterstützung großer Konfigurationen
Alle Rechte vorbehalten, insbesondere gewerbliche Schutzrechte. Änderung von technischen Daten
sowie Lieferbarkeit vorbehalten. Haftung oder Garantie für Vollständigkeit, Aktualität und Richtigkeit
der angegebenen Daten und Abbildungen ausgeschlossen. Wiedergegebene Bezeichnungen
können Marken und/oder Urheberrechte sein, deren Benutzung durch Dritte für eigene Zwecke die
Rechte der Inhaber verletzen kann.
Weitere Einzelheiten unter ts.fujitsu.com/terms_of_use.html
Herausgegeben durch:
Margret Germann
Telefon: ++49 (0)89 3222 2623
Fax: ++49 (0)89 3222 329 2623
Margret.Germann@ts.fujitsu.com
de.ts.fujitsu.com
Partner login
partners.ts.fujitsu.com
Copyright © Fujitsu Technology Solutions GmbH 2009