wp_ibm_ziipspecengformf_focus_2009

by Joel Starkman

A White Paper

The IBM zIIP Specialty Engine for

Mainframe FOCUS

A Benchmark of Significant CPU Cost Reductions

Joel Starkman is director of Operations for the FOCUS Division at Information

Builders, responsible for the creation, delivery, and support of all FOCUS

releases and their functional consistency with the back-end of iWay Software

and WebFOCUS. Joel is a 30-plus-year veteran of FOCUS application

development for Fortune 100 companies, using FOCUS for everything from

financial systems reporting to real-time control of an industrial robot.

Joel guided the functional implementation of zIIP support for the FOCUS

product, working closely with the programming staff to coordinate and test

the user-visible and efficiency aspects of its implementation.

Joel Starkman

Executive Summary

zIIP Benchmark Tests Recap

Background – Advantages of the zIIP Specialty Engine

Mainframe FOCUS Utilization of the zIIP

Is Implementing the zIIP for FOCUS Beneficial?

Local Adjustments That Improve zIIP Usage

Benchmark Tests and Statistical Rewards

Benchmark: Database Variations

Benchmark: Report Size Variations

Benchmark: Typical Application Activities

Conclusion

Appendix I

zIIP Usage Statistics

Appendix II

IBM Workload Manager Tuning

Types of Goals

Appendix III

Glossary

Table of Contents

2

5

7

8

9

13

14

14

15

15

1

3

4

5

6

11

13

14

15

Information Builders1

Executive Summary

As of Release 7.6.10, FOCUS is enabled to run on the system z Integrated Information Processor

(zIIP) engine. This white paper demonstrates the types and approximate amounts of FOCUS

workload transferred to the zIIP under various conditions, and the resulting cost reductions.

The zIIP specialty engine from IBM offloads CPU-intensive workloads from the central processors

(CPs). Since the MIPS capacity of the zIIP engine is not included in the overall rating of the

mainframe, all work incurred using the zIIP engine is free from IBM. Installing a zIIP can be a way to

delay a system upgrade, and it may also be a performance enhancer for products enabled to run

there and for the overall system.

About 80 percent of FOCUS code is able to run on the zIIP, which accounts for as much as 95

percent of CPU capacity, though it will more generally be in the 30 to 80 percent range. These

estimates are above the already documented 20 to 40 percent performance improvement of

Release 7.6 over prior releases due to our continuous improvement program using all of the newer

technologies available. During the zIIP enablement development effort, all of the technical and

legal implementation restrictions imposed by IBM were rigorously respected.

Some internal processes must continue to run on the central processor due to IBM specifications

regarding the types of workload the zIIP may process. Productive zIIP activity is monitored by

FOCUS, and FOCUS reacts accordingly to ensure that IBM-billable CPU charges are minimized

against zIIP-related overhead.

The actual amount of processing diverted to the zIIP is largely dependent on the goal settings

declared locally to the IBM Workload Manager (WLM), which specifies the priority of FOCUS access

to the zIIP in competition with other software. FOCUS provides methods for the user to query zIIP-

related CPU information and improve zIIP-related processing. There are also techniques available

to adjust the application to best take advantage of the zIIP engine when running FOCUS.

If you do not have a feel for how much a zIIP engine installed at your site can reduce the cost

of FOCUS processing, you may simulate the presence of a zIIP engine if none exists, or you may

simulate giving full access to FOCUS processing on an existing zIIP. System statistics will then tell

you how FOCUS would perform with full zIIP advantage.

The IBM zIIP Specialty Engine for Mainframe FOCUS2

zIIP Benchmark Tests Recap

Information Builders designed benchmark tests to evaluate the amount of workload transferred to

the zIIP under specific conditions and test scenarios. The results summarize as follows:

DB2 results vary, depending upon the local configuration of FOCUS and DB2.

CPU Savings

Type of Report or Activity Using zIIP Interpretation

Executive Summary Report 77% Roll-up, out to PDF

Operational Report 64% Medium size

Extract Report 66% Show 100% of file

Exception Report 51% Extract a few records

Database Type Variations 1-88% Various sort methods and destinations*

Reporting Scenarios 59-99% One million records, various complexities

Transaction Processing 42-95% One million records, load, update, etc.

Actual Applications 46% Weighted average of five applications’ usage

Performance Benchmarks 76% Weighted average of targeted internal processes

* Several database types generate low zIIP advantage due to imposed record retrieval methods.


IBM’s zIIP specialty engine is the newest of several specialty engines that IBM has implemented

for mainframe consumption. The zAAP and IFL engines have been highly successful for JavaTM

execution, XML parsing, and Linux applications, respectively.

The zIIP engine offloads workload from the CP, also referred to as the general processor (GP). The

MIPS capacity of the zIIP engine does not count toward the overall MIPS rating of the mainframe

image, so all CPU usage incurred on the zIIP is not chargeable from IBM. Effectively, all workload

run on the zIIP is free.

The zIIP engine is factory-identical to a central processor (CP). It is restricted at installation

time via micro-code to perform specific types of workloads, but always runs at 100 percent of

processor capacity. The zIIP offloads heavily CPU-intensive workloads, leaving the CP more time

to absorb otherwise queued workloads as well as to perform its dedicated tasks of running the

operating system, handling I/O interrupts and timer interrupts, initiating jobs, and controlling user

interactions with the operating system. Therefore, some overall performance improvement can be

perceived across all mainframe activity. The true benefit of the zIIP is its cost reduction effect and

its potential contribution to delaying a system upgrade.

The actual zIIP benefit achieved for FOCUS or any product depends on the response time

goals declared by the local system administrator to the WLM when defining the priority of the

software’s access to the zIIP in competition with other software.

Background – Advantages of the zIIP Specialty Engine


As of Release 7.6.10, the zIIP engine is accessible to FOCUS for processing much of the typical

workload associated with a FOCUS request. zIIP activation begins upon user issuance of a SET

command if all applicable conditions for zIIP use pass properly. If the zIIP is not available to the lpar,

then processing simply continues on the CP; FOCUS continues to run. See the Benchmark Statistics

section (pp.7-13) that examines the gains achievable by use of the zIIP.

FOCUS diverts eligible workload to the zIIP by switching from TCB mode (for instructions that can

run only on the central processor) to SRB mode that engages a preemptible enclave for secure

execution of enabled workloads on the zIIP engine. Though a large percentage of the workload

is eligible for execution on the zIIP, the actual amount permitted to run on the zIIP at any moment

(therefore the benefit achieved for the FOCUS user) largely depends on the response time

goals declared in the WLM by the local system administrator; see the IBM Workload Manager

appendix (p.15).

During the zIIP development effort, all of the technical and legal implementation restrictions

imposed by IBM were rigorously respected. The major factor that affects zIIP’s performance is

IBM’s restriction that the zIIP does not handle I/O interrupts. In applications that require significant

database interrogation, high-volume sorting, or the use of third-party tools or user functions

during processing (most of which are present in typical applications), passing information among

these environments requires switching out of SRB (zIIP) mode into TCB (non-zIIP) mode to

communicate, and then back again to continue processing. This switching can occur thousands or

even millions of times during a single request. Although each switch is miniscule, the cumulative

effect can absorb visible amounts of CPU on both the zIIP engine and the CP. So optimizing this

communication is critical to maximizing the savings attained by using the zIIP.

FOCUS implementation of zIIP-enablement has done just that. FOCUS buffers the records passed

to the system sort utility and some of the adapters, rather than performing record-by-record

transmission, thus generating only one switch for each buffer-full.

FOCUS constantly monitors zIIP usage. When FOCUS detects that the cost ratio of switching

modes compared to work redirected to the zIIP crosses a non-productive threshold during a

task, FOCUS dynamically may decide to no longer use the zIIP just for the duration of that task or

command. Such situations may include pure extracts with few calculations from certain database

types where non-zIIP-able I/O is the dominant activity, or a very low aggregation ratio (such

as PRINT might induce) while extracting from a highly disorganized file. In every case, FOCUS

endeavors to ensure that the user spends no more on CPU cost with the zIIP than they would have

without the zIIP.

Mainframe FOCUS Utilization of the zIIP


If you do not have a zIIP at your site and you are not sure how much a zIIP would benefit FOCUS

processing, then add PROJECTCPU=ON to your sys1.parmlib table and run several jobs. This parm

will make FOCUS believe that a zIIP is available and attempt to redirect its work there. You can then

measure what the advantage of a fully accessible zIIP would be by looking at the &FOCZIIPONCP

reserved amper-variable in FOCUS. This value shows the amount of CPU that would have been

used by FOCUS on the zIIP, but was redirected to the CP by the system because the zIIP was

unavailable. With these results, you can see how beneficial the zIIP would be if a zIIP of sufficient

capacity and priority directed to FOCUS were actually available.

In another situation, you may already have a zIIP accessible to FOCUS, but FOCUS has insufficient

priority access to it such that FOCUS is currently deriving limited zIIP benefit. Under this

circumstance, try: SET ZIIP=SIMMAXZIIP in FOCUS. This will allow the job to run while simulating

full zIIP accessibility to see how much zIIP access the job would have had if the zIIP were 100

percent available for FOCUS usage.

Local Adjustments That Improve zIIP Usage

User-controllable factors that can improve the effect of the zIIP on the FOCUS application include:

Declare policy and goals of WLM to allow FOCUS to access the zIIP with sufficient priority ■

(compared to other zIIP-competing software) to derive significant CPU benefit. Negotiate with

operations to maximize the priority of FOCUS for zIIP access

Maximize the block size of files that are read or written by FOCUS to reduce the number of I/Os ■

required to access the file and therefore the number of switches to non-zIIP mode that FOCUS

would have to make

Move non-Information Builders 3GL functions from DEFINEs to COMPUTEs to reduce the ■

switching to non-zIIP mode for each such call, or rewrite them as DEFINE FUNCTIONS to avoid

the switch entirely

Is Implementing the zIIP for FOCUS Beneficial?


The benchmark tests demonstrate the relative amount of FOCUS workload transferred to the

zIIP during processing of several scenarios varying the file-type and type of request or activity.

These scenarios are selected as approximations of typical customer applications, and several tests

represent more extreme boundary situations. From these results, you may project the savings for

your particular application in accordance with how it parallels these examples.

Under these benchmark tests, WLM was directed to give highest priority to FOCUS, ensuring that

all zIIP-eligible code actually ran on the zIIP rather than having some percentage diverted to the

central processor. Note that some parts of FOCUS processing must always be done on the CP due

to zIIP restrictions.

The following categories of tests were developed and implemented to demonstrate the degree to

which FOCUS uses the zIIP in each instance:

Database Variations

Report Size Variations

Typical Application Activities

Benchmark Tests and Statistical Rewards

Full extractions from various database types, all with

identical database structures, contents, and sort orders.

Each test varies only one factor from the original

Typically sized customer reports in terms of data volume

extracted and report complexity, performed against the

same file

Various activities of reporting, data manipulation, and file

maintenance, most of which exist somewhere in a typical

application, plus execution scenarios of several actual

applications


Benchmark: Database Variations

These tests are full extracts from various database types, all with identical database structures,

contents, and sort orders. Each test varies only one factor from the first test in the list. FOCUS sort

is used unless otherwise stated.

Use zIIP No zIIP

Benchmark Case zIIP CP CP Save

(cpusec) (cpusec) (cpusec)

FOCUS file 36.94 13.73 38.74 65%

FOCUS file to Excel 52.11 7.45 60.89 88%

FOCUS file (DFSORT SORT) 18.14 19.35 27.47 30%

VSAM file 39.57 18.47 59.56 69%

Flat file 45.26 13.22 47.98 73%

IMS file 0.16 69.19 69.59 1%

DB2 file (optimized) 1.91 30.60 30.31 1%

DB2 file (unoptimized) 32.50 57.22 80.09 29%

Scenario: Four million records, all files with identical data, reduced down to 7,500 lines.

Analysis

Savings against a FOCUS file using FOCUS sort reach a respectable 65 percent ■

Outputting to Excel (or other styled formats) requires intensive additional CPU. Since virtually all ■

of that work is performed on the zIIP, the percent savings is much better

Using DFSORT means that the records to be sorted are transferred between FOCUS and the sort ■

package, requiring some buffered switching between zIIP and CP. There is still significant savings

over non-zIIP execution, but not as broad a percentage drop as with FOCUS sort

Newly buffered VSAM file data movement appears to be very efficient in terms of zIIP ■

participation

Flat file processing is highly effective, especially with a high blocking factor, which has always ■

been typical and prudent when reading or writing such files

Extracts from IMS files gain virtually no benefit from the zIIP since records exchanged between ■

IMS and FOCUS must be handled individually, i.e., there is no buffering. So switching between

zIIP and CP to satisfy the I/O restrictions becomes too expensive very quickly. The FOCUS zIIP

Monitor detected this situation early in the extract phase and completed the majority of the

extract task on CP, protecting the user from excessive costs; note that the CP costs of zIIP versus

non-zIIP were approximately the same. However, if the result had been directed to a styled

output like Excel or PDF, that CPU-intensive part of the processing would have occurred on the

zIIP, making the overall savings ratio of the request somewhat more skewed toward the zIIP


Both DB2 and FOCUS are independently zIIP-enabled products; either product’s choice to use ■

the zIIP is not directly influenced by the other product. For an optimized DB2 request, DB2 does

the majority of the work (extract, sort, aggregation) and FOCUS performs the post-retrieval

computations, report formatting, and any output destination processing, most of which runs on

zIIP. Unoptimized DB2 requests show more FOCUS/zIIP usage because FOCUS performs more

of the processing after DB2 merely returns all extracted records to FOCUS. CP usage is higher

for unoptimized cases (and always has been in a pre-zIIP environment). But assuming that a

particular request must be unoptimized due to its requirements, running it via zIIP still costs

much less than without it. DB2’s usage of the zIIP depends upon how it is locally configured

relative to FOCUS

Other database adapters supported by FOCUS (such as Adabas, IDMS, Millennium, Model 204, ■

Oracle, Teradata) have not yet been benchmarked, but are expected to be relatively consistent

with IMS results for much the same reasons as shown in the table for IMS in the first release.

Continuing work is being done and improvements are expected

Benchmark: Report Size Variations

These reports were specifically designed to approximate typical customer usage in terms of data

volume and report complexity. Tests were run under FOCUS Release 7.6.10.

Use zIIP No zIIP

Benchmark Case zIIP CP CP only Save


Executive Summary (roll-up, out to PDF) 2.49 0.91 3.91 77%

Operational Report (medium size) 3.18 1.82 5.08 64%

Extract Report (show 100% of file) 5.99 2.93 8.69 66%

Exception Report (extract few records after full table scan) 1.10 0.86 1.75 51%

Scenario: One million-record FOCUS file

Analysis

Savings are consistently over 50 percent ■

As the Executive Summary noted, PDF output and aggregation are highly CPU-intensive ■

activities, resulting in the largest savings

The Exception Report does very little formatting or aggregation since it is a short-resulting ■

report. Most of the cost is in extracting the data, which requires repeated switching to the CP, so

there is relatively reduced zIIP benefit

The Operational Report and Extract Report show intermediate savings and are close only by ■

coincidence. Their major activities (in addition to a full table scan) occur in temperate doses,

such as aggregation, sorting, HOLD output (in the case of extract), computations, and number of

fields requested


Benchmark: Typical Application Activities

These tests represent characteristic requests in mainstream customer applications including

TABLE, MODIFY, MAINTAIN, and other generally observed activities. As typical scenarios, they are

reused here for zIIP comparison purposes.

Use zIIP No zIIP

Benchmark Case zIIP CP CP Save


TABLE

Detail extract of 1M records (PRINT * HOLD) 3.1 4.4 7.6 42%

TABLE using IF for nonexistent record (full database scan) 1.1 0.6 1.4 57%

1M recs. SUM’ed to top level – 10 lines 2.4 0.5 3.0 83%

1M recs. SUM’ed to top level, DEFINE on every record 2.7 0.6 3.3 82%

