ADAX* - Adabas Cluster Nucleus Messages

A nucleus entered or left the Adabas cluster.

Adabas nucleus cluster members that were identified as active at initialization are indicated with status 'is present'. Post-initialization changes to Adabas cluster membership are indicated with status 'has joined'; 'has withdrawn'; or 'has failed'.

No action is required for this informational message.

XCF reported that the named system (sysn) is not responding. This affects all XCF users on that system, not just Adabas. Until communications are restored, all nuclei on that system may not be able to respond to critical intracluster synchronization messages before the message times out.

Attempt to restore XCF communications with the named system.

After missing one or more status monitoring intervals, the named system (sysn) is now responding to XCF communications.

No action is required for this informational message.

XCF reported that the identified nucleus (nucid) on the identified system (sysn) is not updating its heartbeat monitor. It is likely that the nucleus is not able to process commands, including critical intracluster synchronization messages.

Determine why the nucleus is not able to update its heartbeat monitor. The nucleus may be hung or looping, or there may be other processes in the system preventing the nucleus from getting sufficient CPU allocations.

The identified nucleus (nucid) on the identified system (sysn) has resumed updating its heartbeat monitor.

No action is required for this informational message.

This message may appear when another nucleus terminates.

No action is necessary if the other nucleus is terminating abnormally. If the message occurs in an otherwise normal nucleus session, contact your Software AG technical support representative.

An error described in preceding messages prevented successful initialization of Adabas cluster messaging services. Nucleus initialization fails with PARM-ERROR 092.

Correct the problem identified in the preceding messages.

A request to obtain storage from the work pool for Adabas cluster messaging service control structures failed. Nucleus initialization fails with PARM-ERROR 092.

Increase the amount of virtual storage available. Alternatively, adjust ADARUN parameters to allow for a larger work pool or decrease ADARUN parameters NT and NU to require fewer AXMCBs.

An error occurred while replying to an internucleus V2 command originating from the nucleus whose nucleus ID is given in the message (nucid). The reply could not be sent. The error code given in the message (subcode) is one of the possible subcodes for response code 123. The originating nucleus message sequence number is also given in the message (msgnum).

The originating nucleus will continue to wait for a reply until the message times out or the nonresponding nucleus ends.

If the reason for the error cannot be determined and corrected, notify your Software AG technical support representitive.

Produced during normal nucleus termination, this message provides Adabas Cluster Services messaging service statistics:

No action is required for this informational message.

Produced during normal nucleus termination, this message provides Adabas cluster messaging service statistics:

No action is required for this informational message.

This message is used to display the output from the DXMSG operator command on the console.

No action is required for this informational message.

The z/OS XCF transport service successfully initialized.

No action is required for this informational message.

The error specified by one of the following error texts occurred during the z/OS XCF transport service initialization check:

DBdddddpppppNnn

DBdddddpppppNnn

DBdddddpppppNnn

The user actions are given in the table above. If the problem persists, contact your Software AG technical support representative for assistance.

This nucleus was notified by XCF that it failed to update its heartbeat monitor within the interval specified by ADARUN parameter MXSTATUS. XCF will notify all other nuclei registered to the same XCF group, each of which may issue message ADAX04.

Determine why this nucleus is not able to update its heartbeat monitor. The nucleus may be hung or looping, or there may be other processes in the system preventing the nucleus from getting sufficient CPU allocations.

After missing one or more status monitoring intervals, this nucleus has resumed updating its heartbeat monitor. XCF will notify all other nuclei registered to the same XCF group, each of which may issue message ADAX05. This message reports the number of seconds (nn) since the missing status update was first detected and the related ADAX22 message was printed.

No action is required for this informational message.

An error occurred while processing an incoming asynchronous message. This message appears only in the z/OS Adabas nucleus JESLOG listing, SYSLOG or operator's console. One of the following error texts is given in this message:

The user actions are given in the table above. If the problem persists, contact your Software AG technical support representative for assistance.

An error occurred when processing a member state change event generated by the z/OS XCF messaging transport service as a member attempted to join the XCF group. The control information presented for the XCF group member attempting connection was not formatted as a proper Adabas sysplex cluster nucleus or had a different DBID. The joining member may be an Adabas sysplex cluster nucleus associated with a different DBID or it may be another process using the same XCF group name. All Adabas sysplex cluster nuclei generate xcf-member names in the format

DBdddddpppppNnn

where:

The member state change event is discarded.

Identify the source of xcf-member. If it is an Adabas sysplex cluster nucleus, make sure the parameters NUCID, CLUGROUPNAME, and DBID are correct and notify your Adabas technical support representative if this does not correct the problem. There may be additional information in the messages for the nucleus attempting to join. If it is not an Adabas sysplex cluster nucleus, notify your system programmer or support representative.

An error occurred when processing a member state change event generated by the z/OS XCF messaging transport service.

Contact your Adabas technical support representative. The member state change event is discarded.

This message appears only in the z/OS Adabas nucleus JESLOG listing, SYSLOG, or operator's console. It is issued for certain XCF message transport service requests during initialization and termination, and whenever a request fails. Refer to IBM documentation entitled MVS Programming: Sysplex Services Reference for descriptions of the various return and reason codes for each XCF service.

This message may be associated with an error condition reflected in other messages, or may have caused an Adabas cluster message request to fail. If an associated error is identified, include this message when contacting your Software AG technical support representative.

A program check or system abend was intercepted by the z/OS XCF messaging transport service FRR or ESTAE routine. The error may have occurred under an SRB.

The nucleus should terminate. A dump may be produced in SDUMP format, either in one of the nucleus-allocated files SYSUDUMP, SYSMDUMP, or SYSABEND; or in a system-allocated file such as SYS1.DUMPn.

Contact your Software AG technical support representative for assistance.

One of the following message texts can appear in this message:

The user actions are given in the table above. If the problem persists, contact your Software AG technical support representative for assistance.

One of the following message texts can appear in this message:

The user actions are given in the table above. If the problem persists, contact your Software AG technical support representative for assistance.

One of the following message texts can appear in this message:

The user actions are given in the table above. If the problem persists, contact your Software AG technical support representative for assistance.

One of the following message texts can appear in this message:

The user actions are given in the table above. If the problem persists, contact your Software AG technical support representative for assistance.

One of the following message texts can appear in this message:

The user actions are given in the table above. If the problem persists, contact your Software AG technical support representative for assistance.

A call was made to terminate the cluster session without a previous successful initialization call.

ADASMM terminates.

A cancel call was made without a previous successful initialization.

ADASMM terminates.

One of the following message texts can appear in this message:

The user actions are given in the table above. If the problem persists, contact your Software AG technical support representative for assistance.

One of the following message texts can appear in this message:

The user actions are given in the table above. If the problem persists, contact your Software AG technical support representative for assistance.

While recovering from the failure of one or more Adabas cluster nuclei, this nucleus is about to open the Work data set of the nucleus with the specified (external) NUCID, which terminated abnormally.

No action is required for this informational message.

While recovering from the failure of one or more Adabas cluster nuclei, this nucleus tried to open the Work data set of the nucleus with the NUCID 'nucid' (message ADAX31), but the open failed. ADAIOR issued response code 'cc' (in hexadecimal), and the system's return code is 'ssss' (in hexadecimal). The nucleus job protocol (DD/PRINT) contains an ADAI63 message detailing the name of the Work data set that could not be opened.

Determine why opening the Work data set failed. Possible causes include the following:

• the Work data set or its catalog entry is inaccessible or has been damaged; or

• the PPT block containing the name of the Work data set has been damaged.

• If possible, correct the error and restart the nucleus. Otherwise, the database must be restored and regenerated.

If in doubt, contact your Software AG technical support representative.

While recovering from the failure of one or more Adabas cluster nuclei, this nucleus encountered a Work block in which the timestamp at the beginning of the block did not match the control timestamp at the end of the block. The last write of the block was incomplete, or the block has been damaged for another reason. It is inconsistent and cannot be used for recovery. The block was read from the Work data set of the nucleus with the NUCID 'nucid'. Its RABN is 'rrrr'.

Restore and regenerate the database. If in doubt, contact your Software AG technical support representative.

A program check or system abend was intercepted by the z/OS XES parallel sysplex cache service FRR routine. The error occurred under an SRB.

The nucleus should terminate. A dump may be produced in SDUMP format, either in one of the nucleus-allocated files SYSUDUMP, SYSMDUMP, or SYSABEND; or in a system-allocated file such as SYS1.DUMPn.

Contact your Adabas technical support representative.

ADANCX is the nucleus extension module for Adabas cluster environments. The attempt to allocate space for this module failed.

Reduce memory requirements or expand the amount of memory available.

An attempt to allocate space failed.

Reduce memory requirements or expand the amount of memory available.

Internal error.

Contact your Software AG technical support representative.

ADANCX is the nucleus extension module for Adabas cluster environments. A second attempt to allocate space for this module failed.

Reduce memory requirements or expand the amount of memory available.

An error occurred while connecting to the sysplex cache structure. See the following messages for the reason.

Correct the problem. If the action to take is not obvious, contact your Software AG technical support representative.

An attempt to allocate space failed after Adabas was connected to the external cache structure.

Reduce memory requirements or expand the amount of memory available.

An error occurred while connecting to the sysplex cache structure. The 'x's identify cache-related return codes; the 'y's identify reason codes to explain the error.

If you are using Adabas Parallel Services, contact your Software AG technical support representative for assistance.

If you are using Adabas Cluster Services, see the IBM manual MVS Programming: Sysplex Services Reference for an explanation of the codes. Relevant information can be found in the Return and Reason Codes section of the macro IXLCONN. Common reason codes that occur due to configuration errors include the following:

The message text of this message varies. The following table explains and describes the user action that should occur as a result of the different message texts.

Perform the action described in the table above.

An unexpected return code was returned during execution of a macro related to the cache structure.

If you are using Adabas Parallel Services, contact your Software AG technical support representative for assistance.

If you are using Adabas Cluster Services, see the IBM manual MVS Programming Sysplex Services Reference for an explanation of the codes. Relevant information can be found in the Return and Reason Codes section of the macro IXLCACHE, in the chapter corresponding to the function displayed in the message.

An attempt to allocate space for the cast-out directory buffer failed.

Reduce memory requirements or expand the amount of memory available.

The Adabas nucleus connected successfully to the cache structure; however, the attributes of the cache structure are inappropriate for the Adabas sysplex cluster. Most likely, the cache structure is already being used by another program.

Determine which other program is using the cache structure. Either terminate this other program or specify a different cache structure for use by Adabas Cluster Services.

The cache structure with the name indicated is already being used by another Adabas cluster. Cache structure names may only be used for a single Adabas cluster of nuclei.

Use the cache structure name identified for use by your particular cluster.

An internal error has occurred.

Contact your Software AG technical support representative for assistance.

The cache structure connected successfully; however, the number of cache data elements in the external cache structure (or global cache area)is not sufficient. There must be enough data elements to hold 80,000 or more bytes of information. The number of data elements allocated is indicated earlier in message ADAX57.

Increase the size of the external cache structure (or global cache area). Alternatively, modify the ADARUN parameters DIRRATIO and/or ELEMENTRATIO to ensure that enough cache data elements are allocated.

An internal error occurred that caused the nucleus to terminate abnormally. A message issued prior to this one provides more information related to the error.

Contact your Software AG technical support representative for assistance.

Various message texts can be associated with thie message number, as described in the following table:

For all possible message texts, contact your Software AG technical support representative for assistance.

An Adabas cluster nucleus successfully connected to the specified cache structure (or global cache area) in a cluster environment. This message provides a count of the cache's directory entries and data elements, along with the data element size.

No action is required for this informational message.

The attempt to connect an Adabas cluster nucleus to the cluster cache structure in a sysplex environment timed out waiting for information about existing connections to the cache structure.

Try again to start the Adabas sysplex cluster nucleus. If the error continues to occur, contact your Software AG technical support representative.

An unexpected return code was received during a call to the referenced module. The message includes the function code and return code.

Contact your Software AG technical support representative.

After data storage updates, the nucleus is unable to read a DSST block into the buffer pool or global cache or to write the updated DSST block to the cache, because the buffer pool or cache was full. It is possible that the DSST bytes for one or more of the updated data storage blocks are incorrect.

This message is printed at most once in 10 minutes.

Incorrect DSST bytes may have slightly adverse effects on the effectiveness of space reuse in data storage. If the associated data storage blocks are updated again, incorrect DSST bytes are implicitly corrected.

Either the buffer pool or the global cache or both are too small to support the number of parallel commands running in the nucleus or the whole cluster. Increase the buffer pool or global cache size.

