DSXchange

ray.wurlod wrote:Sounds like they've changed the message (I've been on a 7.0 site for a couple of weeks). Has anyone had a response from support provider about what might cause this?
If it occurs because of client licensing, you (the administrator) can check the DS_LICENSE table to see which client machines are actually connected. This will also give you the PID of their associated dsapi_slave process (or maybe dsapi_server). So you have a more accurate idea of whom to kill. (Anyone remember Serge the Seal?)

Hi Ray,

This is not actually the license issue because we are normally facing this issue every alternate week when our open connections are getting more than 50. This error is because of the open file limit.

Error message for license limit is slightly different.

Regards
dsusr

dsusr wrote:This error is because of the open file limit.

You wouldn't happen to know exactly which 'open file limit', would you? You said it was 'somewhat related' to MFILES or NOFILES in an earlier post, hoping you could clarify that.

Interestingly enough, yesterday when the problem was occuring, there were 57 dsapi sessions on the server. We are licensed for 22 concurrent users and, as best as I could tell, there were only 20 connected. Once some folks disconnected, others were finally able to connect without receiving the error. However, there were so many left over bogus connections out there we decided to still bounce things to clear them all up. After bringing the engine down, there are usually a handful of leftover sockets in a FIN_WAIT_1 or a FIN_WAIT_2 status I have to wait to drain out... yesterday was a record high - 56 of them.

Seemed to behave better under 7.0.1 and just seems to have gotten a little worse about leaving connection remnants behind since upgrading to 7.5.1A.

I agree

I have just had this message today; version 7.5.1A on Linux.

The message (exactly) is:
ACCESS DENIED: Project currently locked.
The project is currently locked by the Administrator. Try again later or see your Administrator.

This even occurs when (as dsadm) I try to open the project Properties from Administrator client. Then the project disappears from the list in the Administrator client.

There are no jobs running and no other users on the server. I can telnet in, and list_readu says there are "No locks or semaphores active".
I can open the project with the Command button in Administrator, but not with Properties.

I am stumped. Since it's the weekend, I can not get support. Can anyone offer a suggestion? I would prefer not to restart DataStage at this time, for reasons unrelated to this problem.

Is the deadlock daemon running? If so, give it a chance to run through another cycle or two - it may clear whatever is locking the project. It may not be one of the locks visible through list_readu - there are others. If dsdlockd is not running, then invoke it manually then check its log to see whether it cleaned anything.

Thank you for speedy reply. The deadlock daemon is running; I will wait 30 minutes before checking again.

How do you know all these things?!

Everything is OK. There wasn't anything obvious in the deadlock daemon log file. I'm still stumped, but happy that the resolution was automatic, and I can use the -p option for quicker resolution (if I read the help dsdlockd -H correctly).

Thank you again for a perspicacious response!

kali wrote:How do you know all these things?!

It's the difference between 12 years of experience versus 12 weeks of experience! Plus the luck to have been a UniVerse specialist working for VMARK when they brought out DataStage and the good fortune to have been able to continue working with the product.