!!! Overview
[{$pagename}] in [eDirectory] is a synchronizing multi-valued [attributeTypes], where each attribute value represents the state in time that the specified [eDirectory] agent has received changes up to.

!! Background Information
[Novell Directory Services] ([eDirectory]) was initially release in [1993|Year 1993]. For instance, in [NetWare] 3.x, there were the enhancements to the [SYSCON] utility called NETCON, which used a form of forced synchronization of user and group objects between servers. In order to overcome the limitations of a patched solution such as NETCON, [NDS] was born to offer a complete [Directory Service] solution, designed from the ground up to fulfill that mission.

Initially, [NDS] was designed with a method of updating information on all servers in the [NDS Tree-name]. This was called [synchronization]. Recently [synchronization] has been improved to handle increased efficiency that were demanded by the current workforce. One of the updates to synchronization is called [Transitive Synchronization]. In order to understand [Transitive Synchronization], it is important to understand the [{$pagename}].

!! The [{$pagename}]
In order to maintain the [EDirectory Synchronization] of [replica]s, [NDS] needs to keep track of the changes that have been made. This is done by placing a [timestamp] on a specific attribute of the [Partition Root Entry]. This timestamp indicates when the last update was made. By looking at the timestamp, NDS can evaluate whether the most current updates have been received by that [replica].

[EDirectory Versions] before [NetWare] 5, an attribute called "[Synchronized Up To]" determined when the latest changes were made. The value of [Synchronized Up To] attribute is unique for each replica and is not synchronized to the other servers in the replica ring ([NDS Tree-name]).

!! [{$pagename}] [NetWare] 5 and greater
[EDirectory Versions] that shipped with [NetWare] 5 and greater, use [{$pagename}] to track changes to a [partition]. The [{$pagename}] holds [Timestamps] for all the [replicas] in the [replica List] from each [NcpServer]'s perspective. 

Each [NcpServer] in the [replica List] has a copy of its own [{$pagename}] and every [NcpServer] also has copies of the [{$pagename}] of the other [NcpServers] in the [NDS Tree-name].

On each single [NcpServer], these [Timestamps] are referred to as the [{$pagename}]. The [{$pagename}] tracks any changes that occur to the immediate [partition].

[{$pagename}] is a [MULTI-VALUE] attribute, the [{$pagename}] is added to the [Partition Root Entry] for each [NDS Partition] in [NDS] ([eDirectory]). By synchronizing the [{$pagename}] values, all of the replicas can synchronize without having every [replica] communicate with every other [replica].

!! [{$pagename}] Values
[{$applicationname}]  has not been able to find any detailed documentation on content of [{$pagename}] and this is based on years of experience, research and theory and a few hints form here and there. Of course [{$applicationname}]  is most interested in how to read the [{$pagename}] from [LDAP]

[Array] of entries which each entry contains:
* [NcpServer] [DN]
** [Timestamp].count - Essentially a the number of [Replicas] on this [NcpServer]
** [Array] of Replicas with length [Timestamp].count
*** [Timestamp] ([Unix Epoch])
*** [Replica number]
*** [Event number] - an incrementing number of [Events] within [Timestamp]

!! [{$pagename}] and the Restore Verification Process
[NcpServers] that hold replicas of the same [partition] communicate with each other to keep the [replicas] synchronized. Each time a server communicates with another server in the [Replica List], it keeps a record of the [{$pagename}] the other [NcpServer] had when they communicated. These [{$pagename}] allow the servers in a [Replica List] to know what information needs to be sent to each [replica] in the ring to keep all the replicas synchronized. When a server goes down, it stops communicating, and the other servers do not send updates or change the [{$pagename}] they have recorded for that [NcpServer] until the server starts communicating again.

When you restore [eDirectory] on a [NcpServer], the restore verification process compares the [{$pagename}] of the server being restored to the other [NcpServers] in the [Replica List]. This is done to make sure that the [replicas] being restored are in the same [state] that the other [NcpServer] expect.

If the [{$pagename}] on the remote server is ahead of the local [{$pagename}], then [data] is missing from the restore, and the verification fails. For example, data might be missing because you __did not__ turn on continuous [Roll-Forward Logs] before the last full or [Incremental Backup], you did not include the roll-forward logs in the restore, or the set of [Roll-Forward Logs] you provided for the restore was not complete.

By default the restored [eDirectory] [database] is __NOT__ opened if it is inconsistent with the other [replicas].

!! [{$pagename}] Example
[{$pagename}] is a time stamp for a [replica]. 

[{$pagename}] is made up of a representation of the number of seconds since a common specific point in history ([UNIX epoch|Time And Epochs#section-Time+And+Epochs-UNIX]), the replica number, and the current event number. 
Here's an example:
{{{
s3D35F377 r02 e002
}}}!! [LDAP] [AttributeTypes] Definition
The [{$pagename}] [AttributeTypes] is defined as:
* [OID] of [2.16.840.1.113719.1.1.4.1.180] 
* [NAME|Attribute-Name]: [{$pagename}]
* DESC: 
* [EQUALITY]: []
* [ORDERING]: []
* SYNTAX:  [1.3.6.1.4.1.1466.115.121.1.40] [Octet String]
* [UPPERBOUND]: 64512
* USAGE [DirectoryOperation] 
* [Extended Flags]: 
** [X-NDS_NAME]: Transitive Vector
** [X-NDS_PUBLIC_READ]: 1
** [X-NDS_SCHED_SYNC_NEVER]: 1
** [X-NDS_NONREMOVABLE]: 1
** [X-NDS_READ_FILTERED]: 1
* Used as [MUST] in:
** 
* Used [MAY] in:
** [Partition]!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]