ADABAS Parallel Services is using z/OS shared 64-bit addressable storage as part of its cache configuration. Connecting to the S64 object establishes a local affinity and makes the object addressable. Disconnecting deletes the affinity, after which the object is no longer addressable. Any non-zero return code received from z/OS IARV64 is formatted.

If the attempt fails, examine the IARV64 return and reason code description in the IBM documentation entitled MVS Programming: Authorized Assembler Services Reference, Volume 2 (EDTINFO-IXGWRITE). If the cause is not clear, notify your Software AG technical support representitive.

This message reports the setting of the ADARUN CLUCACHEUNCHANGED parameter for this Adabas Parallel Services nucleus. Unchanged blocks either will or will not be written to the global cache.

No action is required for this informational message.

An event occurred related to another connector of a cache or lock structure.

No action is required for this informational message.

Whenever a nucleus disconnects from a cache, this message is issued with cache activity statistics. These may be useful in diagnosing problems and selecting a suitable cache configuration. Bear in mind that the statistics show only one nucleus’s activity. Full understanding may require examining the statistics of other nuclei.

This message is also used to display the output from the DXTAT, DXCACHE, DXLOCK, DXFILE, and DMEMTB operator commands on the console. For examples of this message used with these commands, refer to the documentation for Adabas Cluster Services operator commands.

Here is an example of the statistics provided in this message:

ADAX61 Statistics at disconnect for cache C00C7231                             
        Cache Directory Management Activity                                     
                      32,565 Read located active                                
                       5,230 Read obtained from free pool                       
                           0 Read reclaimed, first choice criteria              
                           0 Read reclaimed, second choice criteria             
                           0 Read reclaimed, third choice criteria              
                           0 Read reclaimed, fourth choice criteria             
                           0 Read unable to obtain (cache full)                 
                           0 Total number of directory reclaim attempts         
                           0 Number of directories examined for reclaim         
                       0.000 Average number of directories examined per attempt 
                         680 Write obtained from free pool                      
                         496 Directory high-water mark (this nucleus)           
                       1,134 Directory high-water mark (cluster-wide)           

        Cache Write Requests                                                   
                     306,706 Sufficient preallocated space                     
                         235 Free space allocated                              
                           5 Space reclaimed, first choice criteria            
                       6,322 Space reclaimed, second choice criteria           
                         885 Unable to obtain space (cache full)               
                       4,292 Space search examined part of space chain         
                       3,155 Space search examined entire space chain          
                       7,447 Total number of space allocation attempts         
                     462,840 Number of space chain descriptors examined        
                      62.151 Average number of descriptors examined per attempt

        Cache Space Element Reclamation                                
                          48 Elements reclaimed, first choice criteria 
                      28,431 Elements reclaimed, second choice criteria

        Latch Attempts                Exclusive                     Shared
          Cache Space Chain                                               
            Get                           7,455                           
            WaitFor                           8                           
            Release                       7,447                           
          Cache Directory Index                                           
            Get                           5,351                    249,009
                                          5,228 Upgrade                   
            WaitFor                           0                          0
                                              0 Upgrade                   
            Release                      10,579                    243,781
          Cache Directory                                                 
            Get                         454,179                    398,747
                                          5,335 Upgrade                   
            WaitFor                         205                         53
            Release                     459,297                    393,339
          Cache Cast-Out Class                                            
            Get                          44,865                      3,510
            WaitFor                           0                          0
            Release                      44,865                      3,510
 

These statistics are described in the following table:

No action is required for this informational message.

An attempt to lock or unlock a logical resource failed. The lock manager function number is 'xx'; its response code is 'cccccccc'; and its reason code is 'rrrrrrrr'. All variables are in hexadecimal.

The nucleus terminates abnormally.

This is an unexpected error. Contact your Software AG technical support representative for assistance.

If you are using Adabas Cluster Services, see the IBM manual MVS Programming: Sysplex Services Reference for an explanation of the codes, . Relevant information can be found in the Return and Reason Codes section of the macro IXLLOCK.

An error occurred while connecting to the lock structure. The lock manager's response code is 'cccccccc', its reason code is 'rrrrrrrr'. Both variables are in hexadecimal.

The nucleus terminates abnormally.

