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.