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)
