Re: Question about ARDGATE

Actually killing our PC file server component would cause our RPG service program to timeout. It uses non blocked sockets so we would get the socket timeout so the RPG programmer could handle it.

In the case of ArdGate it may not be an issue with your server. It may be with the IBM SQL Engine. I didn't follow it far enough to find out.

Personally I would suggest making it a high-priority as this is a show stopper for production usage if your RPG SQL jobs lock up on a PC server failure.

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
------------------------------

message: 4
date: Thu, 26 Jul 2012 18:38:51 +0200
from: "D*B" <dieter.bender@xxxxxxxxxxxx>
subject: Re: Question about ARDGATE

<Richard Schoen>
FWIW: I was able to lock up a STRSQL job when I tested ArdGate previously by killing the server in the middle of an SQL select command. May want to add that to the QA testing.
</Richard Schoen>

... thank you for the bug report, we will fix it (with low priority). BTW: killing a File Server might lock up EXCEL too!

Using embedded SQL (especialy going the ArdPgm way) has advantages and disadvantages, its easier to use, but has some limitations, a proprietary call level interface (maybe) doesn't have. The java usage is not so important, because ArdGate uses one prestarted JVM serving multiple clients in a multithreaded environment (and this workload could be moved to a Wintel or Linux Box). If the target database has only an ODBC and no JDBC driver available, I would recommend a ODBC based tool anyway and if there is none of both it would not work with any of the mentioned tools anyway.

D*B