II09480: CHANGES TO DB2 ADMINISTRATION GUIDE VOL. 2 SC26-3265-00, THAT DID NOT MAKE V4.1 GA PUBS. CONTINUED IN II09143 & II10644.

APAR status

• Closed as canceled.

Error description

• 5740xyr00 DB2 R410 V4   continued in II09143 & II10644
  This APAR documents changes to the DB2 Admin. Guide Vol. 2
  SC26326500 which did not make Version 4.1 GA pubs.
  ==============================================================
  Version 4 Book Title: Administration Guide, Volume 2
  Pages: 5-54
  Change description:
  
  The following 2 sentences in the description of the
  hiperpool CASTOUT attribute are incorrect:
    "Specifying CASTOUT as NO protects pages from being
     stolen when their usage is low.  Pages remain
     unless MVS hiperspace maintenance
     requires that the expanded storage pages
     be reconfigured out of the system"
  
  Replace the above sentences with:
     Specifying CASTOUT as NO tells MVS to give high
     priority to keeping the data cached in the hiperpool.
  ============================================================
  Version 4 Book Title: Administration Guide, Vol. 2
  Pages: 5-96
  Change Description:
    The description of the WRITE THRESHOLD field is incorrect.
    Replace the first two sentences with the following:
  
  The WRITE THRESHOLD field indicates the number of
  contiguous 4KB output buffer pages that are allowed to fill
  before data is written to the active log data set.
  The maximum is 256.
  ============================================================
  Version 4 Book Title: Administration Guide, Volume 2
  Pages: 5-131
  Change Description:
   Clarify the cases when threads are available for reuse
   by CICS transactions.
  
    When CICS Threads are Released and Available for Reuse
  
    An existing thread can be reused by a new transaction
  # with the same plan and on the same RCT entry.
  # The thread is released for reuse (or for termination)
  # at the end of a task (EOT) or at SYNCPOINT.
  
  # o   A transaction that is not terminal-driven releases
  #     its thread at the end of a task.
  
  # o   A transaction that is terminal-driven can release its
  #     thread at SYNCPOINT if certain conditions are true.
  #     DB2 uses the following logic to determine whether
  #     a thread can be released at SYNCPOINT, or if it must
  #     wait until EOT:
  
  #     1.  Is the thread terminal-driven?
  
  #         If so, go to the next step.  If not, the thread
  #         cannot be released until EOT.
  
  #     2.  Are the following special registers in their
  #         initial state?
  #             CURRENT SQLID
  #             CURRENT SERVER
  #             CURRENT PACKAGESET
  #             CURRENT RULES
  
  #         If yes, go to the next step.  If no, the thread
  #         cannot be released until EOT.
  
  #     3.  Has the special register CURRENT DEGREE never
  #         been changed during the life of the thread?
  
  #         If it has not been changed, go to the next step.
  #         If it has been changed, the thread cannot be
  #         released until EOT.
  
  #     4.  Are all cursors declared WITH HOLD closed?
  
  #         If yes, this thread can be released at SYNCPOINT.
  #         If no, and this is a local connection,
  #         this thread cannot be released until EOT.
  
  #         If no, and this is a remote connection,
  #         look at the DISCONNECT bind option:
            option:
  
  #         AUTOMATIC  All connections (even those with open
  #                    cursors) are released at commit, and
  #                    the thread can be released.
  #                    However, the thread is NOT reusable
  #                    if you have a type 1 connection and
  #                    the BIND option CURRENTSERVER is a
  #                    remote location.
  
  #         EXPLICIT  Does the application use the SQL
  #                   statement RELEASE ALL?  If
  #                   yes, the thread can be released.
  #                   If not, the thread cannot
  #                   be released until EOT.
  
  #         CONDITIONAL The thread cannot be reused until
  #                     EOT if there are any open cursors
  #                     defined WITH HOLD.
  ============================================================
  Version 4 Book Title: DB2 Administration Guide, Volume 2
  Pages: 5-162
  Change Description:
   To table 68, add information about the timeout multiplier
   value for the DB2 command STOP DATABASE. The multiplier
   value is 10, and it is not a modifiable value.
  ============================================================
  Version 4 Book Title:  Administration Guide, Vol 2.
  Pages: 5-172, 5-174
  Change Description:
    On page 5-172, delete the currently documented restriction
    for isolation UR and change to the following:
  
    There are restrictions on isolation UR. See page 5-174.
  
    On page 5-174, change the 'Restrictions' section
    for UR as follows:
  
  Restrictions:  You cannot use UR isolation for the types
  of statement listed below.
  If you bind with ISOLATION(UR), and the statement does not
  specify WITH RR or WITH RS, then DB2 uses CS isolation for:
  
     o INSERT, UPDATE, and DELETE
     o Any cursor defined with FOR UPDATE OF
  If you bind with isolation UR or specify WITH UR on a
  statement, DB2 does not choose a type 1 index as a candidate
  for the access path.  For packages bound without specifying
  an isolation, DB2 might choose a type 1 index for the access
  path. If it does, and then you run the package under a plan
  bound with UR, DB2 changes the isolation level to cursor
  stability.
  ============================================================
  Version 4 Book Title: Administration Guide, Volume 2
  Pages: 5-173
  
  Modify description of CURRENTDATA(YES) to include
  information about query parallelism:
  
    Locally, CURRENTDATA(YES) means that the data upon
    which the cursor is positioned cannot change while
    the cursor is positioned on it.  If the cursor is
    positioned on data in a local base table or index,
    then the data returned with the cursor is current
    with the contents of that table or index.  If the
    cursor is positioned on data in a work file, the
    data returned with the cursor is current only with
    the contents of the work file; it is not neces-
    sarily current with the contents of the underlying
    table or index.
  
  | Similarly, if the cursor uses query parallelism,
  | data is not necessarily current with the contents of
  | the table or index, regardless of whether a work
  | file is used.  Therefore, for work file access or
  | for parallelism on read-only queries, the CURRENTDATA
  | option has no effect.
  
  | If you are using parallelism but want to maintain
  | currency with the data,
  | you have the following options:
  
  | o   Disable parallelism (Use SET DEGREE = '1' or bind
  |     with DEGREE(1))
  
  | o   Use isolation RR or RS (parallelism can still
  |      be used)
  
  | o   Use the LOCK TABLE statement (parallelism can
  |     still be used)
  ============================================================
  Version 4 Book Title: Administration Guide, Vol. 2
  Pages: 5-175, 176
  Change Description:
  Clarify that locks that are maintained for cursors defined
  WITH HOLD are not data consistency locks.
  
    The Effect of WITH HOLD for a Cursor
  
    For a cursor defined as WITH HOLD, the cursor
    position is maintained past a commit point.
    Hence, locks and claims needed to maintain that position
    are not released immediately, even if they were acquired
    with ISOLATION(CS) or RELEASE(COMMIT).
  
  | For locks and claims needed for cursor position,
  | the rules described above differ as follows:
  
  | PAGE AND ROW LOCKS:  The page or row lock that is
  | necessary for cursor position is held past the commit
  | point.  However, an X or U page or row lock
  | is demoted to an S lock at that time.
  | (Because changes have been committed, exclusive control
  | is no longer needed.)  After the commit point, the lock
  | is released according to the isolation level at which it
  | was acquired:  for CS, when all cursors on the
    page are moved or closed; for  RR or RS, at the next
    commit point, provided that no cursor is still
    positioned on that page or row.
  ============================================================
  Version 4 Book Title:  Administration Guide, Vol. 2.
  Pages: 5-226
  Change Description:
     The descriptions of the following columns in Table 77
     are incorrect. The corrections are as follows:
  
  -CARD column of SYSIBM.SYSTABLES: Add the phrase '-1 to
   trigger DB2's use of the default value, 10000.'
  
  -NACTIVE column of SYSIBM.SYSTABLESPACE: The formula for
   the default should be: (CEILING(1+CARD/20))
  
  -NPAGES column of SYSIBM.SYSTABSTATS: The formula for
   the default should be: (CEILING(1+CARD/20))
  ============================================================
  Version 4 Book Title: Administration Guide, Vol. 2
  Pages:  5-230
  Change Description:
   Add the following to the description of the QUERYNO column:
  
  FETCH statements do not each have an individual
  QUERYNO assigned to them.
  Instead, DB2 uses the QUERYNO of the DECLARE CURSOR
  statement for all corresponding FETCH
  statements for that cursor.
  ===============================================================
  Version 4 Book Title: DB2 Administration Guide, Vol 2.
  Pages: 5-247
  Change Description:
  Add the following restriction to the information about
  limited partition scan:
  
  Restriction with Host Variables and Parameter Markers:
  Limited partition scan is not supported when host variables
  or parameter markers are used on the first key of the
  primary index. This is because the qualified partition
  range based on such a predicate is unknown at bind time.
  ============================================================
  Version 4 Book Title: Administration Guide, Vol. 2
  Pages: 5-270
  Change Description:
   View materialization can happen in other cases. Change
   the paragraph on 5-270 as follows:
  
    When View Materialization Is Used
  
   In general, DB2 uses materialization to satisfy a view
   reference when there is aggregate processing
   (grouping, column functions, distinct), indicated by the
   defining subselect, in conjunction with either aggregate
   processing indicated by the view referencing statement,
   or the view participating in a join.
  #Table 79 indicates some cases in which materialization
  #occurs.  DB2 can also use view materialization in
  #statements that contain multiple outer joins,
  #or outer joins combined with inner joins. This can happen
  #even when the view definitions are not complex.
  ============================================================
  Version 4 Book Title: DB2 Administration Guide, Volume 2
  Pages:  X-115, X-116, X-119, X-120, X-121
  Change Description:
  
           IFCID's 230 and 254, data sharing information,
           have been added to the Administration Guide,
           Appendix E relating to READS.
           Also, IFCID 202 has been added to the
           list for which qualification has been ignored
           on page X-116. (IFCID202 IFCID230 IFCID254)
  ============================================================
  Version 4 Book Title: Administration Guide, Vol. 2
  Pages:  X-160
  Change Description:
  
    Modify the first sentence of the last paragraph:
  
   If you specified YES in the SMF STATISTICS
   field on the Tracing Panel (DSNTIPN), the statistics trace
   starts automatically when you start DB2,
   |sending class 1, 3, 4, and 5 statistics data to SMF.
  ============================================================
  continued in II10644
  

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