Hi Andy,

I agree that TSM should report a failure when a file identified as a
candidate for backup is not able to be backed up.  What I have a problem
with is that in ADSM v2.x and v3.x the files were backed up as they were
identified.  Once we went to ADSM v4.x and now TSM v5x it seems to have
adopted the dump methodology whereby it will examine a large number of
files (I'm truly not sure if it's hitting a directory at a time, a
filesystem at a time or a certain number of files) then come back to back
them up later.  Since I don't have the opportunity to quiesce my
filesystems I'm guaranteed to have a large number of failures and invest a
good amount of my engineers time in investigating a situation that never
should have occurred.  Essentially my complaint is not that TSM reports
failures, my complaint is that TSM fails to backup files when it should
not.  Like ADSM2, ADSM3, tar, pax, afio et al, it should take the file when
it is identified, not wait until it's programmatically convenient.
Advising users to simply exclude any files or filesystems where some of the
files tend to turnover rapidly is not realistic in a large environment of
diverse server configurations managed by a lean staff.

Regards,
Chuck




                      Andrew Raibeck
                      <storman AT US DOT IBM.C        To:       ADSM-L AT 
vm.marist DOT edu
                      OM>                      cc:
                      Sent by: "ADSM:          Subject:  Re: DSMC Exit Code 
Question
                      Dist Stor
                      Manager"
                      <[email protected]
                      .edu>


                      06/27/2003 01:19
                      AM
                      Please respond to
                      "ADSM: Dist Stor
                      Manager"






There is no way to modify TSM behavior as you describe. In fact, your
statement about excluding the files is exactly one of the reasons why TSM
behaves as it does: so you can evaluate the reasons for the missed files,
and take the necessary actions. We feel that it is better to flag the
backup with an RC 4 and let you decide that you don't need backups for the
particular files, than to flag the backup with an RC 0, only to discover
after it is too late that you really needed the backups (in which case,
you'd probably be asking why TSM didn't warn you that it couldn't back up
the files).

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Andy Carlson <andyc AT ANDYC.CARENET DOT ORG>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/26/2003 13:08
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        DSMC Exit Code Question



I had an intersting question posed to me today and I don't have an
answer.  This person is checking the return code on the dsmc command to
determine if the backup needs to be looked at or not.  What he is coming
across is files that are in the directory when the directory is scanned,
but gone when the backup tries to back the file up.  We did figure out
we could probably exclude the files, but what we would like is for TSM
not to give a non-zero return code what a file is not found.  Thanks for
any input into this matter.


Andy Carlson                                    |\      _,,,---,,_
Senior Technical Specialist               ZZZzz /,`.-'`'    -.  ;-;;,_
BJC Health Care                                |,4-  ) )-,_. ,\ (  `'-'
St. Louis, Missouri                           '---''(_/--'  `-'\_)
Cat Pics: http://andyc.dyndns.org/animal.html