II09139: CHANGES TO DB2 ADMINISTRATION GUIDE VOL. 1 SC26326500 THAT DID NOT MAKE DB2 R410 GA PUBS. CONTINUED IN II10229.

APAR status

• Closed as canceled.

Error description

• 5740xyr00 DB2 R410 V4
  This APAR documents changes to the DB2 Administration Guide
  Volume 1 SC26-3265-00 which did not make Version 4.1 GA pubs.
  Continued in II10229.
  ============================================================
  Version 4 Book Title: Administration Guide, Volume 1
  Pages: 2-55
  Change Description:
  
  The following paragraph will be added before the last
  paragraph on page 2-55 that starts "To create a type 2
  index, use the CREATE INDEX...":
  
    The storage space required for an index depends
    on several factors.
    See "Chapter 2-2, Estimating DB2 Storage Needs"
    in the Installation Guide for more information
    on calculating the estimated space required
    for a Type 2 index.
  ============================================================
  Version 4 Book Title:  Administration Guide, Volume 1
  Pages: 2-61
  Change Description:
  Modify the text in Chapter 2-5 'Designing Indexes'
  under the heading 'Partitioned Indexes' starting
  with the second paragraph:
  
  | "In DB2 Version 3,
     if you have both a partitioned index and a
     nonpartitioned index on the same table, you lose
     some of the benefits of partition-level
     independence for utility operations.
     Concurrent utility jobs can operate independently
     on partitions of the table space and its
     partitioned index.
  |  However, access to a nonpartitioned index must
  |  be sequential.
  |  In DB2 Version 4, logical partitions of a
  |  nonpartitioned index can usually be accessed by
  |  utilities and SQL applications concurrently.
  |  The index must be type 2.
  
  |  For more information about utility operations,
  |  nonpartitioned indexes, and impacts of
  |  using Type 1 or Type 2 indexes, see
  |  "Utility Operations with
  |  Nonpartitioned Indexes" on page 5-181.
  ============================================================
  Version 4 Book Title: Administration Guide Volume 1
  Pages: 2-146
  Change Description:
  
   5. Convert the datasets back to DB2-managed using
      new DB2 storage group. Use the following
      SQL ALTER TABLESPACE and ALTER INDEX statements:
  
      ALTER TABLESPACE dbname.tsname
        USING STOGROUP stogroup-name
        PRIQTY priqty
        SECQTY secqty;
  
      ALTER INDEX index-name
        USING STOGROUP stogroup-name
        PRIQTY priqty
        SECQTY secqty;
  ==============================================================
  Version 4 Book Title:  Administration Guide, Volume 1
  Pages: 2-146
  Change description:
  Add the following information at the end of step 5 on
  page 2-146:
  
     If you specify USING STOGROUP without specifying the
     PRIQTY and SECQTY clauses, the default values are used.
     For more information about USING STOGROUP, see "SQL
     Reference".
  ============================================================
  Version 4 Book Title:  Administration Guide, Volume 1
  Pages: 2-148
  
  Modify the text for the bullet list item "The DSNTIAUL
  Program" as follows:
  
      "The program unloads a DB2 table into a
       sequential file and generates statements to
       allow the LOAD utility to load it elsewhere.
   |   For instructions on using DSNTIAUL, see Section 2
   |   of Installation Guide."
  ============================================================
  Version 4 Book Title: Administration Guide, Volume I
  Pages: 3-72, 3-88
  Change Description:
  
   Page 3-72, Figure 65 (part 2), Step 4 (ID Check for
   Connections), add the following paragraphs after ..."DB2
   rejects the request":
  
    In addition, depending on your RACF environment, the
    following RACF checks may also be performed:
  
    1) If the RACF APPL class is active, RACF will verify that
    the ID has been given access to the DB2 APPL.  The APPL
    resource that is checked is the LU name that the requester
    used when the attach request was issued.  This will either
    be the local DB2 logical unit name (LUNAME) or the generic
    LU name.
  
    2) IF the RACF APPCPORT class is active, RACF will verify
    that the ID is authorized access to MVS from the port of
    entry (POE).  The POE that is used in the verify call is
    the requesting LU name.
  
  Page 3-72, Figure 65 (part 2), Step 5, add the following
  paragraph after ..."resources defined to RACF":
  
    The RACROUTE macro call will also verify that the user is
    authorized to use DB2 resources from the requesting system,
    known as the port of entry (POE); for details, see "Permit
    Access for Users and Groups" on page 3-88.
  
  Page 3-88, a new sub-heading under "Permit Access for Users
  and Groups:
  
    Distributed Data Facility:
    ==========================
    The RACF RACROUTE macro that DB2 uses allows access from
    remote requesters to be governed by the requesting system's
    logical unit name (LUNAME), the local DB2 server LUNAME,
    as well as the user ID.
  
    Controlling Distributed access based on requesting LUNAME
    ---------------------------------------------------------
    There are two methods that can be used to control DB2
    distributed access based on the requesting system's LUNAME.
    The preferred method is to use the DSNR RACF class with a
    PERMIT specifying a conditional WHEN(APPCPORT(x)) clause.
  
    For example, the following RACF command lets subsystem DSN
    receive DDF requests, from user ALPHA, that originate from
    any partner in the network:
  
      PERMIT DSN.DIST CLASS(DSNR) ID(ALPHA) ACCESS(READ)
  
    To limit ALPHA to request coming from the partner with the
    LUNAME GILROY, use:
  
      PERMIT DSN.DIST CLASS(DSNR) ID(ALPHA) ACCESS(READ) +
             WHEN(APPCPORT(GILROY))
  
    The second method is to use the RACF APPCPORT class
    instead of the RACF DSNR class.  This method requires that
    you define an APPCPORT resource profile that specifies the
    requesting LUNAME and then PERMIT users access to that
    resource.
  
    The RACF APPCPORT class may already be active on your
    system and a resource profile specifying the requesting
    LUNAME may already exist.  If this is the case and you want
    to use the recommended RACF DSNR class to control access,
    then it will be necessary to PERMIT READ access to the
    APPCPORT resource for those userid's that will be used
    with DB2.
  
    Controlling Distributed access based on local DB2 server
    --------------------------------------------------------
    LUNAME
    ------
    Although you can use the RACF APPL resource class to
    control DB2 Distributed access, it is not recommended.  A
    better solution is to use the RACF DSNR resource class to
    maintain all of the DB2 access controls under the single
    RACF DSNR class.
  
    The RACF APPL class may already be active on your system
    and a resource profile restricting access may already
    exist.  If this is the case and you want to use the
    recommended RACF DSNR class to control access, then it will
    be necessary to PERMIT READ access to the APPL resource for
    the userid 's that will be used with DB2.  The APPL
    resource that is checked is the LU name that the requester
    used when the attach request was issued.  This can be
    either the local DB2 LUNAME or the generic LUNAME.
  ============================================================
  Version 4 Book Title:  Administration Guide, Volume 1
  Pages:  4-45
  Change Description:
  
  In Figure 72, DISPLAY THREAD Showing CICS Connections,
  for all threads with status N, change the token value to 0.
  ============================================================
  Version 4 Book Title: Administration Guide, Volume 1
  Page: 4-83
  Change Description:
  
  Add this text under "Archiving to DASD Volumes":
  
  DB2 uses the basic direct access method (BDAM) to read
  archive logs from DASD.  DFSMS/MVS does not support reading
  of compressed data sets using BDAM.  You should not,
  therefore, use DFSMS/MVS hardware compression on your
  archive log data sets.
  ============================================================
  Version 4 Book Title: Administration Guide, Volume 1
  Pages: 4-98
  Change Description under How to Defer Restart Processing:
  
  change the bullet from:
    Leave the object's data sets unready....
  to:
    Vary the device (or volume) on which the objects
    reside offline.  If the data sets containing
    an object are not available, and the object
    requires recovery during restart, DB2 flags it as
    stopped and requiring deferred restart.  DB2 then
    restarts without it.
  ============================================================
  Version 4 Book Title: Administration Guide Volume 1
  Pages: 4-120
  Change Description:
  
  Under "Step 2: Copying the Data," change the second
  sentence to:
  
  "That operation allows only read access to the data while
  it is copied."
  ============================================================
  Version 4 Book Title:  Administration Guide, Volume 1
  Pages: 4-121
  Change Description:
  After sentence "Copy SYSLGRNX and SYSCOPY last." add the
  following sentences.  Install job DSNTIJIC creates image
  copies of the DB2 catalog and directory table spaces.  See
  Chapter 2 of the Install Guide for a description of job
  DSNTIJIC.
  ============================================================
  Version 4 Book Title: Administration Guide, Volume 1
  Page: 4-170
  Change Description:
  
  Change the paragraph that begins, "If you want to disable
  down-level detection," to this:
  
  How to control down-level detection:
  
  Use the subsystem parameter DLDFREQ to control how often the
  level ID of a page set or partition is updated.  DB2 accepts
  any value between 0 and 65535.  For example, to update the
  level ID after every checkpoint that a page set is open for
  update activity, set DLDFREQ=1.  To update the level ID
  after every fifth checkpoint that the page set is open for
  update activity, set DLDFREQ=5.  DLDFREQ=5 is the default.
  To disable down-level detection, set DLDFREQ=0.
  
  Consider the following when you choose a value for DLDFREQ:
  - How often do you use backup and restore methods outside of
    DB2's control?
    If you rarely use such methods, you do not need
    to update the level ID often.
  - How many page sets are open for update at the same time?
    If DB2 updates level IDs frequently, you have extra
    protection against down-level page sets.  However, if the
    level IDs for many page sets must be set at every
    checkpoint, you might experience a performance
    degradation.
  - How often does the subsystem take checkpoints?
    If the subsystem takes checkpoints frequently, the level
    ID can be set after a larger number of checkpoints.
  
  To activate a new value of DLDFREQ, rerun job DSNTIJUZ
  and restart DB2.                  (ref. msgDSNB232I)
  ============================================================
  Version 4 Book Title: Administration Guide, Volume 1
  Pages: 4-183
  Change Description:
  Replace the second and third bullets under line 'Recover the
  BSDS:' with the following bullets.
  b. To determine the RBA range for this archive log use the
     print log map utility (DSNJU004) to list the current BSDS
     contents.  Find the most recent archive log in the BSDS
     listing and add 1 to it's ENDRBA value.  Use this as the
     STARTRBA.  Find the active log in the BSDS listing that
     starts with this RBA and use it's ENDRBA as the ENDRBA.
  c. Use the change log inventory utility (DSNJU003) to register
     the latest archive log tape data set in the archive log
     inventory of the BSDS just restored.  This is necessary
     since the BSDS image on the archive log tape does not
     reflect the archive log data set residing on that tape.
     For data sharing, running DSNJU003 is critical.  Group
     buffer pool checkpoint information is stored in the BSDS
     and needs to be included from the most recent archive log.
  ============================================================
  The documentation changes are continued in II10229.
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• closed for db2info retention
  

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