Hello

I tried to do an initial full refresh but I failed - nothing happens (no error at all. Status of run apply = 0). Apply works without errors. Details of my environment:

I have the following replication scenario: DB2 UDB apply is running on a Solaris machine (DB2 Version 8, fixpack 9a), capture on a z/OS machine (host).

On the z/OS machine (capture side), the column values of the column "DISABLE_REFRESH" for all source tables are set to 0 therefore allowing a full refresh.

I successfully updated the ASN.IBMSNAP_SUBSET table on the apply side
as followed (as suggested by the Replication Center while performing an
automatic full refresh):

CONNECT TO TESTDB;
UPDATE ASN.IBMSNAP_SUBS_SET SET ACTIVATE=0 WHERE SET_NAME='S_TEST' AND
APPLY_QUAL='A_TEST' AND WHOS_ON_FIRST='S';

UPDATE ASN.IBMSNAP_SUBS_SET SET LASTSUCCESS=NULL, SYNCHPOINT=NULL,
SYNCHTIME=NULL WHERE APPLY_QUAL='A_TEST' AND SET_NAME='S_TEST' AND WHOS_ON_FIRST='S';

UPDATE ASN.IBMSNAP_SUBS_SET SET ACTIVATE=1 WHERE SET_NAME='S_TEST' AND
APPLY_QUAL='A_TEST' AND WHOS_ON_FIRST='S';
COMMIT ;

Then - after checking that all above COLUMNS are set to the above
values - I successfully started the apply but the full refresh didn't
take place. Logfile:

2006-01-24-16.15.30.394515 <CPCIMPC(08/07)> ASN1045I APPLY "A_TEST" :
"Initial". The Apply program was started using database "TESTDB".

2006-01-24-16.15.31.038834 <CPREST(01/00)> ASN1044I APPLY "A_TEST" :
"WorkerThread". The Apply program will become inactive for "0" minutes
and "50" seconds.
...

2006-01-24-16.34.21.725226 <CPREST(01/00)> ASN1044I APPLY "A_TEST" :
"WorkerThread". The Apply program will become inactive for "2" minutes
and "0" seconds.

There were no errors in the apply logfile and checking the
ASN.IBMSNAP_APPLYTRAIL shows that no rows were inserted or deleted in
the target tables (STATUS = 0, FULL_REFRESH = N):

I checked the host side (where capture is running): the tables are not
empty and my apply-process is activated.

Does anybody have an idea why the initial full refresh doesn't take
place? Are on the Capture side some other fields necessary exept DISABLE_REFRESH = 0 in order to process a full refresh?

Thank you very much for your help

With kind regards

John

Don't remember exactly ... ASN.IBMSNAP_PRUNCNTL & ASN.IBMSNAP_REGISTER tables are a few tables to consider .

Cheers
Sathyaram

ibmsnap register keeps the parameter as indicated disable full refresh
if set to 0 : full refresh can occur
any test done with applytrace active : to see more detail
I think you can still specify asnapply ..... trcflow > out.file
also check capture trace table to see if any error over there
but full refresh is done by apply
have you tried to force manual/automated refresh through replication center and see the statements they generate to do this
for initial full refresh no updates are needed to any table, as apply is started this will detect new subscription and trigger the full refresh..
hope this will help

Re: full refresh

Hello Przytula

Thank you very much for your answer.

I already tried your suggestion with the trcflow option (still works). No errors or hints in the output.

And yes, I tried the automated refresh through replication center, i.e. I updated the LASTSUCCESS, SYNCHPOINT and SYNCHTIME columns with NULL. Afterwards, apply performed with STATUS=0 but no full refresh was performed (in APPLYTRAIL table, the column was "full_refresh = N", telling me that no full_refresh was performed).

I also activated the asntrc tool for the apply side but didn't find any hints. The problem is that the apply runs without generating an error but it doesn't perform a full refresh. Everything seems alright. And without an error it's quite difficult to find out why the full refresh doesn't take place ;-)

Any further suggestions?

Thank you

out of ideas.
I presume, that modifications do not come through, as full refresh has not been executed. Do you have a support contract - maybe a pmr could help.
any other subscriptions ? if none, you could try to start the capture with cold, this would also force a full refresh of all sets.. have you checked also the captrace table for any messages..

Thank you very much for your help. The errors were on the capture side: not all correct values in the capture control tables were inserted/updated (our customer is responsible for the capture side). Now the full refresh worked perfectly.

With kind regards

John