Task | LDAP automation and recovery scenarios |
---|---|
Startup | LDAP, as used by
WebSphere Application Server for z/OS, is completely run within the WebSphere
Application Server for z/OS address spaces using something called "the local
backend." This support takes the front side of the LDAP client APIs and the
backend database implementation and runs them completely inside the WebSphere
Application Server for z/OS Naming Server and Interface Repository. For Naming
and IR, OMVS and DB2 must be up before Naming and IR. To run the LDAP
server, TCPIP, OMVS, and DB2 must all be up before the LDAP server. Note: There are two LDAP modes supported:
|
Shutdown | Shutdown Naming and IR, then OMVS and DB2. For the LDAP server, shutdown the LDAP server, then TCPIP and DB2, and then OMVS. |
Handling in-flight or indoubt transactions if there is a failure | If there is a failure during processing, Naming and IR rely on RRS to issue a rollback directly to DB2 and, as a result, any work done by the LDAP code is rolled back along with it. For the LDAP server, AUTOCOMMIT is set to NO, causing any error to ROLLBACK for that transaction. This ensures the atomicity characteristic of LDAP operations. |
How to determine if LDAP is running | In the case of WebSphere Application Server for z/OS, if Naming and IR are operating, then LDAP is operating. In the case of the LDAP server, and a started task is used for the LDAP server, use the SDSF to see if the started task is running. Examine the output log for the started task to see if any error messages were displayed. Alternatively, the LDAPSRCH command (from TSO), or LDAPSEARCH command (from Unix System Services shell) can be used to perform a simple search to verify that the LDAP server is running. |
What happens to WebSphere Application Server for z/OS if LDAP goes down? |
|
What happens to other subsystems if LDAP goes down? | Most z/OS or OS/390 subsystems do not depend on LDAP, but this may change in the future. In the case of accessing LDAP through the LDAP server, there is a way to configure the LDAP server to operate in a sysplex environment such that (using sysplex-enabled DNS) LDAP requests will be sent to the LDAP server in the sysplex that is operating (assuming that there is one). As an alternative, subsystems that want to use LDAP could configure a backup LDAP server to be contacted in case the primary server is not accessible. In this case, the application would assume that it could retrieve all of the same data that it could get from the backup on the primary which would be handled by some replication mechanism. The LDAP server currently supports a master/slave replication mechanism, but you could also try duplicating the sysplex server using DB2 data sharing. |
Where to find more information | z/OS Security Server LDAP Server Administration and Use |