Inventory expiration processes on one of our TSM servers have been failing 
occasionally with no obvious explanation. We were able to get trace data for 
the most recent failure. IBM reviewed the trace data and advised us to increase 
the DB2 LOCKLIST parameter. They referred us to a technote at 
http://www-01.ibm.com/support/docview.wss?uid=swg21430874 for information on 
calculating the new value for the parameter.

The instructions in the document are puzzling, to put it politely. The document 
notes that deduplication greatly increases the need for row locks, but 
recommends the same LOCKLIST setting whether deduplication is being used or 
not. The recommended value is based on gigabytes of data moved rather than 
number of files moved. This sounds reasonable for environments with 
deduplication but is inexplicable in environments without deduplication. The 
document makes reference to "concurrent data movement". In one of the examples 
given, all incoming client data in a four hour period and all data moved by 
migration in the same period is counted as "concurrent data movement". The 
other example treats data movement spread over eight hours as "concurrent". As 
far as I can see, this makes sense only if every database transaction triggered 
by client sessions and background processes remains uncommitted until all data 
movement activity ends.

One of our clients is a 32 bit Windows file server with 18 million files on 
rather slow disk drives. The backup for this client starts in the middle of our 
intended backup window and almost always runs through the day and an hour or 
two into the next backup window. The TSM server can run for months at a time 
with at least one client session in progress at all times. The examples in the 
technote seem to imply that all data movement occurring during those months 
should be counted as "concurrent".

Is there any documentation available in which the criteria for selecting a 
LOCKLIST setting are explained more clearly?

We are currently using TSM 6.2.5.0 server code running under zSeries Linux. We 
are preparing to upgrade to TSM 7.1.1.100. We are not currently using 
deduplication. We may use deduplication for backups of databases on client 
systems after the upgrade. We don't have the CPU and memory resources to use 
deduplication for all client files.

Thomas Denier
Thomas Jefferson University
The information contained in this transmission contains privileged and 
confidential information. It is intended only for the use of the person named 
above. If you are not the intended recipient, you are hereby notified that any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply email and destroy all copies of the original message.

CAUTION: Intended recipients should NOT use email communication for emergent or 
urgent health care matters.