Hi,

we have some strange problems with the above error. It occurs on different installation of DB2 version 8.1.0 when using the jdbc type 2 driver. For some time the programs runs fine - but then it happens:

The Stacktrace:

COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0805N Paket "NULL
ID.SYSLH203 0X5359534C564C3031" nicht gefunden. SQLSTATE=51002

at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_S QLException(Unknown
Source)
at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_S QLException(Unknown
Source)
at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.check_r eturn_code(Unknown
Source)
at COM.ibm.db2.jdbc.app.DB2PreparedStatement.execute2 (Unknown Source)
at COM.ibm.db2.jdbc.app.DB2PreparedStatement.executeQ uery(Unknown Source
)
at de.synthesis.persist.jdbc.JDBCOidGenerator.getNext (JDBCOidGenerator.j
ava:54)
at de.synthesis.persist.jdbc.JDBCOidGenerator.getNext (JDBCOidGenerator.j
ava:36)
at de.synthesis.core.oid.OidGenerator.getOid(Unknown Source)
at de.synthesis.persist.jdbc.JDBCPersistenceAdapter.g etOid(JDBCPersisten
ceAdapter.java:96)
at de.synthesis.model.base.ModelObjectCreator.create( Unknown Source)
at de.synthesis.model.server.impl.FatClientModelObjec tHomeImpl.create(Un
known Source)

Is there a solution - anywhere ??????

TIA

Stephan

db2 bind @db2cli.bnd blocking all grant public
db2 bind @db2ubind.bnd blocking all grant public

from the client

Cheers
Sathyaram

try using db2jdbcbind found in the bin directory. This is supposed to bind all the default NULLID packages if collection is not specified . Try using a size of 20. port number of 50000 / 5000( i m not sure)

Usage:

java com.ibm.db2.jcc.DB2Binder
-url jdbc:db2://<server name>:<port number>/<database name>
-user <userName>
-password <password>
[-size <number of dynamic JCC packages bound for each isolation and holdabil
ity>]
[-collection <ollection to bind the JDBC packages, default is NULLID>]
[-tracelevel <comma-delimited list of jcc trace options>]
[-action { add | replace }]
[-keepdynamic { no | yes }]
[-reopt once]
[-help]

-user
The user must have bind authority.
Access to the JCC packages will be granted to public.

-size
The number of internal JCC packages to bind for each DB2 isolation and holda
bility.
The default is 3.
Since there are 4 DB2 transaction isolations and 2 cursor holdabilities,
there will be 4x2=8 times as many dynamic packages bound as are specified by
this option.
In addition, a single static package for JCC's internal use is always bound.


-collection
The collection ID for JCC's internal packages for JDBC.
The default is NULLID.
May be used by DBA's to create multiple instances of the JCC package set.
This option may only be used in conjunction with the connection/datasource p
roperty jdbcCollection.
Also see documentation for JCC DB2BaseDataSource.jdbcCollection.

-tracelevel
Used to turn tracing on or off, and to specify the granularity of tracing.
Trace level options are defined by the JCC JDBC driver traceLevel data sourc
e property.
See documentation for JCC DB2BaseDataSource.traceLevel for a complete descri
ption.
For complete tracing, use TRACE_ALL. Not all of the JCC JDBC trace level op
tions
are meaningful for DB2Binder, but the complete options are:
TRACE_ALL,TRACE_CONNECTION_CALLS,TRACE_CONNECTS,TR ACE_DIAGNOSTICS,TRACE_DRDA_FLO
WS,TRACE_DRIVER_CONFIGURATION,TRACE_NONE,TRACE_PAR AMETER_META_DATA,TRACE_RESULT_
SET_CALLS,TRACE_RESULT_SET_META_DATA,TRACE_SQLJ,TR ACE_STATEMENT_CALLS,TRACE_XA_C
ALLS

