Skip to main content

[Migrated content. Thread originally posted on 29 March 2005]

A little difficult problem:

We have client-server programms.
Server is something like "@192.168.*".

And we have a Server on the internet (used for updates). Sounds like "@wwwserver.*".

If now a installation checks for a update, we open simply a textfile on the webserver an read the newest versionnumber.
Like: open "@wwwserver.*:home/files/text.txt" for input.
And of course close it afterwards.

it works and is stable, but if the client closes the file and the user leaves the form, the connetion is still alive.

A Netstat at our "webserver" shows the connection as establiched and alive until the user closes the hole programm (and therewith the runtime).

With these symptoms it is not easy to manage our updates. We never know if they are still updating oder have already left the "update"programm and are working with the "normal"programm.

Is there any way to close such a connetion without killing the local runtime (And stay connected with the "local"server)?

i hope i could explain my problem well enough.

[Migrated content. Thread originally posted on 29 March 2005]

A little difficult problem:

We have client-server programms.
Server is something like "@192.168.*".

And we have a Server on the internet (used for updates). Sounds like "@wwwserver.*".

If now a installation checks for a update, we open simply a textfile on the webserver an read the newest versionnumber.
Like: open "@wwwserver.*:home/files/text.txt" for input.
And of course close it afterwards.

it works and is stable, but if the client closes the file and the user leaves the form, the connetion is still alive.

A Netstat at our "webserver" shows the connection as establiched and alive until the user closes the hole programm (and therewith the runtime).

With these symptoms it is not easy to manage our updates. We never know if they are still updating oder have already left the "update"programm and are working with the "normal"programm.

Is there any way to close such a connetion without killing the local runtime (And stay connected with the "local"server)?

i hope i could explain my problem well enough.
What you are experiencing is a 'feature' that Acucobol 'added' to the remote connections in version 5.x.

It has been a real pain for us as we had programs that are running for a long time (several weeks). In that time, something (not the client or Acuserver) chops the socket connection and then the client can't communicate with Acuserver. We have to stop the program and re-start it to reconnect.

However, Acu obviously realised there was a problem with the new lingering socket connection method, and in version 6.0 they introduced the "C$DISCONNECT" library routine which does exactly what you want.

Hope this helps.

Cheers.

[Migrated content. Thread originally posted on 29 March 2005]

A little difficult problem:

We have client-server programms.
Server is something like "@192.168.*".

And we have a Server on the internet (used for updates). Sounds like "@wwwserver.*".

If now a installation checks for a update, we open simply a textfile on the webserver an read the newest versionnumber.
Like: open "@wwwserver.*:home/files/text.txt" for input.
And of course close it afterwards.

it works and is stable, but if the client closes the file and the user leaves the form, the connetion is still alive.

A Netstat at our "webserver" shows the connection as establiched and alive until the user closes the hole programm (and therewith the runtime).

With these symptoms it is not easy to manage our updates. We never know if they are still updating oder have already left the "update"programm and are working with the "normal"programm.

Is there any way to close such a connetion without killing the local runtime (And stay connected with the "local"server)?

i hope i could explain my problem well enough.
What you are experiencing is a 'feature' that Acucobol 'added' to the remote connections in version 5.x.

It has been a real pain for us as we had programs that are running for a long time (several weeks). In that time, something (not the client or Acuserver) chops the socket connection and then the client can't communicate with Acuserver. We have to stop the program and re-start it to reconnect.

However, Acu obviously realised there was a problem with the new lingering socket connection method, and in version 6.0 they introduced the "C$DISCONNECT" library routine which does exactly what you want.

Hope this helps.

Cheers.
Terms & ConditionsAccessibility statement