Hierarchy
SAP_BASIS (Software Component) SAP Basis Component⤷
BC-CTS-ORG (Application Component) Transport Organizer⤷
SCTS_OBJ (Package) CTS: Object Editing (Including Transport Objects)
Basic Data
| Data Element | OB_LOCK_MODE |
| Short Description | Lock mode of any locking mechanism |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | OB_LOCK_MODE | |
| Data Type | CHAR | Character String |
| Length | 1 | |
| Decimal Places | 0 | |
| Output Length | 1 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | Lock mode |
| Medium | 20 | Lock mode |
| Long | 40 | Lock mode |
| Heading | 55 | Lock mode |
Documentation
Definition
For the ZDM enablement it needs to be known which tables are accessed by an After Import Method (AIM). In this case it does not matter if the AIM reads from or writes to this table (read or write access).
The production usage must not overwrite any data which has been written by the upgrade (AIM).
The production usage must not change any data which has been read by an AIM already since this would invalidate the result of the AIM.
For each table it needs to be ensured if and how the table is accessible by the application during the production usage which runs in parallel to the upgrade procedure.
For each table accessed by the AIM please specify how these preconditions shall be met.
Use
The following list explains the different values which are available to define the lock mechanism for the production subsystem of each table accessed by the AIM:
Value Description
Undefined. AIM not yet ZDM enabled. Default option before AIM Analysis is completed, no classification yet available. This means that no information regarding the locking mechanism for this table is available. If at least one table of the AIM has this classification the AIM is considered as not yet ZDM enabled.
Write access to the complete table is blocked: The person responsible for the AIM confirms that the production usage running in parallel with the ZDM procedure does not write to this table. Typically, this is achieved by checking the LOCK_EU flag (global system change option in transaction SE06) or the client changeability before the application writes to the table. Or the application code explicitly checks whether a ZDM procedure is in progress by calling the FM UPGRUNT_CHECK_ZDM_RUNNING before writing to this table.
If this classification is incorrectly set, that is the production use does write to the table, then data inconsistencies or data loss will happen (with cloned tables the data written by production usage will be deleted after the upgrade).
Write access to the relevant key ranges is blocked The person responsible for the AIM confirms that the implemented lock mechanism does allow write access for production usage to the table but it prevents that production usage writes to the key ranges which are accessed (read or write access) by the AIM.
Usually this classification is applicable if persistent Enqueue set by a pre-lock method is used as lock mechanism.
Write access not blocked. Upgrade data wins. Table is not blocked for production usage, but whatever data is written in production while upgrade is running will be deleted after the upgrade procedure has finished.
At the beginning of the ZDM procedure, the ZDM procedure will create a copy of the table and of its content. The original will remain visible for the production running in parallel with the ZDM procedure and the copy will be visible to the ZDM procedure.
ZDM procedure (including the AIM) and production usage can independently from each other access (read and write) their copy of the table. But only data written by the ZDM procedure and in particular by the AIM is available after the upgrade has finished. Data written by production during the ZDM procedure will be lost.
Usually this classification is applicable for tables carrying data which must be preserved together with temporary data which can be created on the fly. Another use case would be a table holding a work lists for report generation.
This classification needs an approval by the LM department, otherwise it will lead to an error in the ZDM procedure.
Write access not blocked. Upgrade data wins. Create empty. Table is not blocked for production usage, but whatever data existed before the ZDM procedure and whatever data is written in production while the ZDM procedure is running will be deleted after the upgrade procedure has finished.
At the beginning of the ZDM procedure, the ZDM procedure will create an empty copy of the table. The original will remain visible for the production running in parallel with the ZDM procedure and the empty copy will be visible to the ZDM procedure.
AIM and production usage can independently from each other access (read and write) their copy of the table. But only data written by the ZDM procedure and in particular by the AIM is available after the upgrade has finished. Data written by production during the ZDM procedure and data which existed before the ZDM procedure will be lost.
Usually this classification is applicable for secondary data that is generated on-the-fly if it does not exist or is outdated and is stored in a DB table for performance reasons. (Caching tables, load tables)
This classification needs an approval by the LM department, otherwise it will lead to an error in the ZDM procedure.
Write access not blocked. AIM accesses only imported data. This classification is only possible under the following two prerequisites:
1. The tables is subject to R3trans import, i.e. the table is part of the transport object definition in transaction SOBJ.
2. The AIM accesses (read or write) only the key ranges overwritten by the R3trans import.
In this case it is not necessary to block any write access within the application; all data written in production while upgrade is running in the above mentioned key ranges will be lost after the upgrade.
Dependencies
Example
History
| Last changed by/on | SAP | 20141013 |
| SAP Release Created in | 740 |
