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,Windows). 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:

Hi,

I've a problem:

I compile modules of embedded SQL (for a dynamic lib) on multiple
platforms (AIX,Linux,Windows). 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???

I don't know if this would help you but have a look at the LEVEL option (V8
also has a VERSION option) of the precompile command. That way, DB2 won't
use the timestamp of the package to verify that the package is in sync with
your source code.

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

[Jochen Luebbers]

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

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

I don't know if this would help you but have a look at the LEVEL option (V8
also has a VERSION option) of the precompile command. That way, DB2 won't
use the timestamp of the package to verify that the package is in sync with
your source code.

Hmm, that sounds good, I will see, if that will work for me.
Thanks for your hint.

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]

Now a have had a look at the LEVEL option. But unfortunately it is only
supported by DRDA servers :-(

But I need the different package names, to avoid platform conflicts.
The very last work around (for German readers: Würgherum!) would be
to rename the SQC file just before doing the DB2 PREP, but that is
not what I would like to do.

Has such a fine database like DB2 really no "normal" solution for
a problem like this?

Thanks again for all hints and 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)

[Pierre Saint-Jacques]

If you issue your PREPO command with a bindfile parameter and NO package
parameter, you only get a bindfile and NO implicit bind.
You then have to take that bindfile (.bnd) and use in a bind command and
specify a specific package name (amod1, lmod1,...) for each specific
bind command.
So TRY the following db2 call for EACH prepare:

DB2 PREP module1.sqc BINDFILE USING amod1.bnd
DB2 PREP module1.sqc BINDFILE USING lmod1.bnd
DB2 PREP module1.sqc BINDFILE USING wmod1.bnd Then take each bind file to each of their target platform and issue the
BIND command there.

You can also write a script that checks the platform and binds the
proper file for it and then ship everything to all platforms.
I suspect that my DB2 V8.2 on XP has a few bindfiles that are not used
by it but shipped and installed as a genreal procedure.
HTH, Pierre.
Jochen Luebbers wrote: Hi,

I've a problem:

I compile modules of embedded SQL (for a dynamic lib) on multiple
platforms (AIX,Linux,Windows). 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

--
Pierre Saint-Jacques - Reply to: sescons at attglobal dot net
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.

[Jochen Luebbers]

Pierre Saint-Jacques <se*****@attglobal.net> wrote:

If you issue your PREPO command with a bindfile parameter and NO
package parameter, you only get a bindfile and NO implicit bind.
You then have to take that bindfile (.bnd) and use in a bind command
and specify a specific package name (amod1, lmod1,...) for each
specific bind command.
So TRY the following db2 call for EACH prepare:

> DB2 PREP module1.sqc BINDFILE USING amod1.bnd
> DB2 PREP module1.sqc BINDFILE USING lmod1.bnd
> DB2 PREP module1.sqc BINDFILE USING wmod1.bnd

Then take each bind file to each of their target platform and issue
the BIND command there.

The problem is *not* the bind-file name, but the *package name*.
If working as suggested, I will get different bind-files, sure,
but they all will bind *one* package named 'MODULE1'. That would
not be helpful, because I want to bind the different platform
packages at the *same* time and database.

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:

Pierre Saint-Jacques <se*****@attglobal.net> wrote:

If you issue your PREPO command with a bindfile parameter and NO
package parameter, you only get a bindfile and NO implicit bind.
You then have to take that bindfile (.bnd) and use in a bind command
and specify a specific package name (amod1, lmod1,...) for each
specific bind command.
So TRY the following db2 call for EACH prepare:

> DB2 PREP module1.sqc BINDFILE USING amod1.bnd
> DB2 PREP module1.sqc BINDFILE USING lmod1.bnd
> DB2 PREP module1.sqc BINDFILE USING wmod1.bnd

Then take each bind file to each of their target platform and issue
the BIND command there.

The problem is *not* the bind-file name, but the *package name*.
If working as suggested, I will get different bind-files, sure,
but they all will bind *one* package named 'MODULE1'. That would
not be helpful, because I want to bind the different platform
packages at the *same* time and database.

Then define an explicit package name using the PACKAGE option of the
PRECOMPILE command.
http://publib.boulder.ibm.com/infoce...e/r0001964.htm

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

[Jochen Luebbers]

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

Then define an explicit package name using the PACKAGE option of the
PRECOMPILE command.

....and we reach the point where I was starting. (see Subject:)

I used the PACKAGE option, but found that, it was binding in the same
step (as described in the documentation for V7).
And I disliked this for the described reasons.

Thanks for all your 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)

[Knut Stolze]

Jochen Luebbers wrote:

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

Then define an explicit package name using the PACKAGE option of the
PRECOMPILE command.

...and we reach the point where I was starting. (see Subject:)

I used the PACKAGE option, but found that, it was binding in the same
step (as described in the documentation for V7).
And I disliked this for the described reasons.

I apologize, but I still don't understand the issue...

First, what's the problem with the implicit binding?
If you combine the various options (BINDFILE, PACKAGE, and LEVEL), you have:
- no collisions for the package names
- no collisions for the bind files
- no mismatches just because you change a bit in the code and left the SQL
statements alone (i.e. no timestamp conflicts)

So again, what's the problem with the implicit binding?

(This is a stupid question maybe: you do have a development system where you
do you precompilations and generate the bind files? So the implicit things
don't influence the production system anyway.
I don't want to present this as a "feature" - I just don't see a real
issue.)

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

[Jochen Luebbers]

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.
(This time I tried to read the docu more carefully. :-)

Or am I wrong, this there mistake in my conclusion?
(This is a stupid question maybe: you do have a development system where you
do you precompilations and generate the bind files? So the implicit things
don't influence the production system anyway.

The system is very small: Development and production are on the same
system with the same database. (Sorry, I did not tell this before.)

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.htm"
(/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)