ADSM-L

Re: Return Code Changes with V4.2.1 TSM Clients - development suggestions

2001-10-19 11:40:53
Subject: Re: Return Code Changes with V4.2.1 TSM Clients - development suggestions
From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Date: Fri, 19 Oct 2001 18:38:36 +0300
May I try to modify the Joel's idea:
Instead of putting new include/exclude option to put a number for include
options:
include [ 0-9 ] <file_pattern>  [ mgmtclass]

If the number is ommited it defaults to 1. Pattern should not begin with
number (is anybody using relative include paths with top dir beginning with
number) so syntax parsing not be affected very much. The number can be
assumed level of importance or anything else. A parameter for the level
(again defaulting to 1) to be added in dsmc/gui such that client will
backup/archive only files matching patterns on this and higher levels.
Files on lower include levels will not be processed. Lower level files have
NOT to be expired.
If client encounters error processing a file on same level it will not
report it retaining existing client behavior and ensuring backward
compatibility. If the file matched higher level pattern RC=4 would be
returned.

So if you have a really important files which have to be reported as backup
errors they have to be included in the inclexcl list at higher level.
If a pattern is defined with level 0 its files will be omitted from
everyday backup operations but not expired. This can help the people who
asked on this list how to exclude a file from backup and always got the
answer to be careful because this would also expire the file. Such files
can be backed up on demand specifying dsmc parameter of 0.

Expiration of files created by parameter 0 will happen only when client is
invoked with parameter 0 and no pattern is specified on the command line.
But creation of such files can be assumed new feature. Expiration of
ordinary files will take place when client is started without pattern (and
lack of parameter defaults to 1). This again will give us backward
compatibility.

Maybe I miss something but the raw idea is shown. This way any scripts and
third party applications relying on current client behavior can stay
unmodified.


Zlatko Krastev
IT Consultant






Joel Fuhrman <joelf AT CAC.WASHINGTON DOT EDU> on 19.10.2001 01:08:00
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: Return Code Changes with V4.2.1 TSM Clients

I don't this a percentage or count is sufficient as they could still result
in the un-reported failure to backup a critical file.  If your backup
include/exclude list is perfect, then a non-zero RC is a failure.

However, its not always possible to build a perfect include/exclude list.
For instance, there may be some files, that are occationally exclusively
used, that you want backed up whenever they are available.  To do, this
while still getting a valid RC, would require another include/exclude
option
such as OPTIONAL and OPTIONAL.DIR. If all backup failures were OPTIONAL
files, then the RC code would be zero.

On Thu, 18 Oct 2001, Seay, Paul wrote:

> 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?
>
> -----Original Message-----
> From: Loon, E.J. van - SPLXM [mailto:Eric-van.Loon AT KLM DOT COM]
> Sent: Thursday, October 18, 2001 7:44 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: FW: v4.2.1 TSM Clients
>
>
> Hi Joachim!
> Jeff Connor had Tivoli open APAR IC31844 for this.
> Kindest regards,
> Eric van Loon
> KLM Royal Dutch Airlines
>
>
> -----Original Message-----
> From: Stumpf, Joachim [mailto:joachim.stumpf AT DATEV DOT DE]
> Sent: Thursday, October 18, 2001 08:09
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Fw: FW: v4.2.1 TSM Clients
>
>
> I think it's true!
>
> I tested the new client on a W2k machine and I got the same RC you
described
> below.
> If one file fails (e.g. it's in use by another proccess), the schedule
> returns with a result code of 4.
>
> I hope Tivoli works on a fix for that.
> We have some automatically checking for result code <> 0 (if there was
> a problem while backing up; and I think "file in use..." isn't a big
> problem)
>
> regards,
> Joachim Stumpf
> Datev eG
>
> "Subash, Chandra" <CSSubash AT TELETECHINTL DOT COM> (Donnerstag, 18. Oktober
2001,
> 06:41:31, MEST):
>
> > i HAVE GOT THIS EMAIL FROM ONE OF MY FRIENDS. GUYS WHAT DO YOU THINK IS
IT
> > TRUE ?
> >
> > Hi Guys
> >
> > According to Tivoli Support they have made an alteration to way client
> > v4.2.1 reports Result code 4 to the server. Earlier version clients
would
> > allow for a certain number of files to fail during the backup and still
> > report to the server that the Schedule was successful. However version
> 4.2.1
> > has been altered so that a result code of failed will be reported to
the
> > server even if 1 file fails during a backup.
> > ntcmachine had been failing on some WINNT system files which I have
added
> > exceptions for under direction of Tivoli support and now backups of
this
> > machine seem to be successful.
> > Bob from Tivoli suggested that if we are worried about seeing failed
> result
> > codes on the daily report that there may be a way to generate a report
> > listing statistics of how many files or how much data had been backed
up
> > from each machine to provide a more accurate picture as to whether the
> > backups were successful.
> >
>
> --
>
>
>
>
> **********************************************************************
> This e-mail and any attachment may contain confidential and privileged
> material intended for the addressee only. If you are not the addressee,
you
> are notified that no part of the e-mail or any attachment may be
disclosed,
> copied or distributed, and that any other action related to this e-mail
or
> attachment is strictly prohibited, and may be unlawful. If you have
received
> this e-mail by error, please notify the sender immediately by return
e-mail,
> and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM),
its
> subsidiaries and/or its employees shall not be liable for the incorrect
or
> incomplete transmission of this e-mail or any attachments, nor
responsible
> for any delay in receipt.
> **********************************************************************
>
<Prev in Thread] Current Thread [Next in Thread>
  • Re: Return Code Changes with V4.2.1 TSM Clients - development suggestions, Zlatko Krastev/ACIT <=