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.
midrange.com
