Syntax for Securing System Resources

This section explains the syntax, parameters, command codes, examples, and usage of the following Resources:
idms19
This section explains the syntax, parameters, command codes, examples, and usage of the following Resources:
2
2
ALTER RESOURCE
Modifies the definition of an activity or a category in the system dictionary.
Authorization
To modify a system, activity, or category definition, you must hold one of these privileges:
  • DCADMIN
  • SYSADMIN
Syntax
►►─── ALTER RESOURCE ─────────────────────────────────────────────────────────►  ►─┬─ ACTIVITY application-name.activity-name NUMBER activity-number ─┬───────►◄    │                          ┌─────────────────────────────────┐     │    └─ CATEGORY category-name ─▼─┬─ ADD ──┬─ category-component ─┴─────┘                                 └─ DROP ─┘
Expansion of Category-Component
                     ┌─────────────────────── , ────────────────────────┐ ►►─┬─ ACCESS MODULE ─▼─ dictionary-name.schema-name.access-module-name ─┴─┬───►◄    │               ┌─────────────────── , ────────────────────┐           │    ├─ LOAD MODULE ─▼─ dictionary-name.Vnnnn.load-module-name ─┴───────────┤    │           ┌───────────── , ──────────┐                               │    ├─ PROGRAM ─▼─ file-name.program-name ─┴───────────────────────────────┤    │         ┌────── , ─────┐                                             │    ├─ QUEUE ─▼─ queue-name ─┴─────────────────────────────────────────────┤    │            ┌───────────────────── , ─────────────────────┐           │    ├─ RUNUNIT ──▼─ database-name.subschema-name.program-name ─┴───────────┤    │        ┌───── , ─────┐                                               │    └─ TASK ─▼─ task-code ─┴───────────────────────────────────────────────┘
Parameters
  • ACTIVITY
    Specifies that you are modifying the security definition of an activity.
  • application-name
    Identifies the application that includes the activity to be altered.
  • activity-name
    Identifies the application activity to be altered.
    The activity must have been previously defined with a CREATE RESOURCE statement.
  • NUMBER activity-number
    Specifies the security classification number to be assigned to the activity.
    Activity-number must be in the range 1 to 256 and must be unique for the application.
  • CATEGORY category-name
    Specifies that you are modifying the definition of a category.
    Category-name must have been previously defined with a CREATE RESOURCE statement.
  • ADD
    Specifies that you are adding a component to the category.
  • DROP
    Specifies that you are dropping a component from the category.
  • category-component
    Identifies the component to be added to or dropped from the category.
    Expanded syntax for
    category-component
    directly follows syntax for ALTER RESOURCE.
    A component that has been assigned to a category cannot be assigned to a second category.
    You can wildcard the name of the category component.
    Note:
    For more information on wildcarding, see Using a Wildcard.
  • ACCESS MODULE
    Specifies that the category component is an access module.
    If you drop an access module from a category, users with execution privilege on the category may no longer be able to execute the access module.
  • dictionary-name
    Identifies the dictionary where the access module is stored (DDLCATLOD area).
  • schema-name
    Identifies the schema with which the access module is associated.
  • access-module-name
    Identifies the access module.
  • LOAD MODULE
    Specifies that the category component is a load module.
    If you drop a load module from a category, users with execution privilege on the category may no longer be able to execute the load module.
  • dictionary-name
    Identifies the dictionary where the load module is stored (DDLDCLOD area).
  • Vnnnn
    Specifies the version of the load module.
    Nnnn identifies the version number of the load module. Leading zeros must be included.
  • load-module-name
    Identifies the load module.
    Load-module-name must match the name of an entity defined in the dictionary by means of a CA IDMS or CA ADS compiler.
  • PROGRAM
    Specifies that the category component is a program.
    If you drop a program from a category, users with execution privilege on the category may no longer be able to execute the program.
  • file-name
    Supplies the external file name of the load library where the program is stored.
    File-name is either 'CDMSLIB' or 'Vnnnn' where nnnn identifies the version number (2 - 9999) of the program. Nnnn must include leading zeroes.
  • program-name
    Identifies the program.
  • QUEUE
    Specifies that the category component is a queue.
    If you drop a queue from a category, users with execution privilege on the category may no longer be able to create or access the queue.
  • queue-name
    Identifies the queue.
  • RUNUNIT
    Specifies that the category component is a run unit.
    If you drop a run unit from a category, users with execution privilege on the category may no longer be able to execute the run unit.
  • database-name
    Specifies the database to be accessed by the run unit.
  • subschema-name
    Specifies the subschema to be used by the run unit.
  • program-name
    Specifies the name of the program binding the run unit.
  • TASK
    Specifies that the category component is a task.
    If you drop a task from a category, users with execution privilege on the category may no longer be able to execute the task.
  • task-code
    Identifies the task.
