IBM Support

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

Subscribe

You can track all active APARs for this component.

 

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 number

    II09139

  • Reported component name

    PB LIB INFO ITE

  • Reported component ID

    INFOPBLIB

  • Reported release

    001

  • Status

    CLOSED CAN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    1995-12-18

  • Closed date

    1997-05-01

  • Last modified date

    1999-06-08

  • 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

[{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
08 June 1999