_SCOPE Parameters
Definition
The application programmer uses this parameter to determine which of the two owners should actually own the lock.
_SCOPE can take the values 1, 2, or 3.
Use
At the start of an SAP LUW two Lock Owners are created. These are the dialog owner and the update owner. With this parameter you specify the owner(s) for your lock and control its behavior during the SAP LUW.
Structure
The following values are permitted:
|
Value |
Meaning |
|---|---|
|
_SCOPE = 1 |
The lock belongs only to the dialog owner (owner_1), and therefore only exists in the dialog transaction. The DEQUEUE call or the end of the transaction, not COMMIT WORK or ROLLBACK WORK, cancels the lock. |
|
_SCOPE = 2 |
The lock belongs to the update owner only (owner_2), so it is inherited by the update task if CALL FUNCTION '...' IN UPDATE TASK and COMMIT WORK are called. The lock is released when the update transaction is complete. You can release the lock before it is transferred to the update using ROLLBACK WORK. COMMIT WORK has no effect, unless CALL FUNCTION '…'IN UPDATE TASK has been called. |
|
_SCOPE = 3 |
The lock belongs to both owners (owner_1 and owner_2). In other words, it combines the behavior of both. This lock is canceled when the last of the two owners has released it. |
Since the _SCOPE parameter is a lock operation parameter, and not a property of the lock itself, the function module for an existing lock can be called again. So an update owner can be added to a lock with one dialog owner ( _SCOPE=1) by calling the function module again with _SCOPE=2. The result of these two calls is no different to a call with _SCOPE=3.
Once the update has finished, a _SCOPE=3 lock changes to a SCOPE = 1. If a new update is required, a new update with _SCOPE = 2 is needed.
More information:
Example
The following graphic shows the locks during an R/3 LUW in connection with the _SCOPE parameter. The diagram also shows how long the SAP locks are active (these are not the actual database locks, as described under SAP Lock Concept).
The lock remains as long as the corresponding DEQUEUE function module is called, or the transaction is ended with an implicit DEQUEUE_ALL (as displayed in the graphic).
In this example, the lock object A (that the programmer created previously in the ABAP Dictionary) is locked during the transaction by the function call CALL FUNCTION 'ENQUEUE_A'. By setting the _SCOPE parameter to 1, lock A is not passed on to the update process (it only belongs to the dialog owner E_1). The lock is released by the function call DEQUEUE_A, or at the latest at the end of the dialog transaction.
Later, the lock B, which belongs to E_2 (the update owner) ( _SCOPE=2), and the lock C, which has two owners ( _SCOPE=3), are requested. An update request is generated when CALL FUNCTION '…' IN UPDATE TASK is called. The COMMIT WORK calls the update process, which the locks and the update owners of locks B and C inherit. At the end of the update, these locks are released. However, lock C from the dialog owner may exist afterwards (depending on the transaction programming).
The dialog locks A and C exist until the end of the dialog transaction.
Only when CALL FUNCTION '...' IN UPDATE TASK is called and a COMMIT WORK executed, is the lock passed to the update process at a later time. It is then marked as a lock with the backup flag in the detail view of the Lock Administration (transaction SM12 Details).