DBlib connection error: bad file number

DBlib connection error: bad file number

Post by Richa » Fri, 08 Nov 2002 22:03:32



My equipment is new IBM PowerPCs running:
- AIX 4.3.3 (patch level?)
- xlc compiler 4.3.0.1
- Sybase 10.0.2 Server + Client (compiler version used?)

Running isql, or executable "X" compiled with DBlib, from the command
prompt connects fine.  However, some processes fail to connect, and
executable "X" fails to connect when another process executes a
'system' call to spawn "X".  Which seems odd in the case of this
particular executable, for why would it work in one instance and not
another???  Environment?

The errors that I receive are:
- SQL Server connection failed.
- Operating system: Bad file number
OR
- Db-Library error: Unable to connect: SQL Server is unavailable or
does not exist.
- Operating System error: Bad file number

Might the problem be:
- missing patch
- missing subset
- too new compiler
- too new O/S

Unfortunately, I am stuck with this level of Server and Client and
would be very hard to change it forwards or backwards, the other stuff
would be "easier".

Any help, thoughts, or suggestions are appreciated!

 
 
 

DBlib connection error: bad file number

Post by Anthony Mandi » Sat, 09 Nov 2002 12:22:34



> My equipment is new IBM PowerPCs running:
> - AIX 4.3.3 (patch level?)
> - xlc compiler 4.3.0.1
> - Sybase 10.0.2 Server + Client (compiler version used?)

> Running isql, or executable "X" compiled with DBlib, from the command
> prompt connects fine.  However, some processes fail to connect, and
> executable "X" fails to connect when another process executes a
> 'system' call to spawn "X".  Which seems odd in the case of this
> particular executable, for why would it work in one instance and not
> another???  Environment?

        The environment is copied to a subprocess during a system call,
        so its most likely not that.

        Mostly likely, that combination isn't certified by Sybase. If
        IBM doesn't provide some sort of guarantee of binary compatibility,
        you'll have your work cut out.

Quote:> The errors that I receive are:
> - SQL Server connection failed.
> - Operating system: Bad file number
> OR
> - Db-Library error: Unable to connect: SQL Server is unavailable or
> does not exist.
> - Operating System error: Bad file number

        You'd need to use a de* or profiler/tracer of some sort to
        work out where it falls over.

-am     ? 2002

 
 
 

DBlib connection error: bad file number

Post by Richa » Sun, 10 Nov 2002 12:55:53




> > My equipment is new IBM PowerPCs running:
> > - AIX 4.3.3 (patch level?)
> > - xlc compiler 4.3.0.1
> > - Sybase 10.0.2 Server + Client (compiler version used?)

> > Running isql, or executable "X" compiled with DBlib, from the command
> > prompt connects fine.  However, some processes fail to connect, and
> > executable "X" fails to connect when another process executes a
> > 'system' call to spawn "X".  Which seems odd in the case of this
> > particular executable, for why would it work in one instance and not
> > another???  Environment?

>    The environment is copied to a subprocess during a system call,
>    so its most likely not that.

It appears as though the environment is NOT copied identically to the
spawned process because the source of the problem is that the number
of file descriptors reported by the process is 4096, and not 2000!
This does not make sense that executables executed from a command
prompt would use the soft default limit, but if the same executable is
spawned by another executable that I start from the same command
prompt and environment, that it would use the hard default limit???

- Show quoted text -

Quote:

>    Mostly likely, that combination isn't certified by Sybase. If
>    IBM doesn't provide some sort of guarantee of binary compatibility,
>    you'll have your work cut out.

> > The errors that I receive are:
> > - SQL Server connection failed.
> > - Operating system: Bad file number
> > OR
> > - Db-Library error: Unable to connect: SQL Server is unavailable or
> > does not exist.
> > - Operating System error: Bad file number

>    You'd need to use a de* or profiler/tracer of some sort to
>    work out where it falls over.

> -am        ? 2002

Under closed inspection, I chose to confirm both the soft and the hard
limits for the number of file descriptors (nofiles):

HOST> ulimit -a
time(seconds)        unlimited
file(blocks)         2097151
data(kbytes)         131072
stack(kbytes)        32768
memory(kbytes)       32768
coredump(blocks)     2097151
nofiles(descriptors) 2000
HOST> ulimit -a -H
time(seconds)        unlimited
file(blocks)         2097151
data(kbytes)         unlimited
stack(kbytes)        unlimited
memory(kbytes)       unlimited
coredump(blocks)     unlimited
nofiles(descriptors) unlimited
HOST>

Therefore I chose to edit the /etc/security/limits file (which does
not have a default for hard limits) by adding "nofiles_hard = 2000"
and reboot the machine.  Now everything appears to be running fine,
but I am trying to confirm whether I may have broken something by
changing the hard limit(?).

# cat limits
*
* Sizes are in multiples of 512 byte blocks, CPU time is in seconds
*
* fsize      - soft file size in blocks
* core       - soft core file size in blocks
* cpu        - soft per process CPU time limit in seconds
* data       - soft data segment size in blocks
* stack      - soft stack segment size in blocks
* rss        - soft real memory usage in blocks
* nofiles    - soft file descriptor limit
* fsize_hard - hard file size in blocks
* core_hard  - hard core file size in blocks
* cpu_hard   - hard per process CPU time limit in seconds
* data_hard  - hard data segment size in blocks
* stack_hard - hard stack segment size in blocks
* rss_hard   - hard real memory usage in blocks
* nofiles_hard - hard file descriptor limit
*
* The following table contains the default hard values if the
* hard values are not explicitly defined:
*
*   Attribute        Value
*   ==========    ============
*   fsize_hard    set to fsize
*   cpu_hard      set to cpu
*   core_hard         -1
*   data_hard         -1
*   stack_hard        -1
*   rss_hard          -1
*   nofiles_hard      -1
*
* NOTE:  A value of -1 implies "unlimited"
*

default:
        fsize = 2097151
        core = 2097151
        cpu = -1
        data = 262144
        rss = 65536
        stack = 65536
        nofiles = 2000

* Force all instances of nofiles to 2000
        nofiles_hard = 2000

root:

daemon:

bin:

sys:

adm:

uucp:

guest:

nobody:

lpd:

#

 
 
 

DBlib connection error: bad file number

Post by Anthony Mandi » Sun, 10 Nov 2002 13:24:30



> It appears as though the environment is NOT copied identically to the
> spawned process because the source of the problem is that the number
> of file descriptors reported by the process is 4096, and not 2000!
> This does not make sense that executables executed from a command
> prompt would use the soft default limit, but if the same executable is
> spawned by another executable that I start from the same command
> prompt and environment, that it would use the hard default limit???

        What does the system man page say? Perhaps the shell is changed.
        You should be able to check the environment for this even if the
        man page doesn't indicate anything.

Quote:> Therefore I chose to edit the /etc/security/limits file (which does
> not have a default for hard limits) by adding "nofiles_hard = 2000"
> and reboot the machine.  Now everything appears to be running fine,
> but I am trying to confirm whether I may have broken something by
> changing the hard limit(?).

        Since I'm not familiar with AIX, I can't say but I can't see
        how the number of file descriptors would affect it.

-am     ? 2002

 
 
 

1. Bad file number errors using Paradox files on NT

Can anyone give any suggestions as to what may be causing the
"Bad File Number" errors that we continually get when running
a Delphi application that uses Paradox tables which are located
on a Windows NT server?  The application itself is on Windows
for Workgroups 3.11, and it's accessing tables on a remote
Windows NT server.  The errors occur most often when multiple
users are using the data, but even a single user will cause
an error within 5 minutes or so.  Running the same application
on the same data when the data is on another Windows for
Workgroups machine, everything works fine.  Any clues?

------------------------

Programmer Analyst
Institute for the Learning Sciences        (708) 491-9768 (h)
Northwestern University                    (708) 467-1334 (w)
    Web Page:  http://www.ils.nwu.edu/~persiko

2. ASSISTANCE NEEDED

3. BDE ERROR "Bad File number"

4. counting members - Calculated members?

5. BDE Error "Bad file number"?????

6. Sql Server 4.21 performance with ODBC/2.0

7. Run-time error '52': Bad file name or number

8. How do I know....

9. osf1 syb 10.02 (o/s error - bad file number)

10. "Bad file number" error

11. trying to close table iirel_idx:bad file number (unix error 9 )

12. trying to close table iirel_idx:bad file number (unix error 9)