You are entirely correct, but going by the people who still run 4.5, I 
am guessing the information will still be useful to a lot of people :)

Here's a summary that should be pretty accurate, since I got back from 
training not too long ago.

The request daemon (bprd) starts the bpsched process on the master 
server, either by user request, or by the scheduled wakeup interval. 
This bpsched process consults bpdbm to determine (a) which jobs need to 
be run, if any, and (b) to figure out the requirements of jobs that need 
to be run. If there is nothing scheduled, this bpsched exits.

If there is anything that needs to be done, the initial bpsched process 
(let's call that A) creates a worklist and kicks off another bpsched (B) 
that is given the worklist. This second bpsched sends out what I think 
is called the birth announcement for the backup jobs that need to run. 
Then, each backup job gets its own bpsched process that are spawned from 
(B). Each of those backup bpsched processes start bpcd process on the 
media server required by the backup job they are running through inetd. 
Then, this bpcd starts a backup and restore manager (bpbrm) for each 
backup job. This process starts a bptm or bpdm (depending on what type 
of storage unit you are using, tape or disk) on the media server, and a 
bpcd process on the client, again through inetd. The client bpcd invokes 
bpbkar to start sending data.

In the mean time, the bptm or bpdm process initiated on the media server 
  figures out the stuff that needs to be done to start writing the data. 
  If you are using tape, bptm communicates with vmd to figure out the 
media to be used and ltid and tpreq to mount the media (and some other 
stuff that I don't remember.) It also creates a child bptm that will be 
communicating with bpbkar on the client and receiving and writing out 
the data buffers sent by that process.

While bpbkar is sending data to bptm, it also sends metadata about the 
backup job to the bpbrm process on the media server, which in turn feeds 
it to the bpdbm process on the master to be entered into the Netbackup 
catalog.

When bpbkar is finished sending buffers to bptm, it exits. When bpbkar 
stops sending buffers, the bptm processes on the media server exit. When 
  the bptm processes exit, the backup bpsched on the master sends a 
notice to its parent, (B), and the parent sends out the end of backup 
announcement, after which the backup bpsched is killed. After all the 
backup bpscheds are finished, the (B) bpsched process first looks to see 
if there are other jobs to be run, and if there aren't, the first 
bpsched (A) exits. This signifies the end of the backup session, and the 
last remaining bpsched process does some cleanup and kicks off a catalog 
backup (if you configured your catalog backup accordingly.)

If you need more information, I have more detailed notes from my 5.0 for 
Solaris class that I can look up.

HTH
Kemal

Greenberg, Katherine A wrote:
> Someone correct me if I'm wrong, but I'm pretty sure that all of the
> bpsched stuff is gone w/ 6.0... so upgrade and it won't really matter ;)
> 
> ~Kate
> 
> 
> 
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Asiye
> Yigit
> Sent: Thursday, November 17, 2005 11:22 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] A request for understanding the behaviour of
> bpsched command!
> 
> 
> Hi gurus,
> I have searched all the guides I have about the understanding of the
> mentality Of bpsched daemon.
> 
> As far as I understand, bprd is starting bpsched daemon according to the
> wakeup interval To cause bpsched to look at the policies whether there
> are some jobs which are due.
> 
> If there is job which is due. Bpsched daemon creates another bpsched
> daemon. I Would like to understan the interaction between of bpsched
> daemons.
> 
> Is there anyone to help me about that. I need a deep technical
> description for that.
> 
> Regards,
> 
> Asiye Yigit
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
> -----------------------------------------
> This e-mail may contain confidential or privileged information.  If you
> think you have received this e-mail in error, please advise the sender
> by
> reply e-mail and then delete this e-mail immediately.  Thank you.
> Aetna
> 
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu