Can someone tell me if this problem be circumvented by specifying that
pruned log entries are to be Discarded?  I.e.,

SCHEDLOGRETENTION 30 D

The APAR does not indicate anything about this, but I figured if the
problem has to do with the pruning log getting too large that specifying a
"D" to discard the pruned entries might just be a workaround.

We unfortunately need to deploy a V3 NT client (for NT servers that backup
Mac filespaces).  We view this bug as a serious one, and not pruning the
log file will lead to other problems on the server.

Thanks.
..Paul

PS: I don't have an NT system handy to try this on, or I'd have tried it
myself!
--
At 10:21 AM 8/19/98 -0400, you wrote:
At 10:21 AM 8/19/98 -0400, you wrote:
>It's a known problem. Please turn off schedule log pruning for now until
we can
>get it fixed.
>
>Pete Tanenhaus, ADSM NT Client Development
>---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 08/19/98
>10:08 AM ---------------------------
>
>
>ADSM-L AT VM.MARIST DOT EDU on 08/19/98 03:30:03 AM
>Please respond to ADSM-L AT VM.MARIST DOT EDU
>To: ADSM-L AT VM.MARIST DOT EDU
>cc:
>Subject: Win32 client bug!!
>
>
>Dear ADSM-ers!
>This is a warning for all Windows 32 client 3.1.05 users!
>If you use the dsmsched.log pruning option this can cause your filespace to
>fill up completely.
>Yesterday I installed the 3.1.05 client on 3 Windows NT machines. After the
>backup the ADSM scheduler starts pruning the dsmsched.log which never
>finishes. It created a dsmprun.log which took up all the available free disk
>space!
>This sounds like a serious bug in the ADSM client code.
>Kindest regards,
>Eric van Loon
>
>
>
>