1. zAAP zSeries Application Assist Processor (zAAP or IFA) (z/OS V1R6 and z990)

2. Marketplace Insight e-business on demand™ is here
Strategic Web-based application exploitation is increasing at exponential rates
Much of this technology is driven by Java™
Java technology-based applications require more resources than traditional applications (up to 2 to 3 times more)
Levels of abstraction, code generation, and reuse result in longer path lengths
Web-based applications can be a source of competitive advantage
Web-based application workloads are often unpredictable
IT budgets are not growing exponentially
In the e-business On Demand era, the only constant is change. As a result, business requirements are changing more frequently than ever. New strategic web applications are being developed and deployed much more rapidly in an effort to remain current and competitive in the face of today’s constantly evolving business environment.
Java adoption and application development continues to accelerate in the marketplace as an open, highly strategic and productive programming model. It’s design and richness of function make it the tool of choice for programmers to write robust, bug free code that can run on almost any platform. Applications developed using Java, however, can be fairly unpredictable and typically require significantly more processing and memory resources (often 2-3x more) than traditional applications. This is due to Java’s platform independent architecture characteristics, which generates applications with high levels of abstraction, code generation and reuse which result in longer path lengths, larger memory footprints and other potential inefficiencies.
IT budgets unfortunately, are not growing exponentially and clients continue to seek more strategic, efficient, productive and cost effective ways of deploying these new strategic Java technology-based applications.
From a customer perspective, there are a variety of new workload deployment options. Depending on the required levels of integration and platform qualities of service required, each option has its applicability:
Distributed, multi-tier implementation using a z/OS backend database server
Linux for zSeries with z/OS database backend
Tightly integrated z/OS Application and Database Serving environment
The IBM eServer zSeries is the industry’s leading platform for to providing the security, flexibility, scalability, resiliency and integration capabilities needed to respond to the realities of today’s dynamic marketplace.
While helping to protect and extend the value of existing zSeries investments, zAAPs are being introduced to strategically enable the integration of new JAVA based workloads within the core z/OS backend database environment for reliable, resilient, highly secure and cost effective on demand computing.
By leveraging zAAPs, customers can help consolidate, simplify and reduce server infrastructures and improve operational efficiencies. Co-location of the database and application server can provide both operational and performance advantages over a physically separated multi-tier solution. These advantages come not only in the elimination of TCP/IP and the associated latency but also in the tight security integration, and most importantly the ability to run the transactions using native z/OS services rather than a distributed 2-phase commit protocol.
At the end of the day, this is about increasing the zSeries marketplace attractiveness for the integration of new Java technology-based workloads with mission-critical data in the most secure and resilient environment the industry offers. This can reduce infrastructure resources and improved operational efficiencies over distributed multi-tier implementation while helping to protect and extend the value of existing zSeries Investments.

