This may be true, although I didn't correlate until I read this.   
We had log pinning problems periodically for several years, but they stopped 
happening at some point even though we are still on 5.5
I assumed they refreshed the slow Windows (100mbit) clients.   Thinking back, 
this was around the time we switched to data domain and sequential-file device 
classes.


Regards, 
Shawn
________________________________
Shawn Drew

> -----Original Message-----
> From: ADSM-L AT VM.MARIST DOT EDU [mailto:ADSM-L AT VM.MARIST DOT EDU]
> Sent: Monday, May 13, 2013 9:46 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] 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.


This message and any attachments (the "message") is intended solely for 
the addressees and is confidential. If you receive this message in error, 
please delete it and immediately notify the sender. Any use not in accord 
with its purpose, any dissemination or disclosure, either whole or partial, 
is prohibited except formal approval. The internet can not guarantee the 
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) 
not therefore be liable for the message if modified. Please note that certain 
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.