A couple more points: 1. zAAP isn't only for Java any more. The z/OS XML System Services now exploit zAAP. The z/OS XML System Services are available for z/OS 1.7 and higher, and one major user of the z/OS XML System Services is DB2 9 for z/OS, assuming you use DB2's XML features. (This may be reason alone to move to DB2 9 quickly.)
IBM has a couple statements of direction indicating there will be more XML exploitation of zAAP in the future, including the z/OS XML Toolkit. 2. The zAAP could influence decisions about how you implement certain functions, yes. But remember that even optimized Java has a longer path length than, say, optimized COBOL. A factor of 10 is not out of the ordinary. Thus I doubt it would be wise to perform non-trivial database joins in Java code versus letting DB2 do the work, for example. But things were a lot more "interesting" with respect to XML parsing. There are many ways to parse XML, including in Java code (e.g. the Xalan/Xerces libraries for Java). It turns out that XML parsing with Java is one of the most zAAP-eligible workloads. So there were some very weird cases where, for example, XML PARSE in COBOL consumed a lot more CPU (on CPs) than XML parsing in WebSphere (which loves the zAAP, longer path length and all). That probably explains in part why there's a lot of focus on moving other XML processing to zAAP and zIIP. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
