Thanks for the clarification

Andrew Raibeck wrote:

> > 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