Getting %SYSTEM-F-LINKDISCON, network partner disconnected logical link when using oracle sql-server

[Jan Lund Svensson_1]

I am running VMS 7.3.2 and Oracle rdb 7.1.2.1
The SQL-server start working fine, but after it have been running for some time it stops working for remote access using forms and ODBC.
The SQS_xxx_disyyy.log file have the following information:

---EVENT BEG: EVENT_LOG ------------------------ Tue Jul 5 13:04:45.670 2005---
%SQLSRV-I-EVENT_LOG, event logged at line 2828 in file CMD.C;1
%SQLSRV-I-CONNECTNAME, Connect : CONNECT_0000026
%SQLSRV-I-CONNECTSTATE, Connect state: 4
%SQLSRV-I-USERNAME, User name: xxxx
%SQLSRV-I-NODENAME, Node : x.x.x.x
%SQLSRV-I-APPLNAME, Application : ifrun60
%SQLSRV-I-SERVICENAME, Service : GENERIC
---EVENT END: EVENT_LOG ------------------------ Tue Jul 5 13:04:45.670 2005---

---EVENT BEG: EVENT_LOG ------------------------ Tue Jul 5 13:04:46.480 2005---
%SQLSRV-I-EVENT_LOG, event logged at line 4455 in file COM_DIALOG.C;1
%SQLSRV-E-READERR, Error on read
%SYSTEM-F-LINKDISCON, network partner disconnected logical link---EVENT END: EVENT_LOG ------------------------ Tue Jul 5 13:04:46.480 2005---

---EVENT BEG: EVENT_LOG ------------------------ Tue Jul 5 13:04:46.500 2005---
%SQLSRV-I-EVENT_LOG, event logged at line 286 in file DISP.C;1
%SQLSRV-W-EXCEPTION_RAISE, Exception raised: DBS_SYSERVICEFAILED
%SQLSRV-I-CONNECTNAME, Connect : CONNECT_0000026
%SQLSRV-I-CONNECTSTATE, Connect state: 2
%SQLSRV-I-USERNAME, User name: x
%SQLSRV-I-NODENAME, Node : x.x.x.x
%SQLSRV-I-APPLNAME, Application : ifrun60
%SQLSRV-I-SERVICENAME, Service : GENERIC
---EVENT END: EVENT_LOG ------------------------ Tue Jul 5 13:04:46.500 2005---

I have not been able to find any clue on the internet about what could cause for this.
Since it help to restart the SQL-server I expect it might be the SQL-server or the TCP interface that got a problem.
Any suggestions are very appreciated.

[Jan van den Ende]

Jan,

Based on VMS 7.3-2, and node-id x.x.x.x, (so, using TCPIP, and not DECnet)
I will try a wild guess:
You are using -- HP -- TCPIPSERVICES (not Multinet) -- AND -- you recently upgraded it/installed a new ECO level.

Remember, TCPIP is maintained to Unix standards, so the VMS principle "do NOT break existing code" is regularly ignored.

One of the things recently changed was the mechanism of Keepalive.

It used to be fixed ON, now it is configurable, default OFF (!)

If this seems to be your case:

@SYS$MANAGER:TCPIP$DEFINE_COMMANDS

sysconfig -h ! for various options.

choose what you think you need.

hth,

Proost.

Have one on me.

jpe

[Antoniov.]

jpe now you are quicker than me ;-)

Jan,
LINKDISCON is a bad beast.
About another trouble like your but using telnet, HP hints to check for PAGEFILE and SWAPFILE
http://h71000.www7.hp.com/wizard/wiz_2258.html

In my mind your trouble is at TCP/IP level. This documentaion may help you
http://h71000.www7.hp.com/doc/732final/6631/6631pro_contents.html

Antonio Vigliotti

[Jan van den Ende]

Yeah.

Antonio, documentation may be Jan's trouble.

Remember my gripe about Unix-style code maintenance?
The "beautiful" part of the TCPIP patches is that they did NOT take the trouble to document this!
(at least not that we, and some others that were initially hit, could detect).
Seems we should get used to non-VMS standards...

Proost.

Have one on me.

jpe

[Robert Gezelter]

Jan,

Also, check the logs on the SERVER side of the connection for any oddities.

LINKDISCON can be caused be any number of causes, one of which is often a failure of some kind on the applications side.

If both sides of the connection report LINKDISCON and similar errors (i.e., errors from the network stack), then I would suspect the network or the network stack as the source of the problem.

I hope that the above is helpful!

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Just some more specifics on the "keepalive" issue:

In this case, the connection was via a firewall, and the firewall disconnected the connection when no data was passing for the timeout period.
The keepalive used to supply some data, but without keepalive messages ....

hth,

Proost.

Have one on me.

jpe

[Jan Lund Svensson_1]

Thanks everybody (--)
We saw this problem also when we were running VMS 7.2.1 but did not get any trace at that time.
It is very difficult to reproduce and might take 2 month until it appears again.
I will start checking with autogen pagefile and swapfile sizes if that could be the problem.

[Wim Van den Wyngaert]

We had a simular problem in 2002.
X emulator Kea!x was used on a PC.
VMS simply terminated the connection (TCP).
This while communication seemed normal (we took a tcptrace and saw normal traffic). It happened every few days on 6.2 with ucx 4.2.

In accounting we found "error on read" as the final message.

A protocol error ? I'm going to check if 7.3 still has the problem.

Wim

[Guinaudeau]

>>> One of the things recently changed was the mechanism of Keepalive. It used to be fixed ON, now it is configurable, default OFF (!)

you mean probably :

$ mc tcpip$sysconfig -q inet tcp_keepalive_default
inet:
tcp_keepalive_default = 0

i looked at our systems, the recent change was already in TCP/IP Alpha Version V5.1 - ECO 5. do you mean the TCPIP version 5 itself ?

>>> Remember, TCPIP is maintained to Unix standards, so the VMS principle "do NOT break existing code" is regularly ignored.

we dont get use with non-VMS standard until now, but we enforced recently a "baseline" strategy on our VMS systems. We really minimize the installation of patches when they are not UPDATE aggregate, and we trend to have as much as possible the same release and patch level by most customers. We cannot avoid small differences where one customer uses one VMS product (eg, DCPS or Advanced Server) and the other one does not. but we attempt to have as few baselines as possible on the base system. Not obvious, sometimes we are forced to install the patch (first on test platform, then on customer).

baseline for most of our customers ~ Alpha + (V7.3-2 update 4 + few) + TCPIP V5.4 - ECO 4

as another example of stress we had in 7.3-x release when not working on few "baselines", i observed a lot of troubles with difference in the VMS behaviour at time changeover between subreleases of 7.3-2, depending on patch levels, due to the fact that we cannot use automatic changeover DTSS or AUTO_DLIGHT_SAV for some application reason.

some patches (not only TCPIP) may have been too quickly released and are soon followed by a repair patch.

louis

[Thomas Ritter]

If the focus becomes "keepalive" timers then either having it either off or on can be a problem. Say you are running a "Checkpoint" firewall. Checkpoint can either terminate the connection because of inactivity or terminate the connection because of so called protocol violation caused by keepalive mechanism ! If the keepalive mechanisim is one of those resend an (n-1) packet and expect the receiver to reject it, then the Fireall may terminate the connection before the receive rejects the packet. Within Checkpoint there are many controls outside the CUI that determine how keepalive implementations are handled. Ask the Admin Guys how the firewall handles keepalives ?
My AUS 2 cents.