ALTER PERMISSION statement

The ALTER PERMISSION statement alters a row permission that exists at the current server.

Invocation for ALTER PERMISSION

This statement can be embedded in an application program or issued interactively. It is an executable statement that can be dynamically prepared only if DYNAMICRULES RUN behavior is in effect. For more information, see Authorization IDs and dynamic SQL.

Authorization for ALTER PERMISSION

The privilege set that is defined below must include the following authority:

  • SECADM authority

Privilege set: If the statement is embedded in an application program, the privilege set is the privileges that are held by the owner of the package. If the statement is dynamically prepared, the privilege set is the union of the privilege sets that are held by each authorization ID and role of the process.

Syntax for ALTER PERMISSION

Read syntax diagramSkip visual syntax diagramALTER PERMISSIONpermission-name ENABLEDISABLEREGENERATEUSING APPLICATION COMPATIBILITYapplcompat-level

Description for ALTER PERMISSION

permission-name
Identifies the permission to be altered. The name must identify a row permission that exists at the current server. The name must not identify a default row permission that is created implicitly by Db2.
ENABLE
Specifies that the row permission is to be enabled for row access control. If row access control is not currently activated for the table, the row permission will become effective when row access control is activated for the table. Start of changeUse of this clause or keyword might invalidate packages that depend on the target object, or packages that depend on related objects through cascading effects. See Changes that invalidate packages.End of change

A row permission with a regeneration error cannot be enabled. To clear the status of the row permission, the row permission must be dropped and re-created with a modified definition.

ENABLE is ignored if the row permission is already defined as enabled for row access control.

DISABLE
Specifies that the row permission is to be disabled for row access control. If row access control is not currently activated for the table, the row permission will remain ineffective when row access control is activated for the table. Start of changeUse of this clause or keyword might invalidate packages that depend on the target object, or packages that depend on related objects through cascading effects. See Changes that invalidate packages.End of change

DISABLE is ignored if the row permission is already defined as disabled for row access control.

REGENERATE
Specifies that the row permission is to be regenerated. The row permission definition in the catalog is used, and any existing authorizations and dependencies are retained. The user-defined functions that are referenced in the row permission definition must be resolved to the same secure UDFs as that were resolved during the row permission creation.

Start of changeGenerally, the REGENERATE keyword is used only for specific situations, such as when implicit regeneration fails for routines or objects, or Db2 maintenance requires objects or routines to be regenerated. For more information, see When to regenerate Db2 database objects and routines.End of change

Start of changeUSING APPLICATION COMPATIBILITY applcompat-levelEnd of change
Start of changeFL 500Specifies that the object is regenerated under applcompat-level application compatibility rules. The ALTER statement fails if it includes any syntax, semantics, or options that require a higher application compatibility level.

If USING APPLICATION COMAPTIBILITY is omitted, the regeneration uses the APPLCOMPAT value of the applicable SYSIBM.SYSENVIRONMENT catalog table row.

The following applcompat-level values can be specified:
Start of changeVvvRrMmmmEnd of change
Start of change

Compatibility with the behavior of the identified Db2 function level. For example, V12R1M510 specifies compatibility with the highest available Db2 12 function level. The equivalent function level or higher must be activated.

Start of changeFor the new capabilities that become available in each application compatibility level, see: End of change

Tip: Start of changeExtra program preparation steps might be required to increase the application compatibility level for applications that use data server clients or drivers to access Db2 for z/OS®. For more information, see Setting application compatibility levels for data server clients and drivers.End of change
End of change
Start of changeV12R1End of change
Start of changeCompatibility with the behavior of Db2 12 function level 500. This value has the same result as specifying V12R1M500.End of change
V11R1
Compatibility with the behavior of Db2 11 new-function mode. After migration to Db2 12, this value has the same result as specifying V12R1M100. For more information, see V11R1 application compatibility level
V10R1
Compatibility with the behavior of DB2® 10 new-function mode. For more information, see V10R1 application compatibility level.
End of change

Notes for ALTER PERMISSION

Invalidation of packages:
This statement might invalidate all packages that depend on target objects, and sometimes other related objects through cascading effects, depending on the clauses and keywords specified and other factors. For more information, see Changes that invalidate packages.
Invalidation of cached dynamic SQL statements:
This statement might invalidate cached dynamic SQL statements that depend on target objects, and sometimes other related objects through cascading effects. For more information, see Invalidation of cached dynamic statements.
Applying Db2 maintenance:
When Db2 maintenance is applied that affects how a row permission is generated, the row permission might need to be regenerated to ensure the row permission is still valid. For more information, see When to regenerate Db2 database objects and routines.

If the row permission is regenerated successfully, the status of the row permission is set to a blank in the catalog table.

If the row permission cannot be regenerated successfully, an error is returned. The regeneration status of the row permission is set to an error. To clear the status of the row permission, the row permission must be dropped and re-created with a modified definition. Or the row permission can be disabled if not disabled yet. A disabled row permission becomes ineffective to a row access control enforced table.

When the table is referenced in a data manipulation statement, the statement returns an error if any enabled row permission has an regeneration error.

Examples for ALTER PERMISSION

Example 1
Enable permission P1.
ALTER PERMISSION P1 ENABLE;
Example 2
Regenerate permission P1.
ALTER PERMISSION P1 REGENERATE;