|
midrange.com
Mike,
I just tried the SQL stored procedure interface. Works like a champ! I
wrote a RPGIV program on Sys1, and registered it as a stored procedure.
CREATE PROCEDURE
TESTED/METAPHONE(
INOUT WordIn CHARACTER (128 ),
INOUT OutWord CHARACTER (6 ))
LANGUAGE RPGLE
NOT DETERMINISTIC
NO SQL
EXTERNAL NAME TESTED/SOUNDEX
PARAMETER STYLE GENERAL
Then, from the remote system, I called it like so:
-------------------------------------------------------------
D $Input S 128 Inz('SOUTHBEACH')
D $Output S 6 Inz('')
D $$$ S 1
D
C/Exec SQL
C+ Connect to SYS01
C/End-Exec
C
C/Exec SQL
C+ CALL TESTED/METAPHONE (:$Input, :$Output)
C/End-Exec
C
C/Exec SQL
C+ DISCONNECT CURRENT
C/End-Exec
C $Output DSPLY $$$
C
C Seton LR
C Return
Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863
-----Original Message-----
From: Mike Silvers [mailto:msilvers@xxxxxxxxxxx]
Sent: Thursday, May 06, 2004 12:33 PM
To: Midrange Systems Technical Discussion
Subject: Re: RUNRMTCMD
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.
>
>
_______________________________________________
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.
As an Amazon Associate we earn from qualifying purchases.
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.
