Previous | Contents | Index |
The SCHEDULE System supports two levels of directories, a top level and one sublevel. Any number of each variety can exist. The basic directory formats are:
Directory | Description |
---|---|
/ | Root directory |
/toplvl/ | Top level directory |
/toplvl/sublvl/ | Sublevel directory |
/default/ | Last resort defaults |
The default directory is the user's username. Each directory can contain three types of entries. 1) Job entries. 2) Calender entries. 3) Directory entries.
For example, to create a new top level directory use the following type of command.
Schedule> mkdir johndoe -log created /johndoe/ |
Access to the root directory is controlled by two parameters. 8
To create a sublevel directory use the following type of command.
Schedule> mkdir /johndoe/test/ -log -owner=[22,43] -protection=(u+rwx,g+rx,o+x) created /johndoe/test |
To create a new calendar entry use the following type of command.
Schedule> mkcal /johndoe/mycalendar |
To create a new job entry use the following type of command.
Schedule> mk /johndoe/myjob |
is optional. This is the default section qualifier and can be left off.
2.3.4 Default job entry
Whenever a new job is created a set of default values is loaded into all the fields of the job definition. These fields are picked up from a special job entry that is named DEFAULT. This DEFAULT job entry is located by a search process.
If you are creating a job in a subdirectory an attempt is made to
locate a default entry in that subdirectory. If that fails, an attempt
is made to locate it in the top directory. If that fails, an attempt is
made to find one in the /default/ directory. If that fails a set of
hard coded default values are loaded.
2.3.5 Calendars
A calendar is a chart showing the days of each month and possibly on what days a job is allowed or is not allowed to run. Any number of separate calendars can be set up. They can be set up system wide or specific to a user. Holidays are defined in a separate calendar which can optionally be superimposed on any other calendar. There are two distinct types of calendars, standard or work days.
The standard calendar is the normal wall calendar that
everyone is used to. A work day calendar is one in which
only the work days of the month are counted. For example December has
31 days on a standard calendar but only 22 days on a work day calendar.
2.3.5.1 Viewing the days of the month
To view the two calendars that are automatically set up when you install the system use the following commands:
Schedule> morecal /default/standard 1998 December (default) Sun. Mon. Tue. Wed. Thu. Fri. Sat. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Schedule> more -calendar /default/workdays 1998 December (default) Sun. Mon. Tue. Wed. Thu. Fri. Sat. .. .. 1 2 3 4 5 .. .. .. .. 6 7 8 9 10 .. .. .. .. 11 12 13 14 15 .. .. .. .. 16 17 18 19 20 .. .. .. .. 21 22 |
2.3.5.2 Control attributes
Each calendar is controlled by a set of attributes. To view the
attributes of all the system wide calendars use the following command:
Schedule> lscal -full /default/* /default/holiday Comment = Holidays - system wide holidays Owner = [SYSTEM] Protection = -rwxr-xr-x Workdays = Flags = Fiscal = 1 /default/standard Comment = Standard calendar - all days Owner = [SYSTEM] Protection = -rwxr-xr-x Workdays = Flags = NoWeekend_runs Fiscal = 1 /default/workdays Comment = Only work days Owner = system Protection = -rwxr-xr-x Workdays = NoHoliday,NoWeekend Flags = Fiscal = 1 |
The workdays setting indicates what days are to be counted so as to produce the desired day numbering scheme. The possible settings are:
Setting | Description |
---|---|
NoHoliday | do not count holidays |
NoWeekend | do not count saturday or sunday |
The NoHoliday setting indicates that the holiday calendar is to be superimposed and any day marked (with any type of mark) on the holiday calendar is considered a non-counted day.
The flag settings indicate what days runs are allowed on. The possible flag settings are:
Flag | Description |
---|---|
NoHoliday_runs | do not allow runs on holidays |
NoWeekend_runs | do not allow runs on Saturday or Sunday |
The NoHoliday_runs flag indicates that the holiday calendar is to be superimposed and any day marked (with any type of mark) on holiday calendar is considered as a non-allowed day.
The Fiscal value is the number of the
first month of that calendar. For example in the above calendars
January (month number 1) is the first month. This value is used
whenever a named day rescheduling method has been indicated and the
names YEAR_START or YEAR_END have been specified.
2.3.5.3 How calendars are located
In each job a calendar name can be specified. This name can not contain a directory path. If the job is in a subdirectory then an attempt is made to locate the calendar in that same subdirectory. If not found there, then an attempt is made to locate the calendar in the top directory. If not found there, then an attempt is made to locate the calendar in the [DEFAULT] directory. If not found there an error message is generated.
This same process is used when trying to locate a holiday calendar.
The holiday calendar is named HOLIDAY. Whenever a holiday calendar is
needed a search is made for a calendar by that name.
2.3.5.4 Marking a calendar
Each day of a calendar can contain up to two letters as marks. The marked calendar rescheduling method specifies that a job is to run on all days marked by a certain letter. Either of the two letters can be this mark.
For example to mark January 10 with the letter "A" use the following command:
Schedule> chcal /default/standard-date=10-jan-mark="A" |
For example to mark January 1 as a day that no runs are allowed on use the following command:
Schedule> chcal -default -standard -date=1-jan -norun |
2.3.5.5 Setting up holidays
To set up system wide holidays use the /default/holiday calendar. To
set up a local holiday calendar just create one by that name in either
your top-level or sub-level directories. Holiday calendars are marked
up just like any other calendar.
For example to mark January 1 as a system wide holiday use the following command:
Schedule> chcal /default/holiday/date=1-jan -norun |
2.3.6 Reports
An important component of the SCHEDULE is a general purpose
report writer. The SCHEDULE system interfaces this report
writer to the SCHEDULE database. The report writer is
controlled by a group of report definitions. A group of 80 (32 history
data, 48 control data)
report definitions are provide with the system. All these definitions
can be customized as needed or new ones defined. 9
The format and content of these reports are documented in a later section of this manual.
There are two types of data that can be used by the report writer. 1)
Control data which contains all the static information about what a job
is and how to schedule it. 2) History data which contains all the
historical information about scheduling state changes.
2.3.7 Scheduling queues
All job scheduling activity is controlled by a series of scheduling queues. Each queue represents a state. For example one queue is used to hold jobs waiting for disk space. The various scheduling queues are identified by a single letter. In general jobs start at the top (queue A) and progress downward (queue S).
The various queue names are listed below.
A series of SCHEDULE commands may be executed using a command file. The command file can consist of multiple SCHEDULE commands as well as several formatting commands.
The command can be entered in any of the following three ways:
$ schedule . command_file.schedule
$ schedule source command_file.schedule
$ schedule @ command_file.schedule
All valid SCHEDULE commands in the command file will be
executed in order. In addition a number of other formatting conventions
may also be used. These are described in the following sections.
2.3.8.1 Comments
A comment may be added to a command file using either of two symbols. Sections of a command file delineated by this symbol will be ignored by the command interpreter. The symbol may be either a # or a !. The following is an example of a comment in a SCHEDULE command file.
#======================================================================== # The following commands will create and set the protection on a SCHEDULE # directory. #======================================================================== mkdir /report chdir -prot=og+r /report |
All or selected lines of a SCHEDULE command file may be displayed to the screen by turning on the verify option. This causes all lines to be echoed following the command. The verify option may be turned off at any point by placing noverify at the end of the designated section. An example of the verify option is shown below:
verify mkdir /report chdir -prot=og+r /report noverify |
SCHEDULE command files can process input from subsequent data lines using a prefix and suffix before and after the input lines. For instance, this can be used to insert report definitions into the SCHEDULE database.
The data input lines must directly follow the command as shown:
insrep new_rep * *data* report title="System wide summary of events/selected by all settings/- (SCHH_SYS_ALLEVENT_ALL_80)",- out=**."Output",- srcshr=scheduleshr,srcrtn=scheduleh_db_io,columns=80 select directory, include="[*],[*.*]" select job_name, include=**."Job" select set_id, minimum=**."Minimum set id", maximum=**."Maximum set id" select log_date, from=**."From log date", to=**."To log date" select sch_event, include=**."Queue_list" print log_date,sort,title="Log date",edit_string="NN-DD-YYBTTTTT" print sch_event,title="Event" print full_name,title="Job name",edit_string="X(20)" print set_id,title="Set id" print cpu_time,edit_string="ZZZ,ZZZ.ZZ",title="Cpu time" print io_count,edit_string="Z,ZZZ,ZZZ",title="Io count" end *eod* |
The keyword or symbol used to represent data input from within the command file can be any of the following:
command *
command sys$input
command stdin
command 0
The list of data must be preceeded by
*data*
or
$deck
and followed by
*eod*.
or
$eod.
8 The two parameters are ROOT_DIR_OWNER and and ROOT_DIR_PROTECTION. The default protection on installation is to allow everyone to create top level directories. To change this edit the parameter file.9 The report definitions are contained in the file SCHEDULE_LIBRARY:SCHRPTCLB.CLB. |
Previous | Next | Contents | Index |