SEO

Hi,

I have problem with db2 8.1.2. I guess that the origin of the problem
could be my select clause because I use IN operand with huge amount of
items like 'SELECT * FROM TABLE WHERE FIELD IN (1, 2, ...,400)'.

The error that db2 gives randomly is

[IBM][CLI Driver][DB2/NT] SQL0805N Hakusuunnitelmaobjektia
"NULLID.SYSLH203 0X5359534C564C3031" ei ole löytynyt. SQLSTATE=51002

That finnish part 'Hakusuunnitelma' means something like IndexObject and
'ei ole löytynyt' means not found.

Is there some limit there how many items there can be used with IN
operand? Or does anyone have any other ideas what should I do?

"erkki" <mail125@operamail.com> wrote in message
news:MMtWb.1099$CO2.87@read3.inet.fi...
> Hi,
>
> I have problem with db2 8.1.2. I guess that the origin of the problem
> could be my select clause because I use IN operand with huge amount of
> items like 'SELECT * FROM TABLE WHERE FIELD IN (1, 2, ...,400)'.
>
> The error that db2 gives randomly is
>
> [IBM][CLI Driver][DB2/NT] SQL0805N Hakusuunnitelmaobjektia
> "NULLID.SYSLH203 0X5359534C564C3031" ei ole löytynyt. SQLSTATE=51002
>
> That finnish part 'Hakusuunnitelma' means something like IndexObject and
> 'ei ole löytynyt' means not found.
>
> Is there some limit there how many items there can be used with IN
> operand? Or does anyone have any other ideas what should I do?
>
In the past there has been a limit, but I don't know what it is, or whether
it has been recently lifted. Probably the best choice is load the valid
values into a another table and do a sub-query.

erkki <mail125@operamail.com> wrote:

> Hi,
>
> I have problem with db2 8.1.2. I guess that the origin of the problem
> could be my select clause because I use IN operand with huge amount of
> items like 'SELECT * FROM TABLE WHERE FIELD IN (1, 2, ...,400)'.
>
> The error that db2 gives randomly is
>
> [IBM][CLI Driver][DB2/NT] SQL0805N Hakusuunnitelmaobjektia
> "NULLID.SYSLH203 0X5359534C564C3031" ei ole löytynyt. SQLSTATE=51002
>
> That finnish part 'Hakusuunnitelma' means something like IndexObject and
> 'ei ole löytynyt' means not found.

SQL0805 says: Package not found.

I strongly doubt that this has anything to do with your IN clause. Make
sure that all the packages are properly bound (CLI and such).
Unfortunately, I don't know what kind of package SYSLH203 is...

--
Knut Stolze
Information Integration
IBM Germany / University of Jena

> Unfortunately, I don't know what kind of package SYSLH203 is...

.... having to do with the db2jdbcbind command...
L : large package (385 sections)
H : with hold
2 : some isolation level i think (rr, rs, cs, ur, ...)
03 is a sequence number

Doc describes them as :
Table 35. DB2 CLI Bind Files and Package Names

Dynamic Placeholders - Large Package WITH HOLD


Using db2jdbcbind with the -size 20 option may solve the problem?

Do you have packages like this in your db?
SYSLH200
SYSLH201
SYSLH202
SYSLH203
SYSLH204
SYSLH205
SYSLH206
SYSLH207
SYSLH208
SYSLH209
SYSLH20A
SYSLH20B
SYSLH20C
SYSLH20D
SYSLH20E
SYSLH20F
SYSLH210
SYSLH211
SYSLH212
SYSLH213

Also verify that someone bound db2schema.bnd on the server. (this may also
be missing if the packages are not there.)

PM

Great!

First I installed FixPack 4 but that did not help. Then i checked that
there was

SYSLH200
SYSLH201
SYSLH202
SYSLH203

Packages in my system. After that I ran that db2jdbcbind with -size 20
and now I have packages from SYSLH200 to SYSLH413. And now the system is
working well so far...

I have absolutely no idea what I just did... This seemed to be stuff
normal developer should not usually be involved with. Do I have to be
woried about of something related to this operation?

Is this the think I have to do with every DB2 database when start to use
it with Java applications?

I'll be eternally gratefull.

PM (pm3iinc-nospam) wrote:
>>Unfortunately, I don't know what kind of package SYSLH203 is...
>
>
> ... having to do with the db2jdbcbind command...
> L : large package (385 sections)
> H : with hold
> 2 : some isolation level i think (rr, rs, cs, ur, ...)
> 03 is a sequence number
>
> Doc describes them as :
> Table 35. DB2 CLI Bind Files and Package Names
>
> Dynamic Placeholders - Large Package WITH HOLD
>
>
> Using db2jdbcbind with the -size 20 option may solve the problem?
>
> Do you have packages like this in your db?
> SYSLH200
> SYSLH201
> SYSLH202
> SYSLH203
> SYSLH204
> SYSLH205
> SYSLH206
> SYSLH207
> SYSLH208
> SYSLH209
> SYSLH20A
> SYSLH20B
> SYSLH20C
> SYSLH20D
> SYSLH20E
> SYSLH20F
> SYSLH210
> SYSLH211
> SYSLH212
> SYSLH213
>
> Also verify that someone bound db2schema.bnd on the server. (this may also
> be missing if the packages are not there.)
>
> PM
>
>

Note : There's also a FP4.a to fix some FP4 problems.

db2jdbcbind and db2schema.bnd related actions are documented in the fixpack
and release notes.

I bet you chose to use the install and pray procedure. ;-)
As you mentionned, this is DBA stuff and developpers are not necessarely
aware of this procedure.

As stated in my previous post, if you had problems with those packages,
there is also a chance that
the actions required on db2schema.bnd never occured.
Read the fixpack / release notes or see those related threads.
http://groups.google.ca/groups?hl=en...abases.ibm-db2

In v8, some packages are shared between jdbc, sqlj, odbc, cli applications.
Any of these could potentially use these packages.
This is normally done at install time on the server but may require
maintenance.
e.g. redo it after fixpack install, problems, special requirements, ...

Never been able to confirm this is required but
i also do the following to ensure all interfaces know/use 20 (or x)
packages.
DB2 UPDATE CLI CFG FOR SECTION xxxxx USING CLIPKG 20
manually bind the @db2cli.lst with CLIPKG 20

http://publib.boulder.ibm.com/infoce...help/index.jsp
search for : CLIPKG

PM