DB2 PREP ... PACKAGE USING ... without implicit binding

[Jochen Luebbers]

Hi,

I've a problem:

I compile modules of embedded SQL (for a dynamic lib) on multiple
platforms (AIX,Linux,Wind ows). They are compiled from the same
source code. To be able to provide all platforms at the same time
on ONE database (server), I want different package names -
e.g. module1.sqc should produce packages AMOD1, LMOD1, and WMOD1.
So I tried the following db2 call for preparing:
DB2 PREP module1.sqc BINDFILE USING amod1.bnd PACKAGE USING amod1 [...]

It does all I want AND a little bit more: On DB2 V7 it binds the
newly created package implicitly! And that is a nightmare, because
I sometimes just compile the module, to be sure, that it is still
compilable on all platforms, after a changed a bit on one platform.

It there any way to name the package as I want/need, without binding it
in the same step???

Thanks for your help,
J. Luebbers

--
Jochen Lübbers lu******@tde-online.de
Software Development Group I TDE - Tele Data Electronic GmbH
"Who desire to give up freedom in order to gain security
will loose both in the end." (Benjamin Franklin)

[Knut Stolze]

Jochen Luebbers wrote:

Knut Stolze <st****@de.ibm. com> wrote:

First, what's the problem with the implicit binding?

I want to be able to create (by now) up to three packages for the three
different platforms (AIX, Linux, and Windows) with the same database.
These packages should be usable at the same time with this database.
They are created from the same (or nearly the same) source code, but
in every case, they are created from the same source file.
I want to avoid a mechanism, that renames the source file just
before precompiling it. But at the same time I want to have unique
packages (to satisfy the above points).

So I tried a the command:
DB2 PREP module1.sqc BINDFILE USING amod1.bnd PACKAGE USING amod1

So far it did everything I wanted.
This module is part of a dynamic link library. I installed the lib, and
the programs used it - fine.

I went further in development and recompiled the module again -
and got failures from the users of the lib - because by DB2 PREP ... had
implicitly done the binding, thereby cutting of the lib with a -818
message.
Of course, it was my fault, not to read the docu carefully enough, that
I would have known about this.

I am told by the DBA, that the two database servers I develop for
are not DRDA servers (one on AIX, one on Linux). So the LEVEL option,
you pointed to, could not be used.

Two questions here:

(1) What has the LEVEL option to do with DRDA? The manual doesn't give any
such restriction:
http://publib.boulder.ibm.com/infoce...e/r0001964.htm

(2) I'm surprised about the statement that AIX and Linux should not use DRDA
as a protocol to communicate between client and DB server. Where does this
idea stem from originally?

(Maybe that's related to V7, I'm not sure.)

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

[Jochen Luebbers]

Knut Stolze <st****@de.ibm. com> wrote:

Two questions here:

(1) What has the LEVEL option to do with DRDA? Ups, my manual tells so. It is from a DB2 documentation CD - installed
locally - file "sqln0082.h tm"
(/usr/lpp/db2_07_01/doc/en_US/html/db2n0/sqln0082.htm on the AIX box)

The manual doesn't give any such restriction:
http://publib.boulder.ibm.com/infoce...e/r0001964.htm You're right, the documentation on the web does not know about
limitations of the LEVEL option, sorry, I just was reading my local
documentation. Is the web documentation (fully) valid for V7 of DB2?

(2) I'm surprised about the statement that AIX and Linux should not use DRDA
as a protocol to communicate between client and DB server. Where does this
idea stem from originally? A college of mine, how has to do the job of the DBA - but maybe it's not
correct.
(Maybe that's related to V7, I'm not sure.)

Any way, I'll try the LEVEL option this week (regardless of version and
DRDA (or not)) and will give feedback this week or in the beginning of
next week.

And again: Thanks for your help and hints.

J. Luebbers
--
Jochen Lübbers lu******@tde-online.de
Software Development Group I TDE - Tele Data Electronic GmbH
"Who desire to give up freedom in order to gain security
will loose both in the end." (Benjamin Franklin)

[Jochen Luebbers]

The LEVEL option - suggested from Knut Stolze <st****@de.ibm. com> -
works on my system - thanks for this hint.

But it is not really the solution, I'm looking for. Why?
1. I want an automatic generation of the LEVEL, because I tend to
forget to change it manualy, if necessary. Now if shifted the
problem only to an other part of the development system (Makefile).
2. I still can not compile code "just for fun" - better saying for
simple testing - without binding in the same step. If I change the
LEVEL, because I changed a lot in the test code, the normal user
gets an -818 error, if I do not change it the code will also not
run any more, because I *did the bind* with an unpassable bindfile.

So, is there really no way, to name the package without binding at the
same time? Hello developers of IBM, here my wish, would that be a nice
feature for the next fixpack/release?

Greetings from an xsnowy display
Jochen Luebbers.
--
Jochen Lübbers lu******@tde-online.de
Software Development Group I TDE - Tele Data Electronic GmbH
"Who desire to give up freedom in order to gain security
will loose both in the end." (Benjamin Franklin)

