job_state

The job_state table defines the set of allowable job and job step states. Each job and job step must be assigned one of the following states at all times.

• NEW (1) - Job is scheduled to be run but is not yet ready to start, because it is either lacking some resource or upstream work needs to be done first.

• READY (2) - Job is ready to start - all prerequisites have been satisfied.

• RUNNING (3) - Job is currently running on an entity.

• COMPLETE (4) - Job has been completed.

• SUSPENDED (5) - (Only available for Jobs) Job has been temporarily suspended, typically in favor of another more important job. An operator who may start a READY job may restart a SUSPENDED job.

• ONHOLD (6) - (Only available for Jobs) Job has been put on hold, typically because of some problem, and a special user privilege is required to start it or ready it.

• CANCELED (7). - (Only available for Jobs) Job has been canceled before being completed but we still want to keep a record of it; e.g. because it was imported from the ERP system.

• BYPASSED (8) - (Only available for Job Steps) Not a job state per se but the state of a step within a job for a given lot; the step was bypassed without being done.

• SUPERSEDED (9) - (Only available for Job Steps) Not a job state per se but the state of step data within a job for a given lot; the step is to be/has been redone, and this information is to be/was superseded by newer information.

The jobs progress through most of these states as they are executed.

The codes used for these states are predefined, however the user can change the description (and background color) for each state, but obviously not insert or delete rows or change the codes.

Codes will be assigned on default display priority.

While descriptions could vary according to language, this is believed to be too time-consuming and/or difficult, so there’s a state_desc field in this table.

Scheduler will run a stored procedure to get the set of jobs to be scheduled. This can look at the attr_value field for a specific attr_id in the wo_attribute table to decide which set to work with. We can also use an attribute to implement the READY(NEXT) pseudo-state (identifying which of several ready jobs should be worked on next) but then the attributes need to be glued on to the job table when it’s being presented, for sorting purposes.