We are looking for a strategy to deploy several Rdz UT servers so we can avoid performance problems related to the number of concurrent users. We would like to use Rdz UT servers as a pool resource so each user can work with all Unit Test servers.

One problem we are facing is that due to there is one DB2 database for each Rdz UT server, each developer has to work always agains the same Rdz UT server. If a developer changes data on a particular server, he has to connect always to the same server if he wants to continue working with the same data set.

We are thinking on using “SQL Replication” or “Q Replication” but we are not sure if it is possible on Rdz UT and also if it means an extra charge.

Is someone facing this problem using a different approach?
Does anyone knows if it is possible to use SQL/Q Replication and if it means and extra charge?

Thanks in advance.

Not sure how Q replication would help in this situation. Depending on which product you are thinking of to do the replication, an additional charge might be involved. I also worry about how close you are trying to get to a production-like environment. As you know, the RDz-UT license specifically prohibits its use for anything that looks like production or psuedo-production. Have you considering accessing the data from UT on a real DB2 server via DRDA? This is fully supported by UT, and could potentially address the currency issues. If you have a zIIP on your z box, you could get substantial DB2 savings by accessing DB2 data in place from UT using DRDA. All DB2 remote access is zIIP eligible.

RDzJohn

Thank you for your answer John.
We didn’t consider the possibility to use DRDA but, as you explain, it seems to be the best option.
We are not trying to reproduce the production environment. Our problem is that we have about 200 mainframe developers so if we want to use Rdz UT instead our present development environment, we have to make sure that it is not going to be a nightmare for them. We don’t want them to face new problems derived on having multiple development databases. In fact, as you may guess, RdZ UT does not offer enough capacity to replace our production environment.
Thank you very much because using DRDA seems to be the solution to our problem.