Planning and executing a DB2 11 for z/OS Migration by Ian Cook

#IDUG
Planning and executing a DB2 11 for
z/OS Migration
Ian Cook
DB2 for z/OS Specialist, zChampion
IBM Software Group
Ian_Cook@uk.ibm.com
Session Code: Session 5
April 16th
2014, 16:00 – 17:30
Platform: z/OS

2
#IDUG
Disclaimer and Trademarks
Information contained in this material has not been submitted to any formal IBM review and is
distributed on "as is" basis without any warranty either expressed or implied. Measurements data have
been obtained in laboratory environment. Information in this presentation about IBM's future plans
reflect current thinking and is subject to change at IBM's business discretion. You should not rely on
such information to make business plans. The use of this information is a customer responsibility.
IBM MAY HAVE PATENTS OR PENDING PATENT APPLICATIONS COVERING SUBJECT
MATTER IN THIS DOCUMENT. THE FURNISHING OF THIS DOCUMENT DOES NOT IMPLY
GIVING LICENSE TO THESE PATENTS.
TRADEMARKS: THE FOLLOWING TERMS ARE TRADEMARKS OR ® REGISTERED
TRADEMARKS OF THE IBM CORPORATION IN THE UNITED STATES AND/OR OTHER
COUNTRIES: AIX, AS/400, DATABASE 2, DB2, e-business logo, Enterprise Storage Server,
ESCON, FICON, OS/390, OS/400, ES/9000, MVS/ESA, Netfinity, RISC, RISC SYSTEM/6000,
System i, System p, System x, System z, IBM, Lotus, NOTES, WebSphere, z/Architecture, z/OS,
zSeries
The FOLLOWING TERMS ARE TRADEMARKS OR REGISTERED TRADEMARKS OF THE
MICROSOFT CORPORATION IN THE UNITED STATES AND/OR OTHER COUNTRIES:
MICROSOFT, WINDOWS, WINDOWS NT, ODBC, WINDOWS 95
For additional information see http://www.ibm.com/legal/copytrade.phtml

3
#IDUG
DB2 11 for z/OS Migration Agenda
• Review the DB2 11 ESP
• Project Plan / Education
• Prerequisite Summary
• Pre migration planning
• Incompatibilities, removed &
deprecated items
• Test configurations
• Regression testing
• Migration Process Details
• Migration to Conversion Mode
(Running DSNTIJTC)
• Enable New-Function-Mode
(Running DSNTIJEN)
• Catalog Evolution / Restructure
•Application Compatibility
•RBA / LRSN Expansion
• Objectives
•Provide planning information
•Outline the migration process
•Share some lessons learned
•Hints, tips, best practices
•Help customers plan for, and
execute DB2 11 for z/OS migrations
as fast as possible, but safely

4
#IDUG
Review of the DB2 11 ESP

5
#IDUG
DB2 11 for z/OS Early Support Program (ESP)
• Major themes
• Performance enhancements
• Enhanced Resiliency and Continuous Availability
• Enhanced business analytics
• Simpler, faster DB2 version upgrades
• WW Customers (21 Core & 6 Extended (2H13))
• Banking, Insurance, Healthcare, Financial Markets, Automotive,
Computer Services, Professional Services
• Key Customer Focus Areas
• Regression testing, New Function
• Out-of-box performance, Additional performance
• Customer views of a DB2 ESP
• Easy access to experts with quick feedback
• Visibility of issues all participants encountered
• Most meetings very informative.
• Definitely want more ESP involvement
ESP Start February 2013
First Code Drop March 2013
“Regular” service process July 2013
GA October 25, 2013
ESP Close January 2014
Announce
Oct. 1, 2013
GA
Oct. 25
2013

6
#IDUG
DB2 11 ESP Customer Feedback
• Excellent quality and reliability at this early stage in the
release cycle
• Good performance and CPU savings
• DRDA workload up to 20% CPU reduction
• CICS workload up to 18% CPU reduction
• Batch workload up to 20% CPU reduction
• Greatest hits
• BIND, REBIND, DDL, Online REORG break in
• Transparent archiving
• IFI 306 filtering by object (Qreplication)
• Online schema change
• Utility improvements particularly Online REORG
• Extended LRBA/LRSN
• Optimizer and migration improvements
• GROUP BY Grouping Sets
DB2 V11
DB2 V11

7
#IDUG
DB2 11 ESP Migration Status at GA
• DB2 11 migration to CM and NFM
• All core participants had DB2 11 CM in sandbox or test systems
• All participants successfully completed DB2 11 NFM migrations, some with
multiple subsystems or data sharing groups
• DB2 10 NFM, DB2 11 CM regression testing
• DB2 10 NFM baselines completed by most
• Several ESP customers sent DB2 11 vs. 10 performance data to DB2 Lab for
analysis
• DB2 11 measurements looked favourable from the comparison data
sent
• Range of 5 to 20% CPU reduction in batch and OLTP workloads
• Increased zIIP offload in both DBM1 and MSTR
• ‘Near production’ systems running DB2 11 CM
• A host of new functions tested
• DB2 11 SAP Certified at GA
• Customer rollout plans in place for 2014
• Positive feedback continues

8
#IDUG
DB2 11 for z/OS ESP Feedback
DB2 11 SAP Certified at GA – the fastest ever certification
for any DB2 for z/OS release in history
DB2 11 Home Page
“I saw a significant performance improvement in recovery of catalog and directory.
(V10 5:53 minutes, V11 2:50 minutes) That rocks! … DB2 11 is the best version I
have ever seen.” - European Gov’t

9
#IDUG
DB2 11 for z/OS ESP Feedback…
“Overall we are very satisfied and astonished about the
system stability of DB2 V11. In V10 we experienced this in
another way.” – European Insurance
“We have seen very few problems in [Installation, Migration, and Performance]. Overall,
it has been a very pleasant experience!!…The quality of the code is clearly much
higher than for the ESP for DB2 10…” - European Banking/FSS
“Good code stability, no outages, no main failures, only a few
PMRs….” – European Banking
“We have been involved in several DB2 for z/OS ESP’s. This one will rank
as one of, if not the smoothest one yet.” – Large NA retailer
“Overall, we have been impressed with the new version of
DB2.” – NA Manufacturer

10
#IDUG
Where can I find further
information on
DB2 11 for z/OS?

11
#IDUG
Key sources of information
• Always refer to the most current documentation when planning your
migration projects
• Announcement Letter 213-376
• Program Directory - GI10-8945-00
• Installation Guide GC19-4056-02
• IBM Knowledge Center New
• DB2 11 Technical Overview Redbook (SG24-8180)
• DB2 11 for z/OS Buffer Pool Monitoring and Tuning
• DB2 11 for z/OS Performance Topics (SG24-8222)
• Technical Conference sessions at IDUG, GSE
• World of DB2 and the series of Webcasts on offer
• DB2 11 for z/OS Technical Overview (2 parts)
• DB2 11 for z/OS Migration Planning and Early Customer Experiences (2 parts)
• DB2 11 for z/OS Migration Planning Workshops
• Hands on Labs workshop coming soon in Hursley
• Experience a DB2 11 for z/OS migration for yourself
Click here for the latest
DB2 11 for z/OS
Product Documentation

12
#IDUG
DB2 11 for z/OS Education & Conferences
DB2 DB2 DB2
DB2
DB2
DB2
DB2
DB2
AVRIO
DB2
The Fillmore Group
Easy way to schedule the 4 GTPs
DB2

13
#IDUG
DB2 11 for z/OS Downloads & Videos
New IDUG Tech Talk:
DB2 11 for z/OS IDUG User Experiences
Sheryl Larsen Tuning SQL Seminar
Sheryl Larsen Advanced SQL Coding Seminar
80 WW DB2 Regional RUGS
DB2
Search for
DB2 topics

14
#IDUG
DB2 11 for z/OS Book Marks
TITLE URL OFFER TYPE
Molaro - How DB2 11 for zOS Can Help Reduce Total Cost of
Ownership
http://ibm.co/1hwmcrA Whitepaper
Stuhler - DB2 11 for z/OS Unmatched Efficiency for Big
Data and Analytics
http://ibm.co/16t00Nw Whitepaper
Improved query performance in IBM DB2 11 for zOS http://ibm.co/16xwar9 Whitepaper
IDUG: DB2 11 for z/OS An IDUG User Technical Perspective http://bit.ly/1cRz8dM Whitepaper
DB2 11 Marketing Flash Demo http://youtu.be/6E4zyu-
eZt4
Demo
DB2 11, Big Data & Analytics Overview & Highlights
Brochure
http://ibm.co/19SE3aL Brochure
DB2 11 and Real Time Business Critical Analytics (IBM
IDAA)
http://ibm.co/189R1S8 Whitepaper
BMW Group develops eco-friendly innovation for smart
drivers with IBM DB2 11
http://ibm.co/GIt7Tu Case Study
JN Data gets the early-adopter advantage for its growing
business with DB2 11
http://ibm.co/1b2NyE3 Case Study
DB2 11 for z/OS The Database for Big Data & Analytics http://ibm.co/160vQgM e-book
Special DB2 11 for z/OS Gaining a Competitive Edge: http://bit.ly/DB211webcast Webcast

15
#IDUG
DB2 11 for z/OS Packaging - PID 5615-DB2
•DB2 Base (HDBBB10)
•REXX
•MQListener
•IRLM V2R3 (HIR2230)
•IMS Attach (HIYBB10)
•RACF Auth Exit (HDREB10)
•Panels – English (JDBBB14)
•DB2 JDBC / SQLJ (JDBBB12)
•DB2 ODBC (JDBBB17)
•z/OS Appl Connectivity to DB2 for z/OS
•(HDDA211)
•DB2 Accessories Suite 5697-Q04
•JSON (II14727) & Data Studio 4.1
• (Announcement letter 213-395)
•DB2 QMF V11
•DB2 QMF Enterprise Edition
•DB2 QMF Classic Edition
Base
DB2 11 for
z/OS
Orderable
No-Charge
Features
Chargeable
Features
Related
No-Charge
Product
** When ordering DB2 11 for z/OS also order the DB2 Utilities Suite (5655-W87)

16
#IDUG
Project Planning & Detailed Test
Plans

17
#IDUG
Base your DB2 11 Migration Project on a solid Plan
• Don’t short change the planning phase
• Identify your migration stakeholders
• Justification for migration:
• Develop a plan to meet your business goals
• Performance, New features,
eventually support
• IBM announces “End of service”
for DB2 9, effective June 27, 2014.
• Establish a cross-discipline project team
• Systems Prog, DBA and Applications to
validate:
• The overall Project Plan
• Items listed in Test plans
• Actual migration process
• End results and expectations
• Assess the training requirements for the team
• Compile the education plan
• See earlier slides for “skills transfer” options
Currency of Versions

18
#IDUG
Project Plan – Technical considerations for the plan
• How did your V10 test plans work?
• Review & incorporate DB2 10 migration findings
• Reuse and improve upon your experiences
• Review the Installation Guide checklists:
• Premigration checklist for migration to DB2 Version 11 conversion mode
• Checklist for migration to DB2 Version 11 conversion mode
• Consider Single Version Charging when building your plan
• Incorporate discoveries from your analysis and known company events
• Many tasks should be moveable to a degree
• Consider parallel and “add on” side projects
• May cause pauses / expansions in the DB2 11 migration plan
• Overlay “freezes” based on your production schedules
• Review environments with multiple subsystems / members in each
• Don’t plan yourself into a corner
• Avoid close timeframes to holidays, major company events
• Always plan for the unknown
• PMRs
• Testing problems
• Data sharing requires both Conversion and Coexistence goals
• Check out the MPW Functional Inventory
MPW Functional
Inventory

19
#IDUG
Project Plan – Early elimination of Risks & Issues is key
• Early discussions to identify project risks
• Systems availability during project
• Workload availability
• People associated with the project team
• Ability to measure, and capture performance information
from current DB2 10 systems, for later comparison with
migrated DB2 11 systems
• Plan regular status meetings
• Update the Stakeholders
• Keep your IBM & ISV teams informed DB2 11 for
z/OS
Migration
Project Plan
on schedule

20
#IDUG
What’s an “MPW”?
DB2 11 Migration Planning Workshop
•The DB2 11 for z/OS Migration Planning Workshop Project Plan Framework
•Incorporate tasks into your Project Plan

21
#IDUG
Installation of
Code
Conversion
Mode
Enable New
Function Mode
New
Function Mode
Sandbox
Environment
Development
System Test/QA
Production
Break/Fix
Sandbox
DB2 11 Project Planning Framework Structure

22
#IDUG
DB2 11 Project Framework...
• Project orientation
• Initial planning
• Upgrade tools as needed
• Log readers (Replication) should
upgrade before DB2 due to 10 byte
RBA/LRSN
• Acquisition
• Includes updates notes
See the Task List for task details

23
#IDUG
DB2 11 Project Framework...
• Complete all Modes in Sandbox
• Develop routines to resolve
incompatible changes
• Test fallback & remigrate
• Initial tools / application testing
• New tasks for
• Migration SQLIDs
• APPLCOMPAT
• Extended RBA/LRSN
• And others ...
• Many Best Practices included

24
#IDUG
• Repeat the steps mastered in the
Sandbox environment, interacted
across environments
• Resolving incompatibilities
• Performance benchmark basis /
measurement
• Preparatory REORGs to find
potential incompatible threads in
ENFM
• Time spent in CM to determine
performance experience &
complete REBINDs
• RBA/LRSN considerations for each
landscape
DB2 11 Project Framework
Several
Notes
added /
updated

25
#IDUG
Sample ESP Customer Migration Test Plan - Early draft
Priority Testing planned Technical Description Timeframe
1 Check migration process of DB2 11 •Pre-migration check by catalog cloning
of prod systems
•Regression tests - baseline
Start March 2013
1 Check basic functions of customer
apps – Batch
•Run batch suite with wide variety of SQL
and utilities
Start April 2013
1 / 2 Improvements for customer appl.
Release changes
•Online Schema Evolution
•Plan stability
Start June 2013
2 Test key new DB2 11 functions •Extended RBA / LRSN
•Data Warehousing
•XML
Depends on success of above
(Priority 1) items
1 Check basic functions of customer
apps – Online
•Run IMS transactions
•Run WAS trans (type 2 / 4 connect)
•DDF support
Start May 2013
1 Tools support (IBM & ISV) DB2 11 CM mode Start March 2013
3 Tools support (IBM & ISV) DB2 11 NFM mode Start January 2014
1 Migrate to DB2 11 CM •Non-production environment Start March 2013
1 Migrate to DB2 11 NFM •Run IVPs Start June 2013
A summarized Migration Test Plan, ordered by test priority

26
#IDUG
Contact your software vendors
• Review your DB2 related software inventory
•Research ISV and in-house developed products
• Assess DB2 11 Requirements / Readiness of the software
• Contact your software vendors / developers
• Some software product vendors may add instructions for
migration and / or require maintenance
• Develop your project plans for testing / deployment of these
products
• It’s likely these products / applications are managed by other members of
your organisation
• Plan for early meetings and outline “your” DB2 11
timescales
• How did your V10 test plan / schedule work out?
• Reuse and improve upon your experiences

27
#IDUG
Technical Planning and
“Key Prerequisites”

28
#IDUG
Prerequisites – Hardware & Operating System
• Processor requirements:
• EC12, z196, z10 processors supporting z/Architecture
• Will probably require increased real storage for a workload
compared to DB2 10 for z/OS (for project planning consider up to 15%)
• Software requirements:
• z/OS V1.13 Base Services (5694-A01) at minimum
• DFSMS V1 R13 – DB2 Catalog is SMS managed
• Language Environment Base Services
• z/OS Version 1 Release 13 Security Server (RACF)
• IRLM Version 2 Release 3 (Shipped with DB2 11 for z/OS)
• z/OS Unicode Services and appropriate conversion definitions are required
• More to follow on subsequent slides

29
#IDUG
Additional planning for prerequisite products & installs
• IBM InfoSphere Data Replication (IIDR) 10.2.1
• Single offering for a wide variety of data replication
solutions:
• Change Data Capture, Q Replication
• SQL Replication, Data Event Publishing
• Supports extended RBA / LRSN
• IBM DB2 Tools Compatibility
• Tools may be “new” versions
• Maintenance to others
• Plan for the SMPE work

30
#IDUG
Prerequisites – DB2 Connect
• DB2 for z/OS V11 in all modes should operate with existing versions of DB2 Connect
in place, even back to DB2 Connect V8
• DB2 for z/OS Development will investigate any connectivity related issues with
existing applications using older versions of DB2 Connect and try to provide a fix
• If any issues cannot be resolved within the DB2 for z/OS server, DB2 Connect will
have to be upgraded to an in-service level to obtain a fix
• For continuous availability during the migration process the minimum recommended
level before leaving DB2 10 is V9.7 FP6 or V10.1 FP2
• This is the level that provides continuous availability for a given application
server as a customer goes from V10 NFM base -> V11 CM -> V11 NFM
• The minimum level for full DB2 11 for z/OS exploitation is currently V10.5 FP2
• Required for specific new function: array support for stored procedures, WLB
support with global variables, autocommit performance improvements,
improved client info
• This recommended level could and probably will change and go up over time as
we gain more customer experiences, roll through best practices, and provide
defect fixes into newer driver levels

31
#IDUG
Prerequisites – DB2 Connect ...
• Most DB2 for z/OS engine features in NFM are supported with any version of DB2
Connect
• DB2 for z/OS Development are being proactive in recommending customers to move
from the client or runtime client packages towards using the data server (ds) driver
instead
• For "evergreen" and/or new function the general upgrade path is the following:
1. DB2 for z/OS Server
2. DB2 Connect Server (if present – we are encouraging direct connect)
3. Drivers installed on application servers (push from client, runtime client -> ds
driver)
4. End user workstations (also push from client, runtime client -> ds driver)
• We do have customers that will push out the drivers first - those are generally driven
by the need for specific application enhancements e.g.,
• The most common example is in the .NET arena - wanting the latest tooling and
driver support in the MS arena

32
#IDUG
Preparing your DB2 10 NFM for Migration to DB2 11 CM
• Apply the Fallback SPE APAR, PM31841 (UK96357) and any
prerequisite fixes
• Your DB2 10 system MUST be at the proper service level
• See Info APAR  II14660
• See II14730 & II14732 for Client & DDF migration information
• Non-Data Sharing
• Current DB2 10 must be started with the SPE applied, or migration to DB2 11 will
terminate
• Data Sharing
• Before migrating a member to DB2 11, all other started DB2 10 members must
have the fallback SPE applied
• The fallback SPE must be on all active DB2 10 group members for DB2 11 to start
Important – Apply SPE to ALL Data Sharing
Members Before Starting Migration!

33
#IDUG
Info APAR II14660: DB2 10  11 MIGRATION/FALLBACK
• Check out FIX CATEGORIES:
• IBM.Migrate-Fallback.DB2.V11
• IBM.Coexistence.DB2.SYSPLEXDataSharing
• See more information on FIXCAT at External Site:
http://www-03.ibm.com/systems/z/os/zos/smpe/
fixcategory.html

34
#IDUG
DSNTIJPM (DSNTIJPB shipped with V10)
• Check / correct incompatibilities
• Very early running via the V10 DSNTIJPB pre-migration job (PM94057 / UK98219)
• Same as V11 DSNTIJPM
• N.B. Check maintenance for currency
• Identify pre-migration catalog cleanup requirements
• Maximise your prepare time by running it early and often
• See Info APAR II14660
• Check for issues before migration
• Take the cleanup actions recommended by the report headers
• Output could be DDL, Utility statements or verbage
• Some examples:
• DB2 10 SAMPLE DB must exist – for DB2 11 CM verification
• DB2 10 user-defined catalog indexes on DB2-managed storage
• DB2 10 plans/packages suitable for automatic BIND in DB2 11
• DB2 9 format EXPLAIN tables - deprecated
• Release Incompatibilities documented in:
• Installation Guide
• Application Programming and SQL Guide

35
#IDUG
DSNTIJPM / DSNTIJPB – Detailed breakdown...
1. Check for previous-release sample database
2. Catalog user defined indexes (user-managed
storage)
– Will need shadow data sets created
before DSNTIJEN
3. Catalog user defined indexes (DB2-managed
storage)
– Will be converted during DSNTIJEN.
Review space allocations
4. Plans last bound prior to V9
5. Packages last bound prior to V9
6. EXPLAIN tables prior to V10
7. Report eliminated
8. MQTs on the Catalog, drop before ENFM
9. AMI based DB2 MQSeries functions (dropped
by JRT)
10. AMI based DB2 XML MQSeries functions
(dropped by JRT)
11. Simple table spaces
12. Triggers with invalid SECTNOI. Recreate...
13. Views with a period specification must be
dropped
14. MQTs with a period specification must be
dropped
15. SQL Functions with a period specification
must be dropped
16. Catalog Table Spaces with a versioning
problem, requires MODIFY RECOVERY &
REORG before CM
17. Packages which will be invalidated by TIJEN
(ENFM) due to catalog changes
18. Orphaned SYSCOPY or SYSOBDS rows
created during V10 ENFM w/o PM41956. No
operational impact, but may impact
migrations.
19. Orphaned rows in SYSTABSTATS that could
impact migration
20. Orphaned rows in SYSCOLAUTH
21. Catalog Tables with inconsistent version
numbers. Contact IBM Service.
22. Plans invalidated in ENFM
23. Packages invalidated in CM (JTC)
24. Plans invalidated in CM
Check ALL output

36
#IDUG
Prerequisite Summary & Planning ...
• Data Sharing: CF Level 12, with 13 or 14 recommended
• GBP Enhancements require CFLEVEL 17 or higher
• z/OS 1.13 requires APARs OA40966 and OA37550
• More information about Coupling Facility (CF) levels
• Old plans and packages V9 or before -> REBIND
• Important to bind all Plans/Packages listed in output of pre-migration job DSNTIJPB
• Otherwise they will go through Autobind when first allocated in V11
• Identify early and rebind while on V10
• DROP Views, MQTs, and Table functions with Period Specification
• Those created in V10 are not supported
• Period Specification must be on base table
• Check programming language requirements – minimum levels etc
• Enterprise COBOL for z/OS V3.4 (5655-G53) or later
• VS Fortran 2.6 (5668-806, 5688-087, 5668-805).
• New data type and function are not supported since DB2 9.
• Enterprise PL/I for z/OS V3.9 (5655-H31)
• DSNHPC7 included in the base for older COBOL and PL/I
• See the Program Directory

37
#IDUG
Prerequisite Summary & Planning ...
• Configure a minimum of (IEASYSxx):
• 1TB of contiguous shared private per DB2 – HVSHARE
• Default is 510TB
• Article on HVSHARE
• 6GB of contiguous shared extended private per DB2 – HVCOMMON
• Same as DB2 10, with a default of 66GB
• Make sure HVCOMMON can accommodate log output buffer
• Configure additional 1MB LFAREA (z/OS parameter in IEASYSxx) for maximum
benefit.
•  Large Frame Area
• See z/OS APAR OA34024 for LFAREA Sizing information
• SMS managed catalog and directory
• Initially a requirement for DB2 10
• Data Class attributes of Extended Format & Extended Addressability
• DSNTIJSS provided as a sample for configuration
• PDSEs
• Required for SDSNLOAD, SDSNLOD2, ADSNLOAD, ADSNLOD2 - Same as V10

38
#IDUG
Deprecated in earlier releases – NOW Removed
• Password protection of Active / Archive Logs
• DSNH CLIST NEWFUN values of V8 and V9 - Use V10 or V11
• Some DB2 Supplied Routines no longer supported
• SYSPROC.DSNAEXP –> Use the EXPLAIN Privilege and issue EXPLAIN directly
• AMI-based DB2 MQ (DB2MQ) functions – Use MQI-based functions in schema DB2MQ
• (see APAR PK37290 for guidance and DSNTIJPB/DSNTIJPM report)
• DB2MQ1C.*, DB2MQ2C.*
• DB2MQ1N.*, DB2MQ2N.*
• DMQXML1C.*, DMQXML2C.*
• Sysplex Query Parallelism - Single member parallelism still supported
• BIND PACKAGE options ENABLE and DISABLE (REMOTE) REMOTE (location-
name,...,<luname>,...) -- specific names cannot be specified
• DSN1CHKR – Service aid no longer needed – No links in Catalog or Directory
• CHARSET application programming default value (KATAKANA) – use CCSIDs

39
#IDUG
Deprecated Feature / Function Summary
• EXPLAIN tables in a previous release format
• V9 & V10 format accepted
• Synonyms
• Should be using Aliases
• Simple Table Spaces remain deprecated
• Can not create Simple Table Spaces (since V9)
• See DSNTIJPB / PM for the existence of simple table spaces
• Should be converted to a different table space type
• NEWFUN SQL processing options and DECP values
• Processing options NEWFUN(YES) and NEWFUN(NO)
• Use NEWFUN(V11) instead of NEWFUN(YES). Use NEWFUN(V10)
instead of NEWFUN(NO)
• Check the Install Guide for ALL Deprecated Features
• Plus ALL New and Removed Parameters

40
#IDUG
Parameters Default & Maximum Changes
• Default
• DESCSTAT
• Is now the default for a new
BIND/REBIND PACKAGE...
DESCSTAT keyword when
there is no existing value
• REORG_PART_SORT_NPSI
• Changed from NO to AUTO
• Also added to DSNTIP62
• SUBQ_MIDX
• Changed from DISABLE to
ENABLE
• Maximum
• DSMAX
• From 100,000 to 200,000
• EDM_SKELETON_POOL
• From 2097152 to 4194304
(KB)
• EDMDBDC
• From 2097152 to 4194304
(KB)
• EDMSTMTC
• From 1048576 to 4194304
(KB)
• MAXKEEPD
• From 65535 to 204800

41
#IDUG
Other Performance Recommendations
• LRSN spin avoidance requires both BSDS and objects conversion
in NFM
• Monitor log I/O performance due to log record size increase
• 3% to 40% increase in log record size observed following BSDS conversion
• Essential to make sure enough zIIP capacity available before V11 CM
migration
• zIIP ‘Help Function” IIPHONORPRIORITY should be set to YES in case there is a
shortage of zIIP capacity
• Continue to monitor zIIP capacity thereafter
• Bufferpool re-classification change - prefetched pages will again
be reclassified as random after random getpage
• May need to re-evaluate VPSEQT setting for certain bufferpools
• MRU (Most Recently Used) used for pages brought in by utilities
• New FRAMESIZE parameter independent from PGFIX parameter

42
#IDUG
Early code
• If your DB2 10 system is at the prerequisite maintenance level,
your Version 10 early code is upward compatible with Version
11.
• The Version 11 early code is downward compatible with
Version 10.
• Activate the DB2 11 EARLY Code
• IPL or
• LLA,REFRESH & REFRESH,DB2 EARLY
•DB2 must be down, but an IPL can be avoided

43
#IDUG
Checking V10 data consistency / integrity
• DBD integrity for user data bases in Catalog & Directory
• REPAIR DBD TEST DATABASE dbname
• REPAIR DBD DIAGNOSE DATABASE dbname
• DB2 RI and table check constraint violations + consistency between base table
and corresponding LOB/XML table spaces
• CHECK DATATABLESPACE dbname.tsname part SCOPE ALL
• Consistency between table spaces and indexes
• CHECK INDEX ALL TABLESPACE or CHECK INDEX LIST (with appropriate LISTDEF)
• Invalid LOB values or structural problems with the pages in a LOB table space
• CHECK LOB TABLESPACE dbname.tsname for each LOB table space
• Integrity of the DB2 catalog
• IBM-provided DSNTESQ queries (should always return zero rows)
• Options to check each page of a table space for consistency
• DSN1COPY with CHECK option

44
#IDUG
DB2 11
ENFM*
DB2 11
ENFM
DB2 11
CM*
DB2 11
CM*
DB2 11
CM
DB2 10
for z/OS
NFM
DB2 10
for z/OS
NFM
DB2 11 for z/OS Migration Modes / NFM Decisions
DB2 11
for z/OS
NFM
ØFallback SPE applied
and incompatibilities
mitigated.
DSNTIJTC DSNTIJNFDSNTIJEN
DSNTIJEN
DSNTIJCS
DSNTIJNF
DSNTIJES
DSNTIJEN
DSNTIJCS
DSNTIJCS
DSNTIJNF
V10 Catalog V11 CM Catalog V11 Catalog V11 Catalog
APPLCOMPAT
Expanded
RBA/LRSN
Optional

45
#IDUG
Use the “Proactive” PMR process for Production
• Consider opening a proactive PMR when migrating in
Production to inform support.
• Use your normal support process to open a PMR
• Use the description to briefly describe what environment is being
migrated and to which mode
• Provide good contact information
• Several names and contact numbers
• Notifies IBM DB2 Support of your up coming migration activity
• It is typically routed to the DB2 Duty Manager on call for that time
• If the problem is serious, ask to be transferred to a Duty Manager
• If problems during the migration, open a new Sev 1 PMR / SR

46
#IDUG
Application Compatibility
“APPLCOMPAT”

47
#IDUG
APPLCOMPAT – Requirement & Solution
• Requirements
• De-couple the need for application program changes to deal with incompatible
SQL DML and XML changes from the actual DB2 system migration to the new
DB2 release which introduced the incompatible SQL DML and XML changes
• Provide a mechanism to identify application programs affected by incompatible
SQL DML and XML changes
• Provide a mechanism to introduce changes at an individual application program
(package) level
• Enable support so that application program changes can be phased in
over much longer time
• Enable support for mixed DB2 release co-existence in data sharing
• Enable support for up to two back level releases of DB2 (N-2)
• Solution
• APPLCOMPATwhich separates DB2 system migration to the new DB2 release
from application program migration to deal with incompatible SQL DML and
XML introduced by the new release

48
#IDUG
APPLCOMPAT – Solution summary
• APPLCOMPAT zparm provides default for BIND/REBIND
• V10R1 for DB2 10 SQL DML behaviour
• V11R1 for DB2 11 SQL DML behaviour
• Default is V11R1 for new installs, V10R1 for migration
• APPLCOMPAT option on BIND/REBIND to override zparm
default
• CURRENT APPLICATION COMPATIBILITY special register and
DSN_PROFILE_ATTRIBUTES for DDF
• For dynamic SQL
• Does not address issues with new reserved words or other incompatibilities
that could only be resolved by having multiple levels of the DB2 parser
• BIF_COMPATIBILITY=V9|V9_DECIMAL_VARCHAR is still honored in all
modes of V11 and is independent of APPLCOMPAT
• New SQL functionality available in V11 NFM cannot be used until package is
bound withy APPLCOMPAT value of V11 R1

49
#IDUG
APPLCOMPAT – Solution summary…
• Migration automatically sets V10R1 prior to NFM … otherwise
• DSNT225I -DSN BIND ERROR FOR PACKAGE location.collid.member
APPLCOMPAT(V11R1) OPTION IS NOT SUPPORTED
• IFCID376 – Summary of V10 function usage
• IFCID366 – Detail of V10 function usage, identifies packages
• We expect changes necessary to avoid V10R1 usage to happen after reaching NFM
• Workaround to distinguish packages which have to absolutely run as V10R1
until they are corrected
• Annotate the package using SQL COMMENT ON PACKAGE colid.name.”version” IS
‘V10R1’
• If version is a pre-compiler timestamp then the double quotes are
necessary
• Stored in the REMARKS column in SYSIBM.SYSPACKAGE table
• Can be queried and be exploited by housekeeping

50
#IDUG
APPLCOMPAT – What can I do at each mode?
• ZParm V10R1
• Can set to V11R1
but will not
operate that way
• BIND/REBIND
• Must be V10R1
• CREATE/ALTER
• Must be V10R1
• SET CAC* not
available
• IFCID
239/366/376
10 NFM 11 CM 11 ENFM 11 NFM
*CAC = CURRENT APPLICATION COMPATIBILITY
• ZParm
• V10R1 or V11R1
• BIND/REBIND
• V10R1/V11R1 available
• BIND
• Defaults to ZParm
• REBIND & Autobind
• Defaults to previous Catalog
value first
• ZParm second
• CREATE/ALTER
• V10R1 or V11R1
• SET CAC* available
• New features
• Require V11R1
• Same as CM

51
#IDUG
DB2 11 Enabling New
Function M ode
DB2 11 Catalog
Data Sharing
Coexistence
DB2 11 Conversion Mode
DB2 11 New Function Mode
(NFM)
CATMAINT UPDATE
(DSNTIJTC)
CATENFM COMPLETE
(DSNTIJNF)
CATENFM START
(DSNTIJEN)
DB2 10 Catalog
DB2 11 Libraries
DB2 10 Libraries
DB2 10 New Function
Mode
(NFM) With SPE
1 – 2 months
1 w eek
2 hours
Bind with APPLCOMPAT(V10R1) option only
Bind with APPLCOMPAT(V10R1) or
APPLCOMPAT(V11R1)
APPLCOMPAT: Migration DB2 10  DB2 11

52
#IDUG
Release incompatibilities

53
#IDUG
Release Incompatibilities Aren’t Just for DBAs
• Check and correct release inconsistencies and incompatibilities:
• Installation Guide
• Application Programming and SQL Guide
• Application and SQL release incompatibilities
• Including these important checks:
• New Reserved Words
• Changed Messages
• Changed SQLCODEs
• Utility release incompatibilities
• Command release incompatibilities
• Storage release incompatibilities
• Other release incompatibilities
Release incompatibilities can change over time. Ensure
that current documentation is reviewed when
constructing your plan.
•Reserved Words
•Changes in Functions
•Bind changes & minimum
package levels
•Database metadata stored
procedures
•Compiler levels and options
•Explain tables
•SQLSTATE changes

54
#IDUG
Suggestions for a “parallel”
testing strategy

55
#IDUG
Systems Programmer Environment (Sandbox)
DB2 10
NFM
DB2 11
CM
Migration
(Clone of Test
Environment)
DB2 11
CM
DB2 11
NFM.
A “suggested” Parallel Test Strategy – Part 1
• Migration and fallback testing is first priority
• Then clone / copy DB2 11 CM to a second DB2 11 CM that gets migrated to NFM
• Use of a cloning Tool may be useful
• This provides two targets (*) for problem re-creation and PTF testing during project
• One in DB2 11 CM, one in DB2 11 NFM
• Parallel testing environments in case of blockers
Clone
Fallback
*
*

56
#IDUG
DB2 11 Testing Environment
DB2 10
NFM
DB2 11
CM
Migration
DB2 11
NFM.
(Clone of Production
Environment)
Switch
DB2 11
CM
Regression
Testing
• DB2 10 NFM: Baseline for regression testing
• Migration testing: DB2 11 CM
• Regression testing in DB2 11 CM clone
• Before rebinds
• After rebinds
• Possible use of a workload
generation tool
• Regression testing in DB2 11 NFM
• New feature / function testing in DB2 11 NFM
Regression
Testing
and
New Function
Testing
Clone
DB2 11
ENFM
Regression
Baseline
Migration
Testing (IVPs)
•Create a CLONE of production
•Repeatable tests to guarantee base
functionalities covering:
•Business needs and jobs,
•Catalog health-checks
•Housekeeping like Utilities, DR- and
Recovery scenarios
•In each of the different phases:
•DB2 V10 NFM
•DB2 V11 CM
•DB2 V11 NFM with and without objects
in mixed mode (split of 6- and 10-byte
pagesets)
ESP Customer sample

57
#IDUG
Pre-migration Catalog Migration Testing
DB2 10
NFM
DB2 11
CM
Migration
Clone of non-Production
Environment (s):
Important Test / QA
Environmnent (s) with
production-like SLAs
• Verify CATMAINT (DSNTIJTC) and ENFM (DSNTIJEN) will work
• Flush out errors
• Learn how long each process takes
ENFM
Testing
DB2 11
ENFM
CATMAINT
Testing

58
#IDUG
Regression Test Planning

59
#IDUG
Regression Test Planning
• Establish key performance benchmarks
• Identify test suites - DB2 applications to focus on:
• Critical on-line, batch, query, utility workloads
• Processing peaks: month-end, quarter end, etc.
• Compare without using DB2 11 function explicitly
• What to compare?
• “Apples to apples” comparison of same workload
• Ideally a “Repeatable” workload
• If workload not repeatable, compare similar periods over several days
• Normalize CPU numbers across measured intervals, i.e. CPU milliseconds per commit
• Multiple test runs recommended to ensure realistic results
• No changes in application and schema
• V10 NFM as base line
• DB2 11 CM without REBIND
• DB2 11 CM after REBIND
• DB2 11 NFM
• What to measure?
• CPU usage in DB2 application
and DB2 address spaces
• Elapsed time
• Transaction rate
• DB2 virtual and real storage usage
• zIIP usage
RMF reports
Workload Activity
SMF
70-79,
100-102
Statistics class (1,3,4,5,6)
Accounting class (1,2,3,7,8)
•MSTR - TCB & SRB
•DBM1 - TCB, SRB & IIP SRB
•IRLM - TCB & SRB
•DIST - TCB & SRB & IIP SRB
Statistics trace
For each CONNTYPE:
•Class 2 CPU on CP and zIIP
•Number of occurrences:
•Getpages,
•Commits
•Rollbacks
Accounting

60
#IDUG
Performance Profile (Workload indicators)
• Performance profile comparison
• DML by type: SELECT, INSERT, UPDATE, FETCH, etc.
• Commits, Rollbacks, Getpages, Buffer updates
• Read and write activity (number of I/Os, number of pages)
• Watch for any changes in hardware, LPAR configurations, additional workload, or buffer pool
changes
• Save performance and access path information
• EXPLAIN output from DB2 10 NFM to compare with EXPLAIN in DB2 11
• Tooling
• Capture pre-migration baseline test scenarios
• Spread sheet input data generator for Statistics and Accounting
• Functional Regression
• Verify applications input and output between DB2 10 NFM and DB2 11 CM
• For performance critical business functions:
• Validate response times, elapsed times, throughput
• Investigate CPU performance regression
• Check for same pattern across releases based on combination of DB2 Statistics and
Accounting traces
• Validate no access path regression after migration, or due to application changes
concurrent with migration

61
#IDUG
Information capture – RMF, Accounting, Statistics, etc

62
#IDUG
Example of Customer Performance Testing Plan
• DB2 10 NFM baseline
• DB2 11 CM before REBIND
• Before REBIND in DB2 11
• Complete performance workload under DB2 10 NFM; document performance profile
• Complete performance workload under DB2 11; document performance profile
• Compare DB2 10 profile (#SQL, #GETPAGES, etc.) with DB2 11 profile
• DB2 11 CM after REBIND
• DB2 11 NFM (no need for further REBIND)
• DB2 11 NFM after REORG (to migrate object to extended LRSN)
• DB2 11 NFM Extended LRSN
REMEMBER - Performance expectations vary depending on many factors,
including:
•Access path selections, Read/Write rate, number of rows returned
•Number and type of columns returned, number of partitions touched
•Schema - Number of partitions defined, DPSI, etc
•RELEASE option on BIND, Table Compression

63
#IDUG
Performance Summary
• Make sure that the CPU numbers are
normalized across those intervals i.e., use
CPU milliseconds per commit
• Easy to combine statistics and
accounting by stacking the various
components of CPU resource
consumption:
• DB2 11:
• Opportunity for improved performance
for legacy application programs
• Your mileage will vary based on your
SQL application workload as certain
features only apply to certain workloads
• Immense CPU savings observed for
some workloads
• Highly optimized static SQL and/or
simple SQL may not see much benefit
• More benefit for more complex SQL i.e.,
not read a single row by primary key
• Do not sell (or buy) the savings before
you have seen them for your workload
MSTR TCB / (commits + rollbacks)
MSTR SRB / (commits + rollbacks)
DBM1 TCB / (commits + rollbacks)
DBM1 SRB / (commits + rollbacks)
DBM1 IIP SRB / (commits + rollbacks)
IRLM TCB / (commits + rollbacks)
IRLM SRB / (commits + rollbacks)
Average Class 2 CP CPU * occurrences / (commits + rollbacks)
Average Class 2 SE CPU * occurrences / (commits + rollbacks)

64
#IDUG
The Migration Process

65
#IDUG
DB2 11 migration process at a glance

66
#IDUG
Migration Process
• Final Preparations
• Customization / Tailoring
• Migration
• Before CM
• Migration to CM
• Fallback to V10
• Remigration to CM
• Conversion to ENFM
• Conversion to NFM
• Application Compatibility
• Extended RBA / LRSN
• Testing
Before Conversion Mode
Conversion Mode
CatalogVisualization
Enable New Function Mode
New Function Mode

67
#IDUG
Migration Preparations DSNTIJXZ ...
• Job to update the installation CLIST input (DSNTIDxx) to reflect
current:
• System parameters
• Buffer pool settings
DSNTXAZP
Existing
DSNTIDxx
SSID
Updated
DSNTIDxx

68
#IDUG
Migration: Pre-Conversion Mode ...
• Iterate Pre-CM / CM steps across landscapes before proceeding to ENFM
• There are exceptions, like Sandbox environments and purchased applications
• Check with your vendors
• Conduct the “final” review and preparation of your system for migration
• Project planning
• Prerequisites – System, Middleware, Tooling
• Making adjustments for release compatibilities
• Run the premigration queries
• Completed other premigration tasks
• Collected and saved (SMF) your V10 Performance Baselines?
• Saved critical access paths
• Review all migration steps ahead
• Meet with others that are needed to complete the tasks
• Understand requirements / concerns of others involved
BeforeConversionMode

69
#IDUG
Migration: Pre-Conversion Mode
• DSNTIJIN
• Defines application libraries – DB2 will define its own clusters for Catalog / Directory
• DSNTIJMV
• Updates PARMLIB & PROCLIB (5xDB2 subsys, 12xWLM, 10xlanguage support)
• In-house procedure management task
• Sets up USS files / paths
• DSNTIJUZ
• System Parameters
• DSNTIJEX
• Sample or user exit routines for Signon, Authorization, and Access
• If in use for V10
• V10 DSNTIJIC
• Backup the Catalog / Directory
• Restart DB2 (V10) in ACCESS(MAINT)
• While DB2 is down, optional full volume dumps for added backup
• Ensure that V10 is stopping clean
• DISPLAY Utilities, Threads, and Database / Spaces
• Clean up any potential problem conditions
• Optional ARCHIVE LOG before stopping V10
BeforeConversionMode

70
#IDUG
Migration: Conversion Mode ...
• Cycle DB2, restarting with V11 Procedures & Libraries
• Catalog level was reported as 111, but is now fixed at 101
• Expect several messages related to needing to run JTC
• DSNT501I & DSNL700I messages with 00C900A6
• Resource unavailable messages
ConversionMode

71
#IDUG
• DSNTIJTC
• Tailors the DB2 Catalog in a single unit of work
• In the case of failure, changes are rolled back
• Run this with DB2 in ACCESS(MAINT)
• Allow workload to flow to other members
ConversionMode
Online Migrations
- Data Sharing configuration
- Run in Coexistence (V10 & V11
members in the same group)
- Use ACCESS(MAINT) while running JTC
on first member to migrate
- Cycle one member at a time
- Online for application SQL access to
user data
- Not meant to run other utilities, DDL,
DCL, or commands
– 00C200EF would indicate the
SMS is not set up properly for
new spaces created
– See DSNTIJSS
– MODE(X) = Coexistence

72
#IDUG
• Initial checkout
• Update data set Aliases, Includes, and/or direct references to libraries
• Optional; consider Catalog verification steps
• DSNTIJCX – runs CHECK DATA and CHECK INDEX on all indexes in Catalog /
Directory
• Run DSNTESQ – with no SPUFI as yet, use V10 DSNTEP2 to run queries
• DSN1COPY utility with the CHECK option on the catalog table spaces
• DSNTIJTM
• Prepares DSNTIAD, binding DSNTIA11 package / plan
• Binds REXX Language support
• Creates additional Work Files (if requested via DSNTIP9) via DSNTWFG
• DSNTIJSG
• Prepares SPUFI, DCLGEN, SQL Utility, EXPLAIN tables
• If re-running uncomment the CLEANUP line
• Creates the Program Authorization Database & Extended Optimization Tables
• Existing DSNRLMTxx tables are used until NFM (expanded Client Info fields).
ConversionMode

73
#IDUG
• DSNTIJRW
• Sets up the WLM environments for DB2 Supplied Routines
• May not be needed for migration
• Check for recommended WLM changes
• Table of NUMTCB, authorization requirements
• DSNTIJRT
• Maintains the DB2 Supplied Routines and dependent objects
• Review the comments in this job
• If running the Administrative Schedule (ADMT), it will not run until JRT is completed in CM
• Job runs in INSTALL mode
• 3 modes available: INSTALL, REINSTALL, and REINITIALIZE
• Each of these also has a PREVIEW mode
• RC=0 does not mean that all routines are usable
• For JDBC / ODBC, see comments about possible need for remote bind
• XML Schema Repository (DSNXSR) is set to DROP RESTRICT
• Must be reversed if running in REINITIALIZE mode
ConversionMode

74
#IDUG
• DSNTIJRV
• Often ends with an RC=08
• Example: If the Administrative Scheduler is not set up, those stored procedures
fail verification
• Verify Views
• SQL documented in Migration Step 26
• DSNTIJIC (V11 CM Version)
• Recommended before ENFM
• 7 additional table spaces included in job
• SYSTSCPY replaces SYSCOPY
• SYSTSCKS, SYSTSCHX, SYSTSCKD, SYSTSSRG replace
DSNDB06.SYSSTR
ConversionMode

75
#IDUG
• Continue using V10 Dynamic programs (TEP2, TEP4, TIAUL, etc)
• Set up attachments
• See Migration Steps 6 , 7, and 8 for TSO, IMS, CICS, etc.
• Establish the Logon CLIST provided to others
• Checking on LE, WLM set up, etc.
• Coexistence considerations
• See the referenced documentation for considerations
• One example is for Utility execution from DB2 10 members
• Release-dependent load module (DSNUT101) and
• Utility-dependent load modules (DSNU10*)
• Need to be copied or concatenated in / with the V11 SDSNLOAD
ConversionMode

76
#IDUG
• REBIND Packages
• Re-enables xPROCs/zPROCs
• Enacts a number of performance advantages in the new release (out of the box
savings)
• Consider using Plan Management (if not already)
• Consider FREEing Original copies that may exist to establish new Package
baselines
• Consider using APCOMPARE or APREUSE if concerned about access path changes
• For Data Sharing, consider your ABIND ZParm and workload coexistence plans
• Activate your Regression Test plans and test, test, test
• Compare results to your Pre-CM benchmark collections
• Run Online REORGs against Catalog and Directory objects prior to the
ENFM/NFM migration
• Check data consistency of Catalog and Directory
• Improve the performance of the ENFM process
ConversionMode

77
#IDUG
Migration: Conversion Mode
• Fallback / Remigration test
• Become familiar with these steps in a Sandbox-like environment
• DSNTIJFV / modified DSNTIJMV
• Upgrade EXPLAIN / Optimization Tables
• See DSNTESC, DSNTESH for DDL
• DSNTIJXA for table migration assistance
• Does not create DSN_PREDICATE_SELECTIVITY, DSN_STAT_FEEDBACK, or
DSN_VIRTUAL_KEYTARGETS
• Administrative Scheduler
• If not established, this task and supporting Database could be configured at this time
• Maintenance
• If applying maintenance, make sure to review HOLDDATA for actions. E.g. REBINDs may be
required.
• CM ends the MLC SVC timing for this subsystem / member
• As long as a Fallback to V10 is not performed
• Structure your project plan to reach CM within 12 months to avoid dual version charging
• Specific customer terms and country consideration must be assessed
ConversionMode

78
#IDUG
Migration: CM Catalog Visualization ...
EXPANSION_REASONSYSPACKSTMT
DESCSTAT
EXTSEQNO
ARCHIVESENSITIVE
APPLCOMPAT
BUSTIMESENSITIVESYSPACKAGE /
SYSPACKCOPYPackages
DVERSION
BAUTHSYSDEPENDENCIESColumns
8 ColumnsSYSTSIXC*SYSINDEXCLEANUP*
RBA_FORMATSYSINDEXPARTIndexes
LASTDATACHANGE
UPDATESIZESYSTABLESPACESTATSReal Time Stats
PROGAUTHSYSPLANPlans
Added ColumnTable SpaceTable *NewCategory

79
#IDUG
SEQNAME
SEQSCHEMASYSSEQUENCESSequences
13 ColumnsSYSTSVAU*SYSVARIABLEAUTH*
3 ColumnsSYSTSVAD*SYSVARIABLES_DESC (LOB)*
3 ColumnsSYSTSVAT*SYSVARIABLES_TEXT (LOB)*
21 ColumnsSYSTSVAR*SYSVARIABLES*Variables
PCTFREE_UPD_CALC
PCTFREE_UPD
RBA_FORMATSYSTABLEPART
STATS_FEEDBACK
ARCHIVING_TABLE
ARCHIVING_SCHEMASYSTABLES
14 ColumnsSYSTSSFB*SYSSTATFEEDBACK*Entities

80
#IDUG
EXPANSION_REASONSYSQUERYPLAN
16 ColumnsSYSTSQRS*SYSQUERYSEL*
42 ColumnsSYSTSQRE*SYSQUERYPREDICATE*Access Path Repos.
3 ColumnsSYSTSOBX*SYSOBD_AUX (LOB)*
RELCREATED
OBD_IMAGE
ROWID
RBASYSOBDS
COLUMN_KEYWORD
PARTITION_KEYWORD
PARTITION
COLUMNSYSPENDINGDDLOnline Schema Evol.

81
#IDUG
ARRAYINDEXSUBTYPE
ARRAYINDEXTYPELEN
ARRAYINDEXTYPEID
ARRAYLENGTHSYSDATATYPES
MODECREATEDSYSCOPYOthers
SELECTIVITY_VALID
OPTION_OVERRIDE
ACCESSPATH_HINT
SELECTVTY_OVERRIDESYSQUERYAccess Path Repos.

82
#IDUG
DB2 11 CM Performance Enhancements
• DDF performance improvements
• xProcs above the bar
• zIIP enablement for all SRB-mode DB2 system agents that
are not response time critical
• Avoid cross-memory overhead for writing log records
• Data decompression performance improvement
• INSERT performance
• Sort performance improvements
• DPSI performance improvements for merge
• Performance improvements with large number of
partitions
• XML performance improvements
• Optimize RELEASE(DEALLOCATE) execution so that it is
consistently better performing than RELEASE(COMMIT)
• IFI 306 filtering capabilities to improve Replication
capture performance
• Utilities performance improvements
• Automatic index pseudo delete clean-up
• ODBC/JDBC Type 2 performance improvements
• Java stored procedures - Multi threaded JVMs
• ACCESS DATABASE command performance
• DGTT performance improvement
• P-procs for LIKE predicates against Unicode tables
• Improved performance for ROLLBACK TO SAVEPOINT
• zEC12 exploitation
• Latch contention reduction and other high n-way
scalability improvements
• Data sharing performance improvements
• Query transformation improvements – less expertise required to
write efficient SQL
• Enhanced query rewrite to improve predicate indexability
• Enhanced pruning of "always true" and "always false"
predicates
• Enhanced duplicate removal
• Lots of queries require duplicate removal: e.g. DISTINCT,
GROUP BY,etc.
• DPSI and page range performance improvements
• Optimizer CPU and I/O cost balancing improvements
• Most In-memory techniques
• Non correlated subquery with mismatched length
• Select list do-once
• Column processing improvements
• RID overflow to workfile handled for Data Manager set
functions
• Performance improvements for common operators
• DECFLOAT data type performance improvements
No REBIND needed
REBIND needed (with or without APREUSE)

83
#IDUG
Migration: Before proceeding to ENFM ...
• Complete the Installation CLIST ENFM panels and generate jobs
• DSNTIPT has a new field to display JDBC AND SQLJ DLLS
• ENFM & NFM conversion and reversion jobs
• DB2 11 IVP jobs
• Catalog RBA / LRSN expansion jobs
• Checkpoint with project stakeholders
• All testing should indicate no need for Fallback to V10
• Regression testing & CM REBINDs should be complete
• Review user defined catalog indexes
• Create shadow data sets for user defined Indexes on user managed storage
• Report 2 of JPM / JPB
• Review allocations for user defined Indexes on DB2 managed storage
• Report 3 of JPM / JPB
• For impacted user defined Indexes with additional pieces (A002 or higher)
• SQL in DSNTIJEN comments
• All active members of data sharing groups must be migrated to CM before
proceeding
EnableNewFunctionMode

84
#IDUG
• Review the UTILITY_OBJECT_CONVERSION setting
• EXTENDED or NOBASIC causes JEN to convert RBA/LRSN to 10 bytes
• Except SYSUTILX
• This setting require OBJECT_CREATE_FORMAT=EXTENDED
• Backup the Catalog and Directory (CM DSNTIJIC)
• Optionally create a volume level backup of the subsystem / group
• Consider MODIFY RECOVERY & RUNSTATS
• Run Online REORGs against Catalog and Directory objects prior to the ENFM/NFM
migration
• Check that REORG can break in
• Check data consistency of Catalog and Directory
• Improve the performance of the ENFM process
• Gain a rough idea of the duration of the REORG for the DSNTIJEN job
• Ensure SYSUTILX is empty
• Utilities recorded in SYSUTILX will cause DSNTIJEN to stop
• DB2 will no longer blindly re-initialize it
• Resets and reinitializes the SYSUTILX table space
Migration: Before proceeding to ENFM ...

85
#IDUG
Migration: Before proceeding to ENFM...
• This is a group wide event
• Table Spaces (Tables) involved:
• SYSUTILX (SYSUTILX, SYSUTIL)
• SYSLGRNX (SYSLGRNX)
• SYSCOPY (SYSCOPY)
• SYSRTSTS (SYSTABLESPACESTATS, SYSINDEXSPACESTATS)
• SYSTSIXS (SYSINDEXES)
• SYSTSTAB (SYSTABLES)
• SYSSTR (SYSCHECKDEP, SYSCHECKS, SYSCHECKS2, SYSSTRINGS)

86
#IDUG
Migration: Enable New Function Mode ...
• DSNTIJEN ...
• Converts to ENFM
• Do not attempt to modify this job
• Issues commands:
• Verifies that the Catalog is at the right level
• Checks for impacted objects in COPY or ICOPY status - DSNTIGCL
• Backs up any found in these statuses
• Avoid running other processes that modify the Catalog / Directory during JEN
execution
Online Migrations
- Online REORG is run against the
migrated objects
- Online for application SQL access
- Not for other utilities, DDL, DCL, or
commands

87
#IDUG
• DSNTIJEN ...
• Establishes metadata about DSNDB01 tables for serviceability SQL access
• Cleans up existing
• SYSDATABASE DBID=1
• SYSTABLESPACE DBID=1
• INSERTs metadata data for Database DSNDB01
• Table Space (Table)
• SYSLGRNX (SYSLGRNX)
• SYSUTILX (SYSUTILX, SYSUTIL)
• SCT02 (SCTR)
• SPT01 (SPTR)
• SYSSPUXA (SYSSPTSEC_DATA)*
• SYSSPUXB (SYSSPTSEC_EXPL)*
• DBD01 (DBDR)
• SYSDBDXA (SYSDBD_DATA)*
• Except for “*” items, Columns, Index, Keys, and Relationship metadata is also created

88
#IDUG
• DSNTIJEN ...
• Converts (CATENFM)
• SYSUTILX
• SYSUTIL
• Converts (CATENFM) & Online REORG ... CONVERTV11
• SHRLEVEL REFERENCE when a Table Space change is made
• SHRLEVEL CHANGE when Table Space remains the same
• SYSLGRNX SHRLEVEL CHANGE
• SYSCOPY SHRLEVEL REFERENCE
• SYSRTSTS SHRLEVEL REFERENCE
• SYSTSIXS SHRLEVEL CHANGE
• SYSTSTAB SHRLEVEL CHANGE
• SYSSTR SHRLEVEL REFERENCE
• Uses Automatic Mapping Table support
• Repeats DISPLAYs and TERM

89
#IDUG
DSNTIJEN – Output from final DISPLAY

90
#IDUG
• DSNTIJEN - Considerations
• DSNTIJNH can be used to halt this job (CATENFM HALTENFM)
• Multiple data sets for a page set may be consolidated
• Everything converted now uses 64GB Extended Format & Addressability
• In case of failure:
• Isolated to the Table Space being processed at that time
• Online REORG shadows will be thrown away
• Resolve the problem
• Do not attempt any recoveries
• Resubmit DSNTIJEN unaltered
• DB2 will operate with the Catalog / Directory in a partially converted state
• Make plans to complete the conversion as soon as practical
• Avoid other utilities on the Catalog / Directory during this time
• DSNTIJCI
• Checks indexes of the Catalog and Directory from the ENFM conversion
• CHECK INDEX(ALL)...on changed Catalog and Directory objects

91
#IDUG
Migration: Enable New Function Mode
• DSNTIJCS
• Reverts to CM*
• No Fallback available from this mode
• Return to ENFM (DSNTIJEN) before NFM
• DSNTIJIC (ENFM)
• Backup the converted Catalog / Directory
• Testing
• Application testing does not need to be repeated
• Light check out should be considered
• DB2 10 Libraries
• At this point, fallback is no longer an option
• Consider cleaning up any reference to V10 libraries to avoid future SVC issues
• Link List
• STEPLIBs
• Aliases
• Etc.
• Reestablish V10 IVP to test DB2 11 before NFM
• COBOL 5 will require modification program preparation PROCs generated by DSNTIJMV
• This is not a migration specific incompatibility
• SYSLMOD needs to be a PDSE
• May need additional SYSUTx and SYSMDECK DDs

92
#IDUG
Migration: ENFM Catalog / Dir Visualization
SYSTSTSS*SYSTABLESPACESTATS
SYSTSISS*SYSINDEXSPACESTATSReal Time Statistics
(STSRTSTS)
SYSSPUXBSYSSPTSEC_EXPLDirectory
SYSSPUXASYSSPTSEC_DATADirectory
SYSDBDXASYSDBD_DATADirectory
USURLSOX
Original Utility start LRSN
USURLSNX
Latest utility start LRSN
SYSUTILDirectory (SYSUTILX)
13 ColumnsSPT01*SPTR*Directory
3 ColumnsSCT02*SCTR*Directory
5 ColumnsDBD01*DBDR*Directory
(Orig Table Space)
Catalog/DirectoryVisualization

93
#IDUG
Migration: ENFM Catalog / Dir Visualization
SYSTSCPY*SYSCOPYCopy
(SYSCOPY)
SYSTSSRG*SYSSTRINGS
SYSTSCHX*SYSCHECKS2
SYSTSCKS*SYSCHECKS
SYSTSCKD*SYSCHECKDEPEntities (SYSSTR)
(Orig Table Space)

94
#IDUG
NewFunctionMode
Migration: New Function Mode ...
• Planning for NFM
• Consider converting to NFM with ENFM
• Pause for brief checkout, and proceed to NFM
• For non-Production environments
• May want to delay NFM to avoid development using new features that
cannot be promoted during this project timeframe
• Consider client behavior
• Drivers sometimes exhibit behavior changes when “seeing” that the
server is now NFM
• This is a group wide event
• Should reversion be necessary
• DSNTIJES will return to EN*
• DSNTIJCS will return to CM*
• Disabling SCA duplexing (DSNTIJNF reformats the SCA RBAs/LRSNs)

95
#IDUG
NewFunctionMode
Migration: New Function Mode ...
• DSNTIJNF
• Converts to NFM & Extends SCA LRSNs
• DB2 11 SQL capabilities are now enabled
• New functions are not available until Packages are rebound APPLCOMPAT V11R1
• While V10R1 (default), new SQL features return SQLCODE -4743
• Functions will retain V10 behavior until APPLCOMPAT is addressed
• Reverting
• DSNTIJCS will return to CM*
• Cannot fallback from CM*
• DSNTIJES will return to EN*
• DSNTIJNG
• Changed DSNHDECP NEWFUN to V11
• DSNTIJRT / JRV
• This job was generated during the MIGRATE execution of the panels
• Find it in the SDSNSAMP library from this generation
• For DB2 Supplied Routines / Objects that require NFM
• Ex. The MVS_CMD_OUTPUT CGTT

96
#IDUG
NewFunctionMode
Migration: New Function Mode
• DSNTIJNX
• REBINDs SPUFI and DSNREXX for
• APPLCOMPAT(V11R1)
• ARCHIVESENSITIVE(YES)
• BUSTIMESENSITIVE(YES)
• SYSTIMESENSITIVE(YES)
• Consider doing the same for client Packages
• Note these keywords must be explicitly stated or the REBIND can default to
the existing setting which will be V10R1
• DSNRLMTxx expanded Client Info fields
• ALTERs provided to modifies this table if it exists, or
• CREATE at this time to if needed
• Prepare V11 Dynamic Sample programs
• DSNTEJ2A
• DSNTEJ1L/P
• Make sure references to V10 programs is removed

97
#IDUG
NewFunctionMode
Migration: New Function Mode
• Consider the ZParm APPLCOMPAT setting
• Begin DB2 11 feature exploitation
• Probably want this left at V10R1 until majority of applications complete new
function testing
• Consider RBA / LRSN expansion
• DB2 11 IVP testing can be performed
• Consider the previous reviewed COBOL 5 change if appropriate
• Conduct a DB2 11 project review
• What worked well?
• What didn’t work well?
• Where there any surprises?
• Any new tests included for this migration?
• Document all items that can assist your next migration project

98
#IDUG
Migration Catalog / Directory Summary
• All new non-AUX create Table Spaces are PBGs
• MAXPARTITIONS 1
• DSSIZE 64G
• 108 Unicode; 7 EBCDIC; 1 ASCII
Ø TS Page Size Counts
– 4K = 76 -> 94
– 8K = 10
– 16K = 5 -> 6
– 32K = 4 -> 6

99
#IDUG
New Function Mode – Test Planning Actions
• Build detailed plan of new functions to test
• Rank the new features of DB2 11 (perhaps 1 – 5)
• Participation of systems, DBA and application teams to validate the plans, actual
new function testing and end results
• Contact vendors
• For product updates. E.g. tools support of new features
• Assess any risk
• Check information APAR in detail & Apply any required service
• Evaluate new parameters (ZPARM) etc
• System, database administration and application based
• Review Info APAR recommendations for new parameters
• Check inconsistencies and incompatibilities
• Run the DB2 11 IVP when in NFM
• Parallel testing environments in case of blockers
• Data consistency checking
• As executed in V10 before migration to V11 CM

100
#IDUG
A brief glimpse at the 10 byte
Extended RBA / LRSN

101
#IDUG
New
Optional Enhancements need NFM + DBA effort
• DSNTIJCB – Optional – Convert BSDS for extended 10-byte RBAs
• - STOP DB2 MODE(QUIESCE)
• DSNTIJCV – Optional – Convert Catalog and Directory table and
index spaces to extended 10-byte RBA format
• REORGs all Catalog and Directory table spaces SHRLEVEL CHANGE
• Can be split up to run REORGs in parallel

102
#IDUG
Extended LRBA/LRSN
• 6 byte format - LRBA/LRSN before DB2 11  x‘LLLLLLLLLLLL’
• 10 byte extended format– LRBA/LRSN has addressing capacity of 1 yottabyte
(2**80)
• 10 byte extended format - LRSN with DB2 11  x‘00LLLLLLLLLLLL000000’
• 10 byte extended format - LRBA with DB2 11  x‘00000000RRRRRRRRRRRR’
• Where do we find LRBA/LRSN?
• DB2 Catalog  SYSCOPY, SYSxxxxPART, …..
• DB2 Directory SYSUTILX, SYSLGRNX, ….
• BSDS  pointer, Active & Archive Log values..
• DB2 Logs Active & Archive logs
• DB2 Pagesets  Catalog & Directory and all user-pagesets
What you need to know for DB2 11 CM and DB2 10 NFM?

103
#IDUG
Extended LRBA/LRSN …
• DB2 11 CM
• DB2 internal coding deals with 10 byte extended format LRBA/LRSN values only
• LRSN in Utility output is shown in 10 byte extended format with precision
‘000000’ except
• QUIESCE utility, which externalizes LRSN in 10 byte extended format with
precision ‘nnnnnn’
• RECOVER utility handles 10 byte extended format LRBA/LRSN input
• Column ‘RBA_FORMAT’ in SYSIBM.SYSxxxPART is set to ‘B‘ for newly defined
objects, which are reorged or loaded with replace-option (possible values ‚B,
blank‚ U, E)
• DB2 11 CM / DB2 10 NFM coexistence in data sharing
• Full toleration of 10 byte extended format LRBA/LRSN value as input to the
RECOVER Utility
• Sanity checks included for ‘wrongly used 6 byte format LRBA/LRSN’
What you need to know for DB2 11 CM and DB2 10 NFM?

104
#IDUG
• Migration to DB2 11 NFM (via DSNTIJEN)
• Catalog & Directory Table ‘LRBA/LRSN Columns’ are altered to 10 byte
extended format
• SYSIBM.SYSLGRNX entries are now stored as 10 byte extended format LRBA/
LRSN values
• SYSIBM.SYSCOPY
• Conversion of all LRBA/LRSN values is done for existing data to 10 byte
extended format with leading byte ‘00’ and precision, ‘000000’ for LRSN and
right justified right with leading ‘00000000’ for LRBA values
• New data is stored in 10 byte extended format with precision ‘nnnnnn’
• LRBA/LRSN for all Utilities use now 10 byte extended format
• LRBA/LRSN values are still written to DB2 logs in 6 byte format
• LRBA/LRSN values are still written to DB2 pagesets in 6 byte format
What you need to know for DB2 11 NFM?

105
#IDUG
• BSDS converted to 10 byte extended format LRBA/LRSN in NFM only
(PGM=DSNJCNVT)
• There is no way back for BSDS!
• Now LRBA/LRSN values are written to DB2 logs of the subject DB2 member now
in 10 byte extended format with precision ‘nnnnnn’
• LRBA/LRSN values are still written to DB2 pagesets in 6 byte format
• Conversion (10 to 6 or 6 to 10 byte) has to be done
• LRSN Spin can still happen
• DSN1LOGP and REPORT RECOVER output will show 10 byte extended format
LRBA/LRSN although never externalized to pagesets (different output, for
DSN1PRNT of pagesets)
• Can be done, whenever you want to do it after entry to V11 NFM, regardless of
pageset formats

106
#IDUG
• Reorg Catalog and Directory pagesets to ‘extended format’ (in NFM only!)
• Can be done whenever you want to, regardless of BSDS and user pageset
formats
• Now LRBA/LRSN values are written to converted pagesets in 10 byte extended
format
• LRSN with precision ‘nnnnnn’, if update is done on a DB2 member with 10
byte extended format BSDS
• LRSN with precision ‘000000’, if update in done in a member with 6 byte
format BSDS
• Column ‘RBA_FORMAT’ in SYSIBM.SYSxxxPART is updated to ‘E’
• LRSN Spin could still happen for DB2 member with 6 byte format BSDS
• Can be converted back to 6 byte format (all or at part level)

107
#IDUG
• Reorg User pagesets to ‘extended format’ (in NFM only!)
• Can be done whenever you want to, regardless of BSDS, Catalog & Directory
pageset formats
• Now LRBA/LRSN values are written to converted pagesets in 10 byte extended
format
• LRSN with precision ‘nnnnnn‘, if update is done in a member with 10 byte
extended format BSDS
• LRSN with precision ‘000000‘, if update in done in a member with 6 byte
format BSDS
• Column ‘RBA_FORMAT’ in SYSIBM.SYSxxxPART is set to ‘E‘
• LRSN Spin could still happen for a DB2 member with 6 byte format BSDS
• Can be converted back to 6 byte (all or at part level)
• Is done by REORG, LOAD .. REPLACE or REBUILD with ‘RBALRSN_CONVERSION
EXTENDED’ or if zparm OBJECT_CONVERTED=EXTENDED
• ‘RECOVER ... TOCOPY ...’ using a 6 byte Copy can reset format back to ‘basic’

108
#IDUG
• Enhancements to improve usability characteristics based on 6
byte/10 byte format LRBA/LRSN handling
• Prevent DSNJCNVT from converting DB2 10 NFM BSDS to extended format
• Support 10 byte extended format input to RECOVER in DB2 10
• Perform sanity checks to guard against invalid LRSN values i.e., 6 byte LRSN
values with leading byte of zeros, to prevent PIT recoveries using bad RBA/LRSN
from failing (RC=8 in UTILINIT phase instead)
• Sanity check also performed in DB2 10 (coexistence)
• Support for ‘NOBASIC’ value for OBJECT_CONVERSION zparm to prevent
converting back pagesets in extended format , and to ‘EXTENDED’ as default if
‘NOBASIC’ is set and catalog column is <> ‘E’
• Add LRSN values to archive log information in REPORT RECOVERY utility output
• Technical white paper being produced explains about ‘6/10 byte LRBA/LRSN
handling’
• Several enhancements to DB2 11 books

109
#IDUG
• Recommended best practice migration strategy
1. Run pre-migration jobs and steps to clean-up
2. Migration to DB2 11 CM
3. Migration to DB2 11 NFM
4. Convert ALL BSDS of data sharing group within ‘n’ weekends
5. Reorg ALL Directory & Catalog Pagesets to ‘extended LRBA/LRSN format’
6. Set OBJECT_CREATE and UTILITY_CONVERSION zparms to EXTENDED
- New objects will be created in 10 byte extended format
- REORG, LOAD REPLACE and REBUILD will convert user objects to extended format
without need to change utility control statements
7. Reorg all objects to extended LRBA/LRSN format by executing normal reorg jobs
or some additional jobs
• Perform regular check for ongoing progress by selecting rows where RBA_FORMAT = ‘E’
in SYSIBM.SYSxxxxPART
8. If all done, set OBJECT _CONVERSION zparm to NOBASIC

110
#IDUG
Migration Summary
• Establish a Project / Test Plan
• Review new features / literature and
build training plans
• Run checks against V10 system
• Resolve / research inconsistencies and
release incompatible changes
• Complete any prerequisite projects
• Collect Performance Baselines
• Set Conversion & Coexistence goals
• Determine your Application
Compatibility / RBA Expansion plans
• Plan and run regression tests
• Execute your migration plans
• Keep your IBM team informed
DB2 11For z/OS

113
#IDUG
Ian Cook
DB2 for z/OS Specialist, zChampion
IBM Software Group
Ian_Cook@uk.ibm.com
Session 5
Planning and executing a DB2 11 for z/OS
Migration

Planning and executing a DB2 11 for z/OS Migration by Ian Cook

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Planning and executing a DB2 11 for z/OS Migration by Ian Cook (20)

Recently uploaded (20)

Planning and executing a DB2 11 for z/OS Migration by Ian Cook