Clearing in previous year

[Former Member]

Hi there

I have an issue in resetting (using FBRA) clearing GL document which belongs to 2007. This clearing doc has few line items, which were generated while clearing other GL docs .

While I thought it might be due to a closed period, I tested in my Quality system and I could reset clearing documents(which has no line items) for last year(opened posting periods). In the same Quality system I am NOT able to reset few clearing documents, and the error is "System lock error: Inform system administrator" Message no. F5288.

Can any body through advice on this issue.

Many thanks in advance

MSJ

Edited by: MSJ on Sep 24, 2008 4:45 PM

[Former Member · Accepted solution]

Go through the OSS note 13907 and ask your basis team to look into the issue:

Reason and Prerequisites

The lock table has overflowed.

Cause 1: Dimensions of the lock table are too small

Cause 2: The update lags far behind or has shut down completely, so that the lock entries of the update requests that are not yet updated cause the lock table to overflow.

Cause 3: Poor design of the application programs. A lock is issued for each object in an application program, for example a collective run with many objects.

Solution

Determine the cause:

SM12 -> Goto -> Diagnosis (old)

SM12 -> Extras -> Diagnosis (new)

checks the effectiveness of the lock management

SM12 -> Goto -> Diagnosis in update (old)

SM12 -> Extras -> Diagnosis in update (new)

checks the effectiveness of the lock management in conjunction with updates

SM12 -> OkCode TEST -> Error handling -> Statistics (old, only in the enqueue server)

SM12 -> Extras -> Statistics (new)

shows the statistics of the lock management, including the previous maximum fill levels (peak usage) of the partial tables in the lock table

If the owner table overflows, cause 2 generally applies.

In the alert monitor (RZ20), an overrunning of the (customizable) high-water marks is detected and displayed as an alert reason.

The size of the lock table can be set with the profile parameter "enque/table_size =<size>". <size> specifies the size of the lock table in kilobytes. The setting must be made in the profile of the enqueue server ( ..._DVEBM.. ). The change only takes effect after the restart of the enqueue server.

The default size is 500 KB in the Rel 3.1x implementation of the enqueue table. The resulting sizes for the individual tables are:

Owner table: approx 560.

Name table: approx 560.

Entry table: approx 2240.

As of Rel 4.xx the new implementation of the lock table takes effect.

It can also be activated as described in note 75144 for the 3.1I kernel. The default size is 2000 KB. The resulting sizes for the individual tables are:

Owner table: approx 5400

Name table: approx 5400

Entry table: approx 5400

Example: with the

"enque/table_size =32000" profile parameter, the size of the enqueue table is set to 32000 KB. The tables can then have approx 40,000 entries.

Note that the above sizes and numbers depend on various factors such as the kernel release, patch number, platform, address length (32/64-bit), and character width (Ascii/Unicode). Use the statistics display in SM12 to check the actual capacity of the lock table.

If cause 2 applies, an enlargement of the lock table only delays the overflow of the lock table, but it cannot generally be avoided.

In this case you need to eliminate the update shutdown or accelerate the throughput of the update program using more update processes. Using CCMS (operation modes, see training BC120) the category of work processes can be switched at runtime, for example an interactive work process can be converted temporarily into an update process, to temporarily increase the throughput of the update.

For cause 3, you should consider a tuning of the task function. Instead of issuing a large number of individual locks, it may be better to use generic locks (wildcard) to block a complete subarea. This will also allow you to considerably improve the performance.