Organization of internal data structures

The Scheduler populates its own internal data structures from the database. These internal data structures are used by all Scheduler logic, including both the prepackaged logic and the special logic that you add.

The internal data structures serve as a link between the standard Scheduler and the code that you write to customize the standard Scheduler. The internal data structure definitions are contained in the header file “factor.h” (see previous section). For this reason, you must include the statement


#include "factor.h"

at the beginning of the code for your Scheduler customization. Once you have included this line in your code, you can use the data defined in “factor.h” in your functions.

The data defined in factor.h falls into three categories:

  • Modeling objects
  • Internal objects
  • Global scheduling structures

The modeling objects are closely related to the input database tables and their columns. You can see this by comparing factor.h to the input database files which end in “000” in the database. For example, the table RESRC000 contains the data for resources.

Each modeling object contains a pointer for auxiliary data to be attached. Auxiliary data can be thought of as user data to be used by the Scheduler for an object. The auxiliary data pointer is a (void *) so you can attach anything to the object, i.e. pointer to a structure, integer value, a string, etc. For example, the resource structure, RESRC, contains an element (void *) rsaux. Auxiliary data would most likely be populated in ucini2.

The internal objects are used in queuing and other internal Scheduler processing. Internal objects are often closely related to modeling objects and may even be pointers to modeling objects. A resource request is an example of an internal object that is a pointer to a modeling object, a resource. Internal objects are used instead of modeling objects on queue lists and other lists. This is done because entities can be on at most one list and many modeling objects are on a global list. Restricting entities to one list only helps to preserve data integrity and expedites searching and processing.

The global structures include data related to the alternative table in the database, the problem definition table in the database, the alternative summary table in the database, lists of members of the structures corresponding to the modeling components, and structures used in the internal workings of the Scheduler.