This is an unexpected error. Contact your Software AG technical support representative for assistance.

If you are using Adabas Cluster Services, see the IBM manual MVS Programming: Sysplex Services Reference for an explanation of the codes. Relevant information can be found in the Return and Reason Codes section of the macros IXCQUERY and IXLCONN. Common reason codes that occur due to configuration errors include the following:

The lock manager failed to acquire main storage.

Restart the nucleus with a larger REGION parameter or make the nucleus parameters NH, NU, or LDEUQP smaller.

This message is printed in two instances. It occurs when:

1. The parameter value of a newly-started cluster nucleus is taken over (replaced) by the global parameter value in use by the already active cluster nuclei. The old value (old-value) is the parameter value read from the ADARUN statements of the starting nucleus; the new value (new-value) is the global parameter value in use by the already active cluster nuclei.

2. A global parameter value is changed on one nucleus in the cluster. This new parameter value is propagated to all of the other active cluster nuclei and is taken over (used) by them.

No action is required for this informational message.

An incompatible parameter value has been specified for a second or subsequent cluster nucleus when it starts. When this occurs, the starting nucleus:

• Does not take over (use) the global parameter value.

• Does not come up.

The parameter value specified (value-specified) by the second or subsequent cluster nucleus and the parameter value currently in effect (value-in-effect) for all cluster nuclei are given in the message.

Resolve the incompatibility of the parameter values so that the newly-started cluster nucleus and the other active cluster nuclei can use the same parameter value.

The lock structure with the name specified in the message is already being used by another Adabas sysplex cluster or by other software. Lock structure names must be unique in the sysplex environment and for each Adabas nucleus cluster.

Use the lock structure name that has been identified for use by your particular Adabas sysplex cluster.

An attempt to connect an Adabas sysplex cluster nucleus to the lock structure timed out waiting for information about existing connections to the lock structure.

Determine whether any conditions exist in the coupling facility or the system itself that could interrupt the flow of information or make the flow extremely slow.

The lock structure defined in the CFRM policy is too small to handle the current settings of the ADARUN parameters. The minimum number of records expected by the processes is indicated.

Either decrease the value of the ADARUN parameters NU, NH, or LDEUQP; or increase the size of the lock structure.

After a peer nucleus disconnected abnormally from the lock structure, this nucleus issued an IXLEERSP request to XES to acknowledge the peer failure, but the IXLEERSP request got the response code and reason code shown. These are documented in MVS Programming: Sysplex Services Reference IBM manual in the Return and Reason Codes section of the IXLEERSP macro.

This nucleus will continue performing the online recovery process after the peer failure. It will disconnect from the lock structure as part of the recovery process, which is another way of acknowledging the peer failure to XES. However, due to the unsuccessful IXLEERSP request, there is a very small chance of a cluster-wide deadlock involving XES.

In the case of a hangup of the online recovery process, cancel a nucleus that has not yet printed an ADAX89 message. This may unravel the deadlock. If there is no such nucleus, cancel the nucleus that will do the session autorestart, as per the ADAX89 messages. Restart the cluster after all nuclei have terminated.

In either case, report the occurrence of the ADAX6B message to your Software AG technical support representative.

An Adabas cluster nucleus successfully connected to the specified lock structure in a z/OS parallel sysplex environment. This message provides

• a count of lock entries; and

• the maximum number of records elements.

No action is required for this informational message.

This message identifies the RABN value in hexadecimal for which a cache write is being retried. The error leading to the write retry is identified in previous messages.

An attempt to allocate space for the lock element table failed.

Reduce the memory requirements for the table or expand the amount of memory available.

An error was detected in the lock structure policy: both the SIZE and INITSIZE values are zero.

Review the lock structure policy and make the necessary changes.

Corresponds to the ADAN05 message at startup, but occurs during online recovery.

Adabas has begun to write data protection log data to the data set identified by DD/PLOGRn. This means that the data set can no longer be copied to tape for subsequent use as input to the REGENERATE or BACKOUT functions of the ADARES utility. A user exit 2 (dual log processing) or user exit 12 (multiple log processing) call either was not made or did not successfully copy the DD/PLOGRn data set with the ADARES utility.

If the database is running without user exit 2, overwriting the PLOG data is normal and this message can be ignored.

