Not flexible enough.  What if just one very critical file fails, like an
Oracle table space file?  Or a control file?  I think RC=4 should be given
if there are *ANY* failures, but continue with the session, and we handle
the return codes in our scripts.  Yes, it may mean more work for us, but I
don't see any other way that Tivoli can accomodate everyone's wishes.  And
whatever they do, it should not be forced... we should have the option of
overriding.

Robin Sharpe
Berlex Laboratories



                    "Seay, Paul"
                    <seay_pd@NAPT
                    HEON.COM>     To:    ADSM-L AT VM.MARIST DOT EDU
                                  cc:    (bcc: Robin Sharpe/WA/USR/SHG)
                    10/18/01      Subject:
                    10:25 AM             Return Code Changes with V4.2.1 TSM 
Clients
                    Please
                    respond to
                    "ADSM: Dist
                    Stor Manager"







We need to make sure that TSM Development gets this right when they change
it.  Typically software is developed this way:

RC=0 is for when nothing goes wrong,
RC=4 nothing went wrong that is serious,
RC=8 serious failure condition,
RC=12 some kind of internal error.

What Tivoli needs to do is allow us to define what number of files (or
percentage of files)  not backed up cause a RC=4 based on the needs of some
of the customers and the same for RC=8.  I personally would like to see an
option that causes a RC=4 if a file misses a backup more than x number of
times in a row.  That way I can determine it is not happening and take
action to either place it in a separate backup process when it can be
backed
up and exclude it from the timeframe it is not available to be backed up.

What does everyone think?