Thanks - I have this on three non-production systems - so we will see how it goes - Hopefully it will solve all the error messages I keep getting on the clients. (see below) Even with a clean backup - I get the error: ANS1301E Server detected system error - and then a failed status.
+11 01/28/03 00:19:48 Total number of objects inspected: 79,781 +12 01/28/03 00:19:48 Total number of objects backed up: 75 +13 01/28/03 00:19:48 Total number of objects updated: 0 +14 01/28/03 00:19:48 Total number of objects rebound: 0 +15 01/28/03 00:19:48 Total number of objects deleted: 0 +16 01/28/03 00:19:48 Total number of objects expired: 5 +17 01/28/03 00:19:48 Total number of objects failed: 0 +18 01/28/03 00:19:48 Total number of bytes transferred: 35.85 MB +19 01/28/03 00:19:48 Data transfer time: 1.38 sec +20 01/28/03 00:19:48 Network data transfer rate: 26,590.52 KB/sec +21 01/28/03 00:19:48 Aggregate data transfer rate: 107.68 KB/sec +22 01/28/03 00:19:48 Objects compressed by: 0% +23 01/28/03 00:19:48 Elapsed processing time: 00:05:40 +24 01/28/03 00:19:48 --- SCHEDULEREC STATUS END +25 01/28/03 00:19:49 ANS1301E Server detected system error +26 +27 01/28/03 00:19:49 --- SCHEDULEREC OBJECT END ADSMSRVR-INCR 01/28/03 00:00:00 +28 01/28/03 00:19:49 +29 Executing Operating System command or script: +30 /usr/local/scripts/backup/process-logs.sh +31 01/28/03 00:19:52 Finished command. Return code is: +32 0 +33 01/28/03 00:19:53 ANS1512E Scheduled event 'ADSMSRVR-INCR' failed. Re turn code = 4. Jane -----Original Message----- From: Andrew Raibeck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 3:30 PM To: [EMAIL PROTECTED] Subject: Re: Backup fails when files fail "Fixtest" (synonymous with "patch") indicates that the code has not been fully tested. If your TSM version has a nonzero value in the 4th part of the version number (i.e. the '8' in '5.1.5.8') then it is a fixtest (or patch). The parts of the version number are as follows: 5 - Version number 1 - Release number 5 - PTF level 8 - Fixtest/patch level Major TSM releases will have new version and/or release numbers, i.e. "4.2", "5.1", etc. The first set of code for a release will have '0' for the PTF and fixtest/patch levels. Between releases, we issue scheduled maintenance in the form of a PTF, i.e. 5.1.1.0 and 5.1.5.0 are PTFs for the 5.1 release. Major releases and PTFs go through our full testing processes. Between PTFs, we issue fixtests to address high impact problems found between PTFs that can not wait until the next formal PTF or release. These usually under very little regression testing. In general, it is good practice to test out any new software on noncritical systems before rolling out to production. This is especially true for fixtests due to the limited testing that they receive. The "*** Fixtest" is just an "eye-catch" to let you know that you are indeed running a fixtest (which has had very little testing). 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. "jane.bamberger" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 01/28/2003 12:57 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: Backup fails when files fail Hi, I think I might be having the problem because of the level of the client - I just put a client 5.1.58 on one aix J50 - and IY22308 - rebooted - and I get this when I issue a dsmc: root-cws01>dsmc Tivoli Storage Manager *** Fixtest, Please see README file for more information *** Command Line Backup/Archive Client Interface - Version 5, Release 1, Level 5.8 (C) Copyright IBM Corporation 1990, 2002 All Rights Reserved. Do you know what the *** Fixtest means? I couldn't find anything in the readme. Jane -----Original Message----- From: Andrew Raibeck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 1:35 PM To: [EMAIL PROTECTED] Subject: Re: Backup fails when files fail Hi Jane, For the problem nodes, what are the *exact* client versions they are running? If they are at 4.2.1.0, then they will exhibit the bug for skipped files. If you are running something other than 4.2.1.0, then check the dsmched.log and dsmerror.log files. If the backups are being reported as failed, it almost certainly has to be for some other reason. Note: if the client option QUIET is being used, it might not be a bad idea to comment it out so you can get more detail in the dsmsched.log file. Let me know what you find. 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. "jane.bamberger" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 01/28/2003 11:17 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: Backup fails when files fail HI, I have Server 5.1.6 with most clients still at 4.2.x - and I still get the failed status, even when other files have backed up: ---------------------------------------------------------------------------------+ | (Backed Up Today) | (Stored on Server) | | Node | Status Elapsed Bytes(MB) | Files Data | Last Acc | ----------------+-------------------------------+---------------------+----------| ADSMSRVR | Failed 00:05:40 35.85 | 152194 4088 MB | <1 | CWS01 | Missed N/A N/A | 229222 46416 MB | 2 | ORSRVR | Missed N/A N/A | 268094 49184 MB | 2 | RX | Failed 00:00:26 3.32 | 108471 4557 MB | <1 | RXSRVR | NoData 08:35:38 .0492 | 101303 1398 MB | 1 | UTILSRVR | NoData 04:07:25 .0411 | 1317040 15466 MB | <1 | ---------------------------------------------------------------------------------+ You can see that for my adsmsrvr - the status is failed - but 35 mb backed up. It is not the behavior I like - but I put the patch on when my server was at 4.2 and it still occurred. I had talked to level 2 support at the time and was told it was a requested feature - that admins had requested to know when a file failed to back up. I would love a solution to this - as my boss questions the failures all of the time. Jane Bassett Health Care -----Original Message----- From: Bernard Rosenbloom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 12:33 PM To: [EMAIL PROTECTED] Subject: Re: Backup fails when files fail Andy, Glad you're on this discussion. I work for IBM and my colleagues and I were told months ago from level2 TSM support that reporting a backup as failed (in the TSM activity) as a result of an rc=4 (files open or not found) was a "bug" in 4.2.x and would be fixed. Andrew Raibeck wrote: > You don't qualify what you mean by "failed", but if you simply mean that > the return code from dsmc was 4, then this is a new 5.1 feature, not a > bug. See the "Automating Tasks" chapter in the 5.1 client manual for > information on return codes from the command line client and their > meanings. If you have any other questions on this, let me know. > > 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. > > Thomas Denier <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 01/27/2003 14:47 > Please respond to "ADSM: Dist Stor Manager" > > To: [EMAIL PROTECTED] > cc: > Subject: 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?