DCL commands provide easy access on all OpenVMS hardware platforms to job database information and current job status. You can run, modify, or review jobs by job name, number, group, owner, or type. The manager supports the use of wildcards on each of a job’s fields, so you can enter a single command for multiple jobs.

You can use the DCL interface to access the full set of Job Management Manager commands (general user commands and also management commands) if you have the required system privileges.

If you have a workstation or other DECwindows display device you can use the Motif interface, which provides you with a graphic view of Job Management Manager jobs. Jobs are represented by boxes. Job dependencies are indicated by arrows that show you the order in which jobs are performed.

You can access all general user commands using menus and dialog boxes; you cannot access management commands using the Motif interface.

To use management commands of the manager, you must have one of the following OpenVMS system privileges:

If you are unsure what your system privileges are, see your system manager.

Some management commands require other privileges. These privileges are described in the respective command descriptions.

For a description of general and management commands, see Chapter 4, Using the DCL Command Interface.

To start the manager, at the DCL prompt, enter the following:

$ @sys$startup:job$manager$startup.com

To stop the manager, at the DCL prompt, enter the following:

$ @sys$startup:job$manager$shutdown.com

To understand how the manager manages jobs, you should understand how it defines a job, a job database, and a job record.

Job

The main part of a Job Management Manager job can be a single system-level command or a command file containing multiple commands. A job also includes all the related information required to process commands, such as when and where to run the commands and how to complete them. You refer to a job by its job name or job number.

Job Database

A job database is the collection of information that tells the manager when and how to process each particular job. The Job Management Manager database is a multikeyed index file that uses OpenVMS record management services (RMS) to store information about each job.

The manager is most useful when processing repetitive jobs, such as fiscal reporting procedures, system maintenance or backup tasks, and user applications. The job database is used to process repetitive jobs.

You can also use the manager to run non-repetitive jobs that would benefit from its scheduling, job synchronization, or other features.

Job Record

A Job Management Manager job is represented in the database by a job record. You create most of the job database information when you create, copy, or modify job characteristics, such as:

The primary part of a job record is a Job Management Manager command, which is any valid system-level command you want to perform. To enter a command, you use the standard command format for the operating system that the command executes on. In the DCL interface, use quotes to enclose a case-sensitive command.

Any user can create a job record or copy a record to the Job Management Manager job database.

The following table documents the limit for text attributes in the job record:

When you create a job in the database, you can specify whether or not to restart the job after system interruptions. You can also include restart labels in the job’s command procedures, if you want the job to restart from a specific step rather than at the beginning.

Format

You can specify a Job Management Manager job by name or number. The job name or number is named the "job specifier".

([node::]job-name[=username])

Example:

XYZ:WEEKLY-RENAME=DOE

Default Node and Username

You do not have to specify a node or username for jobs that you own.

Specifying Another User’s Job

To specify a job that belongs to another user, use the =username qualifier to add the user’s name to the job name. In the following example, the job COPY_IT belongs to user SMITH:

COPY_IT=SMITH

Specifying a Job Outside Your OpenVMS Cluster

You can specify Job Management Manager jobs on nodes outside your OpenVMS Cluster if the manager is installed with its wide area network features. For example, to specify the job COPY_IT on node XYZ outside your OpenVMS Cluster, add that node name to the job name.

XYZ::COPY_IT

Uniqueness of a Job Name and Number

The wide area network feature allows you to:

The following commands and qualifiers are not supported over the network:

Some Job Management Manager commands use qualifiers that require you to specify time intervals using OpenVMS delta time. Here is the format for OpenVMS delta time:

dddd-hh:mm:ss.cc

The /INTERVAL qualifier, used with the COPY, CREATE, and MODIFY commands, allows you to use Job Management Manager delta time. Here is the format for Job Management Manager delta time:

+dddd-hh:mm:ss.cc

Any time a job runs either automatically or as the result of a RUN command, the next scheduled start time for the job is calculated. This calculation takes into consideration the job’s scheduling interval, day restrictions, and Special Day Restrictions.

If a Special Day conflict is detected, requiring that the job be rescheduled or put on hold, any messages to be issued to the job’s owner and the operator will be sent at this time. Since this calculation is performed at the time a job is run, messages about a job’s Special Day scheduling conflicts may be sent before the run of the job has completed.

This is normal and expected behavior.

When you create the first Special Day Class in the database, the manager creates the file NSCHED$:SCHED$SD_CLASSES.DAT with the file protection S:WRED,O:WRED,G:RE,W:RE. If you later copy or back up this file with a different file protection, problems may occur when you use the Special Day Classes.

