Lurking through my SUMMARY table using "select activity,schedule_name,count(*) from summary group by activity,schedule_name" and subsequent selects revealed some facts as follows: - server events/housekeeping which cannot be scheduled do not have SCHEDULE_NAME filled - migration, reclamation, tape mounts, etc. - manually invoked activities do not fill SCHEDULE_NAME - expiration, full/incr DB backups, etc. Administrative schedules leave trail in SUMMARY. - manual backups/archives invoked by the client do not fill SCHEDULE_NAME (it would be surprising if the did :-) - *prompted* client schedules write their name using one of the sessions (if you are interrested which one you can dig further). Other sessions again leave SCHEDULE_NAME blank. - schedules for *polling* clients I think work like the client grabs the schedule time and on that time runs "manual". And they did not fill SCHEDULE_NAME.
Zlatko Krastev IT Consultant "Baines, Paul" <[EMAIL PROTECTED]> on 22.11.2001 17:47:13 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: 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
