Subject: Re: DISMAN-SCHEDULE-MIB

From: Alan Luchuk <[email-masked]>
Date: Thu, 3 Feb 2000 10:52:25 -0500 (EST)

Hello all,

>Juergen Schoenwaelder wrote:
>
>> >>>>> Thippanna Hongal <[email-masked]> writes:
>>
>> >> I have some question regarding daylight sayings non existent time.
>> >> If an calendar schedule is scheduled to shoot every minute, and if
>> >> the time is changed from 2 PM to 3 PM, Do I need to schedule 60
>> >> times the schedule at 3 PM or it is triggered only once ?.
>>
>> Shall we add a sentence which makes that clearer? What about adding
>> the following sentence directly below the last paragraph of section
>> 3.4 in RFC 2591:
>>
>>         This rule applies to all events scheduled for nonexistent
>>         time, regardless whether the scheduled events originate from
>>         one or multiple rows in the schedTable.
>>
>> Would that help?
>>
>
>I do not see any confusion over the explanation in RFC regarding the
>non-existent time.
>
>My question is a specific case of one schedule  and one table.
>
>I have a single row and which does calendar schedule for 60 times in hour.
>For 2hrs of non existant time
>I have to do SNMP SET  for 60 * 2 times at the end of 3 PM.  This might lead
>to net congestion.

If a user creates a single calendar-scheduled event that can trigger
every "n" minutes, that user is really trying to create a periodic
event.  Presumably the reason for doing this using calendar scheduling 
instead of periodic scheduling is to (hopefully) make sure there is
no cumulative drift of the interval from the intended minute.  That is,
one might imagine that an event scheduled as a 300 second interval 
might drift from running on every 5th-minute (like minute 5, 10, 15, 
etc., after the hour).  But a event, calendar-scheduled to trigger
on every 5th minute, should *not* cumulatively drift from minute 5, 
10, 15, etc., after the hour.

Assuming the real intent of calendar-scheduling an event to trigger
every "n" minutes is really to achieve a reduced-drift periodic event.
If all events like this *are* triggered immediately after the missing 
hour, then the period between all of these triggers would be wrong.  
It would seem the right thing to do is to *not* trigger these events 
*at all* after the missing hour.  That way, the periodicity would
be maintained.  

My personal preference would be to add Juergen's statement above and 
move on.  But I see the utility of being able to trigger a periodic 
event that never drifts from the intended minute after the hour.

As a first-cut suggestion, maybe the algorithm should be something like:

-  If a calendar-scheduled event is scheduled to occur ONCE during
   the missing hour, then periodicity is _not_ important, so trigger
   the event immediately after the missing hour; otherwise

-  If a calendar-scheduled event is scheduled to occur MULTIPLE TIMES
   during the missing hour, then periodicity _is_ important, so do
   _not_ trigger the event immediately after the missing hour.

>At this time I would like to add another implementation feature.
>
>If a schedule fails to do its intended operation for certain number of time
>then schedOperStatus is set to DISABLED.

I see the utility of this, and can align with it.

>While considering the number of times , I consider the interval between the
>schedules too.

I am unclear about the utility of this.  I am also unclear about the
algorithm that is used to decide when to disable the event.

Regards,
--Alan

 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 865 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 865 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.snmp.com/
 -----------------------------------------------------------------------------

   Note:  Our area code changed to 865 from 423 in November.  If you have
   trouble reaching us via area code 865, please try the old area code (423) 
   and let us know.  Both area codes should work until April.