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.

During nucleus initialization an existing nucleus had not yet synchronized by processing the ADAXCF IXCJOIN signal. This may not be an error unless the condition persists through retries of the synchronization message.

This message is always followed by message ADAX08. The membername is the nucleus's identification to z/OS XCF. It is of the form "DBdddddPpppppNnn", where ddddd is the DBID, ppppp is the external nucleus ID (NUCID) from the ADARUN parameter, and nn in the internal NUCID assigned by Adabas. The identified member is on the system identified in the message in systemname. The specific condition is described in the message as one of the following reasons:

Review the table above for appropriate actions.

During nucleus initialization one or more existing nuclei did not indicate they had processed the ADAXCF JOIN signal. Specific information about each nonsynchronized member is given by a previous ADAX07 messages.

The synchronization query will be retried once. If all are not then synchronized, nucleus initialization will fail.

No action is required for this informational message. Review the actions for the accompanying ADAX07 messages.

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 intracluster 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 (ADARSP123). 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.

The z/OS XCF service detected an error in the status monitoring exit. Status monitoring is no longer available for this member.

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.

This message is returned by the Adabas Parallel Services messaging module ADASMM, also called the SMM facility.

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.

This message is returned by the Adabas Parallel Services messaging module ADASMM, also called the SMM facility.

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.

This message is returned by the Adabas Parallel Services messaging module ADASMM, also called the SMM facility.

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.

This message is returned by the Adabas Parallel Services messaging module ADASMM, also called the SMM facility.

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.

This message is returned by the Adabas Parallel Services messaging module ADASMM, also called the SMM facility.

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.

This message is returned by the Adabas Parallel Services messaging module ADASMM, also called the SMM facility.

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

ADASMM terminates.

This message is returned by the Adabas Parallel Services messaging module ADASMM, also called the SMM facility.

A cancel call was made without a previous successful initialization.

ADASMM terminates.

This message is returned by the Adabas Parallel Services messaging module ADASMM, also called the SMM facility.

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.

This message is returned by the Adabas Parallel Services messaging module ADASMM, also called the SMM facility.

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.

This nucleus is about to open the Work data set of the nucleus with the specified (external) NUCID. Either nucleus is starting.

No action is required for this informational message.

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 'rc' (in hexadecimal), and the system's return code is 'ssss' (in hexadecimal).This message is preceded by an ADAI62 message detailing the name of the Work data set that could not be opened.

The current operation of the nucleus fails. If the nucleus was processing a request from another nucleus to join the cluster, the session start of the other nucleus will fail.

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. If this error occurs during a session autorestart and cannot be resolved, the database must be restored and regenerated.

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

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'.

If this error occurs during a session autorestart, the database must be restored and regenerated. If in doubt, contact your Software AG technical support representative.

This nucleus is about to close the Work data set of the nucleus with the specified (external) NUCID. Either this nucleus is terminating or the other nucleus has terminated.

No action is required for this informational message.

This nucleus tried to close the Work data set of the nucleus with the NUCID 'nucid' (message ADAX34), but the close operation failed. ADAIOR issued response code 'rc' (in hexadecimal), and the system's return code is 'ssss' (in hexadecimal).

The nucleus ignores this error and continues normally. However, it is conceivable that this error may cause a subsequent error when a Work data set is being opened.

Try to determine why closing the Work data set failed, and if possible, correct the error. Consider shutting down the nucleus and restarting it to clean up any remnant of the close error.

This nucleus is reusing a Work data set (of the nucleus with the specified external NUCID) that it had already opened earlier.

No action is required for this informational message.

This nucleus has found two different Work data sets for the nucleus with the specified (external) NUCID. The message shows the name of the data set the nucleus had already opened ('old-dataset-name') and the name of the data set the nucleus was about to open ('new-dataset-name').

The current operation of the nucleus fails. If the nucleus was processing a request from the other nucleus to join the cluster, the session start of the other nucleus will fail.

Determine why the specified nucleus is associated with two different Work data sets. If the old data set name appears wrong or outdated, consider shutting down and restarting this nucleus (that printed this message).

Another nucleus in the cluster (with the specified external NUCID) could not open the Work data set of this nucleus because it had already opened a different Work data set for this nucleus. The other nucleus reported this error in an ADAX37 message and rejected the attempt of this nucleus to join the cluster. The session start of this nucleus fails.

