Re: Calling a program without knowing the parms

Scott,

Thanks very much, see comments below.

At 04:26 PM 7/3/01 -0500, you wrote:

>On Tue, 3 Jul 2001, John Ross wrote:
> >
> > Is there any way I can call a program from a program without knowing what
> > the second (called) programs name or parameters are at the time I write 
> the
> > first (calling) program. I need to get any parameters back from the second
> > program into the first program.
>
>Hi John,
>
>An interesting dilemna!  You're making me actually think today :)
>I'm sure that doing something like this is possible, however, not
>very easy...
>
> > What I am trying to do is write one sockets program that will run on the
> > AS/400 and run a program that was passed to it from a PC and then pass the
> > results to the PC. The pc will format the call and strip out the returned
> > parameters.
>
>1)  Is there a particular reason that you want to pass the data between
>       your PC program and your AS/400 program using parameters?  why not
>       just send the data directly via the socket?  This would be more
>       efficient and a LOT easier to program...

 From my understanding I would have to change the socket programs for every 
call. Not a big deal but easier if I could just format the call on the pc, 
I hope.


>2)  Assuming that you have to use parameters for some odd reason, is there
>       any reason why you couldn't do it all with ONE parameter, maybe a
>       data structure that could vary in size and hold as many different
>       fields as you like?

My only requirement is not to have to change the called RPG programs on the 
AS/400 how the call gets formatted on the PC and passed to the sockets 
programs I do not care how that is done.

>3)  Finally, assuming that this does need to be given as individual parms,
>       would it hurt for the calling program to supply all 255 possible
>       parameters?   The program that's being called will simply use what
>       ever it needs, and discard the rest.   The only problem would be if
>       you checked %parms or the "number of parms passed" in the SDS...

I do not think I would have to worry about parms passed in SDS being 
checked. But Peter wrote in his email about some of the same concerns I had.


> > It is my understanding the QCMDEXEC and Run remote command (ftp) will not
> > return parameters.
>
>What you need to understand is what is actually passed from one program to
>another when a parm is passed:
>
>  1)   When you compile the program that gets called, the source code given
>          to the compiler tells it the sizes and data types of the
>          parameters, but doesn't tell it where these parms are located in
>          memory.
>
>  2)   At runtime, when you actually make the call, the calling program
>          passes memory addresses to the called program.   That's all it
>          passes!   One address for each parameter.
>
>  3)   At runtime, the called program looks in the addresses given in step
>          #2, and tries to interpret that data in the way that was
>          specified in step #1.
>
>   Therefore, OBVIOUSLY, a "remote command" can't return parms!   If your
>RPG program was passed the addresses of memory on your PC, it wouldn't
>do it any good :)
>
>Therefore, commands like FTP's RCMD, or QCMDEXC will reserve some memory
>for parms, put the data that it thinks the program is expecting into those
>memory locations, and pass the addresses to the program.  Since it's
>reserving its OWN memory (rather than using the memory from the calling
>program) any changes made by the called program don't affect the calling
>program.  Make sense?
>
> > I have not used ILE very much so it maybe easier then I think. I can write
> > the sockets program it is just the part of calling the second program that
> > I need to know how to handle.
>
>Easier than you think?  I rather doubt it.  Most likely, it's much more
>difficult than you think -- especially if think that with very little
>exposure to ILE, you'll be able to sit down and create a sockets program
>that'll do all of these things :)

The socket programs are written. And if I wanted to modify them for every 
call to a different RPG program I would be all set.

>So, having said all of that, I've come up with this pseudo-code:
>
>1) A "listener" program is created on the AS/400 that listens for
>     connection requests from the PC.  Whenever it receives a request,
>     it submits a new job to process that request and uses the
>     givedescriptor/takedescriptor APIs to hand the socket descriptor
>     to that job.

This sockets program is written. Not sure about the 
"givedescriptor/takedescriptor APIs". What do you mean by that.

>2) A PC program uses sockets to connect to the appropriate port for
>     this application.

Yep. Understand this.

>3) The "newly submitted" job will handle the rest of the processing
>     for this request.  It will ask the PC program for a user-name
>     and password, when it gets one, it will use the security APIs
>     to set the current profile to the one passed from the PC.  It
>     would be a huge security hole to try to write this application
>     without doing this.

Done in number one above before the submit.

>4) The As/400 program will request from the PC a program name to call
>     and "parameter buffer".  The parameter buffer should probably
>     contain the number of parms to use, an offset value into the
>     buffer for each parm, and a length of the actual parm data, as
>     well as the data itself.

I understand the concept, but not sure how the actual parameter buffer 
would look. And if it really matters and long as the PC programs and the 
AS/400 socket programs use the same format.

>5) Once this parm data has been received by the AS/400, it will use
>     the number of parms, and offsets for each parm to get a list of
>     pointers to pass to the program that it's about to call.   It
>     could base some 1A fields on these pointers, and pass these
>     as parms to the program that it's about to call.   If there
>     are less than 255 parms to pass, the remaining pointers should
>     probably be set to NULL.  It can now do the actual call.

Ok really confused. I think Peter had an example in his email. But I did 
not understand it.

>6) When the program it calls completes, it needs to send the
>     (possibly updated) parameter buffer back to the PC.  It's
>     probably a good idea to also pass things like error messages
>     and return codes, in case the program that was called had
>     crashed.

Agree.

>7) Now you have the option of letting PC call another program
>    (or the same program again) or simply closing the connection
>    and ending the job.
>
>Probably the best way to organize the whole thing is to create your own
>sort of an "API" on the PC end of the connection, so that this code
>doesn't need to be rewritten for every application that uses it.

Agree. Another learning curve. It will have a connect, disconnect, format 
call, parse data after call, and the call section. I think they are called 
active x on the PC side.

>I've done some similar work in RPG IV, and so I assure you that all of
>this is possible.   But, unless you're already familiar with this type
>of programming, the learning curve is fairly steep.

That is ok with me. I always get to start at the very bottom and even if I 
do not make it to the top I usually learn something out of it. ;)

>Hope that helped, and good luck...

Yes that helped. But instead of luck I will probably need more help ;)

If this is in HTML format, please let me know. I have started to use Eudura 
and not sure if I have it set right or not.

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---