Replication Center SQL Replication Subscription sets

[Odd Bjørn Andersen]

I have a problem when using Replication Center on version 8.2 (fixpack 9)
when I try to manage my SQL Replication environment. When I add existing
Apply Control Servers I am not able to see existing subscription sets on
that Apply Server. The apply program works fine however and data are
replicated from the source without problems. My 'problem' is that I cannot
see old subscription sets from within the Replication Center. If I define a
new subscription set I see this new subscription set in the Replication
Center. I have tried to compare the contents in the IBMSNAP_SUBS_SE T table,
but am not able to see any difference in the definition between the old and
the new subscription sets.

Has anybody any idea about what to do to be able to see the subscriotion set
in the Replication Center ?
--
Regards

Odd Bjørn Andersen
ErgoGroup
IKT-driftstjenester
N-0402 Oslo Norway

[UDBDBA]

Try running db2updv8 utilitiy on the server side. With fixpaks,
sometimes the internal procs/functions are changed and that might cause
this problem.

HTH

Vijay

[Odd Bjørn Andersen]

I tried that now, but it dit not resolve the problem.

Regards
Odd

"UDBDBA" <vi***********@ gmail.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Try running db2updv8 utilitiy on the server side. With fixpaks,
sometimes the internal procs/functions are changed and that might cause
this problem.

HTH

Vijay

[dotyet]

do you see the old entries in the replication tables or not even there?

....
dotyet

Odd Bjørn Andersen wrote:

I tried that now, but it dit not resolve the problem.

Regards
Odd

"UDBDBA" <vi***********@ gmail.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Try running db2updv8 utilitiy on the server side. With fixpaks,
sometimes the internal procs/functions are changed and that might cause
this problem.

HTH

Vijay

[Odd Bjørn Andersen]

Yes, I see the old enitres in the replication tables. I try to compare the
old entries with entries from new definitions we have made, and I cannot see
any differences between the old and the new entries. I have looked on both
subs_set, subs_membr and subs_cols on the target side and pruncntl and
prune_set on the source side.

I wonder where Replication Center 'looks' to get the information about
subscription sets. Perhaps I have been checking the wrong places .......

Regards
Odd

"dotyet" <do****@yahoo.c om> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.com.. .
do you see the old entries in the replication tables or not even there?

....
dotyet

Odd Bjørn Andersen wrote:

I tried that now, but it dit not resolve the problem.

Regards
Odd

"UDBDBA" <vi***********@ gmail.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Try running db2updv8 utilitiy on the server side. With fixpaks,
sometimes the internal procs/functions are changed and that might cause
this problem.

HTH

Vijay

[Andy K]

Hi ,

i've setup two databases for replication on DB2 v7.x on a linux RH ES2
on the same instance and of course the same server (maybe the problem
lies here ...).

I've done the capture and the applying like this :

Source Side :
bind @applyur.lst isolation ur blocking all;

bind @applycs.lst isolation cs blocking all;

Target Side :
bind @applyur.lst isolation ur blocking all;

bind @applycs.lst isolation cs blocking all;

everything runs fine .

at the end , i ran this command line :

../asnccp MONG cold prune

but I got this message :

2005-06-16-15:12:39 ASN0000S: INTERNAL ERROR OCCURRED FOR MESSAGE
NUMBER ASN0048E. ITS SUBSTITUTION FIELDS ARE Permission non accordée.
THE RETURN CODE IS 0.

SQLCA SQL1024N A database connection does not exist. SQLSTATE=08003
Capture will stop.

FYI , MONG is the source database

I also read something about STRDPRCAP on AS/400 but I'm not sure if the
command exists on Linux .

Have you encounter something like this ?

If yes , any help will be welcomed.

TIA ,
Andy the beginner in DB2

UDBDBA a écrit :

Try running db2updv8 utilitiy on the server side. With fixpaks,
sometimes the internal procs/functions are changed and that might cause
this problem.

HTH

Vijay