RE: MSSQL Stored Procedures Call

The issue is JVM startup times. If you want to use JDBC directly out of an IBMi client job, that job has to start the JVM, which takes time. If you have a common job that does all the JDBC access, the JVM startup is only for that job, and not for every client.

Of course, if your IBMi client jobs run for a long time, the one-time JVM startup time might not be as much of an issue.



-----Original Message-----
From: Justin Dearing [mailto:zippy1981@xxxxxxxxx]
Sent: Thursday, March 17, 2016 9:17 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: MSSQL Stored Procedures Call

On Thu, Mar 17, 2016 at 10:02 AM Don Brown <DBrown@xxxxxxxxxx> wrote:

I'm not sure I understand your reply. These are interactive data entry
jobs where additional information is required from the Microsoft SQL Server.

Ok I think I slightly misunderstood the question

Having the procedure initiate the JVM and server connection each
request it too slow.

RPG ODBC calls would probably be faster, but I don't know RPG. Starting a python script in PASE would also be fast. There is pymssql and you can use pyodbc with freetds as well. A php script called from QSH would also work.
Either language would not have a big startup window, and can talk to MSSQL

Having a monitor pgm running in batch waiting to service a data queue
will be much more efficient.

Ok I'm a little murky on the greenscreen side of things hence my weird reply.