Specialist Functions Overview

This section of the user manual should be read in conjunction with the technical documentation supplied with the relevant release of Callista. The section is oriented towards the entry and maintenance of data in Job Control and Scheduling (JBS) forms, while the technical documentation gives more detail about the subsystem's interaction with the wider operating environment.

This documentation assumes a knowledge of information given in Understanding Job Control & Scheduling.

In this section:

• Setting up the Job Control & Scheduling Subsystem
• Jobs, parameter files and outputs
• Batch queues
• Run windows
• Job control
• Default data
• Background processes
• Subsystem Clean-up

Setting Up the Job Control & Scheduling Subsystem

Using the forms described in this part of the subsystem documentation, information technology staff and systems administration staff determine the framework within which jobs are run by end-users. The task includes:

• recording hardware used (in the Maintain Printers (JBSF0110) and Maintain Faxes (JBSF0180) forms)
• naming executable jobs, their parameter files and outputs so that this subsystem can handle them
• defining batch queues
• defining run windows
• determining the access of end-users to jobs and data processed by jobs
• applying suitable checks and restrictions in order to control how jobs run
• creating default output details for jobs
• including reports and other jobs on menus.

Defining jobs, parameter files and outputs

Maintain Job Details (JBSF4110) is the central form used to name and define jobs, parameter files and outputs in the JBS subsystem.

• Multiple Jobs. A single executable job, with associated parameter file, can be known within Callista under more than one job name. These 'named jobs' are referred to in the forms and in this documentation as 'system jobs' or simply as 'jobs'. Creating several system jobs for a single executable job allows system jobs to be tailored to the requirements of different parts of the institution. For example, different security restrictions could apply to the same executable job when accessed from different menus, depending on its job name.
• Output file. Reports obtain their output filename from the Maintain Job Details form. For other types of job, the output filename given in the executable job should be recorded in this form so that the JBS subsystem can direct the file to a destination.

Defining batch queues

Batch jobs are assigned to active batch queues, which are created using the form Maintain Batch Queue Details (JBSF4500). Using this form, batch queues can be suspended at any time.

Defining run windows

'Run windows' may be specified for individual jobs, and must be specified for requests. Jobs can only run in their own run windows. The set of times comprising a run window is recorded in the Maintain Run Windows (JBSF4410) form.

Job control

Various restrictions and indicator settings are used to control the running of jobs in four main ways:

• User restrictions - controlling who can run jobs, how, and the data that the report jobs they initiate can access
• Ordering - controlling the inter-relationships between jobs
• Job flow - controlling the timing and flow of jobs through the system
• Errors - controlling how jobs behave in error situations.

User restrictions. The documentation dealing with access to particular jobs at person and role level is reached through field help in the forms Maintain Person Function Grants (SECF0062), and Maintain Security Role Function Grants (SECF0063). In these two forms it is also possible to grant end-users the required privileges to change the priority of individual jobs at request time, achieved by setting the appropriate Override Priority indicators.

The Allow Standing Request indicator in the Maintain Person Preferences (SECF0066) form is used to grant individuals the privilege to submit jobs as standing requests.

The Run As Requester indicator in the Maintain Job Details (JBSF4110) form can be set to restrict data access in report jobs. If set, the job will return only the data available to the person requesting the job, as determined by normal database security restrictions.

Ordering. If it is necessary that jobs run in a particular order, they can be linked in dependency relationships using the form Maintain Job Dependencies (JBSF4140), which is accessed from the central form, JBSF4110. To ensure that related jobs are always included in the same request, set the Mand (mandatory) indicators. End-users can determine the running order of jobs in a request by using the Sequence indicator in Maintain Request Details (JBSF5210). If neither of these controls apply, jobs will normally run within requests in priority order, though this may depend on whether 'specialty' batch queues exist for particular priorities.

• How many batch jobs can run concurrently This is influenced by:
• the number of active batch queues in the current run window(s)
• whether any batch queues are restricted to running jobs of specific priority, and
• whether there is a number specified for Maximum Concurrent Jobs in Maintain Run Windows (JBSF4410) for the current run window(s).
• Whether jobs are waiting for other jobs to run. This depends on:
• how many jobs are in a prerequisite/dependent relationship or have a sequence specified in the request
• whether in either of these cases, jobs are waiting for low priority jobs to run first.
• The run modes for reports. If required, reports can be restricted to running in IMMEDIATE or in BATCH mode (using the central form, JBSF4110). Run windows can be similarly qualified in the Maintain Run Windows (JBSF4410) form. In conjunction, these two restrictions allow the load on the server at certain times to be weighted in favour of end-users running immediate reports, while at other times batch jobs are favoured.

Errors. If the Restartable indicator is set in the central job form, JBSF4110, a job running at the time of system failure or database restart will be automatically re-scheduled to run at the next available opportunity. Where jobs are in a dependency relationship, dependent jobs are prevented from running (job status ABORTED) if a pre-requisite job fails.

The Abort On Error indicator can be set by end-users in the central request form, JBSF5210, to ensure that if one job fails, subsequent jobs in the request will be prevented from running (their job status is set to ABORTED). This might be especially important if the Sequence indicator is set.

Default data

Destinations for output can be included in the job definition either as mandatory or as default 'options', or can be left for end-users to specify at run time. The Override Options indicators control end-user actions. Options are recorded in the Maintain Job Output Options (JBSF4120) form, while the Override Options indicators are set in the central job form, JBSF4110.

Background processes

• jbsp_mnt_requests is a stored procedure which handles submitted and recurrent jobs up to the point when they are SCHEDULED.
• jbsc_prc_req_rjr_run is a Pro*C program controlling batch queues and the running of jobs.

Subsystem Clean-up

• Delete Old Requests (JBSJ9110) is used to remove 'old' run requests which have completed or been cancelled.
• Delete Old Output Files (JBSJ9120) is used to remove files from various directories containing the output from jobs.
• Delete System Log Entries (GENJ0010) is used to remove 'old' system log entries.