> BTW: if this is of crucial importance to you, you may want to check (and
> perform tests) the functionality when your LDAP server is not available
> for some reason. Can you set it up with multiple LDAP servers, does PMDF
> support this properly, etc. I've seen some odd things in the past when
> doing e.g. LDAP qeuries from within the mappings file.


This is indeed a problem. I added a nasty bit of business to iMS to try and
cope with it several months back. Here's a description:

The $. metacharacter sequence can now be used in a mapping or rewrite
rule to establish a string which will be processed as the mapping entry
result in the event of a temporary LDAP lookup failure. By default
temporary LDAP failures cause the current mapping entry to fail.
This is problematic in cases where different actions need to be taken
depending on whether the LDAP lookup failed to find anything versus the
directory server being unavailable or misconfigured. The temporary
failure string is terminated by an unescaped ".". In the case of mappings
once a failure string has been set using this construct it will remain
set until current mapping processing is completed. Rewrite rules behave
differently; a temporary failure string remains set only for the duration
of the current rule. "$.." can be used to return to the default state
where no temporary failure string is set and temporary LDAP failures
cause mapping entry or rewrite rule failure. Note that all errors other
than failure to match an entry in the directory are considered to be
temporary errors; in general it isn't possible to distinguish between
errors caused by incorrect LDAP URLs and errors caused by directory
server configuration problems.

It's certainly ugly, but it's the only way I could come up with to shoehorn
a three-state outcome into a system that's intrinsicly only allows
two outcomes.

Ned