enqname

[Former Member]

Hi,

I am receiving "system lock errors", "error locking table TBTC0" and "lock table overflow (in the joblogs).

I increased the enque/table_size to 100000

and enque/server/max_requests to 2500

on the enque server

But I notice when I go into SE38 - RSPARAM on my app servers I am seeing a user defined setting for rdisp/enqname for the app server rather than the enq server name. Which is making me think that the app servers are trying to use the settings defined in their instances (which is default since they are not set). I have updated the default.pfl with the rdisp/enqname set to the CI (which is our enq server) but I am still seeing the user-defined value of the app servers rather than the CI when I check RSPARAM on the application servers. How do I set this to point to the CI if not in the default.pfl.

By the way, it is not defined in the instance profiles of the app servers and the system default value is showing the correct value.

Maybe I'm just reading RSPARAM wrong, but if my system was using the default values on the app servers that would explain the overflows.

Any thoughts,

Lee

[Ayax · Accepted solution]

Hello Lee,

Even though you can see it in rsparam report as a user defined value the rdisp/enqname takes its value from the server list that receives from the message server, there is nothing wrong with the parameter and do not worry about the instance not taking the appropiate value.

Regards,

Ayax

[Former Member · Accepted solution]

Ayax,

Thanks for that input. A little further investigation and I found that in SM12 - diagnosis I'm seeing an error that states: Lock server exists, but is not addressed.

I checked my default.pfl and I see the my rdisp/enqname may be incorrect. I am now going to adjust the profile with the correct enqname and recycle the server.

I'll let you know if that resolves it or not.

Lee

[Ayax · Accepted solution]

Usually there is no need to change rdisp/enqname and I do not think is a good idea to change it, what value does it currently have? It must be hostname_SID_SystemNumber.

Regards,

Ayax

[Former Member · Accepted solution]

In my default.pfl it is set to prdpe1-ci_PE1_01. Which seems right according to what you are saying. But all my app severs are getting an error when I go to SM12 and do extras diagnosis. The error says "Lock server exists, but is not addressed".

On my enqueu server I get two errors when I run diagnosis:

Error: Local lock management process despite external lcok managment

and

Error: System contains more than one lock management prdpe1-ci_PE1_01

Any ideas what could be causing these errors?

Lee

[Ayax · Accepted solution]

Try deleting rdisp/enqname from default profile, appropriate value will be taken.

Regards,

Ayax

[Former Member · Accepted solution]

Ayax,

Our original default.pfl did not have the rdisp/enqname in it, so I don't think the default values are working right. It could just be that the enqname is not related to the errors I am seeing. But It definetly looks like I am getting the local instance profile default values. I'm wondering if I should set the enq/table_size setting in the instance profiles to see if that will resolve my overflows.

Lee

[Former Member · Accepted solution]

One other thing. Do you have to set the enq/table_size in the instance profiles. Right now, I have that only increased in the CI (enq server).

Lee

[Ayax · Accepted solution]

Check SM51, is there more than one server with enqueue service?

Also execute tcode SICK to verify installation.

Regards,

Ayax

[Former Member · Accepted solution]

only my CI has the enqueu in SM51. Sick comes back clean. I noticed in SM12 - extras - statistics that my maximum number of lock entries never goes above 3603. I would figure that would change with the amount of locks that are going on.

Even on my CI (Enque server) that number is always at 3603. That seems odd. On my BI environment this number grows.

Lee

[Former Member · Accepted solution]

I've lowered my enque/table_size to 25000 to see if the size of the table matterred... but it did not help.

My dev_enqwork log is showing

[Thr 1094719840] ***LOG GEA=> [enxxmenq.h 1904]

[Thr 1094719840] ***LOG GZZ=> EqSetCluster(); rtc=16 [enxxmenq.h 1905]

[Thr 1094719840] *** ERROR => EqSet1(): GetFreeArg() failed, ArgTable overflow [enxxmenq.h 951]

with every oveflow....

Also, I still never see my SM12 - extras - statistics a value for Maximum number of lock entries excede 3603. Which bothers me. Does anyone know what contrals that growth in statistics?

I'm thinking my system does not have enough memory or the locking table has something wrong with it. But I can not find any clear errors to point me in either direction.

Anyone have any additional advice they think might help debug this problem?

Lee

[Ayax · Accepted solution]

What is odd to me and to what I would give priority are the messages that you get when you run the diagnosis:

Error: Local lock management process despite external lcok managment

and

Error: System contains more than one lock management prdpe1-ci_PE1_01

Have you raised an OSS message with SAP Support?

Regards,

Ayax

[Former Member · Accepted solution]

Thank you for the input. This problem is now solved. The problem was that the table_size parameter was not being picked up. That parameter needs to be in the ASCS instance profile. If you put it in the Default profile or the systems instance profile it is not used.

Lee

[Former Member · Accepted solution]

Hi,

More than one lock management means there would be an enque process on the CI node. Please check in SM50 of all the servers to see if there are any.

Regards,

Sree