Re: Passing a pointer between programs when using a dynamic call

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Stefan,

> Is it possible to use a pointer as a parameter when calling another program?
> The program call has to be made up dynamically and executed using qcmdexec
> or system API…

You have two questions here, I think.  Is it possible to pass a pointer 
as a parameter when calling a program?  Yes!  Provided that you are 
doing a direct program-to-program call.

Is it possible to pass a pointer via QCMDEXC or system()?   No. 
Remember, QCMDEXC (and similar tools) receive one big character string 
from your program, and they interpret the contents of that character 
string, via scanning/parsing techniques.   You can't pass any sort of 
variable (including a pointer, which is after all, a variable) when 
using those tools.


> Program  B gets invoked and need a mechanism to send back information to
> program A. 

Then you don't want to use QCMDEXC or it's friends.

> Just to hide the complexity of the datastructure in program A my 
> thought was to create a service program ( program C ) with procedures
> that can be called by program B. It then seems reasonably that a
> pointer must be used to “connect” the procedures in pgm C with the
> datastructure in pgm A. Along the run it might be needed for program
> C to change pointers in pgm A datastructure ( realloc of memory ).

I don't really understand this part of your message at all.

1) Why does PROGRAM A work this way?  Why do you need so much 
flexibility in terms of the parameter list?  Do you work for a software 
house where your software has to be able to call a customer's program 
with any arbitrary parameter list?   I can't think of any other reason 
someone would do something like this.

2) I don't understand the "Program C" business at all.  If you're 
passing the data via a parameter, how does a service program help?  Why 
not pass the data via the service program instead of the parameter list?

3) Why does a pointer need to be used to "connect" your programs?


> Am I out on very thin ice here? Better solutions?

Hard to say.  I think we need more information to even begin to give you 
advice.  Speaking for myself, at least, I really don't understand your 
scenario.