Hi Cindy,

I had the same problem several times.  The way pruning works, is to copy the
file up to the desired point, delete the old log, and rename the new.  SO
the usual problem is not enough space in the file system.


I reported it to IBM once , and they said that  the only reasons that log
pruning should fail are:
  1) insufficient free space in the file system to create the new files
  generated by the process.
  2) insufficient access authority to the log file.
  3) insufficient memory or other system resource.
.
These are the trace options they gave me to use if I couldn't figure it out:

(These go at the end of the dsm.opt file)
tracefl service
tracefi *:\ dirpath \22360.out
tracemax 2000


The "tracefi" statement should point to an output file for the trace.

The trace output was a bit strange, but it showed me enough to figure out
what the pruning process was trying to write to.

Hope this helps


===============================================================
Wanda Prather
Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think."
              - Scott Adams/Dilbert
===============================================================





> ----------
> From:         Cindy Cannam[SMTP:CCannam AT genam DOT com]
> Sent:         Wednesday, July 15, 1998 10:06 AM
> To:   ADSM-L AT vm.marist DOT edu
> Subject:      log pruning problem
>
> To all:
>
> Just in the last two days, one of ADSM's 3.1.0.0 clients has placed the
> following message in the SCHED.LOG:
>
> 07/13/1998 00:54:56 ANS1483I Schedule log pruning started.
> 07/13/1998 00:54:57 ANS1485E Schedule log pruning failed.
>
> The V3 Messages manual says to run the command with tracing on, but
> doesn't
>  say which trace options are required,
> and what the syntax for the command would be to start log pruning on a
> specific client.
>
> Has anyone else seen this with NT/ADSM V3 clients so far? What did you do
> to resolve the problem? This is only one client
> out of three in this particular domain, but if this can happen to one,
> it's
>  certainly waiting to happen to the other two!
>
> Thanks much!
>
> C.L.Cannam
> Storage Management
> GENAM/St. Louis, MO/USA
> ccannam AT genam DOT com
>