Subj : Binkley.Scd and Binkley.Day
To   : Dallas Hinton
From : Mvan Le
Date : Sun Jan 13 2008 07:59 pm

 DH> I'm not quite sure what you're aiming for -- I find it 
 DH> very seldom necessary to play with the event file. If 
 DH> you DO make a change to the event file, the procedure is as follows:

 DH> a) shut down binkley
 DH> b) delete *.scd, *.day
 DH> c) edit binkley.evt
 DH> d) run BT noforce (which will jump immediately to the current event)

ML> Do I have to start using flag file / semaphore hacks in the batch
ML> file or something ?

 DH> Again, I'm not sure of your target -- shoot me a bit 
 DH> more info and I'll try to make some more intelligent 
 DH> suggestions?

I finally figured the problem was being too brief with my *.evt file eg., 

  event all 00:00 04:20 b m 
  event all 04:20 05:00   m e1=101 t=6,10 e2=20 e3=30 ; binkd poll ZMH
  event all 05:00 23:59 b m e1=71                     ; daily maintenance

which caused Binkleyterm to rerun the e1's every time I deleted the .scd and 
..day files.

The solution is to create "zero" time events to limit a specific event's time 
range (especially an external exit to shell type event) eg., 

  event all 00:00 04:20 b m 
  event all 04:20 04:20   m e1=101 t=6,10 e2=20 e3=30 ; binkd poll
  event all 04:20 05:00   m                           ; ZMH continued
  event all 05:00 05:00 b m e1=71                     ; daily maintenance
  event all 05:00 23:59 b m

which reduce the chances that Binkleyterm would restart any e1's.

I thought events could be a bit more intuitive and self managing than that.

The Noforce option only works for events with the 'f' flag set. And even then 
Binkleyterm reruns the current event after the .scd and .day files are deleted 
irrespective of the Noforce option.

I thought it was a little shortsighted for Binkleyterm not to have an option to 
prevent restarting the current event after .scd and .day deletion.

I'm just having a whinge.

--- Maximus/2 3.01
 * Origin: Top Hat 2 BBS (1:343/41)

.