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: [EMAIL PROTECTED] (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 <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 01/28/2003 10:24 > Please respond to "ADSM: Dist Stor Manager" > > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]] > > Sent: Monday, January 27, 2003 8:02 PM > > To: [EMAIL PROTECTED] > > 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
