LDAP automation and recovery scenarios


LDAP automation and recovery scenarios
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:

  1. Local LDAP backend.
  2. Remote LDAP Server. The WebSphere Application Server for z/OS environment has to be set up correspondingly, and DB2, TCP/IP, and the remote server have to be up and running before WebSphere Application Server for z/OS is started.

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?
  • In J2EE server regions, the LDAP server must be active since it is a separate server that no longer runs inside the WebSphere Application Server for z/OS region. Recycle the JNDI, then restart the J2EE application servers.
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





Searchable topic ID:   rtrb_ldapautorec
Last updated: Jun 21, 2007 9:56:50 PM CDT    WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rtrb_ldapautorec.html

Library | Support | Terms of Use | Feedback