Re: RUNRMTCMD -- MIDRANGE-L

Scott,

Thanks for the thorough explination.  From what I understand, I will be able
to do the following:

Step 1:
Program 1,  System A:
Using the rexec() API, call the Program 2, System B

Step 2:
Program 2, System B:
Program is called and processes
Write the response to the printer file (O specs)
End the program

Step 3:
Since there are three "data channels" open, Program 1, System 1, read stdin
Process the response
End the program

Is this correct?

Do you have any examples of this process?

Thanks

Mike

----- Original Message ----- 
From: "Scott Klement" <klemscot@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, May 06, 2004 1:13 PM
Subject: Re: RUNRMTCMD


>
> > Here is my situation:
> > I have a process that runs on my source 400.  If the process fails, it
needs
> > to run a program on the remote 400 that will run a different process.
The
> > end message depends on the success or failure of the processes.  I need
to
> > pass parameters and receive parameters on the remote call.
>
> Parameters work by sharing memory between two programs.   Because the
> caller's parameters and the called program's parameters are in the same
> memory, changing one will change the other -- presto, you can exchange
> data in both directions!
>
> Now consider the problem of parameters passed to a program on another
> computer.  They CAN'T share the same memory.
>
> [SNIP]
> > CHGVAR     VAR(&COMMAND) VALUE('CALL +
> >              PGM(MSILVERS/TESTRMTCMD)' *BCAT 'PARM("' +
> >              *CAT &SENDPARM *CAT '")')
> > RUNRMTCMD  CMD(&COMMAND) RMTLOCNAME(SHIPLEY1) +
> >              RMTUSER(user) RMTPWD(pass)
> [SNIP]
>
> This is a great example of why you should've known that RUNRMTCMD couldn't
> have passed back parameters.  The RUNRMTCMD command doesn't even KNOW that
> you're passing parameters.  All it knows about is one big long command
> string called &COMMAND -- it doesn't know that some parts are parameters
> and some parts are program calls...  Oh well, that's a moot point I guess.
>
> What you don't know about the REXEC protocol is that it's capable of
> transporting 3 different data streams in addition to the command itself.
> These are "stdin", "stdout" and "stderr".   RUNRMTCMD has only limited
> support for them, it will write the contents of stdout and stderr to a
> spooled file, and will tell the remote command that there's no data on
> "stdin".
>
> However, if you use the rexec() API, or the rexec QShell command you can
> work with these data streams.
>
> And, rexec() on the '400 has a (rather bizarre) feature that allows you to
> write data to stdout by writing it as printer output.  (Only works when
> you're running your program through REXEC or similar facility)
>
> Thus, if you run the following program using the rexec() API, or the rexec
> QShell command, you'll get "Hello World!" back.  Not as a parameter, but
> as a "stdout" data stream:
>
>     FQSYSPRT   O    F  132        PRINTER
>
>     c                   except    print
>     c                   eval      *inlr = *on
>
>     OQSYSPRT   E            PRINT
>     O                                              'Hello World!'
>
> The reason why I'm telling you all of this, is that you can use it to get
> data back from the remote server, which may serve your purposes.
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>