1M recs. SUM’ed to 3rd level – 200 lines 2.4 0.5 3.1 84%

1M recs. SUM’ed to 3rd level – DEFINE on every record 3.2 0.5 3.8 87%

200K recs SUM’ed with COMPUTE 2.3 0.6 3.2 81%

COUNT on keys of all 4 levels – read all pages 2.6 0.6 3.1 81%

1M records SUM’ed to 1st level using MIN. and MAX. on 4th level field 2.6 0.5 3.2 87%

IF test on 4th level non-key field retrieves 10,000 records, but reads all 1M 1.1 0.6 1.5 60%

JOIN 100K record flat HOLD (400 bytes wide) to 1M record FOCUS file 1.7 0.4 2.1 81%

JOIN 100K record FOCUS HOLD to 1M record FOCUS file 1.6 0.4 2.1 81%

HOLD 100K records, then MATCH to 1M record FOCUS file 2.3 0.5 2.6 81%

Table 100K 400-byte records once, then HOLD PDF, HTML, EXL2K, WP 16.2 0.3 21.0 99%

Non-IF’able WHERE against 1M recs 2.9 0.5 3.37 85%

Extract 50K records from VSAM file 0.3 0.4 0.7 43%

MODIFY and MAINTAIN

COMBINE and MODIFY 21 files 0 .8 1.3 2.2 41%

MODIFY include 100K transactions into new FOCUS file 1.5 0.2 1.6 88%

MODIFY update 100K same sorted transactions selected from 1M 2.3 0.6 3.0 80%

MAINTAIN load 100K sorted 400-byte transactions 2.1 0.1 2.4 96%

UTILITIES AND MISCELLANEOUS

? FILE and ? FDT statistics on 71,000 FOCUS pages 0.4 0.4 0.7 43%

REBUILD DUMP/LOAD 1M records restrict to 100K recs 0.8 0.2 1.1 82%

COMPILE four 500-2500 line MODIFYs with up to 50 CRTFORMs each 3.8 0.1 5.0 98%

Load flat file via 10,000 Dialogue Manager – WRITEs 6.7 0.0 8.2 99%

Weighted average of 77 activities on 5 in-house production FOCUS appls 26.7 19.8 36.6 46%

Weighted average of FOCUS General Benchmarks for Performance 3.3 1.3 4.4 70%

Analysis

We see superior results on TABLE commands, most residing in the 80-plus percent savings range. ■

On normal FOCUS file sizes of one million records, the effort of I/O work to read the file trades off

well with average calculation density and output formatting requirements

The full table scans (one for all records and one for no records) both conclude with 40 to 60 ■

percent cost savings since they encounter few calculations and minor report formatting. Most of

the cost is in performing the I/O, which incurs switching overhead

The HOLD outputs to various styled formats are highly CPU intensive, calculation-based ■

operations. So the vast majority of the post-extraction processing is performed on the zIIP,

resulting in a 99 percent CPU cost savings


MODIFY transaction processing did well, CPU savings-wise. The voluminous COMBINE structure ■

incurred more I/O as it navigated the files, thus it produced a somewhat smaller return. The

MAINTAIN test is intentionally similar to the MODIFY test, so it does not even exercise the CPU-

intensive strengths of MAINTAIN stacking, yet it performed impressively

? File and ? FDT are entirely I/O operations, so their CPU savings are merely respectable. REBUILD ■

is largely an I/O operation, but the record constriction induced many calculations, so the 73

percent savings is a compromise

The COMPILE of a MODIFY is entirely oriented toward syntax parsing and internal instruction ■

flow generation, so 98 percent savings is fully expected

The five in-house production applications are several of the custom tools that drive the daily ■

business at Information Builders, and are highly complex in terms of exercising the FOCUS

language and pushing its capabilities. 46 percent falls in the projected range of cost reductions

for most customer applications

The General Benchmarks for Performance tests intensively target low-level internal operations. ■

Seventy percent cost reduction is in line with the application results above since the applications

by definition all use some combination of these low-level operations


The zIIP engine offers tremendous cost savings to the FOCUS user by offloading FOCUS workload