3. Introducing the zAAP zSeries Application Assist Processor
New specialty assist processor dedicated exclusively to execution of Java cycles under z/OS
zAAP for e-business integration and infrastructure simplification
Leveraged by workloads with Java cycles, such as WebSphere®, DB2®
Can help simplify and reduce server infrastructure and improve operational efficiencies
Enables integration of e-business applications with mission-critical database workloads
Potential operational advantages over distributed multi-tier solutions
Available on IBM eServer™ zSeries® 990 (z990) and zSeries 890 (z890) and future zSeries servers only
Executes Java cycles with no changes to applications
Priced at $125K per zAAP engine
Traditional IBM zSeries software charges unaffected
Sub-capacity eligible IBM software charges can be reduced
So, what is the zSeries Application Assist Processor (or zAAP for short)?
Well, it’s the newest, specialty workload processor on both the z890 and the z990 that provides a specialized z/OS Java execution environment for customers who desire the powerful integration advantages and traditional Qualities of Service and core strengths of the zSeries platform.
This optional feature, or assist processor, is designed to be a separate resource pool available to z/OS partitions dedicated to the execution of only Java workload cycles . When configured with central processors within logical partitions running z/OS, zAAPs may enable customers to:
Simplify and reduce server infrastructures and integrate e-business Java Web applications next to mission critical data for high performance, reliability, availability and security.
Increase system productivity by reducing the demands and capacity requirements on general purpose processors which may then be available for reallocation to other zSeries workloads.
Lower the overall cost of computing for WebSphere Application Server and other Java technology-based applications; through hardware, software and maintenance savings.
However, the core value from zAAPs is that it enables the strategic integration of new JAVA based web applications with the traditional z/OS core business database environment more cost-effectively than previously possible:
Available on the z990 and z890 (and future models only) , the zAAP is attractively priced at $125K USD, (similar to an Integrated Facility for Linux or IFL) and significantly lower than that of a standard engine.
From a software perspective, this optional assist feature allows customers to purchase additional processing power exclusively for Java workload execution without affecting the total MSU rating or machine model designation as zAAPs do not carry a rated capacity. Consequently, IBM does not impose software charges on zAAP capacity. Additional IBM software charges will apply only when additional general purpose CP capacity is used. (Customers are encouraged to contact their specific ISVs/USVs directly to determine if their charges will be affected)
Furthermore, zAAPs may have the effect of reducing charges for Sub-capacity eligible IBM software products by lowering the rolling 4-hour average MSUs for LPARs with assigned zAAPs
So how does it work?
zAAPs are very similar in concept to a System Assist Processor (SAP) and even an Integrated Facility for Linux (IFL) with the exception being that the zAAP can only execute Java. Unlike standard CPs, ICFs, and IFLs, zAAPS can do nothing on their own; they cannot be IPLed and only assist the general purpose processors in the execution of Java programming
zAAPs are designed to operate asynchronously with the central processors to execute Java programming under the control of the IBM Java Virtual Machine (JVM). This can help reduce the demands and capacity requirements on central processors which may then be available for reallocation to other zSeries workloads.
Consider this example. A typical WebSphere application that is transactional in nature takes 1000 MSUs today on zSeries and consumes 80% of the machine or LPAR capacity. And, lets assume that half of the application is Java. With the zAAP, the design objective is to reduce the standard CP capacity requirement to 500 MSUs or a 50% reduction by allowing the Java engine (or zAAP) to process those cycles. This can effectively reduce the capacity requirements on the standard CPs (down to 40% utilization) allowing them to process other workloads. The total system can now be enabled to get more work done overall than it would be without zAAPs. The amount of central processor savings will vary based on the amount of Java application code executed by zAAP(s). This is dependent upon the amount of Java cycles used by the relevant application(s) and on the zAAP configuration/execution mode selected by the customer.
Best of all, The IBM JVM processing cycles can be executed on the configured zAAPS with no anticipated modifications to the Java application(s). Execution of the JVM processing cycles on a zAAP is a function of the IBM's Software Developer’s Kit (SDK) 1.4 product, z/OS 1.6 (or z/OS.e 1.6), and the Processor Resource/Systems Manager™ (PR/SM™).
And finally, the zAAP feature is planned for general availability on June 30, 2004; with software exploitation planned for September 24, 2004 with z/OS 1.6
Essentially, as well all know, the industry already recognizes that the zSeries is the safest, most secure, most available, most scalable, and most reliable platform on which to run their legacy workloads and critical databases on. Now there is a set of compelling economic, performance, security and reliability reasons to integrate key strategic Java applications here as well.

4. zSeries Application Assist Processor (zAAP): Technology Overview
A new assist processor for Java applications on z/OS
zAAPs enable a more competitive zSeries data and application server
zAAPs can be significantly more cost-competitive
Corresponding zAAP software pricing (z/OS, WAS) provides for a total zSeries hardware/software price/performance solution
Takes advantage of the z990 processor-rich environment
Builds upon z/OS increased processor scaling capabilities in z/OS 1.6
> 16 processors within a logical partition
Provides a true single-tier integrated application and database server
Direct, integrated application serving and database access within the same logical partition
Security and transaction contexts, network stack efficiencies (no wires, fewer TCP/IP stacks, firewalls, and so on)
1st Tier
2nd Tier
3rd Tier
A new special purpose integrated JAVA engine
zAAPs are designed for z/OS JAVA code execution
z/OS JVMs switch their execution from standard processors to zAAPs
JVM executes JAVA code on zAAPs
Calls (JNIs) to DB subsystems (e.g., DB2) switch back to standard processors
DB returns (JNIs) to JAVA switch back to zAAPs
Provides a true Single Tier integrated application and data base server
Superior performance and QoS over typical 3-tier front-end application server TCP/IP connected back-end data server platforms
zAAPs provide the basis for a more competitive zSeries data base and application serving
zAAPs are significantly more cost competitive
Corresponding zAAP software pricing (z/OS, WAS) provides for a total zSeries hardware/software price/performance solution
Client
Application
Servers
Data Base Servers
Client
Application
Servers
Client
Network Servers
A 3 tier Computing Network

