II05808: CHANGES TO SQL REFERENCE THAT DID NOT MAKE R230 GA PUBS

APAR status

• Closed as canceled.

Error description

• This info apar is for the doc changes that did not make the
  r230 sql reference. 5740xyr00
  ac26-4380-02 sc26438002
  ============================================================
  On page 237 in the SQL Reference under the CREATE TABLESPACE
  statement, the last sentence from the "using-block" text
  should be deleted.  The revised text is as follows:
  
      using-block
      -----------
        The components of the USING clause are discussed
        below, first for nonpartitioned table spaces and then
        for partitioned table spaces.  If you omit USING, the
        default storage group of the database must exist.
        **SENTENCE DELETED HERE.**
  
        USING clause for Nonpartitioned Table Spaces:
        ---------------------------------------------
  
  ============================================================
  ......
  On page 285 in the section on Autorization add the folowing
  bullet:
  The presence of SYSCTRL authority in the priviege set allows
  the granting of all authorities except:
  *  DBADM on databases
  *  DELETE,INSERT, SELECT, and UPDATE on user tables or views
  *  EXECUTE on plans or pakages
  *  SYSADM authority
  *  GRANT PACKADM
  .......
  ============================================================
     The following is additional information on PACKADM, a new
  administrative authority over collections:
  - A PACKADM for a collection has both the CREATE IN
    privilege for that collection PLUS all the package
    privileges for ANY package that is in the collection.
  - Both the PACKADM authority and the CREATE IN privilege may
    be granted over the set of all collections (represented by
    the wildcard "*").
  - The PACKADM authority is recorded in SYSIBM.SYSRESAUTH in
    the USEAUTH column.
  - The OBTYPE column will be set to 'C' and to distinguish
    the PACKADM authority from the CREATE IN privilege, the
    QUALIFIER column will contain the string 'PACKADM'.
  - Revoking a collection privilege on a specific collection
    follows the normal revoke and cascade revoke flows.  However,
    we do not cascade revoke from a REVOKE of a collection
    privilege on all collections ("*").  One result of this is
    that, eventhough the revokee may have totally lost his
    PACKADM authority (for example), there may still be grants
    in the catalog where the revokee has GRANTED the PACKADM
    authority.  That is because, in the case of all collections,
    we did not try to find grants made by the revokee (cascade
    revoke).
  - Thought a REVOKE PACKADM ON COLLECTION * will not cascade,
    any authorization dependencies that the REVOKEE has
    because of his PACKADM authority on all collections WILL
    be removed from the catalog.  For example, if CUSTOMER1
    wanted to bind a plan with a pklist, CUSTOMER1 would need
    the execute privilege on the packages in that pklist.  We
    record this type of information as an authorization
    dependency in the SYSPACKAUTH catalog table.  Now, if
    CUSTOMER1 had execute privilege on the package because of
    the PACKADM authority on all collections, that information
    goes into the authorization dependency record as an "A" in
    the AUTHHOWGOT column.  This record will be removed if
    CUSTOMER1 loses the PACKADM authority on all collections.
    Furthermore, the plan will be invalidated if the execute
    privilege on the package is not held from some other
    source.
  ============================================================
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• This is for doc changes that occured after the GA pubs
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels