Search results

Release notes for IBM Optimization Service Center for DB2 for z/OS.

This presentation discusses migration to DB2 9 and preparing to use it. We'll emphasize recommendations from many other customers and items that tend to be missed, with pointers to more information. The content of this session focuses on the tasks of the person who installs DB2. Systems programmers and database administrators generally perform this task.

The following changes are not yet available in the published version of the DB2® for z/OS® Installation Guide. These changes are made in response to customer feedback sent to db2zinfo@us.ibm.com or through the feedback link in the information center. When these changes are included in the product documentation, they are removed from the information updates Web page.

The following changes are not yet available in the published version of the DB2® UDB for z/OS® Installation Guide. These changes are made in response to customer feedback sent to db2zinfo@us.ibm.com or through the feedback link in the information center. When these changes are included in the product documentation, they are removed from the information updates Web page.

The DSNZPARM installation parameter CONTSTOR (DSN6SPRM macro) controls whether DB2 for z/OS periodically contracts the Agent Local Non-System pool for each DB2 thread. This white paper explains the effects of specifying CONSTOR=YES.

DB2® buffer pools are a key resource for ensuring good performance. This is becoming increasingly important as the difference between processor speed and disk response time for a random access I/O widens in each new generation of processor. A System z® processor can be configured with large amounts of storage which, if used wisely, can help compensate by using storage to avoid synchronous I/O. The purpose of this Redpaper is to: - Describe the functions of the DB2 buffer pools - Introduce a number of metrics for read and write performance of a buffer pool - Make recommendations on how to set up and monitor the DB2 buffer pools - Provide results from using this approach at a number of customers The paper is intended to be read by DB2 system administrators but it may be of interest to any z/OS® performance specialist. It is assumed that the reader is familiar with DB2 and performance tuning.

Distributed Relational Database Architecture™ (DRDA®) is a set of protocols that permits multiple local and remote database systems and application programs, to work together. Any combination of relational database management products that use DRDA can be connected to form a distributed relational database management system. DRDA coordinates communication between systems by defining what can be exchanged and how it must be exchanged. DB2® for z/OS® Distributed Data Facility (DDF) is a built-in component which provides the connectivity to and from other servers or clients over the network. DDF is a full-function DRDA compliant transaction monitor which, equipped with thread pooling and connection management, can support very large networks. Different z/OS workload management priorities can be assigned to different, user-specified classes of DDF-routed application work. In this IBM® Redbooks® publication we describe how to set up your DDF environment, and how to deploy the DDF capabilities in different configurations, including how to develop applications that access distributed databases. We also describe a set of more advanced features, such as thread pooling and high availability distributed configurations, in a DB2 data sharing environment, as well as the traces available to you to do performance monitoring and problem determination. In summary, we show how a high-volume, highly available transactional application can be successfully implemented with a DB2 for z/OS data server accessed by all types

It seems more articles attempt to introduce the DB2 community to a favorite DSNZPARM. This can turn into the classical “good news, bad news” joke. This presentation examines the “truth” about those hidden, not so hidden (opaque), and completely exposed DSNZPARMs.

The EDITUTL1 and EDITUL2 datasets need to be preallocated BEFORE you run the DSNTINST clist.

How can I make the DB2 work file table space generator program (DSNTWFG) create work file table spaces with an explicit SECQTY?