5.1 Policy Elements

XML is the representation for Orchestrator Policy elements. A policy can be deployed to the server and associated with any grid object. The policy element is the root element for policies. Policies contain constraints and fact definitions for grid objects:

5.1.1 Constraints

The constraint element defines the selection of grid objects such as resources. The required type attribute defines the selection type. Supported types are:

  • Resource

  • Provision

  • Allocation

  • Accept

  • Start

  • Continue

  • vmhost

  • Repository

Constraints can also be constructed in JDL and in the Java Client SDK. A JDL constructed constraint can be used for grid search and for scheduling. A Java Client SDK constructed constraint can only be used for grid object search. See also Section 7.7, Working with Facts and Constraints.

5.1.2 Facts

The XML fact element defines a fact to be stored in the grid object's fact namespace. The name, type and value of the fact are specified as attributes. For list or array fact types, the element tag defines list or array members. For dictionary fact types, the dict tag defines dictionary members.

See the examples in the directory, /allTypes.policy. This example policy has an XML representation for all the fact types.

Facts can also be created and modified in JDL and in the Java Client SDK.

5.1.3 Computed Facts

Computed facts are used when you want to run JDL to generate the value for a fact. Although computed facts are not jobs, they use the same JDL syntax.

To create a new computed fact, you subclass the ComputedFact class with the .cfact extension. An implementation uses the ComputedFactContext to get the evaluation context. For more information, see the job structure from the following examples:

After the new computed fact is created, you deploy it using the same procedures required for jobs (using either the zosadmin command line tool or the Orchestrator console).

The following example shows a computed fact that returns the number of active job instances for a specific job for the current job instance. This fact can be used in an accept or start constraint to limit how many jobs a user can run in the system. The constraint is added to the job policy in which to have the limit. In this example, the start constraint uses this fact to limit the number of active jobs for a user to one:

    <constraint type="start" >
        <lt fact="cfact.activejobs"
            reason="You are only allowed to have 1 job running at a time" />

Change JOB_TO_CHECK to define which job is to be limited.

class activejobs(ComputedFact):

   def compute(self):

          j = self.getContext()
          if j == None:
               # This means computed Fact is executed in a non running

               # job context.  e.g., the MMC fact browser
               print "no job instance"
               return 0
               # Computed fact is executing in a job context
               user = j.getFact("user.id")
               activejobs = self.getMatrix().getActiveJobs()
               count = 0
               for j in activejobs:
                    jobname = j.getFact("job.id")

                    # Don't include queued in count !
                    state = j.getFact("jobinstance.state.string")
                    if jobname == JOB_TO_CHECK \
                              and j.getFact("user.id") == user \
                              and (state == "Running" or state == "Starting"):

               jobid = j.getFact("jobinstance.id")
               print "jobid=%s count=%d" % (jobid,count)
               return count

For another computed fact example, see activejobs.cfact (located in the examples/activejobs.cfact directory).