CA Tuesday Tip - How do I get rid of all these locks??

[Sandra_Antunes]

Hey there!

We've seen with some frequency complains about users unable to do any changes in Service Desk Manager due to locks, specially when the user or analyst just created the ticket, and cannot edit it because[i] he himself holds the lock as per the message received from SDM!!!


Sometimes, the lock gets resolved by itself some time later. Others, the analyst has to logoff and login to SDM to have the lock released.
But sure, this is not the best process to follow. It's fine to be used one, two times, but it's annoying!!!
A recycle??? It resolves, but it's a last resource option.

As a first step, the following command issued from the Primary server releases the lock:

[ bopmsg [b]<sdhostname> bpvirtdb_srvr bpvirtdb unlock <persid> Call_Req ]


The id of the ticket can be obtained from the Lock page in the Administration tab of Service Desk Manager or by issueing a pdm_extract:

pdm_extract -f"Select persid from Call_Req where id like <ticket number>"

Now that the lock had been released, how to definitely resolve the problem?
You should add the following variable to NX.ENV:

NX_SREL_BLOCKS_TIMEOUT = 30

It will release all locks on SREL table after 30 seconds.


Don't forget to proceed as per the following TECDOC to add the variable to NX.ENV file:
TEC590407 - Making Manual Changes to the NX.env and NX.env Template Files

Note at this time, a recycle in Service Desk is needed.
And it's done.

Have a great week!

Sandra :wink:

[Legacy User]

Hi Sandra,

I have a customer running r12.5 that has done all this, but they constantly get the locks on tickets resulting in some blanks screens. Regular recycle of SDM is just a NO-NO!

Any ideas on how to permanently address this and why they would get such behavior regularly?

Thanks,
Brian

[Sandra_Antunes]

Hi Brian,

In most cases, setting this variable resolves the problem.
It seems to me this customer is getting a specific behavior, other than only the locks. I would engage Sustaining Engineering on this.

Kind regards,
Sandra

[System]

Thanks for the tip Sandra! :grin:

[Anon Anon]

Won't this setting also unlock tickets that are actually in the process of being edited by other users?

[Sandra_Antunes]

frank.rumfelt wrote:

Won't this setting also unlock tickets that are actually in the process of being edited by other users?

Hi Frank,

This setting is recommended only for those hitting the specific situation described:
"...specially when the user or analyst just created the ticket, and cannot edit it because he himself holds the lock as per the message received from SDM".

In such scenario, setting this variable has been proven efficient.

If anyone faces a different behavior after setting this variable, a ticket should be opened with CA Support for further investigation.

Regards,
Sandra