The /SD_ACTION qualifier is valid only for jobs that have the /NOT_ON qualifier specified for them. When a job has the /ONLY_ON qualifier specified, Special Day actions (HOLD and SKIP) have no effect.

Job Management Manager batch jobs have the following unique characteristics:

The manager queues the job at the specified next run time for the job. The job starts executing when the queues on the system allow it to execute.

If the queues are stopped, full, stalled, or in some other nonrun state, the job remains marked as Queued until the queue allows the job to execute. In this respect, the jobs are controlled by the system batch queues.

If the queue is generic, the job may run on a different node than that specified.

When a job’s mode is set, all the mode-specific characteristics are reset to the default values, or to specified values at the time of setting the mode. These values can be modified later.

Any characteristics of the queue will impact Job Management Manager jobs, including the queue’s run priority.

If a job’s execution queue is on a machine that does not have the manager installed, the job does not execute properly, and is marked as a failed run attempt.

If a job is deleted while pending, the manager will not actually delete the job before execution.

During the time a job is in a queued state, if a request for another run of the same job comes in, the existing request is deleted from the queue and the new one replaces it. Such requests will thus be processed until the job reaches the head of the queue and starts its run.

During the time a job is in a queued state, if a request for characteristic modifications comes in, the existing request is deleted from the queue and the new one replaces it. Such requests will thus be processed until the job reaches the head of the queue and starts its run.

The following logical names supported by the manager provide flexibility around Batch job support:

When you run the manager on multiple nodes of an OpenVMS Cluster, one node becomes the default executor. If load balancing is turned off, this node runs all jobs that do not have a node restriction. If load balancing is turned on and the logical name NSCHED$LBAL$WAIT_AVAIL_NODE is not defined (default) or is set to FALSE, a job that cannot be scheduled to any node in its Load Balance group will run on the default node.

Normally, the first node in the OpenVMS Cluster that starts the manager becomes the default executor; however, the system manager can control this by using the SCHEDULE SET DEFAULT command.

If the default agent node fails or the manager is stopped on that node, another node takes over this function.

To see which node is the current default agent; enter the SCHEDULE SHOW DEFAULT command.

To support batch mode jobs in an OpenVMS Cluster, you should make all batch queues accessible to all nodes in the cluster. If this is not desirable, set up all queues to be accessible to the default node.

If you use the SHOW JOB command from a node that cannot access the batch queue for the job, the command will not be able to find the job.

Job Management Manager provides the opportunity to use dynamic load balancing in an OpenVMS Cluster environment, and runs jobs on the computer that has the lowest current system activity. Your system manager can enable or disable this activity.

Load balancing is enabled by default for all systems in an OpenVMS cluster. To enable load balancing, use the SCHEDULE SET LOAD_BALANCE command. When you enable this feature, Job Management Manager scans all computers in the cluster that are currently running the manager and selects the least loaded of these nodes. The manager assigns the job to run on that node. You can also restrict a job to run on a subset of nodes in a cluster using Load Balance Groups. If you assign a Load Balance Group to a job, the job runs on the least loaded of the nodes in the Load Balance Group. All jobs are load balanced unless you turn off load balancing or a job is restricted to a particular node.

To verify if load balancing is currently enabled, use the SCHEDULE SHOW LOAD_BALANCE command.

For a description of how load balancing works, see Chapter 3, Getting Started with Job Management Manager.

The manager uses a currently least-loaded node approach to determine which node to run a job on. For more information about the algorithm the manager uses, see Chapter 3, Getting Started with Job Management Manager. If you must customize further, you can invoke a command procedure to use a different method to assign jobs to nodes in a cluster. For more information about how to specify your own load balancing algorithm, see the appendix "Customizing Load Balancing."

If a node fails while a job is running, you may want to restart the job on another node. Or, you may decide to put the job on hold and notify the job’s owner to perform manual cleanup.

You can control whether or not to restart a job by specifying the /RESTART or /NORESTART qualifier with the DCL commands SCHEDULE CREATE, SCHEDULE MODIFY, or SCHEDULE COPY, or by choosing Restart options in the DECwindows interface.

You can also restart a job from a particular checkpoint in the job. To set up checkpoints, use the SCHEDULE SET RESTART_VALUE command in your DCL command procedure.

If a node on which the manager is running fails, and the manager is running on at least one other node in the OpenVMS Cluster, the manager:

