Re: Calling dll/exe program from AS400

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

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.