Consider a situation when two users (John and Tom) have to exclusively update a global variable ^ABC.

	Transaction Processing may offer a more efficient and more easily managed solution to the issue of potentially conflicting updates. For more information, see General Language Features of M chapter of the GT.M Programmer's Guide.

At the GT.M prompt of John, execute the following commands:

GTM>lock +^ABC

This command places a GT.M LOCK on "^ABC " (not the global variable^ABC). Note: LOCKs without the +/- always release all LOCKs held by the process, so they implicitly avoid dead locks. With LOCK +, a protocol must accumulate LOCKs in the same order (to avoid deadlocks).

Then execute the following command to display the status of the LOCK database.

GTM>zsystem "lke show -all"

This command produces an output like the following:

DEFAULT ^ABC Owned by PID= 3657 which is an existing
process

Now, without releasing lock^ABC, execute the following commands at the GT.M prompt of Tom.

GTM>lock +^ABC

This command wait for the lock on resource "^ABC " to be released. Note that that the LOCK command does not block global variable ^ABC in any way. This command queues the request for locking resource "^ABC" in the LOCK database. Note that you can still modify the value of global variable ^ABC even if it is locked by John.

Now, at the GT.M prompt of John, execute the following command:

GTM>zsystem "LKE -show -all -wait"

This command produces an output like the following:

DEFAULT ^ABC Owned by PID= 3657 which is an existing process 
Request PID= 3685 which is an existing process

This output shows that the process belonging to John with PID 3657 currently owns the lock for global variable ^ABC and PID of Tom has requested the ownership of that lock. You can use this mechanism to create an application logic that adhere to your concurrent access protocols.