db2 for zos data sharing for...

DB2 for z/OS Data Sharing for EverybodyDB2 for z/OS Data Sharing for Everybody

Bart Steegmans

© 2010 IBM Corporation

Bart Steegmans

GSE meeting 3 June 2010

A dAgenda• What is DB2 data sharing and why would you want it ?

• DB2 Data Sharing Architecture

• Increased availabilityIncreased availability

• Systems management

W kl d t• Workload management

• Summary

Many thanks to Michael Dewert Jeff Josten andMany thanks to Michael Dewert, Jeff Josten and Mark Rader for allowing me to use parts of their material.

© 2010 IBM Corporation1

DB2 for z/OS Data Sharing What and why ?DB2 for z/OS Data Sharing – What and why ?


Th ld h h dThe world has changed

• When DB2 Data sharing was introduced in 1995• When DB2 Data sharing was introduced in 1995• Only for the “happy few”

At th t ti th j it th• At that time the major reason was capacity growth

• A lot has changed since• Increased availability needs with ALL customers

• Fewer opportunities for planned outages

• Unplanned outages can cause a ‘disaster’ for the business

• Server consolidations

• If you are not using DB2 data sharing already, maybe this is a good time to look into what it can bring to your


g g yinstallation

3

DB2 D t Sh i D fi itiDB2 Data Sharing Definitions

• DB2 data sharing – allows applications running on• DB2 data sharing – allows applications running on more than one DB2 subsystem to read and write to the same set of data concurrently

• DB2 data sharing – allows customers to provide highest level of scalability, performance and continuous availabilityto enterprise applications

112

2

3

4567

8

9

1011

DB2A

112

2

3

4567

8

9

1011

DB1AGroup: DSN0A

to enterprise applications that use DB2 data

DB2ADB1A

SCA

Local Locks(IRLM)

Local Buffer Pools

Local Locks(IRLM)

Local Buffer Pools

SCA

Locks

GBP

CatalogDirectory

UserData


BSDSLogs

WorkFiles

BSDSLogs

WorkFiles

RuntimeLibraries

RuntimeLibraries

4

Alternative Parallel DBMS ArchitecturesShared Nothing (SN)

Database is partitionedNo disks are shared amongst the nodes

Node 1 Node 2 Node n. . .

Alternative Parallel DBMS Architectures

No disks are shared amongst the nodes Distributed commit is necessaryData repartioning necessary as nodes are addedSusceptible to skewed access patterns

Shared Disks (SDi)No database partition necessary– But partitioning can give better performance

Strong fail-over characteristics


Strong fail over characteristicsDynamic load balancingInter-node concurrency and coherency control mechanisms are needed– Messaging overhead limits scalabilityMessaging overhead limits scalability

Coupling Technology Shared Data (SDa)Adaptation of SDiCoupling facility is used as hardware assist for efficient


Coupling facility is used as hardware assist for efficient concurrency and coherency controlStrong fail-over and load balancing as with SDiFlexible growthMessaging overhead minimized excellent scalability


Messaging overhead minimized, excellent scalability

Why DB2 Data Sharing?Why DB2 Data Sharing?• General drivers

• Capacity: outgrow single system size• Avoid splitting the databases

• Continuous availability requirements• Protect against planned and unplanned outages

• Easier growth accommodation and cost effectiveness• Need scalable, non-disruptive growth

• Dynamic workload balancing• Effective utilization of available MIPS for mixed workloads• Handle unpredictable workload spikesS lid i f i• System consolidation for easier systems management

• Application Investment Protection• SQL interface is unchanged for data sharing• SQL interface is unchanged for data sharing• Applications do not need to become "cluster aware" • “Turbo Charger” for existing applications


Wh DB2 D t Sh i 2 ?Why DB2 Data Sharing -2 ?

• Leverage existing infrastructure• Leverage existing infrastructure• Enhanced Operational Capability

• Enhanced Return On InvestmentEnhanced Return On Investment Better leverage of your investment in the mainframe

• Low Risk Implementation – as technology is proven

• Low cost or high cost implementation choices available


DB2 for z/OS Data Sharing ArchitectureDB2 for z/OS Data Sharing – Architecture


P ll l S l (PSX)Parallel Sysplex (PSX)Sysplex Timer Protocol (STP)

• Scalable Capacity

• Flexible ConfigurationFlexible Configuration

• Workload Balancing

• 7x24 Availability

S S• Single System Image

• PSX Components:

S l Ti P t l (STP)– Sysplex Timer Protocol (STP)• ‘Sysplex Timers’

– Coupling Facility (CF) LPARsHigh speed shared memory FICON• High-speed shared memory

• CF Control Code (CFCC)• Structures (Lock, Cache, List)

– CF LinksCF Links– CF Resource Management (CFRM)

Policy

– Cross-System Extended Services (XES),


y ( )part of z/OS

DB2 D t Sh i B iDB2 Data Sharing Basics• A DB2 Data Sharing Group consists of:g p

• 2 or more DB2 members with a single Catalog/Directory• 1-way data sharing initially, for migration, etc.

• Active and archive logs for each member• Use log record sequence number (LRSN) instead of RBA

• DB2 and User data on shared disk

• For DB2 use Coupling Facilities (CFs) contain:• For DB2 use, Coupling Facilities (CFs) contain:• 1 Lock structure per data sharing group

1 Sh d C i i A (SCA)• 1 Shared Communications Area (SCA) per group

• Multiple Group Buffer Pools (GBP) per group


• 1 GBP per Buffer Pool containing shared data• GBP0, GBP8K0, GBP16K0, GBP32K0 required

DB2 Data Sharing Implementation StepsDB2 Data Sharing – Implementation StepsCoupling Facilities

11211

Sysplex Timer Protocol (STP)

11221011112234567891011 1122345678

91011SCALOCK1

Group BP

DB2A1 D t Sh i

DB2B

IRLM Buffer Pools 1-way Data SharingIRLM Buffer Pools 2-way Data Sharing

DB2A Log

Shared DASD

DB2 Cat/Dir DB2 DBsDB2B Log


DB2 N-way Data SharingDB2 N-way Data SharingCoupling Facilities

11211

Sysplex Timer Protocol (STP)

11221011112234567891011 1122345678

91011SCALOCK1

Group BP

DB2A DB2B DB2n

IRLM Buffer Pools IRLM Buffer Pools IRLM Buffer Pools

......

DB2A Log

Shared DASD

DB2B Log DB2n Log... DB2 Cat/Dir DB2 DBs


C iti l P f F tCritical Performance Factors

• Two factors to preserving data integrity in a data• Two factors to preserving data integrity in a data sharing environment• Inter-system concurrency control - global lockingInter system concurrency control global locking

• Multiple readers OR • One writer

• Inter-system buffer coherency control – managing changed data

• When one system changes data rows that also reside in other• When one system changes data rows that also reside in other system(s)

• "Data sharing overhead" is attributable to the extra CPU cost needed to manage these two factors• Thousands to tens of thousands of messages per

d t bl ll d i d t


second – not a problem on a well designed system

I t t C C t lInter-system Concurrency ControlGlobal locking using

S CPSX Coupling Technology:

N d 1 N d 2

usecLock ATx1:

Node1 Node2

Lock A

Lock B (no wait)

Tx2:(no wait) Lock

Structure ( )Coupling Facility

• Cost of obtaining lock does not increase when adding (3rd through nth) DBMS instances (scalability)


I t t B ff C h C t lInter-system Buffer Coherency ControlManaging changed data usingPSX Coupling Technology:

Node1 Node2Store-in caching

Tx1:Update page P1 (1)

Tx2:g

usecRead and Register P1 (1)GroupC it Coupling

Facility (2)

R f h P1(3)(3)

( )

Coupling Facility

Group Buffer Pool

CommitWrite P1’ & send XI (2) *(no wait)

Access P1: P1 is invalid

usecRefresh P1(3)

usecBP BPCoupling Facility

P1 P1’ P1

( )

XP1’

* Cross-invalidate (XI) to other member without interrupt


Cross invalidate (XI) to other member without interrupt.

CASTOUT iCASTOUT processing• CASTOUT is the process that ‘hardens’ Sharedchanged pages in the GBP to disk.• CASTOUT will occur when:

• CLASST exceededDB2A DB2B

SharedData

CLASST exceeded• Analogous to VDWQT

• GBPOOLT exceeded• Analogous to DWQT

CastoutBuffer

Castout• GBP checkpoint• No more inter-DB2 interest

in the page set Local LocalB ff

Castout

• GBP being rebuilt, but alternate GBP is not big enough to contain cached pages

BufferPool

Buffer

PoolGlobalBufferpages Pool


D i G l D t Sh i P fDesign Goals - Data Sharing Performance

• Little or no performance impact if data not actually• Little or no performance impact if data not actually shared, i.e. if no inter-DB2 R/W interest• Dynamic recognition of sharingDynamic recognition of sharing

• Minimal and acceptable CPU overhead if inter-DB2 R/W interest existsinter DB2 R/W interest exists• Overhead will vary based on individual workload

characteristics

• Near-linear scalability when adding 3rd through nth

nodes• Incur majority of data sharing overhead going from 1-way

to 2-way


• Beyond 2-way, additional overhead is minimal

DB2 D t Sh i OLTP S l bilitDB2 Data Sharing OLTP Scalability

• IMS/TM with DB2 V4 OLTP workload• 96 75% of ideal scalability from 2 to 8 nodes demonstrated


• 96.75% of ideal scalability from 2 to 8 nodes demonstrated

D t Sh i P f SData Sharing Performance Summary• CPU cost of data sharing varies based on:

• CF access intensity for locking and caching. This varies based on:

• Percentage of CPU time in DB2g• Degree of read/write sharing• Number of locks obtained• Access rate to shared data

I t/d l t i t it• Insert/delete intensity• Release of DB2

• Hardware configuration• Lock contention rates

• Data sharing cost varies from one workload to another• 'Typical' 2-way data sharing overhead about 10%

• Important: this is relative to the workload, not an address space• Individual jobs/transactions may have higher overhead


Individual jobs/transactions may have higher overhead• < 0.5% added cost per member past 2-way

D t Sh i P f i P d tiData Sharing Performance in Production• Host CPU effect with primary application involved inHost CPU effect with primary application involved in

data sharing• 10% is a typical averageyp g

• Scalability and performance for real life customer workloads

Industry Trx Mgr /DB Mgr

z/OSImages

CF accessper Mi

% of usedcapacity

Pharmacy CICS/DB2 3 8 10%

Insurance CICS/IMS+DB2 9 9 10%

Banking IMS/IMS+DB2 4 8 11%

Transportation CICS/DB2 3 6 8%

Banking IMS/IMS+DB2 2 7 9%

Retail CICS/DB2+IMS 3 4 5%

Shipping CICS/DB2+IMS 2 8 9%


Note: “Mi” stands for ‘million instructions’

DB2 for z/OS Data Sharing Increased availabilityDB2 for z/OS Data Sharing – Increased availability


D i f Hi h A il bilitDesign for High Availability

• Most single points of failure eliminated:• DB2 subsystem or z/OS system

CPC ( CEC)• CPC (or CEC) • I/O path

Goal: Continuous availability across planned or• Goal: Continuous availability across planned or unplanned outage of any single hardware or softwareelement

• Strategy:• Remove all causes for planned outages

f f S• Build on legacy of robust, fault tolerant MVS components• On a failure:

• Isolate failure to lowest granularity possible


• Isolate failure to lowest granularity possible• Automate recovery and recover fast

DB2 Member Outage –Planned DB2

Group

• "Rolling" maintenance• One DB2 stopped at a time

DB2B

.…...DB2A DB2n

X X• DB2 data continuously

available via the N-1 members• Other members temporarily pick• Other members temporarily pick

up work of the member that is down• Batch work can be offloaded to another

member with more available capacity to reduce the batch window

• Applies to hardware and operating system changes tooApplies to hardware and operating system changes too• Rolling IPLs

•• KEY TO SUCCESS:KEY TO SUCCESS: Applications must be able to


KEY TO SUCCESS: KEY TO SUCCESS: Applications must be able to run on more than one DB2 member!

DB2 R l Mi tiDB2 Release Migration• DB2 Data Sharing Group can be available – and

applications executing - across release migrations pp g g• N/N+1 release levels can coexist • Coexistence of mixed releases in a data sharing group can

dd l itadd complexity• Consult DB2 manual, Data Sharing: Planning and

Administration for details• Process:

• Apply SPE to each DB2 member• Restart each DB2 member• Put in new release• Restart each DB2 member• Restart each DB2 member

• Catalog migration done once per data sharing group• Catalog migration locks some of the catalog


g g g• Recommendation: Perform during a period of low activity

DB2 M b O tDB2 Member Outage –Unplanned DB2

Group

• The other "surviving" members remain up and running

Th hit t ll ll b

DB2B

.…...DB2nDB2A

• The architecture allows all members to access all portions of the data base

• Work can be dynamically routed away• Work can be dynamically routed away from the failed DB2 member – assuming applications can run on >1 DB2

• The failed member holds "retained locks" to protect inconsistent data from being accessed by other members

• MVS Automatic Restart Manager (ARM) can automatically restart failed DB2 members

• Restart ‘Light’ minimizes impact of LPAR failures


• Restart Light minimizes impact of LPAR failures

C li F ilit O tCoupling Facility Outages• Planned outages: use the z/OS

operator command to "rebuild"CF1 CF2

operator command to rebuild• REBUILD moves the structures to

another CF LPARDB2A DB2B

. . .

• No outage to data sharing group• REALLOCATE to ‘move’ back

• Unplanned outages: the system automatically recovers the lost structures• Lock & SCA are dynamically rebuilt into alternate CF• Lock & SCA are dynamically rebuilt into alternate CF

• Spare CF capacity required to house the structures• ‘White space’ part of CF capacity planning

• GBPs must be duplexed for high availability• GBPs must be duplexed for high availability• DB2 for z/OS allows duplexing of Lock and SCA but

duplexing not necessary for high availability


• Unless in a 2-ICF configuration.

D l i 2 Ki dDuplexing – 2 Kinds• “User-managed” duplexing

A li t GBP• Applies to GBPs• “User” = DB2; DB2 is responsible for managing two

structures in different CF LPARs• “System-managed” duplexing

• Applies to LOCK1 and SCAXES ( /OS) i ibl f i t t t i• XES (z/OS) is responsible for managing two structures in different CF LPARS

• DB2 is not aware of second structure• Everything happens on the primary then on the secondary• Everything happens on the primary, then on the secondary

• Recommended if CFs run on Internal Coupling Facilities (ICFs) and co-reside on CEC with DB2 members

• Avoid ‘double failure scenario’• Avoid double failure scenario• More expensive than DB2’s user managed duplexing (more CF requests)

• For best availability and performance, ensure that Lock and SCA are failure-isolated from the DB2 members


GBP D l iGBP Duplexing• Allocate secondary GBP on alternate CFAllocate secondary GBP on alternate CF• Write changed pages to both primary and secondary• If loss of connectivity or loss of structure -If loss of connectivity or loss of structure

• Switch to secondary (seconds)• No rebuild required; changed pages already in GBPq g p g y• Cross-invalidate buffers and gradually repopulate directory

entries

• No application outage unless both primary and secondary GBPs are lost

• Always enable GBP duplexingAlways enable GBP duplexing• Minimal performance overhead• Can avoid long outage time in case of CF failure


g g

V5 GBP D l i RV5 GBP Duplexing RecoveryIRWW workload

Measured at 08/22/98


P ll l S l C fi tiParallel Sysplex Configurations

CF01CF01

A B

DB2A

ICF02

DB2BDB2A DB2B

CF02CF02

C DDB2BDB2A DB2A

DB2B

ICF02ICF01 ICF01 ICF02


P ll l S l C fi tiParallel Sysplex Configurations• A: “Traditional” configuration

• LOCK1 and SCA in one CF• Duplexed GBPs spread across both CFs

• Primary and secondary GBPs balanced based on load

A

Primary and secondary GBPs balanced based on load

•B: One Integrated CF (ICF), one external CFLOCK1 d SCA i t l CF• LOCK1 and SCA in external CF

• Duplexed GBPs spread across both CFs• Primary GBP in ICF has advantages for ‘local’ DB2

B

•C: Two ICF configuration• Lock1 and SCA duplexed; allocated in both CFsC

• “System-managed” duplexing• Performance implication for LOCK1 requests

• Duplexed GBPs spread across both CFs

C


• Primary GBP in ICF has advantages for ‘local’ DB2

S l i BSysplex in a Box

• Some SAP customers use this configuration to avoid• Some SAP customers use this configuration to avoid planned outages• Still at risk of unplanned outages, especially hardwareStill at risk of unplanned outages, especially hardware

MVSBDB2B

MVSADB2A

ICF02ICF01


Disaster Recovery (DR) PlanningDisaster Recovery (DR) Planning

M di t t h i il bl d d• Many disaster recovery techniques are available and used• PTAM

• XRC• XRC

• GDPS

• …

• Don’t forget to delete the DB2 CF structures before starting up at the remote site!!!

• HyperSwap to protect against DASD failures• Used by GDPS for site failover

• z/OS 1.10 “Basic Hyperswap” for local site availability (not DR)

• Recommendation:


• Practice Disaster Recovery processes and procedures

G hi ll Di d P ll l S lGeographically Dispersed Parallel Sysplex

GDPSParallel SysplexSingle System z

12 1

456

1011 12 1

2345 6 7

89

1011

Site 1 Site 2+System zSite 1Site 1


DB2 for z/OS Data Sharing Systems managementDB2 for z/OS Data Sharing – Systems management


S t tSystems management• Requires a parallel sysplex

• New hardware • CF, CF links, Sysplex Timer Protocol (STP), ..y p ( )

• New software components• XCF XES CFRM policy• XCF, XES, CFRM policy, ..

• Existing software behaves differentE DB2 d diff t t t i th CF• Eg. DB2 needs different structures in the CF, ..

• Not just DB2, but also MVS, IMS, CICS, …

• Don’t rush into it – Build knowledge !• Carefully design, set up , test


• DR will be have to be adjusted as well36

S t M t 2Systems Management -2• Goal: Single - system image• DB2 data sharing "ease of use“ features:

• Command prefix support• Group attachment name• DDL, Bind, utilities, authorization

are all "group scope" Transaction Managers

Network

are all group scope• Single DDF location name for the

DB2 data sharing group

CICS IMS TM DDFWAS

Appl Appl Appl Appl Appl• Subset: LOCATION ALIAS

• "Group scope" on display output"G " f li


• "Group scope" for online performance monitors

• Log merging for replication (IFCID 306)z/OS Parallel Sysplex


g g g p ( )

DB2 for z/OS Data Sharing Workload managementDB2 for z/OS Data Sharing – Workload management


D i W kl d B l iDynamic Workload Balancing• Workload Manager (WLM)• CICSPlex System Manager (CPSM)

• Route workload between CICS TORs and AORsTORs and AORs

• IMS Transaction Manager (TM)• Shared message queues Transaction Managers

Network

• BMPs• WebSphere

CICS IMS TM DDFWAS

Appl Appl Appl Appl Appl

• Connection pooling• Connection concentration

• Distributed access (DDF)


• Distributed access (DDF)• Dynamic Virtual IP Addressing

(DVIPA)z/OS Parallel Sysplex


• Sysplex Distributor

W bS hWebSphereTo exploit DB2 Data Sharing workload balancing and transparent failover,both application server connection pool AND connection concentrator/

A li ti S

both, application server connection pool AND connection concentrator/ connection pool should be used

Application Server

ResourceDB2 Universal Driver JDBC/SQLJ

JVM

Transporton

ResourceAdapter Logical

Connection 1

L i l l d ti1

Transport 2

App

licat

i

JCAConnectionManager

LogicalC i

LogicalConnection

2

CFpooled connectionsto DB2 Data Sharing

Group

DBConnection

Pool

Connection 3

disconnectat commit/rollback


S l Di t ib t d DVIPASysplex Distributor and DVIPAFirst connection through Sysplex Di t ib t d t i t hi h DB2

“DB2 Universal Driver JDBC/SQLJ”IBM Data Server Driveror DB2 Connect

Distributor determines to which DB2 member the requester will attach -Workload Balancing-Availabilityy

“DB2 Universal Driver JDBC/SQLJ”O DB2 C t

Sysplex Distributor

CONNECT TO GroupIP

Or DB2 Connect CF

Pooled connections to DB2 Data Sharing Group

CONNECT TO GroupIP


DB2 for z/OS Data Sharing Applications changesDB2 for z/OS Data Sharing – Applications changes


Application Changes?Application Changes?• SQL interface does not changeg

• However, locking and commit frequency may impact data sharing performance• Commit frequently – long time recommendation

(Also applies to non-data sharing)

• Take advantage of lock avoidance• ISO(CS) and CURRENTDATA NO

• New messages and return codes

• Applications should be able to run on more than oneApplications should be able to run on more than one DB2 member for high availability

• Summary: “Turbo Charger” for existing applications


y g g pp

43

D d t h i ll ll li ?Does data sharing allow parallelism?V3 V4

I/O ParallelismSingle Execution UnitMultiple I/O streams

CP ParallelismMultiple Execution UnitsEach has a single I/O stream

TCB( i i ti

V4

SRBs(paralleltasks)

(originatingtask)

V5Sysplex Query ParallelismSysplex Query ParallelismP ll l t k d P ll l S lParallel tasks spread across Parallel Sysplex

I/O Channel

Memory

Processor

I/O Channel

Memory

Processor

I/O Channel

Memory

Processor


Best Practices Can Help You ImproveBest Practices Can Help You Improve• Availability

• Tune for fast DB2 restarts• Tune for fast DB2 restarts

• Tune RETLWAIT system parameter to wait for incompatible retained locks instead of immediate rejection

• Use Restart Light for LPAR failures

• Combine with z/OS Automatic Restart Manager (ARM)

• Use GBP Duplexing• Use GBP Duplexing

• Utilize rolling software upgrades

• Use advanced disaster recovery features

• Performance• High performance insert

• Minimize lock contention• ISO(CS) CURRENTDATA(NO) or ISO(UR) to encourage lock avoidance

and minimize impact of retained locks


• Commit frequently !

• Avoid “XIs due to directory reclaims”45

Best Practices Can Help You Improve 2Best Practices Can Help You Improve -2• Avoid “affinity routing”

S l bl li ti t lti l DB2 b• Sysplex-enable applications to run on multiple DB2 members

• Symmetry of group brings operational simplicity, makes it easy to scale out horizontally, and easier to roll software maintenance

• Remove application affinities to specific DB2 members so that connections can be dynamically rerouted to other members

• Achieve much better high availability if affinity routing is avoided• Achieve much better high availability if affinity routing is avoided

• Avoid limiting access to an object from a single member• Makes continuous availability unworkable• Retained ‘X’ page set P-lock prevents access from other members until failed member completes

forward phase of restart


DB2 D t Sh i Sh ld B i Y LifDB2 Data Sharing Should Be in Your Life

• Data sharing technology provides the base to allow• Data sharing technology provides the base to allow DB2 to deliver continuous availability and nearly unlimited scalability into the future

• DB2 Data Sharing is a proven technology• Many customers in DB2 data sharing productiony g p

• Work is ongoing to deliver further data sharing enhancements in future releases


DB2 for z/OS Data Sharing SummaryDB2 for z/OS Data Sharing – Summary


DB2 d t h i d P ll l S lDB2 data sharing and Parallel Sysplex

G it 11211• Grow capacity• More tran/sec

12

3

4567

8

9

1011

DB2A

112

2

3

4567

8

9

1011

DB1AGroup: DSN0A

• Reduce ET for singlequery by exploiting sysplex CPU //

Local Locks(IRLM)

Local Locks(IRLM)

sysplex CPU //

• Increase availabilityU l d t

SCA

Locks

Local Buffer Pools

Local Buffer Pools

• Unplanned outages

• Planned outagesGBP

CatalogDirectory

UserData

• Rolling maintenance

• Workload distribution BSDSLogs

WorkFiles

BSDSLogs

WorkFiles

RuntimeLibraries

RuntimeLibraries

Directory Data


Enhanced Operational Capability andEnhanced Operational Capability and Return On Investment• Have you already invested heavily in system infrastructure ?• Have you already invested heavily in system infrastructure ?

• Not getting full value from that investment ?

• Leverage existing investment and achieve step change in operational capability

• Significant improvement to in-site operational recovery capability

N d l f i it f il b bl d• New model for in-site failover can be enabled• vs. full Disaster Recovery invocation

• Better utilisation of existing system resources through workload balancing


• Removing scaling factors that might inhibit M&A activity50

L I l t ti Ri kLow Implementation Risk

• Well proven technology• Well proven technology

• Widespread deployment around worldwide global customer communitycustomer community

• Global experience and skills

• Evolve to target environment with incremental change

• Target applications with demanding requirements for ti il bilitcontinuous availability


You are in good companyYou are in good company

fiservfiserv.


Thank youThank youQuestions?Questions?

[email protected]


_ g @

Disclaimer© Copyright IBM Corporation 2009. All rights reserved.U S G t U R t i t d Ri ht U d li ti di l t i t d b GSA ADP

Disclaimer

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS ANDPURPOSES ONLY. WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. IN ADDITION, THIS INFORMATION IS BASED ON IBM’S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE FOR ANYSUBJECT TO CHANGE BY IBM WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY OTHER DOCUMENTATION. NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, NOR SHALL HAVE THE EFFECT OF, CREATING ANY WARRANTIES OR REPRESENTATIONS FROM IBM (OR ITS SUPPLIERS OR LICENSORS), OR ALTERING THE TERMS AND CONDITIONS ( ),OF ANY AGREEMENT OR LICENSE GOVERNING THE USE OF IBM PRODUCTS AND/OR SOFTWARE.

IBM, the IBM logo, ibm.com, and DB2 are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. S h t d k l b i t d l t d k i th t i A t li t f IBM


Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml

54

db2 for zos data sharing for...

Documents