Fig.1: Scheduler Object model
4 System Management Functions
Last update
PvD
4 SMF
Scheduling Function
Recommendation X.746.
Overview
[X.746] 95/4 This recommendation defines the scheduling function. The scheduling function is a systems management function which may be used by an application process in a centralized or decentralized management environment to exchange information and commands for the purpose of systems management.
Definitions:
{Remark: The standard is not very clear. Either I don't understand the subtleties or it seems to contain some mistakes.}
Scheduling can be modelled as a part of the managed object whose operation or activity is to be scheduled, or as a separate managed object.
Characteristics for the control of a schedule can be imported into a managed object class or can be defined as a separate managed object. These two ways of defining scheduling of a managed object are termed internal and external scheduling, respectively. This Recommendation describes models for both internal and external scheduling.
The activities which can be controlled by scheduling are defined as part of the scheduled managed object (SMO) class. There need to be characteristics in the SMO related to these scheduled activities.
It is appropriate to define the scheduling mechanism within a managed object class if it will not need to be altered in the future {!} and the managed object is to be individually scheduled. The scheduling mechanism can be defined within a managed object class by including the appropriate scheduling components (e.g. attributes and behaviour). If more than one type of scheduling is defined within a managed object class, the conditions for instantiation of each type of scheduling must be defined in the managed object class definition.
When the scheduling mechanism is defined within the managed object whose activity is scheduled, no additional objects are required and the scheduling may be manipulated through the use of systems management operations. However, when multiple activities within a managed object are to be scheduled using this mechanism separate scheduling characteristics are required for each activity {and external scheduling becomes preferable}.
Scheduling characteristics for each activity may include more than one type of scheduling (see below) and the conditions for instantiation of each type shall be defined in the managed object class definition.
It is beneficial to define an external scheduling mechanism so that schedules may be determined independently of SMOs. Many managed objects may be controlled by a single schedule. If a single Scheduler Object (SO) provides the schedule, there may be no need for scheduling components in the SMOs. This eliminates the need to replicate and coordinate schedules across SMOs.
The scheduling function is represented by SO which are separate from the SMOs, as shown in Figure 1. One SO may control activities in any number of SMOs. Multiple external schedules are allowed for the same activity. The approach for defining more than one type of scheduling for the same activity is described below.
Fig.1: Scheduler Object model
The scheduler object provides a schedule to a SMO. SMOs shall have attributes which identify the SOs providing schedules. Each of these attributes shall have and be associated with behaviour which describes the effect of the schedule upon the SMO.
So there are 2 options: the managed object (SMO) contains its own scheduler (SO) and a schedule (which may be altered through systems management operations) to control activities, or the activities in the SMO are controlled by an external scheduler (SO) with all possibilities to manipulate the schedule (and synchronise with other activities).
In terms of functionality, the requirements to be satisfied are:
There are three specific types of scheduling: Interval scheduling, Trigger scheduling, and Operations scheduling.
{IMHO the naming Interval scheduling and Periodic scheduling (Trigger scheduling) are misleading: the definition of Interval scheduling at least suggests absolute day/time (so not an interval but timed), whereas periodic scheduling is actually about scheduling in intervals. Maybe interval scheduling is about long intervals (i.e. days or more), and periodic scheduling about short intervals (hours or much shorter).}
A type of scheduling that controls a number of intervals of operation of activities within specified managed object instances {i.e. the operations are active (versus inactive) during an interval; operations are activate <activity> and deactivate <activity>. Both Internal and External scheduling are possible}.
Requirements:
The standard describes three types of interval scheduling — daily, weekly, and monthly interval scheduling.
{Daily and weekly scheduling packages are defined in X.734.}
{There are also multiple-daily schedules, multiple-weekly schedules, and multiple-monthly schedules.}
Interval scheduling is used to define a schedule that controls a sequence of transitions of an activity of a SMO between the active and inactive state. The schedule may repeat in one of the following ways: a given number of days with specified intervals for each day, a given number of weeks with specified intervals for specified days of each week or a given number of months with specified intervals for specified days of each month. Each of these types of interval scheduling, daily, weekly and monthly is specified by selecting the intervals of day parameter for the day, week or month mask attribute in the appropriate scheduler object class.
The duration over which interval scheduling affects the operation of the SMOs may be controlled by the specified duration start time and duration stop time (date and time).
The intervals of operation are specified by a set of interval start and interval stop times.
The operation of the interval schedulers can be suspended by setting their administrative state attribute to locked and resumed by setting their administrative state attribute to unlocked {i.e. block or unblock a schedule}.
Behaviour: An interval schedule comprises a collection (constructed as a sequence or a sequence of set) of schedules for a single day. Each schedule for a single day comprises a set of distinct (i.e. non-overlapping) intervals. Each of these intervals is specified as a sequence of a start time and a stop time, the values of which represent a twenty-four hour clock co-ordinated with the time base specified for the start time in the duration package. The stop time shall not be less than the start time. An interval may be continued into the next day by specifying a stop time of 24:00 and by specifying an interval with a start time of 0:00 for the next day.
A type of scheduling that controls the triggering of activities within specified managed object instances {i.e. only issue a start <activity> }.
Requirements:
The standard describes two types of trigger scheduling — periodic and aperiodic scheduling. These types of scheduling are defined by packages which may be included in managed objects for the purpose of internal scheduling (except for the operations scheduling) or in a scheduler object for external scheduling.
If a combination of interval and trigger scheduling is required for one activity, the triggering is effective only within the intervals defined by the interval schedule.
A type of scheduling that controls the repetitive triggering of activities within specified managed object instances {e.g. every 5 minutes}.
Periodic scheduling is used to define a schedule that repetitively triggers specified activities at regular time intervals within specified managed object instances. The time duration {interval} over which the activities, specified in the SMOs, can be triggered, may be controlled by the specified duration start time and duration stop time (date and time). When a periodic scheduler is created, it either triggers at the specified duration start time (which may be the object creation time) or it synchronises the first triggering point to a specified synchronisation time. It then synchronises the period to this initial triggering point.
The operation of a scheduler can be suspended and resumed by setting its administrative state attribute. Two methods of synchronisation of the triggering points can be used when the operation of the scheduler is resumed, either period synchronisation time or resynchronise mode. If a period synchronisation time is specified, the triggering will always be synchronised to that time. If a resynchronise mode has been specified in the SO, the triggering may be synchronised to the specified duration start time, or it may be synchronised to the time of resumption of the SO, depending on the resynchronise mode selected. If period synchronisation time and resynchronise mode are absent, the period will always be synchronised to the specified duration start time.
{So when a schedule is resumed (after being suspended), there are two options: by default the activities were blocked during the suspension interval and will resume at the next interval (related to the original starting point). If resynchronisation was specified, it will start immediately and retime the following intervals.}
A type of scheduling that controls the triggering of activities at certain specified times within specified managed object instances.
An activity in a managed object can be triggered at scheduled times {this corresponds to batch scheduling on many computers}. This is achieved by specifying a set of trigger times for the activity rather than specifying an interval for the operation of that activity. This mechanism allows activities in a managed object to be triggered at a absolute times as opposed to the triggering of activities at regular intervals relative to a start time as defined for periodic scheduling.
An aperiodic trigger schedule may repeat in one of the following ways: a given number of days with specified trigger times for each day, a given number of weeks with specified trigger times for specified days of each week or a given number of months with specified trigger times for specified days of each month. Each of these types of aperiodic scheduling, daily, weekly and monthly is specified by selecting the trigger times parameter for the day, week or month mask attribute in the appropriate scheduler object class.
{The standard seems to ignore Aperiodic scheduling for the rest.}
In accord with its schedule, a scheduling object which uses the operation scheduling approach determines operations performed upon SMOs.
In this case the SO may have notifications to report success and failure in the execution of the operations. A scheduling object which uses the operation scheduling approach has attributes to identify a schedule, the SMOs which are being scheduled and the operations and parameters which are to be requested in accord with the schedule. When the result notification is issued the managed object class and managed object instance parameters shall be present in the operation result(s).
{The standard is particular obscure on Operations scheduling. Characteristic of Operations Scheduling seems to be the fact that it reports success or failure.}
A SMO may be scheduled by more than one SO. In order to be scheduled by an external interval or trigger scheduler a SMO shall have an attribute which points at the SO (the external scheduler name attribute). The SO may optionally have an attribute which points at the SMO (the scheduled managed objects attribute). SMOs which have multiple activities to be scheduled shall have an attribute associated with each activity that points to the appropriate SOs. A single SO may provide a schedule for many SMOs. See Figure 1.
If a SMO is deleted, the entry for that object in the scheduled managed objects attribute in the related SO(s) will be deleted. If there are no remaining entries in the scheduled managed objects attribute, the SO will continue to exist. If the SO is deleted, the state of the activities of the SMO shall be as defined by the behaviour of the SMO.
Changes in the administrative and operational state of the SMO will have no effect on the SO. If the administrative state of the SO is changed to locked or the operational state is changed to disabled, the state of the activity in the SMO becomes inactive. This state may be represented by an attribute of the SMO associated with this activity. If the administrative state of the SO is changed to unlocked or the operational state is changed to enabled, the SMO is set to the status as indicated by the schedule defined for the SO.
The relationship between the SO and the SMO is established at the creation time of the SMO or when the identifier of the SO is added to the external scheduler name attribute of an existing SMO. When the SMO is created with the identifier of the SO included in the external scheduler name attribute, the identifier of the SMO instance is added to the scheduled managed objects attribute of the SO (if the SO instance supports it). The relationship may be terminated by deleting either of the objects as described above, by removing the identifier of the SO from the scheduled managed objects attribute of the SMO.
Instantiable managed objects are:
| Top: | Scheduler | |||
| Inherits from Scheduler | Daily Scheduler |
Weekly Scheduler |
Monthly Scheduler |
Periodic Scheduler |
|---|---|---|---|---|
| Inherits from <x> Scheduler |
Daily Operation Scheduler |
Weekly Operation Scheduler |
Monthly Operation Scheduler |
Periodic Operation Scheduler |
Next section: Trouble Management
Up to Contents
Up to Index
=O=