If the database is running with user exit 2, this message occurs only when the user exit asks the nucleus to proceed even though the PLOG has not been copied. Whether this is an error or not depends on the logic the user has implemented in the user exit.

Corresponds to the ADAN21 message at startup, but occurs during online recovery.

Adabas is now ready to begin writing data protection information to the dual or multiple data protection log identified by DD/PLOGRn.

Execute the PLCOPY function of the ADARES utility at this time to reinitialize the PLOGs.

Corresponds to the ADAN02 message at startup, but occurs during online recovery.

The Adabas nucleus session has been initiated and database protection logging has been specified. Subsequent execution of the REGENERATE and BACKOUT functions of the ADARES utility for any updates applied during the session is possible.

A query request to ADAMPM to get the address of the IDTH failed. The nucleus terminates abnormally.

This is an unexpected error. Contact your Software AG technical support representative.

While trying to connect to the global lock area, ADASML detects that either ADACOM is not running or the CLULOCKSIZE parameter is not specified. The nucleus terminates abnormally.

Start ADACOM before starting the Adabas Parallel Services cluster nucleus and specify a nonzero value for the CLULOCKSIZE parameter.

Cluster Services nuclei working on the same database synchronize some of their actions using resource locks via Global Resource Serialization (GRS).

During session start one nucleus detected that a resource lock it obtained was not effective against the peer nucleus with the NUCID shown, which was active on the system shown.

The starting nucleus terminates with parm-error 105.

Contact your system programmer to ensure that GRS is configured in a way that GRS resource locks are mutually effective against one another on all systems on which you intend to run Cluster Services nuclei.

An Adabas cluster nucleus initiated an online recovery process after it detected that a peer nucleus in the same cluster terminated abnormally. (Each surviving nucleus initiates its own online recovery process.) The online recovery process stops all ongoing work in the nucleus, performs a session autorestart (including the backout of all open transactions), or waits until a peer nucleus performs the session autorestart, and then resumes normal processing.

A nucleus started while other nuclei that were already active in the same cluster were performing online recovery in response to a nucleus failure. The starting nucleus waits until the online recovery process completes and then continues with its startup sequence.

In order to recover from the failure of a peer nucleus (online recovery), the nucleus canceled

• a running online save operation in which case the save operation fails;

• a running transaction suspension operation; or

• an ADAEND or HALT shutdown request, in which case the nucleus does not shut down after the recovery process has finished.

Either restart the save operation after the online recovery process has completed successfully; or issue another ADAEND or HALT request if you still want to shut down the nucleus.

When the online recovery process started, one or more transactions were active. The recovery process allows them to continue for a while in an attempt to bring them to normal completion.

All transactions that were active when online recovery started have finished normally.

A number of transactions indicated in the message were active when online recovery started but did not finish within the allotted time and were interrupted. They are backed out during online recovery. The affected users receive response code 9, subcode 18, for their next commands.

When the online recovery process was ready to interrupt all ongoing work, one or more commands were still active. The recovery process allows them to continue for a short time in an attempt to bring them to normal completion.

All active commands that the online recovery process was waiting for have finished normally.

A number of active commands indicated in the message did not finish within the allotted time and were interrupted. They are sent back to their respective users with response code 9, subcode 19. Their associated command IDs, if any, are deleted.

When the online recovery process interrupted all ongoing work, one or more I/Os were active. The recovery process waits for these I/Os to finish.

All I/Os that the online recovery process was waiting for have finished.

When the online recovery process interrupted all ongoing work, one or more internucleus commands were still due a response. The recovery process waits for the responses to arrive.

All outstanding responses for internucleus commands that the online recovery process was waiting for have arrived.

The session autorestart that is part of the online recovery process is performed either by this nucleus or by a peer nucleus, as indicated in the message.

If more than one nucleus remains active when a peer nucleus terminates abnormally, the surviving nuclei synchronize their online recovery processes using several syncpoints, which all nuclei must reach before recovery processing can continue.

This message indicates that the nucleus that performs the session autorestart is ready to proceed when all other nuclei have reached the respective syncpoint.

The online recovery process is waiting for the nucleus that performs the session autorestart to initiate the recovery syncpoint indicated.

All nuclei involved in the collaborative online recovery have reached the recovery syncpoint indicated. The recovery process proceeds.

Various message texts can appear for this message number. The explanation and action for each is given in the following table.

