469,361 Members | 2,264 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,361 developers. It's quick & easy.

BINDFILE vs PACKAGE

running on AIX with DB2 v8.2.2

I ran across a problem with naming source files with similar names.
For instance, if I have these three files:

upd_startaccessingdb.sqc
upd_startusingdb.sqc
upd_startreconproc.sqc

and I precompile like so:

-db2 PREP $*.sqc BINDFILE USING $(MADE)$*.bnd OUTPUT $(MADE)$*.cc
MESSAGES $(MADE)$*.msg

I end up with bindfiles:

upd_startaccessingdb.bnd
upd_startusingdb.bnd
upd_startreconproc.bnd

In the precompile area I read that db2 only uses the first 8 char of
the source file name when packaging so my conclusion was the name
similarity was causing the problem. I changed the names of the files
so the first 8 char where unique and that solved my problem.

Now, I want a way to bypass the problem by renaming the packages. My
confusion came when I read further. This is the info from the DB2
Reference:

1) BINDFILE - Results in the creation of a bind file. A package is not
created unless the package option is also specified...... If a file
name is not entered, the precompiler uses the name of the program
(entered as the filename parameter), and adds the .bnd extension.

2) PACKAGE - Creates a package. If neither package, bindfile, nor
syntax is specified, a package is created in the database by default.
USING package-name
The name of the package that is to be generated by the precompiler. If
a name is not entered, the name of the application program source file
(minus extension and folded to uppercase) is used. Maximum length is 8
characters.

Reading this it seems that a 'PACKAGE' is not being created since my
PREP does not contain the PACKAGE option. Also, only PACKAGE shows the
8 char limitation....it does not state there is a character limitation
in the BINDFILE name.

So my question is, are the BINDFILE names also truncated? so if I just
change the bindfile name to something unique will that resolve the
problem or do the PACKAGE names still come to play even though the
option is not used?

Feb 9 '06 #1
3 2559
shorti wrote:
running on AIX with DB2 v8.2.2

I ran across a problem with naming source files with similar names.
For instance, if I have these three files:

upd_startaccessingdb.sqc
upd_startusingdb.sqc
upd_startreconproc.sqc

and I precompile like so:

-db2 PREP $*.sqc BINDFILE USING $(MADE)$*.bnd OUTPUT $(MADE)$*.cc
MESSAGES $(MADE)$*.msg

I end up with bindfiles:

upd_startaccessingdb.bnd
upd_startusingdb.bnd
upd_startreconproc.bnd

In the precompile area I read that db2 only uses the first 8 char of
the source file name when packaging so my conclusion was the name
similarity was causing the problem. I changed the names of the files
so the first 8 char where unique and that solved my problem.
You can specify an explicit package name that is independent of the bind
file name at precompile/prep time.
Now, I want a way to bypass the problem by renaming the packages. My
confusion came when I read further. This is the info from the DB2
Reference:

1) BINDFILE - Results in the creation of a bind file. A package is not
created unless the package option is also specified...... If a file
name is not entered, the precompiler uses the name of the program
(entered as the filename parameter), and adds the .bnd extension.

2) PACKAGE - Creates a package. If neither package, bindfile, nor
syntax is specified, a package is created in the database by default.
USING package-name
The name of the package that is to be generated by the precompiler. If
a name is not entered, the name of the application program source file
(minus extension and folded to uppercase) is used. Maximum length is 8
characters.

Reading this it seems that a 'PACKAGE' is not being created since my
PREP does not contain the PACKAGE option. Also, only PACKAGE shows the
8 char limitation....it does not state there is a character limitation
in the BINDFILE name.
The limitation is on the package name only. The bind file can be as long as
you wish (or whatever the restrictions of you file system are). The thing
is if you do not give an explicit package name, DB2 will generate one for
you from the name of the bind file. That's all. And if _then_ the first 8
characters of the bind filename are not unique, you will get
collision/problems.
So my question is, are the BINDFILE names also truncated?
No.
so if I just
change the bindfile name to something unique will that resolve the
problem or do the PACKAGE names still come to play even though the
option is not used?


The package names have to be unique. How you provide for that is up to you.
Either with an explicit package name using for the precompile command or by
omitting the package name and letting DB2 derive it from the bind filename.

Personally, I would recommend the use of an explicit package name as this
allows you to choose proper and speaking names for the bind files.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Feb 9 '06 #2
Thanks for your response. Let me make sure i understand you correctly.
By not using "PACKAGE USING" in my precompile, a package is really
still being created but implicitly using the first 8 char of the source
file name (thus causing the problem where all three (packages begin
with upd_star). (this is what is confusing because the Reference guide
says " A package is not created unless the package option is also
specified").

So If I use the PACKAGE USING option in the precompile I can avoid the
problem when I name the packages as STACCESS, STUSING and STRECON even
though the source file names and bind file names remain similar:

upd_startaccessingdb.sqc
upd_startusingdb.sqc
upd_startreconproc.sqc

upd_startaccessingdb.bnd
upd_startusingdb.bnd
upd_startreconproc.bnd

Feb 9 '06 #3
shorti wrote:
By not using "PACKAGE USING" in my precompile, a package is really
still being created
The package will be created when you bind the bindfile against the database
in question.
but implicitly using the first 8 char of the source
file name (thus causing the problem where all three (packages begin
with upd_star).
Correct.
(this is what is confusing because the Reference guide
says " A package is not created unless the package option is also
specified").
During precompile, the package may or may not be created in the database you
precompile against depending on the options you are using. But that is not
an issue as the embedded SQL statements are all in the bind file. So when
deploying your application to the production (or development) system, you
will simply do a "db2 bind <bind file>". That will create (or update) the
package in the database.

If you don't use the PACKAGE option, the package is created implicitly - but
only in the one database that you used to prep against. And usually that's
a different database than production, so the bind is necessary anyways.

Summarized:
- db2 prep extracts the SQL statements from the embedded SQL source code and
places them in a bind file; you can choose pretty much any name for the
bind file
- db2 bind binds the bind file against a certain database to create the
package; during that bind, the SQL statements are actually verified,
compiled and optimized; the name of the package is restricted to 8 chars
and will be generated from the bind file name if not explicitly specified
So If I use the PACKAGE USING option in the precompile I can avoid the
problem when I name the packages as STACCESS, STUSING and STRECON even
though the source file names and bind file names remain similar:

upd_startaccessingdb.sqc
upd_startusingdb.sqc
upd_startreconproc.sqc

upd_startaccessingdb.bnd
upd_startusingdb.bnd
upd_startreconproc.bnd


Exactly.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Feb 10 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Petterson Mikael | last post: by
10 posts views Thread by datapro01 | last post: by
6 posts views Thread by Page Horton | last post: by
debasisdas
reply views Thread by debasisdas | last post: by
debasisdas
reply views Thread by debasisdas | last post: by
debasisdas
reply views Thread by debasisdas | last post: by
reply views Thread by Steven Samuel Cole | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.