5. Integrated z/OS Web App & Database Serving
Leveraging zAAPs for e-business Integration and Infrastructure Simplification
zAAPs can help consolidate, simplify, and reduce server infrastructure and improve operational efficiencies
Enables strategic integration of e-business applications with mission-critical database workloads
Potential operational advantages over distributed multi-tier solutions
Eliminates separate tier to handle application server workload
Remove one hardware tier
Remove one TCP/IP link
Leverages core zSeries strengths and manages Java Workloads automatically with z/OS
zSeries Security
zSeries Workload Manager (WLM)
zSeries Availability
zSeries Scalability
zSeries Flexibility
BEFORE
1st Tier
2nd Tier
3rd Tier
Client
App Server
z/OS Database Server
Networked Web Serving
zAAP
enabled
AFTER
Provides a cost competitive single tier integrated CONTAINER FOR:
Application deployment (e.g., WAS JAVA development platform)
Direct, integrated DB access within the same logical partition w/o all the overhead implied by a TCP/IP communications stack
Security & transaction contexts, Network stack
Provides all of the zSeries and z/OS QoS within the same logical partition
Takes advantage to the z990 multi-book scaling capabilities
Builds upon the z/OS increased processor scaling capabilities in z/OS 1.6
> 16 processors within a logical partition
Introduces a new special purpose engine built upon existing zSeries specialized engine technologies
ICFs, IFLs, SAPs
1st Tier
2nd Tier
Client
Integrated z/OS Application & Database Server
Integrated z/OS Web App & Database Serving
Standard CP
zAAP

6. zAAP Concept Overview: A Simplified Example…
Consider a WebSphere application that is transactional in nature and requires 1000 MIPS today on zSeries.
80% utilization
Java Execution Powered by zAAP
Java
Java
40% utilization
Java
Java
Strategic Intent and Concept Overview of zAAP:
Strategic Web based applications are increasing at exponential rates
Much of this is driven by JAVA technology-based applications
JAVA applications require more IT resources than traditional applications
Levels of abstraction, code generation, and reuse result in longer path lengths
Web based application workloads are often unpredictable
Web based applications can be a source of Competitive Advantage
Budgets are not growing exponentially so customers are more open than ever to low cost, more efficient solutions.
Objective: Move JAVA processing cycles to a lower cost, fully integrated zSeries Operating Environment
Java
Java
Java
Java
1000 MIPS for WebSphere App
500 MIPS for WebSphere App +
500 MIPS now available for additional workloads
In this example, with zAAP, we can reduce the standard CP capacity requirement for the Application to 500 MIPS or a 50% reduction. * For illustrative purposes only

7. zSeries Processing Units (PUs)
Must have at least one standard CP defined for a partition
Can set the number of IFAs for an LPAR
Inherited definitions from standard CPs
If they are dedicated or shared
Although IFAs uses the same weight value you setup for the standard CPs you should be aware that the final weight of the IFAs can be different
There is no support for soft capping
IFAs do not participate in IRD support
IFAs are brought online and offline like standard CPs
The number of IFAs ordered may not exceed the limit of available engines in the machine model
For a z990 D32, for example, the maximum number of zAAPs you can order is 16
Using the 1 to 1 ratio for planning IFAs on machine, one CP must be installed with or prior to any IFAs being installed

8. zAAP Technical Overview: z/OS zAAP Partition
General
Shared
physical
Processor
zAAP
General physical Processor Pool
General CP Instructions
Java
Logical CP
… .
z/OS dispatcher only dispatches Java tasks on zAAP logical processors and general processor tasks on general logical processors
Logical partition hypervisor only dispatches standard logical processors on standard physical processors & zAAP logical processors on zAAP physical processors
z/OS Logical Partition
zAAP physical Processor Pool
zAAP Technical Overview
When a z/OS logical partition is configured, both CPs and zAAPs are defined as necessary to support the planned Java and non-Java workloads. zAAPs may be configured as initially online or reserved for subsequent use by z/OS as necessary. Since zAAPs cannot be IPLed at least one central processor is required for each z/OS partition.
zAAPs may be defined as either shared by other logical partitions or dedicated to a specific partition; however, both the CPs and zAAPs for each partition will have the same shared or dedicated attribute. For a given partition, you cannot define shared central processors and dedicated zAAPs or vice versa. PR/SM configures shared zAAPs from the same pool of shared special purpose processors as the Internal Coupling Facility (ICF) and Integrated Facility for Linux (IFL). Collectively, all shared ICFs, IFLs and zAAPs will also dynamically share in the processing requirements for all three special purpose processor types as controlled by PR/SM.

