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



rexec() (via the API or QShell command) supports passing of stdin, stdout and stderr data streams. Granted, this isn't precisely the same thing as parameters, but it can accomplish the same thing.

You see, on other platforms (Unix & Windows) parameters to program calls are not passed by reference, and therefore can never be bi-directional. Since REXEC was designed for Unix originally, it wouldn't make sense to support bi-directional parameters.

But, Unix and Windows programs (and i5/OS as well, though we don't use it as often) support communications via special data streams called "stdin, stdout, stderr".

You just send your data to the other program via stdin, and it returns it's results via stdout.

RUNRMTCMD doesn't support passing stdin, and it writes stdout to a spooled file. So it won't do the job, but either the API, or the QShell command should work for you, as long as you don't might writing the code to send data via stdin and stdout. (It wouldn't bother me at all, but then, I'm already familiar with it!)

Of course, these aren't your only alternatives. You could also use HTTP as a communication method between programs (though, this also uses stdin/stdout if you use the CGI interface). But this requires a bit more setup. In fact, if you pass your parameters this way in an XML document, you'd basically have a web service.

Another alternative, of course, is SQL -- as you already know.

You could also go a bit more low-level and use sockets. Or data queues. Or something like that. But those might take longer to set up.

I think you'll find that TI-RPC is every bit as complicated as sockets or data queues, and more complicated than rexec or HTTP.

Here are some links to sample rexec() API code in ILE RPG if you like. Granted, they don't demonstrate how to send data via stdin, but perhaps they'll get you on the right path.

http://www.iseriesnetwork.com/noderesources/code/clubtechcode/RexecDemo.zip
http://www.pentontech.com/IBMContent/Documents/article/50809_18_RexecRev.zip

Inspired by your dilemna, I may end up writing a new article that demonstrates more of the communication aspect of this API, but even if I do, it won't be ready til sometime in October, so maybe the above stuff will help.


DeLong, Eric wrote:
I need bi-directional parameters. I did not think that was supported for REXEC invocations.... Are you going to make my day and tell me I'm wrong? <g>

Eric

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Scott Klement
Sent: Thursday, September 27, 2007 5:17 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Alternatives for remote program call


How about RUNRMTCMD? Or the rexec() API? (which uses the same protocol, but has more capabilities). These are very simple ways to call a program over a netwokr...

will they work for you?

DeLong, Eric wrote:
I have the need to remotely call a program with full bi-directional parameter support. My first thought was to use SQL (Connect to xxx; CALL nnnnn (:p1, :p2, :p3)) to invoke this program, but as it turns out, that called program issues a SQL CONNECT TO. This is not allowed, it seems.....

I'm trying to consider alternatives, but so far I'm not finding much....

I was wondering if it would be possible to write a Java program that would use the Java Toolbox to remotely call my RPG. I am not very familliar with the Java Toolbox, so I'm not sure it it even supports bi-directional parameters. Has anyone done something like this?

Thanks for any ideas...
Eric



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.