Determine why this nucleus is associated with two different Work data sets. If the old data set name appears wrong or outdated, consider shutting down and restarting the other nucleus (that printed the ADAX37 message).

Another nucleus in the cluster (with the specified external NUCID) tried to open the Work dataset of this nucleus, but the open failed. The other nucleus reported the open error in an ADAX32 message. The session start of this nucleus fails.

Determine why opening the Work data set failed. If possible, correct the error and restart this nucleus. If this does not resolve the problem, consider shutting down and restarting the other nucleus (that printed the ADAX32 message).

Another nucleus in the cluster (with the specified external NUCID) incurred an I/O error on the Work data set of this nucleus. The other nucleus reported the I/O error in an ADAX3C message. The session start of this nucleus fails.

Determine the cause of the I/O error. If possible, correct the error and restart this nucleus. If this does not resolve the problem, consider shutting down and restarting the other nucleus (that printed the ADAX3C message).

Another nucleus in the cluster (with the specified external NUCID) found bad or unexpected data in the Work data set of this nucleus. The other nucleus reported the validation error in an ADAX3D message. The session start of this nucleus fails.

Determine whether the two nuclei really access the very same data set. This nucleus (which was starting) was accessing the data set via its DD/link-name DD/WORKR1. The other nucleus (which was already running) accessed the data set just via its name in the catalog.

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

This nucleus incurred an I/O error on RABN 'rrrr' of the Work data set of the nucleus with the specified (external) NUCID and rejected the attempt of that nucleus to join the cluster. The session start of the other nucleus fails.

Determine the cause of the I/O error. If possible, correct the error and restart the other nucleus. If the I/O error does not appear to be permanent, consider shutting down and restarting this nucleus.

This nucleus found bad or unexpected data in RABN 'rrrr' of the Work data set of the nucleus with the specified (external) NUCID and rejected the attempt of that nucleus to join the cluster. The session start of the other nucleus fails.

Contact your Software AG technical support representative.

The nucleus encountered an internal NUCID (with the specified value) that was outside the allowed range of 1-32. This is an internal error.

The current operation of the nucleus fails. If the nucleus was processing a request from another nucleus to join the cluster, the session start of the other nucleus fails.

Contact your Software AG technical support representative. If the error is reproducible, provide a nucleus dump that is taken when this message is printed (e.g., on z/OS, using a SLIP trap with MSGID=ADAX3E).

The nucleus encountered an external NUCID (with the specified value) that was outside the allowed range of 1-65,000. This is an internal error.

The current operation of the nucleus fails. If the nucleus was processing a request from another nucleus to join the cluster, the session start of the other nucleus fails.

Try to determine where the invalid NUCID value originates from. If in doubt, contact your Software AG technical support representative. If the error is reproducible, provide a nucleus dump that is taken when this message is printed (e.g., on z/OS, using a SLIP trap with MSGID=ADAX3F).

The nucleus encountered two different external NUCIDs for the same internal NUCID. The message shows the internal NUCID ('id'), the external NUCID of a cluster nucleus ('nucid1') that was to be associated with the internal NUCID and the external NUCID of a nucleus ('nucid2') already associated with that internal NUCID.

Try to determine why two different nuclei in the cluster (as per their external NUCIDs) are attempting to use the same internal NUCID (the "INTNUCID" value in the ADAN03 message). The internal NUCID is derived from the PPT. Run ADACHK PPTPRINT to check the PPT and verify that every cluster nucleus is represented in the PPT.

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

The nucleus encountered two different internal NUCIDs for the same external NUCID. The message shows the external NUCID ('nucid'), the internal NUCID of a cluster nucleus ('id1') that was to be associated with the external NUCID and the internal NUCID of a nucleus ('id2') already associated with that external NUCID.

Try to determine why the cluster nucleus with the specified external NUCID is being associated with two different internal NUCIDs (the "INTNUCID" value in the ADAN03 message). The internal NUCID is derived from the PPT. Run ADACHK PPTPRINT to check the PPT and verify that every cluster nucleus is represented in the PPT exactly once. 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 the 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 representative.

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.