9. zAAP Architecture and Workflow: Executing Java under IBM JVM Control
IBM JVM, parts of LE runtime, and z/OS Supervisor needed to support JVM execution can operate on zAAPs
IBM JVM communicates to z/OS dispatcher when Java code is to be executed
When Java is to be executed, the work unit is "eligible" to be dispatched on a zAAP
z/OS dispatcher attempts to dispatch zAAP eligible work on a zAAP (when present)
zAAP ineligible work only dispatched on standard processors
If there is insufficient zAAP capacity available, or standard processors are idle, the dispatcher may dispatch zAAP eligible work on a standard processor
There is an installation control to limit the use of standard processors to execute zAAP eligible work (see Java code execution options)
Standard Processor
zAAP
WebSphere
z/OS Dispatcher
Execute JAVA Code
z/OS Dispatcher
Dispatch JVM task on z/OS
zAAP logical processor
logical processor
JVM
Switch to zAAP
JVM
z/OS Dispatcher
Suspend JVM task on z/OS
standard logical processor
Java Application Code
Typical zAAP Workflow
It's important to note the following:
zAAPs only execute z/Architecture mode instructions
zAAPs can only execute IBM´s JVM code, Java code, and associated z/OS infrastructure code (e.g., z/OS dispatcher, supervisor services, etc.)
IBM´s JVM is the only authorized zAAP exploiter
When z/OS is IPLed, it determines how many zAAPs are configured and subsequently assigns Java programming to the zAAPs when requested by the JVM. The JVM communicates with the z/OS supervisor to enable the JVM as eligible for execution on a zAAP. The next time the zAAP is available for dispatching, the JVM task is selected for execution. The z/OS dispatcher, operating in conjunction with the z990 PR/SM facility, dispatches zAAP eligible tasks on available zAAPs. Standard CPs also dispatch zAAP eligible work subject to installation controls described later. During the execution of the Java programming, when there is a Java Native Interface (JNI) call which executes code outside the JVM (e.g., DB2), the JVM again communicates with the z/OS dispatcher to switch execution back to the next available central processor. On return from the JNI call, the JVM again enables itself as zAAP eligible and the above process is repeated
This graphic depicts the IBM JVM requesting z/OS to switch execution to a zAAP, and then to switch back to a general purpose processor when the Java application ends, or when the application requests a non-Java programming function such as a database request. The z/OS dispatcher performs the switching operating to the appropriate logical processors. The Processor Resource/System Manager (PR/SM) then performs the appropriate logical processor switching to an associated physical processor
Executing on a zAAP
z/OS Dispatcher
z/OS Dispatcher
logical processor
Dispatch JVM task on z/OS
standard logical processor
JVM
JVM
JVM
Switch to
JVM
Switch to standard processor
z/OS Dispatcher
WebSphere
Suspend JVM task on z/OS
standard logical processor

10. zAAP Integration at Work: Java App Calling DB2
z/OS Logical Partition
Executed on a zAAP
Executed on a General Purpose Processor
RRSAF code
JDBC method
(ASM/PLX)
(Java code)
RRSAF
JNI
connection
Java
App
JDBC DLL 2 3 4 1
(C code)
DB2 address
space 8 6 5 7
zSeries IFJ Processors for z/OS application and DB Integration
This Chart illustrates a WebSphere server address space executing the IBM JVM and associated Java programming. In this example, the Java application program uses a Java Native Interface (JNI) to request a z/OS DB2 data base access. The JNI calls the Java JDBC API method which in turn calls the associated JDBC Dynamic Link Library (DLL) routine. The JDBC DLL then uses a database connecter (RRSAF) to interface with DB2, operating in its own address space, in order to access the application requested data. All Java programming in the red box (the JVM) is eligible to execute on a zAAP. All programming outside the JVM will execute only on general purpose processors.
Provides a cost competitive single tier integrated CONTAINER FOR:
Application deployment (e.g., WAS JAVA development platform)
Direct, integrated DB access within the same logical partition w/o all the overhead implied by a TCP/IP communications stack
Security & transaction contexts, Network stack
Provides all of the zSeries and z/OS QoS within the same logical partition
Takes advantage to the z990 multi-book scaling capabilities
Builds upon the z/OS increased processor scaling capabilities in z/OS 1.6
> 16 processors within a logical partition
Introduces a new special purpose engine built upon existing zSeries specialized engine technologies
ICFs, IFLs, SAPs
A new special purpose integrated JAVA engine
zAAPs are designed for z/OS JAVA code execution
z/OS JVMs switch their execution from standard processors to zAAPs
JVM executes JAVA code on zAAPs
Calls (JNIs) to DB subsystems (e.g., DB2) switch back to standard processors
DB returns (JNIs) to JAVA switch back to zAAPs
Provides a true Single Tier integrated application and data base server
Superior performance and QoS over typical 3-tier front-end application server TCP/IP connected back-end data server platforms
zAAPs provide the basis for a more competitive zSeries data base and application serving
zAAPs are significantly more cost competitive
Corresponding zAAP software pricing (z/OS, WAS) provides for a total zSeries hardware/software price/performance solution
JNI callback
JVM
Address space for the Java code

