DB2 10 Pure XML
DB2 10 Pure XML
Extremely pureXML
in DB2 10 for z/OS
Develop Java and COBOL applications
accessing XML and SQL data
Paolo Bruni
Neale Armstrong
Ravi Kumar
Kirsten Ann Larsen
Tink Tysor
Hao Zhang
[Link]/redbooks
International Technical Support Organization
January 2011
SG24-7915-00
Note: Before using this information and the product it supports, read the information in “Notices” on
page xvii.
This edition applies to Version 10.1 of IBM DB2 for z/OS (program number 5605-DB2).
Note: This book is based on a pre-GA version of a program and may not apply when the program becomes
generally available. Consult the program documentation or follow-on versions of this publication for more
current information.
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
The team who wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Importance of XML data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Growth of XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 The value of XML data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 XML introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 XML definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Document validity and well-formedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.4 Extensible Stylesheet Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.5 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.6 XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.7 XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.8 XSL, XSLT, Xpath, and XHTML examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 What is in this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Contents v
Chapter 10. XML-related tasks for the DBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
10.1 Tasks regarding system setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
10.1.1 Setting up the XSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
10.1.2 Buffer pool for XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
10.1.3 Sizing XMLVALA and XMLVALS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
10.1.4 Be up to date with maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
10.2 Tasks regarding object creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
10.2.1 Creation of table with XML columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
10.2.2 Alteration of implicitly created XML objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
10.2.3 Sizing table spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
10.2.4 Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
10.2.5 Registration of schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
10.2.6 Creation of XML indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
10.2.7 Grants and authorizations required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
10.3 Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
10.4 Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
10.5 Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
10.5.1 Identification of XML related objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
10.5.2 Investigating XML specific errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
10.5.3 Correcting XML data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Contents vii
viii Extremely pureXML in DB2 10 for z/OS
Figures
Examples xv
9-6 JCL for LISTDEF utility and output (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
9-7 JCL for LISTDEF utility and output (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
9-8 JCL for LISTDEF utility and output (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
9-9 LOAD utility JCL and output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
9-10 LOAD utility JCL (using file reference variable) and output . . . . . . . . . . . . . . . . . . . 201
9-11 LOAD utility JCL and output (input to load is in binary format) . . . . . . . . . . . . . . . . . 202
9-12 LOAD utility JCL and output (input to load is in spanned record format) . . . . . . . . . 204
9-13 MERGECOPY utility JCL and output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
9-14 QUIESCE utility JCL and output (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
9-15 QUIESCE utility JCL and output (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
9-16 REBUILD INDEX utility JCL and output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
9-17 RECOVER TABLESPACE utility JCL and output . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
9-18 RECOVER TABLESPACE utility JCL (and modified control statement) and output. 212
9-19 REORG TABLESPACE utility JCL and output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
9-20 REPORT utility JCL (and TABLESPACESET option) and output. . . . . . . . . . . . . . . 218
9-21 REPORT utility JCL (and RECOVERY option for base table space) and output . . . 219
9-22 REPORT utility JCL (and TRECOVERY option for XML table space) and output . . 220
9-23 RUNSTATS utility JCL and output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
9-24 UNLOAD utility JCL and output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
9-25 UNLOAD utility JCL (using file reference variable) and output . . . . . . . . . . . . . . . . . 225
9-26 UNLOAD utility JCL (to unload XML data in binary) and output . . . . . . . . . . . . . . . . 226
9-27 UNLOAD utility JCL (to unload XML data in spanned record format) and output . . . 227
9-28 DSNTIAUL with SQL parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
9-29 DSNTIAUL with LOBFILE parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
10-1 Creating a range-partitioned table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
10-2 Creating an XML index with compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
10-3 Create an XML index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
10-4 Display database command shows XML table space in AUXW . . . . . . . . . . . . . . . . 243
10-5 REPAIR LOCATE control statements for diagnosing XML inconsistencies . . . . . . . 244
10-6 Using REPAIR utility to clear ACHKP status on table space . . . . . . . . . . . . . . . . . . 245
11-1 A lean XML index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
11-2 A heavy XML index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
11-3 A “silly” XML index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
11-4 Explain for XMLEXISTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
11-5 Explain for XMLTABLE with XMLEXISTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
11-6 Explain for XMLTABLE with an XML predicate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
11-7 Explain for XMLQUERY with XMLEXISTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
11-8 The [Link] contents for auxiliary XML table space . . . . . . . . . . . 262
11-9 Reorganization of a table space with an XML table space . . . . . . . . . . . . . . . . . . . . 263
11-10 Multiple XMLQUERY calls replaced with a single XMLTABLE call. . . . . . . . . . . . . 264
11-11 Single select statement combining two xmlquery expressions . . . . . . . . . . . . . . . . 265
A-1 XML message received . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
A-2 XML message parts processed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® IMS™ RACF®
CICS® Informix® Rational®
DataPower® InfoSphere™ Redbooks®
DB2 Connect™ iSeries® Redpaper™
DB2® MVS™ Redbooks (logo) ®
Domino® Optim™ S/390®
DRDA® OS/390® System z®
ESCON® OS/400® VisualAge®
FICON® PR/SM™ WebSphere®
IBM® pureXML® z/OS®
Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Microsoft, Windows NT, Windows, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel
Corporation or its subsidiaries in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
The DB2® pureXML® feature offers sophisticated capabilities to store, process and manage
XML data in its native hierarchical format. By integrating XML data intact into a relational
database structure, users can take full advantage of DB2’s relational data management
features.
In this IBM® Redbooks® publication, we document the steps for the implementation of a
simple but meaningful XML application scenario. We have chosen to provide samples in
COBOL and Java™ language. The purpose is to provide an easy path to follow to integrate
the XML data type for the traditional DB2 for z/OS® user.
We also add considerations for the data administrator and suggest best practices for ease of
use and better performance.
Paolo Bruni is a DB2 Information Management Project Leader at the International Technical
Support Organization based in the Silicon Valley Lab. He has authored several IBM
Redbooks publications about DB2 for z/OS and related tools and has conducted workshops
and seminars worldwide. During Paolo’s many years with IBM, in development and in the
field, his work has been mostly related to database systems.
Neale Armstrong is a Consultant IT Specialist at IBM in the United Kingdom, responsible for
technical support for System z® Information Management products. He has 24 years of
experience in DB2 solutions on z/OS and distributed platforms. He holds a degree in Physics
from the University of Bristol. His areas of expertise include database federation, replication
and event publishing, for DB2, IMS™, and VSAM data sources, which can more generally be
referred to as “database plumbing.” He has co-authored three previous IBM Redbooks
publications.
Ravi Kumar is a Senior Instructor and Specialist for DB2 with IBM Software Group, Australia.
He has approximately 25 years of experience in DB2. He was on assignment at the
International Technical Support Organization, San Jose Center, as a Data Management
Specialist from 1994 to 1997. He has co-authored many IBM Redbooks publications including
DB2 UDB for z/OS Version 8 Everything You Ever Wanted to Know, ... and More, SG24-6079,
DB2 9 for z/OS Technical Overview, SG24-7330, and DB2 10 for z/OS Technical Overview,
SG24-7892. He is currently on virtual assignment as a Course Developer with the Education
Planning and Development team, Information Management, IBM Software Group, U.S.A.
Kirsten Ann Larsen is a Senior IT Specialist and Technical Lead with IT Delivery at IBM in
Denmark. She has 14 years of experience with DB2 for z/OS and has co-authored the IBM
Redbooks publication Securing DB2 and Implementing MLS on z/OS, SG24-6480. She holds
a Master’s degree in Computer Science from Aarhus University. She has worked with XML
since pureXML support was included with the release of DB2 9 in 2007 and has co-authored
a number of articles about XML.
Hao Zhang is a Software Engineer in the IBM China Software Development Lab. He has over
six years of experience in DB2 QA field. He participated in testing several DB2 pureXML
features in DB2 9 and DB2 10 for z/OS, and presented DB2 9 pureXML support to the
Chinese DB2 Users' Group (CDUG) in 2009. His areas of expertise include distributed area in
JCC driver, temporal table, and XML.
Rich Conway
Bob Haimowitz
Emma Jacobs
Diane Sherman
International Technical Support Organization
Mengchu Cai
Li Chen
Jason Cu
Thanh Dao
Eric Katayama
Andrew Lai
Susan Malaika
Gary Mazo
Roger Miller
Jinfeng Ni
Matthias Nicola
Bryan Patterson
Tom Ross
Guogen Zhang
IBM Silicon Valley Lab
Heidi Arnold
IBM Boeblingen
Michael Schwartzbach
Aarhus University
Rick Butler
BMO Toronto
Lee Ackerman
IBM Ottawa
Nagesh Subrahmanyam
IBM India
Find out more about the residency program, browse the residency index, and apply online at:
[Link]/redbooks/[Link]
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about this book or
other IBM Redbooks publications in one of the following ways:
Use the online Contact us review Redbooks form found at:
[Link]/redbooks
Send your comments in an email to:
redbooks@[Link]
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Preface xxi
xxii Extremely pureXML in DB2 10 for z/OS
1
Chapter 1. Introduction
This chapter provides an introduction to XML technology, its importance in the IT business,
and the contents of the book.
These standards facilitate purposes such as the exchange of information between the various
players within these industries and their value-chain members, data definitions for ongoing
operations, and document specifications. More companies are adopting such XML standards
or are being compelled to adopt them to be able to stay competitive, improve efficiencies,
communicate with their trading partners or suppliers, or simply to perform daily tasks.
XML
Service Service
Requestor Provider
Content for these feeds is rendered as XML files and can contain links, summaries, full
articles, and even attached multimedia files such as podcasts. Syndication and web feeds are
transforming the web as we know it. New business models are emerging around these
technologies. As a consequence, XML data now exists not only in companies that adopt XML
industry standards, or enterprises that implement SOAs, but also on virtually every
web-connected desktop.
The growth and pervasiveness of XML assets presents challenges and opportunities for
companies. When XML data is harnessed, and the value of the information it contains is
unlocked, it can translate into opportunities for organizations to streamline operations, derive
insight, and become agile.
However, as XML data becomes more critical to the operations of an enterprise, it presents
challenges in that XML data must be secured, maintained, searched, and shared. Depending
on its use, XML data might also have to be updated, audited, and integrated with traditional
data. All these tasks must be done with the reliability, availability, and scalability afforded to
traditional data assets.
That is, to unleash the potential of XML data requires storage and management services
similar to what enterprise-class relational database management systems such as DB2 have
been providing for relational data.
Chapter 1. Introduction 3
1.2 XML introduction
This brief introduction to Extensible Markup Language (XML) is extracted from XML on z/OS
and OS/390: Introduction to a Service-Oriented Architecture, SG24-6826.
The idea of universal data formats is not new. Programmers have been trying to find ways to
exchange information between various computer programs for a long time. Standard
Generalized Markup Language (SGML) was developed to achieve this. SGML can be used to
mark up data, that is, to add metadata in a way that allows data to be self-describing. SGML
is meta-language.
The markup process involves using tags to identify pieces of information in a document. Tags
are names (strings of characters) surrounded by angle brackets (< and >). Every piece of
data that is encoded has a start tag and an end tag, for example, <town> patiya</town>. The
start and end tags help software to process the encoded information, because it clearly
delineates where certain pieces of information start and where they end.
SGML does not prescribe any particular markup; instead, it defines how any markup
language can be formally specified.
The most popular SGML application is Hypertext Markup Language (HTML), the markup
language that rules the web. The HTML specification is owned by World Wide Web
Consortium (W3C). However, various browser vendors introduced a number of incompatible
tags to HTML, which are outside the scope of the original HTML specifications. These tags
create problems for developers when they author web pages because the developers must
consider what browser will display the pages. Although HTML has been very successful for
displaying information on browsers, it was not found to be useful in describing the data that it
represents, meaning it did not have the metadata capability that is essential for a
self-describing data document.
Furthermore, SGML is quite inefficient and cumbersome when it is used to encode complex
data structure. As a result, a need arose to develop a more lightweight markup language, so
W3C developed the specification for XML. XML is similar to SGML in that it preserves the
notion of general markup. There are very few optional features, and most SGML features that
were deemed difficult to implement have been dropped.
A client, for example, could use a web browser to fill out a form, entering the names of the
employees to add or delete. The data could then be sent to a web application that could
process the XML document and extract the data, generating the necessary updates, for
example, on a DB2 table.
As this example illustrates, the rules are very few: each tag must have an enclosing tag, and
not much more. The tags are invented tags, which means that they are free-form.
Text is system-independent, and because XML is very flexible and is based only on text, it is
used as the main way to transport data between various environments.
Often, XML documents are automatically generated by tools, and in many situations we need
these XML documents to follow rules we create. We use other documents, containing XML
data definitions in which we specify our restrictions, to accomplish this.
Document type definition (DTD) is a set of markup declarations that define a document type
for SGML-family markup languages (SGML, XML, HTML). DTD is described in “Document
type definition” on page 7.
XML Schema1 is another rules language that aims to provide more complex semantic rules. It
also introduces new semantic capabilities, such as support for namespaces and
type-checking within an XML document. XML Schema is described in 1.2.3, “XML Schema”
on page 9.
Chapter 1. Introduction 5
Schema languages typically constrain the set of elements that may be used in a document,
which attributes may be applied to them, the order in which they may appear, and the
allowable parent/child relationships
XSD schema, often referred to as XML Schema, is a newer schema language, successor to
DTD language. XSD documents are far more powerful than DTDs in describing XML
languages. They use a rich data typing system and allow for more detailed constraints on an
XML document's logical structure. XSDs also use an XML-based format, which enables the
possibility of using ordinary XML tools to help process them. This approach has become the
more popular one to working with XSD.
With few exceptions, every DTD can be converted to an equivalent XML Schema.
A document might be well-formed but still not be valid. The following examples illustrate the
difference between well-formedness and validity:
Documents that adhere to rules described in the associated DTD or XSD are valid.
Documents that carry out the syntactical rules for XML documents are well-formed. These
rules have to do with attribute names, which must be unique within an element, and
attribute values, which must not contain the character open angle bracket (<), and so on.
The document shown in Example 1-3 is well-formed, but it is not valid according to the
sample DTD shown in Example 1-2 because the <NOM> tag is not defined in the associated
DTD (tags are case-sensitive).
The DTD can either be stored in a separate file or be embedded within the same XML file. If it
is stored in a separate file it may be shared with other documents.
An XML document is not required to have a DTD. DTDs provide parsers with clear
instructions on what to check for when they are determining the validity of an XML document.
DTDs or other mechanisms, like XML schemas, contribute to the goal of ensuring that the
application can easily determine whether the XML document adheres to a given set of rules,
beyond the well-formedness rules defined in the XML standard.
Because of the non-hierarchical nature of DTD specifications, a lack of clarity exists about
what the comments are meant to explain.
A DTD uses syntax that is differs substantially from XML, so it cannot be processed with a
standard XML parser. That means you cannot read a DTD into an XML Document Object
Model (DOM)2. For example, you cannot modify it, and then write it back out again.
Namespaces
Before talking about XML Schema, we must first clarify the concept of namespaces.
Namespaces are used when there is a need to have separate elements with different
attributes but with the same name. Depending on the context, a tag is related to an element or
to another tag. Example 1-5 on page 8 illustrates this situation.
2
DOM is a programming interface for HTML and XML documents; it defines the way a document can be accessed
and manipulated.
Chapter 1. Introduction 7
Example 1-5 The need for namespaces
<widget type="gadget">
<head size="medium"/>
<info>
<head>
<title>Description of gadget</title>
</head>
<body>
<h1>Gadget</h1>
</body>
</info>
</widget>
Obviously, there is a problem with the meaning of <head> tag. It depends on the context. This
situation complicates matters for processors and might even cause ambiguities. We need a
mechanism to distinguish between the two <head> tags, and apply the correct semantic
description to the correct tag. The root of the problem is one common element or attribute
name.
A simple solution to the problem is the use of namespaces. Namespaces are a simple and
straightforward way to distinguish names that are used in XML documents. If you can specify
the related DTD when an element is being validated, the problem is solved.
As you can see in Example 1-6, the <title> tag is used twice, but in a different context: once
within the <author> element and once within the <book> element. Note the use of the xmlns
keyword in the namespace declaration, one for authr, one for bk. What is interesting is that
the XML recommendation does not specify whether a namespace declaration should point to
a valid Uniform Resource Identifier (URI), only that it should be unique and persistent.
After a prefix is applied to an element name, it applies to all descendants of that element
unless it is overridden by another prefix. The extent to which a namespace prefix applies to
elements in a document is defined as the namespace scope.
Chapter 1. Introduction 9
The main advantages of XML Schemas over DTDs are as follows:
Schemas use XML syntax.
It is possible to specify data types.
Schemas are extensible.
Because the XML Schema is a language, several choices are available to build a possible
schema that covers the XML document. Example 1-9 on page 11 is a possible and simple
design.
Example 1-9 clearly is an XML document because it begins with the XML document
declaration. The schema element opens our schema that is holding the definition of the target
namespace. Then, we define an element named book, which is the root element in the XML
document. We determine it is a complex type because it has attributes and non-text children.
With sequence, we begin to declare the children elements of the root element book. W3C XML
Schema lets us define the type of data, and also the number of possible occurrences of an
element. For more information about possible values for these types, see the specification
documents from W3C.
W3C XML Schema allows us to define data types and use these types to define our attributes
and elements. It also allows the definition of groups of elements and attributes. In addition,
there are several ways to arrange relationships between elements.
Documentation for XML Schemas can be defined by the xs:documentation element, and
processing instructions for applications can be included with the xs:appinfo element.
As of August 2009, XSD 1.1 is a Candidate Recommendation with significant new features as
defined at the following web addresses:
[Link]
[Link]
Chapter 1. Introduction 11
1.2.4 Extensible Stylesheet Language
In previous sections, we covered XML, its syntax, how XML is used to mark up information
according to our own vocabularies, how a program can check the validity of an XML
document, and so forth. We described how XML can ensure that an application running on
any particular platform receives valid data. This way is how we ensure that a program is able
to process this data.
However, because XML describes only document syntax, the program does not know how to
format this data without specific instructions about style.
The solution is XSL transformations. The Extensible Stylesheet Language (XSL) specification
describes powerful tools to accomplish the required transformation of XML data. XSL consists
of the following items:
The XSL Transformations (XSLT) language for transformation
Formatting Objects (FO), a vocabulary for describing the layout of documents
XML Path Language (XPath), which XSLT uses as a separate specification that describes
a means of addressing XML documents and defining simple queries.
XSLT offers a powerful means of transforming XML documents into other forms, producing
XML, HTML, and other formats. It is capable of sorting, selecting, numbering, and has many
other features for transforming XML. It operates by reading a style sheet, which consists of
one or more templates, then matching the templates as it visits the nodes of the XML
document. The templates can be based on names and patterns.
XSLT is increasingly being used to transform XML data into another form, sometimes different
XML (for example, filtering out certain data, SQL statements, plain text, and so on), or any
other format. Thus, any XML document may be shown in various formats, such as HTML,
PDF, RTF, VRML, Postscript, and so forth.
The question is how to access and display the information contained in an XML file. After all,
data is useless unless you can use it. This is where XSLT comes into the picture.
A comparison can be made between the relationship of Cascading Style Sheets (CSS)3 and
HTML and the relationship of XSLT and XML. Indeed, XSLT is usually referred to as the
stylesheet language of XML; however XML and XSLT are far more sophisticated technologies
than HTML and CSS.
Figure 1-2 on page 13 shows the source tree from the XML document shown in
Example 1-10 on page 15.
3
CSS is a mechanism for adding style (such as fonts, colors, spacing) to web documents; see
[Link]
The result tree after an XSL transformation can be an XHTML document, as shown in
Figure 1-3.
XHTML
HEAD BODY
title P
book
title
copies
Based on how we instruct the XSLT processor to access the source of the data being
transformed, the processor will incrementally build the result by adding the filled-in templates.
We write our stylesheets, or transformation specifications, primarily with declarative
constructs, although we can employ procedural techniques if and when needed. We assert
the desired behavior of the XSLT processor, based on conditions that are in our source.
Note: XSLT manipulates only the source tree; the original XML document is unchanged.
The most important aspect of XSLT is that it allows you to perform extremely complex
manipulations on the selected tree nodes by affecting both content and appearance. The final
output might bear absolutely no resemblance to the source document. This ability to
manipulate the nodes is where XSLT far surpasses CSS.
The W3C set the recommended standards for XSLT Version 1.0. The W3C proposed
recommendation for XSL is available at the following address:
[Link]
Chapter 1. Introduction 13
1.2.5 XPath
XPath is a string syntax for building addresses to the information found in an XML document.
We use this language to specify the locations of document structures or data found in an XML
document when processing that information using XSLT. XPath allows us from any location to
address any other location or content. That is, XPath is a tool used in XSLT to select certain
information to be formatted.
XPath 2.0 is the current version of the language. A number of implementations exist but are
not as widely used as XPath 1.0. The XPath 2.0 language specification changes several
fundamental concepts of the language such as the type system.
XPath expressions are usually built from patterns, which describe a branch of an XML tree. A
pattern, therefore, is used to reference one or more hierarchical nodes in a document tree.
The XPath patterns that are listed in Table 1-1 are several examples to give you an idea what
kinds of items can be selected.
// Separator of steps. It refers to any descendant in the node. By default of axisa, in the
next step, it refers to a child.
The basic syntactic construct in XPath is the expression (Example 1-10 on page 15). An
object is obtained by evaluating an expression, which has one of the following four basic
types:
Node-set (an unordered collection of nodes without duplicates)
Boolean
Number
String
This example selects all book elements beyond library element, but only if the title element
matches with good story.
1.2.6 XQuery
XQuery is a functional language that extends XPath. Its basic building blocks are expressions
that are constructed from keywords, operators (symbols), and operands (which are usually
other expressions). Expressions can be nested with full generality. An XQuery query is
composed of a prologue and a body. The query prologue is optional and consists of
declarations that define the execution environment of the query. The query body consists of
an expression that provides the result of the query. The input and the output of the query are
values (instances) of the XQuery 1.0 and XPath 2.0 Data Model (XDM)4.
4
The term XDM instance is used, like the term value, to denote an unconstrained sequence of nodes or atomic
values in the data model.
Chapter 1. Introduction 15
Example 1-11 shows a typical XQuery query. An XQuery query is made up of a prolog and a
body. The XQuery prolog is a series of declarations and definitions that together create the
required environment for query processing. This XQuery prolog includes a namespace
declaration. The XQuery body consists of expressions that specify the intended query result.
1.2.7 XHTML
The history of XHTML is very simple: It is derived directly from HTML version 4.01 and is
designed to be used with XML. XHTML is part of a whole new suite of “X” technologies, with
acronyms such as XML, XPATH, XSL, and XSLT, that are destined to have a profound effect
on the Internet.
People often think XML is an extension of HTML, but XHTML is the real extension of HTML.
Several fundamental differences exist between HTML and XHTML that significantly affect
how you code with XHTML. HTML is a loose and forgiving language; XHTML demands firm
adherence to the rules of grammar.
Fortunately, the syntax and coding rules are very straightforward, easy to implement, and
they make sense. The real purpose of these rules is to allow a seamless integration of
XHTML with XML and other related X technologies. The rules are summarized as follows:
All attributes, events, and tags must be written in lower case.
All elements must be closed.
The value assigned to an attribute must be enclosed in quotes.
No attribute may be minimized.
All elements must be properly nested.
XHTML documents must be well-formed.
A DOCTYPE declaration must exist.
This last rule implies that there must be a DTD to validate the XHTML document. HTML has
become an XML document.
XLink
XML Linking Language (XLink) is a powerful and compact specification for the use of links in
XML documents.
Every developer is familiar with the linking capabilities of the web today. However, as the use
of XML grows, we quickly realize that simple tags similar to those in Example 1-15 are not
going to be enough in the near future.
XLink allows elements to be inserted into XML documents to create and describe links
between resources. It uses XML syntax to create structures that can describe links similar to
the simple unidirectional hyperlinks of today's HTML, and also more sophisticated links.
XLink provides a framework for creating both basic unidirectional links and more complex
linking structures. It allows XML documents to perform the following tasks:
Assert linking relationships among more than two resources.
Associate metadata with a link.
Express links that reside in a location separate from the linked resources.
Although XLink has not been implemented in any of the major commercial browsers yet, its
impact will be crucial for the XML applications of the near future. Its extensible and
easy-to-learn design can be an advantage as the new generation of XML applications
develop.
For more information about Xlink, see the specification document from W3C:
[Link]
Chapter 1. Introduction 17
XPointer
XML Pointer Language (XPointer) specifies a language that builds upon the XPath, to support
addressing into the internal structures of XML documents. In particular, it provides for specific
references to elements, character strings, selections, and other parts of XML documents
(whether or not they bear an explicit ID attribute) by using traversals of a document’s structure
and choice of parts based on their properties, such as element types, attribute values,
character content, and relative position, containment, and order. Xpointer defines the
meaning of the “selector” or “fragment identifier” portion of URIs that locate resources of
text/xml and application/xml MIME media types.
In XPointer, you define the addressing expression to link XML documents using XPath. For
more information about XPointer, see the specification documents from W3C:
[Link]
Consider the XML file shown in Example 1-16. It is a simple file that we use as the source of
information for our XSLT transformation.
Note that the stylesheet association processing instruction in line two refers to a stylesheet
with the name [Link] of type XSL. Recall that an XSLT processor is not obliged to respect
the stylesheet association preference, so we first use a standalone XSLT processor with the
stylesheet [Link], shown in Example 1-17.
This file looks like a simple XHTML file, an XML file that uses the HTML vocabulary. Although
it is simply that, we are allowed to inject into the instance the XSLT instructions by using the
prefix for the XSLT vocabulary that is declared in line three. We can use any XML file as an
XSLT stylesheet, if it declares the XSLT vocabulary within and indicates the version of XSLT
being used. Any prefix can be used for XSLT instructions, although convention often sees
XSL: as the prefix value.
The xsl:value-of instruction uses an XPath expression in the select= attribute to calculate a
string value from our source information. XPath views the source hierarchy using parent/child
relationships. The XSLT processor’s initial focus is the root of the document, which is
considered the parent of the document element. Our XPath expression value "greeting"
We invoke the XSLT processor to point to which is the XML source file, which is the XSL
stylesheet, and where to leave the result. Example 1-18 shows the result file.
This is an HTML file; any browser can interpret it as shown in Figure 1-4.
Chapter 1. Introduction 19
Chapter 5, “Validating XML data” on page 75 introduces the need for validating documents
and the techniques to do so.
Chapter 6, “DB2 SQL/XML programming” on page 89 gives the basis on SQL/XML
programming.
Application development
We document the steps for the implementation of a simple but meaningful XML application
scenario. We provide samples in COBOL and Java language. The purpose is to provide
an easy path to follow to integrate the XML data type for the traditional COBOL and DB2
user or the more innovative Java developer.
Chapter 7, “Using XML with Java” on page 131 describes the Java implementation.
Chapter 8, “Using XML with COBOL” on page 157 describes the COBOL implementation.
Database administration
We also add considerations for the data administrator and suggest best practices for ease
of use and better performance.
Chapter 9, “Utilities with XML” on page 183 revisits most of the DB2 utilities when they are
used for XML data type.
Chapter 10, “XML-related tasks for the DBA” on page 233 highlights differences in
administering XML data.
Chapter 11, “Performance considerations” on page 247 provides a checklist of the major
performance considerations when deploying an application that uses pureXML.
We also summarize the XML infrastructure within DB2 that is required to support these XML
capabilities. Most of the XML function is available for immediate use after a standard DB2 10
for z/OS installation, however several facilities (such as XML schema validation) require that
optional parts of the installation process are completed. We clarify these optional steps.
If you want a brief introduction to DB2 pureXML without excessive technical detail, read this
chapter. This chapter also acts as a start for users who want to understand the technical
details of pureXML, which are covered in more detail in subsequent chapters.
The “native” support for XML is what makes DB2 pureXML so powerful. The reason is
because XML documents and schemas can be used within DB2 with minimal administration
work, as we show within the application scenario that is used in this book.
Several main capabilities that are provided by DB2 pureXML are as follows:
A native XML data type
SQL/XML language, providing XML functions within the SQL language to access XML
structures with the full power of XPath expressions
Hybrid data access, whereby relational and XML structures can be accessed together
using a single SQL/XML statement
Read and write access to XML documents and sub-documents
XML Indexes (based on XPath expressions) to provide efficient access paths
XML schema validation (against an XML schema registered in the Schema Repository)
including support for multiple versions of XML schemas
Collectively with these capabilities, you may use DB2 as a repository for both relational and
XML data structures. Starting with version 9, DB2 for z/OS is a hybrid database. You can
store both kinds of structures in a single database, write applications that use both kinds of
structures concurrently, and manage all your data with the same set of database
administration utilities.
The XML model of data is significantly different from the relational model of data. Java and
JDBC provide many powerful XML manipulation capabilities.
COBOL and PL/I have also added many XML manipulation capabilities, as described at the
following addresses:
[Link]
[Link]
The range of these XML capabilities that are provided by DB2 helps to easily incorporate
XML data into all DB2 databases and applications, including those written in languages like
COBOL and PL/I.
This section reviews the major XML capabilities of DB2, and explains why each of these
capabilities is important for building DB2 applications that contain XML data.
Given the proliferation of XML within modern systems, a database must be able to store XML
documents efficiently, and support efficient data access to any data element within the XML
documents (with all the other qualities of services that a database must provide).
Several vendors have provided XML-only databases for native XML repository and search
engine. Other relational database vendors have provided ways of storing XML documents,
and “stripping” out important data elements into relational structures (such as DB2 V7 and V8
did).
The XML data type is part of the ANSI SQL standard. DB2 implements this standard, and
additionally provides constructs such as XML indexes to make it productive and performant.
What DB2 pureXML provides is the combination of native XML data support with its
established relational data support, in a fully integrated way. The XML data type (first
introduced in DB2 9) is the most fundamental component of DB2’s support for XML. It is
different from storing XML as a string data type (as was done in DB2 V7 and V8).
The first approach is not practically viable from a performance or CPU-cost perspective. XML
parsing is a CPU-intensive activity that you do not want to incur each time you access the
XML data.
The second approach is practical, but is unproductive. This approach requires a significant
development project to be undertaken to prepare the DB2 database before you can start to
develop the application that will use the XML data.
XML documents are placed inside DB2 by inserting them into a column that has been defined
with the XML data type, as illustrated in Example 2-1.
The next sections describe how XML data can be processed after it is inside a DB2 table,
stored in a column of the XML data type.
Although standard SQL is able to access tables with XML columns, it does not have the direct
manipulation capabilities to do anything meaningful with the XML structure within the
retrieved XML document. For this reason, DB2 implemented SQL/XML extensions to SQL, to
provide a range of functions that allow the contents of XML documents to be processed
directly. These functions can also be encapsulated in DB2- stored procedures and
user-defined functions, so that standard SQL can be used against XML data with functions
and procedures that were developed using SQL/XML extensions.
SELECT
XMLELEMENT(
NAME "MsgRcpt",
XMLELEMENT(NAME "Nm", CUSTNAME),
XMLELEMENT(NAME "PstlAdr",
XMLELEMENT(NAME "StrtNm", STRTNM),
XMLELEMENT(NAME "BldgNb", BLDGNB),
XMLELEMENT(NAME "PstCd", PSTCD),
XMLELEMENT(NAME "TwnNm", TWNNM)
) ) from Address ;
-- yields result
<MsgRcpt>
<Nm>John Smith</Nm>
<PstlAdr>
<StrtNm>Bailey Avenue</StrtNm>
<BldgNb>555</BldgNb>
<PstCd>95141</PstCd>
<TwnNm>San Jose</TwnNm>
</PstlAdr>
</MsgRcpt>
XML publishing functions are straightforward. They provide a range of string concatenation
steps that can be combined together to form an XML documents. They simplify what you
could already have done with the standard SQL CONCAT function.
Existing DB2 programmers can extend their skills to include XPath expressions, to extend the
relational programs that they already write, and to incorporate XML data. Their capabilities
are best explained with several simple examples, based on a simple table with two columns,
illustrated in Example 2-3.
XMLEXISTS
The XMLEXISTS function is used as a predicate to retrieve DB2 rows, based on predicates
that are applied to the data within an XML column, as illustrated in Example 2-4. In this
example, each XML document is examined to see whether an <Nm> data element exists with a
value of “John Doe” at /MsgRcpt XPath location, and returns the rows where the predicate is
satisfied.
--yields result
XID XMLADDRESS
--- ------------
2 <MsgRcpt><Nm>John Doe</Nm><PstlAdr><StrtNm>Antelope...
SQL/XML Query
XID XMLADDRESS
1 <MsgRcpt><Nm>John Smith</Nm><PstlAdr><StrtNm>Bailey Avenue</StrtNm>…
2 <MsgRcpt><Nm>John Doe</Nm><PstlAdr><StrtNm>Antelope Street</StrtNm>…
3 <MsgRcpt><Nm>Janet Jones</Nm><PstlAdr><StrtNm>Bailey Avenue</StrtNm>…
… …
Result
Let us examine the structure of the XMLEXISTS predicate as the first example in this book of
the SQL/XML extensions to the SQL language:
The XMLEXISTS clause is the same as any other relational predicate, except that the
XMLEXISTS clause contains XML syntax expressions.
If the Nm field had been a VARCHAR column, the expression would have been
where Nm = "John Doe"
The XPath expression is applied to the XML column using the passing clause. In this way,
the XML document in each row that is accessed is passed as “i” to the XPath predicate
for evaluation
The comparison that is made by the XMLEXISTS clause is identical to what would have
been done relationally. The contents of the XML location /MsgRcpt/Nm are compared to the
"John Doe" string value:
– If the values match, the predicate is satisfied and the row qualifies.
– If the values do not match, the row does not qualify.
– If the data types do not match, the row does not qualify.
Note that the SQL/XML statement does not know whether the contents at /MsgRcpt/Nm is a
string or a number or any other data type. It determines this at run time. The data type of the
/MSgRcpt/Nm location may constrained to be a particular type if the document conforms to an
XML schema. XML schemas and validation of XML documents against XML schemas is
covered in 2.1.6, “XML schema repository and schema validation” on page 36.
If an XML document has a namespace declaration, the query must also define the
namespace, to ensure that we are referencing the correct XML data. Example 2-5 shows how
a namespace is declared on the XMLEXISTS function, if a namespace is required.
By coding the following statement, the DBA or developer must consider whether or not the
name column must be indexed to avoid a table space scan:
select * from table where name = ‘John Doe’
Exactly the same consideration applies to XML data. If we really want to code the SQL/XML
statement in Example 2-4 on page 26, we must consider an XML index to provide an efficient
access path to the <Nm> elements in the XML documents. Otherwise, as a result, we will be
executing the XPath expression against every single XML document in the table.
Of course, the DB2 optimizer is able to choose an access path based on a combination of
XML and relational predicates. Therefore, relational and XML indexes are both available for
access path selection, and can both be used in the same access plan.
XMLTABLE
The XMLTABLE function is used to retrieve XML elements and attributes from an XML
document and map them to a relational table structure, to be used by programs exactly as
though the data had been retrieved from a wholly relational table, as illustrated in
Example 2-6.
... yields
XID XMLADDRESS
Query 1 <MsgRcpt>
<Nm>John Smith</Nm>
<PstlAdr>
SELECT
[Link], [Link], <StrtNm>Bailey Avenue</StrtNm>
[Link], [Link], [Link] <BldgNb>555</BldgNb>
FROM XMLADDRESS C, <PstCd>95141</PstCd>
XMLTable('$cu/MsgRcpt/PstlAdr‘ <TwnNm>San Jose</TwnNm>
PASSING [Link] as "cu"
</PstlAdr>
COLUMNS
"NAME" CHAR(18) PATH '../Nm', </MsgRcpt>
"STREET" CHAR(18) PATH 'StrtNm', 2 <MsgRcpt>
"STREETNUM" CHAR(16) PATH 'BldgNb', <Nm>John Doe</Nm>
"POSTCODE" CHAR(16) PATH 'PstCd',
<PstlAdr>
"TOWN" CHAR(18) PATH 'TwnNm‘
) AS X <StrtNm>Antelope Street</StrtNm>
<BldgNb>32</BldgNb>
<PstCd>87233</PstCd>
<TwnNm>San Diego</TwnNm>
</PstlAdr>
</MsgRcpt>
… …
The mapping is based on an XPath expression that is used to navigate to a particular anchor
point in the XML document (/MsgRcpt/PstlAdr) and then using relative XPath expressions
(such as /StrtNm at the next level down, and ../Nm at the next level up from that anchor point)
to access XML data elements that are mapped to relational fields (such as STREET
VARCHAR(18)).
Note that the example in Figure 2-2 has mapped data from Nm, StrtNm, and TwnNm as
CHAR(18), whereas the original source of the data for all three fields was VARCHAR(70) in
Example 2-2 on page 25. The XMLTABLE function will perform a range of standard data type
casting, and will return an error if the casting is not possible. For example, if you attempted to
cast Nm as an integer, you would get SQL16061N. The value "John Smith" cannot be
constructed as, or cast (using an implicit or explicit cast) to the "xs:integer" data type.
Later in this book, more details are provided for managing the XML to relational mapping and
handling errors that might arise (for example, when casting an XML element to a specific
relational data type).
XMLQUERY
The XMLQUERY function is used to embed XPath expressions within an SQL/XML
statement. It always produces a column of type XML, and, as a scalar function, it returns a
sequence of items for each document (row), as illustrated in Example 2-7 on page 30.
-- yields
Names
-------------------
<Nm>John Smith</Nm>
<Nm>John Doe</Nm>
The XMLQUERY in Example 2-7 shows how XPath expressions can be executed within an
SQL statement, with the resulting XML document (or subdocument) being returned as an
XML structure. This particular example retrieves the XML structure at node /MsgRcpt/Nm for
every single XML document within the XMLADDRESS table.
The XMLEXISTS and XMLTABLE functions are particularly attractive when using traditional
programming languages, because they return data in a relational format. XMLTABLE can also
return an XML column.
The XMLQUERY function differs slightly because it returns a scalar value XML type, not
necessarily an XML document (usually it is not a document). This difference does not
necessarily introduce extra complexity to the traditional programmer, because the returned
XML type can be cast to a string data type, or moved on to another repository such as
WebSphere® Message Queue (MQ).
XMLCAST function casts the contents of an XML data element to a relational data type as
shown in Example 2-8.
select
xmlcast(xmlquery('$i/MsgRcpt/PstlAdr/BldgNb'
passing [Link] as "i") as integer)
as streetnumber from xmladdress c;
A good example of a hybrid data application might be insurance quotes. When an Internet
user fills in multiple HTML forms to get an insurance quote, the insurance company wants to
persist that information in a database, so that the Internet user can return at a later time to
purchase the policy that was quoted.
XML can be an excellent data model for storing insurance quotes because the data can
typically contain a large number of data elements, and various quotes may be structured in
many various ways. For example, the HTML forms that are filled in for a single-driver
car-insurance policy for a small vehicle can differ significantly from the HTML forms that are
filled in by a married couple insuring a powerful sports utility vehicle, and adding their 18
year-old son as a named driver:
If the quotation application was implemented in a relational structure, 10 or 20 main tables,
and multiple code tables, might exist.
If the quotation application was implemented in an XML structure, a single XML document
can contain all the structure and constraints for the quotes.
However, the existing client and policy systems likely will have been written many years ago
using the relational model of data. Therefore, the new quotes application must be able to
bridge the gap between XML and relational data models.
The XMLTABLE function provides the basis for a simple use case. The address details can be
read from an XML document that contains the quote, and inserted into an address table
within the policy system, as shown in Example 2-11.
Clearly, this simplistic example does not reflect the way that insurance systems might be
designed, with error-checking, input validation, and so on. However, the example still serves
to illustrate that the DB2 hybrid data model does provide an integrated database platform
upon which bridging the gap between relational and hierarchical models of data can be
easier.
Inserting and updating XML data is supported with the XMLPARSE option, which parses a
string value to return an XML document, and optionally strips or preserves white space. The
white space handling is illustrated in Example 2-9 on page 31.
Updating XML documents can be performed by either replacing the whole document, or
updating a part of it. A full replacement of an XML document is coded with a simple SQL
update statement, and an XMLPARSE function call if the source data is in string format. A
partial document update uses the XMLMODIFY function to change an existing XML
document.
The XMLMODIFY function depends on the underlying table space being a universal table
space, so that multiple XML versions are supported. Support for multiple XML versions is
implemented in DB2 10 to improve concurrency and reduce locking: A new version of the
XML document is created during an update, which allows SQL read operations (with the
appropriate isolation level) to access the old version of the XML document concurrently.
This section shows examples of all three variations of XMLMODIFY, based on the initial table
contents shown in Example 2-12.
XID XMLADDRESS
--- -------------------------------------
2 <MsgRcpt>
<Nm>Johnny Doe</Nm>
<PstlAdr>
<StrtNm>Antelope Street</StrtNm>
<BldgNb>32</BldgNb>
<PstCd>87233</PstCd>
<TwnNm>San Diego</TwnNm>
</PstlAdr>
</MsgRcpt>
XID XMLADDRESS
--- -------------------------------------
2 <MsgRcpt>
<Nm>Johnny Doe</Nm>
</MsgRcpt>
XID XMLADDRESS
--- -------------------------------------
2 <MsgRcpt>
<Nm>Johnny Doe</Nm>
<Notes>Testing</Notes>
</MsgRcpt>
Sub-document update becomes important for performance reasons if small changes need to
be made to large XML documents. For example, changing the details of one book in an XML
document that contains a book catalog would be a lot cheaper than replacing and revalidating
the whole document.
The major reasons for defining relational indexes in DB2 are as follows:
Efficient access path to data (minimizing I/O and CPU resource consumption)
Option to apply a unique constraint
These same reasons also apply to XML indexes. Their fundamental purposes are to facilitate
performance and to enforce uniqueness.
However, the nature of an XML index has several differences from a relational index. The
major differences are as follows:
Relational indexes may be defined on one or more relational columns. XML Indexes may
be defined only on one XML element or XML attribute (using an XML pattern expression).
Relational indexes always have one index entry for every row in a table. However, XML
indexes are much less prescriptive. XML indexes are based on an XML pattern. An XML
pattern may occur any number of times in an XML document. Therefore, XML indexes
may contain 0, 1, or many entries for each row in the table.
Relational indexes are always based on the data types of the column or columns on which
they are defined. The data types found at the locations of an XML pattern may be many
and varied unless an appropriate XML schema is enforced. Using XML schema validation
against a well-defined XML schema will allow the data types of XML elements to be
controlled (as covered in 2.1.6, “XML schema repository and schema validation” on
page 36).
Relational indexes can be used to support table clustering. XML indexes may not be used
for table clustering support.
XML indexes have a more complex set of physical design considerations than relational
indexes. A good understanding of XPath expressions and XML schemas and XML
namespaces is essential to designing XML indexes that are likely to be chosen by the DB2
optimizer.
Having sounded a caution that XML index design requires careful consideration of a number
of new factors, we also want to state how powerful and productive they are. Without XML
indexes, a database application would have to go through an extra development phase where
key data elements are stripped to relational tables, and indexed by using traditional relational
indexes. With XML indexes, you can avoid this extra development phase and index your XML
data as efficiently as you index your relational data, and realize the simplicity that DB2’s
hybrid data model provides.
Example 2-16 provides simple example of how XML indexes are created in DB2.
An XML index can point to a small number of entries (or none) if the XML pattern of the index
does not fit the data.
XML index design requires the nature of XML indexes to be understood, and the matching
success of the index to be checked.
The DB2 optimizer can use XML indexes and traditional DB2 indexes together to produce the
most efficient access paths for hybrid data access. The way that XML and relational indexes
work together is one of the best illustrations of how DB2 makes hybrid data both valuable and
performant.
DB2 also provides the ability to implement and enforce an XML data model, through its ability
to validate XML documents against a registered XML schema. XML data structures can be
defined through XML schemas. An XML schema defines the structure of an XML document
by defining the following items:
The elements that can appear in a document
The attributes that can appear in a document
Which elements are child elements
The order of child elements
The number of child elements
Whether an element is empty or can include text
The data types for elements and attributes
The default and fixed values for elements and attributes
A simple XML schema is shown in Example 2-17 on page 37, which defines how email
information about an individual should be stored. The <emails> element can be a parent to 1
- 5 specific <email> elements. Each email element is required to have an emailUse tag, which
describes the nature of that particular email account (work, home, and so on).
The XML document in Example 2-18 conforms to the XML schema that is described in
Example 2-17.
DB2 support for XML schema validation consists of the following items:
An XML schema repository, where XML schemas can be stored within DB2
A schema validation function, which allows an XML data type to be validated against a
schema within the repository
A Data Definition Language (DDL) option to define an XML column with a type modifier, so
that schema validation is enforced by DB2 automatically for that column
The schema repository is populated by using the four XML schema repository stored
procedures that are provided by DB2. These stored procedures are invoked by commands
from z/OS UNIX® System Services or DB2 for z/OS1 and DB2 for Linux®, UNIX, and
Windows® command line processor (CLP), as shown in the following examples.
The script in Example 2-19 on page 38 shows a schema being registered to the DB2 XML
schema repository, and then being completed.
1
See DB2 for z/OS CLP:
[Link]
tm
The SQL statement in Example 2-20 shows the DSN_XMLVALIDATE function being invoked
manually, as part of an INSERT operation to a table (TABLE1).
The DDL statement in Example 2-21 shows another Table (TABLE2) being defined, where all
XML documents stored in the XML column of that table will be automatically validated.
The DB2 XML schema validation services are essential for enforcing the integrity of XML
documents against the rules that they should conform to. They can be simple to use, and
allow complex XML schemas to be incorporated easily, as shown by the ISO 20022 examples
later in this book.
XML validation is an optional facility requiring the XML Schema Repository (XSR). You might
not want to use DB2’s XML schema validation for documents that have already been
validated outside of DB2. However, in general, you must have access to this facility or an
equivalent one when you use DB2 pureXML.
For the most current maintenance level, see information APAR II14426. It contains a
summary and pointers to all the XML support delivery APARs.
The installation steps of the XML Schema Repository and functions are as follows:
1. Customize and run the DSNTIJRW and DSNTIJMV jobs:
– Define the WLM environment and startup procedure for the C language XML schema
repository-stored procedures.
A dedicated WLM environment and startup procedure is required for the XSR-stored
procedures that are written in C (XSR_ADDSCHEMADOC, XSR_REGISTER, and
XSR_REMOVE). Note the following information:
• The DSNTIJRW Installation job installs and configures a WLM environment with the
default name of DSNWLM_XML, which you can use it to run the XML schema
repository stored procedures.
• The DSNTIJMV installation job installs a WLM startup procedure named
ssnmWLMX for that WLM environment.
– Define the WLM environment and startup procedure for the Java language XML
schema repository stored procedure. A dedicated WLM environment and startup
procedure is required for the XSR stored procedure written in Java
(XSR_COMPLETE). Note the following information:
• The DSNTIJRW installation job installs and configures a WLM environment with the
default name of DSNWLM_JAVA, which you can use it to run the XML schema
repository stored procedures.
• The DSNTIJMV installation job installs a WLM startup procedure named
ssnmWLMJ for that WLM environment.
2. Customize and run job DSNTIJRT.
Run installation Job DSNTIJRT to create the XSR objects (database, table spaces, tables,
indexes, stored procedures) and bind the DB2 XSR packages for the stored procedures.
3. Bind the Universal JDBC Driver.
Bind the packages for the IBM Data Server Driver for JDBC and SQLJ (on UNIX System
Services, Windows, or both).
D WLM,APPLENV=DSNWLMDB0B_XML
RESPONSE=SC63
IWM029I 14.43.07 WLM DISPLAY 072
APPLICATION ENVIRONMENT NAME STATE STATE DATA
DSNWLMDB0B_XML AVAILABLE
ATTRIBUTES: PROC=DB0BWLMX SUBSYSTEM TYPE: DB2
D WLM,APPLENV=DSNWLMDB0B_JAVA
RESPONSE=SC63
IWM029I 14.43.39 WLM DISPLAY 074
APPLICATION ENVIRONMENT NAME STATE STATE DATA
DSNWLMDB0B_JAVA AVAILABLE
ATTRIBUTES: PROC=DB0BWLMJ SUBSYSTEM TYPE: DB2
Check that the XSR tables are created with the SQL statement in Example 2-24.
XSRANNOTATIONINFO
XSRCOMPONENT
XSROBJECTCOMPONENTS
XSROBJECTGRAMMAR
XSROBJECTHIERARCHIES
XSROBJECTPROPERTY
XSROBJECTS
XSRPROPERTY
Check that the XSR schema validation routines are created with the SQL statement in
Example 2-25.
XSR_ADDSCHEMADOC
XSR_COMPLETE
XSR_REGISTER
XSR_REMOVE
-- which returns “IBM Data Server Driver for JDBC and SQLJ”
If all the checks are successful, and you still have errors using the XSR routines, you must
then look at the specific error codes and address them individually. Potential errors can
include SQLCODE -805 package not found errors if you have not run the bind jobs, or Java
errors if the Java environment is not defined correctly in the [Link] file.
For details about migrating to the new functions, see the following web address:
[Link]
[Link]/db2z_udfdsnxmlvalidatetobifdsnxmlvalidate.htm
You might frequently encounter the situation in which your SQL and DDL statements contain
an XML expression that is greater than 80 bytes long. In such circumstances, you can split an
XPath expression over multiple lines and it will still run successfully, as shown in Figure 2-4.
---------+---------+---------+---------+---------+---------+---------+---------+
AAAASESS-FP-STAT001
...
Figure 2-4 Splitting an XPath expression over multiple lines in 3270 SPUFI session
DB2 Administration Tool for z/OS provides database administration facilities for DB2 objects
containing XML columns. XML columns are just another data type that DB2 Administration
Tool caters for.
Table 2-2 summarizes several tools that are most likely to be used with DB2 and pureXML.
Table 2-2 IBM tools for DB2 administration and development with DB2 pureXML.
Tool Overview of capabilities Comments
Data Studio IDE Data development (SQL, SQL/XML, This download is included in the DB2 license for all
stored procedures, data web services platforms. It provides an Eclipse-based
and more) environment for a wide range of DB2 development
and administration activities, including XML.
XML: XML/Schema editor, XML
mapper, web services, Schema
registration and more
Optim™ Development This tool is based on Data Studio, and This chargeable tool includes additional facilities
Studio includes extensions, such as: beyond Data Studio, which are aimed more at a
pureQuery support development user than a DBA.
XML validator
XSD validator
InfoSphere™ Data Logical and physical data modeling to This chargeable tool is aimed at data modelers and
Architect design databases, discover, relate, and architects. This tool provides logical and physical
integrate and standardize diverse data data modelling and schema development
assets. capabilities.
Rational® Developer Provides System z developers with tools This chargeable tool is aimed at System z
for System z for building traditional and composite application developers.
applications in an SOA and Web 2.0
environment The tool contains an overlapping of XML-related
tools with the products, and extended XML
mapping and integration tools for System z
applications.
A comprehensive paper, “Tools and XML functionality for DB2 pureXML users” by Bryan
Patterson, is available on IBM developerworks website. The paper lists a wider range of IBM
tools, and describes the tasks that they support in the context of typical development and
DBA roles. Access the paper at the following address:
[Link]
Financial services companies are growing their usage of messaging and workflow systems at
a phenomenal rate. Business processes are modelled and implemented, so that they may be
executed as efficiently as possible. ESB technology is used to link together all the systems
that must be involved to complete these business processes. Messages are sent over an
organization's enterprise service bus during the automated execution of these business
processes.
Although many technologies and products might be used to implement these systems, often
the common glue binds them all together is XML.
An audit trail of some or all of the XML messages that are sent and received over the ESB
can be valuable for many reasons:
An audit trail of messages describing high value financial transactions might provide a
valuable source of information for monitoring and dashboard systems.
Compliance requirements for certain applications might require that a very detailed audit
trail be maintained.
Technical problem resolution for messaging and workflow systems might be assisted by
being able to trace the flow of messages through the execution of a business process.
Whatever the reasons for choosing to log event data in a persistent datastore, logging the
XML messages is valuable only if you are subsequently able to read and analyze the XML
messages with easy-to-use query and reporting tools.
DB2 pureXML provides an excellent platform for such event-logging systems, for the following
reasons:
XML messages can be written to DB2 with minimal application development effort. No
complex relational models must be developed to log XML messages for subsequent
auditing processing.
The content of XML messages that have been stored in DB2 can be subsequently
searched and accessed with ease by using SQL/XML queries.
XML data elements that are used for searching and joining of data (such as user ID,
customer ID, time, and date) can be indexed so that queries can be optimized to access
only those XML messages which are needed for the required task.
WebSphere MQ
DB2
MQ Listener
DB2 stored procedure
COBOL
Programs DB2
SQL/XML
<xml> QUERY
Java
Programs
</xml> RDB
A common requirement when implementing XML data within DB2 is to work with an existing
standard for XML messages. In our example, we have chosen to work with ISO 20022
(universal financial industry message scheme).
The ISO 20022 standard provides the financial industry with a common set of messages in a
standardized XML syntax. See the following resources for more information:
Current documentation for this standard:
[Link]
ISO 20022 document:
[Link]
Description and schema of the Bank To Customer Statement V2:
[Link]
The programming scenarios in this book are focussed on only one message type from the
ISO 20022 standard (Bank To Customer Statement V2). We chose this message type
because most readers are familiar with the concept of a bank statement. For the ISO
With DB2 pureXML, it can be easy to import the XML schemas that define an XML standard
into the DB2 XML schema repository, so that all XML documents stored in DB2 can be
automatically (or manually) validated against different versions of the XML schema standards.
The DDL and schema samples are common to all the programming samples. However, each
programming sample is independent of the other programming samples. So, if your interest is
COBOL, you can download and use the COBOL samples, without depending on Java or
stored procedure samples.
Figure 3-2 on page 51 illustrates the flow between the various code samples presented in this
book. The flow is explained in the following sections.
“SHRED TABLES
“Audit” queries Java Programs
The functions of the Java programs are to perform the following tasks:
Shred the previously saved XML message.
Query the message to produce a new XML document.
Output the new message to a WebSphere MQ queue.
Use the binary XML format to retrieve XML documents from DB2 to the IBM universal
driver for JDBC and SQLJ.
Perform XSLT transformations on the XML documents.
Several COBOL programs are presented in Chapter 8, “Using XML with COBOL” on
page 157, and they perform the following tasks:
Read an XML message from a file and save it in DB2.
Select an XML message from DB2 and save it to a file.
Extract information from XML documents in DB2.
Update an XML document on a sub-document level.
In addition, we demonstrate what impact a schema change can have on the COBOL
application and describe how it compares to a relational implementation of the same
database schema.
Finally, we look at some of the XML functionality available in native COBOL as a complement
to the pureXML capabilities in DB2.
You do not specify a length when you define an XML column. There is no architectural limit on
the size of an XML value in a database. However, textual XML data that is exchanged with a
DB2 database is limited to 2 GB minus 1, so the effective limit of an XML column is 2 GB-1.
As with a LOB column, an XML column holds only a descriptor of the column. The data is
stored separately.
Example 4-1 shows how you can define the BK_TO_CSTMR_STMT table, referred to in 3.3,
“Application code samples” on page 50 for the application scenario.
Because the IN clause is not specified, the table is created in an implicitly created
partition-by-growth universal table space with a value of 256 for MAXPARTITIONS. The
additional table space for the XML column is created by using the default storage group
SYSDEFLT in an implicitly created database.
As with LOB data, the table that contains an XML column (the base table) is in a different
table space from the table space which contains the XML data.
The storage structure depends on the type of table space that contains the base table.
We show the relationship between non-partitioned table space for base tables with XML
columns and the corresponding XML table spaces and tables.
NODEID
INDEX
Cols:
DOCID
MIN_NODEID
XMLDATA XML
Index
XMLCol1 Table
DOCID
INDEX Cols:
DOCID
XMLCol1
Partition-by-growth TS for XMLCol1
XMLCol2
Cols:
DOCID NODEID
INDEX
MIN_NODEID
XMLDATA
START_TS
END_TS XML
Index
XMLCol1 Table
DOCID
INDEX Cols:
DOCID
XMLCol1
Partition-by-growth TS for XMLCol1
XMLCol2
Cols: NODEID
BASE Table DOCID INDEX
MIN_NODEID
Partitioned-by- growth Base TS XMLDATA
START_TS
END_TS XML
Index
XMLCol2 Table
We show the relationship between partitioned table space for base tables with XML columns
and the corresponding XML table spaces and tables.
NODEID
INDEX
(NPI)
Part1 Part2
DOCID DOCID XML
DOCID MIN_NODEID MIN_NODEID Index
INDEX XMLDATA XMLDATA
(NPI)
Part1 Part2
DOCID DOCID
MIN_NODEID MIN_NODEID
XMLDATA XMLDATA
START_TS START_TS
END_TS END_TS
DOCID
XML
INDEX
Index
(NPI)
Range-partitioned table space with partitions for XMLCol1
Cols: Cols:
DOCID DOCID
XMLCOL1 XMLCOL1 NODEID
XMLCOL2 XMLCOL2 INDEX
(NPI)
BASE Table BASE Table
Part1 Part2
Part1 Part2
Range-partitioned base table DOCID DOCID
MIN_NODEID MIN_NODEID
space with two partitions XMLDATA XMLDATA
START_TS START_TS
END_TS END_TS
XML
Index
Important: The implicitly created XML table space is always a universal table space, either
partition-by-growth or range-partitioned. If you want to have the ability to handle multiple
versions of XML document make sure the base table space is a universal table space.
Figure 4-5 on page 59 shows the storage structure of XML data when XML versions are not
defined.
DOCID index
XML index (user)
NODEID index
B+tree
B+tree
B+tree B+tree
B+tree B+tree
Base Table XML Table
DocID … XMLPO DOCID MIN_NODEID XMLDATA
1 1 02
2 2 02
3
2 0208
3 02
A table with an XML column has a
DOCID column, used to link from the
Each XMLDATA column is a VARBINARY, containing
base table to the XML table.
a subtree or a sequence of subtrees, with context
A DOCID index is used for getting to
path. Rows in XML table are freely movable, linked
base table rows from XML indexes. with a NODEID index.
The node ID for a node is the concatenation of local node ids contained in each node along
the path from the root to the node. For each XML data record, a context node ID exists that
contains node IDs from the root to the parent node for the nodes inside the record. The
MIN_NODEID column of an XML table contains the minimum node ID within the XMLDATA
record in that row, which is a concatenation of the context node ID and the first node ID in the
record body. DOCID and MIN_NODEID are used for clustering rows that belong to the same
document.
XML indexes: XML indexes are user-created indexes for achieving good performance.
Support: If the base table space is not a universal table space, it does not support multiple
XML versions. To convert the base table space from either segmented or partitioned to
universal table space, you must remove it (with the DROP command) and re-create it.
ALTER and REORG are not sufficient in this case.
With XML versions, when you insert an XML document into an XML column, DB2 assigns a
version number to the XML document. If the entire XML document is updated, DB2 creates a
new version of the document in the XML table. If a portion of the XML document is updated,
DB2 creates a new version of the updated portion. When DB2 uses XML versions, more data
set space is required than when versions are not used. However, DB2 periodically deletes
versions that are no longer needed. In addition, you can run the REORG utility against the
XML table space that contains the XML document to remove unneeded versions. DB2
removes versions of a document when update operations that require the versions are
committed, and when no readers reference the unneeded versions.
XML versions: XML versions differ from table space versions or index versions. The
purpose of XML versions is to optimize concurrency and memory usage. The purpose of
table space and index versions is to maximize data availability.
Suppose that table T1, which is in a universal table space, is defined as follows:
CREATE TABLE T1(
INT1 INT,
XML1 XML,
XML2 XML );
An application performs SQL read operations that are represented by the following
pseudocode:
EXEC SQL
DECLARE CURSOR C1 FOR
SELECT INT1, XML1
At the same time, another application performs SQL write operations that are represented by
the following pseudocode:
EXEC SQL UPDATE T1
SET XML1 = XMLPARSE(DOCUMENT '<B1>222</B1>');
EXEC SQL OPEN CURSOR C1; (Note: Cursor C1 is in another application as described)
EXEC SQL UPDATE T1
SET XML1 = XMLPARSE(DOCUMENT '<C1>333</C1>');
EXEC SQL FETCH FROM C1 INTO :HVINT1, :HVXML1;
With multiple versions, the reading application does not need to hold a lock. Thus, the
updating application can do its update operations without waiting for the reading application to
finish. The reading application reads the old versions of the XML values, which are consistent
data.
3 02 00…650 FF…FFF
When you create a table with XML columns or alter a table to add XML columns, DB2
implicitly creates the following objects:
A table space and table for each XML column
The data for an XML column is stored in the corresponding table.
DB2 creates the XML table space and table in the same database as the table that
contains the XML column (the base table). The XML table space is in the Unicode UTF-8
encoding scheme.
If the base table contains XML columns that support XML versions, each XML table
contains two more columns than an XML table for an XML column that does not support
XML versions. Those columns are named START_TS and END_TS, and they have the
BINARY(8) data type. START_TS contains the RBA or LRSN of the logical creation of an
XML record. END_TS contains the RBA or LRSN of the logical deletion of an XML record.
START_TS and END_TS identify the rows in the XML table that make up a version of an
XML document.
Column START_TS represents the time when that row is created, and column END_TS
represents the time when the row is deleted or updated. Column END_TS contains
X’FFFFFFFFFFFFFFFF’ initially. To avoid compression causing update overflow, columns up
to column END_TS are not compressed in the reordered row format.
Figure 4-7 shows, in general, how DB2 handles support of multiple versions for XML data.
Example: A document is inserted at time t0 and is stored as two records. At time t2, a
node is inserted into the 2nd record, a new version of the record is created at t2 and
the old version ended at t2. The old version is not deleted until garbage clean up.
Time
t0 FF…F
t0 t1 t2 t3 FF…F
Figure 4-7 Multiple versions for XML data
Each row in the XML auxiliary table is associated with two temporal attributes (start and end)
to represent the period when the row exists:
Start represents the time when that row is created.
End represents the time when the row is deleted or expired.
A row in XML auxiliary table is never deleted until the garbage collector cleans it up.
When an XML document is deleted at time t2, all the records for that document are marked
expired at t2. When a row of an XML document is updated, all the records for that document
are marked expired at t2, the new document is inserted into XML auxiliary table with start
time set to t2.
When a part of an XML document is modified, only the existing record (or records) to be
modified expire and a new version of those records is created.
Storage structure: This storage structure is possible only in new-function mode and for
universal table spaces. Storage structure for multiversioning is a prerequisite for several
other XML enhancements such as the following enhancements:
Access of currently committed data
“As Of” option for time-oriented data
XML update with XMLMODIFY
Removing restrictions for SELECT FROM UPDATE//DELETE for XML
Note: The name of the XML table space always starts with X and it is always a
universal table space. In this case, it is partition-by-growth because the base table
space is partition-by-growth, and is created in the same database as the base table
space.
You can get information about the columns in both the base table and XML table from
[Link] as shown in Query 5. The first three rows are for the three
columns that are defined in the base table. The fourth row is the DOCID column that is
generated by DB2. The next three rows are for columns that are defined in the XML table.
The last two rows are for the two extra columns that are defined in the XML table to
support multiple versions for XML documents and are present because the base table is in
partition-by-growth universal table space.
TYPE is TS for a table space, IX for an index space, and XS for an XML table space.
PART is the partition number. Because we have one partition for the partition-by-growth table
space for both the base table and the XML table, PART shows 00001. Over time, the table
space can grow to more partitions and that is why there are two lines for each of the base and
XML table spaces, at present with no value.
For non-partitioned indexes, it is the logical partition number preceded by the character L (for
example, L0001). This is the case for the DOCID and NODEID indexes.
-DISPLAY DB(DSN00242)
In this section, we show an example of the SQL INSERT statement that uses a string literal to
insert rows into a table that contains XML columns. This form of INSERT is suitable for small
documents. The host variable or file reference versions of INSERT are applicable for any
length.
Example 4-6 on page 70 shows the successful insertion of the shorter version of the
Message Received XML document for our application scenario shown in Example A-2 on
page 274.
This technique is cumbersome for large XML documents. We show how to use the LOAD
utility in such cases. LOAD utility is discussed in Chapter 9, “Utilities with XML” on page 183.
The same way that you define relational indexes on selected columns of a relational table,
you define XML indexes on selected elements and attributes within a single XML column of a
table. In particular, XML indexes in DB2 do not automatically index all the values in an XML
column, but only those that you choose. Although you may choose to index all elements and
attributes, you should typically index only those elements and attributes that are frequently
used in predicates and join conditions.
Rather than providing access to the beginning of a document, index entries in an XML index
provide access to nodes within the document by creating index keys based on XML pattern
expressions. Because multiple parts of a XML document can satisfy an XML pattern, DB2
might generate multiple index keys when it inserts values for a single document into the index.
Several keywords that are used with the CREATE INDEX statement for indexes on non-XML
columns do not apply to indexes over XML data.
Example 4-7 shows an the creation of an index on the sample XML document for the
application scenario.
Only one index specification clause is allowed in a CREATE INDEX statement. However, you
may create multiple XML indexes on an XML column.
Every XML pattern expression that you specify in a CREATE INDEX statement must be
associated with a data type. The data type must be VARCHAR, DECFLOAT, DATE, or
TIMESTAMP.
You can interpret the result of pattern expression as multiple data types. For example, the
value 123 has a character representation, but it can also be interpreted as the number 123.
You may create separate indexes on the same pattern expression with separate data types,
so that the data can be indexed, regardless of its data type.
If you validate your XML documents against an XML schema, ensure that the data type
specifications in the XML schema match the data types that you use for your indexes.
The UNIQUE keyword in XML index definitions has a similar but slightly different meaning
than it does for relational index definitions:
For relational indexes, the UNIQUE keyword in the CREATE INDEX statement enforces
uniqueness across all rows in a table.
For indexes over XML data, the UNIQUE keyword enforces uniqueness across all
documents in an XML column.
Because rounding can occur during conversion of an index key value to the specified data
type for the index, multiple values that appear to be unique in the XML document might rarely
result in duplicate key errors.
In addition, XML schema validation strips the ignorable white space from the input document.
The two ways that you can validate an XML document in DB2 10 are as follows:
Automatically, by including an XML type modifier in the XML column definition in a
CREATE TABLE or ALTER TABLE statement
When a column has an XML type modifier, DB2 implicitly validates documents that are
inserted into the column or when documents in the column are updated.
User-controlled, by executing the DSN_XMLVALIDATE built-in function when you insert a
document into an XML column or update a document in an XML column or before
selecting back (not necessarily into a table)
Validation is optional when you insert data into an XML column with no XML type modifier.
Validation is mandatory when you insert data into an XML column with an XML type modifier.
This chapter describes both methods (automatic and user-controlled). First, we describe the
XML type modifier.
The XML data type can accept any well-formed XML documents. However, in many cases,
users want to store, in one XML column, the documents that have similar structures or
conform to the same XML schema. DB2 10 introduces the XML type modifier, which qualifies
the XML data type with a set of one or more XML schemas. The value of an XML column with
an XML type modifier must conform to at least one XML schema that is specified in the type
modifier.
When you define an XML column, you may add an XML type modifier. An XML type modifier
associates a set of one or more XML schemas with the XML data type. You may use an XML
type modifier to cause all XML documents that are stored in an XML column to be validated
according to one of the XML schemas that is specified in the type modifier.
The XML type modifier can identify more than one XML schema. You might want to associate
more than one XML schema with an XML type modifier for the following reasons:
The requirements for an XML schema evolve over time.
An XML column might contain documents that describe only one type of information, but
certain fields in newer documents might need to be different from fields in the older
documents. As new document versions are required, you can add new XML schemas to
the XML type modifier.
A single XML column contains XML documents of various kinds.
An XML column might contain documents that have several formats. In this case, each
type of document needs its own XML schema.
For example, a sales department might have one XML schema that defines purchase orders
and billing statements. You might store purchase orders in one XML column, and billing
statements in another XML column. Both XML columns have an XML type modifier that points
to the same XML schema, but each column restricts documents with separate root elements
in the XML schema.
You define an XML type modifier in a CREATE TABLE or ALTER TABLE statement as part of
an XML column definition.
Not all XML schemas that the XML type modifier identifies must be registered before you
execute the CREATE or ALTER statement. If the XML type modifier specifies a target
namespace, only the XML schemas in that target namespace that exist when the CREATE or
ALTER statement is executed are associated with the XML type modifier.
If altered data type is XML, the old data type of the altered column must also be XML:
If the old data type has no XML type modifier and the new data type does, ensure that all
values in the XML column are valid according to the XML schema that is specified in the
type modifier. The XML table space for the column that is being changed is left in
CHECK-pending status.
If the old data type has the XML type modifier but the new data type has no type modifier,
the existing values do not need to be revalidated. The state of the table space is not
changed.
If the XML schemas that are specified in the old XML type modifier are a subset of the
XML schemas that are specified in the new XML type modifier, the existing values do not
need to be revalidated. The state of the XML table space is not changed.
If the XML schemas that are specified in the old XML type modifier are not a subset of the
XML schemas that are specified in the new XML type modifier, the XML table space for the
column that is being changed is left in the CHECK-pending status.
Changing an XML column to use a different type modifier does not result in the invalidation of
dependent plans, packages, or statements in the dynamic statement cache. Also, changing
an XML column to use a different type modifier does not generate a new version of the table.
XML Schemas
XML Target Namespace Schema Location Registration
schema Timestamp
name
PO1 [Link] [Link] 2009-01-01
[Link].0000
Example 5-1 shows how to specify an XML type modifier for an XML column at creation time.
Example 5-1 Specify an XML type modifier for an XML column at creation time
CREATE TABLE PURCHASEORDERS(
ID INT NOT NULL,
CONTENT XML(XMLSCHEMA ID SYSXSR.PO1))
A table for purchase orders contains an XML column named CONTENT. The documents in
the XML column must be validated according to XML schema SYSXSR.PO1, which has
already been registered.
To alter an existing XML column to include an XML type modifier or remove an XML type
modifier, use ALTER TABLE statement.
Example 5-2 shows the table definition without XML type modifier specified.
The table contains several XML documents. The documents in the XML column must be
validated according to the XML schema SYSXSR.PO1, which has already been registered.
Alter the XML column to add an XML type modifier that specifies SYSXSR.PO1, as shown in
Example 5-3.
Example 5-3 Specify XML type modifier for XML column at alteration time
ALTER TABLE PURCHASEORDERS
ALTER CONTENT
SET DATA TYPE XML(XMLSCHEMA ID SYSXSR.PO1)
Note: The table space that contains the XML documents for the CONTENT column is put
in CHECK-pending status.
XML schema: Because the XML schema specified in the old type modifier is a subset of
the new type modifier, the existing values of the CONTENT column do not need to be
validated again. Thus, the state of the XML table space for the CONTENT column stays
unchanged. If the XML schema that is specified in the old XML type modifier is not a
subset of the XML schema that is specified in the new XML type modifier, the XML table
space for the column that is being changed remains in the CHECK-pending status.
You may also reset the data type of CONTENT to XML without type modifier.
Example 5-5 shows how to reset XML type modifier for an XML column at alter time.
Example 5-5 Reset XML type modifier for XML column at alter time
ALTER TABLE PURCHASEORDERS
ALTER CONTENT
SET DATA TYPE XML
CONTENT column in this example: The existing values of the CONTENT column do not
need to be validated again.
Validation is automatically performed for INSERT and UPDATE SQL statements and the
LOAD utility if the XML column is defined with the XML type modifier.
Instead of specifying the schema name directly as shown in all the examples, you may also
specify the URI and LOCATION keywords, so the schema name can be derived.
Example 5-6 shows how to specify the schema location hint. Both PO2 and PO4 have the
same target namespace [Link] If you want to use PO2, you may add
LOCATION ‘[Link] after the URI ‘[Link]
clause.
Example 5-6 Identify an XML schema by target namespace and schema location
CREATE TABLE PURCHASEORDERS(
ID INT NOT NULL,
CONTENT XML(XMLSCHEMA URI ‘[Link]
LOCATION ‘[Link] ))
Using the URI keyword: If you execute the CREATE TABLE statement before PO4 is
registered, only PO2 is added to the type modifier in [Link].
When PO4 is registered later, the XML type modifier for the CONTENT column remains
unchanged. If you execute the CREATE TABLE statement after PO4 is registered, an SQL
error occurs because the XML type modifier uses the URI keyword to identify two XML
schemas PO2 and PO4. The URI keyword must identify only one XML schema.
If an XML schema does not contain the targetNamespace attribute in its schema document, it
can be referenced in the XML type modifier by NO NAMESPACE.
If an XML schema has more than one global element declaration and you want to validate the
XML value against one of them, you can specify the ELEMENT clause. Assume that the
purchase order schema has declared two global elements: purchaseOrder and comment.
Therefore, a document whose root element is either purchaseOrder or comment could be
valid according to PO1 and can be stored in the PURCHASEORDERS table. However, this
approach might not be desirable. If you want to store only purchase order documents in the
CONTENT column, you can specify the ELEMENT “purchaseOrder” in the XML type modifier
for CONTENT. Example 5-9 shows how you can do this step.
Figure 5-2 on page 81 shows the table definition and the entries in the XSR for the schemas
used as XML type modifiers in the table definition.
Table definition:
Figure 5-3 shows how DB2 chooses an XML schema when the XML type modifier specifies
multiple schemas.
Schema determination
– DB2 determines the XML schema to use upon INSERT, UPDATE or LOAD.
TNS* TargetNamespaces NS* Namespace
Do TNS* of NO
schemas match
with the NS* of the Error
root in the doc?
YES
YES
Only 1 match? Take this one!
NO
Schema YES Schemas YES
match with the Take this one!
Location in
Schema location?
doc?
NO
NO
Take the XML schema with latest
registration timestamp
You may include more than one XML schema in an XML type modifier. When you insert into
or update an XML column, DB2 chooses one XML schema to do validation.
The first member of the pair, [Link] is the namespace name. The
second member of the pair, [Link] is the URI that provides the
schema location hint.
DB2 uses the schema location hint to choose an XML schema in the following way:
If the root element node contains an xsi:schemaLocation attribute, DB2 searches the
attribute value for a schema location hint with a corresponding namespace name that
matches the namespace name in the root element node.
If DB2 finds a schema location hint, DB2 uses the hint to identify an XML schema whose
schema location URI is identical to the schema location hint. DB2 validates the input
document against that schema.
If the root element does not contain an xsi:schemaLocation attribute, or the
xsi:schemaLocation attribute does not contain a schema location hint with a
corresponding namespace name that matches the namespace name in the root element
node, DB2 uses the XML schema with the same target namespace and the latest
registration time stamp.
Examples of how DB2 determines the schema to be used for validation from an XML type
modifier are listed next.
Example 5-10 Schema selection for validation from an XML type modifier (1 of 4)
The namespace name in the root element of the instance document is as follows:
[Link]
This name matches only the target namespace for XML schema PO1.
Example 5-11 Schema selection for validation from an XML type modifier (2 of 4)
INSERT INTO PURCHASE_ORDERS VALUES(2,
‘<po:purchaseOrder xmlns:po="[Link]
xmlns:xsi="[Link]
xsi:schemaLocation="[Link]
[Link]
...
</po:purchaseOrder>‘);
The namespace name in the root element in the instance document is as follows:
http:// [Link]/PO2
It matches the target namespace of XML schemas PO2 and PO4. The root element of the
instance document also contains an xsi:schemaLocation attribute, which has a value that
provides the schema location hint:
http:// [Link]/[Link]
The schema location hint matches the schema location for XML schema PO2. Therefore DB2
chooses PO2 to validate the instance document. If validation with PO2 fails, DB2 uses PO4.
In Example 5-12, DB2 chooses XML schemas PO4 and PO2 in this order.
Example 5-12 Schema selection for validation from an XML type modifier (3 of 4)
INSERT INTO PURCHASE_ORDERS VALUES(3,
‘<po:purchaseOrder xmlns:po="[Link]
xmlns:xsi="[Link]
xsi:schemaLocation="[Link]
[Link]
...
</po:purchaseOrder>‘);
The namespace name in the root element in the instance document is as follows:
http:// [Link]/PO2
It matches the target namespace of XML schemas PO2 and PO4. The root element of the
instance document also contains an xsi:schemaLocation attribute whose value provides the
schema location hint:
http:// [Link]/[Link]
The schema location hint matches the schema location for XML schema PO4. Therefore DB2
chooses PO4 to validate the instance document. If validation with PO4 fails, DB2 uses PO2.
Example 5-13 Schema selection for validation from an XML type modifier (4 of 4)
INSERT INTO PURCHASE_ORDERS VALUES(4,
‘<purchaseOrder xmlns:xsi="[Link]
xsi:noNamespaceSchemaLocation="[Link]
...
</purchaseOrder>‘);
Note that, after you update an XML document in a column that has an XML type modifier,
DB2 validates again, all or part of the document:
If the XML type modifier includes several XML schemas, DB2 uses the same XML schema
for validation that is used for the original validation.
If you update an entire document, DB2 validates the entire document. However, if you use
the XMLMODIFY1 function to update only a portion of the document, DB2 might need to
validate only the updated portion.
Before you can invoke DSN_XMLVALIDATE, all schema documents that make up an XML
schema must be registered in the XML schema repository and successfully compiled.
You may use DSN_XMLVALIDATE with a type modifier, which can be used to override a
schema selected by DB2. DB2 checks whether the schema used in DSN_XMLVALIDATE is
one of the schemas in the type modifier, and skips the double validation.
For all forms, the first parameter contains the document that you want to validate. Note the
following information:
For forms with one parameter, the target namespace and optional schema location of the
XML schema must be in the root element of the instance document that you want to
validate.
For forms with two parameters, the second parameter is the name of the schema object to
use for validation of the document. That object must be registered in the XML schema
repository.
For forms with three parameters, the second and third parameter contain the names of a
namespace URI and a schema location hint that identify the XML schema object to use for
validation of the document. That object must be registered in the XML schema repository.
XML schemas that are used for validation are the same as shown in Figure 5-2 on page 81.
However, the following CREATE TABLE statement is used to create the table:
CREATE TABLE PURCHASE_ORDERS(
ID INT NOT NULL
CONTENT XML )
1
The XMLMODIFY function returns an XML value that might have been modified by the evaluation of an XPath
updating-expression and XPath variables that are specified as input arguments.
The DSN_XMLVALIDATE invocation does not specify an XML schema or target namespace
and schema location hint, therefore DB2 uses the information in the instance document.
The namespace name in the root element of the instance document is as follows:
[Link]
This name matches only the target namespace for XML schema PO1.
Two XML schemas, PO2 and PO4, have that target namespace. DB2 uses PO4, because it
has the later time stamp.
The DSN_XMLVALIDATE invocation does not specify an XML schema or target namespace
and schema location hint, therefore DB2 uses the information in the instance document. The
root element node in the instance document contains an xsi:noNamespaceSchemaLocation
attribute with the following value:
[Link]
Therefore, DB2 uses XML schema PO3, which has no target namespace, and the following
schema location:
[Link]
The user-defined function is deprecated. Now, DB2 uses the built-in function instead, even in
DB2 9.
XMLXSROBJECTID returns the XSR object identifier of the XML schema that was used to
validate the input XML document. The XSR object identifier corresponds to the
XSROBJECTID column in the [Link] “catalog” table. After you call
XMLXSROBJECTID, you may use the returned value to query [Link] for
the XML schema information. If the XML document has not been validated,
XMLXSROBJECTID returns a value of 0 (zero).
The SQL statement in Example 5-18 calls XMLXSROBJECTID to determine which XML
documents in the INFO column of the CUSTOMER table have not been validated. The
statement then calls DSN_XMLVALIDATE to validate those documents against XML schema
SYSXSR.P01.
The SQL statement in Example 5-19 retrieves the XML schema names and target
namespaces for the XML schemas that were used to validate XML documents in the INFO
column of the CUSTOMER table.
Example 5-19 Retrieve target namespaces and XML schema names used for validation
SELECT DISTINCT [Link], [Link]
FROM CUSTOMER C, [Link] S
WHERE XMLXSROBJECTID(INFO) = [Link]
The adoption of pureXML is likely to increase this trend. The ease of handling XML
documents in native SQL procedures, compared to external language environments, such as
COBOL, means that development productivity can be enhanced by encapsulating XML logic
within DB2 procedures and functions, so that external programs have to handle only
traditional SQL-based functions.
Native stored procedures are an excellent vehicle for capturing XML messages from
messaging infrastructure (such as WebSphere MQ and DataPower®) because they have the
following characteristics:
Productive: With them, you can encapsulate multi-step processes into a single DB2
callable routine, which supports the XML data type explicitly.
Well suited to handling XML: They can use XML documents as input and output
parameters, and manipulate XML without necessarily having to persist it to a DB2 table.
Efficient: They can parse the incoming XML document once, and re-use it as an XML data
type without re-parsing.
Well connected: They integrate well with MQ.
Native stored procedures become more powerful as a result of their support for XML. Prior to
DB2 10, a DB2 stored procedure could only pass individual data elements as parameters.
Now, the possibility exists to pass them arrays of data within an XML input parameter, which
is a more practical approach to implement large scale processing work within the DB2
subsystem, where it is most efficient.
This section shows examples of XML handling with native SQL stored procedures, and then
adds integration with WebSphere MQ.
We use the table definitions shown in Example 6-1 for the initial examples. The sample stored
procedures show techniques to validate the data manually, and also automatically, which is
why we have two versions of the audit logging table.
-- create alternate base table for ISO20022 XML documents, without validation
We are also using the ISO 20022 bank-to-customer-statement schema, which we have taken
directly from the ISO 20022 website without any alteration. We downloaded the schema to
the following location and registered the schema with name SYSXSR.SG247915_01 in the
DB2 XSR, by using the commands in Example 6-2:
D:\XMLRES\WEEK3\REDXMPL\[Link]
The commands to register schemas in the XSR are available in two environments:
z/OS UNIX System Services
DB2 for Linux, UNIX, and Windows command line processor (CLP)
They are explained in more detail in 2.1.6, “XML schema repository and schema validation”
on page 36.
Alternatively, in Example 6-2, the register xmlschema command can have the complete
clause at the end to complete the registration in the same command.
BEGIN
SET V_MSG_ID = (
xmlcast(xmlquery(
'declare default element
namespace"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
$d/Document/BkToCstmrStmt/GrpHdr/MsgId'
passing VALIDXML as "d")
as varchar(35))); 3
SET V_CREDTTM = (
xmlcast(xmlquery(
'declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
$d/Document/BkToCstmrStmt/GrpHdr/CreDtTm'
passing VALIDXML as "d")
as timestamp)); 4
SET V_MINISTMT = (
xmlquery('declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
$d/Document/BkToCstmrStmt/Stmt'
passing VALIDXML as "d")) ; 5
END !
The following notes explain each of the annotated points in the source code for the stored
procedure.
1. The parameter list includes one input parameter (data type XML) and three output
parameters (data types VARCHAR(35), Timestamp, and XML). The ability to support XML
as parameters to a callable routine is new in DB2 10.
2. This statement uses the system-provided DSN_XMLVALIDATE function to validate the
input XML document against a schema that is defined in the DB2 XSR, WITHOUT storing
the XML document in a DB2 table. (Most use cases show schema validation as part of an
SQL insert or update).
One of the strengths of the native SQL stored procedure is the ability to operate on an XML
document in memory, without storing it in a DB2 table (as performed in steps 2, 3, 4 and 5).
This ability helps the stored procedure to be efficient because it saves making unnecessary
write and read operations to a DB2 table.
This stored procedure contains XML data types that make it difficult to test from many of the
tools you might be using, because they do not have an easy way to pass XML types to and
from the procedure (such as SPUFI, DB2 command line processor and so on). A Java
program was used as a test driver to call the stored procedure from a Windows DB2 client: it
calls the stored procedure with an XML input parameter, and receives the output parameters,
and writes them to an output file. This program is called [Link], and is included
in the additional materials of this book.
This stored procedure example can be improved in several ways, which we develop in this
chapter, as follows:
No error handling logic is included within the stored procedure.
The three XMLQUERY operations can be replaced by a single XMLTABLE operation.
The previous SQL-stored procedure in Example 6-3 on page 92 has been modified to include
an XMLTABLE function (to replace the two separate XMLQUERY functions) and to include
basic error handling. The modified procedure is listed in Example 6-4 on page 94.
BEGIN
SET VALIDXML = (
DSN_XMLVALIDATE(V_BANKSTMT, 'SYSXSR.SG247915_01')) ; 3
END !
Simple native SQL procedures, such as those listed previously, can easily be coded and
tested with a text editor. More complex stored procedures can benefit from the stored
procedure development and debug capabilities of IBM Data Studio.
IBM Data Studio can be downloaded, at no cost, from the following address:
[Link]
Data Studio provides a wide range of support for developers and DBA. Specifically, with
regard to SQL stored procedures, Data Studio offers the following features:
Supports the build, test, optimization and deployment of SQL stored procedures with an
interactive routine debugger.
Provides drag-and-drop query builders with editors for SQL and SQL/XML.
Supports XML data type too.
For detailed documentation about using Data Studio for stored procedure development, see
Part 6. “Cool tools for an easier life” of DB2 9 for z/OS Stored Procedures: Through the CALL
and Beyond, SG24-7604.
In enterprises that use z/OS mainframes, WebSphere MQ commonly is the transport for XML
messages. DB2 provides a range of DB2 scalar functions and table functions for working with
WebSphere MQ. DB2 also provides the MQ listener, which receives messages from a
message queue and calls a DB2 stored procedure with the contents of the message.
The MQ functions in DB2 10 reside in schema DB2MQ and run in WLM environment
DSNWLM_MQSERIES.
To use the DB2 MQ functions within SQL statements, the MQ functions must be defined as
services to DB2. These service definitions are used to encapsulate the MQ programming
properties that MQ requires, so that the DB2 programmer can use a range of relatively simple
functions to access WebSphere MQ. The programmer simply has to use a system-provided
MQ function (such as MQSEND), in conjunction with an MQ service name.
We have defined an MQ service using the SQL insert in Example 6-5. We have not explicitly
defined an MQ service policy, which means that we can call the DB2 MQ functions without
specifying an MQ service policy, and we implicitly accept the default MQ service policy that
was defined by the installation jobs.
Actually, a more efficient way is to receive an XML document from an external source as a
VARCHAR or a CLOB if you plan to validate the document against an XML schema.
The MQ scalar functions provided by DB2 are summarized in Table 6-1 on page 97.
DB2 provides additional MQ table functions and MQ publishing functions as listed in DB2 10
for z/OS Installation and Migration Guide, GC219-2974.
Examples of the MQREAD and MQSEND functions that can be executed from SPUFI (or any
other SQL editor) are shown in Example 6-6. Several invocation parameters are optional.
-- this SQL statement returns the contents of the first message on the queue
-- referenced by the XMLS1 MQ service as a string.
select [Link]('XMLS1','<testxml><tag1>newvalue</tag1></testxml>')
from sysibm.sysdummy1
-- this SQL statement puts the simple XML string onto the queue referenced by the
-- XMLS1 MQ service as a string.
No DB2 MQ functions directly use XML data type parameters. When using functions such as
MQSEND and MQREAD to send XML documents to and receive them from MQ, the XML
document must be passed as a string data type, and then converted to XML.
XML schema validation (where automatic or using DSN_XMLVALIDATE) accepts input only in
string format. If you use XML type, DB2 must parse the XML document into internal format
during the parameter passing phase, then implicitly serialize it back to string before validation,
which is slower.
BEGIN
DECLARE OUTPUTMQ CLOB ;
DECLARE VALIDXML XML ;
DECLARE MQSVC CHAR(5) ;
DECLARE SQLCODE INTEGER ;
SET MQSVC = 'XMLS1' ;
SET VALIDXML = (
SELECT DSN_XMLVALIDATE(OUTPUTMQ, 'SYSXSR.SG247915_01')
FROM SYSIBM.SYSDUMMY1 ) ; 2
END !
The stored procedure was written to read the first message only from the message queue,
and process it. In practice, however, you modify the stored procedure to call the
[Link] function, so as to receive the message from the queue, and remove it
within the unit of work that is controlled by the DB2 stored procedure.
After installing the MQ listener, it must be configured and started. The UNIX System Services
command to configure the MQ listener to listen on an input queue, is shown in Example 6-8.
In this example, we define a two-phase commit MQ listener process (db2mqln2 command
implies this) in DB2 subsystem DB0B to listen to the MQL.INPUT01 queue in Queue
Manager MQBA and to call the XMLR3.STOREXML4 procedure when a message is
received. The configuration is stored under the label XML1.
returns:
configurationName: XML1
queueManager: MQBA
inputQueue: MQL.INPUT01
procSchema: XMLR3
procName: STOREXML4
numInstances: 1
mqCoordinated: T
The underlying DB2 table that stores the MQ listener configuration data is
[Link], which is shown in Example 6-10.
CONFIGURATIONNAME = XML1
QUEUEMANAGER = MQBA
INPUTQUEUE = MQL.INPUT01
PROCNODE =
PROCSCHEMA = XMLR3
PROCNAME = STOREXML4
PROCTYPE = 1
NUMINSTANCES = 1
WAITMILLIS = 50
MINQUEUEDEPTH = 1
For a stored procedure to be able to work with the MQ listener, it must be coded with INPUT
and OUTPUT characters that may only be VARCHAR, VARBINARY, BLOB or CLOB. The
stored procedure to read an XML message from a message queue, listed in Example 6-7 on
page 98, can be modified to work with the MQ listener by making a few small edits, as shown
in Example 6-11.
BEGIN
DECLARE OUTPUTMQ CLOB ;
DECLARE VALIDXML XML ;
DECLARE MQSVC CHAR(5) ;
DECLARE SQLCODE INTEGER ;
END !
The listener can be operated with the commands, as shown in Example 6-12.
db2mqln2 admin
-adminQueue MQL.INPUT01
-adminQMgr MQBA
-adminCommand shutdown
The previous examples show how native stored procedures can be integrated with
WebSphere MQ to receive XML messages, process them, and log them to DB2.
You do not necessarily need any special XML-enabled query tools to develop and run audit
queries. The reason is because the SQL/XML language provides a range of functions to
search within the XML documents for data of interest, without materializing XML structures
that the query tool has to handle.
If you do have an XML-enabled query tool, SQL/XML can of course return the results of
queries as XML documents. The examples that follow include a mixture of both.
The first several examples in this section include screen captures from Optim Development
Studio. This tool choice is outlined in 2.3.2, “GUI-based tools” on page 45, which provides you
with an idea of the interface style of the Optim Development Studio tool.
First, we look at the entire table. Figure 6-1 shows the Optim Development Studio being used
to execute the following statement:
SELECT * FROM BK_TO_CSTMR_STMT
The query was executed through Optim Development Studio, which includes the following
panes:
The top pane is the project explorer, where we save our source code such as SQL
statements and stored procedures.
The bottom left pane shows database connection, in this case, to DB0B.
The middle top pane shows the SQL statement, which we can run from the action bar.
The bottom right pane shows the results of the SQL statement.
The table contains the XML documents that we received from MQ, and the two fields that we
stripped out using XMLQUERY and XMLTABLE functions in the stored procedure examples.
Optim Development Studio also provides an XML document viewer. Click any of the
BK_TO_CSTMR_STMT XML documents in the results pane to browse the contents of the
XML document, and drill down to look at specific element and attribute values at any level
within the XML document. The contents of the first XML document (MSG_ID
AAAASESS-FP-STAT001) are illustrated in Figure 6-2.
Figure 6-2 Optim Development Studio XML document viewer: Design view
Figure 6-2 shows that we have expanded the values of several data elements in the GrpHdr
node. It also shows that the statement node in this particular message has four Ntry
elements, each representing a credit or debit transaction on the account, during the period
covered by this statement. We can use this viewer to drill down and examine each element in
the XML document.
Figure 6-3 Optim Development Studio XML document viewer: Source view
Conceptually, the information in this XML document is the same as what you see in your
monthly account statement from your own bank, but it looks different in XML format.
Therefore, how easy is it to use SQL/XML to query the document and provide a more
commonly recognizable view of the data?
The XMLTABLE function is designed for transforming elements from an XML document into a
tabular view, similar to your monthly bank statement. The SQL/XML query in Example 6-13
on page 105 retrieves all the debit and credit transactions from the XML document in a
tabular format that looks much more like a traditional bank statement.
The highlighted numbers of the SQL/XML query in Example 6-13 are explained as follows:
1. We select three data elements from the XML document, which are the transaction
timestamp, transaction amount, and credit/debit indicator of each transactional entry in the
BK_TO_CSTMR_STMT XML document. Additionally, we take the statement message_id
and statement date from the base table.
2. As always, we must specify the correct namespaces in the XQuery expression.
3. Important: We must specify the node within the XML document on which the XMLTABLE
function is operating. Usually this is at the node where we want to extract the detailed
information. In this case, we base it on the Ntry node, because we want to retrieve a
separate row in the result set for each transactional entry in the XML document.
4. Because we are focussing this query on a single XML document, we use a predicate on
the base table column to return data from only the document with MSG_ID of
AAAASESS-FP-STAT0001.
5. Finally, we can order the result set by using either a relational column or an XML data
element. In this case, we want to order the result set by the booked transaction date of
each Ntry node in the XML document.
The results are displayed in Figure 6-4. Note that all returned rows contain the same values
for columns from the base table (relating to the bank statement XML document) but unique
values for the columns relating to individual entries from the document.
The contents of XML data from multiple documents can be returned in a single relational
result set, as show by the SQL/XML statement in Example 6-14 on page 106, which retrieves
The results of the query in Example 6-14 are shown in Figure 6-5.
Figure 6-5 Relational result set spanning data elements from multiple XML documents
A wider range of SQL/XML query techniques that use all the DB2 XML functions is described
in 6.4, “SQL/XML query techniques” on page 109.
As the XML audit database grows in size, the need for XML indexes becomes clear. Each
SQL/XML query in 6.3.1, “Simple SQL/XML search examples” on page 102 is considered,
and candidate XML indexes are identified. Chapter 11, “Performance considerations” on
page 247 covers XML index design.
We consider XML index design for the specific purpose of enabling efficient search with an
audit database of bank statements.
We assume that a primary purpose of the audit database is to analyze data at the individual
banking transaction level. That means that the focus of many queries will be the Ntry nodes in
these XML documents. Figure 6-6 shows the typical data elements within an Ntry node.
The corollary of the previous statement is that the XML schemas must place data type
constraints on fields that might be indexed, and the XML documents are validated against
their schema definition. This way is the best for ensuring that effective indexes can be defined
on XML columns.
The simplest way of checking that an Index will be effective is to run RUNSTATS and check
the values of FIRSTKEYCARDF and FULLKEYCARDF in [Link]. If you
know the number of rows in the table, and you have a reasonable expectation of the average
number of XML index hits per XML document, you will have an approximate idea of what the
value of FULLKEYCARDF should be. For example, if you have one million rows in the
BK_TO_CSTMR_STMT table, and an average of 20 Ntry nodes per XML document, you
might be expecting FULLKEYCARDF to be about 20 million. Of course it may be less if the
same values of AcctSvcrRef appear many times, but at least you can make a judgement on
whether the Index has found approximately the correct number of data elements to index.
If an XML index has cardinality of 0, determine why the index did not find any matching data
elements to index. The most likely reasons are a typographical error in the XMLPATTERN, or
the namespace definition, or a data type mismatch.
After you determine that the index has approximately the correct number of entries in it, you
must test your application SQL to determine whether the optimizer will use the XML index.
We did not need to extract XML data elements from the XML documents to build relational
searching columns. The only reason we chose to use the DB2 XML functions to extract
selected data elements is to show the ease of moving data between XML and relational.
The only difficult tasks we have had to do is to understand the concepts of the XML model of
data, and the SQL/XML extensions to the SQL language.
This section provides some sample SQL/XML audit queries to illustrate the various functions
and techniques for querying XML data and how to combine them.
Additionally, constructor functions for each XPath data type are available. Examples of these
are xs:string and xs:date. The namespace for these functions is as follows and xs is the
prefix:
[Link]
For more information about the available XPath functions, see the following address:
[Link]
l/db2z_xpxqfunctionreference.htm
If you want to calculate the sum of all entries in a bank statement, you may use the fn:sum
function as shown in Example 6-16.
The result of the XMLQUERY call is cast as DECIMAL(12,2) by using the XMLCAST function.
Otherwise, the result of the query would have had type XML, although we know that the
content is really numeric. To process the data further by using arithmetic functions,
comparisons, or simply return it as a numeric value, we need to perform this conversion.
The use of the XMLCAST function requires that the input is a sequence of one item. If the
result of the XMLQUERY expression is a longer sequence or an empty sequence, the
XMLCAST function returns an error, SQL code -16003. In this example, we know that the
sequence has exactly one element, because the fn:sum function is applied to all the Amt
elements so it cannot be longer than one, and the result of applying fn:sum to an empty
sequence is 0 (zero), so it always returns a result.
The XMLCAST function can also be used to strip any element tags if the result is a simple
element.
In another example of applying XPath functions, we consider several available date functions.
Date and time functionality has been included in DB2 XPath with version 10 because the
functionality is an important aspect of most business applications.
You might want to select all the entries from a BankToCustomerStatement that were made in
the last month. To create an XPath expression that does that, use the subtraction function for
datetime, which is written as a minus sign (-), and the two constructor functions xs:dateTime
and xs:yearMonthDuration. The result is shown in Example 6-17 on page 111.
The predicate says that the DtTm element must be greater than current timestamp minus one
month, where the current timestamp is given as a parameter in the passing clause, and where
both this parameter and the one month constant is created using constructor functions. The
predicate is applied to each Ntry element in the document, and when evaluated to true, the
Ntry element will be included in the result. The reason is because even though we reference
the elements BookgDt and DtTm, these are only part of the predicate and not of the path that
we have selected.
To return only the rows that actually has some contents, we can apply the same filtering
predicate in the where clause through the function XMLEXISTS. This function returns false for
an empty sequence and true for everything else. It has the same syntax as XMLQUERY.
Note: A predicate must always be in square brackets. If the brackets are omitted, the result
of the XPath expression is either true or false.
Both true and false are non-empty sequences and can cause the XMLEXISTS expression
to evaluate to true, thus returning all rows in the table.
Example 6-19 shows that XMLELEMENT is used to create an outermost element with name
results, and XMLDOCUMENT to create a document from this element.
The result from this query is an XML document for each Bank To Customer Statement that
had any entries the last month, containing these entries.
For more information about the use of publishing functions, go to the following addresses:
[Link]
ml/db2z_publishfuncs.htm
[Link]
In this case, we must be able to create new XML elements across existing XML documents,
and that is exactly what is offered by the XMLAGG publishing function. This function can take
any number of XML values and create a sequence from them. It is an aggregate function in
the same manner as the SQL functions AVG and MIN, so it is applied to all values from all
rows in the select statement.
Example 6-20 shows how to combine Example 6-19 on page 112 with the XMLAGG function
to collect all the entries in one XML document.
Example 6-20 Using XMLAGG to consolidate all entries into one document
SELECT
XMLDOCUMENT(
XMLAGG (
XMLELEMENT(NAME "results",
XMLQUERY (
'declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
Document/BkToCstmrStmt/Stmt/Ntry
[BookgDt/DtTm>xs:dateTime($tm)-xs:yearMonthDuration("P1M")]'
PASSING BK_TO_CSTMR_STMT, CURRENT TIMESTAMP AS "tm"
)
)))
FROM BK_TO_CSTMR_STMT
WHERE XMLEXISTS (
'declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
Document/BkToCstmrStmt/Stmt/Ntry
[BookgDt/DtTm>xs:dateTime($tm)-xs:yearMonthDuration("P1M")]'
PASSING BK_TO_CSTMR_STMT, CURRENT TIMESTAMP AS "tm"
)
Although we no longer get any rows that contain empty sequences because all the Ntry
elements are collected into one document, we still include the XMLEXISTS predicate to allow
for index access.
The row XPath expression returns a sequence of items, each producing a row in the result
table of the XMLTABLE function. If the row XPath expression points to an element, the
Using the row XPath expression as a starting point, one or more column XPath expressions
define the contents of the columns that are returned from the XMLTABLE function. Associated
with each is a data type and a name that can be used in the surrounding select statement.
Example 6-21 shows how to use XMLTABLE to extract all the entries no more than a month
old, returning one row per entry. We use only one XPath column expression ('.'), which
effectively returns the contents of the row XPath expression. This Ntry element is returned
with data type XML and subsequently made into an XML document by using the
XMLDOCUMENT publishing function.
We have now abandoned the XMLEXISTS predicate in the WHERE clause. The row XPath
expressions of an XMLTABLE function is a candidate for index access, so the XMLEXISTS
predicate can yield exactly the same result and is no longer needed.
More information and examples about using the XMLTABLE function is at the following
address:
[Link]
For each of the resulting documents we need entries from several of the original documents,
but assuming that it is possible to make entries in different currencies to the same account,
we cannot be sure that all entries from one account or indeed one
BankToCustomerStatement will go into the same result document.
This can be obtained by combining the XMLTABLE function from Example 6-21 with column
grouping, XMLAGG and publishing functions XMLELEMENT and XMLDOCUMENT. The
query is shown in Example 6-22 on page 115.
We have added another column XPath expression to obtain the currency from the entry, and
the result is grouped according to this currency. We then apply the XMLAGG function to the
resulting entries, and wrap these in an element named Result, which is then given as input to
the XMLDOCUMENT function to produce an XML document.
Each of the three UDFs encapsulates XQuery functions to return a separate data type to the
SQL programmer. Example 6-24 shows how these functions can be used in standard SQL.
The results of the UDF-based query in Example 6-24 are shown in Figure 6-7.
Example 6-25 Modified stored procedure using UDFs instead of XQuery expressions
CREATE PROCEDURE STOREXML5 (
IN V_BANKSTMT XML,
OUT V_MSG_ID VARCHAR(35),
OUT V_CREDTTM TIMESTAMP,
OUT V_MINISTMT XML)
LANGUAGE SQL
MODIFIES SQL DATA
DISABLE DEBUG MODE
BEGIN
SET VALIDXML = (
SELECT DSN_XMLVALIDATE(V_BANKSTMT, 'SYSXSR.CAMT_053_001_02');
SELECT
getmsgid(BK_TO_CSTMR_STMT),
getcredttm(BK_TO_CSTMR_STMT),
getministmt(BK_TO_CSTMR_STMT)
into V_MSG_ID, V_CREDTTM, V_MINISTMT from BK_TO_CSTMR_STMT;
END !
UDFs for XML are a great way to take advantage of DB2’s pureXML capabilities, without
necessarily exposing the SQL programmers to the full complexity of XQuery expressions.
Example 6-26 on page 118 illustrates a UDF that inserts a new XML node into an XML
document.
Triggers can be used on tables with XML columns. However, the new and old values of XML
columns are not available as transition variables to the trigger routine body.
In summary, you can continue to write triggers with tables that have XML columns. However,
if you want to reference the contents of an XML column, you must reread the XML data by
using one of the relational columns that are available as a transition variable.
The ISO 20022 sample XML messages that we are using all relate to an account called
FINPETROL. The account name is stored at the following XPath location:
/Document/BkToCstmrStmt/Stmt/Acct/Ownr/Nm
There are many ways to perform an XML to relational join in SQL/XML. One approach is to
use the XMLEXISTS function (which is indexable). A very simple join statement is illustrated
in Example 6-28. The join is achieved by passing the relational column for the join
([Link]) to the XMLEXISTS function as a variable that is then used as an XML
predicate.
--yields
-- yields
The relational address table is converted to XML using the script in Example 6-30.
-- yields
CUSTADDR
--------------------------------------------------------------------
<MsgRcpt><Nm>FINPETROL</Nm><PstlAdr><StrtNm>Bailey
Avenue</StrtNm><BldgNb>555</BldgNb><PstCd>95141</PstCd><TwnNm>San
Jose</TwnNm></PstlAdr></MsgRcpt>
<MsgRcpt><Nm>WINGPETROL</Nm><PstlAdr><StrtNm>Bond
Street</StrtNm><BldgNb>23</BldgNb><PstCd>98282</PstCd><TwnNm>New
York</TwnNm></PstlAdr></MsgRcpt>
<MsgRcpt><Nm>TAILPETROL</Nm><PstlAdr><StrtNm>Southfork</StrtNm><BldgNb>1</BldgNb><
PstCd>99999</PstCd><TwnNm>Dallas</TwnNm></PstlAdr></MsgRcpt>
Having converted the address table to XML, we can now code XML to XML joins.
Example 6-31 on page 121 shows the use of an XMLEXISTS function to join the two tables.
In this example, we must pass both XML documents ("i" and "j") into the XMLEXISTS
function to perform the comparison.
The XML string function is used with the current location to signify that we want to perform a
string comparison to join the current contents of one location in one document with the
current contents of another location in the other document. The specification of the data type
being used in the join comparison is important for the following reasons:
Unlike relational columns, the XML fields do not have types defined.
Index eligibility is dependent on the data type.
Example 6-31 was created to illustrate the mechanics of an XML to XML join as clearly as
possible. This query does not contain any filter predicate that is indexable. However, the join
predicate is eligible for index access because it has been expressed with the string() function,
which is indexable.
Similarly, if you have XML to XML join on a numeric field, use xs:double so that an XML
DECFLOAT index can be used for the join predicate.
Another common source of XML messages is the range of replication and event publishing
tools that are used to capture changes from existing database, and publish change data
capture (CDC) messages. The published messages can sometimes be used to replicate
changes to another database (such as a data warehouse). Increasingly, CDC messages are
commonly being used in event-driven systems. Changes to source data, which meets certain
criteria (such as bank transfers that exceed a threshold value), can be routed to a workflow
system (such as WebSphere Message Broker) where the CDC event can be examined by
using workflows that implement business processes, and initiate automated actions.
This section considers ways in which CDC messages can be handled by DB2 pureXML.
IBM replication and event publishing tools that publish XML CDC messages include the tools
listed in Table 6-3 on page 122. In the table, LUW stands for Linux, UNIX, and Windows.
InfoSphere Data DB2 for z/OS Offers asynchronous log reader services
Event Publisher DB2 for LUW Writes CDC messages as XML (and other formats)
Oracle Publishes messages directly to WebSphere MQ
Is available for z/OS and LUW versions
InfoSphere Change DB2 for z/OS Offers asynchronous log reader services
Data Capture DB2 for LUW Writes CDC messages as XML (and other formats)
DB2 for iSeries® Source server writes CDC data over tcpip to a target server.
Oracle Target server writes messages to a range of targets, including
Sybase WebSphere MQ and files
SQL Server Is available for z/OS and LUW versions
The purpose of this section is to focus on the XML messages that are published from these
tools, and examine how they can be used with DB2 pureXML.
InfoSphere Data Event Publisher and InfoSphere Classic Data Event Publisher both share a
common schema and generate messages similar to the one in Example 6-32.
Example 6-32 XML CDC message format for DB2 and Classic Data Event Publishers
<?xml version="1.0" ?>
<msg xmlns:xsi="[Link]
xsi:noNamespaceSchemaLocation="[Link]"
version="1.0.0" dbName="$IMS "
seqNum="IMS000003B4009FF00AIMSY _8"> 1
<rowOp authID="USER0000"
planName="USER0000"
cmitLSN="IMS000003B4009FF00AIMSY "
cmitTime="2010-11-[Link].374839"> 2
<insertRow subName="CLASSIC" srcOwner="IMSP" srcName="CLASSIC1"> 3
<col name="STRTNM" isKey="0"> 4
<char>Bailey Avenue</char>
</col>
<col name="BLDGNB" isKey="0">
<char>555</char>
</col>
<col name="PSTCD" isKey="0">
<char>95149</char>
</col>
<col name="TWNNM" isKey="0">
<char>San Jose</char>
</col>
</insertRow>
</rowOp>
</msg>
InfoSphere CDC offers the choice of a range of XML schemas for publishing change data
messages. Example 6-33 shows an SQL update of a simple InfoSphere CDC XML message.
Based on the XML examples presented in the previous sections in this chapter, these CDC
XML messages look fairly straightforward to handle.
Another potential use for CDC messages is to maintain a historical record of changes to
operational data. We expand this idea in 6.8.3, “XML history objects” on page 129.
For now, we examine how to consume a stream of XML CDC messages with DB2 pureXML.
We could use a mixture of all the programming constructs that we have illustrated in this
chapter so far to receive CDC XML messages into DB2 pureXML storage, as illustrated in
Figure 6-8 on page 124.
cdcmsg (xml)
Stored Procedure:
Figure 6-8 Scenario to receive XML CDC messages into DB2 pureXML through MQ
Previously in this chapter, We describe the mechanics of receiving XML messages from
WebSphere MQ. The requirements are more complex if we want to update a historical audit
record.
Figure 6-9 on page 125 shows the contents of the XML historical record before the CDC
record is applied. Fictional customer John Doe, with customer number CUST1 has a record of
two nominated email addresses (one expired, one active) and only one postal address (which
is active). If we receive a CDC message containing a change of address, we must set an
ending date in the node for the current postal address, and add a new node for the new
address.
If we receive the CDC message in Example 6-33 on page 123, we must write a procedure
that performs the following steps:
1. Examine the contents of the XML CDC record to find the customer identifier key.
2. Use the customer identifier key to retrieve the XML document that stores the historical
record of customer address changes.
3. Update the XML node in the document that stored the current address details, to set an
end date for that address.
4. Insert a new node in the XML document to reflect the new address details.
The stored procedure in Example 6-34 on page 126 receives the XML CDC message from
MQ (in the format of the InfoSphere CDC example), and updates the historical record of
changes in DB2. Although this stored procedure picks up the CDC message from a test table,
MQ examples earlier in this chapter show how to adapt the procedure to work with
WebSphere MQ.
BEGIN
UPDATE CUST_HISTORY X
SET X.CUST_HISTORY_OBJECT = XMLMODIFY(
'replace node
/CustomerHistory/DB2CustomerDB/customer_identification/addresses/address[
address_effective_from=$t]
with $V',
PREV_MAX_ADDR AS "V",
V_ADDR_FROM as "t" )
where CUSTID = 'CUST1' ; 6
UPDATE CUST_HISTORY X
SET X.CUST_HISTORY_OBJECT = XMLMODIFY(
'insert node $new as last into
/CustomerHistory/DB2CustomerDB/customer_identification/addresses',
NEXT_MAX_ADDR as "new" )
where CUSTID = 'CUST1' ; 7
END !
The logic of the stored procedure is as follows, with the annotated points from Example 6-34
on page 126.
1. The stored procedure accepts the CDC message as an XML document in INPUT
parameter CDCDOC.
2. The data elements of the incoming CDC message are stripped with a single XMLTABLE
function.
3. Using the customer ID (‘CUST1’) from the CDC document, the current address node is
retrieved from the CUSTOMER_HISTORY table.
4. A replacement XML node is derived for the current address node, using XML publishing
functions.
5. A new XML node is derived from the incoming CDCDOC.
6. The existing XML node that is storing the current address is replaced by using an
XMLMODIFY function.
7. The new XML node is inserted by using a further XMLMODIFY function.
PREV_MAX_ADDR and NEXT_MAX_ADDR are kept as XML types because they will be
used in XMLMODIFY later, therefore avoiding an XMLPARSE() method.
<addresses>
<address>
<address_effective_from>2008-07-18T[Link].000000+01:00</address_effective_from>
<address_effective_to>2010-11-08T[Link].602776-05:00</address_effective_to>
<PstlAdr>
<StrtNm> Bailey Avenue </StrtNm>
<BldgNb> 555 </BldgNb>
<PstCd> 95141 </PstCd>
<TwnNm> San Jose </TwnNm>
</PstlAdr>
</address>
<address>
<address_effective_from>2010-11-08T[Link].602935-05:00</address_effective_from>
<address_effective_to/>
<PstlAdr>
<StrtNm> Nice Street </StrtNm>
<BldgNb> 100 </BldgNb>
<PstCd> 98282 </PstCd>
<TwnNm> San Diego </TwnNm>
</PstlAdr>
</address>
</addresses>
Figure 6-10 Updated CUST_HISTORY table contents for ‘CUST1’
If you use the InfoSphere Data Event Publisher or Classic Data Event Publisher products, the
XML schema differs, although the technique is the same. All you need to do is replace the
XMLTABLE operation on the incoming XML CDC document with a separate XMLTABLE
operation, shown in Example 6-35, to work with the incoming schema.
Note: Apply the program temporary fix (PTF) for APAR PM28385 (currently open) for the
most recent maintenance that is related to XMLTABLE function.
Bitemporal data
Before examining XML support for temporal data, we first investigate another DB2 10
capability that supports the storage of historical data and the execution of temporal queries
against that data: bitemporal data.
The concept of bitemporal data is that four more columns (timestamp data type) are added to
tabular data, reflecting the starting and ending points of system time and business time:
System time is an auditable history of what the data looked like in the system at any point
in history.
Business time is an auditable history of the data, which reflects business corrections.
Bitemporal data support is a productivity feature of DB2 that can be used to maintain an
auditable history of changes over time. Whenever a change is made to a table with bitemporal
data support, the system time and the business time are both automatically tracked to
maintain that auditable history.
Bitemporal data is not explained in any more detail in this book, because it is covered in other
DB2 10 publications. For new DB2 systems, particularly for the relational data model,
bitemporal data probably is the most productive way of supporting temporal data, because
the data structures and programming interface have all been designed into DB2. Also, the use
of bitemporal data in conjunction with XML is fully supported.
The value of XML for historical data is broadly acknowledged as powerful and efficient. The
paper XML-Based Support for Database Histories and Document Versions by Fusheng
Wang, 2004, describes an XML model for storing historical data, and supporting temporal
queries. It is available at the following address:
[Link]
Building XML History Objects from change data capture data streams
Most legacy data sources have been defined without system-provided temporal data support
because bitemporal data is new in DB210 for z/OS.
Many transactional database systems are focussed almost exclusively on the current state of
the data that they store, and might not have much support for historical data. This scenario is
common and often leads to a decision to deploy a data warehouse (which is derived from the
data in the transactional system) for the purpose of storing historical data and performing
trend analysis to see how data has changed over time.
CDC and replication products are often used as a vehicle to feed changes to data
warehouses. The CDC data streams contain details of what the data changes were, and
precisely when they happened, usually as a commit timestamp from the log record on the
source system. This temporal reference data can be used by the extract, transform, and load
(ETL) processes that maintain the data warehouse, to build a record of historical changes in
the target data warehouse.
DB2 pureXML could act as a repository for historical data, with temporal query support as in
Figure 6-11.
DB2
IMS Accounts VSAM Terms DB2 Cust Oracle WebCust
Temporal Queries
In this chapter, we show how JDBC applications handle XML data in DB2 for z/OS, based on
a scenario that uses the ISO 20022 BankToCustomerStatement message.
The description of the application scenario is in Chapter 3, “Application scenario” on page 47.
All Java examples are available for download as additional material. See Appendix B,
“Additional material” on page 277.
The Java programming language and its database interface JDBC are popular choices for
XML application development. DB2 for z/OS provides a universal driver that supports both the
JDBC and the SQLJ interface of the Java language. This driver is the IBM Data Server Driver
for JDBC and SQLJ, also known as Java Common Client (JCC). It supports JDBC type 2 and
type 4 driver and can connect to the DB2 family of products and Informix® Dynamic Server
database systems.
Two versions of the IBM Data Server Driver for JDBC and SQLJ are available:
Version 3.x, JDBC 3.0-compliant
Version 4.x, JDBC 4.0-compliant
Table 7-1 summarizes the Java interfaces for XML data type support.
You control the level of JDBC support by specifying the appropriate set of files in the
CLASSPATH. For example, if you want to use the JCC 4.x driver, include
lib_dir/[Link] and lib_dir/[Link] files in your CLASSPATH.
JDBC3.0 provides basic methods to retrieve an XML document as Bytes, String, or Stream,
or set the XML document from Bytes, String, or Stream. IBM Data Server Driver for JDBC and
SQLJ 3.x also supports DB2Xml interfaces for XML processing.
JDBC4.0 introduces the SQLXML Java data type, which you use to map an XML data type
table column to a Java data type. Use IBM Data Server Driver for JDBC and SQLJ 4.x, the
getBytes Retrieves the value of the designated column in the current row of this
ResultSet object as UTF-8 encoded bytes.
getString Retrieves the value of the designated column in the current row of this
ResultSet object as a string in the Java programming language.
getAsciiStream Retrieves the value of the designated column in the current row of this
ResultSet object as a stream of ASCII characters.
getBinaryStream Retrieves the value of the designated column in the current row of this
ResultSet object as a UTF-8 encoded binary stream.
getCharacterStream Retrieves the value of the designated column in the current row of this
ResultSet object as a [Link] object.
getObject Retrieves the value of the designated column in the current row of this
ResultSet object as a [Link].DB2Xml object.
Note: The methods in Table 7-2 do not add an encoding declaration to the retrieved XML
data.
The getObject method retrieves XML data into an object of type DB2Xml, which provides
more getter methods. The [Link].DB2Xml object supports the methods that are
listed in Table 7-3.
getDB2Bytes() Retrieves the value of the designated column in the current row of
this ResultSet object as UTF-8 encoded bytes.
getDB2XmlBytes() Retrieves the value of the designated column in the current row of
this ResultSet object as a byte array in the Java programming
language. The method converts the bytes to the target encoding
and adds XML declaration with encoding tag.
getDB2String() Retrieves the value of the designated column in the current row of
this ResultSet object as a string in the Java programming
language.
getDB2XmlString() Retrieves the value of the designated column in the current row of
this ResultSet object as a string in the Java programming
language. The method adds an XML declaration with the
"ISO-10646-UCS-2" encoding tag.
getDB2AsciiStream() Retrieves the value of the designated column in the current row of
this ResultSet object as a stream of ASCII characters.
getDB2XmlAsciiStream() Retrieves the value of the designated column in the current row of
this ResultSet object as a stream of ASCII characters. The method
will add XML declaration with encoding tag
getDB2BinaryStream() Retrieves the value of the designated column in the current row of
this ResultSet object as a UTF-8 encoded binary stream.
getDB2XmlBinaryStream() Retrieves the value of the designated column in the current row of
this ResultSet object as a binary stream. The method converts the
bytes to the target encoding and adds the XML declaration with
encoding tag.
getDB2CharacterStream() Retrieves the value of the designated column in the current row of
this ResultSet object as a [Link] object
getDB2XmlCharacterStream() Retrieves the value of the designated column in the current row of
this ResultSet object as a [Link] object. The method
adds an XML declaration with "ISO-10646-UCS-2" encoding tag.
The getDB2XmlXXX methods generate XML declarations with an encoding attribute for the
retrieved XML data. For example, the getDB2String() and getDB2XmlString() methods return
the XML data in the same encoding, USC-2, however the latter adds the appropriate
encoding declaration to the XML document.
In a JDBC application, you can update or insert data into XML columns of a table at a DB2
data server using one of the setter methods of the PreparedStatement interface.
The following setXXX methods are supported against XML columns in JDBC 3.0:
setAsciiStream()
setBinaryStream()
setBlob()
setBytes()
setCharacterStream()
setClob()
setString()
setObject()
This method supports DB2Xml, String, byte[], InputStream, Reader, CLOB, and BLOB as
parameters.
The SQLXML interface provides methods, listed in Table 7-4, for retrieving XML data from an
SQLXML object.
getSource(Class<T> sourceClass) Returns a source for reading the XML value designated by this
SQLXML instance.
The SQLXML interface provides methods, listed in Table 7-5, for setting XML data to a JDBC
object.
setBinaryStream() Retrieves a stream that can be used to write the XML value
that this SQLXML instance represents.
setCharacterStream() Retrieves a stream to be used to write the XML value that this
SQLXML instance represents.
setResult(Class<T> resultClass) Returns a Result for setting the XML value designated by this
SQLXML instance.
void setString(String value)
For the implementation of the BankStmt application in Java, we mostly use the JDBC 4.0
standard SQLXML object in our programming.
The code for constructing XML as a DOM tree is shown in Example 7-2.
DocumentBuilderFactory factory =
[Link]();
try{
DocumentBuilder builder = [Link]();
Document document = [Link](); 1
//************************************************************************
// Create element nodes
//************************************************************************
Element GrpHdr = [Link]("GrpHdr"); 2
Element MsgId = [Link]("MsgId");
Element CreDtTm = [Link]("CreDtTm");
Element MsgPgntn = [Link]("MsgPgntn");
Element PgNb = [Link]("PgNb");
Element LastPgInd = [Link]("LastPgInd");
//************************************************************************
// Create text nodes with designated values
//************************************************************************
Text MsgIdValue = [Link](MsgIdStr); 3
Text CreDtTmValue = [Link](CreDtTmStr);
Text PgNbValue = [Link](PgNbStr);
//************************************************************************
// Append text node under element nodes
//************************************************************************
[Link](MsgIdValue); 4
[Link](CreDtTmValue);
[Link](PgNbValue);
[Link](LastPgIndValue);
//************************************************************************
// Construct the DOM tree
//************************************************************************
[Link](PgNb); 5
[Link](LastPgInd);
[Link](MsgId);
[Link](CreDtTm);
[Link](MsgPgntn);
[Link](GrpHdr);
}catch (Exception e) {
[Link]("Some exception occur: " +
[Link]());
}
Note:
[Link] a new instance of a DOM Document object to build a DOM tree
[Link]() method to create element nodes with specified tagName
[Link]() method to create text nodes with designated values
[Link]() method to append text node under element nodes
[Link] element nodes and construct the DOM tree
The IBM Data Server Driver for JDBC and SQLJ can send XML data to the data server or
retrieve XML data from the data server as textual XML data or binary XML data, as shown in
Figure 7-1 on page 138.
1 [Link]
DB2
(XML stored format
in the tables)
Binary XML
I3foo1I3bar2m12
X4root300
X6Person400X4name500Y3mgr6002NOT4BillzX3age712T235zz
e4e5a62NOT3Joezx712T245zz
zZ
You may set the JCC data source property, xmlFormat, to control whether the data format is
textual XML format or binary XML format. Possible values are as follows:
[Link].DB2BaseDataSource.XML_FORMAT_NOT_SET
Specifies that binary XML format is used if the data server supports it. If the data server
does not support binary XML format, textual XML format is used, which is the default.
[Link].DB2BaseDataSource.XML_FORMAT_TEXTUAL
Specifies that the XML textual format is used.
[Link].DB2BaseDataSource.XML_FORMAT_BINARY
Specifies that the binary XML format is used.
To change the XML format, set the data source property first, then get a new connection,
which will pick up your setting. Example 7-3 shows the Java code for setting xmlFormat.
Storage and retrieval of binary XML data requires the IBM Data Server Driver for JDBC and
SQLJ version 4.9 or later. If you use the DB2 Client, V9.7 Fix Pack 3a and later provides this
support.
The format of XML data is transparent to the application. The IBM Data Server Driver for
JDBC and SQLJ presents binary XML data to the application only through the XML object
interfaces. The user does not see the data in the binary XML format.
Chapter 3, “Application scenario” on page 47 presents a scenario to log and store the
message for auditing purposes. The diagram in Figure 3-2 on page 51 illustrates the flow
between the various code samples presented in this book.
In our Java application, we retrieve, manipulate, and resave those XML documents in DB2,
shred the previously saved XML message (see 7.2.5, “Call stored procedure to shred XML”
on page 147), and query the message to produce an XML document to send out through an
MQ message. The display of this data is generated by combining the XML output with an
XSLT file to produce an new HTML or XML display.
The purpose of the Java application is to demonstrate how to use Java with DB2 pureXML
and we have chosen to just emphasize the steps and choices made that are related to XML,
disregarding irrelevant code and components.
To run the BankStmt application, set up the IBM Data Server Driver for JDBC and SQLJ
version 4.9 or later on your client. If you use the DB2 Client, V9.7 Fix Pack 3a and later
provides this driver. To verify the driver version you have, run the following command in your
command window:
java [Link].DB2Jcc -version
try {
ds.deregisterDB2XmlObject(
"SYSXSR", NameSchema);
}
catch (SQLException e) {}
[Link]("deregister complete");
//************************************************************************
//register the XML schema
//************************************************************************
// Schema Name Qualifiers, always this one, or blank which will default to SYSXSR
xmlSchemaNameQualifiers[0] = "SYSXSR";
// Schema Name
xmlSchemaNames[0] = NameSchema;
ds.registerDB2XmlSchema(
xmlSchemaNameQualifiers,
xmlSchemaNames,
xmlSchemaLocations,
xmlSchemaDocuments,
xmlSchemaDocumentsLengths,
xmlSchemaDocumentsProperties,
xmlSchemaDocumentsPropertiesLengths,
xmlSchemaProperties,
xmlSchemaPropertiesLength,
false);
The DDL for the table is in Example 7-5. The values of MSG_ID and MSG_CRE_DT_TM
columns come from the XML document itself. The corresponding XML element name is
MsgId (Message Identification), CreDtTm (Creation Date Time) in Group Header of the XML
document.
The XML documents can be validated either explicitly by using the DSN_XMLVALIDATE
built-in function, or you can automate XML schema validation by adding an XML type modifier
to an XML column definition. This approach is described in Chapter 5, “Validating XML data”
on page 75. In this chapter, we show the validation through DSN_XMLVALIDATE function.
Because Java provides various XML Parser APIs to parse XML documents, shredding out
useful information from XML data and inserting it into DB2 can be easy to do.
Example 7-6 on page 142 shows that we read the XML document from a file, parse it, get the
MSG_ID and MSG_CRE_DT_TM by using DOM APIs, insert the data, and use
DSN_XMLVALIDATE to validate the XML document during insert.
//************************************************************************
// parse the XML value with a DOM parser
//************************************************************************
try{
DocumentBuilder parser =
[Link]().newDocumentBuilder();
Document result = [Link](XMLFilename); 1
//get MSG_ID
NodeList nodes = [Link]("MsgId"); 2
MsgId = [Link](0).getFirstChild().getNodeValue(); 3
//get MSG_CRE_DT_TM
nodes = [Link]("CreDtTm");
CreDtTm = [Link](0).getFirstChild().getNodeValue();
//convert XML timestamp format to java format
CreDtTm = [Link]("T", " "); 4
} catch (Exception e) {
[Link]();
}
//************************************************************************
// insert XML data, also use DSN_XMLVALIDATE to validate
//************************************************************************
String sql = "INSERT INTO BK_TO_CSTMR_STMT " +
"VALUES(?,?,DSN_XMLVALIDATE(CAST(? AS XML),'SYSXSR.CAMT053_JAVA'))"; 5
pst = [Link](sql);
[Link](1, MsgId);
[Link](2, CreDtTm);
[Link](3, sqlxml1); 6
[Link](); 7
To update the entire XML documents, you can execute a Java statement or execute a
prepareStatement with a setXXX method to set the designated parameter to an XML value.
To update portions of XML documents, use the SQL UPDATE statement with the
XMLMODIFY built-in scalar function. The XMLMODIFY function specifies a basic updating
expression that you can use to insert nodes, delete nodes, replace nodes, or replace the
values of a node in XML documents that are stored in XML columns.
We have inserted a Bank To Customer Statement message, and the statement that reports
on booked entries and balances for a cash account is shown as Figure 7-2 on page 144.
The first balance (Bal element with the Cd code OPBD) shows that the book balance of the
account at the beginning of the account reporting period is 600000 Swedish krona. There is
one entry (Ntry) in the statement, and the code of CdtDbtInd is DBIT which indicates the
balance is a a debit balance, so the operation is a decrease. The Amount is 200100 Swedish
krona. The second balance (Bal element with the Cd code CLBD) shows the balance of the
account at the end of the pre-agreed account reporting period. It is the sum of the opening
booked balance at the beginning of the period and all entries booked to the account during
the pre-agreed account reporting period, so the amount is 399900 Swedish krona.
To modify or correct the message, add a new entry which is a credit balance increase of
100100 Swedish krona. We perform the following modification:
1. Append a new entry (Ntry) after the first entry, record the credit balance of 100100
Swedish krona.
2. Modify the amount of ClosingBooked (CLBD) balance to 500000 Swedish krona
pst = [Link](sql);
[Link](1, "AAAASESS-FP-STAT002");
[Link]();
//************************************************************************
// update XML document, modify the amount of ClosingBooked(CLBD) balance
//************************************************************************
pst = [Link](sql);
[Link](1, "AAAASESS-FP-STAT002");
[Link]();
To retrieve the entire XML document or partial XML document, use the XMLQUERY function.
You can retrieve data from XML columns in a table as binary XML data (data that is in the
Extensible Dynamic Binary XML DB2 Client/Server Binary XML Format), if the data server
supports binary XML data. Example 7-8 shows how to retrieve the entire or partial XML
document.
while ([Link]()) {
sqlxml=[Link](1);
[Link]([Link]());
}
//************************************************************************
// retrieve the XML nodes by using XMLQUERY to a SQLXML object
//************************************************************************
sql = " SELECT XMLQUERY(" +
"'declare default element namespace " +
"\"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02\"; " +
"/Document/BkToCstmrStmt/Stmt/Bal/Amt' " +
"passing BK_TO_CSTMR_STMT ) " +
"FROM BK_TO_CSTMR_STMT " +
while ([Link]()) {
sqlxml=[Link](1);
[Link]([Link]());
}
Example 7-9 shows the definition for the STMT table, each row contains one statement (Stmt
building block) of the BankToCustomerStatement message. For example "STMT_ID" column
corresponds to the 'Id' node under Stmt element, and "STMT_XML" column will be the sub
document (the Stmt building block) of the BankToCustomerStatement message.
Example 7-10 shows our code for creating the SQL procedure in Java.
To call the stored procedures in Java, invoke methods in the CallableStatement class. The
following basic steps call stored procedures, using standard CallableStatement methods:
1. Invoke the [Link] method with the CALL statement as its argument to
create a CallableStatement object.
2. Invoke the [Link] methods to pass values to the input parameters
(parameters that are defined as IN or INOUT in the CREATE PROCEDURE statement).
3. Invoke the [Link] method to register parameters that
are defined as OUT in the CREATE PROCEDURE statement with specific data types.
4. Invoke the [Link] methods to call the stored procedure.
5. Invoke the [Link] methods to retrieve values from the OUT
parameters or INOUT parameters.
The sample code to prepare, call the stored procedure, and retrieve the XML data from OUT
parameters is shown in Example 7-11.
stmt = [Link]();
sql = "SELECT BK_TO_CSTMR_STMT FROM BK_TO_CSTMR_STMT " +
"WHERE MSG_ID='AAAASESS-FP-STAT003-4'";
ResultSet rs = [Link](sql);
if([Link]())
xml1=[Link](1);
[Link](1, xml1);
[Link](2, [Link]);
[Link]();
xml1 = [Link](2);
[Link]("value of output XML:");
[Link]([Link]());
[Link]();
Java API for XML Processing (JAXP) provides interfaces in the [Link]
package, so that applications can invoke an XSLT transformation.
In the BankStmt application, we want to generate a report that lists all entries that have an
amount greater than 100,000 SEK. The expected output is shown in Example 7-12. In the
output, we list the account ID, amount, date and time, and account servicer reference of the
entry.
For more information about XSLT standard, go to the following web address:
[Link]
To add a message to a queue, you must connect to the queue manager first, which provides
queuing services to the applications. Then, you can open a queue and put the message into
it. Figure 7-4 on page 154 show the process.
WebSphere MQ classes for Java Message Service (also referred to as WebSphere MQ JMS)
is a set of Java classes that implement Oracle JMS (Sun) interfaces to enable JMS programs
to access WebSphere MQ systems.
Using WebSphere MQ JMS as the API to write WebSphere MQ applications has a number of
benefits. Several advantages derive from JMS being an open standard with multiple
implementations. Other advantages are from additional features that are present in
WebSphere MQ JMS, but not in WebSphere MQ base Java, such as asynchronous message
delivery, message selectors, and support for publish/subscribe messaging. WebSphere MQ
JMS APIs can be used to connect to MQ on multiple platforms.
The example code to put the message into a queue is shown in Example 7-16 on page 155.
//************************************************************************
// Maps the specified key to the specified value into properties
//************************************************************************
properties = new Hashtable();
[Link]("hostname", ipaddress);
[Link]("port", new Integer([Link](port)));
[Link]("channel", channel);
//************************************************************************
// Connect to MQ
//************************************************************************
try {
queueManager = new MQQueueManager(queueMgr, properties);
}
catch ([Link] e) {
...
}
//************************************************************************
// Open a queue
//************************************************************************
MQQueue system_default_local_queue=null;
try {
system_default_local_queue = [Link](queuename,
MQConstants.MQOO_INPUT_AS_Q_DEF | MQConstants.MQOO_OUTPUT,
null, null, null);
}
catch (MQException ex) {
...
}
//************************************************************************
// Put a message into the queue
//************************************************************************
MQMessage put_msg = new MQMessage();
put_msg.characterSet = 1208;
try {
put_msg.writeUTF(xmlmessage);
}
catch (Exception ex) {
...
}
try {
system_default_local_queue.put(put_msg, new MQPutMessageOptions());
}
catch (MQException ex) {
...
}
In this chapter, we demonstrate the COBOL support for the DB2 pureXML format by
implementing a small COBOL application based on the BankToCustomerStatement message
of the ISO 20022 standard presented in Chapter 3, “Application scenario” on page 47.
We also briefly cover native COBOL facilities for XML and how they complement those of DB2
pureXML.
The complete source code, DDL, XML schema, and scripts that are used in the application
are made available for download, as described in Appendix B, “Additional material” on
page 277.
Because XML is always stored in Unicode, pay special attention to which code pages are
used in the application and how to avoid data conversion.
We use the DB2 precompiler throughout this chapter. Experiences might vary slightly if using
the coprocessor.
Example 8-2 XML host variables after transformation by the DB2 pre-compiler
01 DOC-AS-CLOB.
49 DOC-AS-CLOB-LENGTH PIC S9(9) COMP-5.
49 DOC-AS-CLOB-DATA PIC X(102400).
01 DOC-AS-BLOB.
49 DOC-AS-BLOB-LENGTH PIC S9(9) COMP-5.
49 DOC-AS-BLOB-DATA PIC X(102400).
01 DOC-AS-DBCLOB.
49 DOC-AS-DBCLOB-LENGTH PIC S9(9) COMP-5.
49 DOC-AS-DBCLOB-DATA PIC G(102400) DISPLAY-1.
Whether you want to use CLOBs, DBCLOBs, or BLOBs as the base format depends on how
and whether you want to manipulate the contents of the XML file in the application.
One significant difference between the base format of BLOB compared to that of CLOB (or
DBCLOB) is the encoding. XML is always stored in UTF-8 Unicode; the COBOL application
can work in EBCDIC or UTF-16 Unicode. Therefore, data conversion and data encoding is
always an issue you must consider.
Data encoding
The character-based formats are referred to as externally encoded; the binary-based formats
are referred to as internally encoded. A variable with subtype FOR BIT DATA is also
considered internally encoded.
An XML document might or might not contain an encoding declaration, regardless of whether
it is internally or externally encoded. It is placed as an attribute of the XML declaration as
Example 8-3 shows.
However, the significance of the encoding declaration differs depending on the format. For
internally encoded documents, the encoding declaration is a factor in deciding the code page
of the XML document, together with the Unicode byte order mark (BOM) and the remaining
XML declaration. The BOM is an optional byte sequence that precedes the XML document
denoting the byte order of the following text. It is used for Unicode documents only.
The exact algorithm for determining the code page of an internally encoded XML document is
as follows:
If the document contains a BOM, the BOM decides the endianess. Possible outcomes are
UTF-16, UTF-32, big endian, or little endian.
If no BOM is present, and the XML document contains an encoding declaration, the
encoding declaration decides the code page. Possible outcome is any valid code page, it
does not have to be UTF-n encoding.
If no BOM and no encoding declaration is present, and the document contains an XML
declaration, the code page is UTF-8 if the document is written in single-byte ASCII,
UTF-16 if the document is double-byte ASCII.
If no BOM and no XML declaration is present, the code page is UTF-8.
Note: If there is a mismatch in endianess between BOM and the UTF-16 XML document,
the insert or update fails.
For externally encoded documents, any encoding declarations are ignored by DB2. Instead
the code page is determined as with any character data. The default is the application code
page, but you may override it in the SQLDA, or by an explicit variable declaration as shown in
Example 8-4. This way is probably the easiest, but it requires that the SQLDA is not in use for
the variables in question.
We conclude that the internally encoded variables and externally encoded variables give
different results when used for inserting XML documents into DB2. This information is
summarized in Table 8-1 on page 160; the effect of inserting various XML documents using
either XML AS BLOB or XML AS CLOB is shown.
We assume that the XML AS CLOB variable has an EBCDIC CCSID associated with it, either
through explicit declaration or from the application code page. Also assumed is that the
EBCDIC code page referred to is the same through the table. The XML AS BLOB, of course,
has no associated CCSID.
UTF-8 document with EBCDIC SQL error -20398 SQL error -20398
encoding declaration
Regardless of the encoding format that is used to enter XML data into DB2, ensure that the
encoding declaration is accurate, because data might later be transmitted to other
components or applications relying on the encoding declaration. If the encoding is not
accurate, errors might occur.
For details about how DB2 handles mixed data in a character string, go to the following
address:
[Link]
[Link]/db2z_mixeddatainchar.htm
When an XML document is inserted into DB2, data conversion always takes place if the code
page of the XML document is anything but UTF-8. This situation occurs whether the variable
holding the XML document is internally or externally encoded. Therefore, for the simple case
of inserting an XML document in EBCDIC from a COBOL application, data conversion cannot
be avoided even if using a BLOB as the base for the XML column.
However, when retrieving an XML document from DB2, data conversion occurs only if using
an externally encoded format for the target variable, and if the associated code page differs
from UTF-8. Therefore, although here data conversion is avoided when using a binary format,
you then have the data in Unicode, which might or might not be what you want.
For COBOL applications that work with XML documents in an EBCDIC code page, either
because they are received and transmitted to other applications in that format, or because
they are created and manipulated entirely in COBOL, a good choice is to use externally
encoded variables because that ensures that the necessary data conversions are performed.
However, if the COBOL application receives the XML data from, or transmits XML data to an
application using another code page, for example through WebSphere MQ, there is the risk of
performing an unnecessary interim data conversion.
In this case, using an internally encoded format might be preferable if the external application
either uses Unicode, or is able to perform the conversion from Unicode to its own code page.
The other option is using external encoding with the CCSID of the external application. Both
these choices eliminate the need for an interim conversion of the data, but both require that
the COBOL application can handle the XML data in the other application’s code page.
Using
UsingCLOB
CLOBfor forXML
XMLvariable
variable
1) Using CLOB for
Convert
Convert
XML
from
from
variable Convert from Convert from
CCSID
CCSID XY
X to to Y CCSID YY to
CCSID to UTF-8
UTF-8
XML app.
External
Convert from
COBOL Convert from
CCSID X to Y COBOL CCSID Y to UTF-8 DB2
DB2
dataCCSID
source.X
Websphere CCSIDYY
CCSID
COBOL UTF-8
UTF-8
UTF-8 DB2
CCSID X
MQ Convert
Convert from
from Convert from
Convert from UTF-8
X XCCSID Y totoCCSID
CCSID Y Y
CCSID X
CCSID
CCSID
Convert from
Y to
Y to
Convert from UTF-8
UTF-8
CCSID Y to X to CCSID Y
UsingBLOB
Using BLOBfor forXML
XMLvariable
variable
2) Using BLOBNofor XML variable Convert from
conversion
No conversion Convert
CCSID Xfrom
to UTF-8
CCSID X to UTF-8
External
XML app. No conversion COBOL Convert from DB2
COBOL DB2
dataCCSID
source.X
Websphere CCSID Y CCSID X to UTF-8
UTF-8
Convert from UTF-8 CCSID Y
COBOL No conversion
UTF-8
DB2
CCSID X
MQ to CCSID
Convert fromXUTF-8 No conversion
to CCSID X CCSID Y UTF-8
CCSID X Convert from UTF-8 No conversion
to CCSID X
A possibility is to use non-XML variables for inserting and updating, and for retrieving XML
documents. Possible data types are CLOB, BLOB, DBCLOB, CHAR, VARCHAR, GRAPHIC,
VARGRAPHIC, BINARY and VARBINARY.
You can either let DB2 handle the conversion implicitly, or explicitly call the conversion
functions. XMLSERIALIZE converts the host variable type to XML whereas XMLPARSE
converts XML to a host variable type. A more efficient way is to let DB2 perform the
conversion implicitly when possible.
In more complex SQL/XML, calls, for example XMLMODIFY, substituting the XML type with
other host variable types is not possible. In this case, performing an explicit conversion by
calling XMLPARSE or XMLSERIALIZE might be necessary.
For implicit serialization, the XML declaration always matches the document contents.
They can be used for efficient insertion of XML documents that you receive from outside the
application (if you do not need to manipulate the contents before inserting), and for retrieval of
documents that you want to pass on because they are without any modifications.
The variable declarations for file reference variables in COBOL are listed in Example 8-5.
Example 8-6 XML file reference variables after transformation by the DB2 precompiler
01 DOC-AS-CLOB-FILE.
49 DOC-AS-CLOB-FILE-NAME-LENGTH PIC S9(9) COMP-5 SYNC.
49 DOC-AS-CLOB-FILE-DATA-LENGTH PIC S9(9) COMP-5.
49 DOC-AS-CLOB-FILE-FILE-OPTION PIC S9(9) COMP-5.
49 DOC-AS-CLOB-FILE-NAME PIC X(255).
01 DOC-AS-BLOB-FILE.
49 DOC-AS-BLOB-FILE-NAME-LENGTH PIC S9(9) COMP-5 SYNC.
49 DOC-AS-BLOB-FILE-DATA-LENGTH PIC S9(9) COMP-5.
49 DOC-AS-BLOB-FILE-FILE-OPTION PIC S9(9) COMP-5.
49 DOC-AS-BLOB-FILE-NAME PIC X(255).
01 DOC-AS-DBCLOB-FILE.
49 DOC-AS-DBCLOB-FILE-NAME-LENGTH PIC S9(9) COMP-5 SYNC.
49 DOC-AS-DBCLOB-FILE-DATA-LENGTH PIC S9(9) COMP-5.
49 DOC-AS-DBCLOB-FILE-FILE-OPTION PIC S9(9) COMP-5.
49 DOC-AS-DBCLOB-FILE-NAME PIC X(255).
To work with a file reference variable, you must initialize the fields concerning the file name,
that is the name of the file and the length of the name, and the file option. The file option is
used to signal which type of operation you want to perform on the file. These options are
supplied as constant declarations in COBOL.
The possible values are shown in Table 8-2 on page 163. The length of the file is provided by
DB2 when writing to a file and does not have to be provided by the application.
The initialization needed to read from a file named ‘[Link]’ is shown in Example 8-7.
When the file reference variable is subsequently referred to, the specified file option is
executed. Therefore, if the file is used, such as in an insert operation, the file is read into DB2
and inserted without materializing in application memory.
Note: Apply PTF for currently open APAR PM25980 when using binary file reference and
locator variables. It solves issues for not UTF-8-encoded XML files.
The purpose of the application is to demonstrate how to use COBOL with DB2 pureXML. We
emphasize the steps and choices that are related to XML, disregarding irrelevant code and
components such as presentation layer or user dialog. The application might therefore seem
simple compared to a real-life application.
We use the same subset of the ISO 20022 standard, namely the BankToCustomerStatement
message, which is used throughout the book.
For the COBOL application, we use the database schema that focuses on the statement as a
business object. This approach implies that the BankToCustomerStatement is saved whole
as one XML document, rather than shredding the message into smaller documents before
saving them.
The outermost element is Document containing the BkToCstmrStmt element, which consists of
a GrpHdr element and a Stmt element. The Stmt element contains simple Id elements and
CreDtTm, complex FrToDt and Acct elements, and a number of complex Bal and Ntry
elements.
The schema for messages of this format is available from the ISO 20022 website. It is
extensive, and we do provide details, but we do examine a small subset of the schema that
we work with in this book. If you are not used to working with XML schemas, it is still possible
to get an idea of what the schema is saying. The schema itself is also written in XML.
The Document type is a complex type consisting of a sequence of elements with name
BkToCstmrStmt of type BankToCustomerStatementV02, which is a complex type made up from
another sequence of elements. This sequence contains an element of type GrpHdr and one or
more occurrences of the Stmt element.
Schema registration
We must register XML schemas in the DB2 XML schema repository to allow us to use DB2 to
validate our XML documents.
The documents can either be validated explicitly by using the DSN_XMLVALIDATE function
when inserting or updating, or DB2 can perform the validation automatically on insert and
update. The latter requires that the XML column be associated with an XML type modifier that
holds information about which schemas to use for validation.
The schema consists of a single document ([Link]), from the ISO 20022
website, and is available on our workstation. Options to register the schema are as follows:
Upload the schema to z/OS and register it through the command-line processor (CLP) in
UNIX System Services.
Register the schema through the CLP in Windows on our workstation, connecting to DB2
on z/OS by using DB2 Connect™.
Use Optim Development Studio or similar development framework to register the
schema. This step also requires DB2 Connect to connect to DB2 for z/OS.
For details about the other methods for schema registration, see 2.1.6, “XML schema
repository and schema validation”
With the schema in place, we can create the tables needed for the application.
As stated earlier we have decided that the bank statement is what corresponds to a business
object in this application, and we therefore need one table with one XML column, adding a
few redundant columns for easy access and overview. The XML column is created with a type
modifier that refers to the XML schema that we registered to allow for automatic schema
validation.
The DDL for the tables is shown in Example 8-9. No indexes are created at this time. We add
them when the programs and SQL queries are in place to make sure that the best possible
indexes are chosen.
We also assume that the message is stored in EBCDIC, and matches the application code
page so that the data is automatically converted correctly to UTF-8 if we use a single-byte
character-based XML variable.
We need data from the document to populate the redundant columns in the base table.
However, if we populate those after the insert task, we can do it in DB2 and we do not need to
manipulate the contents of the XML file at all in the application program. This technique
means that we can use a file reference variable to hold the XML.
The redundant columns are populated after the insert operation, so we only have to insert the
XML document. We do, however, need to be able to identify the row after the insert to supply
values for the redundant columns. Therefore, we use the following unique column, which is
generated automatically by DB2 when inserting the XML document:
DB2_GENERATED_DOCID_FOR_XML COLUMN
We select this column from the final table of the insert statement.
EXEC SQL
SELECT DB2_GENERATED_DOCID_FOR_XML INTO :DOC-ID
FROM FINAL TABLE
( INSERT INTO BK_TO_CSTMR_STMT (BK_TO_CSTMR_STMT)
VALUES (:BK-STMT-DATA) )
END-EXEC.
The XML data has now been validated and inserted, and all we need is to populate the two
redundant columns. To do this step, we extract the contents from the XML document by using
the XMLTABLE function.
The update, and therefore the remainder of what is needed for the insert operation is shown
in Example 8-11.
To test the program, two documents must be available in the file system: one that is valid
according to the XML schema and one that is not.
The JCL to run the program is in Example 8-12. The name of the file that is holding the XML
document is given as an input parameter in the SYSIN DD card.
We first run it with the XML document that is not valid. To produce the non-valid document, we
have omit the GrpHdr element altogether; the XML schema states that this element is
required, as we saw in 8.2.1, “Setting up the environment” on page 164. Running the program
with this document produces the error in Example 8-13.
The error is detected in location 184 of the document, and an expected element match was
not found there. By inspecting the document, we find that this error is the first location after
the start tag of the BkToCstmrStmt, and this is exactly the place where the GrpHdr should be,
according to the schema.
We then run the program with the valid document, and the program completes as expected.
To verify that the document has been validated, we use the DB2-supplied SQL function
XMLXSROBJECTID, which takes an XML column and returns the XSR object identifier that
was used to validate the XML document (or 0 if the document was not validated). The
identifier can then be looked up in the [Link] catalog table as shown in
Example 8-14.
Depending on the following situations, we may use any one of the functions:
To change the recipient from the owner to a non-owner, insert a MsgRcpt element.
To change the recipient from a non-owner to another non-owner, replace the MsgRcpt
element.
To change the recipient from a non-owner to the owner, delete the MsgRcpt element.
Note: The use of the XMLMODIFY function to update parts of an XML document is
supported for tables with the multiversioning format that was introduced in DB2 10 only.
For now, we assume that the MsgRcpt element is again available in a file that we can access
through a file reference variable. We input to the program the name of this file, an ID of the
XML message we want to change, and a choice of function to perform (replace, insert, or
update).
An alternative to this approach is to input the raw data and then build an XML element by
using COBOL features. See 8.3.1, “Generation of XML documents in COBOL” on page 178.
Example 8-15 COBOL program for updating a BkToCstmrStmt with a new MsgRcpt
WORKING-STORAGE SECTION.
01 REPLACE-MSG-RCPT PIC 9 VALUE 1.
01 INSERT-MSG-RCPT PIC 9 VALUE 2.
01 DELETE-MSG-RCPT PIC 9 VALUE 3.
01 FUNCTION-CHOICE PIC 9.
EXEC SQL INCLUDE SQLDA END-EXEC.
EXEC SQL INCLUDE SQLCA END-EXEC.
01 WS-BLANK-STRING PIC X(1) VALUE SPACES.
01 NEW-RCPT USAGE IS SQL TYPE IS XML AS CLOB-FILE.
01 MSGID PIC X(35).
...
MAIN SECTION.
EXEC SQL WHENEVER SQLERROR GOTO DBERROR END-EXEC.
EXEC SQL WHENEVER SQLWARNING GOTO DBERROR END-EXEC.
EVALUATE FUNCTION-CHOICE
WHEN REPLACE-MSG-RCPT PERFORM REPLACE-RCPT
WHEN INSERT-MSG-RCPT PERFORM INSERT-RCPT
WHEN DELETE-MSG-RCPT PERFORM DELETE-RCPT
WHEN OTHER DISPLAY "OTHER" FUNCTION-CHOICE
END-EVALUATE.
REPLACE-RCPT.
EXEC SQL
UPDATE BK_TO_CSTMR_STMT
SET BK_TO_CSTMR_STMT =
XMLMODIFY (
'declare default element namespace
- '"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
- 'replace node
- '/Document/BkToCstmrStmt/GrpHdr/MsgRcpt
- 'with $rcp/NewRcpt/MsgRcpt',
:NEW-RCPT AS "rcp"
)
WHERE MSG_ID = :MSGID
END-EXEC.
INSERT-RCPT.
EXEC SQL
DELETE-RCPT.
EXEC SQL
UPDATE BK_TO_CSTMR_STMT
SET BK_TO_CSTMR_STMT =
XMLMODIFY (
'declare default element namespace
- '"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
- 'delete node
- '/Document/BkToCstmrStmt/GrpHdr/MsgRcpt'
)
WHERE MSG_ID = :MSGID
END-EXEC.
The program was tested with function 1, for inserting a new MsgRcpt element, and a file
containing the MsgRcpt element, as shown in Figure 8-4 on page 169. This step produced
the error in Example 8-16.
Example 8-16 SQL error when updating XML document with MsgRcpt element
DSNT408I SQLCODE = -20399, ERROR: ERROR ENCOUNTERED DURING XML VALIDATION:
LOCATION 237; TEXT An element is not in the [Link]=0018,RSN=8608;
XSRID 144.
DSNT418I SQLSTATE = 2201R SQLSTATE RETURN CODE
DSNT415I SQLERRP = DSNNOPAR SQL PROCEDURE DETECTING ERROR
DSNT416I SQLERRD = -510 0 0 -1 0 0 SQL DIAGNOSTIC INFORMATION
DSNT416I SQLERRD = X'FFFFFE02' X'00000000' X'00000000' X'FFFFFFFF'
X'00000000' X'00000000' SQL DIAGNOSTIC INFORMATION
The MsgRcpt element is inserted after the CreDtTm element in the GrpHdr element. We now
compare this information to the schema definition of the GrpHdr element, which is shown in
Figure 8-5. This definition is of the complex type GroupHeader42, which describes the GrpHdr
element. We see that it consists of a sequence with a MsgId element, followed by a CreDtTm
element, which again is followed by an optional MsgRcpt element and two other optional
elements.
The location of the MsgRcpt element is not in conflict with the schema definition, so why does
DB2 not recognize the element name as valid in the context?
The explanation is related to namespaces. Recall that namespaces are a mechanism for
ensuring uniqueness of element names, so that two elements in separate domains and
possibly with separate structure and contents are not confused, although they have the same
element name. By associating with each element a namespace, we guarantee that we know
which one we are referencing. This association can be done either explicitly with a prefix to
the element name, or implicitly by declaring a default element namespace.
The BankToCustomerStatement has the following default namespace and therefore all the
elements belonging to this message have the same namespace unless another namespace
is explicitly given:
urn:iso:std:iso:20022:tech:xsd:camt.053.001.02
The MsgRcpt element we tried to insert into the document had no namespaces associated
with it, and therefore it is not the same element as the one in the BankToCustomerStatement
schema. Therefore, it is not valid in the context.
We alter the contents of the file that contains the MsgRcpt element, shown in Figure 8-6, and
attempt to run the update again. This time the namespace declaration matches the default
element declaration, and the insert succeeds.
Example 8-17 shows how to select a whole XML document, with a given ID from the
BK_TO_CSTMR_STMT table, and write it to a file by using a file reference variable.
EXEC SQL
SELECT BK_TO_CSTMR_STMT INTO :BK-STMT-FILE
FROM BK_TO_CSTMR_STMT
WHERE MSG_ID = :MSGID
END-EXEC.
We want to make a list of all entries that are created after a given date. The list is to contain
the statement ID, amount, currency, credit-debit indicator, and datetime values.
We want to extract these values into simple SQL host variables of type DECIMAL, CHAR, and
TIMESTAMP. In this case, it is transparent to the COBOL application that we are working with
XML data, because all the XML manipulation takes place in DB2 through EXEC SQL
statements. Even for the host variable declarations, we do not have to consider the various
XML alternatives.
Example 8-18 on page 174 shows a program that extracts the entries for all bank statements
and places them in relational host variables. The program inputs a time stamp and selects
data from entries that have a time stamp later than this input time stamp. This step is done by
passing the value of the time stamp as a parameter to the XPath expression, and then using it
in the predicate where it is compared to the time stamp of each entry.
The example uses XMLTABLE to get a relational view of each entry, of which there may be
several per BankToCustomerStatement, so potentially there are more rows returned than
rows in the table. These rows are then filtered by the predicate, so potentially fewer rows
might exist than rows in the table. These values are then placed in relational host variables for
further processing.
EXEC SQL
DECLARE C1 CURSOR FOR
SELECT [Link], [Link], [Link] , [Link] , [Link]
FROM BK_TO_CSTMR_STMT S,
XMLTABLE (XMLNAMESPACES(DEFAULT
'urn:iso:std:iso:20022:tech:xsd:camt.053.001.02',
'/Document/BkToCstmrStmt/Stmt/Ntry[BookgDt/DtTm>$tm]'
PASSING S.BK_TO_CSTMR_STMT, TIMESTAMP(:FROM-TIME) AS "tm"
COLUMNS
"STMT" CHAR(20) PATH '../Id',
"DTTM" CHAR(26) PATH 'BookgDt/DtTm',
"CCY" CHAR(4) PATH 'Amt/@Ccy',
"AMT" DECIMAL(11,2) PATH 'Amt',
"CREDBTIND" CHAR(4) PATH 'CdtDbtInd'
) X
END-EXEC.
EXEC SQL
OPEN C1
END-EXEC.
EXEC SQL
FETCH C1 INTO :STMT-ID ,
:NTRY-TIME ,
:CURRENCY-NM ,
:AMOUNT ,
:CREDIT-DEBIT
END-EXEC.
PERFORM WRITE-AND-FETCH
UNTIL SQLCODE IS NOT EQUAL TO ZERO.
EXEC SQL WHENEVER NOT FOUND GOTO CLOSEC1 END-EXEC.
CLOSEC1.
EXEC SQL CLOSE C1 END-EXEC.
In the COBOL application, we have not used the XMLEXISTS function. The XMLTABLE
function has been used twice, but only the one that extracts entries from the bank statement
contains a predicate.
We must include the path down to, and including, the DtTm element because this one is the
one that the predicate evaluates, and we must include namespace declarations in the index.
Example 8-20 shows the resulting index.
Note: The support for date and time data types and functions in XML functions, including
TIME, DATE, and TIMESTAMP as data types for indexes, requires DB2 10 NFM.
To ensure that the index is used by the COBOL program, we run the Runstats utility on the
table and XML index, and then do an EXPLAIN of the program. Example 8-21 shows
selection of several essential columns from the plan table for the program after and before the
creation of the index.
The access type for access to BK_TO_CSTMR_STMTtable is DX, which is an indication that
an XML index is being used for access; the access name is IXMLNTRY, which is the index we
just created.
If you want to send the same message to more than one recipient, in the XML document you
would have more than one MsgRcpt. What would be the effect on the schema and your
applications? The schema definition of the GrpHdr is shown in Figure 8-7.
Notice that the current schema definition does not allow more than one occurrence of the
MsgRcpt element, which is determined by the maxOccurs=”1” attribute, and if you tried to
insert a document containing, for example two message recipients, a validation error occurs.
Therefore, the first item that has to change is the schema definition.
To alter the schema definition to allow for multiple occurrences of the MsgRcpt element, the
only change necessary is to change the maxOccurs=”1” clause of the element to
maxOccurs=”unbounded”. The result is shown in Figure 8-8.
Figure 8-8 Revised schema definition for GrpHdr with multiple MsgRcpt elements
We give the schema another version, for example SYSXSR.CAMT_053_001_03 and register it to
DB2 in the same way as we did in the original schema. See Example 8-8 on page 166 for
details.
We then alter the table definition so that the version 3 schema is used for automatic
validation. We do not want to remove the original schema because the data that is already in
the table was validated against this schema, and removing it would remove the audit trail. It
would also leave the table in a check-pending state because the rows would not have been
validated against a schema mentioned in the XML type modifier. Instead, we add the new
version to the type modifier of the XML column on top of the original schema.
When updating or inserting new XML documents, these documents are automatically
validated against the latest version of the type modifier, when using automatic validation.
The table and schema repository are now set to handle the updated schema.
Application changes
On the application side, the changes needed are of course influenced by the degree to which
the fields involved in the change are used. The following examples nevertheless show that
XML documents in many ways are robust to minor changes.
The insert application takes a whole XML document from the file system and inserts it into
DB2 without manipulating it at all. The data validation is performed by DB2, but because we
altered the XML type modifier to include the new schema, this step is already taken care of.
Therefore, no changes are necessary in the insert application.
The update application alters the message recipient of the statement. Rather than altering it,
we might, in the future want to only add another message recipient, because this is now
allowed by the new schema. The COBOL program already contains the option of inserting a
new message recipient; we investigate to determine whether the option can be used for
inserting additional message recipients next to existing ones.
The XMLMODIFY expression that is used for inserting is shown in Example 8-23. It inserts
the MsgRcpt element directly after the CreDtTm element. This approach means that if one or
more MsgRcpt elements are already there, the new element is placed before these. This
approach is valid according to the schema, so unless any significance is given to the order of
the MsgRcpt elements, the application requires no changes to cater to the schema change.
None of the query applications make use of the message recipients, so no changes are
necessary here.
These changes can all be performed as online changes. No changes are necessary on the
application side.
If the database schema had been relational, the required changes would likely be much more
extensive, involving a new table for the message recipient data and also converting existing
data to make them available in the new table. This step, in turn, would require application
changes, allowing the application to insert and update data in the new table.
In certain cases, this support might complement the DB2 functionality, when basing the
database design on pureXML.
This section briefly introduces the most important concepts, namely parsing, generating, and
validating XML documents in native COBOL. For more details, see Enterprise COBOL for
z/OS Version 4.2 Programming Guide, SC23-8529-01.
COBOL also offers support for generation of XML documents from COBOL structures
through the XML GENERATE statement.
This function takes as input a data item that is typically a group, and generates as output an
XML document with similar structure as the input data item. The resulting element names are
taken from the names in the group data item, and the resulting element contents is taken from
the contents of these variables.
Example 8-24 on page 179 shows how to use XML GENERATE to generate a MsgRcpt
element from a variable structure.
The generation of the MsgRcpt element provides us with an alternative to the program for
updating the MsgRcpt of a bank statement, described in 8.2.3, “Updating XML documents” on
page 169. Rather than assuming that the new MsgRcpt is provided as an XML element in a
text file, you may input the text values and build the XML element.
Figure 8-10 MsgRcpt element created with XML GENERATE WITH ATTRIBUTES
In most cases, the simple XML GENERATE is probably the better choice. Currently, there is
no support for generating XML documents with both text elements and attributes.
COBOL has similar support for XML documents that are stored in COBOL variables, and is
offered through the XML PARSE statement.
This statement takes as input an XML document and a parsing procedure that handles the
events that occur during parsing. With this approach, you can shred the document into
COBOL variables, for example an alphanumeric group with the same structure as the XML
document or separate elementary data items. In addition, you may process the data directly
without saving the XML contents into variables.
The parsing procedure has to be written in the application program by using the various XML
events provided by the XML parser as it goes through the document.
Example 8-25 COBOL program for shredding a MsgRcpt element into variables
01 MsgRcpt.
05 Nm PIC X(20).
05 PstlAdr.
10 StrtNm PIC X(20).
10 BldgNb PIC X(20).
10 PstCd PIC X(20).
10 TwnNm PIC X(20).
01 NS PIC X(50).
01 RCPT PIC X(207).
01 CURRENT-ELEMENT PIC X(40).
...
XML PARSE NEW-RCPT
PROCESSING PROCEDURE GET-DATA
END-XML.
...
GET-DATA.
EVALUATE XML-EVENT
When 'START-OF-ELEMENT'
Move XML-Text to current-element
When 'CONTENT-CHARACTERS'
EVALUATE current-element
When 'Nm'
Move XML-TEXT TO Nm
When 'PstlAdr'
Move XML-TEXT TO PstlAdr
When 'StrtNm'
Move XML-TEXT TO StrtNm
When 'BldgNb'
Move XML-TEXT TO BldgNb
When 'PstCd'
Move XML-TEXT TO PstCd
When 'TwnNm'
Move XML-TEXT TO TwnNm
When Other
Continue
End-evaluate
When 'ATTRIBUTE-NAME'
Continue
When 'ATTRIBUTE-CHARACTERS'
Continue
When 'EXCEPTION'
DISPLAY 'Exception code: ' XML-CODE
END-EVALUATE.
The XML PARSE statement was introduced in COBOL before the pureXML format was
available in DB2, and is useful for shredding XML documents that are saved as LOBs in DB2.
In general, save XML data as pureXML especially if you need to query the contents of that
data, and in that case the shredding is more readily done by the XMLTABLE function in DB2.
The schema does not have to be registered anywhere, but it does have to be in a
preprocessed format known as Optimized Schema Representation (OSR). This preprocessing
can be done from UNIX System Services with a command such as in Example 8-26. First, the
schema is copied to UNIX System Services from TSO, and then the OSR document is
generated.
We extend the XML PARSE statement in Example 8-25 on page 181 with the validating
phrase shown in Example 8-27.
We use the schema declaration in the SPECIAL-NAMES section to associate the schema
name RSCHEMA with an external file that contains the schema. This association can then be
supplied as a DD statement in the JCL to run the COBOL program, as shown
inExample 8-28.
As mentioned previously, the automatic schema validation that can be set up in DB2, simply
by associating an XML type identifier with the XML column, is robust to schema changes and
can be easy to work with. This choice is generally better than explicit schema validation in
both DB2 and COBOL.
The CHECK DATA utility checks XML relationships and can check the consistency between a
base table space and the corresponding XML table spaces. If the base table space is not
consistent with any related XML table spaces, CHECK DATA reports the error.
The default behavior of CHECK DATA is to check all objects that are in the CHECK-pending
status (SCOPE PENDING). However, you may limit the scope of checking by specifying
SCOPE REFONLY to check only the base tables, or SCOPE AUXONLY to check XML and
LOB objects.
You may specify the action that DB2 performs when it finds an error in XML columns by using
the XMLERROR keyword:
XMLERROR REPORT reports only the error.
XMLERROR INVALIDATE reports the error and sets the column in error to an invalid
status.
You may specify the action that DB2 performs when it finds an error in LOB or XML columns
by using the AUXERROR keyword:
AUXERROR REPORT reports only the error.
AUXERROR INVALIDATE reports the error and sets the column in error to an invalid
status.
The CHECK DATA utility has the following features to support XML data:
Check consistency between the base table space and the NODEID index.
Check consistency between the XML table space and the NODEID index.
Check consistency in the document structure for each XML document.
Validate schema if XML columns have a type modifier.
If you specify the INCLUDE XML TABLESPACES option, CHECK DATA can check the
structural integrity of XML documents. CHECK DATA can verify the following items for XML
objects:
All rows in an XML column exist in the XML table space.
All documents in the XML table space are structurally valid.
Each index entry in the NODEID index has a corresponding XML document.
Each XML document in the XML table space has corresponding entries in the NODEID
index.
Each entry in the DOCID column in the base table space has a corresponding entry in the
NODEID index over the XML table space, if the XML column is not null.
Each entry in the NODEID index contains a corresponding value in the DOCID column.
If an XML column has an XML type modifier, all XML documents in the column are valid
with respect to at least one XML schema that is associated with the XML type modifier.
If the base table space is not consistent with any related XML table spaces, or a problem is
found during any of the previously listed checks, CHECK DATA reports the error.
For XML checking, the default behavior of CHECK DATA is to check only the consistency
between each XML column and its NODEID index. However, you may modify the scope of
checking by specifying combinations of the CHECK DATA SCOPE keyword and the INCLUDE
Table 9-1 is a reference table for the CHECK DATA invocation and is based on the
combination of the various options that are applicable for LOBs also.
X REFONLY - - - -
X XMLSCHEMA - Yes - -
ONLY Default:
INCLUDE XML
TABLESPACES
ALL
X X REFONLY - - - -
X X XMLSCHEMA - Yes - -
ONLY Specified XML
table spaces only
X X X REFONLY - - - -
X X X XMLSCHEMA - Yes - -
ONLY Specified XML
table spaces only
The XML checks column indicates CHECK DATA utility checks only for the consistency
between the base table and the NODEID index.
The LOB checks column indicates CHECK DATA utility checks for the consistency between
the base table and the auxiliary index.
See 10.5, “Diagnostics” on page 242 for examples of invoking the CHECK DATA utility when
diagnosing problems with XML data.
1DSNU000I 314 [Link].95 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 314 [Link].97 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 314 [Link].98 DSNUGUTC - CHECK INDEX(XMLR4.I_DOCIDBK_TO_CSTMR_STMT)
DSNU395I 314 [Link].99 DSNUKPIK - INDEXES WILL BE CHECKED IN PARALLEL, NUMBER OF
TASKS = 3
DSNU701I -DB0B 314 [Link].99 DSNUKIUL - 1 INDEX ENTRIES UNLOADED FROM
'[Link]'
DSNU705I 314 [Link].00 DSNUKPIK - UNLOAD PHASE COMPLETE - ELAPSED TIME=[Link]
DSNU719I 314 [Link].07 DSNUKPIK - 1 ENTRIES CHECKED FOR INDEX
'XMLR4.I_DOCIDBK_TO_CSTMR_STMT'
DSNU720I 314 [Link].07 DSNUKPIK - SORTCHK PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU719I -DB0B 314 [Link].07 DSNUKTER - 1 ENTRIES CHECKED FOR INDEX
'XMLR4.I_DOCIDBK_TO_CSTMR_STMT'
DSNU380I -DB0B 314 [Link].07 DSNUGSRX - TABLESPACE [Link] PARTITION 1 IS IN
COPY PENDING
NOTE: You can specify the CHECK INDEX control statement as shown below:
CHECK INDEX(ALL) TABLESPACE [Link]
CHECK INDEX(ALL) TABLESPACE DSN00242.XBKR0000
The advantage with this approach is any user defined indexes are also checked.
After running the CHECK INDEX utility, you might need to correct XML data.
To correct XML data, based on the CHECK INDEX output, perform one of the actions listed in
Table 9-2.
Problem with a document ID index 1. Confirm that the base table space is at the
correct level.
2. Rebuild the index.
Problem with an XML table space for a NODEID Run REPAIR LOCATE RID DELETE to remove the
index or an XML index and the index is correct orphan row.
Problem with an XML table space for a Run REBUILD INDEX or RECOVER INDEX to
NODEID index or an XML index and the index is rebuild the index.
incorrect
Problem with an XML index over an XML table Run REBUILD INDEX to rebuild the index.
space Restriction: Do not run REPAIR LOCATE RID
DELETE to remove orphan rows unless the
NODEID index does not represent the same row
and the base table space does not use the
document ID index.
Note: CHECK INDEX of an XML index cannot run if REBUILD INDEX, REORG INDEX, or
RECOVER is being run on that index because CHECK INDEX needs access to the
NODEID index. CHECK INDEX SHRLEVEL CHANGE cannot run two jobs concurrently for
two different indexes that are in the same table space.
The COPY utility control statement in Example 9-3 specifies that DB2 is to copy base table
space [Link] and the XML table space DSN00242.XBKR0000.
Example 9-3 COPY utility JCL for taking full image copy and output
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//[Link] DD *
TEMPLATE A DSN(&DB..&SN..&IC..D&DATE..T&TIME..COPY)
COPY TABLESPACE [Link] COPYDDN(A)
TABLESPACE DSN00242.XBKR0000 COPYDDN(A)
1DSNU000I 314 [Link].11 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 314 [Link].14 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 314 [Link].14 DSNUGUTC - TEMPLATE A
DSN(&DB..&SN..&IC..D&DATE..T&TIME..COPY)
DSNU1035I 314 [Link].14 DSNUJTDR - TEMPLATE STATEMENT PROCESSED SUCCESSFULLY
Both full and incremental image copies are supported for an XML table space, and also the
SHRLEVEL REFERENCE, SHRLEVEL CHANGE, CONCURRENT, and FLASHCOPY
options.
To demonstrate using COPY utility to take an incremental image copy, the XML document is
modified, as shown in Figure 9-2 on page 192.
<Amt xmlns:xsi="[Link]
xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02"
Ccy="SEK">435678.50</Amt>
DSNE610I NUMBER OF ROWS DISPLAYED IS 1
UPDATE BK_TO_CSTMR_STMT
SET BK_TO_CSTMR_STMT = XMLMODIFY (
'declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
replace value of node
/Document/BkToCstmrStmt/Stmt/Bal/Amt[../Tp/CdOrPrtry/Cd="CLBD"]
with "900000"')
WHERE MSG_ID IS NULL ;
SELECT XMLSERIALIZE(
XMLQUERY(
'declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
/Document/BkToCstmrStmt/Stmt/Bal/Amt[../Tp/CdOrPrtry/Cd="CLBD"]'
PASSING BK_TO_CSTMR_STMT) AS CLOB(500))
FROM BK_TO_CSTMR_STMT;
<Amt xmlns:xsi="[Link]
xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02" Ccy="SEK">900000</Amt>
DSNE610I NUMBER OF ROWS DISPLAYED IS 1
Figure 9-2 Make a partial update to the XML document
The COPY utility control statement in Example 9-4 on page 193 specifies that DB2 is to take
an incremental image copy of base table space [Link] and the XML table space
DSN00242.XBKR0000.
1DSNU000I 314 [Link].22 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 314 [Link].25 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 314 [Link].26 DSNUGUTC - TEMPLATE A
DSN(&DB..&SN..&IC..D&DATE..T&TIME..COPY)
DSNU1035I 314 [Link].26 DSNUJTDR - TEMPLATE STATEMENT PROCESSED SUCCESSFULLY
Unless either the CONCURRENT option or the FLASHCOPY option is specified, COPY does
not copy empty or unformatted data pages of an XML table space.
To copy an XML table space with a base table space that has the NOT LOGGED attribute, all
associated XML table spaces must also have the NOT LOGGED attribute. The XML table
space acquires this NOT LOGGED attribute by being linked to the logging attribute of its
associated base table space. You cannot independently alter the logging attribute of an XML
table space.
If the LOG column of the [Link] record for an XML table space has the
value of X, the logging attributes of the XML table space and its base table space are linked,
and that the logging attribute of both table spaces is NOT LOGGED. To break the link, alter
the logging attribute of the base table space back to LOGGED, and the logging attribute of
both table spaces are changed back to LOGGED
The COPYTOCOPY utility control statement in Example 9-5 specifies that DB2 is to make
primary and backup copies for the remote site for the DSN00242.XBKR0000 XML table space
using the last full image copy that was created.
1DSNU000I 314 [Link].00 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 314 [Link].04 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 314 [Link].04 DSNUGUTC - TEMPLATE A
DSN(&DB..&SN..&IC..&PB..D&DATE..T&TIME..COPY)
DSNU1035I 314 [Link].04 DSNUJTDR - TEMPLATE STATEMENT PROCESSED SUCCESSFULLY
1DSNU000I 314 [Link].81 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 314 [Link].83 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 314 [Link].83 DSNUGUTC - COPYTOCOPY TABLESPACE DSN00242.XBKR0000
FROMLASTFULLCOPY RECOVERYDDN(A,A)
DSNU1403I 314 [Link].87 DSNU2BCC - LOCAL SITE PRIMARY DATA SET
[Link] WITH
START_RBA 0000696BCB4C IS IN USE BY COPYTOCOPY
FOR TABLESPACE DSN00242.XBKR0000
DSNU1404I 314 [Link].88 DSNU2BDR - COPYTOCOPY PROCESSING COMPLETED FOR
TABLESPACE DSN00242.XBKR0000
ELAPSED TIME = [Link]
NUMBER OF PAGES COPIED=3
DSNU1406I 314 [Link].89 DSNU2BDR - COPYTOCOPY COMPLETED. ELAPSED TIME = [Link]
With the cross-loader function, you can use a single LOAD job to transfer data from one
location to another location or from one table to another table at the same location. You may
use either a local server or any DRDA-compliant remote server as a data input source for
populating your tables. Your input can even be from other sources besides DB2 for z/OS. You
may use IBM Information Integrator Federation feature for access to data from sources as
diverse as Oracle and Sybase, and also the entire DB2 family of database servers.
Note: You cannot declare a cursor that includes XML data. Thus, you cannot use the DB2
family cross-loader function to transfer data from XML columns. However, you can declare
a cursor on a table with XML columns if the cursor does not include any XML columns.
For example, suppose that you create the following table with an XML column:
CREATE TABLE BK_TO_CSTMR_STMT
(MSG_ID VARCHAR(35),
MSG_CRE_DT_TM TIMESTAMP WITH TIMEZONE,
BK_TO_CSTMR_STMT XML NOT NULL)
You cannot declare the following cursor, because it includes XML data in the
BK_TO_CSTMR_STMT column:
EXEC SQL
DECLARE C1 CURSOR FOR SELECT * FROM BK_TO_CSTMR_STMT
END-EXEC
However, you can declare a cursor that includes non-XML columns, as in the following
example:
EXEC SQL
DECLARE C2 CURSOR FOR SELECT MSG_ID FROM BK_TO_CSTMR_STMT
END-EXEC
9.6 LISTDEF
When you create object lists with the LISTDEF utility, specify whether you want related XML
objects to be included or excluded.
For example, the LISTDEF statements in Table 9-3 on page 196 generate the indicated lists.
All tables spaces in the DSN00242 database, including XML table spaces
All index spaces in the DSN00242 database
All tables spaces in the DSN00242 database, including XML table spaces
All index spaces in the DSN00242 database except for XML index spaces
Example 9-6 shows the JCL for the LISTDEF utility for the first LISTDEF statement in
Table 9-3 and the output of the utility run.
1DSNU000I 314 [Link].38 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 314 [Link].41 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 314 [Link].41 DSNUGUTC - OPTIONS PREVIEW
DSNU1000I 314 [Link].41 DSNUZODR - PROCESSING CONTROL STATEMENTS IN PREVIEW MODE
DSNU1035I 314 [Link].41 DSNUZODR - OPTIONS STATEMENT PROCESSED SUCCESSFULLY
0DSNU050I 314 [Link].41 DSNUGUTC - LISTDEF LISTALL INCLUDE TABLESPACES DATABASE
DSN00242 INCLUDE INDEXSPACES DATABASE DSN00242
DSNU1035I 314 [Link].41 DSNUILDR - LISTDEF STATEMENT PROCESSED SUCCESSFULLY
DSNU1020I -DB0B 314 [Link].41 DSNUILSA - EXPANDING LISTDEF LISTALL
DSNU1021I -DB0B 314 [Link].41 DSNUILSA - PROCESSING INCLUDE CLAUSE DATABASE DSN00242.
DSNU1022I -DB0B 314 [Link].42 DSNUILSA - CLAUSE IDENTIFIES 2 OBJECTS
DSNU1021I -DB0B 314 [Link].42 DSNUILSA - PROCESSING INCLUDE CLAUSE DATABASE DSN00242.
DSNU1022I -DB0B 314 [Link].43 DSNUILSA - CLAUSE IDENTIFIES 2 OBJECTS
DSNU1023I -DB0B 314 [Link].43 DSNUILSA - LISTDEF LISTALL CONTAINS 4 OBJECTS
DSNU1010I 314 [Link].43 DSNUGPVV - LISTDEF LISTALL EXPANDS TO THE FOLLOWING OBJECTS:
LISTDEF LISTALL -- 00000004 OBJECTS
INCLUDE TABLESPACE [Link]
INCLUDE TABLESPACE DSN00242.XBKR0000
INCLUDE INDEXSPACE [Link]
INCLUDE INDEXSPACE [Link]
1DSNU000I 314 [Link].19 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 314 [Link].22 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 314 [Link].22 DSNUGUTC - OPTIONS PREVIEW
DSNU1000I 314 [Link].22 DSNUZODR - PROCESSING CONTROL STATEMENTS IN PREVIEW MODE
DSNU1035I 314 [Link].22 DSNUZODR - OPTIONS STATEMENT PROCESSED SUCCESSFULLY
0DSNU050I 314 [Link].22 DSNUGUTC - LISTDEF LISTXML INCLUDE TABLESPACES DATABASE
DSN00242 XML INCLUDE INDEXSPACES DATABASE DSN00242 XML
DSNU1035I 314 [Link].22 DSNUILDR - LISTDEF STATEMENT PROCESSED SUCCESSFULLY
DSNU1020I -DB0B 314 [Link].22 DSNUILSA - EXPANDING LISTDEF LISTXML
DSNU1021I -DB0B 314 [Link].22 DSNUILSA - PROCESSING INCLUDE CLAUSE DATABASE DSN00242.
DSNU1022I -DB0B 314 [Link].22 DSNUILSA - CLAUSE IDENTIFIES 1 OBJECTS
DSNU1021I -DB0B 314 [Link].22 DSNUILSA - PROCESSING INCLUDE CLAUSE DATABASE DSN00242.
DSNU1022I -DB0B 314 [Link].22 DSNUILSA - CLAUSE IDENTIFIES 1 OBJECTS
DSNU1023I -DB0B 314 [Link].22 DSNUILSA - LISTDEF LISTXML CONTAINS 2 OBJECTS
DSNU1010I 314 [Link].22 DSNUGPVV - LISTDEF LISTXML EXPANDS TO THE FOLLOWING OBJECTS:
LISTDEF LISTXML -- 00000002 OBJECTS
INCLUDE TABLESPACE DSN00242.XBKR0000
INCLUDE INDEXSPACE [Link]
Example 9-8 shows the JCL for the LISTDEF utility for the third LISTDEF statement in
Table 9-3 on page 196 and the output of the utility run.
9.7 LOAD
Use one of the following methods to load data containing XML columns:
The XML column can be loaded from the input record. The XML column value can be
placed in the input record with or without any other loading column values. The input
record can be in delimited or non-delimited format:
– For a non-delimited format, the XML column is treated like a variable character with a
2-byte length preceding the XML value.
– For a delimited format there are no length bytes present. If the input record is in
spanned record format, specify the FORMAT SPANNED YES option.
The XML column can be loaded from a separate file whether or not the XML column
length is less than 32 KB.
To load data into a base table that has XML columns, use the following steps:
1. Create input data sets to ensure that you use the appropriate format:
– If the data set is in delimited format, ensure that the XML input fields follow the
standard LOAD utility delimited format.
– If the data set is not in delimited format, specify the XML input fields similar to the way
that you specify VARCHAR input. Specify the length of the field in a 2-byte binary field
that precedes the data.
2. Create a LOAD utility control statement:
– To load XML directly from input record, specify XML as the input field type. XML is the
only acceptable field type and data type conversion is not supported. Do not specify
DEFAULTIF.
If you want the white space to be preserved in the XML data, also specify the keywords
PRESERVE WHITESPACE. By default, LOAD strips the white space.
When data in the binary XML format is loaded into a table, and PRESERVE
WHITESPACE is not specified, DB2 strips white space only when the input data
contains white space tags.
– To load XML from a file, specify CHAR or VARCHAR along with either BLOBF, CLOBF
or DBCLOBF to indicate that the input column contains a file name from which a
BLOBF, CLOBF or DBCLOBF is to be loaded to the XML column.
When you insert XML documents into a table with XML indexes that are of type
DECFLOAT, the values might be rounded when they are inserted. If the index is unique, the
rounding might cause duplicates even if the original values are not exactly the same.
Example 9-9 shows the JCL for the LOAD utility and the output of the utility run.
1DSNU000I 300 [Link].45 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = XMLR4.XMLR4LD
DSNU1044I 300 [Link].47 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 300 [Link].48 DSNUGUTC - LOAD DATA REPLACE
DSNU650I -DB0B 300 [Link].48 DSNURWI - INTO TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU650I -DB0B 300 [Link].48 DSNURWI - (BK_TO_CSTMR_STMT POSITION(1) XML PRESERVE
WHITESPACE)
DSNU350I -DB0B 300 [Link].13 DSNURRST - EXISTING RECORDS DELETED FROM TABLESPACE
DSNU304I -DB0B 300 [Link].26 DSNURWT - (RE)LOAD PHASE STATISTICS - NUMBER OF RECORDS=1
FOR TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU1147I -DB0B 300 [Link].26 DSNURWT - (RE)LOAD PHASE STATISTICS - TOTAL NUMBER OF
RECORDS LOADED=1 FOR TABLESPACE [Link]
DSNU302I 300 [Link].27 DSNURILD - (RE)LOAD PHASE STATISTICS - NUMBER OF INPUT RECORDS
PROCESSED=1
DSNU300I 300 [Link].27 DSNURILD - (RE)LOAD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU349I -DB0B 300 [Link].32 DSNURBXA - BUILD PHASE STATISTICS - NUMBER OF KEYS=1 FOR
INDEX XMLR4.I_DOCIDBK_TO_CSTMR_STMT
DSNU258I 300 [Link].32 DSNURBXD - BUILD PHASE STATISTICS - NUMBER OF INDEXES=1
DSNU259I 300 [Link].32 DSNURBXD - BUILD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU010I 300 [Link].33 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0
This technique requires specifying the exact size of the XML document preceding the data.
DB2 automatically generates the document ID column for each row that is loaded into a table
with at least one XML column. The document ID column is partially hidden. It is not included
in the result set of a SELECT * statement. However, you can query this column by name and
view information about this column and its index in the catalog. Several utilities report
information about this column in their output.
Loading XML data with the LOAD utility has the following restrictions:
You cannot specify that XML input fields be loaded into non-XML columns, such as CHAR
or VARCHAR columns.
DB2 ignores any specified FREEPAGE and PCTFREE values until the next time that you
run the REORG utility on this data.
If you specify PREFORMAT, DB2 preformats the base table space, but not the XML table
space.
You cannot directly load the document ID column of the base table space.
You cannot specify a default value for an XML column.
You can load XML values that are greater than 32 KB by using file reference variables in
the LOAD utility, or using applications with SQL XML as file reference variables.
The XML input file contains the entire XML record and the name of this file is stored in the
normal load input file as a CHAR or VARCHAR field. Therefore, rather than containing the
whole XML record, the normal input file now only contains a file name, which in most cases
no longer causes the sequential file to reach the 32 KB limit.
Additional keywords have been added to the CHAR and VARCHAR field specifications of the
LOAD utility to support a file name as the input for the actual XML record:
BLOBF: The input field contains the name of a file with a BLOB value.
CLOBF: The input field contains the name of a file with a CLOB value.
DBCLOBF: The input field contains the name of a file with a DBCLOB value.
In case of CLOBF and DBCLOBF, CCSID conversions are done when the CCSID of the input
data differs from the CCSID of the table space. (EBCDIC, ASCII, UNICODE, or CCSID
When the input field of a BLOBF, CLOBF, or DBCLOBF is NULL, the resulting XML value is
NULL (null indicator field for the CHAR or VARCHAR field specified in the NULLIF keyword s
hex FF).
Example 9-10 shows the JCL for the LOAD utility using file reference variable and the output
of the utility run.
Example 9-10 LOAD utility JCL (using file reference variable) and output
//XMLR4LD JOB (999,POK),'DB0B COBOL',CLASS=A,
// MSGCLASS=T,NOTIFY=&SYSUID,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//*
//LOAD1 EXEC DSNUPROC,SYSTEM=DB0B,UID=''
//SYSREC DD DSN=[Link],DISP=SHR
//SYSERR DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),UNIT=SYSDA,
// SPACE=(4096,(20,20),,,ROUND)
//SYSDISC DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),UNIT=SYSDA,
// SPACE=(4096,(20,20),,,ROUND)
//SYSMAP DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),UNIT=SYSDA,
// SPACE=(4096,(20,20),,,ROUND)
//SYSUT1 DD DSN=[Link].SYSUT1,
// DISP=(MOD,DELETE,CATLG),UNIT=SYSDA,
// SPACE=(4096,(20,20),,,ROUND)
//UTPRINT DD SYSOUT=*
//SORTOUT DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),UNIT=SYSDA,
// SPACE=(4096,(20,20),,,ROUND)
//[Link] DD *
LOAD DATA REPLACE
INTO TABLE XMLR4.BK_TO_CSTMR_STMT
(BK_TO_CSTMR_STMT POSITION(1:25) CHAR CLOBF)
/*
1DSNU000I 300 [Link].57 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = XMLR4.XMLR4LD
DSNU1044I 300 [Link].61 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 300 [Link].62 DSNUGUTC - LOAD DATA REPLACE
DSNU650I -DB0B 300 [Link].62 DSNURWI - INTO TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU650I -DB0B 300 [Link].62 DSNURWI - (BK_TO_CSTMR_STMT POSITION(1:25) CHAR CLOBF)
DSNU350I -DB0B 300 [Link].31 DSNURRST - EXISTING RECORDS DELETED FROM TABLESPACE
DSNU304I -DB0B 300 [Link].47 DSNURWT - (RE)LOAD PHASE STATISTICS - NUMBER OF RECORDS=1
FOR TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU1147I -DB0B 300 [Link].47 DSNURWT - (RE)LOAD PHASE STATISTICS - TOTAL NUMBER OF
RECORDS LOADED=1 FOR TABLESPACE [Link]
DSNU302I 300 [Link].48 DSNURILD - (RE)LOAD PHASE STATISTICS - NUMBER OF INPUT RECORDS
PROCESSED=1
DSNU300I 300 [Link].48 DSNURILD - (RE)LOAD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU349I -DB0B 300 [Link].54 DSNURBXA - BUILD PHASE STATISTICS - NUMBER OF KEYS=1 FOR
INDEX XMLR4.I_DOCIDBK_TO_CSTMR_STMT
DSNU258I 300 [Link].54 DSNURBXD - BUILD PHASE STATISTICS - NUMBER OF INDEXES=1
DSNU259I 300 [Link].54 DSNURBXD - BUILD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU010I 300 [Link].55 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0
Example 9-11 LOAD utility JCL and output (input to load is in binary format)
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//DSNUPROC.SORTWK01 DD DSN=XMLR4.SORTWK01,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//DSNUPROC.SORTWK02 DD DSN=XMLR4.SORTWK02,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//DSNUPROC.SORTWK03 DD DSN=XMLR4.SORTWK03,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//DSNUPROC.SORTWK04 DD DSN=XMLR4.SORTWK04,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=[Link].REC00,
// DISP=OLD
//DSNUPROC.SYSUT1 DD DSN=XMLR4.SYSUT1,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD *
Note: The LOAD control statement is the output of the UNLOAD utility run, as shown in
Example 9-26 on page 226. We set POSITION(3) because positions 3 and 4 contain the
length of the XML document. Apply the PTF for APAR PM29986 if you want to use
POSITION(*).
Example 9-12 LOAD utility JCL and output (input to load is in spanned record format)
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//DSNUPROC.SORTWK01 DD DSN=XMLR4.SORTWK01,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//DSNUPROC.SORTWK02 DD DSN=XMLR4.SORTWK02,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//DSNUPROC.SORTWK03 DD DSN=XMLR4.SORTWK03,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//DSNUPROC.SORTWK04 DD DSN=XMLR4.SORTWK04,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=[Link],
// DISP=OLD
//DSNUPROC.SYSUT1 DD DSN=XMLR4.SYSUT1,
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=[Link],
// DISP=(MOD,DELETE,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD *
LOAD DATA INDDN SYSREC LOG NO RESUME YES
EBCDIC CCSID(00037,00000,00000)
FORMAT SPANNED YES
INTO TABLE "XMLR4"."BK_TO_CSTMR_STMT"
WHEN(00001:00002) = X'0003'
NUMRECS 1
( "DSN_NULL_IND_00001" POSITION( 00003) CHAR(1)
, "MSG_ID"
POSITION( 00004) VARCHAR
NULLIF(DSN_NULL_IND_00001)=X'FF'
, "DSN_NULL_IND_00002" POSITION( *) CHAR(1)
, "MSG_CRE_DT_TM"
POSITION( *) TIMESTAMP WITH TIME ZONE EXTERNAL(032)
NULLIF(DSN_NULL_IND_00002)=X'FF'
, "BK_TO_CSTMR_STMT"
NOTE: The LOAD control statement is the output of UNLOAD utility run shown in Example 9-27 on page 227.
1DSNU000I 309 [Link].66 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 309 [Link].69 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 309 [Link].70 DSNUGUTC - LOAD DATA INDDN SYSREC LOG NO RESUME YES EBCDIC CCSID(37, 0, 0) FORMAT SPANNED YES
DSNU650I -DB0B 309 [Link].70 DSNURWI - INTO TABLE "XMLR4". "BK_TO_CSTMR_STMT" WHEN(1:2)=X'0003' NUMRECS 1
DSNU650I -DB0B 309 [Link].70 DSNURWI - ("DSN_NULL_IND_00001" POSITION(3) CHAR(1),
DSNU650I -DB0B 309 [Link].70 DSNURWI - "MSG_ID" POSITION(4) VARCHAR NULLIF(DSN_NULL_IND_00001)=X'FF',
DSNU650I -DB0B 309 [Link].70 DSNURWI - "DSN_NULL_IND_00002" POSITION(*) CHAR(1),
DSNU650I -DB0B 309 [Link].70 DSNURWI - "MSG_CRE_DT_TM" POSITION(*) TIMESTAMP WITH TIME ZONE EXTERNAL(32)
NULLIF(DSN_NULL_IND_00002)=X'FF',
DSNU650I -DB0B 309 [Link].70 DSNURWI - "BK_TO_CSTMR_STMT" POSITION(*) XML PRESERVE WHITESPACE)
DSNU304I -DB0B 309 [Link].89 DSNURWT - (RE)LOAD PHASE STATISTICS - NUMBER OF RECORDS=1 FOR TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU1147I -DB0B 309 [Link].89 DSNURWT - (RE)LOAD PHASE STATISTICS - TOTAL NUMBER OF RECORDS LOADED=1 FOR TABLESPACE [Link]
DSNU302I 309 [Link].89 DSNURILD - (RE)LOAD PHASE STATISTICS - NUMBER OF INPUT RECORDS PROCESSED=1
DSNU300I 309 [Link].89 DSNURILD - (RE)LOAD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU349I -DB0B 309 [Link].95 DSNURBXA - BUILD PHASE STATISTICS - NUMBER OF KEYS=1 FOR INDEX XMLR4.I_DOCIDBK_TO_CSTMR_STMT
DSNU258I 309 [Link].95 DSNURBXD - BUILD PHASE STATISTICS - NUMBER OF INDEXES=1
DSNU259I 309 [Link].95 DSNURBXD - BUILD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU380I -DB0B 309 [Link].96 DSNUGSRX - TABLESPACE [Link] PARTITION 1 IS IN COPY PENDING
DSNU380I -DB0B 309 [Link].96 DSNUGSRX - TABLESPACE DSN00242.XBKR0000 PARTITION 1 IS IN COPY PENDING
DSNU010I 309 [Link].96 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4
For UNLOAD, SPANNED with BINARY XML performs significantly better than other formats.
Use SPANNED if possible rather than file references.
9.8 MERGECOPY
The MERGECOPY utility performs either of the following merges:
Merges incremental image copies to produce a merged incremental image copy,
Merges full image copy with incremental image copies to produce a full image copy of the
XML table spaces.
Example 9-13 shows the JCL for MERGECOPY utility and the output of the utility run. This
utility run merges the full image copy taken in Example 9-3 on page 191 and the incremental
image copy taken in Example 9-4 on page 193.
1DSNU000I 314 [Link].98 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 314 [Link].01 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 314 [Link].02 DSNUGUTC - TEMPLATE A
DSN(&DB..&SN..&IC..D&DATE..T&TIME..COPY)
DSNU1035I 314 [Link].02 DSNUJTDR - TEMPLATE STATEMENT PROCESSED SUCCESSFULLY
9.9 QUIESCE
When you specify QUIESCE TABLESPACESET, the table space set includes related XML
objects. You may specify that you want to quiesce the XML table space, base table space, or
both of them, plus related index spaces if they are copy-enabled.
All table spaces that are involved in a versioning relationship are quiesced when QUIESCE is
run on either the system-maintained temporal table or the history table space. Auxiliary LOB
and XML table spaces on both system-maintained temporal table spaces and history table
spaces are included.
Example 9-14 shows the JCL for the QUIESCE utility and the output of the utility run.
Notice that only the table spaces are included. Indexes are included only if they are
copy-enabled.
Figure 9-3 shows how to alter the index definitions to make them copy-enabled.
When you process both NODEID indexes and XML indexes together, they are processed
sequentially. First, the NODEID index is processed and then the XML index.
Example 9-16 shows the JCL for the REBUILD utility and the output of the utility run.
The VERIFYSET option does not apply to point-in-time recoveries of catalog and directory
objects.
We now want to take the table space back to the full image copy before we perform the partial
update to the XML document.
-DISPLAY DB(DSN00242)
SELECT XMLSERIALIZE(
XMLQUERY(
'declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
/Document/BkToCstmrStmt/Stmt/Bal/Amt[../Tp/CdOrPrtry/Cd="CLBD"]'
PASSING BK_TO_CSTMR_STMT) AS CLOB(500))
FROM BK_TO_CSTMR_STMT;
<Amt xmlns:xsi="[Link]
xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02" Ccy="SEK">900000</Amt>
DSNE610I NUMBER OF ROWS DISPLAYED IS 1
Figure 9-5 Content of the XML document
Example 9-17 on page 212 shows the JCL for RECOVER utility to recover the base table
space to the LRSN value associated with the full image copy taken before the partial update
to the XML document was done.
Note: The RBA value for the TOLOGPOINT is the LRSN value associated with the full
image copy shown in Example 9-21 on page 219. It is important to ensure that both the
base table space and the XML table space are recovered to the same point-in-time.
Example 9-18 shows the JCL with the revised RECOVER utility control statement and output
of the utility run.
Example 9-18 RECOVER TABLESPACE utility JCL (and modified control statement) and output
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//[Link] DD *
RECOVER TABLESPACE [Link]
TABLESPACE DSN00242.XBKR0000
TOLOGPOINT X'000069667C5E'
1DSNU000I 315 [Link].07 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 315 [Link].10 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 315 [Link].10 DSNUGUTC - RECOVER TABLESPACE [Link] TABLESPACE
DSN00242.XBKR0000
TOLOGPOINT X'000069667C5E'
DSNU532I 315 [Link].11 DSNUCBMD - RECOVER TABLESPACE [Link] START
DSNU515I 315 [Link].11 DSNUCBAL - THE IMAGE COPY DATA SET
[Link] WITH
DATE=20101110 AND TIME=181248
IS PARTICIPATING IN RECOVERY OF TABLESPACE [Link]
DSNU504I 315 [Link].33 DSNUCBMD - MERGE STATISTICS FOR TABLESPACE [Link]
-
NUMBER OF COPIES=1
NUMBER OF PAGES MERGED=3
ELAPSED TIME=[Link]
DSNU532I 315 [Link].34 DSNUCBMD - RECOVER TABLESPACE DSN00242.XBKR0000 START
DSNU515I 315 [Link].34 DSNUCBAL - THE IMAGE COPY DATA SET
[Link] WITH
DATE=20101110 AND TIME=181248
IS PARTICIPATING IN RECOVERY OF TABLESPACE DSN00242.XBKR0000
DSNU504I 315 [Link].54 DSNUCBMD - MERGE STATISTICS FOR TABLESPACE DSN00242.XBKR0000
-
The base table space and XML table space are now recovered to the same point-in-time. DB2
places the DOCID and NODEID indexes in REBUILD-pending state (RBDP) to ensure the
indexes are consistent with the data.
-DISPLAY DB(DSN00242)
We rebuild the indexes. Example 9-16 on page 208 shows the JCL for the REBUILD INDEX
utility and the output of the utility run.
-DISPLAY DB(DSN00242)
SELECT XMLSERIALIZE(
XMLQUERY(
'declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
/Document/BkToCstmrStmt/Stmt/Bal/Amt[../Tp/CdOrPrtry/Cd="CLBD"]'
PASSING BK_TO_CSTMR_STMT) AS CLOB(500))
FROM BK_TO_CSTMR_STMT;
<Amt xmlns:xsi="[Link]
xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02"
Ccy="SEK">435678.50</Amt>
DSNE610I NUMBER OF ROWS DISPLAYED IS 1
Note: If the DOCID and NODEID indexes are enabled for image copy, Figure 9-6 on
page 213 would show RECP instead of RBDP. Instead of rebuilding the indexes you would
recover the indexes by using RECOVER INDEX utility, which uses the image copy you
would have established for these indexes by using the COPY utility.
When you specify the name of the base table space in the REORG statement, DB2
reorganizes only that table space and not any related XML objects. If you want DB2 to
reorganize the XML objects, you must specify those object names.
When you run REORG on an XML table space that supports XML versions, REORG discards
rows for versions of an XML document that are no longer needed.
For XML table spaces and base table spaces with XML columns, you cannot specify the
following options in the REORG statement:
DISCARD
REBALANCE
UNLOAD EXTERNAL
If you specify a base table space with the STATISTICS keyword, DB2 does not gather
statistics for the related XML table space or its indexes.
If large amounts of data are deleted from a partition-by-growth universal table space,
including XML table spaces, run the REORG TABLESPACE utility with SHRLEVEL
REFERENCE or SHRLEVEL CHANGE on the entire table space to reclaim physical space
from the partition-by-growth and XML table spaces.
Do not use REORG UNLOAD ONLY to propagate data. When you specify the UNLOAD
ONLY option, REORG unloads only the data that physically resides in the base table space;
LOB and XML columns are not unloaded. For purposes of data propagation, use UNLOAD or
REORG UNLOAD EXTERNAL instead.
Example 9-19 on page 216 shows the JCL for the REORG TABLESPACE utility, and the
output of the utility run.
1DSNU000I 319 [Link].66 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 319 [Link].68 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 319 [Link].69 DSNUGUTC - REORG TABLESPACE [Link]
DSNU251I 319 [Link].81 DSNURULD - UNLOAD PHASE STATISTICS - NUMBER OF RECORDS UNLOADED=1 FOR TABLESPACE
[Link] PART 1
DSNU252I 319 [Link].81 DSNURULD - UNLOAD PHASE STATISTICS - NUMBER OF RECORDS UNLOADED=1 FOR TABLESPACE
[Link]
DSNU250I 319 [Link].81 DSNURULD - UNLOAD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU303I -DB0B 319 [Link].21 DSNURWT - (RE)LOAD PHASE STATISTICS - NUMBER OF RECORDS=1 FOR TABLE
XMLR4.BK_TO_CSTMR_STMT PART=1
DSNU304I -DB0B 319 [Link].21 DSNURWT - (RE)LOAD PHASE STATISTICS - NUMBER OF RECORDS=1 FOR TABLE
XMLR4.BK_TO_CSTMR_STMT
DSNU302I 319 [Link].22 DSNURILD - (RE)LOAD PHASE STATISTICS - NUMBER OF INPUT RECORDS PROCESSED=1
DSNU300I 319 [Link].22 DSNURILD - (RE)LOAD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU042I 319 [Link].22 DSNUGSOR - SORT PHASE STATISTICS -
NUMBER OF RECORDS=1
ELAPSED TIME=[Link]
DSNU349I -DB0B 319 [Link].28 DSNURBXA - BUILD PHASE STATISTICS - NUMBER OF KEYS=1 FOR INDEX
XMLR4.I_DOCIDBK_TO_CSTMR_STMT
DSNU258I 319 [Link].28 DSNURBXD - BUILD PHASE STATISTICS - NUMBER OF INDEXES=1
DSNU259I 319 [Link].28 DSNURBXD - BUILD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU421I 319 [Link].30 DSNUGFUM - START OF DFSMS MESSAGES
1PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2010.319 18:06
-ADR030I (SCH)-PRIME( 0), DCB VALUES HAVE BEEN MODIFIED FOR SYSPRINT. BLKSIZE VALUE MODIFIED FROM 0 TO 128
COPY DATASET(INCLUDE( -
[Link].I0001.A001 )) -
RENAMEU( -
([Link].I0001.A001 , -
[Link].N00001.C2RPDUCT )) -
REPUNC ALLDATA(*) ALLEXCP CANCELERROR SHARE -
WRITECHECK TOLERATE(ENQF)
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY '
ADR109I (R/I)-RI01 (01), 2010.319 [Link] INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED
ADR050I (001)-PRIME(01), DFSMSDSS INVOKED VIA APPLICATION INTERFACE
ADR016I (001)-PRIME(01), RACF® LOGGING OPTION IN EFFECT FOR THIS TASK
1PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2010.319 18:06
- COPY DATASET(INCLUDE( -
[Link].DSN00242.XBKR0000.I0001.A001 )) -
RENAMEU( -
([Link].DSN00242.XBKR0000.I0001.A001 , -
DB0BI.DSN00242.XBKR0000.N00001.C2RPDUYM )) -
REPUNC ALLDATA(*) ALLEXCP CANCELERROR SHARE -
WRITECHECK TOLERATE(ENQF)
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY '
ADR109I (R/I)-RI01 (01), 2010.319 [Link] INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED
ADR050I (001)-PRIME(01), DFSMSDSS INVOKED VIA APPLICATION INTERFACE
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
0ADR006I (001)-STEND(01), 2010.319 [Link] EXECUTION BEGINS
0ADR711I (001)-NEWDS(01), DATA SET [Link].DSN00242.XBKR0000.I0001.A001 HAS BEEN ALLOCATED WITH NEWNAME
DB0BI.DSN00242.XBKR0000.N00001.C2RPDUYM USING STORCLAS DB0BDATA, DATACLAS DB0B, AND
MGMTCLAS MCDB22
0ADR806I (001)-T0MI (03), DATA SET [Link].DSN00242.XBKR0000.I0001.A001 COPIED USING A FAST REPLICATION
FUNCTION
0ADR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 1 OF 1 DATA SETS WERE SELECTED: 0 FAILED
SERIALIZATION AND 0 FAILED FOR OTHER REASONS
0ADR454I (001)-DDDS (01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED
0 [Link].DSN00242.XBKR0000.I0001.A001
0ADR006I (001)-STEND(02), 2010.319 [Link] EXECUTION ENDS
0ADR013I (001)-CLTSK(01), 2010.319 [Link] TASK COMPLETED WITH RETURN CODE 0000
0ADR012I (SCH)-DSSU (01), 2010.319 [Link] DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0000
DSNU422I 319 [Link].27 DSNUGFCD - END OF DFSMS MESSAGE
DSNU010I 319 [Link].29 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0
The REORG table space utility reorganizes also the DOCID index (and any user-defined
indexes) when reorganizing the base table space, and the NODEID index when reorganizing
the XML table space.
You can reorganize only the indexes by using the REORG INDEX utility.
The most common use for the REPAIR utility for XML objects is to take corrective action after
you run CHECK DATA with SHRLEVEL CHANGE on a table space with XML columns.
CHECK DATA with SHRLEVEL CHANGE operates on shadow data sets, so it does not
modify XML columns or XML table spaces. Instead, CHECK DATA generates REPAIR
statements that you can run to delete invalid XML documents and to mark the corresponding
XML columns as invalid.
For examples of invoking the REPAIR utility when diagnosing problems with XML data, see
10.5, “Diagnostics” on page 242.
9.14 REPORT
When you specify REPORT TABLESPACESET, the output report includes XML objects in the
list of members in the table space set.
The sample output in Example 9-20 shows a table space set for a table that contains an XML
column.
Example 9-20 REPORT utility JCL (and TABLESPACESET option) and output
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//[Link] DD *
REPORT TABLESPACESET [Link]
1DSNU000I 315 [Link].26 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 315 [Link].28 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 315 [Link].28 DSNUGUTC - REPORT TABLESPACESET [Link]
DSNU587I -DB0B 315 [Link].29 DSNUPSET - REPORT TABLESPACE SET WITH TABLESPACE
[Link]
TABLESPACE : [Link]
TABLE : XMLR4.BK_TO_CSTMR_STMT
INDEXSPACE : [Link]
INDEX : XMLR4.I_DOCIDBK_TO_CSTMR_STMT
TABLESPACE : [Link]
When you specify REPORT RECOVERY, the output report includes recovery-related
information. Use REPORT RECOVERY to find information that is necessary for recovering a
table space, index, or a table space and all of its indexes. This approach is particularly useful
for point-in-time recovery.
Example 9-21 shows the JCL for the REPORT utility with the RECOVERY option for the base
table space and the output of the utility run.
Example 9-21 REPORT utility JCL (and RECOVERY option for base table space) and output
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//[Link] DD *
REPORT RECOVERY TABLESPACE [Link]
1DSNU000I 315 [Link].42 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 315 [Link].45 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 315 [Link].45 DSNUGUTC - REPORT RECOVERY TABLESPACE [Link]
DSNU581I -DB0B 315 [Link].45 DSNUPREC - REPORT RECOVERY TABLESPACE [Link]
DSNU593I -DB0B 315 [Link].46 DSNUPREC - REPORT RECOVERY ENVIRONMENT RECORD:
MINIMUM RBA: 000000000000
MAXIMUM RBA: FFFFFFFFFFFF
MIGRATING RBA: 000000000000
DSNU582I -DB0B 315 [Link].46 DSNUPPCP - REPORT RECOVERY TABLESPACE [Link]
SYSCOPY ROWS AND SYSTEM LEVEL BACKUPS
TIMESTAMP = 2010-11-04-22.02.43.096801, IC TYPE = *C*, SHR LVL = , DSNUM = 0000,
START LRSN =000066569186
DEV TYPE = , IC BACK = , STYPE = L, FILE SEQ = 0000,
PIT LRSN = 000000000000
LOW DSNUM = 0000, HIGH DSNUM = 0000, OLDEST VERSION = 0000, LOGICAL PART = 0000,
LOGGED = Y, TTYPE =
JOBNAME = , AUTHID = , COPYPAGESF = -1.0E+00
NPAGESF = -1.0E+00 , CPAGESF = -1.0E+00
DSNAME = [Link] , MEMBER NAME = ,
INSTANCE = 01, RELCREATED = M
................................................................................
................................................................................
................................................................................
TIMESTAMP = 2010-11-10-18.12.48.246523, IC TYPE = F , SHR LVL = R, DSNUM = 0000,
START LRSN =000069667C5E
DEV TYPE = 3390 , IC BACK = , STYPE = , FILE SEQ = 0000,
PIT LRSN = 000000000000
LOW DSNUM = 0001, HIGH DSNUM = 0001, OLDEST VERSION = 0000, LOGICAL PART = 0000,
LOGGED = Y, TTYPE =
JOBNAME = XMLR4LD , AUTHID = XMLR4 , COPYPAGESF = 3.0E+00
NPAGESF = 3.4E+01 , CPAGESF = 0.0E0
DSNAME = [Link] , MEMBER NAME = ,
INSTANCE = 01, RELCREATED = M
DSNU010I 315 [Link].46 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0
Example 9-22 shows the JCL for the REPORT utility with the RECOVERY option for the XML
table space and the output of the utility run.
Example 9-22 REPORT utility JCL (and TRECOVERY option for XML table space) and output
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//[Link] DD *
REPORT RECOVERY TABLESPACE DSN00242.XBKR0000
1DSNU000I 315 [Link].65 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 315 [Link].68 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 315 [Link].68 DSNUGUTC - REPORT RECOVERY TABLESPACE DSN00242.XBKR0000
DSNU581I -DB0B 315 [Link].68 DSNUPREC - REPORT RECOVERY TABLESPACE DSN00242.XBKR0000
DSNU593I -DB0B 315 [Link].69 DSNUPREC - REPORT RECOVERY ENVIRONMENT RECORD:
MINIMUM RBA: 000000000000
MAXIMUM RBA: FFFFFFFFFFFF
MIGRATING RBA: 000000000000
DSNU582I -DB0B 315 [Link].69 DSNUPPCP - REPORT RECOVERY TABLESPACE DSN00242.XBKR0000
SYSCOPY ROWS AND SYSTEM LEVEL BACKUPS
TIMESTAMP = 2010-11-04-22.02.43.211430, IC TYPE = *C*, SHR LVL = , DSNUM = 0000,
START LRSN =00006656ED79
DEV TYPE = , IC BACK = , STYPE = L, FILE SEQ = 0000,
PIT LRSN = 000000000000
LOW DSNUM = 0000, HIGH DSNUM = 0000, OLDEST VERSION = 0000, LOGICAL PART = 0000,
LOGGED = Y, TTYPE =
JOBNAME = , AUTHID = , COPYPAGESF = -1.0E+00
NPAGESF = -1.0E+00 , CPAGESF = -1.0E+00
Although we do not show the complete output of the REPORT utility, we show only the
relevant entries to demonstrate partial recovery of the table space.
The REPORT utility output shows the entries for the full, incremental, and merged full image
copy for the base table space in Example 9-21 on page 219 and for the XML table space in
Example 9-22 on page 220.
RUNSTATS INDEX ignores the following keywords for XML indexes or NODEID indexes:
KEYCARD
FREQVAL MOST/LEAST/BOTH
HISTOGRAM
XML indexes are related to XML tables, and not to the associated base tables. If you specify a
base table space and an XML index in the same RUNSTATS control statement, DB2
generates an error. When you run RUNSTATS against a base table, RUNSTATS collects
statistics only for indexes on the base table, including the document ID index.
RUNSTATS TABLESPACE does not collect histogram statistics for XML table spaces.
RUNSTATS INDEX does not collect histogram statistics for XML NODEID indexes or XML
indexes.
Example 9-23 shows the JCL for the RUNSTATS utility for the base table space (and XML
table space) and the output of the utility run.
1DSNU000I 319 [Link].28 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 319 [Link].33 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 319 [Link].33 DSNUGUTC - RUNSTATS TABLESPACE [Link] INDEX(ALL)
DSNU610I -DB0B 319 [Link].40 DSNUSUTP - SYSTABLEPART CATALOG UPDATE FOR
[Link] SUCCESSFUL
DSNU610I -DB0B 319 [Link].40 DSNUSUPT - SYSTABSTATS CATALOG UPDATE FOR
XMLR4.BK_TO_CSTMR_STMT SUCCESSFUL
DSNU610I -DB0B 319 [Link].40 DSNUSUTB - SYSTABLES CATALOG UPDATE FOR
XMLR4.BK_TO_CSTMR_STMT SUCCESSFUL
DSNU610I -DB0B 319 [Link].40 DSNUSUTS - SYSTABLESPACE CATALOG UPDATE FOR
[Link] SUCCESSFUL
DSNU610I -DB0B 319 [Link].41 DSNUSUIP - SYSINDEXPART CATALOG UPDATE FOR
XMLR4.I_DOCIDBK_TO_CSTMR_STMT SUCCESSFUL
DSNU610I -DB0B 319 [Link].41 DSNUSUCO - SYSCOLUMNS CATALOG UPDATE FOR
XMLR4.I_DOCIDBK_TO_CSTMR_STMT SUCCESSFUL
DSNU610I -DB0B 319 [Link].41 DSNUSUIX - SYSINDEXES CATALOG UPDATE FOR
XMLR4.I_DOCIDBK_TO_CSTMR_STMT SUCCESSFUL
DSNU610I -DB0B 319 [Link].41 DSNUSUCD - SYSCOLDIST CATALOG UPDATE FOR
XMLR4.I_DOCIDBK_TO_CSTMR_STMT SUCCESSFUL
DSNU620I -DB0B 319 [Link].41 DSNUSEOF - RUNSTATS CATALOG TIMESTAMP =
2010-11-15-19.06.31.341899
DSNU010I 319 [Link].50 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0
9.16 UNLOAD
You can unload XML data to output data records or to separate files. Use either of the
following methods to XML columns can be unloaded by using either of the following methods:
The XML column can be unloaded to the output records. XML column value can be placed
in the OUTPUT record with or without any other unloading column values. The output
record can be in non-delimited or delimited format:
– For a non-delimited format, the XML column is handled like a variable character field
with a 2-byte length preceding the XML value.
– For a delimited format, no byte length is present. If the total output record length is
more than 32 KB, unload the record in spanned record format by specifying the
SPANNED YES option.
The XML column can be unloaded to a separate file whether the XML column length is
less than 32 KB or not.
The output data can be in the textual XML format or the binary XML format. Data that is
unloaded can be in the non-delimited or delimited format.
To unload XML data directly to output record, specify XML as the output field type. If the
output is a non-delimited format, a 2-byte length precedes the value of the XML. For delimited
output, no length field is present. XML is the only acceptable field type when unloading the
XML directly to the output record. No data type conversion applies and you cannot specify
FROMCOPY.
If the input data is in Extensible Dynamic Binary XML DB2 Client/Server Binary XML Format
(binary XML format), you need to specify BINARYXML. To unload XML data to a separate file:
In the UNLOAD utility control statement, specify BLOBF, CLOBF or DBCLOBF. These
keywords indicate that the output column contains the name of a file to which the XML
value is to be unloaded. Also specify either CHAR or VARCHAR instead of XML. Do not
specify FROMCOPY.
Use the template control statement to create the XML output file and filename. If data sets
are not created and the DSN type is not specified on the template, UNLOAD will use PDS
In the UNLOAD statement, specify the base table space. You cannot specify the XML table
space.
Example 9-24 shows the JCL for the UNLOAD utility and the output of the utility run.
1DSNU000I 301 [Link].19 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 301 [Link].21 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 301 [Link].22 DSNUGUTC - UNLOAD TABLESPACE [Link]
DSNU650I -DB0B 301 [Link].22 DSNUUGMS - FROM TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU650I -DB0B 301 [Link].22 DSNUUGMS - (BK_TO_CSTMR_STMT POSITION(*) XML)
DSNU253I 301 [Link].24 DSNUUNLD - UNLOAD PHASE STATISTICS - NUMBER OF RECORDS
UNLOADED=1 FOR TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU252I 301 [Link].24 DSNUUNLD - UNLOAD PHASE STATISTICS - NUMBER OF RECORDS
UNLOADED=1 FOR TABLESPACE [Link]
DSNU250I 301 [Link].24 DSNUUNLD - UNLOAD PHASE COMPLETE, ELAPSED TIME=[Link]
DSNU010I 301 [Link].25 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0
NOTE: SYSREC shows the name of the data set which receives the XML document unloaded by
UNLOAD utility.
SYSPUNCH shows the name of the data set which has the LOAD utility control statements
generated by UNLOAD utility.
The first few characters of the XML document in SYSREC data set are shown below:
7<?xml version="1.0" encoding="IBM037"?><Document xmlns:xsi="http://
0001F46A994A89A89977F4F748989889877CCDFFF7664C98A989A4A999A7AA8778AA9766
03017CF74305592965EF1B0F055364957EF924037FFEC46344553074352A729EF8337A11
A 2-byte length precedes the XML value.
The LOAD utility control statement in SYSPUNCH data set is shown below:
LOAD DATA INDDN SYSREC LOG NO RESUME YES
EBCDIC CCSID(00037,00000,00000)
INTO TABLE "XMLR4"."BK_TO_CSTMR_STMT"
WHEN(00001:00002) = X'0003'
NUMRECS 1
( "BK_TO_CSTMR_STMT"
POSITION( *) XML PRESERVE WHITESPACE
)
Example 9-25 UNLOAD utility JCL (using file reference variable) and output
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//[Link] DD DSN=XMLR4.UNLOAD1,
// DISP=(MOD,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=XMLR4.LOADCTL1,
// DISP=(MOD,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD *
TEMPLATE TCLOBF UNIT(SYSDA) DISP(MOD,CATLG,DELETE)
DSN(&USERID..&DB..&TS..T&TI..UFILEREF)
UNLOAD TABLESPACE [Link]
FROM TABLE XMLR4.BK_TO_CSTMR_STMT
(BK_TO_CSTMR_STMT POSITION(*) VARCHAR CLOBF TCLOBF)
1DSNU000I 301 [Link].80 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 301 [Link].82 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 301 [Link].83 DSNUGUTC - TEMPLATE TCLOBF UNIT(SYSDA) DISP(MOD,
CATLG, DELETE) DSN(&USERID..&DB..&TS..T&TI..UFILEREF)
DSNU1035I 301 [Link].83 DSNUJTDR - TEMPLATE STATEMENT PROCESSED SUCCESSFULLY
0DSNU050I 301 [Link].83 DSNUGUTC - UNLOAD TABLESPACE [Link]
DSNU650I -DB0B 301 [Link].83 DSNUUGMS - FROM TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU650I -DB0B 301 [Link].83 DSNUUGMS - (BK_TO_CSTMR_STMT POSITION(*)
VARCHAR CLOBF TCLOBF)
DSNU1038I 301 [Link].89 DSNUGDYN - DATASET ALLOCATED. TEMPLATE=TCLOBF
DDNAME=SYS00001
DSN=[Link]
DSNU253I 301 [Link].92 DSNUUNLD - UNLOAD PHASE STATISTICS - NUMBER OF
RECORDS UNLOADED=1 FOR TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU252I 301 [Link].92 DSNUUNLD - UNLOAD PHASE STATISTICS - NUMBER OF
RECORDS UNLOADED=1 FOR TABLESPACE [Link]
DSNU250I 301 [Link].93 DSNUUNLD - UNLOAD PHASE COMPLETE, ELAPSED
TIME=[Link]
DSNU010I 301 [Link].94 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN
CODE=0
NOTE: SYSREC shows the name of the data set derived from the Template definition
which has the XML document as shown below:
[Link](C1XSJ2ZY)
The first few characters of the XML document are shown below:
<?xml version="1.0" encoding="IBM037"?><Document xmlns:xsi="[Link]
46A994A89A89977F4F748989889877CCDFFF7664C98A989A4A999A7AA8778AA9766AAA
CF74305592965EF1B0F055364957EF924037FFEC46344553074352A729EF8337A1166A
The XML document starts from position 1.
The LOAD utility control statement in SYSPUNCH data set is shown below:
Example 9-26 UNLOAD utility JCL (to unload XML data in binary) and output
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//[Link] DD DSN=[Link].REC00,
// DISP=(MOD,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD DSN=[Link],
// DISP=(MOD,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD *
UNLOAD DATA
FROM TABLE XMLR4.BK_TO_CSTMR_STMT
(BK_TO_CSTMR_STMT XML BINARYXML)
1DSNU000I 308 [Link].66 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TEMP
DSNU1044I 308 [Link].69 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
0DSNU050I 308 [Link].69 DSNUGUTC - UNLOAD DATA
DSNU650I -DB0B 308 [Link].69 DSNUUGMS - FROM TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU650I -DB0B 308 [Link].69 DSNUUGMS - (BK_TO_CSTMR_STMT XML BINARYXML)
DSNU253I 308 [Link].76 DSNUUNLD - UNLOAD PHASE STATISTICS - NUMBER OF
RECORDS UNLOADED=1 FOR TABLE XMLR4.BK_TO_CSTMR_STMT
DSNU252I 308 [Link].76 DSNUUNLD - UNLOAD PHASE STATISTICS - NUMBER OF
RECORDS UNLOADED=1 FOR TABLESPACE [Link]
DSNU250I 308 [Link].77 DSNUUNLD - UNLOAD PHASE COMPLETE, ELAPSED
TIME=[Link]
NOTE: SYSREC shows the name of the data set which receives the XML document
unloaded by UNLOAD utility.
SYSPUNCH shows the name of the data set which has the LOAD utility control
statements generated by UNLOAD utility.
The first few characters of the XML document in SYSREC data set are shown below:
....-.......ñ.ÌËÑ.ñ.ÇÈÈø...ÏÏÏ.Ï..?ÊÅ......ì(<ëÄÇÁ_/.Ñ>ËÈ/>ÄÁÃñ.ÍÊ>.ÑË?.ËÈÀ.ÑË?.
0003C300000040776142677732277727326762333325445666662667766666427763676377636763
03D4AB510002938398998440AFF777E73EF27F2001F8DC3385D1D9E341E3569E52EA93FA344A93FA
A 2-byte length precedes the XML value.
UNLOAD utility to unload into a VBS data set in spanned record format
To unload data from a table that has large LOB or XML fields, consider unloading the data in
spanned record format to improve performance of read-write operations. When you unload
data in spanned record format, all LOB and XML data for a given table space or table space
partition can be written to an individual sequential file. This file can reside on DASD and can
span multiple volumes. Having such a single sequential file can improve the performance of
read-write operations.
To unload data in spanned record format, specify the SPANNED YES option. Specify in the
field specification list that all LOB and XML data are to be at the end of the record.
Example 9-27 shows the JCL for the UNLOAD utility to unload XML data in spanned record
format and the output of the utility run.
Example 9-27 UNLOAD utility JCL (to unload XML data in spanned record format) and output
//XMLR4LD JOB (999,POK),'DB0B',CLASS=A,
// MSGCLASS=T,NOTIFY=XMLR4,TIME=1440,REGION=0M
/*JOBPARM SYSAFF=SC63,L=9999
// JCLLIB ORDER=([Link])
//UTIL EXEC DSNUPROC,SYSTEM=DB0B,UID='TEMP',UTPROC=''
//[Link] DD DSN=[Link],
// DISP=(MOD,CATLG)
//[Link] DD DSN=[Link].PUNCH3,
// DISP=(MOD,CATLG),
// SPACE=(16384,(20,20),,,ROUND),
// UNIT=SYSDA
//[Link] DD *
UNLOAD DATA SPANNED YES FROM TABLE XMLR4.BK_TO_CSTMR_STMT
(MSG_ID VARCHAR,
MSG_CRE_DT_TM TIMESTAMP WITH TIME ZONE EXTERNAL,
BK_TO_CSTMR_STMT XML)
9.17 DSNTIAUL
Like the UNLOAD utility, the DSNTIAUL sample program also provides two ways to handle
XML data:
Unload XML columns as normal data columns to the SYSRECxx file.
Unload XML columns to a separate file.
In most cases, this method is used only if the XML documents in the table are small.
NOTE:
The first few characters in the unloaded SYSREC00 data set are shown below:
...Ü<?xml version="1.0" encoding="IBM037"?><Document xmlns:xsi="[Link]
001F46A994A89A89977F4F748989889877CCDFFF7664C98A989A4A999A7AA8778AA9766AAA4AF499
001CCF74305592965EF1B0F055364957EF924037FFEC46344553074352A729EF8337A11666B63B69
DSNTIAUL generates in the SYSPUNCH data set the following LOAD control statement:
LOAD DATA LOG NO INDDN SYSREC00 INTO TABLE TBLNAME
(BK_TO_CSTMR_STMT POSITION( 1 ) CLOB )
In the SYSIN DD * if you specify all the column names explicitly as shown below:
SELECT DB2_GENERATED_DOCID_FOR_XML,
MSG_ID,
MSG_CRE_DT_TM,
BK_TO_CSTMR_STMT
FROM XMLR4.BK_TO_CSTMR_STMT ;
DSNTIAUL issues the messages as above including DSNT506I and generates in the SYSPUNCH data
set the following LOAD control statement:
LOAD DATA LOG NO INDDN SYSREC00 INTO TABLE TBLNAME
(DB2_GENERATED_DOCID_FOR_XML POSITION( 1 ) BIGINT NULLIF( 9)='?',
MSG_ID POSITION( 10 ) VARCHAR NULLIF(47)='?',
MSG_CRE_DT_TM POSITION( 48 ) TIMESTAMP WITH TIME ZONE EXTERNAL(32)
NULLIF(80)='?',
BK_TO_CSTMR_STMT POSITION( 81 ) CLOB )
You should edit the LOAD control statement by replacing TBLNAME by the actual table name,
CLOB by XML and POSITION ( 1 ) by POSITION ( 3 ) or
POSITION ( 81 ) by POSITION ( 83 ) depending on how you specify the SELECT statement in
DSNTIAUL, include either RESUME YES or REPLACE, and change
INDDN SYSREC00 to INDDN SYSREC.
You should edit the LOAD control statement by replacing CLOB by XML and
POSITION ( 72 ) by POSITION ( 74 ), include either RESUME YES or REPLACE, and change INDDN
SYSREC00 to INDDN SYSREC.
The data set prefix <prefix> is specified by means of a new DSNTIAUL run-time parameter
named LOBFILE. This parameter is the same one that is used when handling LOBs.
NOTE: In this case, the SYSIN input file contains the name of the base table.
The first few characters in the unloaded SYSREC00 data set are shown below:
..?................................?XMLR4.Q0000000.C0000002.R0000000............
006000000000000000000000000000000006EDDDF4DFFFFFFF4CFFFFFFF4DFFFFFFF000000000000
00F00000000000000000000000000000000F74394B80000000B30000002B90000000000000000000
Notice this data set has only the file name where the XML document is unloaded.
The first few characters in the data set XMLR4.Q0000000.C0000002.R0000000 are:
<?xml version="1.0" encoding="IBM037"?><Document xmlns:xsi="[Link]
You should edit the LOAD control statement to include either RESUME YES or REPLACE, and
change INDDN SYSREC00 to INDDN SYSREC.
In both cases, a sequential data set SYSREC00 containing the normal data fields and the
names of the XML output files is produced. All the XML output files have a name in the
following form (where xxxx can be in the range 0000 - 5882):
XMLR4.Q0000000.C0000006.R000xxxx
The files are dynamically allocated as sequential files with the values:
RECFM=VB,LRECL=27994,BLKSIZE=27998
9.18 DSN1COPY
Use DSN1COPY to copy tables from one subsystem to another. When you copy tables from
one subsystem to another, you must ensure that the version information on the target
subsystem matches the version information on the source subsystem.
Restriction: DB2 XML data is condensed by substituting strings by unique IDs. These
unique IDs are stored in the catalog table [Link] and they are not
available in the related XML table space. Therefore, do not copy XML table spaces from
one subsystem to another using DSN1COPY.
For many of the DBA tasks that are performed with utilities, we include only a brief overview.
Utilities that have additional considerations, with the advent of pureXML, are covered in
Chapter 9, “Utilities with XML” on page 183.
Important: Do not drop these objects after you begin to do XML schema validation.
Doing so can cause unexpected behavior.
2. Define the WLM environment and startup procedure for the C language XSR stored
procedures.
3. Define the WLM environment and startup procedure for the Java language XSR stored
procedures.
Note: The Java stored procedure XSR_COMPLETE must run non-APF authorized.
This step can be accomplished by adding a non-APF-authorized data set to the
STEPLIB concatenation of the WLM procedure.
However, be aware that other Java stored procedures might need to run
APF-authorized, so you might have to create a special WLM procedure for
XSR_COMPLETE.
For detailed information, see “Setting up the XML schema repository” in DB2 10 for z/OS
pureXML Guide, SC19-2981.
The DEFAULT BUFFER POOL FOR USER XML DATA field (TBSBPXML subsystem
parameter) specifies the default buffer pool that is to be used for XML table spaces. The
default is BP16K0.
You may alter the BUFFERPOOL property of the XML table space, which supports the
altering to other 16-KB buffer pools only.
If your DB2 subsystem encounters storage constraints because XML values are using too
much memory, set the XMLVALA and XMLVALS subsystem parameters:
To specify the maximum amount of memory, in KB, for storing XML values for each user,
set XMLVALA. The default is 204800 KB.
To specify the maximum amount of memory, in MB, for storing XML values for the entire
subsystem, set XMLVALS. The default is 10240 MB.
Because DB2 use XML System Services for parsing and validating XML documents, be
attentive to any maintenance offered in this area.
However, be aware of the choices that are made for these objects. Certain properties might
be inherited directly from the base table, some might be inferred from properties of the base
table, and others might be dependant on default values or values of DSNZPARMs.
A good practice is to understand how these properties are derived, so you can plan them or
alter them after the objects have been created. This section describes the most important
properties.
For more information about creation of tables with XML columns and the storage structure for
XML data, see Chapter 4, “Creating and adding XML data” on page 53.
XML table The ALTER TABLE ALTER PARTITION statement is not supported if the
table contains an XML column.
Table 10-2 Table space types for base and XML tables
Base table space XML table space
Simple Partition-by-growth
Segmented Partition-by-growth
Partitioned Range-partitioned
Partition-by-growth Partition-by-growth
Range-partitioned Range-partitioned
For partition-by-growth XML table spaces, there is no correspondence between the partition
in which a particular XML document resides, and the partition of the base table row. The table
spaces grow as needed, and independently of each other.
For partitioned and range-partitioned table spaces, the XML document and the base row
must reside in corresponding partitions. If the base table row moves partition, so does the
XML document. Therefore, the number of rows fitting into a relational partition is limited by the
number of rows that fit into the XML partition.
The DSSIZE of the XML table space is dictated by a combination of the DSSIZE and page
size of the base table. The exact values are listed in Table 10-3.
1 - 4 GB 4 GB 4 GB 4 GB 4 GB
8 GB 32 GB 16 GB 16 GB 16 GB
16 GB 64 GB 32 GB 16 GB 16 GB
32 GB 64 GB 64 GB 32 GB 16 GB
64 GB 64 GB 64 GB 64 GB 64 GB
To understand what impact the decisions made with respect to size and range of partitions, let
us assume that we want to implement the BK_TO_CSTMR_STMT table as a
range-partitioned table with one partition per year. The DDL to create this table is shown in
Example 10-1.
If we want to store 10,000 bank statements each year, this yields the following values (in
round numbers):
For the base table space:
10,000 * 82 bytes = 800 KB
For the XML table space:
10,000 * 4 KB = 40 MB
Therefore, if we simply stay with the (default) DSSIZE of 4 GB and page size of 4 KB, we will
have sufficient space for the data.
However, what if instead of 10,000 bank statements, we have 2 million each year? In this
case, the approximate estimate becomes, as follows:
For the base table space:
2,000,000 * 82 bytes = 160 MB
For the XML table space:
2,000,000 * 4 KB = 7,8 GB
Therefore, even if plenty of space is available for the base table row in each partition that uses
DSSIZE 4G, the limit of the XML table space partition is reached long before the 2 million
rows and this setting imposes a limit on the base table also. An attempt to insert a row when
the XML table space partition is full can result in an SQL code -904, indicating that the XML
table space is unavailable.
The solution is either to use a more granular partitioning key, or to choose a combination of
DSSIZE and page size of the base table space that will result in a larger DSSIZE for the XML
table space.
10.2.4 Compression
Using compression can significantly reduce the amount of disk space needed to store XML
data.
Additionally, when you INSERT, MERGE, or LOAD XML data, a dictionary can be built
specifically for the XML table space if the amount of XML data is large enough. Then, the new
inserted XML data will be compressed.
Note: Real-time statistics (RTS) keeps track of the amount of data for the threshold of
online compression. Apply the PTF for APAR PM22081 to correct RTS errors when LOAD
RESUME is executed on partitioned table spaces.
The compression dictionary is built through these if any of the following statements is true:
The table space or partition is defined with COMPRESS YES.
The table space or partition has no compression dictionary built yet.
The amount of data in the table space is large enough to build the compression dictionary.
You can also compress the XML indexes as shown in Example 10-2.
As Chapter 5, “Validating XML data” on page 75 shows, the XML schema repository offers a
wide range of choices for specifying XML schemas when validating XML documents against a
schema, both for automatic and explicit validation.
You have the option of specifying a schema using any of the following items:
Schema name
URI and location hint
Namespace
Although being able to choose the option you prefer is certainly convenient, a good approach
is to decide and document what method you want to use in your company. This approach can
help ensure that you always have clarity about which XML schema or schemas you are
working with, without having to go through the elaborate rule-set for schema selection.
In addition, a worthwhile plan might be to define a naming standard for the XML schemas,
taking into account that XML schemas can evolve over time and require several versions
available in the XSR at a given time.
Neither of these are technical tasks, but they often lie within the responsibilities of the DBA
and may be good to plan for when starting a new XML project.
Be sure to specify a data type for every XML index. XML indexes support the data types
VARCHAR, DECFLOAT, DATE, and TIMESTAMP. Example 10-3 shows how to create an XML
index.
For XML indexes performance considerations, see 11.3, “Managing access path selection
with XML” on page 253.
If you add an XML column, the privilege set requires the CREATETAB and CREATETS
privileges on the database that contains the table (DSNDB04 if the database is implicitly
created), and USE privilege on the buffer pool and the storage group that is used by the XML
objects.
The implicitly created objects are owned by the owner of the base table.
10.3 Housekeeping
For XML objects maintenance, you can use IBM DB2 for z/OS utilities. The utilities handle
XML objects similar to the way that they handle LOB objects, as follows:
CHECK DATA
In addition to normal checking, the CHECK DATA utility also checks XML relationships, the
integrity of XML documents, and system-generated indexes that are associated with XML
data.
LOAD/UNLOAD
The input/output data can be in the textual XML format or the binary XML format.
If you load data into an XML column that has an XML type modifier, the LOAD utility
validates the input data according to the XML schema that is specified in the XML type
modifier.
By using spanned records, you are able to unload and load XML documents with a file size
in excess of 32 KB with good performance. The crossloader capability of the LOAD utility
does not support the XML data type.
REORG TABLESPACE
Use the REORG TABLESPACE utility to reorganize XML objects.
When you run REORG on an XML table space that supports XML versions, REORG
discards rows for versions of an XML document that are no longer needed.
RUNSTATS
Use the RUNSTATS utility to gather statistics for XML objects.
In the physical implementation, an XML document may take up more than one row in the
XML table space. Therefore, for the real-time statistics of XML table spaces in
[Link], the number of rows is reported, not the number of
XML documents.
For more information about utility support, see Chapter 9, “Utilities with XML” on page 183.
Use the REPORT utility with the TABLESPACESET option to identify related objects, which
may include objects related by referential integrity (RI) or auxiliary relationships to one or
more XML and LOB table spaces. An example can be found at 9.14, “REPORT” on page 218.
You may also use LISTDEF with XML/LOB and RI option to include related objects as a list.
See 9.6, “LISTDEF” on page 195 for more detail.
10.5 Diagnostics
When dealing with errors in XML table spaces and related objects, most of the problems are
the same as with any other table spaces and the usual techniques can be applied to diagnose
and solve the problems.
The output of a display command is shown in Example 10-4. It shows that all spaces are in
read and write (RW) status except the XML table space, which is in the restricted state CHKP
(check pending). The XML table space is easily identifiable with the type of XS.
Example 10-4 Display database command shows XML table space in AUXW
DSNT360I -DB0B ***********************************
DSNT361I -DB0B * DISPLAY DATABASE SUMMARY
* GLOBAL
DSNT360I -DB0B ***********************************
DSNT362I -DB0B DATABASE = DSN00155 STATUS = RW
DBD LENGTH = 4028
DSNT397I -DB0B
NAME TYPE PART STATUS PHYERRLO PHYERRHI CATALOG PIECE
-------- ---- ----- ----------------- -------- -------- -------- -----
BKRTORCS TS 0001 RW
BKRTORCS TS RW
XBKR0000 XS 0001 CHKP
XBKR0000 XS CHKP
IRDOCIDB IX L0001 RW
IRDOCIDB IX L* RW
IRNODEID IX L0001 RW
IRNODEID IX L* RW
IXMLNTRY IX L0001 RW
IXMLNTRY IX L* RW
******* DISPLAY OF DATABASE DSN00155 ENDED **********************
DSN9022I -DB0B DSNTDDIS 'DISPLAY DATABASE' NORMAL COMPLETION
Only three restricted states are related specifically to XML, and they might appear in other
contexts too with another meaning. These states are listed in Table 10-4.
AUXW on base table Invalidated XML column as a result of Can also be related to a
running: LOB column of the table.
CHECK DATA AUXERROR INVALIDATE
ACHKP on base table Invalid XML column detected when Can also be related to a
running: LOB column of the table.
CHECK DATA AUXERROR REPORT
Run the CHECK DATA utility with the INCLUDE XML TABLESPACES keyword to determine
the exact cause of any of these states, and what further action to take. For a comprehensive
description of the XML-related capabilities of the CHECK DATA utility, see 9.1, “CHECK
DATA” on page 184.
Run the REPAIR utility with the LOCATE KEY and LOCATE RID keywords to determine
whether certain rows and index entries exist:
LOCATE KEY can be used to locate a row in a base table by specifying the DOCID key in
the DOCID index.
LOCATE RID can be used to locate a row in the XML table space using the RID of the row.
Example 10-5 shows how to use the utility to locate a row in base table space BKRTORCS
with DocID =2, and a row in the XML table space with RID X'00000201'.
Example 10-5 REPAIR LOCATE control statements for diagnosing XML inconsistencies
REPAIR LOCATE TABLESPACE [Link]
KEY(2) INDEX XMLR2.I_DOCIDBK_TO_CSTMR_STMT DUMP
REPAIR LOCATE TABLESPACE DSN00155.XBKR0000
RID X'00000201' DUMP
Note: Apply the currently open APAR PM26592 to allow for use of BIGINT data type in
REPAIR LOCATE KEY.
If the errors were identified by the CHECK DATA utility, you can use the CHECK DATA utility to
correct the problems.
Run CHECK DATA with SHRLEVEL REFERENCE and XMLERROR INVALIDATE, which
causes the utility to perform the following tasks:
– Delete invalid XML documents and move them to exception tables
– Invalidate XML entries in the base table
Run CHECK DATA with SHRLEVEL CHANGE and XMLERROR INVALIDATE, which
causes the utility to generate control statements for you to execute:
– REPAIR LOCATE DOCID DELETE statements for deleting orphan rows
– REPAIR LOCATE RID REPLACE statements for invalidating entries in the base table
– REBUILD INDEX for the NODEID index if the index is in error.
For details about the CHECK DATA utility and the options for correcting the data, see 9.1,
“CHECK DATA” on page 184.
Apply PTF UK62510 for APAR PM24947 for the CHECK DATA SHRLEVEL CHANGE utility
to generate REPAIR statements.
APAR PM21834 (currently open) provides various usability fixes for DB2 utilities including
CHECK DATA.
If the errors were identified by the CHECK INDEX utility, possibly in conjunction with REPAIR
LOCATE, the appropriate course of action is listed in Table 10-5.
Error in DocID index 1. Ensure that the table space is at the correct level.
2. Rebuild the index.
Mismatch between NODEID index or Use REPAIR LOCATE RID DELETE to remove orphan
user-defined XML index and XML table row.
space, and index is correct.
Finally, you might need to reset the restrictive status by running CHECK DATA SHRLEVEL
REFERENCE, or by using the REPAIR utility as shown in Example 10-6.
Example 10-6 Using REPAIR utility to clear ACHKP status on table space
REPAIR OBJECT
SET TABLESPACE [Link] NOAUXCHKP
XML Other
DOCID
MSGID XML
Index
Unique Index Indexes
BK_TO_CSTMT_STMT
<?xml...><Document xmlns:xsi=...><BkToCstmrStmt><GrpHdr>…....</Document>
<?xml...><Document xmlns:xsi=...><BkToCstmrStmt><GrpHdr>…....</Document>
<?xml...><Document xmlns:xsi=...><BkToCstmrStmt><GrpHdr>…....</Document>
XML Other
DOCID
MSGID XML
Index
Unique Index Indexes
BK_TO_CSTMT_ACCT_RPT
<?xml...><Document xmlns:xsi=...><BkToCstmrAcctRpt><GrpHdr>…....</Document>
<?xml...><Document xmlns:xsi=...><BkToCstmrAcctRpt><GrpHdr>…....</Document>
<?xml...><Document xmlns:xsi=...><BkToCstmrAcctRpt><GrpHdr>…....</Document>
An XML-only design has the following potential drawbacks for traditional DB2 users:
You cannot define referential integrity constraints between tables if it involves XML
columns, or XML expressions against the contents of those XML columns.
Development and DBA teams might be forced to “think” in terms of XML and XPath
expressions for every database interaction that they perform. This approach is a large
conceptual shift from traditional relational and XML thinking.
Reln
DOCID Other Other
MSGID
Index Relational XML
Unique Index
Indexes Indexes
Reln
DOCID Other Other
MSGID
Index Relational XML
Unique Index
Indexes Indexes
The programming examples in this book (SQL procedures, COBOL and Java) all show how
using the SQL/XML language can be easy to strip out data elements of interest, and store
them as relational columns.
Although this approach is not necessary to achieve a high performance database, it can be
desirable for many other reasons:
Referential Integrity can be defined on the indexed relational columns.
The database is easier to work with, because it can be represented easily in the familiar
representation of entity-relationship diagrams, which is the conceptual model upon which
traditional relational systems have been designed for years.
If you have multiple XML columns to store XML documents of separate XML schemas, you
can create many more database objects (table spaces, data sets, DOCID indexes, NODEID
indexes, and so on). The logical data model is easier to understand if separate XML
document types are stored in their columns. However, the physical data model can have a
larger number of objects to track.
XML Indexes and performance might suffer if you combine multiple XML document types into
a single DB2 column. If you create an XML index on an XML column with multiple XML
schemas, the costs of index creation can increase, even if many of the documents do not
contain matching nodes. Additionally, if you are not careful about XPath expressions and
namespaces, you might receive unexpected results if you get an index hit against an XML
document type that you were not targeting in your application.
As a general rule, a good approach usually is to store XML documents in DB2 columns that
are dedicated to documents of that particular XML schema.
Many data structures for in-house systems might be best implemented by using XML.
Consider the example of insurance quotations. The range of data that is collected for a car
insurance proposal can vary dramatically depending on the vehicle, the applicants, the usage
of the vehicle, the claims history, and so on. Do we really want to design a relational database
with 50 or so tables to store millions of Internet quotes, when they are sparsely populated and
only 1% of them will be taken forward into a purchased policy? Surely this is an example of an
in-house data structure that should implemented in XML. Price comparison sites must surely
use XML documents and web services to communicate between separate insurers. With
pureXML, these documents can be stored for efficient retrieval, and indexed and queried in
their native format for patterns in client behavior.
The following data characteristics tend to make XML a good choice for data storage:
Hierarchical data
The XML data model is naturally hierarchical, which means that it tends to be a good fit for
data that is naturally hierarchical.
Semi-structured data
XML schemas can be rigid or loose as appropriate. They can have rigid constraints for
certain XML nodes, and looser constraints for other XML nodes as appropriate, to
accommodate the appropriate level of structure that is required.
Document/narrative data
XML is always accused of being verbose.
Many types of schemas
The ISO 20022 standard is an example. It contains hundreds of schemas. The
development cost of building relational database schemas for all these message
structures would be astronomical. With pureXML, the number of tables and columns can
be very small, because the data structures are managed in the XML schemas, with little
DBA impact.
Large schemas (with sparsely populated attributes and elements)
The ISO 20022 schemas are very large to provide a generic schema that can cater to a
very wide range of payments scenarios. The average personal banking customer uses
only a subset of the facilities in that schema. No additional processing or storage costs are
incurred for leaving the majority of the XML nodes empty of data. XML indexes contain
only entries for those XML patterns where an indexed element or attribute is found, thus
minimizing the space required for XML indexes.
Quickly evolving schema
If a relational database schema changes, months can be spent for the development,
testing, and QA processes to introduce a new release of the application. A major part of
that release time is spent by database change management. This part would be
substantially reduced if all you had to do was add a new schema document to the existing
XSR schema, to define a new release of the XML schema. Furthermore, database
schema changes do not necessarily require data migration; the application can decide
whether an XML document which is compliant with the old schema release must be
modified to accommodate the new schema release.
If the data for your application fits some or all of these characteristics, then pureXML can be
the best physical storage option. If you choose pureXML storage, consider carefully the
optimal hybrid storage design, which can help make development tasks easy, and allows the
strengths of the XML model to be fully utilized.
Be sure to also monitor zIIP and zAAP use, because XML processing is 100% eligible. For
more information about zIIP and zAAP monitoring, go to the following address:
[Link]
The principles of designing access paths are no different from relational access path
selection, as follows:
XML indexes are B-tree structures, like relational indexes.
The DB2 Optimizer considers using both XML and relational indexes, based on their
attractiveness.
The attractiveness of XML indexes is based on largely the same measures as relational
indexes (cardinality, filter factors, and others that you find in the DB2 catalog).
The best way of approaching the subject of XML indexes for access path selection is to be
aware of the differences between XML index usage and relational index usage, and add this
knowledge to traditional quality assurance processes that you already use for access path
selection.
Reln
DOCID Other Other
MSGID
Index Relational XML
Unique Index
Indexes Indexes
BK_TO_CSTMR_STMT
XML indexes are created on an XML pattern (examples are listed in “XML Index patterns” on
page 255). The result of that XML pattern yields a result, which can be variable in nature,
depending on the content of the XML document and the constraints of an XML schema.
The differences between relational and XML indexes are listed in Table 11-1.
May be defined on one or more relational Can be defined only on one XML element or
columns. attribute (using an XML pattern expression).
Always have one index entry for every row in a Are based on an XML pattern. An XML pattern
table. XML indexes are much less prescriptive. may occur any number of times in an XML
document. Therefore, XML indexes may contain
0, 1, or many entries for each row in the table.
Are always based on the data types of the Are defined based on a mapping to a particular
column(s) that they are defined on. The data data type, but whether or not the data type that is
types found at the locations of an XML pattern found at that location can be cast to that data type
may be many and varied unless an appropriate for an index match to be achieved depends on the
XML schema is enforced. degree to which the XML schema constrains the
data contents.
Can be used to support table clustering. May not be used for table clustering support.
Now that you understand the nature of XML indexes and how they differ from relational
indexes, you can use that information when considering how to design XML indexes.
At the most restrictive end of the spectrum are lean indexes. The index in Example 11-1 is
targeted at a data element in a specific XPath location, which is cast to a specific relational
data type. In this example, an index is built and is based on mapping the data elements at
XPath /Document/BkToCstmrStmt/GrpHdr/MsgId and casting whatever is found there to
Varchar(35).
Note: XMLPATTERNS must define the appropriate namespace if the Documents contain a
namespace declarations.
At the least restrictive end of the spectrum are heavy indexes. The index in Example 11-2 is
targeted at any occurrence of a data element, MsgId, within the entire document.
Choosing lean or heavy XML indexes is a physical design trade-off. You want to maximize the
filter factor of every index, but you might be prepared to compromise the filter factor if you can
get away with a smaller number of indexes.
When you create your first XML index, you will want to get confirmation about whether it is
doing the task that you want it to do. The obvious way to do this is to explain a query that
should benefit from the index, and see if the index is selected by the optimizer.
Consider the “silly” XML index in Example 11-3 on page 256. This index was created with an
XMLPATTERN that did not actually match any nodes in the XML document, because of a
typographical error in the xpath expression.
If you find that the index is not selected, and you are unable to determine why the optimizer is
not choosing the index, take a moment to check the contents of [Link]. The
table snapshot in Figure 11-4 shows a subset of the catalog statistics for the lean and the
heavy indexes that were created in Example 11-1 on page 255 and Example 11-2 on
page 255. It also shows the catalog statistics of another XML index, which is based on an
XML pattern with a typographic error. See Figure 11-4. Note the following information:
The table has five rows, each with an XML document.
The lean XML index has a cardinality of 5, because it is based on an XPath expression
that identifies the MsgId data element, which happens to be unique.
The heavy XML index has a cardinality of 24, because the MsgId data element is repeated
multiple times in a typical Bk_To_Cstmr_Stmt message.
The “silly” index has a cardinality of 0!
---------+---------+---------+---------+---------+---------+---------+---------
select
substr(creator,1,5) concat '.' concat substr(name,1,23) as IndexName,
int(firstkeycardf) as firstkeycardf,
int(fullkeycardf) as fullkeycardref
from [Link]
where creator = 'XMLR3' and
tbname = 'BK_TO_CSTMR_STMT'
-- yields
---------+---------+---------+---------+---------+---------+---------+---------
INDEXNAME FIRSTKEYCARDF FULLKEYCARDREF
---------+---------+---------+---------+---------+---------+---------+---------
XMLR3.HEAVY_XMLIX 6 24
XMLR3.I_DOCIDBK_TO_CSTMR_STMT 5 5
XMLR3.LEAN_XMLIX 5 5
XMLR3.RELN_IX1 5 5
XMLR3.SILLY_XMLIX 0 0
DSNE610I NUMBER OF ROWS DISPLAYED IS 5
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+---------+---------
Figure 11-4 Catalog query to [Link]
The fact that FIRSTKEYCARDF and FULLKEYCARDF are zero is the warning alarm that
tells you that the index did not point to any matches in any of the XML documents in the table.
When this situation happens, you can deduce that you have an error in your XML pattern in
the index definition. Check the XML pattern, correct it, re-create the index, run RUNSTATS
and review the cardinality statistics until you get a sensible number.
Learning curve: There is a learning curve for the SQL programmer to become
comfortable with writing XML expressions such as XMLTABLE, XMLQUERY, and
XMLEXISTS. If you code an invalid SQL/XML statement, you receive an SQL error (such
as SQLCODE -104), which usually contains helpful guidance about what is wrong with your
statement. Further frustration is when you code an SQL/XML statement that is valid, but it
returns no rows. The two most common causes of getting no rows are XPath expressions
containing a typographic error, and incorrect namespace declarations. These two reasons
are also the first causes to consider when an XML index matches nothing in the table.
XML indexes are also more expensive for selection than relational indexes because two
indexes must be used:
The NODEID index on the XML table space must be used to find matches for the XML
pattern that is being searched on.
The DOCID index must be used next, to retrieve RIDs to perform table access.
Therefore, use care when choosing XML indexes, because they can increase the path length
of insert operations more than relational indexes. Do not interpret this statement to mean that
all searchable data fields must be stripped from XML documents and placed in indexed DB2
columns. The fact that an XML index adds some extra path length must be balanced against
the flexibility of being able to index directly into any part of a large XML document without
having to maintain a copy of that data element in a separate relational column.
XMLEXISTS functions are eligible for index access, if the XMLEXISTS predicate is supported
by the XML pattern of the XML index. Example 11-4 on page 258 shows an SQL/XML query
with an XMLEXISTS predicate that can be supported by either the lean or the heavy XML
indexes. In this case, the lean XML index is chosen, as proven by the results of an explain
request.
select
planno, creator, tname, accesstype,
matchcols, accesscreator, accessname, table_type
from XMLR3.PLAN_TABLE where queryno = 99;
PLANNO = 1
CREATOR = XMLR3
TNAME = BK_TO_CSTMR_STMT
ACCESSTYPE = DX
MATCHCOLS = 1
ACCESSCREATOR = XMLR3
ACCESSNAME = LEAN_XMLIX
TABLE_TYPE = T
XMLTABLE without a filtering predicate is not generally eligible for XML index access. The
reason is because the result of an XMLTABLE operation is simply a table without any filtering
of DOCIDs, unless a predicate is included with the XMLTABLE function. Example 11-5 shows
the use of the XMLTABLE function in conjunction with an XMLEXISTS predicate. The access
path is to use the lean XML index to retrieve the DOCIDs, and then to use the table function X
(which is the name that is assigned to the result of the XMLTABLE function) to retrieve the
data values.
select
planno, creator, tname, accesstype, matchcols,
accesscreator, accessname, table_type
from XMLR3.PLAN_TABLE where queryno = 88;
PLANNO = 1
CREATOR = XMLR3
TNAME = BK_TO_CSTMR_STMT
PLANNO = 2
CREATOR = XMLR3
TNAME = X
ACCESSTYPE = R
MATCHCOLS = 0
ACCESSCREATOR =
ACCESSNAME =
TABLE_TYPE = F
Another way of getting XMLTABLE to use an XML index does not require the use of
XMLEXISTS. You may specify a predicate on an XMLTABLE function, as Example 11-6
shows, and get XML index access.
select
planno, creator, tname, accesstype, matchcols,
accesscreator, accessname, table_type
from XMLR3.PLAN_TABLE where queryno = 55;
PLANNO = 1
CREATOR = XMLR3
TNAME = BK_TO_CSTMR_STMT
ACCESSTYPE = DX
MATCHCOLS = 1
ACCESSCREATOR = XMLR3
ACCESSNAME = LEAN_XMLIX
TABLE_TYPE = T
PLANNO = 2
CREATOR = XMLR3
TNAME = X
ACCESSTYPE = R
MATCHCOLS = 0
ACCESSCREATOR =
ACCESSNAME =
TABLE_TYPE = F
select
planno, creator, tname, accesstype, matchcols,
accesscreator, accessname, table_type
from XMLR3.PLAN_TABLE where queryno = 77;
PLANNO = 1
CREATOR = XMLR3
TNAME = BK_TO_CSTMR_STMT
ACCESSTYPE = DX
MATCHCOLS = 1
ACCESSCREATOR = XMLR3
ACCESSNAME = LEAN_XMLIX
TABLE_TYPE = T
Native SQL procedures in DB2 can be an excellent environment for developing high
performance applications, with or without XML. They are covered in DB2 9 for z/OS Stored
Procedures: Through the CALL and Beyond, SG24-7604, which explains several of their
strengths as follows:
Multiple procedural steps can be executed within DB2, eliminating network delays that an
external program would experience making each SQL call and waiting for the results.
Stored procedures run entirely within the DB2 engine.
Procedural statements are converted to a native representation that is stored in the DB2
catalog and directory, as it is done with other SQL statements.
They are zIIP-eligible if they are called through DRDA with TCP/IP, type 4 Java.
In addition to the performance benefits of native stored procedures for XML processing,
considerable development productivity benefits can be gained from creating frequently used
procedures that encapsulate XML processing, and can be called by a developer by using
standard SQL.
Native stored procedures provide a high performance platform for the programming of SQL
and SQL/XML routines, which can be called from any application environment. Any
application development project that uses DB2 z/OS must evaluate which programming
functions should be implemented as native stored procedures, so that they can used and
shared by all applications and application environments that use DB2.
XML versioning is the mechanism that allows concurrent read access to an XML document
while another user is updating it. It works by maintaining multiple copies of the XML document
in the XML auxiliary table. It depends on the columns in the XML auxiliary table that are
created in DB2 10 NFM. Although querying the XML table space directly is disabled,
Example 11-8 The [Link] contents for auxiliary XML table space
select name, colno, coltype, length
from [Link]
where tbcreator = user
and tbname = 'XBK_TO_CSTMR_STMT'
order by colno ;
... yields
The DB2 10 multiversioning table space format depends on the use of a cleanup service
request block (SRB) to remove old versions of XML documents that are created by UPDATE
and DELETE. It is a small overhead, but can result in some CPU activity on the 16 KB buffer
pool for the data and the other buffer pool for the indexes even when XML applications are
idle.
This column is an internal object, and IBM does not guarantee to keep it unchanged in the
future. Do not develop applications that depend on this column.
Data compression
The storage of XML documents automatically receives a certain amount of compression. The
XML tags are stored in [Link] and replaced with binary values. However,
the contents of the data values in XML documents are not compressed by default.
The textual nature of many XML documents means that they are particularly well-suited to
compression techniques, which can lead to performance gains from reduced I/O and efficient
use of buffer pool. Therefore, consider compressing DB2 tables with XML, and DB2 XML
indexes.
The DSN1COMP utility can be used to assess the compression benefit, as usual.
The XML table space follows the same partitioning scheme as the base table space, but has
the potential to grow much faster. Make sure that you reorganize (with REORG) the XML
table spaces frequently enough to maintain performance.
The method of reorganizing an XML table space requires that you build a REORG job for the
base table space, and then you add an additional REORG control statement for each of the
XML table spaces. The table spaces for the BK_TO_CSTMR_STMT example table are
reorganized by using the JCL in Example 11-9. You must also specify the WORKDDN
keyword on the REORG for the XML table space and provide the specified temporary work
file. The default is SYSUT1.
16 KB buffer pool
XML table spaces are always defined in a 16 KB buffer pool. You must monitor the size of the
16 KB buffer pool, and ensure that it is appropriately sized and backed up by real storage.
As described in 10.1.3, “Sizing XMLVALA and XMLVALS” on page 235, the XMLVALA
subsystem parameter specifies, in KB, an upper limit for the amount of storage that each user
is to have for storing XML values:
Acceptable values: 1 to 2,097,152 KB
Default: 204,800 KB
The XMLVALS subsystem parameter specifies, in MB, an upper limit for the amount of
storage that each system can use for storing XML values:
Acceptable values: 1 to 51200 MB
Default: 10240 MB
Remember that these values might need to be adjusted if your application materializes a
large volume of XML data.
Example 11-10 Multiple XMLQUERY calls replaced with a single XMLTABLE call
SET V_CREDTTM = (
select xmlcast(xmlquery('declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
$d/Document/BkToCstmrStmt/GrpHdr/CreDtTm'
passing VALIDXML as "d") as timestamp) from sysibm.sysdummy1 );
SET V_MINISTMT = (
select xmlquery('declare default element namespace
"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02";
$d/Document/BkToCstmrStmt/Stmt'
passing VALIDXML as "d") from SYSIBM.SYSDUMMY1 ) ;
Another way of making the code more elegant and more efficient is to combine the two
XMLQUERY calls into a single select statement, as shown in Example 11-11.
Although using predicates to filter rows is a good practice in any situation, because
XMLQUERY and XMLTABLE can be more CPU-heavy than other built-in functions, good
filtering is critical.
For example, XPath with forward slash (/) generally performs better than with double forward
slash (//), both for queries and XML index specifications.
Always review the latest APARs to make sure that you download PTFs that improve
performance of XML processing. The best place to start is II14426, which is the information
APAR to link together all the XML support delivery APARs:
[Link]
Select the Additional materials and open the directory that corresponds with the IBM
Redbooks publication number SG24-7915-00.
[Link]
The compressed file contains code and data to reproduce the application infrastructure.
Prerequisites
The prerequisites are as follows:
DB2 Client for Windows V9.7 Fix Pack 3a
IBM Data Server Driver for JDBC and SQLJ version 4.9 or later (DB2 Client, V9.7 Fix
Pack 3a and later provides this support.)
Environment setup on server for XML schema registration
The table BK_TO_CSTMR_STMT with XML column, and other related tables shown in
Example 6-1 on page 90.
Sample code
The sample code files are as follows:
Stored procedure in Example 6-3 on page 92:
STOREXML1.db2
Java program to drive STOREXML1():
[Link]
Script to run Teststorexml1 java program:
[Link]
Stored procedure in Example 6-4 on page 94:
STOREXML2.db2
Java program to drive STOREXML2():
[Link]
Script to run Teststorexml2 Java program:
[Link]
Stored procedure to prime an MQ queue with an XML message:
LOADMQ.db2
Sample data
The sample data files are as follows:
DDL for all samples:
[Link]
Test data for all samples:
XML_TEST_SOURCE.SQL
Script to reset test data for all samples:
RESET_TEST_SOURCE.SQL
[Link]
The compressed file contains code and data to reproduce our Java scenario.
Prerequisites
The prerequisites are as follows:
SDK for Java Version 6 or later
IBM Data Server Driver for JDBC and SQLJ version 4.9 or later (DB2 Client, V9.7 Fix
Pack 3a and later provides this support.)
Environment setup on server for XML schema registration
The table BK_TO_CSTMR_STMT with XML column must be created (see Example 7-5 on
page 141).
Sample data
The sample data files are as follows:
Schema of bank to customer statement message:
[Link]
XML file of bank to customer statement message:
[Link]
[Link]
[Link]
XSLT file to transform XML message:
[Link]
[Link]
XML document sent to WebSphere MQ:
[Link]
[Link]
The compressed file contains code and data to reproduce our COBOL scenario.
Prerequisites
The prerequisites are as follows:
Enterprise COBOL for z/OS Version 4.1 or later
DB2 Connect Version 9.5 or later
Configuration of DB2 for z/OS node in DB2 Connect
Setup of DB2 XML schema repository
Sample code
The sample code files are as follows:
COBOL program for inserting a BankToCustomerStatement into table
BK_TO_CUSTMR_STSMT using a file reference variable:
[Link]
COBOL program for selecting a BankToCustomerStatement from table
BK_TO_CUSTMR_STSMT into a file using a file reference variable:
[Link]
COBOL program for selecting entries from a BankToCustomerStatement from table
BK_TO_CUSTMR_STSMT using XMLTABLE:
[Link]
COBOL program for altering the message recipient of a BankToCustomerStatement in
table BK_TO_CUSTMR_STSMT using XMLMODIFY. The message recipient element is
received as a file reference variable.
[Link]
COBOL program for altering the message recipient of a BankToCustomerStatement in
table BK_TO_CUSTMR_STSMT using XMLMODIFY. The message recipient element is
generated using COBOL XML GENERATE statement.
[Link]
JCL for precompiling, compiling, link-editing and binding COBOL program INSBKST. It can
be modified to prepare other COBOL programs by replacing INSBKST with other COBOL
program name.
[Link]
JCL for running COBOL program INSBKST. It can be modified to run other COBOL
programs by replacing the program name, but take care to enter the correct input
variables.
[Link]
Sample data
The sample data files are as follows:
Schema for BankToCustomerStatement message:
[Link]
XML file with BankToCustomerStatement message:
[Link]
XML file with MsgRcpt element:
[Link]
address space. A range of virtual storage pages Application Service Provider (ASP). An ASP is an
identified by a number (ASID) and a collection of segment agent or broker that aggregates, facilitates and brokers IT
and page tables which map the virtual pages to real pages services to deliver IT-enabled business solutions across a
of the computer's memory. network through subscription-based pricing.
address space connection. The result of connecting an application-owning region (AOR). A CICS® region in an
allied address space to DB2. Each address space MRO environment that “owns” the CICS applications, and
containing a task that is connected to DB2 has exactly one invokes them on behalf of remotely attached terminal (or
address space connection, although more than one task web) users.
control block (TCB) can be present. See allied address
space and task control block. AR. application requester. See requester.
Advanced Program-to-Program Communication ASCII. (1) American Standard Code for Information
(APPC). (1) The general facility characterizing the LU6.2 Interchange. A standard assignment of 7-bit numeric
architecture and its implementation in separate SNA codes to characters. See also Unicode. (2) An encoding
products. (2) Sometimes used to refer to an LU6.2 product scheme used to represent strings in many environments,
feature, in particular, such as an APPC application typically on PCs and workstations. Contrast with EBCDIC.
programming interface.
attribute. In XML, a name="value" pair that can be placed
allied address space. An area of storage external to DB2 in the start tag of an element. The value must be quoted
that is connected to DB2 and is therefore capable of with single or double quotation marks.
requesting DB2 services.
authorization ID. A string that can be verified for
American National Standards Institute (ANSI). An connection to DB2 and to which a set of privileges are
organization consisting of producers, consumers, and allowed. It can represent an individual, an organizational
general interest groups, that establishes the procedures group, or a function, but DB2 does not determine this
by which accredited organizations create and maintain representation.
voluntary industry standards in the United States.
authorized program analysis report (APAR). A report of
ANSI. See American National Standards Institute. a problem caused by a suspected defect in a current,
unaltered release of a program.
APAR. See authorized program analysis report.
automatic bind. (More correctly automatic rebind). A
API. See application program interface. process by which SQL statements are bound
automatically (without a user issuing a BIND command)
applet. See Java Applet. when an application process begins execution and the
bound application plan or package it requires is not valid.
application. (1) A program or set of programs that
performs a task, for example, a payroll application. (2) In auxiliary table. A table containing LOB or XML columns
Java programming, a self-contained, stand-alone Java and referenced from the base table.
program that includes a static main method. It does not
require an applet viewer. Contrast with applet. B
application plan. The control structure that is produced base table. (1) A table created by the SQL CREATE
during the bind process and used by DB2 to process SQL TABLE statement that is used to hold persistent data.
statements encountered during statement execution. Contrast with result table and temporary table. (2) A table
containing a LOB or XML column definition. The actual
application program interface (API). A functional LOB or XML column data is not stored along with the base
interface supplied by the operating system or by a table. The base table contains a row identifier for each row
separately orderable licensed program that allows an and an indicator column for each of its LOB or SML
application program written in a high-level language to use columns. Contrast with auxiliary table.
specific data or functions of the operating system or
licensed program.
bind. The process by which the output from the DB2 channel-attached. (1) Pertaining to attachment of
precompiler is converted to a usable control structure devices directly by data channels (I/O channels) to a
called a package or an application plan. During the computer. (2) Pertaining to devices attached to a
process, access paths to the data are selected and some controlling unit by cables rather than by
authorization checking is performed. telecommunication lines.
browser. (1) In VisualAge® for Java, a window that character large object (CLOB). A sequence of bytes
provides information about program elements. There are representing single-byte characters or a mixture of single
browsers for projects, packages, classes, methods, and and double-byte characters where the size can be up to 2
interfaces. (2) An Internet-based tool that lets users GB - 1. Although the size of character large object values
browse websites. can be anywhere up to 2 GB - 1, in general, they are used
whenever a character string might exceed the limits of the
built-in function. A function incorporated in the supplied VARCHAR type.
DB2 code which can be used in SQL statements.
class. An encapsulated collection of data and methods to
bytecode. Machine-independent code generated by the operate on the data. A class may be instantiated to
Java compiler and executed by the Java interpreter. produce an object that is an instance of the class.
C class hierarchy. The relationships between classes that
share a single inheritance. All Java classes inherit from
call level interface (CLI). A callable API for database the Object class.
access, which is an alternative to using embedded SQL.
In contrast to embedded SQL, DB2 CLI does not require class method. Methods that apply to the class as a whole
the user to precompile or bind applications, but rather rather than its instances (also called a static method).
provides a standard set of functions to process SQL
statements and related services at run time. class variable. Variables that apply to the class as a
whole rather than its instances (also called a static field).
Cascading Style Sheet (CSS). CSS defines a stylesheet
language for HTML 4.0. A web page designer uses CSS CLASSPATH. In your deployment environment, the
to separately specify style elements of a web page, such environment variable keyword that specifies the
as colors, fonts and font styles. directories in which to look for class and resource files.
casting. Explicitly converting an object or primitive’s data CLOB. See character large object.
type.
codebase. An attribute of the <APPLET> tag that
catalog. In DB2, a collection of tables that contains provides the relative path name for the classes. Use this
descriptions of objects such as tables, views, and indexes. attribute when your class files reside in a different
directory than your HTML files.
catalog table. Any table in the DB2 catalog.
column function. An SQL operation that derives its result
from a collection of values across one or more rows.
Contrast with scalar function.
Common Connector Framework. In the Enterprise data source. A local or remote relational or non-relational
Access Builder, interface and class definitions that provide data manager that is capable of supporting data access
a consistent means of interacting with enterprise through an ODBC driver which supports the ODBC APIs.
resources (for example, CICS and Encina transactions) In the case of DB2 for OS/390®, the data sources are
from any Java execution environment. always relational database managers.
connection. In the VisualAge for Java Visual database management system (DBMS). A software
Composition Editor, a visual link between two components system that controls the creation, organization, and
that represents the relationship between the components. modification of a database and access to the data stored
Each connection has a source, a target, and other within it.
properties.
DB2 thread. The DB2 structure that describes an
connection handle. The data object containing application’s connection, traces its progress, processes
information that is associated with a connection that is resource functions, and delimits its accessibility to DB2
managed by DB2 CLI. This object includes general status resources and services.
information, transaction status, and diagnostic
information. DBCLOB. See double-byte character large object.
content model. In XML, the expression specifying what DBMS. See database management system.
elements and data are allowed within an element.
direct access storage device (DASD). A mass storage
cookie. (1) A small file stored on an individual's computer; medium on which a computer stores data.
this file allows a site to tag the browser with a unique
identification. When a person visits a site, the site’s server distributed relational database architecture (DRDA).
requests a unique ID from the person's browser. If this A connection protocol for distributed relational database
browser does not have an ID, the server delivers one. On processing that is used by IBM relational database
the Windows/Intel platform, the cookie is delivered to a products. DRDA includes protocols for communication
[Link] file; on a Macintosh platform, it is delivered to between an application and a remote relational database
MagicCookie. Just as someone can track the origin of a management system, and for communication between
phone call with Caller ID, companies can use cookies to relational database management systems.
track information about behavior. (2) Persistent data
stored by the client in the Servlet Builder. DLL. See dynamic link library.
cursor. A named control structure used by an application Document Object Model (DOM). DOM allows the
program to point to a row of interest within some set of representation and manipulation of an XML document in
rows, and to retrieve rows from the set, possibly making memory as a programming object. DOM is defined by the
updates or deletions. World Wide Web Consortium.
customer relationship management (CRM). CRM document type definition (DTD). A DTD is a definition of
includes the systems and infrastructure required to which Elements and Attributes are acceptable in a specific
analyze, capture and share all parts of the customer’s XML file. The DTD therefore defines a subset of XML
relationship with the enterprise. From a strategy which may be used for a particular application.
perspective, it represents a process to measure and
allocate organizational resources to those activities that DOM. See Document Object Model.
have the greatest return and impact on profitable
DOM Tree. A DOM Tree is an in-memory representation
customer relationships.
of an XML Document.
D
double precision. A floating-point number that contains
data access bean. In the VisualAge for Java Visual 64 bits. See also single precision.
Composition Editor, a bean that accesses and
manipulates the content of JDBC/ODBC-compliant
relational databases.
Glossary 285
double-byte character large object (DBCLOB). A embedded SQL. SQL statements coded within an
sequence of bytes representing double-byte characters application program. See static SQL.
where the size can be up to 2 GB. Although the size of
double-byte character large object values can be embedded Java. An API and application environment for
anywhere up to 2 GB, in general, they are used when a high-volume embedded devices, such as mobile phones,
double-byte character string might exceed the limits of the pagers, process control, instrumentation, office
VARGRAPHIC type. peripherals, network routers and network switches. The
embedded Java applications run on real-time operating
DRDA. See distributed relational database architecture. systems and are optimized for the constraints of
small-memory footprints and diverse visual displays.
duplex. Pertaining to communication in which data or
control information can be sent and received at the same empty declaration. In XML, the DTD declaration for an
time. Contrast with half duplex. empty tag. For example, if <abcd/> is an empty tag, the
empty declaration looks like: <!ELEMENT abcd EMPTY>.
dynamic bind. A process by which SQL statements are
bound as they are entered. empty tag. In XML, a start and end tag combined in one
tag. The tag has a trailing slash, so an XML parser can
Dynamic I/O Reconfiguration. A S/390 function that immediately recognize it as an empty tag and not bother
allows I/O configuration changes to be made looking for a matching end tag. For example, if abcd is an
nondisruptively to the current operating I/O configuration. empty tag, it looks like <abcd/>.
dynamic link library (DLL). A file containing executable Enterprise Java. Includes Enterprise JavaBeans and
code and data bound to a program at load time or run also open API specifications for: database connectivity,
time, rather than during linking. The code and data in a naming and directory services, CORBA/IIOP
DLL can be shared simultaneously by several interoperability, pure Java distributed computing,
applications. The DLL’s Enterprise Access Builders also messaging services, managing system and network
generate platform-specific DLLs for the workstation and resources, and transaction services.
OS/390 platforms.
Enterprise JavaBeans (EJB). A cross-platform
dynamic SQL. SQL statements that are prepared and component architecture for the development and
executed within an application program while the program deployment of multitier, distributed, scalable,
is executing. In dynamic SQL, the SQL source is object-oriented Java applications. The Enterprise
contained in host language variables rather than being JavaBeans specification defines a way of building
coded into the application program. The SQL statement transactionally aware business objects in Java.
can change several times during the application
program's execution. Enterprise Systems Architecture/390 (ESA/390). An
IBM architecture for mainframe computers and
E peripherals. Processors that follow this architecture
include the S/390 Server family of processors.
EBCDIC. Extended Binary Coded Decimal Interchange
Code. An encoding scheme used to represent character entity. In XML, an entity declaration provides the ability to
data in the MVS™, VM, VSE, and OS/400® have constants or replacement strings, which are
environments. Contrast with ASCII. expanded by a pre-processor. An entity declaration maps
some token to a replacement string. Later the token can
EBNF. Extended Backus-Naur Form. A formal set of be prefixed with the ampersand (&) character and the
production rules that comprise a grammar defining replacement string is put in its place.
another language, such as XML.
environment handle. In DB2 ODBC, the data object that
electronic data interchange (EDI). The automatic contains global information regarding the state of the
machine-to-machine transfer of trading documents (for application. An environment handle must be allocated
example, invoices and purchase orders) using electronic before a connection handle can be allocated. Only one
networks such as the Internet. Originally conducted only environment handle can be allocated per application.
through value-added networks, EDI is gradually moving to
the Internet. ESA/390. See Enterprise Systems Architecture/390.
element. In XML, a start tag and its end tag, plus the
content between the tags. An empty tag is also an
element.
executable content. Code that runs from within an HTML File Transfer Protocol (FTP). In the Internet suite of
file (such as an applet). protocols, an application layer protocol that uses TCP and
Telnet services to transfer bulk-data files between
extends. A subclass or interface extends a class or machines or hosts.
interface if it adds fields or methods, or overrides its
methods. first tier. The client, the hardware and software with which
the user interacts.
external function. A function for which the body is written
in a programming language that takes scalar argument foreign key. A key that is specified in the definition of a
values and produces a scalar result for each invocation. referential constraint. Because of the foreign key, the table
Contrast with sourced function and built-in function. is a dependent table. The key must have the same number
of columns, with the same descriptions, as the primary
extranet. In some cases, intranets have connections to key of the parent table.
other independent intranets. An example is one company
connecting its intranet to the intranet of one of its form data. A generated class that represents the HTML
suppliers. Such a connection of intranets is called an form elements in a visual servlet.
extranet. Depending on the implementation, an extranet
might be fully or partially visible to the outside. FTP. See File Transfer Protocol.
Glossary 287
half duplex. In data communication, pertaining to Internet Protocol (IP). In the Internet suite of protocols, a
transmission in only one direction at a time. Contrast with connectionless protocol that routes data through a
duplex. network or interconnected networks. IP acts as an
intermediary between the higher protocol layers and the
handle. In DB2 CLI, a variable that refers to a data physical network. However, this protocol does not provide
structure and associated resources. See connection error recovery and flow control, and does not guarantee
handle, environment handle. the reliability of the physical network.
hard disk drive. (1) A storage media within a storage interpreter. A tool that translates and executes code
server used to maintain information that the storage line-by-line.
server requires. (2) A mass storage medium for
computers that is typically available as a fixed disk or a Intranet. A private network inside a company or
removable cartridge. organization that uses the same kinds of software that you
would find on the Internet, but that are only for internal
hierarchy. The order of inheritance in object-oriented use. As the Internet has become more popular, many of
languages. Each class in the hierarchy inherits attributes the tools used on the Internet are being used in private
and behavior from its superclass, except for the top-level networks; for example, many companies have web
Object class. servers that are available only to employees.
Java Native Interface (JNI). A native programming Just-In-Time compiler (JIT). A platform-specific software
interface that allows Java code running inside a Java compiler often contained within JVMs. JITs compile Java
Virtual Machine (VM) to interoperate with applications and bytecodes automatically into native machine instructions,
libraries written in other programming languages, such as thereby reducing the need for interpretation.
C and C++.
JVM. See Java Virtual Machine.
Java Platform. The Java Virtual Machine and the Java
Core classes make up the Java Platform. The Java L
Platform provides a uniform programming interface to a
100% Pure Java program regardless of the underlying LAN. See local area network.
operating system. (Definition copyright 1996-1999 Sun
large object (LOB). See LOB.
Microsystems, Inc. All Rights Reserved. Used by
permission.)
licensed internal code (LIC). Microcode that IBM does
not sell as part of a machine, but instead, licenses to the
Java Remote Method Invocation (RMI). Java Remote
customer. LIC is implemented in a part of storage that is
Method Invocation is method invocation between peers,
not addressable by user programs. Some IBM products
or between client and server, when applications at both
use it to implement functions as an alternate to hard-wire
ends of the invocation are written in Java. Included in
circuitry.
JDK 1.1.
linker. A computer program for creating load modules
Java Runtime Environment (JRE). A subset of the Java
from one or more object modules or load modules by
Development Kit for users and developers who want to
resolving cross references among the modules and, if
redistribute the JRE. The JRE consists of the Java Virtual
necessary, adjusting addresses. In Java, the linker
Machine, the Java Core Classes, and supporting files.
creates an executable from compiled classes.
(Definition copyright 1996-1999 Sun Microsystems, Inc.
All Rights Reserved. Used by permission.)
load module. A program unit that is suitable for loading
into main storage for execution. The output of a linkage
Java Server Page (JSP). Java Server Pages are web
editor.
pages that include dynamic tags which are executed on
the server. JSPs are the presentation layer for web-based
LOB (large object). A sequence of bytes representing bit
applications built in Java.
data, single-byte characters, double-byte characters, or a
mixture of single- and double-byte characters. A LOB can
Java Virtual Machine (JVM). A software implementation
be up to 2 GB -1 bytes in length. See also CLOB,
of a central processing unit (CPU) that runs compiled Java
DBCLOB.
code (applets and applications).
local area network (LAN). A computer network located in
Java Database Connectivity (JDBC). In the JDK, the
a user’s premises within a limited geographic area.
specification that defines an API that enables programs to
access databases that comply with this standard.
logical partition (LPAR). A set of functions that create a
programming environment that is defined by the ESA/390
JavaDoc. Sun's tool for generating HTML documentation
architecture. ESA/390 architecture uses this term when
on classes by extracting comments from the Java source
more than one LPAR is established on a processor. An
code files.
LPAR is conceptually similar to a virtual machine
JavaScript. A scripting language used within an HTML environment except that the LPAR is a function of the
page. Superficially similar to Java but JavaScript scripts processor. Also, LPAR does not depend on an operating
appear as text within the HTML page. Java applets, system to create the virtual machine environment.
however, are programs written in the Java language and
logical switch number (LSN). A two-digit number used
are called from within HTML pages or run as standalone
by the I/O configuration program (IOCP) to identify a
applications.
specific ESCON® Director.
JDBC. See Java Database Connectivity.
Glossary 289
logically partitioned (LPAR) mode. A central processor NUL terminator. In C, the value that indicates the end of
mode, available on the Configuration frame when using a string. For character strings, the NUL terminator is
the PR/SM™ facility, that an operator uses to allocate X'00'.
processor hardware resources among logical partitions.
Contrast with basic mode. NUL-terminated host variable. A varying-length host
variable in which the end of the data is indicated by the
LPAR. See logical partition. presence of a NUL terminator.
primary key. A unique, non-null key that is part of the requester. Also application requester (AR). The source of
definition of a table. A table cannot be defined as a parent a request to a remote RDBMS, the system that requests
unless it has a unique key or primary key. the data.
process. A program executing in its own address space, RMI. See Remote Method Invocation.
containing one or more threads.
rollback. The process of restoring data changed by SQL
program temporary fix (PTF). A temporary solution or statements to the state at its last commit point. All locks
bypass of a problem diagnosed by IBM in a current are freed. Contrast with commit.
unaltered release of a program.
RPC. See Remote Procedure Calls.
property. An initial setting or characteristic of a bean, for
example, a name, font, text, or positional characteristic. runtime system. The software environment where
compiled programs run. Each Java runtime system
PTF. See program temporary fix. includes an implementation of the Java Virtual Machine.
R S
RDBMS. See relational database management system. sandbox. A restricted environment, provided by the web
browser, in which Java applets run. The sandbox offers
reentrant. Executable code that can reside in storage as them services and prevents them from doing anything
one shared copy for all threads. Reentrant code is not unacceptable, such as doing file I/O or talking to strangers
self-modifying and provides separate storage areas for (servers other than the one from which the applet was
each thread. Reentrancy is a compiler and operating loaded). The analogy of applets to children led to calling
system concept, and reentrancy alone is not enough to the environment in which they run the sandbox.
guarantee logically consistent results when
multithreading.
Glossary 291
scalar function. An SQL operation that produces a single sourced function. A function that is implemented by
value from another value and is expressed as a function another built-in or user-defined function already known to
name followed by a list of arguments enclosed in the database manager. This function can be a scalar
parentheses. See also column function. function or a column (aggregating) function; it returns a
single value from a set of values (for example, MAX or
Secure Sockets Layer (SSL). SSL is a security protocol AVG). Contrast with external function.
that allows communications between a browser and a
server to be encrypted and secure. SSL prevents SQL. See Structured Query Language.
eavesdropping, tampering, or message forgery on your
Internet or intranet network. SSL. See Secure Sockets Layer.
security. Features in Java that prevent web-downloaded Standardized Generalized Markup Language. An
applets downloaded from deliberately or inadvertently ISO/ANSI/ECMA standard that specifies a way to
doing damage. One such feature is the digital signature, annotate text documents with information about types of
which ensures that an applet came unmodified from a sections of a document.
reputable source.
static bind. A process by which SQL statements are
serialization. Converting an object to a stream, and back bound after they have been precompiled. All static SQL
again. statements are prepared for execution at the same time.
Contrast with dynamic bind.
server. The computer that hosts the web page that
contains an applet. The .class files that make up the static SQL. SQL statements, embedded within a
applet, and the HTML files that reference the applet reside program, that are prepared during the program
on the server. When someone on the Internet connects to preparation process (before the program is executed).
a web page that contains an applet, the server delivers the After being prepared, the SQL statement does not change
.class files over the Internet to the client that made the (although values of host variables specified by the
request. The server is also known as the originating host. statement might change).
server bean. The bean that is distributed using RMI stored procedure. A user-written application program,
services and is deployed on a server. that can be invoked through the use of the SQL CALL
statement.
servlet. See Java servlet.
Structured Query Language (SQL). A standardized
SGML. See Standardized Generalized Markup language for defining and manipulating data in a relational
Language. database. A language used by database engines and
servers for data acquisition and definition.
shell. The user interface of UNIX system software. In
z/OS, an xpg4.2-compliant shell is used. Very often, Sysout. The regular output for a program on z/OS is
OMVS is used as an interface for z/OS shells. SYSOUT. It is the functional equivalent of stdout on UNIX.
In batch, there can be multiple SYSOUTs.
single precision. A floating-point number that contains
32 bits. See also double precision. System. A single instance of the z/OS or OS/390
operating system in a sysplex.
Small Computer System Interface (SCSI). (1) An ANSI
standard for a logical interface to computer peripherals System Management End User Interface (SMEUI). A
and for a computer peripheral interface. The interface Windows-based tool that makes it possible to perform
uses a SCSI logical protocol over an I/O interface that administrative tasks for WebSphere Application Server
configures attached targets and initiators in a multi-drop from a Windows workstation. The SMEUI tool is used to
bus topology. (2) A standard hardware interface that deploy a new application to WebSphere on z/OS.
enables a variety of peripheral devices to communicate
with one another. T
SmartGuide. In IBM software products, an active form of task control block (TCB). A control block used to
help that guides you through common tasks. communicate information about tasks within an address
space that are connected to DB2. An address space can
source type. An existing type that is used to internally support many task connections (as many as one per
represent a distinct type. task), but only one address space connection. A TCB
manages dispatchable tasks. Each UNIX thread is
assigned to a TCB. See address space connection.
Telnet. Telnet provides a virtual terminal facility for users UDT. See distinct type.
of one computer to act as though they were using a
terminal connected to another computer. The Telnet client Unicode. A 16-bit international character set defined by
program communicates with the Telnet daemon on the ISO 10646. See also ASCII.
target system to provide the connection and session.
Uniform Resource Identifier (URI). Uniquely defines a
temporary table. A table created by the SQL CREATE location on the web. Compared to URL, the term URI is a
GLOBAL TEMPORARY TABLE statement that is used to more general term that also incorporates other schemes
hold temporary data. Contrast with result table. for identifying resources.
textual XML format. A system of storing XML data in text, Uniform Resource Locator (URL). Uniquely defines a
as opposed to binary, that allows for direct human reading. location on the web. The unique address that tells a
browser how to find a specific web page or file. URLs are
thin client. Thin client usually refers to a system that runs familiar to anyone who browses the web (for example
on a resource-constrained machine or that runs a small [Link]
operating system. Thin clients do not require local system
administration, and they execute Java applications universal table space. A table space that is both
delivered over the network. segmented and partitioned.
third tier. The third tier, or back end, is the hardware and URI. See Uniform Resource Identifier.
software that provides database and transactional
services. These back-end services are accessed through URL. See Uniform Resource Locator.
connectors between the middle-tier web server and the
third-tier server. Though this conceptual model depicts the user-defined data type (UDT). See distinct type.
second and third tier as two separate machines, the NCF
model supports a logical three-tier implementation in user-defined function (UDF). A function defined to DB2
which the software on the middle and third tier is on the using the CREATE FUNCTION statement that can be
same box. referenced thereafter in SQL statements. A user-defined
function can be either an external function or a sourced
thread. A separate flow of control within a program. function. Contrast with built-in function.
Glossary 293
web. See World Wide Web. XML data type. A data type for XML values.
web application. A web application is a collection of XML element. A logical structure in an XML document
static pages, JSPs, and servlets that share a common that is delimited by a start and an end tag. Anything
URL prefix, and together make a complete application, between the start tag and the end tag is the content of the
accessed over the Internet. element.
web browser. The web uses a client/server processing XML index. An index on an XML column that provides
model. The web browser is the client component. efficient access to nodes within an XML document by
Examples of web browsers include Mozilla, Google, and providing index keys that are based on XML patterns.
Chrome. The web browser is responsible for formatting
and displaying information, interacting with the user, and XML lock. A column-level lock for XML data. The
invoking external functions, such as Telnet, or external operation of XML locks is similar to the operation of LOB
viewers for data types that it does not directly support. locks.
web server. Web servers are responsible for servicing XML node. The smallest unit of valid, complete structure
requests for information from web browsers. The in a document. For example, a node can represent an
information can be a file retrieved from the server’s local element, an attribute, or a text string.
disk or generated by a program called by the server to
perform a specific application function. web servers are XML node ID index. An implicitly created index, on an
sometimes referred to as HTTPD servers or daemons. A XML table that provides efficient access to XML
number of web servers are available for most platforms documents and navigation among multiple XML data rows
including most UNIX variants, OS/2 Warp, OS/390, and in the same document.
Windows NT®.
XML pattern. A slash-separated list of element names, an
well-formed. An XML document is well-formed if there is optional attribute name (at the end), or kind tests, that
one root element, and all its child elements are properly describe a path within an XML document in an XML
nested within each other. Start tags must have end tags, column. The pattern is a restrictive form of path
and each empty tag must be designated as such with a expressions, and it selects nodes that match the
trailing slash. Also, all attributes must be quoted, and all specifications. XML patterns are specified to create
entities must be declared. indexes on XML columns in a database.
white-space. In XML, white space consists of characters XML publishing function. A function that returns an XML
that are not visible, but used in formatting documents or value from SQL values. An XML publishing function is also
programs. These characters include the space, tab, known as an XML constructor
newline, and carriage-return characters.
XML schema. In XML, a mechanism for describing and
World Wide Web. A network of servers that contain constraining the content of XML files by indicating which
programs and files. Many of the files contain hypertext elements are allowed and in which combinations. XML
links to other documents available through the network. schemas are an alternative to DTDs and can be used to
extend functionality in the areas of data typing,
WWW. See World Wide Web. inheritance, and presentation.
XML attribute. A name-value pair within a tagged XML XML table. An auxiliary table that is implicitly created
element that modifies certain features of the element. when an XML column is added to a base table. This table
stores the XML data, and the column in the base table
XML column. A column of a table that stores XML values points to it.
and is defined using the data type XML. The XML values
that are stored in XML columns are internal
representations of well-formed XML documents.
Glossary 295
296 Extremely pureXML in DB2 10 for z/OS
Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this book.
IBM Redbooks
For information about ordering these publications, see “How to get Redbooks” on page 298.
Note that some of the documents referenced here might be available in softcopy only.
DB2 9 for z/OS Stored Procedures: Through the CALL and Beyond, SG24-7604
DB2 10 for z/OS Technical Overview, SG24-7892
XML on z/OS and OS/390: Introduction to a Service-Oriented Architecture, SG24-6826
XML Processing on z/OS, SG24-7810
Other publications
These publications are also relevant as further information sources:
DB2 10 for z/OS Application Programming and SQL Guide, SC19-2969
DB2 10 for z/OS Application Programming Guide and Reference for Java, SC19-2970
DB2 10 for z/OS Installation and Migration Guide, GC219-2974
DB2 10 for z/OS pureXML Guide, SC19-2981
DB2 10 for z/OS SQL Reference, SC19-2983
DB2 pureXML Cookbook, Matthias Nicola and PAV Kumar-Chatterjee, IBM Press,
ISBN-13: 978-0-13-815047-1
WebSphere MQ Application Programming Guide Version 6.0, SC34-6595
WebSphere MQ Using Java Version 6.0, SC34-6591
Online resources
These websites are also relevant as further information sources:
Tools and XML functionality for DB2 pureXML users
[Link]
Extensible Dynamic Binary XML, Client/Server Binary XML Format (XDBX) Version 1.0
[Link]
XSL Transformations (XSLT) Version 1.0
[Link]
pureXML Devotees
[Link]
Index 301
schema location hint 82 privilege 241
namespace prefix 8, 110 procedures 24, 37, 49–51, 89, 140, 161, 234, 249–250,
namespace scope 8 253, 277
Namespaces 7–8 PROCESSING SYSIN 189
namespaces 5, 7–9, 27, 35, 87, 105, 172, 250 programming interface 129
native data type 24 programming language 132–133
native SQL 51, 90, 260 Publishing xix, 24–25, 91, 127, 136
Node 14, 33, 59, 82, 105, 171 purchase order 3, 77
node 14, 30, 33, 56, 58–59, 82, 103, 105, 137, 170–171, PURCHASE_ORDERS Value 83
175, 192, 262, 280 pureQuery 45
node id index 63 pureXML xix–xx, 19–22, 48, 50, 89–90, 109, 139,
NODEID index 157–158, 163, 233–234, 240, 247, 249–250
corresponding entry 185 pureXML storage 123, 250, 252
index entry 185
XML table space 190
NORMAL Completion 69, 211, 243 Q
Ntry element 103 qualified name 86
NUMRECS 1 203 query 15, 27–28, 47–49, 65, 87, 95, 101, 139, 177, 181,
200, 211, 230, 238, 242, 250–251, 255
Querying XML documents 173
O Queue Manager MQBA 99
ODBC 40 QUIESCE 206
optimizer 28, 35–36, 253, 255–256
options 11, 123, 158, 161, 185–186, 191, 215, 244, 261
order by 61, 67, 105–106, 126, 262 R
OUTPUT Start 189, 191 RACF 216–217
overhead 262 RBA 62, 207–208, 212
REBUILD INDEX 190, 208, 244
received XML document
P new XML document 93
package 42 relational and XML objects 115
parameter 42, 84, 90–91, 141, 167, 173, 228–230, 235, RECOVER 190, 209
264, 280 Redbooks web site 50, 277, 298
parent/child relationships 6, 18 Contact us xxi
parser 5, 7, 141–142, 180 REGION 189, 191, 193–194
partition-by-growth 55 registered XML schema 36
partitioning 58, 63, 238, 263 XML documents 36
PATH xix, 12, 28, 59, 94, 167, 171, 253, 258 relational column 29, 51, 98, 118, 249
Pattern 14, 35, 72, 112, 175, 254 data elements 250
PCDATA 6–7 relational data xix, 3, 23–25, 47, 93, 118, 178, 180, 255
performance xix, 20, 23–24, 34–35, 59, 133, 139, 227, relational index 35, 72, 240, 253
235, 240, 247–248 reordered row format 62
persisting 248 REORG 60, 190, 215, 238, 241, 263
PHASE Statistic 199 REORG TABLESPACE 215, 241, 263
PIT LRSN 219 REORG UNLOAD ONLY 215
PK90032 43 REORG utility 60, 200
PK90040 43 REPORT 40, 139, 168, 184, 200, 218, 242
PM21834 245 REPORT RECOVERY 219
PM22081 239 TABLESPACE [Link] ORCS 219
PM24947 245 TABLESPACE [Link] 0000 220
PM26592 244 REPORT TABLESPACESET 218–219
PM28385 128 repository 22, 30, 36, 50, 80, 84, 98, 130, 140, 165, 177,
PM29986 203 234, 280
po requirements 47–49, 76, 124, 278
purchaseOrder xmlns result set 105, 200
po 82 ResultSet 133
point-in-time recovery 210, 242 retrieved XML document
precompiler 158 XML structure 24
predicate 26–27, 105, 111, 173–174, 257–258 return 16, 29–30, 91, 94, 101, 134, 168, 203, 229, 257,
prefix 8, 110, 172, 230 260
primary schema 39 RETURN Code (RC) 40, 199, 201
Index 303
U XHTML 1.0 Frameset 17
UDF 43, 116–118 XHTML 1.0 Strict 16
UDFs 50, 115–116 XHTML 1.0 Transitional 17
UK62510 245 XHTML example 18
Unicode 2, 56, 58, 62, 158–159, 200 XID XMLADDRESS 26
Uniform Resource Identifier 8 XLink 17
Uniform Resource Identifier (URI) 82 XML xix–xx, 1–3, 20–22, 29, 47–48, 53–54, 75–76,
universal table space 32, 54, 56, 60, 65, 169, 215 89–90, 110, 119–120, 131–132, 157–158, 183–184, 234,
UNLOAD 137, 189–190, 226, 241 248, 267–268, 278–280
UPDATE 32–34, 52, 56, 61, 76, 79, 87, 92, 118, 127, definition 4, 66, 76–77, 108, 141, 176, 225, 256
134, 167, 170–171, 192, 222, 262 editor 45
URI 8, 79–80, 240 Repository 22, 37, 81
URL 13, 45 Schema 5, 9, 36, 92, 252
USAGE 33, 48, 60, 108, 159–160, 251 standards 2, 24, 50, 252, 267
UTF-8 10–11, 31, 37, 56, 58, 62, 70, 123, 125, 133–134, web Services 45
158–159, 200, 202, 261, 268, 274 XML column 24, 26–27, 29, 37, 53–54, 56, 63, 76, 118,
UTIL EXEC DSNUPROC 191 132–133, 160, 165–166, 168–169, 176–177, 185, 187,
UTILITY Execution 199, 201 195, 198, 235–236, 250, 278, 281
utility run 189, 196 base table spaces 215
billing statements 77
data 26, 54, 59, 76, 132–133, 176, 236, 241
V definition 77
V_CREDTTM TIMESTAMP 92 document 76
V_MSG_ID VARCHAR 94 length 198
Validation 21, 50, 75–76, 79, 90, 141, 164, 182, 186, need 78
234, 243, 252 purchase orders 77
validity 5–6 Reset XML type modifier 79
VALUE 2, 26, 48, 54, 76, 108, 118, 133, 167, 170, 185, table space 218
216, 244, 252 type modifier 176
VALUES 6, 24–25, 70, 77, 82–83, 92, 96, 162, 167, 198, value 198, 223
216, 235, 252, 268 XML document 70
VARCHAR 25, 27, 29, 54, 56, 58, 67, 84, 90–92, 141, XML table 59
161, 166–167, 195, 198, 200–201, 204, 237, 239–240, XML type identifier 182
255–256, 258–259 XML type modifier 78
VARCHAR NULLIF 201 XML columns 24, 44, 54, 56, 60, 62–63, 77, 108, 118,
variable 99, 118–119, 132, 158, 198, 200–201, 250, 254, 134, 169, 184, 191, 195, 235–236, 248, 250
281 XML data xix, 2, 21–22, 32, 48–49, 51, 54, 58, 62–63,
VBS data 227 76, 90, 93, 105, 109, 131–132, 158, 160, 183–184, 188,
versions 22, 32, 50, 56, 60, 76, 86, 90, 122, 132, 215, 190, 223, 226, 235–236, 238, 249–250, 252, 280
240–241, 262 file reference variables 162
views 18 integrity rules 252
internally encoded variable 161
NODEID index 59
W required transformation 12
W3C 4, 9–10, 136
Storage structure 58
web browser 5, 277
Using non-XML variables 161
web services 2–3, 45, 251
XML variables 161
WebSphere 15, 47, 89, 95–96, 160, 252, 280
XML data model 36, 251
WebSphere Message Broker 121
XML data type 23–24, 76, 95, 97–98, 132, 135, 158, 161,
WebSphere MQ 48, 51–52, 90, 96, 280
253
well-formed XML 9, 31, 76
XML declaration 133–134, 159
well-formedness 5–7
XML document 5, 22–23, 48, 52–53, 56, 58, 76, 82, 84,
white space 31
87, 90–91, 96, 115, 117, 132, 159, 167, 184–185,
whitespace 31–32, 76, 198
191–192, 234, 237, 241, 249–250, 260, 280
wide range 45, 89, 240, 251
Account Name 119
WLM 38–39, 96, 234
adhere 6
WLM environment 39
code page 160
credit transactions 104
X data element 27
XHTML 16 data elements 23
Index 305
159, 200, 202, 224–225, 229, 268, 274
xmladdress c 26
XMLADDRESS table 30
second row 33
single XML document 30
XMLAGG 113
XMLELEMENT 25, 112–115, 178
XMLEXISTS 26, 111, 174, 257
XMLEXISTS predicate 27, 112, 258
XMLMODIFY function 32, 84, 127, 169
XMLNAMESPACES 94, 98, 105, 167, 174, 258–259,
265
xmlns 5, 8, 37, 70, 82–83, 122, 192, 268
XMLPARSE 30–32, 61, 86, 118, 161, 179
XMLPARSE function 32
xmlpattern 35, 73, 108, 175, 239, 255, 257
XMLQUERY function 29
[Link] WK01 189
[Link] WK02 189
[Link] WK03 189
[Link] WK04 189
XMLSERIALIZE 30–31, 120, 161, 192, 211
XMLTABLE 26, 28, 93–95, 167, 173, 235, 257–258, 281
XMLTABLE function 28–30, 32, 93, 102, 104–105, 113,
132, 167, 173–174, 180, 258–259, 264
result table 113
row XPath expressions 114
XMLXSROBJECTID scalar function 87
XPATH 14, 16, 26, 108, 240, 265
XPath 12, 14, 22, 24, 26–27, 29–30, 84, 109–110, 167,
171, 174, 235, 240, 248, 250, 255, 264–265
XPath 2.0 14
XPath expression 18, 27–29, 44, 109–113, 173, 256
good understanding 35
XPath expressions 14, 29, 35, 113–114, 257, 265
XPath location 34
last sequential node 34
XQuery 15, 24, 26, 105, 115–117
xs
element name 11
XSD 6, 9, 11, 38, 45, 70, 79, 91, 140, 165, 182, 192, 239,
255, 268, 280
xsi 70, 82, 192, 211, 259, 268
XSL 12, 280
xsl
value-of select 18
XSL transformation 13
result tree 13
XSLT 12, 14, 52, 139, 152, 280
XSLT processor 13
desired behavior 13
XSLT stylesheet 18
XSLT transformation 18
XSR 38, 80, 87, 91, 168, 234, 251
XSR object 39
Z
z/OS xix, 4, 19, 91, 132, 165, 195, 228, 230, 234,
240–241, 260–261
Extremely pureXML
in DB2 10 for z/OS ®
Develop Java and The DB2 pureXML feature offers sophisticated capabilities to store,
process and manage XML data in its native hierarchical format. By INTERNATIONAL
COBOL applications
integrating XML data intact into a relational database structure, users TECHNICAL
accessing XML and
can take full advantage of DB2’s relational data management features. SUPPORT
SQL data
In this IBM Redbooks publication, we document the steps for the ORGANIZATION
implementation of a simple but meaningful XML application scenario.
Administer your XML
We have chosen to provide samples in COBOL and Java language. The
and SQL data purpose is to provide an easy path to follow to integrate the XML data
type for the traditional DB2 for z/OS user.
Choose the best BUILDING TECHNICAL
We also add considerations for the data administrator and suggest best INFORMATION BASED ON
options for practices for ease of use and better performance. PRACTICAL EXPERIENCE
installation and use
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.