Problem with the demo files

I am running Adabas 6.1.6.02 under Vista Home Premium. It has been running fine on my desktop for about four months.

Yesterday I went to start the demo database, which I had worked with just the day before. I keep the demo database pristine, no updates of any form to the demo files except for “transient” updates (and not many of them) which I promptly follow with BACKOUT TRANSACTION.

I received an error message that the startup of the database failed, followed by the following info.

Reading configuration data from C:\ProgramData\Software AG\Adabas\db003\DB003.INI

%ADANUC-I-STARTED, 04-OCT-2009 11:50:31, Version 6.1.6.02 (Windows)

|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
%ADANUC-W-LICDAYS, License will expire in 89 days
%ADANUC-W-LICDATE, License expiration date is 31-DEC-2009
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

%ADANUC-I-PARSET, setting of ADABAS_ACCESS=ALL
%ADANUC-I-PARSET, setting of AR_CONFLICT=(ABORT)
%ADANUC-I-PARSET, setting of BI=
%ADANUC-I-PARSET, setting of CLOGBMAX=4096
%ADANUC-I-PARSET, setting of CLOGLAYOUT=5
%ADANUC-I-PARSET, setting of DBID=3
%ADANUC-I-PARSET, setting of LAB=1048576
%ADANUC-I-PARSET, setting of LABX=20971520
%ADANUC-I-PARSET, setting of LBP=100M
%ADANUC-I-PARSET, setting of LPXA=10
%ADANUC-I-PARSET, setting of LWP=1000000
%ADANUC-I-PARSET, setting of MGC=50
%ADANUC-I-PARSET, setting of NCL=50
%ADANUC-I-PARSET, setting of NISNHQ=0
%ADANUC-I-PARSET, setting of NT=3
%ADANUC-I-PARSET, setting of NU=20
%ADANUC-I-PARSET, setting of PLOG=
%ADANUC-I-PARSET, setting of TNAA=3000
%ADANUC-I-PARSET, setting of TNAE=3000
%ADANUC-I-PARSET, setting of TNAX=3000
%ADANUC-I-PARSET, setting of TT=3000
%ADANUC-I-PARSET, setting of WRITE_LIMIT=0

%ADANUC-I-CREATED, dataset NUCTMP1, file C:\ProgramData\Software AG\Adabas/db003\NUCTMP1.003 created
%ADANUC-E-CREERR, Dataset NUCPLG, file C:\ProgramData\Software AG\Adabas\db003\NUCPLG.0006 could not be created
%ADANUC-E-ERRNOM, errno (17): File exists
%ADANUC-I-REMOVED, dataset NUCTMP1, file C:\ProgramData\Software AG\Adabas/db003\NUCTMP1.003 removed
%ADANUC-I-IOCNT, 64 IOs on dataset TEMP
%ADANUC-I-IOCNT, 3 IOs on dataset WORK
%ADANUC-I-IOCNT, 18 IOs on dataset ASSO
%ADANUC-I-ABORTED, 04-OCT-2009 11:50:35, elapsed time: 00:00:04

Did a Verify on the database, and that seems to suggest everything is okay.

Yes, I could delete the database and reload it from the CD. That would not explain the error, though. I am curious whether something is amiss within Adabas that might impact my two other databases, both of which still start up with no problems.

Any suggestions as to what might be wrong, and/or suggestions as to how to recover should this happen again (short of actually re-installing the database) to the demo database or the other two databases.

Thanks,

steve

Have you tried renaming or deleting C:\ProgramData\Software AG\Adabas\db003\NUCPLG.0006?

Since you don’t update the database, you also could try turning off the PLOG.

Thanks Ralph;

Turning PLOG off worked.

Which brings up the question of WHY? I did not change PLOG because the other two databases (which I do update) have PLOG turned on, and they started without a problem. Also, I had not changed PLOG since the day before; hence one day earlier the demo database started with PLOG on.

A puzzlement.

Thanks again Ralph;

steve

When Adabas starts a new session, if PLOG is set on, NUCPLG.ssss is created, where ssss is the session number. I haven’t researched where the session number is stored (registry? config file? INI file?), but somehow it was out of sync for DB3. Could it be that DB3 was not shutdown properly at the end of session 6?

Adabas thought the new session number should be 0006, but NUCPLG.0006 already existed. Now that you’ve started another session (without PLOG), I expect that you could turn on the PLOG for the next time you start DB3, because there won’t be a conflict with NUCPLG.0006.

I have had this exact issue several times on ADA614 on AIX5.3. As far as I am aware, the databases always come down cleanly but I never resolved it. However, Ralphs workaround is correct, and it does not affect the data.

This error typically occurs, after you have recreated a database or restored the database. In this case the PLOG number is reset or set to the value valid at the time of the backup. As soon as you try to start a session number, for which a PLOG still exists you get this error. Therefore you should remove the old PLOGs after a database recreation or database restore.
I have never seen before that a new PLOG was created, but the nucleus session number was not adapted accordingly. If this really happened I recommend to contact the Software AG support, because this would be a product error.