T-code SMENQ - replacement for SM12

Within SAP Basis component (ABAP Platform is its new name, not NetWeaver ApplicationServer ABAP Stack anymore) that runs underneath of S/4 systems installations there is a new SAP enqueue server called SAP Standalone Enqueue server 2 available. It was developed to ensure high availability architecture. It comes within ABAP Platform 1809 version. It is a successor to the standalone enqueue server. It is a component of the SAP lock concept and manages the lock table. This principle ensures the consistency of data in an ABAP system.

As a consequence an old t-code that are used to manage locks in the system were refreshed. Some of them are obsolete for long time – such as t-code SM12OLD. Newer ones like RS12 or SM12 are still available but they should not be used. There is more advanced t-code called SMENQ available. It is used for same activities as  old ones – to monitor and administer the server.

More information:

Difference between transactions RS12 / SM12 ?

How to find out SM12 entries...?

BW jobs/work processes hanging within program SAPLSENA

Standalone Enqueue Server 2

BW jobs/work processes hanging within program SAPLSENA

BW system may face a strange situation where there are many jobs or work processes hanging and obviously doing nothing. They are called zombie processes and then hanging with ABAP programs like SAPLSENA, SAPLRSSM, SAPLRSSM_LOAD, SAPLRS_G or SAPLRS_GENERAL etc. During situations like this the BW systems gets slower, loads are not being finished etc. In addition, an unusual number of locks may be observed in t-codes like SM12. Issue is that the system entered into dead lock. One may try to kill those work processes manually in t-codes like SM66, SM50 or killing jobs in SM37. However, it will not help as they start to pile up again quite soon.

Generally speaking; a reason why the system entered into such a state is that massive run of parallel delta loads caused a long wait time of locks. This can be also observer in table RSREQDONE field LOCKWAIT and in tables RSREQDONE or RSICCONT. Other symptom can be that infoproviders involved within the data loads are carrying heavy numbers of requests. Consequently, an enqueue management of the load request administration is not up to date.

To prevent such a situation the key is to have the enqueue management of the BW system always up to date. There are many points to be considered in order to achieve this. They mostly vary on BW version. But generally speaking parallel delta loads need to be kept on reasonable level same as the number of requests in the administration of the infoproviders are to be kept reasonable.

For details per particular BW version see SAP Note 1827854.

More information:

1827854 - Enqueue/Lock during parallel data loads

653996 - Analysis of lock situations

Locks set in BW system by BEx tools

When BW query is opened in BEx Query Designer similarly to when the BW query runs in BEx Query Analyzer there are a locks set in the BW system. There is a reason for that.

Each query is represented by generated ABAP report GP* that executes data selection from BW server to the query. We can compare the generated ABAP report as runtime processing of this BEx query. The lock is set while the ABAP report is generated.

Locks by BEx QD:

Lock by query run:

Normally the locks are not observed by regular BW user runing the query. However in the case that several users are running the same query there can be a message shown like following:

Object requested is currently locked by user (MC601, MC 601)

Every change to the query triggers it regeneration. More complex the query is more time it requires to regenerate. You can manually regenerate the query in t-code RSRT or via ABAP report RSR_GEN_DIRECT_ALL_QUERIES.

More information:

wiki

How to find out SM12 entries...?

Transaction SM12 is very useful also in BW. The SM12 is about the locks. By the locks in SAP system data integrity is guarded.  In case one user is changed an business objects an attempt to change the same objects is rejected by the system because the lock was already set for object for the first user. So basically only one process or one user is allowed to change the business object at same time. This functionality in SAP is called SAP lock/enqueue handling.

Speaking of BW just remember in case of planning application how many time we have to remove lock entries to enable user save the data while particular row was locked by other user some time ago and it wasn’t removed.

Well but what to do in case an access to t-code SM12 is not granted for some reason and simply user is not authorized to run the t-code. Actually there is no table which stored these locks. The locks are managed on operating system level. What the system does while we run the SM21 is that FM ENQUE_READ2 is running. The FM executes following ABAP statement:

  CALL 'C_ENQUEUE' ID 'OPCODE'    FIELD 'Q'

                   ID 'OPCODE2'   FIELD OPCODE2

                   ID 'ENQTABLE'  FIELD ENQ-*SYS*

                   ID 'GRANULE'   FIELD GRANULE

                   ID 'ARG'       FIELD GARG

                   ID 'UNAME'     FIELD GUNAME

                   ID 'CLIENT'    FIELD GCLIENT.

This means a command on operating system level, so called C-function (as ABAP interpreter is written in C/C++). Name of C function in this case is 'C_ENQUEUE'. Conclusion is that w/o access to the t-code SM12 it is not possible to find out what are current locks set in the SAP system.