ADSM-L

Re: "Retry # 1" in dsmc ouput meaning

2006-07-11 09:03:55
Subject: Re: "Retry # 1" in dsmc ouput meaning
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 11 Jul 2006 09:01:16 -0400
On Jul 11, 2006, at 4:50 AM, Marc REYNES wrote:

Hello the list

when 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

<Prev in Thread] Current Thread [Next in Thread>