|
I would like to add one more point to dawall's reply.
When the AS400 program returns a resultset to java, we have to use JDBC
calling the stored procedure using CallableStatement.
If the program returns only a few parameters then we can use ProgramCall.
-----Original Message-----
From: dawall@us.ibm.com [SMTP:dawall@us.ibm.com]
Sent: Wednesday, March 22, 2000 8:20 PM
To: JAVA400-L@midrange.com
Subject: Re: ProgramCall versus JDBC
In general, ProgramCall will be faster then stored procedures because
ProgramCall has less overhead.
Luther made a very good point about connections. ProgramCall and JDBC use
different servers so if you are doing JDBC for db Query then need to call a
program, the Toolbox will make a new connection if you use ProgramCall.
Making the connection takes a measurable amount of time. It is a one-time
cost if you keep the connection up but it is measurable. So, if you are
just doing program calls then ProgramCall will be faster. If you are doing
a lot of activity db via JDBC and you rarely call programs, stored
procedures may be better.
David Wall
AS/400 Toolbox for Java
Mark Sievers <MSievers@promega.com> on 03/21/2000 01:12:37 PM
Please respond to JAVA400-L@midrange.com
To: "'JAVA400-L@midrange.com'" <JAVA400-L@midrange.com>
cc:
Subject: ProgramCall versus JDBC
What is the difference between using the ProgramCall component to call a
program or using JDBC to call a store procedure. I know that you can
return
one or many result sets if you use JDBC. Are there a performance
differences?
Mark
-----Original Message-----
From: dawall@us.ibm.com [mailto:dawall@us.ibm.com]
Sent: Tuesday, March 21, 2000 12:24 PM
To: JAVA400-L@midrange.com
Subject: Re: NT(IIS)->AS400 - where's the bridge?
A couple of choices I can think of are:
1. Use the ProgramCall component of the AS/400 Toolbox for Java. It
does the work so a Java programs can easily call AS/400 programs in a
client/server environment. The Toolbox does all the back end
processing. Your task is to write the Java program that uses the
Toolbox and to get the program invoked in your environment. Check it
out at http://www.ibm.com/as400/toolbox.
2. Use Active Server page support in Client Access / 400. CA/400 has a
set of ActiveX Automation Objects for this environment. Check it out at
http://www.as400.ibm.com/clientaccess/3tier/
David Wall
AS/400 Toolbox for Java
Nikolay.Ichpekov@ssa.co.uk on 03/16/2000 11:26:59 AM
Please respond to JAVA400-L@midrange.com
To: JAVA400-L@midrange.com
cc:
Subject: NT(IIS)->AS400 - where's the bridge?
Hi all,
This is my first post to this forum although I've been following it on and
off for the past month or so. Anyway, enough small talk on with my
problems.
I've just been 'volunteered' to come up with a quick and easy (why do they
always say that!) solution for a limited order entry e-commerce based
product. The scenario is: client (with browser) accesses an application
server (which is also COM client) residing on an NT server running
Microsoft IIS which provides connectivity to various COM servers. (This
already exists!)
My task is to provide a way for IIS to send data across to an AS400 where
the relevant RPG program is called to process it and apply updates to the
database. If you thought that was simple, the conditions are: no use of
client/access (ODBC), no use of MQ Series, no redirection to an AS400
webserver. Emphasis is on minimum cost, methinks.
Having little experience with writing commercial Java (apart from the odd
applet) or indeed using MIIS, I'm a little lost at the moment. I've been
toying with the idea of extending the ISAPI to provide simple socket
connectivity to an AS400 where presumably a simple servlet or cgi script
will call (or wrap) the relevant RPG program. Not quite sure how much work
is involved though. Anyone out there with any ideas will be greatly
rewarded.... Or at least sent a note of thanks!
Nik
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.