[Knut Stolze]

Jochen Luebbers wrote:

The LEVEL option - suggested from Knut Stolze <st****@de.ibm. com> -
works on my system - thanks for this hint.

But it is not really the solution, I'm looking for. Why?
1. I want an automatic generation of the LEVEL, because I tend to
forget to change it manualy, if necessary. Now if shifted the
problem only to an other part of the development system (Makefile).
You could use the "db2bfd" executable ane verify that nothing relevant has
changed:

db2bfd -b sqllib/bnd/gseExport.bnd

This will dump some information of the bind file. Now you can check if
numHVars, numStmt or some other property of the bind file changed due to
your modifications. If that's the case, then you need a new LEVEL because
the packages changed and your customers have to rebind anyways. Otherwise,
the previous bind file is still in sync with your code and you don't have
to rebind.
2. I still can not compile code "just for fun" - better saying for
simple testing - without binding in the same step. If I change the
LEVEL, because I changed a lot in the test code, the normal user
gets an -818 error, if I do not change it the code will also not
run any more, because I *did the bind* with an unpassable bindfile.
What it comes down to is the decision when you have to change the LEVEL. If
you change it, you tell DB2 that this is virtually a new package and, of
course, DB2 won't run it for an old program. If you don't change it but
you did modify the SQL statements in the package, then things are also
screwed up.
So, is there really no way, to name the package without binding at the
same time? Hello developers of IBM, here my wish, would that be a nice
feature for the next fixpack/release?

I still don't understand why avoiding an implicit bind would help you there.
You have to manage your versions of the code is such a way that the
versions of the corresponding bind files/packages matches. That's all.

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

[Jochen Luebbers]

Knut Stolze <st****@de.ibm. com> wrote:

I still don't understand why avoiding an implicit bind would help you
there.

Because I've to develop on a production system. So, if I want to build
a new - maybe trial - version, I've to wait, until all other had gone.

What I dislike, is, that just *building* the new version, can kick off
the other users, only because I want to give the package a specific
name, and not just the first 8 chars of the .sqc file name (which,
for some historic reason all start with lzg_ what makes the effective
part only 4 chars long/short).

You're right, I'll never be able to use two versions of the same package
at the same time. But I just want to be able to recompile my code, even
if the package has changed a lot, and I need (re-)compilings of the code
(because I've sometimes mistakes in my code :-) ).

And because we're a very small company, I've no development system
for my own.

Thank you for having patience with me.

J. Luebbers
--
Jochen Lübbers lu******@tde-online.de
Software Development Group I TDE - Tele Data Electronic GmbH
"Who desire to give up freedom in order to gain security
will loose both in the end." (Benjamin Franklin)

[Gert van der Kooij]

In article <ub************ @tux.tde-online.de>, Jochen Luebbers
(lu******@tde-online.de) says...

You're right, I'll never be able to use two versions of the same package
at the same time. But I just want to be able to recompile my code, even
if the package has changed a lot, and I need (re-)compilings of the code
(because I've sometimes mistakes in my code :-) ).

And because we're a very small company, I've no development system
for my own.

If you create a database with the same tables without or with a small
amount of data you can compile against it without disturbing the
production users. After that you can use the generated bind files to
bind with the needed options against the production db.
All you have to do is keep the table definitions in both db's in
sync.

[Knut Stolze]

Jochen Luebbers wrote:

Knut Stolze <st****@de.ibm. com> wrote:

I still don't understand why avoiding an implicit bind would help you
there. Because I've to develop on a production system. So, if I want to build
a new - maybe trial - version, I've to wait, until all other had gone.

That's an interesting way to do development...
What I dislike, is, that just *building* the new version, can kick off
the other users, only because I want to give the package a specific
name, and not just the first 8 chars of the .sqc file name (which,
for some historic reason all start with lzg_ what makes the effective
part only 4 chars long/short).
I think we discussed this already in detail - you can choose your own
package name.
You're right, I'll never be able to use two versions of the same package
at the same time. But I just want to be able to recompile my code, even
if the package has changed a lot, and I need (re-)compilings of the code
(because I've sometimes mistakes in my code :-) ).

And because we're a very small company, I've no development system
for my own.

Why don't you install the Personal Developer Edition? Or use, as Gert
suggested, a separate database. You activate that database before your
build process starts and deactivate it afterwards. When it is deactivated,
it doesn't consume any resources (except a bit of disk space).
Furthermore, you can do your development stuff without having to wait
"until all others have gone".

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

[Jochen Luebbers]

Knut Stolze <st****@de.ibm. com> wrote:

Why don't you install the Personal Developer Edition? Can the two DB2 system coexist at the same time on the same system?
Or use, as Gert suggested, a separate database.

That sounds good, sorry, I might have been a little bit blind...

J. Luebbers
--
Jochen Lübbers lu******@tde-online.de
Software Development Group I TDE - Tele Data Electronic GmbH
"Who desire to give up freedom in order to gain security
will loose both in the end." (Benjamin Franklin)