from the CP to the zIIP engine on which all CPU utilization is free of charge. FOCUS provides this

capability as of Release 7.6.10.

It is important for the local system administrator to allocate sufficient WLM priority for FOCUS’

access to the zIIP engine to take full advantage of the capability and savings offered.

FOCUS always ensures that zIIP usage for a specific request is of value in terms of cost, and will

protect the user from incurring higher costs due to the zIIP-related resource requirements of that

request.

Conclusion


zIIP Usage Statistics

zIIP-related usage statistics can indicate the benefit gained and CPU costs saved when the

zIIP engine handles some or most of the job’s workload. Properly interpreting the statistics is

important to this analysis. FOCUS provides several reserved amper variables that deliver pertinent

statistics about zIIP processor usage:

&FOCZIIPCPU CPU incurred on zIIP engine, normalized to the speed of CP

&FOCZIIPONCP CPU of work enabled for zIIP but sent to the CP by Workload

Manager and the dispatcher

&FOCCPU CPU incurred on CP; includes &FOCZIIPONCP

&FOCZIIPONCP indicates the amount of CPU spent by code that FOCUS had enabled for

execution on the zIIP but was diverted to the CP by Workload Manager and the dispatcher due

to circumstances of system load and competitive priorities at that moment. Optimally, this value

should be zero for the most savings in execution time and CPU cost. Note that any non-zero

amount of &FOCZIIPONCP is already included in &FOCCPU since it was actually incurred on the CP.

The total CPU for the step is the sum of &FOCZIIPCPU and &FOCCPU, intentionally excluding

&FOCZIIPONCP from the calculation.

Assuming &FOCZIIPONCP is zero or very small, then high amounts of &FOCCPU compared to

&FOCZIIPCPU implies that much of the processing required by the request was not eligible for zIIP

execution. Examine the recommendations in the “Local Adjustments Affect Actual zIIP Impact”

section for possible ways to shift more of the execution of this request to the zIIP engine.

Appendix I


IBM Workload Manager Tuning

WLM prioritizes queued workloads for distribution among the central processors and zIIP

processors based on a complex set of goals and rules established by the system administrator for

each product or other definable category. This applies to all workloads from all sources, not just

for FOCUS. All of these goals described here combine to influence the probability that FOCUS

requests are directed to the zIIP engine at any particular moment.

Types of Goals

Average Response Time Goals ■ declare that all jobs must finish within a declared average

amount of time – a continually recalculated value

Percentile Response Time Goals ■ state that a certain percent, say 90 percent, of all jobs must

finish within a given amount of time. The advantage of this type of goal is that it is not affected

by rogue jobs (the other 10 percent) that run much longer and effectively skew the Average

Response Time Goal toward improper expectations

Discretionary Goals ■ are for lesser priority jobs that given resources only when spare time exists

among higher priority workloads

Velocity Goals ■ complement the other goals by declaring an acceptable time by which any

job may be delayed once it is ready to run, ranging from “run immediately” to “keep it plodding

along until it is done”

System Goals ■ do not specifically belong to WLM, rather they are general operating system

targets for recognized types of work in several service classes

Appendix II


Glossary

3GL Third-generation language such as C, COBOL, PL/1, FORTRAN, or others

(including Assembler, which is a 2GL) in which subroutines may be written

and called from FOCUS (considered a 4GL).

Central Processor The general purpose chip of the IBM mainframe that typically handles the

mainframe workload.

Client SRB Created and executed like an ordinary SRB, but runs with client (scheduler)

dispatching priority and is preemptible.

CP Abbreviation for Central Processor, also known as General Processor. See

Central Processor.

Dispatcher Distributes workloads among available processors, depending upon

current workload conditions and target goals of WLM. Responsible for

determining which zIIP-eligible tasks may be offloaded to the zIIP engine

at any specific moment based on competing task priorities and goal

achievement targets.

Enclave Entity that encapsulates the execution units (TCBs and SRBs), which

execute programs on behalf of the same work request.

Enclave Service Enable workload manager to create and control enclaves

Enclave SRB Created and executed like an ordinary SRB, but runs with Enclave

