Re: Using opdesc ... getting CEE0502

Hi, David:

So, you had to change the prototype for your "procname" procedure to include "opdesc", yes? Therefore, you would have to (at a minimum) recompile every other program that includes this prototype, because the compiler has to _generate extra code_ to pass those operational descriptors in the first place... otherwise, there is nothing there for CEEDOD to retrieve. .. and, hence, your original error CEE0502 ... and so indeed, there IS NO operational descriptor being passed... :-o

So, since you will have to recompile all of the callers anyway, and this is all part of a product for which you have control over the source code, then why not just make the changes I suggested in the first place? ;-)

Mark

> David Gibbs wrote:

Mark S. Waterbury wrote:

Why not just pass one more parameter to your "procname" procedure, with the size of that other parameter (in this case, a data structure)?

That requires that I change the caller ... which I would like to avoid.

Using opdesc should let me determine the length of the variable being passed in.

There is some "overhead" when using operational descriptors ...

There's overhead in everything ... IMO the flexibility of opdesc outweighs the performance hit.

I can understand using CEEDOD with some APIs or "exit points" of some other vendor product, over which you have no control, and when the source code might not even be provided or available. But, to use it within your own code, or as a part of product(s) you are supporting and maintaining or enhancing, I am not sure this is really such a "good idea"... _unless_ you are creating "APIs" that your customers will be calling?

My routine is called from a number of locations in my code ... not all of which I am currently modifying. It's much easier to change the internals of a routine than the prototype.

david