Experiencing LDS broken connection to the LDAP server node.
CAS2379I LDS Recovery process started for LDAP Node: LDAP.CTXXX
Is there is a better way to find and restart the problem with the connection to the LDAP node?
Release : 16.0
Component : ACF2 for z/OS
ACF2 LDS will formats add, modify, or delete requests and sends it to the remote LDAP Server through native TCP/IP. If an LDAP server fails to communicate with LDAP Directory Service (LDS) Recovery due to the LDAP server being down, exceeding the configured time-out, or a busy condition, LDS requests are saved in the recovery file for later transmission. When the connection to the LDAP server is re-established the 'CAS2379I LDS Recovery process started for LDAP Node: LDAP.CTXXX' message is issued.
To determine the cause of the problem the best approach would be to review the console log for any CAS23xxx messages that proceeded the CAS2379I message.
CAS2382E LDS send request failed. LDAP node xxx is not connected
CAS2373E LDAP node is deactivated due to excessive number of connect failures, LDAP Node: xxx
When the LDAP server fails to communicate with LDS due to the LDAP server being down
CAS2372E LDS Connect failed. RC: rc LDAP Node: xxx
CAS2371E LDS Connect failed. Request has timed-out for LDAP Node xxx URL: yyy
If a site uses the LDS Journal file, the file can be browsed to determine the date/time the error(s) started.
Sites can also use the LDS recovery report (LDSRPT), which lists all LDS requests stored in the LDS Recovery File to determine the date and time of the first request written to the LDS Recover file to determine the date/time of the error. Here is sample JCL:
The following is sample JCL to run the LDSRPT report:
//LDSRPT EXEC PGM=CAS4LRPT
//STEPLIB DD DSN=CAI.CAILIB,DISP=SHR
//LDSRCVR DD DSN=CALDAP.LDSRCVR,DISP-SHR
//SYSPRINT DD SYSOUT=*
Once a site identifies the date/time of the connection issue then a site might be able to check for any network related errors or the LDAP Server logs to determine the cause of the failure.