A new feature in 3.4 is the ability of bpstart_notify & bpend_notify to work
with multiple data streams.

Check out the new variables STREAM_NUMBER and STREAM_COUNT.

STREAM_NUMBER is 0 if multiple data streams is disabled.  If multiple data
streams is enabled it will start with 1 and increment for each stream.

STREAM_COUNT is the total number of streams generated.


Scott Kendall
Hospital Products Division
Abbott Laboratories





curtis AT colltech DOT [email protected] on 10/20/2000 04:15:59 PM
Sent by: veritas-bu-admin AT Eng.Auburn DOT EDU
To: veritas-bu AT mailman.eng.auburn DOT edu, steingra AT pprd.Abbott DOT Com
cc:
Subject: Re: [Veritas-bu] Any decision reached on multi-streaming and

It was REAL tricky.

How to figure out which job is first is not too bad.  Essentially, we have
them all touch a file pattern, and whichever one touches it first is "in
charge."  However, since several may start at the exact same second, you
need to have them sleep a unique time before touching the file.  We use the
last two digits of the process id times 2.

HOWEVER, how do you figure out which job is LAST?  The ONLY way to do it is
to use bpdbjobs, and bpdbjobs is not on the client unless its a media
server.  We cheated and put it there.

As simple as all this may sound, it took weeks of trial and error to get it
right.  The biggest time loss was the 'jobs start all at once'
problem.  Before adding the sleep, we couldn't figure out why some would
work and some would not -- especially on HPs.  Go figure.  Five scripts
would touch five files, then they would do an ls to see who touched the
pattern first, and the five scripts would not AGREE!  That's why we had to
add the sleep.

I don't envy anyone having to go through that.  That's why we offer this
workaround free for anyone who wants it.

At 06:38 PM 10/18/00 -0500, Andrew Steingruebl wrote:
>A while ago there was a discussion about how to make sure that the
>bpstart/end
>scripts for a class with multi-streaming were only executed once.  It appears
>that the only good way to do it is to write some sort of checkpoint that
>stores state for each time a start is called, and then only calls the end
>script when the checkpoint decrements to 0.
>
>This doesn't seem extremely difficult to do, but Curtis indicated back in
>November that it was a little tricky, so I'm not sure I'm thinking of all the
>issues.
>
>Anyone want to volunteer the answer?
>
>Thanks.
>
>--
>Andy Steingruebl              | e-mail: steingra AT pprd.abbott DOT com
>Unix Systems Admin/Programmer | phone:  (847) 935-4728
>Unix/Network Security         | fax:    (847) 935-0142
>Abbott Laboratories, PPDR&D   | post:   100 Abbott Park Road, D472 - AP9A
>                               |         Abbott Park, IL 60064-6115
>
>
>_______________________________________________
>Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

---
W. Curtis Preston, Principal Consultant at Collective Technologies
Email: curtis AT colltech DOT com                (Best way to contact me)
Work : 408 452 5555                       (Leave a message.)
Pager: 800 946 4646, pin#1436065        (If urgent.)

Tap into the Collective Intellect (TM): http://www.colltech.com
Backup & Restore resources:        http://www.backupcentral.com

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu