dbinit failed on hpia64 due to 'Allocating a communication buffer failed'

[Former Member]

122 /work/jtli/ra156/RAX-15_5/SQLAny11/bin >dbinit test123.db SQL Anywhere Initialization Utility Version 11.0.1.2045 Allocating a communication buffer failed SQL error (-832) -- Connection error: Found server but communication error occurred Database "test123.db" not created

related env:

SHLIB_PATH=/work/jtli/ra156/RAX-15_5/SQLAny11/lib:/work/jtli/ra156/RAX-15_5/lib/hp64

130 /work/jtli/ra156/RAX-15_5/SQLAny11/lib >ls
libdbextf.so        libdbjodbc11.so     libdbodbc11.so      libdboftsp_r.so     libdbtasks11.so
libdbicu11_r.so     libdblib11.so       libdbodbc11_n.so    libdbscript11_r.so  libdbtasks11_r.so
libdbicudt11.so     libdblib11_r.so     libdbodbc11_r.so    libdbserv11_r.so    libdbtool11_r.so

i installed a SA 12.0 Advanced server edition, and still hit this issue:

140 /work/jtli/sqlanywhere12/bin64 >source sa_config.csh
iAnywhere Solutions, Inc. One Sybase Drive, Dublin, CA 94568, USA
Copyright (c) 2001-2010, iAnywhere Solutions, Inc. Portions copyright (c)
1988-2010, Sybase, Inc. All rights reserved. All unpublished rights reserved.
141 /work/jtli/sqlanywhere12/bin64 >dbinit test123.db
SQL Anywhere Initialization Utility Version 12.0.0.2484
SQL error (-832) -- Connection error: Connection was dropped (may not be a SQL Anywhere server)

[Former Member]

Mark, thank you very much for the quick response. here is the OS info: 174 /work/jtli/sqlanywhere12/bin64 >uname -a HP-UX repqahpi B.11.31 U ia64 3550765068 unlimited-user license if I set SATMP,TEMP and tmp environment variable, dbinit can succesdd with SA 12.0, but dbinit will still fail with SA11.0.1, which is shipped with Replication Agent product. Nov 7, 2010 2:40:08 PM com.sybase.rep.asa.ASAInstanceAdmin log TRACE: dbinit_err: SQL error (-832) -- Connection error: Found server but communication error occurred TRACE: dbinit: Allocating a communication buffer failed

[Former Member]

I think the memory and disk is sufficient, and there is almost 9K free disk in /tmp directory. the same Replication Agent with SA 11.0.1 can work on another hpia64 host, but can't work on this newly setup hpia64 machine.

[Former Member]

Sorry, 9G free disk in /tmp directory

[Former Member]

Mark, can you tell me the incompatibility of the SA 11.0.1 OS/runtime on HPIA? after set SATMMP environemtn variable, I replaced the SA11.0.1 with SA12 in Replication Agent, replication Agen works too, so I want to know the HPIA OS patch level, which is incompatible with SA11.0.1? thanks

[MarkCulp]

The "Allocating a communication buffer failed" error occurs when the communication layer (on either the client or server) is attempting to allocate another communication buffer (in this case a piece of file-backed shared memory) and the allocation failed. This can happen for a number of different reasons:

• there is not an available consecutive piece of address space in the process to satisfy the request
• there is not enough memory and/or backing-store on the computer to satisfy the request
• the process does not have read and/or write permission to the process' "temp" directory in order for it to create/allocate the file which is to be the backing store for the shared memory
• the disk holding your temp directory was full
• some other unforeseen incompatibility of the OS/runtime that is calling a system call to fail

In your specific case (of running dbinit) it is unlikely that the first case (no address space) is the cause of the problem, and I'm going to assume that the second case (no memory or backing store) is unlikely since you would have hopefully seen that the system was short on memory!??

You did not mention which version of HP-UX you were using so I cannot rule out the fifth case (unforeseen incompatibility) but that too is unlikely unless you are using a version of HP-UX that has not been tested before (and HP has introduce a compatibility issue - it wouldn't be the first time that such a thing had happened).

My nickel will go to either the third case (permission problem) or fourth case (full disk). Is it possible that one of these things occurred:

• the "temp" directory was not writable - check your SATMP, TEMP, or TMP environment variable settings and make sure that the value is valid
• the parent directory of the "temp" directory did not exist - e.g. if your "temp" directory was /foo/bar then did the /foo directory exist?
• the temp disk was full
• there was already a database server called 'dbinit_engine' running at the time that you issued the dbinit command and that server's temp directory was not accessible to your dbinit process