Re: Calling dll/exe program from AS400

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.