Client connection fails with SQL0973N Not enough storage in MON_HEAP_SZ

[zamolxe]

Only one client can connect to DB2 at a time from our office. Once a
connection is established, anybody trying to connect gets the message
"SQL0973N Not enough storage is available in the "MON_HEAP_SZ" heap
to process the statement. SQLSTATE=57011".

Multiple connections were possible before, but then something changed
somewhere (probably on the server). Funny thing is, people in other
locations don't have this problem connecting to the same database.

DB2 instance:
DB21085I Instance "db2inst1" uses "32" bits and DB2 code release
"SQL08015"
with level identifier "02060106".
Informational tokens are "DB2 v8.1.1.48", "s040212", "U496793", and
FixPak "5".
Product is installed at "/usr/opt/db2_08_01".

Database monitor heap size (4KB) (MON_HEAP_SZ) = 90

The clients are a mixture of Admin client Fixpack 5 and Fixpack 8:
================================================== ==========
About DB2 Administration Tools Environment
================================================== ==========
DB2 administration tools level:
Product identifier SQL08020
Level identifier 03010106
Level DB2 v8.1.7.445
Build level s040812
PTF WR21342
================================================== ==========
Java development kit (JDK):
Level IBM Corporation 1.4.1
================================================== ==========

Any ideas ?

Thank you
momirlan

[Mark Yudkin]

"zamolxe" <mo******@yahoo.com> wrote in message
news:6e**************************@posting.google.c om...

Only one client can connect to DB2 at a time from our office. Once a
connection is established, anybody trying to connect gets the message
"SQL0973N Not enough storage is available in the "MON_HEAP_SZ" heap
to process the statement. SQLSTATE=57011".

Multiple connections were possible before, but then something changed
somewhere (probably on the server). Funny thing is, people in other
locations don't have this problem connecting to the same database.

DB2 instance:
DB21085I Instance "db2inst1" uses "32" bits and DB2 code release
"SQL08015"
with level identifier "02060106".
Informational tokens are "DB2 v8.1.1.48", "s040212", "U496793", and
FixPak "5".
Product is installed at "/usr/opt/db2_08_01".

Database monitor heap size (4KB) (MON_HEAP_SZ) = 90

The clients are a mixture of Admin client Fixpack 5 and Fixpack 8:
================================================== ==========
About DB2 Administration Tools Environment
================================================== ==========
DB2 administration tools level:
Product identifier SQL08020
Level identifier 03010106
Level DB2 v8.1.7.445
Build level s040812
PTF WR21342
================================================== ==========
Java development kit (JDK):
Level IBM Corporation 1.4.1
================================================== ==========

Any ideas ?

Turn off monitoring and/or increase MON_HEAP_SZ, as the message says
Thank you
momirlan

[zamolxe]

Monitoring is there for a reason. As for the MON_HEAP_SZ, that is not
under our control, and would be very hard to change (the server is on
a client site).

How come people from other offices don't experience the same problem ?
I suspect the problem is located on the windows machines or on the
local network segment, maybe related to some windows 2000 patch (there
were some applied recently).

Thanks anyway,
momirlan

"Mark Yudkin" <my***********************@nospam.org> wrote in message news:<ch**********@ngspool-d02.news.aol.com>...

"zamolxe" <mo******@yahoo.com> wrote in message
news:6e**************************@posting.google.c om...

Only one client can connect to DB2 at a time from our office. Once a
connection is established, anybody trying to connect gets the message
"SQL0973N Not enough storage is available in the "MON_HEAP_SZ" heap
to process the statement. SQLSTATE=57011".

Multiple connections were possible before, but then something changed
somewhere (probably on the server). Funny thing is, people in other
locations don't have this problem connecting to the same database.

DB2 instance:
DB21085I Instance "db2inst1" uses "32" bits and DB2 code release
"SQL08015"
with level identifier "02060106".
Informational tokens are "DB2 v8.1.1.48", "s040212", "U496793", and
FixPak "5".
Product is installed at "/usr/opt/db2_08_01".

Database monitor heap size (4KB) (MON_HEAP_SZ) = 90

The clients are a mixture of Admin client Fixpack 5 and Fixpack 8:
================================================== ==========
About DB2 Administration Tools Environment
================================================== ==========
DB2 administration tools level:
Product identifier SQL08020
Level identifier 03010106
Level DB2 v8.1.7.445
Build level s040812
PTF WR21342
================================================== ==========
Java development kit (JDK):
Level IBM Corporation 1.4.1
================================================== ==========

Any ideas ?

Turn off monitoring and/or increase MON_HEAP_SZ, as the message says

Thank you
momirlan

[Mark Yudkin]

We don't experience this problem as we set MON_HEAP_SZ large enough to
support the monitoring we perform. The "problem" as you call it has little
to do with the things you mention. The default monitor heap size is small,
and needs altering if you intend to carry out non-trivial monitoring. As
such, there is in fact no problem.

"zamolxe" <mo******@yahoo.com> wrote in message
news:6e**************************@posting.google.c om...

Monitoring is there for a reason. As for the MON_HEAP_SZ, that is not
under our control, and would be very hard to change (the server is on
a client site).

How come people from other offices don't experience the same problem ?
I suspect the problem is located on the windows machines or on the
local network segment, maybe related to some windows 2000 patch (there
were some applied recently).

Thanks anyway,
momirlan

"Mark Yudkin" <my***********************@nospam.org> wrote in message

news:<ch**********@ngspool-d02.news.aol.com>...

"zamolxe" <mo******@yahoo.com> wrote in message
news:6e**************************@posting.google.c om...

Only one client can connect to DB2 at a time from our office. Once a
connection is established, anybody trying to connect gets the message
"SQL0973N Not enough storage is available in the "MON_HEAP_SZ" heap
to process the statement. SQLSTATE=57011".

Multiple connections were possible before, but then something changed
somewhere (probably on the server). Funny thing is, people in other
locations don't have this problem connecting to the same database.

DB2 instance:
DB21085I Instance "db2inst1" uses "32" bits and DB2 code release
"SQL08015"
with level identifier "02060106".
Informational tokens are "DB2 v8.1.1.48", "s040212", "U496793", and
FixPak "5".
Product is installed at "/usr/opt/db2_08_01".

Database monitor heap size (4KB) (MON_HEAP_SZ) = 90

The clients are a mixture of Admin client Fixpack 5 and Fixpack 8:
================================================== ==========
About DB2 Administration Tools Environment
================================================== ==========
DB2 administration tools level:
Product identifier SQL08020
Level identifier 03010106
Level DB2 v8.1.7.445
Build level s040812
PTF WR21342
================================================== ==========
Java development kit (JDK):
Level IBM Corporation 1.4.1
================================================== ==========

Any ideas ?

Turn off monitoring and/or increase MON_HEAP_SZ, as the message says

Thank you
momirlan

[zamolxe]

You are repeating the same message, and I cannot change the
MON_HEAP_SZ.
My question is now:
Why dozens of people from other networks can connect to this server,
and our office cannot ?

momirlan

"Mark Yudkin" <my***********************@nospam.org> wrote in message news:<ch**********@ngspool-d02.news.aol.com>...

We don't experience this problem as we set MON_HEAP_SZ large enough to
support the monitoring we perform. The "problem" as you call it has little
to do with the things you mention. The default monitor heap size is small,
and needs altering if you intend to carry out non-trivial monitoring. As
such, there is in fact no problem.

"zamolxe" <mo******@yahoo.com> wrote in message
news:6e**************************@posting.google.c om...

Monitoring is there for a reason. As for the MON_HEAP_SZ, that is not
under our control, and would be very hard to change (the server is on
a client site).

How come people from other offices don't experience the same problem ?
I suspect the problem is located on the windows machines or on the
local network segment, maybe related to some windows 2000 patch (there
were some applied recently).

Thanks anyway,
momirlan

"Mark Yudkin" <my***********************@nospam.org> wrote in message

news:<ch**********@ngspool-d02.news.aol.com>...

"zamolxe" <mo******@yahoo.com> wrote in message
news:6e**************************@posting.google.c om...
> Only one client can connect to DB2 at a time from our office. Once a
> connection is established, anybody trying to connect gets the message
> "SQL0973N Not enough storage is available in the "MON_HEAP_SZ" heap
> to process the statement. SQLSTATE=57011".
>
> Multiple connections were possible before, but then something changed
> somewhere (probably on the server). Funny thing is, people in other
> locations don't have this problem connecting to the same database.
>
> DB2 instance:
> DB21085I Instance "db2inst1" uses "32" bits and DB2 code release
> "SQL08015"
> with level identifier "02060106".
> Informational tokens are "DB2 v8.1.1.48", "s040212", "U496793", and
> FixPak "5".
> Product is installed at "/usr/opt/db2_08_01".
>
> Database monitor heap size (4KB) (MON_HEAP_SZ) = 90
>
> The clients are a mixture of Admin client Fixpack 5 and Fixpack 8:
> ================================================== ==========
> About DB2 Administration Tools Environment
> ================================================== ==========
> DB2 administration tools level:
> Product identifier SQL08020
> Level identifier 03010106
> Level DB2 v8.1.7.445
> Build level s040812
> PTF WR21342
> ================================================== ==========
> Java development kit (JDK):
> Level IBM Corporation 1.4.1
> ================================================== ==========
>
> Any ideas ?
Turn off monitoring and/or increase MON_HEAP_SZ, as the message says

> Thank you
> momirlan