> What I'm trying to do is get something together to overcome the bug
> where, calendar based scheduling , we have a full monthly and full
> weekly running on the same day and to avoid the weekly being selected as
> its window is earlier.
> =20
> So I'm trying to at least give myself a "heads up" that a policy has
> been added and configured this way.

Ugh.  Looks like you're going to have to do some math to find that out.

I'd assume you'd want to look for "^SCHEDCALENDAR\n" to verify that it's
a calendar based schedule.

Then you're going to need to look at the combination of SHEDCALDAYOMONTH
(why no F?) for dates in *any* month (32 being the last day of the
month), and then the combination of SCHEDCALIDATES and SCHEDCALEDATES
('I' for include, 'E' for exclude).  I believe, but am not certain,
that excluded dates override either dayomonth and calidates.  

And of course dayomonth dates are '1' indexed days from the beginning of
the month, while cal[ei]dates are "unix time" or seconds from the epoch
to the beginning of the given date, in local time.  (If you change the
timezone on the master server, does it rewrite the database, or does it
just change the output of 'bpplsched -l', I wonder?)

I'd recommend perl or python with some date manipulation routines....

I might create an array with a cell for each of the next (say) 30 days.
Add a bit or a hash entry for each schedule that appears to schedule
that date.  Then run through the cells and see if two schedules refer to
the same date.

Good luck!

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >