Explanation | The Recovery Log Service is in pending state to allow the system to backup the recovery log files. |
Action | No action is required. |
Explanation | The Recovery Log Service that was suspended earlier is restored to running state. |
Action | No action is required. |
Explanation | This message code is used to support messages that have not yet been allocated their own message code. |
Action | Refer to the message text for more information. |
Explanation | The recovery log service could not create the file indicated in the message. Either the target directory is inaccessible, or the system does not have sufficient permissions to create the required file. |
Action | Ensure that the required directory hierarchy is valid and accessible to the recovery log service. |
Explanation | The recovery log service could not exclusively lock the file indicated in the message. |
Action | If the problem persists, additional information might be available if you search for the message ID on the following Web sites: WebSphere Application Server Support page: http://www.ibm.com/software/webservers/appserv/was/support/ WebSphere Application Server for z/OS Support page: http://www.ibm.com/software/webservers/appserv/zos_os390/support/ . |
Explanation | A new recovery log file has been established to store persistent data. |
Action | No action is required. |
Explanation | Either previously recovery log files have been deleted, or this is the first time recovery log files have been stored in this location. In either case, the associated service will start and will not perform any recovery processing. |
Action | No action is required. |
Explanation | The recovery log has failed, and there is no further access to the recovery log. The message shows the component and the relevant exception. |
Action | Restart the server so that the log can be repaired. Try to fix any conditions indicated by the exception in the message. |
Explanation | This message is issued with message CWRLS0008E to indicate the details of the recovery log failure. |
Action | Use the information in this message and message CWRLS0008E to correct that condition that caused the recovery log to fail. |
Explanation | The recovery log service is directing recovery processing of associated client services. |
Action | No action is required. |
Explanation | The recovery log service is directing recovery processing of associated client services for the peer server. |
Action | No action is required. |
Explanation | The recovery log service has prompted all associated client services to begin recovery. |
Action | No action is required. |
Explanation | The recovery log service has prompted all associated client services to begin recovery for the peer server. |
Action | No action is required. |
Explanation | Recovery processing is being transferred to an alternative application server. Typically, this occurs when a server is restarted and retakes ownership of its recovery logs. |
Action | No action is required. |
Explanation | The file locking mechanism that the recovery log service uses to ensure exclusive access to recovery log files has been explicitly disabled. |
Action | Ensure that the appropriate constraints are in place to support this configuration setting. |
Explanation | Either the target server is active, or the recovery log configuration is incorrect. |
Action | Ensure that the recovery log configuration is valid. |
Explanation | Control of a recovery log has been passed between two application servers. |
Action | No action is required. |
Explanation | The recovery log service has stopped the local server from relinquishing control of its own recovery logs. This might be caused by the core group policy configuration. |
Action | Ensure that the policy configuration does not assign ownership of the recovery log of an active server to an alternative server. |
Explanation | When a snapshot of the log files is requested, all transaction logging activity is suspended while the snapshot is taken, to ensure that the log files are in a known state that is consistent with other systems involved in the snapshot. |
Action | No action is required. |
Explanation | If a snapshot of the log files is taken, the log files might not be in a state that is consistent with other systems involved in the snapshot. |
Action | No action is required. |
Explanation | The recovery log service will be resumed only when there are no outstanding suspend operations. |
Action | No action is required. |
Explanation | If there are no outstanding suspend operations the recovery log service will resume. |
Action | No action is required. |
Explanation | This message is for informational purposes only. |
Action | No action is required. |
Explanation | An exception was detected while attempting to recover from a previous server failure. |
Action | If the problem persists, additional information might be available if you search for the message ID on the following Web sites: WebSphere Application Server Support page: http://www.ibm.com/software/webservers/appserv/was/support/ WebSphere Application Server for z/OS Support page: http://www.ibm.com/software/webservers/appserv/zos_os390/support/ . |
Explanation | In a high availability configuration, server recovery might be automatically initiated on a peer server. |
Action | Do not attempt to start a server in recovery mode if it is enabled for high availability . |
Explanation | The recovery log service cannot exclusively lock the file indicated in the message during recovery, because the file appears to be in use. The recovery service will attempt periodically to gain the exclusive lock so that recovery can proceed. If the recovery log file is one of the main server recovery logs, startup is suspended until access to the logs is possible. If the recovery log file belongs to another peer server, another server might gain the locks and perform peer recovery; in this situation, this server will stop trying to recover. |
Action | Examine any related messages to determine the cause of the problem. If there are no related messages, check the location of the recovery logs and ensure they are not being accessed by another server. For example, this situation could occur if more than one server is configured to use the recovery logs of another server. |
Explanation | Transaction logs from two servers are using a common directory configuration. This might cause recovery lock contention or a failure of data integrity. |
Action | Configure separate log directory paths for each server. |
Explanation | Compensation logs from two servers are using a common directory configuration. This might cause to recovery lock contention or a failure of data integrity. |
Action | Configure separate log directory paths for each server. |
Explanation | The recovery log service cannot perform or complete recovery for the local server and no further work can proceed, so the server will be stopped. |
Action | If the problem persists, additional information might be available if you search for the message ID on the following Web sites: WebSphere Application Server Support page: http://www.ibm.com/software/webservers/appserv/was/support/ WebSphere Application Server for z/OS Support page: http://www.ibm.com/software/webservers/appserv/zos_os390/support/ . |
Explanation | The recovery log service cannot initiate recovery processing for the local server, because it is waiting for the HAManager to activate group membership for the recovery logs of this local server. |
Action | Examine any related messages to determine the cause of the problem. If there are no related messages, check the configuration of the DefaultCoreGroup settings and associated policy definitions for the recovery log service for the server. For example, if the Clustered TM policy is set to not support fail back, another server might have a hold on the logs and will stop this server from being activated. |