The Challenge
Currently, the Data-Sharing Planning and Administration Guide states that SETXCF commands are necessary for the administration of Db2 Group Bufferpools, particularly functions such as:
- Re-sizing group bufferpools
- Rebuilding group bufferpools to change aspects such as directory-to-data RATIO
- Moving group bufferpools from one CF to another
In most shops, System DBAs or Db2 SysAdmins are responsible for managing the group bufferpools, but z/OS Sysprogs are responsible for coupling facility operation. The SETXCF command is very sensitive and many SAF products do not allow command authority to be permitted JUST for specific structures…giving a DBA access to SETXCF START/STOP, for example, would allow them to modify ALL structures in a coupling facility, not just those related to Db2. z/OS Sysprogs often consider this a stability and security risk. Even if a DBA is “trusted”, the possibility of “finger-fumbles” and command mistakes exists.
This often means that simple changes to a group bufferpool, such as a RATIO change or a dynamic resize, requires coordination between components. Such coordination also often involves Change Management protocols, which can delay changes for days or weeks. While local bufferpools can be reconfigured with an –ALT BPOOL command in a matter of seconds, this knid of delay and procedural overhead with the equivalent group bufferpools makes change very slow for System DBAs.
The Proposed Solution
I am proposing the creation of a new command that will allow certain changes to be made to group bufferpools without System DBAs needing access to MVS.OPERCMDS, particularly SETXCF. The command could be called anything, but I am proposing –MODIFY GBPOOL
This command could be issued by the same individuals with authority to issue –ALT BPOOL or –ALT GBPOOL. When issued, the Db2 subsystem would issue the correct SETXCF commands on behalf of the Db2 operator. This does two things:
- It restricts access for the Db2 system DBA to those structures which Db2 owns.
- It prevents incorrect or malicious command syntax, insuring that the SETXCF command does exaxctly what Db2 intends it to do
- It eliminates the need to permit any SETXCF command authority to anyone outside of the authorized Db2 subsystem and the z/OS personnel.
Essentially, -MOD GBPOOL would provide the ability for Db2 system admins to fully operate Db2, while not compromising the security of the OS as a whole.
Examples of –MODIFY GBPOOL
-MODIFY GBPOOL(GBPnn) SIZE(nnnnM)
This command would tell Db2 to perform a SETXCF START,ALTER,STRNAME=name,SIZE=nnnnM to modify the size of a group bufferpool. The size of the structure would still be constrained between INITSIZE and SIZE in the CFRM, allowing the Db2 sysadmin flexibility to enlarge structures but still allowing z/OS sysprogs the ability to set limits on such an expansion. This command could be used in an emergency performance tuning situation to provide a larger structure.
-MODIFY GBP(GBPnn) STARTDUPLEX
This command would tell Db2 to perform a SETXCF START,REBUILD,DUPLEX to initiate group bufferpool duplexing. The CFRM structure PREFLIST would be honored.
-MODIFY GBP(GBPnn) STOPDUPLEX KEEP(PRIMARY/SECONDARY)
This command would tell Db2 to perform a SETXCF STOP,REBUILD,DUPLEX. KEEP(PRIMARY) would specify KEEP=OLD on the command (and be the default) and KEEP(SECONDARY) would specify KEEP=NEW on the command, instructing Db2 to fail GBP operations to the secondary copy of the GBP. As with STARTDUPLEX, the CFRM structure PREFLIST would be honored.
-MODIFY GBP(GBPnn) REBUILD
This command would tell Db2 to perform a SETXCF START,REBUILD on a structure. The purpose of this would be to rebuild a structure to bring in changes such as RATIO adjustments. The command would assume LOC=NORMAL. If the structure was in duplexing-mode, Db2 could either instruct the command-enterer to stop duplexing first, or it could to a STOP,REBUILD,DUPLEX, START,REBUILD, and START,REBUILD,DUPLEX.
-MODIFY GBP(GBPnn) RECOVER
This would be a special command whose main purpose is not to be a proxy for CFRM commands, but for recovery of FAILED-PERSISTENT connections. If Db2 comes down “hard”, we often see FAILED-PERSISTENT connections from members. In some cases, the objects are not updated again for some time after Db2 recycle or IPL, and the connections can persist for long periods of time. We have worked around this by creating “dummy” database objects using those bufferpools and forcing Db2 interest by updates on multiple members, but this process is tedious.
What MODIFY GBP RECOVER would do is tell Db2 to:
- Allocate a connection to the GBP structure
- Clean up the connection to this structure, externalize data, etc
- Disconnect from the GBP structure until it is needed again
Key Points
- z/OS Sysprogs ultimately retain control of the CF via the CFRM…max sizes, PREFLISTs, etc, are all honored, a Db2 sysadmin can only perform operations
- Gives Db2 sysadmins a “safe” API to dynamically manage CF operations exclusively for Db2
- Enforces separation of duties – z/OS group manages CF operations without having to involve themselves with Db2 operations, Db2 sysadmins/system DBAs administer Db2 operation without having to perform MVS/zOS operations.
