DE / EN / IT

tcVISION Anwendungsbeispiele

Finanzinstitut

Schwerpunkt

Retail Banking and Small Business, Corporate Lending and Investments und Treasury Services and Markets

Ausgangslage

  • IBM Mainframe mit dem Betriebssystem z/OS
  • Oracle auf der Open System Seite
  • Die Unternehmensdaten werden in Db2 Datenbanken vorgehalten.

Ziel

Reduzierung der Mainframelast und -kosten, indem Daten aus dem Kernbanksystem in einem kostengünstigeren System in Echtzeit zur Verfügung gestellt werden, um Leseoperationen auf die neue Infrastruktur zu führen.

Umsetzung

Zur Replikation der Daten wird tcVISION eingesetzt, als kostengünstiges System zur Speicherung der Daten wird Apache Hadoop verwendet. Dadurch können auch zahlreiche andere Use Cases abgedeckt werden. Dazu gehören Realtime-Event-Handling & Stream Processing, Analytics auf in Echtzeit verfügbare Daten sowie die Möglichkeit, strukturierte und unstrukturierte Daten hochperformant auswerten zu können. Das System wird auf Commodity Hardware sehr kostengünstig betrieben und ist linear praktisch unbegrenzt skalierbar. Dabei sind die Replikationskosten (CPU-Verbrauch) durch tcVISION im Vergleich zur Einsparung sehr gering.

tcVISION ermöglicht eine signifikante Reduktion der Mainframekosten, wobei es selbst durch die Logfile-basierte Replikation sehr sparsam ist. Darüber hinaus besteht die Möglichkeit, auf Basis der replizierten Daten zahlreiche Anwendungsfälle zu implementieren, die auf einem Mainframe zu ressourcenintensiv wären.

 

 

Finanzinstitut

Schwerpunkt

Datenprovider für Stamm- und Bewegungsdaten

Ausgangslage

  • IBM Mainframe mit z/OS
  • Datenhaltungssystem Db2

Ziel

  • Flexible Datenverteilung
  • Reduzierung des Datentransfervolumens

Umsetzung

Die Verteilung der Abonnement-Daten an die einzelnen Kunden wird von tcVISION übernommen. Die abonnierten Daten werden von tcVISION in Echtzeit aus dem aktiven Log eines Shared Db2 unter z/OS verarbeitet. tcVISION nutzt hierfür das Instrumentation Facility Interface des Db2. Die Änderungsdaten werden über TCP/IP an ein Intel-basiertes Linux System übermittelt und dort anhand von Attributen im Datensatz an die Kunden verteilt.

Technisch wurde die Verteilung der Daten entsprechend den Abonnements der Kunden durch eine Bitleiste in Form eines Integer-Attributs auf den relevanten Tabellen gelöst. Jeder zu replizierende Satz wird anhand logischer Bitvergleiche mit einem je Ausgabe unterschiedlichen Vergleichswert überprüft, ob dieser auch an den Kunden zu senden ist. Wenn dieser Bitvergleich nicht erfolgreich ist, wird dieser Satz verworfen. Zusätzlich zu der Bitleisten-Logik kommen ein Vergleich mittels Lookup-SQL als auch Vergleiche von Zeichenketten für nicht lizenzierte Produkte zum Einsatz.

Um jeden Kunden bedarfsorientiert versorgen zu können, wurde ein Abonnierungssystem geschaffen, welches nur noch die vom Kunden abonnierten Kurse überträgt.

Die zur Verarbeitung notwendigen Definitionen werden im zentralen Repository von tcVISION hinterlegt.

 

 

Technisches Dienstleistungsgewerbe

Schwerpunkt

Verwaltung von Infrastrukturen und technischen Diensten für Finanzinstitute, Zentralinstitute, Unternehmen und öffentlichen Verwaltungen in den Bereichen des elektronischen Zahlungsverkehrs, den Netzwerk Services und Kapitalmärkten

Ausgangslage

  • IBM Mainframe mit z/OS, z/VM und z/Linux, Linux Server, UNIX und Windows Workstations
  • Die Datenbanken basieren auf der Leistungsfähigkeit von Db2 und Oracle.

Ziel

Replikationslösung mit

  • möglichst geringer Mainframelast
  • zentraler Konsole zur Überwachung und Verwaltung der auszuführenden Operationen für die Datenreplikation
  • Funktionen für die Einspeisung der Datenbank Oracle, sowohl für das anfängliche Laden als auch für die Replikation in „Near-Realtime”

Umsetzung

Die tcVISION Replikation basiert auf einem zentralen Repository. In diesem Repository sind alle für die Verarbeitung notwendigen Metadaten, Transformations- und Replikationsregeln abgelegt. Das Repository kann in einer beliebigen Datenbank gespeichert werden, wie z.B. Db2 oder Oracle.

