SCHEDULE
Automated Job Submission System
Guide and Reference Manual

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. ⁸

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

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

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

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.

1. COMPUTE NEXT START Any job that is to be examined to determine when it will start again is entered here. The next start time is computed and the job proceeds on.
2. WAIT FOR NEXT START TIME Any job that has a start time set is entered into this queue and stays here until the start time occurs.
3. INITIATE WITH NO SET ID Any job that has been initiated either manually or automatically that does NOT have a SET ID assigned is entered here. The job is assigned a number and then proceeds.
4. WORKGROUP MANAGER Workgroup processing is performed in this state. Node analysis and selection is performed. Only affects jobs that are part of a workgroup.
5. WAIT FOR LOCAL PREREQUISITE Any job that has prerequisites on the local system (or cluster) is entered into this queue. Once all the prerequisite jobs have successfully completed the job proceeds.
6. REQUEST REMOTE PREREQUISITE Any job that has a prerequisite specified that is on a remote node is entered here. A request is transmitted to the remote node and then the job proceeds.
7. WAIT FOR REMOTE PREREQUISITE Once a job has requested a completion event from a remote node it then waits in this queue until the event occurs. Once all responses have been received the job proceeds on.
8. WAIT FOR A REQUIRED FILE Any job that requires a file to be present is entered into this queue. Once the file has been created the job proceeds.
9. WAIT FOR DISK SPACE REQUIREMENTS Any job that requires a certain amount of disk space to be present before proceeding will stay in this queue until the space is available.
10. READY TO SUBMIT Once a job has met all the resource and other requirements it is entered into this queue. The job is then entered into a batch execution queue and the job proceeds.
11. SUBMITTED FOR EXECUTION Once the job has been submitted for execution an entry is made into this queue.
12. EXECUTION STARTED Once the job starts to execute an entry is made into this queue.
13. JOB COMPLETED When the job completes execution it is entered into this queue.
14. INITIATE DESCENDANTS JOBS On completion the initiate list of each job is examined. Any jobs that are to be activated are entered into the B queue.
15. SEND INITIATE REQUEST TO A REMOTE NODE Any remote initiate job request is placed into this queue. The request is then transmitted over to the remote node.
16. HOLDING PREVIOUS COMPLETIONS When a job completes it is entered into this queue. Entries are held in this queue to be used to satisfy future prerequisite requirements. After a short period typically 1 day the entries are removed.
17. EVENT MESSAGES Foreground processing signal messages are entered into this queue before dispatching them.
18. JOB COMPLETION MESSAGES Foreground job completion messages containing complete history information are entered into this queue before dispatching.
19. REMOTE COMPLETION MESSAGES Remote messages requesting information when a job has completed are kept in this queue until the job completes. At that time a message is sent back to the requesting node.

23. EVALUATING VARIABLES The job is currently evaluating variables and determining the course that the job group will go depending on the resource list, initiates, prerequisites, and end action list.

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

2.3.8.2 Verify

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

2.3.8.3 Data line input

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.