I'm running MP3, and it isn't fixed. I have an open ticket with Veritas
right now for the very same problem.
They got back to me today with a possible fix:
" Before you convert any more frequency based schedules, print out the
schedule if desired, then delete it. Build the new replacement
calendar schedule from scratch. The reason for this, the bug that I am
looking at comes about from converting frequency based schedules to
calendar base. Some of the frequency characteristics of the schedule are
maintained internally to nbu and that is what messes things up."
I haven't actually tested this, but I'll report back afterwards.
--Steve
Double Black wrote:
> The problem under technote 248400 was fixed in NBU_MP_2
>
> dB
>
> ----- Original Message -----
> *From:* Dennis Dwyer <mailto:dfdwyer AT tecoenergy DOT com>
> *To:* veritas-bu AT mailman.eng.auburn DOT edu
> <mailto:veritas-bu AT mailman.eng.auburn DOT edu>
> *Sent:* Wednesday, February 05, 2003 11:10 AM
> *Subject:* [Veritas-bu] Addendum to Calendar Based Scheduling
> Question Posted Earlier
>
> OK ... At the risk of beating this beyond recognition, I went out to
> the Veritas support web site and found several hits on this issue. I
> found a Newsgroup article from Steve Staves titled "Another NBU 4.5
> Calendar versus Frequency Question" from last August that, although
> short, was very to the point. There were other hits as well to
> support this but the bottom line is (my interpretation):
>
> #1: If a backup window for a given policy is large (like 5 or 12
> hours) and the calendar based schedule crosses the midnight hour,
> you will probably get at least two backup schedules submitted for
> the same policy (that appears to be what's happening to us) because
> of the way NBU tracks the days and judges the frequency of the last
> backup.
>
> #2: According to multiple folks who have raised this question with
> Veritas ... Veritas doesn't recognize this as a major problem. Their
> solution (per Tech Note 248400) is to make the calendar based
> schedule window a short period of time rather than a long period of
> time. Preferably, just enough to start the policy. I have no idea
> how this will affect failures and restarts or policies that have the
> entire weekend as a window.
>
> #3: I find it difficult to believe that ArcServeIT (what I consider
> a lesser product to NBU DataCenter and the product I threw out to
> convert to NBU) does calendar based schedule the way I would expect
> it to be done and Veritas thinks their implementation is not a problem.
>
> I guess we'll still tinker with it off and on but until Veritas
> decides to address this (or at least publish in great detail how to
> implement it so it works every time) we are probably going back to
> Frequency Based Scheduling for the majority of our policies.
>
> I hope the Veritas folks that review this group will take this item
> back with you and realize the common perception of how Calendar
> Based Scheduling should work (and does work in other products) is
> not even close to what you've implemented in NBU 4.5. You either
> need to modify NBU Calendar Based Scheduling so it works like the
> users think it will work or ... dare I say it ... document how it
> does work so we will know what to expect.
>
> My thanks to Hampus Lind for his response that pretty much supports
> what I've been able to find in the research.
>
> Regards,
> Dennis
>
> Dennis F. Dwyer
> Manager, Systems Software
> Tampa Electric Company
>
> (813) 225-5181 - Voice
> (813) 275-3599 - FAX
>
> Visit our corporate website at www.tecoenergy.com
> <http://www.tecoenergy.com>
>
> The Colonel Says: "Time is not a test of the truth"
> Translation: Just because you've always done it that way, doesn't
> make it right
--
===================================
Steven L. Sesar
Ops. Sys. Programmer/Analyst, Sr.
Application Operations R10A
The MITRE Corporation
202 Burlington Road - R101
Bedford, MA 01730
tel: (781) 271-7702
fax: (781) 271-2600
email: ssesar AT mitre DOT org
mobile: (617) 893-9635
===================================
|
