Granting privileges for rebinding plans and packages

You can use the GRANT statement to grant privileges for rebuilding plans and packages.

About this task

Spiffy has a different set of tables, which contain actual data that is owned by the ROLE PRODCTN. PROGRAM1 is written with unqualified table names. For example, table T1 was referred to as simply T1, not DEVGROUP.T1. The new packages and plan must refer to table PRODCTN.T1. To move the completed program into production, someone must perform the following steps:

  • Rebind the application plan with the owner PRODCTN.
  • Rebind the packages into the collection BOWLS, again with the owner PRODCTN.

Spiffy gives that job to a production binder with the ID BINDER. BINDER needs privileges to bind a plan or package that DEVGROUP owns, to bind a plan or package with OWNER (PRODCTN), and to add a package to the collection BOWLS. BINDER acquires these abilities through its RACF® DEVGROUP group and ROLE PRODCTN. ROLE PRODCTN needs to have all the necessary privileges.

Suppose that ID BINDER has ROLE PRODCTN when binding in a trusted context and that ROLE PRODCTN has the following privileges:

Begin figure description. Sample binder ID and privileges. End figure description.

BINDER can bind plans and packages for owner ROLE PRODCTN because it performs binds in a trusted context with ROLE PRODCTN.

PACKADM, the package administrator for BOWLS, can grant the CREATE privilege with the following statement:

Begin general-use programming interface information.
GRANT CREATE ON COLLECTION BOWLS TO ROLE PRODCTN;
End general-use programming interface information.

With the plan in place, the database administrator at Spiffy wants to make the PROGRAM1 plan available to all employees by issuing the following statement:

Begin general-use programming interface information.
GRANT EXECUTE ON PLAN PROGRAM1 TO PUBLIC;
End general-use programming interface information.

More than one ID has the authority or privileges that are necessary to issue this statement. For example, ADMIN has SYSADM authority and can grant the EXECUTE privilege. Also, any ID in a trusted context with ROLE PRODCTN that owns PROGRAM1 can issue the statement. When EXECUTE is granted to PUBLIC, other IDs do not need any explicit authority on T1.

Finally, the plan to display bowling scores at Spiffy Computer Company is complete. The production plan, PROGRAM1, is created, and all IDs have the authority to execute the plan.