A legacy application uses Sybase 11.0.3 on OpenVMS. A process
attempts to open a connection to the database using the dblibrary
'dbopen' function, specifying a NULL for the 'server' parameter.
However the connection is refused. The reason is that it is ignoring
the server selected by the DSQUERY logical name (environment variable)
and always using SYB_BACKUP.

I have tried using sybinit to alter the interfaces file, removed all
backup servers completely, used sp_addserver and sp_dropserver to play
with the settings in sysservers, but nothing has helped.

This is a new system that I have set up recently to mimic a customer's
application. Their system does not show this problem, and neither do
any of the systems I have set up before.

Any suggestions are welcome.

Thanks and regards,

Steve

On Jan 7, 2:37*am, Shad <steveshad0... (AT) btinternet (DOT) com> wrote:
How are you determining it is using SYB_BACKUP?

Can you control which interfaces file the application looks at?
If so, you could create an alternate interfaces file with an entry
in it for SYB_BACKUP pointing to the port for the dataserver.

Or perhaps do that in the original interfaces file and name the
real backupserver something else (sysservers would then have
an entry mapping SYB_BACKUP to the real backupserver name).

-bret

Hi Bret,

The application throws an error as follows :

<SYBASE> Msg 4002, Level 14, State 1, Server SYB_BACKUP, Procedure ,
Line 1, : Login failed.

The DSQUERY logical is set to BASLG2_SYB, but is ignored.

I have already tried changing the interfaces file as you suggest, but
it does not seem to work. I will try again and report back.

Thanks,

Steve

This problem is resolved. For information here is what I found.

Further investigation has shown that my client is connecting to the
right server, but that server thinks it has a different name. I can
reproduce the issue from ISQL.

Firstly my interfaces file has entries for servers as follows (with
domain names obscured) :

BASLG2_SYB
query tcp ether baslg2.xxx.xxx.com 5007
master tcp ether baslg2.xxx.xxx.com 5007
BASLG2_BACK
query tcp ether baslg2.xxx.xxx.com 5008
master tcp ether baslg2.xxx.xxx.com 5008

Note that there is no entry for SYB_BACKUP.

Now, from ISQL, with a deliberately incorrect password :

$ isql/u=txpl/p=wrongpwd
Msg 4002, Level 14, State 1:
Server 'SYB_BACKUP', Line 1:
Login failed.
DB-LIBRARY error:
Login incorrect.
%SYBASE-E-ISQLFAIL, ISQL has failed
$

Note SYB_BACKUP reported as server name. However TCP netstat shows
that the connection that serviced this login attempt connected to the
BASLG2_SYB listener port 5007 :

Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign
Address (state)
tcp 0 0 xx.yy.83.53.5007 xx.yy.
83.53.49502 TIME_WAIT

So, it seems that the problem is not with the service request going to
the wrong server, but instead that server has an identity problem.

Looking in sysservers, I had an entry left over from yesterdays
attempts to resolve this problem, with name SYB_BACKUP pointing at
BASLG2_SYB. However, removing this was not enough. I also had to
stop and start the BASLG2_SYB process. Now, all is well.

Thanks and regards,

Steve