Various message texts can appear for this message number. The explanation and action for each is given in the following table.

The session autorestart performed during online recovery was not successful. It received the response code shown. If the response code was associated with a particular file, the file number is also shown.

This nucleus and all peer nuclei participating in the online recovery process will go down.

The situation is now equivalent to that after failure of session autorestart during nucleus session start. Determine why the session autorestart failed. Consider contacting your Software AG technical support representative.

A second nucleus failure occurred while an online recovery process was in progress to handle the abnormal termination of a peer nucleus. All nuclei active in the Adabas cluster will go down.

Restart the Adabas cluster. Determine the reasons for the first and the second failure. Consider contacting your Software AG technical support representative.

A nucleus failure occurred while a utility with exclusive database control was running. All nuclei active in the Adabas cluster will go down.

Restart the Adabas cluster and perform appropriate recovery actions for the utility with exclusive database control.

The online process set up to handle the abnormal termination of a peer nucleus finished successfully. The nucleus resumes normal operation.

An online recovery process that was started to recover from the failure of one nucleus received a response code while communicating with another, still alive nucleus. All remaining active nuclei terminate.

Restart the nuclei. The first starting nucleus performs offline recovery (that is, session autorestart).

An internal command used for inter-nucleus communication encountered a messaging failure; it got the response code/subcode shown from the peer nucleus shown.

This message may follow message ADAX9E or ADAX9H. After a messaging failure during intracluster communication the nucleus has decided to terminate itself due to an uncorrectable communication failure.

The nucleus terminates abnormally with user abend code 79.

Investigate the cause of the intracluster communication failure, starting with the response code and subcode reported in one or more preceding ADAX9E messages.

If some kind of timeout (MXMSGWARN, MXMSG, MXCANCELWARN, or MXCANCEL parameter) was involved in the failure, ensure that all cluster nuclei run with high enough priority to get sufficient resources for participating in cluster-wide business.

Consider contacting your Software AG technical support representative.

When a cluster nucleus tried to determine the status of an internal intracluster command (given in the message), an error occurred. The internal return code is shown. A preceding message might possibly contain more information about the error.

The nucleus ignores the error and continues normally. Because it could not determine the status of the responses to the intracluster command cited, it does not warn early about outstanding responses (ADAX9B and ADAX9C messages)

Contact your Software AG technical support representative.

A cluster nucleus issued an XCF send request for an intracluster command (shown) to a peer nucleus (shown), but the command has not yet been sent within the time period set by the MXMSGWARN parameter. The number nn (shown) distinguishes different internal intracluster commands that may be in progress at the same time.

No direct system action occurs. However, if the command is not sent or the peer nucleus does not respond within the time period set by the MXMSG parameter, either nucleus may terminate abnormally.

This message is for your information. It may be useful for analysis in the case of a subsequent error.

A cluster nucleus sent an internal intracluster command (shown) to a peer nucleus (shown) in the cluster. The peer nucleus has not yet responded to the command within the time period set by the MXMSGWARN parameter. The number nn (shown) distinguishes different internal intracluster commands that may be in progress at the same time.

No direct system action occurs. However, if the peer nucleus does not respond within the time period set by the MXMSG parameter, it will be canceled.

This message is for your information. You may want to use the provided information (NUCID, job name, system name) to make sure that the cited peer nucleus gets sufficient resources (CPU, storage, priority) for participating in cluster-wide business.

The peer nucleus listed in the message (nucid) that was slow to respond to an internal intracluster command (xxx ) has finally responded. This message retracts the warning of a previous ADAX9B or ADAX9C message (shown with a matching nn number).

The peer nucleus is no longer in danger of being canceled (for this particular intracluster command).

No action is required for this informational message.

The internal command listed in the message (xxx) and used for intracluster communication encountered a messaging failure. The response code and subcode as well as the peer nucleus are given in the message. The response code and subcode are described in Nucleus Response Codes.

The reaction of the nucleus to this error varies, depending on the type of internal command and on the response code received. The nucleus may cancel the peer nucleus causing the error, wait for a failing peer nucleus to terminate, terminate itself due to an unhandled error condition, or pass the response code up the call chain.

Investigate the cause of the response code and subcode to resolve the error.

