_SCOPE Parameter 

Definition

The application programmer uses this parameter to determine which of the two owners should actually own the lock.

_SCOPE can have the values 1,2, or 3.

Use

Two Lock Owners are created automatically for each lock. 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 possible values are listed in the table below:

Meaning of the _SCOPE Values

Value	Description
_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 (owner_2) only. Therefore, the update inherits the lock when 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.

 

For more information, see Function Modules for Lock Requests.

Example

The following diagram shows the locks during the course of an SAP LUW in conjunction 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 in place until either the relevant DEQUEUE function module is called or (as shown in the diagram) the transaction is completed with an implicit DEQUEUE_ALL.

During the course of the transaction in this example, the lock object A (which was created previously by the programmer in the ABAP Dictionary) is locked by the function call CALL FUNCTION 'ENQUEUE_A'. Since the _SCOPE parameter is set to 1, the lock A is not forwarded to the update task (it belongs to the dialog owner E_1 only) and, therefore, is released with 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. The CALL FUNCTION '…' IN UPDATE TASK generates an Update Request. At COMMIT WORK, the update task is called and inherits the locks and the update owner of locks B and C. These locks are released when the update is completed. Lock C of the dialog owner, however, may exist longer (depending on how the transaction is programmed).

Dialog locks A and C remain set until the end of the dialog transaction.

If a lock is set with _SCOPE=2, and the COMMIT WORK is called before the CALL FUNCTION ‘…‘ IN UPDATE TASK, the lock remains in place as a dialog lock until this point in time (displayed in black in the overview screen of transaction SM12). At this point in time, it is not yet possible to transfer the lock to an update work process.

Only the call of CALL FUNCTION ‘…‘ IN UPDATE TASK  and COMMIT WORK, called at a later point in time, cause the lock to be transferred to the update process.  It is then displayed in blue in the overview screen of SM12.