Success Story

2014: GDIS UND BOI

Über 25 Jahre Erfolg und Vertrauen.
ZUSAMMENFASSUNG

Die Generali Deutschland Informatik Services GmbH – damals noch Aachener und Münchener Informatik-Service AG – ist seit Mai 1992 treuer Kunde der BOI.

Innerhalb der Generali Deutschland Gruppe tritt die GDIS als zentraler IT-Dienstleister für den gesamten Konzern auf. Ihre Kernkompetenzen liegen auf dem stabilen und kostengünstigen Betrieb einer Multi- Plattform-Infrastruktur und der Entwicklung von leistungsfähigen und zukunftssicheren IT-Anwendungen.

Anfang der 90er Jahre wurde bei der Aachener und Münchener Informatik-Service AG die Kraftfahrt-Anwendung „K-Neu“ entwickelt. Die Architektur dieser Anwendung baute auf komplexen Steuerungen auf, welche im DB2 wegen unzureichender Performance nicht sinnvoll umgesetzt werden konnten.

Daher war man auf der Suche nach einem Tabellenverwaltungssystem, mit dessen Hilfe Tabellenzugriffe hoch-performant möglich wurden. TABEX erhielt den Zuschlag, da sich TABEX gegenüber anderen Tabellenmanagementsystemen mit einer höheren Performance der Tabellenzugriffe auszeichnet und somit den Anforderungen der Aachener und Münchener Informatik-Service AG am besten entsprach. Seit damals wird TABEX produktiv im Unternehmen eingesetzt.

Generali Gruppe Österreich: Allspartenversicherer mit einer um Finanzdienstleistungen erweiterten Angebotspalette; gehört zum Konzern der Assicurazioni Generali S.p.A. in Triest, Italien.

  • Mitarbeiter: 4.811 (2012)
  • Bilanzsumme: 14,99 Mrd. EUR (2012)
  • Drittgrößter Versicherungskonzern Österreichs mit rund 15% Marktanteil
  • Jährlich etwa 999 Milliarden Datentransaktionen
Die Nutzung der Common Data Space Technologie eröffnet den BOI-Kunden entscheidende Wettbewerbsvorteile.

GDIS | Common Data Space Technologie in TABEX

Die Success Story

Herausforderung

Anfang der 90er Jahre wurde bei der Aachener und Münchener Informatik-Service AG die Kraftfahrt-Anwendung „K-Neu“ entwickelt. Die Architektur dieser Anwendung baute auf komplexen Steuerungen auf, welche im DB2 wegen unzureichender Performance nicht sinnvoll umgesetzt werden konnten.

Daher suchte man ein Tabellenverwaltungssystem, mit dessen Hilfe Tabellenzugriffe hoch-performant möglich wurden.

Ziele

  • Einsatzmöglichkeit unter TSO, CICS, IMS/DC und Batch
  • Komfortable Pflege der Tabellen durch die Fachabteilungen der Konzerngesellschaften
  • Gültigkeitsbeschränkungen der Tabellen abhängig vom Datum
  • Zugriffsbeschränkungen im weitesten Sinne, wenn möglich unter RACF
  • Kompatibilität mit DB2, sowohl was Pflege der Daten als auch Datenbankzugriffe betrifft
  • Einfache Wartung und Weiterentwicklung des Systems
  • Möglichkeit der Abbildung des hauseigenen Freigabeverfahrens

Lösung

Mit der Einführung der Common Data Space-Architektur durch IBM wurde der Einsatz von Datenräumen neben den Adressräumen möglich. TABEX wurde dahingehend erweitert, dass es Tabellen in den Common Data Space laden konnte. So wurde die Performance durch die Verwendung der Zugriffe auf dieselben im Speicher geladenen Tabellen aus allen Regions wesentlich gesteigert.

TABEX nutzt weiters die Möglichkeit, dass nach der Einführung der 31-bit-Adressierung neben den Adressräumen für die Anwendungen auch virtuelle Datenräume bis 2 GB bereitgestellt werden. Die Common Data Space-Technologie erlaubt das zentrale Speichern von Daten im Hauptspeicher und den Zugriff auf diese zentral geladenen Daten. Diese Vorgehensweise wurde später in TABEX auch für Betriebssysteme wie Linux, Unix, Solaris oder Windows realisiert.

Diese Technologie garantiert, dass nur eine Kopie einer Tabelle in allen Anwendungen verwendet wird. Außerdem muss kein Datenbankzugriff erfolgen. So kann performant und ohne zusätzlichen Speicherverbrauch auf Daten zugegriffen werden.

Nutzen

Die Verwendung der Common Data Space Technologie in TABEX bietet eine Vielzahl an Vorteilen:

  • Lesende Zugriffe mit High-Performance-Calls
  • Das Befüllen bzw. Reorganisieren von Datenräumen kann ohne Auswirkung auf Anwendungen durchgeführt werden (unterbrechungsfreier Switch zwischen Lade-Datenraum und Arbeitsdatenraum nach Datenänderung oder Reorganisation)
  • keine Synchronisation erforderlich
  • Zugriff auf den richtigen Pfad über Zugriffsmodul in STEPLIB-Verkettung
  • Datenräume abhängig von DB/DC-Umgebung
  • Getrennte Datenräume für die verschiedenen integrierten Gesellschaften (Mandantenfähigkeit) analog zu IMS und DB2. Zur Mandantentrennung werden unterschiedliche Suchpfade und Projektkennungen verwendet.
  • Mehrere Common Data Spaces können parallel aktiv sein und mit unterschiedlichen Tabellen befüllt werden. Durch anwendungsspezifische Pfadangaben (diese definieren den Suchpfad) und Projektkennungen kann die Reihenfolge der Suche z.B. für Instanzen, Mandanten, verschiedene Umgebungen etc. gesteuert werden.
  • Durch die Adressierung jeder Tabelle mittels Name, Datum und File-ID kann neben der Versionierung auch die IT-Organisation durch organisatorische Zugriffssteuerung des Kunden abgebildet werden. Über die zusätzliche Projektkennung sind unterschiedliche Instanzen oder Teststufen möglich. Es wird sichergestellt, dass immer nur auf die richtige Version der Tabellen zugegriffen wird.
  • Ein spezieller Datenraum kann verwendet werden, um Daten zwischenzuspeichern, die nicht von einem Rollback betroffen sein sollen. Dieser wird z.B. genutzt, damit Anwendungen Vertragsnummern, die bei ihrer Bearbeitung zu Abstürzen führen, im nächsten Lauf ausgesteuert werden können. Wichtig dabei ist, dass eine Vertragsnummer in diesem Fall nicht durch ein Rollback verloren geht (dies wäre bei DB2-Speicherung der Fall) bzw. dass die Performance der Anwendung durch Schreiben der Vertragsnummern in eine Datei nicht negativ beeinflusst wird.

Den größten Vorteil der Common Data Space Technologie sieht die GDIS in der hohen Performance der Zugriffe: Nach eigenen Messungen sind die Speicherzugriffe unter Verwendung der Common Data Space Technologie bis 20x schneller als DB2.

GDIS | Vorteile Common Data Space Technologie

BOI Customer Cloud