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

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.

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

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

The OS/390 XCF transport service successfully initialized.

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

DBdddddpppppNnn

DBdddddpppppNnn

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 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 OS/390 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 OS/390 XCF messaging transport service.

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

This message appears only in the OS/390 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 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 OS/390 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.

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 dataset of the nucleus with the specified (external) NUCID, which terminated abnormally.

While recovering from the failure of one or more Adabas cluster nuclei, this nucleus tried to open the Work dataset 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 dataset that could not be opened.

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

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

• the PPT block containing the name of the Work dataset 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 dataset 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 OS/390 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:

An error occurred while disconnecting from the sysplex cache structure. 'r's identify return codes from the ADAXEC module; 'x's identify return codes from the cache structure; and '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 IXLDISC.

The nucleus held a cast-out lock on one or more cache blocks when the nucleus disconnected from the global cache. The cast-out lock has been released. This may occur during abnormal terminations.

If the nucleus is terminating abnormally, no action is required. However, if this message appears in an otherwise normal nucleus session, contact your Software AG technical support representative.

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 cache structure connected successfully; however, the attributes of the cache structure are inappropriate for the Adabas sysplex cluster.

Define the cache structure correctly in the sysplex CFRM policy.

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.

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.

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.

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.

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 IBM documentation. If the cause is not clear, notify your Software AG technical support representitive.

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

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

This message displays cache- and lock-related statistics during termination or in response to a console command issued in an Adabas cluster environment.

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.

A global parameter was changed on one nucleus in the cluster. This parameter was propagated to all other nuclei and taken over by them.

An attempt was made to change an unchangeable global parameter. This change is rejected.

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 Adabas cluster nucleus successfully connected to the specified lock structure in an OS/390 parallel sysplex environment. This message provides

• a count of lock entries; and

• the maximum number of records elements.

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 dataset identified by DD/PLOGRn. This means that the dataset 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 dataset 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 ADACOM is not running. The nucleus terminates abnormally.

Start ADACOM before starting the Adabas Parallel Services cluster nucleus.

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 start-up 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.

After a messaging failure during inter-nucleus communication that was due to an error on the receiver's side, the nucleus receiving the error indication has decided to cancel the peer nucleus causing the error. A subsequent online recovery process will recover from the forced failure of the peer nucleus.