If some kind of timeout (MXMSGWARN or MXMSG parameter settings) is involved in the error, ensure that all cluster nuclei run with high enough priority to get sufficient resources for participating in cluster-wide business.

If the problem persists, contact your Software AG technical support representative.

This message may follow message ADAX9E. A failure occurred when a nucleus issued an intracluster command to a target peer nucleus (listed in the message) because the target nucleus did not respond to the command in time. As a result, the sending nucleus is canceling the target peer nucleus.

The nucleus waits for the canceled peer nucleus to terminate and then performs an online recovery process.

Investigate the cause of the intracluster communication failure, starting with the response code and subcode reported in one or more preceding ADAX9E messages.

If some kind of timeout (MXMSGWARN or MXMSG parameter setting) was involved in the failure, ensure that all cluster nuclei run with high enough priority to get sufficient resources for participating in cluster-wide business.

If the problem persists, contact your Software AG technical support representative.

The nucleus identified in the message by its nucleus ID (nucid), job name (jobname) and system name (sysn) was canceled, but the nucleus printing this message did not receive (within the time period set by the MXCANCELWARN parameter) the failure notifications reported in ADAX60 messages confirming that the canceled nucleus was terminated. As long as the canceled nucleus might still be active, the Adabas cluster cannot recover from the failure.

This message might also occur if the cited nucleus has not been canceled but is failing for another reason and is slow to terminate.

If the peer nucleus does not terminate within the time period set by the MXCANCEL parameter, this nucleus may ask for permission to terminate itself (if the MXWTOR parameter was set) or terminate itself without asking (if the MXWTOR parameter was not set).

Use the provided information (nucleus ID, job name, and system name) to make sure that the canceled peer nucleus gets sufficient resources (CPU, storage, priority) for terminating.

The nucleus identified in the message by its nucleus ID (nucid), job name (jobname) and system name (sysn) was canceled, but the nucleus printing this message did not receive (within the time period set by the MXCANCEL parameter) the failure notifications confirming that the canceled nucleus has terminated. As long as the canceled nucleus might still be active, the Adabas cluster cannot recover from the failure.

This message might also occur if the cited nucleus was not canceled but failed for another reason and has not terminated.

The nucleus printing this message terminates itself with message ADAX99 and user abend 79.

Check the status of the cluster nucleus cited in the message. Investigate why it did not terminate after being canceled or why the nucleus that printed this message did not receive the corresponding failure notifications (reported in ADAX60 messages).

Consider using the MXWTOR parameter to request that a cluster nucleus ask for permission before terminating itself after failing to cancel an unresponsive peer nucleus.

Ensure that all cluster nuclei run with high enough priority to get sufficient resources for participating in cluster-wide business.

If the problem persists, contact your Software AG technical support representative

This message requests an operator response. The nucleus identified in the message by its nucleus ID (nucid), job name (jobname) and system name (sysn) was canceled, but the nucleus printing this message did not receive (within the time period set by the MXCANCEL parameter) the failure notifications reported in the ADAX60 messages confirming that the canceled nucleus has terminated. As long as the canceled nucleus might still be active, the Adabas cluster cannot recover from the failure.

This message might also occur if the cited nucleus was not canceled but failed for another reason and has not yet terminated.

The nucleus will wait for the time period set by the MXWTOR ADARUN parameter for either the failure notifications of the canceled peer nucleus or a response from the operator. If the nucleus receives the expected failure notifications of the canceled peer nucleus, it retracts the ADAX9J message and starts an online recovery process to recover from the failure.

Check the status of the other cluster nucleus cited in the message. If it terminates, this ADAX9J message will be retracted.

Respond to this message using one of the following responses:

If you do not respond and the failure notifications of the canceled peer nucleus do not arrive by the MXCANCEL time, the nucleus terminates itself with messages ADAX9H and ADAX99 and user abend 79.

The peer nucleus identified in the message (nucid) that was slow to terminate after being canceled has finally ended. This message retracts the warning of previous ADAX9G or ADAX9J messages about outstanding failure notifications. The nucleus is no longer in danger of terminating itself (for this particular incident).

No action is required for this informational message.

After the operator was asked in a previous ADAX9J message to check the status of a peer nucleus that had been canceled but did not terminate, the peer nucleus has now ended. The nucleus printing this message has retracted all outstanding ADAX9J operator queries.

No action is required for this informational message.