ControlValue ::= SEQUENCE {
   changeTypes	INTEGER,
   changesOnly	BOOLEAN,
   returnECs	BOOLEAN
}

EntryChangeNotification ::= SEQUENCE {
   changeType ENUMERATED {
           add (1),
           delete (2),
           modify (4),
           moddn (8) },
   previousDN LDAPDN OPTIONAL,
   changeNumber INTEGER OPTIONAL
}

• changeTypes - A bit field that specifies one or more types of changes the client is interested in: 0x01 for add changes, 0x02 for delete changes, 0x04 for modify changes, and 0x08 for modify DN changes.
• changesOnly - A flag that, if TRUE, only changed entries that match the search are returned. If set to FALSE, existing entries matching the search are returned, in addition to changed entries that match the search.
• returnECs - A flag that, if TRUE, an entryChangeNotification control is included when returning a changed entry that matches the search. If set to FALSE, the control is not included.
• changeType - Indicates the type of change made to the entry.
• previousDN - For a moddn changeType, the DN of the entry before it was renamed.
• changeNumber - The changeNumber of the change log entry, if any, that was created for this change.

A persistent search consists of two phases. The first phase is optional (it is done if changesOnly is FALSE), and consists of searching the directory for entries matching the search specification. The second phase consists of executing the search specification against any modifications that occur in the directory and, if found matching, then sending the search results to the waiting client.

Persistent search is supported in the TDBM, CDBM, LDBM, and GDBM backends. In addition, the schema entry (cn=schema) and the rootDSE (zero-length DN) support persistent searches. The persistentSearch configuration option can be used in the backend section of the configuration file to enable or disable persistent search for that backend. See Customizing the LDAP server configuration for more information about the persistentSearch configuration option.

1. An error is returned if an error occurs during processing of the persistent search request. Section 4.b of the specification indicates that SearchResultsDone message is not returned if a persistent search is requested. This is not recognized in the case of an error.
2. If more than one PersistentSearchControl is received per search request, LDAP_PROTOCOL_ERROR is returned.
3. If the requesting client is not bound as adminDN, LDAP_UNWILLING_TO_PERFORM is returned.
4. If persistent search is requested and the dereference option was set to something other than LDAP_DEREF_NEVER or LDAP_DEREF_FINDING, LDAP_PROTOCOL_ERROR is returned. If LDAP_DEREF_FINDING is specified, alias dereferencing is performed when the persistent search is issued to determine the real base entry. The dereferenced base entry is then used to determine if modified entries are within the scope of the persistent search request.
5. If a persistent search request is specified for a suffix that does not exist in the LDAP server configuration file, LDAP_NO_SUCH_OBJECT is returned.
6. If a persistent search request is specified for a suffix that is configured but for a search base that does not exist, no search results are returned until the object is added.
7. The search filter and scope are matched before a delete is done, all other operations are matched afterward. No search results are returned for entries moved out of the search filter or scope because of modification or rename.
8. For a persistent search of the root DSE, the search scope must be LDAP_SCOPE_SUBTREE. Backends that do not support persistent search or do not have persistent search enabled is skipped if a null-based subtree search is used and the persistent search control is marked as critical, otherwise a typical search is performed for those backends.
9. If a PersistentSearch control is included in a search request for a TDBM, CDBM, LDBM, or GDBM backend that has not enabled persistent search, the search request is rejected with LDAP_UNAVAILABLE_CRITICAL_EXTENTION (0x35) if the control is critical. If the control is not critical, a 'typical' search is performed (even if changesOnly is TRUE).
10. Change log entries trimmed by the LDAP server because of the changeLogMaxAge or changeLogMaxEntries configuration options are not returned to a persistent search of the change log directory.
11. If the manageDsaIT control is not specified with the PersistentSearch control and phase one of the search finds a referral, the referral is returned to the client. If the base of the search is equal to or below a referral, the referral is returned and the persistent search second phase does not occur. During the second phase of persistent search, referral entries are always processed such as typical entries, even if the manageDsaIT control is not specified on the persistent search.
12. Idle connection timeout also affects persistent search connections. See the description of the idleConnectionTimeout configuration option in Customizing the LDAP server configuration for more information.
13. sizeLimit and timeLimit parameters and configuration options and group search limits are respected only during the first phase of persistent search, when existing entries are searched. An error is returned if either limit is exceeded and the persistent search ends. During the second phase, when changed entries are searched, sizeLimit, timeLimit, and groups search limits are ignored.
14. Only the entry specified in a modify DN request (the target of the rename operation) can be returned during the second phase of the persistent search. Subentries or entries modified as part of the realignment process are not returned.
15. In a sysplex environment, only one persistent search request must be made to one of the LDAP servers in the sysplex. The sysplex support results in all the LDAP servers participating in the persistent search. The exception to this is if the target of the search is a TDBM backend where the server compatibility level is less than 4. In this case, an identical persistent search request must be issued to each LDAP server in the sysplex. See the description of the serverCompatLevel configuration option in serverCompatLevel {3 | 4 | 5 | 6 | 7} for more information about the server compatibility level.

    Persistent search against a TDBM backend in a sysplex environment with large groups can result in performance problems. See Large access groups considerations for more information.

16. The SDBM backend does not support persistent search. To be notified of changes to a RACF® user (including password changes), group, user-group connection, or general resource profile, request a persistent search of the change log directory. If configured, RACF creates a change log entry when a modification is made to a RACF user, group, connection, or resource profile.
17. Operational attributes are returned on persistent searches except the following: aclSource, hasSubordinates, ibm-allGroups, ibm-allMembers, ibm-entryChecksum, ibm-entryChecksumOp, ibm-replicationChangeLdif, ibm-replicationFailedChangeCount, ibm-replicationFailedChanges, ibm-replicationIsQuiesced, ibm-replicationLastActivationTime, ibm-replicationLastChangeId, ibm-replicationLastFinishTime, ibm-replicationLastResult, ibm-replicationLastResultAdditional, ibm-replicationNextTime, ibm-replicationPendingChangeCount, ibm-replicationPendingChanges, ibm-replicationPerformance, ibm-replicationState, ibm-replicationThisServerIsMaster, ownerSource, and pwdChangedTime. The aclEntry, aclPropagate, entryOwner, and ownerPropagate attributes are returned only if they are defined for the entry and are not inherited from a superior entry.