11. zAAP Characteristics: How zAAPs Differ from General-Purpose Processors
Some zAAP limitations:
zAAPs cannot be IPLed
zAAPs only executes z/Architecture™ mode instructions
zAAPs do not support all manual operator controls
No: PSW Restart, LOAD or LOAD derivates (load from file, CD-ROM, server)
zAAPs do not respond to SIGP requests unless enabled by a z/OS that supports zAAPs
Additional architecture differences are anticipated in future implementations
For example, Java-specific performance enhancements
The z/OS design accommodates processor differences for zAAPs:
No I/O interrupts
No Clock Comparator interrupts
No affinity scheduling
zAAPs are configured via the normal PR/SM LPAR image profile
zAAPs may be defined as shared or dedicated processors
Shared zAAPs may be PR/SM weighted and capped as per standard processors
zAAP support: the existing single set of PR/SM LPAR processor weights (INITIAL, MIN, MAX) are applied independently to the shared standard processors and separately to the shared zAAP processors configured to the LPAR
z/OS WLM will manage standard shared CPs as today but not shared zAAPs
zAAPs may be defined as either "initially" available or "reserved" just as standard processors
Have their own feature code
Are not capacity rated
Do not affect the overall MSU rating of a CEC or an LPAR
May be purchased up to a 1 to 1 ratio with standard processors
All Java code can be offloaded to zAAPs (including vendor Java code)
Execution of Java on standard CPs, zAAPs, or both, is under user control (see Java execution options)

12. zAAP Configuration Execution Options
zAAPs are configured via the normal PR/SM™ Logical Partition Image Profile
Java Application code can be executed under any of the following user-specified options:
Option 1 - Java by Priority (IFAHONOR_PRIORITY = Yes)
Standard processors execute both Java and non-Java work in priority order (as when zAAPs are not configured)
Option 2 - Java Discretionary Crossover (IFAHONOR_PRIORITY = No)
Standard processors execute non-Java work in priority order and Java work in priority order only when there is no non-Java work to execute
Option 3 - No Java Crossover (IFACrossover = No)
Standard processors execute only non-Java work in priority order
The selected switching option can be dynamically changed by a SET OPT command
Enhanced RMF™ reports (to include zAAP usage)
Standard processors: reporting as today
Timing enhancements for zAAPs
Enhanced SMF records (to include zAAP usage)
Type 30 & Type 72
New fields for zAAP time and zAAP eligible on a CP
IFJs Are Configured via the Normal PR/SM Logical Partition Image Profile
IFJs may be defined as shared or dedicated processors
Shared IFJs may be PR/SM weighted and capped as per standard processors
The existing single set of PR/SM logical partition processor weights (INITIAL, MIN, MAX) are applied independently to the shared standard processors and to the shared IFJ processors configured to the logical partition
z/OS WLM will manage standard shared CPs as today but not shared IFJs
JAVA application code can be executed under any of the following user specified options
Option 1 - JAVA by Priority (HONOR_PRIORITY = Yes)
Standard processors execute both JAVA and non-JAVA work in priority order (as when JAFs are not configured)
JAFs execute only JAVA work in priority order
JAVA work reduced or stopped on standard processors when maximum MSUs would be exceeded
This is the z/OS default option
Option 2 - JAVA Discretionary Crossover (HONOR_PRIORITY = No)
Standard processors execute non-JAVA work in priority order and JAVA work, in priority order, only when there is no non-JAVA work to execute
Might be selected when JAVA work would consume too many standard processor cycles due to it's priority
Option 3 - No JAVA Crossover (CROSSOVER= No):
Standard processors execute only non-JAVA work in priority order
For customers that don’t want JAVA executed on more standard processors (e.g., due to a SCRT software pricing license)
Processor crossover only if last JAF fails
SDK1.4.1 has new JVM options to handle IFAs
-Xifa:on - Enables Java work to run on a IFA if a IFA is available
-Xifa:off - Disable the use of IFAs
-Xifa:projectn - Designed to estimate projected IFA usage and write this information to STDOUT at intervals of n minutes
-Xifa:force - Designed to force Java to continue attempting to use IFAs, even if none are available

