On Jul 11, 2006, at 4:50 AM, Marc REYNES wrote:
Hello the listwhen archiving files in /etc/ dsmc outputs lots of "Retry # 1 <file_type>" whereas : - all my copygroups are set dynamic - the retried files are said to be already Sent From the Log pattern, it looks like a rollback/commit behaviour. For exemple, we have : Directory--> 4,096 /etc/foo [Sent] Directory--> 4,096 /etc/bar [Sent] Normal File--> 42 /etc/bar/pipo [Sent] Normal File--> 1 /etc/bar/notreadablefile ** Unsuccessful ** Retry # 1 Directory--> 4,096 /etc/foo [Sent] Retry # 1 Directory--> 4,096 /etc/bar [Sent] Retry # 1 Normal File--> 42 /etc/bar/pipo [Sent] ANS1228E Sending of object '/etc/bar/notreadablefile' failed ANS4007E Error processing '/etc/bar/notreadablefile' : access to the object is denied 1/ Does someone know the underlaying actions done by TSM ? 2/ For large file written directly to tape, isn't this behaviour inefficient? is it possible to commit after each file ?
Marc - A Retry occurs because something interrupted the action, where it can be: - Media not ready; have to await a mount. - File changed during the TSM operation. - A file system object accessibility issue. The "Sent" notation is misleading... Rather than meaning that the object was sent from the client to TSM server storage, it really means that the object was successfully written to the client buffer, and will be sent once the buffer is full. Simply stated, the client- server interaction occurs by Transactions, where the transaction buffer size is governed by the agreed Aggregate size. Large files are bigger than the Aggregate size, and are stored by themselves (Query CONTent F=D on a volume will have a No value for Aggregated?). A transaction interruption is painful, in that it has to be initiated all over again. TSM transaction processing is best described in the Admin Guide, and in the Technical Guide redbook for each version-release. Richard Sims
