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



Rob,

I agree, a stored procedure or a remote data queue would be the front
runners. They would be fast and easy to develop (data queues are in
production in 90 minutes, both sides and could be CL, RPG, or COBOL, or any
combination) and far easier to maintain in the end than a web service or
other technique.

The web service only wins architecturally if in the very near future there
would be a need for heterogeneous systems to call the web services. If it
stays IBM i to IBM i the web service loses in a hurry.

Don't start using the new shinny object just because you can, use it because
it's needed. Sometimes, the old ways work best, because they are old.


--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Tuesday, March 27, 2018 6:34 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Call RPGLE program on another iSeries

Ok Chris, based on Buck's responses, with the addition of Jim's data queue
suggestion, which of the following do you (and I realize this may be a shot
from the hip) think may do the trick?

Buck:
SQL stored procedure
Remote Procedure Call
SBMNETJOB
SBMRMTCMD
Trigger on a 'special' table on the remote system
Jim:
Data queues
Others (sorry but I deleted many of my responses):
Web Services

My initial shot from the hip would be anything with SBM in it's name would
not be the interactive response you're looking for.
The trigger idea would also not be a good command/response pair.

My initial two picks would be SQL Stored Procedures and Data queues. I
plead ignorance on remote procedure calls. Web Services may be a fun
learning experience and something to add to the tool box but I'd have to
have a lot more information to justify going down that road. At Dekko we do
some serving, and consuming, of web services. But is done by others who do
more day-to-day coding in RPG.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Christopher Bipes <chris.bipes@xxxxxxxxxxxxxxx>
To: "'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx>
Date: 03/26/2018 04:53 PM
Subject: RE: Call RPGLE program on another iSeries
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Thank you,

Yes, the program needs to wait for the remote call to complete and then
continue on to process the response.

Basically the program creates and XML file for processing, the remote
system processes the file, then the local system processes the response
file.

The files are on the initiating systems IFS. It can be shared so the
remote system can read / write to the directory.



Chris Bipes
Director of Information Services
CrossCheck, Inc.


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Buck
Calabro
Sent: Monday, March 26, 2018 1:37 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Call RPGLE program on another iSeries

On 3/26/2018 4:28 PM, Christopher Bipes wrote:
How can one call a RPGLE program that resides on another iSeries? They
are on the same LAN. They are connected via Any Net / Enterprise
Extenders.

Starting the discussion:
SQL stored procedure
Remote Procedure Call
SBMNETJOB
SBMRMTCMD
Trigger on a 'special' table on the remote system

The solution set varies if the caller needs an answer, or if it only
needs to kick off a remote process.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.