> From previous discussion threads, and per TSM
> level 2 support, I was under the impression
> that reporting a failed backup as a result of
> a an rc=4 was a "bug" that tivoli was going
> to repair...

No.

There are two things going on here: (1) the RC 4, and (2) the "failed"
status. They are not necessarily one and the same.

The bug that existed in the 4.2.1.0 client (APAR IC31844) was that if one
or more files were skipped during backup (and assuming that everything
else was alright), the backup was flagged as "failed" with a return code
of 4. This was incorrect behavior. The correct behavior was that the
backup should have been flagged as "complete" with a return code of 0. Up
until 5.1 (with the exception of 4.2.1.0) that is how ADSM/TSM always
worked.

Starting with version 5.1, we deliberately changed the behavior such that
a backup that completes with skipped files (but no other warnings or
errors), will be flagged as "complete" with return code 4. This is not the
same as IC31844 that I mentioned above where the status was "failed".

Prior to 5.1, the return codes from dsmc were not documented, nor were
they consistent or predictable in some situations. Version 5.1 addresses
that by providing several return codes that are issued by dsmc and the
scheduler so that you can more readily assess the relative success or
failure of the operation. This fulfilled a long-standing customer
requirement. The RC 4 for skipped files fulfills another related
requirement to provide a means of distinguishing between complete backups
with no skipped files and complete backups with one or more skipped files.

As I mentioned yesterday in my prior post on this subject, the client
manual documents this behavior in the "Automating Tasks" chapter.

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.eyebm DOT com (change eye to i to reply)

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




Bernard Rosenbloom <brosenbl AT OPTONLINE DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/28/2003 10:24
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Backup fails when files fail



>From previous discussion threads, and per TSM level 2 support, I was under
the
impression that reporting a failed backup as a result of a an rc=4 was a
"bug"
that tivoli was going to repair...

"Seay, Paul" wrote:

> Consistent return codes was a Share requirement for years so that
production
> processes could actually be coded and have a determinable consistent
result.
> You may not like the implementation, but it is what was asked for.
>
> Paul D. Seay, Jr.
> Technical Specialist
> Northrop Grumman Information Technology
> 757-688-8180
>
> -----Original Message-----
> From: Richard Sims [mailto:rbs AT BU DOT EDU]
> Sent: Monday, January 27, 2003 8:02 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Backup fails when files fail
>
> >We have an HP-UX TSM client running 5.1.1.0 code. It connects to a
> >4.2.3.3 server running under OS/390. A 'dsmc incremental' command on
> >the HP-UX system failed with an exit status of 4, apparently because
> >three files failed with ANS1228E and ANS4045E (file not found)
> >messages. I remember reading about this kind of behavior in Version 4
> >clients. Has Tivoli managed to resurrect this bug in Version 5?
>
> Give IBM (formerly Tivoli) some credit here...  Customers have been
> clamoring for years for useful return codes, and this is an example of
how
> they can be useful.  Acting on the return codes is optional, after all.
>
>   Richard Sims, BU