Unless otherwise indicated, each of the scenarios in this section is a tried and tested implementation based on actual customer installations. (3)
One of the common uses of IBM Replication is to replicate data changes from an operational system to a decision support system. Generally it is not advisable to run decision support and online systems alongside each other. A process is therefore required to maintain the decision support system in line with the operational system.
IBM Replication solved this problem for one financial institution that had to replicate updates from its customer information database held on DB2 for MVS to a decision support system that was also to be on DB2 for MVS. The main requirements were that the operational system not require any code modifications and the performance of the operational system not be impacted in any way.
IBM Replication was implemented to capture updates from the key operational tables and, on an hourly basis, replicate them to consistent change data (CCD) tables in the decision support system (DSS) DB2 subsystem. CCD tables were used because history information was required in the DSS, but none was maintained in the operational system. The IBM Replication tasks were given an MVS dispatching priority such that no CPU resource was ever taken away from the operational system. If there was a shortfall in capacity during peak periods, the Capture program task simply lagged behind.
The decision support system could be implemented just as easily on any of the supported target platforms and could still be ported to other platforms at some time in the future if required.
A large European retail chain has almost 500 stores around the country, each of which gathers purchase details through an electronic point of sale (EPOS) system. The data is transferred nightly to a central DB2 for MVS site using a preexisting file transfer process from the EPOS terminals. The company wants to leverage the value of the data by enhancing it at the central site and then distributing it to each of the branches and to some regional offices.
IBM Replication solved the problem by providing a weekly, controlled distribution of multilevel summarized results. Apply for AIX is used to summarize the details from the MVS site before transporting them and applying them to the local DB2 for AIX databases. Each store is able to see the local trends and their performance against other outlets in the region. Regional managers are able to more effectively plan their marketing and distribution strategies by using the information to help set objectives for the individual stores.
A small bank rolled out several new OS/2-based client/server applications to its 85 branches. A major source of data for the new applications is the customer and financial reference data, which is derived and held in two operational systems, one on DB2 for MVS and the other on DB2 for AIX. It was not possible to directly access the host site for all data requirements, so a data replication solution that uses IBM Replication was devised.
Changes arising from the two operational systems throughout the day are captured and staged on the AIX platform. Several CCD tables are built, with Apply for AIX taking feeds from both DB2 for MVS and the local DB2 for AIX system. Overnight, the changes are Replicated to the OS/2 applications in the branches, ready for use the next morning.
This approach helps to minimize the network traffic by maintaining a local copy of the database in each branch. Furthermore, IBM Replication replicatesonly the changed customer and financial data and ensures that only the most recent update for each key is replicated, thus reducing network requirements.
A large financial institution wanted to improve the flow of information from two legacy operational systems to its OS/2-based branch organization. The intent was to provide more accurate and timely data to help loan application research and to detect credit card fraud. The data to drive the loan application work was in DB2 for MVS, and the credit card details were captured in an older IMS-based system. Previous attempts to copy the legacy data had been an unworkable mixture of ad hoc reports and file transfer techniques.
Today, using IBM Replication, the branch analysts enjoy a much improved service, with daily feeds from the IMS system and twice weekly downloads of the loan history details. The DB2 for MVS-based data is captured daily but staged in a CCD table for the two weekly replication jobs. Only data that has changed is replicated, and the changes are replicated to provide a historical perspective. The credit card information is captured from IMS with DataPropagator NonRelational. The resulting staging tables are then replicated to the branches.
An international bank has a very sensitive online environment. The online system is used 23 hours 45 minutes a day. Every day the bank must stop the system to quiesce it for a batch application. The batch application requires exactly one day's worth of data. This data is needed for a day account. During the 15 minutes when the system is down, the bank extracts the tables required. When the bank finishes the extraction, the online system is made available for the next financial day.
To meet its goal of using the online system 24 hours a day, but not lose its application quiesce point, the bank decided to use IBM Replication. Data changes made during the online day were captured and then replicated to CCD staging tables. The batch application was modified to take input from CCD tables rather than extract files. The quiesce point can be identified from the data captured.
The source server and copy server are the same DB2 subsystem, so no distributed access is required except for the Control Center.
The archiving of aged or redundant DB2 data has long been a challenge for many large organizations. With IBM Replication, aged or redundant data can be safely deleted from the main tables without worrying about the archive database. The tables that require archiving are defined as replication sources. In doing this, whenever data is deleted, IBM Replication captures the deleted data and can "resurrect" the deleted row in a new target CCD table. The CCD table becomes the archive database.
IBM Replication can be used to track changes to relational tables for auditing purposes, to determine which users made particular changes to the data.
One customer installation, for example, generated audit data by writing audit information to the IMS log, which was not a problem while all database access was through IMS. However, new applications were developed that accessed DB2 through DRDA, bypassing IMS completely. In this instance, IBM Replication was implemented to capture the updates. CCD tables were used, requesting both before and after image columns. The IBMSNAP_AUTHTKN column was replicated from the unit-of-work (UOW) control table to identify who performed the update.
Because of increasing competition from telephone-based direct insurance providers, an established insurance company wants to be more focused and aggressive in its sales campaigns. It wants to equip its sales representatives and agents, who rarely visit the company's office, with a set of offers to attract both new and existing customers--special introductory offers, personalized packages, special "today-only" offers, and tailored cross-selling offers.
The sales force is supplied with laptop computers running OS/2 and DB2 for OS/2. As a sales campaign is launched, custom programming helps to target customers, and IBM Replication is used to download the targeted customer profiles and history, as well as the latest product offers. IBM Replication also solves the problem of keeping the information up to date with regular dial-in downloads. Of course, only new and changed data rows are copied across the network.
See Mobile Replication Requirements for more planning information.
Wanting to improve its check-in and check-out process to better serve its customers, a large hotel chain has equipped each of its cleaning carts with a mobile computer. Using wireless communications, every mobile computer is connected to the front desk. The application, database, and replication software must be installed before the database administrator distributes the cleaning cart computers. The administrator can create or change the replication definitions at any time, before or after the cleaning cart computers are distributed.
Each mobile computer is running DataPropagator for MS Jet and Windows 95. Hotel guests no longer need to wait until 3:00 PM to check in. Now room availability information is reported immediately after the room is cleaned. Even if a room attendant forgets to send the updated room status, DataPropagator for MS Jet will initiate regular dial-in downloads to synchronize room availability information at the front desk. The front desk can also estimate the time that a room will be cleaned. If a guest arrives early, the front desk can locate the room attendant closest to a room and send a status change to have the room cleaned immediately.
See Chapter 17. Mobile Replication Using IBM DB2 DataPropagator for Microsoft Jet for more planning information.
(3) In many cases some of the details have been changed to conceal the real identity of the customer. Sometimes two customer scenarios have been combined.