× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. JAVA400-L
  3. November 1999

Fw: forcing native access with websphere and toolbox

  • Subject: Fw: forcing native access with websphere and toolbox
  • From: "Alex Garrison" <agarrison@xxxxxxxxxxx>
  • Date: Thu, 11 Nov 1999 11:49:23 -0500
 Anyway, I have yet to crack open the V4R4 performance guide, but it has chapters on each of the components involved in our system.
 
One of the things the performance guide recommends is to change your physical files to use ccsid 13488 (unicode) for all character data.  This is supposed to speed things up (IBM says by up to a factor of 12) by eliminating the conversion of ebcdic to unicode that must normally take place once you have retrieved data.   We are doing this now to all our files.  Although we do see an improvement (approximately 25%), we dont see nearly the improvement IBM claims. 
 
----- Original Message -----
Sent: Thursday, November 11, 1999 9:24 AM
Subject: Re: forcing native access with websphere and toolbox

We haven't targeted performance yet- it is coming soon. We are happy with ODBC performance via SQL and stored procedures to the 400 from PC client apps. So far, we are dissapointed (and surprised) with initial performance of an applet which communicates with servlets running under WebSphere (via the HTTP server) which in turn use JDBC access. We have not yet pinpointed the bottleneck(s) so it is too early to say where the problem lies. I don't doubt that record level access is faster, but it doesn't suit our particular requirements. On the other hand, we also have some servlets which respond with HTTP/JSP and access the database with the toolbox JDBC drivers to execute stored procedures, and except for the first time they are run after starting up, the performance is fine. Anyway we have a lot of hunting to do. If we are not happy with the end result, then Rochester has some work to do IMHO. I expect performance via JDBC to be at least as good as with ODBC on the 400 (actually, better if I use the native DB2 drivers directly on the box), especially if Rochester wants to market the 400 as THE java server. Anyway, I have yet to crack open the V4R4 performance guide, but it has chapters on each of the components involved in our system.
 
Luther
 
----- Original Message -----
Sent: Thursday, 11 November 1999 14:19
Subject: Re: forcing native access with websphere and toolbox

A personal comment on jdbc:
 
We used the jdbc drivers from websphere on the as/400 (both toolbox and native) for about 17 months.  To make a long story short - the performance just isnt there.
 
I know others have had a great experience with jdbc.  We brought in several such lucky folks as consultants to learn from their experiences.  Some techniques do help - stored procedures, analyzing sql optimizer diagnostics, etc.  Bottom line, though, is that we get much better (like over 50%) performance using record-level i/o.  I know we lose portability by going to record-level access, but a portable slow-running servlet is just no good to us.   We really just got to the point where we had no choice.
 
I am not saying everyone should dump jdbc for record-level i/o, but I have a feeling there are others out there with the same experience we had.  Anyone else go from jdbc to record-level i/o or are unhappy with jdbc performance in websphere on an as/400?
 
----- Original Message -----
Sent: Thursday, November 11, 1999 4:38 AM
Subject: Re: forcing native access with websphere and toolbox

If you use JDBC, you can use the toolbox JDBC drivers to connect to the AS/400 from anywhere. If you are running your servlets on the AS/400, you can configure your servlet to use the native DB2 JDBC drivers instead of the toolbox drivers for faster access. (Not sure how it compares to record level access- I imagine record level performs faster). Another advtange of JDBC is that your servlet will likely run on any java platform and connect to any database, depending on the SQL that you use instead.
 
Interesting about how you must connect as QTMHHTTP to bypass TCP/IP on the 400 -- I did not know that.
 
Luther
 
----- Original Message -----
Sent: Wednesday, 10 November 1999 21:36
Subject: forcing native access with websphere and toolbox

Tip of the day: IBM Java Toolbox Record Level I/O from Servlets
...

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.