Hi@all,

I think my problem is very specific since I already spent some hours while looking for a solution to it.
Im developing a service (C language) running on MS Windows and Sun Solaris which communicates with a IBM z/OS host. For performance reasons I had to integrate direct access to the DB2 instance running on the z/OS host using DB2 Connect and static SQL statements.

This is already implemented and tested, no problem so far.
The problem appeared when we got to deploy the program.
Since in production environment the service runs on many different machines communicating with different hosts I have to create a package for the service in each host's DB2 instance.

For a host program one would deploy the DBRM file generated by the precompiler and bind it to the different DB2 instances. But the .bnd file generated by the preprocessor on my Windows machine seems to have no valid DBRM file format.

A colleague told me, that he uses db2sqljcustomize for the same problem in a Java static SQL program, which knows a parameter genDBRM.

So to my question:
is there any tool around, which I can use to do the same thing for static SQL in a C program? Or may be anyone knows another solution to this problem?

I hope somebody can give me a hint.

@Edit:
Sorry I forgot to add some information:
db2level
Informationstoken: "DB2 v9.5.300.414", "s081118", "WR21419" und FixPak "3".

db2licm -l
Product name: "DB2 Connect Personal Edition"
Product identifier: "db2conpe"
Version information: "9.5"

DB2 host instance:
DB2 UDB for OS/390 and z/OS
DB2 Version 08.01.5

M.E.

If you have a .bnd file, you typically bind it from a LUW system against the target database. This is not a DBRM and you shouldn't need one.

OK, I have already done it this way for DB2 instance used in development/testing. But I don't have access to the customer's productive DB2 instances, so the bind has to be done by the customer. They intended to do this on their host machines but therefor they need a DBRM file.
So if I understand you correctly, they have to use the bnd file and bind it from a LUW system against their different productive instances?

M.E.

You could do the bind from within your application. There is a DB2 API for that. One way would be to check for the "package not found" error message (I don't recall the exact SQLCODE) and/or a -805 error and then invoke the API. If you don't want to do that, the customer will have to do the bind as part of the installation step for your application.

It's at least uncommon (and maybe even impossible?) to do just the BIND on z/OS; the typical way to do this is as you did on the development system, i.e., the prepare statement does the BIND.

An other, common way to have indeed all BINDs on z/OS is by using a stored procedure.
This way, all SQL (and maybe also some programming logic) really sits on z/OS, and your Solaris and Windows programs just call the stored procedure (within an EXEC SQL) and do no other SQL directly against the z/OS database.

In that case you have either dynamic SQL to drive the CALL statement (if you are permitted to use dynamic SQL), or you need a package for the static SQL in the application. In the latter case, it just reduces the number of SQL statement but doesn't resolve the problem.

Technically speaking you are correct, but apparently, most DBAs on z/OS seem to be more allergic to static SQL coming from e.g. Solaris than to dynamic SQL containing just a CALL procedure statement.

And I understand why: one of the DBA's responsibilities is guaranteeing an efficient access path for all DML, e.g. by monitoring queries (by analysing EXPLAIN output), creating indexes, changing cluster sequence, and regularly running REORG and RUNSTATS. This becomes much harder when the DML statements are coming in in an uncontrolled way.

My personal experience is that much misunderstanding between DBA and developer can be avoided by good communication...

I fully agree with you there, Peter.

The question is whether you look just at the problem of binding or have the more broader view on executing static SQL statements.