ADARAI Utility Messages

ADARAI RECOVER was invoked for a database where the Delta Save Facility was active. In order to run correctly, ADARAI must know the DSIM device type and size of the DSIM data set. This could not be established using the RLOG and the parameters were not provided to ADARAI; therefore, ADARAI operation cannot continue.

Specify the DSIMDEV and DSIMSIZE parameters to ADARAI.

The skeleton job control for the job-control step in the supplied skeleton job control contained a keyword place holder. This placeholder is not permitted in the job-control step.

Modify the `job-control' step in the skeleton to remove the `keyword' placeholder specification.

The skeleton job control for the job-control step in the supplied skeleton job control contained two or more keyword placeholders prior to the next step. Each placeholder should only be specified once in each job control step in the skeleton; otherwise, ADARAI cannot determine which one to use.

Modify the `job-control' step in the skeleton to only specify the `keyword' placeholder once.

The skeleton job control for the job-control step in the supplied skeleton job control did not contain the keyword placeholders anywhere prior to the next step. In order to insert the correct replacement data in the appropriate place in the skeleton, the keyword placeholder must be provided at some point in the job-control skeleton.

Modify the `job-control' step in the skeleton to include the 'keyword' placeholder specification.

The file number file-number is greater than the maximum permitted for the database.

Supply a valid file number and rerun the job.

The ADARAI RECOVER DRIVES parameter was set to drives, however, the original save job was originally run with DRIVES=original. The DRIVES parameter specified for ADARAI RECOVER must be equal to, or less than the original DRIVES parameter. ADARAI ignores the specification and uses the original DRIVES parameter.

Modify the DRIVES parameter to use a valid value.

The file is not known to the recovery log (RLOG). If the file was created by an ADADBS operation, the required checkpoint was not included in the checkpoint file, and the RLOG has no record of the change.

Supply correct file numbers and rerun the job.

The RLOG is from a version of the recovery aid prior to version 7.1, but the newer Adabas recovery aid requires an RLOG created by the updated ADARAI PREPARE function.

Run the ADARAI PREPARE function to convert the RLOG.

Supply a valid RLOGSIZE parameter and rerun the job.

Supply a valid MINGENS parameter and rerun the job.

The input parameter list does not contain a valid pattern string for the JCL to be generated.

Supply a correct JCL/JCS pattern and rerun the job. See the Adabas Utilities documentation for the syntax description.

The value is either greater than MINGENS - 1 or, for a Recovery operation, points to a nonexistent generation.

Supply a valid RELGEN parameter and rerun the job.

The Adabas nucleus is not up. ADARAI called the user exit 2 (dual log processing) or user exit 12 (multiple log processing) to submit a job to copy pending data from a protection log. ADARAI waited for the copy to complete; however, the copy did not complete in the time that ADARAI was waiting.

The Adabas nucleus was called with a FEOFPL command to close and copy the current dual or multiple protection log. ADARAI waited for a copy to be submitted and completed as a result of this command; however, the copy did not complete in the time that ADARAI was waiting.

The only acceptable response is 148.

Shut down the nucleus and rerun the job.

Increase the size of the partition GETVIS and rerun the job.

See the IBM POWER Installation and Operations Manual for corrective action. Then rerun the job.

Contact your Software AG technical support representative.

Check the return code for CDLOAD for corrective action and rerun the job.

Check the return code for CDLOAD for corrective action and rerun the job.

Check the return code for SUBSID for corrective action and rerun the job.

Check the return code for GETVIS for corrective action and rerun the job.

Contact your Software AG technical support representative.

Contact your Software AG technical support representative.

Contact your Software AG technical support representative.

Supply a correct JCL/JCS input and rerun the job.

ADARAI was not able to LIST or RECOVER a generation because the generation is either erroneous or restricted.

Determine the reason for the problem, correct it, and rerun the job.

ADARAI was unable to run because of the problem indicated by the Adabas nucleus response code rc and, if relevant, the subcode sc

See the Adabas response code/subcode descriptions.

The RLOG is in an invalid state for PREPARE. If the RLOG is in use, issue an ADARAI REMOVE for the RLOG. If this is a new RLOG, it must be formatted before running ADARAI PREPARE. The RLOGSIZE defined using ADARAI PREPARE must be the same as that previously defined by the SIZE parameter of the ADAFRM RLOGFRM function.

Use ADARAI REMOVE to deactivate the RLOG, or ADAFRM RLOGFRM to reformat the RLOG before running ADARAI PREPARE.

The generation used to generate the job had a status other than "normal". This indicates that ADARAI determined at some time during the creation of the generation that the job it would generate could not run without changes by the user.

Determine the reason for the status and modify as appropriate. When the generation is "restricted", a later message indicates where the generation actually became restricted. Generally, such jobs run successfully with intervention. If the generation is "erroneous", it is impossible to know what caused this during the recovery phase; therefore, you must determine what caused the problem and correct it in the recovery job if possible and appropriate.

The generation being recovered has no full save data set associated with it. This should only occur for the first generation allocated by default after the RLOG is prepared.

Determine the last full save data set prior to the generation and insert a step to restore this prior to using the generated recovery job. Any steps that took place between the time the full save was taken and the RLOG became available must also be inserted here to insure that the recovery job runs and that the resulting data is valid.

During the generation of the recovery job, ADARAI determined that it needed the range of PLOG blocks listed in the message; however, these PLOG blocks were not recorded in the generation being recovered. This may occur if the generation was restricted, or a PLCOPY step to copy a PLOG failed to record its execution on the RLOG data set. When it is nonzero, a cluster nucleus ID is appended after the low and high PLOG block number.

Determine the PLOG on which the range of blocks is located and add this data set to the job at the appropriate point as identified by the location of the message.

This identifies the point in the recovery job at which the generation became "restricted" and the reason why it was restricted. With user intervention, it should be possible to handle the reason for the generation becoming restricted and thus to enable the recovery job to successfully recover the database.

Take appropriate action to handle the reason for the restriction.

ADARAI encountered an off-line utility execution at a point where a session start record was found but no session end record was found. This indicates that the nucleus session terminated abnormally prior to the off-line utility being executed. This means that ADARAI cannot determine precisely what the last PLOG block of that session was and can only attempt to include all PLOG blocks it knows about for that session.

Ensure that all PLOGs for that particular session are provided to the REGENERATE prior to the utility step about to be executed. Additional PLOGs for the session, not known to ADARAI, can be added at the end of the DD/SIIN statement.

A RESTONL request was encountered that is normally followed by a RESTPLOG entry indicating the PLOGs that must be provided to the RESTONL for it to complete successfully. In this case, no RESTPLOG entry could be found relating to the RESTONL function that was encountered. Under normal circumstances, this can only occur if the RESTONL function fails during the PLOG processing stage and the RESTPLOG is not repeated stand-alone.

Determine if the RESTPLOG was in fact successfully issued but not recorded on the RLOG. If so, the appropriate PLOGs can be added to the RESTONL step based on the information in the RESTPLOG job itself.

While building the recovery job, ADARAI encountered a utility operation that was run online; however, no preceding nucleus sessions start record was encountered. This can only occur if the generation is "restricted" or the session start logging to the RLOG failed.

If there is no reasonable explanation why this occurred, contact your Software AG technical support representative.

Under normal circumstances, a RESTPLOG request is only encountered in association with a RESTONL utility operation. In this case, a RESTPLOG was encountered for the PLOG blocks identified with no preceding RESTONL request. When it is nonzero, the cluster nucleus ID is appended after the block number.

Determine how the RESTPLOG entry occurred at that point and determine if the recovery job will run successfully without that step.

While building the recovery job, ADARAI detected one or more errors that have rendered the generated recovery job not executable.

Correct the errors identified earlier in the job and run the job if it can be successfully repaired based on the errors that have occurred.

The ADARAI data collection mechanism was notified that the step prior to this message was preparing to complete its processing; however, a `commit' record was not written for the utility execution indicating that either it did not run to completion or the commit record could not be written.

Determine the reason for the failure to complete the information on the RLOG. If the recovery job can run successfully without the failing step, remove the step completely from the recovery job. If required, make the appropriate corrections to the job step.

During its PLOG validation processing, ADARAI checks to see whether the PLOG session numbers it encounters are in sequential ascending order (e.g., PLOG 8 follows PLOG 7, PLOG 7 follows PLOG 6 and so on). When it encounters a situation where this is not the case, this message is issued identifying the range of `missing' PLOGs. This can occur when online saves are used. When it is nonzero, a cluster nucleus ID is appended after the session number.

During optimized ADARAI RECOVERY processing, a deleted file may simply not figure in the recovery job itself. This message is issued to register the fact that the file number `file' was deleted during the generation being recovered.