Required authorities for QMF administration

To avoid issuing multiple GRANT statements for specific database objects, you must use an authorization ID with DBADM or equivalent authority for most QMF administration and customization tasks. You need this level of authority on any database in which your users store data.

You need an authorization ID with DBADM or equivalent authority to the following databases on Db2® for z/OS® systems:

DSQDBCTL: The QMF control tables are stored in this database.
DSQDBDEF: When a user issues a SAVE DATA command, the resulting table is stored by default in this database, in table space DSQTSDEF.
Depending on your installation, users may be creating tables in implicitly created table spaces in the DSQDBDEF table.

If your users will be working with database and QMF objects in a Db2 for Linux®, UNIX, and Windows database, you will need DBADM authority on the DSQTSCTL and DSQTSOBJ database partition groups.

To administer QMF under a different ID from which you installed the product, grant DBADM authority to the new ID.

QMF Administrator Privilege

As an alternate to granting DBADM authority to administer QMF, users may be given QMF Administrator privilege. QMF Administrator privilege makes it easier for users to administer and maintain QMF. This is because users having this privilege can perform the following commands on QMF queries, forms, procedures and analytics that are owned by other users without requiring the owners to share these objects with all users:

SAVE
ERASE
IMPORT
EXPORT
DISPLAY

There are 2 ways to have QMF Administrator privilege.

The first is having either INSERT or DELETE authority on the Q.PROFILES control table. This may be through the user having DBADM or equivalent authority or explicit INSERT or DELETE authority on the Q.PROFILES control table.

If this default method of QMF Administrator privilege is chosen, during initialization, QMF checks the authorization ID of the user who is starting QMF to determine whether the ID has either INSERT or DELETE privilege on the Q.PROFILES control table. If the authorization ID has either of these privileges, QMF considers the user to have QMF Administrator privilege.

The DSQUOPTS exit routine runs during QMF initialization and provides a way for you to disable QMF administrator privilege checking by using the DSQEC_DISABLEADM global variable. However, if you disable this feature, you must explicitly set up administrator access to users' QMF objects. For example, you can request that users save their objects with the SHARE=YES parameter, or you can use the DSQEC_SHARE global variable to change the default value for the SHARE parameter to YES. You can also set a new default value for the DSQEC_SHARE global variable in the DSQUOPTS exit routine.
The second way to give users QMF Administrator privilege is to set the value of the users Q.PROFILES MODEL column to a value of A2. When this method is chosen, QMF will not check for INSERT or DELETE privilege on the Q.PROFILES control table during initialization. When a user's QMF profile MODEL column contains a value of A2, the user is automatically considered to have QMF Administrator privilege. Using the MODEL column of the Q.PROFILES table overrides the need for Q.PROFILES authority.

To check to see if a user has QMF Administrator privilege, the user can check the value of the DSQAO_QMFADM global variable. When this global variable is set to a value of '1', the user has QMF Administrator privilege.