Thanks Andy.  Can you find out if this is really a defect or working as
designed?
The PMR we opened for the problem is 15935,180. Here is an example from
our dsmsched.log:

Thanks
Jeff

10/05/2001 02:07:06
Executing scheduled command now.
10/05/2001 02:07:06 --- SCHEDULEREC OBJECT BEGIN DAILY_2AM 10/05/2001 02:00:00
10/05/2001 03:00:05 ANS1228E Sending of object 
'\\appcentsyr1\d$\Shared\VS\DD\Site4\DD1\3565.ISM' failed
10/05/2001 03:00:07 ANS4987E Error processing 
'\\appcentsyr1\d$\Shared\VS\DD\Site4\DD1 \3565.ISM': the object is in use by 
another process
10/05/2001 04:40:55 --- SCHEDULEREC STATUS BEGIN
10/05/2001 04:40:55 Total number of objects inspected: 2,484,236
10/05/2001 04:40:55 Total number of objects backed up:    4,959
10/05/2001 04:40:55 Total number of objects updated:          5
10/05/2001 04:40:55 Total number of objects rebound:          0
10/05/2001 04:40:55 Total number of objects deleted:          0
10/05/2001 04:40:55 Total number of objects expired:      1,231
10/05/2001 04:40:55 Total number of objects failed:           1
10/05/2001 04:40:55 Total number of bytes transferred:     5.05 GB
10/05/2001 04:40:55 Data transfer time:                  787.08 sec
10/05/2001 04:40:55 Network data transfer rate:        6,733.45 KB/sec
10/05/2001 04:40:55 Aggregate data transfer rate:        574.25 KB/sec
10/05/2001 04:40:55 Objects compressed by:                    0%
10/05/2001 04:40:55 Elapsed processing time:           02:33:48
10/05/2001 04:40:55 --- SCHEDULEREC STATUS END
10/05/2001 04:40:56 --- SCHEDULEREC OBJECT END DAILY_2AM 10/05/2001 02:00:00
10/05/2001 04:40:56 ANS1512E Scheduled event 'DAILY_2AM' failed.  Return code = 
4.
10/05/2001 04:40:56 Sending results for scheduled event 'DAILY_2AM'.
10/05/2001 04:40:56 Results sent to server for scheduled event 'DAILY_2AM'.






Andrew Raibeck <storman AT US.IBM DOT COM>@VM.MARIST.EDU> on 10/09/2001 11:44:58
AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:  Re: Windows client behavior change at 4.2.1.0


I am almost certain that this change in behavior is not deliberate. The
APAR is going to be handled as a code defect, not a doc issue. Skipped
files are not cause to fail an incremental backup.

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.ibm DOT com

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




Jeff Connor <connorj AT NIAGARAMOHAWK DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
10/09/2001 08:08
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Windows client behavior change at 4.2.1.0



Not sure how much of an issue this will be for some of you but I thought
I'd pass
along a change we came across in the Windows 4.2.1.0 client.

If you are like us, and don't do a great job of excluding "unimportant"
files
that are regularly missed because they are in use during nightly backups,
then you will probably be affected by the change.  The Windows client
4.2.1.0
now reports a backup schedule failed with a RC=4 if any files are skipped
because they are in use.  The backup does complete but a Q EVENTS
shows the backup schedule failed. Previous versions reported the backup
schedule as completing successfully even if some files were missed.

We are in the process of doing what we should have done already and
building better Exclude lists to omit the non-critical files.  APAR
IC31844
has been
opened for a documentation change so people will be aware of the
new client behavior.

Regards,
Jeff Connor
Niagara Mohawk Power Corp