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 Anwendungsfälle 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.

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.

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.

Ä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.

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.

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.

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.