Die Änderungsdaten werden in Echtzeit aus dem aktiven Db2 Log über die Db2 Instrumentation Facility ermittelt bzw. während der Batchverarbeitung aus einer Kombination von archivierten und aktiven Db2 Logs.

Die tcVISION Manager unter z/OS sind mit den anderen tcVISION Managern (z/OS und z/LINUX) über TCP/IP verbunden. Die Änderungsdaten werden in das jeweilige Zielsystem über Db2 bzw. dem Oracle Call Interface (OCI) appliziert.

Vom tcVISION Controlboard (GUI) werden alle Systeme überwacht und die Replikationsszenarien implementiert.

Die Replikation ist ausfallsicher und kann jederzeit aufgesetzt werden.

 

 

Versicherung

Schwerpunkt

Versicherungs- und Vorsorgelösungen in den Bereichen Schaden- und Unfall- sowie Lebensversicherung

Ausgangslage

  • IBM Mainframe mit z/OS
  • Datenbanksystem Db2
  • Data Warehouse

Ziel

  • Tagesaktuelle Versorgung des Data Warehouses mit den Db2 Daten
  • Verlagerung des Reportings aus den Db2 Tabellen vom Mainframe auf ein gespiegeltes Db2 System auf einem Windows Server

Umsetzung

Änderungen an über 350 Db2 Mainframe-Tabellen werden auf die gespiegelten Db2 Tabellen auf dem Windows Replikationsserver repliziert. Das Replikationsverfahren ist im operativen Ablauf des Rechenzentrums integriert.

Änderungen im Db2 werden von den Onlinesystemen und von Batchprogrammen durchgeführt. Die zu replizierenden Tabellen haben das Attribut „DATA CAPTURE CHANGES“ und die Änderungen werden im Db2 Log festgehalten. Sobald die Online Logs von Db2 archiviert werden, werden diese Dateien über FTP Prozesse auf den Replikationsserver übertragen und dort von tcVISION verarbeitet. tcVISION benötigt dazu Kenntnisse über die Strukturen der Db2 Tabellen, damit die Änderungen in den Log-Dateien erkannt und aufbereitet werden können. Diese Metadaten werden von tcVISION in einem zentralen Repository gespeichert, welches ebenfalls im Db2 liegt. Diese Metadaten werden über Importfunktionen aus dem Db2 erstellt und sind die Grundlage für das erstmalige Laden einer Db2 Tabelle auf dem Server und für die Verarbeitung der Log-Dateien.

Das erstmalige Laden der Db2 Tabellen auf den Replikationsserver wird mittels der BULK TRANSFER Funktion von tcVISION durchgeführt. Eingabe ist ein Db2 Imagecopy, das per FTP auf den Replikationsserver übertragen und dort eingelesen, verarbeitet und mit einem durch tcVISION erzeugten Load-Statement geladen wird. Danach stehen die Tabellen auf dem Replikationsserver zur Verfügung und Änderungen werden über die Log-Dateien verarbeitet.

Die Informationen über die verwendeten Compression Algorithmen werden beim Import der Metadaten von tcVISION festgestellt und im zentralen Repository hinterlegt. Im z/OS wird jede Db2 Tabelle in einem eigenen Tablespace gespeichert. Im Repository sind die unterschiedlichen Versionen von Dictionaries gespeichert, sodass beim Einspielen von Log-Informationen oder Imagecopies je nach Aktualität das zugehörige Compression-Dictionary zur Dechiffrierung verwendet werden kann. Die Metadaten beschreiben die Struktur, wie die Daten zum Zeitpunkt des Strukturimports abgelegt sind. tcVISION historisiert diese Strukturinformation sofern bei einer Strukturänderung ein neuer Import erfolgt. Damit kann tcVISION Änderungen der Datenstruktur erkennen und Daten entsprechend der zum Zeitpunkt ihrer Entstehung gültigen Struktur in die Zieltabelle einpflegen. Aus diesem Grund werden jeden Tag die Strukturinformationen über einen automatisierten Prozess importiert. Dadurch wird sichergestellt, dass immer die richtigen Metadaten und Compression Informationen herangezogen werden. tcVISION bietet Hilfsmittel an, um die historischen Repositoryeinträge, die nicht mehr zur Verarbeitung herangezogen werden, gezielt zu löschen.

Die tägliche Verarbeitung der Db2 Änderungen ist nahezu vollständig automatisiert.

 

 

Metallindustrie

Schwerpunkt

Herstellung von Beschlagsystemen

Ausgangslage

  • IBM Mainframe mit z/OS und Programmiersprache PL/I
  • Windows Systeme mit Db2/LUW
  • Datenbanksysteme Db2/zOS und DL/I, Oracle im Data Warehouse
  • Mehrere Application Server mit Java

