History   View   Links to this page 2013 November 20 | 02:12 am

Obtain list of workloads

A consumer such as Tivoli Workload Scheduler (TWS) can obtain a single workload or a list of workloads, filtered by several criteria if necessary, that the service provider, such as Tivoli System Automation for z/OS (SA z/OS) knows and is able to automate. Workloads are Availability Resources that have multiple differing concepts of status, such as “currently observed” and “desired”.

The consumer may use this status information for display in a user interface, but also to test the observed (= current) availability status against the desired availability status. In case of a mismatch between observed and desired availability status, the consumer may decide to act on the workload in order to align them. Existing mechanisms like Core’s or Automation’s Actions might suffice for “acting on” the workload.

Steps

  1. The consumer is given the service provider to use.
  2. The consumer requests the list of Availability Resources with their status information from the service provider.

Variations

The consumer may be interested in just a single workload or rather a subset of the workloads that the service provider manages.

  1. For a single workload, the consumer either knows the URI of the associated Availability Resource or he looks up the URI of interest from the list of Availability Resources registered by the service provider. Once he has a URI, the consumer requests status information about this Availability Resource from the service provider.
  2. For a list of workloads, the consumer can request a Query Resource using a URI constructed from a Query Capability base URI and Query String. Subsequently, the consumer requests status information for each Availability Resource returned in the collection of resources that match the query criteria.

Example

  1. TWS has a jobplan that at some point in its execution needs to stop a DB2 database for maintenance reasons.
  2. TWS looks up the Availability Resource that represents the database.
  3. TWS requests details for that Availability Resource from SA z/OS.
  4. The database’s observed status indicates it is available.
  5. Now, TWS knows that it can (has to) stop the Availability Resource for maintenance purposes.
  6. TWS finds some way to request the database to stop, and makes the request – the request’s implementation is unimportant, but TWS needs some way to find out when the database has been successfully stopped so that TWS can resume the jobplan’s execution.
  7. TWS monitors the database’s observed current status until it has stopped, and then resumes its job plan.