Paul, Thanks for sharing your testing.
I will look into this issue further, and promise to share my findings as well. Expect something in the next 10 days from me. Cordially, Salvatore. ----- Original Message ----- From: "Baines, Paul" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 23, 2001 1:37 AM Subject: AW: schedule_name field in the summary table Hello Sal, well I looked into this a bit and it seems to be not the case: select node_name, client_version, client_release, client_level, client_sublevel from nodes where node_name in (select entity from summary where schedule_name is null and activity='BACKUP') Shows a full range of clients from 3.1.0.3 to 4.2.1.16, as does the same query with "is not null." So it isn't the case. Mit freundlichen Gr|_en - With best regards Serdeczne pozdrowienia - Slan agus beannacht Paul Baines TSM/ADSM Consultant -----Urspr|ngliche Nachricht----- Von: TAZ [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 22. November 2001 19:03 An: [EMAIL PROTECTED] Betreff: Re: schedule_name field in the summary table Paul, I have noticed the exact same issue, and, I am wondering if you have had an opportunity to test your theory. If you can't test it let me know, because I have the capabilities to do so. Sal. ----- Original Message ----- From: "Baines, Paul" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 22, 2001 8:47 AM Subject: schedule_name field in the summary table Hello, I have noticed that the schedule_name field in the summary table does not always have an entry in it. I think I've narrowed this down to the fact that 3.1 clients fill this in and 3.7 and 4.1 clients leave it blank. This would seem to be caused by the RESOURceutilization parameter causing sub-sessions to update the summary table without a schedule_name, while the main thread, which no longer transmits the backup data, doesn't update the table. Is this correct? If so it would seem that the schedule_name field is no longer relevant unless RESOURceutilization is 1. I also have some NT clients who make two entries in the summary table for one backup. This is caused by the fact that a session is started for c$, this just saves a few files, then it carries on searching through the e$ partition this goes on for over half an hour before it finds any data to send to the server and so the original session gets an idle timeout. As soon as data is found that has changed a new session is started and a new entry in the summary table is created upon it's completion. The first record in the summary table has successful=no and the second successful=yes. This is not really desirable behaviour. It is however documented in the client book under the resourceutilization parameter: "The client could produce multiple accounting records." Just thought I'd share my observations on this as it messes up our statistics gathering and may affect yours. Mit freundlichen Gr|_en - With best regards Serdeczne pozdrowienia - Slan agus beannacht Paul Baines TSM/ADSM Consultant