The manager evaluates the error messages it receives and determines whether the failure is due to its inability to create a detached process or to the job itself failing. If a job has /RESTART set and fails because of a system error that prevents creation of an OpenVMS process, the job is rescheduled according to its interval; /RETRY has no impact on when the job is rescheduled. If the job was created with the /NORESTART qualifier, the job is put on hold and is not restarted automatically.

In addition to the UIC privilege-based security scheme, you can control job access through Job Management Manager using rights identifiers. Each job may have the following identifiers:

If the requesting process also holds that identifier, then access is granted. This feature allows access control to individual jobs on a user-by-user basis, and eliminates the need for privileges for operations personnel. It also removes the need for privileged proxy accounts for remote control of privileged jobs.

The identifiers that are supported in the manager are "general identifiers," or identifiers that can be created with the OpenVMS AUTHORIZE utility and stored in the file RIGHTSLIST.DAT:

Identifier qualifiers do not appear in the DCL user interface as prompts to the CREATE, MODIFY, or COPY commands; they must be explicitly specified on the command line. In the DCL interface, the following qualifiers control the identifiers:

Identifier qualifiers appear in the DECwindows user interface. The following privileges are required to set job identifiers:

Only one identifier value is supported for each of the identifier access qualifiers.

In mixed computing environments, users without system privileges can have security problems initiating and controlling jobs.

One solution is to fill in the following information sheet, use it to create a command procedure, and request a person with SYSPRV privileges to run the command procedure.

Job Management Manager––Job Scheduling Information Sheet

Use this sheet to help track your job scheduling Information:

* = optional

Job Command Information

Main Function to Run:

* Prefunction to Run:

*Postfunction to Run:

Job Information

Job Owner Name:

Job Name:

*Group Name:

*Type Name:

*Node to Run Job on:

*Remote Node to Run Job on:

Detached/Batch/Remote Mode to Run Job:

Retain Job upon Success/Failure/All/None:

*Cluster Nodes to restrict job to LOAD_BALANCE_GROUP:

Schedule Information

Start Time:

Interval:

Days of Week:

*Special Day Classes:

Notification Information

Send Mail on Success/Failure/All/None:

*Send Mail on Special Day Action:

*Mail Addresses:

Terminal Broadcast Message:

OPCOM Message:

Error Recovery Information

Restart on Crash:

Retry on Job Failure:

*Retry Interval:

*Retry Quantity:

*Stall Notify

*Job to Run When Stalled (SJOB):

*Max Time Notify:

*Job to Run When Max Time Exceeded (TJOB):

Logging Information

*Output Logfile Name:

Job Access Security Information

*Read Access Identifier (RDID):

*Execute Access Identifier (EXID):

*Write Access Identifier (WRID):

Other Job Run Information

*Dependent on What Other Jobs (SYNCHRONIZATION):

*Run Priority:

*Comment

Batch Queue Execution Specific Information

Queue to Run Job:

*Queue Priority (QPRIORITY):

*CPU Limit for Job:

You can use a postfunction to create a conditional situation between two jobs. For example, after Job A completes, and if a single condition is met, you want Job B to execute.

If you want a dependent job to run only after one specific ending condition from the main function, use a simple DCL procedure similar to the following:

$ IF NSCHED_STATUS .EQ. the-condition-you-want
$ THEN
$ EXIT 1
$ ELSE
$ EXIT 0
$ ENDIF

For functions that involve timing between different nodes, such as maximum run time and start time for remote or batch mode jobs, system times must be synchronized.

If you are concerned about synchronizing local and remote databases, there are at least two areas of synchronization to consider:

The manager does the rest of it.

Activate the debug log file if you are having a problem, and need to track messages, actions, and times.

Follow the steps in the table below to activate the debug log the next time the manager starts. If you want to turn on debugging immediately, use the SCHED SET DEBUG ON command.

Turning debugging on creates a log file that describes messages, actions, and times. One log file is created in NSCHED$DATA for each machine running the NSCHED process. The file is called 'nodename'.LOG.

In most cases the log file is fairly small. However, the log file that belongs to the default manager could get as large as 5000 blocks. To free disk space, simply purge the log file. The manager creates a new log file at each startup, and purges the log files to limit them to two versions.

You need not create log files until you have a reason to use them. In general, if you have plenty of free space, write the log files.

The system rating is the average between the Memory_rating and the CPU_rating. When jobs are ready for execution, they find the node with the highest rating, and send the job to that node.

The algorithm for calculating ratings follows:

Total Rating = Cpu_rating + Memory_rating

