Application Management

Digg This!

Page 1 of 3   next page »

Running applications in WAS for z/OS lets you take advantage of the z/OS built-in Quality of Service features such as reliability, availability, scalability, and serviceability. However, the solution could be very expensive.

J2EE applications and WAS for z/OS are very CPU-intensive workloads on z/OS. They consume a lot more CPU cycles than the traditional workloads running on z/OS, especially when processing big XML files.

Normally the CPU utilization of an application running on z/OS is measured in MIPS. An application consuming more CPU cycles means that the MIPS number for the application is higher. To provide more MIPS to run your application, more CPUs are needed. However, adding more CPUs to a zSeries server causes virtually all software license fees to go up because of the zSeries's software license model, which by the machine's CPU horsepower.

This is not a new story. Companies have been using different ways to manage the software cost on the zSeries platform for years. When the J2EE applications start running in WAS for z/OS, it's harder to manage the software cost than before.

To reduce the overall cost of enabling Java on zSeries platform, IBM introduced zAAP for Java workloads on z/OS. The following sections describe what a zAAP is, how it works, and how to use it.

What Is zAAP?
zAAP stands for zSeries Application Assist Processor, also known as the Integrated Facility for Application processor (IFA). It's a specialized processing unit (PU a k a CPU on open systems) available on the zSeries 990 (z990), 890 (z890), and z9. It provides a strategic z/OS Java execution environment for customers who want the powerful integration advantages and traditional QoS of the zSeries platform.

Conceptually, zAAP is just a co-processor like your old PC's floating-point co-processor. Instead of working as a standalone general processing unit (CP), it only assists the general-purpose CPs to execute Java programming under the control of the IBM JVM. For this reason, zAAP's capacity doesn't incur IBM or third-party software charges. So you can buy additional processing power exclusively for Java application execution without affecting the machine model designation that's used to determine zSeries software cost.

zAAP has been designed to operate asynchronously with general CPs to execute Java programming under control of the Java Virtual Machine (JVM). Executing IBM JVM processing cycles on a zAAP is a function of the IBM Software Developer Kit (SDK) for z/OS Technology Edition V1.4, z/OS V1R6, and the Processor Resource/System Manager (PR/SM).

Figure 1 is a z/OS Logical Partition with zAAP. One zAAP can be configured per general processor in a Central Electronic Complex (CEC).

zAAP is enabled by IBM's innovative zSeries PR/SM virtualization technology. It can be virtualized into logical zAAPs and assigned to different LPARs. But zAAPs and general CPs should exist in the same z/OS LPAR. On z990s or z890s, zAAPs are grouped in the ICF/IFL/zAAP processor pool. The ICF/IFL/zAAP processor pool appears on the hardware console as ICF processors. The number of ICFs shown is the sum of IFL, ICF, and zAAP processors characterized on the server.

To exploit a zAAP, the operating system must be migrated to the following levels of software:

• z/OS V1R6
• IBM JDK V1.4 with a PTF for APAR PQ 86689
• For WAS for z/OS Java workloads, WAS for z/OS version 5.1 above

WAS for z/OS version 5.1 and above provide support for IBM's JDK 1.4. It makes WAS for z/OS one of the key workloads that can take advantage of zAAPs.

The z/OS exploitation of zAAP capabilities provides the following added values:

• Simplifies and reduces server infrastructures by integrating e-business Java Web applications next to mission-critical data for QoS.
• Maximizes the value of zSeries investment through increased system productivity, achieved by reducing the demands and capacity requirements on general CPs, which can be reallocated to other workloads.
• With WAS for z/OS, your application can exploit the z/OS Workload Manager (WLM), which can guarantee service levels for specific kinds of customers and workloads defined by business needs.

In summary, zAAP is a special PU on the zSeries server that the Java workload can be off-loaded to. The applications you have running in WAS for z/OS can still leverage the QoS features provided by z/OS.

How Does zAAP Work?
When a z/OS logical partition is configured, both CPs and zAAPs are necessary to support the planned Java and non-Java workloads. Normally a Web application running in WAS for z/OS consists of both Java and non-Java workloads.

Figure 2 is the zAAP workflow. It essentially explains how the zAAP works. The IBM JDK V1.4 JVM, parts of Language Environment (LE) runtime, and z/OS Supervisor are needed to support JVM execution on zAAP.

Some of the JVM tasks are dispatched to general CPs. Basically these tasks do the following:

• Determine if the program code is eligible to run on zAAP
• Signal the z/OS dispatcher of the zAAP work
• Handle the program code that's ineligible to run on zAAP

Other JVM tasks are dispatched to zAAPs. These tasks:

• Determine if the program code is eligible to run on zAAP
• Run the zAAP eligible program code
• Signal z/OS dispatcher of non-zAAP work

Whenever a Java unit of work is executed, it's initially dispatched on a general CP. Before the Java code gets executed in the JVM, the JVM determines if the work is eligible to run on the zAAP. If so, the JVM signals the dispatcher that the current unit of work is zAAP-eligible. Then the dispatcher puts the current unit of work in the zAAP dispatcher queue. When a zAAP processor becomes available, the dispatcher selects the highest-priority work from the zAAP work queue and dispatches it on the zAAP processor.

A zAAP-eligible unit of work can be executed on a zAAP. zAAP work inherits the dispatching priority from the execution on the general CP. When the JVM finishes Java code processing, it signals the dispatcher that the current unit of work is not zAAP-eligible any more. The unit of work release control puts it back in the general logical processor work queue.

If the application is a pure Java application, the entire application should be run on the zAAP. Unfortunately, most applications that run in WAS for z/OS use various native libraries implicitly. For example, the JDBC type II driver, MQ batch adapter, and CTG for CICS Access are all Java code wrapprd around native codes. WAS for z/OS itself has other native code to exploit the z/OS environment. So you might see the dispatcher switch the work back and forth between the zAAP and the general CP. You can see in Figure 3 the zAAP integration at work. Switching the works back and forth causes overhead. Using zAAP reduces the MIPS number on general CPs, but the total MIPS number is higher than before.

Page 1 of 3   next page »