Locking of Planning area - Unscrambling Hexadecimal lock argument values

[Former Member]

Hi SCM Gurus,

I have a peculiar issue which is baffling me.

We have a requirement where during an outage program run, we are supposed to identify users who are currently editing Planning books, send a notification to them, to log out and then if the user still has not log off. Then forcefully log them off.

Now the Developer is using the Function Module ENQUEUE_READ and he is passing the Values PAREA in parameter GNAME and the Planning area name in parameter GARG. This Function Module gives the Usernames who have currently locked Planning books in Planning area given in the parameter GARG.

Just for the information PAREA in parameter GNAME signifies that we are searching for Locks on the Planning Area only, the value in GARG only signifies the EXACT name of the planning area.

The problem is that we are getting the list of users from the FM in Dev environment and not in the QA environment.

On Further investigation I found out that in the transaction SM12, the values in the column LOCK ARGUMENT are different for Dev and QA. In Dev, I am getting the name of the exact Planning Area in the said column, whereas in QA, I am getting some hexadecimal value (Scrambled Value).

That is also the reason why the FM (ENQUEUE_READ) used by the developer is working in Dev and not in QA, when he gives the value of the Planning area in the in the parameter GARG of the function module.

Is there a config in APO which can resolve this Locking issue.

NOTE: We can not use the check at the Planning Area level while defining the Planning area.

Cheers

Abhishek

[Former Member]

Abhishek,

I had the same requirements, and so do most of us, but unfortunately for some reason I have seen the FM ENQUEU_READ not giving the desired results. I know its funny, in one of my past engagements it did and in my current it doesnt I know its baffling.

Here is what I did and it worked wonderfully:

Note 1265235 - Demand Planning: Report to display LiveCache Locks

This report is perfect for your requirement in identifying users. You will have to use the same logic in your program.

If you wish to stick to ENQUEUE_READ refer to:

/people/somnath.manna/blog/2009/01/01/from-functional-to-technical--part-4

Hope this helps.

Cheers!

Abhi