_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

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:

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.

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 is completed, a _SCOPE=3 lock changes its character to SCOPE = 1. If it is to be updated again, a new call with _SCOPE = 2 must be made.

You can find an example in Example: Infinite Transaction with Update

For more information, see Function Modules for Lock Requests.

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 DEQUEUEfunction 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 using the call CALL FUNCTION '…' IN UPDATE TASK. 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.

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 marked as a lock with the backup flag in the detail view of the Lock Administration (transaction SM12 ® Details).