From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Otto Chvosta
>After that dbviewb reports that the journal state is 'not valid'. So we
>tried a further inremental backup (scheduled) to get a valid state of
>the journal database.
>This incremental was stopped with
>
>ANS1999E Incremental processing of '\\fileserver\q$' stopped.
>ANS1030E The operating system refused a TSM request for memory
>allocation.
>
>We tried it again and again ... same result :-(((

From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schaub, Steve
>Add this to the dsm.opt file and run the incremental again:
>*======================================================================
*
>
>* Reduce memory usage by processing a directory at a time (slower)
*
>
>*======================================================================
*
>memoryefficientbackup  yes
>
>Large windows fileservers with deep directory structures often exhaust
>memory trying to traverse the entire filesystem during the initial
scan.
>This option scans the filesystem in chunks.

To add a bit of detail:

All modern Windows versions (except possibly Vista) have a hard-set
limit of total memory that can be dedicated to a single process thread.
(I believe it's 192MB, but don't quote me on that.) It is a hard limit
that cannot be gotten around.

Steve's workaround is an option. The other option is to use two
nodenames for the same machine, with two option files/sets of TSM
services/etc. One node backs up half the machine (by using
include/exclude lines in the option files), and the other node backs up
the other half.

The real fix? Use a real server OS.

--
Mark Stapleton (mark.s AT evolvingsol DOT com)
Senior TSM consultant