× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Calling a program without knowing the parms
  • From: "Peter Dow" <pcdow@xxxxxxxxx>
  • Date: Tue, 3 Jul 2001 13:08:26 -0700

Hi Alexei,

As I understand it, all parameters are passed as pointers, either to the
actual data in the calling program (if passed by reference) or to a copy of
the data (if passed by value). In any case, as long as you call a generic
program with more parameters than the program is looking for, you'll have no
problem with the number of parameters.  For example:

pgmA:
    call    pgmB
    parm            a
    parm            b
    parm            c
    parm            b

pgmB:
    *entry    plist
              parm        x
              parm        y

pgmB will ignore c & b.

The problem is the types. If a is character and x expects packed decimal,
it's a problem.

On the other hand, if pgmB is always going to initialize x and y before
using them, i.e. they're return-only parameters, then you could get away
with passing a and b as large character fields and no error would occur.

If John's situation is that all pgmB's have parameters within a certain
range (e.g. no more than 20 parameters, each parameter no larger than say
256a) and the PC program can figure out the data, he might be able to do it.
If not, I don't know any api that will tell you the size and type of a given
program's parameters.

Regards,
Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax





----- Original Message -----
From: "Alexei Pytel" <pytel@us.ibm.com>
To: <RPG400-L@midrange.com>
Sent: Tuesday, July 03, 2001 11:55 AM
Subject: RE: Calling a program without knowing the parms


>
> There is a retrieve program information API which can return number of
> parameters of *PGM object main entry point.
>
>     Alexei Pytel
>
> "The better is the worst enemy of the good"
>
>
>
>
>
>                     Buck Calabro
>                     <Buck.Calabro@com       To:     RPG400-L@midrange.com

>                     msoft.net>              cc:
>                     Sent by:                Subject:     RE: Calling a
program without knowing
>                     owner-rpg400-l@mi        the parms
>                     drange.com
>
>
>                     07/03/2001 01:26
>                     PM
>                     Please respond to
>                     RPG400-L
>
>
>
>
>
> >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.
>
> That's a tall order!  I looked quickly at %paddr/procptr but that only
> works
> for bound procedures, not external program calls.
>
> >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.
>
> So these are batch programs you're wanting to call?  And they can have
> variable number/type of parameters that you need to send to the PC?  How
> nice it would be if these programs did output to stdout and you could
> simply
> pipe the results...  This won't be a simple matter in RPG.  There's always
> brute force:
>
> eval pgmName inpPgmName
> call pgmName
> parm parm1
> trap "wrong parameter list" error
> if error
>   call pgmName
>   parm parm1
>   parm parm2
> endif
> ...
> then you get to have fun assembling all the returned parameters to pass on
> to the PC.
>
> Of course, you could "cache" the program/library/parameter type
information
> in a file.  Try the "normal" CALL; if it fails, run the "discover
> parameters" routine and store the results.  Then use those results as the
> next "normal" CALL.
>
> Perhaps there's another way around your particular business problem than
> trying to directly call the 400 program.  Can you disclose what you're
> working on?
>
> Buck Calabro
> Commsoft; Albany, NY
> Visit the Midrange archives and FAQ at http://www.midrange.com
> "Where so many hours have been spent convincing myself that I am right,
>  is there not some reason to fear that I may be wrong?" -- Jane Austen
> +---
> | 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
> +---
>
>
>
>
> +---
> | 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
> +---


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.