dispatching priority and is preemptible.

General Processor Another name for Central Processor. See Central Processor.

GP Abbreviation for General Processor. See General Processor.

IFL IBM specialty processor for Linux applications.

I/O Input/Output. The act of reading or writing part of a file from disk or other

storage device. That part may be an individual record, or a block of records

determined by the blocksize of the file, or an entire track.

Preemptible Allows the dispatcher to interrupt a task at any time to run other work at

the same or higher dispatching priority. Non-preemptible units (like local

SRBs), once dispatched, continue to run until they complete or incur a

voluntary interrupt like suspend/page fault.

SRB Service Request Block. Dispatchable unit (DU) runs at supervisory priority;

not preemptible (zIIP-able). This is the mode in which FOCUS runs on

the zIIP.

Appendix III


Switch In the context of zIIP-related workloads, the intentional movement of a

portion of code processing from zIIP to non-ZIIP execution or vice versa as

required by IBM zIIP processor restrictions.

TCB Task Control Block. Dispatchable unit (DU) runs at dispatching priority of

address space; preemptible (non-zIIP). This is the mode in which FOCUS

runs on the Central Processor.

Velocity The acceptable amount of delay a process can be allowed to incur when

competing for execution among other tasks.

WLM Abbreviation for WorkLoad Manager. See Workload Manager.

Workload Manager z/OS monitoring tool that actively adjusts priorities of workload tasks so

the dispatcher can effectively distribute them among available processors

with the objective of achieving WLM performance goals.

zAAP Engine An IBM specialty processor for Java execution and XML parsing.

zIIP Engine An IBM specialty processor; accronym for z Integrated Information

Processor. Configured from the Central Processor chip via selective

microcode adjustments at installation time, the zIIP engine offloads CPU-

intensive workloads from the CP. The CPU capacity of the zIIP engine is not

counted toward the MSU capacity of the mainframe images, thus all work

processed by the zIIP engine is effectively free of charge.

Worldwide Offices

Corporate Headquarters Two Penn Plaza, New York, NY 10121-2898 (212) 736-4433 Fax (212) 967-6406 DN1101086.0909

informationbuilders.com [email protected]

Canadian Headquarters 150 York St., Suite 1000, Toronto, ON M5H 3S5 (416) 364-2760 Fax (416) 364-6552

For International Inquiries +1(212) 736-4433

Copyright © 2009 by Information Builders. All rights reserved. [85] All products and product names

mentioned in this publication are trademarks or registered trademarks of their respective companies.

Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc.

in the U.S. and other countries.

Printed in the U.S.A.

on recycled paper

North America

United States ■ Atlanta,* GA (770) 395-9913 ■ Baltimore, MD Professional Services: (703) 247-5565Boston,* ■ MA (781) 224-7660Channels, ■ (800) 969-4636Chicago,* ■ IL (630) 971-6700Cincinnati,* ■ OH (513) 891-2338Dallas,* ■ TX (972) 490-1300Denver,* ■ CO (303) 770-4440Detroit,* ■ MI (248) 641-8820Federal Systems,* ■ DC (703) 276-9006Hartford, ■ CT (860) 249-7229Houston,* ■ TX (713) 952-4800Los Angeles,* ■ CA (310) 615-0735Minneapolis,* ■ MN (651) 602-9100New Jersey* ■ Sales: (973) 593-0022New York,* ■ NY Sales: (212) 736-7928 Professional Services: (212) 736-4433, ext. 4443Orlando,* ■ FL (407) 804-8000Philadelphia,* ■ PA Sales: (610) 940-0790Phoenix, ■ AZ (480) 346-1095Pittsburgh, ■ PA Sales: (412) 494-9699St. Louis,* ■ MO (636) 519-1411San Jose,* ■ CA (408) 453-7600Seattle, ■ WA (206) 624-9055Washington,* ■ DC Sales: (703) 276-9006 Professional Services: (703) 247-5565

Canada

Information Builders (Canada) Inc.Montreal* ■ (514) 421-1555Ottawa ■ (613) 233-7647Toronto* ■ (416) 364-2760Vancouver ■ (604) 688-2499

