II10280: CHANGES TO DB2 DATA SHARING: PLANNING & ADMIN. SC26-3269-01 THATDID NOT MAKE V4.1 GA PUBS. CONT. IN II09146, II09512, II10881.

APAR status

• Closed as canceled.

Error description

• 5740xyr00 R410 DB2 V4
  This APAR documents changes to the DB2 Data Sharing: Planning
  & Admin. SC26326901 which did not make Version 4.1 GA pubs.
  continuation of II09146, II09512 and II10881.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning andAdmin.
  Pages:  53
  Change Description:
    Modify the text under 'Storage for Coupling Facilities'
    as follows:
  
  STORAGE FOR COUPLING FACILITY STRUCTURES
  
  It is difficult to give precise estimates for coupling
  facility structure sizes used in DB2, partly because every
  environment is different, and partly because storage
  allocation is affected by the processor model and level of
  coupling facility control code you have.  Use the
  information given here for your initial estimates.  If you
  are running on MVS Version 5 Release 2 or subsequent
  releases, you can use these initial estimates as your
  initial size values (INITSIZE) and, depending on how much
  your work load varies, give a larger value for SIZE.  You
  can use an MVS SETXCF START,ALTER command to alter the
  structure from INITSIZE to SIZE and back again.  See
  "Changing Structure Sizes" on page 23 for more information.
  
  For the cache structures (group buffer pools) we give both
  "rule of thumb" estimates and input you can use for the
  storage formulas given in an appendix of Enterprise
  System/9000 and Enterprise System/3090 Processor
  Resource/System Manager Planning Guide.  Consult this guide
  if you are looking for detailed information about planning
  for storage in the coupling facility.
  
  When you decide what your structure sizes are, you must
  include those values in the CFRM policy definition.  See
  MVS/ESA Setting Up a Sysplex for more information about
  creating CFRM policies.
  =============================================================
  Version 4 Book Title: Data Sharing: Planning and Admin.
  Pages: 58
  Change Description:
   This change supersedes the change in II09146. This is a
   more detailed way of estimating EXTRA IRLM storage for
   data sharing.
  
  ESTIMATING A VALUE FOR THE IRLM MAXCSA PARAMETER
  
  The requirements for IRLM storage are described in
  Section 2 of Installation Guide. The recommendation is to
  use PC=NO on the IRLM startup procedure and to set the
  MAXCSA value at the high end of your estimates.
  IRLM does not take the storage unless it needs it.
  If you increase MAXCSA, you might need to increase the CSA
  value in SYS1.PARMLIB, too.
  
  For data sharing, plan for additional storage because of
  additional data sharing locks called P-locks.  These locks
  are held on open page sets and on database descriptors
  (DBDs), skeleton cursor tables (SKCTs), and skeleton
  package tables (SKPTs).  Unlike transaction locks, storage
  for P-locks is held even when there is no transaction
  activity, and therefore they consume storage even with no
  transaction activity.  Plan also for extra storage that
  IRLM needs to build retained locks in case other members
  fail and in case you have to run IRLM diagnostic traces.
  The variables you need to account for are shown in the
  following table.
  
  Table 1. Variables used to Estimate Additional IRLM Storage
  -----------------------------------------------------------
  VARIABLE   DESCRIPTION      CALCULATION
  X           P-locks          N = (MAX_OPEN_DATA_SETS * 500)
                               X = N + (N * .20)
  NOTE:  The formula assumes that more than one P-lock might
  be held on a page set occasionally (such as for castout
  activity) and estimates about 20 percent for P-locks on
  the EDM pool objects and for short-lived page P-locks. If
  you know that your EDM pool has relatively few objects in
  it, you could use a lower percentage for that value.
  See Section 5 (Volume 2) of Administration Guide for more
  information about estimating the maximum number of open
  data sets, or use the value specified for the DSMAX
  subsystem parameter.
  
  Y       Ability to hold update       Dependent on how
          retained locks for a failed  update-intensive
          member                       the workload is.
                                       Start with the
                                       following:
                                          Y= .25X
  
  A      Storage for default diag-    .75MB
         nostic traces
  
  B      Storage for extra diagnostic 1.75MB
         traces that you might run
  
  -----------------------------------------------------------
  For example, suppose that your non-data-sharing IRLM storage
  estimate is 5MB.  If you estimate that this DB2 member could
  have as many as 8000 open data sets, you could calculate the
  IRLM storage as follows:
  
    (8000 * 500) + 800KB = 4.58MB
    +
    1 MB (approximate for retained locks)
    +
    .75MB (default trace storage)
    +
    1.75MB (extra trace storage)
    +
    5MB (non-data-sharing estimate)
    -----------------------
    Total IRLM storage = 13.08MB
  
  DON'T FORGET THE PROPER DISPATCHING PRIORITY:
  Be sure to follow the guidelines documented in Section 5
  (Volume 2) of Administration Guide for setting the
  dispatching priority of IRLM when using workload manager.
  If IRLM dispatching priority is too low, storage might not
  be freed as quickly, and IRLM might run out of storage.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning and Admin.
  Pages: 58
  Change Description:
  
  Add the following paragraph to the section on estimating
  EDM pool storage:
  
  Storage for Reusing Threads
  
  One of the general recommendations for data sharing is to
  reuse threads whenever possible and to bind with the option
  RELEASE(DEALLOCATE). Depending on how much your threads get
  reused, this bind option can mean more EDM pool storage is
  necessary for storing objects used by the plan.  Plan for more
  EDM pool storage if you use RELEASE(DEALLOCATE) and thread
  reuse.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning and Admin.
  Pages: 74, 75, 76
  
  Change Description:
    For each procedure (new group, enable, and new member),
    clarify that the installation job DSNTIJMV
    edits the startup procedure with the
    group and member name that is specified
    on the panel.
  
  P. 74 - Add the following sentence at the end of step 2:
  
  Installation job DSNTIJMV edits the ssnmMSTR
  startup procedure with the group name and
  member name you specify here.
  
  P. 75 - Add the following sentence at the end of step 2:
  
  Installation job DSNTIJMV edits the ssnmMSTR
  startup procedure with the group name and
  member name you specify here.
  
  P. 76 - Add the following sentence at the end of step 2:
  
  Installation job DSNTIJMV edits the ssnmMSTR
  startup procedure with the new member name
  you specify here.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning and Admin.
  Pages:  87
  Change Description:
     Add the following section to the information about
     Removing Members from the Data Sharing Group
  
  WHAT DATA SETS TO KEEP
  
  When you quiesce a member, you must keep the log data sets
  until such time as they are no longer needed for recovery
  (other members might need updates that are recorded on that
  member's log).  You must keep the BSDS, too, because it
  contains information that points to those log data sets.
  
  The BSDS is also needed for group restart. However, if you are
  confident that logs for the quiesced member are no longer
  necessary, because that member has been quiesced for a long
  time or is permanently quiesced, it is possible to delete
  the BSDS data sets.  However, during group restart, you must
  expect the following message:
  
  DSNR020I -DB2G csect-name START MEMBER DB1G, OR REPLY 'NO'
             OR 'QUIESCED'
  
  When you respond with QUIESCED, then DB2 issues
  the following message:
  
  DSNR030I -DB2G csect-name WILL CONTINUE WITHOUT THE DB1G
             MEMBER'S LOG, REPLY 'YES' OR 'NO'
  
  In summary, you must do one of the following things to
  ensure that you have group restart capability:
  
  o   Keep the quiesced member's BSDS data sets
      (thus avoiding the WTOR messages above)
  
  o   Update your group restart procedure to ensure that
      operators know how to respond to the DSNR020I and
      DSNR030I messages.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning and Admin.
  Pages: 113
  Change Description:
    The syntax for the MVS D XCF command is incorrect for
    the sample output shown. The correct syntax for
    displaying all structures that results in the output
    shown in figure 25 is
  
      D XCF,STR
  ============================================================
  Version 4 Book Title:  Data Sharing: Planning and Admin.
   Pages:  164
   Change Description:
    Under the first bullet for calculating global contention
    percentages, the calculated denominator is incorrect.
    Instead of 780232, the value should be 780732. This does
    not change the calculated percentage, which is rounded
    up anyway.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning and Admin.
  Pages: 169
  
  Change Description:
     Add a list of caveats in the topic "How to Keep Data from
     Being Shared"
  
    How to Keep Data from Being Shared
  
    It is possible, although not necessarily recommended,
    to restrict access to data to a single member.
    If you choose to do this, there are operational
    issues to consider:
  
    o   You cannot do workload balancing for that data,
        because the other DB2s in the group are not aware
        of that data.  Thus, it is possible for the
        member that has access to the data to become
        overloaded if access to that data increases over
        time.
  
    o   Availability is compromised, because if the member
        that owns the data goes down, no other member can
        access that data.
  
    o   You might have to set up special affinities to allow
        the application access to that data.
        Work cannot be automatically routed around the
        group to find the data.
  
    DEFINING PRIVATE DATA:  If you want access to table
    space named NOSHARE limited only to DB2C, you could
    assign NOSHARE to a previously unused buffer
    pool, such as BP25, using the ALTER TABLESPACE statement.
    Do not define a group buffer pool that corresponds to
    BP25, and assign BP25 a size of zero on any other
    DB2 in the group.  This prevents the other members of
    the group from attempting to use this buffer pool and
    therefore from accessing table space NOSHARE.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning and Admin.
  Pages: 179
  Change Description:
     Delete the section under the heading 'Effect of
     Data Sharing on Virtual Buffer Pool Data Set
     Thresholds'. These thresholds are treated the same for
     data sharing and non-data-sharing systems.
  ============================================================
  Version 4 Book Title:  Data Sharing: Planning and Admin.
  Pages:  191
  Change Description:
    The SETXCF START,ALTER command for changing the size of
    the group buffer pool is incorrect. It should be:
  
  SETXCF START,ALTER,STRNAME=DSNDB0G_GBPn,SIZE=newsize
  ============================================================
  This APAR is continued in II10881.
  

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