In order to perform failsafe tests on the Adabas nucleus, ADAHAM sends a special Adabas call that tests all of the relevant stages within the nucleus. This Adabas call needs an Adabas file that contains test records. To create the FDT for this file, the environment variable ADAHAM must be set to the Adabas file number, and the following initialization command must be issued:
distributedCheck.sh initialize
In order to obtain exclusive access to the Adabas containers, the virtual instance of ADAHAM first needs to get information about their state, and then request access. This process includes unique tests, and locking the containers for registration. Access is requested with the following command:
distributedCheck.sh state
If another instance is already using the Adabas containers, the command will loop and wait until the other Adabas nucleus is no longer active. This call blocks and waits until either access is granted, or an error status is returned.
In the initial stage, the node attempts to get offline access to ADAHAM. The node wants to access ADAHAM, but the nucleus has not yet been started. Use the following command:
distributedCheck.sh notify
While the Adabas nucleus is active, the current state of the nucleus needs to be tracked asynchronously in a loop. Information about the current state is written to the file ADAHA.{DBID}. The corresponding script will return when the nucleus goes offline again (either as a result of being shut down correctly, or because of a nucleus crash). Use the following command to start the synchronization:
distributedCheck.sh sync
If the local Adabas nucleus is active, this command will update the current status of the nucleus. If the nucleus has failed or is inactive, the corresponding record in the file ADAHA.{DBID} will be updated.
The virtual instance can aquire the status of the file ADAHA.{DBID} in order to perform health checks, or to wait and track a running Adabas nucleus. Use the following command to validate the status:
distributedCheck.sh status
The corresponding exit code shows the status (see table below).
| Exit Code | Meaning |
|---|---|
| 0 | Adabas is running correctly |
| 148 | Adabas is offline |
| 101 | Init of HA |
| 102 | Adabas nucleus during AUTORESTART |
| 103 | Adabas nucleus in startup phase |
| 105 | Shutdown requested |
| 106 | Cancel requested |
| 107 | Adabas nucleus during shutdown phase |
| 108 | Adabas nucleus shutdown done, clean-up phase |
| 110 | Local ADAHAM working |
| 111 | Another ADAHAM requesting unique access to the Adabas containers |
| 200 | Registered ADAHAM or Adabas nucleus no longer working, time update fails |
| 201 | Adabas nucleus process no longer exists |
| 250 | Deadlock found |
| 251 | Structure level mismatch |
The exit code is 0 if the local Adabas nucleus is running correctly.
An exit code of between 100 and 150 can be returned if the Adabas nucleus is in a controlled startup or shutdown phase, or if it is running on a remote host. If an exit code in this range is returned, the Adabas nucleus is in a valid state, and no further action is required.
If an exit code >200 is returned, ADAHAM will force a shutdown of the Adabas nucleus and clean up the nucleus resources. After this, another instance of ADAHAM can start up the Adabas nucleus.
The ADAHAM file ADAHA.{DBID} needs to be released during shutdown. Use the following command to release ADAHAM access to the local Adabas nucleus:
distributedCheck.sh release