Files for Process Classes, Locks, Jobs, Job Chains and Permanent Orders

These files contain the XML elements defining objects as follows and are processed according to the following naming convention:

The name= attribute should not be specified here. Should it be necessary to define it here, then it must correspond with the file name.

The replace= and spooler_id= attributes are not valid here.

<job order="yes">
    <script language="shell"><![CDATA[
      echo hello world
    ]]></script>
</job>

<job_chain>
    <job_chain_node  state="start" job="hello_world" next_state="success" error_state="error"/>
    <job_chain_node  state="success"/>
    <job_chain_node  state="error"/>
</job_chain>

<order>
    <run_time>
      <period repeat="3600"/>
    </run_time>
</order>

Directory Mirroring with the Job Scheduler

The Job Scheduler creates an object corresponding to each file possessing a recognised file name ending or extension (.job etc.) and links it with the file. The Job Scheduler then monitors the time stamp of each file and in the event of a change occurring proceeds as follows:

• A file name added to the directory causes the Job Scheduler to create a new, empty object, which is linked to the file. The object can be inspected using . For example, a xxx.job.xml file is mirrored in the Job Scheduler with the object, even when the file may not be readable or empty.
• A deleted file causes the mirrored object to be deleted from the Job Scheduler. Note that deletion is generally delayed, because, for example, a job must wait for the end of a task.
• Should a file be re-added to the directory before the deletion process has been completed, then the Job Scheduler will proceed as if a change had been made to the file.
• After a change has been made to a file - i.e. a change has occurred in its timestamp - then the Job Scheduler will read the file. If the file can be loaded, then the Job Scheduler changes process classes and locks immediately, whereas jobs, job classes and permanent orders are changed after a delay. This allows operations to be completed which are currently being carried out using the object which is to be changed. A more detailed description of this follows below.
• An error occurring whilst a file is being read does not affect a corresponding and already existing object. The Job Scheduler notes the error in the object and sends an e-mail. shows the error.
• Objects with the same (file) names can be present in different directories. The Job Scheduler differentiates between these objects through their paths. When it is necessary to link to objects from other directories - e.g.

  <job  process_class="/my_project/multi.process_class.xml"/>

  <job_chain_node  job="/other_project/hello_world"/>

  then the paths must be specfiied - either relatively or absolutely.

Effects of the Change and Delete Commands

Commands causing changes to be made to objects do not cause the same changes to be made to the corresponding files.

Commands causing objects to be deleted cause the corresponding files to be deleted.

Behaviour of Individual Object Types

Process classes

Changes made to a process class file are immediately taken over by the Job Scheduler.

To delete a process class, the Job Scheduler first stops all the related tasks. The process class is only deleted when all the tasks have been ended. Until this takes place, the Job Scheduler behaves as if the process class has been exhausted.

Locks

The Job Scheduler immediately takes over changes made to a lock.

To delete a lock, the Job Scheduler first stops all related tasks. The lock is only then deleted, when all the tasks have been ended. Until then, the Job Scheduler does not start any further jobs and does not allow any other task access to the lock.

Jobs

The Job Scheduler only takes on a change to a job after all associated tasks have been completed.

The Job Scheduler behaves in the same way when deleting a job object. No new tasks will be started.

Should a process class or a lock for a job be missing, then the Job Scheduler behaves as if the process class were exhausted or the lock unavailable.

Job chains

The Job Scheduler only processes changes to a job chain after all the orders in the chain have completed their jobs. This stops further job steps being initiated.

Orders in job chain nodes with the same order state are carried over by the Job Scheduler into the changed job chain.

The Job Scheduler proceeds in the same manner when deleting job chains.

Should a job chain be missing a job, then orders will collect in the job chain nodes, in the same way as if the job was not ready for execution.

Nested Job Chains

Should a job chain be missing a nested job chain , then the complete (parent) job chain will remain unavailable. All subordinate (child) job chains must be available before the Job Scheduler can determine whether or not the order identifiers are unique.

In the same way, a subordinate job chain will only be deleted once the superordinate (parent) job chains have been deleted.

Permanent Orders

Permanent orders are handled differently to all the other objects. On the one hand, the names of permanent orders have two parts (job_chain= and id= instead of name=) and on the other, the Job Scheduler does not always take account of changes made to permanent order files. The Job Scheduler only takes account of deleted or changed permanent order files, when:

• the order is not recognised;
• the order has not been started or
• the order is to be repeated by way of but has not yet been started.

The <show_state> Command

This command returns an answer for every file-based object.

The answer indicates when the Job Scheduler is in the process of replacing objects from hot folders (jobs, job chains, orders, locks and process classes).

indicates that a file has been deleted but the object associated with the file has not yet been deleted.