Cpu_rating = Cpu_calculation * CPU_weight *
(1 + ((number of CPUs - 1) * .2)) / number of CPUs

Memory_rating = Memory_calculation * Memory_weight

Cpu_calculation = ( %Free CPU * (VUPS per CPU) * #CPUs
* COM-FACTOR ) + (3 * (CPUs* VUPS per CPU))

COM-FACTOR = 0.5 if the ((number of COM+CUR+COMO processes on the
system)-1) is more than the number of CPUs

COM-FACTOR = 1.0 if the ((number of COM+CUR+COMO processes on the
system)-1) is equal to the number of CPUs

COM-FACTOR = 1.5 if the ((number of COM+CUR+COMO processes on the
system)-1) is less than the number of CPUs

Memory_calculation= (FREE_PAGES/TOTAL_PAGES) * MEG * 10

If Current Jobs is greater than or equal to MAX_JOBS, then rating = 0

CPU_weight and Memory_weight have values 0 through 1.

To view the "VUPS per CPU" rating of the system, use the following command: $SCHEDULE SHOW CPU_RATING

This command displays the CPU (VUPS) rating of the system used in the algorithm’s calculation. For example, the command returns the following for a DS20E:

$SCHEDULE SHOW CPU_RATING
Machine Name <XYZ> Hardware Name <COMPAQ AlphaServer DS20E 5o00 MH>
Hardware Model <1921> Rating <1000>

If the system does not have a CPU rating in the Job Management Manager CPU database, Job Management Manager returns a message saying the CPU is not rated. If you see this message, contact VSI Technical Support and provide them with the text of the message. The following is a sample message for an unrated machine:

$SCHEDULE SHOW CPU_RATING
Machine Name <XYZ> Hardware Name <COMPAQ AlphaServer DS20E 5o00 MH>
Hardware Model <1921> is not rated

When jobs are loaded, the manager identifies the node with the highest rating and loads the first job on that node. Then the manager checks to see which node has the highest rating and loads the next job onto that node. Each time the manager determines the node with the highest rating, it checks the node’s MAX_JOBS value (the maximum number of jobs allowed) before loading the job. Jobs are loaded on each node until that node’s MAX_JOBS value is reached.

A node’s rating is updated:

You can adjust the CPU rating in the following way. Define the logical name NSCHED$LBAL_INSENSITIVE to a non-zero integer percentage value. When this logical is greater than zero, the load balancing algorithm considers all systems that are rated within the given percent of each other to be the same rating. They are then load balanced using round robin scheduling. This distributes the load more equitably among similarly rated systems. We recommend you define this logical name cluster wide, or in the system table of each node in the cluster.

You can adjust when a rating is updated in the following way. Define the logical name NSCHED$LBAL$UPDATE_RATING to ON. The manager will decrease a node’s rating when a job is sent to it, so a node is aware of the number of jobs pending and the rating routine will take these jobs into consideration. We recommend you define this logical name cluster wide, or in the system table of each node in the cluster.

The rating is calculated only on the node where the job state changes. If you want to use load balancing on a particular node, you will get an accurate rating for it after the job is started, or after its regular update.

There is no minimum rating a node must have in order to have a job started on it. To remove a node from load balancing, set the rating weights for that node to 0. If the rating is 0, the node is not used in load balancing. When a node has reached its MAX_JOBS value, its rating is zero.

You can balance a job load further by specifying groups of nodes in a cluster that certain jobs may run on. The creation and deletion of load balance groups is a management function. To specify these groups, follow these steps:

Scheduling Notes

The following notes provide further information about scheduling load balancing and Load Balance Groups. These scenarios assume the manager is installed on all nodes in a cluster.

Special Case Job and Load Balance Group Definitions

The following are special cases with Job and Load Balance Group definitions:

A node with group definitions and jobs referencing these groups is moved from a cluster to a standalone system:

In the Motif interface, you can create Load Balance group definitions; however, only the local node is available to add to a Load Balance group. If a node is removed from a group, it is temporarily added to the list of Unselected Nodes. However, when the job modification is complete, it is deleted from the available list. In the Configuration CLI interface, any node can be added or removed from a group (see SCHEDULE CONFIG ADD NODE). For scheduling, load balancing is disabled by default on a standalone node. A job can only run on the standalone node.

A node with group definitions and jobs referencing these groups is moved from a cluster to another cluster:

