II09146: CHANGES TO DB2 DATA SHARING: PLANNING & ADMIN. SC26-3269-01 THAT DID NOT MAKE V4.1 GA PUBS. CONTINUED IN II09512.

APAR status

• Closed as canceled.

Error description

• 5740xyr00 DB2 R410 V4        Continued in II09512
  This APAR documents changes to the DB2 Data Sharing: Planning
  & Admin. SC26-3269-01 which did not make Version 4.1 GA pubs.
  ================================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages: 19
  Change Description:
    Because some application tuning might be necessary for
    *some* applications when moving to data sharing, change
    the sentence 'DB2 data sharing improves price for
    performance.....all without impacting your existing
    applications" to the following:
  
  DB2 data sharing improves price for performance, improves
  the availability of DB2, and provides more flexible ways
  to configure your environment.
  There is no need to change SQL in your applications to use
  data sharing, although some tuning might be needed for
  optimal performance.
  ===============================================================
  Version 4 Book Title: Data Sharing: Planning and Admin.
  Pages: 39, 58
  Change Description:
  p. 39: Add the following paragraph to 'Cross-System Coupling
         Facility (XCF) component of MVS'
  
  DB2 uses the XCF for certain inter-system communications.
  See "Setting up a Sysplex" for more information about
  configuring the XCF.
  
  p. 58: Under 'Estimating Storage for the EDM Pool', modify
      the first sentence of the second paragraph as follows:
  
  DB2 does not have a backing EDM pool in the coupling
  facility for invalidating objects in the EDM pool (DBDs,
  cursor tables, and so on) because these objects are
  modified less frequently than database data.  So, there is
  one EDM pool for each DB2 subsystem.  When a DBD changes,
  perhaps because an object has been changed,
  DB2 uses XCF messages to notify other DB2s
  using that DBD that new transactions should not use that
  copy of the DBD.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages: 56
  Change Description:
    DB2 always asks for 1024 castout classes for group buffer
    pools.  The MCC parameter should just say 1024 for all
    CFLEVELs.  Fix Table 5 accordingly.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages: 58
  Change Description:
  
  STORAGE FOR THE IRLM ADDRESS SPACE
  
  The requirements for IRLM storage are described in Section 2
  of Installation Guide. For data sharing, you should plan for
  additional storage because of additional data sharing locks
  called P-locks.These locks are help on open page sets and
  on objects in the EDM pool.
  
  To estimate the extra storage IRLM needs, use the following
  formula. This 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.If you know that your EDM pool has
  relatively few objects in it, you could use a lower
  percentage for that value.
  
      (MAX_OPEN_DATA_SETS * 500) = X
  
      X + (X * .20) = extra bytes of storage
  
  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 sybsystem
  parameter.
  
  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, the additional storage
  needed in addition to the original IRLM calculation is:
  
      (8000 * 500) = 3.81MB
  
      3.81MB + 800KB = 4.58MB of extra IRLM storage
  
      Total IRLM storage = 9.58MB
  
  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.  Also,
  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 & Administration
  Pages: 61, 72
  Change Description:
   On page 61, under "Naming" highlight the phrase
   'you cannot change them later'.
  On page 72, add the following text under 'Naming Conventions
  for the Originating Member':
   Attention:  You cannot change the group and member names
   after enabling data sharing.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages:  61, 77
  Change Description:
   Add information to help clarify whether or not you should
   consider merging existing DB2 subsystems.  Add the following
   to page 61, under the topic "Merging DB2 Subsystems":
  
  Is Merging the Right Thing to Do?
  
  Merging is a very complicated process. It involves not just
  the physical problem of moving data, it includes many other
  management issues, such as the following:
  
  o Naming conventions for users, plans, packages, databases
    tables, views, and so on
  o Authorization techniques
  o Backup and recovery conventions
  o Availability practices
  
  Before you consider merging existing DB2 subsystems into a
  single data sharing group, ask yourself the following
  question:  Why are the subsystems separate now?
  
  Reasons not to merge
  
  If the subsystems are separated now because of a different
  set of user groups that do not need frequent access to each
  other's data, do not now consider merging them.
  
  For the same reasons that you most likely do not include test
  and production DB2s in a single MVS, we do not recommend
  merging test and production subsystems into a single data
  sharing group.
  
  If you are trying to minimize the number of subsystems because
  you are running short of subsystem recognition characters,
  then using 8-character command prefixes offers relief.
  
  If you have two existing subsystems, availability is usually
  better by keeping the groups separate, and administration is
  simpler by keeping the groups split along the same lines as
  the users.
  
  What are reasons to consider merging?
  
  If the subsystems were split because of capacity constraints
  only, then merging might be a good idea, especially if the
  subsystems already share a common naming convention.
  
  If the subsystems have or need a lot of common data and are
  using shared read only data, distributed access, or data
  replication to handle the problem of sharing the data, merging
  might be a solution. However, this might not be a good approach
  if the security needs of the two groups are very different.
  If you try to merge two subsystems with very different security
  needs, especially if a shared naming convention is not already
  in place for those separate subsystems, then merging them
  could be very difficult.
  
  p. 77  The topic 'Merging Existing DB2 Data into the Group'
         must have a pointer back to the discussion page
         61.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages: 70
  Change Description:
   Add DB2 LOCATION NAME to the table of subsystem parameters
   that must be the same on all members of the data sharing
   group.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages: 76
  Change Description:
    Clarify that you should use the originating member's
    subsystem parameters as a basis for installing new members
    in the group. Change Step 1 under the 'Procedure to Add a
    New DB2 Data Sharing Member' to show the following fields
    on installation panel DSNTIPA1:
  
  INSTALL TYPE ===> INSTALL
  DATA SHARING FUNCTION ===> MEMBER
  .
  .
  INPUT MEMBER NAME===> originating member's output PDS member
  OUTPUT MEMBER NAME ===> new member's output PDS member
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages: 127
  Change Description:
  
  With a single-system data sharing group, there is no longer
  inter-DB2 R/W interest, and the requirements for the coupling
  facility are as follows:
    -A lock structure (which can be smaller)
    -An SCA
  
  No group buffer pools are needed unless you intend to
  do any multi-system data sharing work between the time you
  start up the members of the group and the time you stop all
  but one member of the group.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages:  p. 127
  Change Description:
    Delete the heading and text underneath for 'Installing a
    Data Sharing Group at the Remote Site.' Just as with
    non-data-sharing, it is not necessary to do an install.
    With the additional information needed for data sharing
    (policies, multiple logs and BSDSs and so forth), similar
    procedures apply as for non-data-sharing.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administrtion
  Pages: 139
  Change Description:
    Add the following bullet at the end of the current system
    programmer action:
  
  o If ALL members are down, and you cannot alter the SCA to a
    larger size,  you must do the following:
  
   1. Delete the SCA structure by using the following command:
  
        SETXCF FORCE,STRUCTURE,STRNAME=DSNB0G_SCA
  
   2.  Increase the size of the SCA in the CFRM policy.
  
   3.  Restart DB2 to rebuild the SCA using group restart.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages: 189
  Change Description:
    Add the following table note to table 35 for the third row
    (My DB2 is RW, the other one had no interest):
  
  Exception:
  If the other DB2 previously had R/O interest and then
  physically closed the page set, the page set remains
  GBP-dependent even though there is no inter-DB2 R/W interest
  on the page set or partition.  It remains GBP-dependent until
  the last updating DB2 switches the page set or partition to
  to read-only.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages: 169
  Change Description:
   Add the following to the section on 'Assigning Page Sets
   to Group Buffer Pools':
  
  Recommendation for Performance:
  
  For best performance, it is best to keep GBP-dependent page
  sets in separate buffer pools from non-GBP-dependent page sets.
  For example, it is a good idea to keep work file table spaces,
  which are always non-GBP-dependent, in different buffer pools
  than that used by GBP-dependent page sets.  This means you must
  assign work file table spaces to a buffer pool other than BP0.
  
  This separation helps DB2 more efficiently handle the
  registration and unregistration of pages to the group buffer
  pool.
  ============================================================
  Version 4 Book Title: Data Sharing: Planning & Administration
  Pages: 184, 222
  Change Description:
    The display for DISPLAY GROUPBUFFERPOOL using the GDETAIL
    option is not correct in the format of message DSNB785I.
    There should be two numbers for the line DIRECTORY ENTRY NOT
    CREATED. The second number should always be 0.  It is used
    for exception reporting, not performance monitoring. Here
    is a partial display from page 184:
  
               DIRECTORY ENTRY NOT CREATED (D)     = 332, 0
  
  The formula on page 184 is modified slightly to indicate
  that only the first of those two numbers is used in the
  calculation.
  (A / (A + B + C + D)) x 100  (first number for D)
  ============================================================
  continued in II09512
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• CLOSED 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