tRelational / DPS Adabas-to-Oracle Success in South Africa

by Hans-Peter Will, Senior Technical Representative and Joseph Brady, Manager of Marketing and Technical Documentation at Treehouse Software, Inc.

Recently, Hans-Peter Will, Senior Technical Representative for Treehouse Software, traveled to South Africa to assist our partner Bateleur Software (pty) Ltd. with setting up a large public-sector customer’s data replication implementation using our Adabas-to-RDBMS tool set, tRelational / DPS (Data Propagation System).

Arriving in Johannesburg, Peter met with representatives from Bateleur and the IT Organization, where the key players discussed how tRelational / DPS was going to be used in the project. The customer initially wanted to populate sample data into Oracle, so Peter configured tRelational / DPS to process one of the smaller Adabas files to generate some data. He also recommended running an analysis with tRelational to determine whether the file contained a unique key. Peter took this opportunity to show the customer what other benefits they could realize out of the analysis information. Interestingly, they used a personnel file for analysis, and Peter was immediately able to show that 23 of the records had no gender entry and 180 of records had no surname. The customer was very pleased to see these revelations in the first analysis, and looked forward to identifying other data quality issues before commencing data replication.

Customer Replication Scenario with Treehouse Software Product Set…

_0_tReDPS_Replication_Scenario

The next step was to build the target structure in accordance with the Oracle DBA’s requirements. The DBA had specified that all columns were to be defined as VARCHAR2, except the date information. After the first model was completed, DDL and DPS parameters were generated and a quick materialization of data accomplished the desired result.

At the subsequent kickoff meeting, Peter provided a complete tRelational / DPS overview and discussed the target structure with the attendees and the Oracle DBA. The rest of the day was spent doing Adabas file implementations, analysis and modeling.

Setup was then completed for transferring extracted and transformed Adabas data into the customer’s Windows environment. Adabas Vista is used, so that one logical Adabas file was actually split into two files stored on different Adabas databases, and the customer wanted to combine them into the same target table in Oracle. While there was no unique descriptor, it was discovered that three fields in combination would make a unique key, enabling the model to be created to combine data from the separate physical files into a single Oracle table.

The team proceeded with file implementation, modeling, mapping, DPS executions, and resolving data issues. Various issues that were encountered, like invalid tab characters within the data, negative personnel numbers, duplicates in unique keys (maintained by the application) and the need to add an extra column to the output. These issues were resolved quickly by the customer’s staff.

Within a day, all the files were materialized and the PLOG copy process was modified so that from that point forward, every PLOG copy would automatically be processed through DPS Propagation to update the RDBMS on the target Windows machine.

The next day, Peter was asked by the customer, “How many of the files have been processed so far?”. Peter was pleased to report that every file was processed and was propagating successfully. The happy customer remarked that they never had a project that was completed this far ahead of the deadline.

Throughout the project, Peter never personally laid hands on a customer keyboard, but instead sat with staff, effectively training them and handing over comprehensive knowledge of tRelational / DPS. The customer was very excited to learn that their personnel can now easily use the product set to do any remaining work on their own.

A few days later, we received an e-mail from Bateleur:

“I had a very pleasant meeting with the customer today. They used tRelational to reject the non-unique keys, reran the Materialization, and reran DPS plus update into Oracle. The month-end update of Oracle that was taking nearly three days to complete, now takes five Minutes! Everyone delighted!”

Bjørn (Sam) Selmer-Olsen, Managing Director, Bateleur Software (pty) Ltd


About Treehouse Software’s tRelational / DPS Product Set

tReDPS_DIAGRAM

tRelational / DPS is a robust product set that provides modeling and data transfer of legacy Adabas data into modern RDBMS-based platforms for Internet/Intranet/Business Intelligence applications. Treehouse Software designed these products to meet the demands of large, complex environments requiring product maturity, productivity, feature-richness, efficiency and high performance.

The tRelational component provides complete analysis, modeling and mapping of Adabas files and data elements to the target RDBMS tables and columns. DPS (Data Propagation System) performs Extract, Transformation, and Load (ETL) functions for the initial bulk RDBMS load and incremental Change Data Capture (CDC) batch processing to synchronize Adabas updates with the target RDBMS.

Visit the Treehouse Software website for more information on tRelational / DPS, or contact us to discuss your needs.

TREETIP: tcVISION Supports Data Replication to MongoDB

tcVISONv6

