Re: QSQCLI *BNDDIR not found . . . yet program compiles here

James,

Binding directories are just lists of srvpgm/modules to search through. Your program says it's calling a routine named (for example) SQLAllocEnv. Now the ILE binder needs to FIND that SQLAllocEnv routine in order for your program to work.

So it searches through all of the srvpgms/modules in your binding directory until it finds something called SQLAllocEnv.

So it doesn't necessarily bind to or use anything in the binding directory. It just uses it as a list of things to search through. It only uses the srvpgms/modules in the bnddir *if* they match what it's looking for. Otherwise, they're ignored.

With all of that in mind, it's important to understand that the SQL CLI APIs are system-supplied APIs. You don't need to specify a binding directory to find them!! All high-level languages *automatically* (you don't have to tell them to do this) bind to the QUSAPIBD binding directory, and that binding directory tells it how to find all of the system APIs.

So you don't need to bind to anything in particular to find the CLI API. I've never heard of QSQCLI, but either it's something that was provided before the CLI APIs became system APIs (maybe they used to be a PRPQ??) or it's something one of your programmers created out of ignorance.

I don't think the system is even trying to look for a QSQCLI bnddir. It would only look at that bnddir if it still had procedures that it couldn't find, and needed another place to look for them. Since all of your routines got resolved by looking at the "automatic" binding directories, it'd never even look at your QSQCLI one.


James Lampert wrote:

We've got programs with
> H BNDDIR('QSQCLI')
some of them unnecessarily (I pulled all direct CLI calls into a single program, because I had 2 programs fighting over the CLI).

They compile fine here, both the ones in which the H-spec is necessary and the ones where it's obsolete, even though DSPOBJD *ALL/QSQCLI *ALL turns up a *SRVPGM in QSYS, but no *BNDDIR.

Yet we had someone stick a variant of one of the source members onto a customer box, and until we realized that the above H-spec was unnecessary, and pulled it out, it refused to compile.

Any idea what's going on here?