Usage
Execution Privilege on Individual Access Modules
You can give access module execution privilege by issuing a GRANT EXECUTE ON ACCESS MODULE statement. However, if you subsequently add the same access module to a category, the separate grant of access module execution is ignored at runtime.
If you then drop the access module from the category, and you have not revoked the separate grant of access module execution privilege, the privilege will again be respected at runtime.
Matching Wildcarded Category Component Names
If you use a wildcard when you specify a category component name, the category to which the resource is assigned is the one that most closely matches the resource name.
A match is determined by these rules:
  • The resource name must match the category component name character for character up to the wildcard in order to be assigned to the category.
  • If the resource name matches more than one category component name up to the wildcard, the resource is assigned to the category in which the most number of characters match.
For example, assume you add these two category component definitions:
alter resource category hr_prod   add load module hrdict.v0001*; alter resource category hr_test   add load module hrdict.*;
A load module named HRDICT.V0001.HRMAP1 will be assigned to category HR_PROD, whereas load module HRDICT.V0002.HRMAP1 will be assigned to category HR_TEST.
Altering Categories After a Grant
If a component is added to a category with ALTER RESOURCE after a grant of privilege on the category, the privilege is implicitly granted on the added component. Similarly, if a component is dropped from a category with ALTER RESOURCE after a grant of privilege on the category, the privilege on the dropped component is implicitly revoked.
Examples
Altering an Activity
: The following statement assigns a new number to an
existing activity created for a General Ledger application:
alter resource activity cgl.post number 5;
Altering a Category
: The following statement replaces a resource in an
existing category created for a General Ledger application:
alter resource category glappl drop queue fl* add queue gl*;
More information
For more information on creating and dropping resources, see the topics CREATE RESOURCE and DROP RESOURCE.
CREATE RESOURCE
Creates the definition of a system, activity, or category in the system dictionary.
Authorization
To create a system, activity, or category definition, you must hold one of these privileges:
  • DCADMIN
  • SYSADMIN
Syntax
►►─── CREATE RESOURCE ────────────────────────────────────────────────────────►  ►─┬─ ACTIVITY application-name.activity-name NUMBER activity-number ─┬───────►◄    │                          ┌──────────────────────────┐            │    ├─ CATEGORY category-name ─▼─ ADD category-component ─┴────────────┤    │                                                                  │    └─ SYSTEM system-identifier ───────────────────────────────────────┘
Expansion of Category-Component
                     ┌─────────────────────── , ────────────────────────┐ ►►─┬─ ACCESS MODULE ─▼─ dictionary-name.schema-name.access-module-name ─┴─┬───►◄    │               ┌─────────────────── , ────────────────────┐           │    ├─ LOAD MODULE ─▼─ dictionary-name.Vnnnn.load-module-name ─┴───────────┤    │           ┌───────────── , ──────────┐                               │    ├─ PROGRAM ─▼─ file-name.program-name ─┴───────────────────────────────┤    │         ┌────── , ─────┐                                             │    ├─ QUEUE ─▼─ queue-name ─┴─────────────────────────────────────────────┤    │            ┌───────────────────── , ─────────────────────┐           │    ├─ RUNUNIT ──▼─ database-name.subschema-name.program-name ─┴───────────┤    │        ┌───── , ─────┐                                               │    └─ TASK ─▼─ task-code ─┴───────────────────────────────────────────────┘
Parameters
  • ACTIVITY
    Specifies that you are defining an activity as a secured resource.
    An activity is a discrete application function. After you have defined an activity, you grant execution privilege on the activity to users.
    Note:
    For more information on activities, see Securing System Resources.
  • application-name
    Identifies the application that includes the activity to be secured.
    Application-name must match the name of the application (passed in #SECHECK) whose function is being secured. It can be at most eight characters in length.
  • activity-name
    Names the application function to be secured.
    Activity-name must be unique within the application. It can be at most 18 characters in length.
  • NUMBER activity-number
    Specifies the activity number assigned to the application function.
    Activity-number must be unique within the application. It must be in the range 1 to 256, and it must match the security class assigned within the application.
    For more information on assigning activity numbers within applications, see Securing System Resources.
  • CATEGORY category-name
    Specifies that you are defining category category-name as a secured resource.
    A category can contain tasks, load modules, programs, access modules, run units, and queues. After you have defined a category, you grant execution privilege on the category to users.
    Category-name can be at most 32 characters in length.
    You can define a maximum of 32,767 categories for a DC system.
    Note:
    For more information on categories, see Securing System Resources.
  • ADD category-component
    Identifies a component to be added to the category.
    Expanded syntax for category-component directly follows syntax for CREATE RESOURCE.
    A component that has been assigned to a category cannot be assigned to a second category.
    You can wildcard the name of the category component.
    Note:
    For more information on wildcarding, see Using a Wildcard.
  • SYSTEM system-identifier
    Specifies that system system-identifier is a secured resource. When the system is secured, users must hold definition privileges to define the system and signon privilege to sign on to the system.
    When the system is defined, SYSTEM ID in the SYSTEM statement of system generation must match the value of system-identifier.
  • ACCESS MODULE
    Specifies that the category component is an access module.
    After you add an access module to a category, a user with execution privilege on the category can load the access module but cannot execute it.
  • dictionary-name
    Identifies the dictionary where the access module is stored (DDLCATLOD area).
  • schema-name
    Identifies the schema with which the access module is associated.
  • access-module-name
    Identifies an access module.
  • LOAD MODULE
    Specifies that the category component is a load module.
    After you add a load module to a category, a user with execution privilege on the category can execute the load module.
  • dictionary-name
    Identifies the dictionary where the load module is stored (DDLDCLOD area).
  • Vnnnn
    Specifies the version of the load module.
    Nnnn identifies the version number of the load module. Leading zeros must be included.
  • load-module-name
    Identifies a load module.
  • PROGRAM
    Specifies that the category component is a program.
    After you add a program to a category, a user with execution privilege on the category can execute the program.
  • file-name
    Supplies the name of the external file of the load library where the program is stored.
    File-name is either 'CDMSLIB' or 'Vnnnn' where nnnn identifies the version number (2 - 9999) of the program. Nnnn must include leading zeroes.
  • program-name
    Identifies a program.
  • QUEUE
    Specifies that the category component is a queue.
    After you add a queue to a category, a user with execution privilege on the category can create or access the queue.
  • queue-name
    Identifies a queue.
  • RUNUNIT
    Specifies that the category component is a run unit.
    After you add a run unit to a category, a user with execution privilege on the category can use program-name to access data described in subschema-name of database-name.
  • database-name
    Identifies the database to be accessed by the run unit.
  • subschema-name
    Identifies the subschema to be used by the run unit.
  • program-name
    Identifies the program binding the run unit.
  • TASK
    Specifies that the category component is a task.
    After you add a task to a category, a user with execution privilege on the category can execute the task.
  • task-code
    Identifies the task.
Usage
Adding Categories or Applications After a Grant
A category created after you grant privileges on the category with a wildcard is not included in the scope of the grant even if the resource name matches the wildcarded name. The wildcard is processed at the time the grant is made, not at runtime.
For example, if you create categories X1, X2, and X3, and then grant privileges on category X*, the three categories are within the scope of the grant. If you then create category X4, this category is not within the scope of the grant.
You can include X4 within the scope of the grant by reissuing the original grant on category X*.
The same considerations apply if you wildcard activity-name when granting execution privilege on an activity. The wildcard is processed at the time the grant is made, not at runtime.
Altering Categories After a Grant
If a component is added to a category (ALTER RESOURCE) after a grant of privilege on the category, the privilege is implicitly granted on the added component. Similarly, if a component is dropped from a category (ALTER RESOURCE) after a grant of privilege on the category, the privilege on the dropped component is implicitly revoked.
Matching Wildcarded Category Component Names
If you use a wildcard when you specify a category component name, the category to which the resource is assigned is the one that most closely matches the resource name.
A match is determined by these rules:
  • The resource name must match the category component name character for character up to the wildcard in order to be assigned to the category.
  • If the resource name matches more than one category component name up to the wildcard, the resource is assigned to the category in which the most number of characters match.
For example, assume you add these two category component definitions:
create resource category hr_prod   add load module hrdict.v0001*; create resource category hr_test   add load module hrdict.*;
A load module named HRDICT.V0001.HRMAP1 will be assigned to category HR_PROD, whereas load module HRDICT.V0002.HRMAP1 will be assigned to category HR_TEST.
Examples
The following statement creates a category called PROD_ACCESS that includes resources required for a user to perform production processing:
create resource   category prod_access     add access module proddict.prod*     add load module proddict.v0001.*     add program cdmslib.*     add rununit p*;
Creating an Activity
The following statement assigns an activity name and number to a General Ledger application:
create resource   activity cgl.post   number 4;
Creating a Category
The following statement creates a category of resources used by a General Ledger application:
create resource   category glappl     add load module appldict.v0001.gl*     add task gl*     add queue gl*     add program cdmslib.gl*;
More information
For more information on altering and dropping resources, see “ALTER RESOURCE” and “DROP RESOURCE.”
DROP RESOURCE
Deletes the definition of a secured resource.
Authorization
To delete the definition of a system, activity, or category as a secured resource, you must hold one of these privileges:
  • DCADMIN
  • SYSADMIN
Syntax
►►─── DROP RESOURCE ─┬─ ACTIVITY application-name.activity-name ─┬────────────►◄                      ├─ CATEGORY category-name ──────────────────┤                      └─ SYSTEM system-identifier ────────────────┘
Parameters
  • ACTIVITY
    Specifies that the resource to be dropped is an activity.
  • application-name.activity-name
    Identifies the activity.
  • CATEGORY
    Specifies that the resource to be dropped is a category.
  • category-name
    Identifies the category.
  • SYSTEM
    Specifies that the resource to be dropped is a system.
  • system-identifier
    Identifies the system.
Usage
Automatic Revoking of Privileges
When you drop a resource, you implicitly revoke all privileges granted on the resource.
Examples
Dropping an Activity
The following statement drops an existing activity created for a General Ledger application:
drop resource activity cgl.post;
Dropping a Category
The following statement drops an existing category created for a General Ledger application:
drop resource category glappl;
More information
For more information on creating and altering resources, see CREATE RESOURCE and ALTER RESOURCE.
GRANT Administration Privilege
Gives one or more users or groups DCADMIN privilege.
Authorization
To grant DCADMIN privilege, you must hold one of these privileges:
  • DCADMIN
  • SYSADMIN
Syntax
►►─── GRANT DCADMIN ──────────────────────────────────────────────────────────►           ┌─────────────── , ──────────────┐  ►─── TO ─▼─┬─ PUBLIC ───────────────────┬─┴──────────────────────────────────►◄             └─ authorization-identifier ─┘
Parameters
  • DCADMIN
    Specifies that you are giving DCADMIN privilege to the users or groups identified in the TO parameter.
    DCADMIN controls access to DC system resources. A user with DCADMIN privilege can define system resources and can grant and revoke privileges on system resources.
    Note:
    For more information on the DCADMIN privilege, see Securing System Resources.
  • TO
    Specifies the users or groups to whom you are giving DCADMIN privilege.
  • PUBLIC
    Specifies all users.
    If you grant DCADMIN to group PUBLIC, any user can administer security for the system.
  • authorization-identifier
    Identifies a user or group.
    Note:
    Expanded syntax for authorization-identifier is presented in Notes on Security Statement Syntax.
Usage
Decentralizing Administration
You can decentralize security administration for the system by granting DCADMIN and system definition privileges to other users.
A holder of SYSADMIN or DCADMIN can also specify WITH GRANT OPTION when granting system definition privileges to allow the recipient to grant the same privileges to others.
Examples
Granting DCADMIN to Administrators:
The following statement grants DCADMIN privilege to the security administrator ID and the DCA group ID:
grant dcadmin   to secadmin, dca_group;
More information
For more information on revoking DCADMIN privilege, see REVOKE Administration Privilege.
GRANT Execution Privilege
Gives one or more users or groups access to activities or categories.
Authorization
To grant an execution privilege, you must hold one of these privileges:
  • DCADMIN
  • SYSADMIN
Syntax
►►─── GRANT EXECUTE ──────────────────────────────────────────────────────────►                        ┌─────────────── , ────────────────┐  ►─── ON ─┬─ ACTIVITY ─▼─ application-name.activity-name ─┴─────────┬─────────►           │            ┌─────── , ───────┐                          │           └─ CATEGORY ─▼─ category-name ─┴──────────────────────────┘           ┌─────────────── , ──────────────┐  ►─── TO ─▼─┬─ PUBLIC ───────────────────┬─┴──────────────────────────────────►◄             └─ authorization-identifier ─┘
Parameters
  • EXECUTE
    Specifies that you are giving execution privilege to the users or groups identified in the TO parameter.
  • ON
    Specifies the resources to which execution privilege applies.
  • ACTIVITY
    Specifies that you are giving execution privilege on one or more activities.
  • application-name.activity-name
    Identifies an activity.
    Application-name.activity-name must have been previously defined as an activity with a CREATE RESOURCE statement.
    You can wildcard activity-name. You cannot wildcard application-name. The wildcard character can appear in activity-name at any point after the period following application-name.
    Note:
    For more information on wildcarding, see Using a Wildcard.
  • CATEGORY
    Specifies that you are giving execution privilege on one or more categories.
  • category-name
    Identifies a category.
    Category-name must have been previously defined as a category with a CREATE RESOURCE statement.
    You can wildcard category-name.
    Note:
    For more information on wildcarding, see Using a Wildcard.
  • TO
    Specifies the users or groups to whom you are giving execution privilege.
  • PUBLIC
    Specifies all users.
  • authorization-identifier
    Identifies a user or group.
    Note:
    Expanded syntax for authorization-identifier is presented in the section “Notes on Security Statement Syntax.”
Usage
Wildcarding Activity-Name
If you wildcard activity-name in a GRANT EXECUTE statement, you grant execution privilege on all activities whose names match the wildcarded name.
For example, this statement gives execution privilege on all DCMT activities whose names begin with 'VARY' to DCA_GROUP:
grant execute   on activity dcmt.vary*   to dca_group;
Adding Categories or Activities After a Grant
A category created after you grant privileges on the category with a wildcard is not included in the scope of the grant even if the resource name matches the wildcarded name. The wildcard is processed at the time the grant is made, not at runtime.
For example, if you create categories X1, X2, and X3, and then grant privileges on category X*, the three categories are within the scope of the grant. If you then create category X4, this category is not within the scope of the grant.
You can include X4 within the scope of the grant by revoking the original grant on category X* and then reissuing it.
The same considerations apply if you wildcard activity-name when granting execution privilege on an activity. The wildcard is processed at the time the grant is made, not at runtime.
Examples
Granting Execution Privilege on an Activity
The following statement grants execution privilege on a General Ledger activity to a development group:
grant execute   on activity cgl.post   to appldev1;
Granting Execution Privilege on a Category
The following statement grants execution privilege on the General Ledger category to all users:
grant execute   on category glappl   to public;
Granting Execution Privilege to PUBLIC
If execution privilege on a category has been granted to group PUBLIC, a user who has not signed on has the ability to invoke tasks and access other secured resources in the category.
GRANT Signon Privilege
Gives one or more users access to a CA IDMS system.
Authorization
To issue the GRANT SIGNON statement, you must hold one of these privileges:
  • DCADMIN
  • SYSADMIN
Syntax
►►─── GRANT SIGNON ON SYSTEM system-identifier ──────────────────────────────►  ►─┬──────────────────────────────┬──────────────────────────────────────────►    └─ PROFILE ─┬─ profile-name ─┬─┘                └─ NULL ─────────┘          ┌─────────── , ─────────┐  ►─── TO ▼─── user-identifier ───┴───────────────────────────────────────────►◄
Parameters
  • SIGNON
    Specifies that you are giving signon privilege to the users identified in the TO parameter.
  • ON SYSTEM system-identifier
    Identifies the system to which signon privilege applies.
    System-identifier must have been defined as a resource with the CREATE RESOURCE SYSTEM statement.
    Note:
    You cannot wildcard system-identifier.
  • PROFILE profile-name
    Identifies the system profile to be used in signon processing.
  • NULL
    Specifies that no system profile should be used in signon processing.
  • TO user-identifier
    Identifies a user to whom you are giving signon privilege.
Usage
Changing the User's System Profile
To change the system profile associated with a user identifier:
  • Revoke signon privilege from the user identifier.
  • Grant signon privilege to the user identifier specifying the new profile.
Examples
Granting Signon with a Profile Specification
The following statement grants signon privilege and specifies the system profile to be invoked in signon processing:
grant signon   on system syst0099   profile pub99   to sam;
Changing the User's System Profile
The following statements change user SAM's system profile to CORP99:
revoke signon on system syst0099   from sam; grant signon on system syst0099   profile corp99   to sam;
More information
  • For more information on signon processing, see Signon Processing (CA IDMS).
  • For more information on revoking signon privilege, see REVOKE Signon Privilege.
  • For more information on system profiles, see the
    CA IDMS System Tasks and Operator Reference section
    .
GRANT System Definition Privileges
Gives to one or more users or groups the privilege to define a system or a system profile in the system dictionary.
Authorization
To grant system definition privileges, you must hold one of these privileges:
  • DCADMIN privilege
  • The corresponding grantable privilege on the system or system profile
  • SYSADMIN
Syntax
►►─── GRANT ─┬─ DEFINE ──────────┬────────────────────────────────────────────►              │ ┌────── , ──────┐ │              └─▼─┬─ ALTER ───┬─┴─┘                  ├─ CREATE ──┤                  ├─ DISPLAY ─┤                  └─ DROP ────┘  ►─── ON ─┬─ SYSTEM system-identifier ────┬───────────────────────────────────►           └─ SYSTEM PROFILE profile-name ─┘           ┌─────────────── , ──────────────┐  ►─── TO ─▼─┬─ PUBLIC ───────────────────┬─┴──────────────────────────────────►             └─ authorization-identifier ─┘  ►─┬─────────────────────┬────────────────────────────────────────────────────►◄    └─ WITH GRANT OPTION ─┘
Parameters
  • DEFINE
    Gives the ALTER, CREATE, DISPLAY, and DROP privileges on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
    The DEFINE privilege on a system allows the user to use the CA IDMS system generation compiler to add, modify, or delete the system. The DEFINE privilege also allows the user to display or punch the definition of the system.
    The DEFINE privilege on a system profile allows the user to create, alter, or drop a system profile, or to display security definitions for the system profile.
  • ALTER
    Gives the ALTER privilege on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
    The ALTER privilege on a system allows a user to use the system generation compiler to modify the definition of the system.
    The ALTER privilege on a system profile allows a user to alter the system profile.
  • CREATE
    Gives the CREATE privilege on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
    The CREATE privilege on a system allows a user to use the system generation compiler to add the system.
    The CREATE privilege on a system profile allows a user to create the system profile.
  • DISPLAY
    Gives the DISPLAY privilege on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
    The DISPLAY privilege allows the user to issue a DISPLAY RESOURCE statement on the named system or system profile. The grantable DISPLAY privilege allows a user to issue a DISPLAY PRIVILEGES statement on the named system or system profile.
    The DISPLAY privilege on a system also allows a user to use the system generation compiler to display or punch the system definition.
  • DROP
    Gives the DROP privilege on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
    The DROP privilege on a system allows a user to use the system generation compiler to delete the definition of the system.
    The DROP privilege on a system profile allows a user to drop the system profile.
  • ON
    Specifies the resource to which the definition privileges apply.
  • SYSTEM system-identifier
    Identifies a system.
    You can wildcard system-identifier.
    Note:
    For more information on wildcarding, see Using a Wildcard.
    If you do not wildcard system-identifier, the value you specify must match the identifier of a system secured with the CREATE RESOURCE SYSTEM statement.
  • SYSTEM PROFILE profile-name
    Identifies a system profile.
    Note:
    For more information on creating system profiles, see the
    CA IDMS System Tasks and Operator Reference section
    .
    You can wildcard system-profile.
    Note:
    For more information on wildcarding, see Using a Wildcard.
  • TO
    Specifies the users or groups to whom you are giving the definition privileges.
  • PUBLIC
    Specifies all users.
  • authorization-identifier
    Identifies a user or group.
    Note:
    Expanded syntax for authorization-identifier is presented in the section Notes on Security Statement Syntax.
  • WITH GRANT OPTION
    Gives the privilege of granting the specified definition privileges to the users or groups identified in the TO parameter.
    A privilege granted with the WITH GRANT OPTION is called a grantable privilege.
Usage
The DEFINE Keyword
When you use the DEFINE keyword with a GRANT statement, you grant a set of definition privileges on a resource to one or more users or groups.
When you use the DEFINE keyword with a REVOKE statement, you revoke all definition privileges that have been previously granted on the resource from the specified users or groups.
This means that if you GRANT CREATE privilege on a resource, you can revoke the privilege with either a REVOKE CREATE statement or a REVOKE DEFINE statement. Using REVOKE DEFINE is an efficient technique when you intend to revoke all definition privileges on the resource from a user or group, whether the privileges were granted singly or as a set.
Similarly, you can GRANT DEFINE on a resource to a user and then REVOKE DROP on the resource from the same user as a way to grant all but one definition privilege.
Examples
Granting Privilege to Define the System
The following statement grants the privilege to define a system to the system DCA:
grant define   on system syst0099   to dca0099;
More information
  • For more information on system profiles, see the
    CA IDMS System Tasks and Operator Reference section
    .
  • For more information on revoking system definition privileges, see REVOKE System Definition Privileges.
REVOKE Administration Privilege
Revokes DCADMIN privilege from one or more users or groups.
Authorization
To revoke DCADMIN privilege, you must hold one of these privileges:
  • DCADMIN
  • SYSADMIN
Syntax
►►─── REVOKE DCADMIN ─────────────────────────────────────────────────────────►             ┌─────────────── , ──────────────┐  ►─── FROM ─▼─┬─ PUBLIC ───────────────────┬─┴────────────────────────────────►◄               └─ authorization-identifier ─┘
Parameters
  • DCADMIN
    Specifies that you are revoking DCADMIN privilege from the users or groups named in the FROM parameter.
  • FROM
    Specifies the users or groups from whom you are revoking DCADMIN privilege.
  • PUBLIC
    Specifies all users.
  • authorization-identifier
    Identifies a user or group.
    The privilege must have been previously given to authorization-identifier by means of the GRANT statement.
    Note:
    Expanded syntax for authorization-identifier is presented in section “Notes on Security Statement Syntax."
Example
Revoking DCADMIN from Administrators
The following statement revokes DCADMIN privilege from the DCA group ID:
revoke dcadmin   from dca_group;
More information
For more information on granting DCADMIN privilege, see GRANT Administration Privilege.
REVOKE Execution Privilege
Revokes from one or more users or groups the privilege to access an activity or category.
Authorization
To revoke execution privilege, you must hold one of these privileges:
  • DCADMIN
  • SYSADMIN
Syntax
►►─── REVOKE EXECUTE ─────────────────────────────────────────────────────────►                        ┌──────────────── , ───────────────┐  ►─── ON ─┬─ ACTIVITY ─▼─ application-name.activity-name ─┴──────────┬────────►           │            ┌─────── , ───────┐                           │           └─ CATEGORY ─▼─ category-name ─┴───────────────────────────┘             ┌─────────────── , ──────────────┐  ►─── FROM ─▼─┬─ PUBLIC ───────────────────┬─┴────────────────────────────────►◄               └─ authorization-identifier ─┘
Parameters
EXECUTE
Specifies that you are revoking execution privilege from the users or groups identified in the FROM parameter.
  • ON
    Specifies the resource to which execution privilege applies.
  • ACTIVITY
    Specifies that you are revoking execution privilege on one or more activities.
  • application-name.activity-name
    Identifies an activity.
    You can wildcard activity-name. You cannot wildcard application-name. The wildcard character can appear in activity-name at any point following the period after application-name.
    Note:
    For more information on wildcarding, see Using a Wildcard.
  • CATEGORY
    Specifies that you are revoking execution privilege on one or more categories.
  • category-name
    Identifies a category.
  • FROM
    Specifies the users or groups from whom you are revoking execution privilege.
  • PUBLIC
    Specifies all users.
  • authorization-identifier
    Identifies a user or group.
    The privilege must have been previously given to authorization-identifier by means of the GRANT statement.
    Note:
    Expanded syntax for authorization-identifier is presented in the section Notes on Security Statement Syntax.
Examples
Revoking Execution Privilege on an Activity
The following statement revokes execution privilege on a General Ledger activity from a development group:
revoke execute   on activity cgl.post   from appldev1;
Revoking Execution Privilege on a Category
The following statement revokes execution privilege on the General Ledger category from PUBLIC:
revoke execute   on category glappl   from public;
More information
For more information on granting execution privilege, see GRANT Execution Privilege.
REVOKE Signon Privilege
Revokes the privilege to access a system from one or more users.
Authorization
To revoke signon privilege, you must hold one of these privileges:
  • DCADMIN
  • SYSADMIN
Syntax
►►─── REVOKE SIGNON ON SYSTEM system-identifier ──────────────────────────────►             ┌────────── , ──────────┐  ►─── FROM ─▼─── user-identifier ───┴─────────────────────────────────────────►◄
Parameters
  • SIGNON
    Specifies that you are revoking signon privilege to the system identified in the ON parameter from the users identified in the FROM parameter.
  • ON SYSTEM system-identifier
    Identifies the system to which the signon privilege applies.
  • FROM user-identifier
    Identifies a user from whom you are revoking signon privilege.
    The privilege must have been previously given to user-identifier by means of the GRANT statement.
Example
Revoking Signon
The following statement revokes signon privilege on a specified system from a user:
revoke signon   on system syst0099   from sam;
More information
For more information on granting signon privilege, see GRANT Signon Privilege.
REVOKE System Definition Privileges
Revokes from one or more users or groups the privilege to define a system or a system profile in the system dictionary.
Authorization
To revoke system privileges, you must hold one of these privileges:
  • DCADMIN privilege
  • The corresponding grantable privilege on the system or system profile
  • SYSADMIN
Syntax
►►─── REVOKE ─┬─ DEFINE ──────────┬───────────────────────────────────────────►               │ ┌────── , ──────┐ │               └─▼─┬─ ALTER ───┬─┴─┘                   ├─ CREATE ──┤                   ├─ DISPLAY ─┤                   └─ DROP ────┘  ►─── ON ─┬─ SYSTEM system-identifier ────┬───────────────────────────────────►           └─ SYSTEM PROFILE profile-name ─┘             ┌─────────────── , ──────────────┐  ►─── FROM ─▼─┬─ PUBLIC ───────────────────┬─┴────────────────────────────────►◄               └─ 
authorization-identifier
 ─┘
Parameters
  • DEFINE
    Revokes the ALTER, CREATE, DISPLAY, and DROP privileges on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
  • ALTER
    Revokes the ALTER privilege on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
  • CREATE
    Revokes the CREATE privilege on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
  • DISPLAY
    Revokes the DISPLAY privilege on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
  • DROP
    Revokes the DROP privilege on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
  • ON
    Specifies the resource to which the definition privileges apply.
  • SYSTEM system-identifier
    Identifies a system.
  • SYSTEM PROFILE profile-name
    Identifies a system profile.
  • FROM
    Specifies the users or groups from whom you are revoking the specified definition privileges.
  • PUBLIC
    Specifies all users.
  • authorization-identifier
    Identifies a user or group.
    The privileges must have been previously given to authorization-identifier by means of the GRANT statement.
    Note:
    Expanded syntax for authorization-identifier is presented in the section “Notes on Security Statement Syntax."
Usage
The DEFINE Keyword
When you use the DEFINE keyword with a GRANT statement, you grant a set of definition privileges on a resource to one or more users or groups.
When you use the DEFINE keyword with a REVOKE statement, you revoke all definition privileges that have been previously granted on the resource from the specified users or groups.
This means that if you GRANT CREATE privilege on a resource, you can revoke the privilege with either a REVOKE CREATE statement or a REVOKE DEFINE statement. Using REVOKE DEFINE is an efficient technique when you intend to revoke all definition privileges on the resource from a user or group, whether the privileges were granted singly or as a set.
Similarly, you can GRANT DEFINE on a resource to a user and then REVOKE DROP on the resource from the same user as a way to grant all but one definition privilege.
Examples
Revoking Privilege to Define the System
The following statement revokes the privilege to define a system from the system DCA:
revoke define   on system syst0099   from dca0099;
More information
  • For more information on system profiles, see the
    CA IDMS System Tasks and Operator Reference section
    .
  • For more information on granting system definition privileges, see GRANT System Definition Privileges.