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