Mexico

Information Builders MexicoMexico City ■ 52-55-5062-0660

Australia Information Builders Pty. Ltd.

Melbourne* ■ 61-3-9631-7900Sydney* ■ 61-2-8223-0600

EuropeBelgium* ■ Information Builders Belgium Brussels 32-2-7430240France* ■ Information Builders France S.A. Paris 33-14-507-6600Germany ■ Information Builders (Deutschland) Eschborn* 49-6196-77576-0Netherlands* ■ Information Builders (Netherlands) B.V. Amsterdam 31-20-4563333Portugal ■ Information Builders Portugal Lisbon 351-217-217-400Spain ■ Information Builders Iberica S.A. Barcelona 34-93-344-32-70 Bilbao 34-94-452-50-15 Madrid* 34-91-710-22-75Switzerland ■ Information Builders Switzerland AG Dietlikon 41-44-839-49-49United Kingdom* ■ Information Builders (UK) Ltd. London 44-845-658-8484

RepresentativesAustria ■ Raiffeisen Informatik Consulting GmbH Vienna 43-12-1136-3870Brazil ■ InfoBuild Brazil Ltda. São Paulo 55-11-3285-1050China ■ InfoBuild China, Inc. Shanghai 86-21-5080-5432 Beijing Xinrong Software Technology Co., Ltd. Beijing 86-10-5873-2031Denmark ■ InfoBuild AB Kista, SE 46-735-23-34-97Egypt ■ Al-Hisn Al-Waqi (AHAW) Riyadh, SA 996-1-4412664Ethiopia ■ MKTY IT Services Plc Addis Ababa 251-11-5501933Finland ■ InfoBuild Oy Vantaa 358-207-580-840Greece ■ Applied Science Athens 30-210-699-8225Guatemala ■ IDS de Centroamerica Guatemala City 502-2412-4212Gulf States ■ Al-Hisn Al-Waqi (AHAW)■ Bahrain ■ Kuwait ■ Oman ■ Qatar ■ United Arab Emirates ■ Yemen Riyadh, SA 996-1-4412664India* ■ InfoBuild India Chennai 91-44-42177082

Israel ■ SRL Group Ltd. Tel Aviv 972-3-7662030Italy ■ NessPRO Italy S.p.A. Genoa 39-010-64201-224 Milan 39-02-2515181 Turin 39-011-5513-211Japan ■ K.K. Ashisuto Osaka 81-6-6373-7113 Tokyo 81-3-5276-5863Jordan ■ Al-Hisn Al-Waqi (AHAW) Riyadh, SA 996-1-4412664Malaysia ■ Elite Software Technology Sdn Bhd Kuala Lumpur 60-3-21165682Norway ■ InfoBuild Norway Oslo 47-48-20-40-30Philippines ■ Beacon Frontline Solutions, Inc. Makati City 63-2-750-1972Poland/Central and Eastern Europe ■ InfoBuild SP.J. Warsaw 48-22-657-00-14Russian Federation ■ FOBOS Plus Co., Ltd. Moscow 7-495-926-3358Saudi Arabia ■ Al-Hisn Al-Waqi (AHAW) Riyadh 996-1-4412664Singapore ■ Automatic Identification Technology Ltd. Singapore 65-6286-2922South Africa ■ InfoBuild South Africa (Pty.) Ltd. Gauteng 27-83-4600800 Fujitsu Services (Pty.) Ltd. Johannesburg 27-11-2335911South Korea ■ Unitech Infocom Co. Ltd. Seoul 82-2-2026-3100 UVANSYS Seoul 82-2-832-0705Sweden ■ InfoBuild AB Kista 46-735-23-34-97Taiwan ■ Galaxy Software Services Taipei 886-2-2586-7890Thailand ■ Datapro Computer Systems Co. Ltd. Bangkok 662-679-1927, ext. 200Venezuela ■ InfoServices Consulting Caracas 58-212-763-1653

Toll-Free NumberSales, ISV, VAR, and SI Partner Information ■ (800) 969-4636

* Training facilities are located at these branches.

Documents

wp_ibm_ziipspecengformf_focus_2009