What kind of operation are you running? SELECTIVE or ARCHIVE? Are you using the QUIET option? Incremental backup should not generate these messages.
The reason I ask: We recently fixed a bug (IC39328) where SELECTIVE or ARCHIVE operations don't issue these messages when QUIET is in use, though they are displayed when QUIET is not used. The fixed behavior is consistent in that messages of greater than informational severity should not be suppressed regardless of the QUIET or VERBOSE setting. And certainly the return code should not be affected by QUIET or VERBOSE. I understand the issue, and this has been discussed at length in development. Way back when the incremental, selective, and archive operations were defined, it was decided that use of SELECTIVE and ARCHIVE would imply *all* files in the specification, i.e. if you say "SELECTIVE <this_file_spec>", you want *all* the files. Hence the warning message (and, as of 5.1, the RC 4) to indicate that some files were skipped via EXCLUDE statements. The issue with ARCHIVE is a little bit different. Because ARCHIVE is intended for long-term storage, we wouldn't want to silently skip excluded files just in case there was an error in the exclude statement. While *you* may know what you are excluding, I can easily imagine someone who inadvertently excluded something they didn't intend to exclude, then 2 years later when they try to retrieve it, it isn't there. And then we'd get blamed for not providing adequate warning during the archive that the file was skipped. I understand that this does not give you a solution, but I'm just trying to explain how we got here and some rationale for the choices. I recommend you open a requirement if you would like to see the behavior changed. It should be noted that RC 4 is not defined as a "failed" status for backup, selective, or archive operations; rather, it is "successful" with some files skipped. Though I understand that there is a distinction between files you *meant* to skip versus those that were skipped for reasons other than being excluded. If I have misunderstood anything about the technical details surround this (i.e. if you are seeing this during incremental processing) then please provide more info, such as the *exact* syntax you are using and the output you are receiving. If you can reduce this to a single file or a small set of files, that will be helpful. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. Joe Pendergast <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 07/08/2004 09:18 Please respond to "ADSM: Dist Stor Manager" To [EMAIL PROTECTED] cc Subject Upgrade to TSM client 5.2.3.0 Benefit or Nuisance. I have just upgraded my TSM clients and server to 5.2.3.0 on the AIX 5.2.0.0 systems, and come across an interesting new message. ANS1115W File '/oracle/stage' excluded by Include/Exclude list This new output message is repeated for each directory that I have excluded in the inclexcl listing. They appear on screen during an interactive backup (dsmc i) and are also placed in the schedule log (dsmsched.log) on scheduled backups. Benefit = The administrator can analyze the results of the inclexcl file changes by executing a backup. Detriment = Programs scanning for "W"arning messages will show this purely "I"nformative message. Problem observed: An interactive backup (executed in a ksh script) now exits with a return code of "4" indicating files have been skipped. Yes, I agree, the files have been skipped, but they were skipped by design. Previously my special (ksh) backup processes completed normally (return code 0), and now they complete with an error (return code 4). TSM support response: The message and return code are working as designed. If any of the technical people in this list agree that the files skipped because of the inclexcl list should not trigger a return code 4, please contact TSM support and tell them. I appreciate any workaround ideas to keep my "ksh" backups from failing with return code 4 as a result of the inclexcl statements. I would still like to see the return code 4 if there were truly "failed" files.
