DEQUEUE_ALL — DEQUEUE_ALL Function Module Reference

DEQUEUE_ALL is a standard, released function module that instructs the enqueue server to remove all lock entries owned by the calling user context, without regard to which lock object or table those entries belong to. It exists for situations where a program needs to guarantee a clean lock state without tracking the exact set of individual locks it set, such as generic error recovery or end-of-dialog cleanup in older custom code. It is callable directly from ABAP and is part of the standard runtime; it is not a generated lock-object function module and does not target a single business object. Because of this breadth, it is meant as a last-resort cleanup mechanism, not the normal way to release a lock that a program itself acquired deliberately.

The interface takes only importing parameters, all optional with defaults, and returns nothing.

DEQUEUE_ALL exposes no EXCEPTIONS in its interface at all. This is not an oversight to work around; dequeue operations in the SAP lock concept are designed as fire-and-forget requests to the enqueue server, so there is nothing for the caller to catch. The practical consequence is that sy-subrc after the call is always zero, independent of whether any locks were actually held, whether the enqueue server was reachable, or whether the removal has physically completed by the time control returns. Code that checks sy-subrc to decide whether the cleanup 'worked' is checking a value that carries no information. The real failure mode is silent: a call can appear to succeed while locks are still visible to other work processes for a short window, or while locks the caller assumed were theirs were never touched because the scope or session context did not match what was expected.

Call it with explicit scope rather than relying on the default when the intent is narrower than 'release everything this session holds'. After the call, do not test sy-subrc; instead verify the actual lock state directly if the outcome matters, by checking the enqueue table for the specific object the program cares about. If the code path depends on the lock being gone before the next statement executes, pass _SYNCHRON as active rather than leaving the request queued, since the default asynchronous behaviour only guarantees the request was sent, not that it has been processed.

DEQUEUE_ALL remains available on S/4HANA as part of the kernel-level enqueue/dequeue function module set; it has not been deprecated or replaced by a named successor. It sits outside the clean-core extensibility model in the sense that direct calls to generic lock-management function modules from custom code are discouraged in favour of letting locks fall away naturally at commit or rollback, or dequeuing through the specific generated function module tied to the lock object that was used to set the lock in the first place.

The application developer who added the explicit call owns the consequences of what gets released and when. Basis gets pulled in when investigating enqueue table contents during a lock-related incident, typically via the standard lock display transaction, but the decision to call DEQUEUE_ALL rather than a targeted dequeue is a design choice made in custom or inherited ABAP code, and fixing a misuse means changing that code, not tuning the enqueue server.

Works against the same central lock table that the generated ENQUEUE_ and DEQUEUE_ function modules for specific lock objects operate on, and against the same scope and collect logic described by the RSTFC-based parameters used across the enqueue interface. Lock entries it releases can also be inspected through the standard lock-display transaction (SM12) when diagnosing whether a call actually cleared what it was expected to clear.