A fix is available
APAR status
Closed as new function.
Error description
Set DB2 member ineligible for randomized group attach processing.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All DB2 Version 9 for z/OS users who use the * * group attach feature in a data sharing * * environment. * **************************************************************** * PROBLEM DESCRIPTION: Group attachment requests in DB2 * * Version 9 for z/OS do not work the same * * way as they did in DB2 Version 8 for * * z/OS. Members are selected at * * random. * * * * In addition, when there are * * three or more members of an attachment * * group, the randomizing algorithm * * doesn't distribute group * * attachment requests evenly. * **************************************************************** * RECOMMENDATION: * **************************************************************** DB2 Version 9 for z/OS introduces a new feature: randomization of group attachment requests. This is a change from DB2 Version 8 for z/OS, where group attachment requests are always attempted in the order of DB2 subsystem initialization. Some customers rely on this order to isolate batch processing from transaction processing. This PTF provides a method to restore the DB2 V8 group attachment behavior after migrating to DB2 V9, as well as providing additional flexibility. A related problem is that when there are three or more members of a data sharing group, the DB2 V9 randomization algorithm tends to primarily favor the first and last members of a group, instead of distributing the requests evenly.
Problem conclusion
Temporary fix
Comments
The randomization algorithm is improved to more evenly distribute group attachment requests. This PTF also adds a new DB2 subsystem parameter, RANDOMATT=YES/NO, which may be specified for each DB2 subsystem within the group. The default setting remains YES, which is assumed if no action is taken to update the DB2 subsystem parameters. RANDOMATT=NO may be specified to exclude that member from being selected at random. To satisfy a group attachment request, DB2 first randomly searches for an active DB2 subsystem, excluding those specifying RANDOMATT=NO. If all such subsystems are inactive, DB2 will search for *any* active DB2 subsystem within the group, in the order defined by the z/OS subsystem initialization, regardless of the setting of RANDOMATT. To achieve non-randomized group attachments for all members, as in DB2 Version 8, specify RANDOMATT=NO for all members of the group. The DSNWZP stored procedure is enhanced to display the current value of RANDOMATT in the DB2 subsystem parameter load module. You may take the following actions after applying this PTF and the companion PTF PK79327: See the ++HOLD actions for required post-apply actions. (1) Update your DB2 V9 subsystem parameter (DSNZPxxx) module for each DB2 subsystem. (This action is optional if you want to continue to use the default setting of RANDOMATT=YES.) Add the keyword parameter RANDOMATT=NO, to the invocation of the DSN6GRP macro in your customized version of the installation job DSNTIJUZ. Repeat this for each DB2 subsystem within the attachment group. Make sure to add a continuation character in column 72 if needed. If you omit adding RANDOMATT here, the value will be set to the default of YES when you assemble the DSNZPxxx module. (2) Run the first two steps of the DSNTIJUZ job you modified, to assemble and link the subsystem parameter load module. (3) After the job completes, for the change to take affect, you must either use the DB2 command -SET SYSPARM for each affected DB2 subsystem, or stop and start each affected DB2 subsystem. This action is not required if you are using the default setting of YES for RANDOMATT. Additional keywords: DB2DSHR
APAR Information
APAR number
PK79228
Reported component name
DB2 OS/390 & Z/
Reported component ID
5740XYR00
Reported release
910
Status
CLOSED UR1
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2009-01-22
Closed date
2009-03-03
Last modified date
2009-05-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PK79327 UK44898
Modules/Macros
DSNDGANT DSNDGRP DSNDQWPZ DSNTIDXA DSNTIJUZ DSNTINST DSNWZP DSN3AMI2 DSN3CHGZ DSN6GRP
Fix information
Fixed component name
DB2 OS/390 & Z/
Fixed component ID
5740XYR00
Applicable component levels
R910 PSY UK44898
UP09/04/03 P F904
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"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":"9.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
01 May 2009