Sean ..

 SD> Hello, All.

 SD> I'm having problems with a single nightly event 
 SD> running at the wrong (very wrong!) time.  I have but a 
 SD> single EVENTS00.BBS file for the entire system which 
 SD> is one dialup node and three telnet.  The line in 
 SD> question:

 SD> Event All 0200 exit=105

 SD> For some reason, this event is running at varied times 
 SD> between 0800-0900.  Do I have something wrong in the 
 SD> events file?

I assume that you are running this whole deal under a .CMD file which also
uses the numeric value with a program exit to decide where in the .CMD file
the logic should next go to perform the desired action.

OK .. What you can do in many cases to figure out what might be going wrong
and how programs can somehow interfere with a 'proper' logic step operation
this way is somewhat simple!

You create an additional step by step mini-program action at any given
generic point like this to write a discrete little file on your hard drive
that has a unique text message in it.  Which you can then use to trace a
running .CMD or REXX file to see where a given error is being created! You
give each successive step a different pointer number, 1, 2, 3, 4 ..66 or
whatever.  You then use the little program to write the message you want
and that discrete unique pointer to a common trace file on your hard disk.

Then, sort of in your case, if, for example, the program doesn't exit with
error level 105, as expected, but somehow is different, you can then spot
exact where to go looking for a fix.

This technique can actually be used to manually trace the whole OS/2
operating system matrix for even a massive multi program mix.  Which can
then tell you exactly where a given OS/2 driver or program mix may have
botched even the ring level operations that leads to a strange failure like
this.

This is exactly the reason and the technique that was used for the decades
I was on the official OS/2 Development Testcase crew.  So that I could
check all the latest driver and op system changes on my multiple OS/2
systems. Including the full multiple BBS node number mess that was and
still is on the OS/2 box on which this is being written!  Which is how we
found out a whole huge number of program development errors for the IBM
team going all the way back to where it was in Boca Raton, Florida!

Any more thoughts needed to help you maybe?

Mike {at} 1:117/100



---