13. Always Use zAAPs or Not… ?

14. Investment Flexibility
zAAP Advantages
Industry Solutions
Common Middleware
Open Standards
Integration
Automation
Logical Partitioning
Greater Server Efficiency through Self-Optimization
Mature Systems Management
Virtualization
Resilient
Security-rich
Scalability
Balanced Performance
Mainframe Qualities of Service
zAAPs for e-business Integration and Infrastructure Simplification
Integrate Java technology-based applications with mission-critical data
Helps reduce infrastructure complexity for multi-tier applications
zAAPs Provide Investment Flexibility
Extend the value of existing zSeries investments and lower total cost of ownership
Cost-effective, specialized Java execution environment
Low Total Cost of Acquisition ($125K USD per zAAP)
Helps reduce Total Cost of Ownership (software and Maintenance Savings)
Investment Flexibility
Integrate e-business Web applications with core business database workloads to help meet the e-business requirements for resilient, security-rich, simplified, and cost-effective on demand computing.

15. Requirements for zAAP Exploitation
Available on z990, z890, and follow-on models only
Prerequisites:
z/OS 1.6 (or z/OS.e 1.6)
IBM SDK for z/OS, Java 2 Technology Edition, V1.4 with PTF for APAR PQ86689
Processor Resource/Systems Manager™ (PR/SM) must be enabled.
Subsystems and apps using SDK 1.4 will exploit zAAPs automatically:
WAS 5.1
CICS® /TS 2.3
DB2 V8
IMS™ V8
WebSphere WBI for z/OS
zAAPs must be jointly configured with general purpose processors within z/OS LPARs
Number of zAAPs may not exceed the number of permanently purchased CPs (including z990 unassigned CPs or z890 Downgrade - Record Only CPs) on a given machine model.
Subsystems that will exploit zAAPs include: e.g.,
Subsystems using SDK for z/OS, Java 2 Technology Edition, exploit automatically and z/OS V1R6 or z/OS.e V1R6
WebSphere Application Server (WAS) 5.1
CICS TS 2.3
DB2 V7 and V8
IMS V7, V8 and V9
WebSphere WBI for z/OS
Other Software
z/OS 1.6 (Required)
SDK 1.4 ( ) with UQ88783
IBM, Vendor and Customer Java applications are expected to run

16. Total Value of z/OS 1.6 Requires z/Architecture Server
Extending z/OS scale
Support for up to 24 engines in a single z/OS image (1.6)
Improved scalability of WebSphere (1.6)
Application flexibility
Support for zSeries Application Assist Processor (zAAP) (1.6)
64-bit application development with 64-bit C/C++ and 64-bit Java SOD (1.6)
Self-optimizing
Simplified Workload Manager control for WebSphere (1.5)
GA End of ordering End of service
z/OS 1.4 9/02 9/ /07
z/OS 1.5 3/04 9/ /07
z/OS 1.6 9/04 tbd tbd

17. zAAP Summary Challenges: zAAP …an industry first
New strategic Web-based application exploitation increasing at exponential rates
Much of this technology is driven by Java technology-based applications
Java technology-based applications require up to two to three times the resources of traditional applications
zAAP …an industry first
Only specialized processing units for Java Code today
Supported by IBM middleware such as WebSphere, DB2, and so on
Helps reduce demands on general-purpose processors – makes them available for other work
zAAPs for e-business integration and infrastructure simplification
Integrate Java technology-based applications with mission-critical data
Helps reduce infrastructure complexity for multi-tier applications
zAAPs provide investment flexibility
Extend the value of existing zSeries investments and lower total cost of ownership
Cost-effective, specialized Java execution environment
Low total cost of acquisition ($125K USD per zAAP)
Helps reduce total cost of ownership (software and maintenance savings)