A job referencing a group with nonexistent nodes does not load balance to nodes that do not exist in the current cluster. In the Motif interface, group definitions can be created and deleted. However, only cluster nodes from the new cluster are available to add to any group. If a node from the former cluster is removed from a group, it is temporarily added to the list of Unselected Nodes. However when the job modification is complete, it is deleted from the available list. In the Configuration CLI interface, any node can be added or removed from a group (see SCHEDULE CONFIG ADD NODE). For more information, see the section Scheduling Notes.

A standalone node with no group definitions:

In the Motif interface, you can create group definitions; however, only the local node is available to add to any group. In the Configuration CLI interface, you can add or remove any node from a group (see SCHEDULE CONFIG ADD NODE). Load balancing is disabled by default on a standalone node. A job can only run on the standalone node.

A cluster node with no group definitions:

In the Motif interface, group definitions can be created using nodes available in the cluster to add to any group. In the Configuration CLI interface, any node can be added or removed from a group (see SCHEDULE CONFIG ADD NODE). Load balancing is enabled by default. For more information, see the section Scheduling Notes.

To check if the manager is installed on your system and to see which nodes of an OpenVMS Cluster currently have the manager running, enter the following command:

$ SCHEDULE SHOW STATUS

If the manager is not installed, contact your system manager for more information.

To see whether a remote agent is installed on a remote node running another operating system, use the following command:

$ SCHEDULE SHOW STATUS/REMOTE_NODE=nodename

This document describes all Job Management Manager commands. You can also get help online by entering either of the following commands:

$ HELP SCHEDULE
$ SCHEDULE HELP

General commands are for Job Management Manager users. They allow you to:

For a summary of commands, see the Summary of Job Management Manager Commands. For a description of individual commands, see VSI Job Management for OpenVMS Command Reference Guide.

Management commands are for system managers. They allow you to set up, monitor, and manage the Job Management Manager environment, on an OpenVMS Cluster or among remote nodes on your network. For example, management commands let you set the following:

Management commands also let you:

Most management commands begin with the word SCHEDULE. However, some management commands are standard DCL commands that perform a specific task in support of Job Management Manager.

For a summary of commands, see the Summary of Job Management Manager Commands. For a description of individual commands, see VSI Job Management for OpenVMS Command Reference Guide.

The following restrictions apply to creating or modifying job dependencies:

Before a job can run, all jobs on which it depends must run successfully, at a time later than the dependent job’s synchronization time. The synchronization time is either the last time the job’s dependency list was modified, or the last time the job completed — whichever occurred most recently.

For example, if Job C depends on Jobs A and B, then Job C will not run until Jobs A and B have successfully run following Job C’s synchronization time. If Job D is added to Job C’s dependency list, then Jobs A and B, as well as D must run again before Job C can run.

This is because Job C’s synchronization time would reflect the time that Job D was added to its dependency list.

SCHEDULE> SET JOB job-specifier -
_SCHEDULE> /NO_DEPENDENCY=( dependency [, ...]) )

You can define Special Day Classes by creating a named class and then associating a list of date-expressions with it. Special Day Classes are governed by the following rules:

Acceptable Dates for Special Day Classes

Special Day Classes can contain dates beginning the year 1970 and continuing through the year 2037.

Required Privileges

Only users with OPER or SYSPRV privileges are allowed to create, modify, and delete Special Day Classes.

How to Define Special Day Classes

The following example shows how a Special Day Class is defined in the DCL interface:

SCHEDULE> CREATE MY_CLASS /SD_CLASS -
_SCHEDULE> /DATES=(1-JAN-2012,25-DEC-2011,26-NOV-2011)

How to Add Days To Existing Special Day Classes

The following example shows how to add days to an existing Special Day Class.

SCHEDULE> MODIFY/SD_CLASS/DATES=(1-JAN,TOMORROW) classname

How to Remove Existing Days from a Class

The following example shows how to remove existing days from a Special Day Class.

SCHEDULE> MODIFY/SD_CLASS/NODATES=(TODAY,12-DEC-2011) classname

Once you define Special Day Classes, you can use one or more classes in combination as scheduling constraints for jobs. Defining Special Day constraints for jobs is supported in all the user interfaces of the manager.

You can provide scheduling restraints for jobs by associating a Special Day Restriction Expression with a job-specifier. A Special Day Restriction Expression is a list of one or more Special Day Classes that defines one of the following:

The job-specifier can be a specific job name or use wildcards in the job name. The job-specifier can include a GROUP or TYPE indicator. For example:

SCHEDULE> MODIFY JOBX/GROUP=BATCH -
_SCHEDULE> /SD_RESTRICTION=(COMPANY_HOLIDAYS,PLANT_SHUTDOWNDAYS) -
_SCHEDULE> /NOT_ON