A logic error occurred. An invalid token was passed to the cache disconnect function. If the disconnect is already identified as abnormal, termination continues. If not, the nucleus ends with abend S0C6.

Contact your Software AG technical support representative for assistance.

The specified value for the CLUWORK1CACHE parameter is larger than NWORK1BUFFERS+1 or LP / 20, which serve as upper boundaries for this parameter. CLUWORK1CACHE is reduced to the smaller of these two values (shown as 'xx').

No action is required for this informational message.

If you wish to make the specified CLUWORK1CACHE value effective, increase the NWORK1BUFFERS parameter to a value greater than the desired CLUWORK1CACHE value and/or increase the LP parameter to at least 20 times the desired CLUWORK1CACHE value.

The specified value for the CLUWORK1CACHE parameter, taken in units of Work blocks, amounts to more than 1% of the total size of the data elements in the global cache structure of the cluster. To limit the portion of the cache taken away from ASSO and DATA blocks, at most 1% of the total size of the data elements will be used for protection data. This amounts to the number of Work blocks shown ('xx').

No action is required for this informational message.

If you wish to make the specified CLUWORK1CACHE value effective, increase the size of the cache structure such that the number of data elements times the data element size (i.e., the total size of all data elements) is at least a factor of one hundred times the CLUWORK1CACHE value times the block size of the Work data set.

To perform a session autorestart in the course of online or offline recovery, the nucleus is using protection data from the related extension area on the Work data set of the nucleus with the specified (external) NUCID. That nucleus was running with the parameter CLUPUBLPROT=YES and had not participated in the last buffer flush prior to the nucleus failure that triggered the autorestart. In its place, another nucleus had written any missing protection data to the extension area.

No action is required for this informational message.

While recovering from the failure of one or more Adabas cluster nuclei, this nucleus encountered a Work block in the protection data extension area 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.

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 DXSTAT, 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.

Where function_name is the lock manager function name or X'xx' hexadecimal value of the function code for invalid function code; lock_type is the name of the lock type; its response code is cccccccc (in hexadecimal); and its reason code is rrrrrrrr (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 or disconnecting from 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 for connection problems and IXLDISC for disconnection problems. Common reason codes that occur due to configuration errors during connection attempts 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.

An attempt to lock a logical resource failed.

Where function_name is the lock manager function name or X'xx' hexadecimal value of the function code for invalid function code; lock_type is the name of the lock type; its response code is cccccccc (in hexadecimal); and its reason code is rrrrrrrr (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.

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.

A nucleus at a different release or maintenance level is attempting to join the cluster. If the starting nucleus is known to be incompatible with the active ones initialization fails with Parm-Error 124.

Check the Release Notes to see if this is an incompatible combination.

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.

When a cluster nucleus (nucid) running OPENRQ=NO shuts down, users who should get response code 9 (ADARSP009) may be assigned to another running nucleus. The number of users taken over (nnnnn) is reported in this informational message.

No action is required for this informational message.

When a cluster nucleus running OPENRQ=NO shuts down, users who should get response code 9 (ADARSP009) may be assigned to another running nucleus. The number of users that could not be taken over is reported in this informational message. Users may be taken over only if peer nuclei are available and able to accept new users.

No action is required for this informational message.

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 (ADARSP009), 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 (ADARSP009), 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.

Shortly before the end of an online recovery process (following the failure of a peer nucleus), another peer nucleus has terminated abnormally. The online recovery process is restarted to recover the cluster from this latest failure.

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.

Storage was unavailable for SMF.

Provide more storage and restart the nucleus.

Storage was unavailable for SMF.

Provide more storage and restart the nucleus.

A starting nucleus that is about to join an active cluster has found that its Work data set is not empty (i.e., contains protection data required for recovering from a preceding failure). It will wait until the already active nuclei in the cluster have completed the online recovery process triggered by the preceding failure.

Once this has happened, the nucleus will print message ADAX9Q and continue with the session start. If no session autorestart is in progress, the nucleus will terminate with parm-error 42, because its Work data set should be empty.

No action is required for this informational message.

The starting cluster nucleus that printed message ADAX9P has now determined that the session autorestart performed by the active cluster has completed and that its Work data set is now empty (i.e., contains no relevant protection data anymore). It will continue with the session start.

No action is required for this informational message.