II07837: CHANGES TO DB2 ADMINISTRATIVE GUIDE VOLUME 3, SC26-4888-00 THAT DID NOT MAKE VERSION 3 GA PUBS. CONTINUED IN II08214.

APAR status

• Closed as canceled.

Error description

• This APAR documents changes to the DB2 Administration Guide
  Volume 3 SC26488800 which did not make Version 3 GA pubs.
  Continued in II08214.
  5740xyr00 R310
  ================================================================
  Version 3 Book Title:  DB2 Administration Guide, Volume 3
  Pages:  7-16
  Change Description:
  
  Add the following to Table 151, in row 2 for "Periodic
  Monitoring":
  
  In column 2, add "DB2PM".
  In column 3, add "Consider ACCTG CLASS(2)".
  ================================================================
  Version 3 Book Title:  DB2 Administration Guide, Volume 3
  Pages:  7-18
  Change Description:
  
  Add the following sentence to the end of numbered paragraph
  1:
  
  Evaluate the effectiveness of decisions about I/O scheduling
  priority as appropriate.
  ================================================================
  Version 3 Book Title:  DB2 Administration Guide, Volume 3
  Pages:  7-69
  Change Description:
  
  Change the two paragraphs under "Accounting and Statistics
  Traces" to read as follows:
  
  Accounting and Statistics Traces:  The DB2 accounting class 1
  and 3 traces and statistics class 1, 3, and 4 traces,
  together, cost only about 2% to 5% of processing overhead.
  We recommend that you enable this collection of performance
  information, because it is necessary for capacity planning.
  Do this by specifying YES for the SMF STATISTICS and SMF
  ACCOUNTING parameters of the Tracing installation panel
  (DSNTIPN).
  
  Enabling accounting class 2 along with accounting classes 1
  and 3 provides additional detail relating directly to the
  accounting record IFCID 3, as well as recording thread level
  entry and exit into and out of DB2.  The cost of accounting
  class 2 varies, but depending on the application, it can be
  significant.
  ================================================================
  Book Title: DB2 Administration Guide, Vol 3.
  Page Number: 7-109
  Change Description:
  
  In the paragraph on "Infrequently Updated Data Sets", the third
  sentence says of PCLOSET, "the default is 60 minutes."  That is
  incorrect: the correct value is 10 minutes.
  ================================================================
  Version 3 Book Title:  DB2 Administration Guide, Volume 3
  Pages:  7-111
  Change Description:
  
  "Query 2" on this page is in error and will not execute.
  Change it to read as follows:
  
    SELECT CLOSERULE, COUNT(*)
    FROM   SYSIBM.SYSINDEXES T1, SYSIBM.SYSINDEXPART T2
    WHERE  T1.NAME = T2.IXNAME
    AND    T2.PARTITION < 1
    GROUP BY CLOSERULE;
  ================================================================
  Version 3 Book Title: DB2 Administration Guide, Volume 3
  Pages:  7-120
  Change Description:
  
   The following paragraph will be inserted following the
   second paragraph under the heading "Extending Data Sets":
  
   DB2 gets a data set extension when the
   remaining space in the current extension is
   half of the smaller of either the primary or the
   secondary space size.  For example, when the
   primary allocation is 100 cylinders and the
   secondary allocation is 10 cylinders, then the second
   extent takes place after 95 cylinders are used in
   the primary allocation, and each time after 5 cylinders
   are used for each secondary allocation.
  ================================================================
  Book Title: DB2 Administration Guide, Vol 3.
  Page Number: 7-128
  Change Description:
  
  The last half of the paragraph at the top of the page is
  expanded to read as follows:
  
    The DDF address space (DSNDIST) is given a lower priority
    than local user address spaces, because work done in DSNDIST
    is done in SRB mode on behalf of a remote user.  That might
    consume considerable resources, because SRBs cannot be
    preempted by work in an address space at equal or lower
    priority.  But beware of giving DSNDIST a very low priority
    only because there are few distributed users.  When any user
    task terminates, whether distributed or not, DB2 must
    communicate with DSNDIST.  If that communication is unduly
    delayed, the terminating task could be swapped out, with
    corresponding delays to itself and to others enqueued
    behind it.
  ================================================================
  Version 3 Book Title:  DB2 Administration Guide, Volume 3
  Pages:  7-167
  Change Description:
  
  From the table showing "Operation" and "Mulitiple of Timeout
  Period". delete the row for "Utilities".
  ================================================================
  Version 3 Book Title:  DB2 Administration Guide, Volume 3
  Pages:  7-174
  Change Description:
  
  Add the following sentence to the paragraph that starts,
  "CS means cursor stability:" (second paragraph from the
  bottom of the page):
  
  'If the SQL statement is SELECT...INTO, the lock is
  released as soon as the statement is executed.'
  ================================================================
  Version 3 Book Title:  DB2 Administration Guide, Volume 3
  Pages:  7-175
  Change Description:
  
  Replace the text under the heading, "When Plan and Package
  Options Differ" with the following:
  
  A plan bound with one set of options can include packages in
  its package list that were bound with different sets of
  options.  In general, statements in a DBRM bound as a
  package use the options that the package was bound with, and
  statements in DBRMs bound to a plan use the options that the
  plan was bound with.
  
  The rules are slightly different for the bind options that
  affect locking, RELEASE and ISOLATION.  The values of those
  two options are set when the lock on the resource is
  acquired and usually stay in effect until the lock is
  released.  But a conflict can occur if a statement that is
  bound with one pair of values requests a lock on a resource
  that is already locked by a statement that is bound with a
  different pair of values.  DB2 resolves the conflict by
  resetting each option with the available value that causes
  the lock to be held for the greatest duration.
  
  As a result:
  
  IF THE CONFLICT IS BETWEEN:          THEN THE VALUE USED IS:
  
  RELEASE(COMMIT) and RELEASE(DEALLOCATE)  RELEASE(DEALLOCATE)
  
  ISOLATION(CS) and ISOLATION(RR)          ISOLATION(RR)
  ================================================================
  Version 3 Book Title:  DB2 Administration Guide, Volume 3
  Pages:  7-175
  Change Description:
  
  In the second full paragraph on the page, which begins,
  "For non-updatable cursors bound using ISOLATION(CS)...",
  remove entirely this sentence (the last in the paragraph):
  
    However, if DB2 must lock the data, the duration that the
    lock is held is reduced by releasing it before returning
    to the user.
  ================================================================
  Version 3 Book Title: DB2 Administration Guide
  Pages:  7-224, 7-225
  Change Description:
  
  The sentence on p.7-224 in the paragraph labeled "Example 1:
  Single Table Access" now states:
    'If DB2 decides not to use parallel I/O operations for a
    step, ACCESS_DEGREE and ACCESS_PGROUP_ID are blank.'
  
  This is changed to:
    'If DB2 decides not to use parallel I/O operations for a
    step, ACCESS_DEGREE and ACCESS_PGROUP_ID contain null
    values.'
  
  The sentence on p.7-225 in the paragraph labeled "Example 4:
  Hybrid Join" now states:
    '...therefore, JOIN-DEGREE and JOIN_PGROUP_ID are blank.'
  
  This is changed to:
    '...therefore, JOIN-DEGREE and JOIN_PGROUP_ID contain
    null values.'
  
  In addition, the tables on pages 7-224, and 7-225 are
  changed to show null values instead of blanks in the
  JOIN-DEGREE and JOIN_PGROUP_ID columns.
  ================================================================
  Version 3 Book Title: DB2 Administration Guide, Vol 3.
  Pages: 7-257
  
  The following will be added after the 2nd paragraph under
  the heading 'Are all Predicates Coded Correctly?':
  
  Change Description:
  
  For example, assume that
  a host variable and an SQL column are defined as follows:
  
      Assembler Declaration         SQL definition
      ---------------------         --------------
  
      MYHOSTV  DS PLn 'value'       COL1 DECIMAL(6,3)
  
  When 'n' is used, the host variable precision is '2n-1'.
  If n = 4 and value = '123.123',
  then a predicate such as the following is not a matching
  predicate for an index scan because the precisions are
  different:
  
      ...WHERE COL1 = :MYHOSTV...
  
  One way to avoid an inefficient predicate using decimal host
  variables is to declare the host variable without the 'Ln'
  option:
  
      MYHOSTV  DS P'123.123'
  
  This guarantees the same host variable declaration as the
  SQL column definition.
  
  Please see Section 3 of the DB2 Application Programming and
  SQL Guide, for more information.
  ================================================================
  Version 3 Book Title: Administration Guide Volume 3
  Pages: X-109
  Change Description:
  
  There is a missing log record in 'Table 207. Example
  of a Log Record Sequence for an Insert of One Row Using
  TSO'.  Add the following log record and description
  before the row containing Phase 1-2 Transition:
  
  ------------------------------------------------------------
  Begin Commit 1 &#166; The beginning of the commit process.  The
                 &#166; application has requested a commit either
                 &#166; explicitly (EXEC SQL COMMIT) or implicitly
                 | (for example, by ending the program).
  ------------------------------------------------------------
  ===============================================================
  Book Title: DB2 Administration Guide, Volume 3
  Page Number: X-160
  Change Description:
  
  In the second paragraph following "Possible Data Loss:",
  replace the last sentence (beginning, "Dispatching priority
  is such that...") with the following sentence:
  
  It is the user's responsibility to have a high enough
  dispatching priority that the application can be posted and
  then issue the READA request before significant data is lost.
  ===============================================================
  Book Title: DB2 Administration Guide, Volume 3
  Page Number: X-161
  Change Description:
  
  In the last paragraph before "Example", replace the last
  sentence (beginning, "Another method is to use ...")
  with the following sentence:
  
  Another method is to use the buffer information area on a
  START TRACE command request, shown in Table 223 on page
  X-152, to specify an ECB address to post when a specified
  number of bytes have been buffered.
  ===============================================================
  Version 3 Book Title:  DB2 Administration Guide, Volume 3
  Pages:  X-165
  Change Description:
  
  In Table 229, "IFCID Area", the data type for the field at
  offset 2 is changed to "Signed two-byte integer".
  ===============================================================
  Version 3 Book Title: DB2 Administration Guide, Vol. 3
                        & Master Index
  Pages:  I-41 & p. 103.
  Change Description:
  
           add index entry
             'Parrallel I/O Processing
                 SEE I/O Processing'
  ================================================================
  Continued in II08214.
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• close for INTERNET viewing
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels