ENQUEUE_READ — Reading the enqueue lock table from ABAP
ENQUEUE_READ is a released, RFC-enabled function module that reads entries from the SAP enqueue table, the same data shown in transaction SM12. It is used to check whether a lock object, argument, or user already holds a lock, typically before attempting an update or scheduling a background job that would otherwise fail or queue behind an existing lock. It only reads locks; it does not set or remove them.
This page covers ENQUEUE_READ, the standard function module used to query the enqueue lock table programmatically instead of through SM12. It focuses on what the exceptions actually mean when swallowed, the check-then-act race condition the module cannot protect against, and how it fits alongside DEQUEUE_ALL and commit-triggered lock release.
Published 16 Sept 2026· 1,036 words
What it does
ENQUEUE_READ reads the content of the SAP enqueue table, the central structure behind lock objects and displayed interactively in transaction SM12. It is released for customer use as a programmatic alternative to opening SM12: a program can check whether a given business object, lock argument, or user already holds a lock before deciding to proceed with an update, retry later, or skip a background job that would otherwise sit queued behind an existing lock. It is a pure read operation. It does not acquire or release anything itself; setting a lock is done through the generated ENQUEUE_ function module for the relevant lock object, and releasing everything the calling program holds is done through DEQUEUE_ALL. Because the enqueue table is centralized for the system, this module is sometimes invoked over RFC against the instance that owns the enqueue server rather than called locally.
Parameters
- GCLIENT: client to filter the search on, defaults to the calling client if left blank.
- GNAME: name of the lock object to filter on; leaving it blank returns entries for all lock objects, which can be a large result set on a busy system.
- GARG: lock argument to filter on, matched against the argument string built by the calling program's ENQUEUE_ call; blank returns all arguments for the given object.
- GUNAME: user name to filter on, useful for answering whose locks these are without going through SM12's own filter screen.
- NUMBER (export): the count of lock entries found and returned in the table.
- ENQ (tables parameter): output table of lock entries, one row per active lock, structured like the SM12 display line with lock owner, transaction, program, lock object name, lock argument, and lock mode.
Exceptions
- COMMUNICATION_FAILURE: the call could not reach the enqueue server, most often because it was routed over RFC to an instance that is down, restarting, or unreachable. If this is caught and ignored, the caller ends up treating an unanswered question as a negative answer, i.e. it proceeds as if no lock exists when in fact nothing was actually checked. That reintroduces exactly the collision the lock mechanism exists to prevent.
- SYSTEM_FAILURE: an internal failure on the enqueue server side while assembling the answer, for example the request being rejected. Like COMMUNICATION_FAILURE, this must be treated as an inconclusive result, not as evidence the object is free. Any code path that swallows either exception without aborting or retrying the check is effectively disabling the safety net the lock check was added for.
How to call it safely
Call it with GNAME set to the specific lock object and GARG built exactly the way the corresponding ENQUEUE_ module would build it, rather than leaving both blank, to avoid pulling the entire lock table across the system. Check the exceptions before touching NUMBER or ENQ; a non-zero SY-SUBRC or a raised exception means the result is not trustworthy and the calling program should not infer that the object is unlocked. Loop the ENQ table to inspect the owning user, transaction, or program when a lock is found, and remember that between this read and any subsequent attempt to set the actual lock, another process can still acquire it first; ENQUEUE_READ gives a snapshot, not a reservation.
ECC vs S/4HANA
ENQUEUE_READ is part of the core enqueue infrastructure and continues to work unchanged on S/4HANA; SM12 remains the interactive front end backed by the same mechanism. There is no known dedicated released successor API specific to S/4HANA for reading arbitrary lock entries. It is a read-only module and generally considered low risk to call from custom code in classic extensibility scenarios, but its clean-core status for restricted or public cloud ABAP environments is not confirmed and should be checked against the current released API list before relying on it there.
Common pitfalls
- Treating an empty ENQ table as proof the object is free without first confirming the call did not raise COMMUNICATION_FAILURE or SYSTEM_FAILURE; a failed call and a genuinely free object look identical if exceptions are not checked.
- Calling it with GNAME and GARG both blank on a live system, pulling back a large lock table and adding load to the enqueue server for a check that only needed one specific object.
- Using the result as a substitute for actually setting the lock: checking that an object is free and then updating it without calling the real ENQUEUE_ module first leaves a window where another session can grab the lock in between, producing the same collision the check was meant to avoid.
- Assuming GARG matching is a partial or wildcard match when it needs to match the argument string built by the generating lock object exactly, causing existing locks to be missed silently.
Whose problem this is
The enqueue table itself and its monitoring through SM12 belong to Basis. Custom code that calls ENQUEUE_READ and acts on its result belongs to the development team that owns the calling program. When the module returns wrong or stale-looking results, first rule out an enqueue server problem with Basis (instance down, RFC destination misconfigured); when the symptom is a missed lock followed by a data collision, the fix belongs in the application's exception handling and check-then-act logic, not in Basis.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/enqueue-readERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.