TFConfig states "TFServer Service disabled Restart Manually using program under All Programs or using Services Center Manager". I tried manual start without success. Several times TFConfig used a default .tal. which I changed to the correct .tal. Initally, the production machine was running 2006. It was removed and the 2006 folder deleted. The machine was then upgraded to 2007 with a revised copy of the application loaded under a new name. The TFMonitor indicates a red dot - not connected - and red at the bottom left. The linelist appears correct.

Thanks for the support...

Is there any indication of what is amiss in the logs? Try starting TFServer service again in the Service Control Manager.

When it fails, check the log directory and see what logs are created with today's date. If there is only a TFServer log file, have a look at it and see what it does. If there are logs for the lines in the linelist, check them for errors.

If there are no logs, check TFConfig for "Log Directory". Make sure that the directory exists.

Hi Chris...

While I was waiting for suggestions, I observed the following:

Application would not answer incoming calls...
TFMonitor was not connected...
Tried shutting down and restarting the server with Start\AllPrograms\Teleflow\Server Tools\Telleflow Server Service Stop or Start... Got the following:

Server shut down...
Server cannot shut down....
Server cannot start with server running...
Server started...

Without any pattern, the application starts answering...
Reboot and do the same procedure resulting in no answers.

I'll be looking at your last suggestions....

I would actually stay away from the command files (although technically, these should work fine) and stick with Service Control Manager for starting/stopping TFServer service. This way, when you look at the service, you can tell if it should already be running or not. The errors you were getting suggest TFServer was already running... which could be confusing to your testing.

What I would suggest more than either command files or the Service Control Manager: If you are intending the keep the system running all the time anyway, I would check "Start TeleFlow Service Automatically" in TFConfig, restart the computer, and see what result you get that way. Since that is probably how things will run "normally", start there, and see if this is giving you problems.

Reboot; did not answer incoming; went to start/control panel/admin tools/services; teleflow set to automatic; status is starting; did not answer incoming; right click on teleflow server; no tasks were available - could not restart; ran action/refresh for 2:40 mins; incoming answered - status changed to started.

After a computer restart, this is how it works.

At one time, we simply used service dependencies to determine when it was safe to have TeleFlow start. Unfortunately, in many cases, if Windows has just started, and a service (such as the Dialogic service) reported as started, it wasn't truly ready, and TeleFlow would get errors when querying the board(s).

To help relieve this, TeleFlow waits both a number of minutes after Windows has started AND uses service dependencies to delay starting. This prevents avoidable yellow lights on otherwise working systems.

If it is now answering the phone and continues to do so, it is working as it should.

Hi Chris...

So, a delay of two to three minutes should be expected and provided for.
I just check once per minute and got a timed delay of four minutes before a call went through.

Therefore, since the application will be running without a mouse, keyboard & monitor, I need someway for the application to tell me when the server is ready. I was thinking of having the application run a test loop for the server and issue three beeps when the application is ready to receive calls.

Any suggestions of what can be done and where in the application the cycle be installed to test for the server running would be appreciated.

Chris, it sound like we may be near the end of this one....

Thanks....

Will you be able to connect to the server remotely (I.e. on a computer in the same network) using TeleFlow Monitor?

If you can, you might want to set TFMonitor to connect to that server, and check "Automatically connect" box. While the server isn't ready, it should keep cycling, trying to connect and failing, until it finally comes up. When it does come up and the lines are at "Wait for Call", it should be ready to receive calls.

Alternatively, you could have a "Compare" step just before "Wait for Call" that checks if @PORT = 1. If it is, then take whatever action you wish to let you know the system is ready, then go to "Wait for Call". (That might actually be a moment too early, but not by much)

Are you really going to have no way to interact with this system? Having a production server you can't get your hands on immediately when there is a problem - be it with the TeleFlow application(s) or something completely unrelated - sounds like an invitation for trouble.

Many copies of the application will be installed in a stand alone installation and independent of any network or connection with the outside world except by phone call in and out. Once started, will run unsupervised for its entire life.

Will you be able to connect to the server remotely (i.e. on a computer in the same network) using TeleFlow Monitor? A: No, no connection to the out side world.

Using a "compare" with three beeps will notify anyone nearby that the system is up and running.

Tech support will be by phone to a staff member at the site with some testing by the local staff under the direction of Tech. Support. If the problem is not corrected, a cross shipment will provide a replacement.

During testing to locate the delay problem, sometimes the server came up within 10 seconds. Any thoughts of how this can be done each startup?

Well, for a start, this shouldn't ever happen. Are you sure it was 10 seconds from the point at which Windows starts? This isn't when you log-in, but when Windows actually starts. I can't tell you at precisely what point that is. When Windows starts the TeleFlow service, TeleFlow looks up what date/time Windows started. It then ensures that no board startup is run until the proper delay time is reached.

Furthermore, there isn't anything to be done for it. Before we implemented the delays, there were frequent board errors trying to start ports, because (although the services said otherwise) the boards weren't really ready. In a stable production environment, restarts of the computer are seldom needed anyway, so I wouldn't expect this to give you much in the way of trouble.