This applies to any RMS-CDC Streams solution, including RMS-CDC for SSIS but also regular Streams (now accessible through Replicate)

When a Streams solution is being defined, an OpenVMS NODE list must be provided, which gets deployed into the Agent Adapter.
The agent uses that list to search for change log files for those nodes.

The RMSCDC Agent code, uses this list to generate the trailing 3 characters in the 'agent_context'.
That trailing part is an "N" followed by a 2 digit 0-based ordinal number for the node name where the last context was found.

If a stream needs to be resumed, this last bit of context allows the agent to jump to the correct log file for the change to start from.

When resuming by time, before the last recorded change, there could be a change record duplication issue IF the order has changed.

For example:
- stop solution
- deploy solution with re-ordered node list amongst other changes
- resume solution by time.

If a node retains the same position in the list, then the exact same agent context is generate and any duplicate record will silently be rejected.

But if the order changed, the agent_context looks different and no longer duplicates an already picked up change, resulting in a duplicate change recorded.
For many (UPDATE) operations this is benign, but for inserts it can cause duplicate records (if there is no primary key on the target)

Here is how that problem might look like in the the header in the staging area for a table.
In this case a node was number 5 at 14:23 (udt), but became number 8 by 19:56 (udt) and the same change now appears twice in the list.

This situation can best be recognized by looking at the change sequence number which is encoded in the first 12 characters of the agent_context
(base 16 number, with A..P representing 0..F)
That number is (supposed to be) unique.


Code:
CONTEXT_ID    AGENT_CONTEXT    OPERATION
20131203T195631.008570000000    AAABFPEDHPMG20131203T120135ACIFBHMCN08    BEFOREIMAGE
20131203T195631.008580000000    AAABFPEDHPMH20131203T120135ACIFBIIIN08    UPDATE
20131203T142311.000100000000    AAABFPEDHPMG20131203T120135ACIFBHMCN05    BEFOREIMAGE
20131203T142311.000110000000    AAABFPEDHPMH20131203T120135ACIFBIIIN05    UPDATE
So you've been warned!
Keep your nodes in order if at all possible.
Just add to the end, and remove only given the right, quiet, conditions.
You do want to remove when removed, because each node listed will cause file lookups at the source server.

Regards,
Hein