We did the following and received millions of ADAFCV, ADAF18, ADAF54 messages.
We ran a batch job on the source database (MF) to add a total of 16,575,293 records to 82 files. The job ended with CC 0.
Our target server had some network issues and the throughput slowed down to 75 records per second (expected 250 from other tests).
SYSAOS was locked for the Reptor database. We couldn’t see the Reptor statistics. ADAREP had the same problem. We don’t know why. Maybe Reptor was overwhelmed? On the target database, we still saw some added records, like 37 per second and later only 12 per second.
We cancelled with dump Reptor and recycled it.
Now, the Reptor repeated thousands of previously added records and printed out (9 millions of lines):
ADAF54 2010-04-24 00:08:32 Replication error: Adabas destination D191027
ADAF54 Source DBID 39 FNR 27, Target DBID 191 FNR 27
ADAF18 N2 cmd to DBID 191 FNR 27 RSP 113 subcode ISN 2717024
ADAFCV The record to be inserted already exists on the target DBID/file
ADAFCW The insert is part of a transaction with the resend flag set.
ADAFCY The record will be updated.
We had to recycle Reptor again but the message did show again.
Now, we deleted the entire SLOG and recycled again.
QUESTIONS:
Thousands of records were ‘successfully’ replicated. Why did Reptor try to repeat them
Can we suppress the info message? Otherwise, we will bring down the z/OS operating system (spool overflow).
Why was SYSAOS locked and eventually responded with 224 response code, 0 sub code?
ADAF54 2010-04-24 00:08:32 Replication error: Adabas destination D191027
ADAF54 Source DBID 39 FNR 27, Target DBID 191 FNR 27
ADAF18 N2 cmd to DBID 191 FNR 27 RSP 113 subcode ISN 2717024
ADAFCV The record to be inserted already exists on the target DBID/file
ADAFCW The insert is part of a transaction with the resend flag set.
ADAFCY The record will be updated.
… and the update is a delete (E1) and an add (N2) . Hmmm… could be easier with an A1 ?
I can not say what went wrong in your scenario, but I think this is a support issue, which you should follow up with support of Software AG.
Your questions:
Thousands of records were ‘successfully’ replicated. Why did Reptor try to repeat them
The reptor should only repeat “successfully” replicated transaction, for which he did not receive a positive confirmation about it.
In case of your scenario this would be a response zero to an ET command.
This should happen only to the last transaction sent to a
destination before failure. What went wrong in your case I do not know but the dump might tell. It seems that the reptor did not do clean ups after response zeores were received from the target.
For example if the transaction went to SLOG before, because the target or Net-work could not keep up with the load, could b
Can we suppress the info message? Otherwise, we will bring down the z/OS operating system (spool overflow).
This could be a reasonable change enhancement request. But please note that this happened because of a scenario, where something went seriously wrong. As explained above there should not be so many messages in the first place.
Why was SYSAOS locked and eventually responded with 224 response code, 0 sub code?
I don’t know. This should be followed up with SAG support.
“… and the update is a delete (E1) and an add (N2) . Hmmm… could be easier with an A1 ?”
No, this would not be the same.
The N2, which got a Resp 113 is a complete replacement of the record. An A1 only replaces the fields mentioned in the format buffer.
Therefor we do an delete (E1) followed by an insert (N2).