 View figure. |
The Job Scheduling tool is an integrated and flexible tool for scheduling the automatic execution of other Control Center tools. One-time activities such as adding a dbextent can be scheduled to execute once at a specified date and time; repetitive activities such as performing an archive can be scheduled to execute on a routine basis. Jobs can be executed sequentially, where each job is dependent on the completion of the previous (single-threaded execution), or concurrently as independent activities (multiple threaded execution).
Job control features include defining job priority; execution dependencies on database availability, support machine or service machine availability, and completion of other jobs; and a time window for job execution to begin and complete within.
Additionally, "no-process" days can be defined for your installation, such as local holidays or when your site is shut down. The product avoids scheduling jobs on these days and automatically reschedules them to execute on a specified earlier or later day.
As an example of how you might use the Job Scheduling tool, consider the time and work involved to manually initiate each tool to perform a full database archive, immediately followed by several DBSPACE reorganizations when the database returns to multiple user mode, followed by a log archive when all reorganizations complete. Compound this effort by the number of times you want to repeat the process. Once every month? Once every week? Using the Job Scheduling tool you can establish a thread of inter-dependent jobs to complete the same process, from start to finish, automatically. Furthermore, you can schedule the process to run repeatedly, such as every five days, and optionally during off-shift hours.
| Advanced Usage: | Although it is beyond the scope of this chapter, the Job Scheduling tool can also be used to schedule non-Control Center tools, such as your own internally developed tools, to execute on a Control Center support machine. See Appendix D, Master Scheduling Tool. |
If you plan on scheduling the execution of Database Administration tools, you should:
Use of the Job Scheduling tool and Job Schedule List tool requires Control Center DBA authority or greater.
The Job Scheduling tool itself runs on the Control Center service machine. It is here that the product maintains all job schedules, control files, and execution history files; performs job analysis; and initiates job processing, regardless of where the tool will actually execute. The product initiates System Administration tools to execute directly on the target database machine and Database Administration tools to execute on a specified Control Center support machine.
| Note: |
|---|
|
|
The product will notify you when a job executes, if it fails, and if it does not execute within its defined execution window (discussed later). It also keeps a running history of each job execution start time, stop time, and result (success or failure). Between the time a job is initiated and completes on its own, whether successfully or not, the product is largely unaware of the executing tool. For example, if a job running on a support machine were interrupted by some means, the product would be unaware that the job is no longer active. In fact, until specifically told otherwise, it will show the job status as being active. We discuss how to resolve this problem and others later in this chapter.
Most job output is saved on the machine where the job executes and can be listed, viewed, modified, and deleted using the Job Schedule List tool. Output is automatically purged after the number of days specified during the product installation process.
| Note: |
|---|
|
Job output from the DBSPACE Reorganization Driver and the Reorganization Index Tool is sent to the Control Center service machine and NOT saved. |
Further discussions on how Job Scheduling works is provided in the following section and in Job Scheduling Architecture.
This section discusses the basic concepts of Job Scheduling, providing you with enough information to get you started using the job scheduling tool. Later in this chapter we discuss the Job Scheduling Architecture.
The Job Scheduling tool allows you to define various dependencies for each job which must be met prior to the job being automatically initiated by the product. Typically, a job will be dependent on the availability of the target database manager, either up, running in multiple user mode or down, available to execute a single user mode tool. This will assure that the job is not initiated at a time when the database is unable to process it successfully.
Complex and time-consuming tasks which require several sequentially executed jobs can be automated by defining the execution of each job to be dependent on the completion of the previous. For example, you can schedule a database archive, followed by a reorganization, followed by another archive to execute as a single thread. See Figure 42.
Figure 42. Dependent Job Example
View figure.
Additionally, you can make one job dependent on the completion status (success or failure) of a previous job, allowing even more complex tasks to be scheduled for automatic execution.
Other job dependencies which effectively control if and when a job is initiated are discussed in the following topics of this section.
Repetitive activities such as performing an archive can be scheduled to execute on a routine basis by specifying the time between events. We refer to this as the schedule interval.
For example, to schedule a full archive of your production database to occur once a week, you would first specify the date and time of the initial execution. Next, you would specify a schedule interval of "1 week". After the initial successful job execution and every one thereafter, the product will automatically reschedule the job to execute in "1 week".
The example below shows the execution dates of four jobs, all initiated on March 1st, 1997, but each with a different schedule interval. We discuss the product's handling of the March 5th holiday next.
Figure 43. Schedule Interval Examples
View figure.
When the product automatically reschedules a job to execute, it references the SQLMSTR HOLIDAYS file, which resides on the service machine's 191 A-disk, to determine whether the proposed date matches one of the locally established holidays. See SQLMSTR HOLIDAYS File for a detailed explanation of holiday scheduling. 6 If a match is found, the product will use the specified alternate date for the job's next execution. The alternate day can be earlier or later than the holiday. In the example, March 5th is a holiday and March 6th is the alternate day. After job A completes on March 4th, it is rescheduled to run on the alternate day, coincidentally a day it normally would have run had there not been a holiday. Job B is also rescheduled to run on the alternate day after it executes on March 3rd. Jobs C and D are not impacted by the holiday.
The product can initiate several jobs to execute concurrently as long as no two jobs are vying for the same resource; for example, a Control Center support machine. If and when this should occur, it will favor one job over all others, initiating it to execute while the others are put on hold. As one jobs completes, the product will initiate the next as long as all other dependencies for that job are satisfied. You can control which jobs are favored over others by assigning a priority to each job. The job priority, which ranges from 1 to 9, where 1 is the highest, acts as the tie-breaker in these situations.
In the example below jobs A and B are to begin execution at the same time on support machine MSTRSUP. Since job A has the higher priority, it is initiated first and job B is initiated after it completes.
Figure 44. Job Priority Example
View figure.
The job execution time window defines a period of time within which a job is to begin and complete execution. The product will initiate a job as early as possible within the execution window, after all other dependencies have been met, as long as it determines that the job will complete prior to the end of the window. This allows you to restrict the execution of jobs to periods of low system usage. Conversely, it allows you to prevent the execution of jobs from overlapping into periods of high system usage.
If a job does not execute during the defined execution window, due to system downtime or dependencies not being met, the product will notify you and automatically reschedule the job for the next available window based on the job's defined schedule interval. Jobs scheduled to execute one time only will be placed in an inactive status.
|Regardless of the interval, a job will only run once in an execution |window. For example, if you define a three hour window, you cannot |schedule a job to execute every 30 minutes within that window.
Control Center uses a job's average runtime to determine whether it can complete within the time remaining in the defined execution window. The average runtime is calculated automatically based on the five most recent successful job executions. If it determines that there is insufficient time in the current window, the job will automatically be rescheduled.
In the example that follows, three jobs of varying average runtimes are scheduled to run concurrently. All are scheduled to start at 1:00 a.m. and have a defined window end time of 5:00 a.m.. Due to an unplanned event, the system is unavailable from 1:00 a.m. until 4:00 a.m.. When the system comes back online, only one hour remains before the end of the execution window. At that time, it initiates jobs A and B since both have an average runtime of less than an hour and should complete prior to 5:00 a.m.. Job C has an average runtime of one and a half hours and will not be able to complete by the end of the execution window. The product automatically reschedules it to execute during the next available execution window.
Valid start times for jobs A and B are indicated by the bars (&cursor.&cursor.&cursor.).
Figure 45. Job Execution Window Example
View figure.
The Job Scheduling tool is available as an option within many of the System Administration and Database Administration tools. It is also a part of the Master Scheduling tool, where it can be used to schedule non-Control Center tools, such as your own internally developed tools. The Master Scheduling tool is discussed in Appendix D, "Master Scheduling Tool".
The Job Schedule List tool is used to list all jobs for a given database, view job output, modify and reschedule jobs, delete jobs, and initiate jobs for immediate execution. Refer to Job Schedule List Tool.
The basic Job Scheduling entry panel is shown below. Except for the Server-mach entry field, it is the same regardless of which tool you're scheduling. The Server-mach entry field is not applicable when scheduling tools that execute on the target database machine (single user mode tools).
Figure 46. Job Scheduling Tool Entry Panel
+--------------------------------------------------------------------------------+ | mm/dd/yyyy CONTROL CENTER hh:mm:ss | |*------------------------------- Job Scheduler -----------------------------* | || Command ===> CTRLID: MSTRSRV | | || Jobname ==> ________ NODE: VMSYSTM | | || Server-mach ==> ____________________ (Required for Multi-user mode) | | || Job-status ==> S (S=Scheduled, A=Active, F=Failed, I=Inactive) | | || Priority ==> 5 ( 1 through 9, 1 = HIGH, 9 = LOW ) | | || Next-start ==> 19970419 23:00 ( format: YYYYMMDD HH:MM ) | | || Window-end ==> 19970420 08:00 ( format: YYYYMMDD HH:MM ) | | || Schedule-interval ==> 2WK ( ONCE or form nnnXX, where XX is: | | || MI, HR, DY, WK, WD, WE, MO, YR ) | | || Required-database ==> SQLDBA ( Database machine-id ) | | || Required-dbstatus ==> U ( U=Up, D=Down, A=Any ) | | || Dependent-jobname ==> ________ ( Prior job must run first ) | | || Dependjob-result ==> _ ( S=Successful, F=Failed, A=Any ) | | || Average-runtime ==> 01:00 ( format: HH:MM ) | | || Last-jobstart ==> ______________ Last-jobend ==> ______________ | | || Notify ==> MSTRSRV1 | | || Execute ==> SQLRBIND SQLDBA | | || | | || | | |*---------------------------------------------------------------SQMSCHDM----* | | PF: 1 Help 2 Detailed Help 3 End (Cancel) 6 Schedule | | | +--------------------------------------------------------------------------------+
| Usage Consideration: |
|
The job schedule is maintained on the Control Center service machine specified by your communication path setting shown in the upper right-hand corner of the panel. Refer to Control Center Communication Path and Database Settings. When the product initiates a multiple user mode job, it sends the appropriate command to the specified support machine where it is executed.
| Note! |
|---|
|
|
Together, the Next-start and Window-end parameters define the execution time window within which the job is to begin and complete execution. See Execution Window for more information.
The format of this parameter is YYYYMMDD hh:mm, where YYYY is a four-digit year, MM is a two-digit month, DD is a two-digit day, hh is a two-digit number to indicate the hour of the day (01 to 24), and mm is a two-digit number to indicate the minutes (01 to 59). An asterisk, "*", will appear next to the Next-start date when modifying the job and a "Rescheduled because of holiday" message will appear when viewing the job if this job has been scheduled to run on an alternative date as defined in the SQLMSTR HOLIDAYS file. See SQLMSTR HOLIDAYS File.
| Usage Consideration: | The data entry format must be followed exactly, including leading zeroes, spaces, and colons, to be accepted as valid input. |
The data entry format is the same as that for the Next-start parameter (YYYYMMDD hh:mm).
Valid two-character keywords are:
Example Schedule-intervals are:
Refer to |SQLMSTR HOLIDAYS File for more information.
| Usage Consideration: | The NEXT-START and WINDOW-END fields will be used in combination with the SCHEDULED-INTERVAL field to determine the NEW-START time. A job will only run once in a scheduled window, regardless of the interval. |
Possible values are:
| Operational Note: | Specifying "A" (Any) will still prevent the job from being initiated if the database is in a status other than up or down (such as archiving). |
Possible values are:
If you change the average runtime value on the panel and press PF6, the RUNTIMES file will be updated with five entries using the new average runtime. This will change the average runtime for the job to the new average runtime selected. The five entries in the RUNTIMES file will show UPDATED in the STATUS field.
When all job dependencies have been met, including the Next-start date/time, the product will add the average runtime value to the current time of day and compare the result with the value of the Window-end parameter. If it determines that the job cannot complete prior to the Window-end time, then the job will not be initiated. Instead, it will reschedule the job by adding the Schedule-interval value to the Next-start and Window-end parameters. If the Schedule-interval parameter is ONCE, indicating that it cannot be rescheduled, the job-status value is changed to inactive. The job can then be manually rescheduled or started immediately using the Job Schedule List tool.
The syntax for entering the Notify parameter is given below.
Understanding the command and command syntax requires familiarity with the product's command mode interface. Refer to Appendix G, Command Mode Interface.
The Job Schedule List tool is a comprehensive tool for managing all Control Center jobs for a given database. This includes jobs that are scheduled, active, have failed, or are inactive.
Listed are all jobs for the database identified by your communication path and database settings shown near the top of the panel. The communication path can be changed using Option C from the Control Center Main Menu, whereas the database setting can be changed on the Control Center Main Menu panel itself. See Control Center Communication Path and Database Settings on page "Control Center Communication Path and Database Settings".
Figure 47. Job Schedule List Tool
+--------------------------------------------------------------------------------+ | mm/dd/yyyy CONTROL CENTER hh:mm:ss | |*----------------------------- Scheduled Job List --------------------------* | || Command ===> CTRLID: MSTRSRV | | || Database ===> SQLDBA NODE: VMSYSTM | | || Sel Date Jobname Stat Executable Statement | | || --- -------------- -------- ---- ---------------------------------------- | | || _ 19970205 15:30 ARCHIVE S SQM MSTRSUP SQLEND ARCHIVE | | || _ 19970210 14:15 SQLREORG S SQLREORG SQLDBA PUBLIC.DSQTSCT3 | | || | | || | | || | | || | | || | | || | | || | | || | | || Select: V = View, M = Modify, D = Delete, S = Start Immediate | | || O = List Job Output, R = Display Runtimes | | || Page 1 of 1 | | || | | |*---------------------------------------------------------------SQMSCHDL----* | |PF: 1 Help 3 End 4 Sort/date 5 Sort/jobname | | 10 Refresh Job List Data 12 Dependencies Display | | | +--------------------------------------------------------------------------------+
Possible values are:
See Problem Resolution.
When a job fails, the product does not automatically reschedule it for the next schedule interval. Manual intervention is required to correct the problem and change the status back to 'S'.
You can place a job in an inactive status to temporarily remove it from automatic execution by the product. Jobs scheduled to execute one time only are placed in an inactive status after they execute.
The following column is displayed when PF12 (Dependencies Display) is selected.
Select options can be invoked against listed jobs.
| Usage Consideration: | Prior to deleting a job you should delete all job output using the List Job Output (O) select option. |
Job output is saved on the machine where the job executes and can be viewed, modified, and deleted from the Job Output Filelist panel.
Figure 48. Job Output Filelist Panel
+--------------------------------------------------------------------------------+ | mm/dd/yyyy CONTROL CENTER hh:mm:ss | |*----------------------------- Job Output Filelist -------------------------* | || Command ===> CTRLID: MSTRSRV1 | | || Job Name: DSQWKLY NODE: VMSYSTM | | || FILENAME FILETYPE FM DATE TIME | | || _ DSQTSCT3 LISTING A1 04/20/97 10:34:20 | | || _ DSQTSCT3 UNLIST A1 04/20/97 10:34:13 | | || _ DSQTSCT3 EXEC A1 04/20/97 10:34:12 | | || _ DSQTSCT3 SQLDBSU A1 04/20/97 10:34:03 | | || _ DSQTSCT3 UNLOAD A1 04/20/97 10:33:47 | | || | | || | | || | | || | | || | | || | | || | | || | | || Select: V = View, M = Modify, D = Delete | | || Page 1 of 1 | | || | | |*---------------------------------------------------------------SQMOLIST----* | |PF: 3 End 4 Sort/date 5 Sort/name | | | +--------------------------------------------------------------------------------+
Select options can be invoked against listed job output files.
The underlying scheduling interrupt capability of the product is implemented using the SQLMSTR TIMES file maintained on the Control Center service machine's 191 A-disk.
Each entry in the SQLMSTR TIMES file specifies a date (can be specified for repetitive interrupts), time, and a command that is to be executed at each interrupt. A direct interface to the SQLMSTR TIMES files |is provided using the Master Scheduling tool, but all other user interfaces are through the Job Scheduling tool.
The Database Monitoring tools do not utilize the job scheduler. These tools are designed to operate independently of all other scheduled activities, and therefore do not require the additional dependency characteristics provided by the Job Scheduling tool.
The job scheduler utilizes several additional files on the Control Center service machine which provide data that eventually flows into the SQLMSTR TIMES file as scheduled interrupts. Prior to the actual entry of a scheduled job into the SQLMSTR TIMES file, a thorough schedule analysis is performed by the job schedule analyzer routine. The analyzer reviews the condition of all databases, the current status of all scheduled jobs, and other job-related factors to determine whether the event should be scheduled to execute, and if so, the proper date and time for initiation.
There will always be an entry within the SQLMSTR TIMES file for every scheduled Control Center job, but the scheduled event will differ depending on the results of the job schedule analysis. If the job is ready for execution (all dependencies have been met), the event for the job will be INITIATION. If the job has any dependencies that remain unsatisfied, then the event for the job will be to RESCHEDULE the job at the end of the currently defined window. (If all job dependencies are met before the event interrupt causes the job to be RESCHEDULED, the event will be changed to START JOB). If the job is currently running, the SQLMSTR TIMES file will contain an interrupt entry for the job to issue a warning message if it runs past the end of the job's specified processing window.
Several different files are maintained by the job scheduler on the 191 A-disk of the Control Center service machine to manage scheduled jobs. The scheduling parameters of each job are maintained in a CMS file with a filename equal to the jobname and a filetype of SQMJOB. When a user executes the VIEW, MODIFY, or DELETE functions for a specific job, the SQMJOB file is accessed through the Control Center interface.
The information from each separate SQMJOB file is collected by the job scheduler into a single master schedule file with a filename filetype of SQLMSTR JOBS. This file contains additional information about job dependencies generated by the job schedule analyzer.
The information within the SQLMSTR JOBS file is translated by the job scheduler into specific time/date interrupts that are then inserted into the SQLMSTR TIMES file. This file contains the actual interrupt driver events that will trigger the initiation of a job at the appropriate date and time.
When each job executes, the job scheduler will record the start and stop times, and the results (success or failure). This information is kept in a separate file for each job. The filename of each file will be the applicable jobname and the filetype will be RUNTIMES.
The job scheduler will also utilize the SQLMSTR HOLIDAYS file during job rescheduling to avoid the possibility that jobs will be scheduled for execution on days when the system will be unattended, such as holidays or weekends. The SQLMSTR HOLIDAYS file is maintained on the Control Center service machine's 191 A-disk by the Administrator. It contains future dates which should be avoided by scheduled jobs, along with alternate dates which should be used if any job would normally be scheduled on the given date.
The scheduling parameters of each job are kept on the service machine's 191 A-disk in separate CMS files named jobname SQMJOB. An SQMJOB file is created when a job is initially scheduled. It contains parameter tags in the format of CMS NAMES file tags, along with the associated parameter values. To avoid the possibility of incorrectly modifying the tag syntax, these files should not be updated manually.
Figure 49 is an example of an SQMJOB file for a job with jobname QMFREORG that is scheduled to reorganize a QMF DBSPACE every two months. It uses Control Center support machine MSTRSUP and requires the SQLMACH database virtual machine to be UP in multiple user mode. The SQLREORG command executes against dbname SQLDBA.
Figure 49. Example SQMJOB File
:Nick.QMFREORG
:Jobname.QMFREORG
:Server_machine.MSTRSUP
:Job_status.S
:Priority.5
:Next_start.19970130 23:00
:Window_end.19970201 08:00
:Schedule_interval.2MO
:Required_database.SQLDBA
:Required_dbstatus.U
:Dependent_jobname.
:Dependent_jobresult.
:Average_runtime.00:53
:Last_jobstart.19961130 23:20
:Last_jobend.19961201 00:17
:Notify.MSTRUSR
:Execute.SQLREORG SQLDBA PUBLIC.DSQTSCT3
:Holiday_flag.
The SQLMSTR JOBS file will contain information about all the product's jobs, including all current dependency status data. Each record contains all scheduling information for a single job. The SQLMSTR JOBS file is created and maintained on the service machine's 191 A-disk and should never be modified manually. Figure 50 provides the layout of parameters within each record of the file.
Figure 50. SQLMSTR JOBS File Layout
POSITION(S) PARAMETER DESCRIPTION
----------- ------------------------------------------------------
1 - 8 Jobname
10 - 29 Server-machine
30 Server-machine availability flag
31 Holiday file processing flag
32 Job-status
34 Priority
36 - 49 Next-start
50 Start time exceeded flag
52 - 65 Window-end
67 - 71 Schedule-interval
73 - 80 Required-database
82 Required-dbstatus
83 Required-database availability flag
85 - 92 Dependent-jobname
94 Dependjob-result
96 Dependent job completed flag
97 - 101 Average-runtime
103 - 116 Last-jobstart
118 - 131 Last-jobend
133 - 192 Notify
194 - * Execute
The SQLMSTR TIMES file will contain an entry for each scheduled product job. The scheduled executable statement within the TIMES file will be EXEC SQMJOB, not the executable statement contained within the Execute parameter of the job itself. The EXEC SQMJOB statement of the TIMES file will include an action keyword and the name of the scheduled job, as shown in Figure 51.
The STARTJOB action keyword indicates that all job dependencies have been met and the job will be INITIATED by the product on the specified date and time. The QMFREORG job in the example SQLMSTR TIMES file has all dependencies satisfied and will be initiated at 11:00 p.m. on January 30th, 1997.
The RESCHEDULE action keyword indicates that a job has at least one dependency that has not been met. If all dependencies are not met before the specified date and time, the product will automatically reschedule the job for the next available execution window using the Schedule-interval of the job. The SUMINDEX job in the example SQLMSTR TIMES file is waiting for at least one dependency to be met and will be rescheduled to execute at a later date and time if the dependency has not been met by 6:00am on February 25th, 1997. If all dependencies are met before that date and time, the product will change the SQLMSTR TIMES entry from SQMJOB RESCHEDULE to SQMJOB STARTJOB, with a new date and time for the job to be initiated.
The WINDOWEND action keyword indicates that a job is currently ACTIVE, and a notification message will be sent to the appropriate product users if the job is still active beyond the date and time specified for the Window-end parameter of the job. The MAINTJOB job in the example SQLMSTR TIMES file is scheduled to notify users at 8:00 a.m. on January 19th, 1997 that the job has run beyond its defined Window-end date and time. If the job completes before the specified value, the product will automatically change the WINDOWEND entry and reschedule the job for its next execution.
Figure 51. Example SQLMSTR TIMES File
01/30/97 23:00:00 ........ EXEC SQMJOB STARTJOB QMFREORG 02/25/97 06:00:00 ........ EXEC SQMJOB RESCHEDULE SUMINDEX 01/19/97 08:00:00 ........ EXEC SQMJOB WINDOWEND MAINTJOB |
The job scheduler keeps track of each job execution within a separate RUNTIMES file for each job. RUNTIMES files are maintained on the service machine's 191 A-disk with a filename equivalent to the jobname and a filetype of RUNTIMES.
Each time a job executes, the job scheduler will add another entry to the job's RUNTIMES file which records the start time, completion time, elapsed time (hours and minutes), and whether the job failed. |The job was successful unless it is marked as |"FAILED." This file is used by the job scheduler to calculate the Average-runtime value, using the last five successful entries within the file to update the average runtime of the job. The job scheduler automatically purges old entries from the RUNTIMES file, only maintaining the most recent 50 job executions.
|Changing the Average Runtime of a job on the job menu |automatically resets the Average Runtime for that job. This Average |Runtime is reset by adding five entries (with the new average runtime) to the |RUNTIMES file.
Shown below is an example of a RUNTIMES file.
Figure 52. Example RUNTIMES File
20000111 02:21 20000111 02:59 00:38 FAILED 20000111 23:30 20000112 00:42 01:12 20000118 02:10 20000118 03:27 01:17 |
The SQLMSTR HOLIDAYS file allows each installation to provide the job scheduler with information about specific days that should not be considered for job execution. For example, if the local installation is closed for an entire week in July, on Easter, and on Christmas Day, the job scheduler can be instructed to avoid scheduling jobs on any of these days. For each day that the job scheduler should avoid, an alternate |date can be provided or the word SKIP can be specified to indicate |that the job should not run at all. When the SKIP option is used, the |job is automatically rescheduled for the next scheduled execution |interval.
When the job scheduler determines the correct date for the next execution of each job, the SQLMSTR HOLIDAYS file is referenced to determine whether the proposed date matches one of the locally established holidays. If a match is found, the specified alternate date is used. |The SQLMSTR HOLIDAYS file is checked each time a job is |rescheduled. However, if the SQLMSTR HOLIDAYS file is updated, then |all scheduled jobs are checked to see if their next start date matches a |holiday date in the file.
|The Holiday_flag parameter in the SQMJOB file is used to indicate if |a job has been rescheduled because of a holiday in the SQLMSTR HOLIDAYS |file. If the Holiday_flag is set to Y, then the job will be scheduled to run on an alternative date. Both the holiday date and the alternative date are defined in the SQLMSTR HOLIDAYS file that is maintained on the CTRLCTR service machine's |"A" disk.
After the job executes it will be rescheduled based on the original next-start date. A sample HOLIDAYS file (SQLMSTR $HOLIDAY) is provided on the code disk.
SQLMSTR HOLIDAYS file features include:
When viewing a JOB through the job menu, a "Rescheduled because of holiday" message will appear next to the Next-start date date to indicate that the job is scheduled to run on an alternative date.
If you modify an existing JOB through the menu by changing the the next-start date the holiday-flag will be set to blank. The Holiday_flag job parameter will not appear on the job menu and should not be changed by the user.
Figure 53 provides an example of the SQLMSTR HOLIDAYS file. The first date on each line represents the holiday to be avoided and the second date represents the alternate date for jobs to be scheduled. Note that the dates must be given in the form YYYYMMDD, where YYYY is a four-digit year, MM is a two-digit month, and DD is a two-digit day. Any characters beyond the second date on each line are considered as comments and will be ignored by the product. Also note that times should not be indicated, only dates. |The alternative date can be earlier than the holiday date, but it |cannot be earlier than the current date. You cannot use the same |alternative date more than once, but SKIP can be used for any or all |holidays.
Figure 53. Example SQLMSTR HOLIDAYS File
19990101 SKIP * New Year's Day 20000328 20000406 * Good Friday 20000330 20000407 * Easter 20000526 20000527 * Memorial Day 20000704 20000705 * Independence Day 20000901 20000909 * Labor Day 20001127 20001125 * Thanksgiving 20001128 20001126 * Thanksgiving day 2 20001225 SKIP * Christmas 20010101 SKIP * New Year's Day - skip all jobs |
There are two ways that the SQLMSTR HOLIDAYS file can be created and updated. One method is to stop the service machine, log onto it, create/modify the file (using XEDIT), then restart the service machine. Another method is to use the FILELIST (F) option under the General Control Center commands (G) option on the main menu. This option allows the file to be modified from your user ID using XEDIT and then migrate it to the service machine.
If an executing job is interrupted by some means and is unable to end through the normal job completion process, the job status will not be updated. In effect, the job is stuck in an active status. After determining that the job is no longer active, you can use the modify option of the Job Schedule List tool to change the job status.
The average runtime is automatically calculated by the product based on the last five successful runs. An unusually long job runtime, possibly due to processing problems, can inflate the average runtime to the point where it impacts job scheduling. |To correct the Average Runtime, change its value on the job update |menu and reschedule the job. You do not have to change the parameters |of any other jobs.