Ziel

  • Stammdatenhaltung in Db2 parallel zu DL/I
  • Migration der DL/I Datenbanken nach DB/2
  • Realisierung des Operational Data Stores, d.h. zeitnahes Kopieren operativer Datenbestände für Auswertungszwecke
  • kontinuierliche und bidirektionale Datenreplikation zwischen der Zentrale und den Tochtergesellschaften
  • unidirektionale Replikationen zwischen Systemen z.B. Mainframe und Oracle Datawarehouse
  • Möglichst wenig Belastung der Produktionssysteme

Umsetzung

Die Replikation ist bidirektional, das heißt beide DB/2 Systeme sind gleichberechtigt und Änderungen auf beiden Systemen müssen repliziert werden. Hierzu wird die Replikationsmethode ‚Near Realtime‘ von tcVISION verwendet. Die Änderungen auf alle Tabellen mit einem 'Change Data Capture' Flag werden aus dem Active Log von Db2 extrahiert und an das Partnersystem repliziert. Da es sich um eine bidirektionale Implementation handelt, muss sichergestellt sein, dass Änderungen, die in einem System bereits durchgeführt wurden, nicht wieder zurückrepliziert werden. Dies wird in den Replikationsscripten von tcVISION überprüft und somit werden eventuelle 'Loopback'-Effekte verhindert. Diese Replikation zwischen dem Db2/zOS und dem Db2/LUW geschieht über einen dedizierten LINUX Rechner.

 

 

Informationsdienstleister

Schwerpunkt

Gemeinsame Datenverarbeitung mit integrierten Fachanwendungen und einheitlichen Datenbeständen für landwirtschaftliche Organisationen

Ausgangslage

  • z/OS-System mit Adabas
  • Linux mit Oracle
  • Mainframeanwendungen in PL/I und NATURAL

Ziel

Bidirektionale Datensynchronisation in Echtzeit zwischen Mainframe mit Adabas und Linux mit Oracle

Umsetzung

Das Synchronisationsverfahren basiert auf der Replikation der Mainframe Änderungen in Echtzeit. Die Änderungsdaten werden von der Adabas Extension des tcVISION ermittelt und über einen Datenkollektor und Datenpool an ein LINUX System propagiert. Dort ist eine Oracle Datenbank installiert, in der die Adabas Datenbanken gespiegelt sind. Die Mainframe Änderungen werden von tcVISION direkt in das Oracle System eingestellt.

Beide Plattformen sind gleichberechtigt (Master/Master). Änderungen auf dem Mainframe werden in Echtzeit von der tcVISION DBMS Extension für Adabas ermittelt und direkt in eine Oracle Spiegeldatenbank repliziert. Von dort werden die Änderungen in die Oracle Betriebsdatenbank eingespielt.

Der Replikationsweg von Oracle zum Adabas auf dem Mainframe geht über Oracle und die JDBC Komponente von tcACCESS.

Eine in PL/I geschriebene tcACCESS Stored Procedure übermittelt die Adabas Internal Sequence Number (ISN) für neu aufgenommene Records an die Oracle Umgebung.

Die bidirektionale Replikation stellt sicher, dass Änderungen, die auf einer Plattform bereits durchgeführt wurden, nicht über das Capturing wieder zurückrepliziert werden (tcVISION Loopback Verfahren).

Protokolldateien dokumentieren den ordnungsgemäßen Ablauf der bidirektionalen Replikation.

 

 

Versicherungsgruppe

Schwerpunkt

Krankenversicherungsspezialist der Volksbanken Raiffeisenbanken

Ausgangslage

  • Mainframe mit z/VSE
  • Onlinesysteme laufen unter CICS, die Datenhaltung wird mit VSAM abgedeckt.

Ziel

Migration der VSAM/COBOL-Anwendungen zu MS-SQL Server/Java; sowohl das Entladen der VSAM-Dateien und Laden in SQL Server Tabellen als auch eine bidirektionale Synchronisation in Echtzeit zwischen VSAM und MS-SQL Server

Umsetzung

Es wurde ein Verfahren über tcVISION entwickelt, welches bidirektionale Änderungen erkennt und mehrfache Änderungen sicher ausschließt.

tcVISION wird vor allem dazu verwendet, in zeitgesteuerten Jobs eine Reihe von VSAM-Dateien in größtenteils der VSAM-Struktur entsprechende SQL-Tabellen zu übertragen. Pro Woche werden so zu verschiedenen Zeitpunkten insgesamt bis zu ~ 30 Mio. Datensätze übertragen.

Diese Seite verwendet Cookies.

Durch die Nutzung dieser Seite erklären Sie sich damit einverstanden. Zu unserer Datenschutzerklärung.

Weiter