Restricting a Job from Running on Special Days

You can restrict a job from running on certain days by using the /NOT_ON qualifier in conjunction with the job’s schedule interval. For example:

SCHEDULE> MODIFY JOBX /SD_RESTRICTION=(COMPANY_HOLIDAYS)/NOT_ON

This example instructs the manager not to run JOBX on company holidays.

The manager calculates the job’s next scheduled run time according to the job’s schedule interval and then checks against its Special Day Restrictions. If the job’s next scheduled run time falls on a restricted Special Day, the manager applies one of two user-specified Special Day Actions:

In both cases, if the job has OPCOM or NOTIFY set, the owner of the job and the operator are notified of the Special Day conflict and what Special Day Action was applied.

Restricting a Job to Run Only on Special Days

You can restrict a job to run only on Special Days by using the /ONLY_ON qualifier. For example:

SCHEDULE> MODIFY JOBX/SD_RESTRICTION=(LAST_DAY_OF_FISCAL_QUARTER)/ONLY_ON

This example tells the manager to run JOBX only on the days in the class LAST_DAY_OF_FISCAL_QUARTER.

When the manager calculates the job’s next scheduled run time, the job’s schedule interval is applied. The manager then checks to see if the resulting day is a day the job is permitted to run. If not, the manager applies the schedule interval again until it finds a day the job is permitted to run.

If the manager does not find a day on which the job is permitted to run, it puts the job on hold. In either case, if the job has OPCOM or NOTIFY set, the owner and operator are notified of the conflict, and what Special Day Action was applied.

Restriction Expressions Are Mutually Exclusive

You can use either /NOT_ON or /ONLY_ON for any given job. You cannot use both Special Day qualifiers for the same job.

Special Day Actions specify what action the manager should take when a job’s scheduled run time happens to fall on a day that is part of a Special Day Class. Special Day Actions are specified on a per-job basis. For example, users can instruct the manager to:

Setting a Job’s Special Day Action

Following is an example of how to set a job’s Special Day Action:

SCHEDULE> MODIFY MYJOB/SD_ACTION=HOLD

SD_ACTION can be HOLD or SKIP.

No Special Day Action Specified

If you do not explicitly specify a Special Day Action for a job, the manager applies the system default action at the time the job’s Special Day Restrictions are created. For example, if you define the system default Special Day Action to be SKIP, then new Special Day Restrictions created for jobs have the default Special Day action of SKIP. If you redefine the system default Special Day Action to HOLD, new Special Day Restrictions have the default Special Day Action of HOLD.

You can redefine the system default by defining the logical NSCHED_DEFAULT_SD_ACTION. For example:

$ DEFINE NSCHED_DEFAULT_SD_ACTION HOLD

NSCHED_DEFAULT_SD_ACTION can be HOLD or SKIP. The default as shipped is SKIP.

Redefining the system default Special Day Action does not affect the Special Day Action of jobs with existing Special Day Restrictions.

You can obtain information about the Special Days defined on your system by using the SHOW command. For example:

SCHEDULE> SHOW SD_CLASS name

You can show the Special Day Classes defined on the system, or see the definition of a specific Special Day Class.

When using the SHOW command, Special Day names can contain wildcards.

You can also use the SHOW command to find out what Special Day Restrictions are associated with a job. Job names can also use wildcards, and can include the /GROUP and /TYPE indicators. For example:

SCHEDULE> SHOW JOB/FULL
SCHEDULE> SHOW JOB/GROUP=BATCH/FULL

To change the resource files, follow these steps:

The Motif interface for the manager includes three main windows:

For the manager, mouse buttons perform the following functions:

Menus are not available in the Real Time Message Display window.

The following tables describe the uses of menus and buttons in the Job Display windows:

To start the manager with the Motif interface, enter the following command at the DCL prompt:

$ SCHEDULE/INTERFACE=DECWINDOWS

Three windows and a dialog are displayed, as shown in the following figure. The Graphical Display window, Linear Display window, and Real Time Messages Display window have scroll bars for scrolling through displayed information. You can also resize them or minimize them (shrink them to icons).

The Load Jobs dialog lets you select and display jobs from the Job Management Manager database.

You select jobs to display by filling in one or more of the fields in the window. You can use wildcard characters (*) in any of these fields.

The jobs you select from the Load Jobs dialog are displayed in both Jobs windows.

Clicking OK when the fields are filled in as shown in the figure is equivalent to entering either of the following DCL commands:

$ SCHEDULE SHOW JOBS/USER_NAME=SYSTEM/GROUP=*/TYPE=*/CLUSTER_NODE=*
$ SCHEDULE SHOW JOBS/USER_NAME=SYSTEM

The Load Jobs dialog is displayed when you start the Motif interface to Job Management Manager. You can display this dialog at any time during your session by clicking the Load Jobs... button in the Graphical or Linear Display window.

Refer to Loading Jobs to Display for more information about how to use the Load Jobs dialog to select jobs to display.

The Graphical Display window provides a graphical display of jobs in the Job Management Manager database. Each box shown in this window represents a job. Each job is labeled with its job number preceding and followed by its job name. Refer to Interpreting Your Job Display for more information about interpreting your job display.

The Graphical Display window also lets you display a Navigation window that allows you to select and display portions of the window that are not visible, and to change the size of boxes displayed (see Using Navigation Windows).

The menu bar on this window provides the following five pull-down menus:

Pressing and holding MB3 on a job in the Graphical Display window displays a pop-up menu with the same options on the Jobs pull-down menu. Moving the pointer over Control and dragging the mouse to the symbol [-> displays a submenu with the same choices found on the Control pull-down menu. To select one of these submenu items, move the pointer over the menu item you want and release MB3.

The Linear Display window displays a list of the jobs you selected from the Load Jobs dialog. Each rectangle in the Linear Display window shows the number, name, and owner of a selected job.

By default, all jobs are sorted by job number in the Linear Jobs Display window. Refer to Sorting Jobs in the Linear Display Window for more information about how to sort jobs in the Linear Display window.

The Linear Display window lets you display a Navigation window that allows you to select and display portions of the window that are not visible, and to change the size of boxes displayed (see Using Navigation Windows).

The menu bar in this window includes the same five pull-down menus as the Graphical Display window, with the following differences:

Pressing and holding MB3 a job in the Linear Display window displays a pop-up menu with the same choices found on the Jobs pull-down menu. Moving the pointer over Control and dragging the mouse to the symbol [-> displays a submenu with the same choices found on the Control pull-down menu. To select one of these submenu items, move the pointer over the menu item you want and release MB3.

The Real Time Messages Display window displays all Job Management Manager job events on the system as they occur during your Job Management Manager session. This window maintains up to 100 lines of messages; you can use the scroll bar to see messages that have scrolled off the top of the window. Messages from previous sessions are stored in a log file with NSCHED$:DATA:VERMONT_CREAMERY.LOG as a default name. You need SYSPRV right to view this log file.

Some messages are highlighted, while others are displayed in normal print.

On a color display, different types of messages can appear in different colors, as determined by the file SCHEDULER$MOTIF.DAT in the DECW$SYSTEM_DEFAULTS directory or your DECW$USER_DEFAULTS directory.

Each job box in the Graphical Display window contains two symbols. The symbol in the upper-left corner indicates the last completed status of that job. The symbol in the bottom-right corner indicates the current state of that job.

For example, the hand symbols in the following job box indicate that the job ran successfully last time, and is currently on hold.

The following table describes the symbols displayed in job boxes.

When you select jobs to display in the Load Jobs dialog box, the manager also displays any jobs that are connected to the selected jobs by dependencies. These

dependency-related jobs can be on the current node or a remote node. The manager displays the job boxes for selected and unselected jobs differently, as described in the following table. The owner of an unselected job is always displayed.

The following figure shows an example of selected and unselected job boxes as shown in the Graphical Display window:

In the example shown in the figure, a group of jobs was selected. This group contains two jobs:

Jobs without dependencies are displayed at the top of the Graphical Jobs Display window, and jobs with dependencies are displayed below. Arrows indicate job dependencies. Each arrow indicates the order in which the connected jobs run; the arrow points to the job that depends on the other job.

To view the attributes of a job, select it using MB1 and choose Edit... from the Jobs menu, or choose Edit... from the job’s pop-up menu. In the Graphical Jobs Display window, you can also Double-click on the job using MB1. The manager displays the job in the Job Edit dialog box. You can also edit the job from this dialog box (see Editing a Job).

More information about a job is available by clicking on the buttons at the bottom of the Job Edit dialog box: Auxiliary Options..., View Deps..., and Day Class Restrictions....

Viewing the attributes of a job is similar to using the following command in the DCL interface:

$ SCHEDULE SHOW JOB job_name/FULL

The following figure shows the primary Job Edit dialog box:

A job output file captures the output of a job. An output file is not created unless a file name has been entered in the Output File field of the job’s Job Edit dialog box. When you view the output file for a job, the manager creates a window to display the output log file. You can shrink this window to an icon.

To view the output file for a job, select the job and choose Display Output... from the Jobs menu. When you are finished viewing the information, click the Dismiss button to remove the window.

The Job Monitor window lets you monitor a job’s resource usage based on its historical minimum, average, and maximum usage. To display the Job Monitor window, select a job and choose Monitor... from the Jobs menu. You can shrink this window to an icon. The following figure shows the Job Monitor window:

The top half of the Job Monitor window lists job information such as the job name and number, user name, success count, and status. On the bottom-left are histograms that graphically display the resource usage of the job. For each job running in the Display window, you can monitor the current resource usage of the following:

On the bottom-right of the window are the actual numbers associated with the histograms.

The rectangle outlines next to each resource indicate the historical usage. The left side of each rectangle represents the minimum usage, the right side represents the maximum usage. When information is within a narrow range, a thin or thick line is displayed instead of a rectangle.

The right sides of the rectangles are positioned relative to the maximum usage of each resource. Therefore, when a job is not running, all rectangles will be even on the right side.

A Navigation window is a small window that lets you view the overall contents of the larger window, including the areas not currently displayed. You can see the number of selected jobs not currently visible in the larger windows. Navigation windows do not display the text displayed in the larger windows. You cannot shrink Navigation windows to icons.

You can display a Navigation window for either the Graphical or Linear Display window by clicking on the box located in the corresponding window where the horizontal and vertical scroll bars meet. When you have finished using the Navigation window, click on this box again to remove the Navigation window from the screen.

The following sections describe how to use a Navigation window to:

The next two figures show the Navigation windows for the Graphical Display window and the Linear Display window.

In a Navigation window, the contents of the main window are displayed within a rectangular outline in the Navigation window. To select and display a different area of the main window, click inside this outline and use MB1 to drag it to the new location inside the Navigation window. The main window scrolls to show the new area.

To scale objects in the Graphical Display window (for instance, to see more job boxes in a smaller area):

Creating Special Day Classes requires either OPER or SYSPRV privileges.

You can create a Special Day Class by choosing Create... from the Day Classes menu. This action displays the Special Days Calendar dialog; you select the days that you want to make up the class by clicking them in the calendar. The shaded days on the calendar define the Special Day Class.

You can switch the entire year, complete months, or individual days by clicking MB1 on them. You can switch all monthly occurrences of a day by clicking its symbol. For example, to select all Wednesdays in May, click the W under May on the Calendar screen.

Select any year from 2010 through 2019 by clicking up or down on the scroll bar to the right of the calendar. You can scroll to the next decade by dragging the scroll bar to the bottom (2019) and then clicking MB1 on the stepping arrow beneath the scroll bar. You can scroll to the previous decade by dragging the scroll bar to the top (2010) and then clicking MB1 on the stepping arrow above the scroll bar. You can use the scroll bar and arrows to navigate through the years 1970-2037.

To create Special Day Classes with the Motif interface:

To edit a Special Day Class with the Motif interface:

To delete a Special Day Class with the Motif interface:

Day Class Restrictions let you restrict a job so that it:

To enter or edit Day Class Restrictions for a job, follow these steps:

You can create, edit, or delete a Load Balance Group in the Load Balance Group Editor. To access the Load Balance Group Editor, select Load Balance Groups Editor… from the Linear Display or Graphical Display Edit menu. The Load Balance Group Editor appears.

From the editor, you can select the nodes from your local cluster that you want to include as members of the Load Balance group. The dialog box includes a list of Load Balance Groups. For the currently selected Load Balance group, the editor displays a list of Unselected Nodes and a list of Selected Nodes. With the editor, you can also delete a group and specify a new group name.

To create Load Balance Groups, you must have either OPER or SYSPRV privileges.

To view the nodes that are members of a Load Balance group, click the group name in the Load Balance Groups list. You can move a node from the Unselected Nodes list to the Selected Nodes list by clicking on the node name and then clicking on the ">" button. The ">>" button lets you move all Unselected Nodes to the Selected Nodes list. The "<" and "<<" buttons remove nodes from the Selected Nodes list.

To create Load Balance Groups with the Motif Interface, follow these steps:

To edit a Load Balance Group with the Motif interface, follow these steps:

To delete a Load Balance Group with the Motif interface, follow these steps:

To assign a Load Balance Group to a job or change the Load Balance Group assigned to a job with the Motif Interface, follow these steps: