× 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: Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>
  • Date: Tue, 03 Jul 2001 15:17:22 -0700
  • Organization: Pacer International

I think I see what you are trying to do.  You want a generic TCP/IP
program on the AS/400 that will listen to requests on a certain port,
then accept the request, get the program name to run and the parameters,
run the program, and pass the return parameters back to the socket.

Well, the calling VB program knows what the parameters are can format
them as it likes.  The RPG program basically doesn't care.  It is
just transporting the data for another external program.  The pointer
example shown by Peter Dow should do the trick, to quote Peter:

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

pgmB:
    *entry    plist
              parm        x
              parm        y

And you just receive the parameters back and return them to the VB program
which can parse them out.  Okay, this should meet the specs given.

Now some what ifs.

Oh, cool, your AS/400 has this socket program to run programs and accept
parameters.  I'll just right a real quick socket program on a PC and have
it run the API to change my authority, or create a new user profile with
*ALLOBJ, or open up the FTP port so I can FTP in, or have it dump the
QSYSOPR user profile so I can brute force the password or...  You just
blew security wide open.

I think it would be better to write one program for each AS/400 program
you want to run, or validate the list of programs.  As for copying the
sockets source code this is perfect for writing a module and putting in
a service program.  Code your socket program so it accepts parameters
such as what program to run.  Test it, put in in a subprocedure, compile
in a module and create a service program.

Now, write a very small RPG program that calls this subprocedure and
passes it the port number to listen to and the program to run, or whatever
you want.  Now you can control the flow security wise more easily, and
you don't have to rewrite the socket program every time.  I envision the
RPG program that call the socket to listen and run the program to be maybe
4 to 10 lines long en-total.

Something like:

C             Eval    SocketPort = 12333
C             Eval    RunProgram = 'ARRPT01'
C             CallP   RunSocketListener(SocketPort, RunProgram)

Regards,

Jim Langston

John Ross wrote:
> 
> Thanks.  Yes batch jobs, different parameter list.
> 
> Sure I can say what I am working on.  A week or so ago someone wanted to
> know about Socket programs and some else wanted to know about calling a
> program from VB. I was interested in both of those so I started looking
> into it. I had a book (TCP something from midrange computing) with a good
> example of a sockets program and even how to use it with visual basic. But
> it requires you to write a second sockets program for every program you
> want to run. So If I want to get the serial number of the AS/400 I have to
> copy and paste into a program the socket logic then add the logic to get
> the serial number and pass it back. Then if some other time I want the
> description of the user profile, another copy and paste socket program. It
> get worse when you already have a program to do what you want on the AS/400
> (say pass an item number in and get description, quantity on hand  and
> quantity on order) that is called from an AS/400 program and now you want
> to call it from a PC program. Now you have to copy paste socket program to
> call the already written program and pass the parameter values back to the
> PC program.  I would just like a way to write the one socket program and
> pass it in the program the parms and then send pack the parms. Even if on
> the PC I had to format it like
> call iteminfo Parm('Item1' ' ' ' ' ' ')     which looks like it would work
> with qcmdexec  but no parms back from QCMDEXEC.  I am willing to put the
> x'00000f' in on the PC for numeric packed fields. I guess I am willing to
> even dig through the joblog if qcmdexec (or something else) would write out
> the out parms there.
> 
> Hope that was not to long and gives you an ideal of what I want to do.
> 
> Thanks
> John Ross
> 
> At 02:26 PM 7/3/01 -0400, you 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.
> >
> >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
-- 


Regards,

Jim Langston

Me transmitte sursum, Caledoni!
+---
| 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.