PARM-ERROR 023 ?????

Gang,

OK, rather a newbie here with ADABAS being dumped in our laps, got several databases that will not come up, throwing the message:

PARM-ERROR 023 DETECTED DURING SYSTEM-OPEN
ATTEMPT IS MADE TO START AN UPDATE NUCLEUS
IN PARALLEL TO ANOTHER UPDATE NUCLEUS.

And thus far no luck finding any info on this…I know this is a log-shot, but…….help please!!!

Seriously, any help would be GREATLY appreciated!!!

TK

Tom Kay
cell : 303-601-5325

I’m not a DBA, but a little more info is available in the Adabas Messages and Codes, Nucleus Startup Messages.

If you asked for access to documentation for your TechCommunity user id, then this link should get you there.

[url]http://techcommunity.softwareag.com/ecosystem/documentation/adabas/ada842mfr/messages/nucstart.htm#nucstart[/url]

Otherwise, if you have your site’s Empower password, all documentation is there as well.

If neither available at the present, here are the relevant messages:

PARM-ERROR 23
Explanation

A nucleus entry already exists in the data integrity block (DIB) for one of the following reasons:

An attempt was made to start a nucleus while another update nucleus was still active; or

The previous nucleus session terminated abnormally but the "nucleus" DIB entry was not removed.

Action

If a DIB entry remained after an abnormal termination, rerun the job with the ADARUN IGNDIB=YES parameter. If the FORCE=YES parameter had been applied, then the nucleus must be started with FORCE=YES and IGNDIB=YES. Here the DIB entry will only be removed once the ID Table initialization had been successful. Running with IGNDIB=YES alone will result in a PARM-ERROR 26.

PARM-ERROR 26
Explanation

Interregion communication could not be established.
Action

This message should be preceded by message ADAM98. If the ADAM98 error reason is “DUPLICATE ID (LOCAL)” and a previous nucleus ended such that it was not able to clean up, you may wish to restart specifying FORCE=YES. Refer to ADAM98 message documentation for information about other possible errors.

If IGNDIB=YES was specified, then the nucleus must be started with FORCE=YES and IGNDIB=YES. Here the DIB entry will only be removed once the ID Table initialization had been successful. Running with FORCE=YES alone will result in a PARM-ERROR 23.

Note:
Specifying FORCE=YES with the DBID of a currently active nucleus can disrupt operations on that nucleus. In addition, users of the old database whose ID is overwritten by the FORCE=YES option lose access to the database. Therefore, FORCE=YES should only be specified if absolutely necessary . For more information, refer to the FORCE parameter description in the Adabas Operations documentation.

I have no idea if changing the parameters is all that needs to be done, or how to tell which is the reason, an update nucleus already running, or the previous session terminated abnormally. I the latter, it seems like some type of recovery process or utility might be needed to verify or recover the database.

Utilities like ADACHK or ADAICK might tell you what state the databases are in.

Hopefully an experienced DBA or 2 will weigh in on this and provide more informed suggestions.

Good luck,
George

George,

Thanks so much for the reply sir, excellent!!!

As it turned out, our z/OS SysProg had a ‘magic’ wand that they have used over the years for D/R exercises that case situations like this!!! So, I have included that JCL below, and it worked like a charm this morning so everything is now good!!!

Thanx again for the reply!!! (:-))

TK

//ADADBS00 EXEC ADARUN,LIBRARY=DB00 Reset & Display DIB,UQA
//DDCARD DD *
ADARUN PROGRAM=ADADBS
ADARUN DATABASE=100
ADARUN MODE=MULTI
ADARUN DEVICE=3390
ADARUN SVC=241 *ADABAS 6.2.1 SVC
//DDKARTE DD *
ADADBS OPERCOM DDIB
ADADBS RESETDIB JOBNAME=‘DB00’
ADADBS OPERCOM DDIB