The tcVISION cross-system integration platform is a robust, proven, and mature solution that is constantly under development to meet the requirements of new technologies, including support for MongoDB.

mongodb

MongoDB is among the leading NoSQL databases in the market and has been developed for the needs of today’s information technology. MongoDB supports a data model with dynamic schemata and is especially suitable to store large amounts of data using GridFS. It contains automatic failure protection using an integrated replication. MongoDB also offers native, idiomatic drivers for nearly all programming languages and frameworks.

Find out more about MongoDB here: https://www.mongodb.com

In addition to support for MongoDB, tcVISION features connectivity to other output targets, such as Hadoop (see previous blog about Hadoop support), Adabas LUW, DB2 BLU, and EXASOL. Additionally, new input sources include z/OS VSAM Logstream (CICS and Coupling Facility / Shared VSAM), z/OS VSAM Batch Extension, z/OS DBMS to Logstream, CA IDMS v17, CA Datacom CDC, IMS Active Log, and SMF data.

Find out more about tcVISION — Enterprise ETL and Real-Time Data Replication Through Change Data Capture

tcVISION provides easy and fast data migration for mainframe application modernization projects and enables bi-directional data replication between mainframe, Linux, Unix and Windows platforms.

_0_tcVISION_Simple_Diagram

tcVISION acquires data in bulk or via change data capture methods, including in real time, from virtually any IBM mainframe data source (Software AG Adabas, IBM DB2, IBM VSAM, IBM IMS/DB, CA IDMS, CA Datacom, even sequential files), and transform and deliver to virtually any target. In addition, the same product can extract and replicate data from a variety of non-mainframe sources, including Adabas LUW, Oracle Database, Microsoft SQL Server, IBM DB2 LUW and DB2 BLU, IBM Informix and PostgreSQL.


__TSI_LOGO

Visit the Treehouse Software website for more information on tcVISION, or contact us to discuss your needs.

tcVISION TREETIP: Navigating The Repository Editor

When modeling and mapping a new metadata structure, tcVISION’s powerful Repository Editor is used to define and modify Input and Output Objects. The rich features within the Editor allow users to:

  • import new objects
  • copy or create new objects
  • import metadata for input and/or output objects
  • define target DBMSs
  • specify input and/or output objects for import
  • define DMBS-specific options
  • define target object names
  • replace/supersede existing object metadata

To assist new and even experienced tcVISION users, we’ve put together the following screen shots to give a quick overview of the Repository Editor’s functionality buttons / icons used for setting up modeling and mapping of sources and targets.

Here is an example of what the tcVISION Repository Editor looks like:

_0_tcVISION_RepositoryEditor01

Repository Editor icon definitions: Input objects

_0_tcVISION_RepositoryEditor02Input

Repository Editor icon definitions: Output objects

_0_tcVISION_RepositoryEditor02output

Repository editor right click menu options

_0_tcVISION_RepositoryEditor03OutputOptions

Repository editor extended output target options

_0_tcVISION_RepositoryEditor03RightClick


Enterprise ETL and Real-Time Data Replication Through Change Data Capture

tcVISION_Architecture

tcVISION provides real-time data replication through change data capture, and allows easy and fast data migration for mainframe application modernization projects. Enterprises looking for a product that enables bi-directional heterogeneous data replication between mainframe, Linux, Unix, and Windows platforms need look no further than to tcVISION from Treehouse Software.

To learn more about tcVISION, or to request a demonstration, contact Treehouse Software today.

Treehouse Software will be Exhibiting at SHARE and CA World

If you are attending SHARE in Pittsburgh in August, or CA World in Las Vegas in November, be sure to stop by the Treehouse Software booth and say hello!

We’ll be featuring our comprehensive and flexible portfolio of solutions for integration, replication, and migration of data between mainframe sources and any target, application or platform using ETL, CDC, SQL, XML and SOA technologies.

2014_SHARE

SHARE Technology Exchange Expo
Visit us at Booth #522 | August 3-8
David L. Lawrence Convention Center
Pittsburgh, PA


 

2014_CA_World

CA World ’14
November 9–12, 2014
Mandalay Bay Resort & Casino
Las Vegas, Nevada


Visitors to our exhibits will learn how Treehouse Software is currently providing several large organizations with ETL and real-time, bi-directional data replication using tcVISION. tcVISION provides easy and fast bi-directional data replication between mainframe, Linux, Unix, and Windows platforms.

tcVISION_Architecture


We will also showcase tcACCESS, which integrates mainframe data and applications with open systems and Windows.

tcACCESS_Diagram01

L10n in Heterogeneous Data Replication

by Wayne Lashley, Chief Business Development Officer for Treehouse Software

Most software vendors whose product markets extend beyond their own home country are familiar with the concepts of “i18n” and “L10n”, which are numeronyms for “internationalization” and “localization” respectively. i18n is the process of making a software product capable of adaptation to different languages and cultures, while L10n is the specific adaptation process for a given local market.

These terms take on special significance in the context of data replication software products—such as Treehouse’s DPSync, which provides real-time replication of mainframe ADABAS data to relational database (RDBMS) targets like DB2, Microsoft SQL Server and Oracle on various platforms. The very purpose of these products is to take data from a source and apply appropriate L10n to make it usable at the target, which is generally dissimilar in various aspects of the technical environment.

Perhaps the simplest form of L10n, having nothing to do with language or locale, is to transform database-specific field/column datatypes. Alphanumeric (A) fields in ADABAS are often mapped to CHAR or VARCHAR datatypes in an RDBMS, which are conceptually quite similar. Packed (P) fields may be expressed in an RDBMS as NUMBER, INTEGER, NUMERIC, DECIMAL, etc., depending on the vendor implementation and desired usages.

When it comes to Binary (B) format, things get tricky.  An array of bits in an ADABAS field can’t usually be mapped directly to a binary representation in an RDBMS column, due to the differences in the way data are represented between the platforms.

Decades ago, when I was earning my stripes as a novice mainframe programmer, the rules seemed simple: 8 bits made up a byte, and characters were expressed in single bytes encoded in EBCDIC.

(True story: During a university Assembler class many years ago, one of my classmates was muttering to himself, and the professor queried him about the subject of the “conversation”. The student replied “Just practicing my EBCDIC, sir!”)

Later on, I learned about that ASCII column of the “CODE TRANSLATION TABLE” in my indispensable System/370 Reference Summary GX20-1850-3, and I realized there was a whole world of computers beyond mainframes.

Image

But in fact things can be much more complex than simply EBCDIC and ASCII. L10n of data has to take into account the multitude of code pages and conventions that customers may use—and the customizations and exceptions to these.

Our European Technical Representative, Hans-Peter Will, has had to become somewhat of an expert in this over the past few years as he has worked with various customers in the Middle East on DPSync implementations.

Take the case of the way the Arabic language is handled in the context of applications at one site. Arabic is normally read right-to-left. But depending on system configuration, Arabic characters in a given field may be stored either left-to-right or right-to-left. Certain characters are represented in one byte, others in two. The cursive appearance of certain characters must be altered if they appear in the middle of a word rather than on an end. And in certain of this customer’s applications, the same screen display may show both Arabic and English. Even on screens where all of the words are in Arabic, and displayed right-to-left, there may be embedded numbers (e.g., telephone numbers) that need to be displayed left-to-right.

Now take all these complexities and factor in different database management systems (ADABAS vs. Oracle) running on different platforms (mainframe vs. Unix), each of which have their own configuration settings that affect the way characters are stored and displayed. Add to that the question of endianness (big-endian vs. little-endian) of the processing architecture.

The first time that Hans-Peter visited the customer in question, Treehouse software engineers had to figure out how to handle all these issues to ensure that ADABAS data would be replicated accurately and appropriately for use in Oracle-based applications. Fortunately, the combination of great product maturity (DPSync and its key underlying components tRelational/DPS having been battle-tested at countless sites over many years) and product extensibility (the ability to plug in complex custom transformations) enabled DPSync to be readily configured to accomplish the task at hand.

Having learned from that initial experience, Hans-Peter is now on familiar ground when assisting new Arabic-language sites implementing DPSync. Recently he was back in the Middle East visiting one of these new customers, and only hours after product installation he was able to confirm the accuracy of the SQL Server representation of data materialized (initially loaded via what is commonly called ETL, Extract-Transform-Load) from ADABAS using DPSync. The customer was also impressed with the speed of the process, both in terms of configuring the materialization (taking advantage of the tRelational schema auto-generation feature) and executing it (using an ADASAV backup as source, avoiding any workload on ADABAS). That customer is now in production with real-time ADABAS-to-SQL Server replication.

What’s your L10n challenge? Contact Treehouse and learn how DPSync and our other products are able to meet it.