Client Acceptor Daemon (CAD): what's the point?

badbob001

ADSM.ORG Member
Joined
Aug 14, 2008
Messages
23
Reaction score
0
Points
0
The TSM manual suggests that using the CAD to manage the TSM Scheduler to reduce cpu and memory use, but is this the only advantage to using it as opposed to having the TSM Scheduler service running constantly? If TSM Scheduler crashes, I can have windows auto-restart that service.

I don't have the TSM Web Client service installed so if CAD has anything to do with that, then I don't need that functionality.

The main reason this is an issue is that on a few servers, the server sometimes reboots when CAD starts the TSM Scheduler. Since CAD likes to start the TSM Scheduler a few times a day, the chances of a reboot are high. I uninstalled CAD and left the TSM Scheduler running and the reboots are gone. So what do I lose from not using CAD on all my systems?
 
For one: without the CAD, you cannot use the WEB based interface to do manual backup or do restores.

I personally like the TSM Scheduler over the CAD.
 
For one: without the CAD, you cannot use the WEB based interface to do manual backup or do restores.

We don't use the WEB-based interface so CAD is pointless, right?

It's confusing what services constitute the 'web' interface. When using the wizard to install the TSM Web Client, it installs both the TSM Client Acceptor daemon and the TSM Remote Client Agent. If I just use the wizard to install the TSM Client Scheduler and choose to use CAD, it'll install the TSM Client Acceptor daemon and the TSM Scheduler.

So CAD is some sort of shared component used by the Web client and the Scheduler.

My guess: IBM noticed that the TSM Scheduler is a big complicated service that may crash and cause all future backup jobs to be missed. Windows can auto-restart a crashed service but this may not be the case on all other operating system. So IBM creates the simplier CAD service to periodically run TSM Scheduler. So it's a hack.

If there is really no disadvantage to just using the TSM Scheduler by itself from a resource or reliability standpoint, then goodbye CAD.
 
Over long periods of time you *may* see the scheduler eat up a lot of memory, I had this happen a lot on Linux nodes after the scheduler had run for say 200+ days... Using CAD allows the scheduler to wake up, check for a schedule and then exit.
 
Over long periods of time you *may* see the scheduler eat up a lot of memory, I had this happen a lot on Linux nodes after the scheduler had run for say 200+ days... Using CAD allows the scheduler to wake up, check for a schedule and then exit.

Well, I haven't had this issue for over 600 nodes over the years: mixed Windows, Solaris,, AIX, Novell, Linux. :)
 
Back
Top