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" <Paul.Baines AT PARTNER.COMMERZBANK DOT COM> on 22.11.2001 
17:47:13
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
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