I have just published a blog entry on the z/OS Platform Evaluation Test (zPET) team's blog regarding the use of IBMQREP_IGNTRAN and insert_bidi_signal=n. For anyone interested, you can find it here: zPET Blog Entry - IGNTRAN
IBM Data Replication Answers
MatthewCousens 0600013BR0 124 Visits
N7V6_mohan_babu 270004N7V6 194 Visits
I was having issue when trying to connect to my database (DB2 v10.1.0.3", "s130918", "IP23509", and Fix Pack "3") having authentication as DATA_ENCRYPT using IIDR replication dashboard.
Has anyone come across this issue , is there any work around for this.
QUTY_Dylan_Murphy 060001QUTY 435 Visits
IBM has a comprehensive new Redbook for Q Replication that should appeal to both new and long-time users. It builds on a Redbook published several years ago, but is not a simple dusting off of an old book. Instead, the writers took the time to pick the brains of experts at IBM's Silicon Valley Lab and add information that's never been published. They've also worked hard to make sure the entire Redbook is easily understood by new users. One example I like is this new graphic that shows the 10 factors that affect end-to-end data replication latency:
People always want to understand this stuff, but it's never been shown so clearly, especially the details around MQ. To make sure you follow the graphic, the Redbook discusses each numbered point individually. Another area I like is the chapter called "Managing Q Replication in a DB2 z/OS Environment". Lots of good stuff there. I believe it will be a huge help to mainframe shops that have Q Replication in production.
Understanding and Using Q Replication for High Availability Solutions on the IBM z/OS Platform
BE28_Larryk_Karl 270005BE28 161 Visits
I've recently posted a problem with a dpropr update anywhere configuration not replicating from the source to the master. That is being addressed. The purpose of this post is how to replicate db2xml columns. (DB2XML has been replaced with purescale xml)
My questions are centered around purescalexml. Given that we need to convert from db2xml to purescale xml:
1) is there a reference guide on how to convert db2xml to purescale xml?
2) purescale xml is defined to a db2 table as data type xml
-- is data type xml supported by dpropr (sql replication, qrep, or HADR). The replication guide. states db2 xml not supported, but is this db2xml or purescale xml data type?
replication manual data type restrictions
Data type restrictions
BE28_Larryk_Karl 270005BE28 191 Visits
Recently a dpropr (sql replication) v10.1 was setup in an update anywhere configuration. A refresh was done from the master databases (whos_on_first='S')
I performed the following tests that show replication from the master to the replica works, but replication from the replication does not work. Because the replica capture read the change and inserted the record to the associated CD table, I believe the issue is with the apply whos_on_first='F'
performed table refresh to verify in update anywhere refreshed from master tables to replica tables. This was succesful.
changed a table row on master table (whos_on_first='S'). Data replicated to replica table.
on replica table updated the same row changing the value back to its original master table value.
-- Capture read the change to the cd table
-- Applytrail shows no data for whos_on_first='F replicating to the master table, though it shows successfull replication cycles.
How do I resolve and get the dpropr apply whos_on_first='F' to replicate data back to the master table?
LarryD'Agostino 2000004561 229 Visits
My shop has IMS DPROP for propagation of IMS data to DB2 z/OS. As it is no longer being marketed and EOS unclear, I am looking at the recommended IBM replacement: Infosphere; specifically Infosphere IMS replication for z/OS and Infosphere Data Replication for DB2 z/OS. Is there any information on the relative performance of Ithese nfosphere Data Replication products versus IMS DPROP ?
We have various QREPLICATION Peer to Peer setups, with some tables over 20 gb in size. There are times we have identified were the two sets of tables need to be synchronized. What we have been doing is running ASNTDIFF / ASNTREP on one set of the tables, and then repeating the process on the other set of tables.
Because of the size of the tables we have found that ASNTDIFF / ASNTREP is an inefficient process to get the qreplication peer to peer tables synchronized.
Does anyone have any alternative, performance oriented solution to ASNTDIFF / ASNTREP?
With a mere 4 weeks until IBM's 2013 Information on Demand, the data replication team thought it might be helpful to have a complete listing of all data replication sessions at IOD. From client presentations and our product roadmap to sneak peeks at new IBM Data Replication functionality, our sessions run the gamut!
Simply take a gander at the sessions below then go to the IOD agenda builder, click on Create Sign In, and then enter your confirmation number and the email address that you used to register for the conference. Create your agenda today!
Q Replication Tips for Beginners
If you are new to Q Replication, you may be interested in some tips on making sure your first configuration is successful. This blog is for you. It is a list of tips and includes links to help you successfully configure, deploy and monitor a typical Q Replication scenario.
This blog assumes you've read the post titled A Fast Way to Get Started with Q Replication for DB2 Active-Active Database. For example, this post assumes that you are running replication between two systems as shown in the picture below. However the tips here apply to any Q Replication configuration:
The tips fall into four basic categories:
Expanding our Picture...
In system 1 and system 2, the DB2 instances, Q Capture/Q Apply pairs and MQ managers communicate with each other as shown in the diagram below:
The DB2 database names, MQ manager names and MQ port numbers in the diagram above are also referenced in the tips sections below (Tips #2 and #3). Q Replication tutorial can be found here
Tip #1: Use the InfoSphere Data Replication Dashboard!
Follow the InfoSphere Data Replication Dashboard Install Procedures to install the InfoSphere Data Replication Dashboard on one of your systems. Installation is quite fast and simple, and footprint (including embedded web server) is small.
Just open a web browser window pointing to the URL defined as part of the installation steps and the Q Replication Dashboard will give you:
Tip #2: Validate your MQ Setup!
The post named A Fast Way to Get Started with WebSphere MQ shows you how to use the ASNCLP CREATE MQ SCRIPT command to create MQ definitions for your active-active configuration. The command returns two MQ scripts, one script for system 1 and one script for system 2. Each script creates an MQ queue manager and its related MQ definitions. This section includes some tips on how to use the create mq script command. It also lists a few tools you will want to use to validate your MQ setup, should you encounter some problems.
Guidelines on how to use the ASNCLP 'CREATE MQ SCRIPT' command:
In some cases, you may be asked to reuse an existing MQ environment: an MQ queue manager and possibly MQ administration and restart queues for a Q Capture server. If that is the case, you won't be able to use the ASNCLP script commands as provided and will need to make some updates. This may be error-prone so this section lists various tools and tips to validate and correct your MQ setup for your active-active configuration.
Tools you will want to use to validate (and correct) an MQ configuration for Q Replication:
- is described in the post A Fast Way to Get Started with Q Replication for DB2 Active-Active Database
- catches setup error that occurs with the administration queue; for example, the
DB2 ASN.IBMQREP_RECVQUEUES.ADMINQ column value on system 1 (or system 2)
should be the same as the local MQ administration queue name defined on
system 2 (or system 1); it should never match the local administration queue
system 1 (or system 2). The ASNCLP validate function alerts you if that is the case
- validates that the two MQ managers defined for a Q Replication configuration can talk to each other by sending a test message between the two MQ queue managers
- note that the restriction stating that the Q Capture and Q Apply programs have to be stopped before doing the test has been lifted
- for more information on how to use the Replication Center to verify your MQ setup for Q Replication, watch the short video (seven minutes) that is available on ChannelDB2. If you use DB2 V10 and above, the Replication Center is available as a stand-alone DB2 center.
Tip #3: Validate your DB2 Setup!
Tip #4: Know How to Reset your Q Replication Environment!
If tables in the SITE2 database become out of synch with tables in the SITE1 database, you can reset your Q Replication environment by first stopping and then starting the corresponding Q subscriptions with the necessary load methods to populate the target tables:
If you need to reset your Q Replication environment for other reasons (some subscriptions in inconsistent state, messages were sent to a dead-letter queue or hardware failure could be some examples), use the Data Replication Dashboard's Recovery Advisor tab. It helps you troubleshoot and analyze your environment including four recovery scenarios. The remainder of this section highlights its key features.
Note that the information available in the Recovery Advisor is also available in the Troubleshooting section of the Q Replication Information Center.
The following features are available for you to reset your Q Replication environment:
This post is the answer to one of the FAQs found in
If you download IBM products from Passport Advantage (PPA), you may now have access to IIDR but don't know why. The reason may be that all of the following conditions are true for your shop:
If you don't understand, keep reading... In December of 2012, IBM announced that it would no longer market the following three data replication products after March 11, 2013:
The announcement also said that IBM InfoSphere Data Replication (IIDR) would be the replacement product. IIDR contains all replication technologies from all three of the older products. However, the announcement did not say how you get IIDR if you already own one or more of the older products. Well, it turns out that IBM automatically converted your older product(s) on UNIX, Windows, or System i to IIDR on March 12, 2013 as long as you were current on S&S. There was no announcement. The only way you'll see this is if you look in your PPA account. It should now list IIDR.
If you are unfamiliar with IBM's changes to its data replication portfolio, see either of the following posts for more information:
Feel free to post comments if you have questions.