Re: Calling a program without knowing the parms

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...

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?

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...


> 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 :)

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.

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

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.

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.

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.

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.

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.

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.

Hope that helped, and good luck...



+---
| 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
+---