RE: Calling dll/exe program from AS400

Thanks... Great presentation!

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: October 07, 2009 4:33 PM
To: RPG programming on the IBM i / System i
Subject: Re: Calling dll/exe program from AS400

Hi Isa,

Here's the handout for the talk I give on calling (consuming) web
services from RPG:
http://www.scottklement.com/presentations/#HTTPAPI

I'm not a Windows programmer, I'm not sure how to set one up on Windows.



Wall, Isa (ED) wrote:

Scott,

Thank you for your help. After reading your e-mail I've decided to go
with webservices, it seems the simplest way to go. Can you please

point

me to some articles.

Thank you again.

Isa


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: October 06, 2009 2:55 PM
To: RPG programming on the IBM i / System i
Subject: Re: Calling dll/exe program from AS400

Hello Isa,

How do you call a dll on the IFS From an AS/400 passing it various
Parameters and then wait until a return value is received?

You can't run a DLL or EXE under IBM i (aka OS/400). They are Windows

programs that can only run on Windows.

With appropriate set-up, you can call a Windows program over a

network.

However, unlike i, when Windows passes a parameter to a program, it's
input-only. You can't use a Windows parameter (to a program) to

return

data back to the caller. That's a limitation of the way Windows (and
DOS, and Unix) work.

A better solution is a web service. Put a web service on the Windows
box that calls the EXE/DLL and gets the output, etc. These are the
modern way to do this type of work.

An older approach is to use a remote call mechanism. These work, but
they make error handling much more difficult, and the call mechanism
isn't standardized, so you pretty much have to write custom code for
each command you want to call. That might not matter in your case,
since you probably have only one thing to call...

IBM i Access (aka iSeries Access or Client Access) comes with a

utility

for Windows called "Incoming Remote Command". If you configure that

and

set it up, you can use it to serve out remote program calls over a
network.

From the IBM i, you'd either use RUNRMTCMD (which outputs it's

response

to a spooled file -- maybe not optimal) or the rexec() API, or the

rexec

QShell command. All three of these use the same underlying network
protocol to connect to the Windows box and run a remote command.

This method is, however, fraught with security problems. If you
configure Windows to not expect a password, then ANYONE can issue a
remote command against your PC without any sort of password, which

isn't

good. If Windows requires a password, then you often end up

hard-coding

the password into the calling program, so anyone who gets your source
code or program object can get your password. Plus, the password is
sent over the network in clear text, so anyone with a network sniffer
can see your password. Not good for security except in
highly-controlled environments.

Finally, there's SSH, which has a remote call mechanism that's

protected

nicely by encryption and digital keys that replace passwords. A much
better (but more complicated) scenario. I've never used an SSH server

on Windows, so I don't know how well it works in that scenario. Works

nicely on FreeBSD and Linux, though :)

So, you can see, there are a lot of choices with pros and cons. The

web

service is definitely the way to go if it's available, as it can be

made

secure, and solves all of the problems of the other mechanisms.

If you need more info on any of these options, let me know, and I'll
point you to articles.