We've had some really nasty logpin issues as well....since I don't remember the 
particulars with great clarity, here's my notes:

possible causes:
  - backups that span more than one tape; the pin occurs at the time the first 
tape starts to rewind and another tape is needed
  - BACKUP IMAGE operations that span more than one tape (similar to above)
  - Data Protection for * products, typically with large transactions that pin 
the log until the transaction is committed
  - TSM V6.2 b/a client used to back up system state on Windows 2008, Windows 
2008 R2, Windows 7 and  Windows Vista
  - Other reasons

possible solutions:
  1) TXNGROUPMAX and TXNBYTELIMIT
  2) Extending activity log, to increase available space
  3) THROUGHPUTDATATHRESHOLD and THROUGHPUTTIMETHRESHOLD options
  4) Balance the load between the two TSM servers
  5) Prevent possible conflicts between sessions and processes
  6) SHOW LOGPINNED & LOGPINNED CANCEL commands
  7) Move the client backup schedule

My notes say it's fixed in V6.

Our case was aggrevated by not having a lot of drives; sometimes more than one 
client was trying to hog the log, and everything starts to sloooowly circle the 
drain -- space reclamation and migration start feeling the pain, etc.  In our 
case, I absolutely had to get them off writing directly to tape.  Life got 
better after that.

Hope that helps.

-----------------------

Date:    Mon, 13 May 2013 09:46:11 -0400
From:    Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM<mailto:rrhodes AT 
FIRSTENERGYCORP DOT COM>>
Subject: Log pinning, transactions, and sequential media

Hi Everyone!

Environment:  TSM server v5.5.6

We've been fighting log pin issues for some time.  They are being caused by 
folks installing Windows servers at remote sites that have slow data circuits.  
Many of these servers are trying to backup big files, which pin the log for 
long stretches of time.  We are working to set excludes, break up big files, 
etc, etc.

As our team lead was reading up on log pin issues and came across document
http://www-01.ibm.com/support/docview.wss?uid=swg21584401

It makes the following statement:

>2. Sequential media should be used for large files:
>Any node storing large files should be sent directly to sequential
>media
- tape or file device classes. When using >sequential media a transaction is 
not sent until the transaction completes or when the object spans to the next 
>volume. This can reduce and in some cases eliminate the total pinning time for 
a long running transaction >compared to a disk device class. In comparison, 
backups to disk storage pools immediately pin the recovery log. >To further 
exacerbate the problem, backups to disk storage pools require more unique 
transactions compared to >backups to sequential media. Reducing the length of 
time that a long running transaction is pinning the log and >the number of 
transactions helps to reduce the likelihood of log exhaustion.

Is this really saying that when using sequential media TSM doesn't create a 
transaction for a file until it has FINISHED being sent (or change to a next 
volume)?

Is this also true when sending a file to a diskpool with a Max Size Threshold, 
where the file exceeding that size limit is sent directly to the nextpool and 
the nextpool is of type FILE.



Thanks

Rick




-----------------------------------------
The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.