I have had an issue restarting our database on UNIX over the weekend, when I try to restart I get the following:
%ADASTA-I-STARTUP, Database 001 starting in background
%ADASTA-I-WAITING, Waiting for database 001 to come up .%ADANUC-E-ADA072, * No space available for user in user queue
Does anyone know what this means and what I need to do to resolve
Hi David,
What is the output of adaopr dbid=1 display=uq ?
What is the content of $ADADATADIR/db001/adanuc.log ?
Best regards,
Sven
Hello Sven, I cannot get past db=1 as the database is not active
sag@reuxeuus489[Production]$ adaopr
%ADAOPR-I-STARTED, 18-JAN-2021 11:07:19, Version 5.1.6.02(01) (Solaris 64Bit)
adaopr: db=1
^
%ADAOPR-E-ADA148, * ADABAS is not active or nucleus cannot be contacted
adaopr:
adanuc.log
sag@reuxeuus489[Production]$ cat adanuc.log
%ADANUC-I-STARTED, 18-JAN-2021 10:55:09, Version 5.1.6.02(01) (Solaris 64Bit)
%ADANUC-I-CREATED, dataset NUCTMP1, file /install/SAG/ada/db001/NUCTMP1.001 created
%ADANUC-I-ARPER, performing AUTORESTART on database 1, 18-JAN-2021 10:55:10
%ADANUC-E-ADA072, * No space available for user in user queue
%ADANUC-I-SECWSTR, Writing of dump file started on 18-JAN-2021 10:55:10
%ADANUC-I-SECWFIN, Writing of dump file finished on 18-JAN-2021 10:55:11
Start writing SAGSMP dump, writing to file SAGSMP.001.10:55:09
Dump of SAGSMP finished
%ADANUC-I-REMOVED, dataset NUCTMP1, file /install/SAG/ada/db001/NUCTMP1.001 removed
%ADANUC-I-IOCNT, 64 IOs on dataset TEMP
%ADANUC-I-IOCNT, 27 IOs on dataset WORK
%ADANUC-I-IOCNT, 33 IOs on dataset DATA
%ADANUC-I-IOCNT, 294 IOs on dataset ASSO
%ADANUC-I-IOCNT, 0 IOs on dataset NUCPLG
%ADANUC-I-IOCNT, 0 IOs on dataset NUCPLI
%ADANUC-I-ABORTED, 18-JAN-2021 10:55:14, elapsed time: 00:00:05
Hey David,
as mentioned in the documentation Nucleus Response Codes (softwareag.com)
you can try to increase the NU (number of users) parameter.
When using adastart you need to add/edit “NU = <value>” in the [NUCPARMS] section in $ADADATADIR/DB001/DB001.INI where <value> should be higher than your current value / or higher than the default value of 20 if you don’t have a NU entry.
Best regards
Sven
Hello Sven,
The value was set to 30, I have changed this to 50 but am still getting the same error
Tried uping to 100 and still the same
I have just found out from our infrastructure team that there may have been some patching done on the server over the weekend, he is checking, so this may have caused the issue, potentially permissions to somewhere where it tries to create the user queue, do you know what it creates?
Apparently, our server was not part of the patching, so back to the drawing board…
The user queue is created in shared memory by the adanuc process. It is not a physical file.
Shared memory segments of Adabas can be viewed using showipc.
Adabas Version 5.1 is out of support for a long time as far as I know.
Yes it is, we are in the process of decommissioning the server but is still actively used for some things. Just ran the showipc and it returns nothing, which is what I would have expected as the server isn’t running
Is the message still the same ?
You might run into a SysV resource shortage when you increase NU.
If the message is still the ADA072 increase NU further.
I tried changing it to 100 but still no change, the system has been running for a long time and I have never seen this issue before.
You run into the issue because of
An autorestart creates internal UQs, so this may be very different from what you need for normal operation.
I have increased the NU to 200 and it appears to have started.
Great 
Once the autorestart has completed you can bring the database down and reduce NU again if you want to, then bring it back up, it’ll come up OK for sure.
Can you think of any reason why this has suddenly become an issue?
An autorestart is an unusual condition which happens when the database crashes for some reason and there are open transactions, which happens in very very rare cases, or someone pulled the plug and the database didn’t get a chance for an orderly shutdown.
Adabas keeps the previuos adanuc.log files anyway, you might find an explanation in the one for the nucleus session prior to the first one that failed.
Thank you Sven & Wolfgang, really appreciate your support 