Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

The System i Strategy for New Customers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    The System i Strategy for New Customers

    ** This thread discusses the article: The System i Strategy for New Customers **
    Joe, Your paragraph beginning with the JVM running in the 128-bit address space kind of left me in the dust. I couldn't follow it. But if you believe you could write a more efficient database interface, then more power to you. AFAIK, Java RLA uses the same Host Servers as JDBC. RLA is part of the Toolbox. Following is an introduction to the Tookbox from an IBM Web site: "The IBM Toolbox for Java provides support similar to functions available when using the Client Access/400 APIs. It uses the OS/400 host servers that are part of the base OS/400 operating system to access data and resources on an iSeries or AS/400 system. Each of these servers runs in a separate job on the server, communicating with a Java client program using architected data streams on a socket connection. The socket interfaces are hidden from the Java programmer by the IBM Toolbox for Java classes." AFAIK, all interfaces between Java and native services go through Host Servers, although I seem to recall reading about an optimized interface that didn't use sockets, but the optimizations turned out to be trivial. Finally, I don't know Blair Wyman or what he may have said about the new 32 bit JVM performance, and would prefer not to call him a liar, as you suggested, but would rather give him the benefit of the doubt. I'm mostly having a hard time reconciling IBM's earlier statements about implementing the JVM below the machine interface, with newer statements about implementing the 32-bit version under PASE. Google on "webfacing comparable 5250" and the first hit is a post by IBM's David Slater stating among other things that the Webfacing interface and the 5250 interface have comparable performance. I recall a number of similar statements, but didn't bother saving references. http://search400.discussions.techtar...@@.ee84638/565 I've read a lot of information over the years, mostly from IBM about Java performance. In every case the comparison between Java and ILE performance is ignored, side-stepped, or trivialized to the point of meaningless. We kind of veered off topic. I was just hoping to gather a bit more information about PHP on the iSeries.

    Comment


    • #17
      The System i Strategy for New Customers

      ** This thread discusses the article: The System i Strategy for New Customers **
      In no particular order: back in 2001 David Slater was comparing the performance of WebFacing to screen scrapers. Remember that back then the ONLY person outside of IBM doing direct-to-JSP was me. Everything else was the sickly-slow Jacada/Seagull stuff. So at that time, yes, WebFacing was "comparable" to 5250, at least as opposed to screen scrapers. On the toolbox issue, you are confusing the concept of a Java client on another machine with a native Java application running on the iSeries. IBM states: "Record-level database access, data queues, program call, command call, and user space -- if security requirements are met, functions are performed by directly calling OS/400 or i5/OS APIs instead of making a socket calls to host servers to carry out a request." That's pretty clear: the native optimizations bypass the host servers. As to why the 32-bit PASE version may outperform the classic JVM, the reasons are twofold. First is the simple mathematics of using half the memory for pointers. 32-bit pointers use less memory. More importantly, though, is the fact that the JVM running in the PASE environment (as opposed to the SLIC) will be closer to the silicon. There is something to be said for removing the JVM from the restrictions of the TIMI and letting it act as "just another kernel". (This however is still supposition; we'll need to see real benchmarks.) If you'd like to know more about Blair Wyman, you might try Google yourself. You'll probably come up with a few good references. He tends to present all over the world. Joe

      Comment


      • #18
        The System i Strategy for New Customers

        ** This thread discusses the article: The System i Strategy for New Customers **
        After sleeping on it, I recalled that using the the native JDBC driver would bypass socket based QZDASOINIT jobs, but would communicate instead with QSQSRVR jobs. I'm not sure how to read "functions are performed by directly calling OS/400 or i5/OS APIs", because IIRC there is no way to directly share parameter pointers between the two runtime environments.

        Comment


        • #19
          The System i Strategy for New Customers

          ** This thread discusses the article: The System i Strategy for New Customers **
          The native optimizations bypass all host server functions via direct calls. This is explicit, and indicates that you're wrong in your premise. The JVM lives under the TIMI along with the database stack, the comms stack, the security stack and all the other basic OS functions. They are interoperable and share the same address space. Nathan, at this point you insist on sticking by your recollections faulty as they may be ("IIRC", "AFAIK") as opposed to published information from IBM. Unless you have some facts to back up your statements, I have to bow out of this conversation. Joe

          Comment


          • #20
            The System i Strategy for New Customers

            ** This thread discusses the article: The System i Strategy for New Customers **
            I need to blow out of this conversation too, Joe. There isn't much documentation available about what IBM does below the machine interface, and we both understand that's where the 64-bit JVM "lives". Seeing Jobs like QZDASOINIT and QSQSRVR running above the machine interface, and seeing all the resources allocated to them to service requests from the Java runtime is about all I can point to as evidence of separation.

            Comment

            Working...
            X