Hello, Matthew -

I sought certainty on the customer-reported log name, as it was not
cited in the original posting: we knew what *you* thought the log
was, but not what the customer complained about.  (End users are
typically vague in problem descriptions, which can result in a lot of
wasted time by systems people trying to resolve their issues.)

The simplest explanation for such a log not being pruned is that the
scheduler process was launched prior to the time that the options
file was updated to contain the SCHEDLOGRetention specification.

If upgrading to TSM 5, get at least to 5.3.2, to avoid another
pitfall (IC45287).  And watch out for conflicts between
SCHEDLOGRetention and SCHEDLOGMAX.

   Richard Sims

On Sep 12, 2006, at 7:48 AM, Large, M (Matthew) wrote:

Hi Richard,

The filename is as it states in the first mail - dsmsched_1yr.log -
unfortunately they've deleted it as they needed to free up space.
It was
definitely the schedule log, and besides, wouldn't the setting
ERRORLOGRETENTION manage the dsmerror.log file? (which is also set
to 7
days)

I think we'll upgrade to 5.3.x soon so we'll just use the SCHEDLOGMAX
setting along with the SCHEDLOGRETENTION to ensure that these file
sizes
to not become unreasonably sized.