Linda,

You mentioned how Emory simply moves their /Rptsched/schedlist to a
different file and substitute an empty file in during rebuilds.
 Then they schedule their rebuild reports etc. and replace the full
schedlist file back in place when the rebuilds are done.

From my few thoughts about this I see the following issues for LONGER than a single day downtime cases:

    -when you rename the backup file back into place on say Monday at
10:30 a.m. we would suddenly have all of our "night" reports running
like additem and adutextam and reorgthesauri etc. etc.  Of course,
running adutext during the day has never been recommended and takes
hours during the day.

I like the idea A LOT so here's how I'd make it work.

1.  -copy schedlist to say schedlist.bak

2.  -create a NON-empty file to put in its place at the appropriate time:

$ egrep "^[a-z][a-z][a-z][a-z]\|.*\|.*\|n\|" schedlist.bak > schedlist.never

cp schedlist.never schedlist

        *REASON: This new schedlist will have all the NEVER run template
reports which will be needed for the first day back up on the system.

3.  -schedule the rebuild reports

4.  -post rebuild, on first day the system is up, NEVER template reports
can be copied and run for the reports you do want to run on the first
day up on the system--avoiding additem reports, adutextam reports but
running reports like:

    -ASAP for recallsam and recall2dueam
    -ASAP remoldhold
    -ASAP oneplusholdlis (if Monday or any report that normally runs
a.m. morning system is revived)

    -schedule ONE UP reports for the first evening copy templates (or
NEVER reports--this is why I need the egrep to get the NEVER reports
into the new schedlist file) but with MODIFICATIONS for things that
target date ranges:
    -statlog as normal 17:00
    -gatelog as normal 17:05
    -dorders 17:15 ...etc.etc.

***moverdue2 and doverdues have to have modifications to cover the days
that the system was down because items COULD have fallen due during
those down days if staff inadvertantly set the date due to one of those
days****

As one schedules the reports for that evening, check each one carefully
to see if any date sensitive issues need to be dealt with for the down
days.

Ensure that reports that should have run while the system are down are
either run this evening with any special date range criteria changed as
appropriate (eg. Mackfinalist2, GLOBALordcus, MEMBordcus, STANDordcus,
SUBordcus etc.)  Remember to change the date criteria to what the report
WOULD have targetted had it been run on the appropriate day.

Now use a simple shell program called by the crontab to replace this
temporary schedlist with the old FULL original schedlist at 00:01 so
that it begins to run the full normal schedlist the day AFTER the
rebuilds are done and system has been up for awhile. (I'm writing this program today.)

Make sense?

NOTE:  I tested on nut the situation that may happen of...

when you replace the full schedlist if it sees that a weekly report e.g. Sunday night report,
didn't run this week (according to it's "knowledge" -- field 6 of the
fishbones in schedlist), will it try to run those reports now, say on
Wed. morning?  Thankfully, the answer is NO!!  Perfect.  That's what I want because I would have run that "missed" Sunday night report manually on the first day the system came "alive" with a special date selection correction -- as if it had run on Sunday night.

Situation TWO single day downtime:

This is the complex outline for a multiday DOWN time.  But  for a single day downtime like April all we'll have to do is:

Day before event:
    -suspend any reports which are scheduled to run the next morning from 00:01 through early hours which are NOT to run during the daytime during cataloging etc.
        For example for Wed Apr. 24th 2002 Seter move suspend:
            02:40 additemlistNEWINTERNET WEDNESDAY
            03:00 adutextam in text group
            03:45 reorgtext in text group
LEAVE the two recal reports
            05:00 reorgthesauri in authority group
            06:00 correcthesauri in authority group
            06:15 correcthesauri (Run twice to create x-refs)
LEAVE 06:30 remoldhold remhold in circ group
 

Suspend and run manually the following once the system is up and running on Wed. Apr. 24th:
            07:30 dailybackup (does the daily transaction backup automatically) admin group
            07:45 newcash (daily)cashbyws report in custom gro
 

crontab program (which I'll write soon) to run at 00:01 on day osiris moves to seter which does the moving of the NEVER schedlist into place of the schedlist.  (This way our evening reports run on Tuesday night Apr. 23rd).

Then once we're up and running, we can manually move the schedlist.bak back into play as schedlist (which still will have the suspended reports on it since you did it before the crontab program).

Unsuspend your daily early morning reports to being on tomorrow, or Apr. 25, Thrusday.

Nella