-action
Indicates whether the packages can be added or replaced.
The default is "add".
"add" indicates that a new package to be created only if it does not exist a
lready.
"replace" indicates that a new package is created to replace any existing pa
ckage.

-keepdynamic
Determines whether DB2 keeps dynamic SQL statements after commit points.
Supported by DB2 for OS/390 only.
This option is not sent if not specified. Thus, the default depends on serve
r.
"no" specifies that DB2 does not keep dynamic SQL statements after commit po
ints.
"yes" specifies that DB2 keeps dynamic SQL statements after commit points.

-reopt once
Specifies whether to have DB2 determine an access path at run time only once
,
and use that access path afterwards.
Supported by DB2 for OS/390 only.
This option is not sent if not specified. Thus, the default depends on serve
r.

Hi all,

the solution is as follows: we had to many open statments/prepared statements inside the underlying framework. So the DB2 client runs out of resources and comes up with the above mentioned error message.

We splitted the program into parts - and all worked well (of course freeing unneeded resources inside the framework is a better solution).

thanks a lot

Stephan

I am also experiencing this SYSLH203 problem and am not sure how to resolve it.

The specific circumstances in which I'm encountering this is with an application that I wrote which reads data from a file and either updates existing rows or writes new rows to the database depending on what was previously there.

While the problem can be made go away by running
db2cli.bnd and db2ubind.bnd
I don't understand why I have to do this on a new DB. Same version of DB2 on client and server.

With Over 4000 rows to be inserted in the DB, I get following error 162 times:
[IBM][CLI Driver][DB2/6000] SQL0805N Package "NULLID.SYSLH203 0X5359534C564C3031" was not found. SQLSTATE=51002
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/6000] SQL0805N Package "NULLID.SYSLH203 0X5359534C564C3031" was not found. SQLSTATE=51002

My error reporting isn't smart enough for me to see what the pattern of recurrance of the issue is.

I've been searching the web for info on this and seeing stuff about type 2 drivers, type 4 drivers etc. I'm just pretty confused as to what it's all about.

Following gives some explanation:
http://www-106.ibm.com/developerwork...ikopoulos.html

Don't understand this package thing too well but does the suggestion re. using java com.ibm.db2.jcc.DB2Binder not apply to type 4 driver whereas my error with "CLI Driver" indicates type 2 driver. Am using db2java.zip.

Stephen, re.
"we had to many open statments/prepared statements inside the underlying framework. So the DB2 client runs out of resources and comes up with the above mentioned error message. We splitted the program into parts - and all worked well (of course freeing unneeded resources inside the framework is a better solution)"

any good for a dummies guide as to what this is about? Could you point me to any useful info etc.? I got another developer here to look at this thread and at my code and he couldn't visibly see what the problem was. I put in commits at an interval determined by a value in a properties file but it doesn't appear to have helped.

I'm very new to all of this and if I cannot fix up the data import application we'll have to document this in the release notes and tell people to bind databases before running data import - obviously not an ideal situation. Release is at end of week. Last build is technically tomorrow ;-(

Hi,

Some time ago the following was posted by Joerg Sailer to the newsgroup comp.databases.ibm-db2 (you can find it searching the Google Groups).

I hope this also solves your problem.

Kind regards, Gert

== Copied text from newsgroup message ==

Hello,
again thanks for your help. Now I have solved the problem, the following things we had to do:

increase APPLHEAPSZ to 16384
increase MAXAPPLS to 50 -> (PCKCACHE increases automatic)
doing jdbcbind

The reason for the problem was that firstof all the PCKCACHE was to small because the MAXAPPLS - param is by default set to AUTOMATIC. The jdbcbind with the DB2Binder-Class does not catch the Exception "not enough pckcache" in a correct way. The package will be marked as bound although the package is not really bound to the database. After the increase of the MAXAPPLS to 50 the jdbcbind runs fine and the packages are really bound. Then we were able to increase the applheapsz and now everything runs fine.

================