Subj : testime.btm To : Renato Zambon From : Gerald Miller Date : Sun Aug 11 2002 10:56 am Hello Renato, On Saturday August 10 2002 at 16:48, Renato Zambon [4:801/161] wrote to Gerald Miller, about: testime.btm GM>> Okay, I'll try posting as a plain text file. I was concerned GM>> about word wrap and possible truncation. Thank you for the GM>> "ruling", I will only resort to the encoded method if plain text GM>> becomes problematic.... RZ> Ruling? Was just an oppinion/suggestion, you don't need to agree. I know from experience that it is unhealthy to NOT agree with the moderator. Besides, you'll notice that my use of the word "ruling" was within quotation marks - tongue in cheek.... ;-) GM>> I know it is a little "bloated" and could be cleaned up a bit. GM>> I've been using it for about a week now and it *appears* to be GM>> doing the task that I want. I had to add a deferential factor of GM>> five seconds (if the LOCAL system is within plus or minus five GM>> seconds with that of the Remote system) to prevent constant GM>> updating and to fudge the one second updates. :B-) RZ> I tested here and seems to be working ok. If used by a pvt node that RZ> don't make or accepts events with other systems the RTime will be RZ> always from its uplink. If you run it twice however without a new RZ> event, seems the correction will be doubled, and again, again... I thought that would be a problem and that was solved (on my end) by making a call to the BTM (once only) before the mail gets tossed and only if the uplink was my host system. I think it would take some fancy coding to prevent the correction being applied multiple times.... One possible solution *might* be to create a zero-byte "flag" file when the correction is applied (near the end of the batch file) and insert some code at the beginning to test for the existence of the flag file and to check the date / time stamp of that file. At this moment, I haven't given it much thought and am unsure about how I would proceed with such a "safeguard".... ;-] RZ> Another possible bug, force a poll to my system for instance, without RZ> UTC correction in your batch (or to any not time-reliable node), and RZ> run it in sequence :-) I don't want to even think about going there. I must have wrangled with UTC issues for about three months before I was able to achieve a satisfactory solution that was in agreement with FrontDoor, Squish, AllFix, GoldED and some other software programs. I think it's a Pandora's box and since the TZ *seems* to be working well enough on my end, I know better than to start revising it (again). 8-) RZ> BTW, once FD does have internal time-sync option with configurable RZ> nodes, is it just a batch programming exercise? Yes, I understand that FrontDoor does have an internal time-sync facility, but I chose not to use it. I didn't understand the explanation within the documentation and rather than take a chance with FD revising my system time with that of every uplink, I decided to ignore it. I guess I _should_ take another look at the documentation..... In any event, the batch programming was a good exercise and was an excuse to keep mail flowing in the echo area.... :)) Cheers ... Gerald --- GoldED+/386 v1.1.5-20808 # Origin: An ant that is not close is distANT. (1:342/512) * Origin: Baddog BBS (1:218/903) .