Dropping a service class

You drop service classes using the DDL statement DROP SERVICE CLASS.

Before you begin

To drop a service class, you require WLMADM or DBADM authority.

See Workload management DDL statements for more information about prerequisites.

You cannot drop the default service superclasses (SYSDEFAULTUSERCLASS, SYSDEFAULTMAINTENANCECLASS, and SYSDEFAULTSYSTEMCLASS) or their associated service subclasses. The only way to drop the default service superclasses and their associated service subclasses is to drop the database.

A service class you defined cannot be dropped if any of the following conditions apply:

  • It is enabled
  • It is referenced by any workload
  • It is still referenced by a workload occurrence
  • Any connection or activity is currently mapped to the service class
  • If the service class is set as the target of a REMAP ACTIVITY action.

Dropping a service class cascades to drop any thresholds, work action sets and service subclasses defined for the service class.

Procedure

To drop a service class:

  1. Change workloads to not point to the service class, or disable the workload definitions. Alternatively, use the DROP WORKLOAD statement to drop all workloads that are associated with the service class. Issue a COMMIT statement after dropping each workload.

    Activities already running under the service class will continue to run. You can list agents that are currently mapped to a service class by using the WLM_GET_SERVICE_CLASS_AGENTS table function. If you do not want these activities to complete, you can use the application identifier returned by the table function and use the FORCE APPLICATION command to force these applications off the database.

  2. If you are dropping a service subclass and a work action maps to that service subclass, drop the work action using the DROP WORK ACTION clause of the ALTER WORK ACTION SET statement. Alternatively, drop the work action set that contains the work action that maps to the service subclass by using the DROP WORK ACTION SET statement. Issue a COMMIT statement after dropping each work action, or after dropping the work action set.
  3. If you are dropping a service subclass and thresholds exist with REMAP actions that point to that service subclass, drop the thresholds using the DROP THRESHOLD statement. Issue a COMMIT statement after dropping each threshold.
  4. Disable the service class by using the ALTER SERVICE CLASS statement. If you are dropping a service superclass, this action disables all service subclasses associated with the service superclass. Disabling a service class prevents any additional activities from being associated with it. After disabling the service class, issue a COMMIT statement.
  5. Use the DROP SERVICE CLASS statement to drop the service class. Dropping a service class cascades to drop any thresholds, work action sets and service subclasses defined for the service class.
    Note: You cannot manually drop the default service subclass for the service superclass. The default service subclass for a service superclass is dropped when the service superclass is dropped.
  6. Commit your changes. When you commit your changes, the service class